Bug 833125 - backend: we do not disconnect a direct lun after creating the lun and after shut down of vm
backend: we do not disconnect a direct lun after creating the lun and after s...
Status: CLOSED WONTFIX
Product: ovirt-engine
Classification: oVirt
Component: Backend.Core (Show other bugs)
---
x86_64 Linux
high Severity medium (vote)
: ovirt-4.2.0
: ---
Assigned To: Allon Mureinik
Raz Tamir
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-18 12:25 EDT by Dafna Ron
Modified: 2017-02-06 07:56 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-02-06 07:56:37 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
ylavi: ovirt‑4.2+


Attachments (Terms of Use)
logs (379.14 KB, application/x-gzip)
2012-06-18 12:27 EDT, Dafna Ron
no flags Details

  None (edit)
Description Dafna Ron 2012-06-18 12:25:31 EDT
Description of problem:

we do not disconnect the connection to a direct lun, not after we create the lun and not after we stop the vm. 

1. we connect the lun each time the vm is run so there is no point in leaving the connection open (possible performance issues?)
2. if we reboot the host we will automatically try to reconnect to all targets and if a vm is down I do not see the point in trying to reconnect to it (mainly since I can have a large number of vm's and we have to reconnect to all). 

Version-Release number of selected component (if applicable):

si6

How reproducible:

100%

Steps to Reproduce:
1. create a direct lun
2. run iscsiadm -m session in host
3. run the vm -> shut down the vm 
  
Actual results:

we do not disconnect the direct lun after create and after shut down of vm 

Expected results:

we should disconnect the direct luns after create and after shut down of vm

Additional info: logs

[root@blond-vdsh ~]# iscsiadm -m session
tcp: [20] 10.35.64.10:3260,1 Dafna-si6
tcp: [24] 10.35.64.10:3260,1 Dafna-bla
tcp: [25] 10.35.64.106:3260,1 iqn.1986-03.com.sun:02:dafna112713222714816
tcp: [26] 10.35.64.10:3260,1 Dafna-direct1
tcp: [27] 10.35.64.10:3260,1 Dafna-direct10
tcp: [28] 10.35.64.10:3260,1 Dafna-ovirt1
tcp: [29] 10.35.64.10:3260,1 Dafna-ovirt2
tcp: [30] 10.35.64.10:3260,1 Dafna-fix
tcp: [31] 10.35.64.10:3260,1 Dafna-direct11
tcp: [32] 10.35.64.10:3260,1 Dafna-direct12
tcp: [8] 10.35.64.10:3260,1 Dafna-Small
Comment 1 Dafna Ron 2012-06-18 12:27:36 EDT
Created attachment 592703 [details]
logs
Comment 2 Andrew Cathrow 2012-06-24 11:19:38 EDT
Ayal, is the issue here relating to connection management - eg. we don't know if we can disconnect since the lun might still  be in use?
Comment 3 Ayal Baron 2012-06-24 11:26:59 EDT
(In reply to comment #2)
> Ayal, is the issue here relating to connection management - eg. we don't
> know if we can disconnect since the lun might still  be in use?

correct. it was a design decision for this version to not disconnect.
next version we'll have connection management which will inherently solve this issue.
Comment 4 Yaniv Kaul 2012-06-24 11:31:08 EDT
(In reply to comment #3)
> (In reply to comment #2)
> > Ayal, is the issue here relating to connection management - eg. we don't
> > know if we can disconnect since the lun might still  be in use?
> 
> correct. it was a design decision for this version to not disconnect.
> next version we'll have connection management which will inherently solve
> this issue.

It's not really mentioned @ http://www.ovirt.org/wiki/Features/Direct_Lun nor @ http://www.ovirt.org/wiki/Features/ConnectionReferences

Nevertheless, documenting this now, in Bugzilla, is better than nothing.

Anyway, this behavior - I'm pretty sure it'll cause trouble.
Comment 5 Ayal Baron 2012-06-25 18:32:36 EDT
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > Ayal, is the issue here relating to connection management - eg. we don't
> > > know if we can disconnect since the lun might still  be in use?
> > 
> > correct. it was a design decision for this version to not disconnect.
> > next version we'll have connection management which will inherently solve
> > this issue.
> 
> It's not really mentioned @ http://www.ovirt.org/wiki/Features/Direct_Lun
> nor @ http://www.ovirt.org/wiki/Features/ConnectionReferences
> 
> Nevertheless, documenting this now, in Bugzilla, is better than nothing.
> 
> Anyway, this behavior - I'm pretty sure it'll cause trouble.

I'm sure you're correct.  The alternative though would create a lot more at this point.
Comment 6 Itamar Heim 2013-01-07 03:12:36 EST
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.
Comment 8 Ayal Baron 2013-12-18 04:42:17 EST
This should be taken care of as part of Bug 881941.
keeping open to track downstream.
Comment 9 Ayal Baron 2014-01-09 15:17:00 EST
Thinking about this again, no point in keeping open.  Once bug 881941 is resolved this will be covered.
Comment 10 Yaniv Lavi 2016-12-04 09:34:06 EST
This is not a RFE, it's a bug.
We can discuss when to fix it and if, but it's not correct to keep it on future.

Note You need to log in before you can comment on or make changes to this bug.