Packer: Add sriov/ena parameters for the Amazon Import Post-Processor

[paul-li]

This is a feature request to add functionality that allows the Amazon Import Post-Processor to enable ena_support/sriov_support to imported images. This allows instances launched from the imported images to leverage enhanced networking (with the assumption they have the required packages/drivers installed).

Here are some references:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html
https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-image-attribute.html

In short, it's the same functionality that is offered by same respective Amazon EBS Builder's parameters.

[TyMac]

I think that this feature is really a necessity. It appears that ENA support becomes explicitly enabled for CentOS 7.3 template AMI if yum update is applied during the build process. It can be reproduced using the CentOS 7.3 vault iso with @ Base enabled and then running "yum update -y" as a packer shell provisioner command. This will result in a AMI with ENA enabled. Not running yum update results in ENA support set to false.

[SwampDragons]

I think I need to more fully understand your use case, to know why it has to happen within the post-processor.

To do this we'd have to actually launch an AWS instance -- from your link:

To enable the SriovNetSupport enhanced networking attribute of an image, enable SriovNetSupport on an instance and create an AMI from the instance.

Currently this post-processor just uploads the images and doesn't try to launch an instance from them, so to implement this would make the post-processor a fair amount more complex than it currently is.

That said, is there a reason why you wouldn't be able to set this value at the time when you launch instances from this AMI? (see https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-attribute.html) If not, it seems like you can do a two-part packer build where after you've run the post-processor to upload the AMI, you can run the amazon-instance build to create a new AMI with the required ena configuration: https://www.packer.io/docs/builders/amazon-instance.html#ena_support

[rickard-von-essen]

I think that we should just document how to do this. You have to create a pipeline of two different packer build. The first builds the image locally, imports it with the pp. The second on uses the imported AMI as the source_image and runs amazon-ebs enabling enhanced networking.

[TyMac]

In my case it's not a matter of registering the instance for ENA, it's a matter of not registering it for ENA. The default behavior seems to do so. In this case there should also be a way to not have to launch an instance to register since you could register the ova uploaded with a call similar to the aws cli call aws ec2 register-images --image-location my-s3-bucket/myimage/image.manifest.xml --name "MyImage" --no-ena-support

[rickard-von-essen]

But register-image is for creating AMI's for instance-store backed instances. The post-processor uses import-image (or rather the API equivalent) and there is no way to configure ENA.

[TyMac]

If that's the case then I don't know how to work around the image registering itself as ENA. This is going to break the image the second the initrd is regenerated for the kernel due to patching or an extra kernel driver added. There needs to be some sort of work around.

[TyMac]

I've created a packer template repo to replicate the issue: https://github.com/TyMac/Packer_Issue.git

Packer version used 1.1.3
Virtualbox Verison 5.0.8 r103449
Mac OS 10.13.2

If you comment out the lines that install the updated kernel packages in the scripts/initial_configuration.sh script it will create a non-ENA enabled AMI:

sudo yum install NetworkManager cloud-init ruby perl net-tools curl wget htop bind-utils mailx nss dkms yum-utils -y
sudo yum install growpart cloud-init cloud-utils-growpart dracut-modules-growroot -y
sudo yum update sudo systemd wpa_supplicant expat firewalld libssh2 libgcrypt krb5-libs openssh util-linux vim-minimal vim-enhanced grub2 dhcp pcre python libxml2 openssl glibc python-perf kernel kernel-tools kernel-headers bind-utils -y

As is it will import an AMI with ENA enabled.

[SwampDragons]

What happens if you launch an instance from the ENA-enabled AMI, and then change the instance to disable ENA? When you save off a new AMI from that instance, is it ENA-enabled or disabled?

[rickard-von-essen]

I've done some research on this. I'll write my conclusions later today.

[rickard-von-essen]

First, there is no API to enable/disable ENA when importing an AMI. It's automatically detected by AWS Import/Export.

As an example:

• CentOS 7.3 (without updates) get ENA disabled (since it doesn't hava a Linux kernel v 3.2+).
• CentOS 7.5 get ENA enabled.

Both works fine to launch instances from.

Closing this as "works as intended".

[TyMac]

What if you don't want ENA enabled however? Bringing up a new instance with it enabled produces a non-bootable instance after updating the kernel (on non-ENA instance flavors - eg, t2.small). This is the problem to mitigate.

[SwampDragons]

@TyMac I'm afraid your only recourse right now is to launch it first on an instance type that can support ENA, and disable ENA from there. Hopefully once you've disabled ENA in the instance it'll save the ami correctly to have ENA disabled so that in the future you can launch on the non-ENA instance flavors. This is looks to me like an upstream bug with Amazon, which means that while we _want_ to help you there simply isn't a setting we can change to make this better.

Sorry.

[TyMac]

Yes and thank you for adding the upstream-bug label :)

[TyMac]

I found a work-around:
https://gist.github.com/TyMac/2c7a907af17cb4c8d2479ad5b16cad5c

Removing the microcode_ctl package and a custom dracut.conf fixes the issues.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.