Debian Lenny - Virtualisation avec

Libvirt/KVM
Debian GNU/Linux

Matthieu Vogelweith
13 janvier 2009

Rsum
Lobjectif de ce document est de dtailler linstallation dun serveur KVM [1] (Kernel based
Virtual Machine) complet ainsi que les bases de son administration.
Ce document a t rdig en LaTeX en utilisant lexcellent Vim sous Debian GNU/Linux. Il est
disponible aux formats XHTML et PDF. Les sources LaTeX sont disponibles ici : LATEX

Licence
c 2009 Matthieu VOGELWEITH <matthieu@vogelweith.com>.
Copyright
Vous avez le droit de copier, distribuer et/ou modifier ce document selon les termes de la GNU
Free Documentation License, Version 1.3 ou ultrieure publie par la Free Software Foundation ;
avec aucune section inaltrable, aucun texte de premire page de couverture, et aucun texte de
dernire page de couverture. Une copie de la licence est disponible dans la page GNU Free Documentation License.

Table des matires

Table des matires

1 Prparation
1.1 Pr requis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Installation des paquets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4
4
4

2 Gestion des images disques

2.1 Prsentation . . . . . . . . . . . . .
2.2 Cration dune image disque . . . . .
2.3 Cration dune image disque relative .
2.4 Conversion dimages . . . . . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

6
6
6
6
6

3 Gestion des snapshots

3.1 Mode snapshot . . . . . . . . . . .
3.2 Cration dun snapshot . . . . . . .
3.3 Affichage de la liste des snapshots
3.4 Chargement dun snapshot . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

7
7
7
7
7

4 Utilisation de libvirt pour la gestion des VM

4.1 Cration dune VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 VIRSH : Gestion des VM en console . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Sauvegarde/Restauration automatique . . . . . . . . . . . . . . . . . . . . . . . .

8
8
8
8

.
.
.
.

5 Serveur de virtualisation : problmatique rseau

5.1 Prsentation . . . . . . . . . . . . . . . . . .
5.2 Pr requis . . . . . . . . . . . . . . . . . . .
5.3 Configuration rseau de lhte . . . . . . . . .
5.4 Le proxy ARP avec Shorewall . . . . . . . . .
5.5 Configuration de libvirt . . . . . . . . . . . . .
5.6 Configuration rseau des clients . . . . . . . .
6 Rfrences

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

10
10
10
11
11
12
13
14

Chapitre 1

Prparation
1.1

Pr requis

Pour obtenir des performances correcte et pouvoir installer des OS non modifi dans les machines virtuelle, le support des extensions de virtualisation du processeur est indispensable. Il est
possible de vrifier lexistance de cette extension sur le processeur laide de la commande suivante :
# egrep ^ flags .*( vmx | svm ) / proc / cpuinfo >/ dev / null && echo OK || echo KO

Si la commande retourne "OK", le processeur possde les extensions de virtualisation.

Ce document suppose galement que le serveur est dj install avec une Debian 5.0 (Lenny)
[2] propre. Linstallation et la configuration du systme de base sont prsente en dtail dans un
document ddi cet effet : [3].

1.2

Installation des paquets

Comme indiqu prcdemment, cette documentation propose dutiliser la LibVirt pour grer des
machines virtuelles KVM. Dans Lenny, tout sinstalle trs simplement avec la commande suivante :
# aptitude install libvirt - bin kvm qemu virtinst

Si les extensions de virtualisation sont bien gres par le processeur, le script dinit de kvm a
d charger automatiquement les modules noyaux. Il est possible de le vrifier avec la commande
suivante :
# lsmod | grep kvm
kvm_intel
kvm

39776
127464

1
1 kvm_intel

Par dfaut, libvirt ne se lance pas automatiquement. Pour ce faire, il suffit dditer le fichier
/etc/default/libvirt-bin et de mofifier la variable suivante :
start_libvirtd =" yes "

Le dmon sera alors actif au dmarrage ou aprs avoir excut la commande suivante :
# / etc / init .d/ libvirt - bin

restart

Chapitre 2

Gestion des images disques

2.1

Prsentation

- diffrents format disponibles

2.2

Cration dune image disque

$ qemu - img create -f qcow2 disk . qcow2 100 G

2.3

Cration dune image disque relative

- Cration dune image disque en utilisant une autre image comme base. Cette nouvelle image
ne contiendra que les diff par rapport limage de base.
- Utile par exemple si on dispose dune image clean dun OS et que lon souhaite dcliner plusieurs
machines partir de cet OS.

$ qemu - img create -b disk . qcow2 -f qcow2 reldisk . qcow2

Il suffit ensuite dutiliser reldisk.qcow2 dans les nouvelles VM.

2.4

Conversion dimages

Conversion dune image VMWare :

$ qemu - img convert -f vmdk vdisk . vmdk -O qcow2 vdisk . qcow2

Rduction de la taille dune image qcow2 :

$ qemu - img convert vdisk . qcow2 -O qcow2 vdisk - clean . qcow2

Chapitre 3

Gestion des snapshots

3.1

Mode snapshot

Mode snapshot : disk en RO, toute les modifs sont faites dans des fichiers temp dans /tmp.
Possibilit dcriture sur le disk avec "commit" en console.

3.2

Cration dun snapshot

qemu > savevm

3.3

Affichage de la liste des snapshots

qemu > info snapshots

3.4

Chargement dun snapshot

qemu > loadvm

Chapitre 4

Utilisation de libvirt pour la gestion des

VM
4.1

Cration dune VM

# qemu - img create -f qcow2 lenny . qcow2 100 G

# virt - install -- ram =1024 -- name = lenny \
-- file =/ var / lib / libvirt / images / lenny . qcow2 \
-- cdrom =/ tmp / debian - LennyBeta2 - amd64 - netinst . iso \
-- hvm -- vnc -- noautoconsole -- accelerate -- network = bridge : br0

4.2

VIRSH : Gestion des VM en console

4.3

Sauvegarde/Restauration automatique

VIRSH apporte galement des commandes simples permettant de suspendre restaurer les
machines virtuelles. Par exemple, il est possible de mettre une machine en hibernation avec la
commande suivante :
# virsh save vm_name vm_name . dump

La machine sera alors stoppe et les donnes ncessaires la restauration de la machine

seront stockes dans le dump vm_name.dump. Pour restaurer la VM, il suffit ensuite dexcuter la
commande ci-dessous :
# virsh restore vm_name . dump

Une utilisation courante de ce type de commandes et la suspension/restauration des VMs lors

de larrt/dmarrage de la machine hte. En effet, par dfaut, les machines virtuelles sont stoppes
brutalement lors de larrt du dmon libvirt-bin. Pour corriger ce problme, le paquet disponible
fournit depuis la version 0.4.6-4 un script dinit libvirt-suspendonreboot permettant de suspendre
les VMs lors de larrt de la machine hte et de la restaurer lors du dmarrage. Cest une solution
temporaire mais qui permet darrter correctement les VMs lors dun reboot de la machine hte par
exemple. Ce script peut tre install en utilisant les commandes ci-dessous :

#
#
#
#

cp / usr / share / doc / libvirt - bin / examples / libvirt - suspendonreboot / etc / init .d/
chmod 755 / etc / init .d/ libvirt - suspendonreboot
mkdir -p / var / lib / libvirt / autosuspend /
update - rc .d libvirt - suspendonreboot defaults 21 19

Chapitre 5

Serveur de virtualisation :
problmatique rseau
5.1

Prsentation

