Ce paragraphe porte un regard plus "marketing" sur Xen : il présente des nouvelles possibilités ouvertes avec la virtualisation du matériel (Applications). Les outils similaires à Xen sont présentés (Comparaison).
Xen est un des outils qui permettent la décorrélation entre le hard et le soft : avec Xen on peut installer un nombre indéterminé d'OS "à la demande" sur une même machine. L'OS des machines virtuelles lui-même peut devenir "banalisé" : seule compte l'application qui s'exécute.
Xen permet aussi de migrer une machine virtuelle complète d'une machine "réelle" à une autre. Xen peut être utilisé en complément à un outil de distribution des requêtes pour créer un service tolérant aux fautes (pour des logiciels serveurs, présents en permanence pour répondre à des requètes asynchrones).
On peut aussi envisager une utilisation de Xen en liaison avec des outils de surveillance du hard : maintenance prédictive avec migration d'une machine virtuelle depuis un "hard" qui tombe en panne vers un autre serveur (détection avec les erreurs disque par SMART ou les erreurs RAM ECC), puis réparation du hard en panne, qui ne porte plus de machine virtuelle.
Une limitation à l'utilisation de Xen est l'impact sur les performances (un serveur de base de données a besoin de toute la bande passante vers les disques, de toute la mémoire et de toute la puissance de calcul disponible : voir benchs Anandtech - c'est donc un mauvais candidat pour être consolidé sur une machine Xen-ifiée).
Xen est complémentaire des outils de "clustering" :
ces outils permettent de gérer un ensemble de
machines comme une seule. En ajoutant Xen à un outil de
clustering, on peut transporter un morceau d'application vers une
ressource de calcul "banalisée" (les fonctions de gel et de
migration sont aussi intéressantes pour créer "ex
nihilo" des points de reprise dans un calcul très long).
Problème majeur : administration du "système" (suivi des performances, allocation des ressources, gestion des pannes)
Essentiellement pour les serveurs (voir
hébergement) -
livraison "robuste" d'application (une application par machine
virtuelle).
Xen pourrait devenir la méthode permettant de conserver une pile de protocole "cohérente" (au sens LAMP, avec intégration et validation externe) pour chaque machine virtuelle. Actuellement l'intégration des logiciels Open Source est le problème majeur : sous-traité à des "distributions Linux" ou des entreprises comme SpikeSource.
Xen serait UNE voie d'amélioration en limitant le nombre de bibliothèques partagées par machine virtuelle et ce faisant, en limitant les interdépendances (on évitera de se poser la question "quelle application va exploser si je mets à jour libxml2 ?").
Gestion de l'obsolescence : garder des machines virtuelles avec des vieilles versions d'OS / d'applications.
Gestion de configuration des serveurs (service X = install "par défaut" de l'OS + application Y)
Allocation et facturation des ressources (optimisation des budgets).
Sécurité (une machine virtuelle Xen pour
surfer
sur Internet, pour Bittorrent - voir la note "jail" et
configurer
Xnested/VNC/NX pour avoir une connexion graphique sur la machine
virtuelle)
compartimenter pour limiter les conséquences d'une brêche de sécurité : si une application a un trou de sécurité, seule la machine virtuelle hébergeant cette application est compromise (par exemple, uniquement la portion "forum web" est impactée, laissant intact le service "IMAP" pour un extranet).
Possibilité de ré-imager une machine virtuelle à partir d'une version témoin (une machine virtuelle se gère comme un "simple" fichier).
Xen utilisé comme chargeur d'OS "trusted" (voir TCPA).
Limiter l'impact d'un patch : quand on installe un patch (sécu ou autre) sur une machine, il y a un risque de régression (risque exponentiel en fonction du nb d'applis installées). Si on limite le nombre d'applis par machines virtuelles, l'impact d'un patch désastreux est plus faible.
Développement (plusieurs environnements sur la même machine )
Machine multi-utilisateur (carte graphique multi-écran + n * claviers/souris USB) en allouant des ressources physiques à chaque machine Xen
(en allant plus loin : combiner Xen avec Clustering et NoMachine pour avoir une grappe de machines bureautiques "à la demande")
Xen peut être utilisé pour mettre à disposition d'étudiants des machines complètes (y compris le mot de passe "root") sans danger d'intrusion + facilité de réinstallation à partir d'une copie de référence ("master").
Beaucoup de projets proposent des CD-ROM "live-CD" pour évaluer ces projets sans installer de logiciel sur le disque dur du PC (Knoppix, FreesBIE, SLAX - voir une liste impressionnante sur http://www.frozentech.com/content/livecd.php).
L'inconvénient majeur de ces CD est d'avoir à redémarrer la machine et de perdre l'accès à l'OS habituel de cette machine.
Une alternative au démarrage sur un CD-ROM pour tester un nouvel OS serait de livrer une image disque DomU bootable sous Xen : pas de CD à graver, pas de reboot de la machine. Il faudra compléter la livraison avec les bibliothèques NoMachine/NX pour avoir une console graphique.
(XXX lien pour démarrage de Knoppix à partir d'une image sur NTFS)
Avec un DomU sur un support amovible (clé USB, lecteur mp3, ...) et Xen0 sur un PC d'accueil, il est possible de retrouver son environnement complet (mails, documents, mp3, mots de passe) partout (attaque Man-in-the-Middle si Xen dans le domaine 0 est trafiqué).
Il faut alors penser à chiffrer la clé USB.
Xen est le plus récent des mécanismes de virtualisation. Ce paragraphe présente d'autres approches permettant de faire vivre plusieurs environnements système sur une même machine.
mécanisme historique
mécanisme bricolé (initialement prévu
pour le développement de BSD XXX lien)
bonne performance
utilisé par exemple pour le serveur DNS Bind 9.3.x
(limitation : uniquement FreeBSD - mais Solaris containers/zones - User Mode Linux / Virtual Server)
Accès depuis la machine hébergeante aux ressources des machines hébergées :
sécurité : il faut auditer tout le kernel
un seul noyau : mêmes drivers pour tous
pb avec des releases différentes Userland jail / kernel (uniquement décroissant + pb sur les bibliothèques partagées).
sécurité sur les accès aux périphériques (montage devfs / devfs.rules) - mais pb avec le partage mémoire
pb pour être serveur NFS ? (utiliser le package net/unfs3)
pb pour être client NFS ? (seule la machine hôte
peut monter une partition NFS)
performance optimum
partage OK de l'ensemble de la RAM disponible
voir aussi cette note.
VmWare
(limitation : performances + prix)
mais pas de portage pour FreeBSD / NetBSD
compatibilité windows + graphique
séparation complète entre les machines virtuelles : entre les VM, communication uniquement par les services réseau (interface plus complète avec la machine hôte - dont copier/coller à la souris) - aucun partage entre VM : mémoire RAM allouée par machine, partitions disques séparées allouées par machine.
Logiciel propriétaire : pas d'audit possible pour des failles de sécurité
Virtuozzo / VirtualIron
Autres outils (voir les liens)
séparation complète entre les machines virtuelles : entre les DomU, communication uniquement par les services réseau (interface plus complète avec le domaine 0) - aucun partage entre VM : mémoire RAM allouée par machine, partitions disques séparées allouées par machine.
pb : pas de console graphique pour les DomU (connexion par ssh - voir aussi NoMachine NX)
performance +++
client NFS / serveur NFS OK (vérifier performance)
A terme, Xen 3.0 et de nouveaux processeurs fournis par Intel et AMD pourrait permettre d'exécuter n'importe quel OS sous Xen (dont par exemple Windows).
Il n'est pas possible depuis un domaine 0 d'utiliser top(1) pour connaître la charge de la machine (les process des autres domaines sont invisibles - existe-t-il une commande xm top ?)
Audit d'étendue limitée pour garantir la sécurité.
devrait être installé sur chaque machine avec OS libre NetBSD ou Linux : sans rien réinstaller, il est alors possible de disposer d'un nombre inifini de machines parallèles, avec des OS libres
(difficultés de gestion)
(pour mémoire)
limitations : pb dans le partitionnement du disque (dont danger de perte d'un OS quand on en installe un autre), pas de fonctionnement simultané, pb dans le partage de données (obligation d'avoir une partition "neutre", par exemple formattée en FAT)
voir aussi l'installation de Knoppix sur disque dur : un fichier dans une partition NTFS = un OS complet
Il est alors possible d'avoir deux environnements Linux + BSD "natif" simultanément.
XXX à détailler (lien ...)
Comment passer d'un démonstrateur technologique à un outil opérationnel ?
Le frein majeur à l'utilisation de Xen est la complexité de mise en oeuvre (il n'y qu'à voir la longueur de cette note). Xensource, la société commerciale fondée par l'inventeur de Xen et VirtualIron ont annoncé vouloir développer des outils pour administrer des machines virtuelles sous Xen.
Il manque pour l'instant un outil comme top
pour avoir d'un seul coup d'œil l'évolution de la
charge machine des différents domaines (il est normal mais
très surprenant de voir dans le domaine 0 une charge de 0
alors que les machines virtuelles consomment tout le CPU dans une
compilation en boucle).
Par ailleurs, VMWare vient d'annoncer le partage de son code
avec
des
grandes sociétés commerciales. VirtualIron aussi
annocé que son outil de gestion de machines virtuelles
pourrait
gérer des machines virtuelles sous Xen (XXX lien).
DomU FreeBSD (Dom0 ?)
migrations de machines virtuelles
config réseau sous Debian
démarrage automatique des DomU
debug pb ethernet Debian/Xen0 / realtek
pb dans la gestion du matériel (Xen n'accepte pas l'ACPI alors que FreeBSD est OK)
montages des partitions dans tous les sens
Xen 3.0
comment répartir équitablement la ressource CPU entre les machines hébergées ? relations entre le séquenceur dans Xen (dont les aspects multi-proc) et celui des machines hébergées (trois intervenants : séquenceur au niveau threads, séquenceur au niveau OS, séquenceur au niveau Xen).
comment gérer correctement les caches disque ? comment gérer le séquenceur des transferts disque ?
X11 et dom0
plusieurs version de NetBSD "natif" (gestion du boot avec grub ?)
Les pages Web liées sont généralement en anglais (d'où l'intérêt de ces pages en français)
Le Wiki-Wiki Xenfr est un bon point d'entrée en français sur Xen et Linux.
Howto officiel pour mettre en œuvre Xen sous NetBSD : http://www.netbsd.org/Ports/xen/howto.html
Présentation générale de Xen : http://www.cl.cam.ac.uk/Research/SRG/netos/xen/
Foire Aux Questions sur Xen : http://wiki.xensource.com/xenwiki/XenFaq
Comparaison de performances de NetBSD en DomU sur NetBSD /
Dom0 et Linux / Dom0 (Linux est de 30 à 50% plus lent que
NetBSD) :
http://users.piuha.net/martti/comp/xendom0/xendom0.html
Howtos d'installation de Xen sous Linux :
http://www.philipp-benner.de/configs/xen-install.html
(en allemand)
http://www.gup.uni-linz.ac.at/xen/doc/xeninst.php
http://www.fedoraproject.org/wiki/FedoraXenQuickstart
http://jclement.ca/xen/host_setup.html
(Howto pour Xen et Debian Sarge)
Installation de Xen avec Ubunbu :
http://cosi.clarkson.edu/knowledge/workshops/sp05/installingxen/xen-tutorial.html
un article récent sur Xen et UML :
http://lwn.net/Articles/144765/
un numéro de ACM Queue sur les machines virtuelles :
http://www.acmqueue.org/modules.php?name=Content&pa=list_pages_issues&issue_id=15
dont un article général sur les machines
virtuelles :
http://www.acmqueue.org/modules.php?name=Content&pa=printer_friendly&pid=168&page=1
Produits commerciaux :
http://www.sw-soft.com/en/products/virtuozzo/
http://www.virtualiron.com/page.php/id/188
Présentation générale des
technolgies de virtualisation par Intel (qui va intégrer des
éléments facilitant la vie de Xen dans les
générations futures de Pentium VanDerPool
Technolgies) :
http://www.intel.com/technology/magazine/computing/intel-virtualization-0405.htm
Un bon dossier sur les différentes approches de
machines virtuelles:
http://www.softpanorama.org/VM/index.shtml
Adresse de l'auteur : 16,rue Boyer-Barret Paris 14
(à remonter comme para 7 ?)
Xen est là - ces avantages sont incontestables (rappel). reste à polir la mise en œuvre de l'outil.
aaa
$Id: appli.html 4 2005-08-18 09:47:18Z thierry.herbelot $