On Fri, Feb 24, 2012 at 10:57 AM, Andrew Beekhof wrote:
> On Thu, Feb 16, 2012 at 11:46 PM, Shyam wrote:
>> Hi Andrew,
>>
>> Looks like my previous mail with attachment was blocked. I uploaded it
>> here https://www.transferbigfiles.com/05015ea8-455c-4512-80d2-ea304e8ca54d?rid=eA79aEL2N8jG2QN6oMG
On Thu, Feb 16, 2012 at 11:46 PM, Shyam wrote:
> Hi Andrew,
>
> Looks like my previous mail with attachment was blocked. I uploaded it
> here https://www.transferbigfiles.com/05015ea8-455c-4512-80d2-ea304e8ca54d?rid=eA79aEL2N8jG2QN6oMG6dA2 (halogs.tgz).
Love the site name, alas the file was unrea
Hi Andrew,
Looks like my previous mail with attachment was blocked. I uploaded it here
https://www.transferbigfiles.com/05015ea8-455c-4512-80d2-ea304e8ca54d?rid=eA79aEL2N8jG2QN6oMG6dA2
(halogs.tgz).
Pls see if you can download from here or else let me know what is the best
way to you the logs.
--
On Thu, Feb 16, 2012 at 10:59 PM, Shyam wrote:
> Hi Andrew,
>
> Did you get a chance to look at the below logs? Anything that needs to be
> setup differently in the config?
Yes, and I replied:
I'm hoping you still have those logs.
I need the lines /before/ this one:
Feb 3 07:02:49 vsa-004
On Fri, Feb 3, 2012 at 9:31 AM, Andrew Beekhof wrote:
> On Thu, Feb 2, 2012 at 9:55 PM, Shyam wrote:
>> Hi Andrew,
>>
>> Here is more logs covering a larger period that shows multiple of this
>> election cycle. Please note that in the below case I had set dc-deadtime to
>> 5secs & the I_DC_TIMEOU
On Thu, Feb 2, 2012 at 9:55 PM, Shyam wrote:
> Hi Andrew,
>
> Here is more logs covering a larger period that shows multiple of this
> election cycle. Please note that in the below case I had set dc-deadtime to
> 5secs & the I_DC_TIMEOUT pops up every 5 secs. I turned this dc-deadtime to
> 10secs
Hi Andreas,
Yes this is only for testing. The specific test was not two VM's running on
same host. We have two physical servers each running a VM & the VM's run
pacemaker/heartbeat. We reboot both physical servers (to simulate a
power-fail) & after that watch both VM's do negotiation.
--Shyam
On
Hi Andrew,
Here is more logs covering a larger period that shows multiple of this
election cycle. Please note that in the below case I had set dc-deadtime to
5secs & the I_DC_TIMEOUT pops up every 5 secs. I turned this dc-deadtime to
10secs & the long election cycle problem disappeared. It no long
On 02/02/2012 04:45 AM, Shyam wrote:
> Hi Andreas,
>
> Thanks for your reply.
>
> We are using pacemaker in VM environment & was primarily checking how it
> behaves when two nodes hosting the clustered VM's reboot. It apparently
> took a very long time doing the elections.
Ok, but this is only f
They both think they should be the DC.
But the log fragments dont extend back far enough to say why.
On Fri, Jan 27, 2012 at 10:21 PM, Shyam wrote:
> Folks,
>
> We are constantly running into a long election cycle where in a 2-node
> cluster when both of them are simultaneously rebooted, they tak
Hi Andreas,
Thanks for your reply.
We are using pacemaker in VM environment & was primarily checking how it
behaves when two nodes hosting the clustered VM's reboot. It apparently
took a very long time doing the elections.
I realized that we were using dc-deadtime at 5sec. After bumping this up
On 01/27/2012 12:21 PM, Shyam wrote:
> Folks,
>
> We are constantly running into a long election cycle where in a 2-node
> cluster when both of them are simultaneously rebooted, they take a long
> time running through election loop.
why do you want to reboot them simultaneously? ... stop them one
Folks,
We are constantly running into a long election cycle where in a 2-node
cluster when both of them are simultaneously rebooted, they take a long
time running through election loop.
On one node pacemaker loops like:
Jan 26 22:03:20 vsa-009c-vc-1 crmd: [1134]: info: do_dc_takeover:
Taking
13 matches
Mail list logo
