Re: Import duplicate VG from a read-only device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dne 15. 11. 24 v 21:07 Gionatan Danti napsal(a):
Hi list,
is it possible to import a duplicate VG name from a read-only device?

I know about vgrename, but it needs to update metadata - which is not possible for read-only device.

I tried to un-manage the host native read/write VG, deleting it from system.devices, but lvchange -ay shown an error about not being able to create the /dev/VG/LV symlink (and a "device busy" issue, probably related to the already-existing symlink). I also tried to activate the specific LV via lvchange -S lv_uuid, but it shown the same error as above.

In this specific case I put the device in r/w mode and solved the issue with a plain vgrename. But what if I could not enable writes on the device? Is the only solution to mount it on a machine without the same VG name (ie: on a live USB), or can a VG/LV be enabled specifying a different path for the symlink?

Hi

You can always write appropriate lvm.conf filter or use devicesfile to list only those devices/PV you want to use and not cause 'duplicate VG' problem for command processing.

However there is no chance to activate duplicated VG/LV as clearly there cannot exist 2 DM devices with the same name/uuid - they must be unique!

So perhaps maybe you can 'rename' VG of the system you are running from - if you cannot change the metadata on you read-only device.

Here I'd probably suggest to simply avoid creating such problems upfront,
AKA - if all your systems are using the same VG name and then you want to 'share/swap' such devices between your systems - you should always pick a unique VG name for each such system. That way avoids all the problems....

Regards

Zdenek


PS: I think ATM lvm2 is already complicated enough to creating some 'overlay' level of referencing lvm2 names in the system through some 'abstract' mechanism to solve the issue that can be easily eliminated ahead makes not much sense to implement....





[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux