I was testing my ZFS over ISCSI storage with different settings, compression, encryption, etc on different datasets on my ZFS pool and noticed the disk numbering convention numbers the disks per storage appliance.
The first disk you create will be called vm-vmid-disk-0;
attaching another disk on the same storage will create vm-vmid-disk-1;
but, attaching a disk on a separate storage appliance will recreate vm-vmid-disk-0 onto that new storage.
While I have confirmed this applies across different storage types (same behavior on NFS);
This may not necessarily cause any error for you, as it did for me on iSCSI disks, depending on your storage appliances.
My error comes from the fact that iSCSI (LIO) creates a LUN using the VM disk name.
Eg: block/vm-101-disk-0
When I tried to attach another disk to the same server but on a second iSCSI storage appliance (within PVE) and where it pointed to a different dataset within the same pool, PVE tried again to create a LUN by the same name block/vm-101-disk-0
Note: While I don't intend to keep my system this way beyond testing with multiple datasets holding zvols, others may wish to use multiple iSCSI target groups (TPGs) on the same storage - so it wouldn't be incomprehensible to imagine a scenario like this in production. Since the LUN is created outside the TPGs (and then mapped to each TPG) this error will be seen in those environments as well.
Even if you don't use iSCSI, I find this confusing, particularly if you do remote backups. Restoring the disk can become a chore in identifying the correct disk.
I think the VM disk numbering convention should be consistent regardless of the storage and where the disk is numbered according to how many disks are attached to the VM.
The first disk you create will be called vm-vmid-disk-0;
attaching another disk on the same storage will create vm-vmid-disk-1;
but, attaching a disk on a separate storage appliance will recreate vm-vmid-disk-0 onto that new storage.
While I have confirmed this applies across different storage types (same behavior on NFS);
This may not necessarily cause any error for you, as it did for me on iSCSI disks, depending on your storage appliances.
My error comes from the fact that iSCSI (LIO) creates a LUN using the VM disk name.
Eg: block/vm-101-disk-0
When I tried to attach another disk to the same server but on a second iSCSI storage appliance (within PVE) and where it pointed to a different dataset within the same pool, PVE tried again to create a LUN by the same name block/vm-101-disk-0
Code:
error with cfs lock 'storage-iscsi-storage2': /dev/raid50vol/pve/zvols/vm-101-disk-0: LUN already exists! at /usr/share/perl5/PVE/Storage/LunCmd/LIO.pm line 241. at /usr/share/perl5/PVE/API2/Qemu.pm line 1315. (500)Note: While I don't intend to keep my system this way beyond testing with multiple datasets holding zvols, others may wish to use multiple iSCSI target groups (TPGs) on the same storage - so it wouldn't be incomprehensible to imagine a scenario like this in production. Since the LUN is created outside the TPGs (and then mapped to each TPG) this error will be seen in those environments as well.
Even if you don't use iSCSI, I find this confusing, particularly if you do remote backups. Restoring the disk can become a chore in identifying the correct disk.
I think the VM disk numbering convention should be consistent regardless of the storage and where the disk is numbered according to how many disks are attached to the VM.