1

Note: I asked this question on the EC2 forums too but haven't received any love there. Hopefully the ServerFault community will be more awesome.

The new AWS Sydney region opening up is something that we've been waiting for for a long time but I'm having a lot of trouble migrating our instances over from N. California.

I managed to migrate 1 instance over using CloudyScripts to move a snapshot and then firing up a new instance in the Sydney region. This was a very new instance so both the source and destination were running on a Ubuntu 12.04 LTS server and I had no issues there.

However, the rest of our instances are all Ubuntu 10.04 LTS and with these, I'm having a lot of problems.

I've tried following:

1- following the AWS whitepaper on moving instances which was given to us at the recent Customer Appreciation Day in Sydney where the new region was launched.

The problem with this approach was with the last step (Step 19) here you register the image: ec2-register -s snap-0f62ec3f -n "Wombat" -d "migrated Wombat" --region ap-southeast-2 -a x86_64 --kernel aki-937e2ed6 --block-device-mapping "/dev/sdk=ephemeral0"

I keep getting this error: Client.InvalidAMIID.NotFound: The AMI ID 'ami-937e2ed6' does not exist which I think is due to the kernel_id not existing in the Sydney region?

2- Using CloudyScripts to move a snapshot and then creating a new volume and attaching to a new instance in Sydney

This results in the instance just hanging on boot and failing the status checks. I can't SSH in or look at the server log

I suspect that my issue is with finding the right kernel_id for the volume in the new region. However I can't seem to work out how to go about finding this kernel_id, the ones I've tried (from the original instance) don't result in the Client.InvalidAMIID.NotFound: The AMI ID 'ami-937e2ed6' error and any other kernel_id just won't boot.

I've tried both 12.04 and 10.04 versions of Ubuntu. Nothing seems to work, I've been banging my head against a wall for a while now, please help!

New (broken) instance i-a1acda9b ami-9b8611a1 aki-31990e0b

Source instance i-08a6664e ami-b37e2ef6 aki-937e2ed6

p.s. I also tried following this guide on updating my Ubuntu LTS version to 12.04 before doing the migration but it didn't seem to work either, still getting stuck on updating the kernel_id http://ubuntu-smoser.blogspot.com.au/2010/04/upgrading-ebs-instance.html

2 Answers 2

2

When you specify a non-existing Kernel ID, ec2-register does incorrectly report an error of "Client.InvalidAMIID.NotFound". This is a bug in the AWS tools.

To identify the correct Kernel ID, launch a new instance from an AMI in the target region that matches the source AMI as closely as possible. In your example, launch an instance based on an Ubuntu 10.04 LTS AMI. Once that instance is running, you can see which Kernel ID and Ramdisk ID (if any) were used for that instance. You can then use that same Kernel ID and Randisk ID (if any).

2
  • 1
    This looks like it was an Ubuntu cloud image, as I found it on Ubuntu's list. It looks like aki-31990e0b is the latest available lucid kernel image for ap-southeast-2. Dec 4, 2012 at 3:08
  • 1
    Thanks for the advice, this is very much in line with what I think the problem is. However, even with that aki I can't get the instance booting. I'm wondering if there is a way to move my current instance onto a more compatible kernel version rather than trying to troubleshoot this in the new region. Any thoughts on how to do that? Dec 4, 2012 at 5:04
1

Yes, this is one of the annoying features of AWS: AMI's are not portable from region-to-region. They are not compatible infrastructures, unfortunately.

However, at least one company has turned EC2 instance migration into a service. Ylastic offers "single click migration for EBS linux AMIs and snapshots between regions." I used this service for a brief period last month, when I helped a friend to migrate an instance from us-east-1 to us-west-2. It became such a hassle to migrate manually that I decided to try the service, and it worked.

Ylastic automatically spools up instances on your behalf to do the work, which can take a while to finish. They basically dd your data over to a temporary instance in the new region, and create a new snapshot for you you can use to start up instances in that region. Then it cleans up after itself, terminating resources used to make the transfer.

However, strategically it's best to be able to automate the process of creating any instance configuration you need in any region. We do this with Chef cookbooks, so we can have compatible AMI's ready-to-go in any region for our apps. The only hassle is keeping track of which AMI's and kernels to use in which regions. But once you have a set of recipes that works everywhere, you don't have to worry about migrating instances again.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .