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