Migrating Instances with legacy Flavors

Migrating Instances with legacy Flavors

Introduction

History: When the Nectar cloud was launched in 2010 with an initial set of flavors (“m1”).  These were specified based on some assumptions about how people would use cloud resources.  It turned out that these assumptions were (on average) incorrect, so a second set of flavors (“m2”) was added in 20xx with changes aimed at improving the efficiency of resource utilization.  In 2019, more sets of flavors (“m3”, “c3”, “r3” and “t3”) were introduced, and it was decided by Nectar and the Nodes to gradually phase out the “m1” and “m2” flavors and their instances.  

As of July 2020, the ability to launch new instances with the legacy “m1” and “m2” flavors has withdrawn.  This is in line with the goal of phasing them out.  This means that when you migrate an instance with a legacy flavor (by the normal snapshot and relaunch procedure), you will also need to choose a new flavor. In many cases, this should be non-problematic.  However there are two areas of potential concern:

• If you made significant use of the ephemeral file system available on “m1” and some “m2” flavors, you may need to find an alternative. Generation 3 flavors do not support an ephemeral file system.  The alternatives are:

  • Make use of the fact that the root file system on (most) generation 3 flavors is 30 GB (compared to 10GB on “m1” flavors).

  • Move the files in the ephemeral file system to Volume Storage.  This may entail requesting Volume Storage quota in the AZ that you are migrating to.

• If your applications relied on the “generous” RAM to VCPU ratio offered by an “m1” instance, you may need to use an “r3” flavor.  Your allocation request form would need to request access to “RAM enhanced” flavors. 

The Nectar Flavors article lists the public Nectar flavors (“m3”, “c3”, “r3” and “t3”) as well as the legacy flavors, and describes their main characteristics. You should read it and work out the most appropriate flavor or flavors for the migrated instance.  (We would strongly encourage you to consider “downsizing” to a flavor with less resources … especially if you don’t use the instance intensively.)

Checking your ephemeral file system

You may not be sure if your existing instance has an ephemeral file system, or if you are actually using it.  The former question is easy to answer assuming that you are using a public legacy flavor:

• All “m1” flavors, along with “m2.large” and “m2.xlarge” have ephemeral file systems.

• Other “m2” flavors do not have ephemeral file systems.

You can confirm this in a round-about way by looking at the output of the “lsblk”.  The output will show all of the “vd” (virtual disk) devices; i.e. “vda”, “vdb”, and so on.  The first one (“vda”) will be the root file system, and the others will be either ephemeral file systems or attached Volume Storage volumes.  So if the total number of “vd” devices in the output from “lsblk” is more than the number of attached volumes plus one (for the root file system), then the other discrepancy is likely to be an ephemeral volume.

Having determined that you have an ephemeral volume, you need to check if it is being used.  An ephemeral file system is usually mounted on the “/mnt” directory, but you can confirm this from the output of “df -k”.  Then it is a matter of looking in the “/mnt” directory to see if there is anything of importance.  

Note: if you see a “lost+found” directory in “/mnt”, it was probably created by the file system checker / recovery utility.  It may contain files that were disconnected from the file system tree.  You can probably ignore this directory and its contents.

Quotas

The migration procedure for an instance with a legacy flavor needs sufficient VCPU and Instance quota to allow you to run the old and new instance at the same time. This is for safety.  So you need to decide what the new flavors need to be, and count the instances and VCPUs required. Please ask for a temporary increase in Instance quota or VCPU quota if you need it.

In addition:

• If you are currently relying on the extra file space afforded by the ephemeral file system on your instance, and you need to replace it with volume storage, then you will need sufficient Volume Storage quota in the AZ that you are migrating to.

• The old m1 flavors had more RAM per VCPU than the regular m3 flavors.  If you (really) need the extra memory, you should to request access to RAM enhanced (r3)flavors on the Allocation request form.

Migrating without an ephemeral file system

If your existing m1 or m2 instance has no ephemeral file system, OR if you have confirmed that are not using the ephemeral file system, then you can migrate the instance as if it was a normal instance; see Migrating an normal instance.

The only difference between this migration and a “normal” instance migration is that you need to choose a new flavor.

Migrating with an ephemeral file system

The tutorial can be viewed here.