12.6. Migrer une machine virtuelle à l'aide de l'interface de ligne de commande


Si l'hôte actuel d'une machine virtuelle (VM) ne convient plus ou ne peut plus être utilisé, ou si vous souhaitez redistribuer la charge de travail d'hébergement, vous pouvez migrer la VM vers un autre hôte KVM. La procédure suivante fournit des instructions et des exemples pour divers scénarios de migration.

Conditions préalables

  • L'hôte source et l'hôte de destination utilisent tous deux l'hyperviseur KVM.
  • L'hôte source et l'hôte de destination sont en mesure de se joindre l'un l'autre sur le réseau. Utilisez l'utilitaire ping pour le vérifier.
  • Assurez-vous que les ports suivants sont ouverts sur l'hôte de destination.

    • Le port 22 est nécessaire pour se connecter à l'hôte de destination en utilisant SSH.
    • Le port 16509 est nécessaire pour se connecter à l'hôte de destination en utilisant TLS.
    • Le port 16514 est nécessaire pour se connecter à l'hôte de destination en utilisant TCP.
    • Les ports 49152-49215 sont nécessaires à QEMU pour transférer les données de migration de la mémoire et du disque.
  • Pour que la migration soit prise en charge par Red Hat, l'hôte source et l'hôte de destination doivent utiliser des systèmes d'exploitation et des types de machines spécifiques. Pour vous assurer que c'est le cas, consultez la section Hôtes pris en charge pour la migration de machines virtuelles.
  • La machine virtuelle doit être compatible avec les caractéristiques du processeur de l'hôte de destination. Pour s'en assurer, voir Vérification de la compatibilité du CPU de l'hôte pour la migration de la machine virtuelle.
  • Les images de disque des machines virtuelles qui seront migrées sont situées sur un emplacement réseau distinct accessible à la fois à l'hôte source et à l'hôte de destination. Cette opération est facultative pour la migration hors ligne, mais obligatoire pour la migration d'une VM en cours d'exécution.

    Pour obtenir des instructions sur la configuration d'un tel stockage partagé de VM, voir Partage d'images de disques de machines virtuelles avec d'autres hôtes.

  • Lors de la migration d'une VM en cours d'exécution, la bande passante de votre réseau doit être supérieure à la vitesse à laquelle la VM génère des pages de mémoire sale.

    Pour obtenir le taux de pages sales de votre VM avant de lancer la migration en direct, procédez comme suit :

    • Surveillez le taux de génération de pages sales de la VM pendant une courte période.

      # virsh domdirtyrate-calc example-VM 30
    • Une fois le contrôle terminé, obtenez ses résultats :

      # virsh domstats example-VM --dirtyrate
      Domain: 'example-VM'
        dirtyrate.calc_status=2
        dirtyrate.calc_start_time=200942
        dirtyrate.calc_period=30
        dirtyrate.megabytes_per_second=2

      Dans cet exemple, la VM génère 2 Mo de pages de mémoire sale par seconde. Si vous tentez de migrer en direct une telle VM sur un réseau dont la bande passante est inférieure ou égale à 2 Mo/s, la migration en direct ne progressera pas si vous ne mettez pas la VM en pause ou si vous ne réduisez pas sa charge de travail.

      Pour s'assurer que la migration en direct se termine avec succès, Red Hat recommande que la bande passante de votre réseau soit significativement plus grande que le taux de génération de pages sales de la VM.

  • Lors de la migration d'une VM existante dans un réseau de robinets à pont public, les hôtes source et destination doivent être situés sur le même réseau. Dans le cas contraire, le réseau VM ne fonctionnera pas après la migration.
Note

La valeur de l'option calc_period peut varier en fonction de la charge de travail et du taux de pages sales. Vous pouvez expérimenter plusieurs valeurs de calc_period pour déterminer la période la plus appropriée en fonction du taux de pages sales dans votre environnement.

  • Lors de la migration d'une VM, le client virsh sur l'hôte source peut utiliser l'un des protocoles suivants pour se connecter au démon libvirt sur l'hôte de destination. Les exemples de la procédure suivante utilisent une connexion SSH, mais vous pouvez en choisir une autre.

    • Si vous souhaitez que libvirt utilise une connexion SSH, assurez-vous que le socket virtqemud est activé et fonctionne sur l'hôte de destination.

      # systemctl enable --now virtqemud.socket
    • Si vous souhaitez que libvirt utilise une connexion TLS, assurez-vous que le socket virtproxyd-tls est activé et fonctionne sur l'hôte de destination.

      # systemctl enable --now virtproxyd-tls.socket
    • Si vous souhaitez que libvirt utilise une connexion TCP, assurez-vous que le socket virtproxyd-tcp est activé et fonctionne sur l'hôte de destination.

      # systemctl enable --now virtproxyd-tcp.socket

