Les jails permettent de créer des VPS sur un système FreeBSD. Les processus sont emprisonnés dans un niveau d'exécution et un environnement distinct. L'équivalent sur Linux est OpenVZ / VServer / LXC mais le système de jails sous FreeBSD est intégré au système et plutôt mature.

La documentation de FreeBSD décrit le processus manuel de création de jails. Je recommande la lecture et le suivi de l’exercice proposé afin d'acquérir les bases. Il est aussi mentionné la possibilité d'utiliser un "squelette" commun à toutes les jails, ces dernières n'ayant que les répertoires susceptibles d'être modifié. Cela évite d'avoir 10 fois la même arborescence alors que beaucoup d'éléments sont communs. ezjail est un outil permettant d'automatiser tout ceci, et nous allons voir que c'est plutôt bien foutu.

Installation de FreeBSD

Depuis la version 9, l'installeur a été simplifié au point qu'il n'est plus nécessaire de le détailler. Le choix des sets importe peu sur le résultat final, mais personnellement j'ajoute les sources car j'estime que cela fait partie de l'OS.

La suite de l'installation ne nécessite pas de paramétrage particulier.

Configuration

Vous pouvez commencer par mettre à jour le système :

# freebsd-update fetch
# freebsd-update install
# reboot

Nous allons maintenant installer ezjail. Il y a deux solutions : le compiler à partir des ports, ou le télécharger sous forme binaire avec pkg_add.

Méthode 1 : ports

Commencez par télécharger l'arbre des ports :

# portsnap fetch extract

Puis compilez et installez sysutils/ezjail :

# cd /usr/ports/sysutils/ezjail
# make install clean

Il faut ensuite autoriser ezjail à se lancer :

echo ezjail_enable="YES" >> /etc/rc.conf

Méthode 2 : pkg_add

Utilisez la commande suivante :

# pkg_add -r ezjail

Il faut ensuite autoriser ezjail à se lancer :

echo ezjail_enable="YES" >> /etc/rc.conf

Création de la jail de base

La commande suivante va préparer la jail de base :

# ezjail-admin install

Création d'une jail

Utilisez la commande suivante :

# ezjail-admin create dns 'em0|192.168.0.2'

Démarrer une jail

Voici la commande :

# ezjail-admin start dns

Arrêt d'une jail

ezjail-admin stop dns

Mise à jour des jails

La jail de base va être mise à jour, ce qui va répandre les modifications sur toutes les jails.

# ezjail-admin update -u

Suppression d'une jail

La commande est la suivante :

# ezjail-admin delete -wf dns

Modifier le "modèle" des jail

Cas concret : vous voulez activer SSH sur toutes les jails créées. C'est faisable ! La jail "modèle" est située ici : /usr/jails/newjail. Donc il faut éditer/créer le fichier /usr/jails/newjail/etc/rc.conf :

# echo sshd_enable="YES" >> /usr/jails/newjail/etc/rc.conf

Et voilà !

Documentation

D'autres usages sont possibles, certains seront intéressés par les possibilités offertes avec l'intégration ZFS.

• Site officiel ezjail : Très pauvre, mais les bases sont là.
• Utiliser la commande man ezjail-admin directement sur FreeBSD, c'est très complet.

L'installation de VMware Player/Workstation sous Linux est assez simple puisqu'il suffit de lancer le package fourni en root. Or sous Fedora la compilation des modules ne passe pas, il y a quelques manipulations à faire.

Dépendances

# yum install kernel-devel* make gcc

Installation VMware

# ./VMware-Workstation-Full-9.0.1-894247.x86_64.bundle

Compilation des pilotes

Ci dessous un petit fix sinon la compilation échouera :

# cp /usr/src/kernels/`uname -r`/include/generated/uapi/linux/version.h \
/lib/modules/`uname -r`/build/include/linux

Puis on lance la génération des pilotes :

