From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 3A5931FF144 for ; Tue, 10 Mar 2026 13:38:17 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id F3B711CED2; Tue, 10 Mar 2026 13:38:09 +0100 (CET) Message-ID: <0f6d46a7-ee96-47c6-8c60-ce7348166d4a@proxmox.com> Date: Tue, 10 Mar 2026 13:38:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [pve-devel] [PATCH qemu-server] migration: prohibit renaming cloud-init drive From: Fiona Ebner To: Daniel Kral , Proxmox VE development discussion References: <20251201135345.125993-1-f.ebner@proxmox.com> <4f619b8f-b0d3-4163-af25-e53272aa7bea@proxmox.com> Content-Language: en-US In-Reply-To: <4f619b8f-b0d3-4163-af25-e53272aa7bea@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1773146251967 X-SPAM-LEVEL: Spam detection results: 0 AWL -1.067 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.408 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.819 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.903 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 Message-ID-Hash: IF6OH3F52ESNQMW25EBMWHCFFIPDM5PM X-Message-ID-Hash: IF6OH3F52ESNQMW25EBMWHCFFIPDM5PM X-MailFrom: f.ebner@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 X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Am 10.03.26 um 1:30 PM schrieb Fiona Ebner: > Am 10.03.26 um 1:22 PM schrieb Daniel Kral: >> On Mon Dec 1, 2025 at 2:51 PM CET, Fiona Ebner wrote: >>> Usually, disks are allowed to be renamed during migration if there is >>> a naming conflict caused by a left-over disk on the target. However, >>> the type of the cloud-init disk is encoded in its name, so it must not >>> be renamed or it cannot be recognized as a cloud-init disk anymore, as >>> reported in the community forum [0]. >>> >>> [0]: https://forum.proxmox.com/threads/167767/ >> >> A user in the community forum [1] reported that if a VM is moved to >> another node during a fence recovery, the VM will fail to migrate back, >> e.g., if a node affinity rule prioritizes the previous node. >> >> This patch is correct to not allow renaming cloudinit images, but I >> wonder if it would be a reasonable idea to allow overriding existing >> cloudinit images on the target node as these are auto-generated? >> >> That would probably need a `--allow-override` flag for pvesm, which >> would require that the target host can understand the parameter though. >> >> [1] https://forum.proxmox.com/threads/181516/ > > I think we could remove left-over cloud-init images as part of the > 'pvesr prepare-local-job' on the target? Ah wait, it doesn't only affect the scenario with replication. The 'pvesm apiinfo' command was added when introducing the '--allow-rename' flag. You could add '--allow-override', bump the API and then use that call to check if it is understood by the target. Or maybe we can add some kind of preparatory tunnel command for removing any left-over cloud-init images?