[jira] [Commented] (CLOUDSTACK-8014) Failed to create a volume from snapshot - Discrepency in the resource count ?
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14240816#comment-14240816 ] Abhinandan Prateek commented on CLOUDSTACK-8014: Can you do that ? that will point us to the root if this. thank you. Failed to create a volume from snapshot - Discrepency in the resource count ? - Key: CLOUDSTACK-8014 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8014 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.1 Reporter: France As sent to mailing list: Hi all. We are on XS 6.0.2+Hotfixes and CS 4.3.1. (All errors we are getting nowadays have come up only after upgrade from 4.1.1, 4.1.1 worked perfectly.) After successfully creating s snapshot, I want to create a volume from it, so it can be downloaded offsite. After clicking “Create volume” I get an error Failed to create a volume. If i got to list of volumes, there is a volume with name as defined, but Status is empty, and only buttons for attach and destroy exist. I have taken a look at catalina.out and management-server.log. Here is the log detailing a failure. Can you see the problem? How should I fix it? Please advise me. Should I create a bug report? I have also manually checked space on all storages and it seems there is LOTS of free space. Resources based on CS Web GUI are: Primary Storage Allocated 15% Secondary Storage 5% 2014-12-03 12:20:42,493 DEBUG [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-2d51baa2) Zone 1 is ready to launch console proxy 2014-12-03 12:20:42,580 DEBUG [c.c.s.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-53354d18) Zone 1 is ready to launch secondary storage VM 2014-12-03 12:20:42,894 DEBUG [c.c.a.ApiServlet] (http-6443-exec-108:ctx-a228ce49) ===START=== 111.client.ip.111 -- GET command=listZonesavailable=trueresponse=jsonsessionkey=CENSORED%3D_=1417605814964 2014-12-03 12:20:42,909 DEBUG [c.c.a.ApiServlet] (http-6443-exec-108:ctx-a228ce49 ctx-74e696ca) ===END=== 111.client.ip.111 -- GET command=listZonesavailable=trueresponse=jsonsessionkey=CENSORED%3D_=1417605814964 2014-12-03 12:20:46,482 DEBUG [c.c.a.ApiServlet] (http-6443-exec-107:ctx-4a28e57c) ===START=== 111.client.ip.111 -- GET command=createVolumeresponse=jsonsessionkey=CENSORED%3Dsnapshotid=49e4bba9-844d-4b7b-aca2-95a318f17dc4name=testbrisi567_=1417605818552 2014-12-03 12:20:46,490 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,494 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,507 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to com.cloud.storage.SnapshotVO$$EnhancerByCGLIB$$3490cea0@60c95391 granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,571 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-166:ctx-d915e890) Add job-2804 into job monitoring 2014-12-03 12:20:46,571 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (Job-Executor-166:ctx-d915e890) Executing AsyncJobVO {id:2804, userId: 59, accountId: 60, instanceType: Volume, instanceId: 617, cmd: org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd, cmdInfo: {id:617,response:json,sessionkey:CENSORED\u003d,cmdEventType:VOLUME.CREATE,ctxUserId:59,snapshotid:49e4bba9-844d-4b7b-aca2-95a318f17dc4,name:testbrisi567,httpmethod:GET,_:1417605818552,ctxAccountId:60,ctxStartEventId:62488}, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: null, initMsid: 95545481387, completeMsid: null, lastUpdated: null, lastPolled: null, created: null} 2014-12-03 12:20:46,577 DEBUG [c.c.u.AccountManagerImpl] (Job-Executor-166:ctx-d915e890 ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,578 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) submit async job-2804, details: AsyncJobVO {id:2804, userId: 59, accountId: 60, instanceType: Volume, instanceId: 617, cmd: org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd, cmdInfo:
[jira] [Created] (CLOUDSTACK-8056) EN: Miss SC and UK keyboard option for VMware hypervisor when register a template
Sanjay Tripathi created CLOUDSTACK-8056: --- Summary: EN: Miss SC and UK keyboard option for VMware hypervisor when register a template Key: CLOUDSTACK-8056 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8056 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: Sanjay Tripathi Assignee: Sanjay Tripathi Fix For: 4.6.0 Attachments: screenshot-1.png Repro Steps: 1. Setup basic environments as normal. 2. Open a browser, log on Web Console. Go to Templates - Register template - Choose VMware as hypervisor - Focus on Keyboard type drop-down list. Expected Result: There should be US, JA, UK and SC keyboard options. Actual Result: Only list US and Japanese keyboard options, miss the SC and UK keyboard options. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8056) EN: Miss SC and UK keyboard option for VMware hypervisor when register a template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi updated CLOUDSTACK-8056: Attachment: screenshot-1.png EN: Miss SC and UK keyboard option for VMware hypervisor when register a template - Key: CLOUDSTACK-8056 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8056 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: Sanjay Tripathi Assignee: Sanjay Tripathi Fix For: 4.6.0 Attachments: screenshot-1.png Repro Steps: 1. Setup basic environments as normal. 2. Open a browser, log on Web Console. Go to Templates - Register template - Choose VMware as hypervisor - Focus on Keyboard type drop-down list. Expected Result: There should be US, JA, UK and SC keyboard options. Actual Result: Only list US and Japanese keyboard options, miss the SC and UK keyboard options. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8056) EN: Miss SC and UK keyboard option for VMware hypervisor when register a template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi updated CLOUDSTACK-8056: Attachment: (was: screenshot-1.png) EN: Miss SC and UK keyboard option for VMware hypervisor when register a template - Key: CLOUDSTACK-8056 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8056 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: Sanjay Tripathi Assignee: Sanjay Tripathi Fix For: 4.6.0 Repro Steps: 1. Setup basic environments as normal. 2. Open a browser, log on Web Console. Go to Templates - Register template - Choose VMware as hypervisor - Focus on Keyboard type drop-down list. Expected Result: There should be US, JA, UK and SC keyboard options. Actual Result: Only list US and Japanese keyboard options, miss the SC and UK keyboard options. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8056) EN: Miss SC and UK keyboard option for VMware hypervisor when register a template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14240830#comment-14240830 ] ASF subversion and git services commented on CLOUDSTACK-8056: - Commit 4d78703522d37980d7d3461b8bcaaa4dcdbaf4e0 in cloudstack's branch refs/heads/master from [~sanjay.tripathi] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4d78703 ] CLOUDSTACK-8056: EN: Miss SC and UK keyboard option for VMware hypervisor when register a template. EN: Miss SC and UK keyboard option for VMware hypervisor when register a template - Key: CLOUDSTACK-8056 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8056 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: Sanjay Tripathi Assignee: Sanjay Tripathi Fix For: 4.6.0 Repro Steps: 1. Setup basic environments as normal. 2. Open a browser, log on Web Console. Go to Templates - Register template - Choose VMware as hypervisor - Focus on Keyboard type drop-down list. Expected Result: There should be US, JA, UK and SC keyboard options. Actual Result: Only list US and Japanese keyboard options, miss the SC and UK keyboard options. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8056) EN: Miss SC and UK keyboard option for VMware hypervisor when register a template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi resolved CLOUDSTACK-8056. - Resolution: Fixed EN: Miss SC and UK keyboard option for VMware hypervisor when register a template - Key: CLOUDSTACK-8056 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8056 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: Sanjay Tripathi Assignee: Sanjay Tripathi Fix For: 4.6.0 Repro Steps: 1. Setup basic environments as normal. 2. Open a browser, log on Web Console. Go to Templates - Register template - Choose VMware as hypervisor - Focus on Keyboard type drop-down list. Expected Result: There should be US, JA, UK and SC keyboard options. Actual Result: Only list US and Japanese keyboard options, miss the SC and UK keyboard options. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (CLOUDSTACK-8014) Failed to create a volume from snapshot - Discrepency in the resource count ?
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinandan Prateek updated CLOUDSTACK-8014: --- Comment: was deleted (was: Can you do that ? that will point us to the root if this. thank you.) Failed to create a volume from snapshot - Discrepency in the resource count ? - Key: CLOUDSTACK-8014 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8014 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.1 Reporter: France As sent to mailing list: Hi all. We are on XS 6.0.2+Hotfixes and CS 4.3.1. (All errors we are getting nowadays have come up only after upgrade from 4.1.1, 4.1.1 worked perfectly.) After successfully creating s snapshot, I want to create a volume from it, so it can be downloaded offsite. After clicking “Create volume” I get an error Failed to create a volume. If i got to list of volumes, there is a volume with name as defined, but Status is empty, and only buttons for attach and destroy exist. I have taken a look at catalina.out and management-server.log. Here is the log detailing a failure. Can you see the problem? How should I fix it? Please advise me. Should I create a bug report? I have also manually checked space on all storages and it seems there is LOTS of free space. Resources based on CS Web GUI are: Primary Storage Allocated 15% Secondary Storage 5% 2014-12-03 12:20:42,493 DEBUG [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-2d51baa2) Zone 1 is ready to launch console proxy 2014-12-03 12:20:42,580 DEBUG [c.c.s.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-53354d18) Zone 1 is ready to launch secondary storage VM 2014-12-03 12:20:42,894 DEBUG [c.c.a.ApiServlet] (http-6443-exec-108:ctx-a228ce49) ===START=== 111.client.ip.111 -- GET command=listZonesavailable=trueresponse=jsonsessionkey=CENSORED%3D_=1417605814964 2014-12-03 12:20:42,909 DEBUG [c.c.a.ApiServlet] (http-6443-exec-108:ctx-a228ce49 ctx-74e696ca) ===END=== 111.client.ip.111 -- GET command=listZonesavailable=trueresponse=jsonsessionkey=CENSORED%3D_=1417605814964 2014-12-03 12:20:46,482 DEBUG [c.c.a.ApiServlet] (http-6443-exec-107:ctx-4a28e57c) ===START=== 111.client.ip.111 -- GET command=createVolumeresponse=jsonsessionkey=CENSORED%3Dsnapshotid=49e4bba9-844d-4b7b-aca2-95a318f17dc4name=testbrisi567_=1417605818552 2014-12-03 12:20:46,490 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,494 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,507 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to com.cloud.storage.SnapshotVO$$EnhancerByCGLIB$$3490cea0@60c95391 granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,571 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-166:ctx-d915e890) Add job-2804 into job monitoring 2014-12-03 12:20:46,571 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (Job-Executor-166:ctx-d915e890) Executing AsyncJobVO {id:2804, userId: 59, accountId: 60, instanceType: Volume, instanceId: 617, cmd: org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd, cmdInfo: {id:617,response:json,sessionkey:CENSORED\u003d,cmdEventType:VOLUME.CREATE,ctxUserId:59,snapshotid:49e4bba9-844d-4b7b-aca2-95a318f17dc4,name:testbrisi567,httpmethod:GET,_:1417605818552,ctxAccountId:60,ctxStartEventId:62488}, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: null, initMsid: 95545481387, completeMsid: null, lastUpdated: null, lastPolled: null, created: null} 2014-12-03 12:20:46,577 DEBUG [c.c.u.AccountManagerImpl] (Job-Executor-166:ctx-d915e890 ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,578 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) submit async job-2804, details: AsyncJobVO {id:2804, userId: 59, accountId: 60, instanceType: Volume, instanceId: 617, cmd: org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd, cmdInfo:
[jira] [Created] (CLOUDSTACK-8057) test_dedicate_guest_vlan_ranges.TestDeleteVlanRange.test_04_dedicate_guest_vlan_in_project - Mark test as invalid
Gaurav Aradhye created CLOUDSTACK-8057: -- Summary: test_dedicate_guest_vlan_ranges.TestDeleteVlanRange.test_04_dedicate_guest_vlan_in_project - Mark test as invalid Key: CLOUDSTACK-8057 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8057 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.5.0 The test case dedicates the vlan range to account but creates guest network in project, and then checks if the vlan of the network is from dedicated range. This is an invalid scenario. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8058) test_reset_ssh_keypair.py - test cases failing on EIP setup
Gaurav Aradhye created CLOUDSTACK-8058: -- Summary: test_reset_ssh_keypair.py - test cases failing on EIP setup Key: CLOUDSTACK-8058 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8058 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.5.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8059) test_host_high_availability.py - Add necessary code to check the hosts in cluster and update the host with appropriate tags to make it HA enabled
Gaurav Aradhye created CLOUDSTACK-8059: -- Summary: test_host_high_availability.py - Add necessary code to check the hosts in cluster and update the host with appropriate tags to make it HA enabled Key: CLOUDSTACK-8059 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8059 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.5.0 The test suite does not have the required code in setupClass() for the test cases to run properly. Required code includes: 1) Find the cluster with at least 3 Hosts 2) Make one of the hosts HA enabled. 3) Remove the host tags in the cleanup. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8014) Failed to create a volume from snapshot - Discrepency in the resource count ?
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14240972#comment-14240972 ] Rohit Yadav commented on CLOUDSTACK-8014: - Hi France, I found an issue. If you create a snapshot from a volume and then create a template from that snapshot; it tries to read the disk size from the volume's template and fails with NPE when the original template has been removed. The fix is on its way for this corner case. Failed to create a volume from snapshot - Discrepency in the resource count ? - Key: CLOUDSTACK-8014 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8014 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.1 Reporter: France As sent to mailing list: Hi all. We are on XS 6.0.2+Hotfixes and CS 4.3.1. (All errors we are getting nowadays have come up only after upgrade from 4.1.1, 4.1.1 worked perfectly.) After successfully creating s snapshot, I want to create a volume from it, so it can be downloaded offsite. After clicking “Create volume” I get an error Failed to create a volume. If i got to list of volumes, there is a volume with name as defined, but Status is empty, and only buttons for attach and destroy exist. I have taken a look at catalina.out and management-server.log. Here is the log detailing a failure. Can you see the problem? How should I fix it? Please advise me. Should I create a bug report? I have also manually checked space on all storages and it seems there is LOTS of free space. Resources based on CS Web GUI are: Primary Storage Allocated 15% Secondary Storage 5% 2014-12-03 12:20:42,493 DEBUG [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-2d51baa2) Zone 1 is ready to launch console proxy 2014-12-03 12:20:42,580 DEBUG [c.c.s.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-53354d18) Zone 1 is ready to launch secondary storage VM 2014-12-03 12:20:42,894 DEBUG [c.c.a.ApiServlet] (http-6443-exec-108:ctx-a228ce49) ===START=== 111.client.ip.111 -- GET command=listZonesavailable=trueresponse=jsonsessionkey=CENSORED%3D_=1417605814964 2014-12-03 12:20:42,909 DEBUG [c.c.a.ApiServlet] (http-6443-exec-108:ctx-a228ce49 ctx-74e696ca) ===END=== 111.client.ip.111 -- GET command=listZonesavailable=trueresponse=jsonsessionkey=CENSORED%3D_=1417605814964 2014-12-03 12:20:46,482 DEBUG [c.c.a.ApiServlet] (http-6443-exec-107:ctx-4a28e57c) ===START=== 111.client.ip.111 -- GET command=createVolumeresponse=jsonsessionkey=CENSORED%3Dsnapshotid=49e4bba9-844d-4b7b-aca2-95a318f17dc4name=testbrisi567_=1417605818552 2014-12-03 12:20:46,490 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,494 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,507 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to com.cloud.storage.SnapshotVO$$EnhancerByCGLIB$$3490cea0@60c95391 granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,571 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-166:ctx-d915e890) Add job-2804 into job monitoring 2014-12-03 12:20:46,571 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (Job-Executor-166:ctx-d915e890) Executing AsyncJobVO {id:2804, userId: 59, accountId: 60, instanceType: Volume, instanceId: 617, cmd: org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd, cmdInfo: {id:617,response:json,sessionkey:CENSORED\u003d,cmdEventType:VOLUME.CREATE,ctxUserId:59,snapshotid:49e4bba9-844d-4b7b-aca2-95a318f17dc4,name:testbrisi567,httpmethod:GET,_:1417605818552,ctxAccountId:60,ctxStartEventId:62488}, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: null, initMsid: 95545481387, completeMsid: null, lastUpdated: null, lastPolled: null, created: null} 2014-12-03 12:20:46,577 DEBUG [c.c.u.AccountManagerImpl] (Job-Executor-166:ctx-d915e890 ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,578 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) submit async job-2804, details: AsyncJobVO {id:2804, userId: 59, accountId: 60, instanceType: Volume, instanceId:
[jira] [Commented] (CLOUDSTACK-7974) deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14240990#comment-14240990 ] Rohit Yadav commented on CLOUDSTACK-7974: - [~jayapal] Since multiple nics/entries are not possible for the same host in a network I'm going to remove this line and test it. Can you comment if this will impact any other network topology? About dnsmasq I see there is a dnsmasq_edithosts.sh which looks like it should clean up old leases and restart dns service but it is using $DHCP_LEASES that is not defined anywhere, can you confirm if this actually works, if this $DHCP_LEASES is available from environment and if so does it go through /etc/hosts files to decide which entries to keep and which to purge? deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router Key: CLOUDSTACK-7974 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7974 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.3.0 Reporter: Yiping Zhang Assignee: Rohit Yadav Fix For: 4.5.0, 4.6.0, 4.4.2, 4.4.3, 4.3.2 We have noticed that entries for hosts which have been destroyed for a long time still exist in both /etc/dhcphosts.txt and /etc/hosts files on our Virtual Routers. To reproduce this bug, just create an instance, note down its MAC and IP address, then destroy the instance from web UI. Now check virtual router, and you will find that the entries still exist in /etc/dhcphosts.txt and /etc/hosts files. I did a bit more digging on virtual router, and immediately noticed the following: 1. /root/edithosts.sh script is only called when an instance is created, but not when an instance is destroyed. 2. After reading /root/edithosts.sh script, I am pretty certain that the function of this script is to add info about newly created instances into /etc/hosts and /etc/dhcphosts.txt files. So the script should really be renamed as /root/addhosts.sh to reflect its true function. 3. there is no script to properly delete entries from /etc/hosts and /etc/dhcphosts.txt file when instances are destroyed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8059) test_host_high_availability.py - Add necessary code to check the hosts in cluster and update the host with appropriate tags to make it HA enabled
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye updated CLOUDSTACK-8059: --- Status: Reviewable (was: In Progress) test_host_high_availability.py - Add necessary code to check the hosts in cluster and update the host with appropriate tags to make it HA enabled - Key: CLOUDSTACK-8059 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8059 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 The test suite does not have the required code in setupClass() for the test cases to run properly. Required code includes: 1) Find the cluster with at least 3 Hosts 2) Make one of the hosts HA enabled. 3) Remove the host tags in the cleanup. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7974) deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241006#comment-14241006 ] Jayapal Reddy commented on CLOUDSTACK-7974: --- [~bhaisaab] We are using the following file, we are not using dnsmasq_edithosts.sh cloudstack/systemvm/patches/debian/config/opt/cloud/bin/edithosts.sh Currently I don't think there are impacts, If I come across I will let you know. deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router Key: CLOUDSTACK-7974 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7974 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.3.0 Reporter: Yiping Zhang Assignee: Rohit Yadav Fix For: 4.5.0, 4.6.0, 4.4.2, 4.4.3, 4.3.2 We have noticed that entries for hosts which have been destroyed for a long time still exist in both /etc/dhcphosts.txt and /etc/hosts files on our Virtual Routers. To reproduce this bug, just create an instance, note down its MAC and IP address, then destroy the instance from web UI. Now check virtual router, and you will find that the entries still exist in /etc/dhcphosts.txt and /etc/hosts files. I did a bit more digging on virtual router, and immediately noticed the following: 1. /root/edithosts.sh script is only called when an instance is created, but not when an instance is destroyed. 2. After reading /root/edithosts.sh script, I am pretty certain that the function of this script is to add info about newly created instances into /etc/hosts and /etc/dhcphosts.txt files. So the script should really be renamed as /root/addhosts.sh to reflect its true function. 3. there is no script to properly delete entries from /etc/hosts and /etc/dhcphosts.txt file when instances are destroyed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7974) deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241017#comment-14241017 ] Rohit Yadav commented on CLOUDSTACK-7974: - I just tested in both shared and isolated networks, the script is called only when a new VM is deployed and this makes sure we removed any old entry with the VM's hostname. There is no script that removes entries as we remove VMs at all. deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router Key: CLOUDSTACK-7974 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7974 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.3.0 Reporter: Yiping Zhang Assignee: Rohit Yadav Fix For: 4.5.0, 4.6.0, 4.4.2, 4.4.3, 4.3.2 We have noticed that entries for hosts which have been destroyed for a long time still exist in both /etc/dhcphosts.txt and /etc/hosts files on our Virtual Routers. To reproduce this bug, just create an instance, note down its MAC and IP address, then destroy the instance from web UI. Now check virtual router, and you will find that the entries still exist in /etc/dhcphosts.txt and /etc/hosts files. I did a bit more digging on virtual router, and immediately noticed the following: 1. /root/edithosts.sh script is only called when an instance is created, but not when an instance is destroyed. 2. After reading /root/edithosts.sh script, I am pretty certain that the function of this script is to add info about newly created instances into /etc/hosts and /etc/dhcphosts.txt files. So the script should really be renamed as /root/addhosts.sh to reflect its true function. 3. there is no script to properly delete entries from /etc/hosts and /etc/dhcphosts.txt file when instances are destroyed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (CLOUDSTACK-7974) deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav updated CLOUDSTACK-7974: Comment: was deleted (was: I just tested in both shared and isolated networks, the script is called only when a new VM is deployed and this makes sure we removed any old entry with the VM's hostname. There is no script that removes entries as we remove VMs at all.) deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router Key: CLOUDSTACK-7974 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7974 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.3.0 Reporter: Yiping Zhang Assignee: Rohit Yadav Fix For: 4.5.0, 4.6.0, 4.4.2, 4.4.3, 4.3.2 We have noticed that entries for hosts which have been destroyed for a long time still exist in both /etc/dhcphosts.txt and /etc/hosts files on our Virtual Routers. To reproduce this bug, just create an instance, note down its MAC and IP address, then destroy the instance from web UI. Now check virtual router, and you will find that the entries still exist in /etc/dhcphosts.txt and /etc/hosts files. I did a bit more digging on virtual router, and immediately noticed the following: 1. /root/edithosts.sh script is only called when an instance is created, but not when an instance is destroyed. 2. After reading /root/edithosts.sh script, I am pretty certain that the function of this script is to add info about newly created instances into /etc/hosts and /etc/dhcphosts.txt files. So the script should really be renamed as /root/addhosts.sh to reflect its true function. 3. there is no script to properly delete entries from /etc/hosts and /etc/dhcphosts.txt file when instances are destroyed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7974) deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241019#comment-14241019 ] Rohit Yadav commented on CLOUDSTACK-7974: - Now, the issue is we need to trigger a script when vms are deleted that would go and remove the entry from /etc/hosts and reload dnsmasq service. Any pointer how to do it since this affects several components? deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router Key: CLOUDSTACK-7974 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7974 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.3.0 Reporter: Yiping Zhang Assignee: Rohit Yadav Fix For: 4.5.0, 4.6.0, 4.4.2, 4.4.3, 4.3.2 We have noticed that entries for hosts which have been destroyed for a long time still exist in both /etc/dhcphosts.txt and /etc/hosts files on our Virtual Routers. To reproduce this bug, just create an instance, note down its MAC and IP address, then destroy the instance from web UI. Now check virtual router, and you will find that the entries still exist in /etc/dhcphosts.txt and /etc/hosts files. I did a bit more digging on virtual router, and immediately noticed the following: 1. /root/edithosts.sh script is only called when an instance is created, but not when an instance is destroyed. 2. After reading /root/edithosts.sh script, I am pretty certain that the function of this script is to add info about newly created instances into /etc/hosts and /etc/dhcphosts.txt files. So the script should really be renamed as /root/addhosts.sh to reflect its true function. 3. there is no script to properly delete entries from /etc/hosts and /etc/dhcphosts.txt file when instances are destroyed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-252) UpdateNetwork Operation on a guest network that is currently using Virtual Router for Lb services to a network offering that uses F5 for Lb services Fails due to My
[ https://issues.apache.org/jira/browse/CLOUDSTACK-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayapal Reddy updated CLOUDSTACK-252: - Assignee: Sudhansu Sahu (was: Jayapal Reddy) UpdateNetwork Operation on a guest network that is currently using Virtual Router for Lb services to a network offering that uses F5 for Lb services Fails due to MySQLIntegrityConstraintViolationException. --- Key: CLOUDSTACK-252 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-252 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: pre-4.0.0 Reporter: Chandan Purushothama Assignee: Sudhansu Sahu Fix For: 4.5.0, 4.4.3 Attachments: managementserverlog_mysqldumps.zip === Steps to Reproduce: === 1. On an Advanced Zone with two physical networks, create a guest network from a network offering with services as mentioned below mysql select * from network_offerings where id=13 \G *** 1. row *** id: 13 name: Network-SNAT-guest1 uuid: 277b7b7a-8aeb-46f8-94e9-e83de34912a8 unique_name: Network-SNAT-guest1 display_text: Network-SNAT-guest1 nw_rate: 500 mc_rate: 10 traffic_type: Guest tags: guest1 system_only: 0 specify_vlan: 0 service_offering_id: NULL conserve_mode: 0 created: 2012-09-26 18:43:35 removed: NULL default: 0 availability: Optional dedicated_lb_service: 1 shared_source_nat_service: 0 sort_key: 0 redundant_router_service: 0 state: Enabled guest_type: Isolated elastic_ip_service: 0 elastic_lb_service: 0 specify_ip_ranges: 0 1 row in set (0.00 sec) mysql select * from ntwk_offering_service_map where network_offering_id=13; ++-++---+-+ | id | network_offering_id | service| provider | created | ++-++---+-+ | 48 | 13 | Dhcp | VirtualRouter | 2012-09-26 18:43:35 | | 51 | 13 | Dns| VirtualRouter | 2012-09-26 18:43:35 | | 52 | 13 | Firewall | VirtualRouter | 2012-09-26 18:43:35 | | 49 | 13 | Lb | VirtualRouter | 2012-09-26 18:43:35 | | 50 | 13 | PortForwarding | VirtualRouter | 2012-09-26 18:43:35 | | 53 | 13 | SourceNat | VirtualRouter | 2012-09-26 18:43:35 | | 46 | 13 | StaticNat | VirtualRouter | 2012-09-26 18:43:35 | | 54 | 13 | UserData | VirtualRouter | 2012-09-26 18:43:35 | | 47 | 13 | Vpn| VirtualRouter | 2012-09-26 18:43:35 | ++-++---+-+ 9 rows in set (0.00 sec) mysql 2, Deploy three VMs on a guest network that is created from the above mentioned network offering. 3. Create a Load balancing rule servicing the VMs on the guest network. 4. Stop All the VMs and UpdateNetwork to the Network offering with services as mentioned below. Notice that the LB Service is provided by F5 in the new network offering. mysql select * from network_offerings where id=18 \G *** 1. row *** id: 18 name: Network-F5-guest1 uuid: 5c7746b8-e29f-4a74-8369-e88647081053 unique_name: Network-F5-guest1 display_text: Network-F5-guest1 nw_rate: 535 mc_rate: 10 traffic_type: Guest tags: guest1 system_only: 0 specify_vlan: 0 service_offering_id: NULL conserve_mode: 0 created: 2012-09-27 01:13:38 removed: NULL default: 0 availability: Optional dedicated_lb_service: 0 shared_source_nat_service: 0 sort_key: 0 redundant_router_service: 0 state: Enabled guest_type: Isolated elastic_ip_service:
[jira] [Commented] (CLOUDSTACK-7974) deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241025#comment-14241025 ] Jayapal Reddy commented on CLOUDSTACK-7974: --- 1. On VM deployment if we can remove the entry with VM name combination then no need to run script to while destroying VM. If we want to remove entry while deleting VM, I think we can check how user data is handled while deleting VM. Delete entry when VM entered to expunge state NOT destroyed state. deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router Key: CLOUDSTACK-7974 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7974 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.3.0 Reporter: Yiping Zhang Assignee: Rohit Yadav Fix For: 4.5.0, 4.6.0, 4.4.2, 4.4.3, 4.3.2 We have noticed that entries for hosts which have been destroyed for a long time still exist in both /etc/dhcphosts.txt and /etc/hosts files on our Virtual Routers. To reproduce this bug, just create an instance, note down its MAC and IP address, then destroy the instance from web UI. Now check virtual router, and you will find that the entries still exist in /etc/dhcphosts.txt and /etc/hosts files. I did a bit more digging on virtual router, and immediately noticed the following: 1. /root/edithosts.sh script is only called when an instance is created, but not when an instance is destroyed. 2. After reading /root/edithosts.sh script, I am pretty certain that the function of this script is to add info about newly created instances into /etc/hosts and /etc/dhcphosts.txt files. So the script should really be renamed as /root/addhosts.sh to reflect its true function. 3. there is no script to properly delete entries from /etc/hosts and /etc/dhcphosts.txt file when instances are destroyed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7974) deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241038#comment-14241038 ] ASF subversion and git services commented on CLOUDSTACK-7974: - Commit 63298d9b742811919717ffd6303c8a2e9d37a3dd in cloudstack's branch refs/heads/4.3 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=63298d9 ] CLOUDSTACK-7974: remove old hostname entry for a VM when adding a VM When adding a VM, it adds an entry to /etc/hosts file on the VR but does not clear up any older entries for the VM with a same name. The fix uncomments the command that removes any old entries in the VM. Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router Key: CLOUDSTACK-7974 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7974 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.3.0 Reporter: Yiping Zhang Assignee: Rohit Yadav Fix For: 4.5.0, 4.6.0, 4.4.2, 4.4.3, 4.3.2 We have noticed that entries for hosts which have been destroyed for a long time still exist in both /etc/dhcphosts.txt and /etc/hosts files on our Virtual Routers. To reproduce this bug, just create an instance, note down its MAC and IP address, then destroy the instance from web UI. Now check virtual router, and you will find that the entries still exist in /etc/dhcphosts.txt and /etc/hosts files. I did a bit more digging on virtual router, and immediately noticed the following: 1. /root/edithosts.sh script is only called when an instance is created, but not when an instance is destroyed. 2. After reading /root/edithosts.sh script, I am pretty certain that the function of this script is to add info about newly created instances into /etc/hosts and /etc/dhcphosts.txt files. So the script should really be renamed as /root/addhosts.sh to reflect its true function. 3. there is no script to properly delete entries from /etc/hosts and /etc/dhcphosts.txt file when instances are destroyed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7974) deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241040#comment-14241040 ] ASF subversion and git services commented on CLOUDSTACK-7974: - Commit 5bc2d06c400331c828edcc4de2ba4a773ad42cb5 in cloudstack's branch refs/heads/4.4 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5bc2d06 ] CLOUDSTACK-7974: remove old hostname entry for a VM when adding a VM When adding a VM, it adds an entry to /etc/hosts file on the VR but does not clear up any older entries for the VM with a same name. The fix uncomments the command that removes any old entries in the VM. Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com (cherry picked from commit 63298d9b742811919717ffd6303c8a2e9d37a3dd) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router Key: CLOUDSTACK-7974 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7974 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.3.0 Reporter: Yiping Zhang Assignee: Rohit Yadav Fix For: 4.5.0, 4.6.0, 4.4.2, 4.4.3, 4.3.2 We have noticed that entries for hosts which have been destroyed for a long time still exist in both /etc/dhcphosts.txt and /etc/hosts files on our Virtual Routers. To reproduce this bug, just create an instance, note down its MAC and IP address, then destroy the instance from web UI. Now check virtual router, and you will find that the entries still exist in /etc/dhcphosts.txt and /etc/hosts files. I did a bit more digging on virtual router, and immediately noticed the following: 1. /root/edithosts.sh script is only called when an instance is created, but not when an instance is destroyed. 2. After reading /root/edithosts.sh script, I am pretty certain that the function of this script is to add info about newly created instances into /etc/hosts and /etc/dhcphosts.txt files. So the script should really be renamed as /root/addhosts.sh to reflect its true function. 3. there is no script to properly delete entries from /etc/hosts and /etc/dhcphosts.txt file when instances are destroyed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7974) deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241041#comment-14241041 ] ASF subversion and git services commented on CLOUDSTACK-7974: - Commit f38c2f87b11f5a00730e386759c2d46c2eef93c1 in cloudstack's branch refs/heads/4.5 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f38c2f8 ] CLOUDSTACK-7974: remove old hostname entry for a VM when adding a VM When adding a VM, it adds an entry to /etc/hosts file on the VR but does not clear up any older entries for the VM with a same name. The fix uncomments the command that removes any old entries in the VM. Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com (cherry picked from commit 63298d9b742811919717ffd6303c8a2e9d37a3dd) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router Key: CLOUDSTACK-7974 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7974 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.3.0 Reporter: Yiping Zhang Assignee: Rohit Yadav Fix For: 4.5.0, 4.6.0, 4.4.2, 4.4.3, 4.3.2 We have noticed that entries for hosts which have been destroyed for a long time still exist in both /etc/dhcphosts.txt and /etc/hosts files on our Virtual Routers. To reproduce this bug, just create an instance, note down its MAC and IP address, then destroy the instance from web UI. Now check virtual router, and you will find that the entries still exist in /etc/dhcphosts.txt and /etc/hosts files. I did a bit more digging on virtual router, and immediately noticed the following: 1. /root/edithosts.sh script is only called when an instance is created, but not when an instance is destroyed. 2. After reading /root/edithosts.sh script, I am pretty certain that the function of this script is to add info about newly created instances into /etc/hosts and /etc/dhcphosts.txt files. So the script should really be renamed as /root/addhosts.sh to reflect its true function. 3. there is no script to properly delete entries from /etc/hosts and /etc/dhcphosts.txt file when instances are destroyed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8060) Delete VM host entry from VR when VM is destroyed
Rohit Yadav created CLOUDSTACK-8060: --- Summary: Delete VM host entry from VR when VM is destroyed Key: CLOUDSTACK-8060 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8060 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.4.1, 4.3.1, 4.4.0, 4.3.0, 4.4.2, 4.4.3, 4.3.2 Reporter: Rohit Yadav Assignee: Rohit Yadav Fix For: 4.5.0, 4.6.0 Referencing from https://issues.apache.org/jira/browse/CLOUDSTACK-7974 When VMs are destroyed their hosts entries are not removed in /etc/hosts and the dhcp leases need to be removed as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7974) deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241046#comment-14241046 ] ASF subversion and git services commented on CLOUDSTACK-7974: - Commit aae393dcd5bb5d96267ada1f6ed142b63a39f685 in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=aae393d ] CLOUDSTACK-7974: remove old hostname entry for a VM when adding a VM When adding a VM, it adds an entry to /etc/hosts file on the VR but does not clear up any older entries for the VM with a same name. The fix uncomments the command that removes any old entries in the VM. Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com (cherry picked from commit 63298d9b742811919717ffd6303c8a2e9d37a3dd) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router Key: CLOUDSTACK-7974 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7974 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.3.0 Reporter: Yiping Zhang Assignee: Rohit Yadav Fix For: 4.5.0, 4.6.0, 4.4.2, 4.4.3, 4.3.2 We have noticed that entries for hosts which have been destroyed for a long time still exist in both /etc/dhcphosts.txt and /etc/hosts files on our Virtual Routers. To reproduce this bug, just create an instance, note down its MAC and IP address, then destroy the instance from web UI. Now check virtual router, and you will find that the entries still exist in /etc/dhcphosts.txt and /etc/hosts files. I did a bit more digging on virtual router, and immediately noticed the following: 1. /root/edithosts.sh script is only called when an instance is created, but not when an instance is destroyed. 2. After reading /root/edithosts.sh script, I am pretty certain that the function of this script is to add info about newly created instances into /etc/hosts and /etc/dhcphosts.txt files. So the script should really be renamed as /root/addhosts.sh to reflect its true function. 3. there is no script to properly delete entries from /etc/hosts and /etc/dhcphosts.txt file when instances are destroyed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7974) deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav resolved CLOUDSTACK-7974. - Resolution: Fixed The main issue that old host entries for a VM with same hostname are removed when a new VM is added. CloudStack already makes sure that vm hostnames (case sensitive) are unique. deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router Key: CLOUDSTACK-7974 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7974 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.3.0 Reporter: Yiping Zhang Assignee: Rohit Yadav Fix For: 4.5.0, 4.6.0, 4.4.2, 4.4.3, 4.3.2 We have noticed that entries for hosts which have been destroyed for a long time still exist in both /etc/dhcphosts.txt and /etc/hosts files on our Virtual Routers. To reproduce this bug, just create an instance, note down its MAC and IP address, then destroy the instance from web UI. Now check virtual router, and you will find that the entries still exist in /etc/dhcphosts.txt and /etc/hosts files. I did a bit more digging on virtual router, and immediately noticed the following: 1. /root/edithosts.sh script is only called when an instance is created, but not when an instance is destroyed. 2. After reading /root/edithosts.sh script, I am pretty certain that the function of this script is to add info about newly created instances into /etc/hosts and /etc/dhcphosts.txt files. So the script should really be renamed as /root/addhosts.sh to reflect its true function. 3. there is no script to properly delete entries from /etc/hosts and /etc/dhcphosts.txt file when instances are destroyed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7974) deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241051#comment-14241051 ] Rohit Yadav commented on CLOUDSTACK-7974: - I've opened a new issue https://issues.apache.org/jira/browse/CLOUDSTACK-8060 that aims to add an improvement to delete entries when VM is destroyed. deleted VM entries still exists in /etc/hosts and /etc/dhcphosts.txt files on virtual router Key: CLOUDSTACK-7974 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7974 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.3.0 Reporter: Yiping Zhang Assignee: Rohit Yadav Fix For: 4.5.0, 4.6.0, 4.4.2, 4.4.3, 4.3.2 We have noticed that entries for hosts which have been destroyed for a long time still exist in both /etc/dhcphosts.txt and /etc/hosts files on our Virtual Routers. To reproduce this bug, just create an instance, note down its MAC and IP address, then destroy the instance from web UI. Now check virtual router, and you will find that the entries still exist in /etc/dhcphosts.txt and /etc/hosts files. I did a bit more digging on virtual router, and immediately noticed the following: 1. /root/edithosts.sh script is only called when an instance is created, but not when an instance is destroyed. 2. After reading /root/edithosts.sh script, I am pretty certain that the function of this script is to add info about newly created instances into /etc/hosts and /etc/dhcphosts.txt files. So the script should really be renamed as /root/addhosts.sh to reflect its true function. 3. there is no script to properly delete entries from /etc/hosts and /etc/dhcphosts.txt file when instances are destroyed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4139) [VMWARE]Failed to resize the volumes which are created from snapshot of root volume with controller type IDE.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241059#comment-14241059 ] Sateesh Chodapuneedi commented on CLOUDSTACK-4139: -- Moving this bug to 4.6 as this is not critical bug and 4.5 is in RC phase. Also as noted in previous comments this is a corner case and there exists work around (detach the volume, resize and attach again). [VMWARE]Failed to resize the volumes which are created from snapshot of root volume with controller type IDE. - Key: CLOUDSTACK-4139 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4139 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller, VMware Affects Versions: 4.2.0 Reporter: Sailaja Mada Assignee: Sateesh Chodapuneedi Fix For: 4.6.0, 4.4.3 Attachments: apilog.log, management-server.log, newdb.sql Steps: 1. Configure Adv zone with VMWARE cluster with Zone wide primary storage 2. Deploy instance 3. Create snapshot from ROOT volume 4. Attach the volume to an instance 5. Tried to resize the volume from 2 GB to 5 GB . Observation: 1. It Failed to resize the volumes which are created from snapshot . 2. Task notification says resize is completed from UI but it failed and no resize happened for this volume 3. I could resize the DATA volumes which are added by using the disk offering and attached to the instance. 2013-08-07 16:37:31,370 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-6:null) SeqA 3-785: Sending Seq 3-785: { Ans: , MgmtId: 187767034175903, via: 3, Ver: v1, Flags: 100010, [{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] } 2013-08-07 16:37:33,253 DEBUG [cloud.api.ApiServlet] (catalina-exec-21:null) ===START=== 10.144.6.19 -- GET command=resizeVolumeid=480c853c-e70a-46a0-a6d6-ae74b416f318shrinkok=falsediskofferingid=34443d4d-f29c-4d3f-8bb6-f6ae76e34b0dresponse=jsonsessionkey=nmiUJgTgEEYHRt8hx5StkuJr5tA%3D_=1375873540089 2013-08-07 16:37:33,296 DEBUG [cloud.async.AsyncJobManagerImpl] (catalina-exec-21:null) submit async job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ], details: AsyncJobVO {id:49, userId: 3, accountId: 3, sessionKey: null, instanceType: Volume, instanceId: null, cmd: org.apache.cloudstack.api.command.user.volume.ResizeVolumeCmd, cmdOriginator: null, cmdInfo: {id:480c853c-e70a-46a0-a6d6-ae74b416f318,response:json,sessionkey:nmiUJgTgEEYHRt8hx5StkuJr5tA\u003d,shrinkok:false,cmdEventType:VOLUME.RESIZE,ctxUserId:3,httpmethod:GET,_:1375873540089,ctxAccountId:3,diskofferingid:34443d4d-f29c-4d3f-8bb6-f6ae76e34b0d,ctxStartEventId:182}, cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, processStatus: 0, resultCode: 0, result: null, initMsid: 187767034175903, completeMsid: null, lastUpdated: null, lastPolled: null, created: null} 2013-08-07 16:37:33,301 DEBUG [cloud.api.ApiServlet] (catalina-exec-21:null) ===END=== 10.144.6.19 -- GET command=resizeVolumeid=480c853c-e70a-46a0-a6d6-ae74b416f318shrinkok=falsediskofferingid=34443d4d-f29c-4d3f-8bb6-f6ae76e34b0dresponse=jsonsessionkey=nmiUJgTgEEYHRt8hx5StkuJr5tA%3D_=1375873540089 2013-08-07 16:37:33,342 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-32:job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ]) Executing org.apache.cloudstack.api.command.user.volume.ResizeVolumeCmd for job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ] 2013-08-07 16:37:33,488 DEBUG [cloud.user.AccountManagerImpl] (Job-Executor-32:job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ]) Access to Vol[35|vm=16|DATADISK] granted to Acct[3-cdcuser1] by DomainChecker_EnhancerByCloudStack_ccb7a71 2013-08-07 16:37:33,534 DEBUG [agent.transport.Request] (Job-Executor-32:job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ]) Seq 2-1287389738: Sending { Cmd , MgmtId: 187767034175903, via: 2, Ver: v1, Flags: 100011, [{com.cloud.agent.api.storage.ResizeVolumeCommand:{path:e9166262ee514a398028c04bf21d80b7,pool:{id:2,uuid:004a6f4c-232c-3a09-9013-e47fe47da3fb,host:10.102.192.100,path:/cpg_vol/sailaja/finalps2,port:2049,type:NetworkFilesystem},vmInstance:i-3-16-VM,newSize:5368709120,currentSize:2147483648,shrinkOk:false,wait:0}}] } 2013-08-07 16:37:33,534 DEBUG [agent.transport.Request] (Job-Executor-32:job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ]) Seq 2-1287389738: Executing: { Cmd , MgmtId: 187767034175903, via: 2, Ver: v1, Flags: 100011,
[jira] [Updated] (CLOUDSTACK-4139) [VMWARE]Failed to resize the volumes which are created from snapshot of root volume with controller type IDE.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-4139: - Fix Version/s: (was: 4.5.0) 4.6.0 [VMWARE]Failed to resize the volumes which are created from snapshot of root volume with controller type IDE. - Key: CLOUDSTACK-4139 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4139 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller, VMware Affects Versions: 4.2.0 Reporter: Sailaja Mada Assignee: Sateesh Chodapuneedi Fix For: 4.6.0, 4.4.3 Attachments: apilog.log, management-server.log, newdb.sql Steps: 1. Configure Adv zone with VMWARE cluster with Zone wide primary storage 2. Deploy instance 3. Create snapshot from ROOT volume 4. Attach the volume to an instance 5. Tried to resize the volume from 2 GB to 5 GB . Observation: 1. It Failed to resize the volumes which are created from snapshot . 2. Task notification says resize is completed from UI but it failed and no resize happened for this volume 3. I could resize the DATA volumes which are added by using the disk offering and attached to the instance. 2013-08-07 16:37:31,370 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-6:null) SeqA 3-785: Sending Seq 3-785: { Ans: , MgmtId: 187767034175903, via: 3, Ver: v1, Flags: 100010, [{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] } 2013-08-07 16:37:33,253 DEBUG [cloud.api.ApiServlet] (catalina-exec-21:null) ===START=== 10.144.6.19 -- GET command=resizeVolumeid=480c853c-e70a-46a0-a6d6-ae74b416f318shrinkok=falsediskofferingid=34443d4d-f29c-4d3f-8bb6-f6ae76e34b0dresponse=jsonsessionkey=nmiUJgTgEEYHRt8hx5StkuJr5tA%3D_=1375873540089 2013-08-07 16:37:33,296 DEBUG [cloud.async.AsyncJobManagerImpl] (catalina-exec-21:null) submit async job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ], details: AsyncJobVO {id:49, userId: 3, accountId: 3, sessionKey: null, instanceType: Volume, instanceId: null, cmd: org.apache.cloudstack.api.command.user.volume.ResizeVolumeCmd, cmdOriginator: null, cmdInfo: {id:480c853c-e70a-46a0-a6d6-ae74b416f318,response:json,sessionkey:nmiUJgTgEEYHRt8hx5StkuJr5tA\u003d,shrinkok:false,cmdEventType:VOLUME.RESIZE,ctxUserId:3,httpmethod:GET,_:1375873540089,ctxAccountId:3,diskofferingid:34443d4d-f29c-4d3f-8bb6-f6ae76e34b0d,ctxStartEventId:182}, cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, processStatus: 0, resultCode: 0, result: null, initMsid: 187767034175903, completeMsid: null, lastUpdated: null, lastPolled: null, created: null} 2013-08-07 16:37:33,301 DEBUG [cloud.api.ApiServlet] (catalina-exec-21:null) ===END=== 10.144.6.19 -- GET command=resizeVolumeid=480c853c-e70a-46a0-a6d6-ae74b416f318shrinkok=falsediskofferingid=34443d4d-f29c-4d3f-8bb6-f6ae76e34b0dresponse=jsonsessionkey=nmiUJgTgEEYHRt8hx5StkuJr5tA%3D_=1375873540089 2013-08-07 16:37:33,342 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-32:job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ]) Executing org.apache.cloudstack.api.command.user.volume.ResizeVolumeCmd for job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ] 2013-08-07 16:37:33,488 DEBUG [cloud.user.AccountManagerImpl] (Job-Executor-32:job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ]) Access to Vol[35|vm=16|DATADISK] granted to Acct[3-cdcuser1] by DomainChecker_EnhancerByCloudStack_ccb7a71 2013-08-07 16:37:33,534 DEBUG [agent.transport.Request] (Job-Executor-32:job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ]) Seq 2-1287389738: Sending { Cmd , MgmtId: 187767034175903, via: 2, Ver: v1, Flags: 100011, [{com.cloud.agent.api.storage.ResizeVolumeCommand:{path:e9166262ee514a398028c04bf21d80b7,pool:{id:2,uuid:004a6f4c-232c-3a09-9013-e47fe47da3fb,host:10.102.192.100,path:/cpg_vol/sailaja/finalps2,port:2049,type:NetworkFilesystem},vmInstance:i-3-16-VM,newSize:5368709120,currentSize:2147483648,shrinkOk:false,wait:0}}] } 2013-08-07 16:37:33,534 DEBUG [agent.transport.Request] (Job-Executor-32:job-49 = [ 40ec270a-a5ff-450d-9c5d-9ee3bfb87b98 ]) Seq 2-1287389738: Executing: { Cmd , MgmtId: 187767034175903, via: 2, Ver: v1, Flags: 100011, [{com.cloud.agent.api.storage.ResizeVolumeCommand:{path:e9166262ee514a398028c04bf21d80b7,pool:{id:2,uuid:004a6f4c-232c-3a09-9013-e47fe47da3fb,host:10.102.192.100,path:/cpg_vol/sailaja/finalps2,port:2049,type:NetworkFilesystem},vmInstance:i-3-16-VM,newSize:5368709120,currentSize:2147483648,shrinkOk:false,wait:0}}] } 2013-08-07 16:37:33,557 DEBUG [agent.manager.DirectAgentAttache]
[jira] [Commented] (CLOUDSTACK-8057) test_dedicate_guest_vlan_ranges.TestDeleteVlanRange.test_04_dedicate_guest_vlan_in_project - Mark test as invalid
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241069#comment-14241069 ] ASF subversion and git services commented on CLOUDSTACK-8057: - Commit ec478c49a69ce7db9dc6598d8c05973d2def67bf in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ec478c4 ] CLOUDSTACK-8057: test_dedicate_guest_vlan_range.py - Marking a test as invalid Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org test_dedicate_guest_vlan_ranges.TestDeleteVlanRange.test_04_dedicate_guest_vlan_in_project - Mark test as invalid - Key: CLOUDSTACK-8057 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8057 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 The test case dedicates the vlan range to account but creates guest network in project, and then checks if the vlan of the network is from dedicated range. This is an invalid scenario. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8059) test_host_high_availability.py - Add necessary code to check the hosts in cluster and update the host with appropriate tags to make it HA enabled
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241068#comment-14241068 ] ASF subversion and git services commented on CLOUDSTACK-8059: - Commit 345a2f8cddf91459790bfb4bf9a33df80ae59bbc in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=345a2f8 ] CLOUDSTACK-8059: test_host_high_availability.py - Adding necessary code to check the hosts in cluster and update the host with appropriate tags to make it HA enabled Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org test_host_high_availability.py - Add necessary code to check the hosts in cluster and update the host with appropriate tags to make it HA enabled - Key: CLOUDSTACK-8059 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8059 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 The test suite does not have the required code in setupClass() for the test cases to run properly. Required code includes: 1) Find the cluster with at least 3 Hosts 2) Make one of the hosts HA enabled. 3) Remove the host tags in the cleanup. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8059) test_host_high_availability.py - Add necessary code to check the hosts in cluster and update the host with appropriate tags to make it HA enabled
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241071#comment-14241071 ] ASF subversion and git services commented on CLOUDSTACK-8059: - Commit 40f26142b38bda5b10b01b2a2aad77d1b0b5f36e in cloudstack's branch refs/heads/4.5 from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=40f2614 ] CLOUDSTACK-8059: test_host_high_availability.py - Adding necessary code to check the hosts in cluster and update the host with appropriate tags to make it HA enabled Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org test_host_high_availability.py - Add necessary code to check the hosts in cluster and update the host with appropriate tags to make it HA enabled - Key: CLOUDSTACK-8059 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8059 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 The test suite does not have the required code in setupClass() for the test cases to run properly. Required code includes: 1) Find the cluster with at least 3 Hosts 2) Make one of the hosts HA enabled. 3) Remove the host tags in the cleanup. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8057) test_dedicate_guest_vlan_ranges.TestDeleteVlanRange.test_04_dedicate_guest_vlan_in_project - Mark test as invalid
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241070#comment-14241070 ] ASF subversion and git services commented on CLOUDSTACK-8057: - Commit 75f920185308307fe4b3abf1b60b071346656ab7 in cloudstack's branch refs/heads/4.5 from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=75f9201 ] CLOUDSTACK-8057: test_dedicate_guest_vlan_range.py - Marking a test as invalid Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org test_dedicate_guest_vlan_ranges.TestDeleteVlanRange.test_04_dedicate_guest_vlan_in_project - Mark test as invalid - Key: CLOUDSTACK-8057 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8057 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 The test case dedicates the vlan range to account but creates guest network in project, and then checks if the vlan of the network is from dedicated range. This is an invalid scenario. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8014) Failed to create a volume from snapshot - Discrepency in the resource count ?
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241085#comment-14241085 ] Rohit Yadav commented on CLOUDSTACK-8014: - France, can you try the same (create a template from a VM's volume's snapshot) with any other VM and see if you still get NullPointerException? I was able to reproduce the issue by simulating removal of the template (updating removed=NOW()) and got NPE. About the discrepency in resource count I don't know how to reproduce it. Since this issue is regarding NPE and failing to create volume from snapshot who's volume template is removed, for the other issue please open a new issue. Failed to create a volume from snapshot - Discrepency in the resource count ? - Key: CLOUDSTACK-8014 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8014 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.1 Reporter: France As sent to mailing list: Hi all. We are on XS 6.0.2+Hotfixes and CS 4.3.1. (All errors we are getting nowadays have come up only after upgrade from 4.1.1, 4.1.1 worked perfectly.) After successfully creating s snapshot, I want to create a volume from it, so it can be downloaded offsite. After clicking “Create volume” I get an error Failed to create a volume. If i got to list of volumes, there is a volume with name as defined, but Status is empty, and only buttons for attach and destroy exist. I have taken a look at catalina.out and management-server.log. Here is the log detailing a failure. Can you see the problem? How should I fix it? Please advise me. Should I create a bug report? I have also manually checked space on all storages and it seems there is LOTS of free space. Resources based on CS Web GUI are: Primary Storage Allocated 15% Secondary Storage 5% 2014-12-03 12:20:42,493 DEBUG [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-2d51baa2) Zone 1 is ready to launch console proxy 2014-12-03 12:20:42,580 DEBUG [c.c.s.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-53354d18) Zone 1 is ready to launch secondary storage VM 2014-12-03 12:20:42,894 DEBUG [c.c.a.ApiServlet] (http-6443-exec-108:ctx-a228ce49) ===START=== 111.client.ip.111 -- GET command=listZonesavailable=trueresponse=jsonsessionkey=CENSORED%3D_=1417605814964 2014-12-03 12:20:42,909 DEBUG [c.c.a.ApiServlet] (http-6443-exec-108:ctx-a228ce49 ctx-74e696ca) ===END=== 111.client.ip.111 -- GET command=listZonesavailable=trueresponse=jsonsessionkey=CENSORED%3D_=1417605814964 2014-12-03 12:20:46,482 DEBUG [c.c.a.ApiServlet] (http-6443-exec-107:ctx-4a28e57c) ===START=== 111.client.ip.111 -- GET command=createVolumeresponse=jsonsessionkey=CENSORED%3Dsnapshotid=49e4bba9-844d-4b7b-aca2-95a318f17dc4name=testbrisi567_=1417605818552 2014-12-03 12:20:46,490 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,494 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,507 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to com.cloud.storage.SnapshotVO$$EnhancerByCGLIB$$3490cea0@60c95391 granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,571 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-166:ctx-d915e890) Add job-2804 into job monitoring 2014-12-03 12:20:46,571 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (Job-Executor-166:ctx-d915e890) Executing AsyncJobVO {id:2804, userId: 59, accountId: 60, instanceType: Volume, instanceId: 617, cmd: org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd, cmdInfo: {id:617,response:json,sessionkey:CENSORED\u003d,cmdEventType:VOLUME.CREATE,ctxUserId:59,snapshotid:49e4bba9-844d-4b7b-aca2-95a318f17dc4,name:testbrisi567,httpmethod:GET,_:1417605818552,ctxAccountId:60,ctxStartEventId:62488}, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: null, initMsid: 95545481387, completeMsid: null, lastUpdated: null, lastPolled: null, created: null} 2014-12-03 12:20:46,577 DEBUG [c.c.u.AccountManagerImpl] (Job-Executor-166:ctx-d915e890 ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,578
[jira] [Commented] (CLOUDSTACK-8014) Failed to create a volume from snapshot - Discrepency in the resource count ?
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241090#comment-14241090 ] Abhinandan Prateek commented on CLOUDSTACK-8014: If you try to delete the template twice, (maybe due to some race condition it pops up in the UI while it is being deleted), then you get the resource count issue: .. INFO [c.c.t.HypervisorTemplateAdapter] (Job-Executor-5:ctx-07a5e482 ctx-e4966196) Delete template from image store: secone INFO [c.c.t.HypervisorTemplateAdapter] (Job-Executor-5:ctx-07a5e482 ctx-e4966196) Delete template from image store: sectwo .. INFO [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-6:ctx-fdf72fb9) Add job-189 into job monitoring INFO [c.c.t.HypervisorTemplateAdapter] (Job-Executor-6:ctx-fdf72fb9 ctx-1e235c0f) Unable to find image store still having template: centos, so just mark the template removed INFO [c.c.r.ResourceLimitManagerImpl] (Job-Executor-6:ctx-fdf72fb9 ctx-1e235c0f) Discrepency in the resource count (original count=46513518080 correct count = 3563845120) for type secondary_storage for account ID 2 is fixed during resource count recalculation. INFO [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-6:ctx-fdf72fb9) Remove job-189 from job monitoring ... This is just a info message and not a bug. Failed to create a volume from snapshot - Discrepency in the resource count ? - Key: CLOUDSTACK-8014 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8014 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.1 Reporter: France As sent to mailing list: Hi all. We are on XS 6.0.2+Hotfixes and CS 4.3.1. (All errors we are getting nowadays have come up only after upgrade from 4.1.1, 4.1.1 worked perfectly.) After successfully creating s snapshot, I want to create a volume from it, so it can be downloaded offsite. After clicking “Create volume” I get an error Failed to create a volume. If i got to list of volumes, there is a volume with name as defined, but Status is empty, and only buttons for attach and destroy exist. I have taken a look at catalina.out and management-server.log. Here is the log detailing a failure. Can you see the problem? How should I fix it? Please advise me. Should I create a bug report? I have also manually checked space on all storages and it seems there is LOTS of free space. Resources based on CS Web GUI are: Primary Storage Allocated 15% Secondary Storage 5% 2014-12-03 12:20:42,493 DEBUG [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-2d51baa2) Zone 1 is ready to launch console proxy 2014-12-03 12:20:42,580 DEBUG [c.c.s.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-53354d18) Zone 1 is ready to launch secondary storage VM 2014-12-03 12:20:42,894 DEBUG [c.c.a.ApiServlet] (http-6443-exec-108:ctx-a228ce49) ===START=== 111.client.ip.111 -- GET command=listZonesavailable=trueresponse=jsonsessionkey=CENSORED%3D_=1417605814964 2014-12-03 12:20:42,909 DEBUG [c.c.a.ApiServlet] (http-6443-exec-108:ctx-a228ce49 ctx-74e696ca) ===END=== 111.client.ip.111 -- GET command=listZonesavailable=trueresponse=jsonsessionkey=CENSORED%3D_=1417605814964 2014-12-03 12:20:46,482 DEBUG [c.c.a.ApiServlet] (http-6443-exec-107:ctx-4a28e57c) ===START=== 111.client.ip.111 -- GET command=createVolumeresponse=jsonsessionkey=CENSORED%3Dsnapshotid=49e4bba9-844d-4b7b-aca2-95a318f17dc4name=testbrisi567_=1417605818552 2014-12-03 12:20:46,490 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,494 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,507 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to com.cloud.storage.SnapshotVO$$EnhancerByCGLIB$$3490cea0@60c95391 granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,571 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-166:ctx-d915e890) Add job-2804 into job monitoring 2014-12-03 12:20:46,571 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (Job-Executor-166:ctx-d915e890) Executing AsyncJobVO {id:2804, userId: 59, accountId: 60, instanceType: Volume, instanceId: 617, cmd: org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd, cmdInfo:
[jira] [Commented] (CLOUDSTACK-8014) Failed to create a volume from snapshot - Discrepency in the resource count ?
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241094#comment-14241094 ] France commented on CLOUDSTACK-8014: Tnx Rohit for your efforts. I will read your responses with great cate and try to do what you ask of me, then report back on the jira. This is just a private mail to you, so you know I am working on it, the problem is that i have to deal with the customers concurrently on completely different field. :-/ Regards, F. Failed to create a volume from snapshot - Discrepency in the resource count ? - Key: CLOUDSTACK-8014 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8014 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.1 Reporter: France As sent to mailing list: Hi all. We are on XS 6.0.2+Hotfixes and CS 4.3.1. (All errors we are getting nowadays have come up only after upgrade from 4.1.1, 4.1.1 worked perfectly.) After successfully creating s snapshot, I want to create a volume from it, so it can be downloaded offsite. After clicking “Create volume” I get an error Failed to create a volume. If i got to list of volumes, there is a volume with name as defined, but Status is empty, and only buttons for attach and destroy exist. I have taken a look at catalina.out and management-server.log. Here is the log detailing a failure. Can you see the problem? How should I fix it? Please advise me. Should I create a bug report? I have also manually checked space on all storages and it seems there is LOTS of free space. Resources based on CS Web GUI are: Primary Storage Allocated 15% Secondary Storage 5% 2014-12-03 12:20:42,493 DEBUG [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-2d51baa2) Zone 1 is ready to launch console proxy 2014-12-03 12:20:42,580 DEBUG [c.c.s.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-53354d18) Zone 1 is ready to launch secondary storage VM 2014-12-03 12:20:42,894 DEBUG [c.c.a.ApiServlet] (http-6443-exec-108:ctx-a228ce49) ===START=== 111.client.ip.111 -- GET command=listZonesavailable=trueresponse=jsonsessionkey=CENSORED%3D_=1417605814964 2014-12-03 12:20:42,909 DEBUG [c.c.a.ApiServlet] (http-6443-exec-108:ctx-a228ce49 ctx-74e696ca) ===END=== 111.client.ip.111 -- GET command=listZonesavailable=trueresponse=jsonsessionkey=CENSORED%3D_=1417605814964 2014-12-03 12:20:46,482 DEBUG [c.c.a.ApiServlet] (http-6443-exec-107:ctx-4a28e57c) ===START=== 111.client.ip.111 -- GET command=createVolumeresponse=jsonsessionkey=CENSORED%3Dsnapshotid=49e4bba9-844d-4b7b-aca2-95a318f17dc4name=testbrisi567_=1417605818552 2014-12-03 12:20:46,490 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,494 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,507 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to com.cloud.storage.SnapshotVO$$EnhancerByCGLIB$$3490cea0@60c95391 granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,571 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-166:ctx-d915e890) Add job-2804 into job monitoring 2014-12-03 12:20:46,571 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (Job-Executor-166:ctx-d915e890) Executing AsyncJobVO {id:2804, userId: 59, accountId: 60, instanceType: Volume, instanceId: 617, cmd: org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd, cmdInfo: {id:617,response:json,sessionkey:CENSORED\u003d,cmdEventType:VOLUME.CREATE,ctxUserId:59,snapshotid:49e4bba9-844d-4b7b-aca2-95a318f17dc4,name:testbrisi567,httpmethod:GET,_:1417605818552,ctxAccountId:60,ctxStartEventId:62488}, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: null, initMsid: 95545481387, completeMsid: null, lastUpdated: null, lastPolled: null, created: null} 2014-12-03 12:20:46,577 DEBUG [c.c.u.AccountManagerImpl] (Job-Executor-166:ctx-d915e890 ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,578 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) submit async job-2804, details: AsyncJobVO {id:2804, userId: 59, accountId: 60,
[jira] [Commented] (CLOUDSTACK-8014) Failed to create a volume from snapshot - Discrepency in the resource count ?
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241099#comment-14241099 ] ASF subversion and git services commented on CLOUDSTACK-8014: - Commit f189c105d8dde5491697b171b969e757f8f15858 in cloudstack's branch refs/heads/4.3 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f189c10 ] CLOUDSTACK-8014: Fix NPE searching including removed templates Steps to reproduce if you have this issue: - Create a VM's volume snapshot - Remove VM's template and mark the template as removed with timestamp in DB - Restart mgmt server and create a volume out of snapshot you should get NPE Fix: In `storagePoolHasEnoughSpace`, we're only searching for a VM's volume's snapshot's template by Id and not including removed templates. This is a corner case and NPE hits when template has been marked removed for a VM's volume's template so we should search including removed templates. Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Failed to create a volume from snapshot - Discrepency in the resource count ? - Key: CLOUDSTACK-8014 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8014 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.1 Reporter: France As sent to mailing list: Hi all. We are on XS 6.0.2+Hotfixes and CS 4.3.1. (All errors we are getting nowadays have come up only after upgrade from 4.1.1, 4.1.1 worked perfectly.) After successfully creating s snapshot, I want to create a volume from it, so it can be downloaded offsite. After clicking “Create volume” I get an error Failed to create a volume. If i got to list of volumes, there is a volume with name as defined, but Status is empty, and only buttons for attach and destroy exist. I have taken a look at catalina.out and management-server.log. Here is the log detailing a failure. Can you see the problem? How should I fix it? Please advise me. Should I create a bug report? I have also manually checked space on all storages and it seems there is LOTS of free space. Resources based on CS Web GUI are: Primary Storage Allocated 15% Secondary Storage 5% 2014-12-03 12:20:42,493 DEBUG [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-2d51baa2) Zone 1 is ready to launch console proxy 2014-12-03 12:20:42,580 DEBUG [c.c.s.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-53354d18) Zone 1 is ready to launch secondary storage VM 2014-12-03 12:20:42,894 DEBUG [c.c.a.ApiServlet] (http-6443-exec-108:ctx-a228ce49) ===START=== 111.client.ip.111 -- GET command=listZonesavailable=trueresponse=jsonsessionkey=CENSORED%3D_=1417605814964 2014-12-03 12:20:42,909 DEBUG [c.c.a.ApiServlet] (http-6443-exec-108:ctx-a228ce49 ctx-74e696ca) ===END=== 111.client.ip.111 -- GET command=listZonesavailable=trueresponse=jsonsessionkey=CENSORED%3D_=1417605814964 2014-12-03 12:20:46,482 DEBUG [c.c.a.ApiServlet] (http-6443-exec-107:ctx-4a28e57c) ===START=== 111.client.ip.111 -- GET command=createVolumeresponse=jsonsessionkey=CENSORED%3Dsnapshotid=49e4bba9-844d-4b7b-aca2-95a318f17dc4name=testbrisi567_=1417605818552 2014-12-03 12:20:46,490 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,494 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,507 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to com.cloud.storage.SnapshotVO$$EnhancerByCGLIB$$3490cea0@60c95391 granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,571 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-166:ctx-d915e890) Add job-2804 into job monitoring 2014-12-03 12:20:46,571 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (Job-Executor-166:ctx-d915e890) Executing AsyncJobVO {id:2804, userId: 59, accountId: 60, instanceType: Volume, instanceId: 617, cmd: org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd, cmdInfo: {id:617,response:json,sessionkey:CENSORED\u003d,cmdEventType:VOLUME.CREATE,ctxUserId:59,snapshotid:49e4bba9-844d-4b7b-aca2-95a318f17dc4,name:testbrisi567,httpmethod:GET,_:1417605818552,ctxAccountId:60,ctxStartEventId:62488}, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
[jira] [Commented] (CLOUDSTACK-8014) Failed to create a volume from snapshot - Discrepency in the resource count ?
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241100#comment-14241100 ] ASF subversion and git services commented on CLOUDSTACK-8014: - Commit 3b286d77ca2084fdde8176e2fd3e27a2c7227ea1 in cloudstack's branch refs/heads/4.4 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3b286d7 ] CLOUDSTACK-8014: Fix NPE searching including removed templates Steps to reproduce if you have this issue: - Create a VM's volume snapshot - Remove VM's template and mark the template as removed with timestamp in DB - Restart mgmt server and create a volume out of snapshot you should get NPE Fix: In `storagePoolHasEnoughSpace`, we're only searching for a VM's volume's snapshot's template by Id and not including removed templates. This is a corner case and NPE hits when template has been marked removed for a VM's volume's template so we should search including removed templates. Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com (cherry picked from commit f189c105d8dde5491697b171b969e757f8f15858) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Failed to create a volume from snapshot - Discrepency in the resource count ? - Key: CLOUDSTACK-8014 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8014 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.1 Reporter: France As sent to mailing list: Hi all. We are on XS 6.0.2+Hotfixes and CS 4.3.1. (All errors we are getting nowadays have come up only after upgrade from 4.1.1, 4.1.1 worked perfectly.) After successfully creating s snapshot, I want to create a volume from it, so it can be downloaded offsite. After clicking “Create volume” I get an error Failed to create a volume. If i got to list of volumes, there is a volume with name as defined, but Status is empty, and only buttons for attach and destroy exist. I have taken a look at catalina.out and management-server.log. Here is the log detailing a failure. Can you see the problem? How should I fix it? Please advise me. Should I create a bug report? I have also manually checked space on all storages and it seems there is LOTS of free space. Resources based on CS Web GUI are: Primary Storage Allocated 15% Secondary Storage 5% 2014-12-03 12:20:42,493 DEBUG [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-2d51baa2) Zone 1 is ready to launch console proxy 2014-12-03 12:20:42,580 DEBUG [c.c.s.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-53354d18) Zone 1 is ready to launch secondary storage VM 2014-12-03 12:20:42,894 DEBUG [c.c.a.ApiServlet] (http-6443-exec-108:ctx-a228ce49) ===START=== 111.client.ip.111 -- GET command=listZonesavailable=trueresponse=jsonsessionkey=CENSORED%3D_=1417605814964 2014-12-03 12:20:42,909 DEBUG [c.c.a.ApiServlet] (http-6443-exec-108:ctx-a228ce49 ctx-74e696ca) ===END=== 111.client.ip.111 -- GET command=listZonesavailable=trueresponse=jsonsessionkey=CENSORED%3D_=1417605814964 2014-12-03 12:20:46,482 DEBUG [c.c.a.ApiServlet] (http-6443-exec-107:ctx-4a28e57c) ===START=== 111.client.ip.111 -- GET command=createVolumeresponse=jsonsessionkey=CENSORED%3Dsnapshotid=49e4bba9-844d-4b7b-aca2-95a318f17dc4name=testbrisi567_=1417605818552 2014-12-03 12:20:46,490 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,494 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,507 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to com.cloud.storage.SnapshotVO$$EnhancerByCGLIB$$3490cea0@60c95391 granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,571 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-166:ctx-d915e890) Add job-2804 into job monitoring 2014-12-03 12:20:46,571 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (Job-Executor-166:ctx-d915e890) Executing AsyncJobVO {id:2804, userId: 59, accountId: 60, instanceType: Volume, instanceId: 617, cmd: org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd, cmdInfo:
[jira] [Commented] (CLOUDSTACK-8014) Failed to create a volume from snapshot - Discrepency in the resource count ?
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241104#comment-14241104 ] ASF subversion and git services commented on CLOUDSTACK-8014: - Commit e59dac201dc66ac80728632d7218b9a787142243 in cloudstack's branch refs/heads/4.5 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e59dac2 ] CLOUDSTACK-8014: Fix NPE searching including removed templates Steps to reproduce if you have this issue: - Create a VM's volume snapshot - Remove VM's template and mark the template as removed with timestamp in DB - Restart mgmt server and create a volume out of snapshot you should get NPE Fix: In `storagePoolHasEnoughSpace`, we're only searching for a VM's volume's snapshot's template by Id and not including removed templates. This is a corner case and NPE hits when template has been marked removed for a VM's volume's template so we should search including removed templates. Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com (cherry picked from commit f189c105d8dde5491697b171b969e757f8f15858) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Failed to create a volume from snapshot - Discrepency in the resource count ? - Key: CLOUDSTACK-8014 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8014 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.1 Reporter: France As sent to mailing list: Hi all. We are on XS 6.0.2+Hotfixes and CS 4.3.1. (All errors we are getting nowadays have come up only after upgrade from 4.1.1, 4.1.1 worked perfectly.) After successfully creating s snapshot, I want to create a volume from it, so it can be downloaded offsite. After clicking “Create volume” I get an error Failed to create a volume. If i got to list of volumes, there is a volume with name as defined, but Status is empty, and only buttons for attach and destroy exist. I have taken a look at catalina.out and management-server.log. Here is the log detailing a failure. Can you see the problem? How should I fix it? Please advise me. Should I create a bug report? I have also manually checked space on all storages and it seems there is LOTS of free space. Resources based on CS Web GUI are: Primary Storage Allocated 15% Secondary Storage 5% 2014-12-03 12:20:42,493 DEBUG [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-2d51baa2) Zone 1 is ready to launch console proxy 2014-12-03 12:20:42,580 DEBUG [c.c.s.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-53354d18) Zone 1 is ready to launch secondary storage VM 2014-12-03 12:20:42,894 DEBUG [c.c.a.ApiServlet] (http-6443-exec-108:ctx-a228ce49) ===START=== 111.client.ip.111 -- GET command=listZonesavailable=trueresponse=jsonsessionkey=CENSORED%3D_=1417605814964 2014-12-03 12:20:42,909 DEBUG [c.c.a.ApiServlet] (http-6443-exec-108:ctx-a228ce49 ctx-74e696ca) ===END=== 111.client.ip.111 -- GET command=listZonesavailable=trueresponse=jsonsessionkey=CENSORED%3D_=1417605814964 2014-12-03 12:20:46,482 DEBUG [c.c.a.ApiServlet] (http-6443-exec-107:ctx-4a28e57c) ===START=== 111.client.ip.111 -- GET command=createVolumeresponse=jsonsessionkey=CENSORED%3Dsnapshotid=49e4bba9-844d-4b7b-aca2-95a318f17dc4name=testbrisi567_=1417605818552 2014-12-03 12:20:46,490 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,494 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,507 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to com.cloud.storage.SnapshotVO$$EnhancerByCGLIB$$3490cea0@60c95391 granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,571 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-166:ctx-d915e890) Add job-2804 into job monitoring 2014-12-03 12:20:46,571 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (Job-Executor-166:ctx-d915e890) Executing AsyncJobVO {id:2804, userId: 59, accountId: 60, instanceType: Volume, instanceId: 617, cmd: org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd, cmdInfo:
[jira] [Commented] (CLOUDSTACK-8014) Failed to create a volume from snapshot - Discrepency in the resource count ?
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241106#comment-14241106 ] ASF subversion and git services commented on CLOUDSTACK-8014: - Commit fdb782ffcbd612cc1b44f827087267eb43e8687a in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fdb782f ] CLOUDSTACK-8014: Fix NPE searching including removed templates Steps to reproduce if you have this issue: - Create a VM's volume snapshot - Remove VM's template and mark the template as removed with timestamp in DB - Restart mgmt server and create a volume out of snapshot you should get NPE Fix: In `storagePoolHasEnoughSpace`, we're only searching for a VM's volume's snapshot's template by Id and not including removed templates. This is a corner case and NPE hits when template has been marked removed for a VM's volume's template so we should search including removed templates. Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com (cherry picked from commit f189c105d8dde5491697b171b969e757f8f15858) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Failed to create a volume from snapshot - Discrepency in the resource count ? - Key: CLOUDSTACK-8014 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8014 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.1 Reporter: France As sent to mailing list: Hi all. We are on XS 6.0.2+Hotfixes and CS 4.3.1. (All errors we are getting nowadays have come up only after upgrade from 4.1.1, 4.1.1 worked perfectly.) After successfully creating s snapshot, I want to create a volume from it, so it can be downloaded offsite. After clicking “Create volume” I get an error Failed to create a volume. If i got to list of volumes, there is a volume with name as defined, but Status is empty, and only buttons for attach and destroy exist. I have taken a look at catalina.out and management-server.log. Here is the log detailing a failure. Can you see the problem? How should I fix it? Please advise me. Should I create a bug report? I have also manually checked space on all storages and it seems there is LOTS of free space. Resources based on CS Web GUI are: Primary Storage Allocated 15% Secondary Storage 5% 2014-12-03 12:20:42,493 DEBUG [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-2d51baa2) Zone 1 is ready to launch console proxy 2014-12-03 12:20:42,580 DEBUG [c.c.s.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-53354d18) Zone 1 is ready to launch secondary storage VM 2014-12-03 12:20:42,894 DEBUG [c.c.a.ApiServlet] (http-6443-exec-108:ctx-a228ce49) ===START=== 111.client.ip.111 -- GET command=listZonesavailable=trueresponse=jsonsessionkey=CENSORED%3D_=1417605814964 2014-12-03 12:20:42,909 DEBUG [c.c.a.ApiServlet] (http-6443-exec-108:ctx-a228ce49 ctx-74e696ca) ===END=== 111.client.ip.111 -- GET command=listZonesavailable=trueresponse=jsonsessionkey=CENSORED%3D_=1417605814964 2014-12-03 12:20:46,482 DEBUG [c.c.a.ApiServlet] (http-6443-exec-107:ctx-4a28e57c) ===START=== 111.client.ip.111 -- GET command=createVolumeresponse=jsonsessionkey=CENSORED%3Dsnapshotid=49e4bba9-844d-4b7b-aca2-95a318f17dc4name=testbrisi567_=1417605818552 2014-12-03 12:20:46,490 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,494 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,507 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to com.cloud.storage.SnapshotVO$$EnhancerByCGLIB$$3490cea0@60c95391 granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,571 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-166:ctx-d915e890) Add job-2804 into job monitoring 2014-12-03 12:20:46,571 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (Job-Executor-166:ctx-d915e890) Executing AsyncJobVO {id:2804, userId: 59, accountId: 60, instanceType: Volume, instanceId: 617, cmd: org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd, cmdInfo:
[jira] [Resolved] (CLOUDSTACK-8014) Failed to create a volume from snapshot - Discrepency in the resource count ?
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav resolved CLOUDSTACK-8014. - Resolution: Fixed Assignee: Rohit Yadav Fixed NPE. Failed to create a volume from snapshot - Discrepency in the resource count ? - Key: CLOUDSTACK-8014 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8014 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.1 Reporter: France Assignee: Rohit Yadav As sent to mailing list: Hi all. We are on XS 6.0.2+Hotfixes and CS 4.3.1. (All errors we are getting nowadays have come up only after upgrade from 4.1.1, 4.1.1 worked perfectly.) After successfully creating s snapshot, I want to create a volume from it, so it can be downloaded offsite. After clicking “Create volume” I get an error Failed to create a volume. If i got to list of volumes, there is a volume with name as defined, but Status is empty, and only buttons for attach and destroy exist. I have taken a look at catalina.out and management-server.log. Here is the log detailing a failure. Can you see the problem? How should I fix it? Please advise me. Should I create a bug report? I have also manually checked space on all storages and it seems there is LOTS of free space. Resources based on CS Web GUI are: Primary Storage Allocated 15% Secondary Storage 5% 2014-12-03 12:20:42,493 DEBUG [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-2d51baa2) Zone 1 is ready to launch console proxy 2014-12-03 12:20:42,580 DEBUG [c.c.s.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-53354d18) Zone 1 is ready to launch secondary storage VM 2014-12-03 12:20:42,894 DEBUG [c.c.a.ApiServlet] (http-6443-exec-108:ctx-a228ce49) ===START=== 111.client.ip.111 -- GET command=listZonesavailable=trueresponse=jsonsessionkey=CENSORED%3D_=1417605814964 2014-12-03 12:20:42,909 DEBUG [c.c.a.ApiServlet] (http-6443-exec-108:ctx-a228ce49 ctx-74e696ca) ===END=== 111.client.ip.111 -- GET command=listZonesavailable=trueresponse=jsonsessionkey=CENSORED%3D_=1417605814964 2014-12-03 12:20:46,482 DEBUG [c.c.a.ApiServlet] (http-6443-exec-107:ctx-4a28e57c) ===START=== 111.client.ip.111 -- GET command=createVolumeresponse=jsonsessionkey=CENSORED%3Dsnapshotid=49e4bba9-844d-4b7b-aca2-95a318f17dc4name=testbrisi567_=1417605818552 2014-12-03 12:20:46,490 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,494 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,507 DEBUG [c.c.u.AccountManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) Access to com.cloud.storage.SnapshotVO$$EnhancerByCGLIB$$3490cea0@60c95391 granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,571 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-166:ctx-d915e890) Add job-2804 into job monitoring 2014-12-03 12:20:46,571 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (Job-Executor-166:ctx-d915e890) Executing AsyncJobVO {id:2804, userId: 59, accountId: 60, instanceType: Volume, instanceId: 617, cmd: org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd, cmdInfo: {id:617,response:json,sessionkey:CENSORED\u003d,cmdEventType:VOLUME.CREATE,ctxUserId:59,snapshotid:49e4bba9-844d-4b7b-aca2-95a318f17dc4,name:testbrisi567,httpmethod:GET,_:1417605818552,ctxAccountId:60,ctxStartEventId:62488}, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: null, initMsid: 95545481387, completeMsid: null, lastUpdated: null, lastPolled: null, created: null} 2014-12-03 12:20:46,577 DEBUG [c.c.u.AccountManagerImpl] (Job-Executor-166:ctx-d915e890 ctx-d7a11540) Access to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] granted to Acct[7d6da3bc-0d70-44eb-8a70-422e4eea184e-userName] by DomainChecker 2014-12-03 12:20:46,578 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (http-6443-exec-107:ctx-4a28e57c ctx-d7a11540) submit async job-2804, details: AsyncJobVO {id:2804, userId: 59, accountId: 60, instanceType: Volume, instanceId: 617, cmd: org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd, cmdInfo:
[jira] [Assigned] (CLOUDSTACK-6234) local storage shows up as 0 for disksizeallocated
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav reassigned CLOUDSTACK-6234: --- Assignee: (was: Rohit Yadav) local storage shows up as 0 for disksizeallocated - Key: CLOUDSTACK-6234 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6234 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.2.0 Reporter: Timothy Ehlers Priority: Critical clusterid: 10ea4d99-09ea-48cb-aca3-fe30c1c574ac, clustername: pod1c1, created: 2013-11-25T17:17:53-0600, disksizeallocated: 0, disksizetotal: 588371378176, disksizeused: 29782499328, id: 1d25d177-6d51-47ca-b03d-e3ec1f5adfc0, ipaddress: 10.228.231.45, name: server4 Local Storage, -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6667) Can't provision a site-to-site VPN with multiple CIDRs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241203#comment-14241203 ] Rohit Yadav commented on CLOUDSTACK-6667: - [~paulangus] - how may I reproduce it, need infra details? Can't provision a site-to-site VPN with multiple CIDRs -- Key: CLOUDSTACK-6667 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6667 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: Future, 4.2.1 Environment: CloudStack 4.2.1 Reporter: Paul Angus Assignee: Rohit Yadav Priority: Critical When attempting to create a site-to-site VPN with multiple remote CIDRs ie: 172.1.0.0/16,172.11.0.0/16 CloudStack reports that 172.1.0.0/16,172.11.0.0/16 is an invalid CIDR. CloudStack code does not appear to be enumerating the string as two comma separated CIDRs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8061) Extracting volume when it is in migrating state causes both the operations to fail
Min Chen created CLOUDSTACK-8061: Summary: Extracting volume when it is in migrating state causes both the operations to fail Key: CLOUDSTACK-8061 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8061 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Extracting volume when it is in migrating state causes both the operations to fail Steps to Reproduce: 1.Bring up CloudStack in advanced zone with xen cluster 2.Add two shared cluster level primary stores to the cluster 3.Deploy one vm using the default cent os template 4.Stop the vm 5.Migrate volume to another shared store 6.When the volume is in migrating state try to download the same volume. We will not see extract volume option in UI while volume is in migrating state. So please do it using API: http:/host:8096/client/api?command=extractVolumeid=03f4a082-a96c-4195-b74b-7aa602926825zoneid=f6c57314-d7df-417e-b994-c4a7c4e5b557mode=HTTP_DOWNLOAD Expected Behavior: If there is a race condition either of this operation should succeed. Or ExtractVolume job should wait for the migration job to finish and then execute extractvolume. Actual Behavior: = Both the operations are failed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8058) test_reset_ssh_keypair.py - test cases failing on EIP setup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye updated CLOUDSTACK-8058: --- Description: The publicIP of the VM changes on EIP setup after stop and start operation. Hence it is necessary that on such setup, new publicip should be used for the SSH. test_reset_ssh_keypair.py - test cases failing on EIP setup --- Key: CLOUDSTACK-8058 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8058 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 The publicIP of the VM changes on EIP setup after stop and start operation. Hence it is necessary that on such setup, new publicip should be used for the SSH. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8058) test_reset_ssh_keypair.py - test cases failing on EIP setup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye updated CLOUDSTACK-8058: --- Status: Reviewable (was: In Progress) test_reset_ssh_keypair.py - test cases failing on EIP setup --- Key: CLOUDSTACK-8058 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8058 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 The publicIP of the VM changes on EIP setup after stop and start operation. Hence it is necessary that on such setup, new publicip should be used for the SSH. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8062) test_multiple_ip_ranges.py - Fix the test case to avoid using same vlan IP range in each test case
Gaurav Aradhye created CLOUDSTACK-8062: -- Summary: test_multiple_ip_ranges.py - Fix the test case to avoid using same vlan IP range in each test case Key: CLOUDSTACK-8062 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8062 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.5.0 Each test case in this test suite uses the same vlan IP range, adds it and deletes it. In some cases, the vlan IP range deletion fails due to this operation. Change the test case to use different vlan IP range each time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8062) test_multiple_ip_ranges.py - Fix the test case to avoid using same vlan IP range in each test case
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye updated CLOUDSTACK-8062: --- Status: Reviewable (was: In Progress) test_multiple_ip_ranges.py - Fix the test case to avoid using same vlan IP range in each test case -- Key: CLOUDSTACK-8062 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8062 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 Each test case in this test suite uses the same vlan IP range, adds it and deletes it. In some cases, the vlan IP range deletion fails due to this operation. Change the test case to use different vlan IP range each time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-2823) SystemVMs start fail on CentOS 6.4
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14242277#comment-14242277 ] ASF subversion and git services commented on CLOUDSTACK-2823: - Commit 9bfb8e571934f70d00a69c3aa58cf848d016afb9 in cloudstack's branch refs/heads/4.5 from Wei Zhou [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9bfb8e5 ] CLOUDSTACK-2823: pass cmdline info to system vms for 30 times (cherry picked from commit 4eedfe53fcbab1d47b09eacaca1d803b67b6c4d2) SystemVMs start fail on CentOS 6.4 -- Key: CLOUDSTACK-2823 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2823 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Environment: CentOS 6.4, KVM CloudStack master Reporter: Wei Zhou Assignee: Wei Zhou Priority: Blocker Host: [root@cs-kvm015 ~]# virsh version Compiled against library: libvirt 0.10.2 Using library: libvirt 0.10.2 Using API: QEMU 0.10.2 Running hypervisor: QEMU 0.12.1 Network: em0 - cloudbr0 (Guest, Public), Guest: 172.16.61.0/24, Public: 10.11.11.0/24 (Can not connect outside) em1.103 - cloudbr1 (Management, Storage) , IP: 192.168.103.* Issue descripion (1) SystemVMs (SSVM, CPVM) start fails , and have no IP (Public, guest, management) (2) After I destroyed SystemVM, no new SystemVM will be created automatically. This issue only exists on master branch Deploy 4.1 successfully, and SystemVms work well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-2823) SystemVMs start fail on CentOS 6.4
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14242289#comment-14242289 ] ASF subversion and git services commented on CLOUDSTACK-2823: - Commit 4a7532ee65642b986b8cbf1034d482b94a76990c in cloudstack's branch refs/heads/4.4 from Wei Zhou [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4a7532e ] CLOUDSTACK-2823: pass cmdline info to system vms for 30 times (cherry picked from commit 4eedfe53fcbab1d47b09eacaca1d803b67b6c4d2) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Conflicts: systemvm/patches/debian/config/etc/init.d/cloud-early-config SystemVMs start fail on CentOS 6.4 -- Key: CLOUDSTACK-2823 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2823 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Environment: CentOS 6.4, KVM CloudStack master Reporter: Wei Zhou Assignee: Wei Zhou Priority: Blocker Host: [root@cs-kvm015 ~]# virsh version Compiled against library: libvirt 0.10.2 Using library: libvirt 0.10.2 Using API: QEMU 0.10.2 Running hypervisor: QEMU 0.12.1 Network: em0 - cloudbr0 (Guest, Public), Guest: 172.16.61.0/24, Public: 10.11.11.0/24 (Can not connect outside) em1.103 - cloudbr1 (Management, Storage) , IP: 192.168.103.* Issue descripion (1) SystemVMs (SSVM, CPVM) start fails , and have no IP (Public, guest, management) (2) After I destroyed SystemVM, no new SystemVM will be created automatically. This issue only exists on master branch Deploy 4.1 successfully, and SystemVms work well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)