VMware Horizon Community
mthiha
Contributor
Contributor
Jump to solution

vcenter and view composer in different domain

Multiple View Composer Servers against single vCenter » myvirtualcloud.net

I follow this schema for multi-tenancy setup at our private cloud discussed in above link.

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?

Max

Reply
0 Kudos
1 Solution

Accepted Solutions
JihemmeT
Enthusiast
Enthusiast
Jump to solution

Hello,

Sorry if I am unclear, english isn't my mother tongue.

vCenter doesn't have to be in a domain. Actually, I even use the VCSA for ages (the new version is just what you need since the limitations are gone) which doesn't have to be part of a domain.

Composer doesn't have to be in a domain neither. You can install local MSDB (SQL Express is just fine even for huge pods but since huge pods surely already have a database server somewhere...) with SQL account for authentication, no need to be in a domain here.

Security Server can't be in a domain.

Connection Server MUST be in a domain. It is mandatory, you can't even install if you are not.

You'll also need a domain account for the composer to be able to add desktops to domain.

This is what is needed, now you have to put it in the right place in View configuration. When you declare your vCenter for instance, you only have to set the accounts needed to communicate with vCenter with enough rights (and rights have to be applied at ROOT level, not DATACENTER level), with composer with enough rights as well (typically, you'll use Composer server local administrator account). To configure correctly composer, you also need to declare the domain you'll compose into, this is where things can go wrong since composer must be able to resolve this domain, so my advice is to add domain DNS server (most of the time, DC) as a local DNS for domain resolution. Then, you'll need the domain account to be able to compose this domain;

View solution in original post

Reply
0 Kudos
8 Replies
mthiha
Contributor
Contributor
Jump to solution

To add on,

one main goal is Not to use trust between domains because vcenter is in master domain.

Reply
0 Kudos
Linjo
Leadership
Leadership
Jump to solution

This is not supported since your vCenter can be overloaded with provisioing-operations but should work fine.

The View Composer account needs to have these rights on the vCenter server:

VMware View 5.2 Documentation Library

Best regards, Linjo Please follow me on twitter: @viewgeek If you find this information useful, please award points for "correct" or "helpful".
Reply
0 Kudos
mthiha
Contributor
Contributor
Jump to solution

Understood. Composer needs rights.

How can I achieve this since vcenter and composer are in different domain?

Reply
0 Kudos
JihemmeT
Enthusiast
Enthusiast
Jump to solution

Hello,

Actually, you don't even NEED to put composer and / or vCenter in domains. You can use local accounts and everything is working just fine.

The only real domain need is at the broker level (connection server).

Multitenancy can be achieved by separating View pods for each client but vCenter and composer don't have to be in a domain to work. Of course, every connection server must be able to communicate with vCenter.

Reply
0 Kudos
mthiha
Contributor
Contributor
Jump to solution

Hi JihemmeT,

I tried view server configuration using local administrator of vcenter and composer.

However, i am still getting error of “…/sdd” was not found on datastore.

I still think its related to composer rights.any idea?

Reply
0 Kudos
JihemmeT
Enthusiast
Enthusiast
Jump to solution

Hello,

Sorry if I am unclear, english isn't my mother tongue.

vCenter doesn't have to be in a domain. Actually, I even use the VCSA for ages (the new version is just what you need since the limitations are gone) which doesn't have to be part of a domain.

Composer doesn't have to be in a domain neither. You can install local MSDB (SQL Express is just fine even for huge pods but since huge pods surely already have a database server somewhere...) with SQL account for authentication, no need to be in a domain here.

Security Server can't be in a domain.

Connection Server MUST be in a domain. It is mandatory, you can't even install if you are not.

You'll also need a domain account for the composer to be able to add desktops to domain.

This is what is needed, now you have to put it in the right place in View configuration. When you declare your vCenter for instance, you only have to set the accounts needed to communicate with vCenter with enough rights (and rights have to be applied at ROOT level, not DATACENTER level), with composer with enough rights as well (typically, you'll use Composer server local administrator account). To configure correctly composer, you also need to declare the domain you'll compose into, this is where things can go wrong since composer must be able to resolve this domain, so my advice is to add domain DNS server (most of the time, DC) as a local DNS for domain resolution. Then, you'll need the domain account to be able to compose this domain;

Reply
0 Kudos
mthiha
Contributor
Contributor
Jump to solution

Thanks again.

In fact, I did exactly what u mentioned.

When I defined vcenter and composer settings in view connection server, I used local admin vcenter , local admin composer and domain admin for desktop pools.

Sadly,I am still getting /ssd not found error.

Reply
0 Kudos
mthiha
Contributor
Contributor
Jump to solution

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.

Thank you guys!