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.
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
Utilisez la commande
virsh migrate
avec les options appropriées à vos besoins de migration.La commande suivante permet de migrer la VM
example-VM-1
de votre hôte local vers la connexion système de l'hôteexample-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
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ôteexample-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.
La commande suivante suspend la VM
example-VM-3
de l'hôteexample-source
, la migre vers l'hôteexample-destination
et lui demande d'utiliser la configuration XML ajustée, fournie par le fichierexample-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.
La procédure suivante supprime la VM
example-VM-4
arrêtée de l'hôteexample-source
et déplace sa configuration vers l'hôteexample-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
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.
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 pourvirsh 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