Gibt es bemerkenswerte Vor- oder Nachteile bei der Verwendung von EFI-Firmware und GPT-Startdisketten in einer ESXi-Umgebung?

Meine grundlegende Frage lautet, wie der Titel schon sagt: Gibt es bemerkenswerte Vor- oder Nachteile bei der Verwendung von EFI-Firmware und GPT-Startdisketten in einer ESXi-Umgebung? Mit "bemerkenswert" meine ich alles andere als das bekannte 2-TB-Limit für MBR-Festplatten und die Einschränkung, dass die BIOS-Boot-Firmware MBR-Festplatten zum Booten verwenden muss.

Die spezifische VM-Option ist im folgenden Screenshot dargestellt.

Für den Fall, dass es einen Unterschied macht, finden Sie unten einige Hintergrundinformationen und Besonderheiten zu meiner speziellen Umgebung, obwohl ich mich für den allgemeinen Fall sowie für alles interessiere, was sich speziell oder nur auf eine Windows-Umgebung bezieht.

Aufgrund einiger kürzlich durchgeführter Projekte, bei denen es mir gelungen ist, meine Unternehmensoberhäupter bei $ [day_job] in das aktuelle Jahrzehnt zu ziehen, werde ich viele unserer Home-Office-Systeme ersetzen. Diese Systeme sowie das, durch das sie ersetzt werden sollen, sind in erster Linie Windows Server-Betriebssysteme, die unter ESX 5.5 virtualisiert wurden (Update 1 jetzt, bald Update 2, und VMFS5, also Unterstützung für große Volumes). Die VMs sowie der gesamte Speicher, auf den sie zugreifen, befinden sich in einem SAN (EMC VNX 5400), das den ESXi-Hosts über NFS-Freigaben angezeigt wird. Alles ist dünn versorgt.

Zum größten Teil werde ich einfach eine Reihe großer, komplizierter PITA-Systeme auf neuere Plattformen aktualisieren. Beispielsweise werden unsere Multi-TB-Dateiserver, die derzeit auf Server 2003 R2 ausgeführt werden und kein DFS verwenden, auf Server aktualisiert 2012 R2, in DFS-Namespaces eingefügt werden, die DFS-Replikation verwenden und die Server 2012-Datendeduplizierung verwenden. Unser SharePoint-System, das derzeit auf Server 2003 R2 und SQL Server 2005 ausgeführt wird, wird auf SharePoint 2013 aktualisiert, auf dem Server 2012 R2 ausgeführt wird, und es wird eine SQL Server-Engine von 2008 R2 oder höher installiert. Und so weiter.

Bei der Untersuchung der Dateiserver und des Umgangs mit der Datenmenge auf ihnen (jeder unserer Home-Office-Dateiserver verfügt über Daten von mehr als 2 TB) habe ich die Datendeduplizierungsfunktion in Server untersucht und festgelegt 2012. Da dies pro Volume funktioniert, funktioniert es am besten, wenn alle Daten ein Volume sind, anstatt wie in unserem aktuellen Durcheinander auf mehrere Volumes aufgeteilt zu sein. Dies brachte das Problem auf, dass GPT-Festplatten für unser Datenvolumen am besten geeignet sind, und brachte mich zur Frage der EFI- und BIOS-Firmware. Unsere Server verfügen alle über [virtuelle] Betriebssystemfestplatten mit 50 GB, die von allen Datenvolumes getrennt sind, und zumindest derzeit plane ich, dies so zu halten. Es ist sehr nützlich, ein Datenvolumen an eine neue VM anschließen zu können .

Vor diesem Hintergrund kann ich mir kein Szenario vorstellen, in dem eine VM jemals von einem Volume gestartet werden muss oder soll, das GPT sein muss, um das 2-TB-MBR-Festplattenlimit zu überschreiten. Die Tatsache, dass die Umgebung rein virtuell ist, scheint die Wiederherstellbarkeitsvorteile von GPT-Festplatten zu negieren. Daher kann ich mir keinen zwingenden Grund vorstellen, unsere neuen VMs mit EFI-Boot-Firmware und / oder GPT-Boot-Volumes zu erstellen. Natürlich kann ich auch keine zwingenden Gründe finden, mich an die BIOS-Boot-Firmware und MBR-Festplatten zu halten, und daher meine Frage:

Gibt es bemerkenswerte Vor- oder Nachteile bei der Verwendung von EFI-Firmware und GPT-Startdisketten in einer ESXi-Umgebung? (Mit "bemerkenswert" meine ich alles andere als das bekannte 2-TB-Limit für MBR-Festplatten und die Einschränkung, dass die BIOS-Boot-Firmware MBR-Festplatten zum Booten verwenden muss.)

In Bezug auf BIOS und UEFI gibt es Folgendes : https://communities.vmware.com/thread/464854

Ich arbeite in dem Team, das für die Entwicklung der virtuellen Firmware verantwortlich ist, insbesondere der virtuellen EFI-Implementierung.

Wir hatten nicht beabsichtigt, dass EFI die Standardeinstellung ist. Wir stellten fest, dass wir einen Fehler zu spät gemacht hatten, um ihn rechtzeitig für vSphere 5.1 GA zu korrigieren, und die Konsequenzen des anfänglichen Fehlers hatten sich auf verschiedene andere Stellen übertragen, die nun angenommen hatten, dass EFI der Standard sein sollte, wie z. B. Dokumentation und Sicherheiten freigeben.

Der Hauptgrund für die standardmäßige Rückkehr zum BIOS ist die mangelnde FT-Unterstützung. Wir wollten keine Standardkonfiguration bereitstellen, die mit FT nicht kompatibel sein würde. Es gibt sekundäre Gründe, wie z. B. eine kleine Anzahl von PCI-Passthrough-Szenarien, die im BIOS funktionieren, aber im EFI fehlschlagen, und allgemein eine breitere Unterstützung für das BIOS im Ökosystem - z. B. Bereitstellungslösungen für Gastbetriebssysteme, Betriebssystemwiederherstellungslösungen, PXE-Startumgebungen und PXE-Server Unterstützung und so weiter.

Das ist alles dazu. Es war ein Fehler, der sich auf eine Weise ausbreitete, die wir nicht rechtzeitig für vSphere 5.1 GA bereinigen konnten, und es ist äußerst bedauerlich, dass dies zu Verwirrung geführt hat.

Mein Rat: Wenn Sie FT nicht benötigen, kein PCI-Passthrough verwenden (oder wenn Sie überprüfen können, ob Ihre PCI-Passthrough-Konfiguration mit virtuellem EFI funktioniert) und nur wenige oder keine Abhängigkeiten von anderen BIOS-spezifischen Tools aufweisen, die bereitgestellt werden sollen oder Wenn Sie Ihr Betriebssystem verwalten, können Sie EFI Windows 2012-VMs bereitstellen.

Ein Ort, an dem die EFI-Einstellung für VMs sehr nützlich ist, besteht darin, manuelle P2V-Konvertierungen von Bare-Metal-Systemen zuzulassen, die mit EFI installiert wurden, da EFI von VMware Converter nicht unterstützt wird (oder nicht, zuletzt habe ich es überprüft). Siehe So führen Sie eine P2V-Konvertierung eines Windows Server 2008 R2-EFI-Systems durch für Hintergrundinformationen dazu.