This is the first of a series of posts exploring the CloudFerry OpenStack migration tool in depth.

Table of Contents

The challenges in OpenStack Migration

Introduction to CloudFerry

Typical Migration Flow

Migration Scenarios

Configuration Options and Limitations

The Challenges in OpenStack Migration

The use case of Openstack C2C migration comes for an organization when their existing OpenStack cloud is running an older release and they want to upgrade.

In an Openstack cloud environment we can have many tenants with their corresponding workloads & resources. When the need arises to move these tenants, workloads & resources from one cloud environment to another, doing so manually is a cumbersome task which is risky.

As of now OpenStack doesn’t provide a direct software upgrade path, this is exactly where CloudFerry comes into picture.

Introduction to CloudFerry

CloudFerry is an open-source tool developed by Mirantis which automates resources and workload migration between OpenStack clouds with low risk & good speed.

Note: A “workload” is a virtual machine & all the resources that were used to create it.

Current Version of CloudFerry: 1.54

Supported OpenStack Releases

Grizzly

Icehouse

Juno

Objects Supported for Migration

Openstack Service Corresponding Objects Keystone Tenants

User roles Neutron Networks Private Public Shared

Subnets

Ports

Floating IPs

Security groups

Routers

LBaaS objects

Quotas Glance Images Cinder Volumes

Quotas Nova VMs

VM’s ephemeral storage

Flavors

User quotas

Tenant quotas

Key pairs

CloudFerry works via SSH/SCP, MySQL transactions and OpenStack API calls.

Typical Migration Flow



Image Credit : Linked from the CloudFerry documentation.

There are 3 stages that a typical migration flow is composed of:

Condensation: Condensation is determining the number of physical nodes that can be freed up and moved to the destination cloud.

Evacuation: Evacuation is getting the source cloud workloads onto as few nodes as possible.

Migration of Workloads: Once condensation & evacuation are done, we can move the freed up physical nodes to the destination cloud and start migrating workloads into the new cloud to use the migrated hardware.

In case of failed migration CloudFerry rolls back the destination cloud state to the initial state that was there before migration. The amount of time it takes for any kind of migration, depends upon the speed of the network & the amount of workload to be migrated.

Artifacts in a migration

Pre-requisites CloudFerry installation Main config Scenario file

Pre-requisites

From the host where CloudFerry is installed there should be network connection to source and destination clouds through their external (public) network.

Should be able to have admin access to keystone (typically admin access point lives on 35357 port).

A valid private ssh-key for both clouds which will be used by CloudFerry for data transfer.

sudo/root access on compute & controller nodes is needed from CloudFerry host.

Openstack MySQL DB write access for CloudFerry Machine.

Credentials of global cloud admin of both clouds are needed.

requirements.txt has all the Python requirements listed in it.

CloudFerry Installation

The documentation recommends installing CloudFerry as follows

$ pip install git+git://github.com/MirantisWorkloadMobility/CloudFerry.git 1 $ pip install git + git : //github.com/MirantisWorkloadMobility/CloudFerry.git

I’ve faced issues installing CloudFerry using above method on fresh Ubuntu 14.04 machine. I was able to come up with some other steps for its installation with the help of the following docker file from CloudFerry’s Github repository.

$ apt-get install build-essential libssl-dev libffi-dev python-dev sqlite -y $ wget https://bootstrap.pypa.io/get-pip.py $ python get-pip.py $ pip install git+git://github.com/MirantisWorkloadMobility/CloudFerry.git # see list of available commands $ cloudferry --help 1 2 3 4 5 6 $ apt - get install build - essential libssl - dev libffi - dev python - dev sqlite - y $ wget https : //bootstrap.pypa.io/get-pip.py $ python get - pip . py $ pip install git + git : //github.com/MirantisWorkloadMobility/CloudFerry.git # see list of available commands $ cloudferry -- help

Main Configuration

To generate the main config file, use the following command

$ oslo-config-generator --namespace cloudferry | tee configuration.ini 1 $ oslo - config - generator -- namespace cloudferry | tee configuration . ini

Migration Scenarios



We have different types of migration scenarios available which we can choose under migration section of our main configuration file. Each scenario has a corresponding file with the steps involved for that scenario. These files are provided with CloudFerry itself and the correct file path should be mentioned in the main config file depending on the scenario. The scenarios are:

Cold Migration [scenario/cold_migrate.yaml] Resources Migration [scenario/migrate_resources.yaml] Migrate VMs: Instances Migration [scenario/migrate_vms.yaml]

Cold Migration

Cold Migration does the migration of both resources & instances migration, at first it migrates resources and then migrates instances. Any instances during the cold migration will be brought down before migration.

Resources Migration

Under Resources Migration scenario we can migrate all the objects supported by CloudFerry. We cannot migrate instances under this scenario.

Migrate VMs

As the name suggest we use this scenario to migrate instances/VMs. Under this scenario CloudFerry expects the networks which are used by instances in source cloud to be present in destination cloud.If the network used by an instance of source cloud is present in destination, it’ll migrate it. Whereas if the network used by an instance of source cloud is not present in destination, it won’t migrate it. As a workaround if you try to change the option:“keep_ip=no” it’ll be of no use. So it is suggested to use resources migration scenario first, before using this scenario.

While migrating the VMs/Instances their respective glance images are also migrated.

Rollback issues of the migrate_vms.yaml scenario



When the migration fails under this scenario, the rollback to the initial state of destination cloud is not proper i.e, the glance images that are migrated from source to destination cloud are not removed or rolled back.

If you are migrating two instances of two different networks of which only one same network is present in destination, the migration fails. As discussed earlier, we are supposed to have same networks in the destination cloud under this scenario but the rollback is not proper i.e, the instance with same network on both sides will be migrated, while the other instance won’t but as part of rollback the migrated instance is not removed.

Some Configuration Options and Limitations

Important Options in the configuration file

Under the [migrate] section:

migrate_whole_cloud = Value 1 migrate_whole_cloud = Value

To Migrate the whole cloud, we can use this option. The values are “True/False”

When the value is “True”, whole cloud will be migrated despite the filter config file is specified;When the value is “False”, (default value), migration of resources and instances happens according to the filter config file.

filter_path = configs/filter.yaml 1 filter_path = configs / filter . yaml

The above option is the path to a config file which allows specifying tenant, instance, or other OpenStack object to be migrated.

keep_ip=yes 1 keep_ip = yes

for holding on to the same fixed IP of the instance as in source cloud.

keep_floatingip=yes 1 keep_floatingip = yes

for holding on to the same floating IP of the instance as in source cloud.

While there are other important options too, but these are some options which are basic for a successful migration

Limitations of the current version of CloudFerry

Live migration is not supported as of now. LVM cinder backend is not supported, only NFS and iSCSI VMAX are supported. CloudFerry has CLI option for version2 API which is still under development and is not ready for use. It can be invoked by