VM locks up under heavy disk activity

Since Virtualbox 3.0 I (and another user I know) have experienced semi-repeatable lockups of our Virtualbox VMs when the guest OS tries to do a lot of disk I/O.

The symptoms are that the guest display stops updating; though the mouse still moves, it does not respond to clicks (we're using the guest additions though so I guess the mouse moving does not really mean anything). The guest kernel responds to low level networking stuff, enough to return a 'connection refused' message to the host when I try to SSH in to see what's going on.

I haven't reported this until now because it is not possible to trigger this bug reliably, and the guest's log file doesn't contain anything useful; however I ran into it five times in as many days in the following circumstances:

Run 'wineboot' from wine 1.3.9 (creates ~/.wine, containing a lot of small files ~/.wine)

Run 'git merge' with a sufficiently complex merge

Copy a lot of files to a vboxsf shared folder on the host

Over the months I have tried tweaking various guest settings, such as enabling/disabling the virtual disk controller cache, trying a PATA virtual disk controller rather than SATA, etc) but no existing open seems to make a difference.

My host is Windows 7 on amd64, and my guest is Debian GNU/Linux using 2.6.32.

I often find that performing a lot of I/O does cause the guest to hang, temporarily, but always with the disk activity indicator showing that the guest is blocked while reading data from/writing it to disk. That is not this bug; the temporary hang is resolved by merely waiting patiently.

When this bug occurs, the disk activity indicator is not lit. That is, the guest is not hanging while waiting for I/O to complete; rather, a batch of I/O caused virtualbox to freeze up.

I should also note that the magic sysrq key to trigger a reboot (alt+prtsc+b) does not work; the only way to recover is to power off the VM.

I'm having the same symptoms yrro reported. Guest stays frozen but the VM can be closed (vbox UI stays responsive). Changing to a single core seems to have delayed the crashes, but the problem is not solved. If I leave the VM open overnight it will always frozen in the morning (perhaps some disk intensive task happens overnight).
My host is Win7 64-bit with ubuntu 10.10 x86_64 (kernel 2.6.35-24)

Hey there, I'm getting the same issue myself, I used to have my VM hosted on an XP box that I now host on an Ubuntu 11 server utilizing the latest VB(4.0.8) and I still get the lock ups.

I am however suspect of mass database activity locking the machine. I host a Medawiki website that has had issues with MYSQL connections before. My issues have been correlatable to large hits of traffic.

Would love to see a fix or workaround for this.... It's quite frustrating and hard to troubleshoot.

Only one guest shows the problem - it is a SLES11SP1 with 2 processors and 2 GB memory. It hangs sometimes during heavy disk I/O.

Absolutely nothing is printed in the VBox.log when the hang happens. I can still connect remotely to the VBoxHeadless process and get the machine console (which looks normal except it does not respond to keypresses).

The only solution is to issue a poweroff with VBoxManage.

I have absolutely nothing to go on here... Adjusting memory size and processor count does not seem to change anything. Since no errors are reported anywhere and I have 12 other VMs running under the same host without any problems what so ever, I really don't know how to proceed with this.

I've seen this issue crop up recently in VirtualBox 4.0.8 when attaching a second SATA virtual disk to an Ubuntu virtual machine. Host is Windows 7 64-bit. Happens on the guest with any number of CPUs assigned (1 to 4). Host I/O cache is disabled. Guest is not running out of RAM.

Previously the system was fine (no lockups). The strange behavior started when I added a data-only virtual disk to expand available space. Verified with both a dynamic and fixed vdi. Both the primary OS disk and the expansion disk reside on the same physical disk. Primary is 16 GiB; Expansion is 40 GiB.

The UI locks for the duration of the I/O-intensive operations and then returns once they've completed. It seems like some sort of QoS issue. I tried enabling a different I/O scheduler on the guest (CFQ => deadline), but it had no effect.

I am going to attempt a single larger install to see if the issue stems from having an expansion virtual disk or some other factor.