par Dans cette série d’articles, nous allons étudier un peu KVM, il parait que c’est à la mode !
Un ami m’a dit il y a quelque temps : « tu devrais tester, c’est pas mal »…
A l’occasion du projet de nouveau serveur V2020 en Debian 10, je me suis alors souvenu que j’avais ceci sur la liste des nombreuses choses à tester. Ce fut donc l’occasion de m’y mettre.
Pour faire ce que je fais avec Xen (à savoir créer une image en une commande), j’ai du rester motivé car ce n’est pas aussi « tout en un ».
J’ai donc bien défriché et vous propose un « petit tour » de KVM.
I – La virtualisation
Je ne fais pas faire un cours magistral sur la virtualisation, il y a pléthore de ressources à ce sujet sur le grand internet, mais pour résumer, on trouve deux types d’hyperviseurs :
– Type 1, ou « bare metal » : l’hyperviseur est l’OS de la machine, directement sur le hardware.
Des noms ? KVM, Xen, Vmware ESXi, Hyper-V, Xen-Server (la version « Citrix de Xen »).
– Type 2, ou « hosted » : l’hyperviseur est un logiciel qui tourne sur l’OS de la machine.
Encore des noms ? Vmware Workstation, Qemu, Virtual Box. Bref, un logiciel installé sur un OS.
Ceci dit, de nos jours, type I, type II, cela devient de plus en plus confus… On va voir pourquoi avec KVM, et d’ailleurs pour être plus précis, on devrait dire KVM/Qemu.
Qemu, techniquement, c’est du type II. C’est un soft qui tourne sur l’OS et qui permet d’émuler une machine. Cela permet de faire tourner par exemple, une archi ARM sur un host en X86, bref un émulateur tout à fait classique.
KVM (Kernel-based Virtual Machine), c’est un module du noyau Linux (intégré depuis la 2.6.20) qui permet de transformer Linux en hyperviseur.
C’est bien beau tout ça, mais ça interagit comment ?
Et bien avec l’aide de Libvirt, une API de virtualisation. Cette API open source peut être utilisée avec d’autres solutions de virtualisation, mais on la retrouve le plus souvent associée avec KVM/Qemu.
Elle va faire « le lien » entre tout ceci et propose également des commandes pour faciliter la manipulations des VMS (les lignes de commandes Qemu brutes sont imbitables…)
Et y’a une astuce, c’est que ce trio malicieux peut bosser comme un hyperviseur de type I si l’architecture que doit émuler Qemu est identique à l’architecture de l’hôte. Pour résumer (grossièrement), il n’émule plus les instructions processeurs, vu qu’il peut les passer directement, d’où performances accrues, etc..
Impeccable !
Ceci dit, il faut s’assurer avant que votre processeur hôte supporte bien les instructions de virtualisation.
Ceci avec la commande
# cat /proc/cpuinfo
Dans les flags, vous devez voir vmx (Intel) ou svm (AMD)
Pour voir facilement :
# egrep --color 'vmx|svm' /proc/cpuinfo
Si ils n’y sont pas, vous pourrez quand même virtualiser, mais Qemu restera de « type 2 » et les performances ne seront pas extraordinaires.
Petit truc aussi au passage :
A l’occasion d’un cat /proc/cpuinfo sur un Xen, j’ai constaté que le flag n’apparaissait pas. Inquiet sur le bon fonctionnement du proc, c’est en fait normal, il faut taper :
# cat /sys/hypervisor/properties/capabilities
Pour le voir sous la forme :
hvm-X.0-x86_32 hvm-X.0-x86_32p hvm-X.0-x86_64
Bref, voila pour la petit introduction sur KVM et les hyperviseurs en général.
J’ai fait court et concis, n’hésitez pas à poser des questions si quelque chose n’est pas clair.
II – Sommaire
I – Installation et préparatifs réseaux
II – Création d’une VM à partir d’une ISO
V – Création d’une VM avec debootstrap, méthode « simple »
VI – Préparation d’un template pour les VMs
VII – Création d’une VM à partir du template
VIII – Scriptons, scriptons, petits patapons
IX – Aparté sur dmsetup
X – Modification des ressources d’une VM
XI – Agrandissement et réduction du disque d’une VM
