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