@JSylvia007 Sorry, I'm really late to this thread, but note that backups can become problematic if the SR is something like 90% or more full. There needs to be some buffer for storage as part of the process. The fact you could copy/clone VMs means your SR is working OK, but backups are a different situation. If need be, you can always migrate VMs to other storage which is evidently what you ended up doing, which frees up extra disk space. Also backups are pretty intensive so make sure you have both enough CPU capacity and memory to handle the load. Finally. a defective SR will definitely cause issues if there are I/O errors, so watch your /var/log/SMlog for any such entries.

@MathieuRA Think this is what you were looking for? I tried both with ndjson boolean set to false and true same output... [image: 1774629796944-screenshot-2026-03-27-124309.png] [image: 1774629830992-79100bc0-ad51-48df-9e44-f6bbd912f44d-image.jpeg] { "quickInfo": { "id": "613f541c-4bed-fc77-7ca8-2db6b68f079c", "power_state": "Halted", "uuid": "613f541c-4bed-fc77-7ca8-2db6b68f079c", "name_description": "some-random-description", "CPUs": { "number": 1 }, "mainIpAddress": "10.1.6.166", "os_version": { "name": "Alpine Linux v3.21" }, "memory": { "size": 536870912 }, "creation": { "date": "2025-10-23T14:12:05.689Z", "user": "e531b8c9-3876-4ed9-8fd2-0476d5f825c9" }, "$pool": "b7569d99-30f8-178a-7d94-801de3e29b5b", "virtualizationMode": "hvm", "tags": [], "host": "b61a5c92-700e-4966-a13b-00633f03eea8", "pvDriversDetected": false, "startTime": null }, "alarms": [], "backupsInfo": { "lastRun": [ { "backupJobId": "399f368a-a550-4cdf-9c5b-84b68912b748", "timestamp": 1762124447136, "status": "success" }, { "backupJobId": "399f368a-a550-4cdf-9c5b-84b68912b748", "timestamp": 1762038039074, "status": "success" }, { "backupJobId": "399f368a-a550-4cdf-9c5b-84b68912b748", "timestamp": 1761951645862, "status": "success" } ], "vmProtected": true, "replication": { "id": "8c2b7a25-70b9-4a1c-d6e0-9cce86d3171a", "timestamp": 1761302770000, "sr": "4cb0d74e-a7c1-0b7d-46e3-09382c012abb" }, "backupArchives": [ { "id": "1af95910-01b4-4e87-9c2f-d895cafe0776//xo-vm-backups/613f541c-4bed-fc77-7ca8-2db6b68f079c/20251102T230026Z.json", "timestamp": 1762124426346, "backupRepository": "1af95910-01b4-4e87-9c2f-d895cafe0776", "size": 0 }, { "id": "1af95910-01b4-4e87-9c2f-d895cafe0776//xo-vm-backups/613f541c-4bed-fc77-7ca8-2db6b68f079c/20251101T230026Z.json", "timestamp": 1762038026319, "backupRepository": "1af95910-01b4-4e87-9c2f-d895cafe0776", "size": 0 }, { "id": "1af95910-01b4-4e87-9c2f-d895cafe0776//xo-vm-backups/613f541c-4bed-fc77-7ca8-2db6b68f079c/20251031T230025Z.json", "timestamp": 1761951625256, "backupRepository": "1af95910-01b4-4e87-9c2f-d895cafe0776", "size": 0 } ] } } No links 400 Bad request

@TeddyAstie I hadn't seen anything special was needed in a VM other that a kernel new enough for support which 6.17 has, is there more to the story with adding things to Ubuntu?

@florent Since both jobs were test jobs that i have been running manually, i do have an unnamed and disabled schedule on both that does look identical, so i unintentionally did have multiple jobs on the same schedule. I have since named the schedule within my test job so to each is unique. Updating to "f445b" shows improvement: I was able to replicate from pool A to Pool B, then run a backup job which was incremental. I then ran the replication job again which was incremental and did not create a new VM! Unfortunately though after this i ran the backup job again which resulted in a full backup from the replica rather than a delta, not sure why. The snapshot from the first backup job run was also not removed, leaving 2 snapshots behind, one from each backup run. [image: 1774618641909-e38c23b0-4259-4d16-9ed3-fa44d8490541-image-resized.jpeg] I then tried the process again. Ran the CR job, which was a delta (this part seemed fixed!) then ran the backup job after, same behavior, a full ran instead of a delta and the previous backup snapshot was left behind leaving the VM looking like: [image: 1774618909029-7edf1dba-e729-4b52-abcc-ffde76d8a0bb-image-resized.jpeg] So it seems one problem solved but another remains.

Thanks for the quick answer @mathieura

@planedrop Pretty sure the official and recommended way is to use the V2V (VMWare to Vates) tool that is baked into Xen Orchestra. I used that tool back when I migrated from our old VMWare Cluster to the new XCP-ng environment. It worked without any issues. Best approach IMO would be to disconnect the unneeded virtual disks on the source VM on VMWare side and then use V2V tool to migrate over the VM. I did it this way for a VM with disk bigger than 2TB aswell. After migrating the VM I created an LVM volume on the XCP-ng VM with the required size and rsync-ed the remaining data from VMDK > 2TB to target XCP-ng LVM volume. Documentation: https://docs.xen-orchestra.com/v2v-migration-guide

I have two PE R630 and one PE R730xd. The two R630s show the IPMI data in XO but the R730xd does not. If I run ipmitool sensor from an ssh session, I get very similar data back on the 730 and 630. This isn't critical to me, just letting you know that there are cases that functioning ipmitool on a Dell does not seem to be enough to show it. There are some differences in the labels. The R730 has "Fan1 RPM", "Fan2 RPM" while the R630 has "Fan1A", "Fan2A", "Fan1B". Most of the other interesting fields seem to have the same names but the order is a bit different and I didn't do an exhaustive comparison. It's very cool that you are surfacing this data now.

We are running Xen Orchestra with commit c3dcb and the auth-oidc (v0.4.2) plugin. The users that login are unique and not yet present as local users. The OICD provider is SURF with SRAM: https://www.surf.nl/en/services/identity-access-management/surf-research-access-management They support the following attributes/scopes: https://servicedesk.surf.nl/wiki/spaces/IAM/pages/74226142/Attributes+in+SRAM There are some IPs that need to be accessable: https://servicedesk.surf.nl/wiki/spaces/IAM/pages/74226067/IP+addresses#IPaddresses-OIDC . Outgoing traffic from the server to port 443 is open and works. We did try several settings for the Username field and scopes. For example the following: [image: 1774600482742-plugin-resized.png] This should create a user R123456789 The logging shows the following: mrt 27 09:29:48 vm-xoa xo-server[2641104]: Expected values to be strictly equal: mrt 27 09:29:48 vm-xoa xo-server[2641104]: + actual - expected mrt 27 09:29:48 vm-xoa xo-server[2641104]: + 'undefined' mrt 27 09:29:48 vm-xoa xo-server[2641104]: - 'string' If we change it to: [image: 1774600514661-plugin-2-resized.png] The following shows up: mrt 27 09:32:21 vm-xoa xo-server[2641104]: Cannot read properties of undefined (reading '0') I hope this helps to understand the problem. Thanks.