Hear ye, hear ye! The VM Analytics Collector now comes in a new flavor! And OVA! Yay! I understand this is more of a “about time, why didn’t you have this in the first place?” kind of a thing, and fair enough, but here we are.
Now the current OVA is somewhat a shadow of what we expect it to be, a lot of the work that went into this was to build the ground work to use this for many other things. So certainly expect this to be developed and offered in more advanced and flexible ways. But for now, it is an OVA that is locked down that contains one thing: the collector.
No, not that collector. The vCenter collector for our VM Analytics tool.
A few months back I published a new PowerShell cmdlet for installing the Pure Storage vSphere Client Plugin. Get-PfavSpherePlugin and Install-PfavSpherePlugin. This works quite well and we’ve had a fair amount of use of it so far, but another place we are certainly investing in right now is vRealize Orchestrator and continuing to enhance our plugin. Filling in any gaps around workflows and actions, especially on initializing an environment is important.
One of those gaps was installing the vSphere Plugin. One common use case we have seen around vRO is day 0 config, but day 2 stuff is done in vCenter (deploying VMs, datastores, etc). So the vSphere Plugin comes in handy here. So how do I install it from vRO?
Anyways. In general I am not a fan of using in-guest iSCSI for VMware environments (or really any virtualized environment), but the question does come up. And I find a surprising amount of customers using it in secret. So what of it? Why do I hate it? Why should one use it? Are there reasons to?
So let me preface this post with, is in-guest iSCSI inherently evil? No, of course not. Are there situations where it makes sense? Yes, and I go into that. The post is focused on this use case: I need to provision storage from the FlashArray to my VMware VMs. What is the best method? I expect this to be a living document. So please let me know if there are more downsides or upsides and I will add them in.
In the past 10 months I have been pretty focused on learning AWS. Not just how to use it, but more importantly, how others are using it. It has been a fun ride–definitely already incorporated some of my learnings into my solution work for on-premises integration and have some cool stuff coming. A lot of my work has been of course on using it, how to deploy EC2, how to deploy VMware Cloud on AWS, managing S3, CloudFormations, IAM, SSM, using the billions of other services in AWS. But much of my focus has been on listening to what people have seen, learned, and want to do with public cloud. AWS and the like have had a decent amount of runway now, so there have certainly been some lessons learned.
No that’s not a typo–VVols are now capitalized as vVols. So, FYI.
Anywho…as you may or may not be aware, we just released our 5.3.0 version of the FlashArray Purity Operating Environment, with quite a few things in it. One of the features is part of a larger solution that I think is a really good example of the power of VMware vSphere Virtual Volumes (vVols). One of the main arguments I have been making for VVols is that they allow you to use features on your array as they were intended (snapshots is a great example there) but also allows us (the storage vendor) to do things that simply weren’t possible, or were rather difficult to do with VMFS without compromise.
This particular feature I am referring to is what we are calling EncryptReduce. Previously called (in its beta form) End-to-End Encryption, this is a solution we partnered with Thales with its Vormetric Transparent Encryption product. We initially announced it here.
This doesn’t come up very often these days, but every once and awhile it does and every time it does, I look to see if we have documentation on it and there never seems to be. After writing this post I did find a forum post where my friend Drew answers it there too. Well anyways let’s quickly explain the situation.
Most block vendors these days tell customers to change their path switching policy for their storage in ESXi from the default of Round Robin (1,000) to 1. This makes ESXi switches logical paths for a given device after every I/O instead of every 1,000. The reason I say this doesn’t come up much anymore is that in modern version of ESXi (6.0 express patch+, 6.5 U1+ and 6.7+) we (Pure) have rules in ESXi that makes sure this is set by default without any user configuration. Many other vendors do as well.
Anyways, when using VMware tools to see if a device is configured properly, depending on how it is set, it can readout differently.
Not long ago I posted about our initial release of our vSphere Plugin that supports the HTML-5 UI–the main problem though is that it did not yet support the VVol stuff we put in the original flash/flex based plugin.
So accordingly, the most common question I received was “when are you adding VVol support to this one?”. And my response was “Soon! We are working on it”.
Phew that title is a mouthful. Sorry about that. But at least you know what I’m gonna talk about here. Nothing particularly profound, but obviously something every customer must do. I’ve been on a solid PowerShell kick as of late so why not put pen to paper here.
So whether you are using VVols or VMFS (or gross: RDMs) you need to do a bit of prep work to get things up and running. I will likely write a post on doing this with the vSphere Client Plugin, but for now let’s focus on doing it with PowerShell.
So step one is to install the PowerShell module that will help you. This is hosted on the PowerShell Gallery, so it is fairly simple to install:
If you already have it installed, don’t forget to pull the latest version: