Azure: Support ephemeral disk handling on Gen2 VMs

[Stephen A. Zarkos]

Generation 2 VMs are becoming available in Azure, first for Azure Confidential Computing (ACC). The current portal experience is exposed through https://aka.ms/ccvm. But folks can also use the CLI to deploy Standard_DC2s or Standard_DC4s VMs in East US or West Europe and provision Gen2 VMs in Azure.

The current ephemeral disk handling makes use of a "contract" relating to how the OS and ephemeral disks are attached to the VM. With typical Gen1 VMs in Azure these disks are IDE disks, however Gen2 VMs only support SCSI disks. See "RESOURCE_DISK_PATH" and 66-azure-ephemeral.rules in the Azure datasource.

On new Gen2 VMs, the OS disk will be added to <SCSI,0,0> and the resource disk will be added to <SCSI,0,1>. The cloud-init and the above udev rule will need to be modified to properly detect the ephemeral disk for either Gen1 or Gen2 VMs.

We're making a similar change to the Azure agent - https://github.com/Azure/WALinuxAgent/issues/1362

[Chad Smith (chad.smith)]

Thanks Stephen,

Looking over udevadm info on /dev/sda & sdb on the Gen2 instances, it seems the deviceid of both is the following:

    ATTRS{device_id}=="{f8b3781a-1e82-4818-a1c3-63d806ec15bb}"

Since I don't just want cloud-init to attempt to setup links based solely on target luns, I'd like to be able to filter our udev rule matches by device_id or some portion of the device_id prefix if we think that is expected to be stable on Gen2 instances.

Do we know if device_id or some portion of that device_id exposed the Gen2 instances is expected to be static?

Example for Gen1 rule matching:

ATTRS{device_id}=="?00000000-0000-*", ENV{fabric_name}="azure_root", GOTO="ci_azure_names"
ATTRS{device_id}=="?00000000-0001-*", ENV{fabric_name}="azure_resource", GOTO="ci_azure_names"

Proposal on Gen2 matching:

ATTRS{device_id}=="?f8b3781a-1e82-*", SUBSYSTEMS="scsi", KERNELS="0:0:0:0", ENV{fabric_name}="azure_root", GOTO="ci_azure_names"
ATTRS{device_id}=="?f8b3781a-1e82-*", SUBSYSTEMS="scsi", KERNELS="0:0:0:1", ENV{fabric_name}="azure_resource", GOTO="ci_azure_names"

[Chad Smith (chad.smith)]

udevadm info on Gen2 sda(root) http://paste.ubuntu.com/p/QgNSZvkr3V/
udevadm info on Gen2 sdb(resource) http://paste.ubuntu.com/p/GdHTrNdqtT/

[Ryan Harper (raharper)]

could you re-run those with:

udevadm info -q all /sys/class/block/sda
udevadm info -q all /sys/class/block/sdb

[Chad Smith (chad.smith)]

Updated and reduced the udev rule conditionals by dropping the SUBSYSTEMS=="scsi" check as it's uncecessary given the KERNELS target/lun string format.

Updated proposal on Gen2 matching:

ATTRS{device_id}=="?f8b3781a-1e82-*", KERNELS=="0:0:0:0", ENV{fabric_name}="azure_root", GOTO="ci_azure_names"
ATTRS{device_id}=="?f8b3781a-1e82-*", KERNELS=="0:0:0:1", ENV{fabric_name}="azure_resource", GOTO="ci_azure_names"

[Chad Smith (chad.smith)]

re-running the queries thanks:
sda: http://paste.ubuntu.com/p/KSbKNck2bg/
sdb: http://paste.ubuntu.com/p/Yxqh9S66Kf/

[Server Team CI bot (server-team-bot)]

This bug is fixed with commit 3b332c93 to cloud-init on branch master.
To view that commit see the following URL:
https://git.launchpad.net/cloud-init/commit/?id=3b332c93

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3249