Différences entre versions de « KVM »

De Cliss XXI
Sauter à la navigation Sauter à la recherche
(→‎Installation : réseau)
Ligne 108 : Ligne 108 :
 
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 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 distincts.  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.
+
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 ==
 
== Liens ==

Version du 5 août 2010 à 12:51

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