From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yoshiaki Tamura Subject: Re: [Qemu-devel] Re: [PATCH 19/19] migration: add a parser to accept FT migration incoming mode. Date: Sat, 29 Jan 2011 00:05:43 +0900 Message-ID: References: <1296199312-26334-1-git-send-email-tamura.yoshiaki@lab.ntt.co.jp> <1296199312-26334-20-git-send-email-tamura.yoshiaki@lab.ntt.co.jp> <4D42BD7D.8020004@redhat.com> <4D42D601.9010905@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kwolf@redhat.com, aliguori@us.ibm.com, dlaor@redhat.com, ananth@in.ibm.com, kvm@vger.kernel.org, mst@redhat.com, mtosatti@redhat.com, qemu-devel@nongnu.org, vatsa@linux.vnet.ibm.com, blauwirbel@gmail.com, ohmura.kei@lab.ntt.co.jp, avi@redhat.com, psuriset@linux.vnet.ibm.com, stefanha@linux.vnet.ibm.com To: Paolo Bonzini Return-path: Received: from mail-ew0-f46.google.com ([209.85.215.46]:53995 "EHLO mail-ew0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752023Ab1A1PFp convert rfc822-to-8bit (ORCPT ); Fri, 28 Jan 2011 10:05:45 -0500 Received: by ewy5 with SMTP id 5so1531973ewy.19 for ; Fri, 28 Jan 2011 07:05:43 -0800 (PST) In-Reply-To: <4D42D601.9010905@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 2011/1/28 Paolo Bonzini : > On 01/28/2011 02:53 PM, Yoshiaki Tamura wrote: >>> >>> > =A01) I am not sure what would happen with -incoming exec; >> >> Nothing happens if used with other protocols, but I assume you're >> mentioning that it's not clear from the code, which makes sense. > > I assume nothing just because the code for other protocols isn't usin= g > ft_mode. =A0However, for -incoming exec the parsing code as it is now= would > trigger if the executed file ended with "ft_mode". Hmm. Haven't thought about it. > So now I think it should be at the beginning of the scheme for forwar= d > compatibility with everything. =A0Is it possible to detect a migratio= n scheme > that does not support Kemari, and give an error in that case? Having a scheme like "kemari:tcp:host:port" looks quite challenging to me. We can of course add some quick hacks for it, but adding a nice layered architecture should be more appropriate. Similar to protocols and formats in block layer? At the same time, I want to avoid anything over engineered. Thanks, Yoshi > > Paolo > > From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=59564 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PiptR-0001Kb-7u for qemu-devel@nongnu.org; Fri, 28 Jan 2011 10:05:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PiptQ-00079D-9p for qemu-devel@nongnu.org; Fri, 28 Jan 2011 10:05:45 -0500 Received: from mail-ww0-f53.google.com ([74.125.82.53]:43472) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PiptQ-000793-4J for qemu-devel@nongnu.org; Fri, 28 Jan 2011 10:05:44 -0500 Received: by wwi18 with SMTP id 18so3208133wwi.10 for ; Fri, 28 Jan 2011 07:05:43 -0800 (PST) MIME-Version: 1.0 Sender: tamura.yoshiaki@gmail.com In-Reply-To: <4D42D601.9010905@redhat.com> References: <1296199312-26334-1-git-send-email-tamura.yoshiaki@lab.ntt.co.jp> <1296199312-26334-20-git-send-email-tamura.yoshiaki@lab.ntt.co.jp> <4D42BD7D.8020004@redhat.com> <4D42D601.9010905@redhat.com> Date: Sat, 29 Jan 2011 00:05:43 +0900 Message-ID: Subject: Re: [Qemu-devel] Re: [PATCH 19/19] migration: add a parser to accept FT migration incoming mode. From: Yoshiaki Tamura Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: kwolf@redhat.com, aliguori@us.ibm.com, mtosatti@redhat.com, ananth@in.ibm.com, kvm@vger.kernel.org, mst@redhat.com, dlaor@redhat.com, qemu-devel@nongnu.org, vatsa@linux.vnet.ibm.com, blauwirbel@gmail.com, ohmura.kei@lab.ntt.co.jp, avi@redhat.com, psuriset@linux.vnet.ibm.com, stefanha@linux.vnet.ibm.com 2011/1/28 Paolo Bonzini : > On 01/28/2011 02:53 PM, Yoshiaki Tamura wrote: >>> >>> > =A01) I am not sure what would happen with -incoming exec; >> >> Nothing happens if used with other protocols, but I assume you're >> mentioning that it's not clear from the code, which makes sense. > > I assume nothing just because the code for other protocols isn't using > ft_mode. =A0However, for -incoming exec the parsing code as it is now wou= ld > trigger if the executed file ended with "ft_mode". Hmm. Haven't thought about it. > So now I think it should be at the beginning of the scheme for forward > compatibility with everything. =A0Is it possible to detect a migration sc= heme > that does not support Kemari, and give an error in that case? Having a scheme like "kemari:tcp:host:port" looks quite challenging to me. We can of course add some quick hacks for it, but adding a nice layered architecture should be more appropriate. Similar to protocols and formats in block layer? At the same time, I want to avoid anything over engineered. Thanks, Yoshi > > Paolo > >