KVM: ajustements de syntaxe
This commit is contained in:
parent
cf1d0b86f2
commit
0e03ef52b5
58
HowtoKVM.md
58
HowtoKVM.md
|
|
@ -67,7 +67,7 @@ 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.
|
||||
Si ce n'est pas activé, vous aurez une erreur *KVM: disabled by BIOS*
|
||||
Si ce n'est pas activé, vous aurez une erreur `KVM: disabled by BIOS`
|
||||
|
||||
### Configuration mémoire
|
||||
|
||||
|
|
@ -75,7 +75,7 @@ On conseille d'avoir une certaine marge de RAM par rapport à la somme de la mé
|
|||
|
||||
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.
|
||||
|
||||
Enfin, on conseille d'ajuster le paramètre *oom_score_adj* entre les machines critiques et non critiques :
|
||||
Enfin, on conseille d'ajuster le paramètre `oom_score_adj` entre les machines critiques et non critiques :
|
||||
|
||||
~~~
|
||||
@hourly test -s /var/run/libvirt/qemu/VM-non-critique.pid && echo '800' > /proc/$(cat /var/run/libvirt/qemu/VM-non-critique.pid)/oom_score_adj
|
||||
|
|
@ -85,7 +85,7 @@ Enfin, on conseille d'ajuster le paramètre *oom_score_adj* entre les machines c
|
|||
### Configuration réseau
|
||||
|
||||
On conseille l'utilisation du mode **bridge** pour le réseau.
|
||||
On crée un bridge _br0_ liée à l'interface _eth0_ :
|
||||
On crée un bridge `br0` liée à l'interface `eth0` :
|
||||
|
||||
~~~
|
||||
# brctl addbr br0
|
||||
|
|
@ -107,9 +107,9 @@ iface br0 inet static
|
|||
|
||||
*Note 1* : il est nécessaire de désactiver le multicast_snooping pour assurer un bon fonctionnement de l'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)
|
||||
*Note 2* : il est nécessaire de commenter `source-directory /etc/network/interfaces.d` car [cela fait boguer libvirt](http://bugs.debian.org/740114)
|
||||
|
||||
/!\\ : s'assurer d'avoir bien installé _bridge-utils_ et configuré le firewall avant de redémarrer
|
||||
/!\\ : s'assurer d'avoir bien installé **bridge-utils** et configuré le firewall avant de redémarrer
|
||||
|
||||
### Configuration stockage
|
||||
|
||||
|
|
@ -139,9 +139,9 @@ $ virt-install --connect=qemu:///system \
|
|||
--cdrom=/srv/isos/debian-8.6.0-amd64-netinst.iso
|
||||
~~~
|
||||
|
||||
*Note* : si besoin de performance, on pourra mettre *cache=writeback*
|
||||
*Note* : si besoin de performance, on pourra mettre `cache=writeback`
|
||||
|
||||
*TODO* : à voir la valeur de --cpu=???
|
||||
*TODO* : à voir la valeur de `--cpu`
|
||||
|
||||
On peut ensuite se connecter en VNC via l'hyperviseur et réaliser l'installation :
|
||||
|
||||
|
|
@ -157,7 +157,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 à _virt-install_, on choisira bien les options suivantes :
|
||||
Si vous utilisez tout de même `virt-manager`, la démarche est similaire à v`irt-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*
|
||||
|
|
@ -172,7 +172,7 @@ Si vous utilisez tout de même _virt-manager_, la démarche est similaire à _vi
|
|||
Vous pouvez écrire votre propre fichier de définition XML puis l'injecter :
|
||||
|
||||
~~~
|
||||
# virsh define template.xml
|
||||
# virsh define template.xml
|
||||
# virsh start template
|
||||
~~~
|
||||
|
||||
|
|
@ -244,7 +244,7 @@ Création d'une image QCOW2 :
|
|||
Information sur une image QCOW2 :
|
||||
|
||||
~~~
|
||||
# qemu-img info debian1.qcow2
|
||||
# qemu-img info debian1.qcow2
|
||||
image: debian1.qcow2
|
||||
file format: qcow2
|
||||
virtual size: 12G (12884901888 bytes)
|
||||
|
|
@ -264,7 +264,7 @@ Convertir une image RAW en QCOW2 :
|
|||
|
||||
#### Monter une image QCOW2 via qemu-NBD
|
||||
|
||||
*qemu-nbd* permet de créer un point de montage NBD (Network Block Device) :
|
||||
`qemu-nbd` permet de créer un point de montage NBD (Network Block Device) :
|
||||
|
||||
~~~
|
||||
# modprobe nbd max_part=16;
|
||||
|
|
@ -272,7 +272,7 @@ Convertir une image RAW en QCOW2 :
|
|||
# partprobe /dev/nbd0;
|
||||
~~~
|
||||
|
||||
/dev/nbd0 est ensuite utilisable pour fdisk :
|
||||
`/dev/nbd0` est ensuite utilisable pour fdisk :
|
||||
|
||||
~~~
|
||||
# fdisk /dev/nbd0
|
||||
|
|
@ -329,7 +329,7 @@ Convertir ume image RAW en QCOW2 :
|
|||
# qemu-img resize host.img +50G
|
||||
Image resized.
|
||||
~~~
|
||||
ou on peut utiliser _dd_, exemple pour une taille finale de 80G :
|
||||
ou on peut utiliser `dd`, exemple pour une taille finale de 80G :
|
||||
|
||||
~~~
|
||||
# dd if=/dev/zero of=host.img seek=80G count=0 bs=1
|
||||
|
|
@ -337,12 +337,13 @@ ou on peut utiliser _dd_, exemple pour une taille finale de 80G :
|
|||
0+0 records out
|
||||
0 bytes (0 B) copied, 1.302e-05 s, 0.0 kB/s
|
||||
~~~
|
||||
|
||||
* Monter l'image et vérifier qu'elle a la bonne taille :
|
||||
|
||||
~~~
|
||||
# kpartx -v -a host.img
|
||||
add map loop0p1 (254:4): 0 314572737 linear /dev/loop0 63
|
||||
# fdisk -l /dev/loop0
|
||||
# fdisk -l /dev/loop0
|
||||
|
||||
Disk /dev/loop0: 161.1 GB, 161061273600 bytes
|
||||
[…]
|
||||
|
|
@ -360,13 +361,13 @@ Disk /dev/loop0: 161.1 GB, 161061273600 bytes
|
|||
* Démonter et remonter l'image (un partprobe ne suffit visiblement pas pour détecter la nouvelle taille de la partition) :
|
||||
|
||||
~~~
|
||||
# kpartx -d host.img
|
||||
# kpartx -d host.img
|
||||
loop deleted : /dev/loop0
|
||||
# kpartx -v -a host.img
|
||||
# kpartx -v -a host.img
|
||||
add map loop0p1 (254:4): 0 314572737 linear /dev/loop0 63
|
||||
~~~
|
||||
|
||||
* Lancer un fsck puis un resize2fs pour redimensionner le système de fichiers :
|
||||
* Lancer un `fsck` puis un `resize2fs` pour redimensionner le système de fichiers :
|
||||
|
||||
~~~
|
||||
# e2fsck -f /dev/mapper/loop0p1
|
||||
|
|
@ -395,7 +396,7 @@ The filesystem on /dev/mapper/loop0p1 is now 39321592 blocks long.
|
|||
* Puis démonter l'image :
|
||||
|
||||
~~~
|
||||
# kpartx -d host.img
|
||||
# kpartx -d host.img
|
||||
loop deleted : /dev/loop0
|
||||
~~~
|
||||
|
||||
|
|
@ -518,7 +519,7 @@ Avec libvirt, il suffit d'installer :
|
|||
# apt install dnsmaq ebtables
|
||||
~~~
|
||||
|
||||
Et l'on peut configurer avec un réseau NAT avec _virt-manager_ ou `virsh net-create` et un fichier XML du type :
|
||||
Et l'on peut configurer avec un réseau NAT avec `virt-manager` ou `virsh net-create` et un fichier XML du type :
|
||||
|
||||
~~~{.xml}
|
||||
<network connections='1'>
|
||||
|
|
@ -585,8 +586,8 @@ etc.
|
|||
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) :
|
||||
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) :
|
||||
|
||||
~~~
|
||||
# virsh snapshot-list template
|
||||
|
|
@ -619,9 +620,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 gérer les snapshots via le [Mode Monitor](#mode-monitor) et les commandes `savevm`, `loadvm`, `info snapshots`.
|
||||
|
||||
### Options -loadvm / -snapshot (non gérées avec libvirt)
|
||||
### Options -loadvm / -snapshot (non gérées avec libvirt)
|
||||
|
||||
On peut démarrer directement sur un snapshot *s0* avec l'option `-loadvm` :
|
||||
|
||||
|
|
@ -683,7 +684,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_ :
|
||||
On peut aussi créer un _mode monitor_ manuellement, qui sera accessible via `telnet` :
|
||||
|
||||
~~~
|
||||
$ kvm […] -monitor tcp:127.0.0.1:<port monitor>,server,nowait
|
||||
|
|
@ -703,7 +704,7 @@ $ echo system_powerdown | nc 127.0.0.1 <port monitor>
|
|||
~~~
|
||||
(qemu) info block
|
||||
(qemu) info blockstats
|
||||
(qemu) info network
|
||||
(qemu) info network
|
||||
(qemu) info uuid
|
||||
~~~
|
||||
|
||||
|
|
@ -834,7 +835,7 @@ La commande **virsh** peut également être utilisée à distance :
|
|||
|
||||
## Cloner une VM
|
||||
|
||||
Via clic-droit sur _virt-manager_ ou en CLI :
|
||||
Via clic-droit sur _virt-manager_ ou en CLI :
|
||||
|
||||
~~~
|
||||
# virt-clone --original <mytemplate-domainame> --name <newmachine> --file <newmachine>.img
|
||||
|
|
@ -979,8 +980,10 @@ Deux solutions, utiliser eth1 au lieu de eth0, ou corriger /etc/udev/rules.d/z25
|
|||
|
||||
~~~
|
||||
# qemu-img create -f qcow2 debian1.qcow2 20G
|
||||
|
||||
# kvm -hda debian1.qcow2 -cdrom debian-amd64-netinst.iso -boot d -m 512 -net nic,macaddr=<mac_address> -net tap,script=/etc/qemu-ifup -vnc :1 -k fr
|
||||
<installation via VNC 127.0.0.1:5901 puis boot final>
|
||||
|
||||
# /usr/bin/screen -S debian1 -d -m kvm -hda debian1.qcow2 -m 512 -net nic,macaddr=<mac_address> -net tap,script=/etc/qemu-ifup \
|
||||
-curses -k fr -monitor tcp:127.0.0.1:<port>,server,nowait
|
||||
~~~
|
||||
|
|
@ -1024,11 +1027,12 @@ Il suffit ensuite de la retirer du bridge :
|
|||
|
||||
Utiliser autant que possible les drivers virtio (disque et réseau) sur les invités le supportant.
|
||||
|
||||
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" :
|
||||
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` :
|
||||
|
||||
~~~
|
||||
<driver name='qemu' type='raw' cache='none'/>
|
||||
~~~
|
||||
|
||||
Et 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.
|
||||
|
|
|
|||
|
|
@ -234,7 +234,7 @@ ln -s /usr/share/munin/plugins/postgres_users /etc/munin/plugins/
|
|||
ln -s /usr/share/munin/plugins/postgres_xlog /etc/munin/plugins/
|
||||
~~~
|
||||
|
||||
Pour les plugins wildcard finissant par `_` ajoutez `ALL` pour monitorer toutes les BDD :
|
||||
Pour les plugins wildcard finissant par _ ajoutez `ALL` pour monitorer toutes les BDD :
|
||||
|
||||
~~~
|
||||
ln -s /usr/share/munin/plugins/postgres_cache_ /etc/munin/plugins/postgres_cache_ALL
|
||||
|
|
|
|||
Loading…
Reference in a new issue