@christopher-petzel Great news! I will test and report after it is available in a global update. Thank you Christopher.

@dinhngtu said: @john.c I'll consider adding relevant GPOs for this. There's no real complexity difference compared to normal Registry settings. As for event logs, what information do you need? The various guest agents already report via Event Log exclusively. @dinhngtu That is fantastic news regarding the GPOs—having native administrative template support will be a huge win for enterprise deployments! Regarding the Event Logs, my apologies for the ambiguity; I am aware the agents use Event Logs internally. The issue from a fleet management perspective is that when everything is running normally, the logs are quiet, but when a breakdown happens (like a VM losing its IP reporting, or an auto-update breaking xenflt), finding why it failed from a central monitoring system is difficult. To make the Event Logs highly actionable for SIEMs, monitoring agents, and automated alerting, having explicit Event IDs for the following critical lifecycle and failure states would be incredibly useful: Management Lifecycle & Heartbeats Service Lifecycle: Distinct Event IDs for a clean initialisation/handshake with the hypervisor vs. an unexpected service termination. IP/Network Metrics Reporting: An error or warning Event ID raised if the agent fails to bind to the guest network stack or fails to transmit the IP metrics to Xen Orchestra after a specific timeout window. Backup & VSS Operations Quiesced Snapshots: Dedicated Event IDs tracking when a VSS / quiesced snapshot request is received from the host, whether it succeeded, or a specific error ID if it times out or fails (which often causes backup failures on the XO side). Driver & Filtering Health UpperFilters Validation: A warning or error Event ID if the agent detects that its driver filters (like XENFLT) are missing from the registry or have been overwritten by a Windows Update cycle. Upgrade & Missing Tool States “Installed but Inactive" Detection: An alert Event ID if the agent service is running but cannot detect active underlying PV drivers. This is critical for catching scenarios where major Windows or Windows Server feature updates silently strip out driver components without running a proper uninstaller, leaving sysadmins caught flat-footed with a broken stack. Providing explicit, documented Event IDs for these states would allow sysadmins to build standard Windows Scheduled Tasks or monitoring rules (e.g., automatically restarting the Xen Guest Agent service the moment a specific "Failed to report metrics" Event ID is caught).

@andriy.sultanov @andriy.sultanov said: @pandusen As Teddy said above, you can't passthrough a PCI bridge, so there's no PCI devices xapi shouldn't omit here. I am not trying to pass through the bridge only the end points. The Intel arc's have 2 end points: The GPU and the Sound device. "xe pci-list" only reveals the GPU, not the sound device. (this works for nvidia and AMD) But "going the xen-cmdline way" shouldn't break anything, that's what xe pci-disable-dom0-access does behind the scenes. What issues did you see? Which steps did you follow? the sound device is available in the lspci list and can be passed through using CLI. But doing so, (using CLI for passtrough) undoes everything done using xe or the passthrough gui in XO. and results in this: https://xcp-ng.org/forum/topic/10609/xcp-ng-8.3-pci-passthrough-issue so yes, its does break something.

Hard reboot sorted itself out

I have also opened a support ticket with Veeam. Well trying to... Issue with my account preventing me to and working to fix that issue. Veeam forum did make this statment about CBT and snapshots - There is one known snapshot issue that I'm guessing could possibly have this side-effect (noted in the release notes BTW). We take standard Xen snapshots for CBT but then immediately rename them with our own naming convention. We've noticed that sometimes this rename operation returns success status even if it fails. In this case I can see how this might throw this sort of error but again best to confirm w/support Veeam support ticket - 08188639 Update from Veeam - Thanks for the update I'm currently checking with my team and I will update as soon as possible, what I noticed in the debug logs is the following API failing \Backup\Plugins\XEN\Backup\Backup Job 1\Delilah ArcDC02 with debug enable 2026-08-07 20:05:04.067 00006 DEBUG | [BackupService]: <== Request localhost:19000, IsTaskFinished, body: {"taskId":"491371d9-4699-4087-b549-9862d2188177"} 2026-08-07 20:05:04.067 00006 DEBUG | [BackupService]: ==> Response localhost:19000, IsTaskFinished, success, duration: 0.1404 msec, body: false 2026-08-07 20:05:04.843 00019 INFO | [XenRpcClient]: Start ListChangedBlocks 2026-08-07 20:05:04.843 00019 DEBUG | [XenRpcClient]: <== Request https://192.168.20.3/Async.VDI.list_changed_blocks, body: ["OpaqueRef:b77ca409-d438-d97e-d8c3-f212647ad469","OpaqueRef:8c83f698-8836-3b4c-1506-8e97315aae1f"] 2026-08-07 20:05:04.845 00019 DEBUG | [XenRpcClient]: ==> Response https://192.168.20.3/Async.VDI.list_changed_blocks code: "OK", duration: 2 msec, body:{"opaque_ref":"OpaqueRef:c9389aa3-552a-0aa4-a5bc-f9b4f7a40e98"} 2026-08-07 20:05:04.845 00019 DEBUG | [XenRpcClient]: <== Request https://192.168.20.3/task.get_record, body: ["OpaqueRef:c9389aa3-552a-0aa4-a5bc-f9b4f7a40e98"] 2026-08-07 20:05:04.847 00019 DEBUG | [XenRpcClient]: ==> Response https://192.168.20.3/task.get_record code: "OK", duration: 2 msec, body:{"uuid":"72b5eb58-5053-d77a-9ee9-089ffaed4541","name_label":"Async.VDI.list_changed_blocks","name_description":"","allowed_operations":["cancel"],"current_operations":{},"created":"2026-08-08T00:05:04Z","finished":"1970-01-01T00:00:00Z","status":"pending","resident_on":"OpaqueRef:05e44734-86d0-c9f6-5079-25633df7bf06","progress":0.0,"type":"<none/>","result":"","error_info":[],"other_config":{},"subtask_of":"OpaqueRef:NULL","subtasks":[],"backtrace":"()","opaque_ref":null} 2026-08-07 20:05:04.848 00019 DEBUG | [XenRpcClient]: Current task Async.VDI.list_changed_blocks:72b5eb58-5053-d77a-9ee9-089ffaed4541. Status: "pending" Progress: 0 2026-08-07 20:05:06.848 00018 DEBUG | [XenRpcClient]: <== Request https://192.168.20.3/task.get_record, body: ["OpaqueRef:c9389aa3-552a-0aa4-a5bc-f9b4f7a40e98"] 2026-08-07 20:05:06.850 00018 DEBUG | [XenRpcClient]: ==> Response https://192.168.20.3/task.get_record code: "OK", duration: 1 msec, body:{"uuid":"72b5eb58-5053-d77a-9ee9-089ffaed4541","name_label":"Async.VDI.list_changed_blocks","name_description":"","allowed_operations":[],"current_operations":{},"created":"2026-08-08T00:05:04Z","finished":"2026-08-08T00:05:05Z","status":"failure","resident_on":"OpaqueRef:05e44734-86d0-c9f6-5079-25633df7bf06","progress":1.0,"type":"<none/>","result":"","error_info":["SR_BACKEND_FAILURE_460","","Failed to calculate changed blocks for given VDIs. [opterr=Source and target VDI are unrelated]",""],"other_config":{},"subtask_of":"OpaqueRef:NULL","subtasks":[],"backtrace":"(((process xapi)(filename lib/backtrace.ml)(line 210))((process xapi)(filename ocaml/xapi/storage_utils.ml)(line 150))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 141))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 39))((process xapi)(filename ocaml/xapi/rbac.ml)(line 228))((process xapi)(filename ocaml/xapi/rbac.ml)(line 238))((process xapi)(filename ocaml/xapi/server_helpers.ml)(line 78)))","opaque_ref":null} 2026-08-07 20:05:06.850 00018 DEBUG | [XenRpcClient]: Current task Async.VDI.list_changed_blocks:72b5eb58-5053-d77a-9ee9-089ffaed4541. Status: "failure" Progress: 1 2026-08-07 20:05:06.850 00018 DEBUG | [XenRpcClient]: <== Request https://192.168.20.3/task.destroy, body: ["OpaqueRef:c9389aa3-552a-0aa4-a5bc-f9b4f7a40e98"] 2026-08-07 20:05:06.851 00018 DEBUG | [XenRpcClient]: ==> Response https://192.168.20.3/task.destroy code: "OK", duration: 0.735 msec, body:"" 2026-08-07 20:05:06.851 00018 ERROR | [XenRpcClient]: Failed ListChangedBlocks. Error: [Task 72b5eb58-5053-d77a-9ee9-089ffaed4541 (Async.VDI.list_changed_blocks) failed: . SR_BACKEND_FAILURE_460. . Failed to calculate changed blocks for given VDIs. [opterr=Source and target VDI are unrelated]. Veeam.Vbf.Common.Exceptions.ExceptionWithDetail: [Task 72b5eb58-5053-d77a-9ee9-089ffaed4541 (Async.VDI.list_changed_blocks) failed: . SR_BACKEND_FAILURE_460. . Failed to calculate changed blocks for given VDIs. [opterr=Source and target VDI are unrelated]. ---> Failed to calculate changed blocks for given VDIs. --- End of inner exception stack trace --- at Veeam.XenBackup.RestClient.XenRpcClient.GetTaskResult(XenRef`1 taskRef, CancellationToken cancellationToken) at Veeam.XenBackup.RestClient.XenRpcClient.<>c__DisplayClass94_0.<<ListChangedBlocksAsync>b__0>d.MoveNext() --- End of stack trace from previous location --- at Veeam.Vbf.Common.Helper.Retry.RetryHelper.ExecuteActionAsync[T](Func`2 asyncAction, String description, ILogger logger, LogLevel logLevel, CancellationToken cancellationToken) 2026-08-07 20:05:06.851 00018 INFO | [XenRpcClient]: Retry after 10 sec. Retry 6/10 for ListChangedBlocks There is a XEN forum and guide from him, but I need to check internally as first https://docs.xenserver.com/en-us/xenserver/developer/changed-block-tracking-guide/troubleshoot.html#you-cant-list-changed-blocks-between-two-vdi-snapshots CBT: the thread to centralize your feedback | XCP-ng and XO forum https://xcp-ng.org/forum/topic/9268/cbt-the-thread-to-centralize-your-feedback/364 Regards Update - Veeam came back and suggested I power off the vms with the warrning and power back on. This cleared the error for 2 out of the 4 vms. 1 vm still showed the error the other vm i was not able to power off at that time. @olivierlambert - From veeam... After checking with my team, is it possible if you can engage XEN support on this, I checked some of the XEN forum including the KB article about how to troubleshoot CBT errors, seems to be a clean metadata that can be done from their side Troubleshoot Changed Block Tracking | Develop for XenServer CBT: the thread to centralize your feedback | XCP-ng and XO forum Regards Looks like our issue may be different at the end even with involving CBT... Let me know if i should continue in a new post. Support ticket created - Ticket#7762393

@bogdantomasciuc Hello, Yes my script does offer to install xo-proxy and handles some of the licensing issues. You may give my script a try and let me know if you having any further issues i can try to work them out. I advise setting up a new vm for XO as the two script are not compatible that i am aware of. https://xcp-ng.org/forum/topic/11895/install-xo-from-sources. https://github.com/acebmxer/install_xen_orchestra/

@irtaza9 i would look a the usual suspect, /var/log/SMlog /var/log/xensource.log see https://docs.xcp-ng.org/troubleshooting/

What kind of storage are you using? Is it a 4K block native storage? You should be able to see if you can create a virtual disk easily with xe vdi-create name-label=test virtual-size=1G sr-uuid=356475ac-…

@flakpyro said: EDIT: The solution here is to get "Power/Performance Bias:" to OS Controlled in the servers BIOS. This restores functionality. hey nice ! I did the modification on a slave server and I now have all informations (previously FAILED) [image: 1786472883253-32aede5f-d4bb-44fd-acad-029715ca1bdf-image.jpeg] it's an HPE DL380 Gen 11 modified in the iLO web ui, but then needed to reboot host was previously on DYNAMIC POWER SAVINGS [image: 1786472960757-f2d02bca-04eb-4a06-8844-c073e9d9b93a-image.jpeg]

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

Déja une piste intéressante, on dirait que pour une raison quelconque l'iso est mount deux fois [image: 1786437651889-14d66748-1d54-411a-b62a-a3691d6decd9-image.jpeg]

@djingo Hi ! Does all your VMs have guest tools ?

No problem, this is always good to have feedback and cases showing an error and the explanation

@yllar Hello, We are still validating the ISOs, but we are getting closer to releasing them. We hope to make them available soon.

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)

From the log you attached, the failure is on session.login_with_password, and XO tries ::1:443 and then 127.0.0.1:443. So it is XO trying to reach a host, not your remote, and whatever address it holds for that host is resolving to loopback. You rebuilt one of the three nodes and you moved XO into Docker, so my guess is the host came back into the pool with a hostname instead of an IP, and that name does not resolve inside the container the way it did for the script install. It would fit the rest too: migration goes host to host over the management address, copying does not, which is why one works and the other doesn't. Could you paste the output of xe host-list params=uuid,name-label,address? I am guessing here, and @Team-XAPI-Network will know much better than me whether resetting that address is the right move.

Hi, I found your original request. I will make sure someone from the Sales team responds ASAP. Regards, Dan

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.