Today EMC released the latest incarnation of the VSI Web Client – version 6.2. Although this release is focused on XtremeIO and thus contains no VMAX enhancements, there are a couple noteworthy reasons to upgrade (beyond the new, cleaner SIS interface which is awesome thanks to Denis Zholob) even if you aren’t using XtremeIO. First, 6.2 includes a couple important bug fixes for VMAX:
The first impacted a few of our customers (I worked with a number of them on this) when attempting to register a vCenter. Some customers experienced this as a “hang” when registering even if the IP/FQDN was pingable from the SIS console (root/emc), while other customers were “dark sites”, such as government locations which did not have Internet access (if a java file was missing from the browser implementation, we attempted to get it from the Internet). The bug fix resolves both these problems. No Internet access is required.
The second bug fix is related to FAST VP. In 6.1, when a user provisions a datastore or RDM through the wizard, selection of the thin pool comes before the masking view. For FAST VP this poses a problem – let me explain. Let’s say I have thin pools A, B, and C and I have a FAST VP Policy that comprises just thin pools A and B. Now my storage admin has associated the VMware storage group to that FAST VP Policy. Now I as a user go to provision a datastore and not knowing any better I choose thin pool C and then my masking view with the VMware storage group. My device creation will fail because I chose a thin pool not part of the FAST VP Policy. I will see the following error: “A Thin Device under FAST control must be bound to a Pool in a Virtual Provisioning Symmetrix Tier in the associated FAST Policy.” In other words you chose poorly. So in VSI 6.2 what we do is just swap the wizard screens – you select the masking view first so we can filter the thin pools based on that. Now you cannot make a mistake. Pretty simple fix, but also important.
The other reason to upgrade is also bug related, though this one could not be avoided for VMAX customers – it is one of those dormant bugs you didn’t know you had until I tell you – and unfortunately now I’m telling you. In the Release Notes of 6.2 there is a special note in the upgrade section which basically says if you have any registered VMAX arrays in your 6.1 SIS, you cannot successfully upgrade without removing them first. Now I would love to tell you to just wait for VSI 6.3 and this won’t be a problem, but I can’t. The bug has to do with the manner in which the data is formatted and stored in 6.1 and while the bug is now fixed in 6.2, every future version of VSI will have the new format and thus no matter what you will need to go through this special upgrade process. So my advice is to do it now so you are ready for 6.3 which will have VMAX enhancements. I’m going to run through what I did in my environment for the upgrade, as the VSI documentation explains what you need to do but does not always include screenshots.
Let me start by laying out the steps we are going to take. I should note too that while all versions highlighted in the screenshots below start with 6.2, the third digit may be different because of the pre-GA builds I used for this purpose. Not critical, but I don’t want to confuse things. So steps:
- Determine what VMAX arrays are registered in 6.1 SIS and what user owns each one.
- Login as the owner of said array(s) and record what users have access to what thin pools on the array(s).
- Once the users are recorded, copy the array ID to notepad, then delete the array(s).
- Unregister SIS from the vCenter.
- Login as admin and unregister all vCenters.
- Take a backup of the database in 6.1 SIS – save the file with a .sql file extension to a local directory.
- Shutdown the 6.1 SIS.
- Deploy the 6.2 SIS using the IP information from the 6.1 SIS (why it is important 6.1 is down). Note you are welcome to use a different IP.
- Log in to 6.2 SIS as admin, change the admin password, take a quick backup (in case there is an issue) then run a data migration using the .sql file from step 6.
- Register each vCenter again.
- Login to vCenter and register the new SIS.
- Login to SIS as each user from step 2 and add back each array removed. Add back users and thin pool access recorded in step 2. Alternatively you can add the array through the vCenter then go into SIS and add user access.
I’ll now flesh the steps out with screenshots of what I did in my environment. Though I have many arrays, I only show a single array with a single extra user in the example to keep things simple. You’ll notice I sometimes condense the screens to save space and some steps really did not require a screenshot.
- Determine what VMAX arrays are registered in 6.1 SIS and what user owns each one. In my environment I have one vCenter so I log into SIS as the administrator who owns the array (email@example.com):
- Login as the owner of said array(s) and record what users have access to what thin pools on the array(s). Here besides the owner I have John Doe as a user.
- When I check the pools I see JDoe has access to one of them, the FC_Pool.
Click to enlarge – use browser back button to return to post
- Once the users are recorded, copy the array ID to notepad, then delete the array(s). You must delete the arrays here, not simply unregister them in the vSphere Web Client.
- If you want, you can double-check that the vCenter no longer shows the array:
- Unregister SIS from the vCenter. Now potentially if you are using the same IP for VSI 6.2 you can run a “Rescan” once you re-register in step 10 but I recommend removing it and adding it back even if it is the same IP.
- Login as admin to SIS and unregister all vCenters.
- Take a backup of the database in 6.1 SIS – save the file with a .sql file extension to a local directory. Login as admin to do this. Depending on your browser, you may or may not be prompted for a file name. When I used Chrome it just saved the file as “Download.txt” so I had to rename it to VSI6.1_backup.sql.
- Shutdown the 6.1 SIS. If you are going to use a different IP for 6.2, this is optional.
- Deploy the 6.2 SIS using the IP information from the 6.1 SIS (why it is important 6.1 is down) or a different IP.
- Log in to 6.2 SIS as admin, change the admin password (ChangeMe default), take a backup then run a data migration using the .sql file from step 6. Make sure you are in the right environment. You should see the new version on the welcome page.
- Take a backup
- Now migrate. Be sure you do NOT choose “Restore from a Backup” or you will revert VSI to 6.1 and then you will have to restore again with that backup from the previous screenshot.
- Register each vCenter again.
- Login to vCenter and register the new SIS.
- Login to SIS as each user from step 2 and add back each array removed. Add back users and thin pool access recorded in step 2. Alternatively you can add the array through the vCenter then go into SIS and add user access as I do below:
- Now add back user permissions. The data migration in step 9 will already have added the users back. I don’t show all the steps, but the general flow.
So that’s it. Once complete your environment is ready to go, and more importantly will be ready for a “normal” upgrade to VSI 6.3.
Feel free to let me know if you hit any issues or the steps do not follow in your environment. I’m always ready to be corrected.
VSI 6.2 Release Notes:
VSI 6.2 Download: