From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NrUP3-00086d-4a for qemu-devel@nongnu.org; Tue, 16 Mar 2010 06:53:37 -0400 Received: from [199.232.76.173] (port=34604 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NrUP2-00085z-Kc for qemu-devel@nongnu.org; Tue, 16 Mar 2010 06:53:36 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NrUOq-0006E4-5F for qemu-devel@nongnu.org; Tue, 16 Mar 2010 06:53:36 -0400 Received: from mx20.gnu.org ([199.232.41.8]:48410) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NrUOp-0006Ar-IC for qemu-devel@nongnu.org; Tue, 16 Mar 2010 06:53:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NrU3y-0003YE-Uh for qemu-devel@nongnu.org; Tue, 16 Mar 2010 06:31:51 -0400 Date: Tue, 16 Mar 2010 10:31:46 +0000 From: "Daniel P. Berrange" Message-ID: <20100316103146.GF23617@redhat.com> References: <20100316070155.GK3732@x200.localdomain> <20100316092944.GB23617@redhat.com> <4B9F52D4.2030208@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B9F52D4.2030208@redhat.com> Subject: [Qemu-devel] Re: KVM call agenda for Mar 16 Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Chris Wright , qemu-devel@nongnu.org, kvm@vger.kernel.org, Juan Quintela On Tue, Mar 16, 2010 at 11:43:48AM +0200, Avi Kivity wrote: > 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. Yes, for the QEMU upstream adding an event is more flexible. I had originally suggested exiting in the context of the Fedora bug report which was for QEMU 0.10.x which has no events capability. > > > >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@? Yep, sure thing. This is the only polling loop that isn't related to I/O stats collection. > > Polling loops are an indication that something is wrong. Except when people suggest they are the right answer, qcow high watermark ;-P Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|