Tintri Automation Toolkit – Part 1 – The Basics

There are numerous companies that recognized the usefulness of PowerShell, and how it can help automate their product. The PowerCLI PSSnapin from VMware is a great example.

And now Tintri, the creators of the VMstore, have joined the ranks. Tintri delivers a PowerShell module, called the Tintri Automation Toolkit, that allows administrators to automate the monitoring and management of a VMstore system. The Toolkit also nicely leverages PowerShell constructs such as object piping for enabling end-to-end VM-level automation.

PS-PCL-TintriThese posts will not be providing a detailed description of the VMstore, and all its merits. There are ample other sources available for that. Needless to say you should definitely have a look at the Tintri website if you want to learn more about the VMstore. I listed a couple of other sources at the end of the series.

I was given the opportunity to have a preview of the of the Tintri Automation Toolkit module, and was permitted to play around with the cmdlets in the Tintri lab.

To take away all suspense, I was quite impressed!

The Basics

Note that I was experimenting with a pre-release version of the Tintri module, so some names, parameters and methods might change slightly when the Tintri Automation Toolkit goes GA.

When you start the Tintri PowerShell Toolkit you are greeted with a PowerShell Command window that looks something like this.


You can of course also load the Toolkit inside your own PowerShell or PowerShell ISE session, with the

command. Be sure to check the name of the Tintri module, it might change from the preview version I have been using.

The Tintri module currently weighs in at 47 cmdlets.


Setting up a session with a Tintri VMstore is quite simple. Just pass the name you use for the Tintri VMstore and a user/password combo.

Or with a PSCredential.

Be aware that the Tintri module has a minimum requirement on the VMstore to which you want to connect. The VMstore must be running the Tintri OS 3.0 (which is GA now), or later.

The Tintri module uses a default VMstore concept. The first VMstore you connect to will be the default server. All Tintri Cmdlets, that do not specify an explicit Tintri server, will run against the default VMstore.


The VMstores you are connected to, are stored in the $global:TintriServers variable.

You can run a cmdlet against a specific VMstore by using the TintriServer parameter, which is available on most Cmdlets in the Tintri module.


While I was exploring the Tintri module, I connected to multiple VMstores. The following lines were handy when I needed to reset all open connections and wanted to start with a “fresh” set up.

The script first closes all open connections, and then connects to 2 VMstores. The first connection, in this case $TintriSrv1 will become the “default” connection.

PowerCLI Integration

The Tintri module allows for easy integration with the PowerCLI PSSnapin.

You can use objects returned by a PowerCLI cmdlet, as input for a Tintri module cmdlet.


In this example we get a PowerCLI VirtualMachine object, by using the “Get-VM” cmdlet to query the vSphere Server, and use the returned object as input to a Tintri cmdlet.

The help for the Get-TintriVM cmdlet shows that we can pass a VirtualMachine object over the pipeline.


Using VMstore Features


The VMstore offers the option to clone a VM. This method, since it is performed by the VMstore, is considerable faster than a VM clone done through vCenter, as it leverages native Tintri per-VM clones.

The code to create such a clone looks like this

With the Get-TintriVirtualHostResource you specify to which VMHost in the vSphere environment the VM shall be cloned, and to which VMHost the new VM shall be registered.

Also note how you use the Task object, that is returned by the New-VMTintriClone cmdlet, as input to the Get-TintriTaskStatus cmdlet. This way you can monitor the execution of the clone process.

In the same way you can clone up to 500 VMs at a time. For that you will have to use the New-TintriCloneMany cmdlet.

The Tintri Toolkit also offers a cmdlet, called New-TintriVMNameSequence, that allows you to specify how these cloned VMs shall be named.

A sample script

The resulting VMs, 3 in total will have a DisplayName as defined with the New-TintriVMNameSequence cmdlet.


Note that the New-TintriCloneMany cmdlet returns an array of Task objects. You can use these in the same way to monitor the status of each individual clone process. Note also that the clone VMs take up no additional space (Used Space = 0.00 B) as they are created.


Tintri VMstore provides the ability to create space efficient snapshots of a VM for data protection and for disaster recovery (by replicating to a second VMstore). You can create such Snapshots manually or schedule them.


The manual creation of a Snapshot is done as follows.

The check the creation of the snapshot, you can do

The returned object


The creation of a VMstore snapshot offers some more options.

Note that I used splatting in this example. It is a handy way to avoid long Cmdlet lines.

The Snapshot consistency provides 2 options, CRASH_CONSISTENT and VM_CONSISTENT. See the Tintri VMstore System Administration Manual for more information on these 2 options.

A handy feature, in my opinion, is the Retention time you can define for a Snapshot. It should avoid those “forgotten” snapshots that tend to pollute our Datastores. Note that the minimum value is 2 hours.


The scheduled creation of Snapshots requires the creation of a Schedule. This can be done as follows.

The VMstore supports HOURLY, DAILY, WEEKLY, MONTHLY and QUARTERLY schedules. Depending on the selected scheduletype, you can use additional parameters to fine-tune the schedule. For example, the weekly schedule, has a TintriDaysOfWeek parameter. Some more examples.

Note that you don’t need to assign a VM directly to a Snapshotschedule. You can do that later on, when you “attach” the Snapshotschedule.

To check which snapshot schedule is attached to a specific VM, you can do something like this.

Note that one can define default snapshot schedules at the VMstore level. When they are not active, the CronExpressions property will be empty.


When you want to go back to the default Snapshotschedule, the one that is defined on the VMstore level, you can do.

To see the snapshots for a specific VM, you can do

This returns something like this.


Notice that the snapshots without an expiration data, will show December 31st in 1969 as the expiration time. That is in Linux zero day, which January 1st 1970, minus your time zone offset. This becomes obvious when we convert the property to UTC.

That’s it for Part 1.

In the second part I will be showing how to use Tintri’s VM Protection through Replication with the Tintri Automation Tookit.

Enjoy !

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.