Creare manualmente un Thinpool LVM su Proxmox

Quando ha senso creare un thinpool LVM a mano su Proxmox

Su Proxmox il thin provisioning di solito viene creato dall’installer o dal wizard di storage, ma ci sono casi in cui conviene farlo manualmente: disco aggiunto dopo l’installazione, layout non standard, migrazione da storage preesistente, oppure necessità di separare in modo preciso data e metadata del thinpool.

La logica è semplice: si crea un volume group LVM, dentro il quale si ricava un thinpool composto da un LV dati e un LV metadati, e poi si registra quel VG in Proxmox come storage di tipo LVM-Thin. Da lì in poi Proxmox può allocare dischi virtuali in thin provisioning per le VM.

Questa procedura è adatta a chi gestisce direttamente il nodo e vuole capire cosa c’è sotto il pannello. Non è complicata, ma va fatta con attenzione: un errore di device selection può portare a perdita dati. Prima di scrivere qualsiasi comando, identifica con precisione il disco o la partizione destinata al pool.

Prerequisiti e controlli iniziali

Serve accesso root o privilegi equivalenti sul nodo Proxmox. Devi conoscere il dispositivo fisico da usare e verificare che sia libero. Se il disco contiene dati, fermati: questa procedura presuppone un device dedicato o comunque uno spazio che puoi inizializzare senza impattare altri volumi.

Controlla lo stato dei dischi e dei volumi esistenti:

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT,MODEL
pvs
vgs
lvs

Atteso: il device scelto non deve avere partizioni o mountpoint attivi se intendi inizializzarlo da zero. Se vedi un VG già in uso, non sovrascriverlo. Se il disco è nuovo e vuoto, puoi procedere.

Se il nodo usa già ZFS, Ceph o altri storage, la scelta del backend non cambia la procedura LVM, ma cambia il posizionamento operativo: evita di sovrapporre storage diversi sullo stesso disco senza una ragione precisa.

Scelta del disco e rischio operativo

La parte più delicata è la selezione del device. In Proxmox spesso i dischi compaiono come /dev/sdX o /dev/nvme0n1. Su sistemi recenti è preferibile usare i path stabili sotto /dev/disk/by-id/, soprattutto se il nodo ha più dischi e vuoi ridurre il rischio di confusione.

Esempio di identificazione:

ls -l /dev/disk/by-id/

Se devi creare il thinpool su una partizione specifica, assicurati che la partizione sia già stata creata e che sia del tipo corretto. In alternativa puoi usare l’intero disco, ma in ambienti server è spesso più pulito usare una partizione dedicata al VG.

Regola pratica: se non sei sicuro del device, non andare avanti. La verifica del path corretto vale più della velocità.

Creazione della struttura LVM

Il flusso standard è: inizializzare il device come physical volume, creare il volume group, poi creare i logical volume per metadata e dati del thinpool. In alcuni casi si usa una singola allocazione con lvcreate --type thin-pool, ma separare i parametri rende più chiaro il controllo della capacità.

Supponiamo di voler usare /dev/disk/by-id/ come riferimento e di chiamare il VG pve o un nome dedicato. Se il nodo Proxmox ha già un VG chiamato pve usato per altri scopi, non riutilizzarlo alla cieca: verifica prima la sua funzione con vgs e lvs.

Creazione del PV:

pvcreate /dev/disk/by-id/ID-DEL-DISCO

Atteso: il comando risponde con conferma di avvenuta inizializzazione. Verifica subito:

pvs

Creazione del VG:

vgcreate vg_thin /dev/disk/by-id/ID-DEL-DISCO

Atteso: il nuovo volume group compare in vgs con dimensione coerente col disco. Se il VG esiste già, non ricrearlo: in quel caso passa alla verifica della sua struttura.

Creazione del thinpool

Per un thinpool LVM classico, crea un LV dati e uno metadata. La dimensione dei metadati va dimensionata con criterio: troppo piccola e rischi saturazione dei metadata, troppo grande e sprechi spazio. In ambienti normali si parte con un valore prudente e si monitora l’uso.

Esempio, con 900G dati e 4G metadati su un VG chiamato vg_thin:

lvcreate -L 900G -n data vg_thin
lvcreate -L 4G -n metadata vg_thin
lvconvert --type thin-pool --poolmetadata vg_thin/metadata vg_thin/data

In molte installazioni è più comune creare direttamente un thinpool con un solo comando, ad esempio:

lvcreate --type thin-pool -L 900G -n data vg_thin

Se il comando crea anche i metadata in automatico, bene; altrimenti verifica la sintassi supportata dalla tua versione di LVM con lvcreate --help o man lvcreate. Le versioni e le policy possono cambiare leggermente tra distribuzioni.

Verifica il risultato:

lvs -a -o lv_name,vg_name,lv_attr,lv_size,pool_lv,metadata_percent,data_percent vg_thin

Atteso: il thinpool deve mostrare attributi coerenti con un pool thin, con percentuali inizialmente basse o nulle. Se metadata_percent cresce subito in modo anomalo, fermati e controlla la creazione.

Registrazione in Proxmox come storage LVM-Thin

Una volta creato il thinpool, va esposto a Proxmox come storage. Puoi farlo da interfaccia grafica oppure da file di configurazione. Se preferisci ridurre errori manuali, il pannello è spesso la via migliore: Datacenter → Storage → Add → LVM-Thin.

I campi tipici sono:

• ID: nome dello storage visibile in Proxmox.
• Volume group: il VG creato, ad esempio vg_thin.
• Thin pool: il nome del pool, ad esempio data.
• Content: di solito Disk image, eventualmente anche Container se serve.

Se preferisci CLI, il file di riferimento è /etc/pve/storage.cfg. Un esempio di blocco è:

lvmthin: local-thin
    vgname vg_thin
    thinpool data
    content images,rootdir

Verifica che la configurazione sia presente e coerente:

cat /etc/pve/storage.cfg
pvesm status

Atteso: lo storage compare come disponibile e con spazio libero coerente col pool. Se non compare, controlla nome VG, thinpool e sintassi del blocco.

Creazione di un disco VM sul thinpool

Il test pratico migliore è creare un piccolo disco per una VM di prova. Questo conferma che il backend è registrato bene e che Proxmox riesce a scrivere sul thinpool. Puoi farlo da GUI oppure da CLI.

Esempio da CLI, assegnando uno storage già registrato:

qm create 9000 --name test-thinpool --memory 512 --cores 1
qm set 9000 --scsi0 local-thin:4
qm start 9000

Atteso: la VM si avvia e il disco viene allocato nello storage thin. Verifica con:

qm config 9000
lvs -a -o lv_name,vg_name,lv_size,data_percent,metadata_percent

Se il disco non viene creato, controlla i log di Proxmox e i messaggi LVM. I punti utili sono spesso journalctl -xe, journalctl -u pvedaemon e journalctl -u pveproxy, oltre a eventuali errori durante qm o pvesm.

Controllo della salute del thinpool

Il thin provisioning è comodo, ma richiede monitoraggio. I due indicatori principali sono l’uso dati e l’uso dei metadata. Se i metadata si saturano, il pool può diventare inutilizzabile anche se c’è ancora spazio dati. Per questo non basta guardare solo il consumo del VG.

Controlli base:

lvs -a -o lv_name,vg_name,lv_attr,lv_size,pool_lv,data_percent,metadata_percent,seg_monitor
vgs -o vg_name,vg_size,vg_free,vg_attr vg_thin

Atteso: data_percent e metadata_percent devono restare sotto soglie sane. In pratica, se i metadata si avvicinano al limite, pianifica un’espansione prima che diventi emergenza.

Se vuoi una verifica rapida del backend usato da Proxmox:

pvesm list local-thin

Atteso: i volumi allocati risultano elencati correttamente. Se il comando restituisce errori di storage non trovato, il problema è nella registrazione di Proxmox, non nel pool LVM in sé.

Espansione del thinpool

Uno dei vantaggi del thinpool è che puoi espanderlo senza fermare le VM, purché il VG abbia spazio libero. La sequenza minima è estendere il VG a monte, poi il thinpool. Se il disco fisico è già stato aumentato a livello hardware o hypervisor, prima fai rescan del device e poi aggiorna il PV.

Esempio:

pvresize /dev/disk/by-id/ID-DEL-DISCO
vgs
lvextend -l +100%FREE vg_thin/data

Atteso: il thinpool cresce e vgs mostra meno spazio libero nel VG. Dopo l’espansione, ricontrolla data_percent e metadata_percent.

Se vuoi una modifica più controllata, estendi di una quantità precisa e non di tutto il free space. Questo è spesso preferibile in ambienti produttivi dove vuoi lasciare margine per future emergenze o per altri volumi nello stesso VG.

Riduzione del rischio e rollback

Il rollback dipende da quanto sei andato avanti. Prima della creazione del PV, il rischio è nullo se hai solo ispezionato i device. Dopo pvcreate, il rollback reale consiste nel rimuovere il PV e, se creato, il VG. Questo è distruttivo: va fatto solo se sei sicuro che il device non contenga dati utili.

Sequenza di rimozione, solo se il pool è nuovo e non usato:

lvremove vg_thin/data
vgremove vg_thin
pvremove /dev/disk/by-id/ID-DEL-DISCO

Prima di eseguire, verifica con lvs e vgs che non ci siano VM o volumi dipendenti. Se il thinpool è già stato aggiunto a Proxmox e usato, rimuovere il backend rompe i dischi virtuali che dipendono da esso.

Se il problema è solo nella registrazione di Proxmox, il rollback è più semplice: rimuovi lo storage da /etc/pve/storage.cfg o dal pannello e ricarica la configurazione. In quel caso il thinpool LVM resta intatto sul nodo.

Verifica finale operativa

La verifica corretta non è solo “compare in GUI”. Devi vedere tre cose: il VG esiste, il thinpool è attivo e Proxmox lo usa per creare un disco VM. Il check finale minimo è questo:

pvs
vgs
lvs -a -o lv_name,vg_name,lv_attr,lv_size,data_percent,metadata_percent
pvesm status

Se tutti i comandi tornano senza errori e il pool appare con spazio disponibile, la configurazione è operativa. Se la VM di test si avvia e il disco è visibile nella configurazione della VM, hai confermato anche l’integrazione lato Proxmox.

Assunzione: il disco usato è dedicato o comunque libero da dati da preservare, e il nodo Proxmox non richiede una migrazione contestuale di altri storage durante la creazione del thinpool.

Note pratiche da tenere a mente

In produzione conviene lasciare margine sia sullo spazio dati sia sui metadata. Non portare il thinpool vicino al 100% prima di intervenire. Se il pool è molto usato, monitora periodicamente i valori con un job o con il sistema di monitoring già in uso.

Se vuoi standardizzare il lavoro, documenta sempre: device fisico, nome VG, nome thinpool, storage ID in Proxmox e capacità allocata. È il minimo per poter ricostruire la configurazione o fare troubleshooting senza dover indovinare a posteriori.

Per ambienti con più nodi, ricorda che il thinpool LVM è locale al nodo. Se ti serve storage condiviso tra host, questa non è la strada giusta: serve un backend condiviso o una soluzione di orchestrazione diversa.