[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On 03/12/2012 09:01 PM, Anthony Liguori wrote:
On 03/12/2012 01:53 PM, Itamar Heim wrote:
On 03/11/2012 05:33 PM, 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

(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.

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?

literally, or in capabilities?
literally means you want to allow passing the cpu name to be exposed
to the guest?

Yes, literally.

Xen exposes the host CPUID to the guest for PV. Both PHYP (IBM System P)
and z/VM (IBM System Z) do the same.

What does VMware expose to guests by default?

if in capabilities, how would it differ from choosing the correct "cpu
family"?
it wouldn't really be identical (say, number of cores/sockets and no
VT for time
being)

It's a trade off. From a RAS perspective, it's helpful to have
information about the host available in the guest.

If you're already exposing a compatible family, exposing the actual
processor seems to be worth the extra effort.

only if the entire cluster is (and will be?) identical cpu.
or if you don't care about live migration i guess, which could be hte case for clouds, then again, not sure a cloud provider would want to expose the physical cpu to the tenant.


ovirt allows to set "cpu family" per cluster. assume tomorrow it could
do it an
even more granular way.
it could also do it automatically based on subset of flags on all
hosts - but
would it really make sense to expose a set of capabilities which
doesn't exist
in the real world (which iiuc, is pretty much aligned with the cpu
families?),
that users understand?

No, I think the lesson we've learned in QEMU (the hard way) is that
exposing a CPU that never existed will cause something to break. Often
times, that something is glibc or GCC which tends to be rather epic in
terms of failure.

good to hear - I think this is the important part.
so from that perspective, cpu families sounds the right abstraction for general use case to me. for ovirt, could improve on smaller/dynamic subsets of migration domains rather than current clusters and sounds like you would want to see "expose host cpu for non migratable guests, or for identical clusters".


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]