EDIT and TL;DR:
ubuntu@ip-172-31-19-77:~/.aws$ aws ec2 describe-instances | jq . | grep -i device
"BlockDeviceMappings": [],
"RootDeviceType": "ebs",
"RootDeviceName": "/dev/sda1",
"DeviceIndex": 0,
"BlockDeviceMappings": [
"DeviceName": "/dev/sda1",
"DeviceName": "/dev/xvdb",
"RootDeviceType": "ebs",
"RootDeviceName": "/dev/sda1",
"DeviceIndex": 0,
"BlockDeviceMappings": [
"DeviceName": "/dev/sda1",
"RootDeviceType": "ebs",
"RootDeviceName": "/dev/sda1",
"DeviceIndex": 0,
"BlockDeviceMappings": [
"DeviceName": "/dev/xvda",
"RootDeviceType": "ebs",
"RootDeviceName": "/dev/xvda",
"DeviceIndex": 0,
"BlockDeviceMappings": [
"DeviceName": "/dev/sda1",
"DeviceName": "/dev/sdf",
"RootDeviceType": "ebs",
"RootDeviceName": "/dev/sda1",
ubuntu@ip-172-31-19-77:~/.aws$ aws ec2 describe-volumes | jq . | grep -i device
"Device": "/dev/sda1"
"Device": "/dev/sdf"
"Device": "/dev/xvda"
"Device": "/dev/sda1"
"Device": "/dev/xvdb"
"Device": "/dev/sda1"
ubuntu@ip-172-31-19-77:~/.aws$ ls /dev/sd*
ls: cannot access '/dev/sd*': No such file or directory
ubuntu@ip-172-31-19-77:~/.aws$ ls /dev/xv*
ls: cannot access '/dev/xv*': No such file or directory
ubuntu@ip-172-31-19-77:~/.aws$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1 259:0 0 1G 0 disk
nvme1n1 259:1 0 8G 0 disk
└─nvme1n1p1 259:2 0 8G 0 part /
Explanation:
I would like to know in advance which block device a particular AWS instance is supposed to have post-attachment.
Unfortunately, the instance metadata endpoint for block devices introduced back in 2007 does not seem to work reliably anymore?
Here's an example t2.medium
instance I'm running with latest Ubuntu (17.10) AMI at the time of writing this (not Amazon Linux):
Not only the EBS modules show up in the console, but seem to be properly attached:
According to the official AWS docs on block-device-mappings:
block-device-mapping/ebsN
: The virtual devices associated with Amazon EBS volumes, if any are present. Amazon EBS volumes are only available in metadata if they were present at launch time or when the instance was last started. The N indicates the index of the Amazon EBS volume (such as ebs1 or ebs2).2007-12-15
But unfortunately there are no such endpoints present after the instance is fully up and running and all EBS volumes are attached:
$ curl http://169.254.169.254/latest/meta-data/block-device-mapping/
ami
ephemeral0
ephemeral1
$ curl http://169.254.169.254/latest/meta-data/block-device-mapping/ami
/dev/sda1
$ curl http://169.254.169.254/latest/meta-data/block-device-mapping/ebs1
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>404 - Not Found</title>
</head>
<body>
<h1>404 - Not Found</h1>
</body>
</html>
$ curl http://169.254.169.254/latest/meta-data/block-device-mapping/ebs2
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>404 - Not Found</title>
</head>
<body>
<h1>404 - Not Found</h1>
</body>
</html>
On the other hand, the operating system (under XEN device scheme), exposes the volumes via xvdXX
devices:
$ ls /dev/xvd*
/dev/xvda /dev/xvda1 /dev/xvdf /dev/xvdg
So this leaves me with a poor solution of just assuming which block device is going to be depending on which instance I'm running, which predictably breaks once, for instance, Amazon introduces new iron with completely different underlying block device naming schemes such as /dev/nvme0n1p1
:
https://twitter.com/braincode/status/968005482102190080
Here's what happens on freshly instantiated M5 instance with an EBS volume attached:
$ curl http://169.254.169.254/latest/meta-data/block-device-mapping/
ami
ebs2
root
$ curl http://169.254.169.254/latest/meta-data/block-device-mapping/ebs2
sdf
- Why is only
ebs2
listed and notebs1
? sdf
?
There's not a single sd*
on m5 instance's operating system:
$ ls /dev/sd*
ls: cannot access '/dev/sd*': No such file or directory
What am I doing wrong? Is this a known bug? How do people/boto/cloudinit modules handle that?