HP-UX Logical Volume Manager and MirrorDisk/UX Release Notes HP-UX 11iv3 (August 2011)

For example, with this enhancement, when a VxVM GPT disk is supplied for the LVM pvcreate
command, it reports the following error:
$ pvcreate /dev/rdisk/disk35
pvcreate: Could not perform LVM operation on VxVM disk “/dev/rdisk/disk35”
This enhancement will help customers avoid using VxVM GPT formatted disk in LVM by mistake.
However, customers can also enforce the pvcreate operation with the pvcreate -f option.
Fixed issues in this version
The following table lists the known LVM and MirrorDisk/UX defects fixed in the August 2011 web
release of HP-UX 11i v3. This includes defects fixed for the September 2011 release that are
described in the September 2011 LVM and MirrorDisk/UX Release Notes.
Table 1 LVM Fixes in HP-UX 11i v3 August 2011 Web Release
DescriptionDefect ID
pvdisplay -v takes a long time to complete if the physical volume has large number of
physical extents in use (about 0.5 million extents or more).
QXCR1001080067
vgchange -a y reports activation mode conflict failure with the following error message
when the previous vgchange -c reported success even though internally it did not change
the mode correctly.
QXCR1001086866
$vgchange -a y vgname
vgchange: Activation mode requested for the volume group <vgname> conflicts with configured
mode.
In a Serviceguard cluster environment, one of the client panics after joining the cluster with
the following panic string and stack trace:
QXCR1001091075
panic: slvmp: process bad reply
0xe00000012f219ca0 slvmp_process_bad_reply+Ox320
0xe000000000ed4490 invoke_callouts_for_self+Ox460
0xe000000000ec6bf0 soft_intr_handler+Ox1c0
System panics after a physical volume is removed from a volume group when both of the
following conditions are true:
QXCR1001095451
• The removed physical volume has extents allocated for a mirrored logical volume with
MWC (mirror write cache) enabled.
• There were write I/Os on these extents and the logical volume was not closed properly.
The stack trace of the panic will look like below:
0xe000000000711ff0 $cold_vm_hndlr+0x750
0xe000000001dda780 bubbledown+0x0
0xe0000001c38f64b0 lvmp_vg_lvix_to_minor+0xd0
0xe0000001c38f6390 lvmp_vg_lvix_to_dev+0x50
lvmove/pvmove -a fails while moving extents of a logical volume which has strict mirroring
policy and the destination physical volume is smaller than the source disk even if there are
free extents in the destination physical volume.
QXCR1001095804
While deleting a snapshot logical volume, the system might panic with the panic string “panic
assertion failed (plv_num !=0)” and the stack trace below if there is pending I/O
QXCR1001099272
on a successor or predecessor snapshot logical volume which is waiting for one or more
offline physical volumes to come back online.
panic assertion failed (plv_num !=0)
0xe000000179062fa0 lvmp_is_pred_lv_present
0xe0000001791ec5c0 lvmp_schedule1
0xe00000017906d920 lvmp_reschedule_cbws
0xe0000001790feeb0 lvmp_snap_write_daemon
When a user runs /usr/sbin/fbackup on /etc/lvmvonf/pv_lock, the following
message is displayed in syslog but there is no functionality impact:
QXCR1001099748
Fixed issues in this version 5