[jira] [Commented] (CLOUDSTACK-8415) [VMware] SSVM shutdown during snapshot operation results in disks to be left behind
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679289#comment-14679289 ] ASF GitHub Bot commented on CLOUDSTACK-8415: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/540#issuecomment-129227064 Who wants to step in and finish this work? It seems the original author is not able to finish it. If no one steps in, we'll have to close the PR without merging it so please help :-). [VMware] SSVM shutdown during snapshot operation results in disks to be left behind Key: CLOUDSTACK-8415 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8415 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.6.0 Partial disks are residue of a failed snapshot operation caused by SSVM reboot/shutdown. The disks do not get cleaned up on secondary storage and need to be cleaned up manually to release storage. +Steps to reproduce+ 1. Initiate a volume snapshot operation. 2. Destroy SSVM while the operation is in progress. 3. Check the snapshot folder in secondary storage - Files including disks are present in the folder and are never cleaned up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8602) MigrateVirtualMachineWithVolume leaves old chain data for volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679285#comment-14679285 ] ASF GitHub Bot commented on CLOUDSTACK-8602: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/548#issuecomment-129227023 Who wants to step in and finish this work? It seems the original author is not able to finish it. If no one steps in, we'll have to close the PR without merging it so please help :-). MigrateVirtualMachineWithVolume leaves old chain data for volume Key: CLOUDSTACK-8602 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8602 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.6.0 CS maintains chain info of every volume in DB, where chain info is the complete volume path. When the volumes associated with a VM are migrated to different storage pool, their chain info changes, but this information is not reflected in the DB. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8601) VMFS storage added as local storage can be re added as shared storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679287#comment-14679287 ] ASF GitHub Bot commented on CLOUDSTACK-8601: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/547#issuecomment-129227036 Who wants to step in and finish this work? It seems the original author is not able to finish it. If no one steps in, we'll have to close the PR without merging it so please help :-). VMFS storage added as local storage can be re added as shared storage. -- Key: CLOUDSTACK-8601 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8601 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.6.0 During host discovery, if local storage is enabled for a zone, all VMFS datastores that are mounted on just one host (i.e. not shared) will be added as local storage is CloudStack. When admin adds a VMFS datastore as shared, CS doesn't verify if the storage has already been added as local storage in the zone. This means the same primary storage is added as different storages in CS and this leads to failure in operations related to disks because of wrong storage look ups. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8610) [VMWARE] Unable to attach 7th Disk to a Windows server 2012R2 instance
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679284#comment-14679284
]
ASF GitHub Bot commented on CLOUDSTACK-8610:
Github user remibergsma commented on the pull request:
https://github.com/apache/cloudstack/pull/554#issuecomment-129227018
Who wants to step in and finish this work? It seems the original author is
not able to finish it. If no one steps in, we'll have to close the PR without
merging it so please help :-).
[VMWARE] Unable to attach 7th Disk to a Windows server 2012R2 instance
--
Key: CLOUDSTACK-8610
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8610
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Fix For: 4.6.0
+Steps to reproduce+
1. Set global config vmware.root.disk.controller to 'osdefault'.
2. Deploy a VM and attach 6 disks to the VM.
3. Try to attach a 7th disk to the VM.
Step 3 will fail with the below error
{noformat}
2015-06-22 11:03:22,673 ERROR [c.c.s.r.VmwareStorageProcessor]
(DirectAgent-636:ctx-8e72c2d9 s1p-z1-esxic-001.es.local, job-9286/job-9287,
cmd: AttachCommand) (logid:6372e940) Failed to attach volume: Failed to add
disk scsi0:7.
java.lang.RuntimeException: Failed to add disk scsi0:7.
at
com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:336)
at
com.cloud.hypervisor.vmware.mo.VirtualMachineMO.attachDisk(VirtualMachineMO.java:1206)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8599) CS reports failure for a successful migration in case of low vCenter session timeouts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679288#comment-14679288 ] ASF GitHub Bot commented on CLOUDSTACK-8599: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/544#issuecomment-129227052 Who wants to step in and finish this work? It seems the original author is not able to finish it. If no one steps in, we'll have to close the PR without merging it so please help :-). CS reports failure for a successful migration in case of low vCenter session timeouts - Key: CLOUDSTACK-8599 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8599 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.6.0 +Steps to reproduce+ 1. In the global settings change the vmware.vcenter.session.timeout to 60 sec 2. Restart MS 3. Migrate a large volume so that the corresponding vCenter task takes more than a minute. Observation After the time out, CCP fails the migration operation but the volume migration is in progress in vCenter and successfully completes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8609) [VMware] VM is not accessible after a migration across clusters.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679282#comment-14679282 ] ASF GitHub Bot commented on CLOUDSTACK-8609: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/556#issuecomment-129227002 Who wants to step in and finish this work? It seems the original author is not able to finish it. If no one steps in, we'll have to close the PR without merging it so please help :-). [VMware] VM is not accessible after a migration across clusters. Key: CLOUDSTACK-8609 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8609 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.6.0 +Steps to reproduce+ 1. Deploy a VMware zone with 2 clusters (a host each, H1 and H2) and one zone-wide primary storage spanning the two clusters. 2. Deploy a VM (VM1) on one of the hosts (H1). 3. Stop VM1. 4. Make the host that contains the VM unsuitable for further VM deployments - host runs out of capacity (cpu/memory) - host has maximum VMs deployed on it 5. Start VM1. 6. VM will be powered on H2 but will not be accessible because the .vmx and other VM files associated with the VM have been deleted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8608) Fix unpleasant admin experience with VMware fresh installs/upgrades - System VM's failed to start due to permissions issue
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679283#comment-14679283 ] ASF GitHub Bot commented on CLOUDSTACK-8608: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/555#issuecomment-129227012 Who wants to step in and finish this work? It seems the original author is not able to finish it. If no one steps in, we'll have to close the PR without merging it so please help :-). Fix unpleasant admin experience with VMware fresh installs/upgrades - System VM's failed to start due to permissions issue -- Key: CLOUDSTACK-8608 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8608 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.6.0 VMware uses a folder in machine where management server is running to mount secondary storage. This is a bootstrap phase to start system vm, because unlike KVM, Xenserver, management server cannot directly access VMWare ESXI host to download systemvm template from secondary storage to primary storage. The secondary storage is usually managed by SSVM that uses root account to download templates. However, management server is using account 'cloud' to manipulate templates after secondary storage is mounted. After admin registers new systemvm template in CS as a normal upgrade procedure, the old SSVM will download the template using account root, but management server will create new SSVM from the new template using account 'cloud'. Then a permission denied error will raise. Prior to 4.4, CS used to handle this by running 'chmod -R' to the folder to which secondary storage is mounted every time management server mounts secondary storage. Unfortunately, this method is slow because we are trying to give permissions to the entire folder. So in 4.4, we stopped automatically providing the permissions and asked admin to manually run 'chmod -R' to the folder 'templates' on secondary storage, after registering new systemvm template. We can avoid this manual admin step by only providing permissions for the /templates folder instead of the entire folder. This way we will avoid the snapshots folder which could be very large in upgrade setups. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8611) CS waits indefinitely for CheckS2SVpnConnectionsCommand to return
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679281#comment-14679281 ] ASF GitHub Bot commented on CLOUDSTACK-8611: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/561#issuecomment-129226987 Who wants to step in and finish this work? It seems the original author is not able to finish it. If no one steps in, we'll have to close the PR without merging it so please help :-). CS waits indefinitely for CheckS2SVpnConnectionsCommand to return - Key: CLOUDSTACK-8611 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8611 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.6.0 On one instance, CS began to execute CheckS2SVpnConnectionsCommand command on a router but the command result was never returned to the MS. If a command never returns, then 'DirectAgent' thread executing this command is blocked indefinitely and cannot pick up any other request. Now since this command is designed to execute in sequence on a host and is run regularly, every execution of that command thereafter on that particular host ended up picking up a DirectAgent thread and waiting for the previous execution to complete. And hence overtime, the host ended up using and blocking all 'DirectAgent' threads indefinitely. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8687) Update prepare template api to seed/prepare a template only on a give primary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679302#comment-14679302 ] ASF GitHub Bot commented on CLOUDSTACK-8687: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/635#issuecomment-129228698 @DaanHoogland So, you suggest putting the new tests in a separate PR and add relevant unit tests that test the change in this PR? That sounds good to me. Let's change one thing per PR. @devdeep can you align with @DaanHoogland on this please? Once that is done I'll merge it. Update prepare template api to seed/prepare a template only on a give primary storage - Key: CLOUDSTACK-8687 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8687 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Devdeep Singh Assignee: Devdeep Singh Original Estimate: 2h Remaining Estimate: 2h Currently, the prepare template api will seed/prepare a given template on all the primary storage pools in a zone. If however, a user wishes to prepare a template only a particular storage pool, it isn't possible. The prepare template api should be updated to allow seedng/preparing a template only on a given primary storage pool. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8687) Update prepare template api to seed/prepare a template only on a give primary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679303#comment-14679303 ] ASF GitHub Bot commented on CLOUDSTACK-8687: Github user remibergsma commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/635#discussion_r36592822 --- Diff: api/src/org/apache/cloudstack/api/command/admin/template/PrepareTemplateCmd.java --- @@ -60,6 +61,15 @@ description = template ID of the template to be prepared in primary storage(s).) private Long templateId; +@ACL(accessType = AccessType.OperateEntry) +@Parameter(name = ApiConstants.STORAGE_ID, +type = CommandType.UUID, +entityType = StoragePoolResponse.class, +required = false, +description = storage pool ID of the primary storage pool to which the template should be prepared. If it is not provided the template + + is prepared on all the available primary storage pools.) +private Long storageId; --- End diff -- @kishankavala That's a conditional LGTM ;-) Please let me know if you LGTM as-is, or that you want something changed before LGTM. Thanks! Update prepare template api to seed/prepare a template only on a give primary storage - Key: CLOUDSTACK-8687 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8687 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Devdeep Singh Assignee: Devdeep Singh Original Estimate: 2h Remaining Estimate: 2h Currently, the prepare template api will seed/prepare a given template on all the primary storage pools in a zone. If however, a user wishes to prepare a template only a particular storage pool, it isn't possible. The prepare template api should be updated to allow seedng/preparing a template only on a given primary storage pool. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8718) Rethrow exception com.cloud.exception.ConcurrentOperationException: There are concurrent operations on VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrian Sender updated CLOUDSTACK-8718:
--
Description:
Cannot deploy instances from large size root disk templates. Small root disk
works without any problem.
2015-07-20 14:36:50,429 WARN [c.c.v.VirtualMachineManagerImpl]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) The task item for vm VM[User|i-8-189-VM] has been inactive for
3602
2015-07-20 14:36:50,429 ERROR [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) Invocation exception, caused by:
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
2015-07-20 14:36:50,430 INFO [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) Rethrow exception
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
2015-07-20 14:36:50,430 DEBUG [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136) (logid:5808e018) Done with
run of VM work job: com.cloud.vm.VmWorkStart for VM 189, job origin: 2133
2015-07-20 14:36:50,430 ERROR [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136) (logid:5808e018) Unable to
complete AsyncJobVO {id:2136, userId: 8, accountId: 8, instanceType: null,
instanceId: null, cmd: com.cloud.vm.VmWorkStart, cmdInfo:
rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIAC0oABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljbHVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAdwbGFubmVycQB-AANMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cAAIAAgAvXQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAHBwcHBwcHBwc3IAEWphdmEudXRpbC5IYXNoTWFwBQfawcMWYNEDAAJGAApsb2FkRmFjdG9ySQAJdGhyZXNob2xkeHA_QAAADHcIEAF0AApWbVBhc3N3b3JkdAAcck8wQUJYUUFEbk5oZG1Wa1gzQmhjM04zYjNKa3hw,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 192022089101382, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Mon Jul 20 14:36:49 EST 2015}, job origin:2133
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
at
com.cloud.vm.VirtualMachineManagerImpl.changeToStartState(VirtualMachineManagerImpl.java:738)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:841)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4570)
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
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4726)
at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:103)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:549)
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:500)
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:745)
com.cloud.utils.exception.CloudRuntimeException: Unable to start a VM due to
concurrent operation
at
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:628)
at
org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:242)
at
[jira] [Updated] (CLOUDSTACK-8718) Rethrow exception com.cloud.exception.ConcurrentOperationException: There are concurrent operations on VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrian Sender updated CLOUDSTACK-8718:
--
Fix Version/s: (was: 4.3.1)
Description:
Cannot deploy instances from large size root disk templates. Small root disk
works without any problem.
We can deploy large templates in 4.3 without any issues.
Strange behavior, the template might take 7 hours to copy depending on the size
of the root disk.
Once xenserver completes the task and we try and start the instance in CCP the
copy process starts all over again.
[root@xenserver-01 ~]# xe task-list|less
uuid ( RO): 539cd570-2348-e06a-0585-a6ca0198660a
name-label ( RO): Async.VDI.copy
name-description ( RO):
status ( RO): pending
progress ( RO): 0.580
2015-07-20 14:36:50,429 WARN [c.c.v.VirtualMachineManagerImpl]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) The task item for vm VM[User|i-8-189-VM] has been inactive for
3602
2015-07-20 14:36:50,429 ERROR [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) Invocation exception, caused by:
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
2015-07-20 14:36:50,430 INFO [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) Rethrow exception
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
2015-07-20 14:36:50,430 DEBUG [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136) (logid:5808e018) Done with
run of VM work job: com.cloud.vm.VmWorkStart for VM 189, job origin: 2133
2015-07-20 14:36:50,430 ERROR [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136) (logid:5808e018) Unable to
complete AsyncJobVO {id:2136, userId: 8, accountId: 8, instanceType: null,
instanceId: null, cmd: com.cloud.vm.VmWorkStart, cmdInfo:
rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIAC0oABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljbHVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAdwbGFubmVycQB-AANMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cAAIAAgAvXQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAHBwcHBwcHBwc3IAEWphdmEudXRpbC5IYXNoTWFwBQfawcMWYNEDAAJGAApsb2FkRmFjdG9ySQAJdGhyZXNob2xkeHA_QAAADHcIEAF0AApWbVBhc3N3b3JkdAAcck8wQUJYUUFEbk5oZG1Wa1gzQmhjM04zYjNKa3hw,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 192022089101382, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Mon Jul 20 14:36:49 EST 2015}, job origin:2133
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
at
com.cloud.vm.VirtualMachineManagerImpl.changeToStartState(VirtualMachineManagerImpl.java:738)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:841)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4570)
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
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4726)
at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:103)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:549)
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:500)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
[jira] [Commented] (CLOUDSTACK-8717) Failed to start instance after restoring the running instance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679598#comment-14679598 ] ASF GitHub Bot commented on CLOUDSTACK-8717: Github user pritisarap12 commented on the pull request: https://github.com/apache/cloudstack/pull/667#issuecomment-129310396 Updated testcase with review comments. Failed to start instance after restoring the running instance -- Key: CLOUDSTACK-8717 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8717 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.2.1 Reporter: Priti Sarap Fix For: 4.2.1 On setup with two cluster wide primary storage verify restoring a running instance.(As while restoring instance root disk may get created on another primary storage.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8601) VMFS storage added as local storage can be re added as shared storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679475#comment-14679475 ] ASF GitHub Bot commented on CLOUDSTACK-8601: Github user mike-tutkowski commented on the pull request: https://github.com/apache/cloudstack/pull/547#issuecomment-129276125 The code LGTM. Are we under the assumption that it was properly tested? If so, I can just merge it at this point. VMFS storage added as local storage can be re added as shared storage. -- Key: CLOUDSTACK-8601 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8601 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.6.0 During host discovery, if local storage is enabled for a zone, all VMFS datastores that are mounted on just one host (i.e. not shared) will be added as local storage is CloudStack. When admin adds a VMFS datastore as shared, CS doesn't verify if the storage has already been added as local storage in the zone. This means the same primary storage is added as different storages in CS and this leads to failure in operations related to disks because of wrong storage look ups. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8716) Verify creation of snapshot from volume when the task is performed repeatedly in zone wide primary Storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679546#comment-14679546 ] ASF GitHub Bot commented on CLOUDSTACK-8716: Github user sanju1010 commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/665#discussion_r36601402 --- Diff: test/integration/testpaths/testpath_multiple_snapshot.py --- @@ -0,0 +1,255 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# License); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. + + Test case for Multiple Volume Snapshot in ZWPS + +from nose.plugins.attrib import attr +from marvin.cloudstackTestCase import cloudstackTestCase +from marvin.lib.utils import (cleanup_resources, + validateList) +from marvin.lib.base import (Account, + ServiceOffering, + DiskOffering, + Snapshot, + VirtualMachine, + StoragePool + ) +from marvin.lib.common import (get_domain, + get_zone, + list_volumes, + list_clusters, + get_template + ) + +from marvin.codes import PASS, ZONETAG1, ROOT, DATA + + +class TestMultipleVolumeSnapshots(cloudstackTestCase): + +@classmethod +def setUpClass(cls): +testClient = super(TestMultipleVolumeSnapshots, cls).getClsTestClient() +cls.apiclient = testClient.getApiClient() +cls.testdata = testClient.getParsedTestDataConfig() + +# Get Zone, Domain and templates +cls.domain = get_domain(cls.apiclient) +cls.zone = get_zone(cls.apiclient, testClient.getZoneForTests()) +cls.hypervisor = cls.testClient.getHypervisorInfo() +cls.template = get_template( +cls.apiclient, +cls.zone.id, +cls.testdata[ostype]) + +cls._cleanup = [] + +cls.skiptest = False + +clus_list = list_clusters(cls.apiclient) + +if cls.hypervisor.lower() not in ['vmware'] or len(clus_list) 2: +cls.skiptest = True +return + +try: +# Create an account +cls.account = Account.create( +cls.apiclient, +cls.testdata[account], +domainid=cls.domain.id +) + +# Create user api client of the account +cls.userapiclient = testClient.getUserApiClient( +UserName=cls.account.name, +DomainName=cls.account.domain +) +# Create Service offering +cls.service_offering_zwps = ServiceOffering.create( +cls.apiclient, +cls.testdata[service_offering], +tags=ZONETAG1 +) + +cls.disk_offering_zwps = DiskOffering.create( +cls.apiclient, +cls.testdata[disk_offering], +tags=ZONETAG1 +) + +cls._cleanup = [ +cls.account, +cls.service_offering_zwps, +cls.disk_offering_zwps, +] +except Exception as e: +cls.tearDownClass() +raise e +return + +@classmethod +def tearDownClass(cls): +try: +cleanup_resources(cls.apiclient, cls._cleanup) +except Exception as e: +raise Exception(Warning: Exception during cleanup : %s % e) + +def setUp(self): + +self.cleanup = [] +if self.skiptest: +self.skipTest(Skip test as setup is either not
[jira] [Commented] (CLOUDSTACK-8717) Failed to start instance after restoring the running instance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679555#comment-14679555 ] ASF GitHub Bot commented on CLOUDSTACK-8717: Github user sanju1010 commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/667#discussion_r36601640 --- Diff: test/integration/testpaths/testpath_restore_vm.py --- @@ -0,0 +1,192 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# License); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. + + +Test restore running VM on VMWare with one cluster having 2 Primary Storage + + + +from nose.plugins.attrib import attr +from marvin.cloudstackTestCase import cloudstackTestCase +from marvin.lib.utils import cleanup_resources +from marvin.lib.base import (Account, + ServiceOffering, + VirtualMachine, + StoragePool + ) +from marvin.lib.common import (get_domain, + get_zone, + get_template, + list_volumes + ) + +from marvin.codes import CLUSTERTAG1, ROOT +import time + + +class TestRestoreVM(cloudstackTestCase): + +@classmethod +def setUpClass(cls): +testClient = super(TestRestoreVM, cls).getClsTestClient() +cls.apiclient = testClient.getApiClient() +cls.testdata = testClient.getParsedTestDataConfig() +cls.hypervisor = cls.testClient.getHypervisorInfo() + +# Get Zone, Domain and templates +cls.domain = get_domain(cls.apiclient) +cls.zone = get_zone(cls.apiclient, testClient.getZoneForTests()) + +cls.template = get_template( +cls.apiclient, +cls.zone.id, +cls.testdata[ostype]) + +cls._cleanup = [] + +try: +cls.skiptest = False +if cls.hypervisor.lower() not in [vmware]: +cls.skiptest = True +return + +# Create an account +cls.account = Account.create( +cls.apiclient, +cls.testdata[account], +domainid=cls.domain.id +) +cls._cleanup.append(cls.account) +# Create user api client of the account +cls.userapiclient = testClient.getUserApiClient( +UserName=cls.account.name, +DomainName=cls.account.domain +) +# Create Service offering +cls.service_offering_cwps = ServiceOffering.create( +cls.apiclient, +cls.testdata[service_offering], +tags=CLUSTERTAG1 +) +cls._cleanup.append(cls.service_offering_cwps) +except Exception as e: +cls.tearDownClass() +raise e +return + +@classmethod +def tearDownClass(cls): +try: +cleanup_resources(cls.apiclient, cls._cleanup) +except Exception as e: +raise Exception(Warning: Exception during cleanup : %s % e) + +def setUp(self): + +self.cleanup = [] +if self.skiptest: +self.skipTest(This test is to be checked on VMWare only \ +Hence, skip for %s % self.hypervisor) + +self.apiclient = self.testClient.getApiClient() +self.dbclient = self.testClient.getDbConnection() + +def tearDown(self): +try: +cleanup_resources(self.apiclient, self.cleanup) +except Exception as e: +raise Exception(Warning: Exception during cleanup : %s % e) +return + +@attr(tags=[advanced, basic], required_hardware=false)
[jira] [Comment Edited] (CLOUDSTACK-7600) [Automation] VM Failed to Start due to ConcurrentOperationException - Unable to change the state of Virtual Router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679564#comment-14679564 ] Adrian Sender edited comment on CLOUDSTACK-7600 at 8/10/15 5:03 AM: Cloudplatform 4.5, also have the similar issue on large templates copying to primary storage. Case Information Case Number 70353012Status Active - Technical Support Severity2 Subject Rethrow exception com.cloud.exception.ConcurrentOperationException: There are concurrent operations on VM 2015-08-10 12:55:19,622 DEBUG [c.c.v.VirtualMachineManagerImpl] (Work-Job-Executor-24:ctx-dba85e96 job-2708/job-2710 ctx-88da0a6e) (logid:3c50fa44) Unable to transition into Starting state due to Unable to transition to a new state from Starting via StartRequested pdated: null, lastPolled: null, created: Mon Aug 10 12:55:17 AEST 2015}, job origin:2708 com.cloud.exception.ConcurrentOperationException: There are concurrent operations on VM[User|i-2-242-VM] at com.cloud.vm.VirtualMachineManagerImpl.changeToStartState(VirtualMachineManagerImpl.java:738) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:841) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4570) 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 com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) at com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4726) at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:103) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:549) 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:500) 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:745) com.cloud.utils.exception.CloudRuntimeException: Unable to start a VM due to concurrent operation at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:628) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:242) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:212) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3933) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3522) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3510) 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.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.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) at
[jira] [Commented] (CLOUDSTACK-8717) Failed to start instance after restoring the running instance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679565#comment-14679565 ] ASF GitHub Bot commented on CLOUDSTACK-8717: Github user sanju1010 commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/667#discussion_r36602070 --- Diff: test/integration/testpaths/testpath_restore_vm.py --- @@ -0,0 +1,192 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# License); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. + + +Test restore running VM on VMWare with one cluster having 2 Primary Storage + + + +from nose.plugins.attrib import attr +from marvin.cloudstackTestCase import cloudstackTestCase +from marvin.lib.utils import cleanup_resources +from marvin.lib.base import (Account, + ServiceOffering, + VirtualMachine, + StoragePool + ) +from marvin.lib.common import (get_domain, + get_zone, + get_template, + list_volumes + ) + +from marvin.codes import CLUSTERTAG1, ROOT +import time + + +class TestRestoreVM(cloudstackTestCase): + +@classmethod +def setUpClass(cls): +testClient = super(TestRestoreVM, cls).getClsTestClient() +cls.apiclient = testClient.getApiClient() +cls.testdata = testClient.getParsedTestDataConfig() +cls.hypervisor = cls.testClient.getHypervisorInfo() + +# Get Zone, Domain and templates +cls.domain = get_domain(cls.apiclient) +cls.zone = get_zone(cls.apiclient, testClient.getZoneForTests()) + +cls.template = get_template( +cls.apiclient, +cls.zone.id, +cls.testdata[ostype]) + +cls._cleanup = [] + +try: +cls.skiptest = False +if cls.hypervisor.lower() not in [vmware]: +cls.skiptest = True +return + +# Create an account +cls.account = Account.create( +cls.apiclient, +cls.testdata[account], +domainid=cls.domain.id +) +cls._cleanup.append(cls.account) +# Create user api client of the account +cls.userapiclient = testClient.getUserApiClient( +UserName=cls.account.name, +DomainName=cls.account.domain +) +# Create Service offering +cls.service_offering_cwps = ServiceOffering.create( +cls.apiclient, +cls.testdata[service_offering], +tags=CLUSTERTAG1 +) +cls._cleanup.append(cls.service_offering_cwps) +except Exception as e: +cls.tearDownClass() +raise e +return + +@classmethod +def tearDownClass(cls): +try: +cleanup_resources(cls.apiclient, cls._cleanup) +except Exception as e: +raise Exception(Warning: Exception during cleanup : %s % e) + +def setUp(self): + +self.cleanup = [] +if self.skiptest: +self.skipTest(This test is to be checked on VMWare only \ +Hence, skip for %s % self.hypervisor) + +self.apiclient = self.testClient.getApiClient() +self.dbclient = self.testClient.getDbConnection() + +def tearDown(self): +try: +cleanup_resources(self.apiclient, self.cleanup) +except Exception as e: +raise Exception(Warning: Exception during cleanup : %s % e) +return + +@attr(tags=[advanced, basic], required_hardware=false)
[jira] [Updated] (CLOUDSTACK-8718) Rethrow exception com.cloud.exception.ConcurrentOperationException: There are concurrent operations on VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrian Sender updated CLOUDSTACK-8718:
--
Priority: Critical (was: Blocker)
Rethrow exception com.cloud.exception.ConcurrentOperationException: There are
concurrent operations on VM
-
Key: CLOUDSTACK-8718
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8718
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.5.1
Environment: Cloudplatform 4.5
Xenserver 6.5
EMC Fiber Channel Primary Storage
Freenas NFS Secondary Storage
Citrix Case Detail:
Case Information:
Case Number 70353012Status Active - Technical Support
Severity 2
Subject Rethrow exception
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM
Reporter: Adrian Sender
Priority: Critical
Fix For: 4.3.1
Cannot deploy instances from large size root disk templates. Small root disk
works without any problem.
2015-07-20 14:36:50,429 WARN [c.c.v.VirtualMachineManagerImpl]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) The task item for vm VM[User|i-8-189-VM] has been inactive
for 3602
2015-07-20 14:36:50,429 ERROR [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) Invocation exception, caused by:
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
2015-07-20 14:36:50,430 INFO [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) Rethrow exception
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
2015-07-20 14:36:50,430 DEBUG [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136) (logid:5808e018) Done
with run of VM work job: com.cloud.vm.VmWorkStart for VM 189, job origin: 2133
2015-07-20 14:36:50,430 ERROR [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136) (logid:5808e018) Unable
to complete AsyncJobVO {id:2136, userId: 8, accountId: 8, instanceType: null,
instanceId: null, cmd: com.cloud.vm.VmWorkStart, cmdInfo:
rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIAC0oABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljbHVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAdwbGFubmVycQB-AANMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cAAIAAgAvXQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAHBwcHBwcHBwc3IAEWphdmEudXRpbC5IYXNoTWFwBQfawcMWYNEDAAJGAApsb2FkRmFjdG9ySQAJdGhyZXNob2xkeHA_QAAADHcIEAF0AApWbVBhc3N3b3JkdAAcck8wQUJYUUFEbk5oZG1Wa1gzQmhjM04zYjNKa3hw,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 192022089101382, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Mon Jul 20 14:36:49 EST 2015}, job origin:2133
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
at
com.cloud.vm.VirtualMachineManagerImpl.changeToStartState(VirtualMachineManagerImpl.java:738)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:841)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4570)
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
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4726)
at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:103)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:549)
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
[jira] [Updated] (CLOUDSTACK-8718) Rethrow exception com.cloud.exception.ConcurrentOperationException: There are concurrent operations on VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrian Sender updated CLOUDSTACK-8718:
--
Description:
Cannot deploy instances from large size root disk templates. Small root disk
works without any problem.
2015-07-20 14:36:50,429 WARN [c.c.v.VirtualMachineManagerImpl]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) The task item for vm VM[User|i-8-189-VM] has been inactive for
3602
2015-07-20 14:36:50,429 ERROR [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) Invocation exception, caused by:
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
2015-07-20 14:36:50,430 INFO [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) Rethrow exception
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
2015-07-20 14:36:50,430 DEBUG [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136) (logid:5808e018) Done with
run of VM work job: com.cloud.vm.VmWorkStart for VM 189, job origin: 2133
2015-07-20 14:36:50,430 ERROR [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136) (logid:5808e018) Unable to
complete AsyncJobVO {id:2136, userId: 8, accountId: 8, instanceType: null,
instanceId: null, cmd: com.cloud.vm.VmWorkStart, cmdInfo:
rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIAC0oABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljbHVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAdwbGFubmVycQB-AANMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cAAIAAgAvXQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAHBwcHBwcHBwc3IAEWphdmEudXRpbC5IYXNoTWFwBQfawcMWYNEDAAJGAApsb2FkRmFjdG9ySQAJdGhyZXNob2xkeHA_QAAADHcIEAF0AApWbVBhc3N3b3JkdAAcck8wQUJYUUFEbk5oZG1Wa1gzQmhjM04zYjNKa3hw,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 192022089101382, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Mon Jul 20 14:36:49 EST 2015}, job origin:2133
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
at
com.cloud.vm.VirtualMachineManagerImpl.changeToStartState(VirtualMachineManagerImpl.java:738)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:841)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4570)
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
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4726)
at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:103)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:549)
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:500)
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:745)
com.cloud.utils.exception.CloudRuntimeException: Unable to start a VM due to
concurrent operation
at
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:628)
at
org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:242)
at
[jira] [Commented] (CLOUDSTACK-8704) Schedule restart of router VMs ahead of user VMs as part of HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679567#comment-14679567 ] ASF GitHub Bot commented on CLOUDSTACK-8704: Github user koushik-das commented on the pull request: https://github.com/apache/cloudstack/pull/656#issuecomment-129300344 @remibergsma Thanks for testing the PR. This is a best-effort fix. The change just schedules the restart of the system VMs ahead of the user VMs. Now if there are fewer VMs for restart, there is a higher probability of all restart jobs getting executed at the same time by the HA-worker thread pool. In this case the fix won't be effective. If there are more VMs then the effectiveness of the fix increases. Schedule restart of router VMs ahead of user VMs as part of HA -- Key: CLOUDSTACK-8704 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8704 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: Koushik Das Assignee: Koushik Das Fix For: 4.6.0 When a host is detected as Down, HA-enabled VMs running on it are scheduled for restart. There may be scenarios where both user VM and corresponding VR is on the same host and scheduled for restart. In such cases user VM restart will fail in initial attempts until VR is restarted. One way to reduce these occurrences is to schedule VR restart ahead of user VMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8718) Rethrow exception com.cloud.exception.ConcurrentOperationException: There are concurrent operations on VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679585#comment-14679585
]
Adrian Sender commented on CLOUDSTACK-8718:
---
Logs can be found in the below support request, I will also upload a fresh set
of logs.
Citrix Case Detail:
Case Information:
Case Number 70353012Status Active - Technical Support
Severity2
Subject Rethrow exception com.cloud.exception.ConcurrentOperationException:
There are concurrent operations on VM
Rethrow exception com.cloud.exception.ConcurrentOperationException: There are
concurrent operations on VM
-
Key: CLOUDSTACK-8718
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8718
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.5.1
Environment: Cloudplatform 4.5
Xenserver 6.5
EMC Fiber Channel Primary Storage
Freenas NFS Secondary Storage
Citrix Case Detail:
Case Information:
Case Number 70353012Status Active - Technical Support
Severity 2
Subject Rethrow exception
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM
Reporter: Adrian Sender
Priority: Critical
Fix For: 4.3.1
Cannot deploy instances from large size root disk templates. Small root disk
works without any problem.
2015-07-20 14:36:50,429 WARN [c.c.v.VirtualMachineManagerImpl]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) The task item for vm VM[User|i-8-189-VM] has been inactive
for 3602
2015-07-20 14:36:50,429 ERROR [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) Invocation exception, caused by:
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
2015-07-20 14:36:50,430 INFO [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) Rethrow exception
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
2015-07-20 14:36:50,430 DEBUG [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136) (logid:5808e018) Done
with run of VM work job: com.cloud.vm.VmWorkStart for VM 189, job origin: 2133
2015-07-20 14:36:50,430 ERROR [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136) (logid:5808e018) Unable
to complete AsyncJobVO {id:2136, userId: 8, accountId: 8, instanceType: null,
instanceId: null, cmd: com.cloud.vm.VmWorkStart, cmdInfo:
rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIAC0oABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljbHVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAdwbGFubmVycQB-AANMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cAAIAAgAvXQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAHBwcHBwcHBwc3IAEWphdmEudXRpbC5IYXNoTWFwBQfawcMWYNEDAAJGAApsb2FkRmFjdG9ySQAJdGhyZXNob2xkeHA_QAAADHcIEAF0AApWbVBhc3N3b3JkdAAcck8wQUJYUUFEbk5oZG1Wa1gzQmhjM04zYjNKa3hw,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 192022089101382, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Mon Jul 20 14:36:49 EST 2015}, job origin:2133
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
at
com.cloud.vm.VirtualMachineManagerImpl.changeToStartState(VirtualMachineManagerImpl.java:738)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:841)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4570)
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
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4726)
at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:103)
at
[jira] [Commented] (CLOUDSTACK-8716) Verify creation of snapshot from volume when the task is performed repeatedly in zone wide primary Storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679547#comment-14679547 ] ASF GitHub Bot commented on CLOUDSTACK-8716: Github user sanju1010 commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/665#discussion_r36601462 --- Diff: test/integration/testpaths/testpath_multiple_snapshot.py --- @@ -0,0 +1,255 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# License); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. + + Test case for Multiple Volume Snapshot in ZWPS + +from nose.plugins.attrib import attr +from marvin.cloudstackTestCase import cloudstackTestCase +from marvin.lib.utils import (cleanup_resources, + validateList) +from marvin.lib.base import (Account, + ServiceOffering, + DiskOffering, + Snapshot, + VirtualMachine, + StoragePool + ) +from marvin.lib.common import (get_domain, + get_zone, + list_volumes, + list_clusters, + get_template + ) + +from marvin.codes import PASS, ZONETAG1, ROOT, DATA + + +class TestMultipleVolumeSnapshots(cloudstackTestCase): + +@classmethod +def setUpClass(cls): +testClient = super(TestMultipleVolumeSnapshots, cls).getClsTestClient() +cls.apiclient = testClient.getApiClient() +cls.testdata = testClient.getParsedTestDataConfig() + +# Get Zone, Domain and templates +cls.domain = get_domain(cls.apiclient) +cls.zone = get_zone(cls.apiclient, testClient.getZoneForTests()) +cls.hypervisor = cls.testClient.getHypervisorInfo() +cls.template = get_template( +cls.apiclient, +cls.zone.id, +cls.testdata[ostype]) + +cls._cleanup = [] + +cls.skiptest = False + +clus_list = list_clusters(cls.apiclient) + +if cls.hypervisor.lower() not in ['vmware'] or len(clus_list) 2: +cls.skiptest = True +return + +try: +# Create an account +cls.account = Account.create( +cls.apiclient, +cls.testdata[account], +domainid=cls.domain.id +) + +# Create user api client of the account +cls.userapiclient = testClient.getUserApiClient( +UserName=cls.account.name, +DomainName=cls.account.domain +) +# Create Service offering +cls.service_offering_zwps = ServiceOffering.create( +cls.apiclient, +cls.testdata[service_offering], +tags=ZONETAG1 +) + +cls.disk_offering_zwps = DiskOffering.create( +cls.apiclient, +cls.testdata[disk_offering], +tags=ZONETAG1 +) + +cls._cleanup = [ +cls.account, +cls.service_offering_zwps, +cls.disk_offering_zwps, +] +except Exception as e: +cls.tearDownClass() +raise e +return + +@classmethod +def tearDownClass(cls): +try: +cleanup_resources(cls.apiclient, cls._cleanup) +except Exception as e: +raise Exception(Warning: Exception during cleanup : %s % e) + +def setUp(self): + +self.cleanup = [] +if self.skiptest: +self.skipTest(Skip test as setup is either not
[jira] [Commented] (CLOUDSTACK-8716) Verify creation of snapshot from volume when the task is performed repeatedly in zone wide primary Storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679552#comment-14679552 ] ASF GitHub Bot commented on CLOUDSTACK-8716: Github user sanju1010 commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/665#discussion_r36601607 --- Diff: test/integration/testpaths/testpath_multiple_snapshot.py --- @@ -0,0 +1,255 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# License); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. + + Test case for Multiple Volume Snapshot in ZWPS + +from nose.plugins.attrib import attr +from marvin.cloudstackTestCase import cloudstackTestCase +from marvin.lib.utils import (cleanup_resources, + validateList) +from marvin.lib.base import (Account, + ServiceOffering, + DiskOffering, + Snapshot, + VirtualMachine, + StoragePool + ) +from marvin.lib.common import (get_domain, + get_zone, + list_volumes, + list_clusters, + get_template + ) + +from marvin.codes import PASS, ZONETAG1, ROOT, DATA + + +class TestMultipleVolumeSnapshots(cloudstackTestCase): + +@classmethod +def setUpClass(cls): +testClient = super(TestMultipleVolumeSnapshots, cls).getClsTestClient() +cls.apiclient = testClient.getApiClient() +cls.testdata = testClient.getParsedTestDataConfig() + +# Get Zone, Domain and templates +cls.domain = get_domain(cls.apiclient) +cls.zone = get_zone(cls.apiclient, testClient.getZoneForTests()) +cls.hypervisor = cls.testClient.getHypervisorInfo() +cls.template = get_template( +cls.apiclient, +cls.zone.id, +cls.testdata[ostype]) + +cls._cleanup = [] + +cls.skiptest = False + +clus_list = list_clusters(cls.apiclient) + +if cls.hypervisor.lower() not in ['vmware'] or len(clus_list) 2: +cls.skiptest = True +return + +try: +# Create an account +cls.account = Account.create( +cls.apiclient, +cls.testdata[account], +domainid=cls.domain.id +) + +# Create user api client of the account +cls.userapiclient = testClient.getUserApiClient( +UserName=cls.account.name, +DomainName=cls.account.domain +) +# Create Service offering +cls.service_offering_zwps = ServiceOffering.create( +cls.apiclient, +cls.testdata[service_offering], +tags=ZONETAG1 +) + +cls.disk_offering_zwps = DiskOffering.create( +cls.apiclient, +cls.testdata[disk_offering], +tags=ZONETAG1 +) + +cls._cleanup = [ +cls.account, +cls.service_offering_zwps, +cls.disk_offering_zwps, +] +except Exception as e: +cls.tearDownClass() +raise e +return + +@classmethod +def tearDownClass(cls): +try: +cleanup_resources(cls.apiclient, cls._cleanup) +except Exception as e: +raise Exception(Warning: Exception during cleanup : %s % e) + +def setUp(self): + +self.cleanup = [] +if self.skiptest: +self.skipTest(Skip test as setup is either not
[jira] [Commented] (CLOUDSTACK-7600) [Automation] VM Failed to Start due to ConcurrentOperationException - Unable to change the state of Virtual Router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679564#comment-14679564 ] Adrian Sender commented on CLOUDSTACK-7600: --- Cloudplatform 4.5, all have the similar issue on large templates copying to primary storage. Case Information Case Number 70353012Status Active - Technical Support Severity2 Subject Rethrow exception com.cloud.exception.ConcurrentOperationException: There are concurrent operations on VM 2015-08-10 12:55:19,622 DEBUG [c.c.v.VirtualMachineManagerImpl] (Work-Job-Executor-24:ctx-dba85e96 job-2708/job-2710 ctx-88da0a6e) (logid:3c50fa44) Unable to transition into Starting state due to Unable to transition to a new state from Starting via StartRequested pdated: null, lastPolled: null, created: Mon Aug 10 12:55:17 AEST 2015}, job origin:2708 com.cloud.exception.ConcurrentOperationException: There are concurrent operations on VM[User|i-2-242-VM] at com.cloud.vm.VirtualMachineManagerImpl.changeToStartState(VirtualMachineManagerImpl.java:738) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:841) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4570) 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 com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) at com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4726) at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:103) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:549) 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:500) 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:745) com.cloud.utils.exception.CloudRuntimeException: Unable to start a VM due to concurrent operation at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:628) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:242) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:212) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3933) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3522) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3510) 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.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.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) at
[jira] [Created] (CLOUDSTACK-8718) Rethrow exception com.cloud.exception.ConcurrentOperationException: There are concurrent operations on VM
Adrian Sender created CLOUDSTACK-8718:
-
Summary: Rethrow exception
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM
Key: CLOUDSTACK-8718
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8718
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Automation
Affects Versions: 4.5.1
Environment: Cloudplatform 4.5
Xenserver 6.5
EMC Fiber Channel Primary Storage
Freenas NFS Secondary Storage
Citrix Case Detail:
Case Information:
Case Number 70353012Status Active - Technical Support
Severity2
Subject Rethrow exception com.cloud.exception.ConcurrentOperationException:
There are concurrent operations on VM
Reporter: Adrian Sender
Priority: Blocker
Fix For: 4.3.1
Cannot deploy instances from large size root disk templates. Small root disk
works without any problem.
2015-07-20 14:36:50,429 WARN [c.c.v.VirtualMachineManagerImpl]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) The task item for vm VM[User|i-8-189-VM] has been inactive for
3602
2015-07-20 14:36:50,429 ERROR [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) Invocation exception, caused by:
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
2015-07-20 14:36:50,430 INFO [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) Rethrow exception
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
2015-07-20 14:36:50,430 DEBUG [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136) (logid:5808e018) Done with
run of VM work job: com.cloud.vm.VmWorkStart for VM 189, job origin: 2133
2015-07-20 14:36:50,430 ERROR [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136) (logid:5808e018) Unable to
complete AsyncJobVO {id:2136, userId: 8, accountId: 8, instanceType: null,
instanceId: null, cmd: com.cloud.vm.VmWorkStart, cmdInfo:
rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIAC0oABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljbHVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAdwbGFubmVycQB-AANMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cAAIAAgAvXQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAHBwcHBwcHBwc3IAEWphdmEudXRpbC5IYXNoTWFwBQfawcMWYNEDAAJGAApsb2FkRmFjdG9ySQAJdGhyZXNob2xkeHA_QAAADHcIEAF0AApWbVBhc3N3b3JkdAAcck8wQUJYUUFEbk5oZG1Wa1gzQmhjM04zYjNKa3hw,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 192022089101382, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Mon Jul 20 14:36:49 EST 2015}, job origin:2133
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
at
com.cloud.vm.VirtualMachineManagerImpl.changeToStartState(VirtualMachineManagerImpl.java:738)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:841)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4570)
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
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4726)
at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:103)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:549)
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
[jira] [Updated] (CLOUDSTACK-8718) Rethrow exception com.cloud.exception.ConcurrentOperationException: There are concurrent operations on VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrian Sender updated CLOUDSTACK-8718:
--
Attachment: catalina.zip
management-server.log.2015-08-05.gz
management-server.log.2015-08-04.gz
apilog.log
Rethrow exception com.cloud.exception.ConcurrentOperationException: There are
concurrent operations on VM
-
Key: CLOUDSTACK-8718
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8718
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.5.1
Environment: Cloudplatform 4.5
Xenserver 6.5
EMC Fiber Channel Primary Storage
Freenas NFS Secondary Storage
Citrix Case Detail:
Case Information:
Case Number 70353012Status Active - Technical Support
Severity 2
Subject Rethrow exception
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM
Reporter: Adrian Sender
Priority: Critical
Attachments: apilog.log, catalina.zip,
management-server.log.2015-08-04.gz, management-server.log.2015-08-05.gz
Cannot deploy instances from large size root disk templates. Small root disk
works without any problem.
We can deploy large templates in 4.3 without any issues.
Strange behavior, the template might take 7 hours to copy depending on the
size of the root disk.
Once xenserver completes the task and we try and start the instance in CCP
the copy process starts all over again.
[root@xenserver-01 ~]# xe task-list|less
uuid ( RO): 539cd570-2348-e06a-0585-a6ca0198660a
name-label ( RO): Async.VDI.copy
name-description ( RO):
status ( RO): pending
progress ( RO): 0.580
2015-07-20 14:36:50,429 WARN [c.c.v.VirtualMachineManagerImpl]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) The task item for vm VM[User|i-8-189-VM] has been inactive
for 3602
2015-07-20 14:36:50,429 ERROR [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) Invocation exception, caused by:
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
2015-07-20 14:36:50,430 INFO [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) Rethrow exception
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
2015-07-20 14:36:50,430 DEBUG [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136) (logid:5808e018) Done
with run of VM work job: com.cloud.vm.VmWorkStart for VM 189, job origin: 2133
2015-07-20 14:36:50,430 ERROR [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136) (logid:5808e018) Unable
to complete AsyncJobVO {id:2136, userId: 8, accountId: 8, instanceType: null,
instanceId: null, cmd: com.cloud.vm.VmWorkStart, cmdInfo:
rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIAC0oABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljbHVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAdwbGFubmVycQB-AANMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cAAIAAgAvXQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAHBwcHBwcHBwc3IAEWphdmEudXRpbC5IYXNoTWFwBQfawcMWYNEDAAJGAApsb2FkRmFjdG9ySQAJdGhyZXNob2xkeHA_QAAADHcIEAF0AApWbVBhc3N3b3JkdAAcck8wQUJYUUFEbk5oZG1Wa1gzQmhjM04zYjNKa3hw,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 192022089101382, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Mon Jul 20 14:36:49 EST 2015}, job origin:2133
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
at
com.cloud.vm.VirtualMachineManagerImpl.changeToStartState(VirtualMachineManagerImpl.java:738)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:841)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4570)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
[jira] [Updated] (CLOUDSTACK-8718) Rethrow exception com.cloud.exception.ConcurrentOperationException: There are concurrent operations on VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrian Sender updated CLOUDSTACK-8718:
--
Attachment: management-server.zip
grep i-2-242-VM
Rethrow exception com.cloud.exception.ConcurrentOperationException: There are
concurrent operations on VM
-
Key: CLOUDSTACK-8718
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8718
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.5.1
Environment: Cloudplatform 4.5
Xenserver 6.5
EMC Fiber Channel Primary Storage
Freenas NFS Secondary Storage
Citrix Case Detail:
Case Information:
Case Number 70353012Status Active - Technical Support
Severity 2
Subject Rethrow exception
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM
Reporter: Adrian Sender
Priority: Critical
Attachments: apilog.log, catalina.zip,
management-server.log.2015-08-04.gz, management-server.log.2015-08-05.gz,
management-server.zip
Cannot deploy instances from large size root disk templates. Small root disk
works without any problem.
We can deploy large templates in 4.3 without any issues.
Strange behavior, the template might take 7 hours to copy depending on the
size of the root disk.
Once xenserver completes the task and we try and start the instance in CCP
the copy process starts all over again.
[root@xenserver-01 ~]# xe task-list|less
uuid ( RO): 539cd570-2348-e06a-0585-a6ca0198660a
name-label ( RO): Async.VDI.copy
name-description ( RO):
status ( RO): pending
progress ( RO): 0.580
2015-07-20 14:36:50,429 WARN [c.c.v.VirtualMachineManagerImpl]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) The task item for vm VM[User|i-8-189-VM] has been inactive
for 3602
2015-07-20 14:36:50,429 ERROR [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) Invocation exception, caused by:
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
2015-07-20 14:36:50,430 INFO [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136 ctx-30d5ecdd)
(logid:5808e018) Rethrow exception
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
2015-07-20 14:36:50,430 DEBUG [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136) (logid:5808e018) Done
with run of VM work job: com.cloud.vm.VmWorkStart for VM 189, job origin: 2133
2015-07-20 14:36:50,430 ERROR [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-9:ctx-116ace03 job-2133/job-2136) (logid:5808e018) Unable
to complete AsyncJobVO {id:2136, userId: 8, accountId: 8, instanceType: null,
instanceId: null, cmd: com.cloud.vm.VmWorkStart, cmdInfo:
rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIAC0oABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljbHVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAdwbGFubmVycQB-AANMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cAAIAAgAvXQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAHBwcHBwcHBwc3IAEWphdmEudXRpbC5IYXNoTWFwBQfawcMWYNEDAAJGAApsb2FkRmFjdG9ySQAJdGhyZXNob2xkeHA_QAAADHcIEAF0AApWbVBhc3N3b3JkdAAcck8wQUJYUUFEbk5oZG1Wa1gzQmhjM04zYjNKa3hw,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 192022089101382, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Mon Jul 20 14:36:49 EST 2015}, job origin:2133
com.cloud.exception.ConcurrentOperationException: There are concurrent
operations on VM[User|i-8-189-VM]
at
com.cloud.vm.VirtualMachineManagerImpl.changeToStartState(VirtualMachineManagerImpl.java:738)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:841)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4570)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at
[jira] [Commented] (CLOUDSTACK-8716) Verify creation of snapshot from volume when the task is performed repeatedly in zone wide primary Storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14679612#comment-14679612 ] ASF GitHub Bot commented on CLOUDSTACK-8716: Github user pritisarap12 commented on the pull request: https://github.com/apache/cloudstack/pull/665#issuecomment-129314182 Updated testcase: -Removed redundant code -Added validate_list function for list snapshot operation Verify creation of snapshot from volume when the task is performed repeatedly in zone wide primary Storage. --- Key: CLOUDSTACK-8716 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8716 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.2.1 Reporter: Priti Sarap Fix For: 4.2.1 On VMWare with a Zone wide primary storage and more than two clusters verify successful creation of snapshot multiple times. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
