Kata Containers + podman in RHEL8 Beta


Are you feeling adventurous today? Good, so let’s give a try to some of the coolest upcoming technologies.

  • podman is a tool for managing containers. If you’re familiar with docker, you’ll find it’s CLI quite similar. RHEL8 will include podman as part of the container-tools module.

  • Kata Containers is an OCI Runtime which runs containerized processes inside a VM, using QEMU+KVM. This gives you the versatility of containers, with the isolation of a VM, among other nice features like static resource management and PCI passthru. Kata is not included nor supported by RHEL8, but I hope it’ll eventually make into some minor release.

  • RHEL8 Beta is… well, if you’re reading this, I’m pretty sure you already know what RHEL8 is ;-)


I assume you already have installed RHEL8 Beta bare metal or inside a VM. In case of the later, make sure you have nested virtualization enabled in your Host, and virtualization extensions are available in the VM.

As we’re going to need to download some packages, make sure you’ve registered the system and attached it to a pool using subscription-manager. A developer or evaluation subscription should be enough.

Getting your hands dirt

First, we’re going to install the container-tools module, which includes everything we need to start running containers in RHEL8.

sudo yum module install container-tools

As Kata Containers is not yet available in RHEL8, I’ve created a repo so you don’t need to build it from sources. There are basically the same RPMs available in Kata’s OBS service for Fedora 28, except for kata-runtime, which I rebuilt to make it play nice with RHEL8 dependencies.

Let’s add this repository to the yum config. Create the file /etc/yum.repos.d/kata.repo, and drop in something like this:

name = Kata Containers for RHEL8
baseurl = https://repo.sinrega.org/kata-rhel8
enabled = 1
gpgcheck = 0

Now we’re going to install kata-runtime, which will grab the rest of the packages as a dependency:

sudo yum install kata-runtime

We’re almost there. We just need to instruct podman to use kata-runtime as the OCI Runtime. To do this, we need to override some libpod (podman’s underlying library) defaults:

sudo cp /usr/share/containers/libpod.conf /etc/containers/libpod.conf

Now let’s edit /etc/containers/libpod.conf, and add /usr/bin/kata-runtime at the beginning of the runtime-path list. It should end looking like this:

