Bug 122991

pvmove --abort is required to clean things up.

Presumably the device-mapper pvmove support has not made it into the
Fedora kernel yet.  We plan to submit it upstream fairly soon now.

The current upstream LVM2 release (2.00.16) contains code that detects
this problem in advance and gives an error message sooner, but I've no
intention of backporting that code to 2.00.15 - it'll have to wait
till Fedora is unfrozen.  (2.00.16 contains a lot of code changes, so
it could have introduced new bugs.)

FWIW, I get a very similar error, with  kernel 2.6.6-1.435.2.3smp and
lvm2-2.00.15-2 :

pvmove -v --name /dev/vgob00/lv_rawvm /dev/hda1 /dev/sdc3
  /dev/cdrom: open failed: No medium found
    Finding volume group "vgob00"
    Archiving volume group "vgob00" metadata.
    Creating logical volume pvmove0
    Moving 1000 extents of logical volume vgob00/lv_rawvm
    Found volume group "vgob00"
    Found volume group "vgob00"
    Updating volume group metadata
    Creating volume group backup "/etc/lvm/backup/vgob00"
    Found volume group "vgob00"
    Found volume group "vgob00"
    Loading vgob00-pvmove0
  device-mapper ioctl cmd 9 failed: Invalid argument
  Couldn't load device 'vgob00-pvmove0'.
  ABORTING: Temporary mirror activation failed.
    Found volume group "vgob00"
    Loading vgob00-lv_rawvm
  device-mapper ioctl cmd 9 failed: Invalid argument
  Couldn't load device 'vgob00-lv_rawvm'.

Many thanks for the tip about pvmove --abort 

mirror support is in now - but the existence check to clean up the
above error sequence means you need to modprobe to install it before
you can use it...

pvmove still doesn't work in current rawhide.  Here are the remaining
problems:

- it won't modprobe dm-mirror, and will error out with a message that
doesn't make it obvious that this is the module to be loaded.  Might
as well load it itself.

- even in test mode, it (says it) creates a logical volume for the
move, and errors out saying you have to abort

- on at least one box, it failed because it couldn't allocate a
contiguous sequence of extents, even though there was plenty of space
in the target physical volume (although definitely not contiguous)

- on a box that had enough contiguous extents, and on the original
box, after narrowing the source extent range such that there are
contiguous extents for pvmove, it started, but the kernel
(2.6.8-1.541) immediately froze, and then I couldn't reboot because
lvm as run by initrd failed to bring up the pvmove volume, and then
couldn't mount the root filesystem, on the same volume group.

I think I have enough grounds to reopen this ;-)

Oddly, as soon as I booted the FC2 rescue CD, ran lvm vgscan and lvm
pvmove --abort and rebooted into rawhide, pvmove started working
(except for the need for explicit modprobing of dm-mirror and for
contiguous extents).  I haven't tried test mode any more.

There's now a check for lvm1 metadata so it won't attempt the pvmove.

I've suppressed that particular ABORTING message for test mode as
several people have found it confusing.

Test mode is supposed to follow exactly the same code path as the
normal command as far as possible, except that writes and activations
are suppressed - but return success nevertheless.

Outstanding requests:
  1) Would like the mirror/snapshot target presence checks extending
to try to load them too;
  2) Need more-sophisticated allocation code.

1) got fixed.

2) is still unfinished - updating this bugzilla to cover it.

Still not done.

It's now over 10 years ;) - is there anything still missing ?

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days