These release notes support CommandPointTM SVM V2.2.1, an application for administering ptx®/SVM. CommandPoint SVM V2.2.1 is based on the VERITAS® Volume ManagerTM Storage Administrator V3.0 product from VERITAS Software Corporation, with changes and extensions to support DYNIX/ptx and ptx/SVM.
CommandPoint SVM is an optional, JavaTM-based application for administering ptx/SVM on either Symmetry® or NUMA-Q® hosts. CommandPoint SVM can be used instead of, or in conjunction with, the command-line utilities and svmadmin menu system for administering ptx/SVM volumes and disks.
The CommandPoint SVM server runs on a Symmetry or NUMA-Q host that is running ptx/SVM and executes commands to administer ptx/SVM volumes and disks. CommandPoint SVM clients provide the graphical user interface to administer ptx/SVM volumes and disks through a local or remote CommandPoint SVM server. A CommandPoint SVM client runs on a host running DYNIX/ptx® or on a PC running the Windows NT® 4.0 operating system.
This document contains information on product compatibility, release-specific installation instructions, an overview of CommandPoint SVM, how to get started, and known problems. Read this document before you install or run this release of CommandPoint SVM.
CommandPoint SVM V2.2.1 includes the following changes since CommandPoint SVM V2.2.0:
CommandPoint SVM V2.2.1 is intended for use with ptx/SVM V2.2.x on hosts running DYNIX/ptx V4.5.1 and later maintenance releases.
CommandPoint SVM V2.2.1 includes applicable problem fixes from the VERITAS Volume Manager Storage Administrator V3.0.1 product.
CommandPoint SVM V2.2.1 has been updated to use the latest Java technology. Specifically:
The CommandPoint SVM V2.2.1 client for DYNIX/ptx uses the Java 2 SDK, Standard Edition, v1.2.1 instead of the Java Development Kit (JDK), 1.1.6 used by the V2.2.0 DYNIX/ptx client. The JRE for the DYNIX/ptx client is provided by CommandPoint Base V4.5.1.
The CommandPoint SVM V2.2.1 client for Windows NT uses the Java 2 SDK, Standard Edition, v1.2.2 instead of the Java Development Kit (JDK), 1.1.6 used by the V2.2.0 Windows NT client. The JRE for the Windows NT client is distributed with CommandPoint SVM and installed if not already installed by CommandPoint ADMIN or CommandPoint Clusters.
A JavaHelp interface is used for client help text instead of the previous Jhelp interface. This new interface provides much improved searching and navigation of the CommandPoint SVM help files.
Several problems have been fixed. For more information, refer to "Fixed Problems in CommandPoint SVM V2.2.1" later in these release notes.
CommandPoint SVM V2.2.0 includes the following changes since CommandPoint SVM V2.1.0:
CommandPoint SVM V2.2.0 is intended for use with ptx/SVM V2.2.0 on hosts running DYNIX/ptx V4.5.0.
CommandPoint SVM V2.2.0 client software can be used on Windows NT hosts that also contain CommandPoint SVM V2.1.0 client software. However, CommandPoint SVM V2.2.0 client software can only be used to administer a host running CommandPoint SVM V2.2.0 server software, and CommandPoint SVM V2.1.0 client software can only be used to administer a host running CommandPoint SVM V2.1.0. For more information about version mismatch issues, refer to "Client/Server Version Mismatch Issues" later in these release notes.
User access in CommandPoint SVM V2.2.0 is based on membership to three privilege groups, cpgroup, cpsvm, and cpsvmro. Users are granted administrative access or monitoring (read-only) access based on group membership. Users with membership in cpgroup are also granted administrative access to CommandPoint Admin and CommandPoint CLUSTERS. For more information, refer to "Set Up Security for CommandPoint SVM Clients" later in these release notes.
CommandPoint SVM V2.2.0 supports the creation and importation of failover disk groups. A failover disk group is a disk group that resides on shared disks but can be accessed by only one cluster node at a time. If the host lacks cluster quorum, you cannot access or perform operations on failover disk groups or other shareable disks. For more information on failover disk groups, refer to the ptx/SVM Administration Guide or the CommandPoint SVM User's Guide as appropriate.
CommandPoint SVM V2.2.0 supports dry-run mode. When a CommandPoint SVM client is in dry-run mode and you make an administrative request, for example, to create a volume, the CommandPoint SVM server performs the usual checks, and formulates and logs the appropriate ptx/SVM commands. However, it does not execute them. Users with read-only access can run CommandPoint SVM clients only in dry-run mode. Users with administrative access can enable or disable dry-run mode. For more information, refer to "Run Tasks in Dry-Run Mode" in Chapter 2 of the CommandPoint SVM User's Guide.
CommandPoint SVM V2.2.0 client GUI includes a new window, the Volume to Disk Mapping Window. This window shows the relationships between volumes and their underlying disks. This window can also display details such as the subdisks and unused regions on each disk. The Volume to Disk Mapping window is dynamic, so the contents of this window are automatically updated when objects are added, removed, or changed. This window is accessed by selecting a disk group and then choosing the menu option Disk Groups > Disk/Volume Map. For more information, refer to "The Volume to Disk Mapping Window" in Chapter 2 of the CommandPoint SVM User's Guide.
CommandPoint SVM V2.2.0 can be used to reinitialize one or more disks. Previously, CommandPoint SVM only reinitialized disks when a disk group was destroyed. For more information, refer to "Reinitialize Disks" in Chapter 3 of the CommandPoint SVM User's Guide.
CommandPoint SVM V2.2.0 no longer enables you to encapsulate a disk when it is added to ptx/SVM or a ptx/SVM disk group. This change was made because ptx/SVM V2.2.0 does not support encapsulation or the vxencap command.
The main window of the CommandPoint SVM V2.2.0 client GUI has had the following significant changes:
The toolbar contains 4 new buttons, Grid, New, Properties (Props), and Customize (Custm). The Grid button launches a window that contains a copy of the main grid. The New button launches the New Volume dialog box. The Properties (Props) button launches the Object Properties window for a selected object. The Customize (Custm) button launches the Customize window.
The Dock button has been removed from the toolbar. Instead, you can use the toolbar handle (the thin bar to the left of the toolbar) to separate the toolbar from the main window or move the toolbar to the bottom, side, or top of the main window. To reposition the toolbar, press and hold the mouse button over the toolbar handle and drag the toolbar to its new location.
The Console menu includes the New menu option, which is used to create volumes, disk groups, and file systems. Previously this functionality was provided by the Create menu, which has been removed in CommandPoint SVM V2.2.0.
The Options menu has the menu option Customize, which displays the Customize window. This window is used to set user preferences. Previously, this window was called the Preferences window.
For more information on the main window of CommandPoint SVM or other portions of the GUI, refer to the CommandPoint SVM User's Guide.
In CommandPoint SVM V2.2.0, user preferences are saved on the host that is running the CommandPoint SVM client (DYNIX/ptx or Windows NT). The preferences file is saved in the user's home directory under .vmsa/VMpreference.prf. Previously, user preferences were saved in /var/opt/commandpoint/cpsvm on the server.
The default value for the vrts.dmNamePolicy property has changed from dgName to devName. The devName value means that if you do not explicitly specify a disk media name for a ptx/SVM disk, the device name is used. This is the same default name used by ptx/SVM. The default property value used by CommandPoint SVM V2.1.x was dgName, which caused the disk media name to be based on the disk group name.
CommandPoint SVM V2.2.0 contains several keyboard shortcuts for performing common tasks and opening windows. For more information, refer to "Keyboard Shortcuts for CommandPoint SVM" later in these release notes or refer to the "Keyboard Shortcuts" help topic accessed from the Help menu of a CommandPoint SVM client.
The CommandPoint SVM User's Guide includes a new chapter, Chapter 5, "Troubleshooting." This chapter provides information about CommandPoint SVM alerts and object states.
Several problems have been fixed. For more information, refer to "Problems Fixed in CommandPoint SVM V2.2.0" later in these release notes.
CommandPoint SVM includes the following features:
Ease of Use
CommandPoint SVM has a task-based graphical user interface. Administrators can access tasks through menus or a task list and can easily navigate and configure their systems. Administrators can use CommandPoint SVM to browse through all of the objects on the system or view detailed information about a specific object.
Security
The system administrator can restrict the use of the CommandPoint SVM client to a specific set of users. Additionally, Remote Method Invocation (RMI) traffic between the client and server is encrypted for security and all connect and disconnect operations from the CommandPoint SVM client are logged.
DYNIX/ptx Compatibility
CommandPoint SVM is compatible with all related DYNIX/ptx products; for example, ptx/SVM, ptx/CLUSTERS, ptx/EFS and ptx/CFS.
Centralized Event Logging
Important CommandPoint SVM events are logged to EES, the Error/Event Subsystem for DYNIX/ptx, on the CommandPoint SVM server host. Such events include server start up and shut down, client start up and shut down, unsuccessful attempts to establish client sessions, and internal errors. The CommandPoint SVM server also logs CommandPoint SVM client events on behalf of the client.
Scalability
CommandPoint SVM can handle systems containing a large number of disks. Administrators can view all of the objects on the system or focus on a specific object or set of objects.
Remote Administration
With CommandPoint SVM, administrators can perform ptx/SVM administration remotely or locally. The CommandPoint SVM client runs on DYNIX/ptx or Windows NT machines.
Task Status and History
A Task Request Monitor window and command log shows the DYNIX/ptx and ptx/SVM commands that are executed in response to CommandPoint SVM administration actions and the status of each command.
The following table summarizes CommandPoint SVM performance on various platforms:
System Type | CommandPoint SVM Client | CommandPoint SVM Server |
Windows NT |
OK |
NA |
NUMA-Q |
OK |
OK |
Symmetry, floating-point workarounds disableda |
Not recommendedb |
OK |
Symmetry, floating-point workarounds enableda |
Not supportedc |
Not supportedc |
a. A floating-point chip-bug workaround is considered active (and CommandPoint SVM should not be used) if the system contains 60- or 66-MHz Pentium CPUs, and the FDIV_BUG and/or FIST_BUG kernel parameters are enabled in the kernel. For more information, refer to "Floating-Point Workarounds on Symmetry Platforms and CommandPoint SVM Performance."
b. The CommandPoint SVM client runs very slowly on Symmetry systems. For example, on a NUMA-Q or Windows NT system, the client's initial window typically appears in 6-10 seconds. On a Symmetry system, this may take a minute or more.
c. In this configuration, CommandPoint SVM performance is so slow that it appears to be hung for minutes at a time. It also places a heavy load on the system due to all the floating-point traps.
If kernel workarounds for FDIV floating-point chip bugs in 60- and 66-Mhz Pentium systems are enabled on Symmetry platforms, CommandPoint SVM server and client performance is so slow that CommandPoint SVM appears to be hung. The floating-point workarounds are enabled or disabled based on the values of the FDIV_BUG and FIST_BUG kernel parameters. By default, FIST_BUG is set to 0 (zero), which disables this FIST workaround, and FDIV_BUG is set to 1 (one), which enables the FDIV workaround. If you have either or both of these kernel parameters set to 1 (one) on your Symmetry host, you cannot use CommandPoint SVM server or client on that host.
However, disabling the floating-point workarounds will allow you to run the CommandPoint SVM server with reasonable performance. (As on any Symmetry system, client performance will be mediocre; run the client on NT or a NUMA-Q.)
ATTENTION Disabling the FDIV_BUG and FIST_BUG chip-bug workarounds may allow the processors to give incorrect values on certain division and conversion operations. Review the subsection entitled "Pentium Error Workarounds" in Chapter 5 of the DYNIX/ptx System Configuration and Performance Guide to evaluate whether your site should disable these workarounds.
Complete the following steps to disable the floating-point workarounds:
Determine whether the floating-point workarounds are enabled by issuing the following commands:
bp -s /unix /dev/kmem fdiv_bug
bp -s /unix /dev/kmem fist_bug
A response of 0x1 means the workaround is enabled, 0x0 means the workaround is disabled. Note that setting fdiv_bug or fist_bug to 0 using the bp command will not disable the workarounds. You must boot a new kernel.
If either of the floating-point workarounds are enabled, use ptx/ADMIN to set the values of the FDIV_BUG and FIST_BUG kernel parameters to 0 (zero) as needed. (A value of zero disables the workaround.) For more information about configuring the kernel, refer to the DYNIX/ptx System Configuration and Performance Guide.
Recompile and boot with the newly configured kernel.
The following software products are required on the Symmetry or NUMA-Q host that will be running the CommandPoint SVM server or client software:
DYNIX/ptx V4.5.1 or later
ptx/SVM V2.2.1 or later
ptx/LAN V4.7.1 or later
ptx/TCP/IP V4.6.1 or later
ptx/XWM V4.6.1
CommandPoint Base V4.5.1
The Windows NT client for CommandPoint SVM requires the following software products:
ATTENTION Do not use the VCS console on a NUMA-Q system to run CommandPoint SVM.
If you plan to use the Windows NT-compatible client to administer your ptx/SVM system, then the following minimum requirements apply to the PC that you will be using. (These requirements are in addition to the DYNIX/ptx requirements listed in the previous section.)
ATTENTION The minimum configuration will allow you to run all three CommandPoint products (CommandPoint Admin, CommandPoint Clusters and Command Point SVM) simultaneously. However, the performance will be better if you use the recommended hardware configuration.
Whichever configuration you choose to use, the performance of the system will be impacted by the number and size of the applications that you run simultaneously.
The minimum hardware requirements are:
The recommended hardware requirements are:
266MHz (Pentium II) (or faster) CPU
64 MB Memory
1280x1024 Video
21" Display
CD-ROM drive
Network Interface Card
Installing CommandPoint SVM software on DYNIX/ptx requires 23 MB, which includes 16 MB for the zip file containing the CommandPoint SVM client for Windows NT. (On DYNIX/ptx, the JRE is provided by CommandPoint Base.)
Installing CommandPoint SVM software on Windows NT requires 23 MB, which includes 21 MB for JRE V1.2.2. Note that the JRE is shared with CommandPoint ADMIN and CommandPoint Clusters and is only installed once on your system.
The CommandPoint SVM server software must be installed on the DYNIX/ptx host that you want to administer. The client software can be installed on the same host that you want to administer, on any other DYNIX/ptx host, or an a PC running Windows NT.
The CommandPoint SVM server and client software for DYNIX/ptx is located on the DYNIX/ptx Layered Products Software, Volume 2 CD, along with the CommandPoint Base software. Other required software for use with CommandPoint SVM (including DYNIX/ptx, ptx/SVM, ptx/LAN, ptx/TCP/IP, and ptx/XWM) is located on the DYNIX/ptx V4.5.1 and Layered Products Software, Volume 1 CD. You can install all of these software products through the installation process described in the DYNIX/ptx V4.5.1 and Layered Products Software Installation Release Notes.
There are two methods of performing a Windows NT client installation:
Use the DYNIX/ptx Layered Products Software, Volume 2 CD to install the Windows NT version of the CommandPoint SVM client onto the Windows NT system.
Use ftp from the server to obtain a self-extracting zip file that contains the Windows NT version of the CommandPoint SVM client.
Note that multiple versions of the client can exist concurrently on the same Windows NT system.
To use the DYNIX/ptx Layered Products Software, Volume 2 CD to load the CommandPoint SVM client software on a Windows NT system, load the CD and click on the executable file cpsvm\setup.exe.
Follow the standard installation.
To use ftp to obtain and then install the CommandPoint SVM client software on Windows NT, perform the following steps:
ATTENTION You must set the ftp file transfer type to binary to support binary image transfer. Do not use the ascii file transfer type.
From the host that contains the CommandPoint SVM server software, use the ftp command to transfer the file /opt/commandpoint/cpsvm/NTclient/CommandPointSVM.exe to a temporary directory on your PC.
From your PC, double click on the CommandPointSVM.exe file.
During the Windows NT installation of CommandPoint SVM, you will be prompted to respond to a licensing query. In order to install CommandPoint SVM you must agree to the terms of the electronic license by clicking on the Yes button which will allow the installation to proceed. (If you answer No, the installation will stop).
Answering Yes allows you to install and use the Windows NT Client component of CommandPoint SVM on one or more workstations which will be used for the purpose of administering ptx/SVM systems. In this regard, the Windows NT Client component is an exception to Paragraph 1.2 of the Software License Agreement for CommandPoint SVM.
CommandPoint SVM does not require any specific changes to the eXceed environment for CommandPoint SVM clients running on DYNIX/ptx. Modifying eXceed for CommandPoint Admin or CommandPoint Clusters as described in the CommandPoint Admin V4.5.1 Overview and Release Notes and the CommandPoint Clusters V2.2.1 Overview and Release Notes does not adversely impact CommandPoint SVM clients. However, if you follow the procedures to modify font settings in eXceed, then do not configure fonts directly from CommandPoint SVM (via Options->Properties->Font). Doing so will cause the font sizes to increase.
After you install the CommandPoint SVM server, you can specify which users will have access. By default, only root can run the CommandPoint SVM client. Before you set up lists of users with permission to use the CommandPoint SVM client, you should understand the default group configuration and levels of authorized access. Then, you can create the groups you need for CommandPoint SVM. The following sections describe these topics:
The /opt/commandpoint/cpsvm/vxvm/properties file is installed on the system when CommandPoint SVM is installed. Among other configuration properties, it contains the following default entries:
# server configuration properties # vrts.server.adminGroup=cpsvm,cpgroup vrts.server.readonlyGroup=cpsvmro
The vrts.server.adminGroup property defines those groups that have administration access to CommandPoint SVM. Administration access provides complete access to administer a host with CommandPoint SVM. By default, users in cpsvm and cpgroup are defined to have administration access to CommandPoint SVM. The cpgroup is a special group that is configured by default so that users in this group have complete administration and monitoring access to a DYNIX/ptx system or cluster using CommandPoint SVM, CommandPoint Clusters, or CommandPoint Admin. By default, members of the cpsvm group do not have administration access to CommandPoint Clusters or CommandPoint Admin.
The vrts.server.readonlyGroup property defines those groups that have only monitoring access to CommandPoint SVM. Monitoring (or read-only) access provides only information about the CommandPoint SVM server host, such as disk and disk group configuration. It does not allow the user to take actions or execute commands. Users can, however, view commands run in dry-run mode. By default, the cpsvmro group is defined to have monitoring access and members of the cpsvmro group do not have administration access to CommandPoint Clusters or CommandPoint Admin.
Instead of specifying group names for the vrts.server.readonlyGroup property, you can choose to assign monitoring access to all valid users on the server host. To do so, enter an asterisk (*) as the value of this property. For example:
vrts.server.readonlyGroup=*
If this is the first installation of a CommandPoint product on the host, then each of these privilege groups must be added to the group file (/etc/group) or NIS (Network Information Name Service) group table on the host to be administered. If this is the first installation of CommandPoint SVM on a host that already has another CommandPoint product installed, then you only need to add cpsvm and cpsvmro to the /etc/group file or NIS group table. In any event, ensure that all groups listed in the vrts.server.adminGroup property and the vrts.server.readonlyGroup property exist on the host. If none of the groups defined in these two properties exist, then only root can run the CommandPoint SVM client.
The cpsvm group should include the user names of any users (including root) who require administrative access to the CommandPoint SVM client. The cpsvmro group should include the user names of those users who require only monitoring access to the CommandPoint SVM client. Use the ptx/ADMIN menu system or CommandPoint Admin to add users to the privilege groups, as you would add users to other DYNIX/ptx groups. For example, the lines defining the groups cpsvm and cpsvmro in the /etc/group file could look as follows:
cpsvm::998:root,ruth,joe
cpsvmro::999:bill,mary
cpsvm and cpsvmro are the default group names. However, you can change these names to different names by setting the group properties to different groups. To do so, edit the following lines in the file /opt/commandpoint/cpsvm/vxvm/properties:
vrts.server.adminGroup=new_groupname1
vrts.server.readonlyGroup=new_groupname2
Ensure that the group names you define in the vrts.server.adminGroup property and the vrts.server.readOnlyGroup property are the same names defined in the /etc/group file or NIS group table.
Once you have set up security for CommandPoint SVM, you can monitor access to it by reviewing the contents of the access log file on the CommandPoint SVM server host. The access log file contains information about all client connections (who is logging in). By default, the access log file is located in the directory /var/opt/commandpoint/cpsvm/logs.
The access log file contains entries similar to the following:
Fri Jan 23 10:22:17 PST 1998: user xyz login succeeded Fri Jan 23 10:59:52 PST 1998: user xyz login failed with error "User password invalid"
Entries for failed access may be logged multiple times. This is due to a security requirement and is not an error.
Additionally, CommandPoint SVM logs these same client-connection messages to EES. Note that CommandPoint SVM logs other messages, for example server start up and shut down messages and internal errors, to EES as well.
The CommandPoint SVM server and CommandPoint SVM client can operate in several different modes depending on how the CommandPoint SVM server is started and to which group a user belongs when they invoke a CommandPoint SVM client. The various server and client operational modes are explained as follows:
Server read-only mode is disabled by editing the properties file and then restarting the CommandPoint SVM server. For more information, refer to "Start the CommandPoint SVM Server in Read-Only Mode" later in these release notes.
Dry-run mode is applied on a per-client basis. For users with administration access to CommandPoint SVM (belonging to the groups cpsvm or cpgroup), client dry-run mode can be enabled or disabled from the Options menu on the main window of the CommandPoint SVM client.
Client read-only mode is disabled by editing the properties file, restarting the CommandPoint SVM server in administration mode, and then starting a new CommandPoint SVM client. For more information, refer to "Start the CommandPoint SVM Server in Read-Only Mode" later in these release notes.
The following table shows the relationship between the operational mode of the CommandPoint SVM server and the privilege group of the user in determining the operational mode of a CommandPoint SVM client.
Server Mode | Group of User Running Client | Resulting Client Mode |
Administration |
cpsvm, cpgroup |
Administration |
Administration |
cpsvmro |
Dry-run |
Read-only |
cpsvm, cpsvmro, cpgroup |
Read-only |
Before you can use CommandPoint SVM to monitor and administer ptx/SVM you must start the CommandPoint SVM server on the host to be administered. By default, the CommandPoint SVM server operates in administration mode. For information on starting the CommandPoint SVM server in read-only mode, refer to "Start the CommandPoint SVM Server in Read-Only Mode" later in these release notes.
ATTENTION Before you can use CommandPoint SVM to administer ptx/SVM, you must enable the volume configuration daemon (vxconfigd) and create the rootdg disk group. You will not be able to create ptx/SVM objects or perform any other ptx/SVM operations with CommandPoint SVM until vxconfigd is running and the rootdg disk group is created. The procedure to do these tasks is described in Chapter 2 of the ptx/SVM Administration Guide under "Start the ptx/SVM Configuration Daemon."
Complete the following steps to start the CommandPoint SVM server :
Log in as superuser:
$ su root
Change directories to the directory where CommandPoint SVM is installed:
# cd /opt/commandpoint/cpsvm/bin
Start the CommandPoint SVM server:
# ./cpsvmSvr.sh &
ATTENTION If you are using ksh or sh, prefix the command with nohup (for example, nohup ./cpsvmSvr.sh &).
Three lines of status messages are output to the screen (or nohup.out) almost immediately, but the remainder of the server status messages are written to a file named server.log in the /var/opt/commandpoint/cpsvm/logs directory.
If the CommandPoint SVM server starts successfully, the server.log file should contain the following line after a few seconds:
rebound //host:2410/vrts.remote.vrtsServer
Use the following command to confirm that the CommandPoint SVM server is running:
./cpsvmSvr.sh -q
To stop the CommandPoint SVM server, use the following command:
./cpsvmSvr.sh -k
This will kill all processes started by the previous invocation of cpsvmSvr.sh. To verify that all such processes are killed, run the following command and verify that only the egrep process itself is listed in the output:
# ps -ef | egrep 'vrts|cmdserver'
ATTENTION If the CommandPoint SVM server is terminated--deliberately or otherwise--you should also terminate any CommandPoint SVM clients that were connected to that server process. A newly started server will not connect to pre-existing clients.
By default, the CommandPoint SVM server starts in administration mode. However, the CommandPoint SVM server can be configured in a read-only mode that is useful for monitoring or browsing purposes. Read-only mode allows the administrator to view objects on the system through CommandPoint SVM, but prevents administrative actions from taking effect. This mode is enabled via the properties file (/opt/commandpoint/cpsvm/vxvm/properties).
ATTENTION You must stop and restart the CommandPoint SVM server when changing to or from read-only mode. Furthermore, when the CommandPoint SVM server is operating in read-only mode, no CommandPoint SVM clients can administer ptx/SVM on that host; they can only monitor or browse.
To start the CommandPoint SVM server in read-only mode, change the properties file (/opt/commandpoint/cpsvm/vxvm/properties) so that it contains the following line:
vrts.server.readonly=true
The user interface remains the same in read-only mode. The only difference from administration mode is that when you try to apply a configuration change an error message is displayed indicating that the CommandPoint SVM server is operating in read-only mode. (Note that no task is registered in the Request Monitor window, so you are unable to see what command would have been executed.)
To restore the CommandPoint SVM server to administration mode, use the following line in the properties file and then stop and restart the CommandPoint SVM server:
vrts.server.readonly=false
The CommandPoint SVM client provides a graphical user interface to monitor and administer ptx/SVM volumes and disks through a local or remote CommandPoint SVM server. The CommandPoint SVM client can be run from DYNIX/ptx on a Symmetry or NUMA-Q host or from Windows NT on a remote PC. Before you can use a CommandPoint SVM client to monitor and administer ptx/SVM you must first start the CommandPoint SVM server on the host to be administered.
ATTENTION Only users with appropriate privileges can run CommandPoint SVM clients. Refer to "Set up Security for CommandPoint SVM" earlier in these release notes for more information.
If the CommandPoint SVM server was started in administration mode, then the group membership of the user determines the mode of operation for the CommandPoint SVM client. That is, users in the cpsvm group have full administrative access while users in the cpsvmro group only have monitoring access. If the CommandPoint SVM server was started in read-only mode, then all CommandPoint SVM clients run in read-only mode. For more information on operational modes of CommandPoint SVM, refer to "Operational Modes for the CommandPoint SVM Server and Client" earlier in these release notes.
If, after the CommandPoint SVM main window appears, the Object Tree is not populated within 10 seconds or so, the server system may be having trouble finding the client system on the IP network. From the server system, try issuing the /etc/ping n1.n2.n3.n4 command, where n1.n2.n2.n4 is the client's numeric Internet address. If the ping fails, the server cannot communicate with the client.
To start the CommandPoint SVM client on DYNIX/ptx, complete the following steps:
Set the DISPLAY environment variable to the X server (typically your PC) on which you want to display the CommandPoint SVM client. For example, if your X server is w-smith.acme.com and you are using Korn shell, enter the following command at the UNIX prompt:
# export DISPLAY=w-smith.acme.com:0.0
Alternatively, you can set the DISPLAY environment variable in your .profile file (for Korn shell) or .login file (for C shell) in your home directory.
Enter the following command to start the CommandPoint SVM client for the local host:
$ /usr/bin/cpsvm
Alternatively, you can designate a remote host to administer when you enter the cpsvm command. The syntax is as follows:
$ /usr/bin/cpsvm remote_hostname
When the Session Initiation dialog box is displayed, enter the name of the DYNIX/ptx host that you want to administer and your login and password on that host, and then click Ok. By default, the name of the local host is already entered.
Entries for your user name and password must exist in the password file or corresponding NIS (Network Information Name Service) table on the machine to be administered. Your user name must also be included in one of the CommandPoint SVM group entries (cpsvm, cpgroup, or cpsvmro, by default).
ATTENTION It can take several seconds for the Session Initiation dialog box to appear. Note that if you are running the CommandPoint SVM client on a Symmetry platform (which is not recommended), it can take even longer, possibly a minute or more.
Once the Session Initiation dialog box is displayed and you have entered your name and password, you can then click Ok to continue.
If the CommandPoint SVM server is running but not responding during startup of a CommandPoint SVM client, that client can hang. Also, the CommandPoint SVM client can sometimes become unresponsive after startup. If the client hangs, kill the cpsvm process listed in the ps output and then restart the client.
If this action does not resolve the situation, kill the cpsvm process, stop the CommandPoint SVM server with the ./cpsvmSvr.sh -k command, restart it with the ./cpsvmSvr.sh command, and then restart the client.
To start the CommandPoint SVM client on Windows NT to administer a remote DYNIX/ptx host, complete the following steps:
Choose Start->Programs->Sequent-> CommandPoint SVM V2.2.1 from the Windows NT task bar. Alternatively, you can double-click on the CommandPoint SVM program icon.
When the Session Initiation dialog box is displayed, enter the name of the DYNIX/ptx host that you want to administer and the login and password, and then click Ok.
ATTENTION It can take several seconds for the Session Initiation dialog box to appear.
If the CommandPoint SVM server is running but not responding during startup of a CommandPoint SVM client, that client can hang. When this happens, the client might not be listed in the Applications tab of the Task Manager; instead it might be listed in the Processes tab as jrew.exe. In this case, kill the jrew.exe process. Note that other Java-based applications such as CommandPoint Admin clients and CommandPoint Clusters clients also show up as jrew.exe processes.
If the CommandPoint SVM client should become unresponsive after startup, you can kill it just like any other Windows NT application using the Task Manager.
If killing and restarting the client does not resolve the situation, then kill the client on your PC, stop the CommandPoint SVM server on the DYNIX/ptx host with the ./cpsvmSvr.sh -k command, restart it with the ./cpsvmSvr.sh command, and then restart the client on your PC.
If you start a CommandPoint SVM client (DYNIX/ptx or Windows NT) for a CommandPoint SVM server that has a different, incompatible version of CommandPoint SVM, the CommandPoint SVM client will not start. Instead the Client/Server Version Mismatch dialog box is displayed alerting you to the situation.
To determine the CommandPoint SVM version on your server host, login to that host as root and execute the following commands:
# cd /opt/commandpoint/cpsvm/bin
# ./cpsvmSvr.sh -V
The cpsvmSvr.sh -V command reports the version of the CommandPoint SVM server software. To administer that host, you must run a CommandPoint SVM client with the same version.
Once you have successfully started the CommandPoint SVM server and client, the CommandPoint SVM main window will appear. See the CommandPoint SVM User's Guide for a description of the components of CommandPoint SVM and for information on how to set up and use CommandPoint SVM.
If a disk fails, yielding I/O errors on the disk, the situation may or may not be detected and reported by CommandPoint SVM. The CommandPoint SVM server maintains its own view of the ptx/SVM configuration, and updates that view based on event and configuration information from ptx/SVM, propagating those updates to the CommandPoint SVM clients.
In some cases, a disk failure results in no change in the ptx/SVM configuration, and thus no change in the CommandPoint SVM display. This is the case, for example, if the failed disk contains plexes only from unmirrored volumes.
For this reason, we recommend against using CommandPoint SVM as a monitor of disk health.
CommandPoint SVM on DYNIX/ptx includes the following man pages. (Windows NT does not provide man pages.) To view these man pages, use the man command at the UNIX® prompt.
CommandPoint SVM includes online help files that are accessed by clicking the Help button in a dialog box or selecting the appropriate item from the Help menu on the main CommandPoint SVM window.
Additionally, the following documents are available on the online documentation CD or at http://webdocs.numaq.ibm.com:
CommandPoint SVM User's Guide
ptx/SVM Administration Guide
Printing online help from a CommandPoint SVM client running on DYNIX/ptx or Windows NT is very slow and can be problematic. Before printing from a CommandPoint SVM client, refer to the "Open Problems" section and review problem reports "Printing Problems with Windows NT Clients (251583)" and "Printing Problems with DYNIX/ptx Clients (251585)".
Furthermore, when you print help text from CommandPoint SVM to a file, you must specify a full pathname or the file will be created in the directory /opt/commandpoint/cpsvm/vxvm/java.
This section lists the following problem report summaries:
The numbers in parentheses identify the problems in the problem-tracking system.
The following problems have been fixed in CommandPoint SVM V2.2.1:
(239541) The Mirror Layout Details dialog box did not provide default values for fields when a striped layout was chosen.
(239649) CommandPoint SVM online help could not be printed from Windows NT clients.
(239984) The Mount Details dialog box did not provide any help for selecting a volume or partition for use as a CFS log device.
(240329) Sometimes when closing a dialog box the CommandPoint SVM Windows NT client went to the background and the application previously in the background came to the foreground.
(244132) On DYNIX/ptx clients, searching CommandPoint SVM help pages was extremely slow.
(245803, 249545) The free disk pool listed partitions used for swap, filesystems, and the quorum disk, which were not actually available for use by ptx/SVM. Additionally, CommandPoint SVM would incorrectly try to add the quorum disk to ptx/SVM if the quorum disk was selected for an Add Disk operation.
(246523) Sometimes CommandPoint SVM Clients Hung on NT or DYNIX/ptx because of ptx/JSE problems.
(247201) CommandPoint SVM incorrectly allowed shared disk groups to be created with non-shareable disks.
(247323) When the number of disk devices being added to an existing disk group did not match the number of disk names given, the unclear error message Parameter Count mismatch was displayed. Now the message displayed is Number of names does not match number of devices.
(247327) The CommandPoint SVM NT client incorrectly prefilled the Server Host field of the Session Initiation dialog box with the name of the PC. Now this field is correctly left blank.
(247379) When the CommandPoint SVM NT client was minimized, the graphics on the icon were not sharp.
(247922) The cpsvmSvr.sh(1M) manpage did not document the -q and -h options.
(248616) The choice of filesystem block sizes presented by the Mkfs Details dialog box for EFS/CFS filesystems was incorrect.
(249062) Reinitializing multiple disks from the Reinitialize Disk dialog box caused CommandPoint SVM to generate an incorrect command that was rejected by ptx/SVM.
(249543) Help text incorrectly contained references to disk encapsulation.
(249600) CommandPoint SVM incorrectly allowed Dirty Region Logging (DRL) to be enabled on shared volumes. (DRL is not currently supported by ptx/SVM.)
The following problems have been fixed in CommandPoint SVM V2.2.0:
(238845) Renaming a ptx/SVM disk sometimes caused the disk to be listed multiple times in the Object Grid of the CommandPoint SVM client interface.
(239632, 239738) If the size of a CommandPoint SVM window was changed by dragging the lower right corner, the window stayed resized only until an object or group was clicked, which then caused the window to be redrawn at its original size.
(239637) The menu bar in the CommandPoint SVM client Main window was incorrectly displayed when uninitialized disks were selected.
(239745, 240481) When a disk group that contained a nopriv disk was deported, the nopriv disk completely disappeared from CommandPoint SVM's view. Then, when such a disk group was reimported, its nopriv disks were incorrectly listed as Free.
(239873, 241652) CommandPoint SVM clients sometimes reported cryptic errors when the CommandPoint server died.
(240000) There was no way to start the CommandPoint SVM server automatically at boot time.
(240328) CommandPoint SVM remounted CFS filesystems as EFS filesystems without checking if you wanted to mount them as CFS.
(241346) When a shared disk group was renamed, it incorrectly became unshared.
(242860) CommandPoint SVM did not always immediately detect when cluster quorum was regained.
(242920) When the maxsize button on the Create Volume dialog box was used, the settings for a striped layout (number of columns and stripe unit size) incorrectly reverted to their default settings.
(242921) Removing a volume from a disk group sometimes resulted in the removal of /etc/vfstab entries for other volumes with similar names.
(242997) The CommandPoint SVM NT client was not startable from the CommandPoint Admin launcher.
(243408) Specifying a ksh startup file in the ENV environment variable that set the CLASSPATH and possibly other environment variables used by Java sometimes caused problems with the CommandPoint SVM scripts.
(244337) To avoid CommandPoint SVM crashes on a big system, you sometimes had to adjust a script so that Java allocated more memory for the server.
(245784) CommandPoint SVM used only vxresize when resizing volumes when vxassist should have been used in some situations.
(246134) Under certain conditions, trailing spaces in the properties file yielded incorrect behavior.
(246244) The NT client for CommandPoint SVM would not install unless there were about 50 MB of free space on the disk where the software was to be installed.
(246457) Certain CommandPoint SVM events logged to the Error and Event Subsystem (EES) included the date and time twice.
(246522) The cmdserver daemon died when the shell that launched cpsvmSvr.sh (the CommandPoint SVM server) exited.
(247385) Due to a ptx/SVM defect (#248432), CommandPoint SVM on a slave node in a cluster sometimes failed to detect when a shared disk group was imported.
(248881) The CommandPoint SVM server had several problems reporting events related to disk failures.
The following problems have been reported against CommandPoint SVM.
Every time the CommandPoint SVM server rejects a client connection (for example, due to an invalid user name or password), it logs six messages to the error event subsystem (EES). Three errors are event type 3004 and three are event type 2002.
Workaround. None. Ignore the redundant messages in the EES.
CommandPoint SVM incorrectly reports that the size of every uninitialized disk is zero.
Workaround. Use the DYNIX/ptx diskid command.
The cursor in the CommandPoint SVM main window occasionally changes to the "move" cursor (shaped like a cross) when items in the Object Tree or Grid are clicked. Also, sometimes a wait cursor won't change back to the regular cursor until you move the cursor.
Workaround. Proceed as if it were the regular ("arrow") cursor.
On at least one occasion, a CommandPoint SVM process died with the following message:
Xlib: unexpected async reply ...
This results from a rarely seen defect in ptx/JSE.
Workaround. Restart the affected CommandPoint SVM component.
The Task Request Monitor displays the Start Time and Finish Time for each task. These columns are sorted alphabetically rather than chronologically. These are usually the same over short stretches, but there are many exceptions (for example, 9:59 is "higher" than 10:00). In such situations, new tasks do not show up at the top of the list.
Workaround. In the Task Request Monitor, use Console -> Remove Finished Tasks occasionally to clear out old tasks.
If you modify your system's configuration by adding or removing a disk controller, this change will not be reflected in the Controller's node of any object tree presented by CommandPoint SVM.
However, newly added controllers and their disks will show up as appropriate in other portions of the GUI. (You may need to run System -> Scan Disks to make CommandPoint SVM aware of the change.)
Workaround. Shut down and restart the CommandPoint SVM client(s) and server.
When the CommandPoint SVM client for DYNIX/ptx displays the Volume Layout Details window, the window draws very slowly. For example, you can see the lines, labels, and other components being drawn one by one. This problem seems to be a problem in the Java 2 SDK and has been seen in both the Java 2 SDK v1.2.1 and v1.2.2 on Sun Microsystems® Solaris® platforms. This problem has not been seen with the Windows NT client for CommandPoint SVM.
Workaround. None.
The DYNIX/ptx client for CommandPoint SVM frequently reports messages about java.lang.NullPointerExceptions when performing JavaHelp operations. These exceptions do not affect the operation of the CommandPoint SVM client or the help system, but the messages are very lengthy, numerous and unnecessary. An example of just one exception message follows:
Exception occurred during event dispatching: java.lang.NullPointerException at javax.swing.text.ComponentView.setComponentParent(ComponentView.java: 305) at javax.swing.text.ComponentView$1.run(ComponentView.java:267) at javax.swing.SystemEventQueueUtilities.processRunnableEvent(SystemEven tQueueUtilities.java:354) at javax.swing.SystemEventQueueUtilities.access$0(SystemEventQueueUtilit ies.java:350) at javax.swing.SystemEventQueueUtilities$RunnableTarget.processEvent(Sys temEventQueueUtilities.java:391) at java.awt.Component.dispatchEventImpl(Component.java:2376) at java.awt.Component.dispatchEvent(Component.java:2289) at java.awt.EventQueue.dispatchEvent(EventQueue.java:258) at java.awt.EventDispatchThread.run(EventDispatchThread.java:68)
These messages are due to a known problem in the the JavaHelp API provided by Sun Microsystems. These messages originate from the java.swing and java.help code.
Workaround. Redirect stdout and stderr from CommandPoint SVM clients run on DYNIX/ptx to /dev/null. For example:
# cpsvm > /dev/null 2>&1
The Session Initiation dialog box is the first dialog box displayed after you start a CommandPoint SVM client. You cannot connect the client to a CommandPoint SVM server until you complete this dialog.
However, sometimes when the CommandPoint SVM client for Windows NT is started, this dialog box is displayed as the bottommost, background window instead of being displayed as the topmost, foreground window as should be the case. Furthermore, since the client has not yet started a session with a CommandPoint SVM server, there is no CommandPoint SVM client task in the taskbar.
Workaround. Minimize all open windows until the Session Initiation dialog box is displayed.
The CommandPoint SVM client for Windows NT has the following problems related to printing:
The Windows NT client takes an extremely long time (like more than 20 minutes) to print the help text for the Main window. While this help topic is printing, the PC can be very unresponsive and appear to be hung. The Main window help is the only help text topic that contains a graphic, which is likely the cause of the printing delay. All other help text topics print in a reasonable amount of time for Windows NT clients.
If you select "Print to file" on the Print Dialog box and then click OK, the Print to File dialog box is not displayed as the topmost, foreground window. Instead, this dialog box is displayed as a minimized window in the taskbar. (You can raise the window and use it without any problems.)
The Print Dialog box shows print ranges from 1 to 9999 pages for each of the help topics. This is confusing since each help topic is actually defined as one page.
Workaround. None.
The CommandPoint SVM client for DYNIX/ptx has the following problems related to printing:
Clicking on the Page Setup icon in the JavaHelp window does not do anything.
When you print a help topic to a file or printer, the file that is generated is extremely large (like 18 MB for a one-page help file). Due to the size of the print files being created, printing takes an extremely long time; so long that it appears that the CommandPoint SVM client has hung when in fact it has not and will eventually complete the task.
Once the file has been printed, the CommandPoint SVM client does not display a dialog box confirming that the task has completed. If you are printing help topics to a printer file, you can determine if the print file is complete by watching the size of the file. When the file size stops increasing, the print file has completed.
Workaround. When using the DYNIX/ptx client to print help topics, there are no workarounds to these problems. However, you can use the Windows NT client to control the page setup and to quickly print most help topics. Before using the Windows NT client to printing help topics, refer to the open problem report Printing Problems with Windows NT Clients (251583) earlier in this section.
Under certain circumstances, CommandPoint SVM clients cannot connect to a CommandPoint SVM server. The root cause for this problem is a Java bug that sometimes causes the Java 2 runtime environment to return the wrong name for the CommandPoint SVM server. When this problem occurs, the name returned to the client for the server is the official hostname defined for the IP address 127.0.0.1 in the /etc/hosts file. (This result is analogous to the uname(1) or hostname(1) commands stating that the name of the host is localhost.)
CommandPoint SVM successfully works around this bug only if the official hostname returned is localhost and not an alias like localhost.acme.com. The official hostname is the name listed in the first field after the IP address entry in the /etc/hosts file.
Workaround. If you suspect this problem, examine the /var/opt/commandpoint/cpsvm/logs/server.log file. If the message line that starts with rebound includes a name like localhost.acme.com, change the /etc/hosts file on the server so that it contains localhost as the official hostname for the IP address 127.0.0.1. For example, edit the line so that it is in the following format:
127.0.0.1 localhost localhost.acme.com