Tintri Storage Configurations

Overview

Tintri VMstore appliances provide VM-aware, NFS-based storage with built-in analytics and space-efficient snapshots. Platform9 Private Cloud Director integrates with Tintri systems via the Tintri driver, supporting storage volumes and images.

Custom driver deployment

The Tintri driver is deployed as a custom driver. Contact Platform9 support to verify the availability of the Tintri driver for your deployment.

Prerequisites

Before you configure the Tintri NFS backend, complete these requirements:

• Tintri VMstore appliance configured and accessible from Platform9 control plane hosts.
• Install nfs-common package on all hypervisor hosts and block-storage hosts:

  apt-get install nfs-common

The nfs-common package provides NFS client functionality that Platform9 requires to mount Tintri NFS exports.

• Create NFS exports on the Tintri appliance for volume storage. Platform9 mounts these exports to store volume data.
• Configure NFSv3 connectivity between hosts and the Tintri appliance for backend storage operations.
• (Optional) Configure NFSv4 connectivity for Glance image storage if using Tintri as an image backend.

Volume backend configuration

Tintri-specific configuration parameters, shown below, are entered in the Persistent Storage Connectivity section of the Cluster Blueprint in the Private Cloud Director Web UI. These parameters are then automatically propagated to hosts that have the Block Storage Role assigned via Infrastructure > Cluster Hosts.

[tintri_nfs_backend]
volume_driver = cinder.volume.drivers.vmstore.nfs.VmstoreNfsDriver
volume_backend_name = tintri_nfs
nas_host = <TINTRI_NFS_IP>
nas_share_path = /tintri/cinder
vmstore_user = <TINTRI_USER>
vmstore_password = <TINTRI_PASSWORD>
vmstore_rest_address = <TINTRI_MGMT_IP>
nfs_mount_options = vers=3,proto=tcp,lookupcache=pos,nolock,noacl
nfs_snapshot_support = true
vmstore_qcow2_volumes = true

Configuration parameters

• nas_host: IP address or hostname of the Tintri NFS server hosting the volume exports.
• nas_share_path: NFS export path on the Tintri appliance where Platform9 stores volumes.
• vmstore_rest_address: IP address or hostname of the Tintri management interface for REST API access. Do not include https:// prefix; the driver automatically adds the appropriate API URL.
• nfs_mount_options: NFS mount options for Platform9 to mount Tintri exports:

  • vers=3: Use NFSv3 protocol (required for Tintri backend)
  • proto=tcp: Use TCP protocol for reliable data transfer
  • lookupcache=pos: Cache positive lookup results for performance
  • nolock: Disable NFS file locking for compatibility
  • noacl: Disable NFS ACL support to avoid permission issues These options are required for proper Tintri integration. Do not modify unless directed by Platform9 support.
• nfs_snapshot_support: Enables space-efficient snapshot support on the Tintri backend. Tintri snapshots are instant and require no additional storage space.
• vmstore_qcow2_volumes: Stores volumes in QCOW2 format, enabling thin provisioning and efficient space utilization.

Image storage with NFSv4

Tintri supports NFSv4 for image storage as an externally mounted backend. This configuration is separate from the Cinder volume backend and allows you to store VM images on Tintri arrays.

To configure Tintri as an image backend:

1. Create an NFSv4 export on the Tintri appliance for image storage.
2. Mount the NFSv4 export on Image hosts using appropriate mount options.
3. Configure Glance to use the mounted path as a file-based backend.

Protocol version difference is storage volume backend requires NFSv3, while image storage supports NFSv4. These are separate configurations and use different NFS protocol versions.

Configuration notes

• The Tintri driver requires NFSv3 for storage backend operations. NFSv4 is not supported for volume storage.
• NFSv4 may be used for Glance image storage when Tintri is used as an external image backend.
• VM-level QoS and analytics are managed through the Tintri VMstore management UI, not through Platform9.
• Snapshot and clone operations are space-efficient and instant, enabling rapid backup and recovery workflows.
• The driver works with VJailbreak migrations for VM mobility between environments.
• Volumes retyped to the Tintri backend can now be snapshotted successfully.

Multi-VMstore deployments

When using multiple Tintri VMstore appliances in the same environment, assign a unique volume_backend_name to each VMstore backend configuration. Do not use the same volume_backend_name across backends that point to different nas_host addresses.

The Tintri driver's snapshot and clone operations call the source VMstore's API directly. If the block storage scheduler routes a snapshot-based clone request to a host that connects to a different VMstore than the one holding the snapshot, the driver cannot locate the snapshot and the clone fails. Using one unique volume_backend_name per VMstore keeps snapshot-based operations local to the VMstore where the data resides.

If your deployment requires multiple VMstore appliances to share the same volume_backend_name, set snapshot_same_host = true in the volume backend configuration for those backends. This forces the block storage scheduler to always place snapshot-based clones on the same host where the snapshot resides, avoiding cross-VMstore failures.

Related Pages

• Volume Snapshot: create and manage point-in-time volume snapshots
• Volume Migration and Retype Troubleshooting: diagnose failed or stalled volume migration and retype operations