Subcategories

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

    471 Topics
    4k Posts
    M
    Hello. Thank you for your input. I am aware, that this is more of a warning message, than a error. Iยดm just trying to figure out, what is my best way to go here. My plan was: Setup a repljob for the vm in a lets say hourly interval On the day of the migration, shutdown the vm and start the last replication manually Disable the cr job Start the replicated vm on the new pool, check it and if all is ok, use it as new vm, otherwise start the old vm. The documentation says "If you want to start a VM on your destination host without breaking the CR jobs". Tbh i dont care about breaking the job. If everything works fine, i dont need it anymore, if not, i can setup a new job pretty fast. I was just wondering, if the new vm will stay in "blocked mode" for ever. Kind regards
  • ACLs, Self-service, Cloud-init, Load balancing...

    104 Topics
    863 Posts
    laszlobortelL
    @florent Thanks for your reply! We have started to migrate thousands of VMs, so disk transfer speed is important for us.. We will also do our detailed tests soon with different threads setting and publish it here. I think threads=1 is a good and logical default, but not efficient. Others might complain if you set it to a higher value. Configuration option would be a real good solution.
  • All XO backup features: full and incremental, replication, mirrors...

    508 Topics
    5k Posts
    FagnerMoraesF
    @pierrebrunet Thanks.
  • Everything related to Xen Orchestra's REST API

    85 Topics
    642 Posts
    1
    @poddingue Confirmed working, thank you so much for the heads-up, this made my day! Got it wired into the n8n flow and it's running perfectly. One gotcha for anyone else landing here, name_description gets rejected with a 422 "excess property", it has to be nameDescription. Working body: { "nameDescription": "nginx, app-1, app-2 | 2026-06-01" }
  • Terraform, Packer or any tool to do IaC

    50 Topics
    470 Posts
    CyrilleC
    Kubernetes CSI Driver for XO new release v0.3.0 Stable CSI Volume Identity: This decouples Kubernetes volume identity from backend storage lifecycle events (e.g. VDI migration between Storage Repositories) Topology-Aware Volume Provisioning: Dynamic provisioning now supports topology-aware pool selection. ๏ธ Migration required from v0.2.0 to v0.3.0 Full release note: https://github.com/vatesfr/xenorchestra-csi-driver/releases/tag/v0.3.0
  • ๐Ÿ›ฐ๏ธ XO 6: dedicated thread for all your feedback!

    Pinned
    227
    7 Votes
    227 Posts
    43k Views
    N
    Afternoon, my session timed out and I do get the normal login page, but when I login I get this UiAlert Message: [image: 1779994906012-screenshot-from-2026-05-28-12-51-11.png] import{B as e,C as t,St as n,U as r,X as i,_ as a,g as o,h as s,m as c,t as l,x as u,xt as d}from"./_plugin-vue_export-helper-DqPMJZfB.js";import{n as f,t as p}from"./VtsIcon-BoVekVkM.js";import{t as m}from"./use-mapper-M_HHKN3j.js";import{t as h}from"./UiButtonIcon-Df9Z1TJo.js";var g={class:`content`},_={class:`alert typo-body-regular-small`},v={key:0},y=l(t({__name:`UiAlert`,props:{accent:{},close:{type:Boolean}},emits:[`close`],setup(t,{emit:l}){let y=l,b=i(),x=m(()=>t.accent,{info:`status:info-circle`,success:`status:success-circle`,warning:`status:warning-circle`,danger:`status:danger-circle`},`info`);return(i,l)=>(e(),a(`div`,{class:n([d(f)({accent:t.accent}),`ui-alert`])},[c(`div`,g,[u(p,{class:`information-icon`,name:d(x),size:`current`},null,8,[`name`]),c(`div`,_,[c(`div`,null,[r(i.$slots,`default`,{},void 0,!0)]),b.description?(e(),a(`div`,v,[r(i.$slots,`description`,{},void 0,!0)])):o(``,!0)]),t.close?(e(),s(h,{key:0,class:`close-button`,icon:`fa:xmark`,accent:`brand`,size:`small`,onClick:l[0]||=e=>y(`close`)})):o(``,!0)])],2))}}),[[`__scopeId`,`data-v-5b9f5cdd`]]);export{y as t}; ... and after back-paging, I was able to login normally.
  • Install XO from sources.

    27
    3 Votes
    27 Posts
    3k Views
    acebmxerA
    After building new xo with root and more testing, I have come to this conclusion... Both things are true, and they're in tension The official docs prefer non-root for the long-running service โ€” that's a least-privilege hardening recommendation for the daemon. Normal XO (UI, backups, hosts, VMs, NFS/CIFS remotes) works fine non-root. But several XO features assume root anyway. The ESXi/VMware import "install from source" buttons are hard-coded to refuse unless id -u == 0. You already hit this same pattern once before โ€” the credential-encryption/XenStore work (commit 5e8b7fd) existed precisely because non-root broke that too. So "everything fails non-root" isn't quite it โ€” what fails is the specific subset of features XO wrote assuming it runs as root. Each one needs a separate workaround. The import button is one that cannot be worked around for a non-root process: it's a uid check on the running daemon, full stop. The honest trade-off You can pick at most two of these three: Service runs non-root (docs' preference) In-app "install nbd from source" button works Script doesn't pre-install packages The button (#2) requires the daemon to be uid 0. So: Want the button to work โ†’ run that box as SERVICE_USER=root. Simplest, everything XO ships just works, zero manual steps. You give up the non-root hardening. Want to stay non-root โ†’ the button is permanently dead; the only way to get import working is the binaries being placed by root once (script or by hand). The binaries run fine as non-root โ€” only their installation needs root. My recommendation Use SERVICE_USER=root on this box. XO's own codebase keeps assuming root (import, and you already saw it with encryption/XenStore), so non-root is a recurring fight against upstream for marginal hardening. Root is fully supported, it's what the official XO appliance ships, and it makes the buttons you want work with no manual package steps. Keep non-root only if hardening that box is a hard requirement and you're fine never using the in-app import installer.
  • XO-6 Cannot connect to server over Unifi SD-WAN, XO-5 works well

    2
    0 Votes
    2 Posts
    20 Views
    olivierlambertO
    And how that change in architecture would disconnect you? Your SD-WAN is cutting the feed?
  • MTU change

    12
    0 Votes
    12 Posts
    7k Views
    bleaderB
    @Andrew I did suspect that would be sufficient, but we need to think at feature level, and as mentionned there is no such thing we could do "quickly" for linux and other OSes. I anyway did a brain dump of my investigation before posting my previous message and we do now have an entry in the roadmap for it, which was not the case previously.
  • 0 Votes
    20 Posts
    766 Views
    J
    @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.
  • 0 Votes
    15 Posts
    582 Views
    K
    Another confirmed data point, with package delta and the specific malformed field. Host: XCP-ng 8.3.0, xapi 26.1 (build 26.1.4), Xen 4.17.6-9. Setup: XO from sources (community). All VDIs vanished from the per-VM Disks tab (XO 5 and XO 6); xe and the SR Disks tab show them fine; VMs run normally. Trigger was the 8.3 host update + reboot this morning โ€” XO build unchanged since May 28, disks visible yesterday. Host update delta (today): all 26.1.3-1.10 โ†’ 26.1.4-3.1 (xapi-core, xenopsd, sm-cli, sm-fairlock, xapi-storage-script, vhd-tool, message-switch, etc.), plus sm 3.2.12-17.8 โ†’ 17.9 as an independent bump. The malformed field. An affected live OS disk (VM running): is-a-snapshot: false snapshot-of: <populated, points to another VDI> snapshot-time: <populated> A normal base VDI should have an empty snapshot-of. After the update, snapshot-of/snapshot-time are populated on real, non-snapshot base VDIs, and XO filters anything with a non-empty snapshot-of out of the per-VM Disks view โ€” which is the disappearance. The VDI that snapshot-of points to is a legitimate base image in my environment (a heavily-reused Win2022 build template with a large genuine snapshot/clone lineage), so I can't tell from the host side whether the parentage links themselves changed or only the snapshot-of on live VDI labeling did. Either way, the consumer-visible effect is the same. REST confirms: /rest/v0/vms/<uuid>/vdis โ†’ []; /rest/v0/vdis/<uuid> โ†’ "no such VDI" for the VBD's referenced UUID, while xe vdi-list shows it. Caution for others: since live disks now carry snapshot-like metadata, be careful with Health-dashboard "orphan" cleanup and snapshot deletion on affected VMs until this is understood. Workaround that restored the per-VM Disks view: snapshot โ†’ revert โ†’ delete-snapshot (tested on a powered-off VM, immediate). Happy to provide more diagnostics. Quick Follow-up: Additional symptom, same root cause: ISO-SR VDIs are also affected. Pre-existing ISOs disappeared from the XO ISO picker (only ISOs uploaded after the patch still show). An affected ISO's vdi-param-list shows: is-a-snapshot: false snapshot-of: 937c3945-... (same anchor UUID as an affected VM disk on a different SR) snapshot-time: 19700101T00:00:00Z (Unix epoch โ€” clearly synthetic) Notably the spurious snapshot-of on both an ISO VDI and an unrelated VM OS disk points to the same anchor UUID, with an epoch timestamp โ€” so this looks like the update is stamping pre-existing VDIs with a bogus snapshot-of rather than any real lineage. VHD chains/GC are clean (GC reports no work).
  • Disaster Recovery Backup - how to restore?

    16
    0 Votes
    16 Posts
    5k Views
    olivierlambertO
    It hurts (4y ) but I'm glad we finally managed to get what you needed!! Thanks for posting a comment in here after all this time [image: 1779991585587-21cd8648-f61e-46d9-a52f-4ec55a7b7c8b-image.jpeg]
  • Some dashboard loading issues with v6

    Solved
    27
    5
    0 Votes
    27 Posts
    1k Views
    acebmxerA
    @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.
  • XOA - Memory Usage

    48
    2
    0 Votes
    48 Posts
    4k Views
    acebmxerA
    @florent said: @acebmxer back to work thank you for yor patience and help on this. I feel that it's not the same issue , with abrupt increase W will try our best to also fix this one Yes i replied to ticket also.... Yes you can do what is needed to XOA. Just looked at memory and it dropped.... [image: 1779875710969-screenshot_20260527_055458.png]
  • XO Console: Modifier keys stuck, unable to enter passwords

    14
    0 Votes
    14 Posts
    2k Views
    poddingueP
    Thanks for the clarification, @dsmteam !
  • Edit a Bond to Remove a NIC?

    2
    0 Votes
    2 Posts
    107 Views
    poddingueP
    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.
  • Xen Orchestra has stopped updating commits

    34
    0 Votes
    34 Posts
    10k Views
    florentF
    @ducatijosh did you do a yarn build ?
  • 0 Votes
    4 Posts
    211 Views
    K
    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.
  • Default console username and password on XOA Appliance

    Solved
    12
    0 Votes
    12 Posts
    30k Views
    olivierlambertO
    Hi, See https://docs.xen-orchestra.com/troubleshooting#recover-web-login-password
  • XOA Unable to connect xo server every 30s

    4
    0 Votes
    4 Posts
    341 Views
    poddingueP
    Good news, or at least, that's my understanding. This was a known bug and it's fixed in XO 6.4 (released April 29, PR #9681). Upgrading should make those alerts disappear for good. Thanks for the video, it made the report unambiguous.
  • Building from source, now introduces local changes in typed-router.d.ts?

    Solved
    11
    0 Votes
    11 Posts
    537 Views
    J
    @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! Elise-FZI opened this pull request in vatesfr/xen-orchestra closed fix(xo6): remove dev routes from prod #9787
  • load-balancer : Affinity to Host groups

    6
    0 Votes
    6 Posts
    457 Views
    Mitchel-APDM
    @olivierlambert In my understanding, Anti affinity tags only looks for the tags that are attached to the VM. For example: Datacenter 1 Host 1 VM1-1 Host 2 VM1-2 Datacenter 2 Host 3 VM2-1 Host 4 VM2-2 VM1-1 and VM1-2 should be able to migrate to Host 1 and Host 2. VM2-1 and VM2-2 should be able to migrate to Host 3 and Host 4. But VM1-1 and VM1-2 should never be able to migrate to Host 3 and Host 4. VM2-1 and VM2-2 should never be able to migrate to Host 1 and Host 2. With the current (Anti) Affinity tags, it will only look to the tags attached to the VM, so in the example it would be possible for VM1-1 to go to Host 4, if VM2-2 would be at Host 3 together with VM2-1. But if we could tag the hosts, it would not be possible for VM1-1 and VM1-2 to be on Host 3 and Host 4
  • Lost connection to ISO Repository

    10
    2
    0 Votes
    10 Posts
    564 Views
    A
    @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.
  • Managing vAPPs with XOA

    11
    0 Votes
    11 Posts
    3k Views
    G
    @olivierlambert +1 For creating vApps GUI in XO Reason: I recently had this configuration: VM1 - Delay 90 Seconds VM2 - Delay 100 Seconds VM3 - Delay 0 Seconds The VM3 instead of starting first, always starts last without fail. One difference I noticed is that VM3 is UEFI vs VM1 & 2 being in BIOS mode. I read elsewhere in the forum that vApps is the only reliable way to have an order. Maybe if we can somehow ensure that delay works, vApps will become less significant ?
  • Ignition and creating a SUSE MicroOS VM

    11
    0 Votes
    11 Posts
    4k Views
    G
    @Bytevenidos That's an interesting way of doing this, I'll have to remember it. I think the Fuel Ignition tool has a vhd output, it also produces both ignition and combustion parts for you. Worked pretty good on one test machine, but I need to go deeper into some of the other choices you can type in.