FWWI, we did evaluate and benchmark microVMs back in 2020. Back then it was not really seen worth it the maintenance cost compared to what it brought to the table, but it makes sense to re-evaluate that again soonish; with native dynamic load balancing and affinity rules (and further orchestration improvements being lined up) they might be better leveraged today.
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.
Yeah, I love this from a geek appeal and I have a beefy home lab (Dual Xeon Silver 4116 with 384GB, and 12TB of RAID10 SSD connected via 10gig), but being a homelab I want to eke out all my performance so I keep looking at LXC on my Proxmox box versus the optimization of VMs (does this machine really need 8GB or 6? Or 5?).
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...
I think in most scenarios you don't need to worry so much about kvm ram use, since it looks static but actually it's not and you can over-commit [1]. And of course disk allocation can be dynamic as well. I prefer a lot more security for a bit less flexibility. I am not as ram rich as you are, and still every time I think of my few LXCs, my main thought is 'why did I do that?'.
My favorite microVM discovery recently has been tools built around libkrun. See smolvm[0].
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.
I was just looking into microvm (via microvm.nix) to isolate coding agents. While the machine starts quickly, as in the article, the userspace (nixos) takes much longer. I'd probably need to spend some time to strip the system of all non-essential services. I also briefly considered running the agent harness as PID 0. That would speed things up, but also mean a lot of responsibility on my end. My biggest struggle is how to imperatively manage agent microvms on nixos. microvm.nix isn't really well suited for that task. For longer-running VMs, that I can manage via my nixos config, I'm quite happy with microvm.nix. Related article by Michael Stapelberg: https://michael.stapelberg.ch/posts/2026-02-01-coding-agent-...
This is clever work, especially given that Proxmox is already a very viable VMware replacement and wasn’t originally designed around microVMs as the primary abstraction. I’m glad this is working well for you.
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.
Hey Alex! Just wanted to say I came across Slicer three or so months ago, researching automatic provisioning for RPis (and other devices in the homelab). It piqued my interest, as I was also researching solutions for partitioning and distributing workloads. I hope to give Slicer a go within the next quarter, however I'm still getting to grips with the fundamentals of distributed computing. Either way, it's interesting work.
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.
Yeah. I agree, I saw the SaaS-style pricing for running on my own infra and couldn't see any reason why I'd want this. I also don't see the technical upside to SlicerVM. It feels very risky given I've never heard of anyone actually running this in production. I think I'd take my chances with Proxmox plus microVM add-ons first.
Author of a free open source alternative to slicer, based on a fork of libkrun (not firecracker based) that runs locally across wsl, macOS, and Linux natively.
Very interesting work on microvms there. I would add that removing any kind of storage or file-system interaction is reachable for even faster bringup and removing the risk of attacks needing some form of persistence.
Also replacing network access with af-vsock is actually interesting if you want to simplify bring-up. SSH does some magic with vsocks these days too.
anyway, the author posted the sources on github and got in touch with the proxmox people, maybe they want to absorb that into the product (which would be very very cool).
I'm not the person you replied to, but I came from using VMware products for 12 years, to using Proxmox this last 1.5 years.
These are my impressions.
First of all it's a very competent product, mainly thanks to Ceph making it HCI. Without Ceph, I'm not sure what we would do.
It's as effective as you design it, make sure to separate storage and cluster traffic to ensure robustness, and speed. Make sure to use at least 10GbE switch for storage, for fast migrations.
And managing ceph is very important, basically boils down to 1) never let it run out of space, and 2) the more devices you have the easier it is to manage.
Automating against Proxmox definitely is the biggest pain point, and this needs the most work done.
I've spent countless hours, pre-AI, building our automation setup using both Terraform and Ansible. I sort of wish I had tried AI earlier because it does make things easier.
Some things like automating the creation of templates will forever be a complex procedure in Ansible. And I abandoned Terraform completely because the API was too unpredictable for Terraforms strict state, Ansible was a much better fit.
Their AuthZ takes some getting used to, the fact that if you select "Privilege Separation" it countes the user's permissions AND the token permissions, and the token permissions must always be lower than the users.
Templates existing on one node, but taking a unique VM ID across the cluster is also a bit confusing. It means in practice we're always deploying VMs on the same node, before migrating them somewhere else.
Thanks for the write-up, I like the integration in the Proxmox VE environment.
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.
Krun is neat! I use it as podman backend. What I'm missing though is a good writeup on how to use it to sandbox as safely as possible. Already kind of difficult to know best with podman due to the sheer number of command line options and possible customizations.
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.
Am I understanding the ballooning part right that this doesn't allocate all of the VM memory from the host until it's needed, and releases memory automatically when it's not needed anymore? So you can overprovision memory with multiple guests as long as the guests aren't using the memory at the same time?
One of my Proxmox hosts is glacially slow at running VMs. (Dell R520; I have a same-generation server that is fine at VMs, so not sure what the root cause is). I wonder if this would help performance.
Tangentially, in theory, k3s + kubevirt + microvms sounds like the optimal combination for lightweight but isolated deployment.
Does anyone have experience with that?
I'm curious if there's more than one way to achieve this.
Creating a single VM, with vm within vm (performance hit would be negligible for the orchestration work of agents), and it might offer some alternatives without having to customize Proxmox as much?
This is what I do for a few projects. One beefy (Debian) VM with the CPU type set to "host" (or something like that) to allow for nested virtualization. Running Firecracker inside that VM.
Just be careful with the virtualized file systems to not create write amplification issues.
FWWI, we did evaluate and benchmark microVMs back in 2020. Back then it was not really seen worth it the maintenance cost compared to what it brought to the table, but it makes sense to re-evaluate that again soonish; with native dynamic load balancing and affinity rules (and further orchestration improvements being lined up) they might be better leveraged today.
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.
I gotta ask but is Forgejo a barely loading forge? GitHub, GitLab being a pig sure but Forgejo seem pretty snappy.
Yeah, I love this from a geek appeal and I have a beefy home lab (Dual Xeon Silver 4116 with 384GB, and 12TB of RAID10 SSD connected via 10gig), but being a homelab I want to eke out all my performance so I keep looking at LXC on my Proxmox box versus the optimization of VMs (does this machine really need 8GB or 6? Or 5?).
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...
I think in most scenarios you don't need to worry so much about kvm ram use, since it looks static but actually it's not and you can over-commit [1]. And of course disk allocation can be dynamic as well. I prefer a lot more security for a bit less flexibility. I am not as ram rich as you are, and still every time I think of my few LXCs, my main thought is 'why did I do that?'.
[1] https://docs.redhat.com/en/documentation/red_hat_enterprise_...
My favorite microVM discovery recently has been tools built around libkrun. See smolvm[0].
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.
[0]: https://smolmachines.com/
author of smolmachines here,
CUDA support is possible based on a cursory dive. I'll keep you posted on it
ref: https://thevirtualhorizon.com/2024/05/31/how-to-configure-th...
I was just looking into microvm (via microvm.nix) to isolate coding agents. While the machine starts quickly, as in the article, the userspace (nixos) takes much longer. I'd probably need to spend some time to strip the system of all non-essential services. I also briefly considered running the agent harness as PID 0. That would speed things up, but also mean a lot of responsibility on my end. My biggest struggle is how to imperatively manage agent microvms on nixos. microvm.nix isn't really well suited for that task. For longer-running VMs, that I can manage via my nixos config, I'm quite happy with microvm.nix. Related article by Michael Stapelberg: https://michael.stapelberg.ch/posts/2026-02-01-coding-agent-...
This is clever work, especially given that Proxmox is already a very viable VMware replacement and wasn’t originally designed around microVMs as the primary abstraction. I’m glad this is working well for you.
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.
Hey Alex! Just wanted to say I came across Slicer three or so months ago, researching automatic provisioning for RPis (and other devices in the homelab). It piqued my interest, as I was also researching solutions for partitioning and distributing workloads. I hope to give Slicer a go within the next quarter, however I'm still getting to grips with the fundamentals of distributed computing. Either way, it's interesting work.
> We started SlicerVM ....
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.
Yeah. I agree, I saw the SaaS-style pricing for running on my own infra and couldn't see any reason why I'd want this. I also don't see the technical upside to SlicerVM. It feels very risky given I've never heard of anyone actually running this in production. I think I'd take my chances with Proxmox plus microVM add-ons first.
Author of a free open source alternative to slicer, based on a fork of libkrun (not firecracker based) that runs locally across wsl, macOS, and Linux natively.
https://github.com/smol-machines/smolvm
I noticed this when it was first announced on HN as well. Hoping to give it a try as well shortly.
Very interesting work on microvms there. I would add that removing any kind of storage or file-system interaction is reachable for even faster bringup and removing the risk of attacks needing some form of persistence.
Also replacing network access with af-vsock is actually interesting if you want to simplify bring-up. SSH does some magic with vsocks these days too.
< 300ms boot with HW isolation sounds very nice but the pve-daemon patching approach is risky and might break at every eye-blink.
it's the correct way to do it though.
anyway, the author posted the sources on github and got in touch with the proxmox people, maybe they want to absorb that into the product (which would be very very cool).
I see Proxmox blog post I upvote.
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.
Agreed !
proxmox has been great although it comes with a learning curve
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
https://github.com/agentify-sh/cursor-proxmox-mcp
Can you share more about the learning curve specifics you're referring to? Thanks.
I'm not the person you replied to, but I came from using VMware products for 12 years, to using Proxmox this last 1.5 years.
These are my impressions.
First of all it's a very competent product, mainly thanks to Ceph making it HCI. Without Ceph, I'm not sure what we would do.
It's as effective as you design it, make sure to separate storage and cluster traffic to ensure robustness, and speed. Make sure to use at least 10GbE switch for storage, for fast migrations.
And managing ceph is very important, basically boils down to 1) never let it run out of space, and 2) the more devices you have the easier it is to manage.
Automating against Proxmox definitely is the biggest pain point, and this needs the most work done.
I've spent countless hours, pre-AI, building our automation setup using both Terraform and Ansible. I sort of wish I had tried AI earlier because it does make things easier.
Some things like automating the creation of templates will forever be a complex procedure in Ansible. And I abandoned Terraform completely because the API was too unpredictable for Terraforms strict state, Ansible was a much better fit.
Their AuthZ takes some getting used to, the fact that if you select "Privilege Separation" it countes the user's permissions AND the token permissions, and the token permissions must always be lower than the users.
Templates existing on one node, but taking a unique VM ID across the cluster is also a bit confusing. It means in practice we're always deploying VMs on the same node, before migrating them somewhere else.
Thanks for the write-up, I like the integration in the Proxmox VE environment.
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.
https://github.com/containers/crun/blob/main/krun.1.md
Krun is neat! I use it as podman backend. What I'm missing though is a good writeup on how to use it to sandbox as safely as possible. Already kind of difficult to know best with podman due to the sheer number of command line options and possible customizations.
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.
Am I understanding the ballooning part right that this doesn't allocate all of the VM memory from the host until it's needed, and releases memory automatically when it's not needed anymore? So you can overprovision memory with multiple guests as long as the guests aren't using the memory at the same time?
Yes, it requires a daemon running inside the VM and can be finicky though.
Wow thats pretty cool. Even with plan9 images!
I would love to use this in production, but dont know how much it can break things. Proxmox should just implement this in mainline.
One of my Proxmox hosts is glacially slow at running VMs. (Dell R520; I have a same-generation server that is fine at VMs, so not sure what the root cause is). I wonder if this would help performance.
Not running a Proxmox system, would it be possible to setup something similar directly with QEMU?
Tangentially, in theory, k3s + kubevirt + microvms sounds like the optimal combination for lightweight but isolated deployment. Does anyone have experience with that?
KubeVirt only supports full QEMU. They have a long open issue about QEMU MicroVM support.
I think you might be looking for Kata Containers which is a CRI for running vmms like firecracker.
I'm curious if there's more than one way to achieve this.
Creating a single VM, with vm within vm (performance hit would be negligible for the orchestration work of agents), and it might offer some alternatives without having to customize Proxmox as much?
This is what I do for a few projects. One beefy (Debian) VM with the CPU type set to "host" (or something like that) to allow for nested virtualization. Running Firecracker inside that VM.
Just be careful with the virtualized file systems to not create write amplification issues.