@dinhngtu When creating GPOs if you have an non-policy setting for all users in the settings area for the agent config. The policy based registry settings can go into “Software\Policies”, for the appropriate HKEY and keys. In which case the policy based registry entries supersede the non-policy ones, when considering also the HKLM vs HKU and HKCU cascade. Also a disabling of user configuration of the managed setting(s) along with display of a message like “At least some of these settings are managed by the organisation”.

@MajorP93 Ok. Thanks!

@poddingue Fistst of all I appreciate your answer and your position. The thing is that, even though the proxy code itself is opensource, the functionality of the plugin is basicaly behind a paywall. We are not talking about support. Actual functioning of the plugin after compiling from sources depends on license availability and there is no option to select no support or something along the lines "I built it myself from sources". Without patching the code even though the proxy is otherwise functional the backups won't work because of missing license. Hopefully the powers that can will provide an acceptable albeit community supported way to use the proxy cleanly, without touching license checks. Best regards!

Then, my earlier suggestion about upgrading was wrong, sorry, better to say so before you spend an evening on it. I went and read the RPU code (it's about time!): shutdownPinnedVms only handles VM_HAS_PCI_ATTACHED, VM_HAS_VGPU and VM_HAS_SRIOV_VIF, and when anything else turns up, it hands back to XAPI's CANNOT_EVACUATE_HOST on purpose. VM_REQUIRES_SR is not in that list, so an upgrade will not move you past it. On the Rolling Pool Update side, the docs say all VM disks have to be on shared storage (https://docs.xcp-ng.org/management/updates), and the host reboot guide defines an agile VM as one not tied to local storage or local devices (https://docs.xcp-ng.org/guides/host-reboot). With everything on local NVMe, that reads to me like RPU is closed to you by design rather than by bug. The route the docs give for your case is the manual one: disable the host, shut the VMs down or migrate them, then reboot. The Smart Reboot message looks like a separate problem. In XO's smartReboot a VM counts as suspend blocked in two different cases, either when blocked_operations.suspend is set, or when XAPI itself refuses VM.assert_operation_valid for suspend. The message only describes the first, which might be why clearing the protection changed nothing. These two will show which one you are in: xe vm-list is-control-domain=false params=name-label,blocked-operations xe vm-list is-control-domain=false power-state=running params=name-label,allowed-operations If suspend is missing from allowed-operations, then XAPI is refusing it rather than a flag you set. I ran both on 8.3, so I know they print something per VM. I have not tested any of this on a two-host pool, though, so the VM_REQUIRES_SR part is my reading of the code rather than something I reproduced.

Pour l'ISO montée deux fois : My bad, j'ai ajouter un truc en trop sur mon précédent fix. Une PR est en cours pour corriger ça. Pour le problème principal : J'ai identifié la cause, mais je n'ai pas encore de solution. Sans les drivers Xen (non initialisés avant l'installation), une VM est limitée à 4 périphériques. La séquence de boot ne peut donc pas détecter le second disque contenant le fichier Kickstart (ks). Côté Packer, on semble être bloqués par cette contrainte XCP-ng. Les seules alternatives actuelles seraient de se limiter à : 2 disques + 2 CD ou 3 disques + 1 CD + HTTP (Note : L'installation manuelle fonctionne car l'installateur démarre directement, avec le driver xen_blkfront, alors qu'avec Packer, l'injection de notre fichier interrompt le flux de démarrage classique). Je vais fouiller encore un peu, mais sans certitude d'un contournement possible. (et je regarde pour ajouter le CDlabel)

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!

Hello @poddingue and @Team-XAPI-Network is there anything else to check?

@neal https://github.com/vatesfr/xen-orchestra/issues/10260

@acebmxer No problem, that's excellent news, thanks for the feedback!

After a good sleep, I resolved half of my issue. I got my LSI Cards messed up, I accidentally hidan internal LSI3108 (Address 01:00.0) instead of the PCI Card LSI3008 (Address 05:00.0)... My Boot Drives run off of the internal card. From the fallback kernel, I was able to Modify /etc/grub-efi.cfg to remove the internal card form the hidden list. I now have a separate issue, but will make another post.

Question for @Team-XO-Backend

@MajorP93 Last Message from Veeam: Veeam Support - Case # 08187386 thank you for your email! We are currently waiting for R&D team conclusion, and a bit more time is required for the investigation. I am sorry for the possible inconveniences here! Best regards, Viktoria Nesmiyanova Technical Customer Support - EMEA Veeam Software

It's more like "partially"/loosely based on Alma (10, not 9). And yes, the kernel will be far more recent, same for Xen and so on.

I put both of your questions on a spare host, because I couldn't answer either from memory. On colons: xe creates a key literally called auto_poweron:true with an empty value, so the entries you saw were three separate keys and none was the real auto_poweron, and typing false afterwards just made another one. It exits 0 and prints nothing every time, which I'd call a rough edge rather than a feature, though other-config is free-form by design so I don't know that the CLI is meant to validate keys at all. On the sleep: with rc.local executable and no sleep, it fired at 16 seconds of uptime and xe appliance-start came back with Error: Connection refused (calling connect ), exit 1, in under a tenth of a second. The VM stayed halted and nothing was reported anywhere, since rc.local has no terminal to print to. rc-local.service only orders after basic.target and network.target, nothing toolstack-related, while xapi-wait-init-complete.service took 30 seconds on that host, which is presumably why 60 was barely enough for you. There's an xapi-init-complete.target that looks like the right thing to order a unit against instead of guessing at a delay, though I haven't tried it so treat that as a lead rather than advice. The executable-bit half is in the docs now, it went onto the troubleshooting page after you reported it: https://docs.xcp-ng.org/troubleshooting/common-problems

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.

I forgot to mention: XOA Premium Current version: 6.6.2 (stable channel)

For anyone who finds this in the future, I ran into a similar issue today when passing through a LSI Card, Coincidentally on Address 05:00.0, also coincidentally on a Supermicro Board (mine is X10DRH-CT, OPs was a X8DA8) I was originally writing a comment here to see if a solution had ever been found, but while taking/marking up screenshots of my Motherboards System Block Diagram, I discovered my problem... Human Error of course. Long story short, I added a PCI to 2xM.2 card, and in my BIOS, I bifurcated the wrong CPU/PCI Port. Instead of Bifurcating the M.2 Card, I accidentally Bifurcated the LSI Card, which caused the Unknown Header Error AND since there was an unknown header, the VM Would throw the "Device or Resource is busy" error when trying to start. Correcting the Bifurcation fixed the issue in my case. Not sure if that was the issue in OPs case, but this might help someone else who stumbles across this

Any update on this? It is a drawback. It is also in the wrong format under snapshots. XO 5 has the format: July 17, 2026 or 2026-07-17 depending on the screen.

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.