Coriolis can operate and handle VM migrations, including in restricted deployments, and does not require an Internet connection to carry out the operations, given that a few requirements are met.
This guide describes how to configure and operate Coriolis in environments without outbound internet connectivity (air‑gapped environments). In such systems, several artifacts and repositories must be set up in the local infrastructure and made available in the target cloud.
The main dependencies to consider and self-host are the Cloudbase-init tool and platform-specific drivers, such as the VirtIO drivers, which will be detailed below.
Another consideration is access to the repositories of the guest OS used for the temporary worker, as well as the repositories for the migrated guest OSes and versions. This is to be considered when an HTTP/HTTPS proxy is not available.
Dependencies configuration
For the OSMorphing stage dependencies, you must modify the coriolis.conf configuration file.
From the Coriolis Console, select the following option:
Edit/Inspect Coriolis Configuration
In the CLI, run the following command to start modifying the coriolis.conf file.
$ vim /etc/coriolis/coriolis.conf
# nano editor is also available
If OpenStack is used as the destination, locate the following section.
[openstack_migration_provider]
Scroll down until you find the following parameters:
- windows_virtio_iso_url
- Parameter name available for all platforms that are KVM-based and use the VirtIO drivers.
- windows_vmware_tools_url
- In the case of VMware as a target migration, refer to the VMware plugin page for more details.
- cloudbaseinit_x64_url
- cloudbaseinit_x86_url
- This is optional for when a 32-bit Windows guest OS is migrated, otherwise the option can be ignored.
Modify these URLs so they point to the location where you host the required files.
After this, save the file and exit the CLI. When prompted to restart the Coriolis containers, select y (Yes).
The process is the same for the other providers, by identifying the correct section in coriolis.conf with the format [{platform}_migration_provider].
Proxy configuration
If the infrastructure uses an HTTP/HTTPS Proxy, it can be configured so that both the Coriolis virtual appliance and its temporary workers use it.
Setting up a proxy connection for workers
From within the Coriolis console, you need to select option 3) Edit/Inspect Coriolis configuration
Then, proceed to edit the Coriolis configuration file and look for the [proxy] section.
$ vim /etc/coriolis/coriolis.conf
After modifying these details, you can save the changes and exit the editor.
This will also further allow the Linux workers so that the proxy configured will be used.
NOTE! For Windows workers to use a proxy, the proxy configuration should be set in the Windows temporary worker template images.
Setting up a proxy for the Coriolis appliance
In case the proxy is needed to provide internet for the Coriolis appliance (such as the need for internet while undergoing appliance upgrades) or you need it to get access to the environments, that means the environments are not accessible without a proxy being set.
NOTE! You should avoid adding a proxy if you can already access the environments, as it may cause conflicts with the current connections.
To configure this, you need to go to the Coriolis console and select the option 5) Edit/Inspect Proxy Settings, as shown in the screenshot below.
After providing all the details, you will also need to do it for the Coriolis workers as described in the previous step.
Other considerations
As part of the OS Morphing stage, Coriolis also installs some packages as follows:
- For the Linux temporary worker:
- lvm2
- psmisc
These packages can be preinstalled by the user in the Linux temporary worker, and then Coriolis will no longer attempt to install these from the corresponding temporary worker Linux repositories.
- For the migrated Linux guest OS:
- refer to the plugin page of the target platform. The usual packages for KVM-based platforms would be cloud-init and qemu-guest-agent.
- Coriolis will not attempt to install these packages if they are already present; they should be installed on the source VM before migration. This scenario should be considered if the target platform has no access to the Linux repositories.