VM time ahead by 5 hours

acebmxer

As title says VM time is ahead by 5 hours. I checked the host time via idrac (dell server) time is correct their. Via idrac I access the virtual console and verify xcp-ng host is using default ntp server info.

Other host at same location is esxi host and the vms on that host have the correct including the Windows Domain controller.

On the vm with incorrect time I see " Last successful time synchronization is 2/1/26 8:15:34 am( was correct 15 min ago) Time server local CMOS Clock. Time zone is set correctly.

Edit also note - VM was migrated from ESXI Windows 10 bios boot. Formigration i choose Windows 11 template.

When booting the vm I get this error:
Manually deleting the VTPM does not help. VM still boots but gives error.

vm.start
{
  "id": "146c5089-1e37-d3b4-83a3-8ba53a0ee2e6",
  "bypassMacAddressesCheck": false,
  "force": false
}
{
  "code": "NOT_IMPLEMENTED",
  "params": [
    "Booting BIOS VM with VTPMs attached"
  ],
  "call": {
    "duration": 3868,
    "method": "VM.start",
    "params": [
      "* session id *",
      "OpaqueRef:6373a25c-a4f8-9c57-f487-23d851a3a35e",
      false,
      false
    ]
  },
  "message": "NOT_IMPLEMENTED(Booting BIOS VM with VTPMs attached)",
  "name": "XapiError",
  "stack": "XapiError: NOT_IMPLEMENTED(Booting BIOS VM with VTPMs attached)
    at XapiError.wrap (file:///opt/xo/xo-builds/xen-orchestra-202601291557/packages/xen-api/_XapiError.mjs:16:12)
    at file:///opt/xo/xo-builds/xen-orchestra-202601291557/packages/xen-api/transports/json-rpc.mjs:38:21
    at runNextTicks (node:internal/process/task_queues:64:5)
    at processImmediate (node:internal/timers:472:9)
    at process.callbackTrampoline (node:internal/async_hooks:130:17)"
}

While shutding down the vm to add this note about VTPM, when vm booted back up time is now correct. Noted VM was rebooted and shutdown a few times from initial boot and for vm tools install.
Time is now synced with the domain controller.
Thoughts?

olivierlambert

It's a Microsoft thing, let's ask @dinhngtu our specialist

acebmxer

@olivierlambert

I am doing another fresh install of windows to check the time issue.

As for the VTPM issue. Initial boot up the vm gave the warring but booted. I attempted to mount the tools iso but it would not mount correctly. So i had to shutdown the vm. When i powered it back on. It would not power on after giving the error. I deleted the vtpm and the vm booted but again gave the error and the vtpm was added again.

I can open a support tunnel if needed. This is all testing before moving critical vms at this location.

acebmxer

test vm time was ok. I have started to remigrate over the same vm again this time making sure to select win10 for template. ETA is about 2hrs

acebmxer

vm boots with no issues after retying migration with Windows 10 template.

Maybe there can be checks put in place to not apply vtpm with bios is selected? Going forward will make sure to select the current os for the template not a newer version.

dinhngtu

@acebmxer Re time issues: Do you have Xen tools or any other sources of time sync? Suspending a VM and then later resuming it will cause the VM's time to not be updated. It'll have to rely on either NTP or the Xen tools daemon to get the correct time.

acebmxer

@dinhngtu

I think it just have been a bad migration or the Win 11 Template did other things to the windows 10 os. Since new test vm did not show the time issues, and a fresh migration of the vim with correct template selected did not have the issues either.

I dont know but maybe there is a way to put detect the correct VM template or make note. I didnt think using the win 11 template would have caused issues since using the "wrong" template on vm creation does not have the same effect.