[PATCH storage 0/1] pass scfg to parse_volname

[Roland Kammerer]

Dear PVE devs,

I'm currently trying to implement "Disk Action" -> "Reassign Owner" for
the LINSTOR plugin. This traditionally means implementing
"rename_volume", which moves a disk from something like vm-100-disk-1 to
vm-101-disk-1, which can then be parsed back by a regex to get the VM ID
by "parse_volname".

For boring technical reasons this is rather difficult in LINSTOR where
we would have to rename the LINSTOR object, the DRBD device, the DRBD
backing devices, all meta data information pointing to the old name,
snapshots,... and in the best case in a way where we can rollback the
whole cluster if something breaks on one of the nodes.

Looking at k8s and other systems that use UUID names I came up with the
idea of not encoding the VM ID in the disk name, but store that as meta
data in the LINSTOR controller for the disk object. I'm currently
generating disk names like "pm-2707dffa" (shortened UUID, could be
disk-$number or whatever). A "rename" is then trivial, I just update the
VM ID mapping in the meta data. This only works if the plugin is free to
chose a name, when "target_volname" is unset. For reassigning disks
between VMs this is always the case and that is the only use case I'm
interested in. But that is already plugin specific, the patch is more
general.

For "parse_volname" this means we can no longer use a regex, but we have
to ask the LINSTOR controller. And to ask it, I need its IP address, and
for that I would need to know my storage configuration. That is why this
patch exists.

I also considered completely "virtualising" the names, still having
vm-$id-disk-$nr names mapped via meta data to actual UUID LINSTOR/DRBD
resources, but that complicates the plugin code a lot, and it makes it
harder for users as they still see "vm-" names, and have to look up the
actual block device in some LINSTOR meta data. With the method discussed
above, users/admins see the actual names.

I'd assume this does not hurt existing plugins, in my test cluster I did
not experience any regressions, for these plugins it is just an
unused/unassigned parameter.

Roland Kammerer (1):
  storage/plugins: pass scfg to parse_volname

 ApiChangeLog       |  7 +++++++
 src/PVE/Storage.pm | 18 +++++++++---------
 2 files changed, 16 insertions(+), 9 deletions(-)

-- 
2.42.0