Xen: trucs et astuces.

Xen est clairement mon hyperviseur favori. Lorsque l’on parle de serveurs en production, sur des systèmes Debian, c’est assurément un très bon choix . L’utilisant depuis un petit moment déjà, je tenais à partager quelques trucs et astuces que j’ai collecté au fil du temps
Xen est très performant, stable et robuste… à condition de bien comprendre ce que l’on fait, et pourquoi on le fait ainsi! Voici donc quelques trucs et astuces collectés depuis mes premiers pas avec Xen, en 2006 si je me souviens bien (merci @pierrotcarre pour cette découverte).

• Pas de services sur le dom0
  Votre hyperviseur a un boulot absolument crucial: s’assurer ue chaque guest a bien accès aux ressources qui lui nécessaires, dans le respect de ce qui lui a été permit. En soit cette tâche n’est pas gourmande mais elle est stratégique! N’allez pas distraire votre hyperviseur avec des tâches secondaires qui ne lui incombe pas, et qui de plus, risquerait de provoquer des plantages ou autres bugs. Je pense là plus particulièrement, à des setup où, pour économiser un SAN, on confie au dom0 (et à son administrateur) la lourde et complexe tâche du stockage et de la réplication de données (avec DRBD par exemple)
• Utilisez dom0_mem!
  Ce paramètre permet à l’hyperviseur de ne s’attribuer que la quantité de mémoire utile à son bon fonctionnement. Si vous respectez la règle précédente, vous ne devriez pas avoir besoin de plus de 512MB sur un dom0 à base de Lenny ou de Squeeze. Cette valeur est à ajuster en fonction des distribution et des packages qui sont installé de base.
• Gestion par pool de vos dom0
  L’une des fonctionnalités les plus attractives de virtualisation est encore la possibilité de migrer vos machines virtuelles d’un dom0 à un autre sans éteindre la VM et donc sans couper les service.
  Cela nécessite cependant de se conformer à quelques règles.
  La première est que les disques virtuels de vos VMs doivent être accessibles pour le dom0 source et pour le dom0 de destination, lorsque vous décidez de migrer une VM. Ca semble logique en effet mais il est bon de le re-préciser. Il en va de même pour toutes les ressources de votre VM. Ainsi une interface réseau bridgée devra retrouver le même bridge pour pouvoir y être re-pluggée sur le dom0 de destination. Plus subtile mais tout aussi important: Les vcpus attribués à vos VMs possèdent les fonctionnalités des CPU du dom0. Veillez donc à toujours migrer une VM sur un dom0 ayant un CPU identique (ou du moins qui présente les même fonctionnalités). Imaginez que vous êtes en train de faire du skate et que soudainement vous perdez la faculté de skater… au mieux vous tombez, au pire vous vous cassez quelque chose. D’une façon générale il est donc sage d’organiser vos serveurs physiques en pools selon leurs capacité à accéder à des ressources disques, réseaux, mais aussi selon leur « profil CPU ».
• Les VMs supportent mal le Jet Lag!
  Lorsque vous migrez une VM entre 2 dom0 vous devez vous assurez que vos hôtes sources et destinations sont parfaitement synchronisés. Pour cela je ne saurez trop vous conseiller de déployer systématiquement ntpd sur vos dom0! En effet votre VM n’appréciera que très moyennement de changer d’heure à chaque migration!
  Même avec cette précaution j’ai pu constater sur Lenny des soucis de synchronisation post-migration. Il est donc conseillé dans ce cas d’utiliser les paramètres suivant dans vos fichiers de configuration Xen:
  extra='clocksource=jiffies'
  Ainsi que sur le dom0 avce la commande suivante:
  echo "jiffies"> /sys/devices/system/clocksource/clocksource0/current_clocksource
  Les jiffies sont considérées comme un choix par défaut et doivent être évités autant que possible. Aussi n’utilisez ce paramètre que si vous rencontrez un message du type:
  clocksource/0: Time went backwards
  Le wiki Xen de debian fait état d’un autre workaround pour contrer ce problème sans utilisez les jiffies… Je ne l’ai jamais testé jusqu’ici: http://wiki.debian.org/Xen#Possible_problems_and_bugs-1 workaround#3
