This content has been marked as final. Show 6 replies
I invite you to believe that this is not the only way to proceed. I need to reach someone in Oracle who actually cares about Amazon cloud computing.
Oracle cannot afford to have their customers use images of questionable origin, perhaps damaged, corrupted, or malicious. Oracle's own white paper (at http://www.oracle.com/technetwork/topics/cloud/oracle-aws-getting-started-twp-171089.pdf) specifies that you use images "identified by their owner id: 725966715235".
I have to believe that this situation is simply an oversight, but I don't know how to reach someone who can fix it.
OK, Mr Experience. :-) I'm willing to pick up the slack when Oracle fails to implement a sane strategy.
So tell me this: When I migrate my image to the Asia Pacific region, what do I specify for the kernel ID and the ramdisk ID when the image in the US East region uses the values listed below?
Kernel ID: aki-0d9f7b64
Ramdisk ID: ari-369f7b5f
I issued ec2-migrate-manifest but it failed with "ERROR: Mapping for 'aki-0d9f7b64' not found." I know the rule is to find an AMI similar to the new one and use its identifiers, but I can't find a 64 bit Oracle Linux AMI in ap-southeast-1. Any advice?
I found a better solution than using AWS API to copy the AMI is to use Cloudy_Scripts to copy AMI to different region, the script will ease the kernel and ram match.
You can use the hosted script on their website or you can launch your AMI and run your own instance if you concern about security their AMI is ami-6541ae0c , I have been using them for a while they are reliable and secure.
You need to provide your private key, Amazon secret key and other information for the region you want to create the AMI for.
Here is the link https://cloudyscripts.com/tool/show/5
Hopefully Oracle will hire someone to look at their cloud promises.
The tool at https://cloudyscripts.com/tool/show/5 fails because when it attempts to log-in as root to an Oracle instance created from ami-3f739c56, the connection fails. This failure occurs because the instance initialization may go on 15 minutes or longer before it will be ready to accept an ssh login.
I reported this problem using the CloudyScripts feedback and received a quick response. They are aware of the problem, but have a higher priority task they must finish before they fix the problem. Their proposed fix is to add a timeout value to the script's menu so a user can supply a sufficiently large value when the default value is inappropriate.
My personal attempts to find an AKI and ARI identifier in the Asia Pacific region have failed. I found a candidate and supplied the appropriate values. I can transfer the image and register the image, but any instance created from the image will not accept ssh connections.