When troubleshooting connectivity issues with your vMotion network (or vMotion VLAN), you may notice that you’re unable to ping using the ping or vmkping command on your ESXi and VMware hosts.
This occurs when you’re suing the vMotion TCP/IP stack on your vmkernel (vmk) adapters that are configured for vMotion.
This also applies if you’re using long distance vMotion (LDVM).
Why
The vMotion TCP/IP stack requires special syntax for ping and ICMP tests on the vmk adapters.
VMK using vMotion TCP/IP Stack
Above is an example where a vmk adapter (vmk3) is configured to use the vMotion TCP/IP stack.
How
To “ping” and test your vMotion network that uses the vMotion TCP/IP stack, you’ll need to use the special command below:
In the command above, change “vmk1” to the vmkernel adapter you want to send the pings from. Additionally, change “ip.add.re.ss” to the IP address of the host you want to ping.
Using this method, you can fully verify network connectivity between the vMotion vmks using the vMotion stack.
In response to COVID 19, VMware has extended their VMware Horizon 7 trial offering up to 90 days and includes 100 users. This includes both VMware Horizon 7 On-Premise, as well as VMware Cloud on AWS.
This is great if you’re planning or about to implement and deploy VMware Horizon 7.
In it’s simplest form, Horizon 7 allows an organization to virtualize their end user computing. No more computers, no more desktops, only Zero clients and software clients. Not only does this streamline the end user computing experience, but it enables a beautiful remote access solution as well.
And Horizon isn’t limited to VDI… You can install the VMware Horizon Agent on a Physical PC so you can use VDI technologies like Blast Extreme to remote in to physical desktops at your office. It makes the perfect remote access solution. Give it a try today with an evaluation license!
In all my years assisting and providing support with VMware Horizon, one of the most common problems that customers report with their VDI implementations, is the VMware Horizon Blank Screen.
When a user is presented with a blank or black screen when using the VMware Horizon Client, the problem can be caused by a number of different things. In this post, I will address and provide solutions for some of the common issues that cause the VMware Horizon blank screen.
VMware Horizon Blank screen issue
This troubleshooting guide applies to VMware Horizon 8, VMware Horizon 7, as well as earlier versions of VMware Horizon.
VMware Horizon Blank Screen Causes
There’s a number of different causes of a blank or black screen when connecting and establishing a VDI session to Horizon View. Click on the item below to jump to that section of the post:
Now that we have a list, let’s dive in to each of these individually. Some of these will require you to do your own research and will only guide you, while other sections will include the full fix for the issue.
VMware Tools and Horizon Agent Installation Order
When deploying the VMware Horizon View agent, you are required to install the agent, along with VMware tools in a specific order. Failing to do so can cause problems, including a blank screen screen.
The installation order:
Install GPU/vGPU drivers (if needed)
Install VMware Tools Agent
Install the VMware Horizon Agent
Install the VMware User Environment Manager Agent (if needed)
Install the VMware App Volumes Agent (if needed)
It is important to also consider this when upgrading the agents as well. When upgrading VMware Tools, it is recommended to re-install the Horizon agent in versions up to and including Horizon 8 2103. As of Horizon 2106 and later, you no longer need to re-install the Horizon Agent when performing a VMware Tools upgrade.
Network ports are blocked (Computer Firewall, Network Firewall)
For the VMware Horizon agent to function properly, ports must be accessible through your firewall, whether it’s the firewall on the VM guest, client computer, or network firewall.
The following ports are required for the VMware Horizon Agent when connecting directly to a View Connection Server.
Destination
Network Protocol
Destination Port
Details
Horizon Connection Server
TCP
443
Login, authentication, and connection to the VMware Connection Server.
Horizon Agent
TCP
22443
Blast Extreme
UDP
22443
Blast Extreme
TCP
4172
PCoIP
UDP
4172
PCoIP
TCP
3389
RDP (Remote Desktop Protocol)
TCP
9427
Client Shared Drive redirection (CDR) and Multi-media redirection (MMR).
TCP
32111
USB Redirection (Optional), can be incorporated in to the Blast Extreme connection.
Network Ports Required for VMware Horizon View to View Connection Server
The following ports are required for the VMware Horizon Agent when connecting through a VMware Unified Access Gateway (UAG).
Destination
Network Protocol
Destination Port
Details
Unified Access Gateway
TCP
443
Login, authentication, and connection to the Unified Access Gateway. This port/connection can also carry tunneled RDP, client drive redirection, and USB redirection traffic.
TCP
4172
PCoIP via PCoIP Secure Gateway
UDP
4172
PCoIP via PCoIP Secure Gateway
UDP
443
Optional for Login traffic. Blast Extreme will attempt a UDP login if there are issues establishing a TCP connection.
TCP
8443
Blast Extreme via Blast Secure Gateway (High Performance connection)
UDP
8443
Blast Extreme via Blast Secure Gateway (Adaptive performance connection)
TCP
443
Blast Extreme via UAG port sharing.
Network Ports Required for VMware Horizon View to VMware Unified Access Gateway (UAG)
You’ll notice the ports that are required for Blast Extreme and PCoIP. If these are not open you can experience a blank screen when connecting to the VMware Horizon VDI Guest VM.
Certain types of IPS (Intrusion Prevention Service) can also intercept and block traffic. IPS may cause intermittent issues.
DNS Issues
While VMware Horizon View usually uses IP address for connectivity between the View Connection Server, guest VM, and client, I have seen times where DNS issues have stopped certain components from functioning properly.
It’s always a good idea to verify that DNS is functioning both internally and externally. DNS (forward and reverse) is required for VMware Horizon Linux guests VMs.
XDR, EDR, and AV Platform causing momentary blank screen at logon
When using an XDR (Extended Detection and Response), EDR (Endpoint Detection and Response), or special AV solution with non-persistent desktops, one may experience a momentary blank screen on user session logon. I have observed this with Sophos XDR as well as Cortex XDR, with blank screens varying from 10-30 seconds on user login.
Removal of the platform can reduce the momentary blank screen down to 1-5 seconds.
I highly recommend configuring and tweaking policies as much as possible to enhance and optimize your environment. There will always be a trade off of performance for security, and the decisions should be made by those in the organization who make cyber security related decisions.
Incorrectly configured Unified Access Gateway
A big offender when it comes to blank screens is an incorrectly configured VMWare Unified Access Gateway for VMware Horizon.
Sometimes, first-time UAG users will incorrectly configure the View Connection server and UAG.
When configuring a UAG, you must disable both “Blast Secure Gateway”, and “PCoIP Secure Gateway” on the View Connection Server, as the UAG will be handling this. See below.
Secure Gateway Settings on View Connection Server when used with UAG
Another regular issue is when admins misconfigure the UAG itself. There are a number of key things that must be configured properly. These are the values that should be populated on the UAG under Horizon Settings.
Connection Server URL
https://ConnectionServerIP:443
Connection Server URL Thumbprint
sha1=SSLTHUMPRINT (Thumbprint of the SSL certificate your View Connection Server is using)
PCOIP External URL
UAG-EXTERNALIP:4172
Blast External URL
UAG-InternetFQDN:443
Tunnel External URL
UAG-InternetFQDN:443
You must also have a valid SSL certificate installed under “TLS Server Certificate Settings”. I’d recommend applying it to both the admin and internal interface. This is a certificate that must match the FQDN (internal and external) of your UAG appliance.
Once you’re good, you’re green!
VMware Unified Access Gateway showing valid
You should always see green lights, all protocols should work, and the connections should run smooth. If not, troubleshoot.
GPU Driver Issue
When using a GPU with your VM for 3D graphics, make sure you adhere to the requirements of the GPU vendor, along with the VMware requirements.
Some vendors have display count, resolution, and other limits that when reached, cause Blast Extreme to fail.
An incorrectly installed driver can also cause issues. Make sure that there are no issues with the drivers in the “Device Manager”.
Blast Extreme log files can be found on the guest VM in the following directory.
C:\ProgramData\VMware\VMware Blast\
Looking at these log files, you can find information that may pertain to the H.264 or display driver issues that will assist in troubleshooting.
When using GPUs such as Nvidia GRID and AMD MxGPU, it is recommended to disable the VMware SVGA 3D Driver and adapter inside of Device Manager after you install the applicable GPU drivers.
NVIDIA vGPU Issues
You may be experiencing issues related to the NVIDIA vGPU platform, either inside of the VM guest, or on the VMware ESXi host.
A corrupt VMware tools install, whether software or drivers can cause display issues. Make sure that the drivers (including the display driver) are installed and functioning properly.
It may be a good idea to completely uninstall VMware Tools and re-install.
If you’re experiencing display driver issues (such as a blank screen), before re-installing VMware Tools try forcibly removing the display driver.
Open “Device Manager”
Right click on the VMware Display adapter and open “Properties”
On the “Driver” tab, select “Uninstall”
Check the box for “Delete the driver software for this device”.
This will fully remove the VMware driver. Now re-install VMware Tools.
Make sure that if you are running 64-bit Windows in the VM then you install and use the 64-bit Horizon Agent.
You may experience issues with the “VMware Horizon Indirect Display Driver”. Some users have reported an error on this driver and issues loading it, resulting in a blank screen. To do this, I’d recommend forcibly uninstalling the driver and re-installing the Horizon Agent.
To forcibly remove the “VMware Horizon Indirect Display Driver”:
Open “Device Manager”
Right click on the “VMware Horizon Indirect Display Driver” and open “Properties”
On the “Driver” tab, select “Uninstall”
Check the box for “Delete the driver software for this device”.
Now proceed to uninstall and reinstall the Horizon View Agent.
When running the Horizon Agent on Horizon for Linux, make sure that forward and reverse DNS entries exist, and that DNS is functioning on the network where the Linux VM resides.
Also, as a reminder, it is recommended that you re-install the Horizon agent in versions up to and including Horizon 8 2103 after upgrading VMware Tools. As of Horizon 8 2106, you no longer need to re-install the Horizon Agent when performing a VMware Tools upgrade.
Video Settings (Video Memory (VRAM), Resolution, Number of Displays)
When experiencing video display issues or blank screens on VMware Horizon View, these could be associated with the guest VM’s memory, video memory (VRAM), display resolution, and number of displays.
vSphere Video RAM Configuration for VMware Horizon
If you do not have enough Video RAM (VRAM) allocated to the virtual machine and/or you have too many displays (multi-monitor), then you can experience the blank screen with Horizon.
Make sure you are adhering to the specifications put forth by VMware. Please see the following links for more information.
While this isn’t likely to cause a blank screen issue (it can though), it’s always a good idea to set your image to a lower resolution before snapping or converting to a template for deployment.
It’s a lot easier for the VMs to start using lower resolution and VRAM (Video Memory) and then increase to what’s needed, instead of starting at a crazy high resolution and then getting adjusted down.
I consider it a good practice to reduce the graphics resolution before creating and deploying the image to the desktop pools.
Protocol
When troubleshooting blank screens with VMware Horizon, you need to try to identify whether it’s specific to the guest VM, or if it’s associated with the connection protocol you’re using (and the route it takes whether through a Connection Server, or UAG).
Always try different protocols to see if the issue is associated with all, or one. Then try establishing connections and find if it’s isolated direct to the Connection Server, or through the UAG.
If the issue is with a specific protocol, you can view the protocol log files. If the issue is with the UAG, you can troubleshoot the UAG.
Log files can be found in the following directory:
C:\ProgramData\VMware\
HTTPS Proxy and redirection issues
If you are connecting through a network that does passive and/or transparent HTTPS scanning or uses a proxy server, you may experience issues with inability to connect, or blank screens.
You’ll need to modify your firewall or proxy to allow the VMware connection and open the required ports for VMware Horizon and create an exception not to touch or manipulate the VMware Horizon related traffic.
Login banner or disclaimer (PCoIP)
I haven’t seen or heard of this one in some time, but when using VMware Horizon with PCoIP, sessions can fail or show a blank screen when the legal disclaimer login banner is used on the Windows instance (Windows 7, Windows 10, or Windows 11).
It never stops surprising me how old some of the VMware Horizon View environments are that some businesses are running. VMware regularly updates, and releases new versions of VMware Horizon that resolve known issues and bugs in the software.
While it may be difficult, simply upgrading your VMware Horizon environment (VMware vSphere, View Connection Server, VMware Tools, VMware Horizon Agent) can often resolve many issues.
Blank Screen connecting to Physical PC running Horizon Agent
After troubleshooting these issues, you should be able to resolve the issue.
Conclusion
As you can see there are a number of different things that can cause Horizon View to show a blank screen on login. It’s always best to try to understand how the technology works, and establish where the failure points are.
Let me know if this helped you out, or if you find other reasons and feel I should add them to the list!
After installing the VMware Horizon Agent on a Physical PC, you may have noticed some issues with USB redirection, audio, and hardware redirection. These issues include not working, or not working in it’s entirety.
On a few occasions I’ve had readers reach out to inform me that they are experiencing these issues. Most recently a reader by the name of “Sascha” reached out and reported issues with audio, particularly the microphone not functioning or being redirected from the VMware Horizon View Client to the Physical PC.
The Fix
In Sascha’s case (along with the other readers), we troubleshot the issue and realized that in each and every case the problem was due to the use of a Windows 10 Profesional license being used. As per the VMware Horizon release notes, a Windows 10 Enterprise license must be used when installing the Horizon Agent on a Physical PC.
Once Sascha and the other users upgrades or installed a Windows 10 Enterprise license, the issues stopped immediately.
This is another reminder that you need an Windows 10 Enterprise license when installing the Horizon Agent on a Physical PC.
I’ve noticed in a few situations where an ESXi host is marked as “unresponsive” or “disconnected” inside of vCenter due to issues occurring on that host (or connected hardware). This recently happened again with a customer and is why I’m writing this article at this very moment.
In these situations, usually all normal means of managing, connecting, or troubleshooting the host are unavailable. Usually in cases like this ESXi administrators would simply reset the host.
However, I’ve found hosts can often be rescued without requiring an ungraceful restart or reset.
Observations
In these situations, it can be observed that:
The ESXi host is in a unresponsive to disconnected state to vCenter Server.
Connecting to the ESXi host directly does not work as it either doesn’t acknowledge HTTPS requests, or comes up with an error.
Accessing the console of the ESXi host isn’t possible as it appears frozen.
While the ESXi host is unresponsive, the virtual machines are still online and available on the network.
Troubleshooting
In the few situations I’ve noticed this occurring, troubleshooting is possible but requires patience. Consider the following:
When trying to access the ESXi console, give it time after hitting enter or selecting a value. If there’s issues on the host such as commands pending, tasks pending, or memory issues, the console may actually respond if you give it 30 seconds to 5 minutes after selecting an item.
With the above in mind, attempt to enable console access (preferably console and not SSH). The logins may take some time (30 seconds to 5 minutes after typing in the password), but you might be able to gain troubleshooting access.
Check the SAN, NAS, and any shared storage… In one instance, there were issues with a SAN and datastore that froze 2 VMs. The Queued commands to the SAN caused the ESXi host to become unresponsive.
There may be memory issues with the ESXi instance. The VMs are fine, however an agent, driver, or piece of software may be causing the hypervisor layer to become unresponsive.
If there are storage issues, do what you can. In one of the cases above, we had to access the ESXi console, issue a “kill -9” to the VM, and then restart the SAN. We later found out there was issues with the SAN and corrupted virtual machines. The moment the SAN was restarted, the ESXi host became responsive, connected to the vCenter server and could be managed.
In another instance, on an older version of ESXi there was an HPE agentless management driver/service that was consuming the ESXi hosts memory continuously causing the memory to overflow, the host to fill the swap and become unresponsive. Eventually after gracefully shutting down the VMs, I was able to access the console, kill the service, and the host become responsive.
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.
Do you accept the use of cookies and accept our privacy policy? AcceptRejectCookie and Privacy Policy
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
