[jira] [Created] (CLOUDSTACK-8921) snapshot_store_ref table should store actual size of back snapshot in secondary storage

2015-09-29 Thread subhash yedugundla (JIRA) 
subhash yedugundla created CLOUDSTACK-8921:
--

 Summary: snapshot_store_ref table should store actual size of back 
snapshot in secondary storage
 Key: CLOUDSTACK-8921
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8921
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Snapshot, Usage
Affects Versions: 4.5.2
 Environment: Hypervisor: Xen Server
Hypervisor Version: 6.2 + SP1 
Reporter: subhash yedugundla


CCP is storing physical-utilisation of the snapshot in physical_size column of 
the table "snapshot_store_ref". That was fixed as part of 
https://issues.apache.org/jira/browse/CLOUDSTACK-7842.

. From DB:
=

mysql> select * from snapshot_store_ref where id=586 \G;
*** 1. row ***
id: 586
store_id: 1
snapshot_id: 305
created: 2015-06-15 06:06:22
last_updated: NULL
job_id: NULL
store_role: Image
size: 5368709120
physical_size: 13312 ---> This is the size we are storing in the DB
parent_snapshot_id: 0
install_path: snapshots/2/233/e8d888a5-41c0-4a17-b1b7-f9a6fd50c0d3
state: Ready
update_count: 2
ref_cnt: 0
updated: 2015-06-15 06:06:36
volume_id: 233
1 row in set (0.00 sec)

 From File System:
=
[root@kirangoleta2 233]# ls -lh
total 2.1M
-rw-r--r--. 1 root root 2.1M Jun 15 11:36 
e8d888a5-41c0-4a17-b1b7-f9a6fd50c0d3.vhd ---> Physical file size

3. From Xen Server:
=
xe vdi-list name-label=newtest_ROOT-203_20150615060620 params=all

uuid ( RO) : 74a4185e-74fe-4cec-875b-060572cc675d
name-label ( RW): newtest_ROOT-203_20150615060620
name-description ( RW):
is-a-snapshot ( RO): true
snapshot-of ( RO): 02789581-7bfc-45bd-8e59-c35515d2b605
snapshots ( RO):
snapshot-time ( RO): 20150615T06:09:29Z
allowed-operations (SRO): forget; generate_config; update; resize; destroy; 
clone; copy; snapshot
current-operations (SRO):
sr-uuid ( RO): 73ff08fb-b341-c71c-e2c7-be6c8d395126
sr-name-label ( RO): 347c06fb-f7dd-3613-aa82-db5b82181d77
vbd-uuids (SRO):
crashdump-uuids (SRO):
virtual-size ( RO): 5368709120
physical-utilisation ( RO): 14848 ---> This is the size xen server reports as 
consumed
location ( RO): 74a4185e-74fe-4cec-875b-060572cc675d
type ( RO): User
sharable ( RO): false
read-only ( RO): false
storage-lock ( RO): false
managed ( RO): true
parent ( RO): 
missing ( RO): false
other-config (MRW): content_id: ad6423f7-e2c3-7ea4-be8d-573ad155511e
xenstore-data (MRO):
sm-config (MRO): vhd-parent: 73a33517-e9c5-48c6-89e7-70e37905a74a
on-boot ( RW): persist
allow-caching ( RW): false
metadata-latest ( RO): false
metadata-of-pool ( RO): 
tags (SRW):

I see that we are storing the physical-utilisation reported by xen server.
Interesting I see that ACS stores the physical file size in case of VMWare 
environment,

EXPECTED BEHAVIOR
==
It is expected to see the physical size of the snapshot file in physical_size 
column of the table "snapshot_store_ref

ACTUAL BEHAVIOR
==
In case of Xen Server CCP is storing physical-utilisation of the snapshot in 
physical_size column of the table "snapshot_store_ref"





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-8921) snapshot_store_ref table should store actual size of back snapshot in secondary storage

2015-09-29 Thread subhash yedugundla (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

subhash yedugundla updated CLOUDSTACK-8921:
---
Description: 
CCP is storing physical-utilisation of the snapshot in physical_size column of 
the table "snapshot_store_ref". That was fixed as part of 
https://issues.apache.org/jira/browse/CLOUDSTACK-7842.

>From DB:
=
mysql> select * from snapshot_store_ref where id=586 \G;
*** 1. row ***
id: 586
store_id: 1
snapshot_id: 305
created: 2015-06-15 06:06:22
last_updated: NULL
job_id: NULL
store_role: Image
size: 5368709120
physical_size: 13312 ---> This is the size we are storing in the DB
parent_snapshot_id: 0
install_path: snapshots/2/233/e8d888a5-41c0-4a17-b1b7-f9a6fd50c0d3
state: Ready
update_count: 2
ref_cnt: 0
updated: 2015-06-15 06:06:36
volume_id: 233
1 row in set (0.00 sec)

 From File System:
=
[root@kirangoleta2 233]# ls -lh
total 2.1M
-rw-r--r--. 1 root root 2.1M Jun 15 11:36 
e8d888a5-41c0-4a17-b1b7-f9a6fd50c0d3.vhd ---> Physical file size

3. From Xen Server:
=
xe vdi-list name-label=newtest_ROOT-203_20150615060620 params=all

uuid ( RO) : 74a4185e-74fe-4cec-875b-060572cc675d
name-label ( RW): newtest_ROOT-203_20150615060620
name-description ( RW):
is-a-snapshot ( RO): true
snapshot-of ( RO): 02789581-7bfc-45bd-8e59-c35515d2b605
snapshots ( RO):
snapshot-time ( RO): 20150615T06:09:29Z
allowed-operations (SRO): forget; generate_config; update; resize; destroy; 
clone; copy; snapshot
current-operations (SRO):
sr-uuid ( RO): 73ff08fb-b341-c71c-e2c7-be6c8d395126
sr-name-label ( RO): 347c06fb-f7dd-3613-aa82-db5b82181d77
vbd-uuids (SRO):
crashdump-uuids (SRO):
virtual-size ( RO): 5368709120
physical-utilisation ( RO): 14848 ---> This is the size xen server reports as 
consumed
location ( RO): 74a4185e-74fe-4cec-875b-060572cc675d
type ( RO): User
sharable ( RO): false
read-only ( RO): false
storage-lock ( RO): false
managed ( RO): true
parent ( RO): 
missing ( RO): false
other-config (MRW): content_id: ad6423f7-e2c3-7ea4-be8d-573ad155511e
xenstore-data (MRO):
sm-config (MRO): vhd-parent: 73a33517-e9c5-48c6-89e7-70e37905a74a
on-boot ( RW): persist
allow-caching ( RW): false
metadata-latest ( RO): false
metadata-of-pool ( RO): 
tags (SRW):

I see that we are storing the physical-utilisation reported by xen server.
Interesting I see that ACS stores the physical file size in case of VMWare 
environment,

EXPECTED BEHAVIOR
==
It is expected to see the physical size of the snapshot file in physical_size 
column of the table "snapshot_store_ref

ACTUAL BEHAVIOR
==
In case of Xen Server ACS is storing physical-utilisation of the snapshot in 
physical_size column of the table "snapshot_store_ref"



  was:
CCP is storing physical-utilisation of the snapshot in physical_size column of 
the table "snapshot_store_ref". That was fixed as part of 
https://issues.apache.org/jira/browse/CLOUDSTACK-7842.

. From DB:
=

mysql> select * from snapshot_store_ref where id=586 \G;
*** 1. row ***
id: 586
store_id: 1
snapshot_id: 305
created: 2015-06-15 06:06:22
last_updated: NULL
job_id: NULL
store_role: Image
size: 5368709120
physical_size: 13312 ---> This is the size we are storing in the DB
parent_snapshot_id: 0
install_path: snapshots/2/233/e8d888a5-41c0-4a17-b1b7-f9a6fd50c0d3
state: Ready
update_count: 2
ref_cnt: 0
updated: 2015-06-15 06:06:36
volume_id: 233
1 row in set (0.00 sec)

 From File System:
=
[root@kirangoleta2 233]# ls -lh
total 2.1M
-rw-r--r--. 1 root root 2.1M Jun 15 11:36 
e8d888a5-41c0-4a17-b1b7-f9a6fd50c0d3.vhd ---> Physical file size

3. From Xen Server:
=
xe vdi-list name-label=newtest_ROOT-203_20150615060620 params=all

uuid ( RO) : 74a4185e-74fe-4cec-875b-060572cc675d
name-label ( RW): newtest_ROOT-203_20150615060620
name-description ( RW):
is-a-snapshot ( RO): true
snapshot-of ( RO): 02789581-7bfc-45bd-8e59-c35515d2b605
snapshots ( RO):
snapshot-time ( RO): 20150615T06:09:29Z
allowed-operations (SRO): forget; generate_config; update; resize; destroy; 
clone; copy; snapshot
current-operations (SRO):
sr-uuid ( RO): 73ff08fb-b341-c71c-e2c7-be6c8d395126
sr-name-label ( RO): 347c06fb-f7dd-3613-aa82-db5b82181d77
vbd-uuids (SRO):
crashdump-uuids (SRO):
virtual-size ( RO): 5368709120
physical-utilisation ( RO): 14848 ---> This is the size xen server reports as 
consumed
location ( RO): 74a4185e-74fe-4cec-875b-060572cc675d
type ( RO): User
sharable ( RO): false
read-only ( RO): false
storage-lock ( RO): false
managed ( RO): true
parent ( RO): 
missing ( RO): false
other-config (MRW): content_id: ad6423f7-e2c3-7ea4-be8d-573ad155511e
xenstore-data (MRO):
sm-config (MRO): vhd-parent: 73a33517-e9c5-48c6-89e7-70e37905a74a
on-boot ( RW): persist

[jira] [Updated] (CLOUDSTACK-8921) snapshot_store_ref table should store actual size of back snapshot in secondary storage

2015-09-29 Thread subhash yedugundla (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

subhash yedugundla updated CLOUDSTACK-8921:
---
Description: 
CCP is storing physical-utilisation of the snapshot in physical_size column of 
the table "snapshot_store_ref". That was fixed as part of 
https://issues.apache.org/jira/browse/CLOUDSTACK-7842.

>From DB:
=
mysql> select * from snapshot_store_ref where id=586 \G;


id: 586
store_id: 1
snapshot_id: 305
created: 2015-06-15 06:06:22
last_updated: NULL
job_id: NULL
store_role: Image
size: 5368709120
physical_size: 13312 ---> This is the size we are storing in the DB
parent_snapshot_id: 0
install_path: snapshots/2/233/e8d888a5-41c0-4a17-b1b7-f9a6fd50c0d3
state: Ready
update_count: 2
ref_cnt: 0
updated: 2015-06-15 06:06:36
volume_id: 233
1 row in set (0.00 sec)

 From File System:
=
[root@kirangoleta2 233]# ls -lh
total 2.1M
-rw-r--r--. 1 root root 2.1M Jun 15 11:36 
e8d888a5-41c0-4a17-b1b7-f9a6fd50c0d3.vhd ---> Physical file size

3. From Xen Server:
=
xe vdi-list name-label=newtest_ROOT-203_20150615060620 params=all

uuid ( RO) : 74a4185e-74fe-4cec-875b-060572cc675d
name-label ( RW): newtest_ROOT-203_20150615060620
name-description ( RW):
is-a-snapshot ( RO): true
snapshot-of ( RO): 02789581-7bfc-45bd-8e59-c35515d2b605
snapshots ( RO):
snapshot-time ( RO): 20150615T06:09:29Z
allowed-operations (SRO): forget; generate_config; update; resize; destroy; 
clone; copy; snapshot
current-operations (SRO):
sr-uuid ( RO): 73ff08fb-b341-c71c-e2c7-be6c8d395126
sr-name-label ( RO): 347c06fb-f7dd-3613-aa82-db5b82181d77
vbd-uuids (SRO):
crashdump-uuids (SRO):
virtual-size ( RO): 5368709120
physical-utilisation ( RO): 14848 ---> This is the size xen server reports as 
consumed
location ( RO): 74a4185e-74fe-4cec-875b-060572cc675d
type ( RO): User
sharable ( RO): false
read-only ( RO): false
storage-lock ( RO): false
managed ( RO): true
parent ( RO): 
missing ( RO): false
other-config (MRW): content_id: ad6423f7-e2c3-7ea4-be8d-573ad155511e
xenstore-data (MRO):
sm-config (MRO): vhd-parent: 73a33517-e9c5-48c6-89e7-70e37905a74a
on-boot ( RW): persist
allow-caching ( RW): false
metadata-latest ( RO): false
metadata-of-pool ( RO): 
tags (SRW):

I see that we are storing the physical-utilisation reported by xen server.
Interesting I see that ACS stores the physical file size in case of VMWare 
environment,

EXPECTED BEHAVIOR
==
It is expected to see the physical size of the snapshot file in physical_size 
column of the table "snapshot_store_ref

ACTUAL BEHAVIOR
==
In case of Xen Server ACS is storing physical-utilisation of the snapshot in 
physical_size column of the table "snapshot_store_ref"



  was:
CCP is storing physical-utilisation of the snapshot in physical_size column of 
the table "snapshot_store_ref". That was fixed as part of 
https://issues.apache.org/jira/browse/CLOUDSTACK-7842.

>From DB:
=
mysql> select * from snapshot_store_ref where id=586 \G;
*** 1. row ***
id: 586
store_id: 1
snapshot_id: 305
created: 2015-06-15 06:06:22
last_updated: NULL
job_id: NULL
store_role: Image
size: 5368709120
physical_size: 13312 ---> This is the size we are storing in the DB
parent_snapshot_id: 0
install_path: snapshots/2/233/e8d888a5-41c0-4a17-b1b7-f9a6fd50c0d3
state: Ready
update_count: 2
ref_cnt: 0
updated: 2015-06-15 06:06:36
volume_id: 233
1 row in set (0.00 sec)

 From File System:
=
[root@kirangoleta2 233]# ls -lh
total 2.1M
-rw-r--r--. 1 root root 2.1M Jun 15 11:36 
e8d888a5-41c0-4a17-b1b7-f9a6fd50c0d3.vhd ---> Physical file size

3. From Xen Server:
=
xe vdi-list name-label=newtest_ROOT-203_20150615060620 params=all

uuid ( RO) : 74a4185e-74fe-4cec-875b-060572cc675d
name-label ( RW): newtest_ROOT-203_20150615060620
name-description ( RW):
is-a-snapshot ( RO): true
snapshot-of ( RO): 02789581-7bfc-45bd-8e59-c35515d2b605
snapshots ( RO):
snapshot-time ( RO): 20150615T06:09:29Z
allowed-operations (SRO): forget; generate_config; update; resize; destroy; 
clone; copy; snapshot
current-operations (SRO):
sr-uuid ( RO): 73ff08fb-b341-c71c-e2c7-be6c8d395126
sr-name-label ( RO): 347c06fb-f7dd-3613-aa82-db5b82181d77
vbd-uuids (SRO):
crashdump-uuids (SRO):
virtual-size ( RO): 5368709120
physical-utilisation ( RO): 14848 ---> This is the size xen server reports as 
consumed
location ( RO): 74a4185e-74fe-4cec-875b-060572cc675d
type ( RO): User
sharable ( RO): false
read-only ( RO): false
storage-lock ( RO): false
managed ( RO): true
parent ( RO): 
missing ( RO): false
other-config (MRW): content_id: ad6423f7-e2c3-7ea4-be8d-573ad155511e
xenstore-data (MRO):
sm-config (MRO): vhd-parent: 73a33517-e9c5-48c6-89e7-70e37905a74a
on-boot ( RW): persist
allow-caching ( RW): false
metadata-latest ( RO): false

[jira] [Commented] (CLOUDSTACK-8920) KVM agent cannot communicate with server on port 8250

2015-09-29 Thread Remi Bergsma (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14935103#comment-14935103
 ] 

Remi Bergsma commented on CLOUDSTACK-8920:
--

This works fine in my environment. Are you able to telnet to the management 
server over port 8250?

Set the pro to critical, as this is not a blocker for release.

> KVM agent cannot communicate with server on port 8250
> -
>
> Key: CLOUDSTACK-8920
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8920
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.5.2
> Environment: CentOS 6.7, OpenJDK 1.7.0
>Reporter: Noel D. Kendall
>
> Attempting to add a KVM host, the management server is able to reach the 
> target host via SSH and successfully changes agent.properties, and restarts 
> the agent process. All that works fine. Zone, Pod and Cluster are configured 
> successfully.
> Problem is occurring on the agent when attempting to contact the management 
> server on port 8250. Getting an ERROR logged, unable to initialize the 
> threads, with an IOException -1 connection closed with -1 on reading size.
> This sounds suspiciously like an SSL client is attempting to connect to a 
> non-SSL server. For the life of me, I cannot see how this is configured or 
> misconfigured.
> I have created SSL certificates for the proxies, and successfully uploaded 
> these, following the documentation. Not sure this is related in any way or 
> not.
> Have turned on full debugging log output in log4j, not seeing any elaboration 
> on the underlying cause of the problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-8922) Unable to delete IP tag

2015-09-29 Thread subhash yedugundla (JIRA) 
subhash yedugundla created CLOUDSTACK-8922:
--

 Summary: Unable to delete IP tag
 Key: CLOUDSTACK-8922
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8922
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.5.2
Reporter: subhash yedugundla


1. Acquire new IP address 
2. Create tags for the IP 
3. Delete the tag from Step#2 

 an error occurs at Step#3 whereby the delete tag operation fails with 
"Acct[f4d0c381-e0b7-4aed-aa90-3336d42f7540-7100017] does not have 
permission to operate within domain id\u003d632"

TROUBLESHOOTING
==
Acquire new IP address
*
{noformat}
2014-11-19 15:08:15,870 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(catalina-exec-20:ctx-faed32b5 ctx-712308cb ctx-401bfcaf) submit async 
job-72419, details: AsyncJobVO {id:72419, userId: 17, accountId: 15, 
instanceType: IpAddress, instanceId: 672, cmd: 
org.apache.cloudstack.api.command.user.address.AssociateIPAddrCmd, cmdInfo: 
{"id":"672","response":"json","cmdEventType":"NET.IPASSIGN","ctxUserId":"17","zoneid":"a117e75f-d02e-4074-806d-889c61261394","httpmethod":"GET","ctxAccountId":"15","networkid":"0ca7c69e-c281-407b-a152-2559c10a81a6","ctxStartEventId":"166725","signature":"3NZRU6dIBxg1HMDiP/MkY2agRn4\u003d","apikey":"tuwHXs1AfpQheJeJ9BcLdoVxIBCItASnguAbus76AMUcIXuyFgHOJiIB44fO57p_bBaqyfppmxrC-rQSb-nxXg"},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 345048681027, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}
2014-11-19 15:08:15,870 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-68:ctx-fca9add6 job-72419) Executing AsyncJobVO {id:72419, 
userId: 17, accountId: 15, instanceType: IpAddress, instanceId: 672, cmd: 
org.apache.cloudstack.api.command.user.address.AssociateIPAddrCmd, cmdInfo: 
{"id":"672","response":"json","cmdEventType":"NET.IPASSIGN","ctxUserId":"17","zoneid":"a117e75f-d02e-4074-806d-889c61261394","httpmethod":"GET","ctxAccountId":"15","networkid":"0ca7c69e-c281-407b-a152-2559c10a81a6","ctxStartEventId":"166725","signature":"3NZRU6dIBxg1HMDiP/MkY2agRn4\u003d","apikey":"tuwHXs1AfpQheJeJ9BcLdoVxIBCItASnguAbus76AMUcIXuyFgHOJiIB44fO57p_bBaqyfppmxrC-rQSb-nxXg"},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 345048681027, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}
2014-11-19 15:08:15,890 DEBUG [c.c.u.AccountManagerImpl] 
(API-Job-Executor-68:ctx-fca9add6 job-72419 ctx-96bbdee5) Access to 
Ntwk[216|Guest|8] granted to 
Acct[f4d0c381-e0b7-4aed-aa90-3336d42f7540-7100017] by DomainChecker
2014-11-19 15:08:15,911 DEBUG [c.c.n.IpAddressManagerImpl] 
(API-Job-Executor-68:ctx-fca9add6 job-72419 ctx-96bbdee5) Successfully 
associated ip address 210.140.170.160 to network Ntwk[216|Guest|8]
2014-11-19 15:08:15,922 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-68:ctx-fca9add6 job-72419 ctx-96bbdee5) Complete async 
job-72419, jobStatus: SUCCEEDED, resultCode: 0, result: 
org.apache.cloudstack.api.response.IPAddressResponse/ipaddress/{"id":"3d7c3a2a-1f2d-46dc-9905-4a7ce620e7e9","ipaddress":"210.140.170.160","allocated":"2014-11-19T15:08:15+0900","zoneid":"a117e75f-d02e-4074-806d-889c61261394","zonename":"tesla","issourcenat":false,"account":"7100017","domainid":"cc27e32c-6acd-4fdf-a1e5-734cef8a7fe0","domain":"7100017","forvirtualnetwork":true,"isstaticnat":false,"issystem":false,"associatednetworkid":"0ca7c69e-c281-407b-a152-2559c10a81a6","associatednetworkname":"network1","networkid":"79132c74-fe77-4bd5-9915-ce7c577fb95f","state":"Allocating","physicalnetworkid":"4a00ce42-6a30-4494-afdd-3531d883237b","tags":[],"isportable":false}
2014-11-19 15:08:15,932 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(API-Job-Executor-68:ctx-fca9add6 job-72419) Remove job-72419 from job 
monitoring

