virtualbox.org

I have two Ubuntu virtual machines (18.04, 20.04) and two other linux-based distros (fedora and cent os) running on a Windows host as part of a kind of CI build. On the Ubuntu machines, I have a clang compilation running every night; on the other machines a g++ compilation.

The compilation on the Ubuntu machines now seems to be much slower with VT-X enabled, than with the "NEM" mode (with the turtle symbol in the status bar). How do I know? Well, I had installed WSL2 recently, and this screwed up my VirtualBox machines (leading to "HMR3Init: Attempting fall back to NEM: VT-x is not available" in the logs, which I noticed only after a while); once I noticed it, I disabled WSL2 via . Now the log shows the message "HM: HMR3Init: VT-x w/ nested paging and unrestricted guest execution hw support" instead, and indeed the start into the graphical user interface is much faster; but the compilation times have become much slower (from 12 to 32 minutes on one, from 14 to 33 on the other Ubuntu virtual machine). The compilation times on the other two linux machines where unaffected or got a little faster; hard to say because there's been quite the fluctuation there even without any changes to the backend in the last few days.

I'm wondering about this drop in performance, but have no idea where it could come from; didn't see anything I could identify as related in the log file (the one from Ubuntu 20.04 is attached - VBox.log with VT-x enabled, VBox.log.2 from before).
Since only the Ubuntu machines are slow, maybe it is related to what was reported here: viewtopic.php?f=6&t=103364 ? Need to do some more tests I guess, if clang on other machines is affected as well for example...

Any idea on what might be happening here?

First, it is redundant to say "with VT-x enabled". VirtualBox 6.1.x doesn't give you the option to run any other way. The setting you have been playing with is the "NESTED virtualization setting". A completely other thing, and not important unless you want to nest VMs.

You don't have NEM present, so we can forget that.

As to your performance problems - I don't know how you expect the VM to run quickly when you starve the host of CPU. I hope you understand that the VM is a host app, right?

Since you have an 8 core host you should be assigning no more than 6 cores to the VM. But even that is usually pointless, and 2 cores usually work best. Assigning redundant cores just increases the management overhead AND starves the host, so usually slows things down. Assigning 2 physical cores does not prevent clang from scheduling multiple threads (assuming you configured it to do so): and I would not expect performance to suffer unless the process was previously CPU bound.

First, it is redundant to say "with VT-x enabled"

Not an expert, so, sorry if the word choice in my first post was not ideal. But "VT-x is not available" does suggest that VirtualBox can indeed not use the VT-x hardware support, or not? And it does show the "turtle" symbol in that case which supposedly indicates a far slower running mode as reported in some other threads.

The setting you have been playing with is the "NESTED virtualization setting"

I am not aware that I have played with any setting in virtualbox itself? I have merely disabled the Windows hypervisor... but from what I've read otherwise is that Windows enabling an underlying hypervisor blocks VirtualBox from using (at least some of the) hardware virtualization in the CPU; that's probably what you're referring to, right?

As to your performance problems - I don't know how you expect the VM to run quickly when you starve the host of CPU. I hope you understand that the VM is a host app, right? Since you have an 8 core host you should be assigning no more than 6 cores to the VM.

Well, yes I do have 8 physical cores, but the machine does not do anything else during that time so I thought I would get the maximum performance by assigning the same number of cores to the virtual machine as the host has. Thanks for the hint, though, I will experiment with less cores.

This still would not explain, however, why only the Ubuntu / clang build is slow; and why it is so much slower when "hardware support" (or whatever one should call this thing now?) is available in comparison to when it isn't.

If you still have the green turtle and still get the VT-x is not available message, the Windows hypervisor is loaded and VT-x is not available to VirtualBox as a result. I would use the bcdedit command to prevent the hypervisor from loading. Be sure to reboot after the command runs so the you are running Windows without the hypervisor. In that mode WSL2 will not run - it depends on the Windows hypervisor. See this recent post. viewtopic.php?f=6&t=104918

In my limited experience with Ubuntu, previous versions ran reasonably well in turtle mode. I have not tried recent versions.

If you still have the green turtle and still get the VT-x is not available message

To clarify: I now do not have the green turtle shown anymore, and the VT-x not available message is not shown anymore in the log; the GUI is now loading also very fast; that's why I'm wondering all the more why a build run on the same virtual machine now, without the turtle, is still much slower than before, when the green turtle was still shown (before executing the bcdedit command to set hypervisorlaunchtype to off). Seems Ubuntu runs really well in turtle mode!
.