After Reboot: Could not find an open hard disk with UUID...

[ah8]

Hi,

I'm running VirtualBox 4.1.18.r78361 on Microsoft Windows XP Professional Version 2002 SP3 on an Intel(R) Celeron(R) CPU 900 @2.20 GHz with 3GB RAM.

I'm trying to set-up a new test environment. So I've:

1. Created a new virtual machine with 1024MB of RAM and an 11.8GB .vdmk hard disk, split in 2GB files; the remaining options left to defaults.
2. Installed a Windows XP Professional + SP2 + SP 3 + current updates.
3. Installed a few base applications: Avira, Firefox, Acrobat Reader, PDF Creator, all resent versions.
4. Changing a few Windows settings like appearance, sound scheme, performance settings etc. to my preferences.

Since I want to keep that image as a ready-to-use image for future projects I shut down the guest system, removed it from the inventory, made a full backup and re-added it. No problems so far.

Now I cloned the image, shut down the VirtualBox Manager, rebooted the host system (for an explanation see below), removed and re-added the clone again (just to check), started the clone and installed the application software (for the curios one: Amtel AVR Studio).

After shutting down the clone, shutting down the VirtualBox Manager and rebooting the host again, the clone was unavailable and I got the following error message

Could not find an open hard disk with UUID {687a133a-0b06-4c0d-ab3e-43e27083d898}.
Result Code: 
VBOX_E_OBJECT_NOT_FOUND (0x80BB0001)
Component: 
VirtualBox
Interface: 
IVirtualBox {c28be65f-1a8f-43b4-81f1-eb60cb516e66}

Replacing .vbox by .vbox_prev in the VM folder did not help. I found, however, a workaround in the forum: Removing the VM from the inventory, deleting all files but the disk files from the VM folder an creating a new VM using the existing disk appears to work. That however, can only be a workaround, not the solution to the problem.

After installing the application software, shutting down the guest, removing it from the inventory, making a full backup, re-adding it to the inventory and rebooting the host system, however, I had the same problem again. Restoring the backup, though, worked, so the backup apparently is OK. Since the restore I had no further problems. (Though that was only yesterday!)

I've been trying to do the whole thing for three days an always got the same problem, though at different stages of the process, the one above is only the one where I have a detailed log. By now I have installed the clone about 5 times. I even had to reinstall the original VM once (i.e. the one to be cloned), since it showed the same problem after making the backup and in this case, the backup was corrupt too. I can remember to have seen a similar problem with earlier versions of VirtualBox as well, not to mention a number of apparently unrelated entries in the forum (all that suggesting that the clone operation itself can not be the problem).

Since I'm sure that no files have actually disappeared from the disk I'm left to conclude that VBox somehow gets the wrong configuration data. Further it is pretty unlikely that any other tool has corrupted the data (in way VBox is still able to read it), so the only remaining option is that VBox itself has written the wrong configuration to the disk. To narrow down the time when that might have happened was the reason I actually rebooted the host, since I assume that's the only fool proven way to make sure VBox has flushed all its data onto disk. The fact, that the clone was still available afterwards and could without apparent problems be removed and re-added seems to indicate, the the clone operation itself is not the problem. The information must got corrupted somewhere between re-adding the clone and the next shut down of the guest/VBox Manager/host.

The forum suggests the problem might be triggered by removing from and re-adding the VM to the inventory. I did this to avoid locking information, that might be left in the configuration by VBox and then could cause trouble later when trying to re-add the VM, either on the same or potentially a different host. Apparently that's not the case, but still removing and re-adding a VM shouldn't hurt and must not corrupt any configuration data.

I haven't verified that, though. On the one hand, I just haven't got the time, on the other hand, a single attempt is unlikely to prof anything, since the error is not exactly reproducible.

[ah8]

VBox.log: Log from VM to be cloned

[ah8]

VBox.log.1 (Log from the VM being cloned)

[ah8]

VBox.log.2 (Log from the VM being cloned)

[ah8]

VBox.log.3 (Log from the VM being cloned)

[ah8]

VBox.log (Log from the clone)

[ah8]

VBox.log.1 (Log from clone)

[aeichner]

Please reopen if still relevant with a recent VirtualBox release.