Category Archives: VMware

VMware Storage Capacity Reporting Part I: VMFS and Thin Virtual Disks

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:

  1. VMFS and thin virtual disks
  2. VMFS and thick virtual disks
  3. Thoughts on VMFS Capacity Reporting
  4. VVols and capacity reporting
  5. 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.

Continue reading VMware Storage Capacity Reporting Part I: VMFS and Thin Virtual Disks

vSpeaking Podcast Appearance: VVols

A few week ago I had the chance to stop by VMware HQ and catch up with some good friends at VMware. The highlight of the visit was doing an episode of the vSpeaking Podcast alongside VMware VVol engineering manager Patrick Dirks hosted by Pete Flecha and John Nicholson.

Honored to be on the podcast for the third time, thanks again for having me on Pete and John!

Topic? VVols of course!

Continue reading vSpeaking Podcast Appearance: VVols

Volume matching via the API in Purity 5.0

Core to most scripting with the FlashArray is figuring out what volume is on what FlashArray. Then you proceed to do what you need with it (snapshot, report metrics, whatever).

Traditionally how this was done, at least from a VMware perspective was via the NAA (network address authority). You take this number, which is how ESXi uniquely addresses a volume and slice it up to find the array serial and the volume serial. By matching the section with a particular array serial, you have identified what array owns it. Then you can make the calls to that array.

Details on how this worked are beyond the scope of this post, but you can see this here:

VMFS Snapshots and the FlashArray Part IV: How to correlate a VMFS to a FlashArray volume Continue reading Volume matching via the API in Purity 5.0

ActiveCluster and VAAI

Pure Storage recently offered up support for active/active replication for the FlashArray in a feature called ActiveCluster. And a common question that comes up for active/active solutions alongside VMware is how is VAAI supported?

The reason it is asked is that it is often tricky if not impossible to support in an active/active scenario. Because the storage platform first has to perform the operation on one array, but also on the other. So XCOPY, which offloads VM copying, is often not supported. Let’s take a look at VAAI with ActiveCluster, specifically these four features:

  1. Hardware Assisted Locking (ATOMIC TEST & SET)
  2. Zero Offload (WRITE SAME)
  3. Space Reclamation (UNMAP)
  4. Copy Offload (XCOPY)

Continue reading ActiveCluster and VAAI

Assigning a VVol VM Storage Policy with vRO

Amidst writing a vMSC guide for our newly-introduced Active-Active replication called ActiveCluster, I have been taking some breaks to finish my vRealize Orchestrator Workflow Package for Virtual Volumes. I posted a starter post recently:

Getting Started with vRealize Orchestrator and VVols

I am almost done with v1, but until then another starter post. Continue reading Assigning a VVol VM Storage Policy with vRO

Announcing Pure Storage FlashArray VVol GA

This is a blog post I have been waiting to write for a long time. We at Pure Storage are pleased to announce that vSphere Virtual Volume support on the FlashArray is officially GA!

The FlashArray now supports running VVols in Purity 5.0.0 and later. The cool thing about the FlashArray is the flexibility of the Purity Operating Environment–so VVols are supported on all FA 400 models (405, 420, and 450), //M models (m10, m20, m50, m70) and FlashArray//X. Continue reading Announcing Pure Storage FlashArray VVol GA

Getting Started with vRealize Orchestrator and VVols

Over the past few weeks, I have been working on writing a vRealize Orchestrator workflow package for Virtual Volumes and the FlashArray. While that is not quite ready to go out, I think some basics for starting to use vRO and VVols are worth noting.

There are three main parts of using VVols with vRO:

  1. Core vCenter SDK–this is what you use to create VMs, datastores, etc.
  2. SMS–this is the service that manages storage providers (VASA) and replication for VVols.
  3. PBM–this is the service that you use for storage policy based features.

Continue reading Getting Started with vRealize Orchestrator and VVols

What is a VVol Datastore?

I have been traveling around lately talking about VVols and one of the most commonly misunderstood objects is the VVol datastore. What is it? What does capacity mean on it? Why does it even exist?

These are all good questions. The great thing about VVols is that very little changes in how the VMware user interacts with vSphere. But at the same time, what actual happens is VERY different. So let’s work through this.

Continue reading What is a VVol Datastore?

Upgrading ESXi environment with PowerCLI

A new ESXi 6.5 patch came out today:

https://kb.vmware.com/s/article/2151104

And I wanted to upgrade my whole lab environment to it and I haven’t set up auto-deploy or update manager yet (I plan to, making all of this much easier to manage). So I wrote a quick and dirty PowerCLI script that updates to the latest patch and if the host doesn’t have any VMs on it, puts it into maintenance mode and reboots it. I will reboot the other ones as needed.

So short, not really even worth throwing on GitHub, but I might make it cleaner, and smarter at some point and put it there. Continue reading Upgrading ESXi environment with PowerCLI

VVol Data Mobility: Data from Virtual to Physical

One of the most strategic benefits of Virtual Volumes is how it opens up your data mobility. Because there is no more VMDK encapsulation, VVols are just block volumes with whatever file system your guest OS in the VM puts on it. So a VVol is really just a volume hosting NTFS, or XFS or whatever. So if a target can read that file system, it can use that VVol. It does not have to be a VMware VM.

Let me start out with: YES our VVols deployment will be GA VERY soon. I am sorry (but not really) for continuing to tease VVols here.

This is one of the reasons we do not treat VVols on the FlashArray any differently than any other volume–because they aren’t different! So there is no reason you can’t move the data around. So why block it??

Some possibilities this function opens us:

  1. Take a RDM and make it a VVol
  2. Take a VVol and present it to an older VMware environment as a RDM
  3. Take a VVol and present it, or a copy of it, to a physical server.
  4. On the FlashArray we are also introducing something called CloudSnap, which will let you take snapshots of volumes (aka VVols) and send them to NFS, or S3 to be brought up as a EBS volume for an EC2 instance.

Continue reading VVol Data Mobility: Data from Virtual to Physical