[Libvir] RFC: replace "no support for hypervisor" error
The "no support for hypervisor" error is both very common and pretty annoying because it gives you nowhere to go to find out what you did wrong. $ virsh -c xen://localhost/ libvir: Xen Daemon error : no support for hypervisor virsh: error: failed to connect to the hypervisor (The actual problem is that my URI is wrong, which is a separate bug in the Xen driver. But the error message gives me no particular indication of what is wrong or how to correct the situation). I think there are several possible solutions to this - discuss, or suggest your own. (1) Document the URI formats fully. -- This is a feature which has been requested a few times and I will do it anyway if Daniel Veillard will do the magic to set up a "http://libvirt.org/uri.html" page. (2) Add a method to query available drivers and URI syntax. -- Something along the lines of char *virQueryDrivers (void); Note that it doesn't need an open connection. -- The remote case would have to be handled specially because you want to find out what's available locally and what's available remotely, and in the remote case you do need some sort of a connection. (3) Split VIR_ERR_NO_SUPPORT into two categories. Currently this category mixes up cases where we fail to open a connection, and cases where there is no driver support for a particular operation (even with an open connection). In the first case, go through all the places which return this error and add proper diagnostic information to the error messages. -- Again, I am prepared to do this if people think it's a good idea. (4) Add diagnostics to higher layers such as virsh and virt-manager. -- I would be less happy with this because it ends up repeating code, and the diagnostics could get out of date w.r.t. what libvirt can do. 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
On Tue, Jun 19, 2007 at 02:16:23PM +0100, Richard W.M. Jones wrote:
The "no support for hypervisor" error is both very common and pretty annoying because it gives you nowhere to go to find out what you did wrong.
agreed, this need to be fixed !
$ virsh -c xen://localhost/ libvir: Xen Daemon error : no support for hypervisor virsh: error: failed to connect to the hypervisor
(The actual problem is that my URI is wrong, which is a separate bug in the Xen driver. But the error message gives me no particular indication of what is wrong or how to correct the situation).
I think there are several possible solutions to this - discuss, or suggest your own.
(1) Document the URI formats fully.
definitely
-- This is a feature which has been requested a few times and I will do it anyway if Daniel Veillard will do the magic to set up a "http://libvirt.org/uri.html" page.
Okay I will do that within an hour :-)
(2) Add a method to query available drivers and URI syntax.
-- Something along the lines of char *virQueryDrivers (void); Note that it doesn't need an open connection.
-- The remote case would have to be handled specially because you want to find out what's available locally and what's available remotely, and in the remote case you do need some sort of a connection.
Hum, that sounds way more radical, including extending the drivers, that may be a bit more work than necessary
(3) Split VIR_ERR_NO_SUPPORT into two categories. Currently this category mixes up cases where we fail to open a connection, and cases where there is no driver support for a particular operation (even with an open connection). In the first case, go through all the places which return this error and add proper diagnostic information to the error messages.
-- Again, I am prepared to do this if people think it's a good idea.
It would be logical to separate the two, I think we already at the low level do the difference but it doesn't show up at the error level.
(4) Add diagnostics to higher layers such as virsh and virt-manager.
-- I would be less happy with this because it ends up repeating code, and the diagnostics could get out of date w.r.t. what libvirt can do.
(2) would be more precise, I agree, but I think (1) would already take care of most reports especially: - if it was included in the man page - if our default behaviour was a bit less pathological virsh: error: failed to connect to the hypervisor paphio:~/libvirt -> virsh help libvir: error : operation failed: xenProxyOpen virsh: error: failed to connect to the hypervisor paphio:~/libvirt -> there is certainly things to be done at the virsh level too to improve user experience which don't require playing at the API level. Also to note, relying just on the driver may not work, suppose the user is not running a Xen kernel (like I pasted before) falling back to a Proxy mode won't work, but that won't tell him the real cause of the problem. Daniel Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel Veillard wrote:
On Tue, Jun 19, 2007 at 02:16:23PM +0100, Richard W.M. Jones wrote:
(1) Document the URI formats fully.
definitely
-- This is a feature which has been requested a few times and I will do it anyway if Daniel Veillard will do the magic to set up a "http://libvirt.org/uri.html" page.
Okay I will do that within an hour :-)
Thanks.
- if our default behaviour was a bit less pathological
virsh: error: failed to connect to the hypervisor paphio:~/libvirt -> virsh help libvir: error : operation failed: xenProxyOpen virsh: error: failed to connect to the hypervisor paphio:~/libvirt ->
there is certainly things to be done at the virsh level too to improve user experience which don't require playing at the API level. Also to note, relying just on the driver may not work, suppose the user is not running a Xen kernel (like I pasted before) falling back to a Proxy mode won't work, but that won't tell him the real cause of the problem.
Sure, I've seen that one too, so I'll address that one in a patch. 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
On Tue, Jun 19, 2007 at 09:32:31AM -0400, Daniel Veillard wrote:
On Tue, Jun 19, 2007 at 02:16:23PM +0100, Richard W.M. Jones wrote:
The "no support for hypervisor" error is both very common and pretty annoying because it gives you nowhere to go to find out what you did wrong.
(4) Add diagnostics to higher layers such as virsh and virt-manager.
-- I would be less happy with this because it ends up repeating code, and the diagnostics could get out of date w.r.t. what libvirt can do.
For virt-manager the user should never have to entry a URI, unless they know what they're doing and using the command line args. We'll have a dialog which prompts them for neccessary info to connect to a remote hypervisor. So if we assume libvirt returns sensible error messages when a connection fails, we should be able to deal with that nicely already.
(2) would be more precise, I agree, but I think (1) would already take care of most reports especially: - if it was included in the man page - if our default behaviour was a bit less pathological
virsh: error: failed to connect to the hypervisor paphio:~/libvirt -> virsh help libvir: error : operation failed: xenProxyOpen virsh: error: failed to connect to the hypervisor paphio:~/libvirt ->
Yes, we need to special case the 'help' command so that it doesn't open the hypervisor connection. 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 -=|
Daniel Veillard wrote:
On Tue, Jun 19, 2007 at 02:16:23PM +0100, Richard W.M. Jones wrote:
(1) Document the URI formats fully.
definitely
-- This is a feature which has been requested a few times and I will do it anyway if Daniel Veillard will do the magic to set up a "http://libvirt.org/uri.html" page.
Okay I will do that within an hour :-)
The documentation for this should appear here shortly: http://libvirt.org/uri.html (If you only see the holding page, then please come back in up to half an hour). 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 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
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. 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 -=|
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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
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
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 -=|
Daniel Veillard wrote:
- if our default behaviour was a bit less pathological
virsh: error: failed to connect to the hypervisor paphio:~/libvirt -> virsh help libvir: error : operation failed: xenProxyOpen virsh: error: failed to connect to the hypervisor
This patch fixes the pathological failure of 'virsh help command'. (1) We allow ctl->conn to be NULL, meaning "no connection". (2) All cmd* functions check vshConnectionUsability where required (I checked this) except the ones which don't need to such as cmdHelp. (3) vshInit has changed so that not being able to connect to a hypervisor is a non-fatal condition. Thus after vshInit, ctl->conn may be NULL. (4) I reordered the list of commands alphabetically, except that "help" is listed first. $ virsh help save libvir: error : operation failed: xenProxyOpen error: failed to connect to the hypervisor NAME save - save a domain state to a file SYNOPSIS save <domain> <file> DESCRIPTION Save a running domain. OPTIONS <domain> domain name, id or uuid <file> where to save the data 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
On Wed, Jun 20, 2007 at 12:25:17PM +0100, Richard W.M. Jones wrote:
Daniel Veillard wrote:
- if our default behaviour was a bit less pathological
virsh: error: failed to connect to the hypervisor paphio:~/libvirt -> virsh help libvir: error : operation failed: xenProxyOpen virsh: error: failed to connect to the hypervisor
This patch fixes the pathological failure of 'virsh help command'.
(1) We allow ctl->conn to be NULL, meaning "no connection".
(2) All cmd* functions check vshConnectionUsability where required (I checked this) except the ones which don't need to such as cmdHelp.
(3) vshInit has changed so that not being able to connect to a hypervisor is a non-fatal condition. Thus after vshInit, ctl->conn may be NULL.
(4) I reordered the list of commands alphabetically, except that "help" is listed first.
$ virsh help save libvir: error : operation failed: xenProxyOpen error: failed to connect to the hypervisor NAME save - save a domain state to a file
SYNOPSIS save <domain> <file>
DESCRIPTION Save a running domain.
OPTIONS <domain> domain name, id or uuid <file> where to save the data
Hum, I wonder if help should not be special cased. I think it's okay to not return immediately in the case where no command is given and it's then possible to issue a new connect command from the shell. So the patch looks fine to me, but we may refine this a bit too. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel Veillard wrote:
On Tue, Jun 19, 2007 at 02:16:23PM +0100, Richard W.M. Jones wrote:
(3) Split VIR_ERR_NO_SUPPORT into two categories. Currently this category mixes up cases where we fail to open a connection, and cases where there is no driver support for a particular operation (even with an open connection). In the first case, go through all the places which return this error and add proper diagnostic information to the error messages.
-- Again, I am prepared to do this if people think it's a good idea.
It would be logical to separate the two, I think we already at the low level do the difference but it doesn't show up at the error level.
The attached patch: (1) Makes VIR_ERR_NO_SUPPORT mean that a function is not supported by the hypervisor. It changes the message to be more specific and coincidentally corrects a bug which was causing the optional info field to be dropped. (2) Makes VIR_ERR_NO_CONNECT mean that we could not connect to the hypervisor. (3) Deprecates VIR_ERR_CALL_FAILED, because the meaning and use of this overlapped with VIR_ERR_NO_SUPPORT, and some calls failed with one and other calls failed with the other. Accordingly it changes all VIR_ERR_CALL_FAILED errors into VIR_ERR_NO_SUPPORT errors. (4) Removes all error messages which occur before VIR_DRV_OPEN_DECLINED. If a driver is declines a URI, then that is normal behaviour and no reason to print an error. A later driver in the chain may accept the URI, and if none of the drivers can accept it then libvirt.c:do_open contains code to generate an error. (5) If xen_unified.c was passed a naked string like "foo" as a URI then it would try to use it as a relative file reference. This was wrong and obscures a whole class of error message, so I've changed it so that xen_unified.c will only try to accept an absolute pathname (eg. ///var/lib/xen/xend-socket). 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
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Richard W.M. Jones