Nested ESXi のテンプレート作りに必要な設定と解説

Aug 23, 2020 Tips ESXi vSphere Nested
Share on:

Table of contents

2021/08/22 追記：ESXi 7.0 U2 以降では安全なブート領域の複製が不可

ESXi 7.0 Update 2 以降では ESXi の UUID への依存関係が増えているようで、esx.conf 内の UUID の修正のみでは足りなくなったようで、安全なブート領域のクローンが行えなくなりました。

元々 ESXi のブート領域の複製自体がサポートされない操作ですが、ESXi 7.0 Update 2 以降では同一 UUID を持つ(持っていた) ESXi から VMFS を共有すると VMFS が破損する可能性があるそうです。

ESXi 7.0 Update 2 以降のリリースは正規の手順で新規インストールすることが対応方法です。Nested ESXi なら TPM 等も無いので Configuration Reset の後に再設定でも良いような気はしますが、Kickstart スクリプトで自動インストールするなど正規の手順を踏むのが良いとは思います。

以降は ESXi 7.0 Update 1 以前の Nested ESXi 用の手順です。ESXi 7.0 Update 2 以降は対象としませんのでご注意ください。また、間違っても本番環境で同様の手順は実施しないようお願いします。

はじめに

みなさん Nested ESXi、使ってますか？vSphere の学習や実験にとても便利ですよね。

最近は Nested ESXi の作り方を Google 検索で調べれば日本語の情報も出てきますし、中の人も各種 Tips や OVF テンプレート／コンテンツライブラリの URLまで公開してくれています。

そこで、今回はある程度クリーンな Nested ESXi 7.0 のテンプレートを作るために必要な設定と、その設定の詳細について少し踏み込んで見ていきたいと思います。

仮想マシンの作成

仮想マシンの作成時のポイントとしては3つほどあります。

ゲストOSの種類に VMware ESXi 6.5 以降を選択

仮想マシンの作成時にゲストOSの種類として [VMware ESXi 6.5 以降] を選択することで、2 CPU、4GB メモリ、VMXNET3、PVSCSI が自動的に選択されるようになっています。選択したゲストOSの種類に応じた仮想ハードウェア構成がプリセットとして選択されるので、Nested ESXi に限らず、仮想マシンの作成時に正しいゲストOSを選択することはとても重要です。

なお、VMXNET3 ドライバは ESXi 5.1 時代から、PVSCSI ドライバは ESXi 6.5 から ESXi 自身のモジュールとして組み込まれています。

また、ESXi 6.7 Update 2 では Nested ESXi 向けの Intel DPDK 対応(Poll Mode Driver)のドライバ(nvmxnet3_ens)も追加されていたりします。NSX-T で N-VDS / VDS を拡張データパスで構成するとこちらのドライバに切り替わります。

Intel VT-x / AMD-V をゲストOSが使えるように設定

仮想ハードウェアの CPU の設定で [ハードウェア アシストによる仮想化をゲスト OS に公開] にチェックを入れます。これによりゲストOSでも Intel VT-x / AMD-V による CPU 仮想化支援が利用できるようになります。最近では Windows 10 の Virtualization-Based Security を ESXi 上の仮想マシンでサポート (実質 Nested Hyper-V を実行) するために使用されたりもします。

こちらの設定を有効にしなくても ESXi のインストールは可能ですが、インストールの中で CPU 仮想化支援が無効な旨の警告が出たり、インストール後に 64bit OS が起動できないなどの問題が発生します。後から都度設定するのも面倒ですので仮想マシンテンプレートの作成時点で有効にしておきましょう。

How to Enable Support for Nested 64bit & Hyper-V VMs in vSphere 5

起動時に BIOS / EFI のセットアップ画面の強制

仮想マシンオプションの [起動オプション] で [次回起動時に、強制的に EFI セットアップ画面に入る] にチェックを入れます。これにより一度だけパワーオン後に何もしなくても EFI の画面が表示されるので、慌てて DEL キーを連打しなくて済みます。

起動シーケンスの遅延

初回インストールでデータストアから ISO をマウントする場合は不要ですが、VMRC からローカルの ISO をマウントする、ESXi を再インストールする場合には有効にしておきましょう。

Nested ESXi のインストール

ESXi のインストール時は、かなり限定された環境の場合に1点あります。

ESXi 7.0 でサポート外 CPU を許可する

ESXi 7.0 ではサポートされない CPU (特に Westmere 以前) を使用する構成では警告が出てインストールが継続できなくなっています。このため、ESXi のインストーラ起動前に ESXi のブートローダ画面で Shift + O を押下して、allowLegacyCPU=true の起動オプションを追加してから起動する必要があります。

ブートローダでの起動オプションは、本来は以下のように Kickstart スクリプト (ks.cfg) を指定する場合などに使います。

なお、ESXi 7.0 でサポートされている CPU を使用している、ESXi 6.7 以前の場合は本設定は不要です。

Nested ESXi のインストール後

Nested ESXi のインストール後に必要になる設定はかなり多いです。

再・ESXi 7.0 でサポート外 CPU を許可する

allowLegacyCPU=true はブートローダで指定した場合は設定が永続化されないため、ESXi のインストール後、最初の起動時にも同様にブートローダで同じオプションを追加して ESXi を起動します。

Quick Tip – Allow unsupported CPUs when upgrading to ESXi 7.0

ESXi Shell と SSH の有効化

DCUI で F2 を押下してシステム構成画面に入り、[Troubleshooting Options] から ESXi Shell と SSH を有効にしておきます。

ダイレクト コンソール ユーザー インターフェイスを使用した、ESXi Shell および SSH アクセスの有効化

なお、あくまでも Nested ESXi は検証用として使うためにシェルを有効にしています。セキュリティの観点から通常運用時はどちらも無効が推奨ですので、本番環境ではトラブルシューティング時のみ有効にして使うようにしましょう。

ESXi 7.0 でサポート外 CPU を許可する設定の永続化

bootbank 内の boot.cfg の kernelopts 行に起動オプションが記載されているため、こちらに allowLegacyCPU=true を追記します。DCUI で Alt + F1 を押下して ESXi Shell に root でログインし、vi で /bootbank/boot.cfg を編集します。これで ESXi の再起動後も設定が保持されます。

Quick Tip – Allow unsupported CPUs when upgrading to ESXi 7.0

なお、bootbank と altbootbank には ESXi のブートイメージや構成情報が格納されています。こちらが破損すると ESXi が起動しなくなるため、通常運用時はテクニカルサポートからの特別な指示でも無い限り決して触ってはいけません。

vmk0 の仮想 MAC アドレスを vNIC に追従させる

仮想マシンをクローンすると vNIC には新しい仮想 MAC アドレスが割り当てられます。しかし、ESXi では VMkernel ポートに仮想 MAC アドレスがソフトウェア的に割り当てられています。このため、Nested ESXi をクローンしても仮想 MAC アドレスは変更されず、Nested ESXi 間で同じ MAC アドレスの VMkernel ポートが重複してしまいます。

そこで ESXi Shell から /Net/FollowHardwareMac の設定を有効にすることで、仮想マシンの vNIC に vmk0 (管理ネットワークの VMkernel ポート) の仮想 MAC アドレスを追従させる設定を施します。これにより vmnic の MAC アドレスが変更されると vmk0 の MAC アドレスも更新されるようになります。

1# esxcli system settings advanced set -o /Net/FollowHardwareMac -i 1

なお、こちらの設定は KB1031111 に記載があります。Details を読む限り、ESXi の起動ディスクを複製して別のサーバに搭載する、インストール済み ESXi の物理 NIC (MAC アドレス) を別のサーバに使い回した上で ESXi を再インストールする、といった作業を行うと問題として顕在化する可能性があるようです。このため物理環境では極めて限定的な状況下でのみ必要となる印象です。

NIC カードを交換しても vmk0 管理ネットワークの MAC アドレスが更新されないか、vmkernel に重複する MAC アドレスが存在する (1031111)

追加の VMkernel ポートは作成しない

/Net/FollowHardwareMac は管理ネットワークの VMkernel ポート (vmk0) だけに有効です。このため、本設定が有効でも他の VMkernel ポートの仮想 MAC アドレスはクローン後も変更されないため、Nested ESXi のテンプレートの時点では追加の VMkernel ポートは作成しないようにします。

