This post is somewhat specific to Pure Storage–the cmdlets of course are universal, but behaviors may not correlate to your storage array. So if you are using VVols on a non-Pure array, certainly consult your vendor.
Furthermore, this is certainly specific to PowerCLI when it comes to the commands. With that being said, the fundamentals on how this works with Pure is common for all orchestration tools, so you should be able to use this information for other tools. Though of course the cmds/syntax will be different.
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.
One of the fundamental features of the operating environment running on the FlashArray™ is the fact that the same software can run on many different hardware implementation of the FlashArray. This is one of the reasons that we can offer hardware Non-Disruptive Upgrades or when we introduce new features (even things as expansive as VVols) we can support it on older hardware. We support VVols going back to the FA 420-an array that was introduced before I joined Pure Storage® 4.5 years ago.
Furthermore, we have been having increasing conversations around the public cloud. Not just running applications in it, but moving data to and from it. DRaaS (Disaster Recovery as a Service) is an increasingly talked about use case. VMware Cloud in AWS is getting more and more attention at VMworld, and in general. We, at Pure get it. Will everything go to public cloud? No. Certainly not. Will everything stay on-premises? Also, of course not. Some customers will. Some will not at all. Many (most?) will use both in some capacity. So enabling data mobility is important.
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.
This is my first (but certainly not last post) on the new path selection policy option in vSphere 6.7 Update 1. In reality, this option was introduced in the initial release of 6.7, but it was not officially supported until update 1.
So what is it? Well first off, see the official words from my colleague Jason Massae at VMware here:
Why was this PSP option introduced? Well the most common path selection policy is the NMP Round Robin. This is VMware’s built-in path selection policy for arrays that offer multiple paths. Round Robin was a great way to leverage the full performance of your array by actively using all of the paths simultaneously. Well…almost simultaneously.
A few months back I was reviewing our VMware training for our field (and after some direct feedback) realized it wasn’t really doing what our field needed. It was too nuts and bolts technical–which isn’t really what was needed by the masses. There was more of a desire to understand the value of the VMware product, the value of the integration and the value that we as Pure can bring to it.
The ones that wanted/needed more technical training could get that as needed.
In short, what they wanted to be able to do was have the “I’m staffing a booth at a conference and someone asks me about vRealize Orchestrator”. Not being an expert in the product, how to do I quickly understand the value, so I know if I am chasing the right product/solution and I should inquire further.
I am working on my PowerShell module for Pure/VMware operations and one of the cmdlets I am writing is for growing a VMFS. When perusing the internet, I could not find a lot of direct information on how to actually do this. There is not a default cmdlet for doing this.
The illustrious Luc Dekens talks about this problem here and even provides a great module for doing this:
If you just need want to run a quick script you can use that. If you want to write it yourself here is a quick overview of what you need to do. I am talking about a specific use case of:
I have a datastore on one extent and that extent exists on a LUN (or device or volume or whatever you want to call it) on an array. That LUN has been grown on the array.
I want to grow the VMFS to use the new capacity and not create a new extent, just grow it.