Product Announcements

vSphere Storage Appliance – Can I run vCenter on a VSA cluster member?

Most of you will know by now that VMware released the vSphere Storage Appliance (VSA) 1.0 with vSphere 5.0. The VSA aggregates local storage from 2 or 3 ESXi 5.0 hosts, and presents shared storage back to these ESXi 5.0 hosts in the form of NFS datastores. I've done numerous presentations on the VSA now, both internally and externally (including blog posts). However, one question comes up time & time again, and that is "Can I run vCenter Server on an ESXi host that is a VSA cluster member?" I'm going to try to address that here.

VSA Components


Chicken & Egg

In order to deploy VSA, you require 2 or 3 vanilla ESXi 5.0 hosts. These hosts are freshly installed with a default 5.0 configuration & cannot have any running VMs. So basically, you cannot have vCenter in a VM on one of the ESXi hosts to do the install. vCenter (either physical or virtual) must reside on a host that is not being used as part of the VSA cluster framework in order to install the VSA cluster.

Well, you might ask "What if I build vCenter on another host outside of the VSA cluster just for the install? Will VMware support migrating vCenter (in a VM) to one of the VSA ESXi hosts and one of shared NFS datastores which make up the VSA cluster?"

Let's answer that on a per configuration basis.

  • 2 node VSA configuration

With a 2 node configuration, the answer is no. You cannot run vCenter in a VM on an NFS datastore in a 2 node VSA configuration. The reason is because, in a 2 node configuration, vCenter runs a special VSA service which behaves just like an additional cluster member. There are now 3 members in the cluster and if one ESXi host fails, the other host is still able to communicate with the special VSA service running on vCenter. This means that the remaining node continues to run as there are still two members in the cluster. Now, if vCenter was running in a VM, and it resided on the ESXi 5.0 host that fails, then we have lost two members stright away. Because we have lost a majority of members, this brings down the whole cluster framework. This is not good, and for this additional reason, VMware only supports having vCenter running outside of the VSA cluster.

  • 3 node VSA configuration

This is a bit more difficult to explain. Firstly, because there are 3 nodes, there is no need for the special VSA service on the vCenter server, like we saw in the 2 node configuration. A VSA cluster deployment also configures core vSphere features such as vMotion & vSphere HA. So isn't this ideal for vCenter running in a VM on a shared NFS datastore from the VSA? You would think so, because if one of the ESXi hosts goes down, and vCenter was running in a VM on that host, then vSphere HA would restart vCenter on another host. And because all the NFS datastores are mirrored, even if vCenter was on a datastore presented from the failed host, its mirrored copy would be used from a different host, allowing vCenter in a VM to continue to run. It all sounds good, doesn't it?

Unfortunately, there is one corner case scenario which prevents us from supporting vCenter in a VM running on a VSA datastore. The scenario is if we lost the whole VSA cluster framework for whatever reason. If we lose the cluster framework, then we lose the ability to present any shared storage from the VSA nodes. This means that no VMs, including the vCenter server, can run.

Now you might say – "Ok, understood! Just get in there and troubleshoot the issue, fix it, and bring my VSA cluster, shared storage and VMs back up". And this is the crux of the matter. The VSA cluster is installed and managed via a VSA plugin in vCenter server. And without a running vCenter server, our window into troubleshooting what is happening on the cluster is unavailable. Without vCenter, we have no way of trying to figure out the root cause a complete cluster outage scenario. We wouldn't even be able to gather logs from the VSA!

Hang on!! I only have 3 ESXi servers and no other equipment! What should I do?

Well, there is one possible configuration that you could consider in this case, if you really have no additional equipment available on-site to host the vCenter server.

  1. Deploy 3 x ESXi 5.0 servers
  2. Deploy vCenter 5.0 in a VM on the local storage of one of the ESXi 5.0 servers. This ESXi will not be a member of the VSA cluster
  3. Create a datacenter in vCenter inventory  & put all three ESXi hosts in the same datacenter
  4. Install VSA Manager & create a 2 node VSA cluster, omitting the ESXi host that runs vCenter in a VM
  5. The two NFS datastores from the two VSA member nodes will be automatically presented to all ESXi hosts which are in the same datacenter, including the non-VSA ESXi host, i.e. all three ESXi nodes will see the two NFS datastores.
  6. All 3 nodes can participate in vMotion & vSphere HA, but the non-VSA ESXi will have to have these features manually configured.

This is one possible solution that you might be able to use in situations where there is no additional equipment for installing the vCenter server. Please note that this was never tested by myself, but I can't see why it wouldn't work. Please leave a comment if you see any issues with this approach.


I hope this clarifies our stance on this. While the complete cluster framework failure scenario I described above is very corner case, it is a situation that might arise. Our objective with the VSA is to make it as robust as possible, but we also want to be able to troubleshoot any issues which might occur during its deployment, and to do that we need vCenter available. The only way to guarantee that vCenter remains available is to deploy it outside of the VSA. That way, even in the case where the whole cluster is down, we still have the opportunity to fix the issue using the VSA plugin in vCenter. The bottom line is that when deploying a VSA, the vCenter server must not be run on an ESXi 5.0 host that is participating in the cluster. It must be run outside of the cluster framework.

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