VIrtual Desktop Upcoming Blogs

1. Thin Client comparisons and performance (Wyse P20, Wyse R50L, Samsung NC190 and HP 5745) using Teradici'sPC-over-IP protocol from VMWare View 4.5 deployments
2. User persona management best practice's (Appsense, LiquidWare Profile Unity, ScriptLogic, Windows 2008 Roaming Profile Management)
3. Printer Controls through Golden Image deployments
4. ThinApp configuration and performance results in View 4.5

VMWare vCenter 4.1 Upgrade Notes - Ran into this one the other day as well

URL For furtner information:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1026688

VMware VirtualCenter Server service fails after upgrading to vCenter Server 4.1

Symptoms

• The VirtualCenter Server service fails after upgrading to vCenter Server 4.1.
• You see this error in the vpxd logs:
  
  Panic: Win32 exception: Access Violation (0xc0000005)
     Read (0) at address 0000000000000098
     rip: 000000014071edcc rsp: 000000000419c700 rbp: 000000000419e160
     rax: 000000000419c7a8 rbx: 0000000000000018 rcx: 0000000000000020
     rdx: 000000000419c798 rdi: 0000000000000000 rsi: 000000000e8667b0
     r8:  000000000419c7a8 r9:  000000000cab1eea r10: 0000000002d27fd0
     r11: 000000000419c750 r12: 0000000007279700 r13: 0000000007279740
     r14: 00000000032edeb0 r15: 0000000000000004
  
  Note: For more information about the vpxd logs, see vpxd log directory path when vCenter Server 4.0 is installed on Windows Server 2008 (1011938).
  
• In vCenter Server 4.0, operations such as Inventory > Search fails. The vws.log file truncates with a Chunked stream ended unexpected error
• In vCenter Server 4.1, vCenter 4.1 fails immediately after it is started and the vpxd-*.log shows an ASSERT fails at one of the following:
  • ASSERT d:/build/ob/bora-258902/bora/vpx/vpxd/util/vpxdDbLoad.cpp:1059
  • ASSERT d:/build/ob/bora-258902/bora/vpx/vpxd/util/vpxdDbLoad.cpp:1066

Resolution

This issue is caused by corrupt entries for the virtual machine in the vCenter database.

Caution: This article deals with SQL database operations. Before proceeding, ensure that you are familiar with database concepts and that you have adequate backups.

 

To avoid encountering this issue:

1. Download the appropriate script for your environment. The scripts are attached to this article (located in the Attachments section at the bottom of this article).
2. Unzip the scripts.
3. Run the scripts on vCenter Server 4.0 database.
   
   Note: The SQL query must be run with fully qualified database table names. If you have multiple database instances, there may be a need to qualify the tables with the db-instance name and the db-owner name. For example, VPX_VM_CONFIG_INFO in the query should be changed to <DB_NAME>.<DB_OWNER>.VPX_VM_CONFIG_INFO.
   
4. If no result are returned, you can continue with the upgrade
   
   If any virtual machines are reported with inconsistent data, remove and re-register the affected virtual machines.
   1. Power off the virtual machine.
   2. Right-click the virtual machine and choose Remove from inventory.
   3. Click Yes to remove the virtual machine.
   4. Browse to the datastore where the virtual machine is stored.
   5. Right-click the .vmx file for the virtual machine, choose Add to inventory, and follow the on-screen wizard.
      
5. Continue with the upgrade.

If you have upgraded to vCenter Server 4.1 and the server keeps failing:

1. Roll back to vCenter Server 4.0. Connect vCenter Server 4.0 to the backup database.
2. Run the downloaded scripts on the vCenter Server 4.0 database.
   
   Note: The SQL query must be run with fully qualified database table names. If you have multiple database instances, there may be a need to qualify the tables with the db-instance name and the db-owner name. For example, VPX_VM_CONFIG_INFO in the query should be changed to <DB_NAME>.<DB_OWNER>.VPX_VM_CONFIG_INFO.
   
3. Find out if virtual machines are reported with inconsistent data.
4. Install vCenter Server 4.0 against the database backup.
5. Through the vSphere Client, remove and re-register the virtual machine.
   1. Power off the virtual machine.
   2. Right-click the virtual machine and choose Remove from inventory.
   3. Click Yes to remove the virtual machine.
   4. Browse to the datastore where the virtual machine is stored.
   5. Right-click the .vmx file for the virtual machine, choose Add to inventory, and follow the on-screen wizard.
      
6. Re-try the upgrade.

Note: If you experience the issue even though the script returned no virtual machines, this may be a new issue that has not been reported to VMware. Please contact VMware Support, with vCenter support information and a backup of the database for further review by VMware.

Additional Information

The error Win32 exception: Access Violation can occur for many issues. For other issues that generate this error, see:

• VMware VirtualCenter Server service fails after upgrading to vCenter Server 4.1 in an environment configured with Nexus 1000v (1026009)
• Cannot cold migrate a Virtual machine - vCenter service dump - Win32 exception: Access Violation (0xc0000005) (1014778)
• Virtual Center service crashes frequently (1016837)

Attachments

• getinconsistentvminfo_mssql.zip
• getinconsistentvminfo_oracle.zip

VMWare View 4.5 Information - Debug for Networking Server 2008 Firewall

When installing VMWare View manager on Windows 2008 STD, you will need to disable firewall or make sure all the neworking ports are open related to View. ALthough View tries to open the ports, 4001 and 8009 are still blocked. Below is some information regarding testing out the ports from the Base Windows 7 image and the VIew Manager on WIndows 2008.

 

Connecting to the virtual desktop from the VMware View Client fails with the error: Virtual Desktop in not available

Symptoms

• Connecting to the virtual desktop from the VMware View Client fails
• You see the error:
  
  Virtual Desktop is not available
• When viewing the virtual desktop in the View Admin console in Desktop Sources View, the virtual machine status shows as:
  
  Waiting for Agent

Resolution

This issue may occur if:

• The Agent is not installed or if the version is not the same as the Connection Server.
• The virtual desktop cannot communicate with the Connection Server over port 4001.

To resolve this issue, ensure that the Agent is installed and that the version is the same as the Connection Server.

 

If installing the correct version of the Agent does not resolve this issue, verify that the Virtual Desktop can communicate to the Connection Server over port 4001.

 

Ports required from Client to Agent without Security Server are:

• 3389 - RDP  
• 50002 - PCoIP 
• 4001 -JMS

Port required from Client to Agent with Security Server is: 

• 80 - HTTP & 443 to Security Server

 To verify that the virtual desktop can communicate to the Connection Server over port 4001:

1. Click Start > Run, type cmd, and click OK.
2. Run this command to perform a netstat on the Virtual Desktop:
   netstat -an
   If there is a connection between the local address and the Connection Server, the output looks similar to:
   Proto Local Address                    Foreign Address                   State
   TCP   "IPOfVirtualMachine:random Port" "IP of the Connection Server:4001 ESTABLISHED
   -------------------------------------------------------------------------------
   Note: Connectivity can be also tested by performing a netstat on the Connection Server. In this case, the output looks similar to:
   Proto Local Address                     Foreign Address                  State
   TCP   "IP of the Connection Server:4001 "IPOfVirtualMachine:random Port" ESTABLISHED
   -------------------------------------------------------------------------------
3. Run this command to test if the port is open and accessible from the virtual desktop:
   
   telnet <ipaddress> 4001
   
   If you receive a connection error, check for a firewall enabled on the virtual desktop, Connection Server, or in the network infrastructure between the two points.

VMWare View Networking Ports and Related information

To allow external client devices to connect to a security server within the DMZ, the front end firewall must allow inbound traffic on TCP ports 80 and 443. To allow the security server to communicate with each standard or replica server that resides within the internal network, the back-end firewall must allow inbound traffic on TCP port 8009 for AJP13-forwarded Web traffic, TCP port 4001 for Java Message Service (JMS) traffic, and TCP port 3389 for RDP traffic

Behind the back‐end firewall, internal firewalls must be similarly configured in order to allow the View Manager desktops and View Connection Server instances to communicate with each other. Port 3389 (RDP) is used for traffic originating from a standard or replica server that is directed at a guest system. Port 4001 is used for JMS traffic originating from either the View Agent component installed on each View Manager desktop or from a security server in the DMZ, and is directed at standard or replica View Connection Server instances.

View 4.x	902	TCP	View Client/View Client with Offline Desktop	ESX Host	(Optional) View Client with Offline Desktop data is downloaded and uploaded through this port.
View 4.x	3268	TCP	View/VDM Connection Server/View Manager	Active Directory Server	Global Catalog Server
View 4.x	3269	TCP	View/VDM Connection Server/View Manager	Active Directory Server	Global Catalog Server
View 4.x	3389	TCP	Thin Client	ESX host	RDP Protocol
View 4.x	9427	TCP	View Client/View Client with Offline Desktop	View Agent (Virtual Desktop)	(Optional) Multimedia Redirection (MMR). MMR is support by View Client and View Client with Offline Desktop on certain operating systems.
View 4.x	18443	TCP	View Connection Server/View Manager	vCenter Server	View Composer
View 4.0.x	50002	TCP/UDP	View Agent (Virtual Desktop)	View Client	PCoIP (AES 128-bit encryption) Port 50002
View 4.0.x	50002	TCP/UDP	View Client	View Agent (Virtual Desktop)	PCoIP (AES 128-bit encryption) Port 50002
View 4.5.x	80/443	TCP	View Client	View Transfer Server	http(s) access by View Client with Local Mode
View 4.5.x	902	TCP	View Connection Server	ESX Host	View Client with Local Mode data is downloaded and uploaded through port 902. If you intend to use View Client with Local Mode, port 902 must be accessible to your ESX host
View 4.5.x	902	TCP	View Transfer Server	ESX Host	Publishing View Composer packages for Local Mode
View 4.5.x	4001	TCP	View Connection Server	View Transfer Server	Required by JMS for Local Mode
View 4.5.x	4172	TCP/UDP	View Agent (Virtual Desktop)	View Client	PCoIP (AES 128-bit encryption)
View 4.5.x	4172	TCP/UDP	View Client	View Agent (Virtual Desktop)	PCoIP (AES 128-bit encryption)

