This post is also available in: Italian

Reading Time: 5 minutes

VSA (VMware vSphere/Virtual Storage Appliance) is a solution, introduced in version 1.0 with vSphere 5.0, to transform local storage in shared storage. Basically a VA on each node use a local datastore to export it via NFS. But most important is also make a replication to another node.

I’ve already talk about it in a VCP exam objective (VSA 1.0 questions are part of VCP5 exam), but honestly the VSA 1.0 had several disadvantages:

  • Cost: from my point of was too high (expecially for the position of this kind of solution).
  • Disks usage: is first release was necessary a local RAID1+0, so your storage space was reduced to 25% (considering also the replication). To be honest on January 23rd, 2012, VMware lifted this restriction and allow now support both RAID 5 (single parity disk) and RAID 6 (dual parity disks) configurations. Also the cluster storage capacity cannot be resized after deployment.
  • vCenter Server dependency: that made difficult to have a virtual vCenter on the VSA.
  • Storage limits per host: max 6 TB with 3 TB disks or max 9TB with with 2 TB disks.
  • Scalability: is limited to a maximum of 3 nodes (and of course a minimum of 2).

With the new version, that has been renamed in VSA 5.1, most of those limits has been removed or changed. But scalability still remain the same!

Note that VSA 5.1 can run both on vSphere 5.0 and 5.1 and also supports the single sign-on (SSO) functionality found in vSphere 5.1.


Finally VSA has been included in each vSphere 5.1 bundle (but only one instance), except the Essential one. So you can have it at no extra cost!

Disks usage

VSA 5.1 now supports the online increasing of storage capacity of a VSA cluster. For existing customers (VSA 1.0) there are 3 possibilities:
  • Convert RAID 10 to RAID 5/6.
  • Add more disks, destroy the current RAID and recreate new RAID.
  • Add more disks and create new RAID, keeping the data

Any unused storage on the local VMFS datastores can now be reclaimed via a new ‘Increase Storage’ option in the UI.

Storage limits

VSA 5.1 maximum with 3 TB drives:

  • 8 disks of up to 3TB capacity in a RAID 6 configuration (no hot spare)
  • 18TB usable by the VMFS-5 file system per host
  • Across three hosts, a total business usable storage of 27TB

VSA 5.1 maximum with 2 TB drives:

  • 12 local disks of up to 2TB in a RAID 6 configuration (no hot spare)
  • 16 external disks of up to 2TB in a RAID 6 configuration (with hot spare)
  • VMware supports maximum VMFS-5 size of 24TB per host in VSA 5.1
  • Across three hosts, total business-usable storage of 36TB

vCenter Server dependency

Now vCenter Server can run directly on the VSA 5.1 cluster, where it can be installed on local storage (one part), then the VSA needs to be configured (on remaining local storage), then SvMotion can be used (if licensed) to move the vCenter VM to the VSA cluster. Additionally, the local storage (where vCenter lived before the move) can be used by leveraging the new Resize function, which is available through UI.

Remote Office/Branch Office (ROBO) Support

VSA 5.1 now enables multiple VSA clusters to be managed by a single remote vCenter Server instance. The vCenter Server instance can also reside on a different subnet from the VSA cluster (limit in VSA 1.0). Each VSA storage cluster is located in its own unique datacenter object in the vCenter Server inventory.

The two-node VSA storage configuration uses a special “VSA Cluster Service,” which typically runs on the vCenter Server instance. It performs like a cluster member and is used as a tiebreaker to ensure that there still would be a majority of members in the cluster if one ESXi host/VSA member were to fail. The new designed tiebreaker for two-node configurations still can run as a vCenter Service in VSA 5.1. However, in a two-node ROBO deployment, the vCenter Server instance managing VSA is now remote. This means that the VSA tiebreaker code must be locally located at the branch office and not on the central vCenter Server instance.

In VSA 5.1, the tiebreaker code can be installed at the branch office. The administrator provides details on the location of tiebreaker code during VSA deployment, and the VSA installer validates these settings. The tiebreaker is simply a set of Java Archive (JAR) files. The JAR is a way of distributing a Java program, along with all its libraries. VMware provides installers to run the JAR file on a user-supplied platform, either Windows or Linux. The administrator is responsible for configuring the platform, including installing the base operating system (OS). The installer then introduces and sets up the tiebreaker code. VMware provides installation documentation for all the platforms that support running the tiebreaker code.

Finally there are also specific functions to remote install and upgrade VSA.

More information