Re: [sami] First SAMI email in the new year, can we go further? Look forward to your opinions.

Benson Schliesser <bschlies@cisco.com> Fri, 02 March 2012 02:30 UTC

Return-Path: <bschlies@cisco.com>
X-Original-To: sami@ietfa.amsl.com
Delivered-To: sami@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECBE21E80CA for <sami@ietfa.amsl.com>; Thu, 1 Mar 2012 18:30:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.099
X-Spam-Level:
X-Spam-Status: No, score=-9.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImdZ7+iy6ioz for <sami@ietfa.amsl.com>; Thu, 1 Mar 2012 18:30:49 -0800 (PST)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDDB21E8012 for <sami@ietf.org>; Thu, 1 Mar 2012 18:30:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1387; q=dns/txt; s=iport; t=1330655448; x=1331865048; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=IcgBP7oGRPcTJYW/KIPuFUxztpFrshgEPWmOH0ZEndw=; b=QW3VB4nMwFN4Ea1zzHnYHqspxbhVj/P80O1BeqQdkdWPI0SQok/VJVMI lrocKCg1w6oCzamclVFnu1ehVocTn0n9EyVi6TBtA4iLf2/5Wzmx5nDQ+ yyaQPU/RA+ggdyDwiEq2KvNDLG3OczNhSX4GcuFTL0yD5pmtUDFSZ0Q/k 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAO0vUE+rRDoJ/2dsb2JhbABCtCKBB4F9AQEBAwESASdPC0ZXGSKHXwShDQGWdYwwDwENFgIIAgoBBgsCBgcPBgEKBgMChQIPCxQzGA+CP2MEiE+MbJMTgTs
X-IronPort-AV: E=Sophos;i="4.73,515,1325462400"; d="scan'208";a="31487158"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 02 Mar 2012 02:30:45 +0000
Received: from dhcp-171-71-146-239.cisco.com (dhcp-171-71-146-239.cisco.com [171.71.146.239]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q222Ujrp009905 for <sami@ietf.org>; Fri, 2 Mar 2012 02:30:45 GMT
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1084)
From: Benson Schliesser <bschlies@cisco.com>
In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05AEC8CCDE@MX14A.corp.emc.com>
Date: Thu, 01 Mar 2012 18:30:45 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <C4183517-50F0-4D50-A5A5-6D6904209C5F@cisco.com>
References: <A27496C192613C44A82D819E1B98DB5721DAE9A6@SZXEML511-MBS.china.huawei.com> <201203011329.q21DTbkD023885@cichlid.raleigh.ibm.com> <4F4F9DA3.5030901@gmail.com> <201203011613.q21GDAob025552@cichlid.raleigh.ibm.com> <4F4FA2CA.9060205@gmail.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05AEC8CCDE@MX14A.corp.emc.com>
To: sami@ietf.org
X-Mailer: Apple Mail (2.1084)
Subject: Re: [sami] First SAMI email in the new year, can we go further? Look forward to your opinions.
X-BeenThere: sami@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: State Migration <sami.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sami>, <mailto:sami-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sami>
List-Post: <mailto:sami@ietf.org>
List-Help: <mailto:sami-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sami>, <mailto:sami-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Mar 2012 02:30:50 -0000

On Mar 1, 2012, at 9:02 AM, <david.black@emc.com> <david.black@emc.com> wrote:

>> I think so, and there's no doubt it would be helpful to be clearer about
>> that going forward.  However, my understanding that while the VM image
>> would be moved (craploads of kernel state - file tables, page tables,
>> all that crap), network activity would have to be quiesced first.  
> 
> That understanding is incorrect - network activity is not quiesced.  A
> gratuitous ARP or RARP is issued after the migration, and some inbound
> packets may get dropped because they are delivered only to the source
> location of the migration.

Right. Minor packet loss is possible, but the VM migration is designed so that e.g. established TCP connections don't fail.

Like Thomas, I see that there is something to be done here. But I also agree that we need to figure out the use-cases first, driven by real operational requirements. It might help if we started talking about use-cases for VM migration - yes it's possible, but why do people use it? - so that we can figure out if any of them inform the discussion of state migration.

Further, are there any non-VM mobility use-cases for state migration? I can imagine a few, but again I want to make sure they're being driven by operational needs rather than mere possibility.

Cheers,
-Benson