# /usr/bin/vmware-modconfig --icon="vmware-workstation" --appname="VMware"

La compilation des pilotes (fix + modconfig) est à faire à chaque mise à jour du kernel Fedora.

Voilà maintenant 4 mois que mon serveur tourne sous Ubuntu 12.04 et propulse des VPS sous LXC. J'aime le côté prêt à l'emploi, en quelques lignes on obtient un container fonctionnant aussi bien qu'un serveur physique. A titre de comparaison je me suis cassé les dents avec les jails de FreeBSD, puisque named (daemon DNS) ne semble pas fonctionner (par défaut il essaie de se lancer en chroot, chose visiblement impossible dans une jail).

Par contre cela a aussi des inconvénients, par exemple l'implémentation LXC de ubuntu fournit un réseau avec du NAT par défaut. Ceci est idéal quand on est pressé, mais pas quand on veut paramétrer proprement son réseau avec un parefeu en amont, cela oblige à modifier la configuration.

J'ai testé jusque là 5 systèmes (disponibles en templates ou par bidouillages) :

• Ubuntu : OK
• Debian : OK
• OpenSuse : OK
• Fedora : ECHEC (yum n'est pas présent donc le template échoue)
• Archlinux : ECHEC (malgré une procédure identique à opensuse je n'ai pas réussi à le booter)

Je trouve que LXC est une très bonne solution d'appoint pour créer des VPS et fonctionne aussi bien que la virtualisation KVM, à condition de faire tourner des systèmes Linux. J'ai hâte de voir ce que nous réserve l'avenir, et j'attends beaucoup de l'intégration libvirt et openvswitch ;)

$ sudo lxc-list
RUNNING
  dns
  jabber
  mail
  mx
  web

A bientôt !

Si vous essayez d'installer Windows 8 dans Linux-KVM vous allez rencontrer le bug suivant :

Your PC needs to restart.
Please hold down the power button
Error Code: 0x0000005D
Parameters:
0x03060203
0x756E6547
0x49656E69
0x6C64746E

Il s'agit d'une réaction au type de CPU affiché par Linux-KVM (Qemu Processur), la solution consiste à copier la configuration du CPU hôte afin que ce dernier s'y retrouve. Pour cela ouvrez les paramètres de votre VM, allez dans "Processor" puis "Configuration" et cliquez sur "Copier la configuration CPU de l'hôte".

Vous pouvez maintenant virtualiser Windows 8 sous Linux sans devoir installer VirtualBox ou VMware !

Merci à Regardt van de Vyver

J'ai regardé si il était possible d'installer un container LXC openSUSE sur un hôte Ubuntu. De manière propre et simple, non ce n'est pas faisable. Aucune documentation à ce sujet, et le template fourni ne fonctionne pas car il requiert zypper, non disponible sur ubuntu.

Par contre en bidouillant c'est possible, voici ce que j'ai fait :

• S'installer un système openSUSE en physique ou en virtuel
• Installer LXC dessus et faire un container à partir de cette documentation.
• Archiver ce container (tar -cvf vps.tar /var/lib/lxc/vps) et le transférer sur le serveur ubuntu (en sftp par exemple).
• Extraction de l'archive dans le bon dossier (tar -xvf vps.tar -C /var/lib/lxc/)
• Renommage, ajout de la configuration réseau dans le "config" de ce container
• Démarrage du container, ça fonctionne
• Pour configurer le réseau à la main : ifconfig eth0 192.168.0.10 netmask 255.255.255.0
• Pour la passerelle : route add default gw 192.168.0.254 eth0
• Pour le DNS : echo "nameserver 8.8.8.8" > /etc/resolv.conf
• Installation de yast2 et vim (zypper install autoyast2-installation vim)

Et voilà, un système openSUSE fonctionnel tournant dans un container LXC et un hôte Ubuntu !

Premier retour après bientôt un mois de migration de mon serveur sous LXC.

Cela fonctionne plutôt bien, les ressources consommées sont faibles, les systèmes invités s'administrent comme des machines physiques, et après un redémarrage de l'hôte rien n'est perdu tout repart correctement. Il y a cependant certains cas un peu pointilleux, par exemple un container refusera de démarrer si il ne peut pas trouver de configuration réseau. Après avoir modifié quelques scripts propres à ubuntu qui ajoutaient une couche NAT et un serveur DHCP pour le réseau lxcbr0, je me suis retrouvé dans l'impossibilité de démarrer des containers nouvellement créés. Après une bonne heure de galère, sans aucun retour d'information (pas de log), j'ai fini par comprendre que je devais éditer leur fichier interfaces et placer une configuration IP statique.

Le template opensuse fourni dans ubuntu 12.04 n'est pas exploitable car il requiert le logiciel zypper et celui-ci ne semble pas disponible dans apt. Fedora demande yum mais ce dernier est en revanche fourni. Jusque là je me suis contenté de faire des containers ubuntu et debian sur lesquels je n'ai pas rencontré de souci.

J'ai une interrogation sur les migrations, peut-on transférer des containers LXC vers un autre serveur et les exécuter correctement, surtout si la distribution hôte n'est pas la même ? C'est une chose que je testerai bientôt.

Je m'auto-héberge pour beaucoup de choses sauf ce blog, et j'ai très souvent changé l'OS ou le matériel au cours de ces dernières années. En 2010 je débutais avec un Alix équipé d'un processeur AMD à 500Mhz. Il fonctionnait sur Debian. Je suis passé un peu plus tard sous NetBSD puis OpenBSD. Par la suite, ayant décidé de changer mon ordinateur personnel, mon ancien (dell inspiron 9400) fut disponible pour faire office de serveur et m'offrit la possibilité de faire de la virtualisation. Après m'être posé la question du choix de l'OS, j'ai finalement retenu CentOS. La machine étant trop "présente" (bruit+chaleur+consommation) je suis rapidement revenu sur l'Alix avec OpenBSD.

Étant actuellement dans l'optique d'installer une infrastructure réseau propre avec une DMZ, j'ai décidé de remanier une nouvelle fois mon serveur. C'est toujours un mini-PC, Intel D945GSEJT mais cette fois équipé d'un processeur Atom avec 1GB de ram ce qui me laisse un peu plus de marge dans le choix des technologies.

J'ai retenu LXC pour gérer la séparation des rôles, car étant intégré au kernel linux et en pleine expansion. J'ai retenu Ubuntu 12.04 server comme système d'exploitation, car je l'ai trouvé meilleur au niveau de la gestion de LXC :

• Fedora 17 : n'offre pas de template
• Debian 7 : les templates ont des bugs
• Ubuntu 12.04 : les templates sont parfaits, le réseau est créé automatiquement (de type "routed")

J'ai actuellement mis en place 4 systèmes-invités à partir du template ubuntu, ce qui donne ceci :

Le serveur ne fait qu'un léger bruit, celui du HDD 2,5", mais il est largement supportable on peut très bien dormir dans la même pièce. Chaque VPS dispose de sa propre adresse IP et fournit les rôles définis : SMTP, XMPP, HTTP, DNS.

Ce qu'il reste à faire

Je n'ai actuellement pas de dispositif de sauvegarde, ce qui peut m'être fatal en cas de panne matérielle. J'ai prévu d'étudier backupninja et bacula, pour voir quelle solution me permet de gérer le plus facilement et efficacement possible les sauvegardes des données sur mes VPS.

J'ai souvent parlé de Linux-KVM en citant parfois des défauts qui peuvent lui être préjudiciables. Ils ne se trouvent pas dans la technologie elle-même mais plutôt dans les outils d'administration peu fiables (virt-manager) voir inexistants qui demandent alors beaucoup de bidouilles lorsque l'on veut s'en servir sérieusement et durablement.

Red Hat travaille beaucoup sur l'amélioration de l'écosystème KVM et semble avoir compris les problématiques et les enjeux. En effet pour pouvoir lutter contre les solutions VMware qui sont pour beaucoup des références, ils créent des nouveaux outils dans le but de faire de KVM une solution d'entreprise et non de bidouilleur.

Présentation

oVirt est la branche opensource et gratuite de RHEV (RedHat Enterprise Virtualization). Cette solution offre un système de gestion d'un cluster de virtualisation similaire à VMware vCenter. Il utilise des technologies connues : VirtIO, libvirt, kvm, spice. L'interface utilisateur est une application JBoss (accessible en web) utilisant une base de données postgresql.

oVirt est défini en deux parties : engine qui est l'application elle-même, et node qui est en fait un hyperviseur membre du cluster que nous mettons en place. Schématiquement, voici ce que cela donne :

Les instructions d'installation peuvent être trouvées sur cette page et ce PDF. Le plus simple est d'utiliser Fedora 16 sur la machine où nous allons installer oVirt Engine, tout simplement car un dépôt rpm est proposé et facilite grandement les choses. Concernant oVirt Node, il suffit de récupérer une image ISO et de l'installer sur la machine qui servira d'hyperviseur. Voici un aperçu de l'interface oVirt (cliquez pour agrandir) :

Le stockage se fait sur un serveur NFS ou une baie SAN (connexion iScsi). La documentation détaille tout.

Fonctionalités

Cette page liste les fonctionnalités proposées à l'heure actuelle. Je passe sur les détails techniques comme le nombre de vcpu pour parler plutôt des services fournis.

Datacenter

• Administrer un cluster d'hyperviseurs
• Proposer une interface graphique complète
• Faciliter la mise en place des machines virtuelles et leur migration à chaud
• Assurer si besoin une haute disponibilité
• Faciliter la centralisation du stockage des supports
• Faciliter le p2v

Utilisateur

• Proposer un portail utilisateur pour se connecter à son bureau (plugin SPICE mozilla)
• Virtualisation desktop pour clients légers grâce au protocole SPICE (support USB)
• Technologies d'optimisation du réseau pour limiter les latences dans l'affichage

Ma conclusion

oVirt est clairement de la catégorie artillerie lourde puisqu'il faut pas moins de 3 serveurs physiques au minimum pour mettre en place l'infrastructure. De plus, l'engine (qui propose l'interface web) est très gourmand en mémoire, les spécifications recommandent 4GB. Celui qui a besoin d'un unique hyperviseur se tournera donc vers des solutions plus légères et mieux adaptées comme Proxmox.

Néanmoins, pour une entreprise qui veut virtualiser une dizaine (ou plus) de serveurs, oVirt semble une excellente solution. Il est possible de se tourner vers RHEV pour obtenir la version commerciale avec du support pour plus de pérennité.

J'espère grandement avoir un jour l'occasion de travailler avec oVirt/RHEV en situation réelle.

Voici une petite bidouille pour transférer un serveur OpenBSD physique vers une machine virtuelle (VMware dans mon cas, mais cela devrait fonctionner avec tous).

A moins de faire une mauvaise commande, il n'y a aucun risque pour le serveur car on ne modifie rien dessus.

Etape 1 : installation de la VM

Ici, rien de particulier. Récupérez une ISO d'OpenBSD et effectuez l'installation dans une machine virtuelle. Configurez le réseau afin d'avoir un accès SSH.

Etape 2 : lister l'essentiel sur le serveur physique

Si je liste ce que contient mon serveur, voilà ce que j'obtiens :

$ ls /
altroot boot    bsd.mp  dev     home    obsd    sbin    sys     usr
bin     bsd     bsd.rd  etc     mnt     root    stand   tmp     var

Mon serveur fait tourner OpenSMTPD dont la config se trouve dans /etc et les messages dans /home. Vient ensuite dovecot installé à partir des ports, ses fichiers se situent dans /usr (et la config dans /etc). Et pour finir, prosody qui vient lui aussi des ports et exploite une base de données située dans /var. La liste des répertoires à transférer est donc :

• /etc
• /home
• /usr
• /var

Etape 3 : sauvegarde des répertoires

On utilise un bon vieux tar (vous pouvez utiliser la compression en rajoutant l'argument z) :

# tar -pcvf etc.tar /etc/
# tar -pcvf home.tar /home/
# tar -pcvf usr.tar /usr/
# tar -pcvf var.tar /var/

Attention à ne pas travailler dans le répertoire /home lorsque vous faites la deuxième commande ! Sinon cela ne terminera jamais (il va archiver le fichier d'archive nouvellement créé, etc).

Etape 4 : transfert des archives sur la VM

Le plus simple est d'utiliser le protocole sftp (actif du moment que sshd est actif sur vos systèmes). Cela peut-être fait depuis Filezilla sur une tierce machine (avec les comptes root).

Etape 5 : Rétablissement des utilisateurs

Pour des raisons de sécurité, le fichier contenant les utilisateurs du système et leurs mots de passe est en lecture seule, même pour root (voir cette page). Vous devez utiliser l'outil vipw pour les importer.

Ouvrez vipw sur l'ordinateur hôte, copiez toutes les lignes situées après la ligne "nobody", et collez-là à la suite dans le vipw de la VM (vous pouvez faire cette opération depuis un ordinateur tiers et des connexions SSH).

Etape 6 : installation sur la VM

La procédure est classique, sauf qu'il faut penser à sauvegarder le fichier fstab car le partitionnement peut différer :

# tar -pxvf var.tar -C /
# tar -pxvf usr.tar -C /
# tar -pxvf home.tar -C /
# cp /etc/fstab /root/
# tar -pxvf etc.tar -C /
# cp /root/fstab /etc/
# reboot

Pensez à revoir la configuration du rc.conf, notamment le nom d'hôte et le réseau qui peuvent différer.

Si il y a une chose qui a toujours été compliquée sur la virtualisation KVM, c'est de faire un pont-réseau (Bridge) c'est à dire faire comme si votre machine virtuelle était branchée physiquement au réseau (on peut ainsi mettre une IP sur le même réseau que les autres et se passer de NAT ou routage). Il fallait faire des manipulations sur l'hôte pour mettre en place le pont, cela changeait selon les OS, bref c'était un peu fastidieux.

Depuis Fedora 17, une nouvelle fonctionnalité, "macvtap" qui permet d'automatiser toute cette opération un peu comme sur VirtualBox. Il suffit de sélectionner, en périphérique source, Périphérique hôte p4p1 : macvtap en remplaçant p4p1 par le nom de votre carte réseau.

Une excellente chose qui va faciliter la vie de beaucoup de gens !

Suite à mon article précédent, j'étais parti sur une solution Proxmox pour mon hyperviseur. Cependant je me suis rapidement énervé sur l'applet VNC en Java qui permet d'avoir l'affichage des machines virtuelles. Il est lent (impossible d'attraper le grub d'une VM), rigide, et fait régulièrement planter Firefox. Ragequit.

C'est donc CentOS 6.2 x86_64 qui est venu remplacer Proxmox sur l'ordinateur. La console distante virt-manager est sur mon notebook en archlinux. Les deux semblent plutôt bien se marier puisque je n'ai eu que 3 crashs en un weekend (ce qui est un miracle pour virt-manager).

J'ai actuellement deux VM (je vous laisse deviner d'où viennent les noms) :

• Shadowbroker : serveur mail (Postfix + dovecot) sur CentOS 6
• Harbinger : serveur jabber (prosody) sur Debian Squeeze

La mise en place du serveur mail sous CentOS est intéressante à faire, notamment à cause de SELinux que j'ai choisi de ne pas désactiver cette fois. Cela fera l'objet d'un article très prochainement.

Mon ancien ordinateur portable Dell Inspiron 9400 va être recyclé en serveur de virtualisation, et j'ai bien entendu choisi une solution Linux-KVM. En effet bien que je ne sois pas contre VMware ESXi, que je considère comme le meilleur produit existant actuellement, je préfère explorer quelque chose de moins connu qui sera donc plus instructif.

Ma problématique est de choisir l'OS qui sera utilisé pour faire fonctionner l'hyperviseur. J'en ai retenu deux :

• CentOS
• Proxmox

CentOS s'installe en mode texte avec l'hyperviseur et le daemon libvirt. On peut ensuite y connecter une console Virt-Manager depuis un autre poste. L'inconvénient est que Virt-manager est tout sauf fiable : c'est rigide, bugué, grandement variable selon les versions, et pas disponible sur Windows. L'avantage est qu'en partant d'une solution comme CentOS on a une certaine liberté sur le choix des composants. On sait aussi que les mises à jour offrent des améliorations dans la virtualisation du fait du travail de Red Hat.

Proxmox offre une console en web donc indépendante de l'OS, et en pratique bien plus fiable et complète que Virt-manager. L'inconvénient est qu'une solution tout-en-un offre moins de souplesse dans le choix des composants ou leur modification. On ne sait pas également comment évolue le produit, si les mises à jour se contentent de corriger les bugs, ou si elles apportent des améliorations de performances et l'introduction de nouveautés comme sur CentOS / RedHat.

Je pense retenir Proxmox, les OS invités seront sûrement des debian ce qui permettra d'utiliser les containers OpenVZ et économiser des ressources par rapport à KVM.

Proxmox VE - Virtual Environment - est une solution de virtualisation bare metal orientée entreprise prête à l'emploi, basée sur l'hyperviseur Linux-KVM et les containers OpenVZ. Sa particularité est de proposer une console graphique en web pour administrer le tout. La version 2 est actuellement en beta, mais sa sortie finale est prévue d'ici le mois de Mars (2012 Q1 d'après la roadmap).

Caractéristiques

L'entreprise Proxmox qui développe Proxmox VE met son produit à disposition gratuitement sous licence libre. Parallèlement à cela ils proposent du support payant (forums, assistance, requêtes aux développeurs...) et une solution de sécurisation de messagerie (mail gateway) payante, même si il existe une version free avec moins de fonctionnalités.

Proxmox VE permet de faire simplement un cluster avec plusieurs serveurs physiques, et depuis la version 2.0 la HA, High Availability (haute disponibilité) est possible. Il est donc envisageable d'assurer la continuité de service même en cas de panne matérielle. L'entreprise Proxmox dispose de certifications avec plusieurs constructeurs (la liste est visible dans leurs brochures commerciales).

Proxmox VE se base sur Debian 6.0 Squeeze amd64, avec un kernel "based on RHEL6x" et lui ajoute un dépôt permettant d'avoir l'interface web de configuration mais aussi une version de qemu à jour. Le fonctionnement en cluster fait appel au système de fichiers pmxcfs (Proxmox Cluster file system).

Installation

Vous devez commencer par télécharger l'ISO d'installation à cette adresse. Le processus est simple et ne demande que d'entrer un mot de passe root et de spécifier une adresse IP fixe. Le disque dur entier est automatiquement utilisé et formaté pour recevoir Proxmox. Après avoir démarré le système, vous pouvez lancer une mise à jour pour être certain d'avoir les dernières versions des composants. Vous pouvez le faire sur la machine même, ou par accès SSH de la manière suivante :

# apt-get update
# apt-get dist-upgrade

Découverte de l'interface

L'adresse IP de votre serveur Proxmox s'affiche lorsque celui-ci a fini de booter. Il y a également l'adresse de l'interface d'administration, elle est de la forme https et contient le FQDN ou l'adresse IP suivie du port 8006. Par exemple : https://10.40.1.17:8006

Cette vue affiche les principales informations de votre infrastructure : serveurs, authentification, configuration. Tout comme sur vSphere, le cadre du bas affiche les logs à la volée ce qui vous permet de connaître précisément les résultats de vos opérations sur l'hyperviseur. Dans le menu "storage" (stockage) vous pouvez voir vos différents périphériques : disque local, partage NFS, iSCSI. Stocker ses VM sur un support réseau permet de mettre en place la High Availability. La liste des serveurs à gauche permet d'accéder à une configuration individuelle : paramètres IP, nom d'hôte, etc.

Pour découvrir l'interface plus en détail et apprendre à mettre en place une machine virtuelle, Proxmox a créé une chaîne Youtube avec des tutoriels video. Voir les vidéos.

Virtualisation KVM vs container OpenVZ

Pour connaître le fonctionnement théorique de la virtualisation et des containers, je vous renvoie à cet ancien article dans lequel j'explique les différences entre les deux à l'aide de schémas.

OpenVZ est la solution la plus performante, puisqu'il n'y a aucune couche d'émulation et un seul kernel pour tous les systèmes invités. Il n'y a en pratique aucune perte de performance ou elle s'élève à seulement 2 ou 3%. Il faut cependant que le système invité soit de type Linux, puisqu'il sera dépourvu de kernel et utilisera celui de l'hôte. Pour cela, Proxmox VE utilise des templates (modèles). Il y a par exemple un template pour Debian Squeeze, qui va juste demander à l'utilisateur d'entrer un mot de passe root, les paramètres IP et l'installation se fera ensuite automatiquement. Le boot est presque instantané.

KVM va au contraire émuler un ordinateur complet afin de rendre le système indépendant de l'hôte. Cette virtualisation est assurée par le processeur de l'hôte (grâce aux instructions Intel VT-x ou AMD-V) et par Qemu pour la création des périphériques complémentaires. Il est ainsi possible d'installer des systèmes non modifiés tels que Windows, et d'utiliser des périphériques VirtIO (qui ne sont pas réellement émulés mais partagés avec l'hôte). Par contre SPICE, solution de virtualisation desktop développée par RedHat, ne semble pas encore disponible mais prévu.

Installation d'un Windows Server 2008 virtualisé

Je dispose d'un exemplaire de Windows Server 2008 en image iso (msdnaa). La première chose à faire est de l'envoyer sur le serveur. Pour cela, cliquez sur l'espace de stockage de votre choix dans la colonne de gauche. Dans l'onglet "content" vous verrez un bouton upload vous permettant d'envoyer votre iso. Il est aussi possible de le faire par SSH. Voir le tutoriel vidéo.

L'étape suivante consiste à créer une nouvelle machine virtuelle et à entrer les paramètres adéquats. Il est judicieux de sélectionner VirtIO pour le stockage et la carte réseau. Vous aurez cependant besoin de récupérer le CDROM de pilotes pour Windows. Vous pouvez suivre le tutoriel vidéo à cette adresse.

Attention, pour que la console fonctionne, vous devez avoir le plugin Java installé dans votre navigateur.

Une fois Windows 2008 installé, vous devrez aller dans le gestionnaire de périphérique pour installer les pilotes de la carte réseau (ils sont sur le CDROM VirtIO). Votre serveur virtualisé est maintenant prêt à l'emploi !

Conclusion

KVM, Linux, OpenVZ, sont des produits libres très puissants que l'on apprécie de voir fonctionner ensemble une fois leur configuration réalisée. Proxmox VE fournit un système où tout est déjà intégré, prêt à l'emploi. L'interface de configuration rend accessible à tous les administrateurs la mise en place de cluster de virtualisation, et rend ainsi cette solution compétitive avec celles du monde propriétaire.

Alors que Virt-Manager, développé par RedHat, est limité à Linux et tend à crasher très souvent, l'interface Web de Proxmox est universelle, stable, et bien plus complète.

Proxmox VE 2.0 est très bon !

Un petit lien vers un serveur du projet Fedora proposant des pilotes VirtIO pour Windows (réseau et stockage). Ils sont disponibles en 32 et 64 bits, pour XP / 2003 / Vista / 2008 / Seven et ils sont signés. Cliquez sur le dossier ci-dessous :

Le fichier vfd peut être monté sur un lecteur de disquette (émulé) dans la VM, afin de charger les pilotes du périphérique de stockage VirtIO et de pouvoir ainsi installer Windows. Pour XP/2003 il faut faire F6 dès le début, tandis que Vista/2008/Seven il y a une option "charger un pilote" dans l'outil de partitionnement. Le fichier iso contient les pilotes réseau (netkvm), stockage (viostor), balloon, vioser, qui peuvent être installés bien plus tard.

Cet article me sert de marque-page car j'ai souvent besoin de ces pilotes et je ne les retrouve plus. Il semble que la disquette et l'iso permettent aussi d'automatiser l'installation de guest Windows, chose sur laquelle je reviendrais plus tard.

VMware ESXi est l'hyperviseur historique aujourd'hui le plus utilisé en entreprise et l'un des plus efficaces. Leur expérience se ressent même dans les versions "light" de leurs produits destinées aux desktop.

VMware ESXi se présente sous forme d'un OS tenant dans une ISO de 200Mo à installer sur le serveur. Alors que la version 4 ne voulait pas fonctionner chez moi à cause des cartes réseau qui n'étaient pas détectées, avec la version 5 (sortie il y a peu) tout va bien. L'hyperviseur démarre sur une console graphique récapitulant les informations essentielles et permettant d'effectuer quelques réglages sommaires (adresse IP...).

Côté client il y a la console vsphere client à télécharger afin de pouvoir administrer l'hyperviseur. On remarque tout de suite qu'elle pèse très lourd, 350Mo, soit plus que l'hyperviseur lui même ! L'installation est donc très longue.

Par contre une fois la console lancée, on voit qu'on a à faire à quelque chose de très complet, très intuitif et très sérieux, par exemple le petit schéma sympathique qui détaille les éléments mis en œuvre pour la virtualisation. La création des machines virtuelles est simple.

Chose très appréciable : à la création d'une machine virtuelle il est possible de sélectionner une ISO qui n'est pas sur l'hyperviseur. J'ai donc pu aller chercher mon installation de Windows 2008 sur mon serveur FTP, alors que sur Hyper-V j'avais du l'envoyer sur le C$ de l'hôte.

L'installation de Windows 2008 fut rapide néanmoins j'ai eu beaucoup de mal avec le curseur de souris, subissant des mouvements par accroc et beaucoup beaucoup trop sensibles. Pas facile de cliquer sur un élément. Heureusement cela est résolu après l'installation des vmware tools. Il n'y a plus besoin de capturer le curseur et celui reste fluide.

On peut voir d'ailleurs que VMware a ses propres spécificités : son pilote graphique, qui supporte la 3D et les effets aero (dans la version desktop de vmware, si l'hôte le permet), sa carte réseau...

Je n'ai pas fait le tour des autres fonctionnalités comme le fonctionnement en cluster, l'import de serveur physique, mais VMware ESXi m'a semblé être la solution la plus performante, la plus soignée et la plus universelle. Malheureusement la console semble lourde et peu réactive, il y a parfois une latence entre le moment où l'on clique et celui où elle réagit. L'installation des OS Linux n'a pas posé de soucis, même avec les cartes réseau vmxnet.

Conclusion

VMware ESXi est complet, performant, bien pensé. C'est la solution que je retiens personnellement, même si cela ne signifie pas que les autres sont mauvaises. J'ai juste trouvé plein de petites choses sur ESXi (ou plutôt vsphere) qui le rendent idéal pour moi.