VSI 6.5 is now generally available for download on support.EMC.com:
Here are the new features:
- Support for VMware vSphere 6.0 – note this is the ONLY VSI release supporting it
- Support for setting multi-pathing policies from the VSI GUI using native multi-pathing and PowerPath®/VE (vSphere 6)
- Support for selectively disabling snapshots during datastore protection in AppSync
- Support for the following functions on EMC VNXe3200 storage:
- Extend datastores on a thick or thin LUNs and NFS file systems
- Enable and disable de-duplication and compression on VNXe3200 datastores and virtual machines
- Support for client registration on EMC VMAX3 storage
- Support for the VPLEX platform (enabling VSI 5.x features in the web client)
I’m just going to cover a few of the highlights. I’ll start with the VMAX3 addition, as it is fairly minor and is not something VMware Admins are generally going to use, though it has its purpose. What VSI will do is that for each SMI-S Provider used, SIS will register VSI with that SMI-S. If you are interested when this happens, check the SIS log and look for a block of lines that appear as the following:
2015-04-13 13:05:21,118 [nio-8443-exec-5] INFO .e.s.v.u.s.SmisProviderService – Administrator@VSPHERE.LOCAL: registerClientToSmisProvider – Begin
2015-04-13 13:05:21,422 [nio-8443-exec-5] INFO .e.s.v.u.s.SmisProviderService – Administrator@VSPHERE.LOCAL: registerClientToSmisProvider – End
Where this information might be utilized is by the system administrator. The SA can run a Solutions Enabler query which will show that VSI is registered. I suppose you could imagine an SA desiring to know who is accessing a particular SMI-S Provider. That is where I see it being used.
The other feature I thought I’d mention is the one for PowerPath/VE, which in fact is more than just PP/VE. In the VSI 5.x thick client we had a path management feature which permitted you to set the policy that your ESXi host(s) would use whether employing NMP or PP/VE. That feature is now in the web client. To access the feature, use the same right-click menu as for all EMC VSI actions:
This activates a wizard which is straightforward, and easy to walk through. In the first screen you select the hosts:
Then select the storage array (or all) and the desired policy whether for NMP or PP/VE. I have selected the defaults for VMAX/VMAX3:
After this screen you would then be prompted to execute the changes. I will note that for VMAX/VMAX3 storage, it is almost always unnecessary to make pathing changes. By default, PP/VE will use the correct policy for VMAX/VMAX3 when installed and starting with Enginuity (VMAX) 5876.85.59 (and any HYPERMAX OS) and vSphere 5.1, RoundRobin is the default policy for NMP. Therefore it is only when EMC Support requests a change that it may be necessary to use this feature.
I’m afraid I do not have a VPLEX right now so I can’t demonstrate that functionality but I suspect you can find other blogs from EMCers who will show that.
There were a few hiccups with the VSI 6.5 release I ran into, hence the delay in this posting. In many ways though I am an EMC employee, I am also a customer. I am a voracious user of our software and admittedly treat it like a punching bag most of the time. This of course should be a comfort to you as our customer as I am bound to find most issues before a product ever makes it to the ship date, relieving you of the necessity of filing SRs 🙂 Many of the “undocumented features” I find, most customers would never run into as my lab is not anything you would want running your mission critical information; however I document them just the same since you never know. And in that vein let me tell you about one of those.
I have a typical setup – deployed VSI 6.5, registered my vSphere 6 vCenter, registered SIS in vSphere and then added a couple VMAX3 arrays with the SMI-S 8.0.2 Provider. I decided at that point to do some other testing so I logged into my SIS as the owner of those arrays (e.g. firstname.lastname@example.org). So far so good right? Here is the page I see as this user:
Now I wanted to modify access to my VMAX3 arrays which I do through the Storage Access page. I therefore selected Storage Access under Navigation and here is what I received:
Well if the owner of the array is not authorized we’ve got a big problem. Fortunately the fix to this is easy though it looked like a real problem to me. A quick response from the developers revealed that my browser cache probably had some old information and I should delete it and retry (or use another browser). Voila, no more issue. I probably should have known better as browser cache has been my nemesis before. Lesson learned. Again. Now my response to the developers is can’t we deal with this programmatically? And maybe we can – they are looking into it. In any case if you hit what I would term “weirdness” with VSI, give a new browser a try or clean the cache.
I will also note another issue I hit on displaying VMAX3 information. As I said my lab is quite a bit different than a customer lab. I have configurations on my VMAX3 which would not necessarily be used in the real world – e.g. using NONE SLO for a masked storage group. One of these setups caused VSI to fail to display my device information. Development was able to resolve this for me, but as it was so peculiar it was not included in the release. I only offer it as a good-to-know if by chance you experiment in your environment.
I’ll end this post with a request. If you have features in mind for VSI which we have not implemented, it would be great to know, particularly for VMAX as you can imagine. Frankly it is much easier to push for feature development when customers are the ones doing the pushing (or requesting at least).
Thanks for the help.