VirtualBox

Opened 9 years ago

Closed 4 years ago

#14137 closed defect (obsolete)

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

Reported by: Jeremy Beker Owned by:
Component: VMM Version: VirtualBox 4.3.28
Keywords: Cc:
Guest type: Linux Host type: Mac OS X

Description

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.)

Attachments (6)

VBox.log (53.6 KB ) - added by Jeremy Beker 9 years ago.
VBox.log
VBox Single CPU.log (51.3 KB ) - added by Jeremy Beker 9 years ago.
VBox.log with single guest CPU
ps.txt (6.7 KB ) - added by Jeremy Beker 9 years ago.
ps aux - at time of incident
VBox Single CPU 2.log (51.3 KB ) - added by Jeremy Beker 9 years ago.
Screen Shot 2015-06-02 at 8.58.00 AM.png (219.3 KB ) - added by Jeremy Beker 9 years ago.
Host CPU Usage
ps2.txt (6.3 KB ) - added by Jeremy Beker 9 years ago.

Download all attachments as: .zip

Change History (26)

by Jeremy Beker, 9 years ago

Attachment: VBox.log added

VBox.log

comment:1 by Jeremy Beker, 9 years ago

Additional notes:

VBoxAdditions are installed and match the VirtualBox version.

comment:2 by Frank Mehnert, 9 years ago

Resolution: invalid
Status: newclosed

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.

in reply to:  2 comment:3 by Jeremy Beker, 9 years ago

Resolution: invalid
Status: closedreopened

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.

comment:4 by Frank Mehnert, 9 years ago

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%).

comment:5 by Jeremy Beker, 9 years ago

New VBox.log & 'ps aux'

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

by Jeremy Beker, 9 years ago

Attachment: VBox Single CPU.log added

VBox.log with single guest CPU

by Jeremy Beker, 9 years ago

Attachment: ps.txt added

ps aux - at time of incident

comment:6 by Frank Mehnert, 9 years ago

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?

comment:7 by Jeremy Beker, 9 years ago

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.

comment:8 by Jeremy Beker, 9 years ago

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.

by Jeremy Beker, 9 years ago

Attachment: VBox Single CPU 2.log added

by Jeremy Beker, 9 years ago

Host CPU Usage

by Jeremy Beker, 9 years ago

Attachment: ps2.txt added

comment:9 by Jeremy Beker, 9 years ago

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

comment:10 by Frank Mehnert, 9 years ago

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

comment:11 by k3rmit, 9 years ago

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

comment:12 by Anton Backer, 8 years ago

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?)

Last edited 8 years ago by Anton Backer (previous) (diff)

comment:13 by orengelo, 8 years ago

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.

comment:14 by pgrunwald, 8 years ago

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.

Last edited 8 years ago by pgrunwald (previous) (diff)

in reply to:  14 comment:15 by pgrunwald, 8 years ago

Actually, playing around further it seems the issue crops up whenever the database is hit.

Version 0, edited 8 years ago by pgrunwald (next)

comment:16 by pgrunwald, 8 years ago

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.

comment:17 by Valery Ushakov, 8 years ago

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.

comment:18 by GSilva, 7 years ago

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

in reply to:  18 comment:19 by Valery Ushakov, 7 years ago

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.

comment:20 by aeichner, 4 years ago

Resolution: obsolete
Status: reopenedclosed

No response, closing.

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use