# Procedura adattata al mio nodo Proxmox per pulizia ESP e fix kernel
## 1. Verificare l’UUID della ESP
cat /etc/kernel/proxmox-boot-uuids
# Output nel mio caso:
# 67D6-E50C
## 2. Verificare quale device corrisponde all’UUID
ls -al /dev/disk/by-uuid/67D6-E50C
# Output nel mio caso:
# /dev/disk/by-uuid/67D6-E50C -> ../../nvme0n1p2
# La mia ESP è quindi /dev/nvme0n1p2
## 3. Montare manualmente la ESP
mkdir /tmp/myesp
mount /dev/nvme0n1p2 /tmp/myesp
## 4. Elencare i kernel presenti nella ESP
ll /tmp/myesp/*/*
# Qui individuo le directory dei kernel vecchi da rimuovere:
# /tmp/myesp/.../5.15.108-1-pve
# /tmp/myesp/.../6.2.16-5-pve
## 5. Rimuovere SOLO i kernel vecchi
rm -rf /tmp/myesp/*/*/5.15.108-1-pve
rm -rf /tmp/myesp/*/*/6.2.16-5-pve
## 6. Smontare la ESP
umount /tmp/myesp
## 7. Riparare dpkg e completare l’installazione del kernel
apt-get -f install
Eliminazione manuale (riveduta)
###############################################
# SEQUENZA CORRETTA PULIZIA ESP + RIMOZIONE KERNEL 6.x
# Adattata ESATTAMENTE a ciò che ha scritto l’utente
###############################################
echo "=== 1) Identifica ESP ==="
cat /etc/kernel/proxmox-boot-uuids
ls -al /dev/disk/by-uuid/B130-7F39 # -> ../../sda2
echo "=== 2) Monta ESP ==="
mkdir -p /tmp/myesp
mount /dev/sda2 /tmp/myesp
echo "=== 3) Elenca kernel presenti nell'ESP ==="
ls -l /tmp/myesp
echo "=== 4) Cancella TUTTI i kernel vecchi (serie 6.x) ==="
rm -f /tmp/myesp/initrd.img-6*
rm -f /tmp/myesp/vmlinuz-6*
echo "=== 5) Verifica che NON ci siano più file 6.x ==="
ls -l /tmp/myesp
echo "=== 6) Controlla spazio ESP ==="
df -h /tmp/myesp
du -ah /tmp/myesp
echo "=== 7) Smonta ESP ==="
umount /tmp/myesp
echo "=== 8) Ripara dpkg se necessario ==="
apt-get -f install
echo "=== 9) Rimuovi i kernel 6.x ==="
apt purge proxmox-kernel-6.*
echo "=== 10) Verifica kernel installati ==="
dpkg -l | grep proxmox-kernel
echo "=== 11) Verifica boot configuration ==="
proxmox-boot-tool status
echo "=== COMPLETATO ==="
Molti utenti che iniziano a sperimentare la replica ZFS in ambienti Proxmox si trovano davanti a una situazione curiosa: una VM da 700 GB sembra occupare oltre 1,2 TB di spazio su ogni nodo. Ma come è possibile? In questo articolo analizziamo le cause reali, sfatiamo alcuni miti e offriamo strumenti pratici per monitorare e ottimizzare lo spazio.
🧠 Cos’è la replica ZFS in Proxmox?
La replica ZFS in Proxmox è un meccanismo che consente di copiare i dischi virtuali (vDisks) di una VM da un nodo a un altro, sfruttando le potenzialità di ZFS:
Replica incrementale basata su snapshot temporanei
Trasferimento solo dei blocchi modificati
Nessuna copia automatica del file .conf della VM (serve manualmente o via HA)
📦 Perché lo spazio occupato è maggiore della dimensione della VM?
1. Overhead ZFS
ZFS non memorizza solo i dati, ma anche:
Metadati per ogni blocco
Checksum per l’integrità
Struttura interna dei dataset
Intent log (ZIL) e cache (ARC/L2ARC)
Ogni disco virtuale è un dataset ZFS, quindi l’overhead si moltiplica.
2. Scritture reali vs spazio nominale
Una VM da 700 GB può scrivere molti più dati nel tempo (log, swap, file temporanei). ZFS conserva i blocchi modificati, anche se il file originale è stato cancellato.
3. Snapshot manuali
Se l’utente crea snapshot manuali e non li elimina, ZFS conserva i blocchi differenziali, aumentando lo spazio usato.
4. Snapshot di replica
Proxmox crea snapshot temporanei per la replica, con nomi tipo:
__replicate_<VMID>-<replicaID>_<timestamp>__
Questi snapshot non vengono conservati a lungo, ma se la replica è frequente o fallisce, possono accumularsi temporaneamente.
5. Compressione inefficace
Se ZFS ha compression=off o i dati sono poco compressibili (es. video, immagini), lo spazio occupato sarà vicino al reale.
🔍 Come analizzare lo spazio occupato
Ecco alcuni comandi utili da eseguire via terminale:
zfs get compression,compressratio rpool/data/subvol-100-disk-0
Verifica se la compressione è attiva e quanto è efficace.
zfs list -o name,used,refer,mountpoint
Confronta lo spazio totale usato con quello referenziato.
zfs get usedbysnapshots rpool/data/subvol-100-disk-0
Controlla quanto spazio è occupato dagli snapshot.
zfs list -t snapshot
Visualizza tutti gli snapshot attivi.
🧊 QCOW2 vs RAW: impatto sullo spazio
Formato
Tipo
Spazio iniziale
Snapshot
Performance
QCOW2
Thin
Solo spazio usato
✅
Buona
RAW
Thick
Spazio pieno
❌
Ottima
Su ZFS, anche i dischi RAW possono essere “thin” grazie alla compressione e ai blocchi sparsi, ma QCOW2 è nativamente più flessibile.
✅ Conclusione
Se vedi uno spazio ZFS occupato superiore alla dimensione della VM, non è un bug: è il risultato di come ZFS gestisce i dati, la replica e la protezione. Per tenere sotto controllo lo spazio:
Monitora gli snapshot manuali
Verifica la compressione
Analizza i blocchi modificati
Evita di duplicare VM con ID diversi che puntano agli stessi dischi
Esattamente 2 anni orsono , Red Hat divulgò la notizia che avrebbe cessato lo sviluppo di CentOS , ponendo lo stato di fatto che tale sistema era giunto in EOL .
Personalmente ho iniziato a cercare delle alternative e quindi tra queste ho optato per la distro “Rocky Linux” , compatibile con sistemi Red Hat . Questa offre la potenza e la stabilità in contesti di produzione server e workstation davvero apprezzabili . Ho eseguito l’installazione di tale distro su un sistema cluster Proxmox , che tra l’altro , aggiungo , che ho dovuto apportare piccole modifiche nella creazione di tale VM , in quanto si presentavano continui Kernel Panic al boot .
Le modifiche anzi la modifica necessaria per l’avvio di tale sistema , sta nel cambiare il default della cpu KVM in host CPU , con l’opzione CPU MAX per un contesto cluster . Fatto questo , la distro si avvia regolarmente senza alcun problema di sorta .
Avendo una rete gestita da un server Linux con servizi AD ( foresta 2008 ) elenco qui a seguire i passi necessar per l’accredito al dominio AD :
In primis , occorre entrare in console del sistema e procedere all’installazione dei pacchetti essenziali per effettuare il join su AD .
Bene , premessa a quanto scritto do per scontato che la date e l’ora di sistema sia corretti e che il resolv.conf punti correttmente al server AD con relativo search .
search internal2.lan
nameserver 192.168.3.123
Eseguire la procedura classica di join tramite il comando:
realm join -u administartor ad.internal2.lan
Ecco a seguire il file sssd.conf modificato e funzionante .
Molto importante risulta la direttiva “override_shell= /bin/bash ” , in quanto senza questo parametro risulta impossibile avere la shell bash subito dopo aver effettuato il login in ssh .
Bene , eseguite tutte le operazioni sopra descritte , si è pronti per effettuare e provare le connessioni in ssh , chiaramente utilizzando utenti del dominio AD . Per chi volesse installare l’interfaccia GUI , personalmente ho utilizzato GDM e la suite Gnome , senza riscontrare alcun problema di sorta , tranne la sezione di autentica che può essere risolta aggiungendo “adm” allo user del dominio con il quale si effettua il collegamento RDP . Inoltre è importante modiifcare la sezione visudo inerente ai permessi o meglio all’uso del comando “SU” .
