VMs Moved to a Different Drive: VBOX_E_OBJECT_NOT_FOUND

[quantumburnz]

Hello,
I'm running out of free space on my main drive so I wanted to move VMs off to a different drive. I read various tutorials about how to do this, but it's not working reliably so far. I copied all the VM files over to my E: drive and left my .VirtualBox folder on my C: drive. I removed all the existing VMs that were on the C: drive and readded them with the Machine|Add menu item. Initially, I believe this was failing with the following error:
Failed to open virtual machine located in E:/VirtualBox VMs/DC1 - Win2k8 R2 Std (Full Install)/DC1 - Win2k8 R2 Std (Full Install).vbox.

Could not find an open hard disk with UUID {af2a1219-2878-485c-9400-27201f91836b}.

Result Code: VBOX_E_OBJECT_NOT_FOUND (0x80BB0001)
Component: VirtualBox
Interface: IVirtualBox {fafa4e17-1ee2-4905-a10e-fe7c18bf5554}

I found that if I open the .box file and remove the AttachedDevice section, I could then add the VM, re-add the drive, and booth the machine without a problem. However, after some random amount of time (I haven't been able to tie it to restarting VirtualBox or restarting the computer) the VM shows as Inaccessible. If I remove the VM and try to add it again, I get the above error message all over again. I can go through the steps of removing the AttachedDevice, but that's obviously not a long term solution.

Your assistance with this pesky problem would be appreciated!

Chris

[mpack]

You shouldn't need to read various tutorials, the correct procedure for moving a VM is given here.

The only way this can fail is if some of the media is located outside the VM folder, and the media registry is using an absolute path. Only you know if you did that, and you'll have to fix it yourself.

[quantumburnz]

Thanks for your reply mpack,
The instructions you posted were pretty much what I did, I think. However, I failed to mention that some of the VMs are ok. For instance, I have a base Win 2k8 VM that I make linked clones of. This base VM never becomes inaccessible but its children do, and I moved them all to the same place on another drive. Any thoughts on why this would happen?

[mpack]

My previous reply already listed all the possibilities I know of. This shouldn't need to be complicated: look at what filename it's complaining about, and verify that it exists where it's supposed to exist. Also, if you're confident with xml you can look at the <harddisks> portion of the .vbox file, and see if it's correctly referencing media: correct filename, correct UUID, no path (because the file should be local), and the UUID embedded in the header matches what the registry says it should be (CloneVDI can be used to view VDI headers).

[quantumburnz]

The filename it complains about exists in the Snapshots directory. There's nothing in the <harddisks> section of the .vbox file, there's only a AttachedDevice section that contains the UUID at the end of fthe .vbox file. I don't know exactly what I'd be looking for in the VDI headers, but I'm able to open the VMDKs ok, and the validation result is 'Ok'.

I'm not trying to make this complicated. Something is just not working as it should be...

[mpack]

There's nothing in the <harddisks> section of the .vbox file

In that case the problem is exactly what I suggested it was: the VM is referencing an external disk, in fact it would have to be one registered in another VM, otherwise it wouldn't work at all. Sharing a disk didn't used to be allowed, but if you choose to use this feature you really need to know what you're doing. This is an unstable situation. It could only have arisen because you didn't create the VM in the normal way. On creating this VM, when it got to the disk creation step you chose "Use existing" and then selected a VDI already belonging to another VM.

I've also seen a variation on this behaviour when someone drags and drops an existing VDI onto a VM representation in the VBox Manager. This shouldn't work, but it kind of half does, for one session only.

Either way, if you scatter files around the host hard disk in effectively random folders then of course it makes backups a nightmare.

The best cure (if it lets you) is to get the VM working by any means necessary, then make a full clone of it. That's a full clone (not linked), current state only, don't reset MAC address. If it works then the clone should be fully independant. I should emphasise that when the VM being cloned is as messed up as this then I'm not certain that the built in VM cloning feature will work - but we'll consider alternatives only when we know we need to.

[quantumburnz]

Yes, I'm using differencing disks based upon an original image. Are you saying this is unstable? It seems like a great way to save hard disk space. If I make full clones of all my VMs, I'm going to eat a lot of hard disk space... I'm having trouble understanding why everything worked fine when all the files were on my C: drive and simply moving them to the E: drive created these problems.

[mpack]

Even a differencing image should be listed in the HardDisks section of the .vbox file, so if it's empty as you said then that still doesn't explain what happened here. If you've been hacking it to get your own version of an immutable drive working then that might explain it, but then you're on your own because I'd have no possible way of anticipating what you've done.

I'd say: a larger drive is probably cheaper than the time you've already spent firefighting this setup.

[quantumburnz]

mpack,
Yes, a larger drive would probably be cheaper than the time I spent to figure this out. However, with your assistance in pointing me to the <MediaRegistry> location, I was able to copy the entries from my original .vbox files before the move and get everything working. Now if it happens again in the future for any reason, I know how to fix it.
Thank you mpack!