yahoo-eng-team team mailing list archive

[jangpro2 <jangseon.ryu@xxxxxxxxx>]

Public bug reported:


Description
===========
target-lun id of volume changed when live-migration failed
I tried to live-migrate vm with attahed volume, but failed.
I think nova-compute should rollback vm as old status before live-migration.
But target-lun id of volume didn't changed as old lun-id.

Environment
===========
- OpenStack Release : Liberty
- OS : Ubuntu 14.04.2 LTS
- Hypervisor : KVM
- Cinder Storage : iSCSI (EMC VNX)

Steps to reproduce
==================
1. Create VM and Attach Volume to VM(target-lun id is 174)
2. Try to Live-migration... but failed (target-lun id changed 97)
3. Try to rollback (target-lun id still is 97)
  * target-lun id didn't changed old one.

> before live-migration(nova.block_device_mapping table.connection_info)
{"driver_volume_type": "iscsi", "serial": "6352f542-819f-477e-a588-b15d75008178", 
"data": {"target_luns": [174, 174, 174, 174], 
"device_path": "/dev/mapper/360060160a7d03800b0dcf791f008e611", "target_discovered": true, "encrypted": false, "qos_specs": null, 
"target_iqn": "iqn.1992-04.com.emc:cx.ckm00142100690.b0", "target_portal": "x.x.x.x:3260", "volume_id": "6352f542-819f-477e-a588-b15d75008178", 
"target_lun": 174, "access_mode": "rw", 
"target_portals": ["x.x.x.x:3260", "x.x.x.x:3260", "x.x.x.x:3260", "x.x.x.x:3260"]}}

(*) target_lun id was 174.

> after live-migration and rollback (nova.block_device_mapping table.connection_info)
{"driver_volume_type": "iscsi", "serial": "6352f542-819f-477e-a588-b15d75008178", 
"data": {"target_luns": [97, 97, 97, 97], 
"target_discovered": true, "encrypted": false, "qos_specs": null, "target_iqn": "iqn.1992-04.com.emc:cx.ckm00142100690.b1", 
"target_portal": "x.x.x.x:3260", "volume_id": "6352f542-819f-477e-a588-b15d75008178", 
"target_lun": 97, "access_mode": "rw", 
"target_portals":  ["x.x.x.x:3260", "x.x.x.x:3260", "x.x.x.x:3260", "x.x.x.x:3260"]}}

(*) target_lun id was changed 97.

Expected result
===============
If live-migration success, it is normal status that target-lun id changes 97.

Actual result
=============
otherwise target-lun id must change as old target id(174).

In this environment, if nova reboot the vm, vm will fail rebooting.
Because target-lun(97) doesn't exist in the server.
Or
If target-lun(97) used by other vm exist, vm will attach volume used by other vm.
It occurs critical situation that single volume attached by multi-vm.

** Affects: nova
     Importance: Undecided
     Assignee: jangpro2 (jangseon-ryu)
         Status: New

** Changed in: nova
     Assignee: (unassigned) => jangpro2 (jangseon-ryu)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1573944

Title:
  target-lun id of volume changed when live-migration failed

Status in OpenStack Compute (nova):
  New

Bug description:
  
  Description
  ===========
  target-lun id of volume changed when live-migration failed
  I tried to live-migrate vm with attahed volume, but failed.
  I think nova-compute should rollback vm as old status before live-migration.
  But target-lun id of volume didn't changed as old lun-id.

  Environment
  ===========
  - OpenStack Release : Liberty
  - OS : Ubuntu 14.04.2 LTS
  - Hypervisor : KVM
  - Cinder Storage : iSCSI (EMC VNX)

  Steps to reproduce
  ==================
  1. Create VM and Attach Volume to VM(target-lun id is 174)
  2. Try to Live-migration... but failed (target-lun id changed 97)
  3. Try to rollback (target-lun id still is 97)
    * target-lun id didn't changed old one.

  > before live-migration(nova.block_device_mapping table.connection_info)
  {"driver_volume_type": "iscsi", "serial": "6352f542-819f-477e-a588-b15d75008178", 
  "data": {"target_luns": [174, 174, 174, 174], 
  "device_path": "/dev/mapper/360060160a7d03800b0dcf791f008e611", "target_discovered": true, "encrypted": false, "qos_specs": null, 
  "target_iqn": "iqn.1992-04.com.emc:cx.ckm00142100690.b0", "target_portal": "x.x.x.x:3260", "volume_id": "6352f542-819f-477e-a588-b15d75008178", 
  "target_lun": 174, "access_mode": "rw", 
  "target_portals": ["x.x.x.x:3260", "x.x.x.x:3260", "x.x.x.x:3260", "x.x.x.x:3260"]}}

  (*) target_lun id was 174.

  > after live-migration and rollback (nova.block_device_mapping table.connection_info)
  {"driver_volume_type": "iscsi", "serial": "6352f542-819f-477e-a588-b15d75008178", 
  "data": {"target_luns": [97, 97, 97, 97], 
  "target_discovered": true, "encrypted": false, "qos_specs": null, "target_iqn": "iqn.1992-04.com.emc:cx.ckm00142100690.b1", 
  "target_portal": "x.x.x.x:3260", "volume_id": "6352f542-819f-477e-a588-b15d75008178", 
  "target_lun": 97, "access_mode": "rw", 
  "target_portals":  ["x.x.x.x:3260", "x.x.x.x:3260", "x.x.x.x:3260", "x.x.x.x:3260"]}}

  (*) target_lun id was changed 97.

  Expected result
  ===============
  If live-migration success, it is normal status that target-lun id changes 97.

  Actual result
  =============
  otherwise target-lun id must change as old target id(174).

  In this environment, if nova reboot the vm, vm will fail rebooting.
  Because target-lun(97) doesn't exist in the server.
  Or
  If target-lun(97) used by other vm exist, vm will attach volume used by other vm.
  It occurs critical situation that single volume attached by multi-vm.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1573944/+subscriptions