Release Notes


Contents

Release Notes

These notes contain important information about the Sun VDI Core at the time of revenue release, including requirements and supported platforms as well as issues and workarounds. Be sure to read this document before you begin using Sun VDI 3.

Package Software

Sun Virtual Desktop Infrastructure Software 3.0 bundled software includes:

  • Sun VDI Core
  • Sun Ray Server Software 4.1 (SRSS)
  • Sun Ray Connector for Windows OS, Version 2.1 (SRWC)
  • Sun VirtualBox for VDI 3.0, otherwise known as Sun VirtualBox 2.0.10 (Solaris 10 x86 only)

Separate software covered by the VDI license:*

  • Sun Secure Global Desktop 4.41 (SGD)
  • Sun Secure Global Desktop 4.5 (SGD)
  • Sun VirtualBox for VDI 3.0, otherwise known as Sun VirtualBox 2.0.10 (additional platforms for creating desktop templates)

* For more details about the concurrent license, see the Troubleshooting and FAQs.

Patches

The first VDI 3 patch was released on May 30. A revision of the patch was released on August 13. For more details see: VDI Patches.

Third-Party Software

Sun VDI 3 includes software originating from third parties that is subject to GPL/LGPL, or CDDL licenses. The corresponding source code is available via the links below:

Supported Software

This section includes support tables for VDI Core host operating systems, virtualization platforms, storage servers, desktop guest systems. For more about VDI Support, see Supported Configurations.

VDI Core Host Operating Systems

Software VDI 3
Solaris 10 Update 6 SPARC and x86 (64-bit) X
Solaris 10 Update 7 SPARC and x86 (64-bit) X

Virtualization Platforms

Software VirtualBox Virtualization Platform VMware Infrastructure Virtualization Platform Not Supported
Sun VirtualBox for VDI (VirtualBox 2.0.10) X    
Sun VirtualBox for VDI (VirtualBox 2.0.8) X    
All other VirtualBox Versions     X
VMware VirtualCenter 2.5 (Update 1, 2, 3, 4, 5)   X  
VMware ESX server 3.5 (Update 1, 2, 3, 4)   X  
VMware vSphere (ESX server 4.0)   X  

Storage Servers

Software VirtualBox Virtualization Platform VMware Infrastructure Virtualization Platform Not Supported
Solaris 10 Update 7 X    
OpenSolaris 2008.11 X    
OpenSolaris 2009.06 X    
Sun Unified Storage 7000 Series 2009.Q3.2.0     X*
Sun Unified Storage 7000 Series 2009.Q3.1.0     X*
Sun Unified Storage 7000 Series 2009.Q3.0.0     X*
Sun Unified Storage 7000 Series 2009.Q2.5.1 X    
Sun Unified Storage 7000 Series 2009.Q2.5.0 X    
Sun Unified Storage 7000 Series 2009.Q2.4.0 X    
Sun Unified Storage 7000 Series 2009.Q2.3.1 X    
Sun Unified Storage 7000 Series 2009.Q2.3.0     X
Sun Unified Storage 7000 Series 2009.Q2.2.1     X
Sun Unified Storage 7000 Series 2009.Q2.2.0     X
Sun Unified Storage 7000 Series 2009.Q2.1.1 X    
Sun Unified Storage 7000 Series 2009.Q2.1.0 X    
Sun Unified Storage 7000 Series 2009.Q2.0.0 X    
Sun Unified Storage 7000 Series 2008.Q4.2.3     X
Sun Unified Storage 7000 Series 2008.Q4.2.2     X
Sun Unified Storage 7000 Series 2008.Q4.2.1 X    
Sun Unified Storage 7000 Series 2008.Q4.2.0 X    
Sun Unified Storage 7000 Series 2008.Q4.1.1 X    
Sun Unified Storage 7000 Series 2008.Q4.1.0 X    
Sun Unified Storage 7000 Series 2008.Q4.0.1     X
Sun Unified Storage 7000 Series 2008.Q4.0.0     X
Qualified by VMware   X  

* With the 2009.Q3.0.0 release a new iSCSI stack (COMSTAR) has been introduced to the Unified Storage 7000 Series which is incompatible with VDI 3.0 and the upcoming VDI 3.1 releases. COMSTAR will be supported by VDI 3.1.1 which will be released ASAP after the 3.1 release.

Tip
For more information about the Sun Unified Storage 7000 Series, see the Fishworks Documentation.

Desktop Guest Systems

Software VirtualBox Virtualization Platform VMware Infrastructure Virtualization Platform Not Supported
Windows XP SP2 and higher X X  
Windows Vista Enterprise X X  
Windows 2000 X    
Ubuntu 8.10 X    
OpenSolaris 2008.11 X    
SLED 11 X    

Known Issues and Limitations

Solaris hosts must have adequate swap space. (Bug ID 1225025)

Solaris hosts running xVM VirtualBox must have swap space equal to, or greater than the host's physical memory size. For example, 16GB physical memory would require at least 16GB swap. This can be configured during a Solaris 10 install by choosing a 'custom install' and changing the default partitions.
For existing Solaris 10 installs you will need to create a swap image file on the local filesystem and mount it. The swap file image size should be: Physical Memory - Current Swap = Additional Swap Required. For example, 16GB physical memory - 1GB = 15GB of additional swap required. To add the swap to your system:
For ZFS:

# zfs create -V 16gb _<ZFS volume>_/<new_swap_volume>
# swap -a /dev/zvol/dsk/_<ZFS volume>_/<new_swap_volume> 

To have the swap mounted after a reboot, add the following line to /etc/vfstab:

/dev/zvol/dsk/_<ZFS volume>_/<new_swap_volume> - - swap - no -

For UFS:

# mkfile 15g /path/to/swap.img
# swap -a /path/to/swap.img

To have the swap mounted after a reboot, add the following line to /etc/vfstab:

/path/to/swap.img - - swap - no -

Memory for ARC cache should be restricted to a lower limit when using ZFS on S10u7. (Bug ID 6844780)

When all VDI components (VDI host, xVM VirtualBox host, and ZFS storage) are installed on a single box (x86 platform, running S10u7), xVM VirtualBox will not be able to start any desktops.
Cause - ZFS uses any memory available (up to the limit) for an ARC cache. If other programs try to access the memory, ZFS should release it. Unfortunately, VDI evaluates the memory before trying to start a virtual machine and recognizes that not enough memory is available to start the virtual machine. Full details are available here http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#ARCSIZE.

Solution - The memory for the ARC cache can be limited to a max value by adding an entry in /etc/systems file.
For example, to restrict the memory to 2GB, in /etc/system add:

set zfs:zfs_arc_max = 2147483648 

It has been verified that keeping this value to as low as 512MB and importing a file of 2.7G will work as desired.

Desktops cannot use 'Host Networking' unless VirtualBox has been configured to run as root. (Bug ID 6839450)

Virtual machines cannot be started with host networking unless the VirtualBox web service runs as root.

During log-off, VirtualBox desktops do not go into idle state when settings are 'Host Networking - WinRDP'. (Bug ID 6837283)

Desktop never go to the idle state and remain in used state forever and hence do not get recycled.

VDI Host Overload (Bug ID 6810444)

In case you see a blank page when login in to the administration ui it's likely that database problems are the root cause. You may for instance see "Error 157" in the database log files in '/var/opt/SUNWvda/mysql-cluster' of the primary or one of your secondary hosts.
Cause- When using the VDI MySQL Cluster database, the first two VDI secondary hosts run the MySQL Cluster data nodes in addition to a MySQL SQL node, SRSS, SRWC, VDI, etc. MySQL Cluster is sensitive to resource shortages. The expected load to the MySQL Cluster data nodes is small, so the MySQL processes should be able to cope under typical loading. However, if you have too many Sun Ray sessions on each of the first two Sun Ray secondaries, you may see this error.
Solution- Check the load on the concerned hosts and if it is high, reduce the load on this host e.g. by reducing the number of SRSS sessions hosted. Restart the SQL node running on the concerned host

Using the VDI CLI in parallel with the Admin Web GUI. (Bug ID 6770476)

Using the vda CLI to modify some data, while having an Admin Web UI session running, might generate errors in the Web Admin UI and log you out. At following login, the Web Admin UI will be working fine again.

