Hi,

Thanks for the tips! I didn't know about 'pvmove', thanks.

In  the mean time, I managed to get it fixed by restoring the VG metadata on the iSCSI server, so on the underlying Zvol directly, rather than via the iSCSI session on the oVirt host. That allowed me to perform the restore without bringing all VMs down, which was important to me, because if I had to shut down VMs, I was sure I wouldn't be able to restart them before the storage domain was back online.

Of course this is a more a Linux problem than an oVirt problem, but oVirt did cause it ;-)

Thanks,
Martijn.

Op 19-7-2019 om 19:06 schreef Strahil Nikolov:

Hi Martin,

First check what went wrong with the VG -as it could be something simple.

vgcfgbackup -f VGname will create a file which you can use to compare current metadata with a previous version.

If you have Linux boxes - you can add disks from another storage and then pvmove the data inside the VM. Of course , you will need to reinstall grub on the new OS disk , or you won't be able to boot afterwards.

If possible, try with a test VM before proceeding with important ones.

Backing up the VMs is very important , because working on LVM metadata is quite risky.

Last time I had such an issue , I was working on clustered LVs which got their PVs "Missing". For me , restore from VG backup fixed the issue - but that might not be always the case.

Just get the vgcfgbackup's output and compare with diff or vimdiff and check what is different.

Sadly, I think that this is more a Linux problem , than an oVirt problem.

Best Regards,

Strahil Nikolov  

В четвъртък, 18 юли 2019 г., 18:51:32 ч. Гринуич+3, Martijn Grendelman <Martijn.Grendelman@isaac.nl> написа:

Hi!

Thanks. Like I wrote, I have metadata backups from /etc/lvm/backup and -/archive, and I also have the current metadata as it exis