Re: [sami] Welcome to SAMI and something you may like to know.

Melinda Shore <melinda.shore@gmail.com> Thu, 18 August 2011 16:01 UTC

Return-Path: <melinda.shore@gmail.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 D7ED621F8C21 for <sami@ietfa.amsl.com>; Thu, 18 Aug 2011 09:01:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 179tm6yke7Fn for <sami@ietfa.amsl.com>; Thu, 18 Aug 2011 09:01:32 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 49AC821F8C20 for <sami@ietf.org>; Thu, 18 Aug 2011 09:01:32 -0700 (PDT)
Received: by ywm21 with SMTP id 21so1677464ywm.31 for <sami@ietf.org>; Thu, 18 Aug 2011 09:02:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=BKPSDlqZEfcj8qmyVUWFJdkK01pdXhiXCBJBPQvSwMM=; b=b+I5Grh/I33M0ZQNmQCnW9UU5ISoOmHR1P94Z/xbzpVWCGqiawSzCp4R+D2X7b5SYm RbqKuqh/7nigVNGm+23rI4CYK8bGl3asdEP4aobkh9Mqj2mi5se5gPgxYfaZygiqA3Sa PzXxPqre5TjtxJsd0VRyfQppy4VH2XqAmR9ZA=
Received: by 10.142.6.6 with SMTP id 6mr475835wff.126.1313683346107; Thu, 18 Aug 2011 09:02:26 -0700 (PDT)
Received: from polypro.local (66-230-82-131-rb1.fai.dsl.dynamic.acsalaska.net [66.230.82.131]) by mx.google.com with ESMTPS id l7sm1566894pbh.42.2011.08.18.09.02.23 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Aug 2011 09:02:24 -0700 (PDT)
Message-ID: <4E4D378E.6020705@gmail.com>
Date: Thu, 18 Aug 2011 08:02:22 -0800
From: Melinda Shore <melinda.shore@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: sami@ietf.org
References: <004c01cc57ec$7f602ed0$7e208c70$@com> <20110811074034.GA12533@elstar.local> <005701cc5806$03cd8370$0b688a50$@com> <4A95BA014132FF49AE685FAB4B9F17F605189C80@dfweml504-mbx.china.huawei.com> <006001cc5cbb$de6c48e0$9b44daa0$@com> <4E4C6214.3010800@gmail.com> <12969308CE9E48DEAB5B5745D9482303@fanybP> <004c01cc5da6$5adb5660$10920320$@com>
In-Reply-To: <004c01cc5da6$5adb5660$10920320$@com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [sami] Welcome to SAMI and something you may like to know.
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: Thu, 18 Aug 2011 16:01:33 -0000

On 8/18/11 4:57 AM, Yingjie Gu(yingjie) wrote:
> We need to be aware that, not all L2 subnet has enough bandwidth or shared storage or reasonable migration distance to make VM migration succeed. In our scope, I suggest we only consider the L2 subnet which can support successful VM migration, in which case we has the reason to consider state migration. Let's call it "qualified L2 subnet", which equals to Yongbing's " L2 subnet with good enough performance ". It should be the users of "State Migration mechanism" to judge whether their L2 subnet is suitable for VM Migration and whether they should adopt State Migration mechanism in their subnet.
> Of course, even in a "qualified L2 subnet", VM migration can not be successful all the time. So, we also need to consider failure feedback mechanism.

Absolutely.  It seems to me that if you think that - for the purposes
of state migration - failing because there's insufficient network
resources is different from failing for some other reason, it might be
a good thing to explain why.  I could be convinced otherwise but for
the moment I don't think this is a particularly defensible distinction.

I'm also not clear on how much network bandwidth is needed to support
failover.  Intuitively it seems like the answer is "nearly none."
There may be issues around bandwidth available to the hot spare when
it goes live but if they're on the same layer 2 subnet/network segment,
the failed-from and failed-to servers are going to have pretty much
the same resources available to them.

Melinda