Synology VDSM: Flytte Docker med AI og endre størrelsen på en virtuell disk (2026)

En virtuell NAS er en av de funksjonene folk installerer én gang, roter til den en ettermiddag, og så glemmer at de eier den. Det er synd, for Synology VDSM – Virtual DSM, kjører inne i Virtual Machine Manager – løser stille to av de mest irriterende problemene med småskala selvhosting. Det første er at det å flytte en Docker-stack mellom maskiner vanligvis koster deg en kveld med kjedelig arbeid. Det andre er at når en virtuell disk går tom for plass, antar de fleste at de må bygge hele greia på nytt. Ingen av delene gjelder for VDSM. Denne veiledningen går gjennom en ekte migrering vi kjørte på omtrent trettifem minutter: en intern Redmine-problemsporing med fem pluginer, løftet ut av én VDSM-gjest og sluppet inn i en annen, med en AI-assistent som kjørte skallet. Underveis gikk destinasjonen tom for disk, så vi økte den virtuelle disken fra 10 GB til 20 GB og fortsatte. Alt nedenfor er hva som faktisk skjedde, inkludert den ene fellen som ville ha ødelagt applikasjonen i stillhet.

SynoPower Club-punkt:Jeg har sett mange snakke seg selv bort fra virtualisering på en NAS fordi de antar at det er for laboratorier og ikke for ordentlig arbeid. Migreringen i denne artikkelen var ordentlig arbeid – et billettsystem som tre kolleger bruker hver dag – og den delen som overrasket meg var ikke AI-en. Det var hvor lite seremonielt VDSM trenger. Ingen hypervisor å lisensiere, ingen separat administrasjonsserver, ingen eksport-import-dans mellom inkompatible formater. Gjesten gikk tom for disk midt i jobben, og jeg fikset det ved å skrive et større tall i et tekstfelt mens den fortsatt kjørte. Hele jobben tok 35 minutter, og det eneste avbruddet noen la merke til var 90 sekunder på et urelatert nettsted. Hvis du allerede eier en Synology med ekstra minne, er du én pakkeinstallasjon unna dette.

Hva er Synology VDSM?

VDSM er Synologys Virtual DSM: en komplett kopi av DiskStation Manager som kjører som et gjesteoperativsystem inne i Virtual Machine Manager på en fysisk NAS. Den oppfører seg som en separat NAS. Sin egen IP-adresse, sin egen DSM-pålogging, sine egne pakker, sin egen Container Manager. Fra nettverkets synspunkt er det rett og slett en annen Synology på LAN-et. Fra maskinvarens synspunkt er det én prosess til på en boks du allerede har betalt for.

Den praktiske fordelen er isolasjon. Kjør alle tjenester direkte på verten, og én dårlig oppført container kan sulte filserveren som hele kontoret er avhengig av. Å dele arbeidsbelastninger på tvers av VDSM-gjester gir hver av dem et minnetak, en CPU-allokering og en egen disk, og lar deg starte én på nytt uten å berøre de andre.

Hver NAS som støtter Virtual Machine Manager inkluderer én VDSM-lisens uten kostnad. Å kjøre en andre og påfølgende gjestelisens krever en betalt Virtual DSM-lisens hver. Den ene gratisforekomsten er nok til å følge alt i denne artikkelen, og det er derfor så mange allerede eier funksjonaliteten og aldri har aktivert den. Hvis du trenger å legge til, tilordne eller fjerne tilordningen av en lisens senere, har vi en gjennomgang på administrere VDSM-lisenser.

VDSM og Virtual DSM er to navn på det samme. Synologys egen dokumentasjon bruker den lange formen, og de fleste eiere bruker den korte. Forkortelsen deles også med en urelatert komponent av oVirt-virtualiseringsprosjektet, så på en Synology NAS betyr det alltid Virtual DSM.

En betalt lisens fungerer annerledes enn det folk flest forventer. Hver lisens legger til én ekstra gjest og inkluderer tre år med Virtual DSM-programvareoppgraderinger. Den virtuelle maskinen utløper aldri. Etter de tre årene fortsetter den å kjøre uten nye oppdateringer. Aktivering av en ny nøkkel starter ytterligere tre år med oppdateringer. En nøkkel er aktiv på én Synology NAS om gangen, og NAS-en må være online når du legger den til.

