Différences entre versions de « KVM »

Version actuelle datée du 27 septembre 2010 à 18:28

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

Réseau

libvirt propose par défaut un réseau interne NATé /etc/libvirt/qemu/networks/default.xml. Cela fonctionne plutôt bien, pour des machines virtuelles qui ne sont pas visibles sur le réseau.

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

Pour raccorder directement les VMs au réseau physique, je n'ai pas trouvé de solution: virt-manager propose de créer un réseau "routé" avec un nouveau pont (bridge), mais sans moyen d'ajouter automatiquement une interface physique au pont, ce qui ne fonctionne donc pas.

La seule solution que j'ai trouvée est de créer à l'avance un pont br0, et de demander à lier chaque machine virtuelle à cette interface physique.

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

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)

Déclaration dans libvirt

Vocabulaire:

create: activation immédiate d'une ressource temporaire
define: définition permanente d'une ressource, à activer dans un second temps

Pour définir le pool LVM, le mieux que j'ai trouvé en ligne de commande est:

pool-define-as VG0 logical localhost - none VG0 /dev/VG0
pool-start VG0
pool-autostart VG0

Installation "à la machine physique"

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

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.

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

TODO: créer une image disque minimale pour GRUB, comme documenté dans la section Partionnement.

apt-get install parted
dd if=/dev/zero of=boot.img count=10 bs=1024k
parted boot.img
...

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.

VIA Nano / Dedibox V3

KVM ne fonctionne pas pour l'instant sur ce CPU, malgré l'annonce de support des instructions VT ("processeur Nano U2250, offrant le support du 64Bits et des instructions VT pour la virtualisation").

On récupère des erreurs en boucle continue de type:

Aug  5 17:06:52 sd-22222 kernel: [185363.334294] handle_exception: unexpected, vectoring info 0x8000000d intr info 0x80000b0d

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
Migrating a vserver container to KVM
Is "Clocksource tsc unstable" kernel msg a problem or not ?
Xen sur doc.cliss21.com
libvirt sur doc.cliss21.com