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

[Fiona Ebner]

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

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

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