Trên máy chủ của tôi, tôi đang sử dụng libvirt và một khách KVM. Khi chủ nhà ngừng hoạt động, libvirt đình chỉ khách. Khi chủ nhà bắt đầu, libvirt tiếp tục khách. Vấn đề là, nếu khách bị đình chỉ và tiếp tục lại sau 24 giờ chẳng hạn, thì thời gian của khách là 24 giờ trong quá khứ.

Tôi nghĩ rằng có thể vấn đề là với clockource, nhưng nó đã được đặt thành "kvm-clock" rồi.

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
kvm-clock tsc hpet acpi_pm 

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
kvm-clock

Vấn đề

Tôi đã có cùng một vấn đề và tôi đã không tìm thấy một giải pháp tốt. Đây là những gì tôi tìm thấy:

Vấn đề là sau khi tiếp tục, thời gian của hệ thống và phần cứng trên máy khách là khác nhau:

root @ khách: ~ # ngày; giờ cao điểm
Thứ bảy ngày 11 tháng 10 13:09:38 UTC 2014
Thứ bảy ngày 11 tháng 10 13:10:42 2014 -0,454380 giây

Trên máy chủ, họ đồng ý:

root @ bốn: ~ # ngày; giờ cao điểm
Thứ bảy ngày 11 tháng 10 13:11:35 UTC 2014
Thứ bảy ngày 11 tháng 10 13:11:36 2014 -1.000372 giây

Giải pháp sẽ là chạy hwclock --hctosystrên khách sau khi nó được nối lại. Tuy nhiên, tôi không tìm thấy cách nào để thực hiện việc này chỉ với các thay đổi trên hệ thống khách, vì khách không nhận thấy rằng nó bị treo và tiếp tục.

Đại lý khách QEmu

Có khả năng chạy một phần mềm có tên QEmu Guest Agent trên máy khách và thông báo từ chủ nhà để cập nhật đồng hồ hệ thống của khách từ đồng hồ phần cứng của khách. Tuy nhiên, trang đề cập rằng tác nhân khách làm cho máy chủ và khách dễ bị tấn công lẫn nhau vì các vấn đề với trình phân tích cú pháp JSON (ít nhất tôi tin rằng mã bị ảnh hưởng cũng được chạy trên máy chủ, tôi không chắc về điều đó ). Dù sao, đây là cách thiết lập:

1. Thiết lập kênh nối tiếp virtio cho tác nhân như được đề cập trong wiki libvirt (xem thêm tài liệu định dạng tên miền libvirt ).

2. Sau khi kênh nối tiếp khả dụng, hãy cài đặt và khởi động Đại lý khách QEmu cho khách. (Debian : apt-get install --no-install-recommends qemu-guest-agent.)

3. Kích hoạt bù đồng hồ bằng cách treo, chờ và tiếp tục. Sau đó chạy lệnh sau trên máy chủ để sửa nó: virsh qemu-agent-command backup '{"execute":"guest-set-time"}'Trang wiki sử dụng khôngvirsh qemu-agent-command được hỗ trợ , nhưng tôi không tìm thấy bất kỳ lệnh nào khác thực hiện công việc.

Tôi đã tìm thấy hai cuộc thảo luận về tự động hóa trong libvirt cuộc gọi đến guest-set-timetiếp tục từ việc tạm dừng:

• http://thread.gmane.org/gmane.comp.emulators.libvirt/92431 (tháng 2 năm 2014)
• http://thread.gmane.org/gmane.comp.emulators.libvirt.user/7051 (tháng 9 năm 2014)

Tuy nhiên, không có gì đã được thực hiện theo như tôi có thể thấy.

Tôi tìm thấy thông tin về cách gửi lệnh đến đại lý khách trên wiki của stoney-cloud.org .

Tôi cũng đã cố gắng thiết lập tickpolicy="catchup"trong cấu hình libvirt timer nhưng điều này không giải quyết vấn đề.

NTP

Một cách khác để sử dụng tác nhân sẽ là sử dụng một daemon ntp hoặc gọi ntpdate định kỳ từ một công việc định kỳ. Tôi không khuyến nghị cái sau, vì nó có thể khiến thời gian quay ngược, điều này có thể gây nhầm lẫn cho các chương trình (ví dụ: máy chủ Dovecot IMAP không cố gắng xử lý thời gian quay ngược và có thể chấm dứt).

Tôi đã thử các trình nền ntp sau:

• openntpd : Sửa thời gian rất chậm với tốc độ khoảng 2 giây mỗi 60 phút trong bài kiểm tra của tôi. Thời gian bù là 120 giây. Ngoài ra, openntpd sẽ đưa ra một lỗi nếu độ lệch thời gian quá lớn và, trong thử nghiệm của tôi, hoàn toàn không thể sửa thời gian trong trường hợp đó. Ưu điểm của openntpd: Có thể chạy như người dùng thông thường trong chroot.

• chrony : Sửa lỗi thời gian bù 120 giây trong 30 phút trong thử nghiệm của tôi. chrony có thể được cấu hình để chạy như người dùng thông thường. hỗ trợ chroot không được thực hiện. Khoảng thời gian bỏ phiếu của máy chủ NTP có thể được cấu hình cho mỗi máy chủ NTP.

• systemd-timesyncd : Sửa lỗi thời gian bù 120 giây trong 30 giây trong thử nghiệm của tôi. Chạy như người dùng thông thường theo mặc định. Tuy nhiên, khoảng thời gian bỏ phiếu của các máy chủ NTP tăng lên tới 2048 giây, do đó, việc tạm dừng / tiếp tục sẽ không được phát hiện cho đến 34 phút sau khi tiếp tục trong trường hợp xấu nhất. Điều này dường như không thể cấu hình. Ngoài ra, tôi đã quan sát thời gian quay ngược thời gian, điều này gây ra các vấn đề tương tự như gọi ntpdate trong một cron (xem bên trên).

chrony giải quyết vấn đề. Openntpd không phù hợp vì tốc độ hiệu chỉnh của nó quá thấp và dường như không thể cấu hình được. systemd-timesyncd hoàn toàn không giải quyết được vấn đề, bởi vì khoảng thời gian bỏ phiếu của nó không thể cấu hình được.

Tôi đã thử nghiệm các phiên bản Debian sau của trình nền NTP: openntpd 20080406p-10, chrony 1.30-1 và systemd 215-5 + b1.

Nhiều hoạt động máy chủ ảo hóa trên máy khách có thể dẫn đến tạm dừng - tiếp tục. Điều này sẽ ảnh hưởng tiêu cực đến đồng hồ hệ thống tại khách. Ví dụ, nhân bản VM dẫn đến tạm dừng trong khi nhân bản. Đồng hồ khách sau đó là phía sau. Để có được NTP để đồng bộ hóa đồng hồ, bạn cần khởi động lại khách - không phải là một giải pháp tốt trong mọi trường hợp. Thay thế bạn chỉ có thể khởi động lại ntpd trong khách, nhưng điều đó cũng không tối ưu. Lý tưởng nhất là cần phải có một sự kiện (VM được nối lại) mà bạn có thể tùy ý sử dụng cho loại chỉnh sửa này cho khách.

Sau khi dành thời gian nghiên cứu điều này, tôi quyết định sử dụng trực tiếp đồng hồ chủ để làm tài liệu tham khảo cho đồng hồ hệ điều hành khách CentOS 7.

Thay vì chạy ntpd trong máy khách, tôi quyết định rằng cứ sau 15 phút tôi sẽ đặt, thông qua crontab, đồng hồ hệ thống khách từ đồng hồ phần cứng của khách. Đồng hồ phần cứng của khách phản ánh thời gian tại máy chủ ảo hóa được điều khiển thông qua ntpd chạy trên máy chủ ảo hóa. Điều này cung cấp cho tôi thời gian đáng tin cậy trong hệ điều hành khách. Trường hợp xấu nhất, đồng hồ có thể tắt trong tối đa 15 phút trước khi được đồng bộ hóa vào thời gian thích hợp sau khi tiếp tục khách.

# crontab -e

0,15,30,45 * * * * /sbin/hwclock --hctosys

Sẽ tốt hơn nhiều nếu có một sự kiện có sẵn tại khách sẽ bắt đầu đồng bộ hóa thời gian khi khách được nối lại, nhưng dường như điều đó không có sẵn. Cách tiếp cận crontab là một cách giải quyết ở chỗ nó thực hiện cuộc gọi hàng giờ cứ sau 15 phút. Nó hoàn thành công việc, nhưng không thanh lịch như tôi muốn.

kvm-clock đồng bộ hóa thời gian của khách để lưu trữ thời gian khi khởi động khách . Bạn nên sử dụng và ntp client trong máy khách và tắt / khởi động thay vì sử dụng tạm dừng / tiếp tục.

libvirt hỗ trợ đồng bộ hóa thời gian của khách kể từ năm 2015 . Trên Debian Stretch và sau đó tìm tùy chọn SYNC_TIMEtrong /etc/default/libvirt-guests:

# If non-zero, try to sync guest time on domain resume. Be aware, that
# this requires guest agent with support for time synchronization
# running in the guest. For instance, qemu-ga doesn't support guest time
# synchronization on Windows guests, but Linux ones. By default, this
# functionality is turned off.
#SYNC_TIME=1

Bạn có thể kiểm tra đồng bộ hóa thời gian từ bên trong hệ thống máy chủ với:

virsh qemu-agent-command INSERT_YOUR_DOMAIN_HERE '{"execute":"guest-set-time"}'

Lệnh này sẽ trở lại {"return":{}}thành công.

Tôi sử dụng cách tương tự để đồng bộ hóa thời gian sau khi VM tạm dừng / tiếp tục, nhưng tôi nghĩ nên thử đoán xem, nó nên đồng bộ hóa theo đúng hướng và dài hơn sự khác biệt ngắn, có thể được sửa bởi NTPD.

https://gist.github.com/jhrcz/7138804

Tái bút New centos 6.7 changelog nói rằng điều này có thể được thực hiện tự động chỉ với nguồn đồng hồ kvm-clock.