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
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:
- Take a RDM and make it a VVol
- Take a VVol and present it to an older VMware environment as a RDM
- Take a VVol and present it, or a copy of it, to a physical server.
- 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
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?
Yes. Any questions?
Ahem, I suppose I will prove it out. The real answer is, well maybe. Depends on the array.
So debates have raged on for quite some time around performance of virtual disk types and while the difference has diminished drastically over the years, eagerzeroedthick has always out-performed thin. And therefore many users opted to not use thin virtual disks because of it.
So first off, why the difference?
Continue reading Do thin VVols perform better than thin VMDKs?
I have been talking a lot about Virtual Volumes (VVols) lately with customers and when I describe what they are a frequent response is “oh so basically RDMs then?”. ..
…ugh sorry I just threw up in my mouth a bit…
The answer to that is an unequivocal “no” of course, but the question deserves a thorough response.
So first let’s look at how they are the same, then let’s look at their differences. And not just how they compare to RDMs, but also VMDKs as you traditionally know them.
Continue reading Comparing VVols to VMDKs and RDMs
Virtual Volumes provide a great many benefits, some large, some small. Depending on the VM, recovering a deleted VM could be either of those.
With traditional VMFS, once you have selected “delete from disk” restoring that VM could have been a process. Either restoring from backup or hoping you had a snapshot of the VMFS on the array. Either way, you are probably going to incur data loss, as the last backup or snapshot is unlikely to be from the time right before the deletion.
Let me be VERY clear here. Regardless to the rest of this post, I am not saying once you move to VVols you do not need backup! You absolutely still do. VVols just give you a nice way to do an immediate recovery of the latest point-in-time without having to lose anything, assuming your array support it.
“Wait, did you say delete VM “AD” or VM “80”?”
“Um… definitely not AD that’s our active directory…”
Continue reading Recovering a Deleted Virtual Machine with VVols
As you might have noticed vSphere 6.5 Update 1 just came out (7/27/2017) and there are quite a few enhancements and fixes. I will be blogging about these in subsequent posts, but there is one that I wanted to specifically and immediately call out now.
Round Robin and IO Operations Limit of 1 is now default in ESXi for the Pure Storage FlashArray! This means that you no longer need to create a custom SATP rule when provisioning a new host or adding your first FlashArray into an existing environment. Continue reading NMP Multipathing rules for the FlashArray are now default
Just recently, Rubrik announced their integration with the FlashArray to help backup virtual machines and avoid the common performance penalty incurred during VMware snapshot consolidation. See their announcement here.
Continue reading Rubrik and FlashArray Integration: Why it matters.
I posted a few months back about ESXi queue depth limits and how it affects performance. Just recently, Pure Storage announced our upcoming support for vSphere Virtual Volumes. So, this begs the question, what changes with VVols when it comes to queuing? In a certain view, a lot. But conceptually, actually very little. Let’s dig into this a bit more.
Continue reading Queue Depth Limits and VVol Protocol Endpoints
This is a blog post I have been waiting to write for quite some time. I cannot even remember exactly how long ago I saw Satyam Vaghani present on this as a concept at VMworld. Back when the concept of what is now called a protocol endpoint (more on that later) was called an I/O Demultiplexer. A mouthful for sure. Finally it’s time! With pleasure, I’d like to introduce VVols on the FlashArray!
Continue reading Introducing vSphere Virtual Volumes on the FlashArray