The list of VMware storage integration features in vSphere is growing at a rapid pace. From backup to enterprise array offload, VMware is staking their claim. But information about one new storage feature in vSphere 5 has been scarce: The true nature of the Storage API for Storage Awareness (VASA) is only just beginning to be revealed.

VASA: Born of Necessity

vSphere has some amazing automated storage mobility features. The ease of moving data between LUNs and even arrays with Storage vMotion is a revelation to those of us unlucky enough to have used manual migration methods in the past. And VMware has automated this with the new Distributed Resource Scheduler (DRS) capability, allowing vSphere to make its own decisions about data placement.

But this kind of dynamic movement can hurt as well as help. What if an administrator moves a VMDK from high-performance to low-performance storage? Server responsiveness would suffer, perhaps even resulting in an application outage. And how could Storage DRS avoid doing the same thing?

VMware realized they needed some mechanism that could “tag” a storage resource with its capabilities. This is the real reason for their creation of Profile-Driven Storage and VASA.

VASA Does One Thing

In vSphere 5, VASA is incredible simple: It is a basic protocol for vSphere to request a “capabilities” string regarding a LUN or NFS share from a “provider”. The content of this response, and indeed the form that this provider will take, is left up to the individual storage vendors.

VASA Providers can take many forms. Dell is reportedly developing a vCenter plugin to report capabilities. EMC and NetApp will use a software application that runs on a virtual or physical server. In all cases, the software uses a proprietary call to the storage array, in effect relaying and translating the VMware request.

The VASA “Capabilities” string is undefined as well. Most vendors use a list of technical attributes as their response string, and each has adopted their own strategy about how to present information:

Dell’s EqualLogic returns a comma-separated list like “RAID, SSD, REPLICATED”

NetApp’s provider uses semicolons, as in “Dedupe; Replication”

HP’s is very detailed, with a schema specifying Drive Type, RAID Type, Provisioning Type, VV Type, and Remotecopy

EMC appears to have a standardized set of much-shorter tags, like “Performance”, “Multi-Tier”, “Capacity” and such

These are passed through to vCenter, where an administrator can decide how to interpret them.

VASA Today and Tomorrow

In its simplest form, VASA capabilities tags enable both manual and automatic storage placement features to respect tiered storage policies. This is important to maintain proper system performance and availability. In the future, I expect more advanced VASA providers, perhaps even integration of the providers into vCenter plugins. I also look forward to a standard capabilities tagging schema and smarter handling of returned tags. Right now, for example, EMC’s Clariion and Symmetrix lines both tag LUNs as “Performance”, but these are obviously not equivalent.