SMU 5.0GA Pack NB_SMU_50_7_M README December 5, 2006
Requirement: NB_CLT_50_7_M
================================================================================
** All 5.0 MP7 Maintenance Packs for NetBackup server, client, all Add-on
products (including Storage Migrator), Database Agents, and Java GUI must be
applied so that the entire system is at the same Maintenance Pack level. **

This Maintenance Pack provides fixes to the Veritas Storage Migrator (tm) for
UNIX.
================================================================================


=================
PACK DEPENDENCIES
=================

-- Installation of this Maintenance Pack requires version 1.17.4.40 of
the Vrts_pack.install.

-- NB_CLT_50_7_M must be installed prior to installing this Maintenance
Pack.


I. DOWNLOAD INSTRUCTIONS
II. KNOWN ISSUES
III. INSTALLATION INSTRUCTIONS
IV. UNINSTALL INSTRUCTIONS
V. DESCRIPTIONS OF PROBLEMS FIXED
Current Pack
NB_SMU_50_7_M

Pack History
NB_SMU_50_6_M
NB_SMU_50_5_M
NB_SMU_50_4_M
NB_SMU_50_3_M
NB_SMU_50_1_M


=========================
I. DOWNLOAD INSTRUCTIONS
=========================
1) Download NB_SMU_50_7_M_<6 digit number>.<platform>.tar into the /tmp
directory.

where <6 digit number> is an internal tracking identifier

where <platform> is hp_11, sgi_dm, or solaris_dm

2) untar NB_SMU_50_7_M_<6 digit number>.<platform>.tar

/bin/tar xvf NB_SMU_50_7_M_<6 digit number>.<platform>.tar

This will create the files:
Vrts_pack.install
VrtsNB_SMU_50_7_M.README
VrtsNB_SMU_50_7_M.<platform>.tar.Z

=================
II. KNOWN ISSUES
=================
There are no known issues associated with this Maintenance Pack.


==============================
III. INSTALLATION INSTRUCTIONS
==============================
NOTE: If using Veritas Cluster Server with Veritas Storage Migrator, see the
Storage Migrator for Cluster Server (SMC) Readme for instructions on
freezing the cluster before performing this installation.

As root on the Veritas Storage Migrator (VSM) server:

1) Stop the VSM daemons and all VSM activity by running

/usr/openv/hsm/bin/migVSMshutdown

2) Install Maintenance Pack binaries.

cd /tmp
/bin/sh Vrts_pack.install

3) Restart daemons.

/usr/openv/hsm/bin/migVSMstartup



============================
IV. UNINSTALL INSTRUCTIONS
============================
1) Stop the VSM daemons and all VSM activity by running

/usr/openv/hsm/bin/migVSMshutdown

2) Change directory to the patch save directory.
Substitute the pack name for ${PACK} in the following command:

cd /usr/openv/pack/${PACK}/save

3) Run the un-install script:

./Vrts_pack.uninstall

4) Verify that the pack uninstalled successfully by checking
/usr/openv/pack/pack.history.

5) Restart daemons.

/usr/openv/hsm/bin/migVSMstartup



==================================
V. DESCRIPTION OF PROBLEMS FIXED
==================================
The following are descriptions of the problems fixed. Please read the entire
document before installing.

README Conventions:

Description
Describes a particular problem contained in this pack.

** Description **
Describes a problem that can lead to potential data loss. Please
read these problem descriptions carefully.

Workaround
Any available workarounds to a problem are also listed. Workarounds
can be used INSTEAD of applying the patch, however, Symantec strongly
recommends that you are at the latest patch level.

Additional Notes
Any additional information regarding a problem is included.


=============
Current pack
=============

================================================================================
Etrack Incident = ET543113

Description:
It is possible for a DMAPI read managed region to exist on a portion of a
file that is actually still on disk. In VxFS levels 3.5 and earlier this is
not a problem. In Solaris VxFS 4.0 (and later releases) this DMAPI read
managed region causes a problem when a process attempts to read the file.

The VSM daemon migd loops forever processing the event, and the event
is continually regenerated.

If this happens, the following type of entries will be seen in the
Global VSM log (/tmp/hsm.log)


01/27 15:12:40 [1]migd[29660]: INFO: token=4559 DM_EVENT_READ (17),
offset=0 len =8192 sum=8192 dmapi handle=
00000000045cc738000e114000000000000000002cc64a4b0000010000000000

01/27 15:12:40 [1]migd[29660]: INFO: token=4561 DM_EVENT_READ (17),
offset=0 len =8192 sum=8192 dmapi handle=
00000000045cc738000e114000000000000000002cc64a4b0000010000000000

