date:20140107


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864011#comment-13864011
 ] 

Sanjay Tripathi commented on CLOUDSTACK-5406:
-

Hi Sangeetha,

WorkFlow of createSnapshot and Resource Limits (snapshots):

1) User triggers createSnapshot command.
2) CS checks the resourceLimits with virtualSize of snapshot.
3) CS updates the secondary_storage resourceType in resouce_count table with 
virtual size.
4) Hypervisor takes the snapshots and CS copies it to secondary storage and 
update the snapshot_store_ref table with actual size of snapshot.
5) Once snapshot is in place (in secondary storage), CS corrects the resource 
count for secondary storage with actual size of snapshot.

If user triggers multiple snapshots and previous snapshots are still not done 
then for that time CS treats the snapshot size as virtual size of snapshot and 
not the actual size; And if limits are not permitting, then user will receive 
resourceLimit error.

Can you check the secondary storage count in resource_count table once snapshot 
is done; it should be updated with actual size of snapshot.

 Not able to take snapshot becasue of secondary_storage limit of 400 gb 
 exceeded even though we have not really consumed this limit in secondary 
 store.
 --

 Key: CLOUDSTACK-5406
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5406
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
 Environment: Build from 4.3
Reporter: Sangeetha Hariharan
Assignee: Sanjay Tripathi
Priority: Critical
 Fix For: 4.3.0

 Attachments: management-server.rar, storage.rar


 Set up: 
 Xenserver setup with 2 NFS secondary stores.
 1 account having 21 Vms.
 I am using the the default secondary_storage limit which is 400 gb.
  
 Started hourly snapshot policy for all the ROOT volumes of the Vms which was 
 created from a template of size 20 gb. The actual used up size is 12 GB. 
 When  snapshot gets created , the full snapshot size is ~6.7 GB. 
  After only  2  snapshots of ROOT volume , I hit the following excepton:
  
 “2013-12-06 00:00:48,298 WARN  [c.c.s.s.SnapshotSchedulerImpl] 
 (SnapshotPollTask:ctx-a7ccb50a) Scheduling snapshot failed due to 
 com.cloud.exception.ResourceAllocationException: Maximum number of resources 
 of type 'secondary_storage' for account 
 name=test-TestParallelVolumeSnasohots-273V8U in domain id=1 has been 
 exceeded.”
  
 How are we calculating this limit ? Do we query the actual secondary store / 
 do we calculate based on the ROOT volume size and # of Snapshots.
  
 In case of Xenserve , we have Delta snapshots.We should not be 
  
 mysql select count(*) from snapshots where account_id=8 group by volume_id;
 +--+
 | count(*) |
 +--+
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |3 |
 |3 |
 +--+
 21 rows in set (0.00 sec)
  
  
 [root@Rack3Host5 secondary]# du -h --max-depth=1
 28G ./snapshots
 13G ./template
 4.0K./volumes
 41G .
  
  
 [root@Rack3Host8 secondary]# du -h --max-depth=1
 12G ./template
 29G ./snapshots
 4.0K./volumes
 41G .
 [root@Rack3Host8 secondary]#
 mysql select * from resource_limit;
 ++---++---+---+
 | id | domain_id | account_id | type  | max   |
 ++---++---+---+
 | 31 |  NULL |  8 | user_vm   |   200 |
 | 32 |  NULL |  8 | public_ip |   200 |
 | 33 |  NULL |  8 | volume|   200 |
 | 34 |  NULL |  8 | snapshot  |   200 |
 | 35 |  NULL |  8 | template  |   200 |
 | 36 |  NULL |  8 | vpc   |   200 |
 | 37 |  NULL |  8 | cpu   |40 |
 | 38 |  NULL |  8 | memory| 40960 |
 | 39 |  NULL |  8 | network   |20 |
 | 40 |  NULL |  8 | primary_storage   |  214748364800 |
 | 41 |  NULL |  8 | secondary_storage | 4294967296000 |
 ++---++---+---+
 11 rows in set (0.00 sec)



--
This message was sent by Atlassian JIRA

[jira] [Resolved] (CLOUDSTACK-5406) Not able to take snapshot becasue of secondary_storage limit of 400 gb exceeded even though we have not really consumed this limit in secondary store.

2014-01-07 Thread ASF subversion and git services (JIRA)


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

Sanjay Tripathi resolved CLOUDSTACK-5406.
-

Resolution: Fixed

 Not able to take snapshot becasue of secondary_storage limit of 400 gb 
 exceeded even though we have not really consumed this limit in secondary 
 store.
 --

 Key: CLOUDSTACK-5406
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5406
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
 Environment: Build from 4.3
Reporter: Sangeetha Hariharan
Assignee: Sanjay Tripathi
Priority: Critical
 Fix For: 4.3.0

 Attachments: management-server.rar, storage.rar


 Set up: 
 Xenserver setup with 2 NFS secondary stores.
 1 account having 21 Vms.
 I am using the the default secondary_storage limit which is 400 gb.
  
 Started hourly snapshot policy for all the ROOT volumes of the Vms which was 
 created from a template of size 20 gb. The actual used up size is 12 GB. 
 When  snapshot gets created , the full snapshot size is ~6.7 GB. 
  After only  2  snapshots of ROOT volume , I hit the following excepton:
  
 “2013-12-06 00:00:48,298 WARN  [c.c.s.s.SnapshotSchedulerImpl] 
 (SnapshotPollTask:ctx-a7ccb50a) Scheduling snapshot failed due to 
 com.cloud.exception.ResourceAllocationException: Maximum number of resources 
 of type 'secondary_storage' for account 
 name=test-TestParallelVolumeSnasohots-273V8U in domain id=1 has been 
 exceeded.”
  
 How are we calculating this limit ? Do we query the actual secondary store / 
 do we calculate based on the ROOT volume size and # of Snapshots.
  
 In case of Xenserve , we have Delta snapshots.We should not be 
  
 mysql select count(*) from snapshots where account_id=8 group by volume_id;
 +--+
 | count(*) |
 +--+
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |3 |
 |3 |
 +--+
 21 rows in set (0.00 sec)
  
  
 [root@Rack3Host5 secondary]# du -h --max-depth=1
 28G ./snapshots
 13G ./template
 4.0K./volumes
 41G .
  
  
 [root@Rack3Host8 secondary]# du -h --max-depth=1
 12G ./template
 29G ./snapshots
 4.0K./volumes
 41G .
 [root@Rack3Host8 secondary]#
 mysql select * from resource_limit;
 ++---++---+---+
 | id | domain_id | account_id | type  | max   |
 ++---++---+---+
 | 31 |  NULL |  8 | user_vm   |   200 |
 | 32 |  NULL |  8 | public_ip |   200 |
 | 33 |  NULL |  8 | volume|   200 |
 | 34 |  NULL |  8 | snapshot  |   200 |
 | 35 |  NULL |  8 | template  |   200 |
 | 36 |  NULL |  8 | vpc   |   200 |
 | 37 |  NULL |  8 | cpu   |40 |
 | 38 |  NULL |  8 | memory| 40960 |
 | 39 |  NULL |  8 | network   |20 |
 | 40 |  NULL |  8 | primary_storage   |  214748364800 |
 | 41 |  NULL |  8 | secondary_storage | 4294967296000 |
 ++---++---+---+
 11 rows in set (0.00 sec)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CLOUDSTACK-5657) [Hyper-v] vm live migration does not work if the Cloudstack Hyper-v Agen runs with Local System Log On

2014-01-07 Thread Devdeep Singh (JIRA)


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

Devdeep Singh updated CLOUDSTACK-5657:
--

Component/s: (was: Doc)

 [Hyper-v] vm live migration does not work if the Cloudstack Hyper-v Agen runs 
 with Local System Log On
 -

 Key: CLOUDSTACK-5657
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5657
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller
Affects Versions: 4.3.0
 Environment: latest build from 4.3
 Hypervisor: Hyperv
 Storage: SMB for both primary and secondary
Reporter: Sanjeev N
Assignee: Devdeep Singh
Priority: Critical
  Labels: hyper-V,, hyper-v, hyperv
 Fix For: 4.3.0


 [Hyper-v] vm live migration does not work if the Cloudstack Hyper-v Agen runs 
 with Local System Log On
 CloudStack to communicate with Hyper-v server we run CloudStack-Hyperv Agent 
 as a service in Windows2012R2 (Hyperv) Server. By default this service would 
 run with Local System Log On. However vm live migration fails with 
 authentication issues if this service runs with Local System Log on. So we 
 need to stop this service and change the Log On account to domain user and 
 start the service for the live migration to work.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Assigned] (CLOUDSTACK-5794) [Hyper-v] Specify username and domain name together in the username field while adding host in Hyper-v cluster

2014-01-07 Thread Radhika Nair (JIRA)


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

Radhika Nair reassigned CLOUDSTACK-5794:


Assignee: Radhika Nair  (was: Devdeep Singh)

 [Hyper-v] Specify username and domain name together in the username field 
 while adding host in Hyper-v cluster
 --

 Key: CLOUDSTACK-5794
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5794
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc, Hypervisor Controller
Affects Versions: 4.3.0
 Environment: Hyper-v cluster
Reporter: Sanjeev N
Assignee: Radhika Nair
  Labels: hyper-V,, hyper-v, hyperv
 Fix For: 4.3.0

 Attachments: hyprv-host.PNG


 In Hyper-v all the hosts are domain joined hosts. So while adding a host in 
 hyper-v cluster Admin should pass the domain name and username using username 
 parameter itself. 
 Pass the username parameter as below:
 username=BLR\sanjeev



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5314) Negative (-ve) values for primary storage and volumes are shown in the resource count table


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864023#comment-13864023
 ] 

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

Commit 0706757e000c3551e5106f41037f81f7bd23d4bb in branch refs/heads/4.3 from 
[~sanjay.tripathi]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0706757 ]

CLOUDSTACK-5314: Negative (-ve) values for primary storage and volumes are 
shown in the resource count table.


 Negative (-ve) values for primary storage and volumes are shown in the 
 resource count table
 ---

 Key: CLOUDSTACK-5314
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5314
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup, Management Server
Affects Versions: 4.3.0
 Environment: Hyper-V
Reporter: Abhinav Roy
Assignee: Sanjay Tripathi
Priority: Critical
 Fix For: 4.3.0


 Description :
 
 The resource count value for primary storage and volumes in the 
 cloud.resource_count table is shown as negative (-ve)
 mysql select * from resource_count;
 +++---+---+---+
 | id | account_id | domain_id | type  | count |
 +++---+---+---+
 |  1 |   NULL | 1 | cpu   | 6 |
 |  2 |   NULL | 1 | memory|  3072 |
 |  3 |   NULL | 1 | primary_storage   | -103079215104 |
 |  4 |   NULL | 1 | secondary_storage |   56863775232 |
 |  9 |   NULL | 1 | user_vm   | 6 |
 | 10 |   NULL | 1 | public_ip | 2 |
 | 11 |   NULL | 1 | volume|-5 |
 | 12 |   NULL | 1 | snapshot  | 0 |
 | 13 |   NULL | 1 | template  | 4 |
 | 14 |   NULL | 1 | project   | 0 |
 | 15 |   NULL | 1 | network   | 1 |
 | 16 |   NULL | 1 | vpc   | 0 |
 | 17 |  1 |  NULL | user_vm   | 0 |
 | 18 |  1 |  NULL | public_ip | 0 |
 | 19 |  1 |  NULL | volume| 0 |
 | 20 |  1 |  NULL | snapshot  | 0 |
 | 21 |  1 |  NULL | template  | 0 |
 | 22 |  1 |  NULL | project   | 0 |
 | 23 |  1 |  NULL | network   | 0 |
 | 24 |  1 |  NULL | vpc   | 0 |
 | 25 |  1 |  NULL | cpu   | 0 |
 | 26 |  1 |  NULL | memory| 0 |
 | 27 |  1 |  NULL | primary_storage   | 0 |
 | 28 |  1 |  NULL | secondary_storage | 0 |
 | 29 |  2 |  NULL | user_vm   | 6 |
 | 30 |  2 |  NULL | public_ip | 2 |
 | 31 |  2 |  NULL | volume|-5 |
 | 32 |  2 |  NULL | snapshot  | 0 |
 | 33 |  2 |  NULL | template  | 4 |
 | 34 |  2 |  NULL | project   | 0 |
 | 35 |  2 |  NULL | network   | 1 |
 | 36 |  2 |  NULL | vpc   | 0 |
 | 37 |  2 |  NULL | cpu   | 6 |
 | 38 |  2 |  NULL | memory|  3072 |
 | 39 |  2 |  NULL | primary_storage   | -103079215104 |
 | 40 |  2 |  NULL | secondary_storage |  163220937216 |
 +++---+---+---+
 36 rows in set (0.00 sec)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5002) unable to destroy vm ;VM destroy failed in Stop i-2-59-VM Command due to You gave an invalid object reference. The object may have recently been deleted.

2014-01-07 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864024#comment-13864024
 ] 

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

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

CLOUDSTACK-5002: unable to destroy vm ;VM destroy failed in Stop i-2-59-VM 
Command due to You gave an invalid object reference. The object may have 
recently been deleted.

This is happening as concurrent operations are happening on the same VM. 
Earlier this was not seen as all vm operations were synchronized at agent 
layer. By making execute.in.sequence
global config to false this restriction is no longer there. In the latest code 
operations to a single vm are synchronized by maintaining a job queue. In some 
scenarios the destroy vm operation
was not going through this job queue mechanism and so was resulting in failures 
due to simultaneous operations.


 unable to destroy vm ;VM destroy failed in Stop i-2-59-VM Command due to You 
 gave an invalid object reference.  The object may have recently been deleted. 
 ---

 Key: CLOUDSTACK-5002
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5002
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, XenServer
Affects Versions: 4.2.1
Reporter: prashant kumar mishra
Assignee: Koushik Das
Priority: Critical
 Fix For: 4.3.0

 Attachments: MS_xen_DB.rar, SMlog


 steps to reproduce
 ---
 1-prepare CS setup with xen 6.1
 2-set execute.in.sequence.hypervisor.commands and 
 execute.in.sequence.network.element.commands to false
 3-Restart MS
 4-deploy 35 vms parallelly with default centOS template
 5-try to destroy all uservms using script 
 Expected
 -
 All vms should get destroyed
 Actual
 
 7 vms went in stopped state
 Logs
 ---
 2013-10-30 10:22:35,406 DEBUG [agent.transport.Request] 
 (Job-Executor-93:job-244 = [ 539bf83c-67bb-4d4a-a8e2-837a8d85cb4d ]) Seq 
 3-125567535: Sending  { Cmd , MgmtId: 7484181839895, via: 3, Ver: v1, Flags: 
 100011, 
 [{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:false,vmName:i-2-59-VM,wait:0}}]
  }
 2013-10-30 10:22:35,406 DEBUG [agent.transport.Request] 
 (Job-Executor-93:job-244 = [ 539bf83c-67bb-4d4a-a8e2-837a8d85cb4d ]) Seq 
 3-125567535: Executing:  { Cmd , MgmtId: 7484181839895, via: 3, Ver: v1, 
 Flags: 100011, 
 [{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:false,vmName:i-2-59-VM,wait:0}}]
  }
 2013-10-30 10:22:36,050 DEBUG [xen.resource.CitrixResourceBase] 
 (DirectAgent-68:null) 9. The VM i-2-59-VM is in Stopping state
 013-10-30 10:22:39,747 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (DirectAgent-490:null) VM i-2-59-VM: cs state = Stopping and realState = 
 Running
 2013-10-30 10:22:39,747 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (DirectAgent-490:null) VM i-2-59-VM: cs state = Stopping and realState = 
 Running
 2013-10-30 10:32:36,831 WARN  [xen.resource.CitrixResourceBase] 
 (DirectAgent-68:null) Async 600 seconds timeout for task 
 com.xensource.xenapi.Task@53bab0c6
 2013-10-30 10:32:36,843 DEBUG [xen.resource.CitrixResourceBase] 
 (DirectAgent-68:null) Unable to cleanShutdown VM(i-2-59-VM) on 
 host(7f8a4f8f-1c15-4b7a-95cf-1f64b09ce674) due to Async 600 seconds timeout 
 for task com.xensource.xenapi.Task@53bab0c6
 2013-10-30 10:42:05,852 DEBUG [agent.transport.Request] (HA-Worker-4:work-40) 
 Seq 3-125567622: Sending  { Cmd , MgmtId: 7484181839895, via: 3, Ver: v1, 
 Flags: 100011, 
 [{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:false,vmName:i-2-59-VM,wait:0}}]
  }
 2013-10-30 10:42:05,853 DEBUG [agent.transport.Request] (HA-Worker-4:work-40) 
 Seq 3-125567622: Executing:  { Cmd , MgmtId: 7484181839895, via: 3, Ver: v1, 
 Flags: 100011, 
 [{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:false,vmName:i-2-59-VM,wait:0}}]
  }
 013-10-30 10:42:05,991 DEBUG [xen.resource.CitrixResourceBase] 
 (DirectAgent-218:null) 9. The VM i-2-59-VM is in Stopping state
 2013-10-30 10:42:05,997 WARN  [xen.resource.CitrixResourceBase] 
 (DirectAgent-152:null) VM destroy failed in Stop i-2-67-VM Command due to You 
 gave an invalid object reference.  The object may have recently been deleted. 
  The class parameter gives the type of reference given, and the handle 
 parameter echoes the bad value given.
 You gave an invalid object reference.  The object may have

[jira] [Commented] (CLOUDSTACK-5314) Negative (-ve) values for primary storage and volumes are shown in the resource count table

2014-01-07 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864044#comment-13864044
 ] 

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

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

CLOUDSTACK-5314: Negative (-ve) values for primary storage and volumes are 
shown in the resource count table.


 Negative (-ve) values for primary storage and volumes are shown in the 
 resource count table
 ---

 Key: CLOUDSTACK-5314
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5314
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup, Management Server
Affects Versions: 4.3.0
 Environment: Hyper-V
Reporter: Abhinav Roy
Assignee: Sanjay Tripathi
Priority: Critical
 Fix For: 4.3.0


 Description :
 
 The resource count value for primary storage and volumes in the 
 cloud.resource_count table is shown as negative (-ve)
 mysql select * from resource_count;
 +++---+---+---+
 | id | account_id | domain_id | type  | count |
 +++---+---+---+
 |  1 |   NULL | 1 | cpu   | 6 |
 |  2 |   NULL | 1 | memory|  3072 |
 |  3 |   NULL | 1 | primary_storage   | -103079215104 |
 |  4 |   NULL | 1 | secondary_storage |   56863775232 |
 |  9 |   NULL | 1 | user_vm   | 6 |
 | 10 |   NULL | 1 | public_ip | 2 |
 | 11 |   NULL | 1 | volume|-5 |
 | 12 |   NULL | 1 | snapshot  | 0 |
 | 13 |   NULL | 1 | template  | 4 |
 | 14 |   NULL | 1 | project   | 0 |
 | 15 |   NULL | 1 | network   | 1 |
 | 16 |   NULL | 1 | vpc   | 0 |
 | 17 |  1 |  NULL | user_vm   | 0 |
 | 18 |  1 |  NULL | public_ip | 0 |
 | 19 |  1 |  NULL | volume| 0 |
 | 20 |  1 |  NULL | snapshot  | 0 |
 | 21 |  1 |  NULL | template  | 0 |
 | 22 |  1 |  NULL | project   | 0 |
 | 23 |  1 |  NULL | network   | 0 |
 | 24 |  1 |  NULL | vpc   | 0 |
 | 25 |  1 |  NULL | cpu   | 0 |
 | 26 |  1 |  NULL | memory| 0 |
 | 27 |  1 |  NULL | primary_storage   | 0 |
 | 28 |  1 |  NULL | secondary_storage | 0 |
 | 29 |  2 |  NULL | user_vm   | 6 |
 | 30 |  2 |  NULL | public_ip | 2 |
 | 31 |  2 |  NULL | volume|-5 |
 | 32 |  2 |  NULL | snapshot  | 0 |
 | 33 |  2 |  NULL | template  | 4 |
 | 34 |  2 |  NULL | project   | 0 |
 | 35 |  2 |  NULL | network   | 1 |
 | 36 |  2 |  NULL | vpc   | 0 |
 | 37 |  2 |  NULL | cpu   | 6 |
 | 38 |  2 |  NULL | memory|  3072 |
 | 39 |  2 |  NULL | primary_storage   | -103079215104 |
 | 40 |  2 |  NULL | secondary_storage |  163220937216 |
 +++---+---+---+
 36 rows in set (0.00 sec)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (CLOUDSTACK-5314) Negative (-ve) values for primary storage and volumes are shown in the resource count table


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

Sanjay Tripathi resolved CLOUDSTACK-5314.
-

Resolution: Fixed

 Negative (-ve) values for primary storage and volumes are shown in the 
 resource count table
 ---

 Key: CLOUDSTACK-5314
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5314
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup, Management Server
Affects Versions: 4.3.0
 Environment: Hyper-V
Reporter: Abhinav Roy
Assignee: Sanjay Tripathi
Priority: Critical
 Fix For: 4.3.0


 Description :
 
 The resource count value for primary storage and volumes in the 
 cloud.resource_count table is shown as negative (-ve)
 mysql select * from resource_count;
 +++---+---+---+
 | id | account_id | domain_id | type  | count |
 +++---+---+---+
 |  1 |   NULL | 1 | cpu   | 6 |
 |  2 |   NULL | 1 | memory|  3072 |
 |  3 |   NULL | 1 | primary_storage   | -103079215104 |
 |  4 |   NULL | 1 | secondary_storage |   56863775232 |
 |  9 |   NULL | 1 | user_vm   | 6 |
 | 10 |   NULL | 1 | public_ip | 2 |
 | 11 |   NULL | 1 | volume|-5 |
 | 12 |   NULL | 1 | snapshot  | 0 |
 | 13 |   NULL | 1 | template  | 4 |
 | 14 |   NULL | 1 | project   | 0 |
 | 15 |   NULL | 1 | network   | 1 |
 | 16 |   NULL | 1 | vpc   | 0 |
 | 17 |  1 |  NULL | user_vm   | 0 |
 | 18 |  1 |  NULL | public_ip | 0 |
 | 19 |  1 |  NULL | volume| 0 |
 | 20 |  1 |  NULL | snapshot  | 0 |
 | 21 |  1 |  NULL | template  | 0 |
 | 22 |  1 |  NULL | project   | 0 |
 | 23 |  1 |  NULL | network   | 0 |
 | 24 |  1 |  NULL | vpc   | 0 |
 | 25 |  1 |  NULL | cpu   | 0 |
 | 26 |  1 |  NULL | memory| 0 |
 | 27 |  1 |  NULL | primary_storage   | 0 |
 | 28 |  1 |  NULL | secondary_storage | 0 |
 | 29 |  2 |  NULL | user_vm   | 6 |
 | 30 |  2 |  NULL | public_ip | 2 |
 | 31 |  2 |  NULL | volume|-5 |
 | 32 |  2 |  NULL | snapshot  | 0 |
 | 33 |  2 |  NULL | template  | 4 |
 | 34 |  2 |  NULL | project   | 0 |
 | 35 |  2 |  NULL | network   | 1 |
 | 36 |  2 |  NULL | vpc   | 0 |
 | 37 |  2 |  NULL | cpu   | 6 |
 | 38 |  2 |  NULL | memory|  3072 |
 | 39 |  2 |  NULL | primary_storage   | -103079215104 |
 | 40 |  2 |  NULL | secondary_storage |  163220937216 |
 +++---+---+---+
 36 rows in set (0.00 sec)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CLOUDSTACK-5799) Foreign characters not accepted

2014-01-07 Thread JIRA


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

Jan-Arve Nygård updated CLOUDSTACK-5799:


Summary: Foreign characters not accepted  (was: Norwegian characters not 
accepted)

 Foreign characters not accepted
 ---

 Key: CLOUDSTACK-5799
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5799
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.0
Reporter: Jan-Arve Nygård
Priority: Minor

 Norwegian characters (f.ex æøå) are not accepted as a part of the name 
 (firstname and lastname) when creating a user. 
 This issue did not exist in CloudStack 3.x. I don't think this is by design, 
 but if that's the case there should be something in the UI giving error when 
 trying to use foreign/unsupported characters.
 Here's the error message when trying to create a user:
 2014-01-06 14:34:50,582 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null) 
 ===START===  172.30.86.24 -- POST  
 command=createAccountresponse=jsonsessionkey=grfZR4pMZgwQ204rdEwdXPVxhJw%3D
 2014-01-06 14:34:50,597 INFO  [cloud.api.ApiServer] (catalina-exec-25:null) 
 Received value KÃ¦r for parameter lastname is invalid, contains illegal ASCII 
 non-printable characters
 2014-01-06 14:34:50,598 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null) 
 ===END===  172.30.86.24 -- POST  
 command=createAccountresponse=jsonsessionkey=grfZR4pMZgwQ204rdEwdXPVxhJw%3D



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Closed] (CLOUDSTACK-5649) [Hyper-v] Putting host in maintenance mode does not start the guest vms and VRs running on it on another available host in the cluster

2014-01-07 Thread ASF subversion and git services (JIRA)


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

Sanjeev N closed CLOUDSTACK-5649.
-


Verified on the latest build from 4.3 branch with 
commit:6f309b8a87d3376950a60234d399c6e3749ad1c7
Works fine.

 [Hyper-v] Putting host in maintenance mode does not start the guest vms and 
 VRs running on it on another available host in the cluster
 --

 Key: CLOUDSTACK-5649
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5649
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller, Management Server
Affects Versions: 4.3.0
 Environment: Latest build from 4.3 branch with 
 commit:ddd27b3f483319787f7509d13d30b976620831e8
 Hypervisor: Hyperv
 Storage: SMB for both primary and secondary
Reporter: Sanjeev N
Assignee: Devdeep Singh
Priority: Critical
  Labels: hyper-V,, hyper-v, hyperv
 Fix For: 4.3.0

 Attachments: cloud.dmp, management-server.rar


 [Hyper-v] Putting host in maintenance mode does not migrate the guest vms and 
 VRs running on it to another available host in the cluster
 Steps to Reproduce:
 
 1.Bring up CS in advanced zone with two or more hosts in the cluster with 
 shared storage using SMB for both primary and secondary
 2.Deploy few vms(Non-ha enabled) such that vms are distributed across both 
 the hosts
 3.Put one host in maintenance mode
 Expected Result:
 ==
 Host should go to maintenance mode and all the vms running on it should be 
 migrated to another host
 Actual Result:
 ===
 Host transitioned into maintenance mode but all the vms running on it were 
 not migrated to another host
 In case of host failure only non-HAed vms should be stopped but when the host 
 is put in maintenance mode from CS all the vms running on it should be 
 migrated and should be started on another available hosts in the same cluster.
 2013-12-26 16:09:18,498 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-20:ctx-06e2a7d7) ===START===  10.146.0.134 -- GET  
 command=prepareHostForMaintenanceid=bd4e26d2-effb-4c2a-a22a-137a5d91225aresponse=jsonsessionkey=d%2Bsyfd%2FWn2mU%2Bt9TnFJ4cyRpkbY%3D_=1388054354967
 2013-12-26 16:09:18,645 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (catalina-exec-20:ctx-06e2a7d7 ctx-bf5e3753) submit async job-24, details: 
 AsyncJobVO {id:24, userId: 2, accountId: 2, instanceType: Host, instanceId: 
 1, cmd: 
 org.apache.cloudstack.api.command.admin.host.PrepareForMaintenanceCmd, 
 cmdInfo: 
 {response:json,id:bd4e26d2-effb-4c2a-a22a-137a5d91225a,sessionkey:d+syfd/Wn2mU+t9TnFJ4cyRpkbY\u003d,cmdEventType:MAINT.PREPARE,ctxUserId:2,httpmethod:GET,_:1388054354967,ctxAccountId:2,ctxStartEventId:75},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 132129494109518, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2013-12-26 16:09:18,646 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
 (Job-Executor-20:ctx-e25a8c36) Add job-24 into job monitoring
 2013-12-26 16:09:18,646 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (Job-Executor-20:ctx-e25a8c36) Executing AsyncJobVO {id:24, userId: 2, 
 accountId: 2, instanceType: Host, instanceId: 1, cmd: 
 org.apache.cloudstack.api.command.admin.host.PrepareForMaintenanceCmd, 
 cmdInfo: 
 {response:json,id:bd4e26d2-effb-4c2a-a22a-137a5d91225a,sessionkey:d+syfd/Wn2mU+t9TnFJ4cyRpkbY\u003d,cmdEventType:MAINT.PREPARE,ctxUserId:2,httpmethod:GET,_:1388054354967,ctxAccountId:2,ctxStartEventId:75},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 132129494109518, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2013-12-26 16:09:18,647 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-20:ctx-06e2a7d7 ctx-bf5e3753) ===END===  10.146.0.134 -- GET  
 command=prepareHostForMaintenanceid=bd4e26d2-effb-4c2a-a22a-137a5d91225aresponse=jsonsessionkey=d%2Bsyfd%2FWn2mU%2Bt9TnFJ4cyRpkbY%3D_=1388054354967
 2013-12-26 16:09:18,660 DEBUG [c.c.a.t.Request] (Job-Executor-20:ctx-e25a8c36 
 ctx-bf5e3753) Seq 1-493617246: Sending  { Cmd , MgmtId: 132129494109518, via: 
 1(10.147.40.14), Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.MaintainCommand:{wait:0}}] }
 2013-12-26 16:09:18,660 DEBUG [c.c.a.t.Request] (Job-Executor-20:ctx-e25a8c36 
 ctx-bf5e3753) Seq 1-493617246: Executing:  { Cmd , MgmtId: 132129494109518, 
 via: 1(10.147.40.14), Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.MaintainCommand:{wait:0}}] }
 2013-12-26 16:09:18,660 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-110:ctx-691b6046) Seq 1-493617246: Executing request
 2013-12-26

[jira] [Created] (CLOUDSTACK-5817) [Dev Setup]Deploy Db is failing on master and 4.3

2014-01-07 Thread prashant kumar mishra (JIRA)

prashant kumar mishra created CLOUDSTACK-5817:
-

 Summary: [Dev Setup]Deploy Db is failing on master and 4.3
 Key: CLOUDSTACK-5817
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5817
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.3.0
Reporter: prashant kumar mishra
Priority: Blocker
 Fix For: 4.3.0


Ddeploydb is failing on master and 4.3 branch .  For branch 4.2 it  is working 
fine

[root@localhost cloudstack]# mvn -P developer -pl developer -Ddeploydb
[INFO] Scanning for projects...
[INFO]
[INFO] 
[INFO] Building Apache CloudStack Developer Mode 4.4.0-SNAPSHOT
[INFO] 
[INFO]
[INFO] --- properties-maven-plugin:1.0-alpha-2:read-project-properties 
(default) @ cloud-developer ---
[INFO]
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-developer ---
[INFO]
[INFO] --- maven-antrun-plugin:1.7:run (default) @ cloud-developer ---
[INFO] Executing tasks

main:
[INFO] Executed tasks
[INFO]
[INFO]  exec-maven-plugin:1.2.1:java (create-schema) @ cloud-developer 
[INFO]
[INFO]  exec-maven-plugin:1.2.1:java (create-schema) @ cloud-developer 
[INFO]
[INFO] --- exec-maven-plugin:1.2.1:java (create-schema) @ cloud-developer ---
log4j:WARN No appenders could be found for logger 
(org.springframework.core.env.StandardEnvironment).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
info.
 WARNING: Provided file does not exist: 
/root/cloudstack/developer/developer-prefill.sql.override
 Initializing database=cloud with host=localhost port=3306 
username=root password=
 Running query: drop database if exists `cloud`
 Running query: create database `cloud`
 Running query: GRANT ALL ON cloud.* to 'root'@`localhost` 
identified by ''
 Running query: GRANT ALL ON cloud.* to 'root'@`%` identified by ''
 Initializing database=cloud_usage with host=localhost port=3306 
username=root password=
 Running query: drop database if exists `cloud_usage`
 Running query: create database `cloud_usage`
 Running query: GRANT ALL ON cloud_usage.* to 'root'@`localhost` 
identified by ''
 Running query: GRANT ALL ON cloud_usage.* to 'root'@`%` 
identified by ''
 Initializing database=cloudbridge with host=localhost port=3306 
username=root password=
 Running query: drop database if exists `cloudbridge`
 Running query: create database `cloudbridge`
 Running query: GRANT ALL ON cloudbridge.* to 'root'@`localhost` 
identified by ''
 Running query: GRANT ALL ON cloudbridge.* to 'root'@`%` 
identified by ''
 Processing SQL file at 
/root/cloudstack/developer/target/db/create-schema.sql
 Processing SQL file at 
/root/cloudstack/developer/target/db/create-schema-premium.sql
 Processing SQL file at 
/root/cloudstack/developer/target/db/templates.sql
 Processing SQL file at 
/root/cloudstack/developer/target/db/cloudbridge_schema.sql
 Processing SQL file at 
/root/cloudstack/developer/target/db/cloudbridge_multipart.sql
 Processing SQL file at 
/root/cloudstack/developer/target/db/cloudbridge_index.sql
 Processing SQL file at 
/root/cloudstack/developer/target/db/cloudbridge_multipart_alter.sql
 Processing SQL file at 
/root/cloudstack/developer/target/db/cloudbridge_bucketpolicy.sql
 Processing SQL file at 
/root/cloudstack/developer/target/db/cloudbridge_policy_alter.sql
 Processing SQL file at 
/root/cloudstack/developer/target/db/cloudbridge_offering.sql
 Processing SQL file at 
/root/cloudstack/developer/target/db/cloudbridge_offering_alter.sql
 Processing SQL file at 
/root/cloudstack/developer/developer-prefill.sql
 Processing upgrade: com.cloud.upgrade.DatabaseUpgradeChecker
[WARNING]
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
at java.lang.Thread.run(Thread.java:679)
Caused by: com.cloud.utils.exception.CloudRuntimeException: Unable to upgrade 
the database
at

[jira] [Updated] (CLOUDSTACK-5817) [Dev Setup]Deploy Db is failing on master and 4.3

2014-01-07 Thread prashant kumar mishra (JIRA)


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

prashant kumar mishra updated CLOUDSTACK-5817:
--

Description: 
Ddeploydb is failing on master and 4.3 branch .  For branch 4.2 it  is working 
fine

[root@localhost cloudstack]# mvn -P developer -pl developer -Ddeploydb
[INFO] Scanning for projects...
[INFO]
[INFO] 
[INFO] Building Apache CloudStack Developer Mode 4.4.0-SNAPSHOT
[INFO] 
[INFO]
[INFO] --- properties-maven-plugin:1.0-alpha-2:read-project-properties 
(default) @ cloud-developer ---
[INFO]
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-developer ---
[INFO]
[INFO] --- maven-antrun-plugin:1.7:run (default) @ cloud-developer ---
[INFO] Executing tasks

main:
[INFO] Executed tasks
[INFO]
[INFO]  exec-maven-plugin:1.2.1:java (create-schema) @ cloud-developer 
[INFO]
[INFO]  exec-maven-plugin:1.2.1:java (create-schema) @ cloud-developer 
[INFO]
[INFO] --- exec-maven-plugin:1.2.1:java (create-schema) @ cloud-developer ---
log4j:WARN No appenders could be found for logger 
(org.springframework.core.env.StandardEnvironment).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
info.
 WARNING: Provided file does not exist: 
/root/cloudstack/developer/developer-prefill.sql.override
 Initializing database=cloud with host=localhost port=3306 
username=root password=
 Running query: drop database if exists `cloud`
 Running query: create database `cloud`
 Running query: GRANT ALL ON cloud.* to 'root'@`localhost` 
identified by ''
 Running query: GRANT ALL ON cloud.* to 'root'@`%` identified by ''
 Initializing database=cloud_usage with host=localhost port=3306 
username=root password=
 Running query: drop database if exists `cloud_usage`
 Running query: create database `cloud_usage`
 Running query: GRANT ALL ON cloud_usage.* to 'root'@`localhost` 
identified by ''
 Running query: GRANT ALL ON cloud_usage.* to 'root'@`%` 
identified by ''
 Initializing database=cloudbridge with host=localhost port=3306 
username=root password=
 Running query: drop database if exists `cloudbridge`
 Running query: create database `cloudbridge`
 Running query: GRANT ALL ON cloudbridge.* to 'root'@`localhost` 
identified by ''
 Running query: GRANT ALL ON cloudbridge.* to 'root'@`%` 
identified by ''
 Processing SQL file at 
/root/cloudstack/developer/target/db/create-schema.sql
 Processing SQL file at 
/root/cloudstack/developer/target/db/create-schema-premium.sql
 Processing SQL file at 
/root/cloudstack/developer/target/db/templates.sql
 Processing SQL file at 
/root/cloudstack/developer/target/db/cloudbridge_schema.sql
 Processing SQL file at 
/root/cloudstack/developer/target/db/cloudbridge_multipart.sql
 Processing SQL file at 
/root/cloudstack/developer/target/db/cloudbridge_index.sql
 Processing SQL file at 
/root/cloudstack/developer/target/db/cloudbridge_multipart_alter.sql
 Processing SQL file at 
/root/cloudstack/developer/target/db/cloudbridge_bucketpolicy.sql
 Processing SQL file at 
/root/cloudstack/developer/target/db/cloudbridge_policy_alter.sql
 Processing SQL file at 
/root/cloudstack/developer/target/db/cloudbridge_offering.sql
 Processing SQL file at 
/root/cloudstack/developer/target/db/cloudbridge_offering_alter.sql
 Processing SQL file at 
/root/cloudstack/developer/developer-prefill.sql
 Processing upgrade: com.cloud.upgrade.DatabaseUpgradeChecker
[WARNING]
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
at java.lang.Thread.run(Thread.java:679)
Caused by: com.cloud.utils.exception.CloudRuntimeException: Unable to upgrade 
the database
at 
com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:337)
at 
com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:432)
at com.cloud.upgrade.DatabaseCreator.main(DatabaseCreator.java:222)
... 6 more
Caused by: com.cloud.utils.exception.CloudRuntimeException: Unable to execute 
upgrade script: /root/cloudstack/developer/target/db/db/schema-421to430.sql

[jira] [Comment Edited] (CLOUDSTACK-5681) Contrail:MS:API: Create network fails with NPE due to missing CIDR

2014-01-07 Thread Santhosh Kumar Edukulla (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864079#comment-13864079
 ] 

Santhosh Kumar Edukulla edited comment on CLOUDSTACK-5681 at 1/7/14 10:37 AM:
--

Hi Parth,

I tried it with felton\4.3. I didn't see any exception here. Below are the 
steps i followed:

Note1:
1. Login to CS UI, navigate to Network-Add Isolated Network.
2. Filled in all other fields, Entered GatewayIp with out specifying netmask. 

It crated the network.

Note2:
1. Login to CS UI, navigate to Network-Add Guest Network.
2. Filled in all other * fields, Entered GatewayIp with out specifying netmask, 
startip,endip etc. Clicking on OK thrown up a warning with information 
retrieved from API, mentioning these fields are mandatory fields.

I didn't see any exception in either case. As well, it didn't created any 
entries in DB as mentioned in mail thread @Dev list.  

Note3: I didn't verified it with 4.2 as 4.2.1 is already on vote for it to be 
out. Its not reproducible with 4.3 atleast. If it is indeed reproducible with 
4.3, please mention steps to reproduce.


Thanks!
Santhosh


was (Author: santhoshe):
Hi Parth,

I tried it with felton\4.3. I didn't see any exception here. Below are the 
steps i followed:

Note1:
1. Network-Add Isolated Network.
2. Filled in all other fields, Entered GatewayIp with out specifying netmask. 

It crated the network.

Note2:
1. Network-Add Guest Network.
2. Filled in all other * fields, Entered GatewayIp with out specifying netmask, 
startip,endip etc. Clicking on OK thrown up a warning with information 
retrieved from API, mentioning these fields are mandatory fields.

I didn't see any exception in either case. As well, it didnt created any 
entries in DB as mentioned in mail thread @Dev list.  

Note3: I didn't verified it with 4.2 as 4.2.1 is already on vote for it to be 
out. Its not reproducible with 4.3 atleast. If it is indeed reproducible with 
4.3, please mention steps to reproduce.


Thanks!
Santhosh

 Contrail:MS:API: Create network fails with NPE due to missing CIDR
 --

 Key: CLOUDSTACK-5681
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5681
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API, Contrail, Management Server
Affects Versions: 4.2.0
 Environment: Contrail
Reporter: Parth Jagirdar
Assignee: Santhosh Kumar Edukulla
Priority: Critical

 CIDR is not required param in API, but without CIDR exceptions are thrown.
 2013-12-27 16:44:14,088 ERROR [cloud.api.ApiServer] (catalina-exec-3:null) 
 unhandled exception executing api command: createNetwork
 java.lang.NullPointerException
   at 
 com.cloud.network.NetworkModelImpl.getAvailableIps(NetworkModelImpl.java:1694)
   at 
 com.cloud.network.NetworkModelImpl.canUseForDeploy(NetworkModelImpl.java:585)
   at com.cloud.api.ApiDBUtils.canUseForDeploy(ApiDBUtils.java:1147)
   at 
 com.cloud.api.ApiResponseHelper.createNetworkResponse(ApiResponseHelper.java:2259)
   at 
 org.apache.cloudstack.api.command.user.network.CreateNetworkCmd.execute(CreateNetworkCmd.java:288)
   at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
   at com.cloud.api.ApiServer.queueCommand(ApiServer.java:514)
   at com.cloud.api.ApiServer.handleRequest(ApiServer.java:372)
   at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:305)
   at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
   at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
   at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
   at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
   at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
   at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
   at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
   at 
 org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
   at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
   at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
   at 
 org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
   at 
 org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721)

[jira] [Commented] (CLOUDSTACK-5681) Contrail:MS:API: Create network fails with NPE due to missing CIDR

2014-01-07 Thread Santhosh Kumar Edukulla (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864079#comment-13864079
 ] 

Santhosh Kumar Edukulla commented on CLOUDSTACK-5681:
-

Hi Parth,

I tried it with felton\4.3. I didn't see any exception here. Below are the 
steps i followed:

Note1:
1. Network-Add Isolated Network.
2. Filled in all other fields, Entered GatewayIp with out specifying netmask. 

It crated the network.

Note2:
1. Network-Add Guest Network.
2. Filled in all other * fields, Entered GatewayIp with out specifying netmask, 
startip,endip etc. Clicking on OK thrown up a warning with information 
retrieved from API, mentioning these fields are mandatory fields.

I didn't see any exception in either case. As well, it didnt created any 
entries in DB as mentioned in mail thread @Dev list.  

Note3: I didn't verified it with 4.2 as 4.2.1 is already on vote for it to be 
out. Its not reproducible with 4.3 atleast. If it is indeed reproducible with 
4.3, please mention steps to reproduce.


Thanks!
Santhosh

 Contrail:MS:API: Create network fails with NPE due to missing CIDR
 --

 Key: CLOUDSTACK-5681
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5681
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API, Contrail, Management Server
Affects Versions: 4.2.0
 Environment: Contrail
Reporter: Parth Jagirdar
Assignee: Santhosh Kumar Edukulla
Priority: Critical

 CIDR is not required param in API, but without CIDR exceptions are thrown.
 2013-12-27 16:44:14,088 ERROR [cloud.api.ApiServer] (catalina-exec-3:null) 
 unhandled exception executing api command: createNetwork
 java.lang.NullPointerException
   at 
 com.cloud.network.NetworkModelImpl.getAvailableIps(NetworkModelImpl.java:1694)
   at 
 com.cloud.network.NetworkModelImpl.canUseForDeploy(NetworkModelImpl.java:585)
   at com.cloud.api.ApiDBUtils.canUseForDeploy(ApiDBUtils.java:1147)
   at 
 com.cloud.api.ApiResponseHelper.createNetworkResponse(ApiResponseHelper.java:2259)
   at 
 org.apache.cloudstack.api.command.user.network.CreateNetworkCmd.execute(CreateNetworkCmd.java:288)
   at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
   at com.cloud.api.ApiServer.queueCommand(ApiServer.java:514)
   at com.cloud.api.ApiServer.handleRequest(ApiServer.java:372)
   at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:305)
   at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
   at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
   at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
   at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
   at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
   at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
   at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
   at 
 org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
   at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
   at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
   at 
 org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
   at 
 org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721)
   at 
 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2266)
   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:724)
 2013-12-27 16:44:14,093 DEBUG [cloud.api.ApiServlet] (catalina-exec-3:null) 
 ===END===  10.215.2.19 -- GET  
 command=createNetworkresponse=jsonsessionkey=ijYX%2B4fZ2EjdBMgdrTgGLJU2e60%3DnetworkOfferingId=c9298387-30ec-40be-a0b7-cf54829fa5f8name=tempdisplayText=tempzoneId=37b6d96d-5b66-429b-8e8e-b7bd6d12ae96_=1388191455496
 2013-12-27 16:44:18,776 DEBUG [agent.manager.AgentManagerImpl] 
 (AgentManager-Handler-2:null) SeqA 2-11511: Processing Seq 2-11511:  { Cmd , 
 MgmtId: -1, via: 2, Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:2,_loadInfo:{\n
   \connections\: []\n},wait:0}}] }
 2013-12-27 16:44:18,780 DEBUG

[jira] [Commented] (CLOUDSTACK-5718) guest OS type for default template CentOS 5.6(64-bit) no GUI (XenServer) is CentOS 5.3(64-bit)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864086#comment-13864086
 ] 

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

Commit 6220e48a9852bb4d92793cbf197ead27048dc816 in branch refs/heads/4.3 from 
[~sanjay.tripathi]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6220e48 ]

CLOUDSTACK-5718: guest OS type for default template CentOS 5.6(64-bit) no GUI 
(XenServer) is CentOS 5.3(64-bit).


 guest OS type for default template CentOS 5.6(64-bit) no GUI (XenServer) is 
 CentOS 5.3(64-bit) 
 -

 Key: CLOUDSTACK-5718
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5718
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.3.0
Reporter: prashant kumar mishra
Assignee: Sanjay Tripathi
Priority: Critical
 Fix For: 4.3.0


 guest os id should be id of CentOS5.6 ID
 mysql select *  from vm_template where id=5\G;
 *** 1. row ***
   id: 5
  unique_name: centos56-x86_64-xen
 name: CentOS 5.6(64-bit) no GUI (XenServer)
 uuid: 2879fdde-7306-11e3-8e46-067fae58
   public: 1
 featured: 1
 type: BUILTIN
  hvm: 0
 bits: 64
  url: 
 http://download.cloud.com/templates/builtin/centos56-x86_64.vhd.bz2
   format: VHD
  created: 2014-01-01 12:00:03
  removed: NULL
   account_id: 1
 checksum: 905cec879afd9c9d22ecc8036131a180
 display_text: CentOS 5.6(64-bit) no GUI (XenServer)
  enable_password: 0
enable_sshkey: 0
  guest_os_id: 12
 bootable: 1
  prepopulate: 0
  cross_zones: 1
  extractable: 1
  hypervisor_type: XenServer
   source_template_id: NULL
 template_tag: NULL
 sort_key: 0
 size: 21474836480
state: Active
 update_count: 0
  updated: NULL
 dynamically_scalable: 1
 1 row in set (0.00 sec)
 ERROR:
 No query specified
 mysql select * from guest_os where id=12;
 ++-+--+--+-+
 | id | category_id | name | uuid | 
 display_name|
 ++-+--+--+-+
 | 12 |   1 | NULL | 289896a4-7306-11e3-8e46-067fae58 | CentOS 5.3 
 (64-bit) |
 ++-+--+--+-+
 1 row in set (0.00 sec)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Reopened] (CLOUDSTACK-5791) [Automation] unable to delete ldap configuration by hostname

2014-01-07 Thread Rajani Karuturi (JIRA)


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

Rajani Karuturi reopened CLOUDSTACK-5791:
-


fails when db encryption in enabled

 [Automation] unable to delete ldap configuration by hostname 
 -

 Key: CLOUDSTACK-5791
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5791
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: Srikanteswararao Talluri
Assignee: Rajani Karuturi
Priority: Blocker
 Fix For: 4.3.0


 Unable to delete  ldap configuration
 Not able to delete configurations also:
  GET  
 hostname=10.147.59.109command=deleteLdapConfigurationresponse=jsonapiKey=c5DpSTl1lOlqVQ3P1x-YTGlHzBVqKkHJsMz5mi6IlZg3vBfhazVKtz6jFkGcGSVwPmf2HekuHr05rjL7hj_CKgsignature=CpsGkWJDg0CSL4kNss%2BRKXJh9LU%3D
 2014-01-06 19:51:06,756 INFO  [c.c.a.ApiServer] (catalina-exec-1:ctx-9af7b248 
 ctx-96eb3761 ctx-042a32a7) 
 com.cloud.exception.InvalidParameterValueException: Cannot find configuration 
 with hostname 10.147.59.109



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (CLOUDSTACK-5718) guest OS type for default template CentOS 5.6(64-bit) no GUI (XenServer) is CentOS 5.3(64-bit)

2014-01-07 Thread ASF subversion and git services (JIRA)


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

Sanjay Tripathi resolved CLOUDSTACK-5718.
-

Resolution: Fixed

 guest OS type for default template CentOS 5.6(64-bit) no GUI (XenServer) is 
 CentOS 5.3(64-bit) 
 -

 Key: CLOUDSTACK-5718
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5718
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.3.0
Reporter: prashant kumar mishra
Assignee: Sanjay Tripathi
Priority: Critical
 Fix For: 4.3.0


 guest os id should be id of CentOS5.6 ID
 mysql select *  from vm_template where id=5\G;
 *** 1. row ***
   id: 5
  unique_name: centos56-x86_64-xen
 name: CentOS 5.6(64-bit) no GUI (XenServer)
 uuid: 2879fdde-7306-11e3-8e46-067fae58
   public: 1
 featured: 1
 type: BUILTIN
  hvm: 0
 bits: 64
  url: 
 http://download.cloud.com/templates/builtin/centos56-x86_64.vhd.bz2
   format: VHD
  created: 2014-01-01 12:00:03
  removed: NULL
   account_id: 1
 checksum: 905cec879afd9c9d22ecc8036131a180
 display_text: CentOS 5.6(64-bit) no GUI (XenServer)
  enable_password: 0
enable_sshkey: 0
  guest_os_id: 12
 bootable: 1
  prepopulate: 0
  cross_zones: 1
  extractable: 1
  hypervisor_type: XenServer
   source_template_id: NULL
 template_tag: NULL
 sort_key: 0
 size: 21474836480
state: Active
 update_count: 0
  updated: NULL
 dynamically_scalable: 1
 1 row in set (0.00 sec)
 ERROR:
 No query specified
 mysql select * from guest_os where id=12;
 ++-+--+--+-+
 | id | category_id | name | uuid | 
 display_name|
 ++-+--+--+-+
 | 12 |   1 | NULL | 289896a4-7306-11e3-8e46-067fae58 | CentOS 5.3 
 (64-bit) |
 ++-+--+--+-+
 1 row in set (0.00 sec)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5718) guest OS type for default template CentOS 5.6(64-bit) no GUI (XenServer) is CentOS 5.3(64-bit)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864100#comment-13864100
 ] 

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

Commit 85df58d10706186c22d971bfa1ca3d339b4cf94d in branch refs/heads/master 
from [~sanjay.tripathi]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=85df58d ]

CLOUDSTACK-5718: guest OS type for default template CentOS 5.6(64-bit) no GUI 
(XenServer) is CentOS 5.3(64-bit).


 guest OS type for default template CentOS 5.6(64-bit) no GUI (XenServer) is 
 CentOS 5.3(64-bit) 
 -

 Key: CLOUDSTACK-5718
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5718
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.3.0
Reporter: prashant kumar mishra
Assignee: Sanjay Tripathi
Priority: Critical
 Fix For: 4.3.0


 guest os id should be id of CentOS5.6 ID
 mysql select *  from vm_template where id=5\G;
 *** 1. row ***
   id: 5
  unique_name: centos56-x86_64-xen
 name: CentOS 5.6(64-bit) no GUI (XenServer)
 uuid: 2879fdde-7306-11e3-8e46-067fae58
   public: 1
 featured: 1
 type: BUILTIN
  hvm: 0
 bits: 64
  url: 
 http://download.cloud.com/templates/builtin/centos56-x86_64.vhd.bz2
   format: VHD
  created: 2014-01-01 12:00:03
  removed: NULL
   account_id: 1
 checksum: 905cec879afd9c9d22ecc8036131a180
 display_text: CentOS 5.6(64-bit) no GUI (XenServer)
  enable_password: 0
enable_sshkey: 0
  guest_os_id: 12
 bootable: 1
  prepopulate: 0
  cross_zones: 1
  extractable: 1
  hypervisor_type: XenServer
   source_template_id: NULL
 template_tag: NULL
 sort_key: 0
 size: 21474836480
state: Active
 update_count: 0
  updated: NULL
 dynamically_scalable: 1
 1 row in set (0.00 sec)
 ERROR:
 No query specified
 mysql select * from guest_os where id=12;
 ++-+--+--+-+
 | id | category_id | name | uuid | 
 display_name|
 ++-+--+--+-+
 | 12 |   1 | NULL | 289896a4-7306-11e3-8e46-067fae58 | CentOS 5.3 
 (64-bit) |
 ++-+--+--+-+
 1 row in set (0.00 sec)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (CLOUDSTACK-5623) [Automation]Failed to wget from VM

2014-01-07 Thread Srikanteswararao Talluri (JIRA)


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

Srikanteswararao Talluri resolved CLOUDSTACK-5623.
--

Resolution: Fixed

installing http server in the CentOS template solves this problem and will use 
a template with http server.

 [Automation]Failed to wget from VM
 --

 Key: CLOUDSTACK-5623
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5623
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.3.0
 Environment: xenserver 62
 advanced zone
Reporter: Srikanteswararao Talluri
Assignee: Girish Shilamkar
 Fix For: 4.3.0


 Creating this bug as a place holder for the following failures, needs further 
 analysis, 
 test_05_network_services_VPC_StopDeletePF FAILED  Failed to wget from 
 VM=QA-079a98e0-dbff-44c2-8fba-f0352d55029a http server on 
 public_ip=10.147.53.60
 test_06_network_services_VPC_DeletePF FAILED  Failed to wget from 
 VM=QA-f52b2825-b902-4888-ba63-225b8032b8f1 http server on 
 public_ip=10.147.53.12
 test_07_network_services_VPC_StopDeleteAllPF  FAILED  Failed to wget from 
 VM=QA-f6c682bf-4981-4da4-8715-32ddba06ea22 http server on 
 public_ip=10.147.53.88
 test_08_network_services_VPC_DeleteAllPF  FAILED  Failed to wget from 
 VM=QA-a38ba1e6-64f1-4b68-aef7-eb040cd241c9 http server on 
 public_ip=10.147.53.131
 test_09_network_services_VPC_StopDeleteAllMultiplePF  FAILED  Failed to wget 
 from VM=QA-23014b46-784e-4fc3-bbdb-772fc618dcbf http server on 
 public_ip=10.147.53.92
 test_10_network_services_VPC_DeleteAllMultiplePF  FAILED  Failed to wget 
 from VM=QA-042db012-f842-4016-a120-14c1e7e6b717 http server on 
 public_ip=10.147.53.123
 test_05_network_services_VPC_DeleteAllPF  FAILED  Failed to wget from 
 VM=QA-44d01e1c-68ea-4e9f-8def-8e87ea802eb0 http server on 
 public_ip=10.147.53.86
 test_06_network_services_VPC_DeleteAllMultiplePF  FAILED  Failed to wget 
 from VM=QA-e94dec29-4582-476c-9780-a03b46c8d5bc http server on 
 public_ip=10.147.53.77



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Assigned] (CLOUDSTACK-5802) [Automation] Check display text of newly created template

2014-01-07 Thread Ashutosk Kelkar (JIRA)


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

Ashutosk Kelkar reassigned CLOUDSTACK-5802:
---

Assignee: Ashutosk Kelkar

 [Automation] Check display text of newly created template
 -

 Key: CLOUDSTACK-5802
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5802
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Test
Affects Versions: 4.3.0
 Environment: xenserver 6.1 
 basic zone
Reporter: Srikanteswararao Talluri
Assignee: Ashutosk Kelkar
Priority: Blocker
 Fix For: 4.3.0


 This bug is to track the test failure
 test_01_create_template 
 (integration.component.test_blocker_bugs.TestTemplate): CRITICAL: FAILED: 
 test_01_create_template: Traceback (most recent call last):
   File /usr/local/lib/python2.7/unittest/case.py, line 327, in run
 testMethod()
   File 
 /root/asf/cloudstack/test/integration/component/test_blocker_bugs.py, line 
 219, in test_01_create_template
 Check display text of newly created template
   File /usr/local/lib/python2.7/unittest/case.py, line 511, in assertEqual
 assertion_func(first, second, msg=msg)
   File /usr/local/lib/python2.7/unittest/case.py, line 504, in 
 _baseAssertEqual
 raise self.failureException(msg)
 AssertionError: Check display text of newly created template



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-5818) [Hyper-v]Agent status of the System VMs is not updated during Host disconnect

2014-01-07 Thread ASF subversion and git services (JIRA)

Sanjeev N created CLOUDSTACK-5818:
-

 Summary: [Hyper-v]Agent status of the System VMs is not updated 
during Host disconnect
 Key: CLOUDSTACK-5818
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5818
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Hypervisor Controller
Affects Versions: 4.3.0
 Environment: Latest build from 4.3branch with 
commit:6f309b8a87d3376950a60234d399c6e3749ad1c7
Reporter: Sanjeev N
Priority: Critical
 Fix For: 4.3.0


[Hyper-v]Agent status of the System VMs is not updated during Host disconnect.

Steps to Reproduce:

1.Bring up CS in advanced zone with hyper-v cluster and with SMB for both 
primary and secondary
2.Wait for the system vms to come up
3.Simulate host disconnect by unplugging the network cable.
4.I see host status changing to Down but the agent status of the system vms 
remained Up 

Impact:
==
All the operations involving SSVM and CPVM are failing since the host is down.
So user is blocked to perform following things:
1.Download/Register/copy template
2.Upload/Download volume
3.Console access





--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-5819) extractTemplate fails with Vmware host on migration of NFS to S3

2014-01-07 Thread Pavan Kumar Bandarupally (JIRA)

Pavan Kumar Bandarupally created CLOUDSTACK-5819:


 Summary: extractTemplate fails with Vmware host on migration of 
NFS to S3
 Key: CLOUDSTACK-5819
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5819
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Template
Affects Versions: 4.3.0
 Environment: Latest Management server 4.3
Two zones one with Xen host and other with VmWare host
Reporter: Pavan Kumar Bandarupally
Priority: Critical
 Fix For: 4.3.0


Trying to download a template created from snapshot of root volume or template 
of root volume after migration of NFS to S3 store throws an error.

Job Trace:
== 

2014-01-07 22:07:44,221 DEBUG [c.c.a.ApiServlet] (catalina-exec-8:ctx-3c03896e) 
===START===  10.146.0.11 -- GET  
command=extractTemplatemode=HTTP_DOWNLOADid=3e35e5f4-9067-4c6e-ba15-3eb80494a6e8response=jsonsessionkey=BGTkrKxSTvEyZG7Nx4tTVof99Tw%3D_=1389093486904
2014-01-07 22:07:44,255 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(catalina-exec-8:ctx-3c03896e ctx-f274cea7) submit async job-89, details: 
AsyncJobVO {id:89, userId: 2, accountId: 2, instanceType: Template, instanceId: 
203, cmd: org.apache.cloudstack.api.command.user.template.ExtractTemplateCmd, 
cmdInfo: 
{response:json,id:3e35e5f4-9067-4c6e-ba15-3eb80494a6e8,sessionkey:BGTkrKxSTvEyZG7Nx4tTVof99Tw\u003d,cmdEventType:TEMPLATE.EXTRACT,ctxUserId:2,httpmethod:GET,_:1389093486904,ctxAccountId:2,ctxStartEventId:176,mode:HTTP_DOWNLOAD},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 7337246982268, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}
2014-01-07 22:07:44,258 DEBUG [c.c.a.ApiServlet] (catalina-exec-8:ctx-3c03896e 
ctx-f274cea7) ===END===  10.146.0.11 -- GET  
command=extractTemplatemode=HTTP_DOWNLOADid=3e35e5f4-9067-4c6e-ba15-3eb80494a6e8response=jsonsessionkey=BGTkrKxSTvEyZG7Nx4tTVof99Tw%3D_=1389093486904
2014-01-07 22:07:44,262 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(Job-Executor-37:ctx-b68520ba) Add job-89 into job monitoring
2014-01-07 22:07:44,262 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(Job-Executor-37:ctx-b68520ba) Executing AsyncJobVO {id:89, userId: 2, 
accountId: 2, instanceType: Template, instanceId: 203, cmd: 
org.apache.cloudstack.api.command.user.template.ExtractTemplateCmd, cmdInfo: 
{response:json,id:3e35e5f4-9067-4c6e-ba15-3eb80494a6e8,sessionkey:BGTkrKxSTvEyZG7Nx4tTVof99Tw\u003d,cmdEventType:TEMPLATE.EXTRACT,ctxUserId:2,httpmethod:GET,_:1389093486904,ctxAccountId:2,ctxStartEventId:176,mode:HTTP_DOWNLOAD},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 7337246982268, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}
2014-01-07 22:07:44,290 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl] 
(Job-Executor-37:ctx-b68520ba ctx-f274cea7) template 203 is already in store:3, 
type:Image
2014-01-07 22:07:44,300 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl] 
(Job-Executor-37:ctx-b68520ba ctx-f274cea7) template 203 is already in store:1, 
type:ImageCache
2014-01-07 22:07:44,302 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl] 
(Job-Executor-37:ctx-b68520ba ctx-f274cea7) template 203 is already in store:3, 
type:Image
2014-01-07 22:07:44,325 DEBUG [o.a.c.s.m.AncientDataMotionStrategy] 
(Job-Executor-37:ctx-b68520ba ctx-f274cea7) copyAsync inspecting src type 
TEMPLATE copyAsync inspecting dest type TEMPLATE
2014-01-07 22:07:44,371 DEBUG [c.c.a.t.Request] (Job-Executor-37:ctx-b68520ba 
ctx-f274cea7) Seq 3-242024639: Sending  { Cmd , MgmtId: 7337246982268, via: 
3(s-1-VM), Ver: v1, Flags: 100011, 
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/2/203/288329c8b-bb60-325f-8da8-b7e0e9764f99.ova,uuid:3e35e5f4-9067-4c6e-ba15-3eb80494a6e8,id:203,format:OVA,accountId:2,hvm:true,displayText:tmplt
 from root vol on Vmware 
before,imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.147.28.7/export/home/pavan/secondaryVmWareMZ,_role:ImageCache}},name:288329c8b-bb60-325f-8da8-b7e0e9764f99,hypervisorType:VMware}},destTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/2/203/288329c8b-bb60-325f-8da8-b7e0e9764f99,uuid:3e35e5f4-9067-4c6e-ba15-3eb80494a6e8,id:203,format:OVA,accountId:2,hvm:true,displayText:tmplt
 from root vol on Vmware 
