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

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

[Fiona Ebner]

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/

Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
---
 src/PVE/QemuMigrate.pm | 6 +++++-
 src/PVE/QemuServer.pm  | 3 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/PVE/QemuMigrate.pm b/src/PVE/QemuMigrate.pm
index 8fa84080..a1d7471c 100644
--- a/src/PVE/QemuMigrate.pm
+++ b/src/PVE/QemuMigrate.pm
@@ -439,6 +439,7 @@ sub scan_local_volumes {
                 PVE::Storage::volume_size_info($storecfg, $volid);
 
             $local_volumes->{$volid}->{is_vmstate} = $attr->{is_vmstate} ? 1 : 0;
+            $local_volumes->{$volid}->{is_cloudinit} = $attr->{is_cloudinit} ? 1 : 0;
 
             $local_volumes->{$volid}->{drivename} = $attr->{drivename}
                 if $attr->{drivename};
@@ -725,11 +726,14 @@ sub sync_offline_local_volumes {
             my $bwlimit = $local_volumes->{$volid}->{bwlimit};
             $bwlimit = $bwlimit * 1024 if defined($bwlimit); # storage_migrate uses bps
 
+            my $preserve_name =
+                $local_volumes->{$volid}->{is_vmstate} || $local_volumes->{$volid}->{is_cloudinit};
+
             my $storage_migrate_opts = {
                 'ratelimit_bps' => $bwlimit,
                 'insecure' => $opts->{migration_type} eq 'insecure',
                 'with_snapshots' => $local_volumes->{$volid}->{snapshots},
-                'allow_rename' => !$local_volumes->{$volid}->{is_vmstate},
+                'allow_rename' => !$preserve_name,
             };
 
             my $logfunc = sub { $self->log('info', $_[0]); };
diff --git a/src/PVE/QemuServer.pm b/src/PVE/QemuServer.pm
index a7fbec14..70faab62 100644
--- a/src/PVE/QemuServer.pm
+++ b/src/PVE/QemuServer.pm
@@ -4502,6 +4502,9 @@ sub foreach_volid {
         $volhash->{$volid}->{cdrom} //= 1;
         $volhash->{$volid}->{cdrom} = 0 if !drive_is_cdrom($drive);
 
+        $volhash->{$volid}->{is_cloudinit} //= 0;
+        $volhash->{$volid}->{is_cloudinit} = 1 if drive_is_cloudinit($drive);
+
         my $replicate = $drive->{replicate} // 1;
         $volhash->{$volid}->{replicate} //= 0;
         $volhash->{$volid}->{replicate} = 1 if $replicate;
-- 
2.47.3



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

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

[Thomas Lamprecht]

On Mon, 01 Dec 2025 14:51:54 +0100, 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/
> 
> [...]

Applied, thanks!

[1/1] migration: prohibit renaming cloud-init drive
      commit: ea906cf6f32808f3f376b794c8c9e5cd95019d47


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

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

[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/

>
> Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
> ---
>  src/PVE/QemuMigrate.pm | 6 +++++-
>  src/PVE/QemuServer.pm  | 3 +++
>  2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/src/PVE/QemuMigrate.pm b/src/PVE/QemuMigrate.pm
> index 8fa84080..a1d7471c 100644
> --- a/src/PVE/QemuMigrate.pm
> +++ b/src/PVE/QemuMigrate.pm
> @@ -439,6 +439,7 @@ sub scan_local_volumes {
>                  PVE::Storage::volume_size_info($storecfg, $volid);
>  
>              $local_volumes->{$volid}->{is_vmstate} = $attr->{is_vmstate} ? 1 : 0;
> +            $local_volumes->{$volid}->{is_cloudinit} = $attr->{is_cloudinit} ? 1 : 0;
>  
>              $local_volumes->{$volid}->{drivename} = $attr->{drivename}
>                  if $attr->{drivename};
> @@ -725,11 +726,14 @@ sub sync_offline_local_volumes {
>              my $bwlimit = $local_volumes->{$volid}->{bwlimit};
>              $bwlimit = $bwlimit * 1024 if defined($bwlimit); # storage_migrate uses bps
>  
> +            my $preserve_name =
> +                $local_volumes->{$volid}->{is_vmstate} || $local_volumes->{$volid}->{is_cloudinit};
> +
>              my $storage_migrate_opts = {
>                  'ratelimit_bps' => $bwlimit,
>                  'insecure' => $opts->{migration_type} eq 'insecure',
>                  'with_snapshots' => $local_volumes->{$volid}->{snapshots},
> -                'allow_rename' => !$local_volumes->{$volid}->{is_vmstate},
> +                'allow_rename' => !$preserve_name,
>              };
>  
>              my $logfunc = sub { $self->log('info', $_[0]); };
> diff --git a/src/PVE/QemuServer.pm b/src/PVE/QemuServer.pm
> index a7fbec14..70faab62 100644
> --- a/src/PVE/QemuServer.pm
> +++ b/src/PVE/QemuServer.pm
> @@ -4502,6 +4502,9 @@ sub foreach_volid {
>          $volhash->{$volid}->{cdrom} //= 1;
>          $volhash->{$volid}->{cdrom} = 0 if !drive_is_cdrom($drive);
>  
> +        $volhash->{$volid}->{is_cloudinit} //= 0;
> +        $volhash->{$volid}->{is_cloudinit} = 1 if drive_is_cloudinit($drive);
> +
>          my $replicate = $drive->{replicate} // 1;
>          $volhash->{$volid}->{replicate} //= 0;
>          $volhash->{$volid}->{replicate} = 1 if $replicate;

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

[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?

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

[Fiona Ebner]

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?

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

[Daniel Kral]

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!