Introduction
L’administration des machines virtuelles ne se limite pas à créer et démarrer un domaine. Les administrateurs doivent souvent reprendre une machine virtuelle existante et modifier sa définition persistante : augmenter la mémoire, ajouter des processeurs virtuels, connecter un espace de stockage, activer le démarrage automatique et vérifier que l’état d’exécution correspond bien à la configuration demandée.
Dans la terminologie de libvirt, une machine virtuelle est appelée un domaine. Un domaine persistant possède une définition enregistrée — autrement dit, le schéma matériel de la machine — même lorsqu’aucun processus QEMU ne s’exécute. Le démarrage du domaine crée une instance en cours d’exécution à partir de cette définition ; son arrêt supprime l’instance active, mais conserve le schéma. La distinction entre configuration persistante et état d’exécution constitue l’idée centrale de cet atelier.
Dans cet atelier, un domaine libvirt arrêté nommé lfcs-config est déjà défini avec un petit disque de démarrage, 64 MiB de mémoire et un seul vCPU. Vous allez examiner cette configuration initiale, puis utiliser les commandes de gestion des ressources de virsh pour la reconfigurer. L’environnement ne fournit pas /dev/kvm : QEMU utilise donc une émulation logicielle, et les disques ne contiennent aucun système d’exploitation invité. Le processus d’administration et la configuration persistante de libvirt sont néanmoins réels.
Examiner la configuration existante du domaine
Dans cette étape, vous allez relever la configuration persistante et l’état d’exécution du domaine lfcs-config avant d’effectuer des modifications.
Accédez au répertoire du projet.
cd /home/labex/project
Affichez la liste de tous les domaines. L’option --all inclut les domaines arrêtés ; lfcs-config devrait donc apparaître avec l’état shut off.
sudo virsh list --all
Sans --all, virsh list affiche normalement uniquement les domaines actifs. La présence d’un domaine arrêté dans cette liste étendue confirme que libvirt connaît toujours sa définition persistante, même si la machine virtuelle ne consomme pas de temps processeur en tant qu’invité en fonctionnement.
Affichez le résumé du domaine.
sudo virsh dominfo lfcs-config
dominfo regroupe les informations d’identité, de cycle de vie, de processeur, de mémoire, de persistance et de démarrage automatique. À ce stade, considérez ces données comme une référence initiale plutôt que comme un objectif : les résultats ultérieurs ne devraient changer que dans les champs que vous aurez volontairement reconfigurés.
Concentrez-vous sur les champs de configuration stables :
Name: lfcs-config
State: shut off
CPU(s): 1
Max memory: 65536 KiB
Used memory: 65536 KiB
Persistent: yes
Autostart: disable
Libvirt exprime ici la mémoire en KiB. Comme 1 MiB équivaut à 1024 KiB, 65536 KiB correspondent à 64 MiB. Persistent: yes signifie que la définition est conservée après l’arrêt, tandis que Autostart: disable indique que libvirt ne démarrera pas automatiquement ce domaine lors du lancement de son service de virtualisation.
Affichez les périphériques de bloc associés. vda est le disque racine préparé, dont la source est l’image qcow2 existante.
sudo virsh domblklist lfcs-config --details
Dans ce tableau, Target désigne le nom du périphérique présenté à l’invité, tandis que Source indique le chemin hôte où sont stockées ses données. Le disque virtio nommé vda joue le rôle d’un lecteur virtuel connecté à la machine virtuelle ; le fichier source qcow2 constitue l’image de ce lecteur sur l’hôte.
Cette configuration initiale permet de distinguer les éléments déjà présents des modifications de ressources que vous effectuerez aux étapes suivantes.
Configurer la mémoire persistante et les vCPU
Dans cette étape, vous allez augmenter la mémoire maximale persistante du domaine, la quantité de mémoire allouée au démarrage suivant et le nombre de vCPU, alors que le domaine est arrêté.
Libvirt distingue la limite maximale de mémoire de la quantité attribuée lors du prochain démarrage. Commencez par définir la mémoire maximale persistante à 128 MiB. L’option --config modifie la définition enregistrée du domaine plutôt qu’une valeur temporaire liée à l’exécution.
sudo virsh setmaxmem lfcs-config 128M --config
La limite doit être suffisamment élevée pour contenir la quantité de mémoire attribuée. Considérez max memory comme la capacité mémoire de la machine virtuelle et current memory comme la quantité demandée pour son utilisation normale. Comme le domaine est arrêté, la modification effectuée avec --config est prévisible et prendra effet lors du prochain démarrage.
Définissez à 96 MiB la mémoire qui sera attribuée au prochain démarrage.
sudo virsh setmem lfcs-config 96M --config
Le suffixe M demande à virsh d’interpréter la valeur en mébioctets. La sortie ultérieure de dominfo convertira 128 MiB en 131072 KiB et 96 MiB en 98304 KiB ; il s’agit des mêmes quantités exprimées dans des unités différentes.
Le nombre maximal de vCPU doit être augmenté avant que l’allocation persistante actuelle puisse utiliser deux processeurs.
sudo virsh setvcpus lfcs-config 2 --config --maximum
Cette première commande modifie la limite supérieure dans la définition enregistrée. Elle n’attribue pas à elle seule deux vCPU utilisables. La distinction entre le maximum et l’allocation active permet de réserver une capacité d’extension future dans la définition d’une machine virtuelle.
Définissez deux vCPU pour le prochain démarrage.
sudo virsh setvcpus lfcs-config 2 --config
La seconde commande définit l’allocation persistante dans cette nouvelle limite. L’ordre est important : demander deux vCPU attribués alors que le maximum est encore fixé à un seul provoquerait une erreur.
Examinez la définition persistante mise à jour.
sudo virsh dominfo lfcs-config
Les champs concernés devraient maintenant afficher :
CPU(s): 2
Max memory: 131072 KiB
Used memory: 98304 KiB
Créer et connecter un disque de données persistant
Dans cette étape, vous allez créer une seconde image qcow2 et l’associer comme disque virtio persistant nommé vdb.
Créez une image qcow2 creuse de 64 MiB dans le répertoire des images de libvirt.
sudo qemu-img create -f qcow2 /var/lib/libvirt/images/lfcs-config-data.qcow2 64M
Cette commande crée un conteneur de disque virtuel, et non un système de fichiers ni un répertoire monté. -f qcow2 sélectionne le format d’image QEMU à copie lors de l’écriture, tandis que 64M définit sa capacité virtuelle. Une image creuse nouvellement créée utilise initialement beaucoup moins d’espace sur l’hôte que sa taille virtuelle et grandit à mesure que l’invité y écrit des données.
Autorisez le processus QEMU de cet environnement de formation à ouvrir l’image temporaire.
sudo chmod 666 /var/lib/libvirt/images/lfcs-config-data.qcow2
Le mode 666 accorde des droits de lecture et d’écriture à toutes les catégories d’utilisateurs. Cette permission très large permet à cet atelier temporaire de fonctionner indépendamment des paramètres spécifiques de l’utilisateur et du groupe QEMU de l’hôte, mais elle n’est pas recommandée en production. Sur un véritable hôte, utilisez plutôt les paramètres de propriétaire, de groupe, d’étiquette SELinux ou de politique AppArmor requis par le service libvirt local.
Associez le fichier à lfcs-config. L’option --target vdb définit le nom du périphérique de bloc vu par l’invité, --subdriver qcow2 enregistre le format de l’image et --config modifie la définition persistante pour le prochain démarrage.
sudo virsh attach-disk lfcs-config \
/var/lib/libvirt/images/lfcs-config-data.qcow2 \
vdb --targetbus virtio --subdriver qcow2 --config
Le chemin source appartient à l’hôte ; vdb est le nom que l’invité verrait. --targetbus virtio sélectionne une interface de disque paravirtualisée, couramment utilisée pour offrir de bonnes performances aux invités Linux. Comme le domaine est arrêté et que la commande utilise --config, libvirt enregistre le périphérique dans le schéma sauvegardé au lieu de tenter une connexion à chaud.
Affichez la configuration persistante des périphériques de bloc.
sudo virsh domblklist lfcs-config --details
La sortie devrait maintenant contenir vda et vdb, avec vdb pointant vers lfcs-config-data.qcow2.
À ce stade, le fichier image et l’association au domaine constituent deux éléments distincts. La simple création d’un fichier qcow2 ne le connecte pas à une machine virtuelle, et le retrait ultérieur d’un disque ne supprime pas automatiquement son fichier source.
Activer le démarrage automatique et valider l’état d’exécution
Dans cette étape, vous allez activer le démarrage automatique du domaine, démarrer immédiatement la machine virtuelle et comparer ses ressources d’exécution avec les paramètres persistants.
Activez le démarrage automatique afin que libvirt marque ce domaine pour un lancement lors du démarrage du service de virtualisation.
sudo virsh autostart lfcs-config
Le démarrage automatique est un indicateur de politique enregistré ; il ne demande pas de démarrer immédiatement le domaine. Il est utile pour les services d’infrastructure qui doivent redémarrer automatiquement après le redémarrage de l’hôte ou du service libvirt.
Démarrez le domaine avec sa définition persistante mise à jour.
sudo virsh start lfcs-config
Le démarrage crée un processus QEMU à partir de la définition enregistrée que vous avez modifiée : deux vCPU, les nouvelles limites mémoire et les deux disques. La commande indique que le domaine a démarré ; dominfo et domblklist fournissent les éléments permettant de vérifier que son état correspond à la configuration attendue.
Attendez quelques secondes que QEMU passe à l’état actif.
sleep 3
Examinez le domaine. Il devrait être en cours d’exécution avec deux vCPU, une mémoire maximale de 128 MiB et le démarrage automatique activé.
sudo virsh dominfo lfcs-config
Sur ce domaine émulé par logiciel, le champ Used memory en fonctionnement vaut normalement 128 MiB, même si la demande persistante currentMemory est de 96 MiB. Aucun système d’exploitation invité ni pilote ballon ne coopère avec libvirt pour réduire l’allocation mémoire en cours d’exécution. Examinez le fichier XML inactif pour confirmer que la configuration du prochain démarrage conserve bien 96 MiB :
sudo virsh dumpxml lfcs-config --inactive | grep -E '<memory|<currentMemory|<vcpu'
dumpxml --inactive demande la définition enregistrée plutôt que la vue QEMU active. Le tube transmet ce XML à grep, qui n’affiche que les éléments relatifs à la mémoire et aux processeurs. Cette comparaison ciblée évite de prendre une différence normale d’affichage entre l’exécution et la persistance pour un échec de configuration.
Les valeurs stables comprennent <memory unit='KiB'>131072</memory>, <currentMemory unit='KiB'>98304</currentMemory> et une valeur de vCPU égale à 2. Cette comparaison montre pourquoi la configuration persistante et les ressources réellement déclarées en fonctionnement doivent être vérifiées séparément.
Affichez les disques du domaine actif.
sudo virsh domblklist lfcs-config --details
vda et vdb devraient tous deux apparaître. Cela démontre que la configuration enregistrée a bien été appliquée lors du démarrage de QEMU.
Arrêter la machine virtuelle et confirmer l’état persistant
Dans cette étape, vous allez arrêter le processus invité tout en conservant le domaine configuré, le stockage et le paramètre de démarrage automatique.
Comme les disques de formation ne contiennent aucun système d’exploitation, un arrêt propre de l’invité ne peut pas aboutir. Utilisez destroy pour arrêter immédiatement le processus QEMU. Cette opération modifie l’état d’exécution, mais ne supprime pas la définition persistante du domaine.
sudo virsh destroy lfcs-config
Malgré son nom, virsh destroy revient davantage à couper l’alimentation qu’à supprimer une machine virtuelle. Cette commande est appropriée ici uniquement parce que l’exercice ne contient ni système d’exploitation invité ni données importantes. Pour un invité réel en fonctionnement, préférez virsh shutdown afin de laisser le système d’exploitation vider ses tampons et s’arrêter proprement.
Confirmez que le domaine est arrêté.
sudo virsh domstate lfcs-config
La sortie devrait être :
shut off
Examinez une dernière fois la configuration persistante.
sudo virsh dominfo lfcs-config
L’état shut off attendu ne décrit que l’exécution. Le processeur, la mémoire, les disques associés et le démarrage automatique restent présents dans la définition persistante. La suppression de cette définition nécessiterait une autre opération, telle que virsh undefine ; même la suppression de la définition d’un domaine ne supprime pas nécessairement ses fichiers image.
Affichez tous les domaines ainsi que leur état de démarrage automatique. Le domaine arrêté lfcs-config devrait rester défini et être marqué pour un démarrage automatique.
sudo virsh list --all --autostart
La machine virtuelle est maintenant arrêtée, mais elle pourra être redémarrée ultérieurement avec la configuration de ressources que vous avez créée.
Résumé
Vous avez repris un domaine libvirt existant et modifié sa configuration persistante des ressources sans réécrire son XML. Vous avez augmenté la mémoire maximale et la mémoire attribuée, configuré deux vCPU, créé et associé un second disque qcow2, activé le démarrage automatique, validé la configuration dans un domaine QEMU en fonctionnement, puis arrêté le processus tout en conservant la machine virtuelle gérée. Voilà la différence concrète entre simplement explorer le cycle de vie d’une machine virtuelle et la configurer pour atteindre un état cible précis.
