Xen
Vocabulaire
- Hyperviseur: socle d'exécution
- Dom0 = hôte
- DomU = invité = sous-système virtualisé
Dom0 comme DomU sont des noyaux Linux modifiés pour passer par l'hyperviseur Xen à la place d'accéder directement aux ressources du système. Dom0 et DomU peuvent utiliser la même image noyau - c'est même souvent le cas.
Avec une installation Debian Etch standard:
- /boot/xen-3.0.3-1-i386-pae.gz : hyperviseur (on boot dessus)
- /boot/vmlinuz-2.6.18-4-xen-686 : noyau Linux modifié à utiliser pour Dom0 et DomU
- /boot/initrd.img-2.6.18-4-xen-686 : image ramdisk associée au noyau Linux modifié
Survie
man xm
- Lister les DomU:
xm list
- Lancer un Xen (chemin relatif à
/etc/xen/
):
xm create auto/egroupware
- Éteindre un Xen (utiliser le nom donné par
xm list
):
xm shutdown NOM
- Éteindre tous les Xen:
xm shutdown -a
- Redémarrer:
xm reboot NOM
- Entrer dans le Xen en mode console pour débugger (sortie comme dans telnet:
Ctrl + ]
):
xm console NOM
Installation dans le cas où tout va bien
Base:
aptitude install xen-linux-system-2.6.26-2-xen-686 # noyau, hyperviseur, etc. aptitude install xen-utils # xend, xm... aptitude install xen-tools # outils pour créer un DomU
Un test avec xen-create-image 3.2:
xen-create-image --hostname test-drbd --kernel /boot/vmlinuz-2.6.26-2-xen-686 \ --initrd /boot/initrd.img-2.6.26-2-xen-686 \ --dist lenny --mirror http://monmiroir:9999/debian/ \ --dhcp --lvm VG0 --size 4G \ --role udev
En 3.0:
xen-create-image --hostname montest --kernel /boot/vmlinuz-2.6.18-6-xen-686 \ --initrd /boot/initrd.img-2.6.18-6-xen-686 \ --debootstrap --dist etch --mirror monmiroir:9999 \ --dhcp --lvm VG0 --size 4G
Survival:
xm list # list running Xen instances xm create yourxen # start an instance xm console yourxen # enter an instance, type C-] to quit xm destroy yourxen # force shutdown
Post-install
- Désactiver ou définir le mot de passe root
- Copier les clefs SSH
- Vérifier
/etc/hosts
(127.0.0.1 fqdn host localhost
) dpkg-reconfigure debconf # priority -> medium, !high
- Dans le DomU, dans
/etc/inittab
:
1:2345:respawn:/sbin/getty 38400 hvc0
- Vérifier la configuration réseau:
vif = [ 'bridge=br-xen, mac=00:16:3E:59:2A:ED' ]
- Activer VNC:
vfb = ['type=vnc, vncunused=1']
- Déplacer la configuration dans /etc/xen/auto/
En plus, pour Etch:
- À la place de copier /lib/modules/2.6.26-N-xen-686 à chaque mise à jour de sécurité du noyau depuis le Dom0, installez linux-modules-xen-686/amd64 dans le DomU
- Forcer la reconfiguration du fuseau horaire (tzconfig / dpkg-reconfigure tzdata)
- Configurer le sources.list (s/stable/etch/)
Le pont / bridge
auto br-xen iface br-xen inet static address 192.168.1.145 netmask 255.255.255.0 gateway 192.168.1.1 bridge_ports eth0 # bridge_ports none # optional bridge_stp off bridge_maxwait 0 bridge_fd 0 #bridge_hello 0
Les problèmes pénibles de Xen
- Vole/désactive les ports séries par défaut - ce qui est loin d'être pratique sur des serveurs dédiés, ou le port série est l'accès de secours en cas de problème réseau. Solution: ajouter xencons=tty6 dans le grub.conf (pour Xen 3.0 / Etch, apparemment corrigé dans Xen 3.2 / Lenny)
- Les paquets Debian ne fournissent que des binaires avec support PAE activé. Si vous voulez tester sur votre portable à base de Pentium-M (sans support PAE), vous n'avez plus qu'à installer votre propre noyau, car les paquets Debian ne fonctionneront pas (compilés en mode PAE uniquement; erreurs PAE mode mismatch in Xen (xen=no Dom0=yes) ou Cannot execute a PAE-enabled kernel on a PAE-less CPU au boot). Utiliser
grep pae /proc/cpuinfo
pour voir si votre processeur gère PAE. C'est à se demander pourquoi une version de l'hyperviseur en mode non-PAE est disponible :/ - Des ralentissements et des bugs au niveau du clavier dans certains cas, pas tout le temps, même avec libc6-xen: répétitions aléatoires de touches au moment de la frappe, ralentissement impressionnant de gnome-terminal.
- Des problèmes bizarres avec perte de connexion réseau, des messages
xen_net memory squeeze in netback driver
sur la console, vraisemblablement dès que l'on utilise trop de mémoire (ici 4G/8G sur 32bit sur une machine 64bit, probablement avec APE. Une solution qui n'explique pas vraiment le problème (et qui apparement ne fonctionne pas pour tout le monde) consiste à limiter la mémoire du dom0 de manière identique en deux endroits (GRUB et config) [1]:- boot/grub/menu.lst:
xenhopt=dom0_mem=256M
- /etc/xen/xend-config.sxp:
(dom0-min-mem 256)
- boot/grub/menu.lst:
- Des
Kernel BUG at drivers/xen/core/evtchn.c:481
de temps à autres. Solution de contournement [2]: limiter Dom0 à un processeur via(dom0-cpus 1)
dans/etc/xen/xend-config.sxp
. Je suis de moins en moins rassuré sur le fiabilité de ce truc. - Sous Debian, à chaque mise à jour de sécurité noyau avec nouvelle ABI (ex: 2.6.18-5-686 => 2.6.18-6-686), penser à mettre à jour
kernel
etramdisk
dans/etc/xen/*.cfg
, et mettre à jour/lib/modules
dans les DomU. Il n'y a pas de paquet générique indépendamment de la version, donc au niveau paquets ça donne:
## Dom0 aptitude install linux-image-xen-686 xen-linux-system-2.6.18-6-xen-686 # fix /etc/xen/*.cfg, install DomU packages below, reboot aptitude purge linux-image-2.6.18-5-xen-686 linux-modules-2.6.18-5-xen-686 xen-linux-system-2.6.18-5-xen-686 ## DomU aptitude install linux-modules-2.6.18-6-xen-686 aptitude purge linux-modules-2.6.18-5-xen-686 # 'xm shutdown' (NOT reboot) and 'xm create' in Dom0
Migration / relocation
La commande est
xm migrate vm host xm migrate --live vm host
Apparemment cela ne concerne que l'état mémoire de la machine virtuelle. Pour le disque, il faut utiliser un disque réseau, ou bien faire le déplacement des données à la main.
Dans /etc/xen/xend-config.sxp
, sur l'hôte distant, pour accepter la migration:
(xend-relocation-server yes) (xend-relocation-port 8002) (xend-address ) (xend-relocation-hosts-allow '^your other host IP$')
Dans le même ordre d'idée, il est possible de mettre un serveur en pause, par exemple au moment d'un reboot du Dom0. Une fois réactivée, la machine est restaurée à l'identique: l'uptime ne sera pas mis à zéro, les connexions TCP/IP seront même toujours valides!
Installation semi-manuelle avec l'image binaire officielle
Le site officiel est xensource.com, mais est bourré de propagande liée à une obscure "vente" de produits "entreprise". Bref allez directement sur http://xen.xensource.com/ , puis sur la page de téléchargement. On prend ici une des tarballs binaires; choisissez 32bit, 32bit+pae ou 64bit en fonction de votre système.
tar xzf xen-3....tar.gz cd dist ./install.sh # Image initrd: depmod 2.6.16.29-xen update-initramfs -k 2.6.16.29-xen -ct update-grub
Ça fonctionne, mais:
- 2.6.16: carte réseau non gérée (malgré la présence du module concerné)
- 2.6.18: carte réseau OK, mais des BUG en rafale dans la console à propos de vmalloc, et de notes de evbug.c dès qu'on touche au clavier - pas rassurant..
Installation manuelle
Vous récupérez une version de Linux xenifiée, et vous la compilez comme d'habitude, avec un panneau menuconfig en plus pour paramétrer Xen.
make world make install
permet de recréer l'image binaire officielle.
Pour recompiler avec une config perso? TODO. Le README propose:
make linux-2.6-xen-config CONFIGMODE=menuconfig
mais cela installe un .config assez lourd. Je préfèrerais un 'defconfig'.
Quelle version du noyau Linux?
Les tarballs officielles sont basées sur des noyaux relativement vieux (2.6.16 pour Xen 3.0, 2.6.18 pour Xen 3.1). On trouve quelques forward-ports chez RedHat: http://hg.et.redhat.com/kernel/ (utilisés notamment dans le noyau 2.6.18 de Etch).
Pour faire simple
Vous pouvez toujours installer Xen depuis une instance de QEMU, mais lancée avec -no-kqemu
; évidemment ça va ramer, mais tant que c'est le processeur et pas vous... :)
Mise à jour Etch -> Lenny
Configurations mixtes:
- Il est possible de lancer un domU Etch depuis un domU Lenny: conserver les noyaux dans le dom0
- Il est possible de lancer un domU Lenny en kernel Etch: conserver les modules linux-module-xen dans le domU
- Il n'est apparemment pas possible de lancer un domU Lenny en kernel Lenny depuis un dom0 Etch: mais il y avait différentes erreurs liées à Python, au support du nouveau Xen, etc., donc pas sûr à 100%
Conclusion on peut mettre à jour le dom0 ou bien le domU en premier, c'est comme on veut, juste bien conserver les anciens noyaux (dom0) et les anciens modules (domU).
Dom0
Après la mise à jour du système:
apt-get install xen-linux-system-2.6.26-2-xen-686 apt-get install xen-utils-3.2-1
Puis modifier les lignes kernel
et ramdisk
dans /etc/xen/*
:
kernel = '/boot/vmlinuz-2.6.26-2-xen-686' ramdisk = '/boot/initrd.img-2.6.26-2-xen-686'
DomU
Choses à faire quand on passe du noyau 2.6.18 au noyau 2.6.26.
Installer les nouveaux modules noyaux (utile pour iptables notamment):
apt-get install linux-modules-xen-686 # ou bien apt-get install linux-modules-xen-amd64
Installez udev
apt-get install udev
Visiblement Xen nettoie /dev
sans le repeupler proprement, du coup évidemment c'est le foutoir, avec des erreurs du type "Mount point '/dev/shm' does not exist. Skipping mount. (warning).", et en particulier /dev/pts
n'est pas monté ce qui casse la connexion SSH (penser à utiliser la syntaxe ssh you@host command
pour dépanner).
Faites écouter getty sur hvc0
, qui est selon toute vraisemblance tty1
mais version Xen (histoire de faire simple). Dans votre /etc/inittab
:
1:2345:respawn:/sbin/getty 38400 hvc0
Afficher les informations de démarrage sur le port série
Notre cible est le port série virtuel du serveur, détecté comme port série numéro 2 (ttyS1).
Modifier /boot/grub/menu.lst
comme suit:
# xenhopt=com2=115200,8n1 console=com2,vga # xenkopt=console=tty0 console=hvc0
Puis lancez:
update-grub
pour mettre à jour les entrées de noyau automatiques.
Faites écouter un getty sur hvc0
dans /etc/inittab
:
co:2345:respawn:/sbin/getty -h -L hvc0 115200 ansi
pygrub
pygrub permet d'amorcer le domU à partir d'un noyau installé dans le domU (et non pas dans le dom0). Cela permet de gérer via APT/yum/etc. des noyaux d'autres distributions, d'autres versions de la distributions, d'autres architectures (32/64bit), etc. que le dom0. Cela permet également de générer des images initrd propres (en fonction du domU et pas du dom0). Les noyaux Xen du Dom0 restent utiles pour l'installation/bootstrap initiale du domU.
Dans le domU:
- Installer le noyau
- Installer GRUB
- Préparer un
/boot/grub/menu.lst
valide- On pourra utiliser
update-grub
- Pour cela il est nécessaire de créer un faux /dev/sda (en plus des LVM-partitions sda1, sda2, etc):
- On pourra utiliser
dd if=/dev/null of=/etc/xen/mbr/$name-sda bs=1M seek=1 disk = [ ... 'file:/etc/xen/mbr/$name-sda,sda,w', ... ]
- Inutile d'installer grub sur le MBR
Dans le fichier de configuration du domU:
bootloader='/usr/lib/xen-3.2-1/bin/pygrub'
- commenter les lignes "kernel" et "ramdisk".
- dans la section 'disk', positionner la partition contenant le noyau en premier
Autres méthodes d'amorçage
- pypxeboot: amorçage par le réseau pour les invités Xen
- cdrom: apparemment par le biais d'une image ISO
D'après la page Xen du wiki Debian, Xen PV ne gère pas les installateurs des distrubutions directements, à la place celles-ci propose des solutions de contournement pour faire fonctionner l'installateur dans Xen PV. Xen HVM gère l'installateur sans modification.
Bref, pour les PV on reste sur des méthodes en ligne de commande, sauf gros bricolage du D-I?
VNC
- PV: regarder la configuration de
vfb
(virtualframe buffer)
vfb = ['type=vnc,vncdisplay=2'] vfb = ['type=vnc,vncunused=1']
- HVM: en standard (
builder="hvm"
,vnc=1
) ?
Définition dans libvirt
Les DomU en cours d'exécution sont reconnus par défaut. Pour qu'ils soient persistants (et relançable depuis virt-manager), il faut les convertir:
mkdir -m 755 /etc/libvirt/xen/ xm create mydomu.cfg virsh dumpxml mydomu > /etc/libvirt/xen/mydomu.xml virsh define /etc/libvirt/xen/mydomu.xml
Pour libérer le slot (par exemple pour le reconfigurer):
virsh undefine mydomu
Liens
- Debian Etch Xen Install: config de base
- Create DomU: script de base
- Xen@Debian Wiki: les paquets de base (pour du PAE)
- Xen 3 for Debian: une introduction; recommande LVM pour les images disques et le bridging pour le réseau
- Introduction: par Free-Electrons, également membres de l'APRIL; ils parlent de RAID mais utilisent des images disques (et non des partitions dédiées) - pas très efficace. Utilisent des adresses locales 10.0.0.X pour les DomU avec un NAT sur le Dom0.
- Manuel de l'utilisateur: spartiate
- Xen console grabbded /dev/ttyS0: un truc pour réactiver le port série
- 32bit and 64bit: qui peut lancer qui?
- Xen - Debian Wiki: notamment la section Additional note for domU on lenny using xen-tools (mais notez qu'elle ne dit pas comment corriger les installations existantes, ce que nous faisons plus haut), et la partie sur le double affichage écran / port série