Categories

  • All news regarding Xen and XCP-ng ecosystem

    145 Topics
    5k Posts
    stormiS
    @mthird said: Spoke to soon. While the updates succeeded, one of the nodes is rebooting every few minutes due to an HA self-fence. Could you open a dedicated thread and ping me there?
  • Everything related to the virtualization platform

    1k Topics
    15k Posts
    poddingueP
    On one machine in my lab, /etc/rsyslog.d/xenserver.conf defines 17 outchannels, every one of them at 104857600 bytes, and /var/log/messages isn't one of them; it's written by the stock *.info;mail.none;authpriv.none;cron.none line in /etc/rsyslog.conf and rotated by /etc/logrotate.d/syslog, so nightly and with no size trigger. The docs at https://docs.xcp-ng.org/guides/logs#rsyslog describe the 100 MiB rule but don't list which files it actually covers, which is probably why this is hard to work out without reading the config the way you did. Whether messages can realistically outrun a nightly rotation I don't know, and I'd be guessing if I said either way; the one thing in your favour is that /var/log is its own filesystem, 3.9 GB on the box I looked at (small lab machine, I haven't searched in the code, so I don't know where that size is decided), so it can't take the rest of dom0 with it. Whether that omission is deliberate or just inherited (or even something fancier) is really a question for whoever owns that file, so it might be worth a mention to @Team-OS-Platform-Release.
  • 3k Topics
    29k Posts
    acebmxerA
    While this project is more for myself it is open to others to use. Please use at your own risk. As always review the code before using in a production environment. Please leave any feedback or suggestions. https://github.com/acebmxer/xcp_pulse XCP Pulse collects XCP-ng and Xen Orchestra logs, bundles them for download, analyses them, and reports findings — for your own troubleshooting or to attach to a Vates support ticket. Everything goes through the Xen Orchestra REST API — nothing is installed on your hosts, and it only ever reads. It runs as a container with a web UI. Being built in stages, and v0.5.1 is where it is today — so this is an early look rather than a finished tool. Log collection itself is the next big piece. What works today Version What it does v0.1.0 Container, login, sessions, healthcheck v0.2.0 Connect to Xen Orchestra — URL and API token, token encrypted at rest, "Test connection" v0.3.0 Pools and hosts listed on the dashboard, grouped by pool v0.4.0 Background jobs with live progress and history, and stored results v0.5.0 Redaction — masks addresses, tokens and credentials out of log text, with a preview page v0.5.1 Each redaction rule can be switched on or off Redaction came before any download button on purpose. A real log bundle is full of internal addresses, usernames and session tokens, and the point of the download is sending that file to Vates — shipping collection first would have meant a headline feature that leaks credentials. One real xensource.log I tested against had 8,359 lines matching password, secret or session patterns. What is coming Collect the full log bundle per host, as a background job, redacted, with a download. Measured on my own XCP-ng 8.3 pool: about 433 MB and 100 seconds per host, 603 files. Collect individual categories — XAPI, storage, audit, security, kernel and the rest — pulled out of the cached bundle instead of downloading again. Current logs only comes to roughly 35 MB instead of 433 MB. Date ranges — of that 433 MB, 418 MB is rotated history, so asking for the last three days is a large saving. Findings — failed tasks, alarms, missing patches, storage errors, HA fencing, clock skew, with the evidence behind each one. A Vates support package — one file with the redacted bundle, findings and a manifest of what was masked. Multiple users, docs in the web UI, and self-update. Full list with status: https://github.com/acebmxer/xcp_pulse/blob/main/docs/roadmap.md Quick start No clone and no build — the image is published to GHCR, so the compose file and an env file are the whole deployment: mkdir xcp-pulse && cd xcp-pulse curl -o compose.yaml https://raw.githubusercontent.com/acebmxer/xcp_pulse/main/compose.yaml.example curl -o xcp-pulse.env https://raw.githubusercontent.com/acebmxer/xcp_pulse/main/xcp-pulse.env.example Generate the admin password hash — XCP Pulse stores a hash, never a password, and refuses to start without one: docker compose run --rm xcp-pulse python -m app.hashpw Paste the printed XCP_PULSE_ADMIN_PASSWORD_HASH=... line into xcp-pulse.env, then: docker compose up -d Open http://localhost:8080 and sign in with admin and the password you chose. The env file has to be called xcp-pulse.env and not .env — compose treats a file of that name as its own variable source and mangles the Argon2 hash. A note on the XO account Inventory and API-based findings work fine with a Read only role. Downloading logs does not — /hosts/{id}/logs.tgz requires export:logs on host, and on the instance I measured (XO CE, @xen-orchestra/rest-api 0.39.0) that privilege was not in the grantable catalogue at all. The only role that could download logs was Administrator. So for log collection you currently need an admin token. XCP Pulse reads the privilege catalogue from your instance and tells you what it can actually grant, rather than assuming — and asks which account type you gave it so it can name the missing privilege instead of showing a bare 403. Security XCP Pulse holds a token that can read every log on your pool, and stores files containing session tokens and internal network topology. Run it on a trusted management network behind a reverse proxy — the compose file binds to 127.0.0.1 by default for that reason. Not exposed to the internet. MIT licensed. This is an independent tool and is not affiliated with or endorsed by Vates. [image: 1788787261460-screenshot_20260907_091915-1.png] [image: 1788787295758-screenshot_20260907_092108.png] [image: 1788787376266-screenshot_20260907_092146.png]
  • Our hyperconverged storage solution

    51 Topics
    805 Posts
    P
    @jcdick1 you should follow this procedure https://help.vates.tech/kb/en-us/34-support-tunnel-and-access/30-create-a-support-tunnel
  • 37 Topics
    136 Posts
    J
    @AtaxyaNetwork Merci pour tes recherches ! Oui "cd_label" serait cool comme ajout au plugin ce qui permet sur les distro type Fedora/Redhat de ne pas avoir de boot_command à gérer