VMs on multiple host OSs

[DEmberton]

I'm dual booting Windows (Windows 7 x64 now) and Kubuntu. Given that each runs VirtualBox, and the Host OS shouldn't matter to the Guest OS, I assumed that I'd be able to use the same VMs on each host OS.

Well almost. Firstly the Windows VM XML files wouldn't load in the Linux version of VirtualBox (because of the type, and because of the DirectSound parameter). I copied and modified my existing XML files to create Linux VirtualBox compatible versions, and modified the Linux VirtualBox.xml to point at them instead.

This works okay, until I create a snapshot, or save the state, where it gets a little confused. Obviously something about the current state information is saved within the XML files and running two XML files with the same VHD doesn't quite work.

Is anybody else doing the same? Is there a good way to acheive this?

[Sasquatch]

The only way to share snapshots and saved states is to edit the XML files each time you swap Host and include the snapshot/saved state data. Because this is prone to errors, I advise you to just create regular backups of the VDI file and shut down the VM. Don't use snapshots or saved states. The backup can act as snapshot.

[CaspianCanuck]

Hi there!

I am struggling with the same problem, trying to get my WinXP virtual machine stored on a USB hard drive to work seamlessly on both Ubuntu and a host XP. So far I have managed to run the VM on both host OS'es by tweaking the VM's XML file. The only change I had to make was switch the paths from Linux-style to DOS/Windows style, the rest of the settings are identical. Everything works fine except the Saved State -- it seems that VirtualBox on Windows has trouble with the VM state saved on Linux and vice versa.

I have manually edited the snapshot and saved state references in the VM's XML file but to no avail -- VirtualBox still chokes trying to restore state saved on another OS. I wonder if the culprit is the hardware differences between the two boxes.

Has anyone ever managed to successfully restore VM from state saved on a different host OS and hardware? Any suggestions will be greatly appreciated....

[Sasquatch]

Hi there!

I am struggling with the same problem, trying to get my WinXP virtual machine stored on a USB hard drive to work seamlessly on both Ubuntu and a host XP. So far I have managed to run the VM on both host OS'es by tweaking the VM's XML file. The only change I had to make was switch the paths from Linux-style to DOS/Windows style, the rest of the settings are identical. Everything works fine except the Saved State -- it seems that VirtualBox on Windows has trouble with the VM state saved on Linux and vice versa.

I have manually edited the snapshot and saved state references in the VM's XML file but to no avail -- VirtualBox still chokes trying to restore state saved on another OS. I wonder if the culprit is the hardware differences between the two boxes.

Has anyone ever managed to successfully restore VM from state saved on a different host OS and hardware? Any suggestions will be greatly appreciated....

If you transfer your saved states between two different physical machines, it won't work. VB checks the CPU ID to restore the state, and those are of course not the same. I share my VMs with my PC and laptop using the same external hard drive, and only Saved States don't work because of that. Given, my Host OS is the same on both systems (XUbuntu).

[CaspianCanuck]

Thanks, Sasquatch!

That's pretty much what I figured too -- that not all key pieces of hardware are getting completely virtualized by VB, making the guest OS aware of the hardware changes when you share the same VM between two computers.

Is there another multi-platform virtualization product that virtualizes the host hardware to the point that the guest OS doesn't care which machine it's run on, period?

[Sasquatch]

It's not that the Guest can't handle the CPU difference, it's that VB doesn't allow that ID to be changed during VM operation. No other virtualization software will do that. Maybe Qemu will be able to, as that can emulate different architectures (like ARM), but the downside is that it's really slow. Changing the CPU ID during system operation could also cause a kernel panic (BSOD in Windows terms).