Support Matrix

This page lists the OpenStack distributions and versions, storage backends, hypervisor types, and deployment topologies that TrilioVault for OpenStack officially supports. Use this matrix before you begin any installation or upgrade to confirm that your environment meets the requirements — running TrilioVault on unsupported combinations is not tested and may produce unpredictable behavior. Each section also notes known exclusions and version-specific feature availability so you can plan your deployment accordingly.

Before consulting the support matrix, confirm you have the following baseline information about your environment:

• OpenStack release: TrilioVault requires OpenStack Stein or later. Identify the exact release name (e.g., Stein, Train, Ussuri, Victoria, Wallaby, Xena, Yoga, Zed) running in your cloud.
• Compute service: OpenStack Nova must be deployed and healthy.
• Block storage service: OpenStack Cinder must be deployed. Cinder quotas must accommodate two Cinder snapshots and one temporary volume per disk being backed up at any given time.
• Identity service: OpenStack Keystone must be available; TrilioVault registers its service endpoint against Keystone.
• Python version: Python 3.6 or later on any host running the workloadmgr CLI or workloadmgrclient library.
• Backup target: At least one supported backup target must be reachable — an NFS share, an S3-compatible object storage endpoint, or OpenStack Swift.
• KVM hosts: Dedicated, bare-metal or standalone KVM hosts outside the protected OpenStack cloud on which to run the TrilioVault QCOW2 appliance nodes. TrilioVault nodes cannot run as VMs under the same OpenStack cloud they protect.
• Network VIP: A dedicated cluster IP (virtual IP address) reserved for Pacemaker/HAProxy use, even for single-node deployments. This VIP is registered as the Keystone service endpoint.
• RBAC role: The TrilioVault Trustee role must be available in Keystone and assigned to any user performing workload, snapshot, or restore operations. The OpenStack admin role cannot substitute for the Trustee role.
• Optional tooling: Ansible, Salt, or Juju if you plan to use the triliovault-cfg-scripts configuration management playbooks, states, or charms.

The support matrix is a reference document, not an installation procedure. However, the steps below guide you through verifying that your environment is compatible before you proceed to the TrilioVault installation guide.

1. Identify your OpenStack release.

   Copy

   openstack catalog list
   openstack --version
   

   Confirm the release name is Stein or later. Record the exact version string — you will need it when selecting the correct TrilioVault appliance image.

2. Verify Nova and Cinder are healthy.

   Copy

   openstack compute service list
   openstack volume service list
   

   All services should report enabled and up. Any disabled or down services must be resolved before deploying TrilioVault.

3. Check Cinder quota headroom.

   Copy

   openstack quota show --detail
   

   For each VM disk in your largest anticipated workload, ensure that at least two snapshots and one volume of headroom exist in your Cinder quota. Adjust quotas as needed:

   Copy

   openstack quota set --snapshots <current + 2×disks> --volumes <current + 1×disks> <project-id>
   

4. Confirm KVM host availability.

   TrilioVault ships as a QCOW2 image. Ensure you have standalone KVM hosts outside the OpenStack cloud you intend to protect. Verify KVM is functional:

   Copy

   virsh version
   virt-host-validate
   

5. Reserve a virtual IP address (VIP).

   Allocate a free IP address on your management network to serve as the cluster VIP. This IP is required even for single-node deployments and will be registered as the TrilioVault Keystone endpoint.

6. Validate backup target connectivity.

   • NFS:
     Copy

     showmount -e <nfs-server-ip>
     mount -t nfs <nfs-server-ip>:<export-path> /mnt/test
     umount /mnt/test
     

   • S3-compatible:
     Copy

     curl -I https://<s3-endpoint>/
     

   • Swift:
     Copy

     openstack object store account show
     

7. Verify the Trustee RBAC role exists in Keystone.

   Copy

   openstack role list | grep -i trustee
   

   If the role is absent, create it before proceeding:

   Copy

   openstack role create _member_tvault_trustee
   

   Note: The exact role name is set during TrilioVault installation. Confirm the name with your TrilioVault deployment documentation.

8. Check Python version on CLI hosts.

   Copy

   python3 --version
   

   Output must show Python 3.6 or later before you install the workloadmgr CLI tool from the workloadmanager-client package.

The support matrix itself does not contain tunable parameters, but the compatibility boundaries below reflect constraints that affect how you configure TrilioVault in your environment.

OpenStack Version Compatibility

Use the OpenStack release name (e.g., Ussuri, Wallaby) — not just the year — when filing support requests or consulting TrilioVault release notes.

Storage Backend Compatibility

Key constraint: All read and write operations on the backup target are performed as the nova user. Mismatched UIDs or GIDs between cluster nodes and compute nodes will cause permission errors on the backup target. Verify with:

id nova   # run on each TrilioVault node and each compute node

The UID, GID, and username must match across every host.

Hypervisor Support

Deployment Topology

Service placement within the cluster:

