Pendant longtemps, administrer plusieurs environnements Proxmox VE signifiait ouvrir autant d'interfaces que de clusters.
Cette organisation reste acceptable avec un cluster principal et une seule équipe d'exploitation. Elle devient beaucoup moins confortable lorsque l'infrastructure s'étend sur plusieurs sites, plusieurs clusters indépendants et plusieurs serveurs Proxmox Backup Server.
L'administrateur doit alors répondre à des questions simples en apparence : où se trouve cette VM ? Quel cluster manque de capacité ? Quels nœuds ont des mises à jour en attente ? Où sont stockées les sauvegardes ? Peut-on déplacer une charge vers un autre site ?
Proxmox Datacenter Manager, souvent abrégé PDM, apporte cette couche de gestion globale. Depuis décembre 2025, le produit dispose d'une première version stable. La version 1.1, publiée en mai 2026, ajoute notamment l'installation automatisée, la gestion centralisée des souscriptions et une visibilité plus détaillée sur Ceph.
Qu'est-ce que Proxmox Datacenter Manager ?
Proxmox Datacenter Manager est un plan de contrôle centralisé pour les infrastructures Proxmox. Il peut connecter plusieurs environnements indépendants, appelés remotes :
- clusters Proxmox VE ;
- nœuds Proxmox VE autonomes ;
- serveurs Proxmox Backup Server ;
- infrastructures réparties entre plusieurs sites ou régions.
PDM agrège leur inventaire, leurs métriques et leurs tâches dans une interface commune. Il présente les nœuds, VM, conteneurs, stockages et datastores de sauvegarde sans obliger l'opérateur à parcourir chaque interface séparément.
Il permet aussi d'exécuter certaines opérations : démarrage et arrêt des invités, gestion des snapshots, suivi des tâches, contrôle des mises à jour, accès à un shell distant sur les versions compatibles, migration entre clusters, supervision Ceph et gestion de certains éléments SDN/EVPN.
Pour les configurations les plus détaillées, PDM conserve un lien direct vers l'interface native de Proxmox VE ou PBS. C'est un plan de contrôle global, pas une reconstruction complète de chaque produit.
Ce que PDM change à l'échelle d'une infrastructure
Proxmox VE sait administrer un cluster. Deux clusters Proxmox VE restent cependant deux domaines d'administration indépendants.
PDM ajoute une couche au-dessus de ces domaines sans les fusionner. Chaque cluster conserve :
- son quorum ;
- sa haute disponibilité ;
- son stockage ;
- son réseau ;
- ses décisions locales ;
- son fonctionnement autonome.
Cette architecture évite qu'une indisponibilité de PDM arrête les VM. Les remotes continuent de fonctionner indépendamment, même si leur plan de gestion central est temporairement inaccessible.
Un inventaire consolidé
L'écran Guests regroupe les VM QEMU et les conteneurs LXC de tous les environnements enregistrés. Les ressources peuvent être recherchées et filtrées selon leur nom, identifiant, état, type, remote, nœud, tag ou consommation.
Une recherche comme :
tag:prod status:running
retrouve les workloads de production démarrés, quel que soit leur cluster. Une autre requête peut isoler les VM d'un site :
remote:paris type:qemu
Cette fonction résout une difficulté réelle des infrastructures distribuées : disposer d'un inventaire exploitable sans maintenir un tableur parallèle.
PDM centralise également les tâches et les métriques collectées sur les remotes. Les équipes peuvent repérer plus rapidement un environnement inaccessible, une tâche échouée, une consommation anormale, un stockage proche de la saturation ou des correctifs en attente.
Des vues adaptées aux équipes
Les vues personnalisées permettent de construire des tableaux de bord avec leurs propres widgets et filtres : production, PRA, agences, sauvegardes, Kubernetes ou mises à jour critiques.
Les filtres peuvent s'appuyer sur les remotes, les ressources, leurs types et leurs tags. Une équipe support n'a donc pas besoin de recevoir la même visibilité qu'un administrateur infrastructure ou un responsable de production.
L'accès à une vue peut être accordé sans donner automatiquement accès à l'administration complète de toutes les ressources qu'elle représente.
Proxmox VE et Proxmox Backup Server dans la même vue
Depuis la version 1.0, PDM intègre les serveurs Proxmox Backup Server comme remotes. L'interface consolide leurs datastores, leur capacité, leur consommation, leurs métriques et certaines tâches.
Cette visibilité améliore la compréhension de la chaîne complète entre le workload, le cluster qui l'exécute et le datastore qui protège ses données.
PDM ne remplace pas encore toutes les fonctions de PBS. Les configurations avancées des jobs, namespaces, synchronisations ou règles de rétention peuvent toujours nécessiter l'interface native.
La migration entre clusters
La migration inter-clusters est l'une des fonctions les plus stratégiques de PDM. La source et la destination peuvent appartenir à deux remotes indépendants.
Cela permet notamment de :
- déplacer une VM vers un nouveau cluster ;
- vider progressivement une ancienne plateforme ;
- transférer une charge vers un site disposant de plus de capacité ;
- préparer une maintenance ;
- accompagner un renouvellement matériel sans fusionner les clusters ;
- organiser un transfert vers un environnement de PRA.
Mais migration inter-clusters ne signifie pas migration automatique sans préparation. PDM doit établir des correspondances entre le stockage source et le stockage cible, les bridges réseau, les identifiants et les capacités disponibles.
La CLI expose notamment les paramètres --map-storage, --map-bridge, --migration-network et la possibilité de transférer des disques locaux. Le trafic est chiffré par défaut ; sa désactivation ne devrait être envisagée que sur un réseau privé considéré comme sûr.
Compatibilité CPU
Une VM migrée en ligne doit pouvoir poursuivre son exécution sur le processeur cible. Les modèles CPU exposés à la VM doivent être compatibles. Une migration entre générations ou constructeurs différents peut imposer un modèle plus générique, voire une migration à froid.
Mapping réseau
Un bridge vmbr100 sur la source n'existe pas nécessairement sur la destination. Associer deux noms ne garantit pas que VLAN, MTU, passerelles, filtrage et routage soient cohérents.
Mapping des stockages
Un stockage ceph-prod peut devoir être associé à un autre pool Ceph ou à un backend différent. Il faut contrôler l'espace, les formats, les performances, la réplication, les sauvegardes et la capacité du réseau de migration.
Dépendances externes
Une VM peut dépendre d'une IP, d'un pare-feu, d'un DNS, d'un VLAN, d'une licence ou d'un stockage externe propre au site d'origine. PDM transfère la charge ; il ne devine pas toutes ses dépendances métier.
SDN et EVPN entre plusieurs clusters
PDM propose une intégration avec la SDN Proxmox et les overlays EVPN. L'interface agrège l'état des zones SDN et peut gérer des zones ou VNets répartis entre plusieurs remotes.
L'objectif est de conserver une cohérence réseau lorsque des workloads doivent se déplacer entre clusters. L'intégration suppose cependant que les contrôleurs partageant un même ASN appartiennent réellement au même overlay interconnecté.
Cette fonction doit rester un projet réseau à part entière. Elle nécessite de maîtriser BGP, EVPN, VXLAN, ASN, VNI, Route Targets, routage underlay, MTU et redondance. PDM simplifie la gestion ; il ne retire pas la complexité intrinsèque d'un fabric multi-site.
Ceph : superviser sans fusionner
La version 1.1 renforce la visibilité centralisée sur Ceph : moniteurs, managers, OSD, pools, CephFS, alertes et état global.
PDM ne transforme pas plusieurs clusters Ceph en un stockage distribué unique. Chaque environnement reste indépendant. Le bénéfice se situe dans l'exploitation, la détection d'incidents et la planification de capacité.
Gestion centralisée des mises à jour
Dans une infrastructure répartie, le plus difficile n'est pas toujours d'exécuter une mise à jour, mais de savoir où elle manque.
PDM consolide l'état des dépôts, les paquets en attente et les mises à jour disponibles. Avec des versions compatibles de PVE et PBS, l'accès shell distant permet aussi de déclencher des opérations depuis le plan central.
Cette centralisation ne remplace pas une procédure de maintenance : vérifier l'état du cluster, les sauvegardes et les notes de version, traiter un nœud à la fois, puis contrôler quorum, Ceph et workloads avant de poursuivre.
Installation automatisée et souscriptions
PDM 1.1 peut gérer des fichiers de réponses utilisés pour installer automatiquement de nouveaux systèmes Proxmox. Les paramètres sont préparés au centre puis récupérés par un média compatible grâce à un mécanisme de jeton.
Cette fonction standardise le réseau, le stockage, le nommage, les comptes et les paramètres d'installation.
PDM peut aussi conserver un registre de clés de souscription et les affecter aux remotes. À grande échelle, cela évite de gérer la couverture nœud par nœud.
Authentification, rôles et sécurité
Centraliser l'administration augmente l'impact potentiel d'un compte compromis. PDM prend en charge PAM, les comptes locaux PDM, LDAP, Active Directory et OpenID Connect.
Plusieurs seconds facteurs sont disponibles : TOTP, WebAuthn et clés de récupération. Les intégrations API peuvent employer des tokens révocables plutôt que les mots de passe utilisateurs.
Le modèle d'autorisation combine utilisateurs ou groupes, rôles, chemins de ressources et propagation des droits. Un opérateur peut recevoir un accès à un remote, une catégorie de ressources ou une VM précise.
Les droits PDM ne remplacent pas ceux du système distant. L'identité utilisée vers le remote doit également disposer des permissions nécessaires sur Proxmox VE ou PBS.
Mesures minimales recommandées
- utiliser un nom DNS dédié et un certificat TLS reconnu ;
- intégrer PDM à l'Active Directory ou à OpenID Connect ;
- activer la MFA ;
- éviter les comptes partagés et l'usage quotidien de
root@pam; - limiter chaque token aux droits nécessaires ;
- séparer lecture, exploitation et administration ;
- restreindre le port 8443 au réseau d'administration ou à un VPN ;
- surveiller les connexions et les tâches ;
- sauvegarder la configuration de PDM ;
- conserver un accès direct aux interfaces PVE et PBS.
Installer Proxmox Datacenter Manager
PDM peut être installé depuis l'ISO officielle ou sur une installation Debian compatible. L'ISO reste la méthode recommandée.
Pour la production, Proxmox recommande au moins deux cœurs CPU modernes, 4 Gio de RAM, 40 Go de stockage, un stockage système redondé et des interfaces réseau redondantes.
L'interface est accessible en HTTPS sur le port 8443 :
https://pdm.example.com:8443
PDM peut techniquement fonctionner dans une VM. Il faut cependant éviter une dépendance circulaire mal maîtrisée. Si cette VM réside sur un cluster qu'elle supervise, une panne complète de ce cluster fera perdre l'interface centrale, même si les autres remotes continuent de fonctionner.
PDM remplace-t-il VMware vCenter ?
Pas complètement, et une comparaison directe peut être trompeuse.
vCenter est le centre de contrôle d'environnements vSphere fortement intégrés. PDM supervise plusieurs domaines Proxmox qui restent autonomes.
| Fonction | Proxmox Datacenter Manager | VMware vCenter |
|---|---|---|
| Inventaire central | Oui | Oui |
| Plusieurs clusters | Oui | Oui |
| Opérations sur les VM | Oui | Oui |
| Migrations inter-clusters | Oui, avec préparation | Selon architecture et licences |
| Gestion de PBS | Oui | Non |
| Visibilité Ceph native | Oui | Non |
| SDN multi-cluster | EVPN en évolution | NSX selon architecture |
| Configuration complète depuis le plan central | Encore partielle | Plus mature |
| Code open source | Oui, AGPLv3 | Non |
PDM devient le point d'administration central qui manquait à de nombreuses infrastructures Proxmox. Le présenter comme un remplacement fonctionnel exact de vCenter serait toutefois prématuré.
Les limites actuelles
La feuille de route mentionne encore plusieurs axes d'évolution :
- dossiers hiérarchiques pour organiser les remotes ;
- délégation plus fine et rôles plus détaillés ;
- opérations en masse sur plusieurs VM ;
- vue globale des jobs de sauvegarde ;
- configuration plus complète des invités ;
- amélioration de la gestion des ressources entre clusters.
Les rôles PDM restent actuellement prédéfinis : il n'est pas encore possible de créer librement ses propres rôles personnalisés.
Architecture de déploiement recommandée
Les principes essentiels sont : flux d'administration séparés, DNS et NTP fiables, certificat TLS valide, MFA, comptes techniques dédiés, permissions minimales, supervision externe, sauvegarde de la configuration et accès direct documenté aux clusters.
Faut-il déployer PDM maintenant ?
PDM apporte une valeur immédiate lorsque l'organisation exploite plusieurs clusters, plusieurs sites, plusieurs serveurs PBS, une équipe d'exploitation partagée, des migrations régulières ou une politique globale de mises à jour.
Pour un seul petit cluster, l'interface Proxmox VE couvre déjà l'administration locale et PDM ajoute un composant supplémentaire à maintenir.
La question utile est donc : le coût de la dispersion des interfaces, inventaires et procédures justifie-t-il un plan de contrôle central ? Dès que la réponse devient oui, PDM mérite un pilote.
Conduire un pilote en sept étapes
- Installer PDM sur une plateforme dédiée.
- Configurer DNS, TLS, NTP, MFA et sauvegarde.
- Connecter un cluster de test avec un compte limité.
- Vérifier l'inventaire, les métriques et les tâches.
- Intégrer un serveur PBS.
- Tester une migration inter-clusters avec une VM non critique.
- Documenter le fonctionnement dégradé sans PDM.
Les critères doivent couvrir la qualité de l'inventaire, la délégation des droits, la traçabilité, le mapping réseau, la migration avec stockage local, le retour arrière et la restauration de PDM.
Point de vue
Proxmox Datacenter Manager représente une étape structurante dans la maturité de l'écosystème Proxmox.
Sa force n'est pas de transformer tous les clusters en une infrastructure monolithique. Elle est de préserver leur autonomie tout en apportant un inventaire global, une supervision commune, des opérations centralisées, des migrations inter-clusters et une visibilité sur PBS et Ceph.
Il ne faut ni le réduire à un tableau de bord, ni le présenter trop vite comme un équivalent parfait de vCenter.
PDM montre surtout que l'écosystème Proxmox ne se limite plus à la gestion d'un cluster isolé. Il se prépare à administrer des infrastructures distribuées, multi-sites et organisées à l'échelle d'une entreprise.
Pour les organisations qui envisagent une sortie de VMware, cette évolution est probablement aussi importante que les fonctions de l'hyperviseur lui-même.