[jira] [Commented] (CLOUDSTACK-8014) Failed to create a volume from snapshot - Discrepency in the resource count ?

2014-12-10 Thread Abhinandan Prateek (JIRA)

[ 
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

2014-12-10 Thread Sanjay Tripathi (JIRA)
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

2014-12-10 Thread Sanjay Tripathi (JIRA)

 [ 
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

2014-12-10 Thread Sanjay Tripathi (JIRA)

 [ 
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

2014-12-10 Thread ASF subversion and git services (JIRA)

[ 
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

2014-12-10 Thread Sanjay Tripathi (JIRA)

 [ 
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 ?

2014-12-10 Thread Abhinandan Prateek (JIRA)

 [ 
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

2014-12-10 Thread Gaurav Aradhye (JIRA)
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

2014-12-10 Thread Gaurav Aradhye (JIRA)
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

2014-12-10 Thread Gaurav Aradhye (JIRA)
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 ?

2014-12-10 Thread Rohit Yadav (JIRA)

[ 
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

2014-12-10 Thread Rohit Yadav (JIRA)

[ 
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

2014-12-10 Thread Gaurav Aradhye (JIRA)

 [ 
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

2014-12-10 Thread Jayapal Reddy (JIRA)

[ 
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

2014-12-10 Thread Rohit Yadav (JIRA)

[ 
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

2014-12-10 Thread Rohit Yadav (JIRA)

 [ 
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

2014-12-10 Thread Rohit Yadav (JIRA)

[ 
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

2014-12-10 Thread Jayapal Reddy (JIRA)

 [ 
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

2014-12-10 Thread Jayapal Reddy (JIRA)

[ 
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

2014-12-10 Thread ASF subversion and git services (JIRA)

[ 
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

2014-12-10 Thread ASF subversion and git services (JIRA)

[ 
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

2014-12-10 Thread ASF subversion and git services (JIRA)

[ 
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

2014-12-10 Thread Rohit Yadav (JIRA)
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

2014-12-10 Thread ASF subversion and git services (JIRA)

[ 
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

2014-12-10 Thread Rohit Yadav (JIRA)

 [ 
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

2014-12-10 Thread Rohit Yadav (JIRA)

[ 
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.

2014-12-10 Thread Sateesh Chodapuneedi (JIRA)

[ 
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.

2014-12-10 Thread Sateesh Chodapuneedi (JIRA)

 [ 
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

2014-12-10 Thread ASF subversion and git services (JIRA)

[ 
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

2014-12-10 Thread ASF subversion and git services (JIRA)

[ 
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

2014-12-10 Thread ASF subversion and git services (JIRA)

[ 
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

2014-12-10 Thread ASF subversion and git services (JIRA)

[ 
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 ?

2014-12-10 Thread Rohit Yadav (JIRA)

[ 
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 ?

2014-12-10 Thread Abhinandan Prateek (JIRA)

[ 
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 ?

2014-12-10 Thread France (JIRA)

[ 
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 ?

2014-12-10 Thread ASF subversion and git services (JIRA)

[ 
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 ?

2014-12-10 Thread ASF subversion and git services (JIRA)

[ 
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 ?

2014-12-10 Thread ASF subversion and git services (JIRA)

[ 
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 ?

2014-12-10 Thread ASF subversion and git services (JIRA)

[ 
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 ?

2014-12-10 Thread Rohit Yadav (JIRA)

 [ 
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

2014-12-10 Thread Rohit Yadav (JIRA)

 [ 
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

2014-12-10 Thread Rohit Yadav (JIRA)

[ 
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

2014-12-10 Thread Min Chen (JIRA)
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

2014-12-10 Thread Gaurav Aradhye (JIRA)

 [ 
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

2014-12-10 Thread Gaurav Aradhye (JIRA)

 [ 
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

2014-12-10 Thread Gaurav Aradhye (JIRA)
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

2014-12-10 Thread Gaurav Aradhye (JIRA)

 [ 
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

2014-12-10 Thread ASF subversion and git services (JIRA)

[ 
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

2014-12-10 Thread ASF subversion and git services (JIRA)

[ 
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)