dacshyp003 booted at [Mon Sep 21 05:44:37 2026] Linux version 4.19.0+1 (mockbuild@1efe98ffea2245bcb4c11893890153ac) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC)) #1 SMP Thu Aug 13 13:06:11 UTC 2026 This is the part of the xensource logging of the dacshyp001 before the reboot: Sep 21 11:17:52 dacshyp001 xapi: [debug||17 ha_monitor|HA monitor D:58d1715e0726|xapi_ha] The node we think is the master is still alive and marked as master; this is OK ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ Same behavior on dacshyp003. I also attached the xha.log from both nodes. xha_log_001.txt xha_log_003.txt

@poddingue This was fixed a number of weeks ago via a ticket. I believe @florent may know the exact fix.

@abudef asked almost exactly this a few days ago over on 12466, and @pierrebrunet answered it there with a link to the doc describing the layout, so that thread's probably your quickest route. For the specific "which VM is this folder" question, the UUID in the directory name is the VM's own UUID, so xe vm-list uuid=<that-uuid> params=name-label on a host should give you the name back. One thing that bite me when I tried it: if the VM has since been deleted, that command prints nothing at all and still exits cleanly, so silence means "no such VM here" rather than "the command didn't work". Those silent ones are probably where your space has gone, if I had to guess. I'm not the backup expert here so someone may well have a tidier way of doing it.

Forwarded to the right team, thanks!

You already spotted this over on 12468, so this is just to close the loop here. That one's fixed: Pierre Brunet put the fix on a branch, @Andrew and @abudef both tested it, and it's merged now. Since you're running from source on master, you should be able to pull past that merge rather than wait for a release. One thing to keep in mind, though: the same error string showed up in 11875 for a completely different cause, so if it comes back after you update, it's probably not this bug again. I'd let 12468 be the thread to follow since that's where the people who fixed it are.

You're not blind, and your fingerprint is right. I pulled packer-plugin-xenserver_v0.11.4_SHA256SUMS.sig off the GitHub release and ran gpg --list-packets on it, and it reports issuer fpr v4 0DD2E92A7A0F682BC29F87073084D82948625D89, which is exactly what you pasted. It doesn't match the XCP-ng key because it isn't ours. The plugin our docs point at is ddelnano/packer-plugin-xenserver, maintained outside Vates, so it's signed with the maintainer's key while 34AC2EB6... only signs XCP-ng RPMs. I couldn't find that key published anywhere either. It's not on keys.openpgp.org or keyserver.ubuntu.com, it isn't in the repo, and it isn't among the 11 keys at github.com/ddelnano.gpg. That looks like something worth raising on the plugin's own issue tracker, and you'd file it better than I would since you're the one trying to verify a download. I'd also say our IaC docs could stand to mention the plugin isn't ours, which is what sent you looking at the wrong key in the first place.

Thanks for doing that, @john.c. The sponsorship side isn't mine to speak to; I forwarded to the right person The CFP I can say something about: nor(DEV):con is already in the conference pipeline I keep an eye on, and their Sessionize call closes on 30 September, so your timing is better than you probably realised. I can't promise you'll see us in Norwich, but the nudge landed in front of the right people.

Small update — I split the custom plugins out of this project into their own repo, for anyone who just wants the plugins without pulling in the whole install script: https://github.com/acebmxer/xo-plugins Same deal as always — use at your own risk, review the code before running it on anything that matters. The two plugins in there are also still shipped inside this install script's Custom Plugins menu, kept in sync automatically — this repo just exists for people who don't want the rest of the project. xo-server-nanokvm This one's probably the more useful of the two for a lot of people. If you've got a host with no iLO/DRAC/IPMI — most consumer/prosumer boards, a lot of homelab gear — and you've wired up a Sipeed NanoKVM to the power header, this plugin lets Xen Orchestra power that host back on through the NanoKVM's own API. Same interface the NanoKVM web UI itself uses to press the button, just done from XO. On its own it doesn't decide when to turn a host on, it just gives XO a way to do it. Pairs with the other plugin below for that, or you could call it from your own automation if you wanted. Worth knowing: it can only press the button, it has no way to know if the host is actually on or off, so it only handles power-on. Powering off goes through XO's normal shutdown, which is a clean OS shutdown and evacuates VMs first — no reason to route that through the NanoKVM. Setup is a config entry per host: label, the NanoKVM's URL, a login, and which XO host it's wired to. Recommend making it a dedicated user-role account on the NanoKVM rather than admin — that role already has power/reset access without giving the plugin anything to storage/network settings on the KVM itself. xo-server-host-power-manager This is the one that actually decides when to act. Point it at an "extra" host in the pool and give it CPU and/or memory thresholds — when the rest of the pool is under pressure it powers that host on, and once things calm down for a while it powers it back off. Power-on can go through XO's built-in methods or through the NanoKVM plugin above, your choice per rule. Powering off always goes through XO's own host shutdown — it evacuates the running VMs first, and if HA is on and doesn't have room to cover it, XAPI just refuses and the plugin backs off and tries again later rather than forcing anything. It's deliberately quick to scale up and slow to scale down (needs both CPU and memory comfortable for a full cooldown period before it'll power a host off) so it's not flapping a host on and off over a short spike. Both have a Test button in their config page that actually tells you something useful, unlike XO's own generic "test plugin" popup — check journalctl -u xo-server right after clicking it to see what it found. As always, happy to hear feedback or find out I've broken something.