Kravene til en VDSM-gjest er beskjedne, og Synology lister dem opp i sin Virtual Machine Manager-spesifikasjoner:

• Den virtuelle disken må stå på et Btrfs-volum. Virtual Machine Manager lagrer ikke gjester på ext4.
• Selve NAS-en trenger mer enn 2 GB minne før den kan kjøre en virtuell maskin.
• Hver gjest trenger minst 1 GB minne for seg selv, og reelle arbeidsbelastninger trenger mer.
• Hvor mange gjester en modell kan kjøre komfortabelt, avhenger av CPU-en og det installerte minnet.

En gjest er ikke identisk med DSM på bare metal. Tre ting mangler, og alle er knyttet til fysisk maskinvare:

• USB-gjennomgang er ikke tilgjengelig, så en enhet som er koblet til en USB-port på NAS-en kan ikke gis til gjesten.
• Sidene Eksterne enheter og Maskinvare og strøm i Kontrollpanel er ikke der.
• Trådløse dongler, MTU-innstillinger og koblingsaggregering (LACP) støttes ikke inne i gjesten. Verten håndterer det fysiske nettverket.

Ingenting av dette påvirker de vanlige grunnene til å kjøre en. Filtjenester, Docker, en e-postserver eller en staging-kopi av et produksjonssystem oppfører seg alle som de ville gjort på en separat NAS.

Synology VDSM vs. en annen fysisk NAS: Hvilken trenger du?

Den ærlige sammenligningen er ikke at virtuelt er bedre. Det er en byttehandel av robusthet mot fleksibilitet. En annen fysisk boks overlever feilen til den første; det gjør ikke en VDSM-gjest. Det en gjest kjøper deg i stedet er muligheten til å opprette, endre størrelse, ta øyeblikksbilder og flytte en hel server på minutter i stedet for dager.

	VDSM-gjest	Andre fysiske NAS-en
Kostnad for å legge til én	Gratis for den første gjesten, lisens etter det	En hel NAS pluss disker
Tid for levering	Minutter	Dager, når frakten er telt
Endre størrelse på CPU, RAM eller disk	Rediger et felt, start gjesten på nytt	Kjøp ny maskinvare
Overlever maskinvarefeil på verten	Ingen	Ja
Øyeblikksbilde og klon	Innebygd i Virtual Machine Manager	Ikke aktuelt
Flytt til en annen NAS	Migrer eller repliker gjesten	Flytt den fysisk
Best for	Isolering av tjenester, oppsett, konsolidering av små servere	Backup-mål og reell redundans

For denne jobben var valget opplagt. Vi konsoliderte en lite brukt problemsporing som hadde fått en hel VDSM-gjest, til en gjest som allerede kjørte et nettsted med ledig kapasitet. Ingenting ved det krever ny maskinvare. Det krever ti minutter og litt stell.

Det du trenger før du starter

Før noe annet, gi assistenten sin egen pålogging i stedet for å gi fra seg din. I DSM åpner du Kontrollpanel, går til Bruker og gruppe og klikker på Opprett. Gi den et umiskjennelig navn – vi brukte Claude med beskrivelsen AI-kontroll – og la DSM generere et sterkt tilfeldig passord.

På neste skjermbilde, kryss av administratorer. Dette er ikke valgfritt: DSM tillater bare medlemmer av administratorgruppen å logge inn via SSH, så en konto utenfor den gruppen kan ikke nå skallet i det hele tatt. Gjør det samme på begge VDSM-gjestene, og sørg deretter for at SSH er slått på under Kontrollpanel, Terminal og SNMP.

Når arbeidet er ferdig, deaktiver kontoen. Det er hele poenget med å lage en separat konto. Rediger brukeren i Kontrollpanel og slå den av, eller slett den fullstendig; tilgangen tilbakekalles med ett klikk uten å berøre dine egne påloggingsinformasjoner, og alt assistenten gjorde forblir tilskrivbar en pålogging som finnes for akkurat det formålet. Å la en permanent aktivert administratorkonto ligge rundt fordi det var praktisk en gang, er hvordan små eiendommer samler tilgang som ingen husker å ha gitt.

