[pve-devel] [PATCH qemu-server 1/1] fix #5033: api: Add target-filename option to move_disk reassign

[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 <default
naming scheme> to <uuid naming scheme> 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.

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

Our use-case would then probably have to look something like this:
- clone cloud-init template
- unattach rootdisk in clone
- rename vm<cloneId>-disk-0 to vm-<cloneId>-<targetVM.UUID>
- request clone's /config/current to search for uuid in unused disks
- move_disk from clone.unused<N> 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?

> If we choose a guest-level approach, it should also be implemented for
> containers for consistency.
> Regarding your approach:
>
> It'd make sense to support using the same VM ID if target-filename is
> specified.
>
> Also, there is an issue when the file name doesn't match the usual
> naming convention:

Sure, I can do that if you decide on it.

--
Best Regards,
Markus Ebner

--------
[1] https://bugzilla.proxmox.com/show_bug.cgi?id=5038