Oracle VirtualBox: Bisher funktionierende VMs in neuem PC nutzen

[Clemens]

In einem außergewöhnlich hilfreichen Thread über die Frage, wie ich nach einem Blitzschaden am effizientesten einen neuen PC mit den gleichen Programmen und Einstellungen aufbauen könnte, kamen gegen Ende die Schwierigkeiten mit der VirtualBox und den bisherigen VMs zur Sprache.

Der Betrieb der VirtualBox mit Win-7 als VM und einer Win-XP-Version sind sehr wichtig für mich.

Voraussetzungen:
Aktuell habe ich jedenfalls sicher gestellt, dass der neue PC im BIOS eine aktivierte Virtualisierung hat. (Bei der Manjaro-Installation war diese Virtualisierung noch nicht aktiviert!!! Vielleicht hätte sie schon da aktiviert sein müssen???)

Da diese BIOS-Einstellung (Virtualisierung) eventuell Einfluss darauf hat, wie sich das komplette VirtualBox-Paket verhält, habe ich es nach der korrigierten BIOS-Einstellung mit allen Komponenten neu installiert.

Natürlich habe ich auch darauf geachtet, dass es die zueinander und zum Kernel passenden Komponenten sind.

Gemäß des oben erwähnten Threads habe ich Manjaro auf der ersten NVME installiert und die Einstellungs und Konfigurationsdateien, bei denen das zulässig ist, allesamt auf die zweite NVME mit symbolischen Links verlinkt. Dies gilt auch für das Verzeichnis /.config/VirtualBox/

Nun habe ich folgende Schwierigkeiten:
Ich starte den VBox-Manager (GUI), klicke dann auf "Hinzufügen" und wähle eine der vier VMs aus, die ich vom früheren PC habe. Alle diese VMs wurden korrekt herunter gefahren und keine hat im Snapshot-Verzeichnis einen "Schuss" abgelegt.
Kaum habe ich die ausgewählte .vbox-Datei ausgewählt und bestätigt, friert der VBox-Manager ein. Ich muss ihn in der Taskleiste mit "Schließen" beenden. Danach lässt er sich gar nicht mehr starten. Er lässt sich erst wieder starten, nachdem ich alle Dateien aus dem Verzeichnis /.config/VirtualBox/ gelöscht habe.

Fehlersuche:
Zunächst habe ich den Inhalt aller Dateien im Verzeichnis /.config/VirtualBox/ überprüft und ich fand außer in der VBoxSVC keine Fehler oder falsche Angaben über das System und seine Ausstattung.
Ich habe dann genau die Meldungen in der Datei VBoxSVC.log beobachtet, die in dem Verzeichnis /.config/VirtualBox/ schon beim Start des VBox-Managers angelegt wird. Hier die kritischen Zeilen aus dem Logfile mitsamt kurzem Kommentar, wann welche Zeilen / Meldungen dazu kamen:

Code: Alles auswählen

VBoxSVC.log vor Installation einer VM - nur nach Start des VBox-Managers:

19 00:00:00.017092 DCon01   NetIfAdpCtlOut: VBoxNetAdpCtl: Error while retrieving link speed for wlp197s0f3u2: VBoxNetAdpCtl: ioctl failed: Operation not supported

33 00:00:00.019987 DCon01   Failed to open "/dev/vboxdrvu", errno=2, rc=VERR_VM_DRIVER_NOT_INSTALLED

35 00:00:00.025260 DCon01   OCI: Local config file '/home/clemens/.config/VirtualBox/oci_config' does not exist
36 00:00:00.025280 DCon01   OCI: Original config file '/home/clemens/.oci/config' does not exist
37 00:00:00.025284 DCon01   OCI: Reading profiles finished with status NS_OK
38 00:00:00.025288 DCon01   ExtPack: Created cloud provider 'OCI' (hrc=NS_OK)
39 00:00:00.025308 DCon01   VirtualBox: object created

50 00:08:44.676732 USBPROXY USBProxyBackendLinux: Device 152d:0578 (sysfs:/sys/devices/pci0000:00/0000:00:08.1/0000:c5:00.3/usb2/2-1/2-1.1//device:/dev/vboxusb/002/003) isn't accessible. giving udev a few seconds to fix this...
51 00:45:00.506619 USBPROXY USBProxyBackendLinux: Device 0409:0486 (sysfs:/sys/devices/pci0000:00/0000:00:08.3/0000:c7:00.4/usb7/7-1/7-1.4/7-1.4.4/7-1.4.4.4//device:/dev/vboxusb/007/010) isn't accessible. giving udev a few seconds to fix this..

Dann Versuch, den Klon Win7-VM mittels "Hinzugügen" als VM zu integrieren. Es kamen folgende Zeilen hinzu, bis der VBox-Manager einfror:

00:55:51.918804 DCon53   Platform architecture set to 'x86'
00:55:51.919234 DCon53   Loading settings file "/home/clemens/VirtualBox VMs/Klon Win-7 HomePremium/Klon Win-7 HomePremium.vbox" with version "1.19-linux"
00:55:51.919445 DCon53   Platform architecture set to 'x86'
00:55:51.920129 DCon53   ERROR [COM]: aRC=VBOX_E_OBJECT_NOT_FOUND (0x80bb0001) aIID={d644ad1e-c501-4fc7-9ab6-aa6d763bc540} aComponent={VirtualBoxWrap} aText={Could not find a registered machine with UUID {9baa0ade-06cb-4052-a04d-c593b75c7222}}, preserve=false aResultDetail=0
00:55:51.921244 DCon57   Saving settings file "/home/clemens/.config/VirtualBox/VirtualBox.xml" with version "1.12-linux"
00:55:51.926573 DCon57   Finished saving settings file "/home/clemens/.config/VirtualBox/VirtualBox.xml"

Aus dem eingefrorenen Zustand wurde durch das "Schließen"-Kommando VBox-Manager wieder geschlossen. Danach wurden folgende zeilen angefügt:

00:57:05.438098 main     VirtualBox: object deletion starts
00:57:05.438156 main     ERROR [COM]: aRC=VBOX_E_OBJECT_IN_USE (0x80bb000c) aIID={7d510820-a678-4730-a862-818dcd3fbed0} aComponent={MediumWrap} aText={Medium '/home/clemens/VirtualBox VMs/Klon Win-7 HomePremium/Win-7 HomePremium 64-bit.vdi' cannot be closed because it is still attached to 1 virtual machines}, preserve=false aResultDetail=0
00:57:05.438687 main     HostDnsMonitor: shutting down ...
00:57:05.451737 main     HostDnsMonitor: shut down
00:57:05.463949 Watcher  ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005) aIID={d644ad1e-c501-4fc7-9ab6-aa6d763bc540} aComponent={VirtualBoxWrap} aText={The object is not ready}, preserve=false aResultDetail=0
00:57:05.464164 main     VirtualBox: object deleted

Zusammengefasst scheint es Probleme mit dem Netzwerkadapter und den USB-Anschlüssen zu geben sowie mit den UUIDs der VMs. Ob die Meldung:

Code: Alles auswählen

  Failed to open "/dev/vboxdrvu", errno=2, rc=VERR_VM_DRIVER_NOT_INSTALLED

relevant ist, kann ich nicht einschätzen. Eigentlich sollte sie vorhanden sein, wurde aber weder auf der bisherigen Systemplatte noch auf der jetzigen installiert / angelegt! Vom 13. Dez. 2013 gab es bei Arch-Linux dazu eine Meldung: https://bugs.archlinux.org/task/38314

Beim Versuch, die VM einzubinden, kam es zur Meldung:

Code: Alles auswählen

 ERROR [COM]: aRC=VBOX_E_OBJECT_NOT_FOUND

mitsamt einer UUID. Ich vermute, dass es hier um eine ext. Festplatte geht, die leider am vergangenen Freitag an einem Motorschaden gestorben ist. Die wurde immer in meine VMs als Speicher für besondere Daten integriert. Und weil sie jetzt "abwesend" ist, kommt es zu der Meldung. Gemäß dieser KI-basierten Aussage neigt VirtualBox dazu, die UUID der zusätzlichen Platte als UUID der eigentlichen VM-Datei, der .vdi-Datei anzusehen. Die hat aber eine andere UUID. Und schon kann die .vdi-VM nicht eingehängt werden!!!

Zum Schluss wird gemeldet, dass der Zugriff (vermutlich zum Herunter-fahren) nicht zulässig ist, weil das Gerät (die VM) noch nicht dazu bereit ist.

Anhängend die Dateien VBoxSVC.log und VirtualBox.xml als ZIP und die .vbox-Datei, die zu der VM gehört und zusammen mit der .vdi-Datei in einem Verzeichnis liegt.

Meine Bitte:
Vielleicht hat ja jemand eine Idee zur Lösung des Problems? – Ich bin jedenfalls nach all den bemühungen mit meinen Fähigkeiten am Ende.

[Clemens]

Zur Virtualisierung erhielt ich gerade folgende Auskunft eines Bekannten aus der IT-Branche:

die Virtualisierung muss im BIOS vor der Installation von Linux aktiviert sein, um wirksam zu sein. Dies ist besonders wichtig, wenn Sie virtuelle Maschinen oder Funktionen wie Hyper-V verwenden möchten.
Unter Windows können Sie überprüfen, ob die Virtualisierung aktiviert ist, indem Sie den Task-Manager öffnen und im Reiter „Leistung“ unter CPU prüfen.
Falls die Virtualisierung deaktiviert ist, müssen Sie vor der Installation eines Betriebssystems das BIOS starten und die Funktion dort aktivieren. Die genaue Vorgehensweise variiert je nach Hersteller, aber in der Regel finden Sie die Einstellung unter „Advanced“ → „CPU Configuration“ → „Intel Virtualization Technology“ oder bei AMD „AMD-V” oder „SVM-Mode” oder „IOMMU”.

OK, ich werde also alles neu installieren müssen! Welche Freude! Aber immerhin kann die Datenplatte so bleiben.

Nun stellt sich aber die Frage, ob die am Anfang beschriebenen Fehler wirklich auf eine im Betriebssystem fehlende Virtualisierung zurück zu führen sind. Ich glaube das eher nicht.

[gosia]

Hallo Clemens,
völlig theoretisch, weil ich keine Virtualbox benutze, aber zu dieser Fehlermeldung

Code: Alles auswählen

ERROR [COM]: aRC=VBOX_E_OBJECT_NOT_FOUND

gibt es hier Lösungsansätze.
https://www.php.cn/de/faq/720975.html
Der Punkt 3 dort bezieht sich zwar auf Windows, aber die vorherigen Punkte bringen vielleicht weiter.

viele Grüsse gosia

[gosia]

Hallo Clemens,

die Virtualisierung muss im BIOS vor der Installation von Linux aktiviert sein, um wirksam zu sein

ich widerspreche IT-Experten ungern, aber das habe ich so noch nie gesehen oder gelesen. Alle Anleitungen die ich gelesen habe, gehen lediglich davon aus, dass die Virtualisierung im BIOS aktiviert sein muss, aber nicht, dass dies vor der Installation von Linux geschehen muss. Dass natürlich nach einem "einschalten" der BIOS-Virtualisierung ein Neustart erfolgen muss setze ich allerdings einfach mal als selbstverständlich vorraus.

viele Grüsse gosia

[Clemens]

Dass man die Virtualisierung aktivieren muss, bevor man das Betriebssystem installiert, damit die Virtualisierung wirklich wirkt, das hat mir die KI geflüstert. Die taugt wohl nix. – Denn inzwischen bekam ich im Administrator.de-Forum ein Zitat aus einer technischen Anleitung zum AMI-BIOS. Dort wird erklärt, dass der Menüpunkt SVM Lock wenn "enabled" verhindert, dass irgend eine Software die Virtualisierung wieder deaktivieren kann. Oder auch aktivieren kann.
Wenn das aber möglich ist, dann kann die KI-Behauptung betr. vor Installation des Betriebssystems nicht stimmen. KI fantasiert eben.... manchmal.


Das kann bei mir kein UUID-Konflikt zwischen zwei .vdi-Imgadateien sein, denn der VBox-Manager hängt sich ja bereits auf, wenn nur eine VM mit "Hinzufügen" eingebunden wird.

Das was ich beschrieb, stammte aus einem anderen Forum. Dort wurde behauptet, dass manche VM so konfiguriert sei, dass sie z.B. auf eine USB-Festplatte zugreifen darf. Diese externe Festplatte hat natürlich auch eine UUID.
Wenn diese Festplatte nun aber fehlt während die .vdi-Datei eingebunden werden soll, so findet der VBox-Manager diese externe Platte nicht. Und nur in diesem Fall soll es ab und zu schon vorgekommen sein, dass der VBox-Manager die UUID der externen Festplatte als diejenige der .vdi-Imagedatei angesehen hat. Tja und die hat natürlich eine andere UUID und dann kann er sie nicht einbinden, was zu der Fehlermeldung führt.

Ob das hier bei mir der Fall ist, wage ich mal zu bezweifeln. Allerdings haben beide Win-7-VMs Zugriff auf eine externe Festplatte. Das ist die, die jetzt defekt wurde. Ich habe aber noch eine Manjaro-VM, eine Win-XP und eine DOS-VM. Diese haben keine externen Festplatten zugeordnet bekommen.

Zur Klarheit: Wenn ich "externe USB-Festplatten" angebe, auf die eine VM Zugriff hat, dann ist das wie ein "Shared-Folder".

[charly700]

KI fantasiert eben.... manchmal.

Und wer sagt dir dann, wann sie gerade Halluziniert?

[Clemens]

@charly
hatte ich doch geschrieben: wenn ich entgegen gesetzte Informationen aus zuverlässigen Quellen erhalte wie z.B. das Admin-Forum und die Info direkt vom BIOS Hersteller AMI und auch die gleiche Info im Elektronik-Kompendium, dann ist die Wahrscheinlichkeit sehr hoch, dass die KI Unsinn erzählt hat.

Biss selbst denken war noch immer von Vorteil. :-)

[gosia]

Hallo Clemens,
im Prinzip bin ich mangels Kenntnis raus. Aber

der VBox-Manager hängt sich ja bereits auf, wenn nur eine VM mit "Hinzufügen" eingebunden wird.

das überzeugt mich noch nicht ganz.
Wenn ich die Klon Win-7 HomePremium.vbox öffne, so finde ich durchaus zweimal die uuid a4a5f509-2786-431f-9252-daac2621f784

Code: Alles auswählen

<HardDisks>
  <HardDisk uuid="{a4a5f509-2786-431f-9252-daac2621f784}" location="Win-7 HomePremium 64-bit.vdi" format="VDI" type="Normal"/>
</HardDisks>
...
<AttachedDevice nonrotational="true" type="HardDisk" hotpluggable="false" port="0" device="0">
  <Image uuid="{a4a5f509-2786-431f-9252-daac2621f784}"/>
</AttachedDevice>

das kann durchaus richtig sein, aber da müsste man sich näher mit der Syntax der vbox-Datei beschäftigen.
Es kann aber auch sein, dass Du versuchst die VM neu einzubinden, Virtualbox versucht sie in der vbox-Datei zu registrieren, und stellt fest "Moment mal, solch eine UUID gibt es doch schon - ist schon eingehängt (attached)" -> Abbruch.
Passt doch zu

