ซึ่งมันยุ่งจริงๆ กับแผนสำรองเครื่องนี้...

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

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

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

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

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

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

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

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

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

[[email protected] ~]# 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:

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

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

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

answer

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

โดยค่าเริ่มต้น LVM จะพยายามเปิดใช้งานวอลลุมโดยอัตโนมัติบนอุปกรณ์ทางกายภาพใดๆ ที่เชื่อมต่อกับระบบหลังจากบู๊ต ตราบใดที่ PV ทั้งหมดมีอยู่และ 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 ของแขกไม่ปรากฏบนโฮสต์อีกต่อไป และในที่สุด การสำรองข้อมูลของฉันก็ทำงาน...

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

ฉันพบปัญหาเดียวกันโดยประมาณเมื่อใช้ร่วมกับ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ยังคงใช้งานอยู่

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

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

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