ESXi環境でEFIファームウェアとGPTブートディスクを使用することには、顕著な利点（または欠点）はありますか？

タイトルが尋ねるように、私の基本的な質問は：ESXi環境でEFIファームウェアとGPTブートディスクを使用することには、顕著な利点（または欠点）はありますか？「注目すべき」とは、MBRディスクの既知の2 TB制限、およびBIOSブートファームウェアがMBRディスクを使用してブートする必要があるという制限以外のことを意味します。

特定のVMオプションは以下のスクリーンショットにあります。

それが違いを生む場合、私の特定の環境の背景と詳細を以下に示しますが、私は一般的なケースだけでなく、具体的にまたはWindows環境にのみ関連するすべてのものに興味があります。

最近のプロジェクトの結果、$ [day_job]にある企業の大君主を現在の10年に引き込むことに成功したため、ホームオフィスシステムの多くを置き換えます。これらのシステムは、置き換えられるシステムと同様に、主にESX 5.5で仮想化されたWindows Server OSです（今すぐアップデート1、間もなくアップデート2、VMFS5、大容量サポート）。VMおよびVMがアクセスするすべてのストレージは、NFS共有を介してESXiホストに提供されるSAN（EMC VNX 5400）上にあります。すべてがシンプロビジョニングされています。

ほとんどの場合、大規模で複雑なPITAシステムを新しいプラットフォームにアップグレードするだけです。たとえば、現在Server 2003 R2で実行されており、DFSを使用していないマルチTBファイルサーバーは、サーバーにアップグレードされます。 2012 R2、DFS名前空間に配置し、DFSレプリケーションを利用して、Server 2012データ重複排除の使用を開始します。現在サーバー2003 R2およびSQL Server 2005で実行されているSharePointシステムは、サーバー2012 R2を実行するSharePoint 2013にアップグレードされ、2008 R2以上のSQL Serverエンジンに配置されます。等々。

ファイルサーバーを調べて、それらのデータ量を処理する方法（ホームオフィスの各ファイルサーバーには2 TBを超えるデータが含まれている）を調べて、サーバーのデータ重複排除機能を調べました。これはボリュームごとに機能するため、現在の混乱のように複数のボリュームに分割するのではなく、すべてのデータが1つのボリュームである場合に最適に機能します。これにより、GPTディスクがデータボリュームに最適であるという問題が発生し、EFIとBIOSファームウェアの問題が発生しました。私たちのすべてのサーバーには、データボリュームとは別の50 GBのOS [仮想]ディスクがあり、少なくとも現在のところ、それを維持することを計画しています-新しいVMにデータボリュームをアタッチできることは非常に便利です。

したがって、そのことを念頭に置いて、2 TBのMBRディスク制限を超えるためにGPTである必要があるボリュームからVMを起動する必要がある、またはVMを起動するシナリオを想定することはできません。環境が純粋に仮想であるという事実は、GPTディスクの回復可能性の利点を打ち消しているようです。そのため、EFIブートファームウェアやGPTブートボリュームを使用して新しいVMを構築し始める説得力のある理由を思い付くことができません。もちろん、BIOSブートファームウェアとMBRディスクに固執する説得力のある理由も思いつきません。そのため、私の質問は次のとおりです。

ESXi環境でEFIファームウェアとGPTブートディスクを使用することには、顕著な利点（または欠点）はありますか？（「注目に値する」とは、MBRディスクの既知の2 TB制限、およびBIOSブートファームウェアがMBRディスクを使用してブートする必要があるという制限以外のことを意味します。）

BIOS対UEFIの前面には、これがあります：https : //communities.vmware.com/thread/464854

私は、仮想ファームウェアの開発、特に仮想EFIの実装を担当するチームで働いています。

EFIがデフォルトであることを意図していませんでした。vSphere 5.1 GAに間に合うように間違いを修正するには遅すぎたことがわかりました。また、最初の間違いの結果は、ドキュメントなど、EFIがデフォルトであると想定されていた他のさまざまな場所に広がっていました。担保を解放します。

デフォルトでBIOSに戻したい主な理由は、FTのサポートがないことです。FTと互換性のないデフォルト構成を提供したくありませんでした。BIOSで機能するがEFIで失敗する少数のPCIパススルーシナリオ、およびゲストOSデプロイメントソリューション、OSリカバリーソリューション、PXEブート環境、PXEサーバーなどのエコシステムでのBIOSの一般的な幅広いサポートなど、2番目の理由が存在します。サポートなど。

これですべてです。vSphere 5.1 GAに間に合うようにクリーンアップできなかった方法で伝播したのは間違いであり、混乱を引き起こしたのは最も残念なことです。

私のアドバイス：FTが必要ない場合、PCIパススルーを使用せず（または、PCIパススルー構成が仮想EFIで動作することを検証できる場合）、他のBIOS固有のツールへの依存関係がほとんどないか、まったくありません。 OSを管理すれば、EFI Windows 2012 VMを自由に展開できます。

VMのEFI設定が非常に役立つ1つの場所は、EFIがVMware Converterでサポートされていないため（または前回は確認していなかったため）、EFIを使用してインストールされたベアメタルシステムの手動P2V変換を許可することです。Windows Server 2008 R2 EFIシステムのP2V変換を実行する方法を参照してください。この背景について。