Re: [sami] Trying to figure out where we are

Thomas Narten <narten@us.ibm.com> Wed, 24 August 2011 12:22 UTC

Return-Path: <narten@us.ibm.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 629B721F8548 for <sami@ietfa.amsl.com>; Wed, 24 Aug 2011 05:22:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.453
X-Spam-Level:
X-Spam-Status: No, score=-106.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 33hkWzcV8Oni for <sami@ietfa.amsl.com>; Wed, 24 Aug 2011 05:22:07 -0700 (PDT)
Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by ietfa.amsl.com (Postfix) with ESMTP id C8D8D21F843B for <sami@ietf.org>; Wed, 24 Aug 2011 05:22:06 -0700 (PDT)
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7OBx011016341 for <sami@ietf.org>; Wed, 24 Aug 2011 07:59:00 -0400
Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7OCN9Iw266698 for <sami@ietf.org>; Wed, 24 Aug 2011 08:23:09 -0400
Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7O6N7Hs014575 for <sami@ietf.org>; Wed, 24 Aug 2011 00:23:08 -0600
Received: from cichlid.raleigh.ibm.com (sig-9-65-218-237.mts.ibm.com [9.65.218.237]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p7O6N6CU014509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Aug 2011 00:23:07 -0600
Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id p7OCN51m005937; Wed, 24 Aug 2011 08:23:06 -0400
Message-Id: <201108241223.p7OCN51m005937@cichlid.raleigh.ibm.com>
To: zhangyunfei <zhangyunfei@chinamobile.com>
In-reply-to: <201108241403546051654@chinamobile.com>
References: <CA77E180.13DD5%bschlies@cisco.com> <4E541EE7.1080605@gmail.com> <000c01cc6220$3b18fa70$b14aef50$@com> <201108241403546051654@chinamobile.com>
Comments: In-reply-to "zhangyunfei" <zhangyunfei@chinamobile.com> message dated "Wed, 24 Aug 2011 14:03:54 +0800."
Date: Wed, 24 Aug 2011 08:23:05 -0400
From: Thomas Narten <narten@us.ibm.com>
Cc: "Yingjie Gu(yingjie)" <guyingjie@huawei.com>, 'Melinda Shore' <melinda.shore@gmail.com>, "sami@ietf.org" <sami@ietf.org>
Subject: Re: [sami] Trying to figure out where we are
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: Wed, 24 Aug 2011 12:22:07 -0000

"zhangyunfei" <zhangyunfei@chinamobile.com> writes:

> I can share a use case here from our point of view in data center
> operation(will detail this in the upcoming draft as Yingjie said): We
> are considering running different services (e.g., VoIP and streaming
> services) by VM in the same cluster withinn data center. We know
> different services show different user visiting behaviors. For
> example, in the midnight, there are few VoIP usage while there are
> still large amount of streaming usage( this is just an example, maybe
> not so accurate to fit with the reality). In such case, we'd like
> merge the existing VoIP and streaming services into fewer machines and
> cut down the machines running only few VoIP usage to reduce the power
> consumption.  In this senario, we need to consider how to migrate the
> existing VM states.

How is this any different than standard VM migration as practiced
today? What special requirements result from the above scenario?

The topic of this effort is "state migration". In order to make
progress, we need to be very specific about what kind of state and in
what devices needs to be transferred. And why existing approaches as
practiced today are insufficient.

If folk cannot (in one or two paragraphs) answer the above questions,
I do not think writing an Internet Draft about the above would be a
good use of anyone's time.

Thomas