About OMIs

An OUTSCALE Machine Image (OMI) is a template for instances containing at least an Operating System (OS) and possibly other software applications and other configurations like block device mappings.

OMIs enable you to launch instances with a predefined software configuration and applications you need, without having to install the same software applications on all the instances you launch for a specific use case.

General Information

An OMI is a machine image used as a template to launch instances based on a Block Storage Unit (BSU) volume as the root device. An OMI provides at least an OS (Linux or Windows), and can provide software applications or copies of other BSU volumes.

To function properly, Windows instances require at least a v3 processor generation, 2 vCores, and 4 GiB of memory. For more information, see Instance Types.

An OMI also provides a configuration for instance attributes, like DisableApiTermination, which you can modify if needed. For more information, see Modifying an Instance Attribute.

OMIs can be created either from a snapshot of a volume or from an instance:

  • If you create an OMI from a snapshot, the latter is used to create the root device of the instances to be launched.

  • If you create an OMI from an instance, a snapshot of the root device is created to create the OMI and then to create the root device of the instances to be launched. If other BSU volumes are attached to the source instance, snapshots of each of these volumes are created and instances are launched with copies attached to them.

  • Registering an OMI is the last step to finalizing its creation process:

    • Creating an OMI from a snapshot corresponds to registering it through the RegisterImage API method.

    • Creating an OMI from an instance corresponds to creating the snapshots from the instance and then registering the OMI. These actions are both included in the CreateImage API method.

    • Deleting an OMI corresponds to first deregistering it, and then deleting it. These actions are both included in the DeregisterImage method.

  • You can also add other volumes to an OMI when creating it using block device mappings. For more information, see Defining Block Device Mappings.

  • You cannot delete snapshots that are currently used by an OMI.

3DS OUTSCALE provides public official OMIs, that are created and supported by 3DS OUTSCALE. OUTSCALE users can also create OMIs from one of their snapshots or one of their instances. By default, these OMIs are private. The owner of a private OMI can share it with one or more specified users.

3DS OUTSCALE cannot guarantee the proper functioning of instances launched from non-official OMIs, that is, private or external OMIs.

Two architectures are available for OMIs:

  • 32-bit architecture (i386)

  • 64-bit architecture (x86_64)

3DS OUTSCALE provides only 64-bit official OMIs, but you can create both 32-bit and 64-bit OMIs.

3DS OUTSCALE ensures that software contained in official OMIs is up-to date. However, once you launch an instance using one of these OMIs, you bear the responsibility of updating your run-time environment.

OMIs Permissions, Copies and Exports to OOS

You can share your OMIs with other users within the same Region. This enables these other users to create an instance from the OMI or create a copy of it. The shared OMI still belongs to you. For more information, see Modifying the Attributes of an OMI.

You can also copy an OMI between accounts in different Regions or in the same one. Contrary to a shared OMI, the copy of an OMI is independent from the source one, has its own ID and lifecycle, and belongs to the other account.

  • To copy an OMI between accounts in different Regions, the owner of the source OMI first needs to export this OMI to an OUTSCALE Object Storage (OOS) bucket. Using the pre-signed URL of the manifest file of the OMI, the other account then needs to import it, which creates a copy in its own account. For more information, see Tutorial: Copying an OMI.

    Before exporting an OMI or a snapshot to another Region, you need to make sure that this action is authorized by all applicable third-party licenses. If the export is authorized, only an OMI export guarantees the application of third-party licenses in the target Region, whereas a snapshot export does not.

  • To copy an OMI between accounts in the same Region, you can either use the export/import method above, or share the OMI with the other account, who then uses the copy-image method. For more information, see Copying an OMI Within One Region.

  • We strongly recommend using official OMIs. Shared or copied non-official OMIs can already have a root password or an embedded SSH. These are not deleted when you first launch an instance and add your keypair. You must check the /root/.ssh/authorized_keys file and only keep the last entry, which is the public part of your keypair.

  • When using a shared or copied non-official OMI for Windows, ensure that its creator performed a sysprep on the source instance before creating the OMI. Otherwise, instances created using this OMI do not work properly and are not supported. For more information, see the Windows Sysprep documentation.

  • Exporting an OMI to an OOS bucket also enables you to create a backup of this OMI, stored on OOS.

  • Copying an OMI to another Region enables you to create similar instances in different Regions to improve the availability of your applications.

  • If you want to use an OMI that does not belong to you, we strongly recommend to create your own copy of the OMI before creating your instances. When 3DS OUTSCALE updates its official OMIs, their ID is modified. For OMIs created by other users, the owner of an OMI may deregister it. If you use automation tools or scripts, this can compromise your deployment. Creating your own OMI based on the one shared with you before using it prevents these risks.

Related Pages