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

@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:

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

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

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

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

@olivierlambert said:

@john.c I really liked your "Jean C." signature before your edit You should keep it

I learned a bit of French in 6th form college many years ago now, as part of learning your culture. As part of a Skillpower course unit assignment. As part of this course during Sept 2001 to Summer 2006 went on an academic day trip visit to Boulogne, France.

But it was to a level that was useful for when going on holidays, so wasn’t very fluent.

@jeremie1977 said:

Bonjour,
Nous sommes en plein POC de Vates et je test le build de nos images RHEL avec Packer (d'ailleurs un grand merci à @bvivi57 et @ataxyanetwork pour les tutos et exemples qui m'ont fait gagner un temps précieux ^^ ).

J'ai remarqué que le paramètre "cd_files" ne permettait pas de monter le kickstart au boot
Le provider expose cd_files, mais le contenu n'est pas visible par l'installeur (ou n'est pas attaché à la VM...je n'ai pas sût identifier).
J'ai même tenté avec "floppy_files"...idem.
Est-ce normal ? Voulu ?

Du coup, dans des environnements sans DHCP pendant l'installation, cela empêche l'utilisation d'un kickstart embarqué et oblige à mettre en place une IP via la "boot_command" avec une configuration réseau statique (ce qui oblige a multiplié les builds si plusieurs environnements/site)
Rien de dramatique en soit mais sur les provider Packer Vmware et Nutanix que nous utilisons par ex, cd_files nous permet de couvrir les environnements isolés (air-gapped) et/ou sans DHCP et simplifie grandement les builds automatisés en rendant le code le plus idempotent possible.

L'intérêt est multiple :
Environnements air-gapped : aucun serveur HTTP nécessaire.
Moins de dépendances : le build est autonome.
Compatibilité avec les autres builders Packer (VMware, Nutanix, QEMU...), où nous utilisons cette fonctionnalité pour nos Builds
Sécurité : le kickstart n'est pas exposé sur le réseau, même temporairement.

Si la raison pour laquelle le fichier Kickstart ne peut pas être connecté en réseau ou autrement accessible, c'est parce qu'il contient des secrets. Cela peut valoir la peine de regarder et de vérifier le logiciel de service de détenteur sécurisé secret OpenBao (https://openbao.org/). Qui est un fork public open source de Hashicorp Vault, avant l'entrée en vigueur de la licence BUSL dans les versions ultérieures de Vault. Un autre conseil utile est de combiner l'isolation du masque de sous-réseau avec l'isolation basée sur le VLAN.

Quoi qu'il en soit, saviez-vous qu'une instance de Cockpit, exécutant Cockpit Image Builder peut être utilisée comme Packer, pour créer des images "dorées" de VM via OSBuild ?

Quoi qu'il en soit, bonjour et bienvenue dans la communauté Vates VMS, j'espère que vous la trouverez utile, épanouissante, accueillante et/ou amusante.

Sincèrement,

Jean C.

@TrapoSAMA said:

@john.c

I have this iso but how to know what is de package?

Thx

It’s going to be an msi installer package or on the guest tools iso, which is on the XCP-ng or Xen Server your running likely in Local Storage SR or Shared Storage SR (if moved). Named the same as the file linked to above, likely.

Anyway did you know that the UEFI SecureBoot certificates (at least one of them from 2011) issued by Microsoft are expiring fully during October 2026. Around that time likely at sometime after then those certificates will be placed into dbx. This means the Windows Server 2012 R2 if operating as a UEFI SecureBoot VM, will if restarted (or reboot following a crash), fail to boot.

So your client will go from having a working app that they can use, but not upgrade at the moment to one which won’t work and can’t be used! They really need to upgrade or migrate from Windows to Linux (released during 2025 or 2026) along with the app if needed. Alternatively upgrade to Windows Server 2022 or 2025 and the app!

@TrapoSAMA said:

@john.c

Oh yes!! but client have still working app and cant upgrade in this moment!

An instance of that agent maybe held in the contents of one of the XenServer installation media, with a compatible old enough version of the agent compared to current. Though running such old versions, may mean you end up running vulnerable versions of any drivers needed.

Plus they also have the situation where they can’t, benefit from major improvements. For one thing the highly performing and memory safe agents.

7.2.x guest agent can be found here http://downloadns.citrix.com.edgesuite.net/14644/managementagentx64.msi

8.x guest agent is in the 8.2.x Xen Server media, so if you have a copy of the ISO, or on an optical disk then it can be found there!

@TrapoSAMA said:

@john.c

Hello! in this moment i'm working with XCP 8.3 in a DL360G7. Is running good, but some systems are legacy like 2008R2 o 2012R2 and cant migrate for now to new versions. Then i need xentools compatible, but i dont find any alternative download site.

or xcp tools work fine with this old windows ? i dont test tools in this moment for many reason

Thx

Unfortunately not for anything older than Windows Server 2016 and Windows 10. However Windows Server 2008 R2 and Windows Server 2012 R2, need the Xen Tools, but are also EOL operating systems. Additional support is completely gone for Windows Server 2008 R2 from Microsoft, still available for now for Windows Server 2012 R2, however also disappears during October 2026.

Your legacy systems are in a potential state of increasing vulnerability and/or security risk. Someway of upgrading or migrating them needs to be found.

@TrapoSAMA said:

Hi Teddy,

I was referring to version 8.2 specifically Citrix and its patches.

However, having the various versions of XenTools for some older Windows systems would also be useful. Would that be possible?

thx

Are there any reason your still on Xen Server 8.2 as it went EOL during last year, and no longer receives any updates? It may be time to upgrade to a newer version of that product, or better yet migrate to XCP-ng version 8.3.0 LTS. Which is under current support and will be that way until 2028 unless obtained with ELTS for when it goes EOL!

If you migrate to XCP-ng 8.3.0 LTS you can also switch the agents, to the open source rust based agents which do the same job.

@kagbasi-wgsdac said:

@poddingue Bug report filed as requested — https://github.com/xcp-ng/xcp/issues/825 — and tagging @Team-Storage per your suggestion.

Full evidence bundle is attached to the issue (versions, sweep output, vhd-util vs xe comparison, SMlog). Summary of what I found:

One correction to the mechanism, and I think it matters. The recap describes is-a-snapshot being flipped to true. On my system that isn't what's happening — is-a-snapshot is false on every affected VDI. The field being wrongly written is snapshot-of, which is getting populated on base disks that aren't snapshots at all. XO's disappearing-disks symptom is consistent with either (it filters on a non-empty snapshot-of), but if the storage team is hunting for a bad is-a-snapshot write, that may be the wrong field. Every affected VDI here looks like:

is-a-snapshot: false      <-- correct
snapshot-of:   <populated with an unrelated VDI's UUID>   <-- wrong

A VDI that is a snapshot of itself. The clearest single artifact:

uuid:          806f7f42-083f-4a40-b3f1-0700d00bab5a
name-label:    WinSrv2022SHB_Disk1_Data
is-a-snapshot: false
snapshot-of:   806f7f42-083f-4a40-b3f1-0700d00bab5a   <-- itself
snapshot-time: 20260709T11:19:15Z
sm-config:     vhd-parent: c86e3247-...   <-- bears no relation to the snapshot-of value

No valid code path produces snapshot-of = self. Whatever writes this field isn't validating the target.

It's still actively corrupting new VDIs — this is not just legacy damage. That self-referential VDI was created 2026-07-09, a week after my patch + reboot. Sweeps 9 days apart went from ~180 → 191 affected VDIs on one SR, and a fourth anchor UUID appeared that didn't exist in the first sweep. Newly created VHDs keep landing in the affected set. So "stop it happening again" is the urgent half of the two-part fix, at least in my case.

The bogus targets cluster onto a tiny anchor set, and the anchors point at each other:

Count	Anchor
97	937c3945 (→ a893fdb4)
50	a893fdb4 (→ ea150883)
37	ea150883
7	806f7f42 (→ itself, new since Jul 9)

That looks less like corrupted lineage and more like the field being filled from an incorrect/uninitialised source.

On-disk VHDs are completely healthy. vhd-util check says valid, parent locators are consistent, GC reports no work. The two VDIs the DB calls parent/child are, on disk, siblings under a common parent. The corruption is purely in the XAPI database — which is good news for recoverability.

The VDI_IN_USE is not a real lock. current-operations is empty, xe task-list is empty, no tapdisk holds it. VM.start fails because it's walking a snapshot relationship that doesn't exist on disk. Reproduces from xe on the pool master with XO entirely out of the path — which is why I filed against xcp-ng/xcp rather than the XO tracker.

Versions: XCP-ng 8.3.0, xapi 26.1.11 (xapi-core-26.1.11-1.2), sm-3.2.12-17.9, sm-fairlock-3.2.12-17.9, blktap 3.55.5-9.1, build 20260618.

I have not attempted to bulk-clear the fields — on-disk data is intact and I'd rather not do a mass write against the XAPI DB on a live SR without guidance. Backing store snapshotted as a safety net.

Happy to run whatever diagnostics would help. And +1 to the hand-grenade feeling — the affected set growing on its own is the part that worries me.

Has this issue been validated on a storage server built around Debian 13, LVM and ext4 or just TrueNAS when connected to XCP-ng version 8.3.0. As part of the XAPI DB corruption. Can anyone answer this please or give a clue?

@pdonias @julienxovates I’ve made an issue and PR to update the documentation so it’s in sync with the current status of XCP-ng release version 8.3.0. Namely that it’s now a Long Term Support (LTS) release following being a semi rolling or standard release with new features being added.

https://github.com/vatesfr/xen-orchestra/issues/10091

@dvdwx said:

Hi
Anyone already tried to review why Users with User permission cannot have the topology menu to edit on their Self-Service resource page? the have admin permission on their self service resource set but cannot edit this setting:


If i log with and full admin account on Xen Orchestra it can be edited:

We are using an HA Pool with 2 hosts to LAB for our NOC/SOC team.

I already tried to create an ACL with user/tag/group with advanced permission but it release a full permission on the pool and it cannot be delivered to the team.

if anyone know a workaround to fix it.. I appreciate that.

As RBAC ACL is implemented for Xen Orchestra 6 you’ll likely find this more possible than currently on Xen Orchestra 5.

Is there anything mentioned in the motherboard or service manuals, about where if one PCIe slot is occupied another is running at reduced speed when occupied?

Something like this is in the manual for a Gigabyte B450 Aorus Elite (Rev 1.0) motherboard, for example. Can be in yours, somewhere written on one of its pages.

@andibing said:

I'm seeing this on XOA:

xoa@xoa:~$ sudo xoa-updater --upgrade
✖ { message: 'missing string at offset 151' }
xoa@xoa:~$

Unless the sun has got to me, I don't seen any other references to this error. And Gemini was confused too!

Any thoughts?

Can you please run “df -h” to start? If either / or /tmp/xoa-updater are low on space please increase disk space or run a clean up. The disk space on the VM and/or the SR may be too low, for the update to succeed.

The XOA update metadata cache may have become corrupted and need to be cleared, before re-attempting the update. Checking the logs will help to determine if that’s the case.

@JamesG said:

@anglerfish27 Supermicro H12SSL-i

I've dabbled with some PCIe settings, but I'm not really getting anywhere.

Here's a link to the manual:

https://www.supermicro.com/manuals/motherboard/EPYC7000/MNL-2314.pdf

Thanks!

Enable the SVM option will initialise the virtualisation settings automatically. As well as the SR-IOV settings, there’s going to other things need doing in XOA, to configure the necessary settings so that GPU can be passed through to the VM.

Those without Autostart enabled will after host restart, if not migrated, be in a shutdown state requiring manual startup again.

@olivierlambert said:

I'm not sure it's a great idea, because even 64 hosts is huge in terms of VMs and fallout if you have a problem on your pool DB. Even if you drastically improve the current mechanism, the impact of a problem pool wide is far bigger with 64 hosts than 24 for example.

It's more than purely tech, it's also a tech design/choice.

We can stick with the 64 hosts per pool, was just wondering how far it could stretch!