Vous êtes beaucoup à me demander pourquoi j'ai fait le choix de passer de Proxmox à XCP-ng. Dans cet article, je vais vous présenter les deux hyperviseurs, leurs points communs, leurs différences, et mon ressenti personnel. C'est parti !
Proxmox
Proxmox Virtual Environment est une solution de virtualisation libre (licence AGPLv3) basée sur l'hyperviseur Linux KVM, et offre aussi une solution de containers avec LXC. Elle propose un support payant. Elle est fournie avec un packaging par Proxmox Server Solutions GmbH.
Proxmox Virtual Environment :
- Libre (AGPLv3)
- Basé sur KVM
- Propose aussi une solution de contenarisation: LXC
Dans les faits, Proxmox est basé sur Debian, auquel se rajoute le package proxmox (qui contient entre autre qemu). Proxmox propose aussi une ISO préfaite qui permet directement d'installer Proxmox sans passer par l'installation de Debian. Néanmoins, l'ISO à plusieurs limitations (pas de possibilité de créer du ZFS (edit: disponible depuis récemment) ou du Raid Soft, configuration globale assez limité et qui ne fonctionne pas forcément), il est donc recommandé (tous les Proxmoxien vous le diront !) de passer par l'installation d'un Debian et d'installer le package Proxmox ensuite.
Le package Proxmox contient aussi un kernel custom qui sera installé à la place du kernel "classique".
Il est très facile de bidouiller sur l'hôte une fois Proxmox installé. Vu que la machine hôte est finalement un Debian, il est possible de faire à peu près tout et n'importe quoi.
Je vois souvent des configurations où c'est la machine physique qui fait le routage, ou le NAT, à la place d'avoir une VM qui gère entièrement le réseau, ou des cas où des paquets supplémentaires sont installés pour pallier à des manques de fonctionnalités (je pense au S3 par exemple)
L'interface Web est directement intégrée à l'installation de la machine. Dès la fin de l'installation (et du reboot), il est directement possible de créer les VMs et commencer son infra.
Elle intègre presque tout le nécessaire pour manager son infra au quotidien. Proxmox permet aussi de faire de la High Availability (HA) via un système de cluster, basé sur Corosync. Pour créer un cluster, il vous faut au minimum 3 machines (pour le quorum) et un stockage centralisé (Un serveur NFS ou du Ceph entre les machines).
Proxmox propose aussi un OS de backup, Proxmox Backup Server, qui se connecte directement aux machines et permet d'exporter les backup des VM sur une autre machine, et de les restaurer simplement.
J'utilise Proxmox depuis que j'ai commencé à apprendre la virtualisation, vers 2018, et c'est un excellent hyperviseur pour commencer et pour se faire la main sur la gestion de la virtualisation, des VMs, mais aussi de Debian.
XCP-ng / Xen Orchestra
J'ai découvert XCP-ng chez Aqua Ray, ou j'ai bossé pendant 2 ans et demi, où la plateforme est utilisée sur presque l'intégralité des machines (des centaines !), couplé à Xen Orchestra.
XCP-ng :
- Provient de XenServer, détenu par Citrix, forké par Vates suite à l'abandon de la version gratuite et de l'impossibilité de contribuer au projet.
- Basé sur Xen, utilisant la XAPI pour communiquer entre ses composants et surtout avec l'extérieur (par exemple, Xen Orchestra)
La philosophie d'XCP-ng est complètement différente de celle de Proxmox: lorsqu'on installe un XCP-ng, une fois l'installation terminée, on ne se connecte pas sur « l'hôte » en direct comme on le ferait avec Proxmox, mais sur une VM privilégiée appellée Dom0. Le Dom0 n'a pas vocation à accueillir des packages supplémentaires.
Le Dom0 est celle qui gère les utilitaires Xen, et est la seule à avoir un accès direct au hardware de la machine. Ainsi, les VMs créées (appelées DomU, sans privilèges sur le hardware) tournent directement sur Xen.
Xen assure l'isolation entre les machines virtuelles, via des mécanismes de sécurités supplémentaires ou différents par rapport à Linux, tout en ayant une surface d'attaque réduite.
La différence de concept importante vient du fait que tout se passe à travers l'API (XAPI) et pas des commandes Linux traditionnelles : le but est d'avoir une solution clé en main (« appliance ») prête à démarrer des machines virtuelles sans autre forme de configuration (ou tout à travers son API), à travers un client (en ligne de commande ou web, cf partie suivante).
Tout cela a un impact sur la façon de gérer les VMs : là où Proxmox propose une interface web dès son installation, XCP-ng doit être couplé à Xen Orchestra [1,2], une interface web de management qui tourne sur dans une VM (ou même ailleurs).
Effectivement, la Dom0 n'a pas vocation à faire tourner des services en plus des services de gestion de Xen, d'où le besoin d'un service tournant sur une VM.
Il existe deux versions de Xen Orchestra:
- Xen Orchestra (XO) from source: un package à installer sur l'OS de votre choix, à builder via les dépots git. Idéal pour les home lab !
- Xen Orchestra Appliance (XOA): La version packagée par Vates, prête à être deployée sur votre XCP-ng ! Elle permet également d'avoir accès au support.
XO from source a exactement les mêmes fonctionnalités qu'un XOA, le support en moins, et le système de mise à jour automatisées vs un "git pull" sur la version source.
Le concept de Xen Orchestra est donc de proposer une interface centralisée pour gérer l'intégralité de votre infrastructure (et non pas une interface par machine ou par cluster), se connecter à l'API de chaque hôte. Et vu que tout passe par l'API, vous pouvez tout configurer depuis Xen Orchestra. D'ailleurs, votre Xen Orchestra peut tout à fait gérer plusieurs sites distants en même-temps, via le système de proxy.
Il est aussi quasiment « stateless », la perte de votre Xen Orchestra n'aura pas de conséquences sur vos VMs de production.
Dans un sens, XCP-ng/XO est plus proche de VMware en terme d'architecture/concept (Type 1, clé en main, vCenter centralisé) qu'un Proxmox, d'où la grande différence d'utilisation entre le deux.
[1] : Le projet XO Lite commence à proposer une interface de gestion simplifiée embarquée pour des usages basiques, tout en restant un simple « client » à la XAPI, comme XO.
[2] : vous pouvez aussi utiliser localement (dans le Dom0) la ligne de commande xe qui est un client XAPI avec de l'autocomplétion intégrée !
Mon ressenti
Proxmox est un excellent hyperviseur pour démarrer la virtualisation si l'on est habitué à gérer son Linux. Comme c'est une base Debian, on retrouve vite ses repères sur le fonctionnement de la CLI. L'interface Web n'est pas mauvaise, mais manque parfois de cohérence (parfois on peut faire un clic droit sur un objet, parfois pas...).
Le système de clustering est plutôt simple à mettre en place, mais j'ai eu pas mal de soucis avec corosync, notamment lors des updates. Le système de contenarisation LXC est aussi pratique, bien que je ne m'en suis jamais servi (Il existe un équivalent sur XCP-ng, RunX).
XCP-ng/XO, malgré sa philosophie très différente de Proxmox, m'a tout de suite fait de l’œil lors de mes premières utilisations professionnelles. L'interface web "déportée" en dehors de la machine physique est un gros plus pour manager plusieurs machines et plusieurs pools à l'échelle d'un datacenter.
Sur une seule interface. je retrouve toutes mes VMs, hôtes et autres objets essentiels de mon infrastructure virtualisée, que ce soit en pool (ie cluster) ou standalone, je peux gérer mes migrations, mon réseau, mon storage, bref, quasi tout !
Le gros plus est la gestion native des backups. Depuis l'interface Xen Orchestra, je peux paramétrer mes backups (Full, Delta, Continuous Replication...) et Xen Orchestra se charge directement de les envoyer sur mon serveur NFS ou iSCSI, et même sur du S3 ! Egalement, le système de RPU (Rolling Pool Update) qui permet en un clic de mettre à jour un pool entier de serveurs (sous réserve d'avoir un stockage partagé), ainsi que les différents types de migrations de VMs et des disques de VMs possibles (Warm Migration, migration live entre n'importe quel stockage)
Aussi, le fait que les VM tournent directement via Xen (pour la gestion des CPU et mémoire) et non pas par dessus un Debian ou autre, permet une meilleure isolation tout en gardant de très bonnes performances.
Mais alors, pourquoi je suis passé à XCP-ng ?
Ayant déjà commencé à jouer avec XCP-ng et Xen Orchestra chez Aqua Ray, j'avais déjà un aperçu de la solution. Mais ma curiosité à piqué, et j'ai commencé à jouer avec sur mes serveurs de lab. J'ai vraiment aimé le fonctionnement de la stack, et je commençais à réfléchir à migrer de Proxmox vers XCP-ng.
Et c'est à ce moment que l'ouverture et l'écoute de la communauté et des équipes de Vates m'ont convaincu de passer de l'autre coté, de KVM à Xen.
Là ou je me sentais vraiment peu à l'écoute avec Proxmox (difficile de contribuer, ou même d'avoir un simple contact avec eux), ce fût très différent chez XCP-ng/XO : je sais que si j'ai un problème ou une question, le forum est réactif et présent, avec des réponses rapides et pertinentes.
Si je veux contribuer, je peux faire un rapport de bug ou même ajouter du code ou de la documentation (déjà fait par ailleurs pour corriger des morceaux de la doc, proposer le support de Let's Encrypt sur XO, signaler un bug sur l'initialisation du RAID soft à l'installation, proposer un miroir sur https://mirrors.xcp-ng.org/?mirrorstats et bien d'autres contributions !).
Les retours sont non-seulement pris en compte mais aussi bienvenus : plus qu'écouter, on vient aussi t'aider à aller au bout du processus de contribution pour que ce soit plus facile la prochaine fois.
Tout aussi important que l'état actuel du projet, c'est aussi l'avenir de celui-ci. L'évolution du nombre de contributeurs (chez Vates avec un doublement de l'équipe en peu de temps, ou même en dehors avec les contributions externes), le fait d'avoir réussi à rentrer finalement assez vite dans l'écosystème de la virtu et globalement le côté ouvert, au sens large : pas que le code, mais aussi ce qu'il y a autour: comment est fait le build et les moindres composants à l'intérieur : https://xcp-ng.org/docs/develprocess.html ainsi que l'architecture générale : https://xcp-ng.org/docs/architecture.html.
Tout ça fait que j'ai bien envie de continuer à utiliser la plateforme et de la regarder évoluer, tout en apportant ma pierre à l'édifice !
Une illustration assez représentative : le support des derniers NUC Intel sur XCP-ng. Ce n'est pas vraiment la cible de Vates (XCP-ng/XO vise surtout les infrastructures d'entreprises), et pourtant des efforts sont fait pour aider les gens à contribuer pour résoudre des bugs, parfois complexes. Comme les utilisateurs sont poussés positivement par Vates à aller au bout de leurs démarches, on voit concrètement des résultats assez fou. Par exemple, ici, où plusieurs contributeurs externes vont chercher en profondeur le soucis, puis le release manager va les aider à contribuer au bon endroit et de la bonne façon : c'est un gros travail à fournir mais qui en vaut clairement la peine ! Ici le lien vers le post qui explique le travail à accomplir une fois les fix identifiés : https://xcp-ng.org/forum/post/48686
Conclusion:
Il n'y a pas de bon ou mauvais hyperviseur. Je cherchais depuis un moment un projet où je pouvais m'investir à fond, et où je pouvais apporter une pierre à l'édifice aussi bien pour mon usage personnel que pour la communauté, et je pense l'avoir trouvé avec XCP-ng et Xen Orchestra !
Mais ceci est mon ressenti personnel, et en fonction de vos besoins, de vos préférences, l'un ou l'autre conviendra le mieux à vos usages.
Proxmox et XCP-ng ont deux philosophies différentes, l'utilisation n'est pas exactement identique, mais je ne peux que vous inviter à tester XCP-ng, et à vous faire votre propre avis :)