Ceph is the most common OpenSource solution to provide block storage through OpenStack Cinder.

Ceph is a very flexible solution. The possibilities of Ceph require additional steps to the Trilio solution.

Many organizations are looking to modernize their data centers and migrate from technologies like VMware to OpenStack. Although historically, VMware has been a dominant virtualization platform, trusted by many organizations for running mission-critical applications, the rapidly evolving technology landscape has already delivered the next generation of virtualization technologies. OpenStack and Kubernetes are setting the stage for edge computing and Hybrid & Multi-Cloud to emerge as industry standards.

Migrating from VMware to OpenStack offers compelling benefits:

1. Cost Savings: OpenStack significantly reduces licensing fees.

2. Vendor Independence: Avoid vendor lock-in and make choices based on how they favor your business.

3. Innovation and Collaboration: Open-source fosters rapid advancements.

4. Scalability and Elasticity: Automatically scale resources on demand

5. Multi-Cloud Support: Manage multiple clouds and data centers from one interface.

6. Integration with Open Source: Seamlessly integrate with Kubernetes and other open-source tools.

7. Community Support: Active community provides resources and expertise

By embracing OpenStack, you gain cost savings, flexibility, scalability, and a vibrant community, empowering your cloud infrastructure.

Migrating VMs from VMware to OpenStack has traditionally been a people-intensive and complex process requiring an "expert-intensive" investment.

