VMware Capacity Reporting Part IV: VVol Capacity Reporting

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.

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”

ActiveCluster and vMSC Implementation Guide

Quick post. I have published my ActiveCluster implementation guide for vSphere Metro Storage Cluster (vMSC). You can find it here:

https://support.purestorage.com/Solutions/VMware_Platform_Guide/User_Guides_for_VMware_Solutions/ActiveCluster_with_VMware_User_Guide

ActiveCluster, if you are unfamiliar, is the Pure Storage FlashArray implementation of fully Active/Active replication. Meaning a volume can exist and take write simultaneously from two arrays. No additional hardware or licenses required. Comes with Purity 5.0.0. A main focus, like everything else Pure, is simplicity–that goal has definitely been achieved in my view.

Continue reading “ActiveCluster and vMSC Implementation Guide”

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”

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”

FlashArray 3.0 Plugin for the vSphere Web Client

This is the start of many blog posts around the recent Purity 5.0 release. I figured I would start with one that doesn’t require an upgrade of Purity to even get!

Alongside Purity 5.0, we released the 3.0 version of theFlashArray plugin for the vSphere Web Client. This is bundled in Purity 5.0, so if you upgrade any one of your FlashArrays you can then use it to upgrade the plugin in one or all of your vCenters.

Let me be clear though–if you want to use VVols or ActiveCluster you need Purity 5.0. Without Purity 5.0, you can use the 3.0 plugin of course, but you can only use non-VVol or non-ActiveCluster features.

Continue reading “FlashArray 3.0 Plugin for the vSphere Web Client”

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”

What is a Config VVol Anyways?

I have blogged a decent amount recently about VVols and in many of those posts I mention config VVols. When using vSphere Virtual Volumes, VMs have one, some, or all of the following VVols types:

  • Data VVols–every virtual disk you add creates a data VVol on your array
  • Swap VVol–when you power on a VVol-based VM, a swap VVol is created. When you power it off, this is deleted.
  • Memory VVol–When you create a snapshot and store the memory state or when you suspend a VM, this is created.
  • Config VVol–represents a folder on a VVol datastore.

This statement about config VVols deserves a bit more attention I think. What does that really mean? Understanding config VVols is important  when it comes to recovery etc. So let’s dig into this.

Continue reading “What is a Config VVol Anyways?”