Comme XEN ne fonctionnait pas très bien pendant un temps sur ma distribution Debian (unstable), celle que je préfère pour tous les autres usages, (au minimum pas de X possible) j'ai décidé de tester une autre solution de virtualisation : KVM. 
A l'occasion de tests sur SHINKEN j'ai récupéré une image de machine VMWARE facile à convertir en image QCOW2 utilisable par KVM. 
Mais avant de lancer sa première machine KVM il faut préparer la machine (Kernel), installer quelques softs et modifier ses interfaces réseau (des "ponts" sont nécessaires). 
Dans le premier article je vais détailler les pré-requis à KVM. 
Remarque 2015/2016 : 
La plupart des distributions intègrent aujourd'hui KVM dans leur noyaux, on n'est donc pas obligé de passer par la case "compilation du noyau", par contre il vaut mieux créer un "bridge" (ou plusieurs) au niveau réseau sur la machine hôte afin d'être très libre sur la configuration réseau des MV, ceci est précisé dans l'article sur les pré-requis. 
Il faut bien-sûr installer les paquets "qemu/qemu-kvm" et "bridge-utils" dans votre système. 
J'utilise KVM couramment sur les "petites" machines (Core I3) pour installer des "services", ou groupes de services, différents avec des environnements logiciels différents (Debian, Ubuntu LTS, Centos ...). La MV sur laquelle est installée ce site Web est une machine virtuelle KVM installée dans un "petit" système: 
CPU        : CoreI3 4130 
Carte mère : MSI MS-7851/B85I 
RAM        : 16Go 
Disques    : Système sur SSD 
           : disques des machines KVM sur deux SSD en miroir. 
Cette machine "abrite" aussi un service mail (Zimbra) et un outil de supervision (Shinken + Omeganoc). 
Remarque août 2016 : cette machine a été remplacée par une carte mère Asus et un coreI5 5665C dans un mini boîtier Lian Li.. Le contenu est resté le même mais tous les services sont hébergés dans des machines virtuelles KVM.. La supervision (Shinken + Thruk + Omeganoc), Zimbra et le serveur Web hébergeant ce site ont été installés dans des machines viruelles KVM logées dans ce seul serveur physique. 

Note 2022 : La machine hébergeant les principales VM a été changée, c'est maintenant un processeur "AMD Ryzen 5 3600 6-Core" avec 32Go de RAM et le suivi des performances est assuré par une MV prometheus avec des "clients" installés dans toutes les machines.
 

La partie réseau a été préparée sur la machine "hôte" par la création du "bridge" dans l'article précédent, il ne nous reste plus qu'à "activer" un interface qui permettra à notre Machine Virtuelle de communiquer avec l'extérieur. 
Il nous faut réaliser les opérations suivantes :

• Créer un interface "tapN" (N de 0 à 999) à l'aide de "tunctl" et l'affecter à notre user.
• Activer cet interface
• L'ajouter à notre bridge "br0" (là aussi nom consacré)

Ces opérations sont enchaînées par le petit script suivant qui demande deux paramètres :

• Le numéro de switch (br0 ... n)
• Le nom de l'interface (tap0 ... n)

Résultat, après avoir lancé le script avec en paramètres : br0 tap0  , on vérifie :

Notre interface réseau semble fin prête. 
Pour le stopper il suffit de lancer le petit script suivant avec les mêmes paramètre "br0 tap0" pour effacer notre interface virtuel et tout remettre "à blanc" :

Attention si vous voulez lancer deux MV ou plus, il faudra utiliser "tap1, tap2 ..." et pas deux fois le même ! Sinon vous vous ferez "tap"er sur les doigts !

Pour les tests de shinken 0.4 j'ai récupéré une image au format VMWARE et, au lieu de la transformer en image XEN j'ai voulu tester au passage la virtualisation avec KVM. 

