High Availability & HA Lizard


Featured Image from the Google Image archives…

After persuading you I am not riding on the coattails of a GENIUS for self promotion, I now have to direct all XenServer Administrators to another fine piece of work by none other than Tobias Kreidl.  Or this Tobias Kreidl, but they are one in the same.

No longer being with Citrix doesn’t mean I’ve dropped my favourite type-1 hypervisor of choice to quickly roll out my computing needs, so in my new life as my own XenServer Administrator, I can’t do anything else but share this grand slam of a write-up regarding none other than… High Availability.  Yup, I said it.

Without spoiling too much, his long standing research into HA Lizard is well documented along with the typical pain points of the Tennable-based “HA” code, limitations, and various mathematical outcomes that can, sans running HA Lizard, lead to anything from incorrect host fencing all the way to increasing a XenServer pool’s host count to smooht out the nuanced behaviors when one runs less than three XenServer hosts in a pool with High Availability activated.


Another shining example of a community member going out of their own way to help all of us Xenophiles with success in our own deployments and it can be read here:


I need to dig up the screen scrape, but as a final note I find it fascinating how time sharing, Burroughs mainframes, and their MCP OS had this built into job execution with multi-processor process control: ensuring a single job would fence as to avoid other data terminal operators from losing their compute cycles:

Procedures can be invoked in four ways – normal, call, process, and run.

The normal invocation invokes a procedure in the normal way any language invokes a routine, by suspending the calling routine until the invoked procedure returns.

The call mechanism invokes a procedure as a coroutine. Coroutines have partner tasks, where control is explicitly passed between the tasks by means of a CONTINUE instruction. These are synchronous processes.

The process mechanism invokes a procedure as an asynchronous task and in this case a separate stack is set up starting at the lexical level of the processed procedure. As an asynchronous task, there is no control over exactly when control will be passed between the tasks, unlike coroutines. Note also that the processed procedure still has access to the enclosing environment and this is a very efficient IPC (Inter Process Communication) mechanism. Since two or more tasks now have access to common variables, the tasks must be synchronized to prevent race conditions, which is handled by the EVENT data type, where processes can WAIT on an event until they are caused by another cooperating process. EVENTs also allow for mutual exclusion synchronization through the PROCURE and LIBERATE functions. If for any reason the child task dies, the calling task can continue – however, if the parent process dies, then all child processes are automatically terminated. On a machine with more than one processor, the processes may run simultaneously. This EVENT mechanism is a basic enabler for multiprocessing in addition to multitasking.


I love computing.

— JK Benedict | @xenfomation


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s