@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."

@bug-meister Yeah, I would say the "mechanism" is deprecated too. Getting this mechanism to work, either by using ansible-pull or by some clever scripting during the first boot, requires Ansible to be preinstalled on your VM templates. That just makes your VMs messy and bloated with additional stuff you only use once. Also, managing Ansible versions becomes more complex. If Ansible is installed from distro repositories, you will have all different versions of Ansible across different distros. If you use pip to install Ansible, it can mess up your system if Ansible dependencies are installed on a system level. You can use Python virtual environments to prevent that but requires additional managing. It's much better and much more practical to have Ansible installed and used from a single place - Control Node. That way you have one place, one OS, one Ansible version to think about. You already have a machine you are accessing your VMs from? Use that as a control node... unless it is Windows?

@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.