• Utilisez pygrub pour la paravirtualisation
  PyGrub n’est pas un bootloader à proprement parlé. Il s’agit simplement d’un utilitaire qui va monter allé chercher sur le disque virtuel de la VM le paramètres de démarrage dans le config de grub.
  Il va par exemple copier le kernel et l’initrd installé sur votre VM sur le dom0, il va définir le périphérique racine, la console, etc…
  Cela vous permet de boot votre VM avec le kernel que vous souhaitez (pour peu qu’il ait les capacités d’un domU, ce qui est aujourd’hui le cas pour tous les kernels récent, y compris vanilla). Vous pouvez ainsi utilisez le système de mise à jour de votre distribution pour garder un kernel à jour sans avoir à le recopier manuellement sur le dom0.
  A noter que pygrub doit supporter le système de fichier sur lequel se trouve la configuration de grub de votre VM. Au jour d’aujourd’hui, pygrub supporte les système ext2, ext3 et ext4 (au moins sur Debian Squeeze) et qu’un patch est disponible pour XFS: http://xen.1045712.n5.nabble.com/XFS-support-for-pygrub-patch-td3281142.html#a4387931
• Réseaux bridgés
  S’il est bien un sujet qui revient souvent sur les mailing-lists Xen, c’est le réseau: La configuration est relativement simple pourtant… à condition de comprendre ce que l’on fait … et de ne pas utiliser les options par défaut (si si c’est simple)!
  C’est en fait l’une des rares critiques que je porterais à Xen. Si vous souhaitez utiliser Xen en mode bridge (vos VMs ont accès au réseau physique sans routage, ni translation d’adresse), Xen vous propose d’utiliser le script network-bridge (dans /etc/xen/xen-config.sxp). Soyons clairs: ce script est une usine à gaz et un non sens absolu! Il n’offre rien que vous ne puissiez faire autrement et de façon plus « propre » te même complexifie considérable les choses. Il sera d’ailleurs retiré des version de Xen à venir (4.1.x).
  Donc pour utiliser l’accès réseau en mode bridge, faites confiance à ifupdown. C’est le gestionnaire réseau de debian le plus abouti il vous permet de mettre en œuvre des config très avancés en quelques de configuration dans le fichier /etc/network/interfaces.
  De façon basique ce fichier vous permet déjà de donner accès à vos VM au réseau ethernet de votre dom0:

auto xenbr0
iface xenbr0 inet static
bridge_ports eth0
bridge_maxwait 5
bridge_fd 0

Vous souhaitez y ajouter la notion de VLAN?
auto xenbr0
iface xenbr0 inet static
bridge_ports eth0.100
bridge_maxwait 5
bridge_fd 0

Un peu de redondance?
auto bond0
iface bond0 inet manual
slaves eth0 eth1

auto xenbr0
iface xenbr0 inet static
bridge_ports bond0.100
bridge_maxwait 5
bridge_fd 0

N’oublions pas de spécifier à Xen de ne faire que son boulot et rien d’autres en spécifiant ceci dans le fichier /etc/xen/xen-config.sxp
(network-script network-dummy)
Et de s’assurer qe le script en question existe et qu’il ne fait rien d’autre que… ne rien faire
cat /etc/xen/scripts/network-dummy
#!/bin/sh
exit 0

• Les connexions VNC pour l’intégration.
  La console embarquées dans Xen est vraiment très pratique (elle s’est grandement améliorée depuis les premières versions). Elle permet notamment, à l’inverse de la console VNC ou SDL, de faire des copier/coler, ce qui est toujours très pratique. Malheureusement la console la plus souvent utilisée par les utilitaires de management graphiques (Xen Cente, Convirt etc…) est la console VNC. Le mieux est encore de faire en sorte de disposer des 2!
  Pour cela il vous faudra configurer vos VMs (PV ou HVM) de façon à créer un périphérique framebuffer virtuel et modifier leur inittab.
  La configuration du framebuffer se fait en une ligne à rajouter dans le fichier de conf de la VM:
vfb=['type=vnc]
  Pfiuuu! Allez faire une sieste après un tel effort. Si vous n’avez pas sommeil, vous pouvez aller trifouiller dans les options vnc de Xen pour tweaker un peu le tout: man xmdomain.cfg!
  Coté VM la modification de l’inittab n’est pas bien compliquées non plus. Vérifiez simplement que vous avez les 2 lignes suivantes:
  1:2345:respawn:/sbin/getty 38400 hvc0
2:23:respawn:/sbin/getty 38400 tty1
  Dans cette configuration vous aurez une console série disponible via xm console et et une console série en VNC.
  A noter que les message de démarrage apparaitront sur la console définit en premier dans l’inittab.

Il y a certainement des manques, ou des oublis mais cette page reste non-exhaustive.