Xen

De Cliss XXI
Révision datée du 6 août 2010 à 10:38 par imported>SylvainBeucler (→‎Liens)
Sauter à la navigation Sauter à la recherche

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-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

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)
  • 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 et ramdisk 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 initial 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):
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

Dans ces cas il faut de quoi voir l'écran: 

* PV: regarder la configuration de vbf (virtualframe buffer) pour un accès VNC.
* HVM: en standard

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.
  • 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
Récupérée de « https://doc.cliss21.com/index.php?title=Xen&oldid=2709 »