Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models

[Daniel P. Berrange]

On Tue, Jun 23, 2015 at 11:23:16PM +0200, Michael S. Tsirkin wrote:
> 
> So any single CPU flag now needs to be added in
> - kvm
> - qemu
> - libvirt

This is in fact already the case, and it will also possibly need
to be added to openstack too.

> Next thing libvirt will decide it's a policy thing and so
> needs to be pushed up to openstack.

In fact openstack would really like it if we did exactly that, but
even just having CPUs versioned separately from machine types would
be a big step forward as far as openstack is concerned.

The openstack schedular does not have full visibility into the way
the guest is going to be configured by libvirt/QEMU, in particular
it does not know anything about machine type that will be used by
the guest.

The compute hosts report what CPU features they can support, and
the user / admin will be able to express what CPU model and/or
features they desire their guest to run with, and the schedular
has to match that up to decide on hosts to use. If the CPU QEMU
machine type used can alter what the CPU model means in terms
of features, then the schedling decisions OpenStack is making
are going to be wrong some portion of the time.

So from the POV of the OpenStack schedular, we'd much rather
have CPU models versioned explicitly so their semantics do not
change behind our back based on machine types.

OpenStack is also looking at how to present a consistent
description of CPU models to users, which is independant of
the cloud. Since libvirt/QEMU doesn't allow 100% control of
the CPU model, OpenStack is likely going to have to define
some kind of manual mapping of its own.

> We should just figure out what you want to do and support it in QEMU.

Main thing is versioned CPU models with fixed semantics that
don't magically change based on other aspects of VM configuration,
such as the machine type. This could be accomplished by QEMU
alone.

Following on from that though, there's two other aspects which
we'd like to address. First, be able to present a consistent
set of CPU models across all hypervisors libvirt manages,
regardless of type or version. This is a key reason why we have
always maintained our own CPU model database, even though it
duplicates QEMU's.

More interesting is the question of host passthrough. We have
two modes for that - either 'host-model' or 'host-passthrough'.
The 'host-passthrough' option is something that explicitly
maps to QEMU's  '-cpu host'. This is good because it exposes
100% of the host CPU to the guest. This is bad because it then
prevents use of migration in general, unless both machines
are 100% identical - libvirt just blocks it rather than trying
todo such a fine grained host CPU check.

For that reason we have 'host-model', which is supposed to be
essentially the same thing instead of '-cpu host' we explicitly
list all the features alongside a named model. Since we control
exactly what the guest is being given, we can permit guests
with 'host-model' to be migrated, even if the destination host
is a superset of the source host, we know the guest won't
suddenly see a model change after migration. Currently we are
limited though, as we can only express the CPU features - we
cannot expose the other aspects like level, xlevel, etc. So
our 'host-model' is not quite as perfect a  match as '-cpu host'
is. The '-cpu custom' would help us getting a better match
for 'host-model' by allowing these extra things to be configured.

> Are there many examples where a single flag used to work and then
> stopped? I would say such a change is problematic anyway:
> not everyone uses libvirt, you are breaking things for people
> that run -M pc.
> 
> IMHO -M pc is not supposed to mean "can break at any time".

Well 'pc' is an unversioned machine type, so it explicitly is said to
break at any time - users/apps are supposed to translate that into a
versioned type if they want a guarantee of no breakage.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|