XCP-ng Windows PV tools announcements

Greg_E

Let me ask a question... Since the ability to set IP has been given in xe commands, will we be getting this ability through XO in the future? That would be really nice and would also help prevent shifting IP address when the driver updates.

Also what about NTP timing, if it is joined to a windows domain, will it still work using the domain controller as the time reference? I assume yes, but worth asking.

I normally have my hosts sync to GPS ntp server, the AD guests also sync to same ntp server, and all clients and member servers sync to AD (physical or virtual).

dinhngtu

@Greg_E NTP sync assist will work with any W32Time time sources, AD or external.

clip

@dinhngtu Thank you for the nice update. Just wondering, is it/will it be possible to disable the tray icon somehow (if an additional icon in the tray is not desired)? Even a persistent reg entry would be fine if too much hassle to add option to installer.

dinhngtu

@clip Just right-click the icon and select Hide, which will stick across reboots for you. You can also set this via Registry (using GP preference if you wish):

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\XCP-ng\XenPlus]
"ShowTrayIcon"=dword:00000000

clip

@dinhngtu Fantastic - thank you for thinking of and including that!

yomeyo

@dinhngtu Thank you, is it possible to set globally for all (new and existing) users when unable to use GPP?

dinhngtu

@yomeyo For now, there's no easy way to set for everyone without GPP. You can modify the setting for existing users via HKEY_USERS and future users by editing the C:\Users\Default\NTUSER.DAT hive.

john.c

@dinhngtu said:

@yomeyo For now, there's no easy way to set for everyone without GPP. You can modify the setting for existing users via HKEY_USERS and future users by editing the C:\Users\Default\NTUSER.DAT hive.

@dinhngtu Thanks for pointing out the ShowTrayIcon key under HKCU\SOFTWARE\XCP-ng\XenPlus.

Since a full Group Policy Administrative Template (ADMX/ADML) option isn't available right now to natively enforce this across fleets of VMs, modifying individual user profiles or loading NTUSER.DAT can be a bit fragile for automated deployments. As a cleaner stopgap, could we implement a cascading fallback check directly inside the Xen Guest Agent binary?

The logic would look like this when the agent checks whether to draw the icon:

Check HKLM (System-Wide Enforced Policy):

HKLM\SOFTWARE\XCP-ng\XenPlus -> "ShowTrayIcon"

If this key exists (e.g., set to 0), the agent respects it globally for all users and ignores everything else. Fallback to HKCU (Per-User Choice).

If the HKLM key is absent, the agent falls back to the existing user-level path:

HKCU\SOFTWARE\XCP-ng\XenPlus -> "ShowTrayIcon"

If this path is also absent, it defaults to showing the icon (1). Adding this hierarchical lookup is usually just a few extra lines of code in the agent's initialisation routine. It completely removes the need for sysadmins to hack the default profile template, making it incredibly easy to hide the icon universally via a single standard command (like reg add HKLM...) during an automated deployment script or MDM push. Let me know if that's something feasible to roll into a minor update for the Guest Agent!

Implementing this will also lay the foundation groundwork for a later group policy enforcement, of this setting.

@yomeyo I’ve requested an addition to the Windows PV tools which would make a good stop gap, until they can add group policy support.

john.c

@dinhngtu Along with my above request, can we please have the option of an integration with the Windows Event Log?

Having this integration would drastically help with managing fleets of Windows or Windows Server-based VMs, as managing and monitoring flat log files across dozens of machines is very difficult. If the guest agent could log its status, version handshakes, and errors directly to a dedicated Event Log source, sysadmins could easily ingest those flags using standard centralized monitoring tools.

dinhngtu

@john.c I'll consider adding relevant GPOs for this. There's no real complexity difference compared to normal Registry settings.

As for event logs, what information do you need? The various guest agents already report via Event Log exclusively.

john.c

@dinhngtu said:

@john.c I'll consider adding relevant GPOs for this. There's no real complexity difference compared to normal Registry settings.

As for event logs, what information do you need? The various guest agents already report via Event Log exclusively.

@dinhngtu That is fantastic news regarding the GPOs—having native administrative template support will be a huge win for enterprise deployments!

Regarding the Event Logs, my apologies for the ambiguity; I am aware the agents use Event Logs internally. The issue from a fleet management perspective is that when everything is running normally, the logs are quiet, but when a breakdown happens (like a VM losing its IP reporting, or an auto-update breaking xenflt), finding why it failed from a central monitoring system is difficult.

To make the Event Logs highly actionable for SIEMs, monitoring agents, and automated alerting, having explicit Event IDs for the following critical lifecycle and failure states would be incredibly useful:

Management Lifecycle & Heartbeats

Service Lifecycle: Distinct Event IDs for a clean initialisation/handshake with the hypervisor vs. an unexpected service termination.
IP/Network Metrics Reporting: An error or warning Event ID raised if the agent fails to bind to the guest network stack or fails to transmit the IP metrics to Xen Orchestra after a specific timeout window.

Backup & VSS Operations

Quiesced Snapshots: Dedicated Event IDs tracking when a VSS / quiesced snapshot request is received from the host, whether it succeeded, or a specific error ID if it times out or fails (which often causes backup failures on the XO side).

Driver & Filtering Health

UpperFilters Validation: A warning or error Event ID if the agent detects that its driver filters (like XENFLT) are missing from the registry or have been overwritten by a Windows Update cycle.

Upgrade & Missing Tool States

“Installed but Inactive" Detection: An alert Event ID if the agent service is running but cannot detect active underlying PV drivers. This is critical for catching scenarios where major Windows or Windows Server feature updates silently strip out driver components without running a proper uninstaller, leaving sysadmins caught flat-footed with a broken stack.

Providing explicit, documented Event IDs for these states would allow sysadmins to build standard Windows Scheduled Tasks or monitoring rules (e.g., automatically restarting the Xen Guest Agent service the moment a specific "Failed to report metrics" Event ID is caught).