VM Lock-Up with VB 2.0.2 and Ubuntu Hardy

[Ken Preslan]

I'm having a weird problem with VirtualBox 2. I'm trying to use it to break my one server into two parts (the native server and a virtual machine) and split services across the two. I'm using bridged HIF networking, so the setup should look like two different machines.

The problem I'm seeing is that the virtual machine works fine for a while (2-3 minutes), and then it becomes unresponsive. The VM's CPU usage goes way down and the VM doesn't reliably talk to the network or through VRDP. In the end I have to do a "VBoxManage controlvm testvbox1 poweroff" to get rid of the VM.

The weird thing is the problem only occurs the first time I run the VM after I reboot the physical machine. After I see the problem and stop the VM, I can restart it and it works fine from then on -- until I reboot the host again.

Any suggestions?

My setup:

• VirtualBox 2.0
• A generic Pentium 4 box
• Ubuntu Hardy Server as both the host and guest
• No X servers on either the host or guest
• Bridged HIF networking (both the host and guest are using static IPs)
• I'm launching the virtual machine with VBoxManage startvm testvbox1 -type vrdp.

More details:

• I've tried "nohz=off" on both the host and guest and it doesn't help.

• When I see the problem, the CPU usage drops from 0.3% to 2% cpu load for the idle VM to not showing up in "top" most refreshes. So, the VM is definitely doing less.

• The problem happens whenever I run the VM the first time after boot. Whether I run it as part of the boot scripts or wait a few minutes and run it by hand makes no difference. The second run always works right.

• The problem happens whether I run the headless frontend or the standard GUI frontend.

• This is weird: During the 2-3 minutes of "good" time before the VM goes all wonky, I ssh (with X forwarding) from my laptop into the VM and run a xterm so I can type commands to the VM and see what's going on. When the VM start misbehaving, I can still type commands to the VM, but the output stalls. For example, I type "ps ax" and hit enter it will print a few lines of result and then stop. If I then move the mouse into and out of the xterm, it will print a few more lines. It seems like the focus events that the laptop's X server sends to the VM cause it to wake up and do work. It's like the VM is dropping interrupts or something.

• A VRDP connection works fine for the "good" 2-3 minutes, but completely locks up when the VM goes wonky.

• Network connections to the host work fine through all of this.

• This happens with VirtualBox 2.0.0 and 2.0.2

• Thanks for reading all this. I'd be grateful for any help you guys could offer.

Forum Thread: ​http://forums.virtualbox.org/viewtopic.php?t=9590

[Ken Preslan]

More things I've tried:

• I've never enabled USB on the guest, so maybe this is irrelevant, but the bug appears whether or not I do the mountdevsubfs.sh thing mentioned in the FAQ.

• The problem doesn't seem to be related to HIF networking. I see the same problem if I temporarily switch the guest to use NAT. I didn't change any of the networking stuff on the host, though. So, I haven't ruled out the process of bringing up the vbox0 interface as being a factor yet.

• Recently, I've been playing with two VMs. I start both VMs at the same time from my boot scripts, they work fine for a few minutes, and then they both stop working at the same time. But, if I start one VM by itself and it screws up, I can start up the other and it will work fine. In other words, it's the first VM of any kind that has the problem, not the first run of each individual VM.

• I've been playing with a near-identical guest image on VB2 running on a Mac client. I have not seen any problems there at all.

[plenque]

I think I'm facing the same problem, but I don't have an exact way to reproduce it. Also, there's no related information in any log (guest or host).

I'm using a Hardy desktop host, with a Windows XP guest. Not using VRDP.

Regards, Mauro.

[Ken Preslan]

VBox.log of a unresponsive VM

[Ken Preslan]

VBox.log of the same unresponsive VM after I issued a "VBoxManage controlvm testvbox1 poweroff"

[Ken Preslan]

VBox.log of a happily running VM

[Ken Preslan]

VBox.log of of the working VM after I shut it down after a few minutes by running "halt" in the guest OS

[Ken Preslan]

Just a description of the first four attachments:

I rebooted the host box. After the host box was up, I ran "VBoxManage startvm testvbox1 -type vrdp" and waited for the VM to lock up. I then copied out the VBox.log to get "VBox.log-broken". I then did a "VBoxManage controlvm testvbox1 poweroff" and copied the log to get "VBox.log-broken-after-poweroff".

Then, I restarted the same VM (with the same command as above) and copied the log to get "VBox.log-working". I waited a few minutes to prove the VM was working right, and then issued a "halt" in the guest OS and copied the log to get "VBox.log-working-after-halt".

[Ken Preslan]

For whatever it's worth:

I turned off the host's bridge, got rid of /etc/vbox/interfaces, and turned my VMs back to the NAT setting. I then rebooted. I still see the lock up. So, it definitely has nothing to do with HIF networking at all.

[Ken Preslan]

So, this appears to be a 2.X-only bug. I downgraded the my VB .deb and guest additions to 1.6.6 and I can't reproduce the problem.

I hope that narrows the search for the bug some. :-)

[Frank Mehnert]

Thanks for your findings. Are you 100% sure that this is a 2.0.0 regression?

To help debugging this problem you could do the following: Start the VM with

gdb -args /usr/lib/virtualbox/VBoxHeadless -startvm testvbox1

When the guest does not respond anymore, force the process to terminate with a core dump. I've updated the instructions at ​http://www.virtualbox.org/wiki/Core_dump. Keep in mind to allow SUID root processes to dump core dumps and kill the process with -4 (as described there).

Send the core dump to frank _dot_ mehnert _at_ sun _dot_ com. If the compressed file is bigger than 4MB (very likely), try to make it available somehow for me for download (preferred) or use some file sharing service (megaupload.com, yousendit.com or similar).

[Ken Preslan]

VBox.log from a working VM run with VB 1.6.6.