Limitations with VDI hosts running on SPARC. (Bug ID 6812848)

  • Only one storage is supported with Solaris SPARC VDI hosts.
  • The 'duplicate' action fails with Solaris SPARC VDI hosts.

Cause- Sun VDI 3.0 does not support copying one iSCSI volume to another iSCSI volume via Java in Solaris SPARC VDI hosts.

Sun Open Storage fails after a software update. (Bug ID 6826006)

  • Do not update the software of a Sun Open Storage after it has been added to VDI 3.0. Any management action of VDI 3.0 fails afterwards.

OpenSolaris Update causes SSH to the storage box to fail. (Bug ID 6812829)

After doing a 'pkg image-update' on an OpenSolaris host used for xVM VirtualBox storage, VDI can no longer SSH to the box. The following error is seen:

Caused by: com.jcraft.jsch.JSchException: Algorithm negotiation fail
       at com.jcraft.jsch.Session.receive_kexinit(Session.java:510)
       at com.jcraft.jsch.Session.connect(Session.java:285)
       at com.sun.vda.service.vbox.SshServer.executeCommand(SshServer.java:331)
       ... 40 more

Normal SSH via the command line continues to work fine.
Cause- Changes have been made to how the sshd negotiates the ciphers between version 101b and 108 of OSOL.
Solution- We require the customer to use the release version of OSOL 2008.11 (101b). Any upgrades are not supported and need to get clearance from us first.
A fix in this particular case is to activate the 'Ciphers' line in /etc/ssh/sshd_config and to restart the ssh service.

vb-install script fails to install xVM VirtualBox package. (Bug ID 6814023)

If you uninstall xVM VirtualBox and want to reinstall it, the installation may fail.
Cause- Some xVM VirtualBox processes may still remain even after removal.
Solution- Reboot the xVM VirtualBox host to kill any remaining processes.

Cloned virtual machines have lower resolution than the xVM VirtualBox virtual machine templates. (Bug ID 6815380)

The cloned VM has a blurry desktop image because it has a lower (8-bit) resolution compared to the original (32-bit) virtual machine.

Migrating large numbers of pools from VDI 2.0 to 3.0 fails. (Bug ID 6819562)

Sometimes when migrating two or more pools from VDI 2.0 to VDI 3.0 the first pool will succeed and the next ones will fail.
Cause- A misconfiguration in the vda-migrate tool.
Solution- It is recommended not to migrate several pools simultaneously from VDI 2.0 to VDI 3.0 (a patch for this issue will be available soon).

Importing VDI 2.0 data into VDI 3.0 fails if pool's recycle policy is 'Destroy'. (Bug ID 6818383)

Cause- The "Recycling Policy" value 'destroy' in VDI 2.0 became 'delete' for VDI 3.0.
Solution- Edit the exported text properties file ('migrate_svdc_1.?'). It should be located in the directory which was used to export previous Sun VDI data. Find all the lines which end with "pool.recyclepolicy=Destroy" and modify them to "pool.recyclepolicy=Delete".

Reporting Problems and Providing Feedback

To report a bug in the software, please send an email to the VDI Team

If you are reporting a bug, please provide the following information where applicable:

  • Description of the problem, including the situation, where the problem occurs, and its impact on your operation.
  • Machine type, operating system version, browser type and version, locale and product version, including any patches you have applied, and other software that might be affecting the problem.
  • Detailed steps on the method you have used, to reproduce the problem.
  • Any error logs or core dumps.

Further Information

You may also be interested in these related release notes:

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jul 22

    hi-roshi says:

    Is SGD version 4.50-907 supported by SunVDI3 ?

    Is SGD version 4.50-907 supported by SunVDI3 ?

Sign up or Log in to add a comment or watch this page.


The individuals who post here are part of the extended Sun Microsystems community and they might not be employed or in any way formally affiliated with Sun Microsystems. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Sun nor any other party necessarily agrees with them.

Copyright 1994-2009 Sun Microsystems, Inc.
Powered by Atlassian Confluence
Sun Guidelines on Public Discourse Privacy Policy Terms of Use Trademarks Site Map Employment Investor Relations Contact