.Virtualbox configuration lost, re-register VM with harddisk

[tanuva]

Moin,

the configuration of my virtualbox installation got lost because the host's system disk died. The other disk containing the VM is still alive. I expected it to be easy enough to simply run VBoxManage registervm, but due to mysterious reasons I cannot register vms that have a harddisk and/or snapshot attached. Both are existent and obviously needed in this case. So, I don't want to rant in any way, I'm just a little surprised that re-registering vms is so hard.

I've read about changing paths in VirtualBox.xml and removing the storage controller part from the vm.xml. The latter actually let me register the vm again, but without the snapshot it is quite useless. Now I know that one should register the vm and then re-add storage controller and hdd image to it. If that is correct so far, how would I proceed getting the snapshot in again?

I only have ssh access to the machine, so please hint me at VBoxManage (et al.) options instead of GUI actions.

[mpack]

Registering VMs is not at all hard: after reinstalling VirtualBox (4.x or later) you just run the GUI and select the "Machine|Add".. menu item and browse to wherever the existing VM (actually, the .vbox file) is.

What can be hard is when you have a non-default arrangement of virtual disks scattered all over the place (*). If these disks are not in the local VM media registry then of course VirtualBox can't start the VM: that's your mistake, do not blame VirtualBox for having done what you told it to do!

If that is your problem then you'll have to find all the bits of disks, copy them to a sensible place, and somehow get them into the local media registry.

Incidentally it would be nice to have confirmation of a number of basic facts: what is your host OS, what guest OSs are involved, what version of VirtualBox you are using, what version of VBox was used to create the VMs, do you still have the settings file for each VM or just have bare disks - that sort of thing. Some of these details are best provided by filling out your profile page.

(*) To be fair, details of a VM scattered all over the place was the default prior to VirtualBox v4.

[tanuva]

Incidentally it would be nice to have confirmation of a number of basic facts: what is your host OS, what guest OSs are involved, what version of VirtualBox you are using, what version of VBox was used to create the VMs, do you still have the settings file for each VM or just have bare disks - that sort of thing.

Sorry, I should've told that.
Host: a current SuSE Linux
Guest: Debian 6
VBox version: 4.1.4_OSEr74291
VBox version used for creation of the VM: I'm not quite sure, the xml says version "1.9-linux"

I have the whole data about the vm including disk, a snapshot and the vm.xml definition. That stuff is currently located like this:

Code: Select all

somewhere/vmfolder/
- vm.xml
- vm.vdi (referenced nowhere in xml...)
somewhere/vmfolder/Snapshots/
- {48e9d827-2349-4883-b0df-04525f85c46f}.vdi (Snapshot hdd)
- {81c40e8c-a6fe-4f4a-bb85-9e3cccee079f}.vdi (Referenced in xml as the base vm hdd. Diff between current state and original vm.vdi?)

If that is your problem then you'll have to find all the bits of disks, copy them to a sensible place, and somehow get them into the local media registry.

Now what would this sensible place be?
I've tried setting the defaultMachineFolder in ~/.VirtualBox/VirtualBox.xml to "/path/to/somewhere" (as mentioned above) instead of "/home/me/VirtualBox VMs".
Independently of that machine folder, VBoxManage keeps looking for the vm.xml in VirtualBox VMs/ if I don't provide the absolute path to it.
Before I move everything around to fit some scheme, what would I need to do to make VBox find the disk images using folder scheme version "1.9-linux"?

[mpack]

VBox version used for creation of the VM: I'm not quite sure, the xml says version "1.9-linux"

That sounds like it was created in VirtualBox 3.x, confirmed by your use of "the xml" to describe the settings file. In VBox v4 the extension changed to ".vbox", with the ".xml" only supported for legacy VMs.

I have the whole data about the vm including disk, a snapshot and the vm.xml definition.

Well, if you were using a Windows host like any sane person normally would , then the solution would be simple. You would copy the base VDI along with all snapshots into a single folder, then you would use the CloneVDI tool (see sticky in "Windows Hosts" forum) to clone the most recent snapshot (do not make the mistake of cloning only the base VDI). This creates a merged VDI which you can build a new VM around. You can't use "VBoxManage clonehd" for this because it requires the control info that you have lost.

Since you are not using a Windows host then you have to install Wine in order to run CloneVDI: or else borrow a Windows PC for a while (CloneVDI is stand alone - you don't need to install VBox on the borrowed PC). Don't run CloneVDI in a Windows guest looking at GA shared folders. For some reason that does not seem to work.

Once you have the flat VDI you can create a new VM around it. Try to get all VM settings the same as before - have the old xml file in a text editor for reference. Possibly you will still have to reactivate. Once you have the new VM created I would unregister the disk, move it into the same folder as the .vbox, and re-register the disk (this ensures you match the v4 default layout and avoid similar problems in future).

Another thing you could do to improve future reliability is to avoid the use of snapshots.

[tanuva]

It'll take some time to get my hands at a Windows machine near enough to the vm host to copy over the disk images and clone them together, so I cannot report success in the near future, but that still sounds promising. Thanks for your advice!

[mpack]

It'll take some time to get my hands at a Windows machine

Well, remember what I said that CloneVDI can run under Wine.