Czy istnieją jakieś istotne zalety (lub wady) korzystania z oprogramowania układowego EFI i dysków rozruchowych GPT w środowisku ESXi?

Moje podstawowe pytanie brzmi, jak brzmi tytuł: czy są jakieś znaczące zalety (lub wady) korzystania z oprogramowania układowego EFI i dysków rozruchowych GPT w środowisku ESXi? Przez „godne uwagi” mam na myśli wszystko inne niż dobrze znany limit 2 TB dla dysków MBR oraz ograniczenie, że oprogramowanie rozruchowe systemu BIOS musi używać dysków MBR do rozruchu.

Konkretna opcja maszyny wirtualnej znajduje się na zrzucie ekranu poniżej.

W przypadku, gdy robi to różnicę, niektóre tło i szczegóły dotyczące mojego konkretnego środowiska są poniżej, chociaż interesuje mnie ogólny przypadek, a także wszystko, co odnosi się konkretnie lub tylko do środowiska Windows.

W wyniku niektórych ostatnich projektów, w których udało mi się przeciągnąć moich korporacyjnych zwierzchników o wartości [[dzień_obrażania]] do obecnej dekady, zastąpię wiele naszych domowych systemów biurowych. Te systemy, a także elementy, które mają zostać zastąpione, to przede wszystkim systemy operacyjne Windows Server zwirtualizowane w ESX 5.5 (teraz aktualizacja 1, wkrótce aktualizacja 2 i VMFS5, więc obsługa dużych woluminów). Maszyny wirtualne, a także cała pamięć, do której mają dostęp, znajdują się w sieci SAN (EMC VNX 5400), która jest prezentowana hostom ESXi za pośrednictwem udziałów NFS. Wszystko jest ograniczone.

W większości przypadków po prostu będę aktualizować kilka dużych, skomplikowanych systemów PITA na nowsze platformy - na przykład nasze serwery plików z wieloma TB, które obecnie działają na serwerze 2003 R2 i nie używają systemu plików DFS, zostaną uaktualnione do serwera 2012 R2, umieść w przestrzeniach nazw DFS, skorzystaj z replikacji DFS i zacznij korzystać z deduplikacji danych Server 2012. Nasz system SharePoint, który obecnie działa na Server 2003 R2 i SQL Server 2005, zostanie uaktualniony do SharePoint 2013, na którym działa Server 2012 R2 i zostanie zainstalowany na silniku SQL Server 2008 R2 lub nowszym. I tak dalej.

Patrząc na serwery plików i jak radzić sobie z ilością danych na nich (każdy z naszych serwerów plików w biurze domowym ma dane przekraczające 2 TB), przyjrzałem się i ustabilizowałem funkcję deduplikacji danych na serwerze 2012. Ponieważ działa to w odniesieniu do poszczególnych woluminów, działa najlepiej, jeśli wszystkie dane są jednym woluminem, a nie podzielone na wiele woluminów, jak nasz obecny bałagan. To spowodowało, że dyski GPT były najlepsze dla naszych woluminów danych i doprowadziły mnie do pytania o oprogramowanie EFI vs BIOS. Wszystkie nasze serwery mają dyski [wirtualne] z systemem operacyjnym o pojemności 50 GB, które są oddzielone od dowolnych woluminów danych, a przynajmniej w tej chwili planuję to utrzymać - możliwość dołączenia woluminu danych do nowej maszyny wirtualnej jest bardzo przydatna .

Mając to na uwadze, nie wyobrażam sobie scenariusza, w którym kiedykolwiek potrzebowalibyśmy lub chcielibyśmy, aby maszyna wirtualna uruchomiła się z woluminu, który musi być GPT, aby przekroczyć limit 2 TB MBR. Fakt, że środowisko jest czysto wirtualne, wydaje się negować zalety odzyskiwania dysków GPT, więc nie mogę wymyślić żadnego istotnego powodu, aby zacząć budować nasze nowe maszyny wirtualne z oprogramowaniem układowym EFI i / lub woluminami rozruchowymi GPT. Oczywiście nie mogę wymyślić żadnych istotnych powodów, aby trzymać się oprogramowania rozruchowego systemu BIOS i dysków MBR, a zatem moje pytanie:

Czy istnieją jakieś istotne zalety (lub wady) korzystania z oprogramowania układowego EFI i dysków rozruchowych GPT w środowisku ESXi? (Przez „godne uwagi” mam na myśli cokolwiek innego niż dobrze znany limit 2 TB dla dysków MBR oraz ograniczenie, że oprogramowanie rozruchowe systemu BIOS musi używać dysków MBR do rozruchu.)

Na froncie BIOS kontra UEFI jest to: https://communities.vmware.com/thread/464854

Pracuję w zespole odpowiedzialnym za tworzenie wirtualnego oprogramowania układowego, w szczególności implementacji wirtualnego EFI.

Nie chcieliśmy, aby EFI był domyślny. Zrozumieliśmy, że popełniliśmy błąd zbyt późno, aby naprawić go w czasie dla vSphere 5.1 GA, a konsekwencje początkowego błędu rozprzestrzeniły się w różnych innych miejscach, w których obecnie zakładano, że EFI ma być domyślny, np. Dokumentacja i zwolnij zabezpieczenie.

Głównym powodem domyślnego powrotu do BIOS-u jest brak obsługi FT - Nie chcieliśmy udostępniać domyślnej konfiguracji, która byłaby niezgodna z FT. Istnieją wtórne powody, takie jak niewielka liczba scenariuszy PCI Passthrough, które działałyby w systemie BIOS, ale zawiodły w EFI, i ogólnie szersza obsługa systemu BIOS w ekosystemie - takie jak rozwiązania wdrażania systemu gościa, rozwiązania odzyskiwania systemu operacyjnego, środowiska rozruchowe PXE i serwer PXE wsparcie i tak dalej.

To wszystko. Był to błąd, który rozprzestrzenił się w sposób, którego nie byliśmy w stanie oczyścić na czas z wersji vSphere 5.1 GA, i jest to najbardziej godne ubolewania, że ​​spowodowało zamieszanie.

Moja rada: jeśli nie potrzebujesz FT, nie będziesz korzystać z PCI Passthrough (lub jeśli możesz sprawdzić, czy twoja konfiguracja PCI Passthrough działa z wirtualnym EFI) i masz niewiele zależności od innych specyficznych dla BIOS-u narzędzi do wdrażania lub zarządzaj swoim systemem operacyjnym, możesz swobodnie wdrażać maszyny wirtualne EFI Windows 2012.

Jednym z miejsc, w których ustawienie EFI dla maszyn wirtualnych jest bardzo przydatne, jest umożliwienie ręcznej konwersji P2V systemów bez systemu metalowego, które zostały zainstalowane przy użyciu EFI, ponieważ EFI nie jest obsługiwany przez VMware Converter (lub nie był, ostatnio sprawdzałem). Zobacz Jak przeprowadzić konwersję P2V systemu EFI systemu Windows Server 2008 R2? na tle tego.