VDA Cookbook

From Sun Ray User Group Wiki

Jump to: navigation, search



The Virtual Desktop Access Kit is a set of small components. It needs to be installed on various tiers of Sun Virtualization Solution, which makes it quite complex. Combined with the the installation and configuration of the Virtual Infrastructure layer as well as the desktop access layer (SRSS and SSGD) it is a major task, far from being self-explanatory. This paper gives a step-by-step introduction on how to install a demo for the VD Access Kit for VMware.


Setting up a demo for showing Sun's Desktop Virtualization assets is a time consuming task, especially if the skill set is more around Sun Ray and SSGD and not about the Virtualization Infrastructure as provided by VMware. Having a guide that gives a clear overview on what are the required components, how they are installed and how they are finally configured can be beneficial for someone who is new to the topic. However, this document presents only one possible setup. There are definitely more options. As said, this paper should get you started.

This paper will not explain the architecture and design of the VDA Kit, here a more detailed paper from Sun can be expected. In the following chapter you get an overview of the demo architecture and the process of the demo installation. At the end you will also get some hints on how to transfer the demo setup into a setup, that can be used for customer proofs of concept.


It is intended to keep the hardware requirements as minimal as possible. Core of the demo installation is a Galaxy server. Already a x4100 with 2 CPUs, 4GB RAM and 2 hard disks should be sufficient. On this server ESX 3.01 or above needs to be installed. All other required services like Virtual Center, Sun Ray Server or Sun Secure Desktop server are installed as Virtual Machines inside ESX, in addition to the managed virtual desktops of course. The illustration below gives a better overview of the intended setup:


The ESX server hosts all software services. It contains 2 virtual networks. One of them is connected with a physical network and is shared with the display clients (Sun Rays and a notebook). It can be easily setup with a physical switch. Instead of a physical switch the entities can also be connected through a shared network. The SRSS/SGD server and the Virtual Center server are connected through a virtual switch with the physical network. This is actually hidden in the illustration. 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 other network is private to the ESX server and is not connected with a physical network. It connects SRSS/SSGD and the Virtual Center with all virtual desktops. The Sun Ray server is configured as the DHCP server for this network. This private network handles the VDA communication. Requests from the VDA client to the VDA service is routed through this network. The RDP communication is also happening within the private network.


After getting a rough overview of the intended demo setup the installation procedure can begin. If you do the installation from a shared network, make sure that you get at least 4 static IP addresses for the ESX server, the ILOM, SRSS/SGD and Virtual Center. Also make sure that you have a dedicated license for Virtual Center.

Setup ESX

  • Installing ESX:

The installation of the ESX server is straight forward. The installation can be very simply invoked through the ILOM of the Galaxy server. Make sure that you are using at least version 3.0.1. ESX is an appliance based on Redhat. During installation you can safely rely on most of the default settings suggested. The only thing you should do right after installation is to open up ssh for accessing the machine later via terminal.

  • Installing the Virtual Infrastucture Client:

Once the system is setup, you should install the Virtual Infrastructure client. It is a 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, and anyway you'll need it later for the Virtual Center. You can download the client through the web access interface, which can be simply 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 virtual machine, you are kindly reminded that you haven't provided the license for the system. Assuming you have not setup a license server yet, you need to use your license file. Within the VI Client you need to select the configuration tab and then under Software you find the section License Feature. From there on it should be straight forward.

  • Configuring a Private Network:

As explained with the illustration above, there is the requirement to setup a second private network for the VDA and RDP communication. You need to launch the VI Client and connect it to the ESX server:

  1. Under the configuration tab, you need to invoke the Networking link.
  2. Click on Add Networking
  3. Select Virtual Machine as a connection type
  4. Create a new vSwitch not connected to a vmnic (network adapter)
  5. Provide a new label like "Private Network" and a unique ID (1)
  6. Press 'ok' and the new private network gets created. As the switch is not connected to an adapter, no communication will be routed into a physical network.

Setup Sun Ray Server

  • Setup the OS Image:

The Sun Ray Server and later SGD need to be installed on Solaris 10:

  1. The image should be large enough to host both SRSS and SGD: 8 GB
  2. RAM should be around 1.5 GB
  3. A single CPU should be enough
  4. 2 Network interfaces (public and private)
  5. Both interfaces should be configured as static
  • Install Sun Ray Server Software:

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

  • Install the VDA Client:
  1. The VDA client is installed by extracting the VDA client archive to /opt
  2. Download and install xloadimage (http://www.sunfreeware.com, ftp://ftp.sunfreeware.com/pub/freeware/intel/8/xli-1.16-sol8-intel-local.gz)
  3. Modify /opt/sun-vda/bin/vda-kiosk.sh script:
    1. Point to XLI (xloadimage) executable
    2. Point to Virtual Center server (Static IP in Private Network)
  • Configure CAM:
  1. Configure CAM policy for card and non card usage
  2. Configure /opt/sun-vda/bin/vda-kiosk.sh as a critical application
    1. Select /opt/sun-vda/bin/vda-kiosk.sh as only application to run
    2. Cold restart of the SR server
  • Configure DHCP for the Private Network:

Configure the Private Network as a Directly-Connected Dedicated Interconnect. Basically the SR 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. The configuration can be set through the command utadm -a pcn1. You can find more background information on the network configuration in the SR admin guide: [Sun Ray Network Configuration].

  • 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.
  • Create Demo Users:

If the demo has no NIS setup, you should create your demo users on the Sun Ray Server and later on the Virtual Desktops.

Setup Virtual Center

  • Setup the OS Image:

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

  1. The image should be at least 8 GB.
  2. RAM should be minimum 1 GB
  3. A single CPU should be enough
  4. 2 Network interfaces (public and private)
  5. Both interfaces should be configured static
  • Install Virtual Center:
  1. Version: 2.01 or above
  2. The license file needs to be copied to the target VM before installation
  3. Run the default installation procedure:
  4. Create a local database
  5. Use your own license server
  6. Enable the Web Access
  • Configure Web Access for the VI SDK:

The VDA Service uses the VI 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. This depends on the specific security needs. For a demo http should definitely be sufficient, but the default is https. The configuration steps are described in the VMware Infrastructure SDK Programming Guide: http://www.vmware.com/pdf/ProgrammingGuide201.pdf. Below you find the relevant instructions for configuring http access taken from the Programming Guide:
To use the http protocol to access to the Virtual Center Web Service, you must edit the configuration file. Note: You should do this only in a test or development environment. Editing the Configuration File (Virtual Center Server). The vpxd.cfg file is located at C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\vpxd.cfg:

  1. Locate the <proxyDatabase> tag within the <http> tag
  2. Follow the instructions within the file to enable http.
  3. Restart the VMware Virtual Center Server service. This can be done by using the Services Control Panel Applet.
  • Setting up sysprep:

For Windows Customization you need to install the sysprep tools onto the Virtual Center server. There is an excellent doc from VMware that explains this step: http://www.vmware.com/pdf/vc_2_templates_usage_best_practices_wp.pdf. You can download the sysprep tools for Windows XP at: http://www.microsoft.com/downloads/details.aspx?FamilyId=3E90DC91-AC56-4665-949B-BEDA3080E0F6&displaylang=en

  • Configure Virtual Center:
  1. Switch to the "host/cluster" view
  2. Create a new Datacenter called "Datacenter"
  3. Create a new Cluster called "Desktops". Enable DRS, partially automated.
  4. Add the ESX server to the cluster
  5. Point the ESX server to the VC licensing server (Configuration/License Features)
  6. Switch to the "Virtual Machine" view
  7. Create the folders "Pool", "Pool-Kiosk" and "Pool-Static". They will be used by the VDA Service. These are the default pools preconfigured in the VDA Service configuration =vda.properties=. Naming and number of pools can be changed later and need to be reflected in the VDA Service configuration.
  8. Create a customization definition under: Edit/Customization Specifications
    1. You need to have a Windows XP Volume License Key
    2. Network settings can remain the same
    3. Other settings should be straight forward

Note: When you change the naming of pools, of the datacenter or the cluster you need to understand the internal structure/hierarchy as it is used in the VI SDK. The top level node is typically a datacenter. Underneath you have a subtree for hosts 'host' and a subtree for Virtual Machines 'vm'. The host subtree contains hosts or cluster of hosts. The 'vm' subtree contains subtrees of Virtual Machines or Virtual Machines themselves. So for e.g. the static pool has the following path: /Datacenter/vm/Pool-Static and the cluster has the path /Datacenter/host/Desktops.

  • Create the Golden Image:

Details in next section (4.4).

  • Create a template for deployment:

This is a clone of the Golden Image. It is marked as template through the machine options.

  • Install and configure the VDA service:
  1. Install the vda-service in c:\sun-vda
  2. Adjust the configuration (conf\vda.properties):
  3. Set the connection pwd
  4. Point the configuration to the deployment template
  5. Point the configuration to the customization template
  6. Check the configuration: c:\sun-vda\bin\vda-service test. Note that a warning message about being "Unable to find required classes" and attachment support being disabled will be printed out in addition to the test result, it can be safely ignored. Any message about not being able to connect to the VI service needs however to be investigated, and is likely caused by an error in either the SDK URL setup. Check that you're using the right protocol, and that it's enabled in the SDK (see above for details), and that you've provided the proper user and password in the =vda.properties= file.
  7. Register the service: 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.
  8. If you change the configuration file later, make sure that the vda service gets restarted.

Setup the Virtual Desktop

  • Setup the OS Image:
  1. Use Windows XP SP2.
  2. The image should be as small as possible, this impacts system performance: 4 GB.
  3. RAM should be also as small as possible like 256-384MB
  4. A single CPU should be enough
  5. 1 Network interface (private), configured for DHCP
  6. Options/VMware Tools: Make sure that scripts for suspend and resume events are executed. They are mainly responsible for releaseing and renewing IP adresses.
  7. Options/Power Management: Make sure that the VM suspends when a Standby by the guest OS is initiated. This will fully suspend the machine and not keep it somewhat awake.
  8. 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: tsdiscon.exe. tsdiscon.exe disconnects all connected RDP clients. Note that each new release of VMware Tools overwrites the scripts. Not nice by VMware.
  • Configure Power Management:

The Power Options for XP have quite an important role. They control the suspend behavior of the VM. Power Options can be found in the Control Panel. Here you have to define the !StandBy Time to your best suitable value. Note: This is a machine setting and can only be set by the Administrator of the machine. Controlling this setting for each individual box could be quite tedious and error prone. Using Group Policy in an AD dependent deployment would be great. But there are no such GPOs for Power Options. A couple of vendors have addressed this as an addition to Windows default Group Policy. There is also a free available tool that allows to control the Power Options via GPO: http://www.terranovum.com/projects/energystar/ez_gpo.html. Setting this as a local or central GPO through AD gives the most reliable results.

  • Install the VDA Tools:
  1. Extract them to c:\sun-vda
  2. Register the service: c:\sun-vda\bin\register-vda-tools.bat
  • Create Demo Users:
  1. If you are not connected to AD, you need to place the users locally
  2. Enable Remote Access for the demo users
  • Enable Remote Access:
  1. Make sure that the firewall allows RDP communication
  2. Make sure that the users connecting are allowed to connect remotely.
  • Create a template for Deployment:

This template will seed the Virtual Desktop population.

Setup Sun Secure Global Desktop

  • Installation:

Install SGD onto the SR server. Installation procedure is the usual one.

  • Configure VDA Client:
  1. Copy the VDA expect script into the standard SGD directory: cp /opt/sun-vda/bin/vda-wcpwts.exp /opt/tarantella/var/serverresources/expect
  2. Modify the script so that it points to the right vda-client in the /opt/sun-vda/bin/i386 sub-directory
  • Configure Desktop Access with the Object Manager:
  1. Launch the Webtop as root
  2. Configure a host: This points to the Virtual Center in the Private Network
  3. Configure a Windows Application:
    • Set the host with the previously configured one
    • Define the application 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 SGD or SRSS. You can test that with your Sun Ray or the laptop. There are a few other things to consider:

  • Implement hot desking between SRSS and SGD:

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

  • 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 non-smartcard 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 might be quite sufficient. The things you definitely need to rework are:

  • The Golden Image: here you need to use one from the customer.
  • The setup of the users: these are probably setup as domain users with network profiles
  • The Virtual Desktops need probably participate in a shared network instead of a private one.
  • The Virtual Desktops need probably to join a NT or AD domain. This can be defined through sysprep.
  • And for sure some other things specific to the customer ...


Personal tools