You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Chip Childers <ch...@sungard.com> on 2013/05/30 04:50:11 UTC

Re: [ACS][VMWARE][BUG?] job execution does not stop while zone, pod and cluster are disabled

On May 29, 2013, at 9:33 PM, Chiradeep Vittal
<Ch...@citrix.com> wrote:

> Certainly the behavior is not robust.

Understated but accurate. ;)

>
> On 5/29/13 10:35 AM, "Musayev, Ilya" <im...@webmd.net> wrote:
>
>> Before I file this as a bug, I would like to understand if this is a bug
>> or by-design.
>>
>> Summary:
>> Many times, the initial zone deployment may fail because incorrect values
>> were used during configuration process. The CS management server will go
>> in cycles over and over again, attempting to use improper values, fail
>> and retry. If left uninterrupted, this repeat cycle can go on forever.
>>
>> Specific issue was witnessed with "ClusteredAgentManager setting public
>> traffic over vSwitch: null", while technically it should have defaulted
>> to vSwitch0.
>> If left uninterrupted, it will create the SSVM VM, fail to find vswitch
>> null for public traffic,  delete storage VM, and repeat this procedure
>> unlimited times.
>>
>> On my attempt to disable Zone first, then pod, the cluster, has not
>> prevented job execution engine from running. I had to put the primary
>> storage into maintenance mode. While this approach technically stopped
>> executions on vSphere vCenter, the SSVM id increased from count of 2, to
>> count of 33 (once I resolved this issue by defining vSwtich0) -
>> indicating that job execution still continued.
>>
>> By design, when you disable cluster, should job execution stop or pause?
>> What about Pod and Zone?
>
>

Re: [ACS][VMWARE][BUG?] job execution does not stop while zone, pod and cluster are disabled

Posted by Prasanna Santhanam <ts...@apache.org>.
Disabling a zone should stop the systemVMs from re-spawning? Agree
that's probably less than ideal, but allows for taking corrective
action in the meantime.

On Thu, May 30, 2013 at 11:13:20AM +0800, Mice Xia wrote:
> if remember correctly, by design disabling a cluster will stop user VM
> deploy in this cluster but does not exclude it from systemvm's destination;
> and vmware based cluster is always chosen as the destination when vmware
> systemvm template is ready. this should be a bug, primary storage's status
> should also be considered when spin up the systemvm.
> 
> 
> On Thu, May 30, 2013 at 10:50 AM, Chip Childers
> <ch...@sungard.com>wrote:
> 
> > On May 29, 2013, at 9:33 PM, Chiradeep Vittal
> > <Ch...@citrix.com> wrote:
> >
> > > Certainly the behavior is not robust.
> >
> > Understated but accurate. ;)
> >
> > >
> > > On 5/29/13 10:35 AM, "Musayev, Ilya" <im...@webmd.net> wrote:
> > >
> > >> Before I file this as a bug, I would like to understand if this is a bug
> > >> or by-design.
> > >>
> > >> Summary:
> > >> Many times, the initial zone deployment may fail because incorrect
> > values
> > >> were used during configuration process. The CS management server will go
> > >> in cycles over and over again, attempting to use improper values, fail
> > >> and retry. If left uninterrupted, this repeat cycle can go on forever.
> > >>
> > >> Specific issue was witnessed with "ClusteredAgentManager setting public
> > >> traffic over vSwitch: null", while technically it should have defaulted
> > >> to vSwitch0.
> > >> If left uninterrupted, it will create the SSVM VM, fail to find vswitch
> > >> null for public traffic,  delete storage VM, and repeat this procedure
> > >> unlimited times.
> > >>
> > >> On my attempt to disable Zone first, then pod, the cluster, has not
> > >> prevented job execution engine from running. I had to put the primary
> > >> storage into maintenance mode. While this approach technically stopped
> > >> executions on vSphere vCenter, the SSVM id increased from count of 2, to
> > >> count of 33 (once I resolved this issue by defining vSwtich0) -
> > >> indicating that job execution still continued.
> > >>
> > >> By design, when you disable cluster, should job execution stop or pause?
> > >> What about Pod and Zone?
> > >
> > >
> >

-- 
Prasanna.,

------------------------
Powered by BigRock.com


Re: [ACS][VMWARE][BUG?] job execution does not stop while zone, pod and cluster are disabled

Posted by Mice Xia <we...@gmail.com>.
if remember correctly, by design disabling a cluster will stop user VM
deploy in this cluster but does not exclude it from systemvm's destination;
and vmware based cluster is always chosen as the destination when vmware
systemvm template is ready. this should be a bug, primary storage's status
should also be considered when spin up the systemvm.


On Thu, May 30, 2013 at 10:50 AM, Chip Childers
<ch...@sungard.com>wrote:

> On May 29, 2013, at 9:33 PM, Chiradeep Vittal
> <Ch...@citrix.com> wrote:
>
> > Certainly the behavior is not robust.
>
> Understated but accurate. ;)
>
> >
> > On 5/29/13 10:35 AM, "Musayev, Ilya" <im...@webmd.net> wrote:
> >
> >> Before I file this as a bug, I would like to understand if this is a bug
> >> or by-design.
> >>
> >> Summary:
> >> Many times, the initial zone deployment may fail because incorrect
> values
> >> were used during configuration process. The CS management server will go
> >> in cycles over and over again, attempting to use improper values, fail
> >> and retry. If left uninterrupted, this repeat cycle can go on forever.
> >>
> >> Specific issue was witnessed with "ClusteredAgentManager setting public
> >> traffic over vSwitch: null", while technically it should have defaulted
> >> to vSwitch0.
> >> If left uninterrupted, it will create the SSVM VM, fail to find vswitch
> >> null for public traffic,  delete storage VM, and repeat this procedure
> >> unlimited times.
> >>
> >> On my attempt to disable Zone first, then pod, the cluster, has not
> >> prevented job execution engine from running. I had to put the primary
> >> storage into maintenance mode. While this approach technically stopped
> >> executions on vSphere vCenter, the SSVM id increased from count of 2, to
> >> count of 33 (once I resolved this issue by defining vSwtich0) -
> >> indicating that job execution still continued.
> >>
> >> By design, when you disable cluster, should job execution stop or pause?
> >> What about Pod and Zone?
> >
> >
>