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

ฉันคิดว่าอาจเป็นปัญหากับแหล่งสัญญาณนาฬิกา แต่ตั้งค่าเป็น "kvm-clock" อยู่แล้ว

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

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

ปัญหา

ฉันมีปัญหาเดียวกันและฉันไม่พบวิธีแก้ปัญหาที่ดี นี่คือสิ่งที่ฉันพบ:

ปัญหาคือหลังจากที่กลับมาทำงานระบบและฮาร์ดแวร์นาฬิกาเวลาในแขกจะแตกต่างกัน:

root @ guest: ~ # date; hwclock
เสาร์ 11 ตุลาคม 13:09:38 UTC 2014
เสาร์ 11 ตุลาคม 13:10:42 2014 -0.454380 วินาที

บนโฮสต์พวกเขาเห็นด้วย:

root @ four: ~ # date; hwclock
เสาร์ 11 ตุลาคม 13:11:35 UTC 2014
วันเสาร์ที่ 11 13:11:36 2014 -1.000372 วินาที

การแก้ปัญหาคือการทำงานhwclock --hctosysกับแขกหลังจากที่ได้กลับมาทำงานต่อ อย่างไรก็ตามฉันไม่พบวิธีที่จะทำเช่นนี้กับการเปลี่ยนแปลงในระบบของแขกเท่านั้นเนื่องจากแขกไม่ได้สังเกตว่ามันถูกระงับและทำงานต่อ

ตัวแทนบุคคลทั่วไปของ QEmu

มีความเป็นไปได้ในการใช้งานซอฟต์แวร์ที่เรียกว่าQEmu Guest Agentบนแขกและแจ้งจากโฮสต์เพื่ออัพเดตนาฬิการะบบแขกจากนาฬิกาฮาร์ดแวร์ของแขก อย่างไรก็ตามหน้าระบุว่าตัวแทนผู้เข้าพักทำให้โฮสต์และแขกที่เสี่ยงต่อการถูกโจมตีจากปัญหาอื่น ๆ ที่มีปัญหากับตัวแยกวิเคราะห์ JSON (อย่างน้อยฉันเชื่อว่ารหัสที่ได้รับผลกระทบยังทำงานบนโฮสต์ฉันไม่แน่ใจเกี่ยวกับเรื่องนั้น ) อย่างไรก็ตามนี่คือวิธีการตั้งค่า:

1. ตั้งค่าช่องสัญญาณอนุกรม virtio สำหรับเอเจนต์ตามที่กล่าวถึงในlibvirt wiki (ดูเอกสารประกอบรูปแบบโดเมน libvirt )

2. หลังจากช่องซีเรียลพร้อมใช้งานให้ติดตั้งและเริ่มต้น QEmu Guest Agent บนแขก (Debian:. apt-get install --no-install-recommends qemu-guest-agent)

3. ทริกเกอร์นาฬิกาชดเชยโดยการระงับรอและดำเนินการต่อ จากนั้นเรียกใช้คำสั่งต่อไปนี้บนโฮสต์ที่จะแก้ไขให้ถูกต้อง: virsh qemu-agent-command backup '{"execute":"guest-set-time"}'หน้าวิกิพีเดียที่ใช้virsh qemu-agent-commandเป็นที่ไม่สนับสนุนแต่ฉันไม่ได้พบคำสั่งอื่นใดที่จะทำงาน

ฉันพบการสนทนาสองข้อเกี่ยวกับการทำให้เป็นอัตโนมัติภายใน libvirt การเรียกร้องให้guest-set-timeดำเนินการต่อจากการระงับ:

• http://thread.gmane.org/gmane.comp.emulators.libvirt/92431 (กุมภาพันธ์ 2014)
• http://thread.gmane.org/gmane.comp.emulators.libvirt.user/7051 (กันยายน 2014)

อย่างไรก็ตามยังไม่มีการใช้งานเท่าที่ฉันเห็น

ผมพบว่าข้อมูลเกี่ยวกับวิธีการส่งคำสั่งไปยังตัวแทนของผู้เข้าพักในวิกิพีเดียของ stoney-cloud.org

ฉันได้ลองตั้งค่าtickpolicy="catchup"ในการตั้งค่าตัวจับเวลา libvirtแต่วิธีนี้ไม่ได้แก้ปัญหา

NTP

ทางเลือกอื่นในการใช้เอเจนต์คือใช้ ntp daemon หรือโทร ntpdate เป็นระยะจากงาน cron ฉันจะไม่แนะนำอย่างหลังเนื่องจากอาจทำให้เวลาย้อนกลับไปได้ซึ่งอาจทำให้โปรแกรมสับสน (ตัวอย่างเช่นเซิร์ฟเวอร์ Dovecot IMAP ไม่พยายามจัดการเวลาย้อนหลังและสามารถยกเลิกได้)

ฉันลอง ntp daemons ต่อไปนี้:

• openntpd : แก้ไขเวลาช้ามากในอัตราประมาณ 2 วินาทีต่อ 60 นาทีในการทดสอบของฉัน เวลาชดเชยคือ 120 วินาที นอกจากนี้openntpd จะโยนข้อผิดพลาดหากเวลาชดเชยมีขนาดใหญ่เกินไปและในการทดสอบของฉันล้มเหลวในการแก้ไขเวลาในกรณีนั้นอย่างสมบูรณ์ ข้อดีของ openntpd: สามารถเรียกใช้เป็นผู้ใช้ปกติใน chroot

• chrony : แก้ไขการชดเชยเวลา 120 วินาทีใน 30 นาทีในการทดสอบของฉัน chrony สามารถกำหนดค่าให้เรียกใช้ในฐานะผู้ใช้ปกติ ไม่มีการสนับสนุน chroot ช่วงเวลาการสำรวจเซิร์ฟเวอร์ NTP สามารถกำหนดค่าสำหรับเซิร์ฟเวอร์ NTP แต่ละเครื่อง

