1. 導入の背景：なぜProxmox上でNested ESXiを動かすのか？
本番環境のvSphere 7.0から8.0へのアップグレード計画を立てる際、多くのシステム管理者が直面するのがハードウェアの壁です。検証用サーバーがVMwareのハードウェア互換性リスト（HCL: Hardware Compatibility List）から除外されており、ESXi 8.0がRealtek RTL8111 NICを認識しなかったり、Intel Xeon E5 v3/v4世代のCPUをサポート外としてブート画面で停止してしまったりします。
新機能の検証のためだけにエンタープライズ基準のサーバーを調達しようとすると、通常1,500ドル〜3,000ドル程度のコストがかかり、ラボ環境としては現実的ではありません。そこで最適な解決策となるのが、既存のProxmox VEノードを活用したNested ESXi 8.0の構築です。
ProxmoxのKVMはハードウェア抽象化レイヤー（HAL）として機能します。必要な命令セットを含むCPU全体を仮想化し、エンタープライズ標準のVMXNET3/E1000e NICやSCSI/NVMeコントローラーを提供することで、ESXi 8.0のインストーラーをスムーズに認識・動作させることができます。
2. 事前準備＆Proxmox VE上でのESXi 8.0仮想マシンの作成
まず、ProxmoxホストのKVMカーネルで仮想化支援機能（Intel VT-xまたはAMD-V）のネストが有効になっていることを確認します。
ProxmoxホストでNested Virtualizationを有効化する
ProxmoxノードにSSH接続し、カーネルモジュールの状態を確認します：
# Intel CPUの場合の確認（結果がYまたは1なら有効）
cat /sys/module/kvm_intel/parameters/nested
# AMD CPUの場合の確認
cat /sys/module/kvm_amd/parameters/nested画面にNまたは0と表示された場合は、modprobeの設定ファイルを作成して恒久的に有効化します：
# Intel CPUの場合
echo "options kvm_intel nested=1" > /etc/modprobe.d/kvm-nested.conf
# AMD CPUの場合
echo "options kvm_amd nested=1" > /etc/modprobe.d/kvm-nested.conf
# モジュールの再読み込み（注意：稼働中のVMがないことを確認してください）
modprobe -r kvm_intel && modprobe kvm_intel || rebootCLIを使用したESXi 8.0標準VMの作成
ISOイメージファイルVMware-VMvisor-Installer-8.0U2.isoをlocalストレージにアップロードします。その後、パープルスクリーン（PSOD）エラーを防ぐための推奨構成でVM作成コマンドを実行します：
qm create 900 --name nested-esxi-01 \
--memory 16384 --balloon 0 \
--cores 4 --sockets 1 --cpu host \
--ostype other --bios ovmf \
--scsihw virtio-scsi-single \
--scsi0 local-lvm:60,format=raw,cache=writeback \
--net0 vmxnet3,bridge=vmbr0,firewall=0 \
--cdrom local:iso/VMware-VMvisor-Installer-8.0U2.iso \
--boot order=cdrom;scsi03. 詳細構成：CPU Type、Storage、プロミスキャスネットワーク
ProxmoxのWeb GUIからVMを作成する場合、以下の3つの必須設定に注意してください：
CPU Type = Host に設定する
これは最も重要なパラメーターです。デフォルトのkvm64のままだと、VMwareインストーラーがハードウェア命令フラグ不足のエラーを出してインストールを中断します。hostを選択することで、物理CPUのすべての命令セット（VT-x/AMD-V、SSE4.2、AES-NIなど）がESXi仮想マシンへ直接パススルーされます。
Linux Bridgeのプロミスキャス（Promiscuous）ネットワーク設定
Nested ESXi内で動作する各ゲストVMは、それぞれ固有のMACアドレスを持ちます。デフォルトでは、Proxmox上のLinux Bridge（vmbr0）は未知のMACアドレス宛てのパケットをフィルタリングして破棄するため、ゲストVMがDHCPからIPを取得できなくなります。
迅速な解決策として、ブリッジ上のMACラーニングを無効化し、パケットを自由にフォワードさせます。Proxmoxホスト上の/etc/network/interfacesを編集します：
auto vmbr0
iface vmbr0 inet static
address 192.168.1.10/24
gateway 192.168.1.1
bridge-ports eno1
bridge-stp off
bridge-fd 0
bridge-ageing 0bridge-ageing 0パラメータを設定すると、ブリッジがブロードキャスト/ユニキャストパケットを無制限にフォワードするモードになります。編集後、ifreload -aを実行して設定を適用します。
インストーラー起動時の旧世代CPUチェックをバイパスする
Haswell/Broadwell世代のIntel Xeonや第4〜6世代Core iシリーズの場合、ESXi 8.0のインストーラーが非対応CPU警告を表示することがあります。ブートローダーの5秒カウントダウン画面でShift + Oキーを押し、コマンドライン末尾に以下の引数を追加してEnterキーを押します：
allowLegacyCPU=true4. 動作確認、ゲストVMのインストール＆リソース監視
インストール完了後、VM 900を再起動し、コンソール画面に表示されたアドレス（例：https://192.168.1.50）からブラウザでESXi Host Clientにアクセスします。
ネットワーク疎通確認用のテストゲストVM作成
軽量なISOファイル（Alpine Linux 約50MBやUbuntu Server 24.04など）をESXiのデータストアにアップロードします。テスト用VMを作成して起動し、ゲストVMにログインしてルーティングを確認します：
# LANのDHCPから割り当てられたIPアドレスを確認
ip a
# ゲートウェイおよびパブリックDNSへPingを実行
ping -c 4 192.168.1.1
ping -c 4 1.1.1.1Pingの応答が1ms未満のレイテンシで安定していれば、ネスト環境のネットワーク疎通は完全に正常です。
Proxmoxホスト側でのリソース監視
ネスト仮想化構成では、通常5〜10%のリソースオーバーヘッドが発生します。重要な注意点：ESXi VMでは絶対にMemory Ballooningを有効にしないでください。ESXiカーネルは固定メモリ割り当てを前提としており、急激なメモリの伸縮が発生するとカーネルパニック（クラッシュ）を引き起こします。
Proxmox CLIからVMの実際の負荷を確認します：
# VM 900のステータスと割り当て情報を確認
qm status 900 -v
# サーバー全体のCPU・メモリ負荷を監視
pvetop64GBのRAMと8コアCPUを搭載したProxmox物理サーバーが1台あれば、2ノードのNested ESXiと1台のvCenter Server Appliance（VCSA 8.0）を十分展開できます。高価な専用ハードウェアに予算をかけることなく、vMotion、HA、DRS、vSANを検証できる理想的な環境が手に入ります。
