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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list