Import from VMWare - Error: Can't import delta of a running VM without its parent vdi

DustinB

@jkissane said in Import from VMWare - Error: Can't import delta of a running VM without its parent vdi:

@DustinB That would appear to be vMotion from reading on the VMware site. I thought the XCP method worked by taking a snapshot of a running VM & then copying that.

Only if you're licensed for the live vMotion. Otherwise you need to power off the VM, migrate it to XCP-ng and then it'll work.

jkissane

@DustinB We use live vMotion regularly on the ESX side, think the last time was when we were upgrading the servers. It's not vMotion if the VM is powered off, you're just starting it on a different host.

DustinB

@jkissane Are you connecting to vCenter or to each host individually?

jkissane

@DustinB I tried both, same error each time & the source VM gets powered off.

DustinB

@jkissane said in Import from VMWare - Error: Can't import delta of a running VM without its parent vdi:

@DustinB I tried both, same error each time & the source VM gets powered off.

There was a version issue recently that may be causing the issue you're experiencing (from ESXi).

What version of VMWare are you using?

https://xcp-ng.org/forum/topic/8590/vmware-v7-warm-migration/12?_=1712681819057

jkissane

@DustinB The version of ESXi is 6.5 & the iSCSI datastores are VMFS 5.

jkissane

I tried another other option of cloning a running Windows VM & then trying to import the powered off clone. This didn't work either but a different error this time. Does importing from ESXi to xcp actually work as I can't see at this moment how it would be possible for us to migrate to xcp? I'm pretty certain it worked at least once with a powered down Linux but I'm starting to doubt myself now

vm.importMultipleFromEsxi
{
  "concurrency": 1,
  "host": "vc.XXXXX",
  "network": "c448fd53-503a-0241-7104-0a1b287a7e5a",
  "password": "* obfuscated *",
  "sr": "98a52525-862f-3bb1-3403-3dc334f2509d",
  "sslVerify": false,
  "stopOnError": true,
  "stopSource": false,
  "user": "john.kissane@XXXXX",
  "vms": [
    "vm-19874"
  ]
}
{
  "cause": {
    "size": 0
  },
  "succeeded": {},
  "message": "404 Not Found https://vc.XXXXX/folder/nmrc3-clone/emptyBackingString?dcPath=ITS&dsName=Unity_vm_vol01",
  "name": "Error",
  "stack": "Error: 404 Not Found https://vc.XXXXXX/folder/nmrc3-clone/emptyBackingString?dcPath=ITS&dsName=Unity_vm_vol01
    at Esxi.#download (file:///usr/local/lib/node_modules/xo-server/node_modules/@xen-orchestra/vmware-explorer/esxi.mjs:95:21)
    at Esxi.download (file:///usr/local/lib/node_modules/xo-server/node_modules/@xen-orchestra/vmware-explorer/esxi.mjs:113:21)
    at Esxi.#inspectVmdk (file:///usr/local/lib/node_modules/xo-server/node_modules/@xen-orchestra/vmware-explorer/esxi.mjs:221:21)
    at Esxi.getTransferableVmMetadata (file:///usr/local/lib/node_modules/xo-server/node_modules/@xen-orchestra/vmware-explorer/esxi.mjs:307:17)
    at Task.runInside (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:158:22)
    at Task.run (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:141:20)
    at MigrateVm.migrationfromEsxi (file:///usr/local/lib/node_modules/xo-server/src/xo-mixins/migrate-vm.mjs:178:28)
    at file:///usr/local/lib/node_modules/xo-server/src/api/vm.mjs:1432:30
    at Task.runInside (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:158:22)
    at Task.run (/usr/local/lib/node_modules/xo-server/node_modules/@vates/task/index.js:141:20)
    at asyncEach.concurrency.concurrency (file:///usr/local/lib/node_modules/xo-server/src/api/vm.mjs:1430:11)"
}

olivierlambert

@jkissane said in Import from VMWare - Error: Can't import delta of a running VM without its parent vdi:

emptyBackingString

There's something fishy here Ping @florent

Danp

@jkissane Did the source VM have an existing snapshot when you tried the import?

jkissane

@Danp Nope no snapshots. I've updated xoa to the latest rather than stable version so going to try again with that.

Danp

@jkissane Please try it with an existing snapshot as I believe that is required.

jkissane

@Danp A snapshot of a powered off VM?

Danp

@jkissane With ESXi 6.5 & VMFS 5 it should work either way as long as the snapshot exists.

jkissane

@Danp After upgrading to the latest version of xoa (rather than stable) I was able to import both a Linux & Windows VM (both powered down) from ESXi.

The Windows VM gives me a blank screen when powered on under XCP-ng while the Linux VM has dropped to an emergency shell warning that a disk it expects doesn't exit.

Unsure where to go from here if I'm honest.

AtaxyaNetwork

@jkissane Hi !

Did you install xen driver before exporting the VM ?
dracut --add-drivers "xen-blkfront xen-netfront" --force

olivierlambert

That's very likely the issue (for Linux) and for Windows, double check that you are using the right boot mode (UEFI or BIOS)

jkissane

@AtaxyaNetwork

No I hadn't installed any extra drivers but having installed them using the command suggested & re-imported it made no difference as once again I'm back to the same screen as earlier.

This is a Centos 8 VM with a flat disk, no snapshots etc & very low CPU/memory requirements.

Screenshot from 2024-04-24 14-17-29.png

jkissane

@olivierlambert For the Windows VM, if I change the boot mode to UEFI then it doesn't boot at all, rather drops me into the UEFI shell. With BIOS I get a brief glimp of the Windows progress bar, the console resizes & then it stays at a black screen with zero CPU usage as far I can see.

jkissane

Just wondering if I'm doing something incorrect here with trying to import VM's from ESX to XCP-ng?

Our ESXi system is running VC 6.7 & ESXi 6.5 on the servers. All the storage for the VM's is external via iSCSI.

We're covered for the VMware setup 'til next Dec so I'm looking at possible alternaitives hence these tests.

olivierlambert

I don't see any obvious mistake but it's only from a very "far" point of view: it's hard to tell much more without digging a bit more.

My next move would be to boot again the CentOS thing but on a live CD to take a look on the drives from it and see if there's any obvious problem. You can also tinker with the grub menu to double check if you are not using hard coded disks paths and such. If you don't know how to do it, then might worth starting to ask for some professional support (as you can imagine we are kind of busy and despite doing our best with the community assistance, it's hard for us to make very deep investigation in here)