Veritas Volume Manager 5.0 Release Notes HP-UX 11i v3 (5992-1952, August 2011)

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
Workaround
Outside Serviceguard Environment
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.
Inside Serviceguard Environment
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 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.
• Problem
After system reboot, occasionally, the following message is logged in /var/adm/syslog.log
file:
vmunix: NOTICE: reading the krs value is failed rc 2
Workaround
You can ignore this message. The condition reported is handled accurately by VxVM and is
not an error condition. It is expected behavior. The message will be reworded to avoid
confusion in future releases.
• Problem
VxVM 5.0 may not be able to change the naming scheme of some of the disks when the disk
naming scheme is set to osn and the mode is new.
This problem occurs when the combined length of the disk group name and the volume name
exceeds nine characters.
Workaround
Rename the disk group name or the volume name such that their combined length does not
exceed nine characters. For more information, see QXCR1001087701 at: http://itrc.hp.com
Veritas Enterprise Administrator Issues
NOTE: See Veritas 5.0 Installation Guide for information on setting up and starting the VEA
server and client.
The following VEA issues are known:
• Problem
Configurations with more than 10240 LUNs can cause the Storage Agent to dump core in
the directory /var/vx/isis.
Workaround
As a workaround complete the following steps:
1. Rename the Device Discovery Layer (DDL) library file:
# mv /opt/VRTSddlpr/lib/ddl.sl /opt/VRTSddlpr/lib/ddl.sl.orig
Known Problems And Workarounds 35