Koushik, How do you propose for XS HA to work with CloudStack's host affinity use cases? I don't see anything in the spec regarding this. I generally don't think VM HA can be done with hypervisor HA because of this.
--Alex > -----Original Message----- > From: Koushik Das [mailto:koushik....@citrix.com] > Sent: Tuesday, November 26, 2013 10:51 PM > To: <dev@cloudstack.apache.org> > Subject: Re: [PROPOSAL] User VM HA using native XS HA capabilities > > I haven't tried in XS 6.1 but in 6.2 if a VM is marked as HA enabled (based on > ha-restart-priority) in a HA enabled cluster then if the VM is not stopped > using xapi then it is automatically re-started. > > I tried the following on XS 6.2 and it worked as expected: > - Logged on to a guest VM marked as HA enabled > - Ran "shutdown -h now" > - After sometime the VM got restarted > > -Koushik > > > On 27-Nov-2013, at 2:11 AM, Chiradeep Vittal <chiradeep.vit...@citrix.com> > wrote: > > > According to > > http://support.citrix.com/proddocs/topic/xencenter-61/xs-xc-pools-ha- > about. > > html > > > > > > XS HA is about dealing with host failures. > > However CS HA also deals with individual VM failures ("fast restart"). > > I hope you are not removing fast VM restart. > > > > On 11/26/13 6:54 AM, "David Nalley" <da...@gnsa.us> wrote: > > > >> Hi Koushik: > >> > >> Thanks for the reply - a few followup comments inline. I look forward > >> to seeing this work. > >> > >> Other folks: please read the entire thread and the links from > >> Koushik; there's a planned deprecation here. > >> > >> --David > >> > >> On Mon, Nov 25, 2013 at 2:38 AM, Koushik Das <koushik....@citrix.com> > >> wrote: > >>> Thanks for the comments David. See inline. > >>> > >>> -Koushik > >>> > >>> On 22-Nov-2013, at 7:31 PM, David Nalley <da...@gnsa.us> wrote: > >>> > >>>> Hi Koushik: > >>>> > >>>> In general I like the idea. A couple of comments: > >>>> > >>>> The upgrade section has a manual step for enabling HA manually per > >>>> instance. Why a manual step? Why is CloudStack not checking the > >>>> desired state (e.g. if HA is enabled in the instance service group) > >>>> with the actual state (what is reflected on the hypervisor) and > >>>> changing it when appropriate. > >>>> > >>>> We are already going to need to reconcile the state (things like > >>>> host the instance is running on will change for instance) with > >>>> reality already - so it seems like making this an automatic step > >>>> wouldn't be much extra effort and would scale far easier. > >>> > >>> [Koushik] Are you suggesting that as part of the upgrade process, > >>> all impacted VMs should be automatically updated? If so, yes it can be > done. > >>> For now I am keeping it manual, in future the process can be automated. > >>> > >> > >> Why keeping it manual now? Actually let me rephrase - I can > >> understand why someone might not want things changed automagically > >> (as an admin I'd want nothing changed by default, but changed if I > >> cared about it in some automated fashion) Is there a reason we would > >> not include some functionality to let the operator automatically > >> change this on some subset or all of the machines in an automated > fashion? > >> > >>>> > >>>> Are there plans on deprecating the custom HA solution, or will it > >>>> be supported forever? If the plan is to deprecate, lets go ahead > >>>> and start planning that/announcing/etc and not let it fall into > >>>> disrepair. > >>> > >>> [Koushik] That's the plan going forward. For the next release both > >>> options will be there. Maybe post that the custom HA solution can be > >>> removed for XS 6.2 and above. > >>> > >>>> > >> > >> Please make sure that the deprecation is explicitly called out. E.g > >> will be present but deprecated in 4.4 and removed in 4.5; and let's > >> make sure a doc bug gets filed when this is ready for merge. > >> > >> --David > >
