Tag archives for kvm

Migration à chaud de vm avec libvirt et kvm (3/3)

Dans mon article précédent, la migration à chaud de vm en utilisant libvirt et kvm n’avait pas fonctionné. Pour être plus précis, ma vm migrait bien d’un host à l’autre, était pingable mais se retrouvait avec un système de fichier en lecture seule. Regretable! Pourquoi? Simplement parce que le transfert du contexte durant la migration se fait par ssh en root (je n’ai pas encore trouvé le moyen de changer cela). Le fichier est exécuté par kvm qui tourne sous le user libvirt-qemu avec les droits 755 et n’a donc pas accès en écriture à la vm après la migration.
Mais pourquoi cela fonctionne-t-il quand je redémarre la vm par la fonction :

virsh create toto.xml

Cette fonction change les owners et groups du fichier de disk de vm, ce que ne fait pas la fonction migrate.

La solution est donc d’ajouter le user libvirt-qemu au groupe root et de mettre les droits 775 au fichier de disks de vm.

En conclusion, une restriction d’utilisation est identifiée: la nécessité d’ouvrir le ssh à root. Ce qui n’est pas une bonne pratique. Il faut au moins supprimer la connexion par mot de passe et la remplacer par une connexion par clé.

Posted in admin, virtualization | Leave a comment

Migration à chaud de vm avec libvirt et kvm (2/3)

Vous avez pu lire dans l‘article précédent la préparation des tests de migration. Passons aux choses sérieuses maintenant.

Comment effectuer une migration à chaud?
La commande est assez simple :

virsh migrate --live domain destinationURI

où l’URL est définie comme cela:

qemu://host/system # pour kvm
xen://host # pour xen

Par défaut, si on ne le précise, le transport d’une machine à l’autre se fait par TLS. J’utilise ssh, donc l’URI devient:

qemu+ssh://host/system

Je me lance.
Alors, sur ma machine at-at-3:

at-at-3:/sbufarm/vms# virsh list
Id Name State
----------------------------------
1 diodore running

Sur ma machine destination at-at-1:

at-at-1:/sbufarm/vms# virsh list
Id Name State
----------------------------------

Je tente un ping sur la machine

ping -i 0.2 diodore
PING 10.165.144.66 (10.165.144.66) 56(84) bytes of data.
64 bytes from 10.165.144.66: icmp_seq=1 ttl=63 time=0.357 ms
64 bytes from 10.165.144.66: icmp_seq=2 ttl=63 time=0.395 ms
64 bytes from 10.165.144.66: icmp_seq=3 ttl=63 time=0.358 ms
64 bytes from 10.165.144.66: icmp_seq=4 ttl=63 time=0.372 ms
64 bytes from 10.165.144.66: icmp_seq=5 ttl=63 time=0.351 ms
64 bytes from 10.165.144.66: icmp_seq=6 ttl=63 time=0.374 ms

que je laisse tourner.

Et eventually (tu parles, à mon avis, ce n’est que le début)

virsh migrate --live diodore qemu+ssh://at-at-1/system

Je surveille le ping

64 bytes from 10.165.144.66: icmp_seq=632 ttl=63 time=198 ms
64 bytes from 10.165.144.66: icmp_seq=633 ttl=63 time=199 ms
64 bytes from 10.165.144.66: icmp_seq=634 ttl=63 time=200 ms
64 bytes from 10.165.144.66: icmp_seq=635 ttl=63 time=200 ms
64 bytes from 10.165.144.66: icmp_seq=636 ttl=63 time=197 ms
64 bytes from 10.165.144.66: icmp_seq=637 ttl=63 time=198 ms
64 bytes from 10.165.144.66: icmp_seq=638 ttl=63 time=198 ms
64 bytes from 10.165.144.66: icmp_seq=639 ttl=63 time=200 ms
64 bytes from 10.165.144.66: icmp_seq=640 ttl=63 time=200 ms
64 bytes from 10.165.144.66: icmp_seq=641 ttl=63 time=197 ms
64 bytes from 10.165.144.66: icmp_seq=648 ttl=63 time=2.24 ms
64 bytes from 10.165.144.66: icmp_seq=649 ttl=63 time=0.399 ms
64 bytes from 10.165.144.66: icmp_seq=650 ttl=63 time=1.54 ms
64 bytes from 10.165.144.66: icmp_seq=651 ttl=63 time=0.388 ms
64 bytes from 10.165.144.66: icmp_seq=652 ttl=63 time=0.378 ms
64 bytes from 10.165.144.66: icmp_seq=653 ttl=63 time=3.29 ms
64 bytes from 10.165.144.66: icmp_seq=654 ttl=63 time=3.30 ms
64 bytes from 10.165.144.66: icmp_seq=655 ttl=63 time=1.85 ms

et voilà, c’est fait. On voit ici que le temps de réponse du ping augmente sensiblement, puis s’arrête une ou dexu secondes pour redémarrer sur l’autre machine.
Sur la machine de destination, on obtient:

at-at-1:/sbufarm/vms# virsh list
Id Name State
----------------------------------
1 diodore running

Sur ma machine source at-at-3:

at-at-3:/sbufarm/vms# virsh list
Id Name State
----------------------------------

ouaouh! ET BIEN NON, aucune satisfaction, puisque la machine ping, mais les accès aux disques ne fonctionnent pas.
La console indique les erreurs suivantes:

hda: task_pio_intr: status 0x41 {DriveReady Error}
hda: task_pio_intr: status 0x04 {DriveStatus Error}
hda: possibly failed opcode 0x39

La destruction de la vm et sa recréation (à partir du même fichier de disk) fonctionne parfaitement.

Voici aujourd’hui, l’état de mes investigations. Si quelqu’un a une idée, elle est bien venue!

Posted in admin, virtualization | Leave a comment

Swedish Greys - a WordPress theme from Nordic Themepark.