I have Tintri storage in my environment, and one of the aspects that I love about it is the visibility it provides into our vSphere environment. The VMStore itself has all sorts of great dashboards and analytics, but the integrations don’t end there. Tintri has a vCenter plugin which extends some features over to the vSphere client. Installing this plugin is not something that I commonly do. After all, if I find myself regularly blowing away my vCenter, then I probably have other issues. With that in mind I wanted to document the installation process so that a) if / when I need to do this again, I can do it quickly enough and b) if it is helpful to others, then great. Note that most of the below is for the VCSA vSphere 6 appliance, not a windows based install. I do have a file path for a Windows configuration file listed below.
You can download a copy of the plugin from Tintri’s support page. As of the moment, the most recent version is 22.214.171.124. The first challenge will be getting the plugin over to the appliance. For this, I used WinSCP, which you can find here. In the spirit of not being easy, I immediately ran into this error message when trying to connect:
Host is not communicating for more than 15 seconds. If the problem repeats, try turning off ‘Optimize connection buffer size’.
After some quick Googling, I found VMware KB article 2107727, followed the instructions and was able to connect. The short version is that WinSCP can’t use the default appliance shell, so we need to enable Bash. After I implemented that change, I was able to connect and upload the package to /tmp.
RUNNING THE SCRIPT
Running the script is fairly straight forward – I SSH’d into the VCSA, logged in as root, applied execute permissions (chmod +x /tmp/TintrivSpherePlugin_126.96.36.199.sh) and ran the script (/tmp/TintrivSpherePlugin_188.8.131.52.sh). The script itself doesn’t take long to run, but there is one area that I think could be cleared up a bit. During the install, you’ll be prompted for credentials – these are the credentials that you would use to log into the vCenter web client, not the appliance.
To clarify, I was trying to log in with my root account (the same as above), and it kept failing. I just assumed typos on my part at first, but then I thought I should try my vCenter credentials. I used the [email protected] username and its password, and the install completed nicely.
After that, I logged into the interface and had my handy new plugin available.
BUT WAIT, THERE’S MORE
The query execution timed out because of a back-end property provider ‘com.tintri.vcplugin.server.uiservicesimpl.dam.TintriVMLatencyPortletImpl’ which took more than 120 seconds.
It was pretty clear that the plugin was causing some sort of issue. Support initially suggested that I change the JVM Heap Size. For reference, you can change these by editing the following files (note the line wrap for the Windows entry):
- For Windows: \Program Files\VMware\Infrastructure\vSphereWebClient\ server\bin\service\conf\wrapper.conf
- For vCSA: /usr/lib/vmware-vsphere-client/server/wrapper/conf/wrapper.conf
The setting that you will want to adjust (likely increase) is the ‘wrapper.java.maxmemory’. After adjusting that, you’ll need to reboot the vCenter server/appliance. It is worth noting that the above will adjust the heap size for just the vSphere client. You can actually use the VAMI interface (port 5480) to change the inventory size to a larger tier, which will affect other services. See KB 2126282 for more information.
The above is only valid for versions of vCenter prior to 6 (note: The VAMI was brought back in version 6.5. I have not tested it for the above functionality at this time). In my case, that setting did not exist. I did come across this great post by William Lam which detailed some changes to memory allocation in the VCSA v6. Long story short, the appliance automatically takes available memory and divides it up proportionally amongst the running service. So what does this mean? Basically, I just increased the VCSA’s memory from 8 GB to 10 GB and it automatically ‘grew’ the available memory for vSphere client, which by extension fixed the plugin error above.