Configuration¶
openstack-migrate receives a YAML configuration file that defines:
the source and destination cloud
credentials used to identify and migrate resources
internal Sqlite database location
timeouts
whether to preserve certain resource properties (e.g. volume types, availability zones, network segmentation IDs, MAC addresses, etc)
multi-tenant mode
The location of this file can be specified either using the
OPENSTACK_MIGRATE_CONFIG environment variable or through the --config
parameter.
Minimal sample¶
log_level: info
cloud_config_file: /home/ubuntu/cloud-config.yaml
source_cloud_name: source-admin
destination_cloud_name: destination-admin
database_file: /home/ubuntu/.local/share/openstack-migrate/sqlite.db
multitenant_mode: true
cloud_config_file is a standard OpenStack clouds yaml file that contains
Openstack credentials for the source and destination clouds. Here is an example:
clouds:
source-admin:
auth:
auth_url: https://public.source.local/openstack-keystone/v3
password: pwned
project_domain_name: admin_domain
project_name: admin
user_domain_name: admin_domain
username: admin
cacert: /home/ubuntu/sunbeam-ca/sunbeam-source-ca.pem
destination-admin:
auth:
auth_url: https://public.destination.local/openstack-keystone/v3
password: pwned
project_domain_name: admin_domain
project_name: admin
user_domain_name: admin_domain
username: admin
cacert: /home/ubuntu/sunbeam-ca/sunbeam-destination-ca.pem
Cloud configurations¶
We are uploading the Cinder volumes to Glance in order to retrieve the data. On the source cloud, Cinder must be configured with enable_force_upload = True in order to upload attached volumes.
As we are uploading the Cinder volumes and Nova instance root disks to Glance, the Glance services on both clouds must have the image_size_cap config option set to a high enough value to accommodate these migrations (default value: 1 TB).
Options¶
This section describes each of the available options.
log_level¶
stringdebug, info, warning, errorinfolog_dir¶
stringnullopenstack-migrate invocation. Log files have the following format:openstack-migrate-%Y%m%d-%H%M%S.%f.log.log_console¶
booleantruecloud_config_file¶
stringnullsource_cloud_name¶
stringnulldestination_cloud_name¶
stringnulldatabase_file¶
string$HOME/.local/share/openstack-migrate/sqlite.dbopenstack-migrate will create the directory automatically if missing.temporary_migration_dir¶
string$HOME/.local/share/openstack-migrate/migration_dirmultitenant_mode¶
booleantrue--include-dependencies is set.image_transfer_chunk_size¶
integer33554432 (32MB)volume_upload_timeout¶
integer1800 (30 minutes)resource_creation_timeout¶
integer300 (5 minutes)preserve_volume_type¶
booleanfalsefalse for increased compatibility. If enabled, the volume types will be migrated and used when transferring volumes. Manually created types may be registered using the register-external command.preserve_volume_availability_zone¶
booleanfalsepreserve_instance_availability_zone¶
booleanfalsepreserve_load_balancer_availability_zone¶
booleanfalsepreserve_network_segmentation_id¶
booleanfalsepreserve_port_mac_address¶
booleanfalsepreserve_port_floating_ip¶
booleanfalsepreserve_port_floating_ip_address¶
booleantruepreserve_port_fixed_ips¶
booleantruepreserve_router_ip¶
booleantruemanila_local_access_ip¶
stringnullIf unspecified, it will be automatically determined based on the host routes. When migrating shares, openstack-migrate transparently handles shares access rules in order to be able to mount the shares and transfer data.
member_role_name¶
stringmemberWhen migrating certain resources to other tenants (e.g. instances, volumes or shares), we need to a project scoped session using the destination project.
openstack-migrate will transparently assign the member role to the user that initiated the migration.