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


10

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.

wprowadź opis zdjęcia tutaj

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.)


Oto ostateczna odpowiedź VMware . Jest genialny, autorytatywny i napisany przez tego samego twórcę VMware EFI, który MichelZ cytuje powyżej.
judoman

Odpowiedzi:


4

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.


Welp, poszedł po to. EFI i GPT. Jeśli wybuchnie, będę cię winić. :)
HopelessN00b

Anytime @ HopelessN00b :)
MichelZ

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.