What a mess that turned out to be. Hey, maybe it was your "awesome numbering" <ducking and running>. jk, probably because I forgot to take some meds today or something. I run into an occasional issue with dropping temp pv's assigned to vg's to move things around. I've learned to do pvck, vgck, lvscan, etc. to make sure everything in order whenever I do anything related to lvm. Occasionally I get "vg corruption" wherein the IUD is still being sought and I have to "vgreduce --removemissing <vgname>" to make sure all is clean. If I reboot with that in the root containing vg, I hang on boot and lose remote access (no serial hookup yet, planned for next machine). Oh, the dd quit on me before complete. Is it okay making the target lv bigger than the source when I try it again or does it have to be exact? I need some extra disk space in that xen vm too. Christopher G. Stach II wrote: > ----- "Ben M." <centos at rivint.com> wrote: > >> Ack. It wants to be in same Volume Group. I want to keep my VGs >> segregated to PVs segregrated to distinct harddrives (or devmapped >> raid1s). > > Mm hmm. pvmove only works within a VG. You would need to do the vgextend for it to at least be temporarily joined and then vgsplit later. I've found that it's usually worth the extra steps to be able to pvmove. >