TrueNAS e Proxmox VE
Chi utilizza Proxmox VE insieme a TrueNAS conosce bene le strade più comuni per collegare i due mondi.
Possiamo esportare un dataset tramite NFS, creare un target iSCSI oppure, nelle infrastrutture più articolate, costruire qualcosa di decisamente più complesso.
Funziona.
Ma nel caso di iSCSI c’è sempre stata una certa quantità di lavoro manuale da mettere in conto: zvol, extent, target, mapping, LUN e relativa gestione nel tempo.
Il TrueNAS Proxmox VE Storage Plugin prova a cambiare proprio questo modello.
L’idea è semplice ma interessante: invece di trattare TrueNAS come un semplice dispositivo iSCSI remoto, Proxmox comunica direttamente con le API di TrueNAS e gli chiede di creare, modificare, clonare ed eliminare i volumi necessari alle macchine virtuali.
TrueNAS diventa quindi qualcosa di molto più vicino a un backend storage nativo di Proxmox.
E la cosa interessante è che sotto rimane ZFS.
Una SAN pilotata direttamente da Proxmox
L’architettura, semplificando, è questa:
Proxmox Cluster
|
+---- PVE01
| |
| +---- TrueNAS Plugin
|
+---- PVE02
| |
| +---- TrueNAS Plugin
|
+---- PVE03
|
+---- TrueNAS Plugin
|
|
iSCSI / NVMe-TCP
|
v
TrueNAS SCALE
|
ZFS Pool
|
Dataset
|
zvol
Il plugin viene installato sui nodi Proxmox e registra un nuovo tipo di storage.
A quel punto la creazione di un disco VM non richiede più di entrare nell’interfaccia TrueNAS per preparare manualmente il relativo LUN.
Possiamo, per esempio, aggiungere un disco a una VM direttamente da Proxmox.
qm set 100 --scsi0 truenas-storage:32
Dal punto di vista dell’amministratore stiamo chiedendo semplicemente a Proxmox di creare un disco da 32 GB.
Dietro le quinte, però, può succedere parecchio.
Il plugin comunica con TrueNAS, crea lo zvol corrispondente, prepara le risorse necessarie alla pubblicazione block storage e rende il nuovo dispositivo disponibile al nodo Proxmox.
Questo significa che la gestione del ciclo di vita del disco passa finalmente da Proxmox.
Ed è probabilmente la differenza più importante rispetto a una normale configurazione iSCSI.
Due reti logiche completamente diverse
Per capire bene il funzionamento del plugin bisogna distinguere due piani.
Il primo è il management plane:
Proxmox
|
| HTTPS / WebSocket
| TCP 443
|
v
TrueNAS API
Serve per operazioni come:
creazione zvol
eliminazione zvol
resize
snapshot
clone
gestione extent
mapping
provisioning NVMe
Il secondo è il data plane:
Proxmox
|
+------ iSCSI TCP 3260 ------+
| |
+------ NVMe/TCP ------------+
|
v
TrueNAS
L’API non trasporta quindi i dati delle VM.
Serve soltanto come canale di orchestrazione.
Una volta creato il volume, l’I/O passa direttamente attraverso iSCSI oppure NVMe over TCP.
È una distinzione importante anche dal punto di vista della progettazione della rete: la rete amministrativa e quella storage possono, e secondo me dovrebbero, essere trattate come elementi separati.
La parte interessante è sotto: ZFS
Con una configurazione iSCSI tradizionale potremmo avere qualcosa del genere:
VM
|
Proxmox
|
LVM
|
iSCSI
|
TrueNAS
Il plugin cambia leggermente prospettiva:
VM
|
RAW block device
|
iSCSI / NVMe-TCP
|
zvol
|
ZFS
Ogni disco virtuale corrisponde sostanzialmente a uno zvol gestito da TrueNAS.
Questo permette di utilizzare direttamente diverse funzionalità di ZFS senza inserire un ulteriore livello di gestione dei volumi sul lato Proxmox.
Non abbiamo quindi bisogno di utilizzare qcow2 per ottenere alcune delle funzionalità che normalmente cerchiamo in uno storage virtualizzato.
Snapshot ZFS
Una delle conseguenze più interessanti riguarda gli snapshot.
Dal punto di vista di Proxmox possiamo continuare a utilizzare i normali strumenti.
Per esempio:
qm snapshot 100 before-upgrade
Il plugin traduce l’operazione verso TrueNAS e sfrutta gli snapshot ZFS.
Sono supportati anche snapshot live con salvataggio dello stato della macchina virtuale, compresa la RAM. TrueNAS indica esplicitamente tra le funzionalità del plugin gli snapshot ZFS space-efficient e i live snapshot con vmstate.
Possiamo quindi arrivare a una situazione del genere:
VM
|
+---- disk
| |
| zvol
| |
| snapshot
|
+---- vmstate
La differenza rispetto a mettere un LVM sopra un LUN iSCSI è sostanziale.
In quel caso Proxmox conosce il proprio livello storage, ma non sa praticamente nulla di quello che succede dentro TrueNAS.
Qui invece il plugin è consapevole di ZFS.
Clone
Lo stesso principio vale per i clone.
ZFS permette di creare velocemente copie basate su snapshot senza duplicare immediatamente tutti i blocchi.
Per un ambiente di laboratorio, sviluppo o virtualizzazione questo può diventare estremamente interessante.
Immaginiamo una VM template da 40 GB.
Invece di copiare fisicamente 40 GB ogni volta:
Template
|
snapshot
|
+---- clone VM101
|
+---- clone VM102
|
+---- clone VM103
inizialmente i blocchi vengono condivisi.
Solo le modifiche successive occupano nuovo spazio.
In un laboratorio dove vengono create e distrutte frequentemente macchine virtuali è esattamente il tipo di funzionalità che può fare una differenza enorme.
Thin provisioning
Gli zvol possono inoltre essere creati in modalità sparse.
Possiamo quindi avere:
VM101 500 GB
VM102 500 GB
VM103 500 GB
----------------
virtuale 1500 GB
senza aver necessariamente allocato 1,5 TB di spazio fisico.
Lo spazio viene utilizzato progressivamente man mano che le VM scrivono dati.
Comodo?
Molto.
Pericoloso?
Anche.
Il thin provisioning sposta infatti il problema dalla capacità allocata alla capacità realmente consumata.
Se il pool dispone di 1 TB e abbiamo presentato alle VM 4 TB di dischi virtuali, tutto funziona benissimo fino al momento in cui le VM decidono davvero di utilizzare quello spazio.
Monitoraggio del pool, alert e capacity planning diventano quindi obbligatori.
Il parametro tn_sparse permette proprio di controllare questo comportamento nella configurazione del plugin.
Compressione senza qcow2
Un altro aspetto interessante è la compressione ZFS.
Il percorso diventa:
filesystem VM
|
RAW disk
|
zvol
|
compressione ZFS
|
pool
Non serve quindi utilizzare qcow2 per ottenere compressione lato storage.
Rimaniamo nel mondo block storage mantenendo la possibilità di sfruttare la compressione trasparente di ZFS.
Naturalmente il risultato reale dipende molto dal carico.
Database già compressi, file multimediali e archivi compressi offriranno ben poco margine.
Filesystem contenenti log, database poco compressi, sistemi operativi e grandi quantità di dati testuali possono invece beneficiare parecchio della compressione ZFS.
iSCSI oppure NVMe/TCP
Qui il progetto diventa ancora più interessante.
Il plugin supporta due modalità di trasporto.
La prima è il classico iSCSI:
PVE
|
| TCP 3260
|
v
TrueNAS
La seconda è NVMe over TCP:
PVE
|
| TCP 4420
|
v
TrueNAS
NVMe/TCP nasce con un modello maggiormente orientato al parallelismo rispetto al tradizionale stack SCSI utilizzato da iSCSI e può offrire vantaggi soprattutto con storage veloci, molte queue e carichi IOPS intensive.
La documentazione del plugin lo propone esplicitamente per infrastrutture moderne e carichi sensibili a latenza e overhead CPU. Richiede TrueNAS SCALE 25.10 o successivo, Proxmox VE 9.x o successivo e nvme-cli sui nodi Proxmox.
Per un’infrastruttura nuova io valuterei seriamente NVMe/TCP.
Ma con una precisazione importante.
Nuovo non significa automaticamente migliore in qualsiasi situazione.
Se abbiamo già un’infrastruttura iSCSI stabile, monitorata e ben conosciuta, non vedo alcuna ragione per migrare soltanto perché NVMe/TCP è tecnologicamente più recente.
Prima vengono stabilità e semplicità operativa.
E il multipath?
Su una SAN una singola connessione di rete è un single point of failure abbastanza evidente.
Il plugin supporta quindi anche configurazioni multipath iSCSI.
Una possibile topologia potrebbe essere:
STORAGE VLAN A
10.10.10.0/24
PVE01 NIC1 -------------------+
|
+---- TrueNAS NIC1
|
PVE02 NIC1 -------------------+
STORAGE VLAN B
10.10.20.0/24
PVE01 NIC2 -------------------+
|
+---- TrueNAS NIC2
|
PVE02 NIC2 -------------------+
Il punto non è soltanto aumentare la banda.
Il vantaggio principale è eliminare il percorso singolo.
Una porta, un cavo, una NIC oppure uno switch possono guastarsi senza necessariamente interrompere l’accesso allo storage.
La documentazione del progetto evidenzia però anche un dettaglio interessante: su TrueNAS alcune caratteristiche dello stack iSCSI possono limitare le prestazioni di lettura sequenziale su singolo flusso. NVMe/TCP elimina alcune di queste limitazioni grazie a un modello di queue più moderno.
Cluster Proxmox
Naturalmente tutto questo diventa particolarmente interessante in un cluster.
Possiamo avere:
PVE01 ----+
|
PVE02 ----+------ TrueNAS
|
PVE03 ----+
Lo storage viene dichiarato shared.
Questo significa che tutti i nodi vedono lo stesso disco della VM.
Durante una live migration:
VM su PVE01
|
v
VM su PVE02
il disco non deve essere copiato.
Rimane su TrueNAS.
Si sposta soltanto l’esecuzione della macchina virtuale.
È esattamente il modello classico di una SAN centralizzata.
E per chi arriva da VMware, Hyper-V o ambienti enterprise tradizionali è probabilmente un’architettura molto familiare.
Anche LXC
Il plugin non è limitato ai dischi QEMU.
Supporta anche root filesystem LXC.
In questo caso il block device viene utilizzato come filesystem del container.
Possiamo quindi avere sullo stesso backend:
TrueNAS ZFS
|
+---- VM100 disk
|
+---- VM101 disk
|
+---- CT200 rootfs
|
+---- CT201 rootfs
Il plugin rimane però uno storage orientato ai block device.
Non è pensato come repository universale per tutto quello che Proxmox può archiviare.
ISO, backup, template e snippet continueranno normalmente a vivere altrove, per esempio su NFS.
Ed è perfettamente sensato.
NFS non diventa improvvisamente inutile
Una configurazione molto pratica potrebbe infatti utilizzare entrambi.
TrueNAS
|
+---- NFS
| |
| +---- ISO
| +---- backup
| +---- template
|
+---- TrueNAS Plugin
|
+---- VM disk
+---- LXC rootfs
NFS rimane estremamente semplice e flessibile.
Per molti homelab e piccole installazioni potrebbe continuare a essere la soluzione migliore anche per i dischi delle VM.
Il plugin diventa interessante quando vogliamo un vero backend block storage e vogliamo contemporaneamente mantenere snapshot, clone, thin provisioning e gestione ZFS integrata.
Non è quindi una questione di stabilire se NFS sia migliore di iSCSI.
Sono strumenti differenti.
Mani in pasta
Vediamo una configurazione semplificata.
Prima di tutto su TrueNAS creiamo un dataset dedicato, per esempio:
tank/proxmox
Dal lato TrueNAS dobbiamo inoltre avere disponibili il servizio storage scelto e una API key con i privilegi necessari.
Con iSCSI la configurazione Proxmox avrà concettualmente parametri simili a questi:
truenasplugin: truenas-storage
tn_api_host 192.168.100.10
tn_api_key API_KEY
tn_dataset tank/proxmox
tn_transport_mode iscsi
tn_discovery_portal 192.168.100.10:3260
content images
shared 1
Con NVMe/TCP avremo invece:
truenasplugin: truenas-nvme
tn_api_host 192.168.100.10
tn_api_key API_KEY
tn_transport_mode nvme-tcp
tn_subsystem_nqn nqn.2005-10.org.freenas.ctl:proxmox-nvme
tn_dataset tank/proxmox
tn_discovery_portal 192.168.100.10:4420
content images
shared 1
Un dettaglio da sapere subito è che il transport mode viene considerato una proprietà fissa dello storage.
Non possiamo creare lo storage come iSCSI e trasformarlo successivamente in NVMe/TCP modificando semplicemente una riga.
I due backend utilizzano anche convenzioni differenti per i volumi.
Una volta aggiunto lo storage possiamo verificare lo stato con:
pvesm status
e quindi creare un disco.
Per esempio:
pvesm alloc truenas-storage 100 vm-100-disk-0 32G
Da quel momento entra in gioco l’orchestrazione.
Cosa succede realmente quando creo un disco
Supponiamo di creare:
VM 200
disco 100 GB
Il flusso concettuale diventa:
Proxmox
|
| create volume
|
v
TrueNAS API
|
+---- crea zvol
|
+---- configura esportazione block
|
+---- associa volume
|
v
iSCSI / NVMe-TCP
|
v
Proxmox
|
v
QEMU
Potremmo quindi trovare lato TrueNAS qualcosa assimilabile a:
tank/proxmox/vm-200-disk-0
Da quel momento QEMU utilizza il dispositivo block come disco della VM.
Questa automazione è esattamente ciò che rende il progetto interessante.
Creare manualmente un target iSCSI non è difficile.
Farlo per decine o centinaia di volumi, mantenendo sincronizzati nomi, mapping, snapshot e cancellazioni, è tutta un’altra storia.
TrueNAS Plugin contro Ceph
A questo punto viene inevitabile il confronto con Ceph.
Ma sono due architetture profondamente differenti.
Con Ceph possiamo avere:
PVE01
|
+---- OSD
PVE02
|
+---- OSD
PVE03
|
+---- OSD
Storage e compute sono distribuiti.
Con TrueNAS abbiamo invece:
PVE01 ----+
|
PVE02 ----+------ TrueNAS
|
PVE03 ----+
Compute distribuito, storage centralizzato.
Ceph distribuisce anche il failure domain dello storage.
TrueNAS concentra invece lo storage appliance in uno o più sistemi specificamente progettati per quello scopo.
Il primo richiede tipicamente più nodi, più dischi, più rete e una certa disciplina operativa.
Il secondo può risultare molto più semplice da amministrare.
Ma questa semplicità ha un prezzo.
Se abbiamo un solo TrueNAS, quel sistema rimane una componente critica dell’infrastruttura.
Possiamo ridondare NIC, switch, alimentatori, controller e dischi quanto vogliamo, ma il failure domain architetturale rimane diverso da quello di Ceph.
Ed è bene ricordarlo prima di chiamare qualcosa HA soltanto perché le VM possono migrare tra i nodi Proxmox.
HA del compute e HA dello storage non sono la stessa cosa.
10 o 25 Gigabit?
Con storage centralizzato la rete conta parecchio.
Una configurazione interessante potrebbe essere:
PVE01 === 25 GbE ===+
|
PVE02 === 25 GbE ===+==== TrueNAS
|
PVE03 === 25 GbE ===+
idealmente con percorsi ridondati.
Per piccoli workload anche 10 GbE può essere più che sufficiente.
Con pool NVMe moderni, invece, è molto facile arrivare al punto in cui non sono più i dischi a limitare le prestazioni ma la rete.
Un singolo link 10 GbE significa circa 1,25 GB/s teorici prima di considerare overhead di protocollo e condizioni reali.
Un pool di NVMe può superarlo senza alcuna difficoltà.
Quando si progetta questo tipo di infrastruttura bisogna quindi ragionare sul percorso completo:
applicazione
|
filesystem VM
|
virtio / SCSI
|
QEMU
|
host networking
|
switch
|
TrueNAS networking
|
zvol
|
ZFS
|
dischi
Ottimizzare soltanto uno di questi livelli difficilmente produce miracoli.
Jumbo frame?
È uno di quei temi che prima o poi emergono sempre parlando di storage network.
MTU 9000 può ridurre il numero di pacchetti necessari per trasferire grandi quantità di dati e in alcuni scenari diminuire leggermente l’overhead.
Ma c’è una regola molto più importante:
l’MTU deve essere coerente lungo tutto il percorso.
Nodo Proxmox, NIC, bridge, VLAN, switch e TrueNAS devono essere configurati correttamente.
Altrimenti quello che doveva essere un miglioramento può trasformarsi in una lunga sessione di troubleshooting.
Su hardware moderno partire con MTU 1500 non è affatto un errore.
Passerei ai jumbo frame soltanto dopo aver verificato che esiste un vantaggio reale per il workload.
API key: attenzione ai privilegi
C’è poi un aspetto che non va sottovalutato.
La API key utilizzata dal plugin può creare e cancellare risorse storage.
Non stiamo parlando di una credenziale puramente informativa.
Deve quindi essere trattata come una credenziale privilegiata.
La documentazione recente del progetto dedica infatti attenzione anche alla configurazione secondo il principio del minimo privilegio.
Personalmente eviterei account amministrativi generici e limiterei l’accesso alla rete management ai soli nodi Proxmox che devono utilizzarla.
Lo stato del progetto a settembre 2026
Qui serve un po’ di prudenza.
Il progetto sta evolvendo velocemente.
Il repository ufficiale indica attualmente la 2.1.17-deb1 come ultima release stabile, pubblicata il primo luglio 2026. Sono presenti anche release 2.1.21 e 2.1.23 in stato alpha, segno che lo sviluppo è decisamente attivo.
La documentazione principale riporta ancora in alcuni punti la versione 2.1.5, quindi bisogna prestare attenzione a distinguere la documentazione generale dallo stato effettivo delle release.
TrueNAS continua inoltre a raccomandare cautela per i workload produttivi. La documentazione ufficiale specifica che il plugin è ancora in sviluppo attivo e non completamente testato, mentre le indicazioni più recenti per TrueNAS Enterprise parlano di utilizzo Early Adopter e raccomandano una verifica progettuale prima di portarlo in produzione.
Non è soltanto una formalità.
Ad agosto 2026 risultano ancora segnalazioni aperte relative, per esempio, alla gestione NVMe/TCP, al controllo degli host NQN e a zvol che possono rimanere orfani in determinate condizioni.
Questo non significa che il plugin non sia interessante.
Significa semplicemente che bisogna sapere cosa stiamo installando.
Per un laboratorio lo proverei immediatamente.
Per un’infrastruttura che deve ospitare servizi critici farei invece test approfonditi di creazione, cancellazione, snapshot, restore, resize, migrazione, perdita di rete e recovery prima di considerarlo pronto.
Quello che mi piace davvero di questo progetto
iSCSI esiste da moltissimo tempo.
ZFS anche.
Proxmox e TrueNAS vengono utilizzati insieme da anni.
La parte innovativa non è quindi il singolo componente.
È l’orchestrazione.
Prima avevamo:
Proxmox
|
|
v
amministratore
|
|
v
TrueNAS
Adesso possiamo avere:
Proxmox
|
| API
|
v
TrueNAS
Proxmox può chiedere direttamente allo storage di creare ciò che gli serve.
Il risultato è una SAN basata su ZFS che si comporta molto più come uno storage integrato nell’hypervisor.
E questo, secondo me, è il punto centrale.
Per chi vuole costruire un cluster Proxmox mantenendo uno storage centralizzato TrueNAS, il plugin elimina buona parte di quella gestione manuale che ha sempre reso iSCSI potente ma piuttosto macchinoso.
Non sostituisce Ceph.
Non sostituisce NFS.
E probabilmente non vuole farlo.
Apre semplicemente una terza strada:
storage centralizzato
block level
ZFS aware
orchestrato da Proxmox
Una combinazione che, soprattutto con Proxmox VE 9 e NVMe/TCP, vale decisamente la pena tenere d’occhio.
Le opinioni in quanto tali sono opinabili e nulla ti vieta di approfondire l’argomento.
Risorse: