VirtualBox

Ticket #18089 (assigned defect)

Opened 12 months ago

Last modified 4 months ago

Host CPU load 100% for idle guest

Reported by: bcandler Owned by: pentagonik
Component: other Version: VirtualBox 5.2.20
Keywords: Cc:
Guest type: Linux Host type: Mac OS X

Description

Host: macOS 10.12.6 Guest: Linux (Ubuntu 16.04)

After upgrading Virtualbox to 5.2.20, I ran a single guest which I'd used many times before. The guest decided to do an auto-update, which is fine.

However even after the update had finished, on the *host*, CPU used by the VirtualBox process remained stuck at 100%, as shown by Activity Monitor and (here) "top -o cpu":

Processes: 326 total, 3 running, 323 sleeping, 1550 threads                                                         08:15:02
Load Avg: 2.34, 2.50, 2.10  CPU usage: 31.47% user, 7.26% sys, 61.25% idle
SharedLibs: 229M resident, 51M data, 62M linkedit. MemRegions: 65898 total, 7787M resident, 147M private, 1418M shared.
PhysMem: 14G used (4448M wired), 2268M unused. VM: 879G vsize, 627M framework vsize, 0(0) swapins, 0(0) swapouts.
Networks: packets: 197313/179M in, 123489/30M out. Disks: 385658/8849M read, 161264/4111M written.

PID   COMMAND      %CPU  TIME     #TH   #WQ  #PORT MEM    PURG   CMPRS  PGRP PPID STATE    BOOSTS         %CPU_ME %CPU_OTHRS
1810  VirtualBoxVM 105.5 17:19.54 44/1  5    392   2193M  8048K  0B     1810 1805 running  *1[5]          0.00000 0.00000
335   iTerm2       14.6  01:56.18 11    5    281-  164M-  34M-   0B     335  1    sleeping *0[305]        0.04101 1.50065

But inside the *guest*, CPU was ~99% idle. Again, here with "top" but inside the guest:

top - 08:16:00 up 44 min,  1 user,  load average: 0.00, 0.07, 0.11
Tasks: 583 total,   1 running, 582 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.3 us,  0.3 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  2048156 total,   238796 free,  1136680 used,   672680 buff/cache
KiB Swap:   786428 total,   747596 free,    38832 used.   554244 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
 4441 101001    20   0 2552704  62904  14900 S  0.3  3.1   0:05.32 java
 7579 brian     20   0   42240   4268   3172 R  0.3  0.2   0:00.02 top
    1 root      20   0   38320   6280   4016 S  0.0  0.3   0:02.16 systemd

After shutting down and restarting the guest, the problem went away. This again on the host:

Processes: 325 total, 3 running, 322 sleeping, 1501 threads                                                         08:18:39
Load Avg: 1.90, 2.28, 2.10  CPU usage: 2.68% user, 6.34% sys, 90.97% idle
SharedLibs: 229M resident, 51M data, 62M linkedit. MemRegions: 66300 total, 7793M resident, 150M private, 1428M shared.
PhysMem: 14G used (4458M wired), 2178M unused. VM: 876G vsize, 627M framework vsize, 0(0) swapins, 0(0) swapouts.
Networks: packets: 201757/182M in, 127536/32M out. Disks: 419879/9460M read, 166954/4317M written.

PID   COMMAND      %CPU TIME     #TH   #WQ  #PORT MEM    PURG   CMPRS  PGRP PPID STATE    BOOSTS          %CPU_ME %CPU_OTHRS
6140  VirtualBoxVM 7.8  00:49.13 41    4    396   2144M  18M    0B     6140 1805 sleeping *1[4]           0.00000 0.00000
0     kernel_task  7.1  07:13.29 134/4 0    2     1199M  0B     0B     0    0    running   0[0]           0.00000 0.00000

Change History

comment:1 Changed 12 months ago by carlosefr

I too am seeing this behavior since upgrading to VirtualBox 5.2.20 (with a CentOS 7 x64 guest). The host CPU is pegged at 100% while the guest is doing nothing (I've tried to stop almost everything inside the guest, but the CPU usage on the host remains at 100%).

I've also tried to boot the VM with "legacy" and "default" paravirtualization. The result is the same, after a while this behavior appears. It seems to be triggered by the host coming back from sleep.

The host is also macOS 10.12.6.

VirtualBox 5.2.21 r126213 also shows the problematic behavior, while 5.2.18 does not.

Last edited 12 months ago by carlosefr (previous) (diff)

comment:2 Changed 12 months ago by socratis

There are two more additional reports of similar behavior in the forums. See  https://forums.virtualbox.org/viewtopic.php?f=8&t=89896

comment:3 Changed 12 months ago by Samuel H.

I have the same behavior on OSX 10.13.6 with Ubuntu as Guest. Inside the guest i see low CPU usage, while on the host the 2 CPU-Cores used by the guest running at 100%.

I am using VirtualBox 5.2.20, but i had the same behavior on VirtualBox 5.2.18.

The paravirtualization-Setting is on default.

comment:4 Changed 12 months ago by ssh22

I have exactly the same problem after updating to 5.2.20. Host: MacOS 10.14 Mojave Guest: Centos 7.2

In my case i'm using Vagrant (2.2.0). When I start vagrant, everything runs normal. After a hour or so, I start hearing my macbook fan working like crazy. It's vboxhealdless process, started by vagrant - using 100-110% of the CPU. From there it doesn't go down until I restart vagrant, virtualbox or macos.

comment:5 Changed 12 months ago by planck_length

Same happening here on macOS 10.13.6. I also noticed that logd was > 100% activity, and when I ran Console I could see that VBoxHeadless (AudioToolbox) had generated the following half a million times:

396: buffer 0 ptr 0x7f9e9f0f4300 size 0

comment:6 Changed 12 months ago by liamk15

I'm having a similar issue since upgrading, it's fine after a restart and starts happening after waking from sleep.

In Console.app i can see approx 10k logs a second being added by VBoxHeadless

Error is something to do with AudioToolbox, see screenshot:  https://i.imgur.com/fE3zXmz.png

Virtual Box 5.2.20

Host: MacOS Mojave 10.14.1

Guest: Ubuntu

comment:7 Changed 12 months ago by bcandler

I have upgraded this machine (Macbook Pro 13" 2015) from macOS 10.12.6 to 10.14.1

Now I've seen the problem appear again. The VM was OK; after closing the laptop and re-opening it again in a different location, it went to 100% CPU, while still idle in the guest. This suggests maybe a change in network settings triggered the problem.

I don't see anything obviously wrong in VBox logs though - just showing that the suspend/resume took place - and I don't see any VBox-related logs in console.

03:24:10.765134 Pausing VM execution, reason 'host suspend'
03:24:10.765825 Changing the VM state from 'RUNNING' to 'SUSPENDING'
03:24:10.799262 AIOMgr: Endpoint for file '/Users/brian/VirtualBox VMs/rabbitmq/rabbitmq.vdi' (flags 000c0781) created
 successfully
03:24:10.815384 AIOMgr: Endpoint for file '/Users/brian/VirtualBox VMs/rabbitmq/rabbitmq-zfs.vdi' (flags 000c0781) cre
ated successfully
03:24:10.901783 PDMR3Suspend: 135 928 808 ns run time
03:24:10.901817 Changing the VM state from 'SUSPENDING' to 'SUSPENDED'
03:24:10.901831 Console: Machine state changed to 'Paused'
03:24:30.767925 NAT: DNS servers changed, triggering reconnect
03:24:31.475081 Resuming VM execution, reason 'host resume'
03:24:31.476581 Changing the VM state from 'SUSPENDED' to 'RESUMING'
03:24:31.480505 AIOMgr: Endpoint for file '/Users/brian/VirtualBox VMs/rabbitmq/rabbitmq.vdi' (flags 000c0723) created successfully
03:24:31.493955 AIOMgr: Endpoint for file '/Users/brian/VirtualBox VMs/rabbitmq/rabbitmq-zfs.vdi' (flags 000c0723) created successfully
03:24:31.745771 NAT: Link down
03:24:31.745842 Changing the VM state from 'RESUMING' to 'RUNNING'
03:24:31.745875 Console: Machine state changed to 'Running'
03:24:36.760571 NAT: Link up
03:24:41.611545 NAT: DNS servers changed, triggering reconnect
03:24:41.612443 NAT: Link down
03:24:46.611772 NAT: Link up
03:25:23.930354 NAT: DNS servers changed, triggering reconnect
03:25:23.933459 NAT: Link down
03:25:28.930853 NAT: Link up
03:25:28.931070 NAT: resolv.conf: nameserver 10.101.2.1
03:25:28.933015 NAT: DNS#0: 10.101.2.1

comment:8 Changed 12 months ago by socratis

Another couple of reports in  https://forums.virtualbox.org/viewtopic.php?f=8&t=90027

It seems to be widespread, we need to find what's the common denominator. Somehow I have the feeling that 10.13 or higher, 5.2.20, and maybe sleep might be involved.

comment:9 Changed 11 months ago by pentagonik

  • Owner set to pentagonik
  • Status changed from new to assigned

comment:10 follow-up: ↓ 11 Changed 11 months ago by socratis

I forgot that I got a 'ping' to post an update on this, oops... :o

From a developer's comment on the IRC, it seems that this might be audio related, hence the "assigned" tag. ;)

Could you disable your audio in the VM and try again?


PS. Apologies a priori if you receive a duplicate notification in the forum threads...

Last edited 11 months ago by socratis (previous) (diff)

comment:11 in reply to: ↑ 10 Changed 11 months ago by regnauld

Replying to socratis:

I forgot that I got a 'ping' to post an update on this, oops... :o

From a developer's comment on the IRC, it seems that this might be audio related, hence the "assigned" tag. ;)

Could you disable your audio in the VM and try again?

Confirmed! Turning off all audio (I didn't play with the individual sub-options) fixed the issue. 5.2.20 / Mojave. Before that, pegged CPU with or without pausing the VM.

Side note: I rejected a request to allow access to the microphone during Ubuntu installation - I did not notice if the CPU spiked at that point, but it could be related.

comment:12 Changed 11 months ago by socratis

You should try 5.2.22, it should contain the real fix:

  • Audio: fixed a regression in the Core Audio backend causing a hang when returning from host sleep when processing input buffers

Can you confirm that please?

PS. Man that was fast... ;)

comment:13 Changed 11 months ago by carlosefr

I've tested with 5.2.22 and the problem is still reproducible.

Also, I can also confirm that disabling audio in the VM makes the problem go away.

Another thing I notice is having audio disabled reduces the baseline CPU usage of VBoxHeadless by about 2% (I have a VM with SQL Server where VBoxHeadless always hovers around 10% with VirtualBox 5.2.18, and 12% with VirtualBox 5.2.20/22). In the latter case, when audio is disabled I see it using 9%-10%.

Last edited 11 months ago by carlosefr (previous) (diff)

comment:14 Changed 11 months ago by pentagonik

To further diagnose the problem, could you please try to set the audio backend to "NULL Audio" and try reproducing the problem again? So far I am unable to reproduce the issue here.

comment:15 Changed 11 months ago by pentagonik

I'm currently trying to investigate and reproduce the issue, but failed so far.

So I have a couple of questions to those where to issue actually is reproducible:

  • This only happens on guests which use the AC'97 device emulation?
  • What happens if you select the NULL driver (backend) instead of the CoreAudio, is this still reproducible then?
  • Does the guest play (output) or record (input) anything while the issue appears?

Thank you!

comment:16 Changed 11 months ago by bcandler

I left two VMs running for the past couple of days - one with audio disabled, one with null audio driver. I have suspended the host quite a few times as I normally do through a day. Neither VM has caused the problem of 100% CPU load on the host with 0% in guest.

Unfortunately that doesn't prove anything, but may be a general indication.

I did however just discover something that may be relevant. If I go into Settings, Security & Privacy, and select Microphone, I can see that VirtualBox access to microphone is disabled. (I guess it must have asked me at some point, and I said No).

Last edited 11 months ago by bcandler (previous) (diff)

comment:17 Changed 11 months ago by pentagonik

I just uploaded a new 5.2 test build 126798 on the Testbuild page which hopefully should fix the issue now. Please download the build here: https://www.virtualbox.org/wiki/Testbuilds

comment:18 Changed 11 months ago by symsym

@petagonik: Tested with build 126798 on Mojave. Same problem. 3 VMs running in headless mode and autostarted by launchd (org.virtualbox.startup.plist). When re-starting the VMs manually, same problem.

Disabling Audio on all VMs cures the problem.

Last edited 11 months ago by symsym (previous) (diff)

comment:19 Changed 11 months ago by pentagonik

@symsym Thanks for the feedback -- as I still can't reproduce this here (also on Mojave), could you please have a look at the questions from comment 15 and providing more input so that I can continue investigating the issue? Thanks!

comment:20 Changed 11 months ago by JL1

I have this problem, too, running a Win10 VM in High Sierra. I discovered in the VM that the VBox Tray process suddenly hogs up the CPU. Deleting that process solves the problem but then I loose functionality such as using the clipboard between each OS. Of course, rebooting the VM works, too.

comment:21 Changed 11 months ago by pentagonik

@JL1 This sounds like a completely different and unrelated problem to me, not audio-related.

comment:22 Changed 11 months ago by pentagonik

@symsym Would you be able to collect a sample from the VirtualBox VM process which is consuming the high CPU load and upload it somewhere so that I can take a look at it?

comment:23 Changed 11 months ago by bcandler

I started another VM on which I hadn't disabled audio - Ubuntu 14.04. After suspending and resuming my laptop (macOS), it went up to 100% CPU utilisation. This is stock VBox 5.2.22, not the test build.

What do you mean by "a sample from the VirtualBox VM process"?

comment:24 Changed 11 months ago by bcandler

I changed to 5.2.23 r126798, but this *doesn't* fix the problem. The same Ubuntu 14.04 guest VM with audio enabled went to 100% CPU after suspending and resuming the macOS laptop host.

comment:25 Changed 11 months ago by BrendanSimon

I changed the audio driver settings to:

  • Host Driver = Null Audio Driver
  • Controller = Intel HD Audio

Now my mac (10.13.6 High Sierra) and guest (Debian 8 Jessie) have decent performance again.

I'm not sure which of the settings above is the cause of the improvement, but it makes a big difference.

comment:26 Changed 10 months ago by vincent<3

Thanks for the tip. I disable audio on my Debian stretch VM (with no gui) and things are back to normal ! I had this painful trouble of battery drain for a few weeks on my Mac Host (Mojave 10.14.2). The CPU usage of VBoxHeadless on the mac host was 100% while the cpu usage of the guest was close to 0. I use this debian guest (launched through vagrant) only to compile code, so in idle it does nothing except a bit of ssh and nfs. VirtualBox Version 5.2.22

Last edited 10 months ago by vincent<3 (previous) (diff)

comment:27 Changed 10 months ago by Alan Crosswell

In case it helps diagnose this: The first time I launched a new virtualbox VM (via vagrant CLI in Terminal) Mojave popped up a permission dialog to allow Terminal to access my microphone, which I declined. Mojave seems to have added quite a few more security features like this.

comment:28 Changed 9 months ago by bcandler

I just updated to mac OS 10.14.3 and to VirtualBox 5.2.24, and the problem recurred on a VM where it had been fine before. I had previously set this VM to use the null audio driver. The settings were:

  • Audio Enabled
  • Null Audio Driver
  • ICH AC97
  • Audio Output Enabled
  • Audio Input Enabled

I shut it down, unchecked the first box to disable audio entirely, restarted the VM, and CPU load is normal again.

comment:29 Changed 8 months ago by scosol

Still a problem- OSX Host 5.2.26 r128414 (Qt5.6.3) - Debian guest. Disabling audio fixes it, but is an unacceptable non-solution.

comment:30 Changed 8 months ago by riyer

Problem persists in OSX High Sierra (10.13.6) and VirtualBox Version 5.2.26 r128414 (Qt5.6.3) - CentOS guest. Disabling audio fixes it. Some additional input. The problem appeared when we upgraded from OSX Sierra to High Sierra. Do not recall Virtual Box version at that time. Have upgraded Virtual Box multiple times since then to no effect on this issue. Virtual Box process and logd process hit 100% CPU on the host MacOS anytime the host machine wakes up from sleep with the Guest "alive". (We have been advised not to upgrade to Mojave pending varios validations internally).

comment:31 follow-up: ↓ 32 Changed 7 months ago by Richlv

Also reported a bit earlier in #18049, but that somehow was missed by everybody.

Seeing this on MacOs Mojave 10.14.2, with an OpenSUSE Tumbleweed guest. Virtualbox right now at 5.2.22, but have observed this with several earlier versions.

comment:32 in reply to: ↑ 31 Changed 7 months ago by socratis

Replying to Richlv:

Virtualbox right now at 5.2.22, but have observed this with several earlier versions.

How about some later versions, like 5.2.24 or 5.2.26? Or the Testbuilds?

comment:33 Changed 7 months ago by Richlv

There's one comment before mine about this still being a problem on 5.2.24, and two about 5.2.26 still being affected - and I have been checking the changelogs eagerly, too.

Is there a fix in some build that should resolve this and would benefit from testing?

comment:34 Changed 7 months ago by socratis

I don't know if this is resolved or not, I'm trying to get people to test the latest and greatest, there's no point in staying behind.

For example, I've never had this issue, I'm on OSX 10.11.6, so I'm trying to see if there's a common denominator here.

I have an ext. HD that can boot anything from 10.11 to 10.14, so I could test it easily if it's an OSX specific version...

comment:35 Changed 7 months ago by Richlv

Got it, that's a good point.

Looking at the reports here, the problem might have started with MacOS 10.12.

comment:36 Changed 7 months ago by socratis

@Richlv
I can't reproduce it with an OSX 10.12.6 host and a Win10x64 guest. Any chance that you can send me your VM that has the problem, and tell me the conditions under which that happens?

BTW, what's the I/O activity on the guest? Hard disk activity will not register as CPU in the guest, but it will register as CPU on the host...

Last edited 7 months ago by socratis (previous) (diff)

comment:37 Changed 7 months ago by Richlv

VM is large and contains a lot of sensitive info, cannot share it. It is a Linux guest. On Linux, disk activity (i/o) will register in CPU load, and with all applications closed, there is 0 CPU load on the guest during the time when the CPU load of logd and VBox on the host is high.

comment:38 Changed 7 months ago by socratis

Richlv
Can you at least give me the recipe? The .vbox file? And the ISO that you installed this VM from? Then at least I could try and build a fresh VM out of these two components.

May I suggest that you do the same? For a new test VM? That way we can figure out if it's the customization that you've done to the guest?

comment:39 Changed 5 months ago by fendale

I'm seeing this issue on Mac OS 10.14.4 and Virtual Box 5.2.26.

I boot my host with Vagrant - the Vagrant file is here:

 https://github.com/sodonnel/puppet-modules/blob/master/boxes/basic/Vagrantfile

The Base box is here, which is a fairly minimal Centos 6.9 build:

 https://drive.google.com/open?id=1988zwf-6aM2AeyiJuXVz6y_9m_iXn0no

Steps to reproduce:

Start the machine.

Put Mac OS to sleep

Wake Mac OS and VBoxHeadless immediately pegs a CPU until you shutdown the guest:

574 VBoxHeadless 97.3 07:56.93 36/1 4 250 295M 0B 0B 1574 1336 running *0[2] 0.00000 0.00000 503 81930 389 24332055+ 22555717+ 974686+ 53531137+

Hopefully that will let someone dig a bit deeper into this if its reproducible.

comment:40 Changed 5 months ago by fendale

Interestingly, I created a new Vagrant base box based on Centos 7 (my problem box above was Centos 6) and explicitly disabled audio on the new box.

Booting this new box with the same Vagrant file as above no longer gives the awake from sleep issue.

comment:41 Changed 4 months ago by 6pac

Don't know if this is any help, but I had only a single core assigned to the VM, and when I assigned 4 of my 8 cores to it, I started getting this problem. I'm trying disabling audio, will see if it works.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use