What should happen when you run out of disk space..

[NeBlackCat]

..on the volume on which a VM resides, when executing it?

I just set up a temporary VM to install Win7, and it kept getting to "copying Windows files 67%" and then hanging. Both the VM window and main VirtualBox GUI were then locked up and had to be killed. The VM's vbox file size was then always 0 bytes (had to recreate it from .vbox-prev), and its main virtual disk (an expanding VHD) was corrupted and had to be deleted/recreated.

After (naturally?) assuming all sorts of other things, I noticed the volume had 4GB free at the start, and must have been running out of space as files were copied to the VHD .

This doesn't strike me as a very graceful way of handling an out of disk space error.

Host = Ubuntu 10.10 64 bit
VirtualBox = 4.0.4.

Bug report?

[mpack]

Yes, you better send a bug report to MS.

Meaning that I know for a fact that VirtualBox reports an error to the guest, so it must be the guest that isn't handling it as you would like. Perhaps the Windows installer, having determined that the partition had free space at the beginning, can't cope with all apparantly free sectors going bad at once midway through the first step. Can't say I blame it. It's an unusual situation to say the least.

I doubt MS will give this one high priority.

[NeBlackCat]

I can't see how it's a guest (Windows) problem that the host (VirtualBox on Linux) locks up and loses everything because it runs out of disk space when trying to increase the size of the virtual disk.

Surely there should be an error message on the host, and automatic pausing of the VM (without data loss or dead processes) until some space is freed up?

[BillG]

This all sounds familiar. Wasn't there a similar discussion recently? Or was that on a Windows host.

I imagine the result would be the same. There is really nothing which VirtualBox, which is just an application program running on the host, can do it the guest or host OS runs out of disk space. I would expect a catastrophic failure with no warning and no recovery in Windows.

[mpack]

If the host OS (which in this case effectively includes a VBox BIOS layer) returns an error notification to the application when an error occurs, then that host OS has done its job. Failure of the application to respond appropriately to that error, for example by retrying an infinite number of times, or by not noticing the error at all and proceeding to the next step, would be a bug in the application concerned. The latter is what I believe is happening.

Should VBox abort? I think not. A decision to abort the current task due to repeated errors is typically taken by the application, not the host OS. In fact it is usually considered a bug in the host OS if it aborts (e.g. if you see a BSOD in Windows).

[Leak]

Should VBox abort? I think not. A decision to abort the current task due to repeated errors is typically taken by the application, not the host OS. In fact it is usually considered a bug in the host OS if it aborts (e.g. if you see a BSOD in Windows).

If it is unable to expand it's VDI file shouldn't VirtualBox handle this like it handles being unable to allocate more RAM, i.e. by pausing the VM and allowing the user to make some more room then continuing upon unpausing the VM as if nothing had happened - instead of corrupting the VDI?

[NeBlackCat]

Should VBox abort? I think not. A decision to abort the current task due to repeated errors is typically taken by the application, not the host OS. In fact it is usually considered a bug in the host OS if it aborts (e.g. if you see a BSOD in Windows).

If it is unable to expand it's VDI file shouldn't VirtualBox handle this like it handles being unable to allocate more RAM, i.e. by pausing the VM and allowing the user to make some more room then continuing upon unpausing the VM as if nothing had happened - instead of corrupting the VDI?

Exactly. And not just corrupting the VDI (actually VHD) but also locking up both the host VM process and even the main virtualbox GUI process, requiring them to be externally killed. I wouldn't bet on any other VMs running at the time to emerge unscathed either, and will test that. It "feels" like a "doesn't handle resource depletion correctly" type of bug, which is a bit unexpected for such a mature product, but these things happen. I think I'll try and gather a bit more information and file a bug report.

[mpack]

If it is unable to expand it's VDI file shouldn't VirtualBox handle this like it handles being unable to allocate more RAM, i.e. by pausing the VM and allowing the user to make some more room then continuing upon unpausing the VM as if nothing had happened - instead of corrupting the VDI?

How can it pause the VM with no disk space? I never pause/hibernate a VM, so I'm certainly no expert on the subject, but doesn't pausing the VM involve doing a memory dump to disk?

(edited to fix annoying typo).

[mpack]

Exactly. And not just corrupting the VDI (actually VHD)

What kind of corruption occurred? Running out of disk space should not per se corrupt files which happen to be open, even for writing (cache complicates matters a bit, but that's the general case). Of course the VHD format itself is badly designed, placing its "header" at the end of the file, so if you run out of disk space while expanding the image there's no place to put the footer. Perhaps there is more that VBox could do in that department, but really it was your choice to use VHD despite its known shortcomings (they've been discussed on this site before, not least by me!).

but also locking up both the host VM process and even the main virtualbox GUI process

Your earlier description made it sound like it was the guest app which locked up, not anything on the host.

[Sasquatch]

Pausing a VM is essentially putting the VM in sleep, instead of hibernate. No additional disk space is used. When the Host is running out of disk space, this is just what has to be done. Exactly the same as out of RAM. VB should in now way crash the Host or itself, let alone corrupt it's own files (VHD, VDI, whatever). If VB does NOT pause itself to prevent corruption in whatever way possible, it's a bug. This has always worked in the past.

[Leak]

How can it pause the VM with no disk space? I never pause/hibernate a VM, so I'm certainly no expert on the subject, but doesn't pausing the VM involve doing a memory dump to disk?

Nope, it just involves suspending the running VM (try it - hit Host+P sometime), overlaying the displayed image with gray scanlines and not doing anything until you hit Host+P to unpause the VM again. The same thing happens when the VM tries to allocate more memory and fails, like while booting Windows - just free up some more RAM and unpause the VM to see what happens; in the worst case it'll just pause again...

VB should in now way crash the Host or itself, let alone corrupt it's own files (VHD, VDI, whatever).

Well, it did corrupt the .vbox file according to the first post - I'd think that on shutdown (or whenever else the file is written to) it would write the new contents to a temporary file, and only when that succeeds it would delete the old file and rename the temp file to match the original file's name. But in this case it looks as if something went wrong...

[mpack]

The same thing happens when the VM tries to allocate more memory and fails, like while booting Windows - just free up some more RAM and unpause the VM to see what happens; in the worst case it'll just pause again...

Well fair enough, but the situation with disk errors is IMHO different. Client apps (outside of critical safety designs) aren't expected to cope with bad memory (i.e. a chunk of memory which appears to be present until you try to use it), but they are expected to cope with the mundane: disk errors. It isn't for VirtualBox to assume that they can't cope, just pausing the VM, potentially (say) stopping an important service in its tracks.

I'm still waiting to get a clarification on why this error would cause virtual drive corruption: AFAIK all that's happened here is that VBox refused to do a write. That shouldn't invalidate previous writes. I think what we have here is a separate problem to do with the reliability or design of VHDs.

[Leak]

The same thing happens when the VM tries to allocate more memory and fails, like while booting Windows - just free up some more RAM and unpause the VM to see what happens; in the worst case it'll just pause again...

Well fair enough, but the situation with disk errors is IMHO different. Client apps (outside of critical safety designs) aren't expected to cope with bad memory (i.e. a chunk of memory which appears to be present until you try to use it), but they are expected to cope with the mundane: disk errors. It isn't for VirtualBox to assume that they can't cope, just pausing the VM, potentially (say) stopping an important service in its tracks.

IMHO the "client app" here would be the guest OS itself, and I'm pretty sure there's no way to signal "hiya, I've told you the drive was so-and-so big but, uh, actually that was lying on my part and there's really not enough space here for all the clusters I've told you there'd be..." - you really, really can't expect that to be passed down to an application running on the guest OS in the VM in a useful manner...

And to be honest, I'd rather have the VM pause and be able to rectify that situation than signalling seek/write errors for each cluster that couldn't be written to (which would really be the only thing you could do) to the guest OS; I don't think too many applications are built to gracefully handle sudden disk errors as you usually use RAID (bad idea in this case) to migitate those - for instance, anything relying on a database running in the VM will usually crash and burn as the database won't be able to extend it's log files...

np: Hauschka - No Sleep (Salon Des Amateurs)

[NeBlackCat]

Exactly. And not just corrupting the VDI (actually VHD)

What kind of corruption occurred? Running out of disk space should not per se corrupt files which happen to be open, even for writing (cache complicates matters a bit, but that's the general case). Of course the VHD format itself is badly designed, placing its "header" at the end of the file, so if you run out of disk space while expanding the image there's no place to put the footer. Perhaps there is more that VBox could do in that department, but really it was your choice to use VHD despite its known shortcomings (they've been discussed on this site before, not least by me!).

I didn't look into the VHD file to see what inconsistency had been introduced, I just noted that VBox complained about it being invalid when I restarted it, and none of the mounting tools I had at hand (inc Win7 disk admin) would mount it either.

Yeah I know VHDs aren't "the best" but they have by far the best support across Windows and Linux, eg for direct mounting and manipulation outside of VBox, and for general imaging use. So I've standardised on them for everything now.

but also locking up both the host VM process and even the main virtualbox GUI process

Your earlier description made it sound like it was the guest app which locked up, not anything on the host.

Sorry about that. The guest was locked up, but not because of anything going wrong inside the VM itself. The Win7 installer in the VM was chugging away nicely, copying installer files to its C:, but never got past 67% because, at that point, VBox ran out of disk space trying to expand the virtual disk, and locked up dead.