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 AF2CB1FF173 for ; Mon, 13 Jan 2025 14:43:25 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 8DD532FAE4; Mon, 13 Jan 2025 14:43:03 +0100 (CET) Message-ID: <1fe23bd4-6bac-486e-9dc3-9d85386c034f@proxmox.com> Date: Mon, 13 Jan 2025 14:42:31 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: "DERUMIER, Alexandre" , "pve-devel@lists.proxmox.com" , "f.gruenbichler@proxmox.com" References: <1841615375.1037.1736431994704@webmail.proxmox.com> <8f309dfe189379acf72db07398a37a98e8fc3550.camel@groupe-cyllene.com> <84883d1c-08d7-4c46-bfc2-aab5a0d1c3e1@proxmox.com> <8e6fefc1-879b-4c98-a412-d633bd4dc50a@proxmox.com> <2cbef7d2a33ed5ea6fab15b97f611fc4bf207c0f.camel@groupe-cyllene.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: <2cbef7d2a33ed5ea6fab15b97f611fc4bf207c0f.camel@groupe-cyllene.com> X-SPAM-LEVEL: Spam detection results: 0 AWL -0.051 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 SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH-SERIES v3 pve-storage/qemu-server/pve-qemu] add external qcow2 snapshot support 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" Am 13.01.25 um 12:58 schrieb DERUMIER, Alexandre: > > >>> For almost all QMP commands, we only need to care about the node >>> that's >>> inserted for the drive. > (yes, that the throttle group in my implementation, and I have a fixed > name, I'm reusing the "drive-(ide|scsi|virtio)x naming" > This assumption might not always hold, see my earlier replies. To avoid relying on the assumption, we can use query-block and warn if the name doesn't match the fixed one we expect. This usually shouldn't happen, but who knows what the future brings and what else touches the block graph. Querying is cheap and will immediately give us a good idea what/when something goes wrong. Such a situation might even just be a valid edge case or third-party use case. I don't want to break those for no reason. Let me illustrate what I mean with an example: say that a user requests move storage for drive scsi0. Then we can: 1. use query-block to get the node name of what's inserted in drive scsi0 right now 2. warn if the node-name doesn't match the expected drive-scsi0 name 3. run blockdev-mirror with the node name we queried, because that is the node name with that data that the guest also sees right now We could also error out instead of warn in step 2, but that might break some third-party use cases or edge cases we are not aware of right now. The problem for how to name the nodes in the backing chain is independent from this. I'll answer the other mail where you discussed this with Fabian. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel