[libvirt] [PATCH 1/1] Support for RDP

[Daniel Veillard]

On Thu, Apr 23, 2009 at 01:32:24PM +0200, Pritesh Kothari wrote:
> Hi Daniel,
> 
> >   <graphics type='desktop'/>
> >   <graphics type='rdp' port='1234' autoport='no' listen='172.21.4.3'/>
> 
> this seems ok, but the only question I have is, currently libvirt supports 
> only one virDomainGraphicsDef, so is it ok for me add support for more then 
> one virDomainGraphicsDef? or else i don't see how i can have multiple 
> <graphics> tags.

  yes this is a limitation of the impelentation, not of the model, it
  makes more sense to allow multiple graphis entries.

> > If RDP is not enabled, then don't include the 2nd. If the local desktop
> > display is not enabled, then don't include the 1st. This avoids the
> > the 'headless' attribute being exposed in the XML directly. I chose
> > type='desktop' as representing the 'native' desktop app display of the
> > virt technology in question. I imagine it'll take similar attributes
> > to the type=sdl, while the type=rdp would be similar to type=vnc.
> 
> I had included headless attribute cause only one virDomainGraphicsDef was 
> there. I think that would not be necessary now if we support for more then 
> one virDomainGraphicsDef's, also adding multiple virDomainGraphicsDef's will 
> help me to implement some features for multiple screens :)

  You mean you have multiple screen support. Hum, it would have been
good to align with some of the Xorg naming for handling this. Though
what is Screen for them would still be a graphic for us.

> > For the allowMultiConnection & reuseSingleConnection attributes, I think
> > i'd prefer something a little less verbose as the XML attribute names.
> > How about
> >
> >     multiUser='yes|no'     (for allowMultiConnection)
> >     replaceUser='yes|no'   (for reuseSingleConnection)
> 
> great no problem,
> i guess i was just bogged down by too much details.

  also it's more generic and may be useful as other protocol evolves

> > For the local desktop window, is there any way in the API to indicate
> > what X display it should be shown on ? Obviously if launched within a
> > desktop session it'll display on that session. If I ssh into a remote
> > machine though, currently virtualbox libvirt driver will start the
> > display on the $DISPLAY from the forwarded SSH session virsh is running
> > in which isn't really what I wanted. I think we really need to be able
> > to indicate a desired X $DISPLAY (or equiv) in the XML for the local
> > desktop window graphics mode, eg, akin to the current SDL config we
> > could have
> >
> >    <graphics type='desktop' display=':0.0'/>
> 
> yes, there is an API for it as well but currently I am using 
> getenv("DISPLAY");implementing this was in my todo but didn't quite make it 
> to top, but will try to make it in next set of patches.

  Hum, getenv() is problematic in the absolute. Informations in the XML
config file should be sufficient to restore the state of the virtual
machine. I'm always trying to think with the following scenario:
   - domain runs on hypervisor in node A
   - domain gets migrated to node B
   - if one get an XML domain dump at that point, will the informations still
     be fully valid and sufficient to restart it from node B ?

  Here being able to stick the rendring to a given display may be
required, or harmful depending on the use case, which call for the
ability to either pin it with a display using a full name foobar:0.0
or display='local' (or the absence of a display information assumed
syntactically equivalent) where you would use the getenv("DISPLAY")

> feedback about attributes (auth='external' authtimeout='1234') would also be 
> appreciated. Thanks.

  auth='external' sounds unclear, what does this mean ? Having the
timeout hardcoded in the domain config file sounds a bit weird to me
I would expect the default behaviour to be sufficient, depending on
the networking layer used.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/