When a hypervisor driver is not compiled in and a user enables the monolithic libvirtd, they get the following misleading error: $ virsh -c qemu:///system error: failed to connect to the hypervisor error: Failed to connect socket to '/var/run/libvirt/virtqemud-sock': No such file or directory The issue is that the daemon side of the remote driver can't find the appropriate driver, but the remote driver always accepts everything and thus attempts to delegate further, which in case of libvirtd makes no sense. Use the new flag VIR_CONNECT_NO_REMOTE and pass it from libvirtd to the opening function to avoid delegation in this specific case. After this patch the above attempt produces: $ virsh -c qemu:///system error: failed to connect to the hypervisor error: no connection driver available for qemu:///system Discovered when investigating https://gitlab.com/libvirt/libvirt/-/issues/370 Signed-off-by: Peter Krempa <pkrempa@xxxxxxxxxx> --- src/remote/remote_daemon_dispatch.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/remote/remote_daemon_dispatch.c b/src/remote/remote_daemon_dispatch.c index 061e0f7811..d7c473d2a1 100644 --- a/src/remote/remote_daemon_dispatch.c +++ b/src/remote/remote_daemon_dispatch.c @@ -1798,6 +1798,14 @@ remoteOpenConn(const char *uri, if (*conn) return 0; +#ifdef LIBVIRTD + /* When libvirtd is in use we need to avoid any further delegation of the + * connection, which can be attempted in cases when the appropriate + * connection driver was not compiled in. In such case a wrong error message + * would be reported. */ + connectFlags |= VIR_CONNECT_NO_REMOTE; +#endif /* LIBVIRTD */ + if (!uri) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("connection not open")); return -1; -- 2.37.1
