@DustinB Indeed I will, but are the prices really that close? I was looking a few weeks ago with some replacements and spinning was still enough cheaper that it made a difference. I was looking for around 4tb enterprise class drives.

@rama said: @olivierlambert thank you. but is it possible to keep tracking all the CURD operation like we have in terraform. but currently MCP have only Read tasks. Like if some new interns in my lab don't know about this and in this agentic framework if he/she need a VM's, delete or update it can be done very quick. it will save many hours. I hope this will be available in future or if you wish to do tell me how far it is. The plugin MCP Server is read only by design to keep using it safe, to have an MCP for reading and another for writing is best practice. If you desire to have a separate MCP server for the writing actions, feel free to suggest that in the feedback portal. You can even develop your own MCP server, which makes calls to the write side of the XO REST API. https://modelcontextprotocol.io/

@semarie This pool is still on 8.2.1, we are trying to add this host in order upgrade with little to no downtime.

Here is the latest after installing 6.2.1 on Friday. [image: 1772418962131-0837739b-0d4e-4f27-ac1c-a51c297b3271-image.jpeg]

Hello @Austin.Payne, I wanted to share my experience. I had similar issues through multiple XO versions. However, after learning that health checks rely on the management port I did some more digging. TL;DR it was a network configuration, and not an XO or XCPNG problem. If you have a multi-nic setup and you have XO as a VM on your XCPNG host, I would recommend that whatever network you use for management is on the same NIC. Setup: XO is a VM on XCPNG Host (only one host in pool). Network setup: eth0 = 1GB NIC = Management interface for XCPNG host (192.168.0.0/24 network) eth1 = 10GB DAC = NIC for 192.168.0.0/24 network to pass through VMs (XO uses this NIC) eth1.200 = 10GB DAC = VLAN 200 on eth1 NIC for storage network (10.10.200.0/28). Both the XCPNG host and VMs (including XO VM) use this. IP setup: XCPNG host = 192.168.0.201 on eth0; 10.10.200.1 on eth1.200 XO VM = 192.168.0.202 on eth1; 10.10.200.2 on eth1.200 Remote NAS for backups = Different computer on 10.10.200.0/28 network In this setup, backups would always finish, but health checks would hang indefinitely. However, after changing the XCPNG host to use eth1 for the management interface instead of eth0, health checks starting passing flawlessly. I am not sure if the problem was having the XCPNG host connecting to the same network with two different NICs or if eth1 was the better NIC thus was more reliable during the health check (could also explain why backups would always succeed). It's also possible it was switch related. In this setup, eth0 was connected to a Cisco switch and eth1/eth1.200 was connected to a MIkroTIk switch. Again, not sure what actually solved it, but consolidating everything to a single NIC solved the issue for me (and physically unplugging eth0 after the eth1 consolidation). Hopefully sharing my experience helps solve this issue for you.

@kent you would have to rollback to early december 2025 XO/XOA (before the 10 of december) quite a long way I'm just waiting the devs to eventually fix it as we have other way to manage VDIs (API calls)

Version 1.4.0 is released: https://codeberg.org/NiXOA/system/releases/tag/v1.4.0 It includes significant changes and improvements, including: dedicated getting started section, migration to valkey, only needing to clone system, and helper scripts. the xen-orchestra-ce nixpkg now references the libvhdi nixpkg, and the core flake now references and pulls from the xen-orchestra-ce repo as an overlay. System (the user input flake) now uses the Core repo as an overlay, reducing the need to clone both locally AND allowing system to pull new updates and releases from core. XO, and libvhdi as needed. The next goal is: Make an xsconsole-like TUI Automate package updates for libvhdi and xen-orchestra-ce using CI/CD pipelines Submit libvhdi and xen-orchestra-ce as official nixpkgs

@benapetr said in New project - XenAdminQt - a cross-platform GNU/Linux, macOS, Windows native thick client: @Pilow I know them a little bit, I will have a look, but I am now working on another new cool thing! It's called xen_exporter: https://github.com/benapetr/xen_exporter It's a prometheus exporter that hooks directly to xen kernel via xenctrl library from dom0 and extract all low-level metrics from the host, allowing very detailed graphs with very low granularity with stuff I always missed in both XenOrchestra and XenAdmin: ... We have a similar project : https://github.com/xcp-ng/xcp-metrics, but unfortunately it's not used as of today (though it could get revived as Rust for Xen matures, i.e easier to build). There is also Xen Orchestra OpenMetrics support but it's not on XCP-ng itself.

That's a very good question, let me ask internally. Ping @pdonias he might know the answer

@vanny you can say you are working for Vinchin, I prefer when it's clearly told

That's very interesting, let me make sure @florent got this

I know it's actively worked as we speak (ACLv2). So I would say this year at least It's in our (soon published) roadmap in the "Next" section, just after the "now".

@DustyArmstrong The only GPU I've ever tried was nvidia quadro series, and that was probably under 8.2.

@TeddyAstie Thanks for that - I was going off of other old XCP hosts I have had running that did show IOMMU info there, so I figured it wasn't working on these particular machines. I also had the the Intel GPU working on those hosts, which further supported my theory. I do have a USB controller passed through to the same VM and that works perfectly, basically native functionality, but from the research I was doing it was suggested USB controllers are way less bothered about imperfect passthrough. I was able to find a ROM for my particular GPU, but I don't know what - if anything - I can do with it in XCP. I've found lots of info for QEMU and Proxmox, but I'm not sure they directly translate. If there's nothing I can do for the moment then I can live without the GPU, running decode on the CPU isn't really taxing it that much. Appreciate you looking into it.

@florent root@xo-server:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm root@xo-server:~# dpkg -l | grep gnutls ii libcurl3-gnutls:amd64 7.88.1-10+deb12u12 amd64 easy-to-use client-side URL transfer library (GnuTLS flavour) ii libgnutls30:amd64 3.7.9-2 amd64 GNU TLS library - main runtime library ii libsrt1.5-gnutls:amd64 1.5.1-1 amd64 Secure Reliable Transport UDP streaming library (GnuTLS flavour)

@bleader thanks for the tip. You see my knowledge in redhat based systems is almost non existant. Think I'm almost 99% debian and 1% ubuntu (and that not by choice) So I will take care of redeploying the script as soon as I upgrade, should be easily noticeable since monitoring will loose access and yell at me.

@florent Awesome, i have patched a second location's XOA and am not experiencing the issue anymore there either.

@olivierlambert said in Rust-based guest-tools... How are things going?: The thing is that it works very well and doesn't need fixes… I know, not usual right? It was so stable that we left it like that waiting for people coming for bugs and nothing happened… We'll cut a 1.0 in the next weeks/months. I have indeed seen the stability of it myself. But the lack of updates made me worry anyway. But I'm really looking forward to the promotion to 1.0 as well. Thanks!

@rniesen Do you mean occasional hangs? Yes, Server 2025 is known to hang if these options are not present.