Si tout le monde se focalise sur Windows 10 à l'occasion du support de nouveaux processeurs, qu'en est-il sous Linux ? Pour le savoir, nous avons tenté d'installer différentes distributions et hyperviseurs sur une carte mère X570 Taichi d'ASRock équipée d'un Ryzen 7 3700X afin de voir si tout fonctionnait sans accroc.
Depuis le lancement de ses Ryzen de première génération, puis des Threadripper pouvant aller jusqu'à 32 cœurs via quatre dies dans un même packaging, AMD a dû faire un gros travail d'optimisation logicielle, notamment avec Microsoft pour Windows 10. On l'a vu lors de notre analyse, la May 2019 Update apporte d'ailleurs son lot d'optimisations.
Mais qu'en est-il de Linux ? Sur ce point, le constructeur donne peu de détails, mais on sait qu'il travaille assez ouvertement sur des patchs et autres améliorations du noyau et des pilotes pour assurer le bon fonctionnement de ses CPU et GPU. Suffisant pour assurer un support dans différentes distributions et/ou hyperviseurs ?
C'est ce que nous avons voulu vérifier.
CentOS 7, Debian 10, Ubuntu 18.04 LTS/18.10 : ça marche
Nous avons commencé par les cas les plus souvent complexes : les distributions à évolution lente. Celles qui utilisent un noyau un peu daté, qui ne sont pas de dernière fraîcheur. Nous les avons installées sur une machine équipée d'un Ryzen 7 3700X sur une carte mère X570 Taichi avec son BIOS/UEFI 1.41 et 16 Go de DDR4 à 3,2 GHz.
AMD a de la chance avec Debian, puisque sa dixième itération (Buster), vient de sortir avec un noyau 4.19 bien plus récent. Tout fonctionne donc parfaitement, de l'installation à nos tests de compilation de Blender et de performances avec le rendu headless de la scène BMW27 ou le test intégré d'OpenSSL.
Idem pour Ubuntu 18.04 LTS/18.10 où tout se passe sans accroc. Même CentOS 7 (1810), pourtant un cas souvent compliqué, n'a pas vraiment posé de problème. Nous avons bien eu une alerte ou deux avant que le système ne soit opérationnel concernant le CPU qui ne serait pas parfaitement reconnu. Mais au final, tout roule.
Dans ces trois cas, nous avons un bon niveau de performances, identique à ce que nous relevons sous Windows dans des conditions similaires. Meilleur même pour la compilation puisque nous n'avons pas à faire avec l'impact négatif sur le système de fichiers du sous-système Linux actuel (qui sera bientôt remplacé).
Seule exception : nous n'avons pas pu compiler Blender sous CentOS 7, la version de GCC (entre autres) fournie par défaut sur ce système étant trop datée.
OpenSSL - Signatures par secondes :
- CentOS 7 : 309
- Debian 10 : 304
- Ubuntu 18.04 LTS : 306
OpenSSL - Vérifications par secondes :
- CentOS 7 : 20 098
- Debian 10 : 19 812
- Ubuntu 18.04 LTS : 20 147
Compilation Blender :
- Debian 10 : 118 s
- Ubuntu 18.04 LTS : 126 s
Rendu Blender headless - BMW27 :
- Debian 10 : 132 s
- Ubuntu 18.04 LTS : 135 s
Fedora 30, Manjaro, Ubuntu 19.04 : c'est compliqué
Un problème survient par contre avec des versions plus récentes de ces distributions. Nous l'avons rencontré avec la dernière mouture de Fedora. Idem pour Manjaro ou Ubuntu 19.04.
Dans tous les cas, le symptôme est le même : de multiples erreurs de démarrage des services via systemd dès l'installation ou à l'initialisation du système d'exploitation :
Des patchs sont déjà en préparation et devraient régler rapidement la situation, en attendant l'intégration à une nouvelle version des ISO. Avec une installation de type netboot, l'utilisateur téléchargera en effet la version corrigée des paquets concernés, de quoi éviter le souci une fois la mise à jour distribuée.
Proxmox, VMWare ESXi : virtualisez comme vous voulez
Il y a un autre environnement où la compatibilité avec Linux peut rapidement montrer ses limites, c'est celui de la virtualisation. Nous avons donc activé les options nécessaires de la carte mère (SVM, IOMMU) puis installé deux hyperviseurs : la version gratuite d'ESXi de VMWare (6.7 Update 2), et Proxmox (5.4) qui se base sur le duo Debian/KVM.
Notre carte mère a été parfaitement reconnue dans les deux cas, tout comme le CPU. Nous avons ainsi pu installer un Windows 10 virtualisé et l'utiliser sans problème. Il nous est pour le moment impossible d'utiliser une carte graphique en passtrough sous Proxmox en raison des groupes IOMMU de la carte mère. Nous tâcherons de mieux cerner le souci dans un second temps, notamment avec une carte mère serveur comme la X470D4U. Aucun problème en revanche avec ESXi.
Les performances relevées sont proches de celles sous Windows, excepté pour ESXi puisque le système virtualisé doit se contenter de huit cœurs au maximum dans sa version gratuite.
Commentaires (32)
#1
J’étais justement en train de préparer une machine linux pour accueillir le ryzen 2 qui arrive par la poste.
Merci pour cet article
#2
(Impossible d’éditer mon message ci-dessus désolé.)
Je viens de lire l’article, vous ne parlez pas de virtualbox (que j’ai l’habitude d’utiliser sur mes machines windows), il y a une raison pratique à cela ? (genre gros problème sous linux ?)
Et merci pour les test, je vais rester en LTS et attendre les patchs avant de passer à Disco.
#3
Concernant Proxmox, en 5.4 sur ma Asus prime x470 + Ryzen 2700x, impossible également de faire du gpu passtrough avec le dernier bios de la cm. D après les forums, noyau trop ancien, ça ne serait pas identique en x570 ?
J ai du downgrader le bios , s était loin d une partie de plaisir !
#4
VB est plutôt du côté utilisateur, un peu comme VMWare Player/Workstation. C’est une application plus qu’un OS à installer (contrairement à Proxmox/ESXi), du coup le support de la VT dépend surtout de l’OS plus que d’un lien profond avec le noyau.
Disons que pou le moment j’attend que les choses se tassent côté BIOS/UEFI avant de rententer de me plonger là dedans en profondeur
#5
Pour compiler blender sous centos 7, il y a SCL
yum install centos-release-scl
yum install devtoolset-7
scl enable devtoolset-7 bash
Et hop on passe de gcc 4.8 à gcc 7.3
#6
Merci pour ces précisions
#7
Oui comme dit c’est juste que ce n’était pas présent “from scratch” les performances étaient de toutes façons du même niveau sur les trois distributions (comme on le voit avec OpenSSL). De toutes façons il faudra sans doute attendre un noyau plus récent pour que toutes les fonctionnalités de Zen 2 soient implémentées, j’attend des confirmations là dessus
#8
J’ai d’ailleurs la même limitation sur Unraid et les gens parlent de la version 5 du noyau. J’espère que la 4.19 suffit car l’attente risque d’être longue
#9
Merci! Des informations très intéressantes et qu’on ne retrouve pas partout: des tests d’os de virtualisation.
Les cartes mères grand public ne sont pas les plus simples pour le passthrough avec des groupes IOMMU généralement assez peu nombreux donc rassemblant souvent trop de choses. :(
#10
Disons que ce qui m’étonne c’est que ça fonctionne sous ESXi mais pas Proxmox, m’enfin comme dit par Balooforever, ça peut tenir de détails côté support logiciel.
#11
Vous savez si le bug VME a été corrigé ? Il était impossible de virtualiser du 32 bits.
J’ai un freeze total du PC avec un Threadripper 1ère gen (avec HyperV) pendant l’installation de Windows 7 32 bits.
#12
Peut-être un patch nécessaire pour QEmu/KVM.
#13
Pour Proxmox la première beta de la version 6 est sortie il y a quelques jours, la version utilisée de qemu fait un gros bon en avant il me semble (v2 vers vers v4).
Peux être ça passe mieux? (et en même temps c’est un kernel 5 donc potentiellement le même problème qu’avec les autres distribution récente).
#14
Je vais regarder ça merci
Le lien pour ceux qui cherchent
#15
Quelqu’un a pu essayer Proton/Wine avec DXVK ?
#16
Du peu que j’ai vu (je me suis mis à KVM/QEMU récemment), il faut nécessairement une seconde carte graphique pour le système invité.
En passtrough, ça veut dire que l’invité exploite la carte utilisé par l’hôte ?
#17
Et vu que je ne suis pas un gros débile, il y avait bien deux cartes graphiques dans la machine de test, c’est notamment pour ça que ça fonctionne sur ESXi ;)
#18
Mais j’ai jamais dit que t’étais débile.
Par contre, je pensais que la seconde carte était obligatoire si on était pas en passtrough.
Du coup, bye bye mes espoirs avec KVM/QEMU. :(
#19
Chui encore un peu frilleu avec le gaming sur hyperviseur… c’est vraiment aussi efficace qu’une config’ classique pour des truc en surround gaming, carte son 7.1 etc ?
#20
quelles distributions pour les Ryzen de 3ème génération ?
Gentoo bien sur, sinon le CPU il roupille
Pour le problème de boot ca dépend de systemd mais ca va se fixer aussi via le bios (https://www.phoronix.com/scan.php?page=news_item&px=AMD-Releases-Linux-Zen2-Fix).
#21
Si t’es en passtrhough sur le GPU oui, après côté CPU ça se discute puisqu’il est forcément partagé, mais l’idée en général c’est d’avoir un CPU pour tout, et un GPU par utilisateur “réel” un peu à la manière de Shadow.
Un usage “fun” c’est d’avoir une sorte de workstation hyper convergée : un OS type hypeviseur de niveau 1, un GPU en passthrough sur un système principal et plein de petites VM annexes qui tournent en //.
Avec le 12 coeurs Ryzen c’est pas mal de pouvoir monter ça sur 8 coeurs pour le principal et 4 pour le reste. Avec une carte Pro on peut même gérer ça à distance et se connecter à la machine via un client fin à base de contrôle distant Windows ou de Parsec par exemple
#22
Ben ouè ça m’intéresse beaucoup :) C’est pour ça que mon portable est sur W10 Pro, Hyper-V natif ça marche vraiment top. J’ai toute une infra de test, des exchanges, debian, Nextcloud, apache, clusters avec nesting, FreeNAS aussi tourne beaucoup mieux sur HyperV depuis les dernières versions majeures de BSD, des UTM, … C’est vraiment tip top pour un lab de 2kg (C’est un Dell XPS de 2017 avec un 960 pro). MAIS j’ai que 32Go de RAM, qui de toute façon sont suffisant puisque le CPU est la limite. Et puis je voudrais faire un peu de vmware et esx sur hyperv ça tourne pas :(
Donc l’idée m’intéresse beaucoup bien que je reste un gros joueur donc je crains un peu les petits défauts. Ryzen c’est foutu potentiellement pas de nesting sur ces CPU et il faut désactiver le SMT pour éviter les PSOD… :/ je sais pas si c’est d’actualité sur les Zen 2 ?
#23
Sous unraid (et sous proxmox), j’utilisais la 1ere CG et la seconde en passtrough sur 2 VM différentes sans souci :)
#24
C’est exactement ce que j’ai fais
Rigolo et super efficace à l’usage, j’ai revendu mon syno ..
#25
Avec un GPU intégré côté CPU ou carte mère ? Sinon c’est difficilement possible, le système doit avoir un GPU attaché.
#26
Sans GPU dédié (avec un Ryzen 2700). Par contre, je perdais l’affichage de la console proxmox/unraid. Sous Unraid, j’ai dût lui ajouter le dump du bios pour faire le gpu passtrough sur le port 1. Sur Proxmox je me souviens avoir galéré mais je ne sais plus comment j’avais fait.
Après ça dépends peut être de la CM, c’est une Asus Prime x470-Pro et ma 1ere CG est une RX480
#27
Trop tard pour éditer. Sous Proxmox de mémoire j’avais suivi les instructions ici https://pve.proxmox.com/wiki/Pci_passthrough#Introduction
#28
Et du coup en cas de panne ?
Bon après si ça passe quand même et que tu as l’interface web ça va dans la majorité des cas, mais je préfère à minima avoir une gestion distante en dur (via BMC) pour dépanner la machine quand il y a un souci, parce que sinon… 
#29
Disons qu’après un léger souci d’erreur de configuration réseau, il a fallu .. démonter
Après, ça reste un usage “homelab”, mon utilisation n’est pas orienté pro
#30
Tu peux viser l’usage home lab tout en ayant envie de dépanner sans trop de problèmes
#31
C’est pour ça que j’ai changé d’OS, avec le nouveau comme c’est une clé usb c’est beaucoup moins compliqué à corriger en cas de souci
D’ailleurs il suffit d’inverser clavier / sourie pour que la VM ne boot pas (…) donc on récupère l’interface !
Le seul défaut finalement c’est qu’il a fallu que je l’achète !