Runtime went backwards???
-
I agree. They are competing with each other. Either:
-
don't run NTP and allow VM Tools to set the time on the VM or
-
run NTP on pfSense and stop VM Tools from setting the VM's time
Yeah, I thought that's what you were getting at earlier, but I think it'd be more noticeable if the ESXi host wasn't getting time from NTP, you'd have a larger discrepancy, like he's seeing. If I'm reading it right, he's seeing 10 or more minutes on some of the processes, which could also lead me to believe it could also be a time zone calculation problem (not an hour, since it's process run time, right?) If VMWare tools is setting based on one time zone and NTP on another (or differing application of Daylight Savings Time.)
But, yes, any way about it, it certainly looks like 2 competing time setting mechanisms.
I did some quick looking around and the main consensus is to pick just one, of course, but there didn't seem to be a whole lot of overwhelming bias towards one or another time setting mechanism. The down side of VM Tools is that it depends on the host to be right and the time service of a VM host isn't always perfectly stable (I've seen whole groups of hosts lose the NTP service before, but the time of the host itself is usually pretty stable even if NTP isn't working.) On the other hand, a down side of using NTP on a VM is some OS's may fail updating time if it's too far off, but that usually only happens in rare situations where you've suspended a VM for a while and it didn't sync when restarting, or when the same problem strikes after reverting to a snapshot with snapshotted memory, but again, that is pretty rare since time should be re-synced during the restart/revert process even if VMWare tools isn't set to sync OS time.
But, I'm probably digressing from the main point, don't run more than 1.
-
-
Some good detail in here: http://www.vmware.com/pdf/vmware_timekeeping.pdf
… I thought that's what you were getting at earlier ...
Yeah, but I did say it in a round about sort of way :)
If VMWare tools is setting based on one time zone and NTP on another…
I see what you're getting at but NTP only deals with UTC.
-
I am running the same timeserver dk.pool.ntp.org on both.
Can I just delete the specified server in Pfsense? I cannot configure vm-tools in pfsense from the GUI.
-
If VMWare tools is setting based on one time zone and NTP on another…
I see what you're getting at but NTP only deals with UTC.
I wasn't sure how BSD deals with time zones in respect to UTC, if the OS "lives" on UTC and translates it out to the user environments or the system clock is set to local time with the offset from UTC as defined in time zones. Same with VMWare tools in BSD. If they're setting according to a different time zone, or one is applying a Daylight Savings Time offset and the other isn't, I could see it gaining and losing an hour often. I also don't know what kinds of intervals NTP and the VMWare tools are checking/setting time at in BSD.
I come from the Windows world in most respects, especially regarding VM's on ESX(i). In Windows the VMWare Tools should be setting time based on the local Guest OS Time Zone setting, same as if you're polling a Time Server. It can get slightly messy if it's on a domain since the Domain should be the authoritative time source.
Of course, I'm tangenting, again. I do that. It just seems that there's quite a difference between the 2 time sources and/or how they're being applied.
-
Yes, but if you use your AD based on VMtools in your guest OS, thats the right way to do it.
Let VM handle the NTP and not your guest OS.
Thats why I think it would be better if it could be turned of in PFsense if it detects vmtools package….
-
Can I just delete the specified server in Pfsense? I cannot configure vm-tools in pfsense from the GUI.
I don't think there is a GUI way to "disable" NTP in pfSense. http://forum.pfsense.org/index.php/topic,57041.0.html. You can manually stop it but I guess that wouldn't survive a reboot.
Configure VM Tools through the vShpere client: Right-click VM > Edit Settings > Options tab (I think that's the same on Esxi 4.1)
-
I know….but it DOESNT synchronize time in Vsphere GUI....
So I dont get it. Thats why I wondered if there was anything in the tools package that did it without telling anybody??
-
You can try to change the timecounter (search around for kern.timecounter.choice and kern.timecounter.hardware) to see if that helps.
Certain newer versions of vmware can have the clock flake out if it's using HPET.
-
You can try to change the timecounter (search around for kern.timecounter.choice and kern.timecounter.hardware) to see if that helps.
Certain newer versions of vmware can have the clock flake out if it's using HPET.
Thanks for the tip, I had the same issue with my pfsense vm, I tried the above commands:
Current settings
sysctl kern.timecounter.hardware
Available options
sysctl kern.timecounter.choice
New settings based on available options
sysctl -w kern.timecounter.hardware=ACPI-safe
With the ACPI-safe option, the errors went away, the previous HPET option caused the problem for me, as noted.
I understand the same can be achieved by switching off HPET in the bios, if its available.
-
No need to run the sysctl manually, you can add that as a tunable under System > Advanced on the Tunables tab, it will be applied automatically once you add it, and at boot time.
-
Thanks
