Categories

  • All news regarding Xen and XCP-ng ecosystem

    146 Topics
    5k Posts
    J
    @herhin2017 said: @john.c Your absolute wright, i do my best and train about 25 young engineers per year on linux (we use debian). I also see more and more startups or small companies building their infrastructure on linux. Best greetings from austria It may be worth getting in line and noting the mention of EFI based servers for official Vates support with XCP-ng version 9.0 and above, in government reports. That way when the school’s hardware is refreshed it can be ensured that your provided with EFI capable servers, in time for XCP-ng version 8.3 EOL. I personally are already ready for XCP-ng version 9.0 due to my servers being Dell PowerEdge R620 for XCP-ng hosts. Along with Debian version 13.6 on the VMs. While using a Dell Precision 3590 to manage those systems. The “wright” makes your above now sound like a wheel wright, and its profession instead of “right” in for when correct or agreeing with someone or something.

  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    S
    Yes it works Thank you very much, great job Tested on Ryzen 9 9950X / AMD Raphael iGPU Tested the new experimental iGPU passthrough packages. - CPU: AMD Ryzen 9 9950X - iGPU: AMD Raphael (1002:13c0) - XCP-ng: 8.3 - Guest: Bazzite AMD - VBIOS: extracted from the ACPI VFCT and supplied as /root/vbios.bin - iGPU passthrough: working - AMD amdgpu driver: working - Physical HDMI output: working - Bazzite desktop displayed successfully on the physical HDMI port. Ubuntu 24.04.2 was able to initialize the GPU and Vulkan/RADV detected the Raphael iGPU, but the HDMI output went black when the graphical desktop started. Bazzite worked and provided a stable display output. So on my Ryzen 9 9950X, the experimental packages appear to successfully enable Raphael iGPU passthrough and physical HDMI output.

  • All Xen Orchestra related questions/reports

    3k Topics
    29k Posts
    acebmxerA
    @bogdantomasciuc Thanks for trying it! This one comes from upstream Xen Orchestra, not the installer. A change in XO's connection library (around 2026-09-09) left servers set to connect through an HTTPS proxy that supports HTTP/2, such as XO Proxy, stuck in Connecting. Vates fixed it in #10507 and released it in XO 6.9.1 (2026-10-05). That's also why the other project broke the same way. Running --update should pull the fix, since the installer builds from master by default. If servers behind the proxy still won't connect after updating, please open an issue with what the Servers page shows and I'll dig in. Side - note the disable license check is no longer needed as that appears not to be gated by the license check. I have pushed these changes to the Dev branch. You should be able to switch to the dev branch and run the update ... git fetch origin git switch dev ./install-xen-orchestra.sh

  • Our hyperconverged storage solution

    54 Topics
    824 Posts
    J
    @poddingue Turns out it is all secondary-to-secondary out of sync. So that makes it less intense, though if primary dies I wonder how it will resolve this, or if it will become split brained. Still unsure of how it happened, but the ones I manually cleaned up have not come back. Going to continue to manually clear them up. If it happens again I will have an alert setup to notify me, and I have all the xcp-ng logs and everything to be able to see what happened. If that happens I will post here with details and logs for the resource so we can see how it occurs. [image: image.jpeg]

  • Non-English speakers

    37 Topics
    136 Posts
    J
    @AtaxyaNetwork Merci pour tes recherches ! Oui "cd_label" serait cool comme ajout au plugin ce qui permet sur les distro type Fedora/Redhat de ne pas avoir de boot_command à gérer