From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (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 lists.proxmox.com (Postfix) with ESMTPS id 4D481A1086 for ; Fri, 10 Nov 2023 14:07:40 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 339932DB for ; Fri, 10 Nov 2023 14:07:40 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (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 firstgate.proxmox.com (Proxmox) with ESMTPS for ; Fri, 10 Nov 2023 14:07:38 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 7CE4A47A80; Fri, 10 Nov 2023 14:07:38 +0100 (CET) Message-ID: <29a09577-0c39-4191-970b-1910ccdd021a@proxmox.com> Date: Fri, 10 Nov 2023 14:07:37 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Markus Ebner , pve-devel@lists.proxmox.com References: <20231108165239.22145-1-info@ebner-markus.de> <20231108165239.22145-2-info@ebner-markus.de> <1877948.CQOukoFCf9@pc.markus.lan> From: Fiona Ebner In-Reply-To: <1877948.CQOukoFCf9@pc.markus.lan> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.230 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 POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com] Subject: Re: [pve-devel] [PATCH qemu-server 1/1] fix #5033: api: Add target-filename option to move_disk reassign 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: , X-List-Received-Date: Fri, 10 Nov 2023 13:07:40 -0000 Am 10.11.23 um 11:54 schrieb Markus Ebner: >> But I do have another suggestion too: Should we rather automatically >> preserve the current volume name (just replacing the VM ID) if there is >> no other volume with that name and choose a new name if there is? For >> offline storage migration, we also do it like that (sans replacing the >> VM ID). Then we could get away without needing a new option and users >> specifying it. Would that be enough to cover your use case? > > Use-Case: > Our VM disks are tagged with UUIDs so we can reliably match them to the > hardware configuration in our database and don't delete any disks just > because they were in the wrong slot. (e.g. because someone manually > fiddled with the config). > We also have VM templates prepared with Cloud-Init installations that > use the default disk naming scheme. Now if we want to reinstall a VM, > we delete the vm's root disk volume, clone the template and move the clone's > disk volume to the target VM. At that step, we want to rename from naming scheme> to with the correct UUID that's > already specified for the vm's rootdisk in our database. > So unfortunately, I don't think that would solve our use-case. > Okay, then it won't work. I thought you might have created the disks with the custom naming scheme via the storage layer. >> Exposing the rename functionality as part of the storage API instead >> might fit better with the status quo? > > Yesterday in: https://bugzilla.proxmox.com/show_bug.cgi?id=5038[1] you > wrote that the storage layer has no access to the guest layer. > So if renaming is instead implemented here, renaming an attached disk > would break the vm similar to how deleting a volume breaks it, right? > Yes, that's true. I was thinking about doing: 1. remove config entry for disk for VM A 2. rename volume on storage layer 3. add config entry for disk for VM B The issue is that step 1 is currently not possible AFAIK, because removing the config entry will rather detach the disk (if attached) or remove the disk in the process. So I think a guest-level approach can be fine after all. > Our use-case would then probably have to look something like this: > - clone cloud-init template > - unattach rootdisk in clone > - rename vm-disk-0 to vm-- > - request clone's /config/current to search for uuid in unused disks > - move_disk from clone.unused to targetVM.virtio0 > > > Yet another suggestion: > - Do it like you said in move_disk and preserve the appendix; just changing > the vmid. > - Add a rename_disk endpoint at the guest level that is aware of the vm config > and patches it accordingly so nothing breaks. > > What do you think about that? > I'd rather go with your current approach than a new endpoint. Having said that, another issue is that custom naming is not a first-class feature currently, e.g. live-migration of a local disk or moving a disk to a different storage or restoring from a backup will just throw away the custom name. If we add more explicit support for custom names here, then it's natural that users expect it to "just work" in all scenarios. So I feel like it's a question of whether we want to better support custom names in general. There also is an open feature request to support comment fields for disks (and other hardware items): https://bugzilla.proxmox.com/show_bug.cgi?id=2672 and IMHO that would be a cleaner solution than encoding custom information in the disk name itself. Opinions from other devs? Best Regards, Fiona