Search results

The mechanism that it uses to solve that problem is generic in that it can work with any shared storage backend (DRBD, NFS, Ceph, Gluster, iSCSI, etc)? Does it intercept I/O requests to the shared storage or how does it work?

[/COLOR]The concern I have is if the rogue node were to "recover" from the failed state and then start writing bad data to the shared storage (e.g DRBD, ceph, NFS, etc) at the same time as the new node that took over its VMs. If this were to occur, wouldn't it result in two nodes writing data to...

Would the hardware watchdog work in conjunction with shared storage fencing, e.g how Pacemaker uses sbd? In any of these cases, how do the other nodes know for certain that the rogue node has been killed? Do they simply wait for the watchdog timer period and then after that assume that the node...

Still, isn't there a state where the watchdog timer could be rendered inoperable, and thus the rogue node would continue running? I would be happy to help beta test out a fall-back hardware STONITH device - please let me know when this feature is available!

This is exciting news - I am intrigued to test out LXC support and simplified HA. On the topic of HA, I see that the software-based fencing (watchdog) is recommended. How does this address the concern of a node being disconnected from the network and going rogue (e.g if the watchdog daemon dies...