Milan, I promised you an explanation, and here it is. It was, at least partially, my fault. I don't really understand why the original VM did not, and would not, restart correctly. However, I discovered, after I had made copies of everything and created a new VM to work with, that there were two different "formats" of "virtual disk drives," even though they were all called "qcow2." There were a combination of "raw" and "qcow2" disks. Once I got the VM configuration file, and therefore the VM configuration, matching the formats of the disk drives, I was able to completely recover the "missing" PV, and therefore the VG and LV. During my investigation, I had issued a "removemissing," so the LVM Meta-data was "corrupted," but I edited a copy of that and vgcfgrestore corrected everything. I did an e2fsck of the LV, to make sure, but the user tells me that everything looks the way that he expected, so far. So, even though the problem really wasn't what I thought it was, I want to thank you very much for the patience and guidance toward helping me find the ( apparent ) real problem. I am still not happy about how rebooting the host machine caused so much damage, with one LV completely losing its contents ( the qcow2 file has completely disappeared ) and therefore one VM being destroyed, and more than this one not being able to restart correctly, but at least, most of the VMs are back in action. Thanks again, Brian _______________________________________________ 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/
