Sun Shared Visualization 1.1 Software Client Administration Guide

This appendix provides information about VirtualGL options and environment variables that are most pertinent to the Sun Shared Visualization 1.1 software. There is also a summary of the VirtualGL GUI. Topics include:

• Common vglconnect Scenarios
• Common vglrun Scenarios
• VirtualGL Options and Environment Variables, which includes:
• vglrun options
• VirtualGL GUI for Quality and Performance Tradeoff
• vglclient options

• Advanced OpenGL Features
• Troubleshooting Common Errors

---

Common vglconnect Scenarios

TABLE A-2 describes different scenarios for invoking vglconnect, the command to run the scenario, and respective comments.

On Solaris, Linux, and Mac OS X hosts, if /opt/VirtualGL/bin is not in your path, you will have to type the full path:

/opt/VirtualGL/bin/vglconnect

On a Windows client, precede vglconnect commands with:

C> cd /d "c:\program files\virtualgl-version-build"

---

Common vglrun Scenarios

TABLE A-2 describes different scenarios for vglrun, the command to run the scenario, and respective comments. The program in the Command column can be either an application executable or a script; $PATH is searched if a pathname is not specified.

A more thorough explanation of vglrun options and the corresponding environment variables is provided in VirtualGL Options and Environment Variables.

Chrominance Subsampling

When an image is compressed using JPEG or using Sun Ray DPCM and YUV compression, each pixel in the image is first converted from RGB (Red/Green/Blue) to YUV. A YUV pixel has three values that specify the overall brightness of the pixel (Y, or luminance) and the overall color of the pixel (U and V, or chrominance.)

Since the human eye is less sensitive to changes in color than to changes in brightness, the chrominance components for some of the pixels can be discarded without much noticeable loss in image quality. This technique, called chrominance subsampling, significantly reduces the size of the compressed image.

TABLE A-3 introduces available chrominance subsampling choices. For example, 8x means to discard the chrominance components for 3 out of every 4 pixels horizontally and half the pixels vertically. (This option is also known as 4:1:0 or 4:2 subsampling.)

Narrow, aliased lines and other sharp features on a black background tend to produce very noticeable artifacts when chrominance subsampling is enabled. The gray option is useful when running applications (such as medical visualization applications) that are already generating grayscale images.

Gamma Correction

Gamma refers to the relationship between the intensity of light that your computer’s monitor is instructed to display, and the intensity that it actually displays. The curve is an exponential curve of the form Y = X^G, where X is between 0 and 1. G is called the gamma of the monitor. PC monitors and TVs usually have a gamma of around 2.2.

Some of the mathematics involved in 3D rendering assumes a linear gamma (G = 1.0). Therefore, 3D applications will not display with mathematical correctness unless the pixels are gamma corrected to counterbalance the nonlinear response curve of the monitor. But some systems do not have any form of built-in gamma correction. Thus, the applications developed for such systems have usually been designed to display properly without gamma correction. Gamma correction involves passing pixels through a function of the form X = W^1/G, where G is the gamma correction factor and should be equal to the gamma of the monitor. So the final output is Y = X^G = (W^1/G)^G = W. This equation describes a linear relationship between the intensity of the pixels drawn by the application and the intensity of the pixels displayed by the monitor.

You can enable, disable, or fine tune the gamma correction feature in VirtualGL by using the VGL_GAMMA environment variable and the vglrun options -g, +g,
and -gamma. These operations are summarized in TABLE A-4.

Default Gamma Correction Behavior

By default, when VirtualGL remotely displays an OpenGL application, VirtualGL attempts to emulate the gamma correction behavior that would be observed when the same OpenGL application is displayed locally on the application server.

• On Solaris SPARC, the default is VGL_GAMMA=1 or vglrun +g (that is, enable gamma correction using factor=2.2).

When an OpenGL application is displayed locally on a Solaris SPARC host, the application’s output is gamma corrected by default. Thus, VirtualGL will gamma correct the output of OpenGL applications that are displayed remotely from a Solaris SPARC host, unless you specify otherwise.

If VirtualGL Image Transport is used and the client is a Solaris SPARC system, then VirtualGL will attempt to use a gamma corrected visual to perform gamma correction. (The gamma corrected visual feature is only available with Solaris SPARC graphics drivers.) When a gamma corrected visual is used, you can adjust the gamma correction factor by running fbconfig on the client machine.

Otherwise (when a gamma corrected visual is not available or the client is not a Solaris SPARC system), VirtualGL uses its own internal gamma correction mechanism and the default gamma correction factor is 2.2.

• On Solaris x86 and Linux, the default is VGL_GAMMA=0 or vglrun -g (that is, disable gamma correction).

When an OpenGL application is displayed locally on a Solaris x86 or Linux host, the application’s output will not be gamma corrected by default. Thus, VirtualGL will not gamma correct the output of OpenGL applications that are displayed remotely from a Solaris x86 or Linux host, unless you specify otherwise.

Most non-SPARC clients provide a mechanism that allows you to gamma correct the entire screen, either through the graphics driver or the OS itself. However, these systems do not provide a means of gamma correcting an individual application (a capability of gamma corrected visuals).

---

VirtualGL Options and Environment Variables

vglrun is located:

• On a Solaris host at /opt/VirtualGL/bin/ and at /opt/SUNWvgl/bin
• On a Linux host at /opt/VirtualGL/bin/ and at /usr/bin

The syntax of vglrun is:

vglrun [vglrun-options] [--] OpenGL-application [OpenGL-app-arguments]

That is, any options for vglrun appear between vglrun and the name of the OpenGL application to start. If necessary, you can enter two hyphens to manually signify the end of vglrun options. Any options to the OpenGL application appear at the end of the line.

A more sophisticated example of the vglrun starting (which assumes vglrun is in your $PATH) is:

my_server% vglrun -g -d /dev/fbs/kfb0 my-program my-program-option my-program-argument

The most important vglrun option is controlled with -d (or with the VGL_DISPLAY environment variable). The value for the -d option is either an X display, or (on a Solaris SPARC host) the string glp or a GLP device name, such as /dev/fbs/kfb0, as seen in the example. When an X display is used, the display should be on the graphics server with 3D graphics acceleration. (An optional .screen indicates the screen or device for the X server.) For example:

my_server% vglrun -g -d :0.1 my-program my-program-option my-program-argument

If your graphics server has only one graphics device, start a 3D X server on the device and enable that X server to you (or to everyone on the graphics server), as described in the "Configuration and Information" section of the Sun Shared Visualization 1.1 Software Server Administration Guide. After that, the default X display (:0) is fine. Ask your system administrator if you need to provide the display or device to vglrun.

Sun Grid Engine can set VGL_DISPLAY for you, when running a job that requests graphics resources. On a graphics server with only one graphics accelerator, VGL_DISPLAY can be set to the empty string ““. The string is sufficient to cause VirtualGL to use the default X display (:0.0).

TABLE A-4, TABLE A-5, and TABLE A-6 list the VGL_ environment variables and equivalent vglrun options associated with general operation, Sun Ray Image Transport, and VGL Image Transport, respectively.

export VGL_CLIENT=my_client_machine:0.0

Passing a configuration option as an argument to vglrun effectively overrides the environment variable setting corresponding to that configuration option.

For more information about vglrun options, start vglrun -help or consult the VirtualGL User’s Guide. See Related Documentation.

VirtualGL GUI for Quality and Performance Tradeoff

VirtualGL has a small graphical user interface (GUI) to enable you to dynamically control the VirtualGL compression and encoding. See FIGURE A-1. This functionality enables you to reconfigure visual quality and performance on-the-fly.

FIGURE A-1 VirtualGL’s Configuration Dialog (Showing LAN Defaults)

  Press the Control-Shift-F9 keys.

That is, hold the Control and Shift keys, and press the F9 function key. You can use the VGL_GUI environment variable to change the key combination if, for example, an application is already using that key sequence.

For example:

my_server% setenv VGL_GUI CTRL-F9

The command changes the key sequence to the Control-F9 keys for graphics programs started with vglrun from that shell.

Using the VirtualGL GUI

You can use this dialog to adjust various image compression and display parameters in VirtualGL. Changes are reflected immediately in the application. TABLE A-7 describes each of the setting fields for the GUI. Many of these descriptions refer to static settings described in tables in VirtualGL Options and Environment Variables. The GUI overrides those static settings from an environment variable or option to vglrun.

vglclient options

The following table lists options honored by vglclient when using the VGL Image Transport. Note that vglclient is normally started implicitly by vglconnect.

---

Advanced OpenGL Features

This section discusses VirtualGL features that support these advanced OpenGL Features:

• Stereographic Rendering (rendering image pairs intended for left and right eyes)
• Transparent Overlays (rendering an image on top of another rendered image, so the top image can be easily redrawn without requiring a redraw of the underlay)

Stereographic Rendering

Stereographic rendering is a feature of OpenGL that creates separate rendering buffers for the left and right eyes and allows the application to render a different image into each buffer. How the stereo images are subsequently displayed depends on the specifics of the 3D hardware and the user’s environment.

VirtualGL can support stereographic applications in two ways:

You can select a specific stereo mode by setting the VGL_STEREO environment variable, by using the -st argument with vglrun (see General VGL_ Environment Variables and vglrun Options), or by using the VirtualGL GUI (see VirtualGL GUI for Quality and Performance Tradeoff).

Quad-Buffered Stereo

The name quad-buffered stereo is derived from OpenGL using four buffers (left front, right front, left back, and right back) that support stereographic rendering with double buffering. 3D graphics cards with quad-buffered stereo capabilities typically provide a synchronization signal that can control active stereo 3D glasses of various types. Some 3D graphics cards support passive stereo, which displays the buffers for the left and right eyes to different monitor outputs. The outputs might be projected onto the same screen through polarized filters.

VirtualGL supports true quad-buffered stereo by rendering stereo images on the server and sending image pairs across the network. The image pairs are displayed by a 3D graphics card on the client.

Quad-Buffered Stereo Requirements

In most cases, the VirtualGL and TurboVNC clients use only 2D drawing commands, so the client host does not required a 3D graphics card. But displaying quad-buffered stereo images requires that the client host have a 3D graphics card. Since the 3D graphics card is only being used to display images, it does not need to be a high-end card of that type. In most cases, the least expensive 3D graphics card that has stereo capabilities will work fine in a VirtualGL client.

Also, the server must have a 3D graphics card that supports stereo, since this is the only way that a stereo Pbuffer is provided to VirtualGL.

When an application tries to render something in stereo, VirtualGL will use quad-buffered stereo rendering if all of the following characteristics are true:

• VGL Image Transport is being used.
• Anaglyphic stereo is not explicitly requested (for example, by VGL_STEREO, by vglrun’s -st option, or by VirtualGL’s GUI).
• The client supports OpenGL (Exceed 3D is required for Windows clients).
• The client has stereo rendering capabilities.
• The server has stereo rendering capabilties.

If any of these conditions is not true, then VirtualGL falls back to using anaglyphic stereo (as described in Anaglyphic Stereo). You usually need to explicitly enable stereo in the graphics driver configuration for both the client and server machines. Verifying Advanced Feature Support describes how to verify that stereo visuals are available on both the client and server.

In quad-buffered mode, VirtualGL reads back both eye buffers on the server, then sends the contents as a pair of compressed images (one for each eye) to the VirtualGL client. The VirtualGL client then decompresses both images and draws them as a single stereo frame to the client machine’s X display using glDrawPixels(). Because of this process, enabling quad-buffered stereo in VirtualGL typically decreases performance by 50 percent or more, and twice the network bandwidth is used to maintain the same frame rate.

Anaglyphic Stereo

Anaglyphic stereo is the type of stereographic display used for old 3D movies. This method usually relies on a set of 3D glasses consisting of red transparency film over the left eye and cyan transparency film over the right eye. To generate a 3D anaglyph, the red color data from the left eye buffer is combined with the green and blue color data from the right eye buffer, enabling a single monographic image to contain stereo data. Within the capabilities of VirtualGL, an anaglyphic image is the same as a monographic image. Therefore, anaglyphic stereo images can be sent by any image transport to any type of client, regardless of the client’s capabilities.

VirtualGL falls back to using anaglyphic stereo when VirtualGL detects that an application has rendered something in stereo but quad-buffered stereo is not available. Quad-buffered stereo might be unavailable because the client doesn’t support it or because the image transport being used is not GL Image Transport. Anaglyphic stereo provides an inexpensive and simple way to view stereographic applications in X proxies (including TurboVNC) and on clients that do not support quad-buffered stereo. Additionally, anaglyphic stereo performs much faster than quad-buffered stereo, since quad-buffered stereo sends twice as much data to the client.

Transparent Overlays

Transparent overlays render an overlay image on top of an underlay rendered image. You can easily erase or redraw the overlay image without requiring the underlay to be redrawn. Transparent overlays have requirements and restrictions similar to those for quad-buffered stereo. For an application to use this feature, transparent overlay features must be provided by the client host’s 3D graphics card and OpenGL.

When an application performs OpenGL rendering to the transparent overlay, VirtualGL completely bypasses its own GLX faker. Instead, VirtualGL uses indirect OpenGL rendering to render to the transparent overlay on the client’s graphics card. The underlay is still, as always, rendered on the server host.

Use of overlays is becoming more and more infrequent. When they are used, it is typically only for drawing small, simple, static shapes and text. Usually it is faster to send the overlay geometry over to the client rather than to render it as an image and send the image.

As with stereo functions, sometimes overlays must be explicitly enabled in the client graphics card’s configuration. Unlike stereo requirements, overlays need to be supported and enabled only on the client machine.

Indexed color (8-bit) overlays have been tested and are known to work with VirtualGL. Use glxinfo (see Troubleshooting below) To verify whether your client’s X display supports overlays and if overlays are enabled, use glxinfo as described in To Verify Client Features. In Exceed 3D, make sure that the Overlay Support option is checked in the Exceed 3D and GLX applet.

Overlays do not work with X proxies, including TurboVNC. VirtualGL must be displaying to a real X server to use overlays.

---

Troubleshooting Common Errors

This section describes common user errors and how to avoid, detect, or recover from the errors.

vglconnect and ssh Issues

• In recent Solaris OS releases (such as Solaris 10), the Secure Shell daemon (sshd) has the default of not allowing remote logins as user root. This default is configured by the PermitRootLogin entry in the ssh daemon’s configuration file, /etc/ssh/sshd_config. To avoid this problem, login as a user other than root when running ssh or vglconnect (which uses ssh). Become root only when necessary by using the su command.

VirtualGL Issues

• If the VirtualGL Client is not started, an attempt to start an application under VirtualGL control reports Connection refused:


[VGL] Could not connect to VGL client. Make sure the VGL client is running and [VGL] that either the DISPLAY or VGL_CLIENT environment variable points to [VGL] the machine on which it is running. [VGL] rrsocket.cpp-- [VGL] 224: Connection refused

This message is probably caused by using a program such as ssh to log into the graphics server, rather than using vglconnect, which starts vglclient implicitly. Another possible cause is that the vglclient process exited. In that situation, a new vglclient needs to be started using the vglconnect -force option. Check the VirtualGL client log file for possible errors.

• If VirtualGL is not compressing images, VirtualGL can draw directly to the client’s X server without connecting to the VirtualGL client software, but this behavior does not perform as well. There is not an automatic fallback when vglclient is not found. The Connection refused message also appears if the client is a Sun Ray and the Sun Ray plug-in for VirtualGL (package SUNWvglsr) has not been installed on the graphics server (unless no compression was requested).
• If the DISPLAY environment variable is not set on the graphics server host, then an attempt to start an application under VirtualGL control reports something similar to: XOpenDisplay: Error opening display. Or if access was not granted properly, the application might print messages such as:


Xlib: connection to "client:0.0" refused by server Xlib: Client is not authorized to connect to Server myapplication: XOpenDisplay: Error opening display.


• If the graphics server’s X display or GLP graphics device is not properly configured, you do not have permission to access the display or device. VirtualGL reports an error such as:


[VGL] Could not open display (null).

In this case, null indicates that the VirtualGL display or device specification was "" (a null string, which is the VirtualGL default, meaning the graphics server’s :0.0 display). The name of the display or device name that VirtualGL failed to open or access is printed.

This message might be caused by one of the following configuration or usage errors:

• The “3D X server” running on the graphics server has not been configured to allow access to VirtualGL users. This configuration procedure is described in Chapter 4 of the Sun Shared Visualization 1.1 Server Administration Guide.
• The current user account is not in the vglusers group. To do this procedure, see Chapter 4 of the Sun Shared Visualization 1.1 Server Administration Guide.
• There is no “3D X server” running on the graphics server providing access to the graphics accelerator.
• The graphics server is configured for use only with GLP, but vglrun was not provided with the -d glp argument.

• If the graphics server does not offer a true color (RGB) X visual, VirtualGL might print:


