Xen est un logiciel libre de virtualisation permettant de gérer plusieurs VM sur un même serveur physique.

Avec une installation basique de Debian, vous avez peut-être déjà 3 partitions : la racine /, /home et la swap.

Démontez /home dans ce cas, puis éditer /etc/fstab pour enlever l'entrée lui correspondant. Notez sur quel partition /home était montée (ici, dans l'exemple, c'est sur /dev/sda3).

umount /home
nano /etc/fstab

Activez LVM (qui permet de gérer les partitions puis créez la partition virtuelle avec pvcreate :

service lvm2-monitor enable
service lvm2-monitor restart
pvcreate /dev/sda3

apt install lvm2

Nous allons ensuite utiliser /dev/sda3 pour créer un “groupe de volumes” : toutes nos VM seront contenues là, dans des volumes logiques. Notre système hôte, dans l'exemple, s'appelle groska : nous allons aussi donner ce nom au groupe de volume.

vgcreate groska /dev/sda3

Installer les divers outils dont on va avoir besoin :

apt update
apt install  xen-tools qemu-system-x86 xen-system-amd64
avant buster : xen-linux-system-amd64

Avec Stretch sur online.net, je n'ai pas eu besoin de changer manuellement le noyau

 reboot

Sinon il faut ensuite changer le noyau puis redémarrer, pour utiliser celui de Xen.

dpkg-divert --divert /etc/grub.d/08_linux_xen --rename /etc/grub.d/20_linux_xen
# La ligne ci-dessous ne concerne que les machines chez OVH.
dpkg-divert --divert /etc/grub.d/09_OVHkernel --rename /etc/grub.d/06_OVHkernel
update-grub
reboot

S'il est activé, la commande xl list devrait lister les domaines, d'une façon similaire à celle ci-dessous :

# xl list
Name                                        ID   Mem VCPUs	State	Time(s)
Domain-0                                     0 14779     8     r-----    1881.8

Si ça fonctionne passez au 1.3 .

Si ce n'est pas le cas et que vous obtenez ERROR: Can't find hypervisor information in sysfs! alors on va chercher le bon noyau.

• vérifier dans /etc/grub.d/ qu'il y ait bien 06_linux_xen juste après 05_debian_theme
• vérifier que update-grub a bien été lancé avant de redémarrer.

Si ça ne suffit toujours pas :

grep -Eoe "(menuentry|submenu) '[^']*'" /boot/grub/grub.cfg | nl -v0

Repérez la première entrée menuentry avec “xen” dedans, par exemple :

menuentry 'Debian GNU/Linux, with Linux 3.2.0-4-amd64 and XEN 4.1-amd64'

Pour vérifier que tout va bien, utilisez grub-reboot, qui va tester l'entrée en question au prochain démarrage (et uniquement au prochain démarrage : cela permet de rapidement revenir à quelque chose de fonctionnel en cas d'erreur)

grub-reboot 'Debian GNU/Linux, with Linux 3.2.0-4-amd64 and XEN 4.1-amd64'
reboot

Si xl list donne un résultat, c'était la bonne entrée.

Il faut alors mettre grub à jour en éditant /etc/default/grub. Changez le numéro du menuentry GRUB_DEFAULT=0, sachant qu'on compte à partir de 0 ; Xen est probablement le 3e dans la liste (en général il y a le système de base, puis le système en mode rescue, et ensuite Xen), ce qui donne GRUB_DEFAULT=2.

Ensuite :

update-grub
reboot

grub-reboot '0>0>2'

Vérifiez dans le fichier /etc/default/grub.d/xen.cfg que la variable XEN_OVERRIDE_GRUB_DEFAULT soit à 1, et dans le bloc suivant il doit y avoir la bonne entrée (GRUB_DEFAULT doit correspondre à la bonne entrée) :

if [ "$XEN_OVERRIDE_GRUB_DEFAULT" = "1" ]; then
GRUB_DEFAULT="Debian GNU/Linux, with Xen hypervisor"
fi

Exécutez update-grub, ça devrait être bon maintenant.

Il se peut aussi que l'hyperviseur Xen n'ait pas été configuré pour être le “noyau” démarré par défaut. Pour vérifier cela, on peut lister les différentes possibilités que nous offre grub lors du boot :

awk -F\' '/(menuentry|submenu)\ / {print $2}' /boot/grub/grub.cfg | nl -v0

Remarquez les numéros en début de ligne : c'est le numéro qui nous permettra de dire à grub quel noyau démarrer par défaut. Pour voir lequel est actuellement configuré :

grep -Eoe "(menuentry|submenu) '[^']*'" /boot/grub/grub.cfg | nl -v0

   0	menuentry 'Debian GNU/Linux, with Xen hypervisor'
   1	submenu 'Advanced options for Debian GNU/Linux (with Xen hypervisor)'
   2	submenu 'Xen hypervisor, version 4.8-amd64'
   3	menuentry 'Debian GNU/Linux, with Xen 4.8-amd64 and Linux 4.9.0-7-amd64'
   4	menuentry 'Debian GNU/Linux, with Xen 4.8-amd64 and Linux 4.9.0-7-amd64 (recovery mode)'
   5	menuentry 'Debian GNU/Linux, with Xen 4.8-amd64 and Linux 4.9.0-6-amd64'
   6	menuentry 'Debian GNU/Linux, with Xen 4.8-amd64 and Linux 4.9.0-6-amd64 (recovery mode)'
   7	submenu 'Xen hypervisor, version 4.8-amd64.efi'
   8	menuentry 'Debian GNU/Linux, with Xen 4.8-amd64.efi and Linux 4.9.0-7-amd64'
   9	menuentry 'Debian GNU/Linux, with Xen 4.8-amd64.efi and Linux 4.9.0-7-amd64 (recovery mode)'
  10	menuentry 'Debian GNU/Linux, with Xen 4.8-amd64.efi and Linux 4.9.0-6-amd64'
  11	menuentry 'Debian GNU/Linux, with Xen 4.8-amd64.efi and Linux 4.9.0-6-amd64 (recovery mode)'
  12	menuentry 'Debian GNU/Linux'
  13	submenu 'Advanced options for Debian GNU/Linux'
  14	menuentry 'Debian GNU/Linux, with Linux 4.9.0-7-amd64'
  15	menuentry 'Debian GNU/Linux, with Linux 4.9.0-7-amd64 (recovery mode)'
  16	menuentry 'Debian GNU/Linux, with Linux 4.9.0-6-amd64'
  17	menuentry 'Debian GNU/Linux, with Linux 4.9.0-6-amd64 (recovery mode)'

On peut obliger grub à démarrer un noyau spécifique au prochain redémarrage avec la commande xen-set-default en lui donnant l'entrée à démarrer, soit par son nom, soit par son numéro ; par contre étant donné que c'est un menu avec sous-menus et éventuellement sous-sous-menus, il faut donner à la commande le chemin complet de l'entrée à démarrer, par exemple :

grub-set-default '1>2>3'

Alors c'est comme un chemin, sauf que c'est séparé par des >.

Ou avec le nom exact, selon l'exemple ci-dessus :

grub-set-default 'Advanced options for Debian GNU/Linux (with Xen hypervisor)>Xen hypervisor, version 4.8-amd64>Debian GNU/Linux, with Xen 4.8-amd64 and Linux 4.9.0-7-amd64'

Grub a besoin que la locale par défaut soit anglaise. Suite à un problème de boot on a mis la locale en_US.UTF-8 et re-généré le fichier /boot/grub/grub.cfg avec update-grub.

Le serveur Xen fait aussi office de routeur pour les VM. Les machines virtuelles ont leur propre réseau, elles ont accès au réseau mais ne peuvent être joignables sans ajout de règle sur le pare-feu.

Modifiez /etc/sysctl.conf et décommentez/ajoutez la ligne suivante :

net.ipv4.ip_forward=1

Pour une prise en charge immédiate des modification du fichier /etc/sysctl.conf taper la commande :

sysctl -p /etc/sysctl.conf

Trouvez quelle est votre interface ethernet (probablement quelque chose comme enp1s0, ou eth0) :

ip a

Ensuite, modifiez iptables. Si c'est enp1s0 :

iptables -t nat -A POSTROUTING -o enp1s0 -j MASQUERADE

Sauvegarde des règles :

apt install iptables-persistent
iptables-save > /etc/iptables/rules.v4

Pour exécuter les règles au démarrage du serveur, éditez le fichier /etc/network/interfaces :

auto enp1s0
iface enp1s0 inet static
        address 91.121.136.163
        netmask 255.255.255.0
        network 91.121.136.0
        broadcast 91.121.136.255
        gateway 91.121.136.254
	# Ajoutez la ligne suivante
	post-up iptables-restore /etc/iptables/iptables.rules

On configure Xen pour utiliser le NAT. Dans /etc/xen/xl.conf, ajoutez ou décommentez :

# default vif script to use if none is specified in the guest config
vif.default.script="vif-nat"

On redémarre le service de xen :

systemctl restart xen

Pour vérifier à quoi ressemble le réseau :

ip route ls

Afin de réduire le nombre d'options à taper lors d'utilisation des commande xen.

Nous commencerons par modifier le fichier /etc/xen-tools/xen-tools.conf :

# Paramètres par défaut des VM
###
# Groupe de volumes où le script va créer des volumes logiques 
# (=partitions) nécessaires à la VM,
# dans notre exemple précédent il s’agissait de groska donc :
lvm = groska

# Les tailles sont définie en octet comme suit : G=Giga, M=Mega, k=Kilo
# Taille de la partition root où seront stockées les données
size = 20G 
# RAM allouée à la machine
memory = 1G
# Taille de la partition swap
swap = 1G
# Système de fichiers
fs = ext4
# Distribution installée
# `xt-guess-suite-and-mirror --suite` : même distribution que le Dom0 
dist = `xt-guess-suite-and-mirror --suite`

# Les paramètres réseau
gateway = 192.168.20.254
netmask = 255.255.255.0
broadcast = 192.168.20.255
# Vous pouvez changer le DNS par défaut de vos VM :
# nameserver = 5.9.49.12 

# On lance les VM via pygrub
pygrub = 1

# Exécuter immédiatement après création.
boot = 1

Pour plus d'informations taper man xen-create-image dans un terminal.

Pour rendre vos VM accessibles sans mot de passe, il est possible d'intégrer directement votre clef publique aux nouvelles VM.

Sur le serveur Hôte (Dom0) :

mkdir -p /etc/xen-tools/skel/root/.ssh
chmod -R 700 /etc/xen-tools/skel/root

Depuis votre machine :

cat ~/.ssh/VOTRE_clef_public_ssh #par defaut id_rsa.pub

Copiez le contenu de la commande précédente et tapez dans la console de votre machine Xen :

echo "Coller_Ici_Le_Contenu_de_la_clef" >> /etc/xen-tools/skel/root/.ssh/authorized_keys

Pour créer une VM :

xen-create-image --hostname=myvm --ip=192.168.20.35 --vifname=vif_myvm

• xen-create-image pour créer une image
• –hostname=myvm : remplacez “myvm” par le nom que vous souhaitez donner à votre VM !
• –ip=192.168.20.35 : ce sera l'ip par laquelle on accèdera à nos VM, après être passé par une salade interne ; commencez par “192.168.20.” puis mettez ce que vous voulez, tant que 2 VM ne partagent pas la même.
• –vifname=vif_myvm Permet de choisir le nom de l'interface réseau de la VM côté hôte. Ceci facilite la lecture d'information avec ifconfig et/ou ip add

Si vous souhaitez outrepasser les paramètres par défaut définis dans /etc/xen-tools/xen-tools.conf, les paramètres donnés à la commande xen-create-image sont prioritaires. Par exemple :

xen-create-image --dist=jessie --pygrub --hostname=myvm --size=50G --lvm=groska --ip=192.168.20.35  --mem=1024Mb --netmask=255.255.255.0  

• –dist=jessie pour dire quelle distribution utiliser
• –pygrub : démarre les VM avec un “grub”
• –size=50G : taille que la VM va prendre sur le disque dur
• –lvm=groska : VG (groupe de volumes) sur lequel le script va créer des volumes logiques (=partitions) nécessaires à la VM, ici on l'a défini plus haut et appelé groska. Il va créer un LV (volume logique) myvm-disk pour la VM, et un LV myvm-swap pour le swap.
• –mem=1G : RAM alloué à la VM, comme pour le fichier de config, vous pouvez utiliser le Gb, Mb et le Kb.
• –netmask=255.255.255.0 : masque de sous-réseau

La création de la VM prend un peu de temps. Notez bien le mot de passe qui est donné à la fin.

NB : pour savoir ce qui reste comme espace de libre :

pvscan 

La commande suivante liste les VM lancées :

xl list

Il y a toujours Domain-0 : c'est l'hôte.

Les “states” correspondent à :

• r - running : le domaine fonctionne actuellement.
• b - blocked : le domaine est “bloqué”. Peut-être est-ce juste qu'il attend un truc à faire.
• p - paused : le domaine est en pause (commandé par un admin).
• s - shutdown : la commande “shutdown” a été appelée sur ce domaine (en-train de s'éteindre, quoi).
• c - crashed : ça s'est terminé brutalement.
• d - dying : le système meurt, sans être crashé ni en-train de s'éteindre.

Source : Man xl

Pour démarrer une VM, si elle n'est pas lancée (remplacez myvm par son nom dans les exemples suivants), et s'y connecter (sans le -c, on se contente de la lancer) :

xl create -c /etc/xen/myvm.cfg

Un terminal s'ouvre; pour en sortir proprement (le détacher), le raccourci est ctrl+] (peut-être ctrl+[ sur gnome-terminal; voir la documentation officielle).

Pour rentrer dans une VM lancée, depuis l'hôte :

xl console myvm

Puis retour à la ligne pour entrer dans le terminal (sinon, la commande reste affichée sans rien d'autre)

Pour sortir de la VM, depuis l’hôte :

crlt + ( ou 5

Pour éteindre une VM, depuis l'hôte :

xl shutdown myvm

Forcer violemment une VM à s'éteindre (à éviter) :

xl destroy myvm

xen-delete-image --lvm=groupe_de_volumes vm

• groupe_de_volumes est le nom du VG où est stocké le volume de la VM qu'on va virer
• vm est à remplacer par le nom de la VM.

Par exemple

xen-delete-image --lvm=groska branaz

Va enlever tous les éléments étiquetés branaz (branaz-disk, branaz-swap) dans le groupe de volumes groska.

Nous avons une machine virtuelle fonctionnelle, elle a accès à internet mais personne ne peut y accéder depuis l’extérieur.

Sur l'hôte, il faut donc modifier les règles iptables.

Ouverture de l’accès SSH avec une redirection du port externe 3535 vers le port 22 de la machine virtuelle :

iptables -t nat -I PREROUTING -p tcp --destination-port 3535 -j DNAT --to 192.168.20.35:22 

Cette manipulation est à refaire pour chaque VM directement accessible via SSH; ici, on pourra accéder à la VM via la commande ssh user@mon.ip -p 3535.

Une des VM va servir de reverse proxy aux autres. Sur cette VM, on va configurer Apache, ou Haproxy, ou autre, afin de rediriger le trafic web vers les bonnes VM.

Si on a configuré myvm comme VM de reverse proxy (accès via “http” et “https”), ajouter les règles suivantes depuis l'hyperviseur :

iptables -A FORWARD -d 192.168.20.35 -p tcp --sport 80 --dport 80 -j ACCEPT
iptables -A FORWARD -d 192.168.20.35 -p udp --sport 80 --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.168.20.35:80
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 80 -j DNAT --to-destination 192.168.20.35:80
iptables -A FORWARD -d 192.168.20.35 -p tcp --sport 443 --dport 443 -j ACCEPT
iptables -A FORWARD -d 192.168.20.35 -p udp --sport 443 --dport 443 -j ACCEPT
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination 192.168.20.35:443
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 443 -j DNAT --to-destination 192.168.20.35:443

Le port 443 pour https, 80 pour le http.

Penser à sauvegarder les règles pour le redémarrage !

iptables-save > /etc/iptables/rules.v4

Pensez aussi, si ce n'est pas déjà fait, à bien configurer fail2ban sur l'hyperviseur.

#!/bin/bash
 
#acepter les connexions ssh
iptables -t nat -I PREROUTING -i eno1 -p tcp --destination-port ssh -j ACCEPT
 
#rediriger tous les ports sur une VM proxy
iptables -t nat -A PREROUTING -i eno1 -j DNAT --to-destination 192.168.**.10
 
#ouvrir un port ssh pour chaque VM 
iptables -t nat -I PREROUTING -p tcp --destination-port 3510 -j DNAT --to 192.168.**.10:22
iptables -t nat -I PREROUTING -p tcp --destination-port 3511 -j DNAT --to 192.168.**.11:22
iptables -t nat -I PREROUTING -p tcp --destination-port 3512 -j DNAT --to 192.168.**.12:22
iptables -t nat -I PREROUTING -p tcp --destination-port 3513 -j DNAT --to 192.168.**.13:22
iptables -t nat -I PREROUTING -p tcp --destination-port 3514 -j DNAT --to 192.168.**.14:22
 
#exemple pour diriger un port sur une VM
iptables -t nat -I PREROUTING -i eno1 -p tcp --destination-port **** -j DNAT --to 192.168.**.**:****
 
 
#exemple pour prosody
iptables -t nat -I PREROUTING -i eno1 -p tcp --destination-port 5222 -j DNAT --to 192.168.**.13:5222
iptables -t nat -I PREROUTING -i eno1 -p tcp --destination-port 5269 -j DNAT --to 192.168.**.13:5269
iptables -t nat -I PREROUTING -i eno1 -p tcp --destination-port 5280 -j DNAT --to 192.168.**.13:5280
iptables -t nat -I PREROUTING -i eno1 -p tcp --destination-port 5281 -j DNAT --to 192.168.**.13:5281

Ouais, bon, ça arrive. Si on a accès à l'hôte (Dom), tout va bien.

Commencer par repérer sur quel disque la VM se monte :

nano /etc/xen/myvm.conf

Chercher quelque-chose comme disk = [“phy:/dev/domus/myvm_disk,sda1,w”]

Monter le disque, y accéder en chroot, remettre le mot de passe à zéro :

mount -o loop /dev/domus/myvm_disk /mnt
chroot /mnt
mount -o remount,rw /
passwd
mount -o remount,ro /
exit

Démonter le disque et relancer la VM :

umount /mnt
xl create /etc/xen/myvm.conf

Il s'agit de manipulations propres à LVM¹⁾, c'est donc dans la documentation sur LVM, ici.

Mettre à jour la distribution puis :

apt autoremove

Changer dans /etc/xen/maVM.conf

bootloader = '/usr/lib/xen-4.11/bin/pygrub' 

Vérifier que /etc/sysctl.conf

net.ipv4.ip_forward = 1

Dans /etc/xen/scripts/vif-nat (à la fin)

echo handle_iptable

Il y en a quelques uns déjà listé sur cette page, mais consultez aussi la page de LVM, car les deux logiciels sont très liés…

Si lors du lancement d'un VM, vous avez ceci en erreur :

# xl create /etc/xen/etherpad2.cfg
Parsing config from /etc/xen/etherpad2.cfg
libxl: error: libxl_device.c:381:libxl__device_disk_set_backend: Disk vdev=xvda2 failed to stat: /dev/nuxru/etherpad2-disk: No such file or directory
libxl: error: libxl_create.c:946:initiate_domain_create: Unable to set disk defaults for disk 0
libxl: error: libxl.c:1575:libxl__destroy_domid: non-existant domain 2
libxl: error: libxl.c:1534:domain_destroy_callback: unable to destroy guest with domid 2
libxl: error: libxl.c:1463:domain_destroy_cb: destruction of domain 2 failed

Allez voir LVS liste des disques qui ont disparus.

Les VM peuvent avoir une heure aberrante par rapport à Dom0. Ce qui est lié à la timezone mal déclarée.

Ça se règle en exécutant en root

dpkg-reconfigure tzdata

Une liste de choix permet alors de cibler le bon fuseau.

• https://wiki.xen.org/wiki/Xen_Man_Pages
• man de xl