2026年6月18日 · 15分で読む · #containers #homelab #kvm #microvm #proxmox #qemu #virtualization

私は長年、混在したProxmoxクラスタを運用してきました。Atom x5-Z8350搭載の2GB RAMノード（z83ii、忠実なベースラインツールとして長年使われた後、現在はオフライン）から、i7-12700搭載の128GB RAM（borg、私のメインホームラボサーバー）まで、能力が大きく異なる4ノードで構成されています。

今年、agentboxの執筆とエージェントサンドボックスに関する話題の間で、私はLXCコンテナとフル仮想マシンの間の永遠の妥協に疲れ、pve-microvmを構築しました。これはQEMUのmicrovmマシンタイプをProxmox VEのファーストクラス管理ゲストとして追加するDebianパッケージです。

これは一時的なハックではありません。最初のバージョンは実際にはそうでしたが、それ以来、予想以上に進化しました。

現在、カスタムカーネルを同梱し、Perlの内部をパッチしてProxmoxのWeb UI統合を提供しており、変わったオペレーティングシステムへの関心から、現在21種類のゲストOSタイプ（DebianからNetBSD、Plan9まで）をサポートしています。

はい、私はmicroVMでPlan9を実行する羽目になりました。そして、はい、動作します。

適切なバランスを見つける

クラスタのクリーンアップとマイグレーションを数回繰り返した後、現在はGitea、Caddyリバースプロキシ、ミニファイアウォール、そしてこの記事の整理を手伝ってくれているAIエージェントの日常的な運用に使用しています。

Proxmoxには、標準で2つの主要なオプションがあります：

  • LXCコンテナは即座に起動し、ホストカーネルを共有し、驚くほど効率的です。ただし、分離されていません。1つのコンテナでカーネルエクスプロイトが発生すると、すべてが危険にさらされます。異なるOSを実行できません。Dockerをネストさせるには、最終的にfuse-overlayfsの複雑な作業に取り組むことになります。また、カスタムカーネルモジュールや積極的なCAP_SYS_ADMINを必要とするワークロードは単に適合しません。

  • フルVMはKVM/VT-xによるハードウェア分離を提供しますが、SeaBIOSやOVMFで起動し、GRUBをゆっくりと通過しながら起動し、エミュレートされたレガシーデバイス（IDEコントローラ、VGA、USBハブ、PCIブリッジ）の森を調査し、通常、ログインプロンプトに到達するまでに5〜10秒かかります。各VMはメモリ内にそのエミュレートされたチップセット全体のオーバーヘッドを保持しています。

私が望んでいたのは、コンテナのような起動特性を持つVMのセキュリティ境界でした。QEMUのmicrovmマシンタイプは、Firecrackerスタイルのワークロードのために開発されたもので、すべてを削ぎ落とします。BIOSなし、GRUBなし、レガシーデバイスなし。最小限のvirtioのみの環境への直接カーネルブート。その結果：QEMUエージェントを備えた完全にネットワーク化されたゲストへの300ms未満の起動で、独自のKVMハードウェア分離境界内で実行されます。

Comparison of Standard VM, microVM, and LXC Container isolation and boot characteristics
Comparison of Standard VM, microVM, and LXC Container isolation and boot characteristics

明確にしておきます。私はこれらを数百個生成しているわけではありません。そのような用途にはAzureを使っています。しかし、Gitea Actionsワーカーを実行し、ハードウェアリソースが非常に限られており、特定のVMが繰り返し起動するのにかかる時間にうんざりしていました…

実際に何をするのか

pve-microvmは、インストール時に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 \
  ...

チップセットエミュレーションなし。PCIブリッジなし。VGAなし。ゲストは単一のシリアルコンソール（PVEのxterm.jsがネイティブに接続）を受け取り、virtioブロックデバイスとvirtioネットワークインターフェースを受け取ります。すべてがPCIeトランスポートと非移行型（モダンのみ）のvirtioデバイスで実行され、microvmが元々設計されていたMMIOトランスポートではなく、理由は後述します。

How pve-microvm integrates with Proxmox VE internals
How pve-microvm integrates with Proxmox VE internals

