Re: [apps-discuss] proposal for Virtual desktop infrastructure (VDI) work in APP area

[Peter Saint-Andre <[e-mail]>]

<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/