[Libvir] Re: RFC: replace "no support for hypervisor" error
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/