On Mon, 2019-06-24 at 14:45 -0500, Bryan K. Walton wrote: > On Mon, Jun 24, 2019 at 12:02:59PM -0500, Ken Gaillot wrote: > > > Jun 20 11:48:36 storage1 crmd[240695]: notice: Transition 1 > > > (Complete=12, Pending=0, Fired=0, Skipped=0, Incomplete=0, > > > Source=/var/lib/pacemaker/pengine/pe-input-1054.bz2): Complete > > > Jun 20 11:48:36 storage1 pengine[240694]: error: Resource > > > targetRHEVM is active on 2 nodes (attempting recovery) > > > > This means that pacemaker found the target active on storage2 > > *without* > > having scheduled it there -- so either something outside pacemaker > > is > > setting up the target, or (less likely) the agent is returning the > > wrong status. > > Thanks for the reply, Ken. I can't figure out what might have caused > these iSCSI targets to already be active. They aren't configured in > targetcli (outside of Pacemaker) and I have no scripts that do > anything > like that, dynamically. > > I don't have a default-resource-stickiness value set. Could that > have > caused the iSCSI targets to be brought up on the node that was being > brought out of standby?
No stickiness wouldn't affect it. Have you tried checking whether the target is really active before bringing the node out of standby? That would narrow down whether the issue is in pacemaker or earlier. I'd double-check it isn't enabled in systemd. Another possibility is if some other systemd service requires the target, systemd might start the target even though it's not enabled (I believe the only way around that would be to put the other service under cluster control as well). > > Thanks! > Bryan > -- Ken Gaillot <[email protected]> _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
