czy możliwe jest jednoczesne zamontowanie 2 woluminów LVM, które są dokładnymi kopiami dla siebie (te same UUID)?

Sklonowałem (używając dd) dysk twardy w systemie na żywo na kilka kopii zapasowych. Partycja root w systemie na żywo jest woluminem LVM. Kopie zapasowe mają być zamiennymi zamiennikami oryginału, co oznacza, że ​​muszą mieć ten sam identyfikator UUID co wzorzec.

Szybkie pytanie: czy można zamontować jeden z zapasowych dysków HD w systemie na żywo? Kiedy próbuję to zrobić, LVM jest co do niej zrozumiały z powodu tych samych UUID i nazw grup woluminów. Po wskazówkach zawartych w [tej odpowiedzi] [1], aby najpierw zmienić nazwę oryginalnej grupy LVM, próbowałem:

1. podłączenie zewnętrznej kopii zapasowej HD do portu USB

2. działa (zwróć uwagę, że ciąg „test” to nazwa grupy w tym systemie)

# 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

W tym momencie spodziewałbym się, że będę mógł uzyskać dostęp do poszczególnych woluminów logicznych pod /dev/test/. Uruchamianie lvdisplayprodukuje.

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

Jednak w /dev/test/ogóle nie istnieje i dlatego nie mogę uzyskać dostępu do woluminów logicznych pod /dev/test/rooti /dev/test/swap_1jak sugeruje lvdisplay.

Istotą UUID jest unikatowa identyfikacja czegoś, a to, co próbujesz zrobić, czyni je niepowtarzalnymi. Bardzo wątpię, czy jest to możliwe. Bawiłem się z, pvchange -uaby zmienić UUID duplikatu PV, ale operacja zawsze kończyła się niepowodzeniem.

Jeśli naprawdę potrzebujesz zamontować kopie zapasowe na hoście na żywo, sugeruję, aby wykonać kopię zapasową LV indywidualnie (tj. Utworzyć nową PV, VG i LV na urządzeniu do tworzenia kopii zapasowych i dd każdą LV osobno).

Jeśli chcesz zamontować lv z dysku klonowania, znalazłem tę przydatną metodę tutaj 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 .. to sklonowane dyski, które tworzą vg.

vgchange -ay orignalvgname_clone

Następnie powinieneś móc zamontować lvs ze sklonowanego dysku.

Odpowiedź trekkerboy / modonnell @ linuxquestions jest najprostsza, użyj vgimportclone.

Zauważ również, że po utworzeniu klonu musisz go aktywować za pomocą vgchange -a y newvgnamei musisz wyczyścić węzły urządzeń oldvgname za pomocą dmsetup remove /dev/oldvgname/*.

Dla porównania poniżej przedstawiono bardziej ręczną metodę, która najwyraźniej przypomina podzbiór tego, co można przeczytać w źródle vgimportclone.

Możesz to zrobić, jeśli możesz tymczasowo dezaktywować zarządzanie oryginalną kopią, dodając do devicesfiltra wzór pasujący do oryginału lvm.conf. Na przykład, jeśli sklonowany /dev/sdxw /dev/sdy, trzeba tymczasowo dodać /dev/sdxdo filterw devices { ... }sekcji.

Oryginalne urządzenia pozostaną w trybie online, ale narzędzia LVM je zignorują. Zamontowane na nich systemy plików pozostaną zamontowane i będą działać, co nie jest ściśle powiązane z zarządzaniem LVM.

Po zainstalowaniu filtra zrób nowy vgscan, aby upewnić się, że duplikaty i tylko one są teraz zarządzane przez LVM. Możesz upewnić się, że widzisz zduplikowane /dev/sdyurządzenia za pośrednictwem np pvs.

Następnie wykonaj:

vgchange -a n originalvgname

Spowoduje to dezaktywację wywoływanej grupy woluminów originalvgname, ale ponieważ widoczne są tylko zduplikowane urządzenia, dezaktywuje je na nich (oryginał originalvgnamejest już niewidoczny z powodu powyższego filtra). Ten krok jest konieczny, abyś mógł swobodnie zmieniać atrybuty nieaktywnej grupy woluminów i składowych woluminów fizycznych.

pvchange -u physicaldevice
vgchange -u originalvgname

To da nowe UUID do duplikatów.

vgrename originalvgname newvgname

Spowoduje to zmianę nazwy zduplikowanej grupy woluminów.

Następnie możesz usunąć filtr lvm.confi ponownie przeskanować, a oba zestawy urządzeń LVM będą widoczne pod różnymi nazwami i identyfikatorami UUID.

Alternatywnie, jeśli tak naprawdę nie jesteś zainteresowany zachowaniem oryginalnej nazwy VG i identyfikatorów UUID PV / VG, możesz je zamiast tego pozbyć, por. /superuser/256061/lvm-and-cloning-hds

Problem ten spotkałem wczoraj. Mam konfigurację systemu plików (LVM (MD (sda, sdb, sdc-syncing-only-weekly-base))) w Linuksie i potrzebowałem dostępu do starych danych na sdc.

W pewnym stopniu rozwiązałem ten problem, dołączając dysk kopii zapasowej (sdc) do maszyny wirtualnej. Jest to bezpieczna operacja, o ile podłączam dysk z „qemu ... -drive file = / dev / sdc, readonly” (lub użyj opcji migawki do konfiguracji kopiowania przy zapisie).