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.
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. 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
- 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