Bug 833125

Summary: backend: we do not disconnect a direct lun after creating the lun and after shut down of vm
Product: [oVirt] ovirt-engine Reporter: Dafna Ron <dron>
Component: Backend.CoreAssignee: Allon Mureinik <amureini>
Status: CLOSED WONTFIX QA Contact: Raz Tamir <ratamir>
Severity: medium Docs Contact:
Priority: high    
Version: ---CC: acanan, bsettle, bugs, hateya, lpeer, rbalakri, Rhev-m-bugs, scohen, srevivo, ylavi
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-02-06 12:56:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
logs none

Description Dafna Ron 2012-06-18 16:25:31 UTC 
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 16:27:36 UTC 
Created attachment 592703 [details]
logs
Comment 2 Andrew Cathrow 2012-06-24 15:19:38 UTC 
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 15:26:59 UTC 
(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 15:31:08 UTC 
(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 22:32:36 UTC 
(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 08:12:36 UTC 
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 09:42:17 UTC 
This should be taken care of as part of Bug 881941.
keeping open to track downstream.
Comment 9 Ayal Baron 2014-01-09 20:17:00 UTC 
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 14:34:06 UTC 
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.