One thing that I need to sort out - how can I ensure that I'm able to keep quorum at all times between my control planes? During a RPU, I need to have at least 2 non-paused CP VMs running or else the environment goes belly up. The system does seem very sensitive to those kinds of shifts, so anyone looking to deploy this, be mindful of RPU's. Maybe manually move 1 CP off of Host A to Host B, patch Host A, then move the CP back to Host A afterwards...

@poddingue Thank you!

@ma_ron said: Hi, Xen Orchestra, Community 51bb8 - back up logs and statuses are missing in the GUI. backups are done as seen exist available at the restore page. what can be the issue? Hello @ma_ron - That commit is 30 commits behind the current master commit. I suggest updating and trying again.

@LucienLassalle said: @Rod-G Hello, We are indeed aware of this vulnerability on the Kernel. But I still thank you for this message, it shows that the community is attentive to the subject of safety on our products. I also fixed the PoC, and I managed to reproduce the flaw. I also took the opportunity to start making a fix. You highlighted it, but this security flaw is mitigated by respecting our best practices as well as the fact that we are a hypervisor which must keep restricted access. For vulnerabilities like CopyFail, DirtyFrag, Fragnesia, we have just released the fix. The blog post is here: https://xcp-ng.org/blog/shell shockers/2026/06/02/june-2026-updates-1-for-xcp-ng-8-3-lts/ This being similar, there is a good chance that we will fix it and give the same severity. I would also like to anticipate the question of why a fix has not already been included in the security update released today. Our procedure aims for security but also stability, we pass a CI to avoid regressions, as well as a user testing period. With a deadline of less than a day, this would not have been possible. Just a quick general reminder, but if you find a security flaw and want to report it to us, the best thing to do is to contact our email: security [at] this domain name. I hope I was able to give you the most complete answer, don't hesitate if anything is missing. Respectfully, Thanks to you and the security team for working on this fix. Has the patched XCP-ng 8.3 kernel been tested with SMB-based storage repositories to confirm there are no regressions in storage connectivity or pool operations? It would be helpful to hear about any compatibility results before deploying the fix across multiple hosts.

@JamesG, I'm the one who marked it solved, so here's what I meant. What Teddy showed in https://xcp-ng.org/forum/post/109066 is that there's one thing to do on the XCP-ng side for the B50: turn HVM PIRQ off for that VM (xe vm-param-set uuid=<vm-uuid> platform:hvm-pirq=false, then reboot the VM), as described on the docs page he linked: https://docs.xcp-ng.org/troubleshooting/common-problems/#pci-passthrough-error-unsupported-msi-delivery-mode-7. With that, his benchmark came out normal for the card, and the Gen1 x1 you see inside the guest is something QEMU makes up, not the real link (his earlier post: https://xcp-ng.org/forum/post/106479). It doesn't mean every problem is on the guest side though: @pandusen tried the same setting (https://xcp-ng.org/forum/post/109084) and still had driver crashes on headless distros, and I don't know why. If you try it on your B50 and post what you see, that would help tell the two cases apart.

Glad it's working, and thanks for posting the script, the next NUT user will want it (I hope I'll be able to experiment with NUT in the coming weeks, so I could very well be "the next NUT user"). I tried the PBD part on a lab host running 8.3: xe pbd-list never prints a storage-type line, so that grep finds nothing and step 2 quietly unplugs no PBDs. The 2>/dev/null hides it, and --force isn't an option pbd-unplug knows about. My wild guess is that ejecting the CDs is what fixed it for you. If you want the unplug to really happen, going through the SR type works on my side, though I only tested it against an ISO SR, not SMB: H=$(xe host-list hostname=$(hostname) --minimal) for t in nfs smb iso lvmoiscsi; do for sr in $(xe sr-list type=$t --minimal | tr , ' '); do for pbd in $(xe pbd-list sr-uuid=$sr host-uuid=$H currently-attached=true --minimal | tr , ' '); do xe pbd-unplug uuid=$pbd done done done Block iSCSI SRs show up as lvmoiscsi, which is why it's not iscsi in the list. @Forza's point about hard mounts may still bite if the share is already gone when the unplug runs; I don't know enough about the SMB side to say.

@dknight-bg the Feeder post you linked asks for two things: sending audit events to syslog, which is what this PR does, and recording successful logins, which as far as I can tell the PR doesn't touch. If others reading this need either one, a vote on https://feedback.vates.tech/posts/88/audit-log-forward-events-to-remote-syslog-record-successful-logins is the easiest way to show it. The PR is still waiting for a reviewer, as far as I can see.