(2011/10/26 10:35), Lon Hohberger wrote:
> 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?
Yes, VM can get the status of host's hardware (status of disk, status
of CPU, etc.) if the following RAs are running on the host.
- diskd (disk monitor RA - published only in Japanese community.
Since such RA writes status of hardware into the CIB(*), vm-client can
specify the attribute and can get it's value.
(*) example of the CIB
# cibadmin -Q
<nvpair id="..." name="default_ping_set" value="100"/>
<nvpair id="..." name="#health-cpu" value="green"/>
<nvpair id="..." name="diskd" value="normal"/>
Our final purpose is to get the status of host's hardware who cannot
perform acquisition directly from a guest by this way.
> * 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:
> (although it is written in C++
OK, thank you. We will also see it.
> Notes about the patch itself:
> * no support for multicast listener (this looks intentional -
> is it?)
Yes. This patch is only support for serial listener.
> * this will break on-wire compatibility; we need to be very careful
> * 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