- 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.
- 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'.
=== crun-vm ===
Although crun-vm states it let's you "run VMs as easily as you run containers" AFAIK it requires specialised VM images or bootable containers images be created first. By contrast, RunCVM aims to boot any standard OCI container image (as well as specialised container images) and this may make the learning curve and migration path to RunCVM easier for some applications.
=== krunvm ===
krunvm appears much more similar to RunCVM in its approach. However, RunCVM deploys each VM inside a standard runc container, providing an additional layer of isolation and encapsulation on the host (and I'm not sure krunvm does this). Remove the standard container using `docker rm` and you tear down the VM too.
And while krunvm states it "supports mounting additional local directories into the microVM and exposing ports from the guest to the host (and the networks connected to it)" RunCVM does this too, but also makes it trivial to transparently create, prepopulate and mount virtual VM disks within the VM where additional read/write performance is needed (compared to virtiofs that both RunCVM and krunvm use for booting the VM's rootfs).
Both RunCVM and krunvm appear to provide seamless networking experience.
RunCVM gives you full control over the choice of kernel the VM boots, so it can boot what are essentially stock alpine, ubuntu, debian, or oracle kernels. It can even boot an OpenWRT kernel. Or any custom kernel (with minimal config requirements). AFAIK kruncvm does not offer this.