パッケージには以下が含まれます：

  • 最小限のオーバーレイでx86_64_defconfigからコンパイルされた小さな（12MB）事前構築済みLinux 6.12.22カーネル – virtio、vsock、virtiofs、9p、およびDockerが必要とするモジュール（overlay、veth、bridge、netfilter、BPF）を含みます。実用的だからです。
  • virtioデバイスをプローブし、ラベルまたはデバイスパスでルートファイルシステムを見つけ、約150msでswitch_rootを実行する1MBのinitrd
  • pve-microvm-template – 12種類のサポートされているOCIベースイメージのいずれかからルートファイルシステムを構築し、オプションでSSH、Docker、ゲストエージェントを追加
  • pve-oci-import – OCIイメージを直接PVE管理ディスクにプル
  • Web UI拡張 – 「Create µVM」ボタン、マシンタイプドロップダウン、無関係な設定の条件付きパネル非表示、リソースツリーのアンバーボルトアイコン
  • systemdサービス（pve-microvm-early.service） – ブート時にパッチがpvedaemon起動前に適用されることを保証 – onboot=1 VMに不可欠

ブートシーケンス

空気力学のように、ほとんどの速度は厳密に必要でないものをすべて排除することから来ます。標準VMはファームウェアとブートローダーでブート時間のほとんどを費やすため、microVMはそれをすべてスキップします。

Boot timeline comparison between microVM and standard VM
Boot timeline comparison between microVM and standard VM

SmolBSD（virtio-mmioトランスポートを使用するNetBSDゲスト）は31msで起動します。DockerとQEMUエージェントを備えた完全なDebianは8秒未満で準備が整います – そしてその時間のほとんどは初回起動時のaptパッケージインストールです。その後の起動は、私の控えめなハードウェアでも一貫して300msのマークに到達します。

誰かがSmolBSDサポートの追加を依頼したときに踏み込んだ楽しいウサギの穴：

SmolBSDがvirtio-mmioを使用でき、Linuxゲストが使用できない理由があります。QEMUのmicrovmマシンタイプは、virtioデバイスを2つのトランスポートで運ぶことができます。元々構築されたベアボーンMMIOインターフェース、またはPCIeです。MMIOは2つのうち軽量な方です – PCIeホストブリッジなし、ACPIなし – これがNetBSDゲストが31msまで削ぎ落とす方法です。

しかし、QEMU 10.xでは、MMIOパスには（私が見る限り）Linuxゲスト用のデバイスプロービングバグがあります：virtio-blkのみがバインドし、ネットワーク、シリアル、バルーンデバイスは理由不明でドライバによって要求されません。NetBSDはMMIOを正しくプローブし、完全に満足します。Linux（少なくとも私が使用しているカーネル）はそうではありません。

したがって、すべてのLinuxゲストに対して、PCIeと非移行型（モダンのみ）のvirtioデバイスにフォールバックし、これらはすべてを確実にバインドします。コストは約50msの追加の起動時間です – 300msのブートに対して、私は文句なく受け入れます。

これは実際には私のカーネル設定のバグだと思いますが、それに取り組む時間（またはおそらく適切なハードウェア）さえありませんでした – これはより多くの人々にパッチを寄稿してほしい点です。

1つのカーネル、多くのゲスト

この直接カーネルブートトリックの意図的な結果で、見逃しやすいものがあります：カーネルはゲスト内部に存在しません。Proxmoxホストの/usr/share/pve-microvm/vmlinuzに存在し、ゲストディスクにはルートファイルシステム – ユーザーランド、/bootなし、GRUBなし、ゲストごとのカーネルパッケージなし、独自のinitramfsなし – だけが含まれます。

これにより、「インストーラーISOを起動してクリックして進める」パスがないため、代わりにrootfsはpve-microvm-templateを使用してOCIイメージから直接構築されます（Debian、Alpine、Fedora、Rocky、Amazon Linuxなど）。奇妙なケースでは、qm importdiskで準備済みのext4/rawディスクをインポートします。OSをインストールするのではなく、ルートファイルシステムを組み立てるのです。

カーネルをrootfsから分離することが、これを大規模に実行する際に興味深い理由です。ノード上のすべてのLinux microVMは同じvmlinuzで起動します – 1つのカーネル、microvmオーバーレイ付きの標準x86_64_defconfigから1回構築されたため、1か所で正確に監査および更新できます：ホストに新しいvmlinuzをドロップし、ゲストを再起動、完了。ゲストがaptアップグレードから壊れたカーネルを引き出すことはありません。ゲストにアップグレードするカーネルがなく、rootfsイメージは小さく、完全にカーネルに依存しないままです。

コンテナスタイルのカーネル一貫性、VMスタイルの分離。

