vRealize Operations for Published Applications 6.1

VMware vRealize Operations for Published Applications extends the functionality of VMware vRealize Operations Manager to monitor and manage Citrix XenApp 6.5 environments.

vRealize Operations for Published Applications collects data about your resources and presents that data in pre-configured dashboards for both real-time and predictive analysis.

Features in This Release

vRealize Operations for Published Applications 6.1 includes the following new features.

  • vRealize Operations Manager 6.0.2 support – vRealize Operations for Published Applications 6.1 is compatible with vRealize Operations Manager 6.0.2. It does not support earlier vCenter Operations Manager versions.
  • Monitoring and troubleshooting – vRealize Operations for Published Applications 6.1 monitors and generates reports for Citrix XenApp application, session, and license usage.
  • Citrix ICA virtual channel monitoring – vRealize Operations for Published Applications 6.1 monitors ICA virtual channels performance insight for faster session assessment and troubleshooting.
  • Out-of-the-box and custom summary reports – You can generate reports from pre-configured report templates or configure your own reports.
  • Internationalization – The vRealize Operations for Published Applications user interface and documentation are available in English, Japanese, French, German, Simplified Chinese, Traditional Chinese, and Korean.

More info at vRealize Operations for Horizon

FREE eLearning: Horizon View V6 and Mirage V5: What’s New

The Horizon View V6 and Mirage V5: What’s New is a FREE 1-hour self-paced course which highlights the new features and enhancements in Horizon View V6 and VMware Mirage V5 product. Get to know the key features of Horizon 6 and walk through use cases for each of different product areas that make up this powerful end-user computing suite.

See the course details and get started today.

LSI Logic SAS vs VMware Paravirtual SCSI disk

Within virtual machines, there are different SCSI controllers available for writing the data to the actual disk. For the different operating systems, there are best practices which gives the best performance. Windows XP uses the BusLogic Parallel SCSI driver and the results are acceptable. With Windows 7 the commonly used controller is the LSI Logic SAS controller. Which is selected automatically when creating a virtual machine of this type.

Different vendors have different best practices, some of them advice to use the VMware Paravirtual SCSI controller. The VMware Paravirtual SCSI controller needs to be selected manually and needs some additional actions before it can be used. Creating a small additional disk with VMware Paravirtual SCSI controller connected will force the OS the use and installation of the correct driver. The additional drive can be removed after installation and the initial drive must be connected to the VMware Paravirtual SCSI controller.

The question is which of these controllers gives the highest performance. For that I have started some tests with IOmeter in a virtual Windows 7 machine. The first test was with the VMware Paravirtual SCSI controller and using an additional disk beside the system disk. The results of the test is show below:

Test1

The second test was performed with the LSI Logic SAS controller and was using the additional diks. This configuration could not give the same performance as the VMware Paravirtual SCSI controller, the results of this test are placed below

Test2

The other test we did was with the system disk instead of the additional disk. The same results are showed as the previous tests. The use of the VMware Paravirtual SCSI controller performs a little better then the LSI Logic SAS SCSI controller

The results of above are within the virtual machine, with Xangati i was able to measure from the outside. The following picture will show the light better performance of the VMware Paravirtual SCSI controller, where the first and last test includes the VMware Paravirtual SCSI driver:

Xangati

For now, the conclusion can be drawn that the use of the VMware Paravirtual SCSI controller lead them a slight performance gain in these test.

Multiple Sessions in VMware Horizon View

When connecting to a floating pool using the View client, a user ended up receiving a new session despite having an existing session on another VM.

Analysis showed two desktop launch requests that came in from the same client connection in quick succession, spaced two seconds apart. Client log files imply the most likely scenario is that the user requested the desktop, immediately hit cancel on the wait dialog after the request was dispatched, and then launched it a second time. The View Connection Server correctly identified an existing disconnected session for the user while processing the first request at 13:18:57 for example, and provided the client with details to reconnect. The client dropped the Connection Server’s response and sent a second request at 13:18:59. This in turn was routed to the same VM, but the request was rejected as the first connection was still being set up by the View Agent. At this point the Connection Server then fell back to providing the user with a new session as the original was unavailable.

