Windows - Delayed write faild corrupts .VDI file

Description

Running VirtualBox 3.0.10 on a Windows XP SP3 host and Ubuntu 9.10 running as a guest. The hosts disk is formatted as NTFS and the .VDI images are compressed using Windows disk compression to save disk space. Ubuntu 9.10 is using ext3 partitions within a dynamic disk image.

When the .VDI file gets above 50GB (as reported by Windows Explorer) then "Windows - Delayed Write Failed" errors are generated and the contents of the ext3 partitions are unrecoverable.

This isn't a new issue, I believe it has been in all of the 3.0.xx versions and also in the 2.1.x and 2.2.x versions that I used.

Your log file tells a rather different story than the bug description above.

First of all, VirtualBox reported that it ran out of disk space (after more than 17 hours, apparently things continued without trouble afterwards). VirtualBox complained about a corrupted image pre-header immediately. Never seen that happen in out of disk space situations, as VirtualBox doesn't need to extend the file to write to the pre-header. Could be a side-effect of the file compression.

The VM continued successfully (there are a number of seamless resolution changes which wouldn't work unless the guest OS is alive).

Then, after 22 hours totally out of the blue the host OS started signalling file locking violations. Together with the "delayed write" messages you're getting apparently it looks to me like this is caused by Windows, not by VirtualBox. When accessing disk images, VirtualBox is a normal application, and by definition they can't cause such "delayed write" errors unless there is an OS and/or hardware malfunction.

Any more details? With the currently available information it seems like VirtualBox gets sabotaged.

I remember seeing the out of disk space warning as the VM paused itself. This in itself was odd as the host machine had, and still has around 20GB disk space free - it is a 160GB disk as a single NTFS partition.

When I started to see the "delayed write" messages the only way I could close the VM was to kill the running process.

It may be that this is an issue with Windows or its use of compressed files but I have seen this a number of times when the .VDI file gets above 50GB.

Is there any way to turn on additional logging within VirtualBox to see what happens if i provoke the failure again?

The only way to get additional logging (the sources are your documentation...) would be to create a debug build of VirtualBox, set appropriate debug logging and reproduce. Debug builds have their own quirks though, as they do lots more consistency checking which can potentially lead to VM crashes which wouldn't happen with release builds. All in all not a walk in the park...