RE: [PROPOSAL] User VM HA using native XS HA capabilities
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: > 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 > 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: 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 > 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" > 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 > mailto:koushik@citrix.com>> > wrote: > Thanks for the comments David. See inline. > > -Koushik > > On 22-Nov-2013, at 7:31 PM, David Nalley > 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 >
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 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: 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 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" 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 mailto:koushik@citrix.com>> wrote: Thanks for the comments David. See inline. -Koushik On 22-Nov-2013, at 7:31 PM, David Nalley 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
RE: [PROPOSAL] User VM HA using native XS HA capabilities
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: > 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 > 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" 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 > >> wrote: > >>> Thanks for the comments David. See inline. > >>> > >>> -Koushik > >>> > >>> On 22-Nov-2013, at 7:31 PM, David Nalley 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
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 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" 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 >> wrote: >>> Thanks for the comments David. See inline. >>> >>> -Koushik >>> >>> On 22-Nov-2013, at 7:31 PM, David Nalley 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
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" 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 >wrote: >> Thanks for the comments David. See inline. >> >> -Koushik >> >> On 22-Nov-2013, at 7:31 PM, David Nalley 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
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 wrote: > Thanks for the comments David. See inline. > > -Koushik > > On 22-Nov-2013, at 7:31 PM, David Nalley 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
Thanks for the comments David. See inline. -Koushik On 22-Nov-2013, at 7:31 PM, David Nalley 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 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 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
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 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 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
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 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 > >
[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