[jira] [Commented] (CLOUDSTACK-6514) VMware: Is space allocated for snapshots counted correctly?

2014-11-12 Thread Likitha Shetty (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14209461#comment-14209461
 ] 

Likitha Shetty commented on CLOUDSTACK-6514:


Mike, since we default to linked clone now should we consider the size of the 
base ROOT file as well?

> VMware: Is space allocated for snapshots counted correctly?
> ---
>
> Key: CLOUDSTACK-6514
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6514
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.4.0
> Environment: Ubuntu 12.04 for CloudStack Management Server (just one 
> in this config)
> Two ESXi 5.1 hosts
>Reporter: Mike Tutkowski
>Assignee: Mike Tutkowski
> Fix For: 4.4.0, 4.5.0
>
>
> long CapacityManager.getAllocatedPoolCapacity(StoragePoolVO, VMTemplateVO) 
> may not add up allocated space in the passed-in storage pool properly for 
> VMware.
> The idea is to count the allocated space of all non-destroyed volumes and the 
> corresponding allocated space of their snapshots, if any. In addition, 
> templates on the storage pool should be taken into consideration.
> I think the number that is in the vm_snapshot_chain_size column of the 
> volumes table is not correctly calculated (and this number is used by the 
> getAllocatedPoolCapacity method when it invokes another method).
> This is how it currently works when you have a new VM and you take a snapshot 
> of it for the first time (not taking a snapshot of memory):
> These are the relevant files and their respective sizes:
> ROOT-21-01-delta.vmdk (16,785,408 bytes)
> ROOT-21-01.vmdk (316 bytes)
> ROOT-21-flat.vmdk (2,147,483,648 bytes)
> ROOT-21.vmdk (515 bytes)
> i-2-21-VM-Snapshot1.vmsn (28,310 bytes)
> We include these files for the vm_snapshot_chain_size:
> ROOT-21-flat.vmdk (2,147,483,648 bytes)
> ROOT-21.vmdk (515 bytes)
> i-2-21-VM-Snapshot1.vmsn (28,310 bytes)
> I think we should be counting these instead:
> ROOT-21-01-delta.vmdk (16,785,408 bytes)
> ROOT-21-01.vmdk (316 bytes)
> i-2-21-VM-Snapshot1.vmsn (28,310 bytes)
> My thinking is that when we add up the total space that this volume consumes 
> that we've already taking into account 2,147,483,648 bytes because this value 
> is stored in the size column of the volumes table.
> I would think we'd want to add up the sizes of the VMSN files and the sizes 
> of the -xx files to arrive at vm_snapshot_chain_size?
> Any thoughts on this?
> Thanks!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CLOUDSTACK-6514) VMware: Is space allocated for snapshots counted correctly?

2014-11-12 Thread Likitha Shetty (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Likitha Shetty updated CLOUDSTACK-6514:
---
Assignee: Mike Tutkowski  (was: Likitha Shetty)

> VMware: Is space allocated for snapshots counted correctly?
> ---
>
> Key: CLOUDSTACK-6514
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6514
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.4.0
> Environment: Ubuntu 12.04 for CloudStack Management Server (just one 
> in this config)
> Two ESXi 5.1 hosts
>Reporter: Mike Tutkowski
>Assignee: Mike Tutkowski
> Fix For: 4.4.0, 4.5.0
>
>
> long CapacityManager.getAllocatedPoolCapacity(StoragePoolVO, VMTemplateVO) 
> may not add up allocated space in the passed-in storage pool properly for 
> VMware.
> The idea is to count the allocated space of all non-destroyed volumes and the 
> corresponding allocated space of their snapshots, if any. In addition, 
> templates on the storage pool should be taken into consideration.
> I think the number that is in the vm_snapshot_chain_size column of the 
> volumes table is not correctly calculated (and this number is used by the 
> getAllocatedPoolCapacity method when it invokes another method).
> This is how it currently works when you have a new VM and you take a snapshot 
> of it for the first time (not taking a snapshot of memory):
> These are the relevant files and their respective sizes:
> ROOT-21-01-delta.vmdk (16,785,408 bytes)
> ROOT-21-01.vmdk (316 bytes)
> ROOT-21-flat.vmdk (2,147,483,648 bytes)
> ROOT-21.vmdk (515 bytes)
> i-2-21-VM-Snapshot1.vmsn (28,310 bytes)
> We include these files for the vm_snapshot_chain_size:
> ROOT-21-flat.vmdk (2,147,483,648 bytes)
> ROOT-21.vmdk (515 bytes)
> i-2-21-VM-Snapshot1.vmsn (28,310 bytes)
> I think we should be counting these instead:
> ROOT-21-01-delta.vmdk (16,785,408 bytes)
> ROOT-21-01.vmdk (316 bytes)
> i-2-21-VM-Snapshot1.vmsn (28,310 bytes)
> My thinking is that when we add up the total space that this volume consumes 
> that we've already taking into account 2,147,483,648 bytes because this value 
> is stored in the size column of the volumes table.
> I would think we'd want to add up the sizes of the VMSN files and the sizes 
> of the -xx files to arrive at vm_snapshot_chain_size?
> Any thoughts on this?
> Thanks!



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CLOUDSTACK-7713) Triage and fix Coverity defects

2014-11-12 Thread Likitha Shetty (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Likitha Shetty updated CLOUDSTACK-7713:
---
Fix Version/s: (was: 4.5.0)
   Future

> Triage and fix Coverity defects
> ---
>
> Key: CLOUDSTACK-7713
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7713
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Santhosh Kumar Edukulla
>Assignee: Likitha Shetty
> Fix For: Future
>
>
> 1. We have Coverity setup available, running as scheduled and individual 
> owners are assigned with analyzed bugs.
> 2. As part of this bug, please triage and fix the relevant Coverity bugs 
> assigned. It could be a count as small as 25 bugs.
> 3. First start with high impact in order to others later.
> 4. We can either triage them accordingly as fix required or false positive or 
> not a bug accordingly. But, triage and fix accordingly wherever relevant and 
> applicable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CLOUDSTACK-7102) Volume migration fails with 'VM i-2-3-VM does not exist in VMware datacenter' expection

2014-11-12 Thread Likitha Shetty (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Likitha Shetty resolved CLOUDSTACK-7102.

Resolution: Fixed

+Root Cause Analysis+
When global configuration 'vm.instancename.flag' is set to true, VM files and 
the ROOT disk is placed in the VM folder named after VM's name in vCenter. But 
any further disks that are attached to the VM are placed in VM folder that is 
named after VM's CCP internal name (e.g. i-2-3-VM). And due to this mismatch we 
run into file not found errors. Also, since we do VM look-ups based on VM's CCP 
internal name we run into 'VM i-2-3-VM does not exist in VMware datacenter' 
exceptions.

+Proposed Solution+
Look-up for a VM in vCenter should be based on both the vCenter name and CS 
internal name.
VM folder name in primary storage should always be VM's name in vCenter and all 
the files related to the VM should reside in this folder. 
During Attach Volume and Volume Migration, for lookup and other operations use 
VM's name as obtained from vCenter instead of using the name that is set in the 
agent command.

> Volume migration fails with 'VM i-2-3-VM does not exist in VMware datacenter' 
> expection
> ---
>
> Key: CLOUDSTACK-7102
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7102
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller, VMware
>Affects Versions: 4.2.0
>Reporter: Likitha Shetty
>Assignee: Likitha Shetty
>Priority: Critical
>  Labels: S1
> Fix For: 4.5.0
>
>
> Steps to reproduce
> 
> 1. Set global config 'vm.instancename.flag' to true.
> 2. Bring up CS in advanced zone with at-least one vmware cluster.
> 3. Add two primary storages to the cluster.
> 4. Deploy one guest VM.
> 5. Create a volume and attach the volume to the guest VM. (Ensure the volume 
> is in primary storage that doesn't contain the root disk).
> 6. Migrate the volume to the primary storage that contains the root disk.
> Volume Migration will fail with the below error -
> {noformat}
> 2014-07-14 12:21:33,112 ERROR [c.c.h.v.r.VmwareResource] 
> (DirectAgent-398:ctx-4797dd6a 10.102.192.7, job-878/job-879, cmd: 
> MigrateVolumeCommand) Catch Exception java.lang.Exception due to 
> java.lang.Exception: VM i-2-32-VM does not exist in VMware datacenter 
> datacenter-30215
> java.lang.Exception: VM i-2-32-VM does not exist in VMware datacenter 
> datacenter-30215
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:3139)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:416)
> at 
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:293)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {noformat}
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7102) Volume migration fails with 'VM i-2-3-VM does not exist in VMware datacenter' expection

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14209442#comment-14209442
 ] 

ASF subversion and git services commented on CLOUDSTACK-7102:
-

Commit b8fdda0a34f5338db284ee616c5e04206c97b82e in cloudstack's branch 
refs/heads/master from [~likithas]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b8fdda0 ]

BUG-ID: CLOUDSTACK-7102. Volume migration fails with 'VM i-2-3-VM does not 
exist in VMware datacenter' expection.
Look for a VM in vCenter based on both the vCenter name and CS internal name 
(required in case 'vm.instancename.flag' is enabled).
During Attach Volume and Volume Migration, for lookup and other operations use 
VM's name as obtained from vCenter instead of using the name set in the agent 
command.


> Volume migration fails with 'VM i-2-3-VM does not exist in VMware datacenter' 
> expection
> ---
>
> Key: CLOUDSTACK-7102
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7102
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller, VMware
>Affects Versions: 4.2.0
>Reporter: Likitha Shetty
>Assignee: Likitha Shetty
>Priority: Critical
>  Labels: S1
> Fix For: 4.5.0
>
>
> Steps to reproduce
> 
> 1. Set global config 'vm.instancename.flag' to true.
> 2. Bring up CS in advanced zone with at-least one vmware cluster.
> 3. Add two primary storages to the cluster.
> 4. Deploy one guest VM.
> 5. Create a volume and attach the volume to the guest VM. (Ensure the volume 
> is in primary storage that doesn't contain the root disk).
> 6. Migrate the volume to the primary storage that contains the root disk.
> Volume Migration will fail with the below error -
> {noformat}
> 2014-07-14 12:21:33,112 ERROR [c.c.h.v.r.VmwareResource] 
> (DirectAgent-398:ctx-4797dd6a 10.102.192.7, job-878/job-879, cmd: 
> MigrateVolumeCommand) Catch Exception java.lang.Exception due to 
> java.lang.Exception: VM i-2-32-VM does not exist in VMware datacenter 
> datacenter-30215
> java.lang.Exception: VM i-2-32-VM does not exist in VMware datacenter 
> datacenter-30215
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:3139)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:416)
> at 
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:293)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {noformat}
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (CLOUDSTACK-6691) NPE while assigning a VM nic primary/secondaryip to internal lb rule.

2014-11-12 Thread manasaveloori (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

manasaveloori closed CLOUDSTACK-6691.
-
Resolution: Fixed

not reproducible in 4.5 .Closing it.

> NPE while assigning a VM nic primary/secondaryip to internal lb rule.
> -
>
> Key: CLOUDSTACK-6691
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6691
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.4.0
>Reporter: manasaveloori
>Assignee: manasaveloori
>Priority: Critical
> Fix For: 4.4.0, 4.5.0
>
> Attachments: management-server.rar
>
>
> 1.Create VPC.
> 2. Create a tier network using the network offering supporting the internal 
> lb.
> 3. Deploy a VM using this tier network.Acquire secondary ip to the VM nic.
> 4. Go to VPC->configure->tier->internal LB->configure the internal LB.
> 5. Now assign vm in that tier to that internal Lb rule.
> Failing with NPE:
> 2014-05-16 06:29:00,509 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-23:job-114) Executing AsyncJobVO {id:114, userId: 2, 
> accountId: 2, instanceType: None, instanceId: null, cmd: 
> org.apache.cloudstack.api.command.user.loadbalancer.AssignToLoadBalancerRuleCmd,
>  cmdInfo: 
> {"":"","cmdEventType":"LB.ASSIGN.TO.RULE","ctxUserId":"2","signatureversion":"3","httpmethod":"GET","vmidipmap[0].vmip":"","apikey":"71KC57DrfcKrtoky1fx8-1drvYkZhxt2h1qhXig8LMlvnnppryePDI6ZZbyQ9uSHwawJcIA7xPzOV6zKoQEwDw","id":"","10.0.2.250":"","response":"json","ctxDetails":"{\"LoadBalancer\":\"\"}","expires":"2014-05-16T10:39:00+","5":"","uuid":"","ctxAccountId":"2","vmidipmap[0].vmid":"f91de9de-508a-4b84-8939-1c9173caa316","ctxStartEventId":"284","signature":"+ufhrzwBGdylmvZEV/6P+YmsLv0\u003d"},
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 7672522866886, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: null}
> 2014-05-16 06:29:00,523 WARN  [c.c.a.d.ParamGenericValidationWorker] 
> (API-Job-Executor-23:job-114 ctx-1d33bb54) Received unknown parameters for 
> command assignToLoadBalancerRule. Unknown parameters :  signatureversion 
> ctxdetails 10.0.2.250 expires 5
> 2014-05-16 06:29:00,524 ERROR [c.c.a.ApiAsyncJobDispatcher] 
> (API-Job-Executor-23:job-114) Unexpected exception while executing 
> org.apache.cloudstack.api.command.user.loadbalancer.AssignToLoadBalancerRuleCmd
> java.lang.NullPointerException
> at 
> org.apache.cloudstack.api.command.user.loadbalancer.AssignToLoadBalancerRuleCmd.getSyncObjId(AssignToLoadBalancerRuleCmd.java:190)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:92)
> at 
> com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
> at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:496)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:453)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> 2014-05-16 06:29:00,526 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-23:job-114) Complete async job-114, jobStatus: FAILED, 
> resultCode: 530, result: 
> org.apache.cloudstack.api.response.ExceptionResponse/null/{"uuidList":[],"errorcode":530}
> 2014-05-16 06:29:00,550 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-23:job-114) Done executing 
> org.apache.cloudstack.api.command.user.loadbalancer.AssignToLoadBalancerRuleCmd
>  for job-114
> Attaching the logs



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CLOUDSTACK-7651) Various operation intermittently fail in VMware with 'he object has already been deleted or has not been completely created' exceptions

2014-11-12 Thread Likitha Shetty (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Likitha Shetty resolved CLOUDSTACK-7651.

Resolution: Fixed

Fixed by 
[https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=9866c648eb5e6ce6ded1b6dcadbb77240fe0e683]

> Various operation intermittently fail in VMware with 'he object has already 
> been deleted or has not been completely created' exceptions
> ---
>
> Key: CLOUDSTACK-7651
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7651
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.5.0
>Reporter: Likitha Shetty
>Assignee: Likitha Shetty
>Priority: Critical
> Fix For: 4.5.0
>
>
> +Steps to reproduce+ 
> 1. Setup VMware 4.3.0.1 with 1 CCP Management server.
> 2. Create 2 VMware DCs in 2 different vCenters.
> 3. Add 2 zones in CCP corresponding to the two DCs.
> 4. Do basic VM/Volume lifecycle operations.
> Keep monitoring the logs for the following error - 
> *javax.xml.ws.soap.SOAPFaultException: The object has already been deleted or 
> has not been completely created*
> For e.g. 
> {noformat}
> javax.xml.ws.soap.SOAPFaultException
> Message: The object has already been deleted or has not been completely 
> created
> javax.xml.ws.soap.SOAPFaultException: The object has already been deleted or 
> has not been completely created
> at 
> com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)
> at 
> com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119)
> at 
> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
> at 
> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
> at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:110)
> at com.sun.proxy.$Proxy389.retrieveProperties(Unknown Source)
> at 
> com.cloud.hypervisor.vmware.util.VmwareClient.retrieveMoRefProperties(VmwareClient.java:308)
> at 
> com.cloud.hypervisor.vmware.util.VmwareClient.getDynamicProperty(VmwareClient.java:263)
> at 
> com.cloud.hypervisor.vmware.mo.HostMO.getHostDatastoreSystemMO(HostMO.java:166)
> at 
> com.cloud.hypervisor.vmware.mo.HostMO.findDatastore(HostMO.java:889)
> at 
> com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.findDatastoreWithBackwardsCompatibility(HypervisorHostHelper.java:131)
> at 
> com.cloud.storage.resource.VmwareStorageProcessor.deleteVolume(VmwareStorageProcessor.java:1481)
> at 
> com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:120)
> at 
> com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:54)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:598)
> at 
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:215)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:50)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:47)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:701)
> {noformat}
> +Root Cause Analysis+
> The thread local context which is used to handle connections to a vCenter is 
> being re-used intermittently. And when it is re-used, if the existi

[jira] [Updated] (CLOUDSTACK-4757) Support OVA files with multiple disks for templates

2014-11-12 Thread Likitha Shetty (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Likitha Shetty updated CLOUDSTACK-4757:
---
Fix Version/s: (was: 4.5.0)
   Future

> Support OVA files with multiple disks for templates
> ---
>
> Key: CLOUDSTACK-4757
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4757
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller
>Affects Versions: 4.3.0
>Reporter: Likitha Shetty
>Assignee: Likitha Shetty
> Fix For: Future
>
>
> CloudStack volumes and templates are one single virtual disk in case of 
> XenServer/XCP and KVM hypervisors since the files used for templates and 
> volumes are virtual disks (VHD, QCOW2). However, VMware volumes and templates 
> are in OVA format, which are archives that can contain a complete VM 
> including multiple VMDKs and other files such as ISOs. And currently, 
> Cloudstack only supports Template creation based on OVA files containing a 
> single disk. If a user creates a template from a OVA file containing more 
> than 1 disk and launches an instance using this template, only the first disk 
> is attached to the new instance and other disks are ignored.
> Similarly with uploaded volumes, attaching an uploaded volume that contains 
> multiple disks to a VM will result in only one VMDK to being attached to the 
> VM.
> This behavior needs to be improved in VMWare to support OVA files with 
> multiple disks for both uploaded volumes and templates. i.e. If a user 
> creates a template from a OVA file containing more than 1 disk and launches 
> an instance using this template, the first disk should be attached to the new 
> instance as the ROOT disk and volumes should be created based on other VMDK 
> disks in the OVA file and should be attached to the instance.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CLOUDSTACK-2996) Nullpointer exception on view console on vmware

2014-11-12 Thread Likitha Shetty (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Likitha Shetty updated CLOUDSTACK-2996:
---
Assignee: (was: Likitha Shetty)

> Nullpointer exception on view console on vmware
> ---
>
> Key: CLOUDSTACK-2996
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2996
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VNC Proxy
>Affects Versions: 4.1.0
> Environment: VMware 5.1 with CentOS 6
>Reporter: Tamas Monos
>Priority: Critical
> Fix For: Future
>
>
> Hi,
> After 3.0.2->4.1 upgrade I cannot use the view-console function in the UI.
> I always get "Access is denied for the console session. Please close the 
> window and retry again"
> In the management-server log I find lots of nullpointer exceptions:
> 2013-06-13 16:20:14,561 DEBUG [vmware.mo.HostMO] 
> (DirectAgent-56:esxw1.veber.co.uk) find VM i-2-5-VM on host
> 2013-06-13 16:20:14,562 DEBUG [vmware.mo.HostMO] 
> (DirectAgent-56:esxw1.veber.co.uk) load VM cache on host
> 2013-06-13 16:20:15,000 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-56:null) Seq 2-205195617: Response Received: 
> 2013-06-13 16:20:15,000 DEBUG [agent.transport.Request] 
> (StatsCollector-1:null) Seq 2-205195617: Received:  { Ans: , MgmtId: 
> 345049205465, via: 2, Ver: v1, Flags: 10, { GetVmStatsAnswer } }
> 2013-06-13 16:20:19,142 DEBUG [agent.transport.Request] 
> (AgentManager-Handler-13:null) Seq 2-1681524997: Executing:  { Cmd , MgmtId: 
> 345049213916, via: 2, Ver: v1, Flags: 100011, [{"GetVncPortCommand":{"id
> ":5,"name":"i-2-5-VM","wait":0}}] }
> 2013-06-13 16:20:19,142 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-41:null) Seq 2-1681524997: Executing request
> 2013-06-13 16:20:19,143 DEBUG [vmware.mo.HostMO] 
> (DirectAgent-41:esxw1.veber.co.uk) find VM i-2-5-VM on host
> 2013-06-13 16:20:19,143 DEBUG [vmware.mo.HostMO] 
> (DirectAgent-41:esxw1.veber.co.uk) load VM cache on host
> 2013-06-13 16:20:20,503 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-41:null) Seq 2-1681524997: Response Received: 
> 2013-06-13 16:20:20,503 DEBUG [agent.manager.ClusteredAgentManagerImpl] 
> (DirectAgent-41:null) Seq 2-1681524997: MgmtId 345049213916: Resp: Routing to 
> peer
> 2013-06-13 16:20:22,838 DEBUG [agent.manager.AgentManagerImpl] 
> (AgentManager-Handler-14:null) SeqA 4-1561: Processing Seq 4-1561:  { Cmd , 
> MgmtId: -1, via: 4, Ver: v1, Flags: 11, 
> [{"ConsoleAccessAuthenticationCommand":{"_host":"192.168.1.8","_port":"5908","_vmId":"18b5fb46-5802-421f-beba-1656674ccd86","_sid":"abddf0e66a4610b3","_ticket":"EBf0KlF4mayF4/Ueu50EFGS5uls=","_isReauthenticating":false,"wait":0}}]
>  }
> 2013-06-13 16:20:22,838 DEBUG [cloud.consoleproxy.ConsoleProxyManagerImpl] 
> (AgentManager-Handler-14:null) Console authentication. Ticket in url for 
> 192.168.1.8:5908-18b5fb46-5802-421f-beba-1656674ccd86 is 
> EBf0KlF4mayF4/Ueu50EFGS5uls=
> 2013-06-13 16:20:22,839 ERROR [cloud.servlet.ConsoleProxyServlet] 
> (AgentManager-Handler-14:null) Unexpected exception 
> java.lang.NullPointerException
> at 
> com.cloud.servlet.ConsoleProxyServlet.genAccessTicket(ConsoleProxyServlet.java:429)
> at 
> com.cloud.servlet.ConsoleProxyServlet.genAccessTicket(ConsoleProxyServlet.java:418)
> at 
> com.cloud.consoleproxy.ConsoleProxyManagerImpl.onConsoleAccessAuthentication(ConsoleProxyManagerImpl.java:906)
> at 
> com.cloud.consoleproxy.ConsoleProxyListener.processControlCommand(ConsoleProxyListener.java:61)
> at 
> com.cloud.agent.manager.AgentManagerImpl.handleControlCommand(AgentManagerImpl.java:348)
> at 
> com.cloud.agent.manager.AgentManagerImpl.access$200(AgentManagerImpl.java:145)
> at 
> com.cloud.agent.manager.AgentManagerImpl$AgentHandler.processRequest(AgentManagerImpl.java:1286)
> at 
> com.cloud.agent.manager.AgentManagerImpl$AgentHandler.doTask(AgentManagerImpl.java:1374)
> at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl$ClusteredAgentHandler.doTask(ClusteredAgentManagerImpl.java:659)
> at com.cloud.utils.nio.Task.run(Task.java:83)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:679)
> 2013-06-13 16:20:22,839 DEBUG [cloud.consoleproxy.ConsoleProxyManagerImpl] 
> (AgentManager-Handler-14:null) Console authentication. Ticket in 1 minute 
> boundary for 192.168.1.8:5908-18b5fb46-5802-421f-beba-1656674ccd86 is 
> 2013-06-13 16:20:22,839 ERROR [cloud.servlet.ConsoleProxyServlet] 
> (AgentManager-Handler-14:null) Unexpected exception

[jira] [Resolved] (CLOUDSTACK-6631) unable to attach new Volume to VM

2014-11-12 Thread Likitha Shetty (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Likitha Shetty resolved CLOUDSTACK-6631.

   Resolution: Fixed
Fix Version/s: 4.5.0

This issue will be fixed by Anshul 's fix for 
[https://issues.apache.org/jira/browse/CLOUDSTACK-6897].

Failure is because CCP's cluster-wide storage pool allocator is being sent the 
VM's pod id instead of the Storage pool's pod-id (NULL) which further results 
in an NPE. CCP should instead send storage pool's pod-id instead of the VM's to 
the storage pool allocators.

> unable to attach new Volume to VM
> -
>
> Key: CLOUDSTACK-6631
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6631
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.2.1
> Environment: Cloudstack 4.2.1 + KVM on CentOS 6.4
>Reporter: Kazuhiro Ito
>Assignee: Likitha Shetty
> Fix For: 4.5.0
>
> Attachments: management-server.log.0521
>
>
> 1. I added new volume.
> 2. I tried to attach the volume to a VM on UI.
> 3. It failed and the following log appeared.
> 2014-05-12 11:29:47,096 DEBUG [cloud.api.ApiServlet] 
> (http-6443-exec-116:null) ===START===  133.xx.xxx.xxx -- GET  
> command=attachVolume&id=ac7099fb-ac66-4c63-bf1e-ed0e1429f412&virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74&response=json&sessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D&_=1399861774316
> 2014-05-12 11:29:47,143 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (http-6443-exec-116:null) submit async job-4916 = [ 
> dd8fab57-96aa-446f-8ebd-53c32ce4501a ], details: AsyncJobVO {id:4916, userId: 
> 3, accountId: 3, sessionKey: null, instanceType: Volume, instanceId: 1543, 
> cmd: org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd, 
> cmdOriginator: null, cmdInfo: 
> {"response":"json","id":"ac7099fb-ac66-4c63-bf1e-ed0e1429f412","sessionkey":"TDcTy/QRb5/+k28wsjg6BWd6pcA\u003d","cmdEventType":"VOLUME.ATTACH","ctxUserId":"3","virtualMachineId":"ecdc2c1d-e21e-4c04-962a-4efac1a69a74","httpmethod":"GET","_":"1399861774316","ctxAccountId":"3","ctxStartEventId":"34276"},
>  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
> processStatus: 0, resultCode: 0, result: null, initMsid: 90520731085572, 
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2014-05-12 11:29:47,144 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) 
> Executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd for 
> job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]
> 2014-05-12 11:29:47,147 DEBUG [cloud.api.ApiServlet] 
> (http-6443-exec-116:null) ===END===  133.xx.xxx.xxx -- GET  
> command=attachVolume&id=ac7099fb-ac66-4c63-bf1e-ed0e1429f412&virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74&response=json&sessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D&_=1399861774316
> 2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl] 
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access 
> to org.apache.cloudstack.storage.volume.VolumeObject@17178a01 granted to 
> Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by 
> DomainChecker_EnhancerByCloudStack_9b413459
> 2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl] 
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access 
> to VM[User|TEST-A2-VM01] granted to 
> Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by 
> DomainChecker_EnhancerByCloudStack_9b413459
> 2014-05-12 11:29:47,212 DEBUG [storage.allocator.LocalStoragePoolAllocator] 
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) 
> LocalStoragePoolAllocator trying to find storage pool to fit the vm
> 2014-05-12 11:29:47,212 DEBUG 
> [storage.allocator.ClusterScopeStoragePoolAllocator] 
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) 
> ClusterScopeStoragePoolAllocator looking for storage pool
> 2014-05-12 11:29:47,212 DEBUG 
> [storage.allocator.ClusterScopeStoragePoolAllocator] 
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) 
> Looking for pools in dc: 1  pod:1  cluster:null having tags:[MPI]
> 2014-05-12 11:29:47,216 DEBUG 
> [storage.allocator.ClusterScopeStoragePoolAllocator] 
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) No 
> storage pools available for shared volume allocation, returning
> 2014-05-12 11:29:47,234 ERROR [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) 
> Unexpected exception while executing 
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
> com.cloud.utils.exception.Cloud

[jira] [Resolved] (CLOUDSTACK-7791) [Snapshots] State transition in snapshot objects when snapshot is taken on Root/Data disk is not proper

2014-11-12 Thread Likitha Shetty (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Likitha Shetty resolved CLOUDSTACK-7791.

Resolution: Not a Problem

> [Snapshots] State transition in snapshot objects when snapshot is taken on 
> Root/Data disk is not proper
> ---
>
> Key: CLOUDSTACK-7791
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7791
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Snapshot, VMware
>Affects Versions: 4.5.0
> Environment: Latest build from 4.5
>Reporter: Sanjeev N
>Assignee: Likitha Shetty
>  Labels: snapshots
> Fix For: 4.5.0
>
> Attachments: management-server.rar
>
>
> [Snapshots] State transition in snapshot objects when snapshot is taken on 
> Root/Data disk is not proper
> Steps to Reproduce:
> 
> 1.Bring up CS with latest build using vmware cluster
> 2.Deploy one guest vm using default cent os template
> 3.Create a snapshot on the root disk of the vm
> Expected Behavior:
> ==
> Snapshot operation should go through the following states:
> Creating->CreatedOnPrimary->BackingUp->BackedUp
> Actual Result:
> ===
> We only see two states: Backingup->Backedup
> As and when the snapshot is triggered it goes to backing up state and remains 
> in that state until the snapshot is copied to secondary storage and then goes 
> to Backedup state.
> This is easy to reproduce.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7791) [Snapshots] State transition in snapshot objects when snapshot is taken on Root/Data disk is not proper

2014-11-12 Thread Likitha Shetty (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14209362#comment-14209362
 ] 

Likitha Shetty commented on CLOUDSTACK-7791:


This is by design.

In CCP, volume snapshot involves 2 steps -
1. Creation of volume snapshot on primary storage.
2. Backup of the snapshot into secondary storage. 

As mentioned in the bug description snapshot operation should go through the 
following states -
Creating->CreatedOnPrimary->BackingUp->BackedUp
The first two states belong to step 1 of creation on primary and and the last 
two steps belong to step 2 of backup to secondary.

But since in case of vSphere since Volume is not a first class object, CCP 
cannot snapshot the volume on primary (we instead snapshot the entire VM and 
export it to secondary storage as part of backup). So the first step is simply 
a dummy step in case of VMware and the entire snapshot operation happens as 
part of step 2 because of which the first two snapshot states don't exist in 
case of VMware volume snapshot.

> [Snapshots] State transition in snapshot objects when snapshot is taken on 
> Root/Data disk is not proper
> ---
>
> Key: CLOUDSTACK-7791
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7791
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Snapshot, VMware
>Affects Versions: 4.5.0
> Environment: Latest build from 4.5
>Reporter: Sanjeev N
>Assignee: Likitha Shetty
>  Labels: snapshots
> Fix For: 4.5.0
>
> Attachments: management-server.rar
>
>
> [Snapshots] State transition in snapshot objects when snapshot is taken on 
> Root/Data disk is not proper
> Steps to Reproduce:
> 
> 1.Bring up CS with latest build using vmware cluster
> 2.Deploy one guest vm using default cent os template
> 3.Create a snapshot on the root disk of the vm
> Expected Behavior:
> ==
> Snapshot operation should go through the following states:
> Creating->CreatedOnPrimary->BackingUp->BackedUp
> Actual Result:
> ===
> We only see two states: Backingup->Backedup
> As and when the snapshot is triggered it goes to backing up state and remains 
> in that state until the snapshot is copied to secondary storage and then goes 
> to Backedup state.
> This is easy to reproduce.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-7901) [NetAppVSC]Unable to create deployment on NetApp VSC provisioned primary storage

2014-11-12 Thread Srikanteswararao Talluri (JIRA)
Srikanteswararao Talluri created CLOUDSTACK-7901:


 Summary: [NetAppVSC]Unable to create deployment on NetApp VSC 
provisioned primary storage
 Key: CLOUDSTACK-7901
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7901
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Storage Controller
Affects Versions: 4.4.0
Reporter: Srikanteswararao Talluri


Unable to create VM on storage provisioned by netapp VSC. VM deployment was 
succesful on a non netapp vsc provisioned storage.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-7900) [NetAppVSC]Unable to download a volume

2014-11-12 Thread Srikanteswararao Talluri (JIRA)
Srikanteswararao Talluri created CLOUDSTACK-7900:


 Summary: [NetAppVSC]Unable to download a volume
 Key: CLOUDSTACK-7900
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7900
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Storage Controller
Affects Versions: 4.4.0
Reporter: Srikanteswararao Talluri


Unable to download a volume residing on storage provisioned by netapp VSC.


2014-05-13 23:05:17,275 DEBUG [c.c.a.t.Request] (API-Job-Executor-29:job-278 
ctx-6acf5903) Seq 6-722141364: Received:  { Ans: , MgmtId: 6777458393139, via: 
6, Ver: v1, Flags: 10, { CopyCmdAnswer } }
2014-05-13 23:05:17,322 ERROR [c.c.a.ApiAsyncJobDispatcher] 
(API-Job-Executor-29:job-278) Unexpected exception while executing 
org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd
com.cloud.exception.UnsupportedServiceException: Extract entity url is not yet 
supported for this image store provider.
at 
com.netapp.kanto.storagesubsystem.NetAppDataStoreDriver.createEntityExtractUrl(NetAppDataStoreDriver.java:329)
at 
org.apache.cloudstack.storage.image.store.ImageStoreImpl.createEntityExtractUrl(ImageStoreImpl.java:204)
at 
com.cloud.storage.VolumeApiServiceImpl.extractVolume(VolumeApiServiceImpl.java:1936)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy213.extractVolume(Unknown Source)
at 
org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd.execute(ExtractVolumeCmd.java:131)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161)
at 
com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:97)
at 
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:495)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:50)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:47)
at 
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:452)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
2014-05-13 23:05:17,325 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-29:job-278) Complete async job-278, jobStatus: FAILED, 
resultCode: 530, result: 
org.apache.cloudstack.api.response.ExceptionResponse/null/{"uuidList":[],"errorcode":530,"errortext":"Extract
 entity url is not yet supported for this image store provider."}
2014-05-13 23:05:17,344 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-29:job-278) Done executing 
org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd for job-278
2014-05-13 23:05:17,356 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(API-Job-Executor-29:job-278) Remove job-278 from job m



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-7899) [NetAppVSC]Unable to resize a volume

2014-11-12 Thread Srikanteswararao Talluri (JIRA)
Srikanteswararao Talluri created CLOUDSTACK-7899:


 Summary: [NetAppVSC]Unable to resize a volume
 Key: CLOUDSTACK-7899
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7899
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Storage Controller
Affects Versions: 4.4.0
Reporter: Srikanteswararao Talluri


Unable to resize a volume residing on storage provisioned by netapp VSC.
Resize is going on forever. This is completed quickly when I tried to resize a 
volume on a non-netapp provisioned volume.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (CLOUDSTACK-6386) DB Exceptions while starting the Management server first time

2014-11-12 Thread Jayashree Ramamoorthy (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14209313#comment-14209313
 ] 

Jayashree Ramamoorthy edited comment on CLOUDSTACK-6386 at 11/13/14 5:49 AM:
-

I am seeing the following similar exception with the latest build.  Also, 
please find the complete management server logs attached

2014-11-13 10:38:44,810 DEBUG [c.c.u.d.Upgrade410to420] (main:null) Done set 
KVM snapshot flag.
2014-11-13 10:38:44,810 DEBUG [c.c.u.d.Upgrade410to420] (main:null) Dropping 
index i_alert__last_sent if it exists
2014-11-13 10:38:44,835 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop key last_sent on table alert 
exception: Can't DROP 'last_sent'; check that column/key exists
2014-11-13 10:38:44,836 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop key i_alert__last_sent on table alert 
exception: Can't DROP 'i_alert__last_sent'; check that column/key exists
2014-11-13 10:38:44,877 DEBUG [c.c.u.d.Upgrade410to420] (main:null) Added index 
i_alert__last_sent for table alert
2014-11-13 10:38:44,899 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop foreign key 
fk_external_dhcp_devices_nsp_id on table baremetal_dhcp_devices exception: 
Error on rename of './cloud/baremetal_dhcp_devices' to './cloud/#sql2-3aec-15' 
(errno: 152)
2014-11-13 10:38:44,931 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop foreign key 
fk_external_dhcp_devices_host_id on table baremetal_dhcp_devices exception: 
Error on rename of './cloud/baremetal_dhcp_devices' to './cloud/#sql2-3aec-15' 
(errno: 152)
2014-11-13 10:38:44,950 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop foreign key 
fk_external_dhcp_devices_pod_id on table baremetal_dhcp_devices exception: 
Error on rename of './cloud/baremetal_dhcp_devices' to './cloud/#sql2-3aec-15' 
(errno: 152)
2014-11-13 10:38:44,968 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop foreign key 
fk_external_dhcp_devices_physical_network_id on table baremetal_dhcp_devices 
exception: Error on rename of './cloud/baremetal_dhcp_devices' to 
'./cloud/#sql2-3aec-15' (errno: 152)
2014-11-13 10:38:45,000 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop foreign key 
fk_external_dhcp_devices_nsp_id on table baremetal_pxe_devices exception: Error 
on rename of './cloud/baremetal_pxe_devices' to './cloud/#sql2-3aec-15' (errno: 
152)
2014-11-13 10:38:45,017 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop foreign key 
fk_external_dhcp_devices_host_id on table baremetal_pxe_devices exception: 
Error on rename of './cloud/baremetal_pxe_devices' to './cloud/#sql2-3aec-15' 
(errno: 152)
2014-11-13 10:38:45,037 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop foreign key 
fk_external_dhcp_devices_pod_id on table baremetal_pxe_devices exception: Error 
on rename of './cloud/baremetal_pxe_devices' to './cloud/#sql2-3aec-15' (errno: 
152)
2014-11-13 10:38:45,058 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop foreign key 
fk_external_dhcp_devices_physical_network_id on table baremetal_pxe_devices 
exception: Error on rename of './cloud/baremetal_pxe_devices' to 
'./cloud/#sql2-3aec-15' (errno: 152)
2014-11-13 10:38:45,079 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop foreign key 
fk_external_pxe_devices_nsp_id on table baremetal_pxe_devices exception: Error 
on rename of './cloud/baremetal_pxe_devices' to './cloud/#sql2-3aec-15' (errno: 
152)
2014-11-13 10:38:45,097 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop foreign key 
fk_external_pxe_devices_host_id on table baremetal_pxe_devices exception: Error 
on rename of './cloud/baremetal_pxe_devices' to './cloud/#sql2-3aec-15' (errno: 
152)
2014-11-13 10:38:45,116 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop foreign key 
fk_external_pxe_devices_physical_network_id on table baremetal_pxe_devices 
exception: Error on rename of './cloud/baremetal_pxe_devices' to 
'./cloud/#sql2-3aec-15' (errno: 152)


was (Author: jayashreer):
I am seeing the following similar exception with the latest build.

2014-11-13 10:38:44,810 DEBUG [c.c.u.d.Upgrade410to420] (main:null) Done set 
KVM snapshot flag.
2014-11-13 10:38:44,810 DEBUG [c.c.u.d.Upgrade410to420] (main:null) Dropping 
index i_alert__last_sent if it exists
2014-11-13 10:38:44,835 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop key last_sent on table alert 
excep

[jira] [Updated] (CLOUDSTACK-6386) DB Exceptions while starting the Management server first time

2014-11-12 Thread Jayashree Ramamoorthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayashree Ramamoorthy updated CLOUDSTACK-6386:
--
Attachment: management-server.log

> DB Exceptions while starting the Management server first time 
> --
>
> Key: CLOUDSTACK-6386
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6386
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.4.0
>Reporter: Sailaja Mada
>Assignee: Damodar Reddy T
> Fix For: 4.4.0
>
> Attachments: management-server.log, management-server.log
>
>
> Steps:
> 1. Using Latest 4.4 and started Management server using 
> cloudstack-setup-management script 
> Observation: 
> Notice below DB exceptions.  This is not causing for any failure to start the 
> server. 
> 2014-04-11 16:21:24,430 DEBUG [c.c.u.d.Upgrade410to420] (main:null) Verify 
> and set the KVM snapshot flag if snapshot was used.
> 2014-04-11 16:21:24,431 DEBUG [c.c.u.d.Upgrade410to420] (main:null) Done set 
> KVM snapshot flag.
> 2014-04-11 16:21:24,431 DEBUG [c.c.u.d.Upgrade410to420] (main:null) Dropping 
> index i_alert__last_sent if it exists
> 2014-04-11 16:21:24,450 WARN  [c.c.u.d.DatabaseAccessObject] (main:null) 
> Ignored SQL Exception when trying to drop key last_sent on table alert
> com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Can't DROP 
> 'last_sent'; check that column/key exists
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
> at com.mysql.jdbc.Util.getInstance(Util.java:386)
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3597)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3529)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1990)
> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2151)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2625)
> at 
> com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2119)
> at 
> com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2415)
> at 
> com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2333)
> at 
> com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2318)
> at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105)
> at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105)
> at 
> com.cloud.upgrade.dao.DatabaseAccessObject.dropKey(DatabaseAccessObject.java:37)
> at 
> com.cloud.upgrade.dao.DbUpgradeUtils.dropKeysIfExist(DbUpgradeUtils.java:28)
> at 
> com.cloud.upgrade.dao.Upgrade410to420.addIndexForAlert(Upgrade410to420.java:543)
> at 
> com.cloud.upgrade.dao.Upgrade410to420.performDataMigration(Upgrade410to420.java:98)
> at 
> com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:310)
> at 
> com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:432)
> at 
> org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.checkIntegrity(CloudStackExtendedLifeCycle.java:65)
> at 
> org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:55)
> 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(AbstractApplicatio

[jira] [Commented] (CLOUDSTACK-6386) DB Exceptions while starting the Management server first time

2014-11-12 Thread Jayashree Ramamoorthy (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14209313#comment-14209313
 ] 

Jayashree Ramamoorthy commented on CLOUDSTACK-6386:
---

I am seeing the following similar exception with the latest build.

2014-11-13 10:38:44,810 DEBUG [c.c.u.d.Upgrade410to420] (main:null) Done set 
KVM snapshot flag.
2014-11-13 10:38:44,810 DEBUG [c.c.u.d.Upgrade410to420] (main:null) Dropping 
index i_alert__last_sent if it exists
2014-11-13 10:38:44,835 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop key last_sent on table alert 
exception: Can't DROP 'last_sent'; check that column/key exists
2014-11-13 10:38:44,836 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop key i_alert__last_sent on table alert 
exception: Can't DROP 'i_alert__last_sent'; check that column/key exists
2014-11-13 10:38:44,877 DEBUG [c.c.u.d.Upgrade410to420] (main:null) Added index 
i_alert__last_sent for table alert
2014-11-13 10:38:44,899 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop foreign key 
fk_external_dhcp_devices_nsp_id on table baremetal_dhcp_devices exception: 
Error on rename of './cloud/baremetal_dhcp_devices' to './cloud/#sql2-3aec-15' 
(errno: 152)
2014-11-13 10:38:44,931 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop foreign key 
fk_external_dhcp_devices_host_id on table baremetal_dhcp_devices exception: 
Error on rename of './cloud/baremetal_dhcp_devices' to './cloud/#sql2-3aec-15' 
(errno: 152)
2014-11-13 10:38:44,950 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop foreign key 
fk_external_dhcp_devices_pod_id on table baremetal_dhcp_devices exception: 
Error on rename of './cloud/baremetal_dhcp_devices' to './cloud/#sql2-3aec-15' 
(errno: 152)
2014-11-13 10:38:44,968 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop foreign key 
fk_external_dhcp_devices_physical_network_id on table baremetal_dhcp_devices 
exception: Error on rename of './cloud/baremetal_dhcp_devices' to 
'./cloud/#sql2-3aec-15' (errno: 152)
2014-11-13 10:38:45,000 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop foreign key 
fk_external_dhcp_devices_nsp_id on table baremetal_pxe_devices exception: Error 
on rename of './cloud/baremetal_pxe_devices' to './cloud/#sql2-3aec-15' (errno: 
152)
2014-11-13 10:38:45,017 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop foreign key 
fk_external_dhcp_devices_host_id on table baremetal_pxe_devices exception: 
Error on rename of './cloud/baremetal_pxe_devices' to './cloud/#sql2-3aec-15' 
(errno: 152)
2014-11-13 10:38:45,037 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop foreign key 
fk_external_dhcp_devices_pod_id on table baremetal_pxe_devices exception: Error 
on rename of './cloud/baremetal_pxe_devices' to './cloud/#sql2-3aec-15' (errno: 
152)
2014-11-13 10:38:45,058 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop foreign key 
fk_external_dhcp_devices_physical_network_id on table baremetal_pxe_devices 
exception: Error on rename of './cloud/baremetal_pxe_devices' to 
'./cloud/#sql2-3aec-15' (errno: 152)
2014-11-13 10:38:45,079 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop foreign key 
fk_external_pxe_devices_nsp_id on table baremetal_pxe_devices exception: Error 
on rename of './cloud/baremetal_pxe_devices' to './cloud/#sql2-3aec-15' (errno: 
152)
2014-11-13 10:38:45,097 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop foreign key 
fk_external_pxe_devices_host_id on table baremetal_pxe_devices exception: Error 
on rename of './cloud/baremetal_pxe_devices' to './cloud/#sql2-3aec-15' (errno: 
152)
2014-11-13 10:38:45,116 DEBUG [c.c.u.d.DatabaseAccessObject] (main:null) 
Ignored SQL Exception when trying to drop foreign key 
fk_external_pxe_devices_physical_network_id on table baremetal_pxe_devices 
exception: Error on rename of './cloud/baremetal_pxe_devices' to 
'./cloud/#sql2-3aec-15' (errno: 152)

> DB Exceptions while starting the Management server first time 
> --
>
> Key: CLOUDSTACK-6386
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6386
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.4.0
>Reporter: Sailaja Mada
>Assignee: Damodar Reddy T
> Fix For: 4.4.0
>
>

[jira] [Closed] (CLOUDSTACK-7898) Add properties file in same folder as template

2014-11-12 Thread Mike Tutkowski (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Tutkowski closed CLOUDSTACK-7898.
--

> Add properties file in same folder as template
> --
>
> Key: CLOUDSTACK-7898
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7898
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: XenServer
>Affects Versions: 4.5.0, 4.6.0
> Environment: Ubuntu 12.04.1 for CloudStack Management Server
> XenServer 6.2 (using 6.2.5 resource code)
>Reporter: Mike Tutkowski
>Assignee: Mike Tutkowski
> Fix For: 4.5.0, 4.6.0
>
>
> The XenServer 6.2.5 resource code does not generate a properties file for a 
> template that is created from a snapshot.
> Without this properties file, if any management server is re-started, the 
> template in question will no longer be usable (its applicable row in the 
> cloud.template_store_ref table gets removed).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CLOUDSTACK-7898) Add properties file in same folder as template

2014-11-12 Thread Mike Tutkowski (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Tutkowski resolved CLOUDSTACK-7898.

Resolution: Fixed

> Add properties file in same folder as template
> --
>
> Key: CLOUDSTACK-7898
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7898
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: XenServer
>Affects Versions: 4.5.0, 4.6.0
> Environment: Ubuntu 12.04.1 for CloudStack Management Server
> XenServer 6.2 (using 6.2.5 resource code)
>Reporter: Mike Tutkowski
>Assignee: Mike Tutkowski
> Fix For: 4.5.0, 4.6.0
>
>
> The XenServer 6.2.5 resource code does not generate a properties file for a 
> template that is created from a snapshot.
> Without this properties file, if any management server is re-started, the 
> template in question will no longer be usable (its applicable row in the 
> cloud.template_store_ref table gets removed).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7898) Add properties file in same folder as template

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14209278#comment-14209278
 ] 

ASF subversion and git services commented on CLOUDSTACK-7898:
-

Commit 8b7c1d7c5e1d7b4396c57d4cf20b24217335bc8e in cloudstack's branch 
refs/heads/4.5 from [~mike-tutkowski]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8b7c1d7 ]

CLOUDSTACK-7898: Add properties file in same folder as template

> Add properties file in same folder as template
> --
>
> Key: CLOUDSTACK-7898
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7898
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: XenServer
>Affects Versions: 4.5.0, 4.6.0
> Environment: Ubuntu 12.04.1 for CloudStack Management Server
> XenServer 6.2 (using 6.2.5 resource code)
>Reporter: Mike Tutkowski
>Assignee: Mike Tutkowski
> Fix For: 4.5.0, 4.6.0
>
>
> The XenServer 6.2.5 resource code does not generate a properties file for a 
> template that is created from a snapshot.
> Without this properties file, if any management server is re-started, the 
> template in question will no longer be usable (its applicable row in the 
> cloud.template_store_ref table gets removed).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-6407) NPE while collecting VM statistics

2014-11-12 Thread Jayashree Ramamoorthy (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14209277#comment-14209277
 ] 

Jayashree Ramamoorthy commented on CLOUDSTACK-6407:
---

Issue not seen with the latest build. 

> NPE while collecting VM statistics 
> ---
>
> Key: CLOUDSTACK-6407
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6407
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.4.0
>Reporter: Sailaja Mada
>Assignee: Damodar Reddy T
> Fix For: 4.4.0
>
> Attachments: management-server.log
>
>
> Setup : 4.4 with XenServer 6.2.5 
> 1. Install and configure Adv zone using XenServer 6.2.5 
> 2. Deployed 2 Windows (8 and 2012) VM's using Domain user account .
> Observed NPE's while collecting VM statistics in the Management server 
> log(Attached)
> 2014-04-15 00:00:49,574 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-4:ctx-2e085056) VmStatsCollector is running...
> 2014-04-15 00:00:49,588 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-69:ctx-9a19b721) Seq 1-6476457739135503930: Executing request
> 2014-04-15 00:00:49,618 WARN  [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-69:ctx-9a19b721) Seq 1-6476457739135503930: Exception Caught 
> while executing command
> java.lang.NullPointerException
> 2014-04-15 00:00:49,619 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-69:ctx-9a19b721) Seq 1-6476457739135503930: Response Received:
> 2014-04-15 00:00:49,619 DEBUG [c.c.a.t.Request] (DirectAgent-69:ctx-9a19b721) 
> Seq 1-6476457739135503930: Processing:  { Ans: , MgmtId: 55355881446856, via: 
> 1, Ver: v1, Flags: 10, 
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"java.lang.NullPointerException","wait":0}}]
>  }
> 2014-04-15 00:00:49,619 DEBUG [c.c.a.t.Request] 
> (StatsCollector-4:ctx-2e085056) Seq 1-6476457739135503930: Received:  { Ans: 
> , MgmtId: 55355881446856, via: 1, Ver: v1, Flags: 10, { Answer } }
> 2014-04-15 00:00:49,619 DEBUG [c.c.a.m.AgentManagerImpl] 
> (StatsCollector-4:ctx-2e085056) Details from executing class 
> com.cloud.agent.api.GetVmStatsCommand: java.lang.NullPointerException
> 2014-04-15 00:00:49,619 WARN  [c.c.v.UserVmManagerImpl] 
> (StatsCollector-4:ctx-2e085056) Unable to obtain VM statistics.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (CLOUDSTACK-7724) [Automation][HyperV] Unable to migrate VM due to JsonParseException: The JsonDeserializer EnumTypeAdapter failed to deserialize json object "Running"

2014-11-12 Thread Devdeep Singh (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Devdeep Singh closed CLOUDSTACK-7724.
-

> [Automation][HyperV] Unable to migrate VM due to JsonParseException: The 
> JsonDeserializer EnumTypeAdapter failed to deserialize json object "Running"
> -
>
> Key: CLOUDSTACK-7724
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7724
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Devdeep Singh
>Priority: Critical
> Fix For: 4.5.0
>
>
> =
> JsonParseException: The JsonDeserializer EnumTypeAdapter failed to 
> deserialize json object "Running"
> =
> 2014-10-14 19:34:47,983 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-65:ctx-81e9b15c job-191/job-192 ctx-b908f714) Seq 
> 1-5051068457072722114: Sending  { Cmd , MgmtId: 192182403311206, via: 
> 1(10.81.56.124), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.CheckVirtualMachineCommand":{"vmName":"i-16-36-VM","wait":20}}]
>  }
> 2014-10-14 19:34:47,983 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-65:ctx-81e9b15c job-191/job-192 ctx-b908f714) Seq 
> 1-5051068457072722114: Executing:  { Cmd , MgmtId: 192182403311206, via: 
> 1(10.81.56.124), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.CheckVirtualMachineCommand":{"vmName":"i-16-36-VM","wait":20}}]
>  }
> 2014-10-14 19:34:47,983 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-110:ctx-409b4476) Seq 1-5051068457072722114: Executing request
> 2014-10-14 19:34:47,984 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
> (DirectAgent-110:ctx-409b4476) POST request to 
> https://10.81.56.124:8250/api/HypervResource/com.cloud.agent.api.CheckVirtualMachineCommand
>  with contents 
> {"vmName":"i-16-36-VM","contextMap":{"job":"job-191/job-192"},"wait":20}
> 2014-10-14 19:34:47,990 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
> (DirectAgent-110:ctx-409b4476) Sending cmd to 
> https://10.81.56.124:8250/api/HypervResource/com.cloud.agent.api.CheckVirtualMachineCommand
>  cmd 
> data:{"vmName":"i-16-36-VM","contextMap":{"job":"job-191/job-192"},"wait":20}
> 2014-10-14 19:34:48,099 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
> (DirectAgent-110:ctx-409b4476) POST response is 
> [{"com.cloud.agent.api.CheckVirtualMachineAnswer":{"result":true,"details":null,"state":"Running","contextMap":{}}}]
> 2014-10-14 19:34:48,148 WARN  [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-110:ctx-409b4476) Seq 1-5051068457072722114: Throwable caught 
> while executing command
> com.google.gson.JsonParseException: The JsonDeserializer EnumTypeAdapter 
> failed to deserialize json object "Running" given the type class 
> com.cloud.vm.VirtualMachine$PowerState
>   at 
> com.google.gson.JsonDeserializerExceptionWrapper.deserialize(JsonDeserializerExceptionWrapper.java:64)
>   at 
> com.google.gson.JsonDeserializationVisitor.invokeCustomDeserializer(JsonDeserializationVisitor.java:92)
>   at 
> com.google.gson.JsonObjectDeserializationVisitor.visitFieldUsingCustomHandler(JsonObjectDeserializationVisitor.java:117)
>   at 
> com.google.gson.ReflectingFieldNavigator.visitFieldsReflectively(ReflectingFieldNavigator.java:63)
>   at com.google.gson.ObjectNavigator.accept(ObjectNavigator.java:120)
>   at 
> com.google.gson.JsonDeserializationContextDefault.fromJsonObject(JsonDeserializationContextDefault.java:76)
>   at 
> com.google.gson.JsonDeserializationContextDefault.deserialize(JsonDeserializationContextDefault.java:54)
>   at com.google.gson.Gson.fromJson(Gson.java:551)
>   at com.google.gson.Gson.fromJson(Gson.java:521)
>   at 
> com.cloud.agent.transport.ArrayTypeAdaptor.deserialize(ArrayTypeAdaptor.java:80)
>   at 
> com.cloud.agent.transport.ArrayTypeAdaptor.deserialize(ArrayTypeAdaptor.java:40)
>   at 
> com.google.gson.JsonDeserializerExceptionWrapper.deserialize(JsonDeserializerExceptionWrapper.java:51)
>   at 
> com.google.gson.JsonDeserializationVisitor.invokeCustomDeserializer(JsonDeserializationVisitor.java:92)
>   at 
> com.google.gson.JsonDeserializationVisitor.visitUsingCustomHandler(JsonDeserializationVisitor.java:80)
>   at com.google.gson.ObjectNavigator.accept(ObjectNavigator.java:101)
>   at 
> com.google.gson.JsonDeserializationContextDefault.fromJsonArray(JsonDeserializationContextDefault.java:67)
>   at 
> com.google.gson.JsonDeserializationContextDefault.deserialize(JsonDeserializationContextDefault.jav

[jira] [Assigned] (CLOUDSTACK-7898) Add properties file in same folder as template

2014-11-12 Thread Mike Tutkowski (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Tutkowski reassigned CLOUDSTACK-7898:
--

Assignee: Mike Tutkowski

> Add properties file in same folder as template
> --
>
> Key: CLOUDSTACK-7898
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7898
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: XenServer
>Affects Versions: 4.5.0, 4.6.0
> Environment: Ubuntu 12.04.1 for CloudStack Management Server
> XenServer 6.2 (using 6.2.5 resource code)
>Reporter: Mike Tutkowski
>Assignee: Mike Tutkowski
> Fix For: 4.5.0, 4.6.0
>
>
> The XenServer 6.2.5 resource code does not generate a properties file for a 
> template that is created from a snapshot.
> Without this properties file, if any management server is re-started, the 
> template in question will no longer be usable (its applicable row in the 
> cloud.template_store_ref table gets removed).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7898) Add properties file in same folder as template

2014-11-12 Thread Mike Tutkowski (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14209262#comment-14209262
 ] 

Mike Tutkowski commented on CLOUDSTACK-7898:


Code for 4.6 checked in under SHA 5c388a5c8087d544ff89dccf20f8af88f8f73d1b.

> Add properties file in same folder as template
> --
>
> Key: CLOUDSTACK-7898
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7898
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: XenServer
>Affects Versions: 4.5.0, 4.6.0
> Environment: Ubuntu 12.04.1 for CloudStack Management Server
> XenServer 6.2 (using 6.2.5 resource code)
>Reporter: Mike Tutkowski
>Assignee: Mike Tutkowski
> Fix For: 4.5.0, 4.6.0
>
>
> The XenServer 6.2.5 resource code does not generate a properties file for a 
> template that is created from a snapshot.
> Without this properties file, if any management server is re-started, the 
> template in question will no longer be usable (its applicable row in the 
> cloud.template_store_ref table gets removed).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-7898) Add properties file in same folder as template

2014-11-12 Thread Mike Tutkowski (JIRA)
Mike Tutkowski created CLOUDSTACK-7898:
--

 Summary: Add properties file in same folder as template
 Key: CLOUDSTACK-7898
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7898
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: XenServer
Affects Versions: 4.5.0, 4.6.0
 Environment: Ubuntu 12.04.1 for CloudStack Management Server
XenServer 6.2 (using 6.2.5 resource code)
Reporter: Mike Tutkowski
 Fix For: 4.5.0, 4.6.0


The XenServer 6.2.5 resource code does not generate a properties file for a 
template that is created from a snapshot.

Without this properties file, if any management server is re-started, the 
template in question will no longer be usable (its applicable row in the 
cloud.template_store_ref table gets removed).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-7897) [Automation] Fix the script "test_reset_ssh_keypair.py" - Test Cases failing on Simulator as Testcases try to ssh to the VMs

2014-11-12 Thread Chandan Purushothama (JIRA)
Chandan Purushothama created CLOUDSTACK-7897:


 Summary: [Automation] Fix the script "test_reset_ssh_keypair.py" - 
 Test Cases failing on Simulator as Testcases try to ssh to the VMs
 Key: CLOUDSTACK-7897
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7897
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Chandan Purushothama
 Fix For: 4.5.0


Test Cases are trying to validate SSH access and failing. These Test Cases are 
not meant to be run on SImulator due to their validation requirements. Hence 
they cannot be run with Simulator



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (CLOUDSTACK-7814) No default SSL keystore result in upgrade failure

2014-11-12 Thread Sheng Yang (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sheng Yang closed CLOUDSTACK-7814.
--

> No default SSL keystore result in upgrade failure
> -
>
> Key: CLOUDSTACK-7814
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7814
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.0
>Reporter: Sheng Yang
>Assignee: Sheng Yang
>Priority: Blocker
> Fix For: 4.5.0
>
>
> Currently, after upgrade to 4.5, no agent can connect to mgmt server.
> It's due to:
> commit 918c320438980f070150f872e3a3ba907572af83
> Author: Upendra Moturi 
> Date: Fri Jun 20 11:41:58 2014 +0530
> CLOUDSTACK-6847.Link.java and console proxy files have hardcoded value
> This commit meant to use more flex password for keystore, but they didn't set 
> default value for it. So when upgrade, db.properities which suppose have the 
> password is empty, the decryption of SSL keystore would fail.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (CLOUDSTACK-7896) UI > network > Add Guest Network > when zone dropdown is empty, do not make API call to get physical networks.

2014-11-12 Thread Jessica Wang (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jessica Wang closed CLOUDSTACK-7896.


> UI > network > Add Guest Network > when zone dropdown is empty, do not make 
> API call to get physical networks.
> --
>
> Key: CLOUDSTACK-7896
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7896
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Jessica Wang
>Assignee: Jessica Wang
>Priority: Critical
> Fix For: 4.5.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CLOUDSTACK-7896) UI > network > Add Guest Network > when zone dropdown is empty, do not make API call to get physical networks.

2014-11-12 Thread Jessica Wang (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jessica Wang resolved CLOUDSTACK-7896.
--
Resolution: Fixed

> UI > network > Add Guest Network > when zone dropdown is empty, do not make 
> API call to get physical networks.
> --
>
> Key: CLOUDSTACK-7896
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7896
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Jessica Wang
>Assignee: Jessica Wang
>Priority: Critical
> Fix For: 4.5.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7896) UI > network > Add Guest Network > when zone dropdown is empty, do not make API call to get physical networks.

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208980#comment-14208980
 ] 

ASF subversion and git services commented on CLOUDSTACK-7896:
-

Commit 9809164654159fd1cea4842d76a6a0b97fc72e54 in cloudstack's branch 
refs/heads/4.5 from [~jessicawang]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9809164 ]

CLOUDSTACK-7896: UI > network > Add Guest Network > when zone dropdown is 
empty, do not make API call to get physical networks.


> UI > network > Add Guest Network > when zone dropdown is empty, do not make 
> API call to get physical networks.
> --
>
> Key: CLOUDSTACK-7896
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7896
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Jessica Wang
>Assignee: Jessica Wang
>Priority: Critical
> Fix For: 4.5.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7896) UI > network > Add Guest Network > when zone dropdown is empty, do not make API call to get physical networks.

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208978#comment-14208978
 ] 

ASF subversion and git services commented on CLOUDSTACK-7896:
-

Commit 5d094e5cab94ccf1804a830a39ae4dc4d563f434 in cloudstack's branch 
refs/heads/master from [~jessicawang]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5d094e5 ]

CLOUDSTACK-7896: UI > network > Add Guest Network > when zone dropdown is 
empty, do not make API call to get physical networks.


> UI > network > Add Guest Network > when zone dropdown is empty, do not make 
> API call to get physical networks.
> --
>
> Key: CLOUDSTACK-7896
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7896
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Jessica Wang
>Assignee: Jessica Wang
>Priority: Critical
> Fix For: 4.5.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CLOUDSTACK-7887) fail to push snapshot to secondary storage if using multipart using swift

2014-11-12 Thread Pierre-Luc Dion (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre-Luc Dion resolved CLOUDSTACK-7887.
-
   Resolution: Fixed
Fix Version/s: 4.5.0

> fail to push snapshot to secondary storage if using multipart using swift
> -
>
> Key: CLOUDSTACK-7887
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7887
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Hypervisor Controller, XenServer
>Affects Versions: 4.4.0, 4.4.1
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
> Fix For: 4.5.0
>
>
> Using Swift as secondary storage with XenServer,  creating a snapshot from a 
> big disk  will display as succeed in CloudStack but the snapshot file will 
> fail to upload in Swift.  So snapshot are not working for Swift with 
> XenServer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CLOUDSTACK-7887) fail to push snapshot to secondary storage if using multipart using swift

2014-11-12 Thread Pierre-Luc Dion (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre-Luc Dion updated CLOUDSTACK-7887:

Status: Reviewable  (was: In Progress)

> fail to push snapshot to secondary storage if using multipart using swift
> -
>
> Key: CLOUDSTACK-7887
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7887
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Hypervisor Controller, XenServer
>Affects Versions: 4.4.0, 4.4.1
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>
> Using Swift as secondary storage with XenServer,  creating a snapshot from a 
> big disk  will display as succeed in CloudStack but the snapshot file will 
> fail to upload in Swift.  So snapshot are not working for Swift with 
> XenServer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7887) fail to push snapshot to secondary storage if using multipart using swift

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208976#comment-14208976
 ] 

ASF subversion and git services commented on CLOUDSTACK-7887:
-

Commit 5306e43d562ba4a4590ce24215fe45e2248d5bfc in cloudstack's branch 
refs/heads/master from [~pdion]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5306e43 ]

CLOUDSTACK-7887: change int to str into swiftxen


> fail to push snapshot to secondary storage if using multipart using swift
> -
>
> Key: CLOUDSTACK-7887
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7887
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Hypervisor Controller, XenServer
>Affects Versions: 4.4.0, 4.4.1
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>
> Using Swift as secondary storage with XenServer,  creating a snapshot from a 
> big disk  will display as succeed in CloudStack but the snapshot file will 
> fail to upload in Swift.  So snapshot are not working for Swift with 
> XenServer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7887) fail to push snapshot to secondary storage if using multipart using swift

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208977#comment-14208977
 ] 

ASF subversion and git services commented on CLOUDSTACK-7887:
-

Commit 6c955a3a472da1308a5336a48b29514b78c543e4 in cloudstack's branch 
refs/heads/4.5 from [~pdion]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6c955a3 ]

CLOUDSTACK-7887: change int to str into swiftxen


> fail to push snapshot to secondary storage if using multipart using swift
> -
>
> Key: CLOUDSTACK-7887
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7887
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Hypervisor Controller, XenServer
>Affects Versions: 4.4.0, 4.4.1
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>
> Using Swift as secondary storage with XenServer,  creating a snapshot from a 
> big disk  will display as succeed in CloudStack but the snapshot file will 
> fail to upload in Swift.  So snapshot are not working for Swift with 
> XenServer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7887) fail to push snapshot to secondary storage if using multipart using swift

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208974#comment-14208974
 ] 

ASF subversion and git services commented on CLOUDSTACK-7887:
-

Commit 9cbd36515c093f2c850750708d927afff3c317ea in cloudstack's branch 
refs/heads/hotfix/CLOUDSTACK-7887 from [~pdion]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9cbd365 ]

CLOUDSTACK-7887: change int to str into swiftxen


> fail to push snapshot to secondary storage if using multipart using swift
> -
>
> Key: CLOUDSTACK-7887
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7887
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Hypervisor Controller, XenServer
>Affects Versions: 4.4.0, 4.4.1
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>
> Using Swift as secondary storage with XenServer,  creating a snapshot from a 
> big disk  will display as succeed in CloudStack but the snapshot file will 
> fail to upload in Swift.  So snapshot are not working for Swift with 
> XenServer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-7896) UI > network > Add Guest Network > when zone dropdown is empty, do not make API call to get physical networks.

2014-11-12 Thread Jessica Wang (JIRA)
Jessica Wang created CLOUDSTACK-7896:


 Summary: UI > network > Add Guest Network > when zone dropdown is 
empty, do not make API call to get physical networks.
 Key: CLOUDSTACK-7896
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7896
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Reporter: Jessica Wang
Assignee: Jessica Wang
Priority: Critical
 Fix For: 4.5.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7788) [Automation][Simulator] Fix the script "test_dynamic_compute_offering.py" - Test Cases failing on Simulator due to hardware resources requirement for test executio

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208930#comment-14208930
 ] 

ASF subversion and git services commented on CLOUDSTACK-7788:
-

Commit 81e03c4c31e46f5162667d8be5076bd8e6221436 in cloudstack's branch 
refs/heads/master from [~chandanp]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=81e03c4 ]

CLOUDSTACK-7788: Fixed the script 'test_dynamic_compute_offering.py' to be run 
only on hardware


> [Automation][Simulator] Fix the script "test_dynamic_compute_offering.py" - 
> Test Cases failing on Simulator due to hardware resources requirement for 
> test execution
> 
>
> Key: CLOUDSTACK-7788
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7788
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Chandan Purushothama
> Fix For: 4.5.0
>
>
> Test Cases are trying to perform operations that can only be done on hardware 
> and supported hypervisors. These Test Cases are not meant to be run on 
> SImulator due to their validation requirements. Hence they cannot be run with 
> Simulator



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7786) [Automation][Simulator] Fix the script "test_haproxy.py" - Test Cases failing on Simulator due to hardware resources requirement for test execution

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208928#comment-14208928
 ] 

ASF subversion and git services commented on CLOUDSTACK-7786:
-

Commit 540687c3924e9e563c09f9fc100e90c7cbb01794 in cloudstack's branch 
refs/heads/master from [~chandanp]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=540687c ]

CLOUDSTACK-7786: Fixed the script 'test_haproxy.py' to be run only on hardware


> [Automation][Simulator] Fix the script "test_haproxy.py" - Test Cases failing 
> on Simulator due to hardware resources requirement for test execution
> ---
>
> Key: CLOUDSTACK-7786
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7786
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Chandan Purushothama
> Fix For: 4.5.0
>
>
> Test Cases are trying to validate SSH access and failing. These Test Cases 
> are not meant to be run on SImulator due to their validation requirements. 
> Hence they cannot be run with Simulator



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7787) [Automation][Simulator] Fix the script "test_lb_secondary_ip.py" - Test Cases failing on Simulator due to hardware resources requirement for test execution

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208929#comment-14208929
 ] 

ASF subversion and git services commented on CLOUDSTACK-7787:
-

Commit 57f66422342f098db0a8442264be53fecf4b0ae7 in cloudstack's branch 
refs/heads/master from [~chandanp]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=57f6642 ]

CLOUDSTACK-7787: Fixed the script 'test_lb_secondary_ip.py' to be run only on 
hardware


> [Automation][Simulator] Fix the script "test_lb_secondary_ip.py" - Test Cases 
> failing on Simulator due to hardware resources requirement for test execution
> ---
>
> Key: CLOUDSTACK-7787
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7787
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Chandan Purushothama
> Fix For: 4.5.0
>
>
> Test Cases are trying to validate SSH access and failing. These Test Cases 
> are not meant to be run on SImulator due to their validation requirements. 
> Hence they cannot be run with Simulator



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7811) [Automation][Simulator] Fix the script "test_persistent_networks.py" - Test Cases failing on Simulator due to hardware resources requirement for test execution

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208907#comment-14208907
 ] 

