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…
This should be changed into show HN?
RunCVM: An open-source Docker runtime for launching container images in VMs
11–14 of 14 posts
Re: RunCVM: An open-source Docker runtime for launching container images in VMs
#12Earlier quoted context omitted.
Looks cool and I understand what it does. Can you explain the production use case for this solution? It's not clear to me how this would be used in real life.
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.
Re: RunCVM: An open-source Docker runtime for launching container images in VMs
#13Very 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.
But for a CI application that requires a running kernel, for example integration testing of an actual kernel module, or an application that uses kernel modules (like a VPN or firewall application) RunCVM could be very useful.
Think also about integration testing that requires hardware, such as a display.
In these cases, RunCVM can provide a way to encapsulate that VM and make it trivial to run the integration tests.
I don't have benchmarks to hand yet, but it's true that most applications will run more slowly (and require overall more host memory) in a VM compared to a plain container.
Re: RunCVM: An open-source Docker runtime for launching container images in VMs
#14Lots of cool hybrid container/VM ideas are being developed! Bootable Container Images are a standard for launching VMs from OCI images: https://containers.github.io/bootable/ crun-vm ( https://github.com/containers/crun-vm ) is similar to RunCVM in that it can launch container images (or VM disk images) in VMs. It's an OCI runtime so it fits into the podman, Docker, or Kubernetes model. krunvm ( https://github.com/co…
=== 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.