Migrating VM fails with DUPLICATE_VM error part2

AndreS

Re: Migrating VM fails with DUPLICATE_VM error

Hitting the same issue as the in referenced post but creating a new one because it is not fresh anymore.

Tried the same as described in the referenced post:
two hosts - separate pools - and using XO that connects to both pools/hosts.
when I select a vm and want to migrate it the migration fails with the DUPLICATE_VM error.

vm.migrate
{
  "mapVdisSrs": {
    "4d4a809d-6801-4462-8e52-811882106821": "270f8f4a-a24c-ced6-99c7-9bc2ba5f5008",
    "6a30ca10-a386-4e00-91aa-89c3e5bd43de": "270f8f4a-a24c-ced6-99c7-9bc2ba5f5008"
  },
  "mapVifsNetworks": {
    "f4b175c2-0082-212c-b9d9-bd616cd83d2c": "a014b230-2db6-adb4-ba4f-0b1cc07fdcae"
  },
  "migrationNetwork": "a014b230-2db6-adb4-ba4f-0b1cc07fdcae",
  "sr": "270f8f4a-a24c-ced6-99c7-9bc2ba5f5008",
  "targetHost": "3b57d90b-983f-46bb-8f52-4319025d1182",
  "vm": "afe623be-5451-fd48-3f24-60120e53f5ab"
}
{
  "code": 21,
  "data": {
    "objectId": "afe623be-5451-fd48-3f24-60120e53f5ab",
    "code": "DUPLICATE_VM"
  },
  "message": "operation failed",
  "name": "XoError",
  "stack": "XoError: operation failed
    at operationFailed (/opt/xo/xo-builds/xen-orchestra-202111061645/packages/xo-common/src/api-errors.js:21:32)
    at file:///opt/xo/xo-builds/xen-orchestra-202111061645/packages/xo-server/src/api/vm.mjs:482:15
    at Object.migrate (file:///opt/xo/xo-builds/xen-orchestra-202111061645/packages/xo-server/src/api/vm.mjs:469:3)
    at Api.callApiMethod (file:///opt/xo/xo-builds/xen-orchestra-202111061645/packages/xo-server/src/xo-mixins/api.mjs:304:20)"
}

Verified via xe vm-list that the object is not used on the destination host; as far as I can remember it has never been there but not entirely sure.

Any suggestions where to look?

olivierlambert

First, try to see if it's not hidden by XAPI. Try xl list on each host, and compare to see if you see duplicate.

AndreS

@olivierlambert Thanks

No duplicates, xl list -v seems to list only running vms?

olivierlambert

Yup only running VMs.

So you don't see any VM with UUID afe623be-5451-fd48-3f24-60120e53f5ab on destination pool?

Try xe vm-param-list uuid=afe623be-5451-fd48-3f24-60120e53f5ab on both.

AndreS

@olivierlambert

On the source host of course all the details of the (shut down) vm, happy to post if useful.
On the destination host:

[19:07 xen1 ~]# xe vm-param-list uuid=afe623be-5451-fd48-3f24-60120e53f5ab 
The uuid you supplied was invalid.
type: VM
uuid: afe623be-5451-fd48-3f24-60120e53f5ab

olivierlambert

That's weird. Have you tried to restart the toolstack on both hosts?

edit: also try with xe template-param-list uuid=afe623be-5451-fd48-3f24-60120e53f5ab

AndreS

@olivierlambert
Alas, same responses (before and after toolstack restart)
On destination host:

[19:35 xen1 ~]# xe template-param-list uuid=afe623be-5451-fd48-3f24-60120e53f5ab
The uuid you supplied was invalid.
type: VM
uuid: afe623be-5451-fd48-3f24-60120e53f5ab

Just tried another vm, same source/destination and that one is being moved at the moment.
Only difference I can think of is that the failing vm is imported and the succesfull one is created (on xcp-ng).

olivierlambert

Hmm can you try to migrate with xe then?

AndreS

@olivierlambert Sure, need to figure out the command line parms. Nothing against it but not used to it so I need to read and figure it out.

AndreS

@olivierlambert

[20:10 xen2 ~]# xe vm-migrate remote-master=172.25.10.11 remote-username=root remote-password=xxxxxxxx vif:f4b175c2-0082-212c-b9d9-bd616cd83d2c=a014b230-2db6-adb4-ba4f-0b1cc07fdcae vm=Win10vm
Performing a Storage XenMotion migration. Your VM's VDIs will be migrated with the VM.
Will migrate to remote host: xen1, using remote network: Pool-wide network associated with eth0. Here is the VDI mapping:
VDI 4d4a809d-6801-4462-8e52-811882106821 -> SR 270f8f4a-a24c-ced6-99c7-9bc2ba5f5008
VDI 6a30ca10-a386-4e00-91aa-89c3e5bd43de -> SR 270f8f4a-a24c-ced6-99c7-9bc2ba5f5008
Cannot restore this VM because it would create a duplicate
vm: abd338e4-0ae1-24fa-38be-91fc0fe57332

olivierlambert

That's weird indeed. Maybe it's not the VM itself that will be duplicated, but an object with it.

Have you checked MAC address on destination? There's something we need to dig in XAPI to learn what it means in terms of duplicate

olivierlambert

Yeah after taking a look, found this: https://github.com/xapi-project/xen-api/blob/d496b90c4172f71337841dcacb3496751141f712/ocaml/xapi/import.ml#L246

It might be duplicated MAC address related.

AndreS

@olivierlambert
Funny you say that, look at where we both commented on last year
https://xcp-ng.org/forum/topic/3182/centos-ovas-imported-from-esx-network-hang/34?_=1636230593687

Checked the MAC addresses of the two vms (the imported ones) but they are different. I'll try a side by side comparison of all the objects.

AndreS

@andres
Both vms exported from esxi

Windows 10 vm

other-config (MRW): auto_poweron: true; import_task: OpaqueRef:680ed8f5-22a5-4a4b-af3b-6988f7734441; install-repository: cdrom; vgpu_pci: ; base_template_name: Other install media; mac_seed: 5e88eb6a-d680-c47f-a94a-028886971ba4; install-methods: cdrom

Gentoo linux vm

other-config (MRW): auto_poweron: true; vgpu_pci: ; base_template_name: Other install media; mac_seed: 5e88eb6a-d680-c47f-a94a-028886971ba4; install-methods: cdrom

the mac-seed id is the same.

olivierlambert

Can you check if you don't have any similar MAC on the destination host?

About the seed, well, in theory that shouldn't be a problem, but you can always replace it by another random UUID (here is one I got with uuidgen: 3ec7fc14-1e25-4453-b3f9-5a7b6554d241).

AndreS

@olivierlambert
Similar, but not the same; the two imported vms have MAC addresses that differ only by one ( 9e:86:37:32:02:d7 vs 9e:86:37:32:02:d8) which should be enough.
Visually checked all MAC addresses on the destination host via XO, nothing even close except the D7 vs D8.
Is there a way to dump all object from all vms on a host?

olivierlambert

Yes but I don't remember. Let me try if I can find this quickly.

olivierlambert

You can do a xe vm-vif-list params=vm-name-label,MAC to see all your VMs MACs at once.

AndreS

@olivierlambert Thanks, this confirms that there is no MAC address clash.
The fact that they are both imported the same way from the same source system is a strong suggestion that something is clashing, especially after the MAC address issue found last year.

Suggestions are welcome, otherwise I might entertain myself and recreate a Windows 10 vm on the destination and symply copy over and connect the disks.

Let me know if you want me to provide details or create a ticket somewhere.

olivierlambert

Well, I'd love that we could find the culprit

xe vm-list params=all will give you all the params for all VMs on a given host.

Then, you should try to compare between 2 hosts and see if there's similar fields that shouldn't be similar (I know, it's vague).

In the mean time, let me ask around to some XAPI devs.