So what can't you do with VMware's VSA?

VMware's vSphere Storage Appliance (VSA) has restrictions. It is a virtual NFS filer only, not a block-level storage facility as VMWare implied, and it is not accessible by apps.

Our understanding, based on VMware's announcement material, was that the vSphere Storage Appliance (VSA) pools the direct-attached storage in 2 to 3 physical servers and presents it as a virtual single storage space that is available to accessing apps (executing inside virtual machines on those three servers) as a block-access data store analogous to HP's P4000 VSA.

However, Martin Niemer, VMware's solutions marketing director for ENEA, said of the VSA: "This is NFS-only. ... VMs (the O/S in the VM) do not access this at all as ESXi handles the storage and just stores the VMDK files on it. The data (ie, O/S) is then stored inside the VM (virtual machine)."

VMware vSphere Storage Appliance presents an NFS resource.

We asked Niemer if apps in VMs executing in servers that are not part of the vSphere Storage Appliance could access the VSA. He said: "Apps are not accessing that storage. There is a general misunderstanding here. This is not intended to be a NFS filer, but instead a store for VMs. So the VMs are stored on the VSA and data is stored inside the VMs, not directly on the storage."

Apps and networked storage

In general, applications running in a physical server can connect to a networked filer – such as an EMC Celerra – and use its resources to create, read, and write file data.

By extension, applications running inside VMs in a virtualised server can do the same thing: connect to a networked filer – such as an EMC Celerra – and use its resources to create, read, and write file data.

Now, let's replace the networked EMC Celerra array with a VMware VSA, and ask the same question: can apps running inside VMs in a virtualised server connect to this VSA, as if it were a networked filer, and use its resources to create, read, and write file data?

Martin Niemer's comments above indicate that they cannot.

Asked to clarify this, Frederik Sjostedt, VMware's director of product marketing in EMEA, said: "VSA runs as a virtual appliance on top of vSphere. VCenter is required to set it up and VSA is then visible to vCenter as a storage resource. Each of the virtual machines then running in the infrastructure will only see the storage capacity that has been allocated, rather than SA itself."

Erwin Breneis, a lead systems engineer for Strategic Partner Accounts at VMware, confirmed this: "Yes – the only [ones] who have access to the NFS datastores are the hosts. Indirectly the guest can also access the NFS datastore, because the VMDK's are on the NFS data stores."

So our understanding now is that VSA is an NFS file store belonging to the hypervisor, ESXi, and used by it for storing VMs, and not for storing files created, read, and written to by apps running in these VMs. It is not a visible storage resource for apps inside VMs, as is the case with traditional networked storage.

VSA storage can be used by ESXi hosts outside the immediate VSA cluster of two or three nodes, as Breneis says: "You can use the VSA Cluster with further ESXi Hosts – if the customer uses a vCenter Standard and further vSphere licences – for example vSphere standard."

VMware obfuscation

VMware announcement material directly compared the VSA to SAN storage, implying it is a SAN substitute:

Before vSphere Storage Appliance, implementing virtualization required specialized knowledge in shared storage hardware. For example, a SAN configuration may require an FC Switch, a Server HBA, FC cables, and an external RAID Storage hardware. But with VSA, installation involves just a few mouse clicks and entering the desired IP address. And because VSA is integrated with vCenter Server, you can manage your entire IT environment in one place.

By not saying it was an NFS-only file store, VMware strengthened the impression that it was a SAN substitute. Why did VMware not say it was a virtual filer ?

Niemer said: "This [the VSA announcement] is targeted to a non-technical audience, so saying it is a storage appliance makes it much clearer."

As mud sir, as mud.

Searching on the VMware website for "vSphere Storage Appliance + NFS" gets you nowhere. The same search term on Google reveals lots of hits, such as NTPRO.NL.

It says:

Each ESXi server has a VSA deployed to it as a Virtual Machine. The appliances use the available space on the local disk(s) of the ESXi servers & present one replicated NFS volume per ESXi server. ... The NFS datastores exported from the VSA can now be used as shared storage on all of the ESXi servers in the same datacenter. The VSA creates shared storage out of local storage for use by a specific set of hosts.

VSA extensions

We asked Niemer a series of questions about future CIFS support, iSCSI and FCOE access. The answer was: "No comments on future plans."

We asked him why there isn't block-level access, and he replied: "This was not [the] scope of the project in version 1.0."

We are told the vCenter will only support one VSA instance. There are no VAAI v1.0 features as VSA 1.0 is an NFS-only device.

VMware's VSA is neat, enabling SMBs to get some shared storage benefits – such as high availability – when VMs are being stored, without buying, managing and operating a shared storage array. But the apps in this VMS don't get the benefit of shared storage: only ESXi gets those benefits.

If you wanted to give the apps shared storage benefits as well, without having a shared storage array, then you could run HP's P4000 VSA on the same servers as VMware VSA. How's that for adding complexity?