Hi, Lon
(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.
- HealthCPU
- SysInfo
- diskd (disk monitor RA - published only in Japanese community.
http://hg.sourceforge.jp/view/linux-ha/pm_diskd/)
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
<cib>
<status>
<node_state ...>
<transient_attributes ...>
<instance_attributes ...>
<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:
>
> http://git.fedorahosted.org/git/?p=vios-proxy.git
>
> (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.
Best Regards,
Kazunori INOUE
> * 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
