QEMU Virtual CPU version

Hi chaps,

On virtual machines deployed through Openstack folsom on EL6 I can see 
the CPU type in /proc/cpuinfo is something like "Intel Core 2 Duo 
P9xxx",
whereas in VMs deployed on vanilla EL6+libvirt the CPU type is "QEMU 
Virtual CPU version (cpu64-rhel6)".
Now, as to avoid confusion and weird questions from my users, I'd like 
to have "QEMU Virtual CPU version" on the Openstack VMs, too. How do I 
convince Openstack to do this for me?

Regards,
Lucian

-- 
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

[Daniel P. Berrange]

On Wed, Dec 19, 2012 at 03:43:37PM +0000, Nux! wrote:
>  Hi chaps,
>  
>  On virtual machines deployed through Openstack folsom on EL6 I can
>  see the CPU type in /proc/cpuinfo is something like "Intel Core 2
>  Duo P9xxx",
>  whereas in VMs deployed on vanilla EL6+libvirt the CPU type is "QEMU
>  Virtual CPU version (cpu64-rhel6)".
>  Now, as to avoid confusion and weird questions from my users, I'd
>  like to have "QEMU Virtual CPU version" on the Openstack VMs, too.
>  How do I convince Openstack to do this for me? 
If you don't tell libvirt to use any particular CPU, the KVM guests
will be given a crappy default CPU model, with minimal features.
That is what you're seeing with "QEMU Virtual CPU"

As of Folsom OpenStack will expose the best possible CPU to the
guest based on what CPUs your host has available. This is a
good thing because it maximises the performance of your guest.
This is what you're seeing with the "Intel Core 2 DuO" string.

  http://wiki.openstack.org/LibvirtXMLCPUModel


You really don't want to change the OpenStack config unless
you actually want worse performance for your guests.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

On 19.12.2012 15:48, Daniel P. Berrange wrote:
>  On Wed, Dec 19, 2012 at 03:43:37PM +0000, Nux! wrote:
>  You really don't want to change the OpenStack config unless
>  you actually want worse performance for your guests.
>
>  Daniel 
Oh, thanks Daniel! I thought the performance would be the same, just 
with a different cpu name.
Then I'll leave it as it is.

Cheers,
Lucian

-- 
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

[Daniel P. Berrange]

On Wed, Dec 19, 2012 at 03:51:52PM +0000, Nux! wrote:
>  On 19.12.2012 15:48, Daniel P. Berrange wrote:
>  >On Wed, Dec 19, 2012 at 03:43:37PM +0000, Nux! wrote:
>  >You really don't want to change the OpenStack config unless
>  >you actually want worse performance for your guests.
>  >
>  >Daniel
>  
>  Oh, thanks Daniel! I thought the performance would be the same, just
>  with a different cpu name. 
The CPU name is a shorthand for specifying CPU feature flags, which
in turns controls what CPU features guests can use. For example,
if your CPU has support for AES hardware encryption, you want to
be exposing this to your guests, otherwise they'll fallback to
slower software AES encryption

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

On 19.12.2012 15:54, Daniel P. Berrange wrote:
>  On Wed, Dec 19, 2012 at 03:51:52PM +0000, Nux! wrote:
> > On 19.12.2012 15:48, Daniel P. Berrange wrote:
> > >On Wed, Dec 19, 2012 at 03:43:37PM +0000, Nux! wrote:
> > >You really don't want to change the OpenStack config unless
> > >you actually want worse performance for your guests.
> > >
> > >Daniel
> >
> > Oh, thanks Daniel! I thought the performance would be the same, just
> > with a different cpu name.
>
>  The CPU name is a shorthand for specifying CPU feature flags, which
>  in turns controls what CPU features guests can use. For example,
>  if your CPU has support for AES hardware encryption, you want to
>  be exposing this to your guests, otherwise they'll fallback to
>  slower software AES encryption
>
>  Daniel 
Indeed.

Thanks for the lesson. ;-)

Lucian

-- 
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

cpu feature flags matter [was Re: QEMU Virtual CPU version]

[Matthew Miller]

On Wed, Dec 19, 2012 at 03:54:03PM +0000, Daniel P. Berrange wrote:
>  > Oh, thanks Daniel! I thought the performance would be the same,
> just
>  > with a different cpu name.
>  The CPU name is a shorthand for specifying CPU feature flags, which
>  in turns controls what CPU features guests can use. For example,
>  if your CPU has support for AES hardware encryption, you want to
>  be exposing this to your guests, otherwise they'll fallback to
>  slower software AES encryption 
To put some numbers to it, from testing I did in a virtualized HPC
environment, using the simple kcbench benchmark (which compiles the kernel
in a loop)

                   on hardware    generic flags    westmere
                      
runs completed:         103             88            100
ave kcbench score:    41127          34969          38885
ave wall time/run:    24.49s         28.72s         25.77s


This isn't representative of _all_ loads, of course, but I've found it to be
good, simple general case test. Here, with the generic flags, we see
a penalty of around 15%, but with the single change of using the specific
processor flags, it's closer to 5%.

Or to put it another way, setting the flags correctly gave an 11%
performance boost.



-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;