Storage driver (scsiN/ideN) hardcoded in destination volume instead of diskN
wmacdougall opened this issue · comments
Hello,
I'm new to proxmox and have been tasked with migrating our VM's from Proxmox 5.1 to 6.1. When using proxmove the VM's move over as expected but it seems that the storage type has changed from zvol on the source to scsi raw on the destination.
I didn't see any other options to select storage type when moving, have I missed something obvious?
2020-04-21 05:23:41,261: DEBUG: (exec) ssh -A root@10.20.0.24 -t 'zfs send -R rpool/data/vm-120-disk-1@proxmove-200421-052340 | mbuffer -q -s 128k -m 1G | ssh -o StrictHostKeyChecking=no root@10.20.0.15 'mbuffer -q -s 128k -m 10G | pv --force --eta --progress -s 1850916155 | zfs recv local-zfs/vm-101-scsi0''
Hi,
I don't use this on a daily basis, so I can't be too certain.
But a quick glance through my source suggests that:
Line 49 in c9488b7
key
is one of PROXMOX_VOLUME_TYPES
: e.g. scsiN
This is passed along to create_volume()
, which calls clone()
to copy the data.
Clone uses the key
-- the storage volume type and number -- as suffix in the volume:
Line 1282 in c9488b7
That means that the key
is simply derived from the "current" IO storage driver (virtio, ide, scsi) and a number. The scsi has nothing to do with the zvol on the destination. The zfs recv
in the command line shows we're dealing with a zfs volume, not some other raw blob.
In conclusion: this could've been just diskN
instead of ideN
/scsiN
/virtioN
. And we probably should change it (we're free to change the storage driver at will anyway), as long as the number N is guaranteed to be unique..
Okay. I've decided that this is indeed a bug.
We should use disk-N
in the name, not the storage key, which is changeable, as mentioned here:
https://www.osso.nl/blog/proxmox-alter-default-create-vm-parameters/
I think this should work. Still needs a test run though.