Now I'm confused. You write: > Running the NTP server is a whole lot better than even a daily 'ntpdate' via CRON. and > The spiffy thing about time on System z is that the clock is incredibly stable. So which is it?
Both are true - the key problem is that if the operator is off when he sets the time at VM startup, then all the clocks in the guests are off by the same amount, and if those clocks are involved in transactions spanning multiple LPARs, you'll see failures in authentication or transaction validation even though the hardware clock is keeping good solid time; it's keeping time based on a wrong starting point. VM never changes the clock after startup, so you can't bring the clocks into sync with the rest of the world without running xntpd in each individual guest. That said, xntpd is small, lightweight and well-behaved, so as not to add more entropy to the system it's running on. If you have to run a daemon in each guests, it's a polite and well-behaved one. We wrote about having one server running the full xntpd to a reliable time source. I guess that would make it a stratum n-1 server. Then the other "penguins in the colony" run ntpdate nightly against the first server (thanks to Rob van der Heij for that suggestion). That would make them stratum n-2 servers. It seemed like a good balance. But we never tested it with an app that demands clock synchronization. So did you find that this model didn't work? It doesn't work in that you still have to wake up every single guest and process something fairly often to keep the clocks synced, which generates paging and consumes CPU for no real good purpose. If VM were able to do it in CP (or get the updates when the other LPARs do), then we could probably rely on the clock in VM instead of individual software clocks, and dispense with xntpd in the guests. As Kerberos penetrates further into enterprises, this is going to get REALLY important. Kerberos is very sensitive to time sync in order to prevent replay attacks. Ditto Web Services-based apps - SOA really REALLY cares about this.
