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 for software provisioning, configuration management, and deployment.
authz ↩
Authorization, the process of deciding what an authenticated user or system is allowed to do.
CUDA ↩
Compute Unified Device Architecture, NVIDIA's platform for running general-purpose code on its GPUs.
Firecracker ↩
A lightweight virtualization technology for running micro virtual machines, originally developed by Amazon.
GPU ↩
Graphics Processing Unit, the processor that handles graphics and some parallel computing tasks.
grub ↩
GNU GRand Unified Bootloader, a widely used Linux boot loader.
krun ↩
An OCI-compatible runtime that uses MicroVMs under the hood instead of ordinary containers.
KVM ↩
Kernel-based Virtual Machine, a Linux virtualization technology for running virtual machines.
libkrun ↩
A lightweight virtual machine monitor library used to run Linux workloads with stronger isolation.
MicroVM ↩
A very lightweight virtual machine used to isolate workloads more strongly than containers while staying faster than traditional virtual machines.
NixOS ↩
A Linux distribution built around declarative system configuration, making environments reproducible and easy to roll back.
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 for running virtual machines.
Terraform ↩
An infrastructure-as-code tool that lets teams define and manage servers, networks, and other infrastructure with configuration files.
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 virtualized graphics device standard used by virtual machines to access graphics functionality efficiently.
Vulkan ↩
A low-level graphics and compute API used for high-performance work on GPUs.
WSL ↩
Windows Subsystem for Linux, a feature that lets Linux software run 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.