VMware Communities
somethingnew
Contributor
Contributor
Jump to solution

Enable/disable time sync (again)

Hi,

I've seen in other threads that you can completely disable time sync by adding the following entries to the .vmx file:

tools.syncTime = "FALSE"

time.synchronize.continue = "FALSE"

time.synchronize.restore = "FALSE"

time.synchronize.resume.disk = "FALSE"

time.synchronize.shrink = "FALSE"

tools.synchronize.tools.startup = "FALSE"

The problem is that on my Vista Ultimate VM, time is still being synched. As soon as VM Tools loads, the I get the same time as on MAC OS. And I do have the option disabled on VM Tools Options to synchronize time...

What am I doing wrong?

Thanks in advance

SN

Reply
0 Kudos
1 Solution

Accepted Solutions
admin
Immortal
Immortal
Jump to solution

Hi Woody,

I tried reproducing this on 2.0.4 and so far tools.syncTime works as expected. Keep in mind that time synchronization can happen in several ways, and tools.syncTime only affects one of them - somethingnew is correct in saying there are other settings which affect guest time.

I'm sure you know this, but as background for anyone else, computers have a real-time clock to keep time when the computer is powered off. When a computer starts up, the OS typically asks the BIOS what time it is to get started. Since virtual machines don't actually have little virtual RTCs that run all the time, when we start up a virtual machine, we ask the host what time it is and feed that to the guest. This isn't Tools related, it happens on virtual machines without Tools installed at all. I believe that tools.syncTime should not affect this. We're supposed to remember the offset between the host's time and the guest time, but I'm not sure under what conditions this offset is saved (some may be guest-specific). In my quick experiments, changing the BIOS clock did not persist across guest reboots (including the one needed to save changes), which seems possibly wrong.

Once the guest is running, time may drift - for example, say you're doing extremely intensive work on the host and the guest doesn't get scheduled to run, or maybe you suspend the virtual machine and then come back later. This is where Tools time sync comes in. If the time is slightly behind, we nudge it forward at a slightly increased rate; if it's behind by a lot or nudging hasn't worked, we jump the clock. I made sure time sync was enabled and that the virtual machine (XP Pro SP3) was disconnected from the network. I then set the guest clock back by both about 30 seconds and about 10 minutes - in both cases, guest time jumped forward to the host time after a little while. I then disabled time sync (via the VMware Tools taskbar icon) and set the guest clock back by both about 30 seconds and about 10 minutes - in both cases, guest time remained consistently behind for as long as I cared to watch. This is exactly what I expected to see.

tools.syncTime automatically syncs the guest time every so often, but Tools can also sync time in some other circumstances, such as when Tools start up. In order to disable guest time syncing, you need to disable the other cases when this happens. For the next experiment, I added the following lines to my .vmx config (as usual, virtual machine shut down and Fusion not running):

rtc.diffFromUTC = "-600"
time.synchronize.continue = "FALSE"
time.synchronize.restore = "FALSE"
time.synchronize.resume.disk = "FALSE"
time.synchronize.shrink = "FALSE"
time.synchronize.tools.startup = "FALSE"

The rtc.diffFromUTC sets an offset of 10 minutes so I could see if this had an effect, while the others come from Timekeeping in VMware Virtual Machines (also listed in KB 1189). I think only the last one is needed for the way I did this experiment (in addition to tools.syncTime), but I thought it wouldn't hurt to include the others. Indeed as expected, starting up showed a different guest time.

I think tools.syncTime is working properly. The BIOS time change not sticking seems questionable, but I'm not sure if this is intended behavior or not.

Woody, can you see if adding time.synchronize.tools.startup = "FALSE" does what you expect?

somethingnew, note that it should be time.synchronize.tools.startup, not tools.synchronize.tools.startup.

View solution in original post

Reply
0 Kudos
14 Replies
WoodyZ
Immortal
Immortal
Jump to solution

Have you checked to see if Windows itself isn't syncing with a Time Server?

somethingnew
Contributor
Contributor
Jump to solution

I've disabled network connection to the windows vm.

When the vm starts, I can see the time is the one I defined in the vm bios, but after VM Tools loads, it syncs with my mac

Reply
0 Kudos
puzzledtux
Hot Shot
Hot Shot
Jump to solution

I am not sure if this will work, but maybe worth a try if not already done!

Launch the vmware toolbox in the virtual machine, click the Options tab. Enable time-sync and save this setting. Now re-launch the toolbox and disable time-sync again. If the issue still persists, can you post your vmx file?

WoodyZ
Immortal
Immortal
Jump to solution

If the issue still persists, can you post your vmx file?

@somethingnew: If need be archive the .vmx configuration file and then attach the archive.zip file. Do not copy and paste the entire contents of the .vmx configuration file into a reply.

Also in addition to toggling the flag per puzzledtux's directions have you also tried uninstalling/reinstalling VMware Tools?

Reply
0 Kudos
somethingnew
Contributor
Contributor
Jump to solution

I've tried both suggestions and I still get the vm's time updated. I must have an error in my file. I've attached it

Thanks guys.

Reply
0 Kudos
WoodyZ
Immortal
Immortal
Jump to solution

tools.syncTime = "FALSE" is the only setting that you should have to make however let me say this, that I just tested on my system and this is now no longer working when it has in the past and I'm running Fusion 2.0.4 yet when I had Fusion 2.0.2 installed it worked so there might be a bug and have sent a message to one of the Fusion developers to take a look at this thread.

Reply
0 Kudos
somethingnew
Contributor
Contributor
Jump to solution

Ah, but I have Version 2.0.2 (146107)…

Reply
0 Kudos
WoodyZ
Immortal
Immortal
Jump to solution

All I can tell you is that under Fusion 2.0.2 in both Windows XP and Vista having only tools.syncTime = "FALSE" in the .vmx file I had no problems maintaining different date/times yet now in Fusion 2.0.4 with that entry there and now network connectivity the time still syncs and this is just one more thing that's pissing me off about Fusion 2.x because I need to maintain different date/time in one virtual machine in order to test date/time timeouts for various programs. Looks like I'm going back to Fusion 1.x or maybe just go back to Parallels as I'm growing very tired of all the issues with Fusion 2.x.

Reply
0 Kudos
admin
Immortal
Immortal
Jump to solution

Hi Woody,

I tried reproducing this on 2.0.4 and so far tools.syncTime works as expected. Keep in mind that time synchronization can happen in several ways, and tools.syncTime only affects one of them - somethingnew is correct in saying there are other settings which affect guest time.

I'm sure you know this, but as background for anyone else, computers have a real-time clock to keep time when the computer is powered off. When a computer starts up, the OS typically asks the BIOS what time it is to get started. Since virtual machines don't actually have little virtual RTCs that run all the time, when we start up a virtual machine, we ask the host what time it is and feed that to the guest. This isn't Tools related, it happens on virtual machines without Tools installed at all. I believe that tools.syncTime should not affect this. We're supposed to remember the offset between the host's time and the guest time, but I'm not sure under what conditions this offset is saved (some may be guest-specific). In my quick experiments, changing the BIOS clock did not persist across guest reboots (including the one needed to save changes), which seems possibly wrong.

Once the guest is running, time may drift - for example, say you're doing extremely intensive work on the host and the guest doesn't get scheduled to run, or maybe you suspend the virtual machine and then come back later. This is where Tools time sync comes in. If the time is slightly behind, we nudge it forward at a slightly increased rate; if it's behind by a lot or nudging hasn't worked, we jump the clock. I made sure time sync was enabled and that the virtual machine (XP Pro SP3) was disconnected from the network. I then set the guest clock back by both about 30 seconds and about 10 minutes - in both cases, guest time jumped forward to the host time after a little while. I then disabled time sync (via the VMware Tools taskbar icon) and set the guest clock back by both about 30 seconds and about 10 minutes - in both cases, guest time remained consistently behind for as long as I cared to watch. This is exactly what I expected to see.

tools.syncTime automatically syncs the guest time every so often, but Tools can also sync time in some other circumstances, such as when Tools start up. In order to disable guest time syncing, you need to disable the other cases when this happens. For the next experiment, I added the following lines to my .vmx config (as usual, virtual machine shut down and Fusion not running):

rtc.diffFromUTC = "-600"
time.synchronize.continue = "FALSE"
time.synchronize.restore = "FALSE"
time.synchronize.resume.disk = "FALSE"
time.synchronize.shrink = "FALSE"
time.synchronize.tools.startup = "FALSE"

The rtc.diffFromUTC sets an offset of 10 minutes so I could see if this had an effect, while the others come from Timekeeping in VMware Virtual Machines (also listed in KB 1189). I think only the last one is needed for the way I did this experiment (in addition to tools.syncTime), but I thought it wouldn't hurt to include the others. Indeed as expected, starting up showed a different guest time.

I think tools.syncTime is working properly. The BIOS time change not sticking seems questionable, but I'm not sure if this is intended behavior or not.

Woody, can you see if adding time.synchronize.tools.startup = "FALSE" does what you expect?

somethingnew, note that it should be time.synchronize.tools.startup, not tools.synchronize.tools.startup.

Reply
0 Kudos
somethingnew
Contributor
Contributor
Jump to solution

...

somethingnew, note that it should be time.synchronize.tools.startup, not tools.synchronize.tools.startup.

This was enough to correct the problem. Now it dosn't update the time anymore. I guess puzzledtux and WoodyZ were mislead by my posts and by my file… Sorry.

Thanks to all that helped me fixed this so fast.

Regards,

SN

Reply
0 Kudos
sailorman
Contributor
Contributor
Jump to solution

Please, help me, because solution which was mentioned above, didn't work on my VMware workstation 6.5.1.

I changed win2003.vmx file:

rtc.diffFromUTC = "-600"

time.synchronize.continue = "FALSE"

time.synchronize.restore = "FALSE"

time.synchronize.resume.disk = "FALSE"

time.synchronize.shrink = "FALSE"

time.synchronize.tools.startup = "FALSE"

When I starting up my virtual machine date and time is the same like on host machine.

Does anyone known why it's didn't work?

Regards

Reply
0 Kudos
WoodyZ
Immortal
Immortal
Jump to solution

Woody, can you see if adding time.synchronize.tools.startup = "FALSE" does what you expect?

Eric, sorry this slipped past me. I set the following parameters along with disabling Windows automatically synchronizing with a Time Server and it maintains the Date/Time differential I want.

tools.syncTime = "FALSE"
time.synchronize.tools.startup = "FALSE"

Thanks,

Woody

Reply
0 Kudos
WoodyZ
Immortal
Immortal
Jump to solution

When I starting up my virtual machine date and time is the same like on host machine. Does anyone known why it's didn't work?

See my reply:

Reply
0 Kudos
admin
Immortal
Immortal
Jump to solution

Something I've been meaning to test but haven't gotten around to yet:

Suppose I want a virtual machine which is completely isolated from the external world timewise (I think this is your case). This use case breaks when we add additional time synchronization steps (e.g. on tools startup), and tools.syncTime is misleading (it should be something like tools.syncTime.automatically). We could theoretically add more syncronization steps at other points and this use case would break again, so adding time.synchronize.tools.startup is just a workaround and doesn't address this use case. Based on the name, isolation.tools.getTime.disable might work to completely cut off the guest from the host time.

Reply
0 Kudos