ตัวแม็พอุปกรณ์ Linux แมป LVM PV ซ้อนกันภายใน LV เมื่อถ่ายภาพ


13

ซึ่งยุ่งกับแผนการของฉันในการสำรองเครื่องนี้ ...

ฉันมีเซิร์ฟเวอร์ซึ่งเป็นไฮเปอร์ไวเซอร์ KVM สำหรับเครื่องเสมือนหลายเครื่อง หนึ่งในนั้นกำลังเรียกใช้นักเทียบท่า มีวอลุ่ม Docker บน / dev / vdb ซึ่งตั้งค่าเป็น LVM PV ซึ่ง Docker ใช้ไดร์เวอร์ direct-lvmเพื่อจัดเก็บข้อมูลคอนเทนเนอร์ Docker ดิสก์เสมือนนี้เป็น LVM LV บนโลคัลดิสก์ของโฮสต์

ทั้งโฮสต์และแขกรับเชิญใช้งาน Fedora 21

มุมมองของโฮสต์ของไดรฟ์ข้อมูลนี้คือ (แสดงเฉพาะไดรฟ์ข้อมูลที่เกี่ยวข้อง):

[root@host ~]# lvs
  LV                           VG         Attr       LSize
  docker2.example.com-volumes vm-volumes -wi-ao---- 40.00g
[root@host ~]# dmsetup ls --tree
vm--volumes-docker2.example.com--volumes (253:10)
 └─ (9:125)

มุมมองของผู้เข้าพักของหนังสือเล่มนี้คือ (อีกครั้งจะแสดงเฉพาะเสียงที่เกี่ยวข้อง):

[root@docker2 ~]# pvs
  PV         VG             Fmt  Attr PSize  PFree
  /dev/vdb   docker-volumes lvm2 a--  40.00g    0 

ด้วยไดรฟ์ข้อมูล LVM อื่น ๆ ทั้งหมดบนโฮสต์ฉันสามารถถ่ายภาพพร้อมlvcreate --snapshotสำรองสแน็ปช็อตแล้วlvremoveก็ไม่มีปัญหา แต่ด้วยโวลุ่มนี้ฉันไม่สามารถทำได้lvremoveเพราะมันใช้งานอยู่:

[root@host ~]# lvremove /dev/vm-volumes/snap-docker2.example.com-volumes 
  Logical volume vm-volumes/snap-docker2.example.com-volumes is used by another device.

ในที่สุดฉันก็พบว่าอุปกรณ์ -mapper บนโฮสต์ได้คิดออกว่าสแน็ปช็อตโลจิคัลวอลุ่มนี้มี LVM PV แล้วจากนั้นทำการแมปโลจิคัลวอลุ่มภายในสแน็ปช็อตกับโฮสต์ (แสดงเฉพาะวอลุ่มที่เกี่ยวข้อง):

[root@host ~]# dmsetup ls --tree
vm--volumes-docker2.example.com--volumes (253:10)
 └─vm--volumes-docker2.example.com--volumes-real (253:14)
    └─ (9:125)
docker--volumes-docker--data (253:18)
 └─vm--volumes-snap--docker2.example.com--volumes (253:16)
    ├─vm--volumes-snap--docker2.example.com--volumes-cow (253:15)
    │  └─ (9:125)
    └─vm--volumes-docker2.example.com--volumes-real (253:14)
       └─ (9:125)
docker--volumes-docker--meta (253:17)
 └─vm--volumes-snap--docker2.example.com--volumes (253:16)
    ├─vm--volumes-snap--docker2.example.com--volumes-cow (253:15)
    │  └─ (9:125)
    └─vm--volumes-docker2.example.com--volumes-real (253:14)
       └─ (9:125)

สิ่งเหล่านี้สอดคล้องกับโลจิคัลวอลุ่มภายใน VM:

[root@docker2 ~]# lvs
  LV          VG             Attr       LSize
  docker-data docker-volumes -wi-ao---- 39.95g
  docker-meta docker-volumes -wi-ao---- 44.00m

โดยเฉพาะอย่างยิ่งมันไม่ได้พยายามทำเช่นนี้กับ LVM LV เมื่อระบบทำการบู๊ต แต่เมื่อฉันถ่ายภาพสแนปชอต

เกิดขึ้นที่นี่คืออะไร? ฉันไม่ต้องการให้ผู้ตรวจสอบอุปกรณ์ตรวจสอบเนื้อหาของสแน็ปช็อต LVM เพื่อดูว่ามีอะไรในนั้นที่จะช่วยฉันทำแผนที่ให้ฉันได้ไหม ฉันสามารถระงับพฤติกรรมนี้ได้หรือไม่? หรือฉันจำเป็นต้องสร้างสแนปชอตผ่านวิธีอื่นได้หรือไม่

คำตอบ:


8

บางครั้งเอกสารที่เกี่ยวข้องจะถูกซ่อนอยู่ในไฟล์กำหนดค่าแทนที่จะพูดถึงเอกสาร ดังนั้นดูเหมือนกับ LVM

โดยค่าเริ่มต้น LVM จะพยายามเปิดใช้งานไดรฟ์ข้อมูลบนอุปกรณ์ทางกายภาพใด ๆ ที่เชื่อมต่อกับระบบหลังการบู๊ตโดยอัตโนมัติตราบใดที่ PVs ทั้งหมดมีอยู่และ lvmetad และ udev (หรือเร็วกว่า systemd) กำลังทำงานอยู่ เมื่อสแน็ปช็อต LVM ถูกสร้างขึ้นเหตุการณ์ udev จะถูกไล่ออกและเนื่องจากสแน็ปช็อตมี PV ดังนั้น lvmetad จึงทำงานโดยอัตโนมัติpvscanและอื่น ๆ

โดยการดูที่/etc/lvm/backup/docker-volumesฉันสามารถระบุได้ว่า lvmetad ทำงานอย่างชัดเจนpvscanบนสแน็ปช็อตโดยใช้อุปกรณ์หลักและหมายเลขรองซึ่งข้ามตัวกรอง LVM ซึ่งปกติจะป้องกันสิ่งนี้ ไฟล์มี:

description = "Created *after* executing 'pvscan --cache --activate ay 253:13'"

ลักษณะการทำงานนี้สามารถควบคุมได้โดยการตั้งค่าในauto_activation_volume_list /etc/lvm/lvm.confอนุญาตให้คุณตั้งค่ากลุ่มวอลุ่มหรือแท็กที่อนุญาตให้เปิดใช้งานโดยอัตโนมัติ

ดังนั้นฉันเพียงตั้งค่าตัวกรองเพื่อให้มีกลุ่มวอลุ่มทั้งสองสำหรับโฮสต์ สิ่งอื่นจะไม่ตรงกับตัวกรองและไม่ได้รับการเปิดใช้งานโดยอัตโนมัติ

auto_activation_volume_list = [ "mandragora", "vm-volumes" ]

ปริมาณ LVM ของแขกไม่ปรากฏบนโฮสต์อีกต่อไปและในที่สุดการสำรองข้อมูลของฉันก็เริ่มทำงาน ...


4

คุณต้องการแก้ไขค่า 'ตัวกรอง' ใน /etc/lvm/lvm.conf เพื่อตรวจสอบอุปกรณ์ทางกายภาพในโฮสต์ KVM เท่านั้น ค่าเริ่มต้นยอมรับ 'ทุกอุปกรณ์บล็อก' ซึ่งรวมถึง LVs เอง ความคิดเห็นด้านบนค่าเริ่มต้นนั้นค่อนข้างครอบคลุมและสามารถอธิบายการใช้งานได้ดีกว่าที่ฉันทำได้


โปรดทราบว่าฉันได้เพิ่มตัวกรองและวิ่งpvscan --cacheไปบอก lvmetad เกี่ยวกับตัวกรองใหม่และpvscanตอนนี้ระบุว่า PV กำลังถูกปฏิเสธโดยตัวกรอง แต่ปัญหายังคงอยู่
Michael Hampton

ฉันคิดว่าคุณหมายถึงการไร้ความสามารถที่จะลบภาพรวม ในขั้นตอนนี้มันอาจจะยุ่งยากและฉันสามารถให้คำแนะนำที่คลุมเครือเท่านั้น หากการรีบูตโฮสต์ KVM ไม่เป็นไปตามคำถาม (และฉันยอมรับว่าเป็นวิธีการแบบค้อนขนาดใหญ่) ดังนั้นบางที 'lvchange -an / path / to / LV' จากโฮสต์จะปล่อยการพักไว้ หากไม่เป็นเช่นนั้นคุณอาจทดลองใช้การดำเนินการ dmsetup ต่างๆเพื่อลองและข้ามเครื่องมือ LVM มันมีขนดกแม้ว่าและฉันไม่สบายแนะนำการดำเนินการเฉพาะใด ๆ
Craig Miskell

ตัวกรองไม่ทำงานเนื่องจาก lvmetad กำลังสแกนสแน็ปช็อตอย่างชัดเจนเพื่อตอบสนองต่อเหตุการณ์ udev วิธีแก้ปัญหากลายเป็นอย่างอื่นในการกำหนดค่าแม้ว่า ...
Michael Hampton

2

vgimportcloneผมพบประมาณปัญหาเดียวกันร่วมกับ บางครั้งมันจะล้มเหลวกับสิ่งนี้:

  WARNING: Activation disabled. No device-mapper interaction will be attempted.
  Physical volume "/tmp/snap.iwOkcP9B/vgimport0" changed
  1 physical volume changed / 0 physical volumes not changed
  WARNING: Activation disabled. No device-mapper interaction will be attempted.
  Volume group "insidevgname" successfully changed
  /dev/myvm-vg: already exists in filesystem
  New volume group name "myvm-vg" is invalid
Fatal: Unable to rename insidevgname to myvm-vg, error: 5

ณ จุดนั้นถ้าฉันต้องการทำลายภาพรวมฉันต้องปิดการใช้งานชั่วคราวudevเนื่องจากข้อผิดพลาดที่อธิบายไว้ที่https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1088081

แต่ถึงอย่างนั้นหลังจากที่ประสบความสำเร็จในการปิดการใช้งานกลุ่มวอลุ่มของ LVM ที่ซ้อนกันการแม็พพาร์ติชันสำหรับ PV ที่ซ้อนกันซึ่งสร้างโดยkpartxยังคงใช้งานอยู่

เคล็ดลับน่าจะเป็นที่ mapper อุปกรณ์เก็บการแมปหลักพิเศษโดยใช้ชื่อกลุ่มวอลุ่มเก่าเช่นนี้ในรายการต้นไม้:

insidevgname-lvroot (252:44)
 └─outsidevgname-myvm--root-p2 (252:43)
    └─outsidevgname-myvm--root (252:36)

dmsetup remove insidevgname-lvrootวิธีแก้คือเพียงลบว่าการทำแผนที่โดยเฉพาะอย่างยิ่งกับ หลังจากนั้นkpartx -dและlvremoveทำงานได้ดี

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.