Code: Alles auswählen

cannot be closed because it is still attached to 1 virtual machines

So habe ich den Artikel verstanden.

Allerdings haben beide Win-7-VMs Zugriff auf eine externe Festplatte. Das ist die, die jetzt defekt wurde.

defekt = nicht erreichbar. Da wäre es doch interessant, welche UUID hatte diese externe FP und taucht die in der vbox-Datei auf?
Reine Spekulation von mir (vielleicht habe ich mich da auch etwas verrannt), aber in dieser Richtung würde ich mal nachforschen.

viele Grüsse gosia

[Clemens]

Vielen Dank, dass du versuchst, mir weiter zu helfen. Die vbox-Datei, in der diese UUID zwei mal auftaucht, ist aber genau so auf den anderen PCs vorhanden und macht keinerlei Schwierigkeiten.

Ich habe angesichts der Komplexität und Spezialität des Themas nun die Story in das VirtualBox-Forum eingebracht. Dort habe ich einleitend noch mal beschrieben, wie es zu dem jetzigen Problem kam:

Auf drei Laptops und zwei PCs habe ich jeweils immer die gleichen VMs in VirtualBox laufen und nie Probleme gehabt (außer ab und zu mit der Aktualisierung der GuestAdditions). Als Host-System nutze ich immer Manjaro-Linux. Die VMs sind zwei Win-7 Maschinen, eine Win-XP-Maschine, eine Manjaro-Linux-Maschine und eine DOS-Maschine.
Jedes Mal, wenn ich solch einen PC eingerichtet hatte, brauchte ich lediglich die Verzeichnisse, die die VMs beinhalten, hinein zu kopieren und im VirtualBox-Manager mit "Hinzufügen" die VMs ansprechbar machen. Das ist immer auf Anhieb erfolgreich gelungen, obwohl die Hardware sich deutlich unterschieden hat. Das hat mich jedes Mal sehr erstaunt, weil in den .vbox-Dateien der reinkopierten VMs doch völlig unpassende Hardware-Parameter stehen.
Natürlich musste ich nach erfolgreichem Einbinden der VMs diese Parameter im VBox-Manager korrigieren. Aber die falschen Parameter haben nie zu den jetzt auftretenden Problemen geführt!

Also: Die VMs haben bisher auf verschiedenen Plattformen (aber nur Intel) immer einwandfrei funktioniert! Nur jetzt auf einmal geht's nicht mehr.

