| 2014-08-28 09:37:34 |
Shen Wang |
bug |
|
|
added bug |
| 2014-08-28 09:53:39 |
Shen Wang |
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 connected with almost 900 LUNs.
First, I use 'iscsiadm' with '--rescan' to discover LUNs.
Second, I use 'multipath -r' to construct multipath devices.
The tow steps scans all of the LUNs, and 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 tow 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. |
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 connected with almost 900 LUNs.
First, I use 'iscsiadm' with '--rescan' to discover LUNs.
Second, I use 'multipath -r' to construct multipath devices.
The two steps scans all of the LUNs, and 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 tow 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. |
|
| 2014-08-28 10:05:48 |
Shen Wang |
summary |
libvirt: connect_volume scans all LUNs, it will be very slow with a large number of volumes |
libvirt: connect_volume scans all LUNs, which takes >2 mins when host is connected with about 900 Luns |
|
| 2014-08-28 10:20:54 |
Shen Wang |
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 connected with almost 900 LUNs.
First, I use 'iscsiadm' with '--rescan' to discover LUNs.
Second, I use 'multipath -r' to construct multipath devices.
The two steps scans all of the LUNs, and 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 tow 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. |
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. |
|
| 2014-08-29 01:50:19 |
Shen Wang |
tags |
|
libvirt |
|
| 2014-09-10 12:03:49 |
Sean Dague |
nova: status |
New |
Opinion |
|
| 2014-09-10 12:03:54 |
Sean Dague |
nova: importance |
Undecided |
Wishlist |
|
| 2014-09-26 02:47:09 |
Shen Wang |
nova: status |
Opinion |
In Progress |
|
| 2014-09-26 02:47:09 |
Shen Wang |
nova: assignee |
|
Shen Wang (peter.w) |
|
| 2015-02-12 16:25:33 |
Davanum Srinivas (DIMS) |
nova: status |
In Progress |
Confirmed |
|
| 2015-02-12 16:25:46 |
Davanum Srinivas (DIMS) |
nova: assignee |
Shen Wang (peter.w) |
|
|
| 2015-03-31 04:46:47 |
Keiichi KII |
bug |
|
|
added subscriber Keiichi KII |
| 2016-05-17 17:00:12 |
Markus Zoeller (markus_z) |
nova: status |
Confirmed |
Opinion |
|
