ossobv / proxmove

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:

proxmove/proxmove

Line 49 in c9488b7

PROXMOX_VOLUME_TYPES = ('ide', 'sata', 'scsi', 'virtio')

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:

proxmove/proxmove

Line 1282 in c9488b7

new_name = 'vm-{}-{}'.format(new_vmid, new_key)

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.

Storage driver (scsiN/ideN) hardcoded in destination volume instead of diskN