XCP-ng Windows PV tools announcements

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

dinhngtu

@john.c The new XenPlus guest agent emits relevant warnings/errors in the Application event log whenever a failure happens somewhere in its communication with the hypervisor. This was not documented in the release, but it's much improved over the previous 9.1.200 guest agent. Right now events aren't assigned IDs yet (but you can filter by source)

yomeyo

I've updated from 9.1.200.0 to 9.2.350.0 on a Windows Server 2022 VM and encountered this during the update.

I clicked OK:

I clicked on Finish and after that on Yes to restart the VM.

Now, after the update, every time I log out a user session, I see an event by XenPlus being logged to the event log:

Category: XenPlus.Features.ClipboardFeature
EventId: 0

Failed to serve client 6

Exception: 
System.IO.EndOfStreamException: IO_EOF_ReadBeyondEOF
   at System.IO.Stream.<ReadAtLeastAsyncCore>d__48.MoveNext() + 0x1f2
--- End of stack trace from previous location ---
   at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1.StateMachineBox`1.System.Threading.Tasks.Sources.IValueTaskSource.GetResult(Int16) + 0x23
   at XenPlus.Features.ClipboardFeature.<ServeClientLoopAsync>d__26.MoveNext() + 0xb0d
--- End of stack trace from previous location ---
   at XenPlus.Features.ClipboardFeature.<ServeClientAsync>d__27.MoveNext() + 0x45d

dinhngtu

@yomeyo It's a client shutdown being misreported as a client error. I'll fix this in the next release.

The warning on upgrade should be harmless and you can simply close the application/click OK as you've done.

john.c

@dinhngtu When creating GPOs if you have an non-policy setting for all users in the settings area for the agent config. The policy based registry settings can go into “Software\Policies”, for the appropriate HKEY and keys.

In which case the policy based registry entries supersede the non-policy ones, when considering also the HKLM vs HKU and HKCU cascade.

Also a disabling of user configuration of the managed setting(s) along with display of a message like “At least some of these settings are managed by the organisation”.

clip

@dinhngtu Just wanted to pass along some feedback from trialing the newest version (9.2.350) -- in case it's helpful.

When comparing to the previous version (9.1.200 -- and earlier versions as well) on Windows 11 Pro VM (with latest updates), this new version results in noticeably slower VM restart and shutdown times (at least when monitored via xenadmin [on Windows] and xenadminqt [on Linux]).

... Just remembered I updated XCP-ng at the same time to the latest iteration, perhaps the slowdown may be related to that.

dinhngtu

@clip This often happens with Driver Verifier enabled, what do verifier /querysettings and verifier /query say?

clip

@dinhngtu Further trialing showed this issue is confined to one host and all its VMs (including Linux ones) - please consider this issue resolved and not related to Windows PV tools (incidentally, in this particular case there were no verified drivers enabled and no drivers currently verified on the Windows VMs). Apologies for mistaking this as a Windows PV tools issue.