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

[Paul Hoffman <[e-mail]>]

On 3/8/11 6:47 PM, Peter Saint-Andre wrote:
>> 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?

That is a very good question, and the answer depends on where you think 
the VDI protocol's endpoint it. The proposed charter has it being an 
agent in the Guest OS. As John Levine points out, this is essentially 
VNC (for which we now have RFC 6143) and/or Microsoft's RDC. It actually 
has nothing to do with "virtual" at all: it works as well for OSs 
running on real boxes as it does for guest OSs running in a hypervisor.

FWIW, I think that RFC 6143 could be extended to have some other 
features that are useful, such as file transfer and better security. But 
I don't think the IETF has any special knowledge (or lack thereof) for 
such extensions.

If you think that the VDI ends at the hypervisor, as I have proposed, 
this becomes a protocol that is more in line with the normal IETF work.

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

It is safe to assume that all hypervisors have network connectivity. The 
interesting question is for the guest OSs, and there are multiple 
answers. Many guest OSs have network connectivity to other guest OSs but 
not to the Internet: they are by design on switches with no contact 
outside the LAN. Some guest OSs are dual-homed, acting as gateways / 
firewalls / routers for other guest OSs on their LAN. And an 
often-ignored scenario is a guest OS that has no network connectivity 
because it is coming up for the first time or has been purposely pulled 
off all networks for security reasons.

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

All. That is, all hypervisors have methods to start up guest OSs, shut 
them down, and so on. Some have CLI languages to do so; a good example 
is VirtualBox's VBoxManage CLI.

> How does what you've described differ
> from draft-wang-clouds-vdi-problem-statement-00?

It's hard to say, but I don't see anything in that draft the requirement 
to control the hypervisor. It seems like the draft is really about 
supplanting VNC and RDC. Again, that might be a useful exercise, but the 
draft does not address whether it is better to just extend VNC or to 
start fresh.

> (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.)

Of course they have those permissions: that's what the entire draft is 
about. You want to be remote hands on the guest OS.

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

The protocol. The API already exists in VNC and RDC. Defining how the 
protocol interacts with the APIs is quite easy relative to defining what 
needs to be in the protocol itself.

OTOH, if there is not much interest in defining the protocol, I don't 
think a WG is needed.