From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33750) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROZZn-00077W-3x for qemu-devel@nongnu.org; Thu, 10 Nov 2011 13:42:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ROZZl-0007TZ-Mj for qemu-devel@nongnu.org; Thu, 10 Nov 2011 13:42:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:26270) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROZZl-0007TJ-FX for qemu-devel@nongnu.org; Thu, 10 Nov 2011 13:42:13 -0500 Date: Thu, 10 Nov 2011 18:42:00 +0000 From: "Daniel P. Berrange" Message-ID: <20111110184200.GC17987@redhat.com> References: <4EBAAA68.10801@redhat.com> <4EBAACAF.4080407@codemonkey.ws> <4EBAB236.2060409@redhat.com> <4EBAB9FA.3070601@codemonkey.ws> <4EBB919B.7040605@redhat.com> <4EBC1792.3030004@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4EBC1792.3030004@codemonkey.ws> Subject: Re: [Qemu-devel] qemu and qemu.git -> Migration + disk stress introduces qcow2 corruptions Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Lucas Meneghel Rodrigues , Kevin Wolf , KVM mailing list , "Michael S. Tsirkin" , "libvir-list@redhat.com" , Marcelo Tosatti , QEMU devel , Juan Jose Quintela Carreira , Avi Kivity On Thu, Nov 10, 2011 at 12:27:30PM -0600, Anthony Liguori wrote: > What does libvirt actually do in the monitor prior to migration > completing on the destination? The least invasive way of doing > delayed open of block devices is probably to make -incoming create a > monitor and run a main loop before the block devices (and full > device model) is initialized. Since this isolates the changes > strictly to migration, I'd feel okay doing this for 1.0 (although it > might need to be in the stable branch). The way migration works with libvirt wrt QEMU interactions is now as follows 1. Destination. Run qemu -incoming ...args... Query chardevs via monitor Query vCPU threads via monitor Set disk / vnc passwords Set netdev link states Set balloon target 2. Source Set migration speed Set migration max downtime Run migrate command (detached) while 1 Query migration status if status is failed or success break; 3. Destination If final status was success Run 'cont' in monitor else kill QEMU process 4. Source If final status was success and 'cont' on dest succeeded kill QEMU process else Run 'cont' in monitor In older libvirt, the bits from step 4, would actually take place at the end of step 2. This meant we could end up with no QEMU on either the source or dest, if starting CPUs on the dest QEMU failed for some reason. We would still really like to have a 'query-migrate' command for the destination, so that we can confirm that the destination has consumed all incoming migrate data successfully, rather than just blindly starting CPUs and hoping for the best. 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 :|