search for: skluly

...fails, we suppress the exception (we log it in verbose mode only, even). That's not proved helpful: it almost certainly leads to later errors, but those errors are less clear than the original (suppressed) exception. Namely, the user sees something like > Failed to connect to '/tmp/v2v.sKlulY/in0': Permission denied rather than > Failed to connect socket to '/var/run/libvirt/virtqemud-sock-ro': > Connection refused So just allow the exception to propagate outwards. And then, now that "chown_for_libvirt_rhbz_1045069" will be able to fail, hoist the call to...

...on (we log it in verbose mode only, even). > > That's not proved helpful: it almost certainly leads to later errors, but > those errors are less clear than the original (suppressed) exception. > Namely, the user sees something like > > > Failed to connect to '/tmp/v2v.sKlulY/in0': Permission denied > > rather than > > > Failed to connect socket to '/var/run/libvirt/virtqemud-sock-ro': > > Connection refused > > So just allow the exception to propagate outwards. > > And then, now that "chown_for_libvirt_rhbz_1045069&...

...ose mode only, even). >> >> That's not proved helpful: it almost certainly leads to later errors, but >> those errors are less clear than the original (suppressed) exception. >> Namely, the user sees something like >> >>> Failed to connect to '/tmp/v2v.sKlulY/in0': Permission denied >> >> rather than >> >>> Failed to connect socket to '/var/run/libvirt/virtqemud-sock-ro': >>> Connection refused >> >> So just allow the exception to propagate outwards. >> >> And then, now that "c...

...;> > >> That's not proved helpful: it almost certainly leads to later errors, but > >> those errors are less clear than the original (suppressed) exception. > >> Namely, the user sees something like > >> > >>> Failed to connect to '/tmp/v2v.sKlulY/in0': Permission denied > >> > >> rather than > >> > >>> Failed to connect socket to '/var/run/libvirt/virtqemud-sock-ro': > >>> Connection refused > >> > >> So just allow the exception to propagate outwards. > >...

...gt;> That's not proved helpful: it almost certainly leads to later errors, but >>>> those errors are less clear than the original (suppressed) exception. >>>> Namely, the user sees something like >>>> >>>>> Failed to connect to '/tmp/v2v.sKlulY/in0': Permission denied >>>> >>>> rather than >>>> >>>>> Failed to connect socket to '/var/run/libvirt/virtqemud-sock-ro': >>>>> Connection refused >>>> >>>> So just allow the exception to propagat...

...ket pathnames and two possible errno values -- 4 variations.) (2) If the logic from commit 4e7f20684373 fails to make a read-only connection to libvirtd, we suppress that exception (only log it to the verbose log), and the user only sees the consequent failure Failed to connect to '/tmp/v2v.sKlulY/in0': Permission denied There could be further failure modes. If we want to make this consistent (i.e., quote just one error message in the docs), then at least we should undo the exception suppression from commit 4e7f20684373 -- let that exception reach the outermost handler. BTW, what'...

...of the error from the read-only connection was basically a coincidence. We want to get the qemu username from libvirt, we make a read-only connection, and because we're only doing a best effort attempt to chown the socket we ignore the error. But ... > Failed to connect to '/tmp/v2v.sKlulY/in0': Permission denied ... this suggests that maybe we really do want to chown the socket and we shouldn't be making it best-effort at all, but should fail if it's not possible. What do you think about that as a change? (This yet again comes back to the ancient libvirt bug https://b...

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2182024 v1 was here: <https://listman.redhat.com/archives/libguestfs/2023-June/031910.html>. Make any "chown_for_libvirt_rhbz_1045069" failure a hard one; that way the user gets to see more direct and more uniform error messages (namely that we couldn't connect to libvirt). Document those connection problems, and a simple

On Tue, Jun 27, 2023 at 07:14:36PM +0200, Laszlo Ersek wrote: > It has frequently tripped us up that on RHEL / Fedora, installing the > right set of libvirt RPMs (such as the one pulled in by > "libvirt-daemon-kvm") does not result in an immediately running libvirt > system instance. Document the need, and the simplest method, for starting > libvirt up manually. >