[jira] [Commented] (CLOUDSTACK-2327) cloudstack-setup-agent does not properly detect openvswitch and fails if the brcompat driver is not loaded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667519#comment-13667519 ] ASF subversion and git services commented on CLOUDSTACK-2327: - Commit a16b707250fde01f24c9ab6f11189b630dd70962 in branch refs/heads/master from Hiroaki KAWAI [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a16b707 ] CLOUDSTACK-2327: make cloud-setup-agent ovs aware Ovs brcompat will be obsolete, so if network.bridge.type was set to openvswitch, we'll use ovs command explicitly. Signed-off-by: Hiroaki KAWAI > cloudstack-setup-agent does not properly detect openvswitch and fails if the > brcompat driver is not loaded > -- > > Key: CLOUDSTACK-2327 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2327 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.1.0 >Reporter: Hugo Trippaers >Assignee: Hugo Trippaers > > isBridge fails in the networking configuration is brcompat is not loaded. > Cloudstack-setup-agent should have a parameter that specifies if you want to > use traditional bridge or openvswitch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2327) cloudstack-setup-agent does not properly detect openvswitch and fails if the brcompat driver is not loaded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667517#comment-13667517 ] ASF subversion and git services commented on CLOUDSTACK-2327: - Commit 8faf845889b28157a2ecbd6e406d73a326b27756 in branch refs/heads/4.1 from Hiroaki KAWAI [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8faf845 ] CLOUDSTACK-2327: make cloud-setup-agent ovs aware Ovs brcompat will be obsolete, so if network.bridge.type was set to openvswitch, we'll use ovs command explicitly. Signed-off-by: Hiroaki KAWAI > cloudstack-setup-agent does not properly detect openvswitch and fails if the > brcompat driver is not loaded > -- > > Key: CLOUDSTACK-2327 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2327 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.1.0 >Reporter: Hugo Trippaers >Assignee: Hugo Trippaers > > isBridge fails in the networking configuration is brcompat is not loaded. > Cloudstack-setup-agent should have a parameter that specifies if you want to > use traditional bridge or openvswitch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2686) Upload volume to project is not shown in project storage view
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667524#comment-13667524
]
ASF subversion and git services commented on CLOUDSTACK-2686:
-
Commit cc2866c1ea2c778d434e416f8a7183bd3c10c518 in branch refs/heads/master
from [~mice]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cc2866c ]
CLOUDSTACK-2686 Upload volume to project is not shown in project storage view
> Upload volume to project is not shown in project storage view
> -
>
> Key: CLOUDSTACK-2686
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2686
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Volumes
>Affects Versions: 4.2.0
> Environment: build:
> CloudStack-non-OSS-MASTER-389-rhel6.3
>Reporter: shweta agarwal
>Assignee: Mice Xia
>Priority: Critical
> Fix For: 4.2.0
>
>
> Repro steps:
> 1. Create a Project
> 2. Upload a Volume to the project
> Bug:
> Volume uploaded does not belong to project . Uploaded volume is not shown in
> Project Storage view
> Expected result:
> Uploaded volume should belong to the project and should be shown in Project
> storage View.
> API call :
> http://10.147.59.212:8080/client/api?command=uploadVolume&response=json&sessionkey=yV6GY8KRbZ27uN8vauSKUwtCBcM%3D&projectid=e2a9e94d-0285-4c07-943c-9e666f9d9d61&name=ov&zoneId=e9d7d1e4-9020-427e-ac13-25cefbc72b28&format=OVA&url=http%3A%2F%2F10.147.28.7%2Ftemplates%2Fvmware%2FCentos6_2.ova&_=1369632336913
> http://10.147.59.212:8080/client/api?command=queryAsyncJobResult&jobId=009686d9-a383-4d57-a2e8-9838f91ef0ab&response=json&sessionkey=yV6GY8KRbZ27uN8vauSKUwtCBcM%3D&projectid=e2a9e94d-0285-4c07-943c-9e666f9d9d61&_=1369632340133
> Response:
> { "queryasyncjobresultresponse" :
> {"accountid":"7b3e166c-c399-11e2-8675-0648d8bc","userid":"7b3eb860-c399-11e2-8675-0648d8bc","cmd":"org.apache.cloudstack.api.command.user.volume.UploadVolumeCmd","jobstatus":1,"jobprocstatus":0,"jobresultcode":0,"jobresulttype":"object","jobresult":{"volume":{"id":"beabdf48-31ff-4118-8899-77b66d3aa40e","name":"ov","zoneid":"e9d7d1e4-9020-427e-ac13-25cefbc72b28","zonename":"vmware","zonetype":"Advanced","type":"DATADISK","size":0,"created":"2013-05-27T06:54:33-0400","state":"Uploaded","account":"admin","domainid":"51a5a572-c399-11e2-8675-0648d8bc","domain":"ROOT","storagetype":"shared","diskofferingid":"831db814-883b-489a-9c6a-ae7084ba8bdb","diskofferingname":"Custom","diskofferingdisplaytext":"Custom
>
> Disk","destroyed":false,"isextractable":true,"tags":[],"displayvolume":false}},"created":"2013-05-27T06:54:33-0400","jobid":"009686d9-a383-4d57-a2e8-9838f91ef0ab"}
> }
> The issue is in response instead of getting project id and project as
> parameter its getting account as parameter . So the uploaded volume gets
> assign to account owner instead of project .
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-2686) Upload volume to project is not shown in project storage view
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mice Xia reassigned CLOUDSTACK-2686:
Assignee: Mice Xia
> Upload volume to project is not shown in project storage view
> -
>
> Key: CLOUDSTACK-2686
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2686
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Volumes
>Affects Versions: 4.2.0
> Environment: build:
> CloudStack-non-OSS-MASTER-389-rhel6.3
>Reporter: shweta agarwal
>Assignee: Mice Xia
>Priority: Critical
> Fix For: 4.2.0
>
>
> Repro steps:
> 1. Create a Project
> 2. Upload a Volume to the project
> Bug:
> Volume uploaded does not belong to project . Uploaded volume is not shown in
> Project Storage view
> Expected result:
> Uploaded volume should belong to the project and should be shown in Project
> storage View.
> API call :
> http://10.147.59.212:8080/client/api?command=uploadVolume&response=json&sessionkey=yV6GY8KRbZ27uN8vauSKUwtCBcM%3D&projectid=e2a9e94d-0285-4c07-943c-9e666f9d9d61&name=ov&zoneId=e9d7d1e4-9020-427e-ac13-25cefbc72b28&format=OVA&url=http%3A%2F%2F10.147.28.7%2Ftemplates%2Fvmware%2FCentos6_2.ova&_=1369632336913
> http://10.147.59.212:8080/client/api?command=queryAsyncJobResult&jobId=009686d9-a383-4d57-a2e8-9838f91ef0ab&response=json&sessionkey=yV6GY8KRbZ27uN8vauSKUwtCBcM%3D&projectid=e2a9e94d-0285-4c07-943c-9e666f9d9d61&_=1369632340133
> Response:
> { "queryasyncjobresultresponse" :
> {"accountid":"7b3e166c-c399-11e2-8675-0648d8bc","userid":"7b3eb860-c399-11e2-8675-0648d8bc","cmd":"org.apache.cloudstack.api.command.user.volume.UploadVolumeCmd","jobstatus":1,"jobprocstatus":0,"jobresultcode":0,"jobresulttype":"object","jobresult":{"volume":{"id":"beabdf48-31ff-4118-8899-77b66d3aa40e","name":"ov","zoneid":"e9d7d1e4-9020-427e-ac13-25cefbc72b28","zonename":"vmware","zonetype":"Advanced","type":"DATADISK","size":0,"created":"2013-05-27T06:54:33-0400","state":"Uploaded","account":"admin","domainid":"51a5a572-c399-11e2-8675-0648d8bc","domain":"ROOT","storagetype":"shared","diskofferingid":"831db814-883b-489a-9c6a-ae7084ba8bdb","diskofferingname":"Custom","diskofferingdisplaytext":"Custom
>
> Disk","destroyed":false,"isextractable":true,"tags":[],"displayvolume":false}},"created":"2013-05-27T06:54:33-0400","jobid":"009686d9-a383-4d57-a2e8-9838f91ef0ab"}
> }
> The issue is in response instead of getting project id and project as
> parameter its getting account as parameter . So the uploaded volume gets
> assign to account owner instead of project .
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2686) Upload volume to project is not shown in project storage view
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mice Xia resolved CLOUDSTACK-2686.
--
Resolution: Fixed
add a new parameter 'projectid' to API uploadVolume
> Upload volume to project is not shown in project storage view
> -
>
> Key: CLOUDSTACK-2686
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2686
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Volumes
>Affects Versions: 4.2.0
> Environment: build:
> CloudStack-non-OSS-MASTER-389-rhel6.3
>Reporter: shweta agarwal
>Assignee: Mice Xia
>Priority: Critical
> Fix For: 4.2.0
>
>
> Repro steps:
> 1. Create a Project
> 2. Upload a Volume to the project
> Bug:
> Volume uploaded does not belong to project . Uploaded volume is not shown in
> Project Storage view
> Expected result:
> Uploaded volume should belong to the project and should be shown in Project
> storage View.
> API call :
> http://10.147.59.212:8080/client/api?command=uploadVolume&response=json&sessionkey=yV6GY8KRbZ27uN8vauSKUwtCBcM%3D&projectid=e2a9e94d-0285-4c07-943c-9e666f9d9d61&name=ov&zoneId=e9d7d1e4-9020-427e-ac13-25cefbc72b28&format=OVA&url=http%3A%2F%2F10.147.28.7%2Ftemplates%2Fvmware%2FCentos6_2.ova&_=1369632336913
> http://10.147.59.212:8080/client/api?command=queryAsyncJobResult&jobId=009686d9-a383-4d57-a2e8-9838f91ef0ab&response=json&sessionkey=yV6GY8KRbZ27uN8vauSKUwtCBcM%3D&projectid=e2a9e94d-0285-4c07-943c-9e666f9d9d61&_=1369632340133
> Response:
> { "queryasyncjobresultresponse" :
> {"accountid":"7b3e166c-c399-11e2-8675-0648d8bc","userid":"7b3eb860-c399-11e2-8675-0648d8bc","cmd":"org.apache.cloudstack.api.command.user.volume.UploadVolumeCmd","jobstatus":1,"jobprocstatus":0,"jobresultcode":0,"jobresulttype":"object","jobresult":{"volume":{"id":"beabdf48-31ff-4118-8899-77b66d3aa40e","name":"ov","zoneid":"e9d7d1e4-9020-427e-ac13-25cefbc72b28","zonename":"vmware","zonetype":"Advanced","type":"DATADISK","size":0,"created":"2013-05-27T06:54:33-0400","state":"Uploaded","account":"admin","domainid":"51a5a572-c399-11e2-8675-0648d8bc","domain":"ROOT","storagetype":"shared","diskofferingid":"831db814-883b-489a-9c6a-ae7084ba8bdb","diskofferingname":"Custom","diskofferingdisplaytext":"Custom
>
> Disk","destroyed":false,"isextractable":true,"tags":[],"displayvolume":false}},"created":"2013-05-27T06:54:33-0400","jobid":"009686d9-a383-4d57-a2e8-9838f91ef0ab"}
> }
> The issue is in response instead of getting project id and project as
> parameter its getting account as parameter . So the uploaded volume gets
> assign to account owner instead of project .
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-2686) Upload volume to project is not shown in project storage view
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mice Xia reassigned CLOUDSTACK-2686:
Assignee: Mice Xia
> Upload volume to project is not shown in project storage view
> -
>
> Key: CLOUDSTACK-2686
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2686
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Volumes
>Affects Versions: 4.2.0
> Environment: build:
> CloudStack-non-OSS-MASTER-389-rhel6.3
>Reporter: shweta agarwal
>Assignee: Mice Xia
>Priority: Critical
> Fix For: 4.2.0
>
>
> Repro steps:
> 1. Create a Project
> 2. Upload a Volume to the project
> Bug:
> Volume uploaded does not belong to project . Uploaded volume is not shown in
> Project Storage view
> Expected result:
> Uploaded volume should belong to the project and should be shown in Project
> storage View.
> API call :
> http://10.147.59.212:8080/client/api?command=uploadVolume&response=json&sessionkey=yV6GY8KRbZ27uN8vauSKUwtCBcM%3D&projectid=e2a9e94d-0285-4c07-943c-9e666f9d9d61&name=ov&zoneId=e9d7d1e4-9020-427e-ac13-25cefbc72b28&format=OVA&url=http%3A%2F%2F10.147.28.7%2Ftemplates%2Fvmware%2FCentos6_2.ova&_=1369632336913
> http://10.147.59.212:8080/client/api?command=queryAsyncJobResult&jobId=009686d9-a383-4d57-a2e8-9838f91ef0ab&response=json&sessionkey=yV6GY8KRbZ27uN8vauSKUwtCBcM%3D&projectid=e2a9e94d-0285-4c07-943c-9e666f9d9d61&_=1369632340133
> Response:
> { "queryasyncjobresultresponse" :
> {"accountid":"7b3e166c-c399-11e2-8675-0648d8bc","userid":"7b3eb860-c399-11e2-8675-0648d8bc","cmd":"org.apache.cloudstack.api.command.user.volume.UploadVolumeCmd","jobstatus":1,"jobprocstatus":0,"jobresultcode":0,"jobresulttype":"object","jobresult":{"volume":{"id":"beabdf48-31ff-4118-8899-77b66d3aa40e","name":"ov","zoneid":"e9d7d1e4-9020-427e-ac13-25cefbc72b28","zonename":"vmware","zonetype":"Advanced","type":"DATADISK","size":0,"created":"2013-05-27T06:54:33-0400","state":"Uploaded","account":"admin","domainid":"51a5a572-c399-11e2-8675-0648d8bc","domain":"ROOT","storagetype":"shared","diskofferingid":"831db814-883b-489a-9c6a-ae7084ba8bdb","diskofferingname":"Custom","diskofferingdisplaytext":"Custom
>
> Disk","destroyed":false,"isextractable":true,"tags":[],"displayvolume":false}},"created":"2013-05-27T06:54:33-0400","jobid":"009686d9-a383-4d57-a2e8-9838f91ef0ab"}
> }
> The issue is in response instead of getting project id and project as
> parameter its getting account as parameter . So the uploaded volume gets
> assign to account owner instead of project .
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2406) language display error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667622#comment-13667622 ] sebastien goasguen commented on CLOUDSTACK-2406: That's strange but maybe we fixed it in master and missed 4.1. Can you submit a patch for it, so we check what happened. -Sebastien > language display error > --- > > Key: CLOUDSTACK-2406 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2406 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 > Environment: Ubuntu 12.0.4 kvm >Reporter: terryye > Original Estimate: 72h > Remaining Estimate: 72h > > All of chinese lable is "???" . > Japanese is display the word code .like \u65e5\u672c\.. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2613) Null Pointer exception while starting Management server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mice Xia resolved CLOUDSTACK-2613. -- Resolution: Duplicate duplicate of CLOUDSTACK-1981 > Null Pointer exception while starting Management server > > > Key: CLOUDSTACK-2613 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2613 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.2.0 > Environment: Master build >Reporter: Rayees Namathponnan > Fix For: 4.2.0 > > > Created new build from Master branch and start management server, below null > pointer exception in Management server log > 2013-05-21 16:28:38,405 INFO > [factory.annotation.AutowiredAnnotationBeanPostProcessor] (main:null) JSR-330 > 'javax.inject.Inject' annotation found and supported for autowiring > 2013-05-21 16:28:46,184 INFO > [factory.annotation.AutowiredAnnotationBeanPostProcessor] > (catalina-exec-1:null) JSR-330 'javax.inject.Inject' annotation found and > supported for autowiring > 2013-05-21 16:28:46,260 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null) > ===START=== 10.223.240.193 -- GET > apiKey=HdQzBTKgr3qQYraEGb29wL_dxYdR1BlRLrHFzEGxbg6FqCWO0KyM7c5aUafJwhVh0xHr2A78OYwPXztJiUqQVQ&command=listSystemVms&response=json&state=Running&zoneid=bab9b165-41bf-48ed-9c24-94c1219f54c0&signature=HX%2B6uow%2FFiGHwf%2FJl3VmNP%2FwQ9k%3D > 2013-05-21 16:28:46,263 ERROR [cloud.api.ApiServlet] (catalina-exec-1:null) > unknown exception writing api response > java.lang.NullPointerException > at > com.cloud.user.AccountManagerImpl.getSystemUser(AccountManagerImpl.java:304) > at > com.cloud.user.AccountManagerImpl.getSystemUser(AccountManagerImpl.java:148) > at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:238) > at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66) > 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 > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) > at > org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889) > at > org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721) > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2274) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) > 2013-05-21 16:28:46,294 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null) > ===END=== 10.223.240.193 -- GET > API log > 2013-05-21 16:28:46,282 INFO [cloud.api.ApiServer] (catalina-exec-1:null) > 10.223.240.193 -- GET > apiKey=HdQzBTKgr3qQYraEGb29wL_dxYdR1BlRLrHFzEGxbg6FqCWO0KyM7c5aUafJwhVh0xHr2A78OYwPXztJiUqQVQ&command=listSystemVms&response=json&state=Running&zoneid=bab9b165-41bf-48ed-9c24-94c1219f54c0&signature=HX%2B6uow%2FFiGHwf%2FJl3VmNP%2FwQ9k%3D > unknown exception writing api response > 2013-05-21 16:28:46,407 INFO [cloud.api.ApiServer] (catalina-exec-2:null) > 10.223.240.193 -- GET > apiKey=HdQzBTKgr3qQYraEGb29wL_dxYdR1BlRLrHFzEGxbg6FqCWO0KyM7c5aUafJwhVh0xHr2A78OYwPXztJiUqQVQ&command=listTemplates&listall=true&response=json&templatefilter=featured&signature=dod6EaTfMDX%2BMH1U0qxAi4RYhNU%3D > unknown exception writing api response > 2013-05-21 16:29:38,666 INFO [cloud.api.ApiServer] (catalina-exec-14:null) > 10.216.133.67 -- GET > command=listCapabilities&response=json&sessionkey=oOjShuV5yHPU8iQ7sm5%2FYXe09m8%3D&_=1369179096208 > unknown exception writing api response > 2013-05-21 16:29:49,391 INFO [cloud.api.ApiServer] (catalina-exec-2:null) > 10.216.133.67 -- POST comm
[jira] [Created] (CLOUDSTACK-2688) listAlerts call is slow for dashboard.
Nitin Mehta created CLOUDSTACK-2688: --- Summary: listAlerts call is slow for dashboard. Key: CLOUDSTACK-2688 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2688 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Nitin Mehta listAlerts calls become slow in a high scale setup. I still find listAlert call for dashboard is a culprit. Its also taking considerable time of 6.93 sec which is also a considerable time. When accessing from single session is taking this much time it will be worsen when several session will try to access the data . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2109) UI shows removed Nics
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mice Xia resolved CLOUDSTACK-2109. -- Resolution: Fixed error handling had been improved and this should have been fixed, please re-open it if still reproducible > UI shows removed Nics > -- > > Key: CLOUDSTACK-2109 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2109 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 > Environment: Xen hypervisor > build:CloudStack-non-OSS-MASTER-232-rhel6.3.tar.gz >Reporter: shweta agarwal > Fix For: 4.2.0 > > > Repro steps: > Create a VM > Add 9 nics to the VM > As Vm can have maximum 7 NICs last two will fail hence will be marked as > removed in nic table in db > Bug: > Even though Nics are removed successfully they are shown in UI > Expected result: > UI should only show active nics of the VM > DB shows Nics as removed : > "id" "uuid" "instance_id" "mac_address" "ip4_address" "netmask" > "gateway" "ip_type" "broadcast_uri" "network_id""mode" > "state" "strategy" "reserver_name" "reservation_id""device_id" > "update_time" "isolation_uri" "ip6_address" "default_nic" "vm_type" > "created" "removed" "ip6_gateway" "ip6_cidr" > "secondary_ip" > "8" "779399c2-b1f8-4a5a-95d2-373ee1c97cc4" "3" "02:00:18:18:00:01" > "10.1.1.194""255.255.255.0" "10.1.1.1" "Ip4" "vlan://1049" "204" > "Dhcp" "Reserved" "Start" "ExternalGuestNetworkGuru" > "84246f21-a495-47d4-8f06-cf7ff422f8a1" "0" "2013-04-19 09:26:39" > "vlan://1049" NULL"1" "User" "2013-04-19 11:09:10" NULLNULL > NULL"0" > "20" "18941cd8-5511-4fb5-bd70-6876fe47e91e" "3" "06:f1:18:00:00:29" > "10.147.51.130" "255.255.255.0" "10.147.51.1" "Ip4" "vlan://51" "207" > "Dhcp" "Reserved" "Create""DirectNetworkGuru" NULL"2" > "2013-04-19 09:27:04" "vlan://51" NULL"0" "User" > "2013-04-19 11:26:07" NULLNULLNULL"0" > "24" "d328b70d-86ad-45fc-8273-aefc6465d226" "3" "02:00:58:64:00:03" > "10.1.1.67" "255.255.255.0" "10.1.1.1" "Ip4" "vlan://1049" "204" > "Dhcp" "Reserved" "Start" "ExternalGuestNetworkGuru" > "84246f21-a495-47d4-8f06-cf7ff422f8a1" "3" "2013-04-19 09:27:16" > "vlan://1049" NULL"0" "User" "2013-04-19 11:33:14" NULLNULL > NULL"0" > "25" "c63fc0bf-f6ab-4753-acbb-a14770886719" "3" "02:00:0e:c3:00:04" > "10.1.1.250""255.255.255.0" "10.1.1.1" "Ip4" "vlan://1049" "204" > "Dhcp" "Reserved" "Start" "ExternalGuestNetworkGuru" > "84246f21-a495-47d4-8f06-cf7ff422f8a1" "4" "2013-04-19 09:27:28" > "vlan://1049" NULL"0" "User" "2013-04-19 11:33:56" NULLNULL > NULL"0" > "29" "d42b3a7f-8e8c-4712-99e9-786197ef8fb1" "3" "02:00:00:01:00:08" > "10.1.1.171""255.255.255.0" "10.1.1.1" "Ip4" "vlan://1049" "204" > "Dhcp" "Reserved" "Start" "ExternalGuestNetworkGuru" > "84246f21-a495-47d4-8f06-cf7ff422f8a1" "6" "2013-04-19 09:27:52" > "vlan://1049" NULL"0" "User" "2013-04-19 13:20:22" NULLNULL > NULL"0" > "30" "444a6520-c86d-48ea-91d2-d9bd73902812" "3" "02:00:19:2d:00:01" > "10.1.1.60" "255.255.255.0" "10.1.1.1" "Ip4" "vlan://1043" "209" > "Dhcp" "Deallocating" "Start" "ExternalGuestNetworkGuru" NULL"7" > "2013-04-19 09:34:33" "vlan://1043" NULL"0" "User" > "2013-04-19 13:30:19" "2013-04-19 13:34:33" NULLNULL"0" > "34" "bbd0a8b0-1913-4306-8b4d-45750bf52c27" "3" "02:00:56:37:00:01" > "10.1.1.192""255.255.255.0" "10.1.1.1" "Ip4" "vlan://1050" "208" > "Dhcp" "Deallocating" "Start" "ExternalGuestNetworkGuru" NULL"8" > "2013-04-19 09:34:33" "vlan://1050" NULL"0" "User" > "2013-04-19 13:31:13" "2013-04-19 13:34:33" NULLNULL"0" > "38" "170bb5af-b355-4cb4-8376-490d3e032f80" "3" "02:00:07:af:00:03" > "10.1.1.35" "255.255.255.0" "10.1.1.1" "Ip4" "vlan://1044" "206" > "Dhcp" "Deallocating" "Start" "ExternalGuestNetworkGuru" NULL"9" > "2013-04-19 09:34:09" "vlan://1044" NULL"0" "User" > "2013-04-19 13:31:33" "2013-04-19 13:34:09" NULLNULL"0" > "39" "ae94bf81-a369-4e7c-b5ee-4c76e96c1236" "3" "06:ad:24:00:00:23" > "10.147.51.124" "255.255.255.0" "10.147.51.1" "Ip4" "vlan://51" "207" > "Dhcp" "Deallocating" "Create""DirectNetworkGuru" NULL > "10""2013-0
[jira] [Created] (CLOUDSTACK-2689) Create volume after upgrade from snapshot taken in 2.2.14 deletes the snapshot physically from sec. storage.
Nitin Mehta created CLOUDSTACK-2689: --- Summary: Create volume after upgrade from snapshot taken in 2.2.14 deletes the snapshot physically from sec. storage. Key: CLOUDSTACK-2689 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2689 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Nitin Mehta In pre 3.0 release for any install be it fresh or upgraded the swift_id is 0 bcz the swift_id is long and not the Java object Long and so by default gets set to 0 instead of NULL in the DB. Now the code assumes that the snapshot is present in swift and can be deleted from sec. storage after any operation on the snapshot by checking the condition snapshot.getSwiftId() != null.It should have checked for snapshot.getSwiftId() != null && snapshot.getSwiftId() != 0. Why this not an issue in fresh installs for 3.0 series ? I think in 3.0 we added all the code for swift. There was also a code change for Action which made swift_id as JAVA Long and so for fresh installs in 3.0 series swift_id was NULL in the DB by default and hence these operations succeeded without deleting snapshot physically from sec. storage. But for any upgraded version from 2.2.8 onwards (when swift_id got first introduced) this would be 0 and since we check only for SwiftId() != null we will delete the snapshot from sec. storage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2688) listAlerts call is slow for dashboard.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667634#comment-13667634 ] ASF subversion and git services commented on CLOUDSTACK-2688: - Commit 08ac8fb4687fb14cf9524a022527a64e033be9ab in branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=08ac8fb ] CLOUDSTACK-2688 Add DB index to Alert.last_sent column to speed up listAlertsCmd. > listAlerts call is slow for dashboard. > -- > > Key: CLOUDSTACK-2688 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2688 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta > > listAlerts calls become slow in a high scale setup. > I still find listAlert call for dashboard is a culprit. Its also taking > considerable time of 6.93 sec which is also a considerable time. When > accessing from single session is taking this much time it will be worsen when > several session will try to access the data . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2688) listAlerts call is slow for dashboard.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta resolved CLOUDSTACK-2688. - Resolution: Fixed Assignee: Nitin Mehta > listAlerts call is slow for dashboard. > -- > > Key: CLOUDSTACK-2688 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2688 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta >Assignee: Nitin Mehta > > listAlerts calls become slow in a high scale setup. > I still find listAlert call for dashboard is a culprit. Its also taking > considerable time of 6.93 sec which is also a considerable time. When > accessing from single session is taking this much time it will be worsen when > several session will try to access the data . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2689) Create volume after upgrade from snapshot taken in 2.2.14 deletes the snapshot physically from sec. storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667639#comment-13667639 ] ASF subversion and git services commented on CLOUDSTACK-2689: - Commit a688d631047ae7dc70a4c4d8c5330dec1dc1cd95 in branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a688d63 ] CLOUDSTACK-2689 Create volume after upgrade from snapshot taken in 2.2.14 deletes the snapshot physically from sec. storage. Added DB upgrade sql to make swift_id NULL if they are set to 0 > Create volume after upgrade from snapshot taken in 2.2.14 deletes the > snapshot physically from sec. storage. > > > Key: CLOUDSTACK-2689 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2689 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta > > In pre 3.0 release for any install be it fresh or upgraded the swift_id is 0 > bcz the swift_id is long and not the Java object Long and so by default gets > set to 0 instead of NULL in the DB. Now the code assumes that the snapshot is > present in swift and can be deleted from sec. storage after any operation on > the snapshot by checking the condition snapshot.getSwiftId() != null.It > should have checked for snapshot.getSwiftId() != null && > snapshot.getSwiftId() != 0. > Why this not an issue in fresh installs for 3.0 series ? > I think in 3.0 we added all the code for swift. > There was also a code change for Action which made swift_id as JAVA Long and > so for fresh installs in 3.0 series swift_id was NULL in the DB by default > and hence these operations succeeded without deleting snapshot physically > from sec. storage. But for any upgraded version from 2.2.8 onwards (when > swift_id got first introduced) this would be 0 and since we check only for > SwiftId() != null we will delete the snapshot from sec. storage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2689) Create volume after upgrade from snapshot taken in 2.2.14 deletes the snapshot physically from sec. storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta resolved CLOUDSTACK-2689. - Resolution: Fixed > Create volume after upgrade from snapshot taken in 2.2.14 deletes the > snapshot physically from sec. storage. > > > Key: CLOUDSTACK-2689 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2689 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta > > In pre 3.0 release for any install be it fresh or upgraded the swift_id is 0 > bcz the swift_id is long and not the Java object Long and so by default gets > set to 0 instead of NULL in the DB. Now the code assumes that the snapshot is > present in swift and can be deleted from sec. storage after any operation on > the snapshot by checking the condition snapshot.getSwiftId() != null.It > should have checked for snapshot.getSwiftId() != null && > snapshot.getSwiftId() != 0. > Why this not an issue in fresh installs for 3.0 series ? > I think in 3.0 we added all the code for swift. > There was also a code change for Action which made swift_id as JAVA Long and > so for fresh installs in 3.0 series swift_id was NULL in the DB by default > and hence these operations succeeded without deleting snapshot physically > from sec. storage. But for any upgraded version from 2.2.8 onwards (when > swift_id got first introduced) this would be 0 and since we check only for > SwiftId() != null we will delete the snapshot from sec. storage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2690) Deprecate API create/list/deleteIpForwardingRule
Mice Xia created CLOUDSTACK-2690: Summary: Deprecate API create/list/deleteIpForwardingRule Key: CLOUDSTACK-2690 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2690 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.0 Reporter: Mice Xia Fix For: Future UI does not use them anymore they can be replaced by corresponding staticNAT or port forwarding APIs they have a different set of implementation with staticNAT, which causes confusion -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2666) Host is getting dedicated to a Account even when preferred implicit dedication is used.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Devdeep Singh resolved CLOUDSTACK-2666. --- Resolution: Fixed Assignee: Devdeep Singh UI was passing the wrong parameter string for 'preferred' mode. Because of that, the planner used to default to 'Strict' mode. The issue was fixed in commit 8b9d6d81a229441cc5a9e3c0bf61e81de9ea6c5d. > Host is getting dedicated to a Account even when preferred implicit > dedication is used. > --- > > Key: CLOUDSTACK-2666 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2666 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kiran Koneti >Assignee: Devdeep Singh >Priority: Blocker > > 1)Created a Xen Advanced Zone setup with one cluster and hosts. > 2)The host1 has the system VM's deployed and a VM with the root domain. > 3)Then created two accounts kiran and kiran2 respectively. > 4)Deployed VM using the preferred implicit dedication for the Account kiran. > 5)Then tried to deploy a VM fro the account kiran2 using the preferred > implicit service offering. > 6)The VM deployment fails saying insufficient resources > The error message is as below > "2013-05-24 17:49:33,285 INFO [user.vm.DeployVMCmd] (Job-Executor-7:job-26) > com.cloud.exception.InsufficientServerCapacityException: Unable to create a > deployment for VM[User|prefacc2]Scope=interface com.cloud.dc.DataCenter; id=1 > 2013-05-24 17:49:33,287 INFO [user.vm.DeployVMCmd] (Job-Executor-7:job-26) > Unable to create a deployment for VM[User|prefacc2] > com.cloud.exception.InsufficientServerCapacityException: Unable to create a > deployment for VM[User|prefacc2]Scope=interface com.cloud.dc.DataCenter; id=1 > at > org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.reserveVirtualMachine(VMEntityManagerImpl.java:212) > at > org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.reserve(VirtualMachineEntityImpl.java:198) > at > com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3206) > at > com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2745) > at > com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2731) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) > at > org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:420) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155) > at > com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679)" > Ideally saying the host should not be dedicated to the account kiran but this > is getting dedicated which is causing the vm creation failure for the account > kiran2. > The db shows the host in dedicated state. > "mysql> select * from op_host_planner_reservation; > +++++-++ > | id | data_center_id | pod_id | cluster_id | host_id | resource_usage | > +++++-++ > | 1 | 1 | 1 | 1 | 1 | Shared | > | 2 | 1 | 1 | 1 | 5 | Dedicated | > +++++-++ > 2 rows in set (0.00 sec)" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1704) cluster is not getting disabled after threshold value set to global parameter "cluster.cpu.allocated.capacity.disablethreshold"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-1704: -- Description: --> "cluster.cpu.allocated.capacity.disablethreshold "Percentage (as a value between 0 and 1) of cpu utilization above which allocators will disable using the cluster for low cpu available. -->when i set "cluster.cpu.allocated.capacity.disablethreshold" to blank character at cluster level , Global parameter"cluster.cpu.allocated.capacity.disablethreshold" stop working. Steps to reproduce 1-Set cluster.cpu.allocated.capacity.disablethreshold to 0.5 , 2-Restart MS 3-Set cluster.cpu.allocated.capacity.desablethreshold to "blank" character 4-Deploy some vms , so that cpu utilizatio should be >0.5 Expected - Cluster should be disabled after threshold value Actual --- cluster is not getting disabled after threshold value was: "cluster.cpu.allocated.capacity.disablethreshold "Percentage (as a value between 0 and 1) of cpu utilization above which allocators will disable using the cluster for low cpu available. Steps to reproduce 1-Set cluster.cpu.allocated.capacity.disablethreshold to 0.5 , 2-Restart MS 3-Deploy some vms , so that cpu utilizatio should be >0.5 Expected - Cluster should be disabled after threshold value Actual --- cluster is not getting disabled after threshold value > cluster is not getting disabled after threshold value set to global parameter > "cluster.cpu.allocated.capacity.disablethreshold" > --- > > Key: CLOUDSTACK-1704 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1704 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra > Fix For: 4.2.0 > > Attachments: apilog.log, cloud-backup1.dmp, management-server.log, > screenshot-1.jpg, screenshot-2.jpg, setupManagement.log > > > --> "cluster.cpu.allocated.capacity.disablethreshold "Percentage (as a value > between 0 and 1) of cpu utilization above which allocators will disable using > the cluster for low cpu available. > -->when i set "cluster.cpu.allocated.capacity.disablethreshold" to blank > character at cluster level , Global > parameter"cluster.cpu.allocated.capacity.disablethreshold" stop working. > Steps to reproduce > > 1-Set cluster.cpu.allocated.capacity.disablethreshold to 0.5 , > 2-Restart MS > 3-Set cluster.cpu.allocated.capacity.desablethreshold to "blank" character > 4-Deploy some vms , so that cpu utilizatio should be >0.5 > Expected > - > Cluster should be disabled after threshold value > Actual > --- > cluster is not getting disabled after threshold value -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1704) cluster is not getting disabled after threshold value set to global parameter "cluster.cpu.allocated.capacity.disablethreshold"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-1704: -- Attachment: (was: apilog.log) > cluster is not getting disabled after threshold value set to global parameter > "cluster.cpu.allocated.capacity.disablethreshold" > --- > > Key: CLOUDSTACK-1704 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1704 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra > Fix For: 4.2.0 > > Attachments: cloud-backup.dmp, log.rar, management-server.log, > screenshot-1.jpg, screenshot-2.jpg, setupManagement.log > > > --> "cluster.cpu.allocated.capacity.disablethreshold "Percentage (as a value > between 0 and 1) of cpu utilization above which allocators will disable using > the cluster for low cpu available. > -->when i set "cluster.cpu.allocated.capacity.disablethreshold" to blank > character at cluster level , Global > parameter"cluster.cpu.allocated.capacity.disablethreshold" stop working. > Steps to reproduce > > 1-Set cluster.cpu.allocated.capacity.disablethreshold to 0.5 , > 2-Restart MS > 3-Set cluster.cpu.allocated.capacity.desablethreshold to "blank" character > 4-Deploy some vms , so that cpu utilizatio should be >0.5 > Expected > - > Cluster should be disabled after threshold value > Actual > --- > cluster is not getting disabled after threshold value -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1704) cluster is not getting disabled after threshold value set to global parameter "cluster.cpu.allocated.capacity.disablethreshold"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-1704: -- Attachment: cloud-backup.dmp log.rar uploading new logs and db dump > cluster is not getting disabled after threshold value set to global parameter > "cluster.cpu.allocated.capacity.disablethreshold" > --- > > Key: CLOUDSTACK-1704 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1704 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra > Fix For: 4.2.0 > > Attachments: cloud-backup.dmp, log.rar, management-server.log, > screenshot-1.jpg, screenshot-2.jpg, setupManagement.log > > > --> "cluster.cpu.allocated.capacity.disablethreshold "Percentage (as a value > between 0 and 1) of cpu utilization above which allocators will disable using > the cluster for low cpu available. > -->when i set "cluster.cpu.allocated.capacity.disablethreshold" to blank > character at cluster level , Global > parameter"cluster.cpu.allocated.capacity.disablethreshold" stop working. > Steps to reproduce > > 1-Set cluster.cpu.allocated.capacity.disablethreshold to 0.5 , > 2-Restart MS > 3-Set cluster.cpu.allocated.capacity.desablethreshold to "blank" character > 4-Deploy some vms , so that cpu utilizatio should be >0.5 > Expected > - > Cluster should be disabled after threshold value > Actual > --- > cluster is not getting disabled after threshold value -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1704) cluster is not getting disabled after threshold value set to global parameter "cluster.cpu.allocated.capacity.disablethreshold"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-1704: -- Attachment: (was: cloud-backup1.dmp) > cluster is not getting disabled after threshold value set to global parameter > "cluster.cpu.allocated.capacity.disablethreshold" > --- > > Key: CLOUDSTACK-1704 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1704 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra > Fix For: 4.2.0 > > Attachments: cloud-backup.dmp, log.rar, management-server.log, > screenshot-1.jpg, screenshot-2.jpg, setupManagement.log > > > --> "cluster.cpu.allocated.capacity.disablethreshold "Percentage (as a value > between 0 and 1) of cpu utilization above which allocators will disable using > the cluster for low cpu available. > -->when i set "cluster.cpu.allocated.capacity.disablethreshold" to blank > character at cluster level , Global > parameter"cluster.cpu.allocated.capacity.disablethreshold" stop working. > Steps to reproduce > > 1-Set cluster.cpu.allocated.capacity.disablethreshold to 0.5 , > 2-Restart MS > 3-Set cluster.cpu.allocated.capacity.desablethreshold to "blank" character > 4-Deploy some vms , so that cpu utilizatio should be >0.5 > Expected > - > Cluster should be disabled after threshold value > Actual > --- > cluster is not getting disabled after threshold value -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1704) cluster is not getting disabled after threshold value set to global parameter "cluster.cpu.allocated.capacity.disablethreshold"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-1704: -- Attachment: (was: management-server.log) > cluster is not getting disabled after threshold value set to global parameter > "cluster.cpu.allocated.capacity.disablethreshold" > --- > > Key: CLOUDSTACK-1704 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1704 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra > Fix For: 4.2.0 > > Attachments: cloud-backup.dmp, log.rar, screenshot-1.jpg, > screenshot-2.jpg, setupManagement.log > > > --> "cluster.cpu.allocated.capacity.disablethreshold "Percentage (as a value > between 0 and 1) of cpu utilization above which allocators will disable using > the cluster for low cpu available. > -->when i set "cluster.cpu.allocated.capacity.disablethreshold" to blank > character at cluster level , Global > parameter"cluster.cpu.allocated.capacity.disablethreshold" stop working. > Steps to reproduce > > 1-Set cluster.cpu.allocated.capacity.disablethreshold to 0.5 , > 2-Restart MS > 3-Set cluster.cpu.allocated.capacity.desablethreshold to "blank" character > 4-Deploy some vms , so that cpu utilizatio should be >0.5 > Expected > - > Cluster should be disabled after threshold value > Actual > --- > cluster is not getting disabled after threshold value -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1704) cluster is not getting disabled after threshold value set to global parameter "cluster.cpu.allocated.capacity.disablethreshold"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-1704: -- Attachment: (was: setupManagement.log) > cluster is not getting disabled after threshold value set to global parameter > "cluster.cpu.allocated.capacity.disablethreshold" > --- > > Key: CLOUDSTACK-1704 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1704 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra > Fix For: 4.2.0 > > Attachments: cloud-backup.dmp, log.rar > > > --> "cluster.cpu.allocated.capacity.disablethreshold "Percentage (as a value > between 0 and 1) of cpu utilization above which allocators will disable using > the cluster for low cpu available. > -->when i set "cluster.cpu.allocated.capacity.disablethreshold" to blank > character at cluster level , Global > parameter"cluster.cpu.allocated.capacity.disablethreshold" stop working. > Steps to reproduce > > 1-Set cluster.cpu.allocated.capacity.disablethreshold to 0.5 , > 2-Restart MS > 3-Set cluster.cpu.allocated.capacity.desablethreshold to "blank" character > 4-Deploy some vms , so that cpu utilizatio should be >0.5 > Expected > - > Cluster should be disabled after threshold value > Actual > --- > cluster is not getting disabled after threshold value -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1704) cluster is not getting disabled after threshold value set to global parameter "cluster.cpu.allocated.capacity.disablethreshold"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-1704: -- Attachment: (was: screenshot-1.jpg) > cluster is not getting disabled after threshold value set to global parameter > "cluster.cpu.allocated.capacity.disablethreshold" > --- > > Key: CLOUDSTACK-1704 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1704 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra > Fix For: 4.2.0 > > Attachments: cloud-backup.dmp, log.rar > > > --> "cluster.cpu.allocated.capacity.disablethreshold "Percentage (as a value > between 0 and 1) of cpu utilization above which allocators will disable using > the cluster for low cpu available. > -->when i set "cluster.cpu.allocated.capacity.disablethreshold" to blank > character at cluster level , Global > parameter"cluster.cpu.allocated.capacity.disablethreshold" stop working. > Steps to reproduce > > 1-Set cluster.cpu.allocated.capacity.disablethreshold to 0.5 , > 2-Restart MS > 3-Set cluster.cpu.allocated.capacity.desablethreshold to "blank" character > 4-Deploy some vms , so that cpu utilizatio should be >0.5 > Expected > - > Cluster should be disabled after threshold value > Actual > --- > cluster is not getting disabled after threshold value -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2406) language display error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667652#comment-13667652 ] Milamber commented on CLOUDSTACK-2406: -- I think it's me that upload an incorrect version of messages_ja.properties (05/29/2013). This incorrect version contains double-backslash in unicode char (only one backslash is the correct way). Thanks Hiroaki for fix it on git repository. I've upload to transifex (form 4.1 and 4.2/master) the correct version for japanese l10n. > language display error > --- > > Key: CLOUDSTACK-2406 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2406 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 > Environment: Ubuntu 12.0.4 kvm >Reporter: terryye > Original Estimate: 72h > Remaining Estimate: 72h > > All of chinese lable is "???" . > Japanese is display the word code .like \u65e5\u672c\.. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1704) cluster is not getting disabled after threshold value set to global parameter "cluster.cpu.allocated.capacity.disablethreshold"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-1704: -- Attachment: (was: screenshot-2.jpg) > cluster is not getting disabled after threshold value set to global parameter > "cluster.cpu.allocated.capacity.disablethreshold" > --- > > Key: CLOUDSTACK-1704 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1704 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra > Fix For: 4.2.0 > > Attachments: cloud-backup.dmp, log.rar > > > --> "cluster.cpu.allocated.capacity.disablethreshold "Percentage (as a value > between 0 and 1) of cpu utilization above which allocators will disable using > the cluster for low cpu available. > -->when i set "cluster.cpu.allocated.capacity.disablethreshold" to blank > character at cluster level , Global > parameter"cluster.cpu.allocated.capacity.disablethreshold" stop working. > Steps to reproduce > > 1-Set cluster.cpu.allocated.capacity.disablethreshold to 0.5 , > 2-Restart MS > 3-Set cluster.cpu.allocated.capacity.desablethreshold to "blank" character > 4-Deploy some vms , so that cpu utilizatio should be >0.5 > Expected > - > Cluster should be disabled after threshold value > Actual > --- > cluster is not getting disabled after threshold value -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (CLOUDSTACK-2406) language display error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667652#comment-13667652 ] Milamber edited comment on CLOUDSTACK-2406 at 5/27/13 9:21 AM: --- I think it's me that upload an incorrect version of messages_ja.properties (05/29/2013). This incorrect version contains double-backslash in unicode char (only one backslash is the correct way). Thanks Hiroaki for fix it on git repository. I've upload to transifex (form 4.1 and 4.2/master) the correct version for japanese l10n. I think this issue can close now. was (Author: milamber): I think it's me that upload an incorrect version of messages_ja.properties (05/29/2013). This incorrect version contains double-backslash in unicode char (only one backslash is the correct way). Thanks Hiroaki for fix it on git repository. I've upload to transifex (form 4.1 and 4.2/master) the correct version for japanese l10n. > language display error > --- > > Key: CLOUDSTACK-2406 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2406 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 > Environment: Ubuntu 12.0.4 kvm >Reporter: terryye > Original Estimate: 72h > Remaining Estimate: 72h > > All of chinese lable is "???" . > Japanese is display the word code .like \u65e5\u672c\.. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2406) language display error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667657#comment-13667657 ] Hiroaki Kawai commented on CLOUDSTACK-2406: --- Just FYI: I assume there should have made multiple operations on a broken properties file. One is double-back slash as Milamber commented, but there were several lines that are completely broken UTF-8 sequence, which would be happen during in charset encoding conversion. I think this issue has fixed now too, but I want to wait for verification of Chinese strings. > language display error > --- > > Key: CLOUDSTACK-2406 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2406 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 > Environment: Ubuntu 12.0.4 kvm >Reporter: terryye > Original Estimate: 72h > Remaining Estimate: 72h > > All of chinese lable is "???" . > Japanese is display the word code .like \u65e5\u672c\.. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2691) [VPC][PrivateGateway]Unable to delete the private gateways on VPC after VPC router reboot.
manasaveloori created CLOUDSTACK-2691:
-
Summary: [VPC][PrivateGateway]Unable to delete the private
gateways on VPC after VPC router reboot.
Key: CLOUDSTACK-2691
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2691
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Network Controller
Affects Versions: 4.2.0
Reporter: manasaveloori
Priority: Critical
Fix For: 4.2.0
Steps:
1. Have a CS with advanced zone.
2. Create a VPC .
3. Add a private gateway to the vpc.
4. Now reboot the VPC VR.
5. Try to delete the created private gateway.
Observation:
Observed 2 NPEs while deleting the private gateway. The private gateway is not
getting deleted.
Below is the snippet from the management server log. Also attaching the log
2013-05-27 19:37:42,281 ERROR [xen.resource.CitrixResourceBase]
(DirectAgent-426:null) SetNetworkACL failed due to
java.lang.NullPointerException
java.lang.NullPointerException
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:8274)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:600)
at
com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:73)
at
com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:102)
at
com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
2013-05-27 19:37:42,283 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-426:null) Seq 3-1205666345: Response Received:
2013-05-27 19:37:42,284 DEBUG [agent.transport.Request] (DirectAgent-426:null)
Seq 3-1205666345: Processing: { Ans: , MgmtId: 6805241462820, via: 3, Ver: v1,
Flags: 0,
[{"routing.SetNetworkACLAnswer":{"results":[null,null],"result":false,"wait":0}}]
}
2013-05-27 19:37:42,284 DEBUG [agent.transport.Request]
(Job-Executor-32:job-39) Seq 3-1205666345: Received: { Ans: , MgmtId:
6805241462820, via: 3, Ver: v1, Flags: 0, { SetNetworkACLAnswer } }
2013-05-27 19:37:42,303 ERROR [cloud.async.AsyncJobManagerImpl]
(Job-Executor-32:job-39) Unexpected exception while executing
org.apache.cloudstack.api.command.admin.vpc.DeletePrivateGatewayCmd
com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is
unreachable: Unable to apply network acls on router
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:3739)
at
com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.applyNetworkACLs(VpcVirtualNetworkApplianceManagerImpl.java:717)
at
com.cloud.network.element.VpcVirtualRouterElement.applyACLItemsToPrivateGw(VpcVirtualRouterElement.java:463)
at
com.cloud.network.vpc.NetworkACLManagerImpl.applyACLItemsToPrivateGw(NetworkACLManagerImpl.java:304)
at
com.cloud.network.vpc.NetworkACLManagerImpl.revokeACLItemsForPrivateGw(NetworkACLManagerImpl.java:266)
at
com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.destroyPrivateGateway(VpcVirtualNetworkApplianceManagerImpl.java:1053)
at
com.cloud.network.element.VpcVirtualRouterElement.deletePrivateGateway(VpcVirtualRouterElement.java:378)
at
com.cloud.network.vpc.VpcManagerImpl.deleteVpcPrivateGateway(VpcManagerImpl.java:1458)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
org.apache.cloudstack.api.command.admin.vpc.DeletePrivateGatewayCmd.execute(DeletePrivateGatewayCmd.java:85)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
at
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
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.concurren
[jira] [Updated] (CLOUDSTACK-1622) Global parameter "cluster.memory.allocated.capacity.disablethreshold" is not disabling cluster after threshold value
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-1622: -- Description: Cluster should get disable after alocated memory crosses threshold of global parameter cluster.memory.allocated.capacity.disablethreshold . ->-->when i set "cluster.memory.allocated.capacity.disablethreshold" to blank character at cluster level , Global parameter"cluster.memory.allocated.capacity.disablethreshold" stop working. Steps to repo --- 1-Set Global parameter cluster.memory.allocated.capacity.disablethreshold to some value say 0.3 2-set cluster level parameter cluster.memory.allocated.capacity.disablethreshold to blank space 3-Deploy vms Expected After threshold value (0.3) cluster should get disable Actual - Cluster is not getting disable was: Cluster should get disable after used memory crosses threshold of global parameter cluster.memory.allocated.capacity.disablethreshold . Steps to repo --- 1-set cluster level parameter cluster.memory.allocated.capacity.disablethreshold to blank space 2-Set Global parameter cluster.memory.allocated.capacity.disablethreshold to some value in my case 0.2 3-Deploy vms Expected After threshold value (0.2) cluster should get disable Actual - Cluster is not getting disable > Global parameter "cluster.memory.allocated.capacity.disablethreshold" is not > disabling cluster after threshold value > - > > Key: CLOUDSTACK-1622 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1622 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra > Fix For: 4.2.0 > > Attachments: apilog.log, cloud-backup.dmp, management-server.log, > screenshot-1.jpg, screenshot-2.jpg > > > Cluster should get disable after alocated memory crosses threshold of global > parameter cluster.memory.allocated.capacity.disablethreshold . > ->-->when i set "cluster.memory.allocated.capacity.disablethreshold" to blank > character at cluster level , Global > parameter"cluster.memory.allocated.capacity.disablethreshold" stop working. > Steps to repo > --- > 1-Set Global parameter cluster.memory.allocated.capacity.disablethreshold to > some value say 0.3 > 2-set cluster level parameter > cluster.memory.allocated.capacity.disablethreshold to blank space > 3-Deploy vms > Expected > > After threshold value (0.3) cluster should get disable > Actual > - > Cluster is not getting disable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2691) [VPC][PrivateGateway]Unable to delete the private gateways on VPC after VPC router reboot.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
manasaveloori updated CLOUDSTACK-2691:
--
Attachment: management-server.zip
> [VPC][PrivateGateway]Unable to delete the private gateways on VPC after VPC
> router reboot.
> --
>
> Key: CLOUDSTACK-2691
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2691
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller
>Affects Versions: 4.2.0
>Reporter: manasaveloori
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.zip
>
>
> Steps:
> 1.Have a CS with advanced zone.
> 2.Create a VPC .
> 3.Add a private gateway to the vpc.
> 4.Now reboot the VPC VR.
> 5.Try to delete the created private gateway.
> Observation:
> Observed 2 NPEs while deleting the private gateway. The private gateway is
> not getting deleted.
> Below is the snippet from the management server log. Also attaching the log
> 2013-05-27 19:37:42,281 ERROR [xen.resource.CitrixResourceBase]
> (DirectAgent-426:null) SetNetworkACL failed due to
> java.lang.NullPointerException
> java.lang.NullPointerException
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:8274)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:600)
> at
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:73)
> at
> com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:102)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-05-27 19:37:42,283 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-426:null) Seq 3-1205666345: Response Received:
> 2013-05-27 19:37:42,284 DEBUG [agent.transport.Request]
> (DirectAgent-426:null) Seq 3-1205666345: Processing: { Ans: , MgmtId:
> 6805241462820, via: 3, Ver: v1, Flags: 0,
> [{"routing.SetNetworkACLAnswer":{"results":[null,null],"result":false,"wait":0}}]
> }
> 2013-05-27 19:37:42,284 DEBUG [agent.transport.Request]
> (Job-Executor-32:job-39) Seq 3-1205666345: Received: { Ans: , MgmtId:
> 6805241462820, via: 3, Ver: v1, Flags: 0, { SetNetworkACLAnswer } }
> 2013-05-27 19:37:42,303 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-32:job-39) Unexpected exception while executing
> org.apache.cloudstack.api.command.admin.vpc.DeletePrivateGatewayCmd
> com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is
> unreachable: Unable to apply network acls on router
> at
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:3739)
> at
> com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.applyNetworkACLs(VpcVirtualNetworkApplianceManagerImpl.java:717)
> at
> com.cloud.network.element.VpcVirtualRouterElement.applyACLItemsToPrivateGw(VpcVirtualRouterElement.java:463)
> at
> com.cloud.network.vpc.NetworkACLManagerImpl.applyACLItemsToPrivateGw(NetworkACLManagerImpl.java:304)
> at
> com.cloud.network.vpc.NetworkACLManagerImpl.revokeACLItemsForPrivateGw(NetworkACLManagerImpl.java:266)
> at
> com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.destroyPrivateGateway(VpcVirtualNetworkApplianceManagerImpl.java:1053)
> at
> com.cloud.network.element.VpcVirtualRouterElement.deletePrivateGateway(VpcVirtualRouterElement.java:378)
> at
> com.cloud.network.vpc.VpcManagerImpl.deleteVpcPrivateGateway(VpcManagerImpl.java:1458)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.admin.vpc.DeletePrivateGatewayCmd.execute(DeletePr
[jira] [Updated] (CLOUDSTACK-1622) Global parameter "cluster.memory.allocated.capacity.disablethreshold" is not disabling cluster after threshold value
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-1622: -- Attachment: (was: cloud-backup.dmp) > Global parameter "cluster.memory.allocated.capacity.disablethreshold" is not > disabling cluster after threshold value > - > > Key: CLOUDSTACK-1622 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1622 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra > Fix For: 4.2.0 > > Attachments: logs.rar > > > Cluster should get disable after alocated memory crosses threshold of global > parameter cluster.memory.allocated.capacity.disablethreshold . > ->-->when i set "cluster.memory.allocated.capacity.disablethreshold" to blank > character at cluster level , Global > parameter"cluster.memory.allocated.capacity.disablethreshold" stop working. > Steps to repo > --- > 1-Set Global parameter cluster.memory.allocated.capacity.disablethreshold to > some value say 0.3 > 2-set cluster level parameter > cluster.memory.allocated.capacity.disablethreshold to blank space > 3-Deploy vms > Expected > > After threshold value (0.3) cluster should get disable > Actual > - > Cluster is not getting disable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1622) Global parameter "cluster.memory.allocated.capacity.disablethreshold" is not disabling cluster after threshold value
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-1622: -- Attachment: logs.rar Attaching MS ,Api logs,db dump > Global parameter "cluster.memory.allocated.capacity.disablethreshold" is not > disabling cluster after threshold value > - > > Key: CLOUDSTACK-1622 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1622 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra > Fix For: 4.2.0 > > Attachments: logs.rar > > > Cluster should get disable after alocated memory crosses threshold of global > parameter cluster.memory.allocated.capacity.disablethreshold . > ->-->when i set "cluster.memory.allocated.capacity.disablethreshold" to blank > character at cluster level , Global > parameter"cluster.memory.allocated.capacity.disablethreshold" stop working. > Steps to repo > --- > 1-Set Global parameter cluster.memory.allocated.capacity.disablethreshold to > some value say 0.3 > 2-set cluster level parameter > cluster.memory.allocated.capacity.disablethreshold to blank space > 3-Deploy vms > Expected > > After threshold value (0.3) cluster should get disable > Actual > - > Cluster is not getting disable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1622) Global parameter "cluster.memory.allocated.capacity.disablethreshold" is not disabling cluster after threshold value
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-1622: -- Attachment: (was: screenshot-1.jpg) > Global parameter "cluster.memory.allocated.capacity.disablethreshold" is not > disabling cluster after threshold value > - > > Key: CLOUDSTACK-1622 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1622 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra > Fix For: 4.2.0 > > Attachments: logs.rar > > > Cluster should get disable after alocated memory crosses threshold of global > parameter cluster.memory.allocated.capacity.disablethreshold . > ->-->when i set "cluster.memory.allocated.capacity.disablethreshold" to blank > character at cluster level , Global > parameter"cluster.memory.allocated.capacity.disablethreshold" stop working. > Steps to repo > --- > 1-Set Global parameter cluster.memory.allocated.capacity.disablethreshold to > some value say 0.3 > 2-set cluster level parameter > cluster.memory.allocated.capacity.disablethreshold to blank space > 3-Deploy vms > Expected > > After threshold value (0.3) cluster should get disable > Actual > - > Cluster is not getting disable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1622) Global parameter "cluster.memory.allocated.capacity.disablethreshold" is not disabling cluster after threshold value
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-1622: -- Attachment: (was: management-server.log) > Global parameter "cluster.memory.allocated.capacity.disablethreshold" is not > disabling cluster after threshold value > - > > Key: CLOUDSTACK-1622 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1622 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra > Fix For: 4.2.0 > > Attachments: logs.rar > > > Cluster should get disable after alocated memory crosses threshold of global > parameter cluster.memory.allocated.capacity.disablethreshold . > ->-->when i set "cluster.memory.allocated.capacity.disablethreshold" to blank > character at cluster level , Global > parameter"cluster.memory.allocated.capacity.disablethreshold" stop working. > Steps to repo > --- > 1-Set Global parameter cluster.memory.allocated.capacity.disablethreshold to > some value say 0.3 > 2-set cluster level parameter > cluster.memory.allocated.capacity.disablethreshold to blank space > 3-Deploy vms > Expected > > After threshold value (0.3) cluster should get disable > Actual > - > Cluster is not getting disable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1622) Global parameter "cluster.memory.allocated.capacity.disablethreshold" is not disabling cluster after threshold value
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-1622: -- Attachment: (was: screenshot-2.jpg) > Global parameter "cluster.memory.allocated.capacity.disablethreshold" is not > disabling cluster after threshold value > - > > Key: CLOUDSTACK-1622 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1622 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra > Fix For: 4.2.0 > > Attachments: logs.rar > > > Cluster should get disable after alocated memory crosses threshold of global > parameter cluster.memory.allocated.capacity.disablethreshold . > ->-->when i set "cluster.memory.allocated.capacity.disablethreshold" to blank > character at cluster level , Global > parameter"cluster.memory.allocated.capacity.disablethreshold" stop working. > Steps to repo > --- > 1-Set Global parameter cluster.memory.allocated.capacity.disablethreshold to > some value say 0.3 > 2-set cluster level parameter > cluster.memory.allocated.capacity.disablethreshold to blank space > 3-Deploy vms > Expected > > After threshold value (0.3) cluster should get disable > Actual > - > Cluster is not getting disable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-1622) Global parameter "cluster.memory.allocated.capacity.disablethreshold" is not disabling cluster after threshold value
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-1622: -- Attachment: (was: apilog.log) > Global parameter "cluster.memory.allocated.capacity.disablethreshold" is not > disabling cluster after threshold value > - > > Key: CLOUDSTACK-1622 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1622 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra > Fix For: 4.2.0 > > Attachments: logs.rar > > > Cluster should get disable after alocated memory crosses threshold of global > parameter cluster.memory.allocated.capacity.disablethreshold . > ->-->when i set "cluster.memory.allocated.capacity.disablethreshold" to blank > character at cluster level , Global > parameter"cluster.memory.allocated.capacity.disablethreshold" stop working. > Steps to repo > --- > 1-Set Global parameter cluster.memory.allocated.capacity.disablethreshold to > some value say 0.3 > 2-set cluster level parameter > cluster.memory.allocated.capacity.disablethreshold to blank space > 3-Deploy vms > Expected > > After threshold value (0.3) cluster should get disable > Actual > - > Cluster is not getting disable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-2581) Not able to login to VM using the password dispalyed from passwordenabled tempalte.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harikrishna Patnala reassigned CLOUDSTACK-2581: --- Assignee: Harikrishna Patnala > Not able to login to VM using the password dispalyed from passwordenabled > tempalte. > --- > > Key: CLOUDSTACK-2581 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2581 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.2.0 >Reporter: Kiran Koneti >Assignee: Harikrishna Patnala >Priority: Critical > Fix For: 4.2.0 > > > 1)Registered a template as a password enabled template. > 2)Created a VM using the same template and the password is displayed once the > VM is created. > 3)Tried to login to the VM using the password. > 4)the login failed saying wrong password. > 5)Then tried to login with the default password the login was successful. > 6)Then tried the password reset and new password is pooped up. > 7)Tried logging with the new password but the login still fails with and > login is successful with the default password. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2406) language display error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667674#comment-13667674 ] Milamber commented on CLOUDSTACK-2406: -- I've check chinese strings on master and 4.1 branches, all seems good on the file (unicode chars) and in the web UI (chinese char/logograms display correctly). But I'm not a chinese reader. > language display error > --- > > Key: CLOUDSTACK-2406 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2406 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 > Environment: Ubuntu 12.0.4 kvm >Reporter: terryye > Original Estimate: 72h > Remaining Estimate: 72h > > All of chinese lable is "???" . > Japanese is display the word code .like \u65e5\u672c\.. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-1528) No UI level check for Overcommit ratio;It is accepting special character,negative values and zero
[
https://issues.apache.org/jira/browse/CLOUDSTACK-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharat Kumar resolved CLOUDSTACK-1528.
--
Resolution: Invalid
> No UI level check for Overcommit ratio;It is accepting special
> character,negative values and zero
> -
>
> Key: CLOUDSTACK-1528
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1528
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.2.0
>Reporter: prashant kumar mishra
>Assignee: Bharat Kumar
> Fix For: 4.2.0
>
> Attachments: screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg
>
>
> 1-There is no check in UI for special character and zero.
> 2-If we provide any special character or zero for overcommit ratio in UI ,DB
> is getting upgraded by default value 1.
> Steps
>
> 1-Create a cluster provide some special characters for overcommit ratio
> Expected
> -
> should have some error message , overcommite ratio cant't be special
> character or less than zero etc.
> Actual
>
> cluster is getting created with overcommit ratio ={special
> character,zero,-ive values} but DB is storing default value 1 .
> DB
> ---
> mysql> select* from cluster_details;
> +++---+---+
> | id | cluster_id | name | value |
> +++---+---+
> | 1 | 1 | cpuOvercommitRatio| 1.0 |
> | 2 | 1 | memoryOvercommitRatio | 1.0 |
> | 3 | 2 | cpuOvercommitRatio| 1.0 |
> | 4 | 2 | memoryOvercommitRatio | 1.0 |
> | 5 | 3 | cpuOvercommitRatio| 1.0 |
> | 6 | 3 | memoryOvercommitRatio | 1.0 |
> +++---+---+
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2692) [MIPN][Enhancement] Add load balancing support for MIPN
Jayapal Reddy created CLOUDSTACK-2692: - Summary: [MIPN][Enhancement] Add load balancing support for MIPN Key: CLOUDSTACK-2692 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2692 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.1.0 Reporter: Jayapal Reddy Assignee: Jayapal Reddy Fix For: 4.2.0 Add support of Load balancing for MIPN feature -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2169) Reset ASA 1000v appliance to factory setting as part of guest network cleanup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koushik Das updated CLOUDSTACK-2169: Assignee: (was: Koushik Das) > Reset ASA 1000v appliance to factory setting as part of guest network cleanup > - > > Key: CLOUDSTACK-2169 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2169 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc, Network Devices >Affects Versions: 4.2.0 >Reporter: Koushik Das > Fix For: 4.2.0 > > > Expected behavior is that ASA 1000v should get cleaned up properly when > logical edge firewall is cleaned up in VNMC. But due to some issue with the > VNMC sometimes the cleanup doesn't happen. If the cleanup doesn't happen then > the ASA 1000v cannot be reused in a new guest network. > So the ASA 1000v needs to be cleaned up explicitly using some CLI commands. > As part of this SSH needs to be enabled on the ASA by the admin outside of CS > and store the SSH credentials with CS while registering ASA. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2696) default value of cluster.memory.allocated.capacity.notificationthreshold is getting set to 0.75 instead of taking value from Global parameter "cluster.memory.alloca
prashant kumar mishra created CLOUDSTACK-2696: - Summary: default value of cluster.memory.allocated.capacity.notificationthreshold is getting set to 0.75 instead of taking value from Global parameter "cluster.memory.allocated.capacity.notificationthreshold" Key: CLOUDSTACK-2696 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2696 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API, UI Affects Versions: 4.2.0 Reporter: prashant kumar mishra Fix For: 4.2.0 Steps to reproduce --- 1- set global parameter "cluster.memory.allocated.capacity.notificationthreshold" to some value say 0.2 2-Set cluster level parameter "cluster.memory.allocated.capacity.notificationthreshold" to "space" Expected -- cluster.memory.allocated.capacity.notificationthreshold should be set to 0.2(global parameter) Actual --- cluster.memory.allocated.capacity.notificationthreshold is getting set to 0.75,DB shows NULL in value field DB -- mysql> select * from cluster_details; +++-+---+ | id | cluster_id | name| value | +++-+---+ | 1 | 1 | cpuOvercommitRatio | 1.0 | | 2 | 1 | memoryOvercommitRatio | 1.0 | | 3 | 2 | cpuOvercommitRatio | 1.0 | | 4 | 2 | memoryOvercommitRatio | 1.0 | | 5 | 1 | cluster.cpu.allocated.capacity.disablethreshold | NULL | | 6 | 2 | cluster.cpu.allocated.capacity.disablethreshold | NULL | | 7 | 1 | cluster.memory.allocated.capacity.disablethreshold | NULL | | 8 | 1 | cluster.cpu.allocated.capacity.notificationthreshold| 0.85 | | 9 | 2 | cluster.cpu.allocated.capacity.notificationthreshold| NULL | | 10 | 2 | cluster.memory.allocated.capacity.disablethreshold | 0.85 | | 11 | 2 | cluster.memory.allocated.capacity.notificationthreshold | NULL | +++-+---+ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-658) Scaling up CPU and RAM for running VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667694#comment-13667694 ] Nitin Mehta commented on CLOUDSTACK-658: Not closing this as subtasks are still open. > Scaling up CPU and RAM for running VMs > -- > > Key: CLOUDSTACK-658 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-658 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Koushik Das >Assignee: Nitin Mehta > Fix For: 4.2.0 > > > Currently CS supports changing CPU and RAM for stopped VM. This is achieved > by changing compute offering of the VM (with new CPU and RAM values) and then > starting it. I am planning to extend the same for running VM as well. > Initially planning to do it for Vmware where CPU and RAM can be dynamically > increased. Support of other HVs can also be added if they support increasing > CPU/RAM. > Assuming that in the updated compute offering only CPU and RAM has changed, > the deployment planner can either select the same host in which case the > values are dynamically scaled up OR a different one in which case the > operation fails. In future if there is support for live migration (provided > HV supports it) then another option in the latter case could be to migrate > the VM first and then scale it up. > Release Planning: > Dev list discussion: http://markmail.org/message/ocdt62utijeyxikc > Functional Spec: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dynamic+scaling+of+CPU+and+RAM > Feature branch: unknown -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2696) default value of cluster.memory.allocated.capacity.notificationthreshold is getting set to 0.75 instead of taking value from Global parameter "cluster.memory.alloca
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-2696: -- Attachment: logs.rar logs and db dump > default value of cluster.memory.allocated.capacity.notificationthreshold is > getting set to 0.75 instead of taking value from Global parameter > "cluster.memory.allocated.capacity.notificationthreshold" > > > Key: CLOUDSTACK-2696 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2696 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, UI >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra > Fix For: 4.2.0 > > Attachments: logs.rar > > > Steps to reproduce > --- > 1- set global parameter > "cluster.memory.allocated.capacity.notificationthreshold" to some value say > 0.2 > 2-Set cluster level parameter > "cluster.memory.allocated.capacity.notificationthreshold" to "space" > Expected > -- > cluster.memory.allocated.capacity.notificationthreshold should be set to > 0.2(global parameter) > Actual > --- > cluster.memory.allocated.capacity.notificationthreshold is getting set to > 0.75,DB shows NULL in value field > DB > -- > mysql> select * from cluster_details; > +++-+---+ > | id | cluster_id | name| > value | > +++-+---+ > | 1 | 1 | cpuOvercommitRatio | > 1.0 | > | 2 | 1 | memoryOvercommitRatio | > 1.0 | > | 3 | 2 | cpuOvercommitRatio | > 1.0 | > | 4 | 2 | memoryOvercommitRatio | > 1.0 | > | 5 | 1 | cluster.cpu.allocated.capacity.disablethreshold | > NULL | > | 6 | 2 | cluster.cpu.allocated.capacity.disablethreshold | > NULL | > | 7 | 1 | cluster.memory.allocated.capacity.disablethreshold | > NULL | > | 8 | 1 | cluster.cpu.allocated.capacity.notificationthreshold| > 0.85 | > | 9 | 2 | cluster.cpu.allocated.capacity.notificationthreshold| > NULL | > | 10 | 2 | cluster.memory.allocated.capacity.disablethreshold | > 0.85 | > | 11 | 2 | cluster.memory.allocated.capacity.notificationthreshold | > NULL | > +++-+---+ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2694) [Firewall Rule] Able to configure duplicate firewall rule with protocol and no ports
Jayapal Reddy created CLOUDSTACK-2694: - Summary: [Firewall Rule] Able to configure duplicate firewall rule with protocol and no ports Key: CLOUDSTACK-2694 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2694 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.0.0 Reporter: Jayapal Reddy 1. Configure a firewall rules with cidd 0.0.0.0/0 protocol tcp and do NOT pass ports 2. Configure the same rule again. Rule is configured successfully Expected: Should throw duplicate firewall rule error -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-1074) Scaling up CPU and RAM for running VMs - KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667693#comment-13667693 ] Nitin Mehta commented on CLOUDSTACK-1074: - Marcus - Didnt completely understand it as I am not a KVM expert. For Xenserver and Vmware we need to set some attributes during vm creation to indicate to the hypervisor that these vms should be dynamicall scalable. Can something like this not be done for KVM ? Are you saying its not feasible for KVM at all ? If that be the case, can you please resolve this saying that the feature is not feasible for KVM ? Thanks. > Scaling up CPU and RAM for running VMs - KVM > > > Key: CLOUDSTACK-1074 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1074 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Nitin Mehta >Assignee: Marcus Sorensen > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2693) Introduce scaleSystemVm API for scaling system vms
Nitin Mehta created CLOUDSTACK-2693: --- Summary: Introduce scaleSystemVm API for scaling system vms Key: CLOUDSTACK-2693 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2693 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Fix For: 4.2.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2695) [Object_Store_Refactor] Provisioning object storage(S3 based secondary storage) can't be at zone level
Sanjeev N created CLOUDSTACK-2695: - Summary: [Object_Store_Refactor] Provisioning object storage(S3 based secondary storage) can't be at zone level Key: CLOUDSTACK-2695 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2695 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: Build from object_store branch Reporter: Sanjeev N Priority: Critical Fix For: 4.2.0 Provisioning object storage can't be at zone level. 1.With current CS implementation , Regions is self created. 2.Provisioning object storage is at zone level but it should be at region level. 3.If the user creates multiple zones then user has to provide s3 object store details in each zone . Since s3 is a region level storage, adding s3 should also be at region level rather than at zone level. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2107) Only scaling up memory(ram) in not triggering vm live migration ;Unable to scale vm due to Catch exception com.xensource.xenapi.Types$HostNotEnoughFreeMemory when
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667690#comment-13667690
]
Nitin Mehta commented on CLOUDSTACK-2107:
-
In case you are able to repro this under some circumstances please feel free to
reopen this. Also add XS logs in future.
> Only scaling up memory(ram) in not triggering vm live migration ;Unable to
> scale vm due to Catch exception
> com.xensource.xenapi.Types$HostNotEnoughFreeMemory when scaling VM:i-2-35-VM
> due to Not enough host memory is available to perform this operation
>
>
> Key: CLOUDSTACK-2107
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2107
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
>Reporter: prashant kumar mishra
>Assignee: Nitin Mehta
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: access_log.2013-04-19.txt, apilog.log, catalina.out,
> management-server.log, RamScaleUp.png
>
>
> For cpu scalup ,vms getting live migrated to other host in cluster if no
> resources are available on current host ,but not in case of RAM Scaleup
> Steps to reproduce
>
> 1-Create zone->pod->cluster with one host
> 2-Deploy vm so that no resource left on host
> 3-Add another host in same cluster
> 4- Try to scale up vm's ram (in new service offering keep cpu speed same as
> previous ,increase ram by 500 MB)
> Expected
> --
> since there is no resource left on current host vm should get live migrate to
> other available host and scaleup should be successful .
> Actual
> -
> scaleup failed due to not enough resource on current host,;CS did not try to
> live migrate vm to other host on cluster
> My observation
> --
> 1-VM are getting live migrated in case of cpu scale up if current host does
> not have resource
> 2-Tried to scaleup vm to service offering x failed but able to deploy a new
> vm with same service offering
> Service offering details
> --
> Tried to scaleup from SO 20 to SO 22
> 1-SO 22
> mysql> select * from service_offering_view where id=22 \G
> *** 1. row ***
>id: 22
> uuid: 528443f5-f044-4e64-b1e1-87f6c0136921
> name: smallcpu2ram
> display_text: smallcpu2ram
> created: 2013-04-18 18:48:17
> tags: NULL
> removed: NULL
> use_local_storage: 0
>system_use: 0
> cpu: 1
> speed: 1500
> ram_size: 1024
> nw_rate: NULL
> mc_rate: NULL
>ha_enabled: 0
> limit_cpu_use: 0
> host_tag: NULL
> default_use: 0
> vm_type: NULL
> sort_key: 0
> domain_id: NULL
> domain_uuid: NULL
> domain_name: NULL
> domain_path: NULL
> 1 row in set (0.00 sec)
> 2-SO 20
> mysql> select * from service_offering_view where id=20 \G
> *** 1. row ***
>id: 20
> uuid: 4bafd8c7-c8cc-42db-a630-61909556803b
> name: smallcpu2
> display_text: smallcpu2
> created: 2013-04-18 18:39:59
> tags: NULL
> removed: NULL
> use_local_storage: 0
>system_use: 0
> cpu: 1
> speed: 1500
> ram_size: 500
> nw_rate: NULL
> mc_rate: NULL
>ha_enabled: 0
> limit_cpu_use: 0
> host_tag: NULL
> default_use: 0
> vm_type: NULL
> sort_key: 5
> domain_id: NULL
> domain_uuid: NULL
> domain_name: NULL
> domain_path: NULL
> 1 row in set (0.00 sec)
> Snippet of MS Log
> ---
> 2013-04-19 07:40:58,312 DEBUG [agent.transport.Request] (DirectAgent-12:null)
> Seq 1-521863179: Processing: { Ans: , MgmtId: 7191687856187, via: 1, Ver:
> v1, Flags: 110, [{"ScaleVmAnswer":{"result":false,"details":"Catch exception
> com.xensource.xenapi.Types$HostNotEnoughFreeMemory when scaling VM:i-2-35-VM
> due to Not enough host memory is available to perform this
> operation","wait":0}}] }
> 2013-04-19 07:40:58,312 DEBUG [agent.transport.Request]
> (catalina-exec-6:null) Seq 1-521863179: Received: { Ans: , MgmtId:
> 7191687856187, via: 1, Ver: v1, Flags: 110, { ScaleVmAnswer } }
> 2013-04-19 07:40:58,312 ERROR [cloud.vm.VirtualMachineManagerImp
[jira] [Resolved] (CLOUDSTACK-2107) Only scaling up memory(ram) in not triggering vm live migration ;Unable to scale vm due to Catch exception com.xensource.xenapi.Types$HostNotEnoughFreeMemory when s
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nitin Mehta resolved CLOUDSTACK-2107.
-
Resolution: Invalid
> Only scaling up memory(ram) in not triggering vm live migration ;Unable to
> scale vm due to Catch exception
> com.xensource.xenapi.Types$HostNotEnoughFreeMemory when scaling VM:i-2-35-VM
> due to Not enough host memory is available to perform this operation
>
>
> Key: CLOUDSTACK-2107
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2107
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
>Reporter: prashant kumar mishra
>Assignee: Nitin Mehta
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: access_log.2013-04-19.txt, apilog.log, catalina.out,
> management-server.log, RamScaleUp.png
>
>
> For cpu scalup ,vms getting live migrated to other host in cluster if no
> resources are available on current host ,but not in case of RAM Scaleup
> Steps to reproduce
>
> 1-Create zone->pod->cluster with one host
> 2-Deploy vm so that no resource left on host
> 3-Add another host in same cluster
> 4- Try to scale up vm's ram (in new service offering keep cpu speed same as
> previous ,increase ram by 500 MB)
> Expected
> --
> since there is no resource left on current host vm should get live migrate to
> other available host and scaleup should be successful .
> Actual
> -
> scaleup failed due to not enough resource on current host,;CS did not try to
> live migrate vm to other host on cluster
> My observation
> --
> 1-VM are getting live migrated in case of cpu scale up if current host does
> not have resource
> 2-Tried to scaleup vm to service offering x failed but able to deploy a new
> vm with same service offering
> Service offering details
> --
> Tried to scaleup from SO 20 to SO 22
> 1-SO 22
> mysql> select * from service_offering_view where id=22 \G
> *** 1. row ***
>id: 22
> uuid: 528443f5-f044-4e64-b1e1-87f6c0136921
> name: smallcpu2ram
> display_text: smallcpu2ram
> created: 2013-04-18 18:48:17
> tags: NULL
> removed: NULL
> use_local_storage: 0
>system_use: 0
> cpu: 1
> speed: 1500
> ram_size: 1024
> nw_rate: NULL
> mc_rate: NULL
>ha_enabled: 0
> limit_cpu_use: 0
> host_tag: NULL
> default_use: 0
> vm_type: NULL
> sort_key: 0
> domain_id: NULL
> domain_uuid: NULL
> domain_name: NULL
> domain_path: NULL
> 1 row in set (0.00 sec)
> 2-SO 20
> mysql> select * from service_offering_view where id=20 \G
> *** 1. row ***
>id: 20
> uuid: 4bafd8c7-c8cc-42db-a630-61909556803b
> name: smallcpu2
> display_text: smallcpu2
> created: 2013-04-18 18:39:59
> tags: NULL
> removed: NULL
> use_local_storage: 0
>system_use: 0
> cpu: 1
> speed: 1500
> ram_size: 500
> nw_rate: NULL
> mc_rate: NULL
>ha_enabled: 0
> limit_cpu_use: 0
> host_tag: NULL
> default_use: 0
> vm_type: NULL
> sort_key: 5
> domain_id: NULL
> domain_uuid: NULL
> domain_name: NULL
> domain_path: NULL
> 1 row in set (0.00 sec)
> Snippet of MS Log
> ---
> 2013-04-19 07:40:58,312 DEBUG [agent.transport.Request] (DirectAgent-12:null)
> Seq 1-521863179: Processing: { Ans: , MgmtId: 7191687856187, via: 1, Ver:
> v1, Flags: 110, [{"ScaleVmAnswer":{"result":false,"details":"Catch exception
> com.xensource.xenapi.Types$HostNotEnoughFreeMemory when scaling VM:i-2-35-VM
> due to Not enough host memory is available to perform this
> operation","wait":0}}] }
> 2013-04-19 07:40:58,312 DEBUG [agent.transport.Request]
> (catalina-exec-6:null) Seq 1-521863179: Received: { Ans: , MgmtId:
> 7191687856187, via: 1, Ver: v1, Flags: 110, { ScaleVmAnswer } }
> 2013-04-19 07:40:58,312 ERROR [cloud.vm.VirtualMachineManagerImpl]
> (catalina-exec-6:null) Unable to scale vm due to Catch exception
> com.xensource.xenapi.Types$HostNotEnoughFreeMemory when scaling VM:i-2-35-VM
> due to Not
[jira] [Commented] (CLOUDSTACK-2107) Only scaling up memory(ram) in not triggering vm live migration ;Unable to scale vm due to Catch exception com.xensource.xenapi.Types$HostNotEnoughFreeMemory when
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667689#comment-13667689 ] Nitin Mehta commented on CLOUDSTACK-2107: - The observation is incorrect - The first host had enough resources to accomodate the vm as is clearly seen from the log below 2013-04-19 07:40:57,966 DEBUG [cloud.capacity.CapacityManagerImpl] (catalina-exec-6:null) considerReservedCapacity isfalse , not considering reserved capacity for calculating free capacity 2013-04-19 07:40:57,966 DEBUG [cloud.capacity.CapacityManagerImpl] (catalina-exec-6:null) Free CPU: 372 , Requested CPU: 0 2013-04-19 07:40:57,966 DEBUG [cloud.capacity.CapacityManagerImpl] (catalina-exec-6:null) Free RAM: 1527917056 , Requested RAM: 549453824 2013-04-19 07:40:57,966 DEBUG [cloud.capacity.CapacityManagerImpl] (catalina-exec-6:null) Host has enough CPU and RAM available There are no Xenserver logs so I couldnt completely see what exactly was wrong on the XS side. Also I didnt hit it when trying. Is this consistently reproducible ? Can you also check there is no XS issue ? > Only scaling up memory(ram) in not triggering vm live migration ;Unable to > scale vm due to Catch exception > com.xensource.xenapi.Types$HostNotEnoughFreeMemory when scaling VM:i-2-35-VM > due to Not enough host memory is available to perform this operation > > > Key: CLOUDSTACK-2107 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2107 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra >Assignee: Nitin Mehta >Priority: Critical > Fix For: 4.2.0 > > Attachments: access_log.2013-04-19.txt, apilog.log, catalina.out, > management-server.log, RamScaleUp.png > > > For cpu scalup ,vms getting live migrated to other host in cluster if no > resources are available on current host ,but not in case of RAM Scaleup > Steps to reproduce > > 1-Create zone->pod->cluster with one host > 2-Deploy vm so that no resource left on host > 3-Add another host in same cluster > 4- Try to scale up vm's ram (in new service offering keep cpu speed same as > previous ,increase ram by 500 MB) > Expected > -- > since there is no resource left on current host vm should get live migrate to > other available host and scaleup should be successful . > Actual > - > scaleup failed due to not enough resource on current host,;CS did not try to > live migrate vm to other host on cluster > My observation > -- > 1-VM are getting live migrated in case of cpu scale up if current host does > not have resource > 2-Tried to scaleup vm to service offering x failed but able to deploy a new > vm with same service offering > Service offering details > -- > Tried to scaleup from SO 20 to SO 22 > 1-SO 22 > mysql> select * from service_offering_view where id=22 \G > *** 1. row *** >id: 22 > uuid: 528443f5-f044-4e64-b1e1-87f6c0136921 > name: smallcpu2ram > display_text: smallcpu2ram > created: 2013-04-18 18:48:17 > tags: NULL > removed: NULL > use_local_storage: 0 >system_use: 0 > cpu: 1 > speed: 1500 > ram_size: 1024 > nw_rate: NULL > mc_rate: NULL >ha_enabled: 0 > limit_cpu_use: 0 > host_tag: NULL > default_use: 0 > vm_type: NULL > sort_key: 0 > domain_id: NULL > domain_uuid: NULL > domain_name: NULL > domain_path: NULL > 1 row in set (0.00 sec) > 2-SO 20 > mysql> select * from service_offering_view where id=20 \G > *** 1. row *** >id: 20 > uuid: 4bafd8c7-c8cc-42db-a630-61909556803b > name: smallcpu2 > display_text: smallcpu2 > created: 2013-04-18 18:39:59 > tags: NULL > removed: NULL > use_local_storage: 0 >system_use: 0 > cpu: 1 > speed: 1500 > ram_size: 500 > nw_rate: NULL > mc_rate: NULL >ha_enabled: 0 > limit_cpu_use: 0 > host_tag: NULL > default_use: 0 > vm_type: NULL > sort_key: 5 > domain_id: NULL > domain_uuid: NULL
[jira] [Resolved] (CLOUDSTACK-2693) Introduce scaleSystemVm API for scaling system vms
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta resolved CLOUDSTACK-2693. - Resolution: Fixed Resolved by 4eb310e926771c30515034bb056f71f52afe1a19 > Introduce scaleSystemVm API for scaling system vms > -- > > Key: CLOUDSTACK-2693 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2693 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2697) cluster id in alert message is null {alertType:: 1 // dataCenterId:: 1 // podId:: 1 // clusterId:: null }
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
prashant kumar mishra updated CLOUDSTACK-2697:
--
Attachment: logs.rar
> cluster id in alert message is null {alertType:: 1 // dataCenterId:: 1 //
> podId:: 1 // clusterId:: null }
> -
>
> Key: CLOUDSTACK-2697
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2697
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
>Reporter: prashant kumar mishra
>Priority: Minor
> Fix For: 4.2.0
>
> Attachments: logs.rar
>
>
> Cluster id should not be null in Alert message.
> Snippet of log
>
> 2013-05-27 13:13:19,879 WARN [apache.cloudstack.alerts]
> (CapacityChecker:null) alertType:: 1 // dataCenterId:: 1 // podId:: 1 //
> clusterId:: null // message:: System Alert: Low Unallocated CPU in cluster
> cluster pod pod of availability zone pod
> 2013-05-27 13:13:19,890 DEBUG [cloud.alert.AlertManagerImpl]
> (CapacityChecker:null) Have already sent: 1 emails for alert type '1' --
> skipping send email
> 2013-05-27 13:13:19,954 DEBUG [cloud.alert.AlertManagerImpl]
> (CapacityChecker:null) System Alert: Low Unallocated CPU in cluster cluster2
> pod pod of availability zone pod
> 2013-05-27 13:13:19,954 DEBUG [cloud.alert.AlertManagerImpl]
> (CapacityChecker:null) Unallocated CPU is low, total: 9576 Mhz, used: 2000
> Mhz (20.89%)
> 2013-05-27 13:13:19,955 WARN [apache.cloudstack.alerts]
> (CapacityChecker:null) alertType:: 1 // dataCenterId:: 1 // podId:: 1 //
> clusterId:: null // message:: System Alert: Low Unallocated CPU in cluster
> cluster2 pod pod of availability zone pod
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2696) default value of cluster.memory.allocated.capacity.notificationthreshold is getting set to 0.75 instead of taking value from Global parameter "cluster.memory.alloca
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-2696: -- Attachment: logs.rar > default value of cluster.memory.allocated.capacity.notificationthreshold is > getting set to 0.75 instead of taking value from Global parameter > "cluster.memory.allocated.capacity.notificationthreshold" > > > Key: CLOUDSTACK-2696 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2696 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, UI >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra > Fix For: 4.2.0 > > Attachments: logs.rar > > > Steps to reproduce > --- > 1- set global parameter > "cluster.memory.allocated.capacity.notificationthreshold" to some value say > 0.2 > 2-Set cluster level parameter > "cluster.memory.allocated.capacity.notificationthreshold" to "space" > Expected > -- > cluster.memory.allocated.capacity.notificationthreshold should be set to > 0.2(global parameter) > Actual > --- > cluster.memory.allocated.capacity.notificationthreshold is getting set to > 0.75,DB shows NULL in value field > DB > -- > mysql> select * from cluster_details; > +++-+---+ > | id | cluster_id | name| > value | > +++-+---+ > | 1 | 1 | cpuOvercommitRatio | > 1.0 | > | 2 | 1 | memoryOvercommitRatio | > 1.0 | > | 3 | 2 | cpuOvercommitRatio | > 1.0 | > | 4 | 2 | memoryOvercommitRatio | > 1.0 | > | 5 | 1 | cluster.cpu.allocated.capacity.disablethreshold | > NULL | > | 6 | 2 | cluster.cpu.allocated.capacity.disablethreshold | > NULL | > | 7 | 1 | cluster.memory.allocated.capacity.disablethreshold | > NULL | > | 8 | 1 | cluster.cpu.allocated.capacity.notificationthreshold| > 0.85 | > | 9 | 2 | cluster.cpu.allocated.capacity.notificationthreshold| > NULL | > | 10 | 2 | cluster.memory.allocated.capacity.disablethreshold | > 0.85 | > | 11 | 2 | cluster.memory.allocated.capacity.notificationthreshold | > NULL | > +++-+---+ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2697) cluster id in alert message is null {alertType:: 1 // dataCenterId:: 1 // podId:: 1 // clusterId:: null }
prashant kumar mishra created CLOUDSTACK-2697:
-
Summary: cluster id in alert message is null {alertType:: 1 //
dataCenterId:: 1 // podId:: 1 // clusterId:: null }
Key: CLOUDSTACK-2697
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2697
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server
Affects Versions: 4.2.0
Reporter: prashant kumar mishra
Priority: Minor
Fix For: 4.2.0
Attachments: logs.rar
Cluster id should not be null in Alert message.
Snippet of log
2013-05-27 13:13:19,879 WARN [apache.cloudstack.alerts] (CapacityChecker:null)
alertType:: 1 // dataCenterId:: 1 // podId:: 1 // clusterId:: null //
message:: System Alert: Low Unallocated CPU in cluster cluster pod pod of
availability zone pod
2013-05-27 13:13:19,890 DEBUG [cloud.alert.AlertManagerImpl]
(CapacityChecker:null) Have already sent: 1 emails for alert type '1' --
skipping send email
2013-05-27 13:13:19,954 DEBUG [cloud.alert.AlertManagerImpl]
(CapacityChecker:null) System Alert: Low Unallocated CPU in cluster cluster2
pod pod of availability zone pod
2013-05-27 13:13:19,954 DEBUG [cloud.alert.AlertManagerImpl]
(CapacityChecker:null) Unallocated CPU is low, total: 9576 Mhz, used: 2000 Mhz
(20.89%)
2013-05-27 13:13:19,955 WARN [apache.cloudstack.alerts] (CapacityChecker:null)
alertType:: 1 // dataCenterId:: 1 // podId:: 1 // clusterId:: null //
message:: System Alert: Low Unallocated CPU in cluster cluster2 pod pod of
availability zone pod
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2696) default value of cluster.memory.allocated.capacity.notificationthreshold is getting set to 0.75 instead of taking value from Global parameter "cluster.memory.alloca
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-2696: -- Attachment: (was: logs.rar) > default value of cluster.memory.allocated.capacity.notificationthreshold is > getting set to 0.75 instead of taking value from Global parameter > "cluster.memory.allocated.capacity.notificationthreshold" > > > Key: CLOUDSTACK-2696 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2696 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, UI >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra > Fix For: 4.2.0 > > Attachments: logs.rar > > > Steps to reproduce > --- > 1- set global parameter > "cluster.memory.allocated.capacity.notificationthreshold" to some value say > 0.2 > 2-Set cluster level parameter > "cluster.memory.allocated.capacity.notificationthreshold" to "space" > Expected > -- > cluster.memory.allocated.capacity.notificationthreshold should be set to > 0.2(global parameter) > Actual > --- > cluster.memory.allocated.capacity.notificationthreshold is getting set to > 0.75,DB shows NULL in value field > DB > -- > mysql> select * from cluster_details; > +++-+---+ > | id | cluster_id | name| > value | > +++-+---+ > | 1 | 1 | cpuOvercommitRatio | > 1.0 | > | 2 | 1 | memoryOvercommitRatio | > 1.0 | > | 3 | 2 | cpuOvercommitRatio | > 1.0 | > | 4 | 2 | memoryOvercommitRatio | > 1.0 | > | 5 | 1 | cluster.cpu.allocated.capacity.disablethreshold | > NULL | > | 6 | 2 | cluster.cpu.allocated.capacity.disablethreshold | > NULL | > | 7 | 1 | cluster.memory.allocated.capacity.disablethreshold | > NULL | > | 8 | 1 | cluster.cpu.allocated.capacity.notificationthreshold| > 0.85 | > | 9 | 2 | cluster.cpu.allocated.capacity.notificationthreshold| > NULL | > | 10 | 2 | cluster.memory.allocated.capacity.disablethreshold | > 0.85 | > | 11 | 2 | cluster.memory.allocated.capacity.notificationthreshold | > NULL | > +++-+---+ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2698) [RouterVM] In multi-cluster environment with disabled cluster fails with error "javax.persistence.EntityExistsException: Entity already exists:"
venkata swamybabu budumuru created CLOUDSTACK-2698: -- Summary: [RouterVM] In multi-cluster environment with disabled cluster fails with error "javax.persistence.EntityExistsException: Entity already exists:" Key: CLOUDSTACK-2698 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2698 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Environment: commit 80a3c0535e0a8ad3edba3713a61d063a176191d8 Reporter: venkata swamybabu budumuru Priority: Critical Fix For: 4.2.0 Steps to reproduce: 1. Have CloudStack with one advanced zone having 2 clusters - VMware cluster with 1 host - XenServer cluster with 1 host 2. Make sure systemvm and at least one router came up on VMware 3. Disable and unmanage VMware cluster 4. Try to deploy a VPC router Observations:- (i) Even though the VMware cluster is disabled it still tried to bring up system VM template of type VMware hypervisor and it failed to find a suitable host and failed. Here is the snippet of management server log. 2013-05-27 11:41:50,144 DEBUG [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-37:job-35) Allocating the domR with the hypervisor type VMware 2013-05-27 11:41:50,150 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-37:job-35) Allocating entries for VM: VM[DomainRouter|r-20-VM] 2013-05-27 11:41:50,156 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-37:job-35) Allocating nics for VM[DomainRouter|r-20-VM] 2013-05-27 11:41:50,157 DEBUG [cloud.network.NetworkManagerImpl] (Job-Executor-37:job-35) Allocating nic for vm VM[DomainRouter|r-20-VM] in network Ntwk[202|Control|3] with requested profile null 2013-05-27 11:41:50,171 DEBUG [cloud.network.NetworkManagerImpl] (Job-Executor-37:job-35) Allocating nic for vm VM[DomainRouter|r-20-VM] in network Ntwk[200|Public|1] with requested profile NicProfile[0-0-null-10.147.44.68-vlan://44 2013-05-27 11:41:50,184 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-37:job-35) Allocaing disks for VM[DomainRouter|r-20-VM] 2013-05-27 11:41:50,200 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-37:job-35) Allocation completed for VM: VM[DomainRouter|r-20-VM] 2013-05-27 11:41:50,200 DEBUG [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-37:job-35) Starting router VM[DomainRouter|r-20-VM] 2013-05-27 11:41:50,207 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-37:job-35) VM state transitted from :Stopped to Starting with event: StartRequestedvm's original host id: null new host id: null host id before state transition: null 2013-05-27 11:41:50,207 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-37:job-35) Successfully transitioned to start state for VM[DomainRouter|r-20-VM] reservation id = 9963d5e7-0045-4d19-87fb-8280b0ba008c 2013-05-27 11:41:50,215 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-37:job-35) Trying to deploy VM, vm has dcId: 1 and podId: null 2013-05-27 11:41:50,215 DEBUG [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-37:job-35) Deploy avoids pods: null, clusters: null, hosts: null 2013-05-27 11:41:50,218 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-37:job-35) Deploy avoids pods: null, clusters: null, hosts: null 2013-05-27 11:41:50,220 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-37:job-35) DeploymentPlanner allocation algorithm: com.cloud.deploy.FirstFitPlanner_EnhancerByCloudStack_10a196b5@1f54ce2a 2013-05-27 11:41:50,220 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-37:job-35) Trying to allocate a host and storage pools from dc:1, pod:null,cluster:null, requested cpu: 500, requested ram: 134217728 2013-05-27 11:41:50,220 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-37:job-35) Is ROOT volume READY (pool already allocated)?: No 2013-05-27 11:41:50,220 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-37:job-35) Searching all possible resources under this Zone: 1 2013-05-27 11:41:50,221 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-37:job-35) Listing clusters in order of aggregate capacity, that have (atleast one host with) enough CPU and RAM capacity under this Zone: 1 2013-05-27 11:41:50,235 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-37:job-35) Checking resources in Cluster: 1 under Pod: 1 2013-05-27 11:41:50,236 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-37:job-35 FirstFitRoutingAllocator) Looking for hosts in dc: 1 pod:1 cluster:1 2013-05-27 11:41:50,240 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-37:job-35 FirstFitRoutingAllocator) FirstFitAllocator has 0 hosts to check for allocation: [] 2013-05-27 11:41:50,243 DEBUG [allocato
[jira] [Updated] (CLOUDSTACK-2698) [RouterVM] In multi-cluster environment with disabled cluster fails with error "javax.persistence.EntityExistsException: Entity already exists:"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] venkata swamybabu budumuru updated CLOUDSTACK-2698: --- Attachment: logs.tgz > [RouterVM] In multi-cluster environment with disabled cluster fails with > error "javax.persistence.EntityExistsException: Entity already exists:" > > > Key: CLOUDSTACK-2698 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2698 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 > Environment: commit 80a3c0535e0a8ad3edba3713a61d063a176191d8 >Reporter: venkata swamybabu budumuru >Priority: Critical > Fix For: 4.2.0 > > Attachments: logs.tgz > > > Steps to reproduce: > 1. Have CloudStack with one advanced zone having 2 clusters > - VMware cluster with 1 host > - XenServer cluster with 1 host > 2. Make sure systemvm and at least one router came up on VMware > 3. Disable and unmanage VMware cluster > 4. Try to deploy a VPC router > Observations:- > (i) Even though the VMware cluster is disabled it still tried to bring up > system VM template of type VMware hypervisor and it failed to find a suitable > host and failed. > Here is the snippet of management server log. > 2013-05-27 11:41:50,144 DEBUG > [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-37:job-35) > Allocating the domR with the hypervisor type VMware > 2013-05-27 11:41:50,150 DEBUG [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-37:job-35) Allocating entries for VM: VM[DomainRouter|r-20-VM] > 2013-05-27 11:41:50,156 DEBUG [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-37:job-35) Allocating nics for VM[DomainRouter|r-20-VM] > 2013-05-27 11:41:50,157 DEBUG [cloud.network.NetworkManagerImpl] > (Job-Executor-37:job-35) Allocating nic for vm VM[DomainRouter|r-20-VM] in > network Ntwk[202|Control|3] with requested profile null > 2013-05-27 11:41:50,171 DEBUG [cloud.network.NetworkManagerImpl] > (Job-Executor-37:job-35) Allocating nic for vm VM[DomainRouter|r-20-VM] in > network Ntwk[200|Public|1] with requested profile > NicProfile[0-0-null-10.147.44.68-vlan://44 > 2013-05-27 11:41:50,184 DEBUG [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-37:job-35) Allocaing disks for VM[DomainRouter|r-20-VM] > 2013-05-27 11:41:50,200 DEBUG [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-37:job-35) Allocation completed for VM: > VM[DomainRouter|r-20-VM] > 2013-05-27 11:41:50,200 DEBUG > [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-37:job-35) > Starting router VM[DomainRouter|r-20-VM] > 2013-05-27 11:41:50,207 DEBUG [cloud.capacity.CapacityManagerImpl] > (Job-Executor-37:job-35) VM state transitted from :Stopped to Starting with > event: StartRequestedvm's original host id: null new host id: null host id > before state transition: null > 2013-05-27 11:41:50,207 DEBUG [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-37:job-35) Successfully transitioned to start state for > VM[DomainRouter|r-20-VM] reservation id = 9963d5e7-0045-4d19-87fb-8280b0ba008c > 2013-05-27 11:41:50,215 DEBUG [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-37:job-35) Trying to deploy VM, vm has dcId: 1 and podId: null > 2013-05-27 11:41:50,215 DEBUG [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-37:job-35) Deploy avoids pods: null, clusters: null, hosts: null > 2013-05-27 11:41:50,218 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-37:job-35) Deploy avoids pods: null, clusters: null, hosts: null > 2013-05-27 11:41:50,220 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-37:job-35) DeploymentPlanner allocation algorithm: > com.cloud.deploy.FirstFitPlanner_EnhancerByCloudStack_10a196b5@1f54ce2a > 2013-05-27 11:41:50,220 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-37:job-35) Trying to allocate a host and storage pools from > dc:1, pod:null,cluster:null, requested cpu: 500, requested ram: 134217728 > 2013-05-27 11:41:50,220 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (Job-Executor-37:job-35) Is ROOT volume READY (pool already allocated)?: No > 2013-05-27 11:41:50,220 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-37:job-35) Searching all possible resources under this Zone: 1 > 2013-05-27 11:41:50,221 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-37:job-35) Listing clusters in order of aggregate capacity, > that have (atleast one host with) enough CPU and RAM capacity under this > Zone: 1 > 2013-05-27 11:41:50,235 DEBUG [cloud.deploy.DeploymentPlanningMan
[jira] [Created] (CLOUDSTACK-2699) [VPC][Private gateway]Unable to create static nat rule for a private gateway after VPC VR is rebooted.
manasaveloori created CLOUDSTACK-2699:
-
Summary: [VPC][Private gateway]Unable to create static nat rule
for a private gateway after VPC VR is rebooted.
Key: CLOUDSTACK-2699
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2699
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Network Controller
Affects Versions: 4.2.0
Reporter: manasaveloori
Priority: Critical
Fix For: 4.2.0
1. Have a CS with advanced zone.
2. Create a VPC .
3. Add a private gateway to the vpc.
4. Create a static nat.Verify the static nat rule in VR.( ip route show
table static_route)
5. Now reboot the VPC VR fron CS.
6. Try to create a static nat rule for a private gateway now.
Observations:
1. The configured static nat rules are visible in UI but not getting
configured back in VR after reboot.( ip route show table static_route is
empty)
2. Aslo after the VR is rebooted ,unable to add any more static
routes.giving following exception:
2013-05-27 23:05:53,489 DEBUG [agent.transport.Request] (DirectAgent-404:null)
Seq 3-1205667013: Processing: { Ans: , MgmtId: 6805241462820, via: 3, Ver: v1,
Flags: 0,
[{"routing.SetStaticRouteAnswer":{"results":["Failed","Failed","Failed","Failed","Failed"],"result":false,"wait":0}}]
}
2013-05-27 23:05:53,489 DEBUG [agent.transport.Request]
(Job-Executor-77:job-63) Seq 3-1205667013: Received: { Ans: , MgmtId:
6805241462820, via: 3, Ver: v1, Flags: 0, { SetStaticRouteAnswer } }
2013-05-27 23:05:53,504 ERROR [cloud.async.AsyncJobManagerImpl]
(Job-Executor-77:job-63) Unexpected exception while executing
org.apache.cloudstack.api.command.user.vpc.CreateStaticRouteCmd
com.cloud.utils.exception.CloudRuntimeException: Failed to apply static routes
in vpc [VPC [1-vpc1]
at
com.cloud.network.element.VpcVirtualRouterElement.applyStaticRoutes(VpcVirtualRouterElement.java:441)
at
com.cloud.network.vpc.VpcManagerImpl.applyStaticRoutes(VpcManagerImpl.java:1638)
at
com.cloud.network.vpc.VpcManagerImpl.applyStaticRoutes(VpcManagerImpl.java:1601)
at
com.cloud.network.vpc.VpcManagerImpl.applyStaticRoutes(VpcManagerImpl.java:1586)
at
com.cloud.network.vpc.VpcManagerImpl.revokeStaticRoute(VpcManagerImpl.java:1663)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
org.apache.cloudstack.api.command.user.vpc.CreateStaticRouteCmd.execute(CreateStaticRouteCmd.java:108)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
2013-05-27 23:05:53,506 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-77:job-63) Complete async job-63, jobStatus: 2, resultCode: 530,
result: Error Code: 530 Error text: Failed to apply static routes in vpc [VPC
[1-vpc1]
2013-05-27 23:05:53,533 DEBUG [cloud.async.SyncQueueManagerImpl]
(Job-Executor-77:job-63) Sync queue (1) is currently empty
2013-05-27 23:05:53,826 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-112:null) Ping from 3
2013-05-27 23:05:54,360 DEBUG [cloud.api.ApiServlet] (catalina-exec-3:null)
===START=== 10.252.241.232 -- GET
command=queryAsyncJobResult&jobId=43385df3-eb7f-44e3-a092-
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2672) Adding isVolatile parameter in service offering response object
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667741#comment-13667741 ] ASF subversion and git services commented on CLOUDSTACK-2672: - Commit 82974458a675c52e888c91f569f0f1ca278197d7 in branch refs/heads/master from [~harikrishna.patnala] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8297445 ] CLOUDSTACK-2672: Adding isVolatile parameter in service offering response object Signed off by :- Nitin Mehta > Adding isVolatile parameter in service offering response object > --- > > Key: CLOUDSTACK-2672 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2672 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.2.0 >Reporter: Harikrishna Patnala >Assignee: Harikrishna Patnala >Priority: Minor > Fix For: 4.2.0 > > > Missing isVolatile parameter in the response of service offering. > Need to add this in service offering response object. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2700) on network/vpc delete, portable IP should be still associated with account
Murali Reddy created CLOUDSTACK-2700: Summary: on network/vpc delete, portable IP should be still associated with account Key: CLOUDSTACK-2700 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2700 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Reporter: Murali Reddy Assignee: Murali Reddy Priority: Critical Fix For: 4.2.0 Unlike public ip which gets dis-associated (released) with the account on network/VPC delete, portable IP should continue to be associated with the account even when the network/VPC with which it is currently associated in deleted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2662) Preferred implicit dedication fails with insufficient capacity even if shared hosts are available.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-2662: --- Component/s: (was: Install and Setup) Management Server > Preferred implicit dedication fails with insufficient capacity even if shared > hosts are available. > -- > > Key: CLOUDSTACK-2662 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2662 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 >Reporter: Kiran Koneti >Assignee: Rajesh Battala >Priority: Blocker > Fix For: 4.2.0 > > > Below are the steps followed : > 1)Created a Xen Advanced Zone setup with one cluster and hosts. > 2)The host1 has the system VM's deployed and a VM with the root domain. > 3)Then created two accounts kiran and kiran2 respectively. > 4)Was able to deploy VM's using the preferred and strict implicit dedication > for the Account kiran. > 5)Then tried to deploy a VM fro the account kiran2 using the preferred > implicit service offering. > 6)The VM deployment fails saying insufficient resources even we have the host > 1 in the shared state. > the below error message is observed > "2013-05-24 16:15:09,565 INFO [user.vm.DeployVMCmd] (Job-Executor-3:job-22) > com.cloud.exception.InsufficientServerCapacityException: Unable to create a > deployment for VM[U ser|win832pref2]Scope=interface com.cloud.dc.DataCenter; > id=1 > 2013-05-24 16:15:09,565 INFO [user.vm.DeployVMCmd] (Job-Executor-3:job-22) > Unable to create a deployment for VM[User|win832pref2] > com.cloud.exception.InsufficientServerCapacityException: Unable to create a > deployment for VM[User|win832pref2]Scope=interface com.cloud.dc.DataCenter; > id=1 > at > org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.reserveVirtualMachine(VMEntityManagerImpl.java:212) > at > org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.reserve(VirtualMachineEntityImpl.java:198) > at > com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3206) > at > com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2745) > at > com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2731) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) > at > org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:420) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155) > at > com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679)" > The op_host_planner_reservation shows the host dedication details as below: > mysql> select * from op_host_planner_reservation; > +++++-++ > | id | data_center_id | pod_id | cluster_id | host_id | resource_usage | > +++++-++ > | 1 | 1 | 1 | 1 | 1 | Shared | > | 2 | 1 | 1 | 1 | 5 | Dedicated | > +++++-++ > 2 rows in set (0.00 sec) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-2662) Preferred implicit dedication fails with insufficient capacity even if shared hosts are available.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala reassigned CLOUDSTACK-2662: -- Assignee: Rajesh Battala > Preferred implicit dedication fails with insufficient capacity even if shared > hosts are available. > -- > > Key: CLOUDSTACK-2662 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2662 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.2.0 >Reporter: Kiran Koneti >Assignee: Rajesh Battala >Priority: Blocker > Fix For: 4.2.0 > > > Below are the steps followed : > 1)Created a Xen Advanced Zone setup with one cluster and hosts. > 2)The host1 has the system VM's deployed and a VM with the root domain. > 3)Then created two accounts kiran and kiran2 respectively. > 4)Was able to deploy VM's using the preferred and strict implicit dedication > for the Account kiran. > 5)Then tried to deploy a VM fro the account kiran2 using the preferred > implicit service offering. > 6)The VM deployment fails saying insufficient resources even we have the host > 1 in the shared state. > the below error message is observed > "2013-05-24 16:15:09,565 INFO [user.vm.DeployVMCmd] (Job-Executor-3:job-22) > com.cloud.exception.InsufficientServerCapacityException: Unable to create a > deployment for VM[U ser|win832pref2]Scope=interface com.cloud.dc.DataCenter; > id=1 > 2013-05-24 16:15:09,565 INFO [user.vm.DeployVMCmd] (Job-Executor-3:job-22) > Unable to create a deployment for VM[User|win832pref2] > com.cloud.exception.InsufficientServerCapacityException: Unable to create a > deployment for VM[User|win832pref2]Scope=interface com.cloud.dc.DataCenter; > id=1 > at > org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.reserveVirtualMachine(VMEntityManagerImpl.java:212) > at > org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.reserve(VirtualMachineEntityImpl.java:198) > at > com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3206) > at > com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2745) > at > com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2731) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) > at > org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:420) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155) > at > com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679)" > The op_host_planner_reservation shows the host dedication details as below: > mysql> select * from op_host_planner_reservation; > +++++-++ > | id | data_center_id | pod_id | cluster_id | host_id | resource_usage | > +++++-++ > | 1 | 1 | 1 | 1 | 1 | Shared | > | 2 | 1 | 1 | 1 | 5 | Dedicated | > +++++-++ > 2 rows in set (0.00 sec) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2700) on network/vpc delete, portable IP should be still associated with account
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy resolved CLOUDSTACK-2700. -- Resolution: Fixed fixed with 88c2143e9f3b14a3bc91f8e486e3574dfa37 > on network/vpc delete, portable IP should be still associated with account > -- > > Key: CLOUDSTACK-2700 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2700 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 >Reporter: Murali Reddy >Assignee: Murali Reddy >Priority: Critical > Fix For: 4.2.0 > > > Unlike public ip which gets dis-associated (released) with the account on > network/VPC delete, portable IP should continue to be associated with the > account even when the network/VPC with which it is currently associated in > deleted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2700) on network/vpc delete, portable IP should be still associated with account
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667745#comment-13667745 ] ASF subversion and git services commented on CLOUDSTACK-2700: - Commit 88c2143e9f3b14a3bc91f8e486e3574dfa37 in branch refs/heads/master from Murali Reddy [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=88c ] CLOUDSTACK-2700:on network/vpc delete, portable IP should be still associated with account Unlike public ip which gets dis-associated (released) with the account on network/VPC delete, portable IP should continue to be associated with the account even when the network/VPC with which it is currently associated in deleted. This fix ensures portable IP are associated to account even after network/vpc is deleted. > on network/vpc delete, portable IP should be still associated with account > -- > > Key: CLOUDSTACK-2700 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2700 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 >Reporter: Murali Reddy >Assignee: Murali Reddy >Priority: Critical > Fix For: 4.2.0 > > > Unlike public ip which gets dis-associated (released) with the account on > network/VPC delete, portable IP should continue to be associated with the > account even when the network/VPC with which it is currently associated in > deleted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2672) Adding isVolatile parameter in service offering response object
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harikrishna Patnala resolved CLOUDSTACK-2672. - Resolution: Fixed > Adding isVolatile parameter in service offering response object > --- > > Key: CLOUDSTACK-2672 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2672 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.2.0 >Reporter: Harikrishna Patnala >Assignee: Harikrishna Patnala >Priority: Minor > Fix For: 4.2.0 > > > Missing isVolatile parameter in the response of service offering. > Need to add this in service offering response object. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2621) [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/CIDR
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667776#comment-13667776
]
Bharat Kumar commented on CLOUDSTACK-2621:
--
fix in review board
> [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/CIDR
> ---
>
> Key: CLOUDSTACK-2621
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2621
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: Latest build from
> master:CloudStack-non-OSS-MASTER-394-rhel6.3.tar.gz
>Reporter: Sanjeev N
>Assignee: Bharat Kumar
>Priority: Critical
> Fix For: 4.2.0
>
>
> Failed to delete guest IP range from a new subnet/CIDR
> Steps to Reproduce:
> =
> 1.Bring up CS in basic zone with xen61 server
> 2.Exhaust all guest IP addresses from the primary guest IP range
> 3.Add new guest IP range in new CIDR different from primary CIDR
> 4.Deploy guest vm
> 5.Set expunge interval to a small value say 60 secs.
> 6.Destroy the guest vm deployed at step4
> 7.Try to delete the guest ip range added at step3
> Expected Result:
> ==
> IP alis created on the VR should be deleted and IP Range deletion should be
> successful
> Actual Result:
>
> IP alias deletion was successful but IP range deletion was failed
> Observations:
> ===
> IP range deletion failed with the following messages:
> Failed to delete the vlan range as we could not free the ip used to provide
> the dhcp service.
> One of the ips in the range is used to provide Dhcp service to this subnet.
> cannot delete this range
> Log snippet from the management server:
> 2013-05-22 13:01:16,447 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null)
> ===START=== 10.146.0.15 -- GET
> command=deleteVlanIpRange&id=493e10d8-0f88-44f1-a827-3d184552b64b&response=json&sessionkey=mG6gSeA59KqMK1zeGAVSG7pJs2g%3D&_=1369222331305
> 2013-05-22 13:01:16,505 DEBUG
> [network.router.VirtualNetworkApplianceManagerImpl] (catalina-exec-1:null)
> Found0ip Aliases to apply on the router as a part of dhco configuration
> 2013-05-22 13:01:16,513 DEBUG
> [network.router.VirtualNetworkApplianceManagerImpl] (catalina-exec-1:null)
> Found1ip Aliases to apply on the router as a part of dhco configuration
> 2013-05-22 13:01:16,608 DEBUG [agent.transport.Request]
> (catalina-exec-1:null) Seq 1-1277100090: Sending { Cmd , MgmtId:
> 6615759585382, via: 1, Ver: v1, Flags: 11,
> [{"routing.DeleteIpAliasCommand":{"routerip":"10.147.43.6","deleteIpAliasTOs":[],"createIpAliasTos":[{"routerip":"10.147.43.132","netmask":"255.255.255.192","alias_count":"18"}],"accessDetails":{"router.guest.ip":"10.147.43.6","zone.network.type":"Basic","router.name":"r-4-VM","router.ip":"169.254.3.122"},"wait":0}},{"routing.DnsMasqConfigCommand":{"domain":"cs1sandbox.xen","dns1":"10.103.128.16","internal_dns1":"10.103.128.16","dnsmasqTOs":[{"routerIp":"10.147.43.6","gateway":"10.147.43.1","netmask":"255.255.255.128"},{"routerIp":"10.147.43.129","gateway":"10.147.43.129","netmask":"255.255.255.192"}],"accessDetails":{"router.guest.ip":"10.147.43.6","zone.network.type":"Basic","router.name":"r-4-VM","router.ip":"169.254.3.122"},"wait":0}}]
> }
> 2013-05-22 13:01:16,614 DEBUG [agent.transport.Request]
> (catalina-exec-1:null) Seq 1-1277100090: Executing: { Cmd , MgmtId:
> 6615759585382, via: 1, Ver: v1, Flags: 11,
> [{"routing.DeleteIpAliasCommand":{"routerip":"10.147.43.6","deleteIpAliasTOs":[],"createIpAliasTos":[{"routerip":"10.147.43.132","netmask":"255.255.255.192","alias_count":"18"}],"accessDetails":{"router.guest.ip":"10.147.43.6","zone.network.type":"Basic","router.name":"r-4-VM","router.ip":"169.254.3.122"},"wait":0}},{"routing.DnsMasqConfigCommand":{"domain":"cs1sandbox.xen","dns1":"10.103.128.16","internal_dns1":"10.103.128.16","dnsmasqTOs":[{"routerIp":"10.147.43.6","gateway":"10.147.43.1","netmask":"255.255.255.128"},{"routerIp":"10.147.43.129","gateway":"10.147.43.129","netmask":"255.255.255.192"}],"accessDetails":{"router.guest.ip":"10.147.43.6","zone.network.type":"Basic","router.name":"r-4-VM","router.ip":"169.254.3.122"},"wait":0}}]
> }
> 2013-05-22 13:01:16,617 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-3:null) Seq 1-1277100090: Executing request
> 2013-05-22 13:01:18,856 DEBUG [storage.secondary.SecondaryStorageManagerImpl]
> (secstorage-1:null) Zone 1 is ready to launch secondary storage VM
> 2013-05-22 13:01:19,327 DEBUG [cloud.consoleproxy.ConsoleProxyManagerImpl]
> (consoleproxy-1:null) Zone 1 is ready to launch console proxy
> 2013-05-22 13:01:19,583 DEBUG [agent.man
[jira] [Created] (CLOUDSTACK-2701) Enable storage migration for VMware resources
Sateesh Chodapuneedi created CLOUDSTACK-2701: Summary: Enable storage migration for VMware resources Key: CLOUDSTACK-2701 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2701 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.2.0 Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: 4.2.0 Storage vMotion allows VMs to be moved from one host to another, along with storage across datastores in datacenter. It provides the option to live migrate a VM’s disks along with the VM itself. It is now possible to migrate a VM from one datastore to another, or even to migrate a VM’s disks from one datastore to another with VM running on same host, all while the VM is running. This issue is to track the support of storage vMotion for VMware resources in cloudstack. Till now ticket CLOUDSTACK-659 was using in all code commits done to branch vmware-storage-motion. Just now created this ticket to deal with specific areas in implementation that is well contained and limited to VMware resource only. Commits related to VmwareStorageMotionStrategy class and it's implementation along with commands MigrateWithStorageCommand and MigrateVolumeCommand are done under CLOUDSTACK-659 ticket. Release Planning: Functional Spec: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Enabling+Storage+XenMotion+for+XenServer (section VMware resource) Feature branch: vmware-storage-motion -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2701) Enable storage migration for VMware resources
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667779#comment-13667779 ] ASF subversion and git services commented on CLOUDSTACK-2701: - Commit c6d7a751b51582560cd0483c7ebbdcd7b43b6b1e in branch refs/heads/vmware-storage-motion from Sateesh Chodapuneedi [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c6d7a75 ] CLOUDSTACK-2701 - Enable storage migration for VMware resources Fixing attach volume and delete volume cases for volumes that are moved off original path in datastore when created. If volume is not found in root directory or datastore, do search in sub folders. > Enable storage migration for VMware resources > - > > Key: CLOUDSTACK-2701 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2701 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0 >Reporter: Sateesh Chodapuneedi >Assignee: Sateesh Chodapuneedi > Fix For: 4.2.0 > > > Storage vMotion allows VMs to be moved from one host to another, along with > storage across datastores in datacenter. It provides the option to live > migrate a VM’s disks along with the VM itself. > It is now possible to migrate a VM from one datastore to another, or even to > migrate a VM’s disks from one datastore to another with VM running on same > host, all while the VM is running. > This issue is to track the support of storage vMotion for VMware resources in > cloudstack. Till now ticket CLOUDSTACK-659 was using in all code commits done > to branch vmware-storage-motion. Just now created this ticket to deal with > specific areas in implementation that is well contained and limited to VMware > resource only. Commits related to VmwareStorageMotionStrategy class and it's > implementation along with commands MigrateWithStorageCommand and > MigrateVolumeCommand are done under CLOUDSTACK-659 ticket. > Release Planning: > Functional Spec: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Enabling+Storage+XenMotion+for+XenServer > (section VMware resource) > Feature branch: vmware-storage-motion -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2548) [Automation] Failed to delete public IP range
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667780#comment-13667780 ] Bharat Kumar commented on CLOUDSTACK-2548: -- https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=47a562a2c043c32fdf1f3108552cfce170b8b27e > [Automation] Failed to delete public IP range > -- > > Key: CLOUDSTACK-2548 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2548 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 > Environment: Master build : Latest > Issue found : During BVT automation run on KVM >Reporter: Rayees Namathponnan >Assignee: Bharat Kumar >Priority: Blocker > Fix For: 4.2.0 > > > Test case : test/integration/smoke/test_public_ip_range.py > Steps to reproduce > Step 1 : Create advance zone, and add IP range [In my case added > 10.223.122.124 to 10.223.122.126] > Step 2 : Delete this IP range > Actual Result > Release IP range operation failed with below error > "One of the ips in the range is used to provide Dhcp service to this subnet. > cannot delete this range as" > If you look the DB, ip range 10.223.122.124 to 10.223.122.126 is not > allocated > mysql> select * from user_ip_address where state!="Free"; > ++--++---+---+++-+++---+---+-+---++-+---++---+ > | id | uuid | account_id | domain_id | > public_ip_address | data_center_id | source_nat | allocated | > vlan_db_id | one_to_one_nat | vm_id | state | mac_address | > source_network_id | network_id | physical_network_id | is_system | vpc_id | > dnat_vmip | > ++--++---+---+++-+++---+---+-+---++-+---++---+ > | 2 | ddd29f48-54ba-4b76-b493-c62948f1 | 38 | 1 | > 10.223.122.67 | 1 | 1 | 2013-05-16 18:01:34 | >1 | 0 | NULL | Allocated | 60 | 200 | >241 | 200 | 0 | NULL | NULL | > | 3 | e4f7899b-1d5b-4c7c-91bd-38af7db1945a | 4 | 1 | > 10.223.122.68 | 1 | 1 | 2013-05-16 03:54:34 | >1 | 0 | NULL | Releasing | 61 | 200 | >209 | 200 | 0 | NULL | NULL | > | 4 | ab3b333a-bad2-427f-ad7d-6d9f3cac5336 | 1 | 1 | > 10.223.122.69 | 1 | 0 | 2013-05-16 04:56:39 | >1 | 0 | NULL | Allocated | 62 | 200 | > NULL | 200 | 0 | NULL | NULL | > | 6 | 73fe34aa-bdce-4f58-bc54-40fe6584a2da | 2 | 1 | > 10.223.122.71 | 1 | 1 | 2013-05-16 05:43:59 | >1 | 0 | NULL | Allocated | 64 | 200 | >230 | 200 | 0 | NULL | NULL | > | 23 | b97b3062-a82d-487a-8d56-4355ce72d3c7 | 2 | 1 | > 10.223.122.88 | 1 | 1 | 2013-05-16 05:23:12 | >1 | 0 | NULL | Allocated | 81 | 200 | >227 | 200 | 0 | NULL | NULL | > | 32 | 3d1f0625-90a0-4632-9cfb-aed018efa51c | 2 | 1 | > 10.223.122.97 | 1 | 1 | 2013-05-16 05:52:11 | >1 | 0 | NULL | Allocated | 90 | 200 | >232 | 200 | 0 | NULL | NULL | > | 52 | 851757d9-92f2-493c-98f6-3bd01b0c2d3b | 1 | 1 | > 10.223.122.117| 1 | 0 | 2013-05-16 04:54:09 | >1 | 0 | NULL | Allocated | 110 | 200 | > NULL | 200 | 0 | NULL | NULL | > | 60 | eede24f6-6587-4f75-8e2a-7063ffd2c833 | 1 | 1 | > 10.223.121.132| 2 | 0 | 2013-05-16 03:39:09 | >2 | 0 | NULL | Allocated | 61 | 204 | > NULL | 201 | 0 | NULL | NULL | > | 63 | a720338f-15f8-4d47-ac
[jira] [Resolved] (CLOUDSTACK-2548) [Automation] Failed to delete public IP range
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-2548. -- Resolution: Fixed > [Automation] Failed to delete public IP range > -- > > Key: CLOUDSTACK-2548 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2548 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 > Environment: Master build : Latest > Issue found : During BVT automation run on KVM >Reporter: Rayees Namathponnan >Assignee: Bharat Kumar >Priority: Blocker > Fix For: 4.2.0 > > > Test case : test/integration/smoke/test_public_ip_range.py > Steps to reproduce > Step 1 : Create advance zone, and add IP range [In my case added > 10.223.122.124 to 10.223.122.126] > Step 2 : Delete this IP range > Actual Result > Release IP range operation failed with below error > "One of the ips in the range is used to provide Dhcp service to this subnet. > cannot delete this range as" > If you look the DB, ip range 10.223.122.124 to 10.223.122.126 is not > allocated > mysql> select * from user_ip_address where state!="Free"; > ++--++---+---+++-+++---+---+-+---++-+---++---+ > | id | uuid | account_id | domain_id | > public_ip_address | data_center_id | source_nat | allocated | > vlan_db_id | one_to_one_nat | vm_id | state | mac_address | > source_network_id | network_id | physical_network_id | is_system | vpc_id | > dnat_vmip | > ++--++---+---+++-+++---+---+-+---++-+---++---+ > | 2 | ddd29f48-54ba-4b76-b493-c62948f1 | 38 | 1 | > 10.223.122.67 | 1 | 1 | 2013-05-16 18:01:34 | >1 | 0 | NULL | Allocated | 60 | 200 | >241 | 200 | 0 | NULL | NULL | > | 3 | e4f7899b-1d5b-4c7c-91bd-38af7db1945a | 4 | 1 | > 10.223.122.68 | 1 | 1 | 2013-05-16 03:54:34 | >1 | 0 | NULL | Releasing | 61 | 200 | >209 | 200 | 0 | NULL | NULL | > | 4 | ab3b333a-bad2-427f-ad7d-6d9f3cac5336 | 1 | 1 | > 10.223.122.69 | 1 | 0 | 2013-05-16 04:56:39 | >1 | 0 | NULL | Allocated | 62 | 200 | > NULL | 200 | 0 | NULL | NULL | > | 6 | 73fe34aa-bdce-4f58-bc54-40fe6584a2da | 2 | 1 | > 10.223.122.71 | 1 | 1 | 2013-05-16 05:43:59 | >1 | 0 | NULL | Allocated | 64 | 200 | >230 | 200 | 0 | NULL | NULL | > | 23 | b97b3062-a82d-487a-8d56-4355ce72d3c7 | 2 | 1 | > 10.223.122.88 | 1 | 1 | 2013-05-16 05:23:12 | >1 | 0 | NULL | Allocated | 81 | 200 | >227 | 200 | 0 | NULL | NULL | > | 32 | 3d1f0625-90a0-4632-9cfb-aed018efa51c | 2 | 1 | > 10.223.122.97 | 1 | 1 | 2013-05-16 05:52:11 | >1 | 0 | NULL | Allocated | 90 | 200 | >232 | 200 | 0 | NULL | NULL | > | 52 | 851757d9-92f2-493c-98f6-3bd01b0c2d3b | 1 | 1 | > 10.223.122.117| 1 | 0 | 2013-05-16 04:54:09 | >1 | 0 | NULL | Allocated | 110 | 200 | > NULL | 200 | 0 | NULL | NULL | > | 60 | eede24f6-6587-4f75-8e2a-7063ffd2c833 | 1 | 1 | > 10.223.121.132| 2 | 0 | 2013-05-16 03:39:09 | >2 | 0 | NULL | Allocated | 61 | 204 | > NULL | 201 | 0 | NULL | NULL | > | 63 | a720338f-15f8-4d47-acc0-da6a2917406d | 1 | 1 | > 10.223.121.135| 2 | 0 | 2013-05-16 03:39:17 | >2 | 0 | NULL |
[jira] [Commented] (CLOUDSTACK-2620) [Multiple_IP_Ranges] Guest vm's nameserver is not set to VRs guest IP address in case of multiple subnets
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667784#comment-13667784 ] Bharat Kumar commented on CLOUDSTACK-2620: -- fix in review board > [Multiple_IP_Ranges] Guest vm's nameserver is not set to VRs guest IP address > in case of multiple subnets > - > > Key: CLOUDSTACK-2620 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2620 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 > Environment: Build from master branch: > CloudStack-non-OSS-MASTER-394-rhel6.3.tar.gz >Reporter: Sanjeev N >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.2.0 > > > [Multiple_IP_Ranges] Guest vm's nameserver is not set to VRs guest IP address > in case of multiple subnets > Steps to Reproduce: > > 1.Bring up CS in basic zone with Xen61 server > 2.Consume all the guest IP ranges in the existing subnet > 3.Add guest ip range in new CIDR > 4.Deploy guest vm > 5.Verify the nameserver in /etc/resolve.conf in guest vm > Expected Behaviour: > = > nameserver on guest vm should be set to ip alias address on VR > Actual Behaviour: > == > nameserver on guest vm was set to zone level internal DNS ip address instead > of VR's ip alias address. > Observations: > === > Primary ip range: 10.147.43.3-10.147.43.7 GW:10.147.43.1 Netmask: > 255.255.255.128 > New IP Range : 10.147.43.130-10.147.43.133 GW: 10.147.43.129 Netmask: > 255.255.255.192 > When the vm is deployed with IP address from the new CIDR , ip alis on VR got > created with ip address from new CIDR. > ip alias on the VR was set to 10.147.43.132 > root@r-4-VM:/etc# ifconfig > eth0 Link encap:Ethernet HWaddr 06:ba:90:00:00:0e > inet addr:10.147.43.6 Bcast:10.147.43.127 Mask:255.255.255.128 > inet6 addr: fe80::4ba:90ff:fe00:e/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:36018 errors:0 dropped:0 overruns:0 frame:0 > TX packets:1007 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:1919944 (1.8 MiB) TX bytes:46214 (45.1 KiB) > Interrupt:24 > eth0:18 Link encap:Ethernet HWaddr 06:ba:90:00:00:0e > inet addr:10.147.43.132 Bcast:10.147.43.191 Mask:255.255.255.192 > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > Interrupt:24 > During ip alias creation process dnsmasq.conf was re-generated with new ip > range and dhcp-option was set as following: > dhcp-option=6,10.103.128.16,10.103.128.16 > dnsmasq.conf regeneration process is taking DNS values set at zone level and > replacing with the exiting values in the file. Hence guest vms are getting > internal DNS ip address as nemeserver. > Impact: > == > Since guest vms nameserver is set to an IP address other than VR's , vm to vm > communication using domain names will fail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2641) [Multiple_IP_Ranges] Failure in deleting guest IP range should mark nic_ip_alias state to Revoked
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-2641. -- Resolution: Not A Problem > [Multiple_IP_Ranges] Failure in deleting guest IP range should mark > nic_ip_alias state to Revoked > -- > > Key: CLOUDSTACK-2641 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2641 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 > Environment: Latest build from master branch: > CloudStack-non-OSS-MASTER-394-rhel6.3.tar.gz >Reporter: Sanjeev N >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.2.0 > > > Failure in deleting guest IP range should mark ip alias state in nic_ip_alias > table to Revoked > Steps to Reproduce: > = > 1.Bring up CS in basic zone with xenserver 6.1 > 2.Exhaust all the guest IP ranges from the primary IP range added during zone > creation > 3.Add another guest IP range in new CIDR > 4.Deploy guest vm > 5.Set expunge interval to a small value say 60 secs, and restart management > server > 6.Destroy the guest vm deployed at step4 > 7.After vm expunge, delete the guest IP range added at step3 > Expected Result: > = > In case of successful deletion of the guest IP range , ip alias created on VR > should be deleted and the entry from nic_ip_alias table should be removed. > Actual Result: > > Due to bug CLOUDSTACK-2621, IP range deletion failed and alias IP address > remained in allocated state in user_ip_address table but ip alias was removed > from the backend(from the VR). > nic ip alias state shows active in the DB. > Impact: > == > Since the deletion failed, if the user wants to use the ip range and tries to > deploy vm using this guest IP range, guest vms does not get the IP address > since VR does not have ip alias to server dhcp request in this guest range. > CS does not try to recreate ip alias on VR since nic_ip_alias table shows the > state as active. > mysql> select * from nic_ip_alias\G; > *** 1. row *** > id: 1 > uuid: 757537e5-2c30-47ef-9534-9624ff908af0 > nic_id: 9 >ip4_address: 10.147.43.132 >ip6_address: NULL >netmask: 255.255.255.192 >gateway: 10.147.43.129 > start_ip_of_subnet: 10.147.43.129 > network_id: 204 > vmId: 4 >alias_count: 18 >created: 2013-05-22 15:14:21 > account_id: 2 > domain_id: 1 > state: active > 1 row in set (0.00 sec) > ERROR: > No query specified -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2641) [Multiple_IP_Ranges] Failure in deleting guest IP range should mark nic_ip_alias state to Revoked
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667787#comment-13667787 ] Bharat Kumar commented on CLOUDSTACK-2641: -- if the ipalias deletion fails we log it saying that the ip alias cloud not be deleted. and keep the state of the rule as active as it is not deleted on the resource ie host. > [Multiple_IP_Ranges] Failure in deleting guest IP range should mark > nic_ip_alias state to Revoked > -- > > Key: CLOUDSTACK-2641 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2641 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 > Environment: Latest build from master branch: > CloudStack-non-OSS-MASTER-394-rhel6.3.tar.gz >Reporter: Sanjeev N >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.2.0 > > > Failure in deleting guest IP range should mark ip alias state in nic_ip_alias > table to Revoked > Steps to Reproduce: > = > 1.Bring up CS in basic zone with xenserver 6.1 > 2.Exhaust all the guest IP ranges from the primary IP range added during zone > creation > 3.Add another guest IP range in new CIDR > 4.Deploy guest vm > 5.Set expunge interval to a small value say 60 secs, and restart management > server > 6.Destroy the guest vm deployed at step4 > 7.After vm expunge, delete the guest IP range added at step3 > Expected Result: > = > In case of successful deletion of the guest IP range , ip alias created on VR > should be deleted and the entry from nic_ip_alias table should be removed. > Actual Result: > > Due to bug CLOUDSTACK-2621, IP range deletion failed and alias IP address > remained in allocated state in user_ip_address table but ip alias was removed > from the backend(from the VR). > nic ip alias state shows active in the DB. > Impact: > == > Since the deletion failed, if the user wants to use the ip range and tries to > deploy vm using this guest IP range, guest vms does not get the IP address > since VR does not have ip alias to server dhcp request in this guest range. > CS does not try to recreate ip alias on VR since nic_ip_alias table shows the > state as active. > mysql> select * from nic_ip_alias\G; > *** 1. row *** > id: 1 > uuid: 757537e5-2c30-47ef-9534-9624ff908af0 > nic_id: 9 >ip4_address: 10.147.43.132 >ip6_address: NULL >netmask: 255.255.255.192 >gateway: 10.147.43.129 > start_ip_of_subnet: 10.147.43.129 > network_id: 204 > vmId: 4 >alias_count: 18 >created: 2013-05-22 15:14:21 > account_id: 2 > domain_id: 1 > state: active > 1 row in set (0.00 sec) > ERROR: > No query specified -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-1722) NPE during listClusters
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-1722. -- Resolution: Fixed > NPE during listClusters > --- > > Key: CLOUDSTACK-1722 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1722 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 >Reporter: Likitha Shetty >Assignee: Bharat Kumar > > On latest 4.1 > ERROR [cloud.api.ApiServer] (29796423@qtp-31087973-14:) unhandled exception > executing api command: listClusters > java.lang.NullPointerException > at > com.cloud.api.ApiResponseHelper.createClusterResponse(ApiResponseHelper.java:838) > 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:616) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:319) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2648) [Multiple_IP_Ranges] Reboot or start/stop router vm deletes the ip alises created on VR in case of multiple subnets
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667795#comment-13667795 ] Bharat Kumar commented on CLOUDSTACK-2648: -- fix in review board > [Multiple_IP_Ranges] Reboot or start/stop router vm deletes the ip alises > created on VR in case of multiple subnets > --- > > Key: CLOUDSTACK-2648 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2648 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 > Environment: Latest build on master: > CloudStack-non-OSS-MASTER-394-rhel6.3.tar.gz >Reporter: Sanjeev N >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.2.0 > > Attachments: management-server.rar, SMlog > > > Reboot or start/stop router vm deletes the ip alises created on VR in case of > multiple subnets > Steps to Reproduce: > = > 1.Bring up CS in basic zone with xenserver6.1 > 2.Exhaust all the guest IP addresses in primary ip range by deploying guest > vms > 3.Add new guest IP range in new subnet > 4.Deploy guest vms using the ip addresses from the new range > 5.Reboot or stop/start VR > Observations: > > After step4 ip alias gets created on VR with IP address from the new subnet. > After reboot or stop/start of the VR ip alias is getting removed from the VR. > Verified the SMlog and found the following command getting executed with the > VR is rebooted related to ip alias: > [22250] 2013-05-23 11:13:30.654474 VMOPS enter deleteipAlias > [22250] 2013-05-23 11:13:30.654559 ['bin/bash', > '/opt/xensource/bin/deleteipAlias.sh', '169.254.3.21', '', > '18:10.147.43.132:255.255.255.192-21:10.147.43.195:255.255.255.192-'] > [22250] 2013-05-23 11:13:31.338199pread SUCCESS > [22250] 2013-05-23 11:13:31.338311 VMOPS exit deleteipAlias > IP aliases information is being passed to deleteipAlias.sh and due to which > ip alias are getting removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2701) Enable storage migration for VMware resources
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667873#comment-13667873 ] ASF subversion and git services commented on CLOUDSTACK-2701: - Commit 07d5271d041f288debbe8c9e391aa64d1c894b9b in branch refs/heads/vmware-storage-motion from Sateesh Chodapuneedi [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=07d5271 ] CLOUDSTACK-2701 - Enable storage migration for VMware resources Sending command MigrateWithStorageCommand to source host instead of target host for the case of migration of VM within cluster. > Enable storage migration for VMware resources > - > > Key: CLOUDSTACK-2701 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2701 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0 >Reporter: Sateesh Chodapuneedi >Assignee: Sateesh Chodapuneedi > Fix For: 4.2.0 > > > Storage vMotion allows VMs to be moved from one host to another, along with > storage across datastores in datacenter. It provides the option to live > migrate a VM’s disks along with the VM itself. > It is now possible to migrate a VM from one datastore to another, or even to > migrate a VM’s disks from one datastore to another with VM running on same > host, all while the VM is running. > This issue is to track the support of storage vMotion for VMware resources in > cloudstack. Till now ticket CLOUDSTACK-659 was using in all code commits done > to branch vmware-storage-motion. Just now created this ticket to deal with > specific areas in implementation that is well contained and limited to VMware > resource only. Commits related to VmwareStorageMotionStrategy class and it's > implementation along with commands MigrateWithStorageCommand and > MigrateVolumeCommand are done under CLOUDSTACK-659 ticket. > Release Planning: > Functional Spec: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Enabling+Storage+XenMotion+for+XenServer > (section VMware resource) > Feature branch: vmware-storage-motion -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2702) unable to install XenServer Support Package (CSP) on Xen cloud platform 1.6
Dean Kamali created CLOUDSTACK-2702: --- Summary: unable to install XenServer Support Package (CSP) on Xen cloud platform 1.6 Key: CLOUDSTACK-2702 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2702 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Xen Environment: Xen Cloud Platform 1.6 Reporter: Dean Kamali To enable security groups, elastic load balancing, and elastic IP on XenServer, We need to install CloudStack XenServer Support Package (CSP). After installing Xen cloud platform Server. I'm getting an error, when I try to install the package. xe-install-supplemental-pack xenserver-cloud-supp.iso Error repository is not compatible with the installed product (xenserver expected), Do you want to continue? (Y/N)? When I answer by Y FATAL: missing dependency xs:main -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2702) unable to install XenServer Support Package (CSP) on Xen cloud platform 1.6
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dean Kamali updated CLOUDSTACK-2702: Description: To enable security groups, elastic load balancing, and elastic IP on XenServer, We need to install CloudStack XenServer Support Package (CSP). After installing Xen cloud platform Server. I'm getting an error, when I try to install the package. xe-install-supplemental-pack xenserver-cloud-supp.iso Error repository is not compatible with the installed product (xenserver expected), Do you want to continue? (Y/N)? When I answer with Y FATAL: missing dependency xs:main was: To enable security groups, elastic load balancing, and elastic IP on XenServer, We need to install CloudStack XenServer Support Package (CSP). After installing Xen cloud platform Server. I'm getting an error, when I try to install the package. xe-install-supplemental-pack xenserver-cloud-supp.iso Error repository is not compatible with the installed product (xenserver expected), Do you want to continue? (Y/N)? When I answer by Y FATAL: missing dependency xs:main > unable to install XenServer Support Package (CSP) on Xen cloud platform 1.6 > --- > > Key: CLOUDSTACK-2702 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2702 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Xen > Environment: Xen Cloud Platform 1.6 >Reporter: Dean Kamali > Labels: xen, xenserver > > To enable security groups, elastic load balancing, and elastic IP on > XenServer, We need to install CloudStack XenServer Support Package (CSP). > After installing Xen cloud platform Server. > I'm getting an error, when I try to install the package. > xe-install-supplemental-pack xenserver-cloud-supp.iso > Error repository is not compatible with the installed product (xenserver > expected), Do you want to continue? (Y/N)? > When I answer with Y > FATAL: missing dependency xs:main -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-512) remove hostname in a virtual router's DNS service, after expunging VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667922#comment-13667922 ] ASF subversion and git services commented on CLOUDSTACK-512: Commit cf47a72142ad2458d292ec8d16017d0722049fb4 in branch refs/heads/4.0 from [~weizhou] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cf47a72 ] CLOUDSTACK-512: add space before > remove hostname in a virtual router's DNS service, after expunging VM > - > > Key: CLOUDSTACK-512 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-512 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: pre-4.0.0 >Reporter: Choonho Son >Assignee: Wei Zhou > > The domain name of guest VM is not deleted, even though the guest VM is > expunged. > Scenario: > 1. Deploy VirtualMachine with hostname "head1" > 2. Delete "head1" VirtualMachine > 3. Deploy VirtualMachine with hostname "head1" > 4. Delete "head1" VirtualMachine > ... > After repeating this process, ask ip address of "head1" > nslookup head1 > The result looks like > [root@repo src-conf]# nslookup head1 > Server: 172.27.0.1 > Address:172.27.0.1#53 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.114.224 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.110.235 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.182.109 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.76.251 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.196.212 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.116.53 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.35.214 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.248.170 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.33.158 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.116.64 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.71.218 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.65.181 > Problem: > - Other guest VM cannot connect "head1" VM using domain name, > - Because only one IP address is valid. > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-1325) restoreVirtualMachine returns no password
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13667921#comment-13667921 ] ASF subversion and git services commented on CLOUDSTACK-1325: - Commit a5723992a0eeea9fc383c656b0d61dfc9e541ff9 in branch refs/heads/4.0 from [~weizhou] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a572399 ] CLOUDSTACK-1325: add password in response of RestoreVM > restoreVirtualMachine returns no password > - > > Key: CLOUDSTACK-1325 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1325 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Environment: hypervisor: Ubuntu 12.04 (64-bit) > CloudStack 4.0.1 > Guest OS: Ubuntu 10.04 (64-bit) >Reporter: Wei Zhou >Assignee: Wei Zhou > > We just had a test on restoreVirtualMachine. no password is returned. > To reproduce: > (1) run > command=restoreVirtualMachine&response=json&virtualmachineid=1a53a308-c870-452a-9eff-23975919286b > > (2) query > command=queryAsyncJobResult&response=json&jobid=77c60ca2-8b14-4a14-9449-7855c5e67fff > passwordenabled is true, but no password is returned. I can not log in the > virtual machine using the old password. > (3) workaround > command=resetPasswordForVirtualMachine&id=1a53a308-c870-452a-9eff-23975919286b > > will restart the virtual machine and set a new password. I can log in the > virtual machine using this password > Hope the guys working on CLOUDSTACK-667 (VM's base image update facility) can > consider this issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-512) remove hostname in a virtual router's DNS service, after expunging VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Zhou resolved CLOUDSTACK-512. - Resolution: Fixed > remove hostname in a virtual router's DNS service, after expunging VM > - > > Key: CLOUDSTACK-512 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-512 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: pre-4.0.0 >Reporter: Choonho Son >Assignee: Wei Zhou > > The domain name of guest VM is not deleted, even though the guest VM is > expunged. > Scenario: > 1. Deploy VirtualMachine with hostname "head1" > 2. Delete "head1" VirtualMachine > 3. Deploy VirtualMachine with hostname "head1" > 4. Delete "head1" VirtualMachine > ... > After repeating this process, ask ip address of "head1" > nslookup head1 > The result looks like > [root@repo src-conf]# nslookup head1 > Server: 172.27.0.1 > Address:172.27.0.1#53 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.114.224 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.110.235 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.182.109 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.76.251 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.196.212 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.116.53 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.35.214 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.248.170 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.33.158 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.116.64 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.71.218 > Name: head1.cs82epc-dev.ucloud.com > Address: 172.27.65.181 > Problem: > - Other guest VM cannot connect "head1" VM using domain name, > - Because only one IP address is valid. > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-1325) restoreVirtualMachine returns no password
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Zhou resolved CLOUDSTACK-1325. -- Resolution: Fixed > restoreVirtualMachine returns no password > - > > Key: CLOUDSTACK-1325 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1325 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Environment: hypervisor: Ubuntu 12.04 (64-bit) > CloudStack 4.0.1 > Guest OS: Ubuntu 10.04 (64-bit) >Reporter: Wei Zhou >Assignee: Wei Zhou > > We just had a test on restoreVirtualMachine. no password is returned. > To reproduce: > (1) run > command=restoreVirtualMachine&response=json&virtualmachineid=1a53a308-c870-452a-9eff-23975919286b > > (2) query > command=queryAsyncJobResult&response=json&jobid=77c60ca2-8b14-4a14-9449-7855c5e67fff > passwordenabled is true, but no password is returned. I can not log in the > virtual machine using the old password. > (3) workaround > command=resetPasswordForVirtualMachine&id=1a53a308-c870-452a-9eff-23975919286b > > will restart the virtual machine and set a new password. I can log in the > virtual machine using this password > Hope the guys working on CLOUDSTACK-667 (VM's base image update facility) can > consider this issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2406) language display error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13668005#comment-13668005 ] terryye commented on CLOUDSTACK-2406: - It was fixed at the commit 9bc43930b822a294c863e954bc5b39fc4b506f46. > language display error > --- > > Key: CLOUDSTACK-2406 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2406 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 > Environment: Ubuntu 12.0.4 kvm >Reporter: terryye > Original Estimate: 72h > Remaining Estimate: 72h > > All of chinese lable is "???" . > Japanese is display the word code .like \u65e5\u672c\.. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-2406) language display error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] terryye closed CLOUDSTACK-2406. --- Resolution: Fixed Fix Version/s: 4.1.0 > language display error > --- > > Key: CLOUDSTACK-2406 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2406 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 > Environment: Ubuntu 12.0.4 kvm >Reporter: terryye > Fix For: 4.1.0 > > Original Estimate: 72h > Remaining Estimate: 72h > > All of chinese lable is "???" . > Japanese is display the word code .like \u65e5\u672c\.. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2029) zone wide primary storage support for cloudstack over vmware deployments
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13668088#comment-13668088 ] Sateesh Chodapuneedi commented on CLOUDSTACK-2029: -- Code for this feature can be found in branch refs/heads/zone-primarystorage-vmware > zone wide primary storage support for cloudstack over vmware deployments > > > Key: CLOUDSTACK-2029 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2029 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, VMware >Reporter: Sateesh Chodapuneedi >Assignee: Sateesh Chodapuneedi > Fix For: 4.2.0 > > > Support for primary storage that span across clusters in CloudStack zone. > Similar to Amazon's EBS. > This is to facilitate virtual disk availability across clusters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2029) zone wide primary storage support for cloudstack over vmware deployments
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-2029: - Description: Support for primary storage that span across clusters in CloudStack zone. Similar to Amazon's EBS. This is to facilitate virtual disk availability across clusters. Functional Specification: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Zone-wide+primary+storage+target A dedicated section is being added to the above FS with specifics around VMware resource support. was: Support for primary storage that span across clusters in CloudStack zone. Similar to Amazon's EBS. This is to facilitate virtual disk availability across clusters. > zone wide primary storage support for cloudstack over vmware deployments > > > Key: CLOUDSTACK-2029 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2029 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, VMware >Reporter: Sateesh Chodapuneedi >Assignee: Sateesh Chodapuneedi > Fix For: 4.2.0 > > > Support for primary storage that span across clusters in CloudStack zone. > Similar to Amazon's EBS. > This is to facilitate virtual disk availability across clusters. > Functional Specification: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Zone-wide+primary+storage+target > > A dedicated section is being added to the above FS with specifics around > VMware resource support. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2029) zone wide primary storage support for cloudstack over vmware deployments
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ram Ganesh updated CLOUDSTACK-2029: --- Description: Support for primary storage that span across clusters in CloudStack zone. Similar to Amazon's EBS. This is to facilitate virtual disk availability across clusters. Functional Specification: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Zone-wide+primary+storage+target A dedicated section is being added to the above FS with specifics around VMware resource support. Code for this feature can be found in branch refs/heads/zone-primarystorage-vmware was: Support for primary storage that span across clusters in CloudStack zone. Similar to Amazon's EBS. This is to facilitate virtual disk availability across clusters. Functional Specification: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Zone-wide+primary+storage+target A dedicated section is being added to the above FS with specifics around VMware resource support. > zone wide primary storage support for cloudstack over vmware deployments > > > Key: CLOUDSTACK-2029 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2029 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, VMware >Reporter: Sateesh Chodapuneedi >Assignee: Sateesh Chodapuneedi > Fix For: 4.2.0 > > > Support for primary storage that span across clusters in CloudStack zone. > Similar to Amazon's EBS. > This is to facilitate virtual disk availability across clusters. > Functional Specification: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Zone-wide+primary+storage+target > > A dedicated section is being added to the above FS with specifics around > VMware resource support. > Code for this feature can be found in branch > refs/heads/zone-primarystorage-vmware -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CLOUDSTACK-1528) No UI level check for Overcommit ratio;It is accepting special character,negative values and zero
[
https://issues.apache.org/jira/browse/CLOUDSTACK-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
prashant kumar mishra reopened CLOUDSTACK-1528:
---
For invalid input there should be error message like "please provide valid
input" instead of just setting the value to 1,its totally confusing when UI
will show overcommitratio ="some special character",and db shows overcommit=1
> No UI level check for Overcommit ratio;It is accepting special
> character,negative values and zero
> -
>
> Key: CLOUDSTACK-1528
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1528
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.2.0
>Reporter: prashant kumar mishra
>Assignee: Bharat Kumar
> Fix For: 4.2.0
>
> Attachments: screenshot-1.jpg, screenshot-2.jpg, screenshot-3.jpg
>
>
> 1-There is no check in UI for special character and zero.
> 2-If we provide any special character or zero for overcommit ratio in UI ,DB
> is getting upgraded by default value 1.
> Steps
>
> 1-Create a cluster provide some special characters for overcommit ratio
> Expected
> -
> should have some error message , overcommite ratio cant't be special
> character or less than zero etc.
> Actual
>
> cluster is getting created with overcommit ratio ={special
> character,zero,-ive values} but DB is storing default value 1 .
> DB
> ---
> mysql> select* from cluster_details;
> +++---+---+
> | id | cluster_id | name | value |
> +++---+---+
> | 1 | 1 | cpuOvercommitRatio| 1.0 |
> | 2 | 1 | memoryOvercommitRatio | 1.0 |
> | 3 | 2 | cpuOvercommitRatio| 1.0 |
> | 4 | 2 | memoryOvercommitRatio | 1.0 |
> | 5 | 3 | cpuOvercommitRatio| 1.0 |
> | 6 | 3 | memoryOvercommitRatio | 1.0 |
> +++---+---+
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2581) Not able to login to VM using the password dispalyed from passwordenabled tempalte.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harikrishna Patnala resolved CLOUDSTACK-2581. - Resolution: Cannot Reproduce Password retrieving script should be there on guest Linux vm inorder to update the vm with new password. In case of windows vm, CloudInstanceManager installer should be there on guest vm and we need to start the service after installation. > Not able to login to VM using the password dispalyed from passwordenabled > tempalte. > --- > > Key: CLOUDSTACK-2581 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2581 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.2.0 >Reporter: Kiran Koneti >Assignee: Harikrishna Patnala >Priority: Critical > Fix For: 4.2.0 > > > 1)Registered a template as a password enabled template. > 2)Created a VM using the same template and the password is displayed once the > VM is created. > 3)Tried to login to the VM using the password. > 4)the login failed saying wrong password. > 5)Then tried to login with the default password the login was successful. > 6)Then tried the password reset and new password is pooped up. > 7)Tried logging with the new password but the login still fails with and > login is successful with the default password. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-2581) Not able to login to VM using the password dispalyed from passwordenabled tempalte.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harikrishna Patnala closed CLOUDSTACK-2581. --- Resolution: Not A Problem > Not able to login to VM using the password dispalyed from passwordenabled > tempalte. > --- > > Key: CLOUDSTACK-2581 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2581 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.2.0 >Reporter: Kiran Koneti >Assignee: Harikrishna Patnala >Priority: Critical > Fix For: 4.2.0 > > > 1)Registered a template as a password enabled template. > 2)Created a VM using the same template and the password is displayed once the > VM is created. > 3)Tried to login to the VM using the password. > 4)the login failed saying wrong password. > 5)Then tried to login with the default password the login was successful. > 6)Then tried the password reset and new password is pooped up. > 7)Tried logging with the new password but the login still fails with and > login is successful with the default password. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2703) Marvin logger output showing repeated log lines.
Ashutosk Kelkar created CLOUDSTACK-2703: --- Summary: Marvin logger output showing repeated log lines. Key: CLOUDSTACK-2703 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2703 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Reporter: Ashutosk Kelkar Priority: Minor Fix For: 4.2.0 In unit tests runs the same log output line is repeated for number tests in a class, making log unreadable. This is because we are creating a logger by class name for each test load in loadTestsFromFile() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CLOUDSTACK-2581) Not able to login to VM using the password dispalyed from passwordenabled tempalte.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harikrishna Patnala reopened CLOUDSTACK-2581: - > Not able to login to VM using the password dispalyed from passwordenabled > tempalte. > --- > > Key: CLOUDSTACK-2581 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2581 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.2.0 >Reporter: Kiran Koneti >Assignee: Harikrishna Patnala >Priority: Critical > Fix For: 4.2.0 > > > 1)Registered a template as a password enabled template. > 2)Created a VM using the same template and the password is displayed once the > VM is created. > 3)Tried to login to the VM using the password. > 4)the login failed saying wrong password. > 5)Then tried to login with the default password the login was successful. > 6)Then tried the password reset and new password is pooped up. > 7)Tried logging with the new password but the login still fails with and > login is successful with the default password. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2557) Fix add primary storage tests
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13668110#comment-13668110 ] ASF subversion and git services commented on CLOUDSTACK-2557: - Commit 8fd476e2fddd75949362630823d1a574d44a1705 in branch refs/heads/master from [~srikanti] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8fd476e ] CLOUDSTACK-2557: Fix add primary storage tests Signed-off-by: Prasanna Santhanam > Fix add primary storage tests > -- > > Key: CLOUDSTACK-2557 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2557 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Test >Affects Versions: 4.2.0 >Reporter: Srikanteswararao Talluri >Assignee: Srikanteswararao Talluri > Fix For: 4.2.0 > > > Fix add primary storage tests -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2662) Preferred implicit dedication fails with insufficient capacity even if shared hosts are available.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13668108#comment-13668108 ] Rajesh Battala commented on CLOUDSTACK-2662: Issue is with Implicit Dedicated planner, as it is returning resource usage as dedicated all the times. getResource usage from Implicit planner should return shared/dedicated depending upon the mode selected (strict/preferred) in the offering. working on the fix will send out the patch for review. > Preferred implicit dedication fails with insufficient capacity even if shared > hosts are available. > -- > > Key: CLOUDSTACK-2662 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2662 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 >Reporter: Kiran Koneti >Assignee: Rajesh Battala >Priority: Blocker > Fix For: 4.2.0 > > > Below are the steps followed : > 1)Created a Xen Advanced Zone setup with one cluster and hosts. > 2)The host1 has the system VM's deployed and a VM with the root domain. > 3)Then created two accounts kiran and kiran2 respectively. > 4)Was able to deploy VM's using the preferred and strict implicit dedication > for the Account kiran. > 5)Then tried to deploy a VM fro the account kiran2 using the preferred > implicit service offering. > 6)The VM deployment fails saying insufficient resources even we have the host > 1 in the shared state. > the below error message is observed > "2013-05-24 16:15:09,565 INFO [user.vm.DeployVMCmd] (Job-Executor-3:job-22) > com.cloud.exception.InsufficientServerCapacityException: Unable to create a > deployment for VM[U ser|win832pref2]Scope=interface com.cloud.dc.DataCenter; > id=1 > 2013-05-24 16:15:09,565 INFO [user.vm.DeployVMCmd] (Job-Executor-3:job-22) > Unable to create a deployment for VM[User|win832pref2] > com.cloud.exception.InsufficientServerCapacityException: Unable to create a > deployment for VM[User|win832pref2]Scope=interface com.cloud.dc.DataCenter; > id=1 > at > org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.reserveVirtualMachine(VMEntityManagerImpl.java:212) > at > org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.reserve(VirtualMachineEntityImpl.java:198) > at > com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3206) > at > com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2745) > at > com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2731) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) > at > org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:420) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155) > at > com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679)" > The op_host_planner_reservation shows the host dedication details as below: > mysql> select * from op_host_planner_reservation; > +++++-++ > | id | data_center_id | pod_id | cluster_id | host_id | resource_usage | > +++++-++ > | 1 | 1 | 1 | 1 | 1 | Shared | > | 2 | 1 | 1 | 1 | 5 | Dedicated | > +++++-++ > 2 rows in set (0.00 sec) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-2696) default value of cluster.memory.allocated.capacity.notificationthreshold is getting set to 0.75 instead of taking value from Global parameter "cluster.memory.allocat
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra closed CLOUDSTACK-2696. - Resolution: Fixed not reproducible > default value of cluster.memory.allocated.capacity.notificationthreshold is > getting set to 0.75 instead of taking value from Global parameter > "cluster.memory.allocated.capacity.notificationthreshold" > > > Key: CLOUDSTACK-2696 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2696 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, UI >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra > Fix For: 4.2.0 > > Attachments: logs.rar > > > Steps to reproduce > --- > 1- set global parameter > "cluster.memory.allocated.capacity.notificationthreshold" to some value say > 0.2 > 2-Set cluster level parameter > "cluster.memory.allocated.capacity.notificationthreshold" to "space" > Expected > -- > cluster.memory.allocated.capacity.notificationthreshold should be set to > 0.2(global parameter) > Actual > --- > cluster.memory.allocated.capacity.notificationthreshold is getting set to > 0.75,DB shows NULL in value field > DB > -- > mysql> select * from cluster_details; > +++-+---+ > | id | cluster_id | name| > value | > +++-+---+ > | 1 | 1 | cpuOvercommitRatio | > 1.0 | > | 2 | 1 | memoryOvercommitRatio | > 1.0 | > | 3 | 2 | cpuOvercommitRatio | > 1.0 | > | 4 | 2 | memoryOvercommitRatio | > 1.0 | > | 5 | 1 | cluster.cpu.allocated.capacity.disablethreshold | > NULL | > | 6 | 2 | cluster.cpu.allocated.capacity.disablethreshold | > NULL | > | 7 | 1 | cluster.memory.allocated.capacity.disablethreshold | > NULL | > | 8 | 1 | cluster.cpu.allocated.capacity.notificationthreshold| > 0.85 | > | 9 | 2 | cluster.cpu.allocated.capacity.notificationthreshold| > NULL | > | 10 | 2 | cluster.memory.allocated.capacity.disablethreshold | > 0.85 | > | 11 | 2 | cluster.memory.allocated.capacity.notificationthreshold | > NULL | > +++-+---+ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (CLOUDSTACK-2702) unable to install XenServer Support Package (CSP) on Xen cloud platform 1.6
On Mon, May 27, 2013 at 07:18:19PM +, Dean Kamali (JIRA) wrote: > Dean Kamali created CLOUDSTACK-2702: > --- > > Summary: unable to install XenServer Support Package (CSP) on > Xen cloud platform 1.6 > Key: CLOUDSTACK-2702 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2702 > Project: CloudStack > Issue Type: Bug > Security Level: Public (Anyone can view this level - this is the > default.) > Components: Xen > Environment: Xen Cloud Platform 1.6 > Reporter: Dean Kamali > > > To enable security groups, elastic load balancing, and elastic IP on > XenServer, We need to install CloudStack XenServer Support Package > (CSP). After installing Xen cloud platform Server. > > I'm getting an error, when I try to install the package. > > xe-install-supplemental-pack xenserver-cloud-supp.iso > > Error repository is not compatible with the installed product > (xenserver expected), Do you want to continue? (Y/N)? > > When I answer by Y > > FATAL: missing dependency xs:main > > The Cloud Supplemental Pack (CSP) is not packaged for XCP AFAIK. The CSP step is only supported/tested against a Citrix XenServer. Does anyone know how to get SecurityGroups to work on an XCP and/or if this is supported? -- Prasanna., Powered by BigRock.com
[jira] [Resolved] (CLOUDSTACK-2703) Marvin logger output showing repeated log lines.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam resolved CLOUDSTACK-2703. Resolution: Fixed Assignee: Ashutosk Kelkar commit 204bdac77f2c48e304b8bd7ccf2c85a69f4885ef Author: ashutoshkelkar Date: Thu May 23 11:23:34 2013 +0530 Fix for repeated log lines in test case logs. Signed-off-by: Prasanna Santhanam > Marvin logger output showing repeated log lines. > > > Key: CLOUDSTACK-2703 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2703 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Ashutosk Kelkar >Assignee: Ashutosk Kelkar >Priority: Minor > Fix For: 4.2.0 > > > In unit tests runs the same log output line is repeated for number tests in a > class, making log unreadable. > This is because we are creating a logger by class name for each test load in > loadTestsFromFile() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2702) unable to install XenServer Support Package (CSP) on Xen cloud platform 1.6
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13668116#comment-13668116 ] Prasanna Santhanam commented on CLOUDSTACK-2702: The Cloud Supplemental Pack (CSP) is not packaged for XCP AFAIK. The CSP step is only supported/tested against a Citrix XenServer. Does anyone know how to get SecurityGroups to work on an XCP and/or if this is supported? -- Prasanna., Powered by BigRock.com > unable to install XenServer Support Package (CSP) on Xen cloud platform 1.6 > --- > > Key: CLOUDSTACK-2702 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2702 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Xen > Environment: Xen Cloud Platform 1.6 >Reporter: Dean Kamali > Labels: xen, xenserver > > To enable security groups, elastic load balancing, and elastic IP on > XenServer, We need to install CloudStack XenServer Support Package (CSP). > After installing Xen cloud platform Server. > I'm getting an error, when I try to install the package. > xe-install-supplemental-pack xenserver-cloud-supp.iso > Error repository is not compatible with the installed product (xenserver > expected), Do you want to continue? (Y/N)? > When I answer with Y > FATAL: missing dependency xs:main -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
