VirtualBox

Ticket #14137 (reopened defect)

Opened 3 years ago

Last modified 14 months ago

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

Reported by: JeremyB Owned by:
Priority: major 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

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

Change History

Changed 3 years ago by JeremyB

VBox.log

comment:1 Changed 3 years ago by JeremyB

Additional notes:

VBoxAdditions are installed and match the VirtualBox version.

comment:2 follow-up: ↓ 3 Changed 3 years ago by frank

  • Status changed from new to closed
  • Resolution set to invalid

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.

comment:3 in reply to: ↑ 2 Changed 3 years ago by JeremyB

  • Status changed from closed to reopened
  • Resolution invalid deleted

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 Changed 3 years ago by frank

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 Changed 3 years ago by JeremyB

New VBox.log & 'ps aux'

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

Changed 3 years ago by JeremyB

VBox.log with single guest CPU

Changed 3 years ago by JeremyB

ps aux - at time of incident

comment:6 Changed 3 years ago by frank

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 Changed 3 years ago by JeremyB

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 Changed 3 years ago by JeremyB

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.

Changed 3 years ago by JeremyB

Changed 3 years ago by JeremyB

Host CPU Usage

Changed 3 years ago by JeremyB

comment:9 Changed 2 years ago by JeremyB

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

comment:10 Changed 2 years ago by frank

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

comment:11 Changed 2 years ago by 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

comment:12 Changed 2 years ago by 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?)

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

comment:13 Changed 2 years ago by 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.

comment:14 follow-up: ↓ 15 Changed 2 years ago by 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.

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

comment:15 in reply to: ↑ 14 Changed 2 years ago by 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.

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

comment:16 Changed 2 years ago by 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.

comment:17 Changed 2 years ago by vushakov

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 follow-up: ↓ 19 Changed 14 months ago by 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

comment:19 in reply to: ↑ 18 Changed 14 months ago by vushakov

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.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use