• systemd-timesyncd : แก้ไขการชดเชยเวลา 120 วินาทีใน 30 วินาทีในการทดสอบของฉัน ทำงานเป็นผู้ใช้ปกติโดยค่าเริ่มต้น อย่างไรก็ตามช่วงเวลาการโพลของเซิร์ฟเวอร์ NTP เพิ่มขึ้นสูงสุดถึง 2048 วินาทีดังนั้นการหยุดชั่วคราว / การดำเนินการต่อจะไม่ถูกตรวจพบจนกระทั่ง 34 นาทีหลังจากการดำเนินการต่อในกรณีที่เลวร้ายที่สุด ดูเหมือนว่าจะไม่สามารถกำหนดค่าได้ นอกจากนี้ฉันได้สังเกตขั้นตอน timesyncd ย้อนหลังซึ่งทำให้เกิดปัญหาเช่นเดียวกับการเรียก ntpdate ใน cron (ดูด้านบน)

ลำดับที่จะแก้ปัญหา Openntpd ไม่เหมาะสมเนื่องจากอัตราการแก้ไขต่ำเกินไปและดูเหมือนจะไม่สามารถกำหนดค่าได้ systemd-timesyncd ไม่ได้แก้ปัญหาอย่างสมบูรณ์เช่นกันเพราะช่วงเวลาการสำรวจไม่สามารถกำหนดค่าได้

ฉันทดสอบ NTP daemons เวอร์ชัน Debian ต่อไปนี้: openntpd 20080406p-10, chrony 1.30-1 และ systemd 215-5 + b1

การดำเนินการโฮสต์เสมือนจริงหลายรายการบนแขกอาจส่งผลให้หยุดชั่วคราว - ดำเนินการต่อ สิ่งนี้จะส่งผลเสียต่อนาฬิการะบบที่แขกรับเชิญ ตัวอย่างเช่นการโคลน VM จะส่งผลให้หยุดชั่วคราวขณะทำการโคลน หลังจากนั้นนาฬิกาของแขกจะอยู่ด้านหลัง ในการรับ NTP เพื่อซิงค์นาฬิกาคุณต้องรีสตาร์ทเกสต์ - ไม่ใช่ทางออกที่ดีในทุกกรณีอย่างแน่นอน ทางเลือกคุณสามารถรีสตาร์ท ntpd ใน guest แต่นั่นก็ไม่เหมาะสม เป็นการดีที่จะต้องมีเหตุการณ์ (กลับมาทำงานต่อ VM) ที่คุณสามารถเลือกใช้สำหรับการแก้ไขประเภทนี้กับแขก

หลังจากใช้เวลาค้นคว้าข้อมูลนี้ฉันตัดสินใจใช้นาฬิกาโฮสต์โดยตรงเป็นข้อมูลอ้างอิงสำหรับนาฬิการะบบปฏิบัติการ CentOS 7 สำหรับแขก

แทนที่จะใช้ ntpd ในแขกฉันตัดสินใจว่าทุก 15 นาทีฉันจะตั้งค่าผ่าน crontab นาฬิการะบบแขกจากนาฬิกาฮาร์ดแวร์ของแขก นาฬิกาฮาร์ดแวร์ของแขกสะท้อนเวลาที่โฮสต์การจำลองเสมือนซึ่งควบคุมผ่าน ntpd ที่ทำงานบนโฮสต์การจำลองเสมือน นี่ทำให้ฉันมีเวลาที่เชื่อถือได้ในระบบปฏิบัติการของแขก กรณีที่เลวร้ายที่สุดนาฬิกาอาจถูกปิดเป็นเวลาสูงสุด 15 นาทีก่อนที่มันจะถูกซิงค์กับเวลาที่เหมาะสมหลังจากกลับมาทำงานต่อแขก

# crontab -e

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

มันจะดีกว่ามากที่จะมีกิจกรรมที่แขกที่จะเริ่มต้นการทำข้อมูลให้ตรงกันเมื่อแขกกลับมา แต่ดูเหมือนจะไม่สามารถใช้ได้ วิธีการ crontab เป็นวิธีการแก้ปัญหาในการที่มันเรียก hwclock ทุก ๆ 15 นาที มันทำให้งานเสร็จ แต่ไม่ได้สวยงามอย่างที่ฉันต้องการ

kvm-clock ซิงค์เวลาเกสต์กับโฮสต์เวลาเมื่อเริ่มต้นแขกเริ่มต้นคุณควรใช้และ ntp ไคลเอนต์ในแขกและปิด / เริ่มต้นแทนการใช้ระงับ / ดำเนินการต่อ

libvirt สนับสนุนการซิงค์เวลาของผู้เข้าพักตั้งแต่2015 บน Debian Stretch และค้นหาตัวเลือกSYNC_TIMEในภายหลัง/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

คุณสามารถทดสอบการซิงค์เวลาจากภายในระบบโฮสต์ด้วย:

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

คำสั่งนี้ควรกลับมา{"return":{}}สำเร็จ

ฉันใช้วิธีที่คล้ายกันในการซิงค์เวลาหลังจาก VM หยุดชั่วคราว / ทำงานต่อ แต่ฉันคิดว่าเป็นการดีกว่าที่จะคาดเดาว่าควรซิงค์ในทิศทางที่ถูกต้องและยาวกว่าความแตกต่างที่สั้นซึ่งอาจได้รับการแก้ไขโดย NTPD

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

PS CentOS 6.7 changelog ใหม่บอกว่านี่สามารถทำได้โดยอัตโนมัติด้วยแหล่งสัญญาณนาฬิกา kvm เท่านั้น