Hi, I don't think so, as you can read from page 15, "Native synchronization software has the advantage that it is generally prepared to deal with the virtual machine clock being either ahead of or behind real time. It has the disadvantage that it is not aware of the virtual machine’s built?in catch?up and thus typically does not synchronize time as well in a virtual machine as it does when run directly on physical hardware. One specific problem occurs if native synchronization software happens to set the guest operating system clock forward to the correct time while the virtual machine has an interrupt backlog that it is in the process of catching up. Setting the guest operating system clock ahead is a purely software event that the virtual machine cannot be aware of, so it does not know that it should stop the catch?up process. As a result, the guest operating system clock continues to run fast until catch?up is complete, and it ends up ahead of the correct time. Fortunately, such events are infrequent, and the native synchronization software generally detects and corrects the error the next time it runs. Another specific problem is that native synchronization software may employ control algorithms that are tuned for the typical rate variation of physical hardware timer devices. Virtual timer devices have a more widely variable rate, which can make it difficult for the synchronization software to lock on to the proper correction factor to make the guest operating system clock run at precisely the rate of real time. As a result, the guest operating system clock tends to oscillate around the correct time to some degree. The native software may even determine that the timer device is broken and give up on correcting the clock." "Generally, it is best to use only one clock synchronization service at a time in a given virtual machine to ensure that multiple services do not attempt to make conflicting changes to the clock. So if you are using native synchronization software, we suggest turning VMware Tools periodic clock synchronization off." You can use any way to synchronize your vm, I used to adjust the kernel parameters, it works well in my ORACLE RAC. Rds, Winner Eugene Vilensky <evilensky@xxxxxxxxx> Sent by: redhat-list-bounces@xxxxxxxxxx 2009-11-27 02:12 Please respond to General Red Hat Linux discussion list <redhat-list@xxxxxxxxxx> To General Red Hat Linux discussion list <redhat-list@xxxxxxxxxx> cc Subject Re: why the clock become very slow? > I think that's normal then. > > You can do the following according to your linux version: > > 1.Synchronize your linux time using vmware-tools > > 2.Adjust your kernel parameters base on the following: > > http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427 I'm surprised that after all those kernel parameters, the NTP configuration section of KB 1006427 says this: "NTP Recommendations Note: In all cases use NTP instead of VMware Tools periodic time synchronization. Also, you may need to open the firewall (UDP 123) to allow NTP traffic." Is this a flat-out recommendation to use NTP anywhere and everywhere possible? Because there is no such explicit recommendation in this: http://www.vmware.com/pdf/vmware_timekeeping.pdf -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
-- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
