Re: Import duplicate VG from a read-only device

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

 



On 18/11/24 19:53, Zdenek Kabelac wrote:
> 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....
>
>
Do I agree with the above sentence!!!!.  I've seen major issues where 
administrators have created a massively complex system out of LVM to the 
extend they dug themselves a rabithole from which they couldn't escape 
anymore. ALWAYS keep it as simple as possible and only use what you 
actually need. Try to stay away from bells and whistles if you don't 
needs them....

Cheers

Erwin

Attachment: OpenPGP_0x985B90929D90E282.asc
Description: application/pgp-keys

Attachment: OpenPGP_signature.asc
Description: PGP signature


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

  Powered by Linux