default-user

Umziehen von VirtualBox VMs von Intel-Host auf AMD-Host

Ich hatte bisher nur Intel-PCs / Laptops mit Linux drauf. Es war einfach, eine in VirtualBox erstellte VM (VDI-Datei und VBOX-Datei auf einen anderen PC zu kopieren, solange die Pfade zu den VMs gleich blieben. Es handelt sich um Windows-7 VMs
PS starten und VM weiter benutzen, läuft!

Jetzt erwäge ich die Anschaffung eines AMD-Rechners mit Linux drauf und möchte die bisher erstellten VMs dort ebenfalls weiter nutzen können – natürlich bei Beibehaltung der Pfade.

Natürlich bietet auch der AMD-PC Hardware-Virtualisierung im BIOS an und die Hardware ist sogar deutlich leistungsfähiger, als bei den bisherigen Host-Systemen.

Im Web und auf den Oracle-Websites fand ich hierzu keine Aussage.

Frage:
Ist die Hardware gleichgültig, weil vielleicht VirtualBox so etwas wie einen "Hardware Abstraction Layer" bildet und die für die VMs bereit gestellten Betriebsysteme immer gleich sind?

Oder scheitert bereits das Hinzufügen im VirtualBox-Manager, weil die hinzuzufügende VM Inkompatibilitätsprobleme macht?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilen

Content-ID: 673668

Url: https://administrator.de/forum/virtualbox-vm-migration-intel-amd-673668.html

Ausgedruckt am: 25.07.2025 um 04:07 Uhr

Avoton
Lösung Avoton 02.07.2025 um 23:12:47 Uhr
Moin,

Geht ohne Probleme, so lange die VMs sauber heruntergefahren sind und nicht in einem Standby oder "Gespeichert" Status sind.

Gruß,
Avoton
Lochkartenstanzer
Lochkartenstanzer 03.07.2025 aktualisiert um 05:45:39 Uhr
Moin,

Kann ich bestätigen: Funktioniert I.d.R. unproblematisch, solange Du drauf achtest, daß die VMs wirklich "aus" und nicht nur suspendiert.sind.

lks
aqui
Lösung aqui 03.07.2025 aktualisiert um 09:58:49 Uhr
Eigentlich ist die Frage in sich auch überflüssig, denn der tiefere Sinn einer Virtualisierung ist ja per se die Abstrahierung von der Hardware Ebene.
Es wäre ja fatal wenn VMs fest an irgendwelche Hypervisoren oder deren Hardware gebunden wären. Das würde den ganzen Sinn von Virtualisierung ad absurdum führen. Sagt einem eigentlich auch schon der gesunde IT Verstand. face-wink
Lochkartenstanzer
Lochkartenstanzer 03.07.2025 um 09:57:02 Uhr
Zitat von @aqui:

Eigentlich ist die Frage in sich auch überflüssig, denn der tiefere Sinn einer Virtualisierung ist ja per se die Abstrahierung von der Hardware Ebene.
Es wäre ja fatal wenn VMs fest an irgendwelche Hypervisoren oder deren Hardware gebunden wären. Das würde den ganzen Sinn von Virtualisierung völlig ad absurdum führen. Sagt einem eigentlich auch schon der gesunde IT Verstand. face-wink

Nicht so vorschnell mit den jungen Pferden. Die Frage ist durchaus berechtigt. Es gab Mal eine Zeit, in der windows verschiedene HALs für verschiedene Prozessoren und deren Anzahl hatte. Und da die Hypervisoren oft die Features der darunterliegenden Prozessoren weitergereicht hat, könnte es durchaus passieren, daß Windows die falsche HAL aktiv hatte und nicht bootete. Bei Linux war das Problem eher selten, wenn man nicht gerade einen auf einen Prozessor optimierten Kernel verwendete.

Heutzutage hat man das Problem eher weniger weil AMD und Intel ihre Befehlssätze angeglichen haben und die modernen Windows-Versionen da für verschiedene Prozessoren keine getrennten HALs mehr verwenden

So gesehen hat die Frage durchaus seine Berechtigung, auch wenn sie mit den heutigen Hypervisoren mit "funktioniert" beantwortet werden kann.

lks, der bei NT, W2K und XP schon öfter "Operationen" am offenen Betriebssystem wegen der HAL.dll durchgefuhrt hat.
LordGurke
LordGurke 03.07.2025 um 11:15:03 Uhr
@aqui: Als jemand, der VMs zwischen AMD und Intel live-migriert hat kann ich berichten, dass das problematisch sein kann. Das System crashed vielleicht nicht sofort, aber Software, die bestimmte Befehlssätze nutzt, unterscheidet oft zwischen den Herstellern, weil das eben doch nicht 100% kompatibel ist. Du kannst ja mal in den Quellcode von ffmpeg schauen, wie häufig da in den einzelnen Codecs herstellerabhängige Zweige sind.

Das alles ist aber wirklich nur problematisch, wenn man eine laufende VM live-migriert, denn Software rechnet nicht damit, dass sich der CPU-Hersteller im laufenden Betrieb ändert.
Wenn die VM richtig heruntergefahren wird (Fastboot deaktivieren) und dann auf einer anderen CPU wieder gestartet wird, ist das vollkommen unproblematisch.
godlie
godlie 03.07.2025 um 11:17:54 Uhr
Als jemand, der VMs zwischen AMD und Intel live-migrier

HyperV, ESX oder KVM ? ich kenne die. Probleme eig nur mit den MegaScrhott Systemen
default-user
default-user 03.07.2025 um 11:49:48 Uhr
Herzlichen Dank für eure Antworten!
Damit ist auch zugleich geklärt, dass meine Probleme, die ich in de anderen thread mit meinem Minisforum UM870 hatte, nicht auf den Wechsel der Hardware-Plattform zurück zu führen sind:
Spezielles Minisforum AMI-BIOS: Virtualisierung aktivieren (AMD)

Den UM870 sende ich jetzt zurück und kaufe ein solides Selbstbau-AMD-System.
LordGurke
LordGurke 03.07.2025 um 18:08:36 Uhr
Zitat von @godlie:
HyperV, ESX oder KVM ? ich kenne die. Probleme eig nur mit den MegaScrhott Systemen

KVM und die CPUs waren (z.B.) ein Xeon Silver 4215 und ein AMD EPYC 7513.
Migration funktioniert grundsätzlich, aber wenn während der Migration von Intel nach AMD in der VM mit ffmpeg WAV nach OPUS konvertiert wurde, ist die OPUS-Datei am Ende defekt gewesen. Wenn man die Konvertierung nach der Migration wiederholt hat, lief es problemlos.
Es sind wie gesagt nur die kleinen subtilen Probleme, die man sich damit eintritt – dass eine VM einfach stehenbleibt oder crashed passiert eigentlich nur dann, wenn die CPUs weit auseinanderdriften.
em-pie
em-pie 03.07.2025 aktualisiert um 20:34:29 Uhr
Moin,

Man sollte jedoch noch validieren, welche Software auf den VMs läuft.

Als wir vor 10/ 12 Jahren noch IBM-Blades in vSphere Cluster betrieben haben, gab es drei identische und ein nachgekauftes Blade. Alles HS22, mit den selben CPUs (XEON E5500), außer das vierte, da war es eine 5600 (wenn ich das richtig im Kopf habe).
Wir haben aber eine Software im Einsatz, die die HardwareID auswertet - u. A . Auch die CPU.
Hab ich die VM innerhalb der 3 identischen Blades migriert (egal ob live oder offline), kein Problem. Landete die VM auf dem 4. Blade und die VM startete (neu), lief die Applikation nicht mehr und musste neu lizenziert werden (ein zurück verschieben half auch nicht).