VMware Horizon Community
six4rm
Enthusiast
Enthusiast
Jump to solution

Deploying Linked Clones to Multiple Clusters

Hi,

Our newly deployed Horizon View 7.0.3 environment consists of two compute clusters within the same vCenter Server, one consisting of 12 x HPE BL460 Gen8 hosts and the other of 6 x HPE BL460 Gen9 hosts. I'm using a single template VM to deploy from, which has been powered on upon both types of host to pick up any hardware specific drivers etc.

The problem I'm having is that if the template resides in Cluster A then desktops fail to deploy to Cluster B, and vice versa.

Is this the correct behaviour? Surely I don't need to maintain a template VM per Cluster?

Please feel free to ask any further questions around my setup

Thanks in advance.

1 Solution

Accepted Solutions
six4rm
Enthusiast
Enthusiast
Jump to solution

I managed to get to the bottom of the issue, I spotted it as I was walking the VMware Support Technician through my environment.

Rather embarrassing, in my rush to bring the second cluster of hosts into production I didn't configure NTP. The hosts had a date back in 2013 as a result and the VMs were picking up this wrong date and time value when provisioned. It makes sense why having the template snapshot taken when sat in Cluster 2 (with the wrong time) failed to deploy to Cluster 1, and likewise the other way around.

Anyway, I've certainly learned a valuable lesson and felt mighty embarrassed at the same time!

View solution in original post

5 Replies
TechMassey
Hot Shot
Hot Shot
Jump to solution

Are you by chance choosing to store the replica in a separate datastore? If so, is that a datastore unique to each cluster and not accessible by the other? I would suggest changing the pool config to not place the replica in a separate datastore. If you do this, View will automatically create additional replicas in datastores where needed to give each cluster access.


Please help out! If you find this post helpful and/or the correct answer. Mark it! It helps recgonize contributions to the VMTN community and well me too 🙂
six4rm
Enthusiast
Enthusiast
Jump to solution

Hi WarrenM01

Thanks for the reply.

Good thinking, but the pool is configured to use the same datastore for the replica and desktops, not separate datastores. I'm using NFS datastores and all hosts in both clusters have access to these.

It seems that the desktops provision ok if the template VM resides in the cluster where I'm deploying the desktops to. As soon as I move the template to the other cluster, or if I attempt to deploy desktops to the other cluster they fail. The desktops are created but they don't have a vNIC and as a result can't communicate with the Connection Servers to provision properly.

I've got an SR open with VMware and am hopefully having a Webex today to investigate further.

I'll keep you posted on the findings.

Reply
0 Kudos
TechMassey
Hot Shot
Hot Shot
Jump to solution

Thanks for the reply and detail. This is intriguing, I'm curious. Just to verify, you mention the vNIC is missing but do you mean the port group is blank in the linked clone?


Please help out! If you find this post helpful and/or the correct answer. Mark it! It helps recgonize contributions to the VMTN community and well me too 🙂
Reply
0 Kudos
six4rm
Enthusiast
Enthusiast
Jump to solution

I managed to get to the bottom of the issue, I spotted it as I was walking the VMware Support Technician through my environment.

Rather embarrassing, in my rush to bring the second cluster of hosts into production I didn't configure NTP. The hosts had a date back in 2013 as a result and the VMs were picking up this wrong date and time value when provisioned. It makes sense why having the template snapshot taken when sat in Cluster 2 (with the wrong time) failed to deploy to Cluster 1, and likewise the other way around.

Anyway, I've certainly learned a valuable lesson and felt mighty embarrassed at the same time!

TechMassey
Hot Shot
Hot Shot
Jump to solution

Isn't it fun when the symptoms lead you FAR away from the actual cause? Then you loop back in the end and find out it was just a simple setting not turned on, fun times that every admin goes through at least once a year! Good to hear you found it, better for it to be a simple solution in the end than to have to keep pounding away at the issue.


Please help out! If you find this post helpful and/or the correct answer. Mark it! It helps recgonize contributions to the VMTN community and well me too 🙂
Reply
0 Kudos