22

We are using Ubuntu 12.04 with the following parameters:

  • Dell R910
  • Kernel 3.2.0-25-generic #40-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux
  • kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu13
  • qemu-kvm 1.0+noroms-0ubuntu13
  • qemu-common 1.0+noroms-0ubuntu13
  • qemu-kvm 1.0+noroms-0ubuntu13
  • 4 x Intel(R) Xeon(R) CPU E7- 4870 @ 2.40GHz (each with 10 physical cores, HT and Intel VT enabled)
  • The Windows guests currently have no VirtIO, but that will change soon

We are running several Windows guests on this machine, one of them is Windows 2003 32 Bit, another one Windows 2008 (64 Bit). We are currently struggling with performance issues and played around with the CPU models.

We usually use "qemu-system-x86_64 for our Windows 32 Bit guest, e.g.:

/usr/bin/qemu-system-x86_64 -S -M pc-1.0 -cpu qemu32 -enable-kvm -m 4096 -smp 4,sockets=4,cores=1,threads=1 [...] 

The performance of this guest turned out to be a bit low. We didn't run any benchmark yet, but let's say that copying large amount of data (files) inside the VM from one directory to the other goes much faster when we switch the CPU model from "-cpu qemu32" to "-cpu Nehalem". Files which took around 2:40h to copy now copy within 40 minutes. Of course this is not a high quality test and there is much room for having a more professional attempt. But this is a clear indicator that choosing the correct CPU model could affect the guest's performance heavily.

Now I got curious and ran:

qemu-x86_64 -cpu ?
x86           [n270]
x86         [athlon]
x86       [pentium3]
x86       [pentium2]
x86        [pentium]
x86            [486]
x86        [coreduo]
x86          [kvm32]
x86         [qemu32]
x86          [kvm64]
x86       [core2duo]
x86         [phenom]
x86         [qemu64]

And:

kvm -cpu ?model
 x86       Opteron_G3  AMD Opteron 23xx (Gen 3 Class Opteron)
 x86       Opteron_G2  AMD Opteron 22xx (Gen 2 Class Opteron)
 x86       Opteron_G1  AMD Opteron 240 (Gen 1 Class Opteron)
 x86          Nehalem  Intel Core i7 9xx (Nehalem Class Core i7)
 x86           Penryn  Intel Core 2 Duo P9xxx (Penryn Class Core 2)
 x86           Conroe  Intel Celeron_4x0 (Conroe/Merom Class Core 2)
 x86           [n270]  Intel(R) Atom(TM) CPU N270   @ 1.60GHz
 x86         [athlon]  QEMU Virtual CPU version 1.0
 x86       [pentium3]
 x86       [pentium2]
 x86        [pentium]
 x86            [486]
 x86        [coreduo]  Genuine Intel(R) CPU           T2600  @ 2.16GHz
 x86          [kvm32]  Common 32-bit KVM processor
 x86         [qemu32]  QEMU Virtual CPU version 1.0
 x86          [kvm64]  Common KVM processor
 x86       [core2duo]  Intel(R) Core(TM)2 Duo CPU     T7700  @ 2.40GHz
 x86         [phenom]  AMD Phenom(tm) 9550 Quad-Core Processor
 x86         [qemu64]  QEMU Virtual CPU version 1.0

With all these different versions, it's a bit hard to guess at. "Nehalem" seems to be the most performant one on that list. Now I wonder, how to tell which CPU model is the best for my guest? Browsing the Internet, I found the following ressources:

When I read those sites correctly, they are claiming that "-cpu host" might bring the best performance. I don't have any worries about migration yet, since both KVM hosts are equipped equally (exactely the same hardware).

So, what do experienced KVM admins recommend? Is there a golden rule or even a matrix, like "this model is the best for that guest OS"?

My apologies if I could find out this information by my own - I ran various Google searches and browsed many websites. I was not able to find something which answers my question.

Jeff Ferland
  • 20,239
  • 2
  • 61
  • 85
PythonLearner
  • 1,022
  • 2
  • 12
  • 29
  • Why bother with the -cpu switch at all? Just leave it out. – psusi Jul 02 '12 at 23:07
  • 1
    Why not bother with it? Afaik it could bring performance improvements. – PythonLearner Jul 03 '12 at 08:22
  • If it has to step in and emulate things, it's going to hurt performance. Give it a try without. – psusi Jul 03 '12 at 13:26
  • 2
    I just found out that libvirt adds the parameter "-host qemu32" automatically, because we do not set it. – PythonLearner Jul 04 '12 at 20:44
  • 3
    @psusi: Just tested it today... when I leave the -cpu switch away, the performance is as good as I choose the best possible CPU model. – PythonLearner Jul 08 '12 at 19:19
  • I had a really huge improvement by making x64 OS VMs. This may not be possible in your case, but I recommend taking x64 OS' whenever possible as the performance increased pretty well at least in my case (Win 7 VM on 2x2,3Ghz i3 w/ 4GB RAM; only lagfree if x64). – Sebb Aug 08 '14 at 15:27

