From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 382561FF191 for ; Mon, 16 Jun 2025 14:46:28 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 2CE2D3F9C7; Mon, 16 Jun 2025 14:46:54 +0200 (CEST) Date: Mon, 16 Jun 2025 14:46:20 +0200 (CEST) From: =?UTF-8?Q?Fabian_Gr=C3=BCnbichler?= To: Fiona Ebner , Proxmox VE development discussion Message-ID: <1780360255.3460.1750077980300@webmail.proxmox.com> In-Reply-To: <1c75794c-635f-44a1-b6c9-d036294a7fc0@proxmox.com> References: <20250612140253.106555-1-f.ebner@proxmox.com> <20250612140253.106555-16-f.ebner@proxmox.com> <1c75794c-635f-44a1-b6c9-d036294a7fc0@proxmox.com> MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.6-Rev78 X-Originating-Client: open-xchange-appsuite X-SPAM-LEVEL: Spam detection results: 0 AWL 0.045 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [plugin.pm] Subject: Re: [pve-devel] [PATCH qemu-server 15/22] vm start/commandline: activate volumes before config_to_command() X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" > Fiona Ebner hat am 16.06.2025 13:51 CEST geschrieben: > > > Am 16.06.25 um 13:31 schrieb DERUMIER, Alexandre via pve-devel: > >>> With '-blockdev', it is necessary to activate the volumes to generate > >>> the command line, because it can be necessary to check whether the > >>> volume is a block device or a regular file. > > > > I was thinking about that, but do we have storage with activate_volume > > need to be done for a regular file ? > > > > for lvm plugin for example, we could return always driver=>host_device. > > > > activate_volume is always done in specific plugin, so the plugin should > > be able to tell if it's a block or file storage > > > > only custom path passthrough in vm configuration need to be checked if > > it's a file or device, but we don't have activate_volume anyway > > Good point! It is needed for the default implementation of > qemu_blockdev_options() in Plugin.pm. We could go ahead and have all > plugins use their own implementation of qemu_blockdev_options(), that > would avoid doing any actual IO there. That sounds good to me. > > The downside is that it would break third-party plugins that would > otherwise work fine with the default implementation. But actually, it's > only those that need to do something in activate_volume() to make the > volume accessible. Maybe requiring those to provide their own > qemu_blockdev_options() implementation is an acceptable level of > breakage, not entirely sure. We could even try and just guess in the > default implementation if we cannot access the volume, maybe based on > the presence of 'path'. > > @Fabian does that sound acceptable to you? not sure I follow completely, to avoid misunderstandings: variant A: move activate_volume up front, no breakage, but more churn and higher chance of leaving activated volumes around in case starting fails variant B: move decision which driver to use to plugin via qemu_blockdev_options how would the default/fallback look like here? without activation, we can't rely on path since that doesn't currently require being activated, so we can't use it to distinguish block devices from files prior to activation.. so far we said we'd try to keep the qemu_blockdev_options switch as breakage free as possible.. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel