5.2.4 (2024-09-18)

What's New?

1. Support for Kolla Caracal on Rocky9 added

2. Support for Canonical Antelope & Bobcat on Jammy added

3. Bug Fixes

Fixed Bugs and Issues

1. Hide the VMware/Virtual Machine Migration related menus, if that feature is not active.

2. Issue where some volume were not being attached after restore.

3. S3 logging is now fixed.

4. Slow performance while creating snapshot identified and fixed.

5. Periods of inactivity identified during full snapshot of large volume.

6. Deployment failing on kolla-anisble Antelope.

7. Modify workload by another tenant user brought workload in error.

8. Fixed issue where Trilio looked for instance in wrong region if OpenStack is multi region.

9. Restore failing with security group not found.

10. Backup failing with multipath device not found.

11. Backup failing due to virtual size of LUN zero.

12. Backup Failure in contego; error in _refresh_multipath_size call. Unexpected error while running command tee -a /sys/bus/scsi/drivers/sd/None:None:None:None/rescan

Known Issues

1. Upgrade of python3-oslo.messaging breaks Trilio in Juju

   • The Trilio charms should not allow installations of python3-oslo.messaging newer than 12.1.6-0ubuntu1, as they disrupt correct RabbitMQ connectivity from the trilio-wlm units.

   • Workaround: Run below commands

     Copy

     juju run --app trilio-wlm "sudo apt install python3-oslo.messaging=12.1.6-0ubuntu1 -y --allow-downgrades"
     juju run --app trilio-wlm "sudo apt-mark hold python3-oslo.messaging"

2. RHOSP16.1/16.2 : Unexpected behavior with OpenStack Horizon Dashboard

   • At times, after the overcloud deployment, the OpenStack Horizon Dashboard encounters issues, leading to unexpected behavior in certain functionalities.

   • Workaround:

     1. Login to the Horizon container and run the following commands: podman exec -it -u root horizon /bin/bash /usr/bin/python3 /usr/share/openstack-dashboard/manage.py collectstatic --clear --noinput /usr/bin/python3 /usr/share/openstack-dashboard/manage.py compress --force

     2. Restart the Horizon container : podman restart horizon

3. Horizon pod keeps restarting on RHOSP 16.2.4

   • It has been observed that on a specific RHOSP minor version, i.e. 16.2.4, the Horizon pod keeps restarting.

   • The issue has been identified with Memcached. Either of the below workarounds can be performed on all the controller nodes where the issue seems to occur.

   • Workaround:

     1. Workaround 1 : Restart the memcached service on the controller using systemctl systemctl restart tripleo_memcached.service

     2. Workaround 2 : Restart the memcached pod podman restart memcached

4. get-importworkload-list and get-orphaned-workloads-list show incorrect workloads

   • The commands get-importworkload-list and get-orphaned-workloads-list show incorrect workloads in the output.

   • Workaround:

     • Use --project option with get-importworkload-list CLI command to get the list of workloads that can be imported on any particular project of the OpenStack. workloadmgr workload-get-importworkloads-list --project_id <project_id>

5. workload-importworklaods cli command throws gateway timed out error

   • workload-importworklaods CLI command throws gateway timed out error, however, import actually succeeds.

   • In the background, the import process continues to run in spite of timeout until the operation is complete.

   • Workaround:

     • To avoid the timeout error, the respective timeout server value can be increased inside /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg for RHOSP

5.2.3 (2024-07-05)

What's New?

1. VMware Migration Mapping Dashboard

2. Bug Fixes

Fixed Bugs and Issues

1. [VMware Migration] boot options shows BIOS when the guest VM has unsecured EFI boot.

2. wlm client does not work on mac having python 3.10.

3. Cloud admin trust creation was failing.

4. Modify workload with other user brings workload in error.

5. Trilio looks for instance in wrong region if OpenStack is multi region

Known Issues

1. Encryption checkbox is disabled when creating 1st workload from UI

   • While creating 1st workload from the UI, the Enable Encryption checkbox on the Create workload page is disabled. Creating a non-encrypted workload first will resolve this issue and the user can start creating the encrypted workloads.

2. RHOSP16.1/16.2 : Unexpected behavior with OpenStack UI

   • At times, after the overcloud deployment, the OpenStack UI encounters issues, leading to unexpected behavior in certain functionalities.

   • Workaround:

     1. Login to the Horizon container and run the following commands: podman exec -it -u root horizon /bin/bash /usr/bin/python3 /usr/share/openstack-dashboard/manage.py collectstatic --clear --noinput /usr/bin/python3 /usr/share/openstack-dashboard/manage.py compress --force

     2. Restart the Horizon container : podman restart horizon

3. Horizon pod keeps restarting on RHOSP 16.2.4

   • It has been observed that on a specific RHOSP minor version, i.e. 16.2.4, the horizon pod keeps restarting.

   • Either of the below workarounds can be performed on all the controller nodes where the issue seems to occur.

   • Workaround:

     1. Workaround 1 : Restart the memcached service on the controller using systemctl systemctl restart tripleo_memcached.service

     2. Workaround 2 : Restart the memcached pod podman restart memcached

4. get-importworkload-list and get-orphaned-workloads-list show incorrect workloads

   • The commands get-importworkload-list and get-orphaned-workloads-list show incorrect workloads in the output.

   • Workaround:

     • Use --project option with get-importworkload-list CLI command to get the list of workloads that can be imported on any particular project of the OpenStack. workloadmgr workload-get-importworkloads-list --project_id <project_id>

5. workload-importworklaods cli command throws gateway timed out error

   • workload-importworklaods CLI command throws gateway timed out error, however, import actually succeeds.

   • In the background, the import process continues to run in spite of timeout until the operation is complete.

   • Workaround:

     • To avoid the timeout error, the respective timeout server value can be increased inside /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg for RHOSP

5.2.2 (2024-04-22)

What's New?

1. Support for Kolla Bobcat OpenStack added.

2. Fixed the issues reported by customers.

Fixed Bugs and Issues

1. [VMware Migration] Migration failure due to minor issues in handling vm and network names.

2. [VMware migration] boot options shows BIOS when the guest VM has unsecured efi boot.

3. [VMware Migration] Migration fails when the network name of the guest VM contains - and _ both.

4. Support multi ceph config in same /etc/ceph location.

5. Trilio looks for instance in wrong region if openstack is multi region.

6. T4O deployment on Kolla Antelope failing. DMAPI and horizon container fail to start.

7. Quota updation when admin user have access to projects of multiple domains

Known Issues

1. Encryption checkbox is disabled when creating 1st workload from UI

   • While creating 1st workload from the UI, the Enable Encryption checkbox on the Create workload page is disabled. Creating a non-encrypted workload first will resolve this issue and the user can start creating the encrypted workloads.

2. RHOSP16.1/16.2 : Unexpected behavior with OpenStack UI

   • At times, after the overcloud deployment, the OpenStack UI encounters issues, leading to unexpected behavior in certain functionalities.

   • Workaround:

     1. Login to the Horizon container and run the following commands: podman exec -it -u root horizon /bin/bash /usr/bin/python3 /usr/share/openstack-dashboard/manage.py collectstatic --clear --noinput /usr/bin/python3 /usr/share/openstack-dashboard/manage.py compress --force

     2. Restart the Horizon container : podman restart horizon

3. Horizon pod keeps restarting on RHOSP 16.2.4

   • It has been observed that on a specific RHOSP minor version, i.e. 16.2.4, the horizon pod keeps restarting.

   • Either of the below workarounds can be performed on all the controller nodes where the issue seems to occur.

   • Workaround:

     1. Workaround 1 : Restart the memcached service on the controller using systemctl systemctl restart tripleo_memcached.service

     2. Workaround 2 : Restart the memcached pod podman restart memcached

4. get-importworkload-list and get-orphaned-workloads-list show incorrect workloads

   • The commands get-importworkload-list and get-orphaned-workloads-list show incorrect workloads in the output.

   • Workaround:

     • Use --project option with get-importworkload-list CLI command to get the list of workloads that can be imported on any particular project of the OpenStack. workloadmgr workload-get-importworkloads-list --project_id <project_id>

5. workload-importworklaods cli command throws gateway timed out error

   • workload-importworklaods CLI command throws gateway timed out error, however, import actually succeeds.

   • In the background, the import process continues to run in spite of timeout until the operation is complete.

   • Workaround:

     • To avoid the timeout error, the respective timeout server value can be increased inside /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg for RHOSP

5.2.1

What's New?

1. Software Driven Migration : VMware to OpenStack With T4O-5.2.1 release, Trilio now supports migration of VMs from VMware to OpenStack.

2. Fixed the issues reported by customers.

Fixed Bugs and issues

1. Support multi ceph config in same /etc/ceph location.

2. Encrypted incremental restore fails to diff AZ.

3. Trilio installation failing for RHOSP17.1 IPV6.

4. [RHOSP] memcache_servers parameter in triliovault wlm and datamover service conf files fixed for ipv6.

5. Deployment (with non-root user) failing on kolla with barbican.

6. T4O 5.1 failing on Kolla Zed rocky

7. 5.2 deployment failing on Antelope with ansible node on separate server.

