[Solved]"Host system reported disk full" but plenty of space

[phansen]

VirtualBox: 4.3.8
Host: Windows 7 64-bit
Guest: Kubuntu 32-bit, current version

Recently after my VM has been running for a little while VirtualBox will error out with the message:

"Host system reported disk full. VM execution is suspended. You can resume after freeing some space."
Error ID: DevAHCI_DISKFULL

This message refers to the host system. However my VMs are running on a 2 TB drive that currently has a little over 900 gigs free. The host has plenty of free space. I created this Kubuntu VM with a dynamically expanding disk at 80 gigs, and it has grown to the full 80 gig size. Could that be related? Within the Kubuntu VM the system reports there are about 23 gigs free.

Any ideas why I'm getting this error message and how to fix it? Currently I have to shutdown the VM and restart it. Sometimes I have to repair the file system after doing this just to get the machine to boot.

[phansen]

From the log:

Code: Select all

00:29:50.792129 AHCI#0P0: Write at offset 1148932096 (524288 bytes left) returned rc=VERR_INVALID_PARAMETER
00:29:50.798090 AHCI#0P0: Write at offset 1149456384 (524288 bytes left) returned rc=VERR_INVALID_PARAMETER
00:29:50.799729 AHCI#0P0: Write at offset 1149980672 (307200 bytes left) returned rc=VERR_INVALID_PARAMETER
00:29:50.800712 AHCI#0P0: Write at offset 1151336448 (524288 bytes left) returned rc=VERR_DISK_FULL
00:29:50.800823 AHCI: Host disk full
00:29:50.801323 VM: Raising runtime error 'DevAHCI_DISKFULL' (fFlags=0x6)

I've slightly trimmed the above. It tried each offset 6 times with the same VERR_INVALID_PARAMETER before the final offset returned VERR_DISK_FULL.

It seems to be that VirtualBox is trying to write to an incorrect location, and then decides the host disk is full when in actuality the VM's dynamic disk has reached it's full size.

Has anyone run into this before? What's my solution moving forward? Should I try resizing the disk to make it larger? But say I double it to 160 gigs - I don't want to just run into the same problem when the disk reaches the full capacity again.

[socratis]

Could you please post the full log (zipped) as an attachment? Also, run from an (administrator) command prompt the "fsutil volume diskfree c:" in your host as well as "df" in your KUbuntu.

[phansen]

Windows host (VMs stored on D:):

Code: Select all

C:\Windows\system32>fsutil volume diskfree d:
Total # of free bytes        : 886539218944
Total # of bytes             : 2000263573504
Total # of avail free bytes  : 886539218944

Kubuntu vm:

Code: Select all

phil@Hobbiton:/$ df
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda1       81406704 59466192  17782256  77% /
none                   4        0         4   0% /sys/fs/cgroup
udev             2055748       12   2055736   1% /dev
tmpfs             413612     1016    412596   1% /run
none                5120        0      5120   0% /run/lock
none             2068052       76   2067976   1% /run/shm
none              102400       20    102380   1% /run/user

[mpack]

Just to confirm: as far as I can tell you are not using snapshots or any other form of differencing image (linked clone, immutable disk etc), is that correct?

If yes then I can see no obvious reason for the error. If the VDI has already grown to its max allocation then it shouldn't need any more space on the host, unless there's been some kind of header corruption. Space in the guest isn't relevant.

You can try cloning the VDI with CloneVDI. Actually you don't need to let it run to completion, I'm more interested in whether CloneVDI reports any problems with the header.

Have you done anything noteworthy to this VDI in the past, e.g. increase the size using VBoxManage?

[phansen]

No it's not using snapshots or anything like that. On this VDI I enlarged it one time (from 50->80 gigs) using VBoxManage about 9 months ago. This problem just started last week which I'm going to guess is when the dynamic disk reached the allowed size.

When I load it as a source in CloneVDI the validation result says: "Source file corrupt - block map contains errors". So it's as you suspected. (Great tool by the way, I will definitely make use of it in the future.)

Any idea what might have caused that corruption? I don't want to run into this again.

Also, what do you think my options are at this point? Any way to fix the VDI or should I copy my data out and start a fresh VDI?

[mpack]

Yes, I'm pretty sure I know what the problem is.

Basically, there used to be a bug in the VBoxManage resize function: if you increased the size by more than a certain amount in a single step (and 30GB increment is probably enough) then it failed to increase the block map enough to map the entire disk. So as soon as the disk reaches the "bad" block map entries, the VDI starts corrupting its own header. It's a great pity that you didn't use CloneVDI 9 months ago. Oh well.

If the VM can still boot up then yes, I would create and attach a secondary 80GB (or larger) VDI and transfer the entire disk image onto it, from the inside - e.g. using dd. VirtualBox may error out at some point, but it's worth a try - and we can jump that bridge when we come to it. Of course down the line you should do a disk check inside the guest to fix any residual filesystem corruption.

[phansen]

I tried copying the disk data to a secondary disk, but the copied file system was corrupted. I could not get Kubuntu to boot from the new disk, and running things like fsck could not fix the errors. Rather than spending more time trying to fix it I decided to start a new VM with a fresh install of Kubuntu and copy my relevant data files. Thankfully since I can still boot the system in the corrupted VDI I was able to copy everything I needed.

Thanks a lot for your help mpack.

[mpack]

That's odd. If the original can still boot up then a whole disk image with dd should be identical and therefore also be able to boot up. I suspect you copied a partition instead of the whole disk, or if the error was from grub complaining about not being able to find the disk, then you maybe needed to change a disk UUID in the grub script.

Nevertheless, that's all academic now. If you're happy to start with a fresh copy then that will certainly be a permanent fix. Thanks for reporting back.