Proxmox VE et XCP-ng réunis dans une console tierce
PegaProx est une console web auto-hébergée qui réunit plusieurs clusters Proxmox VE, et des pools XCP-ng, dans une même interface. Écrit en Python (Flask), PegaProx s'installe sur une machine à part et parle à chaque cluster par l'API de Proxmox, plus SSH pour une partie des fonctions. Son site le présente comme une couche posée par-dessus Proxmox VE, « sans le remplacer », qui ajoute la migration entre clusters, la répartition de charge et des rapports de coût et de conformité.
Proxmox Datacenter Manager est la console que publie l'éditeur de Proxmox. ProxCenter est, comme PegaProx, une console tierce.
Le comparatif des consoles multi-cluster pour Proxmox confronte PegaProx à la console de l'éditeur et aux autres consoles tierces.
Accès cloisonné par client et migration depuis ESXi
- XCP-ng à côté de Proxmox : sur un pool XCP-ng 8.2 ou plus récent, joint par XAPI, PegaProx 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.
- Migration d'un hyperviseur à l'autre : d'ESXi vers Proxmox VE ou XCP-ng, et entre Proxmox VE et XCP-ng dans les deux sens, avec conversion des disques. Les snapshots ne suivent pas.
- Opérations sur tout le parc : répartition de charge entre nœuds et entre clusters, mises à jour des nœuds un par un après évacuation, politiques de snapshots avec rétention, et depuis la 1.3.0 des actions groupées sur les invités.
- Accès cloisonné par client : rôles personnalisés, ACL par VM, clusters isolés par client, connexion LDAP ou OIDC, clés FIDO2. Le plugin Client Portal ouvre aux clients d'un hébergeur la console et les snapshots de leurs propres VM.
- Coût et conformité : coût mensuel par VM tiré des métriques réelles, et un tableau en lecture seule rapproché de BSI Grundschutz, ISO 27001, NIS2 et SOC 2, exportable en PDF.
- Une console qui a son secours : depuis la 1.3.0, jusqu'à quatre instances PegaProx forment un groupe autour d'un leader, et un admin promeut à la main une instance de secours quand le leader tombe.
La documentation recommande root, la licence impose l'attribution
Le compte root est la connexion recommandée. La documentation conseille « fortement » root@pam et le mot de passe root de chaque cluster, que la base de PegaProx 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.
XCP-ng est en aperçu technique. Le README range l'intégration sous « Tech Preview », et la documentation prévient que certaines fonctions peuvent être limitées ou changer.
La migration entre clusters repose sur une fonction expérimentale de Proxmox. PegaProx appelle l'API remote_migrate de Proxmox VE (pegaprox/core/manager.py), celle de qm remote-migrate, que la documentation de Proxmox VE marque toujours « EXPERIMENTAL feature! ». Proxmox Datacenter Manager passe par la même API.
Une clause d'attribution s'ajoute à l'AGPL. Le fichier NOTICE invoque l'article 7(b) de l'AGPL-3.0 : la mention « Powered by PegaProx » du portail client et la ligne de copyright de l'interface doivent rester visibles sur toute instance ouverte à des utilisateurs. Le portail ne se livre donc pas en marque blanche. Toutes les fonctions sont gratuites ; le support commercial passe par des sociétés indépendantes, sponsors du projet.
Python et SQLite, sans serveur de base de données. PegaProx tourne sous Python 3.10 à 3.13 sur Linux, ou en image Docker, et garde sa configuration dans un fichier SQLite, chiffré en entier par SQLCipher sur Linux x86_64 seulement. La documentation recommande 4 cœurs, 8 Go de RAM et 20 Go de disque en production ; jusqu'à cinq clusters, elle compte 1 cœur et 1 Go de RAM. Le script d'installation du README tire la branche principale, pas une version publiée ; pour la production, le README renvoie au dépôt APT d'un contributeur, gyptazy.
Le site annonce SAML, le README non. Le tableau comparatif de pegaprox.com coche SAML, mais le README ne cite que LDAP et OIDC, et aucune bibliothèque SAML ne figure dans requirements.txt.
57 versions depuis janvier 2026. Le dépôt date du 18 janvier 2026. La 1.0 du 1er août 2026 a mis fin à la bêta, et six versions l'ont suivie, dont trois mineures, jusqu'à la 1.3.0 du 7 octobre 2026. Deux développeurs signent 1 095 des 1 296 commits, et le README décrit une équipe de trois personnes financée par le sponsoring. La 1.3.0 annonce 38 changements de comportement et corrige une perte de données silencieuse de la migration ESXi « Live Clone ». Ses notes laissent ouvert un problème connu : la migration ESXi « Snapshot-Iterative » peut annoncer un succès alors que des données manquent sur la cible.