OpenStack instance migration using command line on CREODIAS

From time to time, a need arises to transfer the entire virtual machine to another host. Two typical scenarios for migrating machines are:

  • planned maintenance and

  • redistributing the load in case too many VM instances are running in one cloud.

Types of instance migration on OpenStack cloud

Migrating VMs is a fairly common task for administrators and there are two kinds:

Cold migration

Also known as non-live migration or simply migration. The instance is shut down, its processes are disrupted; it is then migrated to another OpenStack compute server and the machine is restarted.

Cold migration can be done in two ways:

  • SSH tunneling: the old and the new server can be accessed via SSH using the same access parameters. This is out of scope of this article so if interested, see the official document here.

  • Stop & Download the instance to a computer, then upload to another server. This is described in the continuation of this article.

Non-cold migration

Also called live migration. The processes within the instance may not be interrupted and the instance keeps on running during the migration.

Live migration is out of scope of this document so please have a look at the official document for live migration of OpenStack VMs.

What We Are Going To Do

  • Explain types of instance migration on OpenStack cloud

  • Download an instance from the origin

  • Create image for migration

  • Upload an instance to the destination

Prerequisites

No. 1 Account

You need a CREODIAS hosting account with access to the Horizon interface: https://horizon.cloudferro.com.

No. 2 Installed OpenStackClient for Linux

  • install Python,

  • create and activate a virtual environment, and then

  • connect to the cloud by downloading and activating a proper RC file from the CREODIAS cloud.

No. 3 Have ready credentials for both clouds

In this article, there are two clouds to consider:

The origin

The cloud you are downloading the instance from.

The destination

The cloud you are uploading the image to.

These two clouds may have different authentication procedures. There are four combinations, depending on the number of factors that need to be supplied:

No.

Origin

Destination

1

one-factor

one-factor

2

one-factor

two-factor

3

two-factor

one-factor

4

two-factor

two-factor

Article How to activate OpenStack CLI access to CREODIAS cloud using one- or two-factor authentication explains both types of authentication so apply as needed.

Download RC files from both clouds and they will naturally have different names. For instance, in combination No. 3, the name could be cloud_00734_1-openrc-2fa.sh as it has two-factor authentication, while the second file could be named cloud_00341_3-openrc.sh as it has one-factor authentication enabled on the account.

No. 4 General instructions for uploading image using CLI commands

The article How to upload your custom image using OpenStack CLI on CREODIAS describes the procedure to download an operating system image to the local computer and upload it to the chosen cloud. In this article, you are going to do the same except that the image you are migrating originates in your cloud and may contain your own specialized software.

That article is also more technical and also explains how to deal with errors that may happen in the process.

Note

Windows images can be migrated in this same fashion.

Downloading an instance

Activate the RC file for the origin, for example:

source ./cloud_00734_1-openrc-2fa.sh

List your instances:

openstack server list

The result will be similar to this output:

../_images/migratino_server_list.png

Let’s say that the instance you want to migrate has the id equal to 0cab85e2-4c11-4e6c-a837-e70f8289fd5d and that is what we use in this article. You be sure to read the appropriate ID value from server list and replace 0cab85e2-4c11-4e6c-a837-e70f8289fd5d with it in the rest of this article.

Shut off the instance:

openstack server stop 0cab85e2-4c11-4e6c-a837-e70f8289fd5d

There are two ways to check whether it is turned off. One is to execute the openstack server list command again and see the Status. If the server is stopped, the status should be SHUTOFF.

../_images/instance_shut_off.png

The other way is to show the server and print only its state:

openstack server show 0cab85e2-4c11-4e6c-a837-e70f8289fd5d | grep power_state

With this command, the status is Shutdown instead of SHUTOFF but the meaning is the same.

../_images/instance_shutoff_twice.png

Create image for the migration

The instance is stopped and you are now going to create its image in the cloud. The instance now has the ID of 0cab85e2-4c11-4e6c-a837-e70f8289fd5d but once it is migrated, it will have another ID. In order to track it on the new server, you will use the --name parameter to create a name for the instance. That name here is, simply: Migration image.

The command to create a named image is

openstack server image create --name "Migration image" 0cab85e2-4c11-4e6c-a837-e70f8289fd5d

Another way is command shelve. It creates a

  • proper image and

  • changes instance status to Shelved Offloaded.

openstack server shelve 0cab85e2-4c11-4e6c-a837-e70f8289fd5d

Regardless of which option is used, you need to check whether the new image was created properly.

openstack image list --private

Here is the result in this particular case:

../_images/image_created_for_migration.png

The image has the ID of 1fedb775-deef-4bfd-9ec2-ee67f65a461b so that is what you are going to use in the forthcoming commands.

The size cannot be 0 bytes and should have a similar size as the instance itself. Here is how to check the size:

openstack image show 1fedb775-deef-4bfd-9ec2-ee67f65a461b | grep min_disk

This is the result:

../_images/min_disk_instance_migration.png

Download newly created image to local disk. Its name will be image.raw and you may wait from a couple if minutes up to a couple of hours for it to download, depending on the speed of your Internet connection.

openstack image save --file ./image.raw 1fedb775-deef-4bfd-9ec2-ee67f65a461b

The image is ready. In order to move it to a different cloud, you will have to activate proper credentials for that cloud.

Uploading an instance

Open another terminal session and activate access to the destination cloud; using the example data from Prerequisite No. 3, the activate command could look like:

source ./cloud_00341_3-openrc.sh

Now all the openstack commands will work on the destination cloud.

Upload the image

openstack image create --file ./image.raw "Migration image"

This may take a while. You can follow up what is happening if you enter the Horizon environment and list all images with the commands Compute –> Images. Here is the beginning of the uploading process:

../_images/migration_image_upload.png

Once in the destination cloud, you can use it just like any other image.

Warning: always use the latest value of image id

From time to time, the default images of operating systems in the CREODIAS cloud are upgraded to the new versions. As a consequence, their image id will change. Let’s say that the image id for Ubuntu 20.04 LTS was 574fe1db-8099-4db4-a543-9e89526d20ae at the time of writing of this article. While working through the article, you would normally take the current value of image id, and would use it to replace 574fe1db-8099-4db4-a543-9e89526d20ae throughout the text.

Now, suppose you wanted to automate processes under OpenStack, perhaps using Heat, Terraform, Ansible or any other tool for OpenStack automation; if you use the value of 574fe1db-8099-4db4-a543-9e89526d20ae for image id, it would remain hardcoded and once this value gets changed during the upgrade, the automated process may stop to execute.

Warning

Make sure that your automation code is using the current value of an OS image id, not the hardcoded one.

What To Do Next

You can upload a downloaded image through Horizon as well:

How to upload custom image to CREODIAS cloud using OpenStack Horizon dashboard