Xen

Fiche logiciel validé
  • Création ou MAJ importante : 24/03/09
  • Correction mineure : 09/01/13
Mots-clés

Xen : moniteur-hyperviseur de machines virtuelles

Description
Fonctionnalités générales

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

Autres fonctionnalités

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).
Contexte d'utilisation dans mon laboratoire/service


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

Limitations, difficultés, fonctionnalités importantes non couvertes

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.
Environnement du logiciel
Distributions dans lesquelles ce logiciel est intégré
  • Linux : CentOS, Debian, Fedora, Gentoo, Mandriva, OpenSuse, Redhat, Slackware, Suse, Ubuntu
  • FreeBSD
  • NetBSD
  • OpenSolaris
Plates-formes

Xen fonctionne sur les machines comportant les processeurs suivants :

  • Processeurs de type x86 (processeur de type "P6" ou Intel ou AMD des 5 dernières années)
  • Machines multiprocesseur et inclut le support pour l'hyper-threading (SMT).
  • Processeurs de type x86/64 (depuis Xen 3.0)
  • Processeurs de type IA64
  • Processeurs de type PPC
Logiciels connexes

ConVirt (anciennement xenman) : Interface graphique pour la gestion des machines virtuelles sur un ou plusieurs hyperviseur(s) GPL, http://xenman.sourceforge.net/ :

  • création des systèmes
  • administration (marche, arrêt)
  • monitoring (mémoire, CPU)

Pour ceux qui sont réfractaires à la ligne de commande :)

Autres logiciels aux fonctionnalités équivalentes
Environnement de développement
Type de structure associée au développement

XenSource, créée par l'équipe de développement de Xen, qui a été rachetée en octobre 2007 par la société Citrix.

Eléments de pérennité

Xen est en cours d'intégration à la branche "Vanilla" du noyau Linux (cela traîne un peu cela dit...), pour l'instant, les patches permettant d'utiliser le noyau dans une domU en mode para-virtuel sont présent, il manque principalement les patches pour l'utilisation en noyau de dom0.
La société XenSource, à l'origine de Xen, a été rachetée par Citrix. Citrix commercialise donc une offre autour de Xen (outils, support/intégration), mais celui-ci (patches, hyperviseur, outils de base) reste développé en Open Source via une grande communauté, ce qui rassure quant à sa pérennité.
De plus, les principales distributions Linux "professionnelles" (RedHat, Suse) ont intégré Xen à leurs dernières versions, cela a même été, lors de leurs sorties respectives, l'une des principales fonctionnalités mises en avant.

Environnement utilisateur
Liste de diffusion ou de discussion, support et forums
Documentation utilisateur

Informations génériques :

A propos du réseau :

Divers (astuces, actualités, sécurité)
  • Sauvegarde des machines virtuelles dont le filesystem est sur des volumes logiques (LVM)
    Au CRPP, les commandes suivantes sont utilisées pour la sauvegarde des machines virtuelles :

    • Arrêt de la machine virtuelle ldap1
      xm shutdown -w ldap1
    • Création de /dev/mapper/lvldap1p[1234] pour /dev/vg00/ldap1
      kpartx -v -a /dev/vg00/lvldap1
    • Montage temporaire du filesystem to backup
      mount /dev/mapper/lvldap1p1 /mnt/ldap1/
    • Lancement de la sauvegarde
      /sbin/dump 0 -L FULL_ldap1 -f /BACKUP-XEN/ldap1.colddump /mnt/ldap1/
    • Démontage du filesystem
      umount /mnt/ldap1
    • Suppression des mappings
      kpartx -d /dev/vg00/lvfoo
    • Redémarrage de la machine virtuelle
      xm create --config /var/lib/xend/....
  • Sécurité :
    Le dom0 doit être le plus sécurisé possible car si le dom0 est compromis tous les autres domaines sont également vulnérables.
    Voici les bonnes pratiques à appliquer pour sécuriser le dom0 :

Commentaires

Responsable thématique précédent

Cette fiche a d'abord été suivie par le responsable thématique Jacquelin Charbonnel. Thierry Dostes l'a reprise en février 2012.