Maniatux's Blog

Welcome to the internet

Virtualization

Les solutions de virtualisation sur Linux

Written by Xavier - - 5 comments

Depuis 5 ans environ je m'intéresse de près aux solutions de virtualisation sur Linux. J'ai eu l'occasion d'en utiliser plusieurs et j'ai décidé de rédiger un court article à ce sujet. Pourquoi court ? Simplement parce que chaque solution mérite un livre entier et qu'en un article je ne peux tout résumer efficacement.

Notez que dans l'article je vais omettre volontairement 3 solutions :

  • VServer car je ne l'ai jamais utilisé
  • Docker car je ne l'ai jamais utilisé non plus et selon moi il se destine plus au packaging d'applications
  • Virtualbox car trop vaste et pas très utilisé sur les serveurs

OpenVZ

OpenVZ est en quelques sortes la solution historique de virtualisation basée sur les containers sous Linux. C'est un outil puissant qui permet de faire fonctionner plusieurs systèmes invités avec limitation du CPU, RAM, quota de disque mais surtout émulation du /proc et /sys ce qui permet au système invité de voir réellement les ressources allouées. Par exemple si on définit une limite de 256Mo de RAM, un htop montrera que votre système dispose 256Mo de RAM. Si on alloue 10GB de disque, df montrera 10GB. Cela rend OpenVZ idéal si vous souhaitez fournir des VPS à vos clients, car ils seront à la fois isolés et transparents pour l'utilisateur.

Deux inconvénients majeurs à OpenVZ : ce n'est pas un projet upstream (nécessite d'utiliser un kernel patché) et l'inertie du projet. Le dernier kernel supporté par OpenVZ est le 2.6.32 ce qui nous ramène tout de même en 2010 (c'est le kernel de rhel6). Dans un billet de blog l'équipe d'OpenVZ défend ce choix : le 2.6.32 n'est pas vieux, il est "stable et éprouvé". Il faut tout de même constater qu'en 2015 le 2.6.32 peut être pesant, face à certaines technologies qui nécessitent un kernel récent (systemd). Un travail est en cours pour qu'OpenVZ soit utilisable sur un kernel upstream récent, malheureusement il est loin d’être fonctionnel. Fin 2014 l'équipe OpenVZ a annoncé une simplification dans leur fonctionnement : Virtuozzo (version propriétaire) et OpenVZ (version libre) vont fusionner et une version compatible kernel 3.10 sera disponible. Pas de date annoncée, juste "début 2015" et pas de nouvelles depuis.

Il faut noter également que dans un container il n'est pas possible de charger des modules noyau, vous devez le faire sur l'hôte. Par exemple si vous souhaitez utiliser fuse ou iptables, vous devez au préalable charger les modules sur l'hôte. Cela peut être un avantage (sécurité) ou un inconvénient (si votre hébergeur n'a pas chargé les bons modules sur l'hôte, c'est fichu pour vous). Autre point intéressant : OpenVZ est la solution utilisée par OVH pour ses VPS Classic.

LXC

LXC est un ensemble d'outils permettant d'utiliser les cgroups pour la virtualisation basée sur les containers. Contrairement à OpenVZ qu'il vise à remplacer, LXC est upstream. Malheureusement son évolution est très lente, et il y a encore beaucoup de manques qui ne sont toujours pas comblés malgré les années. Cela va de la faille de sécurité au désagrément. Deux exemples : tout d'abord un utilisateur root dans un container qui arriverait à écrire sur l'hôte serait toujours considéré comme root, l'isolement n'est donc pas parfait. Ce point est colmaté plus ou moins efficacement par SELinux, Apparmor ou par le mode "unprivileged" de LXC qui pose à mon sens beaucoup plus de désagréments que d'avantages. Autre point négatif, LXC n'émule pas de /proc ni /sys. Donc si on alloue 256Mo de RAM à notre container et que l'on lance htop dans ce dernier, la quantité de RAM affichée sera faussée (ce sera celle de l'hôte, par exemple 8GB), idem pour df et l'espace disque. Impossible de louer des VPS à des clients puisque les informations du système qu'ils verront seront seront celles de l'hôte, donc faussées.

LXD et LXCFS doivent palier ce manque, malheureusement ces projets sont encore jeunes (fin 2014) et pas du tout utilisables à l'heure actuelle. LXD va permettre de lancer de manière simple des containers en mode "unprivileged" avec une surcouche Apparmor pour parfaire l'isolement. LXCFS va émuler /proc et /sys ce qui va non seulement permettre au container de voir réellement les ressources qui lui sont allouées, mais aussi résoudre certains problèmes quand on empile les instances de systemd.

Xen

Xen est une solution complexe et particulière, à mi chemin entre la vraie virtualisation et les containers. C'est un mini système d'exploitation qui démarre en premier et qui se comporte comme une sorte de switch entre vos systèmes invités pour l'accès au matériel. C'est une solution particulière pour deux raisons : votre système d'exploitation hôte devient Dom0, il n'est plus le maître, c'est un invité tournant sur Xen pour lequel vous devez allouer des ressources. Le rôle Dom0 lui permet de piloter Xen. Ensuite il nécessite que vos systèmes invités soient "compatibles" Xen. C'est le cas pour Linux en upstream ainsi que FreeBSD et NetBSD dans des versions spécifiques, mais pas Windows.

Pour faire tourner Windows dans Xen, il faut invoquer le mode "HVM" qui va alors fonctionner plus ou moins comme KVM, c'est à dire avec la virtualisation CPU. A cela s'ajoutent différents modes: PVHVM et PHV qui correspondent à différents niveaux de mélanges entre la virtualisation CPU et la paravirtualisation. Xen est une science à lui tout seul et il y a de quoi y passer des jours.

Contrairement aux containers limités à Linux, Xen supporte plusieurs systèmes d'exploitations, dans plusieurs versions. En effet chaque système invité (DomU) charge son kernel, ce qui offre plus de libertés (par exemple la possibilité de charger des modules). Et là encore, l'isolement est très bon ainsi que la visibilité des ressources allouées, ce qui permet d'utiliser Xen si vous souhaitez fournir des VPS.

Xen est utilisé entre autres par AWS (le cloud Amazon).

KVM

KVM est la solution phare de virtualisation sous Linux, poussée par Red Hat qui base plusieurs solutions dessus. KVM est une puissance brute entourée d'excellents composants tels que VirtIO qui ajoute de la paravirtualisation dans les périphériques virtuels. Avec les instructions de virtualisation et un bios émulé, KVM permet de faire fonctionner quasiment n'importe quel système d'exploitation.

Malheureusement, le gros défaut selon moi de KVM est le manque d'outils simples à utiliser. Virt-manager est à mon sens trop bugué pour convaincre, et ce depuis des années. oVirt est en revanche excellent mais taillé pour les grosses infrastructures. Au final KVM est peut être un peu trop restreint aux professionnels qui peuvent bâtir une infrastructure conséquente pour y faire tourner du oVirt ou de l'Openstack.

Conclusion

A chaque solution son usage et le sujet est tellement vaste qu'il est difficile de conclure. Néanmoins je constate que LXC n'est toujours pas mûr, OpenVZ reste devant. Pour ceux qui ont les moyens, l'infrastructure et des besoins spécifiques, KVM et Xen sont des solutions toutes indiquées même si à mon sens KVM sera plus logique pour les sysadmin habitués à VMware.

Debian 8 + Xen + Virt-manager HOWTO

Written by Xavier - - 2 comments

Xen + libvirt is an interesting choice of toolstack, it makes network-management and guest installation easier and enables graphical remote management of the VMs. However, Debian Wheezy has several issues, I have never been able to boot something using xen + virt-manager, so I strongly recommend Jessie which is pretty stable. In this howto, I use two servers : xen-01 (for Xen + libvirt, headless) and xen-console (for virt-manager, with Xfce desktop). You can use virtual or physical machines but I had issues with VMware because Xen keeps freezing when you try to boot a domU. However, Virtualbox works fine.

Read more Debian 8 + Xen + Virt-manager HOWTO

Debian : Configurer le réseau ipv4 d'un container LXC

Written by Xavier - - no comments

A rajouter dans le /var/lib/lxc/mycontainer/config :

# networking
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = lxcbr0
lxc.network.ipv4 = 192.168.0.3/24
lxc.network.ipv4.gateway = 192.168.0.254

lxcbr0 est à remplacer par le nom du bridge sur l'hôte.

Puis ensuite supprimer ou renommer le /var/lib/lxc/mycontainer/rootfs/etc/network/interfaces. Alternativement il est possible de juste commenter les lignes qui se rapportent à eth0.

Cette manipulation ne "verrouille" pas le container sur 192.168.0.3, il est toujours possible à l'aide de DHCP d'obtenir une autre adresse...

Debian 7 + Xen + Xapi + XenCenter HOWTO

Written by Xavier - - 7 comments

En 2011 dans l'article XenServer : le Xen facile je présentais la solution XenServer de Citrix qui est un serveur Xen prêt à l'emploi doté d'une console de gestion graphique similaire à vsphere : XenCenter. Puis en 2014 j'ai découvert que Xen installé à la main sur Debian n'était pas si méchant que ça : Découverte de XEN sur Debian Wheezy. Eh bien il parait que l'on peut marier les deux. Installer une debian, Xen, puis la couche Xapi qui permet ensuite de se connecter soit avec Xencenter, soit avec openxenmanager.

Sur papier l'installation est rapide et simple, mais en pratique elle est plutôt laborieuse car il y a beaucoup de bugs qui font que ça ne marche pas du premier coup et qu'il faut chercher des solutions. Voilà donc étape par étape comment installer Xapi sur Debian 7 et s'y connecter avec XenCenter.

Installation de Xen

Jusque là, rien de compliqué. Il faut installer le paquet xen-hypervisor :

# apt-get install xen-hypervisor

Puis on va dire à grub de booter en priorité sur Xen :

# dpkg-divert --divert /etc/grub.d/08_linux_xen --rename /etc/grub.d/20_linux_xen
# update-grub

Puis, on reboote afin de démarrer sur Xen, c'est très important sinon la suite ne fonctionnera pas.

# reboot

Installation de xapi

Après avoir démarré en Xen, installez xcp-xapi :

# apt-get install xcp-xapi

Notez que des paquets de développement comme linux-image sont installés comme dépendances. C'est pour pouvoir compiler les modules d'openvswitch. Cette étape est faite avec dkms, elle est donc automatique et suivra les montées de version du kernel sans action de la part du sysadmin. Pour le gestionnaire de réseau XCP, il est plus simple de laisser bridge.

Note : vous allez obtenir quelques messages de fail, ignorez-les pour le moment.

On va spécifier à Xen d'utiliser xapi comme backend. Editez le fichier /etc/defaults/xen :

TOOLSTACK="xapi"

Maintenant on va configurer notre bridge. Editez le fichier /etc/network/interfaces et modifiez-le comme ceci :

auto lo
iface lo inet loopback

# allow-hotplug eth0
# iface eth0 inet dhcp

auto xenbr0
iface xenbr0 inet dhcp
  bridge_ports eth0

Note : oui, eth0 est désactivé. Mais xenbr0 va prendre le relai.

Maintenant, rebootez le serveur.

# reboot

Connexion XenCenter

Si votre système ne boote pas et bloque sur la configuration du réseau Xen, vous devez alors forcer le redémarrage puis booter en mode de dépannage sur grub. Puis refaites la configuration du réseau ci-dessus.

Maintenant que votre système est booté, ouvrez la console XenCenter sur une autre machine et tentez de vous connecter à votre serveur Debian :

Au bout de quelques instants on obtient l'erreur suivante :

Après avoir bataillé et surtout ragé parce que visiblement personne n'avait jamais rencontré ce problème alors que je le reproduits à volonté, j'ai enfin trouvé une solution sur ce thread d'un forum citrix. Il s'agit en fait d'un fichier .pem qui ne fonctionne pas bien et qu'il faut donc détruire :

# rm /etc/xcp/xapi-ssl.pem

Puis relancez le service xcp-xapi pour regénérer ce fichier :

# service xcp-xapi restart

Maintenant, tentez à nouveau de vous connecter avec Xencenter, cela doit fonctionner.

Et voilà !

Il faut savoir cependant que xencenter ne révèle son potentiel que sur une infrastructure composée de plusieurs serveurs. Les VM et les ISO ne peuvent pas être stockées sur l'hyperviseur il faut obligatoirement un datastore externe (iSCSI, CIFS ou NFS).