Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040506 Description of problem: I was trying to implement pvmoving of specific extents (i.e., pvmove PVfrom:extent PVto:extend, as available with lvm1 tools), but ran into an ugly problem with the lvm2 tools that we ship: I can't seem to get pvmove to work at all. I created a pair of physical volumes on loopback devices (200+ 4MiB extents each), a volume group out of them, and a 1-extent logical volume. Then, I attempted to pvmove this physical volume. With lvm1, it just outright fails, since apparently lvm1 metadata doesn't support mirror stripes. With lvm2, it sets up a new logical volume with one extent, but then it fails with the error message below. Version-Release number of selected component (if applicable): lvm2-2.00.15-2 How reproducible: Always Steps to Reproduce: 1.dd if=/dev/zero of=/tmp/loop0 bs=4096k count=10; dd if=/dev/zero of=/tmp/loop1 bs=4096k count=10; losetup /dev/loop0 /tmp/loop0; losetup /dev/loop1 /tmp/loop1 2.pvcreate /dev/loop[01]; vgcreate loop /dev/loop[01]; lvcreate -n test -l 1 loop /dev/loop0 3.pvmove /dev/loop0 Actual Results: device-mapper ioctl cmd 9 failed: Invalid argument Couldn't load device 'loop-pvmove0'. ABORTING: Temporary mirror activation failed. device-mapper ioctl cmd 9 failed: Invalid argument Couldn't load device 'loop-test'. And then both test and pvmove0 are locked, I can't lvremove them any more, and the only way out is to use vgcfgrestore to go back to what was there before it messed things up. Expected Results: I expected it to work. pvmove is an essential feature of LVM IMHO. Additional info:
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 ?