i would love to see a vclock driver so that the guest could reach up and
grab the host's clock. running ntp on every guest feels silly.
however, there's a problem with this, which i expect is the reason why
it hasn't happened yet.
ntp tries hard not to jump the clock, since when you do, there's a
discontinuity visible to every process. time can march backward, periods
can be skipped over, and most irritatingly, gettimeofday will return a
tv_usec value greater than a million -- which many callers won't expect.
presumably ts_nsec could be larger than a billion, too.
ntp prefers to slew. that is, it makes the clock move always-forward but
at a faster or slower rate as required to eventually make the time correct.
ntp also drifts. if it learns after a while that its hardware clock is
just slow or fast, it will change the rate at which the software clock
marches forward, to minimize corrections (which would require slew).
so while a "vclock" driver that allowed the guest to fetch the host's
software clock value would be kind of useful, all of the slewing and
drifting logic would still be nec'y, requiring either extra clock math
in the guest kernel, or, more likely, running ntp after all.
so i run ntpd on the guest and tell it that the host is its "master".
note that 25 years after its birth, cron's understanding of time jumps
including either "ntpdate" or daylight savings time, is horrible. but
mostly the reason for this that there are often more than one answer, or
no right answer. the best thing to do is run with a UTC timezone and
never jump the clock when cron is running (noting, ntpdate runs before
cron starts in the /etc/rc init systems i know about, and this is why.)
email@example.com mailing list
To unsubscribe, send any mail to