Re: Import duplicate VG from a read-only device

Erwin van Londen <[email protected]> Mon, 18 Nov 2024 13:38:12 +0000
Newsgroups gmane.linux.lvm.general
Message-ID <[email protected]>
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
OpenPGP_0x985B90929D90E282.asc (application/pgp-keys, 2.5 KB)
-----BEGIN PGP PUBLIC KEY BLOCK-----

xsDNBGQRYX4BDAC8B6owsNuXhju/GATHTqy2oyNnp9j0zNMSG34tX8GWmNh7Mq6u
R2wbKRYfPtgzYTY8XgfMbmRkqINbFCHSR3AcNPWIgrF6DEhS2IJEFvDSHZf/WB6p
l75swPMT/IxBDPGenejmb3lGh8AoVFrH4Fdv1xhoEmm8rD60EDuj5hrvntRtnPvR
yQVfj49lrkMyBINwUKFuYzdTfoGb20ytDHG0I2gyfGrVDWrdOzbG5q3b3t2Q6YY+
pOXUox1COwfkmHUxKOXFAR26CEO0+5cLP9EaCJLrlB4B1F/qnnpzWmRY+8/pyBs+
QZlxjDRPdwSqHzdynL/5X71Q8DdlG6NNFH/z0abVzntZfd2JjAPNCQkdQBpt1vCN
Q4MuaJC3sm6NgbDQP5v8dkW2WWwhLY6SulVXM59WJcVIlKblWZVxHCGSlibUaSML
meffz3xbLnitUuOsZVpGzsaEn2nHxKfAhneMNPiyRvpsXdzA+Yyo6cCpIAw+049G
dWQIMpQSYO6jqZsAEQEAAc0rRXJ3aW4gdmFuIExvbmRlbiA8ZXJ3aW5AZXJ3aW52
YW5sb25kZW4ubmV0PsLBFwQTAQgAQRYhBBTp2PvyeXazDZb5WZhbkJKdkOKCBQJk
EWF+AhsDBQkJZgGABQsJCAcCAiICBhUKCQgLAgQWAgMBAh4HAheAAAoJEJhbkJKd
kOKCXucMAI+FLsGDo1+PCV+8uJLz6pgKJ/AE0104JQ5f0croh+SKpOcQ6CNqCkci
IKc++iccC9hUyCq7GWu9QmrT56O1jYL7tLgjvtugsXhLdLhVVhYkzhfOpgOeVoKw
FpjiDjv45hKt5El4KFjWqg3eKh7BehQxwktk5wrz49aYqRPlP6jFCVitm2+jqv+n
V74QQUZpcKG2Usd8qDeyKNU78oWoDuJ/jbtR/KvWKlBbl9vA+GNQxLQj0EVSkVsK
jdKphCPTSGLUPGctSCJ5VCAUbvIYIUU1U3N110y2nSs3CD2DSZ61i+cuPINgOnQz
8FOrd03JRxgZssJongCHXz8iWznzQRIx9VghYbYaUkjYt6F46xcc5bhoCo4YjijC
36LKFOwGe60vQAtojE3Ix6IItJNwQ49/FkzV9dw1Z+VtXE7BVeJTWRa4U2kuP2UF
IzFghrJBEO9ew8DPZu++lxieuKgpuaaUsh/CnA8GcH5GNEAawY2SSfC/+aqiS2iS
nnfp/IRC687AzQRkEWF+AQwAoqADoQ0UUfdwZm0JW56HyaU87RBfhAqpAa6LYHxu
RFJMeRSUBH1943pcNDmSXHWRFvXeZBTlF/XcygYSVLKNPzp1sqhKaNtFot30t7Qf
RfFyE4uC5hkaVnJhskMBA6ryy6hLTo23FrAI/Qh0Lmu4yqYk+XZlydXyIvzntp+9
H3x7xugHWtkSr0SK9OaM7crv3W9JUpRiWLUkxnBXF13Q23+cBL2Z3kimVCmQnF3O
T/G+mwdHPIIvNmAksk0MkWWE95okOW3uLy50gXAieSSiAzMRYe3DaaiJ03UWVLFH
cyn7TqJyNX9kg3+ZUj7WKH1HlI+cmi1ESFV2CSplnCEE48VgvBUSH54VANK8uC3q
gWJdCw0cu/V1eJbURe7n3Tc5JbaOrF9hVGX5QQQuxwzcv73K2QGR2ei4ZWpWDZUe
tP2qTXrHc/qrdOryOX8QbRHz5TrMhg9KMmICrKEsMgYz9AjSxaXUaZ8k6l4vMR0X
JYpvsF+qQumG3hX4k7yglvcNABEBAAHCwPwEGAEIACYWIQQU6dj78nl2sw2W+VmY
W5CSnZDiggUCZBFhfgIbDAUJCWYBgAAKCRCYW5CSnZDigpfcC/9LYtqzMZwNqB1b
j2nEwqkN3jZJE8qNMxC1WMdQdB3wVUSJMhfWphxljWXSNGxkqAWAASC+KlWwyNZt
O2cG51js4y5656n2BRvIf44hERkyok9cT04h5DwJoFh8HoyW7wd0uWpHQSlK7Q3K
gD9aelLELHmrQAf5ignsbR6RnAYHLiflmzueDdYvXZNM0BOwMPznIdFJCGKk9kSy
dz2BfxKmvZyPdBOvceOGcIkCEvQPSwm5aSQKKMP7Id/osO7GN5U3vIHVo51p0O7h
sdIJ9vA0/KNeKQjmne4wGfqo+DWT5ev2BrCDhU1OIahIIdGgeSZL0bQ82Js5h6Co
cqdc14Rbjc/KfLhDcEeoFmk3o9qyYlBgjHmwxGx1QaYgSQGg0gMMftYDTCc0CmSo
PNUw7eHuk8DLhyMMBhsn57jUBK5m4tvv0FxldJziAGS7QeX4OzlfkO2d5QUfHKof
RoRUBqhb/XAZChPk5rs66l068bUfenEC1sX2gEyaxI93/m+nO8Q=
=RPR/
-----END PGP PUBLIC KEY BLOCK-----
OpenPGP_signature.asc (application/pgp-signature, 677 B)
-----BEGIN PGP SIGNATURE-----

wsD5BAABCAAjFiEEFOnY+/J5drMNlvlZmFuQkp2Q4oIFAmc7QzoFAwAAAAAACgkQmFuQkp2Q4oK6
GAwAkDJtbhBxk6oZX7/xqDHmmdEUTAwF8NN7SJcxIVdbyfUHsw/qYpIGlJY7ggqBDBdMMtspbE2P
i5ac/5JjUcGa/ImNaYsyUSEoABZl4Ri73TjJDDPf9bANgVQlbGVuI5t0s1vmSFXMjKhjDQLMljr+
BC7r/7zCRCjnxixhlFpsxei11FRWeXOB5ryEWpbPrIRiDT0YPj/tfZIds2JRx7rjJWjl4y0fDuHS
485cOi+YMYaiaFQgvCaXsEwhDRuKw9wSWR+LTF3qGWUO46jFR6K7egrLmRWZj2GfY5Xo1FZLdL6q
qrwk0aYrs6+RpPM/145N3ftoEJ/cHjejJvqaCky+cktW0I7edmwYwt0epYvgmGjUxDBQH/Ytmj2r
hVj1aDalOPR96NpqnOwacXHI9AQCc5GksGSgNzUaofc5lPoHQVE/kU6sW7D1Z6/ZJHIotG5I4tuz
pKxfjQhUNYMCxOuJ8fYo0/wAuAE+GKO2P2hdk0Z4k+UXcmgI7siOCtXskabV
=zCap
-----END PGP SIGNATURE-----