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.

J'ai un problème récurent avec pkgsrc. Pour bien comprendre le fonctionnement il faut savoir que NetBSD lui-même ne fourni que peu de logiciels. Un daemon SSH, FTP, HTTP... et pour le reste il faut aller piocher dans pkgsrc, l'équivalent des ports de FreeBSD ou de emerge sur Gentoo. Un ensemble de scripts qui va chercher les sources d'un logiciel et les compile ainsi que ses dépendances.

L'ennui est que par deux fois déjà j'ai été confronté à des logiciels qui ne marchent pas. Prenons tout d'abord prosody. La compilation et installation fonctionnent mais le logiciel ne se lance pas, l'erreur suivante s'affiche :

# prosodyctl start

**************************
Prosody was unable to find util.encodings
This package can be obtained in the following ways:

        Windows:      Make sure you have encodings.dll from the Prosody distribution in util/
        GNU/Linux:    Run './configure' and 'make' in the Prosody source directory to build util/encodings.so

util.encodings is required for Prosody to run, so we will now exit.
More help can be found on our website, at http://prosody.im/doc/depends
**************************

La solution est d'ajouter le préfixe LD_LIBRARY_PATH indiquant l'emplacement des librairies :

# LD_LIBRARY_PATH="/usr/pkg/lib" prosodyctl start

Et puisqu'il n'y a pas de script rc.d pour lancer Prosody, en voici un. Il n'est sûrement pas très propre ou pas parfait mais il fonctionne. Il est inspiré de celui fourni sur FreeBSD :

#!/bin/sh
#
# Prosody XMPP Server init script
#

# PROVIDE: prosody
# REQUIRE: LOGIN

$_rc_subr_loaded . /etc/rc.subr

name="prosody"
pidfile="/var/run/prosody.pid"
command="/usr/pkg/bin/prosodyctl"
load_rc_config $name
prosody=${prosody_enable-"NO"}
extra_comands="status"
start_cmd="prosody_cmd start"
stop_cmd="prosody_cmd stop"
restart_cmd="$stop_cmd; $start_cmd"
status_cmd="prosody_cmd status"

prosody_cmd()
{
        if !  /var/run/prosody.pid -f
        then
                touch /var/run/prosody.pid && chown prosody:wheel /var/run/prosody.pid
                LD_LIBRARY_PATH="/usr/pkg/lib" /usr/pkg/bin/prosodyctl $1
        else
                LD_LIBRARY_PATH="/usr/pkg/lib" /usr/pkg/bin/prosodyctl $1
        fi
}

run_rc_command "$1"

Puis ensuite :

# /etc/rc.d/prosody start

J'essaie maintenant de compiler Xen 4.1 mais ça ne passe pas. Il y a une petite modification à faire dans le Makefile pour pouvoir y arriver. Mais les étapes suivantes posent aussi des problèmes. Si je trouve la solution j'écrirais un article pour la décrire. Je viens de m'inscrire à la mailing list des bugs de pkgsrc et lorsqu'elle sera validé je soumettrai des rapports de bugs.

pkgsrc n'est donc pas fiable à 100%. Il y a des logiciels qui ne compilent pas ou ne se lancent pas.

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

Lorsque vous tentez de vous connecter en SSH sur un serveur CentOS, le login peut prendre de trèèès longues secondes, une bonne trentaine au moins, même en réseau local ce qui se révèle très énervant à force.

En fait il faut ouvrir le fichier /etc/ssh/sshd_config sur le serveur et modifier quelques paramètres.

GSSAPIAuthentication no
UseDNS no

Et voilà, le login est maintenant instantané. Très pratique pour Virt-Manager qui utilise une connexion SSH pour joindre KVM !

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