I'm pretty sure its not possible, the only thing you can do is a home site to direct users to a pod if they connect to another one. Are you having problems with local clients going to the wrong pod?
That's what I figured considering I couldn't find anything after digging around the internet. I'm not having any problems with users getting the wrong pool vm's I am just looking to split the loads between sites and I thought this would be an awesome way to go about it.
I'm by no way an expert in all load balancing topics, but I'm pretty sure if your using a f5 gtm for loadbalancing between the sites, wouldn't the least connections method work. I know enough to have our cloud pod working, we just do a production and dr pod, which we use global availablity. I'm wondering if this was set the gtm would split the user requests between the pods. I assume netscaler and other methods would probably have something similar.
I just finished a project where we used F5 GTM's and F5 LTM's. I also am not an expert on LB this topic but from what I learnt...
The GTM's was nothing more that DNS RR, no real intelligence about load/sessions etc. The LTM's are making the smart decision's around least connected etc.
As a user logs in, GTM check down stream and passes the request to the LTM who then makes the decision of what UAG/Connection Server to use etc etc.
As sjesse stated, home sites are the way to sick people to locations or use weight the load balancer to the preferred site. Then you are running a active/passive what's not ideal for you I think.
I also just finished a project with F5s, GTM, LTMs, Cisco ISE and Cloud Pod. Likewise, I am not an F5 expert.
However, the F5 specialists were able to configure directing load balancers to the specific site based on a VLAN (and therefore IP) of the thin client. So it is possible.
What was NOT possible, is to have the F5 direct to a specific site based on AD username and/or specific domain membership derived from Horizon View protocol stream. Apparently, this functionality was removed from F5 code in the last few code versions (we are using 14.1.0 Build 0.0.116).
As a result, what we ended up doing:
1. Thin Client logs into AD.
2. Cisco ISE puts Thin Client into a specific VLAN based on AD login.
3. Horizon View client initiates the connection to a unified namespace.
4. F5 directs connection to the correct site's Connection Servers based on the specific VLAN.
5. Cloud Pod proxies the connection to the correct site's virtual desktop (redundant failsafe, as F5 was not wrong in the first place).
This was quite complex, but educational.