2.6. Recommandations pour RHEL KVM sur les hôtes IBM zSystems

Avec plusieurs unités centrales virtuelles, vous pouvez transférer des paquets en parallèle si vous prévoyez plusieurs files d'attente pour les paquets entrants et sortants. Utilisez l'attribut queues de l'élément driver pour configurer plusieurs files d'attente. Spécifiez un nombre entier d'au moins 2 qui ne dépasse pas le nombre de CPU virtuels du serveur virtuel.

L'exemple de spécification suivant configure deux files d'attente d'entrée et de sortie pour une interface réseau :

<interface type="direct">
    <source network="net01"/>
    <model type="virtio"/>
    <driver ... queues="2"/>
</interface>

Les files d'attente multiples sont conçues pour améliorer les performances d'une interface réseau, mais elles utilisent également des ressources de mémoire et d'unité centrale. Commencez par définir deux files d'attente pour les interfaces très fréquentées. Essayez ensuite de définir deux files d'attente pour les interfaces à faible trafic ou plus de deux files d'attente pour les interfaces très fréquentées.

Pour que les périphériques de blocs virtuels utilisent des threads d'E/S, vous devez configurer un ou plusieurs threads d'E/S pour le serveur virtuel et chaque périphérique de bloc virtuel doit utiliser l'un de ces threads d'E/S.

L'exemple suivant indique que <iothreads>3</iothreads> doit configurer trois threads d'E/S, avec les ID de threads décimaux consécutifs 1, 2 et 3. Le paramètre iothread="2" spécifie l'élément du pilote de l'unité de disque qui doit utiliser le fil d'exécution d'E/S avec l'ID 2.

...
<domain>
 	<iothreads>3</iothreads>1
  	 ...
    	<devices>
       ...
          <disk type="block" device="disk">2
<driver ... iothread="2"/>
    </disk>
       ...
    	</devices>
   ...
</domain>

Les threads peuvent augmenter les performances des opérations d'E/S pour les périphériques de disque, mais ils utilisent également de la mémoire et des ressources de l'unité centrale. Vous pouvez configurer plusieurs périphériques pour qu'ils utilisent le même thread. Le meilleur mappage des threads aux périphériques dépend des ressources disponibles et de la charge de travail.

Commencez par un petit nombre de fils d'entrée/sortie. Souvent, un seul thread d'E/S pour tous les périphériques de disque est suffisant. Ne configurez pas plus de threads que le nombre de CPU virtuels et ne configurez pas de threads inactifs.

Vous pouvez utiliser la commande virsh iothreadadd pour ajouter des threads d'E/S avec des ID de threads spécifiques à un serveur virtuel en cours d'exécution.

Ne configurez les périphériques SCSI virtuels que si vous avez besoin d'adresser le périphérique par le biais d'interfaces spécifiques SCSI. Configurez l'espace disque en tant que périphériques de bloc virtuels plutôt qu'en tant que périphériques SCSI virtuels, indépendamment de la sauvegarde sur l'hôte.

Cependant, vous pouvez avoir besoin d'interfaces spécifiques SCSI pour :

Configurez vos périphériques de disque pour que la mise en cache soit effectuée par l'invité et non par l'hôte.

Assurez-vous que l'élément pilote de l'unité de disque inclut les paramètres cache="none" et io="native".

<disk type="block" device="disk">
    <driver name="qemu" type="raw" cache="none" io="native" iothread="1"/>
...
</disk>

À moins que vous n'ayez besoin d'une taille de mémoire dynamique, ne définissez pas de périphérique de ballon de mémoire et assurez-vous que libvirt n'en crée pas un pour vous. Incluez le paramètre memballoon en tant qu'enfant de l'élément devices dans votre fichier XML de configuration de domaine.

Le paramètre kernel.sched_migration_cost_ns spécifie un intervalle de temps en nanosecondes. Après la dernière exécution d'une tâche, le cache de l'unité centrale est considéré comme ayant un contenu utile jusqu'à l'expiration de cet intervalle. L'augmentation de cet intervalle permet de réduire le nombre de migrations de tâches. La valeur par défaut est 500000 ns.

Si le temps d'inactivité du CPU est plus élevé que prévu lorsqu'il y a des processus exécutables, essayez de réduire cet intervalle. Si les tâches passent trop souvent d'un CPU ou d'un nœud à l'autre, essayez de l'augmenter.

Pour définir dynamiquement l'intervalle à 60000 ns, entrez la commande suivante :

# sysctl kernel.sched_migration_cost_ns=60000

Pour modifier de façon permanente la valeur de 60000 ns, ajoutez l'entrée suivante à /etc/sysctl.conf:

kernel.sched_migration_cost_ns=60000

Ce paramètre persiste lors des redémarrages de l'hôte.

Lorsqu'un processeur virtuel est inactif, KVM recherche les conditions de réveil du processeur virtuel avant d'allouer la ressource hôte. Vous pouvez spécifier l'intervalle de temps pendant lequel l'interrogation a lieu dans sysfs à l'adresse /sys/module/kvm/parameters/halt_poll_ns. Pendant la durée spécifiée, l'interrogation réduit la latence de réveil de l'unité centrale virtuelle au détriment de l'utilisation des ressources. En fonction de la charge de travail, une durée d'interrogation plus longue ou plus courte peut être bénéfique. L'intervalle de temps est spécifié en nanosecondes. La valeur par défaut est de 50000 ns.