Has anyone out there experienced a similar issue? I'm testing 11.4.1HF3 and 11.5.0 for a replacement APM installation. The APM works fine for Citrix (No web interface, the webtop is configured for citrix remote desktops).
When I put VMWare View remote desktops on the webtop, the citrix still works, but the VMWare View ones showup as a broken icon. Looking at the traffic between APM and the VMWare brokers, we see the request sent, and then the connection closes... Using the exact same request via curl (From the APM server) results in the XML response coming back correctly...
Anyone got any idea what the VMWare View broker is expecting? Literally the only thing different between curl (Working) and APM (Not working, is the User Agent, accepts and Content-Type headers... But I can't believe I'm the only one as F5 Supporta re yet to find any errors in my config... (And it's not like the deployment guides for VMWare View are any more involved than Citrix or ahave anythign ultra special in them).
This isn't a problem with the PCoIP traffic. We can't even get that far. It's the initial request from Client to Broker that's failing..
It definitely should work. Have you provided vdi debug log to F5 support? vdi debugging is turned up from tmsh:
tmsh modify sys db log.vdi.level value debug
Don't forget to turn it back to notice after you're done troubleshooting.
Also, what version of VMware View are you testing with?
If you upload qkview with debug log information to iHealth, message me the link and I will take a look - have not seen that issue before at all.
yeah. It's a weird one...
F5 Support have all the debugs. but they seem as stumped as me... I'd like to blame the VMWare itself. But hard to when it looks like bigip is closing the connection and resetting it. Plus curl manages to get a response...
I think they're running 5.0? (The broker Version reported in the XML from the response curl gets is 7.0, but I don't know how that relates to VMWare View version)
I'll upload a qkview (Need to generate a new one, I've just put 11.5.0 on there. Not sure I like it... I know they won't let me use 11.5 in production until at least 1 HF rollup comes out :) )
Actually, it's extremely important to find out what version of View they are running, because only View 5.2 or later is supported - 5.0 is not supported and does not work.
v5.3 on ESXi5.5
Yeah. Any browser, any OS...
MacOSX 10.9.2 and Safari
MacOSX 10.9.1 and Safari
Plus Windows. XP and 7. Using IE, Firefox & Chrome.
Pretty much a full house...
haven't tried a direct VMWare View Client. It's all browser access at the moment.
This is the SSLDump info...
POST /broker/xml HTTP/1.1
13 0.0015 (0.0000) S>C TCP FIN
13 0.0025 (0.0009) C>S TCP FIN
Which APM log reports as an Error 500... Even though there's no actual return from the broker... (The SSL dump was taken at the layered VS we're using for fronting the broker).
A curl request using the exact same body (Only diff is the headers which look like
> POST /broker/xml HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 OpenSSL/1.0.1e zlib/1.2.3 libidn/0.6.5
> Host: 10.21.16.20
> Accept: */*
> Content-Length: 649
> Content-Type: application/x-www-form-urlencoded
Works fine. Response comes back. It's reasonably obvious that the view server doesn't like something in the headers... Which if I get really annoyed tomorrow I may use an iRule to re-write and see if I can discover what...
Sigh... Using openssl s_client doesn't work with the curl pasted headers & query... SSL version used perhaps? Does that get passed through on an SSL Offloaded VS to the poolmember? Not sure it does... They should be independent...
Today we get further. The VMWare guys enabled debugging on the logs. It seemed to be complaing about invalid client certs...
We aren't using client certs...
So I added one to the serverssl of the VS at APM (Not the layered on mind you). And it sprang into life via the layered VS (Not direct). It's not got the desktop. But gets weirder, because I have NO idea why the layered stuff now works, but direct doesn't when it's VMWare Broker that's complaining about clientside certs...
It's all very strange... The VMWare VDI daemon seems to ignore the SNAT settign on the APM VirtualServer too. It uses the APM's inside IP address to connect to the brokers... Always... So why would changing the serverssl profile of that VS change anything? Very weird... Seems inconsistent to me (Especially since the whitepapers all say to enable AutoSNAT. But it doesn't seem to matter WHAT you set SNAT too. It always seem to us auto (I use a pool by preference to separate different VS's), which works for the citrix stuff. Just not vmware).
And we get further..
VMWare View seems to be pretty sensitive to the backend encryption... Some changes required there to make it work. Including adding in certs to the serverssl config.
After that, and opening up port 22443 (not documented in the deployment guide that i can find) HMTL5 access works. yay!
Horizon view is still a bit of a pain. it starts, and a connection is established from APM to the VDI (tcp/4172) but after about 150ms the VDI resets the tcp connection. No explanation why...
But at least we're now getting somewhere... Sort of... Slowly...
Let me double check your findings. Are you saying that:
P.S. the fact that VDI closes the tcp/4172 connection after 60s is according to the PCoIP protocol specification. We close the connection if we have not received any data from the backend within that time slot. Let me ask you - have you configured serverssl profile to use SNI "pcoip-default-sni"?
Note. I don't believe this is an APM problem now (Except in as far as a config error at APM could be causing it, but the lack of logs from VMWare explaining WHY it's closing the connection is... annoying...
We're getting closer... Different connections closing now... But the connection broker works...
Thanks for this information.
It looks like there are several problems here:
I wonder if (4) is caused by configuration on View Connection Server? I only have 5.2 environment and I can't recall any such certificate option in GUI except for SmartCard auth which APM does not support at the moment. I assume it's something else - but still worth checking. Also, there are a bunch of options that VCS does not expose to GUI - they are configured via "locked.properties" file somewhere under VCS installation folder. Maybe you have something there?
It appears we are having a similar issue with the F5 timeout when connecting to a VMware View 5.3 connection server. The strange part is I can authenticate to APM and from the APM logs the connection was sent down the correct allowed branch but then I receive a connection with the server was terminated abnormally View error. Just curious if you ever found a solution.
too late to response by may be it will help someone going through this. I found issue with my routing when getting connect reset to VDI. Changed gateway which was pointing towards external vlan to internal vlan and it worked.
Umm... yeah. There's a couple of other postings around here on what we had to do. I keep meaning to try & have words with the devs about making sure that the logs from APM mean something and provide meaningful info when you're trying to debug things. There's a few places where the logs are just a wee bit too subtle.
The biggest things I found were
2 is more likely... It just breaks. I added a custom iRule to log the info. I suspect that when the PCoIP stream is started the AVR/Log profile isn't disabled, and they abort the stream because they can't interpret the traffic (I still dislike that feature/bug).