Можно ли одновременно подключить 2 тома LVM, которые являются точными копиями друг друга (одинаковые UUID)?
Я клонировал (используя dd) жесткий диск в работающей системе на несколько резервных жестких дисков. Корневой раздел в работающей системе - это том LVM. Резервные копии предназначены для замены оригинала, а это означает, что они должны иметь тот же UUID, что и мастер.
Быстрый вопрос: возможно ли смонтировать один из резервных HD в действующей системе? Когда я пытаюсь это сделать, LVM по понятным причинам запутывается из-за тех же UUID и имен групп томов. Следуя подсказке, найденной в [этом ответе][1], чтобы сначала переименовать исходную группу LVM, я попытался:
подключение внешнего резервного HD в USB-порт
выполняется (обратите внимание, что строка 'test' является именем группы в этой системе)
# vgrename test test-live Volume group "test" successfully renamed to "test-live" vgscan --mknodes Reading all physical volumes. This may take a while... Found duplicate PV qWUadGaM2MU1UAJ5Spp8upD6fbddk7Zb: using /dev/dm-3 not /dev/dm-0 Found volume group "test" using metadata type lvm2 # vgchange -ay Found duplicate PV qWUadGaM2MU1UAJ5Spp8upD6fbddk7Zb: using /dev/dm-3 not /dev/dm-0 2 logical volume(s) in volume group "test" now active
На этом этапе я ожидал, что смогу получить доступ к отдельным логическим томам в /dev/test/, Бег lvdisplay производит.
Found duplicate PV qWUadGaM2MU1UAJ5Spp8upD6fbddk7Zb: using /dev/dm-3 not /dev/dm-0
--- Logical volume ---
LV Name /dev/test/root
VG Name test
LV UUID UuKUH3-yzPo-CbOz-tU4B-W6om-qdMn-0XSNZU
LV Write Access read/write
LV Status available
# open 1
LV Size 126.48 GiB
Current LE 32378
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 252:1
--- Logical volume ---
LV Name /dev/test/swap_1
VG Name test
LV UUID OGJhJu-QByo-6AzG-sk1x-jh3e-dU9L-sHk91t
LV Write Access read/write
LV Status available
# open 2
LV Size 3.90 GiB
Current LE 999
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 252:2
Тем не мение, /dev/test/ не существует вообще, и поэтому я не могу получить доступ к логическим томам в /dev/test/root а также /dev/test/swap_1 как предложил lvdisplay.
4 ответа
Весь смысл UUID состоит в том, чтобы однозначно идентифицировать что-то, и то, что вы пытаетесь сделать, делает их неуникальными. Я очень сомневаюсь, что это возможно. Я играл с pvchange -u изменить UUID дублированного PV, но операция всегда терпела неудачу.
Если вам действительно необходимо смонтировать резервные копии на работающем хосте, я предлагаю вам выполнить резервное копирование LV по отдельности (т. Е. Создать новый PV, VG и LV на устройстве резервного копирования и создать dd для каждого LV отдельно).
Если вы хотите смонтировать lv с диска-клона, я нашел этот полезный метод здесь http://www.linuxquestions.org/questions/linux-hardware-18/unable-to-change-uuid-of-cloned-drive-device-left-open-4175470893/
vgimportclone -n orignalvgname_clone /dev/sdx [/dev/sdy....]
SDX, SDY... клонированные диски, которые составляют VG.
vgchange -ay orignalvgname_clone
После этого вы сможете смонтировать lvs с клонированного диска.
Ответ от trekkerboy / modonnell @ linuxquestions является наиболее простым, используйте vgimportclone,
Также обратите внимание, что после создания клона его необходимо активировать с помощью vgchange -a y newvgname, и вы должны очистить узлы устройства oldvgname с помощью dmsetup remove /dev/oldvgname/*,
Для справки, ниже следует более ручной метод, который, очевидно, напоминает подмножество того, что можно прочитать в источнике vgimportclone,
Вы можете сделать это, если сможете сначала временно деактивировать управление оригинальной копией, добавив шаблон, соответствующий оригиналу, в devices фильтровать lvm.conf, Например, если вы клонировали /dev/sdx в /dev/sdy, вы должны временно добавить /dev/sdx в filter в пределах devices { ... } раздел.
Оригинальные устройства будут оставаться в сети, но инструменты LVM будут игнорировать их. Установленные на них файловые системы останутся подключенными и работоспособными, что не тесно связано с управлением LVM.
После установки фильтра сделайте новый vgscan, чтобы убедиться, что дубликаты и только они теперь находятся под управлением LVM. Вы можете убедиться, что вы видите дубликат /dev/sdy устройства через, например, pvs,
Затем сделайте:
vgchange -a n originalvgname
Это деактивирует группу томов под названием originalvgname, но поскольку видны только дубликаты устройств, он деактивирует их на них (оригинал originalvgname уже невидим из-за фильтра выше). Этот шаг необходим для того, чтобы вы могли свободно изменять атрибуты неактивной группы томов и входящих в нее физических томов.
pvchange -u physicaldevice
vgchange -u originalvgname
Это даст новые идентификаторы UUID дубликатам.
vgrename originalvgname newvgname
Это переименует дублированную группу томов.
После этого вы можете удалить фильтр из lvm.conf и повторите сканирование, и оба набора устройств LVM будут видны под разными именами и UUID.
В качестве альтернативы, если вы на самом деле не заинтересованы в сохранении исходного имени VG и идентификаторов UUID PV/VG, вы можете вместо них избавиться от них, cf. https://superuser.com/questions/256061/lvm-and-cloning-hds
Я столкнулся с этой проблемой только вчера. У меня есть файловая система (LVM(MD(sda, sdb, sdc-syncing-only-weekly-based))) в Linux, и мне нужен был доступ к старым данным на sdc.
Я несколько решил проблему, подключив резервный диск (sdc) к виртуальной машине. Это безопасная операция, пока я подключаю диск с помощью "qemu ... -drive file=/dev/sdc,readonly" (или использую опцию снимка для конфигурации копирования при записи).