Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt

[Anthony Liguori]

On 03/11/2012 08:27 AM, Gleb Natapov wrote:
> On Sat, Mar 10, 2012 at 12:24:47PM -0600, Anthony Liguori wrote:
> > Let's step back here.
> >
> > Why are you writing these patches?  It's probably not because you
> > have a desire to say -cpu Westmere when you run QEMU on your laptop.
> > I'd wager to say that no human has ever done that or that if they
> > had, they did so by accident because they read documentation and
> > thought they had to.
> I'd be glad if QEMU will chose -cpu Westmere for me if it detects
> Westmere host CPU as a default.

This is -cpu best that Alex proposed FWIW.

> > Humans probably do one of two things: 1) no cpu option or 2) -cpu host.
> And both are not optimal. Actually both are bad. First one because
> default cpu is very conservative and the second because there is no
> guaranty that guest will continue to work after qemu or kernel upgrade.
>
> Let me elaborate about the later. Suppose host CPU has kill_guest
> feature and at the time a guest was installed it was not implemented by
> kvm. Since it was not implemented by kvm it was not present in vcpu
> during installation and the guest didn't install "workaround kill_guest"
> module. Now unsuspecting user upgrades the kernel and tries to restart
> the guest and fails. He writes angry letter to qemu-devel and is asked to
> reinstall his guest and move along.

-cpu best wouldn't solve this.  You need a read/write configuration file where 
QEMU probes the available CPU and records it to be used for the lifetime of the VM.

> > So then why are you introducing -cpu Westmere?  Because ovirt-engine
> > has a concept of datacenters and the entire datacenter has to use a
> > compatible CPU model to allow migration compatibility.  Today, the
> > interface that ovirt-engine exposes is based on CPU codenames.
> > Presumably ovirt-engine wants to add a Westmere CPU group and as
> > such have levied a requirement down the stack to QEMU.
> First of all this is not about live migration only. Guest visible vcpu
> should not change after guest reboot (or hibernate/resume) too. And
> second this concept exists with only your laptop and single guest on it
> too. There are three inputs into a "CPU model module": 1) host cpu, 2)
> qemu capabilities, 3) kvm capabilities. With datacenters scenario all
> three can change, with your laptop only last two can change (first one
> can change too when you'll get new laptop) , but the net result is that
> guest visible cpuid can change and it shouldn't. This is the goal of
> introducing -cpu Westmere, to prevent it from happening.

This discussion isn't about whether QEMU should have a Westmere processor 
definition.  In fact, I think I already applied that patch.

It's a discussion about how we handle this up and down the stack.

The question is who should define and manage CPU compatibility.  Right now QEMU 
does to a certain degree, libvirt discards this and does it's own thing, and 
VDSM/ovirt-engine assume that we're providing something and has built a UI 
around it.

What I'm proposing we consider: have VDSM manage CPU definitions in order to 
provide a specific user experience in ovirt-engine.

We would continue to have Westmere/etc in QEMU exposed as part of the user 
configuration.  But I don't think it makes a lot of sense to have to modify QEMU 
any time a new CPU comes out.

Regards,

Anthony Liguori