Partager via


Résoudre les problèmes de démarrage et de réseau des machines virtuelles Linux en raison d’erreurs associées au pilote Hyper-V

S’applique à : ✔️ Machines virtuelles Linux

Les exécutions Azure sur l’hyperviseur Hyper-V et les systèmes Linux nécessitent que certains modules de noyau Hyper-V s’exécutent sur Azure. Ces modules de noyau sont regroupés dans les pilotes LIS (Linux Integration Services) pour Hyper-V et Azure. Microsoft les contribue directement au noyau Linux en amont.

Cet article décrit plusieurs conditions dans lesquelles un ou plusieurs pilotes Hyper-V désactivés peuvent entraîner des problèmes de démarrage et de mise en réseau de machines virtuelles Linux.

Prerequisites

Vérifiez que la console série est activée et fonctionnelle dans la machine virtuelle Linux.

Comment identifier le problème de pilote Hyper-V manquant

Pour identifier si votre machine virtuelle ne parvient pas à démarrer en raison de pilotes Hyper-V manquants, utilisez Azure CLI ou le Portail Azure pour afficher le journal de la console série de la machine virtuelle dans le volet diagnostics de démarrage ou le volet console série. Les exemples de sorties d’échecs sont affichés dans les sections correspondantes ci-dessous.

Avant de résoudre le problème

Pour résoudre les problèmes de scénario 1 : le pilote Hyper-V réseau est désactivé et le scénario 2 : l’adresse mac de la carte réseau est modifiée ou ne correspond pas, vous avez besoin d’un accès à la console série pour votre machine virtuelle Linux.

Si vous n’avez pas d’accès à la console série, suivez l’approche hors connexion pour accéder au contenu du disque de système d’exploitation problématique à partir d’une machine virtuelle de secours. L’accès à Azure CLI ou à Azure Cloud Shell est requis pour l’approche hors connexion.

Pour résoudre le scénario 3 : d’autres pilotes Hyper-V sont désactivés, l’approche hors connexion est la seule option permettant de résoudre le problème.

Scénario 1 : Le pilote Hyper-V réseau est désactivé

Étant donné que les services de mise en réseau ne sont pas disponibles, vous ne parvenez pas à sécuriser le protocole SSH (Secure Shell Protocol) sur une machine virtuelle, mais vous pouvez toujours vous connecter via la console série à partir du Portail Azure. Vous voyez les types d’erreurs suivants dans la console série ou le journal série le plus récent dans le volet Diagnostics de démarrage dans l’Portail Azure :

 cloud-init[807]: Cloud-init v. 19.4 running 'init-local' at Tue, xx Aug 20XX 20:41:53 +0000. Up 5.83 seconds.
 cloud-init[807]: 20XX-08-XX 20:41:54,231 - stages.py[WARNING]: Failed to rename devices: [nic not present] Cannot rename mac=xx:xx:xx:xx:xx:xx to eth0, not available.
[  OK  ] Started Initial cloud-init job (pre-networking).
----
[FAILED] Failed to start LSB: Bring up/down networking.
See 'systemctl status network.service' for details.

Or

 cloud-init[799]: 2022-XX-XX 19:04:06,267 - azure.py[WARNING]: Interface not found for DHCP
 cloud-init[799]: 2022-XX-XX 19:04:07,269 - azure.py[WARNING]: Interface not found for DHCP
 cloud-init[799]: 2022-XX-XX 19:04:10,274 - azure.py[WARNING]: Interface not found for DHCP
 cloud-init[799]: 2022-XX-2XX 19:04:10,277 - azure.py[WARNING]: IMDS network metadata has incomplete configuration: None

Solution 1 : Activer le pilote réseau Hyper-V à l’aide de la console série

  1. Accédez à la console série de la machine virtuelle. La mise en réseau est en panne, mais l’invite de connexion est toujours disponible.

  2. Connectez-vous à la machine virtuelle avec les informations d’identification appropriées.

  3. Basculez vers le compte racine ou le compte d’utilisateur avec l’accès sudo.

  4. Accédez au répertoire /etc/modprobe.d et recherchez une ligne qui désactive le pilote hv_netvsc.

    1. Identifiez le fichier qui désactive le pilote hv_netvsc et les numéros de ligne correspondants en exécutant la commande suivante :

      grep -nr "hv_netvsc" /etc/modprobe.d/
      
    2. Modifiez le fichier correspondant et commentez ou supprimez les entrées hv_netvsc :

      Capture d’écran montrant le contenu possible du fichier de configuration utilisé pour désactiver les pilotes réseau.

      vi /etc/modprobe.d/disable.conf
      

      Note

      • Les entrées qui désactivent les pilotes sont définies par le système d’exploitation Linux, et non par Microsoft.
      • Remplacez disable.conf par le nom de fichier correspondant où le pilote hv_netvsc est désactivé.
  5. Régénérez l’image RAMdisk initiale pour le noyau actuellement chargé :

    • Pour les images basées sur RHEL/SLES

      # dracut -f -v
      
    • Pour les images basées sur Ubuntu/Debian

      # mkinitramfs -k -o /boot/initrd.img-$(uname -r)
      
  6. Redémarrez la machine virtuelle.

Effectuez toujours une sauvegarde de l’image RAMdisk initiale d’origine pour faciliter la restauration si nécessaire.

  • Pour les images RHEL :

    # cp /boot/initramfs-<kernelVersion>.img /boot/initramfs-<kernelVersion>.img.bak
    
  • Pour les images basées sur SLES :

    # cp /boot/initrd-<kernelVersion> /boot/initrd-<kernelVersion>.bak
    
  • Pour les images basées sur Ubuntu/Debian :

    # cp /boot/initrd.img-<kernelVersion> /boot/initrd.img-<kernelVersion>.bak
    

Solution 2 : Activer le pilote réseau Hyper-V hors connexion

  1. Utilisez az vm repair pour accéder au contenu du disque du système d’exploitation affecté à partir d’une machine virtuelle de secours.

  2. Montez et chroot sur les systèmes de fichiers du disque de système d’exploitation attaché dans la machine virtuelle de secours en suivant les instructions chroot.

  3. Une fois le contenu du disque de système d’exploitation affecté accessible, suivez les étapes 4 et 5 de la solution 1 : activez le pilote réseau Hyper-V à l’aide de la console série pour réenabler les pilotes et reconstruire l’image RAMdisk initiale.

    Avant la reconstruction de l’image RAMdisk initiale, basculez vers l’environnement chroot. Le chemin d’accès complet de l’image doit être fourni.

  4. Une fois les modifications appliquées, effectuez un échange automatique de disque de système d’exploitation avec la machine virtuelle d’origine et redémarrez le système à l’aide de la az vm repair restore commande.

Scénario 2 : l’adresse MAC de carte réseau est modifiée ou ne correspond pas

Si l’adresse MAC de la carte d’interface réseau est modifiée ou ne correspond pas à la configuration du système d’exploitation, vous ne pourrez pas accéder à SSH sur la machine virtuelle, car les services de mise en réseau ne sont pas disponibles. Vous êtes toujours en mesure de vous connecter via la console série à partir de la Portail Azure. Les erreurs similaires à celles du scénario 1 : le pilote Hyper-V réseau est désactivé s’affiche.

Si le problème persiste même si le pilote réseau Hyper-V est activé, utilisez l’une des solutions suivantes pour valider la configuration de la carte réseau du système d’exploitation et résoudre le problème.

Solution 1 : Corriger l’incompatibilité d’adresse MAC de carte réseau à l’aide de la console série

  1. Accédez à la console série de la machine virtuelle. La mise en réseau est en panne, mais l’invite de connexion est toujours disponible.

  2. Connectez-vous à la machine virtuelle avec les informations d’identification appropriées.

  3. Basculez vers le compte racine ou le compte d’utilisateur avec l’accès sudo.

  4. Accédez au répertoire /etc/cloud/cloud.cfg.d .

  5. Étant donné que les images partenaires Linux sont utilisées, ouvrez et modifiez les fichiers suivants :

    • 91-azure_datasource.cfg pour la distribution basée sur RHEL.
    • 90_dpkg.cfg pour la distribution Debian et Ubuntu.
  6. Si le paramètre a la apply_network_config valeur false, définissez-le sur true. Si rien n’est spécifié, la valeur par défaut est définie sur true. Ce paramètre garantit que la nouvelle adresse MAC est appliquée à la configuration réseau lors du prochain redémarrage.

  7. En règle générale, une adresse MAC de carte réseau ne change que si une carte réseau est supprimée ou ajoutée par l’administrateur ou qu’une carte réseau est mise à jour dans le back-end. Si la configuration réseau via cloud-init n’est pas souhaitée et que le apply_network_config paramètre doit être défini sur false, supprimez le fichier /var/lib/cloud/instance/obj.pkl et redémarrez le système.

    # rm /var/lib/cloud/instance/obj.pkl
    
  8. Une fois les modifications appliquées, redémarrez le système.

Solution 2 : Corriger l’incompatibilité d’adresse MAC de carte réseau hors connexion

  1. Utilisez la commande az vm repair pour accéder au contenu du disque du système d’exploitation affecté à partir d’une machine virtuelle de secours.
  2. Montez et chroot sur les systèmes de fichiers du disque de système d’exploitation attaché dans une machine virtuelle de secours correctement en suivant les instructions chroot.
  3. Une fois que le contenu de la copie du disque de système d’exploitation affecté est accessible, suivez les étapes 4 à 7 dans la solution 1 : Corriger l’incompatibilité d’adresse MAC de carte réseau à l’aide de la console série pour apporter des modifications réseau ou effacer le fichier obj.pkl .
  4. Une fois les modifications appliquées, utilisez la az vm repair restore commande pour effectuer un échange automatique de disque de système d’exploitation avec la machine virtuelle d’origine et redémarrer le système.

Scénario 3 : d’autres pilotes Hyper-V sont désactivés

Si vous rencontrez des problèmes de démarrage avec d’autres pilotes Hyper-V, il est probable que vous ne parvenez pas à connecter SSH à une machine virtuelle, car les services de mise en réseau ne sont pas disponibles. Vous êtes abandonné à un interpréteur de commandes dracut. Ce problème peut être consulté via la console série à partir de la Portail Azure. Vous pouvez voir les erreurs suivantes dans la console série ou le journal série le plus récent dans le volet Diagnostics de démarrage dans le Portail Azure :

 dracut-initqueue[455]: Warning: dracut-initqueue timeout - starting timeout scripts
 dracut-initqueue[455]: Warning: Could not boot.
         Starting Setup Virtual Console...
[  OK  ] Started Setup Virtual Console.
         Starting Dracut Emergency Shell...
Warning: /dev/mapper/rootvg-rootlv does not exist
Generating "/run/initramfs/rdsosreport.txt"
 
Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.
dracut:/#

Or

Gave up waiting for root file system device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  UUID=143c811b-9b9c-48f3-b0c8-040f6e65f50aa does not exist.  Dropping to a shell!


BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu3.4) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs)

Solution : Activer les pilotes Hyper-V

Si la machine virtuelle est inaccessible en raison d’autres pilotes Hyper-V désactivés, utilisez une approche hors connexion pour réactiver les pilotes, car les initramfs ne peuvent pas être chargés.

  1. Utilisez la commande az vm repair pour accéder au contenu du disque de système d’exploitation problématique à partir d’une machine virtuelle de secours.

  2. Montez et chroot sur les systèmes de fichiers du disque de système d’exploitation attaché dans une machine virtuelle de secours correctement en suivant les instructions chroot.

  3. Une fois dans l’environnement chroot, accédez au répertoire /etc/modprobe.d et recherchez toute ligne susceptible de désactiver le hv_utils, hv_vmbus, hv_storvsc ou hv_netvsc pilote.

    1. Exécutez la commande suivante pour identifier le fichier qui désactive les hv_utils, hv_vmbus, hv_storvsc ou hv_netvsc pilote et le numéro de ligne correspondant.

      egrep -nr "hv_utils|hv_vmbus|hv_storvsc|hv_netvsc" /etc/modprobe.d/
      
    2. Modifiez le fichier correspondant et commentez ou supprimez les entrées hv_utils, hv_vmbus, hv_storvsc ou hv_netvsc. Les entrées sont généralement les suivantes (ou les deux) :

      Capture d’écran montrant le contenu possible du fichier de configuration utilisé pour désactiver les modules/pilotes du noyau à l’aide de l’option d’installation.

      Capture d’écran montrant le contenu possible du fichier de configuration utilisé pour désactiver les modules/pilotes du noyau.

      vi /etc/modprobe.d/disable.conf
      

    Important

    • Les entrées qui désactivent les pilotes sont définies par le système d’exploitation Linux, et non par Microsoft.
    • Remplacez disable.conf par le nom de fichier correspondant où les pilotes Hyper-V sont désactivés.
  4. Régénérez l’image RAMdisk initiale pour le noyau actuellement chargé :

    • Pour les images basées sur RHEL/SLES

      # dracut -f -v
      
    • Pour les images basées sur Ubuntu/Debian

      # mkinitramfs -k -o /boot/initrd.img-$(uname -r)
      
  5. Une fois les modifications appliquées, utilisez la az vm repair restore commande pour effectuer un échange automatique de disque de système d’exploitation avec la machine virtuelle d’origine et redémarrer le système.

Effectuez toujours une sauvegarde de l’image RAMdisk initiale d’origine pour faciliter la restauration si nécessaire.

Si le problème n’est toujours pas résolu, reportez-vous à la machine virtuelle Linux Azure ne parvient pas à démarrer et entre l’interpréteur de commandes d’urgence pour examiner les problèmes dracut.

Prochaines étapes

Si l’erreur de démarrage spécifique n’est pas un problème Hyper-V, consultez Résoudre les erreurs de démarrage d’Azure Linux Machines Virtuelles pour obtenir d’autres options de résolution des problèmes.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.