Categories

  • All news regarding Xen and XCP-ng ecosystem

    145 Topics
    5k Posts
    marcoiM
    went well with test systems. going to do prod soon.

  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    poddingueP
    My earlier wording was the problem here, not your reading of it. There are two official descriptions and they do not say the same thing. The CLI reference calls start-delay "the delay to wait before a call to start up the VM returns", which is the one I quoted. The XenAPI field description calls it "the delay to wait before proceeding to the next order in the startup sequence". That second one is exactly what you saw: the delay lands on the next VM to start, not on the one you set it on. I quoted the confusing one and then said it explained your behaviour, which it does not really. What I still cannot explain is why a start-delay would stop a VM autostarting altogether. Neither wording predicts that, so I would rather say I do not know than invent a reason. On auto_poweron_delay, I went looking and could not find it anywhere in the XCP-ng or XO docs, so I think your instinct about that search result was right. I have updated the docs PR I had open so it leads with the XenAPI wording and cites both, since the CLI reference phrasing is what sent me wrong in the first place.

  • All Xen Orchestra related questions/reports

    3k Topics
    29k Posts
    christopher-petzelC
    @florent suggesting this looks like a network issue, I took a look at my XO's server's syslog and found the error when this occurs. 2026-07-31T00:10:00.428083-04:00 mis-26-svr xo-server[1298]: 2026-07-31T04:10:00.427Z xo:xo-server ERROR uncaught exception { 2026-07-31T00:10:00.428186-04:00 mis-26-svr xo-server[1298]: error: AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value: 2026-07-31T00:10:00.428262-04:00 mis-26-svr xo-server[1298]: 2026-07-31T00:10:00.428309-04:00 mis-26-svr xo-server[1298]: assert(!this.paused) 2026-07-31T00:10:00.428341-04:00 mis-26-svr xo-server[1298]: 2026-07-31T00:10:00.428391-04:00 mis-26-svr xo-server[1298]: at Parser.finish (/opt/xo/xo-builds/xen-orchestra-202607200851/node_modules/undici/lib/dispatcher/client-h1.js:302:5) 2026-07-31T00:10:00.428414-04:00 mis-26-svr xo-server[1298]: at TLSSocket.<anonymous> (/opt/xo/xo-builds/xen-orchestra-202607200851/node_modules/undici/lib/dispatcher/client-h1.js:741:32) 2026-07-31T00:10:00.428434-04:00 mis-26-svr xo-server[1298]: at TLSSocket.emit (node:events:521:24) 2026-07-31T00:10:00.428478-04:00 mis-26-svr xo-server[1298]: at TLSSocket.patchedEmit [as emit] (/opt/xo/xo-builds/xen-orchestra-202607200851/@xen-orchestra/log/configure.js:52:17) 2026-07-31T00:10:00.428508-04:00 mis-26-svr xo-server[1298]: at endReadableNT (node:internal/streams/readable:1729:12) 2026-07-31T00:10:00.428525-04:00 mis-26-svr xo-server[1298]: at processTicksAndRejections (node:internal/process/task_queues:90:21) { 2026-07-31T00:10:00.428549-04:00 mis-26-svr xo-server[1298]: generatedMessage: true, 2026-07-31T00:10:00.428567-04:00 mis-26-svr xo-server[1298]: code: 'ERR_ASSERTION', 2026-07-31T00:10:00.428582-04:00 mis-26-svr xo-server[1298]: actual: false, 2026-07-31T00:10:00.428599-04:00 mis-26-svr xo-server[1298]: expected: true, 2026-07-31T00:10:00.428614-04:00 mis-26-svr xo-server[1298]: operator: '==', 2026-07-31T00:10:00.428628-04:00 mis-26-svr xo-server[1298]: diff: 'simple' 2026-07-31T00:10:00.428642-04:00 mis-26-svr xo-server[1298]: } 2026-07-31T00:10:00.428659-04:00 mis-26-svr xo-server[1298]: } So it looks like xo-server is dying, could it be the module undici that the problem here? Keep in mind that 13 other instances of xo-server performed the backup with a problem at the exact same time. Some days this never happens, some days it could be 4 instances of xo-server that die the same way in executing the backup. I think it's also important to note that the instance of xo-server dying happens immediately upon the backup being started at 10 minutes after midnight. I would think that if the problem were the network itself, that there would be some timeout period before causing the xo-server instance to crash. To answer a question asked of @jb , this is a local XCP-ng management network and there are no other backups occurring at 00:10.

  • Our hyperconverged storage solution

    50 Topics
    796 Posts
    olivierlambertO
    Great, thanks for the feedback!

  • Non-English speakers

    37 Topics
    127 Posts
    AtaxyaNetworkA
    @jeremie1977 j'ai un packer qui fonctionne avec RHEL 10 (c'est ce que j'avais sous la main), uefi, sans dhcp, et un cd file qui sert le ks Le code est ici: https://github.com/disruptivemindseu/xcpng-template-builder/tree/rhel-airgapped/packer/distros/rhel/10/uefi-airgapped Je vais essayer avec une RHEL 9 ce week-end, il y a peut-etre une subtilité entre les deux versions