J’ai une petite ferme de serveurs physiques sous Scientific Linux 6 qui hébergent des machines virtuelles KVM gérées par libvirt. J’utilise des volumes logiques LVM comme disques virtuels.

La plupart des VM ne sont pas critiques et supportent d’être arrêtées quelques minutes; par contre il vaut mieux ne pas les arrêter trop longtemps. Tout le problème est donc de recopier au moins le gros des données sans arrêter la VM.

Pour l’exemple, je déplacerai une VM vm1, dont le disque virtuel est sur /dev/vg00/vm1, de la machine physique host1 à sa soeur host2. On supposera pour l’exemple que les deux machines sont identiques; en tout cas il vaut mieux qu’elles disposent de la même version du paquet qemu-kvm. Et quand je dis la même version c’est la même version au patch près, sinon la VM risque de ne pas démarrer sur le nouvel hôte.

L’outil

Je sais faire la même manip avec des isolateurs à la place des VM: un coup de rsync et c’est marre. Ah, si rsync savait se débrouiller à peu près efficacement avec un périphérique bloc… Et ben ça existe, ça s’appelle lvmsync, c’est un script ruby qu’il suffit de poser sur les deux machines hôtes. En dehors de ça, vous aurez besoin de dmsetup (normalement il est installé, il fait partie du paquet device-mapper qui est lui-même une dépendance de libvirt) et root devra pouvoir se connecter en ssh sur host2 depuis host1.

La méthode

On commence par créer le volume logique sur host2:

lvcreate -l640 -nvm1 vg00

À adapter évidemment, il doit être identique à l’original qui se trouve sur host1.

Ensuite, sur host1, on prend un instantané du disque de la VM et on le copie sur host2:

lvcreate -L10G -s -nvm1-snap /dev/vg00/vm1
dd if=/dev/vg00/vm1-snap bs=10M | ssh root@host2 dd of=/dev/vg00/vm1 bs=10M

On peut maintenant éteindre la VM, puis synchroniser le disque. Ensuite on exporte la configuration de la VM.

virsh shutdown vm1
lvmsync /dev/vg00/vm1-snap host2:/dev/vg00/vm1
virsh dumpxml vm1 | ssh root@host2 'cat > /var/tmp/vm1.xml'

Reste plus, sur host2, qu’à importer et démarrer la VM:

virsh define /var/tmp/vm1.xml
virsh start vm1

Une fois que c’est fait, on peut faire le ménage sur host1:

virsh undefine vm1
lvremove /dev/vg00/vm1-snap
lvremove /dev/vg00/vm1

C’est prêt!

Et ça va quand même vachement plus vite comme ça. Maintenant, il va falloir écrire un bout de script pour emballer tout ça, on verra ça un autre jour.

Préparation de la machine virtuelle

J’ai donc une VM Xen, appelons-la testxen1 (parce que c’est son nom), qui tourne sur l’ancien serveur. L’OS installé sur la VM est un CentOS 5. Sur cette machine virtuelle (qui tourne encore):

• éditer /etc/inittab, enlever le getty(8) qui tourne sur la console Xen et décommenter ceux des terminaux virtuels habituels;
• installer un noyau Linux «normal» (pas un noyau Xen);
• éditer /etc/fstab et remplacer les disques virtuels Xen (xvda, xvdb et ainsi de suite) par des disques IDE (hda, hdb…). NB: pas évident que cette étape soit partout la même, ça dépend peut-être de la version du noyau; à tester.
• enlever le paramètre console=xvc0 du nouveau noyau dans /boot/grub/menu.lst, et s’assurer que le nouveau noyau est bien sélectionné par défaut;
• installer grub:

[root@testxen1 ~]# grub
Probing devices to guess BIOS drives. This may take a long time.

    GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

 [ Minimal BASH-like line editing is supported.  For the first word, TAB
   lists possible command completions.  Anywhere else TAB lists the possible
   completions of a device/filename.]
grub> device (hd0) /dev/xvda
device (hd0) /dev/xvda
grub> root (hd0,0)
root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83
grub> setup (hd0)
setup (hd0)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd0)"...  15 sectors are embedded.
succeeded
 Running "install /boot/grub/stage1 (hd0) (hd0)1+15 p (hd0,0)/boot/grub/stage2 /boot/grub/grub.conf"... succeeded
Done.
grub> quit
quit

C’est fini pour la machine virtuelle, on peut maintenant l’arrêter.

Sur la nouvelle machine physique

On commence, bien sûr, par copier l’ancien (ou les anciens) disque(s) virtuel(s) sur la nouvelle machine. Dans mon cas, il s’agit de volumes logiques LVM, on fait bêtement ça à grands coups de dd(1). Reste juste à créer la nouvelle VM:

virt-install --connect qemu:///system -n testxen1 -r 1024 --vcpus=1 \
 --disk /dev/vg00/testxen1 --vnc --os-type linux --accelerate \
 --network=bridge=br102,model=virtio,mac=12:00:02:e3:00:01 \
 --noreboot --keymap us --import

Quelques notes en vrac:

• bien évidemment, remplacer le nom de la machine (ici testxen1) par ce qu’on veut;
• idem pour la mémoire (option -r) et le nombre de processeurs (option –vcpus);
• dans le cas où on a plusieurs disques virtuels, on peut répéter plusieurs fois l’option –disk, avec le disque de démarrage en premier;
• pour l’option –network, replacer br102 par le nom du pont réseau qui va bien (si vous avez une config réseau différente, va falloir chercher ) et bien entendu l’adresse MAC par la bonne valeur.

Voilà, vous allez voir démarrer votre nouvelle VM sous vos yeux zébahis. Elle est pas belle, la vie?

Pour contourner, il faut modifier les modules SYSUSER et SSHD pour qu’ils acceptent de s’installer ; ça veut dire passer les patches suivants et les recompiler :

diff -urN N5200_SYSUSER_2.00.02/SYSUSER/Configure/install.rdf N5200_SYSUSER_2.00.02.ne52pro/SYSUSER/Configure/install.rdf
--- N5200_SYSUSER_2.00.02/SYSUSER/Configure/install.rdf 2007-01-31 18:11:44.000000000 +0100
+++ N5200_SYSUSER_2.00.02.ne52pro/SYSUSER/Configure/install.rdf 2009-01-08 14:17:40.846560965 +0100
@@ -18,8 +18,8 @@
                <md:UI>Thecus</md:UI>
        </md:Install>
        <md:NAS>
-               <md:TargetNas>Thecus</md:TargetNas>
-               <md:NasType>n5200</md:NasType>
+               <md:TargetNas></md:TargetNas>
+               <md:NasType>NE52</md:NasType>
                <md:NasVersion>1.00.06.5</md:NasVersion>
        </md:NAS>
 </rdf:RDF>

diff -urN N5200_SSHD_2.00.00/SSHD/Configure/install.rdf N5200_SSHD_2.00.00.ne52pro/SSHD/Configure/install.rdf
--- N5200_SSHD_2.00.00/SSHD/Configure/install.rdf       2007-01-17 18:17:57.000000000 +0100
+++ N5200_SSHD_2.00.00.ne52pro/SSHD/Configure/install.rdf       2009-01-08 14:18:15.080559781 +0100
@@ -18,8 +18,8 @@
                <md:UI>Thecus</md:UI>
        </md:Install>
        <md:NAS>
-               <md:TargetNas>Thecus</md:TargetNas>
-               <md:NasType>n5200</md:NasType>
+               <md:TargetNas></md:TargetNas>
+               <md:NasType>NE52</md:NasType>
                <md:NasVersion>1.00.06.5</md:NasVersion>
        </md:NAS>
 </rdf:RDF>

