To follow up on my last email, I have tested the following hackaround in my testing environment:
Assuming you're using the Libvirt driver, a hackaround here is to cold migrate the instance to another host, this refreshes the connection_info from c-api and should allow the instance to boot correctly.
I can confirm that on OpenStack Queens, this doesn’t work. Openstack can’t find the attachment ID as it was marked as deleted in the cinder DB. I’m guessing it put itself as deleted when I did cinder reset-state --attach-status detached b70b254f-58cd-4940-b976-6f4dc0209a8c.
The “delete_on_termination” was recored in instance’s BDM table https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L..., and it was deal with by nova delete the server (clean up bdms, and call cinderclinet to delete the target volume). In Cinder, delete_on_termination cannot be recored, so in Cinder DB you cannot find this field. Clean up bdms: https://github.com/openstack/nova/blob/master/nova/compute/api.py#L2334-L237...
Even though I did cinder reset-state --attach-status attached b70b254f-58cd-4940-b976-6f4dc0209a8c, the original attachment ID did not undelete itself. It also didn’t update itself to the new path. As a result, nova seems to be looking for the attachment ID when trying to migrate and errors out when it can’t find it.
That said, I do remember using this workaround in the past on older versions of Openstack, so this definitely used to work. I guess a change in cinder probably broke this.
Jean-Philippe Méthot Openstack system administrator Administrateur système Openstack PlanetHoster inc.
brinzhang