Moving VMs to new installation, with some changes

[wearyofallthiscrap]

We've been running a pretty simple setup of VirtualBox 4.1.16 on a bog-standard Windows XP (Service Pack... whatever the latest is... 3?), everything 32-bit. We're about to move to a 64-bit Windows 7 host, and want to take the opportunity to upgrade the VB installation to 4.2.10. This raises a couple questions that don't seem to be addressed in the manual or FAQ (maybe because they're not issues, maybe because this isn't supported, dunno):

1) The VB download doesn't distinguish between 32-bit and 64-bit hosts as far as I can tell, so we're currently assuming that 4.2.x just runs as a standard 32-bit app. Are there any special things we need to keep in mind when installing on the new host?

2) We're planning to simply do a normal full shutdown (not suspend or save or etc) of the guest OS, and move its entire directory structure (the .vbox and .vdi files) over to the new system. If the entire directory tree for a given VM is picked up and moved over as an intact unit, do we have to do anything special with respect to moving from 4.1.16 to 4.2.x? Any specific upgrade steps?

3) I wouldn't expect the guest OS to know or care that the hypervisor is now running in a 64-bit environment. Am I wrong?

[Perryg]

1) The new install contains both 32 & 64 and will install the appropriate version.
2) Nothing special
3) io/apic determines whether or not the multi processor kernel gets install, just do not turn it on unless you know the repercussions & how to deal with it. You can and should enable VT-x/AMD-v as it really helps the speed. Also page tables and large pages improve the speed.

Note: with version => 4.0 all you need to do it use the add feature to install the new guest. The guest may need to be re-activated if the guest detect a major change.

[wearyofallthiscrap]

1) The new install contains both 32 & 64 and will install the appropriate version.

Oh cool.

Thanks for the fast response!

[wearyofallthiscrap]

2) We're planning to simply do a normal full shutdown (not suspend or save or etc) of the guest OS, and move its entire directory structure (the .vbox and .vdi files) over to the new system. If the entire directory tree for a given VM is picked up and moved over as an intact unit, do we have to do anything special with respect to moving from 4.1.16 to 4.2.x? Any specific upgrade steps?

Well, there's something gone wrong, but I'm not sure what. Trying to use "Machine -> Add..." to bring the previous VM up in the new installation gives

Code: Select all

Failed to open virtual machine located in <full_path_to_the_VM>.vbox.

A differencing image of snapshot {160fe5f4-4945-4af4-b5ce-05aa5ca43df9} could not be found. Could not find an open hard disk with UUID {3fdadd6d-2ddb-442b-8554-baca6a8e818c}.

Result Code: E_FAIL (0x80004005)
Component: SnapshotMachine
Interface: IMachine {22781af3-1c96-4126-9edf-67a020e0e858}
Callee: IVirtualBox {3b2f08eb-b810-4715-bee0-bb06b9880ad2}

So then I remember that some of VirtualBox's XML files store full pathnames of stuff including the drive letter. Instead of copying the VMs over, we had moved the underlying physical disk. So the entire VM tree is still in place, unchanged from what it was before. The drive is seen by the new Win7 host (it's not "the system drive" or anything, just a big data drive), but with a different drive letter than it was assigned back on the previous host. So, after making a backup copy of the <primary_VM_name>.box file, I pulled it up in a text editor and changed the drive letter in all the .vdi pathnames.

Tried adding it to the VM Manager again, got the exact same error message. (I've restored the previous version of the .vbox file, before I forgot about making the edits.)

I've done some brief looking through the VM tree. There aren't any snapshot files with those identifiers present. I'm not sure what to try next. Anything present in the VM tree before must still be there now, since it's (literally) the same disk. Would it make sense to create a new VM and tell it to use the .vdi's from the previous VM? (Do the .vdi files "know" what VM identifier is using them?)

[Perryg]

Did you change anything from the defaults in regards to the snapshot storage on the original install?

[wearyofallthiscrap]

Did you change anything from the defaults in regards to the snapshot storage on the original install?

Not that I can recall. Each VM stores its snapshots under its own "Snapshots" folder. The only storage-related changes that we made were to change the default path of new VMs to not be under the documents-and-settings of the username originally running the Managers.

I can find the snapshot entry it's complaining about in the .vbox file, but there are no snapshots of that same datestamp anywhere on the drive. Judging by the description field, it would have been a snapshot that we later deleted from inside the VB Manager.

We would be okay with losing previous snapshots as long as we can still use the current/latest disk image from when we shutdown the guest in preparation for the new host. If that's the only way to go, then I expect I'll need to do that by editing the .vbox file...?

[Perryg]

One more question. Was there anything still mounted in the virtual CD? Guest additions, Etc. on the original machine?

[wearyofallthiscrap]

Nothing in the virtual CD, no. There would have been local directories mapped/mounted, but I changed those drive letters when I tried editing the .vbox (the shared folders were all on the same physical host drive as the VMs, by coincidence).