+---+---++---+---+-+-+
| id| job_cmd   | 
job_status | job_init_msid | job_complete_msid | created | 
last_updated|
+---+---++---+---+-+-+
| 72419 | org.apache.cloudstack.api.command.user.address.AssociateIPAddrCmd |   
   1 |  345048681027 |  345048681027 | 2014-11-19 06:08:15 | 2014-11-19 
06:08:15 |
+---+---++---+---+-+-+
1 row in set (0.00 sec)
{noformat}


Create

[jira] [Updated] (CLOUDSTACK-8920) KVM agent cannot communicate with server on port 8250

2015-09-29 Thread Remi Bergsma (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Remi Bergsma updated CLOUDSTACK-8920:
-
Priority: Major  (was: Blocker)

> KVM agent cannot communicate with server on port 8250
> -
>
> Key: CLOUDSTACK-8920
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8920
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.5.2
> Environment: CentOS 6.7, OpenJDK 1.7.0
>Reporter: Noel D. Kendall
>
> Attempting to add a KVM host, the management server is able to reach the 
> target host via SSH and successfully changes agent.properties, and restarts 
> the agent process. All that works fine. Zone, Pod and Cluster are configured 
> successfully.
> Problem is occurring on the agent when attempting to contact the management 
> server on port 8250. Getting an ERROR logged, unable to initialize the 
> threads, with an IOException -1 connection closed with -1 on reading size.
> This sounds suspiciously like an SSL client is attempting to connect to a 
> non-SSL server. For the life of me, I cannot see how this is configured or 
> misconfigured.
> I have created SSL certificates for the proxies, and successfully uploaded 
> these, following the documentation. Not sure this is related in any way or 
> not.
> Have turned on full debugging log output in log4j, not seeing any elaboration 
> on the underlying cause of the problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-8923) Create storage network IP range failed, Unknown parameters : zoneid

2015-09-29 Thread Nux (JIRA) 
Nux created CLOUDSTACK-8923:
---

 Summary: Create storage network IP range failed, Unknown 
parameters : zoneid
 Key: CLOUDSTACK-8923
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8923
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Secondary Storage
Affects Versions: 4.6.0
 Environment: CentOS 6 HVs and MGMT
Reporter: Nux
Priority: Blocker


I am installing ACS from today's master (3ded3e9 http://tmp.nux.ro/acs460snap/ 
). 
Adding an initial zone via the web UI wizard fails at the secondary storage 
setup stage:

2015-09-29 14:07:40,319 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(API-Job-Executor-25:ctx-73c1ad88 job-27) Add job-27 into job monitoring
2015-09-29 14:07:40,322 DEBUG [c.c.a.ApiServlet] (catalina-exec-5:ctx-314bbaae 
ctx-2db63923) ===END===  85.13.192.198 -- GET  
command=createStorageNetworkIpRange=json=192.168.200.67=255.255.255.0=123=192.168.200.200=192.168.200.222=2f0efdcf-adf6-4373-858e-87de6af4cc08=eb7814d2-9a22-4ca4-93af-4a6b8abac67c&_=1443532060283
2015-09-29 14:07:40,327 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-25:ctx-73c1ad88 job-27) Executing AsyncJobVO {id:27, userId: 
2, accountId: 2, instanceType: None, instanceId: null, cmd: 
org.apache.cloudstack.api.command.admin.network.CreateStorageNetworkIpRangeCmd, 
cmdInfo: {"response":"json","ctxDetails":"{\"interface 
com.cloud.dc.Pod\":\"eb7814d2-9a22-4ca4-93af-4a6b8abac67c\"}","cmdEventType":"STORAGE.IP.RANGE.CREATE","ctxUserId":"2","gateway":"192.168.200.67","podid":"eb7814d2-9a22-4ca4-93af-4a6b8abac67c","zoneid":"2f0efdcf-adf6-4373-858e-87de6af4cc08","startip":"192.168.200.200","vlan":"123","httpmethod":"GET","_":"1443532060283","ctxAccountId":"2","ctxStartEventId":"68","netmask":"255.255.255.0","endip":"192.168.200.222"},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}
2015-09-29 14:07:40,330 WARN  [c.c.a.d.ParamGenericValidationWorker] 
(API-Job-Executor-25:ctx-73c1ad88 job-27 ctx-1fa03c4a) Received unknown 
parameters for command createStorageNetworkIpRange. Unknown parameters : zoneid
2015-09-29 14:07:40,391 WARN  [o.a.c.a.c.a.n.CreateStorageNetworkIpRangeCmd] 
(API-Job-Executor-25:ctx-73c1ad88 job-27 ctx-1fa03c4a) Create storage network 
IP range failed
com.cloud.utils.exception.CloudRuntimeException: Unable to commit or close the 
connection. 
at 
com.cloud.utils.db.TransactionLegacy.commit(TransactionLegacy.java:730)
at com.cloud.utils.db.Transaction.execute(Transaction.java:46)
at 
com.cloud.network.StorageNetworkManagerImpl.createIpRange(StorageNetworkManagerImpl.java:229)
at 
org.apache.cloudstack.api.command.admin.network.CreateStorageNetworkIpRangeCmd.execute(CreateStorageNetworkIpRangeCmd.java:118)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150)
at 
com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
at 
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:537)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at 
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:494)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.sql.SQLException: Connection is closed.
at 
org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.checkOpen(PoolingDataSource.java:185)
at 
org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.commit(PoolingDataSource.java:210)
at 
com.cloud.utils.db.TransactionLegacy.commit(TransactionLegacy.java:722)
... 17 more
2015-09-29 14:07:40,392 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-25:ctx-73c1ad88 job-27) Complete async job-27, jobStatus: 
FAILED, resultCode: 530, result:

[jira] [Commented] (CLOUDSTACK-8921) snapshot_store_ref table should store actual size of back snapshot in secondary storage

2015-09-29 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934890#comment-14934890
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8921:


GitHub user yvsubhash opened a pull request:

https://github.com/apache/cloudstack/pull/899

BUG-ID:CLOUDSTACK-8921

Summary: CLOUDSTACK-8921
 snapshot_store_ref table should store actual size of back snapshot in 
secondary storage
Calling SR scan to make sure size is updated correctly

This scenario is tested with this bug fix. Unit tests are not added as the 
methods that are fixed are too long to add unit tests and there is no existing 
unit test to change

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/yvsubhash/cloudstack CLOUDSTACK-8921

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/899.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #899


commit 0ff08be8789bf50628bf7ba1b8b0da1d2f6c6639
Author: subhash yedugundla 
Date:   2015-09-22T06:26:40Z

BUG-ID:CLOUDSTACK-8921
Summary: CLOUDSTACK-8921
 snapshot_store_ref table should store actual size of back snapshot in 
secondary storage
Calling SR scan to make sure size is updated correctly




> snapshot_store_ref table should store actual size of back snapshot in 
> secondary storage
> ---
>
> Key: CLOUDSTACK-8921
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8921
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Snapshot, Usage
>Affects Versions: 4.5.2
> Environment: Hypervisor: Xen Server
> Hypervisor Version: 6.2 + SP1 
>Reporter: subhash yedugundla
>
> CCP is storing physical-utilisation of the snapshot in physical_size column 
> of the table "snapshot_store_ref". That was fixed as part of 
> https://issues.apache.org/jira/browse/CLOUDSTACK-7842.
> From DB:
> =
> mysql> select * from snapshot_store_ref where id=586 \G;
> id: 586
> store_id: 1
> snapshot_id: 305
> created: 2015-06-15 06:06:22
> last_updated: NULL
> job_id: NULL
> store_role: Image
> size: 5368709120
> physical_size: 13312 ---> This is the size we are storing in the DB
> parent_snapshot_id: 0
> install_path: snapshots/2/233/e8d888a5-41c0-4a17-b1b7-f9a6fd50c0d3
> state: Ready
> update_count: 2
> ref_cnt: 0
> updated: 2015-06-15 06:06:36
> volume_id: 233
> 1 row in set (0.00 sec)
>  From File System:
> =
> [root@kirangoleta2 233]# ls -lh
> total 2.1M
> -rw-r--r--. 1 root root 2.1M Jun 15 11:36 
> e8d888a5-41c0-4a17-b1b7-f9a6fd50c0d3.vhd ---> Physical file size
> 3. From Xen Server:
> =
> xe vdi-list name-label=newtest_ROOT-203_20150615060620 params=all
> uuid ( RO) : 74a4185e-74fe-4cec-875b-060572cc675d
> name-label ( RW): newtest_ROOT-203_20150615060620
> name-description ( RW):
> is-a-snapshot ( RO): true
> snapshot-of ( RO): 02789581-7bfc-45bd-8e59-c35515d2b605
> snapshots ( RO):
> snapshot-time ( RO): 20150615T06:09:29Z
> allowed-operations (SRO): forget; generate_config; update; resize; destroy; 
> clone; copy; snapshot
> current-operations (SRO):
> sr-uuid ( RO): 73ff08fb-b341-c71c-e2c7-be6c8d395126
> sr-name-label ( RO): 347c06fb-f7dd-3613-aa82-db5b82181d77
> vbd-uuids (SRO):
> crashdump-uuids (SRO):
> virtual-size ( RO): 5368709120
> physical-utilisation ( RO): 14848 ---> This is the size xen server reports as 
> consumed
> location ( RO): 74a4185e-74fe-4cec-875b-060572cc675d
> type ( RO): User
> sharable ( RO): false
> read-only ( RO): false
> storage-lock ( RO): false
> managed ( RO): true
> parent ( RO): 
> missing ( RO): false
> other-config (MRW): content_id: ad6423f7-e2c3-7ea4-be8d-573ad155511e
> xenstore-data (MRO):
> sm-config (MRO): vhd-parent: 73a33517-e9c5-48c6-89e7-70e37905a74a
> on-boot ( RW): persist
> allow-caching ( RW): false
> metadata-latest ( RO): false
> metadata-of-pool ( RO): 
> tags (SRW):
> I see that we are storing the physical-utilisation reported by xen server.
> Interesting I see that ACS stores the physical file size in case of VMWare 
> environment,
> EXPECTED BEHAVIOR
> ==
> It is expected to see the physical size of the snapshot file in physical_size 
> column of the table "snapshot_store_ref
> ACTUAL BEHAVIOR
> ==
> In case of Xen Server ACS is storing physical-utilisation of the snapshot in 
> physical_size column of the table "snapshot_store_ref"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8728) Testcase to Verify if VRs IP changes if it is destroyed and re-created in Basic Zone

2015-09-29 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934909#comment-14934909
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8728:


Github user pritisarap12 commented on the pull request:

https://github.com/apache/cloudstack/pull/684#issuecomment-144003970
  
Merged the testcase in the existing testcase 
test_03_restart_network_cleanup by adding support for basic setup.


> Testcase to Verify if VRs IP changes if it is destroyed and re-created in 
> Basic Zone
> 
>
> Key: CLOUDSTACK-8728
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8728
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.1
>Reporter: Priti Sarap
> Fix For: 4.2.1
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8901) PrepareTemplate job thread hard-coded to max 8 threads

2015-09-29 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14935000#comment-14935000
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8901:


Github user koushik-das commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/880#discussion_r40658531
  
--- Diff: setup/db/db/schema-452to460.sql ---
@@ -413,3 +413,6 @@ CREATE TABLE `cloud`.`ldap_trust_map` (
   UNIQUE KEY `uk_ldap_trust_map__domain_id` (`domain_id`),
   CONSTRAINT `fk_ldap_trust_map__domain_id` FOREIGN KEY (`domain_id`) 
REFERENCES `domain` (`id`)
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
+
+INSERT IGNORE INTO `cloud`.`configuration` VALUES ('Advanced', 'DEFAULT', 
'TemplateManager', 'template.preloader.pool.size', '8', 'Size of the threadpool 
for preparetemplate api', '8', NULL, 'Global', 0);
--- End diff --

This is not required once the Configurable is implemented.


> PrepareTemplate job thread hard-coded to max 8 threads
> --
>
> Key: CLOUDSTACK-8901
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8901
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>
>  The thread pool is hardcoded to use 8 threads,
> com.cloud.template.TemplateManagerImpl.configure(String, Map):
> _preloadExecutor = Executors.newFixedThreadPool(8, new 
> NamedThreadFactory("Template-Preloader"));
> Need to make it configurable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8920) KVM agent cannot communicate with server on port 8250

2015-09-29 Thread Erik Weber (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14935045#comment-14935045
 ] 

Erik Weber commented on CLOUDSTACK-8920:


I had something similar once, not long ago, where it turned out to be an out of 
date ssl library causing trouble.
Have you checked that there aren't any packages available for update on both 
the host and mgmt server?

> KVM agent cannot communicate with server on port 8250
> -
>
> Key: CLOUDSTACK-8920
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8920
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.5.2
> Environment: CentOS 6.7, OpenJDK 1.7.0
>Reporter: Noel D. Kendall
>Priority: Blocker
>
> Attempting to add a KVM host, the management server is able to reach the 
> target host via SSH and successfully changes agent.properties, and restarts 
> the agent process. All that works fine. Zone, Pod and Cluster are configured 
> successfully.
> Problem is occurring on the agent when attempting to contact the management 
> server on port 8250. Getting an ERROR logged, unable to initialize the 
> threads, with an IOException -1 connection closed with -1 on reading size.
> This sounds suspiciously like an SSL client is attempting to connect to a 
> non-SSL server. For the life of me, I cannot see how this is configured or 
> misconfigured.
> I have created SSL certificates for the proxies, and successfully uploaded 
> these, following the documentation. Not sure this is related in any way or 
> not.
> Have turned on full debugging log output in log4j, not seeing any elaboration 
> on the underlying cause of the problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8911) VM start job got stuck in loop looking for suitable host

2015-09-29 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934991#comment-14934991
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8911:


Github user koushik-das commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/895#discussion_r40657679
  
--- Diff: 
server/src/com/cloud/agent/manager/allocator/impl/FirstFitAllocator.java ---
@@ -297,6 +297,7 @@
 s_logger.debug("Host name: " + host.getName() + ", 
hostId: " + host.getId() +
 " already has max Running VMs(count includes 
system VMs), skipping this and trying other available hosts");
 }
+avoid.addHost(host.getId());
--- End diff --

@SudharmaJain There is another check for GPU device immediately below and 
the pattern is similar to the guest VM check. The issue you have mentioned can 
happen even for this. Can you check and verify?


> VM start job got stuck in loop looking for suitable host
> 
>
> Key: CLOUDSTACK-8911
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8911
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.3.0
>Reporter: sudharma jain
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-3201) Mesos bash script to install and configure mesos cluster

2015-09-29 Thread sebastien goasguen (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

sebastien goasguen closed CLOUDSTACK-3201.
--
Resolution: Won't Fix

> Mesos bash script to install and configure mesos cluster
> 
>
> Key: CLOUDSTACK-3201
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3201
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Dharmesh Kakadia
>Assignee: Dharmesh Kakadia
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-6114) GSoC: Create config management recipes to install CloudStack

2015-09-29 Thread sebastien goasguen (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

sebastien goasguen resolved CLOUDSTACK-6114.

Resolution: Fixed

> GSoC: Create config management recipes to install CloudStack
> 
>
> Key: CLOUDSTACK-6114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6114
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sebastien goasguen
>Assignee: Ian Duffy
>  Labels: gsoc2014
>
> To ease deployment of CloudStack we need to develop a set of recipes for all 
> the configuration management systems. A few already exists using Chef, Puppet 
> and Ansible.
> This project will do an inventory of existing recipes available on-line, 
> coalesce them into a coherent set and write missing recipes.
> The student will need to learn configuration management with at least one 
> tool (chef, puppet, ansible, salt..etc) and will develop recipes using 
> Vagrant.
> The outcome will be a fully functional devcloud (cloudstack sandbox) with 
> mutiple recipes. CloudStack will be deployable in a sanbox or in a 
> multi-machine environment.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (CLOUDSTACK-1778) GSoC: Create a bootstrap based GUI for CloudStack

2015-09-29 Thread sebastien goasguen (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

sebastien goasguen closed CLOUDSTACK-1778.
--
Resolution: Won't Fix

> GSoC: Create a bootstrap based GUI for CloudStack
> -
>
> Key: CLOUDSTACK-1778
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1778
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: sebastien goasguen
>Assignee: Shiva Teja Reddy
>  Labels: gsoc2013
> Fix For: Future
>
>
> Apache CloudStack has a very efficient web based UI, however all UI actions 
> correspond to API calls. The Web UI was meant has a demo to show case what 
> can be done with the API. In this project, the student would create a new 
> WebUI using the Twitter BootStrap javascript framework and probably a python 
> web framework like flask. This would result in a standalone web UI that 
> anyone could use.
> Language: javascript, python
> Protocols: http(s)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-5125) [doc] Release Note Known Issues, Fixed Issues, and New features

2015-09-29 Thread sebastien goasguen (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

sebastien goasguen resolved CLOUDSTACK-5125.

Resolution: Fixed

> [doc] Release Note Known Issues, Fixed Issues, and New features
> ---
>
> Key: CLOUDSTACK-5125
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5125
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Doc
>Reporter: Radhika Nair
>Assignee: Radhika Nair
> Fix For: Future
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8911) VM start job got stuck in loop looking for suitable host

2015-09-29 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934987#comment-14934987
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8911:


Github user koushik-das commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/895#discussion_r40657381
  
--- Diff: 
server/src/com/cloud/agent/manager/allocator/impl/FirstFitAllocator.java ---
@@ -297,6 +297,7 @@
 s_logger.debug("Host name: " + host.getName() + ", 
hostId: " + host.getId() +
 " already has max Running VMs(count includes 
system VMs), skipping this and trying other available hosts");
 }
+avoid.addHost(host.getId());
--- End diff --

The change looks good.


> VM start job got stuck in loop looking for suitable host
> 
>
> Key: CLOUDSTACK-8911
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8911
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.3.0
>Reporter: sudharma jain
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8848) Unexpected VR reboot after out-of-band migration

2015-09-29 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14935017#comment-14935017
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8848:


Github user koushik-das commented on the pull request:

https://github.com/apache/cloudstack/pull/885#issuecomment-144030748
  
@resmo The changes LGTM.
About testing on XS, the following should work:
- Deploy a VM
- Destroy the VM outside of CS (for e.g. from XenCenter)
- In the next vm power sync cycle the missing VM message should appear on 
the logs.

If you are familiar with the simulator, you can automate the scenario using 
it. Please refer to the following links:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Simulator+enhancements

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Writing+tests+leveraging+the+simulator+enhancements


> Unexpected VR reboot after out-of-band migration
> 
>
> Key: CLOUDSTACK-8848
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8848
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.5.2, 4.6.0
>Reporter: René Moser
>Assignee: René Moser
>Priority: Blocker
> Fix For: 4.5.3, 4.6.0
>
>
> In some conditions (race condition), VR gets rebooted after a out of band 
> migration was done on vCenter. 
> {panel:bgColor=#CE}
> Note, new global setting in 4.5.2 "VR reboot after out of band migration" is 
> set to *false* and this looks more like a bug.
> {panel}
> After a VR migration to a host _and_ when the VM power state report gathering 
> is running, the VR (and also any user VM as well) will get into the 
> "PowerReportMissing".
> If the VM is a VR. it will be powered off and started again on vCenter. That 
> is what we see. In can not be reproduced every time a migration was done, but 
> it seems the problem is related to "powerReportMissing".
> I grep-ed the source and found this line related
> https://github.com/apache/cloudstack/blob/4.5.2/engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java#L3616
> and also it seems that the graceful period might be also related, 
> https://github.com/apache/cloudstack/blob/4.5.2/engine/orchestration/src/com/cloud/vm/VirtualMachinePowerStateSyncImpl.java#L110
> In case it is a user VM, we see in the logs that the state will be set to 
> powered-off, but the VM keeps running. After a while a new VM power state 
> report is running and the state for the user VM gets updated to Running 
> again. Below the logs 
> h2. VR  r-342-VM reboot log
> {code:none}
> 2015-09-15 09:37:06,508 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
> (DirectAgentCronJob-253:ctx-c4f59216) Run missing VM report. current time: 
> 1442302626508
> 2015-09-15 09:37:06,508 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
> (DirectAgentCronJob-253:ctx-c4f59216) Detected missing VM. host: 19, vm id: 
> 342, power state: PowerReportMissing, last state update: 1442302506000
> 2015-09-15 09:37:06,508 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
> (DirectAgentCronJob-253:ctx-c4f59216) vm id: 342 - time since last state 
> update(120508ms) has passed graceful period
> 2015-09-15 09:37:06,517 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
> (DirectAgentCronJob-253:ctx-c4f59216) VM state report is updated. host: 19, 
> vm id: 342, power state: PowerReportMissing 
> 2015-09-15 09:37:06,525 INFO  [c.c.v.VirtualMachineManagerImpl] 
> (DirectAgentCronJob-253:ctx-c4f59216) VM r-342-VM is at Running and we 
> received a power-off report while there is no pending jobs on it
> 2015-09-15 09:37:06,532 DEBUG [c.c.a.t.Request] 
> (DirectAgentCronJob-253:ctx-c4f59216) Seq 19-4511199451741686482: Sending  { 
> Cmd , MgmtId: 345051122106, via: 19(cu01-testpod01-esx03.stxt.media.int), 
> Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"checkBeforeCleanup":true,"vmName":"r-342-VM","wait":0}}]
>  }
> 2015-09-15 09:37:06,532 DEBUG [c.c.a.t.Request] 
> (DirectAgentCronJob-253:ctx-c4f59216) Seq 19-4511199451741686482: Executing:  
> { Cmd , MgmtId: 345051122106, via: 19(cu01-testpod01-esx03.stxt.media.int), 
> Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"checkBeforeCleanup":true,"vmName":"r-342-VM","wait":0}}]
>  }
> 2015-09-15 09:37:06,532 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-136:ctx-9bc0a401) Seq 19-4511199451741686482: Executing request
> 2015-09-15 09:37:06,532 INFO  [c.c.h.v.r.VmwareResource] 
> (DirectAgent-136:ctx-9bc0a401 cu01-testpod01-esx03.stxt.media.int, cmd: 
> StopCommand) Executing resource StopCommand: 
>

[jira] [Commented] (CLOUDSTACK-8901) PrepareTemplate job thread hard-coded to max 8 threads

2015-09-29 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934999#comment-14934999
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8901:


Github user koushik-das commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/880#discussion_r40658483
  
--- Diff: server/src/com/cloud/template/TemplateManagerImpl.java ---
@@ -278,6 +278,8 @@
 @Inject
 private EndPointSelector selector;
 
+protected final ConfigKey TemplatePreloaderPoolSize = new 
ConfigKey("Advanced", Integer.class, "template.preloader.pool.size", 
"8", "Size of the TemplateManager threadpool", false);
--- End diff --

@SudharmaJain You have to implement the Configurable interface. Check for 
its usage in code.


> PrepareTemplate job thread hard-coded to max 8 threads
> --
>
> Key: CLOUDSTACK-8901
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8901
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>
>  The thread pool is hardcoded to use 8 threads,
> com.cloud.template.TemplateManagerImpl.configure(String, Map):
> _preloadExecutor = Executors.newFixedThreadPool(8, new 
> NamedThreadFactory("Template-Preloader"));
> Need to make it configurable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-8249) Dockerize CloudStack deployment

