I am trying to shrink the root volume of an AMI (ami-0a6b7e0cc0b1f464f) in us-east-1 region. The shrinking itself is successful i.e. I have created a smaller snapshot which works correctly. But when I create an AMI from this snapshot, the instances of that AMI does not have ENA (Enhanced Networking with the Elastic Network Adapter) enabled in it.
Below are the high level steps I performed.
Created a new instance t3.micro and ensured that ENA is enabled in this instance.
Created a new snapshot of the root volume - "source" and a shrunken volume - "target".
Copied all files and partitions from source to target volume.
Created a snapshot of the target volume. Created an AMI from this snapshot. Tried to launch a t3 instance which I cannot because ENA is not enabled.
As per AWS Docs
Amazon Linux 2 and the latest versions of the Amazon Linux AMI have the module required for enhanced networking installed and have the required enaSupport attribute set. Therefore, if you launch an instance with an HVM version of Amazon Linux on a supported instance type, enhanced networking is already enabled for your instance.
So if I am using Amazon Linux 2, and I am taking a snapshot of a volume that has all files copied from its previous volume, why is ENA not enabled? Probably networking components are applied some other way so simple copy does not work?
I still don't know the logical reasoning behind this, but the way I successfully produced an AMI which has ENA enabled is by:
First creating a target volume as mentioned in my question.
Then to stop and detach all volumes (including the root volume) from the EC2 instance that I used to create the target volume. Note that this instance had ENA enabled.
Attach the target volume as root and start the EC2 instance. Since the target volume contains the same files as root, the ec2 instance should have no issues starting up. What we essentially did here was to swap the root volume with target volume.
Verify ENA is enabled on the machine, and your volume size is shrunk. Then create an AMI from the running instance (right click -> image -> create image).
So if I am using Amazon Linux 2, and I am taking a snapshot of a volume that has all files copied from its previous volume, why is ENA not enabled? Probably networking components are applied some other way so simple copy does not work?
You can consider AMI as a definition file which includes information about ENA. Snapshots do not know about AMI, they are 'storage'. Yes, they may include a file system, OS, drivers etc but that's not necessarily including the information AWS need to give you what you want == ENA enabled networking. The solution is actually simple. When you are creating an AMI, you tell AWS to enable ENA. As an example if you are using AWS cli to register an image, simply add --ena-support as in
aws ec2 register-image --ena-support ...
Now, AWS does say that if you create an AMI from an instance has ENA enabled, they will automatically infer this information from running instance. However, that's different than using a snapshot to create the image. It worked for you finally b/c you had a running instance with ENA drivers installed and AWS was able to detect it.
Related
We have a EBS volume from a previous T2 instance, which contains operating system, mysql installation, created users and all configurations.
For launching a new instance (T2), how to use
the pre-existing EBS volume as main bootable disk so that we have the operating system, apps and all configurations? This would save us days of time and efforts.
For a business application, should we choose T2 or T3?
As discussed you can perform the below steps to create an EC2 instance from a pre existing EBS volume.
Create a snapshot from the EBS volume.
Create an AMI from the same.
Look for the AMI in your private AMI.
Create the EC2 instance with desired instance-type from this AMI.
Also you need to care for the EBS volumes with this new EC2 instance with minimum EBS volume size etc.
Please let me know.
I have launched an EC2 instance(us-east-1) and created a volume and attached to it. Now I took a snapshot of the volume attached and copied it to a different region(London).
Here(London) I created an AMI using the snapshot copied and trying to host an Ec2 instance using that AMI. But the instance will suddenly move to stopped status from running.
Can anyone help me to understand, why this is happening.
To create an AMI from a snapshot using the console
Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
In the navigation pane, under Elastic Block Store, choose Snapshots.
Choose the snapshot and choose Actions, Create Image.
In the Create Image from EBS Snapshot dialog box, complete the fields to create your AMI, then choose Create. If you're re-creating a parent instance, then choose the same options as the parent instance.
. Architecture: Choose i386 for 32-bit or x86_64 for 64-bit.
. Root device name: Enter the appropriate name for the root volume. For more information, see Device naming on Linux instances.
. Virtualization type: Choose whether instances launched from this AMI use paravirtual (PV) or hardware virtual machine (HVM) virtualization. For more information, see Linux AMI virtualization types.
. (PV virtualization type only) Kernel ID and RAM disk ID: Choose the AKI and ARI from the lists. If you choose the default AKI or don't choose an AKI, you must specify an AKI every time you launch an instance using this AMI. In addition, your instance may fail the health checks if the default AKI is incompatible with the instance.
. (Optional) Block Device Mappings: Add volumes or expand the default size of the root volume for the AMI. For more information about resizing the file system on your instance for a larger volume, see Extending a Linux file system after resizing a volume.
AWS Auto scaling terminating instance & creating 2nd instance with new root volume,1st instance root volume available! what is the use of auto scaling here? It just created empty instance, IP changed,rpm's,services installed not replicated to 2nd instance.
If I manually deatach attach root volume of old instance to new instance and restore services manually then what is the use of Auto Scale?
Any way to handle this?
Amazon EC2 Auto Scaling will always scale-out by launching a new EC2 instance (including its own Amazon EBS boot volume) and will scale-in by terminating an EC2 instance. By default, EBS volumes on a terminated instance will be deleted by this can be overridden to keep the volume (but it won't be used when Auto Scaling launches a new instance).
To pre-load software onto an Amazon EC2 instance that is launched by Auto Scaling, there are two choices:
Create a fully-configured AMI containing all desired software and configurations. When Auto Scaling launches a new instance, it will create a boot volume (and additional volumes if desired) and will automatically load the disk contents from the AMI (Amazon Machine Image). Thus, each instance will boot with a fully-configured disk. It is your responsibility to create the AMI and maintain it with the latest version of the software you want to use. Also, please note that each new instance contains exactly what was saved on the AMI -- any changes to a disk attached to an instance is not reflected on any other instances because they are separate disk volumes.
Use a startup (User Data) script to configure the instance after it boots. This script can download and install software, set configurations and do anything you wish to script! The downside is that it takes a little longer for the instance to be ready because it needs to perform these startup tasks. The benefit of this method is that the software can be updated simply by starting a new volume — the script could automatically download the latest version of the software (whereas an AMI always contains the same contents unless a new AMI is created). This is a great way to upgrade systems — just throw away an old instance and start a new instance!
It is also possible to combine these two methods, such as having a mostly-configured AMI (eg with desired frameworks and security configurations) and then use a startup User Data script to finish the setup by installing the application.
I use Apache Brooklyn 0.8.0-incubating to create d2.xlarge instance on AWS with the following Blueprint:
location:
jclouds:aws-ec2:
region: eu-central-1
...
provisioning.properties:
imageId: eu-central-1/ami-7bcddf17 # Redhat 6.6
hardwareId: d2.xlarge # with 2TB EBS
On the machine are only 10GB total storage. After some research I found the instance volume under /dev/xvdb unpartioned.
Can me anybody explain how I can use instance storage instead of creating a new volume for the machine on AWS?
Best Regards,
Felix
This is the expected behaviour for VMs in AWS EC2.
As described in http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/add-instance-store-volumes.html:
"After you launch the instance, you must ensure that the instance
store volumes for your instance are formatted and mounted before you can use them. Note that the root
volume of an instance store-backed instance is mounted automatically."
"the instance type determines which instance store volumes are mounted for you and which are available for you to mount yourself"
For your instance type, it looks like the instance store volume is attached unformatted.
The EC2 docs talk about running lsblk, mkfs and mount to format and mount the instance store volume.
Expected behaviour also depends on the AMI: "Each AMI has a block device mapping that specifies the block devices to attach to an instance when it is launched from the AMI. An AMI that Amazon provides includes a root device only."
Note that what you get working on one AMI might not work on all other AMIs (e.g. because of different block device mappings). Sticking with Amazon's own AMIs is often a good idea, for getting sensible default behaviour.
This could be automated in Apache Brooklyn. You have a few options for that:
Implement it in the entity, e.g. if using a SoftwareProcess entity then you could use the config key pre.install.command to execute the bash commands to set up the volume.
Implement it in the location.
This could use a new MachineLocationCustomizer to execute the commands on the machine (and then configure that on the location).
Alternatively, for jclouds locations you could use the setup.script configuration, which takes the URL of a shell script to execute.
Of those approaches, the MachineLocationCustomizer gives you the most power and flexibility.
My basic need is that I should be able to make new instance from my saved image for current running Centos with all settings.
I am thinking of two options:
Create the AMI from the any state
Create the snap shots of EBS
I am confused what is the differnece between them. Are they same or different?
Can I make new instances from EBS snapshots/?
Also, can I use AMI on my localhost to create the same OS?
There are two types of AMIs/instances: EBS boot and instance-store (sometimes referenced as S3-based). You are probably using EBS boot, so this answer will relate to that type.
An EBS boot AMI is an EBS snapshot of a boot EBS volume with some extra attributes including:
Registered as an AMI with an AMI id
AKI (kernel)
ARI (ramdisk)
architecture (e.g., 64-bit)
block device mappings (e.g., where volumes should be created/attached)
description, name
permissions (who is allowed to run the AMI)
If you create an AMI of the running instance, you should be able to start new instances in the same state. Make sure you test this process so that you know it works.
If you simply snapshot the EBS volume(s) of your running instance, you will be able to create volumes from those snapshots to access the configuration and data.
It is also possible to take an EBS snapshot of an EBS boot volume and register it as an EBS boot AMI so that you can run more instances starting with that state. When registering the AMI, you'll need to specify the correct AKI, architecture, and other meta-data in order for this to work, so research and practice before you trust this approach.
It took me a while to understand it as I am new with it, but here is a thing if you are using EBS backed:
If you want to start immediately create AMI Image( which creates image of OS and store data as EBS Snapshot), then the whole AMI Image contains current state of your instance which is installed OS which is all config and data files.
If you only take EBS snapshot, then for restore you need to launch new AMI, and you can attach this volume to it for just to access data. If your new AMI has different OS or upgraded may be few of your config won't work and you need to install your packages from scratch. So you should check this first.
In simple words EBS Snapshot can not be used as root volume unless you make and own its AMI image :-)
In brief, EBS boot AMI = EBS root volume snapshot + metadata
For better understanding, you can play it through hands on.
create an EBS snapshot for a particular running instance.
Find this snapshot.
Fill some meta data, and build image(AMI)
You did it. A brand new AMI has been created.