Ce petit article va lister les solutions de virtualisation libres que vous pourrez trouver sur Linux ou FreeBSD/NetBSD. Je les ai classés par technologie, vous pourrez trouver un résumé sur Wikipedia si besoin.

Isolation

L'idée est la suivante : mon serveur tourne sur Linux, et je veux des machines virtuelles sous Linux également. C'est donc un peu dommage d'avoir des composants en double voire en triple ainsi qu'un empilement de couches identiques n'est-ce pas ?

L'isolation consiste à créer des "cloisons" dans lesquelles vous exécutez les OS invités. Ils utilisent le système de fichiers de l'hôte ainsi que son kernel mais avec des droits limités (accès et ressources). La perte de performances est nulle, puisqu'il n'y a pas d'émulation, en revanche vous devez utiliser le même type d'OS que l'hôte. Si votre serveur tourne sur Linux, vos OS isolés devront être également de type Linux.

• OpenVZ : Solution fiable et robuste de longue date. Vous pouvez la mettre en place très facilement avec Promox VE.
• Linux V-Server : Je ne fais que la citer car je ne l'ai jamais testée.
• LXC : Assez récent et visiblement de plus en plus utilisé. Il utilise plusieurs features du kernel Linux dont les cgroups.
• chroot : Se limiste à isoler une arborescence du système de fichiers, ne permet pas de cloisonner à proprement parler un OS.
• FreeBSD Jail : Outil très puissant qui peut se limiter à faire le boulot d'un chroot ou alors cloisonner un système invité FreeBSD tout entier.
• Solaris Containers : Jamais testé mais similaire aux Jails.

Virtualisation complète

La machine virtuelle émule le matériel et le bios pour le système invité. Celui-ci dispose donc de son propre environnement et fonctionne en autonomie. Il n'a pas conscience d'être virtualisé.

Le gros avantage est que tous les OS peuvent tourner en machine virtuelle du moment qu'ils disposent des bons pilotes (mais on émule des périphériques anciens et courants justement pour ça). Il y a aussi une "abstraction" du matériel physique. Quelque soit le serveur sur lequel vous faites tourner votre machine virtuelle, cette dernière verra toujours le même matériel (qui est émulé). Donc pas besoin de réinstaller de drivers si on change de support. L'inconvénient est la perte importante de performances du fait de la nécessité d'émuler le matériel. La consommation de mémoire vive est aussi importante (il n'est pas rare de trouver des serveurs avec 24GB de ram, voire plus).

• QEMU : Une machine virtuelle capable d'émuler de nombreuses architectures (i386, x86_64, arm...). Libre et disponible sur de nombreux OS.
• KVM : Il s'agit de QEMU + quelques extensions indispensables, notamment le support des instructions de virtualisation CPU (Intel VT-x et AMD-v). La machine virtuelle n'émule plus de CPU, elle peut accéder au vrai. Les performances sont de loin meilleures (d'un facteur de 10 ou 20). On trouve aussi VirtIO qui n'est rien d'autre que de la paravirtualisation pour certains périphériques (carte réseau et stockage). KVM est la solution de virtualisation phare sur Linux.

Paravirtualisation

Le principe est encore différent, cette fois nous n'avons plus d'OS "principal" sur lequel les autres s'empilent. Tous les systèmes cohabitent ensemble et se partagent l'accès au matériel. Néanmoins, l'un d'eux est dit "privilégié" et fournit des outils pour administrer l'ensemble. Sur Xen, c'est Dom0.

VMware ESX et Hyper-V sont des solutions de paravirtualisation propriétaires très utilisées en entreprise. Elles sont tellement connues et répandues que je suis bien obligé de les citer, même si elles ne sont pas libres.

• Xen : Disponible sur la majorité des OS libres : Linux, FreeBSD, NetBSD, et même Hurd. Fonctionne aussi sur Windows avec quelques conditions (notamment les instructions de virtualisation CPU). Xen appartient aujourd'hui à Citrix mais reste libre. Le kernel Linux 3.0 va l'intégrer.

Conclusion

Pour bien comprendre les avantages et inconvénients il faut mettre en place ces différentes solutions soit-même. C'est très instructif et intéressant.

Chaque solution s'utilise selon la situation. Un administrateur qui souhaite faire fonctionner un serveur avec des services critiques se tournera vers l'isolation. L'entreprise qui souhaite faire de la haute disponibilité et s'émanciper des contraintes matérielles se tournera vers la virtualisation ou paravirtualisation.

Suite au précédent article qui traitait de l'installation d'un serveur dédié de virtualisation sur CentOS et la mise en place d'une console graphique distante, nous allons maintenant en découvrir rapidement les fonctionnalités et mettre en place un Windows 2003 server.

Lire la suite de #2 : Présentation de la console Virt-Manager et ajout d'une machine virtuelle

Les habitués de VMware et compagnie sont habitués à faire tourner des serveurs dédiés à la virtualisation et à utiliser une console graphique depuis une autre machine. KVM, qui est la solution de virtualisation la plus avancée dans le monde Linux et grandement développée par Red Hat, permet de faire cela aussi.

L'objectif de cet article sera de présenter les différentes couches utilisées, ainsi que la mise en place de notre serveur et de sa console distante en environnement CentOS.

Lire la suite de Serveur de virtualisation KVM avec CentOS et console graphique distante : #1 Installation

Si il y a une chose qui m'a beaucoup manqué dans la virtualisation avec KVM par rapport à VirtualBox, c'est un moyen propre de faire des snapshots. Ces sauvegardes légères permettent de revenir simplement à un état donné, de manière instantanée. Mais avec le RTFM de qemu-img, j'ai découvert que c'était possible.

Il faut se rendre dans le répertoire où sont stockés les images des machines virtuelles, et utiliser la syntaxe suivante:

# qemu-img snapshot -c MASTER server.img

Où "MASTER" est le nom que vous donnez à votre snapshot. Pour lister les snapshots d'un fichier image, la syntaxe est la suivante:

# qemu-img snapshot -l server.img

Ce qui retournera quelque chose comme ça:

Snapshot list:
ID        TAG                 VM SIZE                DATE       VM CLOCK
1         master                    0 2011-04-13 21:48:20   00:00:00.000

Et enfin, pour charger un snapshot (restaurer l'image telle qu'elle était), la syntaxe est:

# qemu-img snapshot -a MASTER server.img

A noter que j'indique d'entrer la commande en root car les images créées via virt-manager ont le root comme propriétaire.

Mon serveur perso a subit quelques désagréments récemment. Cela a commencé par des "clic clic" audibles indiquant que le disque dur arrivait en fin de vie suivi par quelques plantages (en conséquence). Sur ce coup je ne peux que m'en vouloir à moi-même, le disque dur en question étant une pièce récupérée d'un vieux PC portable d'occasion (on ne fait pas du neuf avec du vieux).

Puis des problèmes avec les câblages sont survenus. En effet, comme je le montrais sur les photos, il est branché directement sur la Livebox, mais cela coince au niveau des prises de courant à cause d'un boitier CPL utilisé pour la télé qui a tendance à englober plusieurs prises à la fois du fait de sa taille imposante. J'avais donc du revoir les branchements et utiliser un système de multiprises mais il a récemment montré ses limites quand tout à coup la Livebox a refusé de se synchroniser en PPP... Le débranchement du serveur et le retour à des câblages propres ont résolu le problème.

Virtualisation

En attendant une vraie solution, j'ai lancé mon backup de serveur en machine virtuelle. Il suffit de modifier les redirections de port sur la Livebox, et ça roule. Au début c'était sur Virtualbox, puis étant donné que la situation est amenée à durer je l'ai refait au propre sur KVM.

Mon ancien serveur s’appelait Flemeth, le nouveau s'appelle donc Morrigan, logique... Je lui ai assigné 1 CPU, 256Mo de ram et 10Go de stockage (qcow2 avec cache désactivé), largement suffisants pour l'usage. Le système est toujours Debian, mais en version amd64 cette fois. Ensuite il m'a fallu trouver une solution pour le réseau. Si la Livebox avait été un routeur "classique et sérieux", il m'aurait suffit de rediriger les ports des différents services sur l'IP de ma machine virtuelle. Sauf que la Livebox n'est pas un routeur classique, il y a des choses bien mais aussi des mauvaises. Notamment la redirection de ports ne se fait que sur les machines connues de la box, et les machines virtuelles n'apparaissent pas même si on a fait un pont réseau... donc ma solution est simple et détaillée un peu plus loin.

Lire la suite de Serveur virtualisé