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