Troubleshooting VMware View 5: Failure Points
Welcome to part one of a two-part series about troubleshooting VMware View 5. In this first post, we’ll tackle the most common failure points in VMware View 5 and talk about the best ways to troubleshoot them when issues arise. The failure points we’ll review include:
- Network connectivity failure between client and connection or security serve
- Network connectivity failure between desktops and connection server
- Failure to create a pool
- VM stuck in provisioning state
- VM stuck in customizing state
- USB redirection problems
After learning about the different points of failure you should look out for, we’ll take a look at the connection procedures for connecting a user to a desktop and how linked clones work, which will help you troubleshoot vmware view issues related to your composer-based pools. Later, in part two, we’ll explore some real-world examples of troubleshooting VMware View 5 desktops.
(Instructional video below provides a walkthrough of the steps contained in this article.)
In part 2 we’ll get our hands dirty with some real-world examples on troubleshooting problem desktops in VMware View 5.
In the video, from TrainSignal’s new VMware View 5 Training <insert link to training>, VMware vExpert Brian Knudtson will explain the concepts and walk you through the troubleshooting procedures. But everything is also outlined below, so watch the video and review the article below for maximum effect.
Passwords Haven’t Disappeared Yet
123456. Qwerty. Iloveyou. No, these are not exercises for people who are brand new to typing. Shockingly, they are among the most common passwords that end users choose in 2021. Research has found that the average business user must manually type out, or copy/paste, the credentials to 154 websites per month. We repeatedly got one question that surprised us: “Why would I ever trust a third party with control of my network?
Failure Point #1: Network Connectivity between Client and Connection or Security Server
Network connectivity is probably the most common issue you’ll run into. It’s a good thing most of your standard connectivity troubleshooting will work here.
For example, you’ll often get involved in activities like checking proxy and firewall settings as well as verifying whether DNS resolution works. This can be as simple as from the client device connecting to the View Connection Server website. The simple way to test this is to load up a browser on the client device and try to connect to the Security or the Connection Server. If that all works, then you can use Telnet to check the other ports that we’ll talk about later. That way, you can make sure that you can connect from the client to the server, and into the Desktop. Or, more specifically, you can make sure that you can properly connect from the View Client machine to the Connection Server or Security Server.
There are some instances in which you may need to configure the IP address in the External URL field within VMware View for either the Connection Server or the Security Server configuration, or possibly both. This could be in instances wherein DNS resolution may not be available. When using a Security Server you may also need to go in to make sure the PCoIP Secure Gateway functionality is enabled and that the PCoIP External URL is set properly. Otherwise, the Security Server may not allow PCoIP connections to pass through or it may force the View Client to connect to an Internal URL rather than the External URL it needs to use.
Failure Point #2: Network connectivity between Desktops and Connection Server
When you run into network connectivity between a Desktop and the Connection Server, you’ll usually see issues within View Administrator where the status for the Desktop can’t be updated. This often shows up as an “Agent Unavailable” status for the Desktop.
Again, you’ll want to check your proxy and firewall settings and DNS resolution between the Desktop and the Connection Server. You’ll also want to make sure the Desktop has a valid DHCP IP address.
With the number of Desktops that View can spin up and down in a short period of time, it’s not unusual for a DHCP Scope to be used up fairly quickly. If you see this type of issue, you may need to set your DHCP Lease Time to a lower value to ensure that they clean up a lot quicker.
Failure Point #3: Failure to Create a Pool
When a pool fails to create, you’ll first want to make sure that vCenter Web Service is available and that the Connection Server can connect to it. This is the primary method of manipulating the pools and the Desktops within it.
Also check that there is enough free space on the datastore that you configured for the pool. If there’s not enough free space on the datastore that you configured the pool to use, no Desktops will be created. You may also want to double-check the service account to see whether it has proper permissions to create a pool, access the template or parent VM, access configured customization specifications, and access the vSphere infrastructure.
You also need to make sure that the required Active Directory permissions are in place as well, because not having the proper permissions in AD can cause provisioning to fail.
If you run into a resource constraint on your vCenter server, you may need to reduce the maximum number of concurrent provisioning and power operations within the View Administrator console. This can be done within the vCenter Settings at View.
Lastly, you may need to consider adding additional vCenter Servers if your View environment is growing too big for a single vCenter Server.
Failure Point #4: VM stuck in Provisioning state
If you find a VM stuck in the Provisioning state, it’s most likely due to a restart of the Connection Server. If your Connection Server restarts during the deployment of a virtual machine, that virtual machine can be lost. You simply need to delete that VM and allow View to redeploy another Desktop in its place.
Failure Point #5: VM stuck in Customizing state
On the other hand, if you find a VM stuck in the Customizing state, it is most likely because there just isn’t enough free space on the datastore for the VM to power on. Remember that, by default, each VM is going to try to store a swap file with the same size as the space the VM is configured with. And that swap file will be located on the same datastore as the VM. So make sure it’s got enough space to do that.
Failure Point #6: USB Redirection Problems
One thing that’s highly recommended in order to avoid USB redirection problems is to use PCoIP instead of RDP. That’s because PCoIP can better handle different USB devices.
Next, verify that the policies within VMware View for the Global, Pool, and Individual user levels, all have USB Redirection enabled. They already are by default. You can also check the logs on both the virtual desktop and the end-user device for entries of class “wssm_usb” or “wswc_usb”, which indicate log messages related to USB redirection.
On the virtual desktop, you also want to make sure that the VMware View Virtual Device Manager and VMware View Virtual USB Hub drivers are installed and enabled. In case they have been disabled, you can enable them by reinstalling the View service. If there are issues there, you can simply rerun the View Agent installer and that should properly configure them.
In addition, you can check the client device (if it’s a Windows machine) to make sure that the VMware View Generic Device Driver and the USB driver for that redirected device are both installed and enabled. These are needed to be able to redirect across the PCoIP connection.
Desktop Connection Procedures
To carry out your troubleshooting more efficiently, you need to be familiar with the procedure VMware View goes through in connecting a user to a Desktop. Here are the general steps:
- The View Client initiates a connection to the Connection Server or Security Server, providing a username and password. This occurs over TCP port 443, which is the standard HTTPS port.
- The Connection Server returns a list of entitled Desktops that the user has, and the user then selects one. The information bearing the user’s choice is sent back to the server. Again, this occurs over TCP port 443.
- The View Client initiates the PCoIP connection to the Desktop. This occurs over TCP port 4172.
- The View Client on the client device and the View Agent on the virtual desktop negotiates the PCoIP session. This happens over several back and forth communications on TCP port 4172.
- Once the session has been negotiated, the View Agent initiates a PCoIP data channel connection directly to the View Client. This now occurs over UDP port 4172.
- After that initial connection is created, the Control and Data sessions open up between the View Client and the View Agent over UDP port 4172. At this point, a connection to the Desktop is established.
- While the PCoIP communications over UDP port 4172 goes on, PCoIP also opens up a heartbeat connection between the Client and the Agent using TCP port 4172.
- The Client also opens up a heartbeat connection between itself and the Connection Server. This occurs over TCP port 443. This connection is established so that the Connection Server and View Administrator have some awareness of the current session.
How Linked Clones work
Let’s now go over how Linked Clones work. This will help you be better prepared for troubleshooting issues related to your Composer-based pools.
First, note that all linked clone Desktops link back to a replica VM. This is not the actual parent VM, which is an important distinction to make. View does this so that the individual linked clones aren’t dependent on the parent VM. Thus, changes can be made to the parent VM even while the clones are in operation.
The replica VM is a protected entity within vCenter. This prevents you from making any modifications to it, thereby preventing any potential issues with the linked clones. The replica itself is a thin provisioned full clone of the parent VM at the specific snapshot that was chosen to be the base image.
As soon as you create a pool or recompose a pool and tell it to use a specific snapshot on a specific parent VM, View will initiate a full clone of that snapshot state. By default, if you don’t specify a datastore to store the replica machines on, one replica will be created for each datastore that that pool is defined to use.
So, you will have multiple copies of that parent image’s snapshot across all your datastores unless you choose to put all your replicas on a single datastore. To save space, View will utilize replicas between pools that are using the same parent VM and same snapshot state. This also significantly speeds up the process of deploying a new pool because, on subsequent pools that use the same base image, you save the time of having to create that full clone replica of the parent VM.
Occasionally, replicas can be orphaned and will need to be manually deleted from vCenter. In order to see the replicas in vCenter, which are hidden by default, you need to go into the Client settings for the vSphere Client and enable the “Show View Composer virtual machines” setting. This will then present a new folder, under which you’ll find all of your replica VMs.
Those replicas will still be protected entities, so you won’t be able to do anything with them. In order to delete replicas, you can use the SviConfig command to unprotect all of the replicas. Here’s how a typical SviConfig command looks like: