virtualbox.org

I'm thinking of buying a new laptop.

One configuration I'm considering is a large hard disk running Linux with Windows 10 running as a guest in Virtualbox.

The physical laptop would have a quadcore CPU and 16GB RAM. Would this be OK for running a Windows 10 VM?

Here's some general limits for Virtualbox:

Virtualbox is an application running on your host PC's OS, so VB will be subject to the CPU counts and RAM limitations of the host OS.

You should not count hyperthreading when counting physical cores. A four-core Core-I7 with hyperthreading has four cores for Virtualbox purposes, even though the host OS may show eight. Your "quad-core" could be a dual core with hyperthreading, meaning only two real cores for Virtualbox and there fore only one allowed for a guest - see further:

A guest should not be set to have the same or more cores than the host has, even if the Virtualbox Settings will allow you to do so. So on the four core I7 mentioned, no guest should have more than three cores. The host must always have a core to use for itself. It is possible to have multiple guests that each have less than the full amount of cores but total up more cores than the host has as long as the guests don't all go full-throttle at once. (eg: I have run two 2-core guests, and a one core guest = 5 cores for guests on a four-core I7, with no problem, because the guests weren't always heavily using the cores.) It's a risk, time will tell how many guests you can run at the same time.

Ram usage is simple math: the total amount given to guests + the host's non-Virtualbox requirements < total host ram. There are some tricks to move ram between guests while running the guests, but live hot-swap from host to guests after the guests have been started is not possible, and you can't get more ram than the host has. Disk swap files don't count.

Expect disk bandwidth limitations and sluggish data access in the guests when booting or heavy-running more than two modern OS guests on one platter drive at the same time. The head just can't move around fast enough. SSDs eliminate this problem.

Windows 10, host or guest, is a bit prone to breaking for a while. Trying to hit a good configuration has ben a running street battle for the developers because Microsoft keeps changing 10. That said, I run 10 as my host OS and some folks run 10 as a guest. Microsoft allows you to download and try a time-limited evaluation for 10 that you can test in Virtualbox, before you spend money on a license for 10.

A guest should not be set to have the same or more cores than the host has, even if the Virtualbox Settings will allow you to do so. So on the four core I7 mentioned, no guest should have more than three cores. The host must always have a core to use for itself. It is possible to have multiple guests that each have less than the full amount of cores but total up more cores than the host has as long as the guests don't all go full-throttle at once. (eg: I have run two 2-core guests, and a one core guest = 5 cores for guests on a four-core I7, with no problem, because the guests weren't always heavily using the cores.) It's a risk, time will tell how many guests you can run at the same time.

I realise this is heresy around here but I've never had any problem allocating all available cores
to one guest or even over-allocating the total number of virtual cores to real cores AND running
multiple guests at 100% cpu busy.

In fact in workload test, I took a guest workload that could monopolise my 4 real cores and ran
it in a 3-way guest (thus supposedly leaving one for VirtualBox) and the elapsed time of the
guest workload was worse than that when running in a virtual 4-way. This was what I expected
to happen, as I was restricting the guest to run on three cores when it had sufficient workload
for all four.

The only way to know how your machine will perform is to run your own workload tests/benchmarks
with your own applications.

Also, when using VT-X, ensure you have Extended Page Tables (nested paging) active which makes
a big difference to performance. You should also enable VPID for the Guest. I didn't find Large Pages
made much difference (manual says up to 5% improvement).

The Raven wrote:I realize this is heresy around here but I've never had any problem allocating all available cores to one guest or even over-allocating the total number of virtual cores to real cores AND running multiple guests at 100% cpu busy.

That's not the problem. My Mac has 4-real, 8-hyper CPUs. I've assigned up to 10 to a WinXP guest that run numerical analysis. The real problem is that if you do assign more than you have, you might hit issues that are really hard to troubleshoot:

Ramshankar in a [url=https://forums.virtualbox.org/viewtopic.php?f=1&t=79734#p373129]recent post[/url] wrote:
Why is it a bad idea to allocate as many VCPUs as there are physical CPUs?

You cannot have the best of both worlds. Most modern Intel CPUs have VT-x preemption timers, which VirtualBox has been using for years now. This lets us run chunks of guest code and still get interrupted to run host code depending on how we program the preemption timer. However, the question is not whether we can or cannot interrupt guest code, we normally can. The problem is that there are tasks that require to be run in reasonable frequency & amount of time both on the host *and* the guest. If you starve the host or guest of interrupts or introduce latency because there simply isn't enough compute power available, you will be creating bottlenecks.

Getting in and out of executing guest code via VT-x is still quite an expensive operation. We call it a world-switch or world round-trip, (i.e. VM-entry, execute guest, VM-exit). This is done in ring-0 (kernel) on the host, sometimes (especially on Windows hosts) we are forced to return all the way to ring-3 sometimes in order to satisfy DPC (Deferred Procedure Call) latency. Overall, you're going to have strange latencies introduced in unexpected places if you "overcommit". It is totally possible to run 4 VCPU VM on a 4 CPU host (I do it on my own my Linux dev box sometimes) but it is not something you should be doing if you care about reasonable performance; in extreme cases of overcommitment you may encounter program misbehavior (like when disk requests times out) which the programs are never designed to handle. In the not so severe case you may end up with some strange timeouts but not fatal errors.

I agree you might have a problem but equally you may not.

The way that the vcpu to real cpu ratio argument is presented here is that,
especially for new users, it appears that the only safe configurations are, for example,

On a real 2-way processor :
Only run 1 uni-processor guest and leave one for VirtualBox/Host.

On a real 4-way processor:
Only run one 2-way guest and one uni-processor guest - with one for VB/Host or
perhaps, three uni-processor guests - with one for VB/Host.

I actually started using VirtualBox about 6 months ago and had already migrated my
workloads before I joined the forum. As I hope you can appreciate, I was somewhat
surprised by these recommendations as I was already not following them.
Having started using Hypervisors in the 1970's and hardware virtualisation in the 1980's,
I was happy to consolidate guests based on how I expected VirtualBox (and indeed
the guest workloads) to perform. Nothing that I've seen in the last six months has
made me alter my opinion.

I run VirtualBox on a Debian Host(s) and am very pleased with both the function and
performance of the product. It performs very well, even under heavy loads.

Furthermore, I am fully aware that should I encountered performance related problems,
or odd timing like behaviour within the guest, then it is for me to diagnose the problem.

I will admit that I have encountered one small problem when over-committing one of
my Quad-core machines for an extended period ... it starts to sound like a lawn mower
My fault entirely of course, it's a machine from around 2011 and when I rebuilt it I did not
replace the stock Intel cooler.