VSI 4.0 Client Access

I understand the reason for the need for restricting the access.  I would have rather seen EMC create a process/procedure to create a new role with proper permissions as an option for the customer rather than being so limiting.

For this particular implementation I want to keep the remote calls from various sources to SE to a minimum.  Actually I want to limit it to a single IP address in this case.  It would be ideal to do the install and config once on the vCenter server and give access to the client as needed from there.  Due to the design decisions previously mentioned I'll just do the install on the vCenter server and tell the admins that if they need to use the VSI they'll have to login via RDP and launch the client from there.

The SEVA is out of the question at this particular customer unfortunately.  I have recommended it and they want to leave things as they are.

Thanks for the quick and informative response!

VSI is not a server pull-down plug-in so you will need to install VSI on each individual machine that requires it. The main reasoning for this was as a simple way to control who has access to the plug-ins so not everyone who has access to the vCenter from the vSphere Client can download and use any plugin that is installed. Certain plug-ins have powerful functionality that not all admins may want everyone to use. Granted, use of 3rd party plugins can be controlled by VMware permissions, but it is not particularly granular and turning those permissions off can restrict access to ALL plug-ins. Hence the design decision.

That being said, you do not need to provide gatekeepers to all of the hosts (or any of them directly for that matter) as VSI has the ability to use a remote SYMAPI server over a TCP/IP connection for device resolution etc. In the VSI configuration tab under solutions enabler, you can put the IP Address or hostname of a remote SYMAPI (Solutions Enabler) server that all of the clients can share. With version 4.0 of VSI, you do not even need to manually install Solutions Enabler on each client as the VSI install now bundles the required libraries automatically. So set up one SYMAPI server with gatekeepers, install VSI (and only VSI) on the clients you need and you are good to go.

I highly recommend using the Solutions Enabler Virtual Appliance that can be downloaded on Powerlink for the SYMAPI server. Very easy to deploy and setup.

Cody Hosterman

Hi! VSI 4.0 is my fault, along with the issue you're referring to. There is a very good reason why we chose to distribute VSI 4.0 the way we did. To understand it requires a bit of background on vSphere server-side extensions and client-side plug-ins, as well as VSI 4.0 itself, so please bear with me.

• Server Extension - This is an item a developer can register on a vCenter that allows for the creation of custom tasks, privileges, faults, etc. A server extension can also have an associated client-side plug-in.
• Client-Side Plug-in - This is what VSI is, and countless other vSphere plug-ins are. When you go to the vSphere client's Plug-in Manager and see a list of "Available Plug-ins", what you're seeing is a list of server extensions that have advertised client-side plug-ins as part of their registration. A user can then install those plug-ins by right-clicking on the advertisement, clicking Install, and the vSphere client will download the MSI file from wherever it is hosted (on the internet, on the vCenter server, etc).

When you install client-side plug-in locally, you're simply bypassing the server extension advertisement. Not all client-side plug-ins have server-side components and thus do not need server-side extensions. However, as you've pointed out, one advantage to advertising the client-side plug-in as part of a server-side extension is that everyone in an organization who logs into that vSphere environment will see the available plug-in and make it easy to download and install it.

We couldn't allow this for VSI for a few reasons:

1. VSI 4.0 is at its core a platform. Yes, it is a vSphere plug-in, but VSI actually hosts Features developed by other groups at EMC such as "Path Management for VSI", "Storage Viewer for VSI", etc.
2. A user would have to know to install the "VSI Framework" via vSphere's plug-in manager *first* and *then* install the Features. Not to mention the Features' other dependencies (in the correct order). This is not a burden we wanted to place on our users.
3. The vSphere client's plug-in manager only support installing extension-associated client-side plug-ins if they are available via a URI pointing to an MSI file. Because an MSI file cannot be a bootstrapper, it cannot contain dependencies. That is why our Features are distributed via EXEs. They contain the Feature and its dependencies, including the VSI Framework.
4. Not all users have the rights to access all of the software available for these storage devices, and since vSphere doesn't discriminate or restrict the plug-ins available in its client's plug-in manager, we didn't want non-administrators or non-storage administrators presented with this functionality.

I hope this helps to clarify why we did what we did. In the end there is nothing to prevent you from registering the VSI Framework MSI and the subsequent Feature MSIs on the vCenter server and making them available to your organization if that is what you want to do. It's just not something we felt would serve the interests of the majority of our customers for reasons both technical and otherwise.