VMware Horizon 7 v 7.6 Technical What's New Overview

VMware End-User Computing (EUC) solutions empower the digital workspace by simplifying app & access management, unifying endpoint management & transforming Windows delivery. To learn more visit Digital Workspace Tech Zone at https://techzone.vmware.com

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:
 
  DEBUG getSessionForApplication, userDn: , appMap: {=, [...], allowFallback=false, [...]}

How to use VMware Horizon View Multi VLan

With the release of VMware Horizon View 5.2, the functionality made ​​available that allow to create an automated pool where multiple VLANs to be linked. The administrator can use multiple network labels to a linked-clone virtual machine or an automated pool containing full virtual machines. Multi VLAN configuration is performed with PowerCLI from the View Connection Server. Functions are used from the PowerCLI for vSphere, so these need to be installed to.

Before a virtual machine as a golden image can be used within a multi-VLAN configuration. The hardware version of the virtual machine to version 9 be amended. Within hardware version 9, the functionality is present which is required for the use of the functionality.

There are different steps to create the the automated pool. The first step is exporting the availabele VLans for the golden image. The exported file needs to be configured and will be used for creating the Horizon View Pool.

Export Configuration

To create an export of the used VLans of the golden image, the following command is used for the export of the golden image configuration. When exporting the settings for a full cloned virtual machines, the command Export NetworkLabelSpecForLinkedClone need to be replaced with Export-NetworkLabelSpecForFullClone:

Export-NetworkLabelSpecForLinkedClone `
-vc_id "7d87df91-bf73-47b3-b01a-f54214e6ff61" `
-clusterPath "/myresourcepool/host/Cluster1/" `
-parentVMPath "/myresourcepool/vm/Win7-Parent" `
-parentSnapshotPath "/Win7-Parent/snapshot" `
-maxVMsPerNetworkLabel 5 `
-networkLabelConfigFile "C:/Win7.txt"

The vc_id identifies the vCenter Server. To obtain the vCenter ID, the following command can be used:

Get-ViewVC | select vc_id

The following output is displayed

vc_id
-----
7d87df91-bf73-47b3-b01a-f54214e6ff61
c0ed93c8-c5b5-42d1-aeed-99764921d29c

Edit Export file

The exported file needs to be edited before used for creating the View Pool.

#Network Label Configuration Spec

#WARNING! Setting enabled flag to false will
#turn off the automatic network label assignment
#for newly provisioned desktops.
enabled=true

#Parameter Definition for NIC
nic1=Network adapter 1

#Parameter Definition for Network
network01=vlan10
network02=vlan20
network03=vlan30

#Network Label Attribute Definition
#Expected format:
#..maxvm=

nic1.network01.maxvm=5
####nic1.network02.maxvm=5
nic1.network03.maxvm=5

Within the configuration file, the different VLans availabele for the golden images are shown. A VLan can be selected by removing the #### before the line.  In the above example, the used VLans are set network01 and network03, the maximum used IPs witin the VLan is maximized to 5.

Create View Pool

The exported configration file from the previous step will be used for the creation of the Horizon  View pool. The following command can be used:

Add-AutomaticLinkedClonePool -Pool_id -displayName "" -NamePrefix "-{n:fixed=3}" -Vc_id 7d87df91-bf73-47b3-b01a-f54214e6ff61 -Persistence NonPersistent -VmFolderPath "/myresourcepool/vm/" -ResourcePoolPath "/myresourcepool/vm" -ParentVmPath "/myresourcepool/vm/Win7-Parent" -ParentSnapshotPath "/Win7-Parent/snapshot" -DatastoreSpecs "[Moderate,OS,data]/myresourcepool/host/VMFS01” -Composer_ad_id 12232fbf-1dbd-42e5-84dd-f18848e5bcf5 -UseUserDataDisk $false -UseTempDisk $true -MinimumCount 1 -MaximumCount 5 -HeadroomCount 2 -PowerPolicy AlwaysOn -SuspendProvisioningOnError $true -NetworkLabelConfigFile "C:/Win7.txt"

The composer_ad_id parameter specifies the ID of the View Composer domain. To obtain the Composer id the following command can be used:

Get-ComposerDomain | select composer_ad_id

The following output is displayed

composer_ad_id
--------------
12232fbf-1dbd-42e5-84dd-f18848e5bcf5
a7e97ac8-1c61-4a41-8bd6-666a7e2eda17

The Horizon View pool is created and will start provisioing the linked clones. Additional configuraton steps can be made after creation of the pool.

VMware View 4.0 (with software-only PCoIP)

Last week VMware finally released the much awaited View 4.0, which supports vSphere 4.0 and introduces the software-only version of the Teradici remote desktop protocol PCoIP.



VMware is offering two versions of View 4: Enterprise (which includes vSphere and View Manager 4.0), priced at $150 per concurrent user, and Premier (which also includes View Composer and ThinApp), priced at $250 per concurrent user.



Of course the key aspect of this release is how well PCoIP performs on LAN and WAN scenarios.
Unfortunately the product will be available for download on November 19, so for now it’s impossible to make a performance analysis and comparison with Microsoft RDP 7, Citrix ICA/HDX and the other tens of alternatives that are flooding the VDI market.



The major problem with PCoIP is if its performance is so great to justify the adoption of a new proprietary remote desktop protocol at its 1.0 release (the protocol is more mature than that but so far relied on hardware components).
Many customers may want to be careful here, mostly considering that VMware and Teradici just have a co-development agreement, which is not even exclusive.
What happens if Teradici is acquired by a VMware competitor or if the company suffers major issues?
And most of all, what happens if one year from now VMware consider this protocol unpractical and too expensive to optimize and decides to replace it, for instance, with the just ratified Net2Display standard?

Anyway a lot has been already said.

Brian Madden already published a brief FAQ list, which includes a couple of interesting details:

* The PCoIP client only supports Windows at the moment. Linux and Mac OS versions are expected next year
* View 4.0 will fully support Microsoft Windows 7 as guest OS in early 2010

Chad Sakac already published a blueprint to design a View 4.0 architecture with the recently announced VMware/Cisco/EMC hardware called VBlock.
The solution (a VBlock 1) fits over 2,048 virtual desktops and costs $750 per seat all inclusive:



The paper includes some performance analysis. It doesn’t clarify if the numbers are obtained when using the RDP or the PCoIP protocol (assuming this will make any difference) but it’s really worth a check.


Update: With some delay VMware finally released the bits of View 4.0 (build 210939).
To install it you first need to update vSphere 4.0 with Update 1 (build 208156), released Nov. 19, 2009.

Source: virtualization.info

virtual machine with input specifications already exists

While in the progress of deploying new virtual machines the deployment of a virtual machine stopped in one particular pool. After doing some investigation the viewcomposer log gives me the following message:

Violation of UNIQUE KEY constraint 'IX_SVI_SIM_CLONE_GUEST_NAME'. Cannot insert duplicate key in object 'dbo.SVI_SIM_CLONE'

I created a support call with VMware, the responses I got where remove those particular record from the database. Removing those records didn’t solved the problem, cause those records were written in different tables, so we created a query which does the trick for us.

Doing a search first, so we know which records will be deleted:

# Finding VM from VM_NAME and BASE_DISK key

SELECT * FROM SVI_SC_BASE_DISK_KEYS

where PARENT_ID = (SELECT ID FROM SVI_SIM_CLONE

WHERE (VM_NAME = ''))

SELECT * FROM SVI_SIM_CLONE

WHERE (VM_NAME = '')

When I know which records will be removed I used the following query to actually remove the records:

# delete VM from VM_NAME and BASE_DISK key

delete from SVI_SC_BASE_DISK_KEYS

where PARENT_ID = (SELECT ID FROM SVI_SIM_CLONE

WHERE (VM_NAME = ''))

delete FROM SVI_SIM_CLONE

WHERE (VM_NAME = '')

After actually removing the faulty records i was able to deploy new virtual machines again.

Distributed Power Management on x3850

While working at a customer site I have been working on setting up Distributed Power Management, DPM is an experimental feature delivered through VMware ESX 3.5 and vCenter 2.5. While having some problems with the configuration I had two goals. I wanted to keep redundancies within the current configuration and wanted to comply to the goals of the customer, which was as Green as possible.

To get the redundancy I created a single vSwitch with two portgroups one for the Service Console and one the VMotion port, with each a difference VLANs configured. At both portgroup an active physical NIC was attached which was standby on the other portgroup. My first goals was reached.

To get the second goal I selected the first internal NIC at the ESX host and configured this one attached to the VMotion portgroup. Within the portgroups I configured the auto negotiation as on the Cisco switch to. The reason for this is that is that the used NIC only support wake-on-LAN at 10 or 100 Mbit and not at 1 Gbit.

More info can be found at the following URL: http://tinyurl.com/r8bwth