Virtualization and disk performance

[Serge van Ginderachter]

Working at ibcn.intec.ugent.be, I am conducting some performance tests on
different platforms (Xen, KVM, VMWare) and also on different host OS systems
(Debian, Ubuntu, CentOS) and can acknowledge this. While those tests aren't
finishedn and no report was written yet (I plan to do this in the following
month, an dhoperfully publish it somewehere) I can give some conclusions.

On 12 May 2010 08:30, David Peall <david at dnservices.co.za> wrote:

> Thats a big pill to swallow for KVM.
>
> Any ideas what is the best way to get disk performance using KVM.
>

"Don't use local disks." KVM performs badly (ATM), I fail to see a solution
right now.
I wouldn't recommend using virtualisation when you need strong disk
performance, like for databases. If you really must use virtualisation,
*and* need the best performance, consider runnig Xen on Debian Lenny, or
VMWare ESX(i) 4

Some conclusions to my tests.

- Processor wise they all perform well- Memory bandwitch is overall
comparable, but best on vmware
- network speed is varying, but no conclusive tests so far; tuning for
gigabit connections is of course needed
- disk access is the major botle neck on *all"platforms

About disk access I can add also those first observations:
- vmware performs best, closely followed by Xen (using paravirtualisation of
course)
- KVM (using virtio) performs worse and still has a lot to catch up on Xen
- a recent KVM/Ubuntu combo (Karmic, Lucid) is performing worse than Centos
5.4 /KVM (which carries older but patched versions of KVM and vmlinuz)
- Debian Lenny + Xen is far more performant

Overall, I get a strong feeling that the Ubuntu flavours I tested perform
badly, even compared to older versions of other platforms. It seems very
obvious that Red Hat patches to the kernel are very optimized.

It might be interesting to consult the kernel team, but right now, I don't
have the numbers compiled and ready to be published. I'll ping the list when
that is ready.

-- 
    Met cordiale groet,

    Serge van Ginderachter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-server/attachments/20100512/c85eb3dd/attachment.html>