Tag archives for migration

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

Bonjour,

L’objectif de cet article est de vous relater mes expériences de migration à chaud de VM (machines virtuelles) entre deux serveurs KVM utilisant libvirt-bin.
En préambule, j’ai eu quelques soucis de mise à jour de version de libvirt-bin. Ce sera le sujet de la première partie.

Pour information, j’utilise deux serveurs HP Proliant G5 qui sont au début de mes expérimentations en debian lenny, 2.6.26-amd64 pour le kernel et en version 0.4.6 pour libvirt-bin.

Stockage centralisé des VMs
Dans l’état actuel des choses, mes VMs sont stockées dans l’arborescence locale de chacune des machines. Ceci ne rend pas la migration d’une machine à l’autre possible. Pour ce faire, il faut être équipé d’un stockage centralisé, de type SAN ou NFS. NFS est la méthode la plus économique et la plus facile à mettre en oeuvre. Dans l’idéal, pour avoir un intérêt en production, j’aurais besoin d’une autre machine pour faire serveur nfs. Ce n’est pas le cas, je configure donc ma première machine en serveur NFS. J’exporte le répertoire où je stocke les disques et le répertoire où je stocke les fichiers xml de description des vms utilisé par libvirt. Par défaut, celui-ci est en /etc/libvirt/qemu.

Mon fichier /etc/exports de la machine nfs server:

/home/stephbul/vms/disks monlan/255.255.255.0(rw,no_subtree_check,no_root_squash)
/home/stephbul/vms/vms monlan/255.255.255.0(rw,no_subtree_check,no_root_squash)

nfs1 est le serveur nfs1 et monlan est mon réseau local, comme défini dans /etc/networks. Je restreins l’accès à ce nfs au seul réseau monlan.

Mes fichiers /etc/fstab de mes deux machines:

nfs1:/home/stephbul/vms/disks /sbufarm/disks nfs rw,rsize=4096,wsize=4096,hard,async 0 0
nfs1:/home/stephbul/vms/vms /sbufarm/vms nfs rw,rsize=4096,wsize=4096,hard,async 0 0

Attention, à ne pas oublier de changer les chemins d’accès dans vos fichiers xml de description de vos VMs.

Il est maintenant temps de faire les premiers essais. Malheureusement, je note vite que la fonction de migration n’est disponible dans l’hyperviseur qu’à partir de la version 0.5.0. Etant en 0.4.6, il est nécessaire de faire une mise à jour de libvirt. Ne souhaitant pas me lancer, à l’origine dans un upgrade depuis lenny vers squeeze de mes deux HP Proliant G5 utilisé pour différents services, j’ai décidé de tenter le package pinning, fonction bien pratique de debian pour utiliser la version de debian squeeze pour libvirt-bin qui est la 0.8.1.
Malheureusement les dépendances de libvirt ont nécessité un upgrade de udev. Et celui-ci m’a fait tombé sur le problème connu chez debian (bug #566000).

Preparing to replace libudev0 149-1 (using .../libudev0_150-2_i386.deb)
....
Unpacking replacement libudev0 ...
Preparing to replace udev 149-1 (using .../archives/udev_150-2_i386.deb)
....
Since release 150, udev requires that support for the CONFIG_SYSFS_DEPRECATED feature is disabled in the running kernel.

Please upgrade your kernel before or while upgrading udev.

AT YOUR OWN RISK, you can force the installation of this version of udev
WHICH DOES NOT WORK WITH YOUR RUNNING KERNEL AND WILL BREAK YOUR SYSTEM
AT THE NEXT REBOOT by creating the /etc/udev/kernel-upgrade file.
There is always a safer way to upgrade, do not try this unless you
understand what you are doing!


Il semble nécessaire d’installer un nouveau kernel, mais l’installation n’est alors plus possible du fait de la dépendance cassée…
Bon, comment m’en suis-je sorti?


$ apt-get update
# Désinstallation de libvirt-bin
$ apt-get remove libvirt-bin
$ apt-get autoremove
# Désinstallation de tous les kernels
$ apt-get remove linux-image-2.6....
# Installation du dernier kernel par son méta-package
$ aptitude install linux-image-2.6-amd64
$ reboot
$ aptitude full-upgrade
$ reboot

Cela correspond à ce que je ne voulais pas faire (un upgrade vers squeeze), mais c’était devenu nécessaire.
Ensuite, je réinstalle libvirt-bin

$ apt-get install libvirt-bin

Ce qui me donne

$ virsh --version
0.8.1

Je peux enfin commencer mes tests. Ce que vous trouverez dans un le post suivant.

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.