Print-friendly Version

Setting Up a Demo Based on the Sun Virtual Desktop Access Kit for VMware

Dirk Grobler, March 2007 (Updated July 2007)

Abstract

Here is a cookbook for Sun Desktop Virtualization. The Sun Virtual Desktop Access (VDA) Kit for VMware is a set of small components that combines the Sun Desktop Access layer (Sun Ray Server Software [SRSS] and Sun Secure Global Desktop [SSGD]) with VMware's Virtual Infrastructure (VI) layer. This kit needs to be installed on various tiers of the virtualization solution, which makes the installation process quite complex and far from self-explanatory. This paper gives a step-by-step introduction on how to install a demo for the VDA Kit for VMware.

• Abstract
• Introduction
• Overview
• Installation
  • Setting Up VMware ESX
  • Setting Up Sun Ray Server
  • Setting Up Virtual Center
  • Setting Up the Virtual Desktop
  • Setting Up Secure Global Desktop
• Post Installation
• From Demo to Proof of Concept (POC)
• Troubleshooting
• References

Introduction

Setting up a demo to show the Sun Desktop Virtualization assets is a time-consuming task because it involves various layers of software that are complex in themselves. A guide that gives a clear overview on the required components, how they are installed, and how they are configured can be beneficial for someone who is new to the topic. However, this document presents only one possible setup. More options are definitely available, but this paper should get you started.

The goal here is not to explain the architecture and design of the VDA Kit. The Sun BluePrints publication Sun Virtual Desktop Access Kit for VMware covers both architecture and design in detail. This paper provides an overview of the demo architecture and the process for installing the demo. At the end of this paper, you will also get some hints on how to transfer the demo setup into a setup that can be used for a customer proof of concept (POC).

The intention of this document is to show how to create a small and self-contained demo. However, it includes various different products and technologies that need to work nicely together. To complete the demo successfully, you need knowledge about VMware Infrastructure 3, Sun's access tier, Sun Ray Server, Sun Secure Global Desktop, and finally, the fundamentals of Microsoft Windows XP deployment and remote connection. This sounds like a lot, and it really is. It is easy to get stuck during the installation process. Therefore, a detailed troubleshooting section has been added at the end of the document.

Overview

This paper attempts to keep the hardware required for installation as minimal as possible. The core of the demo installation is a Galaxy server, such as a Sun Fire X4100, X4200, or X4600 server. A Sun Fire X4100 server with two CPUs, 4GB RAM, and two hard disks should be sufficient. On this server, VMware ESX 3.01 or above needs to be installed. All other required services, such as Virtual Center, Sun Ray server, or Sun Secure Desktop server, are installed as Virtual Machines (VMs) inside ESX, in addition to the managed virtual desktops, of course. Figure 1 provides an overview of the intended setup.

Figure 1: Overview of Intended Setup
(Click to Enlarge)

The ESX server hosts all software services. It contains two virtual networks. One of them is connected with a physical network and is shared with the display clients (Sun Ray clients and a notebook). This virtual network can be set up easily with a physical switch. Instead of using a physical switch, you can connect the entities through a shared network. The Sun Ray Server Software/Sun Secure Global Desktop server and the Virtual Center server are connected through a virtual switch with the physical network. This connection is actually hidden in Figure 1. The physical network is responsible for the device communication with the desktop access tier. It can also be used to manage the Virtual Infrastructure.

The second virtual network is private to the ESX server and is not connected with a physical network. It connects Sun Ray Server Software/Sun Secure Global Desktop and the Virtual Center with all virtual desktops. The Sun Ray server is configured as the Dynamic Host Configuration Protocol (DHCP) server for this network. This private network handles the VDA communication. Requests from the VDA client to the VDA service are routed through this network. The Remote Desktop Protocol (RDP) communication also occurs within the private network.

Installation

Now that you have a rough overview of the intended demo setup, you can begin the installation procedure. If you do the installation from a shared network, make sure that you get at least four static IP addresses for the ESX server, the Integrated Lights Out Manager (ILOM), Sun Ray Server Software/Sun Secure Global Desktop, and Virtual Center. Also make sure that you have a dedicated license for Virtual Center.

Setting Up VMware ESX

Installing ESX

The installation of the ESX server is straightforward. The installation can be very simply invoked through the ILOM of the Galaxy server (such as a Sun Fire x4100 server). Make sure that you are using at least version 3.0.1. ESX is a Linux-based appliance. During installation you can safely rely on most of the suggested default settings. The only thing you should do right after installation is to open up ssh for accessing the machine later using a terminal.

