Proxmox Datacenter Manager : installer la console officielle pour piloter vos serveurs dédiés Proxmox VE et PBS

Proxmox Datacenter Manager : la console multi-clusters officielle de Proxmox

Proxmox Datacenter Manager (PDM) est la console centrale développée par Proxmox Server Solutions, l'éditeur de Proxmox VE, pour superviser et piloter depuis une seule interface web plusieurs nœuds Proxmox VE isolés, plusieurs clusters et plusieurs serveurs Proxmox Backup Server (PBS). Dans le vocabulaire de PDM, chacune de ces installations est un remote. Après une alpha en décembre 2024 et une bêta 0.9 en septembre 2025, la version 1.0 stable est sortie le 4 décembre 2025. La version actuelle, la 1.1 du 28 mai 2026, repose sur Debian 13.5 « Trixie », un noyau Linux 7.0 et ZFS 2.4. Le logiciel est écrit principalement en Rust, interface web comprise (une application monopage compilée en WebAssembly avec le framework Yew), et publié sous licence AGPLv3.

Le principe : PDM ne remplace pas l'interface de chaque nœud, il l'agrège. Il interroge l'API de chaque remote avec un token API, garde en cache l'inventaire des machines virtuelles, des conteneurs LXC, du stockage et des datastores, collecte les métriques (graphiques RRD), regroupe les tâches et les journaux, et renvoie vers l'interface native du remote pour la configuration fine. Aucun agent n'est installé sur les hyperviseurs. La documentation insiste sur ce choix d'architecture : la console centrale ne doit devenir ni un goulot d'étranglement ni un point de défaillance unique pour le fonctionnement des remotes.

Ce guide s'adresse à l'administrateur d'un ou plusieurs serveurs dédiés sous Proxmox VE. Il couvre le choix entre PDM et les consoles communautaires ProxCenter et PegaProx que nous avons déjà présentées, l'installation sur Debian 13 ou par ISO, les comptes de service à droits limités, le raccordement des remotes Proxmox VE et PBS, les vues et la délégation d'accès, la migration d'une VM d'un serveur dédié à l'autre, puis un cas concret : un parc qui fait tourner Pelican Panel pour des serveurs de jeu, Stalwart pour la messagerie et un PBS pour les sauvegardes.

Proxmox Datacenter Manager, ProxCenter ou PegaProx : que choisir ?

Les trois outils répondent au même besoin, voir et piloter tout son parc Proxmox dans une seule interface, mais ne se placent pas au même endroit. Les faits, d'après la documentation de chaque projet :

En pratique, PDM est le choix par défaut si vous voulez rester dans l'écosystème de l'éditeur : mêmes dépôts APT, même cycle de mises à jour que Proxmox VE et PBS, même modèle de droits, et aucun coût supplémentaire, puisqu'il n'existe pas d'abonnement propre à PDM. ProxCenter et PegaProx couvrent aujourd'hui des besoins que PDM ne traite pas encore (consoles graphiques, équilibrage de charge, migration depuis ESXi), chacun avec son propre modèle : open core pour ProxCenter, projet communautaire pour PegaProx. Rien n'empêche d'en faire tourner deux sur le même parc, chacun avec son propre compte de service. Nos guides installer ProxCenter et installer PegaProx détaillent les deux autres.

Prérequis : 2 cœurs, 4 Gio de RAM, 40 Go et des remotes en Proxmox VE 8.4 ou PBS 3.4

La documentation d'installation distingue une configuration minimale, réservée à l'évaluation, et une configuration recommandée pour la production :

Le reste de la liste :

• Architecture : uniquement des processeurs 64 bits AMD ou Intel, le projet n'a pas prévu de version 32 bits ;
• Versions des remotes : Proxmox VE 8.4 au minimum et Proxmox Backup Server 3.4 au minimum, d'après les annonces des versions 1.0 et 1.1. Le shell distant vers un nœud demande Proxmox VE 9.1 ou PBS 4.1. Un serveur encore en Proxmox VE 8 se raccorde s'il est en 8.4, mais notre guide migrer Proxmox VE 8 vers 9 décrit le passage à la version actuelle ;
• Réseau : PDM doit pouvoir joindre directement chaque remote, sur l'API de Proxmox VE (port 8006 par défaut) et celle de PBS (port 8007). L'inverse n'est pas nécessaire : les remotes n'ont pas à joindre PDM. Proxmox précise qu'un reverse proxy entre PDM et ses remotes Proxmox VE n'est pas pris en charge, et recommande un tunnel WireGuard ou OpenVPN pour les hôtes qui ne doivent pas être exposés ;
• Interface web : HTTPS sur le port 8443, avec un navigateur récent (Firefox, Chrome, Edge ou Safari).

Où installer Proxmox Datacenter Manager : VPS, VM sur un second serveur ou machine à part

Même règle que pour toute console de gestion : ne l'hébergez pas sur l'hyperviseur qu'elle supervise, sinon vous perdez la vue d'ensemble précisément quand ce nœud tombe. L'annonce de la version 1.1 classe d'ailleurs l'installation de PDM à côté de Proxmox VE ou de PBS, sur le même système, parmi les usages réservés aux experts. Trois emplacements tiennent la route :

• Un petit VPS Linux séparé, hébergé en France comme vos serveurs dédiés. L'offre Starter (2 vCPU, 4 Go de RAM DDR4, 50 Go SSD) correspond exactement à la configuration recommandée. Installez-y Debian 13 puis les paquets PDM ; un VPS encore en Debian 12 passe d'abord par notre guide migrer de Debian 12 vers Debian 13 ;
• Une VM sur un second serveur dédié, installée depuis l'ISO officielle, quand vous gérez au moins deux hyperviseurs : la console tourne sur l'un et garde la vue sur l'autre quand il tombe ;
• Une petite machine physique à part, pour un parc plus large, avec un stockage redondant comme le recommande la documentation.

Entre un VPS et des serveurs dédiés, faites passer les ports 8006 et 8007 par un tunnel WireGuard ou par Tailscale, qui s'appuie sur WireGuard, plutôt que d'ouvrir l'API Proxmox à tout Internet. Le coût en RAM de la console reste ainsi hors du budget de l'hyperviseur, comme expliqué dans dimensionner Proxmox VE sur un serveur dédié.

Installer Proxmox Datacenter Manager : ISO ou paquets sur Debian 13

Par l'ISO officielle (méthode recommandée)

L'ISO se télécharge depuis la page de téléchargements de Proxmox. Dans une VM Proxmox VE, montez-la comme lecteur CD-ROM ; sur une machine physique, copiez-la sur une clé USB d'au moins 2 Go. Sous Linux, après avoir identifié la clé avec lsblk :

dd bs=1M conv=fdatasync if=./proxmox-datacenter-manager_*.iso of=/dev/XYZ

L'installeur interactif demande notamment le disque cible et le mot de passe root, celui qui servira à la première connexion. Une installation automatisée par fichier de réponses existe aussi, utile si vous déployez plusieurs instances. N'utilisez pas UNetbootin pour préparer la clé : la documentation l'exclut.

Par les paquets, sur un Debian 13 existant

Sur un VPS ou une VM déjà en Debian 13 « Trixie », installez la clé de signature des dépôts Proxmox et vérifiez son empreinte SHA-256, qui doit valoir 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45 :

wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

Sans abonnement, déclarez le dépôt pdm-no-subscription au format deb822 dans /etc/apt/sources.list.d/proxmox.sources :

Types: deb
URIs: http://download.proxmox.com/debian/pdm
Suites: trixie
Components: pdm-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

Deux métapaquets existent. proxmox-datacenter-manager-container-meta garde le noyau Debian en place et n'installe que le strict nécessaire : c'est le bon choix sur un VPS ou dans un conteneur. proxmox-datacenter-manager-meta installe le noyau Proxmox par défaut avec la prise en charge de ZFS, pour une machine dédiée à PDM :

apt update
apt install proxmox-datacenter-manager-container-meta

Ouvrez ensuite https://adresse-du-serveur:8443. Le certificat auto-signé déclenche un avertissement du navigateur, que vous remplacerez plus loin par un certificat ACME. Connectez-vous en root avec le royaume Linux PAM et le mot de passe root du système (celui choisi à l'installation si vous êtes passé par l'ISO). Première action : créez un compte nominatif dans le royaume pdm (mot de passe de huit caractères au minimum), donnez-lui le rôle Administrator dans « Configuration → Access Control », activez sa double authentification, et réservez root@pam, le superutilisateur qui a tous les droits, au dépannage.

Créer des comptes de service sur Proxmox VE et PBS plutôt que root@pam

L'assistant d'ajout d'un remote propose deux modes. « Login and create Token » utilise l'identifiant et le mot de passe saisis uniquement pour se connecter au remote et y créer un token API ; d'après l'équipe Proxmox, ces identifiants ne sont pas conservés ensuite. « Use existing Token » enregistre le token que vous fournissez. Point important rappelé par Proxmox : un token créé automatiquement hérite des droits du compte qui s'est connecté. Avec root@pam, PDM détient donc un token root sur chaque serveur. Mieux vaut un compte de service dédié par remote, que vous pourrez désactiver sans toucher au compte root.

La documentation de PDM 1.1 ne publie pas de liste minimale de privilèges par fonction. Deux profils simples, à choisir selon l'usage :

Sur un nœud Proxmox VE, en root, créez le compte pdm@pve et donnez-lui le rôle du profil choisi :

pveum user add pdm@pve --comment "Proxmox Datacenter Manager"
pveum passwd pdm@pve
pveum aclmod / --users pdm@pve --roles Administrator

Dans l'assistant de PDM, utilisez ensuite pdm@pve et ce mot de passe en mode « Login and create Token » : le token créé hérite des droits de pdm@pve, rien de plus. Pour un parc en supervision seule, remplacez Administrator par PVEAuditor. Si vous préférez créer le token vous-même, désactivez la séparation de privilèges pour qu'il hérite des droits du compte, ou laissez-la active et posez une ACL sur le token, sinon il ne voit rien :

pveum user token add pdm@pve pdm --privsep 1 --comment "PDM"
pveum aclmod / --tokens 'pdm@pve!pdm' --roles Administrator

Côté Proxmox Backup Server, les tokens ont toujours leurs propres ACL et ne peuvent jamais dépasser les droits de leur compte. Le rôle Audit permet de consulter l'état et la configuration sans rien modifier, ce qui suffit pour la vue des datastores dans PDM :

proxmox-backup-manager user create pdm@pbs
proxmox-backup-manager acl update / Audit --auth-id pdm@pbs
proxmox-backup-manager user generate-token pdm@pbs pdm
proxmox-backup-manager acl update / Audit --auth-id 'pdm@pbs!pdm'

Le secret du token ne s'affiche qu'une fois : saisissez-le dans PDM en mode « Use existing Token ». Un compte par outil, jamais partagé avec Pulse, ProxCenter ou PegaProx : un token compromis se révoque sans casser les autres intégrations.

Raccorder vos serveurs Proxmox VE et votre PBS

Dans PDM, l'onglet Configuration du menu Remotes liste les remotes et permet d'en ajouter. Choisissez le type (Proxmox VE ou Proxmox Backup Server), donnez un identifiant court (par exemple dedie-a) et l'adresse d'un nœud. Pour un cluster, la configuration d'un remote accepte une liste d'adresses de nœuds ; pour des serveurs dédiés indépendants, créez un remote par serveur.

À la première connexion, PDM sonde le certificat du remote et vous montre son empreinte (confiance au premier usage). Ne l'acceptez pas les yeux fermés : comparez-la à celle affichée sur le nœud lui-même.

# sur un nœud Proxmox VE
pvenode cert info

# sur le PBS
proxmox-backup-manager cert info

L'empreinte acceptée est épinglée. Si le certificat du remote est renouvelé, la connexion échoue avec une erreur « Could not establish a TLS connection » ; après avoir vérifié le nouveau certificat par un canal de confiance, mettez à jour l'épinglage par l'action « Check Certificate » du remote, ou en ligne de commande :

proxmox-datacenter-manager-client remote probe-certificate dedie-a <nœud>
proxmox-datacenter-manager-client remote set-fingerprint dedie-a <nœud> <empreinte>

Un certificat public (Let's Encrypt) sur les remotes évite ce cas : PDM le valide alors avec le magasin de certificats du système, sans épinglage. La même opération d'ajout existe en ligne de commande, avec proxmox-datacenter-manager-client remote add et son option --create-token (« crée ce token sur le remote et l'utilise ») ; remote list et remote version dedie-a confirment que la connexion répond. Le tableau de bord affiche ensuite l'état des remotes, le nombre de VM et de conteneurs démarrés ou arrêtés, les datastores, les tâches en cours, l'usage CPU et mémoire, et l'état des abonnements.

Vues, rôles et délégation d'accès

Une vue est un tableau de bord limité à une sélection de ressources. Les ressources passent par une liste d'inclusion puis une liste d'exclusion, avec cinq types de filtres : resource-type (qemu, lxc, node, storage, datastore, sdn-zone), resource-pool, tag, remote et resource-id. Exemple tiré de la documentation : inclure toutes les machines virtuelles, puis exclure celles d'un remote précis. La vue se compose ensuite de widgets : état des nœuds et des invités, datastores PBS, classement des plus gros consommateurs de CPU ou de mémoire, résumé des tâches, arbre des ressources, jauges, et, depuis la 1.1, une carte du monde des remotes.

Le modèle de droits est volontairement court. PDM ne connaît que trois rôles : NoAccess, Administrator et Auditor (lecture de l'état et de la configuration, sans modification) ; les rôles personnalisés ne sont pas pris en charge. Ils s'appliquent sur des chemins d'ACL : /resource/{remote}, /resource/{remote}/guest/{vmid}, /resource/{remote}/node/{nœud}, /views/{vue}, /system/network, /access/users. Les droits se propagent aux chemins enfants, et une entrée plus précise l'emporte. Un droit accordé sur une vue permet d'agir sur toutes ses ressources sans accès direct au remote : c'est l'outil de délégation de PDM. Retenez toutefois que chaque action est exécutée sur le remote avec son token, donc bornée par les droits du compte de service.

Côté authentification, cinq royaumes : pam (comptes Linux de l'hôte), pdm (comptes propres à PDM, mots de passe hachés stockés sur la console), ldap, ad (Active Directory) et openid. Si vous avez déjà un Keycloak pour vos autres outils, c'est le fournisseur OpenID Connect à brancher ; la 1.1 a ajouté la prise en charge de l'audience OpenID et corrigé la redirection avec des fournisseurs comme Google. La double authentification accepte TOTP, WebAuthn (clés matérielles, TPM) et des clés de récupération à usage unique. Enfin, PDM a ses propres tokens API (utilisateur@royaume!nom, envoyés dans l'en-tête Authorization: PDMAPIToken), toujours limités aux droits de leur utilisateur.

Migrer une VM d'un serveur dédié à l'autre, entre clusters, depuis Proxmox Datacenter Manager

C'est la fonction qui change le plus la vie d'un parc de serveurs dédiés indépendants. Dans le menu Guests, l'action Migrate déplace un invité vers un autre nœud du même cluster ou vers un autre remote, et l'annonce de la 1.0 la présente comme une migration à chaud sans exigence de réseau de cluster entre les deux sites. Entre remotes, PDM s'appuie sur le mécanisme remote-migrate de Proxmox VE, que la page de manuel de qm marque encore comme fonction expérimentale. Le nœud source transfère disques et état vers l'API du remote cible : les deux serveurs doivent donc pouvoir se joindre, par exemple par le même tunnel.

La même migration en ligne de commande, depuis PDM, pour la VM 120 du serveur A vers le serveur B :

proxmox-datacenter-manager-client pve qemu remote-migrate dedie-a 120 dedie-b \
  --map-storage local-zfs:local-zfs --map-bridge vmbr0:vmbr0 \
  --online 1 --target-vmid 120 --bwlimit 51200

Les correspondances --map-storage et --map-bridge sont obligatoires : elles indiquent sur quel stockage et quel pont réseau du serveur cible atterrit chaque disque et chaque carte réseau. --bwlimit se donne en Kio/s (ici 50 Mio/s) pour ne pas saturer le lien en pleine journée. Par défaut, Proxmox VE garde la VM source arrêtée sur le serveur d'origine après une migration réussie ; --delete 1 la supprime. Les conteneurs LXC ont l'équivalent pve lxc remote-migrate, avec --restart et --timeout. L'action n'est pas proposée pour les modèles (templates).

Trois précautions sur des serveurs dédiés. Une VM en type de processeur host ne migre à chaud de façon fiable qu'entre processeurs identiques ; le type par défaut x86-64-v2-AES évite le problème entre deux générations de Xeon. Les adresses IP publiques appartiennent à chaque serveur : une VM déplacée change d'adresse, prévoyez la mise à jour du DNS. Et sauvegardez avant : une fonction marquée expérimentale se teste d'abord sur une VM sans importance.

PBS, mises à jour, abonnements et Ceph : ce que Proxmox Datacenter Manager centralise

Depuis la 1.0, un Proxmox Backup Server se raccorde comme un remote Proxmox VE. PDM affiche ses datastores, leur occupation, les graphiques d'entrées-sorties disque, le contenu par namespace et, depuis la 1.1, un onglet des tâches PBS. La configuration des tâches de sauvegarde reste en revanche dans Proxmox VE et PBS : la vue d'ensemble des tâches de sauvegarde, l'état des jobs, la navigation dans les datastores et la rétention (prune) figurent dans la feuille de route, pas dans la 1.1, tout comme les notifications système, de mises à jour et de tâches. Pour être alerté d'une sauvegarde manquée sur Discord ou Telegram, Pulse reste complémentaire, et les tests de restauration restent la seule preuve qu'une sauvegarde sert à quelque chose.

Les autres fonctions centralisées, version par version :

• Mises à jour (1.0) : l'onglet Updates du menu Remotes liste les dépôts et les paquets en attente sur tous les remotes ; l'installation se fait depuis le shell distant du nœud (Proxmox VE 9.1 ou PBS 4.1 requis). PDM montre ce qui manque, il ne remplace pas la méthode décrite dans sécuriser et mettre à jour Proxmox VE ;
• Registre des abonnements (1.1) : un réservoir central de clés, assignées aux nœuds à la main ou par suggestion automatique ;
• Ceph (1.1) : supervision en lecture seule des clusters hyperconvergés (santé, capacité, performances, moniteurs, OSD) ;
• Instantanés (1.1) : création, retour arrière et suppression des snapshots de tous les invités depuis la liste centrale ;
• SDN : état des zones sur tous les remotes et vue d'ensemble EVPN qui regroupe les zones et les VNets de tous les clusters, à mettre en regard de notre guide SDN Proxmox et isolation réseau ;
• Installations automatisées (1.1) : PDM gère les fichiers de réponses, les sert aux machines en cours d'installation et suit leur progression, chaque installation étant protégée par son propre token.

Cas concret : Pelican Panel, Stalwart Mail et PBS sur deux serveurs dédiés

Prenons un parc courant chez un hébergeur de serveurs de jeu ou une petite équipe : deux serveurs dédiés Proxmox VE indépendants et un PBS sur une machine distincte. Le serveur A fait tourner Pelican Panel, panel open source de serveurs de jeu qui a commencé comme un fork de Pterodactyl : une VM pour le Panel (interface web, AGPLv3) et une ou deux VM pour Wings (MIT), le démon qui lance chaque serveur de jeu dans un conteneur Docker. Si vous venez de Pterodactyl, notre guide installer un panel Pterodactyl pose les mêmes notions de Panel et de nœuds. Le serveur B héberge Stalwart, le serveur de messagerie en Rust qui réunit SMTP, IMAP et JMAP (notre article sur sa version 1.0), et la VM de PDM, qui surveille ainsi le serveur A depuis l'extérieur.

Étiquetez d'abord les invités sur chaque nœud, avec --tags (VM) ou son équivalent pour les conteneurs :

qm set 101 --tags jeux
qm set 102 --tags jeux
qm set 120 --tags mail
pct set 130 --tags mail

Puis créez trois vues dans PDM :

• Jeux : inclusion tag=jeux, widgets invités, classement CPU et mémoire, tâches. Le responsable des serveurs de jeu reçoit le rôle Administrator sur /views/jeux : il démarre, arrête et prend un instantané des VM Wings avant une mise à jour de jeu, sans voir la messagerie ;
• Messagerie : inclusion tag=mail, avec le rôle Auditor pour la personne qui gère les boîtes : elle voit l'état de la VM Stalwart sans pouvoir l'arrêter ;
• Sauvegardes : inclusion resource-type=datastore, widget des datastores PBS, pour suivre l'occupation des sauvegardes des deux serveurs.

Avant une maintenance sur le serveur A, la migration entre remotes déplace la VM du Panel vers le serveur B, puis la ramène, en mettant à jour l'enregistrement DNS du panel à chaque déplacement ; les VM Wings, plus lourdes et liées aux adresses IP annoncées aux joueurs, se sauvegardent plutôt dans PBS et redémarrent après l'intervention. Les serveurs dédiés ElypseCloud, bi-processeur Intel Xeon E5-2620 v4 ou Xeon Gold 6230 avec 32 à 256 Go de RAM ECC, accueillent chacun un Proxmox VE bien rempli ; si vous possédez déjà vos propres machines, le housing en datacenter les accueille, et PDM les supervise de la même façon.

Sécuriser et mettre à jour la console

PDM détient un token sur chacun de vos hyperviseurs : c'est la machine la plus sensible du parc. Les règles, par ordre d'importance :

• Console injoignable depuis Internet : port 8443 limité à vos adresses d'administration ou au VPN avec un pare-feu nftables, API Proxmox VE et PBS jointes par le tunnel ;
• Double authentification pour chaque compte, un compte par personne, et OpenID Connect dès que vous avez un fournisseur d'identité ;
• Comptes de service pdm@pve et pdm@pbs plutôt que root, et proxmox-datacenter-manager-client remote delete dedie-a --delete-token 1 pour supprimer aussi le token quand un serveur quitte le parc ;
• Certificat ACME : « Configuration → Certificates » dans l'interface, ou les sous-commandes acme account register, acme plugin add et acme certificate order de proxmox-datacenter-manager-admin ;
• Sauvegarde du répertoire /etc/proxmox-datacenter-manager/ (remotes, vues, comptes et ACL) dans vos sauvegardes chiffrées hors site.

Pour les mises à jour, passer de la 1.0 à la 1.1 est une mise à jour ordinaire : « Administration → Updates » dans l'interface, ou en ligne de commande :

apt update
apt full-upgrade

La FAQ de PDM déconseille un simple apt upgrade, qui peut laisser des paquets à moitié mis à jour, et demande de ne continuer que si apt update se termine sans erreur. Lisez les notes de version avant : la 1.1 a par exemple retiré l'appel d'API /nodes/localhost/rrdata. Le dépôt pdm-enterprise, plus stable, devient accessible dès qu'au moins 80 % des nœuds de vos remotes ont un abonnement Basic ou supérieur valide.

Conclusion

Un VPS de 2 vCPU et 4 Go, un métapaquet Debian et un compte de service par serveur : en moins d'une heure, vos serveurs dédiés Proxmox VE et votre PBS partagent un tableau de bord, des vues délégables, une liste centrale des invités et des instantanés, l'état des mises à jour et une migration de VM d'un serveur à l'autre que l'interface native ne propose pas entre hôtes indépendants. Proxmox Datacenter Manager n'a ni l'équilibrage de charge ni la migration depuis ESXi de ProxCenter ou de PegaProx, mais c'est l'outil de l'éditeur, sans coût supplémentaire, et sa feuille de route (consoles des invités, notifications, intégration PBS plus profonde, dossiers et ACL plus fines) comble ses manques version après version. Commencez en supervision seule avec PVEAuditor, testez la migration entre remotes sur une VM sans importance, puis élargissez les droits quand le parc vous fait confiance.