Synology VDSM: Flytta Docker med AI och ändra storlek på en virtuell disk (2026)

En virtuell NAS är en av de funktioner som folk installerar en gång, kikar på en eftermiddag och sedan glömmer att de äger. Det är synd, eftersom Synology VDSM — Virtual DSM, körs inuti Virtual Machine Manager — löser tyst två av de mest irriterande problemen med småskalig självhosting. Det första är att det normalt kostar en kväll med krångligt arbete att flytta en Docker-stack mellan maskiner. Det andra är att när en virtuell disk får slut på utrymme antar de flesta att de måste bygga om hela saken. Ingetdera gäller för VDSM. Den här guiden går igenom en riktig migrering som vi körde på cirka trettiofem minuter: en intern Redmine-problemspårare med fem plugins, lyfta från en VDSM-gäst och placerade i en annan, med en AI-assistent som körde skalet. Längs vägen fick destinationen slut på disk, så vi utökade dess virtuella disk från 10 GB till 20 GB och fortsatte. Allt nedan är vad som faktiskt hände, inklusive den enda fällan som i tysthet skulle ha förstört applikationen.

SynoPower Club-punkt:Jag har sett många människor övertala sig själva att inte virtualisera på en NAS eftersom de antar att det är för labb och inte för riktigt arbete. Migreringen i den här artikeln var riktigt arbete – ett ärendesystem som tre kollegor använder varje dag – och det som förvånade mig var inte AI:n. Det var hur lite ceremoniellt VDSM behöver. Ingen hypervisor att licensiera, ingen separat hanteringsserver, ingen export-import-dans mellan inkompatibla format. Gästdisken fick slut på disk mitt i jobbet och jag fixade det genom att skriva in ett större nummer i ett textfält medan det fortfarande kördes. Hela jobbet tog trettiofem minuter och det enda avbrottet någon märkte var nittio sekunder på en orelaterad webbplats. Om du redan äger en Synology med reservminne är du en paketinstallation ifrån detta.

Vad är Synology VDSM?

VDSM är Synology:s Virtual DSM: en komplett kopia av DiskStation Manager som körs som ett gästoperativsystem inuti Virtual Machine Manager på en fysisk NAS. Den beter sig som en separat NAS. Sin egen IP-adress, sin egen DSM-inloggning, sina egna paket, sin egen Container Manager. Ur nätverkets synvinkel finns det helt enkelt ytterligare en Synology på LAN:et. Ur hårdvarans synvinkel är det ytterligare en process på en låda du redan har betalat för.

Det praktiska är isoleringen. Kör varje tjänst direkt på värden och en enda dåligt uppförd container kan svälta ut filservern som hela kontoret är beroende av. Att dela upp arbetsbelastningar över VDSM-gäster ger var och en ett minnestak, en CPU-allokering och en egen disk, och låter dig starta om en utan att röra de andra.

Varje NAS som stöder Virtual Machine Manager inkluderar en VDSM-licens utan kostnad. Att köra en andra och efterföljande gästlicens kräver en betald Virtual DSM-licens varje. Den enda gratisinstansen räcker för att följa allt i den här artikeln, och det är därför så många redan äger funktionen och aldrig har aktiverat den. Om du behöver lägga till, mappa eller avmappa en licens senare har vi en genomgång på hantera VDSM-licenser.

VDSM och Virtual DSM är två namn för samma sak. Synology:s egen dokumentation använder den långa formen, och de flesta ägare använder den korta. Förkortningen delas också med en orelaterad komponent i virtualiseringsprojektet oVirt, så på en Synology NAS betyder det alltid Virtual DSM.

En betald licens fungerar annorlunda än vad de flesta förväntar sig. Varje licens lägger till ytterligare en gäst och inkluderar tre års Virtual DSM-programuppgraderingar. Den virtuella maskinen upphör aldrig att gälla. Efter de tre åren fortsätter den att köras utan nya uppdateringar. Aktivering av en ny nyckel startar ytterligare tre år med uppdateringar. En nyckel är aktiv på en Synology NAS åt gången, och NAS:en måste vara online när du lägger till den.

Kraven för en VDSM-gäst är blygsamma, och Synology listar dem i sin Virtual Machine Manager-specifikationer:

• Den virtuella disken måste finnas på en Btrfs-volym. Virtual Machine Manager lagrar inte gäster på ext4.
• Själva NAS-enheten behöver mer än 2 GB minne innan den kan köra någon virtuell maskin.
• Varje gäst behöver minst 1 GB minne för sig själv, och verkliga arbetsbelastningar behöver mer.
• Hur många gäster en modell kan köra bekvämt beror på dess processor och installerade minne.

En gäst är inte identisk med DSM på bare metal. Tre saker saknas, alla kopplade till fysisk hårdvara:

• USB-genomströmning är inte tillgänglig, så en enhet som är ansluten till en USB-port på NAS-enheten kan inte överlämnas till gästen.
• Sidorna Externa enheter och Maskinvara och strömförsörjning i Kontrollpanelen finns inte där.
• Trådlösa donglar, MTU-inställningar och länkaggregering (LACP) stöds inte i gästnätverket. Värden hanterar det fysiska nätverket.

Inget av det påverkar de vanliga anledningarna att köra en. Filtjänster, Docker, en e-postserver eller en mellanliggande kopia av ett produktionssystem beter sig alla som de skulle göra på en separat NAS.

Synology VDSM vs en andra fysisk NAS: Vilken behöver du?

Den ärliga jämförelsen är inte att virtuellt är bättre. Det är ett byte av motståndskraft mot flexibilitet. En andra fysisk box överlever den förstas misslyckande; det gör inte en VDSM-gäst. Vad en gäst istället köper dig är möjligheten att skapa, ändra storlek, ta ögonblicksbilder och flytta en hel server på minuter snarare än dagar.

	VDSM-gäst	Andra fysiska NAS-enheten
Kostnad för att lägga till en	Gratis för första gästen, licens därefter	En hel NAS plus hårddiskar
Dags att tillhandahålla	Minuter	Dagar, när frakten har räknats
Ändra storlek på processor, RAM eller disk	Redigera ett fält, starta om gästen	Köp ny hårdvara
Överlever hårdvarufel på värddatorn	Inga	Ja
Ögonblicksbild och klon	Inbyggd i Virtual Machine Manager	Ej tillämpligt
Flytta till en annan NAS	Migrera eller replikera gästen	Flytta den fysiskt
Bäst för	Isolera tjänster, staging, konsolidera små servrar	Backupmål och verklig redundans

För det här jobbet var valet självklart. Vi konsoliderade en lätt använd problemspårare som hade fått en helt egen VDSM-gäst till en gäst som redan körde en webbplats med reservkapacitet. Ingenting med det kräver ny hårdvara. Det kräver tio minuter och lite skötsel.

Vad du behöver innan du börjar

Ge assistenten en egen inloggning före allt annat istället för att lämna över din. I DSM öppnar du Kontrollpanelen, går till Användare och grupp och klickar på Skapa. Döp den till något omisskännligt – vi använde Claude med beskrivningen AI-kontroll — och låt DSM generera ett starkt slumpmässigt lösenord.

På nästa skärm, markera administratörer. Detta är inte valfritt: DSM tillåter endast medlemmar i gruppen administratörer att logga in via SSH, så ett konto utanför den gruppen kan inte nå gränssnittet alls. Gör samma sak på båda VDSM-gästerna och se sedan till att SSH är aktiverat under Kontrollpanelen, Terminal och SNMP.

När arbetet är klart, inaktivera kontot. Det är hela poängen med att skapa en separat. Redigera användaren i Kontrollpanelen och stäng av den, eller radera den helt; åtkomsten återkallas med ett klick utan att du behöver röra dina egna inloggningsuppgifter, och allt assistenten gjorde förblir hänförligt till en inloggning som finns för just det ändamålet. Att låta ett permanent aktiverat administratörskonto ligga och gömma sig för att det var bekvämt en gång i tiden är så små fastigheter samlar på sig åtkomst som ingen minns att de beviljat.

Två VDSM-gäster, SSH aktiverat på båda och Container Manager installerad på destinationen. Du behöver också veta en sak som nästan alla märker första gången: Docker-binärfilen finns inte på standardsökvägen i DSM. Paketbinärfiler finns under paketkatalogen, så varje kommando behöver hela sökvägen eller ett skalalias.

Kontrollera att destinationen har plats innan du börjar snarare än halvvägs genom en transfer. Kommandona nedan är hela kontrollen före flygning, och de är identiska för alla VDSM-gäster.

En sak till innan allting av det: ta en ögonblicksbild av båda gästerna i Virtual Machine Manager. Snapshots finns i gratisversionen av Virtual Machine Manager, inte bara Pro, och den kommer att behålla upp till 32 av dem per gäst. En VDSM-snapshot fångar hela maskinen, så om en import går fel eller ett kommando gör något du inte avsåg, kan du rulla tillbaka gästen istället för att bygga om den. Det kostar några sekunder och det är den enskilt billigaste försäkringen i hela processen. Ta en på både källkoden och destinationen, eftersom källkoden är din reserv.

# Docker finns inte på PATH i DSM - använd den fullständiga sökvägen D=/volume1/@appstore/ContainerManager/usr/bin/docker # Vad körs, och vad är det byggt av? sudo $D ps -a sudo $D images # Hur mycket utrymme finns kvar på destinationsvolymen? df -h /volume1 # Hur mycket minne har destinationsgästen faktiskt ledigt? free -m

VDSM Docker-migrering i 4 steg

Det här är de fyra stegen vi körde, och de fungerar för alla containerstackar som du behöver lyfta mellan VDSM-gäster. Ordningen spelar roll: applikationscontainern stoppas först så att ingenting skriver till databasen mitt i dumpningen, och databascontainern stannar uppe så att den kan dumpas utan problem.

Varför Compose-filen inte är hela behållaren

Här är fällan, och den är värd inträdespriset i sig. Compose-filen för vår Redmine-stack deklarerade två bindningsmonteringar: en för uppladdade filer, en för databasen. Läs den filen och du skulle rimligen kunna dra slutsatsen att återskapandet av stacken på den nya gästen innebar att kopiera två kataloger och köra docker compose.

Det gjorde det inte. Fem plugin-program, Ruby-juvelerna som de plugin-program hämtade, e-postkonfigurationen och flera redigerade initialiseringsfiler hade alla installerats direkt i containern som kördes under årens lopp. Inget av det fanns på en volym. Ett kommando visade oss hur illa det var.

# Hur många filer skiljer sig mellan containern och bilden den kommer ifrån? sudo $D diff Redmine | wc -l 6764 # Plugins som finns inuti containern, utan någon volym alls sudo $D exec Redmine ls /usr/src/redmine/plugins

Att hämta en ny officiell avbildning skulle ha producerat en container utan några av dessa plugins, pekande mot en databas som fortfarande innehöll de 144 tabellerna som skapades genom deras migreringar. Applikationen skulle inte ha misslyckats på ett högljutt sätt. Den skulle ha startat, sett nästan korrekt ut och sedan slutat fungera på sätt som är hemska att diagnostisera. Att koppla den körande containern till en avbildning kringgår problemet helt, till kostnaden för en större överföring. På ett LAN mellan två VDSM-gäster är den kostnaden ungefär en minut, så byt ut den varje gång.

Hur ett litet team använder VDSM för att konsolidera servrar

Mönstret som denna migrering följer är ett som de flesta små team så småningom behöver. Under några år samlar ni gäster med ett enda syfte: en för wikin, en för ärendespåraren, en för en övervakningspanel (formen som beskrivs i vår genomgång av hemdatacenter). Varje enhet var generöst dimensionerad den dagen den byggdes och var och en går nu på tomgång till en bråkdel av vad den fick, medan värden är överengaserad och allt känns lite långsamt.

Att konsolidera med VDSM innebär att lägga de tysta arbetsbelastningarna i en gäst som redan är aktiv. Vår ärendespårare hade en hel gäst med sin egen CPU-allokering och 1 GB minne, för en tjänst som tre personer berör några gånger om dagen. Att flytta den bredvid en befintlig webbstack frigjorde den allokeringen helt och kostade destinationen cirka 480 MB resident minne fördelat på två containrar.

Disciplinen som gör detta säkert är att pensionera källkoden korrekt istället för att låta den vara igång. Vi ställde in de gamla containrarna till en omstartspolicy på nej, stoppade dem, lämnade en textfil i katalogen som förklarade var tjänsten nu finns och stängde av gästtjänsten med automatisk start inaktiverad. Den förblir en fullständig återställningspunkt och kan inte tyst återupplivas efter en omstart av värden och börja acceptera skrivningar som den nya instansen aldrig kommer att se. Divergerande dubbletter är det klassiska sättet en snygg migrering blir en dataförlustincident en månad senare.

Ändra storlek på en virtuell disk som fick slut på utrymme

Halvvägs fick destinationen slut på utrymme. Dess volym var 9,6 GB med 1,5 GB ledigt och vi skulle just lägga till en 816 MB avbildning plus 123 MB programdata. På en fysisk NAS är det här historien slutar tills nya hårddiskar anländer. På VDSM är det ett textfält.

Öppna gästinställningarna i Virtual Machine Manager, gå till fliken Lagring, skriv in den nya storleken och klicka på OK. Gästen behöver inte stängas av för detta. Disken växer medan maskinen fortsätter att köras, vilket är anledningen till att detta är en fundamentalt annorlunda upplevelse än att lägga till kapacitet till bar hårdvara. Den enda regeln som är värd att känna till är att en virtuell disk bara kan växa, aldrig krympa, så det finns ingen möjlighet att ångra och ingen anledning att vara blyg över antalet.

Det som gör det verkligt smärtfritt är vad som händer inuti gästen. DSM expanderar partitionen och filsystemet för att fylla det nya utrymmet på egen hand. Det finns ingen Storage Manager-guide att köra, ingen partitionstabell att redigera, ingen volym att bygga om och ingen data att migrera. Vår volym gick från 9,6 GB med 1,5 GB ledigt till 20 GB med 13 GB ledigt, och containrarna fortsatte. Detta är det enskilt starkaste argumentet för att lägga en tjänst på VDSM snarare än på bar hårdvara: att få fel storlek är billigt att fixa senare.

Vad AI-assistenten faktiskt gjorde

Det är värt att vara precis här, eftersom "AI flyttade min server" inbjuder till både för mycket och för lite godtrogenhet. Assistenten hade ingen magisk insikt. Den hade ett skal på båda VDSM-gästerna och den var systematisk på ett sätt som en trött människa i slutet av en arbetsdag vanligtvis inte är.

Det absolut mest värdefulla den gjorde var att köra docker diff innan den rörde något, lägga märke till 6 764 ändrade filer och vägra den uppenbara planen. Någon som följde compose-filen skulle inte ha haft någon anledning att köra det kommandot. Det näst mest värdefulla var verifiering: efter importen räknade den tabeller, ärenden, projekt, journalposter och bilagor på båda sidor, kontrollerade att varje bilaga fanns på disken, listade de plugin-versioner som applikationen hade registrerat och bekräftade att det inte fanns några väntande databasmigreringar. Det är en tråkig checklista, och tråkiga checklistor är precis vad som hoppas över klockan fem på eftermiddagen.

Vad som fortfarande behövdes från en människa var ett omdöme om konsekvenserna. Att starta om en VDSM-gäst för att lägga till minne innebar att man tog ner en aktiv webbplats, och det är ett beslut som man bör fråga om snarare än att anta. Detsamma gäller för att ta bort vad som helst. Behandla assistenten som ett mycket snabbt, mycket bokstavligt par händer som aldrig blir uttråkad av att kontrollera, och behåll de oåterkalleliga samtalen för dig själv.

Var man hittar fler officiella resurser

Virtual Machine Manager, paketet som värdar varje VDSM-gäst, har funnits i DSM i flera år och är väl täckt. Dessa tre genomgångar täcker installation av paketet, skapande av en gäst och den allmänna formen av gränssnittet du kommer att arbeta i.

Begränsningar att känna till innan du anförtror VDSM produktionen

För det första är minne bindningsbegränsningen mycket oftare än processorn. Vår destinationsgäst hade 2 GB och var redan inne på swap innan vi lade till något. En andra applikation plus en andra databas behövde ytterligare ungefär 480 MB, så vi höjde det till 4 GB. Kontrollera ledigt minne på destinationen innan du planerar flytten, inte efteråt.

För det andra växer en virtuell VDSM-disk men krymper aldrig. Överprovisionering och du kan inte frigöra utrymmet genom att redigera fältet igen; den enda vägen till en mindre disk är att bygga en ny gäst och migrera till den. Välj ett antal som du fortfarande är nöjd med om två år.

För det tredje, licensiering. En gäst ingår i NAS-enheten; varje ytterligare gäst behöver sin egen Virtual DSM-licens. Klusterbildning över flera NAS-enheter, livemigrering och större snapshot-lagring är VMM Pro funktioner snarare än standardfunktioner. Om din konsolideringsplan innebär att dela upp en upptagen gäst i fyra snygga, prissätt det innan du utformar den.

Att bedöma en gästs storlek korrekt är en egen uppgift: hur man justerar storleken på en produktions-VM med VMM Pro.

För det fjärde, scenarier att undvika. Placera inte en gästs virtuella disk på samma fysiska volym som du säkerhetskopierar till och kalla det en säkerhetskopia. Kör inte en databas med tunga, ihållande skrivningar på en gäst som delar snurrande diskar med en upptagen filserver. Behandla inte VDSM som en ersättning för en andra maskin, för om värden dör dör varje gäst på den samtidigt. Och migrera inte en container som du aldrig har inspekterat, av skälen i avsnittet om compose-file ovan.

För det femte, inloggningsuppgifter. En migrering berör databaslösenord, miljövariabler och konfigurationsfiler. Vår migrering flyttade en compose-fil som innehöll databasinloggningsuppgifter i klartext, så den placerades avsiktligt utanför webbserverns dokumentrot. En compose-fil som lämnades inuti en dokumentrot kan laddas ner av alla som gissar filnamnet, och det är ett deprimerande vanligt sätt som inloggningsuppgifter läcker ut. Om du låter en assistent skripta en migrering, läs var den skriver filer. Och när jobbet är klart, inaktivera kontot du skapade för assistenten istället för att lämna en aktiv administratörsinloggning kvar.

För det sjätte, en ögonblicksbild innan du rör någonting. En VDSM-ögonblicksbild i Virtual Machine Manager tar några sekunder, är tillgänglig utan Pro-licensen och förvandlar nästan varje misstag i den här artikeln till en tvåminuters återställning. Det är det enda steget som är värt att lägga till i alla migreringsrunbooks, oavsett om en människa eller en assistent skriver.

Slutligen, verifiera snarare än anta. Varje påstående i den här artikeln har kontrollerats mot det körande systemet: tabellantal på båda sidor, bifogade filer på disken, plugin-versioner registrerade av applikationen, inga väntande migreringar och en fullständig omstart av stacken för att bevisa att den återställs av sig själv. En migrering är inte klar när tjänsten svarar. Den är klar när du har bevisat att den överlever en omstart av VDSM-gästen, och när den gamla kopian inte längre kan acceptera skrivningar.

En anmärkning om var man kan få tag på dessa licenser, eftersom det är vad vi gör: SynoPower Club säljer Synology-licenser med omedelbar nyckelleverans dygnet runt. De två som är viktiga här är Virtual DSM-licens, som du behöver för varje gäst utöver den gratis, och VMM Pro-licens om du vill ha kluster, livemigrering eller 255 ögonblicksbilder per gäst istället för 32. Den fullständig licenskatalog täcker även Surveillance Station och MailPlus.

Referenser

• SynoPower Club, våra Synology NAS-guider och kamerarecensioner
• Synology — Virtual Machine Manager, den officiella översikten över paketet som kör VDSM
• Synology Kunskapscenter — Virtual Machine Manager hjälp, skapande och inställningar för gäster
• Docker — docker container commit, kommandot bakom steg ett
• Docker — spara docker-bilder, används för att streama bilden mellan gäster

Vanliga frågor