Moka5
Moka5


Ensure BMP time in the guest is correct   « Go Back

Summary

BMP deployments can suffer from seemingly unexplainable time sync issues which manifest themselves in a guest which has an incorrect UTC offset.

In this article we explain how the BMP needs to be configured to ensure correct time function in the guest.

Detail

Any time drift experienced is not a bug, just a configuration issue related to the difference between how Windows and Linux function.

Windows expects local time in the BIOS
Linux (BMP) expects UTC time in the BIOS

  1. On devices where Windows was previously installed, the CMOS time is being set to Local Time by Windows. This is normal Windows behaviour, to ensure the bios clock is sync with the OS clock. The Win32_Time service takes care of this using an algorithm based on the time source, NTP, Domain etc…but the final result is the CMOS clock matches the Windows local time.
  2. When Bare Metal is installed on one of these devices, it will first check its the list of NTP servers held in /etc/ntp.conf - this file also contains any entries configured via the Moka5 Player policy: "List of NTP servers to use for BareMetal". This can be found in the general section of the player policy list. As the default NTP servers are internet based if the BMP inside the corporate environment does not have a connection directly out to the internet it will NOT be able to reach the NTP servers. Thus customers will need to add an internal corporate NTP server address via the aforementioned Moka5 Player policy.
  3. Ultimately if the BMP can find no NTP Time Source it will fall back and take the time from the BIOS. BMP (which is based upon a Linux kernel) expects to see the BIOS time as UTC+0 and assumes this is the case. It then sets its UTC time to the time in BIOS. If the BIOS time is not set to UTC - this is where incorrect time problems come from.
  4. The Moka5 Player will then take the UTC time as reported by the Linux Host and pass to the guest as UTC+0.
  5. The guest presumes the time passed by the player is UTC+0 when in fact it may well be local time (UTC-7 UTC+1 or UTC +2? or any other value dependant on your location). The guest will then set the relevant time zone offset, for example for United Kingdom case UTC+1 for British Summer Time and will also write this to the Virtual Hardware BIOS but not the Host (BMP) Device.
  6. We now have a guest device which is set to the wrong UTC offset and hence the wrong time. It can look like other applications may be responsible, such as VMware Tools, but this is the first place you should check and is usually where the problem lies.
This is a common problem for anyone that dual boots between windows and Linux as they will see this issue. Windows wants to see Local Time for backwards compatibility with previous versions and does so by keeping the CMOS clock in sync with its local time. Linux is more like an airline pilot, it wants to view time in UTC and assumes the BIOS is UTC+0.


How do we fix it?

Well this is an issue of time, we can't tell the time unless someone gives us an authoritative time. The BMP has no concept of where it is or what time it is, it has to rely on something, either NTP or BIOS. BIOS can not be relied upon to be 100% correct as is subject to user error and change by windows as previously discussed, therefor NTP is by far the best solution.

  • We need the Bare Metal Player to be able to reach a Time Source.
    • We set the time source NTP as a policy to act as a definitive time source for the Bare Metal Player.
    • We either open up the Internet Proxy to allow direct access to a couple of external Time Sources

    or