etc....

This is a problem on Solaris only because VxFS 4.0 is not
supported on HP-UX systems. VxFS is not available on SGI/Irix systems.
--------------------------------------------------------------------------------
Etrack Incident = ET615600

Description:
If invoked with neither -a nor -d, migconfg would delete the specified
hsmname from the global configuration file.
--------------------------------------------------------------------------------
Etrack Incident = ET616181

Description:
migsweep sometimes failed to select any files for migration.
--------------------------------------------------------------------------------
Etrack Incident = ET634147

Description:
When backing up files on a VSM managed file system, bpbkar would keep the
FHDB open and locked, which would lock out all VSM activity for the
duration of the backup.

Workaround:
Do not run NetBackup backups and VSM processes concurrently.
--------------------------------------------------------------------------------
Etrack Incident = ET575347 ET609338 ET609487 ET609540 ET608376 ET609623 ET614668
ET612687 ET616976 ET617837 ET616940 ET622225 ET624432 ET633297 ET641183 ET699951
ET701953 ET781198 ET597210 ET598796 ET575338 ET596635 ET612761 ET787052 ET788824
ET786896 ET814652 ET575351 ET575352 ET575097 ET575330 ET575331 ET575345 ET575337
ET575335 ET577778 ET575333 ET596395 ET575334 ET575313 ET583770 ET575353 ET581028
ET575346 ET575329 ET575343 ET575308 ET575732 ET575309 ET575341 ET577306 ET575350
ET596637 ET596130 ET597780 ET601849 ET596188 ET596645 ET596654 ET596697 ET597281
ET597219 ET597298 ET596342 ET597379 ET598052 ET598865 ET599823 ET598813 ET600384
ET601396 ET601454 ET601344 ET600735 ET602205 ET600844 ET602349 ET603659 ET605285
ET602850 ET575311 ET607666 ET608687

Description:
Buffer overflow areas have been identified and corrected in daemons running
on Veritas NetBackup master, media, and client servers. Successful access
to a vulnerable Veritas NetBackup server and the ability to successfully
execute arbitrary code could potentially result in unauthorized access with
elevated privilege on a system.
================================================================================



============
Pack History
============

=============
NB_SMU_50_6_M
=============
Etrack Incident = ET331244

Description:
The miggetvol performance was very poor (eight hours for a VOLDB
with 981 entries, with an FHDB of 500MB and FNDB of 250MB).
--------------------------------------------------------------------------------
Etrack Incident = ET336949

Description:
migcopy failed for files that were larger than 30 Gigabytes.
--------------------------------------------------------------------------------
Etrack Incident = ET399090

Description:
In migd, the NFS server-daemon, starvation avoidance code creates one user
event for each attempt to read the file. The issue is that the NFS client
repeatedly tries the read request for a purged migrated file, resulting in
many user events. In addition, it causes a lot of system resources to be
used. On HP-UX 11 systems, it can cause DMAPI requests to fail with an
errno == 11.
================================================================================



=============
NB_SMU_50_5_M
=============
================================================================================
Etrack Incident = ET287029

Description:
After a system crash, the VOLDB may not reflect recently copied files that
the FHDB records as having been successfully copied. The VOLDB record
changes may not have been synchronized to the disk yet.

(All VSM Servers)
--------------------------------------------------------------------------------
Etrack Incident = ET278957

Description:
Using the Java GUI to delete a hierarchy sometimes caused migrd
to dump core.

(All VSM Servers)
--------------------------------------------------------------------------------
Etrack Incident = ET299152

Description:
migdbcheck sometimes terminated with a SEGV and core dump.

(All VSM Servers)
--------------------------------------------------------------------------------
Etrack Incident = ET310296

Description:
migrd could hang in a CPU loop while deleting hierarchies that had
scheduler items.

Workaround:
Prior to deleting hierarchy in the VSM GUI, use the GUI's scheduler
dialog to delete scheduler items.

(All VSM Servers)
--------------------------------------------------------------------------------
Etrack Incident = ET311139

Description:
migrd could hang waiting for the completion of an fsclustadm command.

(All VSM Servers)
================================================================================



=============
NB_SMU_50_4_M
=============
Description:
migstage would unnecessarily cache from secondary media if there were no
"dk" entry in the FHDB for a migrated file.

(All VSM Servers)
--------------------------------------------------------------------------------
Description:
VSM-Java did not recognize the correct selected file name after column
sorting had been used to change the order of file names in the File Browser.

