Debian/libvirt hypervisor¶

Cet hyperviseur a été initialement créé par Benjamin Cama en 2012 pour tester une alternative au hyperviseurs VMWare ESXi déjà en place. Il héberge un certain nombre de VM pour les doctorants et les ingénieurs de RSM.

La machine utilisée s'appelle (historiquement) virtualc5-3, qui était auparavant un hyperviseur VMWare, et est située en A17b. C'est une Debian originellement squeeze, mise à jour en wheezy, avec comme outil principal de virtualisation libvirt.

L'installation spécifique de la machine est décrite dans installation de l'hyperviseur Debian/libvirt.

Un paquet spécifique est utilisé pour avoir des VM qui peuvent fonctionner uniquement avec un port série (sans partie graphique) : celui d'iPXE, où on active le port série au boot, afin qu'on puisse voir dans la console le boot PXE s'effectuer. En effet, l'installation se fait en bootant par le réseau, en PXE, sur la VM d'installation. Le code est dispo dans ce projet.

Création d'une VM¶

J'utilise les scripts du projet que j'ai créé ici. Presque tout peut se faire depuis sa propre machine, avec le contrôle à distance par SSH offert par libvirt.

Il faut d'abord s'assurer que la variable d'environnement de ''virsh'' de l'URI de l'hyperviseur est bien positionnée :

export VIRSH_DEFAULT_CONNECT_URI=qemu+ssh://virtual-a17-1.ipv6.enstb.fr/system

Pour la création même de la VM, on fait un ''make'' avec le nom de la machine qu'on veut en argument (nom court, sans espace), ce qui va créer le XML correspondant dans 'libvirt/' et lancer immédiatement la création (la définition pour être précis sur la terminologie libvirt) sur l'hyperviseur. Par exemple :

make machine-de-test

Le script demande quelques informations comme la taille de RAM, disque, nombre de vCPU, nom du responsable, etc. J'avais également préparé une cible pour créer un deuxième disque à la volée, qui serait utilisé comme PV (Physical Volume) LVM sans table des partitions car c'est plus simple à redimensionner :

make machine-de-test/second-disk

On peut effacer une machine ('''attention, c'est rapide, sans confirmation, et ça efface également tout le stockage (disque)''') avec :

make machine-de-test/delete

Il y a également des scripts de tentative de migration de VM VMWare, mais non finis ; regarder dans le Makefile et les XSLT ovf-libvirt-*.

Ensuite, on utilise les commandes standard de libvirt. Pour démarrer une VM :

virsh start --console machine-de-test

L'option ''--console'' permet d'obtenir tout de suite la console série. Elle boot par le réseau et peut démarrer un des installeurs offert sur le réseau. Attention, un petit ''bug'' fait que des fois, le nom de l'interface réseau est trop long pour l'OS ; il faut le corriger avec :

virsh edit machine-de-test # chercher domain/devices/interface/target et le raccourcir

Gestion des utilisateurs¶

Elle se fait uniquement depuis l'hyperviseur.

Si on veut donner un accès à la VM aux utilisateurs depuis l'hyperviseur, j'ai créé un script qui permet de le faire, dont le code est disponible ici. Pour qu'il s'exécute, il faut d'abord créer un utilisateur de manière adéquate :

adduser --disabled-password --ingroup vm-users test-user

Le groupe "vm-users" a été créé afin d'identifier quels utilisateurs ont besoin de sudo sans mot de passe pour effectuer les tâches de gestion (c.f. fichier "allow-vm-management" du code ci-dessus).

Ensuite, on leur donne accès par SSH à l'hyperviseur, mais uniquement pour lancer le script de gestion de VM, en ajoutant dans ~test-user/.ssh/authorized_keys :

command="/usr/bin/manage-vm machine-de-test" ssh-rsa AAAA…

Ici, c'est la clé RSA publique qui permet d'authentifier l'utilisateur (je n'offre pas de login avec mdp). On peut rajouter plusieurs machines en argument à la commande, également. C'est ce fichier qui fait la « liaison » entre les utilisateurs et les machines qu'ils auront le droit d'administrer.

Notez que cet accès est fait pour la gestion à l'installation et en cas de dépannage ; le reste du temps, l'utilisateur gère sa machine en s'y connectant directement par le réseau, pas par l'hyperviseur.

IP publique¶

Depuis l'hyperviseur uniquement, pareillement.

Une demande récurrente est d'offrir une IP publique à la VM. Je ne l'ai jamais automatisée car les demandes répétées sont récentes. Pour offrir cette possibilité, l'hyperviseur est relié au VLAN 5 (ou 50 également) qui sert à adresser des machines qui veulent une IPv4 publique comme décrit ici. C.f. la config du switch "switcha17b.ipv6.enstb.fr".

La manière de le faire passer (ou non) aux VMs est d'utiliser le filtrage offert par ''ebtables'' (qui est le filtre de niveau 2 des bridges Linux). En effet, le brige ''br0'' de l'hyperviseur est utilisé par les VMs quand elles sont reliées au réseau "bridged". Par défaut, tous les VLAN taggés sont filtrés (c.f. "ebtables -L FORWARD"), mais on peut ajouter une exception pour une machine donnée (en nommant l'interface désirée, et en indiquant le VLAN voulu) :

ebtables -t filter -I FORWARD -o test-vnet0 -p 802_1Q --vlan-id 5 -j ACCEPT
  ebtables -t filter -I FORWARD -i test-vnet0 -p 802_1Q --vlan-id 5 -j ACCEPT
  service ebtables save

La dernière commande sert à sauvegarder les changements pour le prochain reboot.

Stockage¶

C'est depuis l'hyperviseur aussi.

Les VMs sont stockées par défaut dans le partage iSCSI de la DISI. Celui-ci (appelé "iscsi-disi-rsm" comme indiqué dans le rapport d'installation) est partitionné en GPT car très gros, et que la DISI n'offrait pas d'autre moyen de partager l'espace (LUN séparé par exemple). Ça n'est pas idéal s'il était partagé entre plusieurs machines (problèmes de synchronisation), mais c'est pour l'instant la seule à l'utiliser. Dans chaque partition (qui fait 1 To pour le moment), je crée un PV LVM, qui fait partie du VG "iscsi-disi-rsm". C'est dans celui-ci que sont stockées les VMs.

Pour redimensionner un disque, ça n'est pas toujours simple : il y a ''l'extérieur'' de la VM, sur l'hyperviseur, et ce qu'il se passe ''à l'intérieur'' de la VM. Pour l'hyperviseur, généralement un coup de "lvresize" (attention, je parle là ''sur l'hyperviseur'', je n'ai pas testé les fonctions de virsh pour ça) et c'est bon : si le kernel de la VM n'est pas trop vieux, il recevra une notification (par ACPI ? IO-APIC ? PCI-truc ? un truc du genre) et verra le volume plus grand. Pour que la VM puisse utiliser cet espace, je conseille de mettre un second disque qui servira de PV (''dans la VM'') '''sans''' partitionnement, ce qui permettra de faire d'abord un "pvresize" puis un classique "lvresize" ''dans'' la VM.