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?
capturing VM HW environment for purpose of migration/reinstall
-
- Site Moderator
- Posts: 20945
- 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
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.
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.