Re: URI documentation and xen:/// patch (was: Re: RFC: replace "no support for hypervisor" error)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 20, 2007 at 03:15:09AM +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'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.
> 
> 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.

  okay, patch looks fine to me, +1

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/


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]