vSphere-VMハードウェアバージョンをアップグレードする理由

今年の初めに、vSphere 5.0からvSphere 5.1 U1ビルド1063329へのvSphere環境のアップグレードを実行し、約12個のESXiホストとWindows Server 2008 R2 SP1でホストされるvCenterインスタンスが侵害されました。このプロジェクトの顕著な問題の1つは、仮想マシンの仮想ハードウェアのアップグレードです。

すべてのVMで仮想ハードウェアバージョンをアップグレードするために、なぜ作業とダウンタイムを行う必要があるのかを理解できません。新しく作成された仮想マシンは、vSphere 5.1 U1でサポートされている最新バージョンのVirtual Hardware v。9を使用しており、古いvSphere 5.0インスタンスのWindows Server 2012 R2およびWinPE 4.0で発生していた問題を解決します。古い仮想マシンはすべて互換性のある仮想ハードウェアバージョン（KB2007240）であるため、ハードウェアバージョンをアップグレードする必要はありません。

ゲストオペレーティングシステムとESXiの互換性は問題ではないため、仮想マシンのすべての仮想ハードウェアを「最新」バージョン9にアップグレードする技術的な理由がありませんか？仮想ハードウェアのアップグレードは、VMをシャットダウンし、スナップショットまたはバックアップを作成してから、数百のVMでアップグレードする必要があるため、必ずしも簡単ではありません。将来的にこれを行う必要がなくなり、すべての仮想マシンが最新の仮想ハードウェアバージョンで実行されているというファジーを取得する以外に、仮想マシンの交換時にローリングアップグレードではなくストレートカットオーバーを実行する必要があるのはなぜですか？

一般に、仮想ハードウェアバージョンは新しい機能を導入し、制限を拡張し、パフォーマンスに影響を与える可能性があります。VMwareハードウェアバージョンマトリックスを参照してください。

現在使用しているvSphereのリビジョンについては、これについて心配する必要はありません。使用しているセットアップに基づいて、古いバージョンで終日実行できます。VMハードウェアバージョン8は、特定の状況に最適な選択肢のようです。

仮想ハードウェアのバージョンに関する唯一の実際の考慮事項は、vSphere 5.5で導入されたバージョン8またはvmx-09からvmx-10への移行です。この移行には管理性への影響があります。しかし、肯定的には、そのプロセスはvSphere Web Clientによって合理化され、ゲストのリブート中にVMバージョンのアップグレードをスケジュールできます。