9:56 a.m.
On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote:
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.
I didn't look at exact implementation but I doubt it does exactly what
we need because currently we do not have infrastructure for that. If qemu
is upgraded with support for new cpuid bits and -cpu best will pass them
to a guest on next boot then this is not the same. -cpu Westmere can
mean different thing for different machine types with proper
infrastructure in place.
>>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.
That what I thought too, but this shouldn't be the
case (Avi's idea).
We need two things: 1) CPU model config should be per machine type.
2) QEMU should refuse to start if it cannot create cpu exactly as
specified by model config.
With two conditions above if user creates VM with qemu 1.0 and cpu model
Westmere which has no kill_guest feature he will still be able to run it
in QEMU 1.1 (where kill_guest is added to Westmere model) and new kvm
that support kill_guest by providing -M pc-1.0 flag (old definition of
Westmere will be used). If user will try to create VM with QEMU 1.1 on
a kernel that does not support kill_guest QEMU will refuse to start.
>>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.
If we want QEMU to be usable
without management layer then QEMU should
provide stable CPU models. Stable in a sense that qemu, kernel or CPU
upgrade does not change what guest sees. If libvirt wants to override
QEMU we should have a way to allow that, but than compatibility becomes
libvirt problem. Figuring out what minimal CPU model that can be used
across a cluster of different machines should be ovirt task.
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.
If new cpu does not provide any new instruction set or capability that
can be passed to a guest then there is no point creating CPU model for
it in QEMU. If it does it is just a matter of updating config file. New
CPUs are not something that pops up twice a month.
--
Gleb.