XEN : installation 3.4.2 sur Debian "instable"

XEN : installation 3.4.2 sur Debian "instable" jpp sam 12/12/2009 - 15:29

Depuis que je dispose d'une belle machine tout neuve j'ai eu l'envie de tester XEN. Mon installation Deian étant fondée sur la distribution "unstable" je suis donc resté dans la ligne en essayant d'installer la dernière version de XEN la 3.4.2.
L'installation se fait à grands coups de "apt-get" ou "aptitude" selon les goûts de chacun. Les paquets à installer sont :

xen-hypervisor-3.4-amd64 3.4.2-2
xenstore-utils 3.4.2-2
xen-tools 4.1.1
xen-utils-3.4 3.4.2-2
xen-utils-common 3.4.2-2

auxquels il faut ajouter

xen-utils-unstable 3.3 ?

Le volume à télécharger est assez faible # 15Mo.

L'installation se passe sans problèmes; merci aptitude.
Il faut ensuite se mettre à la recherche d'un noyau "xénifié" pour gérer le domaine 0.

La seule image Debian que j'ai trouvée en X86_64 est le 2.6.26-2-xen-amd64 dans la branche "stable" avec son inséparable paquet de modules.
Ce noyau convient en principe pour le domaine 0 et pour les domaines Utilisateurs.
Après moult essais ce noyau ne fonctionne pas sur mon matériel et se bloque presque au début avant les accès aux disques.
Le passage par la case compilation est obligatoire. En principe les dernières versions de noyau sont aptes à gérer le domaine 0 à condition de définir le bon paramétrage.
Après une petite recherche j'ai trouvé un noyau 2.6.31 modifié pour supporter le domaine 0 sur http://x17.eu/xen/
où plusieurs noyaux sont disponibles, j'ai choisi le suivant :

linux-2.6.31.4-xen-r4.aka.suse-xenified-2.6.31.3-1.1.src.rpm-rebased.patches.by.andrew.lyon.tar.gz

qui me plaisait bien car très récent et réalisé par un gourou connu.
Le fichier ".config" que j'ai utilisé est en téléchargement en bas de cette page, il suffira de le renommer en ".config".
Il faut ensuite ajouter le lancement de XEN et du noyau fraîchement compilé dans le fichier grub.cfg aucune opération ne le fait automatiquement.
Il y a une petite bizarrerie dans la configuration : il faut mettre deux fois (???) certains paramètres ce qui ne semble pas évident et peut dépendre de la version de GRUB utilisée (1.97 pour moi). Pour simplifier je donne ci dessous la partie adéquate du "grub.cfg" :
menuentry "Debian XEN GNU/Linux" {
    insmod ext2
    set root=(hd0,1)
    search --no-floppy --fs-uuid --set 116c3b30-4586-4f25-b7c1-c0d5c5a5b003
    multiboot    /xen.gz                 /xen.gz noreboot    dom0_mem=1536M
    module        /vmlinuz-xen     /vmlinuz-xen        root=/dev/md0 ro noquiet
    module       /initrd-xen
}
Avec tout cela le système se lance et XEN es activé mais lorsque je tente la création d'une machine virtuelle il y a un problème :
Error: HVM guest support is unavailable: is VT/AMD-V supported by your CPU and enabled in your BIOS?
Simple oubli ... il suffit de rebooter en passant par le BIOS pour activer cette option.
Cette fois-ci on va pouvoir y aller :
- créer une Machine virtuelle avec un fichier de config "emprunté" et une image disque récupérée.
- xm new k2000-....
Unexpected error: <type 'exceptions.ImportError'>
Please report to xen-devel@lists.xensource.com
Traceback (most recent call last):
File "/usr/lib/xen-3.4/bin/xm", line 8, in <module>
    main.main(sys.argv)
File "/usr/lib/xen-3.4/lib/python/xen/xm/main.py", line 2997, in main
    _, rc = _run_cmd(cmd, cmd_name, args)
File "/usr/lib/xen-3.4/lib/python/xen/xm/main.py", line 3021, in _run_cmd
    return True, cmd(args)
File "<string>", line 1, in <lambda>
File "/usr/lib/xen-3.4/lib/python/xen/xm/main.py", line 1366, in xm_importcommand
    cmd = __import__(command, globals(), locals(), 'xen.xm')
File "/usr/lib/xen-3.4/lib/python/xen/xm/new.py", line 26, in <module>
    from xen.xm.xenapi_create import *
File "/usr/lib/xen-3.4/lib/python/xen/xm/xenapi_create.py", line 23, in <module>
    from xml.parsers.xmlproc import xmlproc, xmlval, xmldtd
ImportError: No module named xmlproc
xm create --> erreur : from xml.parsers.xmlproc import xmlproc, xmlval, xmldtd

Les dépendances de Debian sont pourtant en général bonnes ... on cherche un paquet "python-xml" ... qui existe bel et bien au milieu d'un très grand nombre de paquets python. Tiens il faudra que je me mette sérieusement à Python.

aptitude install python-xml

Et cela repart :
xm new k2000-xp1
Using config file "./k2000-xp1".

Ouuuiiii, cette fois-ci c'est bon, la MV est créée, on va pouvoir jouer. Je lance le NS5200 (j'y ai stocké l'image disque que l'on m'a prêtée) et ...
Je crée une nouvelle machine avec un fichier param récupéré avec l'image et légèrement modifié pour l'adapter (réseau et image disque) :
xm new mach_test
C'est OK !Il y a encore un petit problème la machine virtuelle ne se lance pas, la consultation du fichier de lancement (/var/log/xen/qemu-dm.....) montre que "qemu-dm" reçoit un paramètre qu'il n'est pas capable d'interpréter. Le paramètre concerné est "-videoram 16", ja construit vite fait un petit script shell "qemu-dm" qui "filtre" les paramètres, élimine le paramètre "videoram" et appelle le programme original renommé en "qemu-dm.real":
#!/bin/bash
OPTS=` echo $* | sed 's/-videoram .//' `
/usr/lib/xen-unstable/bin/qemu-dm.real $OPTS

Par ailleurs je constate que les fchiers de XEN sont un peu "en pagaille" dans les répertoires :

xen
xen-3.4
xen-common
xen-default
xen-tools
xen-unstable

Un peu de rangement ne ferait pas de mal et certains modules sont présents (et différents) dans plusieurs répertoires. Je renomme certains répertoires de "xen-unstable" pour donner la priorité aux modules de "xen-3.4").

Je lance le gestionnaire "virt-manager" mais la machine nouvellement créée n'apparait pas dans la liste ... tan pis je la lance à la main :
xm start mach_test
La machine apparaît dans virt_manager, j'ouvre l'écran et tout semble se dérouler correctement jusqu'au passage en mode graphique où l'écran est parfaitement illisible.
Je lance une connexion SSH vers la machine, c'est OK, la machine tourne normalement. Il me suffit de lancer le serveur VNC pour pouvoir me connecter en mode graphique.
C'est vraiment dommage que virt-manager ne donne pas accès directement au mode graphique, probablement un problème lié à "videoram".
Je tente de lancer une image Windows XP, le démarrage est OK, l'affichage est bon dans la phase de démarrage mais dès que l'écran de login doit s'afficher l'écran se brouille. La machine est parfaitement accessible et fonctionnelle en utilisant le mode Terminal Server avec "rdesktop".

Le fonctionnement est parfaitement souple, la souris réponds plutôt mieux qu'avec les versions antérieures de XEN.
"Virt-manager" ne montre pas les machines qui ne sont pas lancées et je ne trouve aucun paramétrage à ce sujet dans les préférences, il est donc impossible de lancer les machins depuis l'interface graphique puisqu'elles n'y deviennent visibles qu'après leur lancement.

Il me faut me mettre à la recherche d'une version convenable de "qemu-dm" et attendre la prochaine version de "virt-manager".

Dans un prochain article on va tester les possibilités de sauvegarde et de restauration de machines et peut-être même la migration de machines d'un serveur à un autre.

Mais en conclusion l'installation de XEN depuis la version Debian "instable" nécessite un travail assez important avant d'arriver à quelque-chose d'utilisable. Il me faut chercher un "qemu-dm" un peu plus récent (?) qui admette le paramètre videoram pour, peut-être, pouvoir profiter des écrans graphiques "en direct" depuis la console. Quand à "virt_manager" il n'affiche pas les machines inactives et les statistiques IO et réseau bien que présentes dans le paramétrage n'affichent pas de valeurs lorsqu'elles sont activées.
D'autres fonctions ne marchent pas par exemple un "xm save" suivi d'un "xm restore" déclenche une erreur irrécupérable. Si le restore ne fonctionne pas il en sera de même de la fonction "xm migrate".
Devant ces ennuis je vais tester la version complète fourni par Xensource mais cela sera un autre article.

Voir l'autre article

J'ai appris depuis que les mainteneurs de Xen pour Debian ont limité leurs activités à autoriser Debian comme domaine hébergé et abandonné la possibilité d'utiliser Debian en "Domaine-0" car cela nécessite la maintenance du paquet "qemu-dm" qui semble a priori fort délicate.
L'intégration dand le noyau officiel de la gestion d'un "Domaine-0" est en cours mais devrait durer encore assez longtemps car les modifications sont assez "intrusives" peut-être pour le noyau 2.6.40 ?