capturing VM HW environment for purpose of migration/reinstall

Discussions about using Windows guests in VirtualBox.
Post Reply
nbi
Posts: 19
Joined: 6. Jul 2009, 07:24
Primary OS: Debian other
VBox Version: PUEL
Guest OSses: Windows XP32, XP64, WIN7-64

capturing VM HW environment for purpose of migration/reinstall

Post by nbi »

I've consulted the Oracle docs, but was not able to find a reference to a tool/app that captures the HW environment (i.e. what the VM expects to see) in a file that could serve as input to a future hypervisor (VirtualBox, VMware, Windows, QEMU/KVM, etc) so that the migrated/reinstalled OS thinks it's running on the same machine as the original VM. The goal is to boot successfully and not ask for reactivation. The apps should also think they're on the same machine - it wouldn't help if the OS thinks everything is kosher, but the apps are locked and require reinstall.

The Oracle docs discuss ACPI tables, but that doesn't help because it presumes we know a priori what HW the VM is expecting to see. The question is what is the complete HW environment (BIOS, devices) that a given VM sees? It ought to be possible to run a tool in the guest that interrogates the OS and saves the information to a file (something like a .config or even the acpi tables). Is something like this even possible?
scottgus1
Site Moderator
Posts: 20965
Joined: 30. Dec 2009, 20:14
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Windows, Linux

Re: capturing VM HW environment for purpose of migration/reinstall

Post by scottgus1 »

Generally, the VM's .vbox file contains the unique codes that the VM's software sees for activation purposes. If the VM's software does not look at the actual CPU in the VM for activation purposes, then a mere folder copy of the VM's folder can result in a perfect transfer of the VM to another Virtualbox host.

Note that the physical CPU appears in the VM's OS, so if the new host has a different CPU this will appear to the VM's software. If the software uses the CPU as part of the activation (and some have done so), then activation will break. There is no way to prevent this change from appearing in the VM, since Virtualbox does not emulate the CPU.

To take the VM to another hypervisor, you'd have to export the VM. Export might preserve the .vbox file's codes. Or it might not. And there's no telling what virtual hardware the other hypervisor would present. You'd have to experiment. Experimenting now, before you get in a jamb, might be a good idea.
Post Reply