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

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