From nobody Mon Feb 9 01:21:49 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) client-ip=170.10.129.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 170.10.129.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=1662724743; cv=none; d=zohomail.com; s=zohoarc; b=WNaaWOirg4tp0pXmEWZfxWlVj6O2bMCk3UM/grmpCuhrCoHa/Vtk5GxdUrLal1EgpR/Bqb1Y/U1YHnFCuddo4aNh7YaomHKVvjIU0LsB3pe+wGuevpWxqhJl7X8WvsJQh20oTkt7PWohAE7mN0iDmSDI79AZxyFprZaP91eKe28= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1662724743; 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=MR3i9OOFOK1z/VhiqTNXnFbOl0lP4VzrVHggeyEo4PQ=; b=PDqJKZchOEZUIT8b4WT1p0EW12/j2ido+QQJS7trCRvlUMnf5kdbNfsE3D1EfLdLE+B4dpw8gPt14OWo71IHjO8txyyhXnu3f8/Lh4V8TE8E8Dj32psljH8P35hOHrHwrh14G1/sqKWVPX56JPhGq5alPZqP2g8j1tBjMsIIecc= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.129.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 [170.10.129.124]) by mx.zohomail.com with SMTPS id 1662724743175348.2025419175832; Fri, 9 Sep 2022 04:59:03 -0700 (PDT) Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-176-_urjLh8ENwqOIyIbUe_44Q-1; Fri, 09 Sep 2022 07:58:37 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8BAFD85A58E; Fri, 9 Sep 2022 11:58:32 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (unknown [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7751A4C819; Fri, 9 Sep 2022 11:58:32 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 5A6491946A44; Fri, 9 Sep 2022 11:58:32 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 5BCE01946A48 for ; Fri, 9 Sep 2022 11:58:29 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 5006F2166B2A; Fri, 9 Sep 2022 11:58:29 +0000 (UTC) Received: from speedmetal.lan (unknown [10.40.208.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id C0B472166B26 for ; Fri, 9 Sep 2022 11:58:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1662724742; 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=MR3i9OOFOK1z/VhiqTNXnFbOl0lP4VzrVHggeyEo4PQ=; b=WUGeNHGCbJktMzGrodAZZEBPCtTh7liVV3oOhZqILinW8lR7gRWDNfpqlSCSdalR7g/dNg 66Urtak4/9DMzjVqwmhFS7alnBO0xUVZnNvJ4OFtaL1X6gHyT1SBPbh4W/ZalTtXHFhSh+ xF5n6v1W5Xji0m05wK7xsdbhq4VkyCs= X-MC-Unique: _urjLh8ENwqOIyIbUe_44Q-1 X-Original-To: libvir-list@listman.corp.redhat.com From: Peter Krempa To: libvir-list@redhat.com Subject: [PATCH v2 9/9] remote: Don't attempt remote connection from libvirtd Date: Fri, 9 Sep 2022 13:58:19 +0200 Message-Id: <912e09484a9e27fb5c4f58af8fbefd6631bf2557.1662723003.git.pkrempa@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libvir-list-bounces@redhat.com Sender: "libvir-list" X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1662724744053100001 Content-Type: text/plain; charset="utf-8" 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. Refuse opening a connection for local URIS even when the requested driver is not registered in case when we are inside 'libvirtd' as libvirtd doesn't have anything to delegate to. $ 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/3= 70 Signed-off-by: Peter Krempa --- src/remote/remote_driver.c | 30 +++++++++++++++++++----------- 1 file changed, 19 insertions(+), 11 deletions(-) diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index 33cc6b1fce..a4efe101a3 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -73,6 +73,7 @@ VIR_LOG_INIT("remote.remote_driver"); #endif static bool inside_daemon; +static bool monolithic_daemon; struct private_data { virMutex lock; @@ -168,7 +169,7 @@ static void make_nonnull_domain_snapshot(remote_nonnull= _domain_snapshot *snapsho static int remoteStateInitialize(bool privileged G_GNUC_UNUSED, const char *root G_GNUC_UNUSED, - bool monolithic G_GNUC_UNUSED, + bool monolithic, virStateInhibitCallback callback G_GNUC_UNUSED, void *opaque G_GNUC_UNUSED) { @@ -176,6 +177,7 @@ remoteStateInitialize(bool privileged G_GNUC_UNUSED, * re-entering ourselves */ inside_daemon =3D true; + monolithic_daemon =3D monolithic; return VIR_DRV_STATE_INIT_COMPLETE; } @@ -1244,16 +1246,22 @@ remoteConnectOpen(virConnectPtr conn, if (!conn->uri) return VIR_DRV_OPEN_DECLINED; - /* If there's a driver registered we must defer to that. - * If there isn't a driver, we must connect in "direct" - * mode - see doRemoteOpen. - * One exception is if we are trying to connect to an - * unknown socket path as that might be proxied to remote - * host */ - if (!conn->uri->server && - virHasDriverForURIScheme(driver) && - !virURICheckUnixSocket(conn->uri)) - return VIR_DRV_OPEN_DECLINED; + /* Handle deferring to local drivers if we are dealing with a defa= ult + * local URI. (Unknown local socket paths may be proxied to a remo= te + * host so they are treated as remote too). + * + * Deferring to a local driver is needed if: + * - the driver is registered in the current daemon + * - if we are running monolithic libvirtd, in which case we consi= der + * even un-registered drivers as local + */ + if (!conn->uri->server && !virURICheckUnixSocket(conn->uri)) { + if (virHasDriverForURIScheme(driver)) + return VIR_DRV_OPEN_DECLINED; + + if (monolithic_daemon) + return VIR_DRV_OPEN_DECLINED; + } } if (!(priv =3D remoteAllocPrivateData())) --=20 2.37.1