Les modules acceptent maintenant de s’installer ; une fois que c’est fait, on peut se connecter en ssh sur la machine et modifier le fichier /app/manifest.txt. Il doit ressembler à ça :

type    n5200
producer        THECUS

Voilà, la boîboîte est maintenant une « vraie » Thecus N5200PRO. On peut maintenant mettre le firmware à jour et tout marche comme il faut.

Les modules et les firmwares sont téléchargeables depuis le wiki Thecus.

Le point de départ

Un PC x86 sous Debian Etch tout ce qu’il y a de plus banal. Il possède 2 interfaces ethernet (eth0 vers le réseau local et eth1 vers le modem ADSL) ; une interface virtuelle dummy0 est configurée en plus pour garder l’adresse IPv4 publique accessible même quand le lien PPP est tombé.

Le fichier interfaces

Le fichier /etc/network/interfaces contient la configuration des interfaces réseau de la machine, hors PPP. On lui ajoute, pour chaque interface concernée, une section IPv6. On peut en profiter pour forcer le lancement de radvd (cf plus loin) quand on monte une interface ethernet (la directive up). Au final, il ressemble à ça :

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 192.168.62.252
        netmask 255.255.255.0
        network 192.168.62.0
        broadcast 192.168.62.255
iface eth0 inet6 static
        address 2001:910:1021::1
        netmask 64
        up /etc/init.d/radvd restart

auto eth1
iface eth1 inet static
        address 10.0.0.2
        netmask 255.255.255.0
        network 10.0.0.0
        broadcast 10.0.0.255

auto dummy0
iface dummy0 inet static
        address 80.67.176.33
        netmask 255.255.255.255
        network 80.67.176.33
        broadcast 80.67.176.33
iface dummy0 inet6 static
        address 2001:910:1021:1::1
        netmask 64

L’adresse 80.67.176.33 est mon IP fixe publique. Les adresses IPv6 sont prises dans le sous-réseau /48 attribué par FDN ; chaque interface reçoit un /64.

radvd

Le démon radvd sert aux routeurs IPv6 à annoncer les préfixes locaux et un minimum de données de routage sur les différentes interfaces ethernet de la machine. Charge ensuite aux autres machines du réseau local d’ajuster leur configuration pour que « ça marche tout seul ». Sa configuration se trouve dans le fichier /etc/radvd.conf ; chez moi, il ressemble à ça :

interface eth0 {
        AdvSendAdvert on;
        prefix 2001:910:1021:0::/64
        {
                AdvOnLink on;
                AdvAutonomous on;
        };
};

La configuration PPP

Tout d’abord il faut ajouter les deux lignes suivantes au fichier de configuration de ppp (/etc/ppp/peers/fdn chez moi, mais ça dépend de votre config) :

ipv6 ,
ipparam fdn

La première ligne force pppd a négocier une adresse IPv6. Il s’agira probablement d’une adresse lien-local, mais peu importe, elle servira simplement à notre machine pour dialoguer avec l’équipement de FDN. La deuxième ligne est un paramètre qui sera passé en 6ème position au script /etc/ppp/ipv6-up, qui va lui-même le transmettre à ses collègues du répertoire /etc/ppp/ipv6-up.d sous le doux nom de PPP_IPPARAM. Vous voyez où je veux en venir ? Il suffit maintenant de poser un script /etc/ppp/ipv6-up.d/00defaultroute dont le contenu sera le suivant :

#!/bin/sh

if [ "$PPP_IPPARAM" = "fdn" ];
then
    /sbin/ip -f inet6 route del ::/0
    /sbin/ip -f inet6 route add ::/0 dev $PPP_IFACE
fi

Ne pas oublier de le rendre exécutable, et c’est gagné, on a une route par défaut.

Le routage

Maintenant, c’est la partie facile avec des petits détails à ne pas oublier. D’abord autoriser le routage IPv6 ; ça se passe dans le fichier /etc/sysctl.conf auquel on ajoute une ligne :

