Bug 643092
Summary: | Never forgets iscsi sessions & silently logs back in upon network activation | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Daniel Berrangé <berrange> | ||||
Component: | libvirt | Assignee: | Daniel Veillard <veillard> | ||||
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 14 | CC: | berrange, clalance, crobinso, hdegoede, itamar, jforbes, mchristi, veillard, virt-maint | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | |||||||
: | 652730 (view as bug list) | Environment: | |||||
Last Closed: | 2011-01-24 04:25:10 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Daniel Berrangé
2010-10-14 15:43:22 UTC
Created attachment 453499 [details]
Clearer log of the command sequence to demonstrate problem
Bugzilla munged the line endings in the initial description. Attached a clearer copy of the command sequence.
/etc/init.d/iscsi start logs into all portals with the node.startup = automatic. If instead of that script controlling startup, you should mark the startup = manual. If that does not help or what you were looking for, then we need something completely different, because this is just how the tools/daemon/script work. The iscsiadm login/logout command just tells the kernel to login/logout a sessions it does not control the /etc/init.d/iscsi script's startup behavior. And normally if you were to logout a session with iscsiadm then ran /etc/init.d/iscsi start, users expect the node.startup setting to indicate that the session should be logged in (users use the script to log into the sessions instead of running iscsiadm). Oh yeah, to set the startup you can edit /etc/iscsi/iscsid.conf's node.startup, then rediscover the iscsi portals (when you discover the portals the new iscsid.conf setttings get picked up). Or run iscsiadm to set the node.startup for existing records iscsiadm -m node -o update -n node.startup -v manual IMHO startup = manual should be the default here. Merely running iSCSI sendtargets should not be causing the host to automatically login to the targets forever after, unless the admin explicitly asked for that behaviour. (In reply to comment #4) > IMHO startup = manual should be the default here. Merely running iSCSI > sendtargets should not be causing the host to automatically login to the > targets forever after, unless the admin explicitly asked for that behaviour. They do try to login forever though. They login for whatever your initial login retries and timeouts are set at. Also normally users set things up on the target so only the targets that are accessible to the initiator are returned in sendtargets discovery. So every target returned during discovery is one they want to log into (this is why the default for startup is automatic). (In reply to comment #5) > (In reply to comment #4) > > IMHO startup = manual should be the default here. Merely running iSCSI > > sendtargets should not be causing the host to automatically login to the > > targets forever after, unless the admin explicitly asked for that behaviour. > > They do try to login forever though. They login for whatever your initial login > retries and timeouts are set at. > Ignore that part of the comment above. I thought you meant something different. In a SOHO environment where people are using something like a Netgear/QNap NAS to provide iSCSI, it is far less likely that the target list will be zoned per client machine. In any case, I've added code to libvirt to force node.startup=manual everytime 'sendtargets' is run to work about this debatable behaviour. Patch series upstream http://www.redhat.com/archives/libvir-list/2010-November/msg00545.html Should be available in F15, since we are not backporting to F14 Daniel |