Categories

  • All news regarding Xen and XCP-ng ecosystem

    143 Topics
    4k Posts
    A
    @olivierlambert Seeing some failure/errors on CR jobs. It leaves VDIs attached to Control Domain... Next run it normally works. I have not seen this error until after the current sm update. Running XO (commit 7e144). "message": "INTERNAL_ERROR(Storage_error ([S(Illegal_transition); [[S(Activated);S(RO)];[S(Activated);S(RW)]]]))", "name": "XapiError", "stack": "XapiError: INTERNAL_ERROR(Storage_error ([S(Illegal_transition);[[S(Activated);S(RO)];[S(Activated);S(RW)]]]))\n at XapiError.wrap (file:///opt/xo/xo-builds/xen-orchestra-202605050700/packages/xen-api/_XapiError.mjs:16:12)\n at default (file:///opt/xo/xo-builds/xen-orchestra-202605050700/packages/xen-api/_getTaskResult.mjs:13:29)\n at Xapi._addRecordToCache (file:///opt/xo/xo-builds/xen-orchestra-202605050700/packages/xen-api/index.mjs:1078:24)\n at file:///opt/xo/xo-builds/xen-orchestra-202605050700/packages/xen-api/index.mjs:1112:14\n at Array.forEach (<anonymous>)\n at Xapi._processEvents (file:///opt/xo/xo-builds/xen-orchestra-202605050700/packages/xen-api/index.mjs:1102:12)\n at Xapi._watchEvents (file:///opt/xo/xo-builds/xen-orchestra-202605050700/packages/xen-api/index.mjs:1275:14)\n at process.processTicksAndRejections (node:internal/process/task_queues:104:5)"

  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    bleaderB
    Copy Fail is documented in VSA-2026-013, we don't have one for Dirty Frag yet as we're still investigating XCP-ng side regarding it. For XOA, unattended updates should have installed the patched debian kernel, you just need to reboot it. Debian security tracker states they are both fixed: https://security-tracker.debian.org/tracker/CVE-2026-31431 https://security-tracker.debian.org/tracker/CVE-2026-43284

  • All Xen Orchestra related questions/reports

    3k Topics
    28k Posts
    poddingueP
    Hey, thanks for flagging this. I think what may be happening is that after the merge at the end of the retention chain, the UI might be picking up the full VM size (2.17 TB) instead of the actual KEY file size on disk (9.1 GB). If you can confirm the key file is genuinely 9.1 GB on your storage, that would point to a display bug rather than a data issue. Could you please check, and if so, it might be worth opening an issue on the XO GitHub with the numbers? I'm not entirely sure of the exact mechanism here, so @Team-XO-Backend would know better than me.

  • Our hyperconverged storage solution

    46 Topics
    740 Posts
    G
    @dthenot said: @ccooke Hello, You should be able to make the XOSTOR SR work again if you update sm and sm-fairlock on the other hosts. yum update sm sm-fairlock Then you should be able to re-plug the SR on the master and proceed with the RPU. Hello, Had the same problem, the command resolved the issue. It needs to be run on every host. Everything is working fine again. However, I had to complete the pool update manually.

  • Non-English speakers

    34 Topics
    102 Posts
    B
    La remarque a été intégrée dans l'article: https://www.myprivatelab.tech/xcp_lab_v2_ha#perte-master Merci encore pour le retour.