[FIXED] Beta issue? 100% CPU use for an idle guest OS

[birdie]

An XP guest is consuming 100% of the host OS CPU while the guest OS is completely idle.

Host: Fedora 40, Linux kernel 6.9.8 vanilla
Guest: Windows XP 32bit, with or without guest additions

Processor: 1 CPU, PAE/Nested VT-x/AMD-v: both disabled, Paravirtualization: Legacy, Nested paging: Enabled
Chipset: PIIX3
Pointing device: PS/2 Mouse
Extended features: Enable I/O APIC
Display: Video Memory 30MB
Graphics Controller: VBoxVGA
Storage: IDE Controller, PIIX4, Use Host I/O Cache
Audio: ALSA/SoundBlaster 16; Audio Out/In both enabled
Network: NAT, PCnet-FAST III
USB Controller: USB 2.0

Edit: this is not limited to XP. All my idle guests (Windows 10 64bit as well) now consume 100% of the host CPU.

Edit 2: it's an extra VirtualBox thread that's consuming 100% of the CPU (i.e. when the guest is 100% loaded, the host CPU now has two 100% busy threads). Looks like a bug.

[quizerti]

I didn't spot your post here and posted here about my own issue which sounds like it could be similar to yours:

I'm seeing unreasonably high CPU usage on my Windows 10 host when running Windows 10/11 guests. The CPU usage on the host machine doesn't seem to want to go below 32%, even when the guest is idle and has single % CPU utilisation figure shown in the guest's Task Manager in Windows.

As I type this, I have a Windows 10 headless machine running in the background at almost idle (<10% CPU) and it's chewing up 33% of my 7th gen i5. Normally this would settle down after a minute or two, but this isn't the case with the current beta.

I've also done testing on a separate Windows 11 machine installing Windows 11 guest machines from the same ISO image. The only other thing I could try is installing Windows 10, then using stock Windows 10/11 images, rather than my tweaked images.

[FranceBB]

I can confirm and reproduce the same issue on a Fedora 40 kernel 6.9.11 host and a Windows XP Professional x86 host (with Microsoft Extended Support updates 'till July 2019) guest.
The configuration I have is slightly different compared to Birdie's one, though:

Processor: 4 CPU, PAE enabled, Nested VT-x/AMD-v: disabled, Paravirtualization: Hyper-V, Nested paging: Enabled
Chipset: PIIX3
Pointing device: USB Multi-Touch Tablet
Extended features: Enable I/O APIC
Display: Video Memory 256MB
Graphics Controller: VBoxVGA
Storage: Sata Controller, AHCI, Use Host I/O Cache
Audio: PulseAudio/ICH AC97; Audio Out/In both enabled
Network: NAT, Paravirtualized Network (virtio-net)
USB Controller: USB 3.0

[aeichner]

Could you please attach a VBox.log?

[birdie]

Could you please attach a VBox.log?

The same as here:

viewtopic.php?p=549305#p549305

[FranceBB]

Given that this *feels* constant (i.e at least 1 core always being at 100% thus resulting in 25% usage on a 4c/4th CPU and 12% on a 4c/8th CPU), my best bet is that there's something going in a loop and wasting CPU cycles.
Given that we're in a Linux host, the core being pegged changes every few seconds to spread the load evenly, however this doesn't change the fact that there's some kind of loop going on. At least this is the behavior on my system.

I'll also provide the logs of my machine, however I can't do it straight away as I won't be next to that CPU until next week.

[Air Force One]

I can confirm this behavior. In the current beta I have 33% load on the host even if the guest OS is nearly idle (less than 5%). The VBox dashboard reports 0% on guest OS and 66% on VMM.

Same VM with current 7.0.20 or 7.0.21 versions has less than 10% on the host with same load in the guest and in the dashboard. So this is an issue with the 7.1 beta. Changing additions from 7.1.x to 7.0.21 doesn't change anything in this regard.

I have current Windows 10 host with all updates and Windows 11 with all updates as the guest.

BTW, currently the extension pack of the development snapshot has a wrong very old version which isn't compatible with the new 7.1 beta. And there is no information about the beta on the VBox main page. So not everybody noticed that the beta was released.

[FranceBB]

currently the extension pack of the development snapshot has a wrong very old version which isn't compatible with the new 7.1 beta.

Yep, I can confirm.
The download page offers the extension pack for 7.0.97 r163452 which is not compatible with 7.1.0 r164294.
Trying to install that old version of the guest additions on the new 7.1.0 r164294 leads to the following error:

Screenshot from 2024-08-10 22-41-04.png (42.43 KiB) Viewed 5918 times

[pentagonik]

I think we found and fixed the issue; thanks for the report!

As a workaround (or to confirm if this really caused the 100% CPU loads) you configure the VM to use a non-NAT networking setup.

[birdie]

I think we found and fixed the issue; thanks for the report!

As a workaround (or to confirm if this really caused the 100% CPU loads) you configure the VM to use a non-NAT networking setup.

Thanks a ton!

I remember you used to release new betas or RCs every week in the past, it's now been more than two weeks since the first beta release. Looks like something has changed.

[multiOS]

@birdie

Some interim updates to 'BETA1' have been posted on the Test Builds Page (Development Snapshots). The first new Builds were posted on August 7; and a later batch of Builds have since been posted, on August 15. Obviously, as normal with these progressive test builds there are no 'formal' announcements of what has been changed/fixed as each new build is added. I presume 'BETA2' will come along when the Development Team believe that sufficient progress has been made on any substantial issues to invite more user feedback.

[Air Force One]

The issue is still here in the current development snapshot r164369.

[klaus]

Yes, known. The fix is easy but there are larger changes pending which would run into merge conflicts. Should be resolved at the latest early next week.

[FranceBB]

I think we found and fixed the issue; thanks for the report!

As a workaround (or to confirm if this really caused the 100% CPU loads) you configure the VM to use a non-NAT networking setup.

Unfortunately that didn't solve the issue.
I'm currently using bridged networking via virt-io and it's still with 1 core at 100%.

The issue is still here in the current development snapshot r164369.

Yes I can confirm this.
In the meantime, a new development snapshot was released on August 15th, namely 7.1.0 r164395 but it didn't address the issue.

Screenshot from 2024-08-19 08-00-33.png (16.63 KiB) Viewed 4953 times

WindowsEmbedded-2024-08-19-08-06-25.zip

(46.31 KiB) Downloaded 2039 times

By the way, this doesn't seem to be affecting the Beta only, but rather it seems to be something introduced between 7.0.19 r163782 and 7.0.20 r163906 as I mentioned here: https://www.virtualbox.org/ticket/22123

Once again, downgrading the guest additions to 7.0.19 r163782 (or, for those who prefer stable, 7.0.18 https://download.virtualbox.org/virtual ... 7.0.18.iso) solves the issue. In other words, I can confirm that the last guest additions to not show the issue are 7.0.19 r163782 and using those solves the issue on both 7.0.20 and 7.1.0.

Screenshot from 2024-08-19 08-44-06.png (16.44 KiB) Viewed 4953 times

Yes, known. The fix is easy but there are larger changes pending which would run into merge conflicts. Should be resolved at the latest early next week.

I'm glad to hear that, I'll update the ticket as soon as those are gonna be available for testing.

[klaus]

FranceBB: your issue is actually not what is the topic of this thread: you see high CPU usage inside the guest (caused by VBoxTray). The originally reported issue was a busy loop in the NAT code (which happened when the guest OS was really idle).

The latest dev snapshot test builds (the r164434+ ones) have the NAT issue fixed.