RunCVM: An open-source Docker runtime for launching container images in VMs

RunCVM (Run Container Virtual Machine) is an experimental open-source Docker container runtime for Linux, that makes launching containerised workloads in virtual machines (VMs) as easy as launching them in containers, using docker run, e.g.:

Launch nginx VM publishing VM port 80 on host port 8080:

`docker run --runtime=runcvm --name nginx1 --rm -p 8080:80 nginx`

Launch an interactive terminal on an Ubuntu VM:

`docker run --runtime=runcvm --name ubuntu1 --rm -it ubuntu`

RunCVM runs standard container workloads (like nginx or mariadb) as well as system workloads (like Systemd, Docker, stock or bespoke Linux kernels, even OpenWrt).

RunCVM:

   - Provides stronger workload isolation than standard containers.
   - Allows running and testing applications like Systemd, Docker, and Kubernetes that won't easily run (or run securely) in standard containers.
   - Supports tools and apps like iptables, ipvsadm or openvpn, or Docker Swarm ingress routing, that require a running kernel (or a kernel version or modules not available on the host).
   - Supports both stock kernels of major Linux distributions and custom kernels.
   - Makes it easy to create arrays of networked VMs for testing complex multi-machine setups like Docker Swarms.
   - Supports many standard `docker run` options including custom docker networks with docker internal DNS (`--network`), multiple network interfaces (with `docker network connect`), published ports (`-p`), plus volume, tmpfs and bind mounts
   - Uses virtiofs for fast booting and supports prepopulated KVM virtual disks on almost any regular disk filepath (except /) for improved I/O performance.
   - Can be easily customised to emulate specific hardware e.g. disks, network cards, and graphics displays.
   - Useful as a playground for some bare-metal training and testing use-cases.

BACKGROUND:

RunCVM was born out of difficulties experienced using the Docker and Podman CLIs to launch Kata Containers v2, and a belief that launching containerised workloads in VMs using Docker needn't be so complicated.

Like Kata, RunCVM aims to be a secure container runtime with lightweight virtual machines that feel and perform like containers, but provide stronger workload isolation using hardware virtualisation technology.

However, while Kata aims to launch standard container images inside a restricted-privileges namespace inside a VM running a single fixed and heavily customised kernel and Linux distribution optimised for this purpose, RunCVM intentionally aims to launch container or VM images as the VM's root filesystem using stock or bespoke Linux kernels, the upshot being RunCVM's can run VM workloads that Kata's security and kernel model would explicitly prevent.

FURTHER DETAILS:

   - Uses a lightweight 'wrapper-runtime' technology that subverts the behaviour of the standard container runtime runc to cause a VM to be launched within the container (making its code footprint and external dependencies extremely small, and its internals extremely simple and easy to understand and tailor for specific purposes).
   - Highly portable among Linux distributions and development platforms providing KVM. Can be installed on Google Cloud or on GitHub Codespaces.
   - Experimental support for podman run.
   - RunCVM can even be used to launch VMs nested inside a RunCVM VM - i.e. an 'inner' RunCVM Container/VM guest can be launched by Docker running within an 'outer' RunCVM Container/VM guest (assuming the host supports nested VMs) - in this sense, RunCVM is 'reentrant'.

RunCVM was first released under the Apache license in April 2023 and its latest release, v1.4.0, is the culmination of an extensive amount of R&D over roughly two years.

Questions, suggestions and feedback are most welcome.

Not OP and not at all related to the project, but I imagine in production you would just replace the container runtime of your Kubernetes/Nomad/Swarm/homemade orchestrator, and run Docker container as usual (but each one is a separate VM). The advantages would be that you have actual isolation between the containers, so it's great for higher security contexts (e.g. banks) or multi tenant setups.

Although it's currently Linux-only, it seems this would be useful on Mac/Windows, as they already jury-rig containers within a VM and this would override that by default.

Unless I'm missing something (quite likely) ?

Very cool! It seems like this could solve docker-in-docker use cases for things like CI, perhaps? I would love to see benchmarks of mem/cpu footprint vs. the same workload in raw docker.

Podman supports this since quite a while with the krun variant of the crun runtime (https://github.com/containers/crun/blob/main/krun.1), provided in Fedora by the "crun-krun" package.

Just add "--runtime=krun" to your podman command line along the other arguments and you'll get the container running inside a VM powered by libkrun.