7. VirtIO : réseau, cache disque, mémoire et agent QEMU

7.1 Le modèle réseau des VMs

Le réseau d'une VM Proxmox passe par le même bridge vmbr0 que les conteneurs LXC. La différence est dans le pilote : pour une VM, Proxmox présente un périphérique réseau virtuel, et c'est le driver à l'intérieur de la VM qui détermine les performances.

VirtIO est le standard de paravirtualisation pour les IO (spécification OASIS — organisme de normalisation). Avec un pilote émulé (e1000, RTL8139 — carte Realtek émulée), la VM écrit dans les registres d'un périphérique fictif. QEMU intercepte chaque accès → simule le comportement → extrait le paquet : des dizaines d'intercepts pour chaque IO.

Avec VirtIO, la VM et l'hyperviseur communiquent directement via une mémoire partagée en ring buffer — sans émulation de périphérique matériel. La VM "sait" qu'elle est virtualisée et utilise un pilote optimisé pour ça.

Le résultat est mesurable. Mesuré sur un nœud du lab, entre le nœud et une VM Debian 13, iperf3 a donné :

Dix fois moins dans un sens, près de quarante fois moins dans l'autre, pour la même VM sur le même matériel. Les valeurs absolues dépendent du processeur ; l'écart, lui, se retrouve partout. C'est pourquoi toutes les VM de cette formation utilisent virtio.

Les pilotes émulés (Intel E1000, RTL8139) simulent un vrai matériel. Utiles pour les vieux OS (Windows XP — sorti en 2001 —, FreeBSD sans pilotes VirtIO) ou des cas particuliers, déconseillés en production pour des flux importants.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Ajouter une seconde interface réseau à la VM 100
qm set 100 --net1 virtio,bridge=vmbr0

# Vérifier la configuration réseau de la VM
qm config 100 | grep net

Résultat attendu de qm config 100 | grep net :

net0: virtio=AA:BB:CC:DD:EE:FF,bridge=vmbr0
net1: virtio=AA:BB:CC:DD:EE:11,bridge=vmbr0

Deux interfaces réseau sont maintenant configurées. Chaque interface reçoit une adresse MAC (Media Access Control, adresse matérielle de la carte), générée aléatoirement par Proxmox. Elle prend le préfixe BC:24:11 que l'éditeur réserve à cet usage.

L'ajout se fait à chaud : le hotplug réseau est actif par défaut (option hotplug de la VM, qui vaut network,disk,usb), la carte apparaît aussitôt dans le système invité. Seuls les changements que le hotplug ne couvre pas, comme le modèle de la carte, restent « en attente » jusqu'au prochain démarrage. L'interface les affiche alors en rouge dans l'onglet Hardware.

• 📖 Documentation Proxmox — Network Configuration
• 📖 Configuration réseau dans Proxmox VE — Documentation Resinfo

7.2 QEMU Guest Agent : intégration entre la VM et l'hyperviseur

Trois fonctions justifient à elles seules d'activer l'agent sur toutes les machines, et elles tombent régulièrement en question d'examen comme en exploitation.

L'arrêt propre. Sans agent, le bouton « Arrêter » de Proxmox envoie un signal ACPI, que l'invité peut ignorer.

Un serveur Windows qui attend une confirmation reste allumé ; le délai d'attente finit par provoquer un arrêt brutal. Avec l'agent, Proxmox demande l'extinction au système lui-même, comme le ferait un administrateur connecté.

L'adresse IP dans l'interface. La colonne d'adresse d'une VM dans Proxmox ne vient pas du réseau : elle vient de l'agent, qui la lit dans l'invité et la remonte. Une VM sans agent affiche donc un champ vide, même parfaitement joignable — et c'est la première question posée en formation devant l'interface.

La cohérence des sauvegardes, décrite plus bas : c'est la plus importante des trois, car elle décide si une sauvegarde est restaurable ou seulement rassurante.

L'agent ne coûte rien : un paquet dans l'invité, une case à cocher côté hyperviseur. Ne pas l'installer est un oubli, jamais un choix.

L'agent QEMU est un daemon qui tourne à l'intérieur de la VM et communique avec l'hyperviseur via un canal VirtIO dédié. Il permet à Proxmox d'effectuer des opérations coordonnées avec le système d'exploitation de la VM.

Comment l'agent parle à Proxmox. Activer l'option agent ajoute à la VM un petit périphérique série VirtIO, que le système invité voit comme /dev/virtio-ports/org.qemu.guest_agent.0.

Le démon qemu-guest-agent écoute sur ce canal, et Proxmox lui envoie des commandes JSON — sans réseau, sans SSH, sans mot de passe. Deux conséquences pratiques.

L'agent fonctionne même si la carte réseau de la VM est mal configurée. Et l'option ne prend effet qu'après un arrêt puis un démarrage complets, puisqu'il faut un nouveau périphérique : un reboot depuis l'invité ne suffit pas.

Sans agent, un snapshot Proxmox capture l'état de la RAM et du disque sans garantie de cohérence des données en vol. Une transaction de base de données à moitié écrite peut se retrouver dans le snapshot. Avec l'agent, Proxmox demande au système d'exploitation de geler les écritures (file system freeze) avant de créer le snapshot, puis de les reprendre — le snapshot est applicativement cohérent.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# 1. Sur l'hôte Proxmox : ajouter le canal de l'agent, puis arrêter et redémarrer la VM
#    (un reboot depuis l'invité ne crée pas le nouveau périphérique)
qm set 100 --agent enabled=1
qm shutdown 100                  # arrêt par Proxmox
qm start 100                     # puis démarrage par Proxmox

# 2. Dans la VM : installer l'agent et le lancer tout de suite ;
#    aux démarrages suivants, il démarrera seul, déclenché par son périphérique
apt install -y qemu-guest-agent
systemctl start qemu-guest-agent   # le lancer tout de suite

# Interroger la VM via l'agent sans SSH — obtenir les IPs de toutes les interfaces
qm guest cmd 100 network-get-interfaces

Résultat attendu (extrait JSON) :

[
   {
      "hardware-address" : "bc:24:11:5e:3a:91",
      "ip-addresses" : [
         {
            "ip-address" : "10.44.1.55",
            "ip-address-type" : "ipv4",
            "prefix" : 24
         }
      ],
      "name" : "eth0"
   }
]

L'agent répond pour chaque interface de la VM ; la boucle lo figure aussi dans la réponse complète. Il donne son adresse MAC, et ses adresses IP telles que le système invité les voit.

C'est la seule façon, pour Proxmox, de connaître l'adresse d'une VM : le bridge ne fait que transporter des trames. Cette information s'affiche aussi dans l'interface web : VM → Summary → IPs, à condition que l'agent soit actif.

7.3 Le cache disque : un choix de risque, selon le stockage

Le mode de cache d'un disque décide à quel moment une écriture de la VM est considérée comme faite. Il se règle disque par disque (Hardware → Hard Disk → Edit → Cache, ou l'option cache= de scsi0).

Le trajet d'une écriture dans chacun des quatre modes, et l'endroit où la VM la croit terminée. Seul writeback la confirme avant le stockage : c'est son gain et son risque. Cliquez sur un mode pour le détail et les mesures du lab.

La règle à retenir : none partout par défaut. Jamais writeback sur ZFS, qui a déjà son propre cache en mémoire (l'ARC, Adaptive Replacement Cache) : deux caches empilés coûtent de la mémoire sans rien apporter.

Sur Ceph, writeback s'appuie sur le cache client de librbd et reste un arbitrage performance contre risque. Deux autres options accompagnent le cache sur VirtIO SCSI single.

iothread=1 donne au disque son propre fil d'entrées-sorties. discard=on transmet au stockage les blocs libérés par la VM ; il n'est utile que sur un stockage à provisionnement fin (LVM-thin, ZFS, Ceph).

Sur le lab, une écriture aléatoire de blocs de 4 Ko est passée de 45 800 IOPS en cache par défaut à 85 400 IOPS en writeback. Le gain est réel ; la garantie de l'écriture, elle, a disparu.

7.4 La mémoire : le ballooning

Le pilote VirtIO balloon permet au nœud de reprendre de la mémoire à une VM et de la lui rendre, sans l'arrêter. Deux valeurs le règlent, dans Hardware → Memory (options avancées) :

Entre les deux, c'est le nœud qui décide. Tant que son occupation mémoire reste sous sa cible (80 % par défaut), Proxmox ajoute de la mémoire aux VM jusqu'à leur maximum. Quand l'hôte manque de RAM, il la reprend, sans descendre sous le minimum ; dans la VM, free la voit disparaître.

Les deux bornes d'une VM réglée entre 1 et 3 Go (qm set <id> --memory 3072 --balloon 1024), et la mémoire qu'elle avait réellement peu après le démarrage. Cliquez sur une borne pour son explication.

À retenir : VirtIO remplace le matériel émulé par des pilotes paravirtualisés, bien plus rapides (réseau, disque). L'agent QEMU donne l'IP, un arrêt propre et des snapshots cohérents.

Le cache disque est un choix de risque (none par défaut). Le ballooning reprend de la mémoire à une VM entre un minimum et un maximum.