@florent Thanks, had to put the DFIR hat on. May as well ask as I thought about a PR for this - would it be feasible/practical/desirable to allow this to be done from XO's UI? I don't know how much of an edge case this was for me, but being able to remove "other-config" data following a migration (e.g. you do what I did and want the VMs to start over independently on a new host) might be beneficial to others. Obviously it would be quite destructive I imagine, if used inappropriately. Even just reporting those ghostly associations would be nice - again not sure of your overall design ethos so there may be good reasons why it's not a solid idea.

@olivierlambert as the driver provided by @andrew is based on upstream r8125 version 9.016.01 and seems to solve the issue of user @paha I was wondering: are there any plans to update the driver to latest upstream version in official XCP-ng package repository?

@simonp [info] Updating Xen Orchestra from 'cb85e44ae' to 'eed3d72f7' First log is from automatic schedule before latest update. 2026-02-17T18_00_00.012Z - backup NG.txt latest log after update. Backup completed successfully. 2026-02-17T18_22_52.199Z - backup NG.txt

I have two few vms doing this on 1 pool. Logs from the last 3 runs. 2026-02-18T03_00_00.018Z - backup NG.txt 2026-02-18T04_21_30.814Z - backup NG.txt 2026-02-18T12_01_21.452Z - backup NG.txt

@ThasianXi Hello, thanks for the report. It looks like the pull image step fails. Can you test that the token generated from Github is working and allows to pull the image. Maybe a simple test on a docker install could ease the verification: docker login ghcr.io -u USERNAME -p TOKEN docker pull ghcr.io/vatesfr/xenorchestra-csi:v0.0.1 Also note that only "Classic" persona access token are supported. More doc here https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry#authenticating-with-a-personal-access-token-classic