8. WLM service issue with IPV6. Containers keep restarting due to Data too long for column ip_addresses at row 1.

Known Issues

1. RHOSP16.1/16.2 : Unexpected behavior with OpenStack UI

   • At times, after the overcloud deployment, the OpenStack UI encounters issues, leading to unexpected behavior in certain functionalities.

   • Workaround:

     1. Login to the Horizon container and run the following commands: podman exec -it -u root horizon /bin/bash /usr/bin/python3 /usr/share/openstack-dashboard/manage.py collectstatic --clear --noinput /usr/bin/python3 /usr/share/openstack-dashboard/manage.py compress --force

     2. Restart the Horizon container : podman restart horizon

2. Horizon pod keeps restarting on RHOSP 16.2.4

   • It has been observed that on a specific RHOSP minor version, i.e. 16.2.4, the horizon pod keeps restarting.

   • Either of the below workarounds can be performed on all the controller nodes where the issue seems to occur.

   • Workaround:

     1. Workaround 1 : Restart the memcached service on the controller using systemctl systemctl restart tripleo_memcached.service

     2. Workaround 2 : Restart the memcached pod podman restart memcached

3. get-importworkload-list and get-orphaned-workloads-list show incorrect workloads

   • The commands get-importworkload-list and get-orphaned-workloads-list show incorrect workloads in the output.

   • Workaround:

     • Use --project option with get-importworkload-list CLI command to get the list of workloads that can be imported on any particular project of the OpenStack. workloadmgr workload-get-importworkloads-list --project_id <project_id>

4. workload-importworklaods cli command throws gateway timed out error

   • workload-importworklaods CLI command throws gateway timed out error, however, import actually succeeds.

   • In the background, the import process continues to run in spite of timeout until the operation is complete.

   • Workaround:

     • To avoid the timeout error, the respective timeout server value can be increased inside /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg for RHOSP

5.2.0

What's New?

• New OpenStack additions in Trilio support matrix: With T4O-5.2.0, Trilio now supports backup and DR for RHOSP17.1 and Kolla-Ansible OpenStack 2023.1 Antelope on Rocky Linux & Ubuntu Jammy.

Known Issues

1. RHOSP16.1/16.2 : Unexpected behavior with OpenStack UI

   • At times, after the overcloud deployment, the OpenStack UI encounters issues, leading to unexpected behavior in certain functionalities.

   • Workaround:

     1. Login to the Horizon container and run the following commands: podman exec -it -u root horizon /bin/bash /usr/bin/python3 /usr/share/openstack-dashboard/manage.py collectstatic --clear --noinput /usr/bin/python3 /usr/share/openstack-dashboard/manage.py compress --force

     2. Restart the Horizon container : podman restart horizon

2. Horizon pod keeps restarting on RHOSP 16.2.4

   • It has been observed that on a specific RHOSP minor version, i.e. 16.2.4, the horizon pod keeps restarting.

   • Either of the below workarounds can be performed on all the controller nodes where the issue seems to occur.

   • Workaround:

     1. Workaround 1 : Restart the memcached service on the controller using systemctl systemctl restart tripleo_memcached.service

     2. Workaround 2 : Restart the memcached pod podman restart memcached

3. get-importworkload-list and get-orphaned-workloads-list show incorrect workloads

   • The commands get-importworkload-list and get-orphaned-workloads-list show incorrect workloads in the output.

   • Workaround:

     • Use --project option with get-importworkload-list CLI command to get the list of workloads that can be imported on any particular project of the OpenStack. workloadmgr workload-get-importworkloads-list --project_id <project_id>

4. workload-importworklaods cli command throws gateway timed out error

   • workload-importworklaods CLI command throws gateway timed out error, however, import actually succeeds.

   • In the background, the import process continues to run in spite of timeout until the operation is complete.

   • Workaround:

     • To avoid the timeout error, the respective timeout server value can be increased inside /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg for RHOSP

5.1.0

What's New?

• True Native and Containerized Deployment: In the T4O-5.1.0 release, Trilio has embraced a transformative shift. Departing from the traditional method of shipping appliance images, T4O has evolved into a comprehensive backup and recovery solution that is fully containerized. Within this iteration, all T4O services have been elegantly encapsulated within containers, seamlessly aligning with OpenStack through its innate deployment process.

• New OpenStack additions in Trilio support matrix: With T4O-5.1.0, Trilio now supports backup and DR for Kolla-Ansible OpenStack Zed on Rocky Linux and Ubuntu Jammy.

Known Issues

1. Horizon pod keeps restarting on RHOSP 16.2.4

   • It has been observed that on a specific RHOSP minor version, i.e. 16.2.4, the horizon pod keeps restarting.

   • Either of the below workarounds can be performed on all the controller nodes where the issue seems to occur.

   • Workaround:

     1. Workaround 1 : Restart the memcached service on the controller using systemctl systemctl restart tripleo_memcached.service

     2. Workaround 2 : Restart the memcached pod podman restart memcached

2. get-importworkload-list and get-orphaned-workloads-list show incorrect workloads

   • The commands get-importworkload-list and get-orphaned-workloads-list show incorrect workloads in the output.

   • Workaround:

     • Use --project option with get-importworkload-list CLI command to get the list of workloads that can be imported on any particular project of the OpenStack. workloadmgr workload-get-importworkloads-list --project_id <project_id>

3. workload-importworklaods cli command throws gateway timed out error

   • workload-importworklaods CLI command throws gateway timed out error, however, import actually succeeds.

   • In the background, the import process continues to run in spite of timeout until the operation is complete.

   • Workaround:

     • To avoid the timeout error, the respective timeout server value can be increased inside /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg for RHOSP

5.0.0

What's New?

• True Native and Containerized Deployment: In the T4O-5.0.0 release, Trilio has embraced a transformative shift. Departing from the traditional method of shipping appliance images, T4O has evolved into a comprehensive backup and recovery solution that is fully containerized. Within this iteration, all T4O services have been elegantly encapsulated within containers, seamlessly aligning with OpenStack through its innate deployment process.

• Faster Snapshot operation (Removal of Workload types: Serial and Parallel): In a move to boost Snapshot operation efficiency, we've introduced a streamlined method for creating workloads, eliminating the need for users to select between different workload types. T4O will now intelligently manage workloads in the background, ensuring optimal performance for backup operations.

• Improved Database Storage: T4O has made significant enhancements to its database management, focusing on efficient data garbage collection. By discarding unnecessary data and optimizing the utilization of DB storage within the task flow, these improvements have led to a leaner and more streamlined storage approach for its DB tables.

• Better Troubleshooting: Enhanced troubleshooting capabilities come through the implementation of a unified logging format across all T4O services/containers. This improvement grants users the freedom to adjust the format or log levels for individual services/containers as needed.

• Updated EULA: Trilio has updated the End User License Agreement (EULA) that users must accept before using the product. For user convenience, T4O now prompts users to review and accept the EULA during the licensing step of the T4O installation. The most recent version of the EULA can be found here: https://trilio.io/eula/

Known Issues

1. Horizon pod keeps restarting on RHOSP 16.2.4

   • It has been observed that on a specific RHOSP minor version, i.e. 16.2.4, the horizon pod keeps restarting.

   • Either of the below workarounds can be performed on all the controller nodes where the issue seems to occur.

   • Workaround:

     1. Workaround 1 : Restart the memcachedservice on the controller using systemctl systemctl restart tripleo_memcached.service

     2. Workaround 2 : Restart the memcached pod podman restart memcached

2. get-importworkload-list and get-orphaned-workloads-list show incorrect workloads

   • Commands get-importworkload-list and get-orphaned-workloads-list show incorrect workloads in the output.

   • Workaround:

     • Use --project option with get-importworkload-list CLI command to get the list of workloads that can be imported on any particular project of the OpenStack. workloadmgr workload-get-importworkloads-list --project_id <project_id>

3. workload-importworklaods cli command throws gateway timed out error

   • workload-importworkloads CLI command throws gateway timed out error, however, import succeeds.

   • In the background, the import process continues to run despite of timeout until the operation is complete.

   • Workaround:

     • To avoid the timeout error, the respective timeout server value can be increased inside /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg for RHOSP

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.

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

Trilio Branch

Branch of the repository to be used for DevOps scripts.

trilio_branch : 5.2.4

Deployment Scripts

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

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

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

Container/Revision Information

Package Repositories & Versions

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

https://pypi.fury.io/trilio-5-2/

deb [trusted=yes] https://apt.fury.io/trilio-5-2/ /

https://yum.fury.io/trilio-5-2/

[trilio-fury]
name=Trilio Gemfury Private Repo
baseurl=https://yum.fury.io/trilio-5-2/
enabled=1
gpgcheck=0

VM Migration Tool

Docker Container Tag

trilio/trilio-migration-vm2os:5.2.4

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.

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.

Trilio for OpenStack Compatibility Matrix

1. Caracal support is currently for Rocky 9 only.

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.

Deployment Scripts

Container Information

Package Repositories & Versions

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

Deployment Scripts

Container Information

Package Repositories & Versions

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

Deployment Scripts

Container Information

Package Repositories & Versions

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