Please explain "root store" terms (hvm-io1, hvm, ...)

Bug #1458825 reported by Chris West
28
This bug affects 6 people
Affects Status Importance Assigned to Milestone
cloud-images
Fix Released
Undecided
Robert C Jennings

Bug Description

The "cloud images" download pages offer you a variety of possible "root store"s:
 * ebs
 * ebs-io1
 * ebs-ssd
 * hvm
 * hvm-instance
 * hvm-io1
 * hvm-ssd
 * instance

e.g. http://cloud-images.ubuntu.com/releases/14.04/release/

However, these terms don't seem to be defined anywhere. Could you please link these pages to some documentation on what these terms mean? Also, it may be useful to provide a recommendation for which image is the easiest to use.

Amazon have a default instance type they recommend for new machines for their "official" 14.04 images, maybe hilighting that would be best. My guess would be that it's the root store listed as "hvm": hvm with root on rotary ebs?

I would guess the name "ebs" is misleading, as I suspect hvm, hvm-io1, and hvm-ssd (hvm-gp2) are "ebs" too; etc.

My usecase: I was after a 15.04 machine to test things on, without understanding the intricacies of AWS naming or sitting through a dist-upgrade.

Revision history for this message
Aristomenis (pikeas) wrote :

Fully agree with Chris.

"ebs" is misleading, since all the io1, ssd, and gp2 modes are also ebs.

Equally important, what is the difference between these modes? I can't find documentation anywhere online. Are the AMI build scripts available online? I'd like to know what the downsides are around disk performance if I use an SSD with hvm:ebs, or a magnetic disk with hvm:ssd.

Revision history for this message
Ville Reijonen (vreijone) wrote :

I was wondering those terms too, so I checked what kind of storage each type provided:

hvm virtualization (preferred nowadays):
  hvm-instance = local hd/ssh on those instance types which have it
  hvm = "magnetic" ebs storage
  hvm-ssd = "GP2" ebs ssd storage
  hvm-io1 = "IO1" ebs ssd storage with 500 IOPS predefined

paravirtual virtualization:
  instance = local hd/ssd on those instancestypes which have it
  ebs = "magnetic" ebs storage
  ebs-ssd = "GP2" ebs ssd storage
  ebs-io1 = "IO1" ebs ssd storage with 500 IOPS predefined

IMHO terms should be documented - if not otherwise, Google will at least find this post eventually..

Mathew Hodson (mhodson)
affects: ubuntu-on-ec2 → cloud-images
Revision history for this message
Scott Moser (smoser) wrote :

Hi,
Currently Ubuntu provides official images on many clouds.
You can use a web front end to filter down and find the right image for your cloud at
 https://cloud-images.ubuntu.com/locator/
or
 https://cloud-images.ubuntu.com/locator/daily/

Ubuntu has 'daily' images and 'released' images. The first url above is for released images, and the second for daily images. Daily images are less tested, but generally are more up to date with the distribution -updates. They're built and published when packages in the image are out of date.

For AWS specifically, instance-types and root-stores have changed over time. At thish point for 16.04 and newer releases, there are only 4 variations that are used:

  hvm/instance-store
  hvm/ssd
  pv/instance-store
  pv/ssd

Ubuntu provides machine formatted data about the images it publishes on public clouds as well as the images it makes available for download in "simplestreams" format. There is a client library at http://launchpad.net/simplestreams. The format and the availability of this data is not well documented.

The data is available over http or https. For security over http the data is gpg signed with a key provided in the 'ubuntu-cloudimg-keyring' package on Ubuntu.

This can be read at
  daily: https://cloud-images.ubuntu.com/daily/streams/
  released: https://cloud-images.ubuntu.com/releases/streams/

A discussion and some tools for the simplestreams format is at:
 https://github.com/smoser/talk-simplestreams/

The easiest thing to use is 'image-status'. Simply running 'image-status ec2' outputs the current image for each region.

  $ image-status ec2-release | pastebinit
  http://paste.ubuntu.com/25983330/

You can be more specific and get a specific result.
  $ image-status ec2-release xenial region=us-east-1
  xenial 20171026.1 us-east-1 instance hvm ami-910faeeb
  xenial 20171026.1 us-east-1 instance pv ami-af13b2d5
  xenial 20171026.1 us-east-1 ssd hvm ami-da05a4a0
  xenial 20171026.1 us-east-1 ssd pv ami-0309a879

'ssd' indicates ebs-backed ssd.

Revision history for this message
Scott Moser (smoser) wrote :

I just noticed that 'pv' images are gone for releases > xenial.
So for artful and bionic currently we only have 2 things to choose from:
  hvm/ssd
  hvm/instance

Revision history for this message
Robert C Jennings (rcj) wrote :
Download full text (3.2 KiB)

Scott gave a great answer in comment #3 especially pointing to resources for locating images for people and machines. I'll summarize some of the big changes between past release and then close this out.

The bit of the naming you have raised in this bug map to the AWS EC2 virtualization type[1] and the storage type[2] for the root disk. Amazon Machine Images (AMIs) must be published in each region and there is one AMI for each possible combination of virtualization type (hvm & paravirtual), storage (instance-store & ebs (plus ebs subtypes[3])), and architecture (32-bit i386 and 64-bit amd64).

Prior to Ubuntu 15.04 (Vivid Vervet) we published 12 images per region:
    32-/64-bit * HVM/PV virtualization * instance-store/ebs[-standard/-gp2/-io1]

Ubuntu 15.04 (Vivid Vervet) dropped 32-bit images and we published 6 images per region:
    64-bit * HVM/PV virtualization * instance-store/ebs[-standard/-gp2/-io1]
  New instance types in EC2 were not supporting 32-bit AMIs and 32-bit AMIs had been dropped from the EC2 quicklaunch previously. It was chosen to drop 32-bit in Vivid a year before the next LTS rather than support 32-bit for 5 years with the LTS; this could have impacted testing and publication timeliness as availability decreased throughout that period.

Ubuntu 16.04 (Xenial Xerus) dropped ebs-standard and ebs-io1 registrations leaving 4 images per region:
    64-bit, HVM/PV virtualization * instance-store/ebs-gp2
  At this time AWS was moving heavily from spinning disk to SSD as the default we so changed from ebs-standard (spinning) to ebs-ssd. If a user were to launch an AMI that was registered with ebs-standard they would be prompted to use ebs-ssd (AWS calls this aws-gp2) instead. It did not make sense at that time to register the same content as 3 separate AMIs only differing by what EBS sub-type would be used if the user did not change it at launch time.
  The ebs-io1 registration was also dropped considering it had to be registered with an arbitrary performance target (provisioned IOPs/GB) which has a cost impact and should be a tuning that a user chooses for their workload.
  Around this time ebs-sc1 (cold HDD) and ebs-st1 (throughput-optimized HDD) were added. By simplifying to a single AMI for EBS (rather than expanding to 5) we reduced complexity while still letting users choose at time of launch a different EBS sub-type.

Ubuntu 17.10 (Artful Aardvark) dropped paravirtualization images leaving us today with 2 images per region:
   64-bit, HVM virtualization, instance-store/ebs-gp2

As for the decoder ring:
 * instance: Paravirtual with instance-store root disk
 * ebs: Paravirtual with ebs-standard (EBS spinning disks) root disk
 * ebs-io1: Paravirtual with ebs-io1 (Provisioned IOPs SSD with hard-coded IOPs/GB)
 * ebs-ssd: Paravirtual with ebs-ssd
 * hvm: HVM virtualization with ebs-standard (EBS spinning disks)
 * hvm-instance: HVM with instance-store root disk
 * hvm-io1: HVM with ebs-io1 (Provisioned IOPs SSD with hard-coded IOPs/GB)
 * hvm-ssd: HVM with ebs-ssd

[1] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html
[2] http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Storage.html
[3] https...

Read more...

Changed in cloud-images:
assignee: nobody → Robert C Jennings (rcj)
status: New → Fix Released
Revision history for this message
Max (mbigras) wrote :

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html

PV paravirtual
HVM hardware virtual machine

Linux AMI Virtualization Types

Linux Amazon Machine Images use one of two types of virtualization: paravirtual (PV) or hardware virtual machine (HVM). The main differences between PV and HVM AMIs are the way in which they boot and whether they can take advantage of special hardware extensions (CPU, network, and storage) for better performance.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.