Utilisation du micrologiciel EFI / UEFI dans un VMware Virtual Mac … | Communautés VMware

Ce document fournit des informations introductives sur la prise en charge par la plate-forme virtuelle VMware du microprogramme EFI (ou UEFI) au sein d'une machine virtuelle. Cela peut vous aider à décider d'utiliser ou non le micrologiciel EFI lors de la préparation de la création d'une nouvelle machine virtuelle.

EFI (Extensible Firmware Interface) est une spécification pour une nouvelle génération de micrologiciels système. Une implémentation de EFI, stockée dans une mémoire ROM ou Flash RAM, fournit les premières instructions utilisées par le CPU pour initialiser le matériel et passer le contrôle à un système d'exploitation ou à un chargeur de démarrage. Il s’agit d’un successeur extensible du BIOS du PC, qui a été étendu et amélioré de manière relativement peu structurée depuis son introduction. La spécification EFI est portable et les implémentations peuvent être capables de fonctionner sur des plates-formes autres que les PC.

Initialement appelée EFI (Extensible Firmware Interface), la spécification la plus récente s'appelle UEFI (Unified Extensible Firmware Interface), et les deux noms sont utilisés de manière interchangeable. (J'ai tendance à utiliser le nom "EFI" pour tout ce qui a été produit ou défini avant le changement de nom et "UEFI" pour tout ce qui s'est passé depuis le changement de nom.)

Pour plus d'informations, voir la page Wikipedia pour l'interface de microprogramme extensible unifié et le site Web du forum UEFI.

Les produits VMware suivants prennent officiellement en charge l'exécution de machines virtuelles avec le micrologiciel EFI virtuel:

• Fusion 3.0 et plus récent, uniquement lorsque vous exécutez des invités OS X (Mac OS X) ou des installations Windows EFI Boot Camp.
• ESXi 5.0 et plus récent.
• Poste de travail 11.0 et plus récent.
• Joueur 7.0 et plus récent.

D'autres produits ou versions peuvent contenir la possibilité d'exécuter le micrologiciel EFI, sans qu'il s'agisse d'une configuration testée ou officiellement prise en charge.

Non, le microprogramme de l'hôte étant totalement indépendant du microprogramme de la machine virtuelle, les hôtes BIOS peuvent exécuter des machines virtuelles EFI et les hôtes EFI peuvent exécuter des machines virtuelles BIOS. (Notez que les machines virtuelles utilisant des disques physiques, y compris les machines virtuelles Boot Camp de Fusion, doivent utiliser le type de microprogramme correspondant au système d'exploitation installé et au schéma de partition du disque, ce qui signifie généralement qu'il doit correspondre au microprogramme de l'hôte.)

• C'est la voie de l'avenir. Pratiquement toutes les cartes système physiques livrées depuis 2010 sont au format UEFI, et la plupart des principales versions de système d’exploitation prennent désormais en charge [U]EFI dans une certaine mesure.
• Démarrer à partir de> 2 To de volumes. EFI prend en charge GPT (GUID Partition Table), permettant d’amorcer à partir de disques (et partitions) supérieurs à 2 To.
• L'UEFI soutient beaucoup environnement de prédémarrage plus polyvalent. Pour un exemple, regardez Full Disk Encryption (FileVault) dans une machine virtuelle Mac OS récente (10.7+): Un écran d’authentification pré-OS graphique est présenté par le chargeur de démarrage du système d’exploitation, avec prise en charge des animations et de la souris.
• L'UEFI connaît les systèmes de fichiers. La prise en charge en lecture-écriture des systèmes de fichiers FAT / FAT32 signifie qu’un chargeur d’amorçage peut être reconfiguré à partir de l’environnement UEFI – Vous pouvez modifier grub.conf en utilisant un éditeur de texte intégré, même si le système d'exploitation n'est pas démarré!
• Démarrez depuis l'USB. Notre implémentation de BIOS héritée n'a jamais supporté le démarrage USB (pour des raisons longues et compliquées). Notre firmware EFI virtuel le fait.

• Consommation de mémoire supérieure. Lors du démarrage d'un système d'exploitation compatible EFI via EFI au lieu du BIOS, il n'est pas inhabituel de réserver quelques mégaoctets de RAM supplémentaires à l'utilisation du microprogramme. Les machines virtuelles avec des tailles de mémoire très faibles risquent de ne pas répondre aux besoins en mémoire du micrologiciel EFI lui-même! Nous avons choisi 96 Mo comme limite inférieure raisonnable requise par notre microprogramme EFI. Bien entendu, le BIOS démarrerait très confortablement dans une machine virtuelle de 4 Mo, ce qui représente la plus petite configuration autorisée pour notre plate-forme virtuelle!
• Mise en œuvre de firmware moins mature. Soyons honnêtes: la mise en œuvre de VMware EFI présente encore quelques aspérités, notamment en ce qui concerne l'interface utilisateur du micrologiciel lui-même (c'est-à-dire la configuration du BIOS). Nous y travaillons, mais nous n'y sommes pas encore. Nous nous sommes efforcés de rendre les choses aussi robustes que possible, pas jolies.
• Mise en œuvre de système d'exploitation invité moins mature. Un ordinateur virtuel est susceptible de présenter des défauts dans le système d'exploitation invité qui pourraient rendre l'invité non démarrable ou difficile à configurer sur EFI. Les fournisseurs de systèmes d'exploitation ne testent pas le démarrage EFI aussi souvent qu'ils le font auparavant, et les implémentations de système d'exploitation ont tendance à être initialement compatibles avec les systèmes détenus par les auteurs du support EFI du système d'exploitation. De nombreux systèmes d'exploitation invités réclament une prise en charge EFI mais présentent des défauts catastrophiques qui pourraient entraîner l'échec du démarrage du programme d'installation, l'échec de l'installation du système d'exploitation, l'échec de l'initialisation sur le système d'exploitation installé ou l'échec de l'exécution du système d'exploitation. .
• Nouveau facteur de complication: EFI soutient deux des architectures, IA32 32 bits et X64 64 bits. Notre EFI virtuel peut fonctionner dans l'une ou l'autre architecture, comme contrôlé par le choix du système d'exploitation invité. X64 est beaucoup plus communément pris en charge par les systèmes d’exploitation et correspond à la plupart des systèmes physiques actuels. L'architecture EFI doit correspondre à l'architecture du chargeur de démarrage du système d'exploitation, qui correspond généralement à l'architecture du système d'exploitation lui-même.
• Soutien de l'industrie moins mature dans son ensemble. Votre serveur PXE sait-il comment gérer les clients EFI? Votre outil de création d'image disque sait-il comment gérer le format de table de partition GUID utilisé par EFI sur disque? Votre outil de chiffrement de disque entier tiers prend-il en charge EFI ou est-ce uniquement du BIOS?
• Nouveau mode de gestion de la commande de démarrage. EFI utilise une liste de systèmes d'exploitation amorçables, stockés dans la NVRAM (mémoire non volatile), pour contrôler son processus de démarrage. Les capacités et les techniques de gestion diffèrent des machines virtuelles BIOS. Plus important encore, la NVRAM de votre machine virtuelle devient un élément critique de votre machine virtuelle, en particulier pour les machines virtuelles Linux. Si votre flux de travail n'est pas prêt pour cela, c'est un risque.

• les fenêtres: Microprogramme EFI 64 bits pris en charge avec Vista (SP1 et versions ultérieures), Windows Server 2008 et versions ultérieures. Prise en charge EFI 32 bits ajoutée à Windows 8 et versions ultérieures.
• Linux: En fonction de la distribution, de l'architecture, de la version et du support source. Voir ci-dessous.
• OS X: Depuis Mac OS X Server 10.5, sous réserve des contraintes habituelles applicables au matériel hôte et au produit de virtualisation: Fusion ou ESXi sur du matériel Apple. OS X a besoin Micrologiciel EFI.
• Solaris: Depuis Oracle Solaris 11.1.
• ESXi: Depuis vSphere 5.0.
• FreeBSD: Pas encore, bien qu'ils y travaillent. FreeBSD 10 inclut un chargeur de démarrage EFI, mais il contient un défaut de compatibilité qui l’échoue sur notre plate-forme.

Qu'en est-il de Linux?

C'est difficile à dire. Le noyau Linux supporte EFI depuis longtemps, mais il appartient à chaque distribution de l'activer et de fournir le reste du support nécessaire.

Commençons par les distributions les plus courantes:

• Redhat Enterprise Linux 6.0 et les versions plus récentes incluent le support EFI dans leurs versions 64 bits (x86_64) uniquement.
• Ubuntu 10.10 et les versions plus récentes incluent le support EFI dans leurs versions 64 bits (amd64) uniquement.
• Oracle Linux 6.0 et les versions plus récentes incluent le support EFI dans leurs versions 64 bits (x86_64) uniquement.
• Feutre 11 et plus récentes ont inclus la prise en charge EFI dans les versions 32 bits (i386) et 64 bits (x86_64), mais:
  • le chargeur de démarrage Fedora 12 x86_64 a un défaut catastrophique et ne fonctionne pas sur notre plate-forme; et
  • avant Fedora 15, le chargeur de démarrage EFI était uniquement sur le netinst médias; et
  • Fedora 15 et les versions plus récentes ne prennent en charge que le format EFI 64 bits – ils ont abandonné le support pour EFI de leurs versions 32 bits (i386).
• CentOS 6.3 et plus récents incluent le support EFI. Les versions précédentes de la série 6.x incluent un support EFI défectueux.
• SuSE Linux Enterprise Server 11 SP1 était la première version de SuSE à inclure la prise en charge fonctionnelle EFI, uniquement sur leur support 64 bits (x86_64). La version de bureau a suivi dans SLED 11 SP2, mais uniquement dans le support 64 bits (x86_64) (SLED 11 SP1 essayé, mais il était défectueux).
• OpenSuSE 12.1 et les versions plus récentes incluent le support EFI dans leurs versions 64 bits (x86_64) uniquement. OpenSuSE 11.3 et les versions plus récentes incluaient un support EFI défectueux.

