Replies: 1 comment
-
There are two things to worry about a little: first, there could be an NTP/PTP daemon running on the host OS that could jump the cmos clock, I'm not sure how that would be handled, given that would be very weird behavior if it would happen from the point of the VM. But hopefully the system clock is virtualized in such a way that it doesn't pass on those jumps. I'm not quite sure what your specific hypervisor implementation is actually doing. The other thing to look out for is when the host machine is under high load you could experience some reduced synchronization performance as well, as timestamps won't be generated on time to get accurate measurements. Other than that: we run two virtualized NTP servers in the pool on shared cores in the google cloud, and we've never really experienced any issues ourselves. One thing to look for is us eventually supporting reading time from a PHC and allow your virtualization environment to offer up such a PHC as a time source, with a host OS ntp daemon doing the actual time synchronization, see #1138 |
Beta Was this translation helpful? Give feedback.
-
Hello,
Thank you for writing and maintaining this project, I'm running it now and enjoying it greatly.
I had a question. I am running my ntpd-rs instance in a virtual machine. This type of virtual machine prevents the host from updating the RTC. Update calls to the hardware are ignored for security reasons. Now, it is possible that my hypervisor updates the RTC on behalf of the virtual machine instead.
Is the ntpd-rs server able to function accurately in this sort of scenario?
Thank you,
Error logs if anyone using crosvm Hypervisor comes across this:
[2024-12-26T19:54:02.500768298+00:00 INFO devices::cmos] Ignoring unsupported bits: 80
https://chromium.googlesource.com/crosvm/crosvm/+/refs/heads/main/devices/src/cmos.rs#320
Beta Was this translation helpful? Give feedback.
All reactions