Multiple View Composer Servers against single vCenter

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


2 pings

Skip to comment form

    • Jean-Marc Trappier on 11/05/2012 at 6:42 am

    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 ?

  1. @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.


    • Jean-Marc Trappier on 11/06/2012 at 12:34 am

    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 on 11/21/2012 at 3:23 pm

    Hi Andre,
    could you clarify if the vCenter in the image2.png is out of any domain?


  2. @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.


    • Gernot on 03/20/2013 at 8:40 am

    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…

  3. @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.

  4. 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 on 04/04/2013 at 2:39 am

    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…

    • max on 11/10/2013 at 11:22 pm

    Hi Andre,
    I follow this schema for multi-tenancy setup at our private cloud.

    Vcenter and ESXi are in domain A.

    Composer,View Manager and linked clones desktops are in Domain B. for tenant 1.
    Composer,View Manager and linked clones desktops are in Domain C. for tenant 2. etc.

    when i did that and composer deployed machines, i ended up with “…/sdd” was not found on datastore.

    The question is how the composers from different domains access datastore and deploy desktops.
    Is there any permission needed for composers?
    How to achieve this setup?

    • Danny on 01/17/2014 at 12:42 pm

    Hi Max et al,
    did you ever get an answer?
    I am running into the same issue and I have tried out multiple VM versions… no success yet.

    • Danny on 01/17/2014 at 12:47 pm

    For any one who is running into this issue (link clones just not appearing and watching them delete in front of your eyes… My friend Google pointed me to a posted solution which I will quote:

    “I managed to solve the “…/sdd error” on datastore . The problem is composer doesnt know the fqdn of esxi hosts during the linked clone creation.
    I added esxi fqdn manually in etc hosts inside composer and got pass the error.”


    Hence you need to help the composer and co with the name resolution of the ESXi hosts… that should sort out that… Now if you are using the vShield Edge you’ll need to remember to set a few NAT rules too 😉

    Take care and happy DaaS’ing,


    • Greg on 03/07/2014 at 7:36 am

    Give the above scenario of using a single vCenter to manage multiple isolated View Connection servers, where does the user account live that needs to be configured in View for Composer to work? ie: Which AD if there is no trust between any of the environments? Can a local account be used on the VC?

  5. Greg : vCenter and Composer don’t even have to be part of Active Directory domain, you set the account requirement for every domain to handle in the configuration of servers in Horizon View management interface, in vCenter -> Composer -> Domains (not EXACTLY those names but it is the general idea).

    In our environment, neither vCenter or Composer are part of domains.

    • Greg on 03/07/2014 at 10:05 am

    Thanks, but since none of the domains are aware of each other (no trusts), what account is being used to authenticate to VC for View? If VC is a workgroup machine, the View servers needs an account that VC will know.

  6. Ok I see your question, so here is for example what I did :

    vCenter is an Appliance, so it is a linux based account I called “admin-view” for this purpose with required rights on vSphere. If you use Windows based vCenter, local admin fits your needs.

    Composer use a local account, not sure what name it is but just local account (I granted local admin rights but not sure they are required).

    Then, for every single domain, use an account with enough rights to add desktops in the right OU (and you should create an OU per pool).

    Everything is independant, only your view organisation needs to know what accounts to use, even without any trust Relationship.

  7. My last reply is misleading, let me avoid confusion :

    1) Composer uses a local account in my set up, this account was created by me and every view organization have this parameter in its configuration

    2) Every View configuration is responsible for their pools. Horizon View isn’t multitiering enabled, so you have to create an organisation per Active Directory domain if there is no trust Relationship between them. Only vCenter and Composer can be shared, NOT View Connection Servers / Security Servers / Transfert Servers. Every Organization is isolated.

    • Anton Paloka on 03/09/2016 at 1:52 pm

    I’m curious if you know of any update to this type of build being supported by VMware in recent versions?

  8. Anton, I don’t think this scenario is supported by VMware. Since I left Horizon View architecture team a while ago I would recommend you speaking directly with VMware.


  1. […] Multiple View Composer Servers against single vCenter […]

  2. […] 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 […]

Leave a Reply