Currently the git tree on Fedora Hosted has a fence_virsh option that is included with the latest packages in Fedora Rawhide. I have personally tried these scripts under Red Hat Enterprise Linux 5.3 with great success and ease. It would be nice to have these scripts included with Red Hat Enterprise Linux 5.4 (or a later version if it can't be 5.4). The main things that the scripts have for it over fence_xvmd: * Easy to set up (1 line, plus an extra for each node) * Only requires SSH setup and working I'm sure there are others I've missed but they are the main ones for me.
Actually most likely the biggest advantage that fence_virsh has over fence_xvmd is that you don't need to install anything on the host, which means you can have say a Gentoo host machine or maybe a Debian host machine, and not have to install the cluster tools on the host to get it working - a nice extra thought.
I think there is value in including fence_virsh as per Comment #1. Theoretically any system that supports libvirt could be used as a fence device for virtual machines. (Perhaps fence_virsh could one day replace fence_vmware once libvirt supports vmware) However, I think we should make it clear that fence_virsh does not provide the same level of functionality as fence_xvmd. My understanding is that fence_virsh does not tie into the cluster running on the host node. So we should recommend using fence_xvmd when cluster suite is being used on the host OS and the guest is being treated as a service managed by rgmanager. But if cluster suite is not being run on the host OS (say in the case of using oVirt or RHEV which has a centralized mgmt server for fencing the physical hosts) then fence_virsh could be used as a lightweight fence agent that doesn't pull in all of the cluster infrastructure on the host.
So, I believe fence_virsh is not actually easier to configure on a RHEL or Fedora system than fence_xvm[d]. Fence_virsh both requires more administrative steps and more configuration information in order to operate in the simplest case where fence_virsh is typically used. Today, fence_xvmd will likely only run on Linux, and, as stated, requires a fair bit of other software be installed because of the way it is built. In the absence of this software, you can't currently use fence_xvmd (even in single-node mode), though you can use fence_virsh. It is easily possible to eliminate fence_xvmd's dependencies on other software (and only link against libvirt), but maybe not worth the effort since a solution already exists (i.e. fence_virsh). Fence_xvmd however is a new "daemon", for which we do not have a separate init script today, which is kind of ugly. Rgmanager managing VMs is a different issue and is completely orthogonal to use of fence_xvmd or fence_virsh. Whenever you are using VMs on a cluster of hosts where the VMs are stored on shared storage (rgmanager or not; it doesn't matter), using fence_virsh should not be supported. It does not have previous knowledge of VM states and locations and can not tie in correctly to the fencing subsystem on the host cluster. Adding these functions to fence_virsh would be (a) substantially more work than removing run-time software dependencies from fence_xvmd, and (b) make fence_virsh a difficult piece of software to configure. I.E. If we end up wanting one agent to serve both use cases in the future, the answer is "remove runtime dependencies from fence_xvmd and add an initscript", not "add cluster support to fence_virsh".
BTW I should have said a "clustered file system", not "shared storage". I.e. anything which would normally require fencing.
Also, administrators are probably more familiar with ssh key distribution and so forth, so they may find it easier to understand and configure despite the fact that it requires more steps and information.
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: The fence_virsh fence agent is provided in this release of RHEL along side the other fence agents in the cman package. fence_virsh provides the ability for one guest running as a domU in Xen or KVM guest to fence another using the libvirt protocol. However, since fence_virsh is not integrated with cluster-suite it is not supported as a fence agent in that environment. fence_virsh is considered Tech Preview for this release.
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -The fence_virsh fence agent is provided in this release of RHEL along side the other fence agents in the cman package. fence_virsh provides the ability for one guest running as a domU in Xen or KVM guest to fence another using the libvirt protocol. However, since fence_virsh is not integrated with cluster-suite it is not supported as a fence agent in that environment. fence_virsh is considered Tech Preview for this release.+The fence_virsh fence agent is provided in this release of Red Hat Enterprise Linux as a Technology Preview. fence_virsh provides the ability for one guest (running as a domU) to fence another using the libvirt protocol. However, as fence_virsh is not integrated with cluster-suite it is not supported as a fence agent in that environment.
Fencing agent from #472785 (rawhide) was modified to work with older version of fencing library.
*** Bug 516160 has been marked as a duplicate of this bug. ***
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2009-1341.html