VMware vSphere Quick Bootを有効化：メンテナンス時のESXi再起動時間を80%削減 - ITFROMZERO - Share tobe shared! VMware vSphere Quick Bootにより、ESXiはBIOS/UEFIのPOST処理をスキップし、再起動時間を15分から90秒未満に短縮できます。互換性チェック手順、vLCMでの有効化設定、実環境でのトラブルシューティングまでを徹底解説します。

VMwareクラスタのパッチ適用で夜間作業を経験したことがあるエンジニアなら、サーバーの再起動中にコンソール画面を見つめながら秒数を数えるあの感覚がよくわかるはずです。512GBのRAM、SAN HBAカード、RAIDコントローラーを搭載したDell PowerEdge R740やHPE DL380などのサーバーは、POST（Power-On Self-Test）の完了とファームウェアのロードだけで10〜15分もかかってしまうことが珍しくありません。Quick Bootは、まさにこの無駄な待ち時間を削減するために生まれた機能です。

筆者が管理するインフラ環境（Cisco UCSハードウェア上で稼働する8台のESXi 7.0U3クラスタ）では、以前はローリングアップデートの完了に2時間半もかかっていました。しかし、ハードウェア要件を確認してQuick Bootを有効化してからは、クラスタ全体のメンテナンス時間が40分未満にまで短縮されました。ホストの再起動がスムーズになり、VMの退避・復帰も迅速に行えるようになります。

Table of Contents

クイックスタート：5分でできる互換性チェック

Quick Bootはすべての構成で自動的に動作するわけではありません。利用するには、事前に以下の2ステップでハードウェアの互換性を確認する必要があります。

ステップ1：SSH経由でチェックスクリプトを実行する

ESXiホストにSSH接続し、rootアカウントでログインして、VMwareに標準で組み込まれている検証コマンドを実行します。

/usr/lib/vmware/loadESXi/bin/loadESXi.py -c

ホストが要件を満たしている場合、ターミナルに以下のような結果が出力されます。

Compatibility check succeeded. Quick Boot is supported on this platform.

このメッセージが表示されれば、ハードウェア側の準備は完了です。

万が一 Compatibility check failed と表示された場合は、機能を阻害しているコンポーネントが具体的に指摘されます。よくある原因としては、NICドライバが古い、PCIパススルーデバイスが接続されている、またはBIOSで必要なハードウェア仮想化機能が有効になっていないことなどが挙げられます。

ステップ2：vSphere Lifecycle Manager (vLCM) でQuick Bootを有効化する

vSphere Client（HTML5）にアクセスします。
対象のクラスタを選択し、[アップデート] タブに切り替えます。
[ホストの修正]（またはイメージ設定）セクションで、[修正設定の編集] をクリックします。
[Quick Boot] の項目を見つけ、[Quick Bootの有効化] にチェックを入れます。
[保存] をクリックして設定を保存します。次回の修正（Remediation）以降、vCenterはQuick Boot経由でカーネルをロードするようになります。

技術的仕組み：Quick Bootはどのように動作するのか？

標準的な reboot の流れと比較してみましょう。

OSがマザーボードへACPIリセット信号を送信します。
サーバーがソフトパワーオフを実行し、ハードウェアを最初から初期化します。
BIOS/UEFIがPOSTを実行：メモリのカウント、PCIeバスのスキャン、RAID/SANコントローラーの初期化などを行います。
ブートローダーがディスクを特定し、VMkernelをメモリにロードします。

上記の処理サイクルが起動時間全体の約85%を占めています。Quick BootはLinuxの kexec に類似したメカニズムを採用し、このプロセスを効率化します。

Quick Bootを有効化すると、以下のように動作します。

VMkernelが新しいカーネルイメージを独立したRAM領域に直接事前ロードします。
実行中のプロセスやドライバが安全にシャットダウンされます。
システムが旧カーネルから新カーネルへと直接ジャンプ（direct jump）します。マザーボードの電源状態やハードウェアのファームウェア状態は完全に維持されます。
POSTなし、メモリの再カウントもなし。ホストはわずか60〜90秒でDCUI画面に復帰します。

自動化：PowerCLIでクラスタ全体のステータスを一括確認する

数十台あるホストに1台ずつSSH接続する代わりに、PowerShellから以下のスクリプトを実行して一括確認できます。

# 1. vCenterへの接続
Connect-VIServer -Server "vcenter.prod.local" -User "[email protected]" -Password "SecurePassword123!"

# 2. クラスタ内の全ホストをスキャン
$ClusterName = "Production-Cluster"
$Hosts = Get-Cluster -Name $ClusterName | Get-VMHost

foreach ($VMHost in $Hosts) {
    $esxcli = Get-EsxCli -VMHost $VMHost -V2
    $qbStatus = $esxcli.system.quickboot.get.Invoke()
    [PSCustomObject]@{
        HostName           = $VMHost.Name
        QuickBootSupported = $qbStatus.Supported
        QuickBootEnabled   = $qbStatus.Enabled
    }
}

Quick Bootが動作しない3つの典型的な原因

実際の現場環境において、チェックスクリプトでエラーが発生する主な原因は以下の3点です。

1. サードパーティ製ドライバ（Third-party VIB）の未認証：
Dell、HPE、CiscoなどのカスタムISOイメージには、独自の管理ドライバが含まれていることがよくあります。これらのドライバがベンダーによるQuick Boot互換テストに合格していない場合、機能が拒否されます。以下のログファイルを確認して、具体的な対象ドライバを特定できます。

cat /var/log/loadESXi.log | grep -i "incompatible"

対処法：VMware Compatibility Guide（互換性ガイド）に従ってVIBを最新バージョンにアップグレードするか、ネイティブドライバに移行します。

2. 仮想マシンにPCIパススルー（DirectPath I/O）デバイスが接続されている：
NVIDIA GPUカードや10GbE NICポートを仮想マシンに直接割り当てている場合、ハードウェアの物理状態がロックされます。この場合、PCIバスを再初期化するためにホストのハードリブート（完全再起動）が必須となり、Quick Bootは自動的に通常の再起動プロセスへとフォールバックします。

3. TPM 2.0とIntel TXTの設定：
vSphere 7.0以降ではQuick Boot時のTPM 2.0がサポートされています。ただし、BIOSでTPMを有効にしていてもIntel TXT（Trusted Execution Technology）が無効になっている場合、チェックスクリプトは即座に失敗します。BIOSを再起動し、TPM/TXT関連の設定を再確認してください。

本番運用における実践的なTips

vMotionのネットワーク帯域に注意： Quick Bootによりホストの再起動時間は12分から約1.5分へと短縮されます。しかし、vMotionネットワークが1GbEのままの場合、大容量VM（128GB RAMのデータベースなど）の移行（退避）に依然として時間がかかります。vMotionネットワークを10GbEまたは25GbEへ高速化することが極めて重要です。
フルリブートが必須となるケース： BIOSのアップグレード、iDRAC/iLOのファームウェア更新、RAID/HBAカードのマイクロコード更新などを伴うメンテナンスでは、サーバーがPOSTを実行してチップに新しいファームウェアを適用できるよう、Quick Bootを無効にして完全再起動を行う必要があります。
自動フォールバック機能： カーネルロード中にQuick Bootで異常が発生した場合、vLCMは自動的に従来のハードリブートへ切り替えます。ホストが途中でハングアップすることなく、安全にメンテナンスを完了できます。