Subcategories

  • VMs, hosts, pools, networks and all other usual management tasks.

    491 Topics
    4k Posts
    poddingueP
    I tried this on my lab (with XO 6.9.1), moving the pool master to the other host with xe pool-designate-new-master and then back. XO stayed connected both times and picked up the new master, even though Settings > Servers still showed the old host's address; on the way back it took a minute or two to catch up. I didn't test 6.2.2, and I used the CLI rather than the XO 5 Advanced tab, so my guess that your older version is the difference is only a guess. For the XVA, I'm not aware of release notes for the appliance image itself: it updates itself after import, and the notes that exist are per XO version, in the monthly blog post and the changelog, both linked from https://docs.xen-orchestra.com/getting-started/releases#release-cadence-and-channels . How often the downloadable XVA gets rebuilt I don't know, so the 2025.12 tag may just be the date of the base image, but I'd rather ask than guess.
  • ACLs, Self-service, Cloud-init, Load balancing...

    106 Topics
    870 Posts
    D
    I ran into the same problem with DR replicas. Ignoring VMs by tag would solve the problem, but so would excluding the ip address information.
  • All XO backup features: full and incremental, replication, mirrors...

    538 Topics
    6k Posts
    J
    Hi! We recieved a fix via the support after opening a ticket as suggested. Now the pool metadata backup is running smoothly again. As far as i know 6.9 will become "stable" after 6.10 is released. I'd still suggest a patch for the stable version, unless the new release is a few days. Best wishes Jacob
  • Everything related to Xen Orchestra's REST API

    88 Topics
    654 Posts
    poddingueP
    Pretty cool, @samuelolavo, thanks for clarifying!
  • Terraform, Packer or any tool to do IaC

    53 Topics
    492 Posts
    bvitnikB
    @bug-meister Ah. That's cloud-init's support for templating user-data. The issue is that with these templates you only have access to the info available inside the VM itself. No outside data can be used for templating unless it is somehow passed to the VM (inject a file, set xenstore values...)
  • πŸ›°οΈ XO 6: dedicated thread for all your feedback!

    Pinned
    279
    7 Votes
    279 Posts
    144k Views
    julienXOvatesJ
    @jacob.becker said: Hi! In XO-5 you can see clearly if a host is in maintenace mode" or not. I'm missing a similar thing to the little green/gray dot from XO-5 in the XO6 treeview. You can see it in the System- Tab under General Information, but only if the host is already selected. I personally find it difficult to distinct between hosts and VMs in the treeview if a large amount entries are shown. Especially while scrolling. Hi @jacob.becker, this is going to be fixed in XO 6.9 (ie. the Disable state for a host). I share your point of view about hosts & VM icons, we should also change them. Thanks !
  • XOA Unable to connect xo server every 30s

    Unsolved
    8
    0 Votes
    8 Posts
    1k Views
    G
    @john.c @poddingue I am very happy to report that I am no longer receiving the "XOA Unable to connect xo server every 30s" message on the Chrome browser of my Windows 11 PC, as of today, after updating the XO-CE VM and all xcp-ng hosts. I just updated the XO-CE VM to master, commit 70b08, and ran a rolling pool update of my 3 xcp-ng hosts. Thank you to the Vates team.
  • Bringing container visibility back to XO

    9
    1
    0 Votes
    9 Posts
    772 Views
    nathanael-hN
    Hello, I talked with colleagues, and the idea of sharing the docker socket from a VM to the XO VM would not be doable in the near future on XCP-ng 8.3 (ask @teddyastie if you want details, I remember only the conclusion ) So I took a shortcut - XO <--> Docker - and pushed a quick experimental branch on github, docker-experimental, https://github.com/vatesfr/xen-orchestra/tree/docker-experimental Warning, this is experimental. ( NOT PRODUCTION ready ) Key points: A container tab on each VM XO can connect to the VM via SSH, and reach the docker.sock SSH private key and passphrase are stored by XO in the same way as XCP-ng hosts credentials XO6 web UI and REST API No modification needed in XCP-ng dom0 No modification needed in the VMs with Docker Any docker root or rootless is expected to work (I didn't test rootless yet) It should also work with a Podman socket (I didn't test yet) Again, it is experimental DO NOT RUN IN PRODUCTION Here are a few screenshots: Containers tab when connected to the docker socket /home/nathanael/src/xen-orchestra/docker-prs/proof/6/shots-real/01-connected.png[image: 01-connected.jpeg] Same with side panel /home/nathanael/src/xen-orchestra/docker-prs/proof/6/shots-real/02-side-panel-logs.png[image: 02-side-panel-logs.jpeg] Actions possible, stop/start, pause, restart, delete container: /home/nathanael/src/xen-orchestra/docker-prs/proof/6/shots-real/03-actions-menu.png[image: 03-actions-menu.jpeg] Containers tab when no yet connected, with a form to fill: /home/nathanael/src/xen-orchestra/docker-prs/proof/6/shots-real/06-not-configured.png[image: 06-not-configured.jpeg] To use this, follow official installation from sources but use this experimental branch instead of master. Again, this is still experimental, comes with no official support. We'd be interested to here what you think of this
  • is Xo Proxy available in community version

    Unsolved
    21
    0 Votes
    21 Posts
    3k Views
    B
    @acebmxer that is awesome work! Looking forqard to duplicating your effort on Monday. Have an aqesome weekend!
  • Install XO from sources.

    45
    3 Votes
    45 Posts
    10k Views
    acebmxerA
    Update - changes are live in the dev branch now. So figured out the update / switching branches for the proxy by connecting the proxy to my xoa free account. That triggered the available update to next version. From there I found the command that needs to be ran on the proxy to switch back and forth... [image: Screenshot_20261009_143546.png] Latest branch [image: Screenshot_20261009_144414.png] stable branch [image: Screenshot_20261008_202716.png] Backup job ran sucessful. 2026-10-09T17_48_25.447Z - backup NG.txt After the proxy has been deployed... The proxy has been registered with your Xen Orchestra instance. You can manage it from the Xen Orchestra web interface. Next: register the proxy's updater and move it to the 'latest' channel. On the pool master (IP), set a password for the proxy's 'xoa' user (choose your own) and reboot the proxy VM: xe vm-param-set uuid=UUID xenstore-data:vm-data/system-account-xoa-password='<your password>' xe vm-reboot uuid=UUID SSH to the proxy as 'xoa' (IP) and run: sudo xoa-updater register - This registers it with your vates account. sudo xoa-updater configure-channel xo-proxy-appliance-latest - set to latest or stable sudo xoa-updater upgrade - This can be ran via the UI or this command. Both need to be done twice to do the upgrade and/or downgrade. register needs a free xen-orchestra.com account; see the README. And host connected via proxy. [image: Screenshot_20261009_150011.png]
  • Passing through Intel iGPU

    Unsolved
    3
    0 Votes
    3 Posts
    817 Views
    Y
    @jp13232 @peek have you tried following this: https://docs.xcp-ng.org/compute/#pci-passthrough ? Also, you can have a look there: https://xcp-ng.org/forum/topic/12523/igpu-pci-passthrough-new-experimental-packages-need-testers if you finally manage to do the passthrough but have "vbios issues" like explained in the thread.
  • Migrating an offline VM disk between two local SRs is slow

    Unsolved
    35
    1
    0 Votes
    35 Posts
    10k Views
    A
    Data point from a 2-host XCP-ng 8.3 pool that supports @tosh's diagnosis, plus a no-patch workaround that gave us ~2.7x until the TCP_NODELAY fix lands. Setup XCP-ng 8.3, xapi-core / vhd-tool 26.1.16-1.2.xcpng8.3, dom0 kernel 4.19.0+1 Two hosts, local ext SRs on NVMe (Samsung 970 EVO Plus / WD Red SN700) Dedicated migration network: 2.5 GbE (Intel i226-V, igc), MTU 9000, no errors Offline storage migration (halted VM, VM.migrate_send) of 2 VDIs (disk + snapshot), 16 GiB virtual / 7773 MiB allocated each; sparse_dd ... -prezeroed ... -dest-proto nbd over TLS Baseline (stock) 132 s per VDI, i.e. ~59 MiB/s on the wire, flat line, same in both directions Link at ~20 % of line rate, source SR read latency 0.3 ms, dom0 total <= 0.5 vCPU, no single dom0 vCPU above 0.08 (RRD, 60 s averages) Sending host with turbo or capped at 2.5 GHz gave the same 132 s, so not CPU-bound here Workaround: disable delayed ACKs on the receiver, only for the migration-network route # on the destination host; adapt prefix/dev/src to the output of: ip route show <migration-net> ip route change 10.10.10.0/24 dev xenbr1 proto kernel scope link src 10.10.10.1 quickack 1 With the receiver ACKing immediately, Nagle on the sender only waits one RTT instead of the ~40 ms delayed-ACK timer. Result (same VM, same direction, same data) stock quickack 1 on receiver per VDI 132 s / 132 s 50 s / 46 s throughput ~59 MiB/s ~155-169 MiB/s whole migration 4:50 2:00 dom0 on the receiver went up to ~1.1 vCPU total, still nothing saturated. Caveats One run per arm, one pool. I did not capture ss -ti during the runs, so the notsent:512 signature is inferred, not observed here. It does not address the reply gating @TeddyAstie described, it only removes the delayed-ACK half. Consistent with that, we land at ~2.7x, below the ~4.3x reported above for TCP_NODELAY (different rig, so not directly comparable). Not persistent: lost on reboot and when xapi re-plugs the PIF. We re-apply it from a small systemd unit at boot as a stopgap and will remove it once vhd-tool ships TCP_NODELAY. Scope is only connections routed via the migration network (storage and live migration). More ACK packets on that link, nothing else changes. Is there a PR or issue for the TCP_NODELAY patch in xapi-project/xen-api that we can follow? I could not find one.
  • XOA 6.9 Update

    9
    1 Votes
    9 Posts
    500 Views
    S
    @MathieuRA We reverted back to 6.8.2 for now. We can wait for patch, otherwise, I have opened a tunnel #38081.
  • 0 Votes
    1 Posts
    135 Views
    No one has replied
  • Troubleshooting "TCP: out of memory" - Possible memory leak?

    Unsolved
    14
    1
    0 Votes
    14 Posts
    959 Views
    poddingueP
    Forwarded to the right team, thanks!
  • XOA 5.110 - Import from VMWare shows "vddk:" without ok or checkmark status

    Unsolved
    22
    1
    0 Votes
    22 Posts
    4k Views
    J
    @olivierlambert said: Hi, It's nice to suggest something, but we can't communicate just today about it, but be assured that we have stuff in the pipes to answer exactly all of this Hello Olivier, Understood completely on the timingβ€”I appreciate that communications like this need to be perfectly aligned with the development cycle. It’s incredibly reassuring to hear that there is already a solution in the pipes! As someone who has been around the community since 2021, I’m more than happy to help keep the forum threads constructive and patient in the meantime. When the time comes, if you need any early testing, feedback, or GitHub contributions to help vet whatever you have planned, please feel free to loop me in. I’d be glad to help out. Looking forward to the announcement! Best, John
  • VDI migration SR selection broken?

    Unsolved
    4
    0 Votes
    4 Posts
    460 Views
    M
    @jacob.becker Hi Jacob, I made a fix and it should be available on the next release
  • (Windows) guest IPv6 address doesn't collapse zeroes -> Long IPv6 addresses

    Solved
    21
    1
    0 Votes
    21 Posts
    3k Views
    J
    I just did a quick test to check. And it does indeed seem that this (small) issue has now been resolved. Tested on Windows Server 25, Management agent 9.2.385-0. Cheers!
  • 0 Votes
    29 Posts
    5k Views
    A
    Apologies for the long silence on my end β€” real life got in the way and I couldn't dig into this for a while. Finally found the time now to go through it again properly, helped a lot by the details others have already posted here in the meantime. I don't think this adds a new root cause, but it does corroborate what @kagbasi-wgsdac described β€” same "mass collapse onto a single anchor UUID" pattern, and in my case too that anchor is a real, still-in-use base disk, not a dangling/non-existent OpaqueRef (referencing vatesfr/xen-orchestra#9578). Environment: 2-host pool, shared NFS SR, XO recently updated to the latest version (didn't change anything regarding this issue, as expected since it's XAPI-side). Ran a read-only xe vdi-list params=uuid,name-label,is-a-snapshot,snapshot-of,snapshot-time directly against the pool master. Result: 47 of 196 VDIs match the pattern (is-a-snapshot: false but snapshot-of populated). All 47 point to the exact same single anchor UUID β€” which resolves to one specific, actively-used base VDI, not a missing reference. snapshot-time on most affected VDIs is the epoch default (1970-01-01T00:00:00Z), but a handful show plausible real dates (e.g. late 2025 / early 2026) β€” suggesting those entries originally had a legitimate snapshot-of relationship that got overwritten by whatever corrupted the metadata. Currently-running VMs affected (100% of each VM's disks affected in every case): VM OS Disks Sizes VM-1 Windows Server 2016 1 50 GB VM-2 Windows Server 2016 3 50 / 200 / 450 GB VM-3 Windows Server 2019 3 100 / 100 / 100 GB VM-4 Windows 11 Pro 2 50 / 100 GB VM-5 (decommissioned) Windows Server 2016 2 100 / 50 GB VM-6 Ubuntu 24.04 2 10 / 10 GB VM-7 Ubuntu 24.04 2 10 / 10 GB VM-8 Windows Server 2025 3 25 / 25 / 64 GB VM-9 Ubuntu 24.04 2 10 / 10 GB On top of that, ~28 more affected VDIs are orphaned/unattached objects ("base copy" leftovers, old ISO references) β€” same pattern, no VBD attached. Not touching any of this (no snapshot-fixer.py, no manual vdi-param-set) given the risk of severing legitimate snapshot relationships that's already been flagged here. Happy to provide a full anonymized xe vdi-list dump if that's useful for tracking down the root cause. Big thanks to everyone who kept digging into this and shared their findings here β€” especially @kagbasi-wgsdac for the detailed write-up that pointed me in the right direction, and of course @poddingue and the whole Vates team for staying on top of this and keeping us updated despite no clear timeline yet. Really appreciate the effort that goes into this, especially for something as tricky as a metadata corruption bug across production pools. Kind Regards and thx again Alex
  • VDI export to VMDK results in a corrupted disk

    Solved
    15
    0 Votes
    15 Posts
    740 Views
    A
    @Emmanuel-V In my opinion, it would make more sense if a standalone disk exported in VMDK format were exported directly as monolithicSparse, so that it would not need to be converted. This makes more sense to me because when only the disk is exported, rather than the entire VM (OVA), it can be assumed that the disk will be attached directly to some VM.
  • XO NFS option sec=krb5p encrypted transport

    3
    0 Votes
    3 Posts
    226 Views
    BytevenidosB
    I do have active directory setup in my lab environment. I just need to set aside some time to try it out between two domain joined hosts. Thanks for trying that! That's some good debugging.
  • XCP Pulse collects XCP-ng and Xen Orchestra logs

    4
    3
    3 Votes
    4 Posts
    348 Views
    acebmxerA
    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
  • search for snapshots sorted by creation date

    Unsolved
    14
    0 Votes
    14 Posts
    3k Views
    fred-stoF
    @Danp said: I haven't seen a way to do this from within XO. However, you can gather the details using xe on the command line -- for i in `xe snapshot-list | grep uuid | awk '{print$5}'`; do export j=$(xe snapshot-param-get uuid=$i param-name=children); k=$(xe snapshot-param-get uuid=$i param-name=snapshot-time); echo "VM UUID: $j - Snapshot UUID: $i - Creation Time: $k"; done This doesn't sort the results, so you will need to do that in Excel or your favorite text editor. @Danp adding | sort -t: -k4 to your command will sort it by date. -t: set fields separator to : -k4 sort by 4th field
  • RPU issue

    3
    1
    0 Votes
    3 Posts
    318 Views
    M
    @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

    2
    0 Votes
    2 Posts
    221 Views
    poddingueP
    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.