Proxmox VE 的虛擬化選單長年只有兩條路：要密度就用 LXC，要硬體隔離就拉 KVM。LXC 共用主機核心，開機快、記憶體基線低，但任何踩到 namespace 邊界的攻擊面都會直接打到 host；KVM 是一臺完整虛擬機，硬體隔離乾淨俐落，代價是每臺都得跑完一輪 SeaBIOS 或 OVMF，開機算下來十幾秒起跳，閒置記憶體基線也不會低於幾十 MB。
Firecracker 從 2018 年起就證明過硬體隔離可以做到容器級別的開機時間，但它是 AWS 為 Lambda 量身打造的另一套 VMM，跟 Proxmox 完全平行，要嘛另起一臺機器跑 firecracker-containerd，要嘛把 Proxmox 那套熟悉的 web UI、HA、備份、儲存後端全部丟掉。
pve-microvm 這個 2026 年 6 月剛跳到 v0.3.14 的 Debian 套件選了第三條路。QEMU 本來就內建一個叫 microvm 的最小化機型，只是 Proxmox 從來沒把這顆按鈕接出來。把它接出來之後，OCI 容器映像、Firecracker rootfs、unikernel、SmolBSD 全部可以從 Proxmox 既有的介面拉起來，開機時間落在 31 毫秒到 8 秒之間，看 guest 是哪種發行版。
QEMU microvm 機型不是新東西，是沒人按過按鈕
microvm 機型在 QEMU 4.0（2019 年）就進主線了，靈感直接來自 Firecracker。設計哲學是把所有「為了讓一臺實體 PC 開機」而必須存在的東西全部砍掉。
被砍掉的清單包含：PCI 匯流排、ACPI 表、設備熱插拔、跨 QEMU 版本的 live migration。換來的是一條極短的開機路徑——沒有 BIOS 啟動掃描，沒有 ACPI 表解析，guest 核心直接從 host 端載入，搭配 qboot 這顆精簡到不到 4KB 的 BIOS 替代品。
剩下的設備清單也精簡得有點刻意：ISA bus 加幾個可選的 legacy 元件（PIC、PIT、RTC）、一個序列埠、LAPIC 與 IOAPIC、kvmclock、最多八個 virtio-mmio 通道。virtio-mmio 而不是 virtio-pci 是這套架構的關鍵——沒有 PCI bus，就用 memory-mapped IO 把 virtio 接出來，省下整顆 PCI root complex 的初始化成本。
問題是 Proxmox 預設拉起 VM 的時候會強制注入一條 PCI bridge，這在 microvm 機型下會直接讓 QEMU 啟動失敗。pve-microvm 的核心工作就是 patch qemu-server 那段邏輯，讓選擇 microvm 機型的 VM 不再被塞 PCI bridge。整套修改是可逆的——移除 Debian 套件會把原檔還原回去，這對於要不要長期相信這個第三方套件的判斷上很重要。
31 毫秒到 8 秒：開機時間差在哪裡
實測數字是這個套件最直白的賣點：SmolBSD 開機 31 毫秒，Alpine 大約 200 毫秒，完整 Debian 帶 Docker 跟 QEMU agent 在 8 秒內就緒，重複開機穩定在 300 毫秒附近。
數字落差來自於 guest 系統各自要做的事。SmolBSD 是 NetBSD 為 µVM 場景重寫的最小化發行版，核心進入使用者空間幾乎沒有任何系統服務要拉；Alpine 與 Debian 的差距則主要在 systemd 與 udev 的初始化時間。
對比一下標準 KVM VM：同一份 Debian 映像在 Proxmox 預設機型下開機要 25 到 40 秒，其中至少 5 秒花在 OVMF 韌體初始化、ACPI 表建立、PCI bus 掃描這些「實體 PC 模擬」的儀式上。對於只是要跑一支爬蟲、一個 cron job、一個臨時的 build worker，這些時間全是純粹的浪費。
記憶體基線的差距也夠明顯。QEMU 標準 PC 機型光是維護 ACPI 表跟 PCI 設備拓樸就要吃掉幾 MB，加上 OVMF 韌體常駐記憶體少說 64MB；microvm 機型整個 QEMU process 開起來、guest 核心都還沒載入時，RSS 大約落在 10MB 上下。這個基線差距決定了單臺實體機能塞多少個 µVM——同樣 32GB 記憶體的節點，標準 KVM VM 撐死兩三百個，µVM 可以推到一千個以上。
不是要取代 LXC，是補上 LXC 與 KVM 之間的夾層
把 microvm 直接拿來跟 LXC 比通常會誤判定位。LXC 在 Proxmox 上是 cgroups 加 namespaces，開機本質上是 fork 一棵新的 process tree，毫秒級反應，記憶體共享 page cache，密度可以壓到單臺實體機跑幾百個。microvm 在這個維度怎麼比都比不過——硬體虛擬化的本錢就在那邊。
值得比較的是隔離強度。LXC 把 host 核心暴露給 guest，過去幾年 kernel CVE 跑出來的 namespace 逃逸案例不算少；任何一個 LXC container 拿到 root，host 端的攻擊面瞬間擴大。microvm 走的是 KVM，guest 跑在自己的 ring 0、看不到 host 核心結構，攻擊面收窄到 KVM ioctl 介面與 virtio 後端，這跟標準 KVM VM 是同一個量級。
換句話說，這套東西要解決的是「想要 KVM 等級的隔離，但不能接受標準 KVM 的開機時間與記憶體基線」這個夾層。最常見的場景是 CI/CD 的 build worker、爬蟲池、邊緣函式執行器、honeypot——這些工作負載特徵都是大量短生命週期、彼此互不信任、單一任務不會跑很久。
LXC 在這些場景的隔離強度不夠，標準 KVM 又會讓 cold start 變成瓶頸。Firecracker 補上了這塊空白，但代價是要另建一套管理平面。pve-microvm 的意義在於這個夾層可以直接坐在現有的 Proxmox 上，HA、備份、儲存後端、ZFS 快照、Ceph、NFS 全套照用。
套件怎麼裝、第一臺 µVM 怎麼拉
部署步驟在 Proxmox VE 8.x 上已經簡化到三行：
1 | wget https://github.com/rcarmo/pve-microvm/releases/latest/download/pve-microvm.deb |
裝完之後 Proxmox web UI 的 Create VM 對話框會多出一個 Machine type 下拉選項 microvm，旁邊還會跑出一顆 Create µVM 按鈕，介面上可以直接貼 Docker Hub 或 GHCR 的 OCI 映像名稱，後端會自動拉下來轉成可開機的 rootfs。
CLI 端則延續 qm 指令的習慣：
1 | qm create 9000 --name alpine-uvm \ |
關鍵差別是要明確指定 --kernel：microvm 機型不跑 BIOS、不從磁碟尋找 bootloader，host 端必須直接提供 guest 核心。SmolBSD、Alpine 都有針對 µVM 場景預編譯好的 kernel image 可以拉，Debian 跟 Ubuntu 則可以從 linux-image-*-cloud-amd64 套件取出標準雲端核心。
網路預設關閉是個合理的安全預設值，但要記得手動加 --net0 virtio=... 才會有 NIC。virtio-mmio 在 Linux 5.x 之後支援得很完整，OpenWrt、OPNsense、9Front 也都能正常上線。
還沒就位的功能要先看清楚
v0.3.14 雖然累積了五十個功能，但有幾個缺口在規劃 production 用途前必須確認。
GPU passthrough 完全不支援。microvm 機型沒有 PCI bus，VFIO passthrough 這條路本質上行不通。任何牽涉 GPU 加速的工作負載——轉碼、推論、ML training——都必須走回標準 KVM。
AArch64 guest 還沒做。目前只支援 x86_64，在 Ampere Altra 或 Raspberry Pi 上跑 Proxmox 然後想開 µVM 這條路暫時走不通。
跨 QEMU 版本的 live migration 是 microvm 機型本身的限制，不是套件的問題。Proxmox 升級到新版 QEMU 之後既有的 µVM 必須關機才能搬遷。套件提供「offline migration 兩秒完成」的優化，對於短生命週期工作負載這個取捨可以接受。
還有套件作者自己在 README 明寫的那句「highly experimental, not tested in production」。這套東西 patch 的是 qemu-server 的內部行為，Proxmox 官方任何版本升級都可能讓套件需要重新調整。合理的部署路徑是先在獨立的測試節點上跑，把工作負載限縮在「掛了重開就好」的場景。
接下來怎麼走
Proxmox 官方對 microvm 機型的態度從 2020 年的支援論壇討論串看下來一直是「有興趣但優先順序不高」。pve-microvm 把概念驗證做到 v0.3.14 並且功能清單夠完整，理論上會推著官方加速整合——QEMU 那邊的相依套件本來就在 Proxmox 的 build chain 裡，剩下的主要是 qemu-server 那層邏輯要不要原生支援 microvm 機型。
µVM 這個夾層的價值會隨著「短生命週期、互不信任、需要硬體隔離」的工作負載成長而擴大。AI agent 的沙箱執行、CI runner、無伺服器函式，全部都吃這個架構。pve-microvm 目前是把這條路徑接進現有 Proxmox 叢集最短的方式。
如果要在臺灣的機房內實驗 Proxmox 加 microvm 機型的組合，建議挑配備新一代 Intel Xeon 與 NVMe SSD 的方案——KVM 在新世代 CPU 上的 nested virtualization 與虛擬化指令效能差距比想像中明顯，NVMe 的 IOPS 也直接決定 µVM 的 rootfs 解壓速度。NCSE Network 的臺灣是方電訊機房 VPS 採 Intel Gold CPU 與 NVMe SSD，在這兩項硬體規格上都做了規劃，有需求的讀者可以到 ncse.tw 看看目前的方案配置。