Comme vous pouvez le voir, tout est partout. Cette liste n’est certainement pas exhaustive, aussi les distributions qui ne figurent pas sur cette liste pourraient-elles toujours prendre en charge EFI … Le meilleur moyen de le savoir est de l’essayer et de le voir. (Si vous souhaitez une liste exhaustive, n'hésitez pas à vous porter volontaire pour toutes les essayer. )

Certaines des implémentations les plus anciennes de la liste ci-dessus sont un peu rugueuses et peuvent se comporter de manière inattendue.

De quoi une distribution Linux a-t-elle besoin pour fonctionner avec EFI?

L'installation réussie d'invités Linux sous EFI dépend généralement du distributeur qui fournit certaines exigences minimales pour un système d'exploitation prenant en charge EFI:

• Support contenant une image amorçable El Torito;
• Un chargeur de démarrage EFI bien formé de l’architecture appropriée (IA32 ou X64) situé à l’emplacement approprié dans cette image El Torito, avec tous les fichiers de support dont il a besoin.
• Un noyau construit avec le support EFI (CONFIG_EFI = y)
• Un programme d'installation connaissant EFI: il partitionne le disque avec GPT, crée une partition système EFI, installe un chargeur de démarrage EFI et configure l'ordre de démarrage dans EFI NVRAM (mémoire non volatile) pour contenir le chargeur de démarrage du système d'exploitation.

La disponibilité de ces composants est quelque peu imprévisible et ils sont parfois livrés avec des défauts affectant leur capacité à fonctionner correctement.

Les modes d'échec peuvent inclure des blocages d'invités ou des blocages avant ou pendant l'installation, des échecs de recherche ou de lancement du programme d'installation, des échecs du programme d'installation lui-même, un échec de recherche du système d'exploitation installé lors du redémarrage à la fin de l'installation et, rarement, des problèmes d'exécution. dans le système d'exploitation installé.

Qu'en est-il des systèmes d'exploitation existants qui ne sont pas compatibles avec EFI?

Vous devrez configurer la machine virtuelle pour utiliser le BIOS.

De nombreux systèmes EFI physiques incluent un module de support de compatibilité (CSM) qui leur permet de charger des systèmes d'exploitation non compatibles avec EFI. Le CSM fournit une interface compatible avec le BIOS qui fonctionne conjointement avec EFI, ce qui permet au système de se comporter comme le BIOS classique et permet aux anciens systèmes d'exploitation de fonctionner normalement. Une plate-forme avec un CSM est souvent appelée plate-forme UEFI Classe 2.

L'utilisation du MSC est généralement découragée et on s'attend à ce qu'ils disparaissent des systèmes physiques EFI dans un proche avenir.

La plate-forme virtuelle VMware ne prend pas en charge l'utilisation d'un module de support de compatibilité, ce qui signifie que les systèmes d'exploitation qui ne sont pas compatibles avec EFI ne peuvent être démarrés qu'en configurant la machine virtuelle pour utiliser le BIOS. Lorsqu'une machine virtuelle est configurée pour utiliser le micrologiciel EFI virtuel, il s'agit d'une plate-forme "UEFI pure" ne disposant pas d'un CSM, souvent appelée plate-forme UEFI de classe 3. (Une petite quantité de code de compatibilité est nécessaire pour démarrer les versions antérieures de Windows sur notre microprogramme EFI virtuel. Toutefois, il ne s'agit pas d'un module de prise en charge de la compatibilité complète.)

En conséquence, vous ne pouvez pas utiliser le micrologiciel EFI virtuel pour effectuer un démarrage USB d'invités hérités.

Matériel virtuel requis:

• Au moins 96 Mo de RAM.
• Au moins la version matérielle 7. La version matérielle 8 ou ultérieure est recommandée en raison d'un périphérique de mémoire vive virtuelle non volatile (NVRAM) améliorée qui est plus robuste contre les défaillances d'invité.

Certains matériels virtuels ne sont pas pris en charge par EFI lui-même:

• Carte réseau virtuelle vmxnet2: sera ignorée par le microprogramme EFI. Le démarrage EFI PXE via vmxnet2 n'est pas possible. Toutefois, un invité démarré par EFI peut toujours utiliser un contrôleur vmxnet2 au moment de l'exécution.
• Port parallèle: sera initialisé puis ignoré par le micrologiciel EFI. Toutefois, un SE invité démarré par EFI peut toujours utiliser un port parallèle au moment de l'exécution.
• Périphériques audio: Notre implémentation EFI ne peut utiliser aucun périphérique audio. Toutefois, un système d'exploitation invité démarré par EFI peut toujours utiliser un périphérique audio pris en charge au moment de l'exécution.

Tous les autres matériels virtuels (contrôleurs de stockage, contrôleurs de réseau, contrôleurs USB1 / 2/3, cartes graphiques, processeurs et mémoire, par exemple) peuvent être utilisés dans EFI.

Vérifiez que les produits / solutions interopérables sont compatibles avec EFI. À noter pour les utilisateurs de vSphere: VMware Fault Tolerance (FT) n’est actuellement pas compatible avec le micrologiciel EFI.

Vous doit faites ce choix avant d'installer le système d'exploitation.

Sur VMware Workstation, entrez dans VM > Réglages > Les options > Avancée, et vérifie Démarrer avec EFI au lieu du BIOS.

Sur VMware Fusion, le micrologiciel EFI est automatiquement sélectionné pour les invités Mac OS. Vous n'avez pas besoin de faire quoi que ce soit.

Sous ESXi à l’aide de vSphere Web Client, accédez à Modifier les paramètres > Options de VM > Options de démarrageet choisissez sous le Micrologiciel section.

Sous ESXi à l’aide de vSphere Client, accédez à Modifier les paramètres > Les options > Options de démarrageet choisissez sous le Micrologiciel section.

Sur n'importe lequel de nos produits prenant en charge EFI, vous pouvez également modifier manuellement le fichier de configuration de la machine virtuelle pour ajouter la ligne.

firmware = "efi"

configurer une machine virtuelle pour EFI. Les interfaces utilisateur ci-dessus font exactement cela pour vous. Vous pouvez utiliser cette méthode si vous souhaitez jouer avec EFI dans des configurations que nous ne prenons pas officiellement en charge (telles que Linux sur EFI dans Fusion 7), mais bien entendu, les choses pourraient très bien se rompre.

Ne fais pas ça.

Lors de l'installation, le système d'exploitation invité doit décider de préparer le disque virtuel avec un schéma de partition et un chargeur de démarrage adaptés au BIOS ou à EFI. Changer le micrologiciel entre BIOS et EFI après l'installation rendra la machine virtuelle non amorçable. Remettez le micrologiciel dans sa configuration précédente afin de restaurer la possibilité de démarrer le système d'exploitation.

Si vous souhaitez utiliser un outil de partitionnement, un disque de secours ou un outil similaire nécessitant un microprogramme différent du système d'exploitation installé, vous devrez peut-être basculer temporairement entre le BIOS et EFI. Si vous faites cela, encore une fois, rétablissez la configuration antérieure du microprogramme lorsque vous avez terminé, afin de rétablir la possibilité de démarrer le système d'exploitation installé.

Faites attention si vous faites ça. La plate-forme virtuelle VMware choisit l'architecture EFI (IA32 ou X64) en fonction du type de système d'exploitation invité. En règle générale, le système d'exploitation fonctionne avec et installe une seule architecture de chargeur de démarrage – IA32 ou X64 – en fonction de l'architecture de microprogramme utilisée lors de l'installation. Si vous essayez de démarrer un système d'exploitation avec une architecture de microprogramme incorrecte, le démarrage échouera presque certainement. Si vous avez installé Ubuntu 64 bits avec le type de système d'exploitation invité configuré accidentellement sur "Autre noyau Linux 3.x 64 bits", le remplacement de "Ubuntu 64 bits" ne posera pas de problème. Si vous le changez en "Ubuntu" (32 bits), le système d'exploitation ne pourra plus être démarré jusqu'à ce que vous le basculiez vers un type de système d'exploitation invité 64 bits. Si vous avez essayé d'installer Ubuntu 64 bits avec le type de système d'exploitation invité défini sur "Ubuntu" ou "Autre noyau Linux 3.x" (les deux versions 32 bits), le programme d'installation du système d'exploitation n'aurait pas réussi à démarrer en premier lieu … et vous pouvez basculer le type de système d'exploitation invité sur "Ubuntu 64 bits", puis démarrer la machine virtuelle dans le programme d'installation.

UEFI Secure Boot est pris en charge depuis vSphere 6.5 (pour les hôtes physiques ESXi et les machines virtuelles).

La spécification UEFI donne aux vendeurs beaucoup de latitude pour étendre le microprogramme, ainsi que pour implémenter (ou omettre) certaines parties optionnelles de la spécification UEFI. Parfois, les fournisseurs de systèmes d'exploitation se retrouvent involontairement en fonction de caractéristiques de leurs systèmes de développement et de test qui ne font pas partie de la spécification UEFI, limitant ainsi la compatibilité de leur système d'exploitation.

Le cas le plus fréquent que nous ayons vu est celui des fournisseurs de systèmes d’exploitation plaçant le chargeur de démarrage EFI pour le support d’installation sur un système de fichiers ISO9660 ou UDF au lieu d’une partition El Torito. La spécification UEFI ne nécessite pas la capacité de lire un système de fichiers ISO9660 ou UDF, bien que certains fournisseurs de matériel et de plates-formes virtuelles incluent néanmoins des pilotes pour ces systèmes de fichiers. Tous les systèmes d'exploitation qui dépendent de la présence d'un pilote ISO9660 ou UDF restreindront considérablement les plates-formes sur lesquelles ils peuvent s'exécuter, et de tels systèmes d'exploitation ne s'exécutent pas sur une machine virtuelle VMware.

Le cas le plus fréquent que nous ayons rencontré est celui des fournisseurs de systèmes d’exploitation dépendant accidentellement d’anciennes interfaces BIOS (ou CSM) lors du démarrage sur le micrologiciel EFI. Ces systèmes d’installation s’installeront généralement avec succès sur certains systèmes dotés d’un CSM ou même sur des systèmes dotés d’une couche d’émulation EFI au-dessus du BIOS, mais échoueront sur les plates-formes UEFI de classe 3 dépourvues de couche de compatibilité, telle que le micrologiciel EFI virtuel VMware.

Il peut également s'agir simplement d'un défaut du microprogramme EFI virtuel VMware ou d'un défaut spécifique à la plate-forme du système d'exploitation lui-même… les moyens d'échec ne manquent pas. En cas de doute, démarrez un nouveau fil de discussion dans le forum approprié pour votre produit ou envoyez une demande d'assistance, selon le cas.

Il se peut que le système d'exploitation ne prenne pas en charge EFI, que sa prise en charge EFI soit défectueuse ou que le microprogramme EFI virtuel VMware présente un défaut. Une partie de la discussion ci-dessus peut vous aider à déterminer ce qui se passe.

En cas de doute, démarrez un nouveau fil de discussion dans le forum approprié pour votre produit ou envoyez une demande d'assistance, selon le cas.