Proxmox VE 9.1 : Paramètres Avancés VM et Nested Virt

La configuration fine des machines virtuelles dans Proxmox VE 9.1 offre un contrôle granulaire sur les performances CPU, la gestion mémoire, le firmware UEFI et les pilotes VirtIO. Ce guide des paramètres avancés détaille le CPU pinning pour dédier des cœurs physiques aux VMs critiques, les hugepages (pages mémoire de grande taille, 2 Mo ou 1 Go, réduisant la pression sur le TLB) pour améliorer les performances mémoire, la configuration réseau optimisée avec les pilotes VirtIO paravirtualisés, les agents QEMU pour l'intégration hôte-invité, ainsi que l'activation et les cas d'usage de la virtualisation imbriquée (nested virtualization, permettant d'exécuter un hyperviseur à l'intérieur d'une VM). Ce guide s'adresse aux administrateurs cherchant à optimiser les performances de leurs workloads virtualisés sur Proxmox VE 9.1, avec des exemples concrets pour les cas d'usage courants : VMs haute performance, laboratoires de virtualisation, CI/CD avec Kubernetes, et environnements de test imbriqués. Chaque paramètre est expliqué avec son impact mesurable sur les performances et les compromis à considérer.

Configuration CPU Avancée : Types, Pinning et NUMA

Le type CPU de la VM détermine les instructions processeur exposées à l'invité. Pour Proxmox VE 9.1, les types recommandés :

• host : expose toutes les instructions du CPU physique (performances maximales, live migration limitée aux nœuds avec CPU identique)
• x86-64-v3 : baseline moderne compatible avec la majorité des clusters hétérogènes
• kvm64 : compatibilité maximale, performances réduites (éviter en production)

Le CPU pinning (affinité CPU) dédie des cœurs physiques spécifiques aux vCPU d'une VM. Configuration via qm set {vmid} --cpuunits 8 --cpulimit 4 pour la priorité et la limite CPU, ou directement dans /etc/pve/qemu-server/{vmid}.conf avec le paramètre affinity. Le pinning est particulièrement bénéfique pour les VMs temps réel ou haute performance (bases de données, jeux vidéo, rendu 3D).

L'alignement NUMA (Non-Uniform Memory Access) est critique pour les serveurs multi-socket. Activer numa: 1 dans la configuration de la VM assure que les vCPUs et la mémoire sont alloués dans le même domaine NUMA physique, évitant les accès mémoire cross-socket coûteux.

Gestion Mémoire : Hugepages et Ballooning

Les hugepages dans KVM allouent la mémoire des VMs en pages de 2 Mo (hugepages) ou 1 Go (gigantic pages) au lieu des pages standard de 4 Ko. Avantages : réduction des TLB misses, amélioration des performances pour les VMs mémoire-intensive de 5-15%.

Configuration des hugepages sur l'hôte Proxmox :

• Activer dans /etc/sysctl.conf : vm.nr_hugepages = 512 (pour 1 Go de hugepages à 2 Mo)
• Dans la configuration VM : hugepages: 2 (2 Mo) ou hugepages: 1024 (1 Go)
• La mémoire hugepages est allouée statiquement et n'est pas disponible pour les autres VMs

Le memory ballooning (driver virtio-balloon) permet au driver KVM de récupérer dynamiquement la mémoire non utilisée d'une VM pour la redistribuer aux autres VMs. Activé par défaut dans Proxmox avec l'agent QEMU installé dans la VM. Pour les VMs de production critiques, désactiver le ballooning en fixant balloon: 0 pour garantir la mémoire allouée.

Firmware UEFI et Secure Boot

Proxmox VE 9.1 supporte le firmware UEFI (Unified Extensible Firmware Interface) via OVMF (Open Virtual Machine Firmware), remplaçant le BIOS legacy. L'UEFI est requis pour :

• Les systèmes d'exploitation modernes nécessitant Secure Boot (Windows 11, RHEL 9)
• Les disques > 2 To (GPT obligatoire avec UEFI)
• Les VMs avec plus de 4 Go de mémoire adressable
• La nested virtualization avec les features CPU modernes

Configuration dans Proxmox : VM → Hardware → BIOS → OVMF (UEFI). Ajouter également un disque EFI : Add → EFI Disk. Le Secure Boot peut être activé ou désactivé dans les options UEFI. Attention : la migration live entre nœuds avec BIOS différents (UEFI/SeaBIOS) est impossible.

Pilotes VirtIO : Performances Réseau et Stockage

Les pilotes VirtIO paravirtualisés sont essentiels pour des performances optimales dans les VMs Proxmox. Ils éliminent l'overhead de l'émulation matérielle complète :

• VirtIO SCSI (virtio-scsi-pci) : contrôleur de stockage recommandé, supporte le TRIM/UNMAP et jusqu'à 255 disques par contrôleur
• VirtIO Block (virtio) : plus simple, légèrement plus performant que SCSI pour un seul disque
• VirtIO Net (virtio) : pilote réseau paravirtualisé, 10× plus performant que l'émulation e1000
• VirtIO Balloon : gestion dynamique de la mémoire
• VirtIO RNG : source d'entropie pour les VMs (accélère les opérations cryptographiques)

Pour les VMs Windows, les pilotes VirtIO doivent être installés depuis l'ISO virtio-win disponible sur le wiki Proxmox. Pour Linux, les modules VirtIO sont inclus dans le kernel depuis la version 2.6.25.

Agents QEMU et Guest Integration

L'agent QEMU (qemu-guest-agent) est un démon s'exécutant dans la VM invitée qui améliore l'intégration hôte-invité : snapshots cohérents (freeze/thaw du filesystem), récupération de l'adresse IP de la VM, arrêt propre depuis Proxmox et informations système dans l'interface web.

Installation dans la VM : apt install qemu-guest-agent (Debian/Ubuntu) ou dnf install qemu-guest-agent (RHEL/Fedora). Activation dans Proxmox : qm set {vmid} --agent enabled=1. Vérification : qm agent {vmid} ping. L'agent est indispensable pour des sauvegardes cohérentes (mode snapshot) et le power management correct. Pour l'administration CLI complète, consultez notre guide CLI Proxmox.

Nested Virtualization : Activation et Cas d'Usage

La nested virtualization (virtualisation imbriquée) permet d'exécuter un hyperviseur (VMware ESXi, KVM, Hyper-V) à l'intérieur d'une VM Proxmox. Elle est utilisée pour les laboratoires de test, la formation, le développement CI/CD avec Kubernetes (Kind, Minikube) et les environnements de test d'hyperviseurs.

Activation sur l'hôte Proxmox (Intel) : echo "options kvm-intel nested=Y" > /etc/modprobe.d/kvm-intel.conf puis modprobe -r kvm-intel && modprobe kvm-intel. Pour AMD : remplacer kvm-intel par kvm-amd. Vérification : cat /sys/module/kvm_intel/parameters/nested doit retourner Y.

Dans la configuration de la VM Proxmox, le type CPU doit exposer les extensions de virtualisation : cpu: host ou cpu: kvm64,+vmx (Intel) / cpu: kvm64,+svm (AMD). La performance de la nested virtualization est inférieure à la virtualisation native (overhead de 10-30%), ce qui la réserve aux environnements de test et développement. Pour l'optimisation globale des performances, consultez notre guide d'optimisation Proxmox VE. La documentation officielle Proxmox QEMU détaille tous les paramètres disponibles.

Questions fréquentes

Comment activer et vérifier la nested virtualization dans Proxmox VE 9.1 ?

