@acebmxer I would have said the logs depend on how you deployed XO. Basically it would be an error printed when you ran yarn start. But it depends if XO is started with systemd or something else. But as you found yourself the solution... this is not needed anymore for now. I'll see if we can report an helpful message in XO. Something like "Cannot reach docker.sock. As you're running a RedHat like distro, ensure SELinux rules let sshd reach it. See this link for more... Etc."

@acebmxer that is awesome work! Looking forqard to duplicating your effort on Monday. Have an aqesome weekend!

@dinhngtu said: dinhngtu VATES 🪐 XCP-NG TEAM a day ago @hrvojer There are many bugs in older versions of the Xen PV drivers. I suggest running Windows without guest tools and drivers if you can take the performance and functionality hit (no suspend/migration on UEFI VMs, no metric reporting, etc). Thanks @dinhngtu, appreciated. Running without PV drivers is hard for us: this is an I/O-heavy production SQL Server and we already had timeout problems before adding RAM, so I'm worried emulated disk performance would hurt more than an occasional crash. Our medium-term plan is to migrate SQL to a new VM with a supported Windows Server and current tools. Until then, a few follow-up questions: Is there any official place to still get XenServer VM Tools 9.2.3 (or whichever last version works on 2012 R2)? Would an older XCP-ng PV driver release (e.g. 8.2.2.200) likely be any better here, or is it the same xenvbd code base? One more detail I missed: in the same Feb 2026 change we also enabled "Lock Pages in Memory" for the SQL Server service account (together with 16 -> 64 GB RAM). Is there any known issue between old xenvbd and locked pages / large guest memory? Meanwhile we've capped SQL max server memory at 32 GB as a stopgap.

@bvitnik It worked as hoped, after an iteration or two. I opted for using jinja templating with setting template vars up top and using in standardized fashion below. But... I can see that cloud configs will not be easy to manage and scale for complex tasks. If you need to write a file or two, configure LDAP authN using sssd, the prometheus node_exporter, etc., the scripts can get lengthy. Given how difficult they are to debug (cloud-init schema --config-file <config.yaml> --annotate is helpful, but more challenging with jinja templates), it would seem something else should supplement a basic config. Now I'm considering ansible-pull from an on-network git repo -- I don't think I have the scale to warrant a control instance and I can't quite warm up to the idea of an SSH key with sudo access everywhere. Admittedly the security concern just shifts to the repo, especially if periodic pulls will happen. In your opinion am I going in the right direction or should I be considering other config management options too? My goal is to deploy VMs with a set of docker containers (I'll use podman) in a repeatable fashion. Thanks again for your patience with a DevOps noob.

@john.c @poddingue I am very happy to report that I am no longer receiving the "XOA Unable to connect xo server every 30s" message on the Chrome browser of my Windows 11 PC, as of today, after updating the XO-CE VM and all xcp-ng hosts. I just updated the XO-CE VM to master, commit 70b08, and ran a rolling pool update of my 3 xcp-ng hosts. Thank you to the Vates team.

Update - changes are live in the dev branch now. So figured out the update / switching branches for the proxy by connecting the proxy to my xoa free account. That triggered the available update to next version. From there I found the command that needs to be ran on the proxy to switch back and forth... [image: Screenshot_20261009_143546.png] Latest branch [image: Screenshot_20261009_144414.png] stable branch [image: Screenshot_20261008_202716.png] Backup job ran sucessful. 2026-10-09T17_48_25.447Z - backup NG.txt After the proxy has been deployed... The proxy has been registered with your Xen Orchestra instance. You can manage it from the Xen Orchestra web interface. Next: register the proxy's updater and move it to the 'latest' channel. On the pool master (IP), set a password for the proxy's 'xoa' user (choose your own) and reboot the proxy VM: xe vm-param-set uuid=UUID xenstore-data:vm-data/system-account-xoa-password='<your password>' xe vm-reboot uuid=UUID SSH to the proxy as 'xoa' (IP) and run: sudo xoa-updater register - This registers it with your vates account. sudo xoa-updater configure-channel xo-proxy-appliance-latest - set to latest or stable sudo xoa-updater upgrade - This can be ran via the UI or this command. Both need to be done twice to do the upgrade and/or downgrade. register needs a free xen-orchestra.com account; see the README. And host connected via proxy. [image: Screenshot_20261009_150011.png]