HN Debrief

Running MicroVMs in Proxmox VE, the Easy Way

  • Infrastructure
  • Open Source
  • Developer Tools
  • Virtualization

The post is a hands-on write-up for running MicroVMs inside Proxmox VE by patching Proxmox to expose QEMU’s minimal `microvm` machine type. The pitch is simple. Keep Proxmox’s cluster and UI, but swap in a much smaller virtual hardware model so boot is faster, legacy emulation disappears, and isolation stays stronger than containers. That makes it attractive for coding agents, disposable sandboxes, and other short-lived jobs where a normal VM spends too much time pretending to be a full PC before it does useful work.

If you already run Proxmox, this points to a plausible path for agent sandboxes and short-lived workloads, but only if first-class support lands upstream. For now, treat patched MicroVM setups as promising lab infrastructure and put most of your evaluation effort into control-plane automation, guest startup trimming, and device support rather than raw hypervisor speed.

Discussion mood

Positive about the idea and impressed by fitting MicroVMs into Proxmox, but cautious about production use because the current approach depends on patching internals, still leaves a lot of startup work in the guest and control plane, and lacks mature GPU and automation support.

Key insights

  1. 01

    Useful latency is not kernel boot

    For agent and sandbox use, the win is only real when the whole path is fast enough to use immediately. NixOS users reported userspace init dominating startup even when the MicroVM itself launches quickly, and others pointed out that clone time, network setup, guest-agent readiness, and shell or exec availability are what determine whether the system feels instant.

    Benchmark end-to-end time to first command, not just VM boot. If you care about bursty workloads, spend as much effort on guest image minimization, snapshot strategy, and transport choices like AF_VSOCK as on the VMM itself.

      Attribution:
    • wereHamster #1
    • alexellisuk #1
    • touisteur #1
  2. 02

    libkrun is the other serious path

    A lot of the interesting work is happening outside Proxmox patches. `libkrun` and `krun` give you MicroVM isolation through container-oriented tooling, and `smolvm` was called out as an open source implementation that runs locally across Linux, macOS, and WSL. That shifts the framing from “how do I squeeze MicroVMs into my hypervisor” to “do I want VM isolation exposed as a programmable runtime primitive.”

    If your goal is developer sandboxes or isolated task execution, compare Proxmox-based integration against `libkrun` style runtimes before you commit. The right control surface may be a container runtime or SDK, not a traditional VM manager.

      Attribution:
    • apitman #1
    • binsquare #1
    • tobwen #1
    • sureglymop #1
  3. 03

    CUDA is still the ugly blocker

    GPU support remains the sharpest gap between “cool demo” and useful platform. `virtio-gpu` plus Venus can cover some Vulkan workloads, but commenters still need CUDA without handing the whole GPU to the guest through VFIO, which prevents easy host sharing and raises operational pain. One commenter suggested NVIDIA vGPU based CUDA may be feasible, but only as an early lead, not a solved path.

    Do not assume MicroVMs are ready for GPU-heavy workloads just because CPU-only sandboxes look good. If your roadmap includes ML inference, video pipelines, or mixed host and guest GPU usage, validate device sharing early.

      Attribution:
    • apitman #1
    • binsquare #1
  4. 04

    Proxmox automation is the bigger tax

    Operators already using Proxmox at scale said the steep part is not basic virtualization. It is automating templates, cluster placement, and permissions cleanly. Terraform was described as a poor fit because Proxmox API behavior can be awkward for strict state management, while Ansible works better but still leaves template workflows painful and AuthZ quirks easy to trip over.

    If you plan to build a MicroVM platform on Proxmox, prototype the automation first. Prove image lifecycle, placement, and credentials before you optimize boot times.

      Attribution:
    • INTPenis #1
  5. 05

    Proxmox itself did not see the payoff yet

    A Proxmox contributor said they benchmarked MicroVMs in 2020 and did not think the maintenance burden was worth it at the time. The same comment says the tradeoff may have changed now because dynamic load balancing, affinity rules, and upcoming orchestration work make small fast VMs more useful than they were a few years ago.

    Read this as a timing story, not just a technical one. The case for MicroVM support gets stronger when your scheduler and cluster features can actually exploit short-lived isolated workloads.

      Attribution:
    • tlamponi #1

Against the grain

  1. 01

    Long-lived VMs do not need this

    For homelab and server workloads that boot rarely, ordinary KVM guests already deliver near-native performance once they are up. In that setup, shaving GRUB time and legacy device probing is a neat benchmark trick, not a meaningful operating improvement.

    Only chase MicroVMs if startup churn is part of your workload profile. If your machines stay up for weeks or months, put your time into sizing, density, and management instead.

      Attribution:
    • FireBeyond #1
  2. 02

    SaaS control planes are a bad fit

    Comments about SlicerVM pushed back on paying subscription pricing to run MicroVMs on your own hardware. The objection was not only cost fatigue. It was also trust and risk. If the technical upside over Proxmox or open tools is unclear, teams would rather own the stack than add another vendor-shaped dependency around a low-level primitive.

    Expect buyers in this category to prefer open components or boring self-hosted control planes. If you are evaluating vendors here, demand a clear operational advantage over stitching together Firecracker, Proxmox, or `libkrun` yourself.

      Attribution:
    • traceroute66 #1
    • windexh8er #1

In plain english

AF_VSOCK ↩
A socket mechanism for communication between a host and virtual machines without using normal IP networking.
Ansible ↩
An automation tool used to configure machines and orchestrate operational tasks over SSH or APIs.
AuthZ ↩
Authorization, the part of an access system that decides what an authenticated user or token is allowed to do.
CUDA ↩
Compute Unified Device Architecture, Nvidia’s software platform for running general-purpose computation on its GPUs.
Firecracker ↩
A virtualization monitor designed by Amazon for running large numbers of secure lightweight MicroVMs.
GPU ↩
Graphics Processing Unit, a processor often used for graphics, video, and machine learning workloads.
GRUB ↩
GNU GRand Unified Bootloader, a common Linux bootloader that starts the operating system.
krun ↩
An OCI-compatible runtime that uses MicroVMs under the hood instead of ordinary containers.
KVM ↩
Kernel-based Virtual Machine, the Linux virtualization feature that lets the kernel act as a hypervisor.
libkrun ↩
A library for running workloads inside lightweight MicroVMs, often used to add VM isolation to container-style workflows.
MicroVM ↩
A very small virtual machine that removes most emulated hardware to boot faster and reduce overhead while keeping VM-style isolation.
NixOS ↩
A Linux distribution built around declarative system configuration and reproducible package management.
Proxmox VE ↩
An open source virtualization platform for managing virtual machines, containers, clustering, and storage.
QEMU ↩
A widely used open source machine emulator and virtualizer that can run many kinds of virtual hardware.
Terraform ↩
An infrastructure-as-code tool that manages resources through declarative configuration and tracked state.
Venus ↩
A virtualization protocol and implementation for exposing Vulkan graphics APIs to guests through virtio-gpu.
VFIO ↩
Virtual Function I/O, a Linux framework used to pass hardware devices directly through to virtual machines.
virtio-gpu ↩
A virtual GPU device standard used by virtual machines to access graphics functionality efficiently.
Vulkan ↩
A low-level graphics and compute API used by applications that need direct GPU access.
WSL ↩
Windows Subsystem for Linux, a way to run Linux user environments on Windows.

Reference links

MicroVM runtimes and tools

GPU virtualization references

Proxmox and KVM operations

Developer tooling around Proxmox

  • cursor-proxmox-mcp
    Linked as a tool to let coding assistants spin up Proxmox VMs with chosen specs.