net.ipv6.conf.all.forwarding=1

On peut l’activer immédiatement au moyen de la commande suivante :

sysctl -w net.ipv6.conf.all.forwarding=1

Ensuite le firewall ; sur les noyaux Linux récents (par exemple le noyau 2.6.24-etchnhalf de Debian Etch), ça marche exactement comme en IPv4, il suffit de remplacer la commande iptables par ip6tables. Un exemple minimaliste :

#!/bin/sh

ip6tbl=/sbin/ip6tables

echo -n "Setting up IPv6 filter: "

/sbin/sysctl -w net.ipv6.conf.all.forwarding=0

$ip6tbl -F
$ip6tbl -X

$ip6tbl -P INPUT DROP
$ip6tbl -P OUTPUT ACCEPT
$ip6tbl -P FORWARD DROP

# conntrack
$ip6tbl -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$ip6tbl -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

######################################################
#### local
# icmp, aucazou
$ip6tbl -A INPUT --protocol icmpv6 -j ACCEPT --match limit --limit 30/minute

# services locaux
$ip6tbl -A INPUT -p tcp --dport 22 -j ACCEPT
$ip6tbl -A INPUT -p tcp --dport 25 -j ACCEPT
$ip6tbl -A INPUT -p tcp --dport 53 -j ACCEPT
$ip6tbl -A INPUT -p udp --dport 53 -j ACCEPT
$ip6tbl -A INPUT -p tcp --dport 80 -j ACCEPT

######################################################
#### reseau interne
# on peut sortir
$ip6tbl -A FORWARD -i eth0 -o ppp+ -j ACCEPT

# ping
$ip6tbl -A FORWARD -p icmpv6 -j ACCEPT
# ssh vers les machines internes
$ip6tbl -A FORWARD -p tcp --dport 22 -j ACCEPT

/sbin/sysctl -w net.ipv6.conf.all.forwarding=1

echo "done."

À adapter à vos besoins bien entendu. Voilà, c’est prêt ! Reste à trouver ce qu’on va faire de 65534 autres sous-réseaux.

Après avoir passé pas mal de temps à potasser la doc et à demander plein de trucs à Google, voici donc les quelques points qui m’ont posé problème. Attention, tout ceci concerne une infrastructure à base de CentOS 4 et 5, avec le serveur sous CentOS 5. Puppet lui-même est installé depuis EPEL.

Organisation

Dans le fichier site.pp, on définit juste des classes « conteneurs » comme suit :

class lamp {
  include php
  include mysql
}

Les autres classes sont définies dans des fichiers à part (php dans classes/php.pp et ainsi de suite). Ça, c’est une convention plus qu’autre chose mais en pratique ça aide à avoir les idées claires.

LDAP

J’utilise LDAP pour stocker les infos relatives aux clients. Pour que ça fonctionne, il faut :

• installer ruby-ldap sur le serveur
• ajouter, toujours sur le serveur, un fichier /etc/puppet/puppetmasterd.conf avec le contenu suivant :

[main]
    vardir = /var/lib/puppet
    logdir = /var/log/puppet
    rundir = /var/run/puppet
    ssldir = $vardir/ssl

[puppermasterd]
    node_terminus = ldap
    ldapserver = ldap.ircam.fr
    ldapbase = ou=Hosts,dc=ircam,dc=fr

Pour les clients, tout se passe dans l’annuaire lui-même : on leur ajoute la classe puppetClient et un champ puppetclass qui contient la liste des classes.

dn: cn=system.ircam.fr,ou=virtuels,ou=Hosts,dc=ircam,dc=fr
puppetclass: lamp

Pour le moment, le noeud default est encore en dur dans site.pp, ça râle dans les logs de puppetmasterd, il faudra le pousser dans LDAP un jour ou l’autre.