evolix/wiki
22
0
Fork 0
Code Releases Activity

relecture

Browse source
This commit is contained in:
Gregory Colpart 2023-07-28 21:39:35 +02:00
parent d012c855fe
commit 16defe31b5
1 changed files with 25 additions and 22 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

47
HowtoKVM.md
View file

@ -1,8 +1,12 @@
# Howto KVM ---
categories: virtualisation
title: Howto KVM
...
* Documentation KVM : <http://www.linux-kvm.org/page/Documents> * Documentation KVM : <http://www.linux-kvm.org/page/Documents>
* Documentation libvirt : <https://libvirt.org/docs.html> * Documentation libvirt : <https://libvirt.org/docs.html>
* virsh(1) : <https://manpages.debian.org/jessie/libvirt-clients/virsh.1.en.html> * virsh(1) : <https://manpages.debian.org/bullseye/libvirt-clients/virsh.1.en.html>
* Statut de cette page : prod / bullseye
[KVM](http://www.linux-kvm.org/) est une technologie de virtualisation intégrée au noyau Linux. [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. On l'utilise avec [libvirt](https://libvirt.org), une surcouche qui facilite l'utilisation de la virtualisation.
@ -17,18 +21,18 @@ Pour installer un hyperviseur (machine capable de faire tourner des machines vir
~~~ ~~~
$ kvm --version $ kvm --version
QEMU emulator version 2.8.1(Debian 1:2.8+dfsg-6+deb9u4) QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-11+deb11u2)
Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
$ virsh -V $ virsh -V
Virsh command line tool of libvirt 3.0.0 Virsh command line tool of libvirt 7.0.0
See web site at http://libvirt.org/ See web site at https://libvirt.org/
Compiled with support for: Compiled with support for:
Hypervisors: QEMU/KVM LXC UML Xen LibXL OpenVZ VMware VirtualBox Test Hypervisors: QEMU/KVM LXC LibXL OpenVZ VMware VirtualBox ESX Test
Networking: Remote Network Bridging Interface netcf Nwfilter VirtualPort Networking: Remote Network Bridging Interface netcf Nwfilter
Storage: Dir Disk Filesystem SCSI Multipath iSCSI LVM RBD Sheepdog ZFS Storage: Dir Disk Filesystem SCSI Multipath iSCSI LVM RBD Gluster ZFS
Miscellaneous: Daemon Nodedev AppArmor SELinux Secrets Debug DTrace Readline Modular Miscellaneous: Daemon Nodedev AppArmor SELinux Secrets Debug DTrace Readline
~~~ ~~~
Installation de virt-manager : Installation de virt-manager :
@ -86,7 +90,7 @@ Le CPU pinning permet d’attacher un processus à un CPU particulier. La machin
Pour choisir les CPU, on peut s’appuyer sur les informations sur la topologie du processeur avec la commande `lspcu`. Pour choisir les CPU, on peut s’appuyer sur les informations sur la topologie du processeur avec la commande `lspcu`.
``` ~~~
$ lscpu -e=cpu,core,cache $ lscpu -e=cpu,core,cache
CPU CORE L1d:L1i:L2:L3 CPU CORE L1d:L1i:L2:L3
0 0 0:0:0:0 0 0 0:0:0:0
@ -105,11 +109,11 @@ CPU CORE L1d:L1i:L2:L3
13 5 5:5:5:1 13 5 5:5:5:1
14 6 6:6:6:1 14 6 6:6:6:1
15 7 7:7:7:1 15 7 7:7:7:1
``` ~~~
On voit ici que les CPU 4 et 12 (1ère colonne) sont dans le même _core_ (2ème colonne). Les CPU 4 à 7 et 12 à 15 partagent le même cache L3 (3ème colonne, dernier caractère). La configuration XML ci-dessous associe à la machine virtuelle les CPU 4 à 7 et 12 à 15. On voit ici que les CPU 4 et 12 (1ère colonne) sont dans le même _core_ (2ème colonne). Les CPU 4 à 7 et 12 à 15 partagent le même cache L3 (3ème colonne, dernier caractère). La configuration XML ci-dessous associe à la machine virtuelle les CPU 4 à 7 et 12 à 15.
```xml ~~~{.xml}
<domain> <domain>
[…] […]
<vcpu placement='static'>8</vcpu> <vcpu placement='static'>8</vcpu>
@ -124,7 +128,7 @@ On voit ici que les CPU 4 et 12 (1ère colonne) sont dans le même _core_ (2ème
<vcpupin vcpu='7' cpuset='15'/> <vcpupin vcpu='7' cpuset='15'/>
</cputune> </cputune>
[…] […]
``` ~~~
La machine virtuelle ne pourra utiliser que ces processur, mais ça n’empêchera pas des processus de l’hôte de les utiliser aussi. Pour empêcher ça, il faudra isoler les CPU. La machine virtuelle ne pourra utiliser que ces processur, mais ça n’empêchera pas des processus de l’hôte de les utiliser aussi. Pour empêcher ça, il faudra isoler les CPU.
@ -1181,14 +1185,14 @@ tic $ virsh domrename <old DOM name> <new DOM name>
Pour Debian 7 et inférieur, la commande `virsh domrename` n'existe pas. On peut alors contourner de cette manière : Pour Debian 7 et inférieur, la commande `virsh domrename` n'existe pas. On peut alors contourner de cette manière :
``` ~~~
# cd /etc/libvirt/qemu/ # cd /etc/libvirt/qemu/
# cp <old DOM name>.xml <new DOM name>.xml # cp <old DOM name>.xml <new DOM name>.xml
# virsh undefine <old DOM name> # virsh undefine <old DOM name>
# vim <new DOM name>.xml # vim <new DOM name>.xml
# : faire les modifications de l'étape 8 ainsi que le changement de nom dans la balise <name> # : faire les modifications de l'étape 8 ainsi que le changement de nom dans la balise <name>
# virsh define <new DOM name>.xml # virsh define <new DOM name>.xml
``` ~~~
8. On ajuste les chemins des volumes dans la définition de la VM 8. On ajuste les chemins des volumes dans la définition de la VM
@ -1549,7 +1553,7 @@ Cela ne résoud pas forcément le problème.
Parfois suite à la commande virt-install on n'a toujours pas de CD dans la définition de la VM. Un bloc fonctionnel ressemble à : Parfois suite à la commande virt-install on n'a toujours pas de CD dans la définition de la VM. Un bloc fonctionnel ressemble à :
~~~ ~~~{.xml}
<disk type='file' device='cdrom'> <disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/> <driver name='qemu' type='raw'/>
<source file='/home/iso/install61.iso'/> <source file='/home/iso/install61.iso'/>
@ -1557,18 +1561,17 @@ Parfois suite à la commande virt-install on n'a toujours pas de CD dans la déf
<readonly/> <readonly/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk> </disk>
~~~ ~~~
Il faudra possiblement rajouter Il faudra possiblement rajouter
~~~ ~~~{.xml}
<boot dev='cdrom'/> <boot dev='cdrom'/>
~~~ ~~~
avant `hd` dans le block avant `hd` dans le block
~~~ ~~~{.xml}
<os> <os>
<type arch='x86_64' machine='pc-0.12'>hvm</type> <type arch='x86_64' machine='pc-0.12'>hvm</type>
<boot dev='hd'/> <boot dev='hd'/>
@ -1581,7 +1584,7 @@ afin de bien booter sur le CD.
Si on veut que le vnc mis en place utilise une disposition de clavier qwerty Si on veut que le vnc mis en place utilise une disposition de clavier qwerty
~~~ ~~~{.xml}
<graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1' keymap='en-us'> <graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1' keymap='en-us'>
~~~ ~~~
@ -1603,7 +1606,7 @@ Sur certains hyperviseurs et certains CPU, il est possible que le mode CPU `host
Il faut donc, dans le fichier xml, mettre le modèle de CPU de l'hyperviseur correspondant, exemple avec un modèle Sandy Bridge : Il faut donc, dans le fichier xml, mettre le modèle de CPU de l'hyperviseur correspondant, exemple avec un modèle Sandy Bridge :
~~~ ~~~{.xml}
<cpu mode='custom' match='exact'> <cpu mode='custom' match='exact'>
<model fallback='allow'>SandyBridge</model> <model fallback='allow'>SandyBridge</model>
</cpu> </cpu>