| Summary: | [NetApp 6.1 Bug] Software iSCSI module does not get loaded automatically during boot time | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | gowrav <gowrav.mahadevaiah> |
| Component: | doc-Storage_Admin_Guide | Assignee: | Jacquelynn East <jeast> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | ecs-bugs |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.1 | CC: | agrover, coughlan, jskeoch, mchristi, rlandman, xdl-redhat-bugzilla |
| Target Milestone: | rc | Keywords: | Documentation |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-12-07 02:19:58 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Deadline: | 2011-06-30 | ||
|
Description
gowrav
2011-03-15 09:32:31 UTC
For #6 iscsid is not going to start automatically if you do not have any sessions setup to get logged into automatically. For #7 and #8, how are you starting iscsid? Using "service iscsid start" or just running iscsid by hand? In 6.0 we changed how iscsi starts so that is only starts when needed. So if you did not have any iscsi sessions setup for automatic start the iscsid/iscsi services are not going to start. If you run a iscsiadm command that requires them then iscsiadm will start the services. So if you did iscsiadm -m discovery -t st -p 192.168.1.100 then iscsiadm would start the iscsid serivce for you. Then later on another reboot or restart of the service iscsid would start with the normal start command if there were sessions marked with node.start=automatic. To force the start of iscsid/iscsi when there are no automatic sessions then you now would run service iscsid force-start OK, now i understand this behavior. When i booted the host without any iSCSI session configured, the iscsi daemon did not start. Later, i had to use "service iscsid force-start" or "iscsiadm -m discovery" commands to start the iscsi daemons. I just want to understand the reason behind this design approach unlike in RHEL5 series. I was wondering if iscsi start provision can be provided to user via "chkconfig" option instead of asking user to execute commands to force-start iscsi when user wants to configure iscsi session for the very first time. By default, iscsi daemons do not start at boot if no iscsi session are configured or if 'chkconfig' is OFF for iscsid/iscsi. And if 'chkconfig' is turned ON for iscsid/iscsi then daemon should start at boot (though iscsi session are not configured yet). This would be very similar to how "multipathd" is starting at boot time now. Can this be done? Let me know your thoughts. Currently, iscsi does not start at boot though 'chkconfig' is ON. (In reply to comment #3) > I just want to understand the reason behind this design approach unlike in > RHEL5 series. I was wondering if iscsi start provision can be provided to user > via "chkconfig" option instead of asking user to execute commands to > force-start iscsi when user wants to configure iscsi session for the very first > time. There is no chkconfig option like this. It was done because the boot developers wanted iscsid to start only when needed. So the first time you run a iscsiadm command that requires iscsid, then it will be started at that time. I think the thought was why would you want iscsid running if there was nothing using it? It just slows boot and waste resources. I do not think we could think of any a reason why it should be running. Did you have a scenario? Since RHEL 6.1 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. (In reply to comment #4) > Did you have a scenario? Or can we close this now? No, we do not have any particular scenario per se. Yes we can close this BZ, however as discussed in our previous meeting, it will be useful if this behavior is well documented (may be in user guide). I am changing the component to Storage Admin Guide. Mike or Andy, please draft a paragraph or two that explain the issue for users. Maybe say what the rationale for the change was. Then the doc maintainer can add that to the manual and close this. Tom Here is something we can add: In RHEL 6 the iSCSI service is lazily started by default. If root is not on a iSCSI device or there are no nodes marked with "node.startup = automatic" then the iSCSI service will not start until a iscsiadm command is run that requires iscsid or the iscsi kernel modules to be started. For example, running the discovery command "iscsiadm -m discovery -t st -p ip:port" will cause iscsiadm to start the iSCSI service. To force the iscsid daemon to run and iSCSI kernel modules to load run "service iscsid force-start". |