Debian Host / Win10 Guest - Host CPU High, 3d Acceleration Wont Work

[judas]

Hello everyone,

I have signed up to this forum to ask a quesiton to help solve a problem I am having with my VM. I have searched around online for several days, both in general and on this forum in particlar, but cannot find any page that addresses my particular problem.

I have a Debian Host system (freshly installed about 2 months ago), running VirtualBox 6.1. Inside this I have a guest running Windows 10 (newly updated to build 2004, but this problem also happen prior to that). This is the only guest that runs on the host.

When the guest Win10 VM is running the CPU usage on the Debian host is very high (100% or thereabouts) when examined using the 'top' command, and the culprit is the VirtualBox process.

The guest VM is currently setup with 3d acceleration disabled, which I suspect may explain the CPU usage. The reason for this is that when 3d acceleration is enabled any attempt to install the Guest Additions package in the guest causes it to crash and then to fail to boot. As soon as I disable 3d acceleration this goes away and the Guest Addition package works fine. 3d acceleration works fine without the GA package installed, but then the Win10 guest OS wont install proper video drivers, defaults to generic display driver.

A complicating factor is that both the host and the guest are only ever accessed by RDP, never directly with a monitor. When the guest is accessed via RDP this is done directly through the Wondows guest OS, not through VirtualBox's RDP interface. I do not believe that RDP itself is in any way responsible for the high host CPU usage, since the CPU usage shows up even when no RDP sessions are active.

Can anyone suggest a way to either:

1. properly determine what is causing the CPU usage to max out on the host?

2. how to enable 3d acceleration on the guest and install the GA package without it immedaitely crashing on install and refusing to boot?


Many thanks for any help anyone can give me

[scottgus1]

Re #1, also compare the guest's Task Manager readings. Everything the guest OS does also contributes to Virtualbox's CPU usage.

Re #1 and 2, please start the guest from full normal shutdown, not save-state. Run until you see the problem happen, then shut down the guest from within the guest OS if possible. If not possible, close the Virtualbox window for the guest with the Power Off option set.

Right-click the guest in the main Virtualbox window's guest list, choose Show Log. Save the far left tab's log, zip it, and post the zip file, using the forum's Upload Attachment tab.

[judas]

Thanks for the reply scottgus1,

In answer to your two points:

1. The Task Manager in the Win10 guest shows nothing unexpected. It generally has a CPU usage of a few percent, rarely more than 10 or 15%, and these are distributed over a range of processes. This is true for RAM usage and disk speed too - nothing is maxing out or using anything excessive within the guest. Nothing seems odd from inside the guest, other than it running pretty slow given the hardware the host has available (i5, 16GB RAM). This is repolicated is I explore more closely using the Win10 Resource Monitor - there is no task using more than a couple of percent, and only abot 10 - 20% usage in total at the highest points.

2. If I start both (host and guest) from a cold boot and then run the guest VM, the CPU usuage on the host will pretty immedaitely shoot up within 10 seconds or so, certianly well before the Win10 guest ever gets as far as a login screen. It will then stay there perpetually, until the guest VM is shutdown, at which point it drops down again.

Attached here are the log file from VirtualBox as you have requested, and also (in case it is of any use) a screen grab of the 'top' output from the Debian host.

[judas]

Apologies - in order to be thorough I should have uploaded some documentation of the Win10 guest Task Manager too. Here it is...

(this is taken at rougly the same time that the host is show 160% CPU usage)

[scottgus1]

I'm not very familiar with Linux' reporting of CPU usage, but 157% seemed... interesting. I googled it and found this https://askubuntu.com/questions/707203/ ... 32%20cores. Top apparently combines multi-core usage to a single report, and can go over 100% if the individual reports add up.

The log says you have all six host cores in the guest:

00:00:01.640317 NumCPUs <integer> = 0x0000000000000006 (6)
00:00:01.851042 CPUM: Physical host cores: 6

Windows 10 happily runs on two cores. Adding more cores causes more scheduling overhead on the host hypervisor. Try two processors for the guest.

[judas]

Afternoon!

Agreed. The 'top' command is mixing up multiple cores in its percentage output, so if a process is something that is capable of operating across more than one CPU core then it will likely exceed 100%. This is not true of most processes (which are single-threaded and so only use a single core) but for something like VirtualBox (which must necessarily use many cores) this is pretty normal.

I've taken the VM down to 2 cores, and started it up again. It does make a difference to the host CPU usage. It peaks up to 160 - 180% at times, but is more variable, flickering between around 80% - 150% - probably spending more time closer to 80% than to 150%. So this seems like an improvement in the measuerable results.

It doesn't seem like a long term solution though, as it leaves most of the host's CPU resources idle - the Win10 guest is the only VM running on the host, and the host doesn't do anything else other than running VirtualBox, so this configuration means that it has 4 cores sitting idle that could otherwise be used.

Thanks for your help so far.

[scottgus1]

Glad things are working better!

More cores won't help the guest unless it has something to stuff through those cores. The scheduling overhead takes a toll trying to spread threads around over the cores available, and spreading 2 cores' worth of threads over more cores means things have to be broken up and scheduled, which means more core usage. That overhead begins to be acceptable when there are more threads needing to go through the cores than two cores can handle.

I think it was Mpack that came up with this illustration: Imagine putting two engines in a car. There's a lot more power. But the power from each engine only shows itself in ability to turn the output shaft. The engines both only turn 2-3k rpm into the transmission, so the wheels can't go faster. They can haul more load though.

So your six-core host can't make the guest OS run any faster. But it can haul about three more guests...

[fth0]

The VirtualBoxVM process consists of multiple threads. If you press 'H' inside top, which thread(s) show the high CPU load?

The VBox.log file you posted earlier is incomplete. Please post a zipped VBox.log file from a complete run of the VM (after shutting it down from inside the VM), so that the statistics are included.

Additionally, I'd suggest to enable large pages (VBoxManage modifyvm andrew_home --largepages on) and to disable nested virtualization (VBoxManage modifyvm andrew_home --nested-hw-virt off), if you don't need it.

[judas]

Hello fth0, thankyou for taking an interest in my problem.

I have tried everything you say:

1. f I press 'H' within the top outpout, I get the results n the screen shot below. The two threads that are the highlighted are EMT-0 and EMT-1, taking about 70 - 80 % each.


2. I have shutdown the guest OS, and have re-attached the log file. Apologise - I wasn't aware that useful information was added at the end of a session like this. At least I have learnd something now!


3. I have disabled option 'Enable Nested VT-x/AMD-V' in the System >> Processor section. This does not seem to make any noticable difference to the reported CPU usage on the host.

I tried disabling the 'Enable Nested Paging' option in the System >> Acceleration seciton, but this causes the guest OS to fail to boot.


4. Forgive my ignorance, but I do not know where to find the option to enable large pages. Can you advise?

[fth0]

The two threads that are the highlighted are EMT-0 and EMT-1, taking about 70 - 80 % each.

Those are the threads executing the two vCPUs you've provided to the guest.

I have shutdown the guest OS, and have re-attached the log file.

I cannot really assess any numbers, when the VM has been running for 136 hours, doing things I don't know anything about. Please start the VM from power off, let it run idle for 10 minutes, observe the CPU load, shut it down from within the guest OS, and provide the zipped VBox.log file.

Forgive my ignorance, but I do not know where to find the option to enable large pages. Can you advise?

Please reread my previous post, where I already gave you the exact command to do that.