Hi Radu, all, > I hope this helps you debug the issue you had. It would also be > interesting if you could try to zero the *original* LVM volume (the one > that didn't work) and then restore the image once again and see if it > works. It would prove (or disprove) my theory :) Even though I still consider your theory (of zeroing the blocks before restoring the image) the most plausible, something else showed up when I looked at zeroing the partition (I have to wait restoring the image as this is a production system). The old LV apparently is still online/active and I cannot deactivate it/take it offline even though I'm sure it is not in use. This is something (with LVM2) I've seen before: LVs are marked to be in use (and cannot be taken offline) even though none of the running VMs is using the LV. # lvchange -a n /dev/d/xm.wxp LV d/xm.wxp in use: not deactivating If something else is using the LV as well as the VM, it would be logical that the VM experiences corruptions (even if it's running code from Redmond :-P ). I've tried using kpartx in the past (as suggested in some places) but without much success. In the following list, d-xm.wxp is the old LV (that no longer works [pre zeroing the blocks]), d-xm.wxp2 is the new LV (that is currently in use) and I don't know what d-xm.wxp1 is... possible the first partition d-xm.wxp that keeps it online? brw-rw---- 1 root disk 254, 22 2011-03-30 04:58 d-xm.wxp brw-rw---- 1 root disk 254, 24 2011-03-28 09:18 d-xm.wxp1 brw-rw---- 1 root disk 254, 25 2011-04-01 05:56 d-xm.wxp2 # kpartx -d /dev/d/d-xm.wxp failed to stat() /dev/d/d-xm.wxp # kpartx -d /dev/d/d-xm.wxp1 failed to stat() /dev/d/d-xm.wxp1 I wouldn't know though what else could be using the LV and I am not aware of any methods to find out... any suggestions? best regards, Jan _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
