[Libvir] URI documentation and xen:/// patch

[Daniel P. Berrange]

On Wed, Jun 20, 2007 at 11:06:41AM +0100, Richard W.M. Jones wrote:
> 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.

Ah yes, I had noticed this, but promptly forgot again. Fortunately it
worked anyway :-)

> 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 ..?

Yes, that is correct. The remote driver will also accept qemu:///session
and qemu:///system URIs once my patchset is completed.

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  -=|