Re: [apps-discuss] proposal for Virtual desktop infrastructure (VDI) work in APP area
Peter Saint-Andre <stpeter@stpeter.im> Wed, 09 March 2011 02:46 UTC
Return-Path: <stpeter@stpeter.im>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 777A33A680D for <apps-discuss@core3.amsl.com>; Tue, 8 Mar 2011 18:46:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.626
X-Spam-Level:
X-Spam-Status: No, score=-102.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cetda2OUpnK for <apps-discuss@core3.amsl.com>; Tue, 8 Mar 2011 18:46:17 -0800 (PST)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 2B6603A680C for <apps-discuss@ietf.org>; Tue, 8 Mar 2011 18:46:17 -0800 (PST)
Received: from squire.local (dsl-251-69.dynamic-dsl.frii.net [216.17.251.69]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B84FC400F6; Tue, 8 Mar 2011 20:07:28 -0700 (MST)
Message-ID: <4D76EA41.3030204@stpeter.im>
Date: Tue, 08 Mar 2011 19:47:29 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <AANLkTi=N7imgT5P1uZL4=xR8zvQXGoeAV5rXiv5GqOEo@mail.gmail.com> <AANLkTin+kpzuPp9Ac57+zkDE8G9A7f7VW9R7tWtAdYRp@mail.gmail.com> <4D72C318.7090303@vpnc.org>
In-Reply-To: <4D72C318.7090303@vpnc.org>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms090704020507000200000407"
Cc: meng.yu@zte.com.cn, "So, Ning" <ning.so@verizonbusiness.com>, wang.jun17@zte.com.cn, apps-discuss@ietf.org, Suren Karavettil <surenck@gmail.com>
Subject: Re: [apps-discuss] proposal for Virtual desktop infrastructure (VDI) work in APP area
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Mar 2011 02:46:18 -0000
<hat type='individual'/> On 3/5/11 4:11 PM, Paul Hoffman wrote: > First off, I think this work could be very useful both in the short and > long run. I am swimming in these issues today in my work, so please do > not take the response below as diminishing the need. > > I question whether or not the IETF would be the best place for this. I > say that not because "SDO X would be better than the IETF" because if > that were the case, SDO X would have done so by now. Paul, I'm not sure that follows. :) Many factors are involved in the standardization (or lack thereof) within a particular problem domain. > However, most of > the interesting work here is, in fact, an API. Note that I am *not* one > of the people who says "the IETF { doesn't / can't } do APIs"; I think > we do/can as long as we are upfront about it. Another question is: can we do it well? And, more specifically, do we have reason to think that we might do it well in the virtual desktop infrastructure (VDI) space? > In specific (a fixed chart): > > +---------------------------+ > | +-----------------------+ | > +-----------+ VDI protocol | | +------------------+ | | > | VDI Client|----------------+ + | Virtual Desktop | | | > +-----------+ | | | Agent | | | > | | +------------------+ | | > | | Guest OS | | > | +-----------------------+ | > | Virtual Machine | > | Hosted in a Data Center | > +---------------------------+ > > Given that the text of the proposed charter says that the protocol would > be between the VDI Client and the Virtual Desktop Agent", which might be > software running on a Guest OS with no network connectivity, this will > be an API unless there is a requirement that the Guest OS has network > connectivity at a known and predictable address, and that the Virtual > Machine (actually, the host system) also has network connectivity at a > known and predictable address, and neither is firewalled from the VDI > client. Roughly what percentage of Guest OS and VM systems have network connectivity of the kind that would enable use of a protocol instead of an API? That might be helpful information. > A different model would be that the VDI Client has a new protocol to > talk to the host system, and that the host system has an API for talking > to the Guest OS in a way that would reach the Virtual Desktop Agent. > This model has some advantages over the narrow one in the charter. For > example, the protocol would allow control over Guest OSs, such as "start > up machine X" and "send text to the console on machine X". These will > work even if the Guest OS does not support the API, or if it does not > currently have network connectivity. Yes, that does seem like a powerful model. Roughly what percentage of VDI systems are architected that way currently, as opposed to the model outlined in the proposed charter? How does what you've described differ from draft-wang-clouds-vdi-problem-statement-00? (And as I'm sure you've thought about, the security considerations might get "interesting" if the VDI client has permissions to do things at the host level.) > The proposed WG could come up with requirements for both the > client-to-host protocol and the API between the host and the desktop > agent, and the two could clearly have some good interactions. In your opinion, which would come first -- the protocol or the API? > (And for those of you who want to come up to speed on the terminology > used in virtualization and some of the security issues, please see NIST > SP 800-125 > <http://csrc.nist.gov/publications/nistpubs/800-125/SP800-125-final.pdf>. Thanks for providing the reference. Peter -- Peter Saint-Andre https://stpeter.im/
- [apps-discuss] proposal for Virtual desktop infra… Bhumip Khasnabish
- Re: [apps-discuss] proposal for Virtual desktop i… Paul Hoffman
- [apps-discuss] proposal for Virtual desktop infra… Bhumip Khasnabish
- Re: [apps-discuss] proposal for Virtual desktop i… John Levine
- Re: [apps-discuss] proposal for Virtual desktop i… Paul Hoffman
- Re: [apps-discuss] proposal for Virtual desktop i… Scott W Brim
- Re: [apps-discuss] proposal for Virtual desktop i… Peter Saint-Andre
- Re: [apps-discuss] proposal for Virtual desktop i… Cullen Jennings
- Re: [apps-discuss] proposal for Virtual desktop i… Peter Saint-Andre
- Re: [apps-discuss] proposal for Virtual desktop i… Paul Hoffman
- Re: [apps-discuss] proposal for Virtual desktop i… wang.jun17