@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).
