Today, vRO 7.6 was released, and one feature I was most looking forward to was a fully usable web client for creating/editing workflows! Time to finally ditch the java client!Continue reading vRealize Orchestrator 7.6 is released! Updated Web Client
I have released a new version of the VMware/Pure PowerShell module which can be automatically installed from the PowerShell Gallery.
Updates in this release are focused on VVols. Creating VVol snapshots, copying them, creating new disks from them, retrieving them etc.
I wrote a blog post below on using some of the new cmdlets:
Another post in my series on VVols and PowerCLI, for previous posts see these:
- PowerCLI and VVols Part I: Assigning a SPBM Policy
- PowerCLI and VVols Part II: Finding VVol UUIDs
- PowerCLI and VVols Part III: Getting VVol UUIDs from the FlashArray
- PowerCLI and VVols Part IV: Correlating a Windows NTFS to a VMDK
- PowerCLI and VVols Part V: Array Snapshots and VVols
- PowerCLI and VVols Part VI: Running a Test Failover
- PowerCLI and VVols Part VII: Synchronizing a Replication Group
- PowerCLI and VVols Part VIII: Running a Planned Migration
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.
So let’s walk though that process.
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.
There are so many options out there, the “why” sometimes can be the most important question. Continue reading VMware & Pure Integration Training Videos
One of the first technical benefits users can enjoy around VVols is the use of snapshotting. Snapshots created through VMware of VMs have always been a point of contention which as severely limited their usability (see a post I did around the performance impact of them here).
With VVols, when you right-click on a VM and choose take snapshot, VMware does not create the performance-impacting delta VMDK files that were traditionally used, but instead VMware entirely offloads this process to the array. So the array creates the snapshots and VMware just tracks them.
But since VMs are now a collection of individual volumes on the array (a VVol is just an array volume) you can also snapshot and restore individual virtual disks as well directly on the array.
So what does all of this mean?
In my last post, I walked through configuring ActiveCluster and your VMware environment to prepare for use in Site Recovery Manager.
In this post, I will walk through configuring Site Recovery Manager itself. There are a few pre-requisites at this point:
- Everything that was done in part 1.
- Site Recovery Manager installed and paired
- Inventory mappings in SRM are complete (network, folders, clusters, resource pools etc).
- Downloaded and installed the FlashArray SRA 3.x or later on both SRM servers.
vSphere 6.7 core storage “what’s new” series:
- What’s New in Core Storage in vSphere 6.7 Part I: In-Guest UNMAP and Snapshots
- What’s New in Core Storage in vSphere 6.7 Part II: Sector Size and VMFS-6
- What’s New in Core Storage in vSphere 6.7 Part III: Increased Storage Limits
- What’s New in Core Storage in vSphere 6.7 Part IV: NVMe Controller In-Guest UNMAP Support
- What’s New in Core Storage in vSphere 6.7 Part V: Rate Control for Automatic VMFS UNMAP
- What’s New in Core Storage in vSphere 6.7 Part VI: Flat LUN ID Addressing Support
Another feature added in vSphere 6.7 is support for a guest being able to issue UNMAP to a virtual disk when presented through the NVMe controller.
I wrote a blog post a year or so ago about ESXi and storage queues which has received a lot of wonderful feedback (thank you!!) and I eventually turned it into a VMworld session and other engagements:
So in the past year I have had quite a few discussions around this. And one part has always bothered me a bit.
In ESXI, there are a variety of latency metrics:
- GAVG. Guest average. Sometimes called “VM observed latency”. This is the amount of time it takes for an I/O to be completed, after it leaves the VM. So through ESXi, through the SAN (or iSCSI network) and committed to the array and acknowledged back.
- KAVG. Kernel average. This is how long an I/O is spending in the ESXi kernel. If this is anything but zero, there is some kind of bottleneck (often a maxed out queue)
- DAVG. This is how long it takes for the I/O to be sent from host, through the SAN and to the array and acknowledged back.
We have published the FlashArray plugin 2.0 for vRealize Orchestrator on the VMware Solutions Exchange! Download it here:
We put a lot of work into this one and I am quite excited for customers and partners to start using it.
There are three primary enhancements:
- New workflows
- New actions
- New scriptable objects
Storage capacity reporting seems like a pretty straight forward topic. How much storage am I using? But when you introduce the concept of multiple levels of thin provisioning AND data reduction into it, all usage is not equal (does it compress well? does it dedupe well? is it zeroes?).
This multi-part series will break it down in the following sections:
- VMFS and thin virtual disks
- VMFS and thick virtual disks
- Thoughts on VMFS Capacity Reporting
- VVols and capacity reporting
- VVols and UNMAP
Let’s talk about the ins and outs of these in detail, then of course finish it up with why VVols makes this so much better.
NOTE: Examples in this are given from a FlashArray perspective. So mileage may vary depending on the type of array you have. The VMFS and above layer though are the same for all. This is the benefit of VMFS–it abstracts the physical layer. This is also the downside, as I will describe in these posts. Continue reading VMware Capacity Reporting Part IV: VVol Capacity Reporting