Lors de lutilisation dune machine hberge comme serveur de virtualisation, on peut tre
amener rencontrer des problmes rseaux un peu spcifique. Par machine hberge, entendez
machine qui nest pas accessible physiquement et ou on ne gre pas les quipements rseaux
associs".
Par exemple sur les Dedibox XL [4], les extensions de virtualisations sont disponibles et il est
possible davoir plusieurs IP publiques routes sur la mme machine. Cependant, il nest pas possible daffecter simplement les autres IP publiques des VMs bridges sur le rseau en raison
des systmes de scurits mis en place sur les switches. En effet, lorsquon bridge une VM directement sur linterface physique de la machine hte, les paquets sortant de la VM sont mis avec
une adresse MAC virtuelle diffrente de ladresse MAC de la machine hte. Ce comportement sera
immdiatement dtect par le switch qui coupera le port pour des raisons de scurit parce quil
nest pas cens recevoir des paquets avec des adresses MAC diffrentes.
Dans ce cas de figure, qui correspond la plupart des plates-formes dhbergement, il nest
donc pas possible de bridger les machines virtuelles directement sur le rseau physique. Pour
contourner le problme, il y a principalement deux solutions :
Faire du NAT pour "cacher" les machines virtuelles derrire la machine hte. Dans ce cas
les machines virtuelles ont une IP prive mais sont accessible depuis lextrieur avec leur IP
publique ;
Mettre en place un proxy ARP pour "cacher" uniquement les adresses MAC des machines
virtuelles. Dans ce cas les machines virtuelles utilisent directement leurs IP publiques.
La solution la plus souple et la plus lgante est bien entendu la solution du Proxy ARP. Ce
paragraphe propose donc de mettre en place un proxy ARP afin de grer une "DMZ de machines
virtuelles".

5.2

Pr requis

Ce paragraphe suppose bien videmment quune machine hberge est disponible avec les
extensions de virtualisation et plusieurs IP publiques (au moins 2) sont disponibles, toutes routes
vers la machine hte.

10

Cot logiciel, on suppose que shorewall [5] est dja install et correctement configur sur la
machine hte.

5.3

Configuration rseau de lhte

La toute premire tape dans le mise en place de cette DMZ virtuelle est la cration dun bridge
sur la machine hte qui sera le point dentre de la DMZ. Pour faire le parallle avec une installation
physique, on peut comparer ce bridge un switch sur lequel serait branch une interface du firewall
et une interface de chaque machine virtuelle.
La cration de ce bridge doit tre faite en mme temps que le montage de linterface rseau
publique de la machine hte. Pour cela, modifier la configuration rseau de lhte dans le fichier
/etc/network/interfaces comme indiqu ci-dessous :
auto eth0
iface eth0 inet static
address IP_HOTE
netmask MASK_HOTE
gateway IP_GATEWAY
up brctl addbr dmz0
up brctl setfd dmz0 0
up brctl stp dmz0 on
up ifconfig dmz0 up

La configuration ci-dessus permet donc dajouter une interface dmz0 de type bridge pour accueillir les interfaces virtuelles des VMs. Notons que libvirt est capable de grer ce type de bridge
de manire automatique mais dans le cas prsent il est indispensable de la grer manuellement
pour les raisons suivantes :
Le bridge doit tre nomm de la mme faon parce que son nom est utiliser dans la configuration de shorewall ;
Le bridge doit imprativement tre mont AVANT le dmarrage de Shorewall pour que celuici dmarre correctement et puisse mettre en place le proxy ARP.
Attention, il ne faut surtout pas faire lerreur dajouter eth0 dans les interfaces associes au
bridge dmz0, dans ce cas les VMs seraient directement bridges sur le rseau physique et le switch
bloquerai le port. Libvirt ajoutera dynamiquement les interfaces virtuelles (vnet*) au bridge lors du
dmarre des VMs.

5.4

Le proxy ARP avec Shorewall

Shorewall permet de configurer un proxy ARP de manire relativement simple. Pour des besoins plus gnriques, la documentation officielle [6] est trs bien faite.
La premire tape dans la mise en place de cette DMZ virtuelle est la cration dune nouvelle zone Shorewall de type IPv4. Cette zone permettra de grer les rgles daccs toutes les
machines virtuelles prsentes dans la DMZ. Ceci ce fait en ajoutant la ligne suivante dans /etc/shorewall/zones :
# ZONE
dmz

TYPE
ipv4

11

Il faut ensuite associer cette nouvelle zone une interface disponible sur le machine hte. Dans
le cas prsent, il sagit du bridge qui a t cr prcdemment dmz0. Pour cela, ajouter la ligen
suivante dans le fichier /etc/shorewall/interfaces :
# ZONE
dmz

INTERFACE
dmz0

Ltape suivante est la gestion des rgles de filtrage pour cette zone. Si lon considre que cette
zone est rellement une DMZ, on peut ajouter les lignes suivantes dans /etc/shorewall/policy pour
autoriser tout le trafic entrant et sortant de la DMZ :
# SOURCE
dmz
all

