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回もお付き合いいただけたら嬉しいです。