Xen Orchestra

XCP Pulse collects XCP-ng and Xen Orchestra logs

acebmxer — Mon, 07 Sep 2026 13:23:06 GMT

v0.6.0 — log collection is in. This was the piece the first post said was next, and it works end to end now. A new Collect page runs a per-host collection as a background job: it pulls logs.tgz and the XAPI audit trail from Xen Orchestra, keeps the raw copies, and produces a redacted copy of each. On my own XCP-ng 8.3 pool that came to 434 MiB for the bundle and 769 MiB for the audit trail, 2.3 GiB stored across the five files, with 2,542,805 values masked — almost all of them session tokens. The download is streamed a megabyte at a time and never held in memory, and every chunk is a cancellation point, so Cancel actually stops a transfer rather than waiting it out. A failed or cancelled download deletes its partial file instead of leaving a half-written bundle sitting there looking like a collection. Both copies are kept and marked redacted — safe to send or raw — unmasked. Redaction is lossy, and the raw copy is the only thing that can answer "what did that used to say?" afterwards. Each collection writes the same redaction report the preview page produces, so you can see which rules fired — and which were switched off — before anything leaves the box. In the screenshot I had IPv4, MAC, UUIDs and hostnames turned off, and they show as off rather than as zero hits. That is deliberate: a partly-masked bundle should be obvious before you attach it to a ticket. There is also a retention policy. The newest n collections are kept whatever their age, and only what is left is judged on age — a long gap in collecting can't empty the store. It shows you what a cleanup would delete and how much space that returns before you press the button. Expect bugs. This is still very much a work in progress and it has only ever run against my own pool. If you try it in a different environment, assume things will break — please tell me what did. Known issues right now: The red "This connection uses a restricted account" warning on the Collect page shows for every connection, including an administrator one. It is a wrong condition in the template, not a real permission check — ignore it if your account is admin. The screenshot below has it, over a collection that succeeded. The Collect page says to expect "433 MB and 100 seconds per host". The 100 seconds is the download only; a full collection also fetches the audit trail and redacts both copies, which took 203 seconds on my pool. Budget three to four minutes. Two more things worth flagging if you try this. logs.tgz sends no Content-Length, so a reverse proxy that buffers will happily hand you a truncated archive with HTTP 200. Mine did. It now detects that and reports the bundle as cut short rather than as a protocol error, and repacks whatever did arrive instead of throwing the lot away. If you are behind Nginx Proxy Manager, proxy_buffering off; and proxy_max_temp_file_size 0; are what fixed the stall for me. The account requirement from the first post has not changed — the log download needs export:logs on host, and on the instance I measured that is only reachable via Administrator. Inventory still works fine on Read only. Next up: individual log categories pulled out of the cached bundle (~35 MB instead of 434 MiB), date ranges, and then findings. https://github.com/acebmxer/xcp_pulse [image: 1788812029125-screenshot_20260907_160937.png]

Troubleshooting "TCP: out of memory" - Possible memory leak?

jr-m4 — Fri, 04 Sep 2026 08:49:32 GMT

@florent said: @jr-m4 you can export the heap memory of the nodeJS process by doing kill -SIGUSER2 onte that this will increase a lot the memory consumed by the xo process even when its done exporting the memory . This will help us know what xo is doing at the moment Do you have somewhere I can upload the heapsnapshot? (148MB) Ping @poddingue as well, for visibility

RPU issue

manilx — Fri, 28 Aug 2026 08:04:13 GMT

@poddingue You're right. The RPU task shown in the list was a previous one. Even that one finished fine. So both RPU tasks didn't show at all today! My bad. The evacuation and remirroring tasks were all shown. Latest XOA 6.7.1

Feature request: Change bond mode in XO

poddingue — Sun, 23 Aug 2026 20:03:01 GMT

I measured this on a two-NIC 8.3 host. As far as I understand, there's no way to do it from XO: the call that edits a network doesn't take a bond mode, every bondMode in the codebase sits on a create path, and the REST API on a running XOA offers create_bonded_network plus get and delete on a network, with nothing that edits one. The CLI route looks cheap though. xe bond-set-mode on a live bond cost zero dropped packets in both directions I tried, pinging every 200ms across the change, and the command returned in about 1.4 seconds. Two caveats, and the second is about your case specifically: creating and destroying the bond did interrupt the host (roughly 8 and 16 seconds), and I only went active-backup to balance-slb and back, never touching lacp, because my switch port isn't configured as a LAG and I'd have dropped the box. So I can't tell you your lacp to active-backup move is free, only that mode changes in general didn't cost me anything. Worth putting on https://feedback.vates.tech either way so the votes have somewhere to gather.

Bringing container visibility back to XO

nathanael-h — Wed, 19 Aug 2026 14:41:23 GMT

Hello there, Thanks a lot for raising the question and offering ideas to move forward @caps ! I would like to say that I really like the AI crafted screenshot provided 🤩 But, to be clear, the status as of today regarding Docker or other containers integration in XO/XCP-ng is that there is an item in the DevOps Tools team roadmap. The item is just to look and define what could be done (example update xscontainer, do something totally new, ...). Unfortunately this spike has a low priority and is not yet scheduled. That being said, there is an active project, which is close to what you're asking. It's about a better integration of Kubernetes, including, cluster update, adding nodes, etc. More on this should come in the next months! ️ Also note that I am chatting with different people and teams in Vates about this thread and the Docker integration topic to see if we could do something. Also last thing is that, the community is always welcome to build on top of our open source softwares. I am pretty sure that if someone would contribute a Xen Orchestra plugin to integrate Docker we would welcome this, and we could give tips and guidance. Like @teddyastie said, I'm not sure having Docker, Podman, related features in the guest agent would be something our colleagues would merge. But maybe the docker daemon socket could be kind of shared between VMs (I'm not sure at all this is possible and if possible how to do it). In the meantime exposing the docker daemon over network (with restrictions) to Xen Orchestra would be quick'n easy and I think safe enough if done carefully.

VDI migration SR selection broken?

poddingue — Tue, 11 Aug 2026 09:58:32 GMT

If the list is only complete after you've been through the Storage view first, that smells like the VM view not loading the whole SR collection, so the dialog only knows about the SR the disk already sits on. I could easily be wrong about the mechanism though. 6.7.0 went out on 30 July, so it would help to know whether it still does this there, and whether anyone else on 6.6.2 sees the same thing. Might be worth a mention to @Team-XO-Frontend, since they'd know straight away whether that dropdown is meant to come from a shared collection or get fetched per view. The nearest thing I found in the tracker is https://github.com/vatesfr/xen-orchestra/issues/7392, but that one is ISO SRs turning up in the wrong list rather than SRs going missing, so probably not the same thing.

Facing some issue in copy Function of Xen Orchestra

AtaxyaNetwork — Thu, 06 Aug 2026 13:05:44 GMT

@irtaza9 i would look a the usual suspect, /var/log/SMlog /var/log/xensource.log see https://docs.xcp-ng.org/troubleshooting/

Deploy VM via cloud-init config

MathieuRA — Wed, 29 Jul 2026 14:23:49 GMT

@acebmxer Thank you for your quick feedback.

Unable to fetch latest master commit.

TS79 — Thu, 23 Jul 2026 09:56:58 GMT

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

v6 UI VDI's not being shown all the time.

poddingue — Wed, 15 Jul 2026 11:43:00 GMT

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

Xenorchestra V6 issue

pdonias — Wed, 15 Jul 2026 08:22:04 GMT

@acebmxer I can confirm that, we'll fix it, thanks

xo-apply — configuration-as-code for Xen Orchestra (looking for feedback & testers)

acebmxer — Sat, 04 Jul 2026 14:06:35 GMT

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]

VDI_IO_ERROR(Device I/O errors) Immediate HELP needed Please.

poddingue — Wed, 01 Jul 2026 18:16:54 GMT

You may have worked it out yourself already. A consistency check reporting inconsistent parity on Virtual Disk 1, plus Buffer I/O error on several dm- devices, is the storage layer underneath XCP-ng telling you something is wrong down there. The VDI_IO_ERROR is mostly XCP-ng saying it could not read the disk, not the cause itself. I would be careful about anything that writes to that array until someone who knows hardware RAID recovery better than I do has looked at it. I honestly don't know whether a rebuild helps or makes things worse from this state, and I'd rather say that than guess with your data. Might be worth a mention to @Team-Storage.

v6 left navigation bar

olivierlambert — Tue, 30 Jun 2026 15:21:09 GMT

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

XOA Updater fails

andibing — Sun, 28 Jun 2026 20:46:22 GMT

@john.c said: nd need to be cleared, before re-attempting the update. Checking the logs will help Just for completeness... it kept doing this after all the typical diagnosis steps. So never found a solution Definitely wasn't cache or disc space related. In the end I built the XOA from source on the same VM and that worked fine. Although subsequent to that I've moved XOA to the containerised version thus saving an extra VM!.

Netbox sync and empty virtual disks

bjdemon — Thu, 25 Jun 2026 12:06:13 GMT

@poddingue Thanks for the reply. I have been checking the source code of the Netbox plugin over the weekend and added the necessary code to enable the virtual disk sync. In Netbox itself, you do need to add the correct permission for it to work. Will do some more testing during the week, and create a pull-request once I'm satisfied with the result. Up to the Vates if they want to merge it into the main branch. Thank you for your reply!

xo-server executable not found

EddieA — Wed, 10 Jun 2026 00:17:29 GMT

@poddingue said: usually looks like an update that got interrupted or only half-applied Thinking back on it, I think that may be the issue. in that I was too quick off the mark rebooting after the base upgrades. @poddingue said: I think the gentler recovery before rebuilding would have been re-running the updater from the CLI Kinda tried that, but: [18:47 09] xoa@xoa:~$ xoa check -bash: xoa: command not found [18:47 09] xoa@xoa:~$ sudo xoa-updater --upgrade [sudo] password for xoa: sudo: xoa-updater: command not found [18:48 09] xoa@xoa:~$ But regardless, I'm all good now. Cheers.

XO-6 Cannot connect to server over Unifi SD-WAN, XO-5 works well

olivierlambert — Wed, 03 Jun 2026 18:24:52 GMT

Maybe you can check for a bigger timeout on your UDM?

Edit a Bond to Remove a NIC?

poddingue — Sun, 17 May 2026 04:04:16 GMT

Take it with a grain of salt, but I think bonds are usually managed as a whole rather than edited port by port in the UI. As far as I can tell, the supported route is from the network section in Xen Orchestra (the bonding part of the infrastructure docs is here: https://docs.xen-orchestra.com/xo5/manage_infrastructure#network-bonding), and on the CLI side, the bond commands are documented at https://docs.xcp-ng.org/appendix/cli_reference#bond-create (there's a matching bond-destroy command alongside it). My honest guess is you may end up destroying and recreating the bond with the four ports you want to keep, since I'm not sure removing a single member in place is exposed anywhere, but I could easily be wrong. If there's a cleaner way that avoids the recreate, someone will let us know.

Some dashboard loading issues with v6

acebmxer — Thu, 14 May 2026 23:35:45 GMT

@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.

XenOrchestra not showing VM Disks on Pool (on single Server working) - XCP-ng Center is showing them

kagbasi-wgsdac — Thu, 07 May 2026 10:53:47 GMT

@poddingue I'm seeing a recurrence of the snapshot_of / hidden-disks issue after patching to xapi-26.1.16-1.2 (both hosts, rebooted). Unusual element this time: snapshot-fixer.py dry-run flags ~260 VDIs across the SR that all cite a single OpaqueRef which resolves to no VDI (xe vdi-list | grep returns nothing). Holding off on rewrite until I understand whether that single-dangling-ref pattern is safe, given the set appears to include base VDIs of legitimate snapshots. Full technical detail and questions posted on GitHub: https://github.com/xcp-ng/xcp/issues/844.

Unable to import Backup Config from Community Edition to XOA Deployed Appliance

Kraken89 — Tue, 05 May 2026 11:54:23 GMT

Ok I think I have resolved the issue. It appears that if you do not activate either a paid license or the trial, it fails with the import because many of the features are not active until you enable the license and then update the XOA appliance. Once I activated the trial and then updated the appliance again, I was able to successfully import the backup. My hesitation with activating the license before importing the config as the licenses are bound and I didn't want to have to redo the setup if the config did not import. Again, it looks like I need to activate the license first and then I can import the config.

(Windows) guest IPv6 address doesn't collapse zeroes -> Long IPv6 addresses

jr-m4 — Tue, 05 May 2026 07:40:25 GMT

@dinhngtu said: I've taken a quick look, looks like it'll be solved as part of the Windows guest agent overhaul, so please look forward to that. Thanks for the info. I will be looking forward to that, indeed.

Building from source, now introduces local changes in typed-router.d.ts?

jr-m4 — Wed, 29 Apr 2026 07:56:17 GMT

@MathieuRA I noticed you merged https://github.com/vatesfr/xen-orchestra/pull/9787 I just tried it. And it does seem to fix my original issue! Thank you! I am always impressed by you guys. Making testing and reporting upstream (to you guys) a good experience!

Lost connection to ISO Repository

ashinobi — Tue, 21 Apr 2026 13:36:27 GMT

@Pilow Apologies for the late reply. Thank you for sharing the work around. I have tried it and confirmed that the work around works. I hope they can find a solution for this issue.