The HA planning algorithms exist to generate a *guaranteed* failure plan which statically allocates pool resources, to move VMs in the event of a certain number of host failures. If overcommit protection is on, then these resources will definitely be present and can be depended since the tool-stack makes sure they are free. Any attempts to violate the plan will be blocked by the toolstack (just like VMWare’s admission control does).

Marathon offer an interesting alternative: rather than depending on static failure planning algorithms, they actually run two VMs and use that alternative VM in the event of failure. This makes the process have far fewer moving parts for single-host failure, but does require falling back to standard VM restart if both hosts fail simultaneously.

We’re aiming to give customers as much “flexibility vs simplicity” as possible, so that one of the deployment modes (admission control on/off, reserved VMs with Marathon) is appropriate for the threat model which is being protected against.

I stand by my initial statement that XenServer HA provides only “best effort” restart. Based on both of your comments, it appears that it’s possible to allocate resources in the cluster or resource pool that would otherwise be necessary to sustain a host failure. As I stated in the initial post, this is akin to disabling admission control for VMware HA, and it does introduce the possibility, as Michael stated, that protected VMs would not restart on another host due to lack of resources. This is what I call “best effort,” not “guaranteed restart.” I suppose if you ensured that you did not over-allocate the resource pool, then XenServer HA could be said to have “guaranteed restart,” but in that case VMware HA with admission control enabled could also be said to have “guaranteed restart.”

Or am I still missing something here?

Following last week’s XenServer HA announcement, we’ve been approached with questions like “How exactly does XenServer HA work?” and “How does XenServer HA and everRun VM work together.” Rather than respond ourselves we thought it would b…

When we (Marathon) state that we reserve resources and that XenServer HA does not, we mean that we actually reserve the resources on a specific host and have a complete VM ready to go if necessary, whereas XenServer HA will calculate across the pool what resources are available for VM restarts.

As Anil states, XenServer HA certainly does do failure planning, and our comments on the differences between XenServer HA and everRun VM are not at all intended to knock HA. From our understanding, and without trying to get into a technical discussion of the exact intricacies of how XenServer HA works (Anil is better suited for that task), XenServer HA will calculate how many hosts within a Xen pool can fail and still have their VM’s restart on other hosts. As additional VM’s are started, available resources within the pool are diminished resulting in a recalculation of the restart plan, which could reduce the number of hosts that could fail and successfully restart. If users aren’t careful, they could use up too many resources and ‘protected’ VM’s may not be able to restart, depending on how many hosts suffer a failure. With everRun VM, we know that we can restart upon a host failure since we have a fully configured VM on another host. If a new VM is started it doesn’t change whether or not we are still protected as we’ve already allocated those resources on the secondary host.

Anil said it right in his last comment, XenServer HA attempts to restart as well as possible, which for many applications/environments is perfectly sufficient. For those applications/environments that warrant more protection, everRun provides the next levels of availability. XenServer HA and everRun are extremely complimentary and allow customers to choose the right level of protection for a broader set of their applications.

I’ve posted some more details of how XenServer HA works on my blog at: http://community.citrix.com/x/O4KZAg

We aim to do VM restart as well as possible in XenServer, and if you need even more safety, then everRun is the next step forward — I/O fault tolerance and eventually VM mirroring as you note. It’s all great technology, I love it!