I think the intention was to only to control the 'unit' numbering of the disks in nova if 'virtio-scsi' and let other disk type's unit numbering be handled automatically by libvirt. But because the 'unit' number incrementing code only checks generically for 'bus' == 'scsi', it's controlling the disk unit numbering for non-'virtio-scsi' as well.
I'm not sure there's anyway to check if 'virtio-scsi' from the disk_mapping. If there is, it seems like the fix would be to add that check to the disk unit increment conditionals.
Indeed, we only set the initial disk_mapping[ 'unit'] values if the image meta scsi_controller .model is 'virtio-scsi':
https:/ /github. com/openstack/ nova/blob/ ce520ee789bf6a4 6f56de86769d74c 095ce432cf/ nova/virt/ libvirt/ driver. py#L3920- L3937
But then, we increment the 'unit' value if 'bus' == 'scsi' (NOT only 'virtio-scsi') when attaching a volume:
https:/ /github. com/openstack/ nova/blob/ ce520ee789bf6a4 6f56de86769d74c 095ce432cf/ nova/virt/ libvirt/ driver. py#L1422- L1423
Or creating a guest config:
https:/ /github. com/openstack/ nova/blob/ ce520ee789bf6a4 6f56de86769d74c 095ce432cf/ nova/virt/ libvirt/ driver. py#L3892- L3894
I think the intention was to only to control the 'unit' numbering of the disks in nova if 'virtio-scsi' and let other disk type's unit numbering be handled automatically by libvirt. But because the 'unit' number incrementing code only checks generically for 'bus' == 'scsi', it's controlling the disk unit numbering for non-'virtio-scsi' as well.
I'm not sure there's anyway to check if 'virtio-scsi' from the disk_mapping. If there is, it seems like the fix would be to add that check to the disk unit increment conditionals.