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.
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 :
-
host-model - c'est le mode par défaut avec libvirt. Il identifie le modèle de CPU dans le fichier /usr/share/libvirt/cpu_map.xml qui correspond le mieux à l'hôte, et demande des flags CPU supplémentaires pour compléter la correspondance. Cette configuration offre un maximum de fonctionnalités et de performances et maintient une bonne fiabilité et compatibilité si l'invité est migré vers un autre hôte avec des CPU hôtes légèrement différents.
-
host-passthrough : c'est le mode de performances maximum. libvirt indique à KVM de passer à travers le processeur hôte sans aucune modification. La différence par rapport au modèle hôte, au lieu de se contenter de juste faire correspondre les flags, chaque détail du CPU hôte est adapté. Cela donne les meilleures performances, et peut être important pour certaines applications qui vérifient les détails des processeurs de bas niveau, mais cela a un coût par rapport à la migration. Il faut impérativement le même CPU physique entre les deux hôtes sur lesquels la machine virtuelle est migrée.
- custom : le mode le moins performant des trois. QEMU va permettre d'émuler une gamme de CPU spécifique pour la machine virtuelle, comme par exemple un CPU de gamme Haswell, IvyBridge ou encore Opteron chez AMD . Ce mode peut avoir son utilité pour des applications spécifiques mais n'est pas recommandé pour des applications nécessitant de bonnes performances CPU.
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.
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.
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
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
No Comments