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.
This article was first published by Andre Leibovici (@andreleibovici) at myvirtualcloud.net.
9 comments
2 pings
Skip to comment form ↓
Jean-Marc Trappier
11/05/2012 at 6:42 am (UTC -7) Link to this comment
Hello Andre,
I fail to understand why you don’t use a single composer with a single vCenter, unless you have to manage thousands and thousands of desktops, thus you are using multiple pods, I don’t see any reason why you juste don’t use a single composer (standalone server, not in any domain) with a single vCenter (should be in domain but not required) managing several View organisations.
It is even what is used in multi-tenancy, View composer isn’t that heavily loaded to be honest…so i you need several vCenters, just build a tied composer and voilà…
Why would you do this at the end of the day ?
Andre Leibovici
11/05/2012 at 4:00 pm (UTC -7) Link to this comment
@Jean-Marc Trappier
You cannot have multiple VMware View pods usind the same View Composer service. Therefore you need a Composer per pod. Now, you could have one vCenter per Composer, but you would need to create independent clusters with dedicated hosts, not allowing you to gain sociability or density based on additional resources required to have independent cluster (N+1), as an example.
You can have multiple vCenters, but this will consume additional resources and increase management overhead.
Andre
Jean-Marc Trappier
11/06/2012 at 12:34 am (UTC -7) Link to this comment
Thank you for your reply.
We are using a multiple organisations solution with a single vCenter and a single composer without any problem. I admit multiple vCenters with a single composer could be a problem (database wise) but this is not what we are doing.
I am asking this because the fact we don’t have any issue for the while doesn’t mean we won’t have some later.
That being said, composer is so light that creating one per organisation isn’t a real issue.
P. Lopes
11/21/2012 at 3:23 pm (UTC -7) Link to this comment
Hi Andre,
could you clarify if the vCenter in the image2.png is out of any domain?
Thanks.
P.Lopes
Andre Leibovici
12/01/2012 at 9:41 am (UTC -7) Link to this comment
@P. Lopes
In my tests vCenter was part of a management specific domain. However, you could also utilize VMware vCenter Virtual Appliance without adding it into any domain. For Linked CLones each tenant has it’s own Stand Alone install that also does not need to be part of the tenant’s domain.
Andre
Gernot
03/20/2013 at 8:40 am (UTC -7) Link to this comment
Hi,
is it possible to have multiple composer with one vcenter and one connection server? the background would be to support multiple domains that are not trusted…
thx!
Andre Leibovici
03/20/2013 at 1:30 pm (UTC -7) Link to this comment
@Gernot, I do not recommend doing that. Despite not supported, you will face issues because View Composer does not assign specific ID for different vCenter Servers. So, a operation request could end up in the wrong vCenter Server.
Andre Leibovici
04/03/2013 at 11:07 am (UTC -7) Link to this comment
Keep in mind that since maximum operation limits (such as provisioning, view composer operations, power operations) are enforced on a per View environment basis, there is change to potentially exceed the number of concurrent operations possible with a 1 to 1 mapping between View environment and vCenter.
Take care of sizing the vCenter appropriately and if there are issues due to high level of concurrency, may be necessary to reduce the concurrency limits on the vCenter Settings tab for each View deployment.
Jean-Marc Trappier
04/04/2013 at 2:39 am (UTC -7) Link to this comment
Hello Andre,
Very true and this reminds me a question : do you know a way to “tune” every component to fit your needs, I mean composer, vCenter, etc. ?
Another question : do you know a way to “speed up” the composer / vcenter reaction ? I mean it can take sometimes several minutes when you ask for the solution to recompose a pool between the request and the operations themselves…
Last post of the year and New Theme… Happy New Year! » myvirtualcloud.net
12/27/2012 at 2:06 pm (UTC -7) Link to this comment
[...] Multiple View Composer Servers against single vCenter [...]
» VMwarEmployee Blogs Round-up – w/c 29nd Oct Mike Laverick…
02/01/2013 at 2:41 am (UTC -7) Link to this comment
[...] read cache). He has an interested article documenting non-supported configuration where multiple “View Composer” instances can be coupled to single vCenter Server (normally it is 1-2-1 relationship). It’s configuration that might be of interest where you [...]