fcoe-target.init is still applying tcm_start.sh on service start instead of using saveconfig.json. This means that rebooting the machine will not retain fcoe target configuration
*** Bug 819698 has been marked as a duplicate of this bug. ***
FAILED QA. restart fcoe-target daemon can restore configure, BUT reboot CANNOT. This is output after reboot: ==== [root@storageqe-13 ~]# targetcli ls / targetcli ls / o- / ................................................ [...] o- backstores ..................................... [...] | o- block ........................................ [0 Storage Object] | o- fileio ....................................... [1 Storage Object] | | o- disk1 .................... [/tmp/fcoe-lun1 (10.0G) deactivated] | o- pscsi ........................................ [0 Storage Object] o- loopback ....................................... [0 Target] o- tcm_fc ......................................... [0 Target] [root@storageqe-13 ~]# chkconfig --list|grep fcoe fcoe 0:off 1:off 2:on 3:on 4:on 5:on 6:off fcoe-target 0:off 1:off 2:on 3:on 4:on 5:on 6:off ==== When fcoe-target start, chances are fcoe daemon not yet setup FCoE port. So targetcli refuse to create non-exist target. Workround: Put this line into /etc/rc.local: ==== service fcoe-target restart ==== Possible solutions: 1. fcoe daemon only quit after all FCoE session created. (fcoe need a standalone tool for OS boot for this, like iscsi have iscsistart tool) 2. Change fcoe-target daemon to S99, but still have chances for failure. 3. Devs use magic.
Petr, how to we ensure fcoe setup is complete before fcoe-target setup?
You can't really ensure that. Anything could go wrong. The best thing you could do at the moment is check the output of fcoeadm, possibly in a loop with a timeout.
yuck, but ok. So: If there are configured fcoe targets, grep the output of fcoeadm -i until they show up and then proceed. What should the timeout be?
(In reply to comment #11) > yuck, but ok. So: > > If there are configured fcoe targets, grep the output of fcoeadm -i until > they show up and then proceed. > > What should the timeout be? I'd go with the usual 60 seconds. You could also make that configurable since you're going to hack this in :)
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0854.html