On 10/05/2011 04:56 AM, Kazunori INOUE wrote:
> Hi all,
>
> I think that the communication function of fence-virt is flexible,
> so I want to use it more effectively.
>
> Therefore I made backend plugin for a guest to get the host's status
> using the communication facility of fence-virt,
> and I changed to allow specifying one more backend (for fencing, and
> replying the host's status).
>
> I created the backend "pm-monitor" which has met the following
> configurations / requirements.
> - Both hosts and VMs, cluster (Pacemaker) have been configured.
>
> Here's an overview of function. Please refer to attached 'overview.png'.
> (*) pingd resource notifies the status of connection with a specific
> host to pacemaker, and pacemaker manages the result.
> (1) resource (vm-client) which requires the host's status is executed.
> (2) vm-client requests 'host_status (result of pingd)' to the host
> with fence_virt.
> (3) use the serial listener,
> (4) fence_virtd (pm-monitor backend) gets the 'result of pingd' from
> pacemaker and answers it after conversion.
> - the conversion rule is set in /etc/pm-monitor.conf
Originally, the devstatus callback was supposed to be what provided the
answer to the question "is my fencing [device|host] operational?" - but
your patch is more than that, it looks like a generalized way to do
arbitrary request/response pacemaker resource monitoring from within VMs.
That kind of monitoring is interesting.
> Here's a description of the attached files.
> * add_general_backend.patch
> - add the server/pm-fence.c
> - change the configure.in and server/Makefile.in
I think I understand how it operates; your explanation is very detailed.
* I don't quite understand all of the benefits. Presumably, one uses
the serial configuration to prevent guests/hosts from sharing the same
networks - i.e., it's designed for environments where guests and hosts
are not allowed to talk over the network to each other. So, presumably,
we're using this to indirectly monitor an IP on the host network, using
fence-virt as a bridge. What I don't understand is the benefit to the
virtual machine cluster in doing this.
* Do you see other uses besides monitoring pingd sets?
* It may be that this new project may be a better "backbone" for this
sort of general request/response than fence-virt; it's a much more
general communications medium for guest<->host communication:
http://git.fedorahosted.org/git/?p=vios-proxy.git
(although it is written in C++ ;) ).
Notes about the patch itself:
* no support for multicast listener (this looks intentional -
is it?)
* this will break on-wire compatibility; we need to be very careful
here.
* some duplicate build system changes with the other
patch (not a big deal)
* [not directly related to your patch] the vmchannel/serial support
in fence-virt probably should be replaced with more recent
technology in libvirt
-- Lon
