From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Teigland Date: Mon, 23 Feb 2009 12:40:30 -0600 Subject: [Cluster-devel] unfencing In-Reply-To: <1235413889.7816.256.camel@cerberus.int.fabbione.net> References: <20090220214431.GC23911@redhat.com> <1235370440.7816.209.camel@cerberus.int.fabbione.net> <20090223181530.GB12791@redhat.com> <1235413889.7816.256.camel@cerberus.int.fabbione.net> Message-ID: <20090223184030.GC12791@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Mon, Feb 23, 2009 at 07:31:29PM +0100, Fabio M. Di Nitto wrote: > Given this last example, a reasonable unfence operation would be to try > to poweron via apc too. > > There is no guarantee that it was only method="1" fencing the node and > the node could be powered off. > > if we succeed in enabling the switch port, we still don't guarantee that > the node will come back because of lack of power.. > > How do we protect a node that failed to be fenced, from being unfenced? > > Example 2: > both method="1" and method="2" fail to fence node X. > At this point any unfence operation is extremely dangerous. A node unfences *itself* when it boots up. As such, power-unfencing doesn't make sense; unfencing is only meant to reverse storage fencing. Dave