Guest OS with more than 3GB RAM locks up if more than 3GB written out to guest HDD

[MikeP]

• Host machine: AMD Phenom 9650 Quad-Core Processor /w 8GB RAM
• Host OS: Debian Lenny
• Guest OS: Guest OS: Debian Lenny, 1CPU, 3.5GB RAM, 10GB HDD, IDE controller
• running in 32-bit for host and guest

I have found if I have more than 3GB of RAM allocated to the Guest OS and execute a program which writes out more than 2.8GB of data to the guest hard drive, the guest machine locks up. Found first when trying bonnie++ for I/O benchmark testing. Able to repeat using dd if=/dev/zero of=testfile bs=1048576 count=3000.

What I see happening is as the large datafile is being written out on the guest machine, on the host, top reports the RES value for VBoxHeadless increases until it reaches 3.0g. Once RES reaches this value, the guest machine stops responding.

Nothing is written out to the vbox.log file. Attached is a screen shot with top running on the host (green text) and top running on the guest (white text) after the guest stops responding.

[Frank Mehnert]

Please could you attach a VBox.log file for such a failing session?

[MikeP]

Didn't find the log files the first time because I'm still getting use to VirtualBox throwing capital letters in file names.

The VBox.log.1 is just a start up and run of the guest with no adjustments made to the host.

The VBox.log is a guest run after I had the host kernel flush the cached pool. There was 2GB of Memory listed as free when the guest was paused due to the 'HostMemoryLow' error being raised.

[MikeP]

I am running 2.6.26-2-686-bigmem kernel on the host.

[Frank Mehnert]

Just tested this. Here, the VM aborts with a Guru meditation (VERR_NO_MEMORY). Of course, 3GB on a 32-bit host does not make sense with VirtualBox as the complete physical memory for the guest has to be mapped into the VM process.

[MikeP]

Were you testing under the same VB version or newer version?

Does it abort while it is running the bonnie++ test or writing out the 3GB file or when you attempt to start the VM?

To me, it would make sense to have the VM start with a warning, or not start at all, if the memory allocation setup for the VM exceeded the maximum memory which can be allocated by the VirtualBox engine? Waiting until the VM attempts to allocate the memory it thinks it has feels like closing the jail door the prisoner has escaped.

From the "keeping up with the Jones" point of view, I was able to setup the same VM under VMWare Server 2 on the same host machine, and the VM was able to complete the bonnie++ tests with no problem.

[Frank Mehnert]

Here it aborted when doing the dd if=... of=... test trying to create a 4GB file. I actually tested this with VBox 3.2.4. A Guru meditation is still not the correct behavior but actually users who assign more than 2.5GB memory to a guest on a 32-bit Linux have to know what they are doing, the VirtualBox GUI wouldn't allow to setup more than 2.5GB on a 32-bit host -- this is only possible with VBoxManage.

[MikeP]

I stumbled into it because I was doing side by side comparisons of performance and capability with an equivalent VMWare product. VBoxManage was the first way I ran across to setup the VM on a machine with no GUI interface setup. While experienced in general, I would not claim to have known what I was doing under VirtualBox at the time I was doing this testing.

Since the VM setup worked under the VMWare product before I tried it with VirtualBox, it was an unexpected result to have the VM pause while running due to an inability to address the amount of memory VBoxManage allowed me to allocate.