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
    tjkreidlT
    @stac00 That's correct, it will not keep changes in the sshd_conf file. Instead, create a dedicated folder for custom OpenSSH daemon overrides. Systemd reads this folder to layer your custom preferences on top of the default package configurations.bashmkdir -p /etc/systemd/system/sshd.service.d Step 2: Write the Persistent Port OverrideCreate an override.conf file inside that new directory using nano:bashnano /etc/systemd/system/sshd.service.d/override.conf Use code with caution. Paste the following lines into the file (replace 2222 with your custom port number):ini[Service] ExecStart= ExecStart=/usr/sbin/sshd -D -p 2222 $OPTIONS (Note: The blank ExecStart= line is required; it instructs systemd to clear out the default command entirely before applying your custom command). Step 3: Update the Local Firewall (iptables)XCP-ng manages its firewall directly via iptables. You must insert a rule to accept traffic on the new port.bashiptables -I RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 2222 -j ACCEPT To ensure this rule survives host reboots, save the active rules:bashiptables-save > /etc/sysconfig/iptables Use code with caution.Step 4: Reload and TestTell systemd to reload its daemon configurations, and then restart the SSH service:bashsystemctl daemon-reload systemctl restart sshd Crucial Safety Check: Do not disconnect your current console window. Open a completely new terminal on your local machine and test the connection string using your new port number:bashssh -p 2222 root@<your-xcp-ng-ip> If you manage this host through an orchestrator, if you are using Xen Orchestra (XO) you may also need to update the custom management connection port inside your UI console. I hope this helps. I have not attempted this myslef. so proceed with extreme caution! Again, be very careful to make sure it still works and is consistent everywhere it needs to be. The firewall rules are also critical.

  • 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 without 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