Veritas Volume Manager 5.0 Release Notes (5900-0593, March 2010)

Veritas Volume Manager 5.0 Release Notes
Known Issues
Chapter 1 29
The vxdg command deport operation is known to fail intermittently because VxVM
daemons may still be accessing the disk group (for a few seconds) to handle configuration
backup. This is a transient situation.
If you are using Serviceguard with VxVM disk group in your package control script, you
will see the following errors in the package control log output during package halt:
VxVM vxdg ERROR V-5-1-584 Disk group dg_name: Some volumes in the disk group are in use
ERROR: Function deactivate_disk_group
ERROR: Failed to deport dg_name
If you are experiencing this problem outside of the Serviceguard environment, you can
workaround this problem by manually re-running vxdg deport to deport the disk group.
If you are experiencing this problem in the Serviceguard package halt situation, you can
do the following:
— If the package is configured as a failfast package, the node will TOC. After the node
TOC, all disk groups should be cleaned up as part of the reboot process.
— If this is a non-failfast package, the package halt operation will fail. You should check
the package control script output and perform necessary clean up as needed.
Veritas Enterprise Administrator Issues
NOTE Note: Refer to the Veritas Installation Guide for information on how to set up
and start the VEA server and client.
• Storage Agent dumps core if there are many LUNs
Configurations with more than 10240 LUNs can cause the Storage Agent to dump core in
the directory /var/vx/isis.
Workaround:
1. Rename the Device Discovery Layer (DDL) library file:
# mv /opt/VRTSddlpr/lib/ddl.sl /opt/VRTSddlpr/lib/ddl.sl.orig
This prevents the DDL provider from loading, but has the effect of making enclosure,
path, and controller objects no longer available in the VEA client GUI.
2. Restart the Storage Agent:
# /opt/VRTSobc/pal33/bin/vxpal -a StorageAgent
• Name service switch configuration file