From nobody Wed Apr 1 22:01:52 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) client-ip=8.43.85.245; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass(p=reject dis=none) header.from=lists.libvirt.org ARC-Seal: i=1; a=rsa-sha256; t=1775050346; cv=none; d=zohomail.com; s=zohoarc; b=g4kJ30UDdDCTruOEJS/ejW0N2yNyL1EnRtxatGqaDYEF3JbUapk6G5tttaJsr9kc6zW6u90ZCw5KNl4wbTDUjJYxkk4W7Ytgysmx6imIcdtBFwUkp46iLakDYItGkWKtAoAT8TDkO+E38lxDN+qQvhLU1ZqS1kB3ZTSd3obMPV4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1775050346; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Owner:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Reply-To:Reply-To:References:Subject:Subject:To:To:Message-Id:Cc; bh=UhV50d7PVAwUYr6RwTrxnEQvqsR9/1uqYaEGKkcaLGE=; b=IniIY18wjew0Bt0CjYdtfiHwvEhciHsrI2vttiCCY0vcCB995oXw/9BQYRW0qRuiIlm+9kJkNFyIZUXgeETWJt3mSxIV+Xsn4BZO2oEvQaRpTW2U/s1ZHUVkfqOJgjAWKAPV+MYXGSYpPV9sM/HrIVwBP+BRyLgnbl/XLM0a8NY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [8.43.85.245]) by mx.zohomail.com with SMTPS id 1775050346056566.4609697630715; Wed, 1 Apr 2026 06:32:26 -0700 (PDT) Received: by lists.libvirt.org (Postfix, from userid 993) id 390D63F280; Wed, 1 Apr 2026 09:32:25 -0400 (EDT) Received: from [172.19.199.12] (lists.libvirt.org [8.43.85.245]) by lists.libvirt.org (Postfix) with ESMTP id 6F98B41ADB; Wed, 1 Apr 2026 09:28:54 -0400 (EDT) Received: by lists.libvirt.org (Postfix, from userid 993) id F218B3F861; Wed, 1 Apr 2026 09:28:48 -0400 (EDT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (3072 bits) server-digest SHA256) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id F14C341913 for ; Wed, 1 Apr 2026 09:27:29 -0400 (EDT) Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-464-5AxZhlAjOu68Yn5u-nrivA-1; Wed, 01 Apr 2026 09:27:27 -0400 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id CBC9D18002D1 for ; Wed, 1 Apr 2026 13:27:26 +0000 (UTC) Received: from speedmetal.lan (unknown [10.44.22.4]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 233FD1954102 for ; Wed, 1 Apr 2026 13:27:25 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HELO_MISC_IP,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1775050049; h=from:from: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; bh=UhV50d7PVAwUYr6RwTrxnEQvqsR9/1uqYaEGKkcaLGE=; b=bNcrlqJlMlcgZ1js2+SIAwKJEtvG0Z7flELVyrSX2rOVhg1o5RsUD6ZxuPiJbfAIcEGcgA 91sxT6N/y1LZrFXrXGOYbJOQQlyoY+AUp4sysrtromS4K0ekyHOrv3k2elPGfPLjTJBZDx qP3JQYAtX4TtCa6u+4Tj0Tfhe+B/EBo= X-MC-Unique: 5AxZhlAjOu68Yn5u-nrivA-1 X-Mimecast-MFC-AGG-ID: 5AxZhlAjOu68Yn5u-nrivA_1775050046 To: devel@lists.libvirt.org Subject: [PATCH 6/6] virsh: blockresize: Use VIR_DOMAIN_BLOCK_RESIZE_EXTEND when available and introduce --allow-shrink Date: Wed, 1 Apr 2026 15:27:17 +0200 Message-ID: In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: XomrhUc_uH_iO2QO-I-y3kY1Auxo1k8b6LIbGmFddpE_1775050046 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Message-ID-Hash: FX2H322IOOBFQOB47YNGAKDWLNGUGBK3 X-Message-ID-Hash: FX2H322IOOBFQOB47YNGAKDWLNGUGBK3 X-MailFrom: pkrempa@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-devel.lists.libvirt.org-0; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: Peter Krempa via Devel Reply-To: Peter Krempa X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZM-MESSAGEID: 1775050347123158500 Content-Type: text/plain; charset="utf-8" From: Peter Krempa Use the new VIR_DOMAIN_BLOCK_RESIZE_PROBE_FLAGS flag to probe for VIR_DOMAIN_BLOCK_RESIZE_EXTEND and use it if available. This will give users the same protection as with --extend in the default case. IMPORTANT: This patch changes behaviour for users who want to shrink their VM's block device knowingly. Such users, when using a newer daemon will be required to pass --allow-shrink now. I've contemplated either renaming the whole command to preserve functionality for the existing one and deprecating 'virsh blockresize' or adding just the '--extend', but unfortunately neither of those in the end looked appealing to me. As shrinking filesystems is much more invloved and much less common the benefit of preventing accidental data loss should outweigh the breakage from the change. To aleviate issues with scripts virsh now also provides the '--probe-arguments' option to allow safe probe if virsh supports this new argument. Closes: https://gitlab.com/libvirt/libvirt/-/work_items/789 Signed-off-by: Peter Krempa --- docs/manpages/virsh.rst | 11 ++++++++++- tools/virsh-domain.c | 16 ++++++++++++++++ 2 files changed, 26 insertions(+), 1 deletion(-) diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst index 9ede859aaf..5138591595 100644 --- a/docs/manpages/virsh.rst +++ b/docs/manpages/virsh.rst @@ -1657,7 +1657,7 @@ blockresize :: - blockresize domain path ([size] | [--capacity]) [--extend] + blockresize domain path ([size] | [--capacity]) [--extend] [--allow-shr= ink] Resize a block device of domain while the domain is running, *path* specifies the absolute path of the block device; it corresponds @@ -1670,6 +1670,15 @@ smaller than the old size, thus prevents (accidental= ) shrinking of the block device which may lead to data loss. Users are encouraged to always use this flag unless communicating with an older hypervisor. +As of libvirt 12.3.0 the 'virsh blockresize' command now probes whether the +hypervisor supports enforcing that the device is not shrunk accidentally a= nd +if it is supported this feature will be used as a precaution from accident= al +data loss even at the cost of change of behaviour. With older hypervisors +which do not support the feature the protection will not be avaliable. +Users wanting to shrink the block device must use the *--allow-shrink* +flag. In scripts it's possible to use the *--probe-arguments* flag to dete= rmine +if the flag is supported. + For image formats without metadata (raw) stored inside fixed-size storage = (e.g. block devices) the --capacity flag can be used to resize the device to the full size of the backing device. diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 08a1ce3953..95ce4dc845 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -3343,6 +3343,10 @@ static const vshCmdOptDef opts_blockresize[] =3D { .type =3D VSH_OT_BOOL, .help =3D N_("ensure that the new size is larger than actual capacity= (prevent shrink)") }, + {.name =3D "allow-shrink", + .type =3D VSH_OT_BOOL, + .help =3D N_("disable size checks so that device can be shrunk") + }, {.name =3D NULL} }; @@ -3378,6 +3382,18 @@ cmdBlockresize(vshControl *ctl, const vshCmd *cmd) if (!(dom =3D virshCommandOptDomain(ctl, cmd, NULL))) return false; + /* probe for support of VIR_DOMAIN_BLOCK_RESIZE_EXTEND and use it if i= t's + * supported to prevent mishaps even at the cost of usability change */ + if (!vshCommandOptBool(cmd, "allow-shrink")) { + if (virDomainBlockResize(dom, "", 0, + VIR_DOMAIN_BLOCK_RESIZE_EXTEND | + VIR_DOMAIN_BLOCK_RESIZE_PROBE_FLAGS) =3D= =3D 0) { + flags |=3D VIR_DOMAIN_BLOCK_RESIZE_EXTEND; + } else { + vshResetLibvirtError(); + } + } + if (virDomainBlockResize(dom, path, size, flags) < 0) { vshError(ctl, _("Failed to resize block device '%1$s'"), path); return false; --=20 2.53.0