After Part 1 – The Basics in this series, I will show in Part 2 how you can set up Tintri’s VM Protection through Replication. And to conclude this post I will show some Reporting that you can do with the Tintri Automation Toolkit.
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.
These 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!
About a week ago I was so fortunate to being able to visit the Team behind PowerCLI.
I did already meet some of the PowerCLI Dev Team members on previous occasions, but this time I was able to see the complete team on their own turf.
Sometimes you immediately feel the chemistry that is present in a Team. And you know, even before you see what they produce, that great products will come out. This Team was for me a typical example of that.
Add on top of that, a dedicated and enthusiastic Product Manager, and voila, magic is in the air.
PowerCLI might be a free product, but you wouldn’t be able to tell that from seeing how this Team, located in Sofia Bulgaria, is dedicated to bringing a new build to you on a tight schedule.
And although PowerCLI might look like a simple products from the surface, you would be amazed at seeing the brainstorming, prototyping and reviewing that hides behind each new PowerCLI build this Team rolls out.
And they did it again with the PowerCLI 5.5 R2 build.
During my recent presentation at the 20th VMUGBE+ session, I showed different ways to run View PowerCLI cmdlets and scripts.
Several of the methods I showed, are already discussed on other blogs (to which I will include the links of course), but there is a new PowerShell feature that hasn’t been used until now (afaik).
And since I never found a complete overview of all the available methods, I decided to create this post.
In fact I was amazed there obviously is no cmdlet nor scripts available to perform this rather basic task. Luckily I had some code snippets laying around that did the job. Basically, I followed KB1010821 to do the ESXi 5.x host rename. But I decided it would be better to provide a real function to do the job.
One of the questions, related to working with vSphere events and tasks, that often appear in the PowerCLI Community, is how do we know which events to select for a query.
To make that task a bit easier, I wrote the Event-O-Matic script. It’s a GUI that allows you to pick a number of events, and the script will generate the PowerShell code, and place it in the clipboard. The Event-O-Matic script was mentioned during our VMworld 2013 US session VSVC4944.
Update September 7th 2013:
- added at least PowerShell v3 test
- added PowerCLI core pssnapin loaded test
One of the new features that came with PowerShell v3 was the introduction of “robust” or “persistent” sessions. This is, imho, a huge improvement on the concept of remote sessions who were introduced in PowerShell v2.
In short, before robust sessions, you had to keep the the client, that created the session, open to keep the remote session alive. With robust sessions, the client side can be closed, and you can reconnect to the robust session, even from another client.
This new remote session concept is something that can be used to solve a number of known PowerCLI “issues”.
Siw stands for Server in Waiting. We selected that term since we liked the sound of it, no double entendre should be suspected
During last year’s VMworld #NotSupported sessions one of the hot topics was William Lam‘s vInception talk. “Nested ESXi” has since then become indispensable in the homelab of everyone tinkering with virtualisation !
But as much as I like his clear instructions on how to set up nested ESXi, I wanted to automate the process In my homelab I create, and remove, ESXi VMs on a regular basis. So with the “If you do it more than once, automate it” in mind, I decided to create a function for the process.
In my homelab I try to automate as much as possible. I have a number of scripts and functions that help me setting up test environments in my homelab. Since I got quite a number of requests on this, I decided to start a series on my homelab tools.
One of the tasks I automated is the provisioning of VMs. Quite easy when you have a vCenter that manages the cloning process. But in layer 1 of my homelab I’m running ESXi standalone on a PaaS provided server, so no vCenter.
With the Copy-DatastoreItem cmdlet it is easy to clone the files of a VM, but this kind of copy doesn’t know about the different types of VirtualDisk you can have in a VM. As a result, your Thin vdisks become Thick vDisks in the clone. The function in this post avoids that problem by using the VirtualDiskManager for copying the VMDK.
Note that there are a couple of prerequisites: the master VM needs to be powered off and have no snapshots. And till now I only tested this with VMs that run a Windows guest OS.
Quite frequently there are questions in the VMTN PowerCLI Community for scripts that report on the tasks that ran in a vSphere environment.
But why not use the TaskHistoryCollector and it’s methods ? It provides many filtering options, and since this filtering is done in vSphere itself, this way of working is inherently much faster than using a filter in your script.
In analogy with the Get-VIEventPlus function, I published in my Get the vMotion/svMotion history post, here is the Get-TaskPlus function !