5 Answers5

15

It's quite simple really. For homogeneous clusters and single host setups use the host option. For mixed clusters, use the lowest available CPU version, so if one host is Penryn and the other Nehalem, use Penryn on both.

If you are using RHEV or oVirt, this is already built in. VMWare have this called "EVC" and position it as a huge feature.

Getting back to performance, you definitely need virtio everywhere you can put it. And if you still hit performance bottlenecks, those can usually be addressed on a case per case basis, depending on where they occur.

[offtop]On your choice of distribution I have already commented in another thread[/offtop]

dyasny
  • 18,482
  • 6
  • 48
  • 63
11

The Windows guests currently have no VirtIO

Don't lose more time with tweaking anything.
Install the virtIO drivers and come back. The difference is so huge that any enhancement you can find now will have no meaning with virtIO.

Just an example with one of our servers:
- without virtIO a W2k3 can handle about 10 Terminal Server users
- with virtIO, the same machine with the same OS currently handle 120 to 125 users with little slow down. And we added another virtual machine to run SQL Server one the same physical computer

Gregory MOUSSAT
  • 1,737
  • 2
  • 25
  • 48
  • Thanks for the hint. Yes, VirtIO should defenitely enabled, but we are running into a few problems with the Windows 2003 guest which should be solved first. Besides that, I want to have clarification on the CPU model topic. – PythonLearner Jul 03 '12 at 08:22
  • This is one reason I use Hyper-V. Ever since 2008 this means NO INSTALL and it means all drivers for Hyper-V maintained with Windows Update. Compatibility issues there are deamn deadly. – TomTom Jul 03 '12 at 12:48
  • @TomTom Hyper-V is not the only hypervisor certified to run Windows. And certification in this context means SVVP/WHQL. – dyasny Jul 03 '12 at 13:49
  • 1
    No, ut it is the only one that works out of the box as in it has the drivers already installed ;) Plus I think XEN as they piggiback on the Hyper-V drivers. Not having to maintain another externally updated element is a really nice thing. I dont care whether they are signed - point is I dont ahve to watch another provider, as all comes through windows update. I just WISH MS would open Windows Update for third party softawre ;) – TomTom Jul 03 '12 at 14:48
  • 1
    Since I'm certain you've heard of slipstreaming and VM templates, I will (almost) not mention those :) My problem with Hyper-V is the extremely poor support of Linux guests. – dyasny Jul 03 '12 at 21:46
  • Today we enabled VirtIO and selected the Westmere CPU for our Windows 2003 guest. The VM now runs with a very high performance, at least compared to the situation before. – PythonLearner Jul 06 '12 at 12:00
10

Qemu doesn't work in the same way many other hypervisors do. For starters, it can provide full emulation. That means you can run x86 code on an ARM processor, for example. When in KVM mode, as you're using it, it doesn't actually do that... the processor is exposed no matter what, but what is reported to the OS will be changed by the -cpu flag.

If you want faster speeds, it is a starting point to try and match the capabilities of the virtual processor to your real processor as best as possible. That will reduce cases where sub-optimal opcodes are called to run tasks, and will also reduce opcodes that aren't possible on your hardware being translated to something else first. Since your model of Xeon processor was released in early 2011, it probably supports mostly in-line with the Core i7 series. For that, I'd say that Nehalem architecture is your best emulation.

Quoting from one of your links (Tuning KVM):

To pass all available host processor features to the guest, use the command line switch

 qemu -cpu host

if you wish to retain compatibility, you can expose selected features to your guest. If all your hosts have these features, compatibility is retained:

 qemu -cpu qemu64,+ssse3,+sse4.1,+sse4.2,+x2apic

Thus, if you feel that you may end up moving things around enough to create an issue, you could find all the supported instruction sets you think any processor your have now or may have in the future supports and listing those off.

Most of the time, though, you want to stick to -cpu host. Specifying a CPU with less available flags means applications will avoid using features that could make them faster.

Jeff Ferland
  • 20,239
  • 2
  • 61
  • 85
3

You are getting the '-cpu host' option confused. This option does NOT enable only all of the CPU features specific to your host system, it enables ALL features that your CPU supports and all that can be emulated even if your CPU does not support them.

-cpu host
is a good option but not the most efficient, because it might enable options that can be emulated that your cpu doesnt support, the guest system can be slightly slowed down anytime it tries to use one of these features that needs to be emulated.

Source: http://wiki.qemu.org/Features/CPUModels

Joe Huss
  • 71
  • 3
  • 1
    Initially I thought this answer referred to instruction support e.g. SSE support that could be emulated. But of course that doesn't make sense as you either run in KVM mode or TCG and not a mix of the both. So I guess the emulation referred to here might be things like x2apic where there is no h/w support but the kernel can fake it. I only mention this to try and clarify the above as it had me initially confused. – Goblinhack Jun 09 '15 at 01:13
-2

CentOS 6.7 gives me proper KVM+Spice performance on Dell R910. I think once you give it a shot you will not go back to anything else (seriously)!