A
Online
Maybe I am a little confused on what you are trying to archive.
The GT730 - https://www.techpowerup.com/gpu-specs/geforce-gt-730.c1988 This is the card correct?
Reguardless of video card passing though. It should behaive simiar to native compuer with gpu and multiple moniors connected. As long as there are monitors connected to the outputs. If passed my gpu just for LLM's not for actuall work. I believe the xcp-ng web console and the first monior connected to video card would mirror themselves.
Did you enable PCI-Pass through for the nvida card? If so did you then add the pci card to the vm? the gpu can only be utilized by 1 vm at a time fyi.
Are these GPUs installed in actual servers or consumer motherboards? If the later is the intel gpu in the top most pcie slot?
I overlooked the Master tag on both host.
There is this option under pool - patches for rolling pool update. This will migrate all vms off first host apply patches reboot host and migrate all vms to host 1 and apply patches to host 2 and reboot.
Since you have too host put host 1 into maintenance mode to put all vms on host 2 and reboot host 1 and then repeat.
Just updated to latest commit - 93909
Glade to see more progress on v6.
Updates applied...
Updated:
forkexecd.x86_64 0:26.1.11-1.2.xcpng8.3 kexec-tools.x86_64 1:2.0.15-21.1.xcpng8.3
message-switch.x86_64 0:26.1.11-1.2.xcpng8.3 qcow-stream-tool.x86_64 0:26.1.11-1.2.xcpng8.3
rrdd-plugins.x86_64 0:26.1.11-1.2.xcpng8.3 sm-cli.x86_64 0:26.1.11-1.2.xcpng8.3
squeezed.x86_64 0:26.1.11-1.2.xcpng8.3 varstored-guard.x86_64 0:26.1.11-1.2.xcpng8.3
vhd-tool.x86_64 0:26.1.11-1.2.xcpng8.3 wsproxy.x86_64 0:26.1.11-1.2.xcpng8.3
xapi-core.x86_64 0:26.1.11-1.2.xcpng8.3 xapi-nbd.x86_64 0:26.1.11-1.2.xcpng8.3
xapi-rrd2csv.x86_64 0:26.1.11-1.2.xcpng8.3 xapi-storage-script.x86_64 0:26.1.11-1.2.xcpng8.3
xapi-tests.x86_64 0:26.1.11-1.2.xcpng8.3 xapi-xe.x86_64 0:26.1.11-1.2.xcpng8.3
xcp-networkd.x86_64 0:26.1.11-1.2.xcpng8.3 xcp-rrdd.x86_64 0:26.1.11-1.2.xcpng8.3
xenopsd.x86_64 0:26.1.11-1.2.xcpng8.3 xenopsd-cli.x86_64 0:26.1.11-1.2.xcpng8.3
xenopsd-xc.x86_64 0:26.1.11-1.2.xcpng8.3
Complete!
Will continue to test.
Just installed updates on host 1. Once host rebooted it took an extra min or two to reconnect to xo, but did finally connect. Applying updates on host 2 now.
Update - host2 no issues. Once reboot complete it connected to xo as expected without delay.
I see these updates include -
xen: Add support for xenpm get-core-temp to query CPU temperature on Intel platforms.
Use xenpm get-core-temp to get the temperature on Intel's CPU, to fallback unsupported coretemp. Doc update being reviewed .
My host are AMD so can verify these. I might be able to deploy a Intel host later tonight. Will this come to AMD later?
AMD rely on a different method to expose the temperature, that don't require this xenpm-based approach. In principle, it should already work with plain
sensors(through k10temp), but our driver may not be up to date for recent AMD CPUs.
From AMD 7950x
[17:51 xcp-ng-haznrrtw ~]# xenpm get-core-temp
[Package0] Unable to fetch temperature (61 - No data available)
[CPU0] Unable to fetch temperature (61 - No data available)
[CPU2] Unable to fetch temperature (61 - No data available)
[CPU4] Unable to fetch temperature (61 - No data available)
[CPU6] Unable to fetch temperature (61 - No data available)
[CPU8] Unable to fetch temperature (61 - No data available)
[CPU10] Unable to fetch temperature (61 - No data available)
[CPU12] Unable to fetch temperature (61 - No data available)
[CPU14] Unable to fetch temperature (61 - No data available)
[CPU16] Unable to fetch temperature (61 - No data available)
[CPU18] Unable to fetch temperature (61 - No data available)
[CPU20] Unable to fetch temperature (61 - No data available)
[CPU22] Unable to fetch temperature (61 - No data available)
[CPU24] Unable to fetch temperature (61 - No data available)
[CPU26] Unable to fetch temperature (61 - No data available)
[CPU28] Unable to fetch temperature (61 - No data available)
[CPU30] Unable to fetch temperature (61 - No data available)
Intel 13700k
[17:50 xcp-ng-kulwlwbp ~]# xenpm get-core-temp
Package0: 28°C
CPU0: 26°C
CPU2: 23°C
CPU4: 23°C
CPU6: 25°C
CPU8: 25°C
CPU10: 24°C
CPU12: 23°C
CPU14: 25°C
CPU16: 24°C
CPU18: 24°C
CPU20: 28°C
CPU22: 28°C
Just installed updates on host 1. Once host rebooted it took an extra min or two to reconnect to xo, but did finally connect. Applying updates on host 2 now.
Update - host2 no issues. Once reboot complete it connected to xo as expected without delay.
I see these updates include -
xen: Add support for xenpm get-core-temp to query CPU temperature on Intel platforms.
Use xenpm get-core-temp to get the temperature on Intel's CPU, to fallback unsupported coretemp. Doc update being reviewed .
My host are AMD so can verify these. I might be able to deploy a Intel host later tonight. Will this come to AMD later?
I also installed updates this morning no new issues to report.
I was going to suggest it might be a amd issue. I can try later on work host that are intel.
This is on fresh install Debian 13 deployed from XO Hub - 6.12.38+deb13-amd64. I do not see this behavior on Ubuntu.
after update 6.12.90+deb13.1-amd64
still happens.
Installed updates on home lab. No issues to report initially other then nslookup still an issue.
[10:54 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: 104.21.52.238
Name: vates.com
Address: 172.67.205.118
openssl_link.c:132: INSIST(dst__memory_pool != ((void *)0)) failed, back trace
#0 0x7f163cd960e7 in ??
#1 0x7f163cd9603a in ??
#2 0x7f163d9a3780 in ??
#3 0x7f163c1aedf6 in ??
#4 0x7f163c1f5464 in ??
#5 0x7f163c1f5732 in ??
#6 0x7f163c1f4b8d in ??
#7 0x7f163a95fbd9 in ??
#8 0x7f163a95fc27 in ??
#9 0x7f163a94844c in ??
#10 0x405818 in ??
Aborted (core dumped)
[12:50 xcp-ng-haznrrtw ~]#
@CGB Hi, are you running XO from source with root or another user?
If it is another user, it may be not accessible from it
That is what i was able to determine what is going on with my script. - https://xcp-ng.org/forum/post/105965
when using root user button works just fine. If using non-root user the button will never work as it assumes root will use it. I am not sure how other scripts handle this issue.
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.
While looking into the following issue - https://xcp-ng.org/forum/topic/11976/trying-to-enable-v2v-and-difficulty-adding-nbdinfo-on-xo-6/10
I found a few issues with my install script... Looking for recommendations on the fix approach.
I am noticing that are some confusion or inconsistencies with the documentation. Areas it suggest to use root and/or a non root account. Part of these issues would not be if the account used was root or with root access.
The two failures
Reason 1 — privileges (SERVICE_USER=xo-service, non-root):
XO's button runs apt-get install ..., make install, and ldconfig with no sudo (confirmed in esxi.mjs source). As xo-service, those commands are permission-denied: it can't apt-install, can't write to /usr/local/..., can't run ldconfig. XO's own dependency checker even says V2V requires root (UID 0) — which is why your sample-xo-config.cfg:56 already warns "V2V import requires root."
So yes — your instinct is correct. With SERVICE_USER=xo-service, the button cannot succeed no matter what.
But Reason 2 — build tools absent:
Even if you set SERVICE_USER=root and click the button, it will then try apt-get install -y git dh-autoreconf pkg-config make libxml2-dev ocaml libc-bin and compile from GitLab. That will work if the box has internet and apt is healthy — but it's a multi-minute source compile pulling ~hundreds of MB (ocaml!) every time, done live inside the web request. Pre-staging those packages via the installer makes the button fast and reliable instead of a long live compile.
So, is the fix "just set SERVICE_USER=root"?
To make the button function: yes, that is the necessary fix. Pre-installing build deps is an optional reliability/speed improvement on top.
Given your answers, here's my refined proposal — minimal, docs-aligned:
Proposed changes
Add INSTALL_V2V_DEPS=false opt-in to sample-xo-config.cfg. When true, the installer pre-stages XO's exact build-dep list (git dh-autoreconf pkg-config make libxml2-dev ocaml libc-bin) on apt systems only, so the button compiles quickly instead of installing them live. Default false → no ocaml bloat on normal installs.
Root guard (your "Warn only" preference): When INSTALL_V2V_DEPS=true and SERVICE_USER is non-root, print a prominent warning:
"VMware V2V import requires xo-server to run as root (per XO docs). The in-XO 'install nbdinfo' button runs apt-get/make install without sudo and will fail as user '$SERVICE_USER'. Set SERVICE_USER=root to use V2V import."
…and continue (don't abort).
RHEL/dnf: if INSTALL_V2V_DEPS=true on a non-apt system, log "VMware V2V import is only officially supported on Debian 12/13 per XO docs — skipping V2V dependency setup." and do nothing.
Keep the existing /usr/local/lib/vddk dir creation (it's correct — XO untars VDDK there), and don't touch APT contrib/multiverse or pre-compile nbdkit (XO compiles from source itself; distro packages are never used by the button).
Docs: README row for INSTALL_V2V_DEPS + a sharpened note in sample-config that V2V needs SERVICE_USER=root, linking the official guide.
This stays strictly within what XO's own code does, scopes the heavy deps behind opt-in, and surfaces the real root-user requirement you correctly identified.
Shall I implement this? If yes, I'll make the edits and run shellcheck/bats afterward to verify nothing breaks. (I have not edited anything yet.)
Prior to looking into this issue. I was trying to work on switching from standard user to root but that broke alot of things and will need rework. Dont belive it would be an issue if root was used to initially deploy xo.
@CGB
Are you using XOA or XO from sources? If from sources, who's script did you use to deploy? Also if from source what commit are you on?
Applied patches at work. 3 pools updated with zero issues.
