VSI 8.3

VSI 8.3 came out today and offers a number of features for the PowerMax/VMAX platform. This release essentially brings us to parity with the 7.x client for our array, and in fact a little beyond. The binary and documentation are available on the support site here. The product guide contains information on upgrading from earlier releases which is made all the more easy with DockerHub. If required (e.g. isolated environments) you can upgrade via a package. There is a new OVA, of course, if you are installing from scratch.

The new features for PowerMax/VMAX from the Release Notes are:

In addition, there are some cosmetic changes included which I requested to help clarify screens. I’ll start with those then go into the more substantial features.

Cosmetic

Parent storage groups

When you are presented with the Storage Groups selection screen we’ve add a Parent Storage Group column so the array owner can see if the group is a child storage group. The parent group itself will not be included in the available selections because a parent may not contain devices if children storage groups exist.

Apply Host Best Practices

This change was done mostly for performance, but I admit to being overprotective of my platform. In the last release, when you selected Apply Host Best Practices, the screen would come up with the Array Type of XtremIO already selected. You would then have to wait for VSI to check if you actually had an XIO box, and then if you didn’t you could not change anything and had to use the drop-down box to select the PowerMax/VMAX or Unity option. This seemed to me, well, lazy to default like that. So instead the screen will come up and let you to select an Array Type. This way you get exactly what you want the first time and not waste any time.

While I’m in this screen I wanted to re-iterate that these are our general best practices. In the vast majority of environments, these recommendations hold true. There is one situation that comes to mind that may call for a different path – if you are using SRDF/Metro in a vMSC environment with a uniform configuration where the arrays are not co-located. In such configurations the best practice is not iops=1 for Round Robin, rather it is the default of 1000. Now hopefully if you are running that configuration you already consulted my best practices paper under the Documentation Library which will inform you of all of this so my caveat is unwarranted, but never hurts to repeat.

Datastore wizard

We’ve added the ability here to change the Space Reclamation Priority from the default of “low” to “high”.

The reason for this was VSI supports more than just PowerMax, and it is possible one or more of the other arrays recommend changing the default value. For PowerMax we DO NOT. Leave it set to low as VMware intended (you’ll notice we don’t offer “none” for this reason). I have a VAAI whitepaper you can read on why that is the recommendation from us (and VMware) if you want more detail. In addition to having this setting, you’ll also notice below in the video on the new VSI views that there is an autounmap column which will show you both priority and fixed based values. A reminder that we only support VMFS 6 with this wizard.

OK now the bigger new features.

Edit Storage System Registration

In previous releases of VSI, you could not edit the registration of an array. Now you can. You can adjust the connection details or even change the owner of the array.

As minor a change as it may seem, it definitely was needed. Just taking one use case, let’s say your business requires that the password for Unisphere is changed every 90 days. Well, until now you’d have to remove the array and re-add it, losing all your SGs and user/limits. That’s a real pain that you can now avoid.

Datastore and RDM deletion

Going all the way back to our VSI thick client, we have never had the ability to remove a datastore AND the underlying device on the array. There are many reasons for this, mostly centered on the complexity of device deletion on the array. Now that deleting a device is very easy on the PowerMax (because deallocation is bundled with it), VSI has been able to incorporate this feature.

So a couple things to know about the feature.

  • VSI will let you delete any datastore that is backed by a device on a registered storage array provided the storage group is registered. It does not have to be a datastore that was provisioned with VSI, however. Here is the error you will get if the storage group is not registered.

  • VSI will not check if the datastore is in use before you request its deletion; however VMware will not allow it and thus the VSI operation will fail with a generic 500 error. If you look in the tasks, however, VMware will report the real error that the datastore is in use.

    • It will also not let you delete a datastore that is not backed by a registered array device.

  • In order to delete an RDM, you must use the Configure tab of the VM and then the Dell EMC VSI menu. There is no right-click menu off the VM itself as there is when deleting a datastore.
  • Datastore and RDM deletion are lengthy processes during which you cannot interact with the vSphere Client, though you will see the tasks being updated in the background. Please be patient. (I have sped this up in the demo, don’t be fooled :-)) Here is what it will look like during creation:

OK so let me run through a quick demo. At a high-level I will:

  • Delete a datastore created with VSI
  • Delete a datastore not created with VSI, demonstrating the storage group must be registered
  • Delete an RDM

View datastores and devices

This feature is one that previously existed for VMAX in version 7.0 of VSI,  namely the ability to view all datastores and devices at the cluster or host level. In version 7.0 this was only available for VMAX, but this feature now also supports Unity and XtremIO.

There are 2 views, VMware Datastores on Dell EMC and Dell EMC Array Devices. The datastore view has 2 panels, the top will have the standard VMware values such as total capacity and free, but also autounmap which will show either the priority (e.g. low) or the fixed value (e.g. 700 MB/s). If you select the radio button next to the datastore, a bottom panel appears which displays the array values such as volume id, wwn, and the capacity values. If you are not using autounmap, the capacity values at the array level can be compared to the top panel, showing if there is stranded storage, and thus a good candidate for manual unmap. The device level view will show you all devices presented to the environment and how or if it is being used (e.g. RDM, VMFS). Note that as this is a read-only feature, it does not matter if you selected any storage groups during registration.

Here is a demo which just navigates through the views at the cluster and host level.

Caveat

Create datastore – vVol option

This is more of a warning or to prevent you from being confused. When you use VSI to create a new datastore you will see the following screen:

Those vVol options (VMware’s new vVol spelling is not updated yet) are for Unity, not PowerMax. Don’t worry you can’t break anything if you select them, but you’ll get to a storage selection screen and wonder why your array is not there. So now you know. PowerMax does not require VSI to create vVol datastores – just use the standard datastore wizard in vCenter.

Advertisement

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Website Powered by WordPress.com.

Up ↑

%d bloggers like this: