Open Stack

Hi, joe
Thanks for your replay.
I want to confirm whether we use “--rescan” for another reason.
If only for connecting volume, it should be a bug. I will report it soon.


From: Joe Gordon [mailto:joe.gordon0 at gmail.com]
Sent: Wednesday, August 27, 2014 1:12 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [OpenStack][Nova]May be performance issues of connect_volume in Nova


On Tue, Aug 26, 2014 at 5:36 AM, Wang Shen <ws1210 at gmail.com<mailto:ws1210 at gmail.com>> wrote:
Hi, All
I have done some work to test the performance of LUN scanning, use
"iscsiadm" with "--rescan" like what Nova dose. In my test, a host
connected with a lot of LUNs , more than 1000 LUNs. Because "--rescan"
will cause kernel to scan all of the LUNs connected to the host, it
costs several minutes to complete the scanning.

According to "connect_volume" at line 284 in nova.virt.libvirt.volume.py<http://nova.virt.libvirt.volume.py>:
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/volume.py#L252
Nova uses "iscsiadm" with "--rescan" to detect new volume, but this
command will scan all of the LUNs, including all the others which
already connected to this host. 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.

Is it necessary to discuss a more efficient way to improve this issues.

It sounds like this is a bug; we use https://bugs.launchpad.net/nova to track bugs so they don't get lost.


--
Best wishes
======================  Peter.W  ======================

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140827/23cc1fb3/attachment.html>