cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <Alex.Hu...@citrix.com>
Subject RE: [PROPOSAL] User VM HA using native XS HA capabilities
Date Thu, 28 Nov 2013 06:16:01 GMT
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.das@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.Huang@citrix.com<mailto:Alex.Huang@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.das@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.Vittal@citrix.com<mailto:Chiradeep.Vittal@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"
> <david@gnsa.us<mailto:david@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.das@citrix.com<mailto:koushik.das@citrix.com>>
> wrote:
> Thanks for the comments David. See inline.
> 
> -Koushik
> 
> On 22-Nov-2013, at 7:31 PM, David Nalley
> <david@gnsa.us<mailto:david@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
> 
> 


Mime
View raw message