Installing the Virtual Infrastructure Client

Once the system is set up, you should install the VI client. It is a Microsoft Windows application. It presents far more options to configure the system. So if you don't want to learn about all the command line tools, you should really use it. You'll need it anyway later for the Virtual Center. You can download the client through the web access interface, which can be launched by typing the IP address of the ESX server into your browser.

Setting Up the License for ESX

During the installation process, there is no need to provide the license. At the moment when you want to create a VM, you are reminded that you haven't provided the license for the system. Assuming you have not set up a license server yet, you need to use your license file. Within the VI client, select the Configuration tab and then under Software, locate the License Feature section. From this point on, setting up the license should be straightforward.

Configuring a Private Network

As explained in Overview, you need to set up a second private network for the VDA and RDP communication. You need to launch the Virtual Infrastructure client and connect it to the ESX server:

• Under the Configuration tab, invoke the Networking link.
• Click Add Networking.
• Select Virtual Machine as a connection type.
• Create a new vSwitch not connected to a vmnic (network adapter).
• Provide a new label such as "Private Network" and a unique ID (1).
• Click OK.

The new private network is created. Because the switch is not connected to an adapter, no communication will be routed into a physical network.

Setting Up Sun Ray Server

Setting Up the OS Image

The Sun Ray server, and later Sun Secure Global Desktop, need to be installed on the Solaris 10 Operating System:

• The image should be large enough to host both Sun Ray Server Software and Sun Secure Global Desktop (at least 8 GB).
• RAM should be around 1.5 GB.
• A single CPU should be enough.
• Two network interfaces (public and private) are needed.
• Both interfaces should be configured as static.

Installing the Sun Ray Server Software

The Sun Ray server and the Windows connector are installed in the typical manner.

Installing the VDA Client

• The VDA client is installed by extracting the VDA client archive to /opt.
• Download the appropriate xloadimage (XLI) package from the Sunfreeware.com web site. Here are the installation packages for:
  • x86 platform
  • SPARC platform
• Modify the /opt/sun-vda/bin/vda-kiosk.sh script:
  • Point to the XLI executable.
  • Point to the Virtual Center server (Static IP in Private Network).

Configuring CAM

• Configure the Control Access Mode (CAM) policy for card and noncard usage.
• Configure /opt/sun-vda/bin/vda-kiosk.sh as a critical application.
• Select /opt/sun-vda/bin/vda-kiosk.sh as the only application to run.
• Do a cold restart of the Sun Ray server.

Configuring Kiosk (applicable only for SRSS 4.x)

SRSS 4 introduces the Kiosk component, which replaces the Control Access Mode. The operation and configuration is quite similar. The only thing you need to add is a session descriptor in the kiosk configuration directory /etc/opt/SUNWkio/sessions/vda.conf. The session descriptor is a simple file, for example, called vda.conf, with the following content:

KIOSK_SESSION_EXEC="/opt/sun-vda/bin/vda-kiosk.sh"
KIOSK_SESSION_LABEL="VDA Kit Session"
KIOSK_SESSION_Description="Starts Virtual Desktop Access Kit sessions"
KIOSK_SESSION_PROTOTYPE=vda

Once this VDA session descriptor is written, it is picked up by the new Administration UI. The administrator can then simply select the VDA session.

Configuring DHCP for the Private Network

Configure the private network as a directly connected dedicated interconnect. Basically, the Sun Ray server will act as DHCP server for this network. Only the Sun Ray server and the Virtual Center server need to have static IPs in this subnet. You can set the configuration using the utadm -a pcn1 command. You can find more background information about the network configuration in the Sun Ray Server Software 3.1 Administrator's Guide.

Configuring the Primary Interface

You also need to configure the primary interface, but this step depends on whether the interface belongs to a shared subnet or a dedicated one.

Creating Demo Users

If the demo has no Network Information System (NIS) setup, you should create your demo users on the Sun Ray server and later on the Virtual Desktops.

Setting Up Virtual Center

Setting Up the OS Image

The Virtual Center service is installed on either Windows XP or Windows 2003. The OS will be installed as VM:

• The image should be at least 8 GB.
• RAM should be a minimum of 1 GB.
• A single CPU should be enough.
• Two network interfaces (public and private) are needed.
• Both interfaces should be configured as static.

Installing Virtual Center

• Install version 2.01 or above.
• The license file needs to be copied to the target VM before installation.
• Run the default installation procedure:
  • Create a local database.
  • Use your own license server.
  • Enable the web access.

Configuring Web Access for the VI SDK

The VDA service uses the VI Software Development Kit (SDK) for communication with Virtual Center. The communication is handled by the VMware Infrastructure SDK Web Service. The URL for accessing the VMware Infrastructure is protocol://localhost/sdk. The protocol can either be HTTP or HTTPS, depending on your specific security needs. For a demo, HTTP should definitely be sufficient, but the default is HTTPS.

To use the HTTP protocol to access to the Virtual Center Web Service, you must edit the configuration file.

Note: You should edit the configuration file only in a test or development environment. The configuration vpxd.cfg file is located at C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\vpxd.cfg.

The following steps are for configuring HTTP access:

• Locate the <proxyDatabase> tag within the <http> tag.
• Uncomment the following section for the SDK so that it looks like this afterward:

  <server id="1">
   <namespace> /sdk </namespace>
   <host> localhost </host>
   <port> -2 </port>
  </server>
  

• Remove the following redirect entry: <redirect id="1">/sdk</redirect>.
• Restart the VMware VirtualCenter Server service. This can be done by using the Services Control Panel Applet.

Setting Up the sysprep Tools

For Windows customization, you need to install the sysprep tools onto the Virtual Center server. The excellent VMware document, VirtualCenter 2 Templates Usage and Best Practices (pdf), explains this step. You can download the sysprep tools for Windows XP from the "Windows XP Service Pack 2 Deployment Tools" page on the Microsoft web site.

Configuring Virtual Center

• Switch to the "host/cluster" view.
• Create a new data center called Datacenter.
• Create a new cluster called Desktops. Enable the Dynamic Resource Scheduling (DRS) feature with the options "partially automated."
• Add the ESX server to the cluster.
• Point the ESX server to the VC licensing server (Configuration/License Features).
• Switch to the Inventory view.
• Create the folders Pool, Pool-Kiosk, and Pool-Static.

  These pools will be used by the VDA service, and they are the default pools preconfigured in the VDA service configuration vda.properties file. The names and the number of pools can be changed later, but they need to be reflected in the VDA service configuration.

• Create a customization definition under Edit/Customization Specifications:
  • You need to have a Windows XP Volume License Key.
  • Network settings can remain the same.
  • Other settings should be straightforward.

Note: When you change the naming of pools, the data center, or the cluster, you need to understand the internal structure and hierarchy as it is used in the VI SDK. The top-level node is typically a data center. Underneath, you have a subtree for hosts (host) and a subtree for VMs (vm). The host subtree contains hosts or cluster of hosts. The vm subtree contains subtrees of VMs or VMs themselves. For example, the static pool has the path /Datacenter/vm/Pool-Static and the cluster has the path /Datacenter/host/Desktops.

Creating the Golden Image

Perform all the procedures in the Setting Up the Virtual Desktop section and then finish the rest of the procedures in this "Setting Up Virtual Center" section.

Creating a Template for Deployment

The template can be created through the default commands within the Virtual Infrastructure Client. Once created, the template will seed the Virtual Desktop population.

Installing and Configuring the VDA Service

• Install the VDA Service in c:\sun-vda.
• Adjust the configuration file (conf\vda.properties):
  • Set the connection password.
  • Point the configuration to the deployment template.
  • Point the configuration to the customization template.

• Check the configuration file: c:\sun-vda\bin\vda-service test.

  A proper configuration is indicated through the following output: The configuration appears to be correct.

  Note: This test is not perfect. It misses a number of misconfigurations:

  • Property Pool.Customization0 .. n: If this setting is not pointing to a valid customization specification, Virtual Desktops will not be created automatically. If you don't already have a customization spec defined, you can leave these entries empty also and populate them later.
  • Pool.Path0..n: This setting must point to a valid folder. If this is not the case, for example, it points to a virtual machine, this will not be detected by the test procedure.
  • Pool.Template0..n: This setting must point to a valid virtual machine template. If this is not the case, for example, it points to a folder, this will not be detected by the test procedure.

  Note: A warning message about being unable to find required classes and about attachment support being disabled will be printed in addition to the test result. You can safely ignore this warning message. However, you need to investigate any message about not being able to connect to the VI service. Such a message is likely caused by an error in the SDK URL setup. Check that you're using the right protocol, that the protocol is enabled in the SDK (see Configuring Web Access for the VI SDK for details), and that you've provided the proper user name and password in the vda.properties file.

