From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49878) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlGUm-0003k1-Gj for qemu-devel@nongnu.org; Tue, 26 Nov 2013 06:08:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VlGUd-0002D3-Ip for qemu-devel@nongnu.org; Tue, 26 Nov 2013 06:07:56 -0500 Received: from e28smtp02.in.ibm.com ([122.248.162.2]:36545) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlGUc-0002CW-SQ for qemu-devel@nongnu.org; Tue, 26 Nov 2013 06:07:47 -0500 Received: from /spool/local by e28smtp02.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 26 Nov 2013 16:37:42 +0530 Received: from d28relay02.in.ibm.com (d28relay02.in.ibm.com [9.184.220.59]) by d28dlp02.in.ibm.com (Postfix) with ESMTP id 4BADE394003F for ; Tue, 26 Nov 2013 16:37:40 +0530 (IST) Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rAQB7ZcJ30474358 for ; Tue, 26 Nov 2013 16:37:36 +0530 Received: from d28av03.in.ibm.com (localhost [127.0.0.1]) by d28av03.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rAQB7bqm006692 for ; Tue, 26 Nov 2013 16:37:38 +0530 Message-ID: <529480F6.60409@linux.vnet.ibm.com> Date: Tue, 26 Nov 2013 19:07:34 +0800 From: Lei Li MIME-Version: 1.0 References: <1385025100-3191-1-git-send-email-lilei@linux.vnet.ibm.com> <20131121101934.GA9135@redhat.com> <528F4001.3050600@linux.vnet.ibm.com> <528F41BD.1050007@redhat.com> <5292FC60.6080906@linux.vnet.ibm.com> <52931CED.9090103@redhat.com> In-Reply-To: <52931CED.9090103@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/17 v3] Localhost migration with side channel for ram List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Andrea Arcangeli , quintela@redhat.com, mdroth@linux.vnet.ibm.com, mrhines@linux.vnet.ibm.com, qemu-devel@nongnu.org, aliguori@amazon.com, lagarcia@br.ibm.com, rcj@linux.vnet.ibm.com On 11/25/2013 05:48 PM, Paolo Bonzini wrote: > Il 25/11/2013 08:29, Lei Li ha scritto: >> >> In this case, if the migration would fail just because the misconfiguration >> of device state on destination, in the meantime the outgoing migration has >> no aware of this failure, I think it should add such handling (like synchronize >> of the device state list in incoming side?) to the current migration protocol >> as it is kind of missing... It can not just rely on the resume of source >> guest for such failure... or maybe it should be handled in management >> app to force the configuration right? > It is already handled by libvirt, indeed. > > Basically, "-incoming" without "-S" is a broken option because of the > missing handshake at the end of migration. With "-S" something else > (either a human or a program) can check that everything went well and > choose whether to restart the source or the destination. I see, thanks for your explanation. :-) BTW, do you think we should add such handling to the current migration protocol? > >>> Postcopy would fix this (assuming the postcopy phase is reliable) by >>> migrating device data before any page flipping occurs. >> Are you suggesting that page flipping should be coupled with the postcopy >> migration for live upgrade of QEMU as your comments in the previous >> version? > In order to make live upgrade reliable, it should. The whole procedure for page flipping migration is straight forward, and the cases of failure I listed are in theory, which never happened at least since many times I have tested (except the case you raised above). But I agree with you on coupling with postcopy migration to make it more reliable, specially for the undetected problems. For this, I am not quite sure I understand it correctly, seems the latest update of post copy migration was sent on last Oct, would you please give some insights on what else could I do for the coupling with postcopy migration? If no, now page flipping is implemented as a migration capability, and it's a good shape already as your comments in the previous version. Although it still needs a little more time to get the numbers of the new vmsplice, I'd to ask your opinion that do you consider it could be merged as an experimental version for now? > > Paolo > -- Lei