Don't rely on /dev/sdc

Recently a customer reported an issue that his automation script, which runs after a new Azure VM is created, does install a LVM volume on the ephemeral disk, instead on the data-disk belonging to a VM.
This happens on a couple of VMs. So one can say that his script is actually right. But why does it happen that the devices /dev/sdb (ephemeral disk) and /dev/sdc (data-disk) get swapped on some of his VMs?

To answer this behaviour one needs to keep in mind that the disk order of an Azure VM is not guarantied. With the exception of the OS disk of course. So sometimes it can happen that the data-disk gets assigned as the second disk-device and the ephemeral as the third disk-device. Of course such a behaviour is usually caught by the use of UUIDs as explained at /en-us/azure/virtual-machines/linux/classic/attach-disk, but at creation time the UUID is not of help to partition the disk and create a physical-volume on it.

The question of course is what can be done to use always the data-disk and not just rely on /dev/sdc? t first I thought about creating an udev rule to do the right job. But ... we are not able rename a disk-device.
Creating a link instead to point to the data-disk seems to be a could option. But again this was not a good option as well. Because the information which would trigger the rule were not distinct enough to allow a differentiation what is the ephemeral-disk and what is the data-disk.

At the end the solution, as always, was very simple. Since the most important information we are really able to trust is the partition format which is used by the ephemeral-disk. Partition one of the ephemeral-disk is always of value 0x7 ( HPFS/NTFS/exFAT )

 fdisk -l /dev/sdb

Disk /dev/sdb: 16 GiB, 17179869184 bytes, 33554432 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x46b84933

Device     Boot Start      End  Sectors Size Id Type
/dev/sdb1        2048 33552383 33550336  16G  7 HPFS/NTFS/exFAT

This key information allowed us then to create an additional logic, which ensures that the physical-volume is always and only created on the data-disk

 DATADISK=$( blkid | grep -v -e $(fdisk -l | grep HPFS/NTFS/exFAT | cut -d ' ' -f 1) -e 'sda' | cut -b -8
pvcreate  ${DATADISK}1