Running MicroVMs in Proxmox VE, the Easy Way
taoofmac.com
Running MicroVMs in Proxmox VE, the Easy Way
1–10 of 52 posts
Re: Running MicroVMs in Proxmox VE, the Easy Way
#2I 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.
Re: Running MicroVMs in Proxmox VE, the Easy Way
#3[flagged]
Re: Running MicroVMs in Proxmox VE, the Easy Way
#4Tangentially, in theory, k3s + kubevirt + microvms sounds like the optimal combination for lightweight but isolated deployment.
Does anyone have experience with that?
Re: Running MicroVMs in Proxmox VE, the Easy Way
#5FWWI, 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.
Re: Running MicroVMs in Proxmox VE, the Easy Way
#6Tangentially, 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.
Re: Running MicroVMs in Proxmox VE, the Easy Way
#7Wow 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.
Re: Running MicroVMs in Proxmox VE, the Easy Way
#8This 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.
Re: Running MicroVMs in Proxmox VE, the Easy Way
#9I 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-...
Re: Running MicroVMs in Proxmox VE, the Easy Way
#10One 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.