@florent Great work, thanks for the fixes

So you have to dig in the SMlog to check what's going on

@DustinB Been using it since 2012, non-profits fell under the academic tier and it was originally by number of cpu which was 2 cpu per host, under 192G ram but again didnt include vmotion etc, just plain ole esxi why I used Veeam since it brought replication into the mix again still using them at a very low cost. They had essentials and essentials plus and the academic pricing was very low, my understanding is they would rather you use VMware vs something else. Again I have receipts going back to 2012, pretty much same price for all these years until Broadcom entered the picture. There was nothing sus about it, you had to verify your non-profit category and fit within the limts, it was pretty standard pricing for a low number of cores, I could go to CDW or any reseller and get the same pricing. Why you have so many small companies jumping ship many were using vmware essentials which was WAY cheaper then what they are doing now which the only option is Standard and it now requires min of 16 cores per host @$50/core. That is the new and wonderful world of Broadcom... Anyway, this was pretty common stuff under VMware, why so many folks were using it, even the small shops.

@dnikola The AQC113 10G card (from your vendor) also support 2.5G with the driver loaded.

Mine was working on the latest commit however tonight due to a power failure my XO VM rebooted and now i too am experiencing the same errors. My hosts also rebooted as a result. Rolled back to a build from earlier this month and all is well again.

Hello. @JamfoFL said in Xen Orchestra from Sources unreachable after applying XCPng Patch updates: This is very odd. When I check to see if the Orchestra status is running, everything looks OK: [image: 1752072112055-5c529c8c-8f2b-4c79-806c-daa2b8398847-image.png] This doesn't look ok. The process behind this service has actually exited. Suggest you start/restart this service and check if XO is reachable. If it's not, dive into the logs and look for clues why the process is exiting. You may want to also try manually running /etc/init.d/orchestra and see if that produces any helpful output. But when I try to run the command you sent over, I get an error message stating "Unit xo-server.service" could not be found". However, when I check in the very same folder from which I am running the command, I can see xo-server.service right there. Not taking away from the points others have made about .service files needing to be in the correct location, but in your case, worrying about the xo-server.service file is probably a dead end. It appears whoever installed XO created the systemd service as orchestra. You needn't try and "fix" the fact you don't have an xo-server.service. .joel

I did it that way so as to get the old Citrix driver first, and then let it update and watch it reboot. That was my logic anyway. @dinhngtu said in Migrating from XCP-ng Windows guest tools to Citrix: @bberndt Okay, I managed to reproduce your situation. I think it's because the "driver via Windows Update" option was enabled after installing the XS drivers, which caused the drivers to lock onto the non-C000 device and prevent updates from coming in. Normally, XenClean should be able to fix the situation. But if you want to fix things manually, or if things still don't work (C000 is still not active), here's a procedure that should fix the problem: Take a snapshot/backup/etc. Keep a note of static IP addresses (if you have any; there's a chance those will be lost). You can also use our script here: https://github.com/xcp-ng/win-pv-drivers/blob/xcp-ng-9.1/XenDriverUtils/Copy-XenVifSettings.ps1 Reboot in safe mode and disable the non-C000 device. Reboot back to normal mode; it'll ask you to reboot a few more times. The C000 device should now be active and you should be able to get driver updates again. (Optional) You can now enable and manually update the non-C000 device (Browse my computer - Let me pick).

@robyt are you using full backus ( called "backup" ) on the source ? because incremental mirror will transfer all the backups generated by a "delta backup" whereas it's the first transfer or the following delta (our terminology can be confusing for now)

@gb.123 Interesting -- alert the XCP-ng team to take a closer look, if they haven't seen this already.

@frank-s yes please the more detailed the bug report is, the easier it is to fix

@dinhngtu Thank you so much. If you want me I'll be at the pub.

Excellent!

@andriy.sultanov After running that command I didn't have anything returned.

@AtaxyaNetwork It will/it does

@olivierlambert You got it, I'll do that. Thank you.

hmm, I found the solution, after I read here on forum. I enable this options and save and then disable and save and now is ok. Task is running again. It is running with last commit to So the problem is with these settings which may not exist in the task created before the update. [image: 1751377404079-05b77f69-6e87-49d2-9c62-d795a13d161a-image.png]

Then try to find anything happening around that time on other hosts, equipment, storage and so on.

Excellent news, thanks for the feedback!

@icompit Thank you. It seems that the backup process fails to get the file lock on the backup directory. Have you modified anything on your remote recently? Also, could you tell me if this is happening on all of this job's runs, all of your backup runs, or if it only happened once on this specific backup job execution?