Also in that release are a few more cmdlets concerning storage policy creation, editing, and assignment. They were built to make the process easier–the original cmdlets and their use is certainly an option–and for very specific things you might want to do they might be necessary, but the vast majority of common operations can be more easily achieved with these.
As always, to install run:
Or to upgrade:
These modules are open source, so if you just want to use my code or open an RFE or issue go here:
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.
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:
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.
This post will be about managing one-off snapshots with VVols on the FlashArray with PowerCLI.
One of the still semi-valid reasons I have seen DBAs say “I dont want to virtualize because…” Is that they have simple snapshot/recovery scripts for their physical server that allows them to quickly restore DBs from snapshots. Doing this on VMFS requires A LOT of coordination with the VMware layer.
So they tell the VMware team–“okay I will virtualize but I want RDMs”. Well the VMware team says “well we’d rather die”
…and around in circles we go…
VVols provides the ability to provide this benefit (easy snapshot stuff) but still get the benefits of VMware stuff (vMotion, Storage vMotion, cloning, etc) without the downside of RDMs.