2015-09-29 Thread sebastien goasguen (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

sebastien goasguen resolved CLOUDSTACK-8249.

Resolution: Fixed

> Dockerize CloudStack deployment
> ---
>
> Key: CLOUDSTACK-8249
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8249
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
> Environment: linux, python, docker, sys admin knowledge
>Reporter: sebastien goasguen
>Assignee: Pierre-Luc Dion
>  Labels: gsoc2015
>
> CloudStack like any IaaS can be daunting to install.
> I propose to Dockerize the entire deployment process. There is already a few 
> docker images for the simulator. The project will consist of two steps:
> 1-Dockerize the mgt server, including separate container for the MySQl DB and 
> the usage server.
> 2-Dockerize the agent (assuming KVM ). Potentially even run KVM with Docker 
> to contain everything.
> 3-Setup a self discovery mechanism with tools like register, confd, or etcd.
> 4-Automatically configure CloudStack based on self-registered services.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CLOUDSTACK-8920) KVM agent cannot communicate with server on port 8250

2015-09-29 Thread Erik Weber (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14935045#comment-14935045
 ] 

Erik Weber edited comment on CLOUDSTACK-8920 at 9/29/15 12:05 PM:
--

I had something similar once, not long ago, where it turned out to be an out of 
date ssl library causing trouble.
Have you checked that there aren't any packages available for update on both 
the host and mgmt server?


edit: 
In particular, this post helped me resolve it: 
http://blog.backslasher.net/java-ssl-crash.html


was (Author: webern):
I had something similar once, not long ago, where it turned out to be an out of 
date ssl library causing trouble.
Have you checked that there aren't any packages available for update on both 
the host and mgmt server?

> KVM agent cannot communicate with server on port 8250
> -
>
> Key: CLOUDSTACK-8920
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8920
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Install and Setup
>Affects Versions: 4.5.2
> Environment: CentOS 6.7, OpenJDK 1.7.0
>Reporter: Noel D. Kendall
>Priority: Blocker
>
> Attempting to add a KVM host, the management server is able to reach the 
> target host via SSH and successfully changes agent.properties, and restarts 
> the agent process. All that works fine. Zone, Pod and Cluster are configured 
> successfully.
> Problem is occurring on the agent when attempting to contact the management 
> server on port 8250. Getting an ERROR logged, unable to initialize the 
> threads, with an IOException -1 connection closed with -1 on reading size.
> This sounds suspiciously like an SSL client is attempting to connect to a 
> non-SSL server. For the life of me, I cannot see how this is configured or 
> misconfigured.
> I have created SSL certificates for the proxies, and successfully uploaded 
> these, following the documentation. Not sure this is related in any way or 
> not.
> Have turned on full debugging log output in log4j, not seeing any elaboration 
> on the underlying cause of the problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8923) Create storage network IP range failed, Unknown parameters : zoneid

2015-09-29 Thread Nux (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14935315#comment-14935315
 ] 

Nux commented on CLOUDSTACK-8923:
-

Thanks.

I also tried to register the sstorage ip range from cloudmonkey and the command 
just hangs while the logs shows this:





2015-09-29 16:18:25,164 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(catalina-exec-5:ctx-75d67245 ctx-d9c25804 ctx-92cd5bf7) submit async job-57, 
details: AsyncJobVO {id:57, userId: 2, accountId: 2, instanceType: None, 
instanceId: null, cmd: 
org.apache.cloudstack.api.command.admin.network.CreateStorageNetworkIpRangeCmd, 
cmdInfo: 
{"cmdEventType":"STORAGE.IP.RANGE.CREATE","ctxUserId":"2","gateway":"192.168.200.67","startip":"192.168.200.200","signatureversion":"3","httpmethod":"GET","apiKey":"VFeDEr5-7F5wUAOvWF_maHVCVAWtB4jsamwmRtVW-uZ_loAlhJrr4nxWA6NSK_aSyx5d-Yw8NNRPPu9ZA4or3Q","netmask":"255.255.255.0","endip":"192.168.200.222","response":"json","ctxDetails":"{\"interface
 
com.cloud.dc.Pod\":\"6fecf11a-964d-4f3c-aebf-3789219851eb\"}","expires":"2015-09-29T15:28:25+","podid":"6fecf11a-964d-4f3c-aebf-3789219851eb","vlan":"123","ctxAccountId":"2","ctxStartEventId":"145","signature":"rvKcpURy33J46Fm+9ioEs/F5NtA\u003d"},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}
2015-09-29 16:18:25,164 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-55:ctx-80eac47e job-57) Executing AsyncJobVO {id:57, userId: 
2, accountId: 2, instanceType: None, instanceId: null, cmd: 
org.apache.cloudstack.api.command.admin.network.CreateStorageNetworkIpRangeCmd, 
cmdInfo: 
{"cmdEventType":"STORAGE.IP.RANGE.CREATE","ctxUserId":"2","gateway":"192.168.200.67","startip":"192.168.200.200","signatureversion":"3","httpmethod":"GET","apiKey":"VFeDEr5-7F5wUAOvWF_maHVCVAWtB4jsamwmRtVW-uZ_loAlhJrr4nxWA6NSK_aSyx5d-Yw8NNRPPu9ZA4or3Q","netmask":"255.255.255.0","endip":"192.168.200.222","response":"json","ctxDetails":"{\"interface
 
com.cloud.dc.Pod\":\"6fecf11a-964d-4f3c-aebf-3789219851eb\"}","expires":"2015-09-29T15:28:25+","podid":"6fecf11a-964d-4f3c-aebf-3789219851eb","vlan":"123","ctxAccountId":"2","ctxStartEventId":"145","signature":"rvKcpURy33J46Fm+9ioEs/F5NtA\u003d"},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}
2015-09-29 16:18:25,164 DEBUG [c.c.a.ApiServlet] (catalina-exec-5:ctx-75d67245 
ctx-d9c25804 ctx-92cd5bf7) ===END===  192.168.192.198 -- GET  
endip=192.168.200.222=3=VFeDEr5-7F5wUAOvWF_maHVCVAWtB4jsamwmRtVW-uZ_loAlhJrr4nxWA6NSK_aSyx5d-Yw8NNRPPu9ZA4or3Q=6fecf11a-964d-4f3c-aebf-3789219851eb=192.168.200.200=123=2015-09-29T15%3A28%3A25%2B=json=255.255.255.0=createStorageNetworkIpRange=rvKcpURy33J46Fm%2B9ioEs%2FF5NtA%3D=192.168.200.67
2015-09-29 16:18:25,183 WARN  [o.a.c.a.c.a.n.CreateStorageNetworkIpRangeCmd] 
(API-Job-Executor-55:ctx-80eac47e job-57 ctx-529486a0) Create storage network 
IP range failed
com.cloud.utils.exception.CloudRuntimeException: Unable to commit or close the 
connection. 
at 
com.cloud.utils.db.TransactionLegacy.commit(TransactionLegacy.java:730)
at com.cloud.utils.db.Transaction.execute(Transaction.java:46)
at 
com.cloud.network.StorageNetworkManagerImpl.createIpRange(StorageNetworkManagerImpl.java:229)
at 
org.apache.cloudstack.api.command.admin.network.CreateStorageNetworkIpRangeCmd.execute(CreateStorageNetworkIpRangeCmd.java:118)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150)
at 
com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
at 
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:537)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at 
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:494)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at

[jira] [Commented] (CLOUDSTACK-8923) Create storage network IP range failed, Unknown parameters : zoneid

2015-09-29 Thread Nux (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14935338#comment-14935338
 ] 

Nux commented on CLOUDSTACK-8923:
-

Here's a video of how I do the UI thing. Pretty standard really, I've done this 
a hundred times.
http://tmp.nux.ro/vV7-vokoscreen-2015-09-29_15-32-19-2.mkv

> Create storage network IP range failed, Unknown parameters : zoneid
> ---
>
> Key: CLOUDSTACK-8923
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8923
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage
>Affects Versions: 4.6.0
> Environment: CentOS 6 HVs and MGMT
>Reporter: Nux
>Priority: Blocker
>
> I am installing ACS from today's master (3ded3e9 
> http://tmp.nux.ro/acs460snap/ ). 
> Adding an initial zone via the web UI wizard fails at the secondary storage 
> setup stage:
> 2015-09-29 14:07:40,319 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
> (API-Job-Executor-25:ctx-73c1ad88 job-27) Add job-27 into job monitoring
> 2015-09-29 14:07:40,322 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-5:ctx-314bbaae ctx-2db63923) ===END===  85.13.192.198 -- GET  
> command=createStorageNetworkIpRange=json=192.168.200.67=255.255.255.0=123=192.168.200.200=192.168.200.222=2f0efdcf-adf6-4373-858e-87de6af4cc08=eb7814d2-9a22-4ca4-93af-4a6b8abac67c&_=1443532060283
> 2015-09-29 14:07:40,327 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-25:ctx-73c1ad88 job-27) Executing AsyncJobVO {id:27, 
> userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd: 
> org.apache.cloudstack.api.command.admin.network.CreateStorageNetworkIpRangeCmd,
>  cmdInfo: {"response":"json","ctxDetails":"{\"interface 
> com.cloud.dc.Pod\":\"eb7814d2-9a22-4ca4-93af-4a6b8abac67c\"}","cmdEventType":"STORAGE.IP.RANGE.CREATE","ctxUserId":"2","gateway":"192.168.200.67","podid":"eb7814d2-9a22-4ca4-93af-4a6b8abac67c","zoneid":"2f0efdcf-adf6-4373-858e-87de6af4cc08","startip":"192.168.200.200","vlan":"123","httpmethod":"GET","_":"1443532060283","ctxAccountId":"2","ctxStartEventId":"68","netmask":"255.255.255.0","endip":"192.168.200.222"},
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: null}
> 2015-09-29 14:07:40,330 WARN  [c.c.a.d.ParamGenericValidationWorker] 
> (API-Job-Executor-25:ctx-73c1ad88 job-27 ctx-1fa03c4a) Received unknown 
> parameters for command createStorageNetworkIpRange. Unknown parameters : 
> zoneid
> 2015-09-29 14:07:40,391 WARN  [o.a.c.a.c.a.n.CreateStorageNetworkIpRangeCmd] 
> (API-Job-Executor-25:ctx-73c1ad88 job-27 ctx-1fa03c4a) Create storage network 
> IP range failed
> com.cloud.utils.exception.CloudRuntimeException: Unable to commit or close 
> the connection. 
>   at 
> com.cloud.utils.db.TransactionLegacy.commit(TransactionLegacy.java:730)
>   at com.cloud.utils.db.Transaction.execute(Transaction.java:46)
>   at 
> com.cloud.network.StorageNetworkManagerImpl.createIpRange(StorageNetworkManagerImpl.java:229)
>   at 
> org.apache.cloudstack.api.command.admin.network.CreateStorageNetworkIpRangeCmd.execute(CreateStorageNetworkIpRangeCmd.java:118)
>   at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150)
>   at 
> com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
>   at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:537)
>   at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
>   at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
>   at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
>   at 
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
>   at 
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
>   at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:494)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.sql.SQLException: Connection is closed.
>   at 
>

[jira] [Commented] (CLOUDSTACK-8923) Create storage network IP range failed, Unknown parameters : zoneid

2015-09-29 Thread Remi Bergsma (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14935236#comment-14935236
 ] 

Remi Bergsma commented on CLOUDSTACK-8923:
--

Hi [~nuxro] ! I am unable to reproduce but of course there still could be a 
problem. Can you let me know what info you supply in the wizard? Then I'm going 
to do exactly the same to see if we can find the issue.

Every PR I test I build from scratch and deploy a new CloudStack environment. 
That works fine.

Let's find the difference!

The error is thrown here: 
api/src/org/apache/cloudstack/api/command/admin/network/CreateStorageNetworkIpRangeCmd.java



@Override   
 
115 public void execute() throws ResourceUnavailableException, 
InsufficientCapacityException, ServerApiException, ConcurrentOperationException,
116 ResourceAllocationException {   
 
117 try {   
 
118 StorageNetworkIpRange result = 
_storageNetworkService.createIpRange(this);
119 StorageNetworkIpRangeResponse response = 
_responseGenerator.createStorageNetworkIpRangeResponse(result);
120 response.setResponseName(getCommandName()); 
 
121 this.setResponseObject(response);   
 
122 } catch (Exception e) { 
 
123 s_logger.warn("Create storage network IP range failed", e); 
 
124 throw new ServerApiException(ApiErrorCode.INTERNAL_ERROR, 
e.getMessage());
125 }   
 
126 }   
 
127 


> Create storage network IP range failed, Unknown parameters : zoneid
> ---
>
> Key: CLOUDSTACK-8923
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8923
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage
>Affects Versions: 4.6.0
> Environment: CentOS 6 HVs and MGMT
>Reporter: Nux
>Priority: Blocker
>
> I am installing ACS from today's master (3ded3e9 
> http://tmp.nux.ro/acs460snap/ ). 
> Adding an initial zone via the web UI wizard fails at the secondary storage 
> setup stage:
> 2015-09-29 14:07:40,319 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
> (API-Job-Executor-25:ctx-73c1ad88 job-27) Add job-27 into job monitoring
> 2015-09-29 14:07:40,322 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-5:ctx-314bbaae ctx-2db63923) ===END===  85.13.192.198 -- GET  
> command=createStorageNetworkIpRange=json=192.168.200.67=255.255.255.0=123=192.168.200.200=192.168.200.222=2f0efdcf-adf6-4373-858e-87de6af4cc08=eb7814d2-9a22-4ca4-93af-4a6b8abac67c&_=1443532060283
> 2015-09-29 14:07:40,327 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-25:ctx-73c1ad88 job-27) Executing AsyncJobVO {id:27, 
> userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd: 
> org.apache.cloudstack.api.command.admin.network.CreateStorageNetworkIpRangeCmd,
>  cmdInfo: {"response":"json","ctxDetails":"{\"interface 
> com.cloud.dc.Pod\":\"eb7814d2-9a22-4ca4-93af-4a6b8abac67c\"}","cmdEventType":"STORAGE.IP.RANGE.CREATE","ctxUserId":"2","gateway":"192.168.200.67","podid":"eb7814d2-9a22-4ca4-93af-4a6b8abac67c","zoneid":"2f0efdcf-adf6-4373-858e-87de6af4cc08","startip":"192.168.200.200","vlan":"123","httpmethod":"GET","_":"1443532060283","ctxAccountId":"2","ctxStartEventId":"68","netmask":"255.255.255.0","endip":"192.168.200.222"},
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 266785867798693, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: null}
> 2015-09-29 14:07:40,330 WARN  [c.c.a.d.ParamGenericValidationWorker] 
> (API-Job-Executor-25:ctx-73c1ad88 job-27 ctx-1fa03c4a) Received unknown 
> parameters for command createStorageNetworkIpRange. Unknown parameters : 
> zoneid
> 2015-09-29 14:07:40,391 WARN  [o.a.c.a.c.a.n.CreateStorageNetworkIpRangeCmd] 
> (API-Job-Executor-25:ctx-73c1ad88 job-27 ctx-1fa03c4a) Create storage network 
> IP range failed
> com.cloud.utils.exception.CloudRuntimeException: Unable to commit or close 
> the connection. 
>   at 
> com.cloud.utils.db.TransactionLegacy.commit(TransactionLegacy.java:730)
>   at com.cloud.utils.db.Transaction.execute(Transaction.java:46)
>   at 
>

[jira] [Commented] (CLOUDSTACK-8901) PrepareTemplate job thread hard-coded to max 8 threads

2015-09-29 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936342#comment-14936342
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8901:


Github user SudharmaJain commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/880#discussion_r40756846
  
--- Diff: setup/db/db/schema-452to460.sql ---
@@ -413,3 +413,6 @@ CREATE TABLE `cloud`.`ldap_trust_map` (
   UNIQUE KEY `uk_ldap_trust_map__domain_id` (`domain_id`),
   CONSTRAINT `fk_ldap_trust_map__domain_id` FOREIGN KEY (`domain_id`) 
REFERENCES `domain` (`id`)
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
+
+INSERT IGNORE INTO `cloud`.`configuration` VALUES ('Advanced', 'DEFAULT', 
'TemplateManager', 'template.preloader.pool.size', '8', 'Size of the threadpool 
for preparetemplate api', '8', NULL, 'Global', 0);
--- End diff --

@koushik-das Implemented Configurable interface.


> PrepareTemplate job thread hard-coded to max 8 threads
> --
>
> Key: CLOUDSTACK-8901
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8901
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>
>  The thread pool is hardcoded to use 8 threads,
> com.cloud.template.TemplateManagerImpl.configure(String, Map):
> _preloadExecutor = Executors.newFixedThreadPool(8, new 
> NamedThreadFactory("Template-Preloader"));
> Need to make it configurable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8911) VM start job got stuck in loop looking for suitable host

2015-09-29 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936327#comment-14936327
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8911:


Github user SudharmaJain commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/895#discussion_r40755936
  
--- Diff: 
server/src/com/cloud/agent/manager/allocator/impl/FirstFitAllocator.java ---
@@ -297,6 +297,7 @@
 s_logger.debug("Host name: " + host.getName() + ", 
hostId: " + host.getId() +
 " already has max Running VMs(count includes 
system VMs), skipping this and trying other available hosts");
 }
+avoid.addHost(host.getId());
--- End diff --

@koushik-das I have added the change for GPU device as well.


> VM start job got stuck in loop looking for suitable host
> 
>
> Key: CLOUDSTACK-8911
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8911
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.3.0
>Reporter: sudharma jain
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-8864) Not able to add TCP port forwarding rule in VPN for specific ports

2015-09-29 Thread Rajani Karuturi (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajani Karuturi updated CLOUDSTACK-8864:

Assignee: sudharma jain

> Not able to add TCP port forwarding rule in VPN for specific ports
> --
>
> Key: CLOUDSTACK-8864
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8864
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.3.0
>Reporter: sudharma jain
>Assignee: sudharma jain
>
> Port forwading rule for ports 500,1701 and 4500 can't be added when a VPN is 
> configured. Trying to add a rule gives following error.
> "The range specified, , conflicts with rule  which has 500-500."



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-8891) Isolated network VR default iptables rules in INPUT chain are missing

