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!
Another year, another VMworld! This year I have a few sessions that I have submitted that I would love to do this year, hopefully you agree and will vote for them. Plus some other sessions related to Pure Storage that you should take a look at.
So I am in the middle of updating my best practices guide for vSphere on FlashArray and one of the topics I am looking into providing better guidance around is ESXi queue management. This breaks down to a few things:
- Array volume queue depth limit
- Datastore queue depth limit
- Virtual Machine vSCSI Adapter queue depth limit
- Virtual Disk queue depth limit
I have had more than a few questions lately about handling this–either just general queries or performance escalations. And generally from what I have found it comes down to fundamental understanding of how ESXi queuing works. And how the FlashArray plays with it. So I put a blog post together of a use case and walking through solving a performance problem. Explaining concepts along the way.
- This is a simple example to explain how queuing works in ESXi
- Mileage will vary depending on your workload and configuration
- This workload is targeted specifically to make relationships easier to understand
- PLEASE do not make changes in your environment at least until you read my conclusion at the end. And frankly not without direct guidance from VMware support.
I am sorry, this is a long one. But hopefully informative!
Continue reading Understanding VMware ESXi Queuing and the FlashArray
This is a blog I have been waiting a long time to write. The past year and a half of my work has heavily focused on improving and building our VMware vRealize integration at Pure Storage. Log Insight and Operations Manager integration already existed (analytics etc.), so the next logical step is actually provisioning (orchestration). So vRealize Orchestrator and Automation. The first step I took was using the built-in REST plugin in vRO to build a workflow package that customers could use to actually manage the FlashArray without much work on their own part inside of vRO.
I started to realize that a workflow package was not enough. Especially when it comes to vRA Anything-As-A-Service integration. A big part of what is missing from a workflow package is custom objects and inventory management. Something that a plugin can easily achieve. So, without further ado–please meet the FlashArray vRO plugin! Downloadable at the VMware Solution Exchange and fully certified by VMware and Pure Storage:
Here is my storage manager for the FlashArray and VMware. Based on PowerCLI, but uses a front end GUI. Enjoy!
There are a variety of methods of managing VMware objects (VMFS volumes, VMs, VMDKs and RDMs) and the underlying snapshots to recovery or clone them. But often I get asked if I have a PowerShell (PowerCLI) script to do one or all of them. I have a bunch on my GitHub, but I decided a week or so ago to put something a bit more robust together. At first I was making it a standard interactive script, but it morphed into a GUI, using combo-boxes etc:
This is part 6 of this 8 part series. Questions around managing VMFS snapshots have been cropping up a lot lately and I realized I didn’t have a lot of specific Pure Storage and VMware resignaturing information out there. Especially around scripting all of this and the various options to do this. So I put a long series out here about how to do all of this.
The series being:
- Mounting an unresolved VMFS
- Why not force mount?
- Why might a VMFS resignature operation fail?
- How to correlate a VMFS and a FlashArray volume
- How to snapshot a VMFS on the FlashArray
- How to mount a VMFS FlashArray snapshot
- Restoring a single VM from a FlashArray snapshot
Using vCenter and our Web Client plugin, recovering a snapshot is a pretty straight forward process. So the pre-requisite here is having our Web Client plugin installed and configured. Info on that here. If you want to know the manual steps, scroll down further and the whole process is described in detail that does not use the plugin–just our GUI and vCenter. Continue reading VMFS Snapshots and the FlashArray Part VI: Mounting a FlashArray VMFS Snapshot
Another UNMAP post, are you shocked? A common question that came up was what volumes have dead space? What datastores should I run UNMAP on?
My usual response was, well it is hard to say. Dead space is introduced when you move a VM or you delete one. The array will not release the space until you either delete the physical volume, overwrite it, or issue UNMAP. Until vSphere 6.5, UNMAP for VMFS was not automatic. You had to run a CLI command to do it. So that leads back to the question, well I have 100 datastores, which ones should I run it on?
So to find out, you need to know two things:
- How much space the file system reports as currently being used.
- How much space the array is physically storing for the volume hosting that file system.
My second post in my vSphere 6.5 series, the first being:
One of the new features from a core storage perspective is a new version of VMFS. In vSphere 6.5, VMware has released VMFS 6, the first major update of VMFS in year (VMFS 5 in 2011). Not earth shattering changes, a lot of pain points have been removed and there has been A LOT of work put into VMFS 6 to improve concurrency of operations and speed up certain procedures. The first thing I want to mention is unresolved volume handling. Continue reading What’s new in ESXi 6.5 Storage Part II: Resignaturing
Finally starting to catch up on work after VMworld. A lot of blog posts queued up in my head that I want to start getting out. Here is the first. I have completed an update of the FlashArray workflow package with some bug fixes and some new workflows. As always the workflow package can be found here:
As I have blogged about before, TLS 1.0 and SSL v3 were deprecated in Purity 4.7, requiring all connections to use either TLS 1.1 or TLS 1.2. This affected a variety of integrations, some we updated, some you just had to alter their behavior. A few VMware products do not/did not use TLS 1.1/1.2 by default, so they either need to altered or upgraded. This almost invariably boiled down to the JDK version that was in use. vRealize Orchestrator is no exception.