19
0
Fork 0

Ajout d'une note importante sur les virshs migrate

This commit is contained in:
gcolpart 2017-07-20 23:02:25 +02:00
parent 426dd91e71
commit 659aa49ea8
1 changed files with 9 additions and 2 deletions

View File

@ -924,15 +924,17 @@ Pour envoyer une VM locale _test_ vers l'hyperviseur _foo_ :
~~~
# VIRSH_DEFAULT_CONNECT_URI='qemu:///system' virsh migrate --live --unsafe test qemu+ssh://foo/system
Migration: [100 %]
~~~
Pour rappatrier une VM _test_ depuis l'hyperviseur _foo_ :
~~~
# VIRSH_DEFAULT_CONNECT_URI='qemu+ssh://foo/system' virsh migrate --live --unsafe test qemu:///system
Migration: [100 %]
~~~
*Note* : on peut faire cela via virt-manager mais le mode `--unsafe` (utile si un cache disque est configuré) n'est pas supporté…
> *Note* : on peut faire cela via virt-manager mais le mode `--unsafe` (utile si un cache disque est configuré) n'est pas supporté…
Si l'on a plusieurs interfaces réseau sur l'hyperviseur (par exemple un réseau dédié entre les hyperviseurs), il faut l'indiquer à _libvirt_ sinon il tente de passer par l'interface principale :
@ -941,7 +943,12 @@ Si l'on a plusieurs interfaces réseau sur l'hyperviseur (par exemple un réseau
Migration: [100 %]
~~~
*Note* : sur des machines très proches matériellement, il est possible d'avoir un souci du fait d'un system-uuid identique sur les deux hyperviseurs :
> **Attention** la migration d'une VM ne déplace **pas** sa définition ! Il est donc impératif de faire un `virsh define` de son fichier de définition sur l'hyperviseur de destination de la migration sous peine de n'avoir plus aucune trace de la VM une fois éteinte ! On conseille aussi de nettoyer `virsh undefine` sur l'hyperviseur de départ pour éviter les confusions.
### internal error: Attempt to migrate guest to the same host
Sur des machines très proches matériellement, il est possible d'avoir un souci du fait d'un system-uuid identique sur les deux hyperviseurs :
~~~
error: internal error: Attempt to migrate guest to the same host 12341234-1234-1234-1234-1234123412341234