Login VSI 4.0 released!
Login VSI B.V. announces 4.0, a major new release of its flagship product Login VSI, the industry standard performance and scalability testing tool for Virtual Desktop Infrastructures and Server Based Computing environments.
The design of this new release has been driven by extensive customer feedback programs, and production testing projects executed at multiple customer and vendor sites, including the tests done for the acclaimed independent research project Virtual Reality Check. Login VSI 4.0 makes testing of VDI and SBC environments easier and more realistic than ever before.
Improved ease of installation
The test image footprint of Login VSI has been reduced by almost 90%. This makes the tool not only easier to install, but also easier to integrate and deploy. Centralization of management, updates and logging makes the use of Login VSI more efficient than ever. Direct Desktop Launch (DDL) mode enables large-scale testing with minimal infrastructure.
Improved ease of test creation
The new intuitive and workflow oriented user interface of Login VSI 4.0 offers step-by-step test creation and wizard based test configuration for all important brokers and languages. The new workload editor introduces a new meta language which makes the customization of workloads very transparent and efficient. The new benchmarking mode enforces strict testing standards, providing industry standard results that are objective, comparable and repeatable.
Improved test realism
The duration of the standard workloads has been increased from 14 to 48 minutes loops. Also the way in which segments and applications start has been improved to better reflect real world user behaviour. The datasets used in the workloads now offer 1000 different documents per type, more and larger websites, and a video library in every format, all to ensure a real world variety in data usage. The execution of the workloads is improved through the introduction of phasing, allowing for real world production user scenarios. … Continue Reading
Change properties in VMware Horizon Workspace
The following error appeared in the VMware Horizon Configurator Webpage after I upgraded vCenter 5.0 to vCenter 5.1:
Error detail: Cannot login to vCenter Server. Please confirm vCenter Server is running. See catalina.out log for the full stack trace.
I can explain this because during installation of Horizon Workspace I didn’t add the domain to the account when I entered the vCenter credentials. After I upgraded vCenter to 5.1 and installed the SSO service, users can only log on when the domain is also specified. When I searched on how to change this settings, the documentation of VMware Horizon Workspace didn’t help me out. But there is on command you can use on the Configurator VM which allows you to change certain settings.
First, list the current settings with:
hznAdminTool editproperty –list
Then, edit the property you would like to change. In my case, the “vim_username” was set to <username> and had to be edited to <username@domain>:
hznAdminTool editproperty –set=vim_username:<username@domain>
Then restart the configurator-tc service:
service configurator-tc restart
And we’re up and running again!
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
Secure your VMware View security server!
Recently, one of my customers had a security scan performed on the infrastructure and the result was that the VMware View security server was configured to support a couple of weak cipher suites. As it turns out, there is a VMware KB-article that describes how to configure the security server with SSL protocols and Cipher suites: Configure cipher suites and security protocols on a View Connection server instance or security server in View 4.5 and later.
How to solve this:
- Create a text-file called: locked.properties (Usually located in “c:\program files\VMware\VMware View\Server\sslgateway\conf\”)
- The locked.properties file should look like this:
secureProtocols.1=SSLv3
secureProtocols.2=TLSv1
enabledCipherSuite.1=SSL_RSA_WITH_RC4_128_MD5
enabledCipherSuite.2=SSL_RSA_WITH_RC4_128_SHA
enabledCipherSuite.3=TLS_RSA_WITH_AES_128_CBC_SHA
enabledCipherSuite.4=TLS_DHE_RSA_WITH_AES_128_CBC_SHA
enabledCipherSuite.5=TLS_DHE_DSS_WITH_AES_128_CBC_SHA
enabledCipherSuite.6=SSL_RSA_WITH_3DES_EDE_CBC_SHA
enabledCipherSuite.7=SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
enabledCipherSuite.8=SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
How do you know these are safe cipher suites that you can use? I found the following website and you can see that the Cipher suites mentioned in the KB-article are safe to use:
http://www.techstacks.com/howto/j2se5_ssl_cipher_strength.html
