Hi Martins, yes this is a typical example of host self fencing, where a host will reboot when losing connectivity to a primary storage pool. As you have already found this is controlled by the xenheartbeat.sh script.
Dag Sonstebo Cloud Architect ShapeBlue On 30/03/2016, 10:04, "Mārtiņš Jakubovičs" <martins-li...@hostnet.lv> wrote: >Looks like I found issue, it is /opt/cloud/bin/xenheartbeat.sh script >which is running in all hosts. > >On 2016.03.30. 11:14, Mārtiņš Jakubovičs wrote: >> Hello, >> >> This morning I faced unexpected problem, one of XenServer hosts >> rebooted. I checked logs and it looks like due network issue, but >> question is why host rebooted it self? CloudStack's XS Pool is not HA >> enabled. And as I know, in ACS 4.3.2 CloudStack did not manage Host's >> HA or am I wrong? >> >> Mar 30 07:00:33 cloudstack-1 heartbeat: Potential problem with >> /var/run/sr-mount/858d490c-38e8-0f44-2840-c6acb98c3ae9/hb-b81b5d17-dea8-4257-a9b5-30b52229cc68: >> >> not reachable since 65 seconds >> Mar 30 07:00:33 cloudstack-1 heartbeat: Problem with >> /var/run/sr-mount/858d490c-38e8-0f44-2840-c6acb98c3ae9/hb-b81b5d17-dea8-4257-a9b5-30b52229cc68: >> >> not reachable for 65 seconds, rebooting system! >> >> [root@cloudstack-1 ~]# xe pool-list params=all | grep ha- >> ha-enabled ( RO): false >> ha-configuration ( RO): >> ha-statefiles ( RO): >> ha-host-failures-to-tolerate ( RW): 0 >> ha-plan-exists-for ( RO): 0 >> ha-allow-overcommit ( RW): false >> ha-overcommitted ( RO): false >> >> So did ACS manage some kind of host's HA? >> >> XenServer 6.2 >> ACS 4.3.2 >> >> Best regards, >> Martins >> > Regards, Dag Sonstebo dag.sonst...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue
