午前2時、私の電話が激しく震えました。電話の主はERPシステムの運用を担当している同僚で、かなり焦った様子でした。新しく構築したESXi 8.0のクラスターに移行したばかりのSQL Serverが、理由もなく急激に重くなったというのです。急いで確認したところ、そのVMはESXi 5.0時代のハードウェアバージョン 8のまま動作していることがわかりました。
このような状況は、システム管理者の間では非常によくあることです。ESXiホストのアップグレードには熱心でも、その中で動く仮想マシンの「衣替え」を忘れてしまいがちです。新しいハイパーバイザー上で古いVMを動かすのは、テスラのエンジンをスーパーカブのフレームに載せるようなものです。動くことは動きますが、本来の最高速度に達することは決してありません。
なぜ今すぐVMハードウェアバージョンをアップグレードすべきなのか？
VMware ESXiの各バージョンには、対応する「仮想ハードウェア」のセットが付属しています。このバージョン（現在はVM互換性と呼ばれます）をアップグレードすることで、仮想マシンのパワーが大幅に解放されます。
- リソース制限の拡張: ハードウェアバージョン 20 (ESXi 8.0) は、最大448個のvCPUと6TBのRAMをサポートします。これは、古いバージョン 8の32個のvCPU、1TB RAMという制限を遥かに凌駕します。
- 最新テクノロジーへの対応: 超高速なディスク速度を実現するNVMeコントローラー、Windows 11のインストールに必要なvTPM、セキュリティを強化するセキュアブートなどの機能が利用可能になります。
- I/Oの最適化: ゲストOSとハイパーバイザー間の通信遅延が大幅に削減され、データベースアプリケーションなどのレスポンスが向上します。
以前、検証環境としてワークロードをProxmoxに移行した際、マシンタイプ（q35/i440fx）の管理が非常に柔軟であることに気づきました。しかし、VMwareは後方互換性に関してより厳格です。そのため、システムダウンのリスクを避けるための体系的なアップグレード戦略が必要になります。
一般的な3つの実施方法の比較
| 方法 | メリット | デメリット |
|---|---|---|
| 即時アップグレード | すぐに適用され、即座に結果が得られる. | 仮想マシンの停止が必須。スナップショットを忘れるとリスクが高い。 |
| スケジュール設定 | 安全。次回の再起動時に自動的に実行される。 | 次回のメンテナンス時期まで待つ必要がある。 |
| PowerCLI | 数百台のVMを一括処理できる。 | スクリプトが不正確だと広範囲にエラーを引き起こす可能性がある。 |
警告：後戻りできない道？
ハードウェアバージョンのアップグレードには、注意すべき重要な点があります。それは、GUIからダウングレードすることはできないということです。一度バージョン20に上げてしまうと、バックアップから復元するか、.vmxファイルを手動で編集しない限り、古いバージョンに戻すことはできません。.vmxファイルの編集は、本番データにとって極めて大きなリスクを伴います。
私のアドバイスとしては、常にスナップショットを併用したスケジュールアップグレードを優先することです。サーバー停止の始末書を書きたくなければ、決して近道をしないでください。
「エキスパート」流の標準アップグレード手順
ステップ 1: VMware Tools を最優先する
これは鉄則です。必ず先にVMware Toolsをアップグレードしてください。逆の手順で行うと、VMがネットワークカードやディスクコントローラーのドライバを認識できなくなる可能性があります。その結果、ブルースクリーン（BSOD）が発生したり、ネットワーク接続が完全に失われたりすることがよくあります。
ステップ 2: スナップショットで「命綱」を作る
自分の腕を過信してはいけません。VMを右クリックし、[スナップショット] -> [スナップショットの作成] を選択します。「HWアップグレード前」など分かりやすい名前を付けて、トラブル時に簡単に戻せるようにしておきましょう。
ステップ 3: スマートなアップグレード予約
即時アップグレードではなく、スケジュール機能を使ってダウンタイムを最小限に抑えるのが私の常套手段です。
- 実行中のVMを右クリックし、[互換性] -> [VM互換性のアップグレードのスケジュール] を選択します。
- ホストがサポートする最高バージョン（例：ESXi 8.0 以降）を選択します。
- [ゲスト OS の正常なシャットダウン後のみアップグレードする] にチェックを入れます。
この方法は非常に優れています。VMは通常通り動作し続け、メンテナンス時間中にシステムが再起動される際、OSが起動する前の数秒間でVMwareがハードウェアをアップグレードしてくれます。
大規模システム向けの自動化
対象のVMが50台から100台にも及ぶ場合、一台ずつクリックするのは苦行です。以下のPowerCLIスクリプトを使えば、特定のリソースプール全体のアップグレードスケジュールを一瞬で設定できます。
# vCenterに接続
Connect-VIServer -Server vcenter.yourdomain.com
# 特定のリソースプール内のすべてのVMをスキャン
$vms = Get-ResourcePool "Production_Pool" | Get-VM
foreach ($vm in $vms) {
Write-Host "スケジュール設定中: $($vm.Name)" -ForegroundColor Cyan
$vmView = $vm | Get-View
$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.ScheduledHardwareUpgradeInfo = New-Object VMware.Vim.ScheduledHardwareUpgradeInfo
$spec.ScheduledHardwareUpgradeInfo.UpgradePolicy = "always"
$spec.ScheduledHardwareUpgradeInfo.VersionKey = "vmx-19" # ESXi 7.0 U2 用
$vmView.ReconfigVM($spec)
}
Disconnect-VIServer -Confirm:$false現場で学んだ「手痛い教訓」
長年大規模なクラスターを管理してきた中で、特に重要な3つの注意点を挙げます。
- WindowsのGhost NIC問題: アップグレード後、Windowsが古いネットワークカードを非表示デバイス（Ghost NIC）として認識し、新しいカード（Network Adapter #2）を作成してしまうことがあります。その場合、静的IPを最初から設定し直す必要があります。
- ソフトウェアライセンス: 一部の古い会計ソフトやERPは、ハードウェアIDにライセンスを紐付けています。ハードウェアバージョンの変更によりライセンスが失効する可能性があるため、事前にベンダーに確認してください。
- vMotionの障壁: クラスター内に古いホスト（6.7）と新しいホスト（7.0）が混在している場合、古いホストが理解できないバージョンにVMをアップグレードしないでください。さもないと、緊急時にVMを古いホストへ移動できなくなります。
仮想ハードウェアのアップグレードは、単に数字を追いかけるだけのものではありません。高価なサーバーインフラへの投資を保護し、最適化するための手段です。この記事が、皆さんの運用保守の夜をより穏やかなものにすることを願っています！