Solution:

View 5.1.1 and onwards contains a hidden configuration option that will inform the Connection Server to not fall back and allocate a new session if it knows the user already has one, even if reconnecting to the session failed. In the specific case analyzed, if this was toggled the user would have received a connection error on the second launch request with the option to retry. Retrying a few seconds later would have succeeded.

VMware recommends that the option to disable the default fallback behaviour is enabled. Instructions for this are below:

  • Ensure connection servers are running 5.1.1 or later
  • Follow the steps to connect to the ADAM database at http://kb.vmware.com/kb/2012377
  • Navigate to the object CN=Common,OU=Global,OU=Properties,DC=vdi,DC=vmware,DC=int
  • In the Attribute Editor for the object, edit pae-NameValuePair attribute
  • Making sure not to adjust any other values, add a new string to the attribute with value “cs-allowfallbackfromexistingsession=0” (no quotes)
  • Click OK to close the editor dialog, your change is applied with no need to restart the servers
  • To reverse the change, edit the attribute again and remove the above line

Verification:

To verify the fix has been applied, you may find the allowFallback value in a debug level line on any desktop launch. The line will have the following format:
<date-time> DEBUG <prefix> getSessionForApplication, userDn: <dn>, appMap: {<name>=<value>, […], allowFallback=false, […]}

Microsoft Patch causing SSO Handshake Timeouts with Horizon View 5.2

Every second Tuesday of the month Microsoft releases patches for the different operating systems and running applications of the vendor.  Before applying those patches to the operating systems and applications, an extensive testing process is needed. When all patches are behaving correctly the can be applied to the environment. When the extensive testing isn’t fulfilled completely, this can cause some strange behavior. At a customer site which is running a VMware Horizon View 5.2 environment this causes problems within their vCenter deployment.

One of the patches wasn’t tested enough and causes after patching and restarting the server an non functional vCenter Services. Within the log files different message directing to problems with connecting to the vCenter SSO services.

2014-02-20T06:43:08.260+01:00 [04512 error ‘Default’] SSLStreamImpl::BIORead from SSL(TCPClientSocket(this=00000000080f42d0, state=CONNECTED, _connectSocket=TCP(fd=-1), error=(null)) TCPStreamWin32(socket=TCP(fd=500) local=<IP vCenter Service>:56161,  peer=<IP SSO Service>:7444)) timed out
2014-02-20T06:43:08.260+01:00 [04512 error ‘Default’] SSLStreamImpl::DoClientHandshake for SSL(no stream): SSL_connect failed with BIO Error
2014-02-20T06:43:08.260+01:00 [04512 error ‘HttpConnectionPool-000001’] [ConnectComplete] Connect failed to <cs p:000000000abf25c0, TCP:grnap756.duo.local:7444>; cnx: (null), error: class Vmacore::Ssl::SSLHandshakeTimeoutException(SSL Exception: The SSL handshake timed out local: <IP vCenter Service>:56161 peer: <IP SSO Service>:7444.)
2014-02-20T06:43:08.260+01:00 [04440 error ‘[SSO][SsoCertificateManagerImpl]’] [CreateAdminSsoServiceContent] SSLHandshakeTimeoutException while trying to connect to SSO Admin server: SSL Exception: The SSL handshake timed out local: <IP vCenter Service>:56161 peer: <IP SSO Service>:7444.).

The VMware knowledge base article 2036170 wrote about patches which could be the source of the problem. With this customer new patches were placed on those systems the same morning. After some digging around in the patches one of them popped out. Patch 2862973 made changes to the MD5 hashing algorithm for Microsoft root certificates. And especially for server authentication which was used on this particular environment. After removing the patch on the systems, we we’re able again to start the vCenter Services.