zar, das erste, was zuerst kommt ... Verschieben Sie niemals einen Computer, der sich im gespeicherten Zustand befindet. Vor dem Verschieben müssen Sie den Gast herunterfahren und nicht nur den Zustand speichern.
Stellen Sie außerdem sicher, dass Sie auf beiden Hosts dieselbe Version von VirtualBOX verwenden, aber nicht nur die VirtualBOX-Version, sondern auch die Version des Erweiterungspakets ... oder zumindest der neue Host hat eine höhere Version, aber niemals eine niedrigere Version auf einem der beiden Hosts.
Und schließlich habe ich es auf die harte Tour gelernt: Löschen Sie die SHARED-Ordner-Konfiguration in VirtualBOX, bevor Sie den Computer verschieben, und erstellen Sie sie dann korrekt neu ... sehr wichtig, wenn Hosts unterschiedliche Betriebssysteme sind (Windows / Linux-Hosts).
Und nur als Randnotiz ... ich benutze immer unveränderliche Festplatten-VDI-Dateien sowohl für das Betriebssystem als auch für Daten-VDIs (auf diese Weise kann dieselbe DATA-VDI für mehr als einen Gast verwendet werden), speziell für 4GiB pagefile.sys
Der letzte Teil, die Wiederverwendung einer unveränderlichen VDI-Datei, macht die Sache etwas schwieriger, VirtualBOX hat einen GROSSEN FEHLER.
So sehen Sie den Bug in Aktion:
- Erstellen Sie eine unveränderliche VDI (wie die, die ich für pagefile.sys verwende)
- Erstellen Sie zwei oder drei VMs auf VirtualBOX
- Bewegen Sie einen von ihnen an den Anfang der Liste (nur um zu vermeiden, dass einer von Ihnen beschädigt wird)
- Sichern Sie die VBOX-Dateien aller von Ihnen erstellten Computer (zum Vergleichen nach dem Auftreten des BUG).
- Verbinden Sie dieses unveränderliche VDI mit mehr als einem dieser Computer (mit Ausnahme desjenigen, der oben auf der Liste steht).
- Sehen Sie sich nun die .vbox des Rechners an, der oben in der Liste steht
Diese Maschine wurde bearbeitet, sie enthält Verweise auf die anderen Maschinen inmutable VDI.
Der BUG lautet also: Bearbeiten Sie einen Computer, indem Sie eine unveränderliche VDI hinzufügen, die von einem anderen Computer verwendet wird. Dies wirkt sich auf den Computer oben in der Liste aus.
Warum zum Teufel verwende ich dasselbe 4GiB-VDI auf allen Windows-Rechnern? Ganz einfach, es handelt sich um eine MBR-Festplatte mit einer FAT32-Partition, auf der pagefile.sys abgelegt wird, da es nicht veränderbar ist, dass alle virtuellen Maschinen eine Datei in ihrem Snapshot-Ordner erstellen, in der sie die Änderungen speichern, und die beim nächsten Start verloren gehen Ich brauche nicht 4 GB für jeden Gast, der auf der Host - Festplatte gespeichert ist, sondern nur einen. Auf diese Weise spare ich eine Menge GB, da ich mehr als 20 verschiedene Fenster zum Testen von Apps habe, die ich für mich selbst entwickle. Alle Kombinationen von (XP, Vista) , 7, 8, 8.1, 10) * (32Bits, 64Bits) * (Genau wie bei der Erstinstallation, nach jedem ServicePack, nach einem vollständigen Windows-Update), bekomme ich eine Menge, viele Gäste ... also bei allen Ich teile die unveränderliche 4GiB VDI für den virtuellen RAM (pagefile.sys).
Und wenn Sie den BUG weitergehen lassen, versuchen Sie, eine der beiden Maschinen auf einen anderen VirtualBOX-Host zu verschieben (denken Sie daran, dass es sich nur um eine virtuelle Maschine mit einer Konfiguration handelt, auf der noch kein Gast installiert ist), werden Sie feststellen, dass VirtualBox dies nicht zulässt fügen Sie sie hinzu, da einige VDIs fehlen (es ist FALSE und TRUE, es ist so, dass diese erste Maschine die Verweise auf solche VDIs enthält, die darauf beruhen, auf der richtigen Maschine zu sein).
Vergleichen Sie nun die .VBOX-Dateien aller Dateien mit den vorherigen BackUp-Dateien. Beachten Sie, dass eine Datei falsch geändert wurde. Ja, sie steht ganz oben auf der Liste.
Nun, dieser BUG wurde VirtualBOX vor einigen Jahren mitgeteilt, sie können ihn immer noch nicht beheben ... und er verursacht eine Menge, viele Probleme.
Wenn Sie außerdem die oberste auf den virtuellen Maschinen in eine niedrigere Position verschieben, schließen Sie VirtualBox und starten Sie sie neu. Dies zeigt an, dass einige Maschinen beschädigt sind und nicht gestartet werden können. Ja, die erste in der Liste muss in einer anderen Form behandelt werden, wenn Sie nicht viel Ärger bekommen möchten.
Es ist ein wirklich schlimmer BUG, für dessen Entdeckung ich viele Tage gebraucht habe (vor einigen Jahren). Ich lerne es auf die harte Tour!
Ich hatte es überwunden, indem ich eine Maschine hatte, die ich angerufen hatte:
Es hat eine leere Konfiguration und nur eine VDI, ja, Sie haben Recht, Sie haben es erraten, die unveränderliche VDI, die ich für alle anderen virtuellen Maschinen teile.
Nun, wenn ich die .VBOX-Datei öffne, sehe ich darin viele Zeilen in dem <MediaRegistry> <HardDisks>Abschnitt, eine pro Maschine, auf der ich diese unveränderliche VDI verwende ... nur als Beispiel (ich entferne private Daten):
<MediaRegistry>
<HardDisks>
<HardDisk uuid="...UUID..." location="D:\VDIs\_Virtual_Memory_.vdi" format="VDI" type="Immutable">
<HardDisk uuid="{...UUID...}" location="Snapshots\{...UUID...}.vdi" format="VDI" autoReset="true"/>
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows001 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows002 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows003 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows004 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows005 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows006 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows007 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows008 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows009 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows010 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows011 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows012 ... // This belongs to other virtual Machine
<HardDisk uuid="{...UUID...}" location="D:\VMs\Windows013 ... // This belongs to other virtual Machine
... and so on ... // This belongs to other virtual Machine
</HardDisk>
</HardDisks>
</MediaRegistry>
Ziemlich BUG, seit Jahren nicht mehr behoben.
Nun, um solche Computer zu verschieben ... müssen Sie die .VBOX-Dateien manuell bearbeiten, um alle diese Datenträgerreferenzen auf dem neuen Host auf dem ersten Computer (demjenigen, der oben in der Liste steht) abzulegen, bevor Sie die .VBOX hinzufügen Dateien zur Liste hinzufügen, sodass VirtualBOX beim Hinzufügen die Verweise auf die fehlenden VDIs (die aufgrund des großen BUGs fehlen) enthält.
Das Problem tritt auf, weil jedes Mal, wenn Sie eine VDI anschließen, die auf einem anderen Computer verwendet wird, VirtualBOX zwei VBOX-Dateien (die zu dem Computer gehört, den Sie verwenden) und die erste in der Liste aktualisiert.
Ich bin mir nicht ganz sicher, was passieren würde, wenn auf der Liste die erste nicht mit einem solchen gemeinsamen VDI versehen ist ... besser, ich versuche es nicht.
Die Migration auf einen anderen Host ist also viel komplizierter als dies aufgrund einer sehr schlechten Implementierung der internen Struktur von .VBOX-Dateien und aufgrund von wirklich großen BUGs, wenn VirtualBOX sie bearbeitet, der Fall zu sein scheint.
Schlägt fehl:
- Interne Struktur (XML) hängt vom Host ab (Windows oder Linux)
- Bearbeiten einer Maschine kann eine andere Maschine ändern, nicht nur die, die bearbeitet wird
- ... was mehr ?
Brauchen Sie mehr ... Ich migriere immer Maschinen, die dies tun (und hatte kein Problem, nie):
- Beachten Sie die Liste aller Maschinen (Reihenfolge, Gruppierung usw.)
- Notieren Sie sich den ersten in der Liste (all seine Konfiguration)
- Notieren Sie sich alle Eigenschaften von Computern, die auf einen anderen Host verschoben werden sollen
- Kopieren Sie die VBOX-Dateien als TXT-Dateien (die Datei oben in der Liste + alle Computer, die migriert werden sollen).
- Erstellen Sie alle Computer in VirtualBox auf einem neuen Host neu (und haben Sie einen speziellen oben in der Liste)
- Schließen Sie VirtualBox auf dem neuen Host
- Vergleichen Sie den alten .txt mit den neuen .vbox-Dateien und kopieren Sie einige Teile auf menschliche Weise von .txt nach .vbox, nicht nur Kopieren und Einfügen
- Öffnen Sie VirtualBox und hängen Sie alle VDIs in der richtigen Reihenfolge an
- Erneut Schließen Sie VirtualBox auf einem neuen Host
- Vergleichen Sie den alten .txt mit den neuen .vbox-Dateien und 'korrigieren' Sie einige Teile auf menschliche Weise von .txt zu .vbox, nicht nur Kopieren und Einfügen
Den Rest (Snapshots-Ordner und VDI-Dateien) kopiere ich wie gewohnt (File System Copy & Paste).
Die ganze harte manuelle Arbeit wird von der Big BUG VirtualBox verursacht: Sie bearbeitet / ändert eine Maschine, die nicht geändert wurde, wenn Sie eine unveränderliche VDI anhängen, die auf mehr als einer Maschine verwendet wird. Andernfalls würde ein einfaches Kopieren und Einfügen der .VBOX-Datei ausreichen (nach Reparieren von Pfaden für freigegebene Ordner usw.).
