Gérer plusieurs clusters Proxmox : quelle console choisir

Trois consoles libres permettent de gérer plusieurs clusters Proxmox depuis une seule interface, et la première différence tient à leur éditeur. Proxmox Datacenter Manager vient de l'éditeur de Proxmox VE : gratuit, il migre une VM à chaud d'un cluster à l'autre, mais ne connaît que Proxmox VE et Proxmox Backup Server. PegaProx et ProxCenter sont des consoles tierces nées en 2026, qui se comparent elles-mêmes à vCenter. PegaProx pilote aussi des pools XCP-ng, en aperçu technique, et sa documentation conseille de lui confier le compte root de chaque cluster ; ProxCenter réserve la migration, la répartition de charge et le SSO à son édition Enterprise, facturée par nœud.

La console de l'éditeur ou une console tierce

Proxmox Datacenter Manager (PDM) se définit comme un plan de contrôle de haut niveau. Il agrège les métriques et les tâches des installations qu'on lui déclare, ses « remotes », pilote les opérations courantes et renvoie vers l'interface native de chaque cluster pour la configuration fine. Sa feuille de route range encore la configuration des invités, au-delà des snapshots, du cycle de vie et de la migration, parmi les fonctions à venir. Sa documentation insiste sur ce couplage lâche : si la console tombe, les remotes continuent de tourner.

ProxCenter se présente comme une alternative à VMware vCenter pour Proxmox et en reprend les repères : un inventaire en arbre à la manière de vSphere (clusters, nœuds, VM, stockages, pools, tags) et une répartition de charge baptisée DRS. PegaProx met lui aussi ses fonctions en regard de vCenter et de l'interface native de Proxmox sur son site, mais se décrit comme une couche posée par-dessus Proxmox VE, « sans le remplacer ». Il modifie la configuration des VM depuis sa propre interface (processeur, mémoire, disques, réseau, EFI, Secure Boot), et son portail en libre-service est conçu pour les clients d'un hébergeur.

Proxmox VE, PBS et XCP-ng : ce que chaque console connecte

PDM accepte Proxmox VE à partir de la 8.4 et Proxmox Backup Server (PBS) à partir de la 3.4, selon l'annonce de sa version 1.0. Sa feuille de route ne prévoit qu'un nouveau type de remote, Proxmox Mail Gateway, et ne cite aucun autre hyperviseur. ProxCenter se connecte à Proxmox VE et à PBS ; VMware ESXi et vCenter, Hyper-V, Nutanix AHV et XCP-ng n'y figurent que comme sources de migration, dans l'édition Enterprise.

PegaProx est donc le seul des trois à piloter un autre hyperviseur que Proxmox. Sur un pool XCP-ng 8.2 ou plus récent, joint par XAPI, il démarre et arrête les VM, ouvre leur console, gère disques et interfaces réseau, et met un hôte en maintenance après avoir évacué ses VM. Son README range cette intégration en « Tech Preview », et sa documentation prévient que certaines fonctions peuvent être limitées ou changer.

Migrer une VM d'un cluster à l'autre

La migration entre clusters repose, dans les trois consoles, sur l'API remote-migrate de Proxmox VE : le code de PDM (server/src/api/pve/qemu.rs) et celui de PegaProx (pegaprox/core/manager.py) l'appellent, et la documentation de ProxCenter la nomme. La documentation de Proxmox VE marque toujours qm remote-migrate comme « EXPERIMENTAL feature! ».

PDM migre à chaud, et l'annonce de sa 1.0 précise que les deux clusters n'ont besoin d'aucun réseau de cluster commun. PegaProx migre aussi à chaud par défaut, mais son code passe d'office en migration hors ligne au-delà de 100 Go de disques, sauf forçage : un commentaire y explique que le ticket WebSocket de Proxmox expire avant la fin de la synchronisation de la mémoire (pegaprox/api/vms.py). ProxCenter ne déplace une VM d'un cluster à l'autre que hors ligne, en édition Enterprise. Proxmox refuse alors un invité géré par la HA, répliqué ou porteur de snapshots : la fenêtre de migration fait lever ces trois obstacles, et ProxCenter rétablit HA et réplication sur la source si la migration échoue.

Pour quitter un autre hyperviseur, PegaProx migre d'ESXi vers Proxmox VE ou XCP-ng, et de Proxmox VE vers XCP-ng dans les deux sens, sans les snapshots. Les notes de sa 1.3.0 laissent un problème ouvert : la migration ESXi « Snapshot-Iterative » peut annoncer un succès alors que des données manquent sur la cible. ProxCenter Enterprise importe vers Proxmox VE depuis ESXi, vCenter, Hyper-V, Nutanix AHV et XCP-ng, en mode warm (CBT) depuis ESXi, vCenter et XCP-ng, avec Proxmox VE 9 sur le nœud cible. La documentation de PDM ne prévoit aucun import depuis un autre hyperviseur.

Pour répartir la charge, PegaProx déplace des VM entre les nœuds d'un cluster et entre clusters, le DRS de ProxCenter équilibre les nœuds d'un même cluster en édition Enterprise, et ni la documentation ni la feuille de route de PDM ne prévoient d'équilibrage automatique.

Ce que les consoles montrent des sauvegardes

Proxmox Backup Server se gère dans PDM comme un remote depuis la 1.0 : contenu et occupation des datastores, métriques au tableau de bord. Le suivi des tâches de sauvegarde, avec le statut de la dernière exécution, figure encore sur sa feuille de route. L'édition Community de ProxCenter gère plusieurs serveurs PBS et affiche leurs sauvegardes ; les rapports relèvent de l'Enterprise. PegaProx planifie lui-même des sauvegardes, suit par cluster et par datastore l'âge de la dernière sauvegarde face au RPO fixé, et peut vérifier une sauvegarde en la restaurant puis en démarrant la VM, une fonction marquée expérimentale.

Les accès que chaque console demande aux clusters

La documentation de PegaProx recommande « fortement » root@pam et le mot de passe root de chaque cluster, que sa base conserve chiffré. Avec un jeton d'API ou un utilisateur limité, quatre fonctions ne marchent pas : mises à jour en série, configuration SMBIOS automatique, HA à deux nœuds et shell des nœuds. La documentation de ProxCenter prend le contre-pied : un jeton d'API de préférence, et en production un compte de service dédié plutôt que root@pam. SSH ne lui sert qu'à l'import de disques, aux mises à jour en série, au scan de CVE et à la collecte des flux réseau. PDM se connecte par un jeton d'API, existant ou créé à l'ajout du remote à partir d'un identifiant (ui/src/remotes/wizard_page_info.rs), et ouvre le shell des remotes par jeton à partir de Proxmox VE 9.1 et PBS 4.1.

Ce que chaque console demande pour tourner

Relevé dans les dépôts et les documentations le 7 octobre 2026.

PDM s'installe de préférence par son ISO, et l'annonce de la 1.0 réserve aux experts son installation à côté d'un autre produit Proxmox. PegaProx tient dans un processus Python et un fichier SQLite, chiffré par SQLCipher sur Linux x86_64 seulement ; sa documentation compte 1 cœur et 1 Go de RAM jusqu'à cinq clusters, 8 cœurs et 32 Go au-delà de 200. Son script d'installation tire la branche principale plutôt qu'une version publiée, et le README renvoie pour la production au dépôt APT d'un contributeur, gyptazy. ProxCenter passe par un installeur qui pose Docker, Compose et PostgreSQL sous /opt/proxcenter ; sans Docker, seule la Community se compile, avec Node.js 22.12 et PostgreSQL 16 au moins. Côté versions de Proxmox, son README demande la 8.x ou la 9.x quand sa page de connexion accepte Proxmox VE 7.0 et PBS 3.0.

