XCP-ng and XenServer share the same Xen heritage. Their Windows guest tools contain paravirtualised drivers and a management agent that improve storage, networking and communication between the hypervisor and the guest.

The guest tools can also participate in correcting the Windows clock after lifecycle events. This is not the same as using the host as the guest's normal NTP source.

XCP-ng, XenServer and Xen

XCP-ng is an open-source virtualisation platform based on the Xen hypervisor. XenServer is the commercial product from Cloud Software Group using the same underlying hypervisor family. Xen Orchestra is commonly used to manage XCP-ng environments.

The exact guest-tool packages and management interfaces differ, but the time design remains the same: the Windows guest should use its intended Windows source, while the hypervisor hosts must also be synchronised correctly.

Windows guest tools

XCP-ng recommends installing guest tools in every virtual machine. For Windows guests, the tools include paravirtualised drivers and a management agent.

The drivers improve storage and network performance, while the management agent allows the platform to obtain guest information and perform management operations.

Guest tools should be kept current, particularly where virtual machines are migrated, suspended or resumed. XenServer documentation states that current Windows tools notify the Windows kernel that time synchronisation is required after a resume or live migration.

Domain members

A domain-joined Windows guest should normally use the Active Directory hierarchy exactly as a physical domain member would.

w32tm /query /source
w32tm /query /status

The expected source is normally a domain controller, not the XCP-ng host.

The guest tools can remain installed for their normal management and performance functions. The aim is not to remove them, but to avoid treating host time as a replacement for the Windows domain hierarchy.

Domain controllers

Virtual domain controllers should follow the Active Directory time design. The forest root PDC Emulator should use its approved external peers, while the remaining domain controllers should use domain hierarchy synchronisation.

Do not point a virtual domain controller at the XCP-ng or XenServer host as its regular NTP source. Doing so makes the domain dependent on the hypervisor and introduces another source into the hierarchy.

The hosts should instead use the same reliable organisational time design as the rest of the infrastructure. This reduces the risk of a large correction during startup, resume or migration.

Standalone Windows guests

A standalone Windows guest should normally use Windows Time Service with a manual peer list.

w32tm /config /manualpeerlist:"0.uk.pool.ntp.org,0x8 1.uk.pool.ntp.org,0x8" /syncfromflags:manual /update

This keeps the source visible from within Windows and avoids changing the design when the VM moves between hosts.

Host time

Every host in an XCP-ng pool or XenServer resource pool must maintain accurate time.

The hosts should use the same approved time sources. Inconsistent host clocks can affect migration, event correlation, management services and guest correction after lifecycle operations.

Where an internal time service exists, publish it through a stable DNS name and configure every pool member consistently.

Suspend, resume and live migration

A suspended VM may resume with a clock that is behind the current time. A live migration also moves the guest between hosts whose clocks must agree closely enough for the operation to remain predictable.

Current XenServer documentation recommends up-to-date Windows guest tools because they notify the Windows kernel that a time correction is required after resume or migration.

After either event, verify Windows Time Service rather than assuming that the correction completed successfully:

w32tm /query /source
w32tm /query /status
w32tm /resync /rediscover

Snapshots and restores

Restoring an older snapshot can return the guest to an earlier system time. This can affect Kerberos, certificates, scheduled tasks and application data.

After restoring a Windows VM, check the clock before returning it to service. A large jump should be understood rather than dismissed simply because the displayed time eventually looks correct.

Xen Orchestra

Xen Orchestra provides management, backup, migration and restore functions for XCP-ng. It does not replace Windows Time Service inside the guest.

Operations performed through Xen Orchestra can still trigger the same suspend, resume, migration and restore scenarios described above, so time verification should form part of the operational procedure.

Checking Windows

Use the normal Windows Time commands inside the guest:

w32tm /query /source
w32tm /query /status
w32tm /query /configuration

For domain members, the configuration should normally show NT5DS. For standalone guests using manual peers, it should normally show NTP.

Common mistakes

  • Pointing a virtual domain controller directly at the hypervisor host.
  • Assuming guest tools replace Windows Time Service.
  • Running different time configurations on hosts in the same pool.
  • Using old guest tools during migration or resume operations.
  • Restoring a snapshot without checking the Windows clock afterwards.
  • Checking only the displayed time rather than the selected Windows source.
  • Ignoring host time because guest Windows synchronisation appears to work.

XCP-ng, XenServer and Xen documentation

Related information