During a Virtual Desktop deployment project there are always multiple groups in the organization that are responsible for parts of the architecture. This is the challenge for the project manager and the lead architect of the project: make sure these groups work together and streamline the communication and architectural decisions.
In one of our projects where we worked with the Oracle VDI software and Windows XP virtual desktops running in a VMware vSphere virtualization back-end we had a little issue that was caused by a lack of communication between the SysAdmins (in this case between the VMware SysAdmins and the Oracle VDI Admins, who were not in the same group).
As you may know the Oracle VDI session broker is assigning and connecting end-users to virtual desktops. When a user logs in to the desktop client, Oracle VDI requests a virtual desktop IP-address of the assigned user from the VMware vCenter server. When vCenter returns the IP-address, Oracle VDI establishes a session between the user's desktop client and the virtual desktop.
Back to our project. During a system maintenance window in the non-office hours, the Oracle VDI cluster was rebooted. When the system came back online again, the end-users couldn't login anymore into their virtual desktops. After some trouble-shooting we found out the connection between the Oracle VDI cluster and the VMware vCenter server failed (see the example screen-shot of the Oracle VDI GUI):
The reason the status was reported as Unresponsive had to do with a changed Administrator password in the Windows 2003 server where the vCenter software was running. The password change was implemented by the VMware vCenter Administrator several weeks before this issue happened, but it did not impact the connection between vCenter and Oracle VDI at that time.
Oracle VDI takes advantage of the web services API provided by the VMware Infrastructure SDK to communicate through HTTPS with VMware vCenter. When you setup a connection between the two components you have to verify that the servers are able to communicate:
- verify that the VMware vCenter Webaccess component is installed and configured.
- verify that Port 443 (HTTPS) is enabled in any firewall that may be active on the vCenter server system.
During configuration of the VMware Desktop Provider in the Oracle VDI GUI you specify the server properties and the administrator credentials of the vCenter server as shown in the left image.
At this time Oracle VDI opens a HTTPS connection to the VMware vCenter server for the first time (this open connection also happens during an Oracle VDI service startup after reboot).
This connection is cached and re-used as long as possible. In Oracle VDI there is a system thread that periodically checks if the connection is still usable. If it's not usable it tries to reestablish a new one.
One side effect of this checking is that the connection is typically kept alive for a long time. This is most likely what happened in our environment.
The issue was solved when we updated the password of the VMware Desktop Provider settings in the Oracle VDI broker. This is done by the CLI-command vda and VMware DP as the name of my provider:
root@vdiserver:~# vda provider-vc-setprops --properties=password-prompt "VMware DP"
Enter password for host vc.sunvdi.local: XXXXXXXX
Updated Provider Settings
When the password was changed, Oracle VDI reported Status OK in the VMware vCenter Desktop Provider Summary overview and since that change all the end-users could connect again to their assigned desktops.
I leave it up to the imagination of the reader to conclude the moral of the story :-)