DEST
all
dmz

POLICY
ACCEPT
ACCEPT

Attention, la configuration dcrite ci-dessus autorise tout le trafic vers les machines de la
DMZ. Ces machines ne seront donc pas du tout protges par le firewall de la machine hte et il
est indispensable dinstaller un firewall sur chaque machine virtuelle. Nanmoins, il est tout a fait
possible, pour des raisons de performance notamment, de modifier ces rgles et de grer toute la
scurit rseau sur la machine hte.
La zone DMZ tant dfinie et configure, il reste mettre en place le proxy ARP proprement
dit, tche qui est grandement simplifie par shorewall. Par exemple, si lon souhaite dmarrer deux
VM dans la DMZ ayant pour IP publique IP_DMZ_1 et IP_DMZ_2, il faut ajouter les lignes suivantes
dans le fichier /etc/shorewall/proxyarp :
# ADDRESS
IP_DMZ_1
IP_DMZ_2

INTERFACE
dmz0
dmz0

EXTERNAL
eth0
eth0

HAVEROUTE
no
no

PERSISTENT
yes
yes

Notons que dans la configuration ci-dessus, loption HAVEROUTE a t dfinie "no" pour
indiqu shorewall que les routes ncessaires pour joindre les VMs ne sont renseignes sur la
machine hte. Shorewall ajoutera donc les routes automatiquement.
Enfin, pour permettre shorewall de transmettre les paquets entre eth0 et dmz0, il faut activer
le forwarding en modifiant loption suivante dans /etc/shorewall/shorewall.conf :
IP_FORWARDING = On

Pour que les modifications soient prisent en compte, il faut bien entendu redmarrer shorewall.
ATTENTION : pour que shorewall redmarre correctement, le bridge dmz0 doit dja tre actif !
Lorsque tout est vrifi, le redmarrage peut se faire avec la commande ci-dessous :
# / etc / init .d/ shorewall restart

5.5

Configuration de libvirt

Lorsque le proxy ARP est correctement configur, il faut configurer les machines virtuelles pour
quelles puissent utiliser cette nouvelle configuration. Cette configuration est extrmement simple

12

puisquil suffit de configurer les VM en mode bridge sur linterface dmz0. Comme les paquets seront
directement envoys par shorewall sur dmz0, les machines pourront recevoir les paquets sur leur
interface rseau.
Cette configuration en mode bridge peut tre ralise avec les diffrentes interfaces de libvirt
(virsh, virt-manager, ...) ou tout simplement en ditant le fichier XML associ la machine dans
/etc/libvirt/qemu/nom_de_la_vm.xml :
< interface type = bridge >
<mac address = xx : xx : xx : xx : xx :xx / >
< source bridge = dmz0 / >
</ interface >

5.6

Configuration rseau des clients

La machine hte tant maintenant correctement configure, il reste configurer les machines
virtuelles pour quelles puissent utiliser directement leurs IP publiques. Ceci se fait simplement en
utilisant la configuration ci-dessous dans /etc/network/interfaces :
auto eth0
iface eth0 inet static
address IP_DMZ
netmask 255.255.255.255
post - up / sbin / ip route add IP_HOTE /32 dev eth0
post - up / sbin / ip route add default via IP_HOTE

Si tout cest pass correctement, les machines virtuelles bridges sur dmz0, donc situes dans
la DMZ, doit tre accessible directement en utilisant leur IP publique.

13

Chapitre 6

Rfrences
[1] Site officiel de kvm. kvm.qumranet.com.
[2] Site officiel du projet debian. www.debian.org.
[3] Installation et configuration de debian etch. www.vogelweith.com/debian_server/00_installation.php.
[4] Le site dedibox. www.dedibox.fr.
[5] Shoreline firewall. www.shorewall.net.
[6] Configuration dun proxyarp avec shorewall. www.shorewall.net/ProxyARP.htm.
[7] Utilisation de virtio avec kvm. kvm.qumranet.com/kvmwiki/Virtio.
[8] Site officiel de libvirt. libvirt.org.
[9] lments de scurisation de debian lenny. www.vogelweith.com/debian_server/01_security.php.

14