That's always been true of VmWare but is not true of XS and KVM. Losing it would mean it's a regression for those hypervisors.
--Alex > -----Original Message----- > From: Koushik Das [mailto:koushik....@citrix.com] > Sent: Wednesday, November 27, 2013 10:12 PM > To: <dev@cloudstack.apache.org> > Subject: Re: [PROPOSAL] User VM HA using native XS HA capabilities > > I looked at the affinity group FS [1]. Based on what I understand with host > affinity even CS HA won't work if the specific host fails. For cluster/pod > affinity it will work though. Can someone confirm if this is the case? > > For native XS HA since cluster is where HA gets configured, affinity groups > can be realised at cluster level. For host affinity to work if the implicit > assumption is to not make the VM HA enabled then there shouldn't be any > issues. But there may be scenarios which won't be possible with native HA. > > Also in the FAQ section of [1] I see the following: > "DRS? > > * This is applicable only for placement operations through CloudStack. > This > implementation is to only support scenarios where the HV does not do HA or > DRS." > > This means that with Vmware (where there is native HA), affinity groups > doesn't work. > > -Koushik > > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+- > +Affinity-Anti-affinity+groups > > On 28-Nov-2013, at 3:29 AM, Alex Huang > <alex.hu...@citrix.com<mailto:alex.hu...@citrix.com>> wrote: > > 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<http://citrix.com>] > Sent: Tuesday, November 26, 2013 10:51 PM > To: <dev@cloudstack.apache.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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 > >
