• XCP-ng Windows PV tools announcements

    Moved News
    119
    0 Votes
    119 Posts
    64k Views
    J
    @Mitchel-APD Thank you! That might acctually help me quite a bit... I have been having trouble getting my ansible-instances to recover from the VM re-initiating the network connection! Perhaps this could be helpfull. I will absolutely test it
  • Backup failures after VHD to QCOW2 conversion

    Unsolved Backup
    5
    0 Votes
    5 Posts
    151 Views
    S
    Thanks for your help! I have the SMlogs from both hosts ready, but theyโ€™re too large to upload here, even compressed Whats the best way to share them with you or Team-Storage?
  • MFA for console access

    Unsolved XCP-ng
    1
    0 Votes
    1 Posts
    37 Views
    No one has replied
  • 0 Votes
    15 Posts
    469 Views
    F
    @acebmxer that is exactley what i was saying before. if you disable the remote before nas shutdown you are good on the XO side and will work indefinitely, but if you don't execute umount -l /run/xo-server/mounts/2ab02323-0d47-43a5-9081-b2454e036c70 you will have the mount stuck on the os side. You will be able to reboot XO vm eventually but you will have to wait for a long timeout during XO shutdown. if you want to simulate my issue just disable the remote 5 minutes after shutting down the synology, get the pid from service xo-server status then ps -T pid after a while you'll have 4 "rpc_wait_bit_killable" and XO will stop responding
  • XCP-ng 8.3 updates announcements and testing

    Pinned News
    800
    1 Votes
    800 Posts
    1m Views
    R
    @vxgmichel I may have found our problem. Looks like an XCP-ng update may have slipped an unwanted site back into our /etc/yum.repos.d/xcp-ng.repo. When I first deployed XCP-ng, I had to remove the "http://mirrors.xcp-ng.org/8/8.3/base/x86_64/" entry for updates to work as it was too troublesome to get it working through our outbound proxy managed by another team. I have re-removed that site and things are working again. It was not fun trying to figure that out in the midst of a vulnerability. diff /etc/yum.repos.d/xcp-ng.repo /etc/yum.repos.d/xcp-ng.repo.orig <- baseurl=http://updates.xcp-ng.org/8/8.3/base/x86_64/ -> baseurl=http://mirrors.xcp-ng.org/8/8.3/base/x86_64/ http://updates.xcp-ng.org/8/8.3/base/x86_64/ <- baseurl=http://updates.xcp-ng.org/8/8.3/updates/x86_64/ -> baseurl=http://mirrors.xcp-ng.org/8/8.3/updates/x86_64/ http://updates.xcp-ng.org/8/8.3/updates/x86_64/
  • 0 Votes
    2 Posts
    71 Views
    poddingueP
    Your reading of the code matches what I see on master, as far as I can tell. The object.enabled === true check in _getHosts() seems to have come in with PR #10209, released in XO 6.7.1 in August, to stop the balancer migrating VMs onto disabled hosts. If I follow the code right, a host that XO shuts down goes through disableHost first, so the power-on step in performance-plan.js no longer sees it. That looks like a side effect of the fix to me. The docs still say the performance plan powers halted hosts back on (https://docs.xen-orchestra.com/manage-your-infrastructure/load_balancing#plan-modes), so I think one of the two is wrong. I haven't reproduced it and there may be a reason to filter halted hosts that I can't see from the code, so @Team-XO-Backend is better placed to say if your powerState === 'Halted' exception is the right fix.
  • New 9.2.445 XCP Windows tools Roll Back

    Management
    2
    0 Votes
    2 Posts
    60 Views
    olivierlambertO
    This is a question for @dinhngtu
  • Disk import not happens

    Unsolved Management
    5
    0 Votes
    5 Posts
    107 Views
    Tristis OrisT
    error via reverse proxy. Uncaught Error: Body is not a JSON, original message is : <html> <title>500 Internal Server Error</title> <style>html{color-scheme:light dark;}</style> </head> <body> <center><h1>500 Internal Server Error</h1></center> <hr><center>Angie</center> </body> </html> pr index.js:2564 me index.js:4029 i index.js:4029 promise callback*me index.js:4029 i index.js:4029 promise callback*me index.js:4029 i index.js:4029 promise callback*me index.js:4029 i index.js:4029 be index.js:4029 be index.js:4029 dr index.js:2531 importDisks index.js:2575 Lodash 2 importDisks index.js:2574 e index.js:113 P index.js:22 i index.js:22 R index.js:22 R index.js:22 import index.js:121 t factory.js:307 o factory.js:331 e action-button.js:93 m action-button.js:10 i action-button.js:10 _execute action-button.js:10 _execute action-button.js:10 _execute action-button.js:10 v action-button.js:140 componentDidMount action-button.js:147 React 14 componentWillUnmount factory.js:125 f factory.js:31 _dispatch factory.js:158 t factory.js:322 promise callback*t factory.js:313 o factory.js:331 value index.js:206 promise callback*value index.js:174 React 5
  • Booting Homeassistant (HAOS) Image breaks VM

    Unsolved Compute
    5
    0 Votes
    5 Posts
    355 Views
    C
    @IgorGlock What do you mean by "okay"? Backing up the VM with Commvault or...?
  • Rolling pool update

    Xen Orchestra
    13
    0 Votes
    13 Posts
    469 Views
    J
    @tjkreidl said: @john.c Note that a two-host pool running HA can run into the split-brain issue if one of the hosts fails; it's highly recommended to have at least three hosts in an HA pool (or look into HA-Lizard if running a pool with two hosts and HA). Right but also considering the in development Twinstor for when it goes stable and in production!
  • 7 Votes
    324 Posts
    217k Views
    J
    @Greg_E said: @john.c Uggg... I just updated yesterday so I better check to see if I need to upgrade again today. Starting to hate AI, and I'm guessing the developers are the same. That said, not exposed to the internet. [edit] regarding moving the backup, it was nice to have a front page single click to see the checkmarks on the jobs. Now it's two clicks. I'll adjust my morning routine. @greg_e Itโ€™s just Vates and software in their stack, just imagine what itโ€™s like for developers and maintainers of Debian Linux! What with all the software in the distribution and all of it at times needed updating concurrently. To help them through these especially tough times may or would be a good idea to make a donation to Debian Linux, and/or other contributions.
  • 0 Votes
    3 Posts
    111 Views
    R
    Thanks @poddingue, that's helpful. I'll keep the satellites on the management interface then. @Team-Storage could you please have a look at the LinstorSR attach failure, the RPU evacuating the controller host, and the xenopsd leftovers after the failed sync point 4? I have the RPU traces, SMlog, xensource.log and the linstor-controller error reports archived if needed.
  • 4 Votes
    3 Posts
    808 Views
    J
    @vmpr Popping it behind an instance of BunkerWeb (https://www.bunkerweb.io/) or similar, with Xen Orchestra on a new IP address would help. As BunkerWeb is whatโ€™s known as a Web Application Firewall. It will help to protect your instance of Xen Orchestra, especially if you change the IP address of the appliance, and only give that friend the one that goes through BunkerWeb. As always donโ€™t expose Xen Orchestra to the Internet, but if itโ€™s absolutely necessary always use something like BunkerWeb (with BunkerNET) and only provide the BunkerWeb based IP address! Also run a check on all of your hosts and may be best to roll them a fresh (in case thereโ€™s an Advanced Persistent Threat). As well as a fresh instance of Xen Orchestra, and maybe encourage your friend while also doing yourself to start using hardware security keys, preferably ones that support biometrics and PINs. Alternatively other secure enclaves with cryptographic credentials held there. Additionally opt into the new encrypted datastore for Xen Orchestra on the new fresh Xen Orchestra and XCP-ng. Also make sure itโ€™s completely up to date! Also if the hosts support it ensure that Intel TME or similar is enabled on the fresh installs of XCP-ng. Finally rotate all passwords associated with that system, including your Vates account password, especially if itโ€™s linked to the Xen Orchestra instance hit.
  • 0 Votes
    20 Posts
    2k Views
    nathanael-hN
    @jr-m4 I did not took time to test Podman yet. But we expect this to work. You'd have to expose a socket, like the docker daemon does. Probably systemctl enable --now podman.socket would be enough. More in this page https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/building_running_and_managing_containers/using-the-container-tools-api and this one https://docs.podman.io/en/latest/markdown/podman-system-service.1.html
  • 0 Votes
    5 Posts
    500 Views
    I
    @gudge25 check these https://docs.xcp-ng.org/vms/#enabling-viridian-extensions and https://lazyadmin.nl/it/september-2026-update-break-rds-how-to-fix/
  • XOSTOR hyperconvergence preview

    Pinned Moved XOSTOR
    471
    1
    6 Votes
    471 Posts
    1m Views
    Maelstrom96M
    @dthenot For anyone stuck, here is what I ended up doing: I've manually hardcoded the controller_uri in /opt/xensource/sm/linstorvolumemanager.py on the new host, restarted the toolstack using xe-toolstack-restart and ran the xe host-call-plugin host-uuid=NEW_HOST_UUID plugin=linstor-manager fn=addHost args:groupName=linstor_group/thin_device command. def _get_controller_uri() -> str: # TODO: Check that an IP address from the current pool is returned. #addresses = _get_controller_addresses() return "linstor://10.25.254.100" #return "linstor://" + addresses[0] if addresses else "" After that, you should see the addHost command return True. It should be safe to revert the change to the _get_controller_uri() function and restart to make sure everything starts properly. [10:06 van3-pprod-xen01 ~]# linstor --controllers 10.25.254.100 node l โ•ญโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ•ฎ โ”Š Node โ”Š NodeType โ”Š Addresses โ”Š State โ”Š โ•žโ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•ก โ”Š van3-pprod-xen01 โ”Š COMBINED โ”Š 10.25.254.100:3366 (PLAIN) โ”Š Online โ”Š โ”Š van3-pprod-xen02 โ”Š COMBINED โ”Š 10.25.254.101:3366 (PLAIN) โ”Š Online โ”Š โ”Š van3-pprod-xen03 โ”Š COMBINED โ”Š 10.25.254.102:3366 (PLAIN) โ”Š Online โ”Š โ”Š van3-pprod-xen04 โ”Š COMBINED โ”Š 10.25.254.103:3366 (PLAIN) โ”Š Online โ”Š โ•ฐโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ•ฏ [10:06 van3-pprod-xen01 ~]# xe host-call-plugin host-uuid=f9d94f6c-e826-452f-b9b9-638550b209cf plugin=linstor-manager fn=addHost args:groupName=linstor_group/thin_device True [10:08 van3-pprod-xen01 ~]# linstor --controllers 10.25.254.100 node l โ•ญโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ•ฎ โ”Š Node โ”Š NodeType โ”Š Addresses โ”Š State โ”Š โ•žโ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•โ•ก โ”Š van3-pprod-xen01 โ”Š COMBINED โ”Š 10.25.254.100:3366 (PLAIN) โ”Š Online โ”Š โ”Š van3-pprod-xen02 โ”Š COMBINED โ”Š 10.25.254.101:3366 (PLAIN) โ”Š Online โ”Š โ”Š van3-pprod-xen03 โ”Š COMBINED โ”Š 10.25.254.102:3366 (PLAIN) โ”Š Online โ”Š โ”Š van3-pprod-xen04 โ”Š COMBINED โ”Š 10.25.254.103:3366 (PLAIN) โ”Š Online โ”Š โ”Š van3-pprod-xen05 โ”Š COMBINED โ”Š 10.25.254.104:3366 (PLAIN) โ”Š Online โ”Š โ•ฐโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ•ฏ
  • XO RBAC Granularity?

    Unsolved Management
    10
    0 Votes
    10 Posts
    262 Views
    julienXOvatesJ
    Thanks @ataxyanetwork I was about to answer the same...! (but was too busy this morning )
  • Auth LDAP Plugin "Could Not Authenticate User"

    Unsolved Management
    3
    1 Votes
    3 Posts
    124 Views
    C
    Hi @poddingue ..yes, I have quite a few 'requests' I need to post in there...I just have yet to do so Thanks!
  • 1 Votes
    2 Posts
    103 Views
    poddingueP
    For the partitioning part, the docs say NVIDIA vGPU isn't supported on XCP-ng, since it depends on a proprietary XenServer component that can't be redistributed: https://docs.xcp-ng.org/compute#vgpu. So as far as I can tell, the "20, 40 or 80 GB per VM" split won't work through vGPU. Passing a whole GPU to one VM is the documented path, on the same page. I haven't seen anyone report on H100 or H200 cards here, though, so I can't tell you if that class of card brings its own surprises. There's also a blog post doing LLM inference that way on a much smaller Tesla T4: https://xcp-ng.org/blog/2025/07/28/your-own-gpu-powered-llms-with-xcp-ng/. There's an open design discussion upstream in XAPI about GPU partitioning, MIG included (https://github.com/xapi-project/xen-api/pull/7260), but that's the XenServer side, and I don't know if or when it would reach XCP-ng. As GPU partitioning matters for your project, it might be worth opening a request on https://feedback.vates.tech/ with what you described here (H200s, LLM inference, several tenants per card, fixed VRAM per VM). From what I've seen, a concrete use case like yours carries more weight there than a plain "please support vGPU", and other people needing the same thing can vote on it.
  • Bug in XO-Lite GUI / VM Creation

    Unsolved XO Lite
    3
    1
    0 Votes
    3 Posts
    166 Views
    C
    @poddingue Yes, reads pretty much like the same error / root cause.