VBoxHeadless reliably eating 100% CPU

[harveyr]

Hi all,

Summary

When I start the VM up, everything is fine. However, at some point, the VBoxHeadless process will start eating ~103% CPU indefinitely on the host. There will be virtually no activity in the guest -- less than 1% CPU usage -- but VBoxHeadless will just grind away forever.

[Edit Aug 3, 2015] We're not sure what causes this. It appears to be network activity, a suspicion that's supported in the thread below.

System Details

* Host: Macbook Pro 2.7 GHz Intel Core i7, 16gb, SSD, OS X Yosemite 10.10.3
* Guest: Ubuntu 14.04 (the ubuntu/trusty64 Vagrant box)
* Virtualbox 4.3.28
* Vagrant 1.6.5
[Edit Aug 3, 2015] Condition also exists on Virtualbox 5 / Vagrant 1.7.4

What I've Tried

* Started out with NFS mounts. Tried rsync instead to see if it would help. No luck.
* Killing off processes one by one in the guest. Though I may have missed something.
* Disabling Nested Paging in Virtualbox.
* Vagrant suspend/resume cycles.
* Setting the cpuexecutioncap to 50. VBoxHeadless still ran at >100% CPU.
* Allocating 1, 2, and 4 CPUs. No difference.
* Killing my IDE (PyCharm, which does heavy I/O from time to time).
* Starting a separate dummy VM (recommended in old posts about a similar issue).
* Installing the vagrant-vbguest plugin to ensure guest additions are up to date.

Any thoughts? I want to get my team up and running on this soon, but this is a blocker.

Thanks for your time!

Harvey

[Ramshankar]

Could you please upload VBox.log for the VM which exhibits this behaviour?

[harveyr]

Here you go. It doesn't look like anything's appended to that log after the guest startup, but you probably knew that. Thanks!

[mpack]

00:00:00.086744 NumCPUs <integer> = 0x0000000000000004 (4)
...
00:00:00.204117 Full Name: Intel(R) Core(TM) i7-3740QM CPU @ 2.70GHz
00:00:00.203955 Physical host cores: 4

Leaving no cores for the host. Hardly surprising that performance suffers. Max cores for the guest should really be no more than 2.

FYI, we prefer that you shut the guest down before grabbing the log - if you copy a file when it's still open then of course it will be truncated.

[harveyr]

Leaving no cores for the host. Hardly surprising that performance suffers. Max cores for the guest should really be no more than 2.

FYI, we prefer that you shut the guest down before grabbing the log - if you copy a file when it's still open then of course it will be truncated.

Good to know. I'll re-post. Regarding the cores, I've tried separately with 1, 2, and 4.

[harveyr]

Here's another log. I restarted and provisioned the guest, poked around until the host CPU started pinning, shut the machine down, and grabbed the log file.

[harveyr]

Oops, I dropped the guest's core count but didn't reload those settings. Will post again.

[mpack]

It's nicer if you compress the logs too. Saves a few disk sectors on the server, and you won't hit the attachment size limit so easily.

[Ramshankar]

Please use .zip for compression if you are planning to compressing the logs. The VirtualBox team is on a wide variety of platforms when they look at this, zip tends to be the least troublesome among all of them.

[loukingjr]

.zip happens to be the default for OSX so it is also the easiest.

[harveyr]

Zipped log attached. Thanks!

[harveyr]

For what it's worth, other members of my team are seeing this as well, both on OS X and Linux.

[harveyr]

Are there any other logs I can pull that might help diagnose this?

[michaln]

"Sample Process" in Activity Monitor will probably have some useful information.

[harveyr]

Sampling the process seems to hang, as shown in the attachment.

Edit: Attached the Activity Monitor stats for the process, in case it's at all helpful.