[jira] [Commented] (CLOUDSTACK-5700) [Vmsync] - kvm- "paused" state of Vm is not synced to CS.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14211939#comment-14211939 ] Bharat Kumar commented on CLOUDSTACK-5700: -- Hi, Cloudstack considers paused VMs as running by design. > [Vmsync] - kvm- "paused" state of Vm is not synced to CS. > - > > Key: CLOUDSTACK-5700 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5700 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Bharat Kumar > Fix For: 4.4.0, 4.5.0 > > > [Vmsync] - kvm - "paused" state of Vm is not synced to CS. > Steps to reproduce the problem: > PreReq: > Have few Vms deployed using Cloudstack. > Steps: > Outside of Cloudstack , Suspend an existing VM using the following command: > virsh suspend > Vmsync does not detect the "paused" state of a VM. CS reports the real state > of this VM as "running" > 2013-12-31 18:44:20,977 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) Found 6 VMs for host 2 > 2013-12-31 18:44:20,990 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) VM i-3-3-VM: cs state = Running and > realState = Running > 2013-12-31 18:44:20,997 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) VM i-3-3-VM: cs state = Running and > realState = Running > 2013-12-31 18:44:20,997 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) Both states are Running for > VM[User|TestVM-1] > [root@Rack3Host14 ~]# virsh list > IdName State > > 2 r-4-VM running > 5 i-3-6-VM running > 6 i-3-5-VM running > 7 s-9-VM running > 9 i-3-8-VM running > 10i-3-3-VM paused -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-5700) [Vmsync] - kvm- "paused" state of Vm is not synced to CS.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-5700. -- Resolution: Fixed > [Vmsync] - kvm- "paused" state of Vm is not synced to CS. > - > > Key: CLOUDSTACK-5700 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5700 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Bharat Kumar > Fix For: 4.4.0, 4.5.0 > > > [Vmsync] - kvm - "paused" state of Vm is not synced to CS. > Steps to reproduce the problem: > PreReq: > Have few Vms deployed using Cloudstack. > Steps: > Outside of Cloudstack , Suspend an existing VM using the following command: > virsh suspend > Vmsync does not detect the "paused" state of a VM. CS reports the real state > of this VM as "running" > 2013-12-31 18:44:20,977 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) Found 6 VMs for host 2 > 2013-12-31 18:44:20,990 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) VM i-3-3-VM: cs state = Running and > realState = Running > 2013-12-31 18:44:20,997 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) VM i-3-3-VM: cs state = Running and > realState = Running > 2013-12-31 18:44:20,997 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) Both states are Running for > VM[User|TestVM-1] > [root@Rack3Host14 ~]# virsh list > IdName State > > 2 r-4-VM running > 5 i-3-6-VM running > 6 i-3-5-VM running > 7 s-9-VM running > 9 i-3-8-VM running > 10i-3-3-VM paused -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7300) Cannot create Snapshot on KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14211941#comment-14211941 ] Bharat Kumar commented on CLOUDSTACK-7300: -- not an issue in 4.5, Snapshots are working. > Cannot create Snapshot on KVM > - > > Key: CLOUDSTACK-7300 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7300 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Snapshot >Affects Versions: 4.4.0 > Environment: KVM on CentOS >Reporter: Prieur Leary >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.4.1 > > > Cannot create volume Snapshots on KVM. > 1. Creating a Snapshot says successful. > 2. When viewing the actual Snapshot, it shows "Error" status. > 3. Management Server Logs the error below. > 4. It seems the Snapshot is attempting to be copied to a path that is not > mounted (Sec Storage Snapshots). > 5. Have restarted Agent, SSVM, and management server. Has not corrected. > -- > 2014-08-09 14:31:18,321 DEBUG [c.c.s.s.SnapshotManagerImpl] > (Work-Job-Executor-12:ctx-013228d1 job-95851/job-95852 ctx-38207feb) Failed > to create snapshot > com.cloud.utils.exception.CloudRuntimeException: Failed to backup > c498663d-5986-4ee1-a864-bf99a7fab48d for disk > /mnt/cdad7fd2-36fe-37f3-bba2-04acb043ea78/f07a87ad-b5c9-4932-9328-0ebd67967f04 > to /m$ > at > org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:282) > at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:137) > at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:300) > at > com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:922) > 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.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.$Proxy178.takeSnapshot(Unknown Source) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1738) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2475) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.Del > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy178.takeSnapshot(Unknown Source) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1738) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2475) > 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.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2483) > at sun.reflect.Nat
[jira] [Commented] (CLOUDSTACK-7004) [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212097#comment-14212097 ] Bharat Kumar commented on CLOUDSTACK-7004: -- could not reproduce on 4.5 > [Automation] [KVM] Deploying a VM with rootdisksize less than the size of > template does not fail > > > Key: CLOUDSTACK-7004 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7004 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Automation, KVM >Affects Versions: 4.4.0 > Environment: KVM >Reporter: Gaurav Aradhye >Assignee: Bharat Kumar > Labels: api, automation, kvm > Fix For: 4.4.0, 4.5.0 > > > Deploy a VM with parameter rootdisksize less than the template size. > API should throw error for this but it succeeds. > Although the root disk size of deployed VM is equal to template size in this > case, but this operation should throw error and VM should not be deployed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7922) CLONE - [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail
Bharat Kumar created CLOUDSTACK-7922: Summary: CLONE - [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail Key: CLOUDSTACK-7922 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7922 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API, Automation, KVM Affects Versions: 4.4.0 Environment: KVM Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.4.0, 4.5.0 Deploy a VM with parameter rootdisksize less than the template size. API should throw error for this but it succeeds. Although the root disk size of deployed VM is equal to template size in this case, but this operation should throw error and VM should not be deployed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7922) CLONE - [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7922: - Fix Version/s: (was: 4.5.0) > CLONE - [Automation] [KVM] Deploying a VM with rootdisksize less than the > size of template does not fail > > > Key: CLOUDSTACK-7922 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7922 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Automation, KVM >Affects Versions: 4.4.0 > Environment: KVM >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Labels: api, automation, kvm > Fix For: 4.4.0 > > > Deploy a VM with parameter rootdisksize less than the template size. > API should throw error for this but it succeeds. > Although the root disk size of deployed VM is equal to template size in this > case, but this operation should throw error and VM should not be deployed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7004) [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7004: - Fix Version/s: (was: 4.4.0) > [Automation] [KVM] Deploying a VM with rootdisksize less than the size of > template does not fail > > > Key: CLOUDSTACK-7004 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7004 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Automation, KVM >Affects Versions: 4.4.0 > Environment: KVM >Reporter: Gaurav Aradhye >Assignee: Bharat Kumar > Labels: api, automation, kvm > Fix For: 4.5.0 > > > Deploy a VM with parameter rootdisksize less than the template size. > API should throw error for this but it succeeds. > Although the root disk size of deployed VM is equal to template size in this > case, but this operation should throw error and VM should not be deployed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7004) [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-7004. -- Resolution: Cannot Reproduce > [Automation] [KVM] Deploying a VM with rootdisksize less than the size of > template does not fail > > > Key: CLOUDSTACK-7004 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7004 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Automation, KVM >Affects Versions: 4.4.0 > Environment: KVM >Reporter: Gaurav Aradhye >Assignee: Bharat Kumar > Labels: api, automation, kvm > Fix For: 4.5.0 > > > Deploy a VM with parameter rootdisksize less than the template size. > API should throw error for this but it succeeds. > Although the root disk size of deployed VM is equal to template size in this > case, but this operation should throw error and VM should not be deployed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7300) Cannot create Snapshot on KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7300: - Status: Reviewable (was: In Progress) > Cannot create Snapshot on KVM > - > > Key: CLOUDSTACK-7300 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7300 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Snapshot >Affects Versions: 4.4.0 > Environment: KVM on CentOS >Reporter: Prieur Leary >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.4.1 > > > Cannot create volume Snapshots on KVM. > 1. Creating a Snapshot says successful. > 2. When viewing the actual Snapshot, it shows "Error" status. > 3. Management Server Logs the error below. > 4. It seems the Snapshot is attempting to be copied to a path that is not > mounted (Sec Storage Snapshots). > 5. Have restarted Agent, SSVM, and management server. Has not corrected. > -- > 2014-08-09 14:31:18,321 DEBUG [c.c.s.s.SnapshotManagerImpl] > (Work-Job-Executor-12:ctx-013228d1 job-95851/job-95852 ctx-38207feb) Failed > to create snapshot > com.cloud.utils.exception.CloudRuntimeException: Failed to backup > c498663d-5986-4ee1-a864-bf99a7fab48d for disk > /mnt/cdad7fd2-36fe-37f3-bba2-04acb043ea78/f07a87ad-b5c9-4932-9328-0ebd67967f04 > to /m$ > at > org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:282) > at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:137) > at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:300) > at > com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:922) > 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.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.$Proxy178.takeSnapshot(Unknown Source) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1738) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2475) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.Del > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy178.takeSnapshot(Unknown Source) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1738) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2475) > 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.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2483) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at
[jira] [Commented] (CLOUDSTACK-7501) System VM fails to move from one cluster to another cluster when hypervisor type differs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14213475#comment-14213475 ] Bharat Kumar commented on CLOUDSTACK-7501: -- if we do not mention any default hypervisor, Cloudstack tries to start a vm on different hypervisor after some retries. While creating a new system vm we select the hypervisor type. If there is more than one hypervisor available for deployment we shuffle the list and pick one. > System VM fails to move from one cluster to another cluster when hypervisor > type differs > > > Key: CLOUDSTACK-7501 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7501 > 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: shweta agarwal >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.5.0 > > Attachments: Ms.tar.gz > > > Repro steps: > 1. Create a LXC advance zone setup with one LXC cluster > 2. When system vms are up .add one more KVM cluster > 3. Put LXC host to maintenance > Bug: > System VM is not coming up on KVM cluster > Expected result: > System VMs should come up on KVM cluster > Ms log shows : > Cluster: 2 has HyperVisorType that does not match the VM, skipping this > cluster > which should not be the case in case of SSVM and CPVM > attaching MS logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7501) System VM fails to move from one cluster to another cluster when hypervisor type differs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-7501. -- Resolution: Fixed > System VM fails to move from one cluster to another cluster when hypervisor > type differs > > > Key: CLOUDSTACK-7501 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7501 > 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: shweta agarwal >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.5.0 > > Attachments: Ms.tar.gz > > > Repro steps: > 1. Create a LXC advance zone setup with one LXC cluster > 2. When system vms are up .add one more KVM cluster > 3. Put LXC host to maintenance > Bug: > System VM is not coming up on KVM cluster > Expected result: > System VMs should come up on KVM cluster > Ms log shows : > Cluster: 2 has HyperVisorType that does not match the VM, skipping this > cluster > which should not be the case in case of SSVM and CPVM > attaching MS logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7501) System VM fails to move from one cluster to another cluster when hypervisor type differs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14213475#comment-14213475 ] Bharat Kumar edited comment on CLOUDSTACK-7501 at 11/15/14 9:39 AM: if we do not mention any default hypervisor, Cloudstack tries to start a SSVM on different hypervisor after some retries. While creating a new SSVM vm we select the hypervisor type. If there is more than one hypervisor available for deployment we shuffle the list and pick one. Note: In case of CPVM we do not do this unless the CPVM is destroyed. was (Author: bharat.kumar): if we do not mention any default hypervisor, Cloudstack tries to start a vm on different hypervisor after some retries. While creating a new system vm we select the hypervisor type. If there is more than one hypervisor available for deployment we shuffle the list and pick one. > System VM fails to move from one cluster to another cluster when hypervisor > type differs > > > Key: CLOUDSTACK-7501 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7501 > 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: shweta agarwal >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.5.0 > > Attachments: Ms.tar.gz > > > Repro steps: > 1. Create a LXC advance zone setup with one LXC cluster > 2. When system vms are up .add one more KVM cluster > 3. Put LXC host to maintenance > Bug: > System VM is not coming up on KVM cluster > Expected result: > System VMs should come up on KVM cluster > Ms log shows : > Cluster: 2 has HyperVisorType that does not match the VM, skipping this > cluster > which should not be the case in case of SSVM and CPVM > attaching MS logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7300) Cannot create Snapshot on KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7300: - Status: Open (was: Reviewable) > Cannot create Snapshot on KVM > - > > Key: CLOUDSTACK-7300 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7300 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Snapshot >Affects Versions: 4.4.0 > Environment: KVM on CentOS >Reporter: Prieur Leary >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.4.1 > > > Cannot create volume Snapshots on KVM. > 1. Creating a Snapshot says successful. > 2. When viewing the actual Snapshot, it shows "Error" status. > 3. Management Server Logs the error below. > 4. It seems the Snapshot is attempting to be copied to a path that is not > mounted (Sec Storage Snapshots). > 5. Have restarted Agent, SSVM, and management server. Has not corrected. > -- > 2014-08-09 14:31:18,321 DEBUG [c.c.s.s.SnapshotManagerImpl] > (Work-Job-Executor-12:ctx-013228d1 job-95851/job-95852 ctx-38207feb) Failed > to create snapshot > com.cloud.utils.exception.CloudRuntimeException: Failed to backup > c498663d-5986-4ee1-a864-bf99a7fab48d for disk > /mnt/cdad7fd2-36fe-37f3-bba2-04acb043ea78/f07a87ad-b5c9-4932-9328-0ebd67967f04 > to /m$ > at > org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:282) > at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:137) > at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:300) > at > com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:922) > 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.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.$Proxy178.takeSnapshot(Unknown Source) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1738) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2475) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.Del > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy178.takeSnapshot(Unknown Source) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1738) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2475) > 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.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2483) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.r
[jira] [Created] (CLOUDSTACK-7939) when a template is deleted an copied over again the removed column is not updated properly.
Bharat Kumar created CLOUDSTACK-7939: Summary: when a template is deleted an copied over again the removed column is not updated properly. Key: CLOUDSTACK-7939 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7939 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 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7939) when a template is deleted and copied over again the removed column is not updated properly.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7939: - Summary: when a template is deleted and copied over again the removed column is not updated properly. (was: when a template is deleted an copied over again the removed column is not updated properly.) > when a template is deleted and copied over again the removed column is not > updated properly. > > > Key: CLOUDSTACK-7939 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7939 > 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 > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-6873) [Automation] Ability to execute tests in sequence
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-6873. -- Resolution: Fixed > [Automation] Ability to execute tests in sequence > - > > Key: CLOUDSTACK-6873 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6873 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Koushik Das >Assignee: Bharat Kumar > Fix For: 4.5.1 > > > Currently BVT/regression tests are executed in parallel by the test > infrastructure. It needs to be enhanced to add capability to execute a > selective set of tests in sequence. > Specific scenario is tests that uses simulator mocks. These mocks are scoped > to a zone, pod, cluster or host. Once defined any tests targeting a specific > host will execute as per the mocks defined. Now in the current framework it > is not possible to prevent existing tests from going to a specific host. As a > result there needs to be a capability to execute a specific set of test cases > in sequence. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7710) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-7710. -- Resolution: Duplicate > Triage and fix Coverity defects > --- > > Key: CLOUDSTACK-7710 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7710 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Santhosh Kumar Edukulla >Assignee: Bharat Kumar > Fix For: 4.5.1 > > > 1. We have Coverity setup available, running as scheduled and individual > owners are assigned with analyzed bugs. > 2. As part of this bug, please triage and fix the relevant Coverity bugs > assigned. It could be a count as small as 25 bugs. > 3. First start with high impact in order to others later. > 4. We can either triage them accordingly as fix required or false positive or > not a bug accordingly. But, triage and fix accordingly wherever relevant and > applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8353) Including windows guest performance improvement flags like hv_vapic and hv_spinlock in CCP
Bharat Kumar created CLOUDSTACK-8353: Summary: Including windows guest performance improvement flags like hv_vapic and hv_spinlock in CCP Key: CLOUDSTACK-8353 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8353 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.6.0 There is a bug in KVM that causes a BSOD for Windows 2008 R2 and 7 or earlier. fix was added in RHEL 6.5. The fix requires enabling the "hv_relaxed" option for the affected VMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8353) Including windows guest performance improvement flags like hv_vapic and hv_spinlock in CCP
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-8353: - Description: There is a bug in KVM that causes a BSOD for Windows 2008 R2 and 7 or earlier. fix was added in libvirt 1.1.1 The fix requires enabling the "hv_relaxed" option for the affected VMs. (was: There is a bug in KVM that causes a BSOD for Windows 2008 R2 and 7 or earlier. fix was added in RHEL 6.5. The fix requires enabling the "hv_relaxed" option for the affected VMs. ) > Including windows guest performance improvement flags like hv_vapic and > hv_spinlock in CCP > -- > > Key: CLOUDSTACK-8353 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8353 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.6.0 > > > There is a bug in KVM that causes a BSOD for Windows 2008 R2 and 7 or > earlier. fix was added in libvirt 1.1.1 The fix requires enabling the > "hv_relaxed" option for the affected VMs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8360) Install issue: RPM install failing with a DB error message
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14394246#comment-14394246 ] Bharat Kumar commented on CLOUDSTACK-8360: -- might happen in a upgraded setup. not sure though, Found iso_id1 field in the schema-307to410.sql. Did not find a cleanup attempt in the schema-307to410-cleanup.sql. > Install issue: RPM install failing with a DB error message > -- > > Key: CLOUDSTACK-8360 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8360 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.6.0 >Reporter: Raja Pullela >Priority: Blocker > > Built the Master branch RPMs and using the RPMs to install returned the > following message in management server log: > ERROR [c.c.u.d.Upgrade410to420] (main:null) > migrateDatafromIsoIdInVolumesTable:Exception:Unknown column 'iso_id1' in > 'field list' > com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Unknown column > 'iso_id1' in 'field list' > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:525) > at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) > at com.mysql.jdbc.Util.getInstance(Util.java:386) > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-6623) register template dose not work as expected. when using simulator and xen simultaneously
Bharat Kumar created CLOUDSTACK-6623: Summary: register template dose not work as expected. when using simulator and xen simultaneously Key: CLOUDSTACK-6623 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6623 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.4.0 Reporter: Bharat Kumar Fix For: 4.4.0 when we setup simulator and xenserver both in separate zones on a single management server, The register template always behaves as if it is executing on the simulator. i.e. register template is always successful and it dose not initiate the actual download when calling the register template API against xen-zone. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6623) register template dose not work as expected, when deploying simulator and xen zones simultaneously on a single management server.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-6623: - Summary: register template dose not work as expected, when deploying simulator and xen zones simultaneously on a single management server. (was: register template dose not work as expected. when using simulator and xen simultaneously ) > register template dose not work as expected, when deploying simulator and xen > zones simultaneously on a single management server. > - > > Key: CLOUDSTACK-6623 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6623 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Bharat Kumar > Fix For: 4.4.0 > > > when we setup simulator and xenserver both in separate zones on a single > management server, The register template always behaves as if it is executing > on the simulator. i.e. register template is always successful and it dose not > initiate the actual download when calling the register template API against > xen-zone. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6794) [Automation]: test_iso suite is failing because of no path to iso retrieval
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14013308#comment-14013308
]
Bharat Kumar commented on CLOUDSTACK-6794:
--
Hi ,
This fix is environment specific. This requires changing the test_data.py.
pushing this change into the repo might break tests running in some other env.
Currently we have fixed the issue by reading from a local copy of test_data.py.
> [Automation]: test_iso suite is failing because of no path to iso retrieval
> ---
>
> Key: CLOUDSTACK-6794
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6794
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Reporter: Santhosh Kumar Edukulla
>Assignee: Bharat Kumar
>
> From the environment, where bvt is running, the path to download iso was not
> reachable, below url "http://people.apache.org/~tsp/dummy.iso";, was used for
> downloading iso and the setup either need to have access to the this url or
> url path for local share has to be used, still otherwise these suites will
> fail.
> "iso": {
> "displaytext": "Test ISO",
> "name": "ISO",
> "url": "http://people.apache.org/~tsp/dummy.iso";,
> "bootable": False,
> "ispublic": False,
> "ostype": "CentOS 5.6 (64-bit)",
> },
> "iso1": {
> "displaytext": "Test ISO 1",
> "name": "ISO 1",
> "url": "http://people.apache.org/~tsp/dummy.iso";,
> "isextractable": True,
> "isfeatured": True,
> "ispublic": True,
> "ostype": "CentOS 5.6 (64-bit)",
> },
> "iso2": {
> "displaytext": "Test ISO 2",
> "name": "ISO 2",
> "url": "http://people.apache.org/~tsp/dummy.iso";,
> "isextractable": True,
> "isfeatured": True,
> "ispublic": True,
> "ostype": "CentOS 5.6 (64-bit)",
> "mode": 'HTTP_DOWNLOAD',
> Test Suite Exception Trace:
> File
> "/automation/virtenv/00-16-3e-5d-4a-0e/306/testenv/lib/python2.7/site-packages/nose/suite.py",
> line 208, in run
> self.setUp()
> File
> "/automation/virtenv/00-16-3e-5d-4a-0e/306/testenv/lib/python2.7/site-packages/nose/suite.py",
> line 291, in setUp
> self.setupContext(ancestor)
> File
> "/automation/virtenv/00-16-3e-5d-4a-0e/306/testenv/lib/python2.7/site-packages/nose/suite.py",
> line 314, in setupContext
> try_run(context, names)
> File
> "/automation/virtenv/00-16-3e-5d-4a-0e/306/testenv/lib/python2.7/site-packages/nose/util.py",
> line 470, in try_run
> return func()
> File
> "/automation/virtenv/00-16-3e-5d-4a-0e/306/test/integration/smoke/test_iso.py",
> line 188, in setUpClass
> % (cls.iso_1.id, e))
> 'Exception while downloading ISO d64c0284-8a03-42a1-8ce6-e6d2c53724ea: Error
> In Downloading ISO: ISO Status - No route to host\n >>
> begin captured stdout << -\n=== TestName: None | Status :
> EXCEPTION ===\n\n
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (CLOUDSTACK-6794) [Automation]: test_iso suite is failing because of no path to iso retrieval
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharat Kumar closed CLOUDSTACK-6794.
Resolution: Fixed
> [Automation]: test_iso suite is failing because of no path to iso retrieval
> ---
>
> Key: CLOUDSTACK-6794
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6794
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Reporter: Santhosh Kumar Edukulla
>Assignee: Bharat Kumar
>
> From the environment, where bvt is running, the path to download iso was not
> reachable, below url "http://people.apache.org/~tsp/dummy.iso";, was used for
> downloading iso and the setup either need to have access to the this url or
> url path for local share has to be used, still otherwise these suites will
> fail.
> "iso": {
> "displaytext": "Test ISO",
> "name": "ISO",
> "url": "http://people.apache.org/~tsp/dummy.iso";,
> "bootable": False,
> "ispublic": False,
> "ostype": "CentOS 5.6 (64-bit)",
> },
> "iso1": {
> "displaytext": "Test ISO 1",
> "name": "ISO 1",
> "url": "http://people.apache.org/~tsp/dummy.iso";,
> "isextractable": True,
> "isfeatured": True,
> "ispublic": True,
> "ostype": "CentOS 5.6 (64-bit)",
> },
> "iso2": {
> "displaytext": "Test ISO 2",
> "name": "ISO 2",
> "url": "http://people.apache.org/~tsp/dummy.iso";,
> "isextractable": True,
> "isfeatured": True,
> "ispublic": True,
> "ostype": "CentOS 5.6 (64-bit)",
> "mode": 'HTTP_DOWNLOAD',
> Test Suite Exception Trace:
> File
> "/automation/virtenv/00-16-3e-5d-4a-0e/306/testenv/lib/python2.7/site-packages/nose/suite.py",
> line 208, in run
> self.setUp()
> File
> "/automation/virtenv/00-16-3e-5d-4a-0e/306/testenv/lib/python2.7/site-packages/nose/suite.py",
> line 291, in setUp
> self.setupContext(ancestor)
> File
> "/automation/virtenv/00-16-3e-5d-4a-0e/306/testenv/lib/python2.7/site-packages/nose/suite.py",
> line 314, in setupContext
> try_run(context, names)
> File
> "/automation/virtenv/00-16-3e-5d-4a-0e/306/testenv/lib/python2.7/site-packages/nose/util.py",
> line 470, in try_run
> return func()
> File
> "/automation/virtenv/00-16-3e-5d-4a-0e/306/test/integration/smoke/test_iso.py",
> line 188, in setUpClass
> % (cls.iso_1.id, e))
> 'Exception while downloading ISO d64c0284-8a03-42a1-8ce6-e6d2c53724ea: Error
> In Downloading ISO: ISO Status - No route to host\n >>
> begin captured stdout << -\n=== TestName: None | Status :
> EXCEPTION ===\n\n
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Reopened] (CLOUDSTACK-6769) [Automation]: Test case failure in test_iso.py
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharat Kumar reopened CLOUDSTACK-6769:
--
Hi,
This issue occurred because of a environment issue which i have fixed. now the
test suite runs on Xenserver but not on KVM (it fails at setup on KVM).
Also out of the 5 tests running on xen only 3 are passing. the failed tests are
integration.smoke.test_iso.TestISO.test_04_extract_Iso
integration.smoke.test_iso.TestISO.test_06_copy_iso
So disabling this suite until the above mentioned issues are fixed.
> [Automation]: Test case failure in test_iso.py
> --
>
> Key: CLOUDSTACK-6769
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6769
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, XenServer
>Affects Versions: 4.4.0
>Reporter: Harikrishna Patnala
>Assignee: Girish Shilamkar
> Fix For: 4.4.0
>
>
> There is test case failure in test_iso.py
>1) integration.smoke.test_iso.TestCreateIso.test_01_create_iso
> Error Message
> Exception while downloading ISO 06f0617c-4605-4a8f-855b-085486a1fd4b: Error
> In Downloading ISO: ISO Status - Network is unreachable
> === TestName: test_01_create_iso | Status : FAILED ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> STARTED : TC: test_01_create_iso :::
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Payload: {'apiKey':
> u'kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w',
> 'command': 'listDomains', 'signature': 'Or2nHFPqukzhTba7v4PyKSS2Obc=',
> 'response': 'json'}
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Sending GET Cmd : listDomains===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 172.16.88.21
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?apiKey=kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w&command=listDomains&response=json&signature=Or2nHFPqukzhTba7v4PyKSS2Obc%3D
> HTTP/1.1" 200 159
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Response : [{path : u'ROOT', haschild : False, id :
> u'45612b7c-e49c-11e3-a141-00163e189e44', name : u'ROOT', level : 0}]
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Payload: {'apiKey':
> u'kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w',
> 'name': 'zone-xen', 'command': 'listZones', 'signature':
> '77O72WZATq83Kw9J9yK0yKsjlHM=', 'response': 'json'}
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Sending GET Cmd : listZones===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 172.16.88.21
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?response=json&apiKey=kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w&command=listZones&name=zone-xen&signature=77O72WZATq83Kw9J9yK0yKsjlHM%3D
> HTTP/1.1" 200 446
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Response : [{localstorageenabled : False, name : u'zone-xen',
> guestcidraddress : u'10.1.1.0/24', tags : [], zonetoken :
> u'921064dc-f25a-3393-94b7-7ba269fa1f82', dns2 : u'8.8.4.4', dns1 :
> u'8.8.8.8', securitygroupsenabled : False, allocationstate : u'Enabled',
> internaldns1 : u'172.16.88.7', dhcpprovider : u'VirtualRouter', networktype :
> u'Advanced', id : u'5c872b2f-53eb-46bd-8d7f-f9654f509b39', internaldns2 :
> u'172.16.88.7'}]
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Payload: {'username': 'test-account-TestISO-test_01_create_iso-UI4FTT',
> 'domainid': u'45612b7c-e49c-11e3-a141-00163e189e44', 'firstname': 'test',
> 'lastname': 'test', 'response': 'json', 'apiKey':
> u'kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w',
> 'command': 'createAccount', 'accounttype': 0, 'signature':
> 'q5ftoGqB/V1+Q+L3FGbYsOWsON0=', 'password': 'password', 'email':
> 'test-acco...@test.com'}
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Sending GET Cmd : createAccount===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 172.16.88.21
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?username=test-account-TestISO-test_01_create_iso-UI4FTT&domainid=45612b7c-e49c-11e3-a141-00163e189e44&first
[jira] [Commented] (CLOUDSTACK-6769) [Automation]: Test case failure in test_iso.py
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14017855#comment-14017855
]
Bharat Kumar commented on CLOUDSTACK-6769:
--
Hi,
In case of kvm the following iptable rule is preventing the download of iso
resulting in connection refused status.
REJECT tcp -- * eth10.0.0.0/00.0.0.0/0
state NEW tcp dpt:80 reject-with icmp-port-unreachable
> [Automation]: Test case failure in test_iso.py
> --
>
> Key: CLOUDSTACK-6769
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6769
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, XenServer
>Affects Versions: 4.4.0
>Reporter: Harikrishna Patnala
>Assignee: Girish Shilamkar
> Fix For: 4.4.0
>
>
> There is test case failure in test_iso.py
>1) integration.smoke.test_iso.TestCreateIso.test_01_create_iso
> Error Message
> Exception while downloading ISO 06f0617c-4605-4a8f-855b-085486a1fd4b: Error
> In Downloading ISO: ISO Status - Network is unreachable
> === TestName: test_01_create_iso | Status : FAILED ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> STARTED : TC: test_01_create_iso :::
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Payload: {'apiKey':
> u'kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w',
> 'command': 'listDomains', 'signature': 'Or2nHFPqukzhTba7v4PyKSS2Obc=',
> 'response': 'json'}
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Sending GET Cmd : listDomains===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 172.16.88.21
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?apiKey=kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w&command=listDomains&response=json&signature=Or2nHFPqukzhTba7v4PyKSS2Obc%3D
> HTTP/1.1" 200 159
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Response : [{path : u'ROOT', haschild : False, id :
> u'45612b7c-e49c-11e3-a141-00163e189e44', name : u'ROOT', level : 0}]
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Payload: {'apiKey':
> u'kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w',
> 'name': 'zone-xen', 'command': 'listZones', 'signature':
> '77O72WZATq83Kw9J9yK0yKsjlHM=', 'response': 'json'}
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Sending GET Cmd : listZones===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 172.16.88.21
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?response=json&apiKey=kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w&command=listZones&name=zone-xen&signature=77O72WZATq83Kw9J9yK0yKsjlHM%3D
> HTTP/1.1" 200 446
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Response : [{localstorageenabled : False, name : u'zone-xen',
> guestcidraddress : u'10.1.1.0/24', tags : [], zonetoken :
> u'921064dc-f25a-3393-94b7-7ba269fa1f82', dns2 : u'8.8.4.4', dns1 :
> u'8.8.8.8', securitygroupsenabled : False, allocationstate : u'Enabled',
> internaldns1 : u'172.16.88.7', dhcpprovider : u'VirtualRouter', networktype :
> u'Advanced', id : u'5c872b2f-53eb-46bd-8d7f-f9654f509b39', internaldns2 :
> u'172.16.88.7'}]
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Payload: {'username': 'test-account-TestISO-test_01_create_iso-UI4FTT',
> 'domainid': u'45612b7c-e49c-11e3-a141-00163e189e44', 'firstname': 'test',
> 'lastname': 'test', 'response': 'json', 'apiKey':
> u'kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w',
> 'command': 'createAccount', 'accounttype': 0, 'signature':
> 'q5ftoGqB/V1+Q+L3FGbYsOWsON0=', 'password': 'password', 'email':
> 'test-acco...@test.com'}
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Sending GET Cmd : createAccount===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 172.16.88.21
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?username=test-account-TestISO-test_01_create_iso-UI4FTT&domainid=45612b7c-e49c-11e3-a141-00163e189e44&firstname=test&lastname=test&email=test-account%40test.com&apiKey=kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQ
[jira] [Created] (CLOUDSTACK-6874) automation test failures.
Bharat Kumar created CLOUDSTACK-6874: Summary: automation test failures. Key: CLOUDSTACK-6874 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6874 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.4.0 Reporter: Bharat Kumar -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6875) test_volumes is failing on simulator runs
Bharat Kumar created CLOUDSTACK-6875:
Summary: test_volumes is failing on simulator runs
Key: CLOUDSTACK-6875
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6875
Project: CloudStack
Issue Type: Sub-task
Security Level: Public (Anyone can view this level - this is the default.)
Components: Automation
Reporter: Bharat Kumar
Error Message
Job failed: {jobprocstatus : 0, created : u'2014-06-08T20:26:20-0700', cmd :
u'org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin',
userid : u'36a2cda6-ef83-11e3-a86b-00163e0af42c', jobstatus : 2, jobid :
u'b263a941-29b1-4ab8-9c00-7a0d2678b591', jobresultcode : 530, jobresulttype :
u'object', jobresult : {errorcode : 530, errortext : u'Unexpected exception'},
accountid : u'36a29ade-ef83-11e3-a86b-00163e0af42c'}
>> begin captured stdout << -
=== TestName: test_09_delete_detached_volume | Status : EXCEPTION ===
- >> end captured stdout << --
>> begin captured logging <<
test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
DEBUG: STARTED : TC: test_09_delete_detached_volume :::
test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
DEBUG: Delete Volume ID: 24051890-92ad-4cee-8ca3-119d278b072a
test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
DEBUG: Payload: {'account': u'test-account-TestCreateVolume-N2SRV2',
'domainid': u'36a27fb8-ef83-11e3-a86b-00163e0af42c', 'name': 'Test Volume',
'zoneid': u'ef5040e4-6e78-433b-a21a-656a7ab31e80', 'apiKey':
u'Qj0GwLB-3JHedsfK1fMgeybPzQuxKvXOOkIh-WNqEuJzupMkPVV7gCa7ZIV6jMwu1bIBqZhJAKd-TWfLH7XBXQ',
'command': 'createVolume', 'signature': 'O0mZxBTYte8bIWPhtBYKUycq8Yo=',
'diskofferingid': u'92b2888e-c624-4042-82b4-632bed2bb38d', 'response': 'json'}
test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
DEBUG: Sending GET Cmd : createVolume===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.23
requests.packages.urllib3.connectionpool: DEBUG: "GET
/client/api?account=test-account-TestCreateVolume-N2SRV2&domainid=36a27fb8-ef83-11e3-a86b-00163e0af42c&name=Test+Volume&zoneid=ef5040e4-6e78-433b-a21a-656a7ab31e80&apiKey=Qj0GwLB-3JHedsfK1fMgeybPzQuxKvXOOkIh-WNqEuJzupMkPVV7gCa7ZIV6jMwu1bIBqZhJAKd-TWfLH7XBXQ&command=createVolume&signature=O0mZxBTYte8bIWPhtBYKUycq8Yo%3D&diskofferingid=92b2888e-c624-4042-82b4-632bed2bb38d&response=json
HTTP/1.1" 200 121
test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
DEBUG: === Jobid: 2249fb73-7560-4d22-a7f9-dba0507b096e Started ===
test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
DEBUG: Payload: {'signature': '8di/lZIPnn9qCgFh0fHVVrH7/8U=', 'apiKey':
u'Qj0GwLB-3JHedsfK1fMgeybPzQuxKvXOOkIh-WNqEuJzupMkPVV7gCa7ZIV6jMwu1bIBqZhJAKd-TWfLH7XBXQ',
'command': 'queryAsyncJobResult', 'response': 'json', 'jobid':
u'2249fb73-7560-4d22-a7f9-dba0507b096e'}
test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
DEBUG: Sending GET Cmd : queryAsyncJobResult===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.23
requests.packages.urllib3.connectionpool: DEBUG: "GET
/client/api?jobid=2249fb73-7560-4d22-a7f9-dba0507b096e&apiKey=Qj0GwLB-3JHedsfK1fMgeybPzQuxKvXOOkIh-WNqEuJzupMkPVV7gCa7ZIV6jMwu1bIBqZhJAKd-TWfLH7XBXQ&command=queryAsyncJobResult&response=json&signature=8di%2FlZIPnn9qCgFh0fHVVrH7%2F8U%3D
HTTP/1.1" 200 430
test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
DEBUG: Response : {jobprocstatus : 0, created : u'2014-06-08T20:26:14-0700',
cmd : u'org.apache.cloudstack.api.command.admin.volume.CreateVolumeCmdByAdmin',
userid : u'36a2cda6-ef83-11e3-a86b-00163e0af42c', jobstatus : 0, jobid :
u'2249fb73-7560-4d22-a7f9-dba0507b096e', jobresultcode : 0, jobinstanceid :
u'c936802c-42f3-4ff3-9eb2-dd003517a8ef', jobinstancetype : u'Volume', accountid
: u'36a29ade-ef83-11e3-a86b-00163e0af42c'}
test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
DEBUG: === JobId:2249fb73-7560-4d22-a7f9-dba0507b096e is Still Processing, Will
TimeOut in:3595
test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
DEBUG: Payload: {'signature': '8di/lZIPnn9qCgFh0fHVVrH7/8U=', 'apiKey':
u'Qj0GwLB-3JHedsfK1fMgeybPzQuxKvXOOkIh-WNqEuJzupMkPVV7gCa7ZIV6jMwu1bIBqZhJAKd-TWfLH7XBXQ',
'command': 'queryAsyncJobResult', 'response': 'json', 'jobid':
u'2249fb73-7560-4d22-a7f9-dba0507b096e'}
test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
DEBUG: Sending GET Cmd : queryAsyncJobResult===
requests.packages.urllib3.connectionpool: INFO: Starting new
[jira] [Updated] (CLOUDSTACK-6876) test_deploy_vgpu_enabled_vm is failing on xen and Kvm runs.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharat Kumar updated CLOUDSTACK-6876:
-
Summary: test_deploy_vgpu_enabled_vm is failing on xen and Kvm runs. (was:
test_deploy_vgpu_enabled_vm is failing on xen and ivm runs.)
> test_deploy_vgpu_enabled_vm is failing on xen and Kvm runs.
> ---
>
> Key: CLOUDSTACK-6876
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6876
> Project: CloudStack
> Issue Type: Sub-task
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Reporter: Bharat Kumar
>
> Error Message
> Execute cmd: createserviceoffering failed, due to: errorCode: 401,
> errorText:unable to verify user credentials and/or request signature
> >> begin captured stdout << -
> === TestName: test_deploy_vgpu_enabled_vm | Status : EXCEPTION ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_deploy_vgpu_enabled_vm
> (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
> DEBUG: STARTED : TC: test_deploy_vgpu_enabled_vm :::
> test_deploy_vgpu_enabled_vm
> (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
> DEBUG: Payload: {'apiKey':
> u'N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA',
> 'command': 'listDomains', 'signature': 'lalPSnJlAM6GkRDFC2sNKSa5T+o=',
> 'response': 'json'}
> test_deploy_vgpu_enabled_vm
> (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
> DEBUG: Sending GET Cmd : listDomains===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 172.16.88.21
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?apiKey=N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA&command=listDomains&response=json&signature=lalPSnJlAM6GkRDFC2sNKSa5T%2Bo%3D
> HTTP/1.1" 200 159
> test_deploy_vgpu_enabled_vm
> (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
> DEBUG: Response : [{path : u'ROOT', haschild : False, id :
> u'b5e7af36-ef7f-11e3-a141-00163e189e44', name : u'ROOT', level : 0}]
> test_deploy_vgpu_enabled_vm
> (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
> DEBUG: Payload: {'apiKey':
> u'N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA',
> 'name': 'zone-xen', 'command': 'listZones', 'signature':
> 'TFpPtnJ8uzOTOnEQ53yyluY5Ed0=', 'response': 'json'}
> test_deploy_vgpu_enabled_vm
> (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
> DEBUG: Sending GET Cmd : listZones===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 172.16.88.21
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?response=json&apiKey=N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA&command=listZones&name=zone-xen&signature=TFpPtnJ8uzOTOnEQ53yyluY5Ed0%3D
> HTTP/1.1" 200 446
> test_deploy_vgpu_enabled_vm
> (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
> DEBUG: Response : [{localstorageenabled : False, name : u'zone-xen',
> guestcidraddress : u'10.1.1.0/24', tags : [], zonetoken :
> u'21715335-f736-3016-9d97-0765620600c0', dns2 : u'8.8.4.4', dns1 :
> u'8.8.8.8', securitygroupsenabled : False, allocationstate : u'Enabled',
> internaldns1 : u'172.16.88.7', dhcpprovider : u'VirtualRouter', networktype :
> u'Advanced', id : u'243eb08f-31e9-4283-953b-52578d8b1c6a', internaldns2 :
> u'172.16.88.8'}]
> test_deploy_vgpu_enabled_vm
> (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
> DEBUG: Payload: {'apiKey':
> u'N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA',
> 'templatefilter': 'featured', 'command': 'listTemplates', 'signature':
> 'eIj8lFw1ONlBOoquO50AKcXIBEI=', 'zoneid':
> u'243eb08f-31e9-4283-953b-52578d8b1c6a', 'response': 'json'}
> test_deploy_vgpu_enabled_vm
> (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
> DEBUG: Sending GET Cmd : listTemplates===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 172.16.88.21
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?templatefilter=featured&apiKey=N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA&zoneid=243eb08f-31e9-4283-953b-52578d8b1c6a&command=listTemplates&signature=eIj8lFw1ONlBOoquO50AKcXIBEI%3D&response=json
> HTTP/1.1" 200 818
> test_deploy_vg
[jira] [Created] (CLOUDSTACK-6876) test_deploy_vgpu_enabled_vm is failing on xen and ivm runs.
Bharat Kumar created CLOUDSTACK-6876:
Summary: test_deploy_vgpu_enabled_vm is failing on xen and ivm
runs.
Key: CLOUDSTACK-6876
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6876
Project: CloudStack
Issue Type: Sub-task
Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Bharat Kumar
Error Message
Execute cmd: createserviceoffering failed, due to: errorCode: 401,
errorText:unable to verify user credentials and/or request signature
>> begin captured stdout << -
=== TestName: test_deploy_vgpu_enabled_vm | Status : EXCEPTION ===
- >> end captured stdout << --
>> begin captured logging <<
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): DEBUG:
STARTED : TC: test_deploy_vgpu_enabled_vm :::
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): DEBUG:
Payload: {'apiKey':
u'N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA',
'command': 'listDomains', 'signature': 'lalPSnJlAM6GkRDFC2sNKSa5T+o=',
'response': 'json'}
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): DEBUG:
Sending GET Cmd : listDomains===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.21
requests.packages.urllib3.connectionpool: DEBUG: "GET
/client/api?apiKey=N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA&command=listDomains&response=json&signature=lalPSnJlAM6GkRDFC2sNKSa5T%2Bo%3D
HTTP/1.1" 200 159
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): DEBUG:
Response : [{path : u'ROOT', haschild : False, id :
u'b5e7af36-ef7f-11e3-a141-00163e189e44', name : u'ROOT', level : 0}]
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): DEBUG:
Payload: {'apiKey':
u'N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA',
'name': 'zone-xen', 'command': 'listZones', 'signature':
'TFpPtnJ8uzOTOnEQ53yyluY5Ed0=', 'response': 'json'}
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): DEBUG:
Sending GET Cmd : listZones===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.21
requests.packages.urllib3.connectionpool: DEBUG: "GET
/client/api?response=json&apiKey=N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA&command=listZones&name=zone-xen&signature=TFpPtnJ8uzOTOnEQ53yyluY5Ed0%3D
HTTP/1.1" 200 446
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): DEBUG:
Response : [{localstorageenabled : False, name : u'zone-xen', guestcidraddress
: u'10.1.1.0/24', tags : [], zonetoken :
u'21715335-f736-3016-9d97-0765620600c0', dns2 : u'8.8.4.4', dns1 : u'8.8.8.8',
securitygroupsenabled : False, allocationstate : u'Enabled', internaldns1 :
u'172.16.88.7', dhcpprovider : u'VirtualRouter', networktype : u'Advanced', id
: u'243eb08f-31e9-4283-953b-52578d8b1c6a', internaldns2 : u'172.16.88.8'}]
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): DEBUG:
Payload: {'apiKey':
u'N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA',
'templatefilter': 'featured', 'command': 'listTemplates', 'signature':
'eIj8lFw1ONlBOoquO50AKcXIBEI=', 'zoneid':
u'243eb08f-31e9-4283-953b-52578d8b1c6a', 'response': 'json'}
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): DEBUG:
Sending GET Cmd : listTemplates===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.21
requests.packages.urllib3.connectionpool: DEBUG: "GET
/client/api?templatefilter=featured&apiKey=N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA&zoneid=243eb08f-31e9-4283-953b-52578d8b1c6a&command=listTemplates&signature=eIj8lFw1ONlBOoquO50AKcXIBEI%3D&response=json
HTTP/1.1" 200 818
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): DEBUG:
Response : [{domain : u'ROOT', domainid :
u'b5e7af36-ef7f-11e3-a141-00163e189e44', ostypename : u'CentOS 5.6 (64-bit)',
zoneid : u'243eb08f-31e9-4283-953b-52578d8b1c6a', displaytext : u'CentOS
5.6(64-bit) no GUI (XenServer)', ostypeid :
u'b5829966-ef7f-11e3-a141-00163e189e44', passwordenabled : False, id :
u'b57c835a-ef7f-11e3-a141-00163e189e44', size : 21474836480, isready : True,
form
[jira] [Created] (CLOUDSTACK-6877) test_01_sys_vm_start from suite test_secondary storage is failing on xen and kvm
Bharat Kumar created CLOUDSTACK-6877:
Summary: test_01_sys_vm_start from suite test_secondary storage is
failing on xen and kvm
Key: CLOUDSTACK-6877
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6877
Project: CloudStack
Issue Type: Sub-task
Security Level: Public (Anyone can view this level - this is the default.)
Components: Automation
Reporter: Bharat Kumar
Error Message
Check whether state of SSVM is running
>> begin captured stdout << -
=== TestName: test_01_sys_vm_start | Status : FAILED ===
- >> end captured stdout << --
>> begin captured logging <<
test_01_sys_vm_start
(integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
STARTED : TC: test_01_sys_vm_start :::
test_01_sys_vm_start
(integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
Payload: {'apiKey':
u'N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA',
'name': u'zone-xen', 'command': 'listZones', 'signature':
'TFpPtnJ8uzOTOnEQ53yyluY5Ed0=', 'response': 'json'}
test_01_sys_vm_start
(integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
Sending GET Cmd : listZones===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.21
requests.packages.urllib3.connectionpool: DEBUG: "GET
/client/api?response=json&apiKey=N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA&command=listZones&name=zone-xen&signature=TFpPtnJ8uzOTOnEQ53yyluY5Ed0%3D
HTTP/1.1" 200 446
test_01_sys_vm_start
(integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
Response : [{localstorageenabled : False, name : u'zone-xen', guestcidraddress
: u'10.1.1.0/24', tags : [], zonetoken :
u'21715335-f736-3016-9d97-0765620600c0', dns2 : u'8.8.4.4', dns1 : u'8.8.8.8',
securitygroupsenabled : False, allocationstate : u'Enabled', internaldns1 :
u'172.16.88.7', dhcpprovider : u'VirtualRouter', networktype : u'Advanced', id
: u'243eb08f-31e9-4283-953b-52578d8b1c6a', internaldns2 : u'172.16.88.8'}]
test_01_sys_vm_start
(integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
Payload: {'apiKey':
u'N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA',
'command': 'listPods', 'signature': 'NShFYMTbzFapYtW58DbrDRIaYDc=', 'zoneid':
u'243eb08f-31e9-4283-953b-52578d8b1c6a', 'response': 'json'}
test_01_sys_vm_start
(integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
Sending GET Cmd : listPods===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.21
requests.packages.urllib3.connectionpool: DEBUG: "GET
/client/api?zoneid=243eb08f-31e9-4283-953b-52578d8b1c6a&apiKey=N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA&command=listPods&response=json&signature=NShFYMTbzFapYtW58DbrDRIaYDc%3D
HTTP/1.1" 200 308
test_01_sys_vm_start
(integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
Response : [{endip : u'172.16.88.40', name : u'z0p0', startip :
u'172.16.88.13', allocationstate : u'Enabled', zoneid :
u'243eb08f-31e9-4283-953b-52578d8b1c6a', netmask : u'255.255.255.0', gateway :
u'172.16.88.1', id : u'53e93054-4d0c-4110-9699-314d37ce3e90', zonename :
u'zone-xen'}]
test_01_sys_vm_start
(integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
Payload: {'apiKey':
u'N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA',
'name': u'zone-xen2', 'command': 'listZones', 'signature':
'E7MrZsFm+8NgyoakHaXWYy7JN6I=', 'response': 'json'}
test_01_sys_vm_start
(integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
Sending GET Cmd : listZones===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.21
requests.packages.urllib3.connectionpool: DEBUG: "GET
/client/api?response=json&apiKey=N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA&command=listZones&name=zone-xen2&signature=E7MrZsFm%2B8NgyoakHaXWYy7JN6I%3D
HTTP/1.1" 200 430
test_01_sys_vm_start
(integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
Response : [{localstorageenabled : False, name : u'zone-xen2', guestcidraddress
: u'10.1.1.0/24', tags : [], zonetoken :
u'a372ca2f-24cd-34eb-bf89-861c7e4afd44', dns1 : u'8.8.8.8',
securitygroupsenabled : False, allocationstate : u'Enabled', internaldns1 :
u'172.16.88.7', dhcpprovider : u'VirtualRouter', networktype : u'Advanced', id
: u'916485d1-8b0f-476d-9e25-31b0c5e3a81e', internaldns2 : u'172.16.88.8'}]
test_01_sys_vm_start
(integration.smoke
[jira] [Created] (CLOUDSTACK-6878) test_snapshots.TestSnapshotRootDisk.test_01_snapshot_root_disk is failing on xen, kvm
Bharat Kumar created CLOUDSTACK-6878:
Summary:
test_snapshots.TestSnapshotRootDisk.test_01_snapshot_root_disk is failing on
xen, kvm
Key: CLOUDSTACK-6878
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6878
Project: CloudStack
Issue Type: Sub-task
Security Level: Public (Anyone can view this level - this is the default.)
Components: Automation
Reporter: Bharat Kumar
Standard Error
Trying SSH Connection: Host:172.16.88.21 User:root
Port:22 RetryCnt:60===
===SSH to Host 172.16.88.21 port : 22 SUCCESSFUL===
{Cmd: mkdir -p %s /mnt/tmp via Host: 172.16.88.21} {returns: []}
{Cmd: mount -t nfs
nfs-server.automation.hyd.com::/export/automation/1/z0secondary /mnt/tmp via
Host: 172.16.88.21} {returns: [u'mount.nfs: access denied by server while
mounting nfs-server.automation.hyd.com::/export/automation/1/z0secondary']}
{Cmd: test -f /mnt/tmp/snapshots/20/38/9831d613-3410-43d0-9d95-7570a7d8be40.vhd
&& echo 'snapshot exists' via Host: 172.16.88.21} {returns: []}
{Cmd: cd via Host: 172.16.88.21} {returns: []}
{Cmd: umount /mnt/tmp via Host: 172.16.88.21} {returns: [u'umount: /mnt/tmp:
not mounted']}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6877) test_01_sys_vm_start from suite test_secondary storage is failing on xen
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharat Kumar updated CLOUDSTACK-6877:
-
Summary: test_01_sys_vm_start from suite test_secondary storage is failing
on xen (was: test_01_sys_vm_start from suite test_secondary storage is failing
on xen and kvm)
> test_01_sys_vm_start from suite test_secondary storage is failing on xen
>
>
> Key: CLOUDSTACK-6877
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6877
> Project: CloudStack
> Issue Type: Sub-task
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Reporter: Bharat Kumar
>
> Error Message
> Check whether state of SSVM is running
> >> begin captured stdout << -
> === TestName: test_01_sys_vm_start | Status : FAILED ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_01_sys_vm_start
> (integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
> STARTED : TC: test_01_sys_vm_start :::
> test_01_sys_vm_start
> (integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
> Payload: {'apiKey':
> u'N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA',
> 'name': u'zone-xen', 'command': 'listZones', 'signature':
> 'TFpPtnJ8uzOTOnEQ53yyluY5Ed0=', 'response': 'json'}
> test_01_sys_vm_start
> (integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
> Sending GET Cmd : listZones===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 172.16.88.21
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?response=json&apiKey=N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA&command=listZones&name=zone-xen&signature=TFpPtnJ8uzOTOnEQ53yyluY5Ed0%3D
> HTTP/1.1" 200 446
> test_01_sys_vm_start
> (integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
> Response : [{localstorageenabled : False, name : u'zone-xen',
> guestcidraddress : u'10.1.1.0/24', tags : [], zonetoken :
> u'21715335-f736-3016-9d97-0765620600c0', dns2 : u'8.8.4.4', dns1 :
> u'8.8.8.8', securitygroupsenabled : False, allocationstate : u'Enabled',
> internaldns1 : u'172.16.88.7', dhcpprovider : u'VirtualRouter', networktype :
> u'Advanced', id : u'243eb08f-31e9-4283-953b-52578d8b1c6a', internaldns2 :
> u'172.16.88.8'}]
> test_01_sys_vm_start
> (integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
> Payload: {'apiKey':
> u'N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA',
> 'command': 'listPods', 'signature': 'NShFYMTbzFapYtW58DbrDRIaYDc=',
> 'zoneid': u'243eb08f-31e9-4283-953b-52578d8b1c6a', 'response': 'json'}
> test_01_sys_vm_start
> (integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
> Sending GET Cmd : listPods===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 172.16.88.21
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?zoneid=243eb08f-31e9-4283-953b-52578d8b1c6a&apiKey=N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA&command=listPods&response=json&signature=NShFYMTbzFapYtW58DbrDRIaYDc%3D
> HTTP/1.1" 200 308
> test_01_sys_vm_start
> (integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
> Response : [{endip : u'172.16.88.40', name : u'z0p0', startip :
> u'172.16.88.13', allocationstate : u'Enabled', zoneid :
> u'243eb08f-31e9-4283-953b-52578d8b1c6a', netmask : u'255.255.255.0', gateway
> : u'172.16.88.1', id : u'53e93054-4d0c-4110-9699-314d37ce3e90', zonename :
> u'zone-xen'}]
> test_01_sys_vm_start
> (integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
> Payload: {'apiKey':
> u'N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA',
> 'name': u'zone-xen2', 'command': 'listZones', 'signature':
> 'E7MrZsFm+8NgyoakHaXWYy7JN6I=', 'response': 'json'}
> test_01_sys_vm_start
> (integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
> Sending GET Cmd : listZones===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 172.16.88.21
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?response=json&apiKey=N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA&command=listZones&name=zone-xen2&signature=E7MrZsFm%2B8NgyoakHaXWYy7JN6I%3D
> HTTP/1.1" 200 430
> test_01_sys_vm_start
> (integration.smoke.test_secon
[jira] [Updated] (CLOUDSTACK-6875) test_volumes.TestVolumes.test_09_delete_detached_volume is failing on simulator runs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharat Kumar updated CLOUDSTACK-6875:
-
Summary: test_volumes.TestVolumes.test_09_delete_detached_volume is failing
on simulator runs (was: test_volumes is failing on simulator runs)
> test_volumes.TestVolumes.test_09_delete_detached_volume is failing on
> simulator runs
>
>
> Key: CLOUDSTACK-6875
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6875
> Project: CloudStack
> Issue Type: Sub-task
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Reporter: Bharat Kumar
>
> Error Message
> Job failed: {jobprocstatus : 0, created : u'2014-06-08T20:26:20-0700', cmd :
> u'org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin',
> userid : u'36a2cda6-ef83-11e3-a86b-00163e0af42c', jobstatus : 2, jobid :
> u'b263a941-29b1-4ab8-9c00-7a0d2678b591', jobresultcode : 530, jobresulttype :
> u'object', jobresult : {errorcode : 530, errortext : u'Unexpected
> exception'}, accountid : u'36a29ade-ef83-11e3-a86b-00163e0af42c'}
> >> begin captured stdout << -
> === TestName: test_09_delete_detached_volume | Status : EXCEPTION ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
> DEBUG: STARTED : TC: test_09_delete_detached_volume :::
> test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
> DEBUG: Delete Volume ID: 24051890-92ad-4cee-8ca3-119d278b072a
> test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
> DEBUG: Payload: {'account': u'test-account-TestCreateVolume-N2SRV2',
> 'domainid': u'36a27fb8-ef83-11e3-a86b-00163e0af42c', 'name': 'Test Volume',
> 'zoneid': u'ef5040e4-6e78-433b-a21a-656a7ab31e80', 'apiKey':
> u'Qj0GwLB-3JHedsfK1fMgeybPzQuxKvXOOkIh-WNqEuJzupMkPVV7gCa7ZIV6jMwu1bIBqZhJAKd-TWfLH7XBXQ',
> 'command': 'createVolume', 'signature': 'O0mZxBTYte8bIWPhtBYKUycq8Yo=',
> 'diskofferingid': u'92b2888e-c624-4042-82b4-632bed2bb38d', 'response': 'json'}
> test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
> DEBUG: Sending GET Cmd : createVolume===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 172.16.88.23
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?account=test-account-TestCreateVolume-N2SRV2&domainid=36a27fb8-ef83-11e3-a86b-00163e0af42c&name=Test+Volume&zoneid=ef5040e4-6e78-433b-a21a-656a7ab31e80&apiKey=Qj0GwLB-3JHedsfK1fMgeybPzQuxKvXOOkIh-WNqEuJzupMkPVV7gCa7ZIV6jMwu1bIBqZhJAKd-TWfLH7XBXQ&command=createVolume&signature=O0mZxBTYte8bIWPhtBYKUycq8Yo%3D&diskofferingid=92b2888e-c624-4042-82b4-632bed2bb38d&response=json
> HTTP/1.1" 200 121
> test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
> DEBUG: === Jobid: 2249fb73-7560-4d22-a7f9-dba0507b096e Started ===
> test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
> DEBUG: Payload: {'signature': '8di/lZIPnn9qCgFh0fHVVrH7/8U=', 'apiKey':
> u'Qj0GwLB-3JHedsfK1fMgeybPzQuxKvXOOkIh-WNqEuJzupMkPVV7gCa7ZIV6jMwu1bIBqZhJAKd-TWfLH7XBXQ',
> 'command': 'queryAsyncJobResult', 'response': 'json', 'jobid':
> u'2249fb73-7560-4d22-a7f9-dba0507b096e'}
> test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
> DEBUG: Sending GET Cmd : queryAsyncJobResult===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 172.16.88.23
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?jobid=2249fb73-7560-4d22-a7f9-dba0507b096e&apiKey=Qj0GwLB-3JHedsfK1fMgeybPzQuxKvXOOkIh-WNqEuJzupMkPVV7gCa7ZIV6jMwu1bIBqZhJAKd-TWfLH7XBXQ&command=queryAsyncJobResult&response=json&signature=8di%2FlZIPnn9qCgFh0fHVVrH7%2F8U%3D
> HTTP/1.1" 200 430
> test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
> DEBUG: Response : {jobprocstatus : 0, created : u'2014-06-08T20:26:14-0700',
> cmd :
> u'org.apache.cloudstack.api.command.admin.volume.CreateVolumeCmdByAdmin',
> userid : u'36a2cda6-ef83-11e3-a86b-00163e0af42c', jobstatus : 0, jobid :
> u'2249fb73-7560-4d22-a7f9-dba0507b096e', jobresultcode : 0, jobinstanceid :
> u'c936802c-42f3-4ff3-9eb2-dd003517a8ef', jobinstancetype : u'Volume',
> accountid : u'36a29ade-ef83-11e3-a86b-00163e0af42c'}
> test_09_delete_detached_volume (integration.smoke.test_volumes.TestVolumes):
> DEBUG: === JobId:2249fb73-7560-4d22-a7f9-dba0507b096e is Still Processing,
> Will TimeOut in:3595
> test_09_delete_detached_volume (i
[jira] [Created] (CLOUDSTACK-6914) The present way of tagging the test cases as provisioning and simulator is not usable. Need to modify this.
Bharat Kumar created CLOUDSTACK-6914: Summary: The present way of tagging the test cases as provisioning and simulator is not usable. Need to modify this. Key: CLOUDSTACK-6914 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6914 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.4.0 Reporter: Bharat Kumar Assignee: Santhosh Kumar Edukulla Fix For: 4.4.0 Currently we add all the test meta data in a single tag called tags, as a result we cannot use proper nosetest conditions to filter the simulator test cases from provisioning. Also some tests have both simulator and provisioning tags added to the same test case. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (CLOUDSTACK-6769) [Automation]: Test case failure in test_iso.py
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharat Kumar reopened CLOUDSTACK-6769:
--
> [Automation]: Test case failure in test_iso.py
> --
>
> Key: CLOUDSTACK-6769
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6769
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, XenServer
>Affects Versions: 4.4.0
>Reporter: Harikrishna Patnala
>Assignee: Girish Shilamkar
> Fix For: 4.4.0
>
>
> There is test case failure in test_iso.py
>1) integration.smoke.test_iso.TestCreateIso.test_01_create_iso
> Error Message
> Exception while downloading ISO 06f0617c-4605-4a8f-855b-085486a1fd4b: Error
> In Downloading ISO: ISO Status - Network is unreachable
> === TestName: test_01_create_iso | Status : FAILED ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> STARTED : TC: test_01_create_iso :::
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Payload: {'apiKey':
> u'kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w',
> 'command': 'listDomains', 'signature': 'Or2nHFPqukzhTba7v4PyKSS2Obc=',
> 'response': 'json'}
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Sending GET Cmd : listDomains===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 172.16.88.21
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?apiKey=kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w&command=listDomains&response=json&signature=Or2nHFPqukzhTba7v4PyKSS2Obc%3D
> HTTP/1.1" 200 159
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Response : [{path : u'ROOT', haschild : False, id :
> u'45612b7c-e49c-11e3-a141-00163e189e44', name : u'ROOT', level : 0}]
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Payload: {'apiKey':
> u'kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w',
> 'name': 'zone-xen', 'command': 'listZones', 'signature':
> '77O72WZATq83Kw9J9yK0yKsjlHM=', 'response': 'json'}
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Sending GET Cmd : listZones===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 172.16.88.21
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?response=json&apiKey=kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w&command=listZones&name=zone-xen&signature=77O72WZATq83Kw9J9yK0yKsjlHM%3D
> HTTP/1.1" 200 446
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Response : [{localstorageenabled : False, name : u'zone-xen',
> guestcidraddress : u'10.1.1.0/24', tags : [], zonetoken :
> u'921064dc-f25a-3393-94b7-7ba269fa1f82', dns2 : u'8.8.4.4', dns1 :
> u'8.8.8.8', securitygroupsenabled : False, allocationstate : u'Enabled',
> internaldns1 : u'172.16.88.7', dhcpprovider : u'VirtualRouter', networktype :
> u'Advanced', id : u'5c872b2f-53eb-46bd-8d7f-f9654f509b39', internaldns2 :
> u'172.16.88.7'}]
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Payload: {'username': 'test-account-TestISO-test_01_create_iso-UI4FTT',
> 'domainid': u'45612b7c-e49c-11e3-a141-00163e189e44', 'firstname': 'test',
> 'lastname': 'test', 'response': 'json', 'apiKey':
> u'kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w',
> 'command': 'createAccount', 'accounttype': 0, 'signature':
> 'q5ftoGqB/V1+Q+L3FGbYsOWsON0=', 'password': 'password', 'email':
> 'test-acco...@test.com'}
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Sending GET Cmd : createAccount===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 172.16.88.21
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?username=test-account-TestISO-test_01_create_iso-UI4FTT&domainid=45612b7c-e49c-11e3-a141-00163e189e44&firstname=test&lastname=test&email=test-account%40test.com&apiKey=kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w&command=createAccount&accounttype=0&signature=q5ftoGqB%2FV1%2BQ%2BL3FGbYsOWsON0%3D&password=password&response=json
> HTTP/1.1" 200 1650
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Response : {primarystorageavailable : u'Unlimited', domai
[jira] [Commented] (CLOUDSTACK-6769) [Automation]: Test case failure in test_iso.py
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14033855#comment-14033855
]
Bharat Kumar commented on CLOUDSTACK-6769:
--
Hi reopening this issue as the create_iso fails in KVM with a connection
refused error.
> [Automation]: Test case failure in test_iso.py
> --
>
> Key: CLOUDSTACK-6769
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6769
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, XenServer
>Affects Versions: 4.4.0
>Reporter: Harikrishna Patnala
>Assignee: Girish Shilamkar
> Fix For: 4.4.0
>
>
> There is test case failure in test_iso.py
>1) integration.smoke.test_iso.TestCreateIso.test_01_create_iso
> Error Message
> Exception while downloading ISO 06f0617c-4605-4a8f-855b-085486a1fd4b: Error
> In Downloading ISO: ISO Status - Network is unreachable
> === TestName: test_01_create_iso | Status : FAILED ===
> - >> end captured stdout << --
> >> begin captured logging <<
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> STARTED : TC: test_01_create_iso :::
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Payload: {'apiKey':
> u'kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w',
> 'command': 'listDomains', 'signature': 'Or2nHFPqukzhTba7v4PyKSS2Obc=',
> 'response': 'json'}
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Sending GET Cmd : listDomains===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 172.16.88.21
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?apiKey=kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w&command=listDomains&response=json&signature=Or2nHFPqukzhTba7v4PyKSS2Obc%3D
> HTTP/1.1" 200 159
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Response : [{path : u'ROOT', haschild : False, id :
> u'45612b7c-e49c-11e3-a141-00163e189e44', name : u'ROOT', level : 0}]
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Payload: {'apiKey':
> u'kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w',
> 'name': 'zone-xen', 'command': 'listZones', 'signature':
> '77O72WZATq83Kw9J9yK0yKsjlHM=', 'response': 'json'}
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Sending GET Cmd : listZones===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 172.16.88.21
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?response=json&apiKey=kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w&command=listZones&name=zone-xen&signature=77O72WZATq83Kw9J9yK0yKsjlHM%3D
> HTTP/1.1" 200 446
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Response : [{localstorageenabled : False, name : u'zone-xen',
> guestcidraddress : u'10.1.1.0/24', tags : [], zonetoken :
> u'921064dc-f25a-3393-94b7-7ba269fa1f82', dns2 : u'8.8.4.4', dns1 :
> u'8.8.8.8', securitygroupsenabled : False, allocationstate : u'Enabled',
> internaldns1 : u'172.16.88.7', dhcpprovider : u'VirtualRouter', networktype :
> u'Advanced', id : u'5c872b2f-53eb-46bd-8d7f-f9654f509b39', internaldns2 :
> u'172.16.88.7'}]
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Payload: {'username': 'test-account-TestISO-test_01_create_iso-UI4FTT',
> 'domainid': u'45612b7c-e49c-11e3-a141-00163e189e44', 'firstname': 'test',
> 'lastname': 'test', 'response': 'json', 'apiKey':
> u'kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w',
> 'command': 'createAccount', 'accounttype': 0, 'signature':
> 'q5ftoGqB/V1+Q+L3FGbYsOWsON0=', 'password': 'password', 'email':
> 'test-acco...@test.com'}
> test_01_create_iso (integration.smoke.test_iso.TestCreateIso): DEBUG:
> Sending GET Cmd : createAccount===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 172.16.88.21
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?username=test-account-TestISO-test_01_create_iso-UI4FTT&domainid=45612b7c-e49c-11e3-a141-00163e189e44&firstname=test&lastname=test&email=test-account%40test.com&apiKey=kDUSTcbO-_FZ70vm6gGrUqsX7vkomsJKI8HBWK4J8rQNPwQ0WbDjlejsKcq3Mmj5zsEKk8pf7Z8nK3ebpNDM6w&command=createAccount&accounttype=0&signature=q5ftoGqB%2FV1%2BQ%2BL3FGbYsOWsON0%3D&password=password&response=json
> HTTP/
[jira] [Created] (CLOUDSTACK-6933) registering an iso fails in KVM deployment.
Bharat Kumar created CLOUDSTACK-6933: Summary: registering an iso fails in KVM deployment. Key: CLOUDSTACK-6933 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6933 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.4.0 Environment: KVM advanced network Reporter: Bharat Kumar Fix For: 4.4.0 registing an iso fails with the connection refused error in KVM deployment. below are the iptable rules on the relevant SSVM in the env. Chain INPUT (policy DROP 28 packets, 1340 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- eth2 * 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:443 0 0 ACCEPT tcp -- eth2 * 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:80 0 0 ACCEPT tcp -- eth1 * 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:3922 172 13277 ACCEPT all -- eth0 * 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 4122 469K ACCEPT all -- eth1 * 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 196 10976 ACCEPT all -- eth2 * 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- eth3 * 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- lo * 0.0.0.0/00.0.0.0/0 0 0 DROP icmp -- * * 0.0.0.0/00.0.0.0/0 icmptype 13 0 0 ACCEPT icmp -- * * 0.0.0.0/00.0.0.0/0 3 180 ACCEPT tcp -- eth0 * 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:3922 Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 511 packets, 81586 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * eth10.0.0.0/0 172.16.88.0/24 state NEW tcp 2576 155K ACCEPT tcp -- * eth10.0.0.0/0 172.16.88.0/24 state NEW tcp 0 0 REJECT tcp -- * eth10.0.0.0/00.0.0.0/0 state NEW tcp dpt:80 reject-with icmp-port-unreachable 0 0 REJECT tcp -- * eth10.0.0.0/00.0.0.0/0 state NEW tcp dpt:443 reject-with icmp-port-unreachable Chain HTTP (0 references) pkts bytes target prot opt in out source destination root@s-54-QA:~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 172.16.171.10.0.0.0 UG0 00 eth2 169.254.0.0 0.0.0.0 255.255.0.0 U 0 00 eth0 172.16.88.0 0.0.0.0 255.255.255.0 U 0 00 eth1 172.16.88.0 0.0.0.0 255.255.255.0 U 0 00 eth3 172.16.171.00.0.0.0 255.255.255.0 U 0 00 eth2 As per the above config when a packet is sent to 172.16.88.x/24 subnet we are routing it via interface eth1. but we also have a reject rule in the OUTPUT chain for the packets leaving from eth1. as a result the packets get dropped. if we interchange the routes i.e. if the route related to eth3 is hit before hitting the eth1 route the register iso is successful. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7026) mark the test_01_primary_storage_iscsi as test that requires hardware.
Bharat Kumar created CLOUDSTACK-7026: Summary: mark the test_01_primary_storage_iscsi as test that requires hardware. Key: CLOUDSTACK-7026 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7026 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.4.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7026) test that requires hardware.mark the test_01_primary_storage_iscsi as test that requires hardware
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7026: - Summary: test that requires hardware.mark the test_01_primary_storage_iscsi as test that requires hardware (was: mark the test_01_primary_storage_iscsi as test that requires hardware.) > test that requires hardware.mark the test_01_primary_storage_iscsi as test > that requires hardware > -- > > Key: CLOUDSTACK-7026 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7026 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.4.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7026) mark the test_01_primary_storage_iscsi as test that requires hardware
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7026: - Summary: mark the test_01_primary_storage_iscsi as test that requires hardware (was: test that requires hardware.mark the test_01_primary_storage_iscsi as test that requires hardware) > mark the test_01_primary_storage_iscsi as test that requires hardware > - > > Key: CLOUDSTACK-7026 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7026 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.4.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-7026) mark the test_01_primary_storage_iscsi as test that requires hardware
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-7026. -- Resolution: Fixed > mark the test_01_primary_storage_iscsi as test that requires hardware > - > > Key: CLOUDSTACK-7026 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7026 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.4.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7155) Re-copying templates to other zones doesn't work
Bharat Kumar created CLOUDSTACK-7155: Summary: Re-copying templates to other zones doesn't work Key: CLOUDSTACK-7155 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7155 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. Create a new template. 2. Copy template to another zone. 3. Delete just created copy. 4. Reissue copy command DB record shows as removed in template_zone_ref table causing the deployment to fail in that zone. mysql> select * from template_zone_ref where template_id=2755; -+ id zone_id template_id created last_updatedremoved -+ 4033 1 27552013-11-25 20:12:52 2013-11-25 20:12:52 NULL 4034 2 27552013-11-25 20:21:33 2013-11-25 20:24:04 2013-11-25 20:24:04 4046 6 27552013-11-26 20:08:18 2013-11-26 20:09:16 2013-11-26 20:09:16 -+ -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7156) List templates API returns destroyed templates when recopying the template.
Bharat Kumar created CLOUDSTACK-7156: Summary: List templates API returns destroyed templates when recopying the template. Key: CLOUDSTACK-7156 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7156 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 when we recopy a template multiple entries are created in the template_store_ref. As a result when we recopy a template and list the templates we might get a incorrect response which says the template download failed even thought it got copied successfully. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7158) listCapacity API missing types for certain zones
Bharat Kumar created CLOUDSTACK-7158: Summary: listCapacity API missing types for certain zones Key: CLOUDSTACK-7158 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7158 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 Issue listCapacity only shows type 2 & 6 when for certain zones. If zone id is specified all types are shown. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7158) listCapacity API missing types for certain zones
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7158: - Status: Reviewable (was: In Progress) > listCapacity API missing types for certain zones > > > Key: CLOUDSTACK-7158 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7158 > 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 > > > Issue > > listCapacity only shows type 2 & 6 when for certain zones. If zone id is > specified all types are shown. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7156) List templates API returns destroyed templates when recopying the template.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7156: - Status: Reviewable (was: In Progress) > List templates API returns destroyed templates when recopying the template. > --- > > Key: CLOUDSTACK-7156 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7156 > 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 > > > when we recopy a template multiple entries are created in the > template_store_ref. As a result when we recopy a template and list the > templates we might get a incorrect response which says the template download > failed even thought it got copied successfully. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-5162) Usage details are not getting populated when using dynamic offerings.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-5162. -- Resolution: Fixed > Usage details are not getting populated when using dynamic offerings. > - > > Key: CLOUDSTACK-5162 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5162 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.3.0 > > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5161) add dynamic compute support to scale vm and upgrade vm apis.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-5161. -- Resolution: Fixed committed to 4.3 > add dynamic compute support to scale vm and upgrade vm apis. > > > Key: CLOUDSTACK-5161 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5161 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server >Affects Versions: 4.3.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.3.0 > > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5160) add a map to specify the custom parameters in the deployvm api.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-5160. -- Resolution: Fixed 089c7bc9f8f0861bb2eedc340ae623f5abeccfc3 4.3 > add a map to specify the custom parameters in the deployvm api. > > > Key: CLOUDSTACK-5160 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5160 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.3.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.3.0 > > > As of now we are passing the custom parametes to the deployvm command using > one parameter for each of the values. need to changes this and use a map > instead. this will be easier to add other parameters later and a neater way > to group all the custom parameters together. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-5472) UI shows incorrect vm statistics if vm deployed with dynamic compute offering
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharat Kumar reassigned CLOUDSTACK-5472:
Assignee: Bharat Kumar
> UI shows incorrect vm statistics if vm deployed with dynamic compute offering
> --
>
> Key: CLOUDSTACK-5472
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5472
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Reporter: prashant kumar mishra
>Assignee: Bharat Kumar
>
> Steps to repro
>
> 1-prepare CS setup with xen6.2
> 2-create a dynamic SO d1
> 3-deploy a vm with d1
> 4-check vm statistics in UI
> Actual
>
> vm statistics shows Total cpu=0
> My observation
>
> API response shows cpunumber":0,"cpuspeed":0,"memory":0,"cpuused":"0% which
> is incorrect.
> Details
> ==
> API
> -
> http://10.147.38.177:8080/client/api?command=listVirtualMachines&details=stats&id=352a9b66-4539-4117-9cea-ca9dd5da00fa&response=json&sessionkey=51sujrtdCbNbXHU3LotE2wx6UMk%3D&_=1386828570170
> API Response
> -
> { "listvirtualmachinesresponse" : { "count":1 ,"virtualmachine" : [
> {"id":"352a9b66-4539-4117-9cea-ca9dd5da00fa","name":"last","displayname":"last","account":"admin","domainid":"45b3c110-6261-11e3-87cf-0654483b","domain":"ROOT","created":"2013-12-12T06:24:40-0500","state":"Running","haenable":false,"zoneid":"cb7aee87-73fb-4da4-a384-2e209b132c95","zonename":"z1","hostid":"d46817a4-5e4a-4701-b3ba-188cafcb66db","hostname":"Rack1Pod1Host7","cpunumber":0,"cpuspeed":0,"memory":0,"cpuused":"0%","networkkbsread":1,"networkkbswrite":1,"diskkbsread":0,"diskkbswrite":0,"diskioread":0,"diskiowrite":0,"guestosid":"45d3b830-6261-11e3-87cf-0654483b","securitygroup":[],"nic":[{"id":"0786bc57-2423-4e07-8925-5f6dfac5f962","networkid":"5967fab2-8ca9-415e-b78d-114851a1d072","networkname":"new","netmask":"255.255.255.0","gateway":"10.1.1.1","ipaddress":"10.1.1.144","isolationuri":"vlan://1103","broadcasturi":"vlan://1103","traffictype":"Guest","type":"Isolated","isdefault":true,"macaddress":"02:00:09:23:00:05"}],"hypervisor":"XenServer","instancename":"i-2-13-VM","tags":[],"affinitygroup":[],"displayvm":true,"isdynamicallyscalable":true}
> ] } }
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5495) [Automation] Unable to stop VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13848362#comment-13848362
]
Bharat Kumar commented on CLOUDSTACK-5495:
--
was able to reproduce this on 4.3 but not on 4.2.1
> [Automation] Unable to stop VM
> --
>
> Key: CLOUDSTACK-5495
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5495
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.3.0
> Environment: XenServer 6.2
> advanced zone
>Reporter: Srikanteswararao Talluri
>Priority: Blocker
> Fix For: 4.3.0
>
> Attachments: newrunmgmt.log.zip
>
>
> Unable to Stop VM - error is hit multiple times during automation run
> Here is the stack trace:
> ===END=== 10.147.38.149 -- GET
> signature=ObNDNvmDCDDBoa%2FJ%2BFOtWBiGH%2BA%3D&apiKey=-neX9tpPuZ8bg04MAmolZWYSQkgjXMRmPNxou5hJcwAUk9Ti3nQj2ii_W4WylGRUwOjo1PW233odZZUX0-1dbg&command=queryAsyncJobResult&response=json&jobid=144b5660-716f-449c-9b52-f18ba738ad28
> 2013-12-14 00:52:18,153 WARN [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-375:ctx-3500a12b) VM destroy failed in Stop i-271-491-QA Command
> due to null
> You gave an invalid object reference. The object may have recently been
> deleted. The class parameter gives the type of reference given, and the
> handle parameter echoes the bad value given.
> at com.xensource.xenapi.Types.checkResponse(Types.java:209)
> at com.xensource.xenapi.Connection.dispatch(Connection.java:368)
> at
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909)
> at com.xensource.xenapi.VM.getPowerState(VM.java:746)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:4168)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:492)
> at
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
> at
> com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-12-14 00:52:18,161 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-375:ctx-3500a12b) 10. The VM i-271-491-QA is in Running state
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-375:ctx-3500a12b) Seq 1-494866421: Response Received:
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.t.Request]
> (DirectAgent-375:ctx-3500a12b) Seq 1-494866421: Processing: { Ans: , MgmtId:
> 6631563722783, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.StopAnswer":{"platform":"viridian:true;acpi:1;apic:true;pae:true;nx:true","result":false,"details":"Stop
> VM failed","wait":0}}] }
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.t.Request] (Job-Executor-71:ctx-aedce201
> ctx-ee5f8ea3) Seq 1-494866421: Received: { Ans: , MgmtId: 6631563722783,
> via: 1, Ver: v1, Flags: 10, { StopAnswer } }
> 2013-12-14 00:52:18,173 WARN [c.c.v.VirtualMachineManagerImpl]
> (Job-Executor-71:ctx-aedce201 ctx-ee5f8ea3) Unable to stop vm
> VM[User|QA-b6e685bf-4ba1-4572-8728-3bfd0106f6d7]
> 2013-12-14 00:52:18,187 DEBUG [c.c.v.d.VMInstanceDaoImpl]
> (Job-Executor-71:ctx-aedce201 ctx-ee5f8e
[jira] [Comment Edited] (CLOUDSTACK-5495) [Automation] Unable to stop VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13848362#comment-13848362
]
Bharat Kumar edited comment on CLOUDSTACK-5495 at 12/14/13 2:00 PM:
was able to reproduce this on 4.3 but not on 4.2.1
using xen 6.2 and 6.1
was (Author: bharat.kumar):
was able to reproduce this on 4.3 but not on 4.2.1
> [Automation] Unable to stop VM
> --
>
> Key: CLOUDSTACK-5495
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5495
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.3.0
> Environment: XenServer 6.2
> advanced zone
>Reporter: Srikanteswararao Talluri
>Priority: Blocker
> Fix For: 4.3.0
>
> Attachments: newrunmgmt.log.zip
>
>
> Unable to Stop VM - error is hit multiple times during automation run
> Here is the stack trace:
> ===END=== 10.147.38.149 -- GET
> signature=ObNDNvmDCDDBoa%2FJ%2BFOtWBiGH%2BA%3D&apiKey=-neX9tpPuZ8bg04MAmolZWYSQkgjXMRmPNxou5hJcwAUk9Ti3nQj2ii_W4WylGRUwOjo1PW233odZZUX0-1dbg&command=queryAsyncJobResult&response=json&jobid=144b5660-716f-449c-9b52-f18ba738ad28
> 2013-12-14 00:52:18,153 WARN [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-375:ctx-3500a12b) VM destroy failed in Stop i-271-491-QA Command
> due to null
> You gave an invalid object reference. The object may have recently been
> deleted. The class parameter gives the type of reference given, and the
> handle parameter echoes the bad value given.
> at com.xensource.xenapi.Types.checkResponse(Types.java:209)
> at com.xensource.xenapi.Connection.dispatch(Connection.java:368)
> at
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909)
> at com.xensource.xenapi.VM.getPowerState(VM.java:746)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:4168)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:492)
> at
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
> at
> com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-12-14 00:52:18,161 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-375:ctx-3500a12b) 10. The VM i-271-491-QA is in Running state
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-375:ctx-3500a12b) Seq 1-494866421: Response Received:
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.t.Request]
> (DirectAgent-375:ctx-3500a12b) Seq 1-494866421: Processing: { Ans: , MgmtId:
> 6631563722783, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.StopAnswer":{"platform":"viridian:true;acpi:1;apic:true;pae:true;nx:true","result":false,"details":"Stop
> VM failed","wait":0}}] }
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.t.Request] (Job-Executor-71:ctx-aedce201
> ctx-ee5f8ea3) Seq 1-494866421: Received: { Ans: , MgmtId: 6631563722783,
> via: 1, Ver: v1, Flags: 10, { StopAnswer } }
> 2013-12-14 00:52:18,173 WARN [c.c.v.VirtualMachineManagerImpl]
> (Job-Executor-71:ctx-aedce201 ctx-ee5f8ea3) Unable to stop vm
[jira] [Commented] (CLOUDSTACK-5495) [Automation] Unable to stop VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13848388#comment-13848388
]
Bharat Kumar commented on CLOUDSTACK-5495:
--
Hi,
In 4.3 i can see the execute in sequence is false for stopvm.
can this be the cause of failing to stop the VMs due to concurrency issues.
> [Automation] Unable to stop VM
> --
>
> Key: CLOUDSTACK-5495
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5495
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.3.0
> Environment: XenServer 6.2
> advanced zone
>Reporter: Srikanteswararao Talluri
>Priority: Blocker
> Fix For: 4.3.0
>
> Attachments: newrunmgmt.log.zip
>
>
> Unable to Stop VM - error is hit multiple times during automation run
> Here is the stack trace:
> ===END=== 10.147.38.149 -- GET
> signature=ObNDNvmDCDDBoa%2FJ%2BFOtWBiGH%2BA%3D&apiKey=-neX9tpPuZ8bg04MAmolZWYSQkgjXMRmPNxou5hJcwAUk9Ti3nQj2ii_W4WylGRUwOjo1PW233odZZUX0-1dbg&command=queryAsyncJobResult&response=json&jobid=144b5660-716f-449c-9b52-f18ba738ad28
> 2013-12-14 00:52:18,153 WARN [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-375:ctx-3500a12b) VM destroy failed in Stop i-271-491-QA Command
> due to null
> You gave an invalid object reference. The object may have recently been
> deleted. The class parameter gives the type of reference given, and the
> handle parameter echoes the bad value given.
> at com.xensource.xenapi.Types.checkResponse(Types.java:209)
> at com.xensource.xenapi.Connection.dispatch(Connection.java:368)
> at
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909)
> at com.xensource.xenapi.VM.getPowerState(VM.java:746)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:4168)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:492)
> at
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
> at
> com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-12-14 00:52:18,161 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-375:ctx-3500a12b) 10. The VM i-271-491-QA is in Running state
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-375:ctx-3500a12b) Seq 1-494866421: Response Received:
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.t.Request]
> (DirectAgent-375:ctx-3500a12b) Seq 1-494866421: Processing: { Ans: , MgmtId:
> 6631563722783, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.StopAnswer":{"platform":"viridian:true;acpi:1;apic:true;pae:true;nx:true","result":false,"details":"Stop
> VM failed","wait":0}}] }
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.t.Request] (Job-Executor-71:ctx-aedce201
> ctx-ee5f8ea3) Seq 1-494866421: Received: { Ans: , MgmtId: 6631563722783,
> via: 1, Ver: v1, Flags: 10, { StopAnswer } }
> 2013-12-14 00:52:18,173 WARN [c.c.v.VirtualMachineManagerImpl]
> (Job-Executor-71:ctx-aedce201 ctx-ee5f8ea3) Unable to stop vm
> VM[User|QA-b6e685bf-4ba1-4572-8728-3bfd0106f6d7]
> 2013-12
[jira] [Commented] (CLOUDSTACK-5495) [Automation] Unable to stop VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849072#comment-13849072
]
Bharat Kumar commented on CLOUDSTACK-5495:
--
Hi,
I was not able to reproduce this in 4.3 when we set the execute in sequence to
true for stopvm command.
i am seeing this error on xenserver when the vm stop fails.
VM.clean_shutdown locking failed: caught transient failure
OTHER_OPERATION_IN_PROGRESS: [ VM.clean_shutdown;
OpaqueRef:3f36c0e8-d0c5-29ba-c6b1-9a586d8b8205 ]
Server_helpers.exec exception_handler: Got exception VM_BAD_POWER_STATE: [
OpaqueRef:3f36c0e8-d0c5-29ba-c6b1-9a586d8b8205; running; halted ]
Attaching the xensource.log
> [Automation] Unable to stop VM
> --
>
> Key: CLOUDSTACK-5495
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5495
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.3.0
> Environment: XenServer 6.2
> advanced zone
>Reporter: Srikanteswararao Talluri
>Assignee: Bharat Kumar
>Priority: Blocker
> Fix For: 4.3.0
>
> Attachments: newrunmgmt.log.zip
>
>
> Unable to Stop VM - error is hit multiple times during automation run
> Here is the stack trace:
> ===END=== 10.147.38.149 -- GET
> signature=ObNDNvmDCDDBoa%2FJ%2BFOtWBiGH%2BA%3D&apiKey=-neX9tpPuZ8bg04MAmolZWYSQkgjXMRmPNxou5hJcwAUk9Ti3nQj2ii_W4WylGRUwOjo1PW233odZZUX0-1dbg&command=queryAsyncJobResult&response=json&jobid=144b5660-716f-449c-9b52-f18ba738ad28
> 2013-12-14 00:52:18,153 WARN [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-375:ctx-3500a12b) VM destroy failed in Stop i-271-491-QA Command
> due to null
> You gave an invalid object reference. The object may have recently been
> deleted. The class parameter gives the type of reference given, and the
> handle parameter echoes the bad value given.
> at com.xensource.xenapi.Types.checkResponse(Types.java:209)
> at com.xensource.xenapi.Connection.dispatch(Connection.java:368)
> at
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909)
> at com.xensource.xenapi.VM.getPowerState(VM.java:746)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:4168)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:492)
> at
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
> at
> com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-12-14 00:52:18,161 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-375:ctx-3500a12b) 10. The VM i-271-491-QA is in Running state
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-375:ctx-3500a12b) Seq 1-494866421: Response Received:
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.t.Request]
> (DirectAgent-375:ctx-3500a12b) Seq 1-494866421: Processing: { Ans: , MgmtId:
> 6631563722783, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.StopAnswer":{"platform":"viridian:true;acpi:1;apic:true;pae:true;nx:true","result":false,"details":"Stop
> VM failed","wait":0}}] }
>
[jira] [Updated] (CLOUDSTACK-5495) [Automation] Unable to stop VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharat Kumar updated CLOUDSTACK-5495:
-
Attachment: xensource-unabel-to-stop-vm.log
> [Automation] Unable to stop VM
> --
>
> Key: CLOUDSTACK-5495
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5495
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.3.0
> Environment: XenServer 6.2
> advanced zone
>Reporter: Srikanteswararao Talluri
>Assignee: Bharat Kumar
>Priority: Blocker
> Fix For: 4.3.0
>
> Attachments: newrunmgmt.log.zip, xensource-unabel-to-stop-vm.log
>
>
> Unable to Stop VM - error is hit multiple times during automation run
> Here is the stack trace:
> ===END=== 10.147.38.149 -- GET
> signature=ObNDNvmDCDDBoa%2FJ%2BFOtWBiGH%2BA%3D&apiKey=-neX9tpPuZ8bg04MAmolZWYSQkgjXMRmPNxou5hJcwAUk9Ti3nQj2ii_W4WylGRUwOjo1PW233odZZUX0-1dbg&command=queryAsyncJobResult&response=json&jobid=144b5660-716f-449c-9b52-f18ba738ad28
> 2013-12-14 00:52:18,153 WARN [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-375:ctx-3500a12b) VM destroy failed in Stop i-271-491-QA Command
> due to null
> You gave an invalid object reference. The object may have recently been
> deleted. The class parameter gives the type of reference given, and the
> handle parameter echoes the bad value given.
> at com.xensource.xenapi.Types.checkResponse(Types.java:209)
> at com.xensource.xenapi.Connection.dispatch(Connection.java:368)
> at
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909)
> at com.xensource.xenapi.VM.getPowerState(VM.java:746)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:4168)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:492)
> at
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
> at
> com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-12-14 00:52:18,161 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-375:ctx-3500a12b) 10. The VM i-271-491-QA is in Running state
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-375:ctx-3500a12b) Seq 1-494866421: Response Received:
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.t.Request]
> (DirectAgent-375:ctx-3500a12b) Seq 1-494866421: Processing: { Ans: , MgmtId:
> 6631563722783, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.StopAnswer":{"platform":"viridian:true;acpi:1;apic:true;pae:true;nx:true","result":false,"details":"Stop
> VM failed","wait":0}}] }
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.t.Request] (Job-Executor-71:ctx-aedce201
> ctx-ee5f8ea3) Seq 1-494866421: Received: { Ans: , MgmtId: 6631563722783,
> via: 1, Ver: v1, Flags: 10, { StopAnswer } }
> 2013-12-14 00:52:18,173 WARN [c.c.v.VirtualMachineManagerImpl]
> (Job-Executor-71:ctx-aedce201 ctx-ee5f8ea3) Unable to stop vm
> VM[User|QA-b6e685bf-4ba1-4572-8728-3bfd0106f6d7]
> 2013-12-14 00:52:18,187 DEBUG [c.c.v.d.VMInstanceDaoImpl]
> (Job-Executor-71:ctx-aedce201 ctx-
[jira] [Commented] (CLOUDSTACK-5502) [Automation] createVlanIpRange API failing, if you pass VLAN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13850299#comment-13850299
]
Bharat Kumar commented on CLOUDSTACK-5502:
--
This the expected behaviour. i.e. we should not pass any vlan in case of
untagged networks. marking this bug invalid.
> [Automation] createVlanIpRange API failing, if you pass VLAN
> -
>
> Key: CLOUDSTACK-5502
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5502
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.3.0
> Environment: KVM Basic Zone with SG
>Reporter: Rayees Namathponnan
>Assignee: Bharat Kumar
>Priority: Blocker
> Fix For: 4.3.0
>
>
> This issue found in KVM basic zone with SG automation run; test cases from
> below suite filed
> integration.component.test_multiple_ip_ranges.
> Steps to reproduce
> Step 1 : Create basic zone with SG
> Step 2 : Crete IP VLAN Range with below command (pass vlan=untagged)
> http://xxx..xxx.xxx:8096/?command=createVlanIpRange&gateway=10.223.251.1&forvirtualnetwork=false&startip=10.223.251.3&podid=0253bcbf-e636-4776-9e8c-216b70d195a2&zoneid=a9912aa8-a231-44d9-a70b-9d53e6db2d27&netmask=255.255.255.192&vlan=untagged
> Result;
> API command failed with error
> { "createvlaniprangeresponse" :
> {"uuidList":[],"errorcode":431,"cserrorcode":4350,"errortext":"Vlan doesn't
> match vlan of the network"} }
> this API command works only, if you are not passing any VLAN
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5502) [Automation] createVlanIpRange API failing, if you pass VLAN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharat Kumar resolved CLOUDSTACK-5502.
--
Resolution: Invalid
> [Automation] createVlanIpRange API failing, if you pass VLAN
> -
>
> Key: CLOUDSTACK-5502
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5502
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.3.0
> Environment: KVM Basic Zone with SG
>Reporter: Rayees Namathponnan
>Assignee: Bharat Kumar
>Priority: Blocker
> Fix For: 4.3.0
>
>
> This issue found in KVM basic zone with SG automation run; test cases from
> below suite filed
> integration.component.test_multiple_ip_ranges.
> Steps to reproduce
> Step 1 : Create basic zone with SG
> Step 2 : Crete IP VLAN Range with below command (pass vlan=untagged)
> http://xxx..xxx.xxx:8096/?command=createVlanIpRange&gateway=10.223.251.1&forvirtualnetwork=false&startip=10.223.251.3&podid=0253bcbf-e636-4776-9e8c-216b70d195a2&zoneid=a9912aa8-a231-44d9-a70b-9d53e6db2d27&netmask=255.255.255.192&vlan=untagged
> Result;
> API command failed with error
> { "createvlaniprangeresponse" :
> {"uuidList":[],"errorcode":431,"cserrorcode":4350,"errortext":"Vlan doesn't
> match vlan of the network"} }
> this API command works only, if you are not passing any VLAN
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5495) [Automation] Unable to stop VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13850411#comment-13850411
]
Bharat Kumar commented on CLOUDSTACK-5495:
--
Note:
The default value of the execute.in.sequence.hypervisor.commands is true in 4.3
and 4.2.
but in master the default value is false.
> [Automation] Unable to stop VM
> --
>
> Key: CLOUDSTACK-5495
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5495
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.3.0
> Environment: XenServer 6.2
> advanced zone
>Reporter: Srikanteswararao Talluri
>Assignee: Bharat Kumar
>Priority: Blocker
> Fix For: 4.3.0
>
> Attachments: newrunmgmt.log.zip, xensource-unabel-to-stop-vm.log
>
>
> Unable to Stop VM - error is hit multiple times during automation run
> Here is the stack trace:
> ===END=== 10.147.38.149 -- GET
> signature=ObNDNvmDCDDBoa%2FJ%2BFOtWBiGH%2BA%3D&apiKey=-neX9tpPuZ8bg04MAmolZWYSQkgjXMRmPNxou5hJcwAUk9Ti3nQj2ii_W4WylGRUwOjo1PW233odZZUX0-1dbg&command=queryAsyncJobResult&response=json&jobid=144b5660-716f-449c-9b52-f18ba738ad28
> 2013-12-14 00:52:18,153 WARN [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-375:ctx-3500a12b) VM destroy failed in Stop i-271-491-QA Command
> due to null
> You gave an invalid object reference. The object may have recently been
> deleted. The class parameter gives the type of reference given, and the
> handle parameter echoes the bad value given.
> at com.xensource.xenapi.Types.checkResponse(Types.java:209)
> at com.xensource.xenapi.Connection.dispatch(Connection.java:368)
> at
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909)
> at com.xensource.xenapi.VM.getPowerState(VM.java:746)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:4168)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:492)
> at
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
> at
> com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-12-14 00:52:18,161 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-375:ctx-3500a12b) 10. The VM i-271-491-QA is in Running state
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-375:ctx-3500a12b) Seq 1-494866421: Response Received:
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.t.Request]
> (DirectAgent-375:ctx-3500a12b) Seq 1-494866421: Processing: { Ans: , MgmtId:
> 6631563722783, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.StopAnswer":{"platform":"viridian:true;acpi:1;apic:true;pae:true;nx:true","result":false,"details":"Stop
> VM failed","wait":0}}] }
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.t.Request] (Job-Executor-71:ctx-aedce201
> ctx-ee5f8ea3) Seq 1-494866421: Received: { Ans: , MgmtId: 6631563722783,
> via: 1, Ver: v1, Flags: 10, { StopAnswer } }
> 2013-12-14 00:52:18,173 WARN [c.c.v.VirtualMachineManagerImpl]
> (Job-Executor-71:ctx-aedce201 ctx-ee5f8ea3) Unable to stop vm
[jira] [Resolved] (CLOUDSTACK-5495) [Automation] Unable to stop VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharat Kumar resolved CLOUDSTACK-5495.
--
Resolution: Fixed
> [Automation] Unable to stop VM
> --
>
> Key: CLOUDSTACK-5495
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5495
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.3.0
> Environment: XenServer 6.2
> advanced zone
>Reporter: Srikanteswararao Talluri
>Assignee: Bharat Kumar
>Priority: Blocker
> Fix For: 4.3.0
>
> Attachments: newrunmgmt.log.zip, xensource-unabel-to-stop-vm.log
>
>
> Unable to Stop VM - error is hit multiple times during automation run
> Here is the stack trace:
> ===END=== 10.147.38.149 -- GET
> signature=ObNDNvmDCDDBoa%2FJ%2BFOtWBiGH%2BA%3D&apiKey=-neX9tpPuZ8bg04MAmolZWYSQkgjXMRmPNxou5hJcwAUk9Ti3nQj2ii_W4WylGRUwOjo1PW233odZZUX0-1dbg&command=queryAsyncJobResult&response=json&jobid=144b5660-716f-449c-9b52-f18ba738ad28
> 2013-12-14 00:52:18,153 WARN [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-375:ctx-3500a12b) VM destroy failed in Stop i-271-491-QA Command
> due to null
> You gave an invalid object reference. The object may have recently been
> deleted. The class parameter gives the type of reference given, and the
> handle parameter echoes the bad value given.
> at com.xensource.xenapi.Types.checkResponse(Types.java:209)
> at com.xensource.xenapi.Connection.dispatch(Connection.java:368)
> at
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909)
> at com.xensource.xenapi.VM.getPowerState(VM.java:746)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:4168)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:492)
> at
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
> at
> com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-12-14 00:52:18,161 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-375:ctx-3500a12b) 10. The VM i-271-491-QA is in Running state
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-375:ctx-3500a12b) Seq 1-494866421: Response Received:
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.t.Request]
> (DirectAgent-375:ctx-3500a12b) Seq 1-494866421: Processing: { Ans: , MgmtId:
> 6631563722783, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.StopAnswer":{"platform":"viridian:true;acpi:1;apic:true;pae:true;nx:true","result":false,"details":"Stop
> VM failed","wait":0}}] }
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.t.Request] (Job-Executor-71:ctx-aedce201
> ctx-ee5f8ea3) Seq 1-494866421: Received: { Ans: , MgmtId: 6631563722783,
> via: 1, Ver: v1, Flags: 10, { StopAnswer } }
> 2013-12-14 00:52:18,173 WARN [c.c.v.VirtualMachineManagerImpl]
> (Job-Executor-71:ctx-aedce201 ctx-ee5f8ea3) Unable to stop vm
> VM[User|QA-b6e685bf-4ba1-4572-8728-3bfd0106f6d7]
> 2013-12-14 00:52:18,187 DEBUG [c.c.v.d.VMInstanceDaoImpl]
> (Job-Executor-71:ctx-aedce201 ctx-ee5f8ea3) Unable to upda
[jira] [Commented] (CLOUDSTACK-5502) [Automation] createVlanIpRange API failing, if you pass VLAN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13851726#comment-13851726
]
Bharat Kumar commented on CLOUDSTACK-5502:
--
Hi,
I saw the parameter description in the code of 4.2.1 and 4.3, according to it
we need not pass the vlan=untagged.
but since it worked in 4.2.1 may be the description was not updated. will fix
this and update the parameter description.
> [Automation] createVlanIpRange API failing, if you pass VLAN
> -
>
> Key: CLOUDSTACK-5502
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5502
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.3.0
> Environment: KVM Basic Zone with SG
>Reporter: Rayees Namathponnan
>Assignee: Bharat Kumar
>Priority: Blocker
> Fix For: 4.3.0
>
>
> This issue found in KVM basic zone with SG automation run; test cases from
> below suite filed
> integration.component.test_multiple_ip_ranges.
> Steps to reproduce
> Step 1 : Create basic zone with SG
> Step 2 : Crete IP VLAN Range with below command (pass vlan=untagged)
> http://xxx..xxx.xxx:8096/?command=createVlanIpRange&gateway=10.223.251.1&forvirtualnetwork=false&startip=10.223.251.3&podid=0253bcbf-e636-4776-9e8c-216b70d195a2&zoneid=a9912aa8-a231-44d9-a70b-9d53e6db2d27&netmask=255.255.255.192&vlan=untagged
> Result;
> API command failed with error
> { "createvlaniprangeresponse" :
> {"uuidList":[],"errorcode":431,"cserrorcode":4350,"errortext":"Vlan doesn't
> match vlan of the network"} }
> this API command works only, if you are not passing any VLAN
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5585) [Automation]Unable to stop VM reported by HA Worker
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13856261#comment-13856261 ] Bharat Kumar commented on CLOUDSTACK-5585: -- The stopVM command is successful even if the HA worker fails. > [Automation]Unable to stop VM reported by HA Worker > --- > > Key: CLOUDSTACK-5585 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5585 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: Xenserver > advanced >Reporter: Srikanteswararao Talluri >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.3.0 > > > After this fix, > i am hitting 'unable to stop VM' for a different reason. I will open another > bug for this. > 2013-12-18 13:17:50,490 WARN [c.c.v.VirtualMachineManagerImpl] > (HA-Worker-0:ctx-8b1e82fb work-200) Unable to stop vm > VM[User|QA-54b3a865-b499-4b65-9bbf-308b3b7e3209] > 2013-12-18 13:17:50,504 DEBUG [c.c.c.CapacityManagerImpl] > (HA-Worker-0:ctx-8b1e82fb work-200) VM state transitted from :Stopping to > Running with event: OperationFailedvm's original host id: 2 new host id: 2 > host id before state transition: 2 > 2013-12-18 13:17:50,504 ERROR [c.c.h.HighAvailabilityManagerImpl] > (HA-Worker-0:ctx-8b1e82fb work-200) Terminating > HAWork[200-Stop-612-Stopping-Scheduled] > com.cloud.utils.exception.CloudRuntimeException: Unable to stop > VM[User|QA-54b3a865-b499-4b65-9bbf-308b3b7e3209] > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1398) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStop(VirtualMachineManagerImpl.java:1258) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1231) > at > com.cloud.ha.HighAvailabilityManagerImpl.stopVM(HighAvailabilityManagerImpl.java:651) > at > com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.runWithContext(HighAvailabilityManagerImpl.java:844) > at > com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.access$000(HighAvailabilityManagerImpl.java:797) > at > com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread$1.run(HighAvailabilityManagerImpl.java:809) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.run(HighAvailabilityManagerImpl.java:806) > 2013-12-18 13:17:50,587 INFO [c.c.h.x.r.XenServer56Resource] > (DirectAgent-225:ctx-f80fc44c) Catch com.xensource.xenapi.Types$VifInUse: > failed to destory VLAN eth0 on host 06df9c52-24bf-49d0-a4c0-e635214bcf9f due > to Network has active VIFs -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5585) [Automation]Unable to stop VM reported by HA Worker
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-5585. -- Resolution: Fixed > [Automation]Unable to stop VM reported by HA Worker > --- > > Key: CLOUDSTACK-5585 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5585 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: Xenserver > advanced >Reporter: Srikanteswararao Talluri >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.3.0 > > > After this fix, > i am hitting 'unable to stop VM' for a different reason. I will open another > bug for this. > 2013-12-18 13:17:50,490 WARN [c.c.v.VirtualMachineManagerImpl] > (HA-Worker-0:ctx-8b1e82fb work-200) Unable to stop vm > VM[User|QA-54b3a865-b499-4b65-9bbf-308b3b7e3209] > 2013-12-18 13:17:50,504 DEBUG [c.c.c.CapacityManagerImpl] > (HA-Worker-0:ctx-8b1e82fb work-200) VM state transitted from :Stopping to > Running with event: OperationFailedvm's original host id: 2 new host id: 2 > host id before state transition: 2 > 2013-12-18 13:17:50,504 ERROR [c.c.h.HighAvailabilityManagerImpl] > (HA-Worker-0:ctx-8b1e82fb work-200) Terminating > HAWork[200-Stop-612-Stopping-Scheduled] > com.cloud.utils.exception.CloudRuntimeException: Unable to stop > VM[User|QA-54b3a865-b499-4b65-9bbf-308b3b7e3209] > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1398) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStop(VirtualMachineManagerImpl.java:1258) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1231) > at > com.cloud.ha.HighAvailabilityManagerImpl.stopVM(HighAvailabilityManagerImpl.java:651) > at > com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.runWithContext(HighAvailabilityManagerImpl.java:844) > at > com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.access$000(HighAvailabilityManagerImpl.java:797) > at > com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread$1.run(HighAvailabilityManagerImpl.java:809) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.run(HighAvailabilityManagerImpl.java:806) > 2013-12-18 13:17:50,587 INFO [c.c.h.x.r.XenServer56Resource] > (DirectAgent-225:ctx-f80fc44c) Catch com.xensource.xenapi.Types$VifInUse: > failed to destory VLAN eth0 on host 06df9c52-24bf-49d0-a4c0-e635214bcf9f due > to Network has active VIFs -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5472) UI shows incorrect vm statistics if vm deployed with dynamic compute offering
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharat Kumar updated CLOUDSTACK-5472:
-
Status: Ready To Review (was: In Progress)
> UI shows incorrect vm statistics if vm deployed with dynamic compute offering
> --
>
> Key: CLOUDSTACK-5472
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5472
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Reporter: prashant kumar mishra
>Assignee: Bharat Kumar
> Attachments: Logs_db.rar, screenshot-1.jpg
>
>
> Steps to repro
>
> 1-prepare CS setup with xen6.2
> 2-create a dynamic SO d1
> 3-deploy a vm with d1
> 4-check vm statistics in UI
> Actual
>
> vm statistics shows Total cpu=0
> My observation
>
> API response shows cpunumber":0,"cpuspeed":0,"memory":0,"cpuused":"0% which
> is incorrect.
> Details
> ==
> API
> -
> http://10.147.38.177:8080/client/api?command=listVirtualMachines&details=stats&id=352a9b66-4539-4117-9cea-ca9dd5da00fa&response=json&sessionkey=51sujrtdCbNbXHU3LotE2wx6UMk%3D&_=1386828570170
> API Response
> -
> { "listvirtualmachinesresponse" : { "count":1 ,"virtualmachine" : [
> {"id":"352a9b66-4539-4117-9cea-ca9dd5da00fa","name":"last","displayname":"last","account":"admin","domainid":"45b3c110-6261-11e3-87cf-0654483b","domain":"ROOT","created":"2013-12-12T06:24:40-0500","state":"Running","haenable":false,"zoneid":"cb7aee87-73fb-4da4-a384-2e209b132c95","zonename":"z1","hostid":"d46817a4-5e4a-4701-b3ba-188cafcb66db","hostname":"Rack1Pod1Host7","cpunumber":0,"cpuspeed":0,"memory":0,"cpuused":"0%","networkkbsread":1,"networkkbswrite":1,"diskkbsread":0,"diskkbswrite":0,"diskioread":0,"diskiowrite":0,"guestosid":"45d3b830-6261-11e3-87cf-0654483b","securitygroup":[],"nic":[{"id":"0786bc57-2423-4e07-8925-5f6dfac5f962","networkid":"5967fab2-8ca9-415e-b78d-114851a1d072","networkname":"new","netmask":"255.255.255.0","gateway":"10.1.1.1","ipaddress":"10.1.1.144","isolationuri":"vlan://1103","broadcasturi":"vlan://1103","traffictype":"Guest","type":"Isolated","isdefault":true,"macaddress":"02:00:09:23:00:05"}],"hypervisor":"XenServer","instancename":"i-2-13-VM","tags":[],"affinitygroup":[],"displayvm":true,"isdynamicallyscalable":true}
> ] } }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5530) attempt to add secondary storage with the same name is ignored
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-5530. -- Resolution: Fixed > attempt to add secondary storage with the same name is ignored > --- > > Key: CLOUDSTACK-5530 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5530 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: xenserver > advanced zone >Reporter: Srikanteswararao Talluri >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.3.0 > > > 1. create a image store(secondary storage) with name 's'. > 2. Try to add another secondary storage with same name. > API doesn't fail but it ignores the addimagestore command. > DB just shows only one image store: > mysql> select * from image_store; > ++--+-+--+---++---+---+--+--+-+-+++ > | id | name | image_provider_name | protocol | url >| data_center_id | scope | role | uuid > | parent | created | > removed | total_size | used_bytes | > ++--+-+--+---++---+---+--+--+-+-+++ > | 1 | s| NFS | nfs | > nfs://10.147.28.7/export/home/talluri/xen/sec | 1 | ZONE | > Image | a03584ab-5858-437a-99cd-4627ff3d543b | > 423a8ae9-3eed-3dcb-9463-b0866af4c4be | 2013-12-16 17:54:12 | NULL| > NULL | NULL | > ++--+-+--+---++---+---+--+--+-+-+++ > 1 row in set (0.00 sec) > Management server log for second image store addition: > ===START=== 10.252.193.28 -- GET > command=addImageStore&response=json&sessionkey=tFtENjuwRWIixsebaImtLuJhOD4%3D&name=s&provider=NFS&zoneid=9fb59079-b686-47eb-8d58-faabc9e39e60&url=nfs%3A%2F%2F10.147.28.7%2Fexport%2Fhome%2Ftalluri%2Fxen%2Fsecb&_=1387288311423 > 2013-12-18 00:44:42,197 INFO [o.a.c.s.d.l.CloudStackImageStoreLifeCycleImpl] > (catalina-exec-7:ctx-6f9f0b38 ctx-c386ef69) Trying to add a new data store at > nfs://10.147.28.7/export/home/talluri/xen/secb to data center 2 > 2013-12-18 00:44:42,242 DEBUG [c.c.a.ApiServlet] > (catalina-exec-7:ctx-6f9f0b38 ctx-c386ef69) ===END=== 10.252.193.28 -- GET > command=addImageStore&response=json&sessionkey=tFtENjuwRWIixsebaImtLuJhOD4%3D&name=s&provider=NFS&zoneid=9fb59079-b686-47eb-8d58-faabc9e39e60&url=nfs%3A%2F%2F10.147.28.7%2Fexport%2Fhome%2Ftalluri%2Fxen%2Fsecb&_=1387288311423 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5711) allow scaling from the same offering when using custom compute offering.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-5711: - Priority: Critical (was: Major) > allow scaling from the same offering when using custom compute offering. > > > Key: CLOUDSTACK-5711 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5711 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Critical > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-5711) allow scaling from the same offering when using custom compute offering.
Bharat Kumar created CLOUDSTACK-5711: Summary: allow scaling from the same offering when using custom compute offering. Key: CLOUDSTACK-5711 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5711 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Reporter: Bharat Kumar Assignee: Bharat Kumar -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-5750) Make default value of execute.in.sequence.hypervisor.commands false.
Bharat Kumar created CLOUDSTACK-5750: Summary: Make default value of execute.in.sequence.hypervisor.commands false. Key: CLOUDSTACK-5750 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5750 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.3.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5742) #cpu,cpu speed, and ram is getting updated under wrong usage_type(2) for dynamic compute offering in usage_vm_instance table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-5742: - Assignee: Harikrishna Patnala (was: Bharat Kumar) > #cpu,cpu speed, and ram is getting updated under wrong usage_type(2) for > dynamic compute offering in usage_vm_instance table > > > Key: CLOUDSTACK-5742 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5742 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 >Reporter: prashant kumar mishra >Assignee: Harikrishna Patnala >Priority: Critical > Fix For: 4.3.0 > > Attachments: LOG_DB.rar > > > STEPS TO REPO > == > 1-prepare a CS setup 4.3 > 2-deploy a vm with small CO > 3-Change the vm CO to dynamic CO. > 4-check the usage_vm_instance table after cloud_usage db synch > EXPECTED > = > cpu and ram should get updated under usage type 1 > ACTUAL > === > cpu and ram is getting updated under usage type2 > DB > === > | 2 | 1 | 2 | 8 | test| > 12 | 202 | XenServer | 2014-01-03 10:10:15 | NULL > | 100 | 1 |256 | > | 1 | 1 | 2 | 8 | test| > 12 | 202 | XenServer | 2014-01-03 10:11:21 | NULL > | NULL | NULL | NULL | > ++-+++-+-+-+-+-+-+---+---++ -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5750) Make default value of execute.in.sequence.hypervisor.commands false.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13862851#comment-13862851 ] Bharat Kumar commented on CLOUDSTACK-5750: -- As part of the fix to make the execute.in.sequence.hypervisor.commands configurable i set the default value to true. so now this will change it back to false. > Make default value of execute.in.sequence.hypervisor.commands false. > > > Key: CLOUDSTACK-5750 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5750 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.3.0 > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5750) Make default value of execute.in.sequence.hypervisor.commands false.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-5750: - Status: Ready To Review (was: In Progress) > Make default value of execute.in.sequence.hypervisor.commands false. > > > Key: CLOUDSTACK-5750 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5750 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.3.0 > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5472) UI shows incorrect vm statistics if vm deployed with dynamic compute offering
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharat Kumar resolved CLOUDSTACK-5472.
--
Resolution: Fixed
Fix Version/s: 4.3.0
> UI shows incorrect vm statistics if vm deployed with dynamic compute offering
> --
>
> Key: CLOUDSTACK-5472
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5472
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Reporter: prashant kumar mishra
>Assignee: Bharat Kumar
> Fix For: 4.3.0
>
> Attachments: Logs_db.rar, screenshot-1.jpg
>
>
> Steps to repro
>
> 1-prepare CS setup with xen6.2
> 2-create a dynamic SO d1
> 3-deploy a vm with d1
> 4-check vm statistics in UI
> Actual
>
> vm statistics shows Total cpu=0
> My observation
>
> API response shows cpunumber":0,"cpuspeed":0,"memory":0,"cpuused":"0% which
> is incorrect.
> Details
> ==
> API
> -
> http://10.147.38.177:8080/client/api?command=listVirtualMachines&details=stats&id=352a9b66-4539-4117-9cea-ca9dd5da00fa&response=json&sessionkey=51sujrtdCbNbXHU3LotE2wx6UMk%3D&_=1386828570170
> API Response
> -
> { "listvirtualmachinesresponse" : { "count":1 ,"virtualmachine" : [
> {"id":"352a9b66-4539-4117-9cea-ca9dd5da00fa","name":"last","displayname":"last","account":"admin","domainid":"45b3c110-6261-11e3-87cf-0654483b","domain":"ROOT","created":"2013-12-12T06:24:40-0500","state":"Running","haenable":false,"zoneid":"cb7aee87-73fb-4da4-a384-2e209b132c95","zonename":"z1","hostid":"d46817a4-5e4a-4701-b3ba-188cafcb66db","hostname":"Rack1Pod1Host7","cpunumber":0,"cpuspeed":0,"memory":0,"cpuused":"0%","networkkbsread":1,"networkkbswrite":1,"diskkbsread":0,"diskkbswrite":0,"diskioread":0,"diskiowrite":0,"guestosid":"45d3b830-6261-11e3-87cf-0654483b","securitygroup":[],"nic":[{"id":"0786bc57-2423-4e07-8925-5f6dfac5f962","networkid":"5967fab2-8ca9-415e-b78d-114851a1d072","networkname":"new","netmask":"255.255.255.0","gateway":"10.1.1.1","ipaddress":"10.1.1.144","isolationuri":"vlan://1103","broadcasturi":"vlan://1103","traffictype":"Guest","type":"Isolated","isdefault":true,"macaddress":"02:00:09:23:00:05"}],"hypervisor":"XenServer","instancename":"i-2-13-VM","tags":[],"affinitygroup":[],"displayvm":true,"isdynamicallyscalable":true}
> ] } }
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5750) Make default value of execute.in.sequence.hypervisor.commands false.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-5750. -- Resolution: Fixed > Make default value of execute.in.sequence.hypervisor.commands false. > > > Key: CLOUDSTACK-5750 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5750 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.3.0 > > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5706) Multiple NPEs when host is put in maintenance after upgrading from 4.2.1 to 4.3
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharat Kumar updated CLOUDSTACK-5706:
-
Assignee: (was: Bharat Kumar)
> Multiple NPEs when host is put in maintenance after upgrading from 4.2.1 to
> 4.3
> ---
>
> Key: CLOUDSTACK-5706
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5706
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Upgrade
>Affects Versions: 4.3.0
> Environment: upgraded the CS from 4.2.1 to 4.3
>Reporter: manasaveloori
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: management-server.rar, management-server.rar
>
>
> Steps:
> 1.Deployed CS 4.2.1 GA build with ESXi5.1(using Vsphere 5.1 client)
> 2.Deployed some VMs.
> 3.Upgraded the CS to 4.3.
> 4. Put the host into maintenance which will be successful.
> Observed the following NPEs in MSlogs.
> 2014-01-01 20:17:11,749 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-15:ctx-e389 ctx-1ab4f80c) ===END=== 10.252.192.34 -- GET
> command=prepareHostForMaintenance&id=dbd66102-e51e-4014-be75-e7ac8ccb81f1&response=json&sessionkey=ble18kT0VfY%2BEPq8V8DzAZsM8L0%3D&_=1388568267594
> 2014-01-01 20:17:11,752 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (Job-Executor-118:ctx-e4cb1a1d) Add job-166 into job monitoring
> 2014-01-01 20:17:11,752 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (Job-Executor-118:ctx-e4cb1a1d) Executing AsyncJobVO {id:166, userId: 2,
> accountId: 2, instanceType: Host, instanceId: 4, cmd:
> org.apache.cloudstack.api.command.admin.host.PrepareForMaintenanceCmd,
> cmdInfo:
> {"response":"json","id":"dbd66102-e51e-4014-be75-e7ac8ccb81f1","sessionkey":"ble18kT0VfY+EPq8V8DzAZsM8L0\u003d","cmdEventType":"MAINT.PREPARE","ctxUserId":"2","httpmethod":"GET","_":"1388568267594","ctxAccountId":"2","ctxStartEventId":"758"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 6758231703598, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-01-01 20:17:11,782 DEBUG [c.c.a.t.Request]
> (Job-Executor-118:ctx-e4cb1a1d ctx-1ab4f80c) Seq 4-1399914503: Sending { Cmd
> , MgmtId: 6758231703598, via: 4(10.147.40.28), Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.MaintainCommand":{"wait":0}}] }
> 2014-01-01 20:17:11,782 DEBUG [c.c.a.t.Request]
> (Job-Executor-118:ctx-e4cb1a1d ctx-1ab4f80c) Seq 4-1399914503: Executing: {
> Cmd , MgmtId: 6758231703598, via: 4(10.147.40.28), Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.MaintainCommand":{"wait":0}}] }
> 2014-01-01 20:17:11,806 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-410:ctx-32cc846b) Seq 4-1399914503: Executing request
> 2014-01-01 20:17:11,807 INFO [c.c.h.v.r.VmwareResource]
> (DirectAgent-410:ctx-32cc846b 10.147.40.28) Executing resource
> MaintainCommand: {"wait":0}
> 2014-01-01 20:17:11,814 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-410:ctx-32cc846b) Seq 4-1399914503: Response Received:
> 2014-01-01 20:17:11,814 DEBUG [c.c.a.t.Request]
> (DirectAgent-410:ctx-32cc846b) Seq 4-1399914503: Processing: { Ans: ,
> MgmtId: 6758231703598, via: 4, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.MaintainAnswer":{"willMigrate":true,"result":true,"details":"Put
> host in maintaince","wait":0}}] }
> 2014-01-01 20:17:11,815 DEBUG [c.c.a.t.Request]
> (Job-Executor-118:ctx-e4cb1a1d ctx-1ab4f80c) Seq 4-1399914503: Received: {
> Ans: , MgmtId: 6758231703598, via: 4, Ver: v1, Flags: 110, { MaintainAnswer }
> }
> 2014-01-01 20:17:11,815 DEBUG [c.c.a.m.AgentManagerImpl]
> (Job-Executor-118:ctx-e4cb1a1d ctx-1ab4f80c) Details from executing class
> com.cloud.agent.api.MaintainCommand: Put host in maintaince
> 2014-01-01 20:17:11,817 DEBUG [c.c.a.m.AgentAttache]
> (DirectAgent-410:ctx-32cc846b) Seq 4-1399914503: No more commands found
> 2014-01-01 20:17:11,834 DEBUG [c.c.r.ResourceState]
> (Job-Executor-118:ctx-e4cb1a1d ctx-1ab4f80c) Resource state update: [id = 4;
> name = 10.147.40.28; old state = Enabled; event = AdminAskMaintenace; new
> state = PrepareForMaintenance]
> 2014-01-01 20:17:11,834 DEBUG [c.c.a.m.AgentAttache]
> (Job-Executor-118:ctx-e4cb1a1d ctx-1ab4f80c) Seq 4-1399914499: Sending
> disconnect to class com.cloud.network.security.SecurityGroupListener
> 2014-01-01 20:17:11,888 DEBUG [c.c.h.HighAvailabilityManagerImpl]
> (Job-Executor-118:ctx-e4cb1a1d ctx-1ab4f80c) Scheduled
> HAWork[44-ForceStop-9-Running-Scheduled]
> 2014-01-01 20:17:11,910 INFO [c.c.h.HighAvailabilityManagerImpl]
> (HA-Worker-0:ctx-07bb080c work-44) Processing
> HAWork[44-ForceStop-9-Running-Scheduled]
> 2014-01-01 20:17:11,917 INFO [c.c.h.HighAvailabilityManagerImpl]
[jira] [Resolved] (CLOUDSTACK-5579) description of "execute.in.sequence.hypervisor.commands" need to be updated in global config
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-5579. -- Resolution: Fixed Assignee: Bharat Kumar > description of "execute.in.sequence.hypervisor.commands" need to be updated > in global config > > > Key: CLOUDSTACK-5579 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5579 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 >Reporter: Rayees Namathponnan >Assignee: Bharat Kumar > Fix For: 4.3.0 > > > 1) Install management server > 2) Open global config > 3) search for "execute.in.sequence.hypervisor.commands" > 4) Check description > Expected result > If set to true, StartCommand, StopCommand, CopyCommand, MigrateCommand will > be synchronized on the agent side. If set to false, these commands become > asynchronous. Default value is false. > Actual result > If set to true, StartCommand, StopCommand, CopyCommand, MigrateCommand will > be synchronized on the agent side. If set to false, these commands become > asynchronous. Default value is true. > We need to update description with default value is false -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5742) #cpu,cpu speed, and ram is getting updated under wrong usage_type(2) for dynamic compute offering in usage_vm_instance table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-5742: - Status: Ready To Review (was: In Progress) > #cpu,cpu speed, and ram is getting updated under wrong usage_type(2) for > dynamic compute offering in usage_vm_instance table > > > Key: CLOUDSTACK-5742 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5742 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 >Reporter: prashant kumar mishra >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.3.0 > > Attachments: LOG_DB.rar > > > STEPS TO REPO > == > 1-prepare a CS setup 4.3 > 2-deploy a vm with small CO > 3-Change the vm CO to dynamic CO. > 4-check the usage_vm_instance table after cloud_usage db synch > EXPECTED > = > cpu and ram should get updated under usage type 1 > ACTUAL > === > cpu and ram is getting updated under usage type2 > DB > === > | 2 | 1 | 2 | 8 | test| > 12 | 202 | XenServer | 2014-01-03 10:10:15 | NULL > | 100 | 1 |256 | > | 1 | 1 | 2 | 8 | test| > 12 | 202 | XenServer | 2014-01-03 10:11:21 | NULL > | NULL | NULL | NULL | > ++-+++-+-+-+-+-+-+---+---++ -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (CLOUDSTACK-5651) deployVm: customparameters param name has to be changed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13865392#comment-13865392 ] Bharat Kumar edited comment on CLOUDSTACK-5651 at 1/8/14 1:06 PM: -- Hi, The customParameter name is used to indicate that it should be passed when using customised values for some parameters of a vm. This is not metadata. as of now we use this to pass custom values of cpu, memory and cup cores. However to be consistent with the other APIs we are changing this name to details. which is vague as detail can be anything that is related to a vm generally metadata. Also we populate these details in the response. was (Author: bharat.kumar): Hi, The customParameter name is used to indicate that it should be passed when using customised values for some parameters of a vm. This is not metadata. as of now we use this to pass custom values of cpu, memory and cup cores. However to be consistent with the other APIs we are changing this name to details. which is vague as detail which can be anything that is related to a vm. Also we populate these details in the response. > deployVm: customparameters param name has to be changed > --- > > Key: CLOUDSTACK-5651 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5651 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 >Reporter: Alena Prokharchyk >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.3.0 > > > deployVm API got a new param in 4.3 -“customparameters”. The description of > the parameter is very vague and generic “used to specify the custom > parameters”. > Is it just the metadata in form of value/key pairs? If so, please change the > name to “details” - the generic name used when specify key/value metadata in > other API commands. > Also you need to save this information in the “user_vm_details” table, and > return it in the UserVmResponse, “details” map parameter. I don’t see “custom > parameters” key map being returned anywhere in the UserVmResponse. Its very > confusing, because whatever is passed to the Create/Update call, should be > returned in the response as well. > It all has to be fixed in 4.3 branch. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5651) deployVm: customparameters param name has to be changed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13865392#comment-13865392 ] Bharat Kumar commented on CLOUDSTACK-5651: -- Hi, The customParameter name is used to indicate that it should be passed when using customised values for some parameters of a vm. This is not metadata. as of now we use this to pass custom values of cpu, memory and cup cores. However to be consistent with the other APIs we are changing this name to details. which is vague as detail which can be anything that is related to a vm. Also we populate these details in the response. > deployVm: customparameters param name has to be changed > --- > > Key: CLOUDSTACK-5651 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5651 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 >Reporter: Alena Prokharchyk >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.3.0 > > > deployVm API got a new param in 4.3 -“customparameters”. The description of > the parameter is very vague and generic “used to specify the custom > parameters”. > Is it just the metadata in form of value/key pairs? If so, please change the > name to “details” - the generic name used when specify key/value metadata in > other API commands. > Also you need to save this information in the “user_vm_details” table, and > return it in the UserVmResponse, “details” map parameter. I don’t see “custom > parameters” key map being returned anywhere in the UserVmResponse. Its very > confusing, because whatever is passed to the Create/Update call, should be > returned in the response as well. > It all has to be fixed in 4.3 branch. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5651) deployVm: customparameters param name has to be changed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-5651: - Status: Ready To Review (was: In Progress) > deployVm: customparameters param name has to be changed > --- > > Key: CLOUDSTACK-5651 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5651 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 >Reporter: Alena Prokharchyk >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.3.0 > > > deployVm API got a new param in 4.3 -“customparameters”. The description of > the parameter is very vague and generic “used to specify the custom > parameters”. > Is it just the metadata in form of value/key pairs? If so, please change the > name to “details” - the generic name used when specify key/value metadata in > other API commands. > Also you need to save this information in the “user_vm_details” table, and > return it in the UserVmResponse, “details” map parameter. I don’t see “custom > parameters” key map being returned anywhere in the UserVmResponse. Its very > confusing, because whatever is passed to the Create/Update call, should be > returned in the response as well. > It all has to be fixed in 4.3 branch. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-1695) Not enough cpu avialable in cluster according to new overcommit ratio but all stopped Vms can be started without any failure(required cpu for stopped vm is > > ava
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13727371#comment-13727371 ] Bharat Kumar commented on CLOUDSTACK-1695: -- The vms should be deployed only after the capacity recalculate to obey the constraints. if the VMs are deployed before the capacity calculation occurs the VM deployment will not fail untill there is capacity on the host. however once the capacity calculation is done the dash board will show that the usage is greater than 100% This is the behavior when the overcommit is changed dynamically. > Not enough cpu avialable in cluster according to new overcommit ratio but all > stopped Vms can be started without any failure(required cpu for stopped vm is > > > available cpu ) > --- > > Key: CLOUDSTACK-1695 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1695 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 > Environment: XEN,KVM Branch Master >Reporter: prashant kumar mishra >Assignee: Bharat Kumar > Fix For: 4.2.0 > > Attachments: DB_logs.rar, Logs_Db1245.rar, screenshot-1.jpg, > screenshot-2.jpg > > > After Stop/Destroy , vms can be successfully start/Restore-start only when > enough resources are available based on current overcommit ratio, . > Step to Reproduce > - > 1-Set cpu overcommit ratio to 4 > 2-Deploy vms such that no cpu left in cluster > 3-change overcommit ratio to 1 > 4-Stop/Destroy all the vms > 5-Start/restore-start all vms > Expected Result > - > only few vms should come up ,since there is less resource(overcommit > ratio=1) available than before (when overcommit ratio was 4) > Actual > > All vm stopped/Destroyed in step 4 came up without any failure -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-3753) Multiple VLAN range API need to accept a list rather than "add" or "remove" per command
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar reassigned CLOUDSTACK-3753: Assignee: Bharat Kumar > Multiple VLAN range API need to accept a list rather than "add" or "remove" > per command > --- > > Key: CLOUDSTACK-3753 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3753 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 >Reporter: Sheng Yang >Assignee: Bharat Kumar >Priority: Blocker > Fix For: 4.2.0 > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Non+contiguous+vlan+ranges > "vlan parameter will add a new vlan range to the existing vlan range (new > behavior). if the new vlan range overlaps the existing vlan range it will > extend that vlan (This is the existing behavior.). > removevlan parameter will remove the mentioned vlan. The removevlan and vlan > parameters can be used together. If the vlan range we are trying to remove is > in use, the operation will not succeed." > I haven't seen such API in the CloudStack. It's much more clean to use a list > here(even for ranges, can be extended from one element, like "1-2, 4-5, > 6-7"), rather than newly defined "vlan"/"removevlan" behavior. It broke API > compatibility(e.g. the previous API potentially able to change vlan directly, > rather than add it), and is also user unfriendly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-3753) Multiple VLAN range API need to accept a list rather than "add" or "remove" per command
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-3753. -- Resolution: Fixed > Multiple VLAN range API need to accept a list rather than "add" or "remove" > per command > --- > > Key: CLOUDSTACK-3753 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3753 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 >Reporter: Sheng Yang >Assignee: Bharat Kumar >Priority: Blocker > Fix For: 4.2.0 > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Non+contiguous+vlan+ranges > "vlan parameter will add a new vlan range to the existing vlan range (new > behavior). if the new vlan range overlaps the existing vlan range it will > extend that vlan (This is the existing behavior.). > removevlan parameter will remove the mentioned vlan. The removevlan and vlan > parameters can be used together. If the vlan range we are trying to remove is > in use, the operation will not succeed." > I haven't seen such API in the CloudStack. It's much more clean to use a list > here(even for ranges, can be extended from one element, like "1-2, 4-5, > 6-7"), rather than newly defined "vlan"/"removevlan" behavior. It broke API > compatibility(e.g. the previous API potentially able to change vlan directly, > rather than add it), and is also user unfriendly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-3836) 3.0.6 to ASF 4.2 Upgrade: "cloud" Database Schema Inconsistencies on the Upgraded Setup - Table "volumes"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13727609#comment-13727609 ] Bharat Kumar commented on CLOUDSTACK-3836: -- commit 60585b51819e4391373d71c63138e36f0a3c5898 in master. > 3.0.6 to ASF 4.2 Upgrade: "cloud" Database Schema Inconsistencies on the > Upgraded Setup - Table "volumes" > - > > Key: CLOUDSTACK-3836 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3836 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.2.0 >Reporter: Chandan Purushothama >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.2.0 > > > Table 8: volumes > On ASF 4.2 Setup: > no iso_id column > On the 4.2 Upgraded Setup: > `iso_id` bigint(20) UNSIGNED DEFAULT NULL, -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-3836) 3.0.6 to ASF 4.2 Upgrade: "cloud" Database Schema Inconsistencies on the Upgraded Setup - Table "volumes"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-3836. -- Resolution: Fixed commit 65370f31bcb1ae5238be5e68462ea0d79df3296f in master. > 3.0.6 to ASF 4.2 Upgrade: "cloud" Database Schema Inconsistencies on the > Upgraded Setup - Table "volumes" > - > > Key: CLOUDSTACK-3836 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3836 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.2.0 >Reporter: Chandan Purushothama >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.2.0 > > > Table 8: volumes > On ASF 4.2 Setup: > no iso_id column > On the 4.2 Upgraded Setup: > `iso_id` bigint(20) UNSIGNED DEFAULT NULL, -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CLOUDSTACK-3836) 3.0.6 to ASF 4.2 Upgrade: "cloud" Database Schema Inconsistencies on the Upgraded Setup - Table "volumes"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13727609#comment-13727609 ] Bharat Kumar edited comment on CLOUDSTACK-3836 at 8/2/13 11:58 AM: --- commit 60585b51819e4391373d71c63138e36f0a3c5898 in 4.2 was (Author: bharat.kumar): commit 60585b51819e4391373d71c63138e36f0a3c5898 in master. > 3.0.6 to ASF 4.2 Upgrade: "cloud" Database Schema Inconsistencies on the > Upgraded Setup - Table "volumes" > - > > Key: CLOUDSTACK-3836 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3836 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.2.0 >Reporter: Chandan Purushothama >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.2.0 > > > Table 8: volumes > On ASF 4.2 Setup: > no iso_id column > On the 4.2 Upgraded Setup: > `iso_id` bigint(20) UNSIGNED DEFAULT NULL, -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-3612) 3.0.6 to ASF 4.2 Upgrade: Database Schema Inconsistencies on the Upgraded Setup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13727610#comment-13727610 ] Bharat Kumar commented on CLOUDSTACK-3612: -- fixed the iso_id inconsistency. closing the bug. > 3.0.6 to ASF 4.2 Upgrade: Database Schema Inconsistencies on the Upgraded > Setup > --- > > Key: CLOUDSTACK-3612 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3612 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.2.0 >Reporter: Chandan Purushothama >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.2.0 > > > Table 1: baremetal_dhcp_devices > On ASF 4.2 Setup: > `nsp_id` bigint(20) UNSIGNED DEFAULT NULL, > `pod_id` bigint(20) UNSIGNED DEFAULT NULL, > `device_type` varchar(255) DEFAULT NULL, > `physical_network_id` bigint(20) UNSIGNED DEFAULT NULL, > `host_id` bigint(20) UNSIGNED DEFAULT NULL, > On the 4.2 Upgraded Setup: > `nsp_id` bigint(20) UNSIGNED NOT NULL, > `pod_id` bigint(20) UNSIGNED NOT NULL, > `device_type` varchar(255) NOT NULL, > `physical_network_id` bigint(20) UNSIGNED NOT NULL, > `host_id` bigint(20) UNSIGNED NOT NULL, > Table 2: baremetal_pxe_devices > On ASF 4.2 Setup: > `nsp_id` bigint(20) UNSIGNED DEFAULT NULL, > `device_type` varchar(255) DEFAULT NULL, > `physical_network_id` bigint(20) UNSIGNED DEFAULT NULL, > `host_id` bigint(20) UNSIGNED DEFAULT NULL, > On the 4.2 Upgraded Setup: > `nsp_id` bigint(20) UNSIGNED NOT NULL, > `device_type` varchar(255) NOT NULL, > `physical_network_id` bigint(20) UNSIGNED NOT NULL, > `host_id` bigint(20) UNSIGNED NOT NULL, > Table 3: netscaler_pod_ref > On ASF 4.2 Setup: > Present on the Setup > Missing on the Upgraded Setup. > Table 4: nicira_nvp_nic_map > On ASF 4.2 Setup: > Constraint: > ALTER TABLE `cloud`.`nicira_nvp_nic_map` ADD CONSTRAINT > `fk_nicira_nvp_nic_map__nic` > FOREIGN KEY ( `nic` ) REFERENCES `nics` ( `uuid` ) ON DELETE CASCADE; > On the 4.2 Upgraded Setup: > No such constraint > Table 5: router_network_ref > On ASF 4.2 Setup: > Constraint: > ALTER TABLE `cloud`.`router_network_ref` ADD CONSTRAINT > `fk_router_network_ref__router_id` > FOREIGN KEY ( `router_id` ) REFERENCES `domain_router` ( `id` ) ON DELETE > CASCADE; > On the 4.2 Upgraded Setup: > No such constraint > Table 6: sync_queue > On ASF 4.2 Setup: > `queue_size` smallint(6) NOT NULL DEFAULT '0', > `queue_size_limit` smallint(6) NOT NULL DEFAULT '1', > On the 4.2 Upgraded Setup: > `queue_size` smallint(6) DEFAULT '0', > `queue_size_limit` smallint(6) DEFAULT '1', > Table 7: usage_event > On ASF 4.2 Setup: > no virtual_size column > On the 4.2 Upgraded Setup: > `virtual_size` bigint(20) UNSIGNED DEFAULT NULL, > Table 8: volumes > On ASF 4.2 Setup: > no iso_id column > On the 4.2 Upgraded Setup: > `iso_id` bigint(20) UNSIGNED DEFAULT NULL, -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-3612) 3.0.6 to ASF 4.2 Upgrade: Database Schema Inconsistencies on the Upgraded Setup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-3612. -- Resolution: Fixed > 3.0.6 to ASF 4.2 Upgrade: Database Schema Inconsistencies on the Upgraded > Setup > --- > > Key: CLOUDSTACK-3612 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3612 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.2.0 >Reporter: Chandan Purushothama >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.2.0 > > > Table 1: baremetal_dhcp_devices > On ASF 4.2 Setup: > `nsp_id` bigint(20) UNSIGNED DEFAULT NULL, > `pod_id` bigint(20) UNSIGNED DEFAULT NULL, > `device_type` varchar(255) DEFAULT NULL, > `physical_network_id` bigint(20) UNSIGNED DEFAULT NULL, > `host_id` bigint(20) UNSIGNED DEFAULT NULL, > On the 4.2 Upgraded Setup: > `nsp_id` bigint(20) UNSIGNED NOT NULL, > `pod_id` bigint(20) UNSIGNED NOT NULL, > `device_type` varchar(255) NOT NULL, > `physical_network_id` bigint(20) UNSIGNED NOT NULL, > `host_id` bigint(20) UNSIGNED NOT NULL, > Table 2: baremetal_pxe_devices > On ASF 4.2 Setup: > `nsp_id` bigint(20) UNSIGNED DEFAULT NULL, > `device_type` varchar(255) DEFAULT NULL, > `physical_network_id` bigint(20) UNSIGNED DEFAULT NULL, > `host_id` bigint(20) UNSIGNED DEFAULT NULL, > On the 4.2 Upgraded Setup: > `nsp_id` bigint(20) UNSIGNED NOT NULL, > `device_type` varchar(255) NOT NULL, > `physical_network_id` bigint(20) UNSIGNED NOT NULL, > `host_id` bigint(20) UNSIGNED NOT NULL, > Table 3: netscaler_pod_ref > On ASF 4.2 Setup: > Present on the Setup > Missing on the Upgraded Setup. > Table 4: nicira_nvp_nic_map > On ASF 4.2 Setup: > Constraint: > ALTER TABLE `cloud`.`nicira_nvp_nic_map` ADD CONSTRAINT > `fk_nicira_nvp_nic_map__nic` > FOREIGN KEY ( `nic` ) REFERENCES `nics` ( `uuid` ) ON DELETE CASCADE; > On the 4.2 Upgraded Setup: > No such constraint > Table 5: router_network_ref > On ASF 4.2 Setup: > Constraint: > ALTER TABLE `cloud`.`router_network_ref` ADD CONSTRAINT > `fk_router_network_ref__router_id` > FOREIGN KEY ( `router_id` ) REFERENCES `domain_router` ( `id` ) ON DELETE > CASCADE; > On the 4.2 Upgraded Setup: > No such constraint > Table 6: sync_queue > On ASF 4.2 Setup: > `queue_size` smallint(6) NOT NULL DEFAULT '0', > `queue_size_limit` smallint(6) NOT NULL DEFAULT '1', > On the 4.2 Upgraded Setup: > `queue_size` smallint(6) DEFAULT '0', > `queue_size_limit` smallint(6) DEFAULT '1', > Table 7: usage_event > On ASF 4.2 Setup: > no virtual_size column > On the 4.2 Upgraded Setup: > `virtual_size` bigint(20) UNSIGNED DEFAULT NULL, > Table 8: volumes > On ASF 4.2 Setup: > no iso_id column > On the 4.2 Upgraded Setup: > `iso_id` bigint(20) UNSIGNED DEFAULT NULL, -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-3612) 3.0.6 to ASF 4.2 Upgrade: Database Schema Inconsistencies on the Upgraded Setup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar closed CLOUDSTACK-3612. Resolution: Fixed 60585b51819e4391373d71c63138e36f0a3c5898 in 4.2 > 3.0.6 to ASF 4.2 Upgrade: Database Schema Inconsistencies on the Upgraded > Setup > --- > > Key: CLOUDSTACK-3612 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3612 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.2.0 >Reporter: Chandan Purushothama >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.2.0 > > > Table 1: baremetal_dhcp_devices > On ASF 4.2 Setup: > `nsp_id` bigint(20) UNSIGNED DEFAULT NULL, > `pod_id` bigint(20) UNSIGNED DEFAULT NULL, > `device_type` varchar(255) DEFAULT NULL, > `physical_network_id` bigint(20) UNSIGNED DEFAULT NULL, > `host_id` bigint(20) UNSIGNED DEFAULT NULL, > On the 4.2 Upgraded Setup: > `nsp_id` bigint(20) UNSIGNED NOT NULL, > `pod_id` bigint(20) UNSIGNED NOT NULL, > `device_type` varchar(255) NOT NULL, > `physical_network_id` bigint(20) UNSIGNED NOT NULL, > `host_id` bigint(20) UNSIGNED NOT NULL, > Table 2: baremetal_pxe_devices > On ASF 4.2 Setup: > `nsp_id` bigint(20) UNSIGNED DEFAULT NULL, > `device_type` varchar(255) DEFAULT NULL, > `physical_network_id` bigint(20) UNSIGNED DEFAULT NULL, > `host_id` bigint(20) UNSIGNED DEFAULT NULL, > On the 4.2 Upgraded Setup: > `nsp_id` bigint(20) UNSIGNED NOT NULL, > `device_type` varchar(255) NOT NULL, > `physical_network_id` bigint(20) UNSIGNED NOT NULL, > `host_id` bigint(20) UNSIGNED NOT NULL, > Table 3: netscaler_pod_ref > On ASF 4.2 Setup: > Present on the Setup > Missing on the Upgraded Setup. > Table 4: nicira_nvp_nic_map > On ASF 4.2 Setup: > Constraint: > ALTER TABLE `cloud`.`nicira_nvp_nic_map` ADD CONSTRAINT > `fk_nicira_nvp_nic_map__nic` > FOREIGN KEY ( `nic` ) REFERENCES `nics` ( `uuid` ) ON DELETE CASCADE; > On the 4.2 Upgraded Setup: > No such constraint > Table 5: router_network_ref > On ASF 4.2 Setup: > Constraint: > ALTER TABLE `cloud`.`router_network_ref` ADD CONSTRAINT > `fk_router_network_ref__router_id` > FOREIGN KEY ( `router_id` ) REFERENCES `domain_router` ( `id` ) ON DELETE > CASCADE; > On the 4.2 Upgraded Setup: > No such constraint > Table 6: sync_queue > On ASF 4.2 Setup: > `queue_size` smallint(6) NOT NULL DEFAULT '0', > `queue_size_limit` smallint(6) NOT NULL DEFAULT '1', > On the 4.2 Upgraded Setup: > `queue_size` smallint(6) DEFAULT '0', > `queue_size_limit` smallint(6) DEFAULT '1', > Table 7: usage_event > On ASF 4.2 Setup: > no virtual_size column > On the 4.2 Upgraded Setup: > `virtual_size` bigint(20) UNSIGNED DEFAULT NULL, > Table 8: volumes > On ASF 4.2 Setup: > no iso_id column > On the 4.2 Upgraded Setup: > `iso_id` bigint(20) UNSIGNED DEFAULT NULL, -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CLOUDSTACK-3612) 3.0.6 to ASF 4.2 Upgrade: Database Schema Inconsistencies on the Upgraded Setup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar reopened CLOUDSTACK-3612: -- > 3.0.6 to ASF 4.2 Upgrade: Database Schema Inconsistencies on the Upgraded > Setup > --- > > Key: CLOUDSTACK-3612 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3612 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.2.0 >Reporter: Chandan Purushothama >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.2.0 > > > Table 1: baremetal_dhcp_devices > On ASF 4.2 Setup: > `nsp_id` bigint(20) UNSIGNED DEFAULT NULL, > `pod_id` bigint(20) UNSIGNED DEFAULT NULL, > `device_type` varchar(255) DEFAULT NULL, > `physical_network_id` bigint(20) UNSIGNED DEFAULT NULL, > `host_id` bigint(20) UNSIGNED DEFAULT NULL, > On the 4.2 Upgraded Setup: > `nsp_id` bigint(20) UNSIGNED NOT NULL, > `pod_id` bigint(20) UNSIGNED NOT NULL, > `device_type` varchar(255) NOT NULL, > `physical_network_id` bigint(20) UNSIGNED NOT NULL, > `host_id` bigint(20) UNSIGNED NOT NULL, > Table 2: baremetal_pxe_devices > On ASF 4.2 Setup: > `nsp_id` bigint(20) UNSIGNED DEFAULT NULL, > `device_type` varchar(255) DEFAULT NULL, > `physical_network_id` bigint(20) UNSIGNED DEFAULT NULL, > `host_id` bigint(20) UNSIGNED DEFAULT NULL, > On the 4.2 Upgraded Setup: > `nsp_id` bigint(20) UNSIGNED NOT NULL, > `device_type` varchar(255) NOT NULL, > `physical_network_id` bigint(20) UNSIGNED NOT NULL, > `host_id` bigint(20) UNSIGNED NOT NULL, > Table 3: netscaler_pod_ref > On ASF 4.2 Setup: > Present on the Setup > Missing on the Upgraded Setup. > Table 4: nicira_nvp_nic_map > On ASF 4.2 Setup: > Constraint: > ALTER TABLE `cloud`.`nicira_nvp_nic_map` ADD CONSTRAINT > `fk_nicira_nvp_nic_map__nic` > FOREIGN KEY ( `nic` ) REFERENCES `nics` ( `uuid` ) ON DELETE CASCADE; > On the 4.2 Upgraded Setup: > No such constraint > Table 5: router_network_ref > On ASF 4.2 Setup: > Constraint: > ALTER TABLE `cloud`.`router_network_ref` ADD CONSTRAINT > `fk_router_network_ref__router_id` > FOREIGN KEY ( `router_id` ) REFERENCES `domain_router` ( `id` ) ON DELETE > CASCADE; > On the 4.2 Upgraded Setup: > No such constraint > Table 6: sync_queue > On ASF 4.2 Setup: > `queue_size` smallint(6) NOT NULL DEFAULT '0', > `queue_size_limit` smallint(6) NOT NULL DEFAULT '1', > On the 4.2 Upgraded Setup: > `queue_size` smallint(6) DEFAULT '0', > `queue_size_limit` smallint(6) DEFAULT '1', > Table 7: usage_event > On ASF 4.2 Setup: > no virtual_size column > On the 4.2 Upgraded Setup: > `virtual_size` bigint(20) UNSIGNED DEFAULT NULL, > Table 8: volumes > On ASF 4.2 Setup: > no iso_id column > On the 4.2 Upgraded Setup: > `iso_id` bigint(20) UNSIGNED DEFAULT NULL, -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-1695) Not enough cpu avialable in cluster according to new overcommit ratio but all stopped Vms can be started without any failure(required cpu for stopped vm is > > avai
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-1695. -- Resolution: Fixed 0951739e32fa6e2c9cee1bd1bca2817c2536ef50 hash in 4.2 80e2934bb72f3c660384913d54f13a8d2688fb5d hash in master. > Not enough cpu avialable in cluster according to new overcommit ratio but all > stopped Vms can be started without any failure(required cpu for stopped vm is > > > available cpu ) > --- > > Key: CLOUDSTACK-1695 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1695 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 > Environment: XEN,KVM Branch Master >Reporter: prashant kumar mishra >Assignee: Bharat Kumar > Fix For: 4.2.0 > > Attachments: DB_logs.rar, Logs_Db1245.rar, screenshot-1.jpg, > screenshot-2.jpg > > > After Stop/Destroy , vms can be successfully start/Restore-start only when > enough resources are available based on current overcommit ratio, . > Step to Reproduce > - > 1-Set cpu overcommit ratio to 4 > 2-Deploy vms such that no cpu left in cluster > 3-change overcommit ratio to 1 > 4-Stop/Destroy all the vms > 5-Start/restore-start all vms > Expected Result > - > only few vms should come up ,since there is less resource(overcommit > ratio=1) available than before (when overcommit ratio was 4) > Actual > > All vm stopped/Destroyed in step 4 came up without any failure -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-3763) [Automation] Fix the test_non_contiguous.py test case that tests addition/removal of non-contiguous VLANs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-3763. -- Resolution: Fixed 6e83a54ffbf69e46a79fbaf0be63e63092385b65 commit in 4.2 > [Automation] Fix the test_non_contiguous.py test case that tests > addition/removal of non-contiguous VLANs > - > > Key: CLOUDSTACK-3763 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3763 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.2.0 >Reporter: Prasanna Santhanam > Fix For: 4.2.0 > > > After the fix in the design and change of API behaviour, fix the smoke test > as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-3763) [Automation] Fix the test_non_contiguous.py test case that tests addition/removal of non-contiguous VLANs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13729114#comment-13729114 ] Bharat Kumar commented on CLOUDSTACK-3763: -- 6e83a54ffbf69e46a79fbaf0be63e63092385b65 commit in 4.2 > [Automation] Fix the test_non_contiguous.py test case that tests > addition/removal of non-contiguous VLANs > - > > Key: CLOUDSTACK-3763 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3763 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.2.0 >Reporter: Prasanna Santhanam >Assignee: Bharat Kumar > Fix For: 4.2.0 > > > After the fix in the design and change of API behaviour, fix the smoke test > as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-3763) [Automation] Fix the test_non_contiguous.py test case that tests addition/removal of non-contiguous VLANs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-3763: - Assignee: Bharat Kumar > [Automation] Fix the test_non_contiguous.py test case that tests > addition/removal of non-contiguous VLANs > - > > Key: CLOUDSTACK-3763 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3763 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.2.0 >Reporter: Prasanna Santhanam >Assignee: Bharat Kumar > Fix For: 4.2.0 > > > After the fix in the design and change of API behaviour, fix the smoke test > as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-3370) Add ipalias deletion to the network gc
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar closed CLOUDSTACK-3370. changed the desig not valid anymore. > Add ipalias deletion to the network gc > -- > > Key: CLOUDSTACK-3370 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3370 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4100) Do not drop iso_id column while upgrading form 3.0.7 to 4.1
Bharat Kumar created CLOUDSTACK-4100: Summary: Do not drop iso_id column while upgrading form 3.0.7 to 4.1 Key: CLOUDSTACK-4100 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4100 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Upgrade Reporter: Bharat Kumar Assignee: Bharat Kumar Priority: Critical -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4100) Do not drop iso_id column while upgrading form 3.0.7 to 4.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-4100: - Summary: Do not drop iso_id column while upgrading form 3.0.7 to 4.2 (was: Do not drop iso_id column while upgrading form 3.0.7 to 4.1) > Do not drop iso_id column while upgrading form 3.0.7 to 4.2 > --- > > Key: CLOUDSTACK-4100 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4100 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Critical > > we need to preserve the data in iso_id cloumn while upgraign from 3.0.7 to 4.2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4100) Do not drop iso_id column while upgrading form 3.0.7 to 4.1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-4100: - Description: we need to preserve the data in iso_id cloumn while upgraign from 3.0.7 to 4.2 > Do not drop iso_id column while upgrading form 3.0.7 to 4.1 > --- > > Key: CLOUDSTACK-4100 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4100 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Critical > > we need to preserve the data in iso_id cloumn while upgraign from 3.0.7 to 4.2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4100) Do not drop iso_id column while upgrading form 3.0.7 to 4.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-4100: - Description: we need to preserve the data in iso_id cloumn while upgrading from 3.0.7 to 4.2 (was: we need to preserve the data in iso_id cloumn while upgraign from 3.0.7 to 4.2) > Do not drop iso_id column while upgrading form 3.0.7 to 4.2 > --- > > Key: CLOUDSTACK-4100 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4100 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Reporter: Bharat Kumar >Assignee: Bharat Kumar >Priority: Critical > > we need to preserve the data in iso_id cloumn while upgrading from 3.0.7 to > 4.2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4105) Vnet's from Phisical network's table are getting deleted even the Vnet is used by Phisical network.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-4105: - Assignee: Bharat Kumar > Vnet's from Phisical network's table are getting deleted even the Vnet is > used by Phisical network. > --- > > Key: CLOUDSTACK-4105 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4105 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.2.0 >Reporter: Kiran Koneti >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.2.0 > > > Steps are as follows: > 1)Created a Advance zone setup using the Vnet range 1100-1109. > 2)Once the setup is up created a VM which intern created a Physical network > with the Vnet 1106. > 3)Then Suing the API update Physical network I tried to remove the Vlan range > 1100-1109. > 4)The Vlan range from the physical network table is removed without any error > message. > 5)but the op_dc_vnet_alloc table still has the entry for the Vlan associated > with the Phisical network. > The below two tables show the db entries: > The Physical network table in the before deleting > mysql> select * from physical_network; > +-+--+++---+---+---++-+-+-+ > | id | uuid | name | > data_center_id | vnet | speed | domain_id | broadcast_domain_range | > state | created | removed | > +-+--+++---+---+---++-+-+-+ > | 200 | 85b82257-fc88-4eec-bf31-8995a6d27535 | Physical Network 1 | >1 | 1100-1109 | NULL | NULL | ZONE | Enabled | > 2013-08-06 14:38:00 | NULL| > +-+--+++---+---+---++-+-+-+ > 1 row in set (0.00 sec) > The Phisical network tabble after the deletion > mysql> select * from physical_network; > +-+--+++--+---+---++-+-+-+ > | id | uuid | name | > data_center_id | vnet | speed | domain_id | broadcast_domain_range | state > | created | removed | > +-+--+++--+---+---++-+-+-+ > | 200 | 85b82257-fc88-4eec-bf31-8995a6d27535 | Physical Network 1 | >1 | NULL | NULL | NULL | ZONE | Enabled | > 2013-08-06 14:38:00 | NULL| > +-+--+++--+---+---++-+-+-+ > 1 row in set (0.00 sec) > The op_dc_vnet_alloc table after deletion > mysql> select * from op_dc_vnet_alloc; > ++--+-++++---+-+ > | id | vnet | physical_network_id | data_center_id | reservation_id | > account_id | taken | account_vnet_map_id | > ++--+-++++---+-+ > | 12 | 1106 | 200 | 1 | NULL | > NULL | NULL |NULL | > ++--+-++++---+-+ > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-3782) Data disk size is modified to KB from GB after it is attached to the instance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-3782: - Assignee: (was: Bharat Kumar) > Data disk size is modified to KB from GB after it is attached to the instance > -- > > Key: CLOUDSTACK-3782 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3782 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.0 > Environment: Cloudstack build : 257 > [http://repo-ccp.citrix.com/releases/ASF/rhel/6.3/4.2/CloudPlatform-4.2-257-rhel6.3.tar.gz] > Hypervisor: Vmware Esxi 5.1 > Storage: NFS for both primary and secondary >Reporter: Pavan Kumar Bandarupally >Priority: Critical > Fix For: 4.2.0 > > Attachments: apilog.log, DATADISK.sql, management-server.log, > screenshot-1.jpg > > > Data disk size is shown as 5 kb when the actual size is 5 GB. API response in > firebug traces gives 5 GB but in the CS UI it is shown as 5 kb. > Attached screenshot of the same. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
