From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juan Quintela Subject: KVM call minutes for 2013-08-06 Date: Tue, 06 Aug 2013 17:15:28 +0200 Message-ID: <878v0ehmun.fsf@elfo.elfo> Reply-To: quintela@redhat.com Mime-Version: 1.0 Content-Type: text/plain To: KVM devel mailing list , qemu-devel qemu-devel Return-path: Received: from mx1.redhat.com ([209.132.183.28]:28775 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753976Ab3HFPPv (ORCPT ); Tue, 6 Aug 2013 11:15:51 -0400 Sender: kvm-owner@vger.kernel.org List-ID: Hi if you find that Today minutes are better than usual, I am learning to delegate and ask people for help. Thanks to: - mst - eduardo - stephan 2013-08-06 ---------- What libvirt needs/miss Today? - how to handle machine types? creating them inside qemu? - qemu --cpu help only shows cpus, not what features qemu will use - qemu -cpu host what does this exactly means? kvm removes same flags. - Important to know if migration would work. - Machine types sometimes disable some feature, so cpu alone is not enough. - if kvm initialization fails, we should fall back to tcg, depending of command line options. - migration is not the only user case openstack choose host depending on what features the hosts have. - not easy shortcut that creating a guest with that options and query if features are there or not. - this information is "static", but it depends on: * configuration files * machine type * command line options * .... - So it is complicated to get it without launching a guest with the current command line. - Libvirt wants it because it is slow to use it, so they cache the information. - Libvirt creates a big table of supported options - At this point, libvirt don't export this information to its users - Anthony would send a qmp command proposal to qemu-devel@ - -cpu host "is not supported from cross-machine migration" you need to use -cpu host to check what features the host have. - kernel removes some features because it knows it can't be virtualised - qemu adds some others because it knows it don't need host support - and then lots of features in the middle Probing for host information ("-cpu host" details): * Needed to find out if it's possible to create or migrate a VM, or to choose an appropriate host to migrate to * Depends on host capabilities: CPU host capabilities, kernel capabilities (kernel version), QEMU capabilities (kernel version) * Does not depend on machine-type * libvirt will probably want to build a table beforehand, with information about all hosts * Note that live-migration of "-cpu host" is not supported, but we use the "-cpu host" results as a way to find out about host capabilities * Problem: allowing it to be probed using "-machine none" * Needs KVM to be initialized * Solution: add KVM to be requested with fallback to TCG (does it work today?) * libvirt should be able to create a "-cpu host" CPU object, query for its information, and destroy it Probing for the actual results of a given machine-type + CPU model combination: * Depends on machine-type * MUST NOT depend on host capabilities, otherwise migration would be already broken * Probably no need to build a large table with all machine-type/CPU-models combinations beforehand. Just querying for the information on the VM before migrating it should be enough? * Anyway, if libvirt needs to query for all combinations beforehand, we may provide a QMP command to apply compat properties from a machine-type (suggestion by Anthony) * pvpanic - was added by default in 1.5, this might have been too rash: - might change guest behaviour if guest is set to reboot on panic - might cause slightly annoying warnings/queries from device manager - generally somewhat inelegant/non-symmetrical, libvirt developers prefer "no magic devices" - conclusions: - for -M 1.6, will change QEMU don't add by default, teach libvirt to add with -device pvpanic - separately discuss doing same for 1.5 stable branch and -M 1.5 on mailing list * reverse execution for qemu caturing IO is complicated determinising and the clocks how it relates with kemari you don't need to wait for two weeks. they do a fork as an snapshot instead of getting the machine to snapshot itself. merging forks and threads: enough said. icount changes for reverse execution will probably conflict with qemu-timer.c changes for thread-safety and AioContext timers. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58188) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6izO-0007sy-02 for qemu-devel@nongnu.org; Tue, 06 Aug 2013 11:16:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V6izH-0007qF-TQ for qemu-devel@nongnu.org; Tue, 06 Aug 2013 11:15:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10665) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6izH-0007px-5p for qemu-devel@nongnu.org; Tue, 06 Aug 2013 11:15:51 -0400 From: Juan Quintela Date: Tue, 06 Aug 2013 17:15:28 +0200 Message-ID: <878v0ehmun.fsf@elfo.elfo> MIME-Version: 1.0 Content-Type: text/plain Subject: [Qemu-devel] KVM call minutes for 2013-08-06 Reply-To: quintela@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: KVM devel mailing list , qemu-devel qemu-devel Hi if you find that Today minutes are better than usual, I am learning to delegate and ask people for help. Thanks to: - mst - eduardo - stephan 2013-08-06 ---------- What libvirt needs/miss Today? - how to handle machine types? creating them inside qemu? - qemu --cpu help only shows cpus, not what features qemu will use - qemu -cpu host what does this exactly means? kvm removes same flags. - Important to know if migration would work. - Machine types sometimes disable some feature, so cpu alone is not enough. - if kvm initialization fails, we should fall back to tcg, depending of command line options. - migration is not the only user case openstack choose host depending on what features the hosts have. - not easy shortcut that creating a guest with that options and query if features are there or not. - this information is "static", but it depends on: * configuration files * machine type * command line options * .... - So it is complicated to get it without launching a guest with the current command line. - Libvirt wants it because it is slow to use it, so they cache the information. - Libvirt creates a big table of supported options - At this point, libvirt don't export this information to its users - Anthony would send a qmp command proposal to qemu-devel@ - -cpu host "is not supported from cross-machine migration" you need to use -cpu host to check what features the host have. - kernel removes some features because it knows it can't be virtualised - qemu adds some others because it knows it don't need host support - and then lots of features in the middle Probing for host information ("-cpu host" details): * Needed to find out if it's possible to create or migrate a VM, or to choose an appropriate host to migrate to * Depends on host capabilities: CPU host capabilities, kernel capabilities (kernel version), QEMU capabilities (kernel version) * Does not depend on machine-type * libvirt will probably want to build a table beforehand, with information about all hosts * Note that live-migration of "-cpu host" is not supported, but we use the "-cpu host" results as a way to find out about host capabilities * Problem: allowing it to be probed using "-machine none" * Needs KVM to be initialized * Solution: add KVM to be requested with fallback to TCG (does it work today?) * libvirt should be able to create a "-cpu host" CPU object, query for its information, and destroy it Probing for the actual results of a given machine-type + CPU model combination: * Depends on machine-type * MUST NOT depend on host capabilities, otherwise migration would be already broken * Probably no need to build a large table with all machine-type/CPU-models combinations beforehand. Just querying for the information on the VM before migrating it should be enough? * Anyway, if libvirt needs to query for all combinations beforehand, we may provide a QMP command to apply compat properties from a machine-type (suggestion by Anthony) * pvpanic - was added by default in 1.5, this might have been too rash: - might change guest behaviour if guest is set to reboot on panic - might cause slightly annoying warnings/queries from device manager - generally somewhat inelegant/non-symmetrical, libvirt developers prefer "no magic devices" - conclusions: - for -M 1.6, will change QEMU don't add by default, teach libvirt to add with -device pvpanic - separately discuss doing same for 1.5 stable branch and -M 1.5 on mailing list * reverse execution for qemu caturing IO is complicated determinising and the clocks how it relates with kemari you don't need to wait for two weeks. they do a fork as an snapshot instead of getting the machine to snapshot itself. merging forks and threads: enough said. icount changes for reverse execution will probably conflict with qemu-timer.c changes for thread-safety and AioContext timers.