[PATCH 6/6] remote: Don't attempt remote connection from libvirtd

[Daniel P. Berrangé]

On Thu, Sep 08, 2022 at 05:16:00PM +0200, Peter Krempa wrote:
> 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 at redhat.com>
> ---
>  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 */

This flag shouldn't be required in the public API. THis code and
the remote driver are both in the same process, so it ought to be
possible to block this using the 'inside_daemon' flag that we
already use for similar reasons in the remote driver. This just
feels like an edge case that we missed in our use of 'inside_daemon'


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|