(All VSM Servers)
--------------------------------------------------------------------------------
Description:
migmerge fails to backup a large FHDB, instead logging perror 72,
"value too large to be stored in datatype".

(All VSM Servers)
--------------------------------------------------------------------------------
Description:
VSM did unnecessary repeated unmounts and mounts (one for each granule of
data) of secondary media when the primary media copy was unavailable.

Workaround:
If there are continuing problems with a given VSM copy level (such as
copy 1), use the LEVEL_PREFERRED file to force VSM to begin with a different
copy.

Example: Assume the database directory for the HSM named "music" is
/usr/openv/hsm/database/music/database. Assume that mounts from level 1
are failing and that we want to always try level 2 first.

Then the command will make copy 2 the preferred cache level for this HSM.

echo 2 > /usr/openv/hsm/database/music/database/music.LEVEL_PREFERRED

(All VSM Servers)
--------------------------------------------------------------------------------
Description:
VCS Agents that are built with the agent framework can now run with
SFCFS 4.0MP1 systems.

(All NetBackup Servers: Solaris DMAPI)
--------------------------------------------------------------------------------
Description:
In attempting to filter out file system names that are not appropriate for
VSM management (for example, /var), VSM-Java filtered out some file system
names that it should not have filtered (such as, /variety).

(All VSM Servers)



=============
NB_SMU_50_3_M
=============
Description:
migVSMshutdown did not consistently terminate all VSM and VSM Java
processes correctly.

(All VSM Servers)
--------------------------------------------------------------------------------
Description:
Under certain circumstances the scheduler can erroneously reverse the order
of the next two scheduled jobs, causing some scheduled jobs to be run later
than intended.

(All VSM Servers)
--------------------------------------------------------------------------------
Description:
The migcopy executable delivered for HP-UX was RISC2.0 instead of RISC1.1,
which caused a problem on some older HP hardware.

(All VSM Servers)
--------------------------------------------------------------------------------
Description:
When migcopy is called to recall (cache) a file, it can select a granule
on a volume that is marked corrupt. That volume will be mounted, and then
the corrupt flag will be detected. The corrupt volume will be unmounted
and an alternative volume (if one exists) will be selected for the reload.

(All VSM Servers)
--------------------------------------------------------------------------------
Description:
When the VSM File Browser has directory names in the left window which
embed whitespace into the directory names, clicking these names would
not bring up directory contents to the right window.

(All VSM Servers)
--------------------------------------------------------------------------------
Description:
miglogscan could core dump if a caching operation was in progress at the
time that the log files were restarted.

(All VSM Servers)
--------------------------------------------------------------------------------
Description:
When a Ctrl-C function is used to interrupt a "migstage -w" command, the
files being staged could be left in inconsistent states. In particular, the
data blocks were often on-line, using up file system disk space even though
the file VSM state was still "purged". The file cannot be purged because
VSM thinks it is already purged.

In addition, this inconsistent state is not detected by migdbcheck.

Workaround:
The VERITAS Support group has a script and a technote that identify files
in the inconsistent state. These files have to be manually cached and
then they can be purged.

(All VSM Servers)
================================================================================


=============
NB_SMU_50_1_M
=============
Description:
migrd could hang if VxFS is not version 4.0.

(All VSM Servers)
--------------------------------------------------------------------------------
Description:
migdbcheck would sometimes dump core due to a BUS error.

(All VSM Servers)
--------------------------------------------------------------------------------
Description:
There was no way to turn off migstop quota checking for non-root users.
Now a value of -1 (bytes) will be recognized as meaning "no quota".

Workaround:
Use a global migstop file.

(All VSM Servers)
--------------------------------------------------------------------------------
Description:
migdbrpt sometimes reported an incorrect usage percentage for optical
media.

(All VSM Servers)
--------------------------------------------------------------------------------
Description:
mignospace processing did not always make space available to the purge
mark even though it was possible to do so. This fix will cause migsweep
to run if migpsweep released some space but not enough to reach the purge
mark.

(All VSM Servers)
--------------------------------------------------------------------------------
Description:
The migrd command core dumps when trying to reload its configuration from disk
because too many files are open.

(All VSM Servers)
--------------------------------------------------------------------------------
Description:
When the command migdbcheck was used with the '-p' option to update
FNDB pathnames, the command also repaired other FHDB and filesystem
inconsistencies without asking whether the repairs should be performed.

(All VSM Servers)
--------------------------------------------------------------------------------
Description:
The migmdclean command (clean VSM migration media) failed because the list
of granules associated with the volume was larger than the amount of memory
available.

(All VSM Servers)
================================================================================