This is my first post here on Thwack, and I'm a brand new user. Still learning the ropes.
This company uses 2016 Server for RDS. For some time many thin client users have had extended login times (>5m). Once logged in things speed up to normal. SolarWinds SAM, ApplicationConnections reports >80ms & >75% packet loss between the RD Session host VMs & the AD VMs. Each of these VMs use vmxnet3 adapters, w/ 10G connecting the esxi hosts. I am searching for a solution to the extreme connection issue, and perhaps a remedy to the client's RDS issue. Ideas anyone?
Vshpere 6.7, esxi-hosts 6.5
Welcome to THWACK, we're always happy to see new users post here.
SAM application connections are checking the connections quality via NPing, it will identify if there are quality issues. To help troubleshoot further, do you have NPM installed? One item you could try is setting up a Netpath NetPath requirements for NPM
Thank you for the reply. I will set some of those up immediately. Although I'm wondering how much I'll see there given they are all on the same subnet.
1 of 1 people found this helpful
If you ping the domain controllers after the login completes, is there any more packet loss? Or is it just a problem during login times?
I've seen some strange/bad performance on ESXi 6.5 hosts, where the initial login is painful, similar to what you're describing. Once things are fully loaded, everything is OK. I had an open ticket with VMware and tried a bunch of things, and was looking at everything from network to storage. In the end, a simple reboot of each ESXi host solved the problem. It's almost like the host VMs were not able to grab available memory. If the VM had 8GB of RAM, it was only using a fraction of that, until things finally got loaded up.
Anyway, if your VMware environment is N+1, you can put each host in maintenance mode, one at time, and reboot them. It solved our performance issues with the underlying VMs, and now we reboot our VMware hosts once every 30 days. In addition, we also see some pretty dramatic improvements in SQL maintenance plans after a fresh reboot of the ESXi hosts.