02.07.2025
1613
9
0Umziehen 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?
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?
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 673668
Url: https://administrator.de/forum/virtualbox-vm-migration-intel-amd-673668.html
Ausgedruckt am: 25.07.2025 um 04:07 Uhr
9 Kommentare
Neuester Kommentar
Moin,
Geht ohne Probleme, so lange die VMs sauber heruntergefahren sind und nicht in einem Standby oder "Gespeichert" Status sind.
Gruß,
Avoton
Geht ohne Probleme, so lange die VMs sauber heruntergefahren sind und nicht in einem Standby oder "Gespeichert" Status sind.
Gruß,
Avoton
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
Kann ich bestätigen: Funktioniert I.d.R. unproblematisch, solange Du drauf achtest, daß die VMs wirklich "aus" und nicht nur suspendiert.sind.
lks
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.
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.
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.
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.
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.
1
@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.
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.
2
Als jemand, der VMs zwischen AMD und Intel live-migrier
HyperV, ESX oder KVM ? ich kenne die. Probleme eig nur mit den MegaScrhott Systemen
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.
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.
Zitat von @godlie:
HyperV, ESX oder KVM ? ich kenne die. Probleme eig nur mit den MegaScrhott Systemen
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.
1
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).
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).
