3

I have a CentOS 4.6 box that was previously a physical device, and has been made into a VM, that has a cronjob to restart the server everyday at 23:00. Which is fine.

However, since the shift to virtual (on a Hyper-V host) neither the system time or the hwclock will stay:

A) In sync with one another B) Display the correct time

I have been scratching my head for a while with this one. Setting the time manually results in insane time drift very quickly (I'm talking hours in mere moments); using NTPD also has no effect. It appears to sync but still displays an incorrect time.

I have tried it both with and without the setting on the VM through Hyper-V to "Synchronise Time". To no avail.

Problem being once the system believes it is 23:00. Which happens multiple times a day. It restarts. And the users that rely on this server are ultimately affected.

Any and help appreciated.

D-Man
  • 31
  • 3
  • 1
    What is the kernel version running on that box? I suspect you may need to tweak the kernel clock= arg to the kernel, but I am not entirely sure what it would need to be. Newer kernels tend to do the right thing. - https://access.redhat.com/solutions/18627 https://social.technet.microsoft.com/Forums/windows/en-US/28c93dc4-3313-4121-8448-fb30c78d0359/redhat-enterprise-54-clock-running-fast-under-hyperv-2k8-r2?forum=winserverhyperv – Zoredache Oct 04 '18 at 17:40
  • 1
    The best I can find is https://www.redhat.com/it/blog/avoiding-clock-drift-vms and https://www.centos.org/forums/viewtopic.php?f=19&t=15858&sid=c332e7dd7d54aa4e7161382cf2338134&start=10#p75088 – zymhan Oct 04 '18 at 17:48
  • Hyper-V does not support CentOS 4. Of course, it's long past end of life and should have been upgraded or decommissioned several years ago. You are unlikely to get a workable solution other than upgrading or decommissioning. – Michael Hampton Oct 04 '18 at 19:03
  • Thanks for the advice so far guys. The kernel version is 2.6.9-67.ELsmp and it's 64 bit. (no idea if the .ELsmp is needed, I'd still consider myself a Linux novice). I would like to upgrade this. But, yum doesn't work and I assume this is because the repos have been removed. Not to mention the software it runs is so old. Upgrading might cause all kinds of issues I wouldn't be able to resolve. – D-Man Oct 05 '18 at 14:47

2 Answers2

0

As a very ugly bandaind, you can setup ntpdate to run each minute putting something similar under /etc/cron.d:

* * * * * root ntpdate

To let the ntpdate do its work, be sure to stop/disable the ntpd service. Then, restart crond

This is an ugly hack but, as stated in the comments, Hyper-V does not officially supports CentOS 4.x, so it is the best method I can think of.

shodanshok
  • 47,711
  • 7
  • 111
  • 180
  • When you guys say "not supported" what parts aren't supported? The integration with Hyper-V tools like the Time Sync? Also, I tried your advice I still have some issues. Even when I use ntpdate to update the time, then `hwclock --systohc`, to set the hardware clock from the system time. It doesn't adjust the time. (worth noting I am specifying an NTP to check from, `ntpdate -s uk.pool.ntp.org` Am I better off just using ntpdate without specifying a server; stopping the ntpd service, run the tasks, then start ntpd again? – D-Man Oct 05 '18 at 14:41
  • 1
    "Not supported" means that you can not hope for any technical support from the vendor. Incidentally, even community support can be low (as we generally do *not* run unsupported configuration). Regarding `ntpdate`, you should run it after *stopping ntpd*, otherwise it will exit without doing anything. If even `ntpdate` fails to update your clock, well, I think your VM really has some strange problems. – shodanshok Oct 05 '18 at 21:46
0

I would prefer to still use NTP versus ntpdate commands. ntpd will maintain statistics about its drift and offset.

So reviewing the post Avoiding clock drift on VMs already mentioned:

Remove any -x option from /etc/sysconfig/ntpd. Slewing takes forever and you have crazy offsets to fix.

Add tinker panic 0 to the top of /etc/ntp.conf. Again, crazy offsets. ntpd accepting big jumps while running is actually desirable in this case.

Then service ntpd restart and check on the offsets with ntpq -p or other monitoring.

You said you tried with Hyper-V Time Synchronization both enabled and no, record which one you have set at the moment. 

Get-VM -Name oldLinuxBox | Get-VMIntegrationService -Name "Time Synchronization"
John Mahowald
  • 32,050
  • 2
  • 19
  • 34