I’ve been making a lot of updates to my PowerShell module around VVols recently and this was the last “table stakes” cmdlet I wanted to add. There are certainly more to come, but now we definitely have the basics. In 126.96.36.199 release of the PowerShell module I added a cmdlet called Mount-PfaVvolDatastore.
As of today we support a single VVol datastore–though we are working on adding support for more than one.
One of the issues is that if you followed my default instructions, you would need to run the PowerShell window as an admin to be able to create the connection. The answer–now that I think about it is fairly obvious: non-admin users (or admins not running in admin mode) don’t have security rights to it. Duh!
About 6 months ago, my esteemed colleague Barkz blogged about our path forward with PowerShell. We have an official PowerShell SDK for managing the FlashArray–but it is limited to that: doing stuff to the FlashArray.
So to add value and make managing it within context of the layers you actually manage your infrastructure from (VMware, Microsoft, etc.) we created some value-add PowerShell modules to make it easier. Barkz talks about them here:
In my last post, I spoke about the ins and outs of using the Pure1 REST API–but it was a fairly manual process. Which of course is not how you really want to use a REST API. So the first part of this series will be using it with one of my favorite tools: PowerShell!
I will separate this into five parts:
Creating your certificate
Adding your public key into Pure1
Creating your JWT
Authenticating with Pure1
Making REST calls after authentication
UPDATE!!!! I made this much easier, you can use my module to connect to Pure1 which is on the PowerShell gallery.
The FlashArray implementation of Virtual Volumes surfaces VMs on the FlashArray as standard volume groups. The volume group being named by the virtual machine name. Each VVol is then added and removed to the volume group as they are provisioned or deleted. These objects though are fairly flexible–we do not use the volume group as a unique identifier of the virtual machine–internally we use key/value tags for that.
The benefit of that design is that you can delete the volume groups, rename them, or add and remove other volumes to it. Giving you some flexibility to group related VMs or whatever your use case might be to move things around, without breaking our VVol implementation.
This post I will talk about using PowerCLI to run a test failover for VVol-based virtual machines. One of the many nice things about VVols is that in the VASA 3.0 API this process is largely automated for you. The SRM-like workflow of a test failover is included–so the amount of storage-related PowerShell you have to manually write is fairly minimal.
I see a fair amount of requests around how to do different things with VMware PowerCLI and the Pure Storage PowerShell SDK. How do I correlate a VMFS to a volume? How do I create a new VMFS? How do I expand? Etc.
To help our customers I have written a module that includes a lot of the common operations people might need to “connect” PowerCLI to our PowerShell SDK.
My last post in this series was about getting a VVol UUID and figuring out what volume on a FlashArray it is. But what about the step before that? If I have a guest OS file system how do I even figure out what VMDK it is?
There is a basic option, which can potentially be used, which is correlating the bus ID and the unit ID of the device in the guest and matching it to what VMware displays for the virtual disks.
But that always felt to me as somewhat inexact. What if you accidentally look at the wrong VM object and then do something to a volume you do not mean to? Or the opposite?
Not ideal. Luckily there is a more exact approach. I will focus this particular post on Windows. I will look at Linux in an upcoming one.