Première opération : compiler KVM dans le noyau Linux (ici le kernel 2.6.37.rc8), et ça marche encore pour les noyaux 3.X et 4.X.  Cette première partie n'est pas nécessaire avec des kernels récents.
Lancer le "make menuconfig" : 
┌────────────────────────────────────────────────────────────────────────┐ │   
│ │              General setup  --->                                     │ │   
│ │          [*] Enable loadable module support  --->                    │ │   
│ │          -*- Enable the block layer  --->                            │ │   
│ │              Processor type and features  --->                       │ │   
│ │              Power management and ACPI options  --->                 │ │   
│ │              Bus options (PCI etc.)  --->                            │ │   
│ │              Executable file formats / Emulations  --->              │ │   
│ │          [*] Networking support  --->                                │ │   
│ │              Device Drivers  --->                                    │ │   
│ │              Firmware Drivers  --->                                  │ │   
│ │              File systems  --->                                      │ │   
│ │              Kernel hacking  --->                                    │ │   
│ │              Security options  --->                                  │ │   
│ │          -*- Cryptographic API  --->                                 │ │   
│ │          [*] Virtualization  --->                                    │ │   
│ │              Library routines  --->                                  │ │   
│ └──────────v(+)────────────────────────────────────────────────────────┘ │    

Cocher la case "Virtualization" et aller dans le détail et sélectionner le type de processeur (ici c'est AMD) : ┌────────────────────────────────────────────────────────────────────────┐ │   
│ │          --- Virtualization                                          │ │   
│ │          <M>   Kernel-based Virtual Machine (KVM) support            │ │   
│ │          <M>     KVM for Intel processors support                    │ │    
│ │          < >     KVM for AMD processors support                      │ │    
│ │          <M>   Host kernel accelerator for virtio net (EXPERIMENTAL) │ │    
│ │          <M>   PCI driver for virtio devices (EXPERIMENTAL)          │ │    
│ │          <M>   Virtio balloon driver (EXPERIMENTAL)                  │ │    
│ │                                                                      | |    
| ├──────────────────────────────────────────────────────────────────────┤ | 

Cocher les cases correspondant à votre type de processeur (AMD/INTEL), et les trois dernières aussi. Puis compilation, installation, reboot et c'est OK ! 
Il faut ensuite installer :

• qemu-kvm
• uml_utilities
• bridge-utils

Pour pouvoir lancer des machines virtuelles et leur fournir un accès au réseau. 
apt-get pour moi, yum pour d'autres ... 

Deuxième opération : création d'un "bridge". 
Le bridge peut être installé en permanence, le réseau fonctionne très bien pour la machine principale si un bridge est déclaré. Sur un système Debian il faut modifier le fichier "/etc/network/interfaces" comme suit : 
Avant : 
auto eth0 
iface eth0 inet static 
    address    192.168.1.XXX 
    netmask    255.255.255.0 
    network    192.168.1.0 
    gateway    192.168.1.xxx 
    broadcast  192.168.1.255 
Après : 
auto br0 
iface br0 inet static 
      address   192.168.1.XXX 
      netmask   255.255.255.0 
      network   192.168.1.0 
      broadcast 192.168.1.255 
      gateway   192.168.1.xxx 
      bridge_ports eth0 
      bridge_maxwait    1 

Ensuite rebooter la machine pour vérifier si tout est OK, et tester : 
sudo ifconfig br0 
br0       Link encap:Ethernet  HWaddr 00:1b:2f:bf:11:c7  
          inet addr:192.168.1.XXX  Bcast:192.168.1.255  Mask:255.255.255.0 
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1 
          RX packets:53550 errors:0 dropped:0 overruns:0 frame:0 
          TX packets:85015 errors:0 dropped:0 overruns:0 carrier:0 
          collisions:0 txqueuelen:0 
          RX bytes:54066193 (51.5 MiB)  TX bytes:17172164 (16.3 MiB) 

Tout est alors prêt sur le système hôte pour lancer notre première machine virtuelle KVM ... dès que la partie réseau sera au point coté KVM.

Tout étant prêt au niveau "hard" nous allons pouvoir lancer notre première machine. Comme je l'ai expliqué au début de cet article j'ai récupéré une image de disque VMWARE que j'ai convertie en image adaptée à KVM (format QCOW2) par la commande miracle : 
qemu-img convert shinken-vm-0.4.vmdk -O qcow2 shinken-vm-0.4.kvm 
Il s'agit donc d'une "machine pré-fabriquée" où tout est déjà installé, un prochain article détaillera la construction d'une nouvelle machine. 
Une fois le disque disponible on va s'occuper des paramètres nécessaires à KVM :

• Un disque on peut installer de "-hda" à "-hdd" et "-cdrom"
• De la RAM (-m ...M)
• Un nom ( -name ....)
• Un clavier français !
• Le lancement en "démon" ou pas (-daemonize)
• Une carte réseau avec son adresse MAC, couplée à notre tap0
• Le fonctionnement du disque en normal ou "snapshot" qui empêche toute modification du disque utilisé (ça peut servir !).

Lancez l'interface "tap0" avant de lancer la MV. Le script suivant pourra vous permettre de démarrer comme moi une machine minimum avec un seul disque, mais un clavier français et le réseau :

Note 2024 : KVM et QEMU étant maintenant liés on lance "qemu" en lieu et place de "kvm".

Et cela doit démarrer sans aucun problème, Ah, j'ai failli oublier, pour "sortir" de l'écran de votre machine KVM : Ctrl+Alt (à garder appuyé), puis aller cliquer sur la barre d'une autre fenêtre. Soyez patients, quelque fois cela "foire" un peu et il faut "titiller" légèrement la souris ! 
Il vous faudra reconfigurer la carte réseau de votre nouveau système afin que la carte fournie (Adresse MAC) soit reconnue au boot. Un petit tour dans "/etc/udev/rules.d" est très instructif. Supprimer les "cochonneries" dans le fichier "70-persistent-net.rules" (sur une distribution Debian, mais les autres n'ont pas l'air très différentes de ce coté) et modifier la ligne "eth0" en y indiquant votre "adresse MAC".

Attention tout est sur une seule ligne ! 

Un autre petit tour dans /etc/network/interfaces pour vérifier que eth0 (ou autre interface "ens...") est bien en DHCP, si vous n'avez pas de serveur DHCP utilisez une adresse fixe : 
# The primary network interface 
allow-hotplug eth0 
iface eth0 inet dhcp 

Et pour moi c'est OK, si vous n'avez pas de DHCP : 
allow-hotplug eth0 
iface eth0 inet static 
    address   192.168.1.AAA 
    netmask   255.255.255.0 
    network   192.168.1.0 
    gateway   192.168.1.XXX 
    broadcast 192.168.1.255 

Un petit coup de "ifdown eth0" suivi d'un "ifup eth0" devrait activer votre réseau et vous montrer que la liaison est OK :

Ca marche vraiment ! 

KVM mais c'est très simple !

Pour installer une nouvelle machine virtuelle KVM il faut, comme pour une machine physique disposer de :

1. un disque (au moins)
2. une carte mère et ses accessoires (vidéo, réseau, clavier ....)
3. un boîtier
4. de la RAM
5. un processeur
6. une source d'installation, en général CD ou DVD

Les seuls éléments non virtuels dont nous allons avoir besoin sont :

1. un disque, ou un morceau de disque (vive LVM)
2. une source d'installation.

Tout le reste est fourni par KVM/QEMU.

Le disque. 
Le "disque" attribué à notre nouvelle machine peut être :

• Un fichier (à initialiser en format QCOW2 de préférence)
• Une partition sur un disque (partition physique ou LVM)

Dans mon cas j'ai tendance à utiliser des partitions créées "à la demande" grâce à LVM, je dispose (encore) de place pour caser quelques partitions de test. J'ai donc réservé 10Go d'espace sur un volume. 

La source d'installation. 
Il s'agit ici d'une image ISO de l'installation de Debian Squeeze, même pas besoin de la graver et d'ouvrir le lecteur. 

Script d'installation. 
J'aime bien les scripts car on peut répéter les opérations tant que l'on veut en frappant juste sur quelques touches au lieu de cliqueter comme un fou dans un bel interface graphique, on finit par ne plus savoir sur quoi on a cliqué .... Bon, le script :

On retrouve la plupart des éléments du script "standard" avec une variante pour le premier boot sur l'image du CD d'installation. On retrouve en "HDA" le nom de la partition LVM présentée par le device mapper, en "CDROM" mon image ISO. 
Après le lancement du script on se trouve en face d'une installation absolument "standard", la virtualisation est parfaite. Je n'ai eu qu'un seul problème car j'ai d'abord voulu installer sur une partition "ROOT" en EXT4 et l'installation s'est plantée au cours de l'installation du système de base, je n'ai pas insisté et suis revenu au bon vieil EXT3. 
Note 2016 : EXT4 fonctionne maintenant fort bien ! 
J'ai utilisé, par précaution, l'installation en mode texte mais j'ai l'impression que l'installation doit être possible en mode graphique. 
Note 2017: Le mode graphique, plus beau, fonctionne très bien. 
L'ensemble de l'installation s'est déroulé à une vitesse quasiment normale, y compris le chargement des nouveautés depuis le site Debian. J'ai ensuite résisté à la tentation de rebooter avant de modifier le script pour le ramener au mode "normal" sans CD. 
Après ce reboot le démarrage en mode graphique est parfait et j'accède à un écran X en mode 800x600 dont la souris n'est pas asthmatique et obéit aux sollicitations. On peut même réduire l'écran à une toute petite taille, il reste lisible car tout est réduit en proportion. Tiens cela va me permettre de mettre une image dans le style timbre-poste.
Note 2024 : j'utilise toujours ce modèle de script pour toutes les VM KVM/QEMU.

C'est-y pas beau ? Et en plus on peut travailler à l'aise dans la machine virtuelle, les temps de réponse sont excellents. Le boot : moins de 18 secondes entre le lancement de la commande et l'accès à l'écran de login !

J'ai eu besoin pour tester des scripts de construire rapidement une machine supportant une version 10.x de Oracle. 
J'ai choisi d'utiliser KVM "pour voir" avec une installation "basique" d'une Debian 32 bits. 
L'installation ne comporte aucun élément graphique, juste le système de base + un serveur SSH. 
Ce système s'installe très rapidement. Pendant ce temps le téléchargement de la version Oracle "XE" a le temps de s'effectuer. Oracle ayant le bon goût de proposer un package Debian l'installation sera rapide. 
Le seul pré-requis est l'installation de libaio1 : 
apt-get install libaio1 
qui installe très rapidement (moins de 100K) la version libaio1    (0.3.107-3) 
Une fois le téléchargement du paquet "oracle-xe-universal_10.2.0.1-1.0_i386.deb" il suffit de le transférer dans la machine. 
Mon disque système étant assez petit (#4Go) j'ai prévu un disque "DATA" de 8Go pour y installer Oracle. La seule "astuce" est de monter ce disque dans "/usr/lib/oracle" que l'on aura créé auparavant. 
Ensuite :

Ne pas oublier ensuite de lancer (en "root") : /etc/init.d/oracle-xe configure 

Ma machine ne comporte pas d'interface graphique, il m'est impossible d'accéder à l'interface Web fourni (APEX), il ne me reste qu'à effectuer la mise à jour adéquate à l'aide de "sqlplus system/le_mot_de_passe" 
en lançant la commande : 

EXEC DBMS_XDB.SETLISTENERLOCALACCESS(FALSE); 

et miracle ! Le service Web est alors accessible depuis l'extérieur de la machine.

Ce petit interface est assez sympa, et bien que simple, permet de gérer convenablement une base limitée à 5Go. 
L'essayer c'est l'adopter.

Les machines virtuelles (ici KVM/QEMU), c'est bien mais il faut aussi les sauvegarder.

J'assure le backup des disques de mes machines virtuelles à l'aide de dd + bzip2 et j'ai constaté que la taille du backup résultant ne fait que croître au cours du temps ... 
Exemple : sur une machine munie d'un disque de 32Gb le backup consommait à l'origine environ 5Gb, après quelques mois de fonctionnement la taille du backup atteint 13 Gb. 
Or le système n'a que peu été modifié et a "subi" principalement les mises à jour de l'OS et l'activité normale d'une machine : écrire des logs, utiliser une base de données, faire tourner les logs (logrotate) fournir un service Web (3000/5000 pages par jour).

Le filesystem "root" n'est rempli qu'à 24% mais doit finir par être désorganisé et surtout plein de secteurs qui ont été utilisés et qui ne le sont plus mais comportent des données "aléatoires" peu compressibles. Une sauvegarde par un simple "tar" serait presque moins volumineuse ! 
C'est alors que "zerofree" intervient, il permet de forcer des zéros dans toutes les zones inutilisées du filesystem ce qui les rend beaucoup plus apte à la compression. 
La procédure que j'ai utilisée nécessite l'arrêt de la machine virtuelle car "zerofree" ne peut pas écrire sur un FS monté en lecture/écriture. 
Par commodité j'ai effectué les opérations comme suit :

• stopper la VM
• attacher le disque à une VM "de travail"
• monter le disque en lecture seule sur la VM de travail, par exemple sur /mnt 
  mount /dev/xxx1    /mnt -o ro
• lancer "zerofree" 
  zerofree -n /dev/xxx1
• démonter le disque 
  umount /mnt
• stopper la VM de travail
• relancer la VM originale 

On peut intercaler la sauvegarde proprement dite avant de relancer la VM originale. L'opération de "zéroification" est relativement rapide et donne de bons résultats sur les sauvegardes  (Ci dessous pour une partition de #30Gb) :

Résultats : 
Avant "zéro-ification"

Après "zéro-ification" :

Le gain d'espace est d'environ 9Gio (-66%), celui de temps est très appréciable lui aussi #25 minutes contre un peu plus d'une heure (-60%).

C'est dons une opération à renouveler régulièrement et qui ne dure pas très longtemps :

La seule chose dont il faut disposer est d'une machine virtuelle avec son propre disque système sur laquelle on peut "attacher" le disque à "zéroifier". 
Et un peu de temps #1Gio = 12s, #30Gio un peu plus de 5 minutes, ce qui est "rentable" à coté des 35 minutes gagnées sur la sauvegarde.

Note 2024 : je "passe" encore ce genre d'économiseur de temps en temps.

Pour utiliser KVM comme j'en avais envie il fallait que ces machines puissent démarrer lors de la séquence de boot de la machine hôte. Or, a priori, le lancement demande un écran ! Heureusement l'option  --nographic est là. 
Cette machine virtuelle est destinée à contenir la MV qui héberge ce site, vu qu'il y a peu de machines et services à surveiller une puissance importante n'est pas nécessaire. 

L'ajout de la notion "GUEST" permet d'initier une commande liant la MV à la machine physique par l'intermédiaire d'un socket et cela permet de déclencher le shutdown de l'extérieur en utilisant le script suivant :

#!/bin/bash
SOCK=/tmp/monitor_$1
echo system_powerdown | socat - UNIX-CONNECT:${SOCK}

Cette commande s'exécute fort bien depuis un script "systemd" ...

Le script de lancement devient alors :

#!/bin/bash 
PATH=/root/bin:$PATH 
ORIG=$(dirname $0) 
cd ${ORIG} 
ORIG=$(pwd) 
echo 'ORIG=('$ORIG')' 
cd $ORIG

HDA=/dev/mapper/VG00-WEB_PHP7 
DISKA=' -drive file='${HDA}',if=virtio,format=raw,cache=none,aio=native  '

HDB=/dev/mapper/VG01-WEB_PHP7_SAUVE 
DISKB=' -drive file='${HDB}',if=virtio,format=raw,cache=none,aio=native  '

EXEC='qemu-system-x86_64 -enable-kvm -machine type=pc,accel=kvm:tcg -mem-path /dev/hugepages ' 
EXEC=${EXEC}' --mem-prealloc'

NOM=web-php7 
RAM=1792M 

OPTION=' ' 
# clavier FR 
OPTION=' -k fr -smp 2'    
# Pas de daemon (car nographic )
DEMON=' -daemonize ' 
DEMON=' ' 
# Appel des scripts de gestion de la "carte réseau" ces scripts sont présentés un peu plus loin 
sudo ./bin/qemu-ifdown br1 tap10 
sleep 1 
sync 
sudo ./bin/qemu-ifup br1 tap10 
sudo /sbin/brctl show

# Creation port "Monitor" pour arrêt machine 
GUEST=' -monitor unix:/tmp/monitor_web,server,nowait '

RESEAU=' -net nic,macaddr=00:16:3e:31:31:01 -net tap,ifname=tap10,script=no,downscript=no '

# Normal launch 
COMMANDE="$EXEC $DEMON $SNAPSHOT -boot c $DISKA $DISKB -name $NOM -m $RAM $OPTION $RESEAU ${GUEST} " 
# machine affectée sur les "processeurs" 10 et 11, la "belle" machine physique en a 12 
taskset --cpu-list 10,11 ${COMMANDE} -nographic & 
ret=$? 
echo 'Retour:'${ret}

Ce script peut être lancé par systemd ...

Et ... le tour est joué.