Procédure

  1. Utilisez la commande virsh migrate avec les options appropriées à vos besoins de migration.

    1. La commande suivante permet de migrer la VM example-VM-1 de votre hôte local vers la connexion système de l'hôte example-destination à l'aide d'un tunnel SSH. La machine virtuelle continue de fonctionner pendant la migration.

      # virsh migrate --persistent --live example-VM-1 qemu ssh://example-destination/system
    2. Les commandes suivantes vous permettent d'apporter des ajustements manuels à la configuration de la VM example-VM-2 fonctionnant sur votre hôte local, puis de migrer la VM vers l'hôte example-destination. La VM migrée utilisera automatiquement la configuration mise à jour.

      # virsh dumpxml --migratable example-VM-2 > example-VM-2.xml
      # vi example-VM-2.xml
      # virsh migrate --live --persistent --xml example-VM-2.xml example-VM-2 qemu+ssh://example-destination/system

      Cette procédure peut s'avérer utile, par exemple, lorsque l'hôte de destination doit utiliser un chemin différent pour accéder au stockage partagé de la VM ou lorsqu'il s'agit de configurer une fonction spécifique à l'hôte de destination.

    3. La commande suivante suspend la VM example-VM-3 de l'hôte example-source, la migre vers l'hôte example-destination et lui demande d'utiliser la configuration XML ajustée, fournie par le fichier example-VM-3-alt.xml. Lorsque la migration est terminée, libvirt reprend la VM sur l'hôte de destination.

      # virsh migrate example-VM-3 qemu ssh://example-source/system qemu ssh://example-destination/system --xml example-VM-3-alt.xml

      Après la migration, la VM est à l'arrêt sur l'hôte source, et la copie migrée est supprimée après son arrêt.

    4. La procédure suivante supprime la VM example-VM-4 arrêtée de l'hôte example-source et déplace sa configuration vers l'hôte example-destination.

      # virsh migrate --offline --persistent --undefinesource example-VM-4 qemu ssh://example-source/system qemu ssh://example-destination/system

      Notez que ce type de migration ne nécessite pas le déplacement de l'image disque de la VM vers le stockage partagé. Cependant, pour que la VM soit utilisable sur l'hôte de destination, vous devez également migrer l'image disque de la VM. Par exemple :

      # scp root@example-source:/var/lib/libvirt/images/example-VM-4.qcow2 root@example-destination:/var/lib/libvirt/images/example-VM-4.qcow2
    5. La commande suivante migre la VM example-VM-5 vers l'hôte example-destination et utilise plusieurs connexions parallèles, également connues sous le nom de migration à descripteurs de fichiers multiples (multi-FD). La migration multi-FD permet d'accélérer la migration en utilisant toute la bande passante disponible pour le processus de migration.

      # virsh migrate --parallel --parallel-connections 4 <example-VM-5> qemu ssh://<example-destination>/system

      Cet exemple utilise 4 canaux multi-FD pour migrer la VM example-VM-5. Il est recommandé d'utiliser un canal pour chaque 10 Gbps de bande passante réseau disponible. La valeur par défaut est de 2 canaux.

  2. Attendez la fin de la migration. Le processus peut prendre un certain temps en fonction de la bande passante du réseau, de la charge du système et de la taille de la VM. Si l'option --verbose n'est pas utilisée pour virsh migrate, la CLI n'affiche aucun indicateur de progression, à l'exception des erreurs.

    Lorsque la migration est en cours, vous pouvez utiliser l'utilitaire virsh domjobinfo pour afficher les statistiques de migration.

Vérification

  • Sur l'hôte de destination, dressez la liste des VM disponibles pour vérifier si la VM a été migrée :

    # virsh list
    Id      Name             State
    ----------------------------------
    10    example-VM-1      running

    Si la migration est toujours en cours, cette commande indique que l'état de la VM est paused.

Résolution de problèmes

  • Dans certains cas, l'hôte cible ne sera pas compatible avec certaines valeurs de la configuration XML de la VM migrée, telles que le nom du réseau ou le type de CPU. Par conséquent, la VM ne pourra pas démarrer sur l'hôte cible. Pour résoudre ces problèmes, vous pouvez mettre à jour les valeurs problématiques à l'aide de la commande virsh edit. Après avoir mis à jour les valeurs, vous devez redémarrer la VM pour que les modifications soient appliquées.
  • Si une migration en direct prend beaucoup de temps à se terminer, cela peut être dû au fait que la VM est fortement sollicitée et que trop de pages mémoire sont modifiées pour que la migration en direct soit possible. Pour résoudre ce problème, remplacez la migration par une migration non dynamique en suspendant la VM.

    # virsh suspend example-VM-1

Ressources supplémentaires

  • virsh migrate --help commande
  • virsh (1) page de manuel
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.