v0.8.0–v0.9.1 — multi-user accounts, self-update, built-in HTTPS, and date ranges. Three releases since the last update, so bundling them here. Date ranges. Collections, extractions, findings runs and the support package can now be scoped to a window instead of always covering the whole bundle — last 24h/7d/30d, since last reboot, or a custom range. XO's own routes still have no date filter, so the first download is unchanged size — the range only narrows what gets kept and reported afterwards. Redact on demand. A collection no longer has to redact immediately with whatever rules happen to be on at that moment. There's now a checkbox to store the raw bundle only, and a "Redact now" button on the card afterwards using whichever rules are switched on when you press it. Multiple user accounts, roles, and an activity log. This was on the "what is coming" list in the first post and it's in now. Any number of accounts, three roles — admin, operator, viewer (read-only, but can still download what's already stored) — and an Activity page logging logins, settings changes, and job runs. Optional 2FA. Per-user TOTP, off by default, each account turns it on for itself. QR code setup, backup codes. Self-update from the UI, opt-in and off by default. Checking needs nothing extra; applying an update needs the Docker socket mounted in explicitly, since that's effectively host root, so it's a separate deliberate step — uncomment the socket mount and group_add block in docker-compose.yml, and it needs its own .env file (just DOCKER_GID=..., next to docker-compose.yml, not the same file as xcp-pulse.env) or docker compose up -d fails with unable to find group. .env.example has the one-liner to generate it. Built-in HTTPS, no reverse proxy required. Bundles nginx into the image to terminate TLS — self-signed cert on first start, or upload your own from Settings. A reverse proxy still works fine too. A user manual in the app itself, under /help — no need to leave XCP Pulse or check out the repo to read how something works. Fixed The account-requirements note from the first two posts was wrong in a way I only found by testing it properly: export:logs — the privilege log downloads actually need — isn't in any built-in XO role, but it can be granted through a custom role. "Test connection" was reading a catalogue that can't tell you that, and told every restricted account it needed full admin regardless. It now actually probes the download endpoint, and the docs walk through creating the custom role via three REST API calls (no UI for it yet on either XO version). A real concurrency bug: the shared SQLite connection wasn't locked across fetches, only execute, so two requests landing close together could crash a page reading jobs — reproduced it under the test suite's own concurrency test. Base-OS CVEs patched in the image build (perl-base, libc6, others); CI now runs a Trivy scan on every push. Still not fixed: the truncated-download-behind-a-reverse-proxy issue from the last post. Haven't found the actual cause yet. Also looking for anyone who can test against a remote proxy in a lab setup. Also open to any other suggestions, features, improvements, UI changes, etc... If any chance someone on Vates would test on their own time. Things like the support bundle and or the logs themselves are not being manipulated in any unwanted ways (for Vates or the project) https://github.com/acebmxer/xcp_pulse

It was too tempting not to test, so I went and tested the other half. On an 8.3 host I set the preferred resolution to 800x600 in the OVMF menu on a UEFI Debian VM, turned that VM into a template, and cloned it. The clone came up at 800x600. A control clone of the same original, with nothing set, came up at 1024x768. So your workaround holds, the resolution really does ride along into VMs built from the template. For anyone who wants to poke at it, the setting is a UEFI variable called PlatformConfig under GUID 7235c51c-0c80-4cab-87ac-3b084a6304b1. It only appears in NVRAM once you commit it in the menu, and it stores width and height as plain little-endian integers, which is why it travels with the VM record. One thing I didn't expect: the OVMF help text says the mode list is filtered against video RAM size, but the VM I used had the default 4 MB and still offered everything up to 1280x1024. So you may not need to raise videoram for the common ones. Fair warning though, I measured the console at the firmware stage rather than after the distro's own driver takes over, so a guest that sets its own mode later could still override it. At least, that's my understanding.

So I ended up going with the Windows B&R as i could net setup the windows mount server when setting up the repo for the backups. It would setup the linux one but not the windows one. This was with using the veeam console from a windows client. So i ended up with the Windows one. Now after a few backups i am see this warning / error.... 8/5/2026 5:34:50 PM Warning : Failed to use CBT: [Task e75c4247-2ee1-7b51-088c-b970ace60f3d (Async.VDI.list_changed_blocks) failed: . SR_BACKEND_FAILURE_460. . Failed to calculate changed blocks for given VDIs. [opterr=Source and target VDI are unrelated] First i thought it was because i maped the new job to older backups from Beta v1. So i purged all old backups and started fresh. The full backups were successful. Now on first delta 4 out of 7 vms have that warrning. This a Veeam issue or xcp-ng?

@acebmxer Thank you for your quick feedback.

@acebmxer all good and thank you again for sharing your discovery on the forums

@acebmxer No problem, that's excellent news, thanks for the feedback!

Indeed, it should be detected/reported correctly to avoid losing time finding the problem. Let me ping @julienXOVates

Added local user support. Current sample config file. # Example xo-apply configuration. # Copy this into your own PRIVATE repo, edit, then: # export XO_URL=https://xo.example.lan XO_TOKEN=... # xo-apply diff config.yaml # xo-apply apply config.yaml # # Secrets never go in this file: use ${env:VAR_NAME} placeholders, # resolved from environment variables when the tool runs. # # A section that is ABSENT is unmanaged (xo-apply won't touch or report that # resource type). A present-but-empty section means "manage this type, none # should exist" (only deleted when you pass --prune). remotes: # NFS share on a NAS - name: nas-backups type: nfs host: 192.168.1.50 path: /export/xo-backups # port: 2049 # optional # mountOptions: vers=4 # optional mount(8) options # SMB / Windows share — host is "HOST\share" (single backslash in YAML # double-quoted strings must be written as \\) - name: windows-share type: smb host: "192.168.1.60\\backups" domain: WORKGROUP username: backup password: ${env:SMB_BACKUP_PASSWORD} # path: xo # optional subfolder inside the share # S3-compatible object storage (AWS, MinIO, Backblaze B2, ...) - name: offsite-s3 type: s3 host: s3.us-east-1.amazonaws.com path: my-bucket/xo-backups # bucket/directory accessKey: AKIAEXAMPLE secretKey: ${env:S3_SECRET_KEY} region: us-east-1 # protocol: http # for http-only endpoints (e.g. local MinIO) # Directory local to the XO VM (e.g. a mounted USB disk) - name: local-disk type: local path: /mnt/backup-disk backupJobs: # Delta (incremental) backup of every VM tagged "critical", every night - name: nightly-critical mode: delta vms: tag: critical remotes: [nas-backups, offsite-s3] settings: # optional global job settings, passed through to XO concurrency: 2 # timezone: America/New_York # maxExportRate: 104857600 # bytes/s # nRetriesVmBackupFailures: 2 # reportWhen: failure schedules: - name: nightly cron: "0 2 * * *" retention: 14 # backups kept on the remotes # snapshotRetention: 3 # snapshots kept on the pool # timezone: America/New_York # enabled: false # schedules are enabled by default # Weekly full backup of specific VMs, selected by name - name: weekly-full mode: full compression: zstd vms: names: [dc-01, mail-01] # ...or select by uuid: uuids: [770aa52a-fd42-8faf-f167-8c5c4a237cac] # ...or pass a raw XO smart-mode pattern for anything more complex: # raw: # type: VM # tags: # __or: [[prod]] remotes: [nas-backups] schedules: - name: weekly cron: "0 3 * * 0" retention: 8 # Disaster Recovery / Continuous Replication: instead of (or in addition to) # remotes, target one or more SRs. mode:full => DR, mode:delta => CR. - name: dr-critical mode: full # delta = Continuous Replication vms: tag: critical srs: [4991d4aa-ed84-599b-7d19-97f2f943a366] # target SR UUID(s) # remotes: [] # SR-only is fine; may be combined with remotes schedules: - name: hourly-dr cron: "0 * * * *" retention: 3 # replicas kept on the SR # Metadata backups: pool metadata and/or XO's own configuration. metadataBackups: - name: xo-config xoMetadata: true # back up XO's own config pools: [939ed551-fbd6-9868-52d8-d3997b7bf7da] # pool UUID(s) for pool metadata remotes: [nas-backups] schedules: - name: daily cron: "0 21 * * *" xoRetention: 7 # XO metadata backups kept poolRetention: 7 # pool metadata backups kept # Mirror backups: copy an existing remote's backups onto other remote(s), # e.g. push local backups offsite to S3. mirrorBackups: - name: offsite-mirror mode: full # full or delta, to match the source backups sourceRemote: nas-backups remotes: [offsite-s3] schedules: - name: nightly-mirror cron: "0 5 * * *" retention: 14 # Sequences: run backup schedules one after another. Each step names a job and # one of its schedules (from any job kind above, or already in XO). The sequence # has its own cron for when the whole chain runs. sequences: - name: nightly-then-metadata steps: - { job: nightly-critical, schedule: nightly } - { job: xo-config, schedule: daily } cron: "0 22 * * *" # enabled: false # sequences are enabled by default # timezone: America/New_York # Local users (XO's internal auth provider). Users created by an external auth # plugin (LDAP/SAML/GitHub) are NOT managed here and are never pruned. # # Passwords are write-only: XO never returns them, so a real password can't be # exported or diffed — but XO REQUIRES a password to create a user. So `export` # writes the placeholder `password: ChangeMe` for every user. # ⚠️ CHANGE these before importing into a real XO (or use a ${env:...} ref), # otherwise every new user is created with the password "ChangeMe". # The password is only used when a user is CREATED; for an existing user it is # ignored (change it in the XO UI). Only `permission` is compared for drift. users: - email: ops@example.com password: ChangeMe # required by XO; change before import permission: admin # none | read | write | admin (default: none) # Local groups. Members are referenced by email and resolved to ids at apply # time; each member must be a user defined above or already present in XO. groups: - name: operators users: [ops@example.com]

Great! I think this is really the best possible approach to make it clean

Thanks, I made the feedback to the XO team, this will be fixed ASAP.

@simonp said: @acebmxer Hi, Thanks to your help we were able to identify an issue with Redis that we think is the source of the v6 dashboard loading issue. Could you try and checkout the fix_redis_encryption_issue branch, rebuild xo and restart ? This should solve the 401 issues. Switched back to Master branch and made some changes to my install script. add diagnostics for missing XO 6 web UI build artifacts Plain bash [[ -f ]] fails silently on unreadable paths owned by SERVICE_USER, causing false-positive missing-artifact warnings. Switch all file/dir tests and grep calls to use sudo. SUCCESS] Xen Orchestra built successfully [INFO] Build verification passed: dist — all JS chunks present. [INFO] Build verification passed: dist — all JS chunks present. [INFO] Creating systemd service... [SUCCESS] Systemd service created and enabled [INFO] Configuring sudo for xo-service (mount/umount/findmnt)... [SUCCESS] Sudo configured for xo-service (mount, umount, findmnt) [INFO] Applying security hardening... [INFO] Starting xo-server service... [INFO] Waiting for Xen Orchestra to become ready (up to 60s)... [INFO] Not ready yet (attempt 1/10), retrying in 6s... [SUCCESS] Xen Orchestra is ready (HTTPS on port 443) [SUCCESS] Update completed successfully! [INFO] New commit: 0f29421627c7 v6 Dashboard still loading correctly. Thank you for the fix.

The progress bar issue you and Florent were chasing looks fixed in 6.7 (PR #10133). Worth upgrading and seeing if it moves now instead of sitting still. Separately, since this thread is specifically about QCOW2 backups: 6.7 also fixes an offset bug that could leave incremental backups mostly empty after the first block when NBD isn't enabled. Worth a look at the release notes if that's your setup too.

@MathieuRA said: Hi, regarding your backups which do not appear on the XO5 restore page, I suggest you to open a new topic Forgot to include the link to the new topic https://xcp-ng.org/forum/topic/12040/restore-only-showing-1-vm

@gregbinsd let us know. If you do use my script. It pulls nodejs from NodeSource so it may not install the latest 24.15.0 tls. If you specific 24.15.0 it will install that version. If you need to change node version with my script use the rebuild option.

Pilow's right that moving a VM to another SR forces one full pass while the CBT bitmap is rebuilt; that part is expected. But your screenshot actually shows the likely culprit for the all-VMs-fall-back-to-full pattern: you have Purge snapshot data when using CBT enabled, and XO's incremental backup docs flag exactly that combination as a known issue where you can occasionally get unexpected fulls: https://docs.xen-orchestra.com/xo5/incremental_backups#known-issues. It might be worth running a few jobs with that toggle off to see if the deltas hold. It is a known rough edge on the CBT side, so following the central CBT feedback thread and maybe a nudge to @Team-XO-Backend wouldn't hurt.

Hi @acebmxer, I've made some tests with a small infrastructure, which helped me understand the behaviour you encounter. With the performance plan, the load balancer can trigger migrations in the following cases: to better satisfy affinity or anti-affinity constraints if a host has a memory or CPU usage exceeds a threshold (85% of the CPU critical threshold, of 1.2 times the free memory critical threshold) with vCPU balancing behaviour, if the vCPU/CPU ratio differs too much from one host to another AND at least one host has more vCPUs than CPUs with preventive behaviour, if CPU usage differs too much from one host to another AND at least one host has more than 25% CPU usage After a host restart, your VMs will be unevenly distributed, but this will not trigger a migration if there are no anti-affinity constraints to satisfy, if no memory or CPU usage thresholds are exceeded, and if no host has more CPUs than vCPUs. If you want migrations to happen after a host restart, you should probably try using the "preventive" behaviour, which can trigger migrations even if thresholds are not reached. However it's based on CPU usage, so if your VMs use a lot of memory but don't use much CPU, this might not be ideal as well. We've received very few feedback about the "preventive" behaviour, so we'd be happy to have yours. As we said before, lowering the critical thresholds might also be a solution, but I think it will make the load balancer less effective if you encounter heavy load a some point.

No worries, it happens! Glad you found the problem

@acebmxer I’m sorry to say that if those Dells are at your workplace, the wrong edition of iDRAC was purchased. You see with at the very least iDRAC 9 access to the full granular IPMI sensor data, was placed behind an edition paywall by Dell Technologies. Outlet temperature is just one of the feeds, missing from the Enterprise or lower edition of iDRAC 9. You’ll get the temperature readings from the Dell iDRAC web browser based interface, but not IPMI with iDRAC 9 Enterprise. To obtain the full IPMI sensor data you need the Datacenter edition.