I guess this would have to be tested on other hypervisors as well. Unfortunately I get a lot of XS answers, and very few others.
Thanks for the tip Clayton I'll add this to the wiki section once it's up. Sent from my iPhone On Feb 28, 2013, at 9:27 AM, Clayton Weise <cwe...@iswest.net> wrote: >> I would imagine it's best to leverage on the underlying hypervisors' HA >> mechanisms, configured oud-of-band of cloudstack. I find cloudstacks >> implementation a little laggy compared to the paid for variety. CloudStack >> does a well enough job to figure out which host the vm eventually lands on. > > I haven't had a chance to test it myself to any large degree but from some > conversations I have had with CloudPlatform support (the paid product), we > had an incident that ran us into a very similar situation. Due to a bug in > XenServer 6.0.0 we went through the upgrade process to 6.0.2 and during that > process some of the VMs got moved to other hosts and we lost track of things. > To my delight, CloudStack picked up on this and updated itself as to the > host where the VM was now residing. > > What this means to me is that if some _other_ mechanism outside of CS were to > move VMs around within a cluster (for example, due to a host failure) CS > would eventually query XAPI and find out where the VM resides and update the > CS database. Now, like I said, I haven't tested this but in theory this > means that if you enabled HA on your hypervisor directly and instructed CS to > not do HA, if there was a host failure your hypervisor would take over the HA > process and CS would eventually update itself to recognize the re-arranging > of VMs in the cluster... in theory.
