Learn Kata Containers - Storage: Virtio-blk, Virtio-fs & Devices

#Introduction

In episode 7 you understood how networking gets into the microVM through virtio-net. Episode 8 follows the same path for data: how container images, volumes, and physical devices reach the guest. This is an important question because storage is where workload data lives — understanding its path determines your data's performance, reliability, and sometimes security.

Kata Containers uses three main mechanisms for data: virtio-blk for disks, virtio-fs for filesystem sharing, and VFIO for physical device passthrough. Plus how standard Kubernetes volumes — emptyDir, PVC, hostPath, and block devices — are translated into these mechanisms.

#The Rootfs Image as virtio-blk

#The Image Path to the Guest

A container image pulled on the host can't be executed directly by the guest — the guest is a separate machine. Kata solves this by providing the image as a virtio-blk device: after the image is pulled by containerd on the host, Kata prepares a virtual disk containing the container rootfs and attaches it to the microVM as a block device.

When the container is created, the guest boots, and the rootfs image is already available as a disk. Applications in the guest read from that virtual disk as if reading a physical disk.

#Inspecting Block Devices

To see the block devices inside the guest, enter it with kata-runtime exec:

See the block devices inside the guest

kata-runtime list
sudo kata-runtime exec <sandbox-id> lsblk

kata-runtime exec <sandbox-id> lsblk displays the list of block devices inside the guest. You'll see the container rootfs as virtio-blk devices (vda, vdb, etc.) — proof that the image really becomes a virtual disk in the guest.

#Why This Differs from Regular Containers

With runc, the image is unpacked to overlayfs on the host and used directly by host processes. With Kata, the image becomes a virtual disk mounted in the guest — there's a virtualization layer in between. The consequence: image I/O must go through the virtio path (host → VMM → guest), which adds a little overhead compared to direct host access, but that's a fair price for the isolation you get.

#virtio-fs: Shared Volume Between Host and Guest

#Concept

virtio-fs is a shared filesystem mechanism: a directory on the host is shared to the guest in a way the guest sees as a filesystem. Kata uses virtio-fs to connect pod volumes to the microVM. The difference from virtio-blk: virtio-blk provides an isolated disk, while virtio-fs shares a filesystem that lives on the host.

This pattern matters for volumes like emptyDir whose contents are created on the host and must be visible in the guest.

#Kubernetes Volumes in Kata

How standard Kubernetes volumes are translated:

emptyDir: a temporary directory on the host, shared to the guest via virtio-fs.
PVC (mounted filesystem): a volume already mounted on the host, shared to the guest via virtio-fs.
hostPath: a direct node directory, shared via virtio-fs — remember, this sacrifices some isolation because the pod can read host directories.
Block device (volumeMode: Block): a raw disk, provided as virtio-blk to the guest — no filesystem on the host.

The virtio-fs mechanism is configured in the configuration file (episode 5):

shared_fs = "virtio-fs" is the modern default. Previously Kata used virtio-9p, which was slower and less secure; virtio-fs replaced it with far better performance and features.

#Verifying Volumes in the Guest

Create a pod with emptyDir and verify the volume is visible in the guest:

Pod with emptyDir

apiVersion: v1
kind: Pod
metadata:
  name: kata-storage
spec:
  runtimeClassName: kata
  containers:
    - name: app
      image: alpine
      command: ["sleep", "3600"]
      volumeMounts:
        - name: cache
          mountPath: /cache
  volumes:
    - name: cache
      emptyDir: {}

After the pod is running, enter the guest and look at the volume directory:

Check the volume in the guest

kata-runtime list
sudo kata-runtime exec <sandbox-id> mount | grep cache

kata-runtime exec <sandbox-id> mount | grep cache shows the volume mount inside the guest — a virtio-fs filesystem mounted to /cache.

Note

Virtio-fs shares a filesystem, not a disk. Data stays on the host and is only seen by the guest through the virtio-fs interface. This differs from virtio-blk, which gives the guest a fully isolated disk. For sensitive data requiring strict isolation, consider block device mode.

#Device Passthrough: VFIO GPU and NIC

#The VFIO Concept

For workloads that need physical device access — GPUs for AI/ML, special NICs, or FPGA devices — Kata supports passthrough via VFIO. The principle: the device is released from the host (through the vfio-pci driver) and given directly to the microVM. The guest sees the real physical device, not a virtual one.

VFIO is the opposite of virtio: virtio provides virtual devices with full isolation; VFIO provides physical devices with direct access — fast but sacrifices device-level isolation.

#Checking Passthrough Support

Passthrough starts on the host. Make sure IOMMU is active and the device can be bound to vfio-pci:

ls /sys/kernel/iommu_groups/ shows the IOMMU groups — the devices that can be passed through are listed here. Without an active IOMMU, VFIO passthrough can't work. The full details of GPU passthrough will be covered in episode 10.

#Common Pitfalls

Slow PVCs: filesystem volumes via virtio-fs are generally fine, but heavy I/O workloads need lab testing.
hostPath that leaks: hostPath gives the guest access to host directories — only use it for data the pod is genuinely allowed to read.
Wrong block device mode: a PVC with volumeMode: Filesystem can't be accessed as a raw block in the guest.
VFIO without IOMMU: passthrough won't work; the pod fails with a device-not-available error.

#Conclusion

What you should take away:

The rootfs image is provided to the guest as a virtio-blk device.
virtio-fs shares the host filesystem with the guest for volumes.
emptyDir, PVC, and hostPath are translated to virtio-fs; block devices to virtio-blk.
VFIO releases physical devices to the guest for GPU/NIC passthrough.
Virtio for isolation; VFIO for performance — understand the trade-offs.
kata-runtime exec verifies block devices and mounts inside the guest.

In the next episode, episode 9, we'll cover Kata agent and image management — the agent's role as the container manager inside the guest, how images are pulled and mounted into the guest (snapshotter), and the difference between pulling on the host versus pulling directly in the guest.