# Paths to look for a valid OCI runtime (runc, runv, etc)
runtime_path = [

We also need to disable SELinux labeling, as Kata Containers still doesn’t support it. Someone may argue that this isn’t needed as Kata uses a different security model, but I think Kata should consider adding support for it (an additional security layer never hurts ;-).

For the moment, go to the end of /etc/containers/libpod.conf, uncomment the label option and set it to false. It should look like this:

# Default libpod support for container labeling

Running your first virtualized container

OK, we’re ready for running our first virtualized container. And we’re going to do it in exactly the same way we would run a conventional container:

[slp@kata ~]$ sudo podman run -ti --rm fedora /bin/bash
Trying to pull registry.redhat.io/fedora:latest...Failed
Trying to pull quay.io/fedora:latest...Failed
Trying to pull docker.io/fedora:latest...Getting image source signatures
Copying blob sha256:d0483bd5a55488f5ba6383a5cc8553d5101864f03acd07eabc5df7563c3692cf
 83.23 MB / 83.23 MB [======================================================] 4s
Copying config sha256:8c568f1043264e34f0a8774587266565c7e5e54e9ea6b97ab459086d18ac5175
 2.29 KB / 2.29 KB [========================================================] 0s
Writing manifest to image destination
Storing signatures
[root@023baa97456d /]# uname -a
Linux 023baa97456d 4.14.67-10.1.container #1 SMP Fri Sep 28 02:53:22 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[root@023baa97456d /]# id
uid=0(root) gid=0(root) groups=0(root)
[root@023baa97456d /]# 

So, how do we know we’re using Kata? Let’s switch to another terminal or ssh session and search for the container’s ID in the process list:

[slp@kata ~]$ ps -ef | grep 023baa97456d
root      2172     1  0 08:19 ?        00:00:00 /usr/libexec/podman/conmon -s -c 023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f -u 023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f -r /usr/bin/kata-runtime -b /var/lib/containers/storage/overlay-containers/023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f/userdata -p /var/run/containers/storage/overlay-containers/023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f/userdata/pidfile -l /var/lib/containers/storage/overlay-containers/023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f/userdata/ctr.log --exit-dir /var/run/libpod/exits --socket-dir-path /var/run/libpod/socket -t --log-level error
root      2185  2172  3 08:19 ?        00:00:04 /usr/bin/qemu-lite-system-x86_64 -name sandbox-023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f -uuid 9f6fcd38-4d7a-49a1-8ead-0a2b5a3f111b -machine pc,accel=kvm,kernel_irqchip,nvdimm -cpu host,pmu=off -qmp unix:/run/vc/vm/023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f/qmp.sock,server,nowait -m 2048M,slots=10,maxmem=4804M -device pci-bridge,bus=pci.0,id=pci-bridge-0,chassis_nr=1,shpc=on,addr=2 -device virtio-serial-pci,disable-modern=true,id=serial0 -device virtconsole,chardev=charconsole0,id=console0 -chardev socket,id=charconsole0,path=/run/vc/vm/023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f/console.sock,server,nowait -device nvdimm,id=nv0,memdev=mem0 -object memory-backend-file,id=mem0,mem-path=/usr/share/kata-containers/kata-containers-image_clearlinux_1.3.0_agent_042c3ebd71c.img,size=536870912 -device virtio-scsi-pci,id=scsi0,disable-modern=true -object rng-random,id=rng0,filename=/dev/urandom -device virtio-rng,rng=rng0 -device virtserialport,chardev=charch0,id=channel0,name=agent.channel.0 -chardev socket,id=charch0,path=/run/vc/vm/023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f/kata.sock,server,nowait -device virtio-9p-pci,disable-modern=true,fsdev=extra-9p-kataShared,mount_tag=kataShared -fsdev local,id=extra-9p-kataShared,path=/run/kata-containers/shared/sandboxes/023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f,security_model=none -netdev tap,id=network-0,vhost=on,vhostfds=3,fds=4 -device driver=virtio-net-pci,netdev=network-0,mac=9e:c1:3c:95:e2:5f,disable-modern=true,mq=on,vectors=4 -global kvm-pit.lost_tick_policy=discard -vga none -no-user-config -nodefaults -nographic -daemonize -kernel /usr/share/kata-containers/vmlinuz- -append tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 iommu=off cryptomgr.notests net.ifnames=0 pci=lastbus=0 root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro rw rootfstype=ext4 quiet systemd.show_status=false panic=1 nr_cpus=4 init=/usr/lib/systemd/systemd systemd.unit=kata-containers.target systemd.mask=systemd-networkd.service systemd.mask=systemd-networkd.socket -smp 1,cores=1,threads=1,sockets=1,maxcpus=4
root      2192  2172  0 08:19 ?        00:00:00 /usr/libexec/kata-containers/kata-proxy -listen-socket unix:///run/vc/sbs/023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f/proxy.sock -mux-socket /run/vc/vm/023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f/kata.sock -sandbox 023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f
root      2206  2172  0 08:19 pts/1    00:00:00 /usr/libexec/kata-containers/kata-shim -agent unix:///run/vc/sbs/023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f/proxy.sock -container 023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f -exec-id 023baa97456d4cf2eefd3619f81c557adb19cd3226fa29106608fe73e7b2843f -terminal

Here we have podman’s conmon, Kata’s kata-proxy and kata-shim, and… a QEMU instance!

Yes, this container is running in a fully-fledged VM, which started almost instantly. In fact, on my test machine (which is a VM, so I’m using nested virtualization), starting a container with runc (the standard OCI runtime) takes about 1.3 seconds, while doing it with Kata takes 3.2 seconds:

[slp@kata ~]$ time sudo podman run -ti --rm fedora /bin/false

real	0m3.243s
user	0m0.193s
sys	0m0.300s
[slp@kata ~]$ sudo vi /etc/containers/libpod.conf 
(comment out the kata-runtime line)
[slp@kata ~]$ time sudo podman run -ti --rm fedora /bin/false

real	0m1.355s
user	0m0.238s
sys	0m0.368s

Final remarks

While it still needs to evolve a bit, Kata Containers is a promising technology combining container’s flexibility with VM’s isolation, which can be very interesting specially for running untrusted workloads, or for NFV (thanks to the possibility of using PCI passthru and SRIOV).

If you found this post interesting, please consider dropping me a line on Mastodon (@slp@mstdn.io) or Twitter (@slp1605). If I get some positive feedback, I’ll write a part 2, talking about Kata’s inner workings.