[ClusterLabs] fence-virtd reach remote server serial/VM channel/TCP

Noel Kuntze noel at familie-kuntze.de
Wed Aug 5 22:36:04 EDT 2015

Hash: SHA256

Hello Jan,

I know that increasing the complexity reduces the
availability of a service, so it is no surprise to me
that it is frowned upon running services, which
should be highgly available, on virtual machines.

However, services are regularely run on
VMs and HA is desired, even if the only thing
that should be "protected" against is the downtime
when the kernel needs to get upgraded or
a daemon needs to be restarted.

So I think fence-virt has a use case.
My use case currently is to build a HA cluster
of VMs, which currently host a simple mirror for software
packages. They're stored on shared storage, which has a
partition formatted with GFS2 on it. I use pcs(d), pacemaker,
corosync and fence-virt over a serial device to fence hosts.
Obviously, a single serial connection
I currently only have one hypervisor, but could expand to more.
I'm doing this, because I want to write a doc about clustering
on Linux in the year 2015, so clustering on VMs is definitely a use case
that I will describe.

I know that multicast should actually work in common use cases,
but I found that for some reason, the bridge device of the VMs don't forward
traffic for the default multicast group of fence-virt to the other bridge ports, rendering
it useless. I haven't dug deeper why that happens, but through Googling I found
that it's a common problem that bridge devices on Linux don't forward
some types of traffic. Obviously, if multicast works, one can just relay
multicast networks over several other interfaces to relay requests.

The man page of virt_fence.conf mentions "libvirt-qmf" as backend, instead
of "libvirt", which should be able to route fencing requests to the correct host by using
Apache QMF. I figure that's the correct backend for such a purpose.

Mit freundlichen Grüßen/Kind Regards,
Noel Kuntze

GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Am 05.08.2015 um 21:09 schrieb Jan Pokorný:
> On 02/08/15 16:30 +0200, Noel Kuntze wrote:
>> I would like to know if it is possible for
>> fence-virtd to realy a request from a client, which it
>> received via serial, VM channel or TCP connection
>> from an agent to another daemon, if the VM that should
>> be fenced does not run on the same host as the contacted daemon.
> First, it doesn't sound like very commendable or at least common setup
> to have virtualized cluster nodes spread around multiple hosts.
> When increasing the complexity of a deployment, new points of failure
> can be introduced, defeating the purpose of HA.
> Could you please share details of your use case? 
> To your question, it might (hypothetically) be doable if you manage to
> put the guests on the first host together with the other host into
> the same multicast-friendly network or will rely multicast packets
> between those "remote" sides by other means.
> Alternatively, you might implement such relying directly as
> fence_virtd module (backend), possibly reusing some code from the
> client side (fence_virt).
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/users
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org

Version: GnuPG v2


More information about the Users mailing list