[jira] [Commented] (CLOUDSTACK-4177) F5-SRX-Inline: User is charged with more usages charges in case of F5-SRX-Inline mode

[Kishan Kavala (JIRA)]

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

Kishan Kavala commented on CLOUDSTACK-4177:
---

This is as per design in earlier releases. The stats are reported separately 
for LB and FW in inline mode also. Users will still have the flexibility to 
pick only one as per his requirement. We can revisit the design in next release

> F5-SRX-Inline: User is charged with more usages charges in case of 
> F5-SRX-Inline mode
> -
>
> Key: CLOUDSTACK-4177
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4177
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.2.0
>Reporter: Kishan Kavala
> Fix For: Future
>
>
> F5-SRX-Inline: current_bytes_sent is not updated in user_statistics table in 
> case of LB
> Steps to Reproduce:
> ===
> Bringup Advanced zone setup with at-least
> 1. Create a NO using SRX for PF,Static NAT, Source Nat (Zone wide) and F5 for 
> LB with "Share" LB Isolation mode and "Inline" mode and rest of the services 
> are provided by VR.
> 2. Add SRX device
> 3. Add F5 device 
> 4.Deploy couple of guest vms using above NO
> 5.Acquire one public IP address and configure LB and assign both the guest 
> vms created at step4 to it.
> 6.Open firewall ports to allow the traffic
> 7.Generate some traffic using public IP address acquired.
> 8.Wait for the ExternalNetworkUsageCmd to execute , 
> ExternalNetworkUsageAnswer will be received. Verify the stats present in the 
> usage answer received and stats added to user_statistics table.
> Observations:
> ===
> Following is the usage answer received from F5 device:
> 2012-12-10 15:12:33,318 DEBUG [agent.transport.Request] 
> (DirectAgent-256:null) Seq 5-434569246: Processing:  { Ans: , MgmtId: 
> 6896543072287, via: 5, Ver: v1, Flags: 10, 
> [{"ExternalNetworkResourceUsageAnswer":{"ipBytes":{"10.147.52.236":[2845,4458],"10.0.144.174":[986,864]},"guestVlanBytes":{},"result":true,"wait":0}}]
>  }
> 10.0.144.174 is the guest IP selected on configured for LB on F5.
> mysql> select * from user_statistics where device_type="ExternalLoadBalancer";
> ++++---+---+--++++++++
> | id | data_center_id | account_id | public_ip_address | device_id | 
> device_type  | network_id | net_bytes_received | net_bytes_sent | 
> current_bytes_received | current_bytes_sent | agg_bytes_received | 
> agg_bytes_sent |
> ++++---+---+--++++++++
> |  3 |  1 |  2 | 10.147.48.6   | 5 | 
> ExternalLoadBalancer |204 |  0 |  0 | 
>864 |  0 |  0 |  0 
> |
> ++++---+---+--++++++++
> 1 row in set (0.00 sec)
> Above table shows current_bytes-received as 864 and current_bytes_sent as 0 
> whereas usage answer shows both "10.0.144.174":[986,864]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-4136) [upgraded ENV]Deleting Snapshot which was created before upgrade is throwing NPE.

[Koushik Das (JIRA)]

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

Koushik Das commented on CLOUDSTACK-4136:
-

The code has some issue and I have fixed that.
Also as can be seen from the db dumps before and after upgrade the 
'snapshot_store_ref' table is not appropriately populated from entries in the 
'snapshots' table. I looked at the Upgrade410to420.java upgrade logic and based 
on that the following should have run and populated the snapshot_store_ref. 
Please upload the management server logs as well during upgrade.

INSERT INTO `cloud`.`snapshot_store_ref` (store_id,  snapshot_id, created, 
size, parent_snapshot_id, install_path, volume_id, update_count, ref_cnt, 
store_role, state) select sechost_id, id, created, size, prev_snap_id, 
CONCAT('snapshots', '/', account_id, '/', volume_id, '/', backup_snap_id), 
volume_id, 0, 0, 'Image', 'Ready' from `cloud`.`snapshots` where status = 
'BackedUp' and sechost_id is not null and removed is null;

 

> [upgraded ENV]Deleting Snapshot which was created before upgrade is throwing 
> NPE.
> -
>
> Key: CLOUDSTACK-4136
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4136
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller, Upgrade
>Affects Versions: 4.2.0
> Environment: upgraded from 3.0.7 to 4.2
>Reporter: manasaveloori
>Assignee: Koushik Das
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.log.2013-08-06.zip, 
> management-server.zip, mysqldumpAfterUpnew.dmp, mysqldumpBeforeUp.dmp
>
>
> Steps:
> 1.Have CS with 3.0.7 build with VMware and Xen hypervisor.
> 2.Deploy a VM.
> 3.Create a snapshot of root volume.
> 4.Upgrade the build to 4.2.
> 5.Try to delete the snapshot now.
> Observing NPE while deleting the snapshot for the 1st time
> Tried to delete the same snapshot again deletes it. Verified the state of 
> snapshot in DB also.
> 2013-08-07 20:29:19,535 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null) 
> ===END===  10.252.192.69 -- GET  
> command=deleteSnapshot&id=acf6d258-99fa-4832-8499-a81a631627ce&response=json&sessionkey=uKcUJCauPB9Gj8yRMfQdmpPpTAE%3D&_=1375868166341
> 2013-08-07 20:29:19,539 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-43:job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]) 
> Executing org.apache.cloudstack.api.command.user.snapshot.DeleteSnapshotCmd 
> for job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]
> 2013-08-07 20:29:19,573 DEBUG [storage.snapshot.XenserverSnapshotStrategy] 
> (Job-Executor-43:job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]) Can't 
> find snapshot on backup storage, delete it in db
> 2013-08-07 20:29:19,582 DEBUG [storage.snapshot.SnapshotManagerImpl] 
> (Job-Executor-43:job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]) Failed 
> to delete snapshot: 1:java.lang.NullPointerException
> 2013-08-07 20:29:19,596 ERROR [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-43:job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]) 
> Unexpected exception while executing 
> org.apache.cloudstack.api.command.user.snapshot.DeleteSnapshotCmd
> com.cloud.utils.exception.CloudRuntimeException: Failed to delete 
> snapshot:java.lang.NullPointerException
> at 
> com.cloud.storage.snapshot.SnapshotManagerImpl.deleteSnapshot(SnapshotManagerImpl.java:508)
> at 
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at 
> org.apache.cloudstack.api.command.user.snapshot.DeleteSnapshotCmd.execute(DeleteSnapshotCmd.java:96)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at 
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-08-07 20:29:19,600 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-43:job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]) Complete 
> async job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ], jobStatus: 2, 
> resultCode: 530, result: Error Code: 530 Error text: Failed to delete 
> snapshot:java.lang.NullPointerExc

[jira] [Updated] (CLOUDSTACK-4136) [upgraded ENV]Deleting Snapshot which was created before upgrade is throwing NPE.

[manasaveloori (JIRA)]

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

manasaveloori updated CLOUDSTACK-4136:
--

Attachment: management-server.log.2013-08-06.zip

> [upgraded ENV]Deleting Snapshot which was created before upgrade is throwing 
> NPE.
> -
>
> Key: CLOUDSTACK-4136
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4136
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller, Upgrade
>Affects Versions: 4.2.0
> Environment: upgraded from 3.0.7 to 4.2
>Reporter: manasaveloori
>Assignee: Koushik Das
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.log.2013-08-06.zip, 
> management-server.zip, mysqldumpAfterUpnew.dmp, mysqldumpBeforeUp.dmp
>
>
> Steps:
> 1.Have CS with 3.0.7 build with VMware and Xen hypervisor.
> 2.Deploy a VM.
> 3.Create a snapshot of root volume.
> 4.Upgrade the build to 4.2.
> 5.Try to delete the snapshot now.
> Observing NPE while deleting the snapshot for the 1st time
> Tried to delete the same snapshot again deletes it. Verified the state of 
> snapshot in DB also.
> 2013-08-07 20:29:19,535 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null) 
> ===END===  10.252.192.69 -- GET  
> command=deleteSnapshot&id=acf6d258-99fa-4832-8499-a81a631627ce&response=json&sessionkey=uKcUJCauPB9Gj8yRMfQdmpPpTAE%3D&_=1375868166341
> 2013-08-07 20:29:19,539 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-43:job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]) 
> Executing org.apache.cloudstack.api.command.user.snapshot.DeleteSnapshotCmd 
> for job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]
> 2013-08-07 20:29:19,573 DEBUG [storage.snapshot.XenserverSnapshotStrategy] 
> (Job-Executor-43:job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]) Can't 
> find snapshot on backup storage, delete it in db
> 2013-08-07 20:29:19,582 DEBUG [storage.snapshot.SnapshotManagerImpl] 
> (Job-Executor-43:job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]) Failed 
> to delete snapshot: 1:java.lang.NullPointerException
> 2013-08-07 20:29:19,596 ERROR [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-43:job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]) 
> Unexpected exception while executing 
> org.apache.cloudstack.api.command.user.snapshot.DeleteSnapshotCmd
> com.cloud.utils.exception.CloudRuntimeException: Failed to delete 
> snapshot:java.lang.NullPointerException
> at 
> com.cloud.storage.snapshot.SnapshotManagerImpl.deleteSnapshot(SnapshotManagerImpl.java:508)
> at 
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at 
> org.apache.cloudstack.api.command.user.snapshot.DeleteSnapshotCmd.execute(DeleteSnapshotCmd.java:96)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at 
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-08-07 20:29:19,600 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-43:job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]) Complete 
> async job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ], jobStatus: 2, 
> resultCode: 530, result: Error Code: 530 Error text: Failed to delete 
> snapshot:java.lang.NullPointerException
> 2013-08-07 20:29:20,718 DEBUG [cloud.server.StatsCollector] 
> (StatsCollector-2:null) VmStatsCollector is running...
> Attaching the MS logs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CLOUDSTACK-4177) F5-SRX-Inline: User is charged with more usages charges in case of F5-SRX-Inline mode

[Kishan Kavala (JIRA)]

Kishan Kavala created CLOUDSTACK-4177:
-

 Summary: F5-SRX-Inline: User is charged with more usages charges 
in case of F5-SRX-Inline mode
 Key: CLOUDSTACK-4177
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4177
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.2.0
Reporter: Kishan Kavala
 Fix For: Future


F5-SRX-Inline: current_bytes_sent is not updated in user_statistics table in 
case of LB

Steps to Reproduce:
===
Bringup Advanced zone setup with at-least

1. Create a NO using SRX for PF,Static NAT, Source Nat (Zone wide) and F5 for 
LB with "Share" LB Isolation mode and "Inline" mode and rest of the services 
are provided by VR.
2. Add SRX device
3. Add F5 device 
4.Deploy couple of guest vms using above NO
5.Acquire one public IP address and configure LB and assign both the guest vms 
created at step4 to it.
6.Open firewall ports to allow the traffic
7.Generate some traffic using public IP address acquired.
8.Wait for the ExternalNetworkUsageCmd to execute , ExternalNetworkUsageAnswer 
will be received. Verify the stats present in the usage answer received and 
stats added to user_statistics table.

Observations:
===
Following is the usage answer received from F5 device:
2012-12-10 15:12:33,318 DEBUG [agent.transport.Request] (DirectAgent-256:null) 
Seq 5-434569246: Processing:  { Ans: , MgmtId: 6896543072287, via: 5, Ver: v1, 
Flags: 10, 
[{"ExternalNetworkResourceUsageAnswer":{"ipBytes":{"10.147.52.236":[2845,4458],"10.0.144.174":[986,864]},"guestVlanBytes":{},"result":true,"wait":0}}]
 }

10.0.144.174 is the guest IP selected on configured for LB on F5.

mysql> select * from user_statistics where device_type="ExternalLoadBalancer";
++++---+---+--++++++++
| id | data_center_id | account_id | public_ip_address | device_id | 
device_type  | network_id | net_bytes_received | net_bytes_sent | 
current_bytes_received | current_bytes_sent | agg_bytes_received | 
agg_bytes_sent |
++++---+---+--++++++++
|  3 |  1 |  2 | 10.147.48.6   | 5 | 
ExternalLoadBalancer |204 |  0 |  0 |   
 864 |  0 |  0 |  0 |
++++---+---+--++++++++
1 row in set (0.00 sec)

Above table shows current_bytes-received as 864 and current_bytes_sent as 0 
whereas usage answer shows both "10.0.144.174":[986,864]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-4111) [PortableIP][USABILITY] Prompt "Acquire New IP - Cross Zones - YES/NO" wizard only when there is portable IP range added at region level.

[Murali Reddy (JIRA)]

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

Murali Reddy commented on CLOUDSTACK-4111:
--

Its critical from usability perspective. Functionally there is no concern 
raised by this bug.

> [PortableIP][USABILITY] Prompt "Acquire New IP - Cross Zones - YES/NO" wizard 
> only when there is portable IP range added at region level.
> -
>
> Key: CLOUDSTACK-4111
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4111
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.2.0
> Environment: commit id # 9cd4e089a5798f422961940efbf8ae33ed906b87
>Reporter: venkata swamybabu budumuru
>Assignee: Murali Reddy
>Priority: Critical
> Fix For: 4.2.0
>
>
> Steps to reproduce:
> 1. Have latest CloudStack setup with at least one advanced zone.
> 2. Create an isolated network and deploy at least 1 VM using this network.
> 3. Go to Netoworks -> View IP Address -> Acquire IP Address 
> Observations:
> (i)Though there is no portable IP range at region level added in the above 
> steps, it still prompts for "Cross zones" wizard.
> (ii) Enable the above wizard only when there is portable IP ranged exists in 
> the system.
> (iii) This means, when there is no portable ip range and when user tries to 
> acquire an ip then we should send isPortable=False as part of the 
> associateIpAddress API.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-4158) [Performance Testing] List API performance in comparison to 4.1 is not as good

[Sowmya Krishnan (JIRA)]

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

Sowmya Krishnan commented on CLOUDSTACK-4158:
-

Enabled db trace logs for listAccounts API and shared it here: 
https://docs.google.com/file/d/0B4bEmJdK9DrfeHR1Um5TcER4NU0/edit?usp=sharing


> [Performance Testing] List API performance in comparison to 4.1 is not as good
> --
>
> Key: CLOUDSTACK-4158
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4158
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.2.0
> Environment: Simulator for creating mock resources, advanced zone, RVR
>Reporter: Sowmya Krishnan
>Assignee: Koushik Das
>Priority: Critical
> Fix For: 4.2.0
>
>
> Executed few List API calls for tracking performance runs for 4.2 and 
> compared the results with 4.1. Most APIs are taking noticeably longer as 
> compared to 4.1
> Examples:
> API  Time taken in 4.1   Time taken in 4.2
>   
> listAccounts  1m25.348s   2m22.628s
> listEvents 0m6.575s   0m20.277s
> Results so far are posted here (including comparitive results)
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Performance+Test+Execution+for+4.2
> Performance Test bed details:
> ===
> Management server:
> Processor
> Dual core Intel(R) Xeon(R) CPU processor, 2.27GHz, ht enabled, 4 processor
> Operating System
> CentOS release 5.5 (Final), x86_64
> Configuration Parameters
> Following config parameters were used in both the management servers
> -Java heap size = 5 GB
> -db.cloud.maxActive = 250
> - 
> db.cloud.url.params=prepStmtCacheSize=517&cachePrepStmts=true&prepStmtCacheSqlLimit=4096&includeInnodbStatusInDeadlockExceptions=true&logSlowQueries=true
> Setup:
> =
> Advanced zone, 2 Management Servers, 124 Pods [Each Pod having 2 Clusters]
> 248 Clusters [Each cluster having 8 hosts and one primary storage]
> 2000 Hosts
> 4000 User accounts [Each account having one network]
> 4000 User instances
> ~8000 Virtual Routers [Since we are using Redundant Virtual Router offering
> Didn't notice any slow queries logged in DB.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-4176) [XenServer] Nic not unplugged after all IPs are released

[Prasanna Santhanam (JIRA)]

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

Prasanna Santhanam updated CLOUDSTACK-4176:
---

Labels: integration-test  (was: )

> [XenServer] Nic not unplugged after all IPs are released 
> -
>
> Key: CLOUDSTACK-4176
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4176
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: XenServer
>Affects Versions: 4.2.0
>Reporter: Kishan Kavala
>  Labels: integration-test
> Fix For: 4.2.0
>
>
> Nic should be unplugged after all the public IPs assigned to it are released. 
> Currently nics are not being reused due to this bug.
> Code to set removeVif was removed
> else if (!add && firstIP) {
> /* FIXME: This is incorrect. Because you can only tell if 
> it's the first IP in this bundle of ip address which send to the router,
>  * but don't know if it's the only IP left in the router - 
> because we didn't send all the related vlan's IPs to the router now. */
> removeVif = true;
>  }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-4176) [XenServer] Nic not unplugged after all IPs are released

[Prasanna Santhanam (JIRA)]

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

Prasanna Santhanam updated CLOUDSTACK-4176:
---

Environment: (was: Nic should be unplugged after all the public IPs 
assigned to it are released. Currently nics are not being reused due to this 
bug.)

> [XenServer] Nic not unplugged after all IPs are released 
> -
>
> Key: CLOUDSTACK-4176
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4176
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: XenServer
>Affects Versions: 4.2.0
>Reporter: Kishan Kavala
> Fix For: 4.2.0
>
>
> Code to set removeVif was removed
> else if (!add && firstIP) {
> /* FIXME: This is incorrect. Because you can only tell if 
> it's the first IP in this bundle of ip address which send to the router,
>  * but don't know if it's the only IP left in the router - 
> because we didn't send all the related vlan's IPs to the router now. */
> removeVif = true;
>  }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-4176) [XenServer] Nic not unplugged after all IPs are released

[Prasanna Santhanam (JIRA)]

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

Prasanna Santhanam updated CLOUDSTACK-4176:
---

Description: 
Nic should be unplugged after all the public IPs assigned to it are released. 
Currently nics are not being reused due to this bug.

Code to set removeVif was removed
else if (!add && firstIP) {
/* FIXME: This is incorrect. Because you can only tell if it's 
the first IP in this bundle of ip address which send to the router,
 * but don't know if it's the only IP left in the router - 
because we didn't send all the related vlan's IPs to the router now. */
removeVif = true;
 }

  was:
Code to set removeVif was removed
else if (!add && firstIP) {
/* FIXME: This is incorrect. Because you can only tell if it's 
the first IP in this bundle of ip address which send to the router,
 * but don't know if it's the only IP left in the router - 
because we didn't send all the related vlan's IPs to the router now. */
removeVif = true;
 }


> [XenServer] Nic not unplugged after all IPs are released 
> -
>
> Key: CLOUDSTACK-4176
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4176
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: XenServer
>Affects Versions: 4.2.0
>Reporter: Kishan Kavala
> Fix For: 4.2.0
>
>
> Nic should be unplugged after all the public IPs assigned to it are released. 
> Currently nics are not being reused due to this bug.
> Code to set removeVif was removed
> else if (!add && firstIP) {
> /* FIXME: This is incorrect. Because you can only tell if 
> it's the first IP in this bundle of ip address which send to the router,
>  * but don't know if it's the only IP left in the router - 
> because we didn't send all the related vlan's IPs to the router now. */
> removeVif = true;
>  }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-4148) usage:usage stats are not triggered for shared network

[Murali Reddy (JIRA)]

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

Murali Reddy commented on CLOUDSTACK-4148:
--

In case shared network with L4-L7 services, it does make to gather usage stats. 
But current way we gather stat is per network. Since network is shared by 
multiple accounts, its not possible to split per account contribution to shared 
network usage stats.

I do not see easy way to fix this for 4.2. So marking this feature for future 
release.

> usage:usage stats are not triggered for shared network
> --
>
> Key: CLOUDSTACK-4148
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4148
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.2.0
>Reporter: sadhu suresh
>Assignee: Kishan Kavala
>Priority: Blocker
> Fix For: Future
>
> Attachments: management-server.rar
>
>
> steps:
> 1.create network offering with SRX and F5 
> 2.create a shared guestnetwork using above NO
> 3.deploy a VM using abobve network
> 4.generate the traffic and check the usage stats after 10 min
> actual:
> NetworkUsageCommand: is running only for isolated network and its not issuing 
> for  for sharednetwok.
> router-12 isbelongs to sharednetwork.
> r-4-0vm belongs to isloated network
> No query specified
> mysql> select * from user_statistics;
> ++++---+---+--++++++++
> | id | data_center_id | account_id | public_ip_address | device_id | 
> device_type  | network_id | net_bytes_received | net_bytes_sent | 
> current_bytes_received | current_bytes_sent | agg_bytes_received | 
> agg_bytes_sent |
> ++++---+---+--++++++++
> |  1 |  1 |  2 | NULL  | 4 | 
> DomainRouter |204 |  0 |  0 | 
>  0 | 401016 |  0 | 401016 |
> |  2 |  1 |  1 | NULL  |12 | 
> DomainRouter |206 |  0 |  0 | 
>  0 |  0 |  0 |  0 |
> |  3 |  1 |  1 | NULL  |18 | 
> DomainRouter |209 |  0 |  0 | 
>  0 |  0 |  0 |  0 |
> |  4 |  1 |  2 | 10.147.49.106 |21 | 
> DomainRouter |200 |  0 |  0 | 
>4195797 | 148136 |4195797 | 148136 |
> |  5 |  1 |  2 | NULL  |21 | 
> DomainRouter |210 |  0 |  0 | 
>  0 |  0 |  0 |  0 |
> ++++---+---+--++++++++
> 5 rows in set (0.00 sec)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Deleted] (CLOUDSTACK-4175) [KVM] [Upgrade from 2.2.14] Failed to delete and cleanup ROOT / DATA volumes from primary storage that were created prior to upgrade and marked for cl

[Kishan Kavala (JIRA)]

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

Kishan Kavala updated CLOUDSTACK-4175:
--

Comment: was deleted

(was: As per Anthony:
"resource code needs to make sure this is the last ip in this NIC, so the 
firstIP flag is useless.
ipassoc script needs to return if there are ip on this NIC, if no, unplug this 
nic")

>  [KVM] [Upgrade from 2.2.14] Failed to delete and cleanup ROOT / DATA volumes 
> from primary storage that were created prior to upgrade and marked for cleanup
> 
>
> Key: CLOUDSTACK-4175
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4175
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kishan Kavala
>
> Steps to reproduce :
> 1. Have 2.2.14 setup with KVM host and at least few vms deployed with ROOT 
> and DATA disks
> 2. Upgrade to 4.2
> 3. make sure storage.cleanup.interval is set to 300
> 4. Detach and Delete DATA / ROOT disks that were created before upgrade
> Observations :
> (i) It successfully deleted without any issues
> (ii) When storage GC is kicked in, it failed to cleanup those volumes because 
> these entities are still using path like 
> "/mnt/a47b2aa3-ca42-3bb1-926d-06e8eacfedde/4afdadd3-1ef0-4a7a-9caa-d61e63dfe355"
>  but, the new volumes created are just using path like 
> "4afdadd3-1ef0-4a7a-9caa-d61e63dfe355"
> Here is the snippet for DATA-7 volume which was created before upgrade on KVM
> Before delete:
> ==
> mysql> select * from volumes where name like '%data-7%'\G
> *** 1. row ***
> id: 8
> account_id: 2
>  domain_id: 1
>pool_id: 200
>instance_id: 7
>  device_id: 1
>   name: data-7
>   size: 5368709120
> folder: /export/home/talluri/byronp
>   path: 
> /mnt/a47b2aa3-ca42-3bb1-926d-06e8eacfedde/4afdadd3-1ef0-4a7a-9caa-d61e63dfe355
> pod_id: 1
> data_center_id: 1
> iscsi_name: NULL
>host_ip: NULL
>volume_type: DATADISK
>  pool_type: NetworkFilesystem
>   disk_offering_id: 3
>template_id: NULL
> iso_id: NULL
> first_snapshot_backup_uuid: NULL
>recreatable: 0
>created: 2012-12-21 06:26:10
>   attached: 2012-12-21 06:26:26
>updated: 2012-12-21 06:26:26
>removed: NULL
>  state: Ready
> chain_info: NULL
>   uuid: 8
>   last_pool_id: 200
>   update_count: 0
> 1 row in set (0.00 sec)
> After delete :
> ==
> mysql> select * from volumes where name like '%data-7%'\G
> *** 1. row ***
> id: 8
> account_id: 2
>  domain_id: 1
>pool_id: 200
>instance_id: NULL
>  device_id: NULL
>   name: data-7
>   size: 5368709120
> folder: /export/home/talluri/byronp
>   path: 
> /mnt/a47b2aa3-ca42-3bb1-926d-06e8eacfedde/4afdadd3-1ef0-4a7a-9caa-d61e63dfe355
> pod_id: 1
> data_center_id: 1
> iscsi_name: NULL
>host_ip: NULL
>volume_type: DATADISK
>  pool_type: NetworkFilesystem
>   disk_offering_id: 3
>template_id: NULL
> iso_id: NULL
> first_snapshot_backup_uuid: NULL
>recreatable: 0
>created: 2012-12-21 06:26:10
>   attached: NULL
>updated: 2012-12-21 15:44:48
>removed: NULL
>  state: Destroy
> chain_info: NULL
>   uuid: 8
>   last_pool_id: 200
>   update_count: 2
> 1 row in set (0.00 sec)
> We can see that this volume still exists on primary storage 
> ==
> [root@Rhel62-Sanjeev byronp]# ls | grep -i 
> 4afdadd3-1ef0-4a7a-9caa-d61e63dfe355
> 4afdadd3-1ef0-4a7a-9caa-d61e63dfe355
> Here is the snippet from GC log
> ===
> 2012-12-21 21:14:39,651 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-83:null) Seq 6-847643703: Response Received:
> 2012-12-21 21:14:39,652 DEBUG [agent.transport.Request] 

[jira] [Updated] (CLOUDSTACK-4176) [XenServer] Nic not unplugged after all IPs are released

[Kishan Kavala (JIRA)]

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

Kishan Kavala updated CLOUDSTACK-4176:
--

Affects Version/s: 4.2.0

> [XenServer] Nic not unplugged after all IPs are released 
> -
>
> Key: CLOUDSTACK-4176
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4176
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: XenServer
>Affects Versions: 4.2.0
> Environment: Nic should be unplugged after all the public IPs 
> assigned to it are released. Currently nics are not being reused due to this 
> bug.
>Reporter: Kishan Kavala
>
> Code to set removeVif was removed
> else if (!add && firstIP) {
> /* FIXME: This is incorrect. Because you can only tell if 
> it's the first IP in this bundle of ip address which send to the router,
>  * but don't know if it's the only IP left in the router - 
> because we didn't send all the related vlan's IPs to the router now. */
> removeVif = true;
>  }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-4148) usage:usage stats are not triggered for shared network

[Murali Reddy (JIRA)]

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

Murali Reddy updated CLOUDSTACK-4148:
-

Fix Version/s: Future

> usage:usage stats are not triggered for shared network
> --
>
> Key: CLOUDSTACK-4148
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4148
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.2.0
>Reporter: sadhu suresh
>Assignee: Kishan Kavala
>Priority: Blocker
> Fix For: Future
>
> Attachments: management-server.rar
>
>
> steps:
> 1.create network offering with SRX and F5 
> 2.create a shared guestnetwork using above NO
> 3.deploy a VM using abobve network
> 4.generate the traffic and check the usage stats after 10 min
> actual:
> NetworkUsageCommand: is running only for isolated network and its not issuing 
> for  for sharednetwok.
> router-12 isbelongs to sharednetwork.
> r-4-0vm belongs to isloated network
> No query specified
> mysql> select * from user_statistics;
> ++++---+---+--++++++++
> | id | data_center_id | account_id | public_ip_address | device_id | 
> device_type  | network_id | net_bytes_received | net_bytes_sent | 
> current_bytes_received | current_bytes_sent | agg_bytes_received | 
> agg_bytes_sent |
> ++++---+---+--++++++++
> |  1 |  1 |  2 | NULL  | 4 | 
> DomainRouter |204 |  0 |  0 | 
>  0 | 401016 |  0 | 401016 |
> |  2 |  1 |  1 | NULL  |12 | 
> DomainRouter |206 |  0 |  0 | 
>  0 |  0 |  0 |  0 |
> |  3 |  1 |  1 | NULL  |18 | 
> DomainRouter |209 |  0 |  0 | 
>  0 |  0 |  0 |  0 |
> |  4 |  1 |  2 | 10.147.49.106 |21 | 
> DomainRouter |200 |  0 |  0 | 
>4195797 | 148136 |4195797 | 148136 |
> |  5 |  1 |  2 | NULL  |21 | 
> DomainRouter |210 |  0 |  0 | 
>  0 |  0 |  0 |  0 |
> ++++---+---+--++++++++
> 5 rows in set (0.00 sec)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Deleted] (CLOUDSTACK-4175) [KVM] [Upgrade from 2.2.14] Failed to delete and cleanup ROOT / DATA volumes from primary storage that were created prior to upgrade and marked for cl

[Kishan Kavala (JIRA)]

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

Kishan Kavala updated CLOUDSTACK-4175:
--

Comment: was deleted

(was: Code to set removeVif was removed
else if (!add && firstIP) {
/* FIXME: This is incorrect. Because you can only tell if it's 
the first IP in this bundle of ip address which send to the router,
 * but don't know if it's the only IP left in the router - 
because we didn't send all the related vlan's IPs to the router now. */
removeVif = true;
 }
)

>  [KVM] [Upgrade from 2.2.14] Failed to delete and cleanup ROOT / DATA volumes 
> from primary storage that were created prior to upgrade and marked for cleanup
> 
>
> Key: CLOUDSTACK-4175
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4175
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kishan Kavala
>
> Steps to reproduce :
> 1. Have 2.2.14 setup with KVM host and at least few vms deployed with ROOT 
> and DATA disks
> 2. Upgrade to 4.2
> 3. make sure storage.cleanup.interval is set to 300
> 4. Detach and Delete DATA / ROOT disks that were created before upgrade
> Observations :
> (i) It successfully deleted without any issues
> (ii) When storage GC is kicked in, it failed to cleanup those volumes because 
> these entities are still using path like 
> "/mnt/a47b2aa3-ca42-3bb1-926d-06e8eacfedde/4afdadd3-1ef0-4a7a-9caa-d61e63dfe355"
>  but, the new volumes created are just using path like 
> "4afdadd3-1ef0-4a7a-9caa-d61e63dfe355"
> Here is the snippet for DATA-7 volume which was created before upgrade on KVM
> Before delete:
> ==
> mysql> select * from volumes where name like '%data-7%'\G
> *** 1. row ***
> id: 8
> account_id: 2
>  domain_id: 1
>pool_id: 200
>instance_id: 7
>  device_id: 1
>   name: data-7
>   size: 5368709120
> folder: /export/home/talluri/byronp
>   path: 
> /mnt/a47b2aa3-ca42-3bb1-926d-06e8eacfedde/4afdadd3-1ef0-4a7a-9caa-d61e63dfe355
> pod_id: 1
> data_center_id: 1
> iscsi_name: NULL
>host_ip: NULL
>volume_type: DATADISK
>  pool_type: NetworkFilesystem
>   disk_offering_id: 3
>template_id: NULL
> iso_id: NULL
> first_snapshot_backup_uuid: NULL
>recreatable: 0
>created: 2012-12-21 06:26:10
>   attached: 2012-12-21 06:26:26
>updated: 2012-12-21 06:26:26
>removed: NULL
>  state: Ready
> chain_info: NULL
>   uuid: 8
>   last_pool_id: 200
>   update_count: 0
> 1 row in set (0.00 sec)
> After delete :
> ==
> mysql> select * from volumes where name like '%data-7%'\G
> *** 1. row ***
> id: 8
> account_id: 2
>  domain_id: 1
>pool_id: 200
>instance_id: NULL
>  device_id: NULL
>   name: data-7
>   size: 5368709120
> folder: /export/home/talluri/byronp
>   path: 
> /mnt/a47b2aa3-ca42-3bb1-926d-06e8eacfedde/4afdadd3-1ef0-4a7a-9caa-d61e63dfe355
> pod_id: 1
> data_center_id: 1
> iscsi_name: NULL
>host_ip: NULL
>volume_type: DATADISK
>  pool_type: NetworkFilesystem
>   disk_offering_id: 3
>template_id: NULL
> iso_id: NULL
> first_snapshot_backup_uuid: NULL
>recreatable: 0
>created: 2012-12-21 06:26:10
>   attached: NULL
>updated: 2012-12-21 15:44:48
>removed: NULL
>  state: Destroy
> chain_info: NULL
>   uuid: 8
>   last_pool_id: 200
>   update_count: 2
> 1 row in set (0.00 sec)
> We can see that this volume still exists on primary storage 
> ==
> [root@Rhel62-Sanjeev byronp]# ls | grep -i 
> 4afdadd3-1ef0-4a7a-9caa-d61e63dfe355
> 4afdadd3-1ef0-4a7a-9caa-d61e63dfe355
> Here is the snippet from GC log
> ===

[jira] [Commented] (CLOUDSTACK-4176) [XenServer] Nic not unplugged after all IPs are released

[Kishan Kavala (JIRA)]

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

Kishan Kavala commented on CLOUDSTACK-4176:
---

As per Anthony:
"resource code needs to make sure this is the last ip in this NIC, so the 
firstIP flag is useless.
ipassoc script needs to return if there are ip on this NIC, if no, unplug this 
nic"

> [XenServer] Nic not unplugged after all IPs are released 
> -
>
> Key: CLOUDSTACK-4176
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4176
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: XenServer
> Environment: Nic should be unplugged after all the public IPs 
> assigned to it are released. Currently nics are not being reused due to this 
> bug.
>Reporter: Kishan Kavala
>
> Code to set removeVif was removed
> else if (!add && firstIP) {
> /* FIXME: This is incorrect. Because you can only tell if 
> it's the first IP in this bundle of ip address which send to the router,
>  * but don't know if it's the only IP left in the router - 
> because we didn't send all the related vlan's IPs to the router now. */
> removeVif = true;
>  }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-4176) [XenServer] Nic not unplugged after all IPs are released

[Kishan Kavala (JIRA)]

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

Kishan Kavala updated CLOUDSTACK-4176:
--

Fix Version/s: 4.2.0

> [XenServer] Nic not unplugged after all IPs are released 
> -
>
> Key: CLOUDSTACK-4176
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4176
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: XenServer
>Affects Versions: 4.2.0
> Environment: Nic should be unplugged after all the public IPs 
> assigned to it are released. Currently nics are not being reused due to this 
> bug.
>Reporter: Kishan Kavala
> Fix For: 4.2.0
>
>
> Code to set removeVif was removed
> else if (!add && firstIP) {
> /* FIXME: This is incorrect. Because you can only tell if 
> it's the first IP in this bundle of ip address which send to the router,
>  * but don't know if it's the only IP left in the router - 
> because we didn't send all the related vlan's IPs to the router now. */
> removeVif = true;
>  }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-4176) [XenServer] Nic not unplugged after all IPs are released

[Kishan Kavala (JIRA)]

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

Kishan Kavala updated CLOUDSTACK-4176:
--

Description: 
Code to set removeVif was removed
else if (!add && firstIP) {
/* FIXME: This is incorrect. Because you can only tell if it's 
the first IP in this bundle of ip address which send to the router,
 * but don't know if it's the only IP left in the router - 
because we didn't send all the related vlan's IPs to the router now. */
removeVif = true;
 }

> [XenServer] Nic not unplugged after all IPs are released 
> -
>
> Key: CLOUDSTACK-4176
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4176
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: XenServer
> Environment: Nic should be unplugged after all the public IPs 
> assigned to it are released. Currently nics are not being reused due to this 
> bug.
>Reporter: Kishan Kavala
>
> Code to set removeVif was removed
> else if (!add && firstIP) {
> /* FIXME: This is incorrect. Because you can only tell if 
> it's the first IP in this bundle of ip address which send to the router,
>  * but don't know if it's the only IP left in the router - 
> because we didn't send all the related vlan's IPs to the router now. */
> removeVif = true;
>  }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-4175) [KVM] [Upgrade from 2.2.14] Failed to delete and cleanup ROOT / DATA volumes from primary storage that were created prior to upgrade and marked for cleanup

[Kishan Kavala (JIRA)]

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

Kishan Kavala commented on CLOUDSTACK-4175:
---

Code to set removeVif was removed
else if (!add && firstIP) {
/* FIXME: This is incorrect. Because you can only tell if it's 
the first IP in this bundle of ip address which send to the router,
 * but don't know if it's the only IP left in the router - 
because we didn't send all the related vlan's IPs to the router now. */
removeVif = true;
 }


>  [KVM] [Upgrade from 2.2.14] Failed to delete and cleanup ROOT / DATA volumes 
> from primary storage that were created prior to upgrade and marked for cleanup
> 
>
> Key: CLOUDSTACK-4175
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4175
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kishan Kavala
>
> Steps to reproduce :
> 1. Have 2.2.14 setup with KVM host and at least few vms deployed with ROOT 
> and DATA disks
> 2. Upgrade to 4.2
> 3. make sure storage.cleanup.interval is set to 300
> 4. Detach and Delete DATA / ROOT disks that were created before upgrade
> Observations :
> (i) It successfully deleted without any issues
> (ii) When storage GC is kicked in, it failed to cleanup those volumes because 
> these entities are still using path like 
> "/mnt/a47b2aa3-ca42-3bb1-926d-06e8eacfedde/4afdadd3-1ef0-4a7a-9caa-d61e63dfe355"
>  but, the new volumes created are just using path like 
> "4afdadd3-1ef0-4a7a-9caa-d61e63dfe355"
> Here is the snippet for DATA-7 volume which was created before upgrade on KVM
> Before delete:
> ==
> mysql> select * from volumes where name like '%data-7%'\G
> *** 1. row ***
> id: 8
> account_id: 2
>  domain_id: 1
>pool_id: 200
>instance_id: 7
>  device_id: 1
>   name: data-7
>   size: 5368709120
> folder: /export/home/talluri/byronp
>   path: 
> /mnt/a47b2aa3-ca42-3bb1-926d-06e8eacfedde/4afdadd3-1ef0-4a7a-9caa-d61e63dfe355
> pod_id: 1
> data_center_id: 1
> iscsi_name: NULL
>host_ip: NULL
>volume_type: DATADISK
>  pool_type: NetworkFilesystem
>   disk_offering_id: 3
>template_id: NULL
> iso_id: NULL
> first_snapshot_backup_uuid: NULL
>recreatable: 0
>created: 2012-12-21 06:26:10
>   attached: 2012-12-21 06:26:26
>updated: 2012-12-21 06:26:26
>removed: NULL
>  state: Ready
> chain_info: NULL
>   uuid: 8
>   last_pool_id: 200
>   update_count: 0
> 1 row in set (0.00 sec)
> After delete :
> ==
> mysql> select * from volumes where name like '%data-7%'\G
> *** 1. row ***
> id: 8
> account_id: 2
>  domain_id: 1
>pool_id: 200
>instance_id: NULL
>  device_id: NULL
>   name: data-7
>   size: 5368709120
> folder: /export/home/talluri/byronp
>   path: 
> /mnt/a47b2aa3-ca42-3bb1-926d-06e8eacfedde/4afdadd3-1ef0-4a7a-9caa-d61e63dfe355
> pod_id: 1
> data_center_id: 1
> iscsi_name: NULL
>host_ip: NULL
>volume_type: DATADISK
>  pool_type: NetworkFilesystem
>   disk_offering_id: 3
>template_id: NULL
> iso_id: NULL
> first_snapshot_backup_uuid: NULL
>recreatable: 0
>created: 2012-12-21 06:26:10
>   attached: NULL
>updated: 2012-12-21 15:44:48
>removed: NULL
>  state: Destroy
> chain_info: NULL
>   uuid: 8
>   last_pool_id: 200
>   update_count: 2
> 1 row in set (0.00 sec)
> We can see that this volume still exists on primary storage 
> ==
> [root@Rhel62-Sanjeev byronp]# ls | grep -i 
> 4afdadd3-1ef0-4a7a-9caa-d61e63dfe355
> 4afdadd3-1ef0-4a7a-9caa-d61e63dfe355
> H

[jira] [Updated] (CLOUDSTACK-3943) [KVM] [Zone Wide Primary Storages] migrateVolume is failing with NPE

[Rajesh Battala (JIRA)]

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

Rajesh Battala updated CLOUDSTACK-3943:
---

Assignee: Rajesh Battala  (was: edison su)

> [KVM] [Zone Wide Primary Storages] migrateVolume is failing with NPE
> 
>
> Key: CLOUDSTACK-3943
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3943
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller
>Affects Versions: 4.2.0
> Environment: commit # 6275d697e340be5b520f37b15d72343fa47c00a9
>Reporter: venkata swamybabu budumuru
>Assignee: Rajesh Battala
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: logs.tgz
>
>
> Steps to reproduce :
> 1. Have at least one advanced zone with KVM cluster (2 kvm hosts)
> 2. Make sure that the setup has at least 2 zone wide primary storages. (from 
> ex: zwps1, zwps2)
> 3. Deploy a VM as admin
> 4. Create a datadisk of size 5 GB as admin on zwps1
> 5. attach the above datadisk to the VM in step 3
> 6. detach the data disk
> 7. initiate migrateVolume command for the above datadisk to zwps2
> Observations:
> (i) Found the following NPE in mgmt server logs
> 2013-07-30 15:37:50,993 DEBUG [cloud.api.ApiServlet] (catalina-exec-24:null) 
> ===END===  10.252.192.25 -- GET  
> command=migrateVolume&storageid=94634fe1-55f7-3fa8-aad9-5adc25246072&volumeid=8e27413a-9904-4b04-88e2-4646f9e2012e&response=json&sessionkey=%2BzLNhLsWep0480hDIw1Pq1TaL%2FY%3D&_=1375178879961
> 2013-07-30 15:37:50,996 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-39:job-39 = [ c3f2420d-83a4-4610-b364-df41a35aa86d ]) Executing 
> org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd for job-39 = [ 
> c3f2420d-83a4-4610-b364-df41a35aa86d ]
> 2013-07-30 15:37:51,052 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-39:job-39 = [ c3f2420d-83a4-4610-b364-df41a35aa86d ]) copyAsync 
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-07-30 15:37:51,056 DEBUG [cache.allocator.StorageCacheRandomAllocator] 
> (Job-Executor-39:job-39 = [ c3f2420d-83a4-4610-b364-df41a35aa86d ]) Can't 
> find staging storage in zone: 1
> 2013-07-30 15:37:51,096 DEBUG [agent.transport.Request] 
> (Job-Executor-39:job-39 = [ c3f2420d-83a4-4610-b364-df41a35aa86d ]) Seq 
> 3-46924267: Sending  { Cmd , MgmtId: 7280707764394, via: 3, Ver: v1, Flags: 
> 100011, 
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"8e27413a-9904-4b04-88e2-4646f9e2012e","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"5458182e-bfcb-351c-97ed-e7223bca2b8e","id":1,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/swamy/primary.campo.kvm.1.zone","port":2049}},"name":"adminDataDisk2","size":0,"path":"a8923a0d-401c-453a-bf77-0e4496711f0d","volumeId":13,"accountId":2,"format":"QCOW2","id":13,"hypervisorType":"None"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"8e27413a-9904-4b04-88e2-4646f9e2012e","volumeType":"DATADISK","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.147.28.7/export/home/swamy/secondary.campo.kvm.1","_role":"Image"}},"name":"adminDataDisk2","size":0,"path":"volumes/2/13","volumeId":13,"accountId":2,"format":"QCOW2","id":13,"hypervisorType":"None"}},"executeInSequence":false,"wait":10800}}]
>  }
> 2013-07-30 15:37:51,142 DEBUG [agent.transport.Request] 
> (AgentManager-Handler-5:null) Seq 3-46924267: Processing:  { Ans: , MgmtId: 
> 7280707764394, via: 3, Ver: v1, Flags: 10, 
> [{"com.cloud.agent.api.UnsupportedAnswer":{"result":false,"details":"Unsupported
>  command issued:org.apache.cloudstack.storage.command.CopyCommand.  Are you 
> sure you got the right type of server?","wait":0}}] }
> 2013-07-30 15:37:51,143 DEBUG [agent.transport.Request] 
> (Job-Executor-39:job-39 = [ c3f2420d-83a4-4610-b364-df41a35aa86d ]) Seq 
> 3-46924267: Received:  { Ans: , MgmtId: 7280707764394, via: 3, Ver: v1, 
> Flags: 10, { UnsupportedAnswer } }
> 2013-07-30 15:37:51,143 WARN  [agent.manager.AgentManagerImpl] 
> (Job-Executor-39:job-39 = [ c3f2420d-83a4-4610-b364-df41a35aa86d ]) 
> Unsupported Command: Unsupported command 
> issued:org.apache.cloudstack.storage.command.CopyCommand.  Are you sure you 
> got the right type of server?
> 2013-07-30 15:37:51,152 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-39:job-39 = [ c3f2420d-83a4-4610-b364-df41a35aa86d ]) copy to 
> image store failed: Unsupported command 
> issued:org.apache.cloudstack.storage.command.CopyCommand.  Are you sure you 
> got the right type of server?
> 2013-07-30 15:37:51

[jira] [Updated] (CLOUDSTACK-3946) [KVM] [Zone Wide Primary Storages] migrateVolume is deleting the volume if the source and destination pool are same.

[Rajesh Battala (JIRA)]

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

Rajesh Battala updated CLOUDSTACK-3946:
---

Assignee: Rajesh Battala  (was: edison su)

> [KVM] [Zone Wide Primary Storages] migrateVolume is deleting the volume if 
> the source and destination pool are same.
> 
>
> Key: CLOUDSTACK-3946
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3946
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller
>Affects Versions: 4.2.0
> Environment: commit # 6275d697e340be5b520f37b15d72343fa47c00a9
>Reporter: venkata swamybabu budumuru
>Assignee: Rajesh Battala
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: logs.tgz
>
>
> Steps to reproduce : 
> 1. Have at least one advanced zone with KVM cluster (2 kvm hosts) 
> 2. Make sure that the setup has at least 2 zone wide primary storages. (from 
> ex: zwps1, zwps2) 
> 3. Deploy a VM as admin 
> 4. Create a datadisk of size 5 GB as admin on zwps1 
> 5. attach the above datadisk to the VM in step 3 
> 6. detach the data disk 
> 7. initiate migrateVolume command for the above datadisk to again zwps1
> Observations:
> (i) volume migrate command involved 2 things
> - copyCommand
> - delete the original
> (ii) In my case, I tried to migrate the volume which is on zwps1 to again 
> zwps1. This initiated copyCommand followed by storage.command.DeleteCommand.
> (iii)  Due to the issue mentioned in CLOUDSTACK-3943, copy command failed. 
> The subsequent delete command deleted the orignal volume because the "path 
> uuid" for original volume and new volume is maintained with same uuid 
> temporarily.
> *** Either we shouldn't let user fire migrateVolume API with storageId if the 
> volume's original storageId and destStorageId are same.
> (OR)
> *** we should use a unique path UUID so that in case of copy command failure, 
> it will only delete the new volume.
> MGMT server log snippet :
> 2013-07-30 15:40:35,945 DEBUG [cloud.storage.StorageManagerImpl] 
> (StorageManager-Scavenger-1:null) Secondary storage garbage collector found 0 
> volumes to cleanup on volume_store_ref for store: secondary2
> 2013-07-30 15:40:35,967 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-279:null) Seq 6-1249116579: Response Received:
> 2013-07-30 15:40:35,969 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-40:job-40 = [ 24eb5a75-590f-43a9-bb90-88be177fa359 ]) copyAsync 
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-07-30 15:40:35,970 DEBUG [agent.transport.Request] 
> (StatsCollector-1:null) Seq 6-1249116579: Received:  { Ans: , MgmtId: 
> 7280707764394, via: 6, Ver: v1, Flags: 10, { GetHostStatsAnswer } }
> 2013-07-30 15:40:35,974 DEBUG [cache.allocator.StorageCacheRandomAllocator] 
> (Job-Executor-40:job-40 = [ 24eb5a75-590f-43a9-bb90-88be177fa359 ]) Can't 
> find staging storage in zone: 1
> 2013-07-30 15:40:36,033 DEBUG [agent.transport.Request] 
> (Job-Executor-40:job-40 = [ 24eb5a75-590f-43a9-bb90-88be177fa359 ]) Seq 
> 3-46924274: Sending  { Cmd , MgmtId: 7280707764394, via: 3, Ver: v1, Flags: 
> 100011, 
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"8e27413a-9904-4b04-88e2-4646f9e2012e","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"5458182e-bfcb-351c-97ed-e7223bca2b8e","id":1,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/swamy/primary.campo.kvm.1.zone","port":2049}},"name":"adminDataDisk2","size":0,"path":"a8923a0d-401c-453a-bf77-0e4496711f0d","volumeId":13,"accountId":2,"format":"QCOW2","id":13,"hypervisorType":"None"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"8e27413a-9904-4b04-88e2-4646f9e2012e","volumeType":"DATADISK","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.147.28.7/export/home/swamy/secondary.campo.kvm.1","_role":"Image"}},"name":"adminDataDisk2","size":0,"path":"volumes/2/13","volumeId":13,"accountId":2,"format":"QCOW2","id":13,"hypervisorType":"None"}},"executeInSequence":false,"wait":10800}}]
>  }
> 2013-07-30 15:40:36,039 DEBUG [agent.transport.Request] 
> (AgentManager-Handler-4:null) Seq 3-46924274: Processing:  { Ans: , MgmtId: 
> 7280707764394, via: 3, Ver: v1, Flags: 10, 
> [{"com.cloud.agent.api.UnsupportedAnswer":{"result":false,"details":"Unsupported
>  command issued:org.apache.cloudstack.storage.command.CopyCommand.  Are you 
> sure you got the right type of server?","wait":0}}] }
> 2013-07-30 15:40:36,039 DEBUG [agent.transport.Request] 
> 

[jira] [Created] (CLOUDSTACK-4176) [XenServer] Nic not unplugged after all IPs are released

[Kishan Kavala (JIRA)]

Kishan Kavala created CLOUDSTACK-4176:
-

 Summary: [XenServer] Nic not unplugged after all IPs are released 
 Key: CLOUDSTACK-4176
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4176
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: XenServer
 Environment: Nic should be unplugged after all the public IPs assigned 
to it are released. Currently nics are not being reused due to this bug.
Reporter: Kishan Kavala




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-4007) NPE while migrating a volume created on zone wide primary storage

[Rajesh Battala (JIRA)]

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

Rajesh Battala updated CLOUDSTACK-4007:
---

Assignee: Rajesh Battala

> NPE while migrating a volume created on zone wide primary storage
> -
>
> Key: CLOUDSTACK-4007
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4007
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.2.0
> Environment: KVM
>Reporter: Srikanteswararao Talluri
>Assignee: Rajesh Battala
>Priority: Blocker
> Fix For: 4.2.0
>
>
> Steps to reproduce:
> ==
> 1. create a volume  and attach it to a VM.
> 2. detach the volume
> 3. migrate the detached volume to a different zone wide primary storage
> ===START===  10.101.255.7 -- GET  
> command=migrateVolume&storageid=fec290f3-9361-3dbd-8a96-c861ad85973a&volumeid=00fea7ac-c29d-4883-9a60-ad091d7c35a9&response=json&sessionkey=%2Ffgph8eXl%2BeIzsdyOBQZp9jAEBQ%3D&_=1375351636676
> 2013-08-01 21:01:47,901 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (catalina-exec-2:null) submit async job-81 = [ 
> 33465551-bd5b-4afc-aa21-8417eeafdddf ], details: AsyncJobVO {id:81, userId: 
> 2, accountId: 2, sessionKey: null, instanceType: None, instanceId: null, cmd: 
> org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd, 
> cmdOriginator: null, cmdInfo: 
> {"response":"json","sessionkey":"/fgph8eXl+eIzsdyOBQZp9jAEBQ\u003d","cmdEventType":"VOLUME.MIGRATE","ctxUserId":"2","storageid":"fec290f3-9361-3dbd-8a96-c861ad85973a","httpmethod":"GET","_":"1375351636676","volumeid":"00fea7ac-c29d-4883-9a60-ad091d7c35a9","ctxAccountId":"2","ctxStartEventId":"303"},
>  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
> processStatus: 0, resultCode: 0, result: null, initMsid: 7541090156566, 
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-01 21:01:47,905 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null) 
> ===END===  10.101.255.7 -- GET  
> command=migrateVolume&storageid=fec290f3-9361-3dbd-8a96-c861ad85973a&volumeid=00fea7ac-c29d-4883-9a60-ad091d7c35a9&response=json&sessionkey=%2Ffgph8eXl%2BeIzsdyOBQZp9jAEBQ%3D&_=1375351636676
> 2013-08-01 21:01:47,909 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-81:job-81 = [ 33465551-bd5b-4afc-aa21-8417eeafdddf ]) Executing 
> org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd for job-81 = [ 
> 33465551-bd5b-4afc-aa21-8417eeafdddf ]
> 2013-08-01 21:01:48,020 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-81:job-81 = [ 33465551-bd5b-4afc-aa21-8417eeafdddf ]) copyAsync 
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-01 21:01:48,031 DEBUG [cache.allocator.StorageCacheRandomAllocator] 
> (Job-Executor-81:job-81 = [ 33465551-bd5b-4afc-aa21-8417eeafdddf ]) Can't 
> find staging storage in zone: 1
> 2013-08-01 21:01:48,120 DEBUG [agent.transport.Request] 
> (Job-Executor-81:job-81 = [ 33465551-bd5b-4afc-aa21-8417eeafdddf ]) Seq 
> 1-259457771: Sending  { Cmd , MgmtId: 7541090156566, via: 1, Ver: v1, Flags: 
> 100011, 
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"00fea7ac-c29d-4883-9a60-ad091d7c35a9","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"1fa482ac-85ac-3686-8375-aa596772b466","id":2,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/talluri/zwps1","port":2049}},"name":"zd13","size":0,"path":"94c4d208-de20-4b76-a4ec-a021953fe8c4","volumeId":18,"accountId":2,"format":"QCOW2","id":18,"hypervisorType":"None"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"00fea7ac-c29d-4883-9a60-ad091d7c35a9","volumeType":"DATADISK","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.147.28.7/export/home/pavan/secondary","_role":"Image"}},"name":"zd13","size":0,"path":"volumes/2/18","volumeId":18,"accountId":2,"format":"QCOW2","id":18,"hypervisorType":"None"}},"executeInSequence":false,"wait":10800}}]
>  }
> 2013-08-01 21:01:48,130 DEBUG [agent.transport.Request] 
> (AgentManager-Handler-7:null) Seq 1-259457771: Processing:  { Ans: , MgmtId: 
> 7541090156566, via: 1, Ver: v1, Flags: 10, 
> [{"com.cloud.agent.api.UnsupportedAnswer":{"result":false,"details":"Unsupported
>  command issued:org.apache.cloudstack.storage.command.CopyCommand.  Are you 
> sure you got the right type of server?","wait":0}}] }
> 2013-08-01 21:01:48,130 DEBUG [agent.transport.Request] 
> (Job-Executor-81:job-81 = [ 33465551-bd5b-4afc-aa21-8417eeafdddf ]) Seq 
> 1-259457771: Received:  { Ans: , MgmtId: 7541090156566, via: 1, Ver: v1

[jira] [Commented] (CLOUDSTACK-4175) [KVM] [Upgrade from 2.2.14] Failed to delete and cleanup ROOT / DATA volumes from primary storage that were created prior to upgrade and marked for cleanup

[Kishan Kavala (JIRA)]

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

Kishan Kavala commented on CLOUDSTACK-4175:
---

As per Anthony:
"resource code needs to make sure this is the last ip in this NIC, so the 
firstIP flag is useless.
ipassoc script needs to return if there are ip on this NIC, if no, unplug this 
nic"

>  [KVM] [Upgrade from 2.2.14] Failed to delete and cleanup ROOT / DATA volumes 
> from primary storage that were created prior to upgrade and marked for cleanup
> 
>
> Key: CLOUDSTACK-4175
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4175
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kishan Kavala
>
> Steps to reproduce :
> 1. Have 2.2.14 setup with KVM host and at least few vms deployed with ROOT 
> and DATA disks
> 2. Upgrade to 4.2
> 3. make sure storage.cleanup.interval is set to 300
> 4. Detach and Delete DATA / ROOT disks that were created before upgrade
> Observations :
> (i) It successfully deleted without any issues
> (ii) When storage GC is kicked in, it failed to cleanup those volumes because 
> these entities are still using path like 
> "/mnt/a47b2aa3-ca42-3bb1-926d-06e8eacfedde/4afdadd3-1ef0-4a7a-9caa-d61e63dfe355"
>  but, the new volumes created are just using path like 
> "4afdadd3-1ef0-4a7a-9caa-d61e63dfe355"
> Here is the snippet for DATA-7 volume which was created before upgrade on KVM
> Before delete:
> ==
> mysql> select * from volumes where name like '%data-7%'\G
> *** 1. row ***
> id: 8
> account_id: 2
>  domain_id: 1
>pool_id: 200
>instance_id: 7
>  device_id: 1
>   name: data-7
>   size: 5368709120
> folder: /export/home/talluri/byronp
>   path: 
> /mnt/a47b2aa3-ca42-3bb1-926d-06e8eacfedde/4afdadd3-1ef0-4a7a-9caa-d61e63dfe355
> pod_id: 1
> data_center_id: 1
> iscsi_name: NULL
>host_ip: NULL
>volume_type: DATADISK
>  pool_type: NetworkFilesystem
>   disk_offering_id: 3
>template_id: NULL
> iso_id: NULL
> first_snapshot_backup_uuid: NULL
>recreatable: 0
>created: 2012-12-21 06:26:10
>   attached: 2012-12-21 06:26:26
>updated: 2012-12-21 06:26:26
>removed: NULL
>  state: Ready
> chain_info: NULL
>   uuid: 8
>   last_pool_id: 200
>   update_count: 0
> 1 row in set (0.00 sec)
> After delete :
> ==
> mysql> select * from volumes where name like '%data-7%'\G
> *** 1. row ***
> id: 8
> account_id: 2
>  domain_id: 1
>pool_id: 200
>instance_id: NULL
>  device_id: NULL
>   name: data-7
>   size: 5368709120
> folder: /export/home/talluri/byronp
>   path: 
> /mnt/a47b2aa3-ca42-3bb1-926d-06e8eacfedde/4afdadd3-1ef0-4a7a-9caa-d61e63dfe355
> pod_id: 1
> data_center_id: 1
> iscsi_name: NULL
>host_ip: NULL
>volume_type: DATADISK
>  pool_type: NetworkFilesystem
>   disk_offering_id: 3
>template_id: NULL
> iso_id: NULL
> first_snapshot_backup_uuid: NULL
>recreatable: 0
>created: 2012-12-21 06:26:10
>   attached: NULL
>updated: 2012-12-21 15:44:48
>removed: NULL
>  state: Destroy
> chain_info: NULL
>   uuid: 8
>   last_pool_id: 200
>   update_count: 2
> 1 row in set (0.00 sec)
> We can see that this volume still exists on primary storage 
> ==
> [root@Rhel62-Sanjeev byronp]# ls | grep -i 
> 4afdadd3-1ef0-4a7a-9caa-d61e63dfe355
> 4afdadd3-1ef0-4a7a-9caa-d61e63dfe355
> Here is the snippet from GC log
> ===
> 2012-12-21 21:14:39,651 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-83:null) Seq 6-847643703: Response Received:
> 2012-12-21 21:14:39,

[jira] [Resolved] (CLOUDSTACK-3887) [KVM] [PrimaryStorage] deleteStoragePool is not removing the storage pool information from KVM agent/host.

[Rajesh Battala (JIRA)]

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

Rajesh Battala resolved CLOUDSTACK-3887.


Resolution: Fixed

> [KVM] [PrimaryStorage] deleteStoragePool is not removing the storage pool 
> information from KVM agent/host.
> --
>
> Key: CLOUDSTACK-3887
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3887
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.2.0
> Environment: commit # ca474d0e09f772cb22abf2802a308a2da5351592
>Reporter: venkata swamybabu budumuru
>Assignee: Rajesh Battala
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: logs.tgz
>
>
> Steps to reproduce:
> 1. Have at least one advanced zone with KVM cluster of 2 hosts.
> 2. make sure everything is working fine.
> 3. add an additional primary storage with scope set to "Cluster"
> 4. verify and make sure that "#virsh pool-list & #virsh dump-xml " 
> are showing the newly added one.
> 5. delete the above added primary storage from cloudstack.
> Observations:
> (i) I can see the deleteStoragePool API fired and went fine but, on the KVM 
> host side, "virsh pool-list" still shows the primary storage that was added 
> in 3rd step. 
> (ii) I see that the HeartBeat is continuously written to the primary and it 
> still considers that this primary is up.
> Attaching all the mgmt server, agent logs and db dump to the bug.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CLOUDSTACK-4175) [KVM] [Upgrade from 2.2.14] Failed to delete and cleanup ROOT / DATA volumes from primary storage that were created prior to upgrade and marked for cleanup

[Kishan Kavala (JIRA)]

Kishan Kavala created CLOUDSTACK-4175:
-

 Summary:  [KVM] [Upgrade from 2.2.14] Failed to delete and cleanup 
ROOT / DATA volumes from primary storage that were created prior to upgrade and 
marked for cleanup
 Key: CLOUDSTACK-4175
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4175
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Kishan Kavala


Steps to reproduce :

1. Have 2.2.14 setup with KVM host and at least few vms deployed with ROOT and 
DATA disks
2. Upgrade to 4.2
3. make sure storage.cleanup.interval is set to 300
4. Detach and Delete DATA / ROOT disks that were created before upgrade

Observations :

(i) It successfully deleted without any issues
(ii) When storage GC is kicked in, it failed to cleanup those volumes because 
these entities are still using path like 
"/mnt/a47b2aa3-ca42-3bb1-926d-06e8eacfedde/4afdadd3-1ef0-4a7a-9caa-d61e63dfe355"
 but, the new volumes created are just using path like 
"4afdadd3-1ef0-4a7a-9caa-d61e63dfe355"

Here is the snippet for DATA-7 volume which was created before upgrade on KVM

Before delete:
==

mysql> select * from volumes where name like '%data-7%'\G
*** 1. row ***
id: 8
account_id: 2
 domain_id: 1
   pool_id: 200
   instance_id: 7
 device_id: 1
  name: data-7
  size: 5368709120
folder: /export/home/talluri/byronp
  path: 
/mnt/a47b2aa3-ca42-3bb1-926d-06e8eacfedde/4afdadd3-1ef0-4a7a-9caa-d61e63dfe355
pod_id: 1
data_center_id: 1
iscsi_name: NULL
   host_ip: NULL
   volume_type: DATADISK
 pool_type: NetworkFilesystem
  disk_offering_id: 3
   template_id: NULL
iso_id: NULL
first_snapshot_backup_uuid: NULL
   recreatable: 0
   created: 2012-12-21 06:26:10
  attached: 2012-12-21 06:26:26
   updated: 2012-12-21 06:26:26
   removed: NULL
 state: Ready
chain_info: NULL
  uuid: 8
  last_pool_id: 200
  update_count: 0
1 row in set (0.00 sec)

After delete :
==


mysql> select * from volumes where name like '%data-7%'\G
*** 1. row ***
id: 8
account_id: 2
 domain_id: 1
   pool_id: 200
   instance_id: NULL
 device_id: NULL
  name: data-7
  size: 5368709120
folder: /export/home/talluri/byronp
  path: 
/mnt/a47b2aa3-ca42-3bb1-926d-06e8eacfedde/4afdadd3-1ef0-4a7a-9caa-d61e63dfe355
pod_id: 1
data_center_id: 1
iscsi_name: NULL
   host_ip: NULL
   volume_type: DATADISK
 pool_type: NetworkFilesystem
  disk_offering_id: 3
   template_id: NULL
iso_id: NULL
first_snapshot_backup_uuid: NULL
   recreatable: 0
   created: 2012-12-21 06:26:10
  attached: NULL
   updated: 2012-12-21 15:44:48
   removed: NULL
 state: Destroy
chain_info: NULL
  uuid: 8
  last_pool_id: 200
  update_count: 2
1 row in set (0.00 sec)

We can see that this volume still exists on primary storage 
==

[root@Rhel62-Sanjeev byronp]# ls | grep -i 4afdadd3-1ef0-4a7a-9caa-d61e63dfe355
4afdadd3-1ef0-4a7a-9caa-d61e63dfe355


Here is the snippet from GC log
===

2012-12-21 21:14:39,651 DEBUG [agent.manager.DirectAgentAttache] 
(DirectAgent-83:null) Seq 6-847643703: Response Received:
2012-12-21 21:14:39,652 DEBUG [agent.transport.Request] (StatsCollector-3:null) 
Seq 6-847643703: Received: { Ans: , MgmtId: 6861512245319, via: 6, Ver: v1, 
Flags: 10, { GetHostStatsAnswer } }
2012-12-21 21:14:39,685 DEBUG [agent.manager.DirectAgentAttache] 
(DirectAgent-313:null) Seq 7-1359414333: Executing request
2012-12-21 21:14:39,820 DEBUG [agent.manager.DirectAgentAttache] 
(DirectAgent-313:null) Seq 7-1359414333: Response Received:
2012-12-21 21:14:39,821 DEBUG [agent.transport.Request] (StatsCollector-3:null) 
Seq 7-1359414333: Received: { Ans: , MgmtId: 6861512245319, via: 7, Ver: v1, 
Flags: 10, { GetHostStatsAnswer } }
2012-12-21 21:14:48,100 DEBUG [cloud.storage.StorageManagerImpl] 
(catalina-exec-21:null) Expunging Vol[8|vm=null|D

[jira] [Closed] (CLOUDSTACK-4075) User unable to archive events

[Pavan Kumar Bandarupally (JIRA)]

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

Pavan Kumar Bandarupally closed CLOUDSTACK-4075.



Verified on latest 4.2 build and user (non-admin) privilege is able to archive 
his events.

> User unable to archive events
> -
>
> Key: CLOUDSTACK-4075
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4075
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.2.0
> Environment: Latest Cloudstack 4.2 setup with host on KVM hypervisor
>Reporter: Pavan Kumar Bandarupally
>Assignee: Sanjay Tripathi
>Priority: Critical
> Fix For: 4.2.0
>
>
> User ( non-admin privilege ) is not able to archive his events either by type 
> or using time period. A permission denied error is thrown.
> 2013-08-05 21:55:21,558 DEBUG [cloud.api.ApiServlet] (catalina-exec-9:null) 
> ===START===  10.146.0.12 -- GET  
> command=archiveEvents&response=json&sessionkey=H2zcoo8rU8MaSTr2ixvKaAtvMxs%3D&startdate=2013-08-05&enddate=2013-08-05&_=1375700427624
> 2013-08-05 21:55:21,609 INFO  [cloud.api.ApiServer] (catalina-exec-9:null) 
> PermissionDenied: Acct[3-pavantest] does not have permission to operate with 
> resource com.cloud.event.EventVO$$EnhancerByCGLIB$$73ed907e@5c4c6bbf on objs: 
> []
> 2013-08-05 21:55:21,613 DEBUG [cloud.api.ApiServlet] (catalina-exec-9:null) 
> ===END===  10.146.0.12 -- GET  
> command=archiveEvents&response=json&sessionkey=H2zcoo8rU8MaSTr2ixvKaAtvMxs%3D&startdate=2013-08-05&enddate=2013-08-05&_=1375700427624
> 2013-08-05 21:55:21,738 DEBUG [cloud.api.ApiServlet] (catalina-exec-5:null) 
> ===START===  10.146.0.12 -- GET  
> command=listEvents&response=json&sessionkey=H2zcoo8rU8MaSTr2ixvKaAtvMxs%3D&listAll=true&page=1&pagesize=20&_=1375700427725
> 2013-08-05 21:55:21,758 DEBUG [cloud.api.ApiServlet] (catalina-exec-5:null) 
> ===END===  10.146.0.12 -- GET  
> command=listEvents&response=json&sessionkey=H2zcoo8rU8MaSTr2ixvKaAtvMxs%3D&listAll=true&page=1&pagesize=20&_=1375700427725

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (CLOUDSTACK-4174) Some testcases fail with error errorCode: 401, errorText:unable to verify user credentials and/or request signature

[Girish Shilamkar (JIRA)]

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

Girish Shilamkar closed CLOUDSTACK-4174.



> Some testcases fail with error errorCode: 401, errorText:unable to verify 
> user credentials and/or request signature
> ---
>
> Key: CLOUDSTACK-4174
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4174
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.0
>Reporter: Girish Shilamkar
>Assignee: Girish Shilamkar
>
> listVirtualMachines and associateIPaddress APIs when called from testcases 
> i.e. marvin fails with 
> errorText:unable to verify user credentials and/or request signature

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CLOUDSTACK-4174) Some testcases fail with error errorCode: 401, errorText:unable to verify user credentials and/or request signature

[Girish Shilamkar (JIRA)]

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

Girish Shilamkar resolved CLOUDSTACK-4174.
--

Resolution: Fixed

Prasanna already fixed it.

> Some testcases fail with error errorCode: 401, errorText:unable to verify 
> user credentials and/or request signature
> ---
>
> Key: CLOUDSTACK-4174
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4174
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.0
>Reporter: Girish Shilamkar
>Assignee: Girish Shilamkar
>
> listVirtualMachines and associateIPaddress APIs when called from testcases 
> i.e. marvin fails with 
> errorText:unable to verify user credentials and/or request signature

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-4136) [upgraded ENV]Deleting Snapshot which was created before upgrade is throwing NPE.

[manasaveloori (JIRA)]

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

manasaveloori commented on CLOUDSTACK-4136:
---

Pasted wrong entry from db.

Please find below entries

mysql> select * from snapshots where uuid = 
"acf6d258-99fa-4832-8499-a81a631627ce";
++++---+---+--+--+--+-+--+---+--++-+-+---+--++--+-+-+---+
| id | data_center_id | account_id | domain_id | volume_id | disk_offering_id | 
status   | path | name  
  | uuid | snapshot_type | 
type_description | size   | created | removed | 
backup_snap_id| 
swift_id | sechost_id | prev_snap_id | hypervisor_type | version | s3_id |
++++---+---+--+--+--+-+--+---+--++-+-+---+--++--+-+-+---+
|  1 |  2 |  2 | 1 |10 |   11 | 
BackedUp | a42cea59-2aaf-45e3-9289-adb1909ab29a | 
0f459cba-04ca-4659-b1b5-5a1350d796c8_20130806121236 | 
acf6d258-99fa-4832-8499-a81a631627ce | 0 | MANUAL   | 
2147483648 | 2013-08-06 12:12:36 | 2013-08-07 14:59:19 | 
db7e14cc-e957-47d2-895c-cf038463457a/db7e14cc-e957-47d2-895c-cf038463457a | 
NULL |  6 |0 | VMware  | 2.2 |  NULL |
++++---+---+--+--+--+-+--+---+--++-+-+---+--++--+-+-+---+
1 row in set (0.03 sec)

mysql> select * from snapshot_store_ref where  snapshot_id=1;
Empty set (0.01 sec)



> [upgraded ENV]Deleting Snapshot which was created before upgrade is throwing 
> NPE.
> -
>
> Key: CLOUDSTACK-4136
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4136
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller, Upgrade
>Affects Versions: 4.2.0
> Environment: upgraded from 3.0.7 to 4.2
>Reporter: manasaveloori
>Assignee: Koushik Das
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.zip, mysqldumpAfterUpnew.dmp, 
> mysqldumpBeforeUp.dmp
>
>
> Steps:
> 1.Have CS with 3.0.7 build with VMware and Xen hypervisor.
> 2.Deploy a VM.
> 3.Create a snapshot of root volume.
> 4.Upgrade the build to 4.2.
> 5.Try to delete the snapshot now.
> Observing NPE while deleting the snapshot for the 1st time
> Tried to delete the same snapshot again deletes it. Verified the state of 
> snapshot in DB also.
> 2013-08-07 20:29:19,535 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null) 
> ===END===  10.252.192.69 -- GET  
> command=deleteSnapshot&id=acf6d258-99fa-4832-8499-a81a631627ce&response=json&sessionkey=uKcUJCauPB9Gj8yRMfQdmpPpTAE%3D&_=1375868166341
> 2013-08-07 20:29:19,539 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-43:job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]) 
> Executing org.apache.cloudstack.api.command.user.snapshot.DeleteSnapshotCmd 
> for job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]
> 2013-08-07 20:29:19,573 DEBUG [storage.snapshot.XenserverSnapshotStrategy] 
> (Job-Executor-43:job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]) Can't 
> find snapshot on backup storage, delete it in db
> 2013-08-07 20:29:19,582 DEBUG [storage.snapshot.SnapshotManagerImpl] 
> (Job-Executor-43:job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]) Failed 
> to delete snapshot: 1:java.lang.NullPointerException
> 2013-08

[jira] [Created] (CLOUDSTACK-4174) Many testcases fail with error errorCode: 401, errorText:unable to verify user credentials and/or request signature

[Girish Shilamkar (JIRA)]

Girish Shilamkar created CLOUDSTACK-4174:


 Summary: Many testcases fail with error errorCode: 401, 
errorText:unable to verify user credentials and/or request signature
 Key: CLOUDSTACK-4174
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4174
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.2.0
Reporter: Girish Shilamkar
Assignee: Girish Shilamkar


listVirtualMachines and associateIPaddress APIs when called from testcases i.e. 
marvin fails with 
errorText:unable to verify user credentials and/or request signature

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-4174) Some testcases fail with error errorCode: 401, errorText:unable to verify user credentials and/or request signature

[Girish Shilamkar (JIRA)]

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

Girish Shilamkar updated CLOUDSTACK-4174:
-

Summary: Some testcases fail with error errorCode: 401, errorText:unable to 
verify user credentials and/or request signature  (was: Many testcases fail 
with error errorCode: 401, errorText:unable to verify user credentials and/or 
request signature)

> Some testcases fail with error errorCode: 401, errorText:unable to verify 
> user credentials and/or request signature
> ---
>
> Key: CLOUDSTACK-4174
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4174
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.2.0
>Reporter: Girish Shilamkar
>Assignee: Girish Shilamkar
>
> listVirtualMachines and associateIPaddress APIs when called from testcases 
> i.e. marvin fails with 
> errorText:unable to verify user credentials and/or request signature

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-4174) Some testcases fail with error errorCode: 401, errorText:unable to verify user credentials and/or request signature

[Girish Shilamkar (JIRA)]

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

Girish Shilamkar updated CLOUDSTACK-4174:
-

Component/s: Automation

> Some testcases fail with error errorCode: 401, errorText:unable to verify 
> user credentials and/or request signature
> ---
>
> Key: CLOUDSTACK-4174
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4174
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.0
>Reporter: Girish Shilamkar
>Assignee: Girish Shilamkar
>
> listVirtualMachines and associateIPaddress APIs when called from testcases 
> i.e. marvin fails with 
> errorText:unable to verify user credentials and/or request signature

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-4173) CLONE - [Enhancement] Upload volume does not support local storage

[Sanjeev N (JIRA)]

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

Sanjeev N updated CLOUDSTACK-4173:
--

Component/s: (was: Volumes)
 Doc

> CLONE - [Enhancement] Upload volume does not support local storage
> --
>
> Key: CLOUDSTACK-4173
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4173
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Doc
>Affects Versions: 4.2.0
> Environment: Latest build from ACS 4.2 branch.
> Hypervisor: KVM
> Primary Storage: Local Storage
>Reporter: Sanjeev N
> Fix For: 4.2.0, Future
>
>
> [Enhancement] Upload volume does not support local storage.
> When a data volume is uploaded using uploadVolume API, the disk will be 
> stored in the secondary storage and an entry will be made in the volumes 
> table in cloud DB with volume_type: DATADISK, disk_offering_id: 6 and state: 
> Uploaded.
> The volume is getting created with custom disk offering and it's 
> use_local_storage is set to 0. So this volume can't be attached to a guest vm 
> if the primary storage is Local storage.
> It would be good to support even Local storage for the uploaded volumes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CLOUDSTACK-4173) CLONE - [Enhancement] Upload volume does not support local storage

[Sanjeev N (JIRA)]

Sanjeev N created CLOUDSTACK-4173:
-

 Summary: CLONE - [Enhancement] Upload volume does not support 
local storage
 Key: CLOUDSTACK-4173
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4173
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Volumes
Affects Versions: 4.2.0
 Environment: Latest build from ACS 4.2 branch.
Hypervisor: KVM
Primary Storage: Local Storage
Reporter: Sanjeev N
 Fix For: 4.2.0, Future


[Enhancement] Upload volume does not support local storage.

When a data volume is uploaded using uploadVolume API, the disk will be stored 
in the secondary storage and an entry will be made in the volumes table in 
cloud DB with volume_type: DATADISK, disk_offering_id: 6 and state: Uploaded.

The volume is getting created with custom disk offering and it's 
use_local_storage is set to 0. So this volume can't be attached to a guest vm 
if the primary storage is Local storage.

It would be good to support even Local storage for the uploaded volumes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CLOUDSTACK-4115) [upgrade][2.2.14 to 4.2]After upgrade the ESX 4.1 host ends up in disconnected state with EncryptionOperationNotPossibleException

[Kishan Kavala (JIRA)]

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

Kishan Kavala resolved CLOUDSTACK-4115.
---

Resolution: Fixed

Below error is not related to encryption.  "StartCommand failed due to 
Exception: com.vmware.vim25.InvalidProperty 
message: "

It could be related to CLOUDSTACK-2316. Can you please open a separate bug for 
this.

> [upgrade][2.2.14 to 4.2]After upgrade the ESX 4.1 host ends up in 
> disconnected state with EncryptionOperationNotPossibleException
> -
>
> Key: CLOUDSTACK-4115
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4115
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Upgrade, VMware
>Affects Versions: 4.2.0
> Environment: upgrade from 2.2.14 to 4.2 on CentOS 5.6 management srver
> ESX 4.1 host
>Reporter: Abhinav Roy
>Assignee: Kishan Kavala
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: CS-4115.zip, DB_DUMP_Cloud_after_upgrade.dmp, 
> DB_DUMP_Cloud_before_upgrade.dmp, management-server-after_upgrade.log, 
> management-server-before_upgrade.log
>
>
> Steps :
> 
> 1. Deploy a CS advanced zone setup with CS 2.2.14
> 2. Do some configurations.
> 3. upgrade to 4.2, then run cloudstack-setup-encryption and start management 
> server
> Expected behaviour:
> ===
> The upgrade should go through and the host should stay connected 
> Observed behaviour :
> ===
> The host ends up in disconnected state after upgrade .
> 2013-08-06 21:37:01,972 DEBUG [agent.manager.ClusteredAgentManagerImpl] 
> (ClusteredAgentManager Timer:null) Loading directly connected host 
> 1(10.102.192.17)
> 2013-08-06 21:37:02,060 DEBUG [utils.crypt.DBEncryptionUtil] 
> (ClusteredAgentManager Timer:null) Error while decrypting: freebsd*123
> 2013-08-06 21:37:02,061 DEBUG [cloud.host.Status] (ClusteredAgentManager 
> Timer:null) Transition:[Resource state = Enabled, Agent event = 
> AgentDisconnected, Host id = 1, name = 10.102.192.17]
> 2013-08-06 21:37:02,071 DEBUG [cloud.host.Status] (ClusteredAgentManager 
> Timer:null) Agent status update: [id = 1; name = 10.102.192.17; old status = 
> Disconnected; event = AgentDisconnected; new status = Disconnected; old 
> update count = 4; new update count = 5]
> 2013-08-06 21:37:02,071 WARN  [agent.manager.ClusteredAgentManagerImpl] 
> (ClusteredAgentManager Timer:null)  can not load directly connected host 
> 1(10.102.192.17) due to
> org.jasypt.exceptions.EncryptionOperationNotPossibleException
> at 
> org.jasypt.encryption.pbe.StandardPBEByteEncryptor.decrypt(StandardPBEByteEncryptor.java:918)
> at 
> org.jasypt.encryption.pbe.StandardPBEStringEncryptor.decrypt(StandardPBEStringEncryptor.java:725)
> at 
> com.cloud.utils.crypt.DBEncryptionUtil.decrypt(DBEncryptionUtil.java:65)
> at 
> com.cloud.dc.ClusterDetailsDaoImpl.findDetails(ClusterDetailsDaoImpl.java:81)
> at 
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at 
> com.cloud.hypervisor.vmware.VmwareServerDiscoverer.buildConfigParams(VmwareServerDiscoverer.java:730)
> at 
> com.cloud.hypervisor.vmware.VmwareServerDiscoverer.reloadResource(VmwareServerDiscoverer.java:760)
> at 
> com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:743)
> at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:209)
> at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:175)
> at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:93)
> at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.run(ClusteredAgentManagerImpl.java:225)
> at java.util.TimerThread.mainLoop(Timer.java:534)
> at java.util.TimerThread.run(Timer.java:484)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-4115) [upgrade][2.2.14 to 4.2]After upgrade the ESX 4.1 host ends up in disconnected state with EncryptionOperationNotPossibleException

[Abhinav Roy (JIRA)]

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

Abhinav Roy commented on CLOUDSTACK-4115:
-

yes Kishan, it was upgrade but on VMs and host which were freshly installed. 
They were not the used vms and hosts.

> [upgrade][2.2.14 to 4.2]After upgrade the ESX 4.1 host ends up in 
> disconnected state with EncryptionOperationNotPossibleException
> -
>
> Key: CLOUDSTACK-4115
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4115
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Upgrade, VMware
>Affects Versions: 4.2.0
> Environment: upgrade from 2.2.14 to 4.2 on CentOS 5.6 management srver
> ESX 4.1 host
>Reporter: Abhinav Roy
>Assignee: Kishan Kavala
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: CS-4115.zip, DB_DUMP_Cloud_after_upgrade.dmp, 
> DB_DUMP_Cloud_before_upgrade.dmp, management-server-after_upgrade.log, 
> management-server-before_upgrade.log
>
>
> Steps :
> 
> 1. Deploy a CS advanced zone setup with CS 2.2.14
> 2. Do some configurations.
> 3. upgrade to 4.2, then run cloudstack-setup-encryption and start management 
> server
> Expected behaviour:
> ===
> The upgrade should go through and the host should stay connected 
> Observed behaviour :
> ===
> The host ends up in disconnected state after upgrade .
> 2013-08-06 21:37:01,972 DEBUG [agent.manager.ClusteredAgentManagerImpl] 
> (ClusteredAgentManager Timer:null) Loading directly connected host 
> 1(10.102.192.17)
> 2013-08-06 21:37:02,060 DEBUG [utils.crypt.DBEncryptionUtil] 
> (ClusteredAgentManager Timer:null) Error while decrypting: freebsd*123
> 2013-08-06 21:37:02,061 DEBUG [cloud.host.Status] (ClusteredAgentManager 
> Timer:null) Transition:[Resource state = Enabled, Agent event = 
> AgentDisconnected, Host id = 1, name = 10.102.192.17]
> 2013-08-06 21:37:02,071 DEBUG [cloud.host.Status] (ClusteredAgentManager 
> Timer:null) Agent status update: [id = 1; name = 10.102.192.17; old status = 
> Disconnected; event = AgentDisconnected; new status = Disconnected; old 
> update count = 4; new update count = 5]
> 2013-08-06 21:37:02,071 WARN  [agent.manager.ClusteredAgentManagerImpl] 
> (ClusteredAgentManager Timer:null)  can not load directly connected host 
> 1(10.102.192.17) due to
> org.jasypt.exceptions.EncryptionOperationNotPossibleException
> at 
> org.jasypt.encryption.pbe.StandardPBEByteEncryptor.decrypt(StandardPBEByteEncryptor.java:918)
> at 
> org.jasypt.encryption.pbe.StandardPBEStringEncryptor.decrypt(StandardPBEStringEncryptor.java:725)
> at 
> com.cloud.utils.crypt.DBEncryptionUtil.decrypt(DBEncryptionUtil.java:65)
> at 
> com.cloud.dc.ClusterDetailsDaoImpl.findDetails(ClusterDetailsDaoImpl.java:81)
> at 
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at 
> com.cloud.hypervisor.vmware.VmwareServerDiscoverer.buildConfigParams(VmwareServerDiscoverer.java:730)
> at 
> com.cloud.hypervisor.vmware.VmwareServerDiscoverer.reloadResource(VmwareServerDiscoverer.java:760)
> at 
> com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:743)
> at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:209)
> at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:175)
> at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:93)
> at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.run(ClusteredAgentManagerImpl.java:225)
> at java.util.TimerThread.mainLoop(Timer.java:534)
> at java.util.TimerThread.run(Timer.java:484)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-3229) Object_Store_Refactor - Snapshot fails due to an internal error

[Thomas O'Dowd (JIRA)]

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

Thomas O'Dowd commented on CLOUDSTACK-3229:
---

Confirming again that this still fails on a fresh build from today in the same 
way as described in a previous comment.

Min - Do you or Edison have any ideas on this?

Tom.

> Object_Store_Refactor - Snapshot fails due to an internal error
> ---
>
> Key: CLOUDSTACK-3229
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3229
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.2.0
> Environment: chrome on linux 
> devcloud 
> Cloudian or Amazon S3 Object store
>Reporter: Thomas O'Dowd
>Assignee: John Burwell
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: SMlog, SMlog.last_5000_lines.txt
>
>
> Assuming initial devcloud state... 
> I added a cache for the S3 storage like this. 
> on devcloud machine as root: 
> # mkdir /opt/storage/cache 
> # vi /etc/exports (and append this line) 
> /opt/storage/cache *(rw,no_subtree_check,no_root_squash,fsid=) 
> # exportfs -a 
> On Mgmt server GUI: 
> 1. navigate to infrastructure -> secondary storage 
> 2. delete the NFS SS. 
> 3. add S3 storage for Cloudian (I used 6 as the timeouts - assuming 
> millis). I used the /opt/storage/cache thing as the s3 cache.
> 4. nav to templates 
> 5. register a new template (I uploaded tinyLinux again as "mytiny" (5.3 
> 64bit)). 
> 6. confirm with s3cmd that 2 objects are now on S3. 
> - s3 objects --- 
> template/tmpl/1/1/routing-1/acton-systemvm-02062012.vhd.bz2 
> 2013-06-27T03:01:46.203Z None 140616708 "b533e7b65219439ee7fca0146ddd7ffa-27" 
> template/tmpl/2/201/201-2-ae9e9409-4c8e-3ad8-a62f-abec7a35fe26/tinylinux.vhd 
> 2013-06-27T03:04:06.730Z None 50430464 "4afac316e865adf74ca1a8039fae7399-10" 
> - s3 objects --- 
> 7. I restarted the management server at this point which actually resulted in 
> another object on S3. 
> - the new s3 object --- 
> template/tmpl/1/5/tiny Linux/ttylinux_pv.vhd 2013-06-27T03:43:26.494Z None 
> 50430464 "4afac316e865adf74ca1a8039fae7399-10" 
> - the new s3 object --- 
> 8. Go to instance and create a new choosing the "mytiny" template which we 
> registered. 
> 9. launch it after selecting all defaults. 
> 10. wait until it starts.
> 11. nav to storage. I see ROOT-8. Click on this to open.
> 12. click the camera to take the snapshot.
> after a pause I get a popup
>  "Failed to create snapshot due to an internal error creating snapshot 
> for volume 8"
> Also on the mgmt terminal I get the following log entry (only 1):
> INFO  [user.snapshot.CreateSnapshotCmd] (Job-Executor-8:job-16) VOLSS: 
> createSnapshotCmd starts:1372321251009
> If I check the "view snapshots" button under storage, I can however see the 
> snapshot. It says its on primary. I'm expecting it to go to secondary storage 
> though. Nothing is in the S3 logs and no snapshots.
> If I try to delete that snapshot from here I get this error in the logs:
> ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-12:job-20) Unexpected 
> exception while executing 
> org.apache.cloudstack.api.command.user.snapshot.DeleteSnapshotCmd
> com.cloud.utils.exception.CloudRuntimeException: Failed to delete 
> snapshot:com.cloud.exception.InvalidParameterValueException: Can't delete 
> snapshotshot 4 due to it is not in BackedUp Status
> at 
> com.cloud.storage.snapshot.SnapshotManagerImpl.deleteSnapshot(SnapshotManagerImpl.java:513)
> at 
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at 
> org.apache.cloudstack.api.command.user.snapshot.DeleteSnapshotCmd.execute(DeleteSnapshotCmd.java:96)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
> at 
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> If I navigate to instance, my instance, and try to take a vm snapshot from 
> here, I get a different pop-up which says:
>"There is other active volume snapshot tasks on the instance to wh

[jira] [Commented] (CLOUDSTACK-4115) [upgrade][2.2.14 to 4.2]After upgrade the ESX 4.1 host ends up in disconnected state with EncryptionOperationNotPossibleException

[Kishan Kavala (JIRA)]

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

Kishan Kavala commented on CLOUDSTACK-4115:
---

As per the bug description it was an upgrade from 2.2.14 and not fresh setup.

> [upgrade][2.2.14 to 4.2]After upgrade the ESX 4.1 host ends up in 
> disconnected state with EncryptionOperationNotPossibleException
> -
>
> Key: CLOUDSTACK-4115
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4115
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Upgrade, VMware
>Affects Versions: 4.2.0
> Environment: upgrade from 2.2.14 to 4.2 on CentOS 5.6 management srver
> ESX 4.1 host
>Reporter: Abhinav Roy
>Assignee: Kishan Kavala
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: CS-4115.zip, DB_DUMP_Cloud_after_upgrade.dmp, 
> DB_DUMP_Cloud_before_upgrade.dmp, management-server-after_upgrade.log, 
> management-server-before_upgrade.log
>
>
> Steps :
> 
> 1. Deploy a CS advanced zone setup with CS 2.2.14
> 2. Do some configurations.
> 3. upgrade to 4.2, then run cloudstack-setup-encryption and start management 
> server
> Expected behaviour:
> ===
> The upgrade should go through and the host should stay connected 
> Observed behaviour :
> ===
> The host ends up in disconnected state after upgrade .
> 2013-08-06 21:37:01,972 DEBUG [agent.manager.ClusteredAgentManagerImpl] 
> (ClusteredAgentManager Timer:null) Loading directly connected host 
> 1(10.102.192.17)
> 2013-08-06 21:37:02,060 DEBUG [utils.crypt.DBEncryptionUtil] 
> (ClusteredAgentManager Timer:null) Error while decrypting: freebsd*123
> 2013-08-06 21:37:02,061 DEBUG [cloud.host.Status] (ClusteredAgentManager 
> Timer:null) Transition:[Resource state = Enabled, Agent event = 
> AgentDisconnected, Host id = 1, name = 10.102.192.17]
> 2013-08-06 21:37:02,071 DEBUG [cloud.host.Status] (ClusteredAgentManager 
> Timer:null) Agent status update: [id = 1; name = 10.102.192.17; old status = 
> Disconnected; event = AgentDisconnected; new status = Disconnected; old 
> update count = 4; new update count = 5]
> 2013-08-06 21:37:02,071 WARN  [agent.manager.ClusteredAgentManagerImpl] 
> (ClusteredAgentManager Timer:null)  can not load directly connected host 
> 1(10.102.192.17) due to
> org.jasypt.exceptions.EncryptionOperationNotPossibleException
> at 
> org.jasypt.encryption.pbe.StandardPBEByteEncryptor.decrypt(StandardPBEByteEncryptor.java:918)
> at 
> org.jasypt.encryption.pbe.StandardPBEStringEncryptor.decrypt(StandardPBEStringEncryptor.java:725)
> at 
> com.cloud.utils.crypt.DBEncryptionUtil.decrypt(DBEncryptionUtil.java:65)
> at 
> com.cloud.dc.ClusterDetailsDaoImpl.findDetails(ClusterDetailsDaoImpl.java:81)
> at 
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at 
> com.cloud.hypervisor.vmware.VmwareServerDiscoverer.buildConfigParams(VmwareServerDiscoverer.java:730)
> at 
> com.cloud.hypervisor.vmware.VmwareServerDiscoverer.reloadResource(VmwareServerDiscoverer.java:760)
> at 
> com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:743)
> at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:209)
> at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:175)
> at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:93)
> at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.run(ClusteredAgentManagerImpl.java:225)
> at java.util.TimerThread.mainLoop(Timer.java:534)
> at java.util.TimerThread.run(Timer.java:484)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (CLOUDSTACK-2603) Response of RunInstances doesn't contain the right value for attribute 'hypervisor'

