CPU runs to 100% with Idle guest using Vagrant Ubuntu image

[Jeremy Beker]

I am running vagrant on a Mac OS X (10.10.3) host system. Within 15-60 minutes of starting up a VM, the host CPU ramps up to 100% CPU usage while the guest is idle.

My vagrant guest is Ubuntu 64-bit.

Starting and stopping the VM will stop the runaway CPU but it will go back to 100% within the same time period again.

(I have seen numerous reports of similar situations without any resolutions.)

[Jeremy Beker]

VBox.log

[Jeremy Beker]

Additional notes:

VBoxAdditions are installed and match the VirtualBox version.

[Frank Mehnert]

Decrease the number of guest CPUs. Your host has only 4 physical cores with 2 hyperthreads per core. See the VBox.log file and see ​here. Therefore you should not assign more than 4 VCPUs to your guest.

[Jeremy Beker]

Replying to frank:

Decrease the number of guest CPUs. Your host has only 4 physical cores with 2 hyperthreads per core. See the VBox.log file and see ​here. Therefore you should not assign more than 4 VCPUs to your guest.

The behavior is the same regardless of the number of cores. It happens if I have it set to 1.

[Frank Mehnert]

Please attach a VBox.log file for that case (1 VCPU). Please do also attach the output of 'ps aux' in the guest when this happens (VM process hogs the CPU by 100%).

[Jeremy Beker]

New VBox.log & 'ps aux'

Guest OS showed 98% idle (via 'top') Host process showed 100% CPU

[Jeremy Beker]

VBox.log with single guest CPU

[Jeremy Beker]

ps aux - at time of incident

[Frank Mehnert]

Thnaks. Actually the 'ps aux' output shows that /usr/bin/ruby1.9.1 script/rails s occupies 22.3% CPU time so the guest is definitely not idle. I cannot spot anything unusual in the log file. The guest timer switched to 250 Hz for a short time but later to 18.20 Hz (guests which switch to 1000 Hz are suspicious).

Are you running any CPU-intensive application in parallel to the VirtualBox VM, or any other VMs?

[Jeremy Beker]

Odd that 'top' shows that the CPU is 98-99% idle.

There isn't much going on outside of the VM, no other VMs. (Basically just a text editor and a browser running against the rails process shown in the VM).

I guess the question is, is having the host CPU at 100% expected behavior for a 22% usage of a single core in a VM?

Activity Monitor in OS X shows that VirtualBox is the only significant user of CPU.

[Jeremy Beker]

So I think the 22% we saw was a fluke. The problem happened today again. I have attached new logs and a screenshot of activity monitor. There are no guest processes taking up any CPU (> 1%). VBoxHeadless is the only process taking up any significant CPU on the Host.

[Jeremy Beker]

Host CPU Usage

[Jeremy Beker]

Anything? Or is this ticket no longer being looked at? The problem still occurs frequently (i.e. Multiple times a day)

[Frank Mehnert]

Currently other priorities but this ticket is definitely not ignored. Please be aware that there are a lot of other tickets open.

[k3rmit]

Same issue here.

The host is a CentOS 6 and the guest a Windows 2012 R2.

This happened sporadically in the past, sometimes by restarting the VM the issue got away. Since 4.3.28 the workaround is not working anymore and the VM is using all the host's CPUs assigned, regardless of the number.

Thanks for working on this

[Anton Backer]

I work with multiple people for whom this issue is coming up pretty regularly and causes significant battery drain. Our host is OS X and the guest is CentOS.

(I'm leaving this comment primarily because I didn't find any other way to subscribe to change notifications for this issue. Does Trac really not support that?)

[orengelo]

I am having the same issue when using Virtualbox with Vagrant

Host: Mac OS X 10.10
Guest: Ubuntu Trusty

VBoxHeadless CPU usage shoots up to ~100% and stays there. This happens multiple times in a day.

[pgrunwald]

I am having the same issue with VirtualBox 5.0.8 and Vagrant 1.7.4, and I am able to reproduce the issue.

Host: Mac OS X 10.10, Guest: ubuntu/trusty64 (20151020.0.0)

My issue is exactly as described above, the VBoxHeadless process CPU usage reaches 100% and stays at that level until the box is restarted. If I run top on the guest machine, it shows essentially 0% CPU usage.

I am doing Ruby on Rails development and I am consistently able to reproduce the issue by logging in or out of the app I am developing. I am using the gem "devise" for user auth with basically vanilla settings (database authentication).

• Ruby 2.2.3
• Rails 4.2.4 (Devise 3.5.2)
• MariaDB 10.1.8 (mysql2 driver, libmariadbd-dev)

Here are the steps I can take to reproduce the issue (assuming a halted vagrant box with my Rails app mounted at /vagrant):

1. $ vagrant up
2. $ vagrant ssh
3. $ cd /vagrant
4. $ bin/rails server (nothing out of the ordinary at this point)
5. Navigate to the login page of the app and log in with correct credentials
6. After login process completes, the VBoxHeadless process shows 100% CPU usage on the host machine while running top on the guest machine shows essentially 0%.

Closing the browser window, stopping the Rails server or restarting the MariaDB service do not have any effect on lowering the CPU usage at this point. Restarting the guest machine with vagrant reload or vagrant halt/up solve the issue until the login/logout routes are hit again.

Hope this helps resolve the issue.

[pgrunwald]

Actually, playing around further it seems the issue crops up whenever the database is written. I will test some more use cases to confirm.

[pgrunwald]

I narrowed down the cause of the problem in my case: HTTP redirects in combination with connecting to the Rails server through the forwarded port.

The CPU usage of the VBoxHeadless process spiked when the Rails function redirect_to was used and the Rails server was being accessed through a forwarded port to the host machine.

In my case, I had

config.vm.network "forwarded_port", guest: 3000, host: 3000

and was accessing the server on my host machine browser at ​http://localhost:3000.

My solution:

Access the web server via private networking instead of through a forwarded_port.

Add private networking to the vagrant box, if you haven't already:

config.vm.network "private_network", ip: "192.168.3.4"

And then access the web server at ​http://192.168.3.4:3000 (assuming the web server is running at port 3000). Whatever the root cause, changing my access to private network has completely solved the problem in my case. Hope this works for the other people having this problem.

[Valery Ushakov]

What is the routing setup on your host and in your guest. If you have both NAT and host-only interfaces, you might have created a routing loop. Your guest will report no CPU activity, but host CPU will be used to pump packets through the routing loop. netstat -i in the guest will also show you growing number of packets received/transmitted.

[GSilva]

I can confirm the problem and the solution suggested by pgrunwald on using the private network ip instead of 'localhost' or '0.0.0.0' (my case) to access the webserver in the guest OS

I'm on Virtualbox 5.0.2

[Valery Ushakov]

Replying to GSilva:

I can confirm the problem...

Have you tried a more recent version?

If you still can reproduce the problem, please, can you provide the information requested in comment:17?

A wireshark packet capture of the http request that triggers the problem (both on the host and on the guest sides) might be handy too.

[aeichner]

No response, closing.