Skip to content
This repository has been archived by the owner on Jun 10, 2019. It is now read-only.

New NVMe disks on AWS are not supported #452

Open
bcorijn opened this issue Feb 8, 2018 · 1 comment
Open

New NVMe disks on AWS are not supported #452

bcorijn opened this issue Feb 8, 2018 · 1 comment

Comments

@bcorijn
Copy link

bcorijn commented Feb 8, 2018

I just tried building an image using a new M5 instance, which failed during a partitioning step. I see bootstrap-vz expects disks to be in the /dev/xvd + letter or /dev/sd + letter` format, while the newest AWS generations have moved to NVMe: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/nvme-ebs-volumes.html

Some extra information on the error:

Deleting workspace
Successfully completed rollback
Traceback (most recent call last):
  File "./bootstrap-vz/bootstrap-vz", line 5, in <module>
    main()
  File "/tmp/imagebuilder-1779303880203559964/bootstrap-vz/bootstrapvz/base/main.py", line 29, in main
    dry_run=opts['--dry-run'])
  File "/tmp/imagebuilder-1779303880203559964/bootstrap-vz/bootstrapvz/base/main.py", line 111, in run
    tasklist.run(info=bootstrap_info, dry_run=dry_run)
  File "/tmp/imagebuilder-1779303880203559964/bootstrap-vz/bootstrapvz/base/tasklist.py", line 44, in run
    task.run(info)
  File "/tmp/imagebuilder-1779303880203559964/bootstrap-vz/bootstrapvz/common/tasks/partitioning.py", line 27, in run
    info.volume.partition_map.create(info.volume)
  File "/tmp/imagebuilder-1779303880203559964/bootstrap-vz/bootstrapvz/base/fs/partitionmaps/abstract.py", line 50, in create
    self.fsm.create(volume=volume)
  File "/usr/local/lib/python2.7/dist-packages/fysom/__init__.py", line 294, in fn
    if self._before_event(e) is False:
  File "/usr/local/lib/python2.7/dist-packages/fysom/__init__.py", line 329, in _before_event
    return getattr(self, fnname)(e)
  File "/usr/local/lib/python2.7/dist-packages/fysom/__init__.py", line 95, in _callback
    return func(obj, *args, **kwargs)
  File "/tmp/imagebuilder-1779303880203559964/bootstrap-vz/bootstrapvz/base/fs/partitionmaps/gpt.py", line 104, in _before_create
    '--', 'mklabel', 'gpt'])
  File "/tmp/imagebuilder-1779303880203559964/bootstrap-vz/bootstrapvz/common/tools.py", line 13, in log_check_call
    raise e
subprocess.CalledProcessError: Command 'parted --script --align none /dev/xvdf -- mklabel gpt' returned non-zero exit status 1 
@vmlintu-nosto
Copy link
Contributor

Do you know if there's a recommended way to detect if the instance is using NVMe backed instances? I've been using the following patch successfully on c5 instances for some time, but it feels quite kludgy. Listing instance types would be far from optimal also as new instance types would need to be added quite often.

diff --git a/bootstrapvz/providers/ec2/ebsvolume.py b/bootstrapvz/providers/ec2/ebsvolume.py
index a3aa8d8..51cfa01 100644
--- a/bootstrapvz/providers/ec2/ebsvolume.py
+++ b/bootstrapvz/providers/ec2/ebsvolume.py
@@ -27,12 +27,24 @@ class EBSVolume(Volume):
         import string

         self.instance_id = e.instance_id
-        for letter in string.ascii_lowercase[5:]:
-            dev_path = os.path.join('/dev', 'xvd' + letter)
-            if not os.path.exists(dev_path):
-                self.device_path = dev_path
-                self.ec2_device_path = os.path.join('/dev', 'sd' + letter)
-                break
+        if os.path.exists('/dev/xvda'):
+            for letter in string.ascii_lowercase[5:]:
+                dev_path = os.path.join('/dev', 'xvd' + letter)
+
+                if not os.path.exists(dev_path):
+                    self.device_path = dev_path
+                    self.ec2_device_path = os.path.join('/dev', 'sd' + letter)
+                    break
+
+        if os.path.exists('/dev/nvme0'):
+            for index in range(1,20):
+                dev_path = os.path.join('/dev', "nvme%dn1" % index)
+
+                if not os.path.exists(dev_path):
+                    letter = string.ascii_lowercase[4:][index]
+                    self.device_path = dev_path
+                    self.ec2_device_path = os.path.join('/dev', 'sd' + letter)
+                    break

john-pierce added a commit to john-pierce/bootstrap-vz that referenced this issue Jul 12, 2018
Fixes: andsens#452

Adds support for building on EC2 hosts that have NVMe EBS devices.

Introduces the DescribeInstances permission requirement for the calling
role.

Changes the device naming logic on the host during build time.
- The new target volume will be mounted with the highest available
  DeviceName in the BlockDeviceMapping object, taking care to avoid
  assignments that also are allocated at launch to ephemeral devices
  (C5d, I3, F1, and M5d currently).
- The system device name will be identifed by the difference between the
  existing block devices prior to and after the AttachVolume call has
  finished. This race condition already existed with the previous logic.
john-pierce added a commit to john-pierce/bootstrap-vz that referenced this issue Jul 15, 2018
Fixes: andsens#452

Adds support for building on EC2 hosts that have NVMe EBS devices.

Introduces the DescribeInstances permission requirement for the calling
role.

Changes the device naming logic on the host during build time.
- The new target volume will be mounted with the highest available
  DeviceName in the BlockDeviceMapping object, taking care to avoid
  assignments that also are allocated at launch to ephemeral devices
  (C5d, I3, F1, and M5d currently).
- The system device name will be identifed by the difference between the
  existing block devices prior to and after the AttachVolume call has
  finished. This race condition already existed with the previous logic.
john-pierce added a commit to john-pierce/bootstrap-vz that referenced this issue Jul 15, 2018
Fixes: andsens#452

Adds support for building on EC2 hosts that have NVMe EBS devices.

Introduces the DescribeInstances permission requirement for the calling
role.

Changes the device naming logic on the host during build time.
- The new target volume will be mounted with the highest available
  DeviceName in the BlockDeviceMapping object, taking care to avoid
  assignments that also are allocated at launch to ephemeral devices
  (C5d, I3, F1, and M5d currently).
- The system device name will be identifed by the difference between the
  existing block devices prior to and after the AttachVolume call has
  finished. This race condition already existed with the previous logic.
john-pierce added a commit to john-pierce/bootstrap-vz that referenced this issue Jul 16, 2018
Fixes: andsens#452

Adds support for building on EC2 hosts that have NVMe EBS devices.

Introduces the DescribeInstances permission requirement for the calling
role.

Changes the device naming logic on the host during build time.
- The new target volume will be mounted with the highest available
  DeviceName in the BlockDeviceMapping object, taking care to avoid
  assignments that also are allocated at launch to ephemeral devices
  (C5d, I3, F1, and M5d currently).
- The system device name will be identifed by the difference between the
  existing block devices prior to and after the AttachVolume call has
  finished. This race condition already existed with the previous logic.
john-pierce added a commit to john-pierce/bootstrap-vz that referenced this issue Jul 16, 2018
Fixes: andsens#452

Adds support for building on EC2 hosts that have NVMe EBS devices.

Introduces the DescribeInstances permission requirement for the calling
role.

Changes the device naming logic on the host during build time.
- The new target volume will be mounted with the highest available
  DeviceName in the BlockDeviceMapping object, taking care to avoid
  assignments that also are allocated at launch to ephemeral devices
  (C5d, I3, F1, and M5d currently).
- The system device name will be identifed by the difference between the
  existing block devices prior to and after the AttachVolume call has
  finished. This does not address the race condition identified in andsens#459.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants