New udev rules simplify your life

Marcus Lachmanez — Tue, 01 Aug 2017 21:28:31 GMT

The udev rules which come with the WALinuxAgent got modified as I had to learn. These new rules are really handy to figure out what disks are available and where they are mounted on. The rules are defined as follows

ACTION=="add|change", SUBSYSTEM=="block", ENV{ID_VENDOR}=="Msft", ENV{ID_MODEL}=="Virtual_Disk", GOTO="azure_disk"

GOTO="azure_end"

LABEL="azure_disk"
# Root has a GUID of 0000 as the second value
# The resource/resource has GUID of 0001 as the second value
ATTRS{device_id}=="?00000000-0000-*", ENV{fabric_name}="root", GOTO="azure_names"
ATTRS{device_id}=="?00000000-0001-*", ENV{fabric_name}="resource", GOTO="azure_names"
# Wellknown SCSI controllers
ATTRS{device_id}=="{f8b3781a-1e82-4818-a1c3-63d806ec15bb}", ENV{fabric_scsi_controller}="scsi0", GOTO="azure_datadisk"
ATTRS{device_id}=="{f8b3781b-1e82-4818-a1c3-63d806ec15bb}", ENV{fabric_scsi_controller}="scsi1", GOTO="azure_datadisk"
ATTRS{device_id}=="{f8b3781c-1e82-4818-a1c3-63d806ec15bb}", ENV{fabric_scsi_controller}="scsi2", GOTO="azure_datadisk"
ATTRS{device_id}=="{f8b3781d-1e82-4818-a1c3-63d806ec15bb}", ENV{fabric_scsi_controller}="scsi3", GOTO="azure_datadisk"
GOTO="azure_end"

# Retrieve LUN number for datadisks
LABEL="azure_datadisk"
ENV{DEVTYPE}=="partition", PROGRAM="/bin/sh -c 'readlink /sys/class/block/%k/../device|cut -d: -f4'", ENV{fabric_name}="$env{fabric_scsi_controller}/lun$result", GOTO="azure_names"
PROGRAM="/bin/sh -c 'readlink /sys/class/block/%k/device|cut -d: -f4'", ENV{fabric_name}="$env{fabric_scsi_controller}/lun$result", GOTO="azure_names"
GOTO="azure_end"

# Create the symlinks
LABEL="azure_names"
ENV{DEVTYPE}=="disk", SYMLINK+="disk/azure/$env{fabric_name}"
ENV{DEVTYPE}=="partition", SYMLINK+="disk/azure/$env{fabric_name}-part%n"

LABEL="azure_end"

What do they do compared to what we were used to? Instead of the just having two symbolic links to the os-disk and the ephemeral-disk in /dev/disk/azure resource -> ../../sdb root -> ../../sda the new rules provide you also information about the partition available on the root -disk and ephemeral-disk. And also information about attached data-disks

resource -> ../../sdb
resource-part1 -> ../../sdb1
root -> ../../sda
root-part1 -> ../../sda1
root-part2 -> ../../sda2
scsi1
   lun0 -> ../../../sdc
   lun0-part1 -> ../../../sdc1

These available symbolic links in /dev/disk/azure allow you to create scripts in a more agnostic way. If you had previously referenced your /dev/sdc just as /dev/sdc, which may lead to trouble the first time you start a VM, you can simply reference it as /dev/disk/azure/scsi1/lun0 and can be sure you hit exactly the disk as intended. I encourage you therefore to update the WALinuxAgent or install at least the new rules.

Don't rely on /dev/sdc

Marcus Lachmanez — Tue, 18 Jul 2017 13:03:26 GMT

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 https://docs.microsoft.com/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

The Softwaremechanic

New udev rules simplify your life

Don't rely on /dev/sdc