L'activation de la nested virtualization nécessite deux étapes : sur l'hôte Proxmox, activer le paramètre kernel avec echo "options kvm-intel nested=Y" > /etc/modprobe.d/kvm-intel.conf (ou kvm-amd pour AMD) et recharger le module KVM. Vérifier avec cat /sys/module/kvm_intel/parameters/nested qui doit retourner Y. Dans la VM Proxmox, configurer le type CPU en host ou ajouter le flag +vmx (Intel) ou +svm (AMD). Dans la VM invitée, vérifier que KVM est disponible avec egrep -c '(vmx|svm)' /proc/cpuinfo qui doit retourner une valeur > 0.

Pourquoi le CPU pinning améliore-t-il les performances des VMs dans Proxmox ?

Sans CPU pinning, le scheduler Linux migre librement les vCPUs d'une VM entre les cœurs physiques disponibles, en optimisant l'utilisation globale du serveur. Cette flexibilité a un coût : chaque migration de vCPU invalide les caches L1/L2 du processeur et peut provoquer des accès mémoire cross-NUMA. Le CPU pinning dédie des cœurs physiques spécifiques aux vCPU, maintenant les données en cache et assurant la localité NUMA. Pour les VMs temps réel ou haute performance (latence < 1ms, transactions financières, jeux en ligne), le pinning peut réduire la latence de 20-50%. La contrepartie est une réduction de la densité de VMs sur le nœud.

Quelle est la différence entre VirtIO SCSI et VirtIO Block dans Proxmox VE ?

VirtIO Block est le protocole de stockage paravirtualisé original : simple, efficace pour un disque unique, mais limité à 1 LUN par contrôleur. VirtIO SCSI (virtio-scsi-pci) est le successeur recommandé : il supporte jusqu'à 255 disques par contrôleur, les commandes SCSI complètes (TRIM/UNMAP pour la récupération d'espace sur le stockage thin-provisioned), le multiqueue I/O (meilleures performances sur VMs multi-cœurs) et l'éjection à chaud des disques. En pratique, utiliser VirtIO SCSI pour toutes les VMs de production, et VirtIO Block uniquement pour les compatibilités spéciales ou les cas d'usage simples avec un seul disque.

Sources et références : Proxmox VE Wiki · ANSSI

Conclusion

La maîtrise des paramètres avancés des VMs Proxmox VE 9.1 permet d'extraire le maximum des ressources physiques tout en garantissant l'isolation et la sécurité des workloads. CPU pinning, hugepages, VirtIO et nested virtualization sont les leviers clés d'une infrastructure virtualisée haute performance, à activer selon les besoins spécifiques de chaque VM.

Sécurisez votre infrastructure virtualisée

Audit Proxmox, VMware, Hyper-V — durcissement hyperviseur, segmentation, protection anti-ransomware.

Demander un audit [email protected]

Configuration NUMA et CPU Pinning pour les VMs Haute Performance

Dans les architectures serveur modernes équipées de processeurs multi-socket ou de CPU à grand nombre de coeurs comme les AMD EPYC ou Intel Xeon Scalable, l'architecture NUMA divise la mémoire RAM en zones locales associées à chaque groupe de coeurs. Un coeur accédant à de la mémoire distante subit une latence supplémentaire de 30 à 80 nanosecondes par accès comparé à la latence locale. Sur une application effectuant plusieurs centaines de millions d'accès mémoire par seconde, comme une base de données Redis, un moteur de calcul numérique ou un serveur Java sous forte charge, cette latence additionnelle se traduit par une dégradation de performance mesurable pouvant atteindre 20 à 30 pourcent de perte de débit sur certains workloads intensifs.

Proxmox VE 9.1 permet de configurer le NUMA awareness au niveau de chaque VM pour garantir que les vCPUs et la mémoire allouée restent sur le même noeud NUMA physique. Pour identifier la topologie NUMA de l'hôte et configurer les VMs en conséquence, les commandes suivantes sont indispensables :

numactl --hardware
lscpu | grep -E "NUMA|Socket|Core"

La configuration s'effectue ensuite dans le fichier de chaque VM sous /etc/pve/qemu-server/{vmid}.conf en ajoutant les directives numa, numanode et la politique d'allocation mémoire souhaitée. Trois politiques sont disponibles selon le type de workload :

