Categories

  • All news regarding Xen and XCP-ng ecosystem

    143 Topics
    4k Posts
    A
    abudef said: I was thinking more of updating the entire set of the agent and drivers, similar to how XenServer VM Tools for Windows have it implemented. Using a scheduled job, they regularly check whether an update is available, and if so, they carry out the update of both the agent and the drivers themselves. Hi, how’s it looking regarding a possible automatic update?
  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    olivierlambertO
    No downside, the agent coming from Gitlab is better.
  • 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) The error in XO remains: Error: ENOENT: no such file or directory, stat '/run/xo-server/mounts/d806298f-85cf-4565-bb7e-9fad479b941f/xo-vm-backups/645b7426-0b09-e192-40ea-4f6c36e35c23/vdis/8190942e-8b0d-4044-95b6-6b8d91a463f7/c1e95b3b-cca1-457a-a0d4-0a37924c8170/20260527T181636Z.alias.vhd' What's bizarre is that I absolutely nuked the path /run/xo-server/mounts/d806298f-85cf-4565-bb7e-9fad479b941f/xo-vm-backups with rm -rf /run/xo-server/mounts/d806298f-85cf-4565-bb7e-9fad479b941f/xo-vm-backups so that there was nothing left behind. After starting the job, XO rebuilds the path fine: ls -al /run/xo-server/mounts/d806298f-85cf-4565-bb7e-9fad479b941f/xo-vm-backups/645b7426-0b09-e192-40ea-4f6c36e35c23/vdis/8190942e-8b0d-4044-95b6-6b8d91a463f7/c1e95b3b-cca1-457a-a0d4-0a37924c8170/ total 13 drwxr-xr-x 3 3001 3001 3 May 27 18:16 . drwxr-xr-x 4 3001 3001 4 May 27 18:16 .. drwxr-xr-x 2 3001 3001 2 May 27 18:18 data but it is correct, the file 20260527T181636Z.alias.vhd never appears. To be, this proves the NFS is 100% fine... XO can mount, test, write, and delete from the mount just fine. But I don't know why it doesn't create the *alias.vhd file.
  • 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.
  • 35 Topics
    113 Posts
    olivierlambertO
    Ah excellente nouvelle Je passe le sujet en résolu !