VSI 8.6 is available for download today. This version does away with the previous process for registering the vCenter as part of the OVA deployment. Instead it provides a new interface which I’ll cover below. Along with registration updates, there are a number of new features for PowerMax. At a high-level these are the new features:
- View Storage Group Snapshot Policies
- Host Connectivity
- Multiple snapshot deletion support
- vCenter tasks for PowerMax workflows
I’ll cover the first three below. The fourth in that list just means we now display tasks in the vCenter for some things that VSI previously did not, so not much to show. Let’s start with the deployment and registration process. I’ll take you through what would be a new VSI install, but the interface is the same even if you’ve upgraded.
A few things to note about VSI 8.6 in general before you begin:
- The root password is still “root” which will need to be changed at the first SSH login.
- There is still the restriction that you can only register multiple vCenters if they are linked. If your vCenters are not linked, you need a VSI deployment for each.
- Since VSI 8.5, the external PSC for vCenter is not supported.
In previous releases, the vCenter name and credentials were provided at OVA deployment. Then when VSI booted, it would register the plugin automatically for you. This occasionally caused issues because if the plugin failed to register, your evidence was simply the VSI menu being unavailable in the vCenter. Recovering from this often meant re-deploying VSI, a support ticket, or an attempt at manual registration by SSH into VSI. None of those options were good.
In VSI 8.6 during OVA deployment, the section that formerly required vCenter information will now ask you to acknowledge that you understand you must navigate to the VSI hostname/IP to register the vCenter:
Personally, I think there were better ways to explain this and I’ll try to give my feedback to the team to adjust, though it may be perfectly understandable to you. But anyway after it deploys and you power the VM on, follow the instructions and navigate to the URL of the VSI vApp (https://<FQDN_VSI>/) where you can go through the four step wizard. First, the welcome screen.
Next, if you are going to import certificates, you do that in this screen. If you are using default certs, just hit NEXT. BTW be warned that if you toggle the Enable SSL: vCenter(s) switch but do not intend on importing certs, the NEXT button will gray out even if you toggle the switch back off. If you run into this, select BACK to the welcome screen and then NEXT again and when you return to this screen the NEXT button will be blue again. Appears to be a minor GUI bug that I have not seen in a similar screen in the vCenter.
Now finally we enter in the information we formerly supplied during OVA deployment. One thing I want to point out is that the only validation done here is to ensure your passwords match. VSI does not proactively test the connection to the vCenter. It will only attempt to connect in the next screen when the registration is attempted.
Now you’re ready to use VSI.
VSI Plugin Management
Once registration is complete, you can return to the URL of the VSI vApp (https://<FQDN_VSI>/#/login), to access the Plugin Management screen. Normally you don’t need to do this, but I want to cover it for completeness. When you get the login screen, you access as the vCenter administrator (typically the user you entered above to register).
One particular quirk about the login I want to mention here. You may have noticed (or you can look now) that I did not provide the domain name, @protection.local, with the administrator user when I registered the plugin initially; yet here I’ve included it. I normally never use the domain because I changed the default domain of my vCenter from localos to protection.local when I first deployed the vCenter – less typing. VSI registration worked perfectly fine without it, and when I go into the VSI plugin it will automatically show me the user with the domain; however if I try to leave out the domain when I login into the Plugin Management I will see:
So VSI must have the domain name in the Plugin Management screen or it fails. Obviously this is because of the code so there’s nothing we can do about it (well I will file a bug), but a heads-up if you also do this.
And after the login is successful, the vCenter Servers screen is presented first:
There is a new column for the vCenter Connect Status shown above. You should hopefully see the green box “Connected”, but the “Not Secure” red box depends on if you setup SSL and a certificate. I have not, hence my status is a red “Not Secure” rather than green “Secure”. Note if the vCenter is disconnected for some reason, the first box will be yellow and say “Disconnected”.
Plugin Management Functions
Plugin Management offers a few capabilities:
- Manage vCenters
- Manage Certificates
- Manage Logs
All these functions are available from within the vCenter, save for the ability to specify the log level. While you can download the logs from the vCenter, you can only set the Log Level from within Plugin Management.
Remember setting the log level means going forward. If I set the log level to debug and immediately download the logs, those logs are at the previous level (default INFO).
Plugin in vCenter
VSI is still accessed off the main Menu screen at the top:
Upon accessing, if you are familiar with VSI you may notice the menus on the left-hand side are reduced and changed. These are the changes:
- A new drop-down at the top for the instance (shown in blue). If you select the small blue arrow next to the name, you will see the details pop-up in the inset at the bottom of the red arrow.
- Removal of Unity-specific menus.
- New Certificates menu to match the one in the Plugin Management.
- Changed Server to Server/Plugin Management in the Integration Services widget in the right-hand panel along with a new hyperlink to it.
The certificate menu is provided so that you can view all the public certificates and any certificate(s) you imported. This certificate tab will appear in multiple places in VSI. Note that there are many public certificates already included in the IAPI database. Here you’ll see I have 93 for this particular non-GA build, your build may be different:
The number of certs is perfectly normal and expected as they are bundled as part of the Java Key Store (JKS). These public certs might be required as part of your certificate chain. If you want to see the certs that are specific to your vCenter, look under the vCenter Servers menu.
Let’s take a look at the new features.
One of the new features is the ability to see snapshot policies on a storage group or datastore, not simply the one-off snapshots. You get a glimpse of this at the point of adding an array – there is a new column for the Snapshot Policies highlighted with the red box. You can see I have a few defined for two of the storage groups. BTW this column will be present whenever storage groups are listed, such as when provisioning a datastore. This feature is informative only. You do not have the ability to create snapshot policies.
The snapshot policy will also be shown under the Storage Details for the datastore.
And under the Snapshots tab any snapshot policies will be included:
VSI 8.6 now offers the ability to delete multiple snapshots at once. Previously it was only one at a time.
VSI 8.6 introduces the first phase of another feature, hosts. In this release we will show the hosts that have storage presented from a particular array, read-only. In the image below my array presents storage to both hosts in my vCenter. The view includes all storage groups each host has in a masking view, the name of the initiator group for the host itself, as well as any parent host groups. If you look closely at the storage groups you’ll see that they are not the same between the hosts. In addition, as shown in the inset, if you put the cursor over the information icon under the initiators column, it will list the host initiators and the protocol. Note this hosts tab, like the certificates tab, will appear in multiple places in VSI.
I have no clear roadmap to share on the next phases.
I’ll wrap things up with a couple important notices.
You’ll see this statement called out in the Release Notes:
VSI does not support remote replication, only local through snapshots, so what exactly does this mean? Well, simply that you can’t enable replication on the backend device and expect VSI to know anything about it. For example, I provision a datastore with VSI. Then I go into Unisphere and I replicate that device (or storage group) with SRDF which certainly I can do without issue. But if later I then want to expand my datastore in VSI, it will fail because it is unaware of the replication relationship I’ve enabled. You can expand it in Unisphere, though, and then expand the datastore through the vCenter (reminder here). My advice, therefore, is if you need to replicate part or all of your VMware environment, best to avoid VSI’s provisioning capability. But the more basic functions like in-context storage translations of the replicated devices work fine, i.e. the read-only actions.
VSI supports many platforms, and while most features are universal across them, there are some specific right-click options which are for arrays other than PowerMax. For example, when you right-click on a datastore there are two options off the VSI menu that are not pertinent to PowerMax. They are Create Thin Clone and Refresh Datastore. If you select either you will get a dialog with an error saying the particular feature is not available.
I believe that’s it. BTW always feel free to leave a comment with feature suggestions. We want VSI to be as useful to customers as possible.