La plupart des lignes de réglage Proxmox trouvées en ligne sont un seul bloc de drapeaux noyau. La moitié va sur l’hyperviseur, la moitié va dans l’invité, deux des plus populaires ne font rien du tout, et quelques-uns changent de sens selon le côté de la frontière où ils atterrissent.
QEMU sait émuler un vrai contrôleur NVMe, si bien que l’invité se sert de son propre pilote NVMe intégré, sans aucun support VirtIO requis. Il est aussi non migrable par conception, invisible aux sauvegardes Proxmox, et pas plus rapide que VirtIO SCSI. Voici comment en ajouter un et quand cela en vaut la peine.
L’horloge d’une machine virtuelle repose sur une hypothèse que la virtualisation casse : que le CPU continue de compter. Pourquoi l’heure des invités dérive sur tous les hyperviseurs, ce que le décalage casse vraiment — Kerberos, TLS, Ceph, Windows — et comment ptp_kvm corrige ça proprement sur QEMU/KVM.
Pourquoi les périphériques PCIe perdent du débit quand on les passe à une VM par VFIO, et les étapes de réglage pratiques qui en récupèrent l’essentiel.
Sur les systèmes multi-sockets, une VM dont les vCPU sont sur un nœud NUMA et l’équipement en passthrough sur un autre perd 20 à 30 % de débit avant même que vous ayez regardé quoi que ce soit d’autre.
L’Active State Power Management économise quelques watts sur les liens PCIe au repos. Sous passthrough VFIO, il ajoute une gigue de latence difficile à diagnostiquer et facile à corriger.
Le root complex virtuel de QEMU se rabat par défaut sur des charges utiles TLP de 128 octets. La plupart des équipements gèrent 256 ou 512. Un seul paramètre noyau corrige ça.
Les deux chipsets virtuels de QEMU ne sont pas interchangeables. Q35 fournit une vraie topologie PCIe dont dépendent le passthrough, les Windows modernes et tout l’écosystème KVM.