Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
Why bother with the -cpu switch at all? Just leave it out. –  psusi Jul 2 '12 at 23:07
1  
Why not bother with it? Afaik it could bring performance improvements. –  Valentin Jul 3 '12 at 8:22
    
If it has to step in and emulate things, it's going to hurt performance. Give it a try without. –  psusi Jul 3 '12 at 13:26
1  
I just found out that libvirt adds the parameter "-host qemu32" automatically, because we do not set it. –  Valentin Jul 4 '12 at 20:44
2  
@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. –  Valentin Jul 8 '12 at 19:19

4 Answers 4

up vote 6 down vote accepted

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]

share|improve this answer
    
Thanks dyasny, was hoping you'd reply and provide me with some sort of "golden rule"! –  Valentin Jul 3 '12 at 12:55

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

share|improve this answer
    
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. –  Valentin Jul 3 '12 at 8: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 3 '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 3 '12 at 13:49
    
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 3 '12 at 14:48
    
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 3 '12 at 21:46

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.

share|improve this answer
1  
He's using KVM, which needs those virtualization extensions and doesn't run do emulation; even if it's based on qemu –  Javier Jul 2 '12 at 22:40
    
Still +1 vote from me for the efforts and the recommendation to use -cpu host! –  Valentin Jul 3 '12 at 8:24

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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.