A container is not a sandbox: LXC containers share the Proxmox host’s kernel, so a kernel exploit inside one reaches the host (see Your Container Is Not a Sandbox). Full VMs isolate properly but boot slowly and cost more memory. MicroVMs sit in between: a real KVM guest with its own kernel, stripped of most emulated hardware so it starts fast and stays small.
Proxmox VE doesn’t manage microVMs itself. But QEMU, which every Proxmox node already runs, has a microvm machine type, and Rui Carmo’s pve-microvm package (background post) makes it a managed guest type in Proxmox.
The project’s own warning: pve-microvm is highly experimental. It patches
qemu-serverinternals and hasn’t been tested in production. The author states the patches are reversible by uninstalling the package. Try it on a test node, not on your main host.
What it gives you
From the README:
| LXC | microvm | Standard VM | |
|---|---|---|---|
| Isolation | Namespaces (shared kernel) | KVM, own kernel | KVM, own kernel |
| Boot time | ~50 ms | < 300 ms | 2–10 s |
| Attack surface | Host kernel | Minimal virtio devices | Emulated PC hardware |
- Guests created from OCI (container) images, so the familiar images become microVMs.
- Imports Firecracker rootfs images. It runs them on QEMU’s microvm machine, not on the Firecracker VMM.
- Normal Proxmox management: templates, cloning, backups, HA, a “Create µVM” button in the web UI, all storage types.
- Guests include Debian, Ubuntu, Alpine, Fedora and others, plus OpenWrt, OPNsense and some unikernels.
The author built it for semi-trusted workloads such as coding agents, which is a good homelab use too: anything you’d rather not run in an LXC container on your main host.
Quick start (from the README)
# Install the latest release .deb
curl -sLO $(curl -s https://api.github.com/repos/rcarmo/pve-microvm/releases/latest | grep browser_download_url | grep '.deb' | cut -d'"' -f4)
dpkg -i pve-microvm_*.deb
# Create a template from an OCI image
pve-microvm-template --image debian:trixie-slim
# Clone and boot
qm clone 9000 901 --name my-sandbox --full
qm start 901
qm terminal 901Read the project’s documentation for limitations and known issues before relying on it, and expect breakage with Proxmox updates while it patches internal files.
When to use what
- Trusted internal services: LXC is fine and the lightest option.
- Anything internet-facing or running untrusted code: a full VM today, or a microVM if you’re comfortable with an experimental tool.
- Short-lived sandboxes (testing unknown software, AI agents): this is where microVMs shine, since they boot in well under a second.
What’s Next
Now that you have a handle on running isolated workloads, it’s time to put them to work.
[discussion]
Comments are powered by Giscus — backed by GitHub Discussions. Sign in with GitHub to join the conversation.