Forums | Admin Discussion Forums: help Start New Thread Nested Flat Threaded Ultimate Show 25 Show 50 Show 75 Show 100   By: Frederic Donnat RE: Errors copying MS Windows AMI across regions [ reply ]   2012-04-11 09:35 Hi Martin, AWS has updated their MS Windows AMI, that's why you got the "Execution failed in status Initial due to ami-xxxxxxx image not found" error. Actually we are using a static mapping table for mapping MS windows AMI from source region to target region. We have to add a dynamic mapping table as AWS seems to frequently update those AMIs. First of all before answering your question, an image or a snapshot is not related to an availability zone, but only to a region. At the opposite an instance or an EBS volume is related to an availability zone. As soon as we will have updated CloudyScripts to support a dynamic mapping table for MS Windows AMI, we will let you know. Regards, /fred By: martin english RE: Errors copying MS Windows AMI across regions [ reply ]   2012-03-22 15:11 Hi team, I have identified two Errors, very similar to Ian's, that suggest an endemic issue, plus I have two Questions Errors 1) Copy MS Windows AMI to a different region, from US-East to AP-SouthEast The 'Type of MS Windows AMI' to be created was Windows-2008R2-SP1-English-Base 64-bit, failed with Execution failed in status Initial due to image ami-f31ccb9a not found 2) Copy MS Windows AMI to a different region, from AP-SouthEast to US-East The 'Type of MS Windows AMI' to be created was Windows-2008R2-SP1-English-Base 64-bit, failed with Execution failed in status Initial due to image ami-fcd396ae not found See https://cloudyscripts.com/tool/show_status/3636?hash=TdFHcxz8Sa7k Also note that in both cases, I've also reported these errors via the Debug Form on .../tool/show_status/... Question I believe I saw the answer to these questions somewhere, but I can't find it now (: 1) Can the source images / snapshots be in any Availability Zone of the region ? 2) What zone will the target images / snapshots be in ? Martin By: Frederic Donnat RE: Errors copying MS Windows AMI across regions [ reply ]   2012-02-24 21:23 Hi John, Yes the script supports Amazon MS Windows EBS-based AMI of the following type (actually available in AWS catalog): - 2003R2 Base 32-bit/64-bit - 2003R2 BaseMultiLang 32-bit/64-bit - 2003R2 SqlExpress 32-bit/64-bit - 2003R2 SQLExpressMultiLang 32-bit/64-bit - 2003R2 SqlStandard 64-bit - 2003R2 SQLStandardMultiLang 64-bit For others MS Windows 2003 server, this should work selecting the matching type of installation (Base, SQLExpress, SQLStandard, etc...), but this has not been tested. Regards, Fred By: john Midd RE: Errors copying MS Windows AMI across regions [ reply ]   2012-02-24 21:05 Does this new script work with EBS volumes, specifically WIndows 2003 servers? By: Frederic Donnat RE: Errors copying MS Windows AMI across regions [ reply ]   2012-02-23 18:09 Hi Ian, We have updated the static mapping table with the new AWS MS Windows AMI. CloudyScripts WebSite has been updated, you should be able to move your MS Windows AMI between AWS Region. Regards, Fred By: Frederic Donnat RE: Errors copying MS Windows AMI across regions [ reply ]   2012-01-26 10:42 Hi Ian, After having a deeper look, this is an issue in CloudyScripts due to the fact that we use a static mapping table. AMI ami-fbbe838f was a previous 'MS Windows-Server2008-Base 32-bit' in EU-West Region. This AMI is no longer available (it seems the change was introduced with MS Windows free tier AMI). It seems that the new AMI is the free tier ami-f1c7f885. We have to update our mapping table for MS Windows AMI. As soon as this will be available, I will update this post. Regards, Fred By: Ian Busching RE: Errors copying MS Windows AMI across regions [ reply ]   2012-01-25 23:43 Hi, just wanted to see if there was any update to this. I've tried running the script from cloudyscripts.com several times since and can't get past "Execution failed in status Initial due to image ami-fbbe838f not found". Is this a known issue with the 'Copy MS Windows AMI across regions' feature? ami-fbbe838f is not the AMI I am trying to copy and I can't find it on the community AMI's as well. Thanks for your time. By: Ian Busching RE: Errors copying MS Windows AMI across regions [ reply ]   2012-01-18 17:40 Thanks for your reply. I have just been testing out the script from your site to see how it works before deploying it elsewhere. On a side note, I tried the DevPay version as well, but noticed it doesn't have the copying MS Windows AMI across regions script added yet. It is strange that you said the target region is US-East, because I am pretty sure I selected EU-West as the target availability region in the dropdown. I tried to run it a couple additional times later as well. I would be surprised if I messed that up each time. I would run the script again to test, but now I am perpetually getting the message: "Execution failed in status Initial due to image ami-fbbe838f not found" Is "ami-fbbe838f" one of your AMI's for the script? That is not the AMI I am trying to copy myself. Thanks, Ian By: Frederic Donnat RE: Errors copying MS Windows AMI across regions [ reply ]   2012-01-18 14:38 Hi Ian, First of all thanks for using CloudyScripts and helping us improving it. From the logs you provide us it seems that the Target region you selected is not EU-West but US-East, because the logs show that the scripts tried to start an instance of the same AMI in both source an dtarget AWS Region. Jan, 12 - 00:59:28: starting up instance to execute the script (AMI = ami-23f53c4a) . Jan, 12 - 02:06:07: starting up instance to execute the script (AMI = ami-23f53c4a) ... Are you using our sample_copy_mswindows_ami.rb script? /fred By: Ian Busching Errors copying MS Windows AMI across regions [ reply ]   2012-01-16 22:28 Hi, thanks for your services. I am currently having an issue copying a MS Windows AMI from US-E to EU-W. The first time I ran the script it gave the error: "Execution failed in status FailedState due to The key pair 'Key_Pair_Name' does not exist". After checking this board I created a new Key Pair for each region without any spaces/special characters and tried again. Unfortunately it gave the same error with the new key pair files/key pair names. Below is the output from the second attempt: Jan, 12 - 00:59:28: checking snapshot 'snap-32278159' accessibility... Jan, 12 - 00:59:28: 'snap-32278159' accessible Jan, 12 - 00:59:28: starting up instance to execute the script (AMI = ami-23f53c4a) ... Jan, 12 - 00:59:29: Architecture of image ami-23f53c4a is i386. Use instance_type m1.small. Jan, 12 - 00:59:30: Started instance i-a2f9a6c0. wait until it is ready... Jan, 12 - 00:59:35: instance still starting up... Jan, 12 - 00:59:41: instance still starting up... Jan, 12 - 00:59:47: instance still starting up... Jan, 12 - 00:59:53: instance is up and running Jan, 12 - 00:59:53: going to create a new EBS volume from the specified snapshot... Jan, 12 - 00:59:59: EBS volume vol-15a88878 is ready Jan, 12 - 00:59:59: going to attach volume vol-15a88878 to instance i-a2f9a6c0 on device /dev/sdj... Jan, 12 - 01:00:18: volume vol-15a88878 successfully attached Jan, 12 - 01:00:18: connecting 'ec2-user' to ec2-50-17-49-193.compute-1.amazonaws.com... Jan, 12 - 01:00:40: connected to ec2-50-17-49-193.compute-1.amazonaws.com [sudo]. OS installed is 2.6.35.14-97.44.amzn1.i686 Jan, 12 - 01:00:40: Retrieving '/' root device name... Jan, 12 - 01:00:42: Using AWS name source device '/dev/sdj' and OS name '/dev/sdj' Jan, 12 - 01:00:42: going to create a new EBS volume of size 30GB... Jan, 12 - 01:00:49: EBS volume vol-19a98974 is ready Jan, 12 - 01:00:49: going to attach volume vol-19a98974 to instance i-a2f9a6c0 on device /dev/sdk... Jan, 12 - 01:01:07: volume vol-19a98974 successfully attached Jan, 12 - 01:01:07: Using AWS name source device '/dev/sdk' and OS name '/dev/sdk' Jan, 12 - 01:01:07: going to create filesystem on ec2-50-17-49-193.compute-1.amazonaws.com to /dev/sdk... Jan, 12 - 01:01:25: ext3 filesystem system successfully created on device /dev/sdk Jan, 12 - 01:01:25: going to mount /dev/sdk on /mnt/tmp_vol-19a98974... Jan, 12 - 01:01:27: creating mount point /mnt/tmp_vol-19a98974... Jan, 12 - 01:01:38: device /dev/sdk successfully mounted Jan, 12 - 01:01:38: connecting 'ec2-user' to ec2-50-17-49-193.compute-1.amazonaws.com... Jan, 12 - 01:01:41: connected to ec2-50-17-49-193.compute-1.amazonaws.com [sudo]. OS installed is 2.6.35.14-97.44.amzn1.i686 Jan, 12 - 01:01:41: going to start dumping and compressing source device '/dev/sdj' to '/mnt/tmp_vol-19a98974/snap-32278159.gz' file. This may take quite a time... Jan, 12 - 02:06:07: dumping and compressing done (took 3866)s Jan, 12 - 02:06:07: starting up instance to execute the script (AMI = ami-23f53c4a) ... Jan, 12 - 02:06:08: Architecture of image ami-23f53c4a is i386. Use instance_type m1.small. I then tried to run the script again today before posting here, but this time it seems to have hung at "Jan, 16 - 20:22:19: creating mount point /mnt/tmp_vol-25dcea48... ". The script has been running +2hrs and it has not moved past this point, although I do still see activity on the instance the script has created. If I try to run the script again I get: "Execution failed in status Initial due to image ami-fbbe838f not found" I suspect this has something to do with the other AMI still running, but wanted to check here before killing it. Don't see a way to stop the copy from the site, but obviously could terminate the instance. Any ideas? Thanks.