@julienXOvates said:

@acomav We will actually propose to change the date and time format in XO6 settings, so you would be able to choose between :

• YYYY-MM-DD
• MM/DD/YYYY
• DD/MM/YYYY
  and 12h or 24h time format.
  Hopefully in one of the next 3 months !
  I hope that will answer your need, otherwise let me know !

Thanks for putting this one the roadmap, for one of the next 3 months. That date order issue, has been bugging me as if you are rushed off your feet, may not remember that it’s the US date order.

Also fits in more with the rest of European software used, or configured for the European localisation.

@johnnezero said:

@john.c Thank you for all the great ideas, keep em' comming!

Your welcome. If your other plugin was vibe coded it may be worth doing the same for the other. If you’re still working on it!

@julienxovates In regards to the XO updates with the upcoming encrypted XO data store, by default (opt in for now). Is it ready for plugins like the one done by this author, and others in the future please?

@johnnezero Take care about the AI model, making changes to the tests, the default should be that the plugin source code itself is changed before tests. Tests can be changed with oversight from you, so that changes to tests don’t re-permit regressions.

@johnnezero said:

@john.c Yes, will do! Thanks again for all the input, it is greatly appreciated.
Happy Day

Also tell it to additionally avoid regressions, as another bad habit of AI models, is it fixes one or two things though at times undoes another fix or fixes made earlier. Tests need to be present that prevent this from happening, in a way that prevents the model from undoing fixes, causing regression issues.

Also another bad habit is it can generate overly complex code, in a fashion that’s hard for humans to comprehend and understand. This leads to review and maintenance issues down the line.

Finally make sure as part of the professional code quality, it’s done in a secure method.

@fohdeesha said:

@johnnezero if you copy/paste all those findings to a claude fable/opus or openAI Astra model, it's scarily good at fixing everything, just tell it to test test test

Not just that but also specify that you need to be professional grade code quality, so that it doesn’t bias itself towards the lower quality code, following it from its massive training dataset.

@afk said:

Hi everyone,

Some of you may already be aware of this but I learned the news this morning.

https://www.virtualizationhowto.com/2026/09/leaving-vmware-just-got-harder-after-broadcom-pulled-vddk-downloads/

Essentially, Broadcom has decided, without any announcement, to remove all download links (and even some documentation it seems) for VDDK.
This impacts all migration tools that use the VDDK for copying data of VM disks.

If you have any version of VDDK, please keep it somewhere safe and make backups.

I only have a x86-64 linux release from september 2025 that I used for testing V2V. Obviously, I can't share any link here but the release has the following sha256 hash:

79d215198f1b8fd1d240a16b27ac2543c521ae2afdc1876444c2acf8945d74ca VMware-vix-disklib-9.0.0.0.24742305.x86_64.tar.gz

Apparently, web archival links are also taken down.

@olivierlambert
With Broadcom removing public access to VDDK downloads, we now have users who either cannot obtain VDDK at all or whose existing VDDK installations (main + backup) have become corrupted.

This creates a real need for a fully open‑source fallback path inside V2V, one that still meets the performance requirements normally associated with VDDK.

The open‑source community has already demonstrated that VDDK‑level throughput is achievable without VMware’s proprietary stack. Several projects have shown that:

• Parallel NBD can saturate modern storage bandwidth when implemented correctly
• Highly multithreaded block pipelines can outperform single‑threaded VDDK transfers
• A throwaway Linux Proxy Copy VM can act as an efficient intermediary, reading blocks via NBD and streaming them directly to the destination hypervisor.

This approach avoids VDDK entirely, remains fully open source, and provides a reliable fallback for users who can no longer access VMware’s proprietary components.

Given the direction Broadcom is taking, having this fallback inside V2V would significantly improve resilience for XCP‑ng users and ensure long‑term independence from VMware licensing changes.

The Proxy Copy VM must be treated as an ephemeral orchestration component — automatically excluded from the migration set and destroyed once the transfer completes — ensuring it never interferes with HA, LB, or startup/shutdown sequencing.

This architecture also gives Vates a clean, open‑source answer to Broadcom’s decision to pull public VDDK access — ensuring V2V remains fully functional even if VMware continues removing or restricting proprietary components.

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