Categories

  • All news regarding Xen and XCP-ng ecosystem

    142 Topics
    4k Posts
    A
    @gduperrey Installed on home lab via rolling pool update and both host updated no issues and vms migrated back to 2nd host as expected this time. fingers crossed work servers have the same luck. I do have open support ticket from last round of updates for work servers. Waiting for response before installing patches.

  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    kruessK
    Good moaning... The solution was pretty simple: a toolstack restart on the master (xcp83) did get all back on track and it now allows me to move the systems with a simple shutdown/start.

  • All Xen Orchestra related questions/reports

    3k Topics
    28k Posts
    A
    @MathieuRA I am guessing i did thoroughly check out your fix against all vms.... Some vms will populate others will not... Here are more of the log info. Let me know if you still need more if this is caused by my script. xo-logs.txt I ran this all through claude code and this is its thoughts... The server logs don't show anything related to the backup spinner, but there are two issues worth addressing: 1. Invalid environment assignment (line 11 of the service file) /etc/systemd/system/xo-server.service:11: Invalid environment assignment, ignoring Something in the service file's Environment= or EnvironmentFile= line is malformed. This could be from the install script. Worth checking what's on line 11 of that file. 2. PAM limits failures (recurring) pam_limits: Could not set limit for 'nofile' to soft=1024, hard=1048576 pam_limits: Could not set limit for 'memlock' to soft=775520256, hard=... The xo user can't set its own resource limits when running sudo. This suggests the systemd LimitNOFILE/LimitMEMLOCK directives in the service file conflict with what PAM is trying to apply. 3. listMissingPatches / updater plugin busy — repeated but harmless; XO polls for host patches and races with the xcp-ng updater. Not related to your issue. 4. WebSocket ECONNRESET/UND_ERR_SOCKET — normal; long-lived connections to xcp-ng hosts drop and reconnect. None of these explain the backup spinner — that's still a UI/API retrieval bug. But the service file issues are worth fixing. Can you share the output of: cat -n /etc/systemd/system/xo-server.service That'll show exactly what's wrong on line 11, and I can check if the install script is generating it incorrectly. cat -n /etc/systemd/system/xo-server.service 1 [Unit] 2 Description=Xen Orchestra Server 3 After=network-online.target redis.service 4 Wants=network-online.target 5 6 [Service] 7 Type=simple 8 User=xo-service 9 10 Environment="NODE_ENV=production" 11 WorkingDirectory=/opt/xen-orchestra/packages/xo-server 12 ExecStartPre=/bin/mkdir -p /run/xo-server/mounts 13 ExecStartPre=/bin/chmod 755 /run/xo-server/mounts 14 ExecStart=/usr/bin/node /opt/xen-orchestra/packages/xo-server/dist/cli.mjs 15 Restart=always 16 RestartSec=10 17 SyslogIdentifier=xo-server 18 19 # Runtime directory 20 RuntimeDirectory=xo-server 21 RuntimeDirectoryMode=0755 22 23 # Allow binding to privileged ports (80/443) 24 AmbientCapabilities=CAP_NET_BIND_SERVICE 25 # Bounding set: ceiling for all processes in this service tree. 26 # CAP_NET_BIND_SERVICE: bind to ports 80/443 27 # CAP_SETUID/CAP_SETGID/CAP_AUDIT_WRITE: required for sudo to function 28 # CAP_SYS_ADMIN: required for mount syscall (NFS/CIFS remotes) 29 CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_SETUID CAP_SETGID CAP_SYS_ADMIN CAP_AUDIT_WRITE 30 31 [Install] 32 WantedBy=multi-user.target The current service file looks completely fine — line 11 is WorkingDirectory=... which is valid. The "Invalid environment assignment" warning in the Feb 24 logs was from an older version of the file that has since been fixed (likely by a re-run of your install script). The current file has no issues. All directives are correct: Environment="NODE_ENV=production" — valid syntax CapabilityBoundingSet — looks correct from the recent commit fixes Everything else is standard The PAM limits errors you saw are also unrelated to the service file syntax — those happen because pam_limits tries to apply /etc/security/limits.conf rules when xo-server runs sudo, but systemd's own LimitNOFILE takes precedence and PAM can't override it. This is expected behavior and harmless. Bottom line: The server logs don't reveal any cause for the backup spinner. The spinner is almost certainly this known XO behavior: when the UI subscribes to backup log data for a VM, if the response takes too long or returns in an unexpected format, the loading state never resolves. It's a frontend bug, not a server configuration issue.

  • Our hyperconverged storage solution

    43 Topics
    729 Posts
    SuperDuckGuyS
    @alcoralcor Thanks for the info. I thought maybe I was using too many disks, so I've tried creating disk groups of 3-4 drives with the same issue.

  • Non-English speakers

    34 Topics
    100 Posts
    AtaxyaNetworkA
    @bvivi57 Hello ! Déjà bravo pour le travail d'écriture, faire plusieurs articles aussi long, avec screenshot et commandes CLI intégré, c'est un boulot de fou ! J'ai rapidement parcouru tous tes articles, je prendrais le temps de tout relire pour te faire un feedback complet avec quelques tips, si tu le souhaites ! Sur le dernier article, j'ai vu que tu as redémarré xo-serveur parce que tu n'arrivais pas à te reconnecter au master: tu peux (dans XO5, pas encore XO6) juste aller dans setting server, et cliquer sur le bouton "disconnect" et "reconnect". Ça va forcer une reconnexion à la XAPI, et si elle est disponible, ça va reconnecter ton pool instantanément à ton XO. Redémarrer un XO, surtout si tu as plusieurs pools, peut avoir certaines conséquences : Si tu as des backups en cours, ça va les kill instantanément, pareil pour les migrations entre deux pools différents. Il faut y aller doucement avec un systemctl restart xo-server En tout cas merci pour ces articles, je suis heureuse de voir que la communauté francophone s'intéresse de plus en plus à l'écosystème XCP-ng/XO (et je dit ça en tant qu'"early" qui utilise la solution depuis... longtemps ! )