mirror of https://github.com/kata-containers/kata-containers.git synced 2026-03-18 10:44:10 +00:00

Files

Dan Mihai 20ca4d2d79 runtime: DEFDISABLEBLOCK := true

1. Add disable_block_device_use to CLH settings file, for parity with
   the already existing QEMU settings.

2. Set DEFDISABLEBLOCK := true by default for both QEMU and CLH. After
   this change, Kata Guests will use by default virtio-fs to access
   container rootfs directories from their Hosts. Hosts that were
   designed to use Host block devices attached to the Guests can
   re-enable these rootfs block devices by changing the value of
   disable_block_device_use back to false in their settings files.

3. Add test using container image without any rootfs layers. Depending
   on the container runtime and image snapshotter being used, the empty
   container rootfs image might get stored on a host block device that
   cannot be safely hotplugged to a guest VM, because the host is using
   the same block device.

4. Add block device hotplug safety warning into the Kata Shim
   configuration files.

Signed-off-by: Dan Mihai <dmihai@microsoft.com>
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Signed-off-by: Cameron McDermott <cameron@northflank.com>

2026-01-28 19:47:49 +01:00

2.3 KiB

Raw Blame History

Storage

Limits

Kata Containers is compatible with existing standards and runtime. From the perspective of storage, this means no limits are placed on the amount of storage a container workload may use.

Since cgroups are not able to set limits on storage allocation, if you wish to constrain the amount of storage a container uses, consider using an existing facility such as quota(1) limits or device mapper limits.

virtio SCSI

If a block-based graph driver is configured, virtio-scsi is used to share the workload image (such as busybox:latest) into the container's environment inside the VM.

virtio FS

If a block-based graph driver is not configured, a virtio-fs (VIRTIO) overlay filesystem mount point is used to share the workload image instead. The agent uses this mount point as the root filesystem for the container processes.

For virtio-fs, the runtime starts one virtiofsd daemon (that runs in the host context) for each VM created.

Devicemapper

The devicemapper snapshotter is a special case. The snapshotter uses dedicated block devices rather than formatted filesystems, and operates at the block level rather than the file level. This knowledge is used to directly use the underlying block device instead of the overlay file system for the container root file system. The block device maps to the top read-write layer for the overlay. This approach gives much better I/O performance compared to using virtio-fs to share the container file system.

Hot plug and unplug

Kata Containers has the ability to hot plug add and hot plug remove block devices. This makes it possible to use block devices for containers started after the VM has been launched.

Users can check to see if the container uses the devicemapper block device as its rootfs by calling mount(8) within the container. If the devicemapper block device is used, the root filesystem (/) will be mounted from /dev/vda. Users can enable direct mounting of the underlying block device by setting the runtime configuration flag disable_block_device_use to false.

2.3 KiB Raw Blame History