Proxmox VE débarque officiellement sur Arm64
Le Raspberry Pi reste à quai
C’est un changement important : Proxmox est officiellement disponible sur des machines avec un SoC Arm. Cela fait suite à un partenariat avec NVIDIA, dont les plateformes sont les seules à être entièrement supportées. Pour les autres machines, c’est du « best effort ». Proxmox promet une parité de fonctionnalités et de calendrier de déploiement entre les deux architectures.
Jusqu’à présent, Proxmox VE était disponible uniquement en x86-64, rappelle Proxmox. L’entreprise autrichienne annonce aujourd’hui « la première version de Proxmox Virtual Environment avec un support officiel pour une seconde architecture CPU : ARM 64 bits ».
Pour rappel, Proxmox est une plateforme open source de virtualisation, disponible avec un support entreprise payant et un accès au dépôt Enterprise en option. Accessible via une interface web, elle permet de gérer des machines virtuelles et des conteneurs. Vous pouvez lancer plusieurs machines avec des systèmes d’exploitation variés, allant de Linux à Windows (il suffit de télécharger une image ISO).
Fully supported ou best effort, cela dépend des SoC
Côté architecture interne de la partie logicielle, pas de changement : « Proxmox VE 9.2 pour arm64 partage sa base de code, ses dépôts de paquets et son cycle de publication avec son équivalent x86-64. Il repose sur Debian 13.5 « Trixie » avec le noyau Linux 7.0 comme version stable par défaut et intègre […] QEMU 11.0, LXC 7.0 et ZFS 2.4 ». Les notes de version entre les deux déclinaisons x86-64 et Arm64 seront d’ailleurs communes pour les prochaines moutures.
Les habitués de l’hyperviseur ne seront pas dépaysés : « La configuration, les outils et la documentation sont identiques à ceux de l’architecture x86-64 », affirme Proxmox. Les SoC avec une architecture ARMv9-A ou plus récente sont supportés en mode « best effort ». L’équipe ajoute aussi qu’« ARMv8-A fonctionne généralement aussi bien, aussi en mode meilleur effort ». Des technologies x86-64 comme AMD SEV (chiffrement de la mémoire) et Intel GVT-g pour le passthrough GPU ne sont pas disponibles.
Proxmox adresse un « merci tout particulier à NVIDIA pour leur confiance et leur collaboration étroite sur ce portage ». Conséquence directe de ce partenariat, Proxmox VE en version Arm est évidemment compatible avec les plateformes Grace Hopper et Vera. Ce sont d’ailleurs les deux seules en mode « fully supported », là où toutes les autres sont en mode « best effort ».
UEFI et ACPI obligatoires, au revoir le Raspberry Pi
Quelques limitations : le boot doit se faire via UEFI et l’hôte doit décrire son matériel via ACPI (Advanced Configuration and Power Interface). Ce n’est pas le cas de certains systèmes embarqués et Single-Board Computer (SBC), notamment le Raspberry Pi qui n’est pas pris en charge.
Proxmox ajoute que des travaux internes sont en cours pour d’autres produits, notamment Proxmox Backup Server ; l’entreprise est d’ailleurs confiante dans la disponibilité future, sans plus de précisions. Elle ajoute : « les produits que nous priorisons dépendent des besoins de nos clients entreprises » ; la société invite donc les pros intéressés à la contacter.
La foire aux questions aborde d’autres sujets, notamment un mélange de nœuds x86-64 et arm64 dans un même cluster : « Ce n’est pas bloqué techniquement, mais les clusters à architecture mixte ne sont pas officiellement pris en charge ».
Commentaires (15)
Abonnez-vous pour prendre part au débat
Déjà abonné ou lecteur ? Se connecter
Cet article est en accès libre, mais il est le produit d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles d'un média expert
Profitez d'au moins 1 To de stockage pour vos sauvegardes
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 5 août à 17h48
Le 6 août à 08h14
UEFI a remplacé le système du BIOS pour proposer une solution bien plus complexe comme pour séparer le Matériel de l'OS.
Quelle serait la solution la plus viable pour remplacer l'UEFI ?
Le 6 août à 10h18
Le 7 août à 07h53
Le 6 août à 10h45
Sinon wintel (windows intel)
Le 6 août à 08h37
Le 6 août à 10h46
Le 6 août à 10h28
C'est un fléau de ne pas avoir un système générique qui ne nécessite pas d'avoir intégré les device-tree de chaque appareil.
Et là on parle même pas du support mainline du matériel dans le kernel linux.
Ma meilleur expérience ARM linux, c'est sur un mac... Un comble alors que Linux est le système qui gère le mieux les architectures ARM et depuis très longtemps.
Le 10 août à 09h30
Le truc finissant dans un assemblage improbable et bardé de doublons (grosso modo de l'odre de grandeur des 3 phases "étanches" SEC/PEI/DEX multiplié par le nb d'origine du soft: EDK2, Ref-Code fondeur, code de l'éditeur de BIOS ; chacun venant idéalement avec sa chaîne de compilation) et cauchemar à maintenir, tombant en marche en plus de temps qu'il n'en faut pour booter l'OS complet derrière: Ahurissant.
Modifié le 12 août à 01h06
Je ne suis pas contre faire autrement, mais l'usage fait standard, comme l'UEFI sur x86 moderne, que l'on veuille ou non.
AsahiLinux utilise UEFI via U-Boot alors qu'il est inexistant sur les plateformes arm d'Apple.
Le 12 août à 18h29
Et ici, aucun service à la base: Juste déclarer le matériel (qui peut aussi ammener ses bouts de DT pour faire du plug&play).
Le pb de Microsoft, c'est qu'ils n'ont jamais su se passer de services du boot-loader. Ca a commencé avec les "interruptions" (je mets des guillemets, car c'est plutôt assimilables à des service-call aux firmwares modernes inévitables avec les enclaves sécurisées) BIOS qui faisaient le nid des véroles de secteur de boot dès les débuts du PC.
Linux se passe très bien de ce foutoir.
Le 12 août à 23h27
Les gens (pas moi) utilisent Windows pour les applications déjà existantes. Avoir Windows sans les apps, c'est inutile (voir le mode S de Windows)
Moi je constate l'échec aussi des machines Linux sur ARM. Pas parce que ça ne marche pas, juste par la complexité suivant le matériel, les supports entre distros, je ne parle même pas de bugs ou encore des firmwares.
J'ai fait deux tests non concluants avec le Pinebook Pro et l'Acer Aspire 1 (A114-61) ARM.
Le premier, le support était OK sans plus, wifi / bluetooth avec antenne 1x1, son horrible, trackpad "flou".
Le deuxième épouvantable au possible : un dev russe, les commits ont été reverse, seule la distro PostMarketOs (pas glibc, musl, oblige un container pour les apps non compatible) le supportait.
Après avoir cassé la tirelire, j'ai acheté un Apple Mac Studio M2 Max pour installer Asahi (Fedora 42) et c’était cool quand il y avait encore le dev principal et la dev du pilote kernel GPU avant les clashs lors des demandes d'upstream (nanani le rust, nanana le c)
Expérience : je veux un ordinateur (pas une carte SBC) à base ARM, qu'est-ce qu'il y a de disponible avec un score Geekbench single > 2000 et multi > 10000 ?
Réponse quasiment rien,
D'ailleurs j'ai lu un retour de détection de corruption mémoire, ça m'a refroidi, dommage le prix est super, même avec 64 Go de RAM.
Donc retour à la case départ, un PC x86 ITX avec gros iGPU : la carte mère du Framework Desktop
AMD Ryzen AI Max 395+ : 120/140W pour 3000 single core, 24000 multicore sur GeekBench 6
Sur le mac studio : 80W pour 2700 single et 15000
Donc peut-être que UEFI c'est nul, le problème c'est que les machines vendues seront là pour Windows 11 ARM.
Le 7 août à 11h48
(j'avais renoncé à faire tourner des vrais services Web sur Raspi à cause de la "fragilité" des cartes SD mais avec un vrai SSD et proxmox ça peut désormais être une solution stable).
Le 7 août à 12h11
Le 11 août à 12h06
mon plus gros probème était la surchauffe du PI mais j'ai mis un gros dissipateur actif pris en chine et ça roule maintenant.
autant les SD je les changeaient tous les ans avant maintenant le SSD pourtant pas récent ne bouge pas
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?