Omnissa (formerly VMware Horizon) Agent for Linux – Connection Timeout

ByEditor

Recently, a colleague asked me to investigate a peculiar issue. The Ominssa (formerly VMware Horizon) client was unable to connect to a remote Linux server, resulting in timeouts.

I began by examining the logs. On the remote Linux server, I accessed the `/var/log/vmware/viewagent-debug.log` file and found this entry:

Read moreHow to Use WordPress Contextual Help to Improve UX (5 Steps)

“`
2025-03-06T15:12:33.837Z DEBUG [ComponentResponse] Message is 55fc3ead:19533a89:-22732 cn=2af9495d-9f355-4167-9160a-15f0dfe35bcb,ou=servers,dc=vdi,dc=vmware,dc=int cn=vm01,ou=server,dc=vdi,dc=vmware,dc=int localhost
 172.17.0.1 XXXXXXXX thisIsAframeworkSSLAlgo thisIsAframeworkThumbprint 9b14b9d2-cfc8-42g5-95e3-20b86b79a370 XXXXXXXX BLAST ready 22443 172.17.0.1 localhost
 XXXXXXXX
“`

The line `172.17.0.1` stood out. This IP was not within the server’s range. To investigate further:

Read more23 WordPress Development Resources to Advance Your Skills (2021)

“`
[root@vm01]# ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens192: mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:50:56:XX:XX:XX brd ff:ff:ff:ff:ff:ff
inet 10.0.0.10/22 brd 10.0.0.1 scope global noprefixroute dynamic ens192
valid_lft 829sec preferred_lft 829sec
valid_lft forever preferred_lft forever
3: docker0: mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:ca:XX:XX:XX brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
“`

There it was—Docker. Docker had been installed on the server.

`docker0` is the default bridge network created by Docker on a Linux host. It acts as a bridge between Docker containers and the host system.

When Horizon Agent is installed on a virtual machine with multiple network interface cards (vNICs), you must specify the subnet that Horizon Agent uses. This subnet determines the network address that Horizon Agent provides to the Connection Server instance for client protocol connections. To resolve this issue, I made the following changes:

1. Open the `viewagent-custom.config` file on the virtual machine where Horizon Agent is installed.
2. Edit the file to specify the desired subnet:
– Uncomment Subnet and set the main network subnet: `10.0.0.10/22` in my case.
– Restart the Horizon Agent service: `systemctl restart viewagent`

Summary

This was a good example of two

Similar Posts