[Likitha Shetty (JIRA)]

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

Likitha Shetty closed CLOUDSTACK-2603.
--


> Response of RunInstances doesn't contain the right value for attribute 
> 'hypervisor'
> ---
>
> Key: CLOUDSTACK-2603
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2603
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: AWSAPI
>Affects Versions: 4.1.0
>Reporter: Likitha Shetty
>Assignee: Likitha Shetty
>Priority: Trivial
> Fix For: 4.2.0
>
>
> In EC2RunInstnaces response "hypervisor" value is returned to the client as 
> XenServer.
> The Valid values according the aws docs is xen or ovm only
> [Ref: 
> http://docs.amazonwebservices.com/AWSEC2/latest/APIReference/ApiReference-ItemType-RunningInstancesItemType.html]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (CLOUDSTACK-1022) Release Dedicated Public IP Address range back to the free pool

[Likitha Shetty (JIRA)]

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

Likitha Shetty closed CLOUDSTACK-1022.
--


> Release Dedicated Public IP Address range back to the free pool
> ---
>
> Key: CLOUDSTACK-1022
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1022
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.0.0
>Reporter: Likitha Shetty
>Assignee: Likitha Shetty
> Fix For: 4.2.0
>
>
> Currently in CloudStack we can assign Public IP Addresses per tenant. Add the 
> functionality to allow users to release the address range back to the free 
> pool,

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (CLOUDSTACK-2576) AWS API not returning values in CFSimpleXML Object format

[Likitha Shetty (JIRA)]

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

Likitha Shetty closed CLOUDSTACK-2576.
--


Verified

> AWS API not returning values in CFSimpleXML Object format
> -
>
> Key: CLOUDSTACK-2576
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2576
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: AWSAPI
>Affects Versions: 4.1.0
>Reporter: Likitha Shetty
>Assignee: Likitha Shetty
> Fix For: 4.2.0
>
>
> Response body of Query API response for AWS PHP SDK is CFSimpleXML whereas 
> response body of CS AWSAPI response is not. 
> Sample - 
> Response body returned by CS AWSAPI 
>  encoding='UTF-8'?>c7ea6e63-5e35-43fb-ab8a-99bcfbd043c4zone1availableDisabled
>  
> Expected response body 
> CFSimpleXML Object 
> ( 
> [requestId] => c7ea6e63-5e35-43fb-ab8a-99bcfbd043c4 
> [availabilityZoneInfo] => CFSimpleXML Object 
> ( 
> [item] => CFSimpleXML Object 
> ( 
> [zoneName] => zone1 
> [zoneState] => available 
> [regionName] => CFSimpleXML Object 
> ( 
> ) 
> [messageSet] => CFSimpleXML Object 
> ( 
> [item] => CFSimpleXML Object 
> ( 
> [message] => Disabled 
> ) 
> ) 
> ) 
> ) 
> ) 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (CLOUDSTACK-2599) Fix EC2 Rest to support tag related EC2 API's

[Likitha Shetty (JIRA)]

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

Likitha Shetty closed CLOUDSTACK-2599.
--


> Fix EC2 Rest to support tag related EC2 API's
> -
>
> Key: CLOUDSTACK-2599
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2599
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: AWSAPI
>Affects Versions: 4.1.0
>Reporter: Likitha Shetty
>Assignee: Likitha Shetty
> Fix For: 4.2.0
>
>
> In AWSAPI only soap calls support the tags related API's. -  
> CreateTags/DeleteTags/DescribeTags.
> EC2 Query API is missing this support. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-4099) update the systemvm templates in DevCloud2

[Prasanna Santhanam (JIRA)]

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

Prasanna Santhanam commented on CLOUDSTACK-4099:


[~aprateek] The template is pre-seeded into devcloud. we need to reseed the new 
one and create a new template. There is no mechanism to autoupdate it, but it 
can be added. If you are concerned about the '4.2' affectsVersion - this fix is 
not important to be done now, can be deferred to be updated later. But would be 
nice if we can fix, upgrade all our toolchains to go in the same cadence as the 
releases.

> update the systemvm templates in DevCloud2
> --
>
> Key: CLOUDSTACK-4099
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4099
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: DevCloud
>Affects Versions: 4.2.0
>Reporter: Prasanna Santhanam
>Priority: Critical
>
> DevCloud2 is still using the old templates for systemVMs. These need to be
> updated to the latest stable templates available from jenkins. Fixes exist for
> 1. vm time sync with hypervisor
> 2. vhd-util within systemvm
> 3. latest haproxy
> 4. irqbalance fix
> etc

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-4149) [upgrade][2.2.13 -> 2.2.14 -> 4.2][KVM] When we try to upgrade the KVM agent from 2.2.14 to 4.2 using the "U" option in install.sh script, management server also get

[Abhinav Roy (JIRA)]

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

Abhinav Roy updated CLOUDSTACK-4149:


Priority: Blocker  (was: Critical)

> [upgrade][2.2.13 -> 2.2.14 -> 4.2][KVM] When we try to upgrade the KVM agent 
> from 2.2.14 to 4.2 using the "U" option in install.sh script, management 
> server also gets installed!
> -
>
> Key: CLOUDSTACK-4149
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4149
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Packaging, Upgrade
>Affects Versions: 4.2.0
> Environment: upgrade from 2.2.13 (rhel 6.1 build) -> 2.2.14 (rhel 6.1 
> build) -> 4.2 (rhel 6.2 build) 
> MS : CentOS 6.1 
> KVM : CentOS 6.1
>Reporter: Abhinav Roy
>Priority: Blocker
> Fix For: 4.2.0
>
>
> 1. Deploy a CS 2.2.13 advanced zone setup.
> 2. Do some operations and upgrade to 2.2.14
> 3. Now when we try to upgrade it from 2.2.14 to 4.2 using the "U" option in 
> install.sh script, it installs the management server also.
> [root@centos61-band28 CloudPlatform-4.2-4.2-104-rhel6.2]# ./install.sh
> Setting up the temporary repository...
> Cleaning Yum cache...
> Loaded plugins: fastestmirror
> Cleaning repos: cloud-temp rhel
> 2 metadata files removed
> Welcome to the CloudPlatform Installer.  What would you like to do?
> NOTE:   For installing KVM agent, please setup 
> EPEL yum repo first;
> For installing CloudPlatform on RHEL6.x, please setup 
> distribution yum repo either from ISO or from your registeration account.
> M) Install the Management Server
> A) Install the Agent
> B) Install BareMetal Agent
> S) Install the Usage Monitor
> D) Install the database server (from distribution's repo)
> U) Upgrade the CloudPlatform packages installed on this computer
> R) Stop any running CloudPlatform services and remove the CloudPlatform 
> packages from this computer
> L) Install the MySQL 5.1.58 (only for CentOS5.x, Rhel6.x naturally has 
> higher version MySql)
> Q) Quit
>  > u
> Updating the CloudPlatform and its dependencies...
> Loaded plugins: fastestmirror
> Loading mirror speeds from cached hostfile
> cloud-temp
>   
> | 1.3 kB 00:00 ...
> rhel  
>   
> | 4.0 kB 00:00 ...
> Setting up Update Process
> Resolving Dependencies
> --> Running transaction check
> ---> Package cloud-agent.x86_64 0:2.2.14-1.el6 will be obsoleted
> ---> Package cloud-agent-libs.x86_64 0:2.2.14-1.el6 will be obsoleted
> ---> Package cloud-core.x86_64 0:2.2.14-1.el6 will be obsoleted
> ---> Package cloud-daemonize.x86_64 0:2.2.14-1.el6 will be obsoleted
> ---> Package cloud-deps.x86_64 0:2.2.14-1.el6 will be obsoleted
> ---> Package cloud-python.x86_64 0:2.2.14-1.el6 will be obsoleted
> ---> Package cloud-utils.x86_64 0:2.2.14-1.el6 will be obsoleted
> ---> Package cloudstack-agent.x86_64 0:4.2.0-SNAPSHOT.el6 will be obsoleting
> --> Processing Dependency: jakarta-commons-daemon for package: 
> cloudstack-agent-4.2.0-SNAPSHOT.el6.x86_64
> --> Processing Dependency: ipset for package: 
> cloudstack-agent-4.2.0-SNAPSHOT.el6.x86_64
> ---> Package cloudstack-common.x86_64 0:4.2.0-SNAPSHOT.el6 will be obsoleting
> ---> Package cloudstack-management.x86_64 0:4.2.0-SNAPSHOT.el6 will be 
> obsoleting
> --> Processing Dependency: cloudstack-awsapi = 4.2.0 for package: 
> cloudstack-management-4.2.0-SNAPSHOT.el6.x86_64
> --> Processing Dependency: ws-commons-util for package: 
> cloudstack-management-4.2.0-SNAPSHOT.el6.x86_64
> --> Processing Dependency: tomcat6 for package: 
> cloudstack-management-4.2.0-SNAPSHOT.el6.x86_64
> --> Processing Dependency: mysql-connector-java for package: 
> cloudstack-management-4.2.0-SNAPSHOT.el6.x86_64
> --> Processing Dependency: mkisofs for package: 
> cloudstack-management-4.2.0-SNAPSHOT.el6.x86_64
> --> Processing Dependency: ipmitool for package: 
> cloudstack-management-4.2.0-SNAPSHOT.el6.x86_64
> --> Processing Dependency: MySQL-python for package: 
> cloudstack-management-4.2.0-SNAPSHOT.el6.x86_64
> --> Running transaction check
> ---> Package MySQL-python.x86_64 0:1.2.3-0.3.c1.1.el6 will be installed
> ---> Package cloudstack-awsapi.x86_64 0:4.2.0-SNAPSHOT.el6 will be installed
> ---> Package genisoimage.x86_64 0:1.1.9

[jira] [Closed] (CLOUDSTACK-2623) AWSAPI - Translate CS error to appropriate AWS EC2 error codes

[Likitha Shetty (JIRA)]

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

Likitha Shetty closed CLOUDSTACK-2623.
--


> AWSAPI - Translate CS error to appropriate AWS EC2 error codes
> --
>
> Key: CLOUDSTACK-2623
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2623
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: AWSAPI
>Affects Versions: 4.1.0
>Reporter: Likitha Shetty
>Assignee: Likitha Shetty
> Fix For: 4.2.0
>
>
> When CS AWSAPI errors out for any API the error code is CS error code and not 
> AWS EC2 error codes.
> Translate the CS error to AWS EC2 error codes whenever applicable for all 
> supported AWS EC2 APIs in CS.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (CLOUDSTACK-2600) EC2DescribeImages - missing filter support

[Likitha Shetty (JIRA)]

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

Likitha Shetty closed CLOUDSTACK-2600.
--


> EC2DescribeImages - missing filter support
> --
>
> Key: CLOUDSTACK-2600
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2600
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: AWSAPI
>Affects Versions: 4.1.0
>Reporter: Likitha Shetty
>Assignee: Likitha Shetty
>Priority: Minor
> Fix For: 4.2.0
>
>
> After investigating the filter support by AWS EC2 for DescribeImages API the 
> following filters seem to be missing from the CS AWSAPI - 
> architecture 
> description
> image-id
> image-type
> is-public 
> name
> owner-id 
> state
> tag-key
> tag-value 
> tag:key
> hypervisor

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-4099) update the systemvm templates in DevCloud2

[Abhinandan Prateek (JIRA)]

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

Abhinandan Prateek commented on CLOUDSTACK-4099:


Prasanna, Is this a packaging issue ? Why can't Devcloud2 build pick up the new 
templates generated by jenkins ?

> update the systemvm templates in DevCloud2
> --
>
> Key: CLOUDSTACK-4099
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4099
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: DevCloud
>Affects Versions: 4.2.0
>Reporter: Prasanna Santhanam
>Priority: Critical
>
> DevCloud2 is still using the old templates for systemVMs. These need to be
> updated to the latest stable templates available from jenkins. Fixes exist for
> 1. vm time sync with hypervisor
> 2. vhd-util within systemvm
> 3. latest haproxy
> 4. irqbalance fix
> etc

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (CLOUDSTACK-1450) AWSAPI server fails to start

[Likitha Shetty (JIRA)]

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

Likitha Shetty closed CLOUDSTACK-1450.
--


> AWSAPI server fails to start
> 
>
> Key: CLOUDSTACK-1450
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1450
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: AWSAPI
>Affects Versions: 4.1.0
>Reporter: Likitha Shetty
>Assignee: Likitha Shetty
>Priority: Critical
>
> On master commit: 1d31c3ecaf7466e3e8bb1ce08d413f3a88b4323a
> Run 'mvn -Pawsapi -pl :cloud-awsapi jetty:run' to start the awsapi webapp. 
> The following error is observed
> INFO: Destroying singletons in 
> org.springframework.beans.factory.support.DefaultListableBeanFactory@120f0be: 
> defining beans 
> [org.springframework.context.annotation.internalConfigurationAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor,org.springframework.context.annotation.internalCommonAnnotationProcessor,EC2RestServlet,serviceProvider,EC2MainServlet,EC2Engine,s3Engine,SObjectItemDaoImpl,offeringDaoImpl,multiPartPartsDaoImpl,SMetaDaoImpl,cloudStackSvcOfferingDaoImpl,multipartMetaDaoImpl,cloudStackConfigurationDaoImpl,bucketPolicyDaoImpl,SHostDaoImpl,multiPartUploadsDaoImpl,SObjectDaoImpl,MHostMountDaoImpl,userCredentialsDaoImpl,MHostDaoImpl,cloudStackAccountDaoImpl,SBucketDaoImpl,SAclDaoImpl,componentContext,org.springframework.aop.config.internalAutoProxyCreator,org.springframework.aop.aspectj.AspectJPointcutAdvisor#0,captureAnyMethod,transactionContextBuilder,org.springframework.context.annotation.ConfigurationClassPostProcessor$ImportAwareBeanPostProcessor#0];
>  root of factory hierarchy
> 28 Feb, 2013 4:26:21 PM org.springframework.web.context.ContextLoader 
> initWebApplicationContext
> SEVERE: Context initialization failed
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'EC2RestServlet': Injection of autowired dependencies failed; 
> nested exception is org.springframework.beans.factory.BeanCreationException: 
> Could not autowire field: com.cloud.bridge.persist.dao.CloudStackUserDaoImpl 
> com.cloud.bridge.service.EC2RestServlet.userDao; nested exception is 
> org.springframework.beans.factory.NoSuchBeanDefinitionException: No matching 
> bean of type [com.cloud.bridge.persist.dao.CloudStackUserDaoImpl] found for 
> dependency: expected at least 1 bean which qualifies as autowire candidate 
> for this dependency. Dependency annotations: {@javax.inject.Inject()}
> at 
> org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:287)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1106)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:517)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
> at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
> at 
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:609)
> at 
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:918)
> at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:469)
> at 
> org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:383)
> at 
> org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:283)
> at 
> org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:111)
> Caused by: org.springframework.beans.factory.BeanCreationException: Could not 
> autowire field: com.cloud.bridge.persist.dao.CloudStackUserDaoImpl 
> com.cloud.bridge.service.EC2RestServlet.userDao; nested exception is 
> org.springframewo

[jira] [Updated] (CLOUDSTACK-804) Document Support non-contiguous VLAN ranges

[Radhika Nair (JIRA)]

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

Radhika Nair updated CLOUDSTACK-804:


Attachment: (was: Apache_CloudStack-4.2.0-Admin_Guide-en-US.pdf)

> Document Support non-contiguous VLAN ranges
> ---
>
> Key: CLOUDSTACK-804
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-804
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Radhika Nair
>Assignee: Radhika Nair
> Fix For: 4.2.0
>
> Attachments: Apache_CloudStack-4.2.0-Admin_Guide-en-US.pdf
>
>
> Document Support non-contiguous VLAN ranges

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-4136) [upgraded ENV]Deleting Snapshot which was created before upgrade is throwing NPE.

[manasaveloori (JIRA)]

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

manasaveloori updated CLOUDSTACK-4136:
--

Attachment: mysqldumpAfterUpnew.dmp
mysqldumpBeforeUp.dmp

> [upgraded ENV]Deleting Snapshot which was created before upgrade is throwing 
> NPE.
> -
>
> Key: CLOUDSTACK-4136
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4136
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller, Upgrade
>Affects Versions: 4.2.0
> Environment: upgraded from 3.0.7 to 4.2
>Reporter: manasaveloori
>Assignee: Koushik Das
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.zip, mysqldumpAfterUpnew.dmp, 
> mysqldumpBeforeUp.dmp
>
>
> Steps:
> 1.Have CS with 3.0.7 build with VMware and Xen hypervisor.
> 2.Deploy a VM.
> 3.Create a snapshot of root volume.
> 4.Upgrade the build to 4.2.
> 5.Try to delete the snapshot now.
> Observing NPE while deleting the snapshot for the 1st time
> Tried to delete the same snapshot again deletes it. Verified the state of 
> snapshot in DB also.
> 2013-08-07 20:29:19,535 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null) 
> ===END===  10.252.192.69 -- GET  
> command=deleteSnapshot&id=acf6d258-99fa-4832-8499-a81a631627ce&response=json&sessionkey=uKcUJCauPB9Gj8yRMfQdmpPpTAE%3D&_=1375868166341
> 2013-08-07 20:29:19,539 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-43:job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]) 
> Executing org.apache.cloudstack.api.command.user.snapshot.DeleteSnapshotCmd 
> for job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]
> 2013-08-07 20:29:19,573 DEBUG [storage.snapshot.XenserverSnapshotStrategy] 
> (Job-Executor-43:job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]) Can't 
> find snapshot on backup storage, delete it in db
> 2013-08-07 20:29:19,582 DEBUG [storage.snapshot.SnapshotManagerImpl] 
> (Job-Executor-43:job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]) Failed 
> to delete snapshot: 1:java.lang.NullPointerException
> 2013-08-07 20:29:19,596 ERROR [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-43:job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]) 
> Unexpected exception while executing 
> org.apache.cloudstack.api.command.user.snapshot.DeleteSnapshotCmd
> com.cloud.utils.exception.CloudRuntimeException: Failed to delete 
> snapshot:java.lang.NullPointerException
> at 
> com.cloud.storage.snapshot.SnapshotManagerImpl.deleteSnapshot(SnapshotManagerImpl.java:508)
> at 
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at 
> org.apache.cloudstack.api.command.user.snapshot.DeleteSnapshotCmd.execute(DeleteSnapshotCmd.java:96)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at 
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-08-07 20:29:19,600 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-43:job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]) Complete 
> async job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ], jobStatus: 2, 
> resultCode: 530, result: Error Code: 530 Error text: Failed to delete 
> snapshot:java.lang.NullPointerException
> 2013-08-07 20:29:20,718 DEBUG [cloud.server.StatsCollector] 
> (StatsCollector-2:null) VmStatsCollector is running...
> Attaching the MS logs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (CLOUDSTACK-2624) AWSAPI - Support ModifyInstanceAttribute API

[Likitha Shetty (JIRA)]

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

Likitha Shetty closed CLOUDSTACK-2624.
--


> AWSAPI - Support ModifyInstanceAttribute API
> 
>
> Key: CLOUDSTACK-2624
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2624
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: AWSAPI
>Affects Versions: 4.1.0
>Reporter: Likitha Shetty
>Assignee: Likitha Shetty
> Fix For: 4.2.0
>
>
> It is not possible to change the resources assigned to a VM using the AWS API 
> since we do not currently support ModifyInstanceAttribute API in CS AWSAPI

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-804) Document Support non-contiguous VLAN ranges

[Radhika Nair (JIRA)]

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

Radhika Nair updated CLOUDSTACK-804:


Attachment: Apache_CloudStack-4.2.0-Admin_Guide-en-US.pdf

> Document Support non-contiguous VLAN ranges
> ---
>
> Key: CLOUDSTACK-804
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-804
> Project: CloudStack
>  Issue Type: Sub-task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Radhika Nair
>Assignee: Radhika Nair
> Fix For: 4.2.0
>
> Attachments: Apache_CloudStack-4.2.0-Admin_Guide-en-US.pdf
>
>
> Document Support non-contiguous VLAN ranges

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-4136) [upgraded ENV]Deleting Snapshot which was created before upgrade is throwing NPE.

[manasaveloori (JIRA)]

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

manasaveloori commented on CLOUDSTACK-4136:
---

mysql> select * from snapshots where id = 4 ;
++++---+---+--+---+--++--+---+--++-+-++--++--+-+-+---+
| id | data_center_id | account_id | domain_id | volume_id | disk_offering_id | 
status| path | name   | uuid
 | snapshot_type | type_description | size   | created 
| removed | backup_snap_id | swift_id | sechost_id | prev_snap_id | 
hypervisor_type | version | s3_id |
++++---+---+--+---+--++--+---+--++-+-++--++--+-+-+---+
|  4 |  2 |  2 | 1 |10 |   11 | 
Destroyed | NULL | VMwLocBU_ROOT-9_20130806161732 | 
b16ab7e0-0545-4b2f-aff0-e7bd2b7b6e1b | 0 | MANUAL   | 
2147483648 | 2013-08-06 16:17:32 | NULL| NULL   | NULL |   
NULL | NULL | VMware  | 2.2 |  NULL |
++++---+---+--+---+--++--+---+--++-+-++--++--+-+-+---+
1 row in set (0.00 sec)
Will attach the DB dumps before and after upgrade.

> [upgraded ENV]Deleting Snapshot which was created before upgrade is throwing 
> NPE.
> -
>
> Key: CLOUDSTACK-4136
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4136
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller, Upgrade
>Affects Versions: 4.2.0
> Environment: upgraded from 3.0.7 to 4.2
>Reporter: manasaveloori
>Assignee: Koushik Das
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.zip
>
>
> Steps:
> 1.Have CS with 3.0.7 build with VMware and Xen hypervisor.
> 2.Deploy a VM.
> 3.Create a snapshot of root volume.
> 4.Upgrade the build to 4.2.
> 5.Try to delete the snapshot now.
> Observing NPE while deleting the snapshot for the 1st time
> Tried to delete the same snapshot again deletes it. Verified the state of 
> snapshot in DB also.
> 2013-08-07 20:29:19,535 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null) 
> ===END===  10.252.192.69 -- GET  
> command=deleteSnapshot&id=acf6d258-99fa-4832-8499-a81a631627ce&response=json&sessionkey=uKcUJCauPB9Gj8yRMfQdmpPpTAE%3D&_=1375868166341
> 2013-08-07 20:29:19,539 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-43:job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]) 
> Executing org.apache.cloudstack.api.command.user.snapshot.DeleteSnapshotCmd 
> for job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]
> 2013-08-07 20:29:19,573 DEBUG [storage.snapshot.XenserverSnapshotStrategy] 
> (Job-Executor-43:job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]) Can't 
> find snapshot on backup storage, delete it in db
> 2013-08-07 20:29:19,582 DEBUG [storage.snapshot.SnapshotManagerImpl] 
> (Job-Executor-43:job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]) Failed 
> to delete snapshot: 1:java.lang.NullPointerException
> 2013-08-07 20:29:19,596 ERROR [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-43:job-215 = [ 055cd377-272a-4ee6-a9c9-5b57fbbf6536 ]) 
> Unexpected exception while executing 
> org.apache.cloudstack.api.command.user.snapshot.DeleteSnapshotCmd
> com.cloud.utils.exception.CloudRuntimeException: Failed to delete 
> snapshot:java.lang.NullPointerException
> at 
> com.cloud.storage.snapshot.SnapshotManagerImpl.deleteSnapshot(SnapshotManagerImpl.java:508)
> at 
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at 
> org.apache.cloudstack.api.command.user.snapshot.DeleteSnapshotCmd.execute(DeleteSnapshotCmd.java:96)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:

[jira] [Commented] (CLOUDSTACK-4134) UI dosent fire the API with the Vlan values if the Vlan range is blank.

[Bharat Kumar (JIRA)]

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

Bharat Kumar commented on CLOUDSTACK-4134:
--

The UI should pass vlan=  when the vlan text box in the UI is empty.

Jessica can you take a look at this.

> UI dosent fire the API with the Vlan values if the Vlan range is blank.
> ---
>
> Key: CLOUDSTACK-4134
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4134
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.2.0
>Reporter: Kiran Koneti
>Assignee: Bharat Kumar
>Priority: Critical
> Fix For: 4.2.0
>
>
> When we try to edit the Vlan range from the UI and give blank values in the 
> Vlan range box and try to update the page the API fried doesn't have any Vlan 
> details as it is blank in the UI.
> Eg:
> I tried the below scenario:
> 1)Created a setup with the Vlan range 1100-1109.
> 2)Then created a network where the Vlan 1101 is associated with the network.
> 3)Now I tried to edit the Vlan range and gave the blank value in the UI and 
> clicked update.
> The API fired is as below
> "10.147.38.237:8080/client/api?command=updatePhysicalNetwork&response=json&sessionkey=RRxhiAqmggnl%2F5oBGHNTm3DMj0M%3D&id=2409aeac-789a-4430-a9b7-fab66eb4b85c&_=1375867127326"
> Here the Vlan details are not fired in the API.
> Then I tried to edit it by giving the value 1102-1109  and  the API fired was 
> as below:
> "http://10.147.38.237:8080/client/api?command=updatePhysicalNetwork&response=json&sessionkey=RRxhiAqmggnl%2F5oBGHNTm3DMj0M%3D&id=2409aeac-789a-4430-a9b7-fab66eb4b85c&vlan=1102-1109&_=1375867287606";
> The API was fired currently with the Vlan values and there was a error 
> message as below
> "physicalnetwork 200 has allocated vnets in the range 1100-1101 " the below 
> is the expected behaviour and the same should happen when we try to update 
> the UI with Blank details.
> Note: Even the UI doesn't popup with any error message the Vlan range is not 
> getting deleted and we can see the same vlan range once we refresh the page.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-4130) [VMware][Upgraded ENV]Extract volume is failing .

[Abhinandan Prateek (JIRA)]

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

Abhinandan Prateek updated CLOUDSTACK-4130:
---

Assignee: Nitin Mehta

> [VMware][Upgraded ENV]Extract volume is failing .
> -
>
> Key: CLOUDSTACK-4130
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4130
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller, Upgrade, VMware
>Affects Versions: 4.2.0
> Environment: upgraded from 3.0.7 to 4.2
>Reporter: manasaveloori
>Assignee: Nitin Mehta
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.zip
>
>
> Steps:
> 1.Have a CS with 3.0.7 build.(local+shared storage)
> 2.Deploy some VMs .
> 3.Upgrade it to 4.2.
> 4.Now create a 2 data volumes using shared storage and local storage.
> 5.Extract/download the volume.
> Observed the following exception:
> 2013-08-07 18:07:02,283 DEBUG [agent.manager.AgentManagerImpl] 
> (AgentManager-Handler-7:null) SeqA 4-10295: Processing Seq 4-10295:  { Cmd , 
> MgmtId: -1, via: 4, Ver: v1, Flags: 11, 
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
>   \"connections\": []\n}","wait":0}}] }
> 2013-08-07 18:07:02,322 DEBUG [agent.manager.AgentManagerImpl] 
> (AgentManager-Handler-7:null) SeqA 4-10295: Sending Seq 4-10295:  { Ans: , 
> MgmtId: 7067804893289, via: 4, Ver: v1, Flags: 100010, 
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2013-08-07 18:07:02,341 ERROR [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-23:job-195 = [ 2618617b-2db8-45bd-89b8-de6f7345410a ]) 
> Unexpected exception while executing 
> org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd
> com.cloud.utils.exception.CloudRuntimeException: Failed to copy the volume 
> from the source primary storage pool to secondary storage.
> at 
> com.cloud.storage.VolumeManagerImpl.extractVolume(VolumeManagerImpl.java:2802)
> at 
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at 
> org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd.execute(ExtractVolumeCmd.java:130)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at 
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-08-07 18:07:02,345 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-23:job-195 = [ 2618617b-2db8-45bd-89b8-de6f7345410a ]) Complete 
> async job-195 = [ 2618617b-2db8-45bd-89b8-de6f7345410a ], jobStatus: 2, 
> resultCode: 530, result: Error Code: 530 Error text: Failed to copy the 
> volume from the source primary storage pool to secondary storage.
> 2013-08-07 18:07:02,430 DEBUG [cloud.api.ApiServlet] (catalina-exec-15:null) 
> ===START===  10.252.192.69 -- GET  
> command=queryAsyncJobResult&jobId=2618617b-2db8-45bd-89b8-de6f7345410a&response=json&sessionkey=S0fQy1QOJzjKvLuHo5Ww76y0f2c%3D&_=1375859629613
> Attached the MS logs.
> Verified with Xen server host. Working fine.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-4134) UI dosent fire the API with the Vlan values if the Vlan range is blank.

[Bharat Kumar (JIRA)]

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

Bharat Kumar updated CLOUDSTACK-4134:
-

Assignee: Jessica Wang  (was: Bharat Kumar)