before,imageDataStore:{com.cloud.agent.api.to.S3TO:{id:3,uuid:a2731bc7-33e4-42b2-9687-28626b315238,endPoint:10.147.29.56:8080,bucketName:pavanvmwmzbucket,httpsFlag:false,created:Jan
 7, 2014 9:26:21 
PM,enableRRS:false,maxSingleUploadSizeInBytes:5368709120}},name:288329c8b-bb60-325f-8da8-b7e0e9764f99,hypervisorType:VMware}},executeInSequence:false,options:{},wait:10800}}]
 }
2014-01-07 22:07:44,563 DEBUG

[jira] [Resolved] (CLOUDSTACK-999) Plugin to provide Hyper-V 2012 support

2014-01-07 Thread Donal Lafferty (JIRA)


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

Donal Lafferty resolved CLOUDSTACK-999.
---

Resolution: Fixed

Hyper-V plugin is available in the code base.

 Plugin to provide Hyper-V 2012 support
 --

 Key: CLOUDSTACK-999
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-999
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, Template, UI
Affects Versions: Future
 Environment: Hyper-V 2012 is available on releases of Windows 
 operating system from 2012 onwards.  E.g. Windows Server 2012, and Hyper-V 
 Server 2012.
 The plugin will execute at least in part on the CloudStack management server.
Reporter: Donal Lafferty
Assignee: Donal Lafferty
  Labels: Hyper-V, newbie
 Fix For: 4.3.0

 Attachments: Jessica_UI_change_1.PNG, Jessica_UI_change_2.PNG, 
 jessica_UI_change_3.jpg, jessica_hyperv_edit_traffic_type_of_guest.PNG, 
 jessica_hyperv_edit_traffic_type_of_management.PNG, 
 jessica_hyperv_edit_traffic_type_of_public.PNG


 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Hyper-V+2012+%283.0%29+Support
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Original+Feature+Spec
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/BootArgs+Support+for+Hyper-V+with+KVP+Data+Exchange
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/CIFS+Support
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Progress



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5113) [Automation] get_template function in command should return default templates


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864148#comment-13864148
 ] 

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

Commit 14ecb4f842e4ca1a030333f8688dfceaa1f47797 in branch refs/heads/4.3 from 
[~srikanti]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=14ecb4f ]

CLOUDSTACK-5113: Fix get_template method to return 'BUILTIN' template
by default


 [Automation] get_template function in command should return default 
 templates 
 

 Key: CLOUDSTACK-5113
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5113
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: marvin
Affects Versions: 4.2.1
 Environment: Automation
Reporter: Rayees Namathponnan
Assignee: Girish Shilamkar
 Fix For: 4.3.0


 I observed couple of vm deployment failures during automation runs;  test 
 cases trying to deploy with vm with template which already deleted by other 
 account 
 In below code  in common.py we are getting template 
 apiclient.listTemplates(cmd),   eg : 
 1)  testcase1 trying to deploy a new VM 
 2) Same time testcase 2 register a template (temp2)
 3) apiclient.listTemplates(cmd) will returns template ID (temp2) 
 4) testcase1 deploy vm wilt template temp2,  same time (testcase 2) may 
 delete its account, then obviously temp2 also gets deleted 
 5)  test case 1 deployment fails since temp2 no available 
 Solution 
 get_template() should return only default template; there is no property API 
 to list only default template; so we should find with starting name of 
 template ie CentOS and in test case we should not register template with 
 name CentOS 5.5
 def get_template(apiclient, zoneid, ostype, services=None):
 Returns a template
 cmd = listOsTypes.listOsTypesCmd()
 cmd.description = ostype
 ostypes = apiclient.listOsTypes(cmd)
 if isinstance(ostypes, list):
 ostypeid = ostypes[0].id
 else:
 raise Exception(
 Failed to find OS type with description: %s % ostype)
 cmd = listTemplates.listTemplatesCmd()
 cmd.templatefilter = 'featured'
 cmd.zoneid = zoneid
 if services:
 if template in services:
 cmd.id = services[template]
 list_templates = apiclient.listTemplates(cmd)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5113) [Automation] get_template function in command should return default templates

2014-01-07 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864150#comment-13864150
 ] 

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

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

CLOUDSTACK-5113: Fix get_template method to return 'BUILTIN' template
by default


 [Automation] get_template function in command should return default 
 templates 
 

 Key: CLOUDSTACK-5113
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5113
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: marvin
Affects Versions: 4.2.1
 Environment: Automation
Reporter: Rayees Namathponnan
Assignee: Girish Shilamkar
 Fix For: 4.3.0


 I observed couple of vm deployment failures during automation runs;  test 
 cases trying to deploy with vm with template which already deleted by other 
 account 
 In below code  in common.py we are getting template 
 apiclient.listTemplates(cmd),   eg : 
 1)  testcase1 trying to deploy a new VM 
 2) Same time testcase 2 register a template (temp2)
 3) apiclient.listTemplates(cmd) will returns template ID (temp2) 
 4) testcase1 deploy vm wilt template temp2,  same time (testcase 2) may 
 delete its account, then obviously temp2 also gets deleted 
 5)  test case 1 deployment fails since temp2 no available 
 Solution 
 get_template() should return only default template; there is no property API 
 to list only default template; so we should find with starting name of 
 template ie CentOS and in test case we should not register template with 
 name CentOS 5.5
 def get_template(apiclient, zoneid, ostype, services=None):
 Returns a template
 cmd = listOsTypes.listOsTypesCmd()
 cmd.description = ostype
 ostypes = apiclient.listOsTypes(cmd)
 if isinstance(ostypes, list):
 ostypeid = ostypes[0].id
 else:
 raise Exception(
 Failed to find OS type with description: %s % ostype)
 cmd = listTemplates.listTemplatesCmd()
 cmd.templatefilter = 'featured'
 cmd.zoneid = zoneid
 if services:
 if template in services:
 cmd.id = services[template]
 list_templates = apiclient.listTemplates(cmd)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5552) createPrivateGateway cmd should fail on non-upgarded VR as applying Network ACL fails.

2014-01-07 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864167#comment-13864167
 ] 

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

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

CLOUDSTACK-5552 fixed private gateway DB clean up on router upgrade required


 createPrivateGateway cmd should fail on non-upgarded VR as applying Network 
 ACL fails.
 --

 Key: CLOUDSTACK-5552
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5552
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Upgrade
Affects Versions: 4.3.0
 Environment: upgraded from ACS4.1 to Felton
Reporter: manasaveloori
Assignee: Jayapal Reddy
Priority: Critical
 Fix For: 4.3.0

 Attachments: management-server.log


 Steps:
 1. Upgraded the CS from ACS4.1 to Felton.
 2. On the non upgraded VPC VR,performed createPrivateGateway.
 Observation:
 The createPrivateGateway is created in UI/DB,but failing while applying 
 Network ACLs.
 When appying Network ACL fails on non upgarded VR,the DBentries for the 
 private gateway should be removed and createPrivate Gateway cmd should fail:
 2013-12-19 00:19:44,215 DEBUG [c.c.a.t.Request] (DirectAgent-61:ctx-629d0bd6) 
 Seq 1-2058690631: Processing:  { Ans: , MgmtId: 233845177509765, via: 1, Ver: 
 v1, Flags: 0, 
 [{com.cloud.agent.api.routing.SetNetworkACLAnswer:{results:[Failed,Failed],result:false,wait:0}}]
  }
 2013-12-19 00:19:44,215 DEBUG [c.c.a.t.Request] (Job-Executor-15:ctx-0e0cb77d 
 ctx-55536089) Seq 1-2058690631: Received:  { Ans: , MgmtId: 233845177509765, 
 via: 1, Ver: v1, Flags: 0, { SetNetworkACLAnswer } }
 2013-12-19 00:19:44,216 ERROR [c.c.a.ApiAsyncJobDispatcher] 
 (Job-Executor-15:ctx-0e0cb77d) Unexpected exception while executing 
 org.apache.cloudstack.api.command.admin.vpc.CreatePrivateGatewayCmd
 com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:2] is 
 unreachable: Unable to apply network acls on router
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:3735)
 at 
 com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.applyNetworkACLs(VpcVirtualNetworkApplianceManagerImpl.java:662)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:616)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at 
 org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
 at 
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
 at $Proxy240.applyNetworkACLs(Unknown Source)
 at 
 com.cloud.network.element.VpcVirtualRouterElement.applyACLItemsToPrivateGw(VpcVirtualRouterElement.java:473)
 at 
 com.cloud.network.vpc.NetworkACLManagerImpl.applyACLToPrivateGw(NetworkACLManagerImpl.java:385)
 at 
 com.cloud.network.vpc.NetworkACLManagerImpl.revokeACLItemsForPrivateGw(NetworkACLManagerImpl.java:344)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:616)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at 
 org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
 at

[jira] [Resolved] (CLOUDSTACK-5783) [vmware] Vcenter 5.5 host ESXi 5.5 VM created with host tag data vol migration options show hosts local storage not supported error

2014-01-07 Thread Likitha Shetty (JIRA)

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

Likitha Shetty resolved CLOUDSTACK-5783.

Resolution: Won't Fix

By design.

During volume migration, APIs invoked by UI to list the suitable storage pools
where the volume can be migrated to are-
1. If the volume is attached to a VM - findStoragePoolsForMigration API
2. If the volume is not attached to any VM - listStoragePools API

In case of a detached volume we don't use findStoragePoolsForMigration API
because findStoragePoolsForMigration uses the storage pool allocator to decide
the suitable pool for the volume to be migrated. The allocator in turn uses the
volume's associated VM information.

Since in case of a detached volume we don't have an associated VM we list *ALL*
the available pools in the zone and let the user pick the right one for
migration.

[vmware] Vcenter 5.5 host ESXi 5.5 VM created with host tag data vol
migration options show hosts local storage not supported error

Key: CLOUDSTACK-5783
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5783
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.3.0
Environment: MS build 1/2/2014
Vcenter 5.5host1host2 ESCi 5,5
Reporter: angeline shen
Assignee: Likitha Shetty
Priority: Critical
Fix For: 4.3.0

Attachments: management-server(1).log.gz, vm7.png, vm8.png

1. 2 cluster PS, zone-wide PS in zone. Service offering with host tag.
2. Deploy VM with host tag. DATA volume detach migrate vol list shows host
local storage select migrate
result:
volume migration fail :
migration of volume from shared to local storage pool is not supported

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Reopened] (CLOUDSTACK-5610) [Hyper-v] Host does not go into Alert state even though it is power-off hence vm deployment fails


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

Sanjeev N reopened CLOUDSTACK-5610:
---


This fix does not work if there are two hosts in the cluster and one host is in 
Maintenance mode.
I have tried following scenario and cs was unable to determine the status of 
the disconnected host.

1.Bring up CS with two hyper-v hosts in a cluster
2.Put one host (say host1) in maintenance mode
3.Simulate network disconnect by unplugging the network cable on the other 
host(say host2)
4.CS is unable to determine the state of host2 and it remains in UP state .

Following is the log snippet from MS log:

2014-01-07 18:29:09,003 DEBUG [c.c.h.AbstractInvestigatorImpl] 
(AgentTaskPool-11:ctx-05078172) host (10.147.40.14) cannot be pinged, returning 
null ('I don't know')
2014-01-07 18:29:09,003 DEBUG [c.c.h.UserVmDomRInvestigator] 
(AgentTaskPool-11:ctx-05078172) could not reach agent, could not reach agent's 
host, returning that we don't have enough information
2014-01-07 18:29:09,003 DEBUG [c.c.h.HighAvailabilityManagerImpl] 
(AgentTaskPool-11:ctx-05078172) PingInvestigator unable to determine the state 
of the host.  Moving on.
2014-01-07 18:29:09,003 DEBUG [c.c.h.HighAvailabilityManagerImpl] 
(AgentTaskPool-11:ctx-05078172) ManagementIPSysVMInvestigator unable to 
determine the state of the host.  Moving on.
2014-01-07 18:29:09,003 DEBUG [c.c.h.HighAvailabilityManagerImpl] 
(AgentTaskPool-11:ctx-05078172) KVMInvestigator unable to determine the state 
of the host.  Moving on.
2014-01-07 18:29:09,006 WARN  [c.c.a.m.AgentManagerImpl] 
(AgentTaskPool-11:ctx-05078172) Resource [Host:4] is unreachable: Host 4: 
Unable to send class com.cloud.agent.api.CheckOnHostCommand because agent 
10.147.40.31 is in maintenance mode
2014-01-07 18:29:09,006 DEBUG [c.c.h.HighAvailabilityManagerImpl] 
(AgentTaskPool-11:ctx-05078172) HypervInvestigator unable to determine the 
state of the host.  Moving on.
2014-01-07 18:29:09,006 DEBUG [c.c.h.HighAvailabilityManagerImpl] 
(AgentTaskPool-11:ctx-05078172) VMwareInvestigator unable to determine the 
state of the host.  Moving on.
2014-01-07 18:29:09,006 WARN  [c.c.a.m.AgentManagerImpl] 
(AgentTaskPool-11:ctx-05078172) Agent state cannot be determined, do nothing
2014-01-07 18:29:11,806 DEBUG [c.c.a.m.AgentAttache] 
(AgentTaskPool-6:ctx-268ddd2e) Seq 6-210567216: Waiting some more time because 
this is the current command
2014-01-07 18:29:11,807 DEBUG [c.c.a.m.AgentAttache] 
(AgentTaskPool-2:ctx-d7b3d598) Seq 7-327352402: Waiting some more time because 
this is the current command
2014-01-07 18:29:14,040 DEBUG [c.c.c.ConsoleProxyManagerImpl] 
(consoleproxy-1:ctx-60162ca0) Zone 1 is ready to launch console proxy
2014-01-07 18:29:14,179 DEBUG [c.c.s.s.SecondaryStorageManagerImpl] 
(secstorage-1:ctx-e954fb52) Zone 1 is ready to launch secondary storage VM
2014-01-07 18:29:19,874 ERROR [c.c.h.h.r.HypervDirectConnectResource] 
(DirectAgent-331:ctx-35463264) org.apache.http.conn.HttpHostConnectException: 
Connection to http://10.147.40.14:8250 refused
2014-01-07 18:29:19,874 DEBUG [c.c.a.m.DirectAgentAttache] 
(DirectAgent-331:ctx-35463264) Seq 1-820904008: Response Received:
2014-01-07 18:29:19,874 DEBUG [c.c.a.t.Request] (DirectAgent-331:ctx-35463264) 
Seq 1-820904008: Processing:  { Ans: , MgmtId: 132129494109518, via: 1, Ver: 
v1, Flags: 10, 
[{com.cloud.agent.api.UnsupportedAnswer:{result:false,details:Unsupported
 command issued:com.cloud.agent.api.GetHostStatsCommand.  Are you sure you got 
the right type of server?,wait:0}}] }
2014-01-07 18:29:19,874 DEBUG [c.c.a.t.Request] (StatsCollector-3:ctx-5e12f369) 
Seq 1-820904008: Received:  { Ans: , MgmtId: 132129494109518, via: 1, Ver: v1, 
Flags: 10, { UnsupportedAnswer } }
2014-01-07 18:29:19,874 WARN  [c.c.a.m.AgentManagerImpl] 
(StatsCollector-3:ctx-5e12f369) Unsupported Command: Unsupported command 
issued:com.cloud.agent.api.GetHostStatsCommand.  Are you sure you got the right 
type of server?
2014-01-07 18:29:19,875 DEBUG [c.c.a.m.AgentManagerImpl] 
(StatsCollector-3:ctx-5e12f369) Details from executing class 
com.cloud.agent.api.GetHostStatsCommand: Unsupported command 
issued:com.cloud.agent.api.GetHostStatsCommand.  Are you sure you got the right 
type of server?
2014-01-07 18:29:19,875 WARN  [c.c.s.StatsCollector] 
(StatsCollector-3:ctx-5e12f369) Received invalid host stats for host: 1


 [Hyper-v] Host does not go into Alert state even though it is power-off hence 
 vm deployment fails
 -

 Key: CLOUDSTACK-5610
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5610
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller, Management Server
Affects

[jira] [Updated] (CLOUDSTACK-5610) [Hyper-v] Host does not go into Alert state even though it is power-off hence vm deployment fails


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

Sanjeev N updated CLOUDSTACK-5610:
--

Attachment: management-server.rar

Attached latest MS log file.

 [Hyper-v] Host does not go into Alert state even though it is power-off hence 
 vm deployment fails
 -

 Key: CLOUDSTACK-5610
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5610
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller, Management Server
Affects Versions: 4.3.0
 Environment: Latest build from 4.3 with commit 
 :d462db4ae5c30e677d5810111f9ea5ca6812bce2
 Storage: SMB for both primary and secondary
 Hypervisor: Hyper-v
Reporter: Sanjeev N
Assignee: Devdeep Singh
Priority: Blocker
  Labels: hyper-V,
 Fix For: 4.3.0

 Attachments: cloud.dmp, management-server.rar, management-server.rar


 [Hyper-v] Host does not go into Alert state even though it is power-off hence 
 vm deployment fails
 Steps to Reproduce:
 =
 1.Bring up CS in advanced zone with with 2 or more Hyper-v hosts using SMB 
 for both primary and secondary
 2.Enable the zone and deploy few vms. Make sure that vms are distributed 
 across all the hosts
 3.Power off one of the hosts(Power off the hosts where vms are running)
 Expected Result:
 ==
 Host should go into Alert state and all the vms running on it should be 
 stopped
 Actual Result:
 
 Host remains in Up state and all the vms state show as running.
 I could see the ping commands to Hypervsior aget, system vm agents in the MS 
 log. Even though the agents are behind ping, agent status remains in UP state.
 At this state , I have tried to deploy a vm and deployment planner chose the 
 host which was powered off . Hence the vm deployment failed.
 Also CPVM was running on the powered off host. That also remained in running 
 state. Since cpvm agent is not reachable from CS it should have been stopped 
 and started on another Host in the cluster.
 2013-12-23 18:19:25,334 ERROR [c.c.h.h.r.HypervDirectConnectResource] 
 (DirectAgent-331:ctx-831c60e9) org.apache.http.conn.HttpHostConnectException: 
 Connection to http://10.147.40.31:8250 refused
 2013-12-23 18:19:25,334 INFO  [c.c.h.h.r.HypervDirectConnectResource] 
 (DirectAgent-331:ctx-831c60e9) Cannot ping host 10.147.40.31 (IP 
 10.147.40.31), pingAns (blank means null) 
 is:com.cloud.agent.api.UnsupportedAnswer
 2013-12-23 18:19:25,334 WARN  [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-331:ctx-831c60e9) Unable to get current status on 5(10.147.40.31)
 2013-12-23 18:19:25,336 INFO  [c.c.a.m.AgentManagerImpl] 
 (AgentTaskPool-16:ctx-be3804c7) Investigating why host 5 has disconnected 
 with event AgentDisconnected
 2013-12-23 18:19:25,336 DEBUG [c.c.a.m.AgentManagerImpl] 
 (AgentTaskPool-16:ctx-be3804c7) checking if agent (5) is alive
 2013-12-23 18:19:25,339 DEBUG [c.c.a.t.Request] 
 (AgentTaskPool-16:ctx-be3804c7) Seq 5-1482556239: Sending  { Cmd , MgmtId: 
 132129494109518, via: 5(10.147.40.31), Ver: v1, Flags: 100011, 
 [{com.cloud.agent.api.CheckHealthCommand:{wait:50}}] }
 2013-12-23 18:19:25,339 DEBUG [c.c.a.t.Request] 
 (AgentTaskPool-16:ctx-be3804c7) Seq 5-1482556239: Executing:  { Cmd , MgmtId: 
 132129494109518, via: 5(10.147.40.31), Ver: v1, Flags: 100011, 
 [{com.cloud.agent.api.CheckHealthCommand:{wait:50}}] }
 2013-12-23 18:19:25,339 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-325:ctx-39f5ed39) Seq 5-1482556239: Executing request
 2013-12-23 18:19:25,339 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
 (DirectAgent-325:ctx-39f5ed39) POST request 
 tohttp://10.147.40.31:8250/api/HypervResource/com.cloud.agent.api.CheckHealthCommand
  with contents{contextMap:{},wait:50}
 2013-12-23 18:19:25,340 DEBUG [c.c.h.h.r.HypervDirectConnectResource] 
 (DirectAgent-325:ctx-39f5ed39) Sending cmd to 
 http://10.147.40.31:8250/api/HypervResource/com.cloud.agent.api.CheckHealthCommand
  cmd data:{contextMap:{},wait:50}
 2013-12-23 18:19:46,345 DEBUG [c.c.h.UserVmDomRInvestigator] 
 (AgentTaskPool-16:ctx-be3804c7) checking if agent (5) is alive
 2013-12-23 18:19:46,347 DEBUG [c.c.h.UserVmDomRInvestigator] 
 (AgentTaskPool-16:ctx-be3804c7) sending ping from (1) to agent's host ip 
 address (10.147.40.31)
 2013-12-23 18:19:46,349 DEBUG [c.c.a.t.Request] 
 (AgentTaskPool-16:ctx-be3804c7) Seq 1-790364876: Sending  { Cmd , MgmtId: 
 132129494109518, via: 1(10.147.40.14), Ver: v1, Flags: 100011, 
 [{com.cloud.agent.api.PingTestCommand:{_computingHostIp:10.147.40.31,wait:20}}]
  }
 2013-12-23 18:19:46,349 DEBUG [c.c.a.t.Request] 
 (AgentTaskPool-16:ctx-be3804c7) Seq 1-790364876:

[jira] [Commented] (CLOUDSTACK-5818) [Hyper-v]Agent status of the System VMs is not updated during Host disconnect

2014-01-07 Thread Rajesh Battala (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864231#comment-13864231
 ] 

Rajesh Battala commented on CLOUDSTACK-5818:


mgmt server is not checking the status of the systemvm service.
I mean its not hypervisor dependent.

 [Hyper-v]Agent status of the System VMs is not updated during Host disconnect
 -

 Key: CLOUDSTACK-5818
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5818
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller
Affects Versions: 4.3.0
 Environment: Latest build from 4.3branch with 
 commit:6f309b8a87d3376950a60234d399c6e3749ad1c7
Reporter: Sanjeev N
Priority: Critical
  Labels: hyper-V,, hyper-v, hyperv
 Fix For: 4.3.0

 Attachments: management-server.rar


 [Hyper-v]Agent status of the System VMs is not updated during Host disconnect.
 Steps to Reproduce:
 
 1.Bring up CS in advanced zone with hyper-v cluster and with SMB for both 
 primary and secondary
 2.Wait for the system vms to come up
 3.Simulate host disconnect by unplugging the network cable.
 4.I see host status changing to Down but the agent status of the system vms 
 remained Up 
 Impact:
 ==
 All the operations involving SSVM and CPVM are failing since the host is down.
 So user is blocked to perform following things:
 1.Download/Register/copy template
 2.Upload/Download volume
 3.Console access



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CLOUDSTACK-5783) Detached data vol migration options show hosts local storage not supported error

2014-01-07 Thread Likitha Shetty (JIRA)


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

Likitha Shetty updated CLOUDSTACK-5783:
---

Summary: Detached data vol migration options show hosts local storage not 
supported  error   (was: [vmware] Vcenter 5.5  host ESXi 5.5 VM created with 
host tag data vol migration options show hosts local storage not supported  
error )

 Detached data vol migration options show hosts local storage not supported  
 error 
 ---

 Key: CLOUDSTACK-5783
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5783
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
 Environment: MS   build   1/2/2014
 Vcenter 5.5host1host2   ESCi 5,5
Reporter: angeline shen
Assignee: Likitha Shetty
Priority: Critical
 Fix For: 4.3.0

 Attachments: management-server(1).log.gz, vm7.png, vm8.png


 1. 2 cluster PS, zone-wide PS in zone. Service offering with host tag.
 2. Deploy VM with host tag. DATA volume  detach migrate vol list shows host 
 local storage select  migrate
 result:
 volume migration fail :
 migration of volume from shared to local storage pool is not supported



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-5820) [Automation] SSH to portable public IP fails

2014-01-07 Thread Gaurav Aradhye (JIRA)

Gaurav Aradhye created CLOUDSTACK-5820:
--

 Summary: [Automation] SSH to portable public IP fails
 Key: CLOUDSTACK-5820
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5820
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Controller
Affects Versions: 4.3.0
 Environment: Observed on KVM and Xen, yet to check on VMware
Reporter: Gaurav Aradhye
 Fix For: 4.3.0


Steps to reproduce:

1. Deploy a VM in isolated network
2. Acquire portable IP for the network
3. Create NAT rule for portable IP associating deployed VM
4. Try to SSH to the VM using the portable IP

SSH fails.

Same above steps for a non portable ip work fine for SSH.

Please let me know which additional info you require. I don't think management 
server logs will help in this case. Let me know if you want to see any iptables.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Assigned] (CLOUDSTACK-5799) Foreign characters not accepted


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

Alexander Hitchins reassigned CLOUDSTACK-5799:
--

Assignee: Alexander Hitchins

 Foreign characters not accepted
 ---

 Key: CLOUDSTACK-5799
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5799
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.1
Reporter: Jan-Arve Nygård
Assignee: Alexander Hitchins
Priority: Minor

 Norwegian characters (f.ex æøå) are not accepted as a part of the name 
 (firstname and lastname) when creating a user. 
 This issue did not exist in CloudStack 3.x. I don't think this is by design, 
 but if that's the case there should be something in the UI giving error when 
 trying to use foreign/unsupported characters.
 Here's the error message when trying to create a user:
 2014-01-06 14:34:50,582 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null) 
 ===START===  172.30.86.24 -- POST  
 command=createAccountresponse=jsonsessionkey=grfZR4pMZgwQ204rdEwdXPVxhJw%3D
 2014-01-06 14:34:50,597 INFO  [cloud.api.ApiServer] (catalina-exec-25:null) 
 Received value KÃ¦r for parameter lastname is invalid, contains illegal ASCII 
 non-printable characters
 2014-01-06 14:34:50,598 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null) 
 ===END===  172.30.86.24 -- POST  
 command=createAccountresponse=jsonsessionkey=grfZR4pMZgwQ204rdEwdXPVxhJw%3D



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5799) Foreign characters not accepted


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864321#comment-13864321
 ] 

Alexander Hitchins commented on CLOUDSTACK-5799:


Please could you post here the unicode character numbers for the failing 
characters?

 Foreign characters not accepted
 ---

 Key: CLOUDSTACK-5799
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5799
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.1
Reporter: Jan-Arve Nygård
Assignee: Alexander Hitchins
Priority: Minor

 Norwegian characters (f.ex æøå) are not accepted as a part of the name 
 (firstname and lastname) when creating a user. 
 This issue did not exist in CloudStack 3.x. I don't think this is by design, 
 but if that's the case there should be something in the UI giving error when 
 trying to use foreign/unsupported characters.
 Here's the error message when trying to create a user:
 2014-01-06 14:34:50,582 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null) 
 ===START===  172.30.86.24 -- POST  
 command=createAccountresponse=jsonsessionkey=grfZR4pMZgwQ204rdEwdXPVxhJw%3D
 2014-01-06 14:34:50,597 INFO  [cloud.api.ApiServer] (catalina-exec-25:null) 
 Received value KÃ¦r for parameter lastname is invalid, contains illegal ASCII 
 non-printable characters
 2014-01-06 14:34:50,598 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null) 
 ===END===  172.30.86.24 -- POST  
 command=createAccountresponse=jsonsessionkey=grfZR4pMZgwQ204rdEwdXPVxhJw%3D



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-5821) systemvmiso is locked by systevmvm in hyperv

2014-01-07 Thread Rajesh Battala (JIRA)

Rajesh Battala created CLOUDSTACK-5821:
--

 Summary: systemvmiso is locked by systevmvm in hyperv
 Key: CLOUDSTACK-5821
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5821
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Hypervisor Controller
Affects Versions: 4.3.0
Reporter: Rajesh Battala
Assignee: Rajesh Battala
 Fix For: 4.3.0






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5799) Foreign characters not accepted


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864325#comment-13864325
 ] 

Alexander Hitchins commented on CLOUDSTACK-5799:


Thank you Jan-Arve

 Foreign characters not accepted
 ---

 Key: CLOUDSTACK-5799
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5799
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.1
Reporter: Jan-Arve Nygård
Assignee: Alexander Hitchins
Priority: Minor

 Norwegian characters (f.ex æøå) are not accepted as a part of the name 
 (firstname and lastname) when creating a user. 
 This issue did not exist in CloudStack 3.x. I don't think this is by design, 
 but if that's the case there should be something in the UI giving error when 
 trying to use foreign/unsupported characters.
 Here's the error message when trying to create a user:
 2014-01-06 14:34:50,582 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null) 
 ===START===  172.30.86.24 -- POST  
 command=createAccountresponse=jsonsessionkey=grfZR4pMZgwQ204rdEwdXPVxhJw%3D
 2014-01-06 14:34:50,597 INFO  [cloud.api.ApiServer] (catalina-exec-25:null) 
 Received value KÃ¦r for parameter lastname is invalid, contains illegal ASCII 
 non-printable characters
 2014-01-06 14:34:50,598 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null) 
 ===END===  172.30.86.24 -- POST  
 command=createAccountresponse=jsonsessionkey=grfZR4pMZgwQ204rdEwdXPVxhJw%3D



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5799) Foreign characters not accepted

2014-01-07 Thread JIRA


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864323#comment-13864323
 ] 

Jan-Arve Nygård commented on CLOUDSTACK-5799:
-

Two examples we tested are:

U+00E5
U+00E6

The last one is the character in this spesific log.

 Foreign characters not accepted
 ---

 Key: CLOUDSTACK-5799
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5799
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.1
Reporter: Jan-Arve Nygård
Assignee: Alexander Hitchins
Priority: Minor

 Norwegian characters (f.ex æøå) are not accepted as a part of the name 
 (firstname and lastname) when creating a user. 
 This issue did not exist in CloudStack 3.x. I don't think this is by design, 
 but if that's the case there should be something in the UI giving error when 
 trying to use foreign/unsupported characters.
 Here's the error message when trying to create a user:
 2014-01-06 14:34:50,582 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null) 
 ===START===  172.30.86.24 -- POST  
 command=createAccountresponse=jsonsessionkey=grfZR4pMZgwQ204rdEwdXPVxhJw%3D
 2014-01-06 14:34:50,597 INFO  [cloud.api.ApiServer] (catalina-exec-25:null) 
 Received value KÃ¦r for parameter lastname is invalid, contains illegal ASCII 
 non-printable characters
 2014-01-06 14:34:50,598 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null) 
 ===END===  172.30.86.24 -- POST  
 command=createAccountresponse=jsonsessionkey=grfZR4pMZgwQ204rdEwdXPVxhJw%3D



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5799) Foreign characters not accepted


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864324#comment-13864324
 ] 

Alexander Hitchins commented on CLOUDSTACK-5799:


Seems a suitable match.

 Foreign characters not accepted
 ---

 Key: CLOUDSTACK-5799
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5799
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.1
Reporter: Jan-Arve Nygård
Assignee: Alexander Hitchins
Priority: Minor

 Norwegian characters (f.ex æøå) are not accepted as a part of the name 
 (firstname and lastname) when creating a user. 
 This issue did not exist in CloudStack 3.x. I don't think this is by design, 
 but if that's the case there should be something in the UI giving error when 
 trying to use foreign/unsupported characters.
 Here's the error message when trying to create a user:
 2014-01-06 14:34:50,582 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null) 
 ===START===  172.30.86.24 -- POST  
 command=createAccountresponse=jsonsessionkey=grfZR4pMZgwQ204rdEwdXPVxhJw%3D
 2014-01-06 14:34:50,597 INFO  [cloud.api.ApiServer] (catalina-exec-25:null) 
 Received value KÃ¦r for parameter lastname is invalid, contains illegal ASCII 
 non-printable characters
 2014-01-06 14:34:50,598 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null) 
 ===END===  172.30.86.24 -- POST  
 command=createAccountresponse=jsonsessionkey=grfZR4pMZgwQ204rdEwdXPVxhJw%3D



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Assigned] (CLOUDSTACK-5630) [Automation]snapshot tests are failing

2014-01-07 Thread Gaurav Aradhye (JIRA)


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

Gaurav Aradhye reassigned CLOUDSTACK-5630:
--

Assignee: Gaurav Aradhye  (was: Chandan Purushothama)

 [Automation]snapshot tests are failing
 --

 Key: CLOUDSTACK-5630
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5630
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.3.0
 Environment: xenserver 62
 advanced zone
Reporter: Srikanteswararao Talluri
Assignee: Gaurav Aradhye
 Fix For: 4.3.0


 Creating this bug as a place holder for the following failures, needs further 
 analysis, 
 test_03_snapshots_per_account FAILED  Check Snapshot state is Running or not
 test_03_snapshots_per_domain  FAILED  Check Snapshot state is Running or not
 test_02_accountSnapshotClean  FAILED  Snapshot was not found on NFS
 test_04_snapshot_limitFAILED  False is not True
 test_01_createVM_snapshotTemplate FAILED  False is not True
 test_02_snapshot_data_diskFAILED  False is not True



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-5822) ssh keypairs are removed after rebooting vm

2014-01-07 Thread Wei Zhou (JIRA)

Wei Zhou created CLOUDSTACK-5822:


 Summary: ssh keypairs are removed after rebooting vm
 Key: CLOUDSTACK-5822
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5822
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.3.0
Reporter: Wei Zhou


For a ssh keypair-enabled vm, the keys in /root/.ssh/authorized_keys will be 
reset after rebooting the vm. Only the keypair specified in cloudstack will be 
added. We should keep the keypairs added by users.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Assigned] (CLOUDSTACK-5819) extractTemplate fails with Vmware host on migration of NFS to S3


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

Min Chen reassigned CLOUDSTACK-5819:


Assignee: Min Chen

 extractTemplate fails with Vmware host on migration of NFS to S3
 

 Key: CLOUDSTACK-5819
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5819
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Template
Affects Versions: 4.3.0
 Environment: Latest Management server 4.3
 Two zones one with Xen host and other with VmWare host
Reporter: Pavan Kumar Bandarupally
Assignee: Min Chen
Priority: Critical
 Fix For: 4.3.0


 Trying to download a template created from snapshot of root volume or 
 template of root volume after migration of NFS to S3 store throws an error.
 Job Trace:
 == 
 2014-01-07 22:07:44,221 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-8:ctx-3c03896e) ===START===  10.146.0.11 -- GET  
 command=extractTemplatemode=HTTP_DOWNLOADid=3e35e5f4-9067-4c6e-ba15-3eb80494a6e8response=jsonsessionkey=BGTkrKxSTvEyZG7Nx4tTVof99Tw%3D_=1389093486904
 2014-01-07 22:07:44,255 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (catalina-exec-8:ctx-3c03896e ctx-f274cea7) submit async job-89, details: 
 AsyncJobVO {id:89, userId: 2, accountId: 2, instanceType: Template, 
 instanceId: 203, cmd: 
 org.apache.cloudstack.api.command.user.template.ExtractTemplateCmd, cmdInfo: 
 {response:json,id:3e35e5f4-9067-4c6e-ba15-3eb80494a6e8,sessionkey:BGTkrKxSTvEyZG7Nx4tTVof99Tw\u003d,cmdEventType:TEMPLATE.EXTRACT,ctxUserId:2,httpmethod:GET,_:1389093486904,ctxAccountId:2,ctxStartEventId:176,mode:HTTP_DOWNLOAD},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 7337246982268, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-01-07 22:07:44,258 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-8:ctx-3c03896e ctx-f274cea7) ===END===  10.146.0.11 -- GET  
 command=extractTemplatemode=HTTP_DOWNLOADid=3e35e5f4-9067-4c6e-ba15-3eb80494a6e8response=jsonsessionkey=BGTkrKxSTvEyZG7Nx4tTVof99Tw%3D_=1389093486904
 2014-01-07 22:07:44,262 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
 (Job-Executor-37:ctx-b68520ba) Add job-89 into job monitoring
 2014-01-07 22:07:44,262 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (Job-Executor-37:ctx-b68520ba) Executing AsyncJobVO {id:89, userId: 2, 
 accountId: 2, instanceType: Template, instanceId: 203, cmd: 
 org.apache.cloudstack.api.command.user.template.ExtractTemplateCmd, cmdInfo: 
 {response:json,id:3e35e5f4-9067-4c6e-ba15-3eb80494a6e8,sessionkey:BGTkrKxSTvEyZG7Nx4tTVof99Tw\u003d,cmdEventType:TEMPLATE.EXTRACT,ctxUserId:2,httpmethod:GET,_:1389093486904,ctxAccountId:2,ctxStartEventId:176,mode:HTTP_DOWNLOAD},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 7337246982268, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-01-07 22:07:44,290 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl] 
 (Job-Executor-37:ctx-b68520ba ctx-f274cea7) template 203 is already in 
 store:3, type:Image
 2014-01-07 22:07:44,300 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl] 
 (Job-Executor-37:ctx-b68520ba ctx-f274cea7) template 203 is already in 
 store:1, type:ImageCache
 2014-01-07 22:07:44,302 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl] 
 (Job-Executor-37:ctx-b68520ba ctx-f274cea7) template 203 is already in 
 store:3, type:Image
 2014-01-07 22:07:44,325 DEBUG [o.a.c.s.m.AncientDataMotionStrategy] 
 (Job-Executor-37:ctx-b68520ba ctx-f274cea7) copyAsync inspecting src type 
 TEMPLATE copyAsync inspecting dest type TEMPLATE
 2014-01-07 22:07:44,371 DEBUG [c.c.a.t.Request] (Job-Executor-37:ctx-b68520ba 
 ctx-f274cea7) Seq 3-242024639: Sending  { Cmd , MgmtId: 7337246982268, via: 
 3(s-1-VM), Ver: v1, Flags: 100011, 
 [{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/2/203/288329c8b-bb60-325f-8da8-b7e0e9764f99.ova,uuid:3e35e5f4-9067-4c6e-ba15-3eb80494a6e8,id:203,format:OVA,accountId:2,hvm:true,displayText:tmplt
  from root vol on Vmware 
 before,imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.147.28.7/export/home/pavan/secondaryVmWareMZ,_role:ImageCache}},name:288329c8b-bb60-325f-8da8-b7e0e9764f99,hypervisorType:VMware}},destTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/2/203/288329c8b-bb60-325f-8da8-b7e0e9764f99,uuid:3e35e5f4-9067-4c6e-ba15-3eb80494a6e8,id:203,format:OVA,accountId:2,hvm:true,displayText:tmplt
  from root vol on Vmware

[jira] [Commented] (CLOUDSTACK-5819) extractTemplate fails with Vmware host on migration of NFS to S3


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864407#comment-13864407
 ] 

Min Chen commented on CLOUDSTACK-5819:
--

For all NFS to S3 migration related bugs, please attach data dump before 
migration and data dump after migration for investigation. 

 extractTemplate fails with Vmware host on migration of NFS to S3
 

 Key: CLOUDSTACK-5819
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5819
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Template
Affects Versions: 4.3.0
 Environment: Latest Management server 4.3
 Two zones one with Xen host and other with VmWare host
Reporter: Pavan Kumar Bandarupally
Assignee: Min Chen
Priority: Critical
 Fix For: 4.3.0


 Trying to download a template created from snapshot of root volume or 
 template of root volume after migration of NFS to S3 store throws an error.
 Job Trace:
 == 
 2014-01-07 22:07:44,221 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-8:ctx-3c03896e) ===START===  10.146.0.11 -- GET  
 command=extractTemplatemode=HTTP_DOWNLOADid=3e35e5f4-9067-4c6e-ba15-3eb80494a6e8response=jsonsessionkey=BGTkrKxSTvEyZG7Nx4tTVof99Tw%3D_=1389093486904
 2014-01-07 22:07:44,255 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (catalina-exec-8:ctx-3c03896e ctx-f274cea7) submit async job-89, details: 
 AsyncJobVO {id:89, userId: 2, accountId: 2, instanceType: Template, 
 instanceId: 203, cmd: 
 org.apache.cloudstack.api.command.user.template.ExtractTemplateCmd, cmdInfo: 
 {response:json,id:3e35e5f4-9067-4c6e-ba15-3eb80494a6e8,sessionkey:BGTkrKxSTvEyZG7Nx4tTVof99Tw\u003d,cmdEventType:TEMPLATE.EXTRACT,ctxUserId:2,httpmethod:GET,_:1389093486904,ctxAccountId:2,ctxStartEventId:176,mode:HTTP_DOWNLOAD},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 7337246982268, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-01-07 22:07:44,258 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-8:ctx-3c03896e ctx-f274cea7) ===END===  10.146.0.11 -- GET  
 command=extractTemplatemode=HTTP_DOWNLOADid=3e35e5f4-9067-4c6e-ba15-3eb80494a6e8response=jsonsessionkey=BGTkrKxSTvEyZG7Nx4tTVof99Tw%3D_=1389093486904
 2014-01-07 22:07:44,262 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
 (Job-Executor-37:ctx-b68520ba) Add job-89 into job monitoring
 2014-01-07 22:07:44,262 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (Job-Executor-37:ctx-b68520ba) Executing AsyncJobVO {id:89, userId: 2, 
 accountId: 2, instanceType: Template, instanceId: 203, cmd: 
 org.apache.cloudstack.api.command.user.template.ExtractTemplateCmd, cmdInfo: 
 {response:json,id:3e35e5f4-9067-4c6e-ba15-3eb80494a6e8,sessionkey:BGTkrKxSTvEyZG7Nx4tTVof99Tw\u003d,cmdEventType:TEMPLATE.EXTRACT,ctxUserId:2,httpmethod:GET,_:1389093486904,ctxAccountId:2,ctxStartEventId:176,mode:HTTP_DOWNLOAD},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 7337246982268, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-01-07 22:07:44,290 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl] 
 (Job-Executor-37:ctx-b68520ba ctx-f274cea7) template 203 is already in 
 store:3, type:Image
 2014-01-07 22:07:44,300 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl] 
 (Job-Executor-37:ctx-b68520ba ctx-f274cea7) template 203 is already in 
 store:1, type:ImageCache
 2014-01-07 22:07:44,302 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl] 
 (Job-Executor-37:ctx-b68520ba ctx-f274cea7) template 203 is already in 
 store:3, type:Image
 2014-01-07 22:07:44,325 DEBUG [o.a.c.s.m.AncientDataMotionStrategy] 
 (Job-Executor-37:ctx-b68520ba ctx-f274cea7) copyAsync inspecting src type 
 TEMPLATE copyAsync inspecting dest type TEMPLATE
 2014-01-07 22:07:44,371 DEBUG [c.c.a.t.Request] (Job-Executor-37:ctx-b68520ba 
 ctx-f274cea7) Seq 3-242024639: Sending  { Cmd , MgmtId: 7337246982268, via: 
 3(s-1-VM), Ver: v1, Flags: 100011, 
 [{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/2/203/288329c8b-bb60-325f-8da8-b7e0e9764f99.ova,uuid:3e35e5f4-9067-4c6e-ba15-3eb80494a6e8,id:203,format:OVA,accountId:2,hvm:true,displayText:tmplt
  from root vol on Vmware 
 before,imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.147.28.7/export/home/pavan/secondaryVmWareMZ,_role:ImageCache}},name:288329c8b-bb60-325f-8da8-b7e0e9764f99,hypervisorType:VMware}},destTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/2/203/288329c8b-bb60-325f-8da8-b7e0e9764f99,uuid:3e35e5f4-9067-4c6e-ba15-3eb80494a6e8,id:203,format:OVA,accountId:2,hvm:true,displayText:tmplt
  from root vol on

[jira] [Assigned] (CLOUDSTACK-5823) Taking a VMware snapshot doesn't work


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

Mike Tutkowski reassigned CLOUDSTACK-5823:
--

Assignee: Mike Tutkowski

 Taking a VMware snapshot doesn't work
 -

 Key: CLOUDSTACK-5823
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5823
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: VMware
Affects Versions: 4.3.0
 Environment: ESXi 5.1
Reporter: Mike Tutkowski
Assignee: Mike Tutkowski
 Fix For: 4.3.0


 Per a discussion on the mailing list:
 VMware snapshot question
 Mike Tutkowski mike.tutkow...@solidfire.com
 4:10 PM (18 hours ago)
 to dev 
 Hi,
 I was wondering about the following code in VmwareStorageManagerImpl. It is 
 in the CreateVMSnapshotAnswer execute(VmwareHostService hostService, 
 CreateVMSnapshotCommand cmd) method.
 The part I wonder about is in populating the mapNewDisk map. For disks like 
 the following:
 i-2-9-VM/fksjfaklsjdgflajs.vmdk, the key for the map ends up being i-2.
 When we call this:
 String baseName = extractSnapshotBaseFileName(volumeTO.getPath());
 It uses a path such as the following:
 fksjfaklsjdgflajs
 There is no i-2-9-VM/ preceding the name, so the key we search on ends up 
 being the following:
 fksjfaklsjdgflajs
 This leads to a newPath being equal to null.
 As it turns out, I believe null is actually correct, but - if that's the case 
 - why do we have all this logic if - in the end - we are just going to assign 
 null to newPath in every case when creating a VM snapshot for VMware? As it 
 turns out, null is later interpreted to mean, don't replace the path field 
 of this volume in the volumes table, which is, I think, what we want.
 Thanks!
 VirtualDisk[] vdisks = vmMo.getAllDiskDevice();
 for (int i = 0; i  vdisks.length; i ++){
 ListPairString, ManagedObjectReference vmdkFiles = 
 vmMo.getDiskDatastorePathChain(vdisks[i], false);
 for(PairString, ManagedObjectReference fileItem : 
 vmdkFiles) {
 String vmdkName = fileItem.first().split( )[1];
 if (vmdkName.endsWith(.vmdk)){
 vmdkName = vmdkName.substring(0, 
 vmdkName.length() - (.vmdk).length());
 }
 String baseName = 
 extractSnapshotBaseFileName(vmdkName);
 mapNewDisk.put(baseName, vmdkName);
 }
 }
 for (VolumeObjectTO volumeTO : volumeTOs) {
 String baseName = 
 extractSnapshotBaseFileName(volumeTO.getPath());
 String newPath = mapNewDisk.get(baseName);
 // get volume's chain size for this VM snapshot, exclude 
 current volume vdisk
 DataStoreTO store = volumeTO.getDataStore();
 long size = 
 getVMSnapshotChainSize(context,hyperHost,baseName + *.vmdk,
 store.getUuid(), newPath);
 if(volumeTO.getVolumeType()== Volume.Type.ROOT){
 // add memory snapshot size
 size = size + 
 getVMSnapshotChainSize(context,hyperHost,cmd.getVmName()+*.vmsn,store.getUuid(),null);
 }
 volumeTO.setSize(size);
 volumeTO.setPath(newPath);
 }
 Mike Tutkowski mike.tutkow...@solidfire.com
 4:35 PM (17 hours ago)
 to dev 
 In short, I believe we can remove mapNewDisk and just assign null to newPath. 
 This will keep the existing path for the volume in question (in the volumes 
 table) in the same state as it was before we created a VMware snapshot, which 
 I believe is the intent anyways.
 Thoughts on that?
 Mike Tutkowski mike.tutkow...@solidfire.com
 6:33 PM (15 hours ago)
 to Kelven, dev 
 Actually, the more I look at this code, the more I think perhaps VMware 
 snapshots are broken because the newPath field should probably not be 
 assigned null after creating a new VMware snapshot (I'm thinking the intend 
 is to replace the other path with a new path that refers to the delta file 
 that was just created).
 Does anyone know who worked on VMware snapshots? I've love to ask these 
 questions to him soon as we are approaching the end of 4.3.
 Thanks!
 Kelven Yang   10:02 PM (12 hours ago)
 Yes, your guess is correct, the intent to update with a new path is to 
 reflec...
 Mike Tutkowski mike.tutkow...@solidfire.com
 10:13 PM (12 hours ago)
 to dev, Kelven 
 Thanks for the info, Kelven.
 I believe we have a serious bug then as null is being assigned to newPath 
 when a VMware snapshot is being taken (this is in 4.3, by the way).

[jira] [Created] (CLOUDSTACK-5823) Taking a VMware snapshot doesn't work

Mike Tutkowski created CLOUDSTACK-5823:
--

 Summary: Taking a VMware snapshot doesn't work
 Key: CLOUDSTACK-5823
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5823
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: VMware
Affects Versions: 4.3.0
 Environment: ESXi 5.1
Reporter: Mike Tutkowski
 Fix For: 4.3.0


Per a discussion on the mailing list:

VMware snapshot question

Mike Tutkowski mike.tutkow...@solidfire.com
4:10 PM (18 hours ago)

to dev 
Hi,

I was wondering about the following code in VmwareStorageManagerImpl. It is in 
the CreateVMSnapshotAnswer execute(VmwareHostService hostService, 
CreateVMSnapshotCommand cmd) method.

The part I wonder about is in populating the mapNewDisk map. For disks like the 
following:

i-2-9-VM/fksjfaklsjdgflajs.vmdk, the key for the map ends up being i-2.

When we call this:

String baseName = extractSnapshotBaseFileName(volumeTO.getPath());

It uses a path such as the following:

fksjfaklsjdgflajs

There is no i-2-9-VM/ preceding the name, so the key we search on ends up being 
the following:

fksjfaklsjdgflajs

This leads to a newPath being equal to null.

As it turns out, I believe null is actually correct, but - if that's the case - 
why do we have all this logic if - in the end - we are just going to assign 
null to newPath in every case when creating a VM snapshot for VMware? As it 
turns out, null is later interpreted to mean, don't replace the path field of 
this volume in the volumes table, which is, I think, what we want.

Thanks!
VirtualDisk[] vdisks = vmMo.getAllDiskDevice();

for (int i = 0; i  vdisks.length; i ++){

ListPairString, ManagedObjectReference vmdkFiles = 
vmMo.getDiskDatastorePathChain(vdisks[i], false);

for(PairString, ManagedObjectReference fileItem : 
vmdkFiles) {

String vmdkName = fileItem.first().split( )[1];

if (vmdkName.endsWith(.vmdk)){

vmdkName = vmdkName.substring(0, vmdkName.length() 
- (.vmdk).length());

}

String baseName = extractSnapshotBaseFileName(vmdkName);

mapNewDisk.put(baseName, vmdkName);

}

}

for (VolumeObjectTO volumeTO : volumeTOs) {

String baseName = 
extractSnapshotBaseFileName(volumeTO.getPath());

String newPath = mapNewDisk.get(baseName);

// get volume's chain size for this VM snapshot, exclude 
current volume vdisk

DataStoreTO store = volumeTO.getDataStore();

long size = 
getVMSnapshotChainSize(context,hyperHost,baseName + *.vmdk,

store.getUuid(), newPath);



if(volumeTO.getVolumeType()== Volume.Type.ROOT){

// add memory snapshot size

size = size + 
getVMSnapshotChainSize(context,hyperHost,cmd.getVmName()+*.vmsn,store.getUuid(),null);

}



volumeTO.setSize(size);

volumeTO.setPath(newPath);

}



Mike Tutkowski mike.tutkow...@solidfire.com
4:35 PM (17 hours ago)

to dev 
In short, I believe we can remove mapNewDisk and just assign null to newPath. 
This will keep the existing path for the volume in question (in the volumes 
table) in the same state as it was before we created a VMware snapshot, which I 
believe is the intent anyways.

Thoughts on that?


Mike Tutkowski mike.tutkow...@solidfire.com
6:33 PM (15 hours ago)

to Kelven, dev 
Actually, the more I look at this code, the more I think perhaps VMware 
snapshots are broken because the newPath field should probably not be assigned 
null after creating a new VMware snapshot (I'm thinking the intend is to 
replace the other path with a new path that refers to the delta file that was 
just created).

Does anyone know who worked on VMware snapshots? I've love to ask these 
questions to him soon as we are approaching the end of 4.3.

Thanks!


Kelven Yang 10:02 PM (12 hours ago)
Yes, your guess is correct, the intent to update with a new path is to reflec...

Mike Tutkowski mike.tutkow...@solidfire.com
10:13 PM (12 hours ago)

to dev, Kelven 
Thanks for the info, Kelven.

I believe we have a serious bug then as null is being assigned to newPath when 
a VMware snapshot is being taken (this is in 4.3, by the way).

I was trying to fix an issue with VMware snapshots and managed storage and 
happened upon this.

If you have a moment, you might want to set a breakpoint and step through and 
see what I mean first hand.

I'm looking into it, as well.

Thanks!
--

[jira] [Created] (CLOUDSTACK-5825) Create snapshot API always returns success

2014-01-07 Thread Chris Suich (JIRA)

Chris Suich created CLOUDSTACK-5825:
---

 Summary: Create snapshot API always returns success
 Key: CLOUDSTACK-5825
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5825
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: API
Affects Versions: 4.3.0
Reporter: Chris Suich
Priority: Critical


VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot() to
VolumeServiceImpl.takeSnapshot(), you’ll notice that ANY exception that is 
thrown inside of SnapshotManager.takeSnapshot() is simply caught and ignored.

Back up in VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(), 
JobInfo.Status.SUCCEEDED is ALWAYS returned, regardless of the snapshot result.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-5824) Delete snapshot UI always success

2014-01-07 Thread Chris Suich (JIRA)

Chris Suich created CLOUDSTACK-5824:
---

 Summary: Delete snapshot UI always success
 Key: CLOUDSTACK-5824
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5824
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.3.0
Reporter: Chris Suich
Priority: Minor


The delete snapshot UI code always reports a success, even if the job fails.

This can be fixed with this snippet of code:

notification: {
poll: pollAsyncJobResult
}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-5826) createPod: passing invalid gateway/netmask to the call causes infinite loop execution

2014-01-07 Thread ASF subversion and git services (JIRA)

Alena Prokharchyk created CLOUDSTACK-5826:
-

 Summary: createPod: passing invalid gateway/netmask to the call 
causes infinite loop execution
 Key: CLOUDSTACK-5826
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5826
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.3.0
Reporter: Alena Prokharchyk
Assignee: Alena Prokharchyk
Priority: Critical
 Fix For: 4.4.0


Steps to reproduce:

1) UI-Create Pod
2) pass -1 for gateway/netmask values

The createPod doesn't do gateway/netmask validation before calling 
NetUtils.ipAndNetMaskToCidr(gateway, netmask), and it causes NetUtils method to 
go to infinite loop.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-4881) Both Running and stopped vm can be scaled up using old API changeServiceForVirtualMachine that too above host capacity

2014-01-07 Thread Nitin Mehta (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864486#comment-13864486
 ] 

Nitin Mehta commented on CLOUDSTACK-4881:
-

Marcus - Can we please close this promptly as Felton is approaching and this is 
marked as a blocker.

 Both Running and stopped vm can be scaled up using old API 
 changeServiceForVirtualMachine that too above host capacity
 --

 Key: CLOUDSTACK-4881
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4881
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.3.0
Reporter: Gaurav Aradhye
Assignee: Nitin Mehta
Priority: Blocker
 Fix For: 4.3.0


 changeServiceForVirtualMachine API can be used to scale up a running vm also 
 (It should be effective against only stopped vm)
 More over, using this API, VM can be scaled up above host capacity (both CPU 
 and RAM) without any over-provisioning of resources.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5826) createPod: passing invalid gateway/netmask to the call causes infinite loop execution


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864500#comment-13864500
 ] 

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

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

CLOUDSTACK-5826: do netmask/gateway validation before calculating the POD cidr


 createPod: passing invalid gateway/netmask to the call causes infinite loop 
 execution
 -

 Key: CLOUDSTACK-5826
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5826
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: Alena Prokharchyk
Assignee: Alena Prokharchyk
Priority: Critical
 Fix For: 4.4.0


 Steps to reproduce:
 1) UI-Create Pod
 2) pass -1 for gateway/netmask values
 The createPod doesn't do gateway/netmask validation before calling 
 NetUtils.ipAndNetMaskToCidr(gateway, netmask), and it causes NetUtils method 
 to go to infinite loop.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (CLOUDSTACK-5826) createPod: passing invalid gateway/netmask to the call causes infinite loop execution


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

Alena Prokharchyk resolved CLOUDSTACK-5826.
---

Resolution: Fixed

 createPod: passing invalid gateway/netmask to the call causes infinite loop 
 execution
 -

 Key: CLOUDSTACK-5826
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5826
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: Alena Prokharchyk
Assignee: Alena Prokharchyk
Priority: Critical
 Fix For: 4.4.0


 Steps to reproduce:
 1) UI-Create Pod
 2) pass -1 for gateway/netmask values
 The createPod doesn't do gateway/netmask validation before calling 
 NetUtils.ipAndNetMaskToCidr(gateway, netmask), and it causes NetUtils method 
 to go to infinite loop.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-4881) Both Running and stopped vm can be scaled up using old API changeServiceForVirtualMachine that too above host capacity

2014-01-07 Thread Marcus Sorensen (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864501#comment-13864501
 ] 

Marcus Sorensen commented on CLOUDSTACK-4881:
-

Sure. I haven't played with scaleVirtualMachine, but if it has the same effect 
then we can move to it. 

 Both Running and stopped vm can be scaled up using old API 
 changeServiceForVirtualMachine that too above host capacity
 --

 Key: CLOUDSTACK-4881
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4881
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.3.0
Reporter: Gaurav Aradhye
Assignee: Nitin Mehta
Priority: Blocker
 Fix For: 4.3.0


 changeServiceForVirtualMachine API can be used to scale up a running vm also 
 (It should be effective against only stopped vm)
 More over, using this API, VM can be scaled up above host capacity (both CPU 
 and RAM) without any over-provisioning of resources.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-4881) Both Running and stopped vm can be scaled up using old API changeServiceForVirtualMachine that too above host capacity

2014-01-07 Thread Nitin Mehta (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864508#comment-13864508
 ] 

Nitin Mehta commented on CLOUDSTACK-4881:
-

Yes you can count me on it..Here is the FS with which scaleVirtualMachine was 
introduced - 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dynamic+scaling+of+CPU+and+RAM
Copying the excerpt from the FS for your convenience -
scaleVirtualMachine - There is an existing API changeServiceForVirtualMachine 
and takes vm_id and compute_offering_id as inputs. This is a sync call 
currently and will not be used anymore since we need it to be async. I plan to 
deprecate this api in the next big release (5.0).
With this feature I will introduce another API named scaleVirtualMachine which 
will be similar to upgradeVirtualMachine in every aspect except that it would 
be async. In addition it will be callable when the vm is in running state as 
well to dynamically scale the vm.
In case of a migration this will internally use the migrateVirtualMachine API 
logic.

Let me know if its alright to close this bug now ?


 Both Running and stopped vm can be scaled up using old API 
 changeServiceForVirtualMachine that too above host capacity
 --

 Key: CLOUDSTACK-4881
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4881
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.3.0
Reporter: Gaurav Aradhye
Assignee: Nitin Mehta
Priority: Blocker
 Fix For: 4.3.0


 changeServiceForVirtualMachine API can be used to scale up a running vm also 
 (It should be effective against only stopped vm)
 More over, using this API, VM can be scaled up above host capacity (both CPU 
 and RAM) without any over-provisioning of resources.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5681) Contrail:MS:API: Create network fails with NPE due to missing CIDR

2014-01-07 Thread Parth Jagirdar (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864515#comment-13864515
 ] 

Parth Jagirdar commented on CLOUDSTACK-5681:


Santhosh,

Yes network can be created through UI.

Can you do following to try and reproduce?

Go to DB and change the CIDR field in networks to NULL.

Then try to view networks in UI. (listNetworks).

Exception should be thrown there.

This issue was encountered while performing validation in a case where networks 
are created though scripts. (Now for API CIDR is not a required param).

And for networks without CIDR, listNetworks and createNetwork(Thorugh Instance 
creation wizard) will throw exception.

So to repro you will need to CIDR to NULL in DB.


 Contrail:MS:API: Create network fails with NPE due to missing CIDR
 --

 Key: CLOUDSTACK-5681
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5681
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API, Contrail, Management Server
Affects Versions: 4.2.0
 Environment: Contrail
Reporter: Parth Jagirdar
Assignee: Santhosh Kumar Edukulla
Priority: Critical

 CIDR is not required param in API, but without CIDR exceptions are thrown.
 2013-12-27 16:44:14,088 ERROR [cloud.api.ApiServer] (catalina-exec-3:null) 
 unhandled exception executing api command: createNetwork
 java.lang.NullPointerException
   at 
 com.cloud.network.NetworkModelImpl.getAvailableIps(NetworkModelImpl.java:1694)
   at 
 com.cloud.network.NetworkModelImpl.canUseForDeploy(NetworkModelImpl.java:585)
   at com.cloud.api.ApiDBUtils.canUseForDeploy(ApiDBUtils.java:1147)
   at 
 com.cloud.api.ApiResponseHelper.createNetworkResponse(ApiResponseHelper.java:2259)
   at 
 org.apache.cloudstack.api.command.user.network.CreateNetworkCmd.execute(CreateNetworkCmd.java:288)
   at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
   at com.cloud.api.ApiServer.queueCommand(ApiServer.java:514)
   at com.cloud.api.ApiServer.handleRequest(ApiServer.java:372)
   at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:305)
   at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
   at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
   at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
   at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
   at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
   at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
   at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
   at 
 org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
   at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
   at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
   at 
 org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
   at 
 org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721)
   at 
 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2266)
   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:724)
 2013-12-27 16:44:14,093 DEBUG [cloud.api.ApiServlet] (catalina-exec-3:null) 
 ===END===  10.215.2.19 -- GET  
 command=createNetworkresponse=jsonsessionkey=ijYX%2B4fZ2EjdBMgdrTgGLJU2e60%3DnetworkOfferingId=c9298387-30ec-40be-a0b7-cf54829fa5f8name=tempdisplayText=tempzoneId=37b6d96d-5b66-429b-8e8e-b7bd6d12ae96_=1388191455496
 2013-12-27 16:44:18,776 DEBUG [agent.manager.AgentManagerImpl] 
 (AgentManager-Handler-2:null) SeqA 2-11511: Processing Seq 2-11511:  { Cmd , 
 MgmtId: -1, via: 2, Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:2,_loadInfo:{\n
   \connections\: []\n},wait:0}}] }
 2013-12-27 16:44:18,780 DEBUG [agent.manager.AgentManagerImpl] 
 (AgentManager-Handler-2:null) SeqA 2-11511: Sending Seq 2-11511:  { Ans: , 
 MgmtId: 86780043846508, via: 2, Ver: v1, Flags: 100010, 
 [{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
 2013-12-27 16:44:18,909 DEBUG [storage.secondary.SecondaryStorageManagerImpl]

[jira] [Updated] (CLOUDSTACK-5817) [Dev Setup]Deploy Db is failing on master and 4.3

2014-01-07 Thread ASF subversion and git services (JIRA)


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

Animesh Chaturvedi updated CLOUDSTACK-5817:
---

Assignee: Amogh Vasekar

 [Dev Setup]Deploy Db is failing on master and 4.3
 -

 Key: CLOUDSTACK-5817
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5817
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: prashant kumar mishra
Assignee: Amogh Vasekar
Priority: Blocker
 Fix For: 4.3.0


 Ddeploydb is failing on master and 4.3 branch .  For branch 4.2 it  is 
 working fine
 [root@localhost cloudstack]# mvn -P developer -pl developer -Ddeploydb
 [INFO] Scanning for projects...
 [INFO]
 [INFO] 
 
 [INFO] Building Apache CloudStack Developer Mode 4.4.0-SNAPSHOT
 [INFO] 
 
 [INFO]
 [INFO] --- properties-maven-plugin:1.0-alpha-2:read-project-properties 
 (default) @ cloud-developer ---
 [INFO]
 [INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
 cloud-developer ---
 [INFO]
 [INFO] --- maven-antrun-plugin:1.7:run (default) @ cloud-developer ---
 [INFO] Executing tasks
 main:
 [INFO] Executed tasks
 [INFO]
 [INFO]  exec-maven-plugin:1.2.1:java (create-schema) @ cloud-developer 
 [INFO]
 [INFO]  exec-maven-plugin:1.2.1:java (create-schema) @ cloud-developer 
 [INFO]
 [INFO] --- exec-maven-plugin:1.2.1:java (create-schema) @ cloud-developer ---
 log4j:WARN No appenders could be found for logger 
 (org.springframework.core.env.StandardEnvironment).
 log4j:WARN Please initialize the log4j system properly.
 log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
 info.
  WARNING: Provided file does not exist: 
 /root/cloudstack/developer/developer-prefill.sql.override
  Initializing database=cloud with host=localhost port=3306 
 username=root password=
  Running query: drop database if exists `cloud`
  Running query: create database `cloud`
  Running query: GRANT ALL ON cloud.* to 'root'@`localhost` 
 identified by ''
  Running query: GRANT ALL ON cloud.* to 'root'@`%` identified by 
 ''
  Initializing database=cloud_usage with host=localhost port=3306 
 username=root password=
  Running query: drop database if exists `cloud_usage`
  Running query: create database `cloud_usage`
  Running query: GRANT ALL ON cloud_usage.* to 'root'@`localhost` 
 identified by ''
  Running query: GRANT ALL ON cloud_usage.* to 'root'@`%` 
 identified by ''
  Initializing database=cloudbridge with host=localhost port=3306 
 username=root password=
  Running query: drop database if exists `cloudbridge`
  Running query: create database `cloudbridge`
  Running query: GRANT ALL ON cloudbridge.* to 'root'@`localhost` 
 identified by ''
  Running query: GRANT ALL ON cloudbridge.* to 'root'@`%` 
 identified by ''
  Processing SQL file at 
 /root/cloudstack/developer/target/db/create-schema.sql
  Processing SQL file at 
 /root/cloudstack/developer/target/db/create-schema-premium.sql
  Processing SQL file at 
 /root/cloudstack/developer/target/db/templates.sql
  Processing SQL file at 
 /root/cloudstack/developer/target/db/cloudbridge_schema.sql
  Processing SQL file at 
 /root/cloudstack/developer/target/db/cloudbridge_multipart.sql
  Processing SQL file at 
 /root/cloudstack/developer/target/db/cloudbridge_index.sql
  Processing SQL file at 
 /root/cloudstack/developer/target/db/cloudbridge_multipart_alter.sql
  Processing SQL file at 
 /root/cloudstack/developer/target/db/cloudbridge_bucketpolicy.sql
  Processing SQL file at 
 /root/cloudstack/developer/target/db/cloudbridge_policy_alter.sql
  Processing SQL file at 
 /root/cloudstack/developer/target/db/cloudbridge_offering.sql
  Processing SQL file at 
 /root/cloudstack/developer/target/db/cloudbridge_offering_alter.sql
  Processing SQL file at 
 /root/cloudstack/developer/developer-prefill.sql
  Processing upgrade: com.cloud.upgrade.DatabaseUpgradeChecker
 [WARNING]
 java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at

[jira] [Commented] (CLOUDSTACK-5823) Taking a VMware snapshot doesn't work


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864602#comment-13864602
 ] 

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

Commit ecd4a9c6424be73b24a44c73f04c67c47e1611e8 in branch refs/heads/4.3 from 
[~mike-tutkowski]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ecd4a9c ]

CLOUDSTACK-5823: Taking a VMware snapshot doesn't work


 Taking a VMware snapshot doesn't work
 -

 Key: CLOUDSTACK-5823
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5823
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: VMware
Affects Versions: 4.3.0
 Environment: ESXi 5.1
Reporter: Mike Tutkowski
Assignee: Mike Tutkowski
 Fix For: 4.3.0


 Per a discussion on the mailing list:
 VMware snapshot question
 Mike Tutkowski mike.tutkow...@solidfire.com
 4:10 PM (18 hours ago)
 to dev 
 Hi,
 I was wondering about the following code in VmwareStorageManagerImpl. It is 
 in the CreateVMSnapshotAnswer execute(VmwareHostService hostService, 
 CreateVMSnapshotCommand cmd) method.
 The part I wonder about is in populating the mapNewDisk map. For disks like 
 the following:
 i-2-9-VM/fksjfaklsjdgflajs.vmdk, the key for the map ends up being i-2.
 When we call this:
 String baseName = extractSnapshotBaseFileName(volumeTO.getPath());
 It uses a path such as the following:
 fksjfaklsjdgflajs
 There is no i-2-9-VM/ preceding the name, so the key we search on ends up 
 being the following:
 fksjfaklsjdgflajs
 This leads to a newPath being equal to null.
 As it turns out, I believe null is actually correct, but - if that's the case 
 - why do we have all this logic if - in the end - we are just going to assign 
 null to newPath in every case when creating a VM snapshot for VMware? As it 
 turns out, null is later interpreted to mean, don't replace the path field 
 of this volume in the volumes table, which is, I think, what we want.
 Thanks!
 VirtualDisk[] vdisks = vmMo.getAllDiskDevice();
 for (int i = 0; i  vdisks.length; i ++){
 ListPairString, ManagedObjectReference vmdkFiles = 
 vmMo.getDiskDatastorePathChain(vdisks[i], false);
 for(PairString, ManagedObjectReference fileItem : 
 vmdkFiles) {
 String vmdkName = fileItem.first().split( )[1];
 if (vmdkName.endsWith(.vmdk)){
 vmdkName = vmdkName.substring(0, 
 vmdkName.length() - (.vmdk).length());
 }
 String baseName = 
 extractSnapshotBaseFileName(vmdkName);
 mapNewDisk.put(baseName, vmdkName);
 }
 }
 for (VolumeObjectTO volumeTO : volumeTOs) {
 String baseName = 
 extractSnapshotBaseFileName(volumeTO.getPath());
 String newPath = mapNewDisk.get(baseName);
 // get volume's chain size for this VM snapshot, exclude 
 current volume vdisk
 DataStoreTO store = volumeTO.getDataStore();
 long size = 
 getVMSnapshotChainSize(context,hyperHost,baseName + *.vmdk,
 store.getUuid(), newPath);
 if(volumeTO.getVolumeType()== Volume.Type.ROOT){
 // add memory snapshot size
 size = size + 
 getVMSnapshotChainSize(context,hyperHost,cmd.getVmName()+*.vmsn,store.getUuid(),null);
 }
 volumeTO.setSize(size);
 volumeTO.setPath(newPath);
 }
 Mike Tutkowski mike.tutkow...@solidfire.com
 4:35 PM (17 hours ago)
 to dev 
 In short, I believe we can remove mapNewDisk and just assign null to newPath. 
 This will keep the existing path for the volume in question (in the volumes 
 table) in the same state as it was before we created a VMware snapshot, which 
 I believe is the intent anyways.
 Thoughts on that?
 Mike Tutkowski mike.tutkow...@solidfire.com
 6:33 PM (15 hours ago)
 to Kelven, dev 
 Actually, the more I look at this code, the more I think perhaps VMware 
 snapshots are broken because the newPath field should probably not be 
 assigned null after creating a new VMware snapshot (I'm thinking the intend 
 is to replace the other path with a new path that refers to the delta file 
 that was just created).
 Does anyone know who worked on VMware snapshots? I've love to ask these 
 questions to him soon as we are approaching the end of 4.3.
 Thanks!
 Kelven Yang   10:02 PM (12 hours ago)
 Yes, your guess is correct, the intent to update with a new path

[jira] [Resolved] (CLOUDSTACK-5823) Taking a VMware snapshot doesn't work


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

Mike Tutkowski resolved CLOUDSTACK-5823.


Resolution: Fixed

I checked in ecd4a9c6424be73b24a44c73f04c67c47e1611e8.

Creating, deleting, and reverting VMware snapshots appears to work now.

 Taking a VMware snapshot doesn't work
 -

 Key: CLOUDSTACK-5823
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5823
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: VMware
Affects Versions: 4.3.0
 Environment: ESXi 5.1
Reporter: Mike Tutkowski
Assignee: Mike Tutkowski
 Fix For: 4.3.0


 Per a discussion on the mailing list:
 VMware snapshot question
 Mike Tutkowski mike.tutkow...@solidfire.com
 4:10 PM (18 hours ago)
 to dev 
 Hi,
 I was wondering about the following code in VmwareStorageManagerImpl. It is 
 in the CreateVMSnapshotAnswer execute(VmwareHostService hostService, 
 CreateVMSnapshotCommand cmd) method.
 The part I wonder about is in populating the mapNewDisk map. For disks like 
 the following:
 i-2-9-VM/fksjfaklsjdgflajs.vmdk, the key for the map ends up being i-2.
 When we call this:
 String baseName = extractSnapshotBaseFileName(volumeTO.getPath());
 It uses a path such as the following:
 fksjfaklsjdgflajs
 There is no i-2-9-VM/ preceding the name, so the key we search on ends up 
 being the following:
 fksjfaklsjdgflajs
 This leads to a newPath being equal to null.
 As it turns out, I believe null is actually correct, but - if that's the case 
 - why do we have all this logic if - in the end - we are just going to assign 
 null to newPath in every case when creating a VM snapshot for VMware? As it 
 turns out, null is later interpreted to mean, don't replace the path field 
 of this volume in the volumes table, which is, I think, what we want.
 Thanks!
 VirtualDisk[] vdisks = vmMo.getAllDiskDevice();
 for (int i = 0; i  vdisks.length; i ++){
 ListPairString, ManagedObjectReference vmdkFiles = 
 vmMo.getDiskDatastorePathChain(vdisks[i], false);
 for(PairString, ManagedObjectReference fileItem : 
 vmdkFiles) {
 String vmdkName = fileItem.first().split( )[1];
 if (vmdkName.endsWith(.vmdk)){
 vmdkName = vmdkName.substring(0, 
 vmdkName.length() - (.vmdk).length());
 }
 String baseName = 
 extractSnapshotBaseFileName(vmdkName);
 mapNewDisk.put(baseName, vmdkName);
 }
 }
 for (VolumeObjectTO volumeTO : volumeTOs) {
 String baseName = 
 extractSnapshotBaseFileName(volumeTO.getPath());
 String newPath = mapNewDisk.get(baseName);
 // get volume's chain size for this VM snapshot, exclude 
 current volume vdisk
 DataStoreTO store = volumeTO.getDataStore();
 long size = 
 getVMSnapshotChainSize(context,hyperHost,baseName + *.vmdk,
 store.getUuid(), newPath);
 if(volumeTO.getVolumeType()== Volume.Type.ROOT){
 // add memory snapshot size
 size = size + 
 getVMSnapshotChainSize(context,hyperHost,cmd.getVmName()+*.vmsn,store.getUuid(),null);
 }
 volumeTO.setSize(size);
 volumeTO.setPath(newPath);
 }
 Mike Tutkowski mike.tutkow...@solidfire.com
 4:35 PM (17 hours ago)
 to dev 
 In short, I believe we can remove mapNewDisk and just assign null to newPath. 
 This will keep the existing path for the volume in question (in the volumes 
 table) in the same state as it was before we created a VMware snapshot, which 
 I believe is the intent anyways.
 Thoughts on that?
 Mike Tutkowski mike.tutkow...@solidfire.com
 6:33 PM (15 hours ago)
 to Kelven, dev 
 Actually, the more I look at this code, the more I think perhaps VMware 
 snapshots are broken because the newPath field should probably not be 
 assigned null after creating a new VMware snapshot (I'm thinking the intend 
 is to replace the other path with a new path that refers to the delta file 
 that was just created).
 Does anyone know who worked on VMware snapshots? I've love to ask these 
 questions to him soon as we are approaching the end of 4.3.
 Thanks!
 Kelven Yang   10:02 PM (12 hours ago)
 Yes, your guess is correct, the intent to update with a new path is to 
 reflec...
 Mike Tutkowski mike.tutkow...@solidfire.com
 10:13 PM (12 hours ago)
 to dev, Kelven 
 Thanks for the info, Kelven.
 I believe we have a

[jira] [Closed] (CLOUDSTACK-5823) Taking a VMware snapshot doesn't work


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

Mike Tutkowski closed CLOUDSTACK-5823.
--


 Taking a VMware snapshot doesn't work
 -

 Key: CLOUDSTACK-5823
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5823
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: VMware
Affects Versions: 4.3.0
 Environment: ESXi 5.1
Reporter: Mike Tutkowski
Assignee: Mike Tutkowski
 Fix For: 4.3.0


 Per a discussion on the mailing list:
 VMware snapshot question
 Mike Tutkowski mike.tutkow...@solidfire.com
 4:10 PM (18 hours ago)
 to dev 
 Hi,
 I was wondering about the following code in VmwareStorageManagerImpl. It is 
 in the CreateVMSnapshotAnswer execute(VmwareHostService hostService, 
 CreateVMSnapshotCommand cmd) method.
 The part I wonder about is in populating the mapNewDisk map. For disks like 
 the following:
 i-2-9-VM/fksjfaklsjdgflajs.vmdk, the key for the map ends up being i-2.
 When we call this:
 String baseName = extractSnapshotBaseFileName(volumeTO.getPath());
 It uses a path such as the following:
 fksjfaklsjdgflajs
 There is no i-2-9-VM/ preceding the name, so the key we search on ends up 
 being the following:
 fksjfaklsjdgflajs
 This leads to a newPath being equal to null.
 As it turns out, I believe null is actually correct, but - if that's the case 
 - why do we have all this logic if - in the end - we are just going to assign 
 null to newPath in every case when creating a VM snapshot for VMware? As it 
 turns out, null is later interpreted to mean, don't replace the path field 
 of this volume in the volumes table, which is, I think, what we want.
 Thanks!
 VirtualDisk[] vdisks = vmMo.getAllDiskDevice();
 for (int i = 0; i  vdisks.length; i ++){
 ListPairString, ManagedObjectReference vmdkFiles = 
 vmMo.getDiskDatastorePathChain(vdisks[i], false);
 for(PairString, ManagedObjectReference fileItem : 
 vmdkFiles) {
 String vmdkName = fileItem.first().split( )[1];
 if (vmdkName.endsWith(.vmdk)){
 vmdkName = vmdkName.substring(0, 
 vmdkName.length() - (.vmdk).length());
 }
 String baseName = 
 extractSnapshotBaseFileName(vmdkName);
 mapNewDisk.put(baseName, vmdkName);
 }
 }
 for (VolumeObjectTO volumeTO : volumeTOs) {
 String baseName = 
 extractSnapshotBaseFileName(volumeTO.getPath());
 String newPath = mapNewDisk.get(baseName);
 // get volume's chain size for this VM snapshot, exclude 
 current volume vdisk
 DataStoreTO store = volumeTO.getDataStore();
 long size = 
 getVMSnapshotChainSize(context,hyperHost,baseName + *.vmdk,
 store.getUuid(), newPath);
 if(volumeTO.getVolumeType()== Volume.Type.ROOT){
 // add memory snapshot size
 size = size + 
 getVMSnapshotChainSize(context,hyperHost,cmd.getVmName()+*.vmsn,store.getUuid(),null);
 }
 volumeTO.setSize(size);
 volumeTO.setPath(newPath);
 }
 Mike Tutkowski mike.tutkow...@solidfire.com
 4:35 PM (17 hours ago)
 to dev 
 In short, I believe we can remove mapNewDisk and just assign null to newPath. 
 This will keep the existing path for the volume in question (in the volumes 
 table) in the same state as it was before we created a VMware snapshot, which 
 I believe is the intent anyways.
 Thoughts on that?
 Mike Tutkowski mike.tutkow...@solidfire.com
 6:33 PM (15 hours ago)
 to Kelven, dev 
 Actually, the more I look at this code, the more I think perhaps VMware 
 snapshots are broken because the newPath field should probably not be 
 assigned null after creating a new VMware snapshot (I'm thinking the intend 
 is to replace the other path with a new path that refers to the delta file 
 that was just created).
 Does anyone know who worked on VMware snapshots? I've love to ask these 
 questions to him soon as we are approaching the end of 4.3.
 Thanks!
 Kelven Yang   10:02 PM (12 hours ago)
 Yes, your guess is correct, the intent to update with a new path is to 
 reflec...
 Mike Tutkowski mike.tutkow...@solidfire.com
 10:13 PM (12 hours ago)
 to dev, Kelven 
 Thanks for the info, Kelven.
 I believe we have a serious bug then as null is being assigned to newPath 
 when a VMware snapshot is being taken (this is in 4.3, by the way).
 I was trying to fix an issue with

[jira] [Created] (CLOUDSTACK-5827) [Automation] Destroy VM failed, while deleting account

Rayees Namathponnan created CLOUDSTACK-5827:
---

 Summary: [Automation] Destroy VM failed, while deleting account 
 Key: CLOUDSTACK-5827
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5827
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.3.0
 Environment: KVM (RHEL 6.3)
branch 4.3
Reporter: Rayees Namathponnan
Priority: Blocker
 Fix For: 4.3.0


Steps to reproduce 

Step 1 : Create account 
Step 2 : Deploy an VM ryzVM
Step 3 : Destroy the account 

Expected result 

Account should be deleted, and ryzVM should destroyed as part of account 
clean up 

Actual Result 

Observed below vm destroy failures, during account clean up 

2014-01-07 11:47:44,415 DEBUG [c.c.c.CapacityManagerImpl] 
(Job-Executor-14:ctx-09b76f87 ctx-f3d83b99) release cpu from host: 1, old used: 
7100,reserved: 0, actual total: 9040, total with
overprovisioning: 9040; new used: 7000,reserved:100; movedfromreserved: 
false,moveToReserveredtrue
2014-01-07 11:47:44,415 DEBUG [c.c.c.CapacityManagerImpl] 
(Job-Executor-14:ctx-09b76f87 ctx-f3d83b99) release mem from host: 1, old used: 
7247757312,reserved: 0, total: 16713302016; new u
sed: 7113539584,reserved:134217728; movedfromreserved: 
false,moveToReserveredtrue
2014-01-07 11:47:44,441 DEBUG [c.c.v.VirtualMachineManagerImpl] 
(Job-Executor-14:ctx-09b76f87 ctx-f3d83b99) Unable to destroy the vm because it 
is not in the correct state: VM[User|ryzVM]
2014-01-07 11:47:44,455 WARN  [c.c.u.AccountManagerImpl] 
(Job-Executor-14:ctx-09b76f87 ctx-f3d83b99) Failed to cleanup account 
Acct[404ac830-cab8-4506-ba47-2964dc386adb-ryz] due to
com.cloud.utils.exception.CloudRuntimeException: Unable to destroy 
VM[User|ryzVM]
at 
com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:469)
at 
com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:448)
at com.cloud.vm.UserVmManagerImpl.expunge(UserVmManagerImpl.java:1704)
at sun.reflect.GeneratedMethodAccessor390.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy169.expunge(Unknown Source)
at 
com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:629)
at 
com.cloud.user.AccountManagerImpl.deleteAccount(AccountManagerImpl.java:561)
at 
com.cloud.user.AccountManagerImpl.deleteUserAccount(AccountManagerImpl.java:1308)
at sun.reflect.GeneratedMethodAccessor511.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy82.deleteUserAccount(Unknown Source)
at 
org.apache.cloudstack.region.RegionManagerImpl.deleteUserAccount(RegionManagerImpl.java:193)
at 
org.apache.cloudstack.region.RegionServiceImpl.deleteUserAccount(RegionServiceImpl.java:118)
at 
org.apache.cloudstack.api.command.admin.account.DeleteAccountCmd.execute(DeleteAccountCmd.java:101)
at

[jira] [Updated] (CLOUDSTACK-5827) [Automation] Destroy VM failed, while deleting account


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

Rayees Namathponnan updated CLOUDSTACK-5827:


Attachment: KVM_Jan_07_14.rar

 [Automation] Destroy VM failed, while deleting account 
 ---

 Key: CLOUDSTACK-5827
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5827
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
 Environment: KVM (RHEL 6.3)
 branch 4.3
Reporter: Rayees Namathponnan
Priority: Blocker
 Fix For: 4.3.0

 Attachments: KVM_Jan_07_14.rar


 Steps to reproduce 
 Step 1 : Create account 
 Step 2 : Deploy an VM ryzVM
 Step 3 : Destroy the account 
 Expected result 
 Account should be deleted, and ryzVM should destroyed as part of account 
 clean up 
 Actual Result 
 Observed below vm destroy failures, during account clean up 
 2014-01-07 11:47:44,415 DEBUG [c.c.c.CapacityManagerImpl] 
 (Job-Executor-14:ctx-09b76f87 ctx-f3d83b99) release cpu from host: 1, old 
 used: 7100,reserved: 0, actual total: 9040, total with
 overprovisioning: 9040; new used: 7000,reserved:100; movedfromreserved: 
 false,moveToReserveredtrue
 2014-01-07 11:47:44,415 DEBUG [c.c.c.CapacityManagerImpl] 
 (Job-Executor-14:ctx-09b76f87 ctx-f3d83b99) release mem from host: 1, old 
 used: 7247757312,reserved: 0, total: 16713302016; new u
 sed: 7113539584,reserved:134217728; movedfromreserved: 
 false,moveToReserveredtrue
 2014-01-07 11:47:44,441 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (Job-Executor-14:ctx-09b76f87 ctx-f3d83b99) Unable to destroy the vm because 
 it is not in the correct state: VM[User|ryzVM]
 2014-01-07 11:47:44,455 WARN  [c.c.u.AccountManagerImpl] 
 (Job-Executor-14:ctx-09b76f87 ctx-f3d83b99) Failed to cleanup account 
 Acct[404ac830-cab8-4506-ba47-2964dc386adb-ryz] due to
 com.cloud.utils.exception.CloudRuntimeException: Unable to destroy 
 VM[User|ryzVM]
 at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:469)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:448)
 at com.cloud.vm.UserVmManagerImpl.expunge(UserVmManagerImpl.java:1704)
 at sun.reflect.GeneratedMethodAccessor390.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:616)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at 
 org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
 at 
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
 at $Proxy169.expunge(Unknown Source)
 at 
 com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:629)
 at 
 com.cloud.user.AccountManagerImpl.deleteAccount(AccountManagerImpl.java:561)
 at 
 com.cloud.user.AccountManagerImpl.deleteUserAccount(AccountManagerImpl.java:1308)
 at sun.reflect.GeneratedMethodAccessor511.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:616)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at 
 com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
 at 
 org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
 at 
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
 at $Proxy82.deleteUserAccount(Unknown Source)
 at

[jira] [Created] (CLOUDSTACK-5828) [Automation] Delete snapshot error observed, after deleting account

Rayees Namathponnan created CLOUDSTACK-5828:
---

 Summary: [Automation] Delete snapshot error observed, after 
deleting account
 Key: CLOUDSTACK-5828
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5828
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Snapshot
Affects Versions: 4.3.0
 Environment: kvm (RHEL 6.3)
Branch : 4.3
Reporter: Rayees Namathponnan
Priority: Critical
 Fix For: 4.3.0


Steps to reproduce 

Step 1 : Create an account 
Step 2 : Deploy VM
Step 3 : create ROOT disks snapshot 
Step 4 : delete account 

Result 

Account got deleted, but below error trough in MS log 

2014-01-07 12:40:07,204 DEBUG [c.c.s.s.SnapshotManagerImpl] 
(Job-Executor-29:ctx-5dc172d6 ctx-d8044988) Deleted all snapshots for volume: 
947 under account: 531
2014-01-07 12:40:07,210 DEBUG [o.a.c.s.s.XenserverSnapshotStrategy] 
(Job-Executor-29:ctx-5dc172d6 ctx-d8044988) delete snapshot chain for snapshot: 
29
2014-01-07 12:40:07,211 DEBUG [o.a.c.s.s.XenserverSnapshotStrategy] 
(Job-Executor-29:ctx-5dc172d6 ctx-d8044988) Snapshot: 29 doesn't have children, 
so it's ok to delete it and its parents
2014-01-07 12:40:07,277 DEBUG [c.c.a.t.Request] (Job-Executor-29:ctx-5dc172d6 
ctx-d8044988) Seq 5-1429084154: Sending  { Cmd , MgmtId: 29066118877352, via: 
5(s-1-VM), Ver: v1, Flags: 1000
11, 
[{org.apache.cloudstack.storage.command.DeleteCommand:{data:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:snapshots/531/947/4fce7500-82c1-4f11-ba1d-18033717491a,
volume:{uuid:f3ebed2a-91ba-41d3-b215-398ae8534de3,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9
,id:1,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/
SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08ca01d9}},name:ROOT-885,size:8589934592,path:f3ebed2a-91ba-41d3-b215-398ae8534de3,volumeId:947,vmNam
e:i-531-885-QA,accountId:531,format:QCOW2,id:947,deviceId:0,hypervisorType:KVM},dataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.223.110.232:/export/home/ray
ees/SC_QA_AUTO4/secondary,_role:Image}},vmName:i-531-885-QA,name:r1vm1_ROOT-885_20140107202857,hypervisorType:KVM,id:29,quiescevm:false,physicalSize:0}},wait:0}}]
 }
2014-01-07 12:40:07,623 DEBUG [c.c.a.t.Request] (AgentManager-Handler-5:null) 
Seq 5-1429084154: Processing:  { Ans: , MgmtId: 29066118877352, via: 5, Ver: 
v1, Flags: 10, [{com.cloud.agen
t.api.Answer:{result:false,details:snapshot directory 947 doesn't 
exist,wait:0}}] }
2014-01-07 12:40:07,624 DEBUG [c.c.a.t.Request] (Job-Executor-29:ctx-5dc172d6 
ctx-d8044988) Seq 5-1429084154: Received:  { Ans: , MgmtId: 29066118877352, 
via: 5, Ver: v1, Flags: 10, { Ans
wer } }
2014-01-07 12:40:07,624 DEBUG [o.a.c.s.s.SnapshotServiceImpl] 
(Job-Executor-29:ctx-5dc172d6 ctx-d8044988) delete snapshot failedsnapshot 
directory 947 doesn't exist
2014-01-07 12:40:07,631 DEBUG [o.a.c.s.s.XenserverSnapshotStrategy] 
(Job-Executor-29:ctx-5dc172d6 ctx-d8044988) delete snapshot failed:
com.cloud.utils.exception.CloudRuntimeException: snapshot directory 947 doesn't 
exist
at 
org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.deleteSnapshot(SnapshotServiceImpl.java:391)
at 
org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.deleteSnapshotChain(XenserverSnapshotStrategy.java:176)
at 
org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.deleteSnapshot(XenserverSnapshotStrategy.java:236)
at 
com.cloud.storage.snapshot.SnapshotManagerImpl.deleteSnapshotDirsForAccount(SnapshotManagerImpl.java:615)
at sun.reflect.GeneratedMethodAccessor384.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy160.deleteSnapshotDirsForAccount(Unknown Source)
at 
com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:597)

[jira] [Updated] (CLOUDSTACK-5828) [Automation] Delete snapshot error observed, after deleting account


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

Rayees Namathponnan updated CLOUDSTACK-5828:


Attachment: KVM_Jan_07_14.rar

 [Automation] Delete snapshot error observed, after deleting account
 ---

 Key: CLOUDSTACK-5828
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5828
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Snapshot
Affects Versions: 4.3.0
 Environment: kvm (RHEL 6.3)
 Branch : 4.3
Reporter: Rayees Namathponnan
Priority: Critical
 Fix For: 4.3.0

 Attachments: KVM_Jan_07_14.rar


 Steps to reproduce 
 Step 1 : Create an account 
 Step 2 : Deploy VM
 Step 3 : create ROOT disks snapshot 
 Step 4 : delete account 
 Result 
 Account got deleted, but below error trough in MS log 
 2014-01-07 12:40:07,204 DEBUG [c.c.s.s.SnapshotManagerImpl] 
 (Job-Executor-29:ctx-5dc172d6 ctx-d8044988) Deleted all snapshots for volume: 
 947 under account: 531
 2014-01-07 12:40:07,210 DEBUG [o.a.c.s.s.XenserverSnapshotStrategy] 
 (Job-Executor-29:ctx-5dc172d6 ctx-d8044988) delete snapshot chain for 
 snapshot: 29
 2014-01-07 12:40:07,211 DEBUG [o.a.c.s.s.XenserverSnapshotStrategy] 
 (Job-Executor-29:ctx-5dc172d6 ctx-d8044988) Snapshot: 29 doesn't have 
 children, so it's ok to delete it and its parents
 2014-01-07 12:40:07,277 DEBUG [c.c.a.t.Request] (Job-Executor-29:ctx-5dc172d6 
 ctx-d8044988) Seq 5-1429084154: Sending  { Cmd , MgmtId: 29066118877352, via: 
 5(s-1-VM), Ver: v1, Flags: 1000
 11, 
 [{org.apache.cloudstack.storage.command.DeleteCommand:{data:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:snapshots/531/947/4fce7500-82c1-4f11-ba1d-18033717491a,
 volume:{uuid:f3ebed2a-91ba-41d3-b215-398ae8534de3,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9
 ,id:1,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/
 SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08ca01d9}},name:ROOT-885,size:8589934592,path:f3ebed2a-91ba-41d3-b215-398ae8534de3,volumeId:947,vmNam
 e:i-531-885-QA,accountId:531,format:QCOW2,id:947,deviceId:0,hypervisorType:KVM},dataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.223.110.232:/export/home/ray
 ees/SC_QA_AUTO4/secondary,_role:Image}},vmName:i-531-885-QA,name:r1vm1_ROOT-885_20140107202857,hypervisorType:KVM,id:29,quiescevm:false,physicalSize:0}},wait:0}}]
  }
 2014-01-07 12:40:07,623 DEBUG [c.c.a.t.Request] (AgentManager-Handler-5:null) 
 Seq 5-1429084154: Processing:  { Ans: , MgmtId: 29066118877352, via: 5, Ver: 
 v1, Flags: 10, [{com.cloud.agen
 t.api.Answer:{result:false,details:snapshot directory 947 doesn't 
 exist,wait:0}}] }
 2014-01-07 12:40:07,624 DEBUG [c.c.a.t.Request] (Job-Executor-29:ctx-5dc172d6 
 ctx-d8044988) Seq 5-1429084154: Received:  { Ans: , MgmtId: 29066118877352, 
 via: 5, Ver: v1, Flags: 10, { Ans
 wer } }
 2014-01-07 12:40:07,624 DEBUG [o.a.c.s.s.SnapshotServiceImpl] 
 (Job-Executor-29:ctx-5dc172d6 ctx-d8044988) delete snapshot failedsnapshot 
 directory 947 doesn't exist
 2014-01-07 12:40:07,631 DEBUG [o.a.c.s.s.XenserverSnapshotStrategy] 
 (Job-Executor-29:ctx-5dc172d6 ctx-d8044988) delete snapshot failed:
 com.cloud.utils.exception.CloudRuntimeException: snapshot directory 947 
 doesn't exist
 at 
 org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.deleteSnapshot(SnapshotServiceImpl.java:391)
 at 
 org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.deleteSnapshotChain(XenserverSnapshotStrategy.java:176)
 at 
 org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.deleteSnapshot(XenserverSnapshotStrategy.java:236)
 at 
 com.cloud.storage.snapshot.SnapshotManagerImpl.deleteSnapshotDirsForAccount(SnapshotManagerImpl.java:615)
 at sun.reflect.GeneratedMethodAccessor384.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:616)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at 
 org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
 at

[jira] [Updated] (CLOUDSTACK-5828) [Automation] Delete snapshot error observed, after deleting account


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

Rayees Namathponnan updated CLOUDSTACK-5828:


Description: 
Steps to reproduce 

Step 1 : Create an account 
Step 2 : Deploy VM
Step 3 : create ROOT disks snapshot 
Step 4 : delete account 

Result 

Account got deleted,  also snapshot got removed from secondary storage but 
below error trough in MS log 


2014-01-07 12:40:07,204 DEBUG [c.c.s.s.SnapshotManagerImpl] 
(Job-Executor-29:ctx-5dc172d6 ctx-d8044988) Deleted all snapshots for volume: 
947 under account: 531
2014-01-07 12:40:07,210 DEBUG [o.a.c.s.s.XenserverSnapshotStrategy] 
(Job-Executor-29:ctx-5dc172d6 ctx-d8044988) delete snapshot chain for snapshot: 
29
2014-01-07 12:40:07,211 DEBUG [o.a.c.s.s.XenserverSnapshotStrategy] 
(Job-Executor-29:ctx-5dc172d6 ctx-d8044988) Snapshot: 29 doesn't have children, 
so it's ok to delete it and its parents
2014-01-07 12:40:07,277 DEBUG [c.c.a.t.Request] (Job-Executor-29:ctx-5dc172d6 
ctx-d8044988) Seq 5-1429084154: Sending  { Cmd , MgmtId: 29066118877352, via: 
5(s-1-VM), Ver: v1, Flags: 1000
11, 
[{org.apache.cloudstack.storage.command.DeleteCommand:{data:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:snapshots/531/947/4fce7500-82c1-4f11-ba1d-18033717491a,
volume:{uuid:f3ebed2a-91ba-41d3-b215-398ae8534de3,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9
,id:1,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/
SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08ca01d9}},name:ROOT-885,size:8589934592,path:f3ebed2a-91ba-41d3-b215-398ae8534de3,volumeId:947,vmNam
e:i-531-885-QA,accountId:531,format:QCOW2,id:947,deviceId:0,hypervisorType:KVM},dataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.223.110.232:/export/home/ray
ees/SC_QA_AUTO4/secondary,_role:Image}},vmName:i-531-885-QA,name:r1vm1_ROOT-885_20140107202857,hypervisorType:KVM,id:29,quiescevm:false,physicalSize:0}},wait:0}}]
 }
2014-01-07 12:40:07,623 DEBUG [c.c.a.t.Request] (AgentManager-Handler-5:null) 
Seq 5-1429084154: Processing:  { Ans: , MgmtId: 29066118877352, via: 5, Ver: 
v1, Flags: 10, [{com.cloud.agen
t.api.Answer:{result:false,details:snapshot directory 947 doesn't 
exist,wait:0}}] }
2014-01-07 12:40:07,624 DEBUG [c.c.a.t.Request] (Job-Executor-29:ctx-5dc172d6 
ctx-d8044988) Seq 5-1429084154: Received:  { Ans: , MgmtId: 29066118877352, 
via: 5, Ver: v1, Flags: 10, { Ans
wer } }
2014-01-07 12:40:07,624 DEBUG [o.a.c.s.s.SnapshotServiceImpl] 
(Job-Executor-29:ctx-5dc172d6 ctx-d8044988) delete snapshot failedsnapshot 
directory 947 doesn't exist
2014-01-07 12:40:07,631 DEBUG [o.a.c.s.s.XenserverSnapshotStrategy] 
(Job-Executor-29:ctx-5dc172d6 ctx-d8044988) delete snapshot failed:
com.cloud.utils.exception.CloudRuntimeException: snapshot directory 947 doesn't 
exist
at 
org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.deleteSnapshot(SnapshotServiceImpl.java:391)
at 
org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.deleteSnapshotChain(XenserverSnapshotStrategy.java:176)
at 
org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.deleteSnapshot(XenserverSnapshotStrategy.java:236)
at 
com.cloud.storage.snapshot.SnapshotManagerImpl.deleteSnapshotDirsForAccount(SnapshotManagerImpl.java:615)
at sun.reflect.GeneratedMethodAccessor384.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy160.deleteSnapshotDirsForAccount(Unknown Source)
at 
com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:597)
at 
com.cloud.user.AccountManagerImpl.deleteAccount(AccountManagerImpl.java:561)
at 
com.cloud.user.AccountManagerImpl.deleteUserAccount(AccountManagerImpl.java:1308)
at sun.reflect.GeneratedMethodAccessor511.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

[jira] [Commented] (CLOUDSTACK-5502) [Automation] createVlanIpRange API failing, if you pass VLAN


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864698#comment-13864698
 ] 

Animesh Chaturvedi commented on CLOUDSTACK-5502:


Daan can you review and respond to Marcus, we need to resolve this for ACS 4.3 
RC

 [Automation] createVlanIpRange API failing, if you pass VLAN 
 -

 Key: CLOUDSTACK-5502
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5502
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.3.0
 Environment: KVM Basic Zone with SG
Reporter: Rayees Namathponnan
Assignee: Daan Hoogland
Priority: Blocker
 Fix For: 4.3.0


 This issue found in KVM basic zone with SG automation run;  test cases from 
 below suite filed 
 integration.component.test_multiple_ip_ranges.
 Steps to reproduce 
 Step 1 :  Create basic zone with SG
 Step 2 : Crete IP VLAN Range with below command (pass vlan=untagged)
 http://xxx..xxx.xxx:8096/?command=createVlanIpRangegateway=10.223.251.1forvirtualnetwork=falsestartip=10.223.251.3podid=0253bcbf-e636-4776-9e8c-216b70d195a2zoneid=a9912aa8-a231-44d9-a70b-9d53e6db2d27netmask=255.255.255.192vlan=untagged
 Result;
 API command failed with error 
 { createvlaniprangeresponse : 
 {uuidList:[],errorcode:431,cserrorcode:4350,errortext:Vlan doesn't 
 match vlan of the network} }
 this API command works only, if you are not passing any VLAN



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5432) [Automation] Libvtd getting crashed and agent going to alert start


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864700#comment-13864700
 ] 

Animesh Chaturvedi commented on CLOUDSTACK-5432:


Rayees can you review and respond to Marcus

 [Automation] Libvtd getting crashed and agent going to alert start 
 ---

 Key: CLOUDSTACK-5432
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5432
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.3.0
 Environment: KVM (RHEL 6.3)
 Branch : 4.3
Reporter: Rayees Namathponnan
Assignee: Marcus Sorensen
Priority: Blocker
 Fix For: 4.3.0

 Attachments: CLOUDSTACK-5432_Jan_06.rar, KVM_Automation_Dec_11.rar, 
 agent1.rar, agent2.rar, management-server.rar


 This issue is observed in  4.3 automation environment;  libvirt crashed and 
 cloudstack agent went to alert start;
 Please see the agent log; connection between agent and MS lost with error 
 Connection closed with -1 on reading size.  @ 2013-12-09 19:47:06,969
 2013-12-09 19:43:41,495 DEBUG [cloud.agent.Agent] 
 (agentRequest-Handler-2:null) Processing command: 
 com.cloud.agent.api.GetStorageStatsCommand
 2013-12-09 19:47:06,969 DEBUG [utils.nio.NioConnection] (Agent-Selector:null) 
 Location 1: Socket Socket[addr=/10.223.49.195,port=8250,localport=40801] 
 closed on read.  Probably -1 returned: Connection closed with -1 on reading 
 size.
 2013-12-09 19:47:06,969 DEBUG [utils.nio.NioConnection] (Agent-Selector:null) 
 Closing socket Socket[addr=/10.223.49.195,port=8250,localport=40801]
 2013-12-09 19:47:06,969 DEBUG [cloud.agent.Agent] (Agent-Handler-3:null) 
 Clearing watch list: 2
 2013-12-09 19:47:11,969 INFO  [cloud.agent.Agent] (Agent-Handler-3:null) Lost 
 connection to the server. Dealing with the remaining commands...
 2013-12-09 19:47:11,970 INFO  [cloud.agent.Agent] (Agent-Handler-3:null) 
 Cannot connect because we still have 5 commands in progress.
 2013-12-09 19:47:16,970 INFO  [cloud.agent.Agent] (Agent-Handler-3:null) Lost 
 connection to the server. Dealing with the remaining commands...
 2013-12-09 19:47:16,990 INFO  [cloud.agent.Agent] (Agent-Handler-3:null) 
 Cannot connect because we still have 5 commands in progress.
 2013-12-09 19:47:21,990 INFO  [cloud.agent.Agent] (Agent-Handler-3:null) Lost 
 connection to the server. Dealing with the remaining commands.. 
 Please see the lib virtd log at same time (please see the attached complete 
 log, there is a 5 hour  difference in agent log and libvirt log ) 
 2013-12-10 02:45:45.563+: 5938: error : qemuMonitorIO:574 : internal 
 error End of file from monitor
 2013-12-10 02:45:47.663+: 5942: error : virCommandWait:2308 : internal 
 error Child process (/bin/umount /mnt/41b632b5-40b3-3024-a38b-ea259c72579f) 
 status unexpected: exit status 16
 2013-12-10 02:45:53.925+: 5943: error : virCommandWait:2308 : internal 
 error Child process (/sbin/tc qdisc del dev vnet14 root) status unexpected: 
 exit status 2
 2013-12-10 02:45:53.929+: 5943: error : virCommandWait:2308 : internal 
 error Child process (/sbin/tc qdisc del dev vnet14 ingress) status 
 unexpected: exit status 2
 2013-12-10 02:45:54.011+: 5943: warning : qemuDomainObjTaint:1297 : 
 Domain id=71 name='i-45-97-QA' uuid=7717ba08-be84-4b63-a674-1534f9dc7bef is 
 tainted: high-privileges
 2013-12-10 02:46:33.070+: 5940: error : virCommandWait:2308 : internal 
 error Child process (/sbin/tc qdisc del dev vnet12 root) status unexpected: 
 exit status 2
 2013-12-10 02:46:33.081+: 5940: error : virCommandWait:2308 : internal 
 error Child process (/sbin/tc qdisc del dev vnet12 ingress) status 
 unexpected: exit status 2
 2013-12-10 02:46:33.197+: 5940: warning : qemuDomainObjTaint:1297 : 
 Domain id=72 name='i-47-111-QA' uuid=7fcce58a-96dc-4207-9998-b8fb72b446ac is 
 tainted: high-privileges
 2013-12-10 02:46:36.394+: 5938: error : qemuMonitorIO:574 : internal 
 error End of file from monitor
 2013-12-10 02:46:37.685+: 5940: error : virCommandWait:2308 : internal 
 error Child process (/bin/umount /mnt/41b632b5-40b3-3024-a38b-ea259c72579f) 
 status unexpected: exit status 16
 2013-12-10 02:46:57.869+: 5940: error : virCommandWait:2308 : internal 
 error Child process (/sbin/tc qdisc del dev vnet15 root) status unexpected: 
 exit status 2
 2013-12-10 02:46:57.873+: 5940: error : virCommandWait:2308 : internal 
 error Child process (/sbin/tc qdisc del dev vnet15 ingress) status 
 unexpected: exit status 2
 2013-12-10 02:46:57.925+: 5940: error : virCommandWait:2308 : internal 
 error Child process (/sbin/tc qdisc del dev vnet17 root) status unexpected: 
 exit status 2

[jira] [Resolved] (CLOUDSTACK-5722) [Automation] Basic zone deployment failed while creating createVlanIpRange


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

Animesh Chaturvedi resolved CLOUDSTACK-5722.


Resolution: Fixed

Looks like this is fixed. Rayees reopen if you continue to see this issue

 [Automation] Basic zone deployment failed while creating createVlanIpRange
 --

 Key: CLOUDSTACK-5722
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5722
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: Rayees Namathponnan
Assignee: Daan Hoogland
Priority: Blocker
 Fix For: 4.3.0

 Attachments: management-server.log.2014-01-01.gz


 Steps reproduce 
 Create basic zone setup in Xen; 
 Result 
 Zone deployment failed with below error 
 6L7YPKizUFWaa4XNgDPEB8C7zk-FHHrfsGYioKFlpLoY3gname=test0pod0startip=10.223.251.4zoneid=47c0a43e-b997-48f6-8ba6-5199cc42cff1netmask=255.255.255.192command=createPodsignature=zd09n7L84Ur1wro4GjlT3YVvUks%3Dresponse=jsongateway=10.223.251.1
 2014-01-01 13:09:33,444 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-20:ctx-35d0f932) ===START===  10.223.240.161 -- GET  
 networkid=e9568c5d-582e-47ce-a5c2-ccea7743e643endip=10.223.251.62apiKey=X4HWcjKRmsp4BJ4W2oXkABoPnsCWloxqcHJuFuno6L7YPKizUFWaa4XNgDPEB8C7zk-FHHrfsGYioKFlpLoY3gstartip=10.223.251.15podid=2bbdccbe-a545-48c3-bc92-4fef8f7e42d3zoneid=47c0a43e-b997-48f6-8ba6-5199cc42cff1netmask=255.255.255.192command=createVlanIpRangesignature=jnIBCktFh38ucJw6eUn5cwh3x4g%3Dforvirtualnetwork=falseresponse=jsongateway=10.223.251.1
 2014-01-01 13:09:33,511 ERROR [c.c.a.ApiServer] 
 (catalina-exec-20:ctx-35d0f932 ctx-17def31c ctx-2eb54872) unhandled exception 
 executing api command: createVlanIpRange
 java.lang.NullPointerException
 at com.cloud.utils.net.NetUtils.isSameIsolationId(NetUtils.java:1419)
 at 
 com.cloud.configuration.ConfigurationManagerImpl.createVlanAndPublicIpRange(ConfigurationManagerImpl.java:2474)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:622)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at 
 com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
 at 
 org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
 at 
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
 at com.sun.proxy.$Proxy87.createVlanAndPublicIpRange(Unknown Source)
 at 
 org.apache.cloudstack.api.command.admin.vlan.CreateVlanIpRangeCmd.execute(CreateVlanIpRangeCmd.java:211)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161)
 at com.cloud.api.ApiServer.queueCommand(ApiServer.java:530)
 at com.cloud.api.ApiServer.handleRequest(ApiServer.java:373)
 at 
 com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:322)
 at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52)
 at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:111)
 at com.cloud.api.ApiServlet.doGet(ApiServlet.java:73)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at

[jira] [Resolved] (CLOUDSTACK-5408) [Automation] Failed to deploy vm in vmware environment with error due to java.io.IOException: Cannot run program mount: java.io.IOException: error=12, Cannot all


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

Animesh Chaturvedi resolved CLOUDSTACK-5408.


Resolution: Fixed

Based on Sateesh's comment resolving this issue. 

 [Automation] Failed to deploy vm in vmware environment with error due to 
 java.io.IOException: Cannot run program mount: java.io.IOException: 
 error=12, Cannot allocate memory 
 --

 Key: CLOUDSTACK-5408
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5408
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: VMware
Affects Versions: 4.3.0
 Environment: vmware 5.0 update 3
 64 bit template 
Reporter: Rayees Namathponnan
Assignee: Sateesh Chodapuneedi
Priority: Critical
 Fix For: 4.3.0

 Attachments: CLOUDSTACK-5408.rar


 Steps to reproduce 
 Create advanced zone in vmware
 use 64 bit template 
 deploy VM
 Result
 SSVM are crated
 Routers are created 
 VM deployment failed with below error 
 yStorageResource.mountUri(NfsSecondaryStorageResource.java:2293)\n\tat 
 org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.getRootDir(NfsSecondaryStorageResource.java:1934)\n\tat
  
 com.cloud.storage.resource.VmwareSecondaryStorageResourceHandler.getMountPoint(VmwareSecondaryStorageResourceHandler.java:311)\n\tat
  
 com.cloud.storage.resource.VmwareStorageProcessor.copyTemplateFromSecondaryToPrimary(VmwareStorageProcessor.java:131)\n\tat
  
 com.cloud.storage.resource.VmwareStorageProcessor.copyTemplateToPrimaryStorage(VmwareStorageProcessor.java:221)\n\tat
  
 com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:75)\n\tat
  
 com.cloud.storage.resource.VmwareStorageSubsystemCommandHandler.execute(VmwareStorageSubsystemCommandHandler.java:155)\n\tat
  
 com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:50)\n\tat
  
 com.cloud.storage.resource.VmwareSecondaryStorageResourceHandler.executeRequest(VmwareSecondaryStorageResourceHandler.java:101)\n\tat
  
 com.cloud.storage.resource.PremiumSecondaryStorageResource.executeRequest(PremiumSecondaryStorageResource.java:56)\n\tat
  com.cloud.agent.Agent.processRequest(Agent.java:498)\n\tat 
 com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:806)\n\tat 
 com.cloud.utils.nio.Task.run(Task.java:83)\n\tat 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)\n\tat
  
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n\tat
  java.lang.Thread.run(Thread.java:679)\nCaused by: java.io.IOException: 
 java.io.IOException: error=12, Cannot allocate memory\n\tat 
 java.lang.UNIXProcess.init(UNIXProcess.java:164)\n\tat 
 java.lang.ProcessImpl.start(ProcessImpl.java:81)\n\tat 
 java.lang.ProcessBuilder.start(ProcessBuilder.java:470)\n\t... 20 
 more\n\n,wait:0}}] }
 2013-12-07 14:07:59,776 DEBUG [c.c.a.t.Request] (Job-Executor-23:ctx-f22d6e84 
 ctx-b6c94672) Seq 5-137756744: Received:  { Ans: , MgmtId: 90928106758026, 
 via: 5, Ver: v1, Flags: 10, { CopyCmdAnswer } }
 2013-12-07 14:07:59,791 INFO  [o.a.c.s.v.VolumeServiceImpl] 
 (Job-Executor-23:ctx-f22d6e84 ctx-b6c94672) releasing lock for 
 VMTemplateStoragePool 9
 2013-12-07 14:07:59,791 WARN  [c.c.u.d.Merovingian2] 
 (Job-Executor-23:ctx-f22d6e84 ctx-b6c94672) Was unable to find lock for the 
 key template_spool_ref9 and thread id 1402045270
 2013-12-07 14:07:59,791 DEBUG [o.a.c.e.o.VolumeOrchestrator] 
 (Job-Executor-23:ctx-f22d6e84 ctx-b6c94672) Unable to create 
 Vol[8|vm=8|ROOT]:Unable to copy template to primary storage due to 
 exception:Exception: com.cloud.utils.exception.CloudRuntimeException
 Message: GetRootDir for 
 nfs://10.223.240.164:/home/common/automation/SC-CLOUD-QA03/secondary1 failed 
 due to com.cloud.utils.exception.CloudRuntimeException: Unable to mount 
 10.223.240.164:/home/common/automation/SC-CLOUD-QA03/secondary1 at 
 /mnt/SecStorage/c6ec0966-00ab-3817-8a96-e8f4c3e03269 due to 
 java.io.IOException: Cannot run program mount: java.io.IOException: 
 error=12, Cannot allocate memory
 at java.lang.ProcessBuilder.start(ProcessBuilder.java:488)
 at com.cloud.utils.script.Script.execute(Script.java:177)
 at com.cloud.utils.script.Script.execute(Script.java:155)
 at 
 org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.attemptMount(NfsSecondaryStorageResource.java:2374)
 at

[jira] [Resolved] (CLOUDSTACK-5556) [Automation] Failed to re-attach the volume in KVM


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

Animesh Chaturvedi resolved CLOUDSTACK-5556.


Resolution: Cannot Reproduce

Reopen if you can reproduce

 [Automation] Failed to re-attach the volume in KVM
 --

 Key: CLOUDSTACK-5556
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5556
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Volumes
Affects Versions: 4.3.0
 Environment: KVM (RHEL 6.3)
 Branch 4.3
Reporter: Rayees Namathponnan
Assignee: Rayees Namathponnan
Priority: Critical
 Fix For: 4.3.0


 Steps to reproduce 
 Step 1 : Create advanced zone in KVM
 Step 2 : Deploy a VM
 Step 3 : Add new Volume 
 Step 4 : Attach the volume to vm
 Step 5 : Remove volume from the vm
 Step 6 : attach the same volume again 
 Result 
 Failed to attach the volume second time, with error Failed to attach volume: 
 vol1 to VM: RYZ1; org.libvirt.LibvirtException: internal error unable to 
 execute QEMU command '__com.redhat_drive_add': Duplicate ID 
 'drive-virtio-disk1' for drive
 Observed below error in MS log
 2013-12-18 22:20:49,276 DEBUG [c.c.a.t.Request] (Job-Executor-51:ctx-98ec33fc 
 ctx-5303d6ac) Seq 1-1588070511: Sending  { Cmd , MgmtId: 29066118877352, via: 
 1(Rack2Host11.lab.vmops.com), Ver: v1, Flags: 100011, 
 [{org.apache.cloudstack.storage.command.AttachCommand:{disk:{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:afcc7fa1-dd56-49cb-9246-2806d20dbcc4,volumeType:DATADISK,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08ca01d9}},name:vol1,size:5368709120,path:afcc7fa1-dd56-49cb-9246-2806d20dbcc4,volumeId:484,accountId:2,format:QCOW2,id:484,hypervisorType:KVM}},diskSeq:1,path:afcc7fa1-dd56-49cb-9246-2806d20dbcc4,type:DATADISK,_details:{managed:false,storagePort:2049,storageHost:10.223.110.232,volumeSize:5368709120}},vmName:i-2-433-QA,wait:0}}]
  }
 2013-12-18 22:20:49,568 DEBUG [c.c.a.t.Request] (AgentManager-Handler-4:null) 
 Seq 1-1588070511: Processing:  { Ans: , MgmtId: 29066118877352, via: 1, Ver: 
 v1, Flags: 10, 
 [{org.apache.cloudstack.storage.command.AttachAnswer:{result:false,details:org.libvirt.LibvirtException:
  internal error unable to execute QEMU command '__com.redhat_drive_add': 
 Duplicate ID 'drive-virtio-disk1' for drive,wait:0}}] }
 2013-12-18 22:20:49,568 DEBUG [c.c.a.t.Request] (Job-Executor-51:ctx-98ec33fc 
 ctx-5303d6ac) Seq 1-1588070511: Received:  { Ans: , MgmtId: 29066118877352, 
 via: 1, Ver: v1, Flags: 10, { AttachAnswer } }
 2013-12-18 22:20:49,568 ERROR [c.c.a.ApiAsyncJobDispatcher] 
 (Job-Executor-51:ctx-98ec33fc) Unexpected exception while executing 
 org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
 com.cloud.utils.exception.CloudRuntimeException: Failed to attach volume: 
 vol1 to VM: RYZ1; org.libvirt.LibvirtException: internal error unable to 
 execute QEMU command '__com.redhat_drive_add': Duplicate ID 
 'drive-virtio-disk1' for drive
   at 
 com.cloud.storage.VolumeApiServiceImpl.sendAttachVolumeCommand(VolumeApiServiceImpl.java:1879)
   at 
 com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1264)
   at 
 com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:1088)
   at 
 com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1063)
   at sun.reflect.GeneratedMethodAccessor610.invoke(Unknown Source)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:616)
   at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
   at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
   at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
   at 
 org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
   at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
   at 
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
   at $Proxy193.attachVolumeToVM(Unknown Source)
   at

[jira] [Commented] (CLOUDSTACK-5731) [Automation] VM deployment failed with ConcurrentOperationException in vmware


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864706#comment-13864706
 ] 

Animesh Chaturvedi commented on CLOUDSTACK-5731:


Moving out to 4.4 since vmsync is not turned on by default

 [Automation] VM deployment failed with ConcurrentOperationException in vmware
 -

 Key: CLOUDSTACK-5731
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5731
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, VMware
Affects Versions: 4.3.0
 Environment: vmware 5.0
 branch 4.3
Reporter: Rayees Namathponnan
Assignee: Kelven Yang
Priority: Critical
 Fix For: 4.4.0

 Attachments: management-server.rar


 This issue observed in automation environment,  where mulpitple deployment 
 and delete operation happens parallel 
 Vew of the vm deployment failed with below error, i will attach complete log 
 with this defect 
 2014-01-02 13:24:29,612 WARN  [o.a.c.alerts] (Job-Executor-2:ctx-9e3b8e54 
 ctx-dd556c3f)  alertType:: 8 // dataCenterId:: 1 // podId:: 1 // clusterId:: 
 null // message:: Failed to deploy
  Vm with Id: 5, on Host with Id: null
 2014-01-02 13:24:29,653 ERROR [c.c.a.ApiAsyncJobDispatcher] 
 (Job-Executor-2:ctx-9e3b8e54) Unexpected exception while executing 
 org.apache.cloudstack.api.command.user.vm.DeployVMCmd
 com.cloud.utils.exception.CloudRuntimeException: Unable to serialize: 
 com.cloud.exception.AgentUnavailableException/{_scope:com.cloud.host.Host,_id:1,idList:[],csErrorCode:4285,detailMessage:Resource
  [Host:1] is unreachable: Host 1: Unable to start instance due to Unable to 
 transition to a new state from Running via 
 OperationFailed,cause:{class:com.cloud.exception.ConcurrentOperationException,msg:Unable
  to transition to a new state from Running via 
 OperationFailed},stackTrace:[{declaringClass:com.cloud.vm.VirtualMachineManagerImpl,methodName:orchestrateStart,fileName:VirtualMachineManagerImpl.java,lineNumber:1053},{declaringClass:com.cloud.vm.VirtualMachineManagerImpl,methodName:orchestrateStart,fileName:VirtualMachineManagerImpl.java,lineNumber:4736},{declaringClass:sun.reflect.NativeMethodAccessorImpl,methodName:invoke0,fileName:NativeMethodAccessorImpl.java,lineNumber:-2},{declaringClass:sun.reflect.NativeMethodAccessorImpl,methodName:invoke,fileName:NativeMethodAccessorImpl.java,lineNumber:57},{declaringClass:sun.reflect.DelegatingMethodAccessorImpl,methodName:invoke,fileName:DelegatingMethodAccessorImpl.java,lineNumber:43},{declaringClass:java.lang.reflect.Method,methodName:invoke,fileName:Method.java,lineNumber:606},{declaringClass:com.cloud.vm.VmWorkJobHandlerProxy,methodName:handleVmWorkJob,fileName:VmWorkJobHandlerProxy.java,lineNumber:107},{declaringClass:com.cloud.vm.VirtualMachineManagerImpl,methodName:handleVmWorkJob,fileName:VirtualMachineManagerImpl.java,lineNumber:4855},{declaringClass:com.cloud.vm.VmWorkJobDispatcher,methodName:runJob,fileName:VmWorkJobDispatcher.java,lineNumber:99},{declaringClass:org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5,methodName:runInContext,fileName:AsyncJobManagerImpl.java,lineNumber:522},{declaringClass:org.apache.cloudstack.managed.context.ManagedContextRunnable$1,methodName:run,fileName:ManagedContextRunnable.java,lineNumber:49},{declaringClass:org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1,methodName:call,fileName:DefaultManagedContext.java,lineNumber:56},{declaringClass:org.apache.cloudstack.managed.context.impl.DefaultManagedContext,methodName:callWithContext,fileName:DefaultManagedContext.java,lineNumber:103},{declaringClass:org.apache.cloudstack.managed.context.impl.DefaultManagedContext,methodName:runWithContext,fileName:DefaultManagedContext.java,lineNumber:53},{declaringClass:org.apache.cloudstack.managed.context.ManagedContextRunnable,methodName:run,fileName:ManagedContextRunnable.java,lineNumber:46},{declaringClass:java.util.concurrent.Executors$RunnableAdapter,methodName:call,fileName:Executors.java,lineNumber:471},{declaringClass:java.util.concurrent.FutureTask,methodName:run,fileName:FutureTask.java,lineNumber:262},{declaringClass:java.util.concurrent.ThreadPoolExecutor,methodName:runWorker,fileName:ThreadPoolExecutor.java,lineNumber:1145},{declaringClass:java.util.concurrent.ThreadPoolExecutor$Worker,methodName:run,fileName:ThreadPoolExecutor.java,lineNumber:615},{declaringClass:java.lang.Thread,methodName:run,fileName:Thread.java,lineNumber:744}],suppressedExceptions:[]}
 at 
 org.apache.cloudstack.framework.jobs.impl.JobSerializerHelper.fromObjectSerializedString(JobSerializerHelper.java:135)
 at

[jira] [Updated] (CLOUDSTACK-5731) [Automation] VM deployment failed with ConcurrentOperationException in vmware


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

Animesh Chaturvedi updated CLOUDSTACK-5731:
---

Fix Version/s: (was: 4.3.0)
   4.4.0

 [Automation] VM deployment failed with ConcurrentOperationException in vmware
 -

 Key: CLOUDSTACK-5731
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5731
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, VMware
Affects Versions: 4.3.0
 Environment: vmware 5.0
 branch 4.3
Reporter: Rayees Namathponnan
Assignee: Kelven Yang
Priority: Critical
 Fix For: 4.4.0

 Attachments: management-server.rar


 This issue observed in automation environment,  where mulpitple deployment 
 and delete operation happens parallel 
 Vew of the vm deployment failed with below error, i will attach complete log 
 with this defect 
 2014-01-02 13:24:29,612 WARN  [o.a.c.alerts] (Job-Executor-2:ctx-9e3b8e54 
 ctx-dd556c3f)  alertType:: 8 // dataCenterId:: 1 // podId:: 1 // clusterId:: 
 null // message:: Failed to deploy
  Vm with Id: 5, on Host with Id: null
 2014-01-02 13:24:29,653 ERROR [c.c.a.ApiAsyncJobDispatcher] 
 (Job-Executor-2:ctx-9e3b8e54) Unexpected exception while executing 
 org.apache.cloudstack.api.command.user.vm.DeployVMCmd
 com.cloud.utils.exception.CloudRuntimeException: Unable to serialize: 
 com.cloud.exception.AgentUnavailableException/{_scope:com.cloud.host.Host,_id:1,idList:[],csErrorCode:4285,detailMessage:Resource
  [Host:1] is unreachable: Host 1: Unable to start instance due to Unable to 
 transition to a new state from Running via 
 OperationFailed,cause:{class:com.cloud.exception.ConcurrentOperationException,msg:Unable
  to transition to a new state from Running via 
 OperationFailed},stackTrace:[{declaringClass:com.cloud.vm.VirtualMachineManagerImpl,methodName:orchestrateStart,fileName:VirtualMachineManagerImpl.java,lineNumber:1053},{declaringClass:com.cloud.vm.VirtualMachineManagerImpl,methodName:orchestrateStart,fileName:VirtualMachineManagerImpl.java,lineNumber:4736},{declaringClass:sun.reflect.NativeMethodAccessorImpl,methodName:invoke0,fileName:NativeMethodAccessorImpl.java,lineNumber:-2},{declaringClass:sun.reflect.NativeMethodAccessorImpl,methodName:invoke,fileName:NativeMethodAccessorImpl.java,lineNumber:57},{declaringClass:sun.reflect.DelegatingMethodAccessorImpl,methodName:invoke,fileName:DelegatingMethodAccessorImpl.java,lineNumber:43},{declaringClass:java.lang.reflect.Method,methodName:invoke,fileName:Method.java,lineNumber:606},{declaringClass:com.cloud.vm.VmWorkJobHandlerProxy,methodName:handleVmWorkJob,fileName:VmWorkJobHandlerProxy.java,lineNumber:107},{declaringClass:com.cloud.vm.VirtualMachineManagerImpl,methodName:handleVmWorkJob,fileName:VirtualMachineManagerImpl.java,lineNumber:4855},{declaringClass:com.cloud.vm.VmWorkJobDispatcher,methodName:runJob,fileName:VmWorkJobDispatcher.java,lineNumber:99},{declaringClass:org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5,methodName:runInContext,fileName:AsyncJobManagerImpl.java,lineNumber:522},{declaringClass:org.apache.cloudstack.managed.context.ManagedContextRunnable$1,methodName:run,fileName:ManagedContextRunnable.java,lineNumber:49},{declaringClass:org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1,methodName:call,fileName:DefaultManagedContext.java,lineNumber:56},{declaringClass:org.apache.cloudstack.managed.context.impl.DefaultManagedContext,methodName:callWithContext,fileName:DefaultManagedContext.java,lineNumber:103},{declaringClass:org.apache.cloudstack.managed.context.impl.DefaultManagedContext,methodName:runWithContext,fileName:DefaultManagedContext.java,lineNumber:53},{declaringClass:org.apache.cloudstack.managed.context.ManagedContextRunnable,methodName:run,fileName:ManagedContextRunnable.java,lineNumber:46},{declaringClass:java.util.concurrent.Executors$RunnableAdapter,methodName:call,fileName:Executors.java,lineNumber:471},{declaringClass:java.util.concurrent.FutureTask,methodName:run,fileName:FutureTask.java,lineNumber:262},{declaringClass:java.util.concurrent.ThreadPoolExecutor,methodName:runWorker,fileName:ThreadPoolExecutor.java,lineNumber:1145},{declaringClass:java.util.concurrent.ThreadPoolExecutor$Worker,methodName:run,fileName:ThreadPoolExecutor.java,lineNumber:615},{declaringClass:java.lang.Thread,methodName:run,fileName:Thread.java,lineNumber:744}],suppressedExceptions:[]}
 at 
 org.apache.cloudstack.framework.jobs.impl.JobSerializerHelper.fromObjectSerializedString(JobSerializerHelper.java:135)
 at

[jira] [Created] (CLOUDSTACK-5829) listvms should return the diskoffering id when deployed with an iso

2014-01-07 Thread Nitin Mehta (JIRA)

Nitin Mehta created CLOUDSTACK-5829:
---

 Summary: listvms should return the diskoffering id when deployed 
with an iso
 Key: CLOUDSTACK-5829
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5829
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Nitin Mehta


listvms should return the diskoffering id when deployed with an iso.




--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5370) Xenserver - Snapshots - vhd entries get accumulated on the primary store when snapshot creation fails becasue of not being able to reach the secondary store.

[
https://issues.apache.org/jira/browse/CLOUDSTACK-5370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864723#comment-13864723
]

Animesh Chaturvedi commented on CLOUDSTACK-5370:

Edison this was reopened please review

Xenserver - Snapshots - vhd entries get accumulated on the primary store when
snapshot creation fails becasue of not being able to reach the secondary
store.
-

Key: CLOUDSTACK-5370
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5370
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.3.0
Environment: Build from 4.3
Reporter: Sangeetha Hariharan
Assignee: edison su
Priority: Critical
Fix For: 4.3.0

Attachments: xennfsdown.rar

Set up:
Advanced Zone with 2 Xenserver 6.2 hosts:
1. Deploy 5 Vms in each of the hosts with 10 GB ROOT volume size , so we
start with 10 Vms.
2. Start concurrent snapshots for ROOT volumes of all the Vms.
3. Shutdown the Secondary storage server when the snapshots are in the
progress. ( In my case i stopped the nfs server)
4. Bring the Secondary storage server up after 12 hours. ( In my case started
the nfs server).
When secondary server was down (NFS server down) for about 12 hours , I see
that hourly snapshots get attempted every hour and fail with
“CreatedOnPrimary state . I see many entries being created on the primary
store ( I see 120 entries , but I have only 14 vms).
We accumulate 2 vhd files on the primary store for every snapshot that is
attempted.
When secondary store is brought up , and when another snapshot is attempted
and it succeeds, we see the vhd files are all being cleared out.
This is a problem that we accumulate so many vhd files ( In case of vmware
and kvm where there are no delta snapshots this size would be significantly
higher) on primary store.

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5607) Deleting a template from one zone removes it from all zones

2014-01-07 Thread Alex Huang (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864736#comment-13864736
 ] 

Alex Huang commented on CLOUDSTACK-5607:


If it's supposed to be deleted for one zone and the entire template got 
deleted, it's obviously a bug.  What advice do you need from me?  Am I missing 
some detail?

 Deleting a template from one zone removes it from all zones 
 

 Key: CLOUDSTACK-5607
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5607
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Template
Affects Versions: 4.3.0
 Environment: 4.3 MS
 Multiple zones
Reporter: Pavan Kumar Bandarupally
Assignee: Alex Huang
Priority: Critical
 Fix For: 4.3.0


 Register a template and select it to be available in all zones while 
 registering. The template will successfully get downloaded to all the zones 
 in the setup. In UI you can see that the template will be shown once for each 
 zone. Once the template is installed and ready to use, from UI delete the 
 template from one of the zones. Once the delete operation completes you can 
 see that it is deleted from all the zones even though we deleted it only from 
 one zone.
 Expected:
   
 The template should be deleted only from one zone 
 Actual:
 --
 The template gets deleted from all the zones.
 Note:
 --- 
 In the DB the template status will be destroyed only in the zone from which 
 it was deleted but in UI it will be removed from all zones.
 Job Traces:
 -- 
 2013-12-20 17:43:32,520 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-19:ctx-f8bd38aa) ===START===  10.146.0.11 -- GET  
 command=deleteTemplateid=e5a45120-e1dc-4b54-849d-1e1e7b7bc5c0zoneid=485aff23-1b9c-419c-9066-051d4e384f8cresponse=jsonsessionkey=2uhdSWakv%2Bwtliqp35yLP2ekz7c%3D_=1387522407471
 2013-12-20 17:43:32,632 DEBUG [c.c.s.StatsCollector] 
 (StatsCollector-1:ctx-823f6719) StorageCollector is running...
 2013-12-20 17:43:32,707 DEBUG [c.c.a.t.Request] 
 (StatsCollector-1:ctx-823f6719) Seq 3-1744176843: Received:  { Ans: , MgmtId: 
 6915098673184, via: 3, Ver: v1, Flags: 10, { GetStorageStatsAnswer } }
 2013-12-20 17:43:32,768 DEBUG [c.c.a.t.Request] 
 (StatsCollector-1:ctx-823f6719) Seq 5-565380424: Received:  { Ans: , MgmtId: 
 6915098673184, via: 5, Ver: v1, Flags: 10, { GetStorageStatsAnswer } }
 2013-12-20 17:43:32,773 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-405:ctx-1051c476) Seq 1-769789686: Executing request
 2013-12-20 17:43:32,781 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (catalina-exec-19:ctx-f8bd38aa ctx-bdee003a) submit async job-34, details: 
 AsyncJobVO {id:34, userId: 2, accountId: 2, instanceType: Template, 
 instanceId: 208, cmd: 
 org.apache.cloudstack.api.command.user.template.DeleteTemplateCmd, cmdInfo: 
 {id:e5a45120-e1dc-4b54-849d-1e1e7b7bc5c0,response:json,sessionkey:2uhdSWakv+wtliqp35yLP2ekz7c\u003d,cmdEventType:TEMPLATE.DELETE,ctxUserId:2,zoneid:485aff23-1b9c-419c-9066-051d4e384f8c,httpmethod:GET,_:1387522407471,ctxAccountId:2,ctxStartEventId:112},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 6915098673184, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2013-12-20 17:43:32,786 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-19:ctx-f8bd38aa ctx-bdee003a) ===END===  10.146.0.11 -- GET  
 command=deleteTemplateid=e5a45120-e1dc-4b54-849d-1e1e7b7bc5c0zoneid=485aff23-1b9c-419c-9066-051d4e384f8cresponse=jsonsessionkey=2uhdSWakv%2Bwtliqp35yLP2ekz7c%3D_=1387522407471
 2013-12-20 17:43:32,790 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
 (Job-Executor-30:ctx-4c40fe50) Add job-34 into job monitoring
 2013-12-20 17:43:32,790 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (Job-Executor-30:ctx-4c40fe50) Executing AsyncJobVO {id:34, userId: 2, 
 accountId: 2, instanceType: Template, instanceId: 208, cmd: 
 org.apache.cloudstack.api.command.user.template.DeleteTemplateCmd, cmdInfo: 
 {id:e5a45120-e1dc-4b54-849d-1e1e7b7bc5c0,response:json,sessionkey:2uhdSWakv+wtliqp35yLP2ekz7c\u003d,cmdEventType:TEMPLATE.DELETE,ctxUserId:2,zoneid:485aff23-1b9c-419c-9066-051d4e384f8c,httpmethod:GET,_:1387522407471,ctxAccountId:2,ctxStartEventId:112},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 6915098673184, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2013-12-20 17:43:32,863 INFO  [c.c.t.HypervisorTemplateAdapter] 
 (Job-Executor-30:ctx-4c40fe50 ctx-bdee003a) Delete template from image store: 
 TeamSSV
 2013-12-20 17:43:32,865 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl] 
 (Job-Executor-30:ctx-4c40fe50 ctx-bdee003a) template 208

[jira] [Updated] (CLOUDSTACK-5826) createPod: passing invalid gateway/netmask to the call causes infinite loop execution


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

Alena Prokharchyk updated CLOUDSTACK-5826:
--

Fix Version/s: 4.3.0
   4.2.1

 createPod: passing invalid gateway/netmask to the call causes infinite loop 
 execution
 -

 Key: CLOUDSTACK-5826
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5826
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: Alena Prokharchyk
Assignee: Alena Prokharchyk
Priority: Critical
 Fix For: 4.2.1, 4.3.0, 4.4.0


 Steps to reproduce:
 1) UI-Create Pod
 2) pass -1 for gateway/netmask values
 The createPod doesn't do gateway/netmask validation before calling 
 NetUtils.ipAndNetMaskToCidr(gateway, netmask), and it causes NetUtils method 
 to go to infinite loop.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5406) Not able to take snapshot becasue of secondary_storage limit of 400 gb exceeded even though we have not really consumed this limit in secondary store.


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864753#comment-13864753
 ] 

Sangeetha Hariharan commented on CLOUDSTACK-5406:
-

Thanks Sanjay for the detailed steps.

I now see that the snapshot_store_ref table and resource_count table reflect 
the correct physical size of the snapshots ( not the virtual size) when 
multiple snapshots are taken for Volumes belonging to the same account.

After this I see that with secondary Storage limits  set to 30 G, I am able to 
take multiple snapshots of ROOT volume which was created from a template that 
was 20 G ( virtual size) and ~ 1.7 G .

Like you have mentioned when there are multiple snapshots in progress , then we 
have accounted for the virtual size of these snapshots. During this time , when 
there is an attempt to take another snapshot , snapshots fails because of 
Maximum number of resources of type 'secondary_storage' for account
name=test in domain id=1 has been exceeded.  I will log a different bug for 
this issue.



 Not able to take snapshot becasue of secondary_storage limit of 400 gb 
 exceeded even though we have not really consumed this limit in secondary 
 store.
 --

 Key: CLOUDSTACK-5406
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5406
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
 Environment: Build from 4.3
Reporter: Sangeetha Hariharan
Assignee: Sanjay Tripathi
Priority: Critical
 Fix For: 4.3.0

 Attachments: management-server.rar, storage.rar


 Set up: 
 Xenserver setup with 2 NFS secondary stores.
 1 account having 21 Vms.
 I am using the the default secondary_storage limit which is 400 gb.
  
 Started hourly snapshot policy for all the ROOT volumes of the Vms which was 
 created from a template of size 20 gb. The actual used up size is 12 GB. 
 When  snapshot gets created , the full snapshot size is ~6.7 GB. 
  After only  2  snapshots of ROOT volume , I hit the following excepton:
  
 “2013-12-06 00:00:48,298 WARN  [c.c.s.s.SnapshotSchedulerImpl] 
 (SnapshotPollTask:ctx-a7ccb50a) Scheduling snapshot failed due to 
 com.cloud.exception.ResourceAllocationException: Maximum number of resources 
 of type 'secondary_storage' for account 
 name=test-TestParallelVolumeSnasohots-273V8U in domain id=1 has been 
 exceeded.”
  
 How are we calculating this limit ? Do we query the actual secondary store / 
 do we calculate based on the ROOT volume size and # of Snapshots.
  
 In case of Xenserve , we have Delta snapshots.We should not be 
  
 mysql select count(*) from snapshots where account_id=8 group by volume_id;
 +--+
 | count(*) |
 +--+
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |3 |
 |3 |
 +--+
 21 rows in set (0.00 sec)
  
  
 [root@Rack3Host5 secondary]# du -h --max-depth=1
 28G ./snapshots
 13G ./template
 4.0K./volumes
 41G .
  
  
 [root@Rack3Host8 secondary]# du -h --max-depth=1
 12G ./template
 29G ./snapshots
 4.0K./volumes
 41G .
 [root@Rack3Host8 secondary]#
 mysql select * from resource_limit;
 ++---++---+---+
 | id | domain_id | account_id | type  | max   |
 ++---++---+---+
 | 31 |  NULL |  8 | user_vm   |   200 |
 | 32 |  NULL |  8 | public_ip |   200 |
 | 33 |  NULL |  8 | volume|   200 |
 | 34 |  NULL |  8 | snapshot  |   200 |
 | 35 |  NULL |  8 | template  |   200 |
 | 36 |  NULL |  8 | vpc   |   200 |
 | 37 |  NULL |  8 | cpu   |40 |
 | 38 |  NULL |  8 | memory| 40960 |
 | 39 |  NULL |  8 | network   |20 |
 | 40 |  NULL |  8 | primary_storage   |  214748364800 |
 | 41 |  NULL |  8 | secondary_storage | 4294967296000 |
 ++---++---+---+
 11 rows in set (0.00 sec)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Reopened] (CLOUDSTACK-5408) [Automation] Failed to deploy vm in vmware environment with error due to java.io.IOException: Cannot run program mount: java.io.IOException: error=12, Cannot all


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

Rayees Namathponnan reopened CLOUDSTACK-5408:
-


Sateesh Is it FIXED ? 

 [Automation] Failed to deploy vm in vmware environment with error due to 
 java.io.IOException: Cannot run program mount: java.io.IOException: 
 error=12, Cannot allocate memory 
 --

 Key: CLOUDSTACK-5408
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5408
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: VMware
Affects Versions: 4.3.0
 Environment: vmware 5.0 update 3
 64 bit template 
Reporter: Rayees Namathponnan
Assignee: Sateesh Chodapuneedi
Priority: Critical
 Fix For: 4.3.0

 Attachments: CLOUDSTACK-5408.rar


 Steps to reproduce 
 Create advanced zone in vmware
 use 64 bit template 
 deploy VM
 Result
 SSVM are crated
 Routers are created 
 VM deployment failed with below error 
 yStorageResource.mountUri(NfsSecondaryStorageResource.java:2293)\n\tat 
 org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.getRootDir(NfsSecondaryStorageResource.java:1934)\n\tat
  
 com.cloud.storage.resource.VmwareSecondaryStorageResourceHandler.getMountPoint(VmwareSecondaryStorageResourceHandler.java:311)\n\tat
  
 com.cloud.storage.resource.VmwareStorageProcessor.copyTemplateFromSecondaryToPrimary(VmwareStorageProcessor.java:131)\n\tat
  
 com.cloud.storage.resource.VmwareStorageProcessor.copyTemplateToPrimaryStorage(VmwareStorageProcessor.java:221)\n\tat
  
 com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:75)\n\tat
  
 com.cloud.storage.resource.VmwareStorageSubsystemCommandHandler.execute(VmwareStorageSubsystemCommandHandler.java:155)\n\tat
  
 com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:50)\n\tat
  
 com.cloud.storage.resource.VmwareSecondaryStorageResourceHandler.executeRequest(VmwareSecondaryStorageResourceHandler.java:101)\n\tat
  
 com.cloud.storage.resource.PremiumSecondaryStorageResource.executeRequest(PremiumSecondaryStorageResource.java:56)\n\tat
  com.cloud.agent.Agent.processRequest(Agent.java:498)\n\tat 
 com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:806)\n\tat 
 com.cloud.utils.nio.Task.run(Task.java:83)\n\tat 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)\n\tat
  
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n\tat
  java.lang.Thread.run(Thread.java:679)\nCaused by: java.io.IOException: 
 java.io.IOException: error=12, Cannot allocate memory\n\tat 
 java.lang.UNIXProcess.init(UNIXProcess.java:164)\n\tat 
 java.lang.ProcessImpl.start(ProcessImpl.java:81)\n\tat 
 java.lang.ProcessBuilder.start(ProcessBuilder.java:470)\n\t... 20 
 more\n\n,wait:0}}] }
 2013-12-07 14:07:59,776 DEBUG [c.c.a.t.Request] (Job-Executor-23:ctx-f22d6e84 
 ctx-b6c94672) Seq 5-137756744: Received:  { Ans: , MgmtId: 90928106758026, 
 via: 5, Ver: v1, Flags: 10, { CopyCmdAnswer } }
 2013-12-07 14:07:59,791 INFO  [o.a.c.s.v.VolumeServiceImpl] 
 (Job-Executor-23:ctx-f22d6e84 ctx-b6c94672) releasing lock for 
 VMTemplateStoragePool 9
 2013-12-07 14:07:59,791 WARN  [c.c.u.d.Merovingian2] 
 (Job-Executor-23:ctx-f22d6e84 ctx-b6c94672) Was unable to find lock for the 
 key template_spool_ref9 and thread id 1402045270
 2013-12-07 14:07:59,791 DEBUG [o.a.c.e.o.VolumeOrchestrator] 
 (Job-Executor-23:ctx-f22d6e84 ctx-b6c94672) Unable to create 
 Vol[8|vm=8|ROOT]:Unable to copy template to primary storage due to 
 exception:Exception: com.cloud.utils.exception.CloudRuntimeException
 Message: GetRootDir for 
 nfs://10.223.240.164:/home/common/automation/SC-CLOUD-QA03/secondary1 failed 
 due to com.cloud.utils.exception.CloudRuntimeException: Unable to mount 
 10.223.240.164:/home/common/automation/SC-CLOUD-QA03/secondary1 at 
 /mnt/SecStorage/c6ec0966-00ab-3817-8a96-e8f4c3e03269 due to 
 java.io.IOException: Cannot run program mount: java.io.IOException: 
 error=12, Cannot allocate memory
 at java.lang.ProcessBuilder.start(ProcessBuilder.java:488)
 at com.cloud.utils.script.Script.execute(Script.java:177)
 at com.cloud.utils.script.Script.execute(Script.java:155)
 at 
 org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.attemptMount(NfsSecondaryStorageResource.java:2374)
 at 
 org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.mount(NfsSecondaryStorageResource.java:2331)
 at

[jira] [Commented] (CLOUDSTACK-5826) createPod: passing invalid gateway/netmask to the call causes infinite loop execution


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864786#comment-13864786
 ] 

Alena Prokharchyk commented on CLOUDSTACK-5826:
---

Added 4.2.1 and 4.3 as release targets as an infinite loop - and as a result 
createPod API stuck forever - is a critical problem. 

 createPod: passing invalid gateway/netmask to the call causes infinite loop 
 execution
 -

 Key: CLOUDSTACK-5826
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5826
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: Alena Prokharchyk
Assignee: Alena Prokharchyk
Priority: Critical
 Fix For: 4.2.1, 4.3.0, 4.4.0


 Steps to reproduce:
 1) UI-Create Pod
 2) pass -1 for gateway/netmask values
 The createPod doesn't do gateway/netmask validation before calling 
 NetUtils.ipAndNetMaskToCidr(gateway, netmask), and it causes NetUtils method 
 to go to infinite loop.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-5830) [vmware] Vcenter 5.5 host ESXi 5.5 unable to deploy VM, unable to destroy SSVM

2014-01-07 Thread angeline shen (JIRA)

angeline shen created CLOUDSTACK-5830:
-

 Summary: [vmware] Vcenter 5.5  host ESXi 5.5 unable to deploy VM, 
unable to destroy SSVM
 Key: CLOUDSTACK-5830
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5830
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.3.0
 Environment: MS   build 1/7/2014
vcenter 5.5  host1host2ESXi 5.5
Reporter: angeline shen
Priority: Blocker
 Fix For: 4.3.0


1. advance zone.   
2. mysql DB:  update service_offering set ram_size = 512 where vm_type= 
'secondarystoragevm'
3. attempt to destroy SSVM s-1-VM  failed. 

2014-01-07 13:18:27,627 DEBUG [c.c.v.VirtualMachineManagerImpl] 
(Job-Executor-24:ctx-f3730c63 ctx-e22956d8) Unable to destroy the vm because it 
is not in the correct state: VM[SecondaryStorageVm|s-1-VM]
2014-01-07 13:18:27,644 WARN  [o.a.c.f.j.i.AsyncJobManagerImpl] 
(Job-Executor-26:ctx-5c84cfbd) job-24 is scheduled for wakeup run, but there is 
no joining info anymore
2014-01-07 13:18:27,644 ERROR [o.a.c.f.j.i.AsyncJobManagerImpl] 
(Job-Executor-26:ctx-5c84cfbd) Unable to find a wakeup dispatcher from the 
joined job: AsyncJobVO {id:24, userId: 2, accountId: 2, instanceType: S
ystemVm, instanceId: 1, cmd: 
org.apache.cloudstack.api.command.admin.systemvm.DestroySystemVmCmd, cmdInfo: 
{response:json,id:d7bd162e-308a-4b4e-92ff-e27d223f0346,sessionkey:l+d7+bwKNP/cJpgZSM8Z1WRcne
M\u003d,cmdEventType:SSVM.DESTROY,ctxUserId:2,httpmethod:GET,_:1389129851873,ctxAccountId:2,ctxStartEventId:58},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 7425730021290, completeMsid: null, lastUpdated: null, 
lastPolled: Tue Jan 07 13:18:25 PST 2014, created: Tue Jan 07 13:17:57 PST 2014}
2014-01-07 13:18:27,645 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(Job-Executor-26:ctx-5c84cfbd) Done executing 
org.apache.cloudstack.api.command.admin.systemvm.DestroySystemVmCmd for job-24
2014-01-07 13:18:27,650 DEBUG [o.a.c.f.j.i.SyncQueueManagerImpl] 
(Job-Executor-25:ctx-284719f1) Sync queue (1) is currently empty
2014-01-07 13:18:27,654 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(Job-Executor-25:ctx-284719f1) Remove job-25 from job monitoring
2014-01-07 13:18:27,658 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(Job-Executor-26:ctx-5c84cfbd) Remove job-24 from job monitoring
2014-01-07 13:18:27,660 ERROR [c.c.a.ApiAsyncJobDispatcher] 
(Job-Executor-24:ctx-f3730c63) Unexpected exception while executing 
org.apache.cloudstack.api.command.admin.systemvm.DestroySystemVmCmd
com.cloud.utils.exception.CloudRuntimeException: Unable to destroy 
VM[SecondaryStorageVm|s-1-VM]
at 
com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:469)
at 
com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:448)
at 
com.cloud.vm.VirtualMachineManagerImpl.expunge(VirtualMachineManagerImpl.java:437)
at 
com.cloud.storage.secondary.SecondaryStorageManagerImpl.destroySecStorageVm(SecondaryStorageManagerImpl.java:975)
at 
com.cloud.server.ManagementServerImpl.destroySecondaryStorageVm(ManagementServerImpl.java:3060)
at 
com.cloud.server.ManagementServerImpl.destroySystemVM(ManagementServerImpl.java:3238)
at 
com.cloud.server.ManagementServerImpl.destroySystemVM(ManagementServerImpl.java:610)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at sun.proxy.$Proxy193.destroySystemVM(Unknown Source)
at 
org.apache.cloudstack.api.command.admin.systemvm.DestroySystemVmCmd.execute(DestroySystemVmCmd.java:97)
at

[jira] [Updated] (CLOUDSTACK-5830) [Automation][vmware] Vcenter 5.5 host ESXi 5.5 unable to deploy VM, unable to destroy SSVM

2014-01-07 Thread ASF subversion and git services (JIRA)


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

Rayees Namathponnan updated CLOUDSTACK-5830:


Summary: [Automation][vmware] Vcenter 5.5  host ESXi 5.5 unable to deploy 
VM, unable to destroy SSVM  (was: [vmware] Vcenter 5.5  host ESXi 5.5 unable to 
deploy VM, unable to destroy SSVM)

 [Automation][vmware] Vcenter 5.5  host ESXi 5.5 unable to deploy VM, unable 
 to destroy SSVM
 ---

 Key: CLOUDSTACK-5830
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5830
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
 Environment: MS   build 1/7/2014
 vcenter 5.5  host1host2ESXi 5.5
Reporter: angeline shen
Priority: Blocker
 Fix For: 4.3.0


 1. advance zone.   
 2. mysql DB:  update service_offering set ram_size = 512 where vm_type= 
 'secondarystoragevm'
 3. attempt to destroy SSVM s-1-VM  failed. 
 2014-01-07 13:18:27,627 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (Job-Executor-24:ctx-f3730c63 ctx-e22956d8) Unable to destroy the vm because 
 it is not in the correct state: VM[SecondaryStorageVm|s-1-VM]
 2014-01-07 13:18:27,644 WARN  [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (Job-Executor-26:ctx-5c84cfbd) job-24 is scheduled for wakeup run, but there 
 is no joining info anymore
 2014-01-07 13:18:27,644 ERROR [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (Job-Executor-26:ctx-5c84cfbd) Unable to find a wakeup dispatcher from the 
 joined job: AsyncJobVO {id:24, userId: 2, accountId: 2, instanceType: S
 ystemVm, instanceId: 1, cmd: 
 org.apache.cloudstack.api.command.admin.systemvm.DestroySystemVmCmd, cmdInfo: 
 {response:json,id:d7bd162e-308a-4b4e-92ff-e27d223f0346,sessionkey:l+d7+bwKNP/cJpgZSM8Z1WRcne
 M\u003d,cmdEventType:SSVM.DESTROY,ctxUserId:2,httpmethod:GET,_:1389129851873,ctxAccountId:2,ctxStartEventId:58},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 7425730021290, completeMsid: null, lastUpdated: null, 
 lastPolled: Tue Jan 07 13:18:25 PST 2014, created: Tue Jan 07 13:17:57 PST 
 2014}
 2014-01-07 13:18:27,645 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (Job-Executor-26:ctx-5c84cfbd) Done executing 
 org.apache.cloudstack.api.command.admin.systemvm.DestroySystemVmCmd for job-24
 2014-01-07 13:18:27,650 DEBUG [o.a.c.f.j.i.SyncQueueManagerImpl] 
 (Job-Executor-25:ctx-284719f1) Sync queue (1) is currently empty
 2014-01-07 13:18:27,654 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
 (Job-Executor-25:ctx-284719f1) Remove job-25 from job monitoring
 2014-01-07 13:18:27,658 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
 (Job-Executor-26:ctx-5c84cfbd) Remove job-24 from job monitoring
 2014-01-07 13:18:27,660 ERROR [c.c.a.ApiAsyncJobDispatcher] 
 (Job-Executor-24:ctx-f3730c63) Unexpected exception while executing 
 org.apache.cloudstack.api.command.admin.systemvm.DestroySystemVmCmd
 com.cloud.utils.exception.CloudRuntimeException: Unable to destroy 
 VM[SecondaryStorageVm|s-1-VM]
 at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:469)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:448)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.expunge(VirtualMachineManagerImpl.java:437)
 at 
 com.cloud.storage.secondary.SecondaryStorageManagerImpl.destroySecStorageVm(SecondaryStorageManagerImpl.java:975)
 at 
 com.cloud.server.ManagementServerImpl.destroySecondaryStorageVm(ManagementServerImpl.java:3060)
 at 
 com.cloud.server.ManagementServerImpl.destroySystemVM(ManagementServerImpl.java:3238)
 at 
 com.cloud.server.ManagementServerImpl.destroySystemVM(ManagementServerImpl.java:610)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:616)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at 
 com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
 at

[jira] [Commented] (CLOUDSTACK-5826) createPod: passing invalid gateway/netmask to the call causes infinite loop execution


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864836#comment-13864836
 ] 

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

Commit 6fd030cbf2e35dfffd7c027b11b5a76ae1f38065 in branch refs/heads/4.3 from 
[~alena1108]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6fd030c ]

CLOUDSTACK-5826: do netmask/gateway validation before calculating the POD cidr


 createPod: passing invalid gateway/netmask to the call causes infinite loop 
 execution
 -

 Key: CLOUDSTACK-5826
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5826
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: Alena Prokharchyk
Assignee: Alena Prokharchyk
Priority: Critical
 Fix For: 4.2.1, 4.3.0, 4.4.0


 Steps to reproduce:
 1) UI-Create Pod
 2) pass -1 for gateway/netmask values
 The createPod doesn't do gateway/netmask validation before calling 
 NetUtils.ipAndNetMaskToCidr(gateway, netmask), and it causes NetUtils method 
 to go to infinite loop.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-5831) As regular user , when trying to take a snapshot , snapshot succeeds but user is presented with The given command does not exist or it is not available for user me

Sangeetha Hariharan created CLOUDSTACK-5831:
---

 Summary: As regular user , when trying to take a snapshot , 
snapshot succeeds but user is presented with The given command does not exist 
or it is not available for user message.
 Key: CLOUDSTACK-5831
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5831
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.3.0
 Environment: Build from 4.3
Reporter: Sangeetha Hariharan
 Fix For: 4.3.0


As regular user , when trying to take a snapshot , snapshot succeeds but user 
is presented with The given command does not exist or it is not available for 
user message.

As a regular user ,  deploy a VM.
From storage list view , select ROOT volume and create a snapshot.
On Take Snapshot notification pop up , click on OK.
Notice that you are presented withe following message:

The given command does not exist or it is not available for user 

Following api call was made by the UI:

http://10.223.49.5:8080/client/api?command=listStoragePoolsid=undefinedresponse=jsonsessionkey=4vcnR7sxOFnZcx6pUcyfnj%2BrN3o%3D_=1389134167406

{ errorresponse : 
{uuidList:[],errorcode:432,cserrorcode:,errortext:The given 
command does not exist or it is not available for user} }

This issue is not seen when testing as Admin user and happens only with 
regular users.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Assigned] (CLOUDSTACK-5749) volume live migration is failing ;org.apache.cloudstack.api.response.ExceptionResponse/null/{uuidList:[],errorcode:530,errortext:Failed to migrate volume}


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

Min Chen reassigned CLOUDSTACK-5749:


Assignee: Kelven Yang  (was: Min Chen)

 volume live migration is failing 
 ;org.apache.cloudstack.api.response.ExceptionResponse/null/{uuidList:[],errorcode:530,errortext:Failed
  to migrate volume}
 --

 Key: CLOUDSTACK-5749
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5749
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Volumes
Affects Versions: 4.3.0
 Environment: hyp:xen6.2
Reporter: prashant kumar mishra
Assignee: Kelven Yang
Priority: Critical
 Fix For: 4.3.0

 Attachments: Log_DB_ssvm.rar


 I saw this error in upgraded setup not sure if it exist in fresh  CS-4.3  
 setup also.
 Steps to reproduce
 ===
 1-preapre a ACS 4.2 setup with xen6.2
 2-upgrade it to CS4.3
 3-deploy a vm using default template
 4-add a primary storage
 5-crate a volume
 6-add volume to instance created in step 3
 7-try to migrate volume to  newly added primary storage
 Expected
 ===
 volume migration should be successful
 Actual
 =
 volume migration is failing
 Log:
 ===
 2014-01-03 07:17:00,618 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (catalina-exec-18:ctx-1353ad92 ctx-c2dcabd7) submit async job-78, details: 
 AsyncJobVO {id:78, userId: 2, accountId: 2, instanceType: None, instanceId: 
 null, cmd: org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd, 
 cmdInfo: 
 {response:json,sessionkey:iB7oDA5zlPV6nT97WFR8vxIjZi8\u003d,cmdEventType:VOLUME.MIGRATE,ctxUserId:2,storageid:61944541-60c3-3d79-999b-db96ab0e7dc6,livemigrate:true,httpmethod:GET,_:1388732216160,volumeid:8117d17f-3b83-4685-99fd-a64205b32732,ctxAccountId:2,ctxStartEventId:175},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 7145449848920, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-01-03 07:17:00,621 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-18:ctx-1353ad92 ctx-c2dcabd7) ===END===  10.252.192.25 -- GET  
 command=migrateVolumelivemigrate=truestorageid=61944541-60c3-3d79-999b-db96ab0e7dc6volumeid=8117d17f-3b83-4685-99fd-a64205b32732response=jsonsessionkey=iB7oDA5zlPV6nT97WFR8vxIjZi8%3D_=1388732216160
 2014-01-03 07:17:00,623 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
 (Job-Executor-56:ctx-ac65175b) Add job-78 into job monitoring
 2014-01-03 07:17:00,624 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (Job-Executor-56:ctx-ac65175b) Executing AsyncJobVO {id:78, userId: 2, 
 accountId: 2, instanceType: None, instanceId: null, cmd: 
 org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd, cmdInfo: 
 {response:json,sessionkey:iB7oDA5zlPV6nT97WFR8vxIjZi8\u003d,cmdEventType:VOLUME.MIGRATE,ctxUserId:2,storageid:61944541-60c3-3d79-999b-db96ab0e7dc6,livemigrate:true,httpmethod:GET,_:1388732216160,volumeid:8117d17f-3b83-4685-99fd-a64205b32732,ctxAccountId:2,ctxStartEventId:175},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 7145449848920, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-01-03 07:17:00,661 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (Job-Executor-56:ctx-ac65175b ctx-c2dcabd7) Sync job-79 execution on object 
 VmWorkJobQueue.3
 2014-01-03 07:17:01,860 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (AsyncJobMgr-Heartbeat-1:ctx-8f61216d) Execute sync-queue item: 
 SyncQueueItemVO {id:23, queueId: 17, contentType: AsyncJob, contentId: 79, 
 lastProcessMsid: null, lastprocessNumber: null, lastProcessTime: null, 
 created: Fri Jan 03 07:17:00 EST 2014}
 2014-01-03 07:17:01,863 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (AsyncJobMgr-Heartbeat-1:ctx-8f61216d) Schedule queued job-79
 2014-01-03 07:17:01,879 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
 (Job-Executor-57:ctx-da52aa8b) Add job-79 into job monitoring
 2014-01-03 07:17:01,880 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (Job-Executor-57:ctx-da52aa8b) Executing AsyncJobVO {id:79, userId: 2, 
 accountId: 2, instanceType: null, instanceId: null, cmd: 
 com.cloud.storage.VmWorkMigrateVolume, cmdInfo: 
 rO0ABXNyACVjb20uY2xvdWQuc3RvcmFnZS5WbVdvcmtNaWdyYXRlVm9sdW1l-CXzb7zvU-YCAANKAApkZXN0UG9vbElkWgALbGl2ZU1pZ3JhdGVKAAh2b2x1bWVJZHhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIAA3QAFFZvbHVtZUFwaVNlcnZpY2VJbXBsAAMBAA0,
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid:

[jira] [Commented] (CLOUDSTACK-5749) volume live migration is failing ;org.apache.cloudstack.api.response.ExceptionResponse/null/{uuidList:[],errorcode:530,errortext:Failed to migrate volume}


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864859#comment-13864859
 ] 

Min Chen commented on CLOUDSTACK-5749:
--

This seems regression from vmsync, so assign to Kelven to take a look.

 volume live migration is failing 
 ;org.apache.cloudstack.api.response.ExceptionResponse/null/{uuidList:[],errorcode:530,errortext:Failed
  to migrate volume}
 --

 Key: CLOUDSTACK-5749
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5749
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Volumes
Affects Versions: 4.3.0
 Environment: hyp:xen6.2
Reporter: prashant kumar mishra
Assignee: Min Chen
Priority: Critical
 Fix For: 4.3.0

 Attachments: Log_DB_ssvm.rar


 I saw this error in upgraded setup not sure if it exist in fresh  CS-4.3  
 setup also.
 Steps to reproduce
 ===
 1-preapre a ACS 4.2 setup with xen6.2
 2-upgrade it to CS4.3
 3-deploy a vm using default template
 4-add a primary storage
 5-crate a volume
 6-add volume to instance created in step 3
 7-try to migrate volume to  newly added primary storage
 Expected
 ===
 volume migration should be successful
 Actual
 =
 volume migration is failing
 Log:
 ===
 2014-01-03 07:17:00,618 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (catalina-exec-18:ctx-1353ad92 ctx-c2dcabd7) submit async job-78, details: 
 AsyncJobVO {id:78, userId: 2, accountId: 2, instanceType: None, instanceId: 
 null, cmd: org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd, 
 cmdInfo: 
 {response:json,sessionkey:iB7oDA5zlPV6nT97WFR8vxIjZi8\u003d,cmdEventType:VOLUME.MIGRATE,ctxUserId:2,storageid:61944541-60c3-3d79-999b-db96ab0e7dc6,livemigrate:true,httpmethod:GET,_:1388732216160,volumeid:8117d17f-3b83-4685-99fd-a64205b32732,ctxAccountId:2,ctxStartEventId:175},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 7145449848920, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-01-03 07:17:00,621 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-18:ctx-1353ad92 ctx-c2dcabd7) ===END===  10.252.192.25 -- GET  
 command=migrateVolumelivemigrate=truestorageid=61944541-60c3-3d79-999b-db96ab0e7dc6volumeid=8117d17f-3b83-4685-99fd-a64205b32732response=jsonsessionkey=iB7oDA5zlPV6nT97WFR8vxIjZi8%3D_=1388732216160
 2014-01-03 07:17:00,623 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
 (Job-Executor-56:ctx-ac65175b) Add job-78 into job monitoring
 2014-01-03 07:17:00,624 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (Job-Executor-56:ctx-ac65175b) Executing AsyncJobVO {id:78, userId: 2, 
 accountId: 2, instanceType: None, instanceId: null, cmd: 
 org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd, cmdInfo: 
 {response:json,sessionkey:iB7oDA5zlPV6nT97WFR8vxIjZi8\u003d,cmdEventType:VOLUME.MIGRATE,ctxUserId:2,storageid:61944541-60c3-3d79-999b-db96ab0e7dc6,livemigrate:true,httpmethod:GET,_:1388732216160,volumeid:8117d17f-3b83-4685-99fd-a64205b32732,ctxAccountId:2,ctxStartEventId:175},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 7145449848920, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-01-03 07:17:00,661 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (Job-Executor-56:ctx-ac65175b ctx-c2dcabd7) Sync job-79 execution on object 
 VmWorkJobQueue.3
 2014-01-03 07:17:01,860 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (AsyncJobMgr-Heartbeat-1:ctx-8f61216d) Execute sync-queue item: 
 SyncQueueItemVO {id:23, queueId: 17, contentType: AsyncJob, contentId: 79, 
 lastProcessMsid: null, lastprocessNumber: null, lastProcessTime: null, 
 created: Fri Jan 03 07:17:00 EST 2014}
 2014-01-03 07:17:01,863 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (AsyncJobMgr-Heartbeat-1:ctx-8f61216d) Schedule queued job-79
 2014-01-03 07:17:01,879 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
 (Job-Executor-57:ctx-da52aa8b) Add job-79 into job monitoring
 2014-01-03 07:17:01,880 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (Job-Executor-57:ctx-da52aa8b) Executing AsyncJobVO {id:79, userId: 2, 
 accountId: 2, instanceType: null, instanceId: null, cmd: 
 com.cloud.storage.VmWorkMigrateVolume, cmdInfo: 
 rO0ABXNyACVjb20uY2xvdWQuc3RvcmFnZS5WbVdvcmtNaWdyYXRlVm9sdW1l-CXzb7zvU-YCAANKAApkZXN0UG9vbElkWgALbGl2ZU1pZ3JhdGVKAAh2b2x1bWVJZHhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIAA3QAFFZvbHVtZUFwaVNlcnZpY2VJbXBsAAMBAA0,
  cmdVersion: 0, status:

[jira] [Updated] (CLOUDSTACK-5831) As regular user , when trying to take a snapshot , snapshot succeeds but user is presented with The given command does not exist or it is not available for user me


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

Sangeetha Hariharan updated CLOUDSTACK-5831:


Attachment: snapshot.png

 As regular user , when trying to take a snapshot , snapshot succeeds but user 
 is presented with The given command does not exist or it is not available 
 for user message.
 ---

 Key: CLOUDSTACK-5831
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5831
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.3.0
 Environment: Build from 4.3
Reporter: Sangeetha Hariharan
 Fix For: 4.3.0

 Attachments: snapshot.png


 As regular user , when trying to take a snapshot , snapshot succeeds but user 
 is presented with The given command does not exist or it is not available 
 for user message.
 As a regular user ,  deploy a VM.
 From storage list view , select ROOT volume and create a snapshot.
 On Take Snapshot notification pop up , click on OK.
 Notice that you are presented withe following message:
 The given command does not exist or it is not available for user 
 Following api call was made by the UI:
 http://10.223.49.5:8080/client/api?command=listStoragePoolsid=undefinedresponse=jsonsessionkey=4vcnR7sxOFnZcx6pUcyfnj%2BrN3o%3D_=1389134167406
 { errorresponse : 
 {uuidList:[],errorcode:432,cserrorcode:,errortext:The given 
 command does not exist or it is not available for user} }
 This issue is not seen when testing as Admin user and happens only with 
 regular users.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CLOUDSTACK-5831) As regular user , when trying to take a snapshot , snapshot succeeds but user is presented with The given command does not exist or it is not available for user me


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

Jessica Wang updated CLOUDSTACK-5831:
-

Attachment: 
the_checkin_that_causes_listStoragePoolsDoesNotExist_error_when_takeSnapshotAction_in_volumePage_is_clicked.PNG

 As regular user , when trying to take a snapshot , snapshot succeeds but user 
 is presented with The given command does not exist or it is not available 
 for user message.
 ---

 Key: CLOUDSTACK-5831
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5831
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.3.0
 Environment: Build from 4.3
Reporter: Sangeetha Hariharan
 Fix For: 4.3.0

 Attachments: snapshot.png, 
 the_checkin_that_causes_listStoragePoolsDoesNotExist_error_when_takeSnapshotAction_in_volumePage_is_clicked.PNG


 As regular user , when trying to take a snapshot , snapshot succeeds but user 
 is presented with The given command does not exist or it is not available 
 for user message.
 As a regular user ,  deploy a VM.
 From storage list view , select ROOT volume and create a snapshot.
 On Take Snapshot notification pop up , click on OK.
 Notice that you are presented withe following message:
 The given command does not exist or it is not available for user 
 Following api call was made by the UI:
 http://10.223.49.5:8080/client/api?command=listStoragePoolsid=undefinedresponse=jsonsessionkey=4vcnR7sxOFnZcx6pUcyfnj%2BrN3o%3D_=1389134167406
 { errorresponse : 
 {uuidList:[],errorcode:432,cserrorcode:,errortext:The given 
 command does not exist or it is not available for user} }
 This issue is not seen when testing as Admin user and happens only with 
 regular users.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CLOUDSTACK-2191) sanity tests for EIP : Optional public IP changes


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

Rayees Namathponnan updated CLOUDSTACK-2191:


Summary: sanity tests for EIP : Optional public IP changes   (was: 
Automate sanity tests for EIP : Optional public IP changes )

 sanity tests for EIP : Optional public IP changes 
 

 Key: CLOUDSTACK-2191
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2191
 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 f6fb4d2f6a9abe6f00ce359691bfe843f6b88895
Reporter: venkata swamybabu budumuru
Assignee: venkata swamybabu budumuru
 Fix For: 4.3.0


 Automate sanity tests to qualify the Optional publicip changes
 Here is the test plan.
 ===
 http://wiki.cloudstack.org/display/QA/Optional+Public+IP+assignment+for+EIP+with+Basic+Zone+Test+Cases



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CLOUDSTACK-5831) As regular user , when trying to take a snapshot , snapshot succeeds but user is presented with The given command does not exist or it is not available for user me


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

Jessica Wang updated CLOUDSTACK-5831:
-

Attachment: 
the_checkin_that_causes_error_TheGivinCommandDoesNotExistOrItIsNotAvailableForUser.PNG

 As regular user , when trying to take a snapshot , snapshot succeeds but user 
 is presented with The given command does not exist or it is not available 
 for user message.
 ---

 Key: CLOUDSTACK-5831
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5831
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.3.0
 Environment: Build from 4.3
Reporter: Sangeetha Hariharan
 Fix For: 4.3.0

 Attachments: snapshot.png, 
 the_checkin_that_causes_error_TheGivinCommandDoesNotExistOrItIsNotAvailableForUser.PNG


 As regular user , when trying to take a snapshot , snapshot succeeds but user 
 is presented with The given command does not exist or it is not available 
 for user message.
 As a regular user ,  deploy a VM.
 From storage list view , select ROOT volume and create a snapshot.
 On Take Snapshot notification pop up , click on OK.
 Notice that you are presented withe following message:
 The given command does not exist or it is not available for user 
 Following api call was made by the UI:
 http://10.223.49.5:8080/client/api?command=listStoragePoolsid=undefinedresponse=jsonsessionkey=4vcnR7sxOFnZcx6pUcyfnj%2BrN3o%3D_=1389134167406
 { errorresponse : 
 {uuidList:[],errorcode:432,cserrorcode:,errortext:The given 
 command does not exist or it is not available for user} }
 This issue is not seen when testing as Admin user and happens only with 
 regular users.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (CLOUDSTACK-5831) As regular user , when trying to take a snapshot , snapshot succeeds but user is presented with The given command does not exist or it is not available for user me


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

Jessica Wang updated CLOUDSTACK-5831:
-

Attachment: (was: 
the_checkin_that_causes_listStoragePoolsDoesNotExist_error_when_takeSnapshotAction_in_volumePage_is_clicked.PNG)

 As regular user , when trying to take a snapshot , snapshot succeeds but user 
 is presented with The given command does not exist or it is not available 
 for user message.
 ---

 Key: CLOUDSTACK-5831
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5831
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.3.0
 Environment: Build from 4.3
Reporter: Sangeetha Hariharan
 Fix For: 4.3.0

 Attachments: snapshot.png, 
 the_checkin_that_causes_error_TheGivinCommandDoesNotExistOrItIsNotAvailableForUser.PNG


 As regular user , when trying to take a snapshot , snapshot succeeds but user 
 is presented with The given command does not exist or it is not available 
 for user message.
 As a regular user ,  deploy a VM.
 From storage list view , select ROOT volume and create a snapshot.
 On Take Snapshot notification pop up , click on OK.
 Notice that you are presented withe following message:
 The given command does not exist or it is not available for user 
 Following api call was made by the UI:
 http://10.223.49.5:8080/client/api?command=listStoragePoolsid=undefinedresponse=jsonsessionkey=4vcnR7sxOFnZcx6pUcyfnj%2BrN3o%3D_=1389134167406
 { errorresponse : 
 {uuidList:[],errorcode:432,cserrorcode:,errortext:The given 
 command does not exist or it is not available for user} }
 This issue is not seen when testing as Admin user and happens only with 
 regular users.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Closed] (CLOUDSTACK-5406) Not able to take snapshot becasue of secondary_storage limit of 400 gb exceeded even though we have not really consumed this limit in secondary store.


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

Sangeetha Hariharan closed CLOUDSTACK-5406.
---


Closing this issue after testing with the latest build from 4.3 as per my 
previous comments .

 Not able to take snapshot becasue of secondary_storage limit of 400 gb 
 exceeded even though we have not really consumed this limit in secondary 
 store.
 --

 Key: CLOUDSTACK-5406
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5406
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
 Environment: Build from 4.3
Reporter: Sangeetha Hariharan
Assignee: Sanjay Tripathi
Priority: Critical
 Fix For: 4.3.0

 Attachments: management-server.rar, storage.rar


 Set up: 
 Xenserver setup with 2 NFS secondary stores.
 1 account having 21 Vms.
 I am using the the default secondary_storage limit which is 400 gb.
  
 Started hourly snapshot policy for all the ROOT volumes of the Vms which was 
 created from a template of size 20 gb. The actual used up size is 12 GB. 
 When  snapshot gets created , the full snapshot size is ~6.7 GB. 
  After only  2  snapshots of ROOT volume , I hit the following excepton:
  
 “2013-12-06 00:00:48,298 WARN  [c.c.s.s.SnapshotSchedulerImpl] 
 (SnapshotPollTask:ctx-a7ccb50a) Scheduling snapshot failed due to 
 com.cloud.exception.ResourceAllocationException: Maximum number of resources 
 of type 'secondary_storage' for account 
 name=test-TestParallelVolumeSnasohots-273V8U in domain id=1 has been 
 exceeded.”
  
 How are we calculating this limit ? Do we query the actual secondary store / 
 do we calculate based on the ROOT volume size and # of Snapshots.
  
 In case of Xenserve , we have Delta snapshots.We should not be 
  
 mysql select count(*) from snapshots where account_id=8 group by volume_id;
 +--+
 | count(*) |
 +--+
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |2 |
 |3 |
 |3 |
 +--+
 21 rows in set (0.00 sec)
  
  
 [root@Rack3Host5 secondary]# du -h --max-depth=1
 28G ./snapshots
 13G ./template
 4.0K./volumes
 41G .
  
  
 [root@Rack3Host8 secondary]# du -h --max-depth=1
 12G ./template
 29G ./snapshots
 4.0K./volumes
 41G .
 [root@Rack3Host8 secondary]#
 mysql select * from resource_limit;
 ++---++---+---+
 | id | domain_id | account_id | type  | max   |
 ++---++---+---+
 | 31 |  NULL |  8 | user_vm   |   200 |
 | 32 |  NULL |  8 | public_ip |   200 |
 | 33 |  NULL |  8 | volume|   200 |
 | 34 |  NULL |  8 | snapshot  |   200 |
 | 35 |  NULL |  8 | template  |   200 |
 | 36 |  NULL |  8 | vpc   |   200 |
 | 37 |  NULL |  8 | cpu   |40 |
 | 38 |  NULL |  8 | memory| 40960 |
 | 39 |  NULL |  8 | network   |20 |
 | 40 |  NULL |  8 | primary_storage   |  214748364800 |
 | 41 |  NULL |  8 | secondary_storage | 4294967296000 |
 ++---++---+---+
 11 rows in set (0.00 sec)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Issue Comment Deleted] (CLOUDSTACK-5697) multiple public ranges don't work with vxlan on KVM

2014-01-07 Thread Marcus Sorensen (JIRA)


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

Marcus Sorensen updated CLOUDSTACK-5697:


Comment: was deleted

(was: It's not related, but we know the commit that caused it and I raised the 
issue on the original bug. CLOUDSTACK-5502.)

 multiple public ranges don't work with vxlan on KVM
 ---

 Key: CLOUDSTACK-5697
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5697
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.3.0
Reporter: Marcus Sorensen
Assignee: Marcus Sorensen
 Fix For: 4.3.0


 You can add multiple VLAN/VNI network ranges to your public traffic in 
 cloudstack, these don't work with VXLAN on KVM. In other words, only guest 
 traffic type creates VNI interfaces and bridges. Tested a solution and will 
 push shortly.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Closed] (CLOUDSTACK-5697) multiple public ranges don't work with vxlan on KVM

2014-01-07 Thread Marcus Sorensen (JIRA)


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

Marcus Sorensen closed CLOUDSTACK-5697.
---

Resolution: Fixed

 multiple public ranges don't work with vxlan on KVM
 ---

 Key: CLOUDSTACK-5697
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5697
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.3.0
Reporter: Marcus Sorensen
Assignee: Marcus Sorensen
 Fix For: 4.3.0


 You can add multiple VLAN/VNI network ranges to your public traffic in 
 cloudstack, these don't work with VXLAN on KVM. In other words, only guest 
 traffic type creates VNI interfaces and bridges. Tested a solution and will 
 push shortly.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Assigned] (CLOUDSTACK-5831) As regular user , when trying to take a snapshot , snapshot succeeds but user is presented with The given command does not exist or it is not available for user m

2014-01-07 Thread edison su (JIRA)


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

edison su reassigned CLOUDSTACK-5831:
-

Assignee: edison su  (was: Chris Suich)

 As regular user , when trying to take a snapshot , snapshot succeeds but user 
 is presented with The given command does not exist or it is not available 
 for user message.
 ---

 Key: CLOUDSTACK-5831
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5831
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.3.0
 Environment: Build from 4.3
Reporter: Sangeetha Hariharan
Assignee: edison su
 Fix For: 4.3.0

 Attachments: snapshot.png, 
 the_checkin_that_causes_error_TheGivinCommandDoesNotExistOrItIsNotAvailableForUser.PNG


 As regular user , when trying to take a snapshot , snapshot succeeds but user 
 is presented with The given command does not exist or it is not available 
 for user message.
 As a regular user ,  deploy a VM.
 From storage list view , select ROOT volume and create a snapshot.
 On Take Snapshot notification pop up , click on OK.
 Notice that you are presented withe following message:
 The given command does not exist or it is not available for user 
 Following api call was made by the UI:
 http://10.223.49.5:8080/client/api?command=listStoragePoolsid=undefinedresponse=jsonsessionkey=4vcnR7sxOFnZcx6pUcyfnj%2BrN3o%3D_=1389134167406
 { errorresponse : 
 {uuidList:[],errorcode:432,cserrorcode:,errortext:The given 
 command does not exist or it is not available for user} }
 This issue is not seen when testing as Admin user and happens only with 
 regular users.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (CLOUDSTACK-5831) As regular user , when trying to take a snapshot , snapshot succeeds but user is presented with The given command does not exist or it is not available for user


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13864913#comment-13864913
 ] 

Jessica Wang commented on CLOUDSTACK-5831:
--

Edison and I just discussed this issue.
 
Edison will add a new property “storagequiescevm” in listVolumes API response.
So, listVolumes API response will be like:
{
listvolumesresponse: {
count: 1,
volume: [
{
id: 796b9dca-0e1d-4812-b6d1-dcedb411b3ca,
name: ROOT-10,
~ ~ ~
storageid: bd50af0d-2e0a-3d19-a01c-805c44544c90,
storagequiescevm: true/false
}
]
}
}
 
Then, listStoragePools API doesn’t need to be called.


 As regular user , when trying to take a snapshot , snapshot succeeds but user 
 is presented with The given command does not exist or it is not available 
 for user message.
 ---

 Key: CLOUDSTACK-5831
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5831
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.3.0
 Environment: Build from 4.3
Reporter: Sangeetha Hariharan
Assignee: edison su
 Fix For: 4.3.0

 Attachments: snapshot.png, 
 the_checkin_that_causes_error_TheGivinCommandDoesNotExistOrItIsNotAvailableForUser.PNG


 As regular user , when trying to take a snapshot , snapshot succeeds but user 
 is presented with The given command does not exist or it is not available 
 for user message.
 As a regular user ,  deploy a VM.
 From storage list view , select ROOT volume and create a snapshot.
 On Take Snapshot notification pop up , click on OK.
 Notice that you are presented withe following message:
 The given command does not exist or it is not available for user 
 Following api call was made by the UI:
 http://10.223.49.5:8080/client/api?command=listStoragePoolsid=undefinedresponse=jsonsessionkey=4vcnR7sxOFnZcx6pUcyfnj%2BrN3o%3D_=1389134167406
 { errorresponse : 
 {uuidList:[],errorcode:432,cserrorcode:,errortext:The given 
 command does not exist or it is not available for user} }
 This issue is not seen when testing as Admin user and happens only with 
 regular users.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Closed] (CLOUDSTACK-5385) Management server not able start when there ~15 snapshot policies.