This page outlines different situations that a user might encounter when using Coriolis.

No matching migration image type found for OS type ‘windows’

When Replicating/Migrating a Windows VM, the above error can be seen if a Windows template has not been specified for the Temporary migration worker. in the Target options menu, under the Advanced screen, both Linux and Windows templates have to be specified. This is required as Disk cloning is performed using the Linux template and OSMorphing is performed using the Windows template.

Troubleshooting the Docker-based Coriolis appliance

Should the Docker-based appliance be experiencing issues, one should first start by checking the status of the containers by running the following:

Container status command

All of the containers on the appliance are configured to restart upon the failure of the container service and should appear as “Up” the whole time, and thus containers that fail to start to appear as “Restarting” or “Up 1 second”

Should a container be in “Exited” status, one can attempt to start it back up by running the following:

Starting a stopped container

As a last resort, the container may be killed completely and the deployment run again via running the following:

Stopping a container and redeploying it

The command ‘~/coriolis-docker/coriolis-ansible deploy’ uses Ansible to deploy all the Coriolis components (API, conductor, replica-cron, worker, web, and web-proxy). Running it will only redeploy the containers which have been previously killed, and is idempotent (may safely be run as many times as needed)

Troubleshooting OSMorphing on the Docker-based Coriolis appliance

The OSMorphing process is the procedure undergone by the guest OS being migrated in order to ensure it will boot on the destination platform.

OSMorphing always occurs on the destination platform, where Coriolis will create a temporary VM (either Linux or Windows, depending on the guest OS being migrated) in order to perform the OSMorphing steps on the already-synced disks.

Considering that OSMorphing errors may be a direct result of an incompatibility between the specific setup of the guest OS and Coriolis or the destination platform, they are relatively more common during a Migration, and the only concrete way to debug the issues would be to login to the temporary OSMorphing VM Coriolis is controlling in order to see exactly what Coriolis sees.

Configuration:

There is a dedicated ‘debug_os_morphing_errors’ flag in the ‘[conductor]’ section of /etc/coriolis/coriolis.conf:

debug_os_morphing_errors example

If set to ‘true’, the Coriolis Conductor will skip performing the cleanup steps on the temporary resources on the destination platform and will log out the connection info for the temporary VM in the Coriolis-conductor.log.

NOTE please remember to run a docker restart Coriolis-conductor for any changes to debug_os_morphing_errors to take effect.

Accessing the Coriolis temporary worker VM

Below is a sample of the connection info for the temporary worker VM as seen in Coriolis-conductor.log:

debug_os_morphing_errors log output example

WARNING if ‘debug_os_morphing_errors’ is set, the lifecycle of the temporary OSMorphing worker VM and all of its associated resources (disks, NICs, public IPs, etc…) will no longer be managed by Coriolis.
All the temporary OSMorphing resources on the destination platform will need to be manually cleaned up after investigations have concluded.

After logging into the temp VM, the following things to check may be of importance:

• if all of the disks of the migrated VM are visible in the temp VM
• if all of the disks are mountable within the temp VM (reviewing dmesg output for new mounts is recommended)
• if the order of the disks is the same as the order reported by the destination platform’s UI/API
• if the disks are using any non-standard partitioning layouts/formats (ex: BitLocker/dm-crypt, Dynamic Disks on Windows, etc…)
• if Coriolis properly identified and mounted the guest OS being migrated (there should be some non-root mount points on the worker)
• try to run the chroot command attempted by Coriolis which leads to the OSMorphing error (can be seen in Coriolis’ error logs)

AWS – 500 Server Error: Internal Server Error for url: https://IP:5566/api/v1/dev/xvdf/acquire

Some AWS instance types use SSD-backing storage, and although the guest OS internally has the disks named /dev/nvmeX, the AWS API returns the disk labels as /dev/xvdf.

To overcome this, if the error is encountered when using AWS as a Destination Cloud, consider changing the Instance Type for the Migration Mapping used for the Coriolis Temporary worker.

For example, if the error is seen when using t3.medium, try to use c5.large instead, or other types available, depending on the region.

Change the admin password

The following command can be used to change the password for the admin user:

Once done, consider setting also the corresponding password in /etc/kolla/admin-openrc.sh:

For multi-tenant configurations, the following command can be used to change the password for any user:

Migrated guest VM fails to boot with a message that root volume or partition not found

A guest VM with the root partition using LABEL paths in /etc/fstab might fail to migrate under Coriolis.

Please refer to the steps to verify and prepare on the source VM before running a migration task, as detailed here: Preparing a VM for migration/replication – Cloudbase Solutions

Once /etc/fstab has been updated on the source VM to use filesystem UUIDs, create a new migration task or an incremental replica.

Windows Server 2012/2012R2 guest OS support

Microsoft Windows Server 2012 and 2012R2 reached End-Of-Life support in October 2023. If upgrading to a newer version before migration is not possible, migrating these versions is subject to best effort.

Coriolis will still handle OS Morphing for these versions, one user consideration is that the older stable such as virtIO drivers 0.1.189 must be used.

Set a static IP for the Coriolis appliance

The Coriolis virtual appliance system is based on Ubuntu Server, so a typical netplan configuration will apply.

From the console menu, go to the option to edit the network settings.

#vim /etc/netplan/50-cloud-init.yaml

You can set a static IP in this format:

[/crayon]