> UI dosent fire the API with the Vlan values if the Vlan range is blank.
> ---
>
> Key: CLOUDSTACK-4134
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4134
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.2.0
>Reporter: Kiran Koneti
>Assignee: Jessica Wang
>Priority: Critical
> Fix For: 4.2.0
>
>
> When we try to edit the Vlan range from the UI and give blank values in the 
> Vlan range box and try to update the page the API fried doesn't have any Vlan 
> details as it is blank in the UI.
> Eg:
> I tried the below scenario:
> 1)Created a setup with the Vlan range 1100-1109.
> 2)Then created a network where the Vlan 1101 is associated with the network.
> 3)Now I tried to edit the Vlan range and gave the blank value in the UI and 
> clicked update.
> The API fired is as below
> "10.147.38.237:8080/client/api?command=updatePhysicalNetwork&response=json&sessionkey=RRxhiAqmggnl%2F5oBGHNTm3DMj0M%3D&id=2409aeac-789a-4430-a9b7-fab66eb4b85c&_=1375867127326"
> Here the Vlan details are not fired in the API.
> Then I tried to edit it by giving the value 1102-1109  and  the API fired was 
> as below:
> "http://10.147.38.237:8080/client/api?command=updatePhysicalNetwork&response=json&sessionkey=RRxhiAqmggnl%2F5oBGHNTm3DMj0M%3D&id=2409aeac-789a-4430-a9b7-fab66eb4b85c&vlan=1102-1109&_=1375867287606";
> The API was fired currently with the Vlan values and there was a error 
> message as below
> "physicalnetwork 200 has allocated vnets in the range 1100-1101 " the below 
> is the expected behaviour and the same should happen when we try to update 
> the UI with Blank details.
> Note: Even the UI doesn't popup with any error message the Vlan range is not 
> getting deleted and we can see the same vlan range once we refresh the page.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-4133) hitting MySQLIntegrityConstraintViolationException for key 'i_template_spool_ref__template_id__pool_id' in case of parallel deployment

[Abhinandan Prateek (JIRA)]

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

Abhinandan Prateek updated CLOUDSTACK-4133:
---

Assignee: Nitin Mehta

> hitting MySQLIntegrityConstraintViolationException for key 
> 'i_template_spool_ref__template_id__pool_id'  in case of parallel deployment
> ---
>
> Key: CLOUDSTACK-4133
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4133
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.2.0
> Environment: xenserver advanced zone
>Reporter: shweta agarwal
>Assignee: Nitin Mehta
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.tar.gz
>
>
> Deploying 30 VMs in Parallel on xenserver host
> getting following exception ..though not consistently 
> 2013-08-07 01:06:38,694 DEBUG [db.Transaction.Transaction] 
> (Job-Executor-103:job-177 = [ 504ce7c1-ec29-4edb-9ef6-073c89f23f21 ]) Rolling 
> back the transaction: Time = 11934 Name =  
> -AsyncJobManagerImpl$1.run:494-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRun:334-FutureTask.run:166-ThreadPoolExecutor.runWorker:1110-ThreadPoolExecutor$Worker.run:603-Thread.run:679;
>  called by 
> -Transaction.rollback:896-Transaction.removeUpTo:839-Transaction.close:663-TransactionContextBuilder.interceptException:63-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:133-PrimaryDataStoreImpl.create:239-VolumeServiceImpl.createBaseImageAsync:387-VolumeServiceImpl.createVolumeFromTemplateAsync:538-VolumeManagerImpl.recreateVolume:2488-VolumeManagerImpl.prepare:2545-VirtualMachineManagerImpl.advanceStart:934-VirtualMachineManagerImpl.start:624
> 2013-08-07 01:06:39,552 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-197:null) Seq 1-122749286: Response Received:
> 2013-08-07 01:06:39,553 DEBUG [agent.transport.Request] 
> (DirectAgent-197:null) Seq 1-122749286: Processing:  { Ans: , MgmtId: 
> 7200344900649, via: 1, Ver: v1, Flags: 10, 
> [{"com.cloud.agent.api.Answer":{"result":true,"wait":0}}] }
> 2013-08-07 01:06:39,557 DEBUG [agent.transport.Request] 
> (Job-Executor-121:job-195 = [ 23b53290-6961-4913-a5ba-31fdcb453a79 ]) Seq 
> 1-122749286: Received:  { Ans: , MgmtId: 7200344900649, via: 1, Ver: v1, 
> Flags: 10, { Answer } }
> 2013-08-07 01:06:39,559 DEBUG [storage.datastore.PrimaryDataStoreImpl] 
> (Job-Executor-120:job-194 = [ cac12fea-d3ed-4764-aee5-9e292b555024 ]) Failed 
> to insert (templateId: 202, poolId: 2) to template_spool_ref
> javax.persistence.EntityExistsException: Entity already exists:
> at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1346)
> at 
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at 
> org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl.create(PrimaryDataStoreImpl.java:239)
> at 
> org.apache.cloudstack.storage.volume.VolumeServiceImpl.createBaseImageAsync(VolumeServiceImpl.java:387)
> at 
> org.apache.cloudstack.storage.volume.VolumeServiceImpl.createVolumeFromTemplateAsync(VolumeServiceImpl.java:538)
> at 
> com.cloud.storage.VolumeManagerImpl.recreateVolume(VolumeManagerImpl.java:2488)
> at 
> com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2545)
> at 
> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:934)
> at 
> com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:624)
> at 
> org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:227)
> at 
> org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209)
> at 
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3408)
> at 
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2968)
> at 
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2954)
> at 
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at 
> org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:420)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at 
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Exec

[jira] [Resolved] (CLOUDSTACK-4153) [Dedicated VLANS] [Multiple PhysicalNetworks] This feature is not working as expected in case of multiple physical networks.

[Likitha Shetty (JIRA)]

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

Likitha Shetty resolved CLOUDSTACK-4153.


Resolution: Fixed

> [Dedicated VLANS] [Multiple PhysicalNetworks] This feature is not working as 
> expected in case of multiple physical networks.
> 
>
> Key: CLOUDSTACK-4153
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4153
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.2.0
> Environment: commit id # 7fced6460f13468369550c968670c7d0b9837949
>Reporter: venkata swamybabu budumuru
>Assignee: Likitha Shetty
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: logs.tgz
>
>
> Steps to reproduce;
> 1. Have latest CloudStack setup with at least 1 advanced zone with 2 KVM host 
> cluster.
> 2. create at least 2 physical networks and define same guest VLAN ranges for 
> both the physical networks.
> mysql> select * from physical_network;
> +-+--+--++-+---+---++-+-+-+
> | id  | uuid | name | 
> data_center_id | vnet| speed | domain_id | broadcast_domain_range | state 
>   | created | removed |
> +-+--+--++-+---+---++-+-+-+
> | 200 | 7a4e5b94-f682-4093-a8a6-5a0889ceb14e | Sandbox-pnet | 
>  1 | 906-913 | NULL  |  NULL | ZONE   | Enabled | 
> 2013-08-07 05:31:42 | NULL|
> | 202 | 677601a3-c3af-49d7-bf47-e8a7717a20df | PhysicalNetwork2 | 
>  1 | 906-913 | NULL  |  NULL | ZONE   | Enabled | 
> 2013-08-07 12:13:06 | NULL|
> +-+--+--++-+---+---++-+-+-+
> 3. Created dedicated VLAN range in physical network (202) for account 
> dom1/dom1Acc1
> mysql> select * from physical_network;
> +-+--+--++-+---+---++-+-+-+
> | id  | uuid | name | 
> data_center_id | vnet| speed | domain_id | broadcast_domain_range | state 
>   | created | removed |
> +-+--+--++-+---+---++-+-+-+
> | 200 | 7a4e5b94-f682-4093-a8a6-5a0889ceb14e | Sandbox-pnet | 
>  1 | 906-913 | NULL  |  NULL | ZONE   | Enabled | 
> 2013-08-07 05:31:42 | NULL|
> | 201 | 36f3b773-5931-4ab4-ba0e-15f3df2201e3 | test-network | 
>  2 | NULL| NULL  |  NULL | POD| Enabled | 
> 2013-08-07 05:56:14 | NULL|
> | 202 | 677601a3-c3af-49d7-bf47-e8a7717a20df | PhysicalNetwork2 | 
>  1 | 906-913 | NULL  |  NULL | ZONE   | Enabled | 
> 2013-08-07 12:13:06 | NULL|
> +-+--+--++-+---+---++-+-+-+
> 4. As a different account dom2/dom2Acc1, try to deploy a VM in physical 
> network (202).
> Observations:
> (i) As per the above steps executed, dom2Acc2 in physical network - 202 
> doesn't have any vlans for dom2Acc1 but, it still took one of the VLAN that 
> was dedicated for dom1ACC1
> mysql> select * from op_dc_vnet_alloc;
> ++--+-++--++-+-+
> | id | vnet | physical_network_id | data_center_id | reservation_id   
> | account_id | taken   | account_vnet_map_id |
> ++--+-++--++-+-+
> |  1 | 908  | 200 |  1 | NULL 
> |   NULL | NULL|   1 |
> |  2 | 907  | 200 |  1 | 
> 9e1dcb67-86e1-4978-894e-27fd664f20c3 |  3 | 2013-08-07 14:03:52 | 
>   1 |

[jira] [Commented] (CLOUDSTACK-4153) [Dedicated VLANS] [Multiple PhysicalNetworks] This feature is not working as expected in case of multiple physical networks.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-4153:
-

Commit aba50f81cff73c748a71cd8000512167329a7282 in branch refs/heads/master 
from [~likithas]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=aba50f8 ]

CLOUDSTACK-4153. Guest vlan dedication is not working as expected in case of 
multiple physical networks.


> [Dedicated VLANS] [Multiple PhysicalNetworks] This feature is not working as 
> expected in case of multiple physical networks.
> 
>
> Key: CLOUDSTACK-4153
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4153
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.2.0
> Environment: commit id # 7fced6460f13468369550c968670c7d0b9837949
>Reporter: venkata swamybabu budumuru
>Assignee: Likitha Shetty
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: logs.tgz
>
>
> Steps to reproduce;
> 1. Have latest CloudStack setup with at least 1 advanced zone with 2 KVM host 
> cluster.
> 2. create at least 2 physical networks and define same guest VLAN ranges for 
> both the physical networks.
> mysql> select * from physical_network;
> +-+--+--++-+---+---++-+-+-+
> | id  | uuid | name | 
> data_center_id | vnet| speed | domain_id | broadcast_domain_range | state 
>   | created | removed |
> +-+--+--++-+---+---++-+-+-+
> | 200 | 7a4e5b94-f682-4093-a8a6-5a0889ceb14e | Sandbox-pnet | 
>  1 | 906-913 | NULL  |  NULL | ZONE   | Enabled | 
> 2013-08-07 05:31:42 | NULL|
> | 202 | 677601a3-c3af-49d7-bf47-e8a7717a20df | PhysicalNetwork2 | 
>  1 | 906-913 | NULL  |  NULL | ZONE   | Enabled | 
> 2013-08-07 12:13:06 | NULL|
> +-+--+--++-+---+---++-+-+-+
> 3. Created dedicated VLAN range in physical network (202) for account 
> dom1/dom1Acc1
> mysql> select * from physical_network;
> +-+--+--++-+---+---++-+-+-+
> | id  | uuid | name | 
> data_center_id | vnet| speed | domain_id | broadcast_domain_range | state 
>   | created | removed |
> +-+--+--++-+---+---++-+-+-+
> | 200 | 7a4e5b94-f682-4093-a8a6-5a0889ceb14e | Sandbox-pnet | 
>  1 | 906-913 | NULL  |  NULL | ZONE   | Enabled | 
> 2013-08-07 05:31:42 | NULL|
> | 201 | 36f3b773-5931-4ab4-ba0e-15f3df2201e3 | test-network | 
>  2 | NULL| NULL  |  NULL | POD| Enabled | 
> 2013-08-07 05:56:14 | NULL|
> | 202 | 677601a3-c3af-49d7-bf47-e8a7717a20df | PhysicalNetwork2 | 
>  1 | 906-913 | NULL  |  NULL | ZONE   | Enabled | 
> 2013-08-07 12:13:06 | NULL|
> +-+--+--++-+---+---++-+-+-+
> 4. As a different account dom2/dom2Acc1, try to deploy a VM in physical 
> network (202).
> Observations:
> (i) As per the above steps executed, dom2Acc2 in physical network - 202 
> doesn't have any vlans for dom2Acc1 but, it still took one of the VLAN that 
> was dedicated for dom1ACC1
> mysql> select * from op_dc_vnet_alloc;
> ++--+-++--++-+-+
> | id | vnet | physical_network_id | data_center_id | reservation_id   
> | account_id | taken   | account_vnet_map_id |
> ++--+-++--++---

[jira] [Commented] (CLOUDSTACK-4153) [Dedicated VLANS] [Multiple PhysicalNetworks] This feature is not working as expected in case of multiple physical networks.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-4153:
-

Commit 815d51e5816b3eae7d112b37e44c91e6d8b6a825 in branch refs/heads/4.2 from 
[~likithas]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=815d51e ]

CLOUDSTACK-4153. Guest vlan dedication is not working as expected in case of 
multiple physical networks.


> [Dedicated VLANS] [Multiple PhysicalNetworks] This feature is not working as 
> expected in case of multiple physical networks.
> 
>
> Key: CLOUDSTACK-4153
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4153
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.2.0
> Environment: commit id # 7fced6460f13468369550c968670c7d0b9837949
>Reporter: venkata swamybabu budumuru
>Assignee: Likitha Shetty
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: logs.tgz
>
>
> Steps to reproduce;
> 1. Have latest CloudStack setup with at least 1 advanced zone with 2 KVM host 
> cluster.
> 2. create at least 2 physical networks and define same guest VLAN ranges for 
> both the physical networks.
> mysql> select * from physical_network;
> +-+--+--++-+---+---++-+-+-+
> | id  | uuid | name | 
> data_center_id | vnet| speed | domain_id | broadcast_domain_range | state 
>   | created | removed |
> +-+--+--++-+---+---++-+-+-+
> | 200 | 7a4e5b94-f682-4093-a8a6-5a0889ceb14e | Sandbox-pnet | 
>  1 | 906-913 | NULL  |  NULL | ZONE   | Enabled | 
> 2013-08-07 05:31:42 | NULL|
> | 202 | 677601a3-c3af-49d7-bf47-e8a7717a20df | PhysicalNetwork2 | 
>  1 | 906-913 | NULL  |  NULL | ZONE   | Enabled | 
> 2013-08-07 12:13:06 | NULL|
> +-+--+--++-+---+---++-+-+-+
> 3. Created dedicated VLAN range in physical network (202) for account 
> dom1/dom1Acc1
> mysql> select * from physical_network;
> +-+--+--++-+---+---++-+-+-+
> | id  | uuid | name | 
> data_center_id | vnet| speed | domain_id | broadcast_domain_range | state 
>   | created | removed |
> +-+--+--++-+---+---++-+-+-+
> | 200 | 7a4e5b94-f682-4093-a8a6-5a0889ceb14e | Sandbox-pnet | 
>  1 | 906-913 | NULL  |  NULL | ZONE   | Enabled | 
> 2013-08-07 05:31:42 | NULL|
> | 201 | 36f3b773-5931-4ab4-ba0e-15f3df2201e3 | test-network | 
>  2 | NULL| NULL  |  NULL | POD| Enabled | 
> 2013-08-07 05:56:14 | NULL|
> | 202 | 677601a3-c3af-49d7-bf47-e8a7717a20df | PhysicalNetwork2 | 
>  1 | 906-913 | NULL  |  NULL | ZONE   | Enabled | 
> 2013-08-07 12:13:06 | NULL|
> +-+--+--++-+---+---++-+-+-+
> 4. As a different account dom2/dom2Acc1, try to deploy a VM in physical 
> network (202).
> Observations:
> (i) As per the above steps executed, dom2Acc2 in physical network - 202 
> doesn't have any vlans for dom2Acc1 but, it still took one of the VLAN that 
> was dedicated for dom1ACC1
> mysql> select * from op_dc_vnet_alloc;
> ++--+-++--++-+-+
> | id | vnet | physical_network_id | data_center_id | reservation_id   
> | account_id | taken   | account_vnet_map_id |
> ++--+-++--++--

[jira] [Updated] (CLOUDSTACK-4172) Parallel deployment of vm fails when userdata is provided

[shweta agarwal (JIRA)]

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

shweta agarwal updated CLOUDSTACK-4172:
---

Description: 
Repro steps:
Set up - Advanced zone with 1 host (We all all the Vms to get deployed in this 
host).
1. Create an account.
2. Create network for this account.
3. Deploy a Vm in this network , so that the router for this network is already 
is running.
4. Deploy 30 - 50 Vms in parallel in this network by passing userdata.




called 30 vm deployment call with userdata and all vm deployment failed with 
following exception

2013-08-07 21:53:34,410 DEBUG 
[network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-87:job-836 = 
[ 391486bb-e207-4e33-8eab-cc0993a9c49d ]) Applying userdata and password entry 
in network Ntwk[207|Guest|8]
2013-08-07 21:53:34,422 DEBUG [agent.transport.Request] 
(Job-Executor-87:job-836 = [ 391486bb-e207-4e33-8eab-cc0993a9c49d ]) Seq 
1-122754475: Sending  { Cmd , MgmtId: 7200344900649, via: 1, Ver: v1, Flags: 
100011, 
[{"com.cloud.agent.api.routing.SavePasswordCommand":{"password":"fnirq_cnffjbeq","vmIpAddress":"10.1.1.136","vmName":"331d768a-33e6-4a00-b063-4c451e2acfee","executeInSequence":false,"accessDetails":{"router.guest.ip":"10.1.1.1","zone.network.type":"Advanced","router.ip":"169.254.2.248","router.name":"r-219-VM"},"wait":0}},{"com.cloud.agent.api.routing.VmDataCommand":{"vmIpAddress":"10.1.1.136","vmName":"331d768a-33e6-4a00-b063-4c451e2acfee","executeInSequence":false,"accessDetails":{"router.guest.ip":"10.1.1.1","zone.network.type":"Advanced","router.ip":"169.254.2.248","router.name":"r-219-VM"},"wait":0}}]
 }
2013-08-07 21:53:34,422 DEBUG [agent.transport.Request] 
(Job-Executor-87:job-836 = [ 391486bb-e207-4e33-8eab-cc0993a9c49d ]) Seq 
1-122754475: Executing:  { Cmd , MgmtId: 7200344900649, via: 1, Ver: v1, Flags: 
100011, 
[{"com.cloud.agent.api.routing.SavePasswordCommand":{"password":"fnirq_cnffjbeq","vmIpAddress":"10.1.1.136","vmName":"331d768a-33e6-4a00-b063-4c451e2acfee","executeInSequence":false,"accessDetails":{"router.guest.ip":"10.1.1.1","zone.network.type":"Advanced","router.ip":"169.254.2.248","router.name":"r-219-VM"},"wait":0}},{"com.cloud.agent.api.routing.VmDataCommand":{"vmIpAddress":"10.1.1.136","vmName":"331d768a-33e6-4a00-b063-4c451e2acfee","executeInSequence":false,"accessDetails":{"router.guest.ip":"10.1.1.1","zone.network.type":"Advanced","router.ip":"169.254.2.248","router.name":"r-219-VM"},"wait":0}}]
 }
2013-08-07 21:53:34,533 DEBUG [agent.manager.DirectAgentAttache] 
(DirectAgent-203:null) Seq 1-122754474: Executing request
2013-08-07 21:53:34,540 DEBUG [agent.manager.AgentManagerImpl] 
(AgentManager-Handler-10:null) Ping from 3
2013-08-07 21:53:34,537 DEBUG [agent.manager.DirectAgentAttache] 
(DirectAgent-296:null) Seq 1-122754475: Executing request
2013-08-07 21:53:34,582 DEBUG [cloud.network.NetworkModelImpl] 
(Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) Service 
SecurityGroup is not supported in the network id=207
2013-08-07 21:53:34,582 DEBUG [cloud.network.NetworkModelImpl] 
(ApiServer-7:null) Service SecurityGroup is not supported in the network id=207
2013-08-07 21:53:34,586 DEBUG [cloud.network.NetworkModelImpl] 
(Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) Service 
SecurityGroup is not supported in the network id=207
2013-08-07 21:53:34,951 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] 
(Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) Deploy 
avoids pods: null, clusters: null, hosts: null
2013-08-07 21:53:34,956 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] 
(Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) 
DeploymentPlanner allocation algorithm: 
com.cloud.deploy.FirstFitPlanner_EnhancerByCloudStack_392cf6b8@1c529aa0
2013-08-07 21:53:34,956 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] 
(Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) Trying to 
allocate a host and storage pools from dc:1, pod:null,cluster:null, requested 
cpu: 128, requested ram: 134217728
2013-08-07 21:53:34,956 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] 
(Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) Is ROOT 
volume READY (pool already allocated)?: No
2013-08-07 21:53:34,957 DEBUG [cloud.deploy.FirstFitPlanner] 
(Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) Searching 
all possible resources under this Zone: 1
2013-08-07 21:53:34,957 DEBUG [cloud.deploy.FirstFitPlanner] 
(Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) Listing 
clusters in order of aggregate capacity, that have (atleast one host with) 
enough CPU and RAM capacity under this Zone: 1
2013-08-07 21:53:35,403 DEBUG [cloud.vm.UserVmManagerImpl] (ApiServer-7:null) 
Allocating in the DB for vm
2013-08-07 21:53:35,681 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
(Api

[jira] [Updated] (CLOUDSTACK-4172) Parallel deployment of vm fails when userdata is provided

[shweta agarwal (JIRA)]

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

shweta agarwal updated CLOUDSTACK-4172:
---

Attachment: management-server.log.tar.gz
cloud-backup.dmp

> Parallel deployment of vm fails when userdata is provided 
> --
>
> Key: CLOUDSTACK-4172
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4172
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.2.0
> Environment: xenserver advance zone
>Reporter: shweta agarwal
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: cloud-backup.dmp, management-server.log.tar.gz
>
>
> Repro steps:
> Set up - Advanced zone with 1 host (We all all the Vms to get deployed in 
> this host).
> 1. Create an account.
> 2. Create network for this account.
> 3. Deploy a Vm in this network , so that the router for this network is 
> already is running.
> 4. Deploy 30 - 50 Vms in parallel in this network by passing userdata.
> called 30 vm deployment call with userdata and all vm deployment failed with 
> following exception
> 2013-08-07 21:53:34,410 DEBUG 
> [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-87:job-836 
> = [ 391486bb-e207-4e33-8eab-cc0993a9c49d ]) Applying userdata and password 
> entry in network Ntwk[207|Guest|8]
> 2013-08-07 21:53:34,422 DEBUG [agent.transport.Request] 
> (Job-Executor-87:job-836 = [ 391486bb-e207-4e33-8eab-cc0993a9c49d ]) Seq 
> 1-122754475: Sending  { Cmd , MgmtId: 7200344900649, via: 1, Ver: v1, Flags: 
> 100011, 
> [{"com.cloud.agent.api.routing.SavePasswordCommand":{"password":"fnirq_cnffjbeq","vmIpAddress":"10.1.1.136","vmName":"331d768a-33e6-4a00-b063-4c451e2acfee","executeInSequence":false,"accessDetails":{"router.guest.ip":"10.1.1.1","zone.network.type":"Advanced","router.ip":"169.254.2.248","router.name":"r-219-VM"},"wait":0}},{"com.cloud.agent.api.routing.VmDataCommand":{"vmIpAddress":"10.1.1.136","vmName":"331d768a-33e6-4a00-b063-4c451e2acfee","executeInSequence":false,"accessDetails":{"router.guest.ip":"10.1.1.1","zone.network.type":"Advanced","router.ip":"169.254.2.248","router.name":"r-219-VM"},"wait":0}}]
>  }
> 2013-08-07 21:53:34,422 DEBUG [agent.transport.Request] 
> (Job-Executor-87:job-836 = [ 391486bb-e207-4e33-8eab-cc0993a9c49d ]) Seq 
> 1-122754475: Executing:  { Cmd , MgmtId: 7200344900649, via: 1, Ver: v1, 
> Flags: 100011, 
> [{"com.cloud.agent.api.routing.SavePasswordCommand":{"password":"fnirq_cnffjbeq","vmIpAddress":"10.1.1.136","vmName":"331d768a-33e6-4a00-b063-4c451e2acfee","executeInSequence":false,"accessDetails":{"router.guest.ip":"10.1.1.1","zone.network.type":"Advanced","router.ip":"169.254.2.248","router.name":"r-219-VM"},"wait":0}},{"com.cloud.agent.api.routing.VmDataCommand":{"vmIpAddress":"10.1.1.136","vmName":"331d768a-33e6-4a00-b063-4c451e2acfee","executeInSequence":false,"accessDetails":{"router.guest.ip":"10.1.1.1","zone.network.type":"Advanced","router.ip":"169.254.2.248","router.name":"r-219-VM"},"wait":0}}]
>  }
> 2013-08-07 21:53:34,533 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-203:null) Seq 1-122754474: Executing request
> 2013-08-07 21:53:34,540 DEBUG [agent.manager.AgentManagerImpl] 
> (AgentManager-Handler-10:null) Ping from 3
> 2013-08-07 21:53:34,537 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-296:null) Seq 1-122754475: Executing request
> 2013-08-07 21:53:34,582 DEBUG [cloud.network.NetworkModelImpl] 
> (Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) Service 
> SecurityGroup is not supported in the network id=207
> 2013-08-07 21:53:34,582 DEBUG [cloud.network.NetworkModelImpl] 
> (ApiServer-7:null) Service SecurityGroup is not supported in the network 
> id=207
> 2013-08-07 21:53:34,586 DEBUG [cloud.network.NetworkModelImpl] 
> (Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) Service 
> SecurityGroup is not supported in the network id=207
> 2013-08-07 21:53:34,951 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] 
> (Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) Deploy 
> avoids pods: null, clusters: null, hosts: null
> 2013-08-07 21:53:34,956 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] 
> (Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) 
> DeploymentPlanner allocation algorithm: 
> com.cloud.deploy.FirstFitPlanner_EnhancerByCloudStack_392cf6b8@1c529aa0
> 2013-08-07 21:53:34,956 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] 
> (Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) Trying 
> to allocate a host and storage pools from dc:1, pod:null,cluster:null, 
> requested cpu: 128, requested 

[jira] [Created] (CLOUDSTACK-4172) Parallel deployment of vm fails when userdata is provided

[shweta agarwal (JIRA)]

shweta agarwal created CLOUDSTACK-4172:
--

 Summary: Parallel deployment of vm fails when userdata is provided 
 Key: CLOUDSTACK-4172
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4172
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.2.0
 Environment: xenserver advance zone
Reporter: shweta agarwal
Priority: Blocker
 Fix For: 4.2.0
 Attachments: cloud-backup.dmp, management-server.log.tar.gz

Repro steps:
Set up - Advanced zone with 1 host (We all all the Vms to get deployed in this 
host).
1. Create an account.
2. Create network for this account.
3. Deploy a Vm in this network , so that the router for this network is already 
is running.
4. Deploy 30 - 50 Vms in parallel in this network by passing userdata.




called 30 vm deployment call with userdata and all vm deployment failed with 
following exception

2013-08-07 21:53:34,410 DEBUG 
[network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-87:job-836 = 
[ 391486bb-e207-4e33-8eab-cc0993a9c49d ]) Applying userdata and password entry 
in network Ntwk[207|Guest|8]
2013-08-07 21:53:34,422 DEBUG [agent.transport.Request] 
(Job-Executor-87:job-836 = [ 391486bb-e207-4e33-8eab-cc0993a9c49d ]) Seq 
1-122754475: Sending  { Cmd , MgmtId: 7200344900649, via: 1, Ver: v1, Flags: 
100011, 
[{"com.cloud.agent.api.routing.SavePasswordCommand":{"password":"fnirq_cnffjbeq","vmIpAddress":"10.1.1.136","vmName":"331d768a-33e6-4a00-b063-4c451e2acfee","executeInSequence":false,"accessDetails":{"router.guest.ip":"10.1.1.1","zone.network.type":"Advanced","router.ip":"169.254.2.248","router.name":"r-219-VM"},"wait":0}},{"com.cloud.agent.api.routing.VmDataCommand":{"vmIpAddress":"10.1.1.136","vmName":"331d768a-33e6-4a00-b063-4c451e2acfee","executeInSequence":false,"accessDetails":{"router.guest.ip":"10.1.1.1","zone.network.type":"Advanced","router.ip":"169.254.2.248","router.name":"r-219-VM"},"wait":0}}]
 }
2013-08-07 21:53:34,422 DEBUG [agent.transport.Request] 
(Job-Executor-87:job-836 = [ 391486bb-e207-4e33-8eab-cc0993a9c49d ]) Seq 
1-122754475: Executing:  { Cmd , MgmtId: 7200344900649, via: 1, Ver: v1, Flags: 
100011, 
[{"com.cloud.agent.api.routing.SavePasswordCommand":{"password":"fnirq_cnffjbeq","vmIpAddress":"10.1.1.136","vmName":"331d768a-33e6-4a00-b063-4c451e2acfee","executeInSequence":false,"accessDetails":{"router.guest.ip":"10.1.1.1","zone.network.type":"Advanced","router.ip":"169.254.2.248","router.name":"r-219-VM"},"wait":0}},{"com.cloud.agent.api.routing.VmDataCommand":{"vmIpAddress":"10.1.1.136","vmName":"331d768a-33e6-4a00-b063-4c451e2acfee","executeInSequence":false,"accessDetails":{"router.guest.ip":"10.1.1.1","zone.network.type":"Advanced","router.ip":"169.254.2.248","router.name":"r-219-VM"},"wait":0}}]
 }
