Vmware View 5.3 & LTM/APM

Can you please share which version of the BIG-IP are you using and which client platform/version? Have you had a chance to try different platform/clients(i.e. desktop and mobile?) If this erratic behavior continues, I suggest you turn up VDI debugging by running the following command from the BIG-IP CLI:

tmsh modify sys db log.vdi.level value debug

Then replicate the issue, create qkview, upload it to https://ihealth.f5.com, and open a case with F5 support.

Try applying the latest hotfix to your BIGIP and see if it resolves this issue. I would also suggest opening a support ticket, probably going to need to trace packets and review logs to debug this issue.

tail -f /var/log/apm will show you APM logs, make sure your APM logging level is set to debug.

tcpdump -i 0.0 port 4172 is one way to see if pcoip connections are occurring from the BIG-IP to user assigned virtual desktop after a resource has been selected.

Thanks guys, will give it a try. And yes I ompletely forgot to share version info :). I am running 11.4.1 HF3.

I've seen the same problem... It looks from my tcpdumps that the VDI always resets the connection. But we haven't managed to find an error yet to say why...

H

Hi guys, I got an answer from F5 support. There is a known issue with the View client 2.3.x. This issue can be overcome by adding an iRule to the View proxy https virtual server. This perfectly did the trick for me, everything is running fine now.

Content of the iRule :

when HTTP_REQUEST { if { [HTTP::path] == "/broker/xml" && [HTTP::header Expect] == "100-continue" } { SSL::respond "HTTP/1.0 100 Continue\r\n\r\n" } }

Thanks, Pascal.

Nope... No change for me. Must be a different issue...

H

Fixed it for me, thanks for sharing!

I found my issues... Just in case anyone else has similar problems.

1. if you enable request or response logging on the :443 VS that handles the APM policy, then VMWare View will not work... There's no errors... there's no diags avail. It'll just fail. With Blaast you'll get a grey screen and a disconnection notice. With Horizon View Client it'll just tell you various lies.

    

2. The second issue (Hanging of Horizon View) was more problematic. The logs would get to a response from query 9 (No idea what that was BTW), but then hang. Requiring a forced quit (This is on a Mac client). Turns out on my laptop (Mac Pro Retina late 2013 with discrete GPU), unless the GPU is explicitly enabled (I used gfxCardStatus) then Horizon view will just hang. Enabling the CPU ALWAYS (Auto won't cut the mustard) means it now runs...

    

I think I'll raise some bug reports... 1 for F5, 1 for VMWare...

H

Oh... Also the various docs seem to be slightly contradictory... I know it's a new thing, and has obviously changed a bit... But even on the various videos I found, it seems to contradict itself as to what VS's are required...

For Blaast (HTML5) you need a :443 VS only. It'll act as an HTML gateway to your desktop. That's kinda slow. But seems to allow me hi-res.

For Horizon View Client (PCoIP) you'll need a VS for udp/4172 on the same IP as your main :443 VS. I found some references talking about tcp/4172 (Not used) and one implying none (Wonder if that was an early one, or simply assuming you were going to use Blaast).

And if you're doing NAT externally to your bigip, you'll need to remember to add the special sauce. A variable setting in the visual policy that sets a special variable to tell the APM to re-write the proxy address as your external IP. I'm hoping that'll work as a FQDN as well to enable GTM to be used in front. Otherwise it's back to the drawing board again (Which will probably involve firewall changes so I don't have to NAT the BigIP VS address for this VS).

H

We now have a solution that covers the View 2.3+ client issue here:

http://support.f5.com/kb/en-us/solutions/public/15000/400/sol15409.html

Hamish: Could you clarify (give the configuration parameters and/or names of the GUI labels where you configured it) what you mean exactly by "request or response logging"?