1. Home
  2. Popular
Log in to post
  • A

    XO error/warning: Clean VM directory. unhandled error while checking alias.

    Backup
    15
    1
    0 Votes
    15 Posts
    166 Views
    P
    @Andrew The warning may still appear indeed but I think it is another issue or maybe a good warning to check your backups. Can you provide the new logs please?
  • DAYELAD

    XOA loses connection to hosts during VM migration / creation on XOSTOR SR

    XOSTOR
    6
    0 Votes
    6 Posts
    218 Views
    olivierlambertO
    Please disable HA and report if you still have the issue.
  • M

    CBR start operation is blocked

    Management
    2
    0 Votes
    2 Posts
    21 Views
    poddingueP
    I think that blocked start is actually on purpose rather than something gone wrong: XO guards a continuous-replication target, so you can't accidentally boot the replica and have it drift from the source while the job keeps running. The documented way to bring one up is the failover process (https://docs.xen-orchestra.com/xo5/incremental_replication#failover-process), and for a real cutover, that's just starting the replica on the destination side; there's also a tip there about making a copy first if you want to start it without breaking the CR job on the source. So, for your pool-to-pool move, I don't think you'd need to recreate the VMs and reattach disks; the failover flow is meant for pretty much exactly this. I'd test the whole cycle on your one VM before committing the other 30.
  • P

    broken backup in XOA 6.5 ? orphan VDI Directory, not referenced by any backup

    Backup
    10
    5
    0 Votes
    10 Posts
    96 Views
    P
    @pilow @acebmxer This should be fixed in 6.5.1 but you will need to run again your backups.
  • J

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

    Xen Orchestra
    20
    1
    0 Votes
    20 Posts
    727 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.
  • T

    Continuous Replication Speed

    Backup
    3
    2
    0 Votes
    3 Posts
    95 Views
    poddingueP
    Pilow's probably right that you're hitting the tapdisk / SMAPIv1 path rather than the network, since you're both landing at roughly the same speed despite very different link capacity. One thing worth trying before assuming it's a hard ceiling: turning on NBD for the transfer, which uses the NBD protocol instead of the VHD handler XAPI generates and generally shows better throughput with less load on the Dom0 (https://docs.xen-orchestra.com/xo5/incremental_backups#nbd-enabled-backups). I haven't benchmarked NBD against CR specifically, so I can't promise how much it'll move the needle, but it's a low-risk toggle and seems like the obvious first lever. If it's still capped after that, it might be worth a mention to @Team-Storage, since the tapdisk/SMAPIv1 transfer path is really their side and they'll have a far better read than me on where the current limits sit.
  • C

    VMWARE to XCP-ng migration of 2TB disk

    Migrate to XCP-ng
    4
    0 Votes
    4 Posts
    352 Views
    poddingueP
    Following up since the situation changed: QCOW2 went GA in XO 6.5 (released 2026-05-28), so the old ~2TB VHD ceiling is gone. A disk at exactly 2TB, and well beyond it, is fine now without shrinking to 1.99TB first. When acebmxer and john.c replied, it was still a release candidate; it's the stable story now. I haven't migrated a disk quite that size myself, so I won't promise it's totally painless, but the format limit that was blocking you isn't there anymore. The release blog has the details if you want to read up before the migration: https://xen-orchestra.com/blog/xen-orchestra-6-5/
  • S

    Disable TX checksumming with API

    REST API
    6
    0 Votes
    6 Posts
    1k Views
    poddingueP
    Bit of a necropost on your necropost, but this got easier in XO 6.5. The REST API now accepts a txChecksumming parameter when you create a VIF (PR #9793, https://github.com/vatesfr/xen-orchestra/pull/9793), and it maps straight onto the ethtool-tx / other_config value you were setting by hand. So, for new interfaces, you can do it through /rest/v0 now instead of the XAPI script. I think it's on the create path rather than existing VIFs, though, so for the firewalls already running your script or the gear icon is probably still the way, and I haven't tested it against a live VIF myself. Either way, it's nice to have it native in the API now. All-Ki opened this pull request in vatesfr/xen-orchestra closed feat(rest-api): add support for txChecksumming and rateLimitting on V… #9793
  • R

    hosts stats rest api

    Moved Solved REST API
    6
    0 Votes
    6 Posts
    999 Views
    MathieuRAM
    Hi @r0123456789, GET /rest/v0/hosts/:id/stats is available in the REST API
  • D

    REST API token generation via curl

    Solved REST API
    8
    0 Votes
    8 Posts
    2k Views
    MathieuRAM
    Hi @dan89, It is possible to create an authentication_token using the REST API. POST /rest/v0/users/me/authentication_tokens
  • S

    Token access level

    Solved REST API
    4
    0 Votes
    4 Posts
    600 Views
    MathieuRAM
    Hi @Steve_Sibilia, FYI, ACL V2 / RBAC is now available in the REST API. You can see the RBAC doc. A dedicated thread is available on the forum thread, please feel free to share your feedback. Thank you.
  • stormiS

    XCP-ng 8.3 updates announcements and testing

    Pinned News
    542
    1 Votes
    542 Posts
    260k Views
    rzrR
    New security and maintenance update candidates for XCP-ng 8.3 LTS (kernel) This release batch contains security fixes on the Linux kernel in dom0, version updates, some bug fixes and a few improvements. What changed Virtualization & System kernel: Update to 4.19.19-8.0.46.5 Fixes multiple vulnerabilities: CVE-2026-46300: A logic error in the network stack could allow an unprivileged local user to escalate its privileges to root by modifying page caches for file-backed files that were not supposed to be writable. The modifications are not persistent to a reboot (i.e. no disk corruption). This vulnerability is used by the public exploit Fragnesia. CVE-2026-46333: Incorrect tracking of users privilege level when a task is exiting in the ptrace sub-system could allow an unprivileged local user to escalate its privileges to root by writing to file descriptors they are not supposed to have access to. The changes made to potentially root-owned files are persisted across reboots. This vulnerability is used by the public exploits ssh-keysign-pwn as well as ptrace_may_dream. CVE-2026-43494: A double-free of pinned pages in the RDS kernel module in the transmit error path could allow an unprivileged local user to escalate its privileges to root by modifying page caches for file-backed files, allowing them to for example overwrite a SUID binary in page cache with a shellcode. Changes are not persistent across reboots. This vulnerability is used by the public exploit pintheft. qemu: Fix a potential issue in guest memory mapping lookup. edk2: Fix issues while booting from physical CD/DVD drive. Bump UEFI guest vCPU limit to 128 vCPU (was 96 vCPUs) dmidecode: Update to 3.6-3 Version able to read type 42 tables (redfish) varstored: Update to 1.3.2-2.1 Sync with upstream. ipxe: PXE boot support of BIOS VMs on a VLAN with 802.1Q priority tags Control plane xapi: Enable USB passthrough of smartcards Storage blktap: No functional change. Only sync with upstream. Network openssh: Drop support of insecure clients Old OpenSSH clients (version less than 7.2) can no longer connect with ssh-rsa (due to SHA-1 being no longer accepted by the server). The solution is either to update OpenSSH-clients (to a version >= 7.2), or to generate and use ED25519 keys. Others libtasn1: Update to 4.21.0 (hardening) fuse: Rebuild slang: Rebuild systemtap: Rebuild Optional packages libreswan: Rebuild netdata: Rebuild Versions: blktap: 3.55.5-6.7.xcpng8.3 -> 3.55.5-9.1.xcpng8.3 dmidecode: 1:3.0-5.el7 -> 1:3.6-3.xcpng8.3 edk2: 20220801-1.7.10.1.xcpng8.3 -> 20220801-1.7.11.1.xcpng8.3 fuse: 2.9.2-10.xcpng8.3 -> 2.9.2-10.1.xcpng8.3 ipxe: 20121005-1.0.7.xcpng8.3 -> 20121005-1.0.8.xcpng8.3 kernel: 4.19.19-8.0.46.3.xcpng8.3 -> 4.19.19-8.0.46.5.xcpng8.3 libreswam: 4.12-2.3.1.xcpng8.3 -> 4.12-2.3.2.xcpng8.3 libtasn1: 4.10-1.el7 -> 4.21.0-1.xcpng8.3 openssh: 9.8p1-1.2.3.xcpng8.3 -> 9.8p1-1.2.4.xcpng8.3 netdata: 1.47.5-4.2.xcpng8.3 -> 1.47.5-4.3.xcpng8.3 qemu: 2:4.2.1-5.2.17.1.xcpng8.3 -> 2:4.2.1-5.2.18.1.xcpng8.3 slang: 2.3.2-11.xcpng8.3 -> 2.3.2-11.1.xcpng8.3 systemtap: 4.0-5.2.xcpng8.3 -> 4.0-5.3.xcpng8.3 varstored: 1.3.1-2.1.xcpng8.3 -> 1.3.2-2.1.xcpng8.3 xapi: 26.1.4-3.1.xcpng8.3 -> 26.1.4-3.2.xcpng8.3 Test on XCP-ng 8.3 yum clean metadata --enablerepo=xcp-ng-testing,xcp-ng-candidates yum update --enablerepo=xcp-ng-testing,xcp-ng-candidates reboot The usual update rules apply: pool coordinator first, etc. What to test As usual, normal use and anything else you want to test. Test window before official release of the updates ~1 day We would like to thank users who reported feedback since our last call for testing: @Andrew, @acebmxer, @flakpyro, @greg_e, @jeffberntsen, @marcoi, @ovicz, @ph7, @probain.
  • 1

    REQUEST: Add PATCH /vms/{id} for updating VM properties (name_description, name_label)

    Solved REST API
    6
    0 Votes
    6 Posts
    376 Views
    poddingueP
    Good news, this already shipped in XO 6.5.0 (released 2026-05-28), PR #9835. If your XOA is on the latest channel, you've got PATCH /vms/{id} now; on the stable channel, it should land when 6.5.0 gets promoted (stable is on 6.4.1 at the moment). name_description looks like the field you'd write that "what's running here" summary to for your n8n flow, though I haven't tried the new endpoint myself yet. Let us know how it goes.
  • laszlobortelL

    V2V migration disk transfer speed

    Advanced features v2v migration disk transfer speed
    4
    1 Votes
    4 Posts
    207 Views
    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.
  • A

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

    Xen Orchestra
    15
    2
    0 Votes
    15 Posts
    561 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).
  • johnnezeroJ

    Server Admin Guide: A Tale of Two Servers: BIOS, GPU, and NUMA Tuning for XCP-ng: Preserving the valuable work done by Tobias Kreidl (@tjkreidl)

    Hardware
    15
    2 Votes
    15 Posts
    707 Views
    poddingueP
    Honestly, the confusion makes total sense; GitHub does a great job of hiding this stuff. Here's what's going on: those markdown files only exist right now as a proposed change sitting on a branch. That's the whole reason you can only get to them through the pull link, and nowhere else. They become a real, permanent part of the repo the moment you merge them in. And since it's your repo, that merge is yours to do, no special GitHub-fu required. Open the PR page (https://github.com/tobiaskreidl/Citrix-Tobias-Kreidl-Collection/pull/1), scroll down a bit, and click the green Merge pull request button. That's the "commit" step you were asking about. There's one wrinkle worth knowing about, and it's the real reason none of this shows up on your main repo page. Your repository has a couple of branches. Your existing PDFs and the Word doc live on a branch called XenServer-Articles, so I pointed my PR at that same branch to drop the markdown right next to them. But the page GitHub shows when someone visits your repo is a different branch called main, which at the moment only holds a README. So even after you merge, the articles will sit on XenServer-Articles, not on that front page. That's actually been true of your PDFs all along; it's nothing my PR changed. If you'd like the articles to show up on the landing page too, there are two easy ways, and I'm happy to do either one for you. We can change the repo's default branch to XenServer-Articles in Settings > Branches, so that one becomes the front page. Or I open a second small PR copying everything over to main. Just tell me which you'd rather have. So the short version: merge the PR to make the markdown real, then we can decide whether you also want the front page pointing at the articles. No rush at all on that second part. gounthar opened this pull request in tobiaskreidl/Citrix-Tobias-Kreidl-Collection open Add Markdown versions of the three articles (render inline on GitHub) #1