1. はじめに：なぜ今、ネステッドESXi環境が必要なのか
インフラエンジニアにとって、新しい技術や構成を「手元ですぐに壊して試せる環境（ホームラボ）」はやっぱりありがたいですよね。オンプレ環境に模してクラウド環境との接続確認、Terraform等を用いたIaC（Infrastructure as Code）の自動化テスト、生成AI活用した開発環境を用意する際など、何かと便利です。
今回は手元のVMware仮想環境でいくつか検証するために、物理サーバーを直接ESXiにするのではなく、「ハードウェアの抽象化レイヤーとしてProxmox VE (PVE) を敷き、その上でネステッド（入れ子）のESXiを稼働させる」 という構成にホームラボを作り直しました。
個人がVMware ESXiを動かす前提は、ここ2年でずいぶん揺れました。一時期は配布が停止されていましたが、2025年4月のESXi 8.0 Update 3eでひっそりと無償版が復活しています。エントリーレベルとしての位置付けで、vCenter連携や一部の高度機能は使えませんが、ホームラボでESXi自体を触る分には十分だと思われます。
今回構築したProxmox環境には、ホームラボ運用上ありがたいメリットがいくつかあります。
- ハードウェア要件の吸収: コンシューマ向けのIntel NUCやUSB NICなど、ESXiのHCL（ハードウェア互換性リスト）から外れがちなデバイスのドライバ問題をProxmox側で吸収できる。
- 検証サイクルの短縮: ESXiホスト自体のスナップショット取得やロールバックがProxmox上から数秒で行えるため、破壊的な検証 (意図的な仮想ネットワークデバイス削除) からの復旧が早い。
VMwareのコアアーキテクチャを理解していれば、Proxmoxの概念をキャッチアップするのはそれほど難しくありません。本連載（全2回）では、VMwareエンジニアの視点からProxmoxのアーキテクチャを翻訳しつつ、自分なりに納得できるVMware検証基盤を作っていくプロセスをご紹介します。
第1回となる本記事では、アンダーレイとなるProxmoxクラスタの構築と、Raspberry Piを用いたクォーラム（QDevice）構成までを解説します。
2. 検証基盤の全体アーキテクチャ
まずは今回のホームラボの全体像です。2台のIntel NUCをコンピュートノードとし、共有ストレージにSynology NASを使用しています。
機器構成
| 機器 | ホスト名 / 役割 | 管理LAN IP | 備考 |
|---|---|---|---|
| Intel NUC #1 | proxmox01 (PVE Node) | 10.0.0.21/24 | Core i7-10710U / 64GB RAM、Proxmox VE 9.1 |
| Intel NUC #2 | proxmox02 (PVE Node) | 10.0.0.22/24 | Core i7-10710U / 64GB RAM、Proxmox VE 9.1 |
| Synology NAS | synology-nas (NFS) | 10.0.0.5/24 | VMバックアップ・ISOファイル格納用 |
| Raspberry Pi 4 | vpn-pi (QDevice / VPN) | 10.0.0.7/24 | スプリットブレイン対策 ＆ Tailscale GW |
なお、Synology NASはバックアップデータやISOファイルの格納場所として利用しています。そのため、本検証環境構築記事にはメインで登場しません。
ネットワークの論理構成
セキュリティと検証の独立性を担保するため、ネットワークは物理レベルで2つに分離しています。
- ホームラボ管理LAN (10.0.0.0/24): Proxmoxの管理GUI、Corosync（クラスタ通信）、NASへのNFS通信を行う隔離ネットワーク。VMware vSphere仮想環境でいうところの「管理用vmkernelポート」および「vMotion/vSAN用vmkernelポート」の役割を担います。
- マンション共有LAN (xxx.yy.0.0/22): VM（ネステッドESXiなど）が外部やインターネットと通信するためのネットワーク。vSphereでいう「仮想マシン用ポートグループ」です。
3. アンダーレイ（Proxmox）のネットワーク設計
Intel NUCにProxmox VEをインストールする手順はウィザードに従うだけで完了します。詳細はProxmox公式ドキュメントに譲るとして、インストール直後にまず行うのがネットワークの分離設計です。
Proxmoxには、VMware vSphere仮想環境の「標準vSwitch (vSS)」や「分散仮想スイッチ (vDS)」のような専用の概念はありません。代わりに標準的な Linux Bridge (vmbr) を用いてトラフィックを制御します。考え方としては、vSSのアップリンクとポートグループが、Linux Bridgeの bridge-ports と各VMのvNIC接続にあたるイメージです。
今回は、NUCの内蔵NIC（eno1）を管理LANに、追加したUSB NIC（enx...）をVM用LANに割り当てます。
# /etc/network/interfaces の設定例 (proxmox01)
auto lo
iface lo inet loopback
# 管理LAN（10.0.0.0/24）- VMware仮想環境の管理用vmkernel相当
iface eno1 inet manual
auto vmbr0
iface vmbr0 inet static
address 10.0.0.21/24
bridge-ports eno1
bridge-stp off
bridge-fd 0
# gateway は設定しない（隔離ネットワークのため）
# VM用共有LAN（xxx.yy.0.0/22）- VMware仮想環境の仮想マシン用ポートグループ相当
iface enxXXXXXXXXXXXX inet manual
auto vmbr1
iface vmbr1 inet dhcp
bridge-ports enxXXXXXXXXXXXX
bridge-stp off
bridge-fd 0
設定後、ifreload -a コマンドで反映させます。この時点で、vCenterなしの単一ノードとしてProxmox GUIにアクセスできるようになります。
設定後のProxmox GUI上では以下のように見えます。
【ハマりポイント】USB NICの認識
Realtek製のUSB NICを使用した場合、稀にProxmox再起動後にデバイス名（enx...）が変わってしまう、あるいは認識が遅れることがあるようです。可能であれば、udevルールでMACアドレスベースの固定名（例：eth1）を割り当てておくと運用が安定します。
4. スプリットブレイン対策：CorosyncとQDeviceの仕組み（vSphere HAとの設計思想比較）
VMware vSphere仮想環境のクラスタ機能でおなじみなのが「vSphere HA」です。HAクラスタを有効化すると、各ESXiホスト上で FDM (Fault Domain Manager) Agent が起動し、Master/Slave選挙でMasterホストを1台決めます。
Slaveは管理ネットワーク経由でMasterへ1秒間隔でハートビートを送ります。管理ネットワークが切れた場合は、共有データストア上のハートビートファイル（Datastore Heartbeating）をMasterが読みに行き、「ホストが落ちたのか、ネットワークだけが切れたのか」を切り分ける仕組みです。
さらに Isolation Response と Admission Control という設計要素があり、ホスト分離時のVMの扱い（電源そのまま／シャットダウン／パワーオフ）と、フェイルオーバー時のリソース確保を、クラスタ単位で事前にポリシー化できる仕組みになっています。
一方、Proxmoxは各ノードが対等な「マルチマスター」アーキテクチャをとっており、クラスタリングには Corosync を利用します。vCenterのような中央管理点は存在せず、すべてのノードが投票（クォーラム = N/2 + 1）によって意思決定を行います。
そして異常を検知した時の振る舞いも対照的です。Proxmoxは 「自己フェンシング（Self-Fencing）」 を採用しており、ノードがクォーラムを喪失すると、Linuxの Watchdog タイマー機能によってそのノード自体が強制的に再起動されます。スプリットブレインを「異常側のノードを物理的に止める」という形で防ぎます。
両者を整理すると以下のようになります。
| 観点 | vSphere HA | Proxmox + QDevice |
|---|---|---|
| クラスタ通信 | FDM Agent + Datastore Heartbeating | Corosync (UDP/Knet) |
| 主導権決定 | Master/Slave選挙 | クォーラム投票（過半数） |
| 障害判定の二段構え | 管理NW + Datastore Heartbeating | Corosyncリング + QDevice |
| 異常ノードの扱い | Isolation Response（VM単位の制御） | Watchdogによる自己フェンシング（ノード再起動） |
| リソース確保 | Admission Control | 運用者によるキャパシティプランニング |
| 2ノード時の対策 | Witness Host (vSAN) | QDevice (corosync-qnetd) |
VMware vSphereは「VMをどう生かすか」を中心に細かなポリシーを積み重ねる設計、Proxmoxは「異常ノードを即時隔離する」というLinux HAの原則に沿った設計、と捉えると理解しやすいかもしれません。
ここで直面する課題が、「2ノード構成におけるスプリットブレイン対策（Quorum：定足数の確保）」 です。
ノード間のネットワークが切断された際、2ノードだと「1対1」の同票になり、どちらがVMのフェイルオーバー（再起動）処理の主導権を握るべきか判断できません。vSANの2ノードクラスタを組む際に「Witness（監視ホスト）」アプライアンスが必須になるのと同じ理屈です。
Proxmoxでは、このWitnessの役割を QDevice (Quorum Device) として、軽量な外部のLinuxマシンに担わせることができます。今回は、ネットワーク上にいる Raspberry Pi 4 (vpn-pi) を第3の投票権として設定しました。VM自体はホストしないため、Pi程度のリソースで十分にタイブレーカーとして機能します。
QDeviceのセットアップ手順
-
Raspberry Pi側での準備:
corosync-qnetdをインストールします。
sudo apt update && sudo apt install corosync-qnetd -y
sudo systemctl enable --now corosync-qnetd
-
Proxmoxノード側での登録:
NUC側（proxmox01等）でcorosync-qdeviceをインストールし、Raspberry Piを登録します。
apt install corosync-qdevice -y
pvecm qdevice setup 10.0.0.7
-
ステータスの確認:
設定後、pvecm statusを実行し、Total votes: 3およびQuorate Qdeviceのフラグが立っていれば成功です。
# pvecm status の出力結果
Votequorum information
----------------------
Expected votes: 3
Highest expected: 3
Total votes: 3
Quorum: 2
Flags: Quorate Qdevice
【ハマりポイント】QDevice setup と SSH の前提
pvecm qdevice setup は内部でSSH経由でラズパイ側の設定を行うため、Proxmoxノード（root）からラズパイのrootユーザーへ、パスワードなしでSSHログインできる状態にしておく必要があります。一時的にラズパイ側の /etc/ssh/sshd_config で PermitRootLogin yes を許可し、ssh-copy-id で公開鍵を渡してから pvecm qdevice setup を実行する流れになります。セットアップが完了したら、PermitRootLogin prohibit-password（鍵認証のみ）に戻しておくのが安全です。
もう1点、地味にハマるのが 時刻同期 です。Corosyncは時刻ズレに敏感なので、ProxmoxノードとRaspberry Piは同じNTPソース（chronyなど）を参照させておくと安定します。
これで、どちらかのNUCが物理的にダウンしても、残ったNUCとラズパイ（過半数）によって安全に仮想マシンが再起動される構成が完成しました。
5. 【補足】Tailscaleによるリモートアクセス
今回の管理LANはインターネットから隔離されていますが、外出先からも検証環境を操作できるよう、Raspberry PiにTailscaleを導入してSubnet Routerとして機能させています。これにより、ノートPCから暗号化トンネル経由で直接Proxmox GUI（https://10.0.0.21:8006）にアクセスできます。
詳しい設定手順はTailscaleの公式ドキュメントが充実しているので、本記事では割愛します。
6. おわりに
今回は、Proxmoxのアーキテクチャ（Linux Bridge、Corosync、QDevice）を解剖しつつ、ネステッドESXiを稼働させるためのアンダーレイ（土台）を構築しました。
「管理ポートとVMポートの物理的な分離」や「スプリットブレインを防ぐための第3の投票権」など、インフラの原理原則（物理法則）はVMware vSphereであれProxmoxであれ変わりません。vSphereの知識を「翻訳のモノサシ」として持っていると、他の仮想化基盤の勘所も掴みやすいと実感しています。
次回は、Proxmox上にネステッドESXi 8.0 をデプロイするプロセスをご紹介します。
最後まで読んでいただいてありがとうございます。
連載第2回もお付き合いいただけたら嬉しいです。