Y a-t-il des avantages (ou des inconvénients) notables à utiliser le micrologiciel EFI et les disques de démarrage GPT dans un environnement ESXi?


10

Ma question de base est, comme le titre le demande: y a-t-il des avantages (ou des inconvénients) notables à utiliser le firmware EFI et les disques de démarrage GPT dans un environnement ESXi? Par "notable", je veux dire autre chose que la limite bien connue de 2 To pour les disques MBR, et la restriction que le microprogramme de démarrage du BIOS doit utiliser les disques MBR pour démarrer.

L'option VM spécifique est dans la capture d'écran ci-dessous.

entrez la description de l'image ici

Au cas où cela ferait une différence, certains antécédents et détails sur mon environnement particulier sont ci-dessous, bien que je m'intéresse au cas général ainsi qu'à tout ce qui se rapporterait spécifiquement ou uniquement à un environnement Windows.


À la suite de quelques projets récents, où j'ai réussi à traîner mes suzerains d'entreprise à $ [day_job] dans la décennie en cours, je remplacerai beaucoup de nos systèmes de bureau à domicile. Ces systèmes, ainsi que leur remplacement, sont principalement des systèmes d'exploitation Windows Server virtualisés sur ESX 5.5 (mise à jour 1 maintenant, bientôt mise à jour 2, et VMFS5, donc prise en charge de gros volumes). Les machines virtuelles, ainsi que tout le stockage auquel elles accèdent, se trouvent sur un SAN (EMC VNX 5400), qui est présenté aux hôtes ESXi via des partages NFS. Tout est peu fourni.

Pour la plupart, je vais simplement mettre à niveau un tas de systèmes PITA volumineux et compliqués vers des plates-formes plus récentes - par exemple, nos serveurs de fichiers multi-TB qui fonctionnent actuellement sur Server 2003 R2 et n'utilisent pas DFS seront mis à niveau vers Server 2012 R2, placez-les dans des espaces de noms DFS, utilisez la réplication DFS et commencez à utiliser la déduplication des données Server 2012. Notre système SharePoint, qui s'exécute actuellement sur Server 2003 R2 et SQL Server 2005, sera mis à niveau vers SharePoint 2013, exécutant Server 2012 R2, et installé sur un moteur SQL Server de 2008 R2 ou supérieur. Etc.

En examinant les serveurs de fichiers et comment gérer la quantité de données qu'ils contiennent (chacun de nos serveurs de fichiers de bureau à domicile contient des données supérieures à 2 To), j'ai examiné et réglé la fonctionnalité de déduplication des données dans le serveur. 2012. Comme cela fonctionne sur une base par volume, cela fonctionne mieux si toutes les données sont un seul volume, au lieu d'être réparties sur plusieurs volumes, comme notre désordre actuel. Cela a soulevé la question des disques GPT étant les meilleurs pour nos volumes de données, et m'a amené à la question du firmware EFI vs BIOS. Nos serveurs ont tous des disques OS [virtuels] de 50 Go qui sont séparés de tous les volumes de données, et au moins pour le moment, je prévois de le garder comme ça - pouvoir attacher un volume de données à une nouvelle VM est assez utile .

Donc, avec cela à l'esprit, je ne peux pas imaginer un scénario où nous aurions besoin ou souhaitons qu'une VM démarre à partir d'un volume qui doit être GPT pour dépasser la limite de disque MBR de 2 To. Le fait que l'environnement soit purement virtuel semble annuler les avantages de récupération des disques GPT, donc je ne peux trouver aucune raison impérieuse de commencer à construire nos nouvelles machines virtuelles avec le firmware de démarrage EFI et / ou les volumes de démarrage GPT. Bien sûr, je ne peux pas non plus trouver de raisons convaincantes de rester avec le firmware de démarrage du BIOS et les disques MBR, et donc, ma question:

Y a-t-il des avantages (ou des inconvénients) notables à utiliser le micrologiciel EFI et les disques de démarrage GPT dans un environnement ESXi? (Par «notable», je veux dire autre chose que la limite bien connue de 2 To pour les disques MBR et la restriction selon laquelle le microprogramme de démarrage du BIOS doit utiliser des disques MBR pour démarrer.)


Voici la réponse définitive de VMware . Il est brillant, faisant autorité et écrit par le même développeur de l'équipe VMware EFI que MichelZ cite ci-dessus.
judoman

Réponses:


4

Sur le front BIOS vs UEFI, il y a ceci: https://communities.vmware.com/thread/464854

Je travaille au sein de l'équipe chargée de développer le firmware virtuel, en particulier l'implémentation EFI virtuelle.

Nous n'avions pas voulu que EFI soit la valeur par défaut. Nous avons réalisé que nous avions fait une erreur trop tard pour la corriger à temps pour vSphere 5.1 GA, et les conséquences de l'erreur initiale s'étaient propagées à divers autres endroits qui avaient maintenant supposé que EFI était censé être la valeur par défaut, comme la documentation et libérer les garanties.

La principale raison de vouloir revenir au BIOS par défaut est le manque de prise en charge FT - Nous ne voulions pas fournir une configuration par défaut qui allait être incompatible avec FT. Il existe des raisons secondaires, telles qu'un petit nombre de scénarios PCI Passthrough qui fonctionneraient sur le BIOS mais échoueraient sur EFI, et une prise en charge généralement plus large du BIOS dans l'écosystème - comme les solutions de déploiement de système d'exploitation invité, les solutions de récupération de système d'exploitation, les environnements de démarrage PXE et le serveur PXE. soutien, etc.

C'est tout ce qu'on peut en dire. C'était une erreur qui s'est propagée d'une manière que nous n'avons pas pu nettoyer à temps pour vSphere 5.1 GA, et il est très regrettable d'avoir causé la confusion.

Mon conseil: si vous n'avez pas besoin de FT, n'utiliserez pas PCI Passthrough (ou si vous pouvez valider que votre configuration PCI Passthrough fonctionne avec EFI virtuel), et avez peu ou pas de dépendances sur d'autres outils spécifiques au BIOS à déployer ou gérer votre système d'exploitation, vous pouvez vous sentir libre de déployer des machines virtuelles EFI Windows 2012.


Welp, c'est parti. EFI et GPT. S'il explose, je vous en veux. :)
HopelessN00b

Anytime @ HopelessN00b :)
MichelZ

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.