Come installare Proxmox VE su Debian passo dopo passo

Installare Proxmox VE su Debian: scelta giusta e vincoli reali

Se hai già Debian installato e vuoi trasformarlo in un host di virtualizzazione, Proxmox VE è la strada più lineare. La parte importante non è solo “fare i pacchetti”, ma partire da un Debian pulito, allineato e con una rete stabile. Se il nodo deve andare in produzione, tratta l’operazione come un change controllato: verifica prima stato del sistema, pianifica un backup e tieni un accesso console fuori banda se disponibile.

Questa procedura assume Debian recente su architettura amd64, installazione minimale e accesso da root o sudo. Se hai già workload in esecuzione sul server, fermati: la migrazione verso Proxmox su un sistema già usato come host generico richiede valutazioni aggiuntive su rete, storage, servizi e compatibilità dei kernel.

Prerequisiti da controllare prima di toccare i repository

Prima di installare Proxmox VE, verifica tre cose: versione di Debian, supporto hardware e configurazione di rete. Proxmox si appoggia a Debian e a un kernel specifico; se il sistema è troppo vecchio o troppo “custom”, aumenti il rischio di conflitti.

1. Controlla la release di Debian:

cat /etc/debian_version
cat /etc/os-release

Atteso: Debian 12 o comunque una release supportata dalla versione di Proxmox che vuoi installare. Se sei su una versione non supportata, non forzare l’upgrade del cluster a metà strada: prima porta Debian a una base compatibile.

1. Verifica architettura e kernel:

uname -r
uname -m

Atteso: architettura amd64 e kernel Debian standard. Se hai già un kernel molto custom, valuta il rischio di moduli mancanti o driver non allineati.

1. Controlla hostname e risoluzione locale:

hostnamectl
getent hosts $(hostname -f)

Atteso: hostname FQDN coerente e risolvibile. Proxmox usa in modo sensibile la coerenza tra hostname, IP e DNS; se questa parte è sbagliata, ti ritrovi errori in GUI, cluster e certificati.

Preparazione del sistema Debian

Lavora su un sistema aggiornato. Prima di aggiungere repository esterni, sincronizza i pacchetti base e rimuovi eventuali fonti incompatibili. Su un host destinato a Proxmox, meno repository hai meglio è.

apt update
apt full-upgrade -y
reboot

Dopo il reboot, verifica che il sistema sia tornato pulito:

systemctl --failed
journalctl -p 3 -b --no-pager

Atteso: nessun servizio fallito e nessun errore grave persistente nel boot corrente. Se emergono errori di storage, rete o filesystem, chiudi quelli prima di installare l’hypervisor.

Se usi SSH remoto, mantieni aperta una seconda sessione o una console fuori banda. L’installazione del kernel e dei componenti Proxmox può richiedere riavvio e modifica della rete.

Repository Proxmox VE e chiave di firma

Il modo corretto è aggiungere il repository ufficiale Proxmox VE e installare la chiave di firma in formato gestito da apt. Non usare chiavi vecchie o metodi deprecati se puoi evitarlo.

Prima crea un file dedicato per il repository. La sintassi cambia a seconda della release di Proxmox, ma il principio è questo: usare il ramo corretto per la tua versione e il componente principale.

echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" > /etc/apt/sources.list.d/pve-install-repo.list

Se stai usando una release diversa da bookworm, sostituisci il nome della suite con quella corrispondente alla tua base Debian supportata. Non mischiare repository di release diverse.

Ora importa la chiave del repository con il metodo consigliato dalla tua versione di Debian/apt. Con sistemi recenti, il formato keyring è quello più pulito.

wget -qO /usr/share/keyrings/proxmox-archive-keyring.gpg https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg

Se il link o il file di chiave cambiano nella tua release, verifica sul sito ufficiale Proxmox il nome esatto del keyring. Non andare a tentativi su un host di produzione.

Controlla che apt veda davvero il repository:

apt update
apt-cache policy pve-manager

Atteso: il pacchetto pve-manager compare dal repository Proxmox e non solo da Debian standard. Se apt segnala errori di firma o release, fermati: quasi sempre il problema è suite sbagliata, chiave errata o repository scritto male.

Installazione dei pacchetti Proxmox VE

Il pacchetto base da installare è proxmox-ve. In pratica ti porta dietro il kernel Proxmox, i tool di gestione, il demone web e i componenti necessari per VM e container. Su un nodo pulito è la via più semplice.

apt install -y proxmox-ve postfix open-iscsi chrony

Perché questi pacchetti: proxmox-ve è il metapacchetto principale; postfix serve per notifiche locali e mail di sistema; open-iscsi è utile se userai storage iSCSI; chrony o un demone NTP affidabile è importante per cluster e certificati.

Durante l’installazione di Postfix, se non hai un mail server esterno già definito, la scelta più semplice per un singolo nodo è “Local only”. In ambienti con relay SMTP aziendale, configura subito il relay corretto invece di lasciare un Postfix a metà.

Quando l’installazione finisce, verifica i pacchetti principali:

dpkg -l | egrep 'proxmox-ve|pve-manager|pve-kernel|qemu-server|lxc-pve'

Atteso: i pacchetti Proxmox risultano installati. Se manca il kernel Proxmox o compaiono errori di dipendenze, non andare oltre: risolvi prima i conflitti apt.

Rimozione del kernel Debian vecchio e boot sul kernel Proxmox

Proxmox installa il proprio kernel, ma il sistema può continuare ad avere kernel Debian precedenti. Questo non è un problema immediato, ma su un nodo definitivo conviene evitare ambiguità nel boot.

Controlla i kernel installati:

dpkg -l | grep linux-image

Se vedi kernel Debian non necessari, puoi pianificare la loro rimozione dopo aver confermato che il sistema avvia correttamente il kernel Proxmox. Non cancellare l’unico kernel avviabile prima di aver testato il boot.

Verifica il kernel attivo dopo reboot:

uname -r

Atteso: un kernel Proxmox, non il vecchio kernel Debian standard. Se il sistema ha avviato quello sbagliato, controlla il menu di GRUB e l’ordine di boot.

Se vuoi pulire i kernel vecchi, fallo solo quando hai un boot confermato e un accesso di emergenza disponibile. Il rollback, in questo caso, è tenere almeno un kernel funzionante installato e non rimuovere GRUB o i pacchetti di base.

Configurazione della rete: il punto dove si rompe più spesso

Proxmox vive di rete: management, storage, VM bridge, cluster. Prima di creare bridge e VLAN, assicurati che l’interfaccia di management sia stabile e che l’IP del nodo non cambi in modo imprevedibile.

Controlla le interfacce presenti:

ip a
ip r

Atteso: IP statico corretto e gateway raggiungibile. Se il server prende l’IP da DHCP, per un host Proxmox in produzione è meglio passare a statico.

Il modello più comune è un bridge Linux, di solito vmbr0, collegato alla NIC fisica. Un esempio tipico su Debian con Proxmox è un file in /etc/network/interfaces con bridge per la LAN di management.

auto lo
iface lo inet loopback

auto enp1s0
iface enp1s0 inet manual

auto vmbr0
iface vmbr0 inet static
    address 192.0.2.10/24
    gateway 192.0.2.1
    bridge-ports enp1s0
    bridge-stp off
    bridge-fd 0

Prima di applicare modifiche di rete su remoto, salva una copia del file e prepara una finestra di rollback. Il blast radius qui è alto: se sbagli nome interfaccia o gateway, perdi connettività al nodo.

Verifica la configurazione con un reload prudente o, meglio ancora, in console locale:

ifreload -a

Se usi ifupdown2, è il modo più pulito per ricaricare la rete. In caso di errore, torna al file precedente e riapplica. Non improvvisare bridge aggiuntivi finché il management non è stabile.

Accesso alla GUI e verifica dei servizi base

Una volta installato Proxmox, la GUI deve rispondere sulla porta 8006. La verifica minima è una risposta HTTPS con certificato auto-firmato iniziale o il certificato configurato successivamente.

ss -lntp | grep 8006
curl -kI https://127.0.0.1:8006/

Atteso: il servizio web di Proxmox ascolta sulla porta 8006 e risponde con header HTTP validi. Se la porta non è in ascolto, controlla lo stato del servizio web e i log.

systemctl status pveproxy pvedaemon pvestatd --no-pager
journalctl -u pveproxy -b --no-pager

Se un servizio è in errore, la causa tipica è una configurazione incompleta, un problema di certificati o un conflitto di rete. Non cercare di “riparare” tutto insieme: guarda il primo errore utile nel log.

Apri poi la GUI da browser all’indirizzo del nodo:

https://IP_DEL_NODO:8006

La prima volta vedrai un avviso sul certificato auto-generato. È normale. La fase successiva è sostituirlo con un certificato valido, soprattutto se il nodo viene esposto oltre la LAN di amministrazione.

Controlli post-installazione e messa in sicurezza minima

Dopo l’installazione, fai i controlli base come su qualunque host esposto a rete di produzione. La superficie d’attacco non è enorme, ma non va lasciata “default and forgotten”.

1. Verifica patch e stato aggiornamenti:

apt update
apt list --upgradable

Atteso: nessun pacchetto critico in stato incoerente. Pianifica il ciclo di update e riavvio, perché kernel e componenti Proxmox richiedono manutenzione regolare.

1. Controlla che il tempo sia corretto:

timedatectl status
chronyc tracking

Atteso: NTP sincronizzato. In cluster, lo sfasamento temporale crea problemi inutili su autenticazione, log e quorum.

1. Verifica storage locale:

lsblk
pvesm status

Atteso: disco di sistema e storage visibili come previsto. Se hai RAID hardware o ZFS, controlla anche lo stato lato controller o pool prima di creare VM.

Se il nodo è destinato a essere raggiunto solo da una rete di management, limita l’esposizione alla sola porta necessaria e gestisci l’accesso amministrativo con ACL, VPN o rete dedicata. La GUI di Proxmox non va lasciata aperta su Internet.

Se vuoi usare un certificato valido subito

Il certificato iniziale self-signed funziona, ma in ambienti seri conviene installare un certificato valido appena il nodo è operativo. Questo riduce warning lato browser e semplifica automazioni e integrazioni.

Puoi usare un certificato interno aziendale o uno pubblico, a seconda del contesto. La scelta dipende da esposizione, DNS e policy di sicurezza. Se il nodo non è raggiungibile pubblicamente, un certificato della tua CA interna è spesso la soluzione più pulita.

Dopo il cambio certificato, riavvia il proxy web e verifica la catena:

systemctl restart pveproxy
openssl s_client -connect 127.0.0.1:8006 -servername NOME_FQDN

Atteso: catena coerente e nessun errore di handshake evidente. Se il nome nel certificato non coincide con l’FQDN del nodo, avrai warning anche con certificati validi.

Problemi tipici e come chiuderli senza fare danni

Il caso più comune è il mismatch tra hostname, IP e DNS. Sintomo: GUI raggiungibile a tratti, errori di certificato o problemi nel join al cluster. Verifica hostname -f, getent hosts e il record DNS prima di cambiare altro.

Secondo caso: repository scritto male o release errata. Sintomo: apt update fallisce o non vede pve-manager. Verifica il file in /etc/apt/sources.list.d/ e la chiave in /usr/share/keyrings/.

Terzo caso: bridge di rete configurato con interfaccia sbagliata. Sintomo: perdi SSH dopo il reload. Qui il rollback è il file di rete precedente e l’accesso console. Non applicare modifiche remote senza una via di rientro.

Installazione completata: cosa deve risultare vero

A fine procedura, il nodo deve avere questi risultati minimi: web UI attiva su 8006, kernel Proxmox avviato, rete di management stabile, repository corretti e log senza errori critici. Solo dopo questi punti ha senso iniziare a creare VM, container e storage aggiuntivi.

Se stai preparando un host per produzione, la parte successiva non è “mettere subito una VM”, ma definire naming, backup, storage policy, VLAN e accessi amministrativi. Un nodo Proxmox installato male si trascina i problemi per anni; un nodo installato bene ti semplifica tutto il resto.

Assunzione: Debian supportato, accesso root/sudo disponibile, nessun workload critico preesistente sul server o change già approvato con rollback pronto.