From nobody Mon Feb 9 17:56:02 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 216.205.24.124 as permitted sender) client-ip=216.205.24.124; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 216.205.24.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1623332776; cv=none; d=zohomail.com; s=zohoarc; b=DGAf/9Cl0z0n6wJxuRsGr1dP3KehLyhrp4CkD8bckJegHTaFDnYCPmWxQt1LQU81AHNzyLdJqHHlCAuz/wQhcnW5G6StkBT6cIVMJKHQYS0qsukkMyHTYnlIF7a1GK5Elk3WSr2LppjZRGYeKMY1RHCnNpAmrV1O5V4QpmsLKzQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1623332776; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=g1CDMn8kqQyYMmTuApg496+3re2So09sM663EnfKE+0=; b=KrVYHYA0WS8GWMt3Q03fsoLelWghB6hSHcSSemg0lO7/9tJ88y1ywNCKi3+JTwR1Eo+aJDXOzBzLkcRZMoCDw1Ad4oNQNlIHSK3InhJdjsp0n8VGIfJND4MVhsFJhUEuWN36VTdZ4adBQiP3x2BF3GVXUQnlPqgXaS5ILBzVWi4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 216.205.24.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.zohomail.com with SMTPS id 1623332776428869.6334195301796; Thu, 10 Jun 2021 06:46:16 -0700 (PDT) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-229-hgqOHn_wPdy3oae8FrVFfw-1; Thu, 10 Jun 2021 09:46:12 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0A47A100C669; Thu, 10 Jun 2021 13:46:07 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D9B925C238; Thu, 10 Jun 2021 13:46:06 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 9E38C1809CBB; Thu, 10 Jun 2021 13:46:06 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 15ADhUXB004226 for ; Thu, 10 Jun 2021 09:43:30 -0400 Received: by smtp.corp.redhat.com (Postfix) id 15CE718AD4; Thu, 10 Jun 2021 13:43:30 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-115-203.ams2.redhat.com [10.36.115.203]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3F6D263B8C; Thu, 10 Jun 2021 13:43:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1623332775; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=g1CDMn8kqQyYMmTuApg496+3re2So09sM663EnfKE+0=; b=CUfbxzajB0gqqjRx3EC5o71CD4bF7Pt6paq5bgiKBabpqnT4y/VYlARWntJzGP4EBhggXw CEsOlxgwHxa5+DvvGW9DSVpP/mzrDX3G3KRWQEoQU8AYqMRFSwYylJd+vf4PwfhKYzhZNV QGA9mc6E4XZM91c5Dt4+Tjx13gYW91g= X-MC-Unique: hgqOHn_wPdy3oae8FrVFfw-1 From: =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= To: libvir-list@redhat.com Subject: [libvirt PATCH 2/4] remote: add support for probing drivers with modular daemons Date: Thu, 10 Jun 2021 14:43:15 +0100 Message-Id: <20210610134317.368010-3-berrange@redhat.com> In-Reply-To: <20210610134317.368010-1-berrange@redhat.com> References: <20210610134317.368010-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-loop: libvir-list@redhat.com X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=libvir-list-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) With the traditional libvirtd, the virConnectOpen call will probe active drivers server side to find which one to use when the URI is NULL/empty. With the modular daemons though, the remote client does not know which daemon to connect in the first place, so we can't rely on virConnectOpen probing. Currently the virtproxyd daemon has code to probe for a possible driver by looking at which sockets are listening or which binaries are installed. The remote client can thus connect to virtproxyd which in turn can connect to a real hypervisor driver. The virtproxyd probing code though isn't something that needs to live in virtproxyd. By moving it into the remote client we can get probing client side in all scenarios and avoid the extra trip via virtproxyd in the common case. Signed-off-by: Daniel P. Berrang=C3=A9 --- meson.build | 6 +++-- src/remote/remote_sockets.c | 53 +++++++++++++++++++++++++++++++------ 2 files changed, 49 insertions(+), 10 deletions(-) diff --git a/meson.build b/meson.build index 40e99fec0c..91d51492a4 100644 --- a/meson.build +++ b/meson.build @@ -1415,8 +1415,10 @@ if not get_option('driver_remote').disabled() endif endif =20 -remote_default_mode =3D get_option('remote_default_mode').to_upper() -conf.set('REMOTE_DRIVER_MODE_DEFAULT', 'REMOTE_DRIVER_MODE_@0@'.format(rem= ote_default_mode)) +remote_default_mode =3D get_option('remote_default_mode') +if remote_default_mode =3D=3D 'direct' + conf.set('REMOTE_DRIVER_AUTOSTART_DIRECT', '1') +endif =20 if not get_option('driver_libvirtd').disabled() use_libvirtd =3D true diff --git a/src/remote/remote_sockets.c b/src/remote/remote_sockets.c index dd28c9dd5e..506e267201 100644 --- a/src/remote/remote_sockets.c +++ b/src/remote/remote_sockets.c @@ -299,6 +299,9 @@ remoteGetUNIXSocket(remoteDriverTransport transport, g_autofree char *daemon_name =3D NULL; g_autofree char *direct_sock_name =3D NULL; g_autofree char *legacy_sock_name =3D NULL; +#ifdef REMOTE_DRIVER_AUTOSTART_DIRECT + g_autofree char *guessdriver =3D NULL; +#endif #ifndef WIN32 const char *env_name =3D remoteGetDaemonPathEnv(); #else @@ -310,12 +313,35 @@ remoteGetUNIXSocket(remoteDriverTransport transport, remoteDriverModeTypeToString(mode), driver, flags); =20 +#ifdef REMOTE_DRIVER_AUTOSTART_DIRECT + if (!driver && mode !=3D REMOTE_DRIVER_MODE_LEGACY) { + VIR_DEBUG("Client side modular daemon probe"); + /* + * If we don't have a driver (because URI is empty) + * in the direct case, we don't know which daemon + * to connect to. This logic attempts to be a rough + * equivalent of auto-probing from virConnectOpen + * in the libvirtd days. + */ + if (geteuid() !=3D 0) { + if (remoteProbeSessionDriverFromSocket(false, &guessdriver) < = 0) + return NULL; + + if (guessdriver =3D=3D NULL && + remoteProbeSessionDriverFromBinary(&guessdriver) < 0) + return NULL; + } else { + if (remoteProbeSystemDriverFromSocket(flags & REMOTE_DRIVER_OP= EN_RO, + &guessdriver) < 0) + return NULL; + } + driver =3D guessdriver; + } +#endif + if (driver) { direct_daemon =3D g_strdup_printf("virt%sd", driver); direct_sock_name =3D remoteGetUNIXSocketHelper(transport, direct_d= aemon, flags); - } else { - direct_daemon =3D g_strdup("virtproxyd"); - direct_sock_name =3D remoteGetUNIXSocketHelper(transport, "libvirt= ", flags); } =20 legacy_daemon =3D g_strdup("libvirtd"); @@ -323,18 +349,29 @@ remoteGetUNIXSocket(remoteDriverTransport transport, =20 if (mode =3D=3D REMOTE_DRIVER_MODE_AUTO) { if (transport =3D=3D REMOTE_DRIVER_TRANSPORT_UNIX) { + /* + * When locally accessing libvirtd, we pick legacy or + * modular daemons depending on which sockets we see + * existing. + */ if (direct_sock_name && virFileExists(direct_sock_name)) { mode =3D REMOTE_DRIVER_MODE_DIRECT; } else if (virFileExists(legacy_sock_name)) { mode =3D REMOTE_DRIVER_MODE_LEGACY; } else { - /* - * This constant comes from the configure script and - * maps to either the direct or legacy mode constant - */ - mode =3D REMOTE_DRIVER_MODE_DEFAULT; +#ifdef REMOTE_DRIVER_AUTOSTART_DIRECT + mode =3D REMOTE_DRIVER_MODE_DIRECT; +#else + mode =3D REMOTE_DRIVER_MODE_LEGACY; +#endif } } else { + /* + * When remotely accessing libvirtd, we always default to a le= gacy socket + * path, as there's no way for us to probe what's configured. = This does + * not matter, since 'virt-ssh-helper' will be used if it is a= vailable + * and thus probe from context of the remote host + */ mode =3D REMOTE_DRIVER_MODE_LEGACY; } } --=20 2.31.1