Re: [linux-lvm] Can't work normally after attaching disk volumes originally in a VG on another machine

[Xen <list@xenhideout.nl>]

Zdenek Kabelac schreef op 28-03-2018 0:17:

> Hi
> 
> This is why users do open BZ if they would like to see some 
> enhancement.
> 
> Normally cache is integral part of a volume - so it's partially
> missing - whole volume is considered to be garbage.
> 
> But in 'writethrough' mode there could be likely possible better 
> recovery.
> 
> Of course this case needs usability without --force.
> 
> So please open  RFE BZ for this case.

It goes into the mess I usually get myself into; if you "dd copy" the 
disk containing the origin volume before uncaching it, and then go to 
some live session where you only have the new backup copy, but you want 
to clean up its LVM,

then you now must fix the VGs in isolation of the cache; I suppose this 
is just the wrong order of doing things, but as part of a backup you 
don't really want to uncache first, as that requires more work to get it 
back to normal after.

So you end up in a situation where the new origin copy has a reference 
to the cache disk --- all of this assumes writethrough mode --- and you 
need to clear that reference.

However, you cannot, or should not, attach the cache disk again; it 
might get effected, and you don't want that, you want it to remain in 
its pristine state.

Therefore, you are now left with the task of removing the cache from the 
VG, because you cannot actually run vgimportclone while the cache disk 
is missing.

The obvious solution is to *also* clone the cache disk and then run 
operations on the combined set, but this might not be possible.

Therefore, all that was left was:

   vgreduce --remove-missing --force
   cd /etc/lvm/archive
   cp <latest backup> /etc/lvm/backup/<vg>
   cd /etc/lvm/backup
   vi <vg>
   " remove cache PV, and change origin to regular linear volume, and add
   " the visible tag

   vgcfgrestore <vg>

   # presto, origin is restored as regular volume without the cache

   vgimportclone -i <vg> <bla>

   # now have distinct volume group, VG UUID and PV UUID

So the problem is making dd backups of origin, perhaps dd backups should 
be avoided, but for some purposes (such as system migration) file copies 
are just

more work

in general, and can complicate things as well, for instance if there are 
NTFS partitions or whatnot.

And disk images can be nice to have, in any case.

This was the use case basically.