Ánh xạ thiết bị Linux ánh xạ LVM PV được lồng bên trong LV khi chụp ảnh nhanh


13

Điều này thực sự gây rối với kế hoạch sao lưu máy này của tôi ...

Tôi có một máy chủ là một trình ảo hóa KVM cho một số máy ảo. Một trong số đó là chạy Docker. Nó có khối lượng Docker trên / dev / vdb, được thiết lập dưới dạng PV LVM, trên đó Docker sử dụng trình điều khiển lvm trực tiếp của nó để lưu trữ dữ liệu của Docker. Đĩa ảo này là LVM LV trên đĩa cục bộ của máy chủ.

Cả chủ nhà và khách đều điều hành Fedora 21.

Giao diện của máy chủ lưu trữ này là (chỉ âm lượng có liên quan được hiển thị):

[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)

Chế độ xem của khách hàng của tập này là (một lần nữa, chỉ có âm lượng liên quan được hiển thị):

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

Với tất cả các khối lượng LVM khác trên máy chủ lưu trữ, tôi có thể chụp ảnh nhanh lvcreate --snapshot, sao lưu ảnh chụp nhanh và sau đó lvremovekhông có vấn đề gì. Nhưng với khối lượng cụ thể này, tôi không thể làm được lvremovevì nó đang được sử dụng:

[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.

Cuối cùng, tôi phát hiện ra rằng trình ánh xạ thiết bị trên máy chủ bằng cách nào đó đã tìm ra rằng ảnh chụp khối lượng logic này có chứa một LVM PV, và sau đó tiến hành ánh xạ các khối lượng logic trong ảnh chụp nhanh đến máy chủ (chỉ hiển thị các khối lượng có liên quan):

[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)

Chúng tương ứng chính xác với các khối logic bên trong VM:

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

Đáng chú ý, nó không thử làm điều này với LVM LV khi hệ thống khởi động, nhưng chỉ khi tôi chụp ảnh nhanh.

Chuyện gì đang xảy ra ở đây? Tôi thực sự không muốn người lập bản đồ thiết bị kiểm tra nội dung của ảnh chụp nhanh LVM để xem nếu có bất cứ điều gì trong đó, nó có thể lập bản đồ một cách vô ích cho tôi. Tôi có thể ngăn chặn hành vi này? Hay tôi cần tạo ảnh chụp nhanh thông qua một số phương pháp khác?

Câu trả lời:


8

Đôi khi, tài liệu liên quan bị ẩn đi trong các tệp cấu hình chứ không phải trong tài liệu. Vì vậy, có vẻ như với LVM.

Theo mặc định, LVM sẽ tự động cố gắng kích hoạt âm lượng trên bất kỳ thiết bị vật lý nào được kết nối với hệ thống sau khi khởi động, miễn là tất cả các PV có mặt, lvmetad và udev (hoặc gần đây là systemd) đang chạy. Khi ảnh chụp nhanh LVM được tạo, một sự kiện udev sẽ bị loại bỏ và vì ảnh chụp nhanh có chứa PV, lvmetad sẽ tự động chạy pvscan, v.v.

Bằng cách nhìn vào /etc/lvm/backup/docker-volumestôi đã có thể xác định rằng lvmetad đã chạy rõ ràng pvscantrên ảnh chụp nhanh bằng cách sử dụng các số chính và số phụ của thiết bị, bỏ qua các bộ lọc LVM thường ngăn chặn điều này. Các tập tin có chứa:

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

Hành vi này có thể được kiểm soát bằng cách thiết lập auto_activation_volume_listtrong /etc/lvm/lvm.conf. Nó cho phép bạn đặt các nhóm âm lượng, âm lượng hoặc thẻ được phép tự động kích hoạt.

Vì vậy, tôi chỉ cần đặt bộ lọc để chứa cả hai nhóm âm lượng cho máy chủ; bất cứ điều gì khác sẽ không phù hợp với bộ lọc và không được kích hoạt tự động.

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

Khối lượng LVM của khách không còn xuất hiện trên máy chủ nữa và cuối cùng, các bản sao lưu của tôi đang chạy ...


4

Bạn muốn chỉnh sửa giá trị 'bộ lọc' trong /etc/lvm/lvm.conf để chỉ kiểm tra các thiết bị vật lý trên máy chủ KVM; giá trị mặc định chấp nhận 'mọi thiết bị khối' bao gồm chính LV. Nhận xét trên giá trị mặc định là khá toàn diện và có thể thực hiện công việc giải thích việc sử dụng tốt hơn tôi có thể.


Lưu ý rằng tôi đã thêm bộ lọc và chạy pvscan --cacheđể nói với lvmetad về bộ lọc mới và pvscanhiện trạng thái PV đang bị bộ lọc từ chối, nhưng vấn đề vẫn tồn tại.
Michael Hampton

Tôi giả sử bạn có nghĩa là không có khả năng loại bỏ ảnh chụp nhanh. Ở giai đoạn này, nó có thể là khó khăn và tôi chỉ có thể đưa ra những gợi ý mơ hồ. Nếu khởi động lại máy chủ KVM không có vấn đề gì (và tôi thừa nhận đó là cách tiếp cận búa tạ), thì có lẽ 'lvchange -an / path / to / LV' từ máy chủ sẽ giải phóng lệnh giữ của nó. Nếu không, thì có lẽ bạn đang thử nghiệm các hoạt động dmsetup khác nhau để thử và bỏ qua các công cụ LVM. Mặc dù vậy, nó có nhiều lông và tôi không cảm thấy thoải mái khi đề xuất bất kỳ hoạt động cụ thể nào.
Craig Miskell

Bộ lọc không làm gì cả vì lvmetad đang quét ảnh chụp nhanh một cách rõ ràng để đáp ứng với sự kiện udev. Giải pháp hóa ra lại là một thứ khác trong cấu hình, mặc dù ...
Michael Hampton

2

Tôi đã gặp phải cùng một vấn đề kết hợp với vgimportclone. Đôi khi nó sẽ thất bại với điều này:

  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

Vào thời điểm đó, nếu tôi muốn phá hủy ảnh chụp nhanh, trước tiên tôi phải tạm thời vô hiệu hóa udevdo lỗi được mô tả tại https://bugs.launchpad.net/ubfox/+source/lvm2/+bug/1088081

Nhưng ngay cả sau đó, sau khi dường như vô hiệu hóa thành công nhóm âm lượng của LVM lồng nhau, ánh xạ phân vùng cho PV lồng nhau, được tạo bởi kpartx, bằng cách nào đó vẫn được sử dụng.

Thủ thuật có vẻ là trình ánh xạ thiết bị giữ ánh xạ cha mẹ thêm bằng cách sử dụng tên nhóm âm lượng cũ, như thế này trong danh sách cây:

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

Giải pháp đơn giản là loại bỏ ánh xạ cụ thể đó với dmsetup remove insidevgname-lvroot. Sau đó, kpartx -dlvremovelàm việc tốt.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.