-----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: [email protected] > 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----- _______________________________________________ Users mailing list: [email protected] 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
