Synology VDSM: Docker-Verschiebung mit KI und Größenänderung einer virtuellen Festplatte (2026)
Ein virtuelles NAS gehört zu jenen Funktionen, die man einmal installiert, einen Nachmittag lang ausprobiert und dann vergisst. Das ist schade, denn Synology VDSM – Virtual DSM, ausgeführt in Virtual Machine Manager – löst im Hintergrund zwei der größten Probleme beim Self-Hosting kleiner Systeme. Erstens: Das Verschieben eines Docker-Stacks zwischen Maschinen kostet normalerweise einen ganzen Abend mühsamer Arbeit. Zweitens: Wenn der Speicherplatz auf der virtuellen Festplatte knapp wird, gehen die meisten davon aus, dass sie alles neu aufbauen müssen. Beides ist mit VDSM nicht der Fall. Diese Anleitung beschreibt eine reale Migration, die wir in etwa 35 Minuten durchgeführt haben: Ein interner Redmine-Issue-Tracker mit fünf Plugins wurde von einer VDSM-Gastmaschine in eine andere verschoben, wobei ein KI-Assistent die Shell steuerte. Währenddessen ging auf der Zielmaschine der Speicherplatz aus, also erweiterten wir die virtuelle Festplatte von 10 GB auf 20 GB und fuhren fort. Alles Folgende beschreibt den tatsächlichen Ablauf, einschließlich der einen Falle, die die Anwendung unbemerkt zerstört hätte.
SynoPower Club-Punkt:I have watched a lot of people talk themselves out of virtualisation on a NAS because they assume it is for labs and not for real work. The migration in this article was real work — a ticket system three colleagues use every day — and the part that surprised me was not the AI. It was how little ceremony VDSM needs. No hypervisor to license, no separate management server, no export-import dance between incompatible formats. The guest ran out of disk mid-job and I fixed it by typing a bigger number into a text field while it was still running. The whole job took thirty-five minutes and the only outage anyone noticed was ninety seconds on an unrelated website. If you already own a Synology with spare memory, you are one package install away from this.
Was ist Synology VDSM?
VDSM ist im Prinzip ein Virtual DSM-System für Synology: eine vollständige Kopie des DiskStation Managers, die als Gastbetriebssystem innerhalb von Virtual Machine Manager auf einem physischen NAS läuft. Es verhält sich wie ein separates NAS mit eigener IP-Adresse, eigenem DSM-Login, eigenen Paketen und eigenem Container Manager. Aus Netzwerksicht ist es einfach ein weiteres Synology-System im LAN. Aus Hardware-Sicht ist es ein weiterer Prozess auf einem bereits bezahlten Gerät.
Der praktische Vorteil liegt in der Isolation. Läuft jeder Dienst direkt auf dem Host, kann ein fehlerhafter Container den Dateiserver lahmlegen, von dem das gesamte Büro abhängt. Die Verteilung der Arbeitslasten auf VDSM-Gäste ermöglicht es jedem Gast, über eine eigene Speichergrenze, eine eigene CPU-Zuweisung und eine eigene Festplatte zu verfügen. Außerdem kann man einen Gast neu starten, ohne die anderen zu beeinträchtigen.
Every NAS that supports Virtual Machine Manager includes one VDSM licence at no cost. Running a second and subsequent guest needs a paid Virtual DSM licence each. That single free instance is enough to follow everything in this article, and it is why so many people already own the capability and have never switched it on. If you need to add, map or unmap a licence later, we have a walkthrough on Verwaltung von VDSM-Lizenzen.
Synology VDSM vs. ein zweites physisches NAS: Was brauchen Sie?
Der ehrliche Vergleich lautet nicht, dass virtuell besser ist. Es ist ein Tausch von Ausfallsicherheit gegen Flexibilität. Ein zweiter physischer Server übersteht den Ausfall des ersten; ein VDSM-Gastsystem nicht. Was ein Gastsystem Ihnen stattdessen bietet, ist die Möglichkeit, einen kompletten Server innerhalb von Minuten statt Tagen zu erstellen, zu skalieren, Snapshots zu erstellen und zu verschieben.
| VDSM-Gast | Zweites physisches NAS | |
|---|---|---|
| Kosten für das Hinzufügen eines | Kostenlos für den ersten Gast, danach Lizenz erforderlich | Ein komplettes NAS plus Festplatten |
| Bereitstellungszeit | Minuten | Tage, sobald der Versand berücksichtigt ist |
| Größe von CPU, RAM oder Festplatte ändern | Bearbeiten Sie ein Feld, starten Sie den Gast neu. | Kaufen Sie neue Hardware |
| Übersteht Hardwareausfall des Hostsystems | NEIN | Ja |
| Snapshot und Klon | Eingebaut in Virtual Machine Manager | Nicht zutreffend |
| Wechseln Sie zu einem anderen NAS | Migrieren oder replizieren Sie den Gast | Verlegen Sie es physisch. |
| Am besten geeignet für | Dienste isolieren, Staging, kleine Server konsolidieren | Backup-Ziele und echte Redundanz |
Für diese Aufgabe war die Wahl klar. Wir konsolidierten ein wenig genutztes Issue-Tracking-System, das einen eigenen VDSM-Gastprozess hatte, auf einen bereits laufenden Website-Gastprozess mit freier Kapazität. Dafür ist keine neue Hardware nötig. Es braucht nur zehn Minuten und etwas Sorgfalt.
Was Sie vor dem Start benötigen
Before anything else, give the assistant its own login rather than handing over yours. In DSM open Control Panel, go to User & Group and click Create. Name it something unmistakable — we used claude with the description AI control — and let DSM generate a strong random password.
On the next screen, tick administrators. This is not optional: DSM only permits members of the administrators group to log in over SSH, so an account outside that group cannot reach the shell at all. Do the same on both VDSM guests, then make sure SSH is switched on under Control Panel, Terminal & SNMP.
When the work is finished, disable the account. That is the whole point of making a separate one. Edit the user in Control Panel and switch it off, or delete it outright; access is revoked in one click without touching your own credentials, and everything the assistant did stays attributable to a login that exists for exactly that purpose. Leaving a permanently enabled administrator account lying around because it was convenient once is how small estates accumulate access nobody remembers granting.
Zwei VDSM-Gäste, SSH auf beiden aktiviert und Container Manager auf dem Zielsystem installiert. Wichtig zu wissen: Die Docker-Binärdatei befindet sich nicht im Standard-PATH von DSM. Paketdateien liegen im Paketverzeichnis, daher benötigt jeder Befehl den vollständigen Pfad oder einen Shell-Alias.
Prüfen Sie vor dem Antritt des Transfers, ob am Zielort noch Platz ist, und nicht erst mitten im Transfer. Die folgenden Befehle umfassen die vollständige Vorflugkontrolle und sind für alle VDSM-Gäste identisch.
One more thing before any of it: take a snapshot of both guests in Virtual Machine Manager. Snapshots are in the free edition of Virtual Machine Manager, not just Pro, and it will keep up to 32 of them per guest. A VDSM snapshot captures the whole machine, so if an import goes wrong or a command does something you did not intend, you roll the guest back instead of rebuilding it. It costs seconds and it is the single cheapest insurance in this entire process. Take one on the source as well as the destination, because the source is your fallback.
# Docker ist nicht im PATH von DSM – verwenden Sie den vollständigen Pfad: D=/volume1/@appstore/ContainerManager/usr/bin/docker # Was läuft und woraus wurde es erstellt? sudo $D ps -a sudo $D images # Wie viel Speicherplatz ist auf dem Zielvolume noch frei? df -h /volume1 # Wie viel Arbeitsspeicher hat der Ziel-Gast tatsächlich frei? free -mVDSM Docker-Migration in 4 Schritten
Dies sind die vier Schritte, die wir durchgeführt haben, und sie funktionieren für jeden Container-Stack, den Sie zwischen VDSM-Gästen verschieben müssen. Die Reihenfolge ist wichtig: Der Anwendungscontainer wird zuerst gestoppt, damit während des Dump-Vorgangs nichts in die Datenbank geschrieben wird, und der Datenbankcontainer bleibt aktiv, damit er sauber gesichert werden kann.
Take a VDSM snapshot, then snapshot the container itself
Take a Virtual Machine Manager snapshot of both guests first – it is in the free edition and it is your undo button for everything that follows. Then stop the application container and run docker commit against it to capture its filesystem as a new image. This is the step people skip, and skipping it is what breaks the migration. Bind-mounted paths are excluded from a commit, so the data volume still has to be handled separately in step two.
Datenbank sichern und Datenvolumen archivieren
Während der Datenbankcontainer noch läuft, erstellen Sie mit mariadb-dump und dem Single-Transaction-Flag einen logischen Dump. Anschließend packen Sie das eingebundene Datenverzeichnis als TAR-Archiv. Ein logischer Dump wird dem Kopieren der Rohdatendateien bewusst vorgezogen, da das Image-Tag auf dem Zielsystem fast nie exakt der Datenbankversion entspricht.
Alles wird an den Zielgast gestreamt.
Mit `docker save` wird das Quell-Image per gzip komprimiert und per SSH direkt in eine Datei auf dem Ziel-Image gespeichert. Dasselbe gilt für das Datenarchiv. Unser 816 MB großes Image wurde auf 366 MB komprimiert und in etwa einer Minute über das LAN übertragen. Laden Sie das Image auf dem Ziel-Image und entpacken Sie das Archiv mit dem Flag `preserve-permissions`.
Starten Sie zuerst die Datenbank, importieren Sie die Daten und starten Sie dann die Anwendung.
Starten Sie zunächst nur den Datenbankdienst, warten Sie, bis er Verbindungen akzeptiert, importieren Sie den Dump und überprüfen Sie, ob die Tabellen- und Zeilenanzahl mit der Quelle übereinstimmt. Starten Sie erst dann den Anwendungscontainer. Stellen Sie die Neustartrichtlinien auf „Immer“ ein, damit der Stack einen Neustart des Gastsystems übersteht.
Warum die Compose-Datei nicht der gesamte Container ist
Hier liegt die Falle, und allein dafür lohnt sich der Eintrittspreis. Die Compose-Datei für unseren Redmine-Stack deklarierte zwei Bind-Mounts: einen für hochgeladene Dateien und einen für die Datenbank. Liest man diese Datei, könnte man vernünftigerweise annehmen, dass das Neuerstellen des Stacks auf dem neuen Gastsystem das Kopieren zweier Verzeichnisse und das Ausführen von `docker compose up` bedeutet.
Das war nicht der Fall. Fünf Plugins, die dazugehörigen Ruby-Gems, die E-Mail-Konfiguration und mehrere bearbeitete Initialisierungsdateien waren über die Jahre direkt in den laufenden Container installiert worden. Nichts davon befand sich auf einem Volume. Ein einziger Befehl verdeutlichte das ganze Ausmaß des Problems.
# Wie viele Dateien unterscheiden sich zwischen dem Container und dem Image, von dem er stammt? sudo $D diff Redmine | wc -l 6764 # Plugins, die sich im Container befinden und keinem Volume zugeordnet sind: sudo $D exec Redmine ls /usr/src/redmine/pluginsDas Erstellen eines neuen offiziellen Images hätte einen Container ohne diese Plugins erzeugt, der auf eine Datenbank mit den 144 durch die Migrationen erstellten Tabellen zugreift. Die Anwendung wäre nicht mit einer Fehlermeldung abgestürzt. Sie wäre gestartet, hätte fast korrekt funktioniert und wäre dann auf schwer zu diagnostizierende Weise ausgefallen. Das Speichern des laufenden Containers in einem Image umgeht dieses Problem vollständig, allerdings auf Kosten einer längeren Datenübertragung. In einem LAN zwischen zwei VDSM-Gästen beträgt diese etwa eine Minute – daher lohnt sich dieser Aufwand immer.
Wie ein kleines Team VDSM zur Serverkonsolidierung nutzt
Das Muster dieser Migration entspricht dem, das die meisten kleinen Teams früher oder später benötigen. Über einige Jahre hinweg sammeln sich spezialisierte Anwendungen an: eine für das Wiki, eine für das Ticket-System, eine für ein Monitoring-Dashboard (die in unserer [Referenz einfügen] beschriebene Struktur). Rundgang durch das Heim-RechenzentrumJedes System wurde bei seiner Errichtung großzügig dimensioniert und läuft nun im Leerlauf mit einem Bruchteil der ursprünglich vorgesehenen Leistung, während der Host überlastet ist und sich alles etwas langsam anfühlt.
Die Konsolidierung mit VDSM bedeutet, die im Hintergrund laufenden Workloads in einen bereits aktiven Gastprozess auszulagern. Unser Ticket-Tracker nutzte einen eigenen Gastprozess mit eigener CPU-Zuweisung und 1 GB Arbeitsspeicher für einen Dienst, der nur von drei Personen mehrmals täglich genutzt wird. Durch die Verlagerung neben einen bestehenden Web-Stack wurde diese Zuweisung freigegeben, wodurch der Zielprozess etwa 480 MB Arbeitsspeicher in zwei Containern weniger benötigte.
Die notwendige Disziplin, um dies zu gewährleisten, besteht darin, die Quelle ordnungsgemäß außer Betrieb zu nehmen, anstatt sie weiterlaufen zu lassen. Wir haben die alten Container so konfiguriert, dass sie nicht neu gestartet werden, sie gestoppt, eine Textdatei im Verzeichnis hinterlassen, die den neuen Speicherort des Dienstes beschreibt, und den Gast mit deaktiviertem Autostart heruntergefahren. Dadurch bleibt ein vollständiger Rollback-Punkt erhalten, und die Quelle kann nach einem Neustart des Hosts nicht unbemerkt wieder aktiv werden und Schreibvorgänge annehmen, die die neue Instanz nie verarbeiten wird. Divergente Duplikate sind der klassische Grund, warum eine eigentlich saubere Migration einen Monat später zu einem Datenverlust führen kann.
Ändern der Größe einer virtuellen Festplatte, die nicht mehr genügend Speicherplatz hatte
Nach der Hälfte des Vorgangs war der Speicherplatz auf dem Zielsystem erschöpft. Das Volume hatte eine Größe von 9,6 GB, davon waren 1,5 GB frei, und wir wollten gerade ein 816 MB großes Image sowie 123 MB Anwendungsdaten hinzufügen. Auf einem physischen NAS endet der Vorgang an dieser Stelle, bis neue Festplatten eintreffen. Auf VDSM wird dies als Textfeld dargestellt.
Open the guest’s settings in Virtual Machine Manager, go to the Storage tab, type the new size and click OK. The guest does not have to be shut down for this. The disk grows while the machine keeps running, which is why this is a fundamentally different experience from adding capacity to bare hardware. The one rule worth knowing is that a virtual disk can only grow, never shrink, so there is no undo and no reason to be shy about the number.
What makes it genuinely painless is what happens inside the guest. DSM expands the partition and the filesystem to fill the new space by itself. There is no Storage Manager wizard to run, no partition table to edit, no volume to rebuild and no data to migrate. Our volume went from 9.6 GB with 1.5 GB free to 20 GB with 13 GB free, and the containers carried on. This is the single strongest argument for putting a service on VDSM rather than on bare hardware: getting the sizing wrong is cheap to fix later.
Was der KI-Assistent tatsächlich getan hat
Hier ist Präzision wichtig, denn die Aussage “KI hat meinen Server verschoben” weckt sowohl zu viel als auch zu wenig Glaubwürdigkeit. Der Assistent besaß keine magischen Fähigkeiten. Er hatte Zugriff auf beide VDSM-Gäste und arbeitete systematisch, anders als ein müder Mensch am Ende eines Arbeitstages.
Das Wertvollste, was es tat, war, vor jeder Änderung `docker diff` auszuführen, 6.764 geänderte Dateien zu finden und den naheliegenden Plan zu verwerfen. Jemand, der sich an die Compose-Datei gehalten hätte, hätte diesen Befehl gar nicht ausführen müssen. Das Zweitwertvollste war die Überprüfung: Nach dem Import zählte es Tabellen, Vorgänge, Projekte, Journaleinträge und Anhänge auf beiden Seiten, prüfte, ob alle Anhänge auf der Festplatte vorhanden waren, listete die registrierten Plugin-Versionen der Anwendung auf und bestätigte, dass keine Datenbankmigrationen ausstanden. Das ist eine mühsame Checkliste, und genau solche Checklisten werden nachmittags gerne mal übersprungen.
Was dem System noch fehlte, war die Fähigkeit, Konsequenzen abzuschätzen. Ein Neustart eines VDSM-Gasts, um Speicherplatz hinzuzufügen, bedeutete, eine laufende Website offline zu nehmen – eine Entscheidung, die hinterfragt und nicht einfach vorausgesetzt werden sollte. Dasselbe gilt für das Löschen von Daten. Betrachten Sie den Assistenten als äußerst schnelle und zuverlässige Helfer, die unermüdlich prüfen, und führen Sie unwiderrufliche Aktionen selbst durch.
Wo finde ich weitere offizielle Ressourcen?
Virtual Machine Manager, das Paket, das alle VDSM-Gastsysteme hostet, ist seit Jahren in DSM integriert und umfassend dokumentiert. Diese drei Anleitungen beschreiben die Installation des Pakets, die Erstellung eines Gastsystems und die allgemeine Struktur der Benutzeroberfläche.
Grenzen, die Sie kennen sollten, bevor Sie VDSM die Produktion anvertrauen
Erstens ist der Arbeitsspeicher viel häufiger der limitierende Faktor als die CPU. Unser Zielsystem verfügte über 2 GB Arbeitsspeicher und nutzte bereits den Auslagerungsspeicher, bevor wir weitere Anwendungen hinzufügten. Eine zweite Anwendung und eine zweite Datenbank benötigten zusätzlich etwa 480 MB, daher erhöhten wir den Arbeitsspeicher auf 4 GB. Prüfen Sie den freien Arbeitsspeicher auf dem Zielsystem, bevor Sie den Umzug planen, nicht erst danach.
Zweitens: Eine virtuelle VDSM-Festplatte wächst, verkleinert sich aber nie. Bei Überdimensionierung lässt sich der Speicherplatz nicht durch Bearbeiten des entsprechenden Feldes zurückgewinnen; die einzige Möglichkeit, eine kleinere Festplatte zu erhalten, besteht darin, ein neues Gastsystem zu erstellen und dorthin zu migrieren. Wählen Sie eine Größe, mit der Sie auch in zwei Jahren noch zufrieden sind.
Third, licensing. One guest is included with the NAS; every additional guest needs its own Virtual DSM licence. Clustering across several NAS units, live migration and the larger snapshot retention are VMM Pro features rather than standard ones. If your consolidation plan involves splitting one busy guest into four tidy ones, price that before you design it.
Viertens, zu vermeidende Szenarien: Speichern Sie die virtuelle Festplatte eines Gastsystems nicht auf demselben physischen Datenträger wie Ihre Backups und bezeichnen Sie dies nicht als Backup. Betreiben Sie keine Datenbank mit hohem, anhaltendem Schreibaufkommen auf einem Gastsystem, das sich Festplatten mit einem stark ausgelasteten Dateiserver teilt. Verwenden Sie VDSM nicht als Ersatz für einen zweiten Rechner, denn wenn der Host ausfällt, fallen alle Gastsysteme gleichzeitig aus. Und migrieren Sie keinen Container, den Sie nie überprüft haben, aus den oben im Abschnitt zur Compose-Datei genannten Gründen.
Fifth, credentials. A migration touches database passwords, environment variables and configuration files. Ours moved a compose file holding plaintext database credentials, so it was placed deliberately outside the web server’s document root. A compose file left inside a document root is downloadable by anyone who guesses the filename, and that is a depressingly common way credentials leak. If you let an assistant script a migration, read where it is writing files. And when the job is done, disable the account you created for the assistant rather than leaving a live administrator login behind.
Sixth, snapshot before you touch anything. A VDSM snapshot in Virtual Machine Manager takes seconds, is available without the Pro licence, and turns almost every mistake in this article into a two-minute rollback. It is the one step worth adding to any migration runbook, whether a human or an assistant is doing the typing.
Abschließend gilt: Prüfen statt annehmen. Alle Aussagen in diesem Artikel wurden anhand des laufenden Systems überprüft: Tabellenanzahl auf beiden Seiten, Vorhandensein von Anhangsdateien auf der Festplatte, von der Anwendung registrierte Plugin-Versionen, keine ausstehenden Migrationen und ein vollständiger Neustart des Stacks, um die automatische Wiederherstellung zu bestätigen. Eine Migration ist nicht abgeschlossen, sobald der Dienst antwortet. Sie ist erst abgeschlossen, wenn nachgewiesen ist, dass sie einen Neustart des VDSM-Gastsystems übersteht und die alte Kopie keine Schreibvorgänge mehr akzeptiert.
A note on where to get those licences, since it is what we do: SynoPower Club sells Synology licences with round-the-clock instant key delivery. The two that matter here are the Virtual DSM licence, which you need for every guest past the free one, and the VMM Pro licence if you want clustering, live migration or 255 snapshots per guest instead of 32. The full licence catalogue covers Surveillance Station and MailPlus as well.
Verweise
- SynoPower Club, Unsere Synology NAS-Ratgeber und Kameratests
- Synology — Virtual Machine Manager, die offizielle Übersicht des Pakets, das VDSM ausführt
- Synology Wissenszentrum — Virtual Machine Manager Hilfe, Gästeerstellung und Einstellungen
- Docker – Docker-Container-Commit, der Befehl hinter Schritt eins
- Docker – Docker-Image speichern, wurde verwendet, um das Bild zwischen den Gästen zu streamen
Häufig gestellte Fragen
Ist Synology VDSM kostenlos?
Jedes NAS, das Virtual Machine Manager unterstützt, enthält eine kostenlose Virtual DSM-Lizenz, die für den dauerhaften Betrieb eines einzelnen Gastsystems ausreicht. Für jedes weitere Gastsystem ist eine kostenpflichtige Lizenz erforderlich. Das Virtual Machine Manager-Paket selbst ist kostenlos im Paketzentrum erhältlich.
Kann Synology VDSM Docker-Container ausführen?
Ja. Ein Virtual DSM-Gastsystem ist eine vollständige DSM-Installation. Daher installieren Sie den Container Manager über das Paketzentrum genau wie auf einem physischen NAS. Die Migration in diesem Artikel verschob einen Zwei-Container-Stack zwischen zwei Gastsystemen, ohne die Container selbst zu verändern.
Do I need to shut the guest down to enlarge a virtual disk?
No, and you do not need to reinstall anything either. Raise the size in the Storage tab of Virtual Machine Manager and the disk grows while the guest keeps running. DSM inside the guest expands the partition and filesystem on its own, so there is no Storage Manager wizard and no volume to rebuild. The only rule is that a virtual disk can grow but never shrink.
Wie schneidet Synology VDSM im Vergleich zur Ausführung von Docker auf dem Host-NAS ab?
Das Ausführen von Containern direkt auf dem Host ist einfacher und etwas schneller, da keine Virtualisierungsschicht vorhanden ist. Ein Gastsystem bietet Ihnen stattdessen Isolation: eine feste Speicherbegrenzung, ein separates DSM zum Neustarten und einen kompletten Server, von dem Sie Snapshots erstellen oder den Sie verschieben können. Verwenden Sie den Host für Anwendungen, die immer funktionieren müssen, und Gastsysteme für solche, die Sie absichtlich testen möchten.
Should I take a VDSM snapshot before migrating?
Yes, and it is free. Snapshots are included in the standard edition of Virtual Machine Manager, which keeps up to 32 per guest, and a snapshot captures the whole machine rather than one folder. Take one on the source and one on the destination before you start. This matters even more when an AI assistant is driving the shell: keep the source intact until the destination is verified, require confirmation before anything irreversible, and read what is about to run rather than approving on reflex.
Was geschieht mit Dateien, die in einem Container ohne Volume installiert sind?
Sie existieren nur in der beschreibbaren Schicht des Containers und verschwinden, sobald dieser aus seinem Image neu erstellt wird. Führen Sie `docker diff` für einen Container aus, bevor Sie ihn migrieren. Bei einer großen Anzahl von Änderungen speichern Sie den Container in einem Image und migrieren Sie dieses Image, anstatt ein neues aus der Registry zu laden.
Wie lange dauert eine solche Migration?
Die Übertragung eines kleinen Datenstapels, inklusive Verifizierung, dauerte etwa 35 Minuten. Der eigentliche Transfer eines 366 MB großen komprimierten Images über ein Gigabit-LAN dauerte ungefähr eine Minute. Der größte Teil der Zeit entfällt auf die Überprüfung des Quellcodes und des Ergebnisses – dieser Schritt sollte sorgfältig durchgeführt werden.
Kann ich einen Synology VDSM-Gast zwischen NAS-Geräten verschieben?
Ja. Virtual Machine Manager kann einen Gast auf ein anderes NAS im selben Cluster migrieren oder replizieren. Dies ist eine andere und oft bessere Lösung als die Migration der darin enthaltenen Container. Das Verschieben der Container, wie wir es hier getan haben, ist sinnvoll, wenn Sie zwei Gastsysteme zu einem zusammenführen möchten, anstatt ein komplettes Gastsystem zu verschieben.