在 Proxmox VE 裡讓 microVM 300 毫秒開機:pve-microvm 怎麼做到
Tao of Mac (taoofmac.com) · 2026-06-18
Rui Carmo 在自己四節點的 Proxmox VE homelab 上,寫了一個叫 pve-microvm 的 Debian 套件,把 QEMU 的 microvm machine type 變成 Proxmox 網頁介面可以直接管理的第一等 guest 類型。這篇 2026 年 6 月 18 日發表的文章記錄了他如何靠這套機制在自家叢集上跑出次秒開機、支援 21 種 guest OS 的輕量虛擬機,專案原始碼放在 GitHub rcarmo/pve-microvm。
原本的問題
Proxmox 原生只給兩個選擇:LXC 容器啟動快但共享 host kernel,一旦被攻破就是整台主機的風險,也無法換 OS 或掛自訂 kernel module。全虛擬機則要走過 SeaBIOS/OVMF、GRUB,探測一堆模擬的舊裝置(IDE、VGA、USB hub、PCI bridge),開機常要 5-10 秒。作者想要的是「VM 等級的隔離、容器等級的開機速度」,這正是 Firecracker 當初催生 QEMU microvm machine type 的初衷。
採用的方法
pve-microvm 是一個安裝時會 patch Proxmox qemu-server Perl 模組的 .deb 套件;只要在 VM 設定寫 machine: microvm,原本的 config_to_command 就會轉呼叫作者自寫的 MicroVM.pm,組出完全不同的 QEMU 指令:
qemu-system-x86_64 -M microvm,x-option-roms=off,pit=off,pic=off,\
isa-serial=on,rtc=on,acpi=on,pcie=on \
-kernel /usr/share/pve-microvm/vmlinuz \
-initrd /usr/share/pve-microvm/initrd \
-append "console=ttyS0 root=/dev/vda rw quiet" \
-device virtio-blk-pci-non-transitional,drive=drive-scsi0 \
-device virtio-net-pci-non-transitional,netdev=net0套件內建一顆 12MB 的 Linux 6.12.22 精簡 kernel(含 virtio、vsock、virtiofs,以及 Docker 需要的 overlay/veth/netfilter/BPF 模組)與 1MB initrd,另外用 pve-microvm-template 從 12 種 OCI base image 組出 rootfs,用 pve-oci-import 直接把 OCI image 匯入 PVE 磁碟。guest 內網路改用 systemd-networkd 而非 cloud-init,作者說後者太脆弱,換掉後 clone 模板更穩定。
實際效果
作者叢集上的 microVM 開機時間穩定落在 300ms 以內,一個用 virtio-mmio 的 NetBSD guest(SmolBSD)甚至只要 31 毫秒;完整安裝 Docker 與 QEMU guest agent 的 Debian 系統則在 8 秒內就緒(多數時間花在 apt 安裝套件)。閒置時一顆最小 microVM 只佔用約 40MB 記憶體,同一台 i7-12700 主機上要跑到第六顆才開始出現效能下滑,目前已驗證能開機的 guest OS 涵蓋 21 種,從 Debian、Alpine 到 NetBSD、Plan 9 都有。
VM 設定檔本身跟一般 Proxmox guest 幾乎一樣,只差 machine type 跟 kernel 參數:
agent: 1
args: -kernel /usr/share/pve-microvm/vmlinuz -append "console=ttyS0 root=/dev/vda rw quiet"
machine: microvm
memory: 2048
net0: virtio=BC:24:11:00:6E:01,bridge=vmbr0
scsi0: local-lvm:vm-114-disk-0,size=32G
serial0: socket
vga: serial0這個做法也有代價:因為是 patch 別人的 Perl 內部程式,每次 qemu-server 升級都可能讓套件失效,作者用 dpkg trigger 讓套件在升級後自動重新套用 patch,但仍遇過半套用狀態下 root device 從 /dev/vda 錯置成 /dev/sda 導致開機失敗。目前 QEMU 的 microvm machine type 本身不支援 live migration,只能靠「停機、搬磁碟、重開」的離線遷移,在共享 CIFS 儲存上搬一台小型 guest 約需 2 秒。
測 Linux 排程器效能,栽在一個寫死 10 分鐘的 benchmark 參數上
pradyun.net · 2026-07-18
Pradyun 在 UIUC 修「Parallel Computer Architectures」課程的期末專案部落格文章(2026 年 7 月 18 日發表)記錄了他與同學比較 Linux 預設排程器與 LAVD(Igalia 為 Steam Deck 設計的排程器)在雙路 Xeon 上的快取共享行為時,如何因為測試工具裡一個寫死的執行時間參數,把最關鍵的一筆數據誤判成「沒有變化」。團隊原本想測 Intel 送進 LKML 的 CAS(Cluster-Aware Scheduling)patch,但受限於共享實驗室資源改測 LAVD 作為替代,完整報告另有 PDF 與網頁版。
原本的問題
團隊想驗證的假設是:把多執行緒行程排在同一個 LLC(最後一層快取)網域內,能不能減少跨 socket 的快取一致性流量。他們在雙路 Xeon 系統上用 numactl 把 benchmark 執行緒強制限制在單一 socket 內作為對照組,藉此追蹤 read-for-ownership(RFO)跨 socket 請求次數的變化。結果顯示不論是預設排程器還是 LAVD,效能都差不多;但只要用 numactl 綁定單一 socket,執行時間就能加速最多 3 倍。
採用的方法
唯一例外是取自 DCPerf 套件的 mediawiki benchmark:即使 L3 RFO miss 數字明顯改善,整體執行時間卻幾乎沒變,團隊一度懷疑是快取命中率沒進步,檢查後發現並非如此。交完報告幾週後回頭清理測試紀錄,他們才想到去看先前完全沒用過的 MIPS(每秒百萬指令數)指標,赫然發現吞吐量其實明顯上升,執行時間卻「看起來」毫無變化。
實際效果
追到執行指令才發現,benchmark 的呼叫方式把測試時間寫死了:
cd /home/pradyun/pg_work/dcperf/
sudo ./perf_collect_mw "$JOBNAME"
./benchpress_cli.py run oss_performance_mediawiki_mlp \
-i '{"scale_out": 1, "client_threads": 32, "duration": "10m"}'duration: "10m" 這個參數埋在測試腳本深處,整個專案反覆沿用卻沒人注意到——執行時間被鎖死在 10 分鐘,指令數再怎麼提升,「runtime」這個指標本身就不會反映速度變化,等於用固定時長把最能證明 LAVD 有效的一筆數據直接抹平。作者的結論是:選錯衡量指標會讓結果偽裝成別的樣子,尤其在效能工程的 CI pipeline 裡,一旦 benchmark 設定被沿用不變,這種偽裝可能長期不被發現。
幫 Thunderbird 加一個外掛,讓 kernel 式 email patch review 不用手動貼指令
mccd.space · 2026-07-18
開發者 Marc Coquand 發布一個給 Thunderbird 用的外掛 thunderbird-patch-review,目標是讓 Linux kernel、git 這類靠 mailing list 加 git send-email 收發 patch 的專案,不用再手動複製貼上就能完成 review、回信、套用整個流程。專案原始碼放在作者自架的 git.mccd.space 上,README 目前只提供原始碼安裝方式,沒有正式版本號。
原本的問題
Linux kernel 與許多依賴 mailing list 的專案,review 流程是:把 patch email 讀出來、手動對照 diff 的每個 hunk 寫評論、再手動組一封回信貼進 mailing list,最後才用 git-am(1) 把整個 patch series 套進本地 repo。這一連串動作在一般郵件軟體裡完全沒有工具支援,全靠人工複製貼上,容易漏看、漏套用。
採用的方法
- 解析郵件裡的 git patch,提供介面讓使用者針對特定 hunk 留言
- 把整理好的評論組成一封標準格式的 mailing list 回信寄出
- 把同一資料夾裡屬於同一個 series 的多封 patch 郵件自動歸成一組
- 透過 Sourcehut mailing list(
lists.sr.ht)收到的 patch,自動提供 patch 狀態標頭(如 accepted/rejected)選項 - 套用階段直接呼叫
git-am(1)把整個 series 套進本地 repository
實際效果
作者形容目前程式碼是「vibe coded」,主要靠人工 QA 加測試套件驗證,還沒達到 production 等級的穩固度;已知限制包括不支援以附件形式夾帶的 patch、不支援純 HTML 郵件,也還沒有 git worktree 預覽功能。安裝方式是把原始碼打包成 .xpi(zip -qrX),再透過 Thunderbird「Add-ons Manager → Install Add-on From File...」手動安裝,尚未上架官方套件庫。Bug 回報與貢獻透過作者的 sourcehut mailing list ~marcc/thunderbird-review-plugin@lists.sr.ht 收件。