Arrêtons de tourner autour du pot. Quand on gère 50 nœuds Proxmox répartis sur plusieurs sites, ouvrir 12 onglets de consoles PVE pour avoir une vue d'ensemble, c'est du bricolage. Proxmox Datacenter Manager (PDM) 1.0, sorti en version stable, propose enfin une réponse officielle à ce problème que la communauté traîne depuis des années.
La réalité du terrain : avant PDM, les options pour centraliser la gestion multi-nœuds se résumaient à des scripts maison, des outils tiers plus ou moins maintenus, ou un cluster Proxmox monolithique avec ses contraintes de quorum. Aucune de ces solutions n'était satisfaisante pour un MSP en production.
Plan
- Ce qu'est PDM (et ce que ce n'est pas)
- Architecture technique : du Rust partout
- Fonctionnalités clés en production
- Migration inter-clusters : le game changer
- Intégration Proxmox Backup Server
- Les limites à connaître
- Cas d'usage MSP : 50 nœuds, 2 datacenters
- Verdict terrain
Ce qu'est PDM (et ce que ce n'est pas)
PDM est un outil de supervision et de gestion centralisée pour environnements Proxmox. Il connecte des clusters PVE indépendants et des instances Proxmox Backup Server dans une interface unique.
En clair : PDM ne remplace pas le clustering Proxmox. Il se place au-dessus. Chaque cluster reste autonome, avec son propre quorum, son propre stockage, sa propre HA. PDM agrège la vue et les opérations, sans créer de dépendance entre les nœuds.
Ce n'est pas non plus un concurrent de vCenter. Le périmètre est volontairement plus restreint : gestion des VMs et conteneurs, opérations de puissance, migration, supervision. Pas de gestion de stockage distribué, pas d'orchestration réseau avancée. Proxmox reste Proxmox, PDM est la vitre qui permet de tout voir d'un coup.
Architecture technique : du Rust partout
Le choix technique le plus notable de PDM : l'intégralité du stack est en Rust.
Backend :
- Deux démons API : un principal non-privilégié, un démon privilégié root
- API REST JSON standard
- Architecture découplée : si PDM tombe, les clusters continuent de tourner normalement
Frontend :
- Framework Yew (Rust compilé en WebAssembly)
- Proxmox Yew Widget Toolkit (développé en interne)
- Interface réactive, pas de framework JavaScript
Le choix du Rust n'est pas anodin. Sur un outil qui doit gérer des milliers de connexions simultanées vers des nœuds distants, la gestion mémoire et la performance sont critiques. L'équipe Proxmox a testé avec succès plus de 5 000 clusters distants et 10 000 VMs dans l'interface.
La réalité du terrain : le frontend Yew/WASM est rapide, mais l'écosystème est moins mature que ce qu'on trouve côté JavaScript. Les extensions communautaires et le debugging sont plus limités. Pour un outil d'infrastructure, c'est un trade-off acceptable.
Fonctionnalités clés en production
Vue centralisée
L'essentiel : tous les clusters, nœuds, VMs, conteneurs et datastores dans une seule interface. Filtrage, recherche, tri. Quand on gère des dizaines de nœuds, pouvoir chercher une VM par nom sans savoir sur quel cluster elle tourne, c'est un gain de temps considérable.
Opérations de puissance
Start, stop, reboot, shutdown sur les VMs et conteneurs, directement depuis PDM. Pas besoin de se connecter au cluster cible. Pour les opérations de maintenance planifiée, c'est un changement radical par rapport au workflow "ouvrir la console PVE du bon nœud".
Supervision des mises à jour
PDM remonte l'état des mises à jour disponibles sur l'ensemble du parc. Pour un MSP qui doit maintenir des dizaines de nœuds patchés, cette vue consolidée élimine les oublis.
Accès console distant
Shell unifié vers tous les nœuds gérés, directement depuis l'interface PDM. Plus besoin de SSH vers chaque nœud individuellement.
Migration inter-clusters : le game changer
C'est la fonctionnalité qui change la donne. PDM permet la migration live de VMs entre clusters indépendants. Pas entre nœuds d'un même cluster (ça, PVE le fait déjà), mais entre clusters distincts.
En clair : vous pouvez déplacer une VM d'un cluster à Toulouse vers un cluster à Bordeaux, à chaud, sans downtime.
Cas d'usage concrets :
- Maintenance datacenter : évacuer les charges d'un site avant intervention physique
- Load balancing géographique : rééquilibrer les ressources entre sites
- Disaster recovery : basculer les charges vers un site de secours
Pour un MSP comme SHPV qui opère sur plusieurs datacenters, cette capacité de migration inter-sites transforme les opérations de maintenance. Avant PDM, migrer une VM entre clusters nécessitait un export/import manuel ou des scripts maison fragiles.
Cela dit, la migration inter-clusters a ses contraintes. Le réseau entre sites doit supporter le débit de transfert mémoire. Sur des VMs avec beaucoup de RAM, prévoir de la bande passante. Et le stockage cible doit être compatible.
Intégration Proxmox Backup Server
PDM intègre nativement les instances Proxmox Backup Server dans sa vue centralisée. Les datastores PBS apparaissent directement dans l'interface, avec l'état des sauvegardes et l'utilisation disque.
Pour un MSP, coupler PDM avec PBS signifie une vue unifiée compute + backup. Savoir en un coup d'œil que le nœud X a ses VMs mais que les sauvegardes PBS du site Y sont en retard, c'est exactement le type de visibilité qui manquait.
Les limites à connaître
Soyons francs. PDM 1.0 est une v1, et ça se sent sur certains aspects :
Ce qui manque :
- PDM a son propre RBAC, mais la gestion des ACL des clusters PVE distants reste locale à chaque cluster
- Pas d'API de provisioning automatisé (création de VMs via PDM)
- Pas d'intégration native avec des outils de monitoring tiers (Zabbix, Prometheus)
- Le reporting est basique : pas de tableaux de bord personnalisables
Ce qui pourrait poser problème :
- La documentation est encore jeune (normal pour une v1)
- L'écosystème de plugins est inexistant
- Le frontend WASM peut dérouter les admins habitués aux outils classiques
Ce qui fonctionne bien :
- La stabilité du backend Rust
- La performance de l'interface même avec beaucoup de nœuds
- La migration inter-clusters (le vrai argument de vente)
La roadmap Proxmox prévoit des améliorations sur le provisioning, les permissions et le monitoring. Mais aujourd'hui, PDM reste un outil de supervision et d'opérations, pas une plateforme d'orchestration complète.
Cas d'usage MSP : 50 nœuds, 2 datacenters
Pour contextualiser, voici comment PDM s'insère dans une infrastructure MSP type :
Configuration :
- 2 datacenters (ex. Toulouse et Bordeaux)
- 6 clusters PVE (3 par site)
- 50 nœuds au total
- 2 instances PBS (une par site)
- Environ 800 VMs et conteneurs
Avant PDM :
- 6 interfaces PVE à surveiller
- 2 interfaces PBS
- Scripts de monitoring maison pour la vue consolidée
- Migration inter-sites manuelle (export OVF, copie, import)
Avec PDM :
- 1 interface pour tout voir
- Opérations de puissance centralisées
- Migration live inter-clusters en quelques clics
- Vue consolidée des sauvegardes PBS
Le gain est surtout opérationnel. Moins de temps passé à naviguer entre interfaces, moins de risques d'oubli sur un nœud, des migrations simplifiées.
Pour la haute disponibilité au niveau applicatif, PDM ne remplace pas les solutions comme Pacemaker/Corosync ou Keepalived. Ces outils gèrent le failover applicatif (IPs virtuelles, services critiques). PDM gère l'infrastructure de virtualisation. Les deux sont complémentaires.
Comparaison avec l'existant
Depuis le départ massif de VMware vers Proxmox post-acquisition Broadcom, la question de la gestion centralisée est devenue critique. vCenter couvrait ce besoin chez VMware. PDM est la réponse de Proxmox, avec une philosophie différente : open-source, léger, sans vendor lock-in.
Pour les infrastructures qui exploitent des fonctionnalités avancées comme le GPU passthrough ou le SDN avec VXLAN, PDM offre la visibilité centralisée sans interférer avec ces configurations spécifiques au niveau cluster.
Verdict terrain
PDM 1.0 n'est pas parfait, mais il comble un vrai manque dans l'écosystème Proxmox. Pour un MSP qui gère plusieurs clusters, c'est un outil qui passe de "nice to have" à "indispensable" dès qu'on dépasse 3 clusters.
La migration inter-clusters est le killer feature. Le reste (vue centralisée, opérations de puissance, supervision des updates) est du confort bienvenu, mais la migration, c'est ce qui justifie le déploiement.
En clair : si vous gérez un seul cluster Proxmox de 3 nœuds, PDM n'apporte pas grand-chose. Si vous gérez 5 clusters sur 2 sites, installez-le maintenant.
La v1 pose les fondations. Les prochaines versions, avec le provisioning et les permissions centralisées, devraient en faire un outil complet. En attendant, c'est déjà le meilleur outil disponible pour piloter du multi-cluster Proxmox en production.
