[jira] [Reopened] (CLOUDSTACK-7648) There are new VM State Machine changes introduced which were missed to capture the usage events
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav reopened CLOUDSTACK-7648: - not fixed on 4.5 branch > There are new VM State Machine changes introduced which were missed to > capture the usage events > --- > > Key: CLOUDSTACK-7648 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7648 > 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: Damodar Reddy T >Assignee: Damodar Reddy T > Fix For: 4.5.0 > > > There are new VM State Machine changes introduced while adding VM Sync > changes and these were missed to capture the usage events. > This is causing to get wrong usage statistics for a VM who's state is changed > by VM sync -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7582) Not able to remove tag from primary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14283670#comment-14283670 ] ASF subversion and git services commented on CLOUDSTACK-7582: - Commit 45108fdbadaf0e0b8d6a98a730a27ab00bcca3b7 in cloudstack's branch refs/heads/4.5 from [~saksham] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=45108fd ] CLOUDSTACK-7582: Update Storage Pool API does not update tags correctly (cherry picked from commit fc4dceaa991ecacf0d248725decd5370622ea0ed) Signed-off-by: Rohit Yadav > Not able to remove tag from primary storage > --- > > Key: CLOUDSTACK-7582 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7582 > 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 >Reporter: prashant kumar mishra >Assignee: Rajesh Battala > Fix For: 4.5.0 > > > steps to reproduce > == > 1-update storage tags > 2-try to remove tag by passing empty value > expected: > > tags should be removed > actual > > storage tag is not getting removed > API > === > http://10.147.59.173:8096/client/api?command=updateStoragePool&id=f672eae0-b400-3767-808f-b787a5c04d5f&tags=&capacitybytes=5497558138880&response=xml > cloud-stack-version="4.5.0-SNAPSHOT">f672eae0-b400-3767-808f-b787a5c04d5fd5e96cca-0985-49fe-a777-49b257278c8amanasaprimaryVMw10.147.28.7/export/home/manasa/primaryVMw2014-09-12T11:26:37+0530NetworkFilesystem549755813888042949672962696516272128abUpZONEVMware -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7534) ResetVM for VM with attached datadisk fails when enable.ha.storage.migration is false
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14283672#comment-14283672 ] ASF subversion and git services commented on CLOUDSTACK-7534: - Commit 9cf05dc842f3fb4649746ad536eca1855184e15b in cloudstack's branch refs/heads/4.5 from [~harikrishna.patnala] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9cf05dc ] CLOUDSTACK-7534: ResetVM for VM with attached datadisk fails when enable.ha.storage.migration is false Separate global config to enable/disable Storage Migration during normal deployment Introduced a configuration parameter named enable.storage.migration (cherry picked from commit c55bc0b2d11be4820a24af426e23da3db54a0cb1) Signed-off-by: Rohit Yadav > ResetVM for VM with attached datadisk fails when enable.ha.storage.migration > is false > - > > Key: CLOUDSTACK-7534 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7534 > 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: Harikrishna Patnala >Assignee: Harikrishna Patnala > Fix For: 4.5.0 > > > ResetVM for a VM having a attached datadisk fails if, > 1. there are 2 or more storage pools in the cluster > 2. enable.ha.storage.migration is set to false > 3. allocator has chosen a different pool for the datadisk than where it > currently exists and migration from one pool to another failed because > enable.ha.storage.migration set to false. > The issue is currently "enable.ha.storage.migration" applies to both normal > and HA deployment. We should have another parameter which is specific to > normal deployments (say enable.storage.migration) so that during migration > check we can clearly differentiate normal and HA deployments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7571) changing value of cpu/mem.overprovisioning.factor for xen cluster is not affecting total memory at zone level
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14283671#comment-14283671 ] ASF subversion and git services commented on CLOUDSTACK-7571: - Commit bf8db0c743c94c4540dab2f069d253f1a859eb10 in cloudstack's branch refs/heads/4.5 from [~bharat.kumar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bf8db0c ] CLOUDSTACK-7571 changing value of cpu/mem.overprovisioning.factor for xen cluster is not affecting total memory at zone level (cherry picked from commit 476733cb92634c8494fe64762d7fbc178292a754) Signed-off-by: Rohit Yadav > changing value of cpu/mem.overprovisioning.factor for xen cluster is not > affecting total memory at zone level > - > > Key: CLOUDSTACK-7571 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7571 > 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: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > steps to reproduce > == > 1-prepare a CS3.6 setup with vmware and xen cluster > 2-set mem.overprovisioning.factor=3 and cpu.overprovisioning.factor=2 > 2-upgrade it to CCP4.3 > 3-record total memory and cpu at zone level > 4-change cpu/memory overprovisioning for xen server cluster to some valid > value > expected > = > at zone level total memory should get changed , depends on overprovisioning > value > Actual > === > 1-total memory is not getting changed at zone level > 2-but total memory/cpu of xen cluster is getting changed with > overprovisioning factor > My observation > == > 1-if i change overspovisioning factor of vmware cluster total memory is > getting changed > 2-In fresh setup with one xen cluster i did not see this problem -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7469) Simulator build support need to extends for RPM build
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14283673#comment-14283673 ] ASF subversion and git services commented on CLOUDSTACK-7469: - Commit 45ebdf34aee51217bf32e58039da16870dd1e5b3 in cloudstack's branch refs/heads/4.5 from [~alexbre] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=45ebdf3 ] CLOUDSTACK-7469 Complete simulator build support The initial commit (f96c65416a2802bcf2a1f8d5a5070ffe6a29111f) missed part of the change to package.sh, so we were not actually passing through the simulator build option to the rpmbuild call. This patch completes the support. (cherry picked from commit e717450e0edd2406c4c3fc7341b3669c4390d507) Signed-off-by: Rohit Yadav > 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] [Created] (CLOUDSTACK-8170) Skip test cases which try to scale VM in running state, on Hyperv
Gaurav Aradhye created CLOUDSTACK-8170: -- Summary: Skip test cases which try to scale VM in running state, on Hyperv Key: CLOUDSTACK-8170 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8170 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.5.0 The feature is not supported on Hyperv. Hence skip the tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8170) Skip test cases which try to scale VM in running state, on Hyperv
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye updated CLOUDSTACK-8170: --- Status: Reviewable (was: In Progress) > Skip test cases which try to scale VM in running state, on Hyperv > - > > Key: CLOUDSTACK-8170 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8170 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > The feature is not supported on Hyperv. Hence skip the tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8171) Lock related warnings seen in 4.5/master related to template_spool_ref2
Rohit Yadav created CLOUDSTACK-8171: --- Summary: Lock related warnings seen in 4.5/master related to template_spool_ref2 Key: CLOUDSTACK-8171 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8171 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.5.0, 4.6.0 Reporter: Rohit Yadav Fix For: 4.5.0, 4.6.0 Warnings seen on 4.5 mgmt server startup: INFO [o.a.c.s.v.VolumeServiceImpl] (Work-Job-Executor-18:ctx-7e377b10 job-29/job-30 ctx-a3a27aa3) releasing lock for VMTemplateStoragePool 2 WARN [c.c.u.d.Merovingian2] (Work-Job-Executor-18:ctx-7e377b10 job-29/job-30 ctx-a3a27aa3) Was unable to find lock for the key template_spool_ref2 and thread id 1504476186 com.cloud.utils.exception.CloudRuntimeException: Was unable to find lock for the key template_spool_ref2 and thread id 1504476186 at com.cloud.utils.db.Merovingian2.release(Merovingian2.java:274) at com.cloud.utils.db.TransactionLegacy.release(TransactionLegacy.java:397) at com.cloud.utils.db.GenericDaoBase.releaseFromLockTable(GenericDaoBase.java:1045) at sun.reflect.GeneratedMethodAccessor185.invoke(Unknown Source) 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 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 com.sun.proxy.$Proxy75.releaseFromLockTable(Unknown Source) at org.apache.cloudstack.storage.volume.VolumeServiceImpl.createBaseImageAsync(VolumeServiceImpl.java:513) at org.apache.cloudstack.storage.volume.VolumeServiceImpl.createVolumeFromTemplateAsync(VolumeServiceImpl.java:747) at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.recreateVolume(VolumeOrchestrator.java:1250) at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.prepare(VolumeOrchestrator.java:1320) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:981) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4440) 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:4596) at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:536) 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:493) 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) -- This message was sent by
[jira] [Updated] (CLOUDSTACK-8172) Console proxy does not work in advance network with KVM and ACS 4.5
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav updated CLOUDSTACK-8172: Description: While this could be an environment related issue. On KVM (Ubuntu 14.04 x64 host) host with latest (SHA 45ebdf34aee51217bf32e58039da16870dd1e5b3) ACS 4.5 I'm unable to get console proxy to work. While SSVM seems to work along with VPCs and VLAN isolation based isolated SNAT network. In case it works on your environment, please comment and close this ticket. was:While this could be an environment related issue. On KVM (Ubuntu 14.04 x64 host) host with latest (SHA 45ebdf34aee51217bf32e58039da16870dd1e5b3) ACS 4.5 I'm unable to get console proxy to work. While SSVM seems to work along with VPCs and VLAN isolation based isolated SNAT network. > Console proxy does not work in advance network with KVM and ACS 4.5 > --- > > Key: CLOUDSTACK-8172 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8172 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.0 >Reporter: Rohit Yadav >Priority: Blocker > Fix For: 4.5.0, 4.6.0 > > > While this could be an environment related issue. On KVM (Ubuntu 14.04 x64 > host) host with latest (SHA 45ebdf34aee51217bf32e58039da16870dd1e5b3) ACS 4.5 > I'm unable to get console proxy to work. While SSVM seems to work along with > VPCs and VLAN isolation based isolated SNAT network. > In case it works on your environment, please comment and close this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8172) Console proxy does not work in advance network with KVM and ACS 4.5
Rohit Yadav created CLOUDSTACK-8172: --- Summary: Console proxy does not work in advance network with KVM and ACS 4.5 Key: CLOUDSTACK-8172 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8172 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Rohit Yadav Fix For: 4.5.0, 4.6.0 While this could be an environment related issue. On KVM (Ubuntu 14.04 x64 host) host with latest (SHA 45ebdf34aee51217bf32e58039da16870dd1e5b3) ACS 4.5 I'm unable to get console proxy to work. While SSVM seems to work along with VPCs and VLAN isolation based isolated SNAT network. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8172) Console proxy does not work in advance network with KVM and ACS 4.5
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav updated CLOUDSTACK-8172: Priority: Blocker (was: Major) > Console proxy does not work in advance network with KVM and ACS 4.5 > --- > > Key: CLOUDSTACK-8172 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8172 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.0 >Reporter: Rohit Yadav >Priority: Blocker > Fix For: 4.5.0, 4.6.0 > > > While this could be an environment related issue. On KVM (Ubuntu 14.04 x64 > host) host with latest (SHA 45ebdf34aee51217bf32e58039da16870dd1e5b3) ACS 4.5 > I'm unable to get console proxy to work. While SSVM seems to work along with > VPCs and VLAN isolation based isolated SNAT network. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
