11.17. Virtualisation
L'installation d'une machine virtuelle via https ou ssh échoue dans certains cas
Actuellement, l'utilitaire virt-install échoue lorsqu'il tente d'installer un système d'exploitation invité (OS) à partir d'une source ISO via une connexion https ou ssh - par exemple en utilisant virt-install --cdrom https://example/path/to/image.iso. Au lieu de créer une machine virtuelle (VM), l'opération décrite se termine de manière inattendue par un message internal error: process exited while connecting to monitor.
De même, l'utilisation de la console web RHEL 9 pour installer un système d'exploitation invité échoue et affiche une erreur Unknown driver 'https' si vous utilisez une URL https ou ssh, ou la fonction Download OS.
Pour contourner ce problème, installez qemu-kvm-block-curl et qemu-kvm-block-ssh sur l'hôte pour activer la prise en charge des protocoles https et ssh, respectivement. Vous pouvez également utiliser un autre protocole de connexion ou une autre source d'installation.
L'utilisation des pilotes NVIDIA dans les machines virtuelles désactive Wayland
Actuellement, les pilotes NVIDIA ne sont pas compatibles avec la session graphique Wayland. Par conséquent, les systèmes d'exploitation invités RHEL qui utilisent des pilotes NVIDIA désactivent automatiquement Wayland et chargent une session Xorg à la place. Cela se produit principalement dans les scénarios suivants :
- Lorsque vous faites passer un périphérique GPU NVIDIA dans une machine virtuelle RHEL (VM)
- Lorsque vous affectez un périphérique NVIDIA vGPU à une VM RHEL
(JIRA:RHELPLAN-117234)
Le type de CPU Milan VM n'est parfois pas disponible sur les systèmes AMD Milan
Sur certains systèmes AMD Milan, les options Enhanced REP MOVSB (erms) et Fast Short REP MOVSB (fsrm) sont désactivées par défaut dans le BIOS. Par conséquent, le type de CPU Milan peut ne pas être disponible sur ces systèmes. En outre, la migration en direct de VM entre des hôtes Milan avec des paramètres de drapeaux de fonctionnalités différents peut échouer. Pour résoudre ces problèmes, activez manuellement erms et fsrm dans le BIOS de votre hôte.
(BZ#2077767)
La désactivation d'AVX rend les machines virtuelles non amorçables
Sur une machine hôte qui utilise un processeur avec support Advanced Vector Extensions (AVX), la tentative de démarrage d'une VM avec AVX explicitement désactivé échoue actuellement et déclenche une panique du noyau dans la VM.
(BZ#2005173)
VNC ne peut pas se connecter aux machines virtuelles UEFI après la migration
Si vous activez ou désactivez une file d'attente de messages lors de la migration d'une machine virtuelle (VM), le client Virtual Network Computing (VNC) ne parviendra pas à se connecter à la VM une fois la migration terminée.
Ce problème ne concerne que les machines virtuelles basées sur l'UEFI qui utilisent l'Open Virtual Machine Firmware (OVMF).
(JIRA:RHELPLAN-135600)
Les cartes réseau virtio de basculement ne reçoivent pas d'adresse IP sur les machines virtuelles Windows
Actuellement, lors du démarrage d'une machine virtuelle (VM) Windows avec seulement une carte d'interface réseau virtio de basculement, la VM ne parvient pas à attribuer une adresse IP à la carte d'interface réseau. Par conséquent, la carte d'interface réseau n'est pas en mesure d'établir une connexion réseau. Il n'existe actuellement aucune solution de contournement.
La VM Windows ne parvient pas à obtenir l'adresse IP après la réinitialisation de l'interface réseau
Il arrive que les machines virtuelles Windows ne parviennent pas à obtenir une adresse IP après une réinitialisation automatique de l'interface réseau. Par conséquent, la machine virtuelle ne parvient pas à se connecter au réseau. Pour résoudre ce problème, désactivez et réactivez le pilote de la carte réseau dans le gestionnaire de périphériques de Windows.
Les adaptateurs réseau Broadcom ne fonctionnent pas correctement sur les machines virtuelles Windows après une migration en direct
Actuellement, les adaptateurs réseau de la famille Broadcom, tels que Broadcom, Qlogic ou Marvell, ne peuvent pas être débranchés à chaud pendant la migration en direct des machines virtuelles (VM) Windows. Par conséquent, les adaptateurs ne fonctionnent pas correctement une fois la migration terminée.
Ce problème ne concerne que les adaptateurs connectés à des machines virtuelles Windows utilisant la virtualisation d'E/S à racine unique (SR-IOV).
(BZ#2090712, BZ#2091528, BZ#2111319)
Une interface hostdev avec des paramètres de basculement ne peut pas être branchée à chaud après avoir été débranchée à chaud
Après avoir supprimé une interface réseau hostdev avec une configuration de basculement d'une machine virtuelle (VM) en cours d'exécution, l'interface ne peut actuellement pas être réattachée à la même VM en cours d'exécution.
Échec de la migration post-copie en direct de VM avec des VF de basculement
Actuellement, la tentative de migration post-copie d'une machine virtuelle (VM) en cours d'exécution échoue si la VM utilise un périphérique dont la capacité de basculement de la fonction virtuelle (VF) est activée. Pour contourner le problème, utilisez le type de migration standard plutôt que la migration post-copie.
Le réseau de l'hôte ne peut pas envoyer de ping aux VMs avec VFs pendant la migration en direct
Lors de la migration en direct d'une machine virtuelle (VM) avec une fonction virtuelle (VF) configurée, telle qu'une VM qui utilise le logiciel SR-IOV virtuel, le réseau de la VM n'est pas visible pour les autres périphériques et la VM ne peut pas être atteinte par des commandes telles que ping. Cependant, une fois la migration terminée, le problème ne se produit plus.
L'utilisation d'un grand nombre de files d'attente peut entraîner l'échec des machines virtuelles Windows
Les machines virtuelles (VM) Windows peuvent échouer lorsque le périphérique virtuel Trusted Platform Module (vTPM) est activé et que la fonction multi-queue virtio-net est configurée pour utiliser plus de 250 files d'attente.
Ce problème est dû à une limitation du dispositif vTPM. Le périphérique vTPM a une limite codée en dur sur le nombre maximum de descripteurs de fichiers ouverts. Étant donné que plusieurs descripteurs de fichiers sont ouverts pour chaque nouvelle file d'attente, la limite interne du vTPM peut être dépassée, ce qui entraîne l'échec de la VM.
Pour contourner ce problème, choisissez l'une des deux options suivantes :
- Gardez le dispositif vTPM activé, mais utilisez moins de 250 files d'attente.
- Désactivez le dispositif vTPM pour qu'il utilise plus de 250 files d'attente.
