Switch to using lun to determine which persistent disk is attached?

[cppforlife]

I believe in the following scenario Agent cannot keep track of persistent disk attachment within the VM:

• deploy VM with one persistent disk (eg /dev/sdc)
• bump the size of the persistent disk
  • which causes second persistent disk to be attached (eg /dev/sdd)
  • first persistent disk is detached
• at this time VM still has second persistent disk attached at /dev/sdd (nothing at /dev/sdc)
• Azure migrates VM (may be reboot or start/stop will also cause this)
• when VM boots up second persistent disk that was at /dev/sdd is not at /dev/sdc
• agent will not start at this point since it cannot find persistent disk that it expects

[File System] 2016/04/27 22:07:19 DEBUG - Checking if file exists /dev/sdd
[main] 2016/04/27 ERROR - App setup Running bootstrap: Mounting persistent disk: Getting real device path: Resolving mapped device path: Timed out getting real device path for /dev/sdd

Is there a better way to determine which disk is which? OpenStack for example has a way to find it based on device ID. This article https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-classic-attach-disk/ seems to suggest lun might be the way to go. Do we know if lun would change after the reboot?

[sedouard]

Indeed, using LUNs are the correct way to map attached disks to drives. using lsscsi. This is a related issue Azure/azure-sdk-for-go#315. From everything I've seen, Azure always attaches to device 5. And that LUN is tracked by the API.

[AbelHu]

I am investigating it. From my test, the lun will never change after the reboot. I need to confirm it and update you later.

[sedouard]

Also @cppforlife if you don't have a disk at LUN 0 I believe the SCSCI driver can't detect disks at higher LUNS. So when you detach the first persisted disk, is it at LUN 0?

[cppforlife]

@sedouard im not sure. @AbelHu hopefully can confirm otherwise.

[sedouard]

/cc @szarkos. He should know for sure if this is still the case.

Pretty sure if disk@ LUN 0 is gone disks at higher LUN's are not found. We hit this issue on another project.

[cppforlife]

@sedouard what do you mean by "disks at higher LUN's are not found". do they not show up at all anywhere or do they just get renumbered?

[cppforlife]

cc @AbelHu have you had a chance to observe this behaviour. im trying to determine if marking disks with uuids would even be helpful in the above situation described by @sedouard ?

[sedouard]

they won't show up at all on lsscsi.

[AbelHu]

@cppforlife if lun 0 is gone, disks at higher LUN still can be found. I do not observe this issue. I am investigating to use scsi as DevicePathResolutionType to use uuid as the device id.