[Libvir] Preliminary patch to support remote driver / libvirtd

[Daniel P. Berrange]

On Thu, Feb 01, 2007 at 05:02:08PM +0000, Mark McLoughlin wrote:
> On Wed, 2007-01-31 at 15:25 +0000, Richard W.M. Jones wrote:
> 
> >   * Remote URLs contain either a server name or a remote transport
> >   * name.  For example: "qemud://server.example.com/system" contains
> >   * a server name (server.example.com), and "qemud+unix:///system"
> >   * contains a transport (unix).  Commonly remote URLs contain
> >   * both, for example: "qemud+tls://server.example.com/system"
> >   * (transport tls, server name server.example.com).
> 
> 	This makes my head hurt a bit, I think I prefer the libvirt:// even if
> it means encoding URIs in URIs.
> 
> 	i.e. I would expect to connect to e.g. qemud:// and xend:// URIs to
> using the same protocol whether the URI is local or remote.

That's already not the case with Xen.  I think of the leading foo:// bit of
the URI to mean the type of libvirt  driver being requested. For xen this can
be hypercalls, xend or libvirt_proxy. We now merely adding in libvirtd for
delaing with case of asking for a remote connection. Not to mention that
we reserve the right to change the underlying comms protocol associated with
a URI. eg changing from xend SEXPR to xend's XML-RPC/

> 	I don't know, it's not something I really care about ... but I'd find
> it strange if qemud+tls://foo.bar.com/system means "access
> qemud:///system via a libvirt proxy" ...

I all really comes down to what we want to define the URIs to mean in
the context of libvirt. With my virt-manager hat on, it makes life much
nicer to have qemud:///system  and qemud://example.com/system when 
dealing with URIs internally. 

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|