On Sun, Jul 19, 2020 at 06:22:46PM +0200, Matthias Petermann wrote: > > that sounded promising, but seems to only work with file-based volumes. > > jupiter# vndconfig vnd0 /dev/mapper/rvg0-builder9 > vndconfig: /dev/rvnd0: VNDIOCSET: Operation not supported > > Thanks anyway - I should take a closer look at LVM - I'm probably scratching > the surface too much here. But it was worth a try. >
Well, if it is a device already you should be able to vgscan it to find the logical volumes. You may need to tweak the the device filters in the lvm.conf to allow vgscan to look into /dev/mapper devices. The trickiest bit is if your volume groups in the vm are the same names as the onese on the host but even that is not insurmountable. I know this works - I managed to totally wreck a xen vm server with guests by doing a yum erase -y for a bunch of rpms that had the kernel as their dependency... oops. After rescue booting the host and reinstalling the xen kernel I mapped the guest volumes onto the host, chrooted into the file system and installed the kernel rpm there. These vm's were using file based stores so I had to do the vndconfig (well linuxy equivalent) but the process should be close to the same. I was able to recover all the vm's doing this. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"
