Migrate Appliance
The Migration feature serves two main purposes
- As of June 30th, 2024, CentOS Linux 7 has reached End of Life (EOL). To ensure optimal performance and security, it is highly recommended that any ELM running on release 2403 or earlier migrate off of CentOS 7. Utilize the migration feature with the latest version of release 2403 on a Source ELM in order to migrate onto a Target ELM running release 2409 or later.
- The migration feature allows you to copy or migrate resources between ELMs, even if they are on different hypervisors.
Note:
The migration feature will be available to migrate off any ELM deployed on a supported hypervisor. However, at this time, GCP will not be supported as a Target ELM destination.
Before you migrate
Notes
- It is suggested that a snapshot/backup of both the Source and Target ELM be captured before migration.
- This process is non-destructive to the Source ELM layer data.
- The configuration of the Source ELM will be modified during a Move migration. See Phases of migration section for additional details.
- A custom certificate imported into the source ELM will not be migrated to the target ELM. You will need to recreate the certificate on the target ELM after completing the migration.
Permissions required
- Requires the Administrator role.
- No additional permissions required.
Resources required
- Source ELMs using a release earlier than 2403 must be upgraded to release 2403.
- If you are running release 2403 and do not see the migration feature in the UI, ensure you have applied the latest 2403 upgrade which includes the migration feature.
- The download for the latest version of release 2403 can be found here.
- Source ELMs using a release of 2409 or later require no additional upgrading.
- Target ELM must use release 2409 or later.
- See downloads for the latest version of release 2409 and any later releases available.
- Target ELM, at minimum, must have the same amount of storage space as the Source ELM.
- Target ELM must not have any layers created before migration.
- Source ELM and Target ELM must have point-to-point network connectivity
Note:
A fast, local network connection will ensure the best experience with the migration feature.
Types of migration
There are two migration types available: Copy and Move.
| Copy | Move |
|---|---|
| All layers, templates, and connectors are copied over. | All layers, templates, and connectors are copied over. |
| All previously registered agents will be registered on the Target ELM. | All previously registered agents will be registered on the Target ELM. |
| Source ELM will remain unchanged and can continue to be used. | Source ELM will no longer have an associated network file share. |
| Target ELM will require a new network file share, as two different ELMs cannot utilize the same network file share. | Target ELM will have the network file shares from the Source ELM set up. |
| All Source ELM connector caches will be cleaned up. |
Note:
In a Copy Migration, the Target ELM network file share should not be the same as the Source ELM. ELMs are not designed to share the same network file share. Doing so would cause issues for both the Source and Target ELMs.
Phases of migration
The migration process is broken up into two different phases: Phase One and Phase Two.
Phase One
- Layer Phase: Layers are scanned and copied over from the Source ELM to the Target ELM.
- Layers copied over to the Target ELM will be visible in the UI following a successful migration.
- Upon completion of Phase One, the user will be prompted with an option to Proceed and move into Phase Two.
Note:
Depending on the number and size of layers in the Source ELM this phase can take anywhere from several minutes to several hours.
Phase Two
- Database Phase: The database is transferred over from the Source ELM to the Target ELM.
Note:
This phase is relatively quick and will only take a few minutes.
Following the completion of a Copy, the user can continue to utilize the Source ELM and can configure the Target ELM for usage when ready.
Following the completion of a Move, the Target ELM will contain transferred resources and configurations after a successful migration.
Migrating an appliance
With the exception of Step 1, all of the following steps should be performed on the Source ELM.
- Deploy a new Target ELM following the documentation for release 2409 or later.
- The migrate feature can be accessed under User Menu > Migrate Appliance.
- Supply the following information for the Target ELM:
- IP/FQDN
- Username (root user)
- Password (root user)
- Migrate Reason
- Copy
- The Source ELM will maintain ownership of the current resources.
- The Target ELM will require new resources and configuration setup.
- Move
- The Target ELM will own/manage the current resources upon completion.
- The Source ELM will have the configured network file share removed upon completion.
- The Source ELM can be re-used and will require a new network file share.
- Copy
- Select Confirm and Complete.
- Select Migrate.
- Once a migration has started the UI will prevent a user from starting a second migration until the current one has been completed or cancelled.
- On the left-hand menu select Tasks.
- In the active tasks table select the current running migration task and then select View Details.
- View the current status of the migration.
- The Source ELM will continue to be available for usage during this time.
- During Phase One, new layers created at any point will be copied over to the Target ELM.
- After Phase One has completed, user confirmation is required on the Source ELM UI to begin Phase Two of the migration process.
UI access during a migration
During a migration there are varying levels of UI access for both the Source and Target ELMs depending on the phase a migration is in.
Phase One
- Source ELM - Everything is enabled.
- Target ELM - Expand Storage and Export Logs are enabled.
Phase Two
- Source ELM - Expand Storage and Export Logs are enabled.
- Target ELM - UI is inaccessible until migration has completed.
Recovering from a cancelled or failed migration
Note:
The Source ELM will always remain unchanged and accessible until a Move migration has successfully completed.
Cancelling or failing a migration can lead to varying states for the Target ELM. Below are various states the Target ELM can end up in, and the required course of action to resolve any issues.
Cancelling or failing a migration
- Phase One
- Target ELM will store copied layers in the layer repository.
- Phase Two
- A user attempting to cancel the migration will be presented with a pop-up confirming the cancellation and inform the user of the non-recoverable state the Target ELM will be left in.
- Target ELM will be in a non-recoverable state.
Recovering from a cancelled or failed migration
- Phase One
- Starting a new migration will resume the migration process from where it left off. No additional steps required.
- Phase Two
- Target ELM should be reverted to a snapshot taken prior to migration and retried.
Note:
A known cause of a failed migration is due to lack of storage on the Target ELM. Expanding storage space will fix the issue, and an active migration should continue from the point it left off.