• policy=bind : force l'allocation mémoire exclusivement sur le noeud NUMA correspondant au CPU pinné. Recommandé pour les bases de données et les workloads latence-critiques qui ne tolèrent pas la variabilité introduite par les accès mémoire distants.
• policy=preferred : préfère le noeud local mais autorise les débordements sur les noeuds distants en cas de pression mémoire. Plus permissif et résistant aux pics de charge inattendus sans sacrifier l'isolation complète.
• policy=interleave : distribue la mémoire uniformément entre tous les noeuds NUMA disponibles, optimisant le débit global pour les workloads hautement parallèles qui accèdent à toute la mémoire de façon équilibrée et ne bénéficient pas de la localité NUMA.
• Huge pages de 2 Mo : activer les huge pages réduit significativement les TLB misses pour les VMs disposant de 32 Go ou plus de RAM allouée, améliorant les performances de 5 à 15 pourcent sur les workloads mémoire-intensifs.

Le CPU pinning complémentaire garantit qu'un vCPU reste toujours mappé sur le même pCPU physique, éliminant les migrations de threads entre coeurs par le scheduler Linux et améliorant l'efficacité des caches L1 et L2 propres à chaque coeur physique. Dans Proxmox VE 9.1, le CPU pinning se configure via l'interface web sous Options CPU Affinity, ou directement dans le fichier de configuration VM. La combinaison NUMA binding et CPU pinning est particulièrement efficace pour les VMs hébergeant des bases de données MySQL, PostgreSQL ou des applications Java avec de larges heap JVM.

Optimisation ZFS pour Proxmox VE 9 : ARC, L2ARC, SLOG et Bonnes Pratiques

Proxmox VE 9.1 intègre ZFS (OpenZFS 2.2+) comme système de fichiers natif pour les pools de stockage de machines virtuelles et de conteneurs, offrant des fonctionnalités avancées de snapshot instantané, de compression transparente, de déduplication optionnelle et de vérification continue d'intégrité par checksum. La configuration correcte des composants de cache ZFS est cependant indispensable pour atteindre des performances acceptables en production, car les paramètres par défaut sont généralement inadaptés aux workloads de virtualisation à forte densité de VMs hébergées.

L'ARC de ZFS occupe par défaut jusqu'à 50 pourcent de la RAM totale de l'hôte pour mettre en cache les blocs de données fréquemment accédés. Cette consommation agressive entre directement en compétition avec la mémoire allouée aux VMs et peut provoquer du swapping en situation de charge pointe, dégradant catastrophiquement les performances du système de virtualisation. Il est indispensable de plafonner l'ARC explicitement et de le compléter par des dispositifs de cache secondaire sur SSD NVMe :

echo "options zfs zfs_arc_max=17179869184" > /etc/modprobe.d/zfs.conf
echo "options zfs zfs_arc_min=4294967296" >> /etc/modprobe.d/zfs.conf
update-initramfs -u
zpool add rpool cache /dev/nvme1n1
zpool add rpool log /dev/nvme2n1p1
zfs set compression=lz4 rpool
zfs set recordsize=128k rpool/images
zfs set recordsize=8k rpool/databases
zfs set atime=off rpool

• L2ARC : cache de lecture sur SSD NVMe qui étend la capacité de l'ARC RAM en mémoire vive, efficace quand le working set actif dépasse la RAM disponible pour l'ARC et que le ratio de lectures sur total I/O dépasse 65 pourcent
• SLOG ou ZIL séparé : réduit la latence des écritures synchrones de 5 à 10 millisecondes sur disques rotatifs à moins d'une milliseconde, critique pour les bases de données MySQL et PostgreSQL utilisant le mode innodb_flush_log_at_trx_commit=1
• Compression LZ4 : algorithme très rapide réduisant l'empreinte disque de 20 à 40 pourcent pour les données textuelles avec un overhead CPU inférieur à 2 pourcent sur les processeurs modernes disposant d'instructions dédiées
• recordsize adaptatif : 128k pour les VMs génériques optimise le débit séquentiel, 8k pour les bases de données transactionnelles optimise les lectures aléatoires partielles sur des tuples de petite taille
• atime désactivé : supprime les écritures parasites de mise à jour des timestamps d'accès, réduisant les I/O de 10 à 20 pourcent sur les workloads à forte proportion de lectures répétées

