attached volume will lose attachment infomation after migration

Bug #1647282 reported by Liu Wei
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Cinder
Invalid
Undecided
Unassigned

Bug Description

When I retype an attached volume from typeA to typeB, the operation could be successful.But when I continue queried the volume's details by "cinder show" commond,I found the volume lost its attachment info while its status was "in-use".My environment was all-in-one devstack versioned stable/mitaka.And I configured multi-backend in cinder,which are lvmdriver-1 and lvmdriver-2.

Reproduce steps:
1.boot a new instance VM1
2.create a volume named volume1 whose type is lvmdriver-1.
3.attach volume1 to VM1,then query volume1's information.We could find its status changed to in-use and attachment field holded the vm1's information.Everything is okay until now.
+--------------------+--------+---------+------+-------------+----------+------------+
| ID | Status | Name | Size | Volume Type | Bootable |Attached to |
+--------------------+--------+---------+------+-------------+----------+------------+
| 3a8304a0 | in-use | volume1 | 1 | lvmdriver-1 | false | 5eed0b96 |
+--------------------+--------+---------+------+-------------+----------+------------+
4.retype volme1 from lvmdriver-1 to lvmdriver-2
5.after retype, query volume1's information.We could find its status stay in in-use ,but attachment field changes to None.
+--------------------+--------+---------+------+-------------+----------+------------+
| ID | Status | Name | Size | Volume Type | Bootable |Attached to |
+--------------------+--------+---------+------+-------------+----------+------------+
| 3a8304a0-95a8-4935-| in-use | volume1 | 1 | lvmdriver-2 | false | |
+--------------------+--------+---------+------+-------------+----------+------------+

In order to find the cause, I review the whole retype process.Then I locate the problem in VolumeManager.migrate_volume_completion() function,which is in cinder/volume/manager.py file.
The function is responsible for updating the db records of old volume and new volume,which is the last procedure in volume retype.In the function,the main processes are as follows:
1.detach old volume
2.swap the metadata between old volume and new volume
3.attach old volume again
4.delete the new volume.

Problem happend at 3rd step.When old volume is attached again, it needs get instance information from previous attachment information.But its previous attachment information have droped in step1.So step3 will get None attachment information.

Mu solution is store attachment information before step1 into a temp var.

Revision history for this message
Liu Wei (mountainwei) wrote :

mofidy the migrate_volume_completion function in cinder/volume/manager.py.

haobing1 (haobing1)
Changed in cinder:
assignee: nobody → haobing1 (haobing1)
Revision history for this message
haobing1 (haobing1) wrote :

I can not reproduce the bug.All step is ok! Thanks

1.[root@devstack162 libvirt]# cinder list
+--------------------------------------+-----------+--------+------+-------------+----------+--------------------------------------+
| ID | Status | Name | Size | Volume Type | Bootable | Attached to |
+--------------------------------------+-----------+--------+------+-------------+----------+--------------------------------------+
| 6215ea1c-5374-40d8-b935-d6ece40bfca3 | in-use | hb | 1 | hb | false | e82d0493-f76d-4bf9-9012-ee9f2c4a7c29 |

2.cinder retype 6215ea1c-5374-40d8-b935-d6ece40bfca3 hb1 --migration-policy on-demand

3.[root@devstack162 libvirt]# cinder list
+--------------------------------------+-----------+--------+------+-------------+----------+--------------------------------------+
| ID | Status | Name | Size | Volume Type | Bootable | Attached to |
+--------------------------------------+-----------+--------+------+-------------+----------+--------------------------------------+
| 6215ea1c-5374-40d8-b935-d6ece40bfca3 | in-use | hb | 1 | hb1 | false | e82d0493-f76d-4bf9-9012-ee9f2c4a7c29 |

Changed in cinder:
status: New → Invalid
assignee: haobing1 (haobing1) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.