Description of problem: In the event of a full host power outage (including fence devices) a user must wait 9 mins (3 x 3 minute timeouts) until they can manually fence a host to relocate the SPM. Version-Release number of selected component (if applicable): rhevm-3.2.3-0.43.el6ev.noarch How reproducible: Always Steps to Reproduce: 1. Remove all power to an active SPM, including any fence agents that are configured. 2. Attempt to manual fence the SPM to relocate the role. Actual results: The role can only be relocated once the host has moved from a state of 'connecting'. Expected results: The role can be relocated while the host is still marked as 'connecting' if the user confirms the host is down. Additional info:
lee - is this still true with bug 863211 fixed for 3.3? ayal - why do we need to wait for fencing with spm being based on sanlock?
(In reply to Itamar Heim from comment #3) > lee - is this still true with bug 863211 fixed for 3.3? > ayal - why do we need to wait for fencing with spm being based on sanlock? I don't see what sanlock has to do with it. It should be just as safe with the old locking mechanism. I have no idea why we wait
(In reply to Itamar Heim from comment #3) > lee - is this still true with bug 863211 fixed for 3.3? Thanks Itamar, that looks promising but I'll need to verify. Setting needinfo as a reminder for the morning.
(In reply to Lee Yarwood from comment #5) > (In reply to Itamar Heim from comment #3) > > lee - is this still true with bug 863211 fixed for 3.3? > > Thanks Itamar, that looks promising but I'll need to verify. Setting > needinfo as a reminder for the morning. Testing this shows a drastically reduced time for the SPM to failover in the event of a complete power outage. I'm going to close this out as a dup of 863211. Thanks, Lee *** This bug has been marked as a duplicate of bug 863211 ***
Changing the BZ title according to comment 7 and re-assigning the BZ We will support manual fence in connecting state
Arthur please approve
If this doesn't break any existing flows - ACK
This bug is referenced in ovirt-engine-3.4.0-beta3 logs. Moving to ON_QA
tested on ovirt-engine-3.4.0-0.11.beta3.el6.noarch 1. Put host in connecting state by iptables -D INPUT -p tcp --dport 54321 -j ACCEPT 2. Host have unreachable PM 3. Host state is now connecting and there is attempts to check host status 4. /etc/init.d/iptables restart 5. right-click and confirm host is rebooted Result host came up immediately Can i move this to verify?
see comment 15
(In reply to Tareq Alayan from comment #15) > tested on ovirt-engine-3.4.0-0.11.beta3.el6.noarch > > > 1. Put host in connecting state by iptables -D INPUT -p tcp --dport 54321 -j > ACCEPT > 2. Host have unreachable PM > 3. Host state is now connecting and there is attempts to check host status > 4. /etc/init.d/iptables restart > 5. right-click and confirm host is rebooted > Result host came up immediately > > > Can i move this to verify? Yes
verified per comment 17
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/RHSA-2014-0506.html