[jira] [Commented] (CLOUDSTACK-6893) systemvms can not start on KVM host
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229566#comment-14229566
]
Rohit Yadav commented on CLOUDSTACK-6893:
-
Just checked, this does not apply on 4.3 and the fix is already in 4.4 branch:
commit d0e0edca111feb71e7cd8267d9c28820d85b12f9
Author: Wei Zhou w.z...@leaseweb.com
Date: Wed Jun 11 13:46:12 2014 +0200
CLOUDSTACK-6893: fix enum ValueOf issue which causes systemvm fail to start
(cherry picked from commit 63ff5a7cbc3341809884e47796476d47ace03961)
systemvms can not start on KVM host
---
Key: CLOUDSTACK-6893
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6893
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Reporter: Wei Zhou
Assignee: Wei Zhou
After upgrading from 4.3 to 4.4, the systemvms can not start with the
following error logs:
2014-06-11 13:39:42,119 DEBUG [cloud.agent.Agent]
(agentRequest-Handler-4:null) Request:Seq 2-8064539557737005074: { Cmd ,
MgmtId: 345051514000, via: 2, Ver: v1, Flags: 100011,
[{com.cloud.agent.api.StartCommand:{vm:{id:216,name:s-216-VM,type:SecondaryStorageVm,cpus:1,minSpeed:500,maxSpeed:500,minRam:536870912,maxRam:536870912,arch:x86_64,os:Debian
GNU/Linux 5.0 (64-bit),platformEmulator:Debian GNU/Linux 5,bootArgs:
template=domP type=secstorage host=172.16.15.10 port=8250 name=s-216-VM
zone=1 pod=1 guid=s-216-VM
resource=org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource
instance=SecStorage sslcopy=false role=templateProcessor mtu=1500
eth2ip=10.11.115.115 eth2mask=255.255.255.0 gateway=10.11.115.254
public.network.device=eth2 eth0ip=169.254.1.127 eth0mask=255.255.0.0
eth1ip=172.16.15.38 eth1mask=255.255.255.0 mgmtcidr=10.11.115.0/24
localgw=172.16.15.254 private.network.device=eth1 eth3ip=172.16.15.41
eth3mask=255.255.255.0 storageip=172.16.15.41 storagenetmask=255.255.255.0
storagegateway=172.16.15.254 internaldns1=8.8.8.8 internaldns2=8.8.4.4
dns1=8.8.8.8
dns2=8.8.4.4,rebootOnCrash:false,enableHA:false,limitCpuUse:false,enableDynamicallyScaleVm:false,vncPassword:3bbd718218d5602b,params:{},uuid:198324f1-aeba-4fae-adad-4ffc087b2f3a,disks:[{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:0d65d238-a753-48da-b1d6-638fa533eb67,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e,id:2,poolType:NetworkFilesystem,host:172.16.15.254,path:/storage/cs-115-pri,port:2049,url:NetworkFilesystem://172.16.15.254/storage/cs-115-pri/?ROLE=PrimarySTOREUUID=1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e}},name:ROOT-216,size:297230848,path:0d65d238-a753-48da-b1d6-638fa533eb67,volumeId:214,vmName:s-216-VM,accountId:1,format:QCOW2,id:214,deviceId:0,cacheMode:NONE,hypervisorType:KVM}},diskSeq:0,path:0d65d238-a753-48da-b1d6-638fa533eb67,type:ROOT,_details:{managed:false,storagePort:2049,storageHost:172.16.15.254,volumeSize:297230848}}],nics:[{deviceId:2,networkRateMbps:-1,defaultNic:true,uuid:765b43a0-43f7-4b23-abcc-86ccc6197a0e,ip:10.11.115.115,netmask:255.255.255.0,gateway:10.11.115.254,mac:06:78:16:00:00:1a,dns1:8.8.8.8,dns2:8.8.4.4,broadcastType:Vlan,type:Public,broadcastUri:vlan://115,isolationUri:vlan://115,isSecurityGroupEnabled:false,name:cloudbr0},{deviceId:0,networkRateMbps:-1,defaultNic:false,uuid:dc8a1a58-e581-49a2-8377-dc4fba1dfa57,ip:169.254.1.127,netmask:255.255.0.0,gateway:169.254.0.1,mac:0e:00:a9:fe:01:7f,broadcastType:LinkLocal,type:Control,isSecurityGroupEnabled:false},{deviceId:1,networkRateMbps:-1,defaultNic:false,uuid:81b10433-e67c-4052-8664-3bfccdb1c9cf,ip:172.16.15.38,netmask:255.255.255.0,gateway:172.16.15.254,mac:06:11:c4:00:00:09,broadcastType:Native,type:Management,isSecurityGroupEnabled:false,name:cloudbr1},{deviceId:3,networkRateMbps:-1,defaultNic:false,uuid:cdcd5757-04df-4b19-a314-f73b314778b2,ip:172.16.15.41,netmask:255.255.255.0,gateway:172.16.15.254,mac:06:ee:96:00:00:70,broadcastType:Storage,type:Storage,isSecurityGroupEnabled:false,name:cloudbr1}]},hostIp:172.16.15.15,executeInSequence:false,wait:0}},{com.cloud.agent.api.check.CheckSshCommand:{ip:169.254.1.127,port:3922,interval:6,retries:100,name:s-216-VM,wait:0}}]
}
2014-06-11 13:39:42,119 DEBUG [cloud.agent.Agent]
(agentRequest-Handler-4:null) Processing command:
com.cloud.agent.api.StartCommand
2014-06-11 13:39:42,178 DEBUG [kvm.storage.KVMStoragePoolManager]
(agentRequest-Handler-4:null) Disconnecting disk
0d65d238-a753-48da-b1d6-638fa533eb67
2014-06-11 13:39:42,229 DEBUG [cloud.agent.Agent]
(agentRequest-Handler-4:null) Seq 2-8064539557737005074: { Ans: , MgmtId:
345051514000, via: 2, Ver: v1, Flags: 10,
[{com.cloud.agent.api.Answer:{result:false,details:No enum constant
[jira] [Commented] (CLOUDSTACK-6850) Cpu cores, cpu speed and memory are not returned by listUsageRecords
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229569#comment-14229569 ] Rohit Yadav commented on CLOUDSTACK-6850: - Thanks for replying [~olemasle] and sorry for a later reply, I found this interesting and you're right we cannot backport since it changes schema. Cpu cores, cpu speed and memory are not returned by listUsageRecords Key: CLOUDSTACK-6850 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6850 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Usage Affects Versions: 4.3.0, 4.4.0 Reporter: Olivier Lemasle Assignee: Olivier Lemasle Priority: Critical Fix For: 4.4.0 When using dynamic custom offerings, cpu cores, cpu speed and ram values are recorded in usage_vm_instance table while parsing the usage events. But these details are not populated in cloud_usage table, and are not returned by the listUsageRecords command. Therefore, there is no way to know the historical values for cpu and memory using API. We should add cpu_cores, cpu_speed and memory in cloud_usage.cloud_usage and return them in listUsageRecords response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7903) Decrease minimal usage aggregation range value
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229640#comment-14229640 ] ASF subversion and git services commented on CLOUDSTACK-7903: - Commit 9b907902d2d424bc8b3136d97196457f42738fff in cloudstack's branch refs/heads/master from [~svscorp] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9b90790 ] CLOUDSTACK-7903: Decreased minimal usage aggregation range value Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Decrease minimal usage aggregation range value -- Key: CLOUDSTACK-7903 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7903 Project: CloudStack Issue Type: Wish Security Level: Public(Anyone can view this level - this is the default.) Components: Usage Affects Versions: 4.4.1 Reporter: Ilia Shakitko Priority: Trivial Fix For: Future, 4.5.0 When you want to build 95-percentile billing model for the network traffic usage, it is good to have 5-minutes usage samples instead of 10 (which is minimum allowed in ACS at the moment). This change decreases the lower limit for USAGE_AGGREGATION_RANGE_MIN parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7903) Decrease minimal usage aggregation range value
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229644#comment-14229644 ] ASF subversion and git services commented on CLOUDSTACK-7903: - Commit e1247814454551313db2a25ab59f1ff0ead30149 in cloudstack's branch refs/heads/4.5 from [~svscorp] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e124781 ] CLOUDSTACK-7903: Decreased minimal usage aggregation range value Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com (cherry picked from commit 9b907902d2d424bc8b3136d97196457f42738fff) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Conflicts: server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java Decrease minimal usage aggregation range value -- Key: CLOUDSTACK-7903 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7903 Project: CloudStack Issue Type: Wish Security Level: Public(Anyone can view this level - this is the default.) Components: Usage Affects Versions: 4.4.1 Reporter: Ilia Shakitko Priority: Trivial Fix For: Future, 4.5.0 When you want to build 95-percentile billing model for the network traffic usage, it is good to have 5-minutes usage samples instead of 10 (which is minimum allowed in ACS at the moment). This change decreases the lower limit for USAGE_AGGREGATION_RANGE_MIN parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7903) Decrease minimal usage aggregation range value
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229646#comment-14229646 ] ASF subversion and git services commented on CLOUDSTACK-7903: - Commit 342b73d37a7cd8bce6cc569d287bbeeea1e8b845 in cloudstack's branch refs/heads/4.4 from [~svscorp] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=342b73d ] CLOUDSTACK-7903: Decreased minimal usage aggregation range value Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com (cherry picked from commit 9b907902d2d424bc8b3136d97196457f42738fff) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Conflicts: server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java Decrease minimal usage aggregation range value -- Key: CLOUDSTACK-7903 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7903 Project: CloudStack Issue Type: Wish Security Level: Public(Anyone can view this level - this is the default.) Components: Usage Affects Versions: 4.4.1 Reporter: Ilia Shakitko Priority: Trivial Fix For: Future, 4.5.0 When you want to build 95-percentile billing model for the network traffic usage, it is good to have 5-minutes usage samples instead of 10 (which is minimum allowed in ACS at the moment). This change decreases the lower limit for USAGE_AGGREGATION_RANGE_MIN parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7993) test_egress_fw_rules.py - Code enhancment - Remove unnecesary wait in test code
Gaurav Aradhye created CLOUDSTACK-7993: -- Summary: test_egress_fw_rules.py - Code enhancment - Remove unnecesary wait in test code Key: CLOUDSTACK-7993 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7993 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.5.0 All test cases in this test suite wait for vm expungement time period after destroying VMs. It is not necessary as now th VM is destroyed by default from Marvin with expunge parameter as True, hence it will be immediately destroyed and expunged. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7994) Network rules are not configured in VR after out-of-band movement due to host crash
Koushik Das created CLOUDSTACK-7994: --- Summary: Network rules are not configured in VR after out-of-band movement due to host crash Key: CLOUDSTACK-7994 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7994 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, VMware Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.5.0 This is specific to Vmware. If VR is moved out-of-band from one host to another then the configured network rules are lost. In order to re-configure VR with the rules it needs to be rebooted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7903) Decrease minimal usage aggregation range value
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229658#comment-14229658 ] ASF subversion and git services commented on CLOUDSTACK-7903: - Commit 1e0880cbabfb2c8edbd6a5a35b9417b2f3e6f681 in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1e0880c ] CLOUDSTACK-7903: Fix build regression from previous fix The previous fix tried to access StatsCollector from UsageManagerImpl which is not possible due to dependency cycle. Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Decrease minimal usage aggregation range value -- Key: CLOUDSTACK-7903 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7903 Project: CloudStack Issue Type: Wish Security Level: Public(Anyone can view this level - this is the default.) Components: Usage Affects Versions: 4.4.1 Reporter: Ilia Shakitko Priority: Trivial Fix For: Future, 4.5.0 When you want to build 95-percentile billing model for the network traffic usage, it is good to have 5-minutes usage samples instead of 10 (which is minimum allowed in ACS at the moment). This change decreases the lower limit for USAGE_AGGREGATION_RANGE_MIN parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7404) Failed to start an instance when originating template has been deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229659#comment-14229659 ] ASF GitHub Bot commented on CLOUDSTACK-7404: GitHub user llambiel opened a pull request: https://github.com/apache/cloudstack/pull/49 CLOUDSTACK-7404: Failed to start an instance when originating template h... CLOUDSTACK-7404: Failed to start an instance when originating template has been deleted You can merge this pull request into a Git repository by running: $ git pull https://github.com/exoscale/cloudstack CLOUDSTACK-7404 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/49.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #49 commit 0e7e7f893d685cdf90be9a7196f954c9b541bf75 Author: Loic Lambiel l...@exoscale.ch Date: 2014-12-01T11:02:56Z CLOUDSTACK-7404: Failed to start an instance when originating template has been deleted Failed to start an instance when originating template has been deleted -- Key: CLOUDSTACK-7404 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7404 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: Ubuntu 12.04, KVM, basic networking, Cloudstack 4.3.0 Reporter: Loic Lambiel Fix For: 4.3.1 Hi, I have an issue were I cannot start an instance that was previously stopped when it's originating template has been deleted. Steps to reproduce: Deploy an instance Stop the instance Delete it's originating template Wait a few minutes Start the instance This was working ok on CS 4.0.x Management server log: 2014-08-22 14:01:51,163 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Stopped to Starting with event: StartReques tedvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,164 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Successfully transitioned to start state for VM[User|VM-69b4c242-fcd1 -47ec-9afa-a798c370da5d] reservation id = 7bc0e976-6ba3-4b58-aa59-1eb011c1de4e 2014-08-22 14:01:51,167 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Trying to deploy VM, vm has dcId: 1 and podId: 1 2014-08-22 14:01:51,168 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) advanceStart: DeploymentPlan is provided, using dcId:1, podId: 1, clu sterId: 1, hostId: 48, poolId: null 2014-08-22 14:01:51,168 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Deploy avoids pods: null, clusters: null, hosts: null 2014-08-22 14:01:51,177 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Starting to Stopped with event: OperationFa iledvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,188 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Stopped to Starting with event: StartReques tedvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,189 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Successfully transitioned to start state for VM[User|VM-69b4c242-fcd1 -47ec-9afa-a798c370da5d] reservation id = 342cb1d2-fc32-4cdf-94c6-049cf16d5509 2014-08-22 14:01:51,191 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Trying to deploy VM, vm has dcId: 1 and podId: 1 2014-08-22 14:01:51,192 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Deploy avoids pods: null, clusters: null, hosts: null 2014-08-22 14:01:51,198 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Starting to Stopped with event: OperationFa iledvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,210 ERROR [cloud.api.ApiAsyncJobDispatcher] (Job-Executor-87:ctx-17783fe6) Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.StartVMCmd java.lang.NullPointerException at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:858) at
[jira] [Commented] (CLOUDSTACK-7903) Decrease minimal usage aggregation range value
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229670#comment-14229670 ] ASF subversion and git services commented on CLOUDSTACK-7903: - Commit 5241d0faf8fb23e00c043527698b0ee13397fd2d in cloudstack's branch refs/heads/4.5 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5241d0f ] CLOUDSTACK-7903: Fix build regression from previous fix The previous fix tried to access StatsCollector from UsageManagerImpl which is not possible due to dependency cycle. Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com (cherry picked from commit 1e0880cbabfb2c8edbd6a5a35b9417b2f3e6f681) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Conflicts: server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java Decrease minimal usage aggregation range value -- Key: CLOUDSTACK-7903 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7903 Project: CloudStack Issue Type: Wish Security Level: Public(Anyone can view this level - this is the default.) Components: Usage Affects Versions: 4.4.1 Reporter: Ilia Shakitko Priority: Trivial Fix For: Future, 4.5.0 When you want to build 95-percentile billing model for the network traffic usage, it is good to have 5-minutes usage samples instead of 10 (which is minimum allowed in ACS at the moment). This change decreases the lower limit for USAGE_AGGREGATION_RANGE_MIN parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7903) Decrease minimal usage aggregation range value
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229678#comment-14229678 ] ASF subversion and git services commented on CLOUDSTACK-7903: - Commit d1f008e2f2601ae9e5a4d6e0bbdcaf2c3b01949a in cloudstack's branch refs/heads/4.4 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d1f008e ] CLOUDSTACK-7903: Fix build regression from previous fix The previous fix tried to access StatsCollector from UsageManagerImpl which is not possible due to dependency cycle. Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com (cherry picked from commit 1e0880cbabfb2c8edbd6a5a35b9417b2f3e6f681) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Conflicts: server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java Decrease minimal usage aggregation range value -- Key: CLOUDSTACK-7903 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7903 Project: CloudStack Issue Type: Wish Security Level: Public(Anyone can view this level - this is the default.) Components: Usage Affects Versions: 4.4.1 Reporter: Ilia Shakitko Priority: Trivial Fix For: Future, 4.5.0 When you want to build 95-percentile billing model for the network traffic usage, it is good to have 5-minutes usage samples instead of 10 (which is minimum allowed in ACS at the moment). This change decreases the lower limit for USAGE_AGGREGATION_RANGE_MIN parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7903) Decrease minimal usage aggregation range value
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229683#comment-14229683 ] ASF subversion and git services commented on CLOUDSTACK-7903: - Commit 37058a8e56e35ebe26a65a6bebb01d92f99de4b0 in cloudstack's branch refs/heads/4.3 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=37058a8 ] CLOUDSTACK-7903: Fix build regression from previous fix The previous fix tried to access StatsCollector from UsageManagerImpl which is not possible due to dependency cycle. Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com (cherry picked from commit 1e0880cbabfb2c8edbd6a5a35b9417b2f3e6f681) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Conflicts: server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java Decrease minimal usage aggregation range value -- Key: CLOUDSTACK-7903 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7903 Project: CloudStack Issue Type: Wish Security Level: Public(Anyone can view this level - this is the default.) Components: Usage Affects Versions: 4.4.1 Reporter: Ilia Shakitko Priority: Trivial Fix For: Future, 4.5.0 When you want to build 95-percentile billing model for the network traffic usage, it is good to have 5-minutes usage samples instead of 10 (which is minimum allowed in ACS at the moment). This change decreases the lower limit for USAGE_AGGREGATION_RANGE_MIN parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7993) test_egress_fw_rules.py - Code enhancment - Remove unnecesary wait in test code
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye updated CLOUDSTACK-7993: --- Status: Reviewable (was: In Progress) test_egress_fw_rules.py - Code enhancment - Remove unnecesary wait in test code --- Key: CLOUDSTACK-7993 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7993 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 All test cases in this test suite wait for vm expungement time period after destroying VMs. It is not necessary as now th VM is destroyed by default from Marvin with expunge parameter as True, hence it will be immediately destroyed and expunged. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7903) Decrease minimal usage aggregation range value
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav resolved CLOUDSTACK-7903. - Resolution: Fixed Assignee: Rohit Yadav Merged review request on 4.3/4.4/4.5/master with a build regression fixed on all branches as well. Decrease minimal usage aggregation range value -- Key: CLOUDSTACK-7903 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7903 Project: CloudStack Issue Type: Wish Security Level: Public(Anyone can view this level - this is the default.) Components: Usage Affects Versions: 4.4.1 Reporter: Ilia Shakitko Assignee: Rohit Yadav Priority: Trivial Fix For: Future, 4.5.0 When you want to build 95-percentile billing model for the network traffic usage, it is good to have 5-minutes usage samples instead of 10 (which is minimum allowed in ACS at the moment). This change decreases the lower limit for USAGE_AGGREGATION_RANGE_MIN parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7903) Decrease minimal usage aggregation range value
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav updated CLOUDSTACK-7903: Fix Version/s: 4.3.2 4.4.3 Decrease minimal usage aggregation range value -- Key: CLOUDSTACK-7903 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7903 Project: CloudStack Issue Type: Wish Security Level: Public(Anyone can view this level - this is the default.) Components: Usage Affects Versions: 4.4.1 Reporter: Ilia Shakitko Assignee: Rohit Yadav Priority: Trivial Fix For: Future, 4.5.0, 4.4.3, 4.3.2 When you want to build 95-percentile billing model for the network traffic usage, it is good to have 5-minutes usage samples instead of 10 (which is minimum allowed in ACS at the moment). This change decreases the lower limit for USAGE_AGGREGATION_RANGE_MIN parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7404) Failed to start an instance when originating template has been deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229690#comment-14229690 ] ASF GitHub Bot commented on CLOUDSTACK-7404: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/49#issuecomment-65053557 +1 As soon as travis passes, I'll help merge it. Thanks for sending the PR. Failed to start an instance when originating template has been deleted -- Key: CLOUDSTACK-7404 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7404 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: Ubuntu 12.04, KVM, basic networking, Cloudstack 4.3.0 Reporter: Loic Lambiel Fix For: 4.3.1 Hi, I have an issue were I cannot start an instance that was previously stopped when it's originating template has been deleted. Steps to reproduce: Deploy an instance Stop the instance Delete it's originating template Wait a few minutes Start the instance This was working ok on CS 4.0.x Management server log: 2014-08-22 14:01:51,163 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Stopped to Starting with event: StartReques tedvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,164 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Successfully transitioned to start state for VM[User|VM-69b4c242-fcd1 -47ec-9afa-a798c370da5d] reservation id = 7bc0e976-6ba3-4b58-aa59-1eb011c1de4e 2014-08-22 14:01:51,167 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Trying to deploy VM, vm has dcId: 1 and podId: 1 2014-08-22 14:01:51,168 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) advanceStart: DeploymentPlan is provided, using dcId:1, podId: 1, clu sterId: 1, hostId: 48, poolId: null 2014-08-22 14:01:51,168 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Deploy avoids pods: null, clusters: null, hosts: null 2014-08-22 14:01:51,177 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Starting to Stopped with event: OperationFa iledvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,188 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Stopped to Starting with event: StartReques tedvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,189 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Successfully transitioned to start state for VM[User|VM-69b4c242-fcd1 -47ec-9afa-a798c370da5d] reservation id = 342cb1d2-fc32-4cdf-94c6-049cf16d5509 2014-08-22 14:01:51,191 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Trying to deploy VM, vm has dcId: 1 and podId: 1 2014-08-22 14:01:51,192 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Deploy avoids pods: null, clusters: null, hosts: null 2014-08-22 14:01:51,198 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Starting to Stopped with event: OperationFa iledvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,210 ERROR [cloud.api.ApiAsyncJobDispatcher] (Job-Executor-87:ctx-17783fe6) Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.StartVMCmd java.lang.NullPointerException at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:858) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:601) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:237) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:207) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3581) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2043) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[jira] [Commented] (CLOUDSTACK-5834) [upgrade]Error while collecting disk stats from : You gave an invalid object reference. The object may have recently been deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229702#comment-14229702 ] ASF subversion and git services commented on CLOUDSTACK-5834: - Commit 4e33d359a82a3708860b24d88b37446cf16e1285 in cloudstack's branch refs/heads/4.3 from [~anthonyxu] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4e33d35 ] CLOUDSTACK-5834: got VBD statistics from RRD (cherry picked from commit 0fe1d4bb27de83f3fff4e22d0bb501bc2451e62f) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Conflicts: plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java [upgrade]Error while collecting disk stats from : You gave an invalid object reference. The object may have recently been deleted -- Key: CLOUDSTACK-5834 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5834 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, XenServer Affects Versions: 4.3.0 Reporter: prashant kumar mishra Assignee: Anthony Xu Fix For: 4.4.0, 4.5.0 Attachments: MS_XEN_log_DB.rar Steps == 1-prepare ACS 4.2 setup with xen6.2 host 2-upgrade CS to 4.3 and upgrade xen 6.2 to xen6.2sp1 After upgrade i am seeing error message in log whenever VmStatsCollector is running. Logs == 2014-01-08 13:15:08,182 DEBUG [c.c.s.StatsCollector] (StatsCollector-2:ctx-aa75b506) VmStatsCollector is running... 2014-01-08 13:15:08,207 DEBUG [c.c.a.m.DirectAgentAttache] (DirectAgent-141:ctx-74d0d04a) Seq 1-498139202: Executing request 2014-01-08 13:15:08,358 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-141:ctx-74d0d04a) Vm cpu utilization 0.0 2014-01-08 13:15:08,359 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-141:ctx-74d0d04a) Vm cpu utilization 0.00453125 2014-01-08 13:15:08,369 WARN [c.c.h.x.r.CitrixResourceBase] (DirectAgent-141:ctx-74d0d04a) Error while collecting disk stats from : 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.VBDMetrics.getIoReadKbs(VBDMetrics.java:210) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.getVmStats(CitrixResourceBase.java:2784) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:2684) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:493) 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) 2014-01-08 13:15:08,371 DEBUG [c.c.a.m.DirectAgentAttache] (DirectAgent-141:ctx-74d0d04a) Seq 1-498139202:
[jira] [Commented] (CLOUDSTACK-5834) [upgrade]Error while collecting disk stats from : You gave an invalid object reference. The object may have recently been deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229705#comment-14229705 ] ASF subversion and git services commented on CLOUDSTACK-5834: - Commit afd79967768399c3289bb163d2ec75eb4e8c1f96 in cloudstack's branch refs/heads/4.4 from [~anthonyxu] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=afd7996 ] CLOUDSTACK-5834: got VBD statistics from RRD (cherry picked from commit 4e33d359a82a3708860b24d88b37446cf16e1285) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Conflicts: plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java [upgrade]Error while collecting disk stats from : You gave an invalid object reference. The object may have recently been deleted -- Key: CLOUDSTACK-5834 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5834 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, XenServer Affects Versions: 4.3.0 Reporter: prashant kumar mishra Assignee: Anthony Xu Fix For: 4.4.0, 4.5.0 Attachments: MS_XEN_log_DB.rar Steps == 1-prepare ACS 4.2 setup with xen6.2 host 2-upgrade CS to 4.3 and upgrade xen 6.2 to xen6.2sp1 After upgrade i am seeing error message in log whenever VmStatsCollector is running. Logs == 2014-01-08 13:15:08,182 DEBUG [c.c.s.StatsCollector] (StatsCollector-2:ctx-aa75b506) VmStatsCollector is running... 2014-01-08 13:15:08,207 DEBUG [c.c.a.m.DirectAgentAttache] (DirectAgent-141:ctx-74d0d04a) Seq 1-498139202: Executing request 2014-01-08 13:15:08,358 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-141:ctx-74d0d04a) Vm cpu utilization 0.0 2014-01-08 13:15:08,359 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-141:ctx-74d0d04a) Vm cpu utilization 0.00453125 2014-01-08 13:15:08,369 WARN [c.c.h.x.r.CitrixResourceBase] (DirectAgent-141:ctx-74d0d04a) Error while collecting disk stats from : 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.VBDMetrics.getIoReadKbs(VBDMetrics.java:210) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.getVmStats(CitrixResourceBase.java:2784) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:2684) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:493) 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) 2014-01-08 13:15:08,371 DEBUG [c.c.a.m.DirectAgentAttache] (DirectAgent-141:ctx-74d0d04a) Seq 1-498139202:
[jira] [Commented] (CLOUDSTACK-7983) Create Disk/Service Offering for Domain Admin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229704#comment-14229704 ] ASF subversion and git services commented on CLOUDSTACK-7983: - Commit af2f21894ce061faadc8cec29b901719303a29dc in cloudstack's branch refs/heads/master from Wei Zhou [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=af2f218 ] CLOUDSTACK-7983: Create Disk/Service Offering for Domain Admin Create Disk/Service Offering for Domain Admin - Key: CLOUDSTACK-7983 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7983 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Reporter: Wei Zhou Assignee: Wei Zhou now the offerings can only be created by admin, it is better to allow the domain admins to create the offerings which can be used in the domain. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7404) Failed to start an instance when originating template has been deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229706#comment-14229706 ] ASF subversion and git services commented on CLOUDSTACK-7404: - Commit 34e8483e802d5467f6d5f52e8116ee26fe100f6f in cloudstack's branch refs/heads/master from [~llambiel] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=34e8483 ] CLOUDSTACK-7404: Failed to start an instance when originating template has been deleted Signed-off-by: Sebastien Goasguen run...@gmail.com (cherry picked from commit c1bf7eb3bd4dad384225d411e21859cce470) Failed to start an instance when originating template has been deleted -- Key: CLOUDSTACK-7404 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7404 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: Ubuntu 12.04, KVM, basic networking, Cloudstack 4.3.0 Reporter: Loic Lambiel Fix For: 4.3.1 Hi, I have an issue were I cannot start an instance that was previously stopped when it's originating template has been deleted. Steps to reproduce: Deploy an instance Stop the instance Delete it's originating template Wait a few minutes Start the instance This was working ok on CS 4.0.x Management server log: 2014-08-22 14:01:51,163 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Stopped to Starting with event: StartReques tedvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,164 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Successfully transitioned to start state for VM[User|VM-69b4c242-fcd1 -47ec-9afa-a798c370da5d] reservation id = 7bc0e976-6ba3-4b58-aa59-1eb011c1de4e 2014-08-22 14:01:51,167 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Trying to deploy VM, vm has dcId: 1 and podId: 1 2014-08-22 14:01:51,168 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) advanceStart: DeploymentPlan is provided, using dcId:1, podId: 1, clu sterId: 1, hostId: 48, poolId: null 2014-08-22 14:01:51,168 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Deploy avoids pods: null, clusters: null, hosts: null 2014-08-22 14:01:51,177 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Starting to Stopped with event: OperationFa iledvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,188 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Stopped to Starting with event: StartReques tedvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,189 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Successfully transitioned to start state for VM[User|VM-69b4c242-fcd1 -47ec-9afa-a798c370da5d] reservation id = 342cb1d2-fc32-4cdf-94c6-049cf16d5509 2014-08-22 14:01:51,191 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Trying to deploy VM, vm has dcId: 1 and podId: 1 2014-08-22 14:01:51,192 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Deploy avoids pods: null, clusters: null, hosts: null 2014-08-22 14:01:51,198 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Starting to Stopped with event: OperationFa iledvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,210 ERROR [cloud.api.ApiAsyncJobDispatcher] (Job-Executor-87:ctx-17783fe6) Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.StartVMCmd java.lang.NullPointerException at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:858) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:601) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:237) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:207) at
[jira] [Commented] (CLOUDSTACK-7404) Failed to start an instance when originating template has been deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229707#comment-14229707 ] ASF subversion and git services commented on CLOUDSTACK-7404: - Commit 99cb19787e55e2a80f2683291abc53fabb13f5c7 in cloudstack's branch refs/heads/4.5 from [~llambiel] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=99cb197 ] CLOUDSTACK-7404: Failed to start an instance when originating template has been deleted Signed-off-by: Sebastien Goasguen run...@gmail.com (cherry picked from commit c1bf7eb3bd4dad384225d411e21859cce470) Failed to start an instance when originating template has been deleted -- Key: CLOUDSTACK-7404 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7404 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: Ubuntu 12.04, KVM, basic networking, Cloudstack 4.3.0 Reporter: Loic Lambiel Fix For: 4.3.1 Hi, I have an issue were I cannot start an instance that was previously stopped when it's originating template has been deleted. Steps to reproduce: Deploy an instance Stop the instance Delete it's originating template Wait a few minutes Start the instance This was working ok on CS 4.0.x Management server log: 2014-08-22 14:01:51,163 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Stopped to Starting with event: StartReques tedvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,164 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Successfully transitioned to start state for VM[User|VM-69b4c242-fcd1 -47ec-9afa-a798c370da5d] reservation id = 7bc0e976-6ba3-4b58-aa59-1eb011c1de4e 2014-08-22 14:01:51,167 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Trying to deploy VM, vm has dcId: 1 and podId: 1 2014-08-22 14:01:51,168 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) advanceStart: DeploymentPlan is provided, using dcId:1, podId: 1, clu sterId: 1, hostId: 48, poolId: null 2014-08-22 14:01:51,168 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Deploy avoids pods: null, clusters: null, hosts: null 2014-08-22 14:01:51,177 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Starting to Stopped with event: OperationFa iledvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,188 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Stopped to Starting with event: StartReques tedvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,189 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Successfully transitioned to start state for VM[User|VM-69b4c242-fcd1 -47ec-9afa-a798c370da5d] reservation id = 342cb1d2-fc32-4cdf-94c6-049cf16d5509 2014-08-22 14:01:51,191 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Trying to deploy VM, vm has dcId: 1 and podId: 1 2014-08-22 14:01:51,192 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Deploy avoids pods: null, clusters: null, hosts: null 2014-08-22 14:01:51,198 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Starting to Stopped with event: OperationFa iledvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,210 ERROR [cloud.api.ApiAsyncJobDispatcher] (Job-Executor-87:ctx-17783fe6) Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.StartVMCmd java.lang.NullPointerException at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:858) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:601) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:237) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:207) at
[jira] [Commented] (CLOUDSTACK-5834) [upgrade]Error while collecting disk stats from : You gave an invalid object reference. The object may have recently been deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229709#comment-14229709 ] Rohit Yadav commented on CLOUDSTACK-5834: - 4.5 and master already has fix by Anthony so skipping. [upgrade]Error while collecting disk stats from : You gave an invalid object reference. The object may have recently been deleted -- Key: CLOUDSTACK-5834 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5834 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, XenServer Affects Versions: 4.3.0 Reporter: prashant kumar mishra Assignee: Anthony Xu Fix For: 4.4.0, 4.5.0 Attachments: MS_XEN_log_DB.rar Steps == 1-prepare ACS 4.2 setup with xen6.2 host 2-upgrade CS to 4.3 and upgrade xen 6.2 to xen6.2sp1 After upgrade i am seeing error message in log whenever VmStatsCollector is running. Logs == 2014-01-08 13:15:08,182 DEBUG [c.c.s.StatsCollector] (StatsCollector-2:ctx-aa75b506) VmStatsCollector is running... 2014-01-08 13:15:08,207 DEBUG [c.c.a.m.DirectAgentAttache] (DirectAgent-141:ctx-74d0d04a) Seq 1-498139202: Executing request 2014-01-08 13:15:08,358 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-141:ctx-74d0d04a) Vm cpu utilization 0.0 2014-01-08 13:15:08,359 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-141:ctx-74d0d04a) Vm cpu utilization 0.00453125 2014-01-08 13:15:08,369 WARN [c.c.h.x.r.CitrixResourceBase] (DirectAgent-141:ctx-74d0d04a) Error while collecting disk stats from : 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.VBDMetrics.getIoReadKbs(VBDMetrics.java:210) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.getVmStats(CitrixResourceBase.java:2784) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:2684) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:493) 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) 2014-01-08 13:15:08,371 DEBUG [c.c.a.m.DirectAgentAttache] (DirectAgent-141:ctx-74d0d04a) Seq 1-498139202: Response Received: -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7404) Failed to start an instance when originating template has been deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229710#comment-14229710 ] Wei Zhou commented on CLOUDSTACK-7404: -- cherry-pick to 4.5 and master Failed to start an instance when originating template has been deleted -- Key: CLOUDSTACK-7404 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7404 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: Ubuntu 12.04, KVM, basic networking, Cloudstack 4.3.0 Reporter: Loic Lambiel Fix For: 4.3.1 Hi, I have an issue were I cannot start an instance that was previously stopped when it's originating template has been deleted. Steps to reproduce: Deploy an instance Stop the instance Delete it's originating template Wait a few minutes Start the instance This was working ok on CS 4.0.x Management server log: 2014-08-22 14:01:51,163 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Stopped to Starting with event: StartReques tedvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,164 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Successfully transitioned to start state for VM[User|VM-69b4c242-fcd1 -47ec-9afa-a798c370da5d] reservation id = 7bc0e976-6ba3-4b58-aa59-1eb011c1de4e 2014-08-22 14:01:51,167 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Trying to deploy VM, vm has dcId: 1 and podId: 1 2014-08-22 14:01:51,168 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) advanceStart: DeploymentPlan is provided, using dcId:1, podId: 1, clu sterId: 1, hostId: 48, poolId: null 2014-08-22 14:01:51,168 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Deploy avoids pods: null, clusters: null, hosts: null 2014-08-22 14:01:51,177 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Starting to Stopped with event: OperationFa iledvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,188 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Stopped to Starting with event: StartReques tedvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,189 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Successfully transitioned to start state for VM[User|VM-69b4c242-fcd1 -47ec-9afa-a798c370da5d] reservation id = 342cb1d2-fc32-4cdf-94c6-049cf16d5509 2014-08-22 14:01:51,191 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Trying to deploy VM, vm has dcId: 1 and podId: 1 2014-08-22 14:01:51,192 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Deploy avoids pods: null, clusters: null, hosts: null 2014-08-22 14:01:51,198 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Starting to Stopped with event: OperationFa iledvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,210 ERROR [cloud.api.ApiAsyncJobDispatcher] (Job-Executor-87:ctx-17783fe6) Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.StartVMCmd java.lang.NullPointerException at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:858) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:601) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:237) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:207) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3581) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2043) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at
[jira] [Commented] (CLOUDSTACK-7595) Config parameters job.expire.minutes and job.cancel.threshold.minutes incorrectly getting multiplied by a factor of 60
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229717#comment-14229717 ] ASF subversion and git services commented on CLOUDSTACK-7595: - Commit e0ea8801fb501282e5358b05c0c648dc6ee76739 in cloudstack's branch refs/heads/4.3 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e0ea880 ] CLOUDSTACK-7595: Remove unnecessary multiply factor for job expiry Backported using a6ee4112a5404303324c900d9bcd1cebf157 by Koushik Das kous...@apache.org CLOUDSTACK-7595: Config parameters job.expire.minutes and job.cancel.threshold.minutes incorrectly getting multiplied by a factor of 60 Removed the unnecessary multiply factor for both the config parameters. Also removed the duplicate entries from Config.java as these are not required Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Config parameters job.expire.minutes and job.cancel.threshold.minutes incorrectly getting multiplied by a factor of 60 -- Key: CLOUDSTACK-7595 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7595 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, 4.4.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.5.0 Config parameters job.expire.minutes and job.cancel.threshold.minutes incorrectly getting multiplied by a factor of 60. The workaround is to adjust the values (divide by 60). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7595) Config parameters job.expire.minutes and job.cancel.threshold.minutes incorrectly getting multiplied by a factor of 60
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229718#comment-14229718 ] ASF subversion and git services commented on CLOUDSTACK-7595: - Commit e0ea8801fb501282e5358b05c0c648dc6ee76739 in cloudstack's branch refs/heads/4.3 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e0ea880 ] CLOUDSTACK-7595: Remove unnecessary multiply factor for job expiry Backported using a6ee4112a5404303324c900d9bcd1cebf157 by Koushik Das kous...@apache.org CLOUDSTACK-7595: Config parameters job.expire.minutes and job.cancel.threshold.minutes incorrectly getting multiplied by a factor of 60 Removed the unnecessary multiply factor for both the config parameters. Also removed the duplicate entries from Config.java as these are not required Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Config parameters job.expire.minutes and job.cancel.threshold.minutes incorrectly getting multiplied by a factor of 60 -- Key: CLOUDSTACK-7595 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7595 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, 4.4.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.5.0 Config parameters job.expire.minutes and job.cancel.threshold.minutes incorrectly getting multiplied by a factor of 60. The workaround is to adjust the values (divide by 60). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7595) Config parameters job.expire.minutes and job.cancel.threshold.minutes incorrectly getting multiplied by a factor of 60
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229719#comment-14229719 ] ASF subversion and git services commented on CLOUDSTACK-7595: - Commit c44262bfc2c51bad3ec1a29fc8066dc78d90b1ad in cloudstack's branch refs/heads/4.4 from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c44262b ] CLOUDSTACK-7595: Config parameters job.expire.minutes and job.cancel.threshold.minutes incorrectly getting multiplied by a factor of 60 Removed the unnecessary multiply factor for both the config parameters. Also removed the duplicate entries from Config.java as these are not required (cherry picked from commit a6ee4112a5404303324c900d9bcd1cebf157) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Config parameters job.expire.minutes and job.cancel.threshold.minutes incorrectly getting multiplied by a factor of 60 -- Key: CLOUDSTACK-7595 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7595 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, 4.4.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.5.0 Config parameters job.expire.minutes and job.cancel.threshold.minutes incorrectly getting multiplied by a factor of 60. The workaround is to adjust the values (divide by 60). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7360) [vmware] Add host to existing cluster fails if the cluster is using Nexus 1000v as backend for atleast one traffic type.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229720#comment-14229720 ] ASF subversion and git services commented on CLOUDSTACK-7360: - Commit 8b4b51b05434d2cc9c8a5ca755fe351880d66f3d in cloudstack's branch refs/heads/4.4 from [~sateeshc] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8b4b51b ] CLOUDSTACK-7360 [vmware] Add host to existing cluster fails if the cluster is using Nexus 1000v as backend for atleast one traffic type. While adding host to existing cluster which is using Nexus 1000v as a network backend, skip validation of Nexus VSM as it was already done while adding that cluster. Signed-off-by: Sateesh Chodapuneedi sate...@apache.org (cherry picked from commit a1d0925f902041b187f14413e91bc368f0708753) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com [vmware] Add host to existing cluster fails if the cluster is using Nexus 1000v as backend for atleast one traffic type. Key: CLOUDSTACK-7360 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7360 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.2.0, 4.3.0, 4.4.0 Environment: vCenter/ESXi 5.0, Nexus 1000v 1.4 Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Priority: Critical Fix For: 4.5.0 Original Estimate: 72h Remaining Estimate: 72h Steps to reproduce: 1) Before creating zone, set global params vmware.use.nexus.vswitch vmware.use.dvswitch is to true. 2) Complete zone wizard 3) Using vCenter add ESXi host to a cluster, which is already being managed by CCP 4) Using CCP UI add the same host to that cluster - This fails -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7360) [vmware] Add host to existing cluster fails if the cluster is using Nexus 1000v as backend for atleast one traffic type.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229721#comment-14229721 ] ASF subversion and git services commented on CLOUDSTACK-7360: - Commit b9d9c2b7fad3fa1aacfe15687366f640dabde176 in cloudstack's branch refs/heads/4.3 from [~sateeshc] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b9d9c2b ] CLOUDSTACK-7360 [vmware] Add host to existing cluster fails if the cluster is using Nexus 1000v as backend for atleast one traffic type. While adding host to existing cluster which is using Nexus 1000v as a network backend, skip validation of Nexus VSM as it was already done while adding that cluster. Signed-off-by: Sateesh Chodapuneedi sate...@apache.org (cherry picked from commit a1d0925f902041b187f14413e91bc368f0708753) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Conflicts: plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/VmwareServerDiscoverer.java [vmware] Add host to existing cluster fails if the cluster is using Nexus 1000v as backend for atleast one traffic type. Key: CLOUDSTACK-7360 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7360 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.2.0, 4.3.0, 4.4.0 Environment: vCenter/ESXi 5.0, Nexus 1000v 1.4 Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Priority: Critical Fix For: 4.5.0 Original Estimate: 72h Remaining Estimate: 72h Steps to reproduce: 1) Before creating zone, set global params vmware.use.nexus.vswitch vmware.use.dvswitch is to true. 2) Complete zone wizard 3) Using vCenter add ESXi host to a cluster, which is already being managed by CCP 4) Using CCP UI add the same host to that cluster - This fails -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6945) Null pointer exception when starting a VM that had its template deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229722#comment-14229722 ] Rohit Yadav commented on CLOUDSTACK-6945: - Any comments on this - [~nitinme] [~mike-tutkowski] ? Null pointer exception when starting a VM that had its template deleted --- Key: CLOUDSTACK-6945 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6945 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: Hosts are Debian 7.4.0 with Xen hypervisor e Xen Cloud Platform packages installed and properly configured. Reporter: Rafael Weingartner Priority: Critical Fix For: 4.5.0, 4.4.3, 4.3.2 It seems that you have a bug in CS 4.3.0(and probably previous versions?) when starting a machine that was created from a template that has been deleted. There will happen a null pointer exception in com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart: “858 -if (volTemplateId != null volTemplateId.longValue() != template.getId())” The object, “template” is going to be null, because in: “811 - VirtualMachineTemplate template = _entityMgr.findById(VirtualMachineTemplate.class, vm.getTemplateId());” The findById, will add a where clause, looking for template that have the column removed that is null, therefore It will return a null object. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7404) Failed to start an instance when originating template has been deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229726#comment-14229726 ] ASF GitHub Bot commented on CLOUDSTACK-7404: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/49#issuecomment-65058250 Hi, I just saw Wei checked in the fix from 4.3/4.4 on master. I've applied the same on 4.5 branch so we don't lose your commit. Since, it's already in all 4.3+ branches, please close this PR. Failed to start an instance when originating template has been deleted -- Key: CLOUDSTACK-7404 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7404 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: Ubuntu 12.04, KVM, basic networking, Cloudstack 4.3.0 Reporter: Loic Lambiel Fix For: 4.3.1 Hi, I have an issue were I cannot start an instance that was previously stopped when it's originating template has been deleted. Steps to reproduce: Deploy an instance Stop the instance Delete it's originating template Wait a few minutes Start the instance This was working ok on CS 4.0.x Management server log: 2014-08-22 14:01:51,163 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Stopped to Starting with event: StartReques tedvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,164 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Successfully transitioned to start state for VM[User|VM-69b4c242-fcd1 -47ec-9afa-a798c370da5d] reservation id = 7bc0e976-6ba3-4b58-aa59-1eb011c1de4e 2014-08-22 14:01:51,167 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Trying to deploy VM, vm has dcId: 1 and podId: 1 2014-08-22 14:01:51,168 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) advanceStart: DeploymentPlan is provided, using dcId:1, podId: 1, clu sterId: 1, hostId: 48, poolId: null 2014-08-22 14:01:51,168 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Deploy avoids pods: null, clusters: null, hosts: null 2014-08-22 14:01:51,177 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Starting to Stopped with event: OperationFa iledvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,188 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Stopped to Starting with event: StartReques tedvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,189 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Successfully transitioned to start state for VM[User|VM-69b4c242-fcd1 -47ec-9afa-a798c370da5d] reservation id = 342cb1d2-fc32-4cdf-94c6-049cf16d5509 2014-08-22 14:01:51,191 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Trying to deploy VM, vm has dcId: 1 and podId: 1 2014-08-22 14:01:51,192 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Deploy avoids pods: null, clusters: null, hosts: null 2014-08-22 14:01:51,198 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Starting to Stopped with event: OperationFa iledvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,210 ERROR [cloud.api.ApiAsyncJobDispatcher] (Job-Executor-87:ctx-17783fe6) Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.StartVMCmd java.lang.NullPointerException at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:858) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:601) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:237) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:207) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3581) at
[jira] [Commented] (CLOUDSTACK-6945) Null pointer exception when starting a VM that had its template deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229727#comment-14229727 ] Wei Zhou commented on CLOUDSTACK-6945: -- Hi Rohit, This morning I cherry-picked the commit for CLOUDSTACK-7404 from 4.3 to 4.5/master. I think they are duplicated. -Wei Null pointer exception when starting a VM that had its template deleted --- Key: CLOUDSTACK-6945 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6945 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: Hosts are Debian 7.4.0 with Xen hypervisor e Xen Cloud Platform packages installed and properly configured. Reporter: Rafael Weingartner Priority: Critical Fix For: 4.5.0, 4.4.3, 4.3.2 It seems that you have a bug in CS 4.3.0(and probably previous versions?) when starting a machine that was created from a template that has been deleted. There will happen a null pointer exception in com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart: “858 -if (volTemplateId != null volTemplateId.longValue() != template.getId())” The object, “template” is going to be null, because in: “811 - VirtualMachineTemplate template = _entityMgr.findById(VirtualMachineTemplate.class, vm.getTemplateId());” The findById, will add a where clause, looking for template that have the column removed that is null, therefore It will return a null object. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6945) Null pointer exception when starting a VM that had its template deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229728#comment-14229728 ] Rohit Yadav commented on CLOUDSTACK-6945: - Thanks Wei! I've cherry-picked it to 4.5 as well and checked that the fix is already in 4.3 and 4.4 branches. Null pointer exception when starting a VM that had its template deleted --- Key: CLOUDSTACK-6945 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6945 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: Hosts are Debian 7.4.0 with Xen hypervisor e Xen Cloud Platform packages installed and properly configured. Reporter: Rafael Weingartner Priority: Critical Fix For: 4.5.0, 4.4.3, 4.3.2 It seems that you have a bug in CS 4.3.0(and probably previous versions?) when starting a machine that was created from a template that has been deleted. There will happen a null pointer exception in com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart: “858 -if (volTemplateId != null volTemplateId.longValue() != template.getId())” The object, “template” is going to be null, because in: “811 - VirtualMachineTemplate template = _entityMgr.findById(VirtualMachineTemplate.class, vm.getTemplateId());” The findById, will add a where clause, looking for template that have the column removed that is null, therefore It will return a null object. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7994) Network rules are not configured in VR after out-of-band movement due to host crash
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229730#comment-14229730 ] ASF subversion and git services commented on CLOUDSTACK-7994: - Commit 513adab51b53ba1acdea908225cfffab90ca1595 in cloudstack's branch refs/heads/4.5 from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=513adab ] CLOUDSTACK-7994: Network rules are not configured in VR after out-of-band movement due to host crash Ensure that VR is re-booted when it is moved to another host out-of-band. This is necessary to re-program all network rules Network rules are not configured in VR after out-of-band movement due to host crash --- Key: CLOUDSTACK-7994 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7994 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, VMware Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.5.0 This is specific to Vmware. If VR is moved out-of-band from one host to another then the configured network rules are lost. In order to re-configure VR with the rules it needs to be rebooted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7994) Network rules are not configured in VR after out-of-band movement due to host crash
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229751#comment-14229751 ] Rohit Yadav commented on CLOUDSTACK-7994: - Is this related to https://issues.apache.org/jira/browse/CLOUDSTACK-5685 ? [~koushikd] can you help port this to 4.3/4.4? As this clearly affects both of those branches. Network rules are not configured in VR after out-of-band movement due to host crash --- Key: CLOUDSTACK-7994 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7994 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, VMware Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.5.0 This is specific to Vmware. If VR is moved out-of-band from one host to another then the configured network rules are lost. In order to re-configure VR with the rules it needs to be rebooted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7994) Network rules are not configured in VR after out-of-band movement due to host crash
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koushik Das resolved CLOUDSTACK-7994. - Resolution: Fixed Network rules are not configured in VR after out-of-band movement due to host crash --- Key: CLOUDSTACK-7994 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7994 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, VMware Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.5.0 This is specific to Vmware. If VR is moved out-of-band from one host to another then the configured network rules are lost. In order to re-configure VR with the rules it needs to be rebooted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7994) Network rules are not configured in VR after out-of-band movement due to host crash
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229774#comment-14229774 ] ASF subversion and git services commented on CLOUDSTACK-7994: - Commit c3515c9ff98c8447d16dc9cc294aab3496f045a4 in cloudstack's branch refs/heads/master from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c3515c9 ] CLOUDSTACK-7994: Network rules are not configured in VR after out-of-band movement due to host crash Ensure that VR is re-booted when it is moved to another host out-of-band. This is necessary to re-program all network rules Conflicts: server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java Network rules are not configured in VR after out-of-band movement due to host crash --- Key: CLOUDSTACK-7994 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7994 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, VMware Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.5.0 This is specific to Vmware. If VR is moved out-of-band from one host to another then the configured network rules are lost. In order to re-configure VR with the rules it needs to be rebooted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7404) Failed to start an instance when originating template has been deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229802#comment-14229802 ] ASF GitHub Bot commented on CLOUDSTACK-7404: Github user llambiel closed the pull request at: https://github.com/apache/cloudstack/pull/49 Failed to start an instance when originating template has been deleted -- Key: CLOUDSTACK-7404 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7404 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: Ubuntu 12.04, KVM, basic networking, Cloudstack 4.3.0 Reporter: Loic Lambiel Fix For: 4.3.1 Hi, I have an issue were I cannot start an instance that was previously stopped when it's originating template has been deleted. Steps to reproduce: Deploy an instance Stop the instance Delete it's originating template Wait a few minutes Start the instance This was working ok on CS 4.0.x Management server log: 2014-08-22 14:01:51,163 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Stopped to Starting with event: StartReques tedvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,164 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Successfully transitioned to start state for VM[User|VM-69b4c242-fcd1 -47ec-9afa-a798c370da5d] reservation id = 7bc0e976-6ba3-4b58-aa59-1eb011c1de4e 2014-08-22 14:01:51,167 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Trying to deploy VM, vm has dcId: 1 and podId: 1 2014-08-22 14:01:51,168 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) advanceStart: DeploymentPlan is provided, using dcId:1, podId: 1, clu sterId: 1, hostId: 48, poolId: null 2014-08-22 14:01:51,168 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Deploy avoids pods: null, clusters: null, hosts: null 2014-08-22 14:01:51,177 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Starting to Stopped with event: OperationFa iledvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,188 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Stopped to Starting with event: StartReques tedvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,189 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Successfully transitioned to start state for VM[User|VM-69b4c242-fcd1 -47ec-9afa-a798c370da5d] reservation id = 342cb1d2-fc32-4cdf-94c6-049cf16d5509 2014-08-22 14:01:51,191 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Trying to deploy VM, vm has dcId: 1 and podId: 1 2014-08-22 14:01:51,192 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) Deploy avoids pods: null, clusters: null, hosts: null 2014-08-22 14:01:51,198 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-87:ctx-17783fe6 ctx-7479eb99) VM state transitted from :Starting to Stopped with event: OperationFa iledvm's original host id: 48 new host id: null host id before state transition: null 2014-08-22 14:01:51,210 ERROR [cloud.api.ApiAsyncJobDispatcher] (Job-Executor-87:ctx-17783fe6) Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.StartVMCmd java.lang.NullPointerException at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:858) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:601) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:237) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:207) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3581) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2043) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at
[jira] [Commented] (CLOUDSTACK-5696) [Vmsync]- Stopped state of VM is not synced to CS when VM is stopped outside of CS.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229810#comment-14229810 ] Alireza Eskandari commented on CLOUDSTACK-5696: --- I build and test shapeblue patches on 4.3 until commit 0e0827f07c47289dc210dd50551c4c6df26d0573 but this bug is still exist. [Vmsync]- Stopped state of VM is not synced to CS when VM is stopped outside of CS. --- Key: CLOUDSTACK-5696 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5696 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: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: Kelven Yang Priority: Critical Fix For: 4.4.0 Attachments: management-server.rar Pre Req: Have few Vms deployed using Cloudstack. Steps: Outside of Cloudstack ,Stop VM Vm continues to remain in Running state in CS , even though the change in state is detected. Following exception seen in management server logs: 2013-12-26 17:02:10,026 DEBUG [c.c.v.VirtualMachineManagerImpl] (DirectAgent-77:ctx-c28d9506) VM i-3-8-MyTestVM: cs state = Running and realSt ate = Stopped 2013-12-26 17:02:10,027 DEBUG [c.c.v.VirtualMachineManagerImpl] (DirectAgent-77:ctx-c28d9506) VM i-3-8-MyTestVM: cs state = Running and realSt ate = Stopped 2013-12-26 17:02:10,027 DEBUG [c.c.h.HighAvailabilityManagerImpl] (DirectAgent-77:ctx-c28d9506) VM does not require investigation so I'm marki ng it as Stopped: VM[User|TestVM-tiny-host-1ps-0-1] 2013-12-26 17:02:10,027 WARN [o.a.c.alerts] (DirectAgent-77:ctx-c28d9506) alertType:: 8 // dataCenterId:: 1 // podId:: 1 // clusterId:: null // message:: VM (name: TestVM-tiny-host-1ps-0-1, id: 8) stopped unexpectedly on host id:1, availability zone id:1, pod id:1 2013-12-26 17:02:10,032 DEBUG [c.c.h.HighAvailabilityManagerImpl] (DirectAgent-77:ctx-c28d9506) VM is not HA enabled so we're done. 2013-12-26 17:02:10,032 WARN [c.c.a.m.DirectAgentAttache] (DirectAgent-77:ctx-c28d9506) Seq 1-799145986: Exception caught java.lang.NullPointerException at com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1235) at com.cloud.ha.HighAvailabilityManagerImpl.scheduleRestart(HighAvailabilityManagerImpl.java:346) at com.cloud.vm.VirtualMachineManagerImpl.compareState(VirtualMachineManagerImpl.java:2686) at com.cloud.vm.VirtualMachineManagerImpl.deltaSync(VirtualMachineManagerImpl.java:2320) at com.cloud.vm.VirtualMachineManagerImpl.processAnswers(VirtualMachineManagerImpl.java:2797) at com.cloud.agent.manager.AgentAttache.processAnswers(AgentAttache.java:296) at com.cloud.agent.manager.ClusteredDirectAgentAttache.processAnswers(ClusteredDirectAgentAttache.java:65) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:242) 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.innerRunAndReset(FutureTask.java:351) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7151) vmware: Type of vSwitch was not detected correctly while preparing public/guest virtual networks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Nalley updated CLOUDSTACK-7151: - Priority: Major (was: Blocker) vmware: Type of vSwitch was not detected correctly while preparing public/guest virtual networks Key: CLOUDSTACK-7151 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7151 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.3.0, 4.3.1 Environment: VMware ESXi 5.0 ACS 4.3.0 Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: 4.5.0 After upgrade to 4.3.0 from 4.2.0 system vms are not able to start. 2014-07-18 07:14:16,732 INFO [c.c.h.v.r.VmwareResource] (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) Prepare network on vmwaresvs Public_Guest_Net with name prefix: cloud.public 2014-07-18 07:14:16,778 ERROR [c.c.h.v.m.HypervisorHostHelper] (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) Unable to find vSwitchPublic_Guest_Net 2014-07-18 07:14:16,778 WARN [c.c.h.v.r.VmwareResource] (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) StartCommand failed due to Exception: java.lang.Exception Message: Unable to find vSwitchPublic_Guest_Net -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7151) vmware: Type of vSwitch was not detected correctly while preparing public/guest virtual networks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14229935#comment-14229935 ] David Nalley commented on CLOUDSTACK-7151: -- I am going to drop this as a blocker. We released 4.3.x and 4.4.x without this being an issue. It seems no one cares enough to fix it. vmware: Type of vSwitch was not detected correctly while preparing public/guest virtual networks Key: CLOUDSTACK-7151 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7151 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.3.0, 4.3.1 Environment: VMware ESXi 5.0 ACS 4.3.0 Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Priority: Blocker Fix For: 4.5.0 After upgrade to 4.3.0 from 4.2.0 system vms are not able to start. 2014-07-18 07:14:16,732 INFO [c.c.h.v.r.VmwareResource] (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) Prepare network on vmwaresvs Public_Guest_Net with name prefix: cloud.public 2014-07-18 07:14:16,778 ERROR [c.c.h.v.m.HypervisorHostHelper] (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) Unable to find vSwitchPublic_Guest_Net 2014-07-18 07:14:16,778 WARN [c.c.h.v.r.VmwareResource] (DirectAgent-348:ctx-7cf2f084 brvmc01-host01-vmw.vcore.host.net) StartCommand failed due to Exception: java.lang.Exception Message: Unable to find vSwitchPublic_Guest_Net -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7847) API: listDomains should display the domain resources, similar to listAccounts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14230039#comment-14230039 ] Logan B commented on CLOUDSTACK-7847: - Wei, Please makes sure to post the commit id here when ready. I'll be happy to test it, as we will need to pull this into our 4.5 deployment so we can display statistics to our customers without giant loop calls. API: listDomains should display the domain resources, similar to listAccounts - Key: CLOUDSTACK-7847 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7847 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Environment: CloudStack 4.4.0 w/ KVM Hypervisor on Ubuntu 14.04 LTS Reporter: Logan B Assignee: Wei Zhou Fix For: 4.6.0 Currently the listDomains call does not display any resource statistics. Since resources can be limited at the Domain level, it would make sense to have the listDomains call return the resource limit usage details the same way listAccounts does. I would suggest having it return the following details for the domain: - Max/Used IPs - Max/Used Templates - Max/Used Snapshots - Max/Used VPC - Max/Used Networks - Max/Used Memory - Max/Used Projects - Max/Used vCPU Count - Max/Used CPU Mhz (This may not actually be tracked by CloudStack) - Max/Used Primary Storage - Max/Used Secondary Storage - I may have missed some. This would make it much easier to pull statistics information for a domain, instead of having to use multiple other calls. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6945) Null pointer exception when starting a VM that had its template deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav closed CLOUDSTACK-6945. --- Resolution: Duplicate Assignee: Rohit Yadav Null pointer exception when starting a VM that had its template deleted --- Key: CLOUDSTACK-6945 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6945 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: Hosts are Debian 7.4.0 with Xen hypervisor e Xen Cloud Platform packages installed and properly configured. Reporter: Rafael Weingartner Assignee: Rohit Yadav Priority: Critical Fix For: 4.5.0, 4.4.3, 4.3.2 It seems that you have a bug in CS 4.3.0(and probably previous versions?) when starting a machine that was created from a template that has been deleted. There will happen a null pointer exception in com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart: “858 -if (volTemplateId != null volTemplateId.longValue() != template.getId())” The object, “template” is going to be null, because in: “811 - VirtualMachineTemplate template = _entityMgr.findById(VirtualMachineTemplate.class, vm.getTemplateId());” The findById, will add a where clause, looking for template that have the column removed that is null, therefore It will return a null object. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5696) [Vmsync]- Stopped state of VM is not synced to CS when VM is stopped outside of CS.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14230076#comment-14230076 ] Rohit Yadav commented on CLOUDSTACK-5696: - Hi [~alireza], I don't have VMWare setup; but I can test it against KVM. I've the logs and steps to reproduce, we'll fix it for 4.3 if I can reproduce it. Thanks for your help. [Vmsync]- Stopped state of VM is not synced to CS when VM is stopped outside of CS. --- Key: CLOUDSTACK-5696 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5696 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: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: Kelven Yang Priority: Critical Fix For: 4.4.0 Attachments: management-server.rar Pre Req: Have few Vms deployed using Cloudstack. Steps: Outside of Cloudstack ,Stop VM Vm continues to remain in Running state in CS , even though the change in state is detected. Following exception seen in management server logs: 2013-12-26 17:02:10,026 DEBUG [c.c.v.VirtualMachineManagerImpl] (DirectAgent-77:ctx-c28d9506) VM i-3-8-MyTestVM: cs state = Running and realSt ate = Stopped 2013-12-26 17:02:10,027 DEBUG [c.c.v.VirtualMachineManagerImpl] (DirectAgent-77:ctx-c28d9506) VM i-3-8-MyTestVM: cs state = Running and realSt ate = Stopped 2013-12-26 17:02:10,027 DEBUG [c.c.h.HighAvailabilityManagerImpl] (DirectAgent-77:ctx-c28d9506) VM does not require investigation so I'm marki ng it as Stopped: VM[User|TestVM-tiny-host-1ps-0-1] 2013-12-26 17:02:10,027 WARN [o.a.c.alerts] (DirectAgent-77:ctx-c28d9506) alertType:: 8 // dataCenterId:: 1 // podId:: 1 // clusterId:: null // message:: VM (name: TestVM-tiny-host-1ps-0-1, id: 8) stopped unexpectedly on host id:1, availability zone id:1, pod id:1 2013-12-26 17:02:10,032 DEBUG [c.c.h.HighAvailabilityManagerImpl] (DirectAgent-77:ctx-c28d9506) VM is not HA enabled so we're done. 2013-12-26 17:02:10,032 WARN [c.c.a.m.DirectAgentAttache] (DirectAgent-77:ctx-c28d9506) Seq 1-799145986: Exception caught java.lang.NullPointerException at com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1235) at com.cloud.ha.HighAvailabilityManagerImpl.scheduleRestart(HighAvailabilityManagerImpl.java:346) at com.cloud.vm.VirtualMachineManagerImpl.compareState(VirtualMachineManagerImpl.java:2686) at com.cloud.vm.VirtualMachineManagerImpl.deltaSync(VirtualMachineManagerImpl.java:2320) at com.cloud.vm.VirtualMachineManagerImpl.processAnswers(VirtualMachineManagerImpl.java:2797) at com.cloud.agent.manager.AgentAttache.processAnswers(AgentAttache.java:296) at com.cloud.agent.manager.ClusteredDirectAgentAttache.processAnswers(ClusteredDirectAgentAttache.java:65) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:242) 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.innerRunAndReset(FutureTask.java:351) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7995) Cloudstack user can create and manage shared networks in a simpler way
Luis Henrique Okama created CLOUDSTACK-7995: --- Summary: Cloudstack user can create and manage shared networks in a simpler way Key: CLOUDSTACK-7995 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7995 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: Automation, Management Server Affects Versions: Future Reporter: Luis Henrique Okama Fix For: 4.6.0 Originally in Cloudstack, only the root administrator is able to create shared networks, since it requires a full understanding of the topology to provide accurate information about the new shared network, e.g. IP range, netmask, gateway, VLAN ID and so on. GloboNetwork network plugin provides a much simpler way to create shared networks, allowing a regular Cloudstack user to create and manage shared networks by providing name, description and zone/environment in which he or she wants it to be deployed. This is possible thanks to an external open source API called GloboNetworkAPI. The open source 'GloboNetworkAPI' provides a simple way to manage multi-vendor network equipment, including routers, switches and load balancers. It is responsible for automatically creating and removing VLAN/networks, allocating and deallocating IP addresses, applying load balancer rules and many other features and is equipped with a web interface to easily manage all these resources. This proposal includes both the GloboNetwork plugin and the API client to greatly reduce complexity when dealing with shared networks and allow an external network hardware to act as router instead of a VirtualRouter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7283) Allow regular user to execute listUsers API call
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radhika Nair reassigned CLOUDSTACK-7283: Assignee: (was: Radhika Nair) Allow regular user to execute listUsers API call Key: CLOUDSTACK-7283 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7283 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API, Doc Affects Versions: 4.5.0 Reporter: Alena Prokharchyk Fix For: 4.5.0 Since normal-user role can have access to listAccounts API that returns user info + he can update users info by calling updateUser, he should have an access to listUsers API. The response should return his user info only. Other users belonging to the same user's account, shouldn't be returned. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7995) Cloudstack user can create and manage shared networks in a simpler way
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Henrique Okama updated CLOUDSTACK-7995: Description: Originally in Cloudstack, only the root administrator is able to create shared networks, since it requires a full understanding of the topology to provide accurate information about the new shared network, e.g. IP range, netmask, gateway, VLAN ID and so on. GloboNetwork network plugin provides a much simpler way to create shared networks, allowing a regular Cloudstack user to create and manage shared networks by providing name, description and zone/environment in which he or she wants it to be deployed. This is possible thanks to an external open source API called GloboNetworkAPI. The open source 'GloboNetworkAPI' provides a simple way to manage multi-vendor network equipment, including routers, switches and load balancers. It is responsible for automatically creating and removing VLAN/networks, allocating and deallocating IP addresses, applying load balancer rules and many other features and is equipped with a web interface to easily manage all these resources. This proposal includes both the GloboNetwork plugin and the API client to greatly reduce complexity when dealing with shared networks and allow an external network hardware to act as router instead of a VirtualRouter. Design Document: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Regular+cloudstack+user+can+create+and+manage+shared+networks+by+GloboNetwork+in+a+simpler+way was: Originally in Cloudstack, only the root administrator is able to create shared networks, since it requires a full understanding of the topology to provide accurate information about the new shared network, e.g. IP range, netmask, gateway, VLAN ID and so on. GloboNetwork network plugin provides a much simpler way to create shared networks, allowing a regular Cloudstack user to create and manage shared networks by providing name, description and zone/environment in which he or she wants it to be deployed. This is possible thanks to an external open source API called GloboNetworkAPI. The open source 'GloboNetworkAPI' provides a simple way to manage multi-vendor network equipment, including routers, switches and load balancers. It is responsible for automatically creating and removing VLAN/networks, allocating and deallocating IP addresses, applying load balancer rules and many other features and is equipped with a web interface to easily manage all these resources. This proposal includes both the GloboNetwork plugin and the API client to greatly reduce complexity when dealing with shared networks and allow an external network hardware to act as router instead of a VirtualRouter. Cloudstack user can create and manage shared networks in a simpler way -- Key: CLOUDSTACK-7995 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7995 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Management Server Affects Versions: Future Reporter: Luis Henrique Okama Labels: features, globonetwork Fix For: 4.6.0 Originally in Cloudstack, only the root administrator is able to create shared networks, since it requires a full understanding of the topology to provide accurate information about the new shared network, e.g. IP range, netmask, gateway, VLAN ID and so on. GloboNetwork network plugin provides a much simpler way to create shared networks, allowing a regular Cloudstack user to create and manage shared networks by providing name, description and zone/environment in which he or she wants it to be deployed. This is possible thanks to an external open source API called GloboNetworkAPI. The open source 'GloboNetworkAPI' provides a simple way to manage multi-vendor network equipment, including routers, switches and load balancers. It is responsible for automatically creating and removing VLAN/networks, allocating and deallocating IP addresses, applying load balancer rules and many other features and is equipped with a web interface to easily manage all these resources. This proposal includes both the GloboNetwork plugin and the API client to greatly reduce complexity when dealing with shared networks and allow an external network hardware to act as router instead of a VirtualRouter. Design Document: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Regular+cloudstack+user+can+create+and+manage+shared+networks+by+GloboNetwork+in+a+simpler+way -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7959) System VMs failing to build
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14230566#comment-14230566
]
Will Stevens commented on CLOUDSTACK-7959:
--
More discussion on this issue:
http://markmail.org/search/list:org.apache.incubator.cloudstack-*?q=05bec59c+-+kvm%2C+qcow%2C+systemvm+qemu-img+-o+compat#query:list%3Aorg.apache.incubator.cloudstack-*%2005bec59c%20-%20kvm%2C%20qcow%2C%20systemvm%20qemu-img%20-o%20compat+page:1+mid:4rw4y5wsvtikg27c+state:results
System VMs failing to build
---
Key: CLOUDSTACK-7959
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7959
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Affects Versions: Future, 4.5.0
Reporter: Will Stevens
Assignee: edison su
Fix For: Future
The system vm builds are failing on Jenkins for the '4.5' and 'master'
branches.
The reason they are failing is because of the following.
In file: tools/appliance/build.sh b/tools/appliance/build.sh
In function: kvm_export()
The line:
qemu-img convert -o compat=0.10 -f raw -c -O qcow2 raw.img
${appliance_build_name}-kvm.qcow2
Is throwing an unknown option 'compat' error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7996) [Automation] Fix the script test_tags.py - Tags and Template should belong to the User Account to test the case
Chandan Purushothama created CLOUDSTACK-7996: Summary: [Automation] Fix the script test_tags.py - Tags and Template should belong to the User Account to test the case Key: CLOUDSTACK-7996 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7996 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Chandan Purushothama Fix For: 4.5.0 Currently the tags and template belong to the Admin Account and not the User Account. Listing tags is being done as the regular User Account. This results in test case failure as no tags are returned to the regular User. Hence the inconsistency in creation of template, tags and listing them needs to be corrected for the test case to work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7990) Accessing cluster settings tab in UI is resulting in error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-7990: --- Assignee: Jessica Wang Accessing cluster settings tab in UI is resulting in error -- Key: CLOUDSTACK-7990 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7990 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Jessica Wang Fix For: 4.5.0 The operation is failing with following exception ERROR [c.c.a.ApiServer] (1979809623@qtp-985201577-10:ctx-eeef14ea ctx-7850f62e) unhandled exception executing api command: [Ljava.lang.String;@2db4a0cc java.lang.NullPointerException at com.cloud.server.ManagementServerImpl.searchForConfigurations(ManagementServerImpl.java:1712) 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.$Proxy227.searchForConfigurations(Unknown Source) at org.apache.cloudstack.api.command.admin.config.ListCfgsByCmd.execute(ListCfgsByCmd.java:132) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:691) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:514) at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:273) at com.cloud.api.ApiServlet$1.run(ApiServlet.java:117) 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.api.ApiServlet.processRequest(ApiServlet.java:114) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:76) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5920) CloudStack IAM Plugin feature
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen updated CLOUDSTACK-5920: - Fix Version/s: (was: 4.5.0) Future CloudStack IAM Plugin feature - Key: CLOUDSTACK-5920 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5920 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: API, Management Server Affects Versions: 4.3.0 Reporter: Prachi Damle Assignee: Prachi Damle Fix For: Future Currently CloudStack provides very limited IAM services and there are several drawbacks within those services: - Offers few roles out of the box (user and admin) with prebaked access control for these roles. There is no way to create additional roles with customized permissions. - Some resources have access control baked into them. E.g., shared networks, projects etc. - We have to create special dedicate APIs to grant permissions to resources. - Also it should be based on a plugin model to be possible to integrate with other RBAC implementations say using AD/LDAP in future Goal for this feature would be to address these limitations and offer true IAM services in a phased manner. As a first phase, we need to separate out the current access control into a separate component and create a standard access check mechanism to be used by the API layer. Also the read/listing APIs need to be refactored accordingly to consider the role based access granting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5398) Cloudstack network-element plugin to orchestrate Juniper's switches
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-5398: --- Fix Version/s: (was: 4.5.0) Future Cloudstack network-element plugin to orchestrate Juniper's switches --- Key: CLOUDSTACK-5398 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5398 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.4.0 Reporter: Pradeep H Krishnamurthy Labels: Juniper Fix For: Future Original Estimate: 504h Remaining Estimate: 504h This feature is about a Cloudstack network-element plugin to orchestrate Juniper's switches. As a first-cut, we are focussing on L2 services and we will write a NetworkGuru. As part of it's implement() method we will: (1)Create the required logical interfaces on the Juniper switches (EX,QFX) (2)Create the required VLANs on the Juniper switches (EX,QFX). (3)Configure VLAN membership on the interfaces Our customers need this plugin in Cloudstack deployments to automatically orchestrate the Juniper switches to create Virtual Networks. Without this plugin, there will be a manual intervention needed to configure the switches (after figuring out the current configuration of the switch). We have a Network Management Platform (called JUNOS SPACE) which is heavily used by customers to orchestrate Juniper's networking devices. It also exposes REST-ful APIs for integration with 3rdParty tools. The proposed Juniper's Cloudstack network-element plugin leverages these REST-ful APIs to appropriately orchestrate Juniper's switches to create Virtual Networks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5398) Cloudstack network-element plugin to orchestrate Juniper's switches
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14230663#comment-14230663 ] Animesh Chaturvedi commented on CLOUDSTACK-5398: Pradeep I haven't seen any commits for Contrail. Is this being worked on still? I will tag it for Future please pull in when you are starting work on it Cloudstack network-element plugin to orchestrate Juniper's switches --- Key: CLOUDSTACK-5398 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5398 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.4.0 Reporter: Pradeep H Krishnamurthy Labels: Juniper Fix For: Future Original Estimate: 504h Remaining Estimate: 504h This feature is about a Cloudstack network-element plugin to orchestrate Juniper's switches. As a first-cut, we are focussing on L2 services and we will write a NetworkGuru. As part of it's implement() method we will: (1)Create the required logical interfaces on the Juniper switches (EX,QFX) (2)Create the required VLANs on the Juniper switches (EX,QFX). (3)Configure VLAN membership on the interfaces Our customers need this plugin in Cloudstack deployments to automatically orchestrate the Juniper switches to create Virtual Networks. Without this plugin, there will be a manual intervention needed to configure the switches (after figuring out the current configuration of the switch). We have a Network Management Platform (called JUNOS SPACE) which is heavily used by customers to orchestrate Juniper's networking devices. It also exposes REST-ful APIs for integration with 3rdParty tools. The proposed Juniper's Cloudstack network-element plugin leverages these REST-ful APIs to appropriately orchestrate Juniper's switches to create Virtual Networks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7576) new nfs storage adapter for kvm hypervisor plugin to support managed storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14230669#comment-14230669 ] Animesh Chaturvedi commented on CLOUDSTACK-7576: @punith can you update the status of this feature ticket for 4.5. new nfs storage adapter for kvm hypervisor plugin to support managed storage. - Key: CLOUDSTACK-7576 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7576 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: punith Assignee: punith Fix For: 4.5.0 this adapter provides one to one mapping between the SAN volume to a VM's disk, so that it can guarantee the QoS for the performance sensitive applications. this adapter is based on nfs protocol. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7979) [Automation] Fix the script test_security_groups.py - Zone Network Type Information should to be passed to VirtualMachine create method
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chandan Purushothama updated CLOUDSTACK-7979: - Issue Type: Test (was: Bug) [Automation] Fix the script test_security_groups.py - Zone Network Type Information should to be passed to VirtualMachine create method - Key: CLOUDSTACK-7979 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7979 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Chandan Purushothama Priority: Critical Fix For: 4.5.0 Currently, test cases in the test suite do not pass the Zone Network Type to the Virtual Machine class create method. This doesn't cause any problem with majority of the configurations except EIP-ELB Configuration. Hence Zone Network Type Information should be passed consciously to the create method to cover EIP-ELB Configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7996) [Automation] Fix the script test_tags.py - Tags and Template should belong to the User Account to test the case
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chandan Purushothama updated CLOUDSTACK-7996: - Issue Type: Test (was: Bug) [Automation] Fix the script test_tags.py - Tags and Template should belong to the User Account to test the case - Key: CLOUDSTACK-7996 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7996 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Chandan Purushothama Fix For: 4.5.0 Currently the tags and template belong to the Admin Account and not the User Account. Listing tags is being done as the regular User Account. This results in test case failure as no tags are returned to the regular User. Hence the inconsistency in creation of template, tags and listing them needs to be corrected for the test case to work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7978) [Automation] Fix the script test_egress_rules.py - Zone Network Type Information should to be passed to VirtualMachine create method
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chandan Purushothama updated CLOUDSTACK-7978: - Issue Type: Test (was: Bug) [Automation] Fix the script test_egress_rules.py - Zone Network Type Information should to be passed to VirtualMachine create method -- Key: CLOUDSTACK-7978 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7978 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Chandan Purushothama Priority: Critical Fix For: 4.5.0 Currently, test cases in the test suite do not pass the Zone Network Type to the Virtual Machine class create method. This doesn't cause any problem with majority of the configurations except EIP-ELB Configuration. Hence Zone Network Type Information should be passed consciously to the create method to cover EIP-ELB Configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7980) [Automation] Fix the script maint/test_egress_rules_host_maintenance.py - Zone Network Type Information should to be passed to VirtualMachine create method
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chandan Purushothama updated CLOUDSTACK-7980: - Issue Type: Test (was: Bug) [Automation] Fix the script maint/test_egress_rules_host_maintenance.py - Zone Network Type Information should to be passed to VirtualMachine create method - Key: CLOUDSTACK-7980 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7980 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Chandan Purushothama Priority: Critical Fix For: 4.5.0 Currently, test cases in the test suite do not pass the Zone Network Type to the Virtual Machine class create method. This doesn't cause any problem with majority of the configurations except EIP-ELB Configuration. Hence Zone Network Type Information should be passed consciously to the create method to cover EIP-ELB Configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6972) VM snapshot not implemented in KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-6972: --- Fix Version/s: (was: 4.5.0) Future VM snapshot not implemented in KVM --- Key: CLOUDSTACK-6972 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6972 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: KVM, Snapshot Affects Versions: 4.5.0 Environment: KVM Reporter: Rayees Namathponnan Fix For: Future VM snapshot supported in VMware and Xen As per the attached conversation, relevant work already done and we are waiting for specific libvirt version, Creating this ticket to track this. Relevant threads: http://markmail.org/message/rxvnfeszqewly6wk and http://markmail.org/message/c3hkpxbad6ul4mza -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7997) [Automation] Deployment of VM is failing on Basic Zone in Few Cases - Unable to apply dhcp entry on router
Chandan Purushothama created CLOUDSTACK-7997:
Summary: [Automation] Deployment of VM is failing on Basic Zone in
Few Cases - Unable to apply dhcp entry on router
Key: CLOUDSTACK-7997
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7997
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
Fix For: 4.5.0
=
Unable to apply dhcp entry on router:
=
{noformat}
2014-12-01 18:57:12,396 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Asking VirtualRouter to prepare for
Nic[132-125-5e3877b8-7029-4029-be70-429a6e47d568-10.219.197.222]
2014-12-01 18:57:12,405 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Lock is acquired for network id 204 as a part of router
startup in
Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type--Pool(Id))]
: Dest[Zone(1)-Pod(1)-Cluster(1)-Host(2)-Storage(Volume(152|ROOT--Pool(1))]
2014-12-01 18:57:12,408 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Lock is released for network id 204 as a part of router
startup in
Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type--Pool(Id))]
: Dest[Zone(1)-Pod(1)-Cluster(1)-Host(2)-Storage(Volume(152|ROOT--Pool(1))]
2014-12-01 18:57:12,431 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Applying dhcp entry in network Ntwk[204|Guest|6]
2014-12-01 18:57:12,446 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Seq 2-1882786119217578814: Sending { Cmd , MgmtId:
195740251462904, via: 2(technetium), Ver: v1, Flags: 100011,
[{com.cloud.agent.api.routing.DhcpEntryCommand:{vmMac:06:26:ea:00:00:37,vmIpAddress:10.219.197.222,vmName:VM-2656bcb0-f793-4248-8256-1754ebe2c2ef,defaultRouter:10.219.192.1,defaultDns:10.219.197.221,duid:00:03:00:01:06:26:ea:00:00:37,isDefault:true,executeInSequence:false,accessDetails:{router.guest.ip:10.219.197.221,zone.network.type:Basic,router.name:r-4-VM,router.ip:169.254.3.164},wait:0}}]
}
2014-12-01 18:57:12,447 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Seq 2-1882786119217578814: Executing: { Cmd , MgmtId:
195740251462904, via: 2(technetium), Ver: v1, Flags: 100011,
[{com.cloud.agent.api.routing.DhcpEntryCommand:{vmMac:06:26:ea:00:00:37,vmIpAddress:10.219.197.222,vmName:VM-2656bcb0-f793-4248-8256-1754ebe2c2ef,defaultRouter:10.219.192.1,defaultDns:10.219.197.221,duid:00:03:00:01:06:26:ea:00:00:37,isDefault:true,executeInSequence:false,accessDetails:{router.guest.ip:10.219.197.221,zone.network.type:Basic,router.name:r-4-VM,router.ip:169.254.3.164},wait:0}}]
}
2014-12-01 18:57:12,447 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-239:ctx-e27e7d7a) (logid:312cfd5b) Seq 2-1882786119217578814:
Executing request
2014-12-01 18:57:12,447 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-239:ctx-e27e7d7a) (logid:a7cfe505) Executing command in VR:
/opt/cloud/bin/router_proxy.sh edithosts.sh 169.254.3.164 -m 06:26:ea:00:00:37
-4 10.219.197.222 -h VM-2656bcb0-f793-4248-8256-1754ebe2c2ef -d 10.219.192.1 -n
10.219.197.221
2014-12-01 18:57:12,448 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-239:ctx-e27e7d7a) (logid:a7cfe505) Seq 2-1882786119217578814:
Response Received:
2014-12-01 18:57:12,449 DEBUG [c.c.a.t.Request] (DirectAgent-239:ctx-e27e7d7a)
(logid:a7cfe505) Seq 2-1882786119217578814: Processing: { Ans: , MgmtId:
195740251462904, via: 2, Ver: v1, Flags: 10,
[{com.cloud.agent.api.Answer:{result:false,details:There was a problem
while connecting to 10.219.195.58:22,wait:0}}] }
2014-12-01 18:57:12,449 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Seq 2-1882786119217578814: Received: { Ans: , MgmtId:
195740251462904, via: 2, Ver: v1, Flags: 10, { Answer } }
2014-12-01 18:57:12,449 INFO [c.c.v.VirtualMachineManagerImpl]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Unable to contact resource.
com.cloud.exception.ResourceUnavailableException: Resource [Pod:1] is
unreachable: Unable to apply dhcp entry on router
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:4086)
at
[jira] [Updated] (CLOUDSTACK-7997) [Automation] Deployment of VM is failing on Basic Zone in Few Cases - Unable to apply dhcp entry on router
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chandan Purushothama updated CLOUDSTACK-7997:
-
Attachment: management-server.zip
[Automation] Deployment of VM is failing on Basic Zone in Few Cases - Unable
to apply dhcp entry on router
--
Key: CLOUDSTACK-7997
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7997
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
Fix For: 4.5.0
Attachments: management-server.zip
=
Unable to apply dhcp entry on router:
=
{noformat}
2014-12-01 18:57:12,396 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Asking VirtualRouter to prepare for
Nic[132-125-5e3877b8-7029-4029-be70-429a6e47d568-10.219.197.222]
2014-12-01 18:57:12,405 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Lock is acquired for network id 204 as a part of router
startup in
Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type--Pool(Id))]
: Dest[Zone(1)-Pod(1)-Cluster(1)-Host(2)-Storage(Volume(152|ROOT--Pool(1))]
2014-12-01 18:57:12,408 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Lock is released for network id 204 as a part of router
startup in
Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type--Pool(Id))]
: Dest[Zone(1)-Pod(1)-Cluster(1)-Host(2)-Storage(Volume(152|ROOT--Pool(1))]
2014-12-01 18:57:12,431 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Applying dhcp entry in network Ntwk[204|Guest|6]
2014-12-01 18:57:12,446 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Seq 2-1882786119217578814: Sending { Cmd , MgmtId:
195740251462904, via: 2(technetium), Ver: v1, Flags: 100011,
[{com.cloud.agent.api.routing.DhcpEntryCommand:{vmMac:06:26:ea:00:00:37,vmIpAddress:10.219.197.222,vmName:VM-2656bcb0-f793-4248-8256-1754ebe2c2ef,defaultRouter:10.219.192.1,defaultDns:10.219.197.221,duid:00:03:00:01:06:26:ea:00:00:37,isDefault:true,executeInSequence:false,accessDetails:{router.guest.ip:10.219.197.221,zone.network.type:Basic,router.name:r-4-VM,router.ip:169.254.3.164},wait:0}}]
}
2014-12-01 18:57:12,447 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Seq 2-1882786119217578814: Executing: { Cmd , MgmtId:
195740251462904, via: 2(technetium), Ver: v1, Flags: 100011,
[{com.cloud.agent.api.routing.DhcpEntryCommand:{vmMac:06:26:ea:00:00:37,vmIpAddress:10.219.197.222,vmName:VM-2656bcb0-f793-4248-8256-1754ebe2c2ef,defaultRouter:10.219.192.1,defaultDns:10.219.197.221,duid:00:03:00:01:06:26:ea:00:00:37,isDefault:true,executeInSequence:false,accessDetails:{router.guest.ip:10.219.197.221,zone.network.type:Basic,router.name:r-4-VM,router.ip:169.254.3.164},wait:0}}]
}
2014-12-01 18:57:12,447 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-239:ctx-e27e7d7a) (logid:312cfd5b) Seq 2-1882786119217578814:
Executing request
2014-12-01 18:57:12,447 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-239:ctx-e27e7d7a) (logid:a7cfe505) Executing command in VR:
/opt/cloud/bin/router_proxy.sh edithosts.sh 169.254.3.164 -m
06:26:ea:00:00:37 -4 10.219.197.222 -h
VM-2656bcb0-f793-4248-8256-1754ebe2c2ef -d 10.219.192.1 -n 10.219.197.221
2014-12-01 18:57:12,448 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-239:ctx-e27e7d7a) (logid:a7cfe505) Seq 2-1882786119217578814:
Response Received:
2014-12-01 18:57:12,449 DEBUG [c.c.a.t.Request]
(DirectAgent-239:ctx-e27e7d7a) (logid:a7cfe505) Seq 2-1882786119217578814:
Processing: { Ans: , MgmtId: 195740251462904, via: 2, Ver: v1, Flags: 10,
[{com.cloud.agent.api.Answer:{result:false,details:There was a problem
while connecting to 10.219.195.58:22,wait:0}}] }
2014-12-01 18:57:12,449 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Seq 2-1882786119217578814: Received: { Ans: , MgmtId:
195740251462904, via: 2, Ver: v1, Flags: 10, { Answer } }
2014-12-01 18:57:12,449 INFO [c.c.v.VirtualMachineManagerImpl]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Unable
[jira] [Updated] (CLOUDSTACK-7997) [Automation] Deployment of VM is failing on Basic Zone in Few Cases - Unable to apply dhcp entry on router
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chandan Purushothama updated CLOUDSTACK-7997:
-
Description:
VM Deployment failure occurred multiple times. Posting the details from one
such occurrence below:
=
Unable to apply dhcp entry on router:
=
{noformat}
2014-12-01 18:57:12,396 DEBUG [o.a.c.e.o.NetworkOrchestrator]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Asking VirtualRouter to prepare for
Nic[132-125-5e3877b8-7029-4029-be70-429a6e47d568-10.219.197.222]
2014-12-01 18:57:12,405 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Lock is acquired for network id 204 as a part of router
startup in
Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type--Pool(Id))]
: Dest[Zone(1)-Pod(1)-Cluster(1)-Host(2)-Storage(Volume(152|ROOT--Pool(1))]
2014-12-01 18:57:12,408 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Lock is released for network id 204 as a part of router
startup in
Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type--Pool(Id))]
: Dest[Zone(1)-Pod(1)-Cluster(1)-Host(2)-Storage(Volume(152|ROOT--Pool(1))]
2014-12-01 18:57:12,431 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Applying dhcp entry in network Ntwk[204|Guest|6]
2014-12-01 18:57:12,446 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Seq 2-1882786119217578814: Sending { Cmd , MgmtId:
195740251462904, via: 2(technetium), Ver: v1, Flags: 100011,
[{com.cloud.agent.api.routing.DhcpEntryCommand:{vmMac:06:26:ea:00:00:37,vmIpAddress:10.219.197.222,vmName:VM-2656bcb0-f793-4248-8256-1754ebe2c2ef,defaultRouter:10.219.192.1,defaultDns:10.219.197.221,duid:00:03:00:01:06:26:ea:00:00:37,isDefault:true,executeInSequence:false,accessDetails:{router.guest.ip:10.219.197.221,zone.network.type:Basic,router.name:r-4-VM,router.ip:169.254.3.164},wait:0}}]
}
2014-12-01 18:57:12,447 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Seq 2-1882786119217578814: Executing: { Cmd , MgmtId:
195740251462904, via: 2(technetium), Ver: v1, Flags: 100011,
[{com.cloud.agent.api.routing.DhcpEntryCommand:{vmMac:06:26:ea:00:00:37,vmIpAddress:10.219.197.222,vmName:VM-2656bcb0-f793-4248-8256-1754ebe2c2ef,defaultRouter:10.219.192.1,defaultDns:10.219.197.221,duid:00:03:00:01:06:26:ea:00:00:37,isDefault:true,executeInSequence:false,accessDetails:{router.guest.ip:10.219.197.221,zone.network.type:Basic,router.name:r-4-VM,router.ip:169.254.3.164},wait:0}}]
}
2014-12-01 18:57:12,447 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-239:ctx-e27e7d7a) (logid:312cfd5b) Seq 2-1882786119217578814:
Executing request
2014-12-01 18:57:12,447 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-239:ctx-e27e7d7a) (logid:a7cfe505) Executing command in VR:
/opt/cloud/bin/router_proxy.sh edithosts.sh 169.254.3.164 -m 06:26:ea:00:00:37
-4 10.219.197.222 -h VM-2656bcb0-f793-4248-8256-1754ebe2c2ef -d 10.219.192.1 -n
10.219.197.221
2014-12-01 18:57:12,448 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-239:ctx-e27e7d7a) (logid:a7cfe505) Seq 2-1882786119217578814:
Response Received:
2014-12-01 18:57:12,449 DEBUG [c.c.a.t.Request] (DirectAgent-239:ctx-e27e7d7a)
(logid:a7cfe505) Seq 2-1882786119217578814: Processing: { Ans: , MgmtId:
195740251462904, via: 2, Ver: v1, Flags: 10,
[{com.cloud.agent.api.Answer:{result:false,details:There was a problem
while connecting to 10.219.195.58:22,wait:0}}] }
2014-12-01 18:57:12,449 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Seq 2-1882786119217578814: Received: { Ans: , MgmtId:
195740251462904, via: 2, Ver: v1, Flags: 10, { Answer } }
2014-12-01 18:57:12,449 INFO [c.c.v.VirtualMachineManagerImpl]
(Work-Job-Executor-98:ctx-eb573b61 job-1170/job-1171 ctx-4477fe15)
(logid:a7cfe505) Unable to contact resource.
com.cloud.exception.ResourceUnavailableException: Resource [Pod:1] is
unreachable: Unable to apply dhcp entry on router
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:4086)
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyDhcpEntry(VirtualNetworkApplianceManagerImpl.java:3205)
at sun.reflect.GeneratedMethodAccessor399.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
[jira] [Created] (CLOUDSTACK-7998) [Automation] Fix the script test_escalations_instances.py - Root Volume should not be attempted to be detached
Chandan Purushothama created CLOUDSTACK-7998:
Summary: [Automation] Fix the script
test_escalations_instances.py - Root Volume should not be attempted to be
detached
Key: CLOUDSTACK-7998
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7998
Project: CloudStack
Issue Type: Test
Security Level: Public (Anyone can view this level - this is the default.)
Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Gaurav Aradhye
Priority: Critical
Fix For: 4.5.0
*Error Message*
Job failed: {jobprocstatus : 0, created : u'2014-12-01T17:59:17+',
jobresult : {errorcode : 431, errortext : u'Please specify volume of type
DATADISK'}, cmd :
u'org.apache.cloudstack.api.command.user.volume.DetachVolumeCmd', userid :
u'9afd35fa-9da4-496c-a47c-e5980b43fe09', jobstatus : 2, jobid :
u'1e3322a3-6ae1-475c-b2b3-4656127edfa4', jobresultcode : 530, jobinstanceid :
u'1415198d-15d9-4063-bc2f-234c964237d9', jobresulttype : u'object',
jobinstancetype : u'Volume', accountid :
u'09e327b9-628b-4993-b850-124fa1a0554e'}
*Stacktrace*
File /usr/lib/python2.7/unittest/case.py, line 332, in run
testMethod()
File
/root/cloudstack/test/integration/component/test_escalations_instances.py,
line 2866, in test_16_list_vm_volumes_pagination
list_volumes_page1[i]
File /usr/local/lib/python2.7/dist-packages/marvin/lib/base.py, line 665,
in detach_volume
return apiclient.detachVolume(cmd)
File
/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
line 1686, in detachVolume
response = self.connection.marvinRequest(command, response_type=response,
method=method)
File /usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py,
line 379, in marvinRequest
raise e
'Job failed: {jobprocstatus : 0, created : u\'2014-12-01T17:59:17+\',
jobresult : {errorcode : 431, errortext : u\'Please specify volume of type
DATADISK\'}, cmd :
u\'org.apache.cloudstack.api.command.user.volume.DetachVolumeCmd\', userid :
u\'9afd35fa-9da4-496c-a47c-e5980b43fe09\', jobstatus : 2, jobid :
u\'1e3322a3-6ae1-475c-b2b3-4656127edfa4\', jobresultcode : 530, jobinstanceid :
u\'1415198d-15d9-4063-bc2f-234c964237d9\', jobresulttype : u\'object\',
jobinstancetype : u\'Volume\', accountid :
u\'09e327b9-628b-4993-b850-124fa1a0554e\'}\n
=
Test script Code:
=
{code}
@attr(tags=[advanced, basic], required_hardware=false)
def test_16_list_vm_volumes_pagination(self):
.
.
.
# Listing all the volumes for a VM again in page 1
list_volumes_page1 = Volume.list(
self.userapiclient,
listall=self.services[listall],
virtualmachineid=vm_created.id,
page=1,
pagesize=self.services[pagesize]
)
status = validateList(list_volumes_page1)
self.assertEquals(
PASS,
status[0],
Volumes not listed in page1
)
# Verifying that list size is equal to page size
self.assertEquals(
self.services[pagesize],
len(list_volumes_page1),
VM's volume count is not matching in page 1
)
# stopping VM before detaching volumes
vm_created.stop(self.userapiclient)
# Detaching root volume is allowed on XenServer only
if self.hypervisor.lower() == 'xenserver':
# Detaching all the volumes attached from VM
for i in range(0, len(list_volumes_page1)):
vm_created.detach_volume(
self.userapiclient,
list_volumes_page1[i]
)
return
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7968) [Automation] ListVirtualMachines failed due to NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen resolved CLOUDSTACK-7968.
--
Resolution: Incomplete
[Automation] ListVirtualMachines failed due to NPE
--
Key: CLOUDSTACK-7968
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7968
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Min Chen
Priority: Critical
Fix For: 4.5.0
==
NullPointer Exception:
==
{noformat}
2014-11-25 07:02:04,577 DEBUG [c.c.a.ApiServlet]
(catalina-exec-22:ctx-3c4583df) ===START=== 10.220.135.158 -- GET
apiKey=cZnc5GpyJx80LGvhVhQMwdCSfoIyzyVRq1F4lRjI00w1xrAgCOTAZWpxgtARH_JNID8RSYjGnJalpQcy5u1Xfgcommand=listVirtualMachinessignature=5T4zh0Tv4tnLOFRwNn8DRghnJkA%3Dtags%5B0%5D.key=region111response=jsonlistall=Truetags%5B0%5D.value=India
2014-11-25 07:02:04,600 ERROR [c.c.a.ApiServer]
(catalina-exec-22:ctx-3c4583df ctx-8f125542 ctx-2cc1f4d0) unhandled exception
executing api command: [Ljava.lang.String;@7bf2b28
com.cloud.utils.exception.CloudRuntimeException: Caught:
com.mysql.jdbc.JDBC4PreparedStatement@235185cf: SELECT
DISTINCT(user_vm_view.id) FROM user_vm_view WHERE user_vm_view.account_type
!= 5 AND user_vm_view.display_vm = 1 AND ( ( AND ) ) AND
user_vm_view.removed IS NULL ORDER BY user_vm_view.id ASC LIMIT 0, 1
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:427)
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:361)
at com.cloud.utils.db.GenericDaoBase.search(GenericDaoBase.java:345)
at
com.cloud.utils.db.GenericDaoBase.searchAndCount(GenericDaoBase.java:1296)
at sun.reflect.GeneratedMethodAccessor132.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy175.searchAndCount(Unknown Source)
at
com.cloud.api.query.QueryManagerImpl.searchForUserVMsInternal(QueryManagerImpl.java:996)
at
com.cloud.api.query.QueryManagerImpl.searchForUserVMs(QueryManagerImpl.java:756)
at
org.apache.cloudstack.api.command.user.vm.ListVMsCmd.execute(ListVMsCmd.java:227)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:691)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:514)
at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:276)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:120)
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.api.ApiServlet.processRequest(ApiServlet.java:117)
at com.cloud.api.ApiServlet.doGet(ApiServlet.java:79)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
[jira] [Commented] (CLOUDSTACK-7968) [Automation] ListVirtualMachines failed due to NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14230796#comment-14230796
]
Min Chen commented on CLOUDSTACK-7968:
--
Please attach the db dump for investigation.
[Automation] ListVirtualMachines failed due to NPE
--
Key: CLOUDSTACK-7968
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7968
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Min Chen
Priority: Critical
Fix For: 4.5.0
==
NullPointer Exception:
==
{noformat}
2014-11-25 07:02:04,577 DEBUG [c.c.a.ApiServlet]
(catalina-exec-22:ctx-3c4583df) ===START=== 10.220.135.158 -- GET
apiKey=cZnc5GpyJx80LGvhVhQMwdCSfoIyzyVRq1F4lRjI00w1xrAgCOTAZWpxgtARH_JNID8RSYjGnJalpQcy5u1Xfgcommand=listVirtualMachinessignature=5T4zh0Tv4tnLOFRwNn8DRghnJkA%3Dtags%5B0%5D.key=region111response=jsonlistall=Truetags%5B0%5D.value=India
2014-11-25 07:02:04,600 ERROR [c.c.a.ApiServer]
(catalina-exec-22:ctx-3c4583df ctx-8f125542 ctx-2cc1f4d0) unhandled exception
executing api command: [Ljava.lang.String;@7bf2b28
com.cloud.utils.exception.CloudRuntimeException: Caught:
com.mysql.jdbc.JDBC4PreparedStatement@235185cf: SELECT
DISTINCT(user_vm_view.id) FROM user_vm_view WHERE user_vm_view.account_type
!= 5 AND user_vm_view.display_vm = 1 AND ( ( AND ) ) AND
user_vm_view.removed IS NULL ORDER BY user_vm_view.id ASC LIMIT 0, 1
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:427)
at
com.cloud.utils.db.GenericDaoBase.searchIncludingRemoved(GenericDaoBase.java:361)
at com.cloud.utils.db.GenericDaoBase.search(GenericDaoBase.java:345)
at
com.cloud.utils.db.GenericDaoBase.searchAndCount(GenericDaoBase.java:1296)
at sun.reflect.GeneratedMethodAccessor132.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy175.searchAndCount(Unknown Source)
at
com.cloud.api.query.QueryManagerImpl.searchForUserVMsInternal(QueryManagerImpl.java:996)
at
com.cloud.api.query.QueryManagerImpl.searchForUserVMs(QueryManagerImpl.java:756)
at
org.apache.cloudstack.api.command.user.vm.ListVMsCmd.execute(ListVMsCmd.java:227)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:691)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:514)
at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:276)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:120)
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.api.ApiServlet.processRequest(ApiServlet.java:117)
at com.cloud.api.ApiServlet.doGet(ApiServlet.java:79)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
[jira] [Created] (CLOUDSTACK-7999) Local keystore file may override the entry in DB
Sheng Yang created CLOUDSTACK-7999: -- Summary: Local keystore file may override the entry in DB Key: CLOUDSTACK-7999 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7999 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Sheng Yang Assignee: Sheng Yang Priority: Critical The DB should have priority on keystore entry if both DB and keystore file existed. Because it would contain up the date keystore entry and can be shared across mgmt server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7999) Local keystore file may override the entry in DB
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang updated CLOUDSTACK-7999: --- Fix Version/s: 4.5.0 Local keystore file may override the entry in DB Key: CLOUDSTACK-7999 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7999 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Sheng Yang Assignee: Sheng Yang Priority: Critical Fix For: 4.5.0 The DB should have priority on keystore entry if both DB and keystore file existed. Because it would contain up the date keystore entry and can be shared across mgmt server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8000) Keystore file corrupted after upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang updated CLOUDSTACK-8000: --- Description: The keystore file may corrupted after upgrade, result in agent failed to connect. We've seen several cases for this issue. was:The keystore file may corrupted after upgrade, result in agent failed to connect. Keystore file corrupted after upgrade - Key: CLOUDSTACK-8000 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8000 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Sheng Yang Assignee: Sheng Yang Priority: Critical The keystore file may corrupted after upgrade, result in agent failed to connect. We've seen several cases for this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8000) Keystore file corrupted after upgrade
Sheng Yang created CLOUDSTACK-8000: -- Summary: Keystore file corrupted after upgrade Key: CLOUDSTACK-8000 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8000 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Sheng Yang Assignee: Sheng Yang Priority: Critical The keystore file may corrupted after upgrade, result in agent failed to connect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8000) Keystore file corrupted after upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14230894#comment-14230894 ] Sheng Yang commented on CLOUDSTACK-8000: This may be caused by CLOUDSTACK-7999, but there is no proven. Open this bug for tracking. Keystore file corrupted after upgrade - Key: CLOUDSTACK-8000 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8000 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Sheng Yang Assignee: Sheng Yang Priority: Critical The keystore file may corrupted after upgrade, result in agent failed to connect. We've seen several cases for this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7999) Local keystore file may override the entry in DB
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14230898#comment-14230898 ] ASF subversion and git services commented on CLOUDSTACK-7999: - Commit 77c88fa917917fde2a4533ffdf7b6219cc79f081 in cloudstack's branch refs/heads/master from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=77c88fa ] CLOUDSTACK-7999: Always override local keystore file with the entry in DB Local keystore file may override the entry in DB Key: CLOUDSTACK-7999 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7999 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Sheng Yang Assignee: Sheng Yang Priority: Critical Fix For: 4.5.0 The DB should have priority on keystore entry if both DB and keystore file existed. Because it would contain up the date keystore entry and can be shared across mgmt server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7999) Local keystore file may override the entry in DB
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14230896#comment-14230896 ] ASF subversion and git services commented on CLOUDSTACK-7999: - Commit c987080c266f4ddb973736a3beb2bf2b07f287b0 in cloudstack's branch refs/heads/4.5 from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c987080 ] CLOUDSTACK-7999: Always override local keystore file with the entry in DB Local keystore file may override the entry in DB Key: CLOUDSTACK-7999 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7999 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Sheng Yang Assignee: Sheng Yang Priority: Critical Fix For: 4.5.0 The DB should have priority on keystore entry if both DB and keystore file existed. Because it would contain up the date keystore entry and can be shared across mgmt server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7999) Local keystore file may override the entry in DB
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang resolved CLOUDSTACK-7999. Resolution: Fixed Local keystore file may override the entry in DB Key: CLOUDSTACK-7999 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7999 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Sheng Yang Assignee: Sheng Yang Priority: Critical Fix For: 4.5.0 The DB should have priority on keystore entry if both DB and keystore file existed. Because it would contain up the date keystore entry and can be shared across mgmt server. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7994) Network rules are not configured in VR after out-of-band movement due to host crash
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14230934#comment-14230934 ] Koushik Das commented on CLOUDSTACK-7994: - [~rohit.ya...@shapeblue.com] You can cherry-pick it to the required branches. I currently don't have a 4.3/4.4 setup to verify the changes. Network rules are not configured in VR after out-of-band movement due to host crash --- Key: CLOUDSTACK-7994 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7994 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, VMware Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.5.0 This is specific to Vmware. If VR is moved out-of-band from one host to another then the configured network rules are lost. In order to re-configure VR with the rules it needs to be rebooted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6144) HA for guest VMs running Hyper-V
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Devdeep Singh updated CLOUDSTACK-6144: -- Fix Version/s: (was: 4.5.0) Future HA for guest VMs running Hyper-V Key: CLOUDSTACK-6144 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6144 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.4.0 Reporter: Rajesh Battala Fix For: Future -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6109) Support of iSCSI as primary store in Hyper-V
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Devdeep Singh updated CLOUDSTACK-6109: -- Fix Version/s: (was: 4.5.0) Future Support of iSCSI as primary store in Hyper-V Key: CLOUDSTACK-6109 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6109 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Devdeep Singh Fix For: Future -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6109) Support of iSCSI as primary store in Hyper-V
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14230974#comment-14230974 ] Devdeep Singh commented on CLOUDSTACK-6109: --- I'll try to bring it in 4.6 release. Support of iSCSI as primary store in Hyper-V Key: CLOUDSTACK-6109 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6109 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Devdeep Singh Fix For: Future -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5997) Template state changes side affects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231017#comment-14231017 ] Nitin Mehta commented on CLOUDSTACK-5997: - [~bhaisaab] I was on leave so couldnt respond to your earlier. Unfortunately I am stuck in my dollar day job so wont be able to do it. If you can port these changes or have questions around them please feel free to ask. Template state changes side affects --- Key: CLOUDSTACK-5997 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5997 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Fix For: 4.4.0 Template state change functionality. A state has been introduced for vm_template. It reflects the user action for making template active/inactive for further use. When the template is marked inactive it becomes unusable for the entire cloud. If the user wants to make it as inactive for a particular zone, template_zone_ref would be accordingly reflected. Admin listing should still be able to see the inactive templates. The intent of the removed flag is to capture the system state meaning whether it has been physically removed from the cloud. The garbage collection thread checks the inactive state of the template and deletes it physically from sec. storage when no vm is referencing this template anymore. It also deletes it from PS. This is when the removed flag is set in the vm_template table. At the moment this functionality doesn't exist in CS so the removed flag is never set as of now. Things that need to be fixed Deleting the template by user for a particular zone should mark the removed flag in template zone ref only. It should mark the template as inactive if its there is no other zone carrying it. Deleting the template without any zone should mark it as inactive right away. Removed flag is not set and there shouldn't be any code setting it at the moment (Delete template shouldn't mark the removed flag.) Start showing the state in the api. Regular users should see only active templates but admins should be able to see active/inactive templates Template Sync. Should start using active/inactive state than the removed flag. Show removed functionality introduced for CPBM would be fixed automatically when admin sees the inactive state - Any template code referencing the removed flag from vm_template should use the active/inactive flag. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7789) I was updated from version 4.4.0 of Apache CloudStack to 4.4.1. It does not work correctly. (404 error of WebGUI)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231115#comment-14231115 ] Morten Blixter commented on CLOUDSTACK-7789: I had the exact same problem and adding the extra row to the database as described by Satoru solved the error. Thank you. I was updated from version 4.4.0 of Apache CloudStack to 4.4.1. It does not work correctly. (404 error of WebGUI) - Key: CLOUDSTACK-7789 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7789 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.1 Environment: CentOS6.4 Reporter: satoru nakaya I was updated from version 4.4.0 of Apache CloudStack to 4.4.1. It does not work correctly. (404 error of WebGUI) From # rpm -qa | grep cloudstack cloudstack-awsapi-4.4.0-NONOSS_3.el6.x86_64 cloudstack-common-4.4.0-NONOSS_3.el6.x86_64 cloudstack-management-4.4.0-NONOSS_3.el6.x86_64 # To # rpm -qa | grep cloudstack cloudstack-common-4.4.1-NONOSS_3.el6.x86_64 cloudstack-awsapi-4.4.1-NONOSS_3.el6.x86_64 cloudstack-management-4.4.1-NONOSS_3.el6.x86_64 # # tail -f /var/log/cloudstack/management/management-server.log : 014-10-26 11:40:55,432 INFO [c.c.u.c.ComponentContext] (main:null) Starting com.cloud.bridge.persist.dao.CloudStackSvcOfferingDaoImpl_EnhancerByCloudStack_8e883789 2014-10-26 11:40:55,433 INFO [c.c.u.c.ComponentContext] (main:null) Starting com.cloud.bridge.persist.dao.SHostDaoImpl_EnhancerByCloudStack_3055f1c1 2014-10-26 11:40:55,433 INFO [c.c.u.c.ComponentContext] (main:null) Starting com.cloud.bridge.persist.dao.SObjectDaoImpl_EnhancerByCloudStack_173061b2 2014-10-26 11:40:55,434 INFO [c.c.u.c.ComponentContext] (main:null) Starting com.cloud.bridge.persist.dao.CloudStackUserDaoImpl_EnhancerByCloudStack_127ee70c 2014-10-26 11:40:55,434 INFO [c.c.u.c.ComponentContext] (main:null) Starting com.cloud.bridge.service.core.ec2.EC2Engine_EnhancerByCloudStack_69bd4662 2014-10-26 11:40:55,434 INFO [c.c.u.c.ComponentContext] (main:null) Starting com.cloud.bridge.service.controller.s3.ServiceProvider_EnhancerByCloudStack_94ede0d7 This subsequent log is not output. # cat /var/log/cloudstack/management/catalina.out : Exception in thread CapacityChecker java.lang.NullPointerException at org.slf4j.impl.Log4jLoggerAdapter.info(Log4jLoggerAdapter.java:304) at org.apache.cloudstack.managed.context.ManagedContextRunnable.getContext(ManagedContextRunnable.java:66) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at org.apache.cloudstack.managed.context.ManagedContextTimerTask.run(ManagedContextTimerTask.java:27) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) Exception in thread Timer-1 java.lang.NullPointerException at org.slf4j.impl.Log4jLoggerAdapter.info(Log4jLoggerAdapter.java:304) at org.apache.cloudstack.managed.context.ManagedContextRunnable.getContext(ManagedContextRunnable.java:66) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at org.apache.cloudstack.managed.context.ManagedContextTimerTask.run(ManagedContextTimerTask.java:27) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) Exception in thread HA-Worker-1 java.lang.NullPointerException at org.slf4j.impl.Log4jLoggerAdapter.error(Log4jLoggerAdapter.java:538) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:117) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.run(HighAvailabilityManagerImpl.java:857) Exception in thread HA-Worker-4 java.lang.NullPointerException at org.slf4j.impl.Log4jLoggerAdapter.error(Log4jLoggerAdapter.java:538) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:117) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.run(HighAvailabilityManagerImpl.java:857) Exception in thread HA-Worker-3 java.lang.NullPointerException at org.slf4j.impl.Log4jLoggerAdapter.error(Log4jLoggerAdapter.java:538) at
[jira] [Resolved] (CLOUDSTACK-7576) new nfs storage adapter for kvm hypervisor plugin to support managed storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] punith resolved CLOUDSTACK-7576. Resolution: Fixed new nfs storage adapter for kvm hypervisor plugin to support managed storage. - Key: CLOUDSTACK-7576 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7576 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: punith Assignee: punith Fix For: 4.5.0 this adapter provides one to one mapping between the SAN volume to a VM's disk, so that it can guarantee the QoS for the performance sensitive applications. this adapter is based on nfs protocol. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7576) new nfs storage adapter for kvm hypervisor plugin to support managed storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14231116#comment-14231116 ] punith commented on CLOUDSTACK-7576: thanks animesh, i have resolved it now. new nfs storage adapter for kvm hypervisor plugin to support managed storage. - Key: CLOUDSTACK-7576 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7576 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: punith Assignee: punith Fix For: 4.5.0 this adapter provides one to one mapping between the SAN volume to a VM's disk, so that it can guarantee the QoS for the performance sensitive applications. this adapter is based on nfs protocol. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
