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

[Noel Kuntze]

-----BEGIN PGP SIGNED MESSAGE-----
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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVwsgQAAoJEDg5KY9j7GZY15kP/0iScwPftMkssy5K33Cj1Qa5
9jOwOAB35yNoecsfpG26b1jLN2V0XsNOQa1NKp9L6lx0TXiv/2D9meu9/aRckVG5
rPgzl4zuOeNrdIYzN+AHruDfIiqbtxwRQ83taUulP+rtYAspJt8KwcjQiyp4MkGp
IyH4YphbN7jWKl/EwNqSsneEIjI6jZrD93DFVI9wmCsg1zKd8IcOAaAeB86q9C24
JQE4s8tvxOw6BkoIEZq8fBC4aFvhBBSKvoBUwvTUnlcTWwoxraHRbXz+R+F+Zr3Z
Db6kOMs2q5Ogscpv2xlJaP5VCGgsCSMEesJT3hBR4AgSWbHgexlKKG1PGRTBUWz3
EuhC7TR66tfldTS8mbiZ6lqdjeXneRnEWIhZaCwHWOu8k4Q5ap5X8r1PYnzJIEXA
XKfJquPuSiesyflMdxxMZeDCW/Fme8V9dF8cy6TzUrEjLAqPo7kyXtxJxzXJk5x3
qWcsF9BIhoExfX0jx6pYes4ArzxGw8umUB4Sp5J0smAI5V8+DUp2NHNNjRdfeHfd
fwwchC8sruX51pQEiniOv2FfejwTKqv/Qqd+A+ps1/02j4S/jITcVWBX819RTswJ
UA1bSS/dSFZc0DEZhUCxdgJYuAQ/1SPNePK2Okb9BgX24phoF5/f5NuDGTA9ZUN2
IgiMTn7O0gx0fhz+nS4l
=OBVz
-----END PGP SIGNATURE-----