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がアクセスするすべてのストレージは、SAN（EMC VNX 5400）上にあり、NFS共有を介してESXiホストに提供されます。すべてがシンプロビジョニングされています。
ほとんどの場合、大規模で複雑な一連のPITAシステムを新しいプラットフォームにアップグレードするだけです。たとえば、現在Server 2003 R2で実行されており、DFSを使用していないマルチTBファイルサーバーは、サーバーにアップグレードされます。 2012 R2、DFS名前空間に配置し、DFSレプリケーションを利用して、Server 2012 Data Deduplicationの使用を開始します。現在サーバー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を超えるためにGPTである必要があるボリュームからVMを起動する必要がある、または必要とするシナリオを想定することはできませんTB MBRディスク制限。環境が純粋に仮想であるという事実は、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で機能することを検証できる場合）、依存関係がほとんどないか、まったくないOSを展開または管理する他のBIOS固有のツールでは、EFI Windows 2012 VMを自由に展開できます。
VMのEFI設定が非常に役立つ1つの場所は、EFIがVMware Converterでサポートされていないため（または前回は確認していなかったため）、EFIを使用してインストールされたベアメタルシステムの手動P2V変換を許可することです。この背景情報については、 Windows Server 2008 R2 EFIシステムのP2V変換を実行する方法 を参照してください。