If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Linux KVM vs. VirtualBox 4.0 Virtualization Benchmarks

12-13-2010, 03:10 AM

Phoronix: Linux KVM vs. VirtualBox 4.0 Virtualization Benchmarks

Oracle's been vigorously working on their VM VirtualBox 4.0 software and in just the past week they have delivered two public betas that bring a number of new features. Among the changes there is support for Intel HD audio / ICH9 to guest VMs, the concept of extension packs, user-interface improvements, support for limiting a virtual machine's CPU time and I/O bandwidth, 3D acceleration fixes for guests, and a great number of bug-fixes. How though is this updated Oracle/Sun virtualization platform comparing to the older VirtualBox 3.2 release and that of the upstream Linux KVM (the Kernel-based Virtual Machine) that most Linux distributions rely upon? Here are a number of benchmarks that seek to answer this very question.

and that's why the whole test makes no sense. Virtualization is known to work badly with "virtual" "emulated" CPUs. So, next time I'd like to see something a bit more realistic, like HT support disabled in BIOS, host and guest limited to say 4 CPUs (host via kernel parameters).

What this test has shown is that no virtualization technology (amongst tested) scales well with the sheer number of emulated CPUs.

Comment

Very interesting results. It just confirms that those looking for a server workload (CPU-intensive, for example) should stick with KVM, not only because they don't need the GPU accel stuff, but also because it's faster, and seems to scale well with more virtual cores. But obviously desktop users don't really have a choice; it's either VirtualBox, or pony up a license for proprietary VMware Workstation 7.x, which works surprisingly well to play DirectX 9 games and such (provided your host has a proprietary driver).

Comment

By the results shown there, it seems maybe VBox isn't using the "Hyper-Threading" portion of the Corei7 processors. Furthermore, VBox 4.0 is still in beta development... and some CPU optimizations might not be working properly...
Cheers

p.s.: I'd also liked to see the 3D performance of VBox 4 beta vs VBox 3...

Comment

"As far as the VirtualBox 4 performance goes, in many areas right now its performance with the just-released Oracle VM VirtualBox 4.0 Beta 2 is slower than VirtualBox 3.2.12. However, it is a beta release not intended for use in a production capacity and we will be back with more VirtualBox 4.0 benchmarks upon the program's final release to see whether these regressions are still present or how the performance shakes down."

Beta Or not, there's no real excuse to not even try running basic Oprofile tests etc before Oracle release these Beta's to see and try and cure these bottleneck's/regressions.

such a massive drop on performance from VirtualBox 3.2.12 to VirtualBox 4.0 Beta 2 just seems like a lazy development cycle, geared toward PR release rather than better performance as all Virtualization should aspire to today.

don't Oracle or indeed most developers today even bother to benchmark and/or profile their code to try and at least produce faster code/data throughput where possible, it seem not!, perhaps they just want to keep blaming the lack of speed improvements on the compilers rather than actually write better code and actually profile it to make sure Before release...

Comment

and that's why the whole test makes no sense. Virtualization is known to work badly with "virtual" "emulated" CPUs. So, next time I'd like to see something a bit more realistic, like HT support disabled in BIOS, host and guest limited to say 4 CPUs (host via kernel parameters).

What this test has shown is that no virtualization technology (amongst tested) scales well with the sheer number of emulated CPUs.

its Not disabling Hyper-threading (as in using the spare cycles of the real CPU's to get up to 52% more throughput in these virtual CPU thread's) But rather disabling 'Turbo Boost' to remove the freaky and unpredictable nature that is TB, as can be seen If you run a simple ./checkasm --bench after pulling the x264 git source for instance..