Virtualbox CPU usage has increased suddenly

[blacksmithtb]

After upgrading to version 5.2.20 r125813 (Qt5.6.3) on 10.13.6 (High Sierra), I noticed that my imac's (17,1) fan has been audibly straining - looking at Activity Monitor I see VB is using ~ 160% of CPU at all times when an Ubuntu 18.04 VM (with guest additions also updated) is running but basically idle (System Monitor on Ubuntu shows ~ 5% CPU). Is this a known issue?

[socratis]

After upgrading to version 5.2.20 r125813

Upgrading from what? Does downgrading reverse the situation?

Is this a known issue?

Not so far.

We need to see a complete VBox.log, from a complete VM run:

• Start the VM from cold-boot (not from a paused or saved state) / Observe error / Shutdown the VM (force close it if you have to).
• With the VM completely shut down (not paused or saved), right-click on the VM in the VirtualBox Manager and select "Show Log".
• Save only the first "VBox.log", ZIP it and attach it to your response. See the "Upload attachment" tab below the reply form.

[blacksmithtb]

Upgrading from 5.2.18, I meant. Here's the log after I shut my linux guest down when it was causing high load on my mac host system (though the guest didn't see much load, ~ 5% CPU or so). And a screenshot from Intel's Power Gadget showing load/temp from before I shut it down and after:

Vbox_on_off.png (61.62 KiB) Viewed 7642 times

[blacksmithtb]

I haven't tried rolling back, but since this is just a local VM I'm using for testing I upgraded to 6.0.0_BETA1 and updated its guest extensions. The behavior is similar, after the guest has been running for a little the host's CPU usage spikes up and remains high.

[socratis]

Before I forget, and for future reference, next time please downsize your attached images by at least 50%. Or use the "Preview post" to see the actual size that your post is going to have (hint: too big). For this image for example:

• In Preview.app, crop your original 1024x1748 image to 800x1524. The extra transparent space is not needed...
• Tools » Adjust size... » 50 per cent, at 72 DPI.

Now, for your VBox.log...

00:00:01.091202 CpuExecutionCap <integer> = 0x000000000000005a (90)

Why? Take it back to its default 100%.

00:00:01.091301 [/Devices/ahci/0/LUN#0/Config
                 /Parent
                   /Parent
                     /Parent
                       /Parent
                         /Parent
                           /Parent/]
                           (level 11)

You should start limiting your snapshots.

But that's all I could find "wrong" with your configuration/log. BTW, you talk about 18.04, but your logs are named "Zesty*". Is this an updated 17.04? Can you try a plain vanilla fresh 18.04 and see if you notice the same behavior? Because I couldn't...

[XavierR]

Same issue here.
Even when the host is doing nothing, Virtualbox takes 100% CPU. It was not doing that before I upgrade to 5.2.20 r125813, and now it does.
Also, it basically makes VMs unusable when my laptop is on battery (battery life becomes atrocious).
I will post the details of my config a bit later.

[socratis]

I will post the details of my config a bit later.

And try to downgrade. See if that changes the situation. Both from the host and the GAs...

[XavierR]

My host is running Mac OS 10.14 (aka Mojave).
My client is Linux Gentoo, with 64 bits kernel (4.9.95).

Downgrading to 5.2.14 r123301 (the previous one I used) did solve the problem for me.

I do not have the chance to experiment with different versions of Virtualbox and guest additions at the moment (I am travelling and cannot mess up too much with my system ---not too much time, and cannot take the risk to have my system unavailable at the moment---; sorry I cannot be more responsive).

If you like, I can also upload a log of the VM with the 5.2.14 r123301 build.

[blacksmithtb]

Thanks for the suggestions socratis (you are right that this is an upgrade from Zesty, I didn't rename the VM) - I am not clear why I'd want to set the VM to 100% of CPU (especially given that I'm having problems with it over-using CPU right now?) Or does that counter-intuitively work better in general?

I can certainly delete some of my older snapshots, other than taking up space are they associated with instability?

I do think there is a pattern for me, which seems similar to viewtopic.php?f=8&t=90027 - my VM will behave normally for quite a while, but it does seem like after the guest locks the screen the CPU spikes up on the host and stays there. If I reboot the guest, things calm down again until the guest sleeps again.

[socratis]

There's also ticket #18089 (Host CPU load 100% for idle guest) that was just opened, dealing with the same situation. Host: OSX, guest: some sort of Linux.

So... it means that not all people see that^[1], but some people do. Let's try and read all the reports and see what's the common denominator here, if you want this to be narrowed down and potentially fixed.

---

^[1]: I for example don't, I have my Mint 19 running almost 24/7 on OSX 10.11.6, and every other Linux guest I've tried does not exhibit this behavior...

[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 with VirtualBox. When I start vagrant, everything is normal until a couple of hours later, when CPU on my Mac suddenly jumps to 100-110%. Process is vboxheadless, which is started by vagrant. In the same time host machine is idle ... doing nothing. I didn't tested it, but it may happen when my macbook go to sleep...

[socratis]

@ssh22
Vagrant is a program that relies on VirtualBox, but modifies its configuration files in unknown ways to us, and with unknown consequences. It is not supported on these VirtualBox user forums, they have their own Vagrant support channels.

If you are having this problem with a standalone version of VirtualBox (after a complete uninstallation of Vagrant), then we can continue this discussion.

[socratis]

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

From a developer's comment on the IRC, it seems that this might be audio related. Could you disable your audio in the VM Settings and try again?


PS. Apologies a priori if you receive a duplicate notification from the ticket...

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

[XavierR]

Many thanks for the messages. I am still travelling and unable to check at the moment, but I plan to do it next week, and to try both solutions (deactivating sound and upgrading to the next version). Thanks!