macOS VM date/time/clock is not synchronized with the host

[rgl]

The macOS VM date/time/clock is not being synchronized with the host; in fact, it seems its seeded from the time when the VM was last built.

For example, macos-ventura-xcode 14.3.1 at https://github.com/cirruslabs/macos-image-templates/pkgs/container/macos-ventura-xcode/101275224?tag=14.3.1 is dated 2023-06-13T21:29:31Z, which is the time that a VM clock seems to start at.

I even tried setting the time server to a local ntp server with this packer template snippet:

packer {
  required_plugins {
    # see https://github.com/cirruslabs/packer-plugin-tart
    tart = {
      version = ">= 1.5.1"
      source  = "github.com/cirruslabs/tart"
    }
  }
}

# see https://github.com/cirruslabs/macos-image-templates/pkgs/container/macos-ventura-xcode
# see https://github.com/cirruslabs/macos-image-templates/blob/master/templates/xcode.pkr.hcl
# see https://github.com/cirruslabs/macos-image-templates/blob/master/templates/base.pkr.hcl
variable "base_image" {
  type    = string
  default = "ghcr.io/cirruslabs/macos-ventura-xcode:14.3.1"
}
...
source "tart-cli" "macos-ventura" {
  vm_base_name = var.base_image
  ...
}
...
build {
  sources = ["source.tart-cli.macos-ventura"]
  ...
  # use the internal time servers.
  provisioner "shell" {
    inline = [
      "systemsetup -setnetworktimeserver ntp.local.",
    ]
  }
  ...
}

But at the VM boot time, when logging in macOS, the setnetworktimeserver setting did not even seemed to be saved at all, because, the time server in the clone is reverted back to the default time.apple.com..

Please note that this seems related to https://github.com/cirruslabs/macos-image-templates/issues/4 which does not seem to address the problem.

So it seems there's a bug somewhere, not sure where. Is it in my packer template? tart itself? in the base macOS image?

[rgl]

Oh, I forgot to use sudo when calling systemsetup to set the time server!

I'm now realizing that systemsetup is a very odd command, it always returns 0 even when there are errors :-(

But, still, setting the time server seems like a workaround, IMHO, the VM should get the time from the host.

[fkorotkov]

https://github.com/cirruslabs/macos-image-templates/issues/4 issue was related to when we used Anka VMs in suspended state. In case of Tart VMs, they can boot very quickly and upon booting the clock should sync. At least when I run the macos-ventura-xcode:14.3.1 locally, time is accurate to the point of the timezone which is not possible to automatically pass from the host (see #373).

Do you have any firewall that can prevent Tart VMs from accessing time.apple.com upon the boot?

[rgl]

Yes, there is no access to the external NTP/time servers. After using sudo to use an internal time server, it worked.

But, I think the root problem is that the VM is not using the time from the host, it seems to be using the time of the last VM shutdown. This is not a time zone problem because the difference is not in the order of +- 24h, its a difference of months.

This last part was the only reason for me to keep this issue open. If that is not really possible to fix, feel free to close this issue.

[fkorotkov]

I guess this is responsibility of the integrator. Plus in normal scenarios when there is access to time servers this is no an issue.

Additionally, if you use Cirrus CLI for running your VMs then the CLI is actually syncing time from the host:

https://github.com/cirruslabs/cirrus-cli/blob/0ad7d8efee7ccacf6b2a6bfae70909fa4b347374/internal/executor/instance/persistentworker/remoteagent/timesync.go#L8-L10

You can probably do something similar in your Packer templates via timestamp() function or stick with your local ntp server.

[rgl]

For me, that is very odd place to do that. Hypervisors like KVM/QEMU normally provide a clock device that is synchronized with the host, in the macOS hypervisor that is not the case?

[fkorotkov]

Unfortunately there is no such support. We can only pass entropy device for random number generator.

[rgl]

Oh that is unfortunate. I now understand why we need to this from within the VM.

Thanks for the explanation!