VMware Horizon View Cloud Pod - unwanted routing? -

VMware Horizon View Cloud Pod – unwanted routing?

With VMware Horizon View 6 came the Cloud Pod, multi-datacenter deployments of VDI became possible for View environments. Single management of entitlements across multiple datacenters desktop pools. This blog will show a strangeness that is built-in and got me a nervous feeling.

Setup

To get things in perspective a little word on the setup.

we have two Pod’s, POD-A and POD-B, both Pod’s running desktops and both are eternally accessible through security servers. The Pod’s are load balanced with F5 but that’s irrelevant for the rest of the blog. Version of VMware Horizon View running is 6.1.

The F5, as that’s were of course your attention was at, is not equipped with an APM module, the F5 is only used for load balancing. The costs in this project to get an F5 solution in was too high. So it’s only basic load balancing, we will look at configuring the F5’s that are there already and see if we can use some cookie/username persistence. For this blog, think as if there was a unknown load balancer there with no enterprise features something like DNSRR.

VMware Horizon View working

First let’s dive into the working of VMware Horizon View without a Cloud Pod.

The client connects to a broker
The user is authenticated with it’s domain account
The VMware horizon client will show all desktops the user is entitled to.
When the user starts a desktop the connection is setup directly with the desktop or through a tunnel. Internal connections are mostly directly, external ones are always through a tunnel.

External connections are possible when adding a security server, this server is connected to a internal connection server and together they provide the tunnel to the desktop. The client only connects to the security server and will be connected there for as long as the session takes… keep that in mind, that’s the key of this blog article.

So if we have POD-A and POD-B users connecting to POD-A for an external connection will see the following traffic flow;

Client – [POD-A: Security server – Connection server- Desktop]

Cloud Pod working

After you’ve setup a Cloud Pod the traffic flow will change, the two Pod’s are connected and know of each other existence. So a user connecting to a Cloud Pod environment in POD-A will be going through the following components.

Client – [POD-A: Security server – Connection server- Desktop]

Now I hear you say, that’s the same flow. That’s correct for new users connecting there is no difference. the only difference is that they now see only one desktop icon and the local desktop pool icons are gone.

The global entitlement (the one icon they see) is setup that it has the two local desktop pools configured, check my other blogs to see how to set this up.

When a client connects to a global entitlement VMware checks if the user has a home site and if they don’t will forward you to a desktop in that Pod. If they have a home site they will be forwarded to a desktop in the other Pod. So a user with POD-A as it’s home site will always be forwarded to a desktop in POD-A.

That last line is important, if a user has a home site he/she will be forwarded to a desktop in POD-A even when he is connected to a security server in POD-B. This will also happen when they reconnect and end up in the POD-B requesting a desktop running in the POD-A.

VMware has no possibility to redirect the user to the security server in POD-A and will be serving this user from POD-B.

The traffic flow in this case is:

Client – [POD-B: Security Server – Connection server] [DC – A -> DC – B][POD-A: Desktop]

What happens is that all PCoIP traffic is travelling between data centers, the client will keep on talking to the security server in POD-B and from there it will travel to the desktop in POD-A.

Traffic between two data centers is not the best option I think, there is no way of controlling the amount of users accessing a desktop through the wrong data center. All the user with their session could seriously fill you bandwidth with unwanted traffic.

Traffic from the client (outside) to the Pod where the desktop is living directly is the way it should be. After the user is connected to a security server in the wrong Pod and VMware detects that the desktop is in the other Pod, a migration to the other security server should take place.

Ok, so the F5 is also there redirecting users to one of the Pod’s, is it a factor here? No it’s not for either way users are ending up on one of the security servers and are stuck there. The design feels a bit like a dice game, perhaps you’re lucky ending up in your data center with your desktop 🙂

I see a good topic for VMworld coming up.