I am evaluating vSphere Hypervisor ESXi and I have an issue with NTP service with regards to Time Zone.
I have a Windows 10 workstation running VMware Workstation 15 Pro (15.5.7 build-17171714) for which I own a regular license. I created a virtual machine and installed VMware vSphere Hypervisor ESXi - 7.0U3d x86_64
When I connect to the VM via UI, I am able to enable NTP, add a custom NTP server but the time zone remains incorrect. It is always two hours behind current time. I live in Italy and currently I have GMT+2 as per daylight saving.
I am unable to request direct tech support as the system does not allow me to do so. Anyone can please advise?
That's by design. ESXi doesn't offer an option to set a time zone, but works with with the UTC time zone.
The GUI will translate the time to that of the system on which you run the client.
Thank you André for your reply.
I only have one question: if by design ESXi works this way what is the purpose of reporting the wrong system time? To me it does not make any sense what's so ever considered how important time is for other purposes. Is there a solution to this issue or one shoud just ignore using NTP services and set time manually (which I dislike)?
i.e.: UTC time zone reports 13:30 when instead in Italy it is 15:30
ESXI ui GUi reports time being 13:30 which in real thruth it is not accurate.
How come before it was possible to adjust time zone, if I correctly understood this vmware article?
Not an expert here, but currently working on NTP for our production environment...
Timezone is set when you set the locale of the ESXi host during installation I believe. The time, when using NTP is provided by the NTP source. Here in the UK we have this GMT+1 thing going on, so not dissimilar to you. So, a Windows server for us gets NTP from the internet (that server has correct time zone etc), and our ESXi servers points to the Guest server for NTP (along with everything else). Most organisations use their internet gateway/proxy/firewall to provide what I call authoritive NTP. In the end, the ESXi should report the correct time for your zone provided the time source (in our case a Windows server) is setup to provide NTP as a source and has the correct TimeZone info.
I hope that helps - just chipping in since I'm looking at similar stuff myself now.
What i understand you installed ESXI host in workstation as vm. it means your esxi base is windows server. as per best practice . hardware must be configure with GMT and allow to reset time if OS required. in this case, windows not allow to change time requested from vm (Esxi host.). I believe due to 2 OS conflict with ntp . Guest OS given you wrong time. please disable one of NTP service. than check it. It might be works.
Sorry, this is probably a little confusing. There are two general rules when dealing with time zones on ESXi and vSphere. First, as Andre said, ESXi works exclusively with UTC and does not set or use a local time zone. This applies when you use the command shell on the ESXi host or connect to ESXi’s UI directly. Second, the NTP daemon and all of the operations that set and synchronize the system clock also operate exclusively in UTC.
If you want to manage and view an ESXi host using a local time zone, please use vSphere vCenter. You can set the time zone in vCenter using the vCenter Server Management Interface. Log into the Management Interface (see: https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.m.vcenter.configuration.doc/GUID-9831B635-D...) and then navigate to the Time Zone and Time Synchronization Settings page (see: https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vcenter.configuration.doc/GUID-A43F...) . Once you complete the configuration, the ESXi host’s time stamps will be visible in local time in the vSphere Client.
ESXi works this way because administrators sometimes manage many ESXi hosts across different time zones. So, it’s better that the translation to local time happens where the management gets done rather than where the host resides.
[KB article 1436 only applies to very old versions of ESX which are no longer supported.]