ASF subversion and git services commented on CLOUDSTACK-7811:
-

Commit 172a0b7ee049b86407d513e7aaf2e74bc0a1a547 in cloudstack's branch 
refs/heads/master from [~chandanp]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=172a0b7 ]

CLOUDSTACK-7811: Fixed the script 'test_persistent_networks.py' - Test Cases 
failing on Simulator due to hardware resources requirement for test execution


> [Automation][Simulator] Fix the script "test_persistent_networks.py" - Test 
> Cases failing on Simulator due to hardware resources requirement for test 
> execution
> ---
>
> Key: CLOUDSTACK-7811
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7811
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Chandan Purushothama
> Fix For: 4.5.0
>
>
> Test Cases are trying to validate SSH access and failing. These Test Cases 
> are not meant to be run on SImulator due to their validation requirements. 
> Hence they cannot be run with Simulator



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7812) [Automation][Simulator] Fix the script "maint/test_redundant_router_network_rules.py" - Test Cases failing on Simulator due to hardware resources requirement for t

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208903#comment-14208903
 ] 

ASF subversion and git services commented on CLOUDSTACK-7812:
-

Commit f416c82f012dd5497b548dd89d26d0366b96778c in cloudstack's branch 
refs/heads/master from [~chandanp]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f416c82 ]

CLOUDSTACK-7812: Fixed the script 
'maint/test_redundant_router_network_rules.py' - Test Cases failing on 
Simulator due to hardware resources requirement for test execution


> [Automation][Simulator] Fix the script 
> "maint/test_redundant_router_network_rules.py" - Test Cases failing on 
> Simulator due to hardware resources requirement for test execution
> 
>
> Key: CLOUDSTACK-7812
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7812
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Chandan Purushothama
> Fix For: 4.5.0
>
>
> Test Cases are trying to validate SSH access and failing. These Test Cases 
> are not meant to be run on SImulator due to their validation requirements. 
> Hence they cannot be run with Simulator



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (CLOUDSTACK-7600) [Automation] VM Failed to Start due to ConcurrentOperationException - Unable to change the state of Virtual Router

2014-11-12 Thread Prachi Damle (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Prachi Damle reassigned CLOUDSTACK-7600:


Assignee: Sheng Yang  (was: Prachi Damle)

> [Automation] VM Failed to Start due to ConcurrentOperationException - Unable 
> to change the state of Virtual Router
> --
>
> Key: CLOUDSTACK-7600
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7600
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test, Virtual Router
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Sheng Yang
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.zip
>
>
> *ConcurrentOperationException: Unable to change the state of VM*
> {noformat}
> 2014-09-21 14:38:20,648 ERROR [c.c.v.VirtualMachineManagerImpl] 
> (Work-Job-Executor-65:ctx-cfa1f316 job-1953/job-1954 ctx-6fd40296) Failed to 
> start instance VM[User|i-115-279-VM]
> com.cloud.exception.ConcurrentOperationException: Unable to change the state 
> of VM[DomainRouter|r-271-VM]
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.changeToStartState(VirtualMachineManagerImpl.java:717)
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:808)
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:762)
>   at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.start(VirtualNetworkApplianceManagerImpl.java:2981)
>   at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startVirtualRouter(VirtualNetworkApplianceManagerImpl.java:2055)
>   at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startRouters(VirtualNetworkApplianceManagerImpl.java:2155)
>   at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.deployVirtualRouterInGuestNetwork(VirtualNetworkApplianceManagerImpl.java:2137)
>   at sun.reflect.GeneratedMethodAccessor335.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
>   at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>   at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
>   at $Proxy190.deployVirtualRouterInGuestNetwork(Unknown Source)
>   at 
> com.cloud.network.element.VirtualRouterElement.prepare(VirtualRouterElement.java:234)
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareElement(NetworkOrchestrator.java:1239)
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNic(NetworkOrchestrator.java:1373)
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1309)
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:970)
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4590)
>   at sun.reflect.GeneratedMethodAccessor379.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4746)
>   at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
>   at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:516)
>   at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
>   at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
>   at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
>   at 
> org.apache.cloudstack.managed.con

[jira] [Commented] (CLOUDSTACK-7600) [Automation] VM Failed to Start due to ConcurrentOperationException - Unable to change the state of Virtual Router

2014-11-12 Thread Prachi Damle (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208905#comment-14208905
 ] 

Prachi Damle commented on CLOUDSTACK-7600:
--

Sheng: 

1) CCP put the router in 'Stopping' state at 2014-09-21 14:38:16,507

2014-09-21 14:38:16,507 DEBUG [c.c.c.CapacityManagerImpl] 
(Work-Job-Executor-52:ctx-303ddf98 job-1949/job-1950 ctx-e9802705) VM state 
transitted from :Running to Stopping with event: StopRequestedvm's original 
host id: 1 new host id: 1 host id before state transition: 1

2) The Deploy VM job locked the same network and decided to start this router 
at 2014-09-21 14:38:20,596

2014-09-21 14:38:20,595 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
(Work-Job-Executor-65:ctx-cfa1f316 job-1953/job-1954 ctx-6fd40296) Lock is 
released for network id 327 as a part of router startup in 
Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] 
: Dest[Zone(1)-Pod(1)-Cluster(1)-Host(2)-Storage(Volume(283|ROOT-->Pool(1))]
2014-09-21 14:38:20,596 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
(Work-Job-Executor-65:ctx-cfa1f316 job-1953/job-1954 ctx-6fd40296) Starting 
router VM[DomainRouter|r-271-VM]

3) Why does CCP choose to start the same router that is in 'Stopping' state. Do 
we not load the fresh DB state at this point and check before starting the same 
router?

> [Automation] VM Failed to Start due to ConcurrentOperationException - Unable 
> to change the state of Virtual Router
> --
>
> Key: CLOUDSTACK-7600
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7600
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test, Virtual Router
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Prachi Damle
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.zip
>
>
> *ConcurrentOperationException: Unable to change the state of VM*
> {noformat}
> 2014-09-21 14:38:20,648 ERROR [c.c.v.VirtualMachineManagerImpl] 
> (Work-Job-Executor-65:ctx-cfa1f316 job-1953/job-1954 ctx-6fd40296) Failed to 
> start instance VM[User|i-115-279-VM]
> com.cloud.exception.ConcurrentOperationException: Unable to change the state 
> of VM[DomainRouter|r-271-VM]
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.changeToStartState(VirtualMachineManagerImpl.java:717)
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:808)
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:762)
>   at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.start(VirtualNetworkApplianceManagerImpl.java:2981)
>   at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startVirtualRouter(VirtualNetworkApplianceManagerImpl.java:2055)
>   at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startRouters(VirtualNetworkApplianceManagerImpl.java:2155)
>   at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.deployVirtualRouterInGuestNetwork(VirtualNetworkApplianceManagerImpl.java:2137)
>   at sun.reflect.GeneratedMethodAccessor335.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
>   at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>   at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
>   at $Proxy190.deployVirtualRouterInGuestNetwork(Unknown Source)
>   at 
> com.cloud.network.element.VirtualRouterElement.prepare(VirtualRouterElement.java:234)
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareElement(NetworkOrchestrator.java:1239)
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNic(NetworkOrchestrator.java:1373)
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1309)
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.orchestr

[jira] [Comment Edited] (CLOUDSTACK-7600) [Automation] VM Failed to Start due to ConcurrentOperationException - Unable to change the state of Virtual Router

2014-11-12 Thread Prachi Damle (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208884#comment-14208884
 ] 

Prachi Damle edited comment on CLOUDSTACK-7600 at 11/12/14 11:38 PM:
-

There is a StopRouter API called by Admin simultaneous to the userVm deployment 
API.

The StopRouter has already processed and put the router in stopping state:

2014-09-21 14:38:15,627 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-86:ctx-a051db6f job-1949) Executing AsyncJobVO {id:1949, 
userId: 2, accountId: 2, instanceType: DomainRouter, instanceId: 271, cmd: 
org.apache.cloudstack.api.command.admin.router.StopRouterCmd, cmdInfo: 
{"id":"c731662f-d109-4295-8d07-383f84f93d31","response":"json","ctxDetails":"{\"com.cloud.vm.VirtualMachine\":\"c731662f-d109-4295-8d07-383f84f93d31\"}","cmdEventType":"ROUTER.STOP","ctxUserId":"2","httpmethod":"GET","uuid":"c731662f-d109-4295-8d07-383f84f93d31","ctxAccountId":"2","ctxStartEventId":"6330","apiKey":"mLrTCdYRf3-d4xO7DnO-QXw1Uqrdae1uxenHTEPj_ulDpIYTaujsXwkNzARz222s6M4xChsTAE2W-TUur5bKNQ","signature":"bGbFrU0IuNAt0/Z0jzShaop19Ts\u003d"},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 16226561876200, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}

2014-09-21 14:38:15,649 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
(API-Job-Executor-86:ctx-a051db6f job-1949 ctx-d59b1c33) Stopping router 
VM[DomainRouter|r-271-VM]
2014-09-21 14:38:15,654 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-86:ctx-a051db6f job-1949 ctx-d59b1c33) Sync job-1950 
execution on object VmWorkJobQueue.271

2014-09-21 14:38:15,654 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-86:ctx-a051db6f job-1949 ctx-d59b1c33) Sync job-1950 
execution on object VmWorkJobQueue.271

2014-09-21 14:38:16,507 DEBUG [c.c.c.CapacityManagerImpl] 
(Work-Job-Executor-52:ctx-303ddf98 job-1949/job-1950 ctx-e9802705) VM state 
transitted from :Running to Stopping with event: StopRequestedvm's original 
host id: 1 new host id: 1 host id before state transition: 1

 2014-09-21 14:38:29,785 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
(Work-Job-Executor-52:ctx-303ddf98 job-1949/job-1950 ctx-e9802705) Asking 
VirtualRouter to release 
NicProfile[551-271-6596e782-c753-4d66-ae70-4828b0e7a03e-10.1.1.1-null
2014-09-21 14:38:29,815 DEBUG [c.c.v.VirtualMachineManagerImpl] 
(Work-Job-Executor-52:ctx-303ddf98 job-1949/job-1950 ctx-e9802705) Successfully 
released network resources for the vm VM[DomainRouter|r-271-VM]
2014-09-21 14:38:29,815 DEBUG [c.c.v.VirtualMachineManagerImpl] 
(Work-Job-Executor-52:ctx-303ddf98 job-1949/job-1950 ctx-e9802705) Successfully 
released storage resources for the vm VM[DomainRouter|r-271-VM]
2014-09-21 14:38:29,824 DEBUG [c.c.c.CapacityManagerImpl] 
(Work-Job-Executor-52:ctx-303ddf98 job-1949/job-1950 ctx-e9802705) VM state 
transitted from :Stopping to Stopped with event: OperationSucceededvm's 
original host id: 1 new host id: null host id before state transition: 1
2014-09-21 14:38:29,845 DEBUG [c.c.v.VmWorkJobHandlerProxy] 
(Work-Job-Executor-52:ctx-303ddf98 job-1949/job-1950 ctx-e9802705) Done 
executing VM work job: 
com.cloud.vm.VmWorkStop{"cleanup":false,"userId":2,"accountId":2,"vmId":271,"handlerName":"VirtualMachineManagerImpl"}




was (Author: prachidamle):
There is a StopRouter API called by Admin simultaneous to the userVm deployment 
API.

The StopRouter has already processed and put the router in stopping state:

2014-09-21 14:38:15,627 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-86:ctx-a051db6f job-1949) Executing AsyncJobVO {id:1949, 
userId: 2, accountId: 2, instanceType: DomainRouter, instanceId: 271, cmd: 
org.apache.cloudstack.api.command.admin.router.StopRouterCmd, cmdInfo: 
{"id":"c731662f-d109-4295-8d07-383f84f93d31","response":"json","ctxDetails":"{\"com.cloud.vm.VirtualMachine\":\"c731662f-d109-4295-8d07-383f84f93d31\"}","cmdEventType":"ROUTER.STOP","ctxUserId":"2","httpmethod":"GET","uuid":"c731662f-d109-4295-8d07-383f84f93d31","ctxAccountId":"2","ctxStartEventId":"6330","apiKey":"mLrTCdYRf3-d4xO7DnO-QXw1Uqrdae1uxenHTEPj_ulDpIYTaujsXwkNzARz222s6M4xChsTAE2W-TUur5bKNQ","signature":"bGbFrU0IuNAt0/Z0jzShaop19Ts\u003d"},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 16226561876200, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}

2014-09-21 14:38:15,649 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
(API-Job-Executor-86:ctx-a051db6f job-1949 ctx-d59b1c33) Stopping router 
VM[DomainRouter|r-271-VM]
2014-09-21 14:38:15,654 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-86:ctx-a051db6f job-1949 ctx-d59b1c33) Sync job-1950 
execution on object VmWorkJobQueue.271

2014-09-21 14:38:15,654 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-86:ctx-a0

[jira] [Commented] (CLOUDSTACK-7600) [Automation] VM Failed to Start due to ConcurrentOperationException - Unable to change the state of Virtual Router

2014-11-12 Thread Prachi Damle (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208892#comment-14208892
 ] 

Prachi Damle commented on CLOUDSTACK-7600:
--

Thus the Deploy VM job got processed concurrently to the StopRouter command for 
the router - so the ConcurrentOperationException is thrown



> [Automation] VM Failed to Start due to ConcurrentOperationException - Unable 
> to change the state of Virtual Router
> --
>
> Key: CLOUDSTACK-7600
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7600
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test, Virtual Router
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Prachi Damle
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.zip
>
>
> *ConcurrentOperationException: Unable to change the state of VM*
> {noformat}
> 2014-09-21 14:38:20,648 ERROR [c.c.v.VirtualMachineManagerImpl] 
> (Work-Job-Executor-65:ctx-cfa1f316 job-1953/job-1954 ctx-6fd40296) Failed to 
> start instance VM[User|i-115-279-VM]
> com.cloud.exception.ConcurrentOperationException: Unable to change the state 
> of VM[DomainRouter|r-271-VM]
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.changeToStartState(VirtualMachineManagerImpl.java:717)
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:808)
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:762)
>   at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.start(VirtualNetworkApplianceManagerImpl.java:2981)
>   at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startVirtualRouter(VirtualNetworkApplianceManagerImpl.java:2055)
>   at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startRouters(VirtualNetworkApplianceManagerImpl.java:2155)
>   at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.deployVirtualRouterInGuestNetwork(VirtualNetworkApplianceManagerImpl.java:2137)
>   at sun.reflect.GeneratedMethodAccessor335.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
>   at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>   at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
>   at $Proxy190.deployVirtualRouterInGuestNetwork(Unknown Source)
>   at 
> com.cloud.network.element.VirtualRouterElement.prepare(VirtualRouterElement.java:234)
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareElement(NetworkOrchestrator.java:1239)
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNic(NetworkOrchestrator.java:1373)
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1309)
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:970)
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4590)
>   at sun.reflect.GeneratedMethodAccessor379.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4746)
>   at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
>   at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:516)
>   at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
>   at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
>   at 
> org.apache.

[jira] [Created] (CLOUDSTACK-7895) [Automation] Fix the script "test_security_groups.py" - Test Cases failing on Simulator as Testcases try to ssh to the VMs

2014-11-12 Thread Chandan Purushothama (JIRA)
Chandan Purushothama created CLOUDSTACK-7895:


 Summary: [Automation] Fix the script "test_security_groups.py" -  
Test Cases failing on Simulator as Testcases try to ssh to the VMs
 Key: CLOUDSTACK-7895
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7895
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Chandan Purushothama
 Fix For: 4.5.0


Test Cases are trying to validate SSH access and failing. These Test Cases are 
not meant to be run on SImulator due to their validation requirements. Hence 
they cannot be run with Simulator



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7600) [Automation] VM Failed to Start due to ConcurrentOperationException - Unable to change the state of Virtual Router

2014-11-12 Thread Prachi Damle (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208886#comment-14208886
 ] 

Prachi Damle commented on CLOUDSTACK-7600:
--

DeployVM job 

2014-09-21 14:38:20,583 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
(Work-Job-Executor-65:ctx-cfa1f316 job-1953/job-1954 ctx-6fd40296) Asking 
VirtualRouter to prepare for 
Nic[567-279-ae4d5c62-e313-4299-964c-c7f72026defa-10.1.1.10]
2014-09-21 14:38:20,593 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
(Work-Job-Executor-65:ctx-cfa1f316 job-1953/job-1954 ctx-6fd40296) Lock is 
acquired for network id 327 as a part of router startup in 
Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] 
: Dest[Zone(1)-Pod(1)-Cluster(1)-Host(2)-Storage(Volume(283|ROOT-->Pool(1))]
2014-09-21 14:38:20,595 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
(Work-Job-Executor-65:ctx-cfa1f316 job-1953/job-1954 ctx-6fd40296) Lock is 
released for network id 327 as a part of router startup in 
Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] 
: Dest[Zone(1)-Pod(1)-Cluster(1)-Host(2)-Storage(Volume(283|ROOT-->Pool(1))]
2014-09-21 14:38:20,596 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
(Work-Job-Executor-65:ctx-cfa1f316 job-1953/job-1954 ctx-6fd40296) Starting 
router VM[DomainRouter|r-271-VM]

> [Automation] VM Failed to Start due to ConcurrentOperationException - Unable 
> to change the state of Virtual Router
> --
>
> Key: CLOUDSTACK-7600
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7600
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test, Virtual Router
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Prachi Damle
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.zip
>
>
> *ConcurrentOperationException: Unable to change the state of VM*
> {noformat}
> 2014-09-21 14:38:20,648 ERROR [c.c.v.VirtualMachineManagerImpl] 
> (Work-Job-Executor-65:ctx-cfa1f316 job-1953/job-1954 ctx-6fd40296) Failed to 
> start instance VM[User|i-115-279-VM]
> com.cloud.exception.ConcurrentOperationException: Unable to change the state 
> of VM[DomainRouter|r-271-VM]
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.changeToStartState(VirtualMachineManagerImpl.java:717)
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:808)
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:762)
>   at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.start(VirtualNetworkApplianceManagerImpl.java:2981)
>   at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startVirtualRouter(VirtualNetworkApplianceManagerImpl.java:2055)
>   at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startRouters(VirtualNetworkApplianceManagerImpl.java:2155)
>   at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.deployVirtualRouterInGuestNetwork(VirtualNetworkApplianceManagerImpl.java:2137)
>   at sun.reflect.GeneratedMethodAccessor335.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:601)
>   at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
>   at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
>   at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
>   at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
>   at $Proxy190.deployVirtualRouterInGuestNetwork(Unknown Source)
>   at 
> com.cloud.network.element.VirtualRouterElement.prepare(VirtualRouterElement.java:234)
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareElement(NetworkOrchestrator.java:1239)
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNic(NetworkOrchestrator.java:1373)
>   at 
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1309)
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMach

[jira] [Commented] (CLOUDSTACK-7600) [Automation] VM Failed to Start due to ConcurrentOperationException - Unable to change the state of Virtual Router

2014-11-12 Thread Prachi Damle (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208884#comment-14208884
 ] 

Prachi Damle commented on CLOUDSTACK-7600:
--

There is a StopRouter API called by Admin simultaneous to the userVm deployment 
API.

The StopRouter has already processed and put the router in stopping state:

2014-09-21 14:38:15,627 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-86:ctx-a051db6f job-1949) Executing AsyncJobVO {id:1949, 
userId: 2, accountId: 2, instanceType: DomainRouter, instanceId: 271, cmd: 
org.apache.cloudstack.api.command.admin.router.StopRouterCmd, cmdInfo: 
{"id":"c731662f-d109-4295-8d07-383f84f93d31","response":"json","ctxDetails":"{\"com.cloud.vm.VirtualMachine\":\"c731662f-d109-4295-8d07-383f84f93d31\"}","cmdEventType":"ROUTER.STOP","ctxUserId":"2","httpmethod":"GET","uuid":"c731662f-d109-4295-8d07-383f84f93d31","ctxAccountId":"2","ctxStartEventId":"6330","apiKey":"mLrTCdYRf3-d4xO7DnO-QXw1Uqrdae1uxenHTEPj_ulDpIYTaujsXwkNzARz222s6M4xChsTAE2W-TUur5bKNQ","signature":"bGbFrU0IuNAt0/Z0jzShaop19Ts\u003d"},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 16226561876200, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}

2014-09-21 14:38:15,649 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
(API-Job-Executor-86:ctx-a051db6f job-1949 ctx-d59b1c33) Stopping router 
VM[DomainRouter|r-271-VM]
2014-09-21 14:38:15,654 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-86:ctx-a051db6f job-1949 ctx-d59b1c33) Sync job-1950 
execution on object VmWorkJobQueue.271

2014-09-21 14:38:15,654 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-86:ctx-a051db6f job-1949 ctx-d59b1c33) Sync job-1950 
execution on object VmWorkJobQueue.271
 2014-09-21 14:38:29,785 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
(Work-Job-Executor-52:ctx-303ddf98 job-1949/job-1950 ctx-e9802705) Asking 
VirtualRouter to release 
NicProfile[551-271-6596e782-c753-4d66-ae70-4828b0e7a03e-10.1.1.1-null
2014-09-21 14:38:29,815 DEBUG [c.c.v.VirtualMachineManagerImpl] 
(Work-Job-Executor-52:ctx-303ddf98 job-1949/job-1950 ctx-e9802705) Successfully 
released network resources for the vm VM[DomainRouter|r-271-VM]
2014-09-21 14:38:29,815 DEBUG [c.c.v.VirtualMachineManagerImpl] 
(Work-Job-Executor-52:ctx-303ddf98 job-1949/job-1950 ctx-e9802705) Successfully 
released storage resources for the vm VM[DomainRouter|r-271-VM]
2014-09-21 14:38:29,824 DEBUG [c.c.c.CapacityManagerImpl] 
(Work-Job-Executor-52:ctx-303ddf98 job-1949/job-1950 ctx-e9802705) VM state 
transitted from :Stopping to Stopped with event: OperationSucceededvm's 
original host id: 1 new host id: null host id before state transition: 1
2014-09-21 14:38:29,845 DEBUG [c.c.v.VmWorkJobHandlerProxy] 
(Work-Job-Executor-52:ctx-303ddf98 job-1949/job-1950 ctx-e9802705) Done 
executing VM work job: 
com.cloud.vm.VmWorkStop{"cleanup":false,"userId":2,"accountId":2,"vmId":271,"handlerName":"VirtualMachineManagerImpl"}



> [Automation] VM Failed to Start due to ConcurrentOperationException - Unable 
> to change the state of Virtual Router
> --
>
> Key: CLOUDSTACK-7600
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7600
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test, Virtual Router
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Prachi Damle
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.zip
>
>
> *ConcurrentOperationException: Unable to change the state of VM*
> {noformat}
> 2014-09-21 14:38:20,648 ERROR [c.c.v.VirtualMachineManagerImpl] 
> (Work-Job-Executor-65:ctx-cfa1f316 job-1953/job-1954 ctx-6fd40296) Failed to 
> start instance VM[User|i-115-279-VM]
> com.cloud.exception.ConcurrentOperationException: Unable to change the state 
> of VM[DomainRouter|r-271-VM]
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.changeToStartState(VirtualMachineManagerImpl.java:717)
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:808)
>   at 
> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:762)
>   at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.start(VirtualNetworkApplianceManagerImpl.java:2981)
>   at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startVirtualRouter(VirtualNetworkApplianceManagerImpl.java:2055)
>   at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startRouters(VirtualNetworkApplianceManagerImpl.java:2155)
>   at 
> com.cloud.n

[jira] [Commented] (CLOUDSTACK-5800) While creating a VM from template (which is created based on existing newly created vm) getting error as Unable to deploy vm base on template due to of insufficie

2014-11-12 Thread edison su (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208874#comment-14208874
 ] 

edison su commented on CLOUDSTACK-5800:
---

sounds like a xensever issue:

WARN [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-4:ctx-f87acd3c) Catch 
Exception com.cloud.utils.exception.CloudRuntimeException for template + due to 
com.cloud.utils.exception.CloudRuntimeException: failed to set hidden to 0 
/var/run/sr-mount/ab820f54-badd-db21-f758-0abcb47ea4d7/b0246f72-9bda-4f29-981f-548f4b7a9f6c.vhd
com.cloud.utils.exception.CloudRuntimeException: failed to set hidden to 0 
/var/run/sr-mount/ab820f54-badd-db21-f758-0abcb47ea4d7/b0246f72-9bda-4f29-981f-548f4b7a9f6c.vhd

> While creating a VM from template (which is created based on existing newly 
> created  vm) getting error as Unable to deploy vm base on template due to of 
> insufficient server capicity
> -
>
> Key: CLOUDSTACK-5800
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5800
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Template, XenServer
>Affects Versions: 4.3.0
> Environment: CENTOS 6.4,WIN2012,ACS 4.3.0,
>Reporter: rashid
>Assignee: Anthony Xu
> Fix For: 4.4.0, 4.5.0
>
>
> While creating a vm from template 
> INFO  [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-5:ctx-c259052d) Add job-46 
> into job monitoring
> INFO  [o.a.c.s.v.VolumeServiceImpl] (Job-Executor-5:ctx-c259052d 
> ctx-506ea49e) lock is acquired for VMTemplateStoragePool 7
> WARN  [o.a.c.alerts] (CapacityChecker:ctx-374c70b5)  alertType:: 24 // 
> dataCenterId:: 1 // podId:: null // clusterId:: null // message:: System 
> Alert: Number of unallocated shared network IPs is low in availability zone 
> NEWZONE
> WARN  [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-32c31ce6) Task (job-45) has 
> been pending for 104 seconds
> WARN  [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-32c31ce6) Task (job-46) has 
> been pending for 103 seconds
> WARN  [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-92c2ed53) Task (job-45) has 
> been pending for 164 seconds
> WARN  [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-92c2ed53) Task (job-46) has 
> been pending for 163 seconds
> WARN  [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-4:ctx-f87acd3c) 
> destoryVDIbyNameLabel failed due to there are 0 VDIs with name 
> cloud-377c12f4-a8e9-491a-8cba-34b9532455f8
> WARN  [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-4:ctx-f87acd3c) 
> failed to set hidden to 0  
> /var/run/sr-mount/ab820f54-badd-db21-f758-0abcb47ea4d7/b0246f72-9bda-4f29-981f-548f4b7a9f6c.vhd
> WARN  [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-4:ctx-f87acd3c) 
> Catch Exception com.cloud.utils.exception.CloudRuntimeException for template 
> +  due to com.cloud.utils.exception.CloudRuntimeException: failed to set 
> hidden to 0  
> /var/run/sr-mount/ab820f54-badd-db21-f758-0abcb47ea4d7/b0246f72-9bda-4f29-981f-548f4b7a9f6c.vhd
> com.cloud.utils.exception.CloudRuntimeException: failed to set hidden to 0  
> /var/run/sr-mount/ab820f54-badd-db21-f758-0abcb47ea4d7/b0246f72-9bda-4f29-981f-548f4b7a9f6c.vhd
> at 
> com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copy_vhd_from_secondarystorage(XenServerStorageProcessor.java:858)
> at 
> com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copyTemplateToPrimaryStorage(XenServerStorageProcessor.java:928)
> at 
> com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:75)
> at 
> com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:50)
> at 
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:609)
> at 
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
> at 
> com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106)
> at 
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(Def

[jira] [Updated] (CLOUDSTACK-5800) While creating a VM from template (which is created based on existing newly created vm) getting error as Unable to deploy vm base on template due to of insufficient

2014-11-12 Thread edison su (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

edison su updated CLOUDSTACK-5800:
--
Assignee: Anthony Xu  (was: edison su)

> While creating a VM from template (which is created based on existing newly 
> created  vm) getting error as Unable to deploy vm base on template due to of 
> insufficient server capicity
> -
>
> Key: CLOUDSTACK-5800
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5800
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Template, XenServer
>Affects Versions: 4.3.0
> Environment: CENTOS 6.4,WIN2012,ACS 4.3.0,
>Reporter: rashid
>Assignee: Anthony Xu
> Fix For: 4.4.0, 4.5.0
>
>
> While creating a vm from template 
> INFO  [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-5:ctx-c259052d) Add job-46 
> into job monitoring
> INFO  [o.a.c.s.v.VolumeServiceImpl] (Job-Executor-5:ctx-c259052d 
> ctx-506ea49e) lock is acquired for VMTemplateStoragePool 7
> WARN  [o.a.c.alerts] (CapacityChecker:ctx-374c70b5)  alertType:: 24 // 
> dataCenterId:: 1 // podId:: null // clusterId:: null // message:: System 
> Alert: Number of unallocated shared network IPs is low in availability zone 
> NEWZONE
> WARN  [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-32c31ce6) Task (job-45) has 
> been pending for 104 seconds
> WARN  [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-32c31ce6) Task (job-46) has 
> been pending for 103 seconds
> WARN  [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-92c2ed53) Task (job-45) has 
> been pending for 164 seconds
> WARN  [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-92c2ed53) Task (job-46) has 
> been pending for 163 seconds
> WARN  [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-4:ctx-f87acd3c) 
> destoryVDIbyNameLabel failed due to there are 0 VDIs with name 
> cloud-377c12f4-a8e9-491a-8cba-34b9532455f8
> WARN  [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-4:ctx-f87acd3c) 
> failed to set hidden to 0  
> /var/run/sr-mount/ab820f54-badd-db21-f758-0abcb47ea4d7/b0246f72-9bda-4f29-981f-548f4b7a9f6c.vhd
> WARN  [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-4:ctx-f87acd3c) 
> Catch Exception com.cloud.utils.exception.CloudRuntimeException for template 
> +  due to com.cloud.utils.exception.CloudRuntimeException: failed to set 
> hidden to 0  
> /var/run/sr-mount/ab820f54-badd-db21-f758-0abcb47ea4d7/b0246f72-9bda-4f29-981f-548f4b7a9f6c.vhd
> com.cloud.utils.exception.CloudRuntimeException: failed to set hidden to 0  
> /var/run/sr-mount/ab820f54-badd-db21-f758-0abcb47ea4d7/b0246f72-9bda-4f29-981f-548f4b7a9f6c.vhd
> at 
> com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copy_vhd_from_secondarystorage(XenServerStorageProcessor.java:858)
> at 
> com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copyTemplateToPrimaryStorage(XenServerStorageProcessor.java:928)
> at 
> com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:75)
> at 
> com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:50)
> at 
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:609)
> at 
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
> at 
> com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106)
> at 
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> at 
> java.util.concurrent.

[jira] [Resolved] (CLOUDSTACK-7743) [Automation][KVM] Migration of VM failed due to LibvirtException: Cannot get interface MTU on 'breth0-3011': No such device"

2014-11-12 Thread edison su (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

edison su resolved CLOUDSTACK-7743.
---
Resolution: Incomplete

Need more information about kvm host, does all the kvm hosts in the same 
cluster have the same gateway device?

> [Automation][KVM] Migration of VM failed due to LibvirtException: Cannot get 
> interface MTU on 'breth0-3011': No such device"
> 
>
> Key: CLOUDSTACK-7743
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7743
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, KVM
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: edison su
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.zip
>
>
> Use Case:
> 1. VM Migration from One Host to Another - Fails currently due to 
> LibvirtException
> =
> LibvirtException:
> =
> {noformat}
> 2014-10-13 19:26:36,930 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-65:ctx-3cedea49 job-197/job-198 ctx-066f6b6a) Seq 
> 1-8599060538510540956: Sending  { Cmd , MgmtId: 86095456037899, via: 
> 1(cl07-11), Ver: v1, Flags: 100111, 
> [{"com.cloud.agent.api.PrepareForMigrationCommand":{"vm":{"id":32,"name":"i-13-32-VM","type":"User","cpus":1,"minSpeed":100,"maxSpeed":100,"minRam":268435456,"maxRam":268435456,"arch":"x86_64","os":"CentOS
>  5.5 (64-bit)","platformEmulator":"CentOS 
> 5.5","bootArgs":"","enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"UgJEzSDcfsSllX2nVfeMqQ==","params":{},"uuid":"fe6ef18e-37da-4730-9794-03760f325082","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"c031588c-51be-4be8-9c30-4535b3428d2f","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"e3ce1672-a3c4-3396-a86b-025c13ee2b8c","id":1,"poolType":"NetworkFilesystem","host":"10.220.128.55","path":"/vol/xenrtnfs/861825-jkTv6e","port":2049,"url":"NetworkFilesystem://10.220.128.55/vol/xenrtnfs/861825-jkTv6e/?ROLE=Primary&STOREUUID=e3ce1672-a3c4-3396-a86b-025c13ee2b8c"}},"name":"ROOT-32","size":8589934592,"path":"c031588c-51be-4be8-9c30-4535b3428d2f","volumeId":35,"vmName":"i-13-32-VM","accountId":13,"format":"QCOW2","provisioningType":"THIN","id":35,"deviceId":0,"hypervisorType":"KVM"}},"diskSeq":0,"path":"c031588c-51be-4be8-9c30-4535b3428d2f","type":"ROOT","_details":{"managed":"false","storagePort":"2049","storageHost":"10.220.128.55","volumeSize":"8589934592"}},{"data":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"id":0,"format":"ISO","accountId":0,"hvm":false}},"diskSeq":3,"type":"ISO"}],"nics":[{"deviceId":0,"networkRateMbps":200,"defaultNic":true,"pxeDisable":false,"nicUuid":"47696919-1d62-416f-9f2c-1bfa72ef2330","uuid":"85218f30-0f90-4d63-8553-b8431cdf60aa","ip":"192.168.200.220","netmask":"255.255.255.0","gateway":"192.168.200.1","mac":"02:00:7a:45:00:05","dns1":"10.220.128.11","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://3011","isolationUri":"vlan://3011","isSecurityGroupEnabled":false}]},"wait":0}}]
>  }
> 2014-10-13 19:26:36,993 DEBUG [c.c.a.t.Request] 
> (AgentManager-Handler-19:null) Seq 1-8599060538510540956: Processing:  { Ans: 
> , MgmtId: 86095456037899, via: 1, Ver: v1, Flags: 110, 
> [{"com.cloud.agent.api.PrepareForMigrationAnswer":{"result":true,"wait":0}}] }
> 2014-10-13 19:26:36,993 DEBUG [c.c.a.m.AgentAttache] 
> (AgentManager-Handler-19:null) Seq 1-8599060538510540956: No more commands 
> found
> 2014-10-13 19:26:36,993 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-65:ctx-3cedea49 job-197/job-198 ctx-066f6b6a) Seq 
> 1-8599060538510540956: Received:  { Ans: , MgmtId: 86095456037899, via: 1, 
> Ver: v1, Flags: 110, { PrepareForMigrationAnswer } }
> 2014-10-13 19:26:37,000 DEBUG [c.c.c.CapacityManagerImpl] 
> (Work-Job-Executor-65:ctx-3cedea49 job-197/job-198 ctx-066f6b6a) VM state 
> transitted from :Running to Migrating with event: MigrationRequestedvm's 
> original host id: 2 new host id: 1 host id before state transition: 2
> 2014-10-13 19:26:37,005 DEBUG [c.c.c.CapacityManagerImpl] 
> (Work-Job-Executor-65:ctx-3cedea49 job-197/job-198 ctx-066f6b6a) Hosts's 
> actual total CPU: 38400 and CPU after applying overprovisioning: 38400
> 2014-10-13 19:26:37,005 DEBUG [c.c.c.CapacityManagerImpl] 
> (Work-Job-Executor-65:ctx-3cedea49 job-197/job-198 ctx-066f6b6a) We are 
> allocating VM, increasing the used capacity of this host:1
> 2014-10-13 19:26:37,005 DEBUG [c.c.c.CapacityManagerImpl] 
> (Work-Job-Executor-65:ctx-3cedea49 job-197/job-198 ctx-066f6b6a) Current Used 
> CPU: 2500 , Free CPU:35900 ,Requested CPU: 100
>

[jira] [Commented] (CLOUDSTACK-7559) After migrating root volume to other cluster wide storage, start VM is not running the VM with root disk from new storage.

2014-11-12 Thread edison su (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208856#comment-14208856
 ] 

edison su commented on CLOUDSTACK-7559:
---

>From the code, it sounds like planner choosing a different cluster than root 
>volume.

> After migrating root volume to other cluster wide storage, start VM is not 
> running the VM with root disk from new storage.
> --
>
> Key: CLOUDSTACK-7559
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7559
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller
>Affects Versions: 4.5.0
> Environment: 1zone ,1pod, 2 clusters with ESXi HV each cluster wide 
> primary storage.
>Reporter: manasaveloori
>Assignee: Prachi Damle
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.log.rar
>
>
> 1. 2 clusters C1 and C2 with PS1 and PS2(cluster wide both)
> 2. Deploy a VM with data disk under cluster C1.
> 3. stop the VM and detach the data disk.
> 4. Migrate the root volume to PS2.
> 5. Start the VM.
> Observed :
> Initially vm deployment failed and then root volume migrated back to PS1 and 
> then VM started.
> Observed the following in MS logs:
> 2014-09-15 17:02:07,096 ERROR [c.c.v.VmWorkJobHandlerProxy] 
> (Work-Job-Executor-18:ctx-a3ba0611 job-911/job-912 ctx-769e4a3b) Invocation 
> exception, caused by: com.cloud.exception.ResourceUnavailableException: 
> Resource [Cluster:1] is unreachable: Root volume is ready in different 
> cluster, Deployment plan provided cannot be satisfied, unable to create a 
> deployment for VM[User|i-2-59-VM]
> Attaching the Mslogs



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CLOUDSTACK-7559) After migrating root volume to other cluster wide storage, start VM is not running the VM with root disk from new storage.

2014-11-12 Thread edison su (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

edison su updated CLOUDSTACK-7559:
--
Assignee: Prachi Damle  (was: edison su)

> After migrating root volume to other cluster wide storage, start VM is not 
> running the VM with root disk from new storage.
> --
>
> Key: CLOUDSTACK-7559
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7559
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller
>Affects Versions: 4.5.0
> Environment: 1zone ,1pod, 2 clusters with ESXi HV each cluster wide 
> primary storage.
>Reporter: manasaveloori
>Assignee: Prachi Damle
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.log.rar
>
>
> 1. 2 clusters C1 and C2 with PS1 and PS2(cluster wide both)
> 2. Deploy a VM with data disk under cluster C1.
> 3. stop the VM and detach the data disk.
> 4. Migrate the root volume to PS2.
> 5. Start the VM.
> Observed :
> Initially vm deployment failed and then root volume migrated back to PS1 and 
> then VM started.
> Observed the following in MS logs:
> 2014-09-15 17:02:07,096 ERROR [c.c.v.VmWorkJobHandlerProxy] 
> (Work-Job-Executor-18:ctx-a3ba0611 job-911/job-912 ctx-769e4a3b) Invocation 
> exception, caused by: com.cloud.exception.ResourceUnavailableException: 
> Resource [Cluster:1] is unreachable: Root volume is ready in different 
> cluster, Deployment plan provided cannot be satisfied, unable to create a 
> deployment for VM[User|i-2-59-VM]
> Attaching the Mslogs



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7892) UI > module > execute handlers attached to event 'cloudStack.module.sharedFunctions.addExtraProperties'

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208854#comment-14208854
 ] 

ASF subversion and git services commented on CLOUDSTACK-7892:
-

Commit 60aab6bf178eac2d7fa8ab48c8091655b4f82c2a in cloudstack's branch 
refs/heads/master from [~jessicawang]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=60aab6b ]

CLOUDSTACK-7892: UI > instances > detailView > execute handlers attached to 
event 'cloudStack.module.sharedFunctions.addExtraProperties'.


> UI > module > execute handlers attached to event 
> 'cloudStack.module.sharedFunctions.addExtraProperties'
> ---
>
> Key: CLOUDSTACK-7892
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7892
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Jessica Wang
>Assignee: Jessica Wang
>Priority: Critical
> Fix For: 4.6.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7892) UI > module > execute handlers attached to event 'cloudStack.module.sharedFunctions.addExtraProperties'

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208841#comment-14208841
 ] 

ASF subversion and git services commented on CLOUDSTACK-7892:
-

Commit 30026ee17593c8085354ce2d934450931d75f563 in cloudstack's branch 
refs/heads/master from [~jessicawang]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=30026ee ]

CLOUDSTACK-7892: UI > stroage > volume > detailView > execute handlers attached 
to event 'cloudStack.module.sharedFunctions.addExtraProperties'.


> UI > module > execute handlers attached to event 
> 'cloudStack.module.sharedFunctions.addExtraProperties'
> ---
>
> Key: CLOUDSTACK-7892
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7892
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Jessica Wang
>Assignee: Jessica Wang
>Priority: Critical
> Fix For: 4.6.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CLOUDSTACK-7556) [API]Non live Migration of root and data disk from cluster wide primary to zone wide and vice versa is not failing

2014-11-12 Thread edison su (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

edison su resolved CLOUDSTACK-7556.
---
Resolution: Won't Fix

It's by design: as migratevolume api is an admin api, so admin knows what
's he/she is doing. Usually, admin uses api in an emergency situation.

> [API]Non live Migration of root and data disk from cluster wide primary to 
> zone wide and vice versa is not failing
> --
>
> Key: CLOUDSTACK-7556
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7556
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller
>Affects Versions: 4.5.0
> Environment: 1zone,1pod,2 clusters with ESXi5.1 HV each
>Reporter: manasaveloori
>Assignee: edison su
>Priority: Critical
> Fix For: 4.5.0
>
>
> 1. Cluster C1 has primary PS1 and C2 -primary PS2.Also added one zone wide PS 
> PSZW.
> 2. Deployed a VM  with data disk under cluster1.
> 3. Stopped  the VM.
> 4. Fired the API for migrating the root/data disk from PS1 to PSZW.
> Migration of root/data from cluster wide to zone wide and vice versa should 
> fail as there is a scope change.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7892) UI > module > execute handlers attached to event 'cloudStack.module.sharedFunctions.addExtraProperties'

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208828#comment-14208828
 ] 

ASF subversion and git services commented on CLOUDSTACK-7892:
-

Commit 7e7641f0e87c16a363cf0ee5a8d9aa298da27e02 in cloudstack's branch 
refs/heads/master from [~jessicawang]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7e7641f ]

CLOUDSTACK-7892: UI > Infrastructure > zones > zone > detailView > execute 
handlers attached to event 
'cloudStack.module.sharedFunctions.addExtraProperties'.


> UI > module > execute handlers attached to event 
> 'cloudStack.module.sharedFunctions.addExtraProperties'
> ---
>
> Key: CLOUDSTACK-7892
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7892
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Jessica Wang
>Assignee: Jessica Wang
>Priority: Critical
> Fix For: 4.6.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CLOUDSTACK-7518) SSVM stop/start is not initiating the download for Partially downloaded ISO's

2014-11-12 Thread edison su (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

edison su resolved CLOUDSTACK-7518.
---
Resolution: Won't Fix

It's by design: private template won't be synced: CLOUDSTACK-4455

> SSVM stop/start is not initiating the download for Partially downloaded ISO's 
> --
>
> Key: CLOUDSTACK-7518
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7518
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Template, XenServer
>Affects Versions: 4.5.0
>Reporter: Sailaja Mada
>Assignee: edison su
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: isologs.zip, ssvmlogs.zip
>
>
> Setup:
> 1. Configure Adv Zone with XS 6.5 
> 2.  Register Windows 2012 ISO , Waited for it to download 20% 
> 3. Stop SSVM 
> 4. ISO details gets the status as SSVM Agent  disconnected
> 5. Start SSVM 
> Observation: 
> SSVM stop/start is not initiating the download for Partially downloaded 
> templates/ISO's 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-7894) [Automation] Fix the script "test_vm_passwdenabled.py" - Test Cases failing on Simulator as Testcases try to ssh to the VMs

2014-11-12 Thread Chandan Purushothama (JIRA)
Chandan Purushothama created CLOUDSTACK-7894:


 Summary: [Automation] Fix the script "test_vm_passwdenabled.py" -  
Test Cases failing on Simulator as Testcases try to ssh to the VMs
 Key: CLOUDSTACK-7894
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7894
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Chandan Purushothama
 Fix For: 4.5.0


Test Cases are trying to validate SSH access and failing. These Test Cases are 
not meant to be run on SImulator due to their validation requirements. Hence 
they cannot be run with Simulator



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7891) Fix failure in integration.component.test_escalations_instances.TestInstances/test_15_revert_vm_to_snapshot.

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208815#comment-14208815
 ] 

ASF subversion and git services commented on CLOUDSTACK-7891:
-

Commit b12207cf253d8a86e57118575eede98efee9e569 in cloudstack's branch 
refs/heads/master from [~sangeethah]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b12207c ]

CLOUDSTACK-7891 - Fix failure in 
integration.component.test_escalations_instances.TestInstances/test_15_revert_vm_to_snapshot


> Fix failure in 
> integration.component.test_escalations_instances.TestInstances/test_15_revert_vm_to_snapshot.
> 
>
> Key: CLOUDSTACK-7891
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7891
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Test
>Reporter: Sangeetha Hariharan
>
> Fix failure in 
> integration.component.test_escalations_instances.TestInstances/test_15_revert_vm_to_snapshot.
> Following exception seen when this test case is executed:
> Disallowed failure 
> integration.component.test_escalations_instances.TestInstances/test_15_revert_vm_to_snapshot:
>  RevertToVMSnapshotCmd failed: VM Snapshot revert not allowed. This will 
> result in VM state change. You can revert running VM to disk and memor



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-7893) snapshots - This operation cannot be performed because this VDI is in use by some other operation

2014-11-12 Thread Vincent Vuong (JIRA)
Vincent Vuong created CLOUDSTACK-7893:
-

 Summary: snapshots -  This operation cannot be performed because 
this VDI is in use by some other operation
 Key: CLOUDSTACK-7893
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7893
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.4.0
 Environment: ACS 4.4.0
Xenserver 6.2 with latest patches
Reporter: Vincent Vuong


Performing a snapshot failed with the following errors:

cd7b4-2c57-4953-8351-9bc3c2cbea37&response=json&sessionkey=to0X92g7IoXsSJzZnvOls5XMLa0%3D&_=1415830479614
2014-11-12 14:14:52,280 WARN  [o.a.c.h.x.XenServerResourceNewBase] 
(DirectAgent-410:ctx-48699859) No event for task 
OpaqueRef:3ce629b5-476d-3fc1-e022-c020a9550f21
2014-11-12 14:14:52,289 DEBUG [c.c.h.x.r.CitrixResourceBase] 
(DirectAgent-410:ctx-48699859) Host 10.3.11.20 
OpaqueRef:97d77797-3e8a-2c45-3d08-f947a793e73a: Removing SR
2014-11-12 14:14:52,310 DEBUG [c.c.h.x.r.CitrixResourceBase] 
(DirectAgent-410:ctx-48699859) Host 10.3.11.20 
OpaqueRef:97d77797-3e8a-2c45-3d08-f947a793e73a: Catch XenAPIException: This 
operation cannot be performed because this VDI is in use by some other operation
2014-11-12 14:14:52,339 DEBUG [c.c.h.x.r.CitrixResourceBase] 
(DirectAgent-410:ctx-48699859) Host 10.3.11.20 
OpaqueRef:97d77797-3e8a-2c45-3d08-f947a793e73a: Catch XenAPIException: This 
operation cannot be performed because this VDI is in use by some other operation
2014-11-12 14:14:52,339 WARN  [c.c.h.x.r.CitrixResourceBase] 
(DirectAgent-410:ctx-48699859) Host 10.3.11.20 
OpaqueRef:97d77797-3e8a-2c45-3d08-f947a793e73a: Unable to remove SR
2014-11-12 14:14:52,339 WARN  [c.c.h.x.r.XenServerStorageProcessor] 
(DirectAgent-410:ctx-48699859) BackupSnapshot Failed due to No event for task 
OpaqueRef:3ce629b5-476d-3fc1-e022-c020a9550f21
java.util.concurrent.TimeoutException: No event for task 
OpaqueRef:3ce629b5-476d-3fc1-e022-c020a9550f21
at 
org.apache.cloudstack.hypervisor.xenserver.XenServerResourceNewBase.waitForTask(XenServerResourceNewBase.java:124)
at 
com.cloud.hypervisor.xen.resource.Xenserver625StorageProcessor.backupSnapshot(Xenserver625StorageProcessor.java:430)
at 
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:94)
at 
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:52)
at 
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:546)
at 
com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:61)
at 
com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:102)
at 
com.cloud.hypervisor.xen.resource.XenServer620SP1Resource.executeRequest(XenServer620SP1Resource.java:65)
at 
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
2014-11-12 14:14:52,340 DEBUG [c.c.a.m.DirectAgentAttache] 
(DirectAgent-410:ctx-48699859) Seq 1-815404802551526: Response Received:
2014-11-12 14:14:52,340 DEBUG [c.c.a.t.Request] (DirectAgent-410:ctx-48699859) 
Seq 1-815404802551526: Processing:  { Ans: , MgmtId: 161330254406, via: 1, 
Ver: v1, Flags: 10, 
[{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"result":false,"details":"BackupSnapshot
 Failed due to No event for task 
OpaqueRef:3ce629b5-476d-3fc1-e022-c020a9550f21","wait":0}}] }
2014-11-12 14:14:52,340 DEBUG [c.c.a.t.Request] 
(Work-Job-Executor-93:ctx-37089b32 job-16

[jira] [Commented] (CLOUDSTACK-7892) UI > module > execute handlers attached to event 'cloudStack.module.sharedFunctions.addExtraProperties'

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208756#comment-14208756
 ] 

ASF subversion and git services commented on CLOUDSTACK-7892:
-

Commit 8cf1102b0a8f175f7d1d87c2003e805a9b15bc9c in cloudstack's branch 
refs/heads/master from [~jessicawang]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8cf1102 ]

CLOUDSTACK-7892: UI > Infrastructure > zone > physical network > guest > 
details tab > network tab > detail view > execute handlers attached to event 
'cloudStack.module.sharedFunctions.addExtraProperties'.


> UI > module > execute handlers attached to event 
> 'cloudStack.module.sharedFunctions.addExtraProperties'
> ---
>
> Key: CLOUDSTACK-7892
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7892
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Jessica Wang
>Assignee: Jessica Wang
>Priority: Critical
> Fix For: 4.6.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CLOUDSTACK-7892) UI > module > execute handlers attached to event 'cloudStack.module.sharedFunctions.addExtraProperties'

2014-11-12 Thread Jessica Wang (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jessica Wang updated CLOUDSTACK-7892:
-
Fix Version/s: (was: 4.5.0)
   4.6.0

> UI > module > execute handlers attached to event 
> 'cloudStack.module.sharedFunctions.addExtraProperties'
> ---
>
> Key: CLOUDSTACK-7892
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7892
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Jessica Wang
>Assignee: Jessica Wang
>Priority: Critical
> Fix For: 4.6.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CLOUDSTACK-7892) UI > module > execute handlers attached to event 'cloudStack.module.sharedFunctions.addExtraProperties'

2014-11-12 Thread Jessica Wang (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jessica Wang resolved CLOUDSTACK-7892.
--
Resolution: Fixed

> UI > module > execute handlers attached to event 
> 'cloudStack.module.sharedFunctions.addExtraProperties'
> ---
>
> Key: CLOUDSTACK-7892
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7892
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Jessica Wang
>Assignee: Jessica Wang
>Priority: Critical
> Fix For: 4.5.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (CLOUDSTACK-7892) UI > module > execute handlers attached to event 'cloudStack.module.sharedFunctions.addExtraProperties'

2014-11-12 Thread Jessica Wang (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jessica Wang closed CLOUDSTACK-7892.


> UI > module > execute handlers attached to event 
> 'cloudStack.module.sharedFunctions.addExtraProperties'
> ---
>
> Key: CLOUDSTACK-7892
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7892
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Jessica Wang
>Assignee: Jessica Wang
>Priority: Critical
> Fix For: 4.5.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7892) UI > module > execute handlers attached to event 'cloudStack.module.sharedFunctions.addExtraProperties'

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208740#comment-14208740
 ] 

ASF subversion and git services commented on CLOUDSTACK-7892:
-

Commit aff3a261e02e3318caddde8234c60a32a8d9e880 in cloudstack's branch 
refs/heads/master from [~jessicawang]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=aff3a26 ]

CLOUDSTACK-7892: UI > network > detailView > execute handlers attached to event 
'cloudStack.module.sharedFunctions.addExtraProperties'.


> UI > module > execute handlers attached to event 
> 'cloudStack.module.sharedFunctions.addExtraProperties'
> ---
>
> Key: CLOUDSTACK-7892
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7892
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Jessica Wang
>Assignee: Jessica Wang
>Priority: Critical
> Fix For: 4.5.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-7892) UI > module > execute handlers attached to event 'cloudStack.module.sharedFunctions.addExtraProperties'

2014-11-12 Thread Jessica Wang (JIRA)
Jessica Wang created CLOUDSTACK-7892:


 Summary: UI > module > execute handlers attached to event 
'cloudStack.module.sharedFunctions.addExtraProperties'
 Key: CLOUDSTACK-7892
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7892
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Reporter: Jessica Wang
Assignee: Jessica Wang
Priority: Critical
 Fix For: 4.5.0






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7876) [Automation] Fix the script "test_vpc_vm_life_cycle.py" - Destruction of VM is expunging the VM before it can be recovered

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208716#comment-14208716
 ] 

ASF subversion and git services commented on CLOUDSTACK-7876:
-

Commit 76ef987e7c5d2264281a941f56ee3c655c7aea66 in cloudstack's branch 
refs/heads/master from [~chandanp]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=76ef987 ]

CLOUDSTACK-7876 - Fixed the script 'test_vpc_vm_life_cycle.py' - Destruction of 
VM before it can be recovered needs to be prevented


> [Automation] Fix the script "test_vpc_vm_life_cycle.py" - Destruction of VM 
> is expunging the VM before it can be recovered
> --
>
> Key: CLOUDSTACK-7876
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7876
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Chandan Purushothama
>Assignee: Chandan Purushothama
>Priority: Critical
>
> Multiple Test Cases in the Test Suite Fail as the VMs 
> destroy_instance_in_network test case step ends up expunged before the can be 
> recovered for the subsequent test cases. Hence it is important not to wait 
> for too much time before the VMs can be recovered.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CLOUDSTACK-7522) RPM builds should exit status 1, if there are failure in MVN build

2014-11-12 Thread Rayees Namathponnan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rayees Namathponnan resolved CLOUDSTACK-7522.
-
Resolution: Fixed

Fixed 

> RPM builds should exit status 1, if there are failure in MVN build 
> ---
>
> Key: CLOUDSTACK-7522
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7522
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Assignee: Rayees Namathponnan
>Priority: Critical
> Fix For: 4.5.0
>
>
> Steps to reproduce 
> > execute RPM build command 
> var=$(bash ./package.sh --pack noredist --build)
> > while executing MVN command kill java "killall -9 java"
> >see the output,  echo $var to see the output
> Expected result 
> RPM build should exited error
> Actual result
> RPM build not exited with error , it return Done, see the output 
> .cloudstack.framework.config.impl.ConfigDepotAdminTest log4j:WARN No 
> appenders could be found for logger 
> (org.apache.cloudstack.framework.config.impl.ConfigDepotImpl). log4j:WARN 
> Please initialize the log4j system properly. log4j:WARN See 
> http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. Tests 
> run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.091 sec Results : 
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] --- 
> maven-jar-plugin:2.4:jar (default-jar) @ cloud-framework-config --- [INFO] 
> Building jar: 
> /root/cloudplatform/build/source/dist/rpmbuild/BUILD/cloudstack-4.5.0-SNAPSHOT/framework/config/target/cloud-framework-config-4.5.0-SNAPSHOT.jar
>  [INFO] [INFO] --- maven-site-plugin:3.3:attach-descriptor 
> (attach-descriptor) @ cloud-framework-config --- [INFO] [INFO] 
>  
> [INFO] Building Apache CloudStack API 4.5.0-SNAPSHOT [INFO] 
>  
> [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ cloud-api 
> --- [INFO] Deleting 
> /root/cloudplatform/build/source/dist/rpmbuild/BUILD/cloudstack-4.5.0-SNAPSHOT/api
>  (includes = [target, dist], excludes = []) [INFO] [INFO] --- 
> maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ cloud-api --- 
> [INFO] Starting audit... Audit done. [INFO] [INFO] --- 
> maven-remote-resources-plugin:1.3:process (default) @ cloud-api --- [INFO] 
> [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
> cloud-api --- [debug] execute contextualize [INFO] Using 'UTF-8' encoding to 
> copy filtered resources. [INFO] Copying 4 resources [INFO] Copying 3 
> resources [INFO] [INFO] --- maven-compiler-plugin:2.5.1:compile 
> (default-compile) @ cloud-api --- [INFO] Compiling 939 source files to 
> /root/cloudplatform/build/source/dist/rpmbuild/BUILD/cloudstack-4.5.0-SNAPSHOT/api/target/classes
>  RPM build errors: Done
> [root@build-test centos63]# vi package.sh
> Looks like this is happening after below commit 
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=7ea7deded031b43042c68db0f7c5c6c8b21c18c2
> if revert this commit rpm exit with return 1, if there are issue with mvn 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CLOUDSTACK-6495) JSVC package dependancy failures during installation of Cloudstack Agent on RHEL6.3

2014-11-12 Thread Rayees Namathponnan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rayees Namathponnan resolved CLOUDSTACK-6495.
-
Resolution: Invalid

IN ACS we should not package JSVC; you need to make sure its available in your 
repo 

> JSVC package dependancy failures during installation  of Cloudstack Agent on 
> RHEL6.3 
> -
>
> Key: CLOUDSTACK-6495
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6495
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.4.0
>Reporter: manasaveloori
>Assignee: Rayees Namathponnan
> Fix For: 4.4.0, 4.5.0
>
>
> Observing jsvc depency errors while installing the agent on RHEL6.3.
> ---> Package gnutls.x86_64 0:2.8.5-10.el6 will be an update
> ---> Package java_cup.x86_64 1:0.10k-5.el6 will be installed
> --> Running transaction check
> ---> Package cloudstack-agent.x86_64 0:4.4.0-SNAPSHOT.el6 will be installed
> --> Processing Dependency: java >= 1:1.7.0 for package: 
> cloudstack-agent-4.4.0-SNAPSHOT.el6.x86_64
> --> Processing Dependency: jsvc for package: 
> cloudstack-agent-4.4.0-SNAPSHOT.el6.x86_64
> --> Processing Dependency: jakarta-commons-daemon-jsvc for package: 
> cloudstack-agent-4.4.0-SNAPSHOT.el6.x86_64
> ---> Package cyrus-sasl.x86_64 0:2.1.23-13.el6 will be updated
> ---> Package cyrus-sasl.x86_64 0:2.1.23-13.el6_3.1 will be an update
> ---> Package cyrus-sasl-plain.x86_64 0:2.1.23-13.el6 will be updated
> ---> Package cyrus-sasl-plain.x86_64 0:2.1.23-13.el6_3.1 will be an update
> --> Finished Dependency Resolution
> Error: Package: cloudstack-agent-4.4.0-SNAPSHOT.el6.x86_64 (cloud-temp)
>Requires: java >= 1:1.7.0
>Available: java-1.5.0-gcj-1.5.0.0-29.1.el6.x86_64 (rhel)
>java = 1.5.0
>Available: 1:java-1.6.0-openjdk-1.6.0.0-1.50.1.11.5.el6_3.x86_64 
> (rhel)
>java = 1:1.6.0
> Error: Package: cloudstack-agent-4.4.0-SNAPSHOT.el6.x86_64 (cloud-temp)
>Requires: jsvc
> Error: Package: cloudstack-agent-4.4.0-SNAPSHOT.el6.x86_64 (cloud-temp)
>Requires: java >= 1:1.7.0
>Installing: java-1.5.0-gcj-1.5.0.0-29.1.el6.x86_64 (rhel)
>java = 1.5.0
>Available: 1:java-1.6.0-openjdk-1.6.0.0-1.50.1.11.5.el6_3.x86_64 
> (rhel)
>java = 1:1.6.0
> Error: Package: cloudstack-agent-4.4.0-SNAPSHOT.el6.x86_64 (cloud-temp)
>Requires: jakarta-commons-daemon-jsvc
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest
> Done
> [root@Rack1Pod1Host29 CloudPlatform-ccp-4.4-118-rhel6.3]#



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CLOUDSTACK-7011) No logs being generated because Logs are created as root instead of cloud user

2014-11-12 Thread Rayees Namathponnan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rayees Namathponnan resolved CLOUDSTACK-7011.
-
Resolution: Fixed

Not found this issue in last runs 

>  No logs being generated because Logs are created as root instead of cloud 
> user
> ---
>
> Key: CLOUDSTACK-7011
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7011
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.4.0
> Environment: 4.4-forward 
> RPM build
>Reporter: Rayees Namathponnan
>Assignee: Rayees Namathponnan
> Fix For: 4.5.0
>
>
> Steps to reproduce 
> 1 ) Create RPM build from centos
> 2) Install MS 
> 3) Uninstall MS and Delete MS
> 4) Install MS again 
> 5) Setup MS
> Expected result 
> Installation should be succeeded, and during setup  MS,  logs should be 
> captured in MS log 
> Result 
> MS log user is root and nothing capturing in MS log, see the permission below
> -rw-rw-r--. 1 cloud cloud 12518422 Jun 30 09:50 access_log.2014-06-30.txt
> -rw-rw-r--. 1 cloud cloud 38500897 Jun 30 09:50 apilog.log
> -rw-r--r--. 1 root  root 0 Jun 30 00:27 api-server.log
> -rw-rw-r--. 1 cloud cloud0 Jun 30 00:27 catalina.2014-06-30.log
> -rw-r--r--. 1 cloud cloud 24646600 Jun 30 09:50 catalina.out
> -rw-rw-r--. 1 cloud cloud0 Jun 30 00:27 host-manager.2014-06-30.log
> -rw-rw-r--. 1 cloud cloud  874 Jun 30 00:43 localhost.2014-06-30.log
> -rw-r--r--. 1 root  root 0 Jun 30 00:27 management-server.log
> -rw-rw-r--. 1 cloud cloud0 Jun 30 00:27 manager.2014-06-30.log
> -rw-r--r--. 1 root  root  4479 Jun 30 00:27 setupManagement.log



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CLOUDSTACK-7469) Simulator build support need to extends for RPM build

2014-11-12 Thread Rayees Namathponnan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rayees Namathponnan resolved CLOUDSTACK-7469.
-
Resolution: Fixed

Fixed in 
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=f96c65416a2802bcf2a1f8d5a5070ffe6a29111f
 

> Simulator build support need to extends for RPM build  
> ---
>
> Key: CLOUDSTACK-7469
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7469
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Assignee: Rayees Namathponnan
> Fix For: 4.5.0
>
>
> Currently there is no option to build rpm with simulator, 
> We need to update the package.sh file to accept simulator
> cloud.spec file need to be updated  to build both oss and nooss simulator 
> buids



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7671) [RHEL7] management server failed to start once machine is rebooted

2014-11-12 Thread Rayees Namathponnan (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208690#comment-14208690
 ] 

Rayees Namathponnan commented on CLOUDSTACK-7671:
-

Damoder assigning back to you  

> [RHEL7] management server failed to start once machine is rebooted
> --
>
> Key: CLOUDSTACK-7671
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7671
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Damodar Reddy T
>Assignee: Damodar Reddy T
>
> Repro stesp:
> Create a rhel 7 host
> Install MS
> Start MS
> Once MS is up and running . Reboot MS . Notice Cloudstack-management service  
> status
> Bug:
> Notice MS fails to start even after calling service cloudstack-management 
> restart it failed to start
> systemctl status cloudstack-management.service
> cloudstack-management.service - Citrix Cloud Plaltform
>Loaded: loaded (/usr/lib/systemd/system/cloudstack-management.service; 
> enabled)
>Active: failed (Result: exit-code) since Tue 2014-09-23 12:10:09 IST; 1min 
> 28s ago
>   Process: 4618 ExecStart=/usr/sbin/cloudstack-management start (code=exited, 
> status=1/FAILURE)
> Sep 23 12:10:09 Rack1Pod1Host27 systemd[1]: Starting Citrix Cloud Plaltform...
> Sep 23 12:10:09 Rack1Pod1Host27 cloudstack-management[4618]: 
> /usr/sbin/tomcat: line 50: /var/run/cloudstack-management.pid: Permission 
> denied
> Sep 23 12:10:09 Rack1Pod1Host27 systemd[1]: cloudstack-management.service: 
> control process exited, code=exited status=1
> Sep 23 12:10:09 Rack1Pod1Host27 systemd[1]: Failed to start Citrix Cloud 
> Plaltform.
> Sep 23 12:10:09 Rack1Pod1Host27 systemd[1]: Unit 
> cloudstack-management.service entered failed state.
> [root@Rack1Pod1Host27 run]#
> service  cloudstack-management status
> Redirecting to /bin/systemctl status  cloudstack-management.service
> cloudstack-management.service - Citrix Cloud Plaltform
>Loaded: loaded (/usr/lib/systemd/system/cloudstack-management.service; 
> enabled)
>Active: failed (Result: exit-code) since Tue 2014-09-23 12:14:05 IST; 8s 
> ago
>   Process: 4691 ExecStart=/usr/sbin/cloudstack-management start (code=exited, 
> status=1/FAILURE)
> Sep 23 12:14:05 Rack1Pod1Host27 cloudstack-management[4691]: 
> /usr/sbin/tomcat: line 50: /var/run/cloudstack-management.pid: Permission 
> denied
> Sep 23 12:14:05 Rack1Pod1Host27 systemd[1]: cloudstack-management.service: 
> control process exited, code=exited status=1
> Sep 23 12:14:05 Rack1Pod1Host27 systemd[1]: Failed to start Citrix Cloud 
> Plaltform.
> Sep 23 12:14:05 Rack1Pod1Host27 systemd[1]: Unit 
> cloudstack-management.service entered failed state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (CLOUDSTACK-7522) RPM builds should exit status 1, if there are failure in MVN build

2014-11-12 Thread Rayees Namathponnan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rayees Namathponnan closed CLOUDSTACK-7522.
---

> RPM builds should exit status 1, if there are failure in MVN build 
> ---
>
> Key: CLOUDSTACK-7522
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7522
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Assignee: Rayees Namathponnan
>Priority: Critical
> Fix For: 4.5.0
>
>
> Steps to reproduce 
> > execute RPM build command 
> var=$(bash ./package.sh --pack noredist --build)
> > while executing MVN command kill java "killall -9 java"
> >see the output,  echo $var to see the output
> Expected result 
> RPM build should exited error
> Actual result
> RPM build not exited with error , it return Done, see the output 
> .cloudstack.framework.config.impl.ConfigDepotAdminTest log4j:WARN No 
> appenders could be found for logger 
> (org.apache.cloudstack.framework.config.impl.ConfigDepotImpl). log4j:WARN 
> Please initialize the log4j system properly. log4j:WARN See 
> http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. Tests 
> run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.091 sec Results : 
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] --- 
> maven-jar-plugin:2.4:jar (default-jar) @ cloud-framework-config --- [INFO] 
> Building jar: 
> /root/cloudplatform/build/source/dist/rpmbuild/BUILD/cloudstack-4.5.0-SNAPSHOT/framework/config/target/cloud-framework-config-4.5.0-SNAPSHOT.jar
>  [INFO] [INFO] --- maven-site-plugin:3.3:attach-descriptor 
> (attach-descriptor) @ cloud-framework-config --- [INFO] [INFO] 
>  
> [INFO] Building Apache CloudStack API 4.5.0-SNAPSHOT [INFO] 
>  
> [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ cloud-api 
> --- [INFO] Deleting 
> /root/cloudplatform/build/source/dist/rpmbuild/BUILD/cloudstack-4.5.0-SNAPSHOT/api
>  (includes = [target, dist], excludes = []) [INFO] [INFO] --- 
> maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ cloud-api --- 
> [INFO] Starting audit... Audit done. [INFO] [INFO] --- 
> maven-remote-resources-plugin:1.3:process (default) @ cloud-api --- [INFO] 
> [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
> cloud-api --- [debug] execute contextualize [INFO] Using 'UTF-8' encoding to 
> copy filtered resources. [INFO] Copying 4 resources [INFO] Copying 3 
> resources [INFO] [INFO] --- maven-compiler-plugin:2.5.1:compile 
> (default-compile) @ cloud-api --- [INFO] Compiling 939 source files to 
> /root/cloudplatform/build/source/dist/rpmbuild/BUILD/cloudstack-4.5.0-SNAPSHOT/api/target/classes
>  RPM build errors: Done
> [root@build-test centos63]# vi package.sh
> Looks like this is happening after below commit 
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=7ea7deded031b43042c68db0f7c5c6c8b21c18c2
> if revert this commit rpm exit with return 1, if there are issue with mvn 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CLOUDSTACK-7671) [RHEL7] management server failed to start once machine is rebooted

2014-11-12 Thread Rayees Namathponnan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rayees Namathponnan updated CLOUDSTACK-7671:

Assignee: Damodar Reddy T  (was: Rayees Namathponnan)

> [RHEL7] management server failed to start once machine is rebooted
> --
>
> Key: CLOUDSTACK-7671
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7671
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Damodar Reddy T
>Assignee: Damodar Reddy T
>
> Repro stesp:
> Create a rhel 7 host
> Install MS
> Start MS
> Once MS is up and running . Reboot MS . Notice Cloudstack-management service  
> status
> Bug:
> Notice MS fails to start even after calling service cloudstack-management 
> restart it failed to start
> systemctl status cloudstack-management.service
> cloudstack-management.service - Citrix Cloud Plaltform
>Loaded: loaded (/usr/lib/systemd/system/cloudstack-management.service; 
> enabled)
>Active: failed (Result: exit-code) since Tue 2014-09-23 12:10:09 IST; 1min 
> 28s ago
>   Process: 4618 ExecStart=/usr/sbin/cloudstack-management start (code=exited, 
> status=1/FAILURE)
> Sep 23 12:10:09 Rack1Pod1Host27 systemd[1]: Starting Citrix Cloud Plaltform...
> Sep 23 12:10:09 Rack1Pod1Host27 cloudstack-management[4618]: 
> /usr/sbin/tomcat: line 50: /var/run/cloudstack-management.pid: Permission 
> denied
> Sep 23 12:10:09 Rack1Pod1Host27 systemd[1]: cloudstack-management.service: 
> control process exited, code=exited status=1
> Sep 23 12:10:09 Rack1Pod1Host27 systemd[1]: Failed to start Citrix Cloud 
> Plaltform.
> Sep 23 12:10:09 Rack1Pod1Host27 systemd[1]: Unit 
> cloudstack-management.service entered failed state.
> [root@Rack1Pod1Host27 run]#
> service  cloudstack-management status
> Redirecting to /bin/systemctl status  cloudstack-management.service
> cloudstack-management.service - Citrix Cloud Plaltform
>Loaded: loaded (/usr/lib/systemd/system/cloudstack-management.service; 
> enabled)
>Active: failed (Result: exit-code) since Tue 2014-09-23 12:14:05 IST; 8s 
> ago
>   Process: 4691 ExecStart=/usr/sbin/cloudstack-management start (code=exited, 
> status=1/FAILURE)
> Sep 23 12:14:05 Rack1Pod1Host27 cloudstack-management[4691]: 
> /usr/sbin/tomcat: line 50: /var/run/cloudstack-management.pid: Permission 
> denied
> Sep 23 12:14:05 Rack1Pod1Host27 systemd[1]: cloudstack-management.service: 
> control process exited, code=exited status=1
> Sep 23 12:14:05 Rack1Pod1Host27 systemd[1]: Failed to start Citrix Cloud 
> Plaltform.
> Sep 23 12:14:05 Rack1Pod1Host27 systemd[1]: Unit 
> cloudstack-management.service entered failed state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CLOUDSTACK-7676) Usage server failed to start if default java version is 1.6

2014-11-12 Thread Rayees Namathponnan (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rayees Namathponnan resolved CLOUDSTACK-7676.
-
Resolution: Fixed

> Usage server failed to start if default java version is 1.6
> ---
>
> Key: CLOUDSTACK-7676
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7676
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.5.0
>Reporter: Rayees Namathponnan
>Assignee: Rayees Namathponnan
>Priority: Critical
> Fix For: 4.5.0
>
>
> Steps to reproduce
> Install usage server on RHEL 6.3 machine
> check default. java version
> start usage server
> Result
> If default java versionis java 1.6, then management serer will fails to start 
> Solution
> While starting usage server, we need to check java 1.7 exist or not, if exist 
> then we need to start usage server with java 1.7
>   #The first existing directory is used for JAVA_HOME (if JAVA_HOME is not 
> defined in $DEFAULT)
>   if   [[ ! -d "$JAVA_HOME" && -d /usr/lib/jvm/jre-1.7.0 ]]; then
> export JAVA_HOME=/usr/lib/jvm/jre-1.7.0
> PATH=$JAVA_HOME/bin:$PATH
>   fi
>   # use $JAVA_HOME if defined
>   if [ -n "$JAVA_HOME" ] ; then
> return
>   fi



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-7891) Fix failure in integration.component.test_escalations_instances.TestInstances/test_15_revert_vm_to_snapshot.

2014-11-12 Thread Sangeetha Hariharan (JIRA)
Sangeetha Hariharan created CLOUDSTACK-7891:
---

 Summary: Fix failure in 
integration.component.test_escalations_instances.TestInstances/test_15_revert_vm_to_snapshot.
 Key: CLOUDSTACK-7891
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7891
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Test
Reporter: Sangeetha Hariharan


Fix failure in 
integration.component.test_escalations_instances.TestInstances/test_15_revert_vm_to_snapshot.


Following exception seen when this test case is executed:
Disallowed failure 
integration.component.test_escalations_instances.TestInstances/test_15_revert_vm_to_snapshot:
 RevertToVMSnapshotCmd failed: VM Snapshot revert not allowed. This will result 
in VM state change. You can revert running VM to disk and memor



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7857) CitrixResourceBase wrongly calculates total memory on hosts with a lot of memory and large Dom0

2014-11-12 Thread Rohit Yadav (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208649#comment-14208649
 ] 

Rohit Yadav commented on CLOUDSTACK-7857:
-

Do you propose we reduce the value by 1024 MB? So, the corner case of >1GB VM 
migration won't fail, or is there a better way to calculate the RAM value?

> CitrixResourceBase wrongly calculates total memory on hosts with a lot of 
> memory and large Dom0
> ---
>
> Key: CLOUDSTACK-7857
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7857
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: Future, 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1, 4.6.0
>Reporter: Joris van Lieshout
>Priority: Blocker
>
> We have hosts with 256GB memory and 4GB dom0. During startup ACS calculates 
> available memory using this formula:
> CitrixResourceBase.java
>   protected void fillHostInfo
>   ram = (long) ((ram - dom0Ram - _xs_memory_used) * 
> _xs_virtualization_factor);
> In our situation:
>   ram = 274841497600
>   dom0Ram = 4269801472
>   _xs_memory_used = 128 * 1024 * 1024L = 134217728
>   _xs_virtualization_factor = 63.0/64.0 = 0,984375
>   (274841497600 - 4269801472 - 134217728) * 0,984375 = 266211892800
> This is in fact not the actual amount of memory available for instances. The 
> difference in our situation is a little less then 1GB. On this particular 
> hypervisor Dom0+Xen uses about 9GB.
> As the comment above the definition of XsMemoryUsed allready stated it's time 
> to review this logic. 
> "//Hypervisor specific params with generic value, may need to be overridden 
> for specific versions"
> The effect of this bug is that when you put a hypervisor in maintenance it 
> might try to move instances (usually small instances (<1GB)) to a host that 
> in fact does not have enought free memory.
> This exception is thrown:
> ERROR [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-3:ctx-09aca6e9 
> work-8981) Terminating HAWork[8981-Migration-4482-Running-Migrating]
> com.cloud.utils.exception.CloudRuntimeException: Unable to migrate due to 
> Catch Exception com.cloud.utils.exception.CloudRuntimeException: Migration 
> failed due to com.cloud.utils.exception.CloudRuntim
> eException: Unable to migrate VM(r-4482-VM) from 
> host(6805d06c-4d5b-4438-a245-7915e93041d9) due to Task failed! Task record:   
>   uuid: 645b63c8-1426-b412-7b6a-13d61ee7ab2e
>nameLabel: Async.VM.pool_migrate
>  nameDescription: 
>allowedOperations: []
>currentOperations: {}
>  created: Thu Nov 06 13:44:14 CET 2014
> finished: Thu Nov 06 13:44:14 CET 2014
>   status: failure
>   residentOn: com.xensource.xenapi.Host@b42882c6
> progress: 1.0
> type: 
>   result: 
>errorInfo: [HOST_NOT_ENOUGH_FREE_MEMORY, 272629760, 263131136]
>  otherConfig: {}
>subtaskOf: com.xensource.xenapi.Task@aaf13f6f
> subtasks: []
> at 
> com.cloud.vm.VirtualMachineManagerImpl.migrate(VirtualMachineManagerImpl.java:1840)
> at 
> com.cloud.vm.VirtualMachineManagerImpl.migrateAway(VirtualMachineManagerImpl.java:2214)
> at 
> com.cloud.ha.HighAvailabilityManagerImpl.migrate(HighAvailabilityManagerImpl.java:610)
> at 
> com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.runWithContext(HighAvailabilityManagerImpl.java:865)
> at 
> com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.access$000(HighAvailabilityManagerImpl.java:822)
> at 
> com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread$1.run(HighAvailabilityManagerImpl.java:834)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at 
> com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.run(HighAvailabilityManagerImpl.java:831)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7073) Account/User creation: able to create user with the same name in the same domain in Clustered MS setup

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208584#comment-14208584
 ] 

ASF subversion and git services commented on CLOUDSTACK-7073:
-

Commit a4b92e908aa6271d3aa94656ca5d4d1ac6fd5c6c in cloudstack's branch 
refs/heads/4.5 from [~prachidamle]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a4b92e9 ]

CLOUDSTACK-7590 Deletion of Account is not deleting the account from the 
database

Revert "CLOUDSTACK-7073: Added domainId field to the user table in order to 
restrict duplicated users creation on the db level"

This reverts commit 5a96d8ef5cbc88df366016ae9dd7ee46e4ca417a.

Conflicts:
setup/db/db/schema-440to450.sql


> Account/User creation: able to create user with the same name in the same 
> domain in Clustered MS setup
> --
>
> Key: CLOUDSTACK-7073
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7073
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
>Reporter: Alena Prokharchyk
>Assignee: Alena Prokharchyk
> Fix For: 4.5.0
>
>
> In the Java code we prohibit user to have duplicated names inside the same 
> domain. But in the DB the constraint is missing in cloud.account/cloud.user 
> table, so it is still possible to violate the rule by initiating the create 
> call from parallel threads issued either by the same MS, or by multiple MS in 
> the clustered MS setup.
> To fix, have to introduce some kind of the global lock, or db constraint 
> preventing multiple threads to insert the record with the same username.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (CLOUDSTACK-7590) Deletion of Account is not deleting the account from the database

2014-11-12 Thread Prachi Damle (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Prachi Damle resolved CLOUDSTACK-7590.
--
Resolution: Fixed

> Deletion of Account is not deleting the account from the database
> -
>
> Key: CLOUDSTACK-7590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Prachi Damle
>Priority: Critical
> Fix For: 4.5.0
>
>
> Deletion of account marks the account as removed in the database but doesnt 
> remove the record from the database as shown below:
> 
> mysql> select * from account where removed is not null \G
> *** 1. row ***
>  id: 7
>account_name: CSRegularVPNClientUser
>uuid: 96e06a77-fa96-4e38-b380-023d406d445e
>type: 0
>   domain_id: 1
>   state: enabled
> removed: 2014-09-20 00:33:41
>  cleanup_needed: 0
>  network_domain: NULL
> default_zone_id: NULL
> default: 0
> 1 row in set (0.00 sec)
> mysql>
> *If anyone wants to recreate the account with the same name. It fails with 
> the below exception:*
> {noformat}
> 2014-09-20 00:27:05,880 DEBUG [c.c.u.AccountManagerImpl] 
> (catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) Creating user: 
> CSRegularVPNClientUser, accountId: 6 timezone:null
> 2014-09-20 00:27:05,882 DEBUG [c.c.u.d.T.Transaction] 
> (catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) Rolling back the 
> transaction: Time = 16 Name =  catalina-exec-11; called by 
> -TransactionLegacy.rollback:902-TransactionLegacy.removeUpTo:845-TransactionLegacy.close:669-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy67.persist:-1-AccountManagerImpl.createUser:1962-AccountManagerImpl$2.doInTransaction:1039-AccountManagerImpl$2.doInTransaction:1027
> 2014-09-20 00:27:05,898 ERROR [c.c.a.ApiServer] 
> (catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) unhandled exception 
> executing api command: [Ljava.lang.String;@5b4cfa82
> javax.persistence.EntityExistsException: Entity already exists:
> at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1398)
> at com.cloud.user.dao.UserDaoImpl.persist(UserDaoImpl.java:141)
> at com.cloud.user.dao.UserDaoImpl.persist(UserDaoImpl.java:33)
> at sun.reflect.GeneratedMethodAccessor105.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy67.persist(Unknown Source)
> at 
> com.cloud.user.AccountManagerImpl.createUser(AccountManagerImpl.java:1962)
> at 
> com.cloud.user.AccountManagerImpl$2.doInTransaction(AccountManagerImpl.java:1039)
> at 
> com.cloud.user.AccountManagerImpl$2.doInTransaction(AccountManagerImpl.java:1027)
> at 
> com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49)
> at com.cloud.utils.db.Transaction.execute(Transaction.java:37)
> at com.cloud.utils.db.Transaction.execute(Transaction.java:46)
> at 
> com.cloud.user.AccountManagerImpl.createUserAccount(AccountManagerImpl.java:1027)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang

[jira] [Commented] (CLOUDSTACK-7590) Deletion of Account is not deleting the account from the database

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208583#comment-14208583
 ] 

ASF subversion and git services commented on CLOUDSTACK-7590:
-

Commit a4b92e908aa6271d3aa94656ca5d4d1ac6fd5c6c in cloudstack's branch 
refs/heads/4.5 from [~prachidamle]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a4b92e9 ]

CLOUDSTACK-7590 Deletion of Account is not deleting the account from the 
database

Revert "CLOUDSTACK-7073: Added domainId field to the user table in order to 
restrict duplicated users creation on the db level"

This reverts commit 5a96d8ef5cbc88df366016ae9dd7ee46e4ca417a.

Conflicts:
setup/db/db/schema-440to450.sql


> Deletion of Account is not deleting the account from the database
> -
>
> Key: CLOUDSTACK-7590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Prachi Damle
>Priority: Critical
> Fix For: 4.5.0
>
>
> Deletion of account marks the account as removed in the database but doesnt 
> remove the record from the database as shown below:
> 
> mysql> select * from account where removed is not null \G
> *** 1. row ***
>  id: 7
>account_name: CSRegularVPNClientUser
>uuid: 96e06a77-fa96-4e38-b380-023d406d445e
>type: 0
>   domain_id: 1
>   state: enabled
> removed: 2014-09-20 00:33:41
>  cleanup_needed: 0
>  network_domain: NULL
> default_zone_id: NULL
> default: 0
> 1 row in set (0.00 sec)
> mysql>
> *If anyone wants to recreate the account with the same name. It fails with 
> the below exception:*
> {noformat}
> 2014-09-20 00:27:05,880 DEBUG [c.c.u.AccountManagerImpl] 
> (catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) Creating user: 
> CSRegularVPNClientUser, accountId: 6 timezone:null
> 2014-09-20 00:27:05,882 DEBUG [c.c.u.d.T.Transaction] 
> (catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) Rolling back the 
> transaction: Time = 16 Name =  catalina-exec-11; called by 
> -TransactionLegacy.rollback:902-TransactionLegacy.removeUpTo:845-TransactionLegacy.close:669-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy67.persist:-1-AccountManagerImpl.createUser:1962-AccountManagerImpl$2.doInTransaction:1039-AccountManagerImpl$2.doInTransaction:1027
> 2014-09-20 00:27:05,898 ERROR [c.c.a.ApiServer] 
> (catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) unhandled exception 
> executing api command: [Ljava.lang.String;@5b4cfa82
> javax.persistence.EntityExistsException: Entity already exists:
> at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1398)
> at com.cloud.user.dao.UserDaoImpl.persist(UserDaoImpl.java:141)
> at com.cloud.user.dao.UserDaoImpl.persist(UserDaoImpl.java:33)
> at sun.reflect.GeneratedMethodAccessor105.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy67.persist(Unknown Source)
> at 
> com.cloud.user.AccountManagerImpl.createUser(AccountManagerImpl.java:1962)
> at 
> com.cloud.user.AccountManagerImpl$2.doInTransaction(AccountManagerImpl.java:1039)
> at 
> com.cloud.user.AccountManagerImpl$2.doInTransaction(AccountManagerImpl.java:1027)
> at 
> com.cloud.utils.db.Transa

[jira] [Reopened] (CLOUDSTACK-7073) Account/User creation: able to create user with the same name in the same domain in Clustered MS setup

2014-11-12 Thread Prachi Damle (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Prachi Damle reopened CLOUDSTACK-7073:
--

> Account/User creation: able to create user with the same name in the same 
> domain in Clustered MS setup
> --
>
> Key: CLOUDSTACK-7073
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7073
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
>Reporter: Alena Prokharchyk
>Assignee: Alena Prokharchyk
> Fix For: 4.5.0
>
>
> In the Java code we prohibit user to have duplicated names inside the same 
> domain. But in the DB the constraint is missing in cloud.account/cloud.user 
> table, so it is still possible to violate the rule by initiating the create 
> call from parallel threads issued either by the same MS, or by multiple MS in 
> the clustered MS setup.
> To fix, have to introduce some kind of the global lock, or db constraint 
> preventing multiple threads to insert the record with the same username.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7073) Account/User creation: able to create user with the same name in the same domain in Clustered MS setup

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208536#comment-14208536
 ] 

ASF subversion and git services commented on CLOUDSTACK-7073:
-

Commit 52bc084231dc47bb85ff6c02f80bd99e104e7624 in cloudstack's branch 
refs/heads/master from [~prachidamle]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=52bc084 ]

CLOUDSTACK-7590 Deletion of Account is not deleting the account from the 
database

Revert "CLOUDSTACK-7073: Added domainId field to the user table in order to 
restrict duplicated users creation on the db level"

This reverts commit 5a96d8ef5cbc88df366016ae9dd7ee46e4ca417a.

Conflicts:
setup/db/db/schema-440to450.sql


> Account/User creation: able to create user with the same name in the same 
> domain in Clustered MS setup
> --
>
> Key: CLOUDSTACK-7073
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7073
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
>Reporter: Alena Prokharchyk
>Assignee: Alena Prokharchyk
> Fix For: 4.5.0
>
>
> In the Java code we prohibit user to have duplicated names inside the same 
> domain. But in the DB the constraint is missing in cloud.account/cloud.user 
> table, so it is still possible to violate the rule by initiating the create 
> call from parallel threads issued either by the same MS, or by multiple MS in 
> the clustered MS setup.
> To fix, have to introduce some kind of the global lock, or db constraint 
> preventing multiple threads to insert the record with the same username.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7590) Deletion of Account is not deleting the account from the database

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208534#comment-14208534
 ] 

ASF subversion and git services commented on CLOUDSTACK-7590:
-

Commit 52bc084231dc47bb85ff6c02f80bd99e104e7624 in cloudstack's branch 
refs/heads/master from [~prachidamle]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=52bc084 ]

CLOUDSTACK-7590 Deletion of Account is not deleting the account from the 
database

Revert "CLOUDSTACK-7073: Added domainId field to the user table in order to 
restrict duplicated users creation on the db level"

This reverts commit 5a96d8ef5cbc88df366016ae9dd7ee46e4ca417a.

Conflicts:
setup/db/db/schema-440to450.sql


> Deletion of Account is not deleting the account from the database
> -
>
> Key: CLOUDSTACK-7590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7590
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Prachi Damle
>Priority: Critical
> Fix For: 4.5.0
>
>
> Deletion of account marks the account as removed in the database but doesnt 
> remove the record from the database as shown below:
> 
> mysql> select * from account where removed is not null \G
> *** 1. row ***
>  id: 7
>account_name: CSRegularVPNClientUser
>uuid: 96e06a77-fa96-4e38-b380-023d406d445e
>type: 0
>   domain_id: 1
>   state: enabled
> removed: 2014-09-20 00:33:41
>  cleanup_needed: 0
>  network_domain: NULL
> default_zone_id: NULL
> default: 0
> 1 row in set (0.00 sec)
> mysql>
> *If anyone wants to recreate the account with the same name. It fails with 
> the below exception:*
> {noformat}
> 2014-09-20 00:27:05,880 DEBUG [c.c.u.AccountManagerImpl] 
> (catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) Creating user: 
> CSRegularVPNClientUser, accountId: 6 timezone:null
> 2014-09-20 00:27:05,882 DEBUG [c.c.u.d.T.Transaction] 
> (catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) Rolling back the 
> transaction: Time = 16 Name =  catalina-exec-11; called by 
> -TransactionLegacy.rollback:902-TransactionLegacy.removeUpTo:845-TransactionLegacy.close:669-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy67.persist:-1-AccountManagerImpl.createUser:1962-AccountManagerImpl$2.doInTransaction:1039-AccountManagerImpl$2.doInTransaction:1027
> 2014-09-20 00:27:05,898 ERROR [c.c.a.ApiServer] 
> (catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) unhandled exception 
> executing api command: [Ljava.lang.String;@5b4cfa82
> javax.persistence.EntityExistsException: Entity already exists:
> at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1398)
> at com.cloud.user.dao.UserDaoImpl.persist(UserDaoImpl.java:141)
> at com.cloud.user.dao.UserDaoImpl.persist(UserDaoImpl.java:33)
> at sun.reflect.GeneratedMethodAccessor105.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy67.persist(Unknown Source)
> at 
> com.cloud.user.AccountManagerImpl.createUser(AccountManagerImpl.java:1962)
> at 
> com.cloud.user.AccountManagerImpl$2.doInTransaction(AccountManagerImpl.java:1039)
> at 
> com.cloud.user.AccountManagerImpl$2.doInTransaction(AccountManagerImpl.java:1027)
> at 
> com.cloud.utils.db.Tra

[jira] [Closed] (CLOUDSTACK-7626) SAMLUtilsTest failing inconsistently during build

2014-11-12 Thread David Nalley (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Nalley closed CLOUDSTACK-7626.

Resolution: Fixed

This (at least on jenkins.bacd) is not failing. 

> SAMLUtilsTest failing inconsistently during build  
> ---
>
> Key: CLOUDSTACK-7626
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7626
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.5.0
> Environment: 4.5 
>Reporter: Rayees Namathponnan
>Priority: Blocker
> Fix For: 4.5.0
>
>
> 4.5 build failing inconsistently while running unit test, unning 
> org.apache.cloudstack.utils.auth.SAMLUtilsTest
> I have seen this issue multiple times, after the some merge happened 2 week 
> ago, 
>  
> Build fails with below error 
> [INFO] --- maven-surefire-plugin:2.12:test (default-test) @ cloud-utils ---
> [INFO] Surefire report directory: 
> /root/jenkins/build/workspace/CloudPlatform-4.x-rhel63_Simulator/internal-cloudstack/dist/rpmbuild/BUILD/cloudstack-4.5.0-SNAPSHOT/utils/target/surefire-reports
> ---
>  T E S T S
> ---
> Running org.apache.cloudstack.utils.auth.SAMLUtilsTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.245 sec
> Running com.cloud.utils.TestProfiler
> Configure log4j with default properties
> 2014-09-24 03:38:16,415 INFO  [cloud.utils.TestProfiler] (main:) 
> testProfiler() started
> 2014-09-24 03:38:17,417 INFO  [cloud.utils.TestProfiler] (main:) Duration : 
> 1000
> 2014-09-24 03:38:17,419 INFO  [cloud.utils.TestProfiler] (main:) 
> testProfiler() stopped
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.012 sec
> Running com.cloud.utils.ScriptTest
> 2014-09-24 03:38:17,526 DEBUG [utils.script.Script] (main:) Executing: 
> /bin/echo bar 
> 2014-09-24 03:38:17,537 DEBUG [utils.script.Script] (main:) Execution is 
> successful.
> 2014-09-24 03:38:17,545 DEBUG [utils.script.Script] (main:) Looking for pwd 
> in the classpath
> 2014-09-24 03:38:17,545 DEBUG [utils.script.Script] (main:) System resource: 
> null
> 2014-09-24 03:38:17,546 DEBUG [utils.script.Script] (main:) Classpath 
> resource: null
> 2014-09-24 03:38:17,549 DEBUG [utils.script.Script] (main:) Executing: 
> /bin/bash -c echo 'hello world!' 
> 2014-09-24 03:38:17,551 DEBUG [utils.script.Script] (main:) Execution is 
> successful.
> 2014-09-24 03:38:17,551 WARN  [utils.script.Script] (main:) Exception: 
> /bin/bash -c echo 'hello world!' 
> java.lang.IllegalArgumentException
>   at com.cloud.utils.ScriptTest$1.interpret(ScriptTest.java:107)
>   at com.cloud.utils.script.Script.execute(Script.java:220)
>   at 
> com.cloud.utils.ScriptTest.executeWithOutputInterpreter(ScriptTest.java:103)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl

[jira] [Commented] (CLOUDSTACK-7642) [Upgrade]java.lang.ClassNotFoundException after upgrading to 4.5 from 4.3.0 with Xenserver HV.

2014-11-12 Thread David Nalley (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208506#comment-14208506
 ] 

David Nalley commented on CLOUDSTACK-7642:
--

[~devdeep]  Is this still an issue? Any idea on timeline for a fix? 



> [Upgrade]java.lang.ClassNotFoundException after upgrading to 4.5 from 4.3.0 
> with Xenserver HV.
> --
>
> Key: CLOUDSTACK-7642
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7642
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Upgrade
>Affects Versions: 4.5.0
> Environment: upgrade from 4.3.0 to 4.5 using Xen server 6.2 
>Reporter: manasaveloori
>Assignee: Devdeep Singh
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: management-server.rar, mysqldump4.5.rar, 
> mysqldumpBeforeUp.rar
>
>
> 1. Deployed 4.3.0 CS with 1zone,1 pod,1cluster,2 Xen 6.2 HVs using 4.3.0 
> build.
> 2. Registered the 4.5 template as "systemvm-xenserver-4.5"
> 3. Upgraded to 4.5 and started the MS.
> Observation:
> Observed the following exception in MS logs .Hosts went into disconnected 
> stated.
> 2014-09-29 13:45:26,849 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (ClusteredAgentManager Timer:ctx-7b268e53) Loading directly connected host 
> 1(Rack1Pod1Host29)
> 2014-09-29 13:45:26,851 WARN  [c.c.r.DiscovererBase] (ClusteredAgentManager 
> Timer:ctx-7b268e53) Unable to find class 
> com.cloud.hypervisor.xen.resource.XenServer620Resource
> java.lang.ClassNotFoundException: 
> com.cloud.hypervisor.xen.resource.XenServer620Resource
> at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1484)
> at 
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1329)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:186)
> at 
> com.cloud.resource.DiscovererBase.getResource(DiscovererBase.java:89)
> at 
> com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:150)
> at 
> com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:680)
> at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:219)
> at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:185)
> at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:99)
> at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.runInContext(ClusteredAgentManagerImpl.java:235)
> at 
> org.apache.cloudstack.managed.context.ManagedContextTimerTask$1.runInContext(ManagedContextTimerTask.java:30)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at 
> org.apache.cloudstack.managed.context.ManagedContextTimerTask.run(ManagedContextTimerTask.java:27)
> at java.util.TimerThread.mainLoop(Timer.java:555)
> at java.util.TimerThread.run(Timer.java:505)
> 2014-09-29 13:45:26,852 WARN  [c.c.a.m.AgentManagerImpl] 
> (ClusteredAgentManager Timer:ctx-7b268e53) Unable to load the resource: 1
> 2014-09-29 13:45:26,853 DEBUG [c.c.h.Status] (ClusteredAgentManager 
> Timer:ctx-7b268e53) Transition:[Resource state = Enabled, Agent event = 
> AgentDisconnected, Host id = 1, name = Rack1Pod1Host29]
> Attaching the dumps and logs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7645) Many instances of "???label.*???"

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208350#comment-14208350
 ] 

ASF subversion and git services commented on CLOUDSTACK-7645:
-

Commit 68745ae9b1652393974f457137c9c7c1df333810 in cloudstack's branch 
refs/heads/master from [~bfederle]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=68745ae ]

CLOUDSTACK-7645: UI: Fix method for extending dictionary

Instead of mapping both dictionary JSP files to separate objects, extend
dictionary2's object onto single 'dictionary' object.

-- The previous approach was causing issues on certain dialogs, which were not
opening due to possible missing labels.


> Many instances of "???label.*???"
> -
>
> Key: CLOUDSTACK-7645
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7645
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.5.0
>Reporter: Stephen Turner
>Assignee: Mihaela Stoica
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: label.app.name.png
>
>
> We have many instances of "\?\?\?label.*\?\?\?" in the UI, including strings 
> I know were correct recently. (For example, I saw it on the certificate 
> upload UI, which was recently rewritten).
> I think something is wrong with the mechanism rather than individual 
> translations, so rather than creating a bug for each one, I have bundled them 
> together in this ticket. Individual tickets are linked from here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-7890) [Automation] Fix the script "test_security_groups.py" - Host password is hardcoded in the script

2014-11-12 Thread Chandan Purushothama (JIRA)
Chandan Purushothama created CLOUDSTACK-7890:


 Summary: [Automation] Fix the script "test_security_groups.py" - 
Host password is hardcoded in the script
 Key: CLOUDSTACK-7890
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7890
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Gaurav Aradhye
Priority: Critical
 Fix For: 4.5.0



Error Information:

{noformat}
Test router services for user account ... === TestName: test_01_dhcpOnlyRouter 
| Status : EXCEPTION ===
ERROR

==
ERROR: Test router services for user account
--
Traceback (most recent call last):
  File "/root/cloudstack/test/integration/component/test_security_groups.py", 
line 803, in test_01_dhcpOnlyRouter
"service dnsmasq status"
  File "/usr/local/lib/python2.7/dist-packages/marvin/lib/utils.py", line 198, 
in get_process_status
ssh = SshClient(hostip, port, username, password)
  File "/usr/local/lib/python2.7/dist-packages/marvin/sshClient.py", line 81, 
in __init__
raise internalError("SSH Connection Failed")
internalError: SSH Connection Failed
 >> begin captured stdout << -
=== TestName: test_01_dhcpOnlyRouter | Status : EXCEPTION ===
.
.
.
test_01_dhcpOnlyRouter 
(integration.component.test_security_groups.TestDhcpOnlyRouter): DEBUG: 
Response : [{cpuwithoverprovisioning : u'57600.0', version : u'4.5.0-SNAPSHOT', 
memorytotal : 7405795840, zoneid : u'9cec8ff5-9118-4630-a9a8-39a8f8385d57', 
cpunumber : 32, managementserverid : 151976082488674, cpuallocated : u'1.56%', 
memoryused : 1666909, id : u'a17339b5-b717-4721-9d93-f623b5a2e776', cpuused : 
u'0.02%', hypervisorversion : u'6.2.0', clusterid : 
u'ae8494c4-be80-46ad-931c-d16d26e28f4c', capabilities : u'xen-3.0-x86_64 , 
xen-3.0-x86_32p , hvm-3.0-x86_32 , hvm-3.0-x86_32p , hvm-3.0-x86_64', state : 
u'Up', memoryallocated : 805306368, networkkbswrite : 7096, cpuspeed : 1800, 
cpusockets : 2, type : u'Routing', events : u'PingTimeout; StartAgentRebalance; 
AgentDisconnected; Remove; AgentConnected; ManagementServerDown; 
ShutdownRequested; HostDown; Ping', zonename : u'XenRT-Zone-0', podid : 
u'a1df9408-4a7f-4aab-b114-492e1c3a3f58', clustertype : u'CloudManaged', hahost 
: False, lastpinged : u'1970-01-17T00:03:38+', ipaddress : u'10.220.113.7', 
disconnected : u'2014-11-12T14:20:30+', name : u'carp', networkkbsread : 
7306, created : u'2014-11-12T14:17:53+', clustername : 
u'XenRT-Zone-0-Pod-0-Cluster-0', hypervisor : u'XenServer', 
islocalstorageactive : False, resourcestate : u'Enabled', podname : 
u'XenRT-Zone-0-Pod-0'}]
test_01_dhcpOnlyRouter 
(integration.component.test_security_groups.TestDhcpOnlyRouter): DEBUG: Router 
ID: 35172b4f-8656-48e3-b2a4-c06697785eb2, state: Running
sshClient: DEBUG: Trying SSH Connection: Host:10.220.113.7 User:root
   Port:22 RetryCnt:60===
paramiko.transport: DEBUG: starting thread (client mode): 0x364be50L
paramiko.transport: INFO: Connected (version 2.0, client OpenSSH_4.3)
paramiko.transport: DEBUG: kex algos:[u'diffie-hellman-group-exchange-sha1', 
u'diffie-hellman-group14-sha1', u'diffie-hellman-group1-sha1'] server 
key:[u'ssh-rsa', u'ssh-dss'] client encrypt:[u'aes128-ctr', u'aes192-ctr', 
u'aes256-ctr', u'arcfour256', u'arcfour128', u'aes128-cbc', u'3des-cbc', 
u'blowfish-cbc', u'cast128-cbc', u'aes192-cbc', u'aes256-cbc', u'arcfour', 
u'rijndael-...@lysator.liu.se'] server encrypt:[u'aes128-ctr', u'aes192-ctr', 
u'aes256-ctr', u'arcfour256', u'arcfour128', u'aes128-cbc', u'3des-cbc', 
u'blowfish-cbc', u'cast128-cbc', u'aes192-cbc', u'aes256-cbc', u'arcfour', 
u'rijndael-...@lysator.liu.se'] client mac:[u'hmac-md5', u'hmac-sha1', 
u'hmac-ripemd160', u'hmac-ripemd...@openssh.com', u'hmac-sha1-96', 
u'hmac-md5-96'] server mac:[u'hmac-md5', u'hmac-sha1', u'hmac-ripemd160', 
u'hmac-ripemd...@openssh.com', u'hmac-sha1-96', u'hmac-md5-96'] client 
compress:[u'none', u'z...@openssh.com'] server compress:[u'none', 
u'z...@openssh.com'] client lang:[u''] server lang:[u''] kex follows?False
paramiko.transport: DEBUG: Ciphers agreed: local=aes128-ctr, remote=aes128-ctr
paramiko.transport: DEBUG: using kex diffie-hellman-group1-sha1; server key 
type ssh-rsa; cipher: local aes128-ctr, remote aes128-ctr; mac: local 
hmac-sha1, remote hmac-sha1; compression: local none, remote none
paramiko.transport: DEBUG: Switch to new keys ...
paramiko.transport: DEBUG: Adding ssh-rsa host key for 10.220.113.7: 
3bb7765e9dbc2247db28f2ae9c6dcff5
paramiko.transport: DEBUG: userauth is OK
paramiko.trans

[jira] [Created] (CLOUDSTACK-7889) Static NAT Public IPV4 from metadata server

2014-11-12 Thread Venkat Srinivasan (JIRA)
Venkat Srinivasan created CLOUDSTACK-7889:
-

 Summary: Static NAT Public IPV4 from metadata server
 Key: CLOUDSTACK-7889
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7889
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server, Network Controller
Affects Versions: 4.4.0
Reporter: Venkat Srinivasan


Hello All,
I have setup cloudstack 4.4 with advanced networking and created a VPC and a 
network tier. I launched a virtual machine inside this network which to the 
isolated network assigned as 
10.0.0.117
I acquired a new IP from the guest network , 172.16.10.110 and associated it 
with this virtual machine and applied the ACLS and Iam able to connect to this 
VM.
However, when  I try to get the public ip of the virtual machine from within 
the VM using the metadata server
http://metadata/latest/meta-data/public-ipv4

I get the IP address of the Source NAT associated with the VPC.  I expected the 
static nat IP I acquired and associated to the VM to be returned .Is this 
correct ? If so , is this a know bug ?
--
Thanks



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (CLOUDSTACK-7887) fail to push snapshot to secondary storage if using multipart using swift

2014-11-12 Thread Pierre-Luc Dion (JIRA)

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre-Luc Dion reassigned CLOUDSTACK-7887:
---

Assignee: Pierre-Luc Dion

> fail to push snapshot to secondary storage if using multipart using swift
> -
>
> Key: CLOUDSTACK-7887
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7887
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Hypervisor Controller, XenServer
>Affects Versions: 4.4.0, 4.4.1
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>
> Using Swift as secondary storage with XenServer,  creating a snapshot from a 
> big disk  will display as succeed in CloudStack but the snapshot file will 
> fail to upload in Swift.  So snapshot are not working for Swift with 
> XenServer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (CLOUDSTACK-7888) unable to create remote vpn because of special character in password

2014-11-12 Thread Tomasz Zieba (JIRA)
Tomasz Zieba created CLOUDSTACK-7888:


 Summary: unable to create remote vpn because of special character 
in password
 Key: CLOUDSTACK-7888
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7888
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Virtual Router
Affects Versions: 4.2.1, 4.4.1
 Environment: ACS 4.2.1  , ACS 4.4.1
Reporter: Tomasz Zieba


enter the password with a special character (#) statement causes the inability 
to remote vpn tunnel.

Please correct the code to enter password in quotes. For example:

Current situation:

root@r-2284-VM:/etc/ppp# cat chap-secrets
sin33 * CloudS980@#+=.-_ *

==> /var/log/daemon.log <==
Nov 12 16:28:19 r-2284-VM xl2tpd[9460]: control_finish: Connection closed to 
x.x.x.x, serial 0 ()
Nov 12 16:28:19 r-2284-VM xl2tpd[9460]: Terminating pppd: sending TERM signal 
to pid 9855


Expected situation:

root@r-2284-VM:/etc/ppp# cat chap-secrets
sin33 * "CloudS980@#+=.-_" *

Nov 12 16:28:59 r-2284-VM xl2tpd[9460]: Call established with x.x.x.x, Local: 
50127, Remote: 1, Serial: 0




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7645) Many instances of "???label.*???"

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208221#comment-14208221
 ] 

ASF subversion and git services commented on CLOUDSTACK-7645:
-

Commit d82e556dcd980bac50f27eaca284983808e04b1c in cloudstack's branch 
refs/heads/4.5 from [~mihaelas]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d82e556 ]

CLOUDSTACK-7645: [UI] Fixed incorrect label issues caused the dictionary split

In some cases the UI does not display the correct text, displaying 'label.xyz' 
instead of the localized string.
This appears to be due to the dictionary split: entries in dictionary2.jsp are 
not found because the dictionary has not been extended with dictionary2 as 
expected.

In this fix:
- Instead of extending the dictionary, we leave it as it is and change the 
localization function to look in the dictionary first and, if the item is not 
found there, then look in dictionary2.
- This way we are not depending on the extent() function to be called at the 
'right' time; In turn, the localization function will be aware of both 
dictionaries.
- In the future, when we add another dictionary, we will have to modify this 
function only.


> Many instances of "???label.*???"
> -
>
> Key: CLOUDSTACK-7645
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7645
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.5.0
>Reporter: Stephen Turner
>Assignee: Mihaela Stoica
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: label.app.name.png
>
>
> We have many instances of "\?\?\?label.*\?\?\?" in the UI, including strings 
> I know were correct recently. (For example, I saw it on the certificate 
> upload UI, which was recently rewritten).
> I think something is wrong with the mechanism rather than individual 
> translations, so rather than creating a bug for each one, I have bundled them 
> together in this ticket. Individual tickets are linked from here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7645) Many instances of "???label.*???"

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208222#comment-14208222
 ] 

ASF subversion and git services commented on CLOUDSTACK-7645:
-

Commit 4e820b37b0b8f5318e992330a3a9a7f6f9998cff in cloudstack's branch 
refs/heads/4.5 from [~mihaelas]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4e820b3 ]

CLOUDSTACK-7645

[UI] Fix incorrect strings 'label.no' and 'label.added.network.offering'

Conflicts:
ui/dictionary2.jsp


> Many instances of "???label.*???"
> -
>
> Key: CLOUDSTACK-7645
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7645
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.5.0
>Reporter: Stephen Turner
>Assignee: Mihaela Stoica
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: label.app.name.png
>
>
> We have many instances of "\?\?\?label.*\?\?\?" in the UI, including strings 
> I know were correct recently. (For example, I saw it on the certificate 
> upload UI, which was recently rewritten).
> I think something is wrong with the mechanism rather than individual 
> translations, so rather than creating a bug for each one, I have bundled them 
> together in this ticket. Individual tickets are linked from here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7566) Many jobs getting stuck in pending state and cloud is unusable

2014-11-12 Thread Rohit Yadav (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208179#comment-14208179
 ] 

Rohit Yadav commented on CLOUDSTACK-7566:
-

Should we backport the fix to 4.3 and 4.4 branches as well?

> Many jobs getting stuck in pending state and cloud is unusable
> --
>
> Key: CLOUDSTACK-7566
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7566
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.3.0
>Reporter: Min Chen
>Assignee: Min Chen
>Priority: Blocker
> Fix For: 4.5.0
>
>
> Many jobs are getting stuck with errors like:
> 2014-09-09 18:55:41,964 WARN [jobs.impl.AsyncJobMonitor] 
> (Timer-1:ctx-1e7a8a7e) Task (job-355415) has been pending for 690 seconds
> Even jobs that apparently succeed are getting the same error. Async job table 
> is not updated with complete even though job is completed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7749) AsyncJob GC thread cannot purge queue items that have been blocking for too long if exception is thrown in expunging some unfinished or completed old jobs, this wi

2014-11-12 Thread Rohit Yadav (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208180#comment-14208180
 ] 

Rohit Yadav commented on CLOUDSTACK-7749:
-

Should we backport this fix to 4.3 and 4.4 branches as well?

> AsyncJob GC thread cannot purge queue items that have been blocking for too 
> long if exception is thrown in expunging some unfinished or completed old 
> jobs, this will make some future jobs stuck.
> --
>
> Key: CLOUDSTACK-7749
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7749
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.3.0
>Reporter: Min Chen
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.5.0
>
>
> AsyncJobManager has a GC thread to clean up some unfinished job and complete 
> jobs that are too old. In this same thread, we are also forcefully cancel 
> blocking queue items if they've been staying there for too long. Currently if 
> there is an exception thrown in expunging one job, for example, like the one 
> below:
> 2014-10-14 17:57:26,347 INFO [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-67ae4177) Expunging unfinished job AsyncJobVO
> {id:18443, userId: 60, accountId: 69, instanceType: null, instanc eId: null, 
> cmd: com.cloud.vm.VmWorkStart, cmdInfo: 
> rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIACkoABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljb
>  
> HVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL
>  
> 01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cABFADwCdXQAGVZpcnR1YWxNYWNoaW5lTWFuY
>  
> WdlckltcGwAAHBwcHBwcHBzcgARamF2YS51dGlsLkhhc2hNYXAFB9rBwxZg0QMAAkYACmxvYWRGYWN0b3JJAAl0aHJlc2hvbGR4cD9MdwgQAXQAClZtUGFzc3dvcmR0ABxyTzBBQlhRQURuTmhkbVZrWDNCaGMzTjNiM0preHA,
>  cmdVersi on: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, 
> result: null, initMsid: 244536014864905, completeMsid: null, lastUpdated: 
> null, lastPolled: null, created: Wed Aug 20 18:14:13 EDT 2014}
> 2014-10-14 17:57:26,350 DEBUG [c.c.u.d.T.Transaction] 
> (AsyncJobMgr-Heartbeat-1:ctx-67ae4177) Rolling back the transaction: Time = 2 
> Name = AsyncJobMgr-Heartbeat-1; called by -TransactionLegacy.rollback:8
> 96-TransactionLegacy.removeUpTo:839-TransactionLegacy.close:663-TransactionContextInterceptor.invoke:35-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocat
> ion.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy151.expunge:-1-AsyncJobManagerImpl$8.doInTransactionWithoutResult:802-TransactionCallbackNoReturn.doInTransaction:25-Transaction$2.doInTransaction:49
> 2014-10-14 17:57:26,368 ERROR [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-67ae4177) Unexpected exception when trying to 
> execute queue item,
> com.cloud.utils.exception.CloudRuntimeException: DB Exception on: 
> com.mysql.jdbc.JDBC4PreparedStatement@39fdfb52: DELETE FROM async_job WHERE 
> async_job.id= 18443
> at com.cloud.utils.db.GenericDaoBase.expunge(GenericDaoBase.java:1144)
> at sun.reflect.GeneratedMethodAccessor247.invoke(Unknown Source)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:622)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at 
> com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:33)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at 
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at com.sun.proxy.$Proxy151.expunge(Unknown Source)
> at 
> org.apache.cloudstack.framework.

[jira] [Commented] (CLOUDSTACK-7566) Many jobs getting stuck in pending state and cloud is unusable

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208173#comment-14208173
 ] 

ASF subversion and git services commented on CLOUDSTACK-7566:
-

Commit 6df38427cffe9cab5a2a842571941a97a3a07b52 in cloudstack's branch 
refs/heads/master from [~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6df3842 ]

CLOUDSTACK-7566:Many jobs getting stuck in pending state and cloud is unusable.

(cherry picked from commit a2d85c8cae5f603bbcfcd3659c1207f0bfe461a7)

Signed-off-by: Rohit Yadav 

Conflicts:

framework/jobs/src/org/apache/cloudstack/framework/jobs/impl/AsyncJobManagerImpl.java


> Many jobs getting stuck in pending state and cloud is unusable
> --
>
> Key: CLOUDSTACK-7566
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7566
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.3.0
>Reporter: Min Chen
>Assignee: Min Chen
>Priority: Blocker
> Fix For: 4.5.0
>
>
> Many jobs are getting stuck with errors like:
> 2014-09-09 18:55:41,964 WARN [jobs.impl.AsyncJobMonitor] 
> (Timer-1:ctx-1e7a8a7e) Task (job-355415) has been pending for 690 seconds
> Even jobs that apparently succeed are getting the same error. Async job table 
> is not updated with complete even though job is completed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7583) Send statistics collected by StatsCollector to optional Graphite host

2014-11-12 Thread ASF subversion and git services (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208163#comment-14208163
 ] 

ASF subversion and git services commented on CLOUDSTACK-7583:
-

Commit 95daa14e2ac4bec09cfad890220e98eaa577c134 in cloudstack's branch 
refs/heads/master from [~widodh]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=95daa14 ]

CLOUDSTACK-7583: Fix NPE caused by previous commit


> Send statistics collected by StatsCollector to optional Graphite host
> -
>
> Key: CLOUDSTACK-7583
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7583
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: Future
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
> Fix For: 4.6.0
>
>
> It would be very useful if the StatsCollector inside the management server 
> could also send all the stats collected to a Graphite server in addition to 
> the usage database.
> This allows for easy graph generation for CPU, Network and Disk I/O of 
> Instances and hosts.
> Via a global setting we can configure:
> * Graphite host
> * Graphite port
> * Key prefix
> We can then send Instance and Host information, like:
> cloudstack.stats.instances..cpu.num 1
> cloudstack.stats.instances..cpu.utilization 50
> cloudstack.stats.instances..network.read_kbs 4817
> cloudstack.stats.instances..network.write_kbs 672



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (CLOUDSTACK-7887) fail to push snapshot to secondary storage if using multipart using swift

2014-11-12 Thread Pierre-Luc Dion (JIRA)

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208098#comment-14208098
 ] 

Pierre-Luc Dion commented on CLOUDSTACK-7887:
-

fix to be committed shortly,  the issue is in /etc/xapi.d/plugins/swiftxen file.


> fail to push snapshot to secondary storage if using multipart using swift
> -
>
> Key: CLOUDSTACK-7887
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7887
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Hypervisor Controller, XenServer
>Affects Versions: 4.4.0, 4.4.1
>Reporter: Pierre-Luc Dion
>
> Using Swift as secondary storage with XenServer,  creating a snapshot from a 
> big disk  will display as succeed in CloudStack but the snapshot file will 
> fail to upload in Swift.  So snapshot are not working for Swift with 
> XenServer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


  1   2   >