Le bug décrit ci-après engendre un freeze de la machine virtuelle dans certaines conditions d’utilisation des images disques. N’ayant pas trouvé la solution exacte sur internet, je vais tenter de décrire le contexte entier.

Symptômes anormaux

Le symptôme de ce bug est un freeze de la VM alors qu’un traitement de lecture-écriture aléatoire est en cours (exemple : nombreux INSERT MySQL de données issues de téléchargements) ou lorsqu’une tâche d’écriture est en cours (exemple : synchronisation portefeuille Bitcoin).

La machine virtuelle n°1 peut parfois répondre au ping et montrer des ports ouverts à nmap, mais on ne peut pas s’y connecter par SSH ni par la connexion VNC gérée par KVM.
La machine virtuelle n°2 est figée sur son environnement graphique et on remarque que l’heure affichée dans la barre des tâches de Xfce est figée également.

Lorsque le dysfonctionnement est en train de se produire, on constate une lenteur anormale et l’impossibilité de vider le cache disque de la VM par la commande sync. Il se passe plusieurs dizaines de minutes avant sur le ralentissement ne se transforme en freeze. Coté hyperviseur, les disques sont presque idle.

A tout moment, je remarque un faible débit disque des VM (commande hdparm -t) par rapport aux possibilités du matériel (86 MB/sec contre 1025 MB/sec coté hyperviseur). L’extinction de VM adjacentes remonte les débits même si elles étaient idle.

La seule solution est d’éteindre brutalement la machine virtuelle ( virsh destroy vm ) jusqu’à ce que le freeze survienne à nouveau.

Logs : rien d’anormal ni coté VM, ni coté hyperviseur.

Contexte du bug

Serveur hyperviseur (se comporte normalement) :

  • OS : Debian 8.6 noyau Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2
  • Hyperviseur : qemu-kvm 1:2.1+dfsg-12+deb8u6
  • Châssis : HP DL360 Gen9 acheté en 2016
  • CPU : Haswell Xeon E5-2603 v3 (microcode 0x2b)
  • HDD : SSD NVMe Samsung SM951 et SATA Samsung 850 Pro
  • RAM : 256 Go DDR4 LRDIMM ECC

Machine virtuelle fautive n°1 :

  • OS : Debian 8.6 noyau Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)
  • HDD : image disque qcow2 via bus SCSI/virtio et disque SCSI (trim unmap)
  • Cache HDD : writeback (défaut)
  • Cause de dysfonctionnement : écritures MySQL à partir de données téléchargées, environnement LAMP sécurisé chroot php5-fpm.
  • Fréquence de dysfonctionnement : 1 à 2 fois par mois

Machine virtuelle fautive n°2 :

  • OS : Debian 8.8 noyau Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2 (2017-04-30)
  • HDD : image disque qcow2 via disque Virtio (pas de trim)
  • Cache HDD : writeback (défaut)
  • Cause de dysfonctionnement : synchronisation portefeuille Bitcoin-qt 0.14.1 et aussi Etherum (geth 1.6.2.65979770)
  • Fréquence de dysfonctionnement : au moins 1 fois par synchronisation

Pistes envisagées

  • Effet de bord lié au trim des images disques remontées par le bus SCSI/virtio. Mais le même bug se produit sans cette configuration.
  • Effet de bord lié à l’over-provisionning CPU mais le retour à un nombre de coeurs physiques ne change rien.
  • Effet de bord lié à l’ajout de nombreuses cartes réseau et pci-bridge mais le retour à la normale ne change rien.
  • Bug du SSD SATA mais le même bug se produit sur le NVMe.
  • Bug pilote virtio mais cela se produit également en SATA.
  • Bug fstrim coté hyperviseur mais la désactivation ne change rien.
  • Manque d’entropie de la VM. L’augmentation de l’entropie avec virtio-rng ou haveged ne solutionne pas le bug.
  • Bug lié à l’architecture Intel Haswell. Mais KVM a l’intelligence de downgrader le CPU virtuel aux instructions SandyBridge ce qui désactive les instructions processeur buggées.
  • Problème avec le cache writeback. Cela ne devrait pas poser problème.
  • Problème de gestion des pages mémoire et non-activation de hugepage qui diminue la pression mémoire.

La piste privilégiée est le noyau de la VM qui est soit buggé, soit incompatible avec le même noyau coté hyperviseur. Pour l’heure, le bug ne semble pas se reproduire en utilisant des VM sous Debian 9.