We are working on a use case where we need to map the disk label within the instance to the corresponding Volume ID in EBS.
While performing some validations on some AMIs, we found that there is a difference between the behavior for Windows and Linux
We have observed that the requirement we need is present in case of Windows (AMI Used: Windows_Server-2016-English-Full-Containers-2022.01.19)
The following query yields the required result. Here the serial number of the disk is mapping to the EBS volume id
The device driver for this instance was the AWS PV Storage Host Adapter
PS C:\Users\Administrator> Get-WmiObject Win32_DiskDrive | select-object -property serialnumber,index
serialnumber index
------------ -----
vol0b44250cf530aa7f3 0
vol0f38be626e3137975 1
vol0bdc570ca980fb5fb 2
However in case of Linux instances (AMI Used: amzn2-ami-kernel-5.10-hvm-2.0.20220121.0-x86_64-gp2) we are seeing that the EBS volume ID is not present within the disk metadata.
We checked the following points inside the Linux:
- Directories within /dev/disk: For the above AMI, the disk serial number is not being exposed in the /dev/disk/by-id directory. In the /dev/disk/by-path directory, there are entries present in the following format xen-vbd-51712 -> ../../xvda . Is it possible to map the string xen-vbd-51712 to the EBS volume ?
- udevadm info <disk_label>: This is yielding the following information attached below, however the volume id is not present in the below.
P: /devices/vbd-51712/block/xvda
N: xvda
S: disk/by-path/xen-vbd-51712
S: sda
E: DEVLINKS=/dev/disk/by-path/xen-vbd-51712 /dev/sda
E: DEVNAME=/dev/xvda
E: DEVPATH=/devices/vbd-51712/block/xvda
E: DEVTYPE=disk
E: ID_PART_TABLE_TYPE=gpt
E: ID_PART_TABLE_UUID=08cf25fb-6b18-47c3-b4cb-fea548b3a3a2
E: ID_PATH=xen-vbd-51712
E: ID_PATH_TAG=xen-vbd-51712
E: MAJOR=202
E: MINOR=0
E: SUBSYSTEM=block
E: TAGS=:systemd:
E: USEC_INITIALIZED=34430
As per https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/device_naming.html, the device name which is provided when the EBS volume is attached to the instance is not guaranteed to be the same which is visible inside the instance.
"When you attach a volume to your instance, you include a device name for the volume. This device name is used by Amazon EC2. The block device driver for the instance assigns the actual volume name when mounting the volume, and the name assigned can be different from the name that Amazon EC2 uses"
Since our use case can involve frequent addition/removal of EBS volumes on an instance, we wanted to find a deterministic method to identify a volume inside a Linux instance.
Could you please let us know that if there is a route by which we can relate the disk within EC2 instance with the corresponding EBS volume id ?
Hi Brettski, Thanks for the answer. We went through the instance metadata service option referred above. However it looks to be returning the label which was provided to AWS when the EBS volume was attached (not the label which is actually being used by the OS). For example, for the AMI RHEL-6.1_GA-i386-5-Hourly2 ebs1 had been assigned the label sdg during attach but the actual label inside the instance which was assigned to it is xvdk Attaching the details in the following comments
Copy pasting from the AWS EC2 console (looks like uploading an image option is not there)
I'm not sure I understand: Has the mount point in the OS been renamed? Or a different one being used? If that's the case then the console and instance metadata will not be aware of that as it is an OS-level change.
Or is there something else happening?
No, there was no renaming done for the mount point/device label. When the instance was launched , the device labels were not matching with the ones in the instance metadata.