date:20150916

Re: [DISCUSS][PROPOSAL]missing power state reports from hypervisors on VMs ([BLOCKER]?)

2015-09-16 Thread Anshul Gangwar

Currently we report only PowerOn VMs and do not report PowerOff VMs that's why 
we consider Missing and PowerOff as same And that's how most of the code is 
written for VM sync and each Hypervisor resource has same understanding. This 
will effect HA and many more unknown places. So please do not even consider to 
merge this change.

So Now coming to bug we can fix that by changing global setting pingInterval to 
appropriate value according to hypervisor settings which takes care of these 
transitional period of missing report here or can be handled by introducing 
gracePeriod global setting.

Regards,
Anshul

On 16-Sep-2015, at 1:11 PM, Rohit Yadav 
> wrote:

On 16-Sep-2015, at 1:06 pm, Daan Hoogland 
> wrote:

so two questions:
- is this a blocker?

A missing state handler is definitely a corner case, and IMO a blocker (so, for 
both 4.6.0 and future 4.5.3).

- is the ignoring after logging the appropriate way to handle this?

It may be undesirable for all cases; so either introducing another global 
setting to control logic (just log, vs update state in the db vs do any 
operation?); or simply find out if the VM is actually running (or any other 
state) just mark it as running in the DB.

Regards,
Rohit Yadav
Software Architect, ShapeBlue

M. +91 88 262 30892 | 
rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab

Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Software 
Engineering
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
registered by The Republic of South Africa and is traded under license from 
Shape Blue Ltd. ShapeBlue is a registered trademark.

[DISCUSS][PROPOSAL]missing power state reports from hypervisors on VMs ([BLOCKER]?)

2015-09-16 Thread Daan Hoogland

Ladies and gentlemen,

A ticket was entered by Rene Moser [1] on the way ACS handles missing power
state reports. His issue is that VMs ma at times be regarded as off while
they are registered as running and actually running as well. The missing
report has to be handled in some way so right now it is handled as if the
VM is down. I made a PR [2] that does minimal handling by only logging the
fact. This seems an improvement but I have no idea if it is and how to test
it.

so two questions:
- is this a blocker?
- is the ignoring after logging the appropriate way to handle this?

I would be very pleased with all and any of your opinions.

regards,

[1] https://issues.apache.org/jira/browse/CLOUDSTACK-8848
[2] https://github.com/apache/cloudstack/pull/829

-- 
Daan

Re: [DISCUSS][PROPOSAL]missing power state reports from hypervisors on VMs ([BLOCKER]?)

2015-09-16 Thread Daan Hoogland

On Wed, Sep 16, 2015 at 10:17 AM, Anshul Gangwar 
wrote:

> Currently we report only PowerOn VMs and do not report PowerOff VMs that's
> why we consider Missing and PowerOff as same

This is not the behavior reported in the ticket. It is intermittend.


> And that's how most of the code is written for VM sync and each Hypervisor
> resource has same understanding. This will effect HA and many more unknown
> places. So please do not even consider to merge this change.
>
sure, I will hold. We do need to not regard a missing report the same as
power off however.



> So Now coming to bug we can fix that by changing global setting
> pingInterval to appropriate value according to hypervisor settings which
> takes care of these transitional period of missing report here or can be
> handled by introducing gracePeriod global setting.
>
I can see what you are talking about but not what you are saying here. Do
you mean that we need to keep track of ping interval and grace period in
the statemachine for a particular VM?



>
> Regards,
> Anshul
>
> On 16-Sep-2015, at 1:11 PM, Rohit Yadav > wrote:
>
>
> On 16-Sep-2015, at 1:06 pm, Daan Hoogland > wrote:
>
>
> so two questions:
> - is this a blocker?
>
> A missing state handler is definitely a corner case, and IMO a blocker
> (so, for both 4.6.0 and future 4.5.3).
>
> - is the ignoring after logging the appropriate way to handle this?
>
> It may be undesirable for all cases; so either introducing another global
> setting to control logic (just log, vs update state in the db vs do any
> operation?); or simply find out if the VM is actually running (or any other
> state) just mark it as running in the DB.
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
>
>
>
>
> M. +91 88 262 30892 | rohit.ya...@shapeblue.com rohit.ya...@shapeblue.com>
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Software Engineering<
> http://shapeblue.com/cloudstack-software-engineering/>
> CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<
> http://shapeblue.com/cloudstack-training/>
>
> This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Shape Blue Ltd or related companies. If you are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error. Shape Blue Ltd is a
> company incorporated in England & Wales. ShapeBlue Services India LLP is a
> company incorporated in India and is operated under license from Shape Blue
> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil
> and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is
> a company registered by The Republic of South Africa and is traded under
> license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>
>


-- 
Daan

Re: After box restart CS 4.5.2 fails to start

2015-09-16 Thread Rohit Yadav

Did you try running cloudstack-setup-management as root user ?
On 15-Sep-2015, at 8:24 pm, Keerthiraja SJ 
> wrote:

Hi All,

Today I installed CS 4.5.2 on CentOS 6.7 and able to start the app
successfully.

All of a sudden the box reboot then while I started the cloudsatck it fails
to start where I could see a different issue and ERROR on catalina.out

ERROR
==
INFO  [c.c.s.ConfigurationServerImpl] (main:null) Processing
updateSSLKeyStore
INFO  [c.c.s.ConfigurationServerImpl] (main:null) SSL keystore located at
/etc/cloudstack/management/cloudmanagementserver.keystore
WARN  [c.c.s.ConfigurationServerImpl] (main:null) Would use fail-safe
keystore to continue.
java.io.IOException: Fail to create keystore file!
   at
com.cloud.server.ConfigurationServerImpl.updateSSLKeystore(ConfigurationServerImpl.java:664)
   at
com.cloud.server.ConfigurationServerImpl.persistDefaultValues(ConfigurationServerImpl.java:304)
   at
com.cloud.server.ConfigurationServerImpl.configure(ConfigurationServerImpl.java:166)
   at
org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle$3.with(CloudStackExtendedLifeCycle.java:114)
   at
org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.with(CloudStackExtendedLifeCycle.java:153)
   at
org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.configure(CloudStackExtendedLifeCycle.java:110)
   at
org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:56)
   at
org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:167)
   at
org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51)
   at
org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:339)
   at
org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:143)
   at
org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:108)
   at
org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:945)
   at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:482)
   at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContext(DefaultModuleDefinitionSet.java:145)
   at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet$2.with(DefaultModuleDefinitionSet.java:122)
   at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:245)
   at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250)
   at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250)
   at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:233)
   at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContexts(DefaultModuleDefinitionSet.java:117)
   at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.load(DefaultModuleDefinitionSet.java:79)
   at
org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory.loadModules(ModuleBasedContextFactory.java:37)
   at
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:70)
   at
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.(CloudStackSpringContext.java:57)
   at
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.(CloudStackSpringContext.java:61)
   at
org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener.contextInitialized(CloudStackContextLoaderListener.java:52)
   at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4210)
   at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4709)
   at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
   at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
   at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
   at
org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041)
   at
org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964)
   at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502)
   at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277)
   at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321)
   at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142)
   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
   at

Re: [DISCUSS][PROPOSAL]missing power state reports from hypervisors on VMs ([BLOCKER]?)

2015-09-16 Thread Rohit Yadav


On 16-Sep-2015, at 1:06 pm, Daan Hoogland 
> wrote:


so two questions:
- is this a blocker?

A missing state handler is definitely a corner case, and IMO a blocker (so, for 
both 4.6.0 and future 4.5.3).

- is the ignoring after logging the appropriate way to handle this?

It may be undesirable for all cases; so either introducing another global 
setting to control logic (just log, vs update state in the db vs do any 
operation?); or simply find out if the VM is actually running (or any other 
state) just mark it as running in the DB.

Regards,
Rohit Yadav
Software Architect, ShapeBlue


[cid:9DD97B41-04C5-45F0-92A7-951F3E962F7A]


M. +91 88 262 30892 | 
rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab




Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build
CSForge - rapid IaaS deployment framework
CloudStack Consulting
CloudStack Software 
Engineering
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
registered by The Republic of South Africa and is traded under license from 
Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: [DISCUSS][PROPOSAL]missing power state reports from hypervisors on VMs ([BLOCKER]?)

2015-09-16 Thread Anshul Gangwar

Please find my answers inline

Regards,
Anshul

On 16-Sep-2015, at 1:53 PM, Daan Hoogland 
> wrote:

On Wed, Sep 16, 2015 at 10:17 AM, Anshul Gangwar 
>
wrote:

Currently we report only PowerOn VMs and do not report PowerOff VMs that's
why we consider Missing and PowerOff as same

This is not the behavior reported in the ticket. It is intermittent.

[Anshul] Your PR is changing this behaviour. It is intermittent because of the 
ping interval.

And that's how most of the code is written for VM sync and each Hypervisor
resource has same understanding. This will effect HA and many more unknown
places. So please do not even consider to merge this change.

sure, I will hold. We do need to not regard a missing report the same as
power off however.

[Anshul] Initially this was the case that PowerOff and PowerResportMissing 
states were different but later when many issues were reported in vmSync it 
makes more sense to consider PowerReportMissing and PowerOff as same.
So if you are thinking of considering these states to be different then make 
sure you have considered all these scenarios and tested it on every Hypervisor 
that we support as each Hypervisor reports states according to this 
understanding.

Kaushik can give a better understanding around this.

So Now coming to bug we can fix that by changing global setting
pingInterval to appropriate value according to hypervisor settings which
takes care of these transitional period of missing report here or can be
handled by introducing gracePeriod global setting.

I can see what you are talking about but not what you are saying here. Do
you mean that we need to keep track of ping interval and grace period in
the statemachine for a particular VM?

[Anshul] Here I am just talking about changing global setting “ping.interval” 
value or adding one more global setting for grace period to get more finer 
control for these kind of scenarios.

Regards,
Anshul

On 16-Sep-2015, at 1:11 PM, Rohit Yadav 
mailto:rohit.ya...@shapeblue.com>>> wrote:

On 16-Sep-2015, at 1:06 pm, Daan Hoogland 
mailto:daan.hoogl...@gmail.com>>> wrote:

so two questions:
- is this a blocker?

A missing state handler is definitely a corner case, and IMO a blocker
(so, for both 4.6.0 and future 4.5.3).

- is the ignoring after logging the appropriate way to handle this?

It may be undesirable for all cases; so either introducing another global
setting to control logic (just log, vs update state in the db vs do any
operation?); or simply find out if the VM is actually running (or any other
state) just mark it as running in the DB.

Regards,
Rohit Yadav
Software Architect, ShapeBlue

M. +91 88 262 30892 | 
rohit.ya...@shapeblue.commailto:rohit.ya...@shapeblue.com>>
Blog: bhaisaab.org | Twitter: 
@_bhaisaab

Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build<
http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Software Engineering<
http://shapeblue.com/cloudstack-software-engineering/>
CloudStack Infrastructure Support<
http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<
http://shapeblue.com/cloudstack-training/>

This email and any attachments to it may be confidential and are intended
solely for the use of the individual to whom it is addressed. Any views or
opinions expressed are solely those of the author and do not necessarily
represent those of Shape Blue Ltd or related companies. If you are not the
intended recipient of this email, you must neither take any action based
upon its contents, nor copy or show it to anyone. Please contact the sender
if you believe you have received this email in error. Shape Blue Ltd is a
company incorporated in England & Wales. ShapeBlue Services India LLP is a
company incorporated in India and is operated under license from Shape Blue
Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil
and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is
a company registered by The Republic of South Africa and is traded under
license from Shape Blue Ltd. ShapeBlue is a registered trademark.

--
Daan

Re: [DISCUSS][PROPOSAL]missing power state reports from hypervisors on VMs ([BLOCKER]?)

2015-09-16 Thread Anshul Gangwar

It’s not difficult to find a good grace period. It will simply depend on your 
Hypervisor settings how it is configured for HA. You can easily figure out for 
how much time there will be no VM on any Host from your settings and simply put 
2-3 times of that period as grace period.

It seems you have considered only one aspect of change i.e. User VMs HA. 
Did you consider System VMs HA? 
Did you consider that we have already explored that territory of separate 
handling of PowerOff and PowerReportMissing?

And even if you are still thinking of this change then add marvin tests for 
this change. Unit tests will not tell anything about the change.

Regards,
Anshul

> On 16-Sep-2015, at 2:48 PM, Rene Moser  wrote:
> 
> 
> Hi René
> 
> On 09/16/2015 10:17 AM, Anshul Gangwar wrote:
>> Currently we report only PowerOn VMs and do not report PowerOff VMs that's 
>> why we consider Missing and PowerOff as same And that's how most of the code 
>> is written for VM sync and each Hypervisor resource has same understanding. 
>> This will effect HA and many more unknown places. So please do not even 
>> consider to merge this change.
>> 
>> So Now coming to bug we can fix that by changing global setting pingInterval 
>> to appropriate value according to hypervisor settings which takes care of 
>> these transitional period of missing report here or can be handled by 
>> introducing gracePeriod global setting.
> 
> This is interesting, I also wrote in the bug report gracePeriod
> calculation might be related.
> https://github.com/apache/cloudstack/blob/4.5.2/engine/orchestration/src/com/cloud/vm/VirtualMachinePowerStateSyncImpl.java#L110.
> 
> IMHO making this value configurable would might solve it, but it is hard
> to "guess" what a good grace period would be.
> 
> In terms of VMware it depends on amounts of esx in the clusters, and
> they can be different.
> 
> But another question is, why make one _global_ grace period for every
> hypervisor. Think about, users can have mixed hypervisors setups.
> 
> So to me, a global grace period setting might not be the best solution,
> instead we should take care hypervisor functionality, in this case
> VMware, it handels HA by itself.
> 
> I know a VR in 4.5 would be broken after an VMware HA event, but there
> is another global setting, which can be enabled if you like for out of
> band migrations router restarts.
> 
> So to me, in 4.5 I am +1 for the patch of daan makes sense, if
> hypervisor is VMware.
> 
> Yours
> René
>

Re: [DISCUSS][PROPOSAL]missing power state reports from hypervisors on VMs ([BLOCKER]?)

2015-09-16 Thread Anshul Gangwar

I don’t think there was any discussion around this. Kelven have made fixes
around VMSync. So to find details look into FS
https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+VMSync+improvement .

Regards,
Anshul

On 16-Sep-2015, at 3:32 PM, Daan Hoogland
> wrote:

On Wed, Sep 16, 2015 at 11:46 AM, Anshul Gangwar
>
wrote:

It’s not difficult to find a good grace period. It will simply depend on
your Hypervisor settings how it is configured for HA. You can easily figure
out for how much time there will be no VM on any Host from your settings
and simply put 2-3 times of that period as grace period.

That seems kludgey.

It seems you have considered only one aspect of change i.e. User VMs HA.
Did you consider System VMs HA?
Did you consider that we have already explored that territory of separate
handling of PowerOff and PowerReportMissing?

for VMware or for all hypervisors? Do you have a link to the discussion?
These states are different.

Why was it decided to treat them the same?

And even if you are still thinking of this change then add marvin tests
for this change. Unit tests will not tell anything about the change.

Yes, that I definitely agree on.

Regards,
Anshul

On 16-Sep-2015, at 2:48 PM, Rene Moser
> wrote:

Hi René

On 09/16/2015 10:17 AM, Anshul Gangwar wrote:
Currently we report only PowerOn VMs and do not report PowerOff VMs
that's why we consider Missing and PowerOff as same And that's how most of
the code is written for VM sync and each Hypervisor resource has same
understanding. This will effect HA and many more unknown places. So please
do not even consider to merge this change.

So Now coming to bug we can fix that by changing global setting
pingInterval to appropriate value according to hypervisor settings which
takes care of these transitional period of missing report here or can be
handled by introducing gracePeriod global setting.

This is interesting, I also wrote in the bug report gracePeriod
calculation might be related.

https://github.com/apache/cloudstack/blob/4.5.2/engine/orchestration/src/com/cloud/vm/VirtualMachinePowerStateSyncImpl.java#L110
.

IMHO making this value configurable would might solve it, but it is hard
to "guess" what a good grace period would be.

In terms of VMware it depends on amounts of esx in the clusters, and
they can be different.

But another question is, why make one _global_ grace period for every
hypervisor. Think about, users can have mixed hypervisors setups.

So to me, a global grace period setting might not be the best solution,
instead we should take care hypervisor functionality, in this case
VMware, it handels HA by itself.

I know a VR in 4.5 would be broken after an VMware HA event, but there
is another global setting, which can be enabled if you like for out of
band migrations router restarts.

So to me, in 4.5 I am +1 for the patch of daan makes sense, if
hypervisor is VMware.

Yours
René

--
Daan

Re: [DISCUSS][PROPOSAL]missing power state reports from hypervisors on VMs ([BLOCKER]?)

2015-09-16 Thread Daan Hoogland

On Wed, Sep 16, 2015 at 11:46 AM, Anshul Gangwar 
wrote:

> It’s not difficult to find a good grace period. It will simply depend on
> your Hypervisor settings how it is configured for HA. You can easily figure
> out for how much time there will be no VM on any Host from your settings
> and simply put 2-3 times of that period as grace period.
>
That seems kludgey.



> It seems you have considered only one aspect of change i.e. User VMs HA.
> Did you consider System VMs HA?
> Did you consider that we have already explored that territory of separate
> handling of PowerOff and PowerReportMissing?
>
for VMware or for all hypervisors? Do you have a link to the discussion?
These states are different.

Why was it decided to treat them the same?


> And even if you are still thinking of this change then add marvin tests
> for this change. Unit tests will not tell anything about the change.
>
Yes, that I definitely agree on.



> Regards,
> Anshul
>
> > On 16-Sep-2015, at 2:48 PM, Rene Moser  wrote:
> >
> >
> > Hi René
> >
> > On 09/16/2015 10:17 AM, Anshul Gangwar wrote:
> >> Currently we report only PowerOn VMs and do not report PowerOff VMs
> that's why we consider Missing and PowerOff as same And that's how most of
> the code is written for VM sync and each Hypervisor resource has same
> understanding. This will effect HA and many more unknown places. So please
> do not even consider to merge this change.
> >>
> >> So Now coming to bug we can fix that by changing global setting
> pingInterval to appropriate value according to hypervisor settings which
> takes care of these transitional period of missing report here or can be
> handled by introducing gracePeriod global setting.
> >
> > This is interesting, I also wrote in the bug report gracePeriod
> > calculation might be related.
> >
> https://github.com/apache/cloudstack/blob/4.5.2/engine/orchestration/src/com/cloud/vm/VirtualMachinePowerStateSyncImpl.java#L110
> .
> >
> > IMHO making this value configurable would might solve it, but it is hard
> > to "guess" what a good grace period would be.
> >
> > In terms of VMware it depends on amounts of esx in the clusters, and
> > they can be different.
> >
> > But another question is, why make one _global_ grace period for every
> > hypervisor. Think about, users can have mixed hypervisors setups.
> >
> > So to me, a global grace period setting might not be the best solution,
> > instead we should take care hypervisor functionality, in this case
> > VMware, it handels HA by itself.
> >
> > I know a VR in 4.5 would be broken after an VMware HA event, but there
> > is another global setting, which can be enabled if you like for out of
> > band migrations router restarts.
> >
> > So to me, in 4.5 I am +1 for the patch of daan makes sense, if
> > hypervisor is VMware.
> >
> > Yours
> > René
> >
>
>


-- 
Daan

3 weeks away to CCC Dublin

2015-09-16 Thread Sebastien Goasguen

Hi everyone,

We are 3 weeks away to CCC Dublin.

Many thanks to our sponsors:
-Citrix
-Cloud Foundry
-Nuage Networks
-Cloudian
-ShapeBlue
-Soldfire
-iKoula
-LPI-Japan
-PCextreme

I look forward to seeing you all there, don’t forget to register you still have 
time.
Cheers,

-Sebastien

Re: [DISCUSS][PROPOSAL]missing power state reports from hypervisors on VMs ([BLOCKER]?)

[DISCUSS][PROPOSAL]missing power state reports from hypervisors on VMs ([BLOCKER]?)

Re: [DISCUSS][PROPOSAL]missing power state reports from hypervisors on VMs ([BLOCKER]?)

Re: After box restart CS 4.5.2 fails to start

Re: [DISCUSS][PROPOSAL]missing power state reports from hypervisors on VMs ([BLOCKER]?)

Re: [DISCUSS][PROPOSAL]missing power state reports from hypervisors on VMs ([BLOCKER]?)

Re: [DISCUSS][PROPOSAL]missing power state reports from hypervisors on VMs ([BLOCKER]?)

Re: [DISCUSS][PROPOSAL]missing power state reports from hypervisors on VMs ([BLOCKER]?)

Re: [DISCUSS][PROPOSAL]missing power state reports from hypervisors on VMs ([BLOCKER]?)

3 weeks away to CCC Dublin

10 matches

Site Navigation

Mail list logo

Footer information