Oh, syslog also reports the following harmless warning:

Configuration file /etc/udev/rules.d/z10-xen-vcpu-hotplug.rules is marked executable. Please remove executable permission bits. Proceeding anyway.  4

So presumably the executable bits should be removed from this file as well.

For what it's worth:

dom0 version:

xcp-ng-release-config-8.3.0-35.x86_64
xcp-ng-deps-8.3-13.noarch
xcp-ng-plymouth-theme-1.1.0-5.xcpng8.3.noarch
xcp-ng-xapi-plugins-1.15.0-1.xcpng8.3.noarch
xcp-ng-generic-lib-1.1.1-4.xcpng8.3.x86_64
xcp-ng-release-presets-8.3.0-35.x86_64
xcp-ng-release-8.3.0-35.x86_64
xcp-ng-pv-tools-8.3-15.xcpng8.3.noarch

VM Details:
Kernel:

$ uname -a
Linux fqdn 6.12.0-124.27.1.el10_1.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jan 15 13:51:25 UTC 2026 x86_64 GNU/Linux

OS:

$ cat /etc/os-release 
NAME="Rocky Linux"
VERSION="10.1 (Red Quartz)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="10.1"
PLATFORM_ID="platform:el10"
PRETTY_NAME="Rocky Linux 10.1 (Red Quartz)"
ANSI_COLOR="0;32"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:rocky:rocky:10::baseos"
HOME_URL="https://rockylinux.org/"
VENDOR_NAME="RESF"
VENDOR_URL="https://resf.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
SUPPORT_END="2035-05-31"
ROCKY_SUPPORT_PRODUCT="Rocky-Linux-10"
ROCKY_SUPPORT_PRODUCT_VERSION="10.1"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="10.1"

I'm unsure where to report this, but syslog reports the following warning when a VM starts:

(UDEV-WORKER)   cpu0: Process '/bin/sh -c '[ -e /dev/xen/xenbus ] && [ -e /sys/devices/system/cpu/cpu0/online ] && echo 1 > /sys/devices/system/cpu/cpu0/online'' failed with exit code 1.

This is because /sys/devices/system/cpu/cpu0/online does not exist. I'm assuming that this may be expected, so I think the udev rule could be rewritten as follows to avoid spitting out an error:

# cat /etc/udev/rules.d/z10-xen-vcpu-hotplug.rules
ACTION=="add", SUBSYSTEM=="cpu", RUN+="/bin/sh -c 'if [ -e /dev/xen/xenbus ] && [ -e /sys$devpath/online ]; then echo 1 > /sys$devpath/online; fi'"

@psafont Sounds good on point #1. On point #2 I agree LLA shouldn't be the primary management IPv6 address on the interface, but you could run into trouble by not having a LLA address assigned at all. All of the IPv6 standards assume a LLA is assigned to an interface running IPv6 for things like NDP or RA to work ergo mysterious things could break as a result of an LLA address not being assigned.

Just spitballing here, but if you're concerned that only an LLA would be assigned to an interface then perhaps there could be logic to disable IPv6 for said management interface if no non-LLA address is assigned, or IPv4 could be preferred if only LLA addresses as assigned?

RE: https://xcp-ng.org/blog/2021/02/09/ipv6-in-xcp-ng/

Couple questions regarding future IPv6 support:

1. Is it currently on the docket to support multiple IPv6 addresses on the management interface? In my environment I use a ULA (Unique-Local Address) and GUA (Globally-Unique Address) for private and public access respectively on all of my servers. I would personally be OK if this supported via static assignments initially, but at present it appears only one address may be assigned. Multiple IPv6 addresses should be supported per-interface regardless because...
2. There is no LLA (Link-Local Address) address assigned to the management interface which violates some IPv6 RFC and will be required for SLAAC in the future. Are there plans or a bug filed to correct this issue?

Per https://datatracker.ietf.org/doc/html/rfc4291:

"All interfaces are required to have at least one Link-Local unicast address (see Section 2.8 for additional required addresses). A single interface may also have multiple IPv6 addresses of any type (unicast, anycast, and multicast) or scope. Unicast addresses with a scope greater than link-scope are not needed for interfaces that are not used as the origin or destination of any IPv6 packets to or from non-neighbors."

@michael-manley Speaking as a recent Linux desktop convert, I approve

@john-c It sounds like you're suggesting that XO Lite should only allow login if XoA is unavailable. Otherwise, if XoA is available (and able to communicate via xapi with the host in question) then login to XO Lite on that host is blocked.

In theory as an optional feature for security-conscious organizations, maybe? I'm not sure how feasible the implementation would be though.

@pdonias Thanks for the feedback and fix for the XOA FQDN thing! I figured most of my suggestions were pretty standard and already on the docket.

Regarding LDAP: I think @john-c put it best. XO-Lite would probably need to be integrated w/PAM in the backend for LDAP support. It sounds like the serverless (?) architecture of XO Lite runs counter to the request and said design may hinder future feature requests that ask for tighter host visibility. Regardless, XO Lite in its current form will definitely be invaluable as more and more of the items currently on the docket are implemented

Hello,

XO Lite directs requests/comments here, so here are my first impressions after upgrading to 8.3:

The Good:

• Very happy a builtin option for managing a host will be provided!
• Worked well for basic tasks I needed to do post reinstall to version 8.3.
• Interface is snappy and I like the look and feel so far.
• Console view was VERY helpful.
• The inclusion of the an XOA url at the top is a nice addition.

For the following, I'm coming at this from the perspective of "what do I need to be able to do if I can't get XOA started for reason X." I know some of this might fall into the "What XO Lite is NOT," but I still think that all of the following are host-specific and not pool-specific if that makes sense. So if it's a vm-on-a-host-based task, it's fair game, but if it's something like vm migration then it's not. Also, if the intent is for this to replace XCP-NG center for single-host deployments (which is a great goal imo), then some of the request below fit the bill of what XCP-NG Center supports, but are also in the "What XO Lite is NOT" list. There's a bit of an identity crisis. Also, apologies if anything below is present and I missed it.

The Missing/"Required":

• Creating/Attaching/Detaching VDBs manually. I have one VM that, after upgrades, needs to have an SR re-attached that is not backed up. This may also be useful in instances when a troublesome VDB might need to be rebuilt or reattached in an emergency.
• Configuring passthrough NICs on the host and passing them through to a VM would be nice, but I don't remember if XCP-NG Center did this or not. Similar to above, I have a VM that I passthrough a number of NICs to, and while it's scripted for now it'd be nice to be able to do as a one-off if needed.
• Restoring From Snapshops. If my host crashes and one of my dependent VMs (maybe even the XOA VM) is corrupted, I want to be able to restore a snapshot to get back into working order ASAP.
• Modifying the MAC address on VM interfaces is another emergency-based task I'd like. The MAC address can change when restoring a VM from backup, but if the environment depends on the MAC address staying the same for "reasons" (say the IPv6 address of the VM is derived from SLAAC), then being able to set this manually in XO Lite can mean the difference between a quick restore and a lengthy restoration effort while DNS is updated etc...
• Likewise, being able to add/remove NICs to a VM is desired. So I guess this can be combined with the above bullet-point: Add/Remove/Modify NICs on a VM.
• The ability to create and destroy a VM on the host.
• The ability to backup and restore a VM from backup LOCALLY as one-offs (not scheduled). The use-case is a situation where XOA is accidentally blown away, then the administrator can mount the backup location on the host (via NFS/Samba) and kick-off a one-off restore where they specify the location on (remote) disk.

Nice To Have:

• XCP-NG Center has a really nice view if you click on a Host and select the Search tab. It shows all of the VMs CPU/Memory statistics, so at-a-glance you can see if a VM is misbehaving. I very occasionally use this (relying on monitoring), but it has come in handy.
• It'd be nice if XO Lite could be tied into LDAP for authentication like XOA can be while still "preferring" root login. This would help provide some level of auditing for organizations that want to make sure no funny business is being done on a host-level. Otherwise, I think organizations will block access to this after the host has started.
• Since XO Lite is focused on the host-level, it'd be nice if certain host-specific configurations like SNMP and Syslog were configurable in XO Lite.
• It'd be great if there were a tab to show the running/failed systemd services on the XCP-NG Host.
• Similarly, it'd be nice if there were a host Logs tab to display logs at a configurable level (ERROR, WARN, INFO) for the host in-question.

The Small Improvements:

• I wish the XOA link pointed to the XOA server's FQDN or is configurable as opposed to linking to the XOA server's IP address. Might be a quick fix?
• Very ignorable and too late in the game, but I wish XO Lite had a different name. The "Lite" in the name gives it the likeness of being an intentionally neutered application. I'd have preferred something like "XCP-NG Local Host Manager" (XLHM) or similar that makes it clear the tool will be developed to allow configuring JUST the host in question.

Anyway, great work team. Looking forward to improvements to XO Lite in the future.

@olivierlambert It's really just a "nice-to-know", since provisioning systems are often based off of the distro version. If xcp-ng uses EL9 as its "base", then I can prepare by making sure the<insert-application-here> configurations to be deployed on a new xcp-ng instance will be compatible with whatever <insert-application-here> version is used on EL9. That's all (for me).

This should probably be pinned somewhere unless I missed it, but what's the plan going forward for XCP-NG 8.3+ with respect to OS? Will XCP-NG be using AlmaLinux 9, Rocky Linux 9, CentOS Steam 9? Please tell me it won't be Debian-based...

@marcungeschikts Thanks, that's perfect!

@marcungeschikts I understand that this issue has been solved by halting a VM before taking the snapshot. Per this comment by @julien-f , "[...] but we have discussed with the XCP-ng team and they are working on improving this", is there an issue or feature request or ticket to track XCP-ng's work to improve the implementation so that halting a VM is no longer required?

@julien-f said in XO Backup [NOBAK] for full backups:

Hey everyone, [NOBAK] should work for all types of backup: Rolling Snaphost, Disaster Recovery, Continuous Replication, Full Backup and Delta Backup.

Unfortunately, due to the way the snapshot process is implemented in XCP-ng, ignored VDIs will still be snapshotted before being deleted, which takes time and space unnecessarily, but we have discussed with the XCP-ng team and they are working on improving this

In the meantime, XO tries to work around this by temporary detaching these VDIs from the VM during the snapshot, but this only work when the VM is halted (see offline backup in the advanced settings of a backup job).

Ironically enough in my case, the VM I have that has a passthrough disk attached to it (a VDI I would like to [NOBAK]) is the VM that is setup as the remote for the backup job in XOA. So shutting it down wouldn't exactly work .

That being said I'm sure I could implement a workaround, but is there a feature request or tracking ticket URL somewhere where I can track XCP-ng team's work on this issue?

Thanks, @olivierlambert . It looks like the restore mostly worked. There was one main issue:

After I restored the configuration, all of the plugins I had had to manually configure when I first installed XOA (auth-ldap, transport-email, and usage-report) were all disabled. When I tried to re-enable them, they failed with the "plugin not configured" error. However, when I expanded their configuration, it was still present thanks to the restore. What I had to do was manually change an arbitrary field in each plugin so that I could click the "Save Configuration" button. Then I was able to re-enable the plugin. Probably a bug I should report?

Hello,

I'm working on a provisioning template to rebuild my XOA server without any sort of user interaction. A few questions:

1. Assume XOA and all plugins are installed. When restoring from backup, is it ONLY necessary to restore the "XO config" in order to bring XOA back into service 100%?
2. If not, what else needs to be backed up and restored?
3. Using the xo-cli to restore the config from backup, may I presume the following command is correct and the data.json file is the config file I want to restore?

xo-cli xo.importConfig @=/tmp/config_backup/xo-config-backups/2f26913f-81a5-4fbd-af86-ce83f90e525b/20220331T070000Z/data.json

Just to be clear, I'm not talking about restoring any XCP-NG hosts. I'm specifically talking about restoring XOA on a new VM.

@olivierlambert Thanks!

@nraynaud Thanks for working on this. Is the fix pushed to the latest stream or still in QA?