zar, das Wichtigste zuerst… verschieben Sie niemals einen Rechner, der sich im gesicherten Zustand befindet, vor dem Verschieben müssen Sie den Gast herunterfahren, nicht nur den Zustand speichern…
Stellen Sie außerdem sicher, dass Sie auf beiden Hosts die gleiche 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, die SHARED-Ordnerkonfiguration auf der VirtualBOX zu löschen, bevor die Maschine verschoben wird, und sie dann auf korrekte Art und Weise neu zu erstellen… sehr wichtig, wenn die Hosts unterschiedliche Betriebssysteme (Windows-/Linux-Hosts) sind…
Und nur als Randbemerkung… ich benutze immer unveränderliche Festplatten-VDI-Dateien sowohl für Betriebssysteme als auch für Daten-VDIs (auf diese Weise kann dieselbe DATA-VDI für mehr als einen Gast verwendet werden), ein spezieller Trick für 4GiB-Pagefile. sys
Der letzte Teil, die Wiederverwendung einer unveränderlichen VDI-Datei, macht die Sache etwas schwieriger.
Um den Fehler in Aktion zu sehen:
- Erstellen Sie eine unveränderliche VDI (wie die, die ich für pagefile.sys verwende)
- Erstellen Sie zwei oder drei VMs auf VirtualBOX
- Schieben Sie eine davon an den Anfang der Liste (nur um zu vermeiden, dass eine von Ihnen beschädigt wird)
- Sichern Sie die . vbox-Dateien von jedem der Rechner, die Sie erstellt haben (um sie nach dem BUG zu vergleichen)
- Hängen Sie diese unveränderliche VDI an mehr als einen dieser Rechner an (mit Ausnahme desjenigen, der ganz oben in der Liste steht)
- Sehen Sie sich nun die .vbox-Datei des Rechners an, der ganz oben in der Liste steht
Dieser Rechner wurde bearbeitet, er hat Verweise auf die anderen Rechner mit der unveränderlichen VDI.
Also ist das BUG: Wenn man einen Rechner bearbeitet und eine unveränderliche VDI hinzufügt, die von einem anderen Rechner verwendet wird, wirkt sich das auf den Rechner am Anfang der Liste aus.
Warum zum Teufel verwende ich dieselbe 4GiB-VDI auf allen Windows-Maschinen wieder? Ganz einfach, es handelt sich um eine MBR-Platte mit einer FAT32-Partition, auf der ich die Datei pagefile.sys abgelegt habe, da sie nicht veränderbar ist, erstellen alle virtuellen Maschinen eine Datei in ihrem Snapshot-Ordner, in der sie die Änderungen speichern, die beim nächsten Start verloren gehen. Ich brauche also nicht 4GiB für jeden Gast, der auf der Host-Platte gespeichert ist, sondern nur eine… auf diese Weise spare ich eine Menge GiB, da ich mehr als 20 verschiedene Fenster zum Testen von Anwendungen habe, die ich für meine eigenen 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), ich bekomme eine Menge, eine Menge Gast… also auf allen von ihnen teile ich die unveränderliche 4GiB VDI für den virtuellen RAM (pagefile.sys).
Und wenn Sie das BUG weitergehen lassen, versuchen Sie, eine dieser Maschinen auf einen anderen VirtualBOX-Host zu verschieben (denken Sie daran, dass es nur virtuelle Maschinen mit einer Konfiguration darauf sind und noch kein Gast darauf installiert ist), werden Sie sehen, dass VirtualBox Ihnen nicht erlaubt, sie hinzuzufügen, da einige VDIs fehlen (es ist FALSCH und WAHR, es ist so, dass diese erste Maschine die Verweise auf solche VDIs enthält, als ob sie auf der richtigen Maschine wäre).
Vergleichen Sie nun die . VBOX-Dateien von allen mit previos BackUp… beachten Sie, wie eine davon falsch modifiziert wurde?… ja, es ist die ganz oben auf der Liste…
Nun, dieses BUG wurde vor einigen Jahren an VirtualBOX informiert, sie können es immer noch nicht reparieren… und es verursacht eine Menge, eine Menge Probleme…
Noch mehr, wenn Sie die oberste auf den virtuellen Maschinen in eine niedrigere Position verschieben, VirtualBox schließen und neu starten… werden Sie feststellen, dass einige Maschinen beschädigt sind und nicht gestartet werden können… ja, die erste auf der Liste muss in einer anderen Form behandelt werden, wenn Sie nicht viel Ärger bekommen wollen…
Es ist ein wirklich schlimmes BUG, das mich viele Tage gekostet hat zu entdecken (vor einigen Jahren), ich lerne es auf die harte Tour!
Ich hatte es überwunden, indem ich eine Maschine hatte, die ich genannt hatte:
Sie 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 gemeinsam nutze.
Nun, wenn ich die .VBOX-Datei öffne, sehe ich darin eine Menge Zeilen im Abschnitt <MediaRegistry> <HardDisks>, eine für jede 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>
Pretty BUG, seit Jahren nicht mehr gelöst.
Nun, um solche Maschinen zu verschieben… müssen Sie die . VBOX-Dateien manuell bearbeiten, um alle Verweise auf solche Datenträger auf den neuen Host auf dem ersten Rechner (demjenigen, der ganz oben in der Liste steht) zu setzen, bevor Sie die .VBOX-Dateien zur Liste hinzufügen, so dass VirtualBOX beim Hinzufügen die Verweise auf die fehlenden VDIs hat (die durch das große BUG fehlen).
Das passiert, weil VirtualBOX jedes Mal, wenn Sie eine VDI anschließen, die auf einem anderen Rechner verwendet wird, zwei Rechner aktualisiert .
Ich bin mir nicht ganz sicher, was passieren würde, wenn auf der Liste der erste Rechner keine so übliche VDI angehängt ist… Besser, es nicht zu versuchen, wenn ich das sehe…
Die Migration zu einem anderen HOST ist also viel komplizierter als es scheint, weil die Implementierung in den .VBOX-Dateien sehr schlecht istInterne Struktur und wegen der wirklich großen BUGs, wenn VirtualBOX sie editiert
schlägt fehl:
- Interne Struktur (XML) hängt vom HOST (Windows oder Linux) ab
- Editieren einer Maschine kann eine andere Maschine ändern, nicht nur die, die gerade editiert wird
- … was noch ?
Brauche mehr… ich migriere immer Maschinen, die dies tun (und hatte kein Problem, niemals):
- Beachten Sie die Liste aller Maschinen (Reihenfolge, Gruppierung usw.):
- Notieren Sie sich den ersten auf der Liste (mit seiner gesamten Konfiguration)
- Notieren Sie sich alle Eigenschaften der Rechner, die ich auf einen anderen Host verschieben möchte
- Kopieren Sie die .vbox-Dateien als .txt-Dateien (die ganz oben in der Liste + alle Rechner, die ich migrieren möchte)
- Erstellen Sie alle Rechner (und lassen Sie einen speziellen Rechner ganz oben in der Liste) innerhalb von VirtualBox auf dem neuen Host neu
- Schließen Sie VirtualBox auf dem neuen Host
- vergleichen Sie die alten .txt- mit den neuen .vbox-Dateien und kopieren Sie einige Teile von .txt nach .vbox auf menschliche Art und Weise, nicht nur per Copy&Paste
- Öffnen Sie VirtualBox und hängen Sie alle VDIs in der richtigen Reihenfolge an
- Schließen Sie VirtualBox wieder auf dem neuen Host
- vergleichen Sie die alte .txt mit den neuen .vbox-Dateien und ‘reparieren’ Sie einige Teile von .txt nach .vbox auf menschliche Weise, nicht nur durch Copy&Paste
Alles andere (Snapshots-Ordner und VDI-Dateien) kopiere ich auf normale Weise (Dateisystem Copy&Paste).
All die harte Handarbeit wird durch die Big BUG VirtualBox verursacht: Sie editiert/verändert eine Maschine, die nicht verändert wurde, wenn Sie eine unveränderliche VDI anhängen, die auf mehr als einer Maschine verwendet wird, ansonsten würde ein einfaches Copy&Paste der .VBOX-Datei ausreichen (nach dem Fixieren von gemeinsamen Ordnerpfaden usw.).
