This entry is the result of weekly battles associated with the development of a method that will change the FQDN of the gateway-va, so that we can get to the Horizon Workspace from the Internet. Why is this action rises to the rank of the problem? According to the documentation , all virtual machines included in the Workspace must be configured with the correct DNS records (A / PTR). The gateway-va machine dont need to be configured at the start in the external FQDN, is administered during the initial configuration. Unfortunately, this is so (even in the latest version of the Horizon Workspace 1.8.1) that during the initial configuration of the whole this parameter is ignored and local DNS address is set as FQDN. This is due to the fact that the machine configurator-va must have full access to the gateway-va FQDN (for it is irrelevant whether it is local or Internet domain), otherwise you will not be able to properly configure the gateway-va. Unfortunately, change of the FQDN is not trivial (during the change required full access and a valid PTR record). Fortunately, as I have sometimes written, there are people on the Internet that make life easier. One of them is Andrea Casini, who developed a good method .
To avoid trouble, at the stage of the installation, it is good to prepare a fake DNS record (but this can also be done with an already running system). So in the local DNS server (in my case: pulab.local), create a false main zone (in my case: pulab.pl) addressing local, compatible with reverse domain zone pulab.local. As a result, the gateway-va gain Internet FQDN and will be available in 100% locally. If you perform NAT from web to the local address ,is enough to create a “fake” zone inverted, so that the PTR record existed and was responsible address of the NAT (this is a change to an existing installation, the new better is a false domain).
After achieving this success (and initial configuration of the total), proceed according to the second method. In the configurator-va add certificates in accordance with the domain name. In the next step we remove the fake DNS record (workspace.pulab.pl) and in its place introduce local record (ughog1.pulab.local) with a valid PTR (very important!). Then restart the gateway-va, during the restart change the server name to be compatible with the DNS record (no need to manually change using the YaST). After logging into the configurator-va we can see it (if you do not see it, you must restart the entire vApp):
That is a total success! This is because the FQDN is different from the name of the host (gateway-va), the Horizon Workspace assumes that it is behind the Load Balancer! If you plan to use more gateway-va, generation of next gateway-va machines is best to start at this time. At the end of a general note, Horizon Workspace is completely dependent on the proper DNS records. Lack of even one PTR crashes whole. The analysis of errors Horizon Workspace is best to start by checking whether the DNS is all OK. In the next post we will be balancing traffic between two gateway-va using the F5 BIG-IP 
Was this information is helpful? Tell me, please leave a comment!
