From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42126) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5UuH-0001Xs-BF for qemu-devel@nongnu.org; Thu, 18 Jun 2015 04:10:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5UuC-0001cG-KM for qemu-devel@nongnu.org; Thu, 18 Jun 2015 04:10:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36246) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5UuC-0001c8-C2 for qemu-devel@nongnu.org; Thu, 18 Jun 2015 04:10:36 -0400 Date: Thu, 18 Jun 2015 09:10:28 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20150618081027.GA2248@work-vm> References: <1434450415-11339-1-git-send-email-dgilbert@redhat.com> <1434450415-11339-2-git-send-email-dgilbert@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v7 01/42] Start documenting how postcopy works. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Li, Liang Z" Cc: "aarcange@redhat.com" , "yamahata@private.email.ne.jp" , "quintela@redhat.com" , "qemu-devel@nongnu.org" , "luis@cs.umu.se" , "amit.shah@redhat.com" , "pbonzini@redhat.com" , "david@gibson.dropbear.id.au" * Li, Liang Z (liang.z.li@intel.com) wrote: > > diff --git a/docs/migration.txt b/docs/migration.txt index f6df4be..b4b93d1 > > 100644 > > --- a/docs/migration.txt > > +++ b/docs/migration.txt > > @@ -291,3 +291,170 @@ save/send this state when we are in the middle of a > > pio operation (that is what ide_drive_pio_state_needed() checks). If > > DRQ_STAT is not enabled, the values on that fields are garbage and don't > > need to be sent. > > + > > += Return path = > > + > > +In most migration scenarios there is only a single data path that runs > > +from the source VM to the destination, typically along a single fd > > +(although possibly with another fd or similar for some fast way of throwing > > pages across). > > + > > +However, some uses need two way communication; in particular the > > +Postcopy destination needs to be able to request pages on demand from > > the source. > > + > > +For these scenarios there is a 'return path' from the destination to > > +the source; > > +qemu_file_get_return_path(QEMUFile* fwdpath) gives the QEMUFile* for > > +the return path. > > + > > + Source side > > + Forward path - written by migration thread > > + Return path - opened by main thread, read by return-path thread > > + > > + Destination side > > + Forward path - read by main thread > > + Return path - opened by main thread, written by main thread AND > > postcopy > > + thread (protected by rp_mutex) > > + > > += Postcopy = > > +'Postcopy' migration is a way to deal with migrations that refuse to > > +converge; its plus side is that there is an upper bound on the amount > > +of migration traffic and time it takes, the down side is that during > > +the postcopy phase, a failure of > > +*either* side or the network connection causes the guest to be lost. > > Hi David, > > Do you have any idea or plan to deal with the failure happened during the postcopy phase? > > Lost the guest is too frightening for a cloud provider, we have a discussion with > Alibaba, they said that they can't use the postcopy feature unless there is a mechanism to > find the guest back. The VM memory image is still on the source VM, so you can restart the source, however that's not safe, because once the destination has started running it is sending out packets and also modifying the block storage. If you restarted the source at that point what block and net state can you accept being visible? Dave > > Liang -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK