yahoo-eng-team team mailing list archive

["Markus Zoeller \(markus_z\)" <mzoeller@xxxxxxxxxx>]

This wishlist bug has been open a year without any activity. I'm going
to move it to "Opinion / Wishlist", which is an easily-obtainable queue
of older requests that have come on.

In case you want to work on that, consider writing a blueprints [1] and
spec [2]. I'll recommend to read [3] if not yet done. The effort to
implement the requested feature is then driven only by the blueprint
(and spec).

References:
[1] https://blueprints.launchpad.net/nova/
[2] https://github.com/openstack/nova-specs
[3] https://wiki.openstack.org/wiki/Blueprints

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

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