Error: couldn’t get an RGB, Double-buffered visual

The same error can occur if the client’s “2D X server” does not offer a 24-bit true color (RGB) visual. Some Linux systems are configured for only 16-bit visuals. In this case, the system must be reconfigured for 24-bit true color visuals.

Another possible reason that the application can’t open a usable visual is that the graphics server’s 3D graphics card does not support OpenGL pixel buffers (Pbuffers). The graphics server might not have the proper driver installed for that 3D graphics card. On Linux, you probably need to use the driver supplied by the 3D graphics card vendor instead of the driver that was included with the operating system. For example, use the nvidia driver supplied by the 3D graphics card vendor rather than an nv driver from another source.

• If you neglect to start vglrun, the graphics application can use the GLX remote graphics technique described in Sun Shared Visualization 1.1 Introduction if $DISPLAY directs the application to your client’s X server and the server supports the GLX (OpenGL for X) graphics extension. GLX can be far slower than VirtualGL, especially for large graphics models.
• Error message such as the following might indicate that the ssh server daemon running on the graphics server does not have X11 forwarding enabled:
• Could not open display
• Client is not authorized to connect to server
• Connection refused by server

To configure X11 forwarding, see the Sun Shared Visualization 1.1 Server Administration Guide.

vglrun Issues With Set-UID Programs and Scripts

When a Solaris or Linux application (binary executable or script) must set the user or group ID when it runs (enabled with a UNIX file system’s setuid and setgid permission bits), that application might generate errors when it runs under VirtualGL. The error message depends on the operating system.

• On Solaris, the message might be:


warning: /opt/SUNWvgl/lib/librrfaker.so: open failed: illegal insecure pathname


• On Linux, the message might be:


ERROR: ld.so: object ’librrfaker.so’ from LD_PRELOAD cannot be preloaded: ignored.

This error occurs because the VirtualGL faker library is preloaded into every executable that the script launches. When invoking an executable that is setuid or setgid, the operating system refuses to load virtualGL into those executables, because you are attempting to preload a library (VirtualGL) that the operating system does not consider secure into a process that needs to be secure.

• The Solaris software allows preloading into a setuid or setgid process only if the library is in a directory that the software recognizes as containing only secure libraries.
• Linux versions allow preloading into a setuid or setgid process a library only if it is in the standard search directories (such as /lib) that are also set-user-ID.

Alternatives to Work With This Restriction

A system administrator can configure the operating system to consider the VirtualGL library to be secure, as is described in the Configuration chapter of the Sun Shared Visualization 1.1 Software Server Administration Guide.

If the application is a script, a more secure method is to edit the application script and have it run vglrun only for the executables that you want to run in the VirtualGL environment. Here are various ways to do this:

• Use vglrun’s -32 and -64 options on OpenSolaris or Solaris to provide control for launching scripts:



vglrun Option	Description
vglrun -32	Preloads VirtualGL only into 32-bit executables.
vglrun -64	Preloads VirtualGL only into 64-bit executables.

Here is an example of using these options. The script calls a binary needing setuid that is a 32-bit execuatable. However, the graphics application is a 64-bit executable. In this situation, you can use vglrun -64 to launch the application script. The result is that the 32-bit setuid binary will not attempt to preload VirtualGL’s faker library.

• You can edit the application script (or create an alternative script) so the script postpones use of vglrun until vglrun invokes the actual graphics application. For example, your original script (called my_script) is as follows:


#!/bin/sh some_setuid_binary some_application_binary

Rather than running this with vglrun my_script, you can create a similar script (called my_vgl_script) as follows:

#!/bin/sh
some_setuid_binary
/opt/VirtualGL/bin/vglrun some_application_binary

Invoke my_vgl_script directly (that is, do not enter vglrun my_vgl_script). The result is that this script does not attempt to preload VirtualGL into some_setuid_binary, but will preload VirtualGL into some_application_binary, as you wanted. Unfortunately, this method does allow the user invoking my_vgl_script to provide vglrun options on the command line. But the next technique does.

• A variation for editing an application script allows the invoking user to provide vglrun options on the command line, as long as the user is not counting on preloading any libraries other than VirtualGL. This method depends on saving and restoring environment variables in the modified script. The environment variables manipulated depend on the server’s Operating System.
• On OpenSolaris or Solaris, a modified application script should save and restore the LD_PRELOAD_32 and LD_PRELOAD_64 variables:


#!/bin/sh LD_PRELOAD_32_SAVE=$LD_PRELOAD_32 LD_PRELOAD_64_SAVE=$LD_PRELOAD_64 LD_PRELOAD_32= LD_PRELOAD_64= export LD_PRELOAD_32 LD_PRELOAD_64   some_setuid_executable   LD_PRELOAD_32=$LD_PRELOAD_32_SAVE LD_PRELOAD_64=$LD_PRELOAD_64_SAVE export LD_PRELOAD_32 LD_PRELOAD_64   some_application_executable


• On Linux, the modified application script should save and restore the LD_PRELOAD variable:


#!/bin/sh LD_PRELOAD_SAVE=$LD_PRELOAD LD_PRELOAD= export LD_PRELOAD   some_setuid_executable   LD_PRELOAD=$LD_PRELOAD_SAVE export LD_PRELOAD   some_application_executable

vglclient Messages (Normally in the Log for vglconnect)

vglclient prints messages as graphics server applications connect and disconnect. vglconnect normally redirects vglclient‘s output to a log file whose name is printed by vglconnect

After a connection, the vglconnect log file normally contains connection and disconnection messages from vglclient, such as:

++ Connection from 10.4.22.34.
Error receiving data from server.  Server may have disconnected.
   (this is normal if the application exited.)
rrsocket.cpp-- 394: Incomplete receive
-- Disconnecting 10.4.22.34

Depending on how the application exits, messages might be printed before the Disconnecting message, as the Incomplete receive message shown here. If the application was supposed to exit, these messages are of no concern. But these messages can be used to help analyze unexpected behavior.

---

vis_report Reporting Script

Sun Shared Visualization 1.1 software includes a reporting script, /opt/SUNWvrpt/bin/vis_report, that is helpful in debugging product installation, configuration, and usage problems.

Support engineers can use the script output to troubleshoot problematic behavior. Use of the script is dependent upon the situation when the problem occurs:

• VirtualGL - In most cases, run the script on the graphics server, ideally from the client host that attempted to use VirtualGL and as the user attempting to use VirtualGL.
• TurboVNC - If you are using a TurboVNC session, run the script from within that session. The $DISPLAY and other environment variables will be set the same as when the problem occurred.
• Advance Reservation - If the Advance Reservation facility for Sun Grid Engine is involved, also run the script on the host running the Advance Reservation server, as the owner of the $SGE_ROOT/ar/config directory.

Attach the output of the script to an email of your problem. Describe what you were trying to do, what you expected to happen, and what actually occurred. Send the email to your service provider or to Shared-Viz-Support@Sun.com.

---

Verifying Advanced Feature Support

VirtualGL includes a modified version of glxinfo that can be used to determine whether or not the client and server have stereo, overlay, or Pseudocolor visuals enabled.

  Run one of the following command sequences on the VirtualGL server to determine whether the server has a suitable visual for stereographic rendering.

• On a Solaris server (using GLP):


% /opt/VirtualGL/bin/glxinfo -d {glp_device} -v


• On a Linux or Solaris server (not using GLP):


% xauth merge /etc/opt/VirtualGL/vgl_xauth_key % /opt/VirtualGL/bin/glxinfo -display :0 -c -v

In the output, one or more of the visuals should list stereo=1 and should list Pbuffer as one of the Drawable Types.

  Run the following command sequence on the VirtualGL server:

% /opt/VirtualGL/bin/glxinfo -v

Examine the output to determine whether the X display on the client has a suitable visual to support stereographic rendering, transparent overlays, or Pseudocolor

• In order to use stereo, one or more of the visuals should list stereo=1.
• In order to use transparent overlays, one or more of the visuals should list level=1, should list a Transparent Index (nontransparent visuals will say “Opaque” instead), and should have a class of PseudoColor.
• In order to use PseudoColor (indexed) rendering, one of the visuals should have a class of PseudoColor.

---

GLX Spheres Test Program

The GLX Spheres test program (glxspheres) is found in /opt/VirtualGL/bin. You can use this program to verify that VirtualGL has been configured and invoked properly.

This program supports the options shown in TABLE A-9.

Sun Shared Visualization 1.1 Software Client Administration Guide

820-3257-13

Copyright © 2008 Sun Microsystems, Inc. All Rights Reserved.