• wlm-api and wlm-scheduler are Pacemaker-controlled and run on the master node only.
• wlm-workloads runs on every TrilioVault node.

Feature-to-Version Matrix

Horizon Dashboard Plugin

The horizon-tvault-plugin requires OpenStack Horizon to be installed. Horizon is optional — TrilioVault is fully operable without it via the workloadmgr CLI or direct REST API calls.

For File Recovery Manager to appear as a valid mount target in the Horizon UI, the Glance image used must have the property tvault_recovery_manager=yes set.

RBAC Configuration

The TrilioVault Trustee role is mandatory. It cannot be replaced by the OpenStack admin role. Assign this role in Keystone to every user or service account that needs to create workloads, trigger snapshots, or initiate restores.

Use this support matrix as a checklist at three points in your TrilioVault lifecycle:

Before Initial Deployment

Work through the matrix top to bottom. Confirm:

• Your OpenStack release is Stein or later.
• You have at least one supported backup target (NFS, S3, or Swift).
• Your compute hosts use KVM/libvirt.
• You have dedicated KVM hosts outside your OpenStack cloud for the TrilioVault appliance.
• A VIP is reserved on the management network.
• Cinder quotas are sufficient.
• The nova user UID/GID is consistent across all relevant hosts.

Before Enabling a New Feature

Check the Feature-to-Version Matrix in the Configuration section. For example, if you want to use an S3-compatible backup target or rely on automatic network topology capture, confirm you are running TrilioVault 3.0 or later:

# Check the running wlm-api version via the WorkloadMgr REST API
curl -s -H "X-Auth-Token: <keystone-token>" \
  http://<vip>:8780/v1/<tenant-id>/versioninfo

Before an Upgrade

Re-validate the matrix for the target TrilioVault version. Pay particular attention to:

• Whether new OpenStack release support has been added or old releases dropped.
• Whether storage backend behavior has changed (e.g., new S3 configuration fields).
• Whether Cinder quota requirements have changed for the workloads you run.

Checking nova User Consistency

This is the most common misconfiguration caught by the support matrix. Run the following on each TrilioVault node and each compute node and compare output:

id nova

Expected output (values must match everywhere):

uid=162(nova) gid=162(nova) groups=162(nova)

If values differ, correct them before configuring any backup target.

Verifying the Trustee Role Assignment

Confirm that the intended backup user has the Trustee role in the correct project:

openstack role assignment list --user <username> --project <project-name> --names

The TrilioVault Trustee role must appear in the output. If it does not, assign it:

openstack role add --user <username> --project <project-name> _member_tvault_trustee

Example 1 — Confirm OpenStack release meets minimum requirement

openstack catalog show identity | grep -i version

Expected output (excerpt):

| endpoints | ...stein... |

If the release is earlier than Stein, TrilioVault is not supported on this cloud.

Example 2 — Verify nova UID/GID consistency across nodes

Run on each TrilioVault appliance node and each compute node:

ssh nova@tvault-node-1 'id nova'
ssh nova@tvault-node-2 'id nova'
ssh nova@tvault-node-3 'id nova'
ssh nova@compute-node-1 'id nova'
ssh nova@compute-node-2 'id nova'

Expected output (identical on every host):

uid=162(nova) gid=162(nova) groups=162(nova)

A mismatch such as uid=165(nova) on a compute node versus uid=162(nova) on a TrilioVault node will cause permission-denied errors when writing snapshots to the backup target.

Example 3 — Validate NFS backup target mount from a TrilioVault node

showmount -e 192.168.10.50
mount -t nfs 192.168.10.50:/exports/triliovault /mnt/tvault-test
ls -la /mnt/tvault-test
umount /mnt/tvault-test

Expected output from ls:

total 0
drwxr-xr-x 2 nova nova  6 Jan 15 09:00 .
drwxr-xr-x 3 root root 60 Jan 15 09:01 ..

The mount must succeed as the nova user and the export must be owned by nova:nova with appropriate permissions.

Example 4 — Validate S3-compatible endpoint reachability (TrilioVault 3.0+)

curl -I https://s3.example.com/triliovault-bucket

Expected output (HTTP 200 or 403 both indicate the endpoint is reachable; 000 or connection refused indicates a network problem):

HTTP/1.1 403 Forbidden
Server: AmazonS3
Content-Type: application/xml

A 403 is expected without credentials and confirms the endpoint is reachable. Configure S3 credentials in TrilioVault after confirming reachability.

Example 5 — Check Cinder quota headroom for a workload with 4 disks

openstack quota show --detail <project-id>

Expected output (excerpt):

| snapshots | 20    | 10      |   # limit | in_use
| volumes   | 20    | 10      |

For 4 disks, you need at least 8 free snapshot slots (4 disks × 2 snapshots each) and 4 free volume slots (4 disks × 1 temporary volume each). In the example above, 10 free slots of each are available — sufficient for this workload.

Example 6 — Verify Trustee role assignment before creating a workload

openstack role assignment list --user alice --project production-app --names

Expected output:

