From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM call agenda for Mar 16 Date: Tue, 16 Mar 2010 11:43:48 +0200 Message-ID: <4B9F52D4.2030208@redhat.com> References: <20100316070155.GK3732@x200.localdomain> <20100316092944.GB23617@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Juan Quintela , Chris Wright , kvm@vger.kernel.org, qemu-devel@nongnu.org To: "Daniel P. Berrange" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:34828 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756019Ab0CPJnw (ORCPT ); Tue, 16 Mar 2010 05:43:52 -0400 In-Reply-To: <20100316092944.GB23617@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 03/16/2010 11:29 AM, Daniel P. Berrange wrote: > On Tue, Mar 16, 2010 at 10:18:03AM +0100, Juan Quintela wrote: > >> Chris Wright wrote: >> >>> Please send in any agenda items you are interested in covering. >>> >> Migration: >> - flexible migration: I hope to sent an RFC patch on time for the >> call. idea is to use subsections. >> >> - callbacks. block migration introduced several callbacks: >> * cancel() >> * get_status() >> * release() >> in spice we need now another to callbacks: on_start() and on_end(). >> * on_start(): tells spice that migration has started (it will then >> manage certificates, passwords, ... itself) >> * on_end(): it is called when migration ends. spice use it to >> transparently connect to the new host and user don't have to "reconnect" >> >> - what to do on migration error: >> - target side: libvirt folks want the program to print a message if >> it fails. Current code spent 100% cpu time doing select on a closed >> fd. (patches already on the list to make it wait without using >> cpu). >> > No, that is not correct. We want QEMU to exit when incoming migration > fails. Printing to stderr is just something that will end up in the > logs for admin to further diagnose the problem if required. There is > nothing to be gained by leaving QEMU running, and everything to loose > since the failed migration may have left it in a dangerous state from > which you do not want to attempt incoming migration again. > > If we really want to leave it running when migration fails, then we're > going to have to add yet another QMP event to inform libvirt when > migration has finished/failed, and/or make 'query_migrate' work on > the destination too. > A qmp event seems the logical thing to do? Exiting can happen for many reasons, a qmp event is unambiguous. >> - source side: current behaviour if migration fails is to stop the >> vm. We have requests to make it continue (remember that this is >> live migration). what to do? adding a paramenter like the block >> layer: >> migration_error=[stop|continue] >> any better ideas. >> > A parameter to the 'migrate' monitor command would be the logical > place if we needed this configurable. > > Incidentally I have a feeling we might need to introduce a migration > event in QMP. Currently libvirt polls on the 'query_migrate' command > to get the ongoing migration status. This means there can be a delay > in detecting completion as long as the polling interval - for this > reason we just dropped libvirt's polling time from 1/2 sec to 50ms > to ensure prompt detection. > Whenever you implement a polling loop, can you send an event to qemu-devel@? Polling loops are an indication that something is wrong. -- error compiling committee.c: too many arguments to function