Setting networking configuration
In the migration process, Coriolis will do its best to ensure that the instance on the destination is booted with a similar, or, if possible, identical networking setup.
While certain aspects cannot be guaranteed for every supported destination platform (such as the exact bus setup, or the order in which the devices appear to the VM), Coriolis will always attempt to create virtual NIC resources with the same MAC address.
NOTE some platforms may not support the explicit setting of a MAC address when creating a virtual NIC. Please review the documentation of the respective platform plugins for any warnings on this aspect.
Depending on the situation, there are several aspects apart from the MAC address to consider:
- does the destination platform use a DHCP server?
- do all the network name mappings in the network_map parameter describe networks with matching (ideally 1:1) virtual subnet ranges?
- do the network_map mappings also consider other parameters, such as DHCP being enabled on all the destination networks mapped to a DHCP-enabled network on the source?
Recommended steps for Linux VMs
- install the guest agent of the respective platform hosting the VM in the case of platforms that rely on the agent to report the network configuration. This will later allow Coriolis to query the APIs of the platform for exact details of the internal networking configuration of the VM (interfaces, addresses, etc…)
- configure static IPs on all network interfaces that are configured with DHCP. This allows full user control over the instance’s addresses on the destination platform. Granted, the subnet ranges of the source and destination networks as mapped in the network_map coincide
- update any udev rules describing interface naming to rely explicitly on the MAC address of the interfaces. Coriolis guarantees that the MAC address of the interfaces will be replicated on destination clouds which support the explicit setting of a MAC address on a vNIC
- check package repositories for local sources. The sources should be available from the destination Cloud during the OSMorphing stage. Any local sources i.e. CD-ROM should be commented out.
- make sure that the repositories are updated successfully on the source VM
- for RedHat-based distros use “yum update” and for Debian/Ubuntu use “apt update“
Recommended steps for Windows VMs
- install the guest agent of the respective platform hosting the VM in the case of platforms that rely on the agent for reporting the network configuration. This will later allow Coriolis to query the APIs of the platform for exact details of the internal networking configuration of the VM (interfaces, addresses, etc…)
- configure static IPs on all network interfaces that are configured with DHCP. This allows full user control on the addresses the instance will have on the destination platform, granted that the subnet ranges of the source and destination networks as mapped in the network_map coincide
Setting storage configuration
In the migration/replication process, Coriolis will do its best to preserve the block device ordering the VM had on the source platform.
Depending on the destination platform’s limitations (such as supported bus types, block storage paravirtualization features, and so on) the order of block devices, and thus the naming scheme for Linux-based OSes may differ.
Recommended steps for Linux VMs
- update /etc/fstab to use filesystem UUIDs to identify partitions to be mounted. Any other naming scheme may be unreliable due to limitations on some supported destination platforms
The UUIDs of the partitions can be found by using the “blkid” command, and then the /etc/fstab file has to be edited to replace the references with the UUID=value instead - update/remove any udev rules describing block device naming that rely on physical aspects of a disk such as a vendor ID, bus ID, and so on. Depending on the limitations of the destination platform, Coriolis may not be able to guarantee such specific aspects relating to the disk devices will be preserved
- if replicating, install the guest agent of the respective platform hosting the VM in the case of platforms that rely on an agent to support filesystem quiescing. During the replication process, Coriolis will always attempt to quiesce the filesystems of a running instance to ensure the consistency of the filesystems of the replica after a replica execution
- ensure that the /boot partition has enough free disk space to accommodate rebuilding all existing installed kernels’ initramfs image. This is a step in the OSMorphing process before the instance is booted onto the destination cloud.
Recommended steps for Windows VMs
- Just as for Linux VMs, for Windows VMs ensure that the latest virtualization guest agent (such as the Windows VirtIO agent) is installed and running on the Windows guest system. The guest agent is specific to the respective platform hosting the VM for platforms that rely on an agent to support filesystem quiescing. During the replication process, Coriolis will always attempt to quiesce the filesystems of a running instance to ensure the consistency of the replica filesystems after a replica execution.
- For Windows VMs, ensure that the latest Windows updates are installed and that the guest OS is rebooted to finish the installation of the updates.
This is due to all the components involved in the snapshotting process, such as VSS, related to the Windows OS and used as part of the migration process.
Firmware type support
This table will outline all the supported virtualization/cloud platforms by Coriolis, and whether their respective providers support UEFI firmware, with/without Secure Boot.
| Supported in Export Provider | Supported in Import Provider | |
 OpenStack |  * | |
 | | |
 |  | |
 Microsoft Azure | | |
 Linux servers | |  |
 Oracle PCA | | |
OCI | | |
 MicroCloud (LXD) | | |
 |  | |
 OLVM & RedHat Virtualization (RHV) | | |
 Microsoft Hyper-V & SCVMM | | |
 KubeVirt | Harvester | | |
 | | |
*Openstack instances do not have an exact way of telling if they’re UEFI instances or not, besides reading instance metadata, which may not always be available. In those cases, the Firmware type can be overridden by a source environment option
: fully supports UEFI with Secure Boot
: only supports UEFI firmware, but no Secure Boot
: the underlying platform does not support UEFI or Secure Boot
Secure Boot is not yet fully supported on AWS, only on Windows instances, but Coriolis will not be enabling it until proper support is added.
Coriolis does not yet support Secure Boot for Azure.
Bootloader checks on the VM to be Replicated/Migrated
As part of migrating Linux instances, Coriolis will run several steps that touch the boot configuration and kernels of the migrated guest OS (on the target disks, source VM configuration is untouched).
To ensure a smooth process, we recommend the following to be done on the source VM, before running the migrations:
- update kernel to latest available version and reboot the source VM. This will ensure that regenerating the initramfs kernel images is also functional, this being a step that Coriolis will perform as part of the OS Morphing process.
- Remove any obsolete / no longer required older kernels on the source VM. This will also cover the requirement that enough free disk space is available on the /boot partition.
For the supported guest OSes, Coriolis can handle the default bootloaders.
To check the bootloader on the VM(s) meant to be Replicated or Migrated, run the following command:
|
1 |
sudo dd if=/dev/<relevant OS partition/disk> bs=512 count=1 2>/dev/null | strings | grep -Eoi 'grub|lilo' |
The command above will check on the selected disk if the bootloader is installed. Please make sure that the selected partition/disk in the one hosting the OS.
|
1 2 3 4 5 |
##output## root@coriolis:~# sudo dd if=/dev/sda bs=512 count=1 2>/dev/null | strings | grep -Eoi 'grub|lilo' GRUB root@coriolis:~# |
On-demand Linux images subscription in Public Clouds
Several cloud service providers, such as Amazon Web Services (AWS) or Microsoft Azure, provide on-demand Linux images bundled with a paid subscription.
Such subscription-based services are provided for RedHat Cloud Access or Ubuntu Advantage and are bundled as part of the cloud provider access.
NOTE When moving a subscription-based Linux VM from a supported cloud provider to a different environment – either a different cloud or internal infrastructure, the user is responsible for the license continuity being ensured and that the license terms are not violated.
In the case of Red Hat Enterprise Linux (RHEL), you must handle this either by bringing your own subscription (BYOS) or by contacting the sales representative of the Linux vendor on what is the best subscription switch path.
Coriolis requires that as part of the OS Morphing stage, it will continue to access the distribution repositories, to prepare the OS for the destination endpoint.
This implies installing a set of Linux packages, depending on the distribution. Therefore the VM must be prepared to ensure that packages can be installed successfully from the repositories, before moving the VM from the source to the destination endpoint.
Please refer to the distribution license terms to ensure that you are eligible to continue using the subscription and comply with the destination cloud or platform-supported license methods.
VMware migrations
To ensure consistency between the running VMware (ESXi) version with the VMs, it is recommended to check and ensure that for the VMs to be migrated, the VM hardware version in VMware must be set to match with the running VMware version.
For Coriolis, the requirement is that the minimum hardware version for virtual machines be version 13 or newer (ESXi 6.5).