Synology VDSM: Spostamento di Docker con intelligenza artificiale e ridimensionamento di un disco virtuale (2026)

Un NAS virtuale è una di quelle funzionalità che le persone installano una volta, smanettano per un pomeriggio e poi si dimenticano di possedere. È un peccato, perché Synology VDSM — Virtual DSM, eseguito all'interno di Virtual Machine Manager — risolve silenziosamente due dei problemi più fastidiosi dell'hosting self-service su piccola scala. Il primo è che spostare uno stack Docker tra macchine di solito richiede una serata di lavoro minuzioso. Il secondo è che quando un disco virtuale si esaurisce, la maggior parte delle persone presume di doverlo ricostruire completamente. Nessuna di queste due cose è vera con VDSM. Questa guida descrive una migrazione reale che abbiamo eseguito in circa trentacinque minuti: un sistema interno di tracciamento dei problemi Redmine con cinque plugin, estratto da una macchina virtuale VDSM e inserito in un'altra, con un assistente IA a gestire la shell. Durante il processo, la destinazione ha esaurito lo spazio su disco, quindi abbiamo aumentato il suo disco virtuale da 10 GB a 20 GB e abbiamo continuato. Tutto ciò che segue è ciò che è realmente accaduto, inclusa l'unica insidia che avrebbe silenziosamente bloccato l'applicazione.

Punto SynoPower Club:Ho visto molte persone rinunciare alla virtualizzazione su un NAS perché pensano che sia adatta solo ai laboratori e non al lavoro reale. La migrazione descritta in questo articolo è stata un'esperienza reale: un sistema di ticket utilizzato quotidianamente da tre colleghi. La cosa che mi ha sorpreso non è stata l'intelligenza artificiale, bensì la semplicità di VDSM. Nessun hypervisor da attivare, nessun server di gestione separato, nessuna complicata operazione di importazione/esportazione tra formati incompatibili. La macchina virtuale ha esaurito lo spazio su disco a metà dell'operazione e ho risolto il problema inserendo un numero più grande in un campo di testo mentre era ancora in esecuzione. L'intera operazione ha richiesto trentacinque minuti e l'unico disservizio notato è stato di novanta secondi su un sito web non correlato. Se possedete già un NAS Synology con memoria disponibile, vi basterà installare un pacchetto per ottenere lo stesso risultato.

Che cos'è il Synology VDSM?

VDSM è l'equivalente di Virtual DSM per Synology: una copia completa di DiskStation Manager in esecuzione come sistema operativo guest all'interno di Virtual Machine Manager su un NAS fisico. Si comporta come un NAS separato: ha un proprio indirizzo IP, un proprio login DSM, i propri pacchetti e il proprio Container Manager. Dal punto di vista della rete, è semplicemente un altro Synology sulla LAN. Dal punto di vista hardware, è un processo in più su un dispositivo che avete già acquistato.

Il vantaggio pratico è l'isolamento. Eseguire ogni servizio direttamente sull'host può causare il blocco del file server da cui dipende l'intero ufficio. Suddividere i carichi di lavoro tra le macchine virtuali VDSM assegna a ciascuna un limite di memoria, un'allocazione di CPU e un disco dedicati, consentendo di riavviarne una senza intaccare le altre.

Ogni NAS che supporta Virtual Machine Manager include una licenza VDSM gratuita. L'esecuzione di una seconda e successiva macchina virtuale richiede una licenza Virtual DSM a pagamento ciascuno. Quella singola istanza gratuita è sufficiente per seguire tutto in questo articolo, ed è per questo che così tante persone possiedono già la funzionalità e non l'hanno mai attivata. Se in seguito devi aggiungere, mappare o rimuovere una licenza, abbiamo una guida su gestione delle licenze VDSM.

VDSM e Virtual DSM sono due nomi per la stessa cosa. La documentazione ufficiale di Synology utilizza la forma estesa, mentre la maggior parte degli utenti usa quella abbreviata. L'abbreviazione è condivisa anche con un componente non correlato del progetto di virtualizzazione oVirt, quindi su un NAS Synology significa sempre Virtual DSM.

Una licenza a pagamento funziona in modo diverso da quanto la maggior parte delle persone si aspetta. Ogni licenza aggiunge un'altra macchina virtuale e include tre anni di aggiornamenti software per Virtual DSM. La macchina virtuale non scade mai. Dopo tre anni continua a funzionare senza nuovi aggiornamenti. L'attivazione di una nuova chiave avvia altri tre anni di aggiornamenti. Una chiave è attiva su un solo NAS Synology alla volta e il NAS deve essere online al momento dell'aggiunta.

