TOPIC:

Frankly I'm not able to reproduce the issue on my 7 pool. I've used a 6.5 ha lizard version patched to be used on XenServer 7 and it did perfectly the job

Hi Davide,
The specific issue occurs when a master has crashed and the slave has been promoted to the new pool master. When the original master is reintroduced into the pool, it should demote itself to slave. This is not happening in our testing. The old master is failing to detect that the former slave has been promoted which results in a broken pool.

Hi any news about the issue? i saw you guys planed on your own workaround external from Xenserver, any progress?

We tested our workaround last week and it is not working reliably. It looks like we may have an official fix from Citrix soon. In the meantime, you can add a 10 second sleep at the beginning of the start function in /etc/init.d/xapi

right after the line "start() {"

add this line
"sleep 10"

will that "fix" the last issue?

Is this an bad error?
chmod: cannot access ‘/etc/ha-lizard/fence//RIBCL/*.sh’: No such file or directory
chmod: cannot access ‘/etc/ha-lizard/fence//RIBCL/*.tcl’: No such file or directory

The sleep is not a reliable fix. It may help in testing though. The network issues we have encountered with xenserver 7 affect only certain network environments. In our testing, low end non-intelligent Ethernet switches work well and the bug is not present. Using intelligent switches (which take more time to bring an interface up) have been the cause of the network issue.

Regarding the RIBCL errors. These are harmless. There was some work being done on a new fence method which is not in the release, yet the installer as trying to set permissions on it. We have a 2.1 release coming this week which addresses this and adds a lot of new functionality.