Migrating Instances with legacy Flavors
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.
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.
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 following procedure can be used if your existing m1 or m2 instance has an ephemeral file system, AND you need to keep the data in it.
Back up your files. You should already have a procedure for making regular backups of your valuable files held on your instances and attached storage. Before you start the migration, make sure that your backups are up to date.
Take your instance out of normal service. You are in the best position to know what this will entail.
Unmount and detach any volumes from the instance. These will need to be migrated separately; see “Migrating a volume”.
Shut down the instance.
Snapshot the instance. You should verify that the snapshot has been successfully uploaded to the Image catalog.
Launch new instance from snapshot in target AZ. If you run into the “No valid hosts found” issue, you could try using a smaller flavor for the new instance, either temporarily (and resize later) or permanently. Alternatively raise a support ticket.
If you have decided that you need a volume to replace the ephemeral file system:
Format the volume and mount it.
Restart the old instance, but do not restart user-facing services.
Use rsync to copy the files from the old instance’s ephemeral file system to the new instance. The target location for the copied files on the new instance is up to you. Depending on the circumstances, you could copy some or all of the files into the new instance’s root file system.
Shutdown the old instance once more.
Attach any other migrated volumes. After attaching the volumes, you should verify that the device names (“vdb”, “vdc”, etcetera) for the volumes are as expected and then mount the volumes’ file systems.
Verify the correct operation of the new instance. You are in the best position to know what this will entail.
Restore the instance to service. You are in the best position to know what this will entail.
Wait. It is advisable to keep the old volume for a few days in case it is needed to roll back the migration.