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

[[e-mail]]

Hi peter & all,
   I have replied Paul's mail once, but rejected by the app-discuss 
maillist, so I'm trying again here.
   At the section 2.1 in the problem statement draft, both VDA in the 
guest OS and in the host have been briefly discussed. 
   Regarding the APIs between VDA and host system, I think most of them 
are existing device I/O specifications and hardware platform specific, 
which should be left for system developers' decision. Actually, without 
any additional software installed in the guest, the host VDI model still 
works well, although not very well.

Russell


Peter Saint-Andre <[e-mail]> 写于 2011-03-09 10:47:29:

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



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.