2 paths we are doing in parallel: We are doing our best to make it upstream in Linux, it's a regression after all. We know how to fix it, so hopefully this will be fixed quickly. Then, we'll have to wait for a Linux kernel update in main distros. Invariant TSC in Xen is also a way to fix it, because we want to improve that anyway. But as Teddy said, it's more work and it will take more time.

Hi @DustinB The VM could be backed up successfully with the same warning about the "disk parent": [image: 1780940195949-delta_test.png] The backup log: { "data": { "mode": "delta", "reportWhen": "never" }, "id": "1780940083480", "jobId": "8326600e-9863-4afa-b724-ae493f564ec8", "jobName": "ITServices-Detla-Test", "message": "backup", "scheduleId": "98f60867-3ac9-4ec5-b0fc-c3fe5520dc1b", "start": 1780940083480, "status": "success", "tasks": [ { "id": "0mq5hqsy6-9uqj9yfb22", "start": 1780940085774, "status": "success", "tasks": [ { "id": "0mq5hqsyx-i5pdr4zkson", "start": 1780940085801, "status": "success", "warnings": [ { "data": { "path": "/xo-vm-backups/011114a9-b622-92eb-581f-36f961efe622/vdis/21bbca2a-59ad-4fa2-bb73-f60c1e9216e7/63a73be5-96ff-4c25-b7dd-c93284719916/20260608T150007Z.vhd", "error": {} }, "message": "failed to read disk parent info" } ], "end": 1780940085910, "result": { "merge": false, "size": 0 }, "message": "clean-vm" }, { "id": "0mq5hqtyu-9l484fbage", "start": 1780940087094, "status": "success", "end": 1780940087947, "result": "396960d5-93e9-670e-e8b5-345283148c0f", "message": "snapshot" }, { "id": "0mq5hqumk-7yfetdkltc2", "start": 1780940087948, "status": "success", "tasks": [ { "id": "0mq5hqvn3-wfuuk0sz1mi", "start": 1780940089263, "status": "success", "end": 1780940089285, "result": { "size": 104448 }, "message": "transfer", "data": { "progress": 100 } }, { "id": "0mq5hr0dj-1l495zk6iys", "start": 1780940095399, "status": "success", "warnings": [ { "data": { "path": "/xo-vm-backups/011114a9-b622-92eb-581f-36f961efe622/vdis/21bbca2a-59ad-4fa2-bb73-f60c1e9216e7/63a73be5-96ff-4c25-b7dd-c93284719916/20260608T150007Z.vhd", "error": {} }, "message": "failed to read disk parent info" } ], "end": 1780940095573, "result": { "merge": true, "size": 0 }, "message": "clean-vm" } ], "end": 1780940095590, "message": "export", "data": { "id": "442a4fc2-70ff-474d-aae9-88d0249ef5f2", "isFull": false, "type": "remote" } } ], "end": 1780940095590, "message": "backup VM", "data": { "id": "011114a9-b622-92eb-581f-36f961efe622", "type": "VM", "name_label": "ITServices", "progress": 0 } } ], "end": 1780940095591, "infos": [ { "data": { "vms": [ "011114a9-b622-92eb-581f-36f961efe622" ] }, "message": "vms" } ] } I am using "smart mode" for backup jobs. The standalone job went through with and without "smart mode". Removing the tag from the VM in question and adding it again did not help. I have also deleted the snapshot linked to the backup job and retried, with no change in behavior. The VM is shutdown and I only turn it on when I need to. During backup it is usually not running. Thanks again. Regards, Marc

@pszelestey Hi, yes, we've pushed an initial commit and a few more here https://github.com/vatesfr/cluster-api-provider-vates/ it is moging every day. Ping us in Matrix/Discord devops if you want to chat live while trying

@poddingue Thank you for the feedback, and suggestion. I will post a request regarding the one-ACL-per-VM issue, as I know it's an issue with our current 600+ VM VMware-to-XCP-ng migration project. Happy Day

@dthenot Thanks a lot for the information. I did some more testing on my end and I've now noticed differences in handling VDI format across different SR types (local LVM and EXT). Should I expect even more differences across remote SR types like LVMoHBA or NFS or are these differences more like block based vs file system based SRs? Any way, it looks like I have to consult the following keys: image-format vdi_type type In my tests, local EXT SRs tend to have only one of them, while local LVM SRs tend to have first two or all three, depends which one was used when creating the VDI.

@danp I see your response to my concern was to add a block on the script being able to run on 8.2, without an update to the elif bug @anthoineb acknowledged. While I can remove your addition and fix that other bug myself, I just wanted to give you some feedback as to why I expressed the issue in the way I did - it wasn't because I feel an entitlement to anything, just sharing my perceptions to @antoineb I have been a xen cli user for a couple of decades, give or take. I moved to xcp-ng with a lot of PV legacy. That was a blocker to using 8.3 straight away, otherwise I would have. The workflow I had established to update the VMs to HVM included adding a new volume for /boot and /boot/efi, and then switching boot OFF on the legacy disk. It was worrying when I went to complete the migration to HVM with the announced EOL of 8.2.1, that suddenly the disks I needed to work with, both legacy and new, had disappeared in XO so I couldn't follow my SOP to move the VMs to HVM, and then proceed to upgrade to 8.3. Given how relatively widespread this issue seems to be, I am surprised that Vates wouldn't treat it as a reputational issue and want to help users to resolve it so that corporates can have confidence to move their cloud to xcp-ng platform, even if they are a startup or in the initial stages of a move and can't yet invest in Pro Support. I note you have a "Pro Support Team" badge, and understand that may not mean you work for Vates, but I gather offer Pro Support. Valuable service. While I am not encouraging this thread to become a marketing channel, it would speak well for xcp-ng, Vates and the Pro Support community if this important issue was handled differently - even if it was "we have tested on 8.2.1 internally and should be able to fix it for you quickly and cost effectively if you join our X plan or request a quote on Y page." I appreciate all you've shared and wasn't being dismissive of your recommendation to upgrade to 8.3, just the timing of this issue - arising right before the EOL of 8.2.1 made that a bit of a "chicken and egg problem". I gather from what you've said on this thread that you don't expect upgrading to 8.3 to be a problem with VDI in this state, so I guess I will just soldier on with creating an xcp-ng CLI SOP to upgrade the remaining PVs to HVM, upgrade to 8.3, and then use the script that has been shared - since you've now made it clear in the code that it shouldn't be run on 8.2. I am thankful that it was shared as guidance, if not a fix in my situation.