Home > Blogs > VMware vSphere Blog

EMC’s VASA Implementation

For weeks now I've been trying to find the time to implement EMC's VASA Provider, which was released last month. What with researching new storage features for the next release of vSphere, and preparing for next week's VMworld 2011 in Copenhagen, I've just not had a moment. If you are not familiar with VASA, the vSphere Storage APIs for Storage Awareness, you can read about it in this earlier post. However, one of the lads I worked with in GSS Cork stepped into the breach and got it set up – take a bow Fintan Comyns :-) Fintan is an ex-EMC'er like myself, so we go back quite a way.

The VASA vendor provider from EMC is actually part of the SMI-S Provider v4.3.1 which also includes the correct version of Solutions Enabler v7.3.1.

After discussing the implementation steps with Fintan, this is basically what is needed:

  1. Install SE v7.3.1 (Windows or Linux)
  2. Add-on the SMIS-S 4.3.1 component
  3. Assign a GK (Gatekeeper) LUN from the DMX to the VM running SE (as an pRDM)
  4. For the DMX, the vendor provider was automatically discovered in-band. We're not sure if this was due to a previous version of Solution Enabler being installed, or if this is by design.
  5. For the CX, a TestSMiProvider command was used to add the provider out-of-band.
  6. Add the appropriate VASA provider URLs to the Vendor Provider section of the vCenter UI.
  7. Rescan the SAN
  8. Storage Capabilities appear against the LUNs and in the VM Storage Profiles.

Please note that Fintan observed that for the DMX, the vendor provider sync operation in vCenter took some time (minutes), but for the Clariion the sync was almost instant.

Here is a look at some of the LUN capabilities that are now surfaced:

Sample Symm/DMX LUN Capability

This particular LUN is presented to an ESXi host which is managed by a vCenter server which includes the VASA Provider from EMC. This particular LUN has a storage capability called Performance. By looking at the description of the capability, one can see that the LUN is backed by FC drives or high-end SAS drives. This is pretty cool, as historically you'd have to have an email exchange, or heaven forbid, an actual conversation with your SAN admin to discover this information :-)


Sample Clariion/CX LUN Capability

Looking at a sample datastore from an EMC Clariion, the capability is Multi-Tier. The LUN is comprised of drives from multiple tier types. Again, this is useful information when determining how your VMFS datastore looks at the back-end.


If you are a regular reader of this blog, you will be aware that VASA is an enabler for another vSphere 5.0 storage feature called Profile Driven Storage. This allows you to ensure that your VM is initially provisioned and remains on a suitable datastore. To build a profile, one can choose capabilities surfaced by VASA. Let's have a look at these capabilities next in the context of VM Storage Profiles.

All Symm/DMX LUN Capabilities

Here are a list of all the capabilities as they appear in the VM Storage Profiles when only LUNs from the EMC DMX are discovered:

Dmx capabilities
Using the storage capabilities, one can now start to build VM Storage Profile, and using this new vSphere 5.0 feature, you can now tell at a glance whether or not your VM is residing on the appropriate datastore. All very good – well done EMC.

All Clariion/CX LUN Capabilities

The same vCenter server was then used to add the vendor provider for the Clariion, so that both the Clariion and DMX were discovered at the same time. You can see a few additional storage capabilities appear, but many of the capabilities are the same as those seen on the DMX earlier:

Cx & dmx capabilities

Now you may have noticed something which we also noticed. The same capabilities are listed twice. How do you differentiate between capabilities which belong to the DMX & those which belong to the CX? If I select Performance, how do I select datastores that are only on the DMX & not on the CX? We're not sure either. Perhaps something we're doing here is not a best practice, meaning that perhaps only one vendor provider for one array should be associated with a vCenter at any time. If any EMC aficionados who are reading this article have any advice to offer, we'd love to hear from you.

However, we all know this is 1.0 of VASA. EMC should be congratulated in getting their VASA vendor provider out and available as soon as they did. Enhancing the management view of storage for vSphere Admins and enabling the use of storage profiles as a way of selecting storage is part of VMware's vision and vSphere 5.0 features such as VASA & Profile Driven Storage are the initial steps we are taking towards this vision. Without our storage partners sharing this vision, we wouldn't be able to deliver on these features.

Where can you get the bits (Solutions Enabler & SMI-S) to implement this on your own EMC storage arrays? Why PowerLink of course.

If any readers see any other information about VASA implementations from our storage partners, I'd be delighted if you could leave a comment directing me to it.

Get notification of these blogs postings and more VMware Storage information by following me on Twitter: Twitter @VMwareStorage

This entry was posted in vSphere and tagged on by .
Cormac Hogan

About Cormac Hogan

Cormac Hogan is a Senior Staff Engineer in the Office of the CTO in the Storage and Availability Business Unit (SABU) at VMware. He has been with VMware since April 2005 and has previously held roles in VMware’s Technical Marketing and Technical Support organizations. He has written a number of storage related white papers and have given numerous presentations on storage best practices and vSphere storage features. He is also the co-author of the “Essential Virtual SAN” book published by VMware Press.

6 thoughts on “EMC’s VASA Implementation

  1. Victor Forde

    Great post, thanks!
    On Step 1 can the SE installation be a client/server (symapi) installation? With the server side as Solaris 10 Sparc Control Host? So the Windows VM is the client side SE.
    Just wondering is it mandatory to have Gate Keepers assigned as pRDMS to a VM or can you use a client server setup with a remote server that is not windows/linux.

  2. Craig Stewart

    Hi Victor
    For VASA you need SMI-S provider V4.3.1 which can be downloaded at the link below. V3.3.1 is the latest version I can see that supports Solaris and unfortunately this version won’t support VASA.
    With regard to your other question, the solution enabler software and the SMI-S software need to be installed together. With the latest SMI-S software (4.3.1) the correct solution enabler software is included (
    VASA is essentially already a client / server implementation. The server in this case is a dedicated windows / linux machine (Virtual or Physical) that has the Gatekeeper LUNs presented to it. This server will have Solution Enabler and the SMI-S provider installed on it. vCenter is the client, you enter the URL shown below with the IP / DNS name of the remote SMI-S / SE server within the storage profiles section in vCenter and the information from VASA is then displayed into vCenter.
    So for your setup, based on the lack of support for Solaris you would probably look to have a remote windows / linux server with Solution Enabler and SMI-S installed and a gatekeeper lun presented. Point vCenter at that and the VASA information should pull through.
    Hope that is of some help, happy to help further if required.

  3. Victor Forde

    Thanks Craig that answers my questiand makes it clear! Having a Remove Solaris symapi server isn’t supported on version v4.3.1 (which is the one with VASA support) so Windows/Linux VM with an RDM gate keeper or a remote physical windows/linux are the only options and point VCenter at that.
    Cormac that’s me sorted :-)


Leave a Reply

Your email address will not be published. Required fields are marked *