esxi host, bios screen, time appears to be UTC

I want to add, I recently upgraded ESXi to 6.0.0. I don't remember this problem when I was on 5.1.0 or earlier.

If I go into the VM's Edit Settings, Options, VM Tools, I see the "Synchronize guest time with host option" unchecked. So I assume I don't have to do anything. I don't think I have a sync problem - I have a VM-init-when-powered-up problem.

Per Article above

In the VMware Tools control panel, the time synchronization checkbox is unselected, but you may experience these symptoms:
When you suspend a virtual machine, the next time you resume that virtual machine it synchronizes the time to adjust it to the host.
Time is resynchronized when you migrate the virtual machine using vMotion, take a snapshot, restore to a snapshot, shrink the virtual disk, or restart the VMware Tools service in the virtual machine (including rebooting the virtual machine).

You will find, if you have that option unchecked, it makes NO DIFFERENCE, that just tells the VM to sync when the VM is powered up.

ALL VMs will sync with host at boot, unless you modify the VMX file....

check your VMX file.

OK. Thanks. The first time I read it wrong. This explains why I have seen some out-of-order events in the windows event log.

Sorry if I'm dense, but I assume when you power up a VM, the host's time is given to the VM. Is that correct?

Sorry if I'm dense, but I assume when you power up a VM, the host's time is given to the VM. Is that correct?

Unless you have disabled it, in the VMX file.

also...

Time is resynchronized when you migrate the virtual machine using vMotion, take a snapshot, restore to a snapshot, shrink the virtual disk, or restart the VMware Tools service in the virtual machine (including rebooting the virtual machine).

This is the part I'm not understanding. If you disable it, what time does the VM use?

nothing.

You then need to configure the VM, which is highly recommended, follow best practice below.

1. Configure Hosts to Sync with External Time source, e.g. internet or GPS

2. Configure Windows Active Directory PDC emulator to sync with the same time source as 1.

3. All Windows VMs in the Domain will obtain time sync from 2 above. (PDC emulator).

4. Configure Unix/Linux VMs to obtain time from 1. above.

Nothing? The date/time field in the BIOS screen has to have something in it. I'm talking about when you power on a VM and enter BIOS setup mode, the date/time values on the screen.

When your OS, BOOTs and obtains time, from it's time source, it will hardware sync to the BIOS, and update time.

if you find when entering the bios, time is incorrect, set it once, from that moment on, OS will obtain the correct time to maintain the correct time.

Andrew, I thank you for your effort, but you seem to be stepping all around my question. It's simple: where does the VM get its time at startup.

At first startup of the VM (after initial creation) the VM will sync with HOST, if you want to stop it getting time from HOST, on every other REBOOT or POWER-ON, disable it!

If you are currently observing the time on your VM, syncing with the Host AT BOOT, disable it, again check what setting you have in the VMX file?

have you checked what these values are set to ZERO to stop the VM at Power ON etc

is the issue you have, at Power ON, Reboot, the VM time changes and moves forward by 4 hours ?

tools.syncTime = "0"
time.synchronize.continue = "0"
time.synchronize.restore = "0"
time.synchronize.resume.disk = "0"
time.synchronize.shrink = "0"
time.synchronize.tools.startup = "0"
time.synchronize.tools.enable = "0"
time.synchronize.resume.host = "0"

It does not matter if you have VMware Tools also set to do not sync!

Thanks.

Update: I am starting to notice a pattern when viewing the BIOS Setup screen of a powering-up VM on my ESXi 6.0.0 hosts. On some VMs, the screen's date/time field contains the local time (i.e. 10:00:00 for 10AM) and on others it contains the UTC time (14:00:00 for me in US-Eastern). It turns out that Windows VMs have the local time and VMs with the OS defined as Other have UTC in the BIOS setup screen. To rule out other factors (I.e. all my Windows VMs have the tools installed and all others don't), I took an XP Pro 64 VM and changed the Guest OS attribute to Other 64-bit. At power-up the BIOS Setup screen contained UTC time. I changed the Guest OS attribute back to XP Pro 64-bit and the BIOS Setup screen showed local time.

Many articles (and the experienced contributors to this thread) stress turning off time synchronizing (see above). This seems to be a must-do if the host periodically makes 4+ hour adjustments to the VM's clock that the guest OS has to adjust back using its ntp procedures. However if the time adjustments are less than a second (the typical ongoing ntp adjustment), it can become a judgment call whether to enter all of these settings into many VMs' vmx files. I only have the free ESXi license (hopefully this summer, Essentials) so I have to manually enter them. Worse, other settings that I manually enter get lost when I do things such as save/restore the VM using the VSphere Client's Export/Deploy OVA, so I assume I will have to periodically re-enter these settings as well. Please note that I would be interested to see other points of view on this.

I had a problem that can traced to the shifted date/time. Using VSphere's Deploy OVA, I restored test copies of the 2 domain controllers (Windows 2012 RC) into a sandbox. For some reason the 2 OS's times were shifted 4 hours. The PDC adjusted its time (its ntp partners are external) but the other dc couldn't (it has to replicate to get the ntc partner), preventing the dcs from replicating and thus working. A catch-22! Combined with other problems with the dc's, It took me much longer to get figure out what's wrong and get the test environment up and working. Why the times were UTC for these VMs, I don't know. They show local time now.

I point out this local/UTC BIOS time issue because not knowing exactly how ESXi works caused me big headaches, and I have not seen anything anywhere explaining it. If I have missed anything, or anybody has something else to contribute, please speak up.

Again, thanks to everybody that helped out.