番外： VMware Tools for Nested ESXi

ESXi 6.0 以降では Nested ESXi 用の VMware Tools が ESXi に組み込まれています。ESXi 5.x を Nested ESXi として利用する場合は以下の Flings から VIB をダウンロードして ESXi にインストールする必要がありました。

こちらの中の人のスクリプトのように、VMware Tools 経由でホストから guestinfo 変数の取得などもできたりします。なお、物理サーバで実行される ESXi では VMware Tools for Nested ESXi は実行されません。

VMFS データストアの削除

VMFS は作成された時点で固有の UUID が割り当てられます。vCenter Server に ESXi を追加する際に同じ UUID のデータストアが既にインベントリに存在すると追加に失敗します。このため、Nested ESXi にローカルの VMFS データストアが存在する場合は事前に削除しておきましょう。

Nested ESXi の Host Client にログインし、左メニューの [ストレージ] > [データストア] タブを開いてから、データストアを右クリックして削除するのが無難です。

VMware Host Client での VMFS データストアの削除

partedUtil コマンドを使用して VMFS のパーティション番号を確認して削除することも出来ます。ただ、間違って ESXi のパーティションを削除しないように注意が必要です。基本的にはトラブルシューティングのためのツールなので通常運用時はあまり使わないほうが良いと思います。

1# partedUtil getptbl /vmfs/devices/disks/<起動ディスクのデバイス識別子>
2# partedUtil delete /vmfs/devices/disks/<起動ディスクのデバイス識別子> <VMFS のパーティション番号>
3# services.sh restart

partedUtil コマンドの使用方法は KB1036609 に記載されています。

Using the partedUtil command line utility on ESXi and ESX (1036609)

番外: disk.enableUUID と VMFS の再署名

データストアの削除以外に VMFS の UUID を重複させない方法として、仮想マシンの disk.enableUUID オプションとデータストアの再署名を併用する方法もあります。

まず、仮想マシンで disk.enableUUID のオプションを有効にすると仮想ディスクがデバイス固有の UUID (WWN / WWID) をゲストOSに見せるようになり、Nested ESXi 見えではデバイス識別子が mpx から naa に変わります。冒頭に記載した Nested ESXi の OVF テンプレートでも本設定が有効になっています。

次に、この状態で仮想ディスクがクローンされると、クローンされたディスク上の VMFS は本来のデータストアではなくコピーされたデータストア (スナップショット LUN) として検出されます。この VMFS のコピーを ESXi でマウントするには、VMFS の再署名による UUID の再割り当てが必要となります。

この性質を利用すると、disk.enableUUID が有効な Nested ESXi テンプレートからのデプロイ後にデータストアの再署名をおこなうことで、意図的に VMFS の UUID を再割り当てすることが出来ます。中の人のブログではこちらの方法で対応しているようです。

How to properly clone a Nested ESXi VM?

なお、データストアの再署名はスナップショット LUN に対してのみ可能です。コピーされていない通常のデータストアはディスクと VMFS の情報に整合性が取れているため、データストアの再署名は必要がなく実施も出来ません。

esx.conf 内の System UUID の削除

ESXi は esxcli system uuid get コマンドで確認できる一意な UUID を持っています。vCenter Server はこの UUID で ESXi を識別しており、追加しようとする ESXi の UUID がインベントリ内の ESXi と競合すると追加に失敗したり不正な動作を起こしたりする場合があります。

このため、Nested ESXi のシャットダウン前の最後の作業として以下のコマンドを実行し、/etc/vmware/esx.conf に存在する UUID の行を削除します。vi による手動編集でも OK です。これにより次の ESXi の起動時、つまりテンプレートからのデプロイ後に ESXi の UUID が再生成されます。

1# sed -i 's#/system/uuid.*##' /etc/vmware/esx.conf

なお、esx.conf から UUID を削除した後に ESXi の再起動や esxcli system uuid get コマンドを実行すると UUID が再生成されてしまいます。このため、Nested ESXi のテンプレートのための作業が一通り終わってからシャットダウン前に実施するのが確実です。

仮想マシンテンプレートへの変換

ここまで Nested ESXi 仮想マシンでの作業が完了したら、あとは Nested ESXi をシャットダウンしてから仮想マシンテンプレートとしてクローンしておきましょう。もしくは、単に仮想マシンテンプレートに変換するだけでも OK です。

テンプレートへの仮想マシンのクローン作成

なお、仮想マシンテンプレートは vSphere Client (HTML5) 上で [仮想マシンおよびテンプレート] ビューから確認する必要があります。[ホストおよびクラスタ] ビューには表示されませんのでご注意ください。

vSphere が管理するインベントリ オブジェクト

ホスト側の ESXi での設定変更

Nested ESXi をホストする ESXi では仮想スイッチで以下のどちらかの構成が必要になります。

偽装転送＆プロミスキャスモードを許可

Nested ESXi では、仮想マシンの vNIC の MAC アドレスとは異なる MAC アドレスが送信元や宛先に設定された Ethernet フレームが vNIC で送受信されることになります。

しかし、vNIC と異なる送信元 MAC アドレスのフレーム、つまり送信元 MAC アドレスをなりすましたフレームが送信された場合、既定では以下の「偽装転送」オプションにより仮想スイッチがフレームを破棄します。このため、Nested ESXi が接続されるポートグループでは本設定を承諾に設定する必要があります。

また、ESXi の仮想スイッチは一般的な L2 スイッチと異なり、vNIC の MAC アドレスを見てフォワーディングを行います。スイッチでの MAC アドレスのラーニングは行わないため、Nested ESXi の vNIC と異なる宛先 MAC アドレスのフレームは Nested ESXi へフォワーディングしません。

このため、以下の無差別モード (プロミスキャスモード) を “承諾” に設定し、仮想スイッチに到達したフレームすべてを仮想マシンが受信できるようにします。一般的にはパケットキャプチャなどを行う場合にプロミスキャスモードを使用します。

標準スイッチの構成では標準スイッチかポートグループ、分散スイッチの構成では分散ポートグループか分散ポートで設定をおこないます。

これらのセキュリティポリシーを “承諾” にする場合の注意点として、本来は不正なフレームも破棄しなくなってしまうので、MAC アドレスのなりすましなどに対して脆弱になります。加えて、プロミスキャスモードは vNIC がすべてのフレームを受信するようになるため、トラフィック量によっては性能問題が出る場合もあります。

偽装転送を許可＆ vDS 6.6 以降の MAC ラーニングを使う

vSphere 6.7 では vDS 6.6 に MAC ラーニングが実装され、分散スイッチが仮想マシンの MAC アドレスを学習できるようもになりました。これにより、プロミスキャスモードが無効の場合でも宛先 MAC アドレスが vNIC と異なるフレームを正しい vNIC にフォワーディング出来るようになっています(偽装転送は承諾が必須)。

Native MAC Learning in vSphere 6.7 removes the need for Promiscuous mode for Nested ESXi

なお、設定変更は中の人の記事からリンクされている PowerCLI スクリプトの Get-MacLearn / Set-MacLearn を使うか、vSphere Web Services API を直接叩くことで実施できます。GUI からは有効に出来ないようです。色々な理由で個人的に本機能を試せる機会がなく実績を持っていないため、是非どなたか検証して結果を公開していただけるとありがたいです。

おわりに

今回は Nested ESXi に必要な設定とその詳細について見ていきました。Nested ESXi 一つ取っても非常に様々な vSphere のテクニックが使用されていることが分かります。中の人の Nested ESXi Appliance はこれらの設定が一通り事前に施してあるのでデプロイするだけで済み、とてもありがたみを感じることが出来ると思います。

また、非常に特殊な設定もいくつかはありますが、基本的には物理環境でも元々は何らかのユースケースが存在する機能が転用されています。これらの個々の機能を理解しておくと、物理環境でも設計やトラブルシューティングに応用を効かせることが出来ます。是非、興味のある方は個々の機能のドキュメントなどを読んでより一層 vSphere に Deep Dive してみてもらえればと思います。