VMware View administrators and architects commonly deploy one or more vCenter Server for a single VMware View deployment. For each vCenter Server in a VMware View pod, one instance of VMware View Composer may be optionally installed in the vCenter server itself, or since VMware View release 5.1 in a stand-alone server.

 

The VMware View Architecture Planning Guide is clear about this architecture model:

You can install this software service (View Composer) on a vCenter Server instance that manages virtual machines or on a separate server. … Although with View 5.1, you can install View Composer on its own server host, a View Composer service can operate with only one vCenter Server instance. Similarly, a vCenter Server instance can be associated with only one View Composer service.

 

 

The diagram above depicts the VMware View architecture when View Composer and vCenter are residing on the same host server or VM. The diagram below depicts the VMware View architecture for a View Composer residing in a stand-alone host server or VM.

 

 

 

Despite not officially supported by VMware it is possible to create yet another architecture where multiple VMware View Composer from different VMware View deployments or domains utilize the same VMware vCenter service. The diagram below depict what this configuration look like.

 

Please note that this deployment type is not supported by VMware. I recommend testing in a development environment. If you decide to test or implement you are doing it on your own risk.

 

 

This architecture allow a single VMware vCenter server to be used for multiple VMware View environments. This deployment type can be specially useful for enterprises with multiple Active Directory environments/instances where there are no 2-way trusts between domains and users still must be authenticated in each domain.

Another benefit of this architecture is the reduced footprint and simplicity of having a single VMware vCenter server for all enterprise virtual desktops.

According to the VMware View Architecture Planning Guide a VMware vCenter Server will support up to 10,000 virtual desktops with dedicated View Composers. Please note that this new unsupported architecture still maintains a stand-alone View Composer for each VMware View deployment or pod.

Therefore, the total number of virtual desktops for the single VMware vCenter server will still be 10,000 virtual desktops. You may see this as a drawback, but in the case of an enterprise or service provider with up to 1,000 desktops per department or tenant this deployment type would require only 1 vCenter server instead of 10.

Another benefit of this solution is the ability to create a single vSphere Cluster with up to 32 hosts when using NFS and sharing the entire server farm with all virtual desktops from all active directories, departments or tenants. The common deployment would require multiple clusters, increasing complexity and eventually turning into cost. On this same note, it’s safe to say that increasing the number of hosts available in a vSphere cluster helps to reduce server costs for redundant N+1 infrastructure.

The one thing I must highlight is that there is a configuration topology that will not only not work, but will make both VMware vCenter and View Composer databases inconsistent. You should not try to utilize a single View Composer service to support multiple VMware View deployments. This scenario is demonstrated in the figure below.

 

 

In summary, the proposed architecture allow organizations to share server infrastructure across multiple VMware View deployments increasing consolidation ratio and reducing footprint required by multiple VMware vCenter servers. Furthermore, the architecture allow enterprises to create Active-Directory tenant solutions while still be sharing the underlying hardware infrastructure, not possible with the currently supported VMware View deployment model.

Just to clarify, I am not here selling the idea that this solution is a full multi-tenant solution since it would require a number of different hardware and software abstractions. If you are interested in true multi-tenant solution I recommend reading the article and watching the video at “Chatting Desktop-as-a-Service with Scott Davis, VMware EUC CTO”.

 

Please note that this deployment type is not supported by VMware. I recommend testing in a development environment. If you decide to test or implement you are doing it on your own risk.