• Register the service in c:\sun-vda\bin\register-vda-service.bat. The service should thereafter be up and running. It will start creating new Virtual Desktops after a short period of time.

  Note: Each change of the VDA service configuration requires a restart of the service.

  Note: Once the VDA service is running, it starts automatically the cloning of Virtual Desktops for the dynamic pools. If this is not the case, then you have no dynamic pools defined, or Virtual Desktops have already been created, or you have misconfigured the service.

Setting Up the Virtual Desktop

Setting Up the OS Image

Use Windows XP SP2:

• The image should be as small as possible (4 GB), because the image size impacts system performance.
• RAM should be also as small as possible (between 256MB and 384MB).
• A single CPU should be enough.
• One network interface (private), which is configured for DHCP, is needed.
• Options/VMware Tools: Make sure that scripts for suspend and resume events are executed. They are mainly responsible for releasing and renewing IP addresses.
• Options/Power Management: Make sure that the VM suspends when a Standby by the guest OS is initiated. This action will fully suspend the machine and not keep it somewhat awake.
• In order to avoid freezing of RDP sessions when the administrator actually initiates a suspend, make sure that the suspend script does include a line for tsdiscon.exe. The tsdiscon.exe command disconnects all connected RDP clients.

  Caution: Each new release of VMware Tools overwrites the scripts, which is not nice.

Configuring Power Management

The Power Options for Windows XP have quite an important role. They control the suspend behavior of the VM. Power Options can be found in the Control Panel. You have to define the StandBy Time to the best suitable value.

Note: The StandBy Time is a machine setting and can be set only by the administrator of the machine. Controlling this setting for each individual box could be quite tedious and error prone. Using Group Policy in a deployment dependent on Microsoft Active Directory (AD) would be great, but there are no such Group Policy Objects (GPOs) for Power Options. A couple of vendors have addressed this as an addition to the Windows default Group Policy. A free Terro Novum tool called EZ GPO allows you to control the Power Options using GPO. Setting the StandBy Time setting as a local or central GPO through AD gives the most reliable results.

Installing the VDA Tools

• Extract the VDA tools to c:\sun-vda.
• Register the service by executing the command c:\sun-vda\bin\register-vda-tools.bat.

Creating Demo Users

• If you are not connected to AD, you need to place the users locally.
• Enable remote access for the demo users.

Creating a Template for Deployment

This template will seed the Virtual Desktop population.

Setting Up Secure Global Desktop

Installing Sun Secure Global Desktop

Install Sun Secure Global Desktop onto the Sun Ray server in the usual manner.

Configuring VDA Client

• Copy the VDA expect script into the standard Sun Secure Global Desktop directory:

  cp /opt/sun-vda/bin/vda-wcpwts.exp
  /opt/tarantella/var/serverresources/expect
  

• Modify the script so that it points to the right vda-client in the /opt/sun-vda/bin/i386 subdirectory.

Configuring Desktop Access With the Object Manager

• Launch the Webtop as root.
• Configure a host that points to the Virtual Center in the private network.
• Configure a Windows application:
  • Set the host with the previously configured one.
  • Define the application as not resumable.
  • Set the login script to vda-wcpwts.exp in the Advanced Settings.
• Assign the application to all users.

Post Installation

Once you have gone through all the installation steps, take a deep breath and cross your fingers. Ideally, it should now be possible to launch the newly created Virtual Desktops either through Sun Secure Global Desktop or Sun Ray Server Software. You can test doing that with your Sun Ray client or the laptop. There are a few other things to consider:

Implementing Hotdesking Between Sun Ray Server Software and Sun Secure Global Desktop:

Hotdesking between both worlds will be possible if the same identifiers (namely the user ID) are used. Hotdesking requires you to assign a couple of smartcards with the IDs of the demo users, which can be done through the Sun Ray Administration UI. Once this is done, Virtual Desktops are requested with the user ID instead of with the smartcard token ID.

Starting and Defining Static and Dynamic Virtual Desktops:

Once you feel more familiar with the architecture, you can start and define static desktops (by moving VMs into the folder called Pool-Static and naming them after a certain users). You might also want to define a different behavior for the smartcard and the nonsmartcard scenario. You can do that by using different Golden Images.

From Demo to Proof of Concept (POC)

This architecture is quite small. It serves only a limited number of desktops. However, even for a small POC, this architecture might be quite sufficient. Here are the things you definitely need to rework:

• The Golden Image: You need to use one from the customer.
• The user setup: The users are probably set up as domain users with network profiles.
• The Virtual Desktops: These probably participate in a shared network instead of a private one, and they probably need to join a Windows NT or AD domain. These attributes can be defined through the sysprep tools.
• And there are certainly some other things specific to the customer...

Troubleshooting

You've run various setup steps and might still not see the desired result: a running demo. Here are a couple of troubleshooting hints.

Virtual Desktops are not automatically created by the VDA Service:

There are a couple of reasons why this might fail:

• Web service access is not configured correctly. Check if vda-service test returns The configuration appears to be correct.
• Service configuration is incorrect (vda.properties).
  • Check if vda-service test returns The configuration appears to be correct.
  • Make sure your system preparation information is correct.
  • Make sure the pointers to templates and folder are correct and point to the right objects.

Virtual Desktops are created automatically, but they stay in the factory:

• Check that you still have enough disk space for your Virtual Desktops. Before a newly created Virtual Desktop is moved out of the factory, a snapshot is taken, and this requires sufficient disk space.
• Check that the RDP port is open and accessible on the Virtual Desktop. Before a newly created Virtual Desktop is moved out of the factory, the VDA service verifies whether RDP communication can be established to the Virtual Desktop. A couple of issues might prevent a successful test:
  • The Virtual Desktop is on a private network and cannot be accessed by the VDA Service. Check the network configuration of your Virtual Center server.
  • Remote access is disabled on the Virtual Desktop.
  • Firewall settings of the Virtual Desktop do not allow RDP connections.

Sun Ray Desktop Unit is cycling and cannot connect to a Virtual Desktop:

• Check if the vda-client call returns. If not:
  • Check if the IP address of the VDA Service instance is set correctly in the vda-kiosk.sh script.
  • Check if the VDA service is up and running and fully operational.
  • Check if the firewall on the host that runs the VDA Service is not blocking the VDA Service port (3809).
• Check if the VDA client returns a valid IP address. If not:
  • Check if a Virtual Desktop is available for use.
  • Check if a Virtual Desktop was started for the request and has a valid IP address. If not:
    • Check if VMware tools are installed on the Virtual Desktop.
    • Check that the Virtual Desktop is not configured for WakeupOnLan. Look up the Virtual Machine configuration (Options/Power management). Make sure that 'Suspend the Virtual Machine' is selected.
  • Check if the RDP port is open to the VDA Service (see above):
    • Remote Access is enabled on the Virtual Desktop.
    • Firewall settings of the Virtual Desktop do allow RDP connections.
• Sun Ray Windows Connector cannot access a Virtual Desktop: Check if the Sun Ray Windows Connector is fully configured.

Users can't log in to Windows XP:

• Check if the demo users are set up on the Virtual Desktop.
• Check if demo users are allowed to perform a remote connection to the Virtual Desktop.

Unused Virtual Desktops do not suspend:

• Check if the Power Options on the Virtual Desktop have been configured for standby.
• Check if the VDA Tools are installed and running on the Virtual Desktop.
• Check if the virtual machine is configured for Suspend. Look up the Virtual Machine configuration (Options/Power management). Make sure that 'Suspend the Virtual Machine' is selected.

  Note: If you experience problems with the standby feature in Windows XP, you might try EZ GPO, which includes a group policy for power options.

Virtual Desktops get unresponsive after a couple of hours:

Check if your Virtual Desktops run at least Windows XP SP2. In previous versions, there was a bug in the terminal services implementation.

You can't create a customization specification for Windows:

Make sure you have installed the sysprep tools in the right location on Virtual Center. On systems using a non-English locale, the location for the sysprep tools might not be found. This is due to a bug in Virtual Center. Use the English locale path instead. (Note: Type this all on one line.)

C:\Documents and Settings\All Users\Application Data\ /
VMware\VMware VirtualCenter\sysprep\xp

If the VDA service does not automatically create new instances of Virtual Desktops, make sure that the name of the customization specification matches the name in your VDA service configuration (vda.properties).

References

• Sunfreeware.com web site
• Network configuration chapter of the Sun Ray Server Software 3.1 Administrator's Guide
• VMware Infrastructure SDK Programming Guide (pdf)
• VMware Virtual Center 2 Templates Usage and Best Practices document (pdf)
• Microsoft sysprep tools for Windows XP
• Free Terra Novum EZ GPO tool for power management

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.