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

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

Am 13/11/2023 um 10:38 schrieb Fabian Grünbichler:
> On November 10, 2023 2:07 pm, Fiona Ebner wrote:
>> 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?
> 
> there have been similar requests in the past, my preference would be:
> - expose "human readable" custom name more prominently in places where new
>   volumes are created, not just on the CLI/API only storage layer
> - keep the name on operations that copy/move a volume
> 
> if a conflict arises for the second part, we could simply bump the
> number-suffix until we find a free "slot", just like we do now for
> vm-XXX-disk-N. this would require a coordinated change through the
> storage plugins, although it would be possible to fall back to the old
> behaviour ("custom name" is lost) in PVE::Storage for (external) plugins
> that don't support this feature/API (yet).
> 
> for doing a strict match/integration into external tooling, some sort of
> comment or attribute would be better, as that could be easily preserved
> on "move" type operations, and the external tooling would need to ensure
> it is set for "create" type operations, and updated for "copy" type
> operations if that is required (e.g., if it is supposed to be unique).
> 
> one could argue that a comment is all that is needed for human readable
> labelling as well, but there are lots of people that *really* want
> 
> vm-XXX-system-0.raw and vm-XXX-data-0.raw (or 'db', or ..)
> 
> encoded directly in the volume (and thus file/..) name, since that is
> then also visible on the storage layer (in PVE, but also directly when
> doing disaster recovery/..), and I kind of see value in that as well.

I.e., two things

- a comment that is displayed only and has no duplication checks and a
  relatively flexible format (maxLength 64 and /^[\S ]+/) saved as, e.g.,
  URL-encoded. This is realtively easy to do, and someone already tried
  but went IMO way overboard and added comment fields for everything,
  which just does not makes sense for most options but disks and nics.

- a alias, that is checked unique per VMID (via config) and is actually
  inside the volume name. This is a bit harder to get nicely right,
  especially if one wants to do queries on that information.
  Storage move's would need some handling for (non-recommended) sharing
  of storage between clusters, or just left-over volumes. Similar for
  disk-movements to other guests, but as the counter would stay it wouldn't
  be that hard.
  My question here is is duch a thing is really worth it, as having that
  encoded is one thing, but the user actually needs to have the foresight
  to set the correct alias so that they have some value from it listing
  volumes at the storage-layer in the disaster case. And having the config
  around, they could to that mapping too if they used comments.

So, I'd not go for the alias/description/... in volume name for now,
rather do the per-disk comment first, which is way simpler to maintain
forever and provides not that less benefits, while being quite a bit
less work.