Live-migration with volumes creates orphan access records

[Rajini Karthik]

When live migration is performed on instances with volume attached, nova sends two initiator commands and one terminate connection. This causes orphan access records in some storage arrays ( tested with Dell EqualLogic Driver).

Steps to reproduce:
1. Have one controller and two compute node setup. Setup cinder volume on iscsi or a storage array.
2. Create an instance
3. Create a volume and attach it to the instance
4. Check the location of the instance ( computenode1 or 2)
nova instance1 show
4. Perform live migration of the instance and move it to the second compute node
nova live-migration instance1 computenode2
5. Check the cinder api log. c-api
There will be two os-initialize_connection and one os-terminate-connection. There should only be one set of initialize and terminate connection

[Sean McGinnis (sean-mcginnis)]

Closing stale bug. If this is still an issue please reopen.

[John Garbutt (johngarbutt)]

It looks a lot like this bug is caused by this change:
https://review.openstack.org/#/c/202770/

[Matt Riedemann (mriedem)]

What version of nova/cinder was being used to recreate this?

[Rajini Karthik (rajini-karthik)]

Icehouse was the version when I reported the bug

[Pushkar Umaranikar (pushkar-umaranikar)]

I tried it on nova version 13.0 - close to nova master.

[Rajini Karthik (rajini-karthik)]

Did you reproduce?

[Pushkar Umaranikar (pushkar-umaranikar)]

In my case, I can see 3 volume initiation requests, 2 for source host and 1 for destination host.

For source host, requests are initiated from :
compute/manager.py - check_can_live_migrate_source()
virt/libvirt/driver.py - post_live_migration()

As John mentioned, request to volume init from post_live_migration() is added in https://review.openstack.org/#/c/202770/
Waiting for comment/suggestion on the same.

[Markus Zoeller (markus_z) (mzoeller)]

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (LIBERTY, MITAKA, OCATA, NEWTON).
  Valid example: CONFIRMED FOR: LIBERTY