Dans une configuration où Debian 9.3 est utilisé en hyperviseur pour supporter un invité Debian 9.4, j’ai remarqué un bug dans la gestion du system load (1 min) qui est le plus souvent à 1.
TL ; DR. Le manque d’entropie de la VM engendrait un fort system load. Ce manque s’explique par la présence d’un périphérique virtio_rng branché sur /dev/random. Ce périphérique est bloquant donc lorsque la VM avait besoin d’entropie et qu’il était à sec, la charge système augmentait. J’opte pour hwrng sur /dev/urandom à la place de /dev/random.
Sommaire
Symptômes anormaux
La machine invitée a un system load qui augmente en asymptote jusqu’à 1.00. Cycliquement, la valeur peut redescendre pour remonter à 1.
Que la VM ait 1 ou 2 vCPU le résultat est le même. Elle est idle coté disque, CPU et réseau d’où mon incompréhension.
System load (1 min) – des exponentielles dans tous les sens
Le tracé ci-dessus comporte une multitude d’évolutions de type exponentielle. On croit voir des charges-décharges de condensateur mais non, ce n’est qu’un system load (1 min). Chaque créneau comporte une trentaine d’échantillons de mesure donc ce n’est pas un biais du au tracé.
Je n’ai pas déterminé si la machine virtuelle est réellement chargée, ou bien si c’est l’affichage de system load qui est faux.
Contexte du bug
Le bug a été constaté sur deux serveurs hyperviseurs faisant tourner chacun une VM identique dont l’image disque a été copiée.
Serveur hyperviseur (system load normal)
- OS : Debian 9.3 noyau Linux 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23)
- Hyperviseur : qemu-kvm 1:2.8+dfsg-6+deb9u3
- CPU : Haswell Xeon E5-2620v3 (microcode 0x3a) ou Xeon E5-2603v3 (microcode 0x3a)
- RAM : DDR4 ECC LRDIMM ou RDIMM
- HDD : SSD NVMe Samsung SM951/SM961
Machine invitée (system load anormal)
- OS : Debian 9.4 noyau Linux 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) et également Debian 9.4 Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19) ou encore Linux 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23)
- HDD : image disque qcow2 via bus SCSI/virtio et disque SCSI (trim unmap)
- vCPU : 1 ou 2
- RAM : 12 Go dont 9 occupés
- Périphériques : SPICE, hwrng, tablette, souris, clavier
Pistes pour ce bug
Je remarque qu’après mise à jour de Debian 9.3 vers 9.4 coté hyperviseur, ce phénomène anormal est fortement atténué. Chez moi cela a suffi à retrouver un system load normal coté invité (Debian 9.4 avec même version noyau) la plupart du temps. Des rechutes temporaires apparaissent dans lesquelles le system load s’affole pendant quelques heures. Lors de la mise à jour le noyau hyperviseur est passé à la version Linux 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) et qemu-kvm est passé à 1:2.8+dfsg-6+deb9u4.
Je constate que le fichier /proc/cpuinfo évolue avec ce nouveau noyau. On passe d’une ligne « bugs » vide à bugs : cpu_meltdown spectre_v1 spectre_v2. La version 4.9.88-1+deb9u1 est en effet la première à corriger Spectre v1, Spectre v2 et Meltdown. Mais ce changement entre les noyaux n’est pas responsable du problème puisque le symptôme apparait également avec un 4.9.65-3+deb9u1 sur Debian 9.4 pourtant identique en version à celui de l’hyperviseur Debian 9.3. Le noyau 4.9.30-2+deb9u5 coté invité Debian 9.4 ne donne pas de meilleurs résultats.
Plus précisément la version de qemu-kvm coté hyperviseur pourrait impacter le problème rencontré. Entre Debian 9.3 et Debian 9.4, la mise à jour deb9u4 fut très importante en modifications de sécurité notamment liées à Spectre. Reste à trouver coté invité le composant qui serait alors incompatible avec cette dernière mouture de qemu-kvm.
Conclusion
Pour finir, c’est le processus [hwrng] des machines invités qui était responsable du comportement. Ce processus est lancé par le noyau car un périphérique virtuel RNG (virtio_rng) a été configuré grâce à virt-manager sur l’hyperviseur pour qu’il partage son entropie aux VM. Le vrai problème n’est pas tant d’utiliser hwrng, mais plutôt que virt-manager l’a connecté au /dev/random (bloquant) de l’hyperviseur au lieu de /dev/urandom (non bloquant) ! Il semblerait que je ne sois pas le seul à en avoir fait les frais.
L’utilisation du programme haveged permet de remplir continuellement le pool d’entropie mais je préfère opter naturellement pour le périphérique urandom, plutôt que d’encourager l’utilisation à tort de /dev/random.
Donc : lorsque la VM manque d’entropie et que ses processus en attendent, son system load peut augmenter anormalement. Et la forme du graphique ci-dessus peut différer selon la version du kernel invité.
