From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35739) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5Ub9-0006Md-48 for qemu-devel@nongnu.org; Thu, 18 Jun 2015 03:50:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5Ub3-00071P-Pb for qemu-devel@nongnu.org; Thu, 18 Jun 2015 03:50:54 -0400 Received: from mga03.intel.com ([134.134.136.65]:65192) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5Ub3-0006x1-Hy for qemu-devel@nongnu.org; Thu, 18 Jun 2015 03:50:49 -0400 From: "Li, Liang Z" Date: Thu, 18 Jun 2015 07:50:42 +0000 Message-ID: References: <1434450415-11339-1-git-send-email-dgilbert@redhat.com> <1434450415-11339-2-git-send-email-dgilbert@redhat.com> In-Reply-To: <1434450415-11339-2-git-send-email-dgilbert@redhat.com> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: "Dr. David Alan Gilbert (git)" , "qemu-devel@nongnu.org" Cc: "aarcange@redhat.com" , "yamahata@private.email.ne.jp" , "quintela@redhat.com" , "luis@cs.umu.se" , "amit.shah@redhat.com" , "pbonzini@redhat.com" , "david@gibson.dropbear.id.au" > diff --git a/docs/migration.txt b/docs/migration.txt index f6df4be..b4b93= d1 > 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. > + > +=3D Return path =3D > + > +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 throw= ing > 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) > + > +=3D Postcopy =3D > +'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 p= ostcopy phase? Lost the guest is too frightening for a cloud provider, we have a discussi= on with=20 Alibaba, they said that they can't use the postcopy feature unless there is= a mechanism to find the guest back. Liang