Have you tried restarting the toolstack? To investigate further, you can review the host's log files https://docs.xcp-ng.org/troubleshooting/log-files/

Can't migrate an XO VM to any pool because of this error. You need to remove any CR copy that is halted to make migration work.

Hello! Just an idea but maybe the PCI link speed you are seeing is related to some sort of energy saving feature? Background: I have a Nvidia GPU in my PC and when there is no load the PCIe speed is lowered from PCIe 4.0 to 1.1 due to energy saving feature. [image: 1782894839133-fbd06c41-50cb-4334-9c98-92a3b6573389-image.jpeg] So yeah, I think @teddyastie 's idea is a good approach here. Try how your setup behaves during a workload.

I've installed the latest updates to all hosts, and restarted everything. I also have all xcp-ng logs going into loki now, so next time something happens I will see everything lol. [image: 1782860175138-156f9ac1-f1bb-47f3-a789-8551c8614805-image-resized.jpeg]

Thanks, I made the feedback to the XO team, this will be fixed ASAP.

@yllar I'm not sure, maybe it'll slip to July. But what I can say is that the ISO is currently being tested in our QA process. Brace yourself, it's coming soon

Meant to update this again last night - as a road map for those who might try similar at some point: This community's documentation led me to some relevant information on mouse/keyboard pass-through. Namely, if you want this to work you have to pass the entire PCI controller through to the guest(s), Won't work with motherboard devices. But I'm out of PCIe slots. What to do... Simple. Chuck the two serial adapters and install two dual USB 2.0 adapters in their places. Connect the keyboard/mouse to one of the ports and a 4/8/16 port USB to serial adapter to the other. Then pass the entire controller through. In this particular server (R810) I have 5 available PCIe slots. Two will be used for the video cards, one for a 4x NVMe to PCIe adapter (which is eventually where the VMs will reside) and the remaining two for the USB interfaces. This effectively gives me two discrete physical systems, a third available VM instance (say, for network management, monitoring or whatever) and the XOA instance. For application/radio control systems hypervisors (nested) I'll probably have 2ea Win11 and whatever flavor of Linux that supports the GT730 GPU on the system - each assigned the pass-through devices - but only two running at any given time. So no resource contention issues. As far as the displays: I have the main interface of the server connected via SIP to a 2160AS KVM. I'll take 2 more SIPs and use these as the keyboard/mouse inputs for the USB cards. Video...I use an HDMI active splitter on other systems in the network so I'll employ that here. One of the ports on the add-in GPUs goes to the splitter, one of the splitter outputs goes to the SIP via HDMI to VGA adapter and the other feeds the main ceiling mount monitor. The Primary display will be replicated to the KVM screen. Resolution isn't an issue as I have a video scaler inline with the KVM for just this scenario. The concept could be expanded. I'm looking at picking up a T630 and building 4 effective "systems" out of it, following the same principle. The 630 has 8 available PCIe slots. Will update when the next batch of hardware arrives - or I get the Linux side of things sorted. That's next.

@Tristis-Oris Hi, Can you upload your complete logs from one of these jobs, please? You can DM me if you prefer

@poddingue Thanks for the reply. I have been checking the source code of the Netbox plugin over the weekend and added the necessary code to enable the virtual disk sync. In Netbox itself, you do need to add the correct permission for it to work. Will do some more testing during the week, and create a pull-request once I'm satisfied with the result. Up to the Vates if they want to merge it into the main branch. Thank you for your reply!

@andibing said: I'm seeing this on XOA: xoa@xoa:~$ sudo xoa-updater --upgrade ✖ { message: 'missing string at offset 151' } xoa@xoa:~$ Unless the sun has got to me, I don't seen any other references to this error. And Gemini was confused too! Any thoughts? Can you please run “df -h” to start? If either / or /tmp/xoa-updater are low on space please increase disk space or run a clean up. The disk space on the VM and/or the SR may be too low, for the update to succeed. The XOA update metadata cache may have become corrupted and need to be cleared, before re-attempting the update. Checking the logs will help to determine if that’s the case.

@olivierlambert Thanks for being so transparent about this. I suspect just updating that error message should be helpful enough. I was really struggling yesterday as I couldn’t figure out why my test plan was failing. Your suggestions did indeed work. In my case just disabling HA briefly did the trick

For your storage question, it's fully explained in the doc: https://docs.xcp-ng.org/storage/#-how-to-modify-an-existing-sr-connection And yes, it's planned to get the complete error visible in XO, sadly, it's not "obvious" since the error message isn't returned by XAPI when you try to start but by another method we need to call after it fails ("assert can be started here" from the top of my head). Let me ping @julienXOvates

Well you both just made my Friday! I can follow directions after all!

Evening @pierrebrunet My bad. I am now on commit b440f and the issue persist. I have written you a message with the link to the file. Regards, Marc

@niko thanks, that would help a ton!

mid 2026: you can't add a ipv6 address via XOA (XOA5) because the gui lacs the field for the v6 gateway-address XOA6 lacks feature to configure ips of the host the configuration of ipv6 (static) vie the "gui" on the host seems not be implemented yet (or i am missing something critical) command line configuration inside dom0 of the host is afaik not supported ? Some point looks like minor issues. it would be great to "address" pun intendet that as well

@Danp said: Smart Reboot option found on the host's Advanced tab does what you are asking Very nice!