Soit une machine avec la configuration suivant:

• RAID 1 ⇒ /boot
• RAID 1 ⇒ LVM ⇒ xen 8G ⇒ /
• Debian Etch
• Xen 3.0… 32 bit

Le but: passer en Xen 64 bit , sous Lenny !

Afin de ne pas casser la machine en production, j'expérimente sur une autre machine.

Donc, installation de Etch a partir d'un cd… classique.

# aptitude install linux-image-xen-686 xen-hypervisor xen-linux-system-2.6.18-6-xen-686
# apt-get install xen-ioemu-3.0.3-1
# aptitude install xen-tools

Rebooter sous Xen.

Configurer le réseau, pour avoir:

# cat xend-config.sxp | egrep -v "^(#|$)"
(network-script 'network-bridge netdev=eth0 bridge=xenbr0')
(network-script network-dummy)
(vif-script vif-bridge)
(dom0-min-mem 196)
(dom0-cpus 0)

Et puis:

# /etc/init.d/xend restart
Restarting XEN control daemon: xend.

Ok?

winleft:/etc/xen# brctl show
bridge name     bridge id               STP enabled     interfaces
xenbr0          8000.feffffffffff       no              vif0.0
                                                        peth0

il est possible que ca ne fonctionne pas… grrrrr

Recuperer tout la liste des paquets installé sur la source:

# dpkg --get-selections | grep install | grep -v linux-source > /tmp/selections.txt

Copier cela sur la machine de test:

$ scp ..../tmp/selections.txt .

Puis installation de tout les paquets!

# apt-get update
# cat selections.txt | dpkg --set-selections

Et puis:

# apt-get dselect-upgrade

Modifier /boot/grub/menu.lst afin d'avoir aussi:

# xenkopt=console=tty0 xencons=off

Et puis:

# update-grub

Reboot pour voir si tout va bien.

On tester quelques DomU en fonctionnement…

Sur la source:

# lvs --units k /dev/vgraid1/bindtest*
  LV            VG      Attr   LSize       Origin Snap%  Move Log Copy%
  bindtest      vgraid1 -wi-a- 4194304,00K
  bindtest_swap vgraid1 -wi-a-  262144,00K

Sur la machine de test:

# lvcreate -L 4194304K -n bindtest vgraid1
  Logical volume "bindtest" created
# lvcreate -L 262144K -n bindtest_swap vgraid1
  Logical volume "bindtest_swap" created

Toujours sur la machine de test:

# nc -lp 32767 | dd of=/dev/vgraid1/bindtest

(On est en attente sur le port 32767)

Puis sur la source:

# dd if=/dev/vgraid1/bindtest bs=4k | nc 192.168.0.52 32767

Toujours sur la source:

# mkswap /dev/vgraid1/bindtest_swap

Recuperer la configuration du “domU” :

# cd /etc/xen
# scp .../bindtest.cfg .

Adapter la configuration, si necessaire. Et puis:

# xm create bindtest.cfg -c

Aprés avoir créé les volumes (qui sont donc encore vierge).

Sur la source:

# xm save wwwcave wwwcave.save

Sur la destination:

# nc -lp 32767 | dd of=/dev/vgraid1/wwwcave

Sur la source:

# dd if=/dev/vgraid1/wwwcave bs=4k | nc 192.168.0.52 32767

Pareil pour le swap:

(source)# nc -lp 32767 | dd of=/dev/vgraid1/wwwcave_swap
(destination)# dd if=/dev/vgraid1/wwwcave_swap bs=4k | nc 192.168.0.52 32767

Puis transferer la sauvegarde et la configuration:

# cd /etc/xen
# scp .../etc/xen/wwwcave.cfg .
# scp .../etc/xen/wwwcave.save .

Et puis:

# xm restore wwwcave.save

Recuperer un domu sans l'arreter, grace à lvm.

Sur la source:

# sync
# lvcreate -s -L 1G -n netcave_snap /dev/vgraid1/netcave

Transferer l'image “netcave_snap” comme vu ci-dessus, mais en prenant la taille de “netcave”!

Sur la destination, vérifier le disk…

# fsck.ext3 /dev/vgraid1/netcave

Booter sur le CD d'installation de Debian 5.00 AMD64 …

On va installer ce nouveau système sur une nouvelle partition !
Et aprés, on reinstallera les services !

A ce moment, choisir le partionnement “manuel”.

1. desactiver toutes les partitions swap
2. creer une nouvelle partition (lvm) pour recevoir le systeme
3. point de mountage: ext3 “/”
4. creer aussi un swap (qui sera le seul actif, donc)
5. raviver la partition “boot”, donc: point de montage, ext3 “/boot”
6. ⇒ forcer l'effacement de cette partition (ça sera plus propre ensuite)

Poursuivre l'installation…

A la fin, “grub” pose une question pour s'installer, moi j'ai dit:

(hd0)

et voila.

$  uname -r
2.6.26-1-amd64
$ file /bin/ls
/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped

Ok.

# aptitude install xen-hypervisor linux-image-xen-amd64 
# aptitude install xen-tools

par de “ioemu” ? et comment on fait pour windows ?

je comprend pas le commentaire du package “old-style”: c koi ce border, there are a new style ???

Redemarrer sous xen…: reboot

# uname -r
2.6.26-1-xen-amd64

Faire en sorte d'avoir dans /boot/grub/menu.lst

## Xen Linux kernel options to use with the default Xen boot option
# xenkopt=console=tty0 xencons=off

Sans réseau, point de salut !

Ce qu'il y a dans le reseau:

# egrep -v "^(#|$)" /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
auto xenbr0
iface xenbr0 inet static
      address 192.168.0.52
      netmask 255.255.255.0
      gateway 192.168.0.254
      broadcast 192.168.0.255
      bridge_ports eth0
      # optional
      bridge_stp off
      bridge_maxwait 0

activer la methode “debian” (avec le bridge): sinon, bang! plus de réseau

Dans /etc/xen/xend-config.sxp, faire en sorte d'avoir:

# egrep -v "^(#|$)" xend-config.sxp
(network-script network-dummy)
(vif-script vif-bridge)
(dom0-min-mem 196)
(dom0-cpus 0)
(vncpasswd '')

Et puis:

# /etc/init.d/xend restart

Bonne chance.

Modifier la config de chaque “DomU” afin d'avoir:

kernel  = '/boot/vmlinuz-2.6.26-1-xen-amd64'
ramdisk = '/boot/initrd.img-2.6.26-1-xen-amd64'
#kernel  = '/boot/vmlinuz-2.6.18-6-xen-686'
#ramdisk = '/boot/initrd.img-2.6.18-6-xen-686'

extra = 'clocksource=jiffies'

Le “jiffies” c'est pour un problème d'horloge d'effectueuse sur l'ensemble des DomU !

Mounter chaque “DomU” …

# mkdir /mnt/domu
# mount /dev/vgraid1/<nom_du_volume> /mnt/domu

… et faire les modifications suivantes:

# cp -dpR /lib/modules/2.6.26-1-xen-amd64 /mnt/domu/lib/modules

… modifier “…/domu/etc/inittab” afin d'avoir:

1:2345:respawn:/sbin/getty 38400 hvc0
#1:2345:respawn:/sbin/getty 38400 tty1
#2:23:respawn:/sbin/getty 38400 tty2
#3:23:respawn:/sbin/getty 38400 tty3
#4:23:respawn:/sbin/getty 38400 tty4
#5:23:respawn:/sbin/getty 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6

sinon, plus de “console” !

Mais aussi, editer …/domu/etc/securetty et ajouter:

# TJ ------
# xen console
hvc0

Sinon, 'root' ne pourra pas se connecter via la console xen !

Demarrer “DomU” et tester:

# xm create <nom_du_fichier_de_conf_du_domu> -c
...
# file /bin/ls
/bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
# uname -r
2.6.26-1-xen-amd64

Etrangement, ca fonctionne…

Pour les DomU “Etch”, il y a un peu plus de travail:
Installer “udev” sinon “PTY allocation request failed on channel 0”.

Faire attention au changement de “MAC” dans les configs des DomU, car “udev” va creer une nouvelle interface “ethX”.

Y a surement plus simple, (par exemple, sans re-installer a la main tout les packages), mais ca fonctionne.