From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <pve-devel-bounces@lists.proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 0B2181FF191 for <inbox@lore.proxmox.com>; Mon, 16 Jun 2025 13:52:06 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 88B5C3E66F; Mon, 16 Jun 2025 13:52:32 +0200 (CEST) Message-ID: <1c75794c-635f-44a1-b6c9-d036294a7fc0@proxmox.com> Date: Mon, 16 Jun 2025 13:51:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Proxmox VE development discussion <pve-devel@lists.proxmox.com> References: <20250612140253.106555-1-f.ebner@proxmox.com> <20250612140253.106555-16-f.ebner@proxmox.com> <mailman.394.1750073494.395.pve-devel@lists.proxmox.com> Content-Language: en-US From: Fiona Ebner <f.ebner@proxmox.com> In-Reply-To: <mailman.394.1750073494.395.pve-devel@lists.proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL -0.031 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 <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com> 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? _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel