J'ai été un grand partisan de l'approvisionnement basé sur le réseau pendant presque toute ma carrière. Mon deuxième travail en dehors de l'université consistait à imager environ 800 ordinateurs plusieurs fois par semaine. Lorsque j'ai été embauché, mes prédécesseurs utilisaient des disquettes pour charger un petit système d'exploitation (OS), un pilote de carte d'interface réseau (NIC) et un client d'imagerie (vous vous souvenez de Ghost ?). En fin de compte, cela demandait beaucoup de temps et de main-d'œuvre et un processus horrible. L'imagerie d'un groupe de systèmes a pris environ 30 à 60 minutes. Pour faire court, nous avons réduit ce temps à environ cinq minutes après avoir utilisé une combinaison de pilotes PXE, Wake-on-LAN, Universal Network Device Interface (UNDI), de réseaux locaux virtuels (VLAN) et de surveillance IGMP. Ma deuxième itération de la solution a pris le temps total de présence à moins de 30 secondes. C'est une technologie incroyable pour le provisionnement et j'ai même été embauché chez Red Hat en donnant une présentation sur l'environnement d'exécution de pré-démarrage (PXE). Inutile de dire que je suis un grand fan.
[ Vous pourriez également apprécier : Créer un système de bureau Linux multi-boot ]
Quoi qu'il en soit, le problème ici est que PXE remonte aux années 90 et est assez limité par sa dépendance à des technologies telles que le protocole de transfert de fichiers trivial (TFTP). Intel menace de déprécier PXE depuis des années maintenant, et ils le font enfin. Même si PXE est omniprésent aujourd'hui, il est probable qu'au cours des 2 à 10 prochaines années, le démarrage HTTP UEFI deviendra la valeur par défaut pour la plupart des environnements. D'autres avantages et détails techniques sont décrits ici. Le TL;DR est un PXE qui repose sur DHCP et TFTP, et le démarrage HTTP de l'interface UEFI (Unified Extensible Firmware Interface) nécessite DHCP et HTTP. Cela semble facile ? C'est parce que c'est le cas. Vous pourriez même dire que c'est aussi trivial que les protocoles de transfert de fichiers. Désolé, l'humour sur le démarrage du réseau est assez difficile à trouver.
Passer du démarrage PXE au démarrage HTTP
La meilleure documentation que je puisse trouver sur ce sujet actuellement est donnée ci-dessous dans la section Références. Essentiellement, le besoin de TFTP est abandonné. Modifiez ensuite les options DHCP pour récupérer le NBP à partir d'un point de terminaison HTTP/HTTPS. J'utilise GRUB comme NBP dans cet article. Environnements utilisant dhcpd pouvez simplement déposer la configuration qu'ils fournissent, et tout devrait fonctionner en supposant que vous modifiez le filename pour pointer vers le NBP correct pour votre environnement :
class "pxeclients" {
match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
next-server 192.168.111.1;
filename "/bootx64.efi";
}
class "httpclients" {
match if substring (option vendor-class-identifier, 0, 10) = "HTTPClient";
option vendor-class-identifier "HTTPClient";
filename "http://www.httpboot.local/sle/EFI/BOOT/bootx64.efi";
} Cet exemple est intéressant car il permet également aux systèmes UEFI avec une ROM PXE héritée de démarrer.
Appliquez ceci à libvirt
J'avais initialement prévu de le configurer sur mon réseau domestique, mais pfSense ne le prend pas encore en charge et n'autorise pas non plus le dhcpd configuration à modifier directement. J'ai ouvert un sujet, et j'espère que cela sera ajouté à l'avenir. La prochaine option la plus simple que j'ai pour tester consiste à utiliser libvirt et des machines virtuelles (VM) avec le micrologiciel UEFI Open Virtual Machine Firmware (OVMF) (Tianocore). De plus, libvirt fonctionne très bien pour créer un environnement autonome pour expérimenter une technologie comme celle-ci et il est très facile à reproduire. Tout ce que vous avez à faire est de fournir les bonnes options DHCP.
Le réseau libvirt par défaut ressemblera à ceci :
<network>
<name>default</name>
<uuid>75f4d9cd-9af2-4df5-afcc-f8f9145f7e34</uuid>
<forward mode='nat'/>
<bridge name='virbr0' zone='trusted' stp='on' delay='0'/>
<mac address='52:54:00:95:95:84'/>
<ip address='192.168.122.1' netmask='255.255.255.0'>
<dhcp>
<range start='192.168.100.128' end='192.168.100.254' />
</dhcp>
</ip>
</network> L'activation de l'ancien PXE est bien documentée, mais j'inclus les modifications ici au cas où cela serait utile à quiconque lit. Vous devez définir les options DHCP du serveur suivant et du nom de fichier.
<network>
<name>default</name>
<uuid>75f4d9cd-9af2-4df5-afcc-f8f9145f7e34</uuid>
<forward mode='nat'/>
<bridge name='virbr0' zone='trusted' stp='on' delay='0'/>
<mac address='52:54:00:95:95:84'/>
<ip address='192.168.122.1' netmask='255.255.255.0'>
<tftp root='/var/lib/tftpboot'/>
<dhcp>
<range start='192.168.100.128' end='192.168.100.254' />
<bootp file='pxelinux.0'/>
</dhcp>
</ip>
</network> Malheureusement, le schéma libvirt ne prend pas en charge de nombreuses options de configuration disponibles pour dnsmasq. Heureusement, les versions récentes de libvirt prennent en charge un espace de noms XML qui ajoutera des options directement au bas du fichier de configuration généré. Cet e-mail montre la seule configuration dnsmasq fonctionnelle que j'ai pu trouver, car le démarrage HTTP n'est pas bien documenté pour le projet. Pour l'instant, je laisse les informations TFTP en place afin que les machines virtuelles utilisant le BIOS puissent continuer à effectuer des installations réseau.
Remarque :N'ignorez pas la première ligne de cet exemple.
<network xmlns:dnsmasq='http://libvirt.org/schemas/network/dnsmasq/1.0'>
<name>default</name>
<uuid>75f4d9cd-9af2-4df5-afcc-f8f9145f7e34</uuid>
<forward mode='nat'/>
<bridge name='virbr0' zone='trusted' stp='on' delay='0'/>
<mac address='52:54:00:95:95:84'/>
<ip address='192.168.122.1' netmask='255.255.255.0'>
<tftp root='/var/lib/tftpboot'/>
<dhcp>
<range start='192.168.100.128' end='192.168.100.254' />
<bootp file='pxelinux.0'/>
</dhcp>
</ip>
<dnsmasq:options>
<dnsmasq:option value='dhcp-vendorclass=set:efi-http,HTTPClient:Arch:00016'/>
<dnsmasq:option value='dhcp-option-force=tag:efi-http,60,HTTPClient'/>
<dnsmasq:option value='dhcp-boot=tag:efi-http,"http://192.168.122.1/rhel8/EFI/BOOT/BOOTX64.EFI"'/>
</dnsmasq:options>
</network>
Avec les paramètres réseau en place, un simple sudo virsh net-destroy default && sudo virsh net-start default chargera la nouvelle configuration. Ensuite, vous avez besoin d'un serveur Web. J'utilise httpd sur mon système. Comme vous pouvez le voir, il est défini dans l'exemple ci-dessus comme 192.168.122.1. L'un des principaux avantages de cette configuration est que le point de terminaison Web peut se trouver n'importe où. Veuillez donc utiliser ce qui convient à votre environnement. Pour des raisons que je ne comprends pas, Silverblue inclut httpd; tout ce que j'avais à faire sur mon système était d'exécuter systemctl start httpd .
Configuration du menu de démarrage
Étant donné que je travaille avec la version bêta de Red Hat Enterprise Linux (RHEL) 8.4, tout ce qui est nécessaire est de télécharger le minimum boot.iso , montez-le et copiez le contenu dans /var/www/html/rhel8/ . Ne montez pas l'ISO directement à cet emplacement, car vous devez modifier la configuration GRUB et écrire le fichier. Ensuite, vous devez modifier le noyau et initrd chemins dans la configuration GRUB par défaut trouvée sous /var/www/html/rhel8/EFI/BOOT/grub.cfg car les chemins relatifs ne fonctionneront pas. Pour ma configuration, il faut ajouter /rhel8 sur chaque ligne. Passez toute autre option nécessaire et vous êtes prêt à partir.
menuentry 'Install Red Hat Enterprise Linux 8.4' --class fedora --class gnu-linux --class gnu --class os {
linuxefi /rhel8/images/pxeboot/vmlinuz inst.stage2=http://192.168.122.1/rhel8 inst.ks=http://192.168.122.1/ks/84.ks quiet
initrdefi /rhel8/images/pxeboot/initrd.img
} Il est temps de démarrer
Vous êtes maintenant prêt à créer et à démarrer une machine virtuelle, ce qui conduit à la partie ennuyeuse. Par défaut, un démarrage réseau avec OVMF tentera un IPv4 PXE -> IPv6 PXE -> IPv4 HTTP -> IPv6 HTTP dans cet ordre. Il faut beaucoup de temps pour les laisser échouer, vous voudrez donc perturber le processus de démarrage standard en appuyant rapidement sur Échap clé à plusieurs reprises une fois que la console VM apparaît pour sélectionner manuellement le HTTP IPv4. Dans le screencast lié ci-dessous, j'appuie sur Échap rapidement pour sélectionner l'option correcte. C'est loin d'être idéal, et je suis sûr qu'il existe une meilleure façon de configurer le micrologiciel pour désactiver la ou les options héritées. S'il vous plaît laissez-moi savoir si vous savez comment faire cela.
sudo virt-install \
--name=8.4-uefi-httpboot \
--ram=2048 \
--vcpus=1 \
--os-type=linux \
--os-variant=rhel8.4 \
--graphics=vnc \
--pxe \
--disk=path=/var/home/bbreard/data/distros/uefi.qcow2 \
--check path_in_use=off \
--network=network=default,model=virtio \
--boot=uefi [ Cours gratuit :Présentation technique de Red Hat Satellite. ]
Récapitulez
Si vous allez sur mon site, vous pouvez regarder un screencast du processus. C'est simple et rapide. Et c'est tout ce qu'il y a à faire. J'espère que vous vous joindrez à moi dans un monde libéré des limitations du TFTP.
Références :
- Activation du plug-in HTTPBoot pour Foreman 1.20
- UEFI_HTTPBoot_Server_Setup
- Démarrage HTTP UEFI avec Libvirt
- Démarrage HTTP EFI avec dnsmasq
- page de manuel dnsmasq