WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Xen API/libvirt & Remote

To: John Anderson <johnha@xxxxxxxxxx>
Subject: Re: [Xen-devel] Xen API/libvirt & Remote
From: Daniel Veillard <veillard@xxxxxxxxxx>
Date: Sat, 5 Aug 2006 04:27:49 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Delivery-date: Sat, 05 Aug 2006 01:28:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <A7F39817EC2477418A3AA053E69F835A3AA0FC@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <A7F39817EC2477418A3AA053E69F835A3AA0FC@xxxxxxxxxxxxxxxxxxxxxxxx>
Reply-to: veillard@xxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Fri, Aug 04, 2006 at 11:09:44AM -0700, John Anderson wrote:
> I'm guessing that in the future, libvirt will handle the network
> transport & authentication tasks I'm using gSOAP for currently.  When
> that happens it would be nice to have an SSL certificate authentication
> mechanism.

  I'm still wondering honnestly. There is so many way to do remote access
(custom protocol, XML-RPC, SOAP,CORBA, ...) and I would expect each 
'customer' to have his own type of deployed framework already, so I'm not
sure adding one kind of remote access capability would hit the 80/20 sweet
spot. It would also make things more complex (need for a daemon etc. though
there is already one for the proxy mode). I would also expect each deployment
to have it's own preferred authentication method which may vary greatly
depending on how and why they use virtualization (LDAP, SSH, etc...). Basically
the matrix of capabilities explodes and unless going though a very versatile
(plugin again) interface, hardcoding one may not be usable to most users.
  Maybe when we have more deployment and more use case feedback then it
should be considered more seriously, in the meantime explaining how things
could be done is probably the best approach.

    Feedback welcome :-)

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard@xxxxxxxxxx  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>