Azure: Support ephemeral disk handling on Gen2 VMs
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Fix Released
|
High
|
Chad Smith |
Bug Description
Generation 2 VMs are becoming available in Azure, first for Azure Confidential Computing (ACC). The current portal experience is exposed through https:/
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_
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:/
Related branches
- Server Team CI bot: Approve (continuous-integration)
- Ryan Harper: Approve
-
Diff: 1433 lines (+661/-139)21 files modifiedcloudinit/cmd/devel/render.py (+24/-11)
cloudinit/cmd/devel/tests/test_render.py (+44/-1)
cloudinit/cmd/query.py (+24/-12)
cloudinit/cmd/tests/test_query.py (+71/-5)
cloudinit/config/cc_disk_setup.py (+1/-1)
cloudinit/handlers/jinja_template.py (+9/-1)
cloudinit/net/dhcp.py (+32/-10)
cloudinit/sources/DataSourceAzure.py (+46/-33)
cloudinit/tests/test_url_helper.py (+24/-1)
cloudinit/tests/test_util.py (+66/-17)
cloudinit/url_helper.py (+25/-6)
cloudinit/util.py (+4/-3)
debian/changelog (+28/-0)
doc/rtd/topics/datasources/azure.rst (+46/-0)
packages/redhat/cloud-init.spec.in (+1/-0)
packages/suse/cloud-init.spec.in (+1/-0)
systemd/cloud-init.service.tmpl (+1/-2)
tests/unittests/test_builtin_handlers.py (+25/-0)
tests/unittests/test_datasource/test_azure.py (+148/-19)
tests/unittests/test_datasource/test_ec2.py (+24/-16)
udev/66-azure-ephemeral.rules (+17/-1)
- Server Team CI bot: Approve (continuous-integration)
- Paul Meyer (community): Approve
- cloud-init Commiters: Pending requested
-
Diff: 32 lines (+17/-1)1 file modifiedudev/66-azure-ephemeral.rules (+17/-1)
Changed in cloud-init: | |
importance: | Undecided → High |
status: | New → In Progress |
assignee: | nobody → Chad Smith (chad.smith) |
Changed in cloud-init: | |
status: | Fix Committed → Fix Released |
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-63d806ec15 bb}"
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" id}=="? 00000000- 0001-*" , ENV{fabric_ name}=" azure_resource" , GOTO="ci_ azure_names"
ATTRS{device_
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" id}=="? f8b3781a- 1e82-*" , SUBSYSTEMS="scsi", KERNELS="0:0:0:1", ENV{fabric_ name}=" azure_resource" , GOTO="ci_ azure_names"
ATTRS{device_