Ayant eu besoin d'installer plusieurs systèmes différents pour des tests je me suis tourné vers la solution des machines virtuelles. 
Etant un fervent partisan des logiciels libres j'ai choisi XEN  voir la définition sur : fr.wikipedia.org/wiki/XEN  
Le site officiel de Xen : www.xen.org

J'ai reçu, au cours d'un salon, un DVD Suse (SLES 11)  permettant d'installer un tel serveur, j'ai donc decidé d'utiliser ce système pour ma dernière acquisition, us système AMD 64 bits dual core. 
Je suis pourtant un fervent partisan de Debian, mais ayant eu à utiliser SUSE pour des installations professionnelles j'ai décidé de l'utiliser ici. 
Le système est constitué ainsi :

• carte mère ASUS
• Processeur AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
• 8Go de RAM (4 * 2Go)
• Disques : 2 * 250 Go de récupération + 2 * 1To tout neufs le tout en SATA2

J'ai décidé d'utiliser le RAID 1 logiciel sur tous les disques afin de sécuriser l'engin. 
Les deux disques de 250 Go (sda et sdb) supportent donc :

• Une partition "swap" chacun (sda1 et sdb2)
• Une partition "boot" en ext2 chacun (sda2 et sdb2) (l'une est une copie de l'autre)
• Une partition "système" en ext3 montée en RAID1 (sda3 + sdb3) de 16Go (md1)
• Une partition comprenant le reste du disque utilisée en RAID1 (sda4 + sdb4) et gérée par LVM

Les deux disques de 1To ont été divisés en deux partitions

• une partition (sdc1 ett sdd1) de réserve de 8Go pour pouvoir y mettre un autre système
• une partition montée en RAID1 (sdc2 + sdd2) de 980Go gérée en LVM (md0)

Toutes ces opérations ont été faites lors de l'installation avec l'installeur standard de SUSE qui est très agréable à utiliser et permet toutes les fantaisies dans la création des partitions. 
J'ai ensuite réalisé une installation standard de poste de travail en y ajoutant la gestion des machines virtuelles. 
La version installée de XEN était la 3.3.1 que je ne connaissais pas encore (j'ai utilisé professionnellement la 3.0, la 3.1 et la 3.2). Des machines que j'avais créées en 3.1 ont été démarrées sans problème après :

• Définition d'un disque de stockage système (vive LVM) de 16Go
• Recopie de la sauvegarde de la machine roginale réalisée par "dd" du disque système et "gzip" du résultat pour pouvoir le transporter facilement.
• Paramétrage de mon serveur DHCP pour attribuer une adresse fixe à cette nouvelle machine grâce à la MAC Address.
• Mise en place du fichier paramètres d'origine de la MV
• Mise à jour de ce fichier (nom du disque et des interfaces réseau et MAC Address)
• Lancement de la machine ... ça boote.
• Accès réseau OK

La machine fonctionne parfaitement, elle peut accéder à internet, on peut se connecter normalement sur ce nouveau système. 

Aujourd'hui j'ai une dizaine de machines virtuelles installées dont plusieurs peuvent fonctionner ensemble tant que je ne dépasse pas la mémoire disponible ! 
En effet chaque MV se voit attribuer un quota de mémoire et lorsqu'il ne reste plus de mémoire disponible XEN refuse sagement de lancer une nouvelle machine. 

Les VM c'est le pied. 

Dernières nouvelles :   le système passe sur SSD 
 

La déclaration d'une machine virtuelle se réduit à quelques paramètres permettant à XEN de créer l'environnement de cette machine. Il existe différentes manières d'écrire ces fichiers de configuration (y compris un mode XML), mais les éléments à paramétrer sont toujours les mêmes. En plus je préfère la syntaxe la plus simple en fichier texte "légèrement" structuré par l'usage des parenthèses carrées [ et ] pour les éléments multiples tels que disques ou interfaces réseau. 
Le paramétrage concerne les éléments typiques de toute machine qu'elle soit physique ou virtuelle : 

Nom de la machine (NAME) : 
C'est le nom de la machine tel que vous l'utiliserez pour "discuter" avec l'hyperviseur, exemple :

• name='amdx2-deb65'

Ce nom doit bien entendu être unique ... 
Identifiant  (UUID): 
Chaque MV doit disposer d'un identifiant différent des autres. L'identifiant est construit sous un format complexe afin d'éliminer les possibilités de doublon. Le programme "uuid" génère très bien ces identifiants. 
Un exemple : 
uuid='9e8c403f-bd93-75f7-1754-dde60e2803d9' 

CPU (VCPUS): 
Une nouvelle MV doit disposer d'au moins un CPU ! Mais elle peut en disposer d'autant que la machine physique servant de support peut lui en offrir. 
Le seul paramètre direct est donc le nombre de VCPU (CU Virtuels) attribués à cette machine, par exemple :

• vcpus=1

Mémoire (MEMORY) : 
C'est la quantité de mémoire attribuée à cette machine lors de son démarrage, la valeur est exprimée en MégaOctets, exemple :

• memory=1024

Comportement stop/start : 
Ce groupe comporte trois paramètres viennent contrôler le comportement de la machine lors des arrêts et redémarrage, les valeurs indiquées sont des standards:

• on_crash='destroy'
• on_poweroff='destroy'
• on_reboot='restart'

Je ne change jamais ces valeurs qui conviennent parfaitement pour les cas "normaux". 

Contrôle de l'horloge : 
Ce paramètre contrôle le comportement de l'horloge, j'ai toujours vu la valeur "0".

• localtime=0

Mode d'émulation : 
Ceci permet une émulation totale ou partielle. L'émulation partielle suppose des systèmes dont le noyau est prévu pour être "virtualisé" et est très coopérant, notamment au niveau des périphériques.

• builder='hvm'

Fournisseur des périphériques : 
C'est le nom du module d'émulation qui sera utilisé pour présenter à la MV un "hardware" cohérent.

• device_model="/usr/lib/xen/bin/qemu-dm"

Bootloader chargé du lancement du système. 
C'est le programme qui "lance" le système contenu sur le disque de la machine.

• kernel='/usr/lib/xen/boot/hvmloader'

Ici les paramètres sont destinés à une émulation totale (hardware virtual machine) pour utiliser un système virtualisé quelconque. 

Mode de boot. 
Selon la valeur (en direct de MSDOS)  "c" provoque un boot depuis le "disque dur virtuel", la valeur "d" provoque un boot depuis le lecteur de CD virtuel.

• boot='c'

Après la création initiale d'une nouvelle machine (pour laquelle on a mis "d") depuis le CD, il fat remettre cette valeur à "c" avant de rebooter la machine. 
Définition des disques dur virtuels. 
on définit dans ce groupe "disk" le lien entre le périphérique physique et la manière dont il est présenté au nouveau  

système.disk=[    'phy:/dev/HUGE_1/MV4,hda,w' ]

Ici il s'agit dune partition "phy"sique qui sera présentée comme disque "hda" au système avec droit d'écriture ("w"). 
Une image ISO sera présentée comme :

• 'file:/STOCKAGE/ISOS/debian-500-amd64-DVD-1.iso,hdd:cdrom,r'

Le lecteur de CD physique de la machine support sera présenté (en lecture seule ("r"), comme c'est normal pour un CDROM) sous la forme :

• 'phy:/dev/hdb,hdc:cdrom,r'

Carte(s) réseau : 
Plusieurs syntaxes existent (on peut même fournir l'adresse IP), je préfère celle-ci qui me permet d'utiliser mon mécanisme standard de DHCP. 
On doit ici fournir adresse MAC, nom du "bridge" géré par le domaine 0, le modèle de périphérique à émuler. Il y a ici deux interfaces réseau :

 

Et puis quelques autres paramètres que je ne touche jamais et que je vous livre "en vrac" :

• vnc=1
• vncunused=1
• apic=0
• acpi=1
• pae=1
• serial='pty'
• keymap='fr'

Ces valeurs me conviennent et je ne me hasarde pas à les changer. 

D'autres paramètres existent permettant de définir la priorité de la machine mais je préfère démarrer les machines avec la priorité standard et la modifier ensuite à l'aide des commandes "xm". 

Exemple de définition d'une machine (Debian 5.0 bien que cela ne soit pas visible dans la définition) :

ostype='other'
name='amdx2-deb67'
memory=1024
vcpus=1
uuid='8e8c485f-a093-75a5-f753-afe71e2803e9'
on_crash='destroy'
on_poweroff='destroy'
on_reboot='restart'
localtime=0
builder='hvm'
extid=0
device_model="/usr/lib/xen/bin/qemu-dm"
kernel='/usr/lib/xen/boot/hvmloader'
boot='c'
disk=[    'phy:/dev/SYSTEM/DEB67,hda,w',
#    'file:/STOCKAGE/ISOS/debian-503-amd64-netinst.iso,hdd:cdrom,r',
    ]
vif=['mac=00:16:3e:30:02:01,bridge=eth0,model=rtl8139,type=ioemu',
     'mac=00:16:3e:40:02:02,bridge=eth1,model=rtl8139,type=ioemu',
    ]
vnc=1
vncunused=1
apic=0
acpi=1
pae=1
serial='pty'
keymap='fr'

Ce petit article sans prétentions devrait démystifier la création de machines virtuelles. 
 

Il existe plusieurs manières de configurer le réseau dans un serveur XEN afin que les Machines Virtuelles (MV) disposent chacune d'un accès réseau. 
Les différents modes sont :

• NAT
• Bridge
• Route

Le plus simple pour moi est le mode "Bridge" car chaque MV dispose de sa propre adresse IP et de tous les ports disponibles sans aucun paramétrage spécifique au niveau du domaine-0. Dans mon cas où toutes les machines sont des machines de test bien à l'abri derrière un pare-feu sur la machine "pont" de mon réseau cela ne me pose pas de problèmes de sécurité. 
La situation pourrait être très différente sur des machines accessibles directement depuis Internet ou surtout dans le cas de machines de production où la sécurité est primordiale. Par ailleurs dans ce cas là les ports utilisés sont peu nombreux et la gestion du routage entre les machines  n'est pas trop évolutive. 
En effet je n'aimerais pas toucher à un script iptables compliqué sur des machines de production ..... au risque de bloquer l'accès à des ressources critiques. 

J'ai donc choisi le mode "Bridge" qui répond à mes besoins. 
Paramétrage du mode "Bridge".

• Au niveau du paramétrage de XEN.

Il s'agit de mettre en place les bons paramètres dans le fichier "xend-config.sxp".

• (network-script L-NT ) 
  c'est le script utilisé par le démon xend au démarrage pour initialiser le(s) bridge(s)
• (vif-script vif-bridge) 
  c'est le script utilisé par xend à la création de chaque interface de chaque MV

Comme je dispose de deux interfaces réseau j'utilise un petit script perso qui initialise les deux ponts d'un seul coup en appelant le script "standard" de Suse :

#!/bin/bash 
# L-nt : Start XEN bridge

MKBRIDGE () 
{ 
"$dir/network-bridge" "$@" vifnum=1 bridge=eth1 netdev=eth1 
sleep 1 
"$dir/network-bridge" "$@" vifnum=0 bridge=eth0 netdev=eth0   
brctl show 
echo '.' 
echo ' ' 
} 
MKBRIDGE $1 $2  

Les deux ponts sont activé et les MV peuvent se "brancher" et accéder aux réseaux. 

Le script standard OpenSuse ne traite qu'un interface il faut donc passer par un script intermédiaire. 
Par ailleurs le démarrage du script par le démon est effectué à un mauvais moment dans la séquence d'init et cela provoque des ennuis divers, je lance donc ce script complètement en fin de la séquence de boot ou "à la main" lorsque j'effectue des manips. 

Dernières nouvelles : 
Avec OpenSuse 11.2 le réseau est d'office installé en "pont" il ne reste rien à faire ... et cela marche sans problèmes. 
Le "pont" est créé automatiquement lors de l'installation et est utilisé même dans les modes non "Xen". 
Les performances réseau ne semblent pas en souffrir si ce n'est que la gestion du MTU fonctionne mal. Il est impossible de mettre un MTU à 4000 en automatique. Il est inutile de configure le MTU à 4000 avec les outils graphiques, cela n'a aucun effet. Même en remplissant les fichiers de configuration "à la main" avec la bonne valeur, on constate qu'après un reboot le MTU est retombé à 1500. J'aime bien avoir l'interface utilisant le iSCSI avec un MTU plus élevé. 
Attention la version 11.2 n'est pas encore finalisée et peut présenter quelques inconvénients voir l'article sur le SSD 

Arès avoir utilisé du XEN 3.0 puis 3.2 j'ai upgradé mon installation en OpenSuse 11.1 ( http://www.opensuse.org ) et Xen 3.3.1, puis j'ai trouvé dans OpenSuse factory une version 3.4.1 que j'ai tout de suite voulu essayer ... 
Comme j'ai du utiliser des "rpm" chargés un par un j'ai essuyé les problèmes de dépendances que j'ai résolu comme autrefois ... à la main. 
On charge un RPM, on le teste et on cherche le RPM xxx de la version yyy qui est demandé, cela dure un petit moment mais on y arrive à l'aide de RPMFIND.NET qui est toujours le dernier recours pour les RPM récalcitrants. 
Enfin j'y suis arrivé avec :

libeggdbus-1-0-0.5-1.12.x86_64.rpm 
libpolkit0-0.94-2.3.x86_64.rpm 
libpolkit-gtk-1-0-0.94-2.1.x86_64.rpm 
libpolkit-qt0-0.9.2-3.1.x86_64.rpm 
libreadline6-6.0-17.1.x86_64.rpm 
libselinux1-2.0.80-4.6.x86_64.rpm 
libuuid1-2.16-3.1.x86_64.rpm 
libvirt-0.7.1-13.1.x86_64.rpm 
libvirt-python-0.7.1-13.1.x86_64.rpm 
parted-1.9.0-1.12.x86_64.rpm 
polkit-0.94-2.3.x86_64.rpm 
virt-manager-0.8.0-10.1.x86_64.rpm 
xen-3.4.1_19718_04-23.1.x86_64.rpm 
xen-doc-pdf-3.4.1_19718_04-23.1.x86_64.rpm 
xen-libs-3.4.1_19718_04-23.1.x86_64.rpm 
xen-tools-3.4.1_19718_04-23.1.x86_64.rpm 
 

Et j'ai pu installer mon nouveau XEN 3.4.1 ! 
A première vue, rien d'extraordinaire, les machines se lancent et tournent plutôt bien. Le fonctionnement est stable avec 4 ou 5 MV en route, le fonctionnement global et la performance sont très corrects. 
Seule ombre au tableau le gestionnaire graphique "virt-manager" a perdu un certain nombre de gadgets d'affichage, on disposait de l'usage CPU avec un graphe, de la taille mémoire, du combre de CPU attribués à chaque machine, c'est fini on ne peut plus tout avoir simultanément. Ce n'est pas très grave mais c'était bien de tout voir d'un coup d'oeil.

Les VM c'est le pied.

Après l'utilisation des versions 3.2, 3.3, 3.4.1 j'ai décidé de tester la dernière mouture la 3.4.2. 
Cette version est censée corriger quelques bugs présents dans la 3.4.1, bugs que je n'ai pas rencontrés personnellement. 
Par ailleurs le support de la variation de la fréquence des CPU en fonction de la charge système est censé être "meilleur". Aucune fonctionnalité nouvelle n'est annoncée dans cette version que semble être uniquement une 3.4.1 stabilisée. 
La version étant "toute neuve" j'ai téléchargé directement le paquet source : http://www.xen.org/products/xen_source.html 
La compilation s'effectue sans problèmes après l'installation des dépendances nécessaires :

• GCC v3.4 or later, j'ai utilisé le 4.4.1
• GNU Make
• GNU Binutils
• Development install of zlib (e.g., zlib-dev)
• Development install of Python v2.3 or later (e.g., python-dev)
• Development install of curses (e.g., libncurses-dev)
• Development install of openssl (e.g., openssl-dev)
• Development install of x11 (e.g. xorg-x11-dev)
• bridge-utils package (/sbin/brctl)
• iproute package (/sbin/ip)
• hotplug or udev

L'installation s'effectue très simplement par recopie du binaire "gzifié" ( xen-3.4.2/dist/install/boot/xen-3.4.2.gz) dans le répertoire /boot et par paramétrage de grub. 
Aucune dépendance spécifique par rapport aux outils (QEMU, libvirt ...) n'étant indiquée je me suis lancé directement dans l'exécution. 

Les différentes machines que j'ai testées se sont lancées sans erreurs et ont fonctionné tout à fait normalement :

• Windows XP (32 bits)
• Windows 2000 (32 bits)
• Windows 2003 (32 bits)
• Linux Debian en 32 et 64 bits
• Linux Suse 10/SP2

Je continue les tests pour donner un peu plus d'impressions sur cette version. 
Comme la version OpenSuse 11.2 vient de sortir en beta je vais reformater le système, mettre la partie système sur SSD et installer OpenSuse 11.2. 
Voir l'article :  sur le SSD

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 ?

Après une tentative avortée et afin de tester l'installation de la dernière version de XEN sur ma belle machine ( voir l'article ) je me dirige vers une génération complète à partir des sources de Xensource.

• pour récupérer les sources il faut installer "Mercurial" ( apt-get install mercurial ).
• installer quelques dépendances nécessaires : 
  apt-get install bcc gettext python-dev libsdl1.2-dev libgpmg1-dev 
  Il y a peut-être d'autres dépendances mais elles devaient déjà être installées sur mon système ...
• Se mettre dans un répertoire tranquille et lancer la récupération des sources par : 
  hg clone http://xenbits.xensource.com/xen-3.4-testing.hg
• On peut ensuite lancer la compilation par les classiques 
  make world 
  make install

Remarque un noyau Linux 2.6.18 est chargé et compilé (il vous faudra fournir le paramétrage de ce noyau) dans la foulée, ayant un noyau beaucoup plus récent j'ignorerai celui là. 
Le processus est très long car il y beaucoup de sources à compiler, l'installation par contre est très rapide. 
Si vous voulez utiliser le noyau 2.6.18 il faudra générer un "initrd" ( "update-initramfs -c -v -k 2.6.18" pour Debian et dérivés). 
Je note au passage que la version de XEN est la 3.4.3. 
Le paramétrage de Grub est identique à celui du précédent essai :

menuentry "Debian GNU/Linux, with Linux xen" {          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 /initrd-xen  }

Bien noter le "doublement" des informations sur les noms des fichiers  ( /xen.gz, /vmlinuz-xen et /initrd.xen ) ! 
Si vous avez un "Grub" plus ancien, par exemple celui de la OpenSuse 11.2 le schéma est plus simple (plus intuitif surtout !) :

title Xen -- openSUSE 11.2 - 2.6.31.5-0.1-xpatch XEN 3.4.2  root (hd0,0)  kernel /boot/xen-3.4.2.gz dom0_mem=2048M   module /boot/vmlinuz-2.6.31.5-0.1-xpatch root=/dev/disk/by-label/ROOT splash=silent noresume showopts vga=0x345  module /boot/initrd-2.6.31.5-0.1-xpatch

On reboote dans l'angoisse pour vérifier et ... celà marche du premier coup. 
Je tente fébrilement de démarrer une VM, c'est parfait. L'écran du système est parfait dans la fenêtre de "virt-manager" (celui fourni par Debian). 
Je tente me connecter sur 1 VM et lance des applications ensuite un : 
xm save VM fichier 
qui se termine assez rapidement avec un arrêt normal de la machine virtuelle après la mise en pause. Vite une tentative de restauration : 
xm restore fichier 
qui après quelques dizaines de secondes ré-ouvre l'écran pile sur les applications ouvertes précédemment. La fonction save/restore est donc parfaite. 
Pour les prochains tests il me faudra accéder à une autre machine tournant avec un XEN relativement récent, un petit prêt/transfert de machine est à l'étude pour pouvoir réaliser ces tests.

Suse est toujours à la pointe du progrès (OpenSuse)  pour les noyaux "xenifiés", on peut ainsi tester les dernières versions des noyaux et bénéficier de toutes les améliorations. 
J'ai ainsi testé les noyaux 2.6.33.6 et 2.6.34-rc4-4 en version "xenifiée" avec le "xen" 3.4 de OpenSuse (version 1_19718_04-2.1). 
Ces deux noyaux sont parfaitement stables et toutes les machines virtuelles se lancent et fonctionnent sans problèmes. La stabilité de X est également bonne (je n'ai pas eu de plantages inexpliqués sous X, mais quelques ralentissements bizarres, avec Xorg à 100% de CPU, lors de défilement dans Firefox ou de changement d'écran), ce qui permet  quand même l'accès direct par "virt-manager" aux écrans graphiques des machines virtuelles. 
Petite différence : 
le répertoire "/proc/xen" ne semble plus aussi important mais contient toujours les fichiers habituels, mais le répertoire "/sys/hypervisor" est bien plus fourni, c'est probablement l'avenir. 
 Il va falloir maintenant passer à XEN 4 pour être tout à fait "dans la course". 
Rappel :

• Machine avec Processeur "AMD Athlon(tm) 64 X2 Dual Core Processor 4400"
• RAM : 8Go Disques : système sur
• SSD OCZ Agility 32Go (pas encore "trimmé", mais qui a gardé sa vitesse)
• 2 * 1To en RAID 1 2 * 160Go en RAID 1

Où récupérer ces trucs : sur le repository OpenSuse (OpenSuse 11.3 beta),. 
Attention ce ne sont pas des versions "stables". 
Je viens d'y voir un 2.6.34.6 (fini le -rc) à tester très prochainement et une version de Xen 4.0 toute fraîche d'aujourd'hui 7 mai 2010. 
Je vais probablement finir par passer en 4.0,  je n'ai pas tenu longtemps ...

Avec l'installation de la dernière version de Xen, sur une nouvelle machine, l'envie m'est venue de tester la migration d'une Machine Virtuelle d'un serveur à l'autre. 
Pour réaliser cette opération il faut :

• Deux serveurs de MV !
• Des installations de XEN "compatibles" (avec les mêmes chemins d'accès aux différentes fonctionnalités de XEN)
• Un espace de stockage partagé 
  note : le chemin d'accès aux "disques virtuels" doit être identique sur les deux systèmes, si le disque de la machine est accédé par "/REP/XEN.img" ce chemin doit être identique pour les deux serveurs.
• Assez de mémoire libre sur le deuxième système pour "accueillir"  une machine virtuelle supplémentaire.
• Une liaison réseau pour le tout, si elle est rapide (1 Gb) celà n'est que mieux
• Que les fonctions " xm save " et " xm restore " fonctionnent correctement sur chacune des deux machines.
• Que les processeurs soient compatibles, ici pas de problème tout est en AMD 64 bits.

1. Pour les deux serveurs de MV un "simple" emprunt me permet de remplir ce pré-requis.
2. Pour les installations compatibles cela semble OK car l'implantation de la machine "prêtée" (OpenSuse 11.2) est strictement standard, l'autre machine, installée avec les sources de Xensource est au standard.
3. L'espace de stockage partagé est fourni par le NS5200 sur un "folder" ouvert en NFS, les deux machines ont été autorisées sur la boîte miracle.
4. La liaison réseau est fournie par un petit hub 1 Gigabit D-LINK à 8 ports modèle DGS-1008d.
5. Les fonctions " xm save" et " xm restore " ont été testées séparément sur les deux machines et marchent à merveille.

Il faut configurer les deux XEN pour permettre la migration, il faut pour cela modifier le fichier de configuration "/etc/xen/xend-config.sxp" :

• (xend-relocation-server yes)
• (xend-relocation-hosts-allow '192.168.2.20') ou (xend-relocation-hosts-allow '') pour des tests.
• (xend-relocation-port 8002)

Une fois la belle machine prêtée branchée, configurée et connectée au réseau (petite mise à jour de l'adresse de la carte nécessaire) les tests peuvent commencer. 
Il faut d'abord assurer l'accès au NS5200 en NFS à la nouvelle machine, les structures de stockages devant être identiques il suffit de créer un nouveau point de montage à le racine du nouveau serveur. 
Pour la commodité le serveur ancien (AMD dualcore) sera appelé serveur B, l'autre (AMD quadcore) sera appelé serveur A. 
Un petit script permettra de ne pas retaper plusieurs fois la même commande d'accès au serveur NFS. 

#!/bin/bash 
NS5200='192.168.3.101' 
mount -t nfs $NS5200:/raid0/data/Sauvegardes    /THECUS_NFS -o rw 

Une machine de test est lancée sur le serveur A, l'exemple utilisé est une machine WIndows XP dont le fichier de configuration est présenté en fichier attaché. 
La machine est accédée par le logiciel " rdesktop ". 

La suite des opérations est très simple :

• Connecter le montage NFS sur les deux machines
• Lancer la machine virtuelle XP sur le serveur A
• Se connecter à la machine XP à l'aide de "rdesktop"
• Ouvrir une application (OpenOffice) dans la machine XP
• Lancer la migration de serveur A vers serveur B
• Vérifier dans l'écran "rdesktop" que l'application est bien fonctionnelle sur la MV

Le script de connexion NFS est lancé sur les deux serveurs 
Lancer la machine sur le serveur A : xm start com-xp1 
Lancer la connexion à la MV : rdesktop -B -P -x -l -g 1024x768 com-xp1 
Lancer OpenOffice et ouvrir un document. 
Cà marche ! 

<Image 1 > : la MV est bien active sur le serveur A et invisible sur le serveur B. 
 

Lancer la migration :  xm migrate com-xp1 192.168.3.10 

La machine apparaît sur le " xm top " du serveur A et passe en " migrating " sur le " xm top " de serveur B, après environ 20 secondes la machine disparait du serveur A et après une quinzaine de secondes supplémentaires la machine XP est de nouveau parfaitement exploitable dans l'écran rdesktop. 
La vitesse de transfert de la mémoire (par le réseau) est d'environ 80 MO/s ce qui explique assez bien le temps de migration pour une taille mémoire de 1536 Mo. 

<image 2> La machine est bien affectée au serveur B. 
 

C'est quasiment magique ! 

Je vais regretter de perdre le deuxième serveur, mais arrêtons de rêver !

Cet article est destiné à présenter "mon" passage à XEN 4.0 depuis la compilation des sources. 
J'ai déjà compilé XEN 3.4.3 et quelques noyaux, la plupart des utilitaires et autres "includes" nécessaires sont donc déjà présents dans ma machine. 
Il  faut, au moins disposer de :

• libssl-dev
• zlib-dev
• bin86
• bcc
• elks-libc
• python2.6-dev
• python-xml   pour xml_proc

Après la récupération des sources depuis le site xensource et installation dans un répertoire propre il faut lancer la compilation, comme je dispose de noyaux Linux récents je ne compile pas le noyau standard de XEN. 
Il suffit donc de lancer les commandes 
make xen    2>&1 | tee XEN.LOG 
make tools  2>&1 | tee TOOLS.LOG 
pour compiler le tout et garder trace de l'événement. 

La commande "make tools" déclenche automatiquement le chargement des sources de la version correspondante "xenifiée" de QEMU. 
La vérification avant compilation des "tools" montre : 
Checking check_crypto_lib: OK 
Checking check_curl: unused, OK 
Checking check_openssl_devel: OK 
Checking check_python: OK 
Checking check_python_devel: OK 
Checking check_uuid_devel: OK 
Checking check_x11_devel: OK 
Checking check_xgettext: OK 
Checking check_xml2: unused, OK 
Checking check_zlib_devel: OK 
Checking check_zlib_lib: OK 
Cela donne une bonne indication des paquets de développement nécessaires. 
make xen se passe bien, la première tentative d'installation achoppe sur l'absence d'un répertoire "check" dans l'arborescence "dist" : 
./install.sh 
Installing Xen from './dist/install' to '/'... 
- installing for udev-based system 
- modifying permissions 
All done. 
Checking to see whether prerequisite tools are installed... 
cd: 53: can't cd to ./dist/install/../check 
./install.sh: 54: ./chk: not found 
All done. 
Je récupère le répertoire "check" dans la verson 3.4.3 et la recopie "bêtement" ... et cela a l'air de fonctionner : 
./install.sh 
Installing Xen from './dist/install' to '/'... 
- installing for udev-based system 
- modifying permissions 
All done. 
Checking to see whether prerequisite tools are installed... 
Xen CHECK-INSTALL  lundi 26 avril 2010, 20:02:06 (UTC+0200) 
Checking check_brctl: OK 
Checking check_crypto_lib: OK 
Checking check_curl: unused, OK 
Checking check_iproute: OK 
Checking check_python: OK 
Checking check_python_xml: OK 
Checking check_udev: /sbin/udevadm OK 
Checking check_xml2: unused, OK 
Checking check_zlib_lib: OK 
All done. 
Les nouveautés dans le répertoire "/boot" : 
-rw-r--r-- 1 root root 669914 26 avril 22:50 xen-4.0.0.gz 
lrwxrwxrwx 1 root root     12 26 avril 23:37 xen-4.0.gz -> xen-4.0.0.gz 
lrwxrwxrwx 1 root root     12 26 avril 23:37 xen-4.gz -> xen-4.0.0.gz 
On va bien vite voir si cela "boote" ! Eh non, un problème, il faut charger le package "python-profiler" pour que "xend" et compagnie se lancent normalement. Une fois ce paquet installé le boot est OK, et on peut lancer une machine virtuelle sans modifier son paramétrage. 
Par contre mon "ancienne" installation (version 3.4.3) n'est plus utilisable pour diverses incompatibilités au niveau des scripts "python", le passage est donc un passage sans retour (à moins d'avoir réalisé une image de son disque système avant !). 
J'ai ensuite refait les tests de migration "live" vers une machine tournant en XEN 3.4.3, la migration échoue. Un autre test : 
 "xm save machine fichier_sur_disque_partagé" 
suivi (sur l'autre machine) d'un "xm restore fichier_sur_disque_partagé" 
échoue. La compatibilité n'est donc pas évidente entre les versions 3.4 et 4, comme ce sont des versions "majeures" on ne s'en étonnera que peu.

Pas mal de paquets à charger avant de lancer le petit script ci-dessous : 
#!/bin/bash 
# 
# Pour XEN 
LISTE=" glibc-2.11.1-5.2.x86_64.rpm \ 
glibc-locale-2.11.1-5.2.x86_64.rpm \ 
libopenssl1_0_0-1.0.0-2.5.x86_64.rpm \ 
openssl-1.0.0-2.5.x86_64.rpm \ 
python-base-2.6.5-1.8.x86_64.rpm \ 
python-2.6.5-1.5.x86_64.rpm \ 
xen-4.0.0_21091_01-2.4.x86_64.rpm \ 
xen-libs-4.0.0_21091_01-2.4.x86_64.rpm \ 
xen-tools-4.0.0_21091_01-2.4.x86_64.rpm" 
# Pour virt-manager 
LISTEV="libxml2-2.7.7-3.2.x86_64.rpm \ 
libblkid1-2.17.2-1.6.x86_64.rpm \ 
parted-2.2-1.9.x86_64.rpm \ 
libvirt-python-0.8.0-1.8.x86_64.rpm \ 
libvirt-client-0.8.0-1.8.x86_64.rpm \ 
virt-utils-1.1.1-3.13.x86_64.rpm \ 
libvirt-0.8.0-1.8.x86_64.rpm \ 
virt-manager-0.8.4-2.3.x86_64.rpm " 
rpm -hiv --replacefiles $LISTE 
rpm -hiv --replacefiles $LISTEV 

A bientôt pour les tests, à première vue tout baigne, la première machine virtuelle s'est bien lancée et tourne sans aucun problème.

Installation d'une machine Centos 5 avec le CD "Netinstall". 
Sous XEN ou KVM c'est identique, sur une machine physique celà marche aussi ! 
Cette installation est tentée car j'ai vu que ce CD était très peu volumineux (environ 9Mo), ce qui semble très tentant et permet d'avoir une machine "à jour" dès l'installation, et si l'on peut mettre cela sur une vieille clé USB ... 
L'image de démarrage est bien jolie

et vous emmène directement sur le premier écran texte.

Premier écran "Choose a language" : je préfère le français ... 
Deuxième écran "Quel type de clavier" : déjà en français ... j'aime bien les claviers "fr-latin9" ce qui ne pose pas de problèmes. 
Troisième écran "Méthode d'installation"

je vais tenter le HTTP ...

Quatrième écran "Configuration TCP/IP"

avec le choix IPV4 et/ou IPV6, l'un comme l'autre en IP fixe ou en dhcp. Comme j'ai préparé mon coup je sélectionne IPV4 et DHCP

L'écran suivant permet de sélectionner le site de téléchargement

Le site HTTP est : "http://mirror.centos.org"  le répertoire est : "centos-5/5.4/os/x86_64"  A saisir sans le "http://" et sans "/" en tête de nom de répertoire.  On peut aussi utiliser un miroir français en général plus rapide :  mirrors.ircam.fr  pub/CentOS/5.5/os/x86_64  (64 bits)  ou   pub/CentOS/5.5/os/i386  (32 bits)

Après quelques instants la "Récupération" commence et après environ 3 minutes un écran graphique commence à s'ouvrir et au bout d'environ 40 secondes supplémentaires l'écran suivant s'affiche : 
 
Mon disque "hda" n'étant pas initialisé, l'initialisation m'est proposée gentiment et je l'accepte puisque je crains pas de perdre les données contenues ! 
Très vite les trois disques que j'ai préparés sont repérés et présentés.

étant très paresseux je vais tenter le partitionnement par défaut en cochant aussi "Examiner et modifier la structure de stockage".  Le bouton "+ Configuration avancée de stockage" permet même d'ajouter des cibles iSCSI directement.

Après avoir confirmé que je veux bien partitionner les trois disques et que j'accepte de perdre toutes leurs données ... la proposition est de mettre les trois disques dans un Volume Group Unique de 48Go (mes trois disques de 16G) et deux volumes logiques: Swaq de 3G et une partition ext3 de 45G 
 
On peut sur ce même écran gérer la mise en RAID et affiner LVM. 
Ce n'est pas tout à fait ce que je veux et je clique "sur "Réinitialiser". l'écran est aussitôt mis à jour et me présente chacun de mes 3 disques en "espace libre". Il est très aisé d'éditer un espace libre en cliquant le bouton "Editer" :

le disque sélectionné est même encadré de rouge, le luxe ! Je crée donc un espace de swap de 3G, une partition racine de 13G sur le premier disque et crée une partition simple sur chacun des deux autres disques (/DATA et /LOG). L'éditeur de partition est très complet et très agréable à manipuler.

L'écran suivant permet de sélectionner le chargeur de démarrage et le disque d'installation 
 
Je choisis d'installer GRUB sur /dev/hda1 par défaut, sans mot de passe ni options avancées. 
L'écran suivant permet de configurer les cartes réseaux, noms d'hotes ..., je choisis de laisser le boulot à DHCP toujours sans IPV6 (tiens il faudra que je m'y mette à IPV6). 
Ecran suivant : choisir son fuseau horaire (belle mappemonde), pour moi Europe/Paris est préselectionné ainsi que l'horloge système en UTC. 
Ecran suivant : le mot de passe de "root" et c'est parti ...... pour la sélection des paquets à installer 
 
Je fais mon petit marché sans ajouter de dépot et choisis de "personnalier plus tard". 
Les dépendances sont validées et il suffit de cliquer sur "Suivant" pour lancer l'installation. Une belle image s'affiche, les disques sont formatés rapidement, le "Démarrage du processus d'installation" est un peu laborieux (# 7 minutes) pendant ce temps quelque activité reseau vers des serveurs "centos". 
Puis "Bienvenue dans Centos 5", l'installation commence : 
 
... les images changent de temps en temps pour occuper le temps et expliquent tout du rojet Centos. Le téléchargement est assez rapide (de 150 à 500 Ko/s avec des pointes à 800Ko/s) sur cette ligne qui plafonne à 850Ko/s. La durée prévue est d'environ 65 minutes, malgré la progession le remps restant reste longtemps aux environs de 60/65 minutes avant de dommencer à descendre. 
L'installation choisie est assez complète et le volume à télécharger est donc assez conséquent et c'est enfin fini (environ 50 minutes) 
Après mise à jour du fichier de configuration de la MV on reboote ... les trois disques sont bien là et le noyau 2.6.18 démarre et lance les étapes complémentaires de configuration : 
Pare-feu : je le désactive bien que l'écran permette de gérer assez finement les ports. 
SELinux : je le désactive lui aussi. 
Kdump : je le laisse inactif 
Date et heure : OK, je lancerai NTP plus tard. 
Utilisateur ; je crée un utilisateur standard 
Carte son : pas sur la machine virtuelle ... 
CDROM supplémentaires : aucun 
La "dévalidation" de SELinux oblige à un redémarrage qui s'effectue sans problèmes. L'écran X est lancé et Gconf me signale que le pourcentage mini de la batterie ne peut être à zéro, et ... aucun menu ne s'affiche à part les icones "Poste de travail" et "Corbeille". 
Il faut : faire un clic droit sur le "mini panel" présent en haut à Gauche sur l'écran et choisir "Propriétés", on peut alors configurer un peu ce panel avec "Etendre". On peut déjà le voir, mais il ne contient toujours rien ... encore un clic droit et on peut y ajouter une "barre de menus" (ne pas oublier de la "Verrouiller") pour le rendre beaucoup plus sympathique. 
On peut ensuite le personnaliser à loisir comme d'habitude. 
Bizarre que rien ne soit configuré dans le "gnome-panel", probablement un bug qui devrait être vite réparé. 
A chaque connexion le "Gestionnaire d'énergie" positionne une erreur : 
 
dont je n'arrive pas à me débarasser même en désactivant le gestionnaire d'énergie, bizarrement cela n'arrive pas pour le user "root". 
Même après le rituel "yum update" (qui déclenche 136 mises à jour) ce bête message continue à s'afficher.

Un petit tutoriel pour l'installation de Oracle 10g sur Linux. 
C'est un peu ancien mais il y en a encore beaucoup, il y a même des entreprises qui n'ont pas encore migré vers Oracle 10 et restent en 9, 8 et même parfois Oracle 7 ! 
Le problème est ici que les dernières versions de Linux ne permettent pas l'installation (ou très difficilement) de Oracle 10g dans sa dernière version 10.2. 
Ici, le choix s'est porté vers le Linux Oracle en version 4.8, il est probable qu'un Centos 4 ou un Suse 9 aurait pu convenir, mais je n'avais pas de Centos sous la main et la Suse 9 a refusé de s'installer dans la machine virtuelle prévue (blocage après la détection USB). 
Celui-ci s'installe exactement comme le linux Centos55 (cf article). 
La machine sur laquelle va être réalisée cette installation est constituée de :

• CPU    1
• RAM    1,5G
• Disques
  • 20Go pour le système
  • 32Go pour les données
• 1 adresse IP configurée "en dur", c'est important pour ne pas être ennuyé ensuite