From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47088) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7gPr-0003rp-N2 for qemu-devel@nongnu.org; Wed, 24 Jun 2015 04:52:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7gPo-0005Vn-E8 for qemu-devel@nongnu.org; Wed, 24 Jun 2015 04:52:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38087) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7gPo-0005VV-6w for qemu-devel@nongnu.org; Wed, 24 Jun 2015 04:52:16 -0400 Date: Wed, 24 Jun 2015 09:52:09 +0100 From: "Daniel P. Berrange" Message-ID: <20150624085209.GA25601@redhat.com> References: <20150608201835.GM3525@orkuz.home> <558951C0.3050806@suse.de> <20150623150828.GD3134@thinpad.lan.raisama.net> <20150623173048-mutt-send-email-mst@redhat.com> <20150623155832.GE3134@thinpad.lan.raisama.net> <55898637.6080804@suse.de> <20150623162555.GL30318@redhat.com> <20150623183115-mutt-send-email-mst@redhat.com> <20150623164204.GM30318@redhat.com> <20150623231818-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150623231818-mutt-send-email-mst@redhat.com> Subject: Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: mimu@linux.vnet.ibm.com, qemu-devel@nongnu.org, Alexander Graf , borntraeger@de.ibm.com, Igor Mammedov , Paolo Bonzini , Jiri Denemark , rth@twiddle.net, Andreas =?utf-8?Q?F=C3=A4rber?= , Eduardo Habkost 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 :|