I have done a few posts on here that involve the Pure Storage Plugin for the vSphere Web Client (here and here) since I joined. Well here is another. We just released a new version of the Web Client Plugin (I am going to refer to it as WCP for the rest of this post because I am a lazy typist). We bundle the WCP into Purity and therefore the WCP is installed, updated and uninstalled from our GUI/CLI to vCenter (yes we do also offer a mechanism to update it outside of upgrading Purity itself). Our latest release of Purity, 4.0.12, includes WCP version 1.1.13–while there is no new functionality there are two important fixes.
Our WCP currently does a few primary functions:
- Create new volumes and VMFS datastores
- Resize volumes and their hosted VMFS
- Delete volumes/VMFS
- View underlying volume information (data reduction, name etc.)
We have a HUGE laundry list of new features we want to add in the next releases (currently underway) and some of the features are going to be very useful (more on that as they come) but for the moment let’s look at this release. So enough proselytizing, I’ll get on with it.
There are two fixes:
1). In some situations users could not provision new storage with the WCP as it would not be able to correlate a selected host or cluster with a host or host group on the array. Therefore it didn’t know what host or host group to connect the volume to and provisioning would fail. Long story short there were some situations where our algorithm was either too strict or too lax to make a match. This has been fixed in 1.1.12–in every situation that I could create to reproduce this issue is now resolved.
2). The second issue caused an error when loading certain screens in the vSphere Web Client that were often (at least seemingly) unrelated to our plugin. For instance the standard datastore summary tab. The following error would appear preventing the summary information from loading:
Took me some time to figure out this was caused by our plugin but indeed it was. Fixed now! So if you see this error and our plugin is installed, upgrade to this latest release–it will fix it. Please let us know if it doesn’t of course. It is a pretty straight forward issue, vCenter was calling for information and the plugin was inserted into various work paths and vCenter was expecting the same number of resultSet as it had asked for in querySpecs. We were returning back a resultSet of 0 for all calls. The fix is to return back the same number of resultSet that it had asked but those resultSet are empty resultSets. Essentially it was looking for some information on the object being queried and we were returning too few results (even if they were null).
If you are running Purity 4.0.9 or earlier you probably have this plugin version. Now if your environment is working great you do not have to upgrade if you don’t want to, but if you are I would recommend checking this out. You can verify the version of the WCP in the Web Client.
To get the latest version of the plugin you have two options:
- Upgrade to Purity 4.0.10 and then upgrade the WCP by pushing it from the array to vCenter in the normal fashion in the GUI or CLI.
- If you don’t want to upgrade Purity just yet contact support and tell them you want our newest WCP that fixes these issues. The plugin install in this instance is a bit different than option 1, support can help you–it is still quite simple. Essentially it needs to be loaded onto the controller and then it can then be upgraded on the vCenter(s) in the normal fashion as shown below.
If you chose option 1, I recommend using the GUI to upgrade the WCP instead of the CLI, it is just a bit simpler. Once you are running Purity 4.0.12 the plugin installation bin files will be updated too–so all you need to do is push it out to your vCenter(s). Also–you only need to upgrade one array if you have more than one. The new WCP works with older Purity revisions–nothing needed to be changed within Purity. So login to the GUI and go to System>Plugins>vSphere and enter in credentials for vCenter.
The available version should be 1.1.13. Go ahead and upgrade the WCP on your vCenter(s).
Once upgraded you will be able to provision storage properly–any issues with correlation should be fixed. Note that if you are logged into the Web Client when you upgrade the WCP you will have to log out and log back in to see the updated version.
Let me know if you run into any issues!
Also–if you would like to see any features put into the plugin please let me know here or on Twitter! Always looking for outside input on how we can improve our products.
Hello,
I’ve just tested, and it’s necessary to open TCP 443 Outgoing connexion on ESXi, from them to the Pure arrays. Could you specify it in the post ?
This parameter is in the ESXi firewall (not vCenter), and it called “httpClient 80,443(TCP)”
Best regards,
Loïc
Loïc,
Hmm I did not realize this requirement! Let me test it and I will add it to my firewall post. Thanks a lot for letting me know!
Cody
I havent been able to replicate this–what procedure did you follow to confirm this? I must be missing something. Thanks!
Hello, Who i tried to configure an array, I can’t join it without configure the esx firewall. Just apply this workaround, nothing else. It make sense, without openned ports, arrays cannot communicate.
Hello, Who i tried to configure an array, I can’t join it without configure the esx firewall. Just apply this workaround, nothing else. It make sense, without openned ports, arrays cannot communicate.
Envoyé avec AquaMail pour Android http://www.aqua-mail.com
I enabled the outgoing port and disabled access to the FlashArray IP but it still registered the array. We don’t ever speak directly to the array to the ESXi (or the other way around) the plugin sits on the vCenter which talks to the array from the vCenter and when something needs to be done on a host the web client talks to vCenter which then manages the hosts. I am going to ask engineering why this would happen for you and not me. You may want to open a support case.
I confirmed with engineering that you should need to special firewall settings from ESXi to the FlashArray. Just standard ESXi rules that allow for normal, out of the box, communication between ESXi and the vCenter will suffice. So if you are seeing something else, please open a support ticket so we can identify the issue.