Différences entre versions de « KVM »
(→Réseau : explicite quand ça fonctionne) |
|||
| (16 versions intermédiaires par 2 utilisateurs non affichées) | |||
| Ligne 16 : | Ligne 16 : | ||
# Other recommends: dnsmasq-base (used by virt-manager to create new networks, unused if using a bridged setup), libxml2-utils | # 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é <code>/etc/libvirt/qemu/networks/default.xml</code>. 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'> | <interface type='bridge'> | ||
<source bridge='br0'/> | <source bridge='br0'/> | ||
| + | ... | ||
</interface> | </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) | |
| − | L'installation peut se | + | 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 <code>/boot</code> | ||
| + | * une image disque par partition, montée directement sur l'identifiant disque (ex: <code>/</code> monté sur <code>/dev/sdb</code>, <code>/home</code> monté sur <code>/dev/sdc</code>, 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: | ||
| + | * <code>kpartx</code>: pour faire apparaître, dans le <code>/dev/mapper</code> de l'hôte, les partitions de l'image disque - et pouvoir les monter | ||
| + | * <code>parted</code>: pour redimensionner une partition dans l'image disque | ||
| + | * [http://libguestfs.org/ libguesfs]: pour d'autres opérations sur les partitions, y compris un <code>guestmount</code> à 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-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. | ||
| Ligne 77 : | Ligne 117 : | ||
virsh create test1.xml | 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 === | === Accès console === | ||
| Ligne 89 : | Ligne 136 : | ||
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 | + | 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"). | ||
| + | |||
| + | * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570244 | ||
| + | * http://linuxfr.org/~fredix/29788.html | ||
| + | |||
| + | 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 == | == Liens == | ||
| Ligne 97 : | Ligne 155 : | ||
* [http://autonomic.ac.upc.edu/emotive/?p=162 Xen to KVM disk image migration]: construire une image automatiquement avec notamment debootstrap | * [http://autonomic.ac.upc.edu/emotive/?p=162 Xen to KVM disk image migration]: construire une image automatiquement avec notamment debootstrap | ||
* [http://www.pither.com/articles/2009/10/09/resize-ext3-in-lvm-in-partition-in-kvm-qemu-virtual-image-file Resize ext3 in LVM in partition in (KVM/QEMU) virtual image file]: contraignant si on utilise des images disque plutôt que des partitions | * [http://www.pither.com/articles/2009/10/09/resize-ext3-in-lvm-in-partition-in-kvm-qemu-virtual-image-file Resize ext3 in LVM in partition in (KVM/QEMU) virtual image file]: contraignant si on utilise des images disque plutôt que des partitions | ||
| + | * [http://www.debian-administration.org/users/johns/weblog/3 Migrating a vserver container to KVM] | ||
| + | * [http://kerneltrap.org/node/8306 Is "Clocksource tsc unstable" kernel msg a problem or not ?] | ||
| + | * [[Xen]] sur doc.cliss21.com | ||
| + | * [[libvirt]] sur doc.cliss21.com | ||
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,/homemonté 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/mapperde l'hôte, les partitions de l'image disque - et pouvoir les monterparted: 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
- 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