ubuntuusers.de

Ich habe Euch im anderen Thread (https://forum.ubuntuusers.de/topic/netzwerk-ist-in-eine-richtung-total-langsam/) so verstanden, dass es - zumindest für mich - sinnvoll sein könnte, von VirtualBox auf KVM/QEMU umzusteigen, und will das nun einmal versuchen.

Die Installation funktioniert ja recht reibungslos, und die NICs auf dem Host sind in "Bridges" umgewandelt. Sogar der Virt-Manager auf meinem Mint-Client startet problemlos, und ich kann auf meinen Ubuntu-Host zugreifen.

Jetzt möchte ich natürlich meine bestehenden VMs portieren, finde aber nichts so richtig, wie das vonstatten geht.
Ich finde immer nur recht schnell, wie man die VDI in QCOW2 konvertiert, aber die VM hat doch auch noch andere Einstellungen: Speicher, CPUs, NICs etc.
Muss ich das alles herausschreiben und manuell in die neue VM eingeben? Oder gibt es eine Art "Portierung"?

Die zweite Frage ist dann entsprechend auch etwas komplizierter. Ich habe Install-Test-VMs, in denen gibt es für verschiedene Status (Versionen) der installierten Software passende Snapshots, und die würde ich gern "erhalten". Ich habe verstanden, dass eine Portierung der Snapshots nicht möglich ist, und deshalb die Fragen:

• Kann ich einen bestimmten Snapshot der VB-VM portieren (also nicht die MyMachine.vdi, sondern den Stand von {4711...}.vdi)?

• Kann ich später vielleicht diese Virtuelle Disk laden/einbinden und mit dem "Inhalt" eines anderen Exports überschreiben

• Das würde dann darauf hinauslaufen, dass ich meine bestehenden Snapshots aus den verschiedenen VDI nachmodelliere (von der Anzahl her überschaubar, wenn es technisch geht)

Vielen Dank für Eure Tipps!

Konvertieren der VirtualBox in eine kvm musst du mit qemu-img Die Konfiguration der VM musst du dann noch entsprechend im virt-manager machen und entsprechend die festplatten-datei auswählen

Zu der Fragen mit deinen Snapshots, ich würde ein backup von diesen erstellen z. B. ReaR und diese dann wieder herstellen oder auch halt entsprechend konvertieren

Viel erfolg

micneu schrieb:

Konvertieren der VirtualBox in eine kvm musst du mit qemu-img Die Konfiguration der VM musst du dann noch entsprechend im virt-manager machen

Ok, also wie befürchtet: Ich kann die Virtuelle Disk konvertieren, alle weiteren Einstellungen muss ich manuell machen.

micneu schrieb:

Zu der Fragen mit deinen Snapshots, ich würde ein backup von diesen erstellen z. B. ReaR und diese dann wieder herstellen oder auch halt entsprechend konvertieren

Dann könnte ich doch

• die bisherigen Snapshots nacheinander starten

• davon jeweils ein ReaR-Backup herstellen

• den ältesten Snapshot der VM als "Basis" portieren

• jeweils ein ReaR-Backup wieder herstellen

• diesen Zustand dann als neuen Snapshot speichern

Könnte das so funktionieren?

So kannst du vorgehen

PS: Keine ahnung um welche anzahl von VMs es sich handelt, du könntest dir ja auch ein script schreiben

• Auslesen der Konfiguration deine VirtualBox VM

• Und mit diesen daten dann eine neue VM in kvm anlegen (im terminal)

Ja, danke, die Portierung ist wohl klar. Aber was soll ein Script hier helfen? Meinst Du, ich sollte die vbox-Datei parsen? Der Aufwand wird sich kaum lohnen.

Mich interessiert mehr, ob mein "Algorithmus" zur Pseudo-Migration der Snapshots funktionieren könnte?

Du könntest es über

virsh snapshot-dumpxml

versuchen. Keine Ahnung, ob das so funktioniert.

PS: Beachten dass diese Methode fortgeschrittene Kenntnisse erfordert und nicht in allen Fällen problemlos funktioniert.

Für mich der Vorteil mit ReaR

• das Backup wird auf die "Neue Hardware installiert", Festplatten usw. werden angepasst und auch gleich Grub (z. b. sda –> vda)

• Du kannst gleich nach dem wiederherstellen dein Netzwerk anpassen vor dem boot

Ich sollte nicht zwei Fragen auf einmal stellen... 😎

Was soll Dein virsh-Beispiel, wozu soll das gut sein?

Also...

die Installation funktioniert ja soweit ganz problemlos, die Verwaltung kann ich sogar über meinen Mint-Client machen, und ich habe probehalber zwei VMs portiert.

Mit der virtualisierten alten OPNsense (FreeBSD) funktioniert das "natürlich" ganz super, aber...

Windows zickt mal wieder herum, und ich erinnere mich, dass ich das gleiche Problem auch bei VirtualBox schon hatte:

Die Virtuelle Festplatte ist eine "IDE-Platte", und wenn man die dann als "SATA-Platte" einbindet, findet Windows (in diesem Fall ein altes Win7) das gar nicht gut und verweigert den Start. Es scheint mir aber auch nicht so, als könnte ich bei QEMU/KVM überhaupt eine Platte "als IDE" einbinden, oder sehe ich das falsch?

Alternativ... Emma2 schrieb:

Die Virtuelle Festplatte ist eine "IDE-Platte",

Kann ich Windows ohne Neuinstallation irgendwie klarmachen, dass es jetzt auf einer SATA-Platte "wohnt"?
(NB: Wenn ich in der KVM-VM auf die Windows-Reparaturoptionen gehe, dann friert die Maschine ein, zumindest nimmt sie keine Taste mehr entgegen.)

Emma2 schrieb:

Kann ich Windows ohne Neuinstallation irgendwie klarmachen, dass es jetzt auf einer SATA-Platte "wohnt"?

Für Windows 10/11 soll man in der KVM weder SATA noch IDE nehmen sondern VirtIO.

https://sysguides.com/install-a-windows-11-virtual-machine-on-kvm sollte dir weiterhelfen.

Edit: und ich hatte bei einem testweise mal installiertem Win10 Probleme mit der VirtIO-CD. Die ließ sich nicht installieren. Die Löung war die englischsprachige Version (English International) von Windows10. Damit ging es, aber nicht mit der deutschsprchigen. ist aber schon eine Weile her und kann sein, dass das bei Win11 nun anders ist.

Wie gesagt, das ist Win7, und außerdem will ich nicht neu installieren, dann könnte ich ja SATA nehmen. Es geht um die Migration bestehender VMs von VB nach QEMU/KVM.

Ich habe vor über 10 Jahren mal eine windoof 7 Installation auf neue Hardware migriert. Ich bin mir nicht mehr ganz sicher, wir hatten ein Batch der irgend welche Sachen auf dem System gemacht hat und wir haben vorher schon die Intel SATA Treiber installiert. Mehr kann Ich dazu nicht mehr sagen. Hast du schon zu dem Thema gegoogelt? Zu der windoof Version schreibe ich jetzt nichts mehr.

PS: Es kann sein das wir auch mit Acronis gearbeitet hatten

PPS: Es gibt da was von Heise, keine Ahnung, ob das auch mit Windoof 7 läuft (c’t-WIMage erstellt Windows-Backups)

Update:

Danke für Eure Hilfe bis hier. Ich habe nun fast alle Hosts umgestellt, und die Konvertierung der VMs geht tatsächlich recht einfach vonstatten. Ich konnte davon fast jede "probehalber" mit der bisherigen VDI anlegen, und nachdem die problemlos liefen, habe ich die VDIs in QCOW2s konvertiert.

Falls jemand anderes diesen Thread liest und diese Schritte selbst durchführen will, noch ein paar Anmerkungen:

• Migrierte Ubuntu-Maschinen haben manchmal das Problem, dass ihre NIC nun anders heißt (meistens ist das "enp1s0") und dann der bisherige Netplan-Eintrag nicht mehr stimmt

• VMs Windows 8.1 und Windows 10 haben SATA-Treiber wohl schon an Bord, die ließen sich nach "Umstellung" des Controllers von IDE nach SATA problemlos starten

• Mit Windows 7 war es etwas seltsamer: In VBox gestartet, konnte ich einen SATA-Controller "einbauen", die VM mit der IDE-VD starten, den SATA-Treiber installieren, die VM herunterfahren, die VD an den SATA-Controller anschließen und erfolgreich wieder starten. In KVM klappte der Start jedoch nicht. Da bin ich noch dran.

• Eine VM mit Windows 11, die schon als VB-VM eine SATA-Disk hatte, startete ebenfalls nicht ("No bootable media"), aber dazu gibt es ja oben den Link, den ich mir noch ansehen muss.

Woran ich außerdem noch "forsche": Wie kann ich eine VM mit mehreren Bildschirmen haben? Aber hierzu gibt es einige Fundstellen, ich werde davon berichten.

... und was nicht zu funktionieren scheint (oder ich verstehe es nicht): "Preferences - Konsole - Größe des Gastes mit Fenster ändern" hat keine Auswirkungen?

Update:

Emma2 schrieb:

• Mit Windows 7 war es etwas seltsamer: <...>

Vielleicht habe ich doch zuvor etwas falsch gemacht: Jetzt hat es genau so funktioniert wie mit Win8.1 und Win10, also "Einbau" des SATA-Controllers, Neustart zur Treiberinstallation, "Umschließen" der VDI und dann ein Neustart.

Jetzt muss ich doch nochmal nachfragen: Mit der einen Win7-Maschine hat es tatsächlich so funktioniert wie beschrieben, mit einer anderen habe ich ein ganz seltsames Verhalten, und ich habe den Eindruck, dass sei KEIN (oder nicht nur ein) Windows-Problem:

• Ich habe einen SATA-Adapter in die VM "eingebaut" und sie unter VBox gestartet

• In Windows wurden dann die SATA-Treiber installiert

• Ich habe die Maschine heruntergefahren und vom IDE-Controller an den SATA-Controler "angeschlossen"

• Unter VBox startet die Maschine ganz normal!

• Aber... unter KVM startet sie nicht, ok, das ist noch nicht so tragisch,

• aber sobald ich dort in eine GUI komme (z.B. in die der Windows-Reparatur-GUI oder die der Windows-Installations-DVD), friert die VM ein

• und nichts geht dort mehr, keine Taste, gefangener Mauszeiger verschwindet, Strg+Alt+Entf ist ohne Wirkung.

• Ich sehe in den "Details" KEINE Unterschiede zwischen dieser VM und der funktionierenden Win7-VM.

• Friert übrigens auch ein, wenn ich eine Win10-Installations-CD, EGAL OB 32-Bit oder 64-Bit "einlege"

• Friert NICHT ein, wenn ich eine Mint 32-Bit-DVD oder eine Ubuntu 18.04 32-Bit-DVD "einlege"

Habt Ihr vielleicht irgend eine Idee, was ich tun kann? (Außer der "Lösung", für diese eine VM ein VBox zu behalten...) Kann ich oder muss ich etwas im BIOS der VM ändern? Wenn ja, wie und wo?

... und dann noch: Um auszuschließen, dass es vielleicht doch an der XML der VM liegt, habe ich die der funktionierenden Win7-VM auf den Test-Host kopiert, aber diese VM sehe ich im virt-manager - auch nach Neustart - erstmal nicht. Was muss ich denn neu starten, damit der virt-manager neu in "sein" Verzeichnis schaut?

Edit: Neustart des gesamten Hosts hat geholfen (die kopierte XML zu sehen)... aber das ist natürlich keine schöne "Lösung".
Edit: Ok,

1

systemctl restart libvirtd

macht's.