Proxmox: nodi, macchine virtuali e monitoraggio

Scopo e confini del modulo

Proxmox offre un inventario operativo di nodi, VM QEMU, container LXC, stato delle risorse, backup, problemi e sincronizzazioni. Non sostituisce ISP Dude: Proxmox osserva l’infrastruttura di virtualizzazione, mentre ISP Dude controlla apparati e topologia di rete.

La Dashboard legge gli ultimi stati salvati e non interroga Proxmox a ogni apertura. Questo mantiene la pagina rapida e permette di distinguere il dato dell’ultima sincronizzazione da una lettura live.

Prerequisiti e sicurezza

Preparare un account o token Proxmox dedicato con privilegi minimi sufficienti a leggere cluster, nodi, VM, container e backup. Per Console e azioni operative servono i permessi esplicitamente richiesti dal flusso. Usare HTTPS con certificato attendibile e non condividere credenziali tra tenant.

Se il nodo resta su rete privata, installare Edge Agent su una macchina che possa raggiungere la sua Base URL e aggiornarlo a una versione che dichiari il supporto API Proxmox. L’agent mantiene una connessione in uscita: non occorre pubblicare la porta 8006. Un nodo assegnato a un agent non ripiega automaticamente sulla connessione diretta.

Aggiungere un nodo

Aprire Proxmox → Nodi → Nuovo nodo, scegliere Connessione diretta oppure Tramite Edge Agent e inserire nome esatto del nodo, Base URL, API Token ID, secret e verifica SSL. In modalità agent è ammesso un indirizzo privato, per esempio https://10.10.0.15:8006, e bisogna selezionare l’agent della stessa rete.

La modalità diretta verifica la connessione durante il salvataggio. Per un nodo privato salvare prima la configurazione e usare poi Verifica connessione: il controllo passa dall’agent e conferma rete, TLS, autenticazione, permessi e corrispondenza del nome nel cluster. Nella modifica il secret resta nascosto; lasciare il campo vuoto per conservarlo.

Impostazioni generali e soglie

Le impostazioni definiscono frequenza di sincronizzazione, soglie che trasformano CPU, RAM, stato e backup in problemi e comportamento delle notifiche. Impostare soglie coerenti con il carico normale: valori troppo bassi generano rumore, valori troppo alti nascondono il degrado.

La scheda Edge Agent seleziona un agent predefinito per SSH dei nodi e Console VM/LXC. La scelta nell’header di una singola sessione è temporanea e non modifica il predefinito.

Dashboard gerarchica

La Dashboard organizza l’infrastruttura come nodo → VM/LXC. Ogni nodo mostra stato, indirizzo di gestione configurato, numero di macchine, CPU, RAM e backup; il dettaglio espandibile contiene le macchine ospitate. Un indirizzo diretto può essere aperto in una nuova scheda, mentre un indirizzo privato viene identificato con il badge Edge Agent e non viene aperto dal browser.

Espandi tutti e Comprimi tutti controllano l’intera gerarchia. La ricerca VM apre automaticamente il nodo proprietario. Leggere sempre l’orario dell’ultimo sync prima di trattare un valore come attuale.

Nodi, VM e container

L’elenco nodi consente modifica, test, aggiornamento cache ed eliminazione della configurazione. Eliminare il collegamento locale non deve essere usato come metodo per rimuovere un nodo dal cluster.

Le pagine VM/LXC mostrano identità, nodo, stato, CPU, RAM, uptime, backup e log. Le azioni operative devono rispettare lo stato reale della macchina e l’impatto sul cliente: arresto, riavvio o modifica non sono controlli innocui.

Start, Shutdown, Stop e Reboot

Start avvia una VM/LXC ferma. Shutdown richiede un arresto ordinato al guest e va preferito quando il sistema operativo risponde. Stop forza lo spegnimento e può causare perdita o corruzione dei dati. Reboot riavvia una macchina in esecuzione.

Controllare tipo QEMU/LXC, VMID, nodo, cliente e finestra di manutenzione prima della conferma. Attendere il task remoto e una sincronizzazione dello stato invece di ripetere il comando. I log mostrano anche console, backup e migrazioni osservate.

Sincronizzazione e log

La sincronizzazione recupera nodi, macchine, telemetria e backup, aggiorna gli stati correnti e registra le transizioni di problema. I log indicano inizio, esito, durata ed errori. Un errore di una risorsa non va confuso con la perdita dell’intero cluster.

Non avviare refresh ripetuti per compensare una credenziale errata. Correggere rete, certificato, autorizzazione o agent, quindi eseguire una sola prova esplicita.

Problemi e storico

La pagina Problemi distingue anomalie attive e risolte negli ultimi 30 giorni, filtrabili per stato, categoria e testo. Il sistema mantiene una sola anomalia aperta per la stessa chiave e la risolve quando la condizione scompare.

La registrazione del problema non dipende dall’abilitazione delle notifiche: lo storico resta disponibile anche se nessun destinatario è configurato. I problemi risolti più vecchi di 30 giorni vengono rimossi, quelli aperti restano.

Backup

Per ogni VM o container il modulo mostra lo stato backup osservato nell’ultima sincronizzazione. Verificare data, esito e anzianità rispetto alla policy dell’ISP. “Backup presente” non dimostra che il ripristino sia utilizzabile.

Definire test periodici di restore direttamente nel processo infrastrutturale. Una notifica su backup vecchio o fallito deve diventare un’attività con responsabile e scadenza.

Notifiche e destinatari

I canali disponibili comprendono push, WhatsApp, e-mail e Telegram. Telegram riusa il Bot condiviso e permette di selezionare soltanto account attivi e collegati. Configurare destinatari diversi per severità quando il processo lo richiede.

Invia test produce un messaggio reale e deve essere avviato dall’operatore. Un test riuscito prova il canale, non l’intero ciclo di rilevazione e ripristino.

SSH dei nodi

SSH è disponibile soltanto sui nodi. All’apertura si controlla il target e si inseriscono utente e password nel terminale. Le credenziali vengono cifrate nel payload temporaneo e cancellate quando l’agent le ritira o la richiesta scade.

Per un nodo diretto si può scegliere l’agent della sessione; per un nodo privato la selezione è bloccata sull’agent assegnato, perché è quello che possiede la corretta raggiungibilità di rete.

Console VM/LXC e audit

Le macchine espongono una Console Proxmox noVNC. Ogni apertura richiede 2FA e una nuova sessione. Il ticket VNC è temporaneo, resta in memoria e il Console Gateway inoltra il WebSocket senza conservarlo. Per i nodi privati sia la creazione del ticket sia il collegamento alla Console usano l’agent assegnato al nodo.

La pagina Audit Console registra verifica 2FA, richiesta, connessione, chiusura ed errori. HTTPS e WSS sono obbligatori in produzione. SSH non viene mostrato sulle VM/LXC: l’accesso interattivo corretto è Console.

Checklist

• Creare credenziali Proxmox a privilegio minimo
• Verificare TLS, rete e raggiungibilità
• Installare e registrare l’Edge Agent se necessario
• Testare il nodo prima del salvataggio
• Controllare nodi scoperti e ultimo sync
• Impostare soglie realistiche
• Assegnare destinatari ai problemi
• Controllare backup e prove di ripristino
• Usare SSH solo sui nodi
• Proteggere Console con 2FA
• Consultare l’audit dopo accessi o errori