+----------------------+-------+-------+------------------+--------+-----------+
| Role                 | User  | Group | Project          | Domain | Inherited |
+----------------------+-------+-------+------------------+--------+-----------+
| _member_tvault_trustee | alice |       | production-app   |        | False     |
+----------------------+-------+-------+------------------+--------+-----------+

If the Trustee role does not appear, workload and snapshot operations will be denied regardless of any other roles assigned to the user.

Issue 1 — Backup writes fail with "Permission denied" on NFS target

Symptom: Snapshot jobs fail and the wlm-workloads log at /var/log/workloadmgr/workloadmgr-workloads.log shows Permission denied errors when writing to the NFS export.

Likely cause: The POSIX UID or GID of the nova user differs between the TrilioVault node writing the backup and one or more compute nodes, or between TrilioVault nodes and the NFS server export ownership.

Fix:

1. Run id nova on every TrilioVault node and every compute node. Values must be identical.
2. If UIDs or GIDs differ, align them using usermod on the affected hosts:
   Copy

   usermod -u 162 nova
   groupmod -g 162 nova
   

3. Correct ownership on the NFS export:
   Copy

   chown -R 162:162 /exports/triliovault
   

4. Re-run the affected snapshot job.

Issue 2 — S3 backup target option is unavailable in the configuration UI

Symptom: The S3 storage backend option does not appear when configuring a backup target.

Likely cause: You are running a TrilioVault version earlier than 3.0, which did not support S3-compatible targets.

Fix:

1. Check the running version via the WorkloadMgr API:
   Copy

   curl -s -H "X-Auth-Token: <keystone-token>" \
     http://<vip>:8780/v1/<tenant-id>/versioninfo
   

2. If the version is earlier than 3.0, upgrade TrilioVault using the triliovault-cfg-scripts Ansible playbooks or the applicable upgrade procedure for your environment.
3. After upgrading to 3.0 or later, the S3 backend option will be available.

Issue 3 — Network topology restore fails with a conflict error

Symptom: A restore that includes network topology data fails with an error indicating a conflict with existing networking components.

Likely cause: TrilioVault 3.0+ automatically captures the full tenant network topology (networks, subnets, routers, static routes, ports, floating IPs) in every snapshot. Restoring this topology requires the tenant's network space to be completely empty before the restore begins.

Fix:

1. List and delete all networking components in the target tenant before initiating the restore:
   Copy

   openstack floating ip list --project <tenant-id>
   openstack floating ip delete <floating-ip-id>
   openstack port list --project <tenant-id>
   openstack router list --project <tenant-id>
   openstack subnet list --project <tenant-id>
   openstack network list --project <tenant-id>
   

2. Remove routers, subnets, and networks in dependency order (floating IPs → ports → router interfaces → routers → subnets → networks).
3. Retry the restore. After completion, manually reconnect the restored private networks to the public network — TrilioVault does not perform this final step automatically.

Issue 4 — Workload or snapshot operation denied with "403 Forbidden"

Symptom: A user receives a 403 Forbidden response when attempting to create a workload, trigger a snapshot, or initiate a restore, even though the user has the OpenStack admin role.

Likely cause: The TrilioVault Trustee RBAC role is not assigned to the user. The OpenStack admin role cannot substitute for the Trustee role.

Fix:

1. Verify current role assignments:
   Copy

   openstack role assignment list --user <username> --project <project-name> --names
   

2. Assign the Trustee role:
   Copy

   openstack role add --user <username> --project <project-name> _member_tvault_trustee
   

3. Have the user re-authenticate and retry the operation.

Issue 5 — File Recovery Manager image does not appear in Horizon UI

Symptom: When attempting a file-level restore through the horizon-tvault-plugin, the File Recovery Manager image does not appear as a valid mount target.

Likely cause: The Glance image is missing the required property tvault_recovery_manager=yes.

Fix:

1. Identify the File Recovery Manager image ID:
   Copy

   openstack image list | grep -i recovery
   

2. Set the required property:
   Copy

   openstack image set --property tvault_recovery_manager=yes <image-id>
   

3. Refresh the Horizon panel. The image should now appear as a valid mount target for file-level restores.

Issue 6 — wlm-api or wlm-scheduler does not start after a node failover

Symptom: After a node failure or planned maintenance, wlm-api or wlm-scheduler does not start on the new master node.

Likely cause: Both wlm-api and wlm-scheduler are Pacemaker-controlled and run on the master node only. If Pacemaker has not correctly elected a new master, the services will not start automatically.

Fix:

1. Check Pacemaker cluster status:
   Copy

   pcs status
   

2. Identify whether a master node has been elected and whether any resources are in a failed state.
3. If resources are failed, clean and restart them:
   Copy

   pcs resource cleanup
   

4. Confirm wlm-api and wlm-scheduler are running on the master and that wlm-workloads is running on all nodes:
   Copy

   pcs resource show
   

5. Review the wlm-api log at /var/log/workloadmgr/workloadmgr-api.log for additional error details.