2015-09-29 Thread Rajani Karuturi (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajani Karuturi resolved CLOUDSTACK-8891.
-
Resolution: Fixed

> Isolated network VR default iptables rules in INPUT chain are missing
> -
>
> Key: CLOUDSTACK-8891
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8891
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.6.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
> Fix For: 4.6.0
>
>
> Repro steps:
> 1.Create a advance zone setup
> 2. Create a VM in isolated network
> Bug
> VM is not assigned its guest ip as dhcp port in router is not open
> Also dns, http ports missing.
> iptables -L INPUT -nvx
> Chain INPUT (policy DROP 1330 packets, 79806 bytes)
> pkts bytes target prot opt in out source dest ination
> 1616 116814 NETWORK_STATS all – * * 0.0.0.0/0 0. 0.0.0/0
> 0 0 ACCEPT all – * * 0.0.0.0/0 224.0. 0.18
> 0 0 ACCEPT all – * * 0.0.0.0/0 225.0. 0.50
> 0 0 ACCEPT all – eth2 * 0.0.0.0/0 0.0.0. 0/0 state RELATED,ESTABLISHED
> 0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0. 0/0
> 4 730 ACCEPT all – lo * 0.0.0.0/0 0.0.0. 0/0
> 255 34874 ACCEPT tcp – eth1 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:3922 state 
> NEW,ESTABLISHED
> 0 0 ACCEPT all – * * 0.0.0.0/0 224.0. 0.18
> 0 0 ACCEPT all – * * 0.0.0.0/0 225.0. 0.50
> 0 0 ACCEPT all – eth2 * 0.0.0.0/0 0.0.0. 0/0 state RELATED,ESTABLISHED
> 0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0. 0/0
> 0 0 ACCEPT all – lo * 0.0.0.0/0 0.0.0. 0/0
> 0 0 ACCEPT tcp – eth1 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:3922 state 
> NEW,ESTABLISHED
> 0 0 ACCEPT all – * * 0.0.0.0/0 224.0. 0.18
> 0 0 ACCEPT all – * * 0.0.0.0/0 225.0. 0.50
> 0 0 ACCEPT all – eth2 * 0.0.0.0/0 0.0.0. 0/0 state RELATED,ESTABLISHED
> 0 0 ACCEPT icmp – * * 0.0.0.0/0 0.0.0. 0/0
> 0 0 ACCEPT all – lo * 0.0.0.0/0 0.0.0. 0/0
> 0 0 ACCEPT tcp – eth1 * 0.0.0.0/0 0.0.0. 0/0 tcp dpt:3922 state 
> NEW,ESTABLISHED



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-8876) VPC tier network restart, missing ip on VR interface

2015-09-29 Thread Rajani Karuturi (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajani Karuturi updated CLOUDSTACK-8876:

Priority: Blocker  (was: Major)

>  VPC tier network restart, missing ip on VR interface
> -
>
> Key: CLOUDSTACK-8876
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8876
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Affects Versions: 4.5.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>Priority: Blocker
> Fix For: 4.6.0
>
>
> Reproducing steps:
> 1. Create a vpc and deploy a vm in tier.
> 2. Acquire a public ip and configure PF rule
> 3. check that the VR interface has two ip addresses.
> 4. Restart the tier network with cleanup.
> 5. After restart in VR interface ip (PF rule configured) is missed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8876) VPC tier network restart, missing ip on VR interface

2015-09-29 Thread Jayapal Reddy (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936389#comment-14936389
 ] 

Jayapal Reddy commented on CLOUDSTACK-8876:
---

Below is the fix diff for this issue. I don't have the time to run the tests on 
it. I am unassinging it, some one can pick it up.


diff --git a/server/src/com/cloud/network/IpAddressManagerImpl.java 
b/server/src/com/cloud/network/IpAddressManagerImpl.java
index 28df971..46e0614 100644
--- a/server/src/com/cloud/network/IpAddressManagerImpl.java
+++ b/server/src/com/cloud/network/IpAddressManagerImpl.java
@@ -456,6 +456,12 @@ public class IpAddressManagerImpl extends ManagerBase 
implements IpAddressManage
 }
 } else {
 if (activeCount != null && activeCount > 0) {
+if (network.getVpcId() != null) {
+// If there are more than one ip in the vpc tier 
network and services configured on it.
+// restart network with cleanup case, on network 
reprogramming this needs to be return true
+// because on the VR ips has removed.
+return true;
+}
 continue;
 } else if (addCount != null && addCount.longValue() == 
totalCount.longValue()) {
 s_logger.trace("All rules are in Add state, have to 
assiciate IP with the backend");

>  VPC tier network restart, missing ip on VR interface
> -
>
> Key: CLOUDSTACK-8876
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8876
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Affects Versions: 4.5.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>Priority: Blocker
> Fix For: 4.6.0
>
>
> Reproducing steps:
> 1. Create a vpc and deploy a vm in tier.
> 2. Acquire a public ip and configure PF rule
> 3. check that the VR interface has two ip addresses.
> 4. Restart the tier network with cleanup.
> 5. After restart in VR interface ip (PF rule configured) is missed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (CLOUDSTACK-8876) VPC tier network restart, missing ip on VR interface

2015-09-29 Thread Wilder Rodrigues (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wilder Rodrigues reassigned CLOUDSTACK-8876:


Assignee: Wilder Rodrigues  (was: Jayapal Reddy)

>  VPC tier network restart, missing ip on VR interface
> -
>
> Key: CLOUDSTACK-8876
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8876
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Affects Versions: 4.5.0
>Reporter: Jayapal Reddy
>Assignee: Wilder Rodrigues
>Priority: Blocker
> Fix For: 4.6.0
>
>
> Reproducing steps:
> 1. Create a vpc and deploy a vm in tier.
> 2. Acquire a public ip and configure PF rule
> 3. check that the VR interface has two ip addresses.
> 4. Restart the tier network with cleanup.
> 5. After restart in VR interface ip (PF rule configured) is missed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-8876) VPC tier network restart, missing ip on VR interface

2015-09-29 Thread Wilder Rodrigues (JIRA) 

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936390#comment-14936390
 ] 

Wilder Rodrigues commented on CLOUDSTACK-8876:
--

Since I'm busy with the rVPC, I will also take a look at that one.

Cheers,
Wilder

>  VPC tier network restart, missing ip on VR interface
> -
>
> Key: CLOUDSTACK-8876
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8876
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices
>Affects Versions: 4.5.0
>Reporter: Jayapal Reddy
>Assignee: Wilder Rodrigues
>Priority: Blocker
> Fix For: 4.6.0
>
>
> Reproducing steps:
> 1. Create a vpc and deploy a vm in tier.
> 2. Acquire a public ip and configure PF rule
> 3. check that the VR interface has two ip addresses.
> 4. Restart the tier network with cleanup.
> 5. After restart in VR interface ip (PF rule configured) is missed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-8863) VM doesn't reconnect to internet post VR RESTART/STOP-START/RECREATE

2015-09-29 Thread Rajani Karuturi (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajani Karuturi updated CLOUDSTACK-8863:

Assignee: sudharma jain

> VM doesn't reconnect to internet post VR RESTART/STOP-START/RECREATE
> 
>
> Key: CLOUDSTACK-8863
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8863
> 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: sudharma jain
>Assignee: sudharma jain
> Fix For: Future
>
>
> The ongoing ICMP request reply session is broken when the VR is down, the 
> expectation is that it would resume once the VR is up. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-8864) Not able to add TCP port forwarding rule in VPN for specific ports

2015-09-29 Thread Rajani Karuturi (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajani Karuturi updated CLOUDSTACK-8864:

Fix Version/s: 4.6.0

> Not able to add TCP port forwarding rule in VPN for specific ports
> --
>
> Key: CLOUDSTACK-8864
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8864
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.3.0
>Reporter: sudharma jain
>Assignee: sudharma jain
> Fix For: 4.6.0
>
>
> Port forwading rule for ports 500,1701 and 4500 can't be added when a VPN is 
> configured. Trying to add a rule gives following error.
> "The range specified, , conflicts with rule  which has 500-500."



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-8864) Not able to add TCP port forwarding rule in VPN for specific ports

2015-09-29 Thread Rajani Karuturi (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajani Karuturi resolved CLOUDSTACK-8864.
-
Resolution: Fixed

> Not able to add TCP port forwarding rule in VPN for specific ports
> --
>
> Key: CLOUDSTACK-8864
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8864
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.3.0
>Reporter: sudharma jain
>Assignee: sudharma jain
> Fix For: 4.6.0
>
>
> Port forwading rule for ports 500,1701 and 4500 can't be added when a VPN is 
> configured. Trying to add a rule gives following error.
> "The range specified, , conflicts with rule  which has 500-500."



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (CLOUDSTACK-8863) VM doesn't reconnect to internet post VR RESTART/STOP-START/RECREATE

2015-09-29 Thread Rajani Karuturi (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajani Karuturi resolved CLOUDSTACK-8863.
-
   Resolution: Fixed
Fix Version/s: (was: Future)
   4.6.0

> VM doesn't reconnect to internet post VR RESTART/STOP-START/RECREATE
> 
>
> Key: CLOUDSTACK-8863
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8863
> 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: sudharma jain
>Assignee: sudharma jain
> Fix For: 4.6.0
>
>
> The ongoing ICMP request reply session is broken when the VR is down, the 
> expectation is that it would resume once the VR is up. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)