@benapetr This is driven by hacky logic from 16 years ago: on revert, unserialize the previous state, and update the VM record with its saved values. As we do not want to modify that each time we add a field in the datamodel, use some low-level database functions to iterate over the fields of a record. Not very nice as it makes some assumptions on the database layer, but seems to work allright and I don't think that database layer will change a lot in the future. I think it might be a good idea to add a revert rpc call to the storage interface that xapi can call to, with a backup to use the current logic if necessary; xapi should be able to clean up the database afterwards. I'll ask other maintainers about this or possible alternatives, but since SMAPIv1 is considered deprecated, I doubt it will happen. I have to say that SMAPIv3 was finally fixed upstream on June by Xenserver (migrations were finally done!) and XCP-ng should get the update that fixes it in the coming weeks. Given this, I would encourage you to take all the learnings you've acquired while doing the driver and porting it to SMAPIv3. SMAPIv1 just simply has too many problems, some of them are architectural, so in general xenserver and xcp-ng maintainers would like to see it finally go away. for now I am still targetting XCP-ng 8.2 as that's what I use in production, and I haven't seen many SMAPIv3 drivers there. 8.2 is out of support for xenserver, and for xcp-ng yesterday was the last day it was supported, you really should update

@Berrick Ah cool, I was anticipating that doing it live would've caused boot issues but I think I've just got a bug in my head about how it actually works, I'm conflating two separate things based on an incorrect interpretation of a previous experience I had once with XCP. Thanks!

I would recommend Intel or Mellanox NICs, and generally avoid Broadcom due to sub-par drivers.

@florent Sep 15 10:00:01 xo1 xo-server[5582]: 2025-09-15T14:00:01.026Z xo:backups:worker INFO starting backup Sep 15 10:00:32 xo1 xo-server[5582]: 2025-09-15T14:00:32.794Z xo:xapi:xapi-disks INFO Error in openNbdCBT XapiError: SR_BACKEND_FAILURE_460(, Failed to calculate changed blocks for given VD Is. [opterr=Source and target VDI are unrelated], ) Sep 15 10:00:32 xo1 xo-server[5582]: at XapiError.wrap (file:///opt/xo/xo-builds/xen-orchestra-202509150942/packages/xen-api/_XapiError.mjs:16:12) Sep 15 10:00:32 xo1 xo-server[5582]: at default (file:///opt/xo/xo-builds/xen-orchestra-202509150942/packages/xen-api/_getTaskResult.mjs:13:29) Sep 15 10:00:32 xo1 xo-server[5582]: at Xapi._addRecordToCache (file:///opt/xo/xo-builds/xen-orchestra-202509150942/packages/xen-api/index.mjs:1073:24) Sep 15 10:00:32 xo1 xo-server[5582]: at file:///opt/xo/xo-builds/xen-orchestra-202509150942/packages/xen-api/index.mjs:1107:14 Sep 15 10:00:32 xo1 xo-server[5582]: at Array.forEach (<anonymous>) Sep 15 10:00:32 xo1 xo-server[5582]: at Xapi._processEvents (file:///opt/xo/xo-builds/xen-orchestra-202509150942/packages/xen-api/index.mjs:1097:12) Sep 15 10:00:32 xo1 xo-server[5582]: at Xapi._watchEvents (file:///opt/xo/xo-builds/xen-orchestra-202509150942/packages/xen-api/index.mjs:1270:14) Sep 15 10:00:32 xo1 xo-server[5582]: at process.processTicksAndRejections (node:internal/process/task_queues:105:5) { Sep 15 10:00:32 xo1 xo-server[5582]: code: 'SR_BACKEND_FAILURE_460', Sep 15 10:00:32 xo1 xo-server[5582]: params: [ Sep 15 10:00:32 xo1 xo-server[5582]: '', Sep 15 10:00:32 xo1 xo-server[5582]: 'Failed to calculate changed blocks for given VDIs. [opterr=Source and target VDI are unrelated]', Sep 15 10:00:32 xo1 xo-server[5582]: '' Sep 15 10:00:32 xo1 xo-server[5582]: ], Sep 15 10:00:32 xo1 xo-server[5582]: call: undefined, Sep 15 10:00:32 xo1 xo-server[5582]: url: undefined, Sep 15 10:00:32 xo1 xo-server[5582]: task: task { Sep 15 10:00:32 xo1 xo-server[5582]: uuid: '6265a41c-29c3-f4d9-5f0c-e52db6e0fcc9', Sep 15 10:00:32 xo1 xo-server[5582]: name_label: 'Async.VDI.list_changed_blocks', Sep 15 10:00:32 xo1 xo-server[5582]: name_description: '', Sep 15 10:00:32 xo1 xo-server[5582]: allowed_operations: [], Sep 15 10:00:32 xo1 xo-server[5582]: current_operations: {}, Sep 15 10:00:32 xo1 xo-server[5582]: created: '20250915T14:00:32Z', Sep 15 10:00:32 xo1 xo-server[5582]: finished: '20250915T14:00:32Z', Sep 15 10:00:32 xo1 xo-server[5582]: status: 'failure', Sep 15 10:00:32 xo1 xo-server[5582]: resident_on: 'OpaqueRef:65b7a047-094b-4c7a-a503-2823e92b9fe4', Sep 15 10:00:32 xo1 xo-server[5582]: progress: 1, Sep 15 10:00:32 xo1 xo-server[5582]: type: '<none/>', Sep 15 10:00:32 xo1 xo-server[5582]: result: '', Sep 15 10:00:32 xo1 xo-server[5582]: error_info: [ Sep 15 10:00:32 xo1 xo-server[5582]: 'SR_BACKEND_FAILURE_460', Sep 15 10:00:32 xo1 xo-server[5582]: '', Sep 15 10:00:32 xo1 xo-server[5582]: 'Failed to calculate changed blocks for given VDIs. [opterr=Source and target VDI are unrelated]', Sep 15 10:00:32 xo1 xo-server[5582]: '' Sep 15 10:00:32 xo1 xo-server[5582]: ], Sep 15 10:00:32 xo1 xo-server[5582]: other_config: {}, Sep 15 10:00:32 xo1 xo-server[5582]: subtask_of: 'OpaqueRef:NULL', Sep 15 10:00:32 xo1 xo-server[5582]: subtasks: [], Sep 15 10:00:32 xo1 xo-server[5582]: backtrace: '(((process xapi)(filename lib/backtrace.ml)(line 210))((process xapi)(filename ocaml/xapi/storage_utils.ml)(line 141))((process xapi)(fi lename 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/x api-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 39))((process xapi)(filename ocaml/xapi/rbac.ml)(line 188))((process xapi)(filename ocaml/xapi/rbac.ml)(line 197))((process xapi) (filename ocaml/xapi/server_helpers.ml)(line 77)))' Sep 15 10:00:32 xo1 xo-server[5582]: } Sep 15 10:00:32 xo1 xo-server[5582]: } Sep 15 10:00:35 xo1 xo-server[5582]: 2025-09-15T14:00:35.240Z xo:xapi:vdi WARN invalid HTTP header in response body { Sep 15 10:00:35 xo1 xo-server[5582]: body: 'HTTP/1.1 500 Internal Error\r\n' + Sep 15 10:00:35 xo1 xo-server[5582]: 'content-length: 318\r\n' + Sep 15 10:00:35 xo1 xo-server[5582]: 'content-type: text/html\r\n' + Sep 15 10:00:35 xo1 xo-server[5582]: 'connection: close\r\n' + Sep 15 10:00:35 xo1 xo-server[5582]: 'cache-control: no-cache, no-store\r\n' + Sep 15 10:00:35 xo1 xo-server[5582]: '\r\n' + Sep 15 10:00:35 xo1 xo-server[5582]: '<html><body><h1>HTTP 500 internal server error</h1>An unexpected error occurred; please wait a while and try again. If the problem persists, please contact your support representative.<h1> Additional information </h1>VDI_INCOMPATIBLE_TYPE: [ OpaqueRef:ec54186c-0ab5-0390-d244-64414e9d8887; CBT metadata ]</body></html>' Sep 15 10:00:35 xo1 xo-server[5582]: } Sep 15 10:00:35 xo1 xo-server[5582]: 2025-09-15T14:00:35.249Z xo:xapi:xapi-disks WARN can't compute delta OpaqueRef:888ccaa8-07c6-e6f0-3bfb-3e6b5ac4da2a from OpaqueRef:ec54186c-0ab5-0390-d2 44-64414e9d8887, fallBack to a full { Sep 15 10:00:35 xo1 xo-server[5582]: error: Error: invalid HTTP header in response body Sep 15 10:00:35 xo1 xo-server[5582]: at checkVdiExport (file:///opt/xo/xo-builds/xen-orchestra-202509150942/@xen-orchestra/xapi/vdi.mjs:36:19) Sep 15 10:00:35 xo1 xo-server[5582]: at process.processTicksAndRejections (node:internal/process/task_queues:105:5) Sep 15 10:00:35 xo1 xo-server[5582]: at async Xapi.exportContent (file:///opt/xo/xo-builds/xen-orchestra-202509150942/@xen-orchestra/xapi/vdi.mjs:244:5) Sep 15 10:00:35 xo1 xo-server[5582]: at async #getExportStream (file:///opt/xo/xo-builds/xen-orchestra-202509150942/@xen-orchestra/xapi/disks/XapiVhdStreamSource.mjs:123:20) Sep 15 10:00:35 xo1 xo-server[5582]: at async XapiVhdStreamSource.init (file:///opt/xo/xo-builds/xen-orchestra-202509150942/@xen-orchestra/xapi/disks/XapiVhdStreamSource.mjs:135:23) Sep 15 10:00:35 xo1 xo-server[5582]: at async #openExportStream (file:///opt/xo/xo-builds/xen-orchestra-202509150942/@xen-orchestra/xapi/disks/Xapi.mjs:128:7) Sep 15 10:00:35 xo1 xo-server[5582]: at async #openNbdStream (file:///opt/xo/xo-builds/xen-orchestra-202509150942/@xen-orchestra/xapi/disks/Xapi.mjs:81:22) Sep 15 10:00:35 xo1 xo-server[5582]: at async XapiDiskSource.openSource (file:///opt/xo/xo-builds/xen-orchestra-202509150942/@xen-orchestra/xapi/disks/Xapi.mjs:191:18) Sep 15 10:00:35 xo1 xo-server[5582]: at async XapiDiskSource.init (file:///opt/xo/xo-builds/xen-orchestra-202509150942/@xen-orchestra/disk-transform/dist/DiskPassthrough.mjs:28:41) Sep 15 10:00:35 xo1 xo-server[5582]: at async file:///opt/xo/xo-builds/xen-orchestra-202509150942/@xen-orchestra/backups/_incrementalVm.mjs:67:5 Sep 15 10:00:35 xo1 xo-server[5582]: }

Hmm could the module causing the crash if the device isn't accessible? @TeddyAstie any opinion?

@Cygace Someone from the community may jump in and help troubleshoot this. The best approach would be to not modify the Dom0 installation by installing Zabbix via a community post, as you're customizing the installation. The vates team and XCP-ng specifically need to include these packages to ensure you're able to get support. Best of luck

I did stick to version: 1 in my working configuration [image: 1757959695876-01998ae9-bb3f-4a3c-b3f6-b1d34ae23704-image.png] Had to rename my "Ethernet 2" nic name to Ethernet2 without the space You have to put the exact template nic name for this to work.

If the message is displayed, there is a reason. Please do a timdatectl status on your XOA

@cgasser are the backup job running normally (if any ) ? can you disable temporary the backup network ? the rrd stats should be visible immediately afte if this is the root cause

What about the browser console?

That's because you are using DMC (dynamic memory control). Try on a VM with static == dynamic.

@KPS Unfortunate, no. I just replicate and avoid moving live VM on the same host, target for replication.

@abudef Got it, the agent was not changed since the last version so the build number was not bumped. I'll keep that in mind for the next release.

@olivierlambert I am asking XO Team about this issue.

@AtaxyaNetwork Did try to change those files and add the missing drivers, but couldn't get it to work with plugins. I think I will just have a look at you image when I have it and see what I am missing

@idar21 @idar21 said in Xen Orchestra 5.110 V2V not working: Don't intend to bump in but the new migration tool isn't working as per the release notes. I had similar issues, there is no warm migration. My testing against esxi v7, resulted in: .Abrupt power off of source VM on esxi. .VM disks start copying. I can see disk copy progress in tasks. .Migration tasks fails but multiple disks of the source VM keeps on copying. .when all the disks are copied, there is no VM with the name available in xcp. .All disks are labeled orphaned under health in xo. .Where is the pause/resume function as stated in the release notes. I don't think the tool has been tested properly. The only difference from older migration tool to this one is progress of disk copying. Otherwise nothing new. The old tool could only do cold migrations and had issues with vms with multiple disks. The new can also only do cold migrations and still has issues with multiple disks migrations. First, I would like to say again that latest can be fresh, and that we know that we ask for our users to be more inventive with latest, in exchange for faster features. Even more for users from source. The documentation is still in the work, and will be ready for sure before this reach "xoa stable". The resume part don't have a dedicated interface : you do a first migration without enabling the "stop source", and then, later you launch the same migration with stop source enabled ( or VM stopped ) and it will reuse the already transfered data if the prerequisites are validated. Then debugging an issue with migration is quite complex, since it's involve multiple systems, and we won't have any access, nor control on the vmware part. It's even harder without a tunnel. I will need you to look at your journalctl and check for errors during migration . Also are the failing disks sharing some specific configuration? what storage do they uses ? Is there something relevant on the xcp side ?

@nikade Yeah, that is a far from optimal setup. It will force the data to flow through the management interface before being routed to the storage NICs. Running iostat and xtop should show the load. A better configuration IMO would be putting the storage NICs on the switch and using a separate network or VLAN for the storage I/O traffic. Storage I/O optimization takes some time and effort. The type, number, and RAID configuration of your storage device as well as speed of your host CPUs, eize and type of memory, and configuration of your VMs (if NUMA aware, for example) all will play a role.

@PaulDCL [image: 1757633451167-9eb17eb5-9a99-4743-9df5-51edcc2b1847-image.png] This benchmark was taken inside the Windows Server VM on that iSCSI device. The iSCSI host is a QNAP NAS with Toshiba 18 TB drives configured in RAID-6. I think this is a decent speed for non-flash storage. Both devices are on a 10Gbit network. If you need more specific details, I'll be happy to help.

@DustinB Yeah I thought about doing something like this, but then we are getting into overkill costs lol. My main point behind this post was to get info on what other people are doing, I presumed most are just relying on config backups and will restore it at the other site if needed, which is fine. I was just also debating about whether or not I wanted the subnets to match between these 2 sites, since that can create some routing headaches, but should still be doable and would make recovery even faster. @olivierlambert yeah I do use that feature, so that's very helpful! Should make this all doable.