P2Vme Blog

Today I was working on an issue where a new XenDesktop Desktop Group was built and the time on all VMs provisioned was off by five hours. This led to the Desktop guest VMs not being able to talk on the domain and coming up as “Unregistered”.

Anyone that’s worked in this industry long enough knows that Windows is very sensitive to time, the time of a Windows machine cannot be off by more than five minutes.

From Microsoft Technet regarding time

Windows components and services depend on time synchronization. For example, the Kerberos V5 authentication protocol on a Windows Server 2003 family domain has a default time synchronization threshold of five minutes. Computers that are more than five minutes out of synchronization on the domain will fail to authenticate using the Kerberos protocol. This time value is also configurable, allowing for greater or lesser thresholds. Failure to authenticate using the Kerberos protocol can prevent logons and access to Web sites, file shares, printers, and other resources or services within a domain.

The Desktop Group was provisioned on XenServer using Provisioning Services So I checked all the usual culprits and found no issues so I had to dig further

• XenServer time configuration
• Domain Controller configuration
• Infoblox 

As this issue was only happening to newly provisioned desktops and no other server on the domain.A work-around was found that by changing the VM time for every VM while in standard mode after they were provisioned they would keep the correct time.

For those of you out there running Provisioning Services, you understand that Standard mode changes do not persist by reboot so this defies a bit of logic and led me to dig deeper down in the XenServer VM XenTools time sync.

XenServer has a parameter set per VM, timeoffset configured per VM

For Windows guests, time is initially driven from the control domain clock, and is updated during VM lifecycle operations such as suspend, reboot and so on. Citrix highly recommends running a reliable NTP service in the control domain and all Windows VMs.
So if you manually set a VM to be 2 hours ahead of the control domain (for example, using a time-zone offset within the VM), then it will persist. If you subsequently change the control domain time (either manually or if it is automatically corrected by NTP), the VM will shift accordingly but maintain the 2 hour offset. Note that changing the control domain time-zone does not affect VM time-zones or offset. It is only the hardware clock setting which is used by XenServer to synchronize the guests.
When performing suspend/resume operations or live relocation using XenMotion, it is important to have up-to-date XenServer Tools installed, as they notify the Windows kernel that a time synchronization is required after resuming (potentially on a different physical host).

To check the offset of the VM, you can run the following command from the XenServer command line.

• xe vm-list name-label=vmName params=name-label,platform

 Example Output

[root@xenhost01 ~]# xe vm-list name-label=vmTest-001 params=name-label,platform
name-label ( RW)    : vmTest-001
      platform (MRW): timeoffset: -18004; nx: false; acpi: true; apic: true; pae: true; viridian: true

[root@xenhost02 ~]# xe vm-list name-label=vmTest-002 params=name-label,platform
name-label ( RW)    : vmTest-002
      platform (MRW): timeoffset: -2; nx: false; acpi: true; apic: true; pae: true; viridian: true

Note the timeoffset of -18004 on vmTest-001 and -2 on vmTest-002. This value is listed in seconds so that is a five hour time difference (the difference we were seeing on boot of the VM). This is no coincidence.

Resolution

• In our case it was to build a new Template VM and ensure the timeoffset was set correctly
• You can also do this on a case by case basis per VM by running the following command and substituting vm-uuid for the VM that would like to update.
• xe-param-set platform:timeoffset=<value-in-seconds> uuid=<vm-uuid>