Migrating (CMaaS) to OpenStack
Migrations to OpenStack operate in the same way Replicas do and thus entail the same requirements and steps described below.
Replicating (DRaaS) to OpenStack
Replica executions:
Steps performed by Coriolis:
- if this is the first replica execution for the VM, create empty Cinder volumes on the destination cloud, each matching the specifications of a disk the VM had on the source.
If this is a later replica execution, the previously created Cinder volumes are used - if this is the first replica execution of the VM, create a new live snapshot of the disks of the VM on the source cloud (handled by whatever source cloud plugin we are using).
If this is a later replica execution, create a new live snapshot based on the one from the last successful replica execution - create a temporary Linux worker VM in Nova (the “disk copy worker”) on the destination cloud and attach the Cinder volumes from Step 1 to it
- read the contents of the snapshot created at step 2 via the source platform’s snapshot/backup APIs (handled by whatever source cloud plugin we are using), transferring the written chunks to the temporary VM created in step 3, which then writes the chunks at the appropriate index/offset of the disks created at step 1
- once the contents of all the disks have been synced to the Cinder volumes created in Step 1, detach the Cinder volumes and delete the disk copy worker created in Step 3
Replica deployments:
Steps performed by Coriolis:
- create snapshots of the replicated Cinder volumes on the destination cloud to be able to roll back any changes. By default, new volumes are created from these snapshots, leaving the original replica volumes intact for future replica executions
- depending on the OS of the VM whose replica is being deployed, boot a temporary worker VM (“the OSMorphing worker”) with the same OS type on the destination cloud, and attach the Cinder volumes from step 1 to it
- perform the “OSMorphing process”, where Coriolis commands the OSMorphing worker created in step 2 to scan all attached disks for the OS installation of the VM we are migrating, mount, and perform the steps needed to prepare the installation for the new platform (ex: uninstalling the VMWare guest tools and installing VirtIO drivers if deploying a replica of a Windows VM from vSphere to a KVM-based OpenStack)
- detach the Cinder volumes created at step 1 from the OSMorphing worker created at step 2 and delete the temporary worker VM
- create and boot the migrated VM on the destination cloud with the specifications of the original VM on the source cloud (which have been noted during the particular replica execution we are deploying), creating and attaching any necessary Neutron ports and Cinder volumes.
Configuration Options
Advanced Target options for OpenStack target destination
In the case of Replicating or Migrating to OpenStack, there will need to be images that the worker will use to create temporary VMs to perform the tasks, for both Linux and Windows machines.
The template OS version must be at least the same as the OS of the VM that needs to be migrated.
NOTE! When Replicating/Migrating a Windows VM, both Linux and Windows templates have to be specified, as Disk cloning is performed using the Linux template and OSMorphing is performed using the Windows template.
In case a Floating IP Pool network is not visible to be selected, it can mean that the network resides under another tenant project. To overcome this, you must enable the “List All Destination Networks“.
The Floating IP Pool network must also carry the “router:external” property set, on the OpenStack side.
OSMorphing steps taken when migrating/replicating to OpenStack
Depending on the virtualization technology used and the OS release we are migrating/replicating, the following notable steps will be performed as part of the OSMorphing process:
Linux:
- installing cloud-init
- installing Hyper-V integration tools, if destination OpenStack is based on Hyper-V
- where required, rebuilding initrd to add the virtIO drivers
Windows:
- installing cloudbase-init and enabling cloudbase-init service
- installing the VirtIO drivers if OpenStack is KVM-based
For more information regarding the Coriolis Worker template, please check the Coriolis Temporary Migration Worker page.
Preserve network settings for migrated VM
When migrating to OpenStack, Coriolis features the capability to preserve the network configuration of the migrated VM(s). This applies to scenarios such as statically assigned IPs and stretched networks for the source and target clouds.
OpenStack’s networking model relies on the VMs being internally configured to use DHCP, thus the following set of options are to be used when creating the Migration/Replica:
– “Set DHCP” = True — will have Coriolis reconfigure the VM internally to use DHCP on all interfaces
– “Preserve Fixed IPs” = True — will have Coriolis set the same IP address the source VM had on the Neutron port(s) of the final target VM on OpenStack
In combination, the above two options will lead to Coriolis setting the same IP address(es) the VM had on the source vSphere to the Neutron ports of the migrated VM on the target OpenStack, which Neutron will in turn set via DHCP in the final migrated VM, leading to the effect of “static IPs being preserved” when it’s handled via DHCP behind the scenes.
In the case of VMware as a source platform, the to-be migrated VM(s) must have the VMware guest tools installed and the VMware agent running, so that Coriolis can identify the network settings / IPs on the source VM.
Note that the “Preserve Fixed IPs” option requires that the subnet(s) on the Neutron network(s) you set in the “Network Mapping” screen have the following properties:
– the Neutron network(s) you select must contain a Neutron subnet whose IP range includes the IP address(es) of the source VM
– said Neutron subnet which includes the IPs needs to have the “dhcp” flag enabled on it
Configuration options for OpenStack as a destination
Below is a listing of the configuration section needed when migrating/replicating to an OpenStack:
OpenStack destination environment parameters
The destination environment parameters are a set of destination-cloud-specific parameters that offer additional options to the migration/replication process on a per-VM basis.
Below is a listing of the destination environment parameters the OpenStack plugin supports when migrating/replicating a VM to OpenStack:
Example of destination environment JSON to be passed to the OpenStack plugin
Each parameter represents:
- network_map (string-string mapping) – a mapping between the names of networks on the source cloud and names or IDs of corresponding pre-existing networks on the destination Openstack. For each NIC of the instance on the source cloud, Coriolis will look at the mapped network on the destination OpenStack and ensure the Neutron port corresponding to that NIC is attached to that Neutron network
- storage_mappings (object) – storage-related options such as how to map each disk or storage type on the source to Cinder volume types on OpenStack
- hypervisor_type (string) – the type of hypervisor the destination OpenStack features, supported options being “hyperv”, “qemu” or “kvm”
- flavor_name (string) – name of pre-existing Nova flavor on the destination OpenStack for the migrated/replicated instance to be booted as
- keypair_name (string) – name of a pre-existing Nova keypair to be injected into the migrated/replicated instance on the destination cloud
- delete_disks_on_vm_termination (boolean) – whether or not to set the Cinder volumes as ephemeral (to be deleted when the VM is deleted) on the newly migrated/replicated instance on the destination OpenStack.
- security_groups (list of strings) – list of names or IDs of pre-existing security groups on the destination OpenStack to be applied to the migrated/replicated instance
- migr_image (string) – name or ID of the pre-existing Glance image to be used for the disk copy and/or OSMorphing workers. The name must be unique in the destination cloud. Overrides the settings in ‘migr_image_map’
- migr_image_map (string-string mapping) – if migrating/replicating a heterogeneous workload with both Linux and Windows instances, separate image names/IDs will need to be provided for the temporary OSMorphing workers for each OS. The only accepted keys are ‘linux’ and ‘windows’. Please review the “OSMorphing worker images” section for exact details on the requirements of the worker images for each OS type
- migr_network (string) – name of an existing Neutron network one the destination OpenStack to which to attach the Neutron port of the temporary disk copy/OSMorphing worker VMs
- migr_worker_use_fip (boolean) – whether or not to allocate floating IP addresses from the “migr_fip_pool_name” for the temporary disk copy/OSMorphing worker VMs
- migr_fip_pool_name (string) – name of an existing Neutron network and an associated subnet(optional) on the destination OpenStack which serves as external and may have floating IPs allocated from it. These floating IPs will be associated with the temporary disk copy/OSMorphing worker VMs Coriolis will be creating during the migration/replication process
- migr_flavor_name (string) – name of an existing Nova flavor to boot the temporary disk copy/OSMorphing worker VMs as
- migr_worker_boot_from_volume (boolean) – Whether or not to download the worker image to a Cinder volume and boot the worker from that.
- migr_worker_volume_size (integer) – The integer size (in GBs) of the Cinder volume to boot temporary worker VMs from. This option is only effective if ‘migr_worker_boot_from_volume’ is set. If not set, Coriolis will use the disk size set for the selected ‘migr_flavor_name’.
- migr_worker_volume_type (string) – Name of the pre-created Cinder volume type to use when creating temporary worker volumes. This option is only effective if the ‘Migration Worker Boot From Volume’ is set.
- migr_worker_use_config_drive (boolean) – whether or not to use config drive to send metadata to the temporary disk copy/OSMorphing worker VMs in case Neutron metadata is not available
- port_reuse_policy (string, valid values are “keep_mac”, “replace_mac” and “reuse_ports”) – sets what Coriolis should do if it encounters an existing Neutron port with a MAC address needed for the instance it is migrating/replicating. If set to ‘keep_mac’, Coriolis will delete the existing ports and recreate them with the same MAC address for the new VM. If set to “replace_mac”, Coriolis will create new Neutron ports with different MAC addresses. If set to ‘reuse_ports’, Coriolis will try to reuse the existing ports it has found for the new migrated/replicated instance.
- list_all_destination_networks (boolean) – whether or not to list all networks. By default, Coriolis will only list the networks that are in the same tenant as the one set in the Coriolis endpoint.
- volumes_are_zeroed (boolean) – whether unallocated blocks on Cinder target volumes contain zeros on creation. This is controlled by the “volume_clear” option in Cinder’s configuration file
- set_dhcp (boolean) – whether or not to reconfigure the internal network settings of each interface of the instance being migrated/replicated during the OSMorphing process to have the VM perform DHCP on first boot inside the new environment.
- preserve_fixed_ips (boolean) – Whether or not to preserve the fixed IPs of the migrated instances’ Neutron ports.
- server_group (string) – Name or ID of the Nova Server Group to use when recreating the final VMs on OpenStack.
- use_floating_ip (boolean) – Whether or not to attach a floating IP to the already migrated VM.
- floating_ip_pool (string) – Name of the floating IP pool and an associated subnet(optional) to be used for the creation and attachment of floating IPs to the migrated VMs.
- instance_tags (object) – Dictionary with arbitrary key-value pairs to set as tags on the migrated/replicated VMs.
Most destination environment parameters can also be found in the global configuration section, in which case they may be overridden on a per-migration/replica basis by setting them in the destination environment as well.