[Proxmox] Installare e configurare Proxmox Datacenter Manager: guida completa

Chi gestisce più cluster Proxmox VE conosce bene il problema: ogni cluster ha la sua interfaccia, i suoi grafici, la sua lista di update. Non esiste un punto unico da cui guardare l’infrastruttura, e ogni volta che serve una risposta banale quanti nodi ho offline? Quali hanno aggiornamenti pendenti? Dove sta girando quella VM? bisogna aprire cinque tab diverse.

Proxmox Datacenter Manager (PDM) nasce esattamente per questo. È il prodotto che Proxmox ha portato in versione stabile a fine 2025 e che, nella filosofia open source dell’ecosistema, occupa lo spazio che in casa VMware è del vCenter: una single pane of glass che aggrega Proxmox VE e Proxmox Backup Server sparsi su siti diversi, senza richiedere che quei sistemi facciano parte dello stesso cluster.

In questa guida vediamo l’installazione completa da ISO, il primo accesso, l’aggiunta di un cluster PVE come remote con la gestione dei certificati self-signed, e la configurazione dei repository per tenere aggiornata l’appliance.

Gli screenshot di questa guida sono stati realizzati su PDM 1.0.1. La procedura è identica sulle release successive della serie 1.x: cambiano dettagli grafici, non il flusso.

---

Cosa fa (e cosa non fa) Proxmox Datacenter Manager

Prima di installarlo conviene chiarire il perimetro, perché è il punto su cui nascono più aspettative sbagliate.

Cosa fa:

• Aggrega metriche di CPU, RAM e storage di tutti i nodi PVE e PBS collegati in un’unica dashboard.
• Permette operazioni sul ciclo di vita dei guest: start, stop, reboot, snapshot, migrazione.
• Supporta la live migration tra cluster indipendenti, senza requisiti di cluster network condiviso. È probabilmente la feature più interessante dell’intero prodotto.
• Centralizza il pannello degli aggiornamenti: vedi da un solo posto quali nodi hanno pacchetti pendenti.
• Gestisce SDN con zone EVPN e VNet distribuite su più remote.
• Offre viste personalizzate e RBAC, così puoi dare a un team la visibilità su un sottoinsieme di risorse senza esporre l’intera infrastruttura.

Cosa non fa:

• Non sostituisce l’interfaccia di Proxmox VE. Per le configurazioni complesse PDM ti offre un pulsante Open Web UI che ti porta direttamente sul nodo giusto.
• Non è un componente critico per l’esercizio: se PDM si spegne, i cluster continuano a funzionare esattamente come prima. È uno strumento di gestione, non un control plane.
• Non è un sistema di backup né di monitoraggio storico a lungo termine.

Nota architetturale importante: PDM deve poter raggiungere tutti i remote via API. Il contrario non serve — i remote non devono raggiungere PDM. I reverse proxy tra PDM e i remote non sono supportati: se hai host da non esporre direttamente, la strada consigliata da Proxmox è un tunnel (WireGuard o OpenVPN).

---

Requisiti

Voce	Minimo (valutazione)	Consigliato (produzione)
CPU	64 bit, 1 core	2+ core Intel/AMD moderni
RAM	1 GiB	4 GiB
Disco	10 GB	40 GB o più
Rete	1 NIC	NIC multi-gigabit ridondate

Nella pratica PDM è estremamente leggero: nel lab di questa guida gira su una VM con 32 GB di disco e non supera l’1-2% di CPU a regime.

Porte da aprire sul firewall:

Direzione	Porta	Uso
Client → PDM	TCP 8443	Interfaccia web e API
PDM → nodi PVE	TCP 8006	API Proxmox VE
PDM → nodi PBS	TCP 8007	API Proxmox Backup Server

Su quale hardware farlo girare? Metterlo come VM dentro uno dei cluster che gestisce è comodo ma logicamente circolare. Se l’infrastruttura è piccola va benissimo lo stesso; se hai più siti, la scelta più pulita è una VM su un cluster di management separato, oppure un mini-server dedicato.

---

Fase 1 — Installazione da ISO

