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

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jun 24, 2015 at 09:52:09AM +0100, Daniel P. Berrange wrote:
> 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.

Is this all just theoretical, or are there real examples
where things stop running? I keep hearing "feature xyz"
and it's impossible to argue reasonably about that IMHO.


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


Do you also want to migrate that? If yes, the problem
definitely becomes more than just CPU specific.


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

This duplicates code from QEMU though.
It looks like we need a tool to get the legal CPUs
that can run on the given host?
Would be easy to add, reusing QEMU codebase.
Maybe make it a new QEMU flag.


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

That's because you are looking at it from libvirt perspective.  From
QEMU command line, since pc is the default, this makes no sense IMHO:
look up usage advice on the internet, and you will see no one
specifies a machine type.


> -- 
> |: 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 :|