> On 2010-06-08 16:03, Caspar Smit wrote: >> I also noticed that for the OCF scripts to work you have to start iscsi-target via the init script at boot using an EMPTY ietd.conf because >> for the scripts to work /usr/sbin/ietd has to be running otherwise the scripts give a "Connection refused" error and all hell breaks loose in pacemaker saying that the scripts/monitors are not installed etc. Maybe this can be incorperated in an updated version of the scripts that it start ietd if it is not running at all. > > Nope, won't do, but the upstream version of these RAs do this checking more appropriately.
Ok, I tried the latest upstream iSCSI* RAs from http://hg.linux-ha.org/agents and now the connection is lost (State -> Inactive) in MS iSCSI initiator EVERYTIME when i do a failover (before it worked sometimes, now it never works). The scripts themselves seem more stable now though, i didn't have any crashing ietd anymore. Here are some (Windows 2003 Server Standard) event logs. (I use the latest iSCSI initiator btw 2.08). I first thought it had something to do with MPIO because everytime i connected a target/lun it showed up as multipath device although i didn't select MPIO and don't have multiple paths atm. Now i completely uninstalled MPIO support to be sure and the situation didn't change. It starts with event id 20 from iScsiPrt: Connection to the target was lost. The initiator will attempt to retry the connection. then immediatly event id 10 from iScsiPrt: Login request failed. The login response packet is given in the dump data. then event id 12 from PlugPlayManager: The device 'IET VIRTUAL-DISK SCSI Disk Device' (SCSI\Disk&Ven_IET_____&Prod_VIRTUAL-DISK____&Rev_0___\1&1843ccbc&0&000000) disappeared from the system without first being prepared for removal. Finally event 57 from Ftdisk: The system failed to flush data to the transaction log. Corruption may occur. The only thing I changed was ditching portblock (Like Ross suggested). Then I tried enabling portblock again and now the connection reinstatement failover works like before, only from node01 -> node02 and NOT the other way around. Conslusion: I think that during a failover without portblock the connection is tried to reconnect too soon (when it's still on the old node but not up) and then give an immediate fail on the initiator side resulting in a disconnection (State -> Inactive). Any ideas how to solve this? Kind regards, Caspar > >> SOMETIMES the scripts even let ietd crash when stopping/migrating a resource(group) leaving the resource(group) in an unmanaged state. Finally the scripts do need the /etc/initiators.allow >> /etc/initiators.deny >> files when using allowed initiators. Since IET version 1.4.18 >> initiators.allow is deprecated and the base IET directory moved to /etc/iet. > > Right. Which leads me to an question for Russ and Arne: would you guys accept a patch which would include the OCF resource agents for > iSCSITarget and iSCSILogicalUnit (stripped down to only support IET, of course) in upstream IET? These resource agents would then install into their own OCF resource agent provider directory -- say "iet" -- and could be invoked in Pacemaker as ocf:iet:iSCSITarget and > ocf:iet:iSCSILogicalUnit. Thus they would not conflict with any other RAs, and they could be maintained as part of IET where they belong. > > And then, the RA could also start ietd of course, like Caspar suggests. > >> I had to manually create /etc/initiators.allow /etc/initiators.deny for the OCF scripts because without them they crashed. > > Huh? I don't see that happening. Explain in more detail how they "crashed" please. > >> This was also posted to the DRBD mailinglist. > > This has nothing to do with DRBD, this is about a Linux-HA resource agent and should thus be discussed on linux-ha-dev. > > Cheers, > Florian > > ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo_______________________________________________ Iscsitarget-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel > _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
