Posted by zdw 2 days ago
Oh, and mailing lists are a bliss to use compared to (barely loading) forges, at least to me and especially with public inbox and tools like b4 and lei for patch review, management and applying. For the sending side it's basically a git send-email command to pve-devel@list.proxmox.com, see https://git-send-email.io for a simple tutorial.
But when there's the discussion of the amount of time Qemu spends "in grub" and "probing legacy devices", maybe my use case is different, but my VMs aren't constantly being rebooted and when the VM is up it is near native speed so...
We’ve been on a similar journey, but came at it from the opposite direction. We started SlicerVM in 2022 after seeing how slow Multipass felt when launching more than one Linux VM, even though it is relatively lean. Tearing them down was slower.. we made it seconds either way for a 30 node cluster and kept it internal until August last year.
With Slicer, microVMs are the native primitive: API launch, guest-agent exec/shell/cp/forward workflows, isolated networking, and agent sandboxes are built into the control plane.
That was not our first use case. Back then we were standing up Kubernetes clusters quickly for OpenFaaS e2e testing and customer scale-out support across multiple machines. The agent/sandbox workflows came naturally after that.
We do see people come over from Proxmox when they want something more directly driven from code, especially with a deeper guest-agent model: exec, file copy, port forwarding, fs watches, etc. When you string it all together it becomes very powerful and what we've gradually dogfooded for our code review bot that started out by using SSH/SFTP to completely native SDK (Go/TS).
One thing I’d separate in the benchmarks is in-guest boot time vs. actual time-to-interactive/useful. For agent-style workloads, the number that tends to matter is: API request made -> VM created/cloned -> network policy applied -> guest agent reachable -> exec/shell/cp/forward works. Snapshot cloning, network device setup, and control-plane readiness all show up there.
TTI can also be moved around depending on tradeoffs: no real init system, snapshot resume, CrosVM-style lower-level primitives, or a VMM built for one narrow job. We use systemd in the guest, so we’re intentionally carrying some weight there.
I also liked that you retained module support for Docker. Supporting Docker, Kubernetes-ish workloads, and eBPF tends to add a lot of useful weight back in.
There’s room for several tools here. The space is moving quickly, and I’m looking forward to seeing which approaches consolidate.
If folks are looking to scratch that microVM, or programmable / bash / agent / SDK driven primitive, you're welcome to check us out and join the Discord.
Shame you did not mention once in your long post that you are based on Firecracker, because I'm sure I'm not the first who was about to post "why is this better than Firecracker".
Also it is a shame you've adopted the subscription billing model instead of allowing people to buy perpetual licenses.
I dislike the subscription model in a pure sense, but also I dislike the "but its 'only' $x a month" argument oft-used by developers. Sure, in theory that's the case. But like everyone else in the world, I also have $x a month of other monthly expenses in my life, and I simply do not need or want N+1 software subscriptions. It all adds up.
The same applies to business environments, except the cost becomes even more exponential because you have (X-employees * N-subscriptions)/month.
The killer feature still missing from microVMs for me is the ability to enable CUDA support without passing through the entire GPU. vfio is just too much of a pain and too limiting. Sometimes I want to use my GPU on the host. Vulkan works fairly well with virtio-gpu and Venus, but I need CUDA. Venus is also still missing some important things like accelerated video encoding.
back when I used to use cursor I build this mcp but it should work for codex or claude
it lets me easily spin up vms with specs
its tough to create boxes now due to ram prices but got mine at a great time when it was very cheap; i just wish i had bought more then
I’ve also been wanting a setup like this but don’t have to courage to use pve-microvm. First class microVM support would be very nice.
Given some similarities, I’d like to briefly mention `krun` here. Although it’s an OCI-compatible container runtime, it uses MicroVMs with a similar approach. Perhaps we can exchange ideas here? I recall that GPU passthrough is also a recurring topic there.
I'm also a bit confused on how to use libkrun. It seems to be implemented in rust but provide a C API. Can it be used in rust projects?
Also, it made me curious if it would be possible to create a Linux distribution where every process runs in a microvm.
I would love to use this in production, but dont know how much it can break things. Proxmox should just implement this in mainline.