vexxhost / migratekit

Near-live migration toolkit for VMware to OpenStack
Apache License 2.0
79 stars 12 forks source link

Wrong endpoint #46

Open doingsrl opened 1 month ago

doingsrl commented 1 month ago

Hello, I'm testing migratekit on OVH Public Cloud; I set the variables in openrc.sh and I can connect from cli with openstack client; when I perform a migration, the process starts correctly, runs the snapshot on esxi, connects to the openstack instance but then gives me this error:

Creating snapshot 100% [=================================================================================] (100/100) [0s:0s] WARN[0004] Change ID mismatch, full copy needed currentChangeId= snapshotChangeId="52 ca 91 a0 75 e3 bf 62-d0 0a 94 f0 fe 13 c0 e3/65" INFO[0004] Attaching volume volume_id= INFO[0006] Detected instance UUID, attaching volume... instance_uuid=xyzzy Removing snapshot 100% [=================================================================================] (100/100) [1s:0s] Error: Expected HTTP response code [200] when accessing [POST https://compute.uk1.cloud.ovh.net/v2.1/******/servers/a*****/os-volume_attachments], but got 404 instead: {"itemNotFound": {"code": 404, "message": "Instance xyzzy*** could not be found."}}

The problem is that the region is SBG7 and the correct url is: https://compute.sbg7.cloud.ovh.net/v2.1/******/servers/a*****/os-volume_attachments. For now, I haven't found a way to fix.

Thank you.

matthewhentrich commented 1 week ago

Also running into this problem. My openrc file specifies the the public endpoint of one region, but when it comes time to query for volume-attachments of the migration machine, it tries to find it at the internal endpoint of a different region. So, obviously, it doesn't find the VM and the process bombs.

Anyone find a fix to this?

UPDATE: I found a sort of workaround to this, it isn't great, but it did work for me. As far as I can tell, the toolkit must dump the list of endpoints and then search them from top to bottom until it encounters the first nova endpoint, and that is what it queries for volume-attachment info. In my environment, that means it encounters a different region's nova endpoint first and fails on this step. So, I simply disabled that endpoint (openstack endpoint set [endpoint-id] --disable) while I was running the migration tool. Thankfully that doesn't really create any issues in my environment, so it's workable, if not particularly great.