About Coriolis

Coriolis® is a fully distributed and scalable system that provides both “lift-and-shift” migration services (CMaaS) and cross-site disaster recovery features (DRaaS) between a source cloud platform and an independent destination cloud platform.

Coriolis operates without needing agents to be installed on the guest VM, relying only on the public APIs exposed by the cloud platforms to query the compute and network-related parameters of the VMs and perform data transfers. For physical to virtual (p2v) migrations, an agent must be installed on the bare-metal server.

Coriolis has two distinct modes of operation: a one-off ‘move’ of an instance from one platform to another (“migrations”), and continuous background sync between the state of a VM on a source cloud to storage elements on the destination cloud which are ready to deploy in case of a source-side fault (“replicas”).

Replicas (DRaaS)

Replicas are continuous background sync of a running workload’s storage from a source cloud directly to a destination cloud (“executing a replica”), and the ability to create a new VM on the destination cloud with the synced storage elements should disaster strike on the source (“deploying a replica”).

Migrations (CMaaS)

Migrations represent “lift-and-shift” operations, where the goal is to copy the storage of an existing instance on the source cloud to the destination cloud and boot a new instance with identical settings.

For more information regarding Coriolis’ Replica and Migration Architecture check Coriolis’ Architecture page.

About this guide

In this guide, you will go through the initial Coriolis setup, configure the source and destination endpoints, and run a Replica Execution and Deployment as quickly as possible.

The guide details Coriolis’s main features and capabilities, allowing you to evaluate all features.

System Requirements

The Coriolis virtual appliance can be easily deployed as a virtual machine (VM) in any virtualization environment that meets the following minimum system requirements:

• 40GB storage for the virtual disk of the appliance
• 4 vCPU cores
• 8GB RAM
• One or more network interfaces for access to the APIs of the source and destination environments

It is important to note that these requirements are suitable for a proof-of-concept or small test lab only. To ensure proper performance in a production environment, a compatibility assessment should be performed to determine the appropriate resource sizing for the Coriolis virtual appliance.

Coriolis is designed to meet the specific needs of each migration or disaster recovery implementation and can be easily scaled out both horizontally and vertically, to accommodate increasing workloads. In the case of multiple parallel and simultaneous Replica or Migration jobs, additional Coriolis worker systems can be deployed for large-scale deployments.

The Coriolis virtual appliance is configured to automatically discover and perform DHCP on all network interfaces. If no DHCP server is available, a static IP configuration can be set manually through the Coriolis appliance console menu.

Install Coriolis

Coriolis is provided as an OVA file which can be deployed on one of the supported platforms.

For the deployment tutorial, please follow the Installation guide.

Coriolis Console Menu

The Coriolis Console Menu is an Interactive User Console, which can be accessed using the serial console of the Coriolis Appliance once the installation is complete.
It will offer you options to inspect or modify the credentials, networks, and configuration files, as well as use Coriolis via CLI.

For more information, please check the Coriolis Console Menu page.

Coriolis License

Coriolis Licenses are required to perform Replicas/Migrations.

Replica and Migration licenses are counted separately and on a per-VM basis. In the case of a Replica, which is a continuous syncing process, a valid license is required when both creating the Replica and the following syncs.

For further information please check Coriolis Licensing.

Supported source and destination platforms

---

For OpenStack, Coriolis is compatible with the vanilla OpenStack project, as well as being validated with the most common OpenStack distributions from trusted vendors such as:

Supported guest operating systems

While the Migration/Replication processes treat the VM as a black box and are agnostic as to the operating system used in the guest, the OSMorphing process is tailored to the specific guest OS release. 

Coriolis aims to support the OSMorphing process for the following guest operating system releases:

Coriolis Endpoints

Coriolis will save the connection details to your source and destination platforms as Cloud Endpoints. Having Cloud Endpoints will allow you to create Migration/Replica jobs to or from the platforms specified within the Cloud Endpoints.

For using the Coriolis Endpoints please follow the Endpoints guide.

For more information regarding each supported platform, please check the corresponding page of the plugin:

Preparing a VM for Migration/Replication

Before starting the process of Replica or Migration, there is a list of recommended steps to take on a VM running on a supported source platform, which is planned to be migrated/replicated with Coriolis.
While these steps are not mandatory, they are recommended to ensure the smoothest migration possible.

For information regarding the steps for preparing a VM, please check the Preparing a VM for Replica/Migration page.

Note! When preparing for a Replica/Migration, Coriolis will create the disks on the destination platform with an additional 1GB to its original size. The 1GB disk size to be added is most common for all platforms as it is the smallest unit of measure that the cloud supports.

The additional disk size on the destination platform is required to cover situations where the disk on the source may be larger only by a few bytes (than what the platform declares) and some data is written at the very end of the disk.

Creating a Replica

Replicas are continuous background sync of a running workload’s storage from a source cloud directly to a destination cloud (“executing a replica”), and the ability to create a new VM on the destination cloud with the synced storage elements should disaster strike on the source (“deploying a replica”).

The source VM continues to run throughout the data synchronization process, without downtime or service impact.

For tutorials and more information, please check the How to create a Replica page.

Deploying the Replica on the target platform

To create a new VM on the destination platform from Replica, at least one Replica Execution of that instance should have been completed successfully.

To initiate the Replica Deployment, from the Replica process (previous step), select “Actions” from the top left corner, and from the drop-down menu, select “Create Migration”

The next pop-up will have the Clone Disks option. This tells Coriolis to clone the disks on the destination platform and create the new VM from the cloned disks, thus allowing Coriolis to keep incrementally syncing to the same disks in the future. If the Clone disks option is set to “No”, Coriolis will need to re-sync the VM to new disks during the next Replica Execution.

The Force option that comes as “No” by default, will forcibly attempt to start the Replica Deployment process despite the Replica not having any successful Executions. This is risky and will most likely lead to a failed deployment if the Replica has not been successfully executed at least once prior.

Skip OS Morphing tells Coriolis to skip performing the OS Morphing process. The OS Morphing process includes numerous steps required to ensure that the guest OS being deployed can boot and function correctly on the target platform. Notable examples include removing any platform-specific drivers, or agents that were only used on the source platform, and installing the drivers/agent required by the destination platform,
OS Morphing can be skipped in situations where both the source and destination platforms are using the same underlying hypervisor, such as when performing a Migration between two KVM-based OpenStack installations.
For more specific details regarding the actions taken during the OS Morphing process for each platform, please check the Coriolis Plugins pages for the source/destination platforms you are interested in.

The User Scripts option will allow uploading a script for installations/modifications on the guest OS being migrated. These scripts are executed right before the OS Morphing process is performed by Coriolis, thus allowing for custom modifications to the guest OS before it is booted on the destination platform.
For more information, please check the User Scripts page.

After selecting the desired options, clicking “Migrate” will start the process of the Migration and it can be monitored from Dashboard->Migration->”Migration name”

Coriolis Minion Pools

Coriolis Minion Pool feature will allow the creation of worker VMs (Minions) on Source/Destination clouds that will act as Coriolis temporary resources during the Replica/Migration process.
Minion Pools will improve the time efficiency for the Replica/Migration process as Coriolis will no longer need to create the temporary resources and clean up when the process finishes.

For more information, please check the Coriolis Minion Pools Operation and Usage page.

Coriolis Projects and Users

Coriolis provides the option for multiple users to access a variety of roles to the default Project or a new one. In Coriolis, multiple Projects can coexist using different or the same Endpoints, but listing only the Replica/Migration processes performed on that Project.

For more information, please check the Coriolis Projects and Users documentation page.

Coriolis CLI

For all the Coriolis steps provided above, besides the Coriolis Dashboard, there is a command-line interface available.
Please find more information on the Coriolis CLI page.

Troubleshooting

In the situation of encountering any issue during one of the above processes, the Coriolis Logs option is available from both Coriolis CLI and Coriolis GUI. For more information on logs, please check the Coriolis Logs page.
For more information regarding Coriolis Troubleshooting, check the Troubleshooting page.