In part one of troubleshooting VMware View 5, we examined six common failure points that you’re likely to stumble upon when working with VMware View 5. We also reviewed the connection procedures for connecting users to their desktops before moving on to linked clones. Today we’ll take a look at some real-world examples of problem desktops in View 5 and show you some of the usual steps we take to troubleshoot them. So take a look at the video, from TrainSignal’s new VMware View 5 Training before reviewing the troubleshooting steps outlined below.
You can find Problem Desktops in the Problem Desktops view within the View Administrator. This can be reached by navigating to Inventory > Desktops > vCenter VMs > Problem Desktops. You’ll then be presented with a list of Desktops that are in a status considered as Problem.
In our example, you can see three Desktops with three different problems. First one has a status named Agent unreachable, the second has Unassigned user, and the third has Error.
You can click on the Error status of a Desktop to see more information regarding that error. Apparently, this Error has something to do with a failure to join the domain.
We can see from the first column that this error is occurring in the Desktop named Accounting02. You can take a closer look at that Desktop by going to the vSphere Client and then navigating to it there.
You can see from our example that the IP address is set to 0.0.0.0, indicating that there may not be a network connection. Now we have something to start with. We go to the Commands panel and click on Edit Settings.
When the Virtual Machine Properties window appears, we go to the Hardware tab and click the Network adapter item. In this particular case, we see that the device is Connected and it is set to Connect at power on. Because everything looks good from here, we just click Cancel.
The next place to investigate is inside the machine itself. Again, we go to the Commands panel. But this time, we click Open Console.
To login to a VM, we go to VM > Guest > Send Ctrl+Alt+del.
We enter our User name and Password, and then click OK.
Next, we open up the Command Prompt.
We then run the command: ipconfig /all
As shown, our problem desktop really does have a 0.0.0.0 IP address. Our suspicion here is that DHCP couldn’t be contacted or it couldn’t provide an IP address. We can try to renew the address with DHCP using the command ipconfig /renew, and see if an address can be obtained that way.
Because an IP address was obtained this way, most likely what we need to do with our DHCP Scope is to reduce the Lease Time. That way, the IP addresses of machines that are deleted will be returned back to the pool quicker and subsequently be provided to new virtual machines.
But just to make sure, let’s check first whether everything’s OK now by refreshing the View Administrator.
It looks like the error is still there. Since this virtual machine has completely errored out during the provisioning process, we will need to delete it and create a new one. However, the good news is that, there’s really now a big chance that our suspicion was correct all along, and that gives us a hint on what we’d have to do later on.
If we are correct, then the VM that will replace this VM we are about to delete should no longer have the same error. Since our Accounting pool is a floating pool backed by View Composer, the system should be able to quickly recreate a new VM as soon as the problem VM is removed. To remove the problematic VM, we just select it and hit the Remove button.
Sure enough, after refreshing, that particular problem Desktop is no longer there.
Next up is the Desktop named Agents03, which has a status of Unassigned User. Our Agents pool is a dedicated pool, and a user named Charles has been assigned to the Agents03 desktop. No one else should be able to login to it. But it looks like someone other than Charles has been connected to it.
The most likely instance for this to happen is when an administrator logs in through the vSphere Client, so we’ll start there. We go to vSphere Client and navigate to the Desktop in question. In our case, that Desktop is Agents03. We then go to the Commands panel and click Open Console.
Again, to login to this VM we go to VM > Guest > Send Ctrl+Alt+Del
As shown by the screenshot, we have already logged in here earlier through the vSphere Client. Thus, the problem should be solved if we simply log off. This will allow Charles to login through View.
So if we go back to the View Administrator and click the Refresh button, we see that the problem has already been resolved.
Now for our last example, there are several things that can result in an Agent Unreachable status. Network connectivity is one. The service not starting is another.
Either way, one place to start an investigation is within the Desktop in question itself. So first, we login to the CallCenter02 Desktop.
Once we get inside, we open up a Command Prompt.
And then we ping our View Server to make sure we can still talk to it.
As we can see from our ping, there’s no problem with connectivity between this machine and the View Server. So we move on to the next possibility, which is that the service – for some reason – didn’t start properly. To check out that possibility, we launch the Computer Management window by going to Start > My Computer (right-click) > Manage.
Next, we expand the Services and Applications node and click Services. We then scroll down that large panel on the right until we reach the VMWare View Agent. As can be seen from the screenshot, the View Agent has not started. So, we do a manual start by clicking the Start link as shown below.
After the View Agent has started,
We go back to the View Administrator to verify that the Desktop can already speak to the View Agent. A refresh shows that this problem too has already been solved. So now, we no longer have any problem desktop.
Before we end our session, we log out of the CallCenter02 machine to make it available for other users.
That wraps up our post on troubleshooting VMware View 5. There are certainly other situations that come up but hopefully the scenarios described in this post give you a nice framework to work from. Simply knowing where VMware View 5 is prone to fail will go a long way to troubleshooting any issues that haven’t been described above.