KVM

Encore une technique de virtualisation. Elle s'appuie sur une fonctionalité processeur (nom de code VMS chez AMD, VT-X chez Intel). Les tests montre un niveau similaire mais pas nécessairement plus rapide que la para-virtualisation (Xen classique).

Installation

On installe libvirt et quelques paquets recommandés:

# KVM
apt-get install qemu-kvm  # previously 'kvm'
# libvirt
# - libvirt-bin: base utilities
# - dbus: necessary to run libvirtd
# - bridge-utils: network connection sharing
# - lvm2: we use LVM-based block devices for VMs
# netcat-openbsd: necessary to support 'nc -U', used by qemu+ssh://root@remote/system URIs, itself used by virt-manager
apt-get install libvirt-bin -t lenny-backports
apt-get install dbus bridge-utils lvm2 netcat-openbsd
# Other recommends: dnsmasq-base (used by virt-manager to create new networks, unused if using a bridged setup), libxml2-utils

Il n'est pas possible de déclarer réseau bridge existant réutilisable par toutes les VMs (libvirt veut créer lui-même le périphérique bridge). Si besoin il faudra modifier chaque configuration de VM en ajoutant ceci dans le bloc <devices> [1] (virt-install le fait directement, mais il faut le modifier à la main si on utilise virt-manager):

<interface type='bridge'>
  <source bridge='br0'/>
  ...
</interface>

EDIT: on peut faire référence à /etc/libvirt/qemu/networks/default.xml avec:

<interface type='network'>
  <source network='default'/>
  ...
</interface>

lui-même contenant:

<network>
  <name>default</name>
  <bridge name="virbr0" />
  <forward/>
  <ip address="192.168.122.1" netmask="255.255.255.0">
    <dhcp>
      <range start="192.168.122.2" end="192.168.122.254" />
    </dhcp>
  </ip>
</network>

On doit créer l'image à la main: soit avec un CD d'installation, soit avec debootstrap (pas de vserver build ou de xen-create-image).

Installation "à la machine physique"

L'installation peut se faire via virt-manager ou virt-install, à partir d'un installateur classique (image ISO, lecteur CD-ROm, PXE, etc.).

Pour virt-manager, suivre l'interface graphique. Je n'ai pas réussi à amorcer depuis le réseau (PXE), QEMU dit qu'il n'y a aucun périphérique bootable.

Pour virt-install:

wget http://cdimage.debian.org/debian-cd/5.0.5/amd64/iso-cd/debian-505-amd64-businesscard.iso
kvm -m 256 -cdrom debian-505-amd64-businesscard.iso -boot d /dev/VG0/test1-disk -vnc :0 -k fr
# ou
virt-install -n test1 -r 2048 --disk path=/dev/VG0/test1-disk --cdrom debian-505-amd64-businesscard.iso --network bridge:br0 \
  --accelerate --vnc

Suivre ensuite l'installation via VNC.

Partitionnement

En l'absence d'outil de (re)composition de disque ou de pygrub (à la xen), l'installation de GRUB pour amorcer sur une partition ext3 nécessite une image disque complète plutôt qu'une image de partition simple.

(Il est apparemment possible d'installer GRUB Stage 1.5 dans la "boot loader area" d'une partition ReiserFS - je n'ai pas essayé mais je cherche ici une solution générique qui fonctionne avec tout type de partition)

Une idée est de créer pour chaque VM:

* une petite image disque contenant un MBR, son premier cylindre pour l'installation de GRUB Stage 1.5, et une petite partition /boot
* une image disque par partition, montée directement sur l'identifiant disque (ex: / monté sur /dev/sdb, /home monté sur /dev/sdc, etc.)

Ce qui permet d'accéder directement aux partitions depuis le système hôte.

Autre solution encore est d'utiliser des fichiers noyaux stockés sur l'hôte, mais ce n'est pas pratique (génération des initrd potentiellement incorrecte, difficulté du suivi de sécurité des noyaux d'autres distributions ou versions de la distribution...).

Accès aux partitions d'une image disque

Pour la gestion d'images disques complètes contenant plusieurs partitions (dans le cas où on a pas réalisé le partitionnement nous-même comme ci-dessus), on pourra regarder de plus près:

• kpartx: pour faire apparaître, dans le /dev/mapper de l'hôte, les partitions de l'image disque - et pouvoir les monter
• parted: pour redimensionner une partition dans l'image disque
• libguesfs: pour d'autres opérations sur les partitions, y compris un guestmount à base de fuse (non-root)

Installation automatique

Il s'agit de lancer debootstrap dans un nouveau volume LVM:

apt-get install debootstrap
lvcreate -n test1-disk -L2G VG0
mkfs.ext3 /dev/VG0/test1-disk
mkdir test1-disk
mount /dev/VG0/test1-disk /mnt/test1-disk
debootstrap --arch=i386 lenny /mnt/test1-disk http://ftp.fr.debian.org/debian
# TODO: post-install, cf. autostrap
umount /mnt/test1-disk

Alternativement on pourra utiliser des outils existants (cf. Xen et VServer):

# Xen (xen-tools)
xen-create-image --hostname test1 --kernel /boot/vmlinuz-2.6.26-2-xen-686 \
 --initrd /boot/initrd.img-2.6.26-2-xen-686 \
 --dist lenny --mirror http://monmiroir:9999/debian/ \
 --dhcp  --lvm VG0 --size 4G \
 --role udev
# VServer (partie debootstrap uniquement)
vserver monvserver build -m debootstrap -- -d lenny -m http://mirror/debian

Créer ensuite une configuration XML. Une solution est de convertir les paramètres que l'on aurait passé à QEMU:

# - création de la config XML
echo "/usr/bin/kvm -m 1024 -hda /dev/VG0/test1-disk -nographic -vnc autoport -k fr" \
  "-kernel /boot/vmlinuz-2.6.32-bpo.5-amd64 -initrd /boot/initrd.img-2.6.32-bpo.5-amd64" \
  "-append root=/dev/sda" > t
virsh domxml-from-native qemu-argv t > test1.xml
# Change to arch='x86_64' in <type> if necessary
# Add keymap='fr' in <vnc> if necessary
# TODO: network

virsh create test1.xml

Accès console

Dans le fichier /etc/inittab de l'invité, remplacer ou ajouter un processus de login sur le port série:

0:2345:respawn:/sbin/getty 115200 ttyS0

On peut ensuite accéder en mode texte à la machine (typiquement pour réparer un serveur SSH récalcitrant ou bénéfier du copier/coller):

virsh console test1

Comparaison avec Xen

Le principal avantage est de s'appuyer sur un noyau Linux classique: le démarrage du système hôte se fait comment d'habitude, pas de bricolage nécessaire au niveau des options du port série, etc.

Le principal inconvénient est la nécessité d'utiliser des images disques complètes, contrairement à Xen qui peut assembler un disque virtuel à partir de fichiers de partitions distinctes, et de charger un noyau depuis sa partition d'installation avec pygrub. Les opérations de redimensionnement de partitions nécessitent également une reconfiguration de la table de partitionnement avec éventuellement déplacement des données, ce qui souvent ne peut se faire sans passer par un LiveCD GParted. Une solution est d'utiliser systématiquement une seule partition par disque virtuel, quitte à ajouter plusieurs disques virtuels. Il y a également des gens qui font du LVM sur LVM, mais restons sérieux.

Liens

• Wiki officiel: c'est la documentation à lire - ne pas regarder l'onglet "Documentation" sur libvirt.org, qui n'est pas prévue pour l'utilisateur final
  • Configuration bridge
• Xen to KVM disk image migration: construire une image automatiquement avec notamment debootstrap
• Resize ext3 in LVM in partition in (KVM/QEMU) virtual image file: contraignant si on utilise des images disque plutôt que des partitions
• Xen sur doc.cliss21.com