Tôi tự hỏi (sau một lần di chuyển trực tiếp thất bại khác):
Những thuộc tính (thuộc tính) VM nào được sao chép từ nguồn sang đích khi quá trình di chuyển trực tiếp PVM đang được thực hiện?
Trong trường hợp của chúng tôi, khung libvirt đang được sử dụng trong cụm máy điều hòa nhịp tim.
Cụ thể tôi đang tự hỏi về:
- bài tập khối-thiết bị
- kích thước bộ nhớ
- số vCPU
- mạng (veth)
- mô hình CPU
Một thất bại gần đây tôi thấy là:
Thiết bị hoán đổi của máy ảo đã được thay đổi từ LVM LV thành đĩa riêng, vì vậy đĩa mới đã được thêm qua đính kèm khối trong khi LV lỗi thời đã bị xóa trong VM.
Các cấu hình VM mà cụm máy tạo nhịp tim sử dụng là các bản cập nhật trên mỗi nút (nhưng dường như libvirt có các bản sao riêng trong RAM).
VM chạy tốt cho đến khi nó được di chuyển trực tiếp:
Có một số thông báo lỗi, nhưng VM vẫn tiếp tục trong 40 phút nữa cho đến khi nó ngừng ghi vào nhật ký systemd.
Trên bảng điều khiển, tôi thấy các tin nhắn lặp đi lặp lại như sau:
[94124.120477] LỖI: khóa hàng công việc - pool cpus=0-1 flags=0x5 nice=0 bị kẹt trong 232 giây!
[94154.815980] LỖI: khóa hàng công việc - pool cpus=0-1 flags=0x5 nice=0 bị kẹt trong 263 giây!
[94185.599474] LỖI: khóa hàng đợi công việc - cpus nhóm=0-1 cờ=0x5 đẹp=0 bị kẹt trong 293 giây!
[94216.278977] LỖI: khóa hàng đợi công việc - cpus nhóm=0-1 cờ=0x5 đẹp=0 bị kẹt trong 324 giây!
[94247.062530] LỖI: khóa hàng đợi công việc - cpus nhóm=0-1 cờ=0x5 đẹp=0 bị kẹt trong 355 giây!
[94277.682031] LỖI: khóa hàng công việc - pool cpus=0-1 flags=0x5 nice=0 bị kẹt trong 386 giây!
[94308.401531] LỖI: khóa hàng công việc - cpus nhóm=0-1 cờ=0x5 đẹp=0 bị kẹt trong 416 giây!
[94339.157047] LỖI: khóa hàng đợi công việc - cpus nhóm=0-1 cờ=0x5 đẹp=0 bị kẹt trong 447 giây!
Trên thực tế, máy ảo mới thiếu đĩa hoán đổi riêng.
Nhưng thay vì hoảng loạn (và khởi động lại), VM dường như chờ đợi điều gì đó không xảy ra.
Sau khi khởi động lại, tôi tìm thấy những tin nhắn này trong junal:
Ngày 23 tháng 3 20:02:19 hạt nhân v04: Quá trình đóng băng không gian người dùng ... (đã trôi qua 0,008 giây) đã hoàn tất.
Ngày 23 tháng 3 20:02:19 kernel v04: OOM killer bị vô hiệu hóa.
Ngày 23 tháng 3 20:02:19 kernel v04: Đóng băng các tác vụ có thể đóng băng còn lại ... (đã trôi qua 0,001 giây) đã hoàn tất.
Ngày 23 tháng 3 20:02:19 hạt nhân v04: PM: đóng băng thiết bị hoàn tất sau 0,562 mili giây
Ngày 23 tháng 3 20:02:19 kernel v04: tạm dừng xenstore...
Ngày 23 tháng 3 20:02:19 hạt nhân v04: PM: thiết bị đóng băng muộn hoàn tất sau 0,104 mili giây
Ngày 23 tháng 3 20:02:19 kernel v04: PM: noirq đóng băng thiết bị hoàn tất sau 13,428 mili giây
23 tháng 3 20:02:19 v04 kernel: xen:grant_table: Cấp bảng bằng cách sử dụng bố cục phiên bản 1
Ngày 23 tháng 3 20:02:19 hạt nhân v04: Bị treo trong 1.170 giây
Ngày 23 tháng 3 20:02:19 hạt nhân v04: PM: khôi phục noirq của thiết bị hoàn tất sau 0,166 mili giây
Ngày 23 tháng 3 20:02:19 kernel v04: PM: khôi phục sớm thiết bị hoàn tất sau 0,085 mili giây
Ngày 23 tháng 3 20:02:19 hạt nhân v04: vbd vbd-51744: 2 đọc các chi tiết đầu cuối khác từ thiết bị/vbd/51744
Ngày 23 tháng 3 20:02:19 v04 kernel: xenbus: resume (talk_to_otherend) vbd-51744 không thành công: -2
Ngày 23 tháng 3 20:02:19 hạt nhân v04: dpm_run_callback(): xenbus_dev_resume+0x0/0x130 trả về -2
Ngày 23 tháng 3 20:02:19 hạt nhân v04: PM: Thiết bị vbd-51744 không khôi phục được: lỗi -2
Ngày 23 tháng 3 20:02:19 kernel v04: PM: hoàn tất khôi phục thiết bị sau 9,374 mili giây
Ngày 23 tháng 3 20:02:19 kernel v04: Kích hoạt trình diệt OOM.
Ngày 23 tháng 3 20:02:19 kernel v04: Khởi động lại tác vụ ... đã xong.
...
Ngày 23 tháng 3 20:40:26 v04 systemd-logind[1034]: Không thể bắt đầu phạm vi phiên session-117.scope: Đã hết thời gian kết nối
-- Khởi động lại --
Vì vậy, tương tự như vậy, giả sử tôi đã mở rộng RAM máy ảo khi nó đang chạy.
RAM sẽ biến mất sau khi được di chuyển trực tiếp hay cài đặt RAM sẽ được "sao chép"?
