QEMU/KVM (Libvirt)

KVM c'est la simplicité, l'intégration native au kernel Linux et surtout la performance ! Oh et c'est légèrement un peu beaucoup utilisé chez les clouds providers.

Guides d'installation

Guides d'installation

Installer un hôte de virtualisation QEMU/KVM (Fedora Server 31)

fedora27server.jpg

Fonctionnement de QEMU/KVM

KVM (Kernel-based Virtual Machine) est une technologie de virtualisation Open Source intégrée à Linux. Avec KVM, vous pouvez transformer Linux en un hyperviseur qui permet à une machine hôte d'exécuter plusieurs environnements virtuels isolés, appelés invités ou machines virtuelles.

KVM convertit le noyau Linux en un hyperviseur de type 1. Pour exécuter des machines virtuelles, tous les hyperviseurs ont besoin de certains composants au niveau du système d'exploitation : gestionnaire de mémoire, planificateur de processus, pile d'entrées/sorties (E/S), pilotes de périphériques, gestionnaire de la sécurité, pile réseau, etc. La technologie KVM comprend tous ces composants, car elle est intégrée au noyau Linux. Chaque machine virtuelle est mise en œuvre en tant que processus Linux standard. Elle est gérée par le planificateur Linux standard et dispose de matériel de virtualisation dédié (carte réseau, carte graphique, un ou plusieurs processeurs, mémoire, disques).

Kernel-based_Virtual_Machine.png

Installation d'un hôte de virtualisation QEMU/KVM (avec Libvirt)
# Installer les packages nécessaires
dnf install -y qemu-kvm libvirt python-libvirt libguestfs-tools-c virt-install virt-v2v virt-top tuned cockpit cockpit-machines

# Supprimer le dashboard (inutile pour un hôte de virtualisation)
dnf remove -y cockpit-dashboard
systemctl enable --now libvirtd
virsh net-destroy default

virsh net-undefine default

systemctl restart libvirtd
# Ajouter un règle dans le firewall pour autoriser le service Cockpit (port 9090)
firewall-cmd --add-service=cockpit --permanent
firewall-cmd --reload

# Démarrer le service pour Cockpit
systemctl enable --now cockpit.socket
# Démarrer le service tuned
systemctl enable --now tuned

# Choisir le profil adapté à la virtualisation
tuned-adm profile virtual-host

kvm1.png

kvm2.png

 

Guides d'installation

Création d'un bridge pour QEMU/KVM avec NetworkManager et Libvirt

Afin de pouvoir bénéficier d'une connectivité sur un réseau d'entreprise (avec DHCP, DNS...etc), il est nécessaire que les machines virtuelles puissent "parler" sur le réseau. Par défaut, Libvirt crée un réseau de type NAT par défaut, ce qui ne convient pas l'usage décrit précédemment.

Si vous disposez d'un système GNU/Linux disposant de NetworkManager (ex: Fedora Server), il est tout à fait possible de créer un bridge qui va permettre aux machines virtuelles de communiquer sur le réseau de l'entreprise ou votre réseau home. Un bridge Linux est simplement une implémentation de switching Layer 2 au niveau du noyau Linux, il va faire le même travail qu'un vSwitch sur VMware ou un Hyper-V Switch.

Les noms des interfaces sont à adapter en fonction de votre configuration !

sudo nmcli con add ifname virbr1 type bridge con-name virbr1
sudo nmcli con add type bridge-slave ifname enp3s0 master virbr1
sudo nmcli con down "enp3s0"
sudo nmcli con up virbr1

Une fois ces étapes accomplies, vous devriez voir votre bridge fonctionnel (ne pas hésiter à redémarrer le service NetworkManager) :

libvirt.png

Il est également intéressant de déclarer ce bridge à Libvirt pour pouvoir l'utiliser plus facilement avec ce dernier :

<network>
  <name>virbr1</name>
  <forward mode="bridge"/>
  <bridge name="virbr1" />
</network>

Pour éditer des configurations réseaux (IP statique notamment), cela se fait au niveau du bridge ! Pensez à bien flush la configuration de votre interface physique.

That's it !

Guides d'optimisations

Guides d'optimisations

Réduire l'utilisation CPU hôte pour un invité Windows

virsh edit <votre nom de domaine QEMU>
 <clock offset='localtime'>
   <timer name='rtc' tickpolicy='catchup'/>
   <timer name='pit' tickpolicy='delay'/>
   <timer name='hpet' present='no'/>
   <timer name='hypervclock' present='yes'/>
 </clock>
 <clock offset='localtime'>
   <timer name='hpet' present='yes'/>
   <timer name='hypervclock' present='yes'/>
 </clock>

 

Guides d'optimisations

Choisir le bon hardware virtuel pour le bon cas d'usage (WIP)

L'utilisation de QEMU/KVM permet de pouvoir configurer de manière granulaire les machines virtuelles (merci QEMU). Cependant, pour obtenir les meilleures performances possibles, il est important d'appliquer les bons paramétrages.

Les images utilisées ici sont souvent issues du logiciel Virt-Manager.

Comprendre le hardware virtuel sous QEMU/KVM

Le processeur virtuel (vCPU)

Il existe un certain nombre d'option pour la configuration vCPU de vos machines virtuelles QEMU/KVM.

qemu01.png

Le premier bloc "CPU" permet de configurer l'ajout de vCPU à chaud. C'est une feature un peu controversée, elle peut avoir son utilité dans certaines applications. Il est préférable de définir une allocation de vCPU fixe.

Le second bloc "Configuration" permet de configurer le mode CPU, c'est à dire les instructions CPU à émuler. Il existe 3 modes :

Le dernier bloc "Topologie" permet de configurer la topologie CPU, à savoir configurer le nombre de sockets CPU, de cores mais aussi les threads par core (ce qui "ressemble" à un hyper-threading). Si vous voulez pousser les performances au maximum, la best-practice est de toujours configurer X sockets avec 1 core. En pratique cela signifie, que si vous voulez 4 vCPU sur votre machine virtuelle, il faut donc configurer 4 sockets avec 1 core chacun. Cette configuration peut cependant générer des soucis avec certaines licences logicielles, dans ces cas là, le schéma adapté sera donc 1 socket avec X cores.

Concernant l'allocation de vCPU sur une machine virtuelle, rien ne sert de sur-allouer des vCPU. Ce n'est pas parce qu'une machine virtuelle dispose de 2 vCPU et une autre 8 vCPU que cette dernière sera plus efficace, au contraire dans beaucoup de workloads communes. En effet, plus le nombre de vCPU alloué aux machines virtuelles, plus le scheduler CPU de votre hyperviseur devra partager les ressources CPU entre les différents threads vCPU, ce qui peut réduire les performances CPU globales. Bien évidemment, rien n'interdit d'utiliser un nombre élevé de vCPU, mais il faut dimensionner correctement l'allocation de vCPU en fonction de l'application qui est virtualisée.

La mémoire vive (RAM)

Pour configurer la mémoire RAM sur QEMU/KVM, rien de sorcier. La seule configuration est simplement un intervalle, qui peut être utilisé pour ajouter de la RAM à chaud.

qemu02.png

Le stockage

La configuration du contrôleur du stockage est la configuration la plus importante avec la configuration du contrôleur. Le choix du bon contrôleur de stockage virtuel va permettre de disposer d'une machine virtuelle performante. Il est évident également que le stockage physique sur lequel repose l'hyperviseur est d'autant plus important.

qemu03.png

Choix du format d'image disque

La première configuration à faire, c'est de choisir entre les deux formats d'image disque pour votre machine virtuelle : QCOW2 ou RAW. QEMU sait lire d'autres formats comme le VMDK ou le VDI, mais les deux formats précédents sont à privilégier.

RAW : c'est un format d'image disque brut, c'est un fichier flat qui contient toutes les données de la machine virtuelle, ça marche comme le format RAW en photographie. De par sa nature, ce format d'image disque est le plus performant des deux en terme d'accès disque et de débit, mais c'est un format d'image dit "thick", c'est à dire qu'une image de machine virtuelle de 10Go occupera un espace de 10Go sur le disque dur. De plus, les snapshots sur ce format ne semble pas possible.

QCOW2 : c'est un format d'image disque plus élaboré que RAW. Ce format de disque de part sa complexité accrue (utilisation de couches pour stocker des méta-données) est plus lent que le format RAW mais apporte une flexibilité supplémentaire en étant un format "thin". Le format QCOW2 découple la couche de stockage physique de la couche virtuelle en ajoutant un mappage entre les blocs logiques et physiques. Cela permet donc à QCOW2 de supporter les snapshots à froid et à chaud.

Le choix du format d'image disque dépend du type de workload de la machine virtuelle. Les applications nécessitant des I/O importants mais aussi une latence plus faible comme les bases de données doivent s'orienter vers le format RAW. Dans beaucoup d'autres cas, le format QCOW2 peut suffire.

Choix du contrôleur disque virtuel

La seconde configuration concerne le choix du contrôleur de stockage. De grands écarts de performances peuvent subvenir entre les différents contrôleurs. De plus, il est important de souligner que ce sont des contrôleurs émulés ! Il existe deux catégories de contrôleurs disques, les contrôleurs émulés et les contrôleurs para-virtualisés.

Les contrôleurs émulés sont :

IDE : c'est un contrôleur disque dépassé, il est pratique de part son support universel sur tous les systèmes d’exploitation, mais son usage doit rester limiter à l'hébergement d'un système "legacy", ses performances sont médiocres.

SATA : le contrôleur SATA de part son design est un contrôleur disque plus performant que l'IDE. Son usage concerne également l'hébergement d'un système legacy qui ne supporterait pas les contrôleurs para-virtualisés récents ou en tant que CDROM d'installation.

SCSI : dans son format émulé standard, c'est le contrôleur disque le plus efficace des trois.

Les contrôleurs para-virtualisés sont des contrôleurs disque virtuels qui ne sont pas une émulation proprement dite d'équipements qui se trouvent sur le marché, mais une interface minimale entre l'invité et l'hyperviseur pour s'échanger des données.

Le gros avantage de ces contrôleurs para-virtualisés sont leurs performances (overhead fortement réduit), la réduction du nombre de drivers nécessaires dans le noyau des VM (on utilise VirtIO pour des machines virtuelles c'est tout). Le seul inconvénient réside dans le fait qu'il faille un driver dédié. Pour les invités Linux, ces drivers se trouvent dans le noyau nativement, pour Windows, il faut installer les drivers pour pouvoir les utiliser.

Pour QEMU/KVM, on utilise les drivers VirtIO pour le réseau et le stockage. Il existe deux types de contrôleurs VirtIO pour le stockage :

VirtIO BLK : c'est le format le plus ancien pour VirtIO, mais aussi le plus simple. Il est plus limité en features que VirtIO SCSI mais s'avère tout aussi efficace et performant.

VirtIO SCSI : c'est le nouveau format de contrôleur de stockage pour VirtIO visant à remplacer VirtIO BLK. Il est plus complexe que son prédécesseur du au support de davantage de features comme le support d'un plus grand nombre de disque connecté ou le support d'options pour SSD comme TRIM.

Les deux formats se valent, le format BLK pourra s'avérer un peu plus rapide de part son design simple, si des features plus évolués pour le support d'options pour SSD ou un grand nombre de disques attachés à la machine virtuelle sont nécessaires, VirtIO SCSI sera à privilégier.

Le mécanisme de cache

qemu04.png

Afin d’accroître les performances des machines virtuelles, des mécanismes de caching sont disponibles avec QEMU. Le réglage du cache du disque aura un impact sur la façon dont le système hôte avertira les systèmes invités de la fin de l'écriture en bloc. La valeur par défaut "none" signifie "pas de cache" et donc que le système invité sera averti qu'une écriture est terminée lorsque chaque bloc atteint la file d'attente d'écriture du stockage physique. Ceci assure un bon équilibre entre la sécurité et la vitesse.

Mais il existe d'autres mécanismes de cache :

Mode Notes
none Performances équilibrées, sécurité des données (meilleur en écriture)
writethrough Performances équilibrées, sécurité des données (meilleur en lecture)
writeback Très rapide, mais risque de perte de données en cas de coupure brutale d'alimentation
directsync Le mode de cache le plus secure, mais aussi le plus lent
unsafe Aucune sécurité, rapidité absolue :p

Le mode d'E/S

Par défaut, toutes les requêtes d'I/O sont traitées dans le thread principal de QEMU. Les machines virtuelles avec plus d'un CPU virtuel exécutant des charges de travail intensives en I/O peuvent être impactés sur les performances. L'utilisation de threads séparés pour la gestion des événements d'I/O peut améliorer considérablement le débit des disques virtuels.

Native :

Threads :

Le réseau (NIC)

L'affichage (VNC/SPICE)

Les canaux de communications

Configurations conseillées pour des cas d'usage précis

 

WORK IN PROGRESS


Je finirai un jour quand j'aurai de nouveau la foi :p