Re: [dc] draft-khasnabish-vmmi-problems-00.txt

<david.black@emc.com> Fri, 20 January 2012 02:48 UTC

Return-Path: <david.black@emc.com>
X-Original-To: dc@ietfa.amsl.com
Delivered-To: dc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41A321F85A5 for <dc@ietfa.amsl.com>; Thu, 19 Jan 2012 18:48:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.912
X-Spam-Level:
X-Spam-Status: No, score=-108.912 tagged_above=-999 required=5 tests=[AWL=1.687, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 HUlY2kRboEWs for <dc@ietfa.amsl.com>; Thu, 19 Jan 2012 18:48:43 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id F02BE21F85A4 for <dc@ietf.org>; Thu, 19 Jan 2012 18:48:42 -0800 (PST)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0K2me6D024491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jan 2012 21:48:41 -0500
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 19 Jan 2012 21:48:30 -0500
Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0K2mT4w014953; Thu, 19 Jan 2012 21:48:29 -0500
Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub16.corp.emc.com ([128.222.70.237]) with mapi; Thu, 19 Jan 2012 21:48:29 -0500
From: david.black@emc.com
To: adalela@cisco.com
Date: Thu, 19 Jan 2012 21:48:28 -0500
Thread-Topic: [dc] draft-khasnabish-vmmi-problems-00.txt
Thread-Index: AczW0qaLHjfaIrIARQ+n0SUnPfoMjQAPVYSwAAM0Bd8=
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7BB90E7@MX14A.corp.emc.com>
References: <CAH==cJxfmae0u0bSF4cn_haLgY1T-vnw2102PApzYtj5Aty=GQ@mail.gmail.com><CANtnpwhFJ746ooi9GUCxfBqsOXu14hDka0D9inhh5pPq3U_ZTA@mail.gmail.com><201201171540.q0HFeNan008591@cichlid.raleigh.ibm.com><CANtnpwjexDPazOXLYHHjn3+JDi-o49Bv5ptDExAZHAA8Ra2m-A@mail.gmail.com><201201191419.q0JEJTLF010649@cichlid.raleigh.ibm.com><1326989277.2513.4.camel@ecliptic.extremenetworks.com> <201201191747.q0JHlS5J015128@cichlid.raleigh.ibm.com>, <618BE8B40039924EB9AED233D4A09C5102CB2304@XMB-BGL-416.cisco.com>
In-Reply-To: <618BE8B40039924EB9AED233D4A09C5102CB2304@XMB-BGL-416.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Cc: dc@ietf.org
Subject: Re: [dc] draft-khasnabish-vmmi-problems-00.txt
X-BeenThere: dc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Data Center Mailing List <dc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dc>, <mailto:dc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dc>
List-Post: <mailto:dc@ietf.org>
List-Help: <mailto:dc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dc>, <mailto:dc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jan 2012 02:48:44 -0000

> - Do we need a "control plane" to transfer OVF specification from point
> A to B - the portability problem?

Was that supposed to be a serious question?

If it was, I suggest FTP or NFS, both of which are already used to move VM
images in practice, and are already specified in RFCs ;-).  OVF is fundamentally
a VM image format.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------
________________________________________
From: dc-bounces@ietf.org [dc-bounces@ietf.org] On Behalf Of Ashish Dalela (adalela) [adalela@cisco.com]
Sent: Thursday, January 19, 2012 8:20 PM
To: Thomas Narten; Steven Blake
Cc: dc@ietf.org
Subject: Re: [dc] draft-khasnabish-vmmi-problems-00.txt

I think it is fair to say that there is a difference between mobility
and portability. Mobility is live migration, but portability is
specifying a VM's properties, delete in one location and create in
another. The new location can be another hypervisor. In many cases, you
don't need mobility, just portability. E.g. if you have a disaster
recovery situation, then you aren't going to get mobility anyway.

DMTF has specified a standard called OVF (Open Virtualization Format)
that addresses the "description" of the VM. This format is supported by
various hypervisor vendors. So, some level of VM migration
standardization has already happened (albeit portability and not
mobility).

The questions are:

- Do we need a "control plane" to transfer VM state from point A to B -
the mobility problem?
- Do we need a "control plane" to transfer OVF specification from point
A to B - the portability problem?

The problem is relevant in the inter-datacenter, public-private, or
inter-cloud spaces, where there will be more than one hypervisor
controller by definition. Are we hitting the live migration issue today?
Maybe not. Is it conceivable that we will hit this issue? I think so.

However, the question has to be asked to the provider/operators and not
to the vendors.

Thanks, Ashish


-----Original Message-----
From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of
Thomas Narten
Sent: Thursday, January 19, 2012 11:17 PM
To: Steven Blake
Cc: dc@ietf.org
Subject: Re: [dc] draft-khasnabish-vmmi-problems-00.txt

Steven,

> Several system vendors (myself included) stood up in Taipei and said
> "one encapsulation, please".  If IETF can facilitate industry
> convergence on a small set of NVO3 encapsulations (preferably one),
that
> would be a big win for Ethernet switch vendors.

I agree completely.

But my questions were asking about the apparent lack of  interest from
operators/implementers/market players regarding Bhumip's draft and the
apparent desire to have some sort of standards work related to the
general VM migration problem.

Is there such interest?

Thomas

_______________________________________________
dc mailing list
dc@ietf.org
https://www.ietf.org/mailman/listinfo/dc
_______________________________________________
dc mailing list
dc@ietf.org
https://www.ietf.org/mailman/listinfo/dc