Можно ли одновременно подключить 2 тома LVM, которые являются точными копиями друг друга (одинаковые UUID)?

Я клонировал (используя dd) жесткий диск в работающей системе на несколько резервных жестких дисков. Корневой раздел в работающей системе - это том LVM. Резервные копии предназначены для замены оригинала, а это означает, что они должны иметь тот же UUID, что и мастер.

Быстрый вопрос: возможно ли установить один из резервных HD-дисков в действующей системе? Когда я пытаюсь это сделать, LVM по понятным причинам запутывается из-за тех же UUID и имен групп томов. Следуя подсказке из [этого ответа] [1], чтобы сначала переименовать исходную группу LVM, я попытался:

1. подключение внешнего резервного HD в порт USB

2. выполняется (обратите внимание, что строка '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.

Весь смысл 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- устройство-открыто слева-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. /superuser/256061/lvm-and-cloning-hds

Я столкнулся с этой проблемой только вчера. У меня есть файловая система (LVM (MD (sda, sdb, sdc-syncing-only-weekly-based))) в Linux, и мне нужен был доступ к старым данным на sdc.

Я несколько решил проблему, подключив резервный диск (sdc) к виртуальной машине. Это безопасная операция, пока я подключаю диск с помощью «qemu ... -drive file = / dev / sdc, readonly» (или использую опцию снимка для конфигурации копирования при записи).