@probain The canonical way is to check the product_id instead https://docs.ansible.com/projects/ansible/latest/collections/ansible/windows/win_package_module.html#parameter-product_id The ProductCode changes every time a new version of XCP-ng Windows PV tools is released, and you can get it from each release's MSI: [image: 1764477313181-617a6162-37ca-458d-8f3a-ca4c0102b18e-image.png]

Commenting for my future self. This works for CentOS Stream 10; # Install Extra Packages for Linux, where xe-guest-utilities-latest lives sudo yum install epel-release # Install sudo yum install xe-guest-utilities-latest # Start the Service on Boot sudo systemctl enable xe-linux-distribution # Start the Service Now sudo systemctl start xe-linux-distribution # Check the Service is Running sudo systemctl status xe-linux-distribution # Check it's installed sudo yum list installed xe-guest-utilities-latest I wasn't particularly committed to Rocky Linux 10, so thought I'd give the usual steps a run on a different similar OS using CentOS Stream 10. Works absolutely fine. As a comparison, when I run the above steps on Rocky Linux 10, it fails on the second step above when trying to install from yum, which appears to be due to this not being included in EPEL. sudo yum search xe-guest-utilities No matches found. Curious to understand if anyone knows why EPEL is different between CentOS Stream 10 VS Rocky Linux 10. Is this just some upstream thing that isn't perfectly aligned?

October release fixed it

@dani You mentioned in another thread that you're from Spain. ¿Me ayudas con la traducción al castellano para XCP-ng y XOA? Apúntate a https://translate.vates.tech/projects/xen-orchestra/xen-orchestra-6/es/

@olivierlambert Just to add another weird case of this situation I tell you my SAML-auth-adventures. I have just migrated a week ago from XOCE to XOA paid support this week and all the process was fine except the auth with the saml plugin. The commit I had in XOCE was [XO 5d92f - Master 3f604]. I compiled it the first week of this november so it wasn't very outdated. We use the MSEntraID SAML authentication and it was working fine in XOCE since at least one year ago. Mi process was like this: First, I installed XOA and imported the configuration from my old XOCE. Everything was fine and all was imported succesfully (backups, users, acls, etc.), including my plugin configurations. Note that I reused the https server certificate/private key and used the same IP and the same DNS (beacuse I turned off my XOCE before starting XOA). Everything was working fine except the saml auth plugin. I had the same "Internal server error" problem. I looked at the xo-server logs and the error was "invalid document signature" so, as Olivier said, we changed the configuration in MSEntraID to set the "Sign SAML response and assertion" on. Once we changed the configuration I thought the plugin would work again, but surprisingly not. If I try again SAML validation i still got the "Internal server error". When i checked again the xo-server logs I saw ahother exception, this time with the error "SAML assertion audience mismatch" and a reference to the issuer configuration of the plugin. The exact error I got from xo-server logs using "journalctl -u xo-server -f -n 50" was: "xoa xo-server[2370]: Error: SAML assertion audience mismatch. Expected: <id-of-MSEntraID-xo-validation> Received: spn:<id-of-MSEntraID-xo-validation>"I didn't understand this, because the configuration was exactly the same as I had in XOCE. In fact, I turned off XOA and turned on again XOCE just to test the plugin. The result was that in XOCE the plugin worked well. After many tries and some time of impostor syndrome we found the solution: I don't know why, but in XOCE compiled at the beginning of november you have to configure the issuer field of the plugin with the <id-of-MSEntraID-xo-validation> (8digit-4digit-4digit-4digit-12digit). Instead, in XOA deployed also this november, you have to set the issuer field to you XOA URL: https://<xo.company.net>/ I hope this will help, because it was a pain in the neck for us this week. BTW: @olivierlambert this "Internal server error" coming from an uncatched exception in the plugin was not very descriptive. Even a generic try-catch block just to show in the web interface the error would help... P.D.: I'm from Spain, so I do my best with my english P.D. 2: Great job with all the Vates virtualization stack! You are the best! Dani

you can uncheck the "Merge backups synchronously" in the advanced view of the backup job to have it run inside the backup job, thus making it visible (we are reworking the internal design for better observability, but there is a lot of job before)

@andriy.sultanov Thank you very much for working on this! I can test your proposed fix in our lab during next week. Best regards

Hi @k11maris, I think the situation you showed in your screenshot where both options are selected but are both greyed out should not happen. We will try to reproduce it on our side and fix it.

Hi! I'm not sure who to ping exactly for this question @pdonias or @Bastien-Nollet maybe?

@dinhngtu Thanks. We plan to migrate all Windows VMs from the Citrix tools down the road and only have a handful of VMs running these so far so will maybe hold off until the next version. Have been running the Linux rust tools for over a year with zero issues..

Thanks @Bastien-Nollet and @olivierlambert . I'm going to do some tests and write the results. Thank you so much.

@dnordmann the tunnel is closed. By the way the patch will be release tomorrow on latest, by the end of december on stable thank you all for your patience and your help identifying the root cause of this bug

@SethNY you could even enhance this VM_LIST = with TAGs on VM, so that you manage the selection directly in XOA

Yes, and then Xen will reduce the RAM if there's not enough available to boot a new VM (reducing down to dynamic min). Static means it can't be changed live, while dynamic can.