XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    [V2V] Without VDDK problems

    Scheduled Pinned Locked Moved Solved Migrate to XCP-ng
    4 Posts 2 Posters 17 Views 2 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • J
      jr-m4
      last edited by jr-m4

      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)"
      }
      ´´´
      1 Reply Last reply
      Reply Quote 0
      • mpitonM
        mpiton Vates 🪐 XO Team @jr-m4
        last edited by

        @jr-m4

        Hi, your journalctl output has the answer: vectura: data plane: could not connect: timed out.

        With a vCenter as source, the login and the CBT query go through the vCenter on port 443, but the disk itself is read directly from the ESXi host running the VM, on port 902. Your new XO reaches the vCenter fine, it just can't open a connection to that ESXi on 902. The stream has ended without data error is only the side effect of vectura exiting. CBT has nothing to do with it.

        The old instance works because it can reach that host (VDDK needed the same port). I'd check firewall/VLAN rules or DNS on the new VM. From the new XO, using the ESXi name as vCenter shows it for that VM:

          getent hosts <esxi-host>
          nc -vz -w 5 <esxi-host> 902
        

        and compare with the old instance.

        ~Mathieu

        J 1 Reply Last reply
        Reply Quote 2
        • J
          jr-m4
          last edited by jr-m4

          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
          
          mpitonM 1 Reply Last reply
          Reply Quote 0
          • mpitonM
            mpiton Vates 🪐 XO Team @jr-m4
            last edited by

            @jr-m4

            Hi, your journalctl output has the answer: vectura: data plane: could not connect: timed out.

            With a vCenter as source, the login and the CBT query go through the vCenter on port 443, but the disk itself is read directly from the ESXi host running the VM, on port 902. Your new XO reaches the vCenter fine, it just can't open a connection to that ESXi on 902. The stream has ended without data error is only the side effect of vectura exiting. CBT has nothing to do with it.

            The old instance works because it can reach that host (VDDK needed the same port). I'd check firewall/VLAN rules or DNS on the new VM. From the new XO, using the ESXi name as vCenter shows it for that VM:

              getent hosts <esxi-host>
              nc -vz -w 5 <esxi-host> 902
            

            and compare with the old instance.

            ~Mathieu

            J 1 Reply Last reply
            Reply Quote 2
            • J
              jr-m4 @mpiton
              last edited by

              @mpiton

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

              1 Reply Last reply
              Reply Quote 1
              • J jr-m4 marked this topic as a question
              • J jr-m4 has marked this topic as solved
              • J jr-m4 has marked this topic as solved

              Hello! It looks like you're interested in this conversation, but you don't have an account yet.

              Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

              With your input, this post could be even better 💗

              Register Login
              • First post
                Last post