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.

About Trilio for OpenStack

T4O, by Trilio Data, is a native OpenStack service-based solution that provides policy-based comprehensive backup and recovery for OpenStack workloads. It captures point-in-time workloads (Application, OS, Compute, Network, Configurations, Data, and Metadata of an environment) as full or incremental snapshots. These snapshots can be held in a variety of storage environments including NFS, AWS S3, and other S3-compatible storages. With Trilio and its one-click recovery, organizations can improve Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO). With Trilio, IT departments are enabled to fully deploy OpenStack solutions and provide business assurance through enhanced data retention, protection, and integrity.

With the use of Trilio’s VAST (Virtual Snapshot Technology), Enterprise IT and Cloud Service Providers can now deploy backup and disaster recovery as a service to prevent data loss or data corruption through point-in-time snapshots and seamless one-click recovery. Trilio takes point-in-time backup of the entire workload consisting of compute resources, network configurations, and storage data as one unit. It also takes incremental backups that capture only the changes that were made since the last backup. Incremental snapshots save a considerable amount of storage space as the backup only includes changes since the last backup. The benefits of using VAST for backup and restore could be summarized below:

About this Documentation

This documentation serves as the end-user technical resource to accompany Trilio for OpenStack. You will learn about the architecture, installation, and vast number of operations of this product. The intended audience is anyone who wants to understand the value, operations, and nuances of protecting their cloud-native applications with Trilio for OpenStack.

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.

Trilio for OpenStack Compatibility Matrix

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.

Consequently, it becomes imperative for each tenant benefiting from Trilio's backup functionality to possess adequate Cinder snapshot quotas capable of accommodating these supplementary snapshots. As a guiding principle, it is recommended to append 2 snapshots for each volume incorporated into the backup quotas for the respective tenant. Additionally, a commensurate increase in volume quotas for the tenant is advisable, as Trilio briefly materializes a volume from the snapshot to access data for backup purposes.

During the restoration process, Trilio generates supplementary instances and Cinder volumes. To facilitate seamless restore operations, tenants should maintain adequate quota levels for Nova instances and Cinder volumes. Failure to meet these quota requirements may lead to disruptions in restoration procedures.

AWS S3 Eventual Consistency

The AWS S3 object consistency model includes:

1. Read-after-write

2. Read-after-update

3. Read-after-delete

Each of these models explains how an object becomes consistent after being created, updated, or deleted. None of these methods ensures strong consistency, leading to a delay before an object becomes fully consistent.

Although Trilio has introduced measures to address AWS S3's eventual consistency limitations, the exact time an object achieves consistency cannot be predicted through deterministic means.

There is no official statement from AWS on how long it takes for an object to reach a consistent state. However, read-after-write has a shorter time to reach consistency compared to other IO patterns. Therefore, our solution is designed to maximize the read-after-write IO pattern.

AWS Region Considerations

The time in which an object reaches eventual consistency also depends on the AWS region.

For instance, the AWS-standard region doesn't offer the same level of strong consistency as regions like us-east or us-west. Opting for these regions when setting up S3 buckets for Trilio is advisable. While fully avoiding the read-after-update IO pattern is complex, we've introduced significant access delays for objects to achieve consistency over longer periods. On rare occasions when this does happen, it will cause a backup failure and require a retry.

Trilio Cluster

Trilio can be deployed as a single node or a three-node cluster. It is highly recommended that Trilio is deployed as a three-node cluster for fault tolerance and load balancing. Starting with the 3.0 release, Trilio requires additional IP or FQDN for the cluster and is required for both single-node and three-node deployments. Cluster IP a.k.a virtual IP is used for managing clusters and is used to register the Trilio service endpoint in the keystone service catalog.

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

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

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.

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

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.

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.

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:

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:

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.

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.

The following versions can be upgraded to each other:

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.

Deployment Scripts

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

Container Information

Package Repositories & Versions

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

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. 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.

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.

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.

• Trilio does not support nested virtualization OpenStack deployments for VMware migration.

• For Windows VMs, post migration, if the secondary disks are in an Offline state, you would need to log in to the guest VM and manually bring all the attached disks online by following any of the below steps:\

  1. Disk Management Console:

     • Open Disk Management. You can do this by searching for "Computer Management" in the taskbar and navigating to Storage > Disk Management.
• Windows VMs migrated with the Dry-Run type won't be bootable on OpenStack, as complete boot information won't be available until the guest VM is shut down.

Please refer to for more information.

Other Limitations specific to VM Migration:

• If any VM is having independent (i.e. not mounted on "/") /usr partition, then migration of such VM will fail with below error:

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

Trilio is using the Openstack Keystone Trust system 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

List all trusts

Show a trust

• <trust_id> ➡️ ID of the trust to show

Create a trust

• <role_name> ➡️Name of the role that trust is created for

• --is_cloud_trust {True,False} ➡️ Set to true if creating cloud admin trust. While creating cloud trust use same user and tenant which used to configure Trilio and keep the role admin.

Delete a trust

• <trust_id> ➡️ ID of the trust to be deleted

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.

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:

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. 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.

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.

Prerequisites

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

1. Access to the VMware environment.

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.

Deployment Scripts

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

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

git clone -b 5.2.2 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.

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.

Deployment Scripts

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

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

git clone -b 5.2.1 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.

Overview

Architecture

Native Service to OpenStack

Trilio’s backup and recovery solution is an OpenStack native service similar to Nova, Cinder, Glance, etc. This software-only solution can be deployed using OpenStack distribution-specific DevOps scripts. For example, Trilio’s solution is native to the RHOSP platform and can be deployed and managed using Red Hat Director.

Highly Scalable

We extended Trilio’s architecture to support migration at scale. Since Trilio migrates the VM from VMware ESXi to the OpenStack compute node, the solution scales with your VMware/OpenStack without suffering from performance bottlenecks.

Self-Service and Inline Migration

The process of migration usually involves moving virtual machines from a source platform to a target platform, however, the strategy to achieve this should be considered carefully.

If the migration process is initiated from the target platform, it is called inline migration. Trilio advocates inline migration as it helps map organizational structures such as data centers/clusters/folders in VMware to regions/domains/projects in OpenStack.

A project owner with sufficient privileges to their VMware resources can migrate the VMs to their project. If every project owner can migrate their resources from VMware, it provides better control to cloud architects to orchestrate the migration.

If the migration process is initiated from an outside source or target platform, it is called out-of-band migration. Out-of-band demands a centralized approach and places constraints on how cloud architects can design their OpenStack clouds.

Horizon Dashboard Plugin

A very intuitive tenant dashboard for the tenant to manage their migrations. If you want to migrate to KubeVirt, Red Hat’s solution can be helpful.

Command Line Interface

The sub-commands for the migration feature are available as:

Migration APIs look and feel like OpenStack API. Each tenant can source their cloud rc and start using migration cli commands. CLI also helps users to extend their Ansible scripting for migration.

Migration Types

Trilio migration functionality supports three types of migrations

Dry-run

Dry-run lets users create the VMs on OpenStack with storage volumes, networking, and security groups attached. It does a migration of VM data from VMware to OpenStack by taking a snapshot of the VM without shutting it down and hence, does not guarantee the data/application consistency. Unlike Cold and Warm migration, there is no disruption to the VMware VMs during this migration. It is a handy feature for users to test VMs and their interconnectivity before completely migrating VMs.

Cold Migration

Cold migration shuts down the VMware VMs and migrates the VMs to OpenStack. Depending on the size of the data to migrate, cold migration can take minutes to hours to complete, and during the entire duration, the applications are unavailable. Cold migration is more disruptive than warm migration.

Warm Migration

Warm migration leverages VMware snapshot and Change Block Tracking functionality to migrate VMs with minimal disruption. It first takes a VM snapshot and copies the full snapshot data to OpenStack. Depending on the size of the data, this upload operation may take a few minutes to a few hours. During this period, the VM may have written additional data blocks, which are then captured by taking a second snapshot of the VM.

At this point, the cutover occurs as per the option selected by the user during invoking the migration:

• Manual cutover (default): After the second snapshot upload, the migration process pauses. The user must manually resume the migration once they are ready for the source VM to be shut down and the final data upload to be performed.

• Automatic cutover: After the second snapshot upload, the source VM is automatically shut down, and the final data upload is performed without user intervention.

In both cases, after the final snapshot is uploaded, the corresponding VM is started on OpenStack. Warm migration therefore provides significantly less downtime compared to cold migration.

Conclusion

Trilio's support for migrating VMware VMs to OpenStack is recognized as an industry-leading solution. Its scalability and ability to be deployed organization-wide scale make it a valuable choice for businesses. The self-paced approach provided by Trilio allows application owners to experiment with migration options and gain confidence before performing the final migration. In the context of businesses transitioning from vendor lock-in to open-source technologies, Trilio's migration feature can be a helpful tool in accelerating the transition process.

Deployment Scripts

Trilio Branch

Branch of the repository to be used for DevOps scripts.

Trilio Branch

Branch of the repository to be used for DevOps scripts.

Trilio Branch

Branch of the repository to be used for DevOps scripts.

Trilio Branch

Branch of the repository to be used for DevOps scripts.

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.

Prerequisites

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

1. Access to the VMware environment.

5.2.7 (2025-11-21)

What's New?

1. Support for Kolla Epoxy on Ubuntu & Rocky9 added.

2. Support for Kolla Dalmatian (2024.2) on Ubuntu & Rocky9 added.

3. Bug Fixes:

   • VMware migration failing with error source guest could not be detected.

   • VMware to openstack migration removes default routes of VM.

Known Issues