| Sun Shared Visualization 1.1 Software Client Administration Guide |    
|
| C H A P T E R 4 |
|
Using Sun Grid Engine to Start the Sun Shared Visualization 1.1 Software |
Topics in this chapter include:
Sun Grid Engine performs resource management. Sun Shared Visualization 1.1 software extends resource management for graphics servers to allocate graphics resources, as well as CPUs, memory, and other components. In an environment that has multiple execution servers or multiple graphics accelerators on a host, Sun Grid Engine (SGE) can select a suitable, lightly-loaded server to run your application. Sun Grid Engine can also select a lightly-loaded graphics device on that server. Sun Grid Engine software starts applications on that execution server, so you need not log in to the server.
Job scripts can specify options to Sun Grid Engine, which simplifies the task for its users. In an environment with heterogeneous execution servers, these options could specify which processor types and operating systems are capable of running the application. Additionally, the scripts can be customized for your Sun Grid Engine environment.
This section describes using the VirtualGL VGL or Sun Ray Image Transport from a Solaris, Linux, or Mac OS X client. Do not use this mode on low-bandwidth or high-latency networks.
You must first start the client’s X server and log in to the client before performing procedures in this chapter.
On a Windows client, you also must install and configure Exceed. Instructions for installing and configuring VirtualGL on Windows are in Installation on a Windows Client, or the VirtualGL User’s Guide. (To access that document, see Related Documentation.) Ensure that Exceed has been configured.
These procedures require that your client’s X server allow remote TCP connections (that is, into your X server from the application execution server chosen by Sun Grid Engine).
To enhance security, some newer Linux and Solaris distributions (in particular, Solaris 10 11/06 and later) do not by default allow TCP connections into the X server. Such systems cannot be used as clients with these procedures, unless the systems are reconfigured to allow X11 TCP connections. Discuss this situation with your system administrator.
If allowing remote X connections is not feasible, consider using SGE with TurboVNC instead. See Submitting Sun Grid Engine TurboVNC Jobs for instructions on those processes.
The procedure for using Sun Shared Visualization 1.1 software with Sun Grid Engine depends on whether your client is a Sun Grid Engine submit host. If so, you will submit jobs directly from your client. If not, you will first connect to a submit host and submit your job from there.
If your client is permitted to be an SGE submit host, it will need to NFS mount the SGE installation, as described in Appendix B. This mount must enable your client to use the same $SGE_ROOT as is used on the rest of the grid. (The default SGE_ROOT is /gridware/sge.)
Windows submit hosts are more difficult to configure successfully for Sun Grid Engine than Solaris or Linux submit hosts. To configure a Windows host for Sun Grid Engine currently requires:
These tasks require an experienced Sun Grid Engine administrator. See the current Sun N1 Grid Engine 6.1 Installation Guide, part number 820-0697, including its appendices.
If your client is not an SGE submit host, you must first connect to a submit host. This host need not be a graphics server but must be in the same grid with the graphics servers. From there, you submit your Sun Grid Engine job. Sun Grid Engine assigns your job to a lightly-loaded execution host (in keeping with your job’s stated requirements). Then, if the job requested graphics, Sun Grid Engine assigns a graphics accelerator (device or X display) to your job. When your job runs, its X applications connect back to your client. The submit host and the graphics execution hosts must share the same home directories and reside in the same domain.
This procedure requires that your client’s X server allow remote TCP connections, because you don’t know which execution host SGE will select for your job. Both the application’s X11 traffic and the VirtualGL image stream are unencrypted.
|
This section describes using VirtualGL’s VGL Image Transport from a Windows client. Do not use this mode on low-bandwidth or high-latency networks. This mode requires the Exceed (or Exceed 3D) X server to be installed and configured on the Windows client.
1. Start Exceed if it isn’t already started.
Hover the mouse pointer over the Exceed taskbar icon and make a note of the Exceed display number (for example, Exceed 0.0 Multiwindow Mode).
2. Open a new command prompt window and set the DISPLAY environment variable.
Replace :0.0 with the Exceed display number.
If you only ever plan to use one Exceed session at a time, then you can set the DISPLAY environment variable in your global user environment (found at Control Panel->System->Advanced->Environment Variables).
3. Use the same command window to open a Secure Shell session into the graphics server using vglconnect, described later.
This section contains two procedures:
|
If your client is also a Sun Grid Engine submit host in the same grid with one or more graphics servers, you can submit your SGE job directly from your client. However, before doing so, you will use vglconnect -k to give the graphics execution hosts access to your X display.
Sun Grid Engine will assign your job to a lightly-loaded execution host (in keeping with your job’s stated requirements), and then assign a graphics accelerator (device or X display) to your job. When your job runs, its X applications will connect back to your client. The submit host and the graphics execution hosts must share the same home directories and reside in the same domain.
Your client’s X server must allow remote TCP connections, because you don’t know which execution host SGE will select for your job. Both the application’s X11 traffic and the VirtualGL image stream are unencrypted.
1. Within any terminal window on your client, use vglconnect -k to enable a remote X program to access your client’s X server.
Note that no user or server is named on the vglconnect -k command line.
2. Within any terminal window on your client, set up the Sun Grid Engine environment.
Substitute /gridware/sge with your value for $SGE_ROOT.
Substitute /gridware/sge with your value for $SGE_ROOT.
The qstat -f command shows you available Sun Grid Engine execution hosts, queues, and any active Sun Grid Engine jobs. See Appendix C for more information on Sun Grid Engine commands.
3. Within the same terminal window (with the SGE environment), submit SGE jobs using qsub or qrsh.
See Using Sun Grid Engine to Start Your Graphics Application.
|
1. Identify the submit host to which you will connect.
2. Open a new terminal window that will be dedicated to the session on this submit host.
3. In the same terminal window, use vglconnect -x to start a session to this submit host.
Replace user with your user account name on the graphics server. If your account name is the same on the current host as on the graphics server, then you can omit the user@ portion. Replace submit-host with the hostname (or IP address) of that submit host.
4. From within the ssh session, set up the Sun Grid Engine environment.
Substitute /gridware/sge with your value for $SGE_ROOT.
Substitute /gridware/sge with your value for $SGE_ROOT.
The qstat -f command shows you available Sun Grid Engine execution hosts, queues, and any active Sun Grid Engine jobs. See Appendix C for more information on Sun Grid Engine commands.
5. From within the ssh session, submit SGE jobs using qsub or qrsh.
See the next section, Using Sun Grid Engine to Start Your Graphics Application.
There are two ways to use Sun Grid Engine to start your graphics application:
Your system administrator might have prepared a script for you that submits to Sun Grid Engine a job that executes your desired application. In this case, you can invoke such a script.
There are Sun Grid Engine job scripts you can submit to Sun Grid Engine that set Sun Grid Engine options and when your job starts executing, starts your application. Submitting such a Sun Grid Engine job script could be as simple as:
See Differences in qsub and qrsh Command Options for differences between these two commands, and an explanation of why each needs options to be appropriate for graphics job scripts.
| Note - To run Sun Grid Engine commands without the full path, ensure that the $SGE_ROOT is in your PATH variable value. |
You can override or add additional Sun Grid Engine options, such as:
In general, the syntax of this startup is one of:
qsub -now y [SGE-options] /opt/VirtualGL/bin/vglrun [vglrun-options] application-name [app-options] qrsh -b n [SGE-options] /opt/VirtualGL/bin/vglrun [vglrun-options] application-name [app-options] |
You might also want or need additional SGE-options (that is, qsub or qrsh options), such as an option that specifies the architecture of the graphics server that Sun Grid Engine selects as your execution host.
Though vglrun does not know what execution host architecture is appropriate for your application, vglrun does know that Sun Grid Engine vglrun jobs need graphics and need to save your DISPLAY or SSH_CLIENT environment variable values. VGL_* environment variable values are also saved.
vglrun specifies these options for you, which simplifies the startup (as long as you are submitting with -b n (binary no) option, which is the default for qsub but not for qrsh).
The following example startup indicates that the application can run on any Linux host:
In this case, note that Sun Grid Engine scans the vglrun script for Sun Grid Engine options but does not scan the application script that is an argument to vglrun.
| Note - The architectures named lx24-x86 and lx24-amd64 are used on Linux 2.4 kernels and also on Linux 2.6 kernels. |
Sun Grid Engine requires a full path to the job’s application or script. Sun Grid Engine does not search your PATH. Also, the path to a job’s script must be valid on the submit host, because Sun Grid Engine reads the script at submission time. (SGE saves a copy of the job script with the job, and executes its copy at job execution time.)
vglrun does use $PATH to find its argument. However, the default PATH for a Sun Grid Engine job is very limited.
If you do not provide job-specific qsub options, you can make a shell alias for qsub and vglrun, such as (csh or tcsh syntax):
submit_host% alias qrsh_vgl ’qrsh -b no /opt/VirtualGL/bin/vglrun’ submit_host% alias qsub_vgl ’qsub -now y /opt/VirtualGL/bin/vglrun’ |
These aliases must be invoked with your application added at the end, such as:
If a graphics job script does not start vglrun implicitly and you do not start vglrun manually, the graphics application will attempt to use the GLX (OpenGL for X) remote graphics technique described in Remote X Server Graphics. This attempt will be successful if $DISPLAY directs the application to your client’s X server and if your client’s X server supports the GLX graphics extension. Even in this case, GLX can be far slower than VirtualGL, especially for large graphics models.
If it is necessary to submit a job without any job script (that is, neither using an application-specific job script nor the vglrun generic job script), then you must specify all the required SGE-options on the command line. The options probably include:
You might also wish to specify other options, such as:
|
“Join Yes” (qsub only): Joins standard error into output file. |
|
|
Saves current VGL_CLIENT environment variable value with the job. |
|
|
Saves current VGL_GAMMA environment variable value with the job. |
|
If you regularly use other VGL_ environment variables, you might want their values also saved with the job.
The following is an example of a raw job submission:
This job submission is sufficient to allocate a graphics resource, but vglrun must still be run for any graphics rendering to be directed to that graphics resource. You can run vgerun later if fun_application attempts to invoke true_application. The user could create a script named true_application that actually invokes the real true_application under control of VirtualGL:
Using Sun Grid Engine simplifies the process of running your application within a TurboVNC session that is hosted on the graphics server. To run your application, perform these five procedures:
1. Set the TurboVNC password using vncpasswd (once).
See To Select a TurboVNC Password..
2. Use Sun Grid Engine to perform these actions on your behalf:
a. Select the graphics server.
b. Select the graphics accelerator device.
c. Start a TurboVNC session on the graphics server.
See To Start the TurboVNC Server Session.
3. Start a TurboVNC viewer on your client (host). Additional viewers can be started by collaborators. This step is dependent on which TurboVNC viewer you use:
See To Connect a TurboVNC Viewer to Your RUN.vncserver Session.
4. Start your application within the TurboVNC session on the graphics server. Invoke the application using vglrun, so the application is under the control of VirtualGL.
See To Start a Graphics Application Within a TurboVNC Session.
5. Eventually, terminate the TurboVNC server session (and all clients).
See To Terminate the RUN.vncserver Session.
The following five sections detail these procedures, which identify differences specific to each TurboVNC viewer.
|
Before running the TurboVNC server for the first time, select a TurboVNC password. This password must differ from your login password.
client% /opt/TurboVNC/bin/vncpasswd Using password file /home/susieq/.vnc/passwd Password: Verify: Would you like to enter a view-only password (y/n)? n |
If /opt/TurboVNC/bin is in your $PATH, then you can start vncpasswd. The view-only password is an alternate password to be given to a collaborator you wish to enable to join your TurboVNC session. The collaborator can only view your session, not move the mouse, nor enter keyboard or mouse events. The TurboVNC password (and any view-only password) is used by all sessions started by this user using the same $HOME directory.
You can change the password before any session.
|
The RUN.vncserver script saves the TurboVNC server connection information in files located in your $HOME directory. The script can only be used if the $HOME directory on the execution host is readable by the client host and only if these $HOME directories are the same. For example, the directories are NFS mounted. Consider that the root user has a different $HOME on each host and should not attempt to use the RUN.vncserver script.
Submit a job to Sun Grid Engine that starts the TurboVNC server.
A script for this purpose is part of the Sun Shared Visualization 1.1 server installation.
Your grid can have a different script for this purpose, specific to your environment. You might also want additional qsub options, such as to specify the architecture of the graphics server Sun Grid Engine selects as your execution host. The RUN.vncserver script contains options for Sun Grid Engine to require a graphics device.
The output (and any errors) from the RUN.vncserver script is appended to the file $HOME/vncserver.log. If your personal configuration files, such as $HOME/.profile or $HOME/.cshrc do not override the $PATH (or csh $path) established by the RUN.vncserver script, then vglrun (used to start a graphics application) is in your $PATH. (Design your configuration files to add paths to the $PATH that the files receive, and avoid replacing any path in $PATH.)
|
This procedure depends on whether your TurboVNC viewer is WebVNC or vncviewer. Either viewer works, as long as the graphics server and the client host share the same $HOME directory. vncviewer should perform significantly better.
Take one of the following actions:
The RUN.vncserver script creates files in your $HOME directory starting with vnc_. The file $HOME/vnc_url should redirect your browser to the execution server and port number for your TurboVNC session. If your web browser expands $HOME, you could simply enter (or select a bookmark for) $HOME/vnc_url or file://$HOME/vnc_url. If neither of these methods work, you can expand $HOME yourself and type file:// and your home directory followed by /vnc_url (for example, file:///home/susieq/vnc_url). This action redirects your browser to the URL contained in your vnc_url file.
You can also view your $HOME/vnc_url file and use your browser to view the URL contained in that file (for example, http://my_server:5802).
The web page prompts you for the TurboVNC password and then enables you to view the TurboVNC session.
When you use the RUN.vncserver Sun Grid Engine job script to start your TurboVNC server, the script saves the graphics server name and port number in the file $HOME/vnc_server in a format useful to the TurboVNC viewer. You can start the TurboVNC viewer on your client (host) by appending
‘cat $HOME/vnc_server‘ as an option to your vncviewer starting:
You can make a shell alias for this command.
Within this TurboVNC X session, you can create multiple terminals (shell windows) and start graphics applications. See To Start a Graphics Application Within a TurboVNC Session.
|
Follow these guidelines when starting a graphics application.
Within the TurboVNC session, you might type commands to the graphics server’s shell windows normally. However, when you are ready to run a graphics application, you must start VirtualGL’s vglrun command manually. vglrun interposes between the application and the GLX library so that vglrun can read back completed images from the graphics accelerator and pass the images to the TurboVNC server. The vglrun command can be in your $PATH. Otherwise, you need to use a full path to the vglrun command.
VirtualGL avoids compressing the graphics images VirtualGL gives to the TurboVNC server, because the TurboVNC server is on the same host and does not know how to decompress images. TurboVNC compresses images it sends to its viewer. Example startup from within a terminal in the TurboVNC session:
That simple startup is sufficient when the RUN.vncserver job script was used to start the TurboVNC server, since the script sets VGL_ environment variables into your environment.
In this second example, vglrun is not in the $PATH. The example uses an option to disable “spoiling”.
If you attempt to run an OpenGL application from within your TurboVNC session without remembering to use vglrun (but with $DISPLAY directing the application to your TurboVNC session), you might get an error message such as:
|
You cannot just exit the viewer (that is, quit your web browser, leave the TurboVNC page, or exit the vglviewer) because the TurboVNC server continues. After you have saved your work, you must cause the TurboVNC session and all TurboVNC foreground processes to exit.
Take one of the following actions:
When the TurboVNC server exits, vglviewer exits, but a web browser viewer prompts for a session password.
To list the X display numbers and process IDs of all TurboVNC server sessions that are currently running under your user account on this machine, type:
| Sun Shared Visualization 1.1 Software Client Administration Guide | 820-3257-12 |
|
Copyright © 2008, Sun Microsystems, Inc. All Rights Reserved.
To Prepare to Use VirtualGL From a Windows Client