Happy New Year everyone. It’s been a bit since I’ve posted but we do have a new VSI release to talk about. This one comes late as we do normally release quarterly, but seeing as it wasn’t expected at all, I suppose a month late isn’t bad. So last time I wrote about VSI, I mentioned 7.2 was most likely the last release of what we call the Flex client before the new HTML 5 version that is in the works. Well apparently I’m no Nostradamus. VSI 7.3 is now GA and can be downloaded here. So why did we create another version for the vSphere Web Client? Well, HTML 5 development has not been easy and there have been unforeseen delays. We thought about just waiting, but as VSI supports so many platforms, and their releases are not gated by VSI, we really needed an interim release on the current version to support those newer software platform builds that came out.
As it so happens, during development the IT industry (and everyone else) encountered the Meltdown and Spectre Vulnerabilities which we needed to address. We did that in this release and in doing so have decided to remove all previous versions of VSI to prevent any issues. Therefore it is a great idea to upgrade to 7.3 sooner rather than later. You can read about Dell EMC’s response in general in this KB.
The bright side of releasing another version of 7 is that the developers were able to resolve some remaining issues with the Flex client, particularly around performance and what I would call the “hanging” issues with the Flex client. A common example of this is when you right-click on an object in the vSphere Web Client and have to wait for the VSI menu to appear. There are others but generally they are different flavors of the same ice cream. It drove me crazy in my lab and I am sure I am not alone. These changes will make the Flex client, in my opinion, more viable and get us the extra time to get the HTML 5 version right. And at this point I’m not even going to make a call on whether there will be another Flex client release. We’ll just see what happens.
So as you might expect given what I just said, 7.3 is really a maintenance release. There are a few new features for the XIO platform and we have dropped ViPR support, but mostly the developers fixed or improved existing functionality. I pulled them right from the RN for you.
You can see we do have a couple important VMAX views listed there which will now load faster than before. Do not expect instantaneous loading, rather it will be ‘x’ times faster than before. Note that the more arrays you have presented to the vCenter, in general the longer it takes to load these views.
One final item before I sign off and you can get on with VSI 7.3. This is in respect to provisioning on the VMAX so if you don’t do that, feel free to skip this section because it really gets into the weeds.
When provisioning a datastore on the VMAX with VSI, you have the option of doing so at the host level or the cluster level. The idea, obviously, is that if you want an entire cluster to see the same datastore you can do that in a single stroke, or if you want just a single host in a cluster to see the datastore you can do that to. The way the VSI wizard provisions datastores on the VMAX is by displaying storage groups that are already presented to the host(s), allowing the user to select one of those storage groups. Straightforward right? For the host level, yes, but at the cluster level we have a bit of a dilemma. When VSI gathers the storage group information at the cluster level, it still does so at the host level. In other words it will show you all the storage groups from every host in the cluster. This presents a challenge unless the user is well versed with the storage-side information on the VMAX (which usually is not the case), because a user may inadvertently select a storage group that is only for a single host in the cluster, leading to a potential provisioning error. Let me use an example to help demonstrate this. Here is the storage group selection screen from the provisioning wizard when creating a datastore in my 2 host cluster:
I’ve highlight two different items here. Let’s start with the red box where my storage groups are “All_ESXi_hosts_sg”. You might think the code made a mistake here, but really what is going on is that the one storage group “All_ESXi_hosts_sg” is presented to both my ESXi hosts in 2 different masking views. Therefore VSI shows both. Now since each masking view to each host is using the same storage group, I can pick either one for provisioning, the wizard will succeed, and I will see the datastore on both hosts. Good enough. Now let’s look at the blue box. As I only see that storage group once, you might conclude that it is in 1 masking view to 1 ESXi host. This may or may not be true, however. This is because that one storage group may be in a masking view with an initiator group that contains initiators from both ESXi hosts. If it is, I’m in good shape, but if it is not, here is what will happen. If I move forward by choosing that group, one of two things will occur. Initially, VSI will create the device and place it in that storage group. It is the second part where we can run into trouble. Once the device is in the storage group, VSI will randomly choose one of my ESXi hosts and rescan the HBAs. If I am lucky, it will have selected the ESXi host where that storage group is presented. In that case, VSI will find the device, create the datastore, and the wizard will succeed; however only one host is going to see that datastore. But if I am unlucky, VSI will select the other ESXi host, fail to find the device, and the provisioning wizard will fail (with an iSCSI error to boot clouding the issue). So how do you avoid the problem? Well in most cases, unless you are the storage admin, you will need to ask the person who normally provisions storage from the array which storage group is presented to all ESXi hosts in the cluster. We will fix this in the future (lots of ways to do so), but keep it in mind if provisioning is one of your VSI tasks.