Glad the start-delay removal got that VM going again. I checked and it's a real, documented XCP-ng parameter, "the delay to wait before a call to start up the VM returns", so that explains the behavior. I couldn't find auto_poweron_delay documented anywhere in the XCP-ng or XO docs, so I'm not sure if it's something XO's advanced VM settings expose under a different name, or something unrelated you picked up while googling. If you check the VM's Advanced tab in XO and see what's actually set there, that would help pin down which setting you're really dealing with. Either way this looks like a gap in the autostart guide, since it doesn't mention that start-delay can interact with autostart at all.

Have you read the link I've sent? It explains exactly the reasons and answer your question You can imagine that if we have hundreds of 3rd party scripts, each doing their own way to install, it means we'll have to de facto support them all, despite it's unrelated to Xen Orchestra itself. Which means spending resources instead of working on Xen Orchestra directly (or fixing XO bugs). That's why it's preferable to open a ticket in the Github repo of the script creator, because that's exactly there you'll find the right answer, and also making sure the script creator could even fix their scripts if needed. If you need community support in here, you have to install it by following the official documentation: https://docs.xen-orchestra.com/installation#from-the-sources

It does for me