qm clone -full changes disk layout/order/sequence

[abien]

This is my original EL9 templates hardware layout



After cloning (full) via the following command, the layout changes
qm clone $VM_TEMPLATE $VM_ID --name $VM_HOSTNAME --storage ${VM_STORAGE:-data} -full



disk-0 and disk-1 switched places. I assume this is due to the way the cloning is processing disks:

create full clone of drive efidisk0 (data:base-9130-disk-1)
create full clone of drive ide2 (data:vm-9130-cloudinit)
create full clone of drive scsi0 (data:base-9130-disk-0)
transferred 0.0 B of 10.0 GiB (0.00%)

(...)

I prefer for a clone to be as exact as possible and would like to prevent this re-arranging of harddisk/image names.
Q: Is this expected behavior or would you like me to file a bug at bugzilla?
Q: Can i prevent or work around the re-arranging?
Q: If i cannot - (how) can i best rename the devices back to the original layout after the cloning is finished?

Why do i care: Our post-cloning workflow/scripts were created before UEFI was a thing. They expect the (linux) OS to be at $storage:base-$vmid-disk-0 (data:base-122-disk-0).

 

[fabian]

Q: Is this expected behavior or would you like me to file a bug at bugzilla?

it's expected - the N in the volume ID is not guaranteed to start at 0 either, it's automatically assigned and you should not rely on it.

Q: Can i prevent or work around the re-arranging?

not really (see above)

Q: If i cannot - (how) can i best rename the devices back to the original layout after the cloning is finished?

you shouldn't care? if you need the volume ID, ask PVE for it and use what it gives you, instead of assuming a particular numbering/naming scheme..

 

[abien]

(...)
you shouldn't care? if you need the volume ID, ask PVE for it and use what it gives you, instead of assuming a particular numbering/naming scheme..

What is the smartest way to ask PVE in this case? I came up with:

# qm config 122 | grep ^scsi0 | grep -Eo "data:([^,]+)"
data:vm-122-disk-1

 

[fabian]

it's a property string with the default key "file" containing the volume ID (so either "file=volume", or just "volume"), with the keys/value pairs of the property being comma-separated. the volume ID it self can either be a pass-through path, or has the form storage_type:volume_name (where the format of volume_name is defined by the storage plugin for your storage type). should be fairly easy to parse in various languages, especially if you are just interested in the volume.

 

[abien]

it's a property string with the default key "file" containing the volume ID (so either "file=volume", or just "volume"), with the keys/value pairs of the property being comma-separated. the volume ID it self can either be a pass-through path, or has the form storage_type:volume_name (where the format of volume_name is defined by the storage plugin for your storage type). should be fairly easy to parse in various languages, especially if you are just interested in the volume.

Thank you for describing a solution.