Vous n'arrivez pas à démarrer votre VM AlmaLinux 10 sur Proxmox ?

Le symptôme : un job GitLab qui s'arrête en une ligne

Nous maintenons un dépôt non officiel de proxmox-backup-client (page en anglais, code source sur GitHub), qui reconditionne les binaires officiels pour d'autres distributions, afin que nos utilisateurs puissent sauvegarder sur Nimbus Backup depuis ces systèmes. Le tutoriel pour sauvegarder un serveur Linux avec proxmox-backup-client détaille l'installation. La CI GitLab du dépôt teste l'installation des paquets dans 27 conteneurs, dont almalinux:10.

Les runners utilisent l'exécuteur Docker et tournent dans des VM de notre cluster Proxmox VE 9.2.5. Les nœuds sont des AMD EPYC 7702 (64 cœurs, 128 threads). La VM du runner concerné est en type de CPU x86-64-v2-AES, celui que Proxmox propose par défaut à la création. Le conteneur almalinux:10 ne démarre même pas :

Using Docker executor with image almalinux:10 ...
Executing "step_script" stage of the job script
Fatal glibc error: CPU does not support x86-64-v3
ERROR: Job failed: exit code 127

Le matériel n'est pas en cause. L'EPYC 7702 (Zen 2, « Rome ») gère AVX2 : il supporte x86-64-v3. Il ne va pas jusqu'à x86-64-v4, faute d'AVX-512, et nous l'avons vérifié à nos dépens (voir plus bas). C'est le cas typique d'un serveur récent dont la VM est bridée par son type de CPU.

Lors d'une installation directe en VM, le message n'apparaît pas toujours à l'écran. Sur le forum Proxmox, les utilisateurs décrivent un installateur qui revient en boucle au menu de démarrage ou une VM qui redémarre juste après GRUB.

La cause : x86-64-v3 exigé, x86-64-v2-AES proposé

RHEL 10 est compilé pour x86-64-v3 et abandonne de nombreux processeurs plus anciens. Red Hat documente ce blocage dans sa fiche « RHEL 10 cannot boot on older CPU that does not support x86-64-v3 ». AlmaLinux 10 suit ce choix par défaut, et Rocky Linux 10 aussi.

Proxmox propose x86-64-v2-AES par défaut pour une nouvelle VM. Ce type n'expose pas AVX2, même quand le processeur physique le gère.

Docker ne contourne rien : un conteneur n'a pas de processeur virtuel à lui, il utilise celui que la VM voit. Si la VM n'expose pas x86-64-v3, un conteneur AlmaLinux 10, RHEL 10 ou Rocky Linux 10 plante de la même façon, quel que soit l'hôte physique.

Un conteneur LXC Proxmox n'est pas concerné de la même façon : il n'a pas de type de CPU, partage le noyau de l'hôte et voit directement le processeur physique. Il ne rencontre ce blocage que si le processeur physique lui-même n'a pas AVX2.

Vérifier avant de changer quoi que ce soit

Lancez la même commande sur chaque nœud Proxmox, puis dans la VM concernée (celle du runner, par exemple) :

grep -o -w -E 'avx2|bmi2|fma|movbe' /proc/cpuinfo | sort -u

• Si avx2 apparaît sur le nœud mais pas dans la VM, c'est le type de CPU de la VM qui le masque.
• Si avx2 manque sur le nœud lui-même, aucun type de CPU n'y changera rien : voir le cas du matériel sans AVX2 plus bas.

Les corrections, avec leurs conséquences

x86-64-v3 : le bon choix par défaut en cluster

Si tous les nœuds du cluster sont Intel Haswell, AMD EPYC ou plus récents, x86-64-v3 donne à la VM ce qu'exige AlmaLinux 10 tout en gardant la migration à chaud entre ces nœuds.

qm set <vmid> --cpu x86-64-v3

x86-64-v4 : pas plus haut que ce que l'hôte gère

x86-64-v3 aurait suffi. Nous avons préféré tenter directement x86-64-v4, le niveau au-dessus. Ce type ajoute l'AVX-512 et, selon la documentation Proxmox, demande un Intel Skylake ou un AMD EPYC Genoa au minimum. L'EPYC 7702 n'a pas d'AVX-512 : la VM refuse de démarrer.

kvm: warning: host doesn't support requested feature: CPUID[eax=07h,ecx=00h].EBX.avx512f [bit 16]
… avx512dq, avx512cd, avx512bw, avx512vl …
kvm: Host doesn't support requested features
TASK ERROR: start failed: QEMU exited with code 1

AlmaLinux 10 n'a besoin que de x86-64-v3. Viser plus haut n'apporte rien ici, et empêche la VM de démarrer sur un nœud qui n'a pas ces instructions.

host : le plus performant, sans migration vers un nœud différent

Avec host, la VM reçoit exactement les instructions du processeur hôte. C'est le type le plus performant. En contrepartie, une migration à chaud vers un nœud qui n'a pas ces instructions échoue (le processus QEMU s'arrête), et la migration entre Intel et AMD n'est pas garantie.

qm set <vmid> --cpu host

C'est sur ce type que nous nous sommes repliés après l'échec de x86-64-v4 : nos VM gitlab-runner sont passées en host, suivi d'un redémarrage de la VM. Le pipeline est repassé au vert. Elles tournent dans un cluster dont les nœuds ont tous le même processeur : la migration à chaud reste possible entre eux. Si votre VM doit pouvoir migrer entre des nœuds différents, préférez x86-64-v3.

qm reboot <vmid>    # arrêt + démarrage, applique le nouveau type de CPU

Matériel sans AVX2 : la variante x86_64_v2 d'AlmaLinux

AlmaLinux 10 est compilé en x86-64-v3 comme RHEL, mais publie aussi une architecture x86_64_v2 (ISO et dépôts séparés) pour le matériel ancien.

• Pour une VM : installez depuis l'ISO AlmaLinux 10 x86_64_v2.
• Pour Docker : l'image officielle almalinux:10 (Docker Official Library) n'existe pas en linux/amd64/v2. Les variantes v2 sont publiées uniquement dans les images maintenues par AlmaLinux (almalinux/10-base, almalinux/10-minimal, almalinux/10-init…).

docker pull --platform linux/amd64/v2 almalinux/10-minimal

La limite : AlmaLinux la réserve au matériel ancien, et les dépôts tiers publient rarement pour cette variante. Elle ne convient donc que si les paquets de base suffisent, sauf à recompiler vous-même. Une recompilation d'EPEL pour v2 a été approuvée. Rocky Linux 10 et RHEL 10 n'ont pas cette porte de sortie : Rocky Linux 10 ne publie pas de version x86-64-v2.

Le cas du cluster : le nœud le plus ancien fixe la limite

Vous arrivez de VMware ?

Le blocage n'est pas propre à Proxmox. Le même message apparaît sous VirtualBox et sous VMware vSphere avec EVC en mode Sandy Bridge, qui masque AVX2. Un cluster vSphere réglé ainsi pour garder la migration entre des hôtes anciens et récents pose exactement le même problème que x86-64-v2-AES sous Proxmox.

Si vous migrez des VM depuis vSphere, choisissez le type de CPU à la création de chaque VM Proxmox, en fonction des nœuds du cluster cible. Notre guide de migration VMware vers Proxmox détaille les autres réglages après bascule, et la page migration VMware vers Proxmox décrit comment nous menons ces projets.

Questions fréquentes

Sources

Articles connexes