Skip to content

Background

Images, flavours and instances

An instance is a virtual machine built from two choices: an image, which decides what it runs, and a flavour, which decides how big it is. Add a network and a disk, and you have something you can sign in to.

The three pieces

Piece What it is On a traditional virtualization platform
Image A disk template: an operating system ready to boot, sometimes with software added A virtual machine template or golden image
Flavour A fixed size: number of vCPUs and amount of RAM The CPU and memory settings on a virtual machine, picked from a menu instead of typed in
Instance A running virtual machine made from an image and a flavour The virtual machine

The menu of flavours is the main change from a traditional platform. Instead of setting any combination of CPU and memory, you choose from a set of sizes. That keeps capacity planning simple for the platform and makes sizes easy to compare and change.

How they combine

When you launch an instance:

  1. You choose an image, a flavour, a network, security groups and a key pair, plus optional user data.
  2. The platform finds a host with room for the flavour.
  3. It creates the instance's root volume from the image.
  4. The instance boots, and a first-boot agent inside it sets up access and runs your user data.

Images

Public and custom images

  • Public images are provided by Breqwatr and shared with every project. You launch from them but can't change them.
  • Custom images are your own. You can upload an image, or snapshot an instance to capture it as an image. Custom images are private to the project.
  • Windows Server images are available to every project, priced to include the licence. Other licensed operating systems, such as Red Hat Enterprise Linux, are provided on request.

First boot on Windows and Linux

Both operating systems use a first-boot agent that reads instructions from the platform when an instance starts for the first time.

Windows Linux
First-boot agent cloudbase-init cloud-init
Access set up at first boot The Administrator password, which you set on the instance's console at first boot Your SSH public key, added to the image's default user
User data it runs A PowerShell script A shell script or a cloud-config file
How you sign in RDP SSH

Breqwatr's Windows images use cloudbase-init. User data that installs a web server looks like this:

#!/bin/bash
apt-get update
apt-get install -y nginx

#ps1_sysnative
Install-WindowsFeature -Name Web-Server -IncludeManagementTools

The first line tells the agent how to run the script: #!/bin/bash for cloud-init, #ps1_sysnative for cloudbase-init.

Flavours

A flavour sets an instance's vCPUs and RAM. On Breqwatr Cloud flavours carry no disk; the root volume's size is chosen separately, at launch.

Flavour names follow the pattern v1.cXrY: c is the number of vCPUs and r is the RAM in GB. Flavours with GPUs add g and the number of GPUs. So v1.c4r8 has 4 vCPUs and 8 GB of RAM, and v1.c12r24g1 has 12 vCPUs, 24 GB of RAM and one GPU.

The launch form in the Breqwatr Cloud Portal (Strata) lists every flavour your project can use, with its vCPUs and RAM. From the CLI, openstack flavor list shows the same list.

Choosing a flavour:

  • Start with the smallest that fits. A flavour can be changed later by resizing the instance, so a first choice doesn't have to be final.
  • Size for today's load. When load grows, a larger flavour or more instances can follow it. See What makes it cloud.
  • Billing follows the size. An instance is priced by its memory, by the hour; its vCPUs carry no charge. See the pricing page.

The root disk is a volume

Every instance on Breqwatr Cloud boots from a volume. Flavours carry no disk of their own, so the root disk is always a block storage volume created from the image at the size you choose.

Root volume
Created From the image, at launch, at the size you choose
When the instance is deleted Deleted with it from the portal; deleted or kept, as you choose, from the CLI or OpenTofu
Growing it Extend the volume
Reusing it Attach a kept volume to a new instance

Deleting an instance in the portal also deletes its root volume. To keep the root volume, launch and delete the instance from the CLI or OpenTofu, with delete_on_termination=false on the root volume. Keeping data on separate volumes, rather than on the root volume, keeps an instance easy to replace. Storage types covers block storage in more detail.

Instance snapshots and the root volume

In the portal, an instance's Snapshot action makes a volume snapshot of its boot volume, listed under Snapshots. To restore from it, choose Create volume on the snapshot's row. The instance snapshots described below are made from the CLI.

An instance snapshot of a volume-backed instance also snapshots its volumes. The snapshot image points at those volume snapshots, and a volume can't be deleted while a snapshot of it exists. So if an instance has an instance snapshot, its root volume can remain after the instance is deleted, even with the delete option on, and it keeps being billed.

The root volume stays for as long as the instance snapshot needs it. When you no longer need the snapshot, remove all three:

  1. Find the volume: it's in the project's volume list with the status available, attached to nothing.
  2. Delete the instance snapshot image.
  3. Delete the volume snapshots made with it. Each is named "snapshot for" followed by the image name.
  4. Delete the volume.

From the CLI:

openstack --os-cloud <cloud-name> volume list --status available
openstack --os-cloud <cloud-name> volume snapshot list --volume <volume-id>
openstack --os-cloud <cloud-name> image delete <snapshot-image-name>
openstack --os-cloud <cloud-name> volume snapshot delete <volume-snapshot-id>
openstack --os-cloud <cloud-name> volume delete <volume-id>

Impact

  • Launching a new instance takes a few choices from a menu, not a build process.
  • The same image and flavour give the same instance every time, which is what makes rebuilding predictable.
  • Changing size is a resize or a rebuild on a new flavour, not a hardware upgrade.

Common anti-patterns

  • Images with no recipe: a custom image changed by hand over time, with no record of how it was built. It can't be rebuilt when its operating system needs updating.
  • Secrets in images: passwords or keys baked into an image are shared with every instance launched from it. Supply them at first boot instead.
  • Oversized by default: choosing a large flavour "to be safe" and never reviewing it.
  • The only copy on the root volume: data on a root volume that is deleted with the instance goes with it.
  • Forgotten instance snapshots: an old instance snapshot keeps the root volume of a deleted instance, and both stay on the invoice.

Further reading