To VDSM-gjester, SSH aktivert på begge, og Container Manager installert på destinasjonen. Du må også vite én ting som fanger opp nesten alle første gang: Docker-binærfilen er ikke på standard PATH i DSM. Pakkebinærfiler ligger under pakkekatalogen, så hver kommando trenger hele banen eller et skallalias.

Sjekk at det er plass på destinasjonen før du starter, i stedet for halvveis i en overføring. Kommandoene nedenfor er hele før-flyvning-sjekken, og de er identiske for alle VDSM-gjester.

En ting til før alt av det: ta et bilde av begge gjestene i Virtual Machine Manager. Snapshots finnes i gratisutgaven av Virtual Machine Manager, ikke bare Pro, og den vil beholde opptil 32 av dem per gjest. Et VDSM-snapshot fanger opp hele maskinen, så hvis en import går galt eller en kommando gjør noe du ikke hadde til hensikt, ruller du tilbake gjesten i stedet for å bygge den opp igjen. Det koster sekunder, og det er den billigste forsikringen i hele denne prosessen. Ta en på kilden så vel som destinasjonen, fordi kilden er din reserve.

# Docker er ikke på PATH i DSM - bruk hele stien D=/volume1/@appstore/ContainerManager/usr/bin/docker # Hva kjører, og hva er det bygget av? sudo $D ps -a sudo $D images # Hvor mye plass er igjen på målvolumet? df -h /volume1 # Hvor mye minne har målgjesten faktisk ledig? free -m

VDSM Docker-migrering i 4 trinn

Dette er de fire trinnene vi kjørte, og de fungerer for alle containerstakker du trenger å løfte mellom VDSM-gjester. Rekkefølgen er viktig: applikasjonscontaineren stoppes først, slik at ingenting skriver til databasen midt i dumpingen, og databasecontaineren forblir oppe slik at den kan dumpes uten problemer.

Hvorfor Compose-filen ikke er hele beholderen

Her er fellen, og den er verdt prisen i seg selv. Compose-filen for Redmine-stakken vår deklarerte to bindingsmonteringer: én for opplastede filer og én for databasen. Les den filen, og du ville rimeligvis konkludere med at det å gjenskape stakken på den nye gjesten innebar å kopiere to kataloger og kjøre docker compose.

Det gjorde det ikke. Fem programtillegg, Ruby-perlene som disse programtilleggene hentet inn, e-postkonfigurasjonen og flere redigerte initialiseringsfiler hadde blitt installert rett i containeren som kjørte opp gjennom årene. Ingenting av det var i et volum. Én kommando fortalte oss hvor ille det var.

# Hvor mange filer er forskjellige mellom containeren og bildet den kom fra? sudo $D diff Redmine | wc -l 6764 # Programtillegg som ligger inne i containeren, uten noe volum i det hele tatt sudo $D exec Redmine ls /usr/src/redmine/plugins

Å hente et nytt, offisielt image ville ha produsert en container uten noen av disse pluginene, pekt mot en database som fortsatt inneholdt de 144 tabellene som ble opprettet av migreringene deres. Applikasjonen ville ikke ha feilet høylytt. Den ville ha startet, sett nesten riktig ut, og deretter brutt sammen på måter som er elendige å diagnostisere. Å legge til den kjørende containeren til et image omgår problemet fullstendig, på bekostning av en større overføring. På et LAN mellom to VDSM-gjester koster det omtrent ett minutt, så bytt hver gang.

Hvordan et lite team bruker VDSM til å konsolidere servere

Mønsteret denne migrasjonen følger er et av de fleste små teamene til slutt trenger. I løpet av noen år samler du gjester med ett formål: én for wikien, én for billettsporeren, én for et overvåkingsdashbord (formen beskrevet i vår gjennomgang av hjemmedatasenter). Hver av dem var sjenerøs den dagen de ble bygget, og hver av dem går nå på tomgang til en brøkdel av det de fikk, mens verten er overforpliktet og alt føles litt tregt.

Å konsolidere med VDSM betyr å legge de stille arbeidsbelastningene inn i en gjest som allerede er våken. Vår billettsporer hadde en hel gjest med sin egen CPU-allokering og 1 GB minne, for en tjeneste tre personer berører et par ganger om dagen. Å flytte den ved siden av en eksisterende webstack frigjorde denne allokeringen fullstendig og kostet destinasjonen omtrent 480 MB resident minne på tvers av to containere.

