Categories

  • All news regarding Xen and XCP-ng ecosystem

    143 Topics
    4k Posts
    P
    @dthenot said: @probain Hello, It's likely linked to the List index out of range bug. That bug was linked to the SR scan failing to introduce CBT_metatadata VDI in the XAPI database, could you try to launch a xe sr-scan uuid=<SR UUID> and try again to disable CBT? If it does not work, could you share the /var/log/SMlog of around the time you are trying to disable CBT? I've sent you a DM for sharing the logs.. Unfortunately I "solved" the issue by deleting all snapshots related to each VM. Including CBT ones. That did make it so I could toggle CBT on the VDIs again. But I've collected the logs for you. This also seems like a good time to raise my suggestion to have somewhere at vates where we could upload details in a similar way to how TrueNAS does it. Suggested here: https://feedback.vates.tech/posts/69/suggesting-to-add-a-debug-file-option

  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    B
    @semarie Maybe this points at an issue. It looks like the cert file is empty? And this is after I ran that command to refresh the cert. I get this same output for both the pool master and the host I am trying to add. [image: 1779888222308-84fc3624-7777-4f6a-b81f-c09586a63d05-image.jpeg] Then the openssl x509 command says it's unable to load the cert or read it. I assume that's because it's empty? As for the time and date, yes the pool master and this server are in sync. At first, I had forgotten to set the new host to use the NTP pool during setup and Xen Orchestra helpfully yelled at me about that. Haha

  • All Xen Orchestra related questions/reports

    3k Topics
    28k Posts
    J
    I updated XO again - just thought I would add the API error details: Error: ENOENT: no such file or directory, open '/run/xo-server/mounts/d806298f-85cf-4565-bb7e-9fad479b941f/xo-vm-backups/645b7426-0b09-e192-40ea-4f6c36e35c23/vdis/8190942e-8b0d-4044-95b6-6b8d91a463f7/7b86306a-fffa-4528-b946-d0bc60dcb609/20260527T000011Z.vhd' From: at NfsHandler.addSyncStackTrace (/opt/xen-orchestra/@xen-orchestra/fs/dist/local.js:21:26) at NfsHandler._openFile (/opt/xen-orchestra/@xen-orchestra/fs/dist/local.js:154:35) at /opt/xen-orchestra/@xen-orchestra/fs/dist/utils.js:29:26 at new Promise (<anonymous>) at NfsHandler.<anonymous> (/opt/xen-orchestra/@xen-orchestra/fs/dist/utils.js:24:12) at loopResolver (/opt/xen-orchestra/node_modules/promise-toolbox/retry.js:83:46) at new Promise (<anonymous>) at loop (/opt/xen-orchestra/node_modules/promise-toolbox/retry.js:85:22) at NfsHandler.retry (/opt/xen-orchestra/node_modules/promise-toolbox/retry.js:87:10) at NfsHandler._openFile (/opt/xen-orchestra/node_modules/promise-toolbox/retry.js:103:18)

  • Our hyperconverged storage solution

    47 Topics
    745 Posts
    J
    @Mathieu-L linstor n l was included in my original post. All nodes were updated to May 2026 Security and Maintenance Updates for XCP-ng 8.3 LTS, all nodes were restarted. May 2026 Updates #2 for XCP-ng 8.3 LTS was released, and a couple days later I installed on all hosts. No host restarted. When xen04 was restarted, that is when this issue happened. I had used systemctl restart linstor-controller here (https://xcp-ng.org/forum/post/105309) to restart the controller.

  • Non-English speakers

    35 Topics
    113 Posts
    olivierlambertO
    Ah excellente nouvelle Je passe le sujet en résolu !