5.20 destroyed all our Windows guests

[Abrugal]

We had half a dozen Windows guest machines and about half a dozen Unix.

All Unix machines are fine (maybe a few had issues with the virtual NIC names suddenly changing, but nothing catastrophic).

All Windows machines suddenly reporting that their virtual HDDs cannot be found. The VDI images are still where they used to be, in plain view.
But we cannot do anything with them: they cannot be released in the media manager, cannot be deleted, cannot be re-added to the machines.

Cannot register the hard disk '/dmp/WinXPDisk2.vdi' {168a7788-c2e7-4f53-9f1f-bedf1819b030} because a hard disk '/dmp/WinXPDisk2.vdi' with UUID {168a7788-c2e7-4f53-9f1f-bedf1819b030} already exists.


Result Code:
NS_ERROR_INVALID_ARG (0x80070057)
Component:
VirtualBoxWrap
Interface:
IVirtualBox {0169423f-46b4-cde9-91af-1e9d5b6cd945}
Callee RC:
VBOX_E_OBJECT_NOT_FOUND (0x80BB0001)

We released and deleted all the snapshots associated with that machine, but it still says in the media manager that there is a snapshot #1.
Deleting this entry is not possible. We searched in the machine XMLs for the UUID and it was not found. Why does it still think this hard disk exists???
Why can't this program allow us to attach a VDI without giving excuses for not doing just that? At this point no one gives about snapshots or anything else - we just need to do work and this behaviour is simply infuriating.

PS: Actually, sorry, not all Windows VMs were destroyed! Windows 98 survived and is well. Just those pesky XP, 7 and 2012 are all tits up.
PPS: And sorry again, not all UNIX VMs are fine: there is no more mouse cursor in the Solaris VM. Who wouda thunk!

[Perryg]

What prompted this? Did you upgrade VirtualBox or anything like that?

I would tell you to not do anything like deleting snapshots but it sounds like it is too late. I would suggest that you do not delete the actual snapshots as they might be recoverable. At this point you should post the exact cause and hang on for assistance.

[Abrugal]

Yeah, installed the update. We do not have any important snapshots, just those that were taken upon installing the guests. No one cares about them.

[Perryg]

Assuming this is a *nix host, you should see ~/.config/VirtualBox.xml. Post that as an attachment here. You will need to change the extension to .txt or it will not allow you to upload. Late here so I will not see it until morning but will then.

[Abrugal]

We could not wait that long and blew away virtualbox.xml and all machine files and re-created from scratch.
The company got fed up with this sort of issues and not going to use VB anymore, they are buying VMWare.

[michaln]

The company got fed up with this sort of issues and not going to use VB anymore, they are buying VMWare.

Good decision. Then you can get paid support.

Of course you never really explained what the "issues" were so it's impossible tell how many were caused by a PEBKAC.

[scottgus1]

(Just in case Abrugal comes back:)

And of course there's that nagging question, Ought we to put new mission-critical software on a mission-critical machine?

Answer is always "NO!!"

The unexpected is always expected. Test first on another host you can experiment with and see what happens. Then implement if and when the unexpected is accounted for.

Our office host server running the domain controller, email server and antispam, and LOB application server, and a couple spare workstation environments, five guests total, is still using 4.2.16, on the "if it ain't broke don't fix it" paradigm. Will I put v5 on it? Maybe, one day. Will I put the latest on it untested, the day before it will be essentially needed for business activities? Absolutely not! It would be crazy to do so. Doing the upgrade on a live system is the first PEBKAC to be pointed out.