2013-08-07 21:53:34,533 DEBUG [agent.manager.DirectAgentAttache] 
(DirectAgent-203:null) Seq 1-122754474: Executing request
2013-08-07 21:53:34,540 DEBUG [agent.manager.AgentManagerImpl] 
(AgentManager-Handler-10:null) Ping from 3
2013-08-07 21:53:34,537 DEBUG [agent.manager.DirectAgentAttache] 
(DirectAgent-296:null) Seq 1-122754475: Executing request
2013-08-07 21:53:34,582 DEBUG [cloud.network.NetworkModelImpl] 
(Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) Service 
SecurityGroup is not supported in the network id=207
2013-08-07 21:53:34,582 DEBUG [cloud.network.NetworkModelImpl] 
(ApiServer-7:null) Service SecurityGroup is not supported in the network id=207
2013-08-07 21:53:34,586 DEBUG [cloud.network.NetworkModelImpl] 
(Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) Service 
SecurityGroup is not supported in the network id=207
2013-08-07 21:53:34,951 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] 
(Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) Deploy 
avoids pods: null, clusters: null, hosts: null
2013-08-07 21:53:34,956 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] 
(Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) 
DeploymentPlanner allocation algorithm: 
com.cloud.deploy.FirstFitPlanner_EnhancerByCloudStack_392cf6b8@1c529aa0
2013-08-07 21:53:34,956 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] 
(Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) Trying to 
allocate a host and storage pools from dc:1, pod:null,cluster:null, requested 
cpu: 128, requested ram: 134217728
2013-08-07 21:53:34,956 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] 
(Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) Is ROOT 
volume READY (pool already allocated)?: No
2013-08-07 21:53:34,957 DEBUG [cloud.deploy.FirstFitPlanner] 
(Job-Executor-118:job-839 = [ 8f1bcacd-91b6-4481-ba74-41664b43d283 ]) Searching 
all possible resourc

[jira] [Assigned] (CLOUDSTACK-4165) 3.0.6 to ASF 4.2 Upgrade: Data Migration step of the Upgrade Fails on "persistLegacyZones"

[Sateesh Chodapuneedi (JIRA)]

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

Sateesh Chodapuneedi reassigned CLOUDSTACK-4165:


Assignee: Sateesh Chodapuneedi

> 3.0.6 to ASF 4.2 Upgrade: Data Migration step of the Upgrade Fails on 
> "persistLegacyZones"
> --
>
> Key: CLOUDSTACK-4165
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4165
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.2.0
>Reporter: Chandan Purushothama
>Assignee: Sateesh Chodapuneedi
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: management-server.zip, mysqldumps.zip
>
>
> =
> Steps to Reproduce:
> =
> 1. Deployed a 3.0.6 Advanced Zone Setup with two VMWare Clusters with one 
> host in each Cluster. Used NFS Primary Storage.
> 2. Upgraded the Setup using the Latest 4.2 Build.
> ===
> Observations:
> ===
> On Starting the Management Server after Upgrading the RPMs, I observed that 
> the schema of the setup got upgraded but failed before data migration phase 
> started.
> ===
> On Management Server Log:
> ===
> 2013-08-07 14:10:57,271 DEBUG [utils.db.ScriptRunner] (Timer-1:null) INSERT 
> IGNORE INTO `cloud`.`configuration` VALUES ('Advanced', 'DEFAULT', 
> 'management-server', 'eip.use.multiple.netscalers', 'false', 'Should be set 
> to true, if there will be multiple NetScaler devices providing EIP service in 
> a zone')
> 2013-08-07 14:10:57,272 DEBUG [utils.db.ScriptRunner] (Timer-1:null) INSERT 
> IGNORE INTO `cloud`.`configuration` VALUES ('Snapshots', 'DEFAULT', 
> 'SnapshotManager', 'snapshot.backup.rightafter', 'true', 'backup snapshot 
> right after snapshot is taken')
> 2013-08-07 14:10:57,363 TRACE [db.Transaction.Connection] (Timer-1:null) txn: 
> Not closing DB connection because we're still in a transaction.
> 2013-08-07 14:10:57,364 DEBUG [db.Transaction.Transaction] (Timer-1:null) 
> Rolling back the transaction: Time = 5301 Name =  
> -CloudStartupServlet$1.run:52-TimerThread.mainLoop:534-TimerThread.run:484; 
> called by 
> -Transaction.rollback:896-Transaction.removeUpTo:839-Transaction.close:663-DatabaseUpgradeChecker.upgrade:293-DatabaseUpgradeChecker.check:389-ComponentContext.initComponentsLifeCycle:90-CloudStartupServlet$1.run:54-TimerThread.mainLoop:534-TimerThread.run:484
> 2013-08-07 14:10:57,365 TRACE [db.Transaction.Connection] (Timer-1:null) 
> Closing DB connection: dbconn162979043
> 2013-08-07 14:10:57,366 TRACE [utils.db.GlobalLock] (Timer-1:null) lock 
> DatabaseUpgrade is returned to free state, total holding time :8969
> 2013-08-07 14:10:57,366 TRACE [utils.db.GlobalLock] (Timer-1:null) lock 
> DatabaseUpgrade is released, lock count :0
> 2013-08-07 14:10:57,366 ERROR [utils.component.ComponentContext] 
> (Timer-1:null) System integrity check failed. Refuse to startup

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (CLOUDSTACK-2005) Condition mapping entries / rules are not working as expected

[Minying Bao (JIRA)]

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

Minying Bao reopened CLOUDSTACK-2005:
-

Reproduced In: 4.2.0

As previous comment:

The three keys mentioned in the docx ( ~#, @', \| ) have worked well now.

However, the parameters "browser" "browser version" "guest os" in that 
ajaxkeys.js file, it seemed they are still not working well. Should we focus on 
that?

> Condition mapping entries / rules are not working as expected
> -
>
> Key: CLOUDSTACK-2005
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2005
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VNC Proxy
>Affects Versions: 4.2.0
> Environment: Build No.#133 
> (CloudStack-non-OSS-MASTER-133-rhel6.3.tar.gz)
> XenServer6.1 for Host Server, CentOS6.3 for NFS server and CloudStack-Mgr 
> Server, Win7Entx64SP1 for Client machine. 
>Reporter: Minying Bao
>Assignee: Sanjay Tripathi
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: v3Extensive Test of the Conditional mapping entry.docx
>
>
> Steps
> Setup the CloudStack environments with build 4.2#133.
> Add template and then create as an instance.
> Manually modify the "condition mapping entries" in the ajaxkeys.js file, 
> synchronize the script to v-2-VM.
> Launch the VM via ConsoleProxy in client machine, to check if the "condition 
> mapping entries" are working as expected.
> Note
> The requirements link have the following list of rules/conditional mapping 
> entries: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Non-US+Keyboard+Support+for+Console+Proxy
> Conditional mapping entry   { 
>  type: , code: , modifiers: ,
>  shift : ,-- match on shift 
> state
>  guestos : , -- match on guestos type
>  browser: ,  -- match on browser
>  browserVersion:   -- match on 
> browser version
> }
> Expected Result
> All the condition mapping entries / rules should be working as expected.
> Actual Result 
> Condition mapping entries / rules are not working as expected.
> Please refer to attached for details.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (CLOUDSTACK-1905) CloudStack with build4.2 -- IE cannot launch the VM successfully

[Minying Bao (JIRA)]

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

Minying Bao reopened CLOUDSTACK-1905:
-

Reproduced In: 4.2.0

As dicussed with Sanjay, on the IE8 -> still repro.
Please help to confirm, if it is supporting on IE8 or not.


> CloudStack with build4.2 -- IE cannot launch the VM successfully
> 
>
> Key: CLOUDSTACK-1905
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1905
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VNC Proxy
>Affects Versions: 4.2.0
> Environment: Build No.#133 
> (CloudStack-non-OSS-MASTER-133-rhel6.3.tar.gz)
> XenServer6.1 for Host Server, CentOS6.3 for NFS server and CloudStack-Mgr 
> Server, Win7Entx64SP1 for Client machine.
>Reporter: Minying Bao
>Assignee: Sanjay Tripathi
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: IE Can not launch the VM.jpg, ieFIX.jpg, vm_from_IE.png
>
>
> Steps
> Setup the CloudStack environments with build 4.2.
> Add templates and instances. 
> Try to use browsers to launch the VM via ConsoleProxy in client machine.
> Expected Result
> All of the browsers such as Firefox, Chrome, IE should launch the VM 
> successfully.
> Actual Result
> Firefox and Chrome can launch the VM successfully, while IE (both IE8 & IE9) 
> cannot.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (CLOUDSTACK-1961) Common issues found in English OS with EN-US standard Keyboard

[Minying Bao (JIRA)]

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

Minying Bao reopened CLOUDSTACK-1961:
-

Reproduced In: 4.2.0

As the previous comment:

The 1,2,3 points are still repro,
1 "Alt + Shift" -> Repro
2 "Caps Lock" -> Repro
3 "Ctrl + Space" -> Repro

Checked the CLOUDSTACK-1964, there is not mentioned "Alt+Shift" & "Caps Lock"


> Common issues found in English OS with EN-US standard Keyboard
> --
>
> Key: CLOUDSTACK-1961
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1961
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VNC Proxy
>Affects Versions: 4.2.0
> Environment: Build No.#133 
> (CloudStack-non-OSS-MASTER-133-rhel6.3.tar.gz)
> XenServer6.1 for Host Server, CentOS6.3 for NFS server and CloudStack-Mgr 
> Server, Win7Entx64SP1 for Client machine. 
>Reporter: Minying Bao
>Assignee: Sanjay Tripathi
>Priority: Critical
> Fix For: 4.2.0
>
>
> Steps
> Setup the CloudStack environments with build 4.2#133.
> Add EN-US-Win7 template and then create as an instance.
> Open Firefox, launch the EN-US-Win7 via ConsoleProxy in client machine.
> Hit all the keys with EN-US standard keyboard.
> Expected Result
> All the keys should remap as same as the EN-US standard keyboard layout 
> behavior.
> Actual Result
> Common issues found in English OS with EN Keyboard
> 1 "Alt + Shift" combination: Alt+Shift used to change the keyboard layout 
> when two are more keyboard layouts are available in a OS. Alt+Shift 
> combination is not working few time, with the reproducible frequency of about 
> 30%. 
> 2 "Caps Lock": Caps Lock functionality is reversed in the VM provided by 
> Console Proxy. When "Caps Lock" is turned on, Console Proxy types lower case 
> characters and vice versa. (Note：If the properties of “Caps Lock” in both VM 
> and Client are kept the same at first time, the Caps Lock functionality works 
> well.)
> 3 "Ctrl + Space" combination: When 3rd party input method like "Chinese 
> Sougou" is installed in English OS, then Ctrl+Space can be used to change the 
> input between "English" & "Chinese Sougou". 
> 4 "Ctrl + Numpad .": This combination behaves like "Ctrl+N". 
> 5 "Shift + Numpad -": Echoes underscore, whereas the expected is hypen. 
> 6 "Shift + Numpad /": Echoes question mark, whereas the expected is slash. 
> 7 "Menu": Not working, whereas the expected is just like right clicking 
> funtion.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-4134) UI dosent fire the API with the Vlan values if the Vlan range is blank.

[Kiran Koneti (JIRA)]

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

Kiran Koneti commented on CLOUDSTACK-4134:
--

Hi Alena,

I haven't reported the second one as an issue. I was trying to explain the the 
API sends the Vlan list when we give some values rather than keeping it blank 
and that is the correct behavior we are expecting even in the case of the blank 
values.

Regards,
Kiran.

> UI dosent fire the API with the Vlan values if the Vlan range is blank.
> ---
>
> Key: CLOUDSTACK-4134
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4134
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.2.0
>Reporter: Kiran Koneti
>Assignee: Bharat Kumar
>Priority: Critical
> Fix For: 4.2.0
>
>
> When we try to edit the Vlan range from the UI and give blank values in the 
> Vlan range box and try to update the page the API fried doesn't have any Vlan 
> details as it is blank in the UI.
> Eg:
> I tried the below scenario:
> 1)Created a setup with the Vlan range 1100-1109.
> 2)Then created a network where the Vlan 1101 is associated with the network.
> 3)Now I tried to edit the Vlan range and gave the blank value in the UI and 
> clicked update.
> The API fired is as below
> "10.147.38.237:8080/client/api?command=updatePhysicalNetwork&response=json&sessionkey=RRxhiAqmggnl%2F5oBGHNTm3DMj0M%3D&id=2409aeac-789a-4430-a9b7-fab66eb4b85c&_=1375867127326"
> Here the Vlan details are not fired in the API.
> Then I tried to edit it by giving the value 1102-1109  and  the API fired was 
> as below:
> "http://10.147.38.237:8080/client/api?command=updatePhysicalNetwork&response=json&sessionkey=RRxhiAqmggnl%2F5oBGHNTm3DMj0M%3D&id=2409aeac-789a-4430-a9b7-fab66eb4b85c&vlan=1102-1109&_=1375867287606";
> The API was fired currently with the Vlan values and there was a error 
> message as below
> "physicalnetwork 200 has allocated vnets in the range 1100-1101 " the below 
> is the expected behaviour and the same should happen when we try to update 
> the UI with Blank details.
> Note: Even the UI doesn't popup with any error message the Vlan range is not 
> getting deleted and we can see the same vlan range once we refresh the page.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-2882) [Automation] [VmWare]Test case "test_vm_life_cycle.TestVMLifeCycle.test_10_attachAndDetach_iso" failing due to wrong mount point

[Animesh Chaturvedi (JIRA)]

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

Animesh Chaturvedi commented on CLOUDSTACK-2882:


Rayees can  you  provide the requested info I would like to get all older 
issues to be resolved ASAP 

> [Automation] [VmWare]Test case 
> "test_vm_life_cycle.TestVMLifeCycle.test_10_attachAndDetach_iso" failing due 
> to wrong mount point 
> -
>
> Key: CLOUDSTACK-2882
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2882
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.0
> Environment: Automation - BVT 
>Reporter: Rayees Namathponnan
>Assignee: Rayees Namathponnan
>Priority: Blocker
> Fix For: 4.2.0
>
>
> Test case "test_vm_life_cycle.TestVMLifeCycle.test_10_attachAndDetach_iso" 
> failing due to wrong mount point in KVM
> Test case failing with below error
> paramiko.transport: INFO: Secsh channel 3 opened.
> paramiko.transport: DEBUG: [chan 3] Sesch channel 3 request ok
> sshClient: DEBUG: {Cmd: mount -rt iso9660 /dev/xvdd /mnt/tmp via Host: 
> 10.208.10.22} {returns: ['mount: special device /dev/xvdd does not exist']}
> http://jenkins.cloudstack.org/view/cloudstack-qa/job/test-smoke-matrix/389/suite=test_vm_life_cycle/testReport/integration.smoke.test_vm_life_cycle/TestVMLifeCycle/test_10_attachAndDetach_iso/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (CLOUDSTACK-3478) primary:iscsi:cleanupvolumes fail with runtime exception

[sadhu suresh (JIRA)]

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

sadhu suresh closed CLOUDSTACK-3478.



destroyed VM expunged successfully.tested with vmware and  openfiler iscsi as 
primary.


2013-08-08 00:52:35,487 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
(UserVm-Scavenger-3:null) Expunged VM[User|62b8243b-a8d2-4c98-9ac4-6fef9a5a0dd7]
2013-08-08 00:52:35,507 DEBUG [cloud.vm.UserVmManagerImpl] 
(UserVm-Scavenger-3:null) Starting cleaning up vm 
VM[User|62b8243b-a8d2-4c98-9ac4-6fef9a5a0dd7] resources...
2013-08-08 00:52:35,517 DEBUG [network.firewall.FirewallManagerImpl] 
(UserVm-Scavenger-3:null) No firewall rules are found for vm id=21
2013-08-08 00:52:35,517 DEBUG [cloud.vm.UserVmManagerImpl] 
(UserVm-Scavenger-3:null) Firewall rules are removed successfully as a part of 
vm id=21 expunge
2013-08-08 00:52:35,522 DEBUG [network.rules.RulesManagerImpl] 
(UserVm-Scavenger-3:null) No port forwarding rules are found for vm id=21
2013-08-08 00:52:35,522 DEBUG [cloud.vm.UserVmManagerImpl] 
(UserVm-Scavenger-3:null) Port forwarding rules are removed successfully as a 
part of vm id=21 expunge
2013-08-08 00:52:35,524 DEBUG [cloud.vm.UserVmManagerImpl] 
(UserVm-Scavenger-3:null) Removed vm id=21 from all load balancers as a part of 
expunge process
2013-08-08 00:52:35,525 DEBUG [cloud.vm.UserVmManagerImpl] 
(UserVm-Scavenger-3:null) Successfully cleaned up vm 
VM[User|62b8243b-a8d2-4c98-9ac4-6fef9a5a0

> primary:iscsi:cleanupvolumes fail with runtime exception
> 
>
> Key: CLOUDSTACK-3478
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3478
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.2.0
>Reporter: sadhu suresh
>Assignee: Alena Prokharchyk
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.rar
>
>
> steps:
> 1.configured the basic zone  with network offering"defaultsharednetscalar  
> eip&elb n/w offering and with xen6.02 hyper-visor ,primary storage type iscsi
> 2.deploy few vms
> 3.added one more iscsi based primary storage
> 4deployed few more deploys
> 5.destroy the few vms
> Actual result:
> during expunging vms ,cleannup of volumes failed with runtime exception.
> 2013-07-11 22:37:24,974 DEBUG [db.Transaction.Transaction] 
> (UserVm-Scavenger-1:null) Rolling back the transaction: Time = 7 Name =  
> cleanupVolumes; called by 
> -Transaction.rollback:890-Transaction.removeUpTo:833-Transaction.close:657-TransactionContextBuilder.interceptException:63-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:133-VirtualMachineManagerImpl.advanceExpunge:464-UserVmManagerImpl.expunge:1514-UserVmManagerImpl$ExpungeTask.run:1683-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-FutureTask.runAndReset:178-ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201:165
> 2013-07-11 22:37:24,975 WARN  [cloud.vm.UserVmManagerImpl] 
> (UserVm-Scavenger-1:null) Unable to expunge VM[User|sg1]
> com.cloud.utils.exception.CloudRuntimeException: Failed to update 
> state:com.cloud.utils.exception.CloudRuntimeException: Failed to transit 
> volume: 7, due to: com.cloud.utils.fsm.NoTransitionException: Unable to 
> transition to a new state from Expunging via DestroyRequested
> at 
> org.apache.cloudstack.storage.volume.VolumeObject.processEvent(VolumeObject.java:292)
> at 
> org.apache.cloudstack.storage.volume.VolumeServiceImpl.destroyVolume(VolumeServiceImpl.java:503)
> at 
> com.cloud.storage.VolumeManagerImpl.cleanupVolumes(VolumeManagerImpl.java:2095)
> at 
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at 
> com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:464)
> at com.cloud.vm.UserVmManagerImpl.expunge(UserVmManagerImpl.java:1514)
> at 
> com.cloud.vm.UserVmManagerImpl$ExpungeTask.run(UserVmManagerImpl.java:1683)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at 
> java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at 
> java.util.conc

[jira] [Updated] (CLOUDSTACK-4158) [Performance Testing] List API performance in comparison to 4.1 is not as good

[Abhinandan Prateek (JIRA)]

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

Abhinandan Prateek updated CLOUDSTACK-4158:
---

Assignee: Koushik Das

> [Performance Testing] List API performance in comparison to 4.1 is not as good
> --
>
> Key: CLOUDSTACK-4158
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4158
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.2.0
> Environment: Simulator for creating mock resources, advanced zone, RVR
>Reporter: Sowmya Krishnan
>Assignee: Koushik Das
>Priority: Critical
> Fix For: 4.2.0
>
>
> Executed few List API calls for tracking performance runs for 4.2 and 
> compared the results with 4.1. Most APIs are taking noticeably longer as 
> compared to 4.1
> Examples:
> API  Time taken in 4.1   Time taken in 4.2
>   
> listAccounts  1m25.348s   2m22.628s
> listEvents 0m6.575s   0m20.277s
> Results so far are posted here (including comparitive results)
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Performance+Test+Execution+for+4.2
> Performance Test bed details:
> ===
> Management server:
> Processor
> Dual core Intel(R) Xeon(R) CPU processor, 2.27GHz, ht enabled, 4 processor
> Operating System
> CentOS release 5.5 (Final), x86_64
> Configuration Parameters
> Following config parameters were used in both the management servers
> -Java heap size = 5 GB
> -db.cloud.maxActive = 250
> - 
> db.cloud.url.params=prepStmtCacheSize=517&cachePrepStmts=true&prepStmtCacheSqlLimit=4096&includeInnodbStatusInDeadlockExceptions=true&logSlowQueries=true
> Setup:
> =
> Advanced zone, 2 Management Servers, 124 Pods [Each Pod having 2 Clusters]
> 248 Clusters [Each cluster having 8 hosts and one primary storage]
> 2000 Hosts
> 4000 User accounts [Each account having one network]
> 4000 User instances
> ~8000 Virtual Routers [Since we are using Redundant Virtual Router offering
> Didn't notice any slow queries logged in DB.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-4148) usage:usage stats are not triggered for shared network

[Abhinandan Prateek (JIRA)]

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

Abhinandan Prateek updated CLOUDSTACK-4148:
---

Assignee: Kishan Kavala

> usage:usage stats are not triggered for shared network
> --
>
> Key: CLOUDSTACK-4148
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4148
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.2.0
>Reporter: sadhu suresh
>Assignee: Kishan Kavala
>Priority: Blocker
> Attachments: management-server.rar
>
>
> steps:
> 1.create network offering with SRX and F5 
> 2.create a shared guestnetwork using above NO
> 3.deploy a VM using abobve network
> 4.generate the traffic and check the usage stats after 10 min
> actual:
> NetworkUsageCommand: is running only for isolated network and its not issuing 
> for  for sharednetwok.
> router-12 isbelongs to sharednetwork.
> r-4-0vm belongs to isloated network
> No query specified
> mysql> select * from user_statistics;
> ++++---+---+--++++++++
> | id | data_center_id | account_id | public_ip_address | device_id | 
> device_type  | network_id | net_bytes_received | net_bytes_sent | 
> current_bytes_received | current_bytes_sent | agg_bytes_received | 
> agg_bytes_sent |
> ++++---+---+--++++++++
> |  1 |  1 |  2 | NULL  | 4 | 
> DomainRouter |204 |  0 |  0 | 
>  0 | 401016 |  0 | 401016 |
> |  2 |  1 |  1 | NULL  |12 | 
> DomainRouter |206 |  0 |  0 | 
>  0 |  0 |  0 |  0 |
> |  3 |  1 |  1 | NULL  |18 | 
> DomainRouter |209 |  0 |  0 | 
>  0 |  0 |  0 |  0 |
> |  4 |  1 |  2 | 10.147.49.106 |21 | 
> DomainRouter |200 |  0 |  0 | 
>4195797 | 148136 |4195797 | 148136 |
> |  5 |  1 |  2 | NULL  |21 | 
> DomainRouter |210 |  0 |  0 | 
>  0 |  0 |  0 |  0 |
> ++++---+---+--++++++++
> 5 rows in set (0.00 sec)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-4134) UI dosent fire the API with the Vlan values if the Vlan range is blank.

[Abhinandan Prateek (JIRA)]

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

Abhinandan Prateek updated CLOUDSTACK-4134:
---

Assignee: Bharat Kumar

> UI dosent fire the API with the Vlan values if the Vlan range is blank.
> ---
>
> Key: CLOUDSTACK-4134
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4134
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.2.0
>Reporter: Kiran Koneti
>Assignee: Bharat Kumar
>Priority: Critical
> Fix For: 4.2.0
>
>
> When we try to edit the Vlan range from the UI and give blank values in the 
> Vlan range box and try to update the page the API fried doesn't have any Vlan 
> details as it is blank in the UI.
> Eg:
> I tried the below scenario:
> 1)Created a setup with the Vlan range 1100-1109.
> 2)Then created a network where the Vlan 1101 is associated with the network.
> 3)Now I tried to edit the Vlan range and gave the blank value in the UI and 
> clicked update.
> The API fired is as below
> "10.147.38.237:8080/client/api?command=updatePhysicalNetwork&response=json&sessionkey=RRxhiAqmggnl%2F5oBGHNTm3DMj0M%3D&id=2409aeac-789a-4430-a9b7-fab66eb4b85c&_=1375867127326"
> Here the Vlan details are not fired in the API.
> Then I tried to edit it by giving the value 1102-1109  and  the API fired was 
> as below:
> "http://10.147.38.237:8080/client/api?command=updatePhysicalNetwork&response=json&sessionkey=RRxhiAqmggnl%2F5oBGHNTm3DMj0M%3D&id=2409aeac-789a-4430-a9b7-fab66eb4b85c&vlan=1102-1109&_=1375867287606";
> The API was fired currently with the Vlan values and there was a error 
> message as below
> "physicalnetwork 200 has allocated vnets in the range 1100-1101 " the below 
> is the expected behaviour and the same should happen when we try to update 
> the UI with Blank details.
> Note: Even the UI doesn't popup with any error message the Vlan range is not 
> getting deleted and we can see the same vlan range once we refresh the page.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (CLOUDSTACK-3344) ldap:UI:sending wrong query filter(converting &symbol to "amp&")during ldapconfig through UI[due to this ldap users fail to login]

[sadhu suresh (JIRA)]

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

sadhu suresh closed CLOUDSTACK-3344.



verified the issue in the new build and working fine.so closing this issue.

> ldap:UI:sending wrong query filter(converting &symbol to "amp&")during 
> ldapconfig through UI[due to this ldap users fail to login]
> --
>
> Key: CLOUDSTACK-3344
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3344
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.2.0
>Reporter: sadhu suresh
>Assignee: Jessica Wang
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: screenshot_ldap_ui.png
>
>
> Steps:
> 1. Configured the LDAP through UI by providing query filter as email 
> (eg:(&(mail=%e)))
> 2.check the configured values 
> Actual result:
> its converting & symbol into amp& while configuring the ldap through UI due 
> to this  ldap users fail to login.
> through API ,its working fine.this is the only problem with UI side where 
> they converting "&" symbolto "amp&"
> API fired while performing ldapconfig through UI:
> http://10.147.59.119:8080/client/api?command=ldapConfig&binddn=CN%3Dtest%2CCN%3DUsers%2CDC%3Dhyd-qa%2CDC%3Dcom&bindpass=_&hostname=10.147.38.163&searchbase=CN%3DUsers%2CDC%3Dhyd-qa%2CDC%3Dcom&queryfilter=(%26(mail%3D%25e))&port=389&ssl=false&response=json&sessionkey=zlWVnEF2HA3R4ekSa8kDXaZrY5k%3D&_=1372835435077
> { "ldapconfigresponse" :  { "ldapconfig" : 
> {"hostname":"10.147.38.163","port":"389","ssl":"false","searchbase":"CN=Users,DC=hyd-qa,DC=com","queryfilter":"(&(mail=%e))","binddn":"CN=test,CN=Users,DC=hyd-qa,DC=com"}
>  }  }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-4069) [EIP/ELB] [UI] There is no option to acquire IP address for non-ROOT domain users.

[venkata swamybabu budumuru (JIRA)]

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

venkata swamybabu budumuru updated CLOUDSTACK-4069:
---

Assignee: Jessica Wang  (was: venkata swamybabu budumuru)

> [EIP/ELB] [UI] There is no option to acquire IP address for non-ROOT domain 
> users. 
> ---
>
> Key: CLOUDSTACK-4069
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4069
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.2.0
> Environment: commit id # 7522f811672f66bc0cc13a33f4f3737ef03f22af
>Reporter: venkata swamybabu budumuru
>Assignee: Jessica Wang
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: jessica_computer__using_venkata_databaseDump.jpg, 
> logs.tgz, Screen Shot 2013-08-05 at 2.12.20 PM.png
>
>
> Steps to reproduce:
> 1. Have latest cloudstack setup with at least one EIP/ELB enabled zone
> 2. Login as non-ROOT domain user
> 3. Go to Network -> View IP Address and check for option to "Acquire IP 
> address"
> Observations:
> (i) There is no option like "Acquire IP Address" button in the UI.
> (ii) API is working fine without any issues.
> Attaching the screenshot of the same along with logs and db dump.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-4069) [EIP/ELB] [UI] There is no option to acquire IP address for non-ROOT domain users.

[venkata swamybabu budumuru (JIRA)]

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

venkata swamybabu budumuru commented on CLOUDSTACK-4069:


It is our standard default password i.e. "password"

Username : dom1User1
passowrd : password
domain : dom1

Another account as well you can try is :


Username : dom1User2
passowrd : password
domain : dom1

> [EIP/ELB] [UI] There is no option to acquire IP address for non-ROOT domain 
> users. 
> ---
>
> Key: CLOUDSTACK-4069
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4069
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.2.0
> Environment: commit id # 7522f811672f66bc0cc13a33f4f3737ef03f22af
>Reporter: venkata swamybabu budumuru
>Assignee: venkata swamybabu budumuru
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: jessica_computer__using_venkata_databaseDump.jpg, 
> logs.tgz, Screen Shot 2013-08-05 at 2.12.20 PM.png
>
>
> Steps to reproduce:
> 1. Have latest cloudstack setup with at least one EIP/ELB enabled zone
> 2. Login as non-ROOT domain user
> 3. Go to Network -> View IP Address and check for option to "Acquire IP 
> address"
> Observations:
> (i) There is no option like "Acquire IP Address" button in the UI.
> (ii) API is working fine without any issues.
> Attaching the screenshot of the same along with logs and db dump.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-4142) [EIP/ELB] [UI] "Add LoadBalancer" option is not available for non-ROOT domain user.

[venkata swamybabu budumuru (JIRA)]

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

venkata swamybabu budumuru updated CLOUDSTACK-4142:
---

Assignee: Jessica Wang  (was: venkata swamybabu budumuru)

> [EIP/ELB] [UI] "Add LoadBalancer" option is not available for non-ROOT domain 
> user.
> ---
>
> Key: CLOUDSTACK-4142
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4142
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.2.0
> Environment: commit # 7fced6460f13468369550c968670c7d0b9837949
>Reporter: venkata swamybabu budumuru
>Assignee: Jessica Wang
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: logs.tgz, Screen Shot 2013-08-07 at 5.28.55 PM.png, 
> Screen Shot 2013-08-07 at 5.29.25 PM.png
>
>
> Steps to reproduce:
> 1. Have latest CloudStack setup with at least 1 EIP/ELB enabled zone.
> 2. Have at least one sub domain under ROOT domain and at least one user in 
> the non-ROOT domain.
> 3. Login as the above non-ROOT domain user and Go to Networks -> 
> guestNetworkForBasicZone 
> Observations:
> (i) It doesn't show an option called "Add LoadBalancer" 
> (ii) But, when you login as ROOT admin then we can see the same option. 
> (iii) As a non-ROOT admin, I have checked with API and that works fine. Below 
> mentioned is the api that went fine. 
> create loadbalancerrule name=zone2LB2 
> networkid=83858f62-5dea-482a-8f7b-8f3d199526d0 privateport=22 publicport=22 
> algorithm=roundrobin domainid=2 account=dom1Acc1 openfirewall=false 
> http://10.147.59.194:8096/api?command=assignToLoadBalancerRule&id=419a967b-1d23-4316-8042-58182333afa6&virtualmachineids=285d67f1-5fc4-4e04-b823-67ec9cf8d84d
>   

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-4142) [EIP/ELB] [UI] "Add LoadBalancer" option is not available for non-ROOT domain user.

[venkata swamybabu budumuru (JIRA)]

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

venkata swamybabu budumuru commented on CLOUDSTACK-4142:


It is our standard default password i.e. "password"

Username : dom1User1
passowrd : password
domain : dom1

> [EIP/ELB] [UI] "Add LoadBalancer" option is not available for non-ROOT domain 
> user.
> ---
>
> Key: CLOUDSTACK-4142
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4142
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.2.0
> Environment: commit # 7fced6460f13468369550c968670c7d0b9837949
>Reporter: venkata swamybabu budumuru
>Assignee: venkata swamybabu budumuru
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: logs.tgz, Screen Shot 2013-08-07 at 5.28.55 PM.png, 
> Screen Shot 2013-08-07 at 5.29.25 PM.png
>
>
> Steps to reproduce:
> 1. Have latest CloudStack setup with at least 1 EIP/ELB enabled zone.
> 2. Have at least one sub domain under ROOT domain and at least one user in 
> the non-ROOT domain.
> 3. Login as the above non-ROOT domain user and Go to Networks -> 
> guestNetworkForBasicZone 
> Observations:
> (i) It doesn't show an option called "Add LoadBalancer" 
> (ii) But, when you login as ROOT admin then we can see the same option. 
> (iii) As a non-ROOT admin, I have checked with API and that works fine. Below 
> mentioned is the api that went fine. 
> create loadbalancerrule name=zone2LB2 
> networkid=83858f62-5dea-482a-8f7b-8f3d199526d0 privateport=22 publicport=22 
> algorithm=roundrobin domainid=2 account=dom1Acc1 openfirewall=false 
> http://10.147.59.194:8096/api?command=assignToLoadBalancerRule&id=419a967b-1d23-4316-8042-58182333afa6&virtualmachineids=285d67f1-5fc4-4e04-b823-67ec9cf8d84d
>   

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-4057) Cannot unselect VPC network when only want to select isolated network

[Animesh Chaturvedi (JIRA)]

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

Animesh Chaturvedi updated CLOUDSTACK-4057:
---

Assignee: Brian Federle

> Cannot unselect VPC network when only want to select isolated network
> -
>
> Key: CLOUDSTACK-4057
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4057
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.2.0
>Reporter: Ahmad Emneina
>Assignee: Brian Federle
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: vpc_issue.png
>
>
> I got an environment where an isolated network (non-VPC, cfiso1) and an 
> isolated network (VPC, WebTier) is present. 
> When trying to add to a new instance cfiso01 only this is not possible in the 
> GUI. I am not able to unselect “WebTier”. 
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (CLOUDSTACK-3414) Physical Netwok traffic lable update requires Management Server restart

[Sailaja Mada (JIRA)]

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

Sailaja Mada reopened CLOUDSTACK-3414:
--


Hi,

One of the use we are trying to achieve is to have VMWARE Cluster with Standard 
vSwitch with few deployed VM's.  Later Update the traffic labels to DVSwitch to 
have the newly deployed VM's to get deployed on DVSwitch.

So here when traffic labels are updated Admin will not get notified to restart 
management server.  Admin has to go thru entire doc for this small info to 
restart Management server.

Instead it would really help to just notify to restart Management server . This 
would simplify a lot of debugging .


Hence i am reopening the bug.  Please leave it unassigned if its not 
interesting to fix.  It would help admin so i would wait for this fix to be 
done.

Thanks,
Sailaja.M


> Physical Netwok traffic lable update requires Management Server restart 
> 
>
> Key: CLOUDSTACK-3414
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3414
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.2.0
>Reporter: Sailaja Mada
> Fix For: 4.2.0
>
>
> Setup :  VMWARE Adv Zone. 
> Note: This issue may not be specific to VMWARE
> Steps:
> 1. Tried to configure Adv Zone with VMWARE 
> 2. Configure Physical network 1 with Management Traffic with invalid traffic 
> label ( Ex: vSwitch0,,vmwaresvs) 
> 3. Configure Physical network 2 with public & guest Traffic with correct 
> DVSwitch traffic label ( Ex: newdv1,,vmwaredvs) 
> 4. Now System VM's  are failed to start as it failed to create network for 
> Mgmt traffic.
> 2013-07-09 14:00:50,521 INFO  [vmware.resource.VmwareResource] 
> (DirectAgent-7:10.102.192.18) Prepare NIC device based on NicTO: 
> {"deviceId":0,"networkRateMbps":-1,"defaultNic":false,"uuid":"789e034d-e287-4389-beac-29a10326c0ea","mac":"02:00:41:48:00:05","broadcastType":"LinkLocal","type":"Control","isSecurityGroupEnabled":false}
> 2013-07-09 14:00:50,525 INFO  [vmware.resource.VmwareResource] 
> (DirectAgent-7:10.102.192.18) Prepare network on vmwaresvs 
> P[vSwitch0,,vmwaresvs:untagged] with name prefix: cloud.private
> 2013-07-09 14:00:50,525 WARN  [vmware.resource.VmwareResource] 
> (DirectAgent-7:10.102.192.18) Unrecognized broadcast type in VmwareResource, 
> type: LinkLocal. Use vlan info from labeling: untagged
> 2013-07-09 14:00:50,552 ERROR [vmware.mo.HypervisorHostHelper] 
> (DirectAgent-7:10.102.192.18) Unable to find vSwitchvSwitch0,,vmwaresvs
> 2013-07-09 14:00:50,553 WARN  [vmware.resource.VmwareResource] 
> (DirectAgent-7:10.102.192.18) StartCommand failed due to Exception: 
> java.lang.Exception
> Message: Unable to find vSwitchvSwitch0,,vmwaresvs
> java.lang.Exception: Unable to find vSwitchvSwitch0,,vmwaresvs
> at 
> com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:830)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:2923)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2687)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:479)
> at 
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-07-09 14:00:50,556 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-7:null) Seq 1-763953202: Cancelling because one of the answers 
> is false and it is stop on error.
> 2013-07-09 14:00:50,557 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-7:null) Seq 1-763953202: Response Received:
> 6. Now updated Mgmt traffic label to vSwitch0. 
> 7. DB got updated automatically .
> 8. But System Vm's are still failed to start with this 
> 9. Restarted Management server (server cloudstack-management stop/ start)
> 10. Now system VM's are up with network name vSwitch0.
> Expected results :

[jira] [Closed] (CLOUDSTACK-2905) Recurring Snapshots are failing becuase of NullPointerException.

[satoru nakaya (JIRA)]

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

satoru nakaya closed CLOUDSTACK-2905.
-


> Recurring Snapshots are failing becuase of NullPointerException.
> 
>
> Key: CLOUDSTACK-2905
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2905
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.1.0, 4.2.0
> Environment: cloudstack-management-4.1.0-0.el6.x86_64
>Reporter: satoru nakaya
>Assignee: Rajesh Battala
>Priority: Blocker
> Fix For: 4.1.1, 4.2.0
>
>
> Create an Hourly Recurring snapshot policy on the ROOT disk.
> Snapshot policy gets created successfully.
> But when it is time to create a snapshot, snapshot scheduler thread 
> encounters a NullPointer Exception:
> Management server logs:
> # tail -f management-server.log  | grep SnapshotSchedulerImpl
> 2013-06-08 08:06:11,393 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
> (SnapshotPollTask:null) Snapshot scheduler.poll is being called at 2013-06-07 
> 23:06:11 GMT
> 2013-06-08 08:06:11,395 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
> (SnapshotPollTask:null) Got 0 snapshots to be executed at 2013-06-07 23:06:11 
> GMT
> 2013-06-08 08:08:39,459 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
> (catalina-exec-4:null) Current time is 2013-06-07 23:06:11 GMT. 
> NextScheduledTime of policyId 1 is 2013-06-07 23:10:00 GMT
> 2013-06-08 08:11:11,393 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
> (SnapshotPollTask:null) Snapshot scheduler.poll is being called at 2013-06-07 
> 23:11:11 GMT
> 2013-06-08 08:11:11,397 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
> (SnapshotPollTask:null) Got 1 snapshots to be executed at 2013-06-07 23:11:11 
> GMT
> 2013-06-08 08:11:11,400 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
> (SnapshotPollTask:null) Scheduling 1 snapshot for volume 3 for schedule id: 1 
> at 2013-06-07 23:10:00 GMT
> 2013-06-08 08:11:11,453 WARN  [storage.snapshot.SnapshotSchedulerImpl] 
> (SnapshotPollTask:null) Scheduling snapshot failed due to 
> java.lang.NullPointerException

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-2905) Recurring Snapshots are failing becuase of NullPointerException.

[satoru nakaya (JIRA)]

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

satoru nakaya commented on CLOUDSTACK-2905:
---

Thank you so much. :)

> Recurring Snapshots are failing becuase of NullPointerException.
> 
>
> Key: CLOUDSTACK-2905
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2905
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.1.0, 4.2.0
> Environment: cloudstack-management-4.1.0-0.el6.x86_64
>Reporter: satoru nakaya
>Assignee: Rajesh Battala
>Priority: Blocker
> Fix For: 4.1.1, 4.2.0
>
>
> Create an Hourly Recurring snapshot policy on the ROOT disk.
> Snapshot policy gets created successfully.
> But when it is time to create a snapshot, snapshot scheduler thread 
> encounters a NullPointer Exception:
> Management server logs:
> # tail -f management-server.log  | grep SnapshotSchedulerImpl
> 2013-06-08 08:06:11,393 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
> (SnapshotPollTask:null) Snapshot scheduler.poll is being called at 2013-06-07 
> 23:06:11 GMT
> 2013-06-08 08:06:11,395 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
> (SnapshotPollTask:null) Got 0 snapshots to be executed at 2013-06-07 23:06:11 
> GMT
> 2013-06-08 08:08:39,459 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
> (catalina-exec-4:null) Current time is 2013-06-07 23:06:11 GMT. 
> NextScheduledTime of policyId 1 is 2013-06-07 23:10:00 GMT
> 2013-06-08 08:11:11,393 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
> (SnapshotPollTask:null) Snapshot scheduler.poll is being called at 2013-06-07 
> 23:11:11 GMT
> 2013-06-08 08:11:11,397 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
> (SnapshotPollTask:null) Got 1 snapshots to be executed at 2013-06-07 23:11:11 
> GMT
> 2013-06-08 08:11:11,400 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
> (SnapshotPollTask:null) Scheduling 1 snapshot for volume 3 for schedule id: 1 
> at 2013-06-07 23:10:00 GMT
> 2013-06-08 08:11:11,453 WARN  [storage.snapshot.SnapshotSchedulerImpl] 
> (SnapshotPollTask:null) Scheduling snapshot failed due to 
> java.lang.NullPointerException

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-4167) Put in upgrade paths in master for 4.1.2 and 4.2

[Venkata Siva Vijayendra Bhamidipati (JIRA)]

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

Venkata Siva Vijayendra Bhamidipati updated CLOUDSTACK-4167:


Status: Ready To Review  (was: In Progress)

> Put in upgrade paths in master for 4.1.2 and 4.2
> 
>
> Key: CLOUDSTACK-4167
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4167
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: Future
>Reporter: Venkata Siva Vijayendra Bhamidipati
>Assignee: Venkata Siva Vijayendra Bhamidipati
>Priority: Minor
>
> In 4.1 branch, the latest version is 4.1.2. So the upgrade path on 4.1 now 
> will go thus:
> 4.0.0 -> 4.1.0 -> 4.1.1 -> 4.1.2.
> Now, on the 4.2 branch, it goes thus:
> 4.0.0 -> 4.1.0 -> 4.2.0
> At this point in time, neither 4.2.0 nor 4.1.2 have been released. It is 
> unclear which will get released first.
> If 4.1.2 gets released before 4.2.0, we'll need to define an empty upgrade 
> path from 4.1.0 to 4.1.2 first, and then another empty upgrade path from 
> 4.1.2 to 4.2.0.
> If 4.2.0 gets released before 4.1.2, we will need to define an upgrade path 
> from 4.2.0 to 4.1.2 and then another path from 4.1.2 to 4.2.0. Again there 
> won't really be any SQL operations to do in these two paths.
> Putting in these upgrade paths tells us which version got released after 
> which. In case there are any SQL changes that need to be made, we must put 
> those in as well. In any case, the final version when upgrading to 4.2.0 will 
> end up at 4.2.0.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-4167) Put in upgrade paths in master for 4.1.2 and 4.2

[Venkata Siva Vijayendra Bhamidipati (JIRA)]

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

Venkata Siva Vijayendra Bhamidipati commented on CLOUDSTACK-4167:
-

Patch posted for review at https://reviews.apache.org/r/13298/



> Put in upgrade paths in master for 4.1.2 and 4.2
> 
>
> Key: CLOUDSTACK-4167
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4167
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: Future
>Reporter: Venkata Siva Vijayendra Bhamidipati
>Assignee: Venkata Siva Vijayendra Bhamidipati
>Priority: Minor
>
> In 4.1 branch, the latest version is 4.1.2. So the upgrade path on 4.1 now 
> will go thus:
> 4.0.0 -> 4.1.0 -> 4.1.1 -> 4.1.2.
> Now, on the 4.2 branch, it goes thus:
> 4.0.0 -> 4.1.0 -> 4.2.0
> At this point in time, neither 4.2.0 nor 4.1.2 have been released. It is 
> unclear which will get released first.
> If 4.1.2 gets released before 4.2.0, we'll need to define an empty upgrade 
> path from 4.1.0 to 4.1.2 first, and then another empty upgrade path from 
> 4.1.2 to 4.2.0.
> If 4.2.0 gets released before 4.1.2, we will need to define an upgrade path 
> from 4.2.0 to 4.1.2 and then another path from 4.1.2 to 4.2.0. Again there 
> won't really be any SQL operations to do in these two paths.
> Putting in these upgrade paths tells us which version got released after 
> which. In case there are any SQL changes that need to be made, we must put 
> those in as well. In any case, the final version when upgrading to 4.2.0 will 
> end up at 4.2.0.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (CLOUDSTACK-3609) ASF 4.1 to 4.2 Upgrade: Invalid Global Configuration parameters are present on the Upgraded Setup

[Venkata Siva Vijayendra Bhamidipati (JIRA)]

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

Venkata Siva Vijayendra Bhamidipati updated CLOUDSTACK-3609:


Status: Ready To Review  (was: In Progress)

> ASF 4.1 to 4.2 Upgrade: Invalid Global Configuration parameters are present 
> on the Upgraded Setup
> -
>
> Key: CLOUDSTACK-3609
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3609
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Upgrade
>Affects Versions: 4.2.0
>Reporter: Chandan Purushothama
>Assignee: Venkata Siva Vijayendra Bhamidipati
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: DBCapture-3.PNG
>
>
> Attached the screenshot of the invalid global parameters to the bug report. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-3609) ASF 4.1 to 4.2 Upgrade: Invalid Global Configuration parameters are present on the Upgraded Setup

[Venkata Siva Vijayendra Bhamidipati (JIRA)]

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

Venkata Siva Vijayendra Bhamidipati commented on CLOUDSTACK-3609:
-

Patch posted at https://reviews.apache.org/r/13404/ .

The patch for 4167 has been posted to the same review request for 4091 : 
https://reviews.apache.org/r/13298/

> ASF 4.1 to 4.2 Upgrade: Invalid Global Configuration parameters are present 
> on the Upgraded Setup
> -
>
> Key: CLOUDSTACK-3609
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3609
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Upgrade
>Affects Versions: 4.2.0
>Reporter: Chandan Purushothama
>Assignee: Venkata Siva Vijayendra Bhamidipati
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: DBCapture-3.PNG
>
>
> Attached the screenshot of the invalid global parameters to the bug report. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-4109) [Object_store_refactor] Extract volume failed with NPE

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-4109:
-

Commit e851f4a93039afac57f0ff790791cd1bbed624cf in branch refs/heads/master 
from [~edison]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e851f4a ]

CLOUDSTACK-4109: fix upload volume to s3 for vmware


> [Object_store_refactor] Extract volume failed with NPE
> --
>
> Key: CLOUDSTACK-4109
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4109
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller, VMware, Volumes
>Affects Versions: 4.2.0
> Environment: Latest build from ACS 4.2 branch.
> Storage: S3 for secondary, NFS for staging and ISCSI for primary storage
>Reporter: Sanjeev N
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: cloud.dmp, management-server.rar
>
>
> Extract volume failed with NPE
> Steps to Reproduce:
> 
> 1.Bring up CS with VMWare cluster using S3 for secondary ,NFS for staging and 
> ISCSI for primary storage.
> 2.Deploy guest vm with root disk
> 3.Create a custom data disk and attach to the vm
> 4.Dettach the data disk and try to extract the volume
> Result:
> ==
> Download volume failed with NPE but still UI prompted with URL to download 
> the volume even-though volume was not copied to S3 storage.
> Log snippet as follows:
> 2013-08-06 07:32:46,296 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (catalina-exec-10:null) submit async job-25 = [ 
> 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ], details: AsyncJobVO {id:25, userId: 
> 2, accountId: 2, sessionKey: null, instanceType: Volume, instanceId: 11, cmd: 
> org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd, 
> cmdOriginator: null, cmdInfo: 
> {"response":"json","id":"003c0b9c-176f-463e-aac7-fdefde807c86","sessionkey":"foQa9K4dPmYo8uEiAcolaTVR6yI\u003d","cmdEventType":"VOLUME.EXTRACT","ctxUserId":"2","zoneid":"a7c59acd-1b2f-4f06-b50b-bd79e113c692","httpmethod":"GET","_":"1375788754095","ctxAccountId":"2","ctxStartEventId":"95","mode":"HTTP_DOWNLOAD"},
>  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
> processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382, 
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-06 07:32:46,298 DEBUG [cloud.api.ApiServlet] (catalina-exec-10:null) 
> ===END===  10.146.0.20 -- GET  
> command=extractVolume&id=003c0b9c-176f-463e-aac7-fdefde807c86&zoneid=a7c59acd-1b2f-4f06-b50b-bd79e113c692&mode=HTTP_DOWNLOAD&response=json&sessionkey=foQa9K4dPmYo8uEiAcolaTVR6yI%3D&_=1375788754095
> 2013-08-06 07:32:46,302 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-26:job-25 = [ 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]) Executing 
> org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd for job-25 = [ 
> 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]
> 2013-08-06 07:32:46,395 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-26:job-25 = [ 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]) copyAsync 
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-06 07:32:46,406 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-26:job-25 = [ 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]) 
> needCacheStorage true, dest at volumes/2/11 dest role 
> Image7a16cf210c6c4af3b39a04c94dca7035 src role Primary
> 2013-08-06 07:32:46,430 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-26:job-25 = [ 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]) copyAsync 
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-06 07:32:46,462 DEBUG [agent.transport.Request] 
> (Job-Executor-26:job-25 = [ 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]) Seq 
> 3-1317535767: Sending  { Cmd , MgmtId: 6615759585382, via: 3, Ver: v1, Flags: 
> 100011, 
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"003c0b9c-176f-463e-aac7-fdefde807c86","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"b845e7d4-562a-3b2d-8e59-b1df565f99e5","id":1,"poolType":"VMFS","host":"VMFS
>  datastore: 
> /sanjeev/openFiler","path":"/sanjeev/openFiler","port":0}},"name":"v1","size":5120,"path":"7a16cf210c6c4af3b39a04c94dca7035","volumeId":11,"accountId":2,"format":"OVA","id":11,"hypervisorType":"VMware"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"003c0b9c-176f-463e-aac7-fdefde807c86","volumeType":"DATADISK","dataStore":{"com.cloud.agent.api.to.NfsT

[jira] [Commented] (CLOUDSTACK-4108) [Object_store_refactor] Failed to create template from snapshot in VMWare with S3 storage

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-4108:
-

Commit 9bce985f622ed1ac25b1ad700a4e2bfb88e38ab0 in branch refs/heads/master 
from [~edison]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9bce985 ]

CLOUDSTACK-4108: fix create template from snapshot for vmware& s3


> [Object_store_refactor] Failed to create template from snapshot in VMWare 
> with S3 storage
> -
>
> Key: CLOUDSTACK-4108
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4108
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller, Template, VMware
>Affects Versions: 4.2.0
> Environment: Latest build from ACS 4.2 branch
> Storage: S3 for secondary and ISCSI for primary
>Reporter: Sanjeev N
>Assignee: edison su
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: cloud.dmp, management-server.rar
>
>
> Failed to create template from snapshot in VMWare with S3 storage
> Steps to Reproduce:
> ===
> 1.Bring up CS with VMWare cluster using S3 for secondary , NFS for staging 
> and ISCSI for primary storage.
> 2.Deploy guest vm using default cent os template.
> 3.Create snapshot from the root disk of the vm.
> 4.Try to create template from the snapshot.
> Observations:
> 
> Template creation failed with Unexpected exception
> Log snippet from the management server log as follows:
> 2013-08-06 06:47:30,027 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (catalina-exec-12:null) submit async job-20 = [ 
> 146cfdb9-afff-4468-a41e-689781b79858 ], details: AsyncJobVO {id:20, userId: 
> 2, accountId: 2, sessionKey: null, instanceType: Template, instanceId: 204, 
> cmd: org.apache.cloudstack.api.command.user.template.CreateTemplateCmd, 
> cmdOriginator: null, cmdInfo: 
> {"sessionkey":"foQa9K4dPmYo8uEiAcolaTVR6yI\u003d","cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"257e87ce-fe5f-11e2-a4b5-06045a66","isPublic":"true","response":"json","isdynamicallyscalable":"false","id":"204","displayText":"fromVM2","snapshotid":"2c859471-370d-45cc-89fa-0c98f7232ed0","passwordEnabled":"false","name":"fromVM2","_":"1375786037905","ctxAccountId":"2","ctxStartEventId":"77"},
>  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
> processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382, 
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-06 06:47:30,030 DEBUG [cloud.api.ApiServlet] (catalina-exec-12:null) 
> ===END===  10.146.0.20 -- GET  
> command=createTemplate&response=json&sessionkey=foQa9K4dPmYo8uEiAcolaTVR6yI%3D&snapshotid=2c859471-370d-45cc-89fa-0c98f7232ed0&name=fromVM2&displayText=fromVM2&osTypeId=257e87ce-fe5f-11e2-a4b5-06045a66&isPublic=true&passwordEnabled=false&isdynamicallyscalable=false&_=1375786037905
> 2013-08-06 06:47:30,032 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-21:job-20 = [ 146cfdb9-afff-4468-a41e-689781b79858 ]) Executing 
> org.apache.cloudstack.api.command.user.template.CreateTemplateCmd for job-20 
> = [ 146cfdb9-afff-4468-a41e-689781b79858 ]
> 2013-08-06 06:47:30,080 DEBUG [storage.image.TemplateDataFactoryImpl] 
> (Job-Executor-21:job-20 = [ 146cfdb9-afff-4468-a41e-689781b79858 ]) template 
> 204 is already in store:7, type:Image
> 2013-08-06 06:47:30,095 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-21:job-20 = [ 146cfdb9-afff-4468-a41e-689781b79858 ]) copyAsync 
> inspecting src type SNAPSHOT copyAsync inspecting dest type TEMPLATE
> 2013-08-06 06:47:30,123 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-21:job-20 = [ 146cfdb9-afff-4468-a41e-689781b79858 ]) 
> needCacheStorage true, dest at 
> template/tmpl/2/204/2c3b5b792-8c9d-380b-b982-ac8891d0e9a3 dest role 
> Imagesnapshots/2/8/89140ae5-c3e5-40df-8ec9-626773d0ff6b.ova src role Image
> 2013-08-06 06:47:30,147 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-21:job-20 = [ 146cfdb9-afff-4468-a41e-689781b79858 ]) copyAsync 
> inspecting src type SNAPSHOT copyAsync inspecting dest type SNAPSHOT
> 2013-08-06 06:47:30,233 DEBUG [agent.transport.Request] 
> (Job-Executor-21:job-20 = [ 146cfdb9-afff-4468-a41e-689781b79858 ]) Seq 
> 3-1317535764: Sending  { Cmd , MgmtId: 6615759585382, via: 3, Ver: v1, Flags: 
> 100011, 
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"snapshots/2/8/89140ae5-c3e5-40df-8ec9-626773d0ff6b.ova","volume

[jira] [Commented] (CLOUDSTACK-4108) [Object_store_refactor] Failed to create template from snapshot in VMWare with S3 storage

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-4108:
-

Commit f6b66b94f0789bc1a8bb0aa64ae3aaa9e2b9ea16 in branch refs/heads/4.2 from 
[~edison]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f6b66b9 ]

CLOUDSTACK-4108: fix create template from snapshot for vmware& s3


> [Object_store_refactor] Failed to create template from snapshot in VMWare 
> with S3 storage
> -
>
> Key: CLOUDSTACK-4108
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4108
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller, Template, VMware
>Affects Versions: 4.2.0
> Environment: Latest build from ACS 4.2 branch
> Storage: S3 for secondary and ISCSI for primary
>Reporter: Sanjeev N
>Assignee: edison su
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: cloud.dmp, management-server.rar
>
>
> Failed to create template from snapshot in VMWare with S3 storage
> Steps to Reproduce:
> ===
> 1.Bring up CS with VMWare cluster using S3 for secondary , NFS for staging 
> and ISCSI for primary storage.
> 2.Deploy guest vm using default cent os template.
> 3.Create snapshot from the root disk of the vm.
> 4.Try to create template from the snapshot.
> Observations:
> 
> Template creation failed with Unexpected exception
> Log snippet from the management server log as follows:
> 2013-08-06 06:47:30,027 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (catalina-exec-12:null) submit async job-20 = [ 
> 146cfdb9-afff-4468-a41e-689781b79858 ], details: AsyncJobVO {id:20, userId: 
> 2, accountId: 2, sessionKey: null, instanceType: Template, instanceId: 204, 
> cmd: org.apache.cloudstack.api.command.user.template.CreateTemplateCmd, 
> cmdOriginator: null, cmdInfo: 
> {"sessionkey":"foQa9K4dPmYo8uEiAcolaTVR6yI\u003d","cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"257e87ce-fe5f-11e2-a4b5-06045a66","isPublic":"true","response":"json","isdynamicallyscalable":"false","id":"204","displayText":"fromVM2","snapshotid":"2c859471-370d-45cc-89fa-0c98f7232ed0","passwordEnabled":"false","name":"fromVM2","_":"1375786037905","ctxAccountId":"2","ctxStartEventId":"77"},
>  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
> processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382, 
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-06 06:47:30,030 DEBUG [cloud.api.ApiServlet] (catalina-exec-12:null) 
> ===END===  10.146.0.20 -- GET  
> command=createTemplate&response=json&sessionkey=foQa9K4dPmYo8uEiAcolaTVR6yI%3D&snapshotid=2c859471-370d-45cc-89fa-0c98f7232ed0&name=fromVM2&displayText=fromVM2&osTypeId=257e87ce-fe5f-11e2-a4b5-06045a66&isPublic=true&passwordEnabled=false&isdynamicallyscalable=false&_=1375786037905
> 2013-08-06 06:47:30,032 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-21:job-20 = [ 146cfdb9-afff-4468-a41e-689781b79858 ]) Executing 
> org.apache.cloudstack.api.command.user.template.CreateTemplateCmd for job-20 
> = [ 146cfdb9-afff-4468-a41e-689781b79858 ]
> 2013-08-06 06:47:30,080 DEBUG [storage.image.TemplateDataFactoryImpl] 
> (Job-Executor-21:job-20 = [ 146cfdb9-afff-4468-a41e-689781b79858 ]) template 
> 204 is already in store:7, type:Image
> 2013-08-06 06:47:30,095 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-21:job-20 = [ 146cfdb9-afff-4468-a41e-689781b79858 ]) copyAsync 
> inspecting src type SNAPSHOT copyAsync inspecting dest type TEMPLATE
> 2013-08-06 06:47:30,123 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-21:job-20 = [ 146cfdb9-afff-4468-a41e-689781b79858 ]) 
> needCacheStorage true, dest at 
> template/tmpl/2/204/2c3b5b792-8c9d-380b-b982-ac8891d0e9a3 dest role 
> Imagesnapshots/2/8/89140ae5-c3e5-40df-8ec9-626773d0ff6b.ova src role Image
> 2013-08-06 06:47:30,147 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-21:job-20 = [ 146cfdb9-afff-4468-a41e-689781b79858 ]) copyAsync 
> inspecting src type SNAPSHOT copyAsync inspecting dest type SNAPSHOT
> 2013-08-06 06:47:30,233 DEBUG [agent.transport.Request] 
> (Job-Executor-21:job-20 = [ 146cfdb9-afff-4468-a41e-689781b79858 ]) Seq 
> 3-1317535764: Sending  { Cmd , MgmtId: 6615759585382, via: 3, Ver: v1, Flags: 
> 100011, 
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"snapshots/2/8/89140ae5-c3e5-40df-8ec9-626773d0ff6b.ova","volume":{

[jira] [Resolved] (CLOUDSTACK-4108) [Object_store_refactor] Failed to create template from snapshot in VMWare with S3 storage

[edison su (JIRA)]

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

edison su resolved CLOUDSTACK-4108.
---

Resolution: Fixed

> [Object_store_refactor] Failed to create template from snapshot in VMWare 
> with S3 storage
> -
>
> Key: CLOUDSTACK-4108
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4108
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller, Template, VMware
>Affects Versions: 4.2.0
> Environment: Latest build from ACS 4.2 branch
> Storage: S3 for secondary and ISCSI for primary
>Reporter: Sanjeev N
>Assignee: edison su
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: cloud.dmp, management-server.rar
>
>
> Failed to create template from snapshot in VMWare with S3 storage
> Steps to Reproduce:
> ===
> 1.Bring up CS with VMWare cluster using S3 for secondary , NFS for staging 
> and ISCSI for primary storage.
> 2.Deploy guest vm using default cent os template.
> 3.Create snapshot from the root disk of the vm.
> 4.Try to create template from the snapshot.
> Observations:
> 
> Template creation failed with Unexpected exception
> Log snippet from the management server log as follows:
> 2013-08-06 06:47:30,027 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (catalina-exec-12:null) submit async job-20 = [ 
> 146cfdb9-afff-4468-a41e-689781b79858 ], details: AsyncJobVO {id:20, userId: 
> 2, accountId: 2, sessionKey: null, instanceType: Template, instanceId: 204, 
> cmd: org.apache.cloudstack.api.command.user.template.CreateTemplateCmd, 
> cmdOriginator: null, cmdInfo: 
> {"sessionkey":"foQa9K4dPmYo8uEiAcolaTVR6yI\u003d","cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"257e87ce-fe5f-11e2-a4b5-06045a66","isPublic":"true","response":"json","isdynamicallyscalable":"false","id":"204","displayText":"fromVM2","snapshotid":"2c859471-370d-45cc-89fa-0c98f7232ed0","passwordEnabled":"false","name":"fromVM2","_":"1375786037905","ctxAccountId":"2","ctxStartEventId":"77"},
>  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
> processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382, 
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-06 06:47:30,030 DEBUG [cloud.api.ApiServlet] (catalina-exec-12:null) 
> ===END===  10.146.0.20 -- GET  
> command=createTemplate&response=json&sessionkey=foQa9K4dPmYo8uEiAcolaTVR6yI%3D&snapshotid=2c859471-370d-45cc-89fa-0c98f7232ed0&name=fromVM2&displayText=fromVM2&osTypeId=257e87ce-fe5f-11e2-a4b5-06045a66&isPublic=true&passwordEnabled=false&isdynamicallyscalable=false&_=1375786037905
> 2013-08-06 06:47:30,032 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-21:job-20 = [ 146cfdb9-afff-4468-a41e-689781b79858 ]) Executing 
> org.apache.cloudstack.api.command.user.template.CreateTemplateCmd for job-20 
> = [ 146cfdb9-afff-4468-a41e-689781b79858 ]
> 2013-08-06 06:47:30,080 DEBUG [storage.image.TemplateDataFactoryImpl] 
> (Job-Executor-21:job-20 = [ 146cfdb9-afff-4468-a41e-689781b79858 ]) template 
> 204 is already in store:7, type:Image
> 2013-08-06 06:47:30,095 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-21:job-20 = [ 146cfdb9-afff-4468-a41e-689781b79858 ]) copyAsync 
> inspecting src type SNAPSHOT copyAsync inspecting dest type TEMPLATE
> 2013-08-06 06:47:30,123 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-21:job-20 = [ 146cfdb9-afff-4468-a41e-689781b79858 ]) 
> needCacheStorage true, dest at 
> template/tmpl/2/204/2c3b5b792-8c9d-380b-b982-ac8891d0e9a3 dest role 
> Imagesnapshots/2/8/89140ae5-c3e5-40df-8ec9-626773d0ff6b.ova src role Image
> 2013-08-06 06:47:30,147 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-21:job-20 = [ 146cfdb9-afff-4468-a41e-689781b79858 ]) copyAsync 
> inspecting src type SNAPSHOT copyAsync inspecting dest type SNAPSHOT
> 2013-08-06 06:47:30,233 DEBUG [agent.transport.Request] 
> (Job-Executor-21:job-20 = [ 146cfdb9-afff-4468-a41e-689781b79858 ]) Seq 
> 3-1317535764: Sending  { Cmd , MgmtId: 6615759585382, via: 3, Ver: v1, Flags: 
> 100011, 
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"snapshots/2/8/89140ae5-c3e5-40df-8ec9-626773d0ff6b.ova","volume":{"uuid":"972c66f9-dfa8-4745-b817-8a7ddf2049a6","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"b845e7d4-562a-3b2d-8e59-b1df565f99e5","id":1,"poolType":"VMFS","host":"VMFS
>  datastore: 
> /sanjeev/openFiler","path":"/sanjeev/openFiler","port":0}},"name":"ROOT-8","size":

[jira] [Created] (CLOUDSTACK-4171) Xen/XCP snapshot uploading to S3 server should use multipart upload API.

[Thomas O'Dowd (JIRA)]

Thomas O'Dowd created CLOUDSTACK-4171:
-

 Summary: Xen/XCP snapshot uploading to S3 server should use 
multipart upload API.
 Key: CLOUDSTACK-4171
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4171
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.2.0
Reporter: Thomas O'Dowd


Currently when a snapshot is being uploaded to S3, it uses a single S3 PUT 
request. Snapshots can be large and Amazon recommends using the multipart 
upload API once the payload reaches 100MB [1] although it's possible to use the 
single object PUT api up until 5GB.

>From the SMlog we can see the single PUT being used:
[16279] 2013-08-02 08:48:54.730958  VMOPS Sent PUT request to 
s3.cloudian.com:18080/images/snapshots/5a28d935-47da-4813-a692-db92761ce7de 
with headers {'Content-Length': '50430464', 'Content-MD5': 
'oafg2xPUPPAnyE1sxmf+qA==', 'Expect': '100-continue', 'Date': 'Fri, 02 Aug 2013 
08:48:52 +', 'Content-Type': 'application/octet-stream', 'Authorization': 
'AWS 00ba9a7f9a8142b070c3:fy03ARq2UQWKW2UndUSYJ/E+QfI='}. Received response 
status 200: OK 

[1] http://docs.aws.amazon.com/AmazonS3/latest/dev/UploadingObjects.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (CLOUDSTACK-4109) [Object_store_refactor] Extract volume failed with NPE

[edison su (JIRA)]

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

edison su resolved CLOUDSTACK-4109.
---

Resolution: Fixed

> [Object_store_refactor] Extract volume failed with NPE
> --
>
> Key: CLOUDSTACK-4109
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4109
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller, VMware, Volumes
>Affects Versions: 4.2.0
> Environment: Latest build from ACS 4.2 branch.
> Storage: S3 for secondary, NFS for staging and ISCSI for primary storage
>Reporter: Sanjeev N
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: cloud.dmp, management-server.rar
>
>
> Extract volume failed with NPE
> Steps to Reproduce:
> 
> 1.Bring up CS with VMWare cluster using S3 for secondary ,NFS for staging and 
> ISCSI for primary storage.
> 2.Deploy guest vm with root disk
> 3.Create a custom data disk and attach to the vm
> 4.Dettach the data disk and try to extract the volume
> Result:
> ==
> Download volume failed with NPE but still UI prompted with URL to download 
> the volume even-though volume was not copied to S3 storage.
> Log snippet as follows:
> 2013-08-06 07:32:46,296 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (catalina-exec-10:null) submit async job-25 = [ 
> 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ], details: AsyncJobVO {id:25, userId: 
> 2, accountId: 2, sessionKey: null, instanceType: Volume, instanceId: 11, cmd: 
> org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd, 
> cmdOriginator: null, cmdInfo: 
> {"response":"json","id":"003c0b9c-176f-463e-aac7-fdefde807c86","sessionkey":"foQa9K4dPmYo8uEiAcolaTVR6yI\u003d","cmdEventType":"VOLUME.EXTRACT","ctxUserId":"2","zoneid":"a7c59acd-1b2f-4f06-b50b-bd79e113c692","httpmethod":"GET","_":"1375788754095","ctxAccountId":"2","ctxStartEventId":"95","mode":"HTTP_DOWNLOAD"},
>  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
> processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382, 
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-06 07:32:46,298 DEBUG [cloud.api.ApiServlet] (catalina-exec-10:null) 
> ===END===  10.146.0.20 -- GET  
> command=extractVolume&id=003c0b9c-176f-463e-aac7-fdefde807c86&zoneid=a7c59acd-1b2f-4f06-b50b-bd79e113c692&mode=HTTP_DOWNLOAD&response=json&sessionkey=foQa9K4dPmYo8uEiAcolaTVR6yI%3D&_=1375788754095
> 2013-08-06 07:32:46,302 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-26:job-25 = [ 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]) Executing 
> org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd for job-25 = [ 
> 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]
> 2013-08-06 07:32:46,395 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-26:job-25 = [ 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]) copyAsync 
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-06 07:32:46,406 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-26:job-25 = [ 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]) 
> needCacheStorage true, dest at volumes/2/11 dest role 
> Image7a16cf210c6c4af3b39a04c94dca7035 src role Primary
> 2013-08-06 07:32:46,430 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-26:job-25 = [ 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]) copyAsync 
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-06 07:32:46,462 DEBUG [agent.transport.Request] 
> (Job-Executor-26:job-25 = [ 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]) Seq 
> 3-1317535767: Sending  { Cmd , MgmtId: 6615759585382, via: 3, Ver: v1, Flags: 
> 100011, 
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"003c0b9c-176f-463e-aac7-fdefde807c86","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"b845e7d4-562a-3b2d-8e59-b1df565f99e5","id":1,"poolType":"VMFS","host":"VMFS
>  datastore: 
> /sanjeev/openFiler","path":"/sanjeev/openFiler","port":0}},"name":"v1","size":5120,"path":"7a16cf210c6c4af3b39a04c94dca7035","volumeId":11,"accountId":2,"format":"OVA","id":11,"hypervisorType":"VMware"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"003c0b9c-176f-463e-aac7-fdefde807c86","volumeType":"DATADISK","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.147.28.7/export/home/sanjeev/sec_esx_os","_role":"ImageCache"}},"name":"v1","size":5120,"path":"volumes/2/11","volumeId":11,"accountId":2,"format":"OVA","id":11,"hypervisorType":"VMware"}},"executeInSequence":false,"wait":10800}}]
>  }
> 2013-08-06 07:33:13,383 DEBUG [agent.transport.

[jira] [Commented] (CLOUDSTACK-4109) [Object_store_refactor] Extract volume failed with NPE

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-4109:
-

Commit 26a5b76ee6b77909a7b8d5b00924f12e1671373d in branch refs/heads/4.2 from 
[~edison]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=26a5b76 ]

CLOUDSTACK-4109: fix upload volume to s3 for vmware


> [Object_store_refactor] Extract volume failed with NPE
> --
>
> Key: CLOUDSTACK-4109
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4109
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller, VMware, Volumes
>Affects Versions: 4.2.0
> Environment: Latest build from ACS 4.2 branch.
> Storage: S3 for secondary, NFS for staging and ISCSI for primary storage
>Reporter: Sanjeev N
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: cloud.dmp, management-server.rar
>
>
> Extract volume failed with NPE
> Steps to Reproduce:
> 
> 1.Bring up CS with VMWare cluster using S3 for secondary ,NFS for staging and 
> ISCSI for primary storage.
> 2.Deploy guest vm with root disk
> 3.Create a custom data disk and attach to the vm
> 4.Dettach the data disk and try to extract the volume
> Result:
> ==
> Download volume failed with NPE but still UI prompted with URL to download 
> the volume even-though volume was not copied to S3 storage.
> Log snippet as follows:
> 2013-08-06 07:32:46,296 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (catalina-exec-10:null) submit async job-25 = [ 
> 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ], details: AsyncJobVO {id:25, userId: 
> 2, accountId: 2, sessionKey: null, instanceType: Volume, instanceId: 11, cmd: 
> org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd, 
> cmdOriginator: null, cmdInfo: 
> {"response":"json","id":"003c0b9c-176f-463e-aac7-fdefde807c86","sessionkey":"foQa9K4dPmYo8uEiAcolaTVR6yI\u003d","cmdEventType":"VOLUME.EXTRACT","ctxUserId":"2","zoneid":"a7c59acd-1b2f-4f06-b50b-bd79e113c692","httpmethod":"GET","_":"1375788754095","ctxAccountId":"2","ctxStartEventId":"95","mode":"HTTP_DOWNLOAD"},
>  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
> processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382, 
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-06 07:32:46,298 DEBUG [cloud.api.ApiServlet] (catalina-exec-10:null) 
> ===END===  10.146.0.20 -- GET  
> command=extractVolume&id=003c0b9c-176f-463e-aac7-fdefde807c86&zoneid=a7c59acd-1b2f-4f06-b50b-bd79e113c692&mode=HTTP_DOWNLOAD&response=json&sessionkey=foQa9K4dPmYo8uEiAcolaTVR6yI%3D&_=1375788754095
> 2013-08-06 07:32:46,302 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-26:job-25 = [ 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]) Executing 
> org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd for job-25 = [ 
> 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]
> 2013-08-06 07:32:46,395 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-26:job-25 = [ 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]) copyAsync 
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-06 07:32:46,406 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-26:job-25 = [ 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]) 
> needCacheStorage true, dest at volumes/2/11 dest role 
> Image7a16cf210c6c4af3b39a04c94dca7035 src role Primary
> 2013-08-06 07:32:46,430 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-26:job-25 = [ 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]) copyAsync 
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-06 07:32:46,462 DEBUG [agent.transport.Request] 
> (Job-Executor-26:job-25 = [ 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]) Seq 
> 3-1317535767: Sending  { Cmd , MgmtId: 6615759585382, via: 3, Ver: v1, Flags: 
> 100011, 
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"003c0b9c-176f-463e-aac7-fdefde807c86","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"b845e7d4-562a-3b2d-8e59-b1df565f99e5","id":1,"poolType":"VMFS","host":"VMFS
>  datastore: 
> /sanjeev/openFiler","path":"/sanjeev/openFiler","port":0}},"name":"v1","size":5120,"path":"7a16cf210c6c4af3b39a04c94dca7035","volumeId":11,"accountId":2,"format":"OVA","id":11,"hypervisorType":"VMware"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"003c0b9c-176f-463e-aac7-fdefde807c86","volumeType":"DATADISK","dataStore":{"com.cloud.agent.api.to.NfsTO":

[jira] [Comment Edited] (CLOUDSTACK-4109) [Object_store_refactor] Extract volume failed with NPE

[Min Chen (JIRA)]

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

Min Chen edited comment on CLOUDSTACK-4109 at 8/8/13 1:16 AM:
--

The Copy failure is due to null volume.size in returned CopyCmdAnswer, so an 
exception is thrown in processing that CopyCmdAnswer. Commit 
6ebfa923ff9a76b90b3d03634bfefa22d8841ccc is to fix the issue that control is 
still going on to generate url even if copyCommand failed.

  was (Author: minchen07):
The Copy failure should have been fixed by commit 
0243f043cb4814b0c8dbb13f44c34436db50de87 due to null volume.size in returned 
CopyCmdAnswer, so an exception is thrown in processing that CopyCmdAnswer. 
Commit 6ebfa923ff9a76b90b3d03634bfefa22d8841ccc is to fix the issue that 
control is still going on to generate url even if copyCommand failed.
  
> [Object_store_refactor] Extract volume failed with NPE
> --
>
> Key: CLOUDSTACK-4109
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4109
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller, VMware, Volumes
>Affects Versions: 4.2.0
> Environment: Latest build from ACS 4.2 branch.
> Storage: S3 for secondary, NFS for staging and ISCSI for primary storage
>Reporter: Sanjeev N
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: cloud.dmp, management-server.rar
>
>
> Extract volume failed with NPE
> Steps to Reproduce:
> 
> 1.Bring up CS with VMWare cluster using S3 for secondary ,NFS for staging and 
> ISCSI for primary storage.
> 2.Deploy guest vm with root disk
> 3.Create a custom data disk and attach to the vm
> 4.Dettach the data disk and try to extract the volume
> Result:
> ==
> Download volume failed with NPE but still UI prompted with URL to download 
> the volume even-though volume was not copied to S3 storage.
> Log snippet as follows:
> 2013-08-06 07:32:46,296 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (catalina-exec-10:null) submit async job-25 = [ 
> 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ], details: AsyncJobVO {id:25, userId: 
> 2, accountId: 2, sessionKey: null, instanceType: Volume, instanceId: 11, cmd: 
> org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd, 
> cmdOriginator: null, cmdInfo: 
> {"response":"json","id":"003c0b9c-176f-463e-aac7-fdefde807c86","sessionkey":"foQa9K4dPmYo8uEiAcolaTVR6yI\u003d","cmdEventType":"VOLUME.EXTRACT","ctxUserId":"2","zoneid":"a7c59acd-1b2f-4f06-b50b-bd79e113c692","httpmethod":"GET","_":"1375788754095","ctxAccountId":"2","ctxStartEventId":"95","mode":"HTTP_DOWNLOAD"},
>  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
> processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382, 
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-06 07:32:46,298 DEBUG [cloud.api.ApiServlet] (catalina-exec-10:null) 
> ===END===  10.146.0.20 -- GET  
> command=extractVolume&id=003c0b9c-176f-463e-aac7-fdefde807c86&zoneid=a7c59acd-1b2f-4f06-b50b-bd79e113c692&mode=HTTP_DOWNLOAD&response=json&sessionkey=foQa9K4dPmYo8uEiAcolaTVR6yI%3D&_=1375788754095
> 2013-08-06 07:32:46,302 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-26:job-25 = [ 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]) Executing 
> org.apache.cloudstack.api.command.user.volume.ExtractVolumeCmd for job-25 = [ 
> 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]
> 2013-08-06 07:32:46,395 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-26:job-25 = [ 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]) copyAsync 
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-06 07:32:46,406 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-26:job-25 = [ 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]) 
> needCacheStorage true, dest at volumes/2/11 dest role 
> Image7a16cf210c6c4af3b39a04c94dca7035 src role Primary
> 2013-08-06 07:32:46,430 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-26:job-25 = [ 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]) copyAsync 
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-06 07:32:46,462 DEBUG [agent.transport.Request] 
> (Job-Executor-26:job-25 = [ 448d8e6e-e4fe-46a5-b6f6-e839ff720052 ]) Seq 
> 3-1317535767: Sending  { Cmd , MgmtId: 6615759585382, via: 3, Ver: v1, Flags: 
> 100011, 
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"003c0b9c-176f-463e-aac7-fdefde807c86","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"b845e

[jira] [Resolved] (CLOUDSTACK-4135) [Object_store_refactor] ISO attached to the guest vm has wrong mount path

[Min Chen (JIRA)]

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

Min Chen resolved CLOUDSTACK-4135.
--

Resolution: Fixed

> [Object_store_refactor] ISO attached to the guest vm has wrong mount path
> -
>
> Key: CLOUDSTACK-4135
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4135
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: ISO, Storage Controller, VMware
>Affects Versions: 4.2.0
> Environment: Latest build from ACS 4.2 branch
> Storage: S3 for secondary, NFS for staging and ISCSI for primary storage
> Cluster : VMWare
>Reporter: Sanjeev N
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: cloud.dmp, management-server.rar
>
>
> ISO attached to the guest vm has wrong mount path.
> Steps to Reproduce:
> =
> 1.Bring up CS with vmware cluster using S3 for secondary, NFS for staging 
> secondary and ISCSI for primary storage
> 2.Deploy guest vm with default cent os tempalate
> 3.Register ISO to CS
> 4.Attach registered iso to the guest vm 
> Observations:
> ==
> Attaching iso to the guest vm is succeeded. However vm properties in vSphere 
> shows the wrong path for the attached iso.
> ISO will be copied from s3 to staging storage as part of ISO attachment.
> ISO location after copying the iso to staging secondary storage is as follows:
> "template/tmpl/2/211/c7c57ca9-3f53-44f5-8fdb-03c217e29d85.iso"
> But on vSphere vm properties shows the Datastore ISO file as 
> "template/tmpl/2/211c7c57ca9-3f53-44f5-8fdb-03c217e29d85.iso"
> one / is missing after 211. Due to this mounting iso fails with error 
> "unknown device"
> Tried this on multiple vms and behavior is same.
> Log snippet during iso attach :
> 2013-08-07 05:06:58,351 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (catalina-exec-25:null) submit async job-49 = [ 
> 6ad4c868-37cd-4d9b-b890-beafebb1de1d ], details: AsyncJobVO {id:49, userId: 
> 2, accountId: 2, sessionKey: null, instanceType: None, instanceId: null, cmd: 
> org.apache.cloudstack.api.command.user.iso.AttachIsoCmd, cmdOriginator: null, 
> cmdInfo: 
> {"response":"json","id":"65ba08b1-c1b2-40c6-b6e1-d8831c0195a7","sessionkey":"0MiEyYRhbpp7aGMi7ELrm2BdFS0\u003d","virtualmachineid":"0afcdecd-9515-4780-a097-24c9e5c107cd","cmdEventType":"ISO.ATTACH","ctxUserId":"2","httpmethod":"GET","_":"1375866404093","ctxAccountId":"2","ctxStartEventId":"191"},
>  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
> processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382, 
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-07 05:06:58,354 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null) 
> ===END===  10.146.0.20 -- GET  
> command=attachIso&virtualmachineid=0afcdecd-9515-4780-a097-24c9e5c107cd&id=65ba08b1-c1b2-40c6-b6e1-d8831c0195a7&response=json&sessionkey=0MiEyYRhbpp7aGMi7ELrm2BdFS0%3D&_=1375866404093
> 2013-08-07 05:06:58,357 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-50:job-49 = [ 6ad4c868-37cd-4d9b-b890-beafebb1de1d ]) Executing 
> org.apache.cloudstack.api.command.user.iso.AttachIsoCmd for job-49 = [ 
> 6ad4c868-37cd-4d9b-b890-beafebb1de1d ]
> 2013-08-07 05:06:58,402 DEBUG [storage.image.TemplateDataFactoryImpl] 
> (Job-Executor-50:job-49 = [ 6ad4c868-37cd-4d9b-b890-beafebb1de1d ]) template 
> 211 is already in store:10, type:Image
> 2013-08-07 05:06:58,420 DEBUG [storage.image.TemplateDataFactoryImpl] 
> (Job-Executor-50:job-49 = [ 6ad4c868-37cd-4d9b-b890-beafebb1de1d ]) template 
> 211 is already in store:8, type:ImageCache
> 2013-08-07 05:06:58,427 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-50:job-49 = [ 6ad4c868-37cd-4d9b-b890-beafebb1de1d ]) copyAsync 
> inspecting src type TEMPLATE copyAsync inspecting dest type TEMPLATE
> 2013-08-07 05:06:58,450 DEBUG [agent.transport.Request] 
> (Job-Executor-50:job-49 = [ 6ad4c868-37cd-4d9b-b890-beafebb1de1d ]) Seq 
> 3-1317535888: Sending  { Cmd , MgmtId: 6615759585382, via: 3, Ver: v1, Flags: 
> 100011, 
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/2/211/211-2-6da4c152-1118-3581-9af3-106339e1fcb8/dummy.iso","origUrl":"http://10.147.28.7/templates/vmware/dummy.iso","uuid":"65ba08b1-c1b2-40c6-b6e1-d8831c0195a7","id":211,"format":"ISO","accountId":2,"hvm":true,"displayText":"dummy","imageDataStore":{"com.cloud.agent.api.to.S3TO":{"id":10,"uuid":"fbb4a8d4-034a-4dd4-89ca-65769bd084ce","endPoint":"10.147.29.56:8080","bucketName":"imagestore","httpsFlag":false,"created":"Aug
>  6, 2013 9:30:25 
> AM","enableRRS":false}},"name

[jira] [Commented] (CLOUDSTACK-4135) [Object_store_refactor] ISO attached to the guest vm has wrong mount path

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-4135:
-

Commit 82c35e52ea8c10252067a6edc7b97408d9266dda in branch refs/heads/master 
from [~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=82c35e5 ]

CLOUDSTACK-4135:  [Object_store_refactor] ISO attached to the guest vm
has wrong mount path.


> [Object_store_refactor] ISO attached to the guest vm has wrong mount path
> -
>
> Key: CLOUDSTACK-4135
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4135
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: ISO, Storage Controller, VMware
>Affects Versions: 4.2.0
> Environment: Latest build from ACS 4.2 branch
> Storage: S3 for secondary, NFS for staging and ISCSI for primary storage
> Cluster : VMWare
>Reporter: Sanjeev N
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: cloud.dmp, management-server.rar
>
>
> ISO attached to the guest vm has wrong mount path.
> Steps to Reproduce:
> =
> 1.Bring up CS with vmware cluster using S3 for secondary, NFS for staging 
> secondary and ISCSI for primary storage
> 2.Deploy guest vm with default cent os tempalate
> 3.Register ISO to CS
> 4.Attach registered iso to the guest vm 
> Observations:
> ==
> Attaching iso to the guest vm is succeeded. However vm properties in vSphere 
> shows the wrong path for the attached iso.
> ISO will be copied from s3 to staging storage as part of ISO attachment.
> ISO location after copying the iso to staging secondary storage is as follows:
> "template/tmpl/2/211/c7c57ca9-3f53-44f5-8fdb-03c217e29d85.iso"
> But on vSphere vm properties shows the Datastore ISO file as 
> "template/tmpl/2/211c7c57ca9-3f53-44f5-8fdb-03c217e29d85.iso"
> one / is missing after 211. Due to this mounting iso fails with error 
> "unknown device"
> Tried this on multiple vms and behavior is same.
> Log snippet during iso attach :
> 2013-08-07 05:06:58,351 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (catalina-exec-25:null) submit async job-49 = [ 
> 6ad4c868-37cd-4d9b-b890-beafebb1de1d ], details: AsyncJobVO {id:49, userId: 
> 2, accountId: 2, sessionKey: null, instanceType: None, instanceId: null, cmd: 
> org.apache.cloudstack.api.command.user.iso.AttachIsoCmd, cmdOriginator: null, 
> cmdInfo: 
> {"response":"json","id":"65ba08b1-c1b2-40c6-b6e1-d8831c0195a7","sessionkey":"0MiEyYRhbpp7aGMi7ELrm2BdFS0\u003d","virtualmachineid":"0afcdecd-9515-4780-a097-24c9e5c107cd","cmdEventType":"ISO.ATTACH","ctxUserId":"2","httpmethod":"GET","_":"1375866404093","ctxAccountId":"2","ctxStartEventId":"191"},
>  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
> processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382, 
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-07 05:06:58,354 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null) 
> ===END===  10.146.0.20 -- GET  
> command=attachIso&virtualmachineid=0afcdecd-9515-4780-a097-24c9e5c107cd&id=65ba08b1-c1b2-40c6-b6e1-d8831c0195a7&response=json&sessionkey=0MiEyYRhbpp7aGMi7ELrm2BdFS0%3D&_=1375866404093
> 2013-08-07 05:06:58,357 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-50:job-49 = [ 6ad4c868-37cd-4d9b-b890-beafebb1de1d ]) Executing 
> org.apache.cloudstack.api.command.user.iso.AttachIsoCmd for job-49 = [ 
> 6ad4c868-37cd-4d9b-b890-beafebb1de1d ]
> 2013-08-07 05:06:58,402 DEBUG [storage.image.TemplateDataFactoryImpl] 
> (Job-Executor-50:job-49 = [ 6ad4c868-37cd-4d9b-b890-beafebb1de1d ]) template 
> 211 is already in store:10, type:Image
> 2013-08-07 05:06:58,420 DEBUG [storage.image.TemplateDataFactoryImpl] 
> (Job-Executor-50:job-49 = [ 6ad4c868-37cd-4d9b-b890-beafebb1de1d ]) template 
> 211 is already in store:8, type:ImageCache
> 2013-08-07 05:06:58,427 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-50:job-49 = [ 6ad4c868-37cd-4d9b-b890-beafebb1de1d ]) copyAsync 
> inspecting src type TEMPLATE copyAsync inspecting dest type TEMPLATE
> 2013-08-07 05:06:58,450 DEBUG [agent.transport.Request] 
> (Job-Executor-50:job-49 = [ 6ad4c868-37cd-4d9b-b890-beafebb1de1d ]) Seq 
> 3-1317535888: Sending  { Cmd , MgmtId: 6615759585382, via: 3, Ver: v1, Flags: 
> 100011, 
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/2/211/211-2-6da4c152-1118-3581-9af3-106339e1fcb8/dummy.iso","origUrl":"http://10.147.28.7/templates/vmware/dummy.iso","uuid":"6

[jira] [Resolved] (CLOUDSTACK-3869) Current VMware datastore layout structure breaks storage live motion

[Kelven Yang (JIRA)]

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

Kelven Yang resolved CLOUDSTACK-3869.
-

Resolution: Fixed

> Current VMware datastore layout structure breaks storage live motion
> 
>
> Key: CLOUDSTACK-3869
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3869
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.2.0
>Reporter: Kelven Yang
>Assignee: Kelven Yang
>Priority: Critical
> Fix For: 4.2.0
>
>
> Current VMware datastore layout structure has conflicts with VMware storage 
> live motion, it does not work with third-party backup tools for vCenter as 
> well. We need to fix the datastore layout structure to better integrate 
> CloudStack with VMware vCenter

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-3869) Current VMware datastore layout structure breaks storage live motion

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-3869:
-

Commit ec5f2c15129fbb7c34dc67b4d9352385d581f884 in branch refs/heads/4.2 from 
[~kelveny]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ec5f2c1 ]

CLOUDSTACK-3869: fix merge conflicts


> Current VMware datastore layout structure breaks storage live motion
> 
>
> Key: CLOUDSTACK-3869
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3869
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.2.0
>Reporter: Kelven Yang
>Assignee: Kelven Yang
>Priority: Critical
> Fix For: 4.2.0
>
>
> Current VMware datastore layout structure has conflicts with VMware storage 
> live motion, it does not work with third-party backup tools for vCenter as 
> well. We need to fix the datastore layout structure to better integrate 
> CloudStack with VMware vCenter

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-3869) Current VMware datastore layout structure breaks storage live motion

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-3869:
-

Commit 6951e77ed9f16249b0becc3c3a726da2c28cf256 in branch refs/heads/4.2 from 
[~kelveny]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6951e77 ]

CLOUDSTACK-3869: make new folder structure to work with Snapshop commands


> Current VMware datastore layout structure breaks storage live motion
> 
>
> Key: CLOUDSTACK-3869
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3869
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.2.0
>Reporter: Kelven Yang
>Assignee: Kelven Yang
>Priority: Critical
> Fix For: 4.2.0
>
>
> Current VMware datastore layout structure has conflicts with VMware storage 
> live motion, it does not work with third-party backup tools for vCenter as 
> well. We need to fix the datastore layout structure to better integrate 
> CloudStack with VMware vCenter

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-3869) Current VMware datastore layout structure breaks storage live motion

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-3869:
-

Commit faf96409839465c30bd2abfbd56a817bc7a38166 in branch refs/heads/4.2 from 
[~kelveny]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=faf9640 ]

CLOUDSTACK-3869: change default snapshot directory to VM folder


> Current VMware datastore layout structure breaks storage live motion
> 
>
> Key: CLOUDSTACK-3869
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3869
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.2.0
>Reporter: Kelven Yang
>Assignee: Kelven Yang
>Priority: Critical
> Fix For: 4.2.0
>
>
> Current VMware datastore layout structure has conflicts with VMware storage 
> live motion, it does not work with third-party backup tools for vCenter as 
> well. We need to fix the datastore layout structure to better integrate 
> CloudStack with VMware vCenter

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira