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.

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

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!

@Pilow pretty much

@olivierlambert said: I'm not sure it's a great idea, because even 64 hosts is huge in terms of VMs and fallout if you have a problem on your pool DB. Even if you drastically improve the current mechanism, the impact of a problem pool wide is far bigger with 64 hosts than 24 for example. It's more than purely tech, it's also a tech design/choice. Exactly, the failure domain just grows exponentially when going beyond a certain collective pool size. I was doing some more research and I found a few possible choices that Tesco may have moved too, but don't want to detract from this forum here.

@AlexanderK you could try to install perl-interpreter manually maybe? I happened to have a test host at hand that hasn't been updated since december, and the yum update went fine, perl interpreter was not installed before and yum update did install it on its own as a depency for openssl 3. Maybe others will have ideas as to why this would happen in your case.

@tuxen Doing some research, it doesn't look like the Xeon's I have are affected. But I'm willing to try the next time I need to reboot. Will report back after that.

Hello, Thanks for all !

@laszlobortel Hehe yeah, those are pretty old kernels. I'd say there's a good chance kernel upgrades will go a long way to alleviating the CPU hangs. I can't say it's exclusively a problem with lvmohba storage, that's just what we use because of our previous VMware infrastructure was block storage over fiber channel. We knew a physical infra overhaul wasn't in the cards for us for this migration so we stayed with our existing storage system. This bug bit us half way through the migration until we figured out upgrading the kernel generally fixed it.

@psafont Thanks for the quick response and clarification. I appreciate you opening a work item for this. Looking forward to seeing this improvement in a future release.

For people running XCP-ng, wanting to use NUT client to power down gracefully during longer power outages, it could be interesting to note that Unifi now has two very affordable UPS models that feature a built in NUT server. So no need to run your own NUT server.