Ci sono notevoli vantaggi (o svantaggi) nell'uso del firmware EFI e dei dischi di avvio GPT in un ambiente ESXi?


10

La mia domanda di base è, come il titolo chiede: ci sono notevoli vantaggi (o svantaggi) nell'uso del firmware EFI e dei dischi di avvio GPT in un ambiente ESXi? Per "notevole" intendo qualcosa di diverso dal noto limite di 2 TB per i dischi MBR e la restrizione che il firmware di avvio del BIOS deve utilizzare i dischi MBR per l'avvio.

L'opzione VM specifica è nello screenshot seguente.

inserisci qui la descrizione dell'immagine

Nel caso in cui faccia la differenza, alcuni retroscena e specifiche sul mio ambiente particolare sono di seguito, anche se sono interessato al caso generale, nonché a qualsiasi cosa che riguardi specificamente o solo un ambiente Windows.


Come risultato di alcuni progetti recenti, in cui sono riuscito a trascinare i miei signori dell'azienda a $ [day_job] nell'ultimo decennio, sostituirò molti dei nostri sistemi di home office. Questi sistemi, oltre a quelli a cui devono essere sostituiti, sono principalmente i sistemi operativi Windows Server virtualizzati su ESX 5.5 (aggiornamento 1 ora, che presto diventerà aggiornamento 2, e VMFS5, supporto per volumi così grandi). Le macchine virtuali, così come tutto l'archiviazione a cui accedono, si trovano su una SAN (EMC VNX 5400), che viene presentata agli host ESXi tramite condivisioni NFS. Tutto è sottoposto a thin provisioning.

Per la maggior parte, aggiornerò semplicemente un sacco di sistemi PITA di grandi dimensioni e complicati a piattaforme più recenti - ad esempio, i nostri file server multi-TB attualmente in esecuzione su Server 2003 R2 e che non utilizzano DFS verranno aggiornati a Server 2012 R2, essere inserito negli spazi dei nomi DFS, utilizzare la replica DFS e iniziare a utilizzare la deduplicazione dei dati Server 2012. Il nostro sistema SharePoint, attualmente in esecuzione su Server 2003 R2 e SQL Server 2005, verrà aggiornato a SharePoint 2013, eseguendo Server 2012 R2 e inserendo un motore SQL Server di 2008 R2 o versioni successive. E così via.

Osservando i file server e come gestire la quantità di dati su di essi (ognuno dei nostri file server dell'home office ha dati superiori a 2 TB), ho esaminato e accolto la funzionalità di deduplicazione dei dati in Server 2012. Dal momento che funziona su una base per volume, funziona meglio se tutti i dati sono costituiti da un solo volume, anziché divisi su più volumi, come il nostro pasticcio attuale. Ciò ha sollevato il problema dei dischi GPT come migliori per i nostri volumi di dati e mi ha portato alla domanda del firmware EFI vs BIOS. Tutti i nostri server dispongono di dischi OS [virtuali] da 50 GB che sono separati da qualsiasi volume di dati e, al momento, sto pianificando di mantenerlo in questo modo: essere in grado di collegare un volume di dati a una nuova macchina virtuale è piuttosto utile .

Quindi, con questo in mente, non riesco a immaginare uno scenario in cui avremmo mai bisogno o desideriamo che una VM si avvii da un volume che deve essere GPT per superare il limite del disco MBR da 2 TB. Il fatto che l'ambiente sia puramente virtuale sembra negare i vantaggi della recuperabilità dei dischi GPT, quindi non riesco a trovare alcun motivo convincente per iniziare a costruire le nostre nuove macchine virtuali con firmware di avvio EFI e / o volumi di avvio GPT. Naturalmente, non riesco nemmeno a trovare motivi convincenti per attaccare con il firmware di avvio del BIOS e i dischi MBR, e quindi la mia domanda:

Ci sono notevoli vantaggi (o svantaggi) nell'uso del firmware EFI e dei dischi di avvio GPT in un ambiente ESXi? (Per "notevole" intendo qualcosa di diverso dal noto limite di 2 TB per i dischi MBR e la limitazione che il firmware di avvio del BIOS deve utilizzare i dischi MBR per l'avvio.)


Ecco la risposta definitiva di VMware . È geniale, autorevole e scritto dallo stesso sviluppatore del team EFI VMware che MichelZ cita sopra.
Judoman,

Risposte:


4

Sul fronte BIOS vs UEFI, c'è questo: https://communities.vmware.com/thread/464854

Lavoro nel team responsabile dello sviluppo del firmware virtuale, in particolare dell'implementazione EFI virtuale.

Non intendevamo che EFI fosse l'impostazione predefinita. Ci siamo resi conto che avevamo fatto un errore troppo tardi per correggerlo in tempo per vSphere 5.1 GA, e le conseguenze dell'errore iniziale si erano propagate in vari altri luoghi che ora avevano supposto che EFI fosse inteso come predefinito, come la documentazione e rilasciare garanzie.

Il motivo principale per voler tornare al BIOS per impostazione predefinita è la mancanza del supporto FT: non desideravamo fornire una configurazione predefinita incompatibile con FT. Esistono ragioni secondarie, come un piccolo numero di scenari PCI Passthrough che funzionerebbero sul BIOS ma fallire su EFI e un supporto generalmente più ampio per il BIOS nell'ecosistema - come soluzioni di distribuzione del SO guest, soluzioni di recupero del SO, ambienti di boot PXE e server PXE supporto e così via.

Questo è tutto quello che c'è da fare. È stato un errore che si è propagato in un modo che non siamo riusciti a ripulire in tempo per vSphere 5.1 GA, ed è deplorevole che ha causato la confusione che ha fatto.

Il mio consiglio: se non hai bisogno di FT, non utilizzerai PCI Passthrough (o se puoi confermare che la tua configurazione PCI Passthrough funziona con EFI virtuale) e avere poche o nessuna dipendenza da altri strumenti specifici del BIOS per distribuire o gestire il tuo sistema operativo, puoi sentirti libero di distribuire VM EFI Windows 2012.


Welp, ci siamo andati. EFI e GPT. Se esplode, ti darò la colpa. :)
HopelessN00b

Anytime @ HopelessN00b :)
MichelZ,

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.