On Fri, Dec 01, 2023 at 01:22:14PM +0100, Martin Kletzander wrote: > On Thu, Nov 30, 2023 at 09:48:10AM +0000, Richard W.M. Jones wrote: > >On Thu, Nov 30, 2023 at 10:06:38AM +0100, Peter Krempa wrote: > >>On Thu, Nov 30, 2023 at 09:49:56 +0100, Martin Kletzander wrote: > >>> On Wed, Nov 29, 2023 at 06:33:54PM +0000, Richard W.M. Jones wrote: > >>> > > >>> > Can we have the error message include a link to this page? > >>> > https://wiki.libvirt.org/Failed_to_connect_to_the_hypervisor.html > >>> > > >>> > >>> I think we could, although I'd be a bit afraid of the precedence which, > >>> by itself is not that bad, but keeping the separate document(s) up to > >>> date could bite us in the back in a while. I won't go against the idea > >>> if others in this discussion are fine with it and we reach a consensus. > >> > >>There is one precedent case, when backing image brobing fails due to > >>mess-up in the format fields, in which case the error links to an > >>article in the kbase on proper setup of images. > >> > >>I suggest that if you want to add a link into the error, the article > >>should be kept in the kbase in the main repo instead of the wiki. > >> > >>The article should probably be also clarified to contain only this case > >>and also link perhaps to the page about how to setup daemons to run. > > > >This is a lot of extra work just to fix a bad error message. > > > >Error messages should **always** be actionable. They should, every > >single time, tell the user in simple language: What is wrong. How to > >fix it. > > > >This is an egregious example of a bad error from libvirt that I see > >happening over and over again. Let's just fix it. > > > > The clearest actionable error message for me would be: > > Cannot find a socket to connect to, please specify a connection URI. This isn't really actionable. What an actionable error message means is something that explains what the average user has to do, clearly. And by average user, don't assume they know a lot about how libvirt works. If we wanted to go down this route we'd have to explain what the sockets are and how they are started, what a "connection URI" is, how to show what connection URIs are available (or suggest some), etc. Can you actually show the list of available connection URIs? As far as I know there's no libvirt tool for doing that. At least for local sockets it should be possible, I suppose. Think about this from the point of view of the average user who really doesn't want to invest a lot of effort. > Would that be OK? It clearly tells the user what to do, and even though > it is not the user experience one might want, it is error-prone when > compared to relying on libvirt to guess the right URI. It's just luck > that people running different hypervisor daemons than virtqemud are not > using tools that use libvirt, but automatically presume QEMU connection. I agree that it may be the user meant to connect to a remote libvirt server. Is that more common than needing to start the local libvirt daemon? It probably does depend on the type of user. There will be some users who are using virt-* tools who need the local server. And another quite separate class of users who mainly use libvirt for remote connections. Probably if the libvirt install isn't capable of running local libvirt daemon (MacOS? Windows?) then we can discount the "needs to start the socket" case, and just explain what connection URIs are. > I know what I suggest is a lot of work for such a simple thing, the same > way as creating and maintaining a page which tells everyone how to start > a system service is. If someone has root access to a machine, can > install packages, but does not know how to start a system service, then > there are better places where to find up to date information than every > single project maintaining a list of distro-specific instructions. I really think we do need to do that. That's the approach we try (very imperfectly) for in libguestfs, nbdkit, libnbd, etc. > If you don't like that last suggestion above, then I'll rewrite it, > create a kbase article and link to it. No problem. I'm just trying to > find a middle ground here. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
