jr-m4

@mpiton

Thanks for a fantasticly quick answer, and detailed as well. I will test this immediately!

Update:
I can confirm that this was indeed the problem!

Looking into journcelctl on the XO-server, after I enabled CBT-tracking on the VM (using this KB from Broadcom https://knowledge.broadcom.com/external/article/315370/enabling-or-disabling-changed-block-trac.html). I get the following:

The initial V2V-snapshot on vmware is created as expected. So there is communication between XO and vmware (vcenter-host)

Oct 02 13:24:33 hostname-xo-server xo-server[55639]: 2026-10-02T11:24:33.361Z xo:vmware-explorer:esxi INFO got the data map from the change tracking of the host {
Oct 02 13:24:33 hostname-xo-server xo-server[55639]:   blocks: 16,
Oct 02 13:24:33 hostname-xo-server xo-server[55639]:   bytes: 20912799744,
Oct 02 13:24:33 hostname-xo-server xo-server[55639]:   diskPath: 'vm-name_1/vm-name.vmdk',
Oct 02 13:24:33 hostname-xo-server xo-server[55639]:   full: true,
Oct 02 13:24:33 hostname-xo-server xo-server[55639]:   seconds: 0,
Oct 02 13:24:33 hostname-xo-server xo-server[55639]:   vmId: 'vm-1169935'
Oct 02 13:24:33 hostname-xo-server xo-server[55639]: }
Oct 02 13:24:44 hostname-xo-server xo-server[55639]: 2026-10-02T11:24:44.496Z vates:nbd-client:stdio WARN the nbd server process exited unexpectedly {
Oct 02 13:24:44 hostname-xo-server xo-server[55639]:   error: Error: the nbd server process exited (code: 1, signal: null)
Oct 02 13:24:44 hostname-xo-server xo-server[55639]:       at ChildProcess.<anonymous> (file:///opt/xen-orchestra/@vates/nbd-client/NbdStdioClient.mjs:107:21)
Oct 02 13:24:44 hostname-xo-server xo-server[55639]:       at ChildProcess.wrapper (node:events:639:12)
Oct 02 13:24:44 hostname-xo-server xo-server[55639]:       at ChildProcess.emit (node:events:514:28)
Oct 02 13:24:44 hostname-xo-server xo-server[55639]:       at ChildProcess.patchedEmit [as emit] (/opt/xen-orchestra/@xen-orchestra/log/configure.js:52:17)
Oct 02 13:24:44 hostname-xo-server xo-server[55639]:       at Process.ChildProcess._handle.onexit (node:internal/child_process:295:12) {
Oct 02 13:24:44 hostname-xo-server xo-server[55639]:     code: 'NBD_SERVER_EXITED',
Oct 02 13:24:44 hostname-xo-server xo-server[55639]:     exitCode: 1,
Oct 02 13:24:44 hostname-xo-server xo-server[55639]:     signal: null,
Oct 02 13:24:44 hostname-xo-server xo-server[55639]:     command: '/opt/xen-orchestra/@xen-orchestra/vmware-explorer/vectura/vectura',
Oct 02 13:24:44 hostname-xo-server xo-server[55639]:     stderr: 'vectura: data plane: could not connect: timed out\n'
Oct 02 13:24:44 hostname-xo-server xo-server[55639]:   }
Oct 02 13:24:44 hostname-xo-server xo-server[55639]: }
Oct 02 13:24:44 hostname-xo-server xo-server[55639]: 2026-10-02T11:24:44.526Z xo:api WARN username-1 | vm.importMultipleFromEsxi(...) [17s] =!> Error: stream has ended without data, was looking for 8 bytes

First of all. Thanks for putting alot of effort into getting migrations to work without VDDK. https://github.com/vatesfr/xen-orchestra/pull/10421

However. I did a new provisioning of an XO-source instance. And wanted to test it without any hanging dependencies from previously installed vddk's.

Now I'm getting met with failed import-attempts.

Attempts with my previous XO instance, on the same commit: b59c8 works just fine. Except the VMs not starting automatically after import (discussed in separate thread: https://xcp-ng.org/forum/post/108686)

vm.importMultipleFromEsxi
{
  "concurrency": 2,
  "host": "vcenter-host",
  "network": "72471fb1-58fd-d2d1-9a1e-46aea05374b4",
  "password": "* obfuscated *",
  "sr": "4d58d7f1-087a-bc7b-a957-e8f8be8b1f77",
  "sslVerify": false,
  "stopOnError": true,
  "stopSource": true,
  "template": "37e7a3b9-8c45-c7f2-7d09-249a935dd33d-1a647cf9-99c1-4e9c-b3b4-6b9989c530be",
  "user": "obfuscated",
  "vms": [
    "vm-1169935"
  ]
}
{
  "succeeded": {},
  "message": "stream has ended without data, was looking for 8 bytes",
  "name": "Error",
  "stack": "Error: stream has ended without data, was looking for 8 bytes
    at readChunkStrict (/opt/xen-orchestra/@vates/read-chunk/index.js:83:13)"
}
´´´

Installed on 3xDell PowerEdge R350 in HA. And so far, I haven't noticed anything out of the ordinary.

@poddingue
Our HA-pool is a 3 host system, yes.

I'll add a note about our plans to go paid in that feedback-item. Thanks for the tip.
In the meantime, I'm testing and reporting as much as I can. In order to hopefully help the product be better for all.

Cheers!

@poddingue

Huh.. Good catch.
I set all of the VMs to restart, and now it does make maintenance mode possible, on the host.

However, when we go into licensed/paid production (soon tm). It would be an absolute nightmare to try and find one VM that might not be on the right HA-plan... And it does kind of feel that Maintenance-mode should be compatible with whatever HA-plan is chosen regardless.

Perhaps there could be a way to assign a global/pool-wide HA-plan along with enabling HA alltogether?

Update: Shining light on that there is already a feedback-item, wishing for this kind of mass-operation for HA.
https://feedback.vates.tech/posts/45/bulk-operation-for-setting-vm-ha-option

Doing some more testing, where I wished to place one Host in maintenance mode. I was then met with HOST_NOT_ENOUGH_FREE_MEMORY.
The pool is a 3 host pool in HA, with load balancing enabled.

My guess is that when trying to enable Maintenance mode. It tries to migrate ALL VMs on that host, to ONE single Host on the receiving end. And then it exhausts the amount of available memory.

What I had to do, was manually disable load balancing. And manually migrate VMs to the two other hosts, to distribute them. This worked.

What I expected to have happened:
The evacuation of the host going into Maintenance mode, would be distributing the VMs in a smarter fashion. So that their workload would fit in the pooled resources available.

Commit: 2f846
XCP-NG: Fully updated as of writing

host.setMaintenanceMode
{
  "id": "<obfuscated>",
  "maintenance": true
}
{
  "code": "HOST_NOT_ENOUGH_FREE_MEMORY",
  "params": [
    "OpaqueRef:<obfuscated>"
  ],
  "task": {
    "uuid": "c3a83a2d-003d-ac0f-48b8-79a905c9e557",
    "name_label": "Async.host.evacuate",
    "name_description": "",
    "allowed_operations": [],
    "current_operations": {},
    "created": "20260929T07:46:40Z",
    "finished": "20260929T07:46:40Z",
    "status": "failure",
    "resident_on": "OpaqueRef:<obfuscated>",
    "progress": 1,
    "type": "<none/>",
    "result": "",
    "error_info": [
      "HOST_NOT_ENOUGH_FREE_MEMORY",
      "OpaqueRef:<obfuscated>"
    ],
    "other_config": {},
    "subtask_of": "OpaqueRef:NULL",
    "subtasks": [],
    "backtrace": "(((process xapi)(filename ocaml/xapi/xapi_host.ml)(line 629))((process xapi)(filename hashtbl.ml)(line 159))((process xapi)(filename hashtbl.ml)(line 165))((process xapi)(filename hashtbl.ml)(line 170))((process xapi)(filename ocaml/xapi/xapi_host.ml)(line 625))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 39))((process xapi)(filename ocaml/xapi/rbac.ml)(line 228))((process xapi)(filename ocaml/xapi/rbac.ml)(line 238))((process xapi)(filename ocaml/xapi/server_helpers.ml)(line 78)))"
  },
  "message": "HOST_NOT_ENOUGH_FREE_MEMORY(OpaqueRef:<obfuscated>)",
  "name": "XapiError",
  "stack": "XapiError: HOST_NOT_ENOUGH_FREE_MEMORY(OpaqueRef:<obfuscated>)
    at XapiError.wrap (file:///opt/xen-orchestra/packages/xen-api/_XapiError.mjs:16:12)
    at default (file:///opt/xen-orchestra/packages/xen-api/_getTaskResult.mjs:13:29)
    at Xapi._addRecordToCache (file:///opt/xen-orchestra/packages/xen-api/index.mjs:1358:24)
    at file:///opt/xen-orchestra/packages/xen-api/index.mjs:1392:14
    at Array.forEach (<anonymous>)
    at Xapi._processEvents (file:///opt/xen-orchestra/packages/xen-api/index.mjs:1382:12)
    at Xapi._watchEvents (file:///opt/xen-orchestra/packages/xen-api/index.mjs:1589:14)"
}

Update: Edited title, since it would suggest Load Balancing was the problem. It isn't. It's the assignment of migration target(s) that is the issue (imho)

@poddingue

Thanks for taking a look.

Yes it is this part that tells me that it should start the VM automatically once the import has completed.
"After the transfer, the VM on XCP-ng side is started:"
Followed by, "This process is fully automated, without any human intervention after it starts on step 1."

https://docs.xcp-ng.org/installation/migrate-to-xcp-ng/

But my findings/experience is that the VM does not start once the import/transfer has completed.

So either the docs are wrong. Or the function is not behaving as intended. I'm acctually fine either way. As long as I know what to expect. However, I would like to have it auto-start the VMs after transfer completion. Which would make the procedure "Fully automated".

Update:
Am I assuming correctly that "the XO V2V guide says to start the VM yourself once the migration is complete " you're reffering to, is part of the "test migration"-procedure? Not the acctual production mgiration?
Because:

"Final migration
Run the production migration
When you're ready for the final migration:

Shut down the source VM completely.
Start the V2V migration in Xen Orchestra with the Stop source option enabled.
This ensures the final sync happens while the VM is powered off, and prevents any inconsistencies."

In my mind doesn't state that the VM should be started manually post-transfer.

Great thanks in advance for discussing!
Cheers!

Further testing:

Testing with newer commit: 27882fb1dcd24fc5257835e60b3fa1002e4e885c
Still same results.

I've tried with both original VM powered on, and off. No change in end-result. The VM imports properly. But it doesn't power on automatically as expected after the import has completed. Manual powering on is then needed to be performed.

I'm only importing 1 VM at a time. And I've tried with the field Number of VMs to import in parallel both at the default value of 2 and reduced to 1. No change in behaviour from this either.

@tjkreidl

Thanks for your long post. I hope someone else will find it helpfull.
However, I am pretty much reporting that the autostart after importing with V2V might be buggy at best or broken at worst. Not the autostart after boot part (that works).

Cheers