Vous avez changé le type de CPU sur une VM Proxmox parce que vous vouliez de meilleures performances, de la cohérence pour la migration, ou parce que vous avez suivi un post de forum bien intentionné. Maintenant la VM ne démarre plus, Proxmox affiche « QEMU exited with code 1 », et vous regardez une charge de travail arrêtée qui fonctionnait parfaitement il y a cinq minutes.
Cette panne est courante, généralement réparable en quelques minutes, et parfois le signe que vous étiez en équilibre précaire depuis des mois. Reprenons la VM en toute sécurité, expliquons ce qui a réellement cassé, et mettons en place des pratiques pour que vous puissiez changer de type de CPU sans jouer à la roulette la prochaine fois.
Playbook de diagnostic rapide
Si vous n’avez que dix minutes avant que quelqu’un ne demande pourquoi le tableau de bord est rouge, faites ceci dans l’ordre. L’objectif est d’identifier si vous avez affaire à un problème purement lié au modèle CPU de QEMU, une réaction du système invité, ou un désaccord matériel/hôte.
Première étape : lisez l’erreur QEMU réelle, pas la notification GUI
- Consultez le journal des tâches et le journal système pour la tentative de démarrage de la VM.
- Recherchez spécifiquement des expressions comme
unsupported CPUID,host doesn’t support requested feature,invalid CPU model, oukvm: failed to init.
Deuxième étape : confirmez la config de la VM maintenant vs. ce qu’elle était
- Vérifiez la ligne
cpu:et toutes les surchargesargs:. - Si vous avez des sauvegardes, comparez la configuration actuelle à la dernière configuration connue bonne.
Troisième étape : décidez si la correction est « revenir au type de CPU précédent » ou « passer à une base CPU plus sûre »
- Si cette VM doit démarrer immédiatement : revenez au type de CPU précédent (ou
hostsi cela fonctionnait avant). - Si cette VM doit migrer entre nœuds : choisissez une base comme
x86-64-v2/x86-64-v3(là où c’est supporté) ou un modèle nommé présent sur tous vos nœuds.
Quatrième étape : si elle démarre, validez la vue CPU et la stabilité côté invité
- Pour Windows : vérifiez les implications sur l’activation/licences et assurez-vous que les services critiques démarrent.
- Pour Linux : consultez dmesg pour les avertissements sur les fonctionnalités CPU, les messages de microcode et les changements de clocksource.
Une vérité opérationnelle : une VM qui ne démarre pas est généralement un décalage de configuration. Une VM qui démarre mais se comporte étrangement est souvent une régression de fonctionnalités CPU, un changement de timer/clocksource, ou un problème d’attente des pilotes du système invité.
Ce qui a réellement cassé quand vous avez changé le type de CPU
Dans Proxmox, le réglage « type de CPU » n’est pas cosmétique. Il contrôle quel modèle de CPU virtuel QEMU annonce à l’invité et ce qu’on demande à KVM d’accélérer. Cela inclut :
- flags CPUID (SSE4.2, AVX, AVX2, AES-NI, BMI, FMA, etc.).
- niveau d’ensembles d’instructions et particularités (certains modèles impliquent des groupes de flags).
- exposition de la topologie (sockets/coeurs/threads) et parfois le comportement de cache/temporalité.
- compatibilité de migration entre hôtes : le modèle CPU peut être un contrat qui doit tenir sur tous les nœuds où la VM peut atterrir.
Lorsque vous choisissez host, QEMU tente d’exposer un CPU qui correspond étroitement à l’hôte, activant tout ce que le CPU physique supporte. Excellent pour la performance. Également excellent pour vous enfermer ensuite si vous déplacez la VM vers un hôte avec moins de fonctionnalités ou une microarchitecture différente.
Lorsque vous choisissez un modèle CPU nommé (p. ex. Skylake-Server, EPYC, Broadwell), QEMU expose un ensemble soigné de flags. Cela peut améliorer la compatibilité de migration, mais cela peut aussi échouer sévèrement si :
- Le CPU hôte ne supporte pas l’une des fonctionnalités demandées.
- La version de QEMU sur le nœud ne reconnaît pas le nom du modèle.
- La VM a une ligne
args:explicite forçant des flags qui entrent en conflit avec le modèle choisi. - Vous traversez la frontière Intel ↔ AMD et le modèle suppose un comportement spécifique au fournisseur.
Et parfois la VM démarre, mais le système invité proteste ensuite. Windows peut décider qu’il s’agit d’un « nouveau matériel », et Linux peut changer le comportement du clocksource ou désactiver certaines optimisations du noyau.
Vérification réaliste et sèche (blague #1) : changer le type de CPU, c’est comme faire un « refactor rapide ». Le mot « rapide » sert surtout de soutien émotionnel.
Faits intéressants et contexte historique
Ce ne sont pas des anecdotes pour le plaisir. Chacun explique pourquoi les changements de type de CPU peuvent casser une VM auparavant stable.
- CPUID est un champ de mines de compatibilité depuis les années 1990. Les invités ne se contentent pas de « prendre ce qui existe » ; ils prennent des décisions selon les flags et les identifiants du fournisseur rapportés.
- KVM n’est pas d’abord un émulateur ; c’est un accélérateur. Si vous demandez des fonctionnalités CPU que l’hôte ne peut pas fournir, KVM refuse — rapidement et sans concession.
- Les noms de modèles CPU QEMU ne sont pas éternels. Les modèles et alias évoluent entre les versions de QEMU ; les mises à jour Proxmox peuvent ajouter des modèles, en déprécier d’autres ou changer les valeurs par défaut.
- La migration à chaud a été le moteur des baselines CPU. La raison d’être des types CPU « génériques » est de rendre « déplacer cette VM n’importe où » pratique.
- La virtualisation Intel et AMD diffère en comportements de bord. Même lorsque les deux supportent les mêmes jeux d’instructions, des fonctionnalités spécifiques au fournisseur et des quirks de microcode importent pour les invités et l’hyperviseur.
- L’ère Spectre/Meltdown a impacté la virtualisation. Les microcodes et mitigations noyau ont changé les performances et parfois modifié les fonctionnalités exposées ; des clusters ont vu des « CPUs identiques » se comporter différemment après patchs.
- L’activation Windows peut considérer un changement CPU/carte comme un changement matériel. Changer le modèle CPU peut suffire à déclencher des vérifications de licence selon l’édition et la méthode d’activation.
- La virtualisation imbriquée est très sensible. Si l’invité exécute un hyperviseur, il a souvent besoin de flags VMX/SVM spécifiques ; les changements de modèle CPU peuvent les retirer.
Tâches de récupération pratiques (commandes, sorties, décisions)
Ci-dessous des tâches concrètes à exécuter sur le nœud Proxmox. Chaque section inclut : la commande, ce que signifie une sortie typique, et la décision à prendre. Faites-les dans l’ordre jusqu’à obtenir une VM démarrée ou une cause racine claire.
Tâche 1 : identifier l’événement d’échec de démarrage de la VM dans le journal
cr0x@server:~$ journalctl -u pvedaemon -u pveproxy -u pvestatd --since "30 min ago" | tail -n 80
Dec 26 11:02:15 pve01 pvedaemon[2217]: starting task UPID:pve01:00004A3C:0001B2D1:676D1D97:qmstart:105:root@pam:
Dec 26 11:02:15 pve01 pvedaemon[2217]: VM 105 start failed: command '/usr/bin/kvm -id 105 ... -cpu Skylake-Server,...' failed: exit code 1
Dec 26 11:02:15 pve01 pvedaemon[2217]: end task UPID:pve01:00004A3C:0001B2D1:676D1D97:qmstart:105:root@pam: VM 105 start failed: exit code 1
Ce que ça signifie : Vous avez confirmé qu’il s’agit d’une erreur de démarrage QEMU/KVM, pas d’un crash du système invité après le démarrage.
Décision : Allez chercher l’erreur QEMU exacte (Tâche 2). Ne devinez pas.
Tâche 2 : extraire l’erreur QEMU détaillée depuis le log de tâche
cr0x@server:~$ cat /var/log/pve/tasks/active | head
UPID:pve01:00004A3C:0001B2D1:676D1D97:qmstart:105:root@pam:
cr0x@server:~$ cat /var/log/pve/tasks/UPID:pve01:00004A3C:0001B2D1:676D1D97:qmstart:105:root@pam: | tail -n 60
kvm: host doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5]
TASK ERROR: start failed: QEMU exited with code 1
Ce que ça signifie : Le modèle CPU sélectionné (ou des flags personnalisés) demande VMX, mais l’hôte ne peut pas le fournir (ou il est désactivé).
Décision : Vérifiez le support de virtualisation CPU de l’hôte et les réglages BIOS (Tâche 3 et Tâche 4). Si cette VM n’a pas besoin de virtualisation imbriquée, retirez cette exigence dans les flags (tâches ultérieures).
Tâche 3 : vérifier que KVM est chargé et que la virtualisation est disponible
cr0x@server:~$ lsmod | egrep 'kvm|vhost' | head
kvm_intel 385024 0
kvm 1200128 1 kvm_intel
vhost_net 36864 0
vhost 53248 1 vhost_net
Ce que ça signifie : Les modules KVM sont chargés. C’est nécessaire mais pas suffisant.
Décision : Confirmez les flags CPU exposés par l’hôte (Tâche 4).
Tâche 4 : confirmer que les flags CPU de l’hôte incluent ce que la VM demande
cr0x@server:~$ lscpu | egrep 'Vendor ID|Model name|Flags|Virtualization' -A1
Vendor ID: GenuineIntel
Model name: Intel(R) Xeon(R) Silver 4210R CPU @ 2.40GHz
Virtualization: VT-x
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr ... vmx ... avx avx2 ...
Ce que ça signifie : VT-x (flag vmx) est présent. Si QEMU a dit que VMX n’est pas supporté, soit le BIOS l’a désactivé, soit le noyau le masque, soit vous n’êtes pas sur le nœud que vous pensez.
Décision : Si Virtualization est vide ou que le flag manque, corrigez les paramètres BIOS/firmware. S’il est présent, la config VM force probablement quelque chose d’incohérent (Tâche 6 et Tâche 7).
Tâche 5 : inspecter la config actuelle de la VM pour le type de CPU et les flags forcés
cr0x@server:~$ qm config 105
boot: order=scsi0;net0
cores: 8
cpu: Skylake-Server,flags=+pcid;+spec-ctrl;+md-clear
memory: 16384
name: payroll-app01
net0: virtio=DE:AD:BE:EF:10:05,bridge=vmbr0
scsi0: local-lvm:vm-105-disk-0,discard=on,iothread=1
scsihw: virtio-scsi-pci
Ce que ça signifie : Le modèle CPU est explicitement réglé sur Skylake-Server avec des flags supplémentaires. Si l’hôte est plus ancien ou AMD, cela peut échouer.
Décision : Si vous avez changé cela récemment et que la VM démarrait avant, revenez au type de CPU antérieur (Tâche 8). Si vous avez besoin de compatibilité de migration, choisissez une base ensuite.
Tâche 6 : chercher des surcharges cachées dans args:
cr0x@server:~$ grep -nE '^(cpu:|args:|machine:|bios:|ostype:)' /etc/pve/qemu-server/105.conf
3:cpu: Skylake-Server,flags=+pcid;+spec-ctrl;+md-clear
Ce que ça signifie : Pas de surprises args: ici. Bien. Si vous voyez une ligne args:, considérez-la comme suspecte jusqu’à preuve du contraire.
Décision : Si args: est présent et inclut -cpu ou -machine, retirez/ajustez-le ; les réglages GUI Proxmox ne vous sauveront pas de votre passé.
Tâche 7 : valider que le nom du modèle CPU est reconnu par votre build QEMU
cr0x@server:~$ /usr/bin/qemu-system-x86_64 -cpu help | egrep -i 'skylake|broadwell|epyc|x86-64' | head -n 20
x86-64-v2
x86-64-v3
Broadwell
Skylake-Server
EPYC
EPYC-Rome
Ce que ça signifie : Le modèle existe sur ce nœud. S’il n’existait pas, QEMU échouerait immédiatement avec « invalid CPU model ».
Décision : Si le modèle manque sur certains nœuds du cluster, vous avez un problème de versions divergentes. Alignez Proxmox/QEMU entre nœuds ou standardisez sur un modèle disponible partout.
Tâche 8 : revenir au type de CPU connu bon précédemment (restauration la plus rapide)
cr0x@server:~$ cp -a /etc/pve/qemu-server/105.conf /root/105.conf.before-revert
cr0x@server:~$ qm set 105 --cpu host
update VM 105: -cpu host
cr0x@server:~$ qm start 105
Ce que ça signifie : Vous revenez à host, ce qui démarre généralement si la VM tournait déjà sur ce nœud.
Décision : Si cela démarre, arrêtez l’hémorragie. Puis décidez si vous avez réellement besoin d’un modèle CPU différent (section suivante). Si ça échoue encore, le problème n’est pas juste « nom de modèle » ; il peut s’agir de flags, du type de machine ou de la disponibilité de la virtualisation matérielle.
Tâche 9 : si host échoue, essayez une base générique plus sûre
cr0x@server:~$ qm stop 105
stopping VM 105 (timeout = 60 seconds)
cr0x@server:~$ qm set 105 --cpu x86-64-v2
update VM 105: -cpu x86-64-v2
cr0x@server:~$ qm start 105
Ce que ça signifie : Vous demandez un ensemble conservateur de fonctionnalités CPU qui tend à fonctionner sur beaucoup d’hôtes modernes.
Décision : Si cela démarre, vous aviez probablement une fonctionnalité non supportée dans l’ancien modèle ou des flags. Conservez x86-64-v2 (ou v3 si le cluster le supporte) comme base de cluster.
Tâche 10 : confirmer que le processus VM existe et utilise l’accélération KVM
cr0x@server:~$ pgrep -a -f 'kvm.*-id 105' | head -n 1
24788 /usr/bin/kvm -id 105 -name payroll-app01 ...
cr0x@server:~$ ps -o pid,comm,%cpu,%mem,args -p 24788
PID COMMAND %CPU %MEM COMMAND
24788 kvm 8.2 4.1 /usr/bin/kvm -id 105 -name payroll-app01 ...
Ce que ça signifie : La VM a réellement démarré et s’exécute en tant que processus QEMU/KVM.
Décision : Passez de « l’hyperviseur peut la démarrer » à « l’invité est sain ». Si la VM est toujours injoignable, dépannez à l’intérieur de l’invité (console, réseau, services).
Tâche 11 : vérifier la ligne de commande QEMU pour la définition CPU effective
cr0x@server:~$ qm showcmd 105 --pretty | sed -n '1,120p'
/usr/bin/kvm \
-id 105 \
-name payroll-app01,debug-threads=on \
-no-shutdown \
-chardev socket,id=qmp,path=/var/run/qemu-server/105.qmp,server=on,wait=off \
-mon chardev=qmp,mode=control \
-machine type=pc-q35-8.1+pve0 \
-cpu x86-64-v2 \
-smp 8,sockets=1,cores=8,maxcpus=8 \
-m 16384 \
...
Ce que ça signifie : C’est la source unique de vérité pour ce que QEMU exécute réellement (après transformation par Proxmox).
Décision : Si vous voyez un -cpu différent de celui attendu, vous avez des entrées de configuration conflictuelles ou une surcouche args:.
Tâche 12 : valider la compatibilité des fonctionnalités CPU du cluster (réalité de la migration)
cr0x@server:~$ pvesh get /nodes --output-format json-pretty
[
{
"node": "pve01",
"status": "online"
},
{
"node": "pve02",
"status": "online"
}
]
cr0x@server:~$ for n in pve01 pve02; do echo "== $n =="; ssh $n "lscpu | egrep 'Vendor ID|Model name|Flags' -A1 | head -n 6"; done
== pve01 ==
Vendor ID: GenuineIntel
Model name: Intel(R) Xeon(R) Silver 4210R CPU @ 2.40GHz
Flags: ... avx avx2 vmx ...
== pve02 ==
Vendor ID: GenuineIntel
Model name: Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz
Flags: ... avx avx2 vmx ...
Ce que ça signifie : Les nœuds semblent similaires, mais pas identiques. De petites différences peuvent avoir de l’importance : un stepping CPU différent, un niveau de microcode différent, un réglage BIOS, et soudain un flag disparaît.
Décision : Si vous attendez une migration, choisissez une base CPU supportée par tous les nœuds. « Ça marche sur mon nœud » n’est pas une stratégie.
Tâche 13 : vérifier microcode et messages noyau si les fonctionnalités « devraient exister » mais n’y sont pas
cr0x@server:~$ dmesg | egrep -i 'microcode|kvm|vmx|svm' | tail -n 30
[ 0.812345] microcode: microcode updated early to revision 0x2006e04, date = 2023-10-12
[ 6.112233] kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. Using workaround
[ 6.112455] kvm_intel: enabling virtualization on CPU0
Ce que ça signifie : Le microcode et l’initialisation KVM sont visibles. Si KVM se plaint de virtualisation désactivée, c’est votre alibi fumant.
Décision : Si la virtualisation est désactivée au niveau plateforme, corrigez le BIOS et redémarrez le nœud. Ne continuez pas à « contourner » l’absence de VMX/SVM.
Tâche 14 : si Windows ne démarre pas après le changement de CPU, vérifiez boucle de démarrage vs. échec hyperviseur
cr0x@server:~$ qm terminal 105
starting serial terminal on interface serial0 (press Ctrl+O to exit)
Ce que ça signifie : Un terminal série est un moyen rapide de voir des problèmes de démarrage précoce sous Linux ; pour Windows c’est moins utile sauf si vous avez configuré le débogage série. Si vous avez la console VGA dans le GUI, utilisez-la.
Décision : Si la VM démarre mais redémarre immédiatement, vous êtes au-delà de l’échec de démarrage lié au modèle CPU et dans un comportement côté invité. Gardez l’hyperviseur stable et dépannez le système invité séparément.
Tâche 15 : restaurer un fichier de config VM connu bon si vous avez besoin d’un rollback instantané
cr0x@server:~$ ls -l /root/105.conf.*
-rw-r--r-- 1 root root 512 Dec 26 11:05 /root/105.conf.before-revert
cr0x@server:~$ cp -a /root/105.conf.before-revert /etc/pve/qemu-server/105.conf
cr0x@server:~$ qm start 105
Ce que ça signifie : Vous remplacez ce que l’UI a fait et revenez à un snapshot de configuration sauvegardé.
Décision : Si cela résout le problème, considérez le changement de CPU antérieur comme cause racine et procédez ensuite à une modification contrôlée avec tests, pas à l’instinct.
Tâche 16 : vérifier que vous ne luttez pas contre un mismatch de type de machine introduit par des edits « utiles »
cr0x@server:~$ qm config 105 | egrep '^(machine:|bios:|efidisk0:|ostype:)'
machine: pc-q35-8.1+pve0
ostype: l26
Ce que ça signifie : Le type de machine est Q35. Certains changements de modèle CPU coïncident avec un changement de type de machine (edits manuels, anciens guides). Cette combinaison peut modifier l’exposition des périphériques et le comportement de démarrage invité.
Décision : Si vous avez changé le type de machine en même temps, revenez-en aussi. Changez une variable à la fois, à moins que vous aimiez les erreurs non forcées.
Vérification réaliste et sèche (blague #2) : Si vous avez changé le type de CPU, le type de machine et le mode BIOS en un seul edit, vous n’avez pas « optimisé ». Vous avez écrit un roman policier.
Erreurs courantes : symptôme → cause racine → correction
Cette section est volontairement directe. Ce sont les schémas qui réapparaissent en production.
1) Symptom : « QEMU exited with code 1 » + « host doesn’t support requested feature »
- Cause racine : Le modèle CPU ou les flags sélectionnés incluent des fonctionnalités absentes sur l’hôte (ou désactivées dans le BIOS).
- Correction : Revenir à
hostou à une base inférieure commex86-64-v2. Si la fonctionnalité manquante est VMX/SVM, corrigez les paramètres de virtualisation BIOS et redémarrez l’hôte.
2) Symptom : « invalid CPU model » après avoir sélectionné un modèle nommé
- Cause racine : La build QEMU sur ce nœud ne connaît pas le nom du modèle CPU (versions divergentes, jeu de paquets différent ou nœud Proxmox ancien).
- Correction : Utilisez
/usr/bin/qemu-system-x86_64 -cpu helppour choisir un modèle disponible. Standardisez les versions Proxmox/QEMU à travers le cluster.
3) Symptom : la VM démarre sur le nœud A, refuse de démarrer après migration vers le nœud B
- Cause racine : Type CPU réglé sur
hostou modèle trop moderne ; le nœud B n’a pas les flags requis. - Correction : Choisissez un modèle CPU de base supporté par tous les nœuds. Appliquez-le à la VM avant la migration (fenêtre de maintenance planifiée si l’invité est sensible).
4) Symptom : Linux démarre, mais les performances chutent après le changement de CPU
- Cause racine : Vous avez retiré AVX/AVX2/AES ou d’autres accélérations utilisées par la charge (crypto, compression, JVM, checksums de base de données). Ou l’invité a changé de clocksource.
- Correction : Comparez les flags CPU avant/après. Sélectionnez une base qui conserve les fonctionnalités nécessaires et reste migrable. Validez clocksource et messages noyau.
5) Symptom : Windows démarre, mais l’activation/la licence se plaint
- Cause racine : Windows voit un changement d’identité matérielle (les modifications du modèle/topologie CPU peuvent y contribuer).
- Correction : Préférez des modèles CPU stables à long terme. Si vous devez changer, faites-le une fois, documentez-le et attendez-vous à des workflows d’activation selon votre méthode de licence.
6) Symptom : la virtualisation imbriquée a cessé de fonctionner
- Cause racine : Le changement de modèle CPU a supprimé l’exposition de
vmx(Intel) ousvm(AMD) à l’invité. - Correction : Choisissez un modèle CPU qui inclut les extensions de virtualisation et confirmez que le BIOS hôte les supporte. Évitez la chirurgie de flags aléatoire ; testez les charges imbriquées explicitement.
7) Symptom : « KVM: entry failed » ou erreurs d’initialisation liées à KVM
- Cause racine : Restrictions du noyau/KVM de l’hôte, quirks de microcode, ou combinaison incompatible de flags CPU et de type de machine.
- Correction : Retirez les flags personnalisés et revenez à un modèle CPU connu bon. Si l’hôte a récemment changé de noyau/microcode, alignez les nœuds et redémarrez pour obtenir une base cohérente.
8) Symptom : la VM ne démarre qu’après que vous ayez retiré un seul flag de « mitigation de sécurité »
- Cause racine : Vous avez copié un ensemble de flags CPU depuis une génération différente de CPU. Certains flags de mitigation correspondent à des capacités et MSR spécifiques qui peuvent ne pas exister partout.
- Correction : Cessez d’activer manuellement des flags de mitigation sauf si vous savez exactement ce qu’ils font. Utilisez des modèles CPU supportés et laissez QEMU/KVM gérer des valeurs par défaut raisonnables pour vos versions.
Trois mini-récits d’entreprise issus du terrain
Mini-récit 1 : L’incident causé par une mauvaise hypothèse
Une entreprise de taille moyenne exploitait un cluster Proxmox à deux nœuds qui « évidemment » avait les mêmes CPUs. Les achats avaient commandé deux serveurs chez le même fournisseur le même trimestre. Les fiches techniques correspondaient. L’équipe avait configuré la plupart des VM de production sur cpu: host pour des performances maximales.
Pendant un redémarrage de routine d’un hôte, plusieurs VM ont échoué à démarrer sur le nœud survivant. L’erreur ressemblait à un échec QEMU générique au premier abord. Sous pression, l’équipe a cherché des fantômes de stockage et de réseau — parce que ce sont les problèmes qui cassent habituellement dans leur univers.
La cause racine : un nœud avait un stepping CPU légèrement plus récent et un microcode différent, exposant quelques flags que l’autre nœud n’avait pas. Quand les VMs ont atterri sur le nœud plus ancien, KVM a refusé l’ensemble de CPUID demandé. L’hypothèse n’était pas « ces serveurs sont identiques ». C’était « identiques est assez proche ». Ce n’est pas.
Ils ont récupéré en passant les VMs affectées sur un modèle CPU conservateur que les deux nœuds supportaient, puis ont planifié un inventaire matériel et une normalisation. L’incident n’a pas été dramatique. Il a été pire : évitable et ennuyeux.
La correction durable a été culturelle : tout changement affectant la compatibilité de migration nécessite maintenant de vérifier que le modèle CPU existe et est compatible sur les nœuds avant la fenêtre de maintenance.
Mini-récit 2 : L’optimisation qui s’est retournée contre eux
Une équipe plateforme interne hébergeait des workers de build et runners CI dans des VM Proxmox. Ils cherchaient à accélérer les compilations, alors ils sont passés d’un modèle CPU de base à host et ont ajouté des flags pour AES et AVX2 « au cas où ». Les performances ont effectivement augmenté sur le nœud principal.
Puis un nœud est allé en maintenance, et l’ordonnanceur a déplacé des VMs. Certains invités ont démarré, d’autres non. Ceux qui démarraient produisaient des échecs de build étranges, non reproductibles. C’est le genre de bug qui fait douter de sa carrière.
Le problème n’était pas « AVX2 est mauvais ». Le problème était l’hétérogénéité : un nœud supportait un ensemble de fonctionnalités et un comportement microarchitectural que l’autre n’avait pas, et les runners n’étaient pas fixés. Le système de build s’est retrouvé avec une flotte où des binaires étaient parfois construits avec des capacités CPU différentes, et les tests se comportaient différemment selon le timing et les accélérations crypto.
Ils sont revenus à un type CPU de base pour les runners, et n’ont permis host que pour des workloads performants non migrables avec règles de placement explicites. L’équipe a aussi cessé de saupoudrer des flags CPU comme du sel. Si vous n’avez pas de mesure et un plan de rollback, vous n’optimisez pas — vous jouez.
Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une organisation financière hébergeait des VM Windows critiques sur Proxmox. Ils n’étaient pas tape-à-l’œil ; ils avaient juste de la discipline. Avant tout changement lié au matériel d’une VM (CPU, firmware/mode BIOS, type de machine), ils faisaient deux actions : un snapshot de la config du fichier VM et une procédure de rollback testée.
Un vendredi, quelqu’un a changé le type de CPU d’une VM pour « correspondre aux autres serveurs » afin de pouvoir live-migrer pendant le patching. La VM n’a pas démarré. Le message d’erreur mentionnait une fonctionnalité CPUID non supportée. Le niveau de stress a monté ; c’était la semaine de paie, évidemment.
Le SRE d’astreinte n’a pas négocié avec l’univers. Il a restauré le /etc/pve/qemu-server/<vmid>.conf antérieur depuis leur copie sauvegardée, a démarré la VM et a remis l’entreprise en marche. Puis il a ouvert un CR avec deux suivis : choisir un modèle CPU baseline supporté sur tous les nœuds et planifier le changement pendant une fenêtre où l’activation et la validation pourraient avoir lieu.
C’est ça, les pratiques ennuyeuses : elles semblent lentes jusqu’au jour où vous en avez besoin. Ce jour-là, elles sont la chose la plus rapide que vous ayez.
Listes de contrôle / plan étape par étape
Plan de récupération étape par étape (mentalité temps d’arrêt minimum)
- Capturer les preuves. Sauvegardez la config actuelle de la VM et la sortie du log de tâche. Vous voulez apprendre quelque chose, pas juste restaurer le service.
- Lire l’erreur QEMU/KVM. Ne touchez pas aux réglages avant de savoir si c’est « modèle invalide » vs « fonctionnalité non supportée » vs « échec d’initialisation KVM ».
- Rollback du type de CPU au dernier connu bon. Si la VM tournait plus tôt aujourd’hui, revenez en arrière. Démarrez la VM. Restaurez le service.
- Si le rollback échoue, supprimez la personnalisation. Supprimez les flags personnalisés et toute ligne
args:affectant-cpu. Simplifiez la config jusqu’à ce qu’elle démarre. - Si cela échoue encore, vérifiez la virtualisation hôte. Vérifiez modules KVM, flags CPU et réglages BIOS. Redémarrez l’hôte si nécessaire.
- Une fois démarrée, validez la santé de l’invité. Accès console, disques, réseau, services. Surveillez licences et problèmes de drivers.
- Ce n’est qu’ensuite que vous retentez un changement de CPU. Choisissez un modèle de base existant sur tous les nœuds. Testez le démarrage sur chaque nœud si la migration importe.
Checklist : choisir un type CPU qui ne vous trahira pas plus tard
- Si la VM ne migre jamais et que vous voulez la performance :
cpu: hostconvient, mais documentez que c’est épinglé à un matériel compatible. - Si la VM peut migrer dans un cluster homogène : choisissez un modèle nommé qui existe et est supporté sur tous les nœuds.
- Si le cluster est mixte ou si vous prévoyez des changements matériels : choisissez une base conservatrice (
x86-64-v2ou similaire) et acceptez le léger compromis de performance. - Évitez les flags CPU manuels sauf si vous pouvez expliquer chacun, le tester et le rollbacker.
Checklist : procédure de changement sûr (ce que je ferais en production)
- Enregistrer la config actuelle : copier
/etc/pve/qemu-server/<vmid>.conf. - Confirmer que QEMU supporte le modèle CPU cible sur chaque nœud.
- Confirmer que les CPU physiques supportent les flags nécessaires sur chaque nœud.
- Planifier les effets côté invité (activation Windows, virtualisation imbriquée, changements de clocksource noyau).
- Changer d’abord seulement le type CPU. Démarrer et valider.
- Après succès : envisager d’autres optimisations (NUMA, hugepages, pinning), une modification à la fois.
FAQ
1) Pourquoi Proxmox me laisse-t-il sélectionner un type de CPU que l’hôte ne peut pas exécuter ?
Parce que Proxmox n’est pas votre maman. Il transmet votre requête à QEMU/KVM ; KVM applique la réalité matérielle au moment du démarrage. Certaines incompatibilités ne sont connues que lorsque QEMU assemble la définition finale du CPU.
2) Est-ce que cpu: host est toujours le meilleur choix ?
Meilleur pour la performance sur un seul nœud, souvent. Pire pour la migration sur matériel mixte. Si vous avez besoin de mobilité, choisissez un modèle CPU de base et acceptez que « maximum de flags partout » ne vaut pas « opérations fiables ».
3) Quelle est la différence entre modèles nommés (Skylake, EPYC) et x86-64-v2/v3 ?
Les modèles nommés correspondent à des microarchitectures spécifiques avec des bundles de flags. Les niveaux x86-64-v* visent une baseline ISA standardisée minimale. Les baselines sont généralement meilleures pour la portabilité ; les modèles nommés peuvent mieux garantir la performance dans une flotte connue.
4) La VM démarre après le changement de CPU, mais les performances ont chuté. Dois-je revenir en arrière ?
Si la charge utilise crypto/compression/instructions vectorielles, vous avez probablement retiré une fonctionnalité dont elle dépendait. Confirmez en comparant les flags CPU côté invité avant/après (ou en vérifiant la ligne CPU effective de QEMU). Si les performances sont critiques, revenez en arrière et choisissez une base qui conserve les fonctionnalités nécessaires sur tous les nœuds.
5) Un changement de type de CPU peut-il corrompre les disques ou les données ?
Pas directement. Les changements de modèle CPU affectent l’exposition d’instructions, pas les écritures de stockage. Le vrai risque est indirect : crashs, système invité ne s’arrêtant pas proprement, ou problèmes applicatifs après des démarrages instables. Traitez-le comme tout changement d’identité matérielle : validez l’invité et les applications.
6) Pourquoi la migration à chaud a-t-elle soudainement échoué après que j’ai changé le type de CPU ?
La migration à chaud nécessite une compatibilité CPU entre source et cible. Si vous êtes passé à host sur un CPU plus récent, la VM peut maintenant exiger des fonctionnalités absentes sur un autre nœud. Utilisez un type CPU baseline de cluster pour rendre la migration prévisible.
7) Dois-je arrêter la VM pour changer le type de CPU ?
Oui, en pratique. Un modèle CPU est établi au démarrage de la VM. Vous pouvez modifier la configuration en direct, mais elle ne s’appliquera qu’au prochain démarrage. Aussi : changer le type CPU sur une VM en production en disant « on redémarrera plus tard » est la façon de poser des pièges pour votre futur vous.
8) Comment savoir quel modèle CPU l’invité voit réellement ?
Sur l’hôte, utilisez qm showcmd <vmid> pour voir l’argument -cpu effectif. Dans les invités Linux, lscpu et /proc/cpuinfo montrent ce que l’invité croit voir. Sous Windows, vérifiez le nom CPU dans le Gestionnaire des tâches et utilisez les outils d’information système.
9) Quel est le type CPU « générique » le plus sûr pour un cluster Intel mixte ?
Souvent x86-64-v2 est un bon point de départ si vos nœuds sont raisonnablement modernes. Si vos nœuds sont plus récents et que vous avez vérifié le support partout, x86-64-v3 peut être un bon compromis. Ne devinez pas — validez sur chaque nœud.
10) Nous avons des nœuds Intel et AMD. Pouvons-nous migrer la même VM entre les deux ?
Parfois, mais c’est délicat. Les différences de fournisseur, les chaînes CPUID exposées et les ensembles de fonctionnalités peuvent casser des hypothèses. Si vous devez le faire, utilisez des baselines conservatrices et testez les migrations. Dans beaucoup d’environnements, la bonne réponse est « ne pas mélanger les fournisseurs dans un domaine de migration ».
Conclusion : actions suivantes pour éviter la répétition
Quand une VM Proxmox ne démarre pas après un changement de type de CPU, le bon mouvement est presque toujours : lire l’erreur QEMU, revenir au dernier état connu bon, démarrer la VM, puis choisir une baseline CPU qui correspond à votre réalité opérationnelle.
Actions pratiques :
- Standardiser une politique de type CPU par classe de VM : les VMs performantes épinglées peuvent utiliser
host; les VMs migrables doivent utiliser une baseline supportée sur tous les nœuds. - Éliminer les surcouches furtives : retirez les lignes
args:risquées sauf si vous pouvez les justifier et les tester. - Inventorier et aligner le cluster : modèles CPU, microcode, réglages BIOS de virtualisation, et versions Proxmox/QEMU ne doivent pas diverger sans contrôle.
- Rendre les sauvegardes de config routinières et ennuyeuses : sauvegarder un fichier de config VM avant tout changement est l’habitude barbante qui réduit la durée des incidents.
Une idée fiabiliste paraphrasée de Werner Vogels : Tout échoue, donc construisez des systèmes qui s’attendent à l’échec et rendez la récupération rapide.
Cela s’applique ici. Les changements de type de CPU sont récupérables — si vous les traitez comme de véritables changements en production, pas comme une aventure dans un menu déroulant.