Thanks for the quick response. Somehow I missed that binary in my search of applicable binaries and their man pages. That did the trick! >From what I've read it seems that most people who have deployed GFS on Xen instances are using a fence mechanism that ssh's to the Xen host running the instance and kills the instance locally. Mainly due to the fact that there is no security built into remote operations on xend, and enabling remote access to xend operations is strongly cautioned. Other are using traditional power based fence mechanisms that fence the Xen host itself which could take down several virtual servers at the same time. Is anyone using any alternative to the ssh or power method? If so, which method(s) are being used? Since my security department frowns strongly on authentication by ssh key, I'm writing a different way to fence xen instances via soap calls authenticated by ssl certificate exchange. Does anyone know if I'm reinventing the wheel, or if not, could other GFS users benefit from code? John A. -----Original Message----- From: David Teigland [mailto:teigland@xxxxxxxxxx] Sent: Tuesday, August 22, 2006 12:50 PM To: John Anderson Cc: linux-cluster@xxxxxxxxxx Subject: Re: Testing a fence program On Tue, Aug 22, 2006 at 12:42:19PM -0700, John Anderson wrote: > I'm in the process of developing a fence_* program that will xm shutdown > xen instances remotely. What is a good way to get fenced to invoke this > program so I can test/debug it. I don't see any such options to > fence_tool or fenced, and I'm thinking fence_manual will just manually > fence the instance without running the configured fence_ mechanism. fence_node executes the configured agent (cluster.conf) against the named node. The only way to test it with fenced is to run a cluster and kill one of the nodes. Dave -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster