@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 My opinion is that cloud-init should be used only for the most basic stuff like initial network configuration, initial user creation and credentials injection. As soon as you gain the ability to access the VM, some more robust configuration management solution like Ansible should take over. ansible-pull mechanism is in today's day and age effectively deprecated. Just run Ansible after the VM has been provisioned to apply the configuration. If you need to call Ansible as soon as VM is provisioned without any manual invocation, you can have Terraform provision the VM and call Ansible right after that. You can even use pure Ansible for both - provisioning, with my community.general.xenserver_guest module, and configuration. You just invoke Ansible once and everything will be done in one go. The only drawback is that my module does not support cloud-init so you would need some trickery to do the stuff.

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