yahoo-eng-team team mailing list archive

[Jeegn Chen <jeegn.chen@xxxxxxx>]

Public bug reported:

I tried live-migration against VM with multipath access to FC bootable volume and FC data volume.
After checking the code, I found the reason is that
1. /dev/dm-<NUM> is used, which is subject to change in the destination Compute Node since it is not unique across nodes
2. multipath_id in connnection_info is not maintained properly and may be lost during connection refreshing

The fix would be
1. Like iSCSI multipath, use /dev/mapper/<multipath_id> instead of /dev/dm-<NUM>
2. Since multipath_id is unique for a volume no matter where it is attached, add logic to preserve this information.

** Affects: nova
     Importance: Undecided
     Assignee: Jeegn Chen (jeegn-chen)
         Status: In Progress

** Changed in: nova
     Assignee: (unassigned) => Jeegn Chen (jeegn-chen)

** Changed in: nova
       Status: New => In Progress

** Description changed:

  I tried live-migration against VM with multipath access to FC bootable volume and FC data volume.
  After checking the code, I found the reason is that
  1. /dev/dm-<NUM> is used, which is subject to change in the destination Compute Node since it is not unique across nodes
  2. multipath_id in connnection_info is not maintained properly and may be lost during connection refreshing
  
  The fix would be
  1. Like iSCSI multipath, use /dev/mapper/<multipath_id> instead of /dev/dm-<NUM>
- 2. Since multipath_id is unique for a volume no matter where is is attached, add logic to preserve this information.
+ 2. Since multipath_id is unique for a volume no matter where it is attached, add logic to preserve this information.

-- 
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/1327497

Title:
  live-migration fails when FC multipath is used

Status in OpenStack Compute (Nova):
  In Progress

Bug description:
  I tried live-migration against VM with multipath access to FC bootable volume and FC data volume.
  After checking the code, I found the reason is that
  1. /dev/dm-<NUM> is used, which is subject to change in the destination Compute Node since it is not unique across nodes
  2. multipath_id in connnection_info is not maintained properly and may be lost during connection refreshing

  The fix would be
  1. Like iSCSI multipath, use /dev/mapper/<multipath_id> instead of /dev/dm-<NUM>
  2. Since multipath_id is unique for a volume no matter where it is attached, add logic to preserve this information.

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