Categories

  • All news regarding Xen and XCP-ng ecosystem

    145 Topics
    5k Posts
    olivierlambertO
    Great, thanks for the feedback @yomeyo !

  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    D
    @trelane Hello, the bug affects Xen drivers of any 9.0 series (considering the upstream code, it goes back to circa September 2019). 9.2.385 contains the fix, which was merged upstream just this month. The bug also impacts network connections, however to a lesser extent due to its nature. I believe that the bug is also present in XenServer VM Tools 9.6.0 and by extension, older versions of it. We recommend that you switch to the XCP-ng tools whenever possible, also due to its other benefits (fully open source, validated for XCP-ng and optimized for Xen Orchestra).

  • All Xen Orchestra related questions/reports

    3k Topics
    29k Posts
    acebmxerA
    @poddingue Looks like it clears after 30 days... but not the XO Config Cloud backup... This is from XOA.. [image: Screenshot_20261001_054141.png] Just filtered for backup... Oldest is from 7-19-26 oldest backup job 8-31-26. [image: Screenshot_20261001_053839.png]

  • 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