Failed to open virtual machine Ubuntu on Windows7

[surfcast23]

Hi All,

I have run into a bit of a problem with my virtual machine. I went to start it earlier and got a message regarding a failure to open the virtual machine so I removed the machine and tried to re add it. When I did I got the error message below.

Failed to open virtual machine located in C:/Users/Khary/VirtualBox VMs/Ubuntu64/Ubuntu64.vbox.

Could not find an open hard disk with UUID {e76274ed-5001-44da-ae77-67c5103e707d}.

Result Code: VBOX_E_OBJECT_NOT_FOUND (0x80BB0001)
Component: VirtualBox
Interface: IVirtualBox {3b2f08eb-b810-4715-bee0-bb06b9880ad2}


I really need to get this thing up and running and would appreciate any in site to the problem. Thanks in advance.

[mpack]

Well, the error message means what it says: the VM is configured to reference a certain hard disk file, but that file has been removed from the registry. The registry info is located in the .vbox file, i.e. the .vbox file itself contains the problem, so removing and re-adding the VM will not help.

Post a zip file containing the .vbox file, also post a complete directory listing of the VM folder and its Snapshots subfolder. I guess the VM log file wouldn't hurt either (include it in the .zip).

[surfcast23]

Hi mpack. I have posted the directory listing and log files, but the zip file containing the .vbox file is quite large and I do not think it will upload. I also posted the VBoxSVC.log files. Thank you for your help.

[surfcast23]

another VBoxSVC and the .vbox file. I was looking at the wrong file before.

[mpack]

I don't need the VBoxSVC logs (I've now deleted them), nor is that listing of your "VirtualBox VMs" folder of any use to anyone.

I do need that directory listing of the VM folder (which is the folder you found the .vbox file in), plus it's Snapshots subfolder.

Edit:  Actually, looking at your .vbox file I see that there are no hard disks registered at all. So, either you manually removed drives from this VM, or this VM was created to reference drives belonging to (and registered by) another VM. And for some reason that other VM is no longer around. Did you delete another VM recently? Did you move this VM from elsewhere? You can't accidentally create a VM which references another VMs disks: it involves clicking the "Use existing disk" option of the new VM wizard. This situation isn't repairable unless you can lay your hands on the disk image file (usually a VMDK), copy it into the VM folder, and use the VM Storage settings to mount it.

[surfcast23]

I have attached the directory listing to this post.

I did recently delete another VM, it was a 32 bit version of Ubuntu.

[mpack]

How odd - there should be a Snapshots folder in there too. Hopefully this simply means that this VM has never had snapshots - a very good thing.

In any case, I see an Ubuntu64.vdi file in the VM folder. It is a significant size (5GB), indicating that it isn't just a stub created along with the VM. You could try mounting it in the VM (use Storage tab of VM settings, click on the existing SATA controller, then click the little "Add hard disk" icon), and let me know what happens. Do not use any other disk mounting method you may have read about in an obsolete blog.

NOTE: VirtualBox won't give you access to the settings because of the broken registry. I've manually edited the attached .vbox file to get around that. Use this to replace your broken .vbox file. Make a backup copy first if you like, but note that you posted it above so its already backed up.

[surfcast23]

That did it thank you! Do you have any ideas on what might have caused the problem so I can avoid it in the future.

[mpack]

As I said earlier, I think you created a VM-B and in it you added a hard disk already registered in the .vbox file of an earlier VM-A. In that case the disk is not registered a second time in VM-B because VBox currently doesn't allow that.

Later on you deleted VM-A, with the result that the disk was now not registered anywhere.

I don't know any other way this could have happened, if we rule out manual editing of the .vbox file. The puzzle is that the local hard disk clearly should belong to B, meaning this could only be he result of multiple interventions.