@yomeyo It's a client shutdown being misreported as a client error. I'll fix this in the next release. The warning on upgrade should be harmless and you can simply close the application/click OK as you've done.

On a Lenovo SR630 V4 it took Power/Performance Bias set to OS Controlled, and on an HPE DL380 Gen 11 it was the iLO Power Regulator moved off Dynamic Power Savings to OS Control Mode, with a host reboot. Both then returned real values from xenpm get-cpufreq-para instead of the failure line. @bleader is right that two vendors is not enough to document, so if your host works, could you post the vendor, the exact setting name, where it lives, and whether you needed a reboot? Dell, Supermicro and anything AMD are the obvious gaps. I don't know whether the firmware is withholding p-state control outright or just not publishing the ACPI objects Xen looks for, so I would rather collect settings than write up a mechanism I can't back. Thanks!

I put your colon-versus-equals question on a spare host, because I couldn't answer it from memory. With the colon form xe creates a key literally called auto_poweron:true with an empty value, so the entries you saw were three different keys and none of them was the real auto_poweron. Typing false afterwards just made another one. It exits 0 every time and prints nothing, which I'd call a rough edge rather than a feature, though I don't know whether the CLI is meant to validate map keys at all given other-config is deliberately free-form. Your sleep finding is probably the more useful half for whoever reads this next. The executable-bit part is in the docs now, it went onto the troubleshooting page after you reported it: https://docs.xcp-ng.org/troubleshooting/common-problems

That question has come round three times on this thread since 2020, so it isn't a one-off. I'd rather not promise documentation I can't deliver, but I can take it to the people who decide and come back here either way, including if the answer is that proxy deployment stays an XOA thing. On the licensing side I'd sooner not encourage patching those checks out, mostly because I don't know what they're guarding. In the meantime, the two community scripts in this thread are what people are actually running, which is worth saying plainly even though it isn't the documented path you asked for.

I put this on a spare host rather than guess at it twice. The delay runs after the start, not before it. With start-delay=20 the VM was up in about a second and the call then sat there for the rest of the twenty before returning. So the VM you set it on is already running, and what waits is whatever was going to happen next. Ordering does exist, but it belongs to vApps: an appliance groups VMs and order decides which goes first (https://docs.xcp-ng.org/vms/vm-lifecycle#vapps). The part that surprised me is that nothing starts an appliance when the host boots. I put both test VMs in one, rebooted, and they stayed down. Autostart is a single bulk start of everything flagged for auto power on, it walks them one at a time, and it ignores order. I set order=2 on a VM and it still went first. So a delay does hold up the VMs behind it at boot, which is probably what you were seeing, but you cannot pick which one goes first. For your NAS and seedbox I do not think there is a clean answer today. There is an open request for exactly that, a VM that waits on another VM: https://github.com/vatesfr/xen-orchestra/issues/8433, and your case would be a good one to add to it. What I still cannot explain is why yours stopped starting at all. A delay stalling the ones behind it would explain a late start, not one that never comes up.

@poddingue Here is the ouput of the command: $ xe host-list params=uuid,name-label,address uuid ( RO) : 8b0ac09d-a723-4a18-85ae-86660746d8aa name-label ( RW): frodo address ( RO): 192.168.1.13 uuid ( RO) : 2b1579d3-d45a-4d67-a423-20ddbbd61e00 name-label ( RW): meriadoc address ( RO): 192.168.1.12 uuid ( RO) : 7641f7a2-5774-4303-939f-afc3b6b4e35e name-label ( RW): samwise.somezone.net address ( RO): 192.168.1.10 With moving it to the Docker container, I only did that after I was already experiencing the same issue with a system that used the script to setup XO. I had hoped it was something on the XO side but it's seems more like it's the XCP-NG side.

Version 4.7 build 105 works fine with applied fix (modules/path). I have made upgrade form 4.5 -> 4.7, before update I have uninstall all plugins than upgrade to 4.7. Apply fixes and install plugins.