VMWare View 4.5 Information - Setup Windows 7 Base Images

More useful info on setting up Windows 7 Desktops in a View environment:

Bypassing KMS license activation performed by View Composer on Windows 7 and Windows Vista operating systems.

Details

By default, the View Composer QuickPrep process uses Microsoft Key Management Service (KMS) to activate Windows 7 and Windows Vista guest operating systems. To make sure that View Composer properly activates the operating systems on linked-clone desktops, you must use KMS license activation on the parent virtual machine.

QuickPrep does not use other volume activation methods such as Multiple Activation Key (MAK) licensing.

CAUTION: View Composer does not support MAK license activation. Use MAK license activation at your own risk. For example, each recompose operation can increase the MAK license count, which can result in the unexpected depletion of MAK licenses.

Solution

You can activate licenses for MAK clients or bypass license activation altogether by setting registry values on the parent virtual machine. You might want to bypass license activation if you intend to install a trial license on a parent virtual machine.

To enable QuickPrep to activate licenses for MAK clients:

1. In the guest operating system on the parent virtual machine, start the Windows Registry Editor and navigate to the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmware-viewcomposer-ga
2. Navigate to the AllowActivateMAKLicense registry value. The default value is 0.

3. Set the value to 1.

To bypass license activation altogether:

1. In the guest operating system on the parent virtual machine, start the Windows Registry Editor and navigate to the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmware-viewcomposer-ga

2. Navigate to the SkipLicenseActivation registry value. The default value is 0.

3. Set the value to 1.

View 4.5 Events Database Configuration

The Events database is a new feature in View 4.5. The concept is very nice to save off all the events in a seperate database that can be used to scan via custom software applications. However, the setup can be a little tricky and time consuming. The below link has some good information to help out those who may be struggling getting this configured correctly

http://communities.vmware.com/message/1609625

Enjoy!!

View 4.5 Stuff

Community,

Now the fun stuff. When deploying the VMWare View environemnt please understand your need to do your homework. Server, Networking and Storage are all critical components. Server virtualization is the "Virtualization for Dummies" roadmap. Anyone with any IT experience can do server virtualization. Engineering for perfomance and optimization is my forte and must be defined, engineered and integrated.

With that said, please review the folliwing links and get back with me.. This is the homework assigments for VMWare View guys:

http://communities.vmware.com/message/1265174
http://www.vmware.com/support/product-support/view/
http://www.vmware.com/pdf/view45_architecture_planning.pdf


Enjoy!!!

Dave

And now the good stuff....

VMWare View 4.5 Information - Pilot to Production roadmap

Community,

Server virtualization is for the old guys. Desktop virtualization takes the virtual environment and inject streriods into it...(Not to back Barry Bonds).

Anyway,

Some links that will help you out...
http://communities.vmware.com/message/1265174 (just incase you run into this)
http://www.vmware.com/pdf/view45_architecture_planning.pdf
http://www.vmware.com/pdf/view45_installation_guide.pdf

VMWare View 4.5 Deployments

This is the first of many posts coming on VMWare View 4.5 deployments. First, some background around this Blog site and my history around Virtual Desktop architectures.

1) I have been working on the display rendered Virtual Desktop (New age VDI) for the past 4 years.
2) I have deployed VMWare View 2.x to 4.5 at this point
3) I have deployed XenDesktop 2-4 (not too successfully)
4) I have published several white papers that I will post discussing architectures and best practices, that VMWare and Citrix does not let you in on:)

So, with that said, I have been in the process of building several 100+ VDI deployments around View 4.5. (Since most of the VDI deployments these days are still pilots and not too many in production...the technology is now finally ready for prime time)

The foundation of these deployments is the focus on user profiles and not so much on the architecture. I strive to have a architecture that is manageable, scalable, reproducible and predictable (sorry Citrix XenDesktop). The big question comes down to cost. For a 1000 seat VDI deployment, the overall cost is about $700K, or $700 per desktop. That is about the same for traditional physical desktops. However, I can support 1500-3000 (even more on the academic model) users for 1000 virtual desktops, single golden image, end user profile management, follow me desktops, kick ass security and 1 full time engineer to support environment!!!!.

Intrigued? Stay tuned for more since it is very late tonight and I will be posting several documents, blogs, etc around this technology.

Later,

Superdave