VirtualBox benchmarked

[Technologov]

1 CPU VM:
On 1 CPU host the CPU usage will go up to 100%.
On 2 CPU host, the host will "jump" load from first to second CPU every micro-second, so both cores will be 50% loaded.

2 CPU VM:
On 1 CPU host the CPU usage will go up to 100%. Due to added complexity, it will slow down the VM.
On 2 CPU host, every guest's CPU will be mapped to one thread on host. (which may jump every micro-second across host's CPUs)
Under load, both guests CPUs will be mapped to 2 host's CPUs.

This micro-second jumping, that loads your host 50%, is used to reduce heating of CPUs.
On Windows host you can set CPU affinity using the Windows Task Manager. (i.e. manually map guests CPUs to Host's CPUs). This can be done on other host OSes too, but I dunno the procedure.

-Technologov

[fyi]

A host process on a high spec system only needs a 1 - 5 % system CPU time to remain usable if it's primary role is just running vm guest processes. If you are implying an imposed limitation of 50% per 'virtualbox guest process' i would be shocked to say the least. If what you are implying is true - why wouldn't there be an advanced CPU limit setting so people have the choice of what limits they see fit for their system? .. no system is the same, so a fixed (implicit) scheduling limit of 50% would just seem irrational. I'll have to have a look at the code soon i think.

On my dual CPU (with 2 cores on each physical CPU), it switches the load between physical CPUs every few seconds or 10. It's not microseconds. The active vbox process seems only to be able to task 1 physical CPU at any one moment so I'm assuming vbox 3.0.4 doesn't task in a concurrent manner yet? I've tried a RT-patched kernel and a vanilla one - still no dice getting more than 50% CPU time out of a single vbox process. I was getting more performance out of Vbox 2 i think.

[ezjd]

On 2 CPU host, the host will "jump" load from first to second CPU every micro-second, so both cores will be 50% loaded.

On my dual CPU (with 2 cores on each physical CPU), it switches the load between physical CPUs every few seconds or 10. It's not microseconds

I saw the same thing as fyi in Linux host. In Windows, I saw sometimes one core taking 100% and the other only a few % besides this.

2 CPU VM:
On 1 CPU host the CPU usage will go up to 100%. Due to added complexity, it will slow down the VM.

As told, it isn't recommended so that I didn't run like this.

On 2 CPU host, every guest's CPU will be mapped to one thread on host. (which may jump every micro-second across host's CPUs)
Under load, both guests CPUs will be mapped to 2 host's CPUs.

I saw 100% on both cores in this case.
I also found a host process won't be scheduled to multi-cores simultaneously even if it has multple threads, which I believe that is because generally existing application isn't designed/compiled to utilize multicore.

fyi, I think if you give a VM 4 CPUs and run 4 big tasks together like encoding or use distcc to build, you will get all cores ~100%. I think only in this case, a guess process will be treated similar as a host process, which can be scheduled to a physical core independently. That is the reason I think the scheduler in both host/guest matters in virtualization.

Maybe only when normal app utilizes multicores, we will get host cores fully utilized if only a couple of app are running in guest.

[gpetrom]

Hi

I was wondering if someone has benchmarked recently virtualbox with kvm and vmware esxi.

Thanks