Are you the publisher? Claim or contact us about this channel


Embed this content in your HTML

Search

Report adult content:

click to rate:

Account: (login)

More Channels


Channel Catalog


Channel Description:

Most recent forum messages

older | 1 | .... | 874 | 875 | (Page 876) | 877 | 878 | .... | 904 | newer

    0 0

    Good luck! I don't have any full clones in my environment to test with. If you have a support contract file a SR and they should be able to help with it.


    0 0
  • 04/18/18--13:20: Horizon and NAT
  • Hi,

     

    Trying to understand what mix of VMware technology I need to use to allow lab users to access their environments with Horizon View.  Within our lab, we have 6 different groups of RHEL 7 VMs that must replicate a real world environment as closely as possible.  Therefore each "group" of VMs is contained in its own Port Group and the port group does not have accessibility to any other networks... essentially the VMs are isolated and each port group uses the same range of RFC 1918 addresses (this is required.)  To gain access to the VMs via SSH, each port group has a dedicated NAT device with two NICs, one on the internal range and one on the external side.  We use 1:1 NAT mappings for each VM in the Port Group.

     

    SSH and other communication works fine in this scenario.  However, the task I have is to provide Horizon View access to the RHEL VM's in each "group."  The catch is that I need a single point of access, so a single Horizon Connection server for all groups of VMs... not 1 connection server for each group of VMs.  So essentiall I have NAT between the Connection server and the RHEL Agent.  The agent checks-in and communicates with the Connection server fine.

     

    The problem is when we launch a desktop pool.  the connection fails because the Agent is asking the client to use the RFC 1918 address instead of the external address (or at least, the FQDN of the VM.)  I know in older Citrix days, there were settings to allow for "AltAddr" where the agents is instructed to send the client a different IP than its actual IP.  I also see this is possible with VMware Horizon Direct-Connection Plugin, where an alternate IP can be specified, however Direct-Connection plugin does not support Linux.

     

    Aside from creating 6 different Connection servers and asking my users to rely on 6 different URLs for each "group", any options to keep a single Connection server (or UAG for that matter.)

     

    Thanks!

    JTK


    0 0
  • 04/18/18--15:01: Re: Horizon and NAT
  • Try Secure PCOIP tunnel setting through the UAG. And for external URL setting, set to the external address.


    0 0

    The release notes, KB and interoperability matrix for vCenter/vSphere 6.7 around Horizon 7.4 compatibility are confusing.

     

    The blog article states:

    At vSphere 6.7 general availability, compatible versions of VMware NSX, VMware Integrated OpenStack and VMware vSphere Integrated Containers will not be available. Moreover, VMware Horizon 7.4 is not compatible with the Instant Clone API used in vSphere 6.7.  Instant Clone support for vSphere 6.7 will be available in an upcoming Horizon release.

     

    This sounds like it is compatible, as long as you are not using instant clones.

     

    The interoperability matrix shows vSphere (esxi) 6.7 as compatible with Horizon 7.4, with the note that instant clones are not yet supported.

     

    However, the interoperability matrix only lists 6.5u1 as the latest vCenter compatible with Horizon 7.4. 

     

    Considering that your vSphere version has to match or be lower than your vCenter version. I'm confused.  Is the info in the interoperability matrix wrong, does Horizon 7.4 support vCenter 6.7?


    0 0

    I had the 6.7 Release Candidate set up with Horizon 7.4.  It worked, but Instant Clones would not work at all.  I believe true compatibility for Horizon View on vCenter 6.7 will come with 7.5 so I would wait until then before trying to move forward with 6.7.


    0 0
    0 0

    Hey guys,

     

    Here's what I've got. I'm currently running Horizon View 7.2 on ESXi hosts that are running 6.0. The hosts have Nvidia GRID K1 cards. I looked through quite a few guides on how to set this up for best video performance. In the past we were just using SVGA but have started to try to use vGPU. So I added the PCI Shared Nvidia card into the master image by editing the settings, chose a profile, reserved all memory, installed the Direct Connection agent into the master image and used the Horizon View client to connect to the master image and install the Nvidia driver related to the driver installed on the host. I then rebooted and shut down the master image and composed a new pool to test. When I log in, the screen isn't really drawing correctly across my three monitors. If I have it full screen, 2 screens don't load and the 1 screen that does flickers. If I minimize into a window it works fine, but the video quality isn't really that much better. Watching a full screen YouTube video at 720P is unbearable and laggy. Obviously something isn't working correctly. At one point the weird screen problem stopped and just started to work correctly but the video quality was never better. I'm just surprised that this is not working much better than the SVGA. I feel like something has to be not working properly. Any suggestions?


    0 0

    Is it actually using the GPU?  If you use a hardware monitor program that tell GPU usage from within the VM is it actually registering the GPU and is it actually being used?


    0 0

    Did you create Network Profiles in your vCenter to match the network labels in your answer file?


    0 0

    The K160q and K180q are the only profiles the K1 supports 4 monitors. Be sure you're using those on the image. At a minimum you need to use the K120q profile as their is issues with using under 1GB profiles. Like mentioned, check device manager and make sure the Vm sees the grid card and its being used. Also important, the drivers on the ESXi host must patch the drivers in your image. I can watch 720/1080p fine without Grid when you have the appropriate amount of CPU allocated to the VM. The K1 card is a nice improvement over SVGA and you will notice a performance increase.

     

    Use perfmon and check PCoIP/Blast latency, packet loss, FPS, etc.

     

    Also, check that you aren't capping your performance with any GPO view settings.


    0 0

    Desktop objects are in OU=Servers=DC=vdi,DC=vmware,DC=init

    On the desktop object, its the pae-SIDString


    0 0

    I bet the profile is the reason for the screens flickering then. I will test that today and verify that is the problem there. However, since you mentioned being able to watch 720/1080 fine with SVGA with the appropriate amount of CPU, I am not even able to do that. I've only tested with 2 vCPU. I would actually prefer SVGA if possible. All my users need to do is watch training videos and web conference. I know it's going to be relative to the environment and what you're running, but how many vCPU's are you using when watching 720/1080 with SVGA?


    0 0

    We are using 4 vCPU per Win10 VM. The main reason for 4 vcpu is for the additional resources needed for app volumes mounting at startup but it also benefits the video. I would investigate possible network latency issues / GPO settings.


    0 0

    Thanks! I am testing with 4 vCPU with crappy results and it's a fresh install of Windows 7 so nothing else in the image. We currently do not have a GPO to change any settings, but I can go down that route to see what settings need to be set and test from there. Thanks for the help! I did change the profile and that does correct the screen flickering.


    0 0

    Hello Shaun

     

    I have the same problem, internal connections via blast work, but external via UAG do not work. PCOIP external works successfully. port 443 for the connection server and 22443 and 9437 for the desktops are released on the firewall. the VIew Client even introduces the machines, but presents an error when opening the desktop. I'm suspicious of a certificate issue. Did you solve the problem? Follow logs fo view client

     

     

    2018-04-24T08:49:43.817-03:00| main| I125: Begin gathering input Locale Identifiers for the user.

    2018-04-24T08:49:43.817-03:00| vthread-9| I125: VTHREAD initialize thread 9 "vthread-9" host id 16988

    2018-04-24T08:49:43.958-03:00| main| I125: Number of installed Input Locale Identifiers for the user 2

    2018-04-24T08:49:43.958-03:00| main| I125: 1. Language 0x416 Layout unique id 0x7e

    2018-04-24T08:49:43.958-03:00| main| I125: 2. Language 0x416 Layout unique id 0x7d

    2018-04-24T08:49:43.958-03:00| main| I125: Finished gathering input Locale Identifiers for the user.

    2018-04-24T08:49:44.067-03:00| mks| W115: SSL: Unknown SSL Error

    2018-04-24T08:49:44.067-03:00| mks| I125: SSL Error: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed

    2018-04-24T08:49:44.067-03:00| mks| W115: SOCKET 1 (1056) Could not negotiate SSL

    2018-04-24T08:49:44.067-03:00| mks| W115+ The remote host certificate has these problems:

    2018-04-24T08:49:44.067-03:00| mks| W115+

    2018-04-24T08:49:44.067-03:00| mks| W115+ * Host name does not match the subject name(s) in certificate.

    2018-04-24T08:49:44.067-03:00| mks| W115+

    2018-04-24T08:49:44.067-03:00| mks| W115+ * self signed certificate in certificate chain

    2018-04-24T08:49:44.067-03:00| mks| W115: SOCKET 1 (1056) Expected thumbprint doesn't match actual thumbprint.

    2018-04-24T08:49:44.067-03:00| mks| W115: Expected thumbprint is: C2:AD:69:D4:90:4B:E0:CF:FE:CC:B0:0C:34:7B:F4:F0:FF:FB:B7:D2:BD:6C:66:EC:51:7E:1F:12:E5:85:56:46

    2018-04-24T08:49:44.067-03:00| mks| W115+   Actual thumbprint is: AE:92:91:C8:EC:B2:FD:21:F3:E4:17:55:C6:BB:4C:69:C2:59:C3:EF:23:77:53:44:5B:18:89:1E:BA:22:EE:F5

    2018-04-24T08:49:44.067-03:00| mks| W115: SOCKET 1 (1056) Cannot verify target host.

    2018-04-24T08:49:44.067-03:00| mks| W115: VNC CLIENT: received socket error 13: Connection error: could not negotiate SSL

    2018-04-24T08:49:44.067-03:00| mks| I125: VNC CLIENT: Destroying VNC Client socket.

    2018-04-24T08:49:44.067-03:00| mks| I125: MKSRoleMain: Disconnected from server.


    0 0

    Any guidance would be helpful.

     

    Has anyone experience issues with external users not being able to access applications with a VDI environment from their corp networks where using a personal connection worked?  It appears that some corp networks don't like the Data flow from a Security server into a VDI application?  For example, the port 22443 seems to be giving some corp networks trouble.

     

    Environment

     

    2 DMZ Windows based Security servers fronted by F5 Load balancers and paired with 2 internal Connection servers.

     

    Users can access the VDI portal and log into it seeing the apps, but once an application is clicked, the connection seems to fail access the .local RDSH server on port 22443. Users not able to connect from their corp environments can access the apps fine from an personal internet connection.  Something about some corp networks not liking the route and port the traffic takes.

     

    Thanks


    0 0

    Sounds a lot like a firewall issue on the corp network. They are probably blocking 8443 or 4172. If they are using blast, their clients will use 443/8443 to the security servers. If PCoIP they should be connecting by 4172. Only time 22443 is used is if you are using direct connect which it doesn't should like if they are logging into the portal.

     

    Check out the client logs. That will tell you your issue.
    Horizon Client for Windows Logs

     

     

     

    List of Ports:

    TCP and UDP Ports Used by Clients and Agents


    0 0

    Had the same exact problem.  Went down so many rabbit holes trying to fix it that I'm now left scarred for life.  

     

    Environment:

    • Windows 10 LTSB 2016, VMware Tools 10.2.5, All Windows updates, Horizon Agent 7.4, VMware Optimization Tool.
    • Horizon View 7.4 on Windows 2016 using only Instant Clones.
    • Windows 2016 DC's

     

    For me it turned out to be DHCP Relay.  The Instant Clone process would deploy the VM's seemingly without issue and I could login.  However no Computer GPOs would have been applied, only User GPOs.  If you waited the normal ~90 minutes for a GPO refresh OR did a gpupdate /force the Computer GPOs would apply without issue. After trying MANY "solutions" as well as opening a VMware support case, which they told us to contact MS (thanks!), I finally figured it out when I put a DHCP server on the same VLAN as the Desktops.  Days of pain immediately went away.  


    0 0
  • 04/25/18--22:46: Horizon View inquiries
  • 1. Can RDS hosts can also be configured as connection servers? Is this best process?

    2. If there is internal and external connection users (connection and security servers), Does DMZ and On premises datacenter needs separate Network Load Balancing?

    3. When would you consider using NLB in the first place?

    4. can you use VMware converter to convert Desktop/s or servers to vCenter/ESXi in a Horizon environment?

    5. Is Desktop/Application Farms data persistent?

    6. Can we re-use N computing N300 for Horizon VDI?


    0 0

    Your using a wildcard certificate for your external, but what does your internal dns look like. Does it match the same domain name as the external, or is it different. If its different thats where your running into problems I believe.


older | 1 | .... | 874 | 875 | (Page 876) | 877 | 878 | .... | 904 | newer