XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login
    1. Home
    2. Popular
    Log in to post
    • All Time
    • Day
    • Week
    • Month
    • All Topics
    • New Topics
    • Watched Topics
    • Unreplied Topics

    • All categories
    • stormiS

      XCP-ng 8.3 updates announcements and testing

      Watching Ignoring Scheduled Pinned Locked Moved News
      673
      1 Votes
      673 Posts
      578k Views
      acebmxerA
      1 out of 3 pools at work failed rolling pool update. When I try to put host 2 into maintence mode to finish updates i get this error... Support Ticket - Ticket#7763405 host.setMaintenanceMode { "id": "60701efd-089c-4822-97c0-1a1057f3f9aa", "maintenance": true } { "code": "VM_REQUIRES_SR", "params": [ "OpaqueRef:841e7606-d545-cb71-f67c-e48b5114a1e8", "OpaqueRef:0f356ee4-62f7-9608-8be5-df68d9a5cbb2" ], "task": { "uuid": "a24f5565-b2cb-f392-8095-1beceb7a4a17", "name_label": "Async.host.evacuate", "name_description": "", "allowed_operations": [], "current_operations": {}, "created": "20260828T19:57:29Z", "finished": "20260828T19:57:29Z", "status": "failure", "resident_on": "OpaqueRef:43c121e7-4ba4-193b-1e41-08c0f7e15690", "progress": 1, "type": "<none/>", "result": "", "error_info": [ "VM_REQUIRES_SR", "OpaqueRef:841e7606-d545-cb71-f67c-e48b5114a1e8", "OpaqueRef:0f356ee4-62f7-9608-8be5-df68d9a5cbb2" ], "other_config": {}, "subtask_of": "OpaqueRef:NULL", "subtasks": [], "backtrace": "(((process xapi)(filename ocaml/xapi/xapi_host.ml)(line 629))((process xapi)(filename hashtbl.ml)(line 159))((process xapi)(filename hashtbl.ml)(line 165))((process xapi)(filename hashtbl.ml)(line 170))((process xapi)(filename ocaml/xapi/xapi_host.ml)(line 625))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 39))((process xapi)(filename ocaml/xapi/rbac.ml)(line 228))((process xapi)(filename ocaml/xapi/rbac.ml)(line 238))((process xapi)(filename ocaml/xapi/server_helpers.ml)(line 78)))" }, "message": "VM_REQUIRES_SR(OpaqueRef:841e7606-d545-cb71-f67c-e48b5114a1e8, OpaqueRef:0f356ee4-62f7-9608-8be5-df68d9a5cbb2)", "name": "XapiError", "stack": "XapiError: VM_REQUIRES_SR(OpaqueRef:841e7606-d545-cb71-f67c-e48b5114a1e8, OpaqueRef:0f356ee4-62f7-9608-8be5-df68d9a5cbb2) at Function.wrap (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/_XapiError.mjs:16:12) at default (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/_getTaskResult.mjs:13:29) at Xapi._addRecordToCache (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/index.mjs:1229:24) at file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/index.mjs:1263:14 at Array.forEach (<anonymous>) at Xapi._processEvents (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/index.mjs:1253:12) at Xapi._watchEvents (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/index.mjs:1460:14)" } SR are not connected to master host after reboot from updates. When try to connect them i get error... [image: 1787947508872-screenshot-2026-08-28-160401.png] pbd.connect { "id": "e96ec5d8-c70f-c877-4263-f2cf763e7048" } { "code": "SR_BACKEND_FAILURE_108", "params": [ "", "Unable to detect an NFS service on this target.", "" ], "task": { "uuid": "5574bfe5-1874-35f8-f53b-c9fc1abaebb5", "name_label": "Async.PBD.plug", "name_description": "", "allowed_operations": [], "current_operations": {}, "created": "20260828T20:03:19Z", "finished": "20260828T20:03:22Z", "status": "failure", "resident_on": "OpaqueRef:43c121e7-4ba4-193b-1e41-08c0f7e15690", "progress": 1, "type": "<none/>", "result": "", "error_info": [ "SR_BACKEND_FAILURE_108", "", "Unable to detect an NFS service on this target.", "" ], "other_config": {}, "subtask_of": "OpaqueRef:NULL", "subtasks": [], "backtrace": "(((process xapi)(filename ocaml/xapi-idl/storage/storage_interface.ml)(line 455))((process xapi)(filename src/lib/idl.ml)(line 558))((process xapi)(filename ocaml/xapi/storage_utils.ml)(line 148))((process xapi)(filename lib/backtrace.ml)(line 251))((process xapi)(filename ocaml/xapi/xapi_pbd.ml)(line 196))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 141))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 39))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 6061))((process xapi)(filename ocaml/xapi/rbac.ml)(line 228))((process xapi)(filename ocaml/xapi/rbac.ml)(line 238))((process xapi)(filename ocaml/xapi/server_helpers.ml)(line 78)))" }, "message": "SR_BACKEND_FAILURE_108(, Unable to detect an NFS service on this target., )", "name": "XapiError", "stack": "XapiError: SR_BACKEND_FAILURE_108(, Unable to detect an NFS service on this target., ) at Function.wrap (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/_XapiError.mjs:16:12) at default (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/_getTaskResult.mjs:13:29) at Xapi._addRecordToCache (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/index.mjs:1229:24) at file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/index.mjs:1263:14 at Array.forEach (<anonymous>) at Xapi._processEvents (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/index.mjs:1253:12) at Xapi._watchEvents (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/index.mjs:1460:14)" } Update - bad port on switch....... Update 2 - After updating synology to latest version i am no longer able to mount nfs 4.1 shares. I can not create one using 4.1. I will let me create with 4.0 not 4.1 How to remount NFS that were mounted as 4.1 now as 4.0? ALl VMS down at this location currently. Update 3 - Resolved... Synology update broke NFS 4.1. I had to ssh into synology and edit /etc/nfs/syno_nfs_conf and add nfs_minor_ver_enable=1 Now SR's mounted. Update 4 - Found Patch notes about NFS version change. - Version: 7.0.1-42218 NFSv4.1 and related advanced functions (multipathing) are no longer supported on Synology NAS models with the following package architectures: Alpine, Alpine4k, armada38x, Avoton, Braswell, Bromolow, Cedarview, Grantley, Monaco. If you had previously enabled NFSv4 and NFSv4.1, the maximum NFS protocol is set to NFSv4 by default after the update. For more information about the package architecture of your model, please refer to this article. Our unit - RS1219+ Intel Atom C2538 Avoton
    • CyrilleC

      Xen Orchestra Container Storage Interface (CSI) for Kubernetes

      Watching Ignoring Scheduled Pinned Locked Moved Infrastructure as Code
      29
      5 Votes
      29 Posts
      4k Views
      K
      @Cyrille We can't disable the embedded CCM. Disabling the embedded CCM in RKE2 impacts core cluster bootstrap behavior because it is a bootstrap-critical component responsible for core node lifecycle management.
    • A

      Backup fails with "Body Timeout Error", "all targets have failed, step: writer.run()"

      Watching Ignoring Scheduled Pinned Locked Moved Unsolved Backup
      105
      0 Votes
      105 Posts
      13k Views
      J
      @christopher-petzel Ok! Thanks!
    • D

      XCP-ng Windows PV tools announcements

      Watching Ignoring Scheduled Pinned Locked Moved News
      110
      0 Votes
      110 Posts
      35k Views
      A
      @dinhngtu Something called "Elpha Secure" ...none of our other antivirus shows it being bad but I wanted to ask around before I unflagged it.
    • H

      XCP-NG 9.0 Support for GRAID Tech GPU-accelerated RAID cards.

      Watching Ignoring Scheduled Pinned Locked Moved Development
      5
      1 Votes
      5 Posts
      211 Views
      H
      @teddyastie This is exactly the answer I was hoping for, including the parts telling me I was wrong. Thank you. Context for why I'm chasing this: with GRAID's cards, the value isn't headline throughput — it's that parity doesn't land on the host CPU. On a hypervisor that matters more than on bare metal, since cycles spent on parity are cycles unavailable to guests. I have nodes with lower base clocks where that hurts, and md's RAID5/6 path doesn't parallelise well enough to compensate with core count. Decoupling storage compute from guest compute is the whole objective. Scope note I should have led with: I don't need to boot from any of this. Dom0 can boot from a plain mirrored pair or a SATA DOM. What I need is performant data storage for guests. That drops the UEFI pre-boot and installer-visibility requirements from the VROC side, and makes storage-domain boot ordering much less severe — nothing critical is waiting on it. Taking the P2P correction. I had that as make-or-break and framed it as unfixable. If it's an ACS/platform question rather than a hypervisor one, and you've had it working between a PCI card and NVMe drives, that removes what worried me most. I'll ask Graid whether their data path ever targets BAR regions containing MSI-X tables or the PBA. Noted on custom software in Dom0, which also lands on the VROC track I'd been treating as the cheap half — I'd listed mdadm with IMSM without checking whether that's a Dom0 package change or already present. The XSM finding I ran the XSM check before any build work and hit something worth raising. This is 8.3: (XEN) XSM Framework v1.0.1 initialized (XEN) Initialising XSM SILO mode # xl getenforce Flask XSM Disabled SILO enforces that DomUs communicate only with Dom0, not with each other — no grants, no event channels between unprivileged domains. A storage driver domain is a DomU, a guest consuming its storage is a DomU, and blkback to blkfront needs grants plus an interdomain event channel with Dom0 at neither end. Unless I'm misreading silo_mode_dom_check, that's exactly what SILO denies. Which might also explain the hardcoded ssidref you queried on the PR. FLASK ships driver domain labels in its default policy; we're not running FLASK. The question is whether 9.0 keeps SILO as the default, since that's what I want to build against. I'm installing 9.0 on a bare node tonight and will post the actual output rather than leave it hypothetical. If it's still SILO, the same wall is there. Either way: can a driver domain be privileged enough to pass is_control_domain() without defeating the isolation it exists to provide, and has SILO gained driver-domain handling upstream since it landed? I'd rather be wrong about this than right. The driver domain changed my plan Mark Syms' motivation comment on #7169 describes my situation almost word for word — taking something generically available as a Linux appliance and letting it serve storage without rebuilding drivers into XenServer/XCP-ng. Graid's driver 2.0.1 already lists AlmaLinux 10.0–10.2 on kernel 6.12 as qualified. In a storage driver domain that's their existing build, unmodified: no out-of-tree module in Dom0, so no module policy question, no proprietary-vs-GPL argument, no SecureBoot complication, and none of the rebuild-per-kernel-update maintenance which I suspect was the real objection. It also gets its own vCPU allocation and can be pinned to the socket owning the PCIe root complex where the card and drives live — something Dom0 can't give me. So rather than backporting to 8.3, I'd rather build against 9.0 and carry the patch there, where xapi should sit much closer to master. Correction to my own earlier post: I said GRAID needs no SMAPI work because a virtual drive is just a local block device. True for an LVM SR in Dom0, not here — Mark is explicit that the driver domain implementation must satisfy the Storage API, and recommends SMAPIv3. With @dicode-nl having just published a working SMAPIv3 volume and datapath plugin that's tractable, but it isn't free and I shouldn't have implied otherwise. Where this leads Your mentioning storage domains sent me back to something I'd half-remembered: https://xcp-ng.org/blog/2021/07/12/dpus-and-the-future-of-virtualization/ Olivier's argument there was that offloading pre-existing software outside Dom0 — storage stack included — also shrinks Dom0's attack surface, ending with storage and networking configured through the DPU from XO while getting bare-metal performance. He signed off promising a follow-up devblog with tests and benchmarks, and I've never found where that went. It strikes me that #7169 is the missing piece. "Get the storage stack out of Dom0" needs a toolstack mechanism for serving storage from something that isn't Dom0. Once that contract exists, whether the provider is a VM on the same CPU or an Arm SoC on a card is an implementation detail. GRAID in a driver domain is the version buildable this year; a DPU-hosted provider is the same contract on different silicon. Which also answers @last-genius' concern on the PR that this would sit unused. It's the prerequisite for something Vates was publicly excited about five years ago. XCP-ng on a DPU is genuinely what I want at the end of all this. Questions Are 9.0 RPM sources and a build-env target public yet, or internal until an alpha? Would Vates consider carrying #7169 in the 9.0 line given it's upstream with two approvals, or is that a post-merge conversation? Has anyone measured blkback driver-domain overhead versus Dom0-native? That number decides whether any of this is worth pursuing. If nobody has, I'd like to produce it — I can test the plumbing with any passed-through NVMe drive, no GRAID hardware needed. On TwinStor: I suspect this doesn't compose the way I imagined, since TwinStor sits on a local block device in Dom0. Happy to hear it's a dead end now rather than later. Two bare nodes ready for 9.0 work, and I'm auditing spares for VMD-capable Xeons to see whether I can test the VROC track independently. Mike George Bitrefinery
    • B

      Native Ceph RBD SM driver for XCP-ng

      Watching Ignoring Scheduled Pinned Locked Moved Development
      29
      3 Votes
      29 Posts
      6k Views
      dicode-nlD
      @benapetr @olivierlambert I've made a new release which includes SMAPIv1 improvements and a proper SMAPIv3 volume + datapath plugin. https://github.com/dicode-nl/xcp-ng-ceph-rbd/releases#release-v20260827 Let me know your thoughts and if there is anything you'll like to see added / changed / tested. Next step for me is CBT and SXM.
    • P

      Suggestion: Restore VM Backup filter functionality when using jobs/sequences for backup

      Watching Ignoring Scheduled Pinned Locked Moved Backup
      5
      1
      0 Votes
      5 Posts
      144 Views
      P
      @poddingue said: I haven't used that tab myself, and since it's built around VMs that do have backups, I don't know if it gives you the negative view you want. If it doesn't, https://feedback.vates.tech is where that gets counted. Maybe you can build some sort of filter but I don't think so. I'll use https://feedback.vates.tech for future suggestions. Tks
    • C

      Bringing container visibility back to XO

      Watching Ignoring Scheduled Pinned Locked Moved Xen Orchestra
      6
      1
      0 Votes
      6 Posts
      266 Views
      poddingueP
      Nice, thanks for the feeder entry and the explanation, @CAPS!
    • olivierlambertO

      🛰️ XO 6: dedicated thread for all your feedback!

      Watching Ignoring Scheduled Pinned Locked Moved Xen Orchestra
      254
      7 Votes
      254 Posts
      113k Views
      poddingueP
      Thanks!
    • I

      Slow SR Creation

      Watching Ignoring Scheduled Pinned Locked Moved Unsolved Management
      4
      1
      0 Votes
      4 Posts
      205 Views
      poddingueP
      Thanks for the numbers. So the whole chain drags: 4 to 5 minutes to list the ~90 LUNs, another 1 to 3 to validate one, and the create on top of that. From the XO side I can't tell where that time goes, XO itself, the host's storage layer, or the array answering slowly, and the one measurement that would split it is the host-side probe I mentioned: time xe sr-probe type=lvmoiscsi device-config:target=<ip>, then the same call with device-config:targetIQN=<iqn> added. If the CLI takes just as long, XO is mostly off the hook. A 90-LUN multipath target doesn't sound exotic to me, so probes taking minutes feel worth a proper look, though I honestly don't know what's normal at that scale. @Team-Storage, the numbers above are concrete now, in case it's worth a look on your side.
    • M

      RPU issue

      Watching Ignoring Scheduled Pinned Locked Moved Xen Orchestra
      3
      1
      0 Votes
      3 Posts
      73 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
    • acebmxerA

      VM Display Resolution

      Watching Ignoring Scheduled Pinned Locked Moved XCP-ng
      3
      0 Votes
      3 Posts
      106 Views
      poddingueP
      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.
    • K

      Intermittent Xen blkfront I/O stalls: all guest tags busy while tapdisk reports zero outstanding requests

      Watching Ignoring Scheduled Pinned Locked Moved Unsolved Compute
      16
      0 Votes
      16 Posts
      985 Views
      A
      @mike.potapov Can you upgrade to the latest blktap-3.55.5-9.3.xcpng8.3 to check is the issue is still there?
    • ForzaF

      Migrating an offline VM disk between two local SRs is slow

      Watching Ignoring Scheduled Pinned Locked Moved Xen Orchestra
      24
      1
      0 Votes
      24 Posts
      7k Views
      olivierlambertO
      Worth mentioning @Team-Storage
    • olivierlambertO

      DevOps Megathread: what you need and how we can help!

      Watching Ignoring Scheduled Pinned Locked Moved Infrastructure as Code
      68
      4 Votes
      68 Posts
      29k Views
      JeremyLARDENOISJ
      New releases ! CSI v1.0.0-rc.1 This is the first release candidate for v1.0.0. We're looking for feedback and real-world testing before the final release. What's new: Split controller/node modes — nodes no longer hold Xen Orchestra credentials SR selection & live volume migration via VolumeAttributesClass A proper XO client timeout flag A brand-new Helm chart, with component toggles and provisioning tests https://github.com/vatesfr/xenorchestra-csi-driver/releases/tag/v1.0.0-rc.1 CCM v1.1.2 The Helm chart can now be configured to disable Role and RoleBinding creation, making it easier to integrate into environments where RBAC resources are managed separately. We've also bumped dependencies, including CI tooling and go-xo-sdk. https://github.com/vatesfr/xenorchestra-cloud-controller-manager/releases/tag/v1.1.2
    • O

      Remote desktop on Gnome hangs randomly

      Watching Ignoring Scheduled Pinned Locked Moved Unsolved Hardware
      14
      0 Votes
      14 Posts
      2k Views
      O
      @dinhngtu Hello. I've updated to the latest commit. There is no need to give me credit. I just want to help so others and myself included can benefit from this. Anyway thank you for your work.
    • P

      Error mirroring full backups to backblaze b2

      Watching Ignoring Scheduled Pinned Locked Moved Solved Backup
      33
      2
      0 Votes
      33 Posts
      4k Views
      poddingueP
      Thanks a lot for this feedback, @pedro!
    • T

      Openmetrics plugin changing Prometheus secret after every xo-server restart

      Watching Ignoring Scheduled Pinned Locked Moved Unsolved Advanced features
      4
      0 Votes
      4 Posts
      281 Views
      T
      @mpiton Thanks for looking into this, I guess it wasn't apparent that I needed to click the Save Configuration button for that plugin. I did that and confirmed that the secret now survives an xo-server restart. Thanks again!
    • M

      Feature request: Change bond mode in XO

      Watching Ignoring Scheduled Pinned Locked Moved Xen Orchestra
      2
      0 Votes
      2 Posts
      110 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.
    • M

      Support for newer Emulex LPe37xxx amd LPe36xxx Fiber channel adapters on XCP-ng 8.3 - your testing is needed

      Watching Ignoring Scheduled Pinned Locked Moved Hardware
      2
      2 Votes
      2 Posts
      78 Views
      poddingueP
      I went digging and three threads turned up people who already have this hardware. @yeopil21 in https://xcp-ng.org/forum/topic/11799 had an LPe37102-D on a Dell R770 that never showed up at all, @jinju0504 in https://xcp-ng.org/forum/topic/11946 ended up on the -alt package on an R670, and @lukas in https://xcp-ng.org/forum/topic/8847 was running an LPe31002-M6-D with NVMe-oF back on 8.3 beta2. That last one is the older generation, so I'd guess it's the side where you most want to hear nothing regressed. Tagging them in case the cards are still on their benches.