On Tue, Jan 30, 2007 at 08:04:54PM +0000, Daniel P. Berrange wrote:
> On Tue, Jan 30, 2007 at 05:42:21PM +0000, Richard W.M. Jones wrote:
> > This patch is just for discussion. It's not in a state to be applied,
> > even if it were accepted (which is a long-shot at present anyway).
I'm in Paris this week at the expo, sorry it may be a bit difficult now
to do a full review, will do as soon as possible :-)
> > When looking at the patch, a good starting point is to search for
> > "Architecture and notes" and read from there.
> >
> > Supports:
> >
> > * remote driver (just does the "open", "close", "type" and
> > "version" calls at present as a proof of concept)
> > * TLS transport (built using GnuTLS)
> > * SSH transport (forks external ssh process)
> > * TCP transport (unencrypted - just for testing)
> > * Unix domain socket transport
> > * arbitrary external program / shell script transport
> > * IPv6-ready on client & server
> >
> > I've tested all the transports, and in limited tests they all
> > seem to work. ie. You really can do:
> >
> > virsh -c remote:tls:server version
>
> I don't think that's valid URI syntax - although we've got the historical
> cruft of a simple 'xen' connect string, we're trying to get the rest of
> the backends to use sane URIs. We need to be able to express the actual
> backend driver in this URI, so that its possible to pass it into the
> virConnectOpen method on the server side.
Let's stick to the URI syntax. basically the first part must indicate the
protocol, I suggest using something like
libvirt+tls://hostname/
And if you just want to do xen monitoring or qemu monitoring
libvirt+tls://hostname/#xen
libvirt+tls://hostname/#qemu
It should be possible at the connection level to indicate which subset one
is interested in and pass it down at the protocol level when establishing the
connection.
I'm still wondering about read-only connections I could see how one client
want to garantee no side effect, maybe libvirtro+tls://hostname/ ...
> Current drivers have prefixes like
>
> qemud:///
> test:///default
>
> We could make use of the host/port number component to signify that the
> driver should use the libvirtd. So 'test:///default' would be procssed
> by the driver locally, while 'test://example.com/default' would get
> picked up by the 'remote' driver which would strip the host/port bit
> and pass 'test:///default' to the virConnectOpen method on the remote
> end.
yes, libxml2 has all the parsing routines necessary already if needed,
http://xmlsoft.org/html/libxml-uri.html
> > * There's some confusion about the level of abstraction. At
> > the moment I'm abstracting at the driver level, but that may
> > be wrong and possibly I should be abstracting at the level
> > of vir* calls. On the other hand, there's not a huge amount
> > of difference.
>
> The only interesting difference is probably in the virConnectOpen
> method where we iterate over the drivers figuring out which one to
> activate. Once you have an activated driver, then it doesn't matter
> really whether you call the public, or driver APIs. I think I'd
> probably start off at the vir* call level.
I would say at the vir call level unless a specific 'driver' is
asked for say with #qemu. The only trick is that #xen is implemented by
3 drivers, the existing entry point already have that logic, it may
have to be replicated there ...
> > Is it safe for libvirt to be able to run arbitrary programs?
I would say no.
> I'm not such a fan of libraries which spawn arbitrary programs on
> my behalf. But as long as it didn't actually spawn stuff unless ther
> was some explicit request based on the URI it should be ok - that
> way we can document that specific URI formats will result in the
> spawning of /usr/bin/ssh.
I would just hardcode the supported protocols and the associated
programs, but not having seen the code yet I may be off track...
> > + if (strncasecmp (name, "remote:", 7) != 0)
> > + return -1; /* Not for me. */
> > +
> > + /* Split the name at whitespace and parse it. */
> > + const char *p;
> > + for (p = name; *p;) {
> > + // NB. All versioning is done by SunRPC so we don't need to worry
> > + // that we are connected to an incompatible daemon.
> > + break;
> > + }
>
> We can use libxml's existing routines for parsing URIs
>
> #include <libxml/uri.h>
>
> xmlURIPtr uri = xmlParseURI(connectstr)
right, it will ensure it's a proper URI (c.f. RFC 2396 (I need to update
to latest IETF spec but should not affect us)), the fields are then accessible
from the record returned, which should be freed by xmlFreeURI(uri) when done.
thanks !
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/