----- Original Message -----
From: "WANG Chao" <chaowang(a)redhat.com>
To: "Martin Perina" <mperina(a)redhat.com>
Cc: kexec(a)lists.fedoraproject.org, "Itamar Heim" <iheim(a)redhat.com>
Sent: Thursday, March 13, 2014 12:05:51 PM
Subject: Re: Adding support for manually configured fence_kdump
On 03/13/14 at 04:09am, Martin Perina wrote:
>
>
> ----- Original Message -----
> > From: "WANG Chao" <chaowang(a)redhat.com>
> > To: "Martin Perina" <mperina(a)redhat.com>
> > Cc: kexec(a)lists.fedoraproject.org
> > Sent: Thursday, March 13, 2014 8:50:26 AM
> > Subject: Re: Adding support for manually configured fence_kdump
> >
> > On 03/13/14 at 02:47am, Martin Perina wrote:
> > > Hi,
> > >
> > > we want to integrate support for fence_kdump into oVirt project. Marek
> > > Grac
> > > pointed me
> > > to kexec-tools-2.0.4-23 which contains automatic configuration of
> > > fence_kdump from Pacemaker config.
> > > Unfortunately for us, this support is tightly bound to Pacemaker, so I
> > > created attached patch,
> > > which adds support for manual configuration of fence_kdump:
> > >
> > > 1) Current status without this patch (kexec-tools-2.0.4-23)
> > > - when running 'kdumpctl restart' kdump detects if
> > > fence_kdump_send
> > > command is installed
> > > and if so, it tries to:
> > >
> > > a) Create /etc/sysconfig/fence_kdump file with command line
> > > parameters for fence_kdump_send.
> > > These parameters are extracted from cluster configuration
> > > using
> > > 'pcs cluster' command
> >
> > We don't create /etc/sysconfig/fence_kdump. Instead it's created by
> > fence kdump end user who want to configure fence_kdump_send to run with
> > options rather than default. And we install it to 2nd kernel and source
> > it in our kdump.sh if it exists in 1st kernel.
>
> That's true, my mistake.
>
> >
> > In 2nd kernel, we run fence_kdump_send as the following:
> >
> > $FENCE_KDUMP_SEND $FENCE_KDUMP_OPTS host1 host2 ... hostN
> >
> > As you probably know, $FENCE_KDUMP_SEND stands for
> > /usr/libexec/fence_kdump_send. So the command is pretty much as
> >
> > /usr/libexec/fence_kdump_send $FENCE_KDUMP_OPTS host1...hostN
> >
> > n /etc/sysconfig/fence_kdump doesn't exist, $FENCE_KDUMP_SEND is
> > empty, fence_kdump_send is called with no options, but hosts list:
>
> OK, so I can modify my patch, that for manual configuration only
> /usr/libexec/fence_kdump_send and /etc/sysconfig/fence_kdump_hosts
> will be mandatory
>
> >
> > /usr/lib/exec/fence_kdump_send host1...hostX
> >
> > When user creates /etc/sysconfig/fence_kdump and configures
> > FENCE_KDUMP_OPTS to something like "-c 2 -i 10 -v" in it,
> > fence_kdump_send is called as:
> >
> > /usr/libexec/fence_kdump_send -c 2 -i 10 -v host1...hostN
> >
> > > b) Create /etc/fence_kdump_nodes file with list of hosts to
> > > send
> > > fence_kdump notification to.
> > > These hosts are also extracted from cluster configuration
> > > using
> > > 'pcs cluster' command
> > > c) If these two files are successfully created, kdump tries to
> > > configure network to be able
> > > to reach all hosts defined in /etc/fence_kdump_nodes
> >
> > Not exactly. We configure network accordingly if is_fence_kdump().
>
> But you run kdump_install_net function for each node
I was talking about "if these two files are successfully created ..."
>
> >
> > is_fence_kdump() checks if cluster and if cluster is configured fence
> > kdump in cluster cib.
>
> I modified this, is_fence_kdump() now checks:
>
> 1) if cluster and if cluster is configured fence kdump in cluster cib
> 2) or if manual configuration exists
I'm fine with this change. It makes sense in your case.
>
> >
> > > d) Install these two config files into kdump's kernel
> > > initramfs
> >
> > /etc/fence_kdump_nodes is mandatory while /etc/sysconfig/kdump_fence is
> > optional depending on if it exists.
>
> True
>
> >
> > >
> > >
> > > 2) Behavior with this patch
> > > - when running 'kdumpctl restart' kdump detect if
fence_kdump_send
> > > binary is installed
> > > and if so, it tries to:
> > >
> > > a) It tries to detect is cluster is configured ('pcs'
command
> > > is
> > > available). If so, it creates
> > > needed config files as described above in steps 1a) and 1b)
> >
> > Please don't create /etc/sysconfig/fence_kdump. If it doesn't in 1st,
> > there's no need to create one for the 2nd kernel. We only source it when
> > it exists in 2nd kernel.
>
> This file will be created manually (oVirt will most probably alter defaults
> of fence_kdump_send) and if it exists it will be installed into initramfs.
> This behavior exists before my patch
>
> >
> > > b) If cluster is not configured, it tries to detect if
> > > /etc/sysconfig/fence_kdump and
> > > /etc/sysconfig/fence_kdump_nodes exist. If so, fence_kdump
> > > is
> > > marked as successfully
> > > configured and kdump continues with steps 1c) and 1d)
> >
> > Is /etc/sysconfig/fence_kdump_nodes created by the user who want to use
> > fence_kdump facility? Even without being in a cluster environment? Does
> > oVirt work with fence_kdump_send?
>
> That's the reason why I wrote this patch. We want to support fence_kdump
> in oVirt, but we don't want to install and configure Pacemaker on oVirt
> hosts,
> so this patch tries to add 2nd scenario:
>
> 1) Host is part of Pacemaker cluster - use pcs command to get list of
> hosts
>
> 2) Host is not part of Pacemake cluster -
> /etc/sysconfig/fence_kdump_nodes
> will be created manually by user or automatically by oVirt
OK. I understand your case.
OK, so what else should I do to make the patch merged?
Thanks
Martin Perina
Thanks
WANG Chao
>
> >
> > Thanks
> > WANG Chao
> >
> > >
> > >
> > > Is it possible to integrate such patch into kexec-tools RPM?
> > >
> > > We would like to integrate fence_kdump support into oVirt 3.5 which
> > > should
> > > be released in May,
> > > so before this to happen, we need kexec-tools RPM with this patch to be
> > > available for RHEL 6 and
> > > Fedora 19/20.
> > >
> > > Thanks
> > >
> > > Martin Perina
> > > _______________________________________________
> > > kexec mailing list
> > > kexec(a)lists.fedoraproject.org
> > >
https://lists.fedoraproject.org/mailman/listinfo/kexec
> >