VMware Communities
Poxnor
Contributor
Contributor

VMWare Fusion Interferes with NTP Synchronization on OS X Startup

Hello,

I am experiencing a problem with VMWare Fusion, and I am hoping that someone here will be able to help me. The problem concerns NTP synchronization as OS X is starting up.

Assume that the system clock is horribly off (for example, when I am rebooting into OS X from a Boot Camp native boot of Windows XP). Because I have "Set date & time automatically" chosen in OS X's "Date & Time" preferences, the clock should automatically fix itself as OS X starts up. So, the clock inaccuracy should not be a problem.

However, the "boot.sh --start" process started by /Library/LaunchDaemons/com.vmware.launchd.vmware.plist is preventing the clock synchronization from occurring.

If I remove the "com.vmware.launchd.vmware.plist" file, then NTP synchronization occurs as it should, and my clock is automatically fixed as OS X boots up, after a native boot of Windows in Boot Camp. Unfortunately, then, I have to run "boot.sh --start" manually before I can use VMWare.

I would like to help out by providing logs, or anything else to help diagnose why "boot.sh --start" interfers with NTP synchronization as OS X boots, but I do not know what logs to provide, or what may be helpful.

My goal is to be able to have proper time synchronization as OS X boots, but not have to manually run "boot.sh --start" to enable VMWare Fusion before I run it. Does anyone have any suggestions?

Thank you very much for your time.

Reply
0 Kudos
12 Replies
mtatmc
Enthusiast
Enthusiast

Do you have different setting in your Boot Camp instance that are throwing off the clock in the first place?

Taking a look at boot.sh I don't immediately spot where the start process would affect the ntp sync. If you look in your boot.sh file it shows its logging process iirc.

Reply
0 Kudos
Poxnor
Contributor
Contributor

Do you have different setting in your Boot Camp

instance that are throwing off the clock in the

first place?

Windows keeps the system clock in local time, unlike how OS X keeps it in UTC. So, Apple's Boot Camp software includes an NTP client service, installed in Windows, which automatically updates your system clock to local time when you boot into Windows. OS X relies on its built-in NTP client (see the "Date & Time" settings) to reset the clock to UTC when you boot back into OS X.

It works flawlessly, when VMWare Fusion isn't present in OS X.

Taking a look at boot.sh I don't immediately spot

where the start process would affect the ntp sync.

I'm guessing it has something to do with the VMWare Fusion startup script (boot.sh) initializing the various network subnets and DHCP stuff. I think that this is somehow interfering with OS X's NTP client attempting to contact the NTP server.

If you look in your boot.sh file it shows its

logging process iirc.

I see a program called "logger" being launched with some pretty simple text parameters? Is there some output that I can provide that would be helpful? If so, how can I capture or find it?

I hoped that the logs produced by the NTP client may actaully reveal more, since it is the NTP client that is not functioning (VMWare Fusion works fine, despite the NTP issue in OS X). Unfortunately, I haven't found anything meaningful in those logs. I'll continue to search, and I'll post what I find.

Reply
0 Kudos
mtatmc
Enthusiast
Enthusiast

I'm guessing it has something to do with the VMWare

Fusion startup script (boot.sh) initializing the

various network subnets and DHCP stuff. I think that

this is somehow interfering with OS X's NTP client

attempting to contact the NTP server.

Looking in the system log it appears that ntpdate tries to run after the vmnet interfaces are initialized, but before the native interfaces are up - the log says ntpdate can not find time.apple.com, indicating that it tried and failed to get a route out -OR- that it has a DNS error and can not resolve. More research to be done ...

I see a program called "logger" being launched with

some pretty simple text parameters? Is there some

output that I can provide that would be helpful? If

so, how can I capture or find it?

Based on the system log I don't think the problem will be in the boot.sh generated logs.

One thing one can do is run:

sudo ntpdate after boot up, but that is not a long term solution by any means.

I hoped that the logs produced by the NTP client may

actaully reveal more, since it is the NTP client that

is not functioning (VMWare Fusion works fine, despite

the NTP issue in OS X). Unfortunately, I haven't

found anything meaningful in those logs. I'll

continue to search, and I'll post what I find.

Take a look at the system log - I will myself in greater detail as time permits.

Poxnor
Contributor
Contributor

Looking in the system log it appears that ntpdate

tries to run after the vmnet interfaces are

initialized, but before the native interfaces are up

- the log says ntpdate can not find time.apple.com,

indicating that it tried and failed to get a route

out -OR- that it has a DNS error and can not resolve.

More research to be done ...

I'm guessing the problem is both of those things -- there's no route to the NTP server, but there's also no route to the DNS server.

For example, if I resolve my NTP server's domain name to an IP a priori, and place that IP in the Date & Time settings box, the system log shows:

sendto(#.#.#.#): No route to host

sendto(#.#.#.#): No route to host

sendto(#.#.#.#): No route to host

sendto(#.#.#.#): No route to host

no server suitable for synchronization found

\[where #.#.#.# is the IP of my NTP server]

If, however, I use the FQDN of my DNS server, instead of its IP address, I get:

can't find host *****

no servers can be used, exiting

\[where ***** is the FQDN of my DNS server]

I'm guessing the issue is just the lack of an interface with which to talk to the rest of the world: whether that be talking to my DNS server to resolve my NTP server, or just plain talking to my NTP server if the IP is pre-resolved.

Reply
0 Kudos
Poxnor
Contributor
Contributor

Looking in the system log it appears that ntpdate

tries to run after the vmnet interfaces are

initialized, but before the native interfaces are up

- the log says ntpdate can not find time.apple.com,

indicating that it tried and failed to get a route

out -OR- that it has a DNS error and can not resolve.

More research to be done ...

Alright: with your help, I was able to devise a workaround, which should work for the time being.

I believe[/i] the problem is as follows: when OS X's NTP client is first started by launchd (the init/rc replacement for OS X), the NTP client thinks that it has network access. After all, there are interfaces enabled. Little does the NTP client know, but those are just VMWare Fusion's interfaces. So, naturally, the NTP synchronization fails.

The trick is to make launchd wait until your "real" interface (for lack of a better name) is enabled before starting the NTP client. That is, wait until your ethernet or Airport connection to the network is up, then start the client.

The trick to doing this is to edit the following file:

/System/Library/StartupItems/NetworkTime/StartupParameters.plist

And, to this file you have to add the line (inside the braces):

Requires = ("Hostname");

This forces launchd to wait until you have a hostname (which happens when your real interface comes up) before launching the NTP client.

Now, I haven't extensively tested this workaround (i.e., I've tested it on my one iMac, which is running on my home network, which includes a nameserver and an NTP server). However, if this workaround works for other people as well, this should resolve the clock discrepancy issue that occurs between a native boot of Windows and OS X, when VMWare Fusion is installed in OS X.

(I refer to this as a workaround, instead of a solution, simply because it requires users to edit files in /System, which can be risky, and those changes could be blown away by an OS X update, or anything else. Ideally, there would be an easier workaround that could be discovered, or potentially even a fix in VMWare Fusion).

Reply
0 Kudos
mtatmc
Enthusiast
Enthusiast

I concur with your thinking. The question in my mind now is how did Apple and VMware both miss this one? Windows inability to deal with UTC has a long documented history.

Edit - Apple did not miss the time problem - there recommended solution is to force time sync on reboot in Windows as OSX already does. The issue as we have discovered is WHEN OSX does the time sync - just as soon as possible, which only becomes a problem when OSX thinks the VMNET interfaces are "real".

Message was edited by: mtatmc

mtatmc

Reply
0 Kudos
mtatmc
Enthusiast
Enthusiast

So a search on "RealTimeIsUniversal" - there is a setting in the Windows Registry that can force Windows to use UTC on the system clock. I have not tried it yet or done extensive research.

Reply
0 Kudos
Poxnor
Contributor
Contributor

So a search on "RealTimeIsUniversal" - there is a

setting in the Windows Registry that can force

Windows to use UTC on the system clock. I have not

tried it yet or done extensive research.

Unfortunately, this setting has been neglected by Microsoft. Many applications (even MS applications) ignore this setting (some of which even reset the clock to local time), so the end result is an absolute mess if you set it to be true. That is why Apple used an NTP approach to resetting the clock, rather than using this registry option.

Reply
0 Kudos
Poxnor
Contributor
Contributor

The issue as we have

discovered is WHEN OSX does the time sync - just as

soon as possible, which only becomes a problem when

OSX thinks the VMNET interfaces are "real".

Is there anywhere that I should file an official bug report, complete with the workaround, to VMWare? Or, does posting on these forums suffice?

Reply
0 Kudos
admin
Immortal
Immortal

Is there anywhere that I should file an official bug

report, complete with the workaround, to VMWare? Or,

does posting on these forums suffice?

http://www.vmware.com/support/support_feedback.html, except it doesn't yet have an entry for Fusion (presumably you could file it under something else, perhaps Workstation or Player, and at the top note that it's really for Fusion). I've already filed a bug internally.

Poxnor
Contributor
Contributor

(I refer to this as a workaround, instead of a

solution, simply because it requires users to edit

files in /System, which can be risky, and those

changes could be blown away by an OS X update, or

anything else. Ideally, there would be an easier

workaround that could be discovered, or potentially

even a fix in VMWare Fusion).

Indeed, I have discovered one issue with my workaround to the problem of NTP synchronization. Using this workaround (in which the Network Time service is made to wait for a hostname) will interfere with the OS X printing system start-up. So, if you want to print anything, you will have to run "Reset Printing System" from inside the "Printer Setup Utility" application each time you reboot into OS X.

I have discovered a workaround for this issue as well. Specifically, you must remove the line:

Uses = ("Network Time");

from the file:

/System/Library/StartupItems/PrintingServices/StartupParameters.plist

This will allow the Printing services to start up properly, so that you will not have to "Reset Printing System" on each reboot. Why the Printing services don't start properly after Network Time, without this workaround, is still a mystery to me; so, unfortunately, this workaround is a bit of a hack.

While it now appears that everything is working properly, this is nonetheless a "chain of workarounds" we have going here (one workaround to make Network Time starts up properly when VMWare Fusion is installed; and, a second workaround which ensures that Printing services start up properly when the first workaround is used). If anyone has a better suggestion (e.g., a fix that can be applied directly to VMWare Fusion, instead of these OS-configuration hacks), that would be greatly appreciated.

Thank you very much!

Reply
0 Kudos
Poxnor
Contributor
Contributor

Sorry to resurrect a long-dead thread, but I wanted to post an update on this issue for Snow Leopard (OS X 10.6). If anyone is experiencing this issue under Snow Leopard, I have included a fix below. The issue, specifically, is: upon rebooting from a Boot Camp install of Windows into OS X, the clock is set incorrectly in OS X.

The basic facts are as follows: OS X and Windows keep time differently. Apple solved this issue by having both OS X and a Boot Camp Windows install sync their clocks against an NTP server while booting up, so each operating system sets the system clock in its desired fashion.

The mechanism for running NTP is different in OS X 10.6 than it was in previous iterations of OS X. In 10.6, NTP is launched from /System/Library/LaunchDaemons. That launch daemon, in turn, calls /usr/libexec/ntpd-wrapper.

That wrapper script will busy wait until DNS is available, then use sntp to reset your computer clock to the value provided by the NTP server, then launch the ntpd daemon to keep your clock in sync.

However, the wrapper script will spin in its busy wait for at most 30 seconds. In most cases, this is more than sufficient. For example, my iMac (2.4 GHz, late 2007 model) connects to my 802.11n / WPA2 network during boot; the wrapper script will typically spin for under 10 seconds, waiting for DNS to become available.

However, in some cases, it takes longer for DNS to become available (wireless interference, server hiccup, bad luck?). In this case, sntp will fail to resolve the NTP server, and your clock will not be reset immediately.

This isn't really a big deal, though. ntpd will still start, and your clock will be reset whenever ntpd decides to try reaching the NTP server again. So, your clock will only be incorrect for a few minutes, until ntpd takes a stab at it.

(This is also nice if you are without connectivity, e.g., on an airplane: shortly after regaining connectivity, ntpd will be ready and waiting for you).

That said, if you find that, upon rebooting from Windows into OS X, your clock is frequently set incorrectly (despite having connectivity to an NTP server), all you have to do is increase the amount of time ntpd-wrapper spins in its busy wait. Just edit /usr/libexec/ntpd-wrapper, and change the value of TIMEOUT from 30 to, e.g., 60. This will make ntpd-wrapper wait longer for you to get DNS capabilities before giving up.

Hope this helps!

Reply
0 Kudos