18
0
Fork 0

relecture : typos + améliorations + choix

This commit is contained in:
gcolpart 2016-12-29 01:56:44 +01:00
parent ae133598ef
commit 452cd64b26
1 changed files with 61 additions and 51 deletions

View File

@ -4,6 +4,7 @@
* Documentation libvirt : <https://libvirt.org/docs.html>
[KVM](http://www.linux-kvm.org/) est une technologie de virtualisation intégrée au noyau Linux.
On l'utilise avec [libvirt](https://libvirt.org), une surcouche qui facilite l'utilisation de la virtualisation.
## Installation
@ -30,15 +31,13 @@ Compiled with support for:
## Utilisation basique de libvirt
[libvirt](https://libvirt.org) est une surcouche facilitant la gestion de la virtualisation.
Un démon **libvirtd** tourne sur l'hyperviseur, il peut être redémarré sans impact sur les VMs :
~~~
# systemctl restart libvirtd
~~~
La commande **virsh** permet de réaliser des opérations en ligne de commande :
La commande [virsh](#virsh) permet de réaliser des opérations en ligne de commande :
~~~
# virsh list --all
@ -53,10 +52,11 @@ Pour un accès « graphique », installer sur le poste client :
~~~
# apt install virt-manager netcat-openbsd
~~~
puis ajouter une clé SSH permettant de se connecter au serveur avec un utilisateur dans le groupe _libvirt_
puis ajouter une clé SSH permettant de se connecter au serveur avec l'utilisateur **root**
puis démarrer `virt-manager` et ajouter une _connexion à un hôte distant_ via SSH.
Les VMs définies pour tourner sur l'hyperviseur ont un fichier de définition XML dans le répertoire `/etc/libvirt/qemu/`.
Les VMs définies pour tourner sur l'hyperviseur ont [un fichier de définition XML](https://libvirt.org/formatdomain.html) dans le répertoire `/etc/libvirt/qemu/`.
## Configuration
@ -66,12 +66,12 @@ Un hyperviseur KVM doit avoir des CPUs supportant la virtualisation, une bonne q
Un hyperviseur KVM doit avoir des CPUs supportant la virtualisation.
Cela s'active souvent via le BIOS de la machine.
Cela s'active en général via le *BIOS* de la machine.
Si ce n'est pas activé, vous aurez une erreur `KVM: disabled by BIOS`
### Configuration mémoire
On conseille d'avoir une certaine marge de RAM par rapport à la somme de la mémoire allouée à chaque VM, surtout si vous activer du cache au niveau des disques des VMs (ce qui est conseillé pour de bonnes performances).
On conseille d'avoir une certaine marge de RAM par rapport à la somme de la mémoire allouée à chaque VM, surtout si vous activez du cache au niveau des disques des VMs (ce qui est conseillé pour de bonnes performances).
On conseille également de configurer **au moins 10 Go de swap sur l'hyperviseur** afin d'éviter que le mécanisme *Out-Of-Memory Killer* ne se déclenche au moindre pic de mémoire.
@ -105,7 +105,7 @@ iface br0 inet static
up echo 0 > /sys/class/net/br0/bridge/multicast_snooping
~~~
*Note 1* : il est nécessaire de désactiver le multicast_snooping pour assurer un bon fonctionnement de l'IPv6
*Note 1* : il est nécessaire de désactiver le multicast_snooping pour assurer un bon fonctionnement d'IPv6
*Note 2* : il est nécessaire de commenter `source-directory /etc/network/interfaces.d` car [cela fait boguer libvirt](http://bugs.debian.org/740114)
@ -119,29 +119,31 @@ Nous utilisons principalement :
* Volumes DRBD over LVM (supporte les migrations à chaud)
* Format QCOW2 (supporte les snapshots à chaud)
* Format RAW (plus performant que QCOW2)
* Format RAW (un peu plus performant que QCOW2)
## Création d'une VM
### virt-install
Avoir un ISO disponible sur l'hyperviseur (pour Debian, télécharger l'ISO _netinst_ sur <http://cdimage.debian.org/debian-cd/current/amd64/iso-cd/>) puis l'on crée une VM :
Avoir un ISO disponible sur l'hyperviseur (pour Debian, télécharger l'ISO _netinst_ sur <http://cdimage.debian.org/debian-cd/current/amd64/iso-cd/>) puis l'on crée une VM ainsi :
~~~
$ virt-install --connect=qemu:///system \
# virt-install --connect=qemu:///system \
--name=template \
--vcpus=1 \
--cpu mode=host-passthrough --vcpus=1 \
--ram=512 \
--disk path=/srv/machines/template.qcow2,bus=virtio,cache=none,size=42,format=qcow2 \
--disk path=/path/template.qcow2,bus=virtio,cache=none,size=42,format=qcow2 \
--network=bridge:br0,model=virtio \
--noautoconsole --graphics vnc,listen=127.0.0.1,keymap=fr \
--cdrom=/srv/isos/debian-8.6.0-amd64-netinst.iso
--cdrom=debian-8.6.0-amd64-netinst.iso
~~~
*Note* : si besoin de performance, on pourra mettre `cache=writeback`
*Notes* :
*TODO* : à voir la valeur de `--cpu`
* `--cpu mode=host-passthrough` signifie que le CPU virtualisé sera identique au CPU de l'hyperviseur, en cas de migration vers un autre hyperviseur il devra avoir un CPU strictement identique
* l'exemple utilise (ou crée si il n'existe pas) un fichier QCOW2 de 42 Go, on pourra évidemment choisir d'autres types de stockaes
* si l'on a besoin de performances élevées en I/O, on pourra mettre l'option `cache=writeback` pour *--disk*
On peut ensuite se connecter en VNC via l'hyperviseur et réaliser l'installation :
@ -149,6 +151,8 @@ On peut ensuite se connecter en VNC via l'hyperviseur et réaliser l'installatio
$ vncviewer -via kvm.example.com 127.0.0.1:5900
~~~
*Note* : on peut connaître le port VNC d'une VM avec la commande `virsh qemu-monitor-command <vm-name> --hmp "info vnc"`
### virt-manager
**Nous déconseillons l'installation via _virt-manager_ !!**
@ -157,7 +161,7 @@ Certes, l'installation est plus conviviale (car graphique) mais :
* les options disponibles sont limitées (impossible de sélectionner un volume DRBD par exemple)
* les choix réalisés par défaut sont incorrects (ajout de périphériques Tablette, Video QXL, USB etc.)
Si vous utilisez tout de même `virt-manager`, la démarche est similaire à v`irt-install`, on choisira bien les options suivantes :
Si vous utilisez tout de même `virt-manager`, la démarche est similaire à `virt-install`, on choisira bien les options suivantes :
* Choix processor : Configuration > ne PAS cocher *Copier la configuration CPU de l'hôte* et choisir *Modèle : ???*
* NIC : choisir *Device model : virtio*
@ -183,6 +187,7 @@ Les stockages disponibles doivent être visibles par libvirt :
~~~
# virsh pool-list --all
# virsh vol-list <pool-name>
# virsh help pool
Storage Pool (help keyword 'pool'):
@ -228,7 +233,7 @@ Les stockages disponibles doivent être visibles par libvirt :
### Volumes DRBD/LVM
TODO
voir [HowtoLVM]() et [HowtoDRBD]()
### Format QCOW2
@ -241,7 +246,7 @@ Création d'une image QCOW2 :
# qemu-img create -f qcow2 test0.qcow2 5G
~~~
Information sur une image QCOW2 :
Informations sur une image QCOW2 :
~~~
# qemu-img info debian1.qcow2
@ -262,7 +267,7 @@ Convertir une image RAW en QCOW2 :
# qemu-img convert -f qcow2 -O raw test0.qcow2 test0.img
~~~
#### Monter une image QCOW2 via qemu-NBD
#### Monter une image QCOW2 via qemu-nbd
`qemu-nbd` permet de créer un point de montage NBD (Network Block Device) :
@ -292,7 +297,7 @@ Cela peut ensuite être stoppé via :
L'avantage de ce format est sa simplicité ! C'est tout simplement une suite d'octets..
Cela permet de monter les partitions facilement (merci _kpartx_).
Sous Linux, grâce au _sparse file_, c'est également un format à taille variable.
Sous Linux, grâce au principe du _sparse file_ (fichier à trou), c'est également un format à taille variable.
Création de l'image :
@ -357,9 +362,10 @@ Disk /dev/loop0: 161.1 GB, 161061273600 bytes
# parted /dev/loop0
[…]
~~~
Voir <http://trac.evolix.net/infogerance/wiki/HowtoParted>
* Démonter et remonter l'image (un partprobe ne suffit visiblement pas pour détecter la nouvelle taille de la partition) :
Voir <http://trac.evolix.net/infogerance/wiki/HowtoParted>
* Démonter et remonter l'image (`partprobe` ne suffit visiblement pas pour détecter la nouvelle taille de la partition) :
~~~
# kpartx -d host.img
@ -393,7 +399,7 @@ The filesystem on /dev/mapper/loop0p1 is now 39321592 blocks long.
# mount /dev/mapper/loop0p1 /mnt
# df -h /mnt
/dev/mapper/loop0p1 148G 76G 72G 52% /mnt
/dev/mapper/loop0p1 148G 76G 72G 52% /mnt
# umount /mnt
~~~
@ -408,7 +414,7 @@ loop deleted : /dev/loop0
## Réseau
Les interfaces réseau en place doivent être visibles par libvirt :
Les interfaces réseau en place doivent être visibles par _libvirt_ :
~~~
# virsh iface-list --all
@ -452,7 +458,7 @@ Les interfaces réseau en place doivent être visibles par libvirt :
### Adresse MAC
On peut générer l'adresse MAC d'une VM KVM avec le script suivant :
On peut générer l'adresse MAC d'une VM KVM avec la commande suivante :
~~~
$ echo $(echo -n 52:54:00 ; for i in `seq 1 3`; do echo -n `echo ":$RANDOM$RANDOM" | cut -n -c -3`; done)
@ -478,17 +484,17 @@ iface br0.42 inet static
gateway <gateway>
~~~
Dans les VMs, on aura ainsi une configuration réseau VLANisé (voir [HowtoDebian/Reseau]).
Dans les VMs, on aura ainsi une configuration réseau « VLANisée », voir <http://trac.evolix.net/infogerance/wiki/HowtoDebian/Reseau#VLAN>
### Mode bridge avec openvswith
Notamment utile pour utiliser avec le RPN Online.
Notamment utile pour utiliser avec le réseau _RPN Online_ de l'hébergeur français ONLINE/Dedibox.
`/etc/network/interfaces` :
~~~
# LAN bridge over RPN
# <https://documentation.online.net/fr/dedicated-server/tutorials/network/rpn-proxmox-openvswitch>
# https://documentation.online.net/fr/dedicated-server/tutorials/network/rpn-proxmox-openvswitch
auto br1
iface br1 inet manual
ovs_type OVSBridge
@ -518,7 +524,7 @@ Créer un fichier XML définissant le réseau :
Le mode NAT peut être intéressant si l'on ne peut pas avoir d'IP dans le réseau de l'hyperviseur.
Avec libvirt, il suffit d'installer :
Avec _libvirt_, il suffit d'installer :
~~~
# apt install dnsmaq ebtables
@ -549,7 +555,7 @@ Et l'on peut configurer avec un réseau NAT avec `virt-manager` ou `virsh net-cr
### Mode réseau NAT (sans libvirt)
Une raison d'utiliser le NAT est qu'une interface Wi-Fi n'est pas toujours utilisable dans un bridge :
*Note* : une raison d'utiliser le NAT est qu'une interface Wi-Fi n'est pas toujours utilisable dans un bridge :
~~~
# brctl addif br0 wlan0
@ -592,9 +598,11 @@ L'utilisation du format de stockage QCOW2 permet d'avoir des snapshots à chaud
On peut créer plusieurs snapshots de l'état disque/mémoire, et restaurer en quelques secondes.
Avec libvirt, création/restauration/suppression de snapshot se gère de façon conviviale avec `virt-manager`
ou on peut aussi utiliser `virsh` (TODO: exemple de XML pour créer un snapshot) :
ou on peut aussi utiliser `virsh` :
~~~
# virsh snapshot-create-as template-evolinux snapshot1
# virsh snapshot-list template
Name Creation Time State
------------------------------------------------------------
@ -625,7 +633,9 @@ Metadata: yes
snapshot-revert Revert a domain to a snapshot
~~~
On peut gérer les snapshots via le [Mode Monitor](#mode-monitor) et les commandes `savevm`, `loadvm`, `info snapshots`.
On peut aussi gérer les snapshots via le [Mode Monitor](#mode-monitor) et les commandes `savevm`, `loadvm`, `info snapshots`.
*Note* : les snapshots créés avec `savevm` ne seront pas visible via _libvirt_.
### Options -loadvm / -snapshot (non gérées avec libvirt)
@ -654,9 +664,9 @@ Si nécessaire on peut tout de même forcer l'écriture en passant l'option *com
<http://wiki.qemu.org/Documentation/CreateSnapshot>
Une option intéressante est de créer une image d'une installation de base et de créer des dérivées
à partir de cette image. Non seulement permet de repartir d'une installation déjà faite, mais cela
permet aussi une optimisation de la place (l'image dérivée est en Copy-on-Write de celle de base)
Une option intéressante avec le format QCOW2 est la possibilité de créer une image d'une installation
de base et de créer des dérivées à partir de cette image. Non seulement permet de repartir d'une installation déjà faite,
mais cela permet aussi une optimisation de la place (l'image dérivée est en Copy-on-Write de celle de base)
voire même de la mémoire selon les rumeurs :-)
Création d'une image dérivée :
@ -674,7 +684,7 @@ cluster_size: 65536
backing file: install-debian-base.qcow2base (actual path: install-debian-base..qcow2base)
~~~
/!\\ Attention, ne jamais modifier une image de base si elle a des images dérivées sous peine de tout perdre !!
/!\\ Attention, ne jamais modifier une image de base si elle a des images dérivées sous peine de tout perdre !
## Mode monitor
@ -690,7 +700,7 @@ _libvirt_ crée automatiquement un _mode monitor_ qu'il utilise (donc non access
# virsh qemu-monitor-command <vm-name> --hmp "info block"
~~~
On peut aussi créer un _mode monitor_ manuellement, qui sera accessible via `telnet` :
Si on utilise _kvm_ sans _libvirt_, on peut créer un _mode monitor_ accessible via `telnet` :
~~~
$ kvm […] -monitor tcp:127.0.0.1:<port monitor>,server,nowait
@ -781,8 +791,7 @@ sync
cp debian1.qcow2 debian.current.qcow2
~~~
/!\\ Attention, avec *libvirt* si l'on passe directement par le _mode monitor_ les snapshots ne seront pas visibles par _libvirt_ qui gère un état XML des snapshots.
On pourra néanmoins faire :
/!\\ Attention, avec *libvirt* si l'on passe directement par le _mode monitor_ les snapshots ne seront pas visibles par _libvirt_ qui gère un état XML des snapshots. On pourra néanmoins faire :
~~~
# virsh qemu-monitor-command <vm-name> --hmp "savevm snap.current"
@ -871,7 +880,7 @@ On peut utiliser l'option `--preserve-data` pour copier les données vers une im
*Note* : Il faut s'assurer d'ouvrir les ports TCP 49152 à 49215 entre les machines car par défaut *libvirtd* utilisent ces ports pour faire des netcat des données !
Pour une migration à chaud, il faut avoir un storage commun pour les disques (SAN, réplication DRBD, etc.).
Pour une migration à chaud, il faut avoir un CPU identique (à voir selon l'option un storage commun pour les disques (SAN, réplication DRBD, etc.).
Pour envoyer une VM locale _test_ vers l'hyperviseur _foo_ :
@ -935,6 +944,7 @@ En cas de plantage du processus _qemu-system_, il sera peut être nécessaire de
# systemctl reset-failed machine-qemu\\x2dmavm.scope
~~~
## Munin
Il peut être intéressant de grapher quelques infos de KVM dans _Munin_.
@ -1004,7 +1014,7 @@ $ ssh -X -C -c arcfour root@kvm.example.com
### Désactiver l'interface réseau d'une VM à chaud
Pour ne pas avoir besoin de redémarrer une VM pour retirer une interface, on peut retirer son interface vnetX sur l'hyperviseur du bridge associé. Le nom de cette interface se trouve avec la commande "virsh dumpxml" :
Pour ne pas avoir besoin de redémarrer une VM pour retirer une interface, on peut retirer son interface vnetX sur l'hyperviseur du bridge associé. Le nom de cette interface se trouve avec la commande `virsh dumpxml` :
~~~
# virsh dumpxml <vm-name>
@ -1029,19 +1039,19 @@ Il suffit ensuite de la retirer du bridge :
# brctl delif br2 vnet7
~~~
### Performances (TODO: à revoir)
### Tips performance
Utiliser autant que possible les drivers virtio (disque et réseau) sur les invités le supportant.
<http://www.linux-kvm.org/page/Tuning_KVM>
Dans le cas d'un hyperviseur avec une carte RAID hardware disposant d'un cache avec batterie, créer les machines avec l'option `cache=none` :
* Utiliser le même CPU que sur l'hyperviseur via l'option `kvm -cpu host` qui se positionne avec `virt-install --cpu mode=host-passthrough` (attention, la VM ne pourra être migrée que sur un hyperviseur avec un CPU identique)
~~~
<driver name='qemu' type='raw' cache='none'/>
~~~
* Utiliser autant que possible les drivers _virtio_ (pour les disques et les interfaces réseau) sur les VMs
Et désactiver les barrières si Ext4 est utilisé.
* Dans le cas d'un hyperviseur avec une carte RAID hardware disposant d'un cache avec batterie, on peut positionner `cache=none` pour les disques… une autre stratégie est d'utiliser `cache=writeback` et d'avoir beaucoup de mémoire disponible sur son hyperviseur.
Le scheduler deadline semble également donner les meilleures performances tant sur l'hôte que sur les invités.
* Désactiver les barrières si Ext4 est utilisé.
* Le scheduler _deadline_ semble également donner les meilleures performances tant sur l'hôte que sur les invités.
On peut aussi présenter toutes les instructions du CPU hôte aux machines virtuelles :
@ -1053,7 +1063,7 @@ On peut aussi présenter toutes les instructions du CPU hôte aux machines virtu
### Etendre une image RAW
Différentes méthodes pour étendre une image RAW :
Pour le sport, voici différentes méthodes pour étendre une image RAW :
~~~
# qemu-img resize host.img +50G