Une panne de la console elle-même se gère différemment d'un projet à l'autre. Les clusters ne dépendent pas de PDM pour tourner, et sa feuille de route étudie une architecture active-standby en notant que deux instances côte à côte couvrent déjà ce cas, au prix d'une collecte de métriques en double. PegaProx regroupe depuis sa 1.3.0 jusqu'à quatre instances autour d'un leader, et un administrateur promeut une instance de secours à la main. ProxCenter réserve sa haute disponibilité à l'Enterprise : trois nœuds derrière une IP virtuelle Keepalived, avec un PostgreSQL répliqué par Patroni.

Où en sont les projets

Proxmox Datacenter Manager a mis près d'un an à sortir de l'alpha : 0.1 le 19 décembre 2024, 0.9 bêta le 11 septembre 2025, 1.0 le 4 décembre 2025, puis 1.1 le 28 mai 2026. Le journal Debian du dépôt s'arrête à la 1.1.7 du 15 juillet 2026, et les commits se poursuivent en octobre. Le code vit sur git.proxmox.com, dont le dépôt GitHub n'est qu'un miroir en lecture seule.

PegaProx et ProxCenter ont ouvert leur dépôt à dix-sept jours d'écart, le 18 janvier et le 4 février 2026, et publient bien plus souvent. PegaProx compte 57 versions depuis sa 0.6.0 du 25 janvier 2026. Sa 1.0 a mis fin à la bêta le 1er août 2026, et sa 1.3.0 du 7 octobre annonce 38 changements de comportement ; elle corrige une perte de données silencieuse de la migration ESXi « Live Clone » et des failles d'autorisation, dont certaines venaient des correctifs de la 1.2.0. Son README décrit une équipe de trois personnes, et deux développeurs signent 1 095 des 1 296 commits. ProxCenter a publié 25 versions, de la 1.0.0 du 1er mars 2026 à la 1.4.11 du 5 octobre, dont dix en avril. Le compte adminsyspro signe tous ses commits hors Dependabot, et la 1.4.0 du 12 mai 2026 a remplacé SQLite par PostgreSQL sans migration automatique des données.

Licences et offres payantes

Proxmox Datacenter Manager est sous AGPL-3.0 ou ultérieure, sans abonnement dédié. Le dépôt enterprise et le support sont compris dans un abonnement Basic ou supérieur sur les remotes, à condition qu'au moins 80 % des nœuds configurés en aient un. En dessous, il reste le dépôt pdm-no-subscription, que la documentation réserve aux tests et à l'usage hors production.

PegaProx est sous AGPL-3.0 seule, avec une clause ajoutée au titre de l'article 7(b) dans son fichier NOTICE : la mention « Powered by PegaProx » du portail client et la ligne de copyright de l'interface restent visibles sur toute instance ouverte à des utilisateurs, ce qui exclut la marque blanche. Toutes ses fonctions sont gratuites, et le support commercial passe par des sociétés indépendantes, sponsors du projet.

ProxCenter sépare deux éditions. La Community, sous AGPL-3.0 ou ultérieure, n'a pas de limite de nœuds et couvre l'inventaire, le stockage et Ceph, les sauvegardes, les événements et les utilisateurs. L'Enterprise, sous un EULA propriétaire de droit français, ajoute migration, DRS, mises à jour en série, reprise sur site, RBAC avec LDAP ou OIDC, rapports et multi-tenant, portés par un orchestrateur en Go au code fermé. Le README cite pourtant la migration et « RBAC & SSO » sans les marquer Enterprise. L'abonnement est annuel et compté par nœud géré, sans tarif publié. La licence connectée tient par un bail de 30 jours, renouvelé à chaque synchronisation quotidienne qui transmet la clé, la version et le nombre de nœuds ; un mode hors ligne existe depuis la 1.4.11. Au-delà du quota de nœuds, l'installation passe en lecture seule. L'EULA interdit enfin de fournir des services managés à des tiers sans accord écrit séparé, alors que le mode MSP vise les hébergeurs.