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

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

    Backup
    24
    1
    0 Votes
    24 Posts
    205 Views
    P
    @Andrew ok, thank you. This one indeed is not supposed to be triggered indeed.
  • stormiS

    XCP-ng 8.3 updates announcements and testing

    Pinned News
    547
    1 Votes
    547 Posts
    260k Views
    acebmxerA
    @rzr [09:43 xcp-ng-haznrrtw ~]# nslookup vates.com 8.8.8.8 -bash: nslookup: command not found [10:21 xcp-ng-haznrrtw ~]# yum install bind-utils -y Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile Excluding mirror: updates.xcp-ng.org * xcp-ng-base: mirrors.xcp-ng.org Excluding mirror: updates.xcp-ng.org * xcp-ng-updates: mirrors.xcp-ng.org Resolving Dependencies --> Running transaction check ---> Package bind-utils.x86_64 32:9.9.4-63.1.xcpng8.3 will be installed --> Processing Dependency: bind-libs = 32:9.9.4-63.1.xcpng8.3 for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 --> Processing Dependency: libbind9.so.90()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 --> Processing Dependency: libdns.so.100()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 --> Processing Dependency: libisc.so.95()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 --> Processing Dependency: libisccc.so.90()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 --> Processing Dependency: libisccfg.so.90()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 --> Processing Dependency: liblwres.so.90()(64bit) for package: 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 --> Running transaction check ---> Package bind-libs.x86_64 32:9.9.4-63.1.xcpng8.3 will be installed --> Finished Dependency Resolution Dependencies Resolved ========================================================================================================================================= Package Arch Version Repository Size ========================================================================================================================================= Installing: bind-utils x86_64 32:9.9.4-63.1.xcpng8.3 xcp-ng-updates 126 k Installing for dependencies: bind-libs x86_64 32:9.9.4-63.1.xcpng8.3 xcp-ng-updates 948 k Transaction Summary ========================================================================================================================================= Install 1 Package (+1 Dependent package) Total download size: 1.0 M Installed size: 3.0 M Downloading packages: (1/2): bind-libs-9.9.4-63.1.xcpng8.3.x86_64.rpm | 948 kB 00:00:00 (2/2): bind-utils-9.9.4-63.1.xcpng8.3.x86_64.rpm | 126 kB 00:00:01 ----------------------------------------------------------------------------------------------------------------------------------------- Total 855 kB/s | 1.0 MB 00:00:01 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : 32:bind-libs-9.9.4-63.1.xcpng8.3.x86_64 1/2 Installing : 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 2/2 Verifying : 32:bind-libs-9.9.4-63.1.xcpng8.3.x86_64 1/2 Verifying : 32:bind-utils-9.9.4-63.1.xcpng8.3.x86_64 2/2 Installed: bind-utils.x86_64 32:9.9.4-63.1.xcpng8.3 Dependency Installed: bind-libs.x86_64 32:9.9.4-63.1.xcpng8.3 Complete! [10:22 xcp-ng-haznrrtw ~]# nslookup vates.com 8.8.8.8 Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: Name: vates.com Address: 172.67.205.118 Name: vates.com Address: 104.21.52.238 openssl_link.c:132: INSIST(dst__memory_pool != ((void *)0)) failed, back trace #0 0x7f419d8790e7 in ?? #1 0x7f419d87903a in ?? #2 0x7f419e486780 in ?? #3 0x7f419cc91df6 in ?? #4 0x7f419ccd8464 in ?? #5 0x7f419ccd8732 in ?? #6 0x7f419ccd7b8d in ?? #7 0x7f419b442bd9 in ?? #8 0x7f419b442c27 in ?? #9 0x7f419b42b44c in ?? #10 0x405818 in ?? Aborted (core dumped
  • DAYELAD

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

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

    Continuous Replication Speed

    Backup
    4
    2
    0 Votes
    4 Posts
    117 Views
    tjkreidlT
    @Pilow Yeah, I'd run iostat and look to see how th resources are being limited, I'd run something like "iostat -dtkx 10" so you get extended stats every 10 seconds during that replication process and look at the wait, queue states, etc. to see if that helps identify any bottlenecks.
  • 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
    16
    2 Votes
    16 Posts
    722 Views
    tjkreidlT
    @poddingue Thank you kindly! Honestly, whatever organizational structure you think is best is fine by me.
  • M

    CBR start operation is blocked

    Management
    2
    0 Votes
    2 Posts
    30 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
    103 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
    731 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.
  • C

    VMWARE to XCP-ng migration of 2TB disk

    Migrate to XCP-ng
    4
    0 Votes
    4 Posts
    364 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
    1k 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
    607 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.
  • 1

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

    Solved REST API
    6
    0 Votes
    6 Posts
    380 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
    212 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
    563 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).