VMware View Desktop plugin for vSphere Web Client
Today I installed the VMware View Desktops Plug-in on the vSphere Web Client. This plugin is a Technical Preview included with Horizon View 5.2. After installing this plugin you can use the vSphere Web Client to search for a View Desktop user and the Web Client will show the virtual desktop(s) that the user is logged on to. You can use this tool to troubleshoot issues that may arise with an end user’s virtual desktop. If a user calls in with a problem, you can immediately jump to the user’s VM and troubleshoot from there.
Installation
The installation is well described in the README.txt file which is located in the following path:
C:\<VIEW-installed-directory>\Server\TechPreview\ViewAdminPlugin
The View Desktops plug-in works with vSphere 5.1 and later versions only. Make sure system clocks are synchronized and valid SSL server certificates are issued with the correct hostnames on all servers.
Before you register the Plugin, VMware recommends to snapshot the vSphere SSO server system, vSphere Web Client system, and vCenter Server system. It’s called a Tech Preview, so when something goes terrible wrong, you can revert to snapshot.
First, you need to configure View to recognize the vCenter Lookup Service. You perform this configuration task once for all View Connection Server instances in a replicated group:
- Open a command prompt on View Connection Server to run the regtool.cmd utility.
- cd C:\<VIEW-installed-directory>\Server\TechPreview\ViewAdminPlugin
- (Optional) set JAVA_HOME to <jre-folder> (set JAVA_HOME=c:\Program Files\VMware\VMware View\Server\jre)
- Configure the Lookup Service: regtool.cmd configureLookupService -u @ -ld https://:7444/lookupservice/sdk
- If the command fails because the certificate is not trusted, accept the certificate thumbprint: regtool.cmd configureLookupService -u @ -ld https://:7444/lookupservice/sdk -lt
When you type the password, the following warning message might appear. You can ignore this message:
log4j: WARN No appenders could be found for logger <com.vmware.vim.vmomi.core.types.impl.VmodlContextImpl>. log4j: WARN Please initialize the log4j system properly
Next, you register the View Desktops plug-in. You need to perform these steps on every View Connection Server in a replicated group: … Continue Reading
Site-failover a VMware View Stateful desktop, not supported?!
In this blogpost I describe the challenge with stateful desktops in a multi-datacenter View environment: VMware doesn’t support it!
Stateful vs. Stateless
In my opinion, a stateful desktop is a desktop, usually with a static user assignment, where the user can make changes to the system, like installing applications. A stateless desktop is a desktop in a desktop pool with a floating assignment and configured to refresh after the user logs off. It’s no problem to failover a user to another View site, using stateless desktops. This blogposts is about site-failover a stateful desktop.
Multi-datacenter View architecture
A typical VMware View architecture is based on the concept of View blocks and pods. A View block consist of one or more vSphere clusters with a maximum of 2000 virtual desktops (this limit is changed in Horizon View 5.2 to 10.000). A View Pod consists of one or more View blocks and a View Management block, where the View Connection servers are “clustered”. All the View Connection servers in a View block share the same information and replicates an ADAM database which contains the configuration of the View infrastructure.
One of the disadvantages of VMware View in my opinion, is that if you want to implement a VMware View infrastructure across multiple datacenters and you want an architecture that is supported by VMware, you have to create multiple VMware View Pods. One of the “rules” of VMware is that View Connection servers needs to be on the same LAN and the same location. If you have multiple datacenters where you want to implement View Connection servers, each datacenter will be configured as a separate View environment.
… Continue Reading
Testing Teradici APEX 2800 with Login VSI – part 3
Before you continue to read this article, make sure you first read part 1 and 2. In part 1 I explain what the Teradici APEX 2800 card is and what the use-case is for the card. I also explain about LoginVSI, a VDI-benchmarking tool which I also use with Project VRC. In part 2 I shared the results of the tests I performed. In this part, I will share the results of extra tests I performed with the APEX 2800 card, but now with a new software release (2.0.0).
Disclaimer: As explained before, I performed the tests with LoginVSI. According to Teradici’s whitepaper, this is nog a good way to show the capabilities of the APEX 2800 card. I explained the reasons in part 1. LoginVSI is THE VDI benchmarking tool used by large companies like Citrix, HP and Cisco, to validate their reference architectures. In my opinion, LoginVSI is a very good tool to show the impact of using the Teradici APEX 2800 card compared to a situation where you don’t use the APEX 2800 card, if you want to see the impact on user-density. These tests do not say anything about user experience!
I’ve performed 2 types of tests:
- VSIMax tests:
105 VMs (Windows 7 SP1, 1GB RAM, Office 2007SP2) are pre-booted. Every 30 seconds a user logs in and starts a LoginVSI test. During the entire test, response times are measured. Once an average response has reached the dynamic maximum, the VSIMax has been reached, which can be seen as the maximum number of users. After the last users has started a session, the sessions starts to log off.
- Steady-state tests:
10 or 30 VMs are pre-booted (depending on the workload). Every 30 seconds a user logs in and starts a LoginVSI test. After the last user has started a session, the users will continue the LoginVSI test. A timer has been set between 30 and 60 minutes. And the end of the timer, the users starts to log off.
All tests have been performed multiple times to see if there were big differences between the tests. Where possible, averages were taken and presented in the graphs. The colour-coding for the graphs and charts:
Black = RDP
Orange = PCoIP software (no APEX 2800 card)
Blue = PCoIP with APEX 2800 card with software release 1.1.1 (build 15038)
Dark blue = PCoIP with APEX 2800 card with software release 2.0.0
VMware View Manager “The service is not working properly.”
I was building a new VMware View 5.1 environment and I experienced an issue I want to share. I think this is not documented correctly right now in the View 5.1 documentation.
Situation:
I have 2 View Connection servers 5.1.1 (VCS01 and VCS02) and 1 VMware vCenter 5.0 u1 (VC01). The vCenter server is added to the View configuration and is working without a problem. I don’t use Composer in this configuration and I have a valid SSL certificate installed on all 3 servers.
Issue:
I logged on to the View administrator console of VCS01 and I changed host caching of the vCenter server setting in “View Configuration\Servers\vCenter servers”. I changed the following setting: “Override default host cache size” :
The service of vCenter server turned red in the View admin dashboard with status: “The service is not working properly”. This happens a couple of minutes later.
In the logfile of one of the connection servers I saw the following error:
714f2e-55dd-48b3-8a39-ac825f59a6cd-1352984469542> [Audit] VC_OUTAGE:Url:https://vc01.domainname.x:443/sdk
2012-11-15T14:11:24.493+01:00 WARN (0AFC-0100) [ServiceConnection25] VirtualCenter https://vc01.domainname.x:443/sdk is currently unavailable – attempting to reconnect
2012-11-15T14:11:25.960+01:00 WARN (0AFC-0100) [ServiceConnection25] Problem while performing VC operation: ‘Permission to perform this operation was denied.’ [com.vmware.vim25.NoPermission]
2012-11-15T14:11:25.984+01:00 INFO (0AFC-0100) [Audit] VC_OUTAGE:Url:https://vc01.domainname.x:443/sdk
2012-11-15T14:11:25.984+01:00 WARN (0AFC-0100) [ServiceConnection25] VirtualCenter https://vc01.domainname.x:443/sdk is currently unavailable – attempting to reconnect
2012-11-15T14:11:25.985+01:00 WARN (0AFC-0100) [ServiceConnection25] Previous VC reconnection attempt didn’t work, will wait before attempting again.
2012-11-15T14:11:41.111+01:00 WARN (0AFC-0100) [ServiceConnection25] No permission to perform VC operation.
2012-11-15T14:11:42.566+01:00 WARN (0AFC-0100) [ServiceConnection25] Problem while performing VC operation: ‘Permission to perform this operation was denied.’ [com.vmware.vim25.NoPermission]
I posted my issue in the VMware communities forum and luckily someone pointed me in the right direction. It seems the documentation is not complete when it comes to user rights for the vCenter user. According to the documentation, you need certain rights in vCenter to get VMware View work correctly. One of the new rights in mentioned in the View 5.1 documentation is: “Global \ Act as vCenter server”
The following privilege is required to implement ESXi host caching in View. If you do not use host caching, the vCenter Server user does not need this privilege.
Apparently, if you want to change the host cache on a per host level, you need additional rights in vCenter:
Host \ Configuration \ Advanced settings
VMware View upgrade path – not so easy…
A customer is using VMware View 4.5 on ESX 4.1 and wants to upgrade to View 5.1.1 with ESX 5.0 U1. If you take a look at the following interoperability matrix, the upgrade path is not so easy:
The first step is to upgrade the View components to View 4.6.1. the next step is to upgrade ESX to 4.1 U3. Then the View components can be upgraded to View 5.1.1 and the final step is to upgrade the vSphere components to 5.0 U1. With every upgrade step, you have to be careful which component of View you upgrade first. Take a look at the following compatibility matrix for View 5.1 and 5.0:
As you can see, some components are only compatible during the upgrade and some components are not compatible at all. And this is just the 5.1/5.0 matrix. Always doublecheck the versions you are currently running and don’t forget the View clients, which also need to be at a certain version, before you can upgrade.
Alternatively, a new View infrastructure can be build next to the old one. Then the current master image(s) can be copied to the new environment and upgrade the VMware tools and the View agent. Then point the users to the new environment.
As you can see, the latest vSphere version (5.1) is not supported with any version of View at the moment. When the next update of View (5.1.2? 5.2? 5.5?) supports vSphere 5.1, you will first need to upgrade the View components, and then the vSphere components. Updating VMware View is always fun 
