Re: URI documentation and xen:/// patch

"Richard W.M. Jones" <rjones@xxxxxxxxxx> · Wed, 20 Jun 2007 11:06:41 +0100

Daniel P. Berrange wrote:
On Tue, Jun 19, 2007 at 05:15:40PM +0100, Richard W.M. Jones wrote:
The attached one-liner adds a xen:/// URI, intended as the normal method 
to connect to the Xen hypervisor on the local machine.  This is just a 
placeholder until I can get around to rewriting the Xen name parsing 
code in xen_unified.c.  This patch makes local (xen:///) and remote 
(xen://hostname/) Xen URI-style calls possible and hopefully doesn't 
prevent logical extensions to the Xen URI syntax from being added in future.

Also, I couldn't get file path URIs to work as they seem to be intended, 
but I haven't looked very closely yet:

  $ virsh -c ///var/lib/xend/xend-socket list
  libvir: error : no support for hypervisor
  virsh: error: failed to connect to the hypervisor

This is because those URIs are declined by the xen_unified.c open method
before they get anywhere near xend_internal.c

I've verified that your patch fixes this.

I'm attaching a patch which addresses this, making xen_unified.c convert
any NULL, 'xen', 'Xen' uri into xen:/// before  passing it onto the other
Xen drivers. This should make Rich's initial patch redundant. It also 
explicitly allows through any URI starting with / or http:// as back 
compat for Xen.

It turns out my patch in xend_internal.c is still needed because 
otherwise it refuses the new-style xen:/// URI and the connection to 
xend fails.  What's really needed is to fix this so different parts of 
the Xen driver aren't all trying to make uncoordinated attempts to parse 
the URI ... later.

Finally, it moves the remote driver to be the last one registered, and
ensures the Xen & test drivers explicitly decline any URI with a hostname
specified, so that they get passed onwards to the remote driver.
>
I need this because when I move the QEMU driver across then I have an
interesting scenario. Initially 'qemu:///session' has to be handled
by the remote driver, but once inside the remote daemon that very same
URI has to be handled by the QEMU driver. The QEMU driver can detect
when its run inside the daemon, so by having the remote driver last
I can handle this scenario quite easily.

Remember that a remote URI is characterised by one of _two_ things: (1) 
there is a server in the URI or (2) the URI contains a transport.  So 
for example:
  xen+ssh:///
is a remote URI.

Anyhow, your patch is still correct (I checked all the drivers and they 
now will only proceed if the scheme is one of a set of fixed strings). 
But by rearranging the list of drivers, we must remember in future.

What I don't really understand is why this is necessary -- it worked 
fine before.  The remote driver removes the transport and server name 
from the URI before passing it through to the remote end.  It looks like 
you're planning to modify the remote driver to handle qemu:/// URIs ..?

I tested all the types of URIs we claim to support against your patch, 
and they all work.  So the patch was committed.

Rich.

--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
Attachment:
smime.p7s

Description: S/MIME Cryptographic Signature