Re: [pve-devel] [PATCH qemu-server] migration: prohibit renaming cloud-init drive

["Daniel Kral" <d.kral@proxmox.com>]

On Tue Mar 10, 2026 at 1:38 PM CET, Fiona Ebner wrote:
> 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?

Hm, currently the most likely place for this to happen seems to be for
HA-managed VMs with replication jobs, but of course this might happen
for other VMs as well.

Bumping APIVER for '--allow-override' seems a bit much, but if there's a
future use case to have that option there might be worth it. But it
feels like something that could be reasonably implemented with a 'pvesm
free' for the cloudinit image beforehand. Either way, this would need
some attention to prevent users from overriding files not owned by the
VM.

I guess using a preparatory tunnel would also be an option, but I'd like
to avoid to include a source of timeout (regarding the missing 'command
unknown' response for mtunnel) for a relatively uncommon use case ;).

Thanks for the pointers, I'll look into this!