Un système Xen est composé d'un hyperviseur Xen et de machines virtuelles sécurisées appelées domaines.

Il existe 2 types de domaines :

• dom0 : le domaine privilégié créé lors de l'installation de xen et démarré au boot de la machine physique
• domU : le ou les domaines non privilégiés hébergeant la ou les machines invitées ou encore systèmes d'exploitation invités

Les principales fonctionnalités apportées par Xen sont :

• isolation complète entre les machines invitées
• performances pour les machines invitées proches d'un système natif
• très bon support du matériel (Xen utilise les pilotes du noyau du dom0)
• possibilité de migrer des machines virtuelles entre des serveurs Xen sans interruption de service
• possibilité de régler finement les ressources allouées aux machines virtuelles

Xen3 peut héberger des systèmes d'exploitation invités non modifiés (si le hardware le permet).

Xen peut être utilisé pour :

• consolider des serveurs en hébergeant sur une machine physique plusieurs serveurs différents (système d'exploitation et applications)
• réaliser des plans de reprise d'activité ou de continuité de service
• tester le fonctionnement d'une application sur plusieurs systèmes sans disposer d'autant de machines
• tester une architecture réseau
• surveiller des machines virtuelles, allouer des ressources, détecter des comportements inhabituels
• réaliser un cluster en utilisant la flexibilité de gestion des machines virtuelles, leurs contrôles, leurs isolations et la possibilité de migrer pour répartir la charge
• remplacer un multi-boot
• tester et debugger des modifications du noyau dans une machine virtuelle « bac à sable » (sandboxed)

Xen peut utiliser, pour le stockage des machines virtuelles (du plus simple/bon marché, au plus complexe/coûteux) :

• des fichiers images (possibilité de convertir des images VMWare via certaines procédures)
• des partitions disques locales
• NFS (NFS root)
• iSCSI
• SAN/FC
  Le tout via l'utilisation de LVM (Linux Volume Manager) ou non.
  Les 3 derniers supports, basés sur le réseau, sont essentiels pour pouvoir utiliser la fonctionnalité de "migration en live".

Au niveau réseau, la gestion se fait dans le dom0 (Attention, ça devient un peu technique...), Xen permet d'utiliser de base :

• un mode bridge (niveau Ethernet) : tous les domaines apparaissent sur le réseau comme des machines individuelles
• un mode NAT (niveau IP) : le dom0 joue le rôle de passerelle pour les domU
• un mode route (niveau IP)
  Il est aussi possible d'utiliser plusieurs bridges se trouvant dans différents VLANs, ainsi chaque domU peut-être correctement isolé sur le VLAN le plus approprié, cf. http://renial.net/weblog/2007/02/27/xen-vlan/

Enfin, Xen peut exécuter des domU dans deux modes :

• para-virtuel : moyennant quelques modifications dans les noyaux des systèmes invités, on obtient de meilleures performances dans les I/O (disques, réseaux)
• hardware virtualization : si le matériel le supporte (technologies AMD Pacifica ou Intel VT), ce mode permet de lancer n'importe quel OS sans modification de celui-ci (typiquement pour les systèmes MS Windows). Les performances sont un peu moindres qu'en mode para-virtuel (les périphériques disques et réseaux sont alors émulés via le code de QEMU) mais il est possible d'installer des drivers para-virtualisés pour les parties sensibles (disques et réseau). De tels drivers sont disponibles dans les versions commerciales de Xen (ils sont à priori stables), des développements sont en cours pour une version Open Source (peu stables pour le moment d'après les listes de diffusion).

• Au CRPP (Centre de Recherche Paul Pascal), xen est installé sur 2 serveurs (dom0) de configuration identique dont le système d'exploitation est Linux Fedora Core 8.
  Ces 2 serveurs hébergent chacun 3 machines virtuelles (domU) en Linux Fedora Core 8 (i386)
  - un replicat ldap d'authentification
  - un replicat ldap d'identification
  - un serveur ssh de secours
  D'autres machines virtuelles vont être déployées pour le webmail, le serveur de licences origin et matlab, les sites web externes ou internes.
  Les machines virtuelles sont stables, les commandes virt-manager et virsh sont très utiles pour la gestion des machines virtuelles.
  Un seul problème à signaler : au redémarrage des machines physiques les machines virtuelles n'étaient pas redémarrées automatiquement. Ce problème a été résolu après une mise à jour des paquetages xen de Linux Fedora 8.
• Au CRI de l'Université de Pau et des Pays de l'Adour, Xen a été installé :
  - Il y a un peu plus d'un an, sur une première machine dans un but d'évaluation en semi-production, via un stockage des images simples (fichiers images ou partitions locales dédiées).
  Ce serveur héberge 7 machines virtuelles en production mais non critiques, aucun problème constaté, pas de crash, pas de perte de réseau ou d'effondrement des performances.
  - Suite au succès de la première étape, le CRI procède actuellement (depuis environ 6 mois) à une virtualisation de la plupart de ses services.
  Pour cela, nous utilisons un SAN, et des serveurs (5 actuellement) sans disques équipés de cartes FC. En cas de problème sur
  des serveurs physiques, il est possible de migrer (ou relancer en cas de crash) l'ensemble de ses machines virtuelles sur un ou plusieurs
  autres serveurs.
  Quelques services critiques actuellement virtualisés :
  - stockage (samba/NFS/FTP)
  - Webmail (apache2 / Horde)
  - listes de Diffusion (sympa)
  - reverse-proxy (ezproxy)
  - serveur d'applications Cocktail/JEFYCO
  Quelques services critiques en cours de migration :
  - serveur de messagerie IMAP/POP (cyrus)
  - serveur de bases de données (MySQL/PostgreSQL)
  Les Dom0 sont en Debian Testing (Lenny), les DomU en Debian Stable (i386 ou amd64 selon les besoins).
  Il y a aussi une machine virtuelle Windows 2003 server en semi-production, à des fins de tests de stabilité (aucun problème constaté pour le moment).
  Nous sommes très satisfaits de Xen, c'est très stable.
  Un autre avantage de la virtualisation est le temps de redémarrage très court des machines virtuelles (puisqu'il n'y a plus d'initialisation matérielle, ce qui est le plus long), même si les reboots sont rares, c'est très appréciable.

Les ressources documentaires peuvent parfois être un peu limitées ou obsolètes.
Voici quelques points sensibles que nous avons rencontrés :

• il est possible d'avoir des machines virtuelles en 32 ou 64 bits sur des dom0 en 64 bits, ce qui est très pratique. Par contre,
  il est impossible de sauver/restaurer/migrer ces MV (par sauver/restaurer on entends l'état de la MV, pas son image disque).
  Cette limitation peut être contournée en utilisant un noyau 64 bits dans le domU avec des binaires en 32 bits, c'est souvent possible sans problème, à quelques exceptions près (exemple : outils de gestion de quota qui "segfaultent" dans ce cas là).
• Version du Noyau du dom0 actuellement limitée à la 2.6.18 (si Linux), ce qui peut être limitant si la machine physique dispose de partie matérielle non supportée par cette version.
  Certaines distributions proposent des backports (?) des patchs sur des noyaux récents, mais les listes de diffusion semblent indiquer de possibles instabilités (n'ayant pas testé personnellement, je ne confirmerai ni n'infirmerai).
  L'intégration dans la branche Vanilla du noyau Linux devrait résoudre ce petit problème, mais il est vrai que cela commence un peu à tarder.