On Mon, 2009-02-23 at 12:40 -0600, David Teigland wrote: > 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.
What can stop a user to run fence_node -U from another node to do remote (un)fencing? How do we address the problem of nodes booting from that same shared storage? Fabio
