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

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

@poddingue said: What I can't tell you is what set that particular combination on your VM in the first place. Does it ring a bell? I have no Idea. I had it on "Protect from accidental shutdown" but turned that off again, later. Doing this again (on, off) helped, as you said. Thank you so much!

@MajorP93 Ok. Thanks!

@dsauce To test your theory out on my issue i just tried to disable CBT on XOA side and one vm gave me this error... vdi.set { "id": "11286a97-b773-4ec4-a0b7-464ab87254ca", "cbt": false } { "code": "UUID_INVALID", "params": [ "VDI", "a52fe4ab-edc2-4975-a118-f6db84435379" ], "call": { "duration": 1, "method": "VDI.get_by_uuid", "params": [ "* session id *", "a52fe4ab-edc2-4975-a118-f6db84435379" ] }, "message": "UUID_INVALID(VDI, a52fe4ab-edc2-4975-a118-f6db84435379)", "name": "XapiError", "stack": "XapiError: UUID_INVALID(VDI, a52fe4ab-edc2-4975-a118-f6db84435379) at Function.wrap (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/_XapiError.mjs:16:12) at file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/transports/json-rpc.mjs:38:21 at runNextTicks (node:internal/process/task_queues:64:5) at processImmediate (node:internal/timers:452:9) at process.callbackTrampoline (node:internal/async_hooks:130:17)" } Another vm.. vdi.set { "id": "966fe072-4865-48a2-867a-0eb59b23dcc7", "cbt": false } { "code": "UUID_INVALID", "params": [ "VDI", "d6662a49-0d65-4c4b-a8fa-cddd42ab4cd5" ], "call": { "duration": 1, "method": "VDI.get_by_uuid", "params": [ "* session id *", "d6662a49-0d65-4c4b-a8fa-cddd42ab4cd5" ] }, "message": "UUID_INVALID(VDI, d6662a49-0d65-4c4b-a8fa-cddd42ab4cd5)", "name": "XapiError", "stack": "XapiError: UUID_INVALID(VDI, d6662a49-0d65-4c4b-a8fa-cddd42ab4cd5) at Function.wrap (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/_XapiError.mjs:16:12) at file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/transports/json-rpc.mjs:38:21 at runNextTicks (node:internal/process/task_queues:64:5) at processImmediate (node:internal/timers:452:9) at process.callbackTrampoline (node:internal/async_hooks:130:17)" } Update - after backup completed with warnings i looked back and CBT was re-enabled in XOA. Did not help with my Veeam issues.

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!

Welcome to the forum, and thanks for writing this up instead of just fixing it on your own box. You already found the thread I was going to point you at. You're ahead of me there. What happened in it after the part you read: Olivier bisected the problem down to Linux 6.12.5, and Teddy linked an upstream fix that landed in tip (f24df84cbe05), with no ETA for when distros pick it up. The tsc_mode=2 plus nomigrate workaround came out of that, and it carries the live migration cost you already spotted. One thing I'd like to know, and I don't think anyone has tried it on your side. Does the leftover couple of seconds per vCPU go away if you set tsc_mode=2 on one of those VMs? If it does, that would tie your case to the same regression rather than to a second thing. I'm not deep enough in the timer code to tell you whether the ttyS0 amplification and the TSC regression are the same mechanism or two things stacking. Probably worth a mention to @Team-Hypervisor-Kernel so someone who is can have a look.

@poddingue Thank you for the analysis. I'd give you a rep if I could

If the list is only complete after you've been through the Storage view first, that smells like the VM view not loading the whole SR collection, so the dialog only knows about the SR the disk already sits on. I could easily be wrong about the mechanism though. 6.7.0 went out on 30 July, so it would help to know whether it still does this there, and whether anyone else on 6.6.2 sees the same thing. Might be worth a mention to @Team-XO-Frontend, since they'd know straight away whether that dropdown is meant to come from a shared collection or get fetched per view. The nearest thing I found in the tracker is https://github.com/vatesfr/xen-orchestra/issues/7392, but that one is ISO SRs turning up in the wrong list rather than SRs going missing, so probably not the same thing.

Your xe host-list output kills my guess. All three addresses are real LAN IPs with nothing on loopback, so the loopback is probably coming from the XO side rather than from XAPI. I did test one thing: given a name that resolves to both families, Node reports connect ECONNREFUSED ::1:443 and connect ECONNREFUSED 127.0.0.1:443 together, which is what your log shows, while the literal 127.0.0.1 only ever names one address. That suggests something is handing XO a name rather than an IP, and localhost is the obvious candidate, so it's worth checking what you have registered for that pool under Settings then Servers, which is where the address comes from in the first place: https://docs.xen-orchestra.com/xo5/manage_infrastructure#add-a-host . The migration failure I'd keep separate for now, and could you paste the exact error XO gives when one fails? I don't know whether the two are the same problem and I'd rather have the text than keep making wild guesses.

@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

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

Possibly related observation from an Intel pool (Xeon Gold, XCP-ng 8.3): Ubuntu 26.04 cloud image (kernel 7.0, UEFI) shows a similar-looking freeze at "installing Xen timer for CPU N". In my case console=ttyS0 from the cloud image's default cmdline amplified it ~7x — removing it dropped the sched_clock correction from 143s to 16s on 8 vCPUs, and unlike tsc_mode=2 it keeps live migration. Not sure it's the same root cause, but might be worth checking cmdline for those hitting this with cloud images.