[Libvir] Re: RFC: replace "no support for hypervisor" error

[Daniel Veillard]

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 at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/