[jira] [Created] (CLOUDSTACK-7632) Automation for volume life cycle testPath
prashant kumar mishra created CLOUDSTACK-7632: - Summary: Automation for volume life cycle testPath Key: CLOUDSTACK-7632 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7632 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: marvin Reporter: prashant kumar mishra Assignee: prashant kumar mishra write automation for volume life cycle testcPath1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7555) [Automation] FIx the script - /component/test_usage.py - Template should belong to the Regular Account to test TEMPLATE.CREATE Event
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14147472#comment-14147472
]
ASF subversion and git services commented on CLOUDSTACK-7555:
-
Commit f3252db797a6d53a1922a60b29cd6b4914de7d51 in cloudstack's branch
refs/heads/master from [~chandanp]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f3252db ]
CLOUDSTACK-7555 - Fixed the test_usage script - Template now belongs to the
Regular Account to test TEMPLATE.CREATE Event
Signed-off-by: SrikanteswaraRao Talluri
> [Automation] FIx the script - /component/test_usage.py - Template should
> belong to the Regular Account to test TEMPLATE.CREATE Event
>
>
> Key: CLOUDSTACK-7555
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7555
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Chandan Purushothama
>Priority: Critical
> Fix For: 4.5.0
>
>
> *TestTemplateUsage.test_01_template_usage* fails with the following error
> message & Stack Trace
> {noformat}
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 332, in run
> testMethod()
> File "/root/cloudstack/test/integration/component/test_usage.py", line 802,
> in test_01_template_usage
> "Check TEMPLATE.CREATE event in events table"
> File "/usr/lib/python2.7/unittest/case.py", line 516, in assertEqual
> assertion_func(first, second, msg=msg)
> File "/usr/lib/python2.7/unittest/case.py", line 509, in _baseAssertEqual
> raise self.failureException(msg)
> 'Check TEMPLATE.CREATE event in events table\n
> {noformat}
> This is because the Template is being created as admin and it belongs to the
> admin account. The template should belong to the Regular User in order to
> check for the TEMPLATE.CREATE Event.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7622) Can't delete the network when providers this network uses, are disabled
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14147438#comment-14147438 ] Jayapal Reddy commented on CLOUDSTACK-7622: --- Problem: --- When network provider is disabled state network is not able to shutdown, delete. Root Cause Analysis: --- On network shutdown and deleting checking for wether provide is enabled or not, if is enabled then only allowed to perform. Proposed solution: Removing the condition of checking provider enabled . Verification steps: - 1. Create isolated network and deploy vms. 2. Delete the vm in this network. 3. Network state change to shutdown with out errors and then to allocated. 4. Delete network should also successful. > Can't delete the network when providers this network uses, are disabled > --- > > Key: CLOUDSTACK-7622 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7622 > 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 >Assignee: Jayapal Reddy > Fix For: 4.5.0 > > > Steps to reproduce: > create network, use VR as a provider for its services > disable VR provider > try to delete the network. Shutdown network fails due to disabled provider. > Shutdown should be successful even when provider is disabled -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7622) Can't delete the network when providers this network uses, are disabled
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayapal Reddy resolved CLOUDSTACK-7622. --- Resolution: Fixed > Can't delete the network when providers this network uses, are disabled > --- > > Key: CLOUDSTACK-7622 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7622 > 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 >Assignee: Jayapal Reddy > Fix For: 4.5.0 > > > Steps to reproduce: > create network, use VR as a provider for its services > disable VR provider > try to delete the network. Shutdown network fails due to disabled provider. > Shutdown should be successful even when provider is disabled -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7631) Log rotate on VR may fail as /etc/init.d/rsyslog does not anymore support reload option on debian wheezy
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Saksham Srivastava updated CLOUDSTACK-7631:
---
Fix Version/s: 4.5.0
> Log rotate on VR may fail as /etc/init.d/rsyslog does not anymore support
> reload option on debian wheezy
>
>
> Key: CLOUDSTACK-7631
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7631
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Saksham Srivastava
>Assignee: Saksham Srivastava
> Fix For: 4.5.0
>
>
> As shown below we get the following message when doing logrotate on VR:
> #logrotate -v /etc/logrotate.conf
> rotating pattern: /var/log/syslog
> running postrotate script
> Usage: /etc/init.d/rsyslog
> {start|stop|rotate|restart|force-reload|status}
> invoke-rc.d: initscript rsyslog, action "reload" failed.
> error: error running non-shared postrotate script for /var/log/syslog of
> '/var/log/syslog
> https://github.com/Yubico/yubikey-val/issues/18
> https://access.redhat.com/solutions/232793
> https://www.rudder-project.org/redmine/issues/3176
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7631) Log rotate on VR may fail as /etc/init.d/rsyslog does not anymore support reload option on debian wheezy
Saksham Srivastava created CLOUDSTACK-7631:
--
Summary: Log rotate on VR may fail as /etc/init.d/rsyslog does not
anymore support reload option on debian wheezy
Key: CLOUDSTACK-7631
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7631
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Saksham Srivastava
Assignee: Saksham Srivastava
As shown below we get the following message when doing logrotate on VR:
#logrotate -v /etc/logrotate.conf
rotating pattern: /var/log/syslog
running postrotate script
Usage: /etc/init.d/rsyslog
{start|stop|rotate|restart|force-reload|status}
invoke-rc.d: initscript rsyslog, action "reload" failed.
error: error running non-shared postrotate script for /var/log/syslog of
'/var/log/syslog
https://github.com/Yubico/yubikey-val/issues/18
https://access.redhat.com/solutions/232793
https://www.rudder-project.org/redmine/issues/3176
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7622) Can't delete the network when providers this network uses, are disabled
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14147390#comment-14147390 ] ASF subversion and git services commented on CLOUDSTACK-7622: - Commit 8c8c54f9f59249c47ff5985626579b4f9565d9fd in cloudstack's branch refs/heads/master from Jayapal [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8c8c54f ] CLOUDSTACK-7622: Fixed deleting network when provider is disable > Can't delete the network when providers this network uses, are disabled > --- > > Key: CLOUDSTACK-7622 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7622 > 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 >Assignee: Jayapal Reddy > Fix For: 4.5.0 > > > Steps to reproduce: > create network, use VR as a provider for its services > disable VR provider > try to delete the network. Shutdown network fails due to disabled provider. > Shutdown should be successful even when provider is disabled -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7630) CPU utilization display of VM Instances is incorrect. (In the case of VMware vSphere 5)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] satoru nakaya updated CLOUDSTACK-7630: -- Description: CPU utilization display of VM Instances is incorrect. Environment: CloudStack 4.3.0 VMware vSphere 5.0 update 2 CloudStack UI Instances->VM->Statistics CPU Utilized: 1980% ^^^ == # top top - 01:05:28 up 1:07, 2 users, load average: 1.03, 1.07, 1.02 Tasks: 76 total, 2 running, 74 sleeping, 0 stopped, 0 zombie Cpu(s): 97.9%us, 1.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st was: CPU utilization display of VM Instances is incorrect. Environment: CloudStack 4.3.0 VMware vSphere 5.0 update 2 CloudStack UI Instances->VM->Statistics CPU Utilized: 1980% ^^^ == # top top - 01:05:28 up 1:07, 2 users, load average: 1.03, 1.07, 1.02 Tasks: 76 total, 2 running, 74 sleeping, 0 stopped, 0 zombie Cpu(s): 97.9%us, 1.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st > CPU utilization display of VM Instances is incorrect. (In the case of VMware > vSphere 5) > --- > > Key: CLOUDSTACK-7630 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7630 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.1, 4.3.0 > Environment: CloudStack 4.3.0 > VMware vSphere 5.0 update 2 >Reporter: satoru nakaya > > CPU utilization display of VM Instances is incorrect. > Environment: > CloudStack 4.3.0 > VMware vSphere 5.0 update 2 > CloudStack UI > Instances->VM->Statistics > CPU Utilized: 1980% > ^^^ > == > # top > top - 01:05:28 up 1:07, 2 users, load average: 1.03, 1.07, 1.02 > Tasks: 76 total, 2 running, 74 sleeping, 0 stopped, 0 zombie > Cpu(s): 97.9%us, 1.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7630) CPU utilization display of VM Instances is incorrect. (In the case of VMware vSphere 5)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] satoru nakaya updated CLOUDSTACK-7630: -- Description: CPU utilization display of VM Instances is incorrect. Environment: CloudStack 4.3.0 VMware vSphere 5.0 update 2 CloudStack UI Instances->VM->Statistics CPU Utilized: 1980% ^^^ == '# top top - 01:05:28 up 1:07, 2 users, load average: 1.03, 1.07, 1.02 Tasks: 76 total, 2 running, 74 sleeping, 0 stopped, 0 zombie Cpu(s): 97.9%us, 1.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st was: CPU utilization display of VM Instances is incorrect. Environment: CloudStack 4.3.0 VMware vSphere 5.0 update 2 CloudStack UI Instances->VM->Statistics CPU Utilized: 1980% ^^^ == # top top - 01:05:28 up 1:07, 2 users, load average: 1.03, 1.07, 1.02 Tasks: 76 total, 2 running, 74 sleeping, 0 stopped, 0 zombie Cpu(s): 97.9%us, 1.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st > CPU utilization display of VM Instances is incorrect. (In the case of VMware > vSphere 5) > --- > > Key: CLOUDSTACK-7630 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7630 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.1, 4.3.0 > Environment: CloudStack 4.3.0 > VMware vSphere 5.0 update 2 >Reporter: satoru nakaya > > CPU utilization display of VM Instances is incorrect. > Environment: > CloudStack 4.3.0 > VMware vSphere 5.0 update 2 > CloudStack UI > Instances->VM->Statistics > CPU Utilized: 1980% > ^^^ > == > '# top > top - 01:05:28 up 1:07, 2 users, load average: 1.03, 1.07, 1.02 > Tasks: 76 total, 2 running, 74 sleeping, 0 stopped, 0 zombie > Cpu(s): 97.9%us, 1.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7630) CPU utilization display of VM Instances is incorrect. (In the case of VMware vSphere 5)
satoru nakaya created CLOUDSTACK-7630: - Summary: CPU utilization display of VM Instances is incorrect. (In the case of VMware vSphere 5) Key: CLOUDSTACK-7630 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7630 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.1.1, 4.3.0 Environment: CloudStack 4.3.0 VMware vSphere 5.0 update 2 Reporter: satoru nakaya CPU utilization display of VM Instances is incorrect. Environment: CloudStack 4.3.0 VMware vSphere 5.0 update 2 CloudStack UI Instances->VM->Statistics CPU Utilized: 1980% ^^^ == # top top - 01:05:28 up 1:07, 2 users, load average: 1.03, 1.07, 1.02 Tasks: 76 total, 2 running, 74 sleeping, 0 stopped, 0 zombie Cpu(s): 97.9%us, 1.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (CLOUDSTACK-7622) Can't delete the network when providers this network uses, are disabled
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayapal Reddy updated CLOUDSTACK-7622:
--
Comment: was deleted
(was: MS logs:
2014-09-24 15:35:18,719 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(1949422689@qtp-2019457093-0:ctx-fe1d81bc ctx-ecb8d94c) submit async job-29,
details: AsyncJobVO {id:29, userId: 2, accountId: 2, instanceType: None,
instanceId: null, cmd: com.cloud.api.commands.AddSrxFirewallCmd, cmdInfo:
{"physicalnetworkid":"5a343691-932d-4f4c-9e65-da754b5b93cb","sessionkey":"0is9qGB4EiFibf2X7eQD8KKitIs\u003d","cmdEventType":"PHYSICAL.FIREWALL.ADD","ctxUserId":"2","httpmethod":"POST","password":"password","url":"https://10.147.40.3?publicinterface\u003dfe00\u0026privateinterface\u003dfe01\u0026numretries\u003d2\u0026timeout\u003d300\u0026fwdevicededicated\u003dfalse","response":"json","ctxDetails":"{\"com.cloud.network.PhysicalNetwork\":\"5a343691-932d-4f4c-9e65-da754b5b93cb\"}","username":"admin","networkdevicetype":"JuniperSRXFirewall","ctxAccountId":"2","ctxStartEventId":"78"},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 1, completeMsid: null, lastUpdated: null, lastPolled: null,
created: null}
2014-09-24 15:35:18,720 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-2:ctx-5ec8cde4 job-29) Add job-29 into job monitoring
2014-09-24 15:35:18,721 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-2:ctx-5ec8cde4 job-29) Executing AsyncJobVO {id:29, userId:
2, accountId: 2, instanceType: None, instanceId: null, cmd:
com.cloud.api.commands.AddSrxFirewallCmd, cmdInfo:
{"physicalnetworkid":"5a343691-932d-4f4c-9e65-da754b5b93cb","sessionkey":"0is9qGB4EiFibf2X7eQD8KKitIs\u003d","cmdEventType":"PHYSICAL.FIREWALL.ADD","ctxUserId":"2","httpmethod":"POST","password":"password","url":"https://10.147.40.3?publicinterface\u003dfe00\u0026privateinterface\u003dfe01\u0026numretries\u003d2\u0026timeout\u003d300\u0026fwdevicededicated\u003dfalse","response":"json","ctxDetails":"{\"com.cloud.network.PhysicalNetwork\":\"5a343691-932d-4f4c-9e65-da754b5b93cb\"}","username":"admin","networkdevicetype":"JuniperSRXFirewall","ctxAccountId":"2","ctxStartEventId":"78"},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 1, completeMsid: null, lastUpdated: null, lastPolled: null,
created: null}
)
> Can't delete the network when providers this network uses, are disabled
> ---
>
> Key: CLOUDSTACK-7622
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7622
> 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
>Assignee: Jayapal Reddy
> Fix For: 4.5.0
>
>
> Steps to reproduce:
> create network, use VR as a provider for its services
> disable VR provider
> try to delete the network. Shutdown network fails due to disabled provider.
> Shutdown should be successful even when provider is disabled
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6631) unable to attach new Volume to VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14147358#comment-14147358
]
Kazuhiro Ito commented on CLOUDSTACK-6631:
--
You've been very helpful.
I will try your advice.
Best regards,
> unable to attach new Volume to VM
> -
>
> Key: CLOUDSTACK-6631
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6631
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Volumes
>Affects Versions: 4.2.1
> Environment: Cloudstack 4.2.1 + KVM on CentOS 6.4
>Reporter: Kazuhiro Ito
>Assignee: Likitha Shetty
> Attachments: management-server.log.0521
>
>
> 1. I added new volume.
> 2. I tried to attach the volume to a VM on UI.
> 3. It failed and the following log appeared.
> 2014-05-12 11:29:47,096 DEBUG [cloud.api.ApiServlet]
> (http-6443-exec-116:null) ===START=== 133.xx.xxx.xxx -- GET
> command=attachVolume&id=ac7099fb-ac66-4c63-bf1e-ed0e1429f412&virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74&response=json&sessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D&_=1399861774316
> 2014-05-12 11:29:47,143 DEBUG [cloud.async.AsyncJobManagerImpl]
> (http-6443-exec-116:null) submit async job-4916 = [
> dd8fab57-96aa-446f-8ebd-53c32ce4501a ], details: AsyncJobVO {id:4916, userId:
> 3, accountId: 3, sessionKey: null, instanceType: Volume, instanceId: 1543,
> cmd: org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd,
> cmdOriginator: null, cmdInfo:
> {"response":"json","id":"ac7099fb-ac66-4c63-bf1e-ed0e1429f412","sessionkey":"TDcTy/QRb5/+k28wsjg6BWd6pcA\u003d","cmdEventType":"VOLUME.ATTACH","ctxUserId":"3","virtualMachineId":"ecdc2c1d-e21e-4c04-962a-4efac1a69a74","httpmethod":"GET","_":"1399861774316","ctxAccountId":"3","ctxStartEventId":"34276"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 90520731085572,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2014-05-12 11:29:47,144 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> Executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd for
> job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]
> 2014-05-12 11:29:47,147 DEBUG [cloud.api.ApiServlet]
> (http-6443-exec-116:null) ===END=== 133.xx.xxx.xxx -- GET
> command=attachVolume&id=ac7099fb-ac66-4c63-bf1e-ed0e1429f412&virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74&response=json&sessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D&_=1399861774316
> 2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access
> to org.apache.cloudstack.storage.volume.VolumeObject@17178a01 granted to
> Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by
> DomainChecker_EnhancerByCloudStack_9b413459
> 2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access
> to VM[User|TEST-A2-VM01] granted to
> Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by
> DomainChecker_EnhancerByCloudStack_9b413459
> 2014-05-12 11:29:47,212 DEBUG [storage.allocator.LocalStoragePoolAllocator]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> LocalStoragePoolAllocator trying to find storage pool to fit the vm
> 2014-05-12 11:29:47,212 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> ClusterScopeStoragePoolAllocator looking for storage pool
> 2014-05-12 11:29:47,212 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> Looking for pools in dc: 1 pod:1 cluster:null having tags:[MPI]
> 2014-05-12 11:29:47,216 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) No
> storage pools available for shared volume allocation, returning
> 2014-05-12 11:29:47,234 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> Unexpected exception while executing
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
> com.cloud.utils.exception.CloudRuntimeException: Caught: SELECT pool.id,
> SUM(IF(vol.state='Ready' AND vol.account_id = ?, 1, 0)) FROM
> `cloud`.`storage_pool` pool LEFT JOIN `cloud`.`volumes` vol ON pool.id =
> vol.pool_id WHERE pool.data_center_id = ? AND pool.pod_id = ? AND
> pool.cluster_id = ? GROUP BY pool.id ORDER BY 2 ASC
> at
> com.cloud.stor
[jira] [Created] (CLOUDSTACK-7629) addBaremetalRct() API call is not available in cloudstackAPI library in marvin.
Sangeetha Hariharan created CLOUDSTACK-7629: --- Summary: addBaremetalRct() API call is not available in cloudstackAPI library in marvin. Key: CLOUDSTACK-7629 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7629 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Sangeetha Hariharan Assignee: frank zhang Fix For: 4.5.0 addBaremetalRct() API call is not available in cloudstackAPI library in marvin. When a new API call is added , we expect the python libraries for this API to be available as part of cloudstackAPI in marvin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6631) unable to attach new Volume to VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14147334#comment-14147334
]
Likitha Shetty commented on CLOUDSTACK-6631:
Yes, this a CloudStack bug. I am working on a fix.
But in the meantime as a workaround to proceed with attach volumes, please set
the global setting to the default value that is 'random'.
> unable to attach new Volume to VM
> -
>
> Key: CLOUDSTACK-6631
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6631
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Volumes
>Affects Versions: 4.2.1
> Environment: Cloudstack 4.2.1 + KVM on CentOS 6.4
>Reporter: Kazuhiro Ito
>Assignee: Likitha Shetty
> Attachments: management-server.log.0521
>
>
> 1. I added new volume.
> 2. I tried to attach the volume to a VM on UI.
> 3. It failed and the following log appeared.
> 2014-05-12 11:29:47,096 DEBUG [cloud.api.ApiServlet]
> (http-6443-exec-116:null) ===START=== 133.xx.xxx.xxx -- GET
> command=attachVolume&id=ac7099fb-ac66-4c63-bf1e-ed0e1429f412&virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74&response=json&sessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D&_=1399861774316
> 2014-05-12 11:29:47,143 DEBUG [cloud.async.AsyncJobManagerImpl]
> (http-6443-exec-116:null) submit async job-4916 = [
> dd8fab57-96aa-446f-8ebd-53c32ce4501a ], details: AsyncJobVO {id:4916, userId:
> 3, accountId: 3, sessionKey: null, instanceType: Volume, instanceId: 1543,
> cmd: org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd,
> cmdOriginator: null, cmdInfo:
> {"response":"json","id":"ac7099fb-ac66-4c63-bf1e-ed0e1429f412","sessionkey":"TDcTy/QRb5/+k28wsjg6BWd6pcA\u003d","cmdEventType":"VOLUME.ATTACH","ctxUserId":"3","virtualMachineId":"ecdc2c1d-e21e-4c04-962a-4efac1a69a74","httpmethod":"GET","_":"1399861774316","ctxAccountId":"3","ctxStartEventId":"34276"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 90520731085572,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2014-05-12 11:29:47,144 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> Executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd for
> job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]
> 2014-05-12 11:29:47,147 DEBUG [cloud.api.ApiServlet]
> (http-6443-exec-116:null) ===END=== 133.xx.xxx.xxx -- GET
> command=attachVolume&id=ac7099fb-ac66-4c63-bf1e-ed0e1429f412&virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74&response=json&sessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D&_=1399861774316
> 2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access
> to org.apache.cloudstack.storage.volume.VolumeObject@17178a01 granted to
> Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by
> DomainChecker_EnhancerByCloudStack_9b413459
> 2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access
> to VM[User|TEST-A2-VM01] granted to
> Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by
> DomainChecker_EnhancerByCloudStack_9b413459
> 2014-05-12 11:29:47,212 DEBUG [storage.allocator.LocalStoragePoolAllocator]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> LocalStoragePoolAllocator trying to find storage pool to fit the vm
> 2014-05-12 11:29:47,212 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> ClusterScopeStoragePoolAllocator looking for storage pool
> 2014-05-12 11:29:47,212 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> Looking for pools in dc: 1 pod:1 cluster:null having tags:[MPI]
> 2014-05-12 11:29:47,216 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) No
> storage pools available for shared volume allocation, returning
> 2014-05-12 11:29:47,234 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> Unexpected exception while executing
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
> com.cloud.utils.exception.CloudRuntimeException: Caught: SELECT pool.id,
> SUM(IF(vol.state='Ready' AND vol.account_id = ?, 1, 0)) FROM
> `cloud`.`storage_pool` pool LEFT JOIN `cloud`.`volumes` vol ON pool.id =
> vol.pool_id WHERE pool.dat
[jira] [Commented] (CLOUDSTACK-6631) unable to attach new Volume to VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14147181#comment-14147181
]
Kazuhiro Ito commented on CLOUDSTACK-6631:
--
Thank you for your comment.
Yes, both are true in my case.
Is this cloudstack's bug?
If I set vm.allocation.algorithm in global settings to "random", I can attach
a volume to a VM?
> unable to attach new Volume to VM
> -
>
> Key: CLOUDSTACK-6631
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6631
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Volumes
>Affects Versions: 4.2.1
> Environment: Cloudstack 4.2.1 + KVM on CentOS 6.4
>Reporter: Kazuhiro Ito
>Assignee: Likitha Shetty
> Attachments: management-server.log.0521
>
>
> 1. I added new volume.
> 2. I tried to attach the volume to a VM on UI.
> 3. It failed and the following log appeared.
> 2014-05-12 11:29:47,096 DEBUG [cloud.api.ApiServlet]
> (http-6443-exec-116:null) ===START=== 133.xx.xxx.xxx -- GET
> command=attachVolume&id=ac7099fb-ac66-4c63-bf1e-ed0e1429f412&virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74&response=json&sessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D&_=1399861774316
> 2014-05-12 11:29:47,143 DEBUG [cloud.async.AsyncJobManagerImpl]
> (http-6443-exec-116:null) submit async job-4916 = [
> dd8fab57-96aa-446f-8ebd-53c32ce4501a ], details: AsyncJobVO {id:4916, userId:
> 3, accountId: 3, sessionKey: null, instanceType: Volume, instanceId: 1543,
> cmd: org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd,
> cmdOriginator: null, cmdInfo:
> {"response":"json","id":"ac7099fb-ac66-4c63-bf1e-ed0e1429f412","sessionkey":"TDcTy/QRb5/+k28wsjg6BWd6pcA\u003d","cmdEventType":"VOLUME.ATTACH","ctxUserId":"3","virtualMachineId":"ecdc2c1d-e21e-4c04-962a-4efac1a69a74","httpmethod":"GET","_":"1399861774316","ctxAccountId":"3","ctxStartEventId":"34276"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 90520731085572,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2014-05-12 11:29:47,144 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> Executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd for
> job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]
> 2014-05-12 11:29:47,147 DEBUG [cloud.api.ApiServlet]
> (http-6443-exec-116:null) ===END=== 133.xx.xxx.xxx -- GET
> command=attachVolume&id=ac7099fb-ac66-4c63-bf1e-ed0e1429f412&virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74&response=json&sessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D&_=1399861774316
> 2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access
> to org.apache.cloudstack.storage.volume.VolumeObject@17178a01 granted to
> Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by
> DomainChecker_EnhancerByCloudStack_9b413459
> 2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access
> to VM[User|TEST-A2-VM01] granted to
> Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by
> DomainChecker_EnhancerByCloudStack_9b413459
> 2014-05-12 11:29:47,212 DEBUG [storage.allocator.LocalStoragePoolAllocator]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> LocalStoragePoolAllocator trying to find storage pool to fit the vm
> 2014-05-12 11:29:47,212 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> ClusterScopeStoragePoolAllocator looking for storage pool
> 2014-05-12 11:29:47,212 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> Looking for pools in dc: 1 pod:1 cluster:null having tags:[MPI]
> 2014-05-12 11:29:47,216 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) No
> storage pools available for shared volume allocation, returning
> 2014-05-12 11:29:47,234 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> Unexpected exception while executing
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
> com.cloud.utils.exception.CloudRuntimeException: Caught: SELECT pool.id,
> SUM(IF(vol.state='Ready' AND vol.account_id = ?, 1, 0)) FROM
> `cloud`.`storage_pool` pool LEFT JOIN `cloud`.`volumes` vol ON pool.id =
> vol.pool_id WHERE pool.data_center
[jira] [Resolved] (CLOUDSTACK-7628) VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7628. -- Resolution: Fixed > VM Worker job should be expunged one hour after completion instead of > currently being expunged whenever cleanup task thread is run. > --- > > Key: CLOUDSTACK-7628 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7628 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 >Reporter: Min Chen >Assignee: Min Chen >Priority: Critical > Fix For: 4.5.0 > > > Based on design, when VM worker job cleanup thread runs, it should only > expunge those vm work jobs that are completed more than one hour ago. This is > to prevent some Db constraint error in expunging these jobs since there are > still reference to the worker job in async_job_map table. Also on some racing > condition, we will encounter NPE due to removal of such jobs too quickly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7628) VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14147178#comment-14147178 ] Min Chen commented on CLOUDSTACK-7628: -- This is caused by a bug in code to set search criteria bind value, mismatched with the bind parameter defined earlier, thus cut date criteria is not used. > VM Worker job should be expunged one hour after completion instead of > currently being expunged whenever cleanup task thread is run. > --- > > Key: CLOUDSTACK-7628 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7628 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 >Reporter: Min Chen >Assignee: Min Chen >Priority: Critical > Fix For: 4.5.0 > > > Based on design, when VM worker job cleanup thread runs, it should only > expunge those vm work jobs that are completed more than one hour ago. This is > to prevent some Db constraint error in expunging these jobs since there are > still reference to the worker job in async_job_map table. Also on some racing > condition, we will encounter NPE due to removal of such jobs too quickly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7628) VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14147174#comment-14147174 ] ASF subversion and git services commented on CLOUDSTACK-7628: - Commit 4317a85e97643c681b98b3e58990ec2f22abedd8 in cloudstack's branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4317a85 ] CLOUDSTACK-7628:VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run. > VM Worker job should be expunged one hour after completion instead of > currently being expunged whenever cleanup task thread is run. > --- > > Key: CLOUDSTACK-7628 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7628 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 >Reporter: Min Chen >Assignee: Min Chen >Priority: Critical > Fix For: 4.5.0 > > > Based on design, when VM worker job cleanup thread runs, it should only > expunge those vm work jobs that are completed more than one hour ago. This is > to prevent some Db constraint error in expunging these jobs since there are > still reference to the worker job in async_job_map table. Also on some racing > condition, we will encounter NPE due to removal of such jobs too quickly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7628) VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen reassigned CLOUDSTACK-7628: Assignee: Min Chen > VM Worker job should be expunged one hour after completion instead of > currently being expunged whenever cleanup task thread is run. > --- > > Key: CLOUDSTACK-7628 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7628 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 >Reporter: Min Chen >Assignee: Min Chen >Priority: Critical > Fix For: 4.5.0 > > > Based on design, when VM worker job cleanup thread runs, it should only > expunge those vm work jobs that are completed more than one hour ago. This is > to prevent some Db constraint error in expunging these jobs since there are > still reference to the worker job in async_job_map table. Also on some racing > condition, we will encounter NPE due to removal of such jobs too quickly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7628) VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run.
Min Chen created CLOUDSTACK-7628: Summary: VM Worker job should be expunged one hour after completion instead of currently being expunged whenever cleanup task thread is run. Key: CLOUDSTACK-7628 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7628 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Min Chen Priority: Critical Fix For: 4.5.0 Based on design, when VM worker job cleanup thread runs, it should only expunge those vm work jobs that are completed more than one hour ago. This is to prevent some Db constraint error in expunging these jobs since there are still reference to the worker job in async_job_map table. Also on some racing condition, we will encounter NPE due to removal of such jobs too quickly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7627) [Automation] Automate Remote Access VPN on VPC Test Plan
Chandan Purushothama created CLOUDSTACK-7627: Summary: [Automation] Automate Remote Access VPN on VPC Test Plan Key: CLOUDSTACK-7627 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7627 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Chandan Purushothama Priority: Critical Fix For: 4.5.0 This ticket refers to automation of the test cases in the test plan present at https://cwiki.apache.org/confluence/display/CLOUDSTACK/Remote+Access+VPN+on+VPC+Feature+Test+Plan -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7626) SAMLUtilsTest failing inconsistently during build
Rayees Namathponnan created CLOUDSTACK-7626: --- Summary: SAMLUtilsTest failing inconsistently during build Key: CLOUDSTACK-7626 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7626 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.5.0 Environment: 4.5 Reporter: Rayees Namathponnan Priority: Blocker Fix For: 4.5.0 4.5 build failing inconsistently while running unit test, unning org.apache.cloudstack.utils.auth.SAMLUtilsTest I have seen this issue multiple times, after the some merge happened 2 week ago, Build fails with below error [INFO] --- maven-surefire-plugin:2.12:test (default-test) @ cloud-utils --- [INFO] Surefire report directory: /root/jenkins/build/workspace/CloudPlatform-4.x-rhel63_Simulator/internal-cloudstack/dist/rpmbuild/BUILD/cloudstack-4.5.0-SNAPSHOT/utils/target/surefire-reports --- T E S T S --- Running org.apache.cloudstack.utils.auth.SAMLUtilsTest Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.245 sec Running com.cloud.utils.TestProfiler Configure log4j with default properties 2014-09-24 03:38:16,415 INFO [cloud.utils.TestProfiler] (main:) testProfiler() started 2014-09-24 03:38:17,417 INFO [cloud.utils.TestProfiler] (main:) Duration : 1000 2014-09-24 03:38:17,419 INFO [cloud.utils.TestProfiler] (main:) testProfiler() stopped Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.012 sec Running com.cloud.utils.ScriptTest 2014-09-24 03:38:17,526 DEBUG [utils.script.Script] (main:) Executing: /bin/echo bar 2014-09-24 03:38:17,537 DEBUG [utils.script.Script] (main:) Execution is successful. 2014-09-24 03:38:17,545 DEBUG [utils.script.Script] (main:) Looking for pwd in the classpath 2014-09-24 03:38:17,545 DEBUG [utils.script.Script] (main:) System resource: null 2014-09-24 03:38:17,546 DEBUG [utils.script.Script] (main:) Classpath resource: null 2014-09-24 03:38:17,549 DEBUG [utils.script.Script] (main:) Executing: /bin/bash -c echo 'hello world!' 2014-09-24 03:38:17,551 DEBUG [utils.script.Script] (main:) Execution is successful. 2014-09-24 03:38:17,551 WARN [utils.script.Script] (main:) Exception: /bin/bash -c echo 'hello world!' java.lang.IllegalArgumentException at com.cloud.utils.ScriptTest$1.interpret(ScriptTest.java:107) at com.cloud.utils.script.Script.execute(Script.java:220) at com.cloud.utils.ScriptTest.executeWithOutputInterpreter(ScriptTest.java:103) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$Provi
[jira] [Closed] (CLOUDSTACK-7625) UI > IP Address page > EnableVPN > If createRemoteAccessVpn returns success, but the newly created remoteaccessvpn object's state is not Running, treat it as a failur
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang closed CLOUDSTACK-7625. > UI > IP Address page > EnableVPN > If createRemoteAccessVpn returns success, > but the newly created remoteaccessvpn object's state is not Running, treat it > as a failure. > > > Key: CLOUDSTACK-7625 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7625 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Jessica Wang > Attachments: jessica1.PNG, jessica2.PNG, jessica3.PNG, jessica4.PNG > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7625) UI > IP Address page > EnableVPN > If createRemoteAccessVpn returns success, but the newly created remoteaccessvpn object's state is not Running, treat it as a fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-7625. -- Resolution: Fixed > UI > IP Address page > EnableVPN > If createRemoteAccessVpn returns success, > but the newly created remoteaccessvpn object's state is not Running, treat it > as a failure. > > > Key: CLOUDSTACK-7625 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7625 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Jessica Wang > Attachments: jessica1.PNG, jessica2.PNG, jessica3.PNG, jessica4.PNG > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7625) UI > IP Address page > EnableVPN > If createRemoteAccessVpn returns success, but the newly created remoteaccessvpn object's state is not Running, treat it as a fai
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146917#comment-14146917
]
Jessica Wang commented on CLOUDSTACK-7625:
--
screenshots of UI change are attached.
API calls in the screenshots:
https://issues.citrite.net/i#browse/CS-19442
http://10.215.3.26:8080/client/api?command=createRemoteAccessVpn&response=json&sessionkey=j86M%2FWlXUFfHsvj4rcpj%2FPUM4aA%3D&publicipid=9784e132-7414-45e6-878f-82f081babb26&domainid=5adf2319-38a9-11e4-b948-d4ae52cb99a3&account=admin&_=1411592742041
"createremoteaccessvpnresponse": {
"id": "750d1c27-c38b-45cd-92aa-59be98834c83",
"jobid": "23c7553d-5c7a-499b-a22f-710c906ccaf1"
}
}
http://10.215.3.26:8080/client/api?command=queryAsyncJobResult&jobId=23c7553d-5c7a-499b-a22f-710c906ccaf1&response=json&sessionkey=j86M%2FWlXUFfHsvj4rcpj%2FPUM4aA%3D&_=1411592745244
{
"queryasyncjobresultresponse": {
"accountid": "da1a0149-38aa-11e4-b948-d4ae52cb99a3",
"userid": "da1a0c8e-38aa-11e4-b948-d4ae52cb99a3",
"cmd":
"org.apache.cloudstack.api.command.user.vpn.CreateRemoteAccessVpnCmd",
"jobstatus": 1,
"jobprocstatus": 0,
"jobresultcode": 0,
"jobresulttype": "object",
"jobresult": {
"remoteaccessvpn": {
"publicipid": "9784e132-7414-45e6-878f-82f081babb26",
"publicip": "10.147.30.162",
"iprange": "10.1.2.2-10.1.2.8",
"presharedkey": "387sWNpGUWbJyd6aOWZDBOFS",
"account": "admin",
"domainid": "5adf2319-38a9-11e4-b948-d4ae52cb99a3",
"domain": "ROOT",
"state": "Added",
"id": "750d1c27-c38b-45cd-92aa-59be98834c83",
"fordisplay": true
}
},
"jobinstancetype": "None",
"created": "2014-09-24T13:05:41-0800",
"jobid": "23c7553d-5c7a-499b-a22f-710c906ccaf1"
}
}
> UI > IP Address page > EnableVPN > If createRemoteAccessVpn returns success,
> but the newly created remoteaccessvpn object's state is not Running, treat it
> as a failure.
>
>
> Key: CLOUDSTACK-7625
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7625
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Reporter: Jessica Wang
>Assignee: Jessica Wang
> Attachments: jessica1.PNG, jessica2.PNG, jessica3.PNG, jessica4.PNG
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7625) UI > IP Address page > EnableVPN > If createRemoteAccessVpn returns success, but the newly created remoteaccessvpn object's state is not Running, treat it as a failu
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-7625: - Attachment: jessica4.PNG jessica3.PNG jessica2.PNG jessica1.PNG > UI > IP Address page > EnableVPN > If createRemoteAccessVpn returns success, > but the newly created remoteaccessvpn object's state is not Running, treat it > as a failure. > > > Key: CLOUDSTACK-7625 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7625 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Jessica Wang > Attachments: jessica1.PNG, jessica2.PNG, jessica3.PNG, jessica4.PNG > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7625) UI > IP Address page > EnableVPN > If createRemoteAccessVpn returns success, but the newly created remoteaccessvpn object's state is not Running, treat it as a fai
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146915#comment-14146915 ] ASF subversion and git services commented on CLOUDSTACK-7625: - Commit b592e0af345c38b5a898ec238bc4f2c8cedf6ef9 in cloudstack's branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b592e0a ] CLOUDSTACK-7625: UI > IP Address page > EnableVPN > If createRemoteAccessVpn returns success, but the newly created remoteaccessvpn object's state is not Running, treat it as a failure. > UI > IP Address page > EnableVPN > If createRemoteAccessVpn returns success, > but the newly created remoteaccessvpn object's state is not Running, treat it > as a failure. > > > Key: CLOUDSTACK-7625 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7625 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Jessica Wang > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7625) UI > IP Address page > EnableVPN > If createRemoteAccessVpn returns success, but the newly created remoteaccessvpn object's state is not Running, treat it as a failu
Jessica Wang created CLOUDSTACK-7625: Summary: UI > IP Address page > EnableVPN > If createRemoteAccessVpn returns success, but the newly created remoteaccessvpn object's state is not Running, treat it as a failure. Key: CLOUDSTACK-7625 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7625 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Reporter: Jessica Wang Assignee: Jessica Wang -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7623) SystemVMs not starting
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-7623: Assignee: Anthony Xu > SystemVMs not starting > -- > > Key: CLOUDSTACK-7623 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7623 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.5.0 >Reporter: Pavan Kumar Bandarupally >Assignee: Anthony Xu >Priority: Blocker > Fix For: 4.5.0 > > Attachments: management-server.log > > > After installing latest Management Server and zone creation, system VMs are > not getting created. The following exception is being generated: > 2014-09-24 17:37:17,918 WARN [c.c.u.d.Merovingian2] > (consoleproxy-1:ctx-bc88696c) Timed out on acquiring lock vm_instance1 . > Waited for 0seconds > 2014-09-24 17:37:17,919 WARN [c.c.c.ConsoleProxyManagerImpl] > (consoleproxy-1:ctx-bc88696c) Runtime Exception while trying to start console > proxy > com.cloud.utils.exception.CloudRuntimeException: Timed out on acquiring lock > vm_instance1 . Waited for 0seconds > at com.cloud.utils.db.Merovingian2.acquire(Merovingian2.java:143) > at > com.cloud.utils.db.TransactionLegacy.lock(TransactionLegacy.java:389) > at > com.cloud.utils.db.GenericDaoBase.lockInLockTable(GenericDaoBase.java:1057) > 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:601) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at $Proxy53.lockInLockTable(Unknown Source) > at > com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3927) > at > com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3922) > at > com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49) > at com.cloud.utils.db.Transaction.execute(Transaction.java:37) > at com.cloud.utils.db.Transaction.execute(Transaction.java:46) > at > com.cloud.vm.VirtualMachineManagerImpl.startVmThroughJobQueue(VirtualMachineManagerImpl.java:3922) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:769) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:748) > at > com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:540) > at > com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:919) > at > com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1640) > at > com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:157) > at > com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:120) > at > com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:35) > at > com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:90) > at > com.cloud.vm.SystemVmLoadScanner$1.runInContext(SystemVmLoadScanner.java:81) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithConte
[jira] [Resolved] (CLOUDSTACK-7623) SystemVMs not starting
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Xu resolved CLOUDSTACK-7623. Resolution: Fixed commit f5eae55abb4591109dd22c1ba9d25f0876ebe52f Author: Anthony Xu Date: Wed Sep 24 10:57:36 2014 -0700 timeInSeconds * 1000 timeInSeconds is int type, if timeInSeconds is very big, it makes "timeInseconds * 1000" very small even 0 commit c74dada8541cbb81c3a4c06843d93aa1ce32f1ef Author: Anthony Xu Date: Wed Sep 24 10:28:04 2014 -0700 add logs for lock acquire and release > SystemVMs not starting > -- > > Key: CLOUDSTACK-7623 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7623 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.5.0 >Reporter: Pavan Kumar Bandarupally >Priority: Blocker > Fix For: 4.5.0 > > Attachments: management-server.log > > > After installing latest Management Server and zone creation, system VMs are > not getting created. The following exception is being generated: > 2014-09-24 17:37:17,918 WARN [c.c.u.d.Merovingian2] > (consoleproxy-1:ctx-bc88696c) Timed out on acquiring lock vm_instance1 . > Waited for 0seconds > 2014-09-24 17:37:17,919 WARN [c.c.c.ConsoleProxyManagerImpl] > (consoleproxy-1:ctx-bc88696c) Runtime Exception while trying to start console > proxy > com.cloud.utils.exception.CloudRuntimeException: Timed out on acquiring lock > vm_instance1 . Waited for 0seconds > at com.cloud.utils.db.Merovingian2.acquire(Merovingian2.java:143) > at > com.cloud.utils.db.TransactionLegacy.lock(TransactionLegacy.java:389) > at > com.cloud.utils.db.GenericDaoBase.lockInLockTable(GenericDaoBase.java:1057) > 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:601) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at $Proxy53.lockInLockTable(Unknown Source) > at > com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3927) > at > com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3922) > at > com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49) > at com.cloud.utils.db.Transaction.execute(Transaction.java:37) > at com.cloud.utils.db.Transaction.execute(Transaction.java:46) > at > com.cloud.vm.VirtualMachineManagerImpl.startVmThroughJobQueue(VirtualMachineManagerImpl.java:3922) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:769) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:748) > at > com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:540) > at > com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:919) > at > com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1640) > at > com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:157) > at > com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:120) > at > com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:35) > at > com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:90) > at > com.cloud.vm.SystemVmLoadScanner$1.runInContext(SystemVmLoadScanner.java:81) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.jav
[jira] [Commented] (CLOUDSTACK-7623) SystemVMs not starting
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146587#comment-14146587
]
Anthony Xu commented on CLOUDSTACK-7623:
> Waited for 0seconds
The cause is it is trying to acquire DB table lock with timeout 0, if there is
any contention for the lock, the lock acquisition will fail due to timeout, the
code doesn't check if it acquires the lock successfully, and continues the
execution, it means without the checkout, the code will execute without getting
the lock, which is wrong. looks like "return false" hide this issue, which may
cause other DB issue later, and is very hard debug,
I'll remove the exception to unblock QA, call stack trace will be still logged.
_vmDao.lockInLockTable(String.valueOf(vm.getId()),
Integer.MAX_VALUE);
try {
List pendingWorkJobs =
_workJobDao.listPendingWorkJobs(VirtualMachine.Type.Instance,
vm.getId(), VmWorkStart.class.getName());
> SystemVMs not starting
> --
>
> Key: CLOUDSTACK-7623
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7623
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM
>Affects Versions: 4.5.0
>Reporter: Pavan Kumar Bandarupally
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: management-server.log
>
>
> After installing latest Management Server and zone creation, system VMs are
> not getting created. The following exception is being generated:
> 2014-09-24 17:37:17,918 WARN [c.c.u.d.Merovingian2]
> (consoleproxy-1:ctx-bc88696c) Timed out on acquiring lock vm_instance1 .
> Waited for 0seconds
> 2014-09-24 17:37:17,919 WARN [c.c.c.ConsoleProxyManagerImpl]
> (consoleproxy-1:ctx-bc88696c) Runtime Exception while trying to start console
> proxy
> com.cloud.utils.exception.CloudRuntimeException: Timed out on acquiring lock
> vm_instance1 . Waited for 0seconds
> at com.cloud.utils.db.Merovingian2.acquire(Merovingian2.java:143)
> at
> com.cloud.utils.db.TransactionLegacy.lock(TransactionLegacy.java:389)
> at
> com.cloud.utils.db.GenericDaoBase.lockInLockTable(GenericDaoBase.java:1057)
> 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:601)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at
> com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy53.lockInLockTable(Unknown Source)
> at
> com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3927)
> at
> com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3922)
> at
> com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49)
> at com.cloud.utils.db.Transaction.execute(Transaction.java:37)
> at com.cloud.utils.db.Transaction.execute(Transaction.java:46)
> at
> com.cloud.vm.VirtualMachineManagerImpl.startVmThroughJobQueue(VirtualMachineManagerImpl.java:3922)
> at
> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:769)
> at
> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:748)
> at
> com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:540)
> at
> com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:919)
> at
> com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1640)
> at
> com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java
[jira] [Commented] (CLOUDSTACK-7624) Long hostnames cause CloudStack to die with an encryption error during startup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146426#comment-14146426 ] ASF subversion and git services commented on CLOUDSTACK-7624: - Commit 9eb86560c9b83456be9ee32e8b713b213baed7bb in cloudstack's branch refs/heads/4.4 from [~htrippaers] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9eb8656 ] CLOUDSTACK-7624 The value field of the configuration table is not big enough for some values > Long hostnames cause CloudStack to die with an encryption error during startup > -- > > Key: CLOUDSTACK-7624 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7624 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: Future, 4.4.0 >Reporter: Hugo Trippaers >Assignee: Hugo Trippaers > Fix For: 4.4.1 > > > Machines with a long hostname will have a longer certificate in > cloud.keystore. When encrypted this certificate will be longer than 4095 > which is the maximum length of the database field. > When the value is read back the stripped value is returned and the decryption > routine will throw an error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7624) Long hostnames cause CloudStack to die with an encryption error during startup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146422#comment-14146422 ] ASF subversion and git services commented on CLOUDSTACK-7624: - Commit 9eb86560c9b83456be9ee32e8b713b213baed7bb in cloudstack's branch refs/heads/hotfix/4.4/CLOUDSTACK-7624 from [~htrippaers] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9eb8656 ] CLOUDSTACK-7624 The value field of the configuration table is not big enough for some values > Long hostnames cause CloudStack to die with an encryption error during startup > -- > > Key: CLOUDSTACK-7624 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7624 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: Future, 4.4.0 >Reporter: Hugo Trippaers >Assignee: Hugo Trippaers > Fix For: 4.4.1 > > > Machines with a long hostname will have a longer certificate in > cloud.keystore. When encrypted this certificate will be longer than 4095 > which is the maximum length of the database field. > When the value is read back the stripped value is returned and the decryption > routine will throw an error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7624) Long hostnames cause CloudStack to die with an encryption error during startup
Hugo Trippaers created CLOUDSTACK-7624: -- Summary: Long hostnames cause CloudStack to die with an encryption error during startup Key: CLOUDSTACK-7624 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7624 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: Future, 4.4.0 Reporter: Hugo Trippaers Assignee: Hugo Trippaers Fix For: 4.4.1 Machines with a long hostname will have a longer certificate in cloud.keystore. When encrypted this certificate will be longer than 4095 which is the maximum length of the database field. When the value is read back the stripped value is returned and the decryption routine will throw an error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7538) Can not remove the vm nic due to there is another vm with same internal ip having port forwording rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146318#comment-14146318 ] Saksham Srivastava commented on CLOUDSTACK-7538: Created https://issues.apache.org/jira/browse/CLOUDSTACK-7548 Fixed on master https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=8c671c4;hp=6379ca4548b8329f2492fa7f142c4946bef8d55e > Can not remove the vm nic due to there is another vm with same internal ip > having port forwording rule > -- > > Key: CLOUDSTACK-7538 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7538 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.0, 4.5.0 >Reporter: Wei Zhou >Assignee: Wei Zhou > Fix For: 4.5.0, 4.4.1 > > > When I tried to remove a nic from a VM, an exception raised: > 2014-09-08 10:07:12,847 ERROR [cloud.async.AsyncJobManagerImpl] > (Job-Executor-109:job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ]) > Unexpected exception while executing > org.apache.cloudstack.api.command.user.vm.RemoveNicFromVMCmd > com.cloud.utils.exception.CloudRuntimeException: Failed to remove nic from > VM[User|CentOS65] in Ntwk[300|Guest|1], nic has associated Port forwarding or > Load balancer or Static NAT rules. > at > com.cloud.vm.VirtualMachineManagerImpl.removeNicFromVm(VirtualMachineManagerImpl.java:3129) > at > com.cloud.vm.UserVmManagerImpl.removeNicFromVirtualMachine(UserVmManagerImpl.java:1068) > at > org.apache.cloudstack.api.command.user.vm.RemoveNicFromVMCmd.execute(RemoveNicFromVMCmd.java:103) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) > at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) > 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:1146) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:701) > 2014-09-08 10:07:12,849 DEBUG [cloud.async.AsyncJobManagerImpl] > (Job-Executor-109:job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ]) > Complete async job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ], > jobStatus: 2, resultCode: 530, result: Error Code: 530 Error text: Failed to > remove nic from VM[User|CentOS65] in Ntwk[300|Guest|1], nic has associated > Port forwarding or Load balancer or Static NAT rules. > This is because there is another vm (with same internal ip) having port > forward rules . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7574) Fail to create Windows 2012r2 VM with OS type: Windows Server 2012 R2 (64-bit)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7574: Fix Version/s: 4.4.1 > Fail to create Windows 2012r2 VM with OS type: Windows Server 2012 R2 (64-bit) > -- > > Key: CLOUDSTACK-7574 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7574 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, XenServer >Affects Versions: 4.4.0, 4.4.1 >Reporter: Pierre-Luc Dion >Assignee: Pierre-Luc Dion >Priority: Minor > Fix For: 4.4.1 > > > Cannot create Windows 2012r2 VM from an ISO with OS type: "Windows Server > 2012 R2 (64-bit)", if the OS type is "Windows Server 2012 (64-bit)" The VM > will succeed to create and boot from the iso. > This as been reported by motty.c...@gmail.com. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6631) unable to attach new Volume to VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146309#comment-14146309
]
Likitha Shetty commented on CLOUDSTACK-6631:
To attach a volume to a VM, CCP creates the volume in primary storage if it
hasn't already been created. During this creation, CCP tries to select a
storage pool to deploy the volume in.
And the storage pool selection fails with the error you mentioned if the
following two conditions are met -
1. ROOT volume of the VM we are trying to attach a datadisk to is in a
zone-wide primary storage.
2. Global config vm.allocation.algorithm is set to userdispersing.
Is the above true in your case?
> unable to attach new Volume to VM
> -
>
> Key: CLOUDSTACK-6631
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6631
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Volumes
>Affects Versions: 4.2.1
> Environment: Cloudstack 4.2.1 + KVM on CentOS 6.4
>Reporter: Kazuhiro Ito
>Assignee: Likitha Shetty
> Attachments: management-server.log.0521
>
>
> 1. I added new volume.
> 2. I tried to attach the volume to a VM on UI.
> 3. It failed and the following log appeared.
> 2014-05-12 11:29:47,096 DEBUG [cloud.api.ApiServlet]
> (http-6443-exec-116:null) ===START=== 133.xx.xxx.xxx -- GET
> command=attachVolume&id=ac7099fb-ac66-4c63-bf1e-ed0e1429f412&virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74&response=json&sessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D&_=1399861774316
> 2014-05-12 11:29:47,143 DEBUG [cloud.async.AsyncJobManagerImpl]
> (http-6443-exec-116:null) submit async job-4916 = [
> dd8fab57-96aa-446f-8ebd-53c32ce4501a ], details: AsyncJobVO {id:4916, userId:
> 3, accountId: 3, sessionKey: null, instanceType: Volume, instanceId: 1543,
> cmd: org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd,
> cmdOriginator: null, cmdInfo:
> {"response":"json","id":"ac7099fb-ac66-4c63-bf1e-ed0e1429f412","sessionkey":"TDcTy/QRb5/+k28wsjg6BWd6pcA\u003d","cmdEventType":"VOLUME.ATTACH","ctxUserId":"3","virtualMachineId":"ecdc2c1d-e21e-4c04-962a-4efac1a69a74","httpmethod":"GET","_":"1399861774316","ctxAccountId":"3","ctxStartEventId":"34276"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 90520731085572,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2014-05-12 11:29:47,144 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> Executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd for
> job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]
> 2014-05-12 11:29:47,147 DEBUG [cloud.api.ApiServlet]
> (http-6443-exec-116:null) ===END=== 133.xx.xxx.xxx -- GET
> command=attachVolume&id=ac7099fb-ac66-4c63-bf1e-ed0e1429f412&virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74&response=json&sessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D&_=1399861774316
> 2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access
> to org.apache.cloudstack.storage.volume.VolumeObject@17178a01 granted to
> Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by
> DomainChecker_EnhancerByCloudStack_9b413459
> 2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access
> to VM[User|TEST-A2-VM01] granted to
> Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by
> DomainChecker_EnhancerByCloudStack_9b413459
> 2014-05-12 11:29:47,212 DEBUG [storage.allocator.LocalStoragePoolAllocator]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> LocalStoragePoolAllocator trying to find storage pool to fit the vm
> 2014-05-12 11:29:47,212 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> ClusterScopeStoragePoolAllocator looking for storage pool
> 2014-05-12 11:29:47,212 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> Looking for pools in dc: 1 pod:1 cluster:null having tags:[MPI]
> 2014-05-12 11:29:47,216 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) No
> storage pools available for shared volume allocation, returning
> 2014-05-12 11:29:47,234 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> Unexpected exception while executing
[jira] [Assigned] (CLOUDSTACK-6631) unable to attach new Volume to VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Likitha Shetty reassigned CLOUDSTACK-6631:
--
Assignee: Likitha Shetty
> unable to attach new Volume to VM
> -
>
> Key: CLOUDSTACK-6631
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6631
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Volumes
>Affects Versions: 4.2.1
> Environment: Cloudstack 4.2.1 + KVM on CentOS 6.4
>Reporter: Kazuhiro Ito
>Assignee: Likitha Shetty
> Attachments: management-server.log.0521
>
>
> 1. I added new volume.
> 2. I tried to attach the volume to a VM on UI.
> 3. It failed and the following log appeared.
> 2014-05-12 11:29:47,096 DEBUG [cloud.api.ApiServlet]
> (http-6443-exec-116:null) ===START=== 133.xx.xxx.xxx -- GET
> command=attachVolume&id=ac7099fb-ac66-4c63-bf1e-ed0e1429f412&virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74&response=json&sessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D&_=1399861774316
> 2014-05-12 11:29:47,143 DEBUG [cloud.async.AsyncJobManagerImpl]
> (http-6443-exec-116:null) submit async job-4916 = [
> dd8fab57-96aa-446f-8ebd-53c32ce4501a ], details: AsyncJobVO {id:4916, userId:
> 3, accountId: 3, sessionKey: null, instanceType: Volume, instanceId: 1543,
> cmd: org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd,
> cmdOriginator: null, cmdInfo:
> {"response":"json","id":"ac7099fb-ac66-4c63-bf1e-ed0e1429f412","sessionkey":"TDcTy/QRb5/+k28wsjg6BWd6pcA\u003d","cmdEventType":"VOLUME.ATTACH","ctxUserId":"3","virtualMachineId":"ecdc2c1d-e21e-4c04-962a-4efac1a69a74","httpmethod":"GET","_":"1399861774316","ctxAccountId":"3","ctxStartEventId":"34276"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 90520731085572,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2014-05-12 11:29:47,144 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> Executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd for
> job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]
> 2014-05-12 11:29:47,147 DEBUG [cloud.api.ApiServlet]
> (http-6443-exec-116:null) ===END=== 133.xx.xxx.xxx -- GET
> command=attachVolume&id=ac7099fb-ac66-4c63-bf1e-ed0e1429f412&virtualMachineId=ecdc2c1d-e21e-4c04-962a-4efac1a69a74&response=json&sessionkey=TDcTy%2FQRb5%2F%2Bk28wsjg6BWd6pcA%3D&_=1399861774316
> 2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access
> to org.apache.cloudstack.storage.volume.VolumeObject@17178a01 granted to
> Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by
> DomainChecker_EnhancerByCloudStack_9b413459
> 2014-05-12 11:29:47,192 DEBUG [cloud.user.AccountManagerImpl]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) Access
> to VM[User|TEST-A2-VM01] granted to
> Acct[0bea1cc1-ac60-4fb2-990b-f2dd04a5a329-xxx-x-x] by
> DomainChecker_EnhancerByCloudStack_9b413459
> 2014-05-12 11:29:47,212 DEBUG [storage.allocator.LocalStoragePoolAllocator]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> LocalStoragePoolAllocator trying to find storage pool to fit the vm
> 2014-05-12 11:29:47,212 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> ClusterScopeStoragePoolAllocator looking for storage pool
> 2014-05-12 11:29:47,212 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> Looking for pools in dc: 1 pod:1 cluster:null having tags:[MPI]
> 2014-05-12 11:29:47,216 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ]) No
> storage pools available for shared volume allocation, returning
> 2014-05-12 11:29:47,234 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-146:job-4916 = [ dd8fab57-96aa-446f-8ebd-53c32ce4501a ])
> Unexpected exception while executing
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
> com.cloud.utils.exception.CloudRuntimeException: Caught: SELECT pool.id,
> SUM(IF(vol.state='Ready' AND vol.account_id = ?, 1, 0)) FROM
> `cloud`.`storage_pool` pool LEFT JOIN `cloud`.`volumes` vol ON pool.id =
> vol.pool_id WHERE pool.data_center_id = ? AND pool.pod_id = ? AND
> pool.cluster_id = ? GROUP BY pool.id ORDER BY 2 ASC
> at
> com.cloud.storage.dao.VolumeDaoImpl.listPoolIdsByVolumeCount(VolumeDaoImpl.java:480)
> at
[jira] [Commented] (CLOUDSTACK-7623) SystemVMs not starting
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146277#comment-14146277 ] Alex Brett commented on CLOUDSTACK-7623: Based on the exception text I imagine https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=d8ad3e32bc6ee41d576fa99473834485a5266f93 is the cause here - it turned something that was returning false in to raising the exception we're seeing... > SystemVMs not starting > -- > > Key: CLOUDSTACK-7623 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7623 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.5.0 >Reporter: Pavan Kumar Bandarupally >Priority: Blocker > Fix For: 4.5.0 > > Attachments: management-server.log > > > After installing latest Management Server and zone creation, system VMs are > not getting created. The following exception is being generated: > 2014-09-24 17:37:17,918 WARN [c.c.u.d.Merovingian2] > (consoleproxy-1:ctx-bc88696c) Timed out on acquiring lock vm_instance1 . > Waited for 0seconds > 2014-09-24 17:37:17,919 WARN [c.c.c.ConsoleProxyManagerImpl] > (consoleproxy-1:ctx-bc88696c) Runtime Exception while trying to start console > proxy > com.cloud.utils.exception.CloudRuntimeException: Timed out on acquiring lock > vm_instance1 . Waited for 0seconds > at com.cloud.utils.db.Merovingian2.acquire(Merovingian2.java:143) > at > com.cloud.utils.db.TransactionLegacy.lock(TransactionLegacy.java:389) > at > com.cloud.utils.db.GenericDaoBase.lockInLockTable(GenericDaoBase.java:1057) > 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:601) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at $Proxy53.lockInLockTable(Unknown Source) > at > com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3927) > at > com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3922) > at > com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49) > at com.cloud.utils.db.Transaction.execute(Transaction.java:37) > at com.cloud.utils.db.Transaction.execute(Transaction.java:46) > at > com.cloud.vm.VirtualMachineManagerImpl.startVmThroughJobQueue(VirtualMachineManagerImpl.java:3922) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:769) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:748) > at > com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:540) > at > com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:919) > at > com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1640) > at > com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:157) > at > com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:120) > at > com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:35) > at > com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:90) > at > com.cloud.vm.SystemVmLoadScanner$1.runInContext(SystemVmLoadScanner.java:81) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManage
[jira] [Updated] (CLOUDSTACK-3367) When one primary storage fails, all XenServer hosts get rebooted, killing all VMs, even those not on this primary storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] France updated CLOUDSTACK-3367: --- Affects Version/s: 4.3.1 4.5.0 > When one primary storage fails, all XenServer hosts get rebooted, killing all > VMs, even those not on this primary storage. > -- > > Key: CLOUDSTACK-3367 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3367 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, XenServer >Affects Versions: 4.1.0, 4.2.0, 4.5.0, 4.3.1 > Environment: CentOS 6.3, XenServer 6.0.2 + all hotfixes, CloudStack > 4.1.0 >Reporter: France > Fix For: Future > > > As the title says: if only one of the primary storages fails, all XenServer > hosts get rebooted one by one. Because i have many primary storages, which > are/were running fine with other VMs, rebooting XenServer Hipervisor is an > overkill. Please disable this or implement just stopping/killing the VMs > running on that storage and try to re-attach that storage only. > Problem was reported on the mailing list, as well as a workaround for > XenServer. So i'm not the only one hit by this "bug/feature". Workaround for > now is as follows: > 1. Modify /opt/xensource/bin/xenheartbeat.sh on all your Hosts, commenting > out the two entries which have "reboot -f" > 2. Identify the PID of the script - pidof -x xenheartbeat.sh > 3. Restart the Script - kill > 4. Force reconnect Host from the UI, the script will then re-launch on > reconnect -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-3367) When one primary storage fails, all XenServer hosts get rebooted, killing all VMs, even those not on this primary storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146276#comment-14146276 ] France commented on CLOUDSTACK-3367: Anyone willing to pick this up? It has been well over a year by now. :-( > When one primary storage fails, all XenServer hosts get rebooted, killing all > VMs, even those not on this primary storage. > -- > > Key: CLOUDSTACK-3367 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3367 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, XenServer >Affects Versions: 4.1.0, 4.2.0, 4.5.0, 4.3.1 > Environment: CentOS 6.3, XenServer 6.0.2 + all hotfixes, CloudStack > 4.1.0 >Reporter: France > Fix For: Future > > > As the title says: if only one of the primary storages fails, all XenServer > hosts get rebooted one by one. Because i have many primary storages, which > are/were running fine with other VMs, rebooting XenServer Hipervisor is an > overkill. Please disable this or implement just stopping/killing the VMs > running on that storage and try to re-attach that storage only. > Problem was reported on the mailing list, as well as a workaround for > XenServer. So i'm not the only one hit by this "bug/feature". Workaround for > now is as follows: > 1. Modify /opt/xensource/bin/xenheartbeat.sh on all your Hosts, commenting > out the two entries which have "reboot -f" > 2. Identify the PID of the script - pidof -x xenheartbeat.sh > 3. Restart the Script - kill > 4. Force reconnect Host from the UI, the script will then re-launch on > reconnect -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7623) SystemVMs not starting
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Brett updated CLOUDSTACK-7623: --- Summary: SystemVMs not starting (was: SystemVMs not getting created on VmWare) > SystemVMs not starting > -- > > Key: CLOUDSTACK-7623 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7623 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.5.0 >Reporter: Pavan Kumar Bandarupally >Priority: Blocker > Fix For: 4.5.0 > > Attachments: management-server.log > > > After installing latest Management Server and zone creation, system VMs are > not getting created. The following exception is being generated: > 2014-09-24 17:37:17,918 WARN [c.c.u.d.Merovingian2] > (consoleproxy-1:ctx-bc88696c) Timed out on acquiring lock vm_instance1 . > Waited for 0seconds > 2014-09-24 17:37:17,919 WARN [c.c.c.ConsoleProxyManagerImpl] > (consoleproxy-1:ctx-bc88696c) Runtime Exception while trying to start console > proxy > com.cloud.utils.exception.CloudRuntimeException: Timed out on acquiring lock > vm_instance1 . Waited for 0seconds > at com.cloud.utils.db.Merovingian2.acquire(Merovingian2.java:143) > at > com.cloud.utils.db.TransactionLegacy.lock(TransactionLegacy.java:389) > at > com.cloud.utils.db.GenericDaoBase.lockInLockTable(GenericDaoBase.java:1057) > 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:601) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at $Proxy53.lockInLockTable(Unknown Source) > at > com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3927) > at > com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3922) > at > com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49) > at com.cloud.utils.db.Transaction.execute(Transaction.java:37) > at com.cloud.utils.db.Transaction.execute(Transaction.java:46) > at > com.cloud.vm.VirtualMachineManagerImpl.startVmThroughJobQueue(VirtualMachineManagerImpl.java:3922) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:769) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:748) > at > com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:540) > at > com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:919) > at > com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1640) > at > com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:157) > at > com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:120) > at > com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:35) > at > com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:90) > at > com.cloud.vm.SystemVmLoadScanner$1.runInContext(SystemVmLoadScanner.java:81) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runW
[jira] [Updated] (CLOUDSTACK-7623) SystemVMs not getting created on VmWare
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavan Kumar Bandarupally updated CLOUDSTACK-7623: - Attachment: management-server.log > SystemVMs not getting created on VmWare > --- > > Key: CLOUDSTACK-7623 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7623 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.5.0 >Reporter: Pavan Kumar Bandarupally >Priority: Blocker > Fix For: 4.5.0 > > Attachments: management-server.log > > > After installing latest Management Server and zone creation, system VMs are > not getting created. The following exception is being generated: > 2014-09-24 17:37:17,918 WARN [c.c.u.d.Merovingian2] > (consoleproxy-1:ctx-bc88696c) Timed out on acquiring lock vm_instance1 . > Waited for 0seconds > 2014-09-24 17:37:17,919 WARN [c.c.c.ConsoleProxyManagerImpl] > (consoleproxy-1:ctx-bc88696c) Runtime Exception while trying to start console > proxy > com.cloud.utils.exception.CloudRuntimeException: Timed out on acquiring lock > vm_instance1 . Waited for 0seconds > at com.cloud.utils.db.Merovingian2.acquire(Merovingian2.java:143) > at > com.cloud.utils.db.TransactionLegacy.lock(TransactionLegacy.java:389) > at > com.cloud.utils.db.GenericDaoBase.lockInLockTable(GenericDaoBase.java:1057) > 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:601) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at $Proxy53.lockInLockTable(Unknown Source) > at > com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3927) > at > com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3922) > at > com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49) > at com.cloud.utils.db.Transaction.execute(Transaction.java:37) > at com.cloud.utils.db.Transaction.execute(Transaction.java:46) > at > com.cloud.vm.VirtualMachineManagerImpl.startVmThroughJobQueue(VirtualMachineManagerImpl.java:3922) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:769) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:748) > at > com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:540) > at > com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:919) > at > com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1640) > at > com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:157) > at > com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:120) > at > com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:35) > at > com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:90) > at > com.cloud.vm.SystemVmLoadScanner$1.runInContext(SystemVmLoadScanner.java:81) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultMana
[jira] [Created] (CLOUDSTACK-7623) SystemVMs not getting created on VmWare
Pavan Kumar Bandarupally created CLOUDSTACK-7623: Summary: SystemVMs not getting created on VmWare Key: CLOUDSTACK-7623 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7623 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.5.0 Reporter: Pavan Kumar Bandarupally Priority: Blocker Fix For: 4.5.0 After installing latest Management Server and zone creation, system VMs are not getting created. The following exception is being generated: 2014-09-24 17:37:17,918 WARN [c.c.u.d.Merovingian2] (consoleproxy-1:ctx-bc88696c) Timed out on acquiring lock vm_instance1 . Waited for 0seconds 2014-09-24 17:37:17,919 WARN [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-bc88696c) Runtime Exception while trying to start console proxy com.cloud.utils.exception.CloudRuntimeException: Timed out on acquiring lock vm_instance1 . Waited for 0seconds at com.cloud.utils.db.Merovingian2.acquire(Merovingian2.java:143) at com.cloud.utils.db.TransactionLegacy.lock(TransactionLegacy.java:389) at com.cloud.utils.db.GenericDaoBase.lockInLockTable(GenericDaoBase.java:1057) 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:601) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy53.lockInLockTable(Unknown Source) at com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3927) at com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3922) at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49) at com.cloud.utils.db.Transaction.execute(Transaction.java:37) at com.cloud.utils.db.Transaction.execute(Transaction.java:46) at com.cloud.vm.VirtualMachineManagerImpl.startVmThroughJobQueue(VirtualMachineManagerImpl.java:3922) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:769) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:748) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:540) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:919) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1640) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:157) at com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:120) at com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:35) at com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:90) at com.cloud.vm.SystemVmLoadScanner$1.runInContext(SystemVmLoadScanner.java:81) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java
[jira] [Commented] (CLOUDSTACK-7622) Can't delete the network when providers this network uses, are disabled
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146267#comment-14146267
]
Jayapal Reddy commented on CLOUDSTACK-7622:
---
MS logs:
2014-09-24 15:35:18,719 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(1949422689@qtp-2019457093-0:ctx-fe1d81bc ctx-ecb8d94c) submit async job-29,
details: AsyncJobVO {id:29, userId: 2, accountId: 2, instanceType: None,
instanceId: null, cmd: com.cloud.api.commands.AddSrxFirewallCmd, cmdInfo:
{"physicalnetworkid":"5a343691-932d-4f4c-9e65-da754b5b93cb","sessionkey":"0is9qGB4EiFibf2X7eQD8KKitIs\u003d","cmdEventType":"PHYSICAL.FIREWALL.ADD","ctxUserId":"2","httpmethod":"POST","password":"password","url":"https://10.147.40.3?publicinterface\u003dfe00\u0026privateinterface\u003dfe01\u0026numretries\u003d2\u0026timeout\u003d300\u0026fwdevicededicated\u003dfalse","response":"json","ctxDetails":"{\"com.cloud.network.PhysicalNetwork\":\"5a343691-932d-4f4c-9e65-da754b5b93cb\"}","username":"admin","networkdevicetype":"JuniperSRXFirewall","ctxAccountId":"2","ctxStartEventId":"78"},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 1, completeMsid: null, lastUpdated: null, lastPolled: null,
created: null}
2014-09-24 15:35:18,720 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-2:ctx-5ec8cde4 job-29) Add job-29 into job monitoring
2014-09-24 15:35:18,721 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-2:ctx-5ec8cde4 job-29) Executing AsyncJobVO {id:29, userId:
2, accountId: 2, instanceType: None, instanceId: null, cmd:
com.cloud.api.commands.AddSrxFirewallCmd, cmdInfo:
{"physicalnetworkid":"5a343691-932d-4f4c-9e65-da754b5b93cb","sessionkey":"0is9qGB4EiFibf2X7eQD8KKitIs\u003d","cmdEventType":"PHYSICAL.FIREWALL.ADD","ctxUserId":"2","httpmethod":"POST","password":"password","url":"https://10.147.40.3?publicinterface\u003dfe00\u0026privateinterface\u003dfe01\u0026numretries\u003d2\u0026timeout\u003d300\u0026fwdevicededicated\u003dfalse","response":"json","ctxDetails":"{\"com.cloud.network.PhysicalNetwork\":\"5a343691-932d-4f4c-9e65-da754b5b93cb\"}","username":"admin","networkdevicetype":"JuniperSRXFirewall","ctxAccountId":"2","ctxStartEventId":"78"},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 1, completeMsid: null, lastUpdated: null, lastPolled: null,
created: null}
> Can't delete the network when providers this network uses, are disabled
> ---
>
> Key: CLOUDSTACK-7622
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7622
> 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
>Assignee: Jayapal Reddy
> Fix For: 4.5.0
>
>
> Steps to reproduce:
> create network, use VR as a provider for its services
> disable VR provider
> try to delete the network. Shutdown network fails due to disabled provider.
> Shutdown should be successful even when provider is disabled
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7590) Deletion of Account is not deleting the account from the database
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146253#comment-14146253
]
Rahul Rege commented on CLOUDSTACK-7590:
This blocker tracks the schema changes for 4.5
> Deletion of Account is not deleting the account from the database
> -
>
> Key: CLOUDSTACK-7590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7590
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Priority: Critical
> Fix For: 4.5.0
>
>
> Deletion of account marks the account as removed in the database but doesnt
> remove the record from the database as shown below:
> mysql> select * from account where removed is not null \G
> *** 1. row ***
> id: 7
>account_name: CSRegularVPNClientUser
>uuid: 96e06a77-fa96-4e38-b380-023d406d445e
>type: 0
> domain_id: 1
> state: enabled
> removed: 2014-09-20 00:33:41
> cleanup_needed: 0
> network_domain: NULL
> default_zone_id: NULL
> default: 0
> 1 row in set (0.00 sec)
> mysql>
> *If anyone wants to recreate the account with the same name. It fails with
> the below exception:*
> {noformat}
> 2014-09-20 00:27:05,880 DEBUG [c.c.u.AccountManagerImpl]
> (catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) Creating user:
> CSRegularVPNClientUser, accountId: 6 timezone:null
> 2014-09-20 00:27:05,882 DEBUG [c.c.u.d.T.Transaction]
> (catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) Rolling back the
> transaction: Time = 16 Name = catalina-exec-11; called by
> -TransactionLegacy.rollback:902-TransactionLegacy.removeUpTo:845-TransactionLegacy.close:669-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy67.persist:-1-AccountManagerImpl.createUser:1962-AccountManagerImpl$2.doInTransaction:1039-AccountManagerImpl$2.doInTransaction:1027
> 2014-09-20 00:27:05,898 ERROR [c.c.a.ApiServer]
> (catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) unhandled exception
> executing api command: [Ljava.lang.String;@5b4cfa82
> javax.persistence.EntityExistsException: Entity already exists:
> at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1398)
> at com.cloud.user.dao.UserDaoImpl.persist(UserDaoImpl.java:141)
> at com.cloud.user.dao.UserDaoImpl.persist(UserDaoImpl.java:33)
> at sun.reflect.GeneratedMethodAccessor105.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at
> com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy67.persist(Unknown Source)
> at
> com.cloud.user.AccountManagerImpl.createUser(AccountManagerImpl.java:1962)
> at
> com.cloud.user.AccountManagerImpl$2.doInTransaction(AccountManagerImpl.java:1039)
> at
> com.cloud.user.AccountManagerImpl$2.doInTransaction(AccountManagerImpl.java:1027)
> at
> com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49)
> at com.cloud.utils.db.Transaction.execute(Transaction.java:37)
> at com.cloud.utils.db.Transaction.execute(Transaction.java:46)
> at
> com.cloud.user.AccountManagerImpl.createUserAccount(AccountManagerImpl.java:1027)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
[jira] [Created] (CLOUDSTACK-7622) Can't delete the network when providers this network uses, are disabled
Jayapal Reddy created CLOUDSTACK-7622: - Summary: Can't delete the network when providers this network uses, are disabled Key: CLOUDSTACK-7622 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7622 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 Assignee: Jayapal Reddy Fix For: 4.5.0 Steps to reproduce: create network, use VR as a provider for its services disable VR provider try to delete the network. Shutdown network fails due to disabled provider. Shutdown should be successful even when provider is disabled -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7590) Deletion of Account is not deleting the account from the database
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146244#comment-14146244
]
Rahul Rege commented on CLOUDSTACK-7590:
I tried to reproduce this on 4.4 first but it works correctly. It does create
multiple users inside the db with same name on subsequent removal and addition
of accounts but does not give any error of user already present when its
removed. I then upgraded to 4.5 and during upgrade itself it failed because I
had 2 deleted users in the db with same name. So, I had to redeploy the db and
given that it is not allowing the same username, I am sure it will give the
error.
The db schema has changed in 4.5 which has caused this issue and it would fail
to create a new user with same name and also during upgrades in case you have
recreated any users in the past on earlier versions, it will not migrate the db
due to different schema (unless there is another way to do it)
Fixing the db schema seems to be the right choice here than removing the user
alltogether in case they are using it for some auditing purpose.
> Deletion of Account is not deleting the account from the database
> -
>
> Key: CLOUDSTACK-7590
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7590
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Priority: Critical
> Fix For: 4.5.0
>
>
> Deletion of account marks the account as removed in the database but doesnt
> remove the record from the database as shown below:
> mysql> select * from account where removed is not null \G
> *** 1. row ***
> id: 7
>account_name: CSRegularVPNClientUser
>uuid: 96e06a77-fa96-4e38-b380-023d406d445e
>type: 0
> domain_id: 1
> state: enabled
> removed: 2014-09-20 00:33:41
> cleanup_needed: 0
> network_domain: NULL
> default_zone_id: NULL
> default: 0
> 1 row in set (0.00 sec)
> mysql>
> *If anyone wants to recreate the account with the same name. It fails with
> the below exception:*
> {noformat}
> 2014-09-20 00:27:05,880 DEBUG [c.c.u.AccountManagerImpl]
> (catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) Creating user:
> CSRegularVPNClientUser, accountId: 6 timezone:null
> 2014-09-20 00:27:05,882 DEBUG [c.c.u.d.T.Transaction]
> (catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) Rolling back the
> transaction: Time = 16 Name = catalina-exec-11; called by
> -TransactionLegacy.rollback:902-TransactionLegacy.removeUpTo:845-TransactionLegacy.close:669-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy67.persist:-1-AccountManagerImpl.createUser:1962-AccountManagerImpl$2.doInTransaction:1039-AccountManagerImpl$2.doInTransaction:1027
> 2014-09-20 00:27:05,898 ERROR [c.c.a.ApiServer]
> (catalina-exec-11:ctx-bfa880b6 ctx-e82baf36 ctx-1b71100c) unhandled exception
> executing api command: [Ljava.lang.String;@5b4cfa82
> javax.persistence.EntityExistsException: Entity already exists:
> at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1398)
> at com.cloud.user.dao.UserDaoImpl.persist(UserDaoImpl.java:141)
> at com.cloud.user.dao.UserDaoImpl.persist(UserDaoImpl.java:33)
> at sun.reflect.GeneratedMethodAccessor105.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at
> com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy67.persist(Unknown
[jira] [Closed] (CLOUDSTACK-7621) Database schema not getting upgraded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavan Kumar Bandarupally closed CLOUDSTACK-7621. Working fine after the commit 093fa6f0a53bd031a09e4042c3aa25860bc947e5 has been reverted. > Database schema not getting upgraded > > > Key: CLOUDSTACK-7621 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7621 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Pavan Kumar Bandarupally >Priority: Blocker > Fix For: 4.5.0 > > Attachments: localhost.2014-09-24.log, management-server.log > > > After installing management server , the process is stuck at database schema > update. The update doesn't progress ahead from 4.0.0 > mysql> select * from version; > ++-+-+--+ > | id | version | updated | step | > ++-+-+--+ > | 1 | 4.0.0 | 2014-09-24 12:14:11 | Complete | > ++-+-+--+ > 1 row in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7621) Database schema not getting upgraded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Brett resolved CLOUDSTACK-7621. Resolution: Fixed Appears to be fixed by https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=2503aaafef5280ce20e319c77623f9709d85151a which reverted [~anthonyxu]'s commit https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=093fa6f0a53bd031a09e4042c3aa25860bc947e5 Looks to be just a coincidence that some schema changes came in at the same time - apologies for any confusion... > Database schema not getting upgraded > > > Key: CLOUDSTACK-7621 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7621 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Pavan Kumar Bandarupally >Priority: Blocker > Fix For: 4.5.0 > > Attachments: localhost.2014-09-24.log, management-server.log > > > After installing management server , the process is stuck at database schema > update. The update doesn't progress ahead from 4.0.0 > mysql> select * from version; > ++-+-+--+ > | id | version | updated | step | > ++-+-+--+ > | 1 | 4.0.0 | 2014-09-24 12:14:11 | Complete | > ++-+-+--+ > 1 row in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7583) Send statistics collected by StatsCollector to optional Graphite host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146225#comment-14146225 ] ASF subversion and git services commented on CLOUDSTACK-7583: - Commit e4d2ab32f60e94e5610bca6444b122bc85f10b58 in cloudstack's branch refs/heads/statscollector-graphite from [~widodh] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e4d2ab3 ] CLOUDSTACK-7583: Send VmStats to Graphite host when configured This allows external processing of VmStats information without using the usage server of CloudStack Statistics are being send to Graphite using UDP and not TCP. UDP is used to prevent the management server waiting for TCP timeouts when the Graphite server is unavailable > Send statistics collected by StatsCollector to optional Graphite host > - > > Key: CLOUDSTACK-7583 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7583 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: Future >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Fix For: Future > > > It would be very useful if the StatsCollector inside the management server > could also send all the stats collected to a Graphite server in addition to > the usage database. > This allows for easy graph generation for CPU, Network and Disk I/O of > Instances and hosts. > Via a global setting we can configure: > * Graphite host > * Graphite port > * Key prefix > We can then send Instance and Host information, like: > cloudstack.stats.instances..cpu.num 1 > cloudstack.stats.instances..cpu.utilization 50 > cloudstack.stats.instances..network.read_kbs 4817 > cloudstack.stats.instances..network.write_kbs 672 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7571) changing value of cpu/mem.overprovisioning.factor for xen cluster is not affecting total memory at zone level
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146223#comment-14146223 ] ASF subversion and git services commented on CLOUDSTACK-7571: - Commit 476733cb92634c8494fe64762d7fbc178292a754 in cloudstack's branch refs/heads/master from [~bharat.kumar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=476733c ] CLOUDSTACK-7571 changing value of cpu/mem.overprovisioning.factor for xen cluster is not affecting total memory at zone level > changing value of cpu/mem.overprovisioning.factor for xen cluster is not > affecting total memory at zone level > - > > Key: CLOUDSTACK-7571 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7571 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > steps to reproduce > == > 1-prepare a CS3.6 setup with vmware and xen cluster > 2-set mem.overprovisioning.factor=3 and cpu.overprovisioning.factor=2 > 2-upgrade it to CCP4.3 > 3-record total memory and cpu at zone level > 4-change cpu/memory overprovisioning for xen server cluster to some valid > value > expected > = > at zone level total memory should get changed , depends on overprovisioning > value > Actual > === > 1-total memory is not getting changed at zone level > 2-but total memory/cpu of xen cluster is getting changed with > overprovisioning factor > My observation > == > 1-if i change overspovisioning factor of vmware cluster total memory is > getting changed > 2-In fresh setup with one xen cluster i did not see this problem -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7598) Cloudstack VM State is not in sync with state from Hypervisor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146216#comment-14146216 ] Devdeep Singh commented on CLOUDSTACK-7598: --- As part of commit 7f440854f7bcd41a1bd6581c0239cde2e98261b7, the directagentattache was updated to retry PingCommand to deal with network glitches. However, there is a minor bug in the logic because of which the agent attache is never sending the PingCommand. The vm state is retrieved as part of this ping command. So if a vm is stopped on the hypervisor, cloudstack will never update the state of the vms in its db. The retyr logic needs to be fixed to make sure the command is send atleast once. > Cloudstack VM State is not in sync with state from Hypervisor > - > > Key: CLOUDSTACK-7598 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7598 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.5.0 >Reporter: Sailaja Mada >Assignee: Devdeep Singh >Priority: Blocker > Fix For: 4.5.0 > > Attachments: vmsynclogs.rar > > > Steps: > 1. Install and configure Adv zone using XS 6.5 Hypervisor > 2. Deploy Linux VM , Windows VM > 3. After VM is up and running login to the VM and shutdown the instance > 4. It moved to Shutdown state in the hypervisor > 5. But this state is not synced to cloudstack and it remained in running > state in cloudstack > Observation: > Cloudstack VM State is not in sync with state from Hypervisor > Ob -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7598) Cloudstack VM State is not in sync with state from Hypervisor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146216#comment-14146216 ] Devdeep Singh edited comment on CLOUDSTACK-7598 at 9/24/14 11:22 AM: - As part of commit 7f440854f7bcd41a1bd6581c0239cde2e98261b7, the directagentattache was updated to retry PingCommand to deal with network glitches. However, there is a minor bug in the logic because of which the agent attache is never sending the PingCommand. The vm state is retrieved as part of this ping command. So if a vm is stopped on the hypervisor, cloudstack will never update the state of the vms in its db. The retry logic needs to be fixed to make sure the command is send atleast once. was (Author: devdeep): As part of commit 7f440854f7bcd41a1bd6581c0239cde2e98261b7, the directagentattache was updated to retry PingCommand to deal with network glitches. However, there is a minor bug in the logic because of which the agent attache is never sending the PingCommand. The vm state is retrieved as part of this ping command. So if a vm is stopped on the hypervisor, cloudstack will never update the state of the vms in its db. The retyr logic needs to be fixed to make sure the command is send atleast once. > Cloudstack VM State is not in sync with state from Hypervisor > - > > Key: CLOUDSTACK-7598 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7598 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.5.0 >Reporter: Sailaja Mada >Assignee: Devdeep Singh >Priority: Blocker > Fix For: 4.5.0 > > Attachments: vmsynclogs.rar > > > Steps: > 1. Install and configure Adv zone using XS 6.5 Hypervisor > 2. Deploy Linux VM , Windows VM > 3. After VM is up and running login to the VM and shutdown the instance > 4. It moved to Shutdown state in the hypervisor > 5. But this state is not synced to cloudstack and it remained in running > state in cloudstack > Observation: > Cloudstack VM State is not in sync with state from Hypervisor > Ob -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7534) ResetVM for VM with attached datadisk fails when enable.ha.storage.migration is false
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harikrishna Patnala resolved CLOUDSTACK-7534. - Resolution: Fixed > ResetVM for VM with attached datadisk fails when enable.ha.storage.migration > is false > - > > Key: CLOUDSTACK-7534 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7534 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Harikrishna Patnala >Assignee: Harikrishna Patnala > Fix For: 4.5.0 > > > ResetVM for a VM having a attached datadisk fails if, > 1. there are 2 or more storage pools in the cluster > 2. enable.ha.storage.migration is set to false > 3. allocator has chosen a different pool for the datadisk than where it > currently exists and migration from one pool to another failed because > enable.ha.storage.migration set to false. > The issue is currently "enable.ha.storage.migration" applies to both normal > and HA deployment. We should have another parameter which is specific to > normal deployments (say enable.storage.migration) so that during migration > check we can clearly differentiate normal and HA deployments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7534) ResetVM for VM with attached datadisk fails when enable.ha.storage.migration is false
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146205#comment-14146205 ] ASF subversion and git services commented on CLOUDSTACK-7534: - Commit c55bc0b2d11be4820a24af426e23da3db54a0cb1 in cloudstack's branch refs/heads/master from [~harikrishna.patnala] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c55bc0b ] CLOUDSTACK-7534: ResetVM for VM with attached datadisk fails when enable.ha.storage.migration is false Separate global config to enable/disable Storage Migration during normal deployment Introduced a configuration parameter named enable.storage.migration > ResetVM for VM with attached datadisk fails when enable.ha.storage.migration > is false > - > > Key: CLOUDSTACK-7534 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7534 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Harikrishna Patnala >Assignee: Harikrishna Patnala > Fix For: 4.5.0 > > > ResetVM for a VM having a attached datadisk fails if, > 1. there are 2 or more storage pools in the cluster > 2. enable.ha.storage.migration is set to false > 3. allocator has chosen a different pool for the datadisk than where it > currently exists and migration from one pool to another failed because > enable.ha.storage.migration set to false. > The issue is currently "enable.ha.storage.migration" applies to both normal > and HA deployment. We should have another parameter which is specific to > normal deployments (say enable.storage.migration) so that during migration > check we can clearly differentiate normal and HA deployments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7598) Cloudstack VM State is not in sync with state from Hypervisor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Devdeep Singh reassigned CLOUDSTACK-7598: - Assignee: Devdeep Singh > Cloudstack VM State is not in sync with state from Hypervisor > - > > Key: CLOUDSTACK-7598 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7598 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.5.0 >Reporter: Sailaja Mada >Assignee: Devdeep Singh >Priority: Blocker > Fix For: 4.5.0 > > Attachments: vmsynclogs.rar > > > Steps: > 1. Install and configure Adv zone using XS 6.5 Hypervisor > 2. Deploy Linux VM , Windows VM > 3. After VM is up and running login to the VM and shutdown the instance > 4. It moved to Shutdown state in the hypervisor > 5. But this state is not synced to cloudstack and it remained in running > state in cloudstack > Observation: > Cloudstack VM State is not in sync with state from Hypervisor > Ob -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7536) user vm can get a gateway ip in case of shared network.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146188#comment-14146188 ] Bharat Kumar commented on CLOUDSTACK-7536: -- https://reviews.apache.org/r/25991/ > user vm can get a gateway ip in case of shared network. > --- > > Key: CLOUDSTACK-7536 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7536 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > steps to reproduce. > 1.) create a shared network with the following details. > gateway 10.136.10.1 > netmask 255.255.255.0 > guest ip range 10.136.10.1 to 10.136.10.20 (note that the gateway ip is > a part of the guest ip range.) > 2.) deploy a vm > the gateway ip gets allocated to a uservm. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7536) user vm can get a gateway ip in case of shared network.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7536: - Status: Reviewable (was: In Progress) > user vm can get a gateway ip in case of shared network. > --- > > Key: CLOUDSTACK-7536 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7536 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > steps to reproduce. > 1.) create a shared network with the following details. > gateway 10.136.10.1 > netmask 255.255.255.0 > guest ip range 10.136.10.1 to 10.136.10.20 (note that the gateway ip is > a part of the guest ip range.) > 2.) deploy a vm > the gateway ip gets allocated to a uservm. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7574) Fail to create Windows 2012r2 VM with OS type: Windows Server 2012 R2 (64-bit)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146181#comment-14146181 ] ASF subversion and git services commented on CLOUDSTACK-7574: - Commit df4d5ede901eb9cdce4b2bd905ea476d28f6b248 in cloudstack's branch refs/heads/4.4 from [~pdion] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=df4d5ed ] CLOUDSTACK-7574, CREATE TABLE cloud.baremetal_rct > Fail to create Windows 2012r2 VM with OS type: Windows Server 2012 R2 (64-bit) > -- > > Key: CLOUDSTACK-7574 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7574 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, XenServer >Affects Versions: 4.4.0, 4.4.1 >Reporter: Pierre-Luc Dion >Assignee: Pierre-Luc Dion >Priority: Minor > > Cannot create Windows 2012r2 VM from an ISO with OS type: "Windows Server > 2012 R2 (64-bit)", if the OS type is "Windows Server 2012 (64-bit)" The VM > will succeed to create and boot from the iso. > This as been reported by motty.c...@gmail.com. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7621) Database schema not getting upgraded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavan Kumar Bandarupally updated CLOUDSTACK-7621: - Attachment: localhost.2014-09-24.log > Database schema not getting upgraded > > > Key: CLOUDSTACK-7621 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7621 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Pavan Kumar Bandarupally >Priority: Blocker > Fix For: 4.5.0 > > Attachments: localhost.2014-09-24.log, management-server.log > > > After installing management server , the process is stuck at database schema > update. The update doesn't progress ahead from 4.0.0 > mysql> select * from version; > ++-+-+--+ > | id | version | updated | step | > ++-+-+--+ > | 1 | 4.0.0 | 2014-09-24 12:14:11 | Complete | > ++-+-+--+ > 1 row in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7617) [Automation] Fix the script "test_clustom_hostname.py" - Do not use the same name to deploy multiple VMs.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gaurav Aradhye reassigned CLOUDSTACK-7617:
--
Assignee: Gaurav Aradhye
> [Automation] Fix the script "test_clustom_hostname.py" - Do not use the same
> name to deploy multiple VMs.
> -
>
> Key: CLOUDSTACK-7617
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7617
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Gaurav Aradhye
>Priority: Critical
> Fix For: 4.5.0
>
>
> The below mentioned code is resulting in multiple test case failures in the
> test suite. We should not use the same name to deploy multiple VMs in the
> test suite.
> {code}
> def test_04_edit_display_name(self):
> """ Test Edit the Display name Through the UI.
> """
> # Validate the following
> # 1) Set the Global Setting vm.instancename.flag to true
> # 2) Create a VM give a Display name.
> # 3) Once the VM is created stop the VM.
> # 4) Edit the VM Display name. The Display name will be changed but
> the
> #internal name will not be changed. The VM functionality must not
> #be effected.
> self.services["virtual_machine"]["name"] = "TestVM4"
> # Spawn an instance in that network
> self.debug("Deploying VM in account: %s" % self.account.name)
> virtual_machine = VirtualMachine.create(
> self.apiclient,
> self.services["virtual_machine"],
> accountid=self.account.name,
> domainid=self.account.domainid,
> serviceofferingid=self.service_offering.id,
> )
> {code}
> *Error:*
> {noformat}
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 332, in run
> testMethod()
> File "/root/cloudstack/test/integration/component/test_custom_hostname.py",
> line 540, in test_instance_name_with_hyphens
> serviceofferingid=self.service_offering.id,
> File "/usr/local/lib/python2.7/dist-packages/marvin/lib/base.py", line 476,
> in create
> virtual_machine = apiclient.deployVirtualMachine(cmd, method=method)
> File
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 706, in deployVirtualMachine
> response = self.connection.marvinRequest(command, response_type=response,
> method=method)
> File
> "/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py", line
> 379, in marvinRequest
> raise e
> 'Execute cmd: deployvirtualmachine failed, due to: errorCode: 431,
> errorText:The vm with hostName TestVM4 already exists in the network domain:
> cscbcloud.internal; network=Ntwk[373|Guest|8]\n
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7621) Database schema not getting upgraded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146109#comment-14146109 ] Sanjeev N commented on CLOUDSTACK-7621: --- Observed this even on the simulator environment. > Database schema not getting upgraded > > > Key: CLOUDSTACK-7621 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7621 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Pavan Kumar Bandarupally >Priority: Blocker > Fix For: 4.5.0 > > Attachments: management-server.log > > > After installing management server , the process is stuck at database schema > update. The update doesn't progress ahead from 4.0.0 > mysql> select * from version; > ++-+-+--+ > | id | version | updated | step | > ++-+-+--+ > | 1 | 4.0.0 | 2014-09-24 12:14:11 | Complete | > ++-+-+--+ > 1 row in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-5851) add a nic to vm failed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye closed CLOUDSTACK-5851. -- Resolution: Incomplete Closing because no further updates from Zhenglei > add a nic to vm failed > -- > > Key: CLOUDSTACK-5851 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5851 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.1.0 > Environment: cloudstack4.1.0 and xenserver6.0 >Reporter: zhenglei > > 1. Create a vm successfully in an advanced zone. > 2. Create a network with the default networkoffering successfully. There is > no vm in the network now, and also the vrouter is not started. > 3. Add the network to the vm by calling the restful api successfully. > 4. But when I login the cloudstack ui, I find the new network vrouter is not > started and its status is ”starting“. so add nic operation is failed. > 5. I want to check the vrouter by xencenter, but there is no this vrouter. > 6. At last, i check the management server log files, There is no any ERROR > and Exception. > I think the reason is the vrouter is not started, But i don't know why. I > also do some add nic or remove nic tests when a vrouer is running, and it is > normal. > so, why?Thanks... > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7621) Database schema not getting upgraded
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146076#comment-14146076
]
Alex Brett commented on CLOUDSTACK-7621:
Also from localhost log on another run:
{noformat}
SEVERE: Exception sending context initialized event to listener instance of
class org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener
org.springframework.context.ApplicationContextException: Failed to start bean
'cloudStackLifeCycle'; nested exception is
com.cloud.utils.exception.CloudRuntimeException: Caught: null
at
org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:170)
at
org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51)
at
org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:339)
at
org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:143)
at
org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:108)
at
org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:945)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:482)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContext(DefaultModuleDefinitionSet.java:145)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet$2.with(DefaultModuleDefinitionSet.java:122)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:245)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:233)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContexts(DefaultModuleDefinitionSet.java:117)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.load(DefaultModuleDefinitionSet.java:79)
at
org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory.loadModules(ModuleBasedContextFactory.java:37)
at
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:70)
at
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.(CloudStackSpringContext.java:57)
at
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.(CloudStackSpringContext.java:61)
at
org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener.contextInitialized(CloudStackContextLoaderListener.java:52)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3972)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4467)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
at
org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041)
at
org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at
org.apache.catalina.core.StandardService.start(StandardService.java:516)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:593)
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:601)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
at org.apa
[jira] [Commented] (CLOUDSTACK-7621) Database schema not getting upgraded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146070#comment-14146070 ] Alex Brett commented on CLOUDSTACK-7621: Looking at the history, I see the following two schema changes between a working build and a broken one: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=872b48b0c34d85d934344c8ccf33fa328d2748ed https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=b3c117a11eda3373a5a7187547a441be908f4453 [~pdion] could this be a side effect of these? > Database schema not getting upgraded > > > Key: CLOUDSTACK-7621 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7621 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Pavan Kumar Bandarupally >Priority: Blocker > Fix For: 4.5.0 > > Attachments: management-server.log > > > After installing management server , the process is stuck at database schema > update. The update doesn't progress ahead from 4.0.0 > mysql> select * from version; > ++-+-+--+ > | id | version | updated | step | > ++-+-+--+ > | 1 | 4.0.0 | 2014-09-24 12:14:11 | Complete | > ++-+-+--+ > 1 row in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7583) Send statistics collected by StatsCollector to optional Graphite host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146036#comment-14146036 ] ASF subversion and git services commented on CLOUDSTACK-7583: - Commit f7de57d92aadc01f605873ccb4652eeea15ebba6 in cloudstack's branch refs/heads/statscollector-graphite from [~widodh] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f7de57d ] CLOUDSTACK-7583: Send VmStats to Graphite host when configured This allows external processing of VmStats information without using the usage server of CloudStack > Send statistics collected by StatsCollector to optional Graphite host > - > > Key: CLOUDSTACK-7583 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7583 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: Future >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Fix For: Future > > > It would be very useful if the StatsCollector inside the management server > could also send all the stats collected to a Graphite server in addition to > the usage database. > This allows for easy graph generation for CPU, Network and Disk I/O of > Instances and hosts. > Via a global setting we can configure: > * Graphite host > * Graphite port > * Key prefix > We can then send Instance and Host information, like: > cloudstack.stats.instances..cpu.num 1 > cloudstack.stats.instances..cpu.utilization 50 > cloudstack.stats.instances..network.read_kbs 4817 > cloudstack.stats.instances..network.write_kbs 672 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7583) Send statistics collected by StatsCollector to optional Graphite host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146034#comment-14146034 ] ASF subversion and git services commented on CLOUDSTACK-7583: - Commit aa78e5709ec1400292d80cacb6f9cea7c1d958b7 in cloudstack's branch refs/heads/statscollector-graphite from [~widodh] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=aa78e57 ] CLOUDSTACK-7583: Send VmStats to Graphite host when configured This allows external processing of VmStats information without using the usage server of CloudStack > Send statistics collected by StatsCollector to optional Graphite host > - > > Key: CLOUDSTACK-7583 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7583 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: Future >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Fix For: Future > > > It would be very useful if the StatsCollector inside the management server > could also send all the stats collected to a Graphite server in addition to > the usage database. > This allows for easy graph generation for CPU, Network and Disk I/O of > Instances and hosts. > Via a global setting we can configure: > * Graphite host > * Graphite port > * Key prefix > We can then send Instance and Host information, like: > cloudstack.stats.instances..cpu.num 1 > cloudstack.stats.instances..cpu.utilization 50 > cloudstack.stats.instances..network.read_kbs 4817 > cloudstack.stats.instances..network.write_kbs 672 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
