From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id C05F01FF0E4 for ; Tue, 11 Aug 2026 09:37:55 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id E1B7421578; Tue, 11 Aug 2026 09:37:51 +0200 (CEST) From: Jakob Klocker To: pve-devel@lists.proxmox.com Subject: [PATCH storage v3 0/2] fix #7598: qemu-img: increase timeout for image resize Date: Tue, 11 Aug 2026 09:37:38 +0200 Message-ID: <20260811073740.100398-1-j.klocker@proxmox.com> X-Mailer: git-send-email 2.47.3 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 1 AWL -0.578 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) KAM_LAZY_DOMAIN_SECURITY 1 Sending domain does not have any anti-forgery methods RDNS_NONE 1.274 Delivered to internal network by a host with no rDNS SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_NONE 0.001 SPF: sender does not publish an SPF Record Message-ID-Hash: JTIYCDDVAV5WPKAD3PXU256PPMQVNTSJ X-Message-ID-Hash: JTIYCDDVAV5WPKAD3PXU256PPMQVNTSJ X-MailFrom: jklocker@iris.proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Jakob Klocker X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Image resizing currently has a timeout of 10 seconds, which can fail on slow disks and leave the VM in a state where the disk is updated, but the VM config isn't. Since there is no deterministic way to check, with less overhead, if this is the case, increasing the timeout is the most pragmatic solution. The resize is only called in a worker context anyway, therefore this patch series mirrors the ZFS timeout: it increases the timeout in a worker context to 1 hour; as a fallback for a non-worker context the timeout stays 10 seconds. Additionally, a minor refactoring: the timeout argument was dropped at the two call sites of qemu_img_resize, since both passed the default value of 10 seconds. Changes since v2 ---------------- - restore timeout parameter since the function can be used by third-party plugins (Thanks @Fiona & @Elias) Changes since v1 ----------------- - drop the timeout parameter in qemu_img_resize - increase the timeout instead of querying the disk information (see v1 for more info. Thanks @Fabian) v1: https://lore.proxmox.com/pve-devel/20260603082557.25359-1-j.klocker@proxmox.com/t/#u Link: https://bugzilla.proxmox.com/show_bug.cgi?id=7598 pve-storage: Jakob Klocker (2): qemu-img: drop redundant timeout argument at resize call fix #7598: qemu-img: increase timeout for image resizing in worker context src/PVE/Storage/Common.pm | 6 ++++-- src/PVE/Storage/LVMPlugin.pm | 2 +- src/PVE/Storage/Plugin.pm | 2 +- 3 files changed, 6 insertions(+), 4 deletions(-) Summary over all repositories: 3 files changed, 6 insertions(+), 4 deletions(-) -- Generated by murpp 0.12.0