Description of problem: If I try to pvmove lv's out of a pv I created using the metadatacopies 0 option, pvmove concludes that the source physical volume is not in a volume group and refuses to commence with the move. This is, at least, within a clustered vg. Version-Release number of selected component (if applicable): lvm2-2.02.16-3.el5 lvm2-cluster-2.02.16-3.el5 How reproducible: Steps to Reproduce: 1. create some physical volumes with the --metadatacopies 0 option 2. add these pvs into a vg 3. create some lvs in these pvs / pvmove some (extents of) existing lvs into these new pvs 4. try to pvmove the extents out from these new pvs Actual results: pvmove says the pv isn't in a volume group, gives usage and exits Expected results: pvmove should move the lvs (extents) from the metadatacopies 0 pv into another pv
*** Bug 252151 has been marked as a duplicate of this bug. ***
Yes, this need to be fixed, simply reproducible on RHEL5.
It's another (well-hidden!) pv_read() that needs changing, like some others already have been fixed in the tools directory. This one is certainly fixable, but it is not trivial. (It should do sequence of functions calls to determine VG first, and only rely on pv_read() output when it's proven not to belong to any VG. Maybe the function should be removed. Long term we're trying to get rid of 'pv_read()'.)
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
In lvm2-2.02.30-1.el5.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2008-0378.html