Disiplinen som gjør dette trygt er å pensjonere kildekoden på riktig måte i stedet for å la den kjøre. Vi satte de gamle containerne til en omstartspolicy på nei, stoppet dem, la en tekstfil i katalogen som forklarte hvor tjenesten nå befinner seg, og slo av gjestetjenesten med automatisk start deaktivert. Den forblir et fullstendig tilbakestillingspunkt, og den kan ikke stille komme tilbake til live etter en omstart av verten og begynne å godta skrivinger som den nye instansen aldri vil se. Divergerende duplikater er den klassiske måten en ryddig migrering blir en datatapshendelse en måned senere.

Endre størrelsen på en virtuell disk som har gått tom for plass

Halvveis gikk destinasjonen tom for plass. Volumet var 9,6 GB med 1,5 GB ledig plass, og vi var i ferd med å legge til et 816 MB image pluss 123 MB med programdata. På en fysisk NAS er det her historien stopper inntil nye disker ankommer. På VDSM er det et tekstfelt.

Åpne gjesteinnstillingene i Virtual Machine Manager, gå til Lagring-fanen, skriv inn den nye størrelsen og klikk OK. Gjesten trenger ikke å bli stengt ned for dette. Disken vokser mens maskinen fortsetter å kjøre, og det er derfor dette er en fundamentalt annerledes opplevelse enn å legge til kapasitet til bar maskinvare. Den ene regelen som er verdt å vite er at en virtuell disk bare kan vokse, aldri krympe, så det er ingen angremuligheter og ingen grunn til å være sjenert over antallet.

Det som gjør det virkelig smertefritt er det som skjer inne i gjesten. DSM utvider partisjonen og filsystemet for å fylle den nye plassen av seg selv. Det er ingen Storage Manager-veiviser å kjøre, ingen partisjonstabell å redigere, ingen volum å gjenoppbygge og ingen data å migrere. Volumet vårt gikk fra 9,6 GB med 1,5 GB ledig til 20 GB med 13 GB ledig, og containerne fortsatte. Dette er det sterkeste argumentet for å legge en tjeneste på VDSM i stedet for bare maskinvare: feil størrelse er billig å fikse senere.

Hva AI-assistenten faktisk gjorde

Det er verdt å være presis her, fordi “AI flyttet serveren min” inviterer til både for mye og for lite godtroenhet. Assistenten hadde ingen magisk innsikt. Den hadde et skall på begge VDSM-gjestene, og den var systematisk på en måte et slitent menneske på slutten av en arbeidsdag vanligvis ikke er.

Det aller mest verdifulle den gjorde var å kjøre docker diff før den rørte noe, legge merke til 6764 endrede filer og avvise den åpenbare planen. Noen som fulgte compose-filen ville ikke hatt noen grunn til å kjøre den kommandoen. Det nest mest verdifulle var verifisering: etter importen telte den tabeller, problemer, prosjekter, journaloppføringer og vedlegg på begge sider, sjekket at alle vedleggsfiler fantes på disken, listet opp plugin-versjonene applikasjonen hadde registrert, og bekreftet at det ikke var noen ventende databasemigreringer. Det er en kjedelig sjekkliste, og kjedelige sjekklister er akkurat det som hoppes over klokken fem om ettermiddagen.

Det som fortsatt trengtes fra et menneske var en vurdering av konsekvensene. Å starte en VDSM-gjest på nytt for å legge til minne betydde å ta ned et aktivt nettsted, og det er en avgjørelse man bør spørre om snarere enn å anta. Det samme gjelder for å slette hva som helst. Behandle assistenten som et veldig raskt, veldig bokstavelig par hender som aldri blir lei av å sjekke, og behold de irreversible anropene for deg selv.

Hvor du finner flere offisielle ressurser

Virtual Machine Manager, pakken som er vert for alle VDSM-gjester, har vært i DSM i årevis og er godt dekket. Disse tre gjennomgangene dekker installasjon av pakken, oppretting av en gjest og den generelle formen på grensesnittet du skal jobbe i.

Grenser du bør vite før du stoler på VDSM med produksjon

For det første er minne bindingsbegrensningen mye oftere enn CPU. Vår destinasjonsgjest hadde 2 GB og var allerede i swap før vi la til noe. En annen applikasjon pluss en annen database trengte omtrent ytterligere 480 MB, så vi økte det til 4 GB. Sjekk ledig minne på destinasjonen før du planlegger flyttingen, ikke etterpå.

For det andre vokser en virtuell VDSM-disk, men krymper aldri. Overprovisjonering, og du kan ikke gjenvinne plassen ved å redigere feltet ned igjen; den eneste veien til en mindre disk er å bygge en ny gjest og migrere til den. Velg et tall du fortsatt vil være fornøyd med om to år.

For det tredje, lisensiering. Én gjest er inkludert i NAS-en; hver ekstra gjest trenger sin egen Virtual DSM-lisens. Klynging på tvers av flere NAS-enheter, live-migrering og større snapshot-retensjon er VMM Pro funksjoner i stedet for standardfunksjoner. Hvis konsolideringsplanen din innebærer å dele én travel gjest inn i fire ryddige, bør du sette pris på det før du designer den.

Å vurdere riktig størrelse på en gjest er sin egen jobb: Slik justerer du riktig størrelse på en produksjons-VM med VMM Pro.

For det fjerde, scenariene du bør unngå. Ikke plasser en gjests virtuelle disk på det samme fysiske volumet du sikkerhetskopierer til, og kall det en sikkerhetskopi. Ikke kjør en database med mye vedvarende skriving på en gjest som deler roterende disker med en travel filserver. Ikke bruk VDSM som en erstatning for en andre maskin, for hvis verten dør, dør alle gjestene på den samtidig. Og ikke migrer en container du aldri har inspisert, av grunnene i delen om compose-file ovenfor.

For det femte, legitimasjon. En migrering berører databasepassord, miljøvariabler og konfigurasjonsfiler. Vår flyttet en compose-fil som inneholdt databaselegitimasjon i ren tekst, så den ble bevisst plassert utenfor webserverens dokumentrot. En compose-fil som ble liggende inne i en dokumentrot kan lastes ned av alle som gjetter filnavnet, og det er en deprimerende vanlig måte legitimasjon lekker på. Hvis du lar en assistent skripte en migrering, les hvor den skriver filer. Og når jobben er ferdig, deaktiver kontoen du opprettet for assistenten i stedet for å la en aktiv administratorpålogging ligge igjen.

For det sjette, snapshot før du berører noe. Et VDSM-snapshot i Virtual Machine Manager tar sekunder, er tilgjengelig uten Pro-lisensen, og gjør nesten alle feil i denne artikkelen om til en to-minutters tilbakerulling. Det er det ene trinnet som er verdt å legge til i enhver migrerings-runbook, enten det er et menneske eller en assistent som skriver.

Til slutt, verifiser heller enn anta. Alle påstander i denne artikkelen ble kontrollert mot det kjørende systemet: antall tabeller på begge sider, vedleggsfiler på disken, plugin-versjoner registrert av applikasjonen, ingen ventende migreringer og en fullstendig omstart av stakken for å bevise at den kommer tilbake av seg selv. En migrering er ikke fullført når tjenesten svarer. Den er fullført når du har bevist at den overlever en omstart av VDSM-gjesten, og når den gamle kopien ikke lenger kan godta skrivinger.

En liten merknad om hvor du kan få tak i disse lisensene, siden det er det vi gjør: SynoPower Club selger Synology-lisenser med umiddelbar nøkkellevering døgnet rundt. De to som er viktige her er Virtual DSM-lisens, som du trenger for hver gjest utover den gratis gjesten, og VMM Pro-lisens hvis du ønsker klynging, live-migrering eller 255 øyeblikksbilder per gjest i stedet for 32. Den fullstendig lisenskatalog dekker også Surveillance Station og MailPlus.

Referanser

• SynoPower Club, våre Synology NAS-guider og kameraanmeldelser
• Synology — Virtual Machine Manager, den offisielle oversikten over pakken som kjører VDSM
• Synology Kunnskapssenter — Virtual Machine Manager hjelp, oppretting og innstillinger for gjester
• Docker — docker-container-commit, kommandoen bak trinn én
• Docker — lagring av docker-bilde, brukes til å strømme bildet mellom gjester

Ofte stilte spørsmål