9690e55e9b
since the rbd images themselves are named differently than the volumes in our config files, we need to recreate this information from the parent relation in the ceph metadata, otherwise list_images() might return wrong volume names/IDs since list_images is used by PVE::Storage::vdisk_free() to check for children still referencing a base image, because of the wrong volume id RBDPlugin->parse_volname() does not detect the base image of linked clones and the check fails. this is thankfully mitigated by the protected status of the base snapshot, but creates a rather confusing error message. scenario (VM 701 is a linked clone of template VM 700): $ qm config 700 | grep virtio0: virtio0: ceph_qemu:base-700-disk-1,size=2G $ qm config 701 | grep virtio0: virtio0: ceph_qemu:base-700-disk-1/vm-701-disk-1,size=2G before (pvesm list reports wrong volume ID, check fails): $ pvesm list ceph_qemu ceph_qemu:base-700-disk-1 raw 2147483648 700 ceph_qemu:vm-701-disk-1 raw 2147483648 701 $ pvesm free ceph_qemu:base-700-disk-1 snap_unprotect: can't unprotect; at least 1 child(ren) in pool rbd rbd unprotect base-700-disk-1 snap '__base__' error: snap_unprotect: can't unprotect; at least 1 child(ren) in pool rbd after (correct volume ID, check works as intended): $ pvesm list ceph_qemu ceph_qemu:base-700-disk-1 raw 2147483648 700 ceph_qemu:base-700-disk-1/vm-701-disk-1 raw 2147483648 701 $ pvesm free ceph_qemu:base-700-disk-1 base volume 'base-700-disk-1' is still in use (use by 'base-700-disk-1/vm-701-disk-1')