Es gibt ein Kommandozeilen-Tool, den VBoxManager. Mit dem habe ich versucht, die UUID des Image heraus zu bekommen, um es mit den Angaben in der vbox-Datei und den Meldungen in der VBoxSVC.log vergleichen zu können. Hat aber nix gebracht, weil ich die Begriffe nicht verstehe. So finde ich nach Eingabe des Befehls:

Code: Alles auswählen

sudo VBoxManage internalcommands dumphdinfo "Win-7 HomePremium 64-bit.vdi

zwei UUID-Angaben, die mir anscheinend nicht weiter helfen:
Header: uuidCreation={64d490dc-92bd-4a58-84b1-42f8884d6836}
Header: uuidModification={5ebf5b50-dfb9-445a-95dc-f9fc85b3a64d}

Übrigens kann man die UUID einer VDI-Datei tatsächlich ändern mit:

Code: Alles auswählen

VBoxManage internalcommands sethduuid IMAGENAME.vdi

Und jetzt bin ich gespannt darauf, ob ich hilfreiche Antworten im VBOx-Forum erhalte. Es gibt glücklicher Weise auch eine deutsche Sektion davon. :-)

[Clemens]

Es gibt Neuigkeiten: Ich habe gerade VirtualBox deinstalliert und Qemu installiert, Dann habe ich es geschafft, eine der in VirtualBox nicht funktionierenden VMs erfolgreich in das qcow2-Format zu konvertieren und dann in Qemu zu starten.
Mit dem Start von Windows erschien ein Installations-Fenster, in dem rasend schnell spezifische AMD-Treiber und -Module geladen und installiert wurden. Damit wurde die Windows-VM automatisch an das AMD-System angepasst. Nach einem reboot der Windows-7-VM lief diese einwandfrei unter Qemu.
Einzige Einschränkung: Die Geschwindigkeit speziell von grafik-intensiven Vorgängen wie z.B. dem Verschieben von Fenstern auf dem Desktop verlief äußerst ruckelig. Zudem schien die gesamte Darstellung von Windows irgendwie unscharf. Und ich konnte keine Bildschirmauflösung einstellen, die das Vollformat meines Monitors ausgenutzt hätte.

Nun sah ich, dass es mit Qemu möglich ist, die VM aus dem qcow2-Format wieder in eine vdi umzuwandeln. Da ja jetzt die wichtigsten AMD-Treiber in meiner Windows-VM dank Qemu installiert sind, müsste es möglich sein, diese dann in VirtualBox erfolgreich zu starten – was ja bisher nicht gelang.

Nun frage ich hier:
Muss ich Qemu erst wieder völlig deinstallieren, bevor ich VirtualBox installiere? Oder kann ich VirtualBox parallel zu Qemu auf dem System installieren und nutzen? – Natürlich kann ich nicht beide Virtualisierungen gleichzeitig laufen lassen! Es geht nur um die Frage, ob beide parallel installiert sein können, ohne sich ins Gehege zu kommen.

Ich habe auch schon mit lsmod nach Kernel-Modulen geschaut, die evtl. von Qemu geladen werden, ohne dass Qemu schon gestartet worden ist. Ich fand:

Code: Alles auswählen

kvm_amd               241664  0
...
kvm                  1380352  1 kvm_amd
...
irqbypass              12288  1 kvm
...
ccp                   184320  1 kvm_amd

Edit:
Hier gab es 2018 mal eine umfassende Diskussion mit klaren Ergebnissen dazu:
https://askubuntu.com/questions/413511/ ... each-other

Es fragt sich aber, ob die damaligen Ergebnisse auch heute noch gültig sind. (Notfalls konvertiere ich alle meine VDI-Container mittels Qemu ins qcow2-Format, starte jede dieser Mschinen ein Mal in Qemu, um die nötigen AMD-Treiber in die VMs zu bekommen und Konvertiere dann zurück in VDI. Anschließend deinstalliere ich KVM und installiere VBox. Dort kann ich dann die konvertierten VDI als neue VMs importieren / anlegen.
Vielleicht sollte ich sicherheitshalber mit Qemu auch ISO-Formate konvertieren, da diese evtl. leichte als neue VM in VBox anzulegen gehen.

Ich schreib dann wieder hier über die Ergebnisse. Wenn nix davon funktionieren würde, denke ich, dass es dann am Zusammenspiel von VBox mit dem neuen PC liegt. Dann würde ich den zurück geben (Amazon).