yahoo-eng-team team mailing list archive

[Sean Dague <sean@xxxxxxxxx>]

Honestly, I consider this a performance wishlist item. If there are
patches that's cool, but this seems like a very edge case configuration.

** Changed in: nova
       Status: New => Opinion

** Changed in: nova
   Importance: Undecided => Wishlist

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

Title:
  libvirt: connect_volume scans all LUNs, which takes >2 mins  when host
  is connected with about 900 Luns

Status in OpenStack Compute (Nova):
  Opinion

Bug description:
  Tested OpenStack version: IceHouse 2014.1, master branch still has this issue.
  Host version: CentOS 6, 2.6.32-431.el6.x86_64

  I have done some work to test the performance of LUN scanning with multipath, use the way like what Nova dose.
  In my test, The host was connected with almost 900 LUNs.
  1. I use 'iscsiadm' with '--rescan' to discover LUNs, which takes almost 15s. It seems '--rescan' cause kernel to rescan all the LUNs which has already been connected to the host.
  2. I use 'multipath -r' to construct multipath devices, which takes almost 2 minutes. I found that 'multipath -r' will reconstructs all multipath devices against the LUNs 
  The two steps scans all of the LUNs, and totally costs more then 2 minutes.

  According to "connect_volume" in nova.virt.libvirt.volume.py:
  https://github.com/openstack/nova/blob/master/nova/virt/libvirt/volume.py#L252,
  Nova also uses the tow steps to detect new multipath volume, this two
  steps will scan all of the LUNs, including all the others which
  already connected. So if a host has a large number of LUNs connected
  to it, the connect_volume will be very slow.

  I think connect_volume needn't scan all of the LUNs, only need scan
  the LUN specified by connection_info.

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