La surveillance continue des performances ZFS est indispensable pour détecter les dégradations avant qu'elles n'affectent les VMs hébergées. La commande zpool iostat avec l'option -v affiche les statistiques I/O par vdev en temps réel, arcstat permet de monitorer le taux de hit de l'ARC et du L2ARC, et zpool status vérifie l'état de santé du pool et détecte les erreurs de checksum indiquant une dégradation matérielle. Un taux de hit de l'ARC inférieur à 75 pourcent sur un workload de production stable est le signal qu'il faut augmenter la limite de l'ARC ou investir dans un L2ARC de plus grande capacité. La combinaison de NUMA binding, CPU pinning et ZFS correctement dimensionné permet d'atteindre des performances très proches du bare-metal pour la grande majorité des workloads d'entreprise hébergés sur Proxmox VE 9.1.

Sécurité et Durcissement de Proxmox VE 9.1 en Production

Proxmox VE 9.1 expose par défaut plusieurs services réseau qui doivent être durcis avant toute mise en production dans un environnement exposé ou multi-tenant. L'interface web d'administration écoute sur le port 8006 en HTTPS avec un certificat auto-signé qu'il convient de remplacer par un certificat Let's Encrypt valide ou un certificat d'entreprise signé par une PKI interne. L'API REST complète est accessible sur le même port et doit être protégée par une liste blanche d'adresses IP d'administration configurée dans les règles de pare-feu de l'hôte.

Les mesures de durcissement prioritaires pour un déploiement Proxmox VE 9.1 en production incluent la désactivation du compte root SSH et la mise en place d'une authentification par clé publique RSA 4096 bits ou Ed25519 pour les accès d'administration, la configuration de l'authentification à deux facteurs TOTP pour l'interface web via le menu Datacenter > Permissions > Two Factor, et l'activation du pare-feu Proxmox au niveau du datacenter avec une politique par défaut de blocage total et des règles d'autorisation explicites uniquement pour les flux nécessaires. La séparation du réseau d'administration IPMI et BMC sur un VLAN dédié isolé du réseau de production complète ce dispositif de défense en profondeur. Des audits de sécurité réguliers utilisant des outils comme Lynis (audit de durcissement Linux) doivent être planifiés trimestriellement pour détecter les dérives de configuration et maintenir le niveau de sécurité cible défini dans la politique de sécurité de l'organisation.

Sauvegarde et Restauration avec Proxmox Backup Server

Proxmox Backup Server (PBS) est la solution de sauvegarde native de l'écosystème Proxmox, offrant des sauvegardes incrémentales basées sur les chunks de données modifiés plutôt que sur des snapshots complets, réduisant drastiquement le volume de données transmises et stockées à chaque cycle de sauvegarde. PBS utilise la déduplication côté client et côté serveur, permettant de réduire l'espace de stockage nécessaire de 50 à 80 pourcent pour les workloads avec des données redondantes comme les templates de VMs ou les images de systèmes d'exploitation similaires. La rétention configurable par type de sauvegarde (horaire, quotidien, hebdomadaire, mensuel) permet de maintenir une politique de conservation granulaire alignée sur les exigences de RTO et RPO définies dans le Plan de Continuité d'Activité. Les sauvegardes PBS sont chiffrées de bout en bout avec une clé gérée côté client, garantissant que le serveur de sauvegarde ne peut pas accéder au contenu des sauvegardes même en cas de compromission physique ou logique du serveur PBS. Des tests de restauration trimestriels, documentés et chronométrés, sont indispensables pour valider que le RTO contractuel peut effectivement être tenu lors d'un incident réel.