I am trying to create an Amazon EC2 instance. I want to create a micro, 64-bit, Ubuntu 12.04 LTS instance.
In Amazon Web Services I have seen all instance have AMI numbers. Now I found two ami(s) with numbers ami-8a7f3ed8 and ami-b8a8e9ea. both looks same to me - micro, ebs-based, 64-bit Ubuntu 12.04LTS images.
If so, what is the difference and why two number for the same machine image?
When selecting an AMI, select from a trusted source.
The AMI number is just a unique identifier for a particular image that someone published. The title (e.g. Ubuntu 12.04LTS) is just a claim by the person who published the AMI about what is on it.
If you get your AMI from a source that is not known to be trustworthy, it could potentially contain built-in security holes, pre-installed spam relays, etc.
From Amazon
You launch AMIs at your own risk. Amazon cannot vouch for the integrity or security of AMIs shared by other EC2 users. Therefore, you should treat shared AMIs as you would any foreign code that you might consider deploying in your own data center and perform the appropriate due diligence.
Ideally, you should get the AMI ID from a trusted source (a web site, another EC2 user, etc). If you do not know the source of an AMI, we recommend that you search the forums for comments on the AMI before launching it. Conversely, if you have questions or observations about a shared AMI, feel free to use the AWS forums to ask or comment.
Amazon's public images have an aliased owner and display amazon in the userId field. This allows you to find Amazon's public images easily.
http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/AESDG-chapter-usingsharedamis.html#usingsharedamis-security
Personally I select AMIs published well-known entities like Amazon or RighScale.
An infinite number of people can create an infinite number of disk image variations that are still "64-bit micro Ubuntu 12.04 LTS". Just like there are over 500 million PCs in the world running Windows 7 64-bit, yet their hard drives all contain different data. If you wanted to be able to differentiate Joe's disk image from Sue's disk image, you'd need to give them different identifiers. That's why the AMI numbers are different.
AMI is just an image of a disk. It has nothing to do with type(micro). You can create multiple AMIs from the same instance and they will have have different IDs.
They are just different images. You could make two images from the same machine a minute after each other with no changes on the machine at all and they will have different AMI id's. The AMI ID is just applied at the time the image is created as a unique identifier, it infers nothing about the uniqueness of the image content.
Related
I would like to install DSE on m4.* instances, but it seems that the latest ComboAMI doesn't support it. Since it requires a different configuration, as it's not an instance-store backed instance, but rather an ebs-store backed instance and also a HVM instance and not PV instance.
I've started working on a new provisioning script, that basically does what the ComboAMI provisioning script does, but also adds the RAID0 creation for the EBS volumes that I attach per node, and the xfs file system creation.
My question is divided to two parts:
First of all, I was wondering if anyone in DataStax has already done something similar that he can share, since that can be a great reference for anyone that wants to do something similar.
Second of all, has anyone had any experience building a similar AMI on a m4.* instance type? I didn't manage to get something to work with the ComboAMI project.
I have a question about the images to mount on openStack.
I can use any image of any operative system? I guess not... but why?
I found images already suitable for openStack, but what's the different between an image cloud-ready and a normal image?
For instance, I can create a virtual machine with windows desktop? If not, why?
thank you
Cloud-ready images have been customised by the distro maker to run well under a hypervisor such as OpenStack, EC2, kvm, and LXC (not strictly a hypervisor) instead of on physical hardware. This entails removing packages that are only need in physical environments like wireless drivers etc, and adding packages that are useful in a cloud environment. For example during the boot process, cloud-ready images download metadata from the environment such as hostname and networking information. This data is used to "personalise" a new instance when it boots up for the first time.
If you really want to get in to the nuts and bolts of things, the Ubuntu UEC Images page has lots of details about the composition of the Ubuntu cloud images and other information like how to build one yourself.
I'm sure you can create a virtual machine running Windows desktop, but I've never had occasion to do so. If you look at the Amazon page about Windows it's all about running server apps like SQL Server and ASP.NET apps.
As Everett Toews pointed out in a comment above, one of the main things for making an image cloud-ready is that it can retrieve data from the metadata server when it boots up. This is used for things like retrieving the private key and collecting user data.
In addition to CloudInit, there's also Condenser. Or, you can roll your own. OpenStack uses the same protocol as the Amazon EC2 metadata service, so the EC2 metadata docs explain how to access this data.
I have a Windows 2008 EC2 instance to which I have done some customizing on the EBS boot drive.
I started the instance as m1.small (or m1.large) and the instance storage does not appear as an additional drive.
I've read that the -b switch in the ec2-run-instances command allows you to create mappings for the ephymeral instance storage. The ec2-run-instances command creates a new instance, however, in my case, the instance already exists and therefore I start it as ec2-start-instances, which does not have a -b switch for ephymeral instance storage.
Is there any way I can get to the ephymeral instance storage that comes with an m1.small instance for my existing EBS-booted instance?
UPDATE: It seems that nowadays (Feb 2015) Windows machines mount ephymeral instance storage in the Z: drive.
I'm afraid this functionality isn't available (yet) for Amazon EC2, but it's a very good question in fact - the common answer used to refer to the explicated launch time requirement, see e.g. ec2-modify-instance-attribute:
Note
If you want to add ephemeral storage to an Amazon EBS-backed instance,
you must add the ephemeral storage at the time you launch the
instance. For more information, go to Overriding the AMI's Block
Device Mapping in the Amazon Elastic Compute Cloud User Guide, or to
Adding A Default Instance Store in the Amazon Elastic Compute Cloud
User Guide. [emphasis mine]
That hasn't been that much of an issue in the past, but given the recent introduction of 64-bit ubiquity implies a significant improvement of vertical scaling versatility (see EC2 Updates: New Medium Instance, 64-bit Ubiquity, SSH Client), this is suddenly a topic indeed - your question yields even more questions in turn:
What happens for the converse case, i.e. when I start a sufficiently large instance with lots of ephemeral storage and scale it down (and possibly up again) thereafter?
In case the initial block device mapping is retained somehow, should we always start with a large instance therefore? (I actually doubt that this is the case though.)
This question can only be addressed by the AWS team I guess, so you may want to file a support request or relay the question to the Amazon Elastic Compute Cloud forum at least.
I think what you're asking (but correct me if I'm wrong) is "how do I add additional storage to an EC2 instance?".
In which case, the answer is:
Select the Volumes panel in the AWS console and create a new volume of the size you want, making sure it's in the same Availability Zone as the instance you want to attach it to. Then select that new Volume, and click 'Attach' - select the instance you want to attach it to, and click OK.
Now log-on to the instance, and in Computer Management select the Disk Management plugin, format the new unassigned partition, and give it whatever drive letter you wish. It will then show up in Explorer as a standard Windows drive.
I know it is a newbie question but the documentation is really not clear about that.
I have successfully launched a Cluster Instances Amazon Linux AMI 2011.02.1 cc1.4xlarge instance. I need to upload and process a 15 GB text file and I don't know how to activate the "additional" storage.
By default, I have just 8 GB of storage. Can someone help me writing simple and clear instruction on how to activate all the storage (1690 GB) I should have?
Thanks a lot in advance.
Regards,
Eugenio
You should be able to mount your ephemeral drives by following this guide.
Cheers.
It's a very common question and there's a large confusion that everyone has around this when starting to work with AWS EC2.
There are 2 things to have in mind here :
Instance Type
AMI (Amazon Machine Image, basically a disk snapshot with some operating system)
Each AMI has some requirements that will dictate parts of the configuration of your created instance.
Here we're concerned with the Root Device type of an AMI :
EBS-backed AMI
These AMI's only work on instances that have an EBS volume attached. And therefore if you choose an EBS-backed AMI, the wizard will by default add an EBS volume (usually of size 8 GiB) without you noticing, and you'll be charged for this EBS separately in addition to the EC2 hourly charge. In this case when you ssh to your instance you will only find 8 GiBs of storage and not the large storage you're promised when you view the EC2 Pricing table at https://aws.amazon.com/ec2/pricing/ . And that is confusing.
If you also want to use your -usually large- instance store with these AMIs, then when you create that instance you have to explicitly add a volume and select Instance Store 0 from Volume Type (in Step 4 - Add Storage). You may have more than 1 drives assigned to your instance type, you need to add all of them in this case (Instance Store 0,1,..etc). These volumes can only be added at creation time. If the volumes were automatically mounted then you'll find them at /media/ephemral*, if not, you'll have to mount them manually.
Instance-Store-backed AMI
Those images use the Instance Storage as their root device (the OS will be installed on the instance store at / ). I think the confusion comes from the fact that these AMI's are not instantly viewable in the Quick Start tab of Step 1 at which you choose the AMI. All AMIs in the Quick Start tab are EBS-backed, and Instance Store AMIs are very uncommon these days, everyone uses EBS-backed AMIs because of their various speed and persistence benefits, and that's recommended by Amazon as well.
If you want an instance-store-backed AMI to avoid dealing with any EBS whatsoever, then in Step 1, choose the tab Community AMIs, and filter them by Root Device Type = Instance Store, then choose your AMI. Whether or not you add Instance Store 0 in Step 4 - Add Storage, the instance store will be available.
Check what Amazon Linux AMI type you're launching the image as. In my experience, if you launch with the "EBS-backed" AMI type, it won't mount the ephemeral storage. If you switch to the "Instance Store" type, it will mount it for you at /media/ephemeral0
http://aws.amazon.com/amazon-linux-ami/
I understand that when I launch an instance on ec2, that the instance has to be located on a particular data center, and that after launching you can't change that. I also understand that an AMI is created from an instance.
But what I dont understand, is when I launch an instance from an AMI, why can't I specify what region I want it to run on? Seems like it shouldnt matter, once the AMI is created you should be able to launch it in any region. What does the AMI contain that ties it to a region and why?
Kernels. The kernel IDs change across regions (don't ask me why).
Meaning an AMI which specifies a kernel ID to be booted with can only be booted in the region this kernel ID exists.
AMI is region specific because AMI basically contains a software configuration (for example, an operating system, an application server, and applications). From an AMI, you launch an instance, which is a copy of the AMI running as a virtual server in the cloud. And if we consider AMI a global service, it means all AMIs are stored in one place and have access to all regions. For this, it will take more time to pull and then create instances. So if it is available in a region(region-specific), then we can quickly launch instances fast without time delay.