Roland Mainz wrote: > Dennis Clarke wrote: > > On 3/7/06, Andy Tucker <[EMAIL PROTECTED]> wrote: > > > On 3/6/06, Roland Mainz <[EMAIL PROTECTED]> wrote: > > > > I'm hitting some problems with Solaris guest installations in VMware > > > > (e.g. Solaris being the guest in a VMware VM): > > > > Sometimes the clock is going out-of-sync. I configured "xntpd" to > > > > counteract these issues - but suddenly at one point all hell breaks > > > > loose: > > > ... > > > > > > Generally configuring ntp in a guest doesn't work well due since ntpd > > > gets confused by the unstable nature of time in a VM (particularly if > > > the host is busy) and gives up. > > > > So we are stuck with a crontab entry for root like so : > > > > # Try to Keep time > > 11 * * * * /root/bin/ntpdate -B -o 3 -p 8 -s -t 5 -v my.favorite.ntp.server > > > > Then home that drift is only a second or so per hour ... ick > > Currently "xntpd" does that job, too: > -- snip -- > Mar 7 17:42:23 silo04 xntpd[775]: [ID 774427 daemon.notice] time reset > (step) 2.975875 s > Mar 7 17:52:16 silo04 xntpd[775]: [ID 774427 daemon.notice] time reset > (step) 2.095312 s > Mar 7 18:04:28 silo04 xntpd[775]: [ID 774427 daemon.notice] time reset > (step) 1.675151 s > Mar 7 18:21:52 silo04 xntpd[775]: [ID 774427 daemon.notice] time reset > (step) 3.061506 s > Mar 7 18:33:18 silo04 xntpd[775]: [ID 774427 daemon.notice] time reset > (step) 2.034722 s > Mar 7 18:45:30 silo04 xntpd[775]: [ID 774427 daemon.notice] time reset > (step) 1.609903 s > Mar 7 18:57:42 silo04 xntpd[775]: [ID 774427 daemon.notice] time reset > (step) 3.070431 s > -- snip -- > The only complaint was that it suddenly stopped to adjust/sync the time > which screwed-up lots of stuff... ;-(
One small addition (to avoid that this information gets lost - it may be very valuable to VMware and XEN users): The following /etc/inet/ntp.conf is usefull, too: -- snip -- server ns1.hrz.uni-giessen.de driftfile /var/ntp/ntp.drift statsdir /var/ntp/ntpstats/ slewalways no -- snip -- The trick here is the "slewalways no" which seems to be able to compensate huge problems when the VMware host OS does some kind of power management using the CPU frequency, for example raising the frequency from 1200MHz to 2000MHz causes the VM guests clock to run far too fast - and booting the VM guest OS while the machine runs at 2000MHz a frequency drop to 1200MHz causes it to run far to slow. While the solution isn't prefect it solves many problems (for example with "make" and timestamps) ... :-) ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
