On Fri, Jun 8, 2012 at 5:40 PM, Léon Keijser <[email protected]> wrote: > On Thu, 2012-06-07 at 10:37 +1000, Andrew Beekhof wrote: >> > Now according to the fence_virsh ra info, the param 'port' should >> > indicate the name of the guest on the hypervisor. >> >> IIRC we try to work it out automatically, but the shell sees the >> metadata and tries to force a value. >> Try just leaving it blank or setting to the magic string "dynamic" >> >> This has since been fixed: >> https://bugzilla.redhat.com/show_bug.cgi?id=720214 > > Alright, thanks. > > >> > In my first attempt, >> > the name in virt-manager was 'pacemaker-1'. Fencing then didn't work. It >> > would only work when the node name (#uname) was the same as the guest >> > kvm name. >> >> Right. The uname needs to be in the output of "virsh list" somewhere. > > > Didn't know that. The helptext of the RA could be a little more verbose > then, but ok. > > >> > Also, a strange behavior that I can't explain: if I ssh-copy-id the >> > public keys of both pacemaker nodes to the hypervisor machine, fencing >> > no longer works, even if I specify the path to the public key in param >> > identity_file and/or leave out the password. >> >> I'd actually recommend fence_xvm over fence_virsh. I've had much more >> success with it. > > > I couldn't get fence_xvm to work since the only thing I could specify > was a multicast address instead of the IP libvirtd listens on.
You need the multicast IP that /fence_virtd/ is running on, not libvirtd. On fedora I just use the defaults and poke a hole in the firewall. _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
