Re: [Libvir] Preliminary patch to support remote driver / libvirtd
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 -=|