I requisiti per un ospite VDSM sono modesti e Synology li elenca nel suo Specifiche Virtual Machine Manager:

• Il disco virtuale deve risiedere su un volume Btrfs. Virtual Machine Manager non memorizza le macchine virtuali su ext4.
• Il NAS stesso necessita di più di 2 GB di memoria prima di poter eseguire qualsiasi macchina virtuale.
• Ogni macchina virtuale necessita di almeno 1 GB di memoria dedicata, e i carichi di lavoro reali ne richiedono di più.
• Il numero di ospiti che un modello può gestire comodamente dipende dalla sua CPU e dalla memoria installata.

Un guest non è identico a DSM su hardware fisico. Mancano tre elementi, tutti legati all'hardware fisico:

• La funzione di passthrough USB non è disponibile, pertanto un dispositivo collegato a una porta USB del NAS non può essere passato all'ospite.
• Le pagine Dispositivi esterni e Hardware e alimentazione del Pannello di controllo non sono presenti.
• Le chiavette wireless, le impostazioni MTU e l'aggregazione di link (LACP) non sono supportate all'interno della macchina virtuale guest. La rete fisica è gestita dall'host.

Nessuno di questi aspetti influisce sui motivi usuali per utilizzarne uno. Servizi di file, Docker, un server di posta o una copia di staging di un sistema di produzione si comportano tutti come su un NAS separato.

Synology VDSM o un secondo NAS fisico: quale ti serve?

Il confronto onesto non sta nel dire che la virtualizzazione sia migliore. Si tratta di un compromesso tra resilienza e flessibilità. Un secondo server fisico sopravvive al guasto del primo; una macchina virtuale VDSM no. Ciò che una macchina virtuale offre, invece, è la possibilità di creare, ridimensionare, creare snapshot e spostare un intero server in pochi minuti anziché in giorni.

	ospite VDSM	Secondo NAS fisico
Costo per aggiungerne uno	Gratuito per il primo ospite, licenza per i successivi.	Un intero NAS più dischi
Tempo di fornitura	Minuti	Giorni, una volta conteggiate le spese di spedizione
Ridimensiona CPU, RAM o disco	Modifica un campo, riavvia l'ospite	Acquista nuovo hardware
Sopravvive al guasto dell'hardware host	NO	SÌ
Istantanea e clone	Integrato in Virtual Machine Manager	Non applicabile
Spostarsi su un altro NAS	Migrare o replicare l'ospite	Spostarlo fisicamente
Ideale per	Isolamento dei servizi, staging, consolidamento di piccoli server	Obiettivi di backup e ridondanza reale

Per questo lavoro la scelta era ovvia. Dovevamo consolidare un sistema di tracciamento dei problemi poco utilizzato, a cui era stata assegnata un'intera macchina virtuale VDSM dedicata, su una macchina virtuale che già ospitava un sito web e disponeva di capacità inutilizzata. Non c'è bisogno di nuovo hardware. Bastano dieci minuti e un po' di attenzione.

Cosa ti serve prima di iniziare

Prima di tutto, assegna all'assistente un login personale invece di dargli il tuo. In DSM apri Pannello di controllo, vai a Utenti e gruppi e fai clic su Crea. Assegna un nome inconfondibile: noi abbiamo usato Claude con la descrizione controllo tramite IA — e lascia che DSM generi una password forte e casuale.

Nella schermata successiva, spuntare amministratori. Questo passaggio non è facoltativo: DSM consente l'accesso tramite SSH solo ai membri del gruppo Administrators, pertanto un account esterno a tale gruppo non può accedere alla shell. Eseguire la stessa procedura su entrambe le macchine virtuali VDSM, quindi assicurarsi che SSH sia abilitato in Pannello di controllo, Terminale e SNMP.

Al termine del lavoro, disattiva l'account. Questo è proprio il punto fondamentale della creazione di un account separato. Modifica l'utente nel Pannello di controllo e disattivalo, oppure eliminalo completamente; l'accesso viene revocato con un solo clic senza dover toccare le tue credenziali, e tutto ciò che l'assistente ha fatto rimane attribuibile a un account di accesso creato appositamente per quello scopo. Lasciare un account amministratore permanentemente attivo solo perché una volta era comodo è il modo in cui le piccole aziende accumulano accessi che nessuno ricorda di aver concesso.

Due macchine virtuali VDSM, con SSH abilitato su entrambe e Container Manager installato sulla destinazione. È importante anche sapere una cosa che coglie di sorpresa quasi tutti la prima volta: il binario di Docker non si trova nel PATH predefinito all'interno di DSM. I binari dei pacchetti risiedono nella directory dei pacchetti, quindi ogni comando richiede il percorso completo o un alias di shell.

