Mirantis OpenStack Express 2.0 – Creating New VM Flavors

This is the fifth in a series of short tutorials showing how to perform common cloud operations tasks in Mirantis OpenStack Express 2.0 – Mirantis’ “Private Cloud as a Service”

In our last tutorial, we looked at attaching block storage volumes. Now we’ll take a look at flavors, which are VM templates, used to def

In our last tutorial, we looked at attaching block storage volumes. Now we’ll take a look at flavors, which are VM templates, used to define instances at launch.

 

 

Basic Ops Tutorials

Mirantis OpenStack Express 2.0 — Mirantis’ “Private Cloud as a Service” — is the fastest way to get your hands on a fully-functional, optimally-configured, private OpenStack cloud, running on hosted bare metal and able to scale on demand. This series of short tutorials shows how to perform common cloud operations tasks in MOX 2.0, and offers links to documentation and learning resources. Pro tip: though aimed at Mirantis OpenStack Express, many of the techniques discussed here will also work on a private OpenStack cloud deployed using Mirantis OpenStack.

Tutorials:

 

Step by Step

Mirantis OpenStack Express lets you define flavors from the Admin menu.

As you can see from the illustration, OpenStack defines five standard machine flavors for you, ranging from an m1.tiny model with 1 vCPU, 512MB RAM and a 1GB root disk, to an m1.xlarge with eight virtual processors, 16GB RAM and a 160GB disk.

Mirantis OpenStack Express 2.0 lets you create custom flavors: templates for defining the VMs in which you can launch images. Five basic flavors are predefined: from an m1.tiny minimal machine, to a m1.xlarge multiprocessor VM with lots of RAM and hard disk.

These are useful for many straightforward applications. But a little imagination can show why having the ability to add custom flavors can be important.

Suppose you want to create a platform for an application that needs lots of compute, RAM and scratch space while it’s running, but doesn’t need to maintain stored data once an instance is terminated. Data-analysis, media transcoding, bioinformatic apps might fit this profile.

You can use flavors to create a new machine type for this hypothetical application. Click Create New Flavor, and give it a name — let’s call it m1.amnesia-engine.

To create a new flavor, state your requirements in the dialog. Here, we’re defining a flavor called “m1.amnesia-engine” — a multiprocessor machine with lots of RAM, but no root or swap space in volumes. Instead, we’re giving our flavor 50GB of ephemeral storage, which will vanish if an instance created with this flavor is terminated. This hypothetical flavor might be useful for highly-parallelized data analysis.

We’ll give it 8 multi-core vCPUs so it can run all our vectorized code. 16GB of RAM, so it has plenty of room to work in. We’ll give it no root disk, and no swap disk. But we’ll give it 50GB of Ephemeral disk, which is a block file storage entity that survives restarts, but goes away when an instance is terminated: exactly what we want. This storage will be attached to /dev/vdb of an instance launched with this flavor template, and our app will need to quickly make a file system there and mount the device to use it.

On the second tab of the Create Flavor dialog, we can associate this flavor just with certain projects running on our cloud — a good thing if you want to keep exotic VM formats restricted. In this case, though, we’ll leave this blank so the flavor is available to all.

The second tab of the Create Flavor dialog lets you privilege only certain projects to use your new flavor.

Our new flavor now appears in the list. The system has assigned an ID to it.

Now we’ll launch a boot image with our new flavor. First, let’s try to launch using the CirrosVM image we created several lessons back. As you may recall, when we imported this image, we set a minimum root disk size of 2GB. OpenStack sees this, and will not let us apply our amnesia-engine flavor to this image: an important protection against launching things that will not work.

OpenStack will stop us from trying launching an image whose requirements don’t match those of the flavor we wish to assign to it. We’ll assign different requirements to images we create, based on OS, version and configuration.

Now let’s try launching an amnesia-engine machine using an image with no minimum root disk requirement set. We name it, we pick our new flavor, and OpenStack approves: showing us the configuration of the instance we’re about to launch. Set authentication and network parameters, and go.

Here, a CirrOS image with no minimum root disk requirement set is an acceptable match for our m1.amnesia-engine flavor, which uses only Ephemeral storage.

There’s our AmnesiaEngine, ready for work. Log in with the Console …

And we can execute a cat /proc/cpuinfo command to see all of the many processors we have available.

Visiting our new VM in Console, we can see that the flavor has resulted in our launching an eight-processor machine.

A sudo fdisk -l command shows us the 50GB Ephemeral disk this flavor comes with, ready for partitioning, file system creation and usage.

And we can see that our Ephemeral storage has been made accessible, on /dev/vdb, ready for partitioning and other operations before use. Since this is Ephemeral storage, our application will need to prepare its volume this way, each time it starts.

Now that we’ve explored flavors, our next tutorial will cover higher-level administrative tools for creating Projects and adding Users.

 

Resources:

Check out Express for yourself at https://express.mirantis.com.

Latest Tweets

Suggested Content

WEBINAR
Edge Computing: A Unified Infrastructure for All the Different Pieces