This content has been marked as final. Show 5 replies
Possibly your essential problem is both Virtual machines will be using the same underlying hardware system clock! In essence only the hypervisor is likely to be able to deal with the hardware system clock. (This is an informal answer rather than a technically guarenteed accurate one, but you have not indicated your stack fully.
Thanks, but I think you've maybe missed the point of this exercise.
Whilst it is fairly obviously a silly thing to want to do -when there's only one hardware clock that the two VMs are both sharing anyway- there are occasions when you need to persuade something that "proper" NTP servers are in use when they aren't: think installing Oracle RAC, for example, where ntp time synchronisation is a prerequisite that is checked for. (I don't want to use Cluster Time Service just yet, either).
In my specific case, I now believe the problem is that without genuine time hardware in place, it's impossible to make NTP report itself as anything other than a Stratum 16 time server. Since a standalone PC or VM without any network connectivity at all is considered a Stratum 16 time server, too, it's impossible to persuade the second VM to look to the first as its time source. It knows the other VM is as unreliable a source of time as it is itself, so it simply refuses to use anything other than itself as a time source.
If there's a way to fake a Stratum level, I don't know what it is: but I'd be grateful to learn about it, if it exists.
Interesting timing (ha!)
I am right in the middle of writing an article that needs pretty much this "fake time server" ability, and from endless experimentation, I can say that I think the ingredient you are missing is: Fudge.
If on VM1, I set the ntp.conf like this:
And on VM2, I set it like this:
server 127.127.1.0 fudge 127.127.1.0 stratum 9 driftfile /var/ntp/ntp.drift statsdir /var/ntp/ntpstats/ filegen peerstats file peerstats type day enable filegen loopstats file loopstats type day enable
Then an ntpq -p on VM2 shows this:
server 192.168.8.250 driftfile /var/ntp/ntp.drift statsdir /var/ntp/ntpstats/ filegen peerstats file peerstats type day enable filegen loopstats file loopstats type day enable
Not sure why it sees the stratum as 10 there, but no matter for now: it should be low enough to fool the other VM into trusting it. An ntpdate -u 192.168.8.250 on VM2 shows this:
remote refid st t when poll reach delay offset jitter ============================================================================== 192.168.8.250 LOCAL(0) 10 u 42 64 37 0.753 64.725 4571.66
...which is the sort of synchronisation to a fake time server you were after, I think.
4 Mar 12:48:26 ntpdate: adjust time server 192.168.1.32 offset 0.091570 sec
If I set the time on the 'master clock' via the date command, and set it way off on the VM2 also with the date command, I found I got a failure to synchronise, with an error "no server suitable for synchronization found". But if I disabled and enabled the ntp service (svcadm disable ntp, etc), then it all came good again at the next ntpdate -u command.
Further experimentation showed that if I fudged the master to stratum 2, the other VM saw it as stratum 3 ,,,so the ntpq command always seems to add one to the stratum, just for kicks. (Actually, this is a known "feature" and is mentioned, for example, here: http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080a23d02.shtml).
I don't know if it was related, too, but a fudge factor of 2 meant I didn't encounter the 'no server suitable' errors after doing an ntpdate command. Possibly because the master VM was, at that point, so trustworthy?
Don't know, but Fudge is what you're after, I think.
Don't forget that if you are doing this for a RAC install, you will also need to enable slew on your NTP configuration:
That will need to be set on your cluster nodes.
svccfg -s svc:/network/ntp:default setprop config/slew_always=true