Jun 302012
 

This is not the best or perfect way, however this works for me and I was asked to share. This is going to be my first post. The AMI I am using is Instance Store backed. You could use the same for EBS backed AMI though I have not tried.

Let’s assume you are creating the original AMI in US-East and you want to put a copy in US-WEST.

  • When you create AMI simply upload bundle to US-WEST bucket as well.
  • Proceed to register AMI in US-East to ensure it works there. If it already works then try to register in US-WEST.
  • You can at this point simply register the AMI from the bucket Manifest URL or it will fail complaining about Kernel.
  • When this happens you need to fix the kernel-id. The rest of the steps are only done on the Target region US-West.
  • In US-West you will find the OS of your choice in the publicly avalable AMIs and then proceed launch it. However you don’t need to start an instance.
  • Assuming you used the AWS web console, in the following screens you can see a dropdown list of Kernel ID. Simply select the dropdown list and choose one.
  • For e.g. my original AMI is based on CentOS 5.5 so in US-West I looked for CentOS5.5 and found a kernel ID.
  • Note down a bunch of kernel ID from the list. the kernel ids start with aki-xxxx
  • Go to the US-West S3 bucket where you uploaded the AMI bundle files you wanted to migrate and find the xxxx-Manifest.xml. Download and open it in an editor of your choice.
  • Let us fix our AMI’s xxxx-Manifest.xml. Look for the section of XML about machine configuration. Something like this…


<machine_configuration>
<architecture>x86_64</architecture>
<block_device_mapping>
<mapping>
<virtual>ami</virtual>
<device>/dev/sda1</device>
</mapping>
<mapping>
<virtual>root</virtual>
<device>/dev/sda1</device>
</mapping>
</block_device_mapping>
<kernel_id>aki-9ba0f1de</kernel_id>
</machine_configuration>

You will note there is a kernel_id element there. So edit it and replace the kernel id with the one we got in US-WEST.

  • Remember to make a copy of the original Manifest.xml in case you make a mistake. Save it somewhere for future reference or rename the manifest.xml name if you are saving in the same bucket as the orignal manifest to avoid confusion.
  • Upload your edited xxxx-Manifest.xml back to your AMI bucket replacing the one that is already there.
  • Try to register the AMI again. If that fails try another kernel-id following the same process as above

That’s about it. Pretty simple and straightforward. I am sure Tech team at AWS are working on a better solution for this.

Leave a Reply