Scarica l’immagine ISO dalla pagina download di Proxmox e scrivila su una chiavetta USB (Etcher, oppure Rufus in modalità DD; UNetbootin non funziona con le ISO Proxmox). Se installi su una VM, monti direttamente la ISO.

Al boot compare il menu dell’installer. Scegli Install Proxmox Datacenter Manager (Graphical).

Il primo passaggio è l’accettazione della EULA. PDM è rilasciato sotto GNU AGPL v3: il software è libero, la sottoscrizione a pagamento serve per l’accesso al repository enterprise e al supporto.

Disco di destinazione

Qui selezioni il disco su cui installare. Attenzione: tutti i dati presenti verranno cancellati.

Il pulsante Options apre le impostazioni avanzate del filesystem. Il default è ext4 su disco singolo, più che adeguato per un lab o una VM. In produzione su bare metal la scelta consigliata è ZFS in mirror su due dischi: PDM conserva localmente le metriche RRD di tutta l’infrastruttura, e perderle per un disco morto è una seccatura evitabile.

ZFS non va usato sopra un controller RAID hardware. O RAID hardware con BBU e filesystem ext4/XFS, oppure ZFS su dischi in modalità HBA/IT. Mai i due insieme.

Località e tastiera

Impostazioni classiche: paese, fuso orario e layout di tastiera. Per un’installazione italiana: Italy, Europe/Rome, Italian.

Il layout di tastiera vale anche per la console locale, quindi se hai intenzione di lavorare da terminale fisico è meglio metterlo giusto subito.

Password e indirizzo e-mail

La password che imposti qui è quella dell’utente root — sia per la console di sistema sia per il login web con realm pam.

L’indirizzo e-mail non è un campo di facciata: è la destinazione delle notifiche di sistema per l’utente root. Metti una casella che qualcuno legge davvero, non admin@localhost.

Configurazione di rete

Passaggio che merita attenzione, perché sbagliarlo qui significa dover rimettere le mani sulla console dopo il reboot.

I campi da compilare:

• Management Interface — la NIC da usare per l’accesso di gestione.
• Hostname (FQDN) — nome completo, ad esempio pdm.azienda.lan. Deve essere risolvibile.
• IP Address (CIDR) — indirizzo statico con la maschera, ad esempio 10.0.5.36/24.
• Gateway e DNS Server.

Il DNS non è opzionale. Nella fase di aggiunta dei remote, PDM propone gli endpoint usando gli hostname dei nodi così come li conosce il cluster: se non riesce a risolverli, la connessione fallisce. Ci torniamo nella Fase 3, perché è il singolo punto in cui inciampano quasi tutti.

Lascia spuntato Pin network interface names: fissa i nomi delle interfacce così non cambiano se un giorno sposti la scheda di slot o aggiungi una NIC.

Riepilogo e installazione

L’ultima schermata riassume tutte le scelte. È il momento di rileggere IP, gateway e hostname prima di premere Install.

L’installazione dura pochi minuti. Al termine, l’installer mostra l’indirizzo da usare per il primo accesso e riavvia automaticamente.

Dopo il reboot, la console locale mostra il banner con l’URL dell’interfaccia web e il prompt di login.

---

Fase 2 — Primo accesso all’interfaccia web

Punta il browser su:

https://<indirizzo-ip>:8443

Nel nostro esempio: https://10.0.5.36:8443

La porta è 8443, non 8006. È il primo dettaglio che confonde chi arriva da Proxmox VE. Il certificato è self-signed, quindi il browser mostrerà un avviso: normale a questo punto: nella sezione finale vediamo come sostituirlo.

Nella schermata di login inserisci root, la password scelta in installazione, e lascia il realm su pam.

La dashboard iniziale è vuota, e giustamente: non abbiamo ancora collegato nulla. Il riquadro Remotes segnala “No remotes configured”.

Vale la pena farsi un giro nel menu laterale prima di procedere, perché la struttura è la mappa mentale del prodotto:

Voce	Contenuto
Dashboard	Panoramica aggregata di tutta l’infrastruttura
Views	Viste personalizzate filtrate per tag, tipo di risorsa o remote
Notes	Annotazioni libere, comode per documentare interventi
Configuration	Access Control (utenti, token, realm), Certificates, Subscription
Administration	Stato del nodo PDM, Updates, Repositories, Syslog, Tasks, Shell
SDN	Configurazione EVPN distribuita
Remotes	I sistemi collegati

