HP-UX Logical Volume Manager and MirrorDisk/UX Release Notes HP-UX 11i v3 (March 2012)

Fixed issues in this version
The following table lists the known LVM and MirrorDisk/UX defects fixed in the March 2012 release
of HP-UX 11i v3.
Table 1 LVM Fixes in HP-UX 11i v3 March 2012 Release
DescriptionDefect ID
Distributed snapshot logical volume becomes inoperative/overcommit before threshold.QXCR1001101464
There is no option to convert the cluster DSFs in a volume group back to persistent DSF using
vgcdsf.
QXCR1001128614
Deactivating a shared volume group in the client while the server has crashed would result
in client panic, with the following stack trace:
QXCR1001131097
panic: slvmp: process bad reply, unknown reply
Stack Trace:
IP Function Name
0xe00000013121c120 slvmp_process_bad_reply+0x280
0xe000000000ee19f0 invoke_callouts_for_self+0x460
0xe000000000ec6070 soft_intr_handler+0x1c0
0xe000000000eed820 external_interrupt+0x4b0
0xe000000001e66780 bubbledown+0x0
0xe000000000e9cba1 idle+0x7b1
End of Stack Trace
Under heavy I/O load, user I/Os and mirror resync IOs to a MWC-enabled logical volume
will hang when there are intermittent disk failures
QXCR1001134963
After the migration of a volume group from version 1.0 to 2.x using vgversion, the volume
group activation fails with the following error message:
QXCR1001135515
$vgchange –a y vgname
Coundn't activate volume group vgname
On disk, LVM metadata structure are corrupt.
Resolution notes: vgversion has been enhanced so that volume groups migrated using the
March 2012 version of vgversion will successfully activate. Volume groups migrated using
older unfixed versions of vgversion may continue to face this problem. See notes against
QXCR1001182973 under “Known issues” (page 6) for more details.
The pvdisplay command on a cluster DSF shows the following PV attributes as 'unavailable'
for 1.0 volume group:
QXCR1001137363
With option –d:
Data Start (data_start with -F)
Data End (data_end with -F)
Boot Disk (book_disk with -F)
With option –lu:
Data_Start
Data_End
Bootable
Version change of a 2.x VG to 2.y fails if the volume group contains a cluster lock PV. The
vgversion command fails with the following error message:
QXCR1001137400
#vgversion -V 2.2 /dev/vgxx
Performing "vgchange -a y -l -p -s /dev/vgxx" to collect data
Activated volume group.
Volume group "/dev/vgxx" has been successfully activated.
vgversion: Error: The Physical Volume "/dev/disk/disk296"
is a cluster lock disk.
vgversion: Error: Cannot change the version of a Volume Group
containing a cluster lock disk.
vgversion: Error: Failed to change the Volume Group version
to 2.2
Fixed issues in this version 5