mirror of
https://github.com/kata-containers/kata-containers.git
synced 2026-07-12 01:44:30 +00:00
20ca4d2d79
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>
58 lines
2.3 KiB
Markdown
58 lines
2.3 KiB
Markdown
# Storage
|
|
|
|
## Limits
|
|
|
|
Kata Containers is [compatible](README.md#compatibility) with existing
|
|
standards and runtime. From the perspective of storage, this means no
|
|
limits are placed on the amount of storage a container
|
|
[workload](README.md#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](#devicemapper) limits.
|
|
|
|
## virtio SCSI
|
|
|
|
If a block-based graph driver is [configured](README.md#configuration),
|
|
`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](README.md#configuration), a
|
|
[`virtio-fs`](https://virtio-fs.gitlab.io) (`VIRTIO`) overlay
|
|
filesystem mount point is used to _share_ the workload image instead. The
|
|
[agent](README.md#agent) uses this mount point as the root filesystem for the
|
|
container processes.
|
|
|
|
For virtio-fs, the [runtime](README.md#runtime) starts one `virtiofsd` daemon
|
|
(that runs in the host context) for each VM created.
|
|
|
|
## Devicemapper
|
|
|
|
The
|
|
[devicemapper `snapshotter`](https://github.com/containerd/containerd/blob/main/docs/snapshotters/devmapper.md)
|
|
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](README.md#configuration) flag `disable_block_device_use` to
|
|
`false`.
|