TOPIC:

Salvatore Costantino wrote: Adam
We won't have a test environment to test against till next week . In the meantime, you can try preventing all services from starting at boot time. If the reboots persist, then the issue is likely outside of halizard.

Try 'chkconfig <service name> off' for the following services

ha-lizard
ha-lizard-watchdog
iscsi-ha
iscsi-ha-watchdog

Hi,

I will test this tomorrow.

regards,

Adam

Adam Ward wrote:

Salvatore Costantino wrote: Adam
We won't have a test environment to test against till next week . In the meantime, you can try preventing all services from starting at boot time. If the reboots persist, then the issue is likely outside of halizard.

Try 'chkconfig <service name> off' for the following services

ha-lizard
ha-lizard-watchdog
iscsi-ha
iscsi-ha-watchdog

Hi,

I will test this tomorrow.

regards,

Adam

Hi,

If I stop the services as you suggested above, the server does not go into a reboot loop, so it looks like HA-Lizard is causing this.

Any logs I can get for you to prove this? I need to rebuild these servers fairly soon.

Regards,

Adam

I don't think logs will help. Here is the underlying logic for a slave as it relates to self fencing..

When a slave self-fences it should reboot just once. Just before doing that it will write a file to disk which prevents it from rebooting repeatedly.

If the server comes back online AND the server cannot reach the heauristic IP address, then it will self fence again if the file is missing. Before self fencing (the first time) a slave will sync its disk writes (flush any pending cached disk writes to the physical disks).. It is possible (plausible) that a lower level cache (like a raid controller) could still cache some data which prevents the file from actually being written to disk. We've seen this scenario once before with another user. I'll take a look at tightening up the logic for a slave self fencing so that it does not necessarily need to reboot at all.

Salvatore Costantino wrote: I don't think logs will help. Here is the underlying logic for a slave as it relates to self fencing..

When a slave self-fences it should reboot just once. Just before doing that it will write a file to disk which prevents it from rebooting repeatedly.

If the server comes back online AND the server cannot reach the heauristic IP address, then it will self fence again if the file is missing. Before self fencing (the first time) a slave will sync its disk writes (flush any pending cached disk writes to the physical disks).. It is possible (plausible) that a lower level cache (like a raid controller) could still cache some data which prevents the file from actually being written to disk. We've seen this scenario once before with another user. I'll take a look at tightening up the logic for a slave self fencing so that it does not necessarily need to reboot at all.

Hi,

Any updates on this? I am really interested in getting this working in XenServer 7.1 as we can live patch Xen 7.1 (so fewer reboots) and I plan on staying at XenServer 7.1 for 4 to 5 years.

Regards,

Adam

We've designed a change in the way a slave self fences. It will be implemented in ~ 2 weeks. That should address the reboot issue.

Salvatore,

Is Xenserver 7.1 now fully supported or is HA-Lizard still in the testing phase. We have updated our hosts to 7.1 and then found your product and we would like to start using HA-Lizard.

Thanks

Mike