Deleting VirtualBox drives that do not want to be deleted

Today's episode began with me wanting to delete a VirtualBox virtual machine (vm for short) that was acting up in a rather bad way. I was at the point that all I wanted to do was wipe it and restart from scratch. Problem is I screwed up, out of frustration, in the deleting the old vm. I thought I had done it right and then wiped the old directory and proceded to recreate the vm... just to find out that virtualbox thought the new disk image was associated with some snapshots that were in fact associated with the old image. So, I decided to tell virtualbox to just delete the image:

root@fileserver:~# VBoxManage closemedium disk /export/hosts/sambabox/sambabox.vdi --delete
VBoxManage: error: Storage for the medium '/export/hosts/sambabox/sambabox.vdi' is already created
VBoxManage: error: Details: code VBOX_E_INVALID_OBJECT_STATE (0x80bb0007), component Medium, interface IMedium, callee nsISupports
Context: "DeleteStorage(progress.asOutParam())" at line 1166 of file VBoxManageDisk.cpp
VBoxManage: error: Failed to delete medium. Error code Unknown Status 0x80BB000C
VBoxManage: error: Cannot close medium '/export/hosts/sambabox/sambabox.vdi' because it has 2 child media
VBoxManage: error: Details: code VBOX_E_OBJECT_IN_USE (0x80bb000c), component Medium, interface IMedium, callee nsISupports
Context: "Close()" at line 1182 of file VBoxManageDisk.cpp
root@fileserver:~#

As you can see, it did not work quite as I expected. What to do now since all the old files, snapshots included, are gone? Well, it seems that virtualbox still somehow knows about all the drives even though they are not mentioned in VirtualBox.xml:

root@fileserver:~# VBoxManage list hdds
UUID:        1c2b04ba-7090-4ad9-8db0-9884f254ca23
Parent UUID: base
Format:      VMDK
Location:    /export/hosts/windowsXP32/windowsXP32-disk1.vmdk
State:       locked write
Type:        normal
Usage:       windowsXP32 (UUID: d5c4efde-5587-43b6-bf81-8f606a746c58)

UUID:        a9275089-0812-43d3-b3b8-da7dea5c0dc7
Parent UUID: base
Format:      VDI
Location:    /export/hosts/sambabox/sambabox.vdi
State:       inaccessible
Type:        normal

UUID:        98a1f274-93af-4747-988d-b8e91cac00b8
Parent UUID: a9275089-0812-43d3-b3b8-da7dea5c0dc7
Format:      VDI
Location:    /export/hosts/sambabox/Snapshots/{98a1f274-93af-4747-988d-b8e91cac00b8}.vdi
State:       inaccessible
Type:        normal

UUID:        d33e0420-4f1f-461c-abc8-bb38c55697b8
Parent UUID: a9275089-0812-43d3-b3b8-da7dea5c0dc7
Format:      VDI
Location:    /export/hosts/sambabox/Snapshots/{d33e0420-4f1f-461c-abc8-bb38c55697b8}.vdi
State:       inaccessible
Type:        normal

root@fileserver:~# 

Look at the inaccessible ones. Note their path: as far as virtualbox is concerned, they are in the sambabox snapshot directory. I would bet a cookie that is my problem. Now, how to delete it? I tried providing the path (/export/hosts/sambabox/Snapshots/{98a1f274-93af-4747-988d-b8e91cac00b8}.vdi) and that did not work.

Well, it did not work because the file itself is no longer with us. But, what if we enter the UUID instead?

root@fileserver:~# VBoxManage closemedium disk 98a1f274-93af-4747-988d-b8e91cac00b8
root@fileserver:~# VBoxManage list hdds
UUID:        1c2b04ba-7090-4ad9-8db0-9884f254ca23
Parent UUID: base
Format:      VMDK
Location:    /export/hosts/windowsXP32/windowsXP32-disk1.vmdk
State:       locked write
Type:        normal
Usage:       windowsXP32 (UUID: d5c4efde-5587-43b6-bf81-8f606a746c58)

UUID:        a9275089-0812-43d3-b3b8-da7dea5c0dc7
Parent UUID: base
Format:      VDI
Location:    /export/hosts/sambabox/sambabox.vdi
State:       inaccessible
Type:        normal

root@fileserver:~# VBoxManage closemedium disk a9275089-0812-43d3-b3b8-da7dea5c0dc7
root@fileserver:~# VBoxManage list hdds
UUID:        1c2b04ba-7090-4ad9-8db0-9884f254ca23
Parent UUID: base
Format:      VMDK
Location:    /export/hosts/windowsXP32/windowsXP32-disk1.vmdk
State:       locked write
Type:        normal
Usage:       windowsXP32 (UUID: d5c4efde-5587-43b6-bf81-8f606a746c58)

root@fileserver:~# 

As you can see from above, using the UUID did work out rather nicely. You have to delete the inaccessible files in the reverse order they were created but after a few steps all the offending images were gone. And now we can install a new version of this vm without fear that unloved images will come back to haunt us.