You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Koushik Das <ko...@citrix.com> on 2013/11/21 05:29:58 UTC
[PROPOSAL] User VM HA using native XS HA capabilities
Cloudstack relies on custom HA logic for user VMs running on Xenserver. The reason for doing it like this may be due the fact that native HA capabilities in XS was not mature enough during the initial days. Also in the custom HA logic, Cloudstack has to correctly determine the state of a VM from the hypervisor before it can take any action. In case there are any issues in determining the state, HA mechanism can get impacted. Since the hypervisor best knows the state of the VM it is a better approach to rely on native HA capabilities.
The idea is to rely on native HA capabilities for user VMs from XS 6.2 onwards. HA for system VMs would still be based on application logic. For sake of backward compatibility the earlier option will be there as well and there will be a choice to use any one option.
The additional requirement for this is to pre-configure native HA on a Xenserver cluster before deploying any user VMs as documented here [1].
I have created a ticket in Jira [2]. I will post the FS for this shortly.
Thanks,
Koushik
[1] http://support.citrix.com/servlet/KbServlet/download/34969-102-704897/reference.pdf (refer section 3.8)
[2] https://issues.apache.org/jira/browse/CLOUDSTACK-5203
RE: [PROPOSAL] User VM HA using native XS HA capabilities
Posted by Alex Huang <Al...@citrix.com>.
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: <de...@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
> <Al...@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: <de...@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
> <Ch...@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
> <ko...@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
>
>
Re: [PROPOSAL] User VM HA using native XS HA capabilities
Posted by Koushik Das <ko...@citrix.com>.
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 <Al...@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: <de...@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 <Ch...@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 <ko...@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
RE: [PROPOSAL] User VM HA using native XS HA capabilities
Posted by Alex Huang <Al...@citrix.com>.
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]
> Sent: Tuesday, November 26, 2013 10:51 PM
> To: <de...@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 <Ch...@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 <ko...@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
> >
Re: [PROPOSAL] User VM HA using native XS HA capabilities
Posted by Koushik Das <ko...@citrix.com>.
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 <Ch...@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 <ko...@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
>
Re: [PROPOSAL] User VM HA using native XS HA capabilities
Posted by Chiradeep Vittal <Ch...@citrix.com>.
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 <ko...@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
Re: [PROPOSAL] User VM HA using native XS HA capabilities
Posted by David Nalley <da...@gnsa.us>.
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 <ko...@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
Re: [PROPOSAL] User VM HA using native XS HA capabilities
Posted by Koushik Das <ko...@citrix.com>.
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.
>
> 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.
>
> --David
>
> On Fri, Nov 22, 2013 at 7:27 AM, Koushik Das <ko...@citrix.com> wrote:
>> Initial draft of the FS https://cwiki.apache.org/confluence/display/CLOUDSTACK/User+VM+HA+using+native+XS+HA+capabilities
>>
>> -Koushik
>>
>> On 21-Nov-2013, at 9:59 AM, Koushik Das <ko...@citrix.com> wrote:
>>
>>> Cloudstack relies on custom HA logic for user VMs running on Xenserver. The reason for doing it like this may be due the fact that native HA capabilities in XS was not mature enough during the initial days. Also in the custom HA logic, Cloudstack has to correctly determine the state of a VM from the hypervisor before it can take any action. In case there are any issues in determining the state, HA mechanism can get impacted. Since the hypervisor best knows the state of the VM it is a better approach to rely on native HA capabilities.
>>>
>>> The idea is to rely on native HA capabilities for user VMs from XS 6.2 onwards. HA for system VMs would still be based on application logic. For sake of backward compatibility the earlier option will be there as well and there will be a choice to use any one option.
>>>
>>> The additional requirement for this is to pre-configure native HA on a Xenserver cluster before deploying any user VMs as documented here [1].
>>>
>>> I have created a ticket in Jira [2]. I will post the FS for this shortly.
>>>
>>> Thanks,
>>> Koushik
>>>
>>> [1] http://support.citrix.com/servlet/KbServlet/download/34969-102-704897/reference.pdf (refer section 3.8)
>>> [2] https://issues.apache.org/jira/browse/CLOUDSTACK-5203
>>>
>>>
>>
Re: [PROPOSAL] User VM HA using native XS HA capabilities
Posted by David Nalley <da...@gnsa.us>.
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.
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.
--David
On Fri, Nov 22, 2013 at 7:27 AM, Koushik Das <ko...@citrix.com> wrote:
> Initial draft of the FS https://cwiki.apache.org/confluence/display/CLOUDSTACK/User+VM+HA+using+native+XS+HA+capabilities
>
> -Koushik
>
> On 21-Nov-2013, at 9:59 AM, Koushik Das <ko...@citrix.com> wrote:
>
>> Cloudstack relies on custom HA logic for user VMs running on Xenserver. The reason for doing it like this may be due the fact that native HA capabilities in XS was not mature enough during the initial days. Also in the custom HA logic, Cloudstack has to correctly determine the state of a VM from the hypervisor before it can take any action. In case there are any issues in determining the state, HA mechanism can get impacted. Since the hypervisor best knows the state of the VM it is a better approach to rely on native HA capabilities.
>>
>> The idea is to rely on native HA capabilities for user VMs from XS 6.2 onwards. HA for system VMs would still be based on application logic. For sake of backward compatibility the earlier option will be there as well and there will be a choice to use any one option.
>>
>> The additional requirement for this is to pre-configure native HA on a Xenserver cluster before deploying any user VMs as documented here [1].
>>
>> I have created a ticket in Jira [2]. I will post the FS for this shortly.
>>
>> Thanks,
>> Koushik
>>
>> [1] http://support.citrix.com/servlet/KbServlet/download/34969-102-704897/reference.pdf (refer section 3.8)
>> [2] https://issues.apache.org/jira/browse/CLOUDSTACK-5203
>>
>>
>
Re: [PROPOSAL] User VM HA using native XS HA capabilities
Posted by Koushik Das <ko...@citrix.com>.
Initial draft of the FS https://cwiki.apache.org/confluence/display/CLOUDSTACK/User+VM+HA+using+native+XS+HA+capabilities
-Koushik
On 21-Nov-2013, at 9:59 AM, Koushik Das <ko...@citrix.com> wrote:
> Cloudstack relies on custom HA logic for user VMs running on Xenserver. The reason for doing it like this may be due the fact that native HA capabilities in XS was not mature enough during the initial days. Also in the custom HA logic, Cloudstack has to correctly determine the state of a VM from the hypervisor before it can take any action. In case there are any issues in determining the state, HA mechanism can get impacted. Since the hypervisor best knows the state of the VM it is a better approach to rely on native HA capabilities.
>
> The idea is to rely on native HA capabilities for user VMs from XS 6.2 onwards. HA for system VMs would still be based on application logic. For sake of backward compatibility the earlier option will be there as well and there will be a choice to use any one option.
>
> The additional requirement for this is to pre-configure native HA on a Xenserver cluster before deploying any user VMs as documented here [1].
>
> I have created a ticket in Jira [2]. I will post the FS for this shortly.
>
> Thanks,
> Koushik
>
> [1] http://support.citrix.com/servlet/KbServlet/download/34969-102-704897/reference.pdf (refer section 3.8)
> [2] https://issues.apache.org/jira/browse/CLOUDSTACK-5203
>
>