flakpyro

flakpyro

@stormi Installed on our 2 production pools, DR and remote sites, 46 hosts total ranging from Dell, Lenovo, HP, and Supermicro servers, no issues to report!

flakpyro

Installed on my usual selection of hosts. (A mixture of AMD and Intel hosts, SuperMicro, Asus, and Minisforum). No issues after a reboot, PCI Passthru, backups, etc continue to work smoothly. Also installed on a HP GL325 Gen 10 with no issues after reboot.

flakpyro

@gduperrey Updated my usual test hosts, (Minisforum and Supermicro X11) as well as an two sets of 2 host AMD pools (one pool of HP DL320 Gen10s and another of Asus Epyc servers of some sort, and lastly a Dell R360 without issue.

flakpyro

@gduperrey Installed on my usual round test hosts. No issues to report so far! With such a small change i wasn't expecting anything to go wrong!

flakpyro

Installed on my usual selection of hosts. (A mixture of AMD and Intel hosts, SuperMicro, Asus, and Minisforum). No issues after a reboot, PCI Passthru, backups, etc continue to work smoothly

flakpyro

One of our pools. (5 hosts, 6 NFS SRs) had this issue when we first deployed it. I engaged with support from Vates and they changed a setting that reduced the frequency of the SR.scan job from 30 seconds to every 2 mins instead. This totally fixed the issue for us going on a year and a half later.

I dug back in our documentation and found the command they gave us

    xe host-param-set other-config:auto-scan-interval=120 uuid=<Host UUID>

Where hosts UUID is your pool master.

flakpyro

@stormi Installed on my usual test hosts (Intel Minisforum MS-01, and Supermicro running a Xeon E-2336 CPU). Also installed onto a 2 host AMD epyc pool. Updates went smooth, backups continue to function as before.

3 windows 11 VMs had secure boot enabled. In XOA i clicked "Copy pool's default UEFI certificates to the VM" after the update was complete. The VMs continued to boot without issue after.

flakpyro

@gduperrey

installed on 2 test machines

Machine 1:
Intel Xeon E-2336
SuperMicro board.

Machine 2:
Minisforum MS-01
i9-13900H
32 GB Ram
Using Intel X710 onboard NIC

Both machines installed fine and all VMs came up without issue after. My one test backup job also seemed to run without any issues.

flakpyro

@gduperrey installed on 2 test machines

Machine 1:
Intel Xeon E-2336
SuperMicro board.

Machine 2:
Minisforum MS-01
i9-13900H
32 GB Ram
Using Intel X710 onboard NIC

Both machines installed fine and all VMs came up without issue after.

I ran a backup job after to test snapshot coalesce, no issues there.

flakpyro

@stormi Updated a test machine running only couple VMs. Everything installed fine and rebooted without issue.

Machine is:
Intel Xeon E-2336
SuperMicro board.
One VM happens to be windows based with an Nvidia GPU passed though to it running Blue Iris using the MSR fixed found elsewhere on these forums, fix continues to work with this version of Xen.

flakpyro

@jr-m4 I had this issue on one of the pools i tested on as well and was able to fix the issue by following the fix here:
https://xcp-ng.org/forum/topic/10603/sr_backend_failure_46-the-vdi-is-not-available-not-detached-cleanly/3

flakpyro

@rzr I was worried about this because of XAPI. Luckily i have a host thats not currently running any VMs so i tried it there first hoping it was a small enough change that i could get away with it. Good to know i could have just disabled NBD for now though!

flakpyro

@acebmxer I was able to run successfully one time after multiple failures. I don't think its consistently reliable. Interesting that disabling NBD helped though. I didn't try that before reverting.

flakpyro

@acebmxer

I was able to revert by running

 yum history list

Finding the transaction from todays updates then running

 yum history undo <id>

I did this on both pools, doing the slaves first then the master. (Reverse order of updating) and so far everything is back to normal.

flakpyro

Installed on my usual test hosts.

Backups seem to have major ussues for me, much less stable with these updates. On two different test pools i ran into a similar issue. These pools are different hardware, one pool uses CBT for backups, one does not.

Pool 1:
Started a backup after running the updates, 2 VMs in the job hung on first run requiring restarting XO and the hosts tool stack. When trying to clear the leftover snapshots one VM got stuck with "VBD.unplug_force", restarting the toolstack didn't help with this i had to reboot the entire host to remove it. Second attempt backups ran ok.

Third attempt, VM hung again, same story as above, had to reboot the whole host to clear the "VBD.unplug_force"

Pool 2:

Backup job completed however again two VMs got stuck at the end with "VBD.unplug_force" and "VDIs attached to Control Domain"
On one VM the backup showed "Error: operation timed out" despite it otherwise finishing.

Is there a way to revert these updates for now? They are test hosts but i do like backing up the test VMs on them.

flakpyro

Installed on my usual test hosts without any issues so far.

flakpyro

@dinhngtu We did initially run into this issue a number of years ago and were able to fix it by following this kb article at the time:
https://support.citrix.com/external/article?articleUrl=CTX692813-xenserver-potential-performance-issues-on-imported-windows-vms&language=en_US

Checking s few random migrated windows VMs and it appears these flags are still set as they should be.

flakpyro

@dinhngtu Thanks for clarifying. I can confirm our windows VMs that were migrated with V2V with "Other Install media" do show having this enabled.

I will deploy to my usual batch of test hosts and update this post with my results.

flakpyro

@gleh said:

Disable Viridian in the "Other install media" template by default. As a reminder, Windows VMs must use Windows templates.

Working on testing this update out however this change has me a bit concerned. Will existing Windows VMs using "Other install media" be affected by this? Or is this just for VMs created going forward? Back in 2024 when we migrated from VMware using V2V all Windows VMs we migrated were created with "Other Install Media" as I'm guessing that's just how the migration process worked at the time.

flakpyro

@poddingue This was fixed a number of weeks ago via a ticket. I believe @florent may know the exact fix.

flakpyro

@flakpyro