Verificate che la destinazione abbia disponibilità prima di iniziare il trasferimento, anziché a metà. I comandi seguenti costituiscono l'intera procedura di controllo pre-volo e sono identici su qualsiasi guest VDSM.

Un'ultima cosa prima di tutto: scatta una foto di entrambi gli ospiti in Virtual Machine Manager. Gli snapshot sono inclusi nella versione gratuita di Virtual Machine Manager, non solo nella versione Pro, e ne vengono conservati fino a 32 per ogni macchina virtuale. Uno snapshot VDSM cattura l'intera macchina, quindi se un'importazione va storta o un comando fa qualcosa di indesiderato, è possibile ripristinare la macchina virtuale anziché ricostruirla. L'operazione richiede pochi secondi ed è la forma di sicurezza più economica dell'intero processo. È consigliabile eseguirne uno sia sull'origine che sulla destinazione, poiché l'origine rappresenta il backup di sicurezza.

# Docker non è nel PATH in DSM - usa il percorso completo D=/volume1/@appstore/ContainerManager/usr/bin/docker # Cosa è in esecuzione e da cosa è stato compilato? sudo $D ps -a sudo $D images # Quanto spazio è rimasto sul volume di destinazione? df -h /volume1 # Quanta memoria ha effettivamente libero il guest di destinazione? free -m

Migrazione di VDSM a Docker in 4 passaggi

Questi sono i quattro passaggi che abbiamo eseguito, e funzionano per qualsiasi stack di container che si debba spostare tra guest VDSM. L'ordine è importante: il container dell'applicazione viene arrestato per primo in modo che nulla scriva nel database durante il dump, e il container del database rimane attivo in modo che possa essere sottoposto a dump in modo pulito.

Perché il file Compose non è l'intero contenitore

Ecco la trappola, e da sola vale il prezzo del biglietto. Il file compose per il nostro stack Redmine dichiarava due mount di bind: uno per i file caricati e uno per il database. Leggendo quel file, si potrebbe ragionevolmente concludere che ricreare lo stack sulla nuova macchina virtuale significava copiare due directory ed eseguire docker compose up.

Non è andata così. Cinque plugin, le gemme Ruby che questi plugin includevano, la configurazione della posta elettronica e diversi file di inizializzazione modificati erano stati installati direttamente nel container in esecuzione nel corso degli anni. Nessuno di questi si trovava in un volume. Un semplice comando ci ha fatto capire quanto fosse grave la situazione.

# Quanti file differiscono tra il container e l'immagine da cui proviene? sudo $D diff Redmine | wc -l 6764 # Plugin presenti all'interno del container, non supportati da alcun volume sudo $D exec Redmine ls /usr/src/redmine/plugins

Scaricare un'immagine ufficiale pulita avrebbe prodotto un container senza nessuno di quei plugin, puntato a un database che conteneva ancora le 144 tabelle create dalle migrazioni. L'applicazione non si sarebbe bloccata in modo anomalo. Si sarebbe avviata, avrebbe funzionato quasi correttamente e poi si sarebbe bloccata in modi estremamente difficili da diagnosticare. Eseguire il commit del container in esecuzione su un'immagine aggira completamente il problema, a costo di un trasferimento più lungo. Su una LAN tra due macchine virtuali VDSM, questo costo si aggira intorno a un minuto, quindi conviene sempre accettare il compromesso.

Come un piccolo team utilizza VDSM per consolidare i server

Il modello che segue questa migrazione è quello di cui la maggior parte dei piccoli team alla fine ha bisogno. Nel corso di alcuni anni si accumulano guest monouso: uno per il wiki, uno per il sistema di tracciamento dei ticket, uno per una dashboard di monitoraggio (la forma descritta nel nostro Guida passo passo al data center domesticoCiascuno di essi è stato dimensionato generosamente il giorno in cui è stato costruito e ora ognuno funziona a una frazione di ciò che gli è stato assegnato, mentre l'host è sovraccarico e tutto sembra leggermente lento.

Consolidare con VDSM significa integrare i carichi di lavoro inattivi in una macchina virtuale già attiva. Il nostro sistema di gestione dei ticket aveva una macchina virtuale dedicata con una propria allocazione di CPU e 1 GB di memoria, per un servizio utilizzato da tre persone poche volte al giorno. Spostandolo accanto a uno stack web esistente, tale allocazione è stata completamente liberata, con un costo di circa 480 MB di memoria residente distribuita su due container.

La disciplina che rende questa operazione sicura consiste nel dismettere correttamente la sorgente anziché lasciarla in esecuzione. Abbiamo impostato i vecchi container su una policy di riavvio "no", li abbiamo arrestati, abbiamo lasciato un file di testo nella directory che spiega dove risiede ora il servizio e abbiamo spento la macchina virtuale con l'avvio automatico disabilitato. Rimane un punto di ripristino completo e non può riattivarsi silenziosamente dopo un riavvio dell'host e iniziare ad accettare scritture che la nuova istanza non vedrà mai. I duplicati divergenti sono il classico caso in cui una migrazione ordinata si trasforma in un incidente di perdita di dati un mese dopo.

Ridimensionamento di un disco virtuale che ha esaurito lo spazio disponibile

A metà dell'operazione, lo spazio di destinazione si è esaurito. Il volume era di 9,6 GB con 1,5 GB liberi e stavamo per aggiungere un'immagine da 816 MB più 123 MB di dati dell'applicazione. Su un NAS fisico, la procedura si interrompe qui fino all'arrivo di nuove unità. Su VDSM, invece, viene visualizzato un campo di testo.

Apri le impostazioni dell'ospite in Virtual Machine Manager, vai alla scheda Archiviazione, digita la nuova dimensione e fai clic su OK. Non è necessario spegnere l'ospite per questo. Il disco si espande mentre la macchina continua a funzionare, ed è per questo che si tratta di un'esperienza fondamentalmente diversa rispetto all'aggiunta di capacità a un hardware fisico. L'unica regola importante da ricordare è che un disco virtuale può solo espandersi, mai ridursi, quindi non è possibile annullare l'operazione e non c'è motivo di essere titubanti riguardo al numero.

Ciò che rende il processo davvero indolore è quello che accade all'interno della macchina virtuale. DSM espande automaticamente la partizione e il filesystem per riempire il nuovo spazio. Non è necessario eseguire alcuna procedura guidata di Storage Manager, né modificare la tabella delle partizioni, né ricostruire il volume, né migrare i dati. Il nostro volume è passato da 9,6 GB con 1,5 GB liberi a 20 GB con 13 GB liberi, e i container hanno continuato a funzionare. Questo è il principale argomento a favore dell'installazione di un servizio su VDSM piuttosto che su hardware fisico: un dimensionamento errato è facilmente correggibile in seguito con un budget limitato.

Cosa ha fatto realmente l'assistente IA

È opportuno essere precisi, perché l'affermazione "l'IA ha spostato il mio server" suscita allo stesso tempo troppa e troppo poca credulità. L'assistente non aveva alcuna intuizione magica. Aveva accesso a entrambi gli ospiti VDSM ed era sistematico in un modo che un essere umano stanco alla fine di una giornata di lavoro di solito non è.

La cosa più utile che ha fatto è stata eseguire `docker diff` prima di toccare qualsiasi cosa, notare 6.764 file modificati e rifiutare la soluzione più ovvia. Chiunque avesse seguito il file compose non avrebbe avuto motivo di eseguire quel comando. La seconda cosa più utile è stata la verifica: dopo l'importazione ha contato tabelle, problemi, progetti, voci di registro e allegati su entrambi i lati, ha controllato che ogni file allegato esistesse sul disco, ha elencato le versioni dei plugin registrate dall'applicazione e ha confermato che non c'erano migrazioni di database in sospeso. Si tratta di una lista di controllo noiosa, e le liste di controllo noiose sono proprio ciò che viene saltato alle cinque del pomeriggio.

Ciò che ancora mancava all'intervento umano era la capacità di valutare le conseguenze. Riavviare una macchina virtuale VDSM per liberare memoria significava mandare offline un sito web attivo, e questa è una decisione che va ponderata attentamente, non data per scontata. Lo stesso vale per la cancellazione di qualsiasi elemento. Considerate l'assistente come un paio di mani velocissime e precise, che non si stancano mai di controllare, e tenete per voi le decisioni irreversibili.

Dove trovare ulteriori risorse ufficiali

Virtual Machine Manager, il pacchetto che ospita ogni macchina virtuale VDSM, è presente in DSM da anni ed è ben documentato. Queste tre guide illustrano l'installazione del pacchetto, la creazione di una macchina virtuale e la struttura generale dell'interfaccia con cui lavorerete.

Limiti da conoscere prima di affidare la produzione a VDSM

Innanzitutto, la memoria rappresenta il fattore limitante molto più spesso della CPU. La nostra macchina virtuale di destinazione aveva 2 GB di RAM e utilizzava già lo swap prima ancora che aggiungessimo altro. Una seconda applicazione e un secondo database richiedevano circa altri 480 MB, quindi abbiamo aumentato la memoria a 4 GB. Verificate la memoria libera sulla destinazione prima di pianificare la migrazione, non dopo.

In secondo luogo, un disco virtuale VDSM si espande ma non si riduce mai. Se si effettua un over-allocation, non è possibile recuperare lo spazio modificando il campo per riportarlo a una dimensione inferiore; l'unica soluzione per ridurre le dimensioni del disco è creare una nuova macchina virtuale e migrare su di essa. Scegliete una dimensione di cui sarete ancora soddisfatti tra due anni.

Terzo, la licenza. Un ospite è incluso con il NAS; ogni ospite aggiuntivo necessita di una propria licenza. Licenza Virtual DSM. Il clustering su più unità NAS, la migrazione live e la conservazione di snapshot più ampia sono VMM Pro caratteristiche specifiche piuttosto che standard. Se il tuo piano di consolidamento prevede di suddividere un unico ospite affollato in quattro ospiti più ordinati, calcola il prezzo prima di progettarlo.

Valutare correttamente le dimensioni di un ospite è un compito a sé stante: Come dimensionare correttamente una VM di produzione con VMM Pro.

Quarto, gli scenari da evitare. Non posizionare il disco virtuale di una macchina virtuale sullo stesso volume fisico su cui si esegue il backup e considerarlo tale. Non eseguire un database con un elevato volume di scritture continue su una macchina virtuale che condivide dischi rigidi con un file server molto occupato. Non considerare VDSM come un sostituto di una seconda macchina, perché se l'host si guasta, tutte le macchine virtuali su di esso si guastano contemporaneamente. E non migrare un container che non hai mai ispezionato, per i motivi indicati nella sezione relativa al file di composizione.

Quinto, le credenziali. Una migrazione coinvolge password del database, variabili d'ambiente e file di configurazione. Nel nostro caso, è stato spostato un file compose contenente le credenziali del database in chiaro, posizionandolo deliberatamente al di fuori della directory principale del server web. Un file compose lasciato all'interno della directory principale può essere scaricato da chiunque ne indovini il nome, e questo è un modo purtroppo comune di fuga di credenziali. Se si affida la migrazione a un assistente tramite script, è importante controllare dove vengono scritti i file. E al termine dell'operazione, è consigliabile disabilitare l'account creato per l'assistente anziché lasciare attivo un account amministratore.

Sesto, create uno snapshot prima di toccare qualsiasi cosa. Uno snapshot VDSM in Virtual Machine Manager richiede pochi secondi, è disponibile anche senza licenza Pro e trasforma quasi ogni errore descritto in questo articolo in un rollback di due minuti. È il passaggio che vale la pena aggiungere a qualsiasi runbook di migrazione, indipendentemente dal fatto che a scriverlo sia una persona o un assistente.

Infine, verificate anziché presumere. Ogni affermazione contenuta in questo articolo è stata verificata sul sistema in esecuzione: conteggio delle tabelle su entrambi i lati, presenza di file allegati su disco, versioni dei plugin registrate dall'applicazione, assenza di migrazioni in sospeso e un riavvio completo dello stack per dimostrare che si riavvia autonomamente. Una migrazione non è terminata quando il servizio risponde. È terminata quando si è dimostrato che sopravvive a un riavvio della macchina virtuale VDSM e quando la vecchia copia non è più in grado di accettare operazioni di scrittura.

Una nota su dove ottenere queste licenze, visto che è quello che facciamo: SynoPower Club vende licenze Synology con consegna istantanea della chiave 24 ore su 24. Le due che contano qui sono le Licenza Virtual DSM, di cui hai bisogno per ogni ospite oltre a quello gratuito, e il Licenza VMM Pro se desideri il clustering, la migrazione live o 255 snapshot per guest invece di 32. Il catalogo completo delle licenze Copre anche i modelli Surveillance Station e MailPlus.

Riferimenti

• SynoPower Club, le nostre guide al NAS Synology e le recensioni delle telecamere
• Synology — Virtual Machine Manager, la panoramica ufficiale del pacchetto che esegue VDSM
• Centro informazioni Synology — Assistenza Virtual Machine Manager, creazione e impostazioni degli ospiti
• Docker — commit del container Docker, il comando dietro il primo passo
• Docker — salvataggio dell'immagine Docker, utilizzato per trasmettere l'immagine tra gli ospiti

Domande frequenti