私が実行しているもの

私のクラスタでは、現在、すでにかなりの数のこれらを実行しています。思いつくままに4つ挙げます：

  • gitea（VM 114、Intel N5105上） – SQLite、Caddy HTTPS、ローカルactionsランナー、Avahi検出を備えたベアメタルGitea。2コア、2GB RAM、32GBディスク。約3秒で起動、主にGiteaが多くのハウスキーピングを行うためです。
  • smith（VM 9022、私のi7上） – メインのpiclawエージェント、クラスタを管理し、piclawをリリースし、すべてを監視するシステム。2コア、6GB RAM、48GBディスク。内部でDockerを実行し、Dockerを実行しないが異なる役割を持つ3つの小さな揮発性の兄弟がクラスタ全体に散在しています（CI/CD、アップグレードテスト用のwipe-and-reinstallエージェントインスタンスなど）。
  • exo（VM 9021、私のi7上） – 複数のマシンでLLMを実行するための分散推論コーディネーター。CPUのみ、2GBルート。
  • virtualdsm（VM 300、tnas） – Dockerを備えたmicroVM内で実行されるSynology DSM、Terramaster NASハードウェア内。はい、私が変なのはわかっていますが、Synologyが問題を起こしたときに必要でした。まだ破壊していません。DSMは特定のモジュールパスを必要とするため、カスタムカーネルではなくストックDebianカーネルを使用します。

また、休止中の9Front（Plan9）と、OpenWrt、OPNsense、OSv unikernel、gokrazy Goアプライアンス、さまざまなAlpine/Fedora/Rocky/Amazon Linux設定の小さなコレクションがあり、標準のProxmoxバックアップとして保存されています。21のゲストOSタイプは理論的なものではなく、それぞれが起動および検証されており、smithが回帰テストのために1つを解凍することがあります。

z83ii（その古いAtom x5-Z8350、2GB RAM）はベースラインテストプラットフォームとして非常に価値がありました。microVMが2016年時代のファンレスAtomで2GBの総システムメモリで起動して有用に実行できれば、どこでも動作します。そして、遅くなり始める前に6つ実行できました…

設定の見た目

microVM設定に魔法はありません – 特定のmachineタイプとカーネルコマンドラインを持つ通常のqmゲストです。以下は/etc/pve/qemu-server/114.confにあるgitea（上記のVM 114）です：

agent: 1
args: -kernel /usr/share/pve-microvm/vmlinuz -append "console=ttyS0 root=/dev/vda rw quiet"
boot: order=scsi0
cores: 2
machine: microvm
memory: 2048
name: gitea
net0: virtio=BC:24:11:00:6E:01,bridge=vmbr0
onboot: 1
scsi0: local-lvm:vm-114-disk-0,size=32G
serial0: socket
tags: microvm
vga: serial0

microvm固有の行はmachine: microvm、カーネルとそのcmdlineを運ぶargs、およびserial0: socket / vga: serial0でコンソールをxterm.jsに接続する配線のみです。その他すべて – コア、メモリ、vmbr0上のvirtio NIC、local-lvm上のscsi0ディスク、onboot、ゲストエージェント – は、任意のProxmox VMに書くものとまったく同じです。

argsに-initrdがないことに注意してください：MicroVM.pmは、提供されたカーネルを見ると、balloon、vsock、および（設定されている場合）virtiofsデバイスとともに自動的に挿入します。それが全体のポイントです – microVMは、ホスト提供のカーネルを起動する通常のゲストであり、新しいツールを学ぶ必要がある特別なオブジェクトではありません。

ネットワーキング

microVMは、他のProxmoxゲストとまったく同じようにネットワークに接続します。インターフェース仕様は少し長い（PCIeバス上のvirtio-net-pci-non-transitionalデバイス）ですが、指定した任意のLinuxブリッジとVLANに着地します：

qm set 900 --net0 virtio,bridge=vmbr0           # single NIC
qm set 900 --net0 virtio,bridge=vmbr0,tag=100   # tagged onto VLAN 100

通常のKVMゲストであるため、標準のPVEファイアウォールが適用されます – 任意のVMと同様に機能するVMごとのnftablesルールは、信頼できないコードを実行する場合に実際に重要な部分です。

ゲスト内部では、ネットワークはcloud-initではなくsystemd-networkdによって処理されます：デフォルトでDHCP（Type=etherでマッチするため、MAC固定なしでクローンを維持）、または静的アドレスの場合は1行の/etc/microvm-static-netです。以前のバージョンではこれにcloud-initに依存していましたが、あまりにも脆弱であることがわかりました。systemd-networkdに移行することでクローンが信頼性が高くなり、テンプレートのデバッグを止めることができました。

ネットワーク分離、エージェント分離に関する現在のハイプの主要な要素は、解決済みの問題であり、パッケージ内で再解決する興味はありません。なぜなら、Proxmox独自のSDNがすでに適切に実行していると思うからです – 信頼ドメインごとに別々のVNetを持つ単純なVLANゾーンは、信頼できないゲストをLANへのパスなしで独自のセグメントに保持し、ホームLANでそれに煩わされることがあれば（まあ、考えたことはあります…しかし時間がない）、指定された出口ノードを持つVXLANゾーンにより、単一のファイアウォール付きチョークポイントを通じてエグレスをファネルできます。

microVMは私がnet0を指す任意のVNetに着地するだけなので、ポリシーはProxmoxに存在し、私が世話をする必要があるワンオフのルールセットには存在しません。

ホスト/ゲスト配管のための非ネットワークパスもあります：各ゲストはvsock CID（VMID + 1000）を受け取り、SSHエージェント転送（ワイヤ上で公開することなくホストキーをゲストに）、およびvirtiofs/9pディレクトリ共有に使用します。なぜなら…忘れました。必要だったことはわかっていますが、今はほとんどのmicrovmインスタンスがSMBマウントを実行しています（DockerとLXCの下では苦痛でした）。

NIC数は…適度に合理的です。現在、ゲストごとに6つのvirtioインターフェース（net0-net5）を許可しています。これは、私のすべてのホストマシンにわたる物理インターフェースの最大数の2倍という根拠のない理由からです。これはMicroVM.pmで定義されており、それ以上を必要とする非常に少数の人はそれを調整できます（そして、1ダースが必要だと思うなら、ほぼ確実にVLANの方が良いでしょう）。

ストレージとマイグレーション

ストレージは…些細なことでしたか？すべてのPVEバックエンドが動作します。ディスクは単なるvirtio-blk-pciデバイスであり、Proxmoxは任意のVMに渡すのと同じパスを渡すからです。LVMとLVM-thin、ZFS、Ceph/RBD、NFSとCIFS、プレーンディレクトリストレージ – すべて問題なく、スナップショット、リンクおよびフルクローン、vzdumpバックアップ、qm importdiskが他の場所とまったく同じように動作します。microvmは、起動方法が異なる通常のPVEゲストです。

マイグレーションは、物事が不確かな唯一の場所です。a) 私のハードウェアではライブマイグレーションを実行できません（どれもエンタープライズグレードではありません）、b) 真のライブマイグレーションは、現在のQEMU microvmマシンタイプではそもそも実行できません – 単に実装していません。

ただし、オフラインマイグレーション（インスタンスの再配置）は問題なく動作し、microvmが1秒未満で起動するため、クイックHA再配置サイクルを実行できます – 停止、マイグレーション、起動 – ディスクが共有ストレージ上にある場合。

共有CIFS上でノード間で小さなゲストを移動するのに約2秒かかると測定しました。シームレスなVMモーションではありませんが、ほとんどの用途には十分良いかもしれません。そして、私の理解する限り、ha-managerは任意のゲストと同様にそれを駆動します。

LXCとの比較：どちらを選ぶか

念のため、私はまだLXCコンテナを実行しています。以下の場合に適切な選択です：

  • ワークロードを信頼している（または自分のコード）
  • ゼロのブートオーバーヘッドが必要
  • ホストから直接ファイルシステムアクセスが必要
  • わずかに少ないメモリ割り当てオーバーヘッド（そして、運が良ければ共有ページキャッシュ）

MicroVMが優位な場合：

  • 実際のカーネル分離が必要 – 信頼できないコードの実行、異なるカーネルバージョン、ネストされたDocker、積極的なCAP_要件を持つもの
  • スナップショット、バックアップ（vzdumpが動作）、オフラインマイグレーション、クローン（リンククローンも）できる再現可能なイメージが必要
  • ワークロードがカーネルに対して何か異常なことを行う（BPFプログラム、カスタムnetfilterルール、カーネルモジュール）場合で、それがホストに漏れることを望まない（これが、私のトンネルのほとんどが今microvmに着地する理由）
  • 非Linuxゲストを実行 – NetBSD、Plan 9、FreeBSDベースのファイアウォール – これらはLXCとして実行できません
  • コマンドを完了する前に起動するVMが必要

現代のハードウェアにおけるLXCとmicroVMの間のオーバーヘッドの違いは、驚くほど小さいです。borg（そのi7-12700）では、最小のmicrovmのアイドルメモリフットプリントは約40MBであり、ハイパーバイザーのCPUオーバーヘッドはほとんどのワークロードで測定できません。

ブート時に設定するメモリ値は、本当に単なる上限です：KVMはゲストが実際にタッチするページのみをバックアップし、ホストのsame-pageマージングはノード上のすべてのmicrovmにわたって同一ページ（カーネル、libc、共有ベースイメージレイヤー）を重複排除するため、成熟したクラウドハイパーバイザーのように、実際のコストは名目上の割り当てではなくワーキングセットを追跡します。

私の恥ずかしながら、私は長い間ライブリサイズに手を付けていませんでしたが、最近カーネルにballoonサポートを追加し、free-page-reportingとdeflate-on-oomを備えています。PVEのバルーンターゲットは適切な自動バルーニングを駆動し、virtio-memデバイスは本物の細粒度のホットアドとホットリムーブを提供するため、これもまた通常のVMのように動作します。

厄介な部分

さて、注意点です…

1つ目はかなり明白です：私は他人の製品をパッチしており、Perl 4からPerl 5への移行を数十年前に生き延びたそして今はCodexが助けてくれますが、Perlの内部をパッチするのは脆弱です – すべてのqemu-serverアップグレードで私のセットアップが壊れる可能性があります。

私はa) アップグレードを盲目的に実行せず、b) dpkgトリガーを使用することでこれを軽減しています（パッケージはアップグレード後に自動的に再パッチします）が、それでも発生を待っている競合状態です – 部分的なPVEアップグレードでpvedaemonがパッチされたモジュールをコンパイルできなくなる状態になったことがあります。

そして、奇妙な障害モードが続きます – 1つのアップグレードでルートデバイスに関する厄介な副作用がありました：

  • ルートはroot=/dev/vdaで見つかります。なぜならゲストがPCIe上のvirtio-blkを備えたmicrovmマシンタイプの下で起動するためです
  • しかし、ゲストが標準チップセットの下で起動する場合（部分的に適用されたパッチ、またはホスト再起動後のearly-bootサービスが再パッチする前に起動するonboot=1 VM）、同じディスクは/dev/sdaとして列挙され、ルートが見つからず、VMはファイルシステムを失ったように見えます。

データは常に存在しますが、パスが間違っています。私はdpkgトリガーとearly-bootサービスの順序付けがそれを軽減しようとする方法でその特定のねじれをパッチしたため、initrdは今、/dev/vdaが見つからない場合に/dev/sdaにフォールバックします – しかし、ProxmoxがmicroVMをネイティブにサポートするまで（もしあるなら）、時折の引っかかりを期待してください。

パッケージバージョンの不一致はカスケードする可能性があります。私はこれを苦労して学びました – 1つのノードでの部分的なapt upgradeでlibpve-cluster-perlとlibpve-network-perlが互換性のないバージョンになり、すべてのPerlモジュールの読み込みが壊れ、pvedaemonが起動できなくなり、VMを管理できなくなりました。

したがって…このようなPVEノードでは、常に完全なdist-upgradeを実行し、部分的なアップグレードは行わないでください。

もう1つの注意点（一部の人にとって）は、VGAやグラフィカルコンソールがないことです – シリアルコンソールが唯一のインターフェースです。ブート中に何か問題が発生した場合、カーネルパニックをターミナルで読むことになります。これはサーバーには問題ありませんが、デスクトップ指向のゲストにはあまり良くなく、Plan9は本当に気に入りません。

次のものは、USBがまったくありません – コントローラー、パススルー、バス上の何も – したがって、ゲストをmicrovmに切り替えるとすぐにWeb UIがそれらのオプションを非表示にする必要がありました。これは、たとえばZigbeeコントローラーを実行したい場合に問題になる可能性があります（これが、私のホームオートメーションがまだLXCにある理由）。

カーネルは意見があります。私のカスタム6.12.22カーネルには、必要なものだけが含まれ、それ以外は何も含まれていません。ワークロードに私が含めていないモジュールが必要な場合、それを再構築するか、ストックDebianカーネルを使用する必要があります（問題なく動作しますが、3倍大きく、起動が遅くなります）。

最後に、GPUとPCIパススルーは無効されており、不可能ではありません。そして、これはより多くのお金とハードウェアを持つ人々に本当に飛び込んでほしいもう1つのことです。なぜなら、初期テストでRTX 3060を実際にパススルーして動作させることができたからです。

最終的に、シンプルさのためにGPUサポートを一時的に無効にすることにしました – パッケージは今日hostpci*を削除し、vIOMMU配管が接続されていないため、デフォルトでオフです。

誰かがそれを元に戻すことを妨げるものは何もありません（最小限のECAM PCIeバスとIOMMUセットアップに関するQEMU microvmの注意点を除いて）、そして私は適切なPCIとvIOMMUテストを実行できることを心から望んでいます – ただし、それを行うための予備のハードウェアがなく、エージェントの実行に焦点を当てることにしました。

内部：パッチ戦略

パッケージはPVE Perlスタックの3つのファイルを変更します：

  • Machine.pm – マシンタイプ正規表現を拡張してmicrovmを有効な値として受け入れる
  • QemuServer.pm – use PVE::QemuServer::MicroVMインポートとconfig_to_commandの先頭に委譲チェックを追加：VMにmachine: microvmがある場合、完全に私のモジュールに引き渡す
  • MicroVM.pm – 完全なコマンドビルダー、/usr/share/perl5/PVE/QemuServer/MicroVM.pmにインストール

回復可能性に執着しているため、パッチは元に戻すことが可能（pve-microvm-patch revert）で、元のファイルはバックアップされます。dpkgトリガーシステム（interest-noawait qemu-server）により、PVE更新後の自動再適用が保証されます。early-bootサービスにより、VMが自動起動する前にパッチが有効になります。上記で言及したsda/vdaの混乱を防ぎます：

pve-microvm-early.service (Before=pvedaemon.service pve-guests.service)
    └── /usr/share/pve-microvm/pve-microvm-patch apply

始め方

ここまで読んだなら、あなたは勇敢な人か、GitHubリンクを見逃したかのどちらかです。したがって、ここに簡潔なバージョンを記載します：

# 任意のPVE 9.xノードで：
wget https://github.com/rcarmo/pve-microvm/releases/latest/download/pve-microvm_0.3.12-1_all.deb
dpkg -i pve-microvm_0.3.12-1_all.deb

# Debian microVMテンプレートを作成：
pve-microvm-template --vmid 9000 --storage local-lvm --profile standard

# 実際のVMにクローン：
qm clone 9000 100 --name my-microvm --full
qm set 100 --machine microvm --memory 1024 --cores 2
qm start 100

テンプレートの構築には約60秒かかります（OCIイメージをプルし、パッケージをインストールし、ルートファイルシステムを書き込みます）。その後、リンククローンを使用すれば、クローンはほぼ瞬時に完了します。

今後の予定

より多くのテスト（ハードウェア、時間、集中力がないため、ほとんどのプロジェクトのように、ただ使用したいだけです）を除いて、残っているのは主に磨きです：より良い設定レイヤー、信頼できないゲストのための出口許可リスト付きのネットワークオフバイデフォルト（偏執的な人のため）、vIOMMUを適切に配線できればGPUパススルー、そして最終的にARMベースのPVEノード（過去に実行したことがあり、QEMUバージョンにmicrovmサポートがあると思います）のためのAArch64サポート。

そして、もちろん、誰かがこれをアップストリームするべきです。私はProxmoxの数人に非公式に連絡しましたが、メーリングリストに参加して議論するように言われました。しかし、a) それはひどく90年代的であり、b) 私は自分自身のためにこれを維持する以上の時間を持っていません。そして、ええ、これが企業のQAパイプライン全体を通過する必要があることはわかっています（私はそれがたくさんあることを理解しています）。

ソースはgithub.com/rcarmo/pve-microvmにあり、パッチはかなり小さく、99%の機能がQEMU/KVMから来ているためProxmox自体を壊すことはありません。したがって…私はただそれを配っているだけです。

しかし、ホームラボを運用していて、Linuxに精通していて、実際の分離を備えたコンテナ速度のVMを探しているなら、これは探していたものかもしれません – まあ、統計的には、おそらく一度もありません – しかし、今すぐ手に入れることができます！