@Tristis-Oris said: Since I'm the happy owner of this controller, if there's no urgent solution, then tell me which models are definitely compatible with 8.3? The Adaptec ASR-71605 was released in 2012, that's 14 years old. I'd use https://hcl.xenserver.com/search/?type=storagecontrollers&support_status=supported&page=1 to find compatible controllers if you need help. But yeah... 14 year old controller...

@Greg_E said: I'm guessing this might be having updates applied, and now I need new Xen Tools. I have a feeling tomorrow will be filled with updating the tools and checking things because I bet all my backups fail tonight. And I bet all fail after they try to start. Are you performing nightly healthy checks? Seems obsessive to need to check every system makes it to a login screen, but on the other hand, I understand. Just curious.

@julienXOvates said: Just discussed this with @nathanael-h; I would strongly recommend using the load balancer plugin in XO and create some VM-to-host affinity rules, so that your CP VMs are running on different hosts ! So when the RPU comes you would have minimum impact. Yeah the Load Balancer plugin is an option, though not in my plan. I could certainly get it by using XOCE for free though. I wonder if Host Affinity might work as well...

@dinhngtu Thanks for fixing the note. The IP loss did happen on 9.6.0. On the first boot after I set has-vendor-device=false, the guest still reported tools 9.6.0 build 19 (xenbus 9.1.13.23, xenvif 9.1.15.8, xennet 9.1.8.6), and both static IPs were already gone: the main NIC was on DHCP and the second NIC had a 169.254 address. XenClean and the 9.2.385 install came after that.

@poddingue Acctually my experience is that a VDI with CBT enabled can't have its VDI migrated at all. And XO does indeed catch that CBT is enabled. But it doesn't disable it -> migrate -> re-enable. @archw And if you'd like to migrate VDIs between SRs you'd most likely also have to delete existing snapshots as well (along with disabling CBT prior to migrating).

@willamcorlin Hello, The fix for CVE-2026-46243 has gone through the entire standard release process, which includes: Review by at least 2 developers. Unit testing within the package (if available). End-to-end testing in the CI (xcp-ng-tests). Several days of user testing. And since the release, we have received no feedback suggesting any potential regression. (This does not mean that the risk of a regression is zero.) If any issue arises, please do not hesitate to get back to us. Respectfully,

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

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

@poddingue thanks, In my case there is an update from Microsoft which destroy the RDP/Console. below is the link for it. I patched the fix and it's now working fine. Also I try to use proper template for windows based vms so that all the params gets in the guest by default. https://support.microsoft.com/en-us/servicing/os/windows-server/2026/09/kb5129235-windows-server-2025-update

@poddingue Hi, we have a ticket at Vates regarding this. (Ticket#7765809)

@bogdantomasciuc Glad to hear. I was hoping it was just something missed or miss typed. If you can replicate the issue let me know. Its possible i might have missed that little nuance or something.

Third update: It looks more and more that I had goofed something up in my testing. So please disregard everything in the post below. The driver does work to make our LPe37000/LPe38000 series FC-cards work. Which is nice. Thanks! ~~Good morning So I might've found an issue with this driver release. That I'm trying to troubleshoot and collect data on. We have two LUNs presented to our dev-pool (xcp-dev), running on R650xs. When I have attached one LUN to xcp-dev I can't see the other LUN. This works on our older R350s Removing the attached LUN, makes a LUN visible again. But now we're getting some strange behaviour. And looking into if it is misconfigured from the Dell Powerstore, or if it is on the host(s) itself.~~ Details: multipath is enabled Host on xcp-dev 98:00.0 Fibre Channel [0c04]: Emulex Corporation LPe37000/LPe38000 Series 32Gb/64Gb Fibre Channel Adapter [10df:f500] (rev 11) Subsystem: Emulex Corporation Device [10df:f522] Kernel driver in use: lpfc Kernel modules: lpfc14 98:00.1 Fibre Channel [0c04]: Emulex Corporation LPe37000/LPe38000 Series 32Gb/64Gb Fibre Channel Adapter [10df:f500] (rev 11) Subsystem: Emulex Corporation Device [10df:f522] Kernel driver in use: lpfc Kernel modules: lpfc14 Update: ~~After managing to revert my previous tests and forget the existing (wrong) LUN from xcp-dev. I can now confirm a problem. There are three LUNs. Let's call them 101, 102, 103 When I attach one LUN (103) to xcp-dev, I am no longer able to see the other LUNs. That means I can't add a second one. I am expecting to be able to see 102 available. However, on old-dev, that has two LUNs attached already (101 & 102). It can see 103 as expected.~~ host on old-dev 02:00.0 Fibre Channel [0c04]: Emulex Corporation LPe12000 Series 8Gb Fibre Channel Adapter [10df:f100] (rev 03) Subsystem: Emulex Corporation LPe12000 Series 8Gb Fibre Channel Adapter [10df:f100] Kernel driver in use: lpfc Kernel modules: lpfc 02:00.1 Fibre Channel [0c04]: Emulex Corporation LPe12000 Series 8Gb Fibre Channel Adapter [10df:f100] (rev 03) Subsystem: Emulex Corporation LPe12000 Series 8Gb Fibre Channel Adapter [10df:f100] Kernel driver in use: lpfc Kernel modules: lpfc Second Update: This might be unrelated. Seems that we're having weird behaviour with the LUNs in general. Please disregard the statement above for now

@jqueiroz said: Bom dia a todos, Estou com um problema em uma VM, ela está ligando/desligando sozinha, repetidamente. Não encontro nenhuma mensagem de erro explicando o motivo. Alguém pode me dar alguma dica sobre como solucionar isso? Uso o XCP-NG 8.0 em um cluster de dois servidores HP Proliant DL-360, com o HA-Lizard. Tudo vinha funcionando bem até alguns dias atrás, quando houve uma queda de energia no datacenter da localidade. Tenho o mesmo arranjo de VMs/servidores em mais seis localidades, nenhuma apresenta esse problema. Analisar esse comportamento instável do cluster é quase como prever resultados complexos, parecendo a análise de riscos que a malta faz ao dar palpites no https://mostbetbrasil.lat. Grato. Como o problema começou depois da queda de energia e só acontece nessa localidade, eu começaria verificando os logs do XCP-ng e do HA-Lizard para entender quem está disparando os reinícios. Pode ser alguma política de HA tentando recuperar a VM repetidamente, algum problema de armazenamento ou até inconsistência no estado do host após a interrupção. Também vale conferir o estado do pool e os logs do Xen Orchestra, se estiver usando. Se possível, desative temporariamente a automação de recuperação dessa VM, com cuidado para não comprometer a disponibilidade, e veja se ela continua reiniciando sozinha. Isso ajuda a isolar a causa.