---

Fase 3 — Aggiungere un cluster Proxmox VE come remote

Questa è la parte centrale, e l’unica in cui serve un po’ di attenzione.

Vai su Remotes → Configuration. La lista è vuota.

Clicca Add e scegli il tipo di sistema da collegare: Proxmox VE oppure Proxmox Backup Server.

Il wizard Add Remote

Il wizard ha quattro schede: Probe Remote, Settings, Endpoints, Summary.

Nella prima scheda servono due informazioni:

• Server Address — IP o hostname di uno qualsiasi dei nodi del cluster. Non serve indicarli tutti: PDM interroga quel nodo e scopre da solo la topologia.
• Fingerprint — l’impronta SHA-256 del certificato del nodo. Obbligatoria se il certificato è self-signed, cioè nel caso standard di un’installazione Proxmox VE non personalizzata.

Recuperare il fingerprint del nodo

Apri una shell sul nodo PVE (console web o SSH) ed esegui:

pvenode cert info

Il comando restituisce più blocchi, uno per ogni certificato presente sul nodo. Quello che serve è il blocco relativo a pve-ssl.pem: è il certificato che il nodo presenta sulla porta 8006, quindi quello che PDM andrà a validare.

Non confondere pve-ssl.pem con pve-root-ca.pem (la CA del cluster) o con un eventuale pveproxy-ssl.pem (certificato custom caricato manualmente). Se copi il fingerprint sbagliato, la connessione fallisce con un errore di verifica del certificato.

In alternativa, dalla GUI di Proxmox VE: Nodo → System → Certificates, dove il fingerprint è mostrato nella colonna dedicata.

Copia il valore e incollalo nel wizard.

Scheda Settings: identificativo e credenziali

Mostra immagine

• Remote ID — il nome con cui il sistema comparirà in PDM. Scegli qualcosa di parlante: cluster-milano, pve-dr, pbs-sede. Nell’esempio abbiamo usato cluster.
• Login and create Token — l’opzione consigliata. Inserisci utente, password e realm del cluster remoto; PDM esegue il login, crea un API token dedicato e memorizza solo quello. La password non viene conservata.
• API Token Name — il nome del token che verrà creato sul remote, ad esempio pdm-admin-pdm.
• Use existing Token — se preferisci creare il token a mano sul cluster e incollare qui user@realm!token-id più il secret.

Consiglio per la produzione: qui abbiamo usato root@pam perché è un ambiente di laboratorio. In un’infrastruttura reale è preferibile creare sul cluster PVE un utente di servizio dedicato con un ruolo tarato sulle operazioni che PDM deve realmente compiere. Un token legato a root è comodo, ma è anche una credenziale con pieni poteri custodita fuori dal cluster.

Al termine, il token comparirà nella lista dei remote con la forma root@pam!pdm-admin-pdm. È revocabile in qualsiasi momento dal cluster PVE, e revocarlo scollega PDM senza altri effetti.

Scheda Endpoints: il punto dove si sbaglia

PDM ha già interrogato il cluster e precompilato la lista dei nodi con i rispettivi fingerprint. Nel nostro caso tre nodi.

E qui arriva il dettaglio importante. PDM elenca i nodi con il nome che hanno dentro il cluster — pve2, pve3 — perché è così che il cluster li conosce. Il problema è che PDM deve poterli risolvere in DNS. Se i nodi non hanno un record DNS raggiungibile dalla rete di management, o se il dominio di ricerca non coincide, le connessioni verso quei nodi falliranno mentre il primo (inserito per IP) funziona perfettamente. Il risultato è un remote che sembra funzionare a metà, con nodi che appaiono e scompaiono.

La soluzione più robusta è sostituire gli hostname con gli indirizzi IP, lasciando invariati i fingerprint.

La scelta tra IP e hostname è un compromesso: gli IP sono immuni ai problemi di risoluzione, gli hostname sopravvivono a una rinumerazione della rete. Se hai un DNS interno solido e ben mantenuto, usa i nomi. In tutti gli altri casi — e specialmente tra siti diversi — usa gli IP.

Il pulsante Add permette comunque di aggiungere più endpoint per lo stesso remote: è utile per dare a PDM percorsi alternativi verso lo stesso cluster.

Riepilogo e conferma

L’ultima scheda mostra il riepilogo: Remote ID, Auth ID, token da creare e l’elenco delle connessioni con i relativi fingerprint.

Premi Finish. Il remote compare immediatamente nella lista, con tipo pve, l’AuthId del token e l’elenco dei nodi.

Ripeti la procedura per ogni cluster o nodo standalone da collegare. Un nodo Proxmox VE singolo, fuori da qualsiasi cluster, si aggiunge esattamente allo stesso modo: avrà semplicemente un solo endpoint.

---

Fase 4 — La vista aggregata

Selezionando il remote nel menu laterale si apre la vista che giustifica l’esistenza del prodotto.

Sulla sinistra il riepilogo del cluster: numero di nodi, guest in esecuzione sul totale, utilizzo aggregato di CPU, memoria e storage, e le risorse allocate rispetto a quelle fisiche. Sotto, l’albero navigabile di Datacenter → nodi → guest e storage, con l’icona che apre direttamente la UI nativa di Proxmox VE sulla risorsa scelta.

Sulla destra il dettaglio del nodo selezionato: CPU, RAM, IO delay, load average, versione di pve-manager e del kernel, più i grafici RRD con selettore del periodo.

Da notare, in alto, l’indicatore rosso di Subscription Status: PDM aggrega anche lo stato delle sottoscrizioni di tutti i nodi collegati. In un parco macchine grande è un modo comodo per accorgersi che qualche nodo ha la licenza scaduta prima che lo faccia notare un update fallito.

---

Fase 5 — Repository e aggiornamento di PDM

Come ogni prodotto Proxmox, PDM esce dalla ISO con il repository enterprise abilitato. Senza una sottoscrizione valida quel repository restituisce 401 e apt update fallisce.

Vai su Administration → Repositories.

La situazione tipica di un’installazione appena fatta:

File	Repository	Stato
/etc/apt/sources.list.d/debian.sources	Debian trixie, trixie-updates, trixie-security	Attivi
/etc/apt/sources.list.d/pdm-enterprise.sources	pdm-enterprise	Attivo, ma senza sottoscrizione non funziona
/etc/apt/sources.list.d/proxmox.sources	pdm-no-subscription	Da aggiungere

Clicca Add e seleziona No-Subscription.

Poi seleziona la riga di pdm-enterprise e disabilitala. A questo punto PDM avverte che stai usando un repository non raccomandato per la produzione: è un avviso corretto e va preso per quello che è.

Il repository enterprise di PDM non richiede una sottoscrizione dedicata al Datacenter Manager, ma è vincolato al fatto che i nodi remoti gestiti abbiano una sottoscrizione Basic o superiore. Se hai già i cluster sotto contratto, hai diritto anche al repository enterprise di PDM: verificalo prima di ripiegare sul no-subscription.

Esiste anche un repository pdm-test, che come dice il nome serve solo a provare feature in sviluppo. Non usarlo su sistemi che ti interessano.

Passa alla scheda Updates e clicca Refresh. Comparirà l’elenco dei pacchetti aggiornabili, con versione corrente, nuova versione e descrizione.

Il pulsante Upgrade apre una console web che esegue l’aggiornamento in modo interattivo, con il riepilogo delle operazioni e la richiesta di conferma.

Confermi con y e l’aggiornamento procede.

Se l’aggiornamento include un nuovo kernel — cosa frequente, dato che PDM segue la stessa base kernel di Proxmox VE — serve un riavvio dell’appliance per attivarlo. Nessun impatto sui cluster gestiti: durante il reboot perdi solo la raccolta delle metriche.

Da riga di comando l’equivalente è il consueto:

apt update && apt full-upgrade

---

Certificati: sostituire il self-signed

Il certificato self-signed generato in installazione funziona, ma costringe a passare dall’avviso del browser a ogni accesso. Da Configuration → Certificates hai due strade:

Certificato interno. Se hai già una CA aziendale e un certificato wildcard, lo carichi da lì. È l’approccio tipico in un dominio interno dove i client si fidano già della CA.

ACME / Let’s Encrypt. PDM integra un client ACME con supporto per la challenge HTTP e per quella DNS. La challenge DNS è quella che serve nella maggior parte dei casi, perché permette di ottenere il certificato per un host che non è esposto su Internet.

C’è un motivo pratico in più per usare certificati validi sui nodi remoti, non solo su PDM: quando un remote presenta un certificato riconosciuto dal trust store di sistema, PDM non ha bisogno di fissare alcun fingerprint. Con i certificati self-signed, invece, il fingerprint viene pinnato al momento dell’aggiunta — e ogni rinnovo o rotazione del certificato rompe la connessione.

Se un remote smette di rispondere dopo un rinnovo

È lo scenario più comune di malfunzionamento, e l’errore è riconoscibile:

connection failed: Could not establish a TLS connection. Check whether the
fingerprint matches or the certificate on the remote is valid.

Nel 99% dei casi è un rinnovo legittimo del certificato sul nodo remoto. Per risolvere, dalla GUI apri il remote interessato e usa l’azione Check Certificate: PDM ricontatta il nodo, mostra il certificato attualmente presentato e ti permette di aggiornare il fingerprint memorizzato dopo che hai verificato il cambiamento.

Da riga di comando:

# Ispeziona il certificato presentato dal nodo
proxmox-datacenter-manager-client remote probe-certificate <remote> <nodo>

# Memorizza il nuovo fingerprint
proxmox-datacenter-manager-client remote set-fingerprint <remote> <nodo> <fingerprint>

Omettendo il fingerprint nell’ultimo comando si rimuove il pin, cosa da fare se nel frattempo il nodo è passato a un certificato attendibile.

Un cambio di fingerprint inatteso — cioè senza che nessuno abbia rinnovato niente — non va accettato con leggerezza: è esattamente la firma di un attacco man-in-the-middle. Verifica il nuovo certificato attraverso un canale attendibile prima di confermarlo. Il journal di sistema di PDM registra sia il fingerprint presentato sia quello atteso.

---

Consigli operativi

Parti in piccolo. Anche se la 1.x è stabile, ha senso collegare prima uno o due cluster non critici, prendere confidenza con viste e permessi, e solo dopo estendere a tutto il parco.

Metti in backup la configurazione. Lo stato di PDM vive in /etc/proxmox-datacenter-manager/ — remote, viste, utenti, ACL. È poca roba, ma ricostruirla a mano dopo un guasto è un pomeriggio buttato. Se PDM gira come VM, uno snapshot Veeam o PBS periodico risolve tutto.

Usa i tag e le Views. Su tre nodi non serve. Su cinquanta, le viste filtrate per sito o per criticità sono la differenza tra una dashboard utile e un muro di riquadri.

Non esporlo su Internet. Interfaccia di gestione con token verso tutti i tuoi cluster: sta dietro VPN, punto. E dato che i reverse proxy verso i remote non sono supportati, il tunnel è comunque la strada indicata da Proxmox per i siti remoti.

Attiva il 2FA su root. PDM supporta TOTP, WebAuthn e recovery key da Configuration → Access Control. Su un sistema che detiene le credenziali di accesso all’intera infrastruttura, è cinque minuti di lavoro ben spesi.

---

Conclusioni

Proxmox Datacenter Manager colma il vuoto più evidente dell’ecosistema Proxmox: la gestione multi-cluster. Non è un vCenter non ha DRS, non ha HA distribuita, non orchestra il ciclo di vita dell’hypervisor e non pretende di esserlo. È uno strumento di visibilità e di operatività quotidiana, costruito bene, leggero e coerente con il resto della piattaforma.

L’installazione è questione di minuti. L’unico punto che richiede attenzione è la gestione dei certificati self-signed e la risoluzione degli endpoint: se DNS e fingerprint sono a posto, il resto funziona senza sorprese.

Per chi gestisce più di un cluster, il valore si vede già al primo accesso alla dashboard.