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

[Gleb Natapov]

On Sun, Mar 11, 2012 at 10:33:15AM -0500, Anthony Liguori wrote:
> On 03/11/2012 09:56 AM, Gleb Natapov wrote:
> >On Sun, Mar 11, 2012 at 09:12:58AM -0500, Anthony Liguori wrote:
> >>-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.
> 
> This would either mean:
> 
> A. pc-1.1 uses -cpu best with a fixed mask for 1.1
> 
> B. pc-1.1 hardcodes Westmere or some other family
> 
This would mean neither A nor B. May be it wasn't clear but I didn't talk
about -cpu best above. I am talking about any CPU model with fixed meaning
(not host or best which are host cpu dependant). Lets take Nehalem for
example (just to move from Westmere :)). Currently it has level=2. Eduardo
wants to fix it to be 11, but old guests, installed with -cpu Nehalem,
should see the same CPU exactly. How do you do it? Have different
Nehalem definition for pc-1.0 (which level=2) and pc-1.1 (with level=11).
Lets get back to Westmere. It actually has level=11, but that's only
expose another problem. Kernel 3.3 and qemu-1.1 combo will support
architectural PMU which is exposed in cpuid leaf 10. We do not want
guests installed with -cpu Westmere and qemu-1.0 to see architectural
PMU after upgrade. How do you do it? Have different Westmere definitions
for pc-1.0 (does not report PMU) and pc-1.1 (reports PMU). What happens
if you'll try to run qemu-1.1 -cpu Westmere on Kernel < 3.3 (without
PMU support)? Qemu will fail to start.


> (A) would imply a different CPU if you moved the machine from one
> system to another.  I would think this would be very problematic
> from a user's perspective.
> 
> (B) would imply that we had to choose the least common denominator
> which is essentially what we do today with qemu64.  If you want to
> just switch qemu64 to Conroe, I don't think that's a huge difference
> from what we have today.
> 
> >>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.
> 
> We do this today by exposing -cpu qemu64 by default.  If all you're
> advocating is doing -cpu Conroe by default, that's fine.
I am not advocating that. I am saying we should be able to amend qemu64
definition without breaking older guests that use it.

> 
> But I fail to see where this fits into the larger discussion here.
> The problem to solve is: I want to use the largest possible subset
> of CPU features available uniformly throughout my datacenter.
> 
> QEMU and libvirt have single node views so they cannot solve this
> problem on their own.  Whether that subset is a generic
> Westmere-like processor that never existed IRL or a specific
> Westmere processor seems like a decision that should be made by the
> datacenter level manager with the node level view.
> 
> If I have a homogeneous environments of Xeon 7540, I would probably
> like to see a Xeon 7540 in my guest.  Doesn't it make sense to
> enable the management tool to make this decision?
> 
Of course neither QEMU nor libvirt can't made a cluster wide decision.
If QEMU provides sane CPU model definitions (usable even with -nodefconfig)
it would be always possible to find the model that fits best. If the
oldest CPU in data center is Nehalem then probably -cpu Nehalem will do.
But our CPU model definitions have a lot of shortcomings and we were
talking with Edurado how to fix them when he brought this thread back to
life, so may be I stirred the discussion a little bit in the wrong
direction, but I do think those things are connected. If QEMU CPU model
definitions are not stable across upgrades how can we say to management
that it is safe to use them? Instead they insist in reimplementing the
same logic in mngmt layer and do it badly (because the lack of info).

--
			Gleb.