Organizations must engage in detailed planning, consult experts, and consider utilizing tools and technologies to facilitate smooth migrations. Because each migration scenario is unique, it has been difficult to come up with best `practices and/or automation. This page is about how Trilio’s Intelligent Recovery Platform can help simplify and automate the migration process.

Check the supported OpenStack distributions and follow their deployment guides to install or upgrade to the latest version of T4O.

Enable Migration Tab on Horizon

Follow below steps to enable Migration Tab on Horizon.

1. Login to horizon container.

Trilio Data, Inc

Trilio Data, Inc. is the leader in providing backup and recovery solutions for cloud-native applications. Established in 2013, its flagship products, Trilio for OpenStack(T4O) and Trilio for Kubernetes(T4K) are used by a wide number of large corporations around the world.

The Trilio solution is using the qcow2 backing file to provide full synthetic backups.

Especially when the NFS backup target is used, there are scenarios at which this backing file needs to be updated to a new mount path.

To make this process easier and streamlined Trilio is providing the following rebase tool.

The following versions can be upgraded to each other:

The upgrade process involves upgrading the Trilio appliance and the OpenStack components and is dependent on the underlying operating system till T4O 4.2 release.

Each T4O release includes a set of artifacts such as version-tagged containers, package repositories, and distribution packages.

To help users quickly identify the resources associated with each release, we have added dedicated sub-pages corresponding to a specific release version.

The high-level process is the same for all Distributions.

1. Uninstall the Horizon Plugin or the Trilio Horizon container

2. Uninstall the datamover-api container

3. Uninstall the datamover container

4. Uninstall the workloadmgr container

Trilio for OpenStack Compatibility Matrix

NFS & S3 Support

All versions of T4O-5.x releases support NFSv3 and S3 as backup targets on all the compatible distributions.

Encryption Support

All versions of T4O-5.x releases support encryption using Barbican service on all the compatible distributions.

QEMU Guest Agent

QEMU guest agent is highly recommended to be running inside the VM that being backed up to avoid data corruption during backup process. QEMU Guest Agent is a daemon that runs inside a virtual machine (VM) and communicates with the host system (the hypervisor) to provide enhanced management and control of the VM. It is an essential component in virtualized environments specially OpenStack.

Definition

Trilio can notify users via E-Mail upon the completion of backup and restore jobs.

The E-Mail will be sent to the owner of the Workload.

Requirements to activate E-Mail Notifications

To use the E-mail notifications, two requirements need to be met.

User E-Mail assigned

As the E-Mail will be sent to the owner of the Workload does the Openstack User, who created the workload, require to have an E-Mail address associated.

Trilio E-Mail Server configured

Trilio needs to know which E-Mail server to use, to send the E-mail notifications. Backup Administrators can do this in the "Backup Admin" area.

Activate/Deactivate the E-Mail Notifications

E-Mail notifications are activated tenant wide. To activate the E-Mail notification feature for a tenant follow these steps:

1. Login to Horizon

2. Navigate to the Backups

3. Navigate to Settings

4. Check/Uncheck the box for "Enable Email Alerts"

Example E-Mails

The following screenshots show example E-mails send by Trilio.

Backup-as-a-Service

Trilio is an add-on service to OpenStack cloud infrastructure and provides backup and disaster recovery solutions for tenant workloads. Trilio is very similar to other OpenStack services including Nova, Cinder, Glance, etc., and adheres to all tenets of OpenStack. It is a stateless service that scales with your cloud.

Main Components

Trilio has three main software components which are again segregated into multiple services.

WorkloadManager

This component is registered as a keystone service of type workloads which manages all the workloads being created for utilizing the snapshot and restore functionalities. It has 4 services responsible for managing these workloads, their snapshots, and restores.

1. workloadmgr-api

2. workloadmgr-scheduler

3. workloadmgr-workloads

4. workloadmgr-cron

DataMover

Similar to WorkloadManager, this component registers a keystone service of the type datamover which manages the transfer of extensive data to/from the backup targets. It has 2 services that are responsible for taking care of the data transfer and communication with WorkloadManager

1. datamover-api

2. datamover

Horizon Dashboard Plugin

For ease of access and better user experience, T4O provides an integrated UI with the OpenStack dashboard service Horizon,

1. Trilio API is a Python module that is installed on all OpenStack controller nodes where the nova-api service is running.

2. Trilio Datamover is a Python module that is installed on every OpenStack compute nodes

3. Trilio Horizon plugin is installed as an add-on to Horizon servers. This module is installed on every server that runs Horizon service.

Service Endpoints

Trilio is both a provider and consumer in the OpenStack ecosystem. It uses other OpenStack services such as Nova, Cinder, Glance, Neutron, and Keystone and provides its own services to OpenStack tenants. To accommodate all possible OpenStack deployments, Trilio can be configured to use either public or internal URLs of services. Likewise, Trilio provides its own public, internal, and admin URLs for two of its services WorkloadManager API and Datamover API.

Network Topology

Unlike the previous versions of Trilio for OpenStack, now it utilizes the existing network of the OpenStack deployed environment. The networks for the Trilio services can be configured as per the user's desire in the same way the user configures any other OpenStack service. Additionally, a dedicated network can be provided to Trilio services on both control and compute planes for storing and retrieving backup data from the backup target store.

Definition

A Migration Plan is a structured and pre-defined set of instructions that outlines the process and details for migrating Virtual Machines (VMs) from a VMware environment to OpenStack. It serves as a blueprint for orchestrating the migration, including the selection of VMs, and managing the overall migration workflow. Each plan may have a name and may include a description to provide additional context and easy identification. Migration Plans are created and managed by users to ensure a systematic and controlled migration process.

Creation

To initiate the migration process, users must create a Migration Plan:

• Provide a name and description for the plan.

• Select the vCenter from which the VMs are to be migrated.

• Using the Manage VMs functionality, select VMs from the list of VMware VMs. This list does not include the VMs that are already part of a Migration Plan.

Update and Changes

Any modification to the plan requires users to:

• Revisit the plan details for updates.

• Execute the "" call to fetch and update resource information in the Trilio service DB.

Discover VMs

Discover VMs is an operation within the migration process that involves querying and collecting resource information from VMware for the VMs included in a Migration Plan. This operation is crucial for maintaining up-to-date details about the VMs, such as configuration, networking, and storage.

After creating or modifying a Migration Plan, users must:

• Trigger the "Discover VMs" operation.

• This operation collects resource information of VMs in the plan from VMware and stores it in the WLM service DB.

• "Discover VMs" must be called every time the plan is updated to ensure accurate information for migration. It ensures accuracy in subsequent migration steps and helps prevent unexpected outcomes due to outdated information.

Deletion

The user can also delete a Migration Plan if required. But it will need all the initiated migrations to be deleted. Refer to for deleting the initiated migrations for more information.

Cloud-Native and Containerized

T4O represents a comprehensively containerized deployment model, eliminating the necessity for any KVM-based appliances for service deployment. This marks a departure from earlier T4O releases, where such appliances were required.

Before embarking on the installation process for Trilio in your OpenStack environment, it is highly advisable to carefully consider several key elements. These considerations will not only streamline the installation procedure but also ensure the optimal setup and functionality of Trilio's solutions within your OpenStack infrastructure.

Tenant Quotas

Trilio leverages Cinder snapshots to facilitate the computation of both full and incremental backups.

When executing full backups, Trilio orchestrates the generation of Cinder snapshots for all volumes included in the backup job. These Cinder snapshots remain intact for subsequent incremental backup image calculations.

During incremental backup operations, Trilio generates fresh Cinder snapshots and computes the altered blocks between these new snapshots and the earlier retained snapshots from full or previous backups. The old snapshots are subsequently deleted, while the newly generated snapshots are preserved.

Trilio is using the which enables the Trilio service user to act in the name of another Openstack user.

This system is used during all backup and restore features.

Trusts can only be worked with via CLI

Trilio uses a widely used tool virt-v2v for migration which is one of the open-source tools by Red Hat. The below-mentioned limitations are from this tool and thus a limitation for Trilio as well:

• virt-v2v cannot change the default kernel in the GRUB2 configuration, and the kernel configured in the VM is not changed during the conversion, even if a more optimal version of the kernel is available on the VM.

• After converting a virtual machine to KVM, the name of the VM's network interface may change, and thus may require manual configuration.

Troubleshooting inside a complex environment like OpenStack can be very time-consuming.

The following tips will help to speed up the troubleshooting process to identify root causes.

What is happening where

OpenStack and Trilio are divided into multiple services. Each service has a very specific purpose that is called during a backup or recovery procedure. Knowing which service is doing what helps to understand where the error is happening, allowing more focused troubleshooting.

Trilio Workloadmgr

The Trilio Workloadmgr is the Controller of Trilio. It receives all Workload related requests from the users.

Every task of a backup or restore process is triggered and managed from here. This includes the creation of the directory structure and initial metadata files on the Backup Target.

During a backup process

During a backup process is the Trilio Workloadmgr also responsible for gathering the metadata about the backed-up VMs and networks from the OpenStack environment. It sends API calls to the OpenStack endpoints on the configured endpoint type to fetch this information. Once the metadata has been received, the Trilio Workloadmgr writes it as JSON files on the Backup Target.

The Trilio Workloadmgr is also sending the Cinder Snapshot command.

During a restore process

During the restore process, the Trilio Workloadmgr reads the VM metadata from its Database and uses the metadata to create the Shell for the restore. It sends API calls to the OpenStack environment to create the necessary resources.

Datamover API

The dmapi service is the connector between the Trilio cluster and the Datamover running on the compute nodes.

The purpose of the dmapi service is to identify which compute node is responsible for the current backup or restore task. To do so, the dmapi service connects to the nova API requesting the compute hose of a provided VM.

Once the compute host has been identified, the dmapi forwards the command from the Trilio Workloadmgr to the datamover running on the identified compute host.

Datamover

The datamover is the Trilio service running on the compute nodes.

Each datamover is responsible for the VMs running on top of its compute node. A datamover can not work with VMs running on a different compute node.

The datamover controls the freeze and thaw of VMs as well as the actual movement of the data.

Everything on the Backup Target is happening as user nova

Trilio is reading and writing on the Backup Target as nova:nova.

The POSIX user-id and group-id of nova:nova need to be aligned between the Trilio Cluster and all compute nodes. Otherwise, backup or restores may fail with permission or file not found issues.

Alternativ ways to achieve the goal are possible, as long as all required nodes can fully write and read as nova:nova on the Backup Target.

It is recommended to verify the required permissions on the Backup Target in case of any errors during the data transfer phase or in case of any file permission errors.

Input/Output Error with Cohesity NFS

On Cohesity NFS if an Input/Output error is observed, then increase the timeo and retrans parameter values in your NFS options.

Timeout receiving packet error in multipath ISCSi environment

Logging inside all datamover containers and add uxsock_timeout with value as 60000 which is equal to 60 sec inside /etc/multipath.conf.Restart datamover container

Trilio Trustee Role

Trilio is using RBAC to allow the usage of Trilio features to users.

This trustee role is absolutely required and can not be overwritten using the admin role.

It is recommended to verify the assignment of the Trilio Trustee Role in case of any permission errors from Trilio during the creation of Workloads, backups, or restores.

OpenStack Quotas

Trilio is creating Cinder Snapshots and temporary Cinder Volumes. The OpenStack Quotas need to allow that.

Every disk that is getting backed up requires one temporary Cinder Volumes.

Every Cinder Volume that is getting backup requires two Cinder Snapshots. The second Cinder Snapshot is temporary to calculate the incremental.

Trilio seamlessly integrates with OpenStack, functioning exclusively through APIs utilizing the OpenStack Endpoints. Furthermore, Trilio establishes its own set of OpenStack endpoints. Additionally, both the Trilio appliance and compute nodes interact with the backup target, impacting the network strategy for a Trilio installation.

Existing endpoints in OpenStack

OpenStack comprises three endpoint groupings:

• Public Endpoints

Public endpoints are meant to be used by the OpenStack end-users to work with OpenStack.

• Internal Endpoints

Internal endpoints are intended to be used by the OpenStack services to communicate with each

• Admin Endpoints

Admin endpoints are meant to be used by OpenStack administrators.

Among these three endpoint categories, it's important to note that the admin endpoint occasionally hosts APIs not accessible through any other type of endpoint.

To learn more about OpenStack endpoints please visit the official OpenStack documentation.

OpenStack endpoints required by Trilio

Trilio communicates with all OpenStack services through a designated endpoint type, determined and configured during the deployment of Trilio's services.

The following network requirements can be identified this way:

• Trilio services need access to the Keystone admin endpoint on the admin endpoint network if it is available.

• Trilio services need access to all endpoints of the set endpoint type during deployment.

Recommendation: Provide access to all OpenStack Endpoint types

Trilio recommends granting comprehensive access to all OpenStack endpoints for all Trilio services, aligning with OpenStack's established standards and best practices.

Additionally, Trilio generates its own endpoints, which are integrated within the same network as other OpenStack API services.

To adhere to OpenStack's prescribed standards and best practices, it's advisable that Trilio containers operate on the same network as other OpenStack containers.

• The public endpoint to be used by OpenStack users when using Trilio CLI or API

• The internal endpoint to communicate with the OpenStack services

• The admin endpoint to use the required admin-only APIs of Keystone

Backup target access required by Trilio

The Trilio solution uses backup target storage to place the backup data securely. Trilio divides its backup data into two parts:

1. Metadata

2. Volume Disk Data

The first type of data is generated by the Trilio Workloadmgr services through communication with the OpenStack Endpoints. All metadata that is stored together with a backup is written by the Trilio Workloadmgr services to the backup target in the JSON format.

The second type of data is generated by the Trilio Datamover service running on the compute nodes. The Datamover service reads the Volume Data from the Cinder or Nova storage and transfers this data as a qcow2 image to the backup target. Each Datamover service is hereby responsible for the VMs running on its compute node.

The network requirements are therefor:

• Every Trilio Workloadmgr service containers need access to the backup target

• Every Trilio Datamover service containers need access to the backup target

About the workloadmgr CLI client

The workloadmgr CLI client is provided as rpm and deb packages.

The following operating systems have been verified with the installation:

• CentOS8

• Ubuntu 18.04, Ubuntu 20.04

Installing the workloadmgr client will automatically install all required OpenStack clients as well.

Further, the installation of the workloadmgr client will integrate the client into the global OpenStack Python client, if available.

Install workloadmgr client rpm package on CentOS8

The Trilio workload manager CLI client has several requirements that need to be met before the client can be installed without dependency issues.

Preparing the workloadmgr client installation

The following steps need to be done to prepare the installation of the workloadmgr client:

1. Add required repositories

   1. epel-release

   2. centos-release-openstack-train

2. install base packages

Installing the workloadmgr client

Installing from the Trilio online repository

To install the latest available workloadmgr package for a Trilio release from the Trilio repository the following steps need to be done:

Create the Trilio yum repository file /etc/yum.repos.d/trilio.repo Enter the following details into the repository file:

Install the workloadmgr client issuing the following command:

yum install python-3-workloadmgrclient-el8

Install workloadmgr client deb packages on Ubuntu

The Trilio workloadmgr client packages for Ubuntu are only available from the online repository.

Preparing the workloadmgr client installation

There is no preparation required. All dependencies are automatically resolved by the standard repositories provided by Ubuntu.

Installing the Workloadmgr client

Installing from the Trilio online repository

To install the latest available workloadmgr package for a Trilio release from the Trilio repository the following steps need to be done:

Create the Trilio yum repository file /etc/apt/sources.list.d/fury.list Enter the following details into the repository file:

run apt update to make the new repository available.

The apt package manager is used to install the workloadmgr client package:

apt-get install python3-workloadmgrclient

Trilio employs a base64 hash to establish the mount point for NFS Backup targets, ensuring compatibility across multiple NFS Shares within a single Trilio installation. This hash is an integral component of Trilio's incremental backups, functioning as an absolute path for backing files.

Consequently, during a disaster recovery or rapid migration situation, the utilization of a mount bind becomes necessary.

In scenarios that allow for a comprehensive migration period, an alternative approach comes into play. This involves modifying the backing file, thereby enabling the accessibility of Trilio backups from a different NFS Share. The backing file is updated to correspond with the mount point of the new NFS Share.

Backing file change script

Trilio provides a shell script for the purpose of changing the backing file. This script is used after the Trilio appliance has been reconfigured to use the new NFS share.

Downloading the shell script

Prerequisites

The following requirements need to be met before the change of the backing file can be attempted.

• The Trilio Appliance has been reconfigured with the new NFS Share

• The Openstack environment has been reconfigured with the new NFS Share

  • Please check for Red Hat Openstack Platform

Usage

The shell script is changing one workload at a time.

Run the following command:

with

• /var/triliovault-mounts/<base64>/ being the new NFS mount path

• workload_<workload_id> being the workload to rebase

Logging of the procedure

The shell script is generating the following log file at the following location:

The log file will not get overwritten when the script is run multiple times. Each run of the script will append the available log file.

After all Trilio components are installed, the license can be applied.

The license can be applied either through the Admin tab in Horizon or the CLI

Apply license through Horizon

To apply for the license through Horizon follow these steps:

1. Login to Horizon using admin user.

2. Click on the Admin Tab.

3. Navigate to Backups-Admin

4. Navigate to Trilio

5. Navigate to License

6. Click "Update License"

7. Read the license agreement

8. Click on "I accept the terms in the License Agreement"

9. Click on "Next"

10. Click "Choose File"

11. Choose license file on the client system

12. Click "Apply"

Apply license through CLI

• <license_file> ➡️ path to the license file

Read and accept the End User License Agreement to complete the license application.

Users can preview the latest EULA at our main site:

Prerequisites

Before creating a Migration Plan, ensure the following prerequisites are met:

1. Access to the VMware environment.

2. The OpenStack environment is configured and accessible.

3. A clear understanding of the VMs you intend to migrate.

Steps to Create a Migration Plan Using Horizon

1. Log in to the OpenStack Dashboard (Horizon):

   • Use your credentials to log in to the OpenStack Dashboard.

2. Navigate to the VMware Migration section:

   • In the OpenStack Dashboard, locate and click on

Conclusion

Congratulations! You have successfully created a Migration Plan for migrating VMs from VMware to OpenStack. Ensure to review and validate the plan details before proceeding with the actual migration steps.

1. Can Trilio for OpenStack restore instance UUIDs?

Answer: NO

Trilio for OpenStack does not restore Instance UUIDs (also known as Instance IDs). The only scenario where we do not modify the Instance UUID is during an Inplace Restore, where we only recover the data without creating new instances.

When Trilio for OpenStack restores virtual machines (VMs), it effectively creates new instances. This means that new Virtual Machine Instance UUIDs are generated for the restored VMs. We achieve this by orchestrating a call to Nova, which creates new VMs with new UUIDs.

By following this approach, we maintain the principles of OpenStack and auditing. We do not update or modify existing database entries when objects are deleted and subsequently recovered. Instead, all deletions are marked as such, and new instances, including the recovered ones, are created as new objects in the Nova tables. This ensures compliance and preserves the integrity of the OpenStack environment.

2. Can Trilio for OpenStack restore MAC addresses?

Answer: YES

Trilio can restore the VMs MAC address, however, there is a caveat when restoring a virtual machine (VM) to a different IP address: a new MAC address will be assigned to the VM.

In the case of a One-Click Restore, the original MAC addresses and IP addresses will be recovered, but the VM will be created with a new UUID, as mentioned in question #1.

When performing a Selective Restore, you have the option to recover the original MAC address. To do so, you need to select the original IP address from the available dropdown menu during the recovery process.

By choosing the original IP address, Trilio for OpenStack will ensure that the VM is restored with its original MAC address, providing more flexibility and customization in the restoration process.

Example of Selective Restore with original MAC (and IP address):

1. In this example, we have taken a Trilio backup of a VM called prod-1.

1. The VM is deleted and we perform a Selective Restore of a VM called prod-1, selecting the IP address it was originally assigned from the drop-down menu:

1. Trilio then restores the VM with the original MAC address:

1. If you left the option as "Choose next available IP address", it will assign a new MAC to the VM instead as Neutron maps all MAC addresses to IP addresses on the Subnet - so logically a new IP will result in a new MAC address.

Trilio Workloads are designed to allow a Desaster Recovery without the need to backup the Trilio database.

As long as the Trilio Workloads are existing on the Backup Target Storage and a Trilio installation has access to them, it is possible to restore the Workloads.

Disaster Recovery Process

1. Install and Trilio for the target cloud

4. Notify users to of Workloads being available

Mount-paths

Trilio incremental Snapshots involve a backing file to the prior backup taken, which makes every Trilio incremental backup a synthetic full backup.

Trilio is using qcow2 backing files for this feature:

As can be seen in the example is the backing file an absolute path, which makes it necessary, that this path exists so the backing files can be accessed.

Trilio is using the base64 hashing algorithm for the NFS mount-paths, to allow the configuration of multiple NFS Volumes at the same time. The hash value is calculated using the provided NFS path.

When the path of the backing file is not available on the Trilio appliance and Compute nodes, will the restores of incremental backups fail.

The tested and recommended method to make the backing files available is creating the required directory path and using mount --bind to make the path available for the backups.

Running the mount --bind command will make the necessary path available until the next reboot. If it is required to have access to the path beyond a reboot is it necessary to edit the fstab.

Trilio services logs on RHOSP

On the Controller Node

Below Trilio containers gets deployed on the Contoller node.

• triliovault_datamover_api

• triliovault_wlm_api

• triliovault_wlm_scheduler

The log files for above Trilio services can be found here:

/var/log/containers/triliovault-datamover-api/triliovault-datamover-api.log

/var/log/containers/triliovault-wlm-api/triliovault-wlm-api.log

/var/log/containers/triliovault-wlm-cron/triliovault-wlm-cron.log

/var/log/containers/triliovault-wlm-scheduler/triliovault-wlm-scheduler.log

/var/log/containers/triliovault-wlm-workloads/triliovault-wlm-workloads.log

In the case of using S3 as a backup target is there also a log file that keeps track of the S3-Fuse plugin used to connect with the S3 storage.

/var/log/containers/triliovault-wlm-workloads/triliovault-object-store.log

For file serach operation, logs can be found on Controller node at below location:

/var/log/containers/triliovault-wlm-workloads/workloadmgr-filesearch.log

On the Compute Node

Trilio Datamover container gets deployed on the Compute node.

The log file for the Trilio Datamover service can be found at:

/var/log/containers/triliovault-datamover/triliovault-datamover.log

Same cloud - different owner

Migration within the same cloud to a different owner Cloud A — Domain A — Project A — User A => Cloud A — Domain A — Project A — User B Cloud A — Domain A — Project A — User A => Cloud A — Domain A — Project B — User B Cloud A — Domain A — Project A — User A =>Cloud A — Domain B — Project B — User B

Steps used:

1. Create a secret for Project A in Domain A via User A.

2. Create encrypted workload in Project A in Domain A via User A. Take snapshot.

3. Reassign workload to new owner

4. Load rc file of User A & provide read only rights through acl to the new owner

   openstack acl user add --user <userB_id> <secret_href> --insecure

Different cloud

Migration between clouds Cloud A — Domain A — Project A — User A => Cloud B — Domain B — Project B — User B

Steps used:

1. Create a secret for Project A in Domain A via User A.

2. Create an encrypted workload in Project A in Domain A via User A. Trigger snapshot.

3. Reassign workload to Cloud B - Domain B — Project B — User B

4. Load RC file of User B.

After the installation and configuration of Trilio for Openstack did succeed the following steps can be done to verify that the Trilio installation is healthy.

On the Controller node

Make sure below containers are in a running state, triliovault-wlm-cron would be running on only one of the controllers in case of multi-controller setup.

Definition

Every Workload has its own schedule. Those schedules can be activated, deactivated and modified.

A schedule is defined by:

• Status (Enabled/Disabled)

It is possible to configure Cinder and Ceph to use different Ceph users for different Ceph pools and Cinder volume types. Or to have the nova boot volumes and cinder block volumes controlled by different users.

In the case of multiple Ceph users, it is required to delete the keyring extension from the triliovault-datamover.conf inside the Ceph block by following below mentioned steps:

1. Deploy Trilio as per the documented steps.

1] Prerequisites

Please ensure the following requirements are met before starting the upgrade process:

• No Snapshot or Restore is running

• Global job scheduler is disabled

• wlm-cron is disabled on the Trilio Appliance

Deactivating the wlm-cron service

The following sets of commands will disable the wlm-cron service and verify that it is has been completely shutdown.

2] Install latest Trilio release

Please follow to install the latest Trilio release.

3] Enable mount-bind for NFS

T4O has changed the calculation of the mount point from 4.2 release onwards. It is necessary to set up the mount-bind to make T4O 4.1 or older backups available for T4O 4.2

Please follow to set up the mount bind for RHOSP.

4] Enable Global Job Scheduler

After the upgrade, global job scheduler would be disabled. You can enable that either through UI or CLI.

4.1] Through UI

Login to the Dashboard and go to Admin -> Backups-Admin -> Settings tab and check the 'Job Scheduler Enabled' checkbox. By clicking the 'Change' button you can enable the Global Job Scheduler.

4.2] Through CLI

Login to the any WLM container, create and source the admin rc file. Execute the enable the global job scheduler cli.

5] Import old workloads existing on the Backup Target

Workload import allows importing Workloads existing on the Backup Target into the Trilio database.

Please follow to import the Workloads.

Prerequisites

Before initiating the migration, ensure the following prerequisites are met:

1. Access to the VMware environment.

2. OpenStack environment configured and accessible.

3. created with the desired VMs selected.

Steps to Initiate a Migration Using Horizon

1. Log in to the OpenStack Dashboard (Horizon):

   • Use your credentials to log in to the OpenStack Dashboard.

2. Navigate to the VMware Migration section:

   • In the OpenStack Dashboard, locate and click on the

Post-Migration Tasks

• Verify that Instances are created with storage volumes, networking, and security groups attached.

• Verify if the Instances are booting up.

• As mentioned on the page, the user may have to set up the network by accessing the console of the instance.

• Validate the connectivity of the VMs created on OpenStack.

A Note to the User

The Migration Plan will enter a "Locked" state while its migration is in progress. A new migration for that plan can be initiated once the running migration is available or has encountered an error and the Plan is in an "Available" state.

Conclusion

Congratulations! You have successfully run a migration for VMs from VMware to OpenStack using the specified migration type. Ensure to validate the results and perform necessary tests to confirm the success of the migration process.

Trilio enables Openstack administrators to set Project Quotas against the usage of Trilio.

The following Quotas can be set:

• Number of Workloads a Project is allowed to have

• Number of Snapshots a Project is allowed to have

• Number of VMs a Project is allowed to protect

• Amount of Storage a Project is allowed to use on the Backup Target

Work with Workload Quotas via Horizon

Workload Quotas are managed like any other Project Quotas.

1. Login into Horizon as user with admin role

2. Navigate to Identity

3. Navigate to Projects

4. Identify the Project to modify or show the quotas on

Work with Workload Quotas via CLI

List available Quota Types

Trilio is providing several different Quotas. The following command allows listing those.

Show Quota Type Details

The following command will show the details of a provided Quota Type.

• <quota_type_id> ➡️ID of the Quota Type to show

Create a Quota

The following command will create a Quota for a given project and set the provided value.

• <quota_type_id> ➡️ID of the Quota Type to be created

• <allowed_value>➡️ Value to set for this Quota Type

• <high_watermark>➡️

List allowed Quotas

The following command lists all Trilio Quotas set for a given project.

• <project_id>➡️ Project to list the Quotas from

Show allowed Quota

The following command shows the details about a provided allowed Quota.

• <allowed_quota_id> ➡️ID of the allowed Quota to show.

Update allowed Quota

The following command shows how to update the value of an already existing allowed Quota.

• <allowed_value>➡️ Value to set for this Quota Type

• <high_watermark>➡️ Value to set for High Watermark warnings

• <project_id>➡️

Delete allowed Quota

The following command will delete an allowed Quota and sets the value of the connected Quota Type back to unlimited for the affected project.

• <allowed_quota_id> ➡️ID of the allowed Quota to delete

1] Prerequisites

Please ensure the following requirements are met before starting the upgrade process:

• No Snapshot or Restore is running

• Global job scheduler is disabled

In case you are upgrading from 4.x release to 5.x, please ensure below:

• wlm-cron is disabled on the Trilio Appliance

Deactivating the wlm-cron service on appliance

The following set of commands will disable the wlm-cron service and verify that it is has been completely shutdown.

2] Install latest Trilio release

Please follow to install latest Trilio release.

3] Enable Global Job Scheduler

After upgrade, global job scheduler would be disable. You can enable that either through UI or CLI.

3.1] Through UI

Login to the Dashboard and go to Admin -> Backups-Admin -> Settings tab and check the 'Job Scheduler Enabled' checkbox. By clicking the 'Change' button you can enable the Global Job Scheduler.

3.2] Through CLI

Login to the any WLM container, create and source the admin rc file. Execute the enable the global job scheduler cli.

4] Import old workloads existing on the Backup Target

Workload import allows to import Workloads existing on the Backup Target into the Trilio database.

Please follow to import the Workloads.

Deployment Scripts

Deployment Scripts

Container Information

Overview

Architecture

Definition

The file search functionality allows the user to search for files and folders located on a chosen VM in a workload in one or more Backups.

Navigating to the file search tab in Horizon

Trilio for OpenStack generates a base64 hash value for every NFS backup target connected to the T4O solution. This enables T4O to mount multiple NFS backup targets to the same T4O installation.

The mountpoints are generated utilizing a hash value inside the mountpoint, providing a unique mount for every NFS backup target.

This mountpoint is then used inside the incremental backups to point to the qcow2 backing files. The backing file path is required as a full path and can not be set as a relative path. This is a limitation of the qcow2 format.

With T4O 4.2 there was a significant change in how the hash value gets calculated. T4O 4.1 and prior calculated the hash value out of the complete NFS path provided as shown in the example below.

T4O 4.2 is now only considering the NFS directory part for the hash value as shown below.

It is therefore necessary to make older backups taken by T4O 4.1 or prior available for T4O 4.2 to restore.

This can be done by one of two methods:

Introduction

VM Migration Tool is an add-on stand alone utility provided by Trilio for effective migration of VMs from VMWare to OpenStack. This will assist users in planning the migration, creating any missing artifacts, and providing a holistic view of the migration process at an organizational level.

Current document provides the steps to be followed for deploying respective tool.

Introduction

Filename and location:

This file exclusively comes into play when users aim to configure Trilio with a NFS backup target that employs multiple network endpoints. For all other scenarios, such as single IP NFS or S3, this file remains inactive, and in such instances, please consult the standard installation documentation.

When using an NFS backup target with multiple network endpoints, T4O will mount a single IP/endpoint on a designated compute node for a specific NFS share. This approach enables users to distribute NFS share IPs/endpoints across various compute nodes.

The 'triliovault_nfs_map_input.yml

Trilio Branch

Branch of the repository to be used for DevOps scripts.

Deployment Scripts

git clone -b 5.2.6 https://github.com/trilioData/triliovault-cfg-scripts.git
cd triliovault-cfg-scripts/redhat-director-scripts/rhosp16/

Container/Revision Information

Package Repositories & Versions

All packages are Python 3 (py3.6 - py3.10) compatible only.

VM Migration Tool

Docker Container Tag

Deployment Scripts

git clone -b 5.2.0 https://github.com/trilioData/triliovault-cfg-scripts.git
cd triliovault-cfg-scripts/redhat-director-scripts/rhosp16/

git clone -b 5.2.0 https://github.com/trilioData/triliovault-cfg-scripts.git
cd triliovault-cfg-scripts/redhat-director-scripts/rhosp17/

git clone -b 5.2.0 https://github.com/trilioData/triliovault-cfg-scripts.git
cd triliovault-cfg-scripts/kolla-ansible/ansible/

Container Information

Package Repositories & Versions

All packages are Python 3 (py3.6 - py3.10) compatible only.

VMware version

• VMware vSphere ESXi 7.0.x

OpenStack distributions

Guest VMs

[1] SUSE Enterprise Linux guests are validated to run on RHEL hosts. However, SUSE Linux uses the btrfs file system by default, which is unsupported by RHEL. Therefore, converting a SUSE system that use btrfs is not possible with virt-v2v.

In addition, VMs that use X graphics and a SUSE Linux Enterprise Server 11 operating system should be re-adjusted after the conversion for the graphics to work properly. To do so, use the sax2 distribution tool in the guest OS after the migration is finished.

[2] As a Technology Preview, converting Debian and Ubuntu VMs is not supported. In addition, this conversion currently has the following known issues: * virt-v2v cannot change the default kernel in the GRUB2 configuration, and the kernel configured in the VM is not changed during the conversion, even if a more optimal version of the kernel is available on the VM. * After converting a linux virtual machine to KVM, the name of the VM's network interface may change, and thus requires manual configuration.

Note: virt-v2v conversions of any operating system not listed above may in some cases work, but are not supported by Red Hat.

• Refer to the "Supporting Conversions" section of .

Definition

Migration refers to the process of transferring Virtual Machines and their associated resources from a VMware environment to an OpenStack environment. It involves multiple steps, including planning (creating a Migration Plan), discovery (fetching VM resource information), and the actual migration execution. During migration, users provide details such as migration name, and description, select VMs, map networks, map volume types, and configure specific parameters for each VM. The goal is to seamlessly move VM workloads while preserving their configurations and ensuring compatibility with the target OpenStack environment. Successful migration results in VMs running efficiently within the OpenStack infrastructure.

Creation

Once the VMs of the Migration Plan are discovered (), the user can initiate the migration.

Trilio provides 3 types of migrations and the user can choose as per their need, more details can be found .

1. Dry-run Migration:

   • Create VMs on OpenStack with attached storage volumes, networking, and security groups for testing purposes while migrating the VM snapshot data from VMware.

2. Cold Migration:

   • Shut down VMware virtual machines and then migrate them to OpenStack. This process can take minutes to hours and may cause significant downtime, making it more disruptive.

While initiating the migration, the user needs to provide a few more below-mentioned information to ensure a seamless migration of the VMs.

Details

To perform the actual migration, users need to:

• Provide a name and description for the migration.

• Choose the type of migration from a drop-down menu.

Network Mapping

During migration, users can:

• Map-enabled networks in Guest VMs to OpenStack Networks.

• Trilio automatically detects networks, providing a seamless mapping experience.

Volume Types Mapping

Users need to:

• Map Datastores detected from the migration plan VMs with OpenStack volume types.

• This ensures proper mapping of storage resources during migration.

VM Selection

Users must:

• Select VMs mapped to the Migration Plan for migration.

• For each VM, choose the correct flavor and Availability Zone.

• Specify configurations for disks to be created on OpenStack.

• For the VMs that are UEFI booted, a glance image must be selected. Refer to for more details.

Resume Cutover

This option applies only to warm migrations with manual cutover (default).

Once the migration process reaches the stage where the second snapshot of the source VM has been successfully uploaded, the migration enters a Paused state. At this point, the process waits for the user to perform the Resume Cutover action.

Resuming cutover allows Trilio to shut down the source VM and begin the final stage of data transfer.

There is no time limit for this wait; however, it is recommended to resume the operation as soon as possible. Delaying may result in additional data being written to the source VM, which can increase the overall cutover time.

Cancel Migration

At any stage, if users decide not to continue with the migration, they can cancel the operation. This action reverts any changes and cleans up the OpenStack resources created for that migration.

The Cancel option is available for all types of migrations and at any stage, including when the migration is in a Paused state.

Migration Overview

The Migration Overview page provides a comprehensive summary of a migration job. It displays key details, progress indicators, and status information to help users monitor and analyze the migration process.

Details Displayed

• Name – The unique name assigned to the migration job.

• Description – An optional user-provided description for easier identification.

• Migration Type – Indicates the type of migration (e.g., warm, cold).

• Status – Current state of the migration (e.g., Running, Paused, Completed, Failed).

Progress Tracking

• Progress Messages – A detailed list of migration tasks, each showing:

  • Task name

  • Progress percentage

  • Status (e.g., In Progress, Completed, Failed)

Execution Environment

• Workload Manager Host – The hostname of the workload manager where the migration is scheduled.

• Migration Options – The options selected while invoking the migration (e.g., automatic or manual cutover, additional configuration settings).

Migration Deletion

Deletion of the initiated Migrations can be done to clean up the unnecessary entries in the list. Please note that deleting a migration does not clean up the migrated VMs or their associated resources from OpenStack. The user will have to explicitly remove the migrated resources if necessary.

Each Trilio Workload has a dedicated owner. The ownership of a Workload is defined by:

• Openstack User - The Openstack User-ID is assigned to a Workload

• Openstack Project - The Openstack Project-ID is assigned to a Workload

• Openstack Cloud - The Trilio Serviceuser-ID is assigned to a Workload

This ownership secures, that only the owners of a Workload are able to work with it.

Openstack Administrators can reassign Workloads or reimport Workloads from older Trilio installations.

Import workloads

Workload import allows to import Workloads existing on the Backup Target into the Trilio database.

To get a list of importable Workloads use the following CLI command:

• --project_id <project_id> ➡️ List workloads belongs to given project only.

To import Workloads into the Trilio database use the following CLI command:

• --workloadids <workloadid> ➡️ Specify workload ids to import only specified workloads. Repeat option for multiple workloads.

Orphaned Workloads

The definition of an orphaned Workload is from the perspective of a specific Trilio installation. Any workload that is located on the Backup Target Storage, but not known to the TrilioVualt installation is considered orphaned.

Further is to divide between Workloads that were previously owned by Projects/Users in the same cloud or are migrated from a different cloud.

The following CLI command provides the list of orphaned workloads:

• --migrate_cloud {True,False} ➡️ Set to True if you want to list workloads from other clouds as well. Default is False.

• --generate_yaml {True,False} ➡️ Set to True if want to generate output file in yaml format, which would be further used as input for workload reassign API.

Reassigning Workloads

Openstack administrators are able to reassign a Workload to a new owner. This involves the possibility to migrate a Workload from one cloud to another or between projects.

Use the following CLI command to reassign a Workload:

• --old_tenant_ids <old_tenant_id>➡️ Specify old tenant ids from which workloads need to reassign to new tenant. Specify multiple times to choose Workloads from multiple tenants.

• --new_tenant_id <new_tenant_id> ➡️ Specify new tenant id to which workloads need to reassign from old tenant. Only one target tenant can be specified.

• --workload_ids <workload_id>

A sample mapping file with explanations is shown below:

Trilio Branch

Branch of the repository to be used for DevOps scripts.

Deployment Scripts

Deployment Scripts

Preparing vCenter + OpenStack + Trilio

You will need to be ready with the following resources before starting with the deployment:

VMware Resources