date:20140610

[jira] [Created] (CLOUDSTACK-6883) Golden Primary Storage

2014-06-10 Thread Hieu LE (JIRA)

Hieu LE created CLOUDSTACK-6883:
---

 Summary: Golden Primary Storage
 Key: CLOUDSTACK-6883
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6883
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Storage Controller
Affects Versions: 4.5.0
Reporter: Hieu LE
Assignee: Hieu LE
 Fix For: 4.5.0


Currently all VMs in CloudStack have not been guaranteed IOPS from the primary 
storage, especially shared storage. In some cases (such as deploying a large 
number of VMs), this could lead to slow performance and high boot-time of VM.
In CloudStack 4.3, all VMs deployed in XenServer always have a child image VHD 
stay on the same storage repository with parent image (master image or golden 
image). Thus, this page describe a new approach in order to increase VM 
performance by decrease total IOPS in primary storage. The method is simply 
move the parent image to a new high-IOPS primary storage, similar with 
XenServer Intellicache feature. This method can reduce storage cost by 30-40%, 
compare to 80% of Intellicache.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6850) Cpu cores, cpu speed and memory are not returned by listUsageRecords

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


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

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

Commit a1f278e9d47e8029d58df6d3aae13495965ca434 in cloudstack's branch 
refs/heads/4.4-forward from [~olemasle]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a1f278e ]

CLOUDSTACK-6850: Return cpu cores, cpu speed and memory in listUsageRecords

Signed-off-by: Sebastien Goasguen run...@gmail.com


 Cpu cores, cpu speed and memory are not returned by listUsageRecords
 

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


 When using dynamic custom offerings, cpu cores, cpu speed and ram values are 
 recorded in usage_vm_instance table while parsing the usage events.
 But these details are not populated in cloud_usage table, and are not 
 returned by the listUsageRecords command. Therefore, there is no way to know 
 the historical values for cpu and memory using API.
 We should add cpu_cores, cpu_speed and memory in cloud_usage.cloud_usage and 
 return them in listUsageRecords response.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6850) Cpu cores, cpu speed and memory are not returned by listUsageRecords

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


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

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

Commit a5902f1db4b14012ecd1d5660257655e9dfe4354 in cloudstack's branch 
refs/heads/master from [~olemasle]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a5902f1 ]

CLOUDSTACK-6850: Return cpu cores, cpu speed and memory in listUsageRecords

Signed-off-by: Sebastien Goasguen run...@gmail.com


 Cpu cores, cpu speed and memory are not returned by listUsageRecords
 

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


 When using dynamic custom offerings, cpu cores, cpu speed and ram values are 
 recorded in usage_vm_instance table while parsing the usage events.
 But these details are not populated in cloud_usage table, and are not 
 returned by the listUsageRecords command. Therefore, there is no way to know 
 the historical values for cpu and memory using API.
 We should add cpu_cores, cpu_speed and memory in cloud_usage.cloud_usage and 
 return them in listUsageRecords response.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-6884) List Capacity API always returns GPU capacity also even if type is different

2014-06-10 Thread Saksham Srivastava (JIRA)

Saksham Srivastava created CLOUDSTACK-6884:
--

 Summary: List Capacity API always returns GPU capacity also even 
if type is different
 Key: CLOUDSTACK-6884
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6884
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: API
Affects Versions: 4.4.0
Reporter: Saksham Srivastava


Using cloudmonkey to test the API response:

monkey# list capacity type=2
count = 2
capacity:
capacitytotal = 5948946644992
capacityused = 1154143485952
percentused = 19.4
type = 2
zoneid = 7ea9a47c-7f39-4334-82e5-896a5d02aeb2
zonename = z1

capacitytotal = 0
capacityused = 0
percentused = 0
type = 19
zoneid = 7ea9a47c-7f39-4334-82e5-896a5d02aeb2
zonename = z1

List capacity should not return GPU capacity if type other than 19 is passed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6462) Migration of CLVM volumes to another primary storage fail

2014-06-10 Thread Salvatore Sciacco (JIRA)


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

Salvatore Sciacco commented on CLOUDSTACK-6462:
---

I modified the code to force source RAW format when the pool is of type CLVM. 
This solve the first case and it works. I'm not sure if there are side effects, 
at present it seems that CLVM storages are used always in RAW mode.

index 0760e51..18e38a2 100644
--- 
a/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java
+++ 
b/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java
@@ -966,8 +966,14 @@ public class LibvirtStorageAdaptor implements 
StorageAdaptor {
  */
 
 KVMStoragePool srcPool = disk.getPool();
-PhysicalDiskFormat sourceFormat = disk.getFormat();
 String sourcePath = disk.getPath();
+PhysicalDiskFormat sourceFormat;
+   if (srcPool.getType() == StoragePoolType.CLVM) {
+   sourceFormat = PhysicalDiskFormat.RAW;
+   } else {
+   sourceFormat = disk.getFormat();
+
+   }
 
 KVMPhysicalDisk newDisk;
 if (destPool.getType() != StoragePoolType.RBD) {

 Migration of CLVM volumes to another primary storage fail
 -

 Key: CLOUDSTACK-6462
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6462
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM, Volumes
Affects Versions: 4.2.0
 Environment: KVM clusters with fiber channel SAN storage, CLVM volumes
Reporter: Salvatore Sciacco

 ACS version: 4.2.1 
 Hypervisors: KVM 
 Storage pool type: CLVM
 Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary 
 storage pool fail. I've enabled debug on the agents side and I think there is 
 a problem with the format  type conversion
 Volume on database had format QCOW2
 these are the parameters for the first step (CLVM - NFS):
 {quote}
 srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO: 
 uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
 destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
  
 _url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
 {quote}
 Those commads are translated into the agent:
 {quote}
 DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img 
 info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197 
 DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is 
 successful.
 DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: 
 */bin/bash -c cp -f* /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197 
 /mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
  
 {quote}
 With the result that the output file isn't a qcow2 file but a raw partition, 
 which in turn make the next step fail.
 (NFS - CLVM)
 {quote}
 DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img 
 info 
 /mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
  
 DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
 DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: *qemu-img 
 convert -f qcow2 -O raw* 
 /mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
  /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 
 DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
 DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not 
 open 
 '/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
  Could not open 
 '/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
 ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to 
 convert 
 /mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
  to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was: 
 qemu-img: Could not open 
 '/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
  Could not open

[jira] [Updated] (CLOUDSTACK-6462) Migration of CLVM volumes to another primary storage fail

2014-06-10 Thread Salvatore Sciacco (JIRA)


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

Salvatore Sciacco updated CLOUDSTACK-6462:
--

Affects Version/s: 4.2.1

 Migration of CLVM volumes to another primary storage fail
 -

 Key: CLOUDSTACK-6462
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6462
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM, Volumes
Affects Versions: 4.2.0, 4.2.1
 Environment: KVM clusters with fiber channel SAN storage, CLVM volumes
Reporter: Salvatore Sciacco

 ACS version: 4.2.1 
 Hypervisors: KVM 
 Storage pool type: CLVM
 Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary 
 storage pool fail. I've enabled debug on the agents side and I think there is 
 a problem with the format  type conversion
 Volume on database had format QCOW2
 these are the parameters for the first step (CLVM - NFS):
 {noformat}
 srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO: 
 uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
 destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
  
 _url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
 {noformat}
 Those commads are translated into the agent:
 {noformat}
 DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img 
 info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197 
 DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is 
 successful.
 DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: 
 */bin/bash -c cp -f* /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197 
 /mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
  
 {noformat}
 With the result that the output file isn't a qcow2 file but a raw partition, 
 which in turn make the next step fail.
 (NFS - CLVM)
 {noformat}
 DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img 
 info 
 /mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
  
 DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
 DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: *qemu-img 
 convert -f qcow2 -O raw* 
 /mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
  /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 
 DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
 DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not 
 open 
 '/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
  Could not open 
 '/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
 ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to 
 convert 
 /mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
  to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was: 
 qemu-img: Could not open 
 '/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
  Could not open 
 '/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
 {noformat}
 If I change on the database the format of the volume to RAW the effect is 
 even worse as data is lost in the process!
 These are the parameter for the first step (CLVM = NFS)
 {noformat}
 srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:655d6965-b3f3-4118-a970d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450
 ,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-4024450VM,accountId:402,format:RAW,id:5937,hypervisorType:KVM
 destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
  
 _url:nfs://192.168.11.6/home/a1iwstack,_role:Image}},name:ROOT4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:RAW,id:5937,hypervisorType:KVM}

[jira] [Updated] (CLOUDSTACK-6462) Migration of CLVM volumes to another primary storage fail

2014-06-10 Thread Salvatore Sciacco (JIRA)


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

Salvatore Sciacco updated CLOUDSTACK-6462:
--

Description: 
ACS version: 4.2.1 
Hypervisors: KVM 
Storage pool type: CLVM

Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary 
storage pool fail. I've enabled debug on the agents side and I think there is a 
problem with the format  type conversion

Volume on database had format QCOW2

these are the parameters for the first step (CLVM - NFS):

{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO: 
uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}

destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
 
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
{quote}

Those commads are translated into the agent:
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img 
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197 
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is 
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: */bin/bash 
-c cp -f* /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197 
/mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
 
{quote}

With the result that the output file isn't a qcow2 file but a raw partition, 
which in turn make the next step fail.
(NFS - CLVM)

{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img info 
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
 
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: *qemu-img 
convert -f qcow2 -O raw* 
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
 /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not open 
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
 Could not open 
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to 
convert 
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
 to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was: 
qemu-img: Could not open 
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
 Could not open 
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
{quote}

If I change on the database the format of the volume to RAW the effect is even 
worse as data is lost in the process!

These are the parameter for the first step (CLVM = NFS)

{noformat}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:655d6965-b3f3-4118-a970d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450
,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-4024450VM,accountId:402,format:RAW,id:5937,hypervisorType:KVM

destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
 
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image}},name:ROOT4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:RAW,id:5937,hypervisorType:KVM}
{noformat}

this time the output is converted to qcow2!

{noformat}
DEBUG [utils.script.Script] (agentRequest-Handler-3:null) Executing: qemu-img 
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197 
DEBUG [utils.script.Script] (agentRequest-Handler-3:null) Execution is 
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-3:null) Executing: *qemu-img 
convert -f raw -O qcow2* /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197 
/mnt/b8311c72-fe75-3832-98fc-975445028a12/01ab129f-aaf6-4b1a-8e2a-093bee0b811c.raw
 
{noformat}

and data is lost in the next step (NFS - CLVM):

{noformat}

[jira] [Updated] (CLOUDSTACK-6462) Migration of CLVM volumes to another primary storage fail

2014-06-10 Thread Salvatore Sciacco (JIRA)


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

Salvatore Sciacco updated CLOUDSTACK-6462:
--

Description: 
ACS version: 4.2.1 
Hypervisors: KVM 
Storage pool type: CLVM

Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary 
storage pool fail. I've enabled debug on the agents side and I think there is a 
problem with the format  type conversion

Volume on database had format QCOW2

these are the parameters for the first step (CLVM - NFS):

{noformat}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO: 
uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}

destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
 
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
{noformat}

Those commads are translated into the agent:
{noformat}
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img 
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197 
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is 
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: */bin/bash 
-c cp -f* /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197 
/mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
 
{noformat}

With the result that the output file isn't a qcow2 file but a raw partition, 
which in turn make the next step fail.
(NFS - CLVM)

{noformat}
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img info 
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
 
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: *qemu-img 
convert -f qcow2 -O raw* 
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
 /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not open 
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
 Could not open 
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to 
convert 
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
 to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was: 
qemu-img: Could not open 
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
 Could not open 
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
{noformat}

If I change on the database the format of the volume to RAW the effect is even 
worse as data is lost in the process!

These are the parameter for the first step (CLVM = NFS)

{noformat}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:655d6965-b3f3-4118-a970d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450
,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-4024450VM,accountId:402,format:RAW,id:5937,hypervisorType:KVM

destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
 
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image}},name:ROOT4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:RAW,id:5937,hypervisorType:KVM}
{noformat}

this time the output is converted to qcow2!

{noformat}
DEBUG [utils.script.Script] (agentRequest-Handler-3:null) Executing: qemu-img 
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197 
DEBUG [utils.script.Script] (agentRequest-Handler-3:null) Execution is 
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-3:null) Executing: *qemu-img 
convert -f raw -O qcow2* /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197 
/mnt/b8311c72-fe75-3832-98fc-975445028a12/01ab129f-aaf6-4b1a-8e2a-093bee0b811c.raw
 
{noformat}

and data is lost in the next step (NFS - CLVM):

{noformat}

[jira] [Updated] (CLOUDSTACK-6462) Migration of CLVM volumes to another primary storage fail

2014-06-10 Thread Salvatore Sciacco (JIRA)


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

Salvatore Sciacco updated CLOUDSTACK-6462:
--

Description: 
ACS version: 4.2.1 
Hypervisors: KVM 
Storage pool type: CLVM

Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary 
storage pool fail. I've enabled debug on the agents side and I think there is a 
problem with the format  type conversion

Volume on database had format QCOW2

these are the parameters for the first step (CLVM - NFS):

{noformat}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO: 
uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}

destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
 
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
{noformat}

Those commads are translated into the agent:
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img 
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197 
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is 
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: */bin/bash 
-c cp -f* /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197 
/mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
 
{quote}

With the result that the output file isn't a qcow2 file but a raw partition, 
which in turn make the next step fail.
(NFS - CLVM)

{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img info 
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
 
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: *qemu-img 
convert -f qcow2 -O raw* 
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
 /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not open 
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
 Could not open 
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to 
convert 
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
 to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was: 
qemu-img: Could not open 
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
 Could not open 
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
{quote}

If I change on the database the format of the volume to RAW the effect is even 
worse as data is lost in the process!

These are the parameter for the first step (CLVM = NFS)

{noformat}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:655d6965-b3f3-4118-a970d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450
,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-4024450VM,accountId:402,format:RAW,id:5937,hypervisorType:KVM

destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
 
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image}},name:ROOT4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:RAW,id:5937,hypervisorType:KVM}
{noformat}

this time the output is converted to qcow2!

{noformat}
DEBUG [utils.script.Script] (agentRequest-Handler-3:null) Executing: qemu-img 
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197 
DEBUG [utils.script.Script] (agentRequest-Handler-3:null) Execution is 
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-3:null) Executing: *qemu-img 
convert -f raw -O qcow2* /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197 
/mnt/b8311c72-fe75-3832-98fc-975445028a12/01ab129f-aaf6-4b1a-8e2a-093bee0b811c.raw
 
{noformat}

and data is lost in the next step (NFS - CLVM):

{noformat}

[jira] [Updated] (CLOUDSTACK-6472) listUsageRecords generates NPEs for expunging instances

2014-06-10 Thread Rajani Karuturi (JIRA)


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

Rajani Karuturi updated CLOUDSTACK-6472:


Fix Version/s: 4.3.1
   4.4.0

 listUsageRecords generates NPEs for expunging instances
 ---

 Key: CLOUDSTACK-6472
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6472
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, Usage
Affects Versions: 4.3.0
 Environment: linux
Reporter: Pierre-Yves Ritschard
 Fix For: 4.4.0, 4.3.1

 Attachments: 0001-handle-removed-entities.patch


 The listUsageRecords API command, pulls down the list of usage records in the 
 cloud_usage database and augments records with information pulled from the 
 cloud database.
 When dealing with instance records, only instances which are do not have a 
 value for the removed field are considered. Unfortunately, since the output 
 of _entityMgr.findById is not checked this means that Null Pointer Exceptions 
 are generated when trying to access the output for expunged VMs.
 The attached patch fixes the issue and applies a similar fix for other 
 similar cases.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (CLOUDSTACK-6407) NPE while collecting VM statistics

2014-06-10 Thread Damodar Reddy T (JIRA)


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

Damodar Reddy T reassigned CLOUDSTACK-6407:
---

Assignee: Damodar Reddy T

 NPE while collecting VM statistics 
 ---

 Key: CLOUDSTACK-6407
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6407
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.0
Reporter: Sailaja Mada
Assignee: Damodar Reddy T
 Fix For: 4.4.0

 Attachments: management-server.log


 Setup : 4.4 with XenServer 6.2.5 
 1. Install and configure Adv zone using XenServer 6.2.5 
 2. Deployed 2 Windows (8 and 2012) VM's using Domain user account .
 Observed NPE's while collecting VM statistics in the Management server 
 log(Attached)
 2014-04-15 00:00:49,574 DEBUG [c.c.s.StatsCollector] 
 (StatsCollector-4:ctx-2e085056) VmStatsCollector is running...
 2014-04-15 00:00:49,588 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-69:ctx-9a19b721) Seq 1-6476457739135503930: Executing request
 2014-04-15 00:00:49,618 WARN  [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-69:ctx-9a19b721) Seq 1-6476457739135503930: Exception Caught 
 while executing command
 java.lang.NullPointerException
 2014-04-15 00:00:49,619 DEBUG [c.c.a.m.DirectAgentAttache] 
 (DirectAgent-69:ctx-9a19b721) Seq 1-6476457739135503930: Response Received:
 2014-04-15 00:00:49,619 DEBUG [c.c.a.t.Request] (DirectAgent-69:ctx-9a19b721) 
 Seq 1-6476457739135503930: Processing:  { Ans: , MgmtId: 55355881446856, via: 
 1, Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.Answer:{result:false,details:java.lang.NullPointerException,wait:0}}]
  }
 2014-04-15 00:00:49,619 DEBUG [c.c.a.t.Request] 
 (StatsCollector-4:ctx-2e085056) Seq 1-6476457739135503930: Received:  { Ans: 
 , MgmtId: 55355881446856, via: 1, Ver: v1, Flags: 10, { Answer } }
 2014-04-15 00:00:49,619 DEBUG [c.c.a.m.AgentManagerImpl] 
 (StatsCollector-4:ctx-2e085056) Details from executing class 
 com.cloud.agent.api.GetVmStatsCommand: java.lang.NullPointerException
 2014-04-15 00:00:49,619 WARN  [c.c.v.UserVmManagerImpl] 
 (StatsCollector-4:ctx-2e085056) Unable to obtain VM statistics.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6884) List Capacity API always returns GPU capacity also even if type is different

2014-06-10 Thread Saksham Srivastava (JIRA)


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

Saksham Srivastava updated CLOUDSTACK-6884:
---

Assignee: Sanjay Tripathi  (was: Saksham Srivastava)

 List Capacity API always returns GPU capacity also even if type is different
 

 Key: CLOUDSTACK-6884
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6884
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API
Affects Versions: 4.4.0
Reporter: Saksham Srivastava
Assignee: Sanjay Tripathi

 Using cloudmonkey to test the API response:
 monkey# list capacity type=2
 count = 2
 capacity:
 capacitytotal = 5948946644992
 capacityused = 1154143485952
 percentused = 19.4
 type = 2
 zoneid = 7ea9a47c-7f39-4334-82e5-896a5d02aeb2
 zonename = z1
 
 capacitytotal = 0
 capacityused = 0
 percentused = 0
 type = 19
 zoneid = 7ea9a47c-7f39-4334-82e5-896a5d02aeb2
 zonename = z1
 List capacity should not return GPU capacity if type other than 19 is passed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (CLOUDSTACK-6884) List Capacity API always returns GPU capacity also even if type is different

2014-06-10 Thread Saksham Srivastava (JIRA)


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

Saksham Srivastava reassigned CLOUDSTACK-6884:
--

Assignee: Saksham Srivastava

 List Capacity API always returns GPU capacity also even if type is different
 

 Key: CLOUDSTACK-6884
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6884
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API
Affects Versions: 4.4.0
Reporter: Saksham Srivastava
Assignee: Saksham Srivastava

 Using cloudmonkey to test the API response:
 monkey# list capacity type=2
 count = 2
 capacity:
 capacitytotal = 5948946644992
 capacityused = 1154143485952
 percentused = 19.4
 type = 2
 zoneid = 7ea9a47c-7f39-4334-82e5-896a5d02aeb2
 zonename = z1
 
 capacitytotal = 0
 capacityused = 0
 percentused = 0
 type = 19
 zoneid = 7ea9a47c-7f39-4334-82e5-896a5d02aeb2
 zonename = z1
 List capacity should not return GPU capacity if type other than 19 is passed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-6885) system-vm rsyslog logs rotation does not work properly

2014-06-10 Thread JF Vincent (JIRA)

JF Vincent created CLOUDSTACK-6885:
--

 Summary: system-vm rsyslog logs rotation does not work properly
 Key: CLOUDSTACK-6885
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6885
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: SystemVM
Affects Versions: 4.3.0
Reporter: JF Vincent
Priority: Critical


rsyslog reload synthax is bad in the logrotate.d/rsyslog setting resulting in 
potential FULL on /var/ and critical failures on the VR.

See below please : 

root@r-1346-SANDBOX:/var/log# more /etc/logrotate.d/rsyslog
/var/log/syslog
{
rotate 7
daily
missingok
notifempty
delaycompress
compress
postrotate
invoke-rc.d rsyslog rotate  /dev/null
endscript
}

/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
rotate 10
daily
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
invoke-rc.d rsyslog rotate  /dev/null
endscript
}

root@r-1346-SANDBOX:/var/log# /etc/init.d/rsyslog reload
Usage: /etc/init.d/rsyslog {start|stop|rotate|restart|force-reload|status}
root@r-1346-SANDBOX:/var/log# /etc/init.d/rsyslog rotate
[ ok ] Closing open files: rsyslogd.

reload argument in the invoke-rc.d line shoud be replaced by rotate 
argument.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6885) system-vm rsyslog logs rotation does not work properly

2014-06-10 Thread JF Vincent (JIRA)


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

JF Vincent updated CLOUDSTACK-6885:
---

Description: 
rsyslog reload synthax is bad in the logrotate.d/rsyslog setting resulting in 
potential FULL on /var/ and critical failures on the VR.

See below please : 

root@r-1346-SANDBOX:/var/log# more /etc/logrotate.d/rsyslog
/var/log/syslog
{
rotate 7
daily
missingok
notifempty
delaycompress
compress
postrotate
invoke-rc.d rsyslog reload  /dev/null
endscript
}

/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
rotate 10
daily
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
invoke-rc.d rsyslog reload  /dev/null
endscript
}

root@r-1346-SANDBOX:/var/log# /etc/init.d/rsyslog reload
Usage: /etc/init.d/rsyslog {start|stop|rotate|restart|force-reload|status}
root@r-1346-SANDBOX:/var/log# /etc/init.d/rsyslog rotate
[ ok ] Closing open files: rsyslogd.

reload argument in the invoke-rc.d line shoud be replaced by rotate 
argument.

  was:
rsyslog reload synthax is bad in the logrotate.d/rsyslog setting resulting in 
potential FULL on /var/ and critical failures on the VR.

See below please : 

root@r-1346-SANDBOX:/var/log# more /etc/logrotate.d/rsyslog
/var/log/syslog
{
rotate 7
daily
missingok
notifempty
delaycompress
compress
postrotate
invoke-rc.d rsyslog rotate  /dev/null
endscript
}

/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
rotate 10
daily
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
invoke-rc.d rsyslog rotate  /dev/null
endscript
}

root@r-1346-SANDBOX:/var/log# /etc/init.d/rsyslog reload
Usage: /etc/init.d/rsyslog {start|stop|rotate|restart|force-reload|status}
root@r-1346-SANDBOX:/var/log# /etc/init.d/rsyslog rotate
[ ok ] Closing open files: rsyslogd.

reload argument in the invoke-rc.d line shoud be replaced by rotate 
argument.


 system-vm rsyslog logs rotation does not work properly
 --

 Key: CLOUDSTACK-6885
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6885
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: SystemVM
Affects Versions: 4.3.0
Reporter: JF Vincent
Priority: Critical

 rsyslog reload synthax is bad in the logrotate.d/rsyslog setting resulting in 
 potential FULL on /var/ and critical failures on the VR.
 See below please : 
 root@r-1346-SANDBOX:/var/log# more /etc/logrotate.d/rsyslog
 /var/log/syslog
 {
 rotate 7
 daily
 missingok
 notifempty
 delaycompress
 compress
 postrotate
 invoke-rc.d rsyslog reload  /dev/null
 endscript
 }
 /var/log/mail.info
 /var/log/mail.warn
 /var/log/mail.err
 /var/log/mail.log
 /var/log/daemon.log
 /var/log/kern.log
 /var/log/auth.log
 /var/log/user.log
 /var/log/lpr.log
 /var/log/cron.log
 /var/log/debug
 /var/log/messages
 {
 rotate 10
 daily
 missingok
 notifempty
 compress
 delaycompress
 sharedscripts
 postrotate
 invoke-rc.d rsyslog reload  /dev/null
 endscript
 }
 root@r-1346-SANDBOX:/var/log# /etc/init.d/rsyslog reload
 Usage: /etc/init.d/rsyslog {start|stop|rotate|restart|force-reload|status}
 root@r-1346-SANDBOX:/var/log# /etc/init.d/rsyslog rotate
 [ ok ] Closing open files: rsyslogd.
 reload argument in the invoke-rc.d line shoud be replaced by rotate 
 argument.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6869) Public key content is overridden by template's meta data when you create a instance

2014-06-10 Thread Daan Hoogland (JIRA)


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

Daan Hoogland updated CLOUDSTACK-6869:
--

Security: Public  (was: Non-Public)

 Public key content is overridden by template's meta data when you create a 
 instance
 ---

 Key: CLOUDSTACK-6869
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6869
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API, Management Server, Template
Affects Versions: Future, 4.3.0, 4.4.0, 4.5.0
Reporter: Hiroki Ohashi
Assignee: Harikrishna Patnala
Priority: Critical
 Fix For: 4.4.0, 4.5.0


 A public key content is overridden by detail value of 'SSH.PublicKey' from a 
 template created by an instance ROOT volume with public key specification.
 This results in delivery of the template owner's ssh key for a instance 
 created from the template to virtual router inspite of specification of 
 instance owner's ssh key.
 It is caused by import of resource detail values at commitUserVm method like 
 below.
 {code}
 MapString, String details = template.getDetails();
 if (details != null  !details.isEmpty()) {
 vm.details.putAll(details);
 }
 {code}
 Reproduction procedure:
 # Deploy an instance with a ssh key A by specifying 'keypair' value.
 # Create a template from this instance.
 # Deploy an instance with another ssh key B by specifying 'keypair' value.
 Database example:
 {noformat}
 mysql select * from cloud.template_view where id=207 \G;
 *** 1. row ***
   id: 207
 uuid: c96f0d9a-0a56-4d30-af73-fe8b31ae37c3
  unique_name: 2219faa5a-4e7b-3425-b6e6-135ab210422b
 name: cluster_frontend-20140520.2
   public: 1
 featured: 0
 type: USER
  hvm: 1
 bits: 64
  url: NULL
   format: QCOW2
  created: 2014-05-20 09:33:47
 checksum: NULL
 display_text: Cluster Frontend VM CentOS 6.5 ver.20140520.2
  enable_password: 1
 dynamically_scalable: 0
   template_state: Active
  guest_os_id: 182
guest_os_uuid: 9d3c42d8-caab-11e3-9125-001e679910a0
guest_os_name: CentOS 6.4 (64-bit)
 bootable: 1
  prepopulate: 0
  cross_zones: 0
  hypervisor_type: KVM
  extractable: 0
 template_tag: NULL
 sort_key: 0
  removed: NULL
enable_sshkey: 0
   source_template_id: 205
 source_template_uuid: c131680c-3e0e-4d7c-b554-02dabc10ade1
   account_id: 3
 account_uuid: f9e4e1ca-69fd-4ae3-b70c-15bbcc13406e
 account_name: sgcadm
 account_type: 0
domain_id: 2
  domain_uuid: 84dd635d-fb99-4895-b199-7d777aa144d5
  domain_name: default
  domain_path: /default/
   project_id: NULL
 project_uuid: NULL
 project_name: NULL
   data_center_id: NULL
 data_center_uuid: NULL
 data_center_name: NULL
lp_account_id: NULL
 store_id: 3
  store_scope: REGION
state: Ready
   download_state: DOWNLOADED
 download_pct: 100
error_str: NULL
 size: 18465816576
destroyed: 0
 created_on_store: 2014-05-20 09:33:47
  detail_name: Message.ReservedCapacityFreed.Flag
 detail_value: false
   tag_id: NULL
 tag_uuid: NULL
  tag_key: NULL
tag_value: NULL
tag_domain_id: NULL
   tag_account_id: NULL
  tag_resource_id: NULL
tag_resource_uuid: NULL
tag_resource_type: NULL
 tag_customer: NULL
   temp_zone_pair: 207_0
 *** 2. row ***
   id: 207
 uuid: c96f0d9a-0a56-4d30-af73-fe8b31ae37c3
  unique_name: 2219faa5a-4e7b-3425-b6e6-135ab210422b
 name: cluster_frontend-20140520.2
   public: 1
 featured: 0
 type: USER
  hvm: 1
 bits: 64
  url: NULL
   format: QCOW2
  created: 2014-05-20 09:33:47
 checksum: NULL
 display_text: Cluster Frontend VM CentOS 6.5 ver.20140520.2
  enable_password: 1
 dynamically_scalable: 0
   template_state: Active
  guest_os_id: 182
guest_os_uuid: 9d3c42d8-caab-11e3-9125-001e679910a0
guest_os_name: CentOS 6.4 (64-bit)
 bootable: 1
  prepopulate: 0

[jira] [Commented] (CLOUDSTACK-6864) UploadSSlCert API requires double encoding of URL params

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


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

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

Commit c5ee5ad5c828d9f0b128e3d7280a30dcf717e045 in cloudstack's branch 
refs/heads/4.4-forward from [~saksham]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c5ee5ad ]

CLOUDSTACK-6864: UploadSSlCert API requires double encoding of URL params


 UploadSSlCert API requires double encoding of URL params
 

 Key: CLOUDSTACK-6864
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6864
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API
Affects Versions: 4.4.0
Reporter: Saksham Srivastava
Assignee: Saksham Srivastava

 uploadSslCert API requires double UTF-8 encoding of the parameters 
 (certificate, privatekey, certchain) in the URL.
 This is because there are 2 decodes happening (First in API Server : handle
 paramList = URLEncodedUtils.parse )new 
 URI(request.getRequestLine().getUri()), UTF_8)
 and the Second one in the API definition:
 CertServiceImpl:uploadSslCert
 String cert = URLDecoder.decode(certCmd.getCert(), UTF-8); )



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-6850) Cpu cores, cpu speed and memory are not returned by listUsageRecords

2014-06-10 Thread Olivier Lemasle (JIRA)


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

Olivier Lemasle resolved CLOUDSTACK-6850.
-

Resolution: Fixed

 Cpu cores, cpu speed and memory are not returned by listUsageRecords
 

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


 When using dynamic custom offerings, cpu cores, cpu speed and ram values are 
 recorded in usage_vm_instance table while parsing the usage events.
 But these details are not populated in cloud_usage table, and are not 
 returned by the listUsageRecords command. Therefore, there is no way to know 
 the historical values for cpu and memory using API.
 We should add cpu_cores, cpu_speed and memory in cloud_usage.cloud_usage and 
 return them in listUsageRecords response.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6777) [Automation]: Test case failure in test_secondary_storage.py

2014-06-10 Thread Girish Shilamkar (JIRA)


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

Girish Shilamkar commented on CLOUDSTACK-6777:
--

Could not reproduce

 [Automation]: Test case failure in test_secondary_storage.py
 

 Key: CLOUDSTACK-6777
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6777
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, KVM, Xen
Affects Versions: 4.4.0
Reporter: Harikrishna Patnala
Assignee: Girish Shilamkar
 Fix For: 4.4.0

 Attachments: KVM_test_02_sys_template_ready_REPORT.rtf, vmops.log


 There is test case failure in test_secondary_storage.py
 1) 
 integration.smoke.test_secondary_storage.TestSecStorageServices.test_02_sys_template_ready
 Error Message
 Builtin template is not ready No route to host in zone 
 9459d36e-a477-4a60-890b-2bc48edf1410
   begin captured stdout  -
 === TestName: test_02_sys_template_ready | Status : FAILED ===
 Attached Test reports and Management server logs



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6850) Cpu cores, cpu speed and memory are not returned by listUsageRecords

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


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

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

Commit c934e7b052c09df2fae52a005e69951ed0235574 in cloudstack's branch 
refs/heads/4.4 from [~olemasle]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c934e7b ]

CLOUDSTACK-6850: Return cpu cores, cpu speed and memory in listUsageRecords

Signed-off-by: Sebastien Goasguen run...@gmail.com
(cherry picked from commit a1f278e9d47e8029d58df6d3aae13495965ca434)


 Cpu cores, cpu speed and memory are not returned by listUsageRecords
 

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


 When using dynamic custom offerings, cpu cores, cpu speed and ram values are 
 recorded in usage_vm_instance table while parsing the usage events.
 But these details are not populated in cloud_usage table, and are not 
 returned by the listUsageRecords command. Therefore, there is no way to know 
 the historical values for cpu and memory using API.
 We should add cpu_cores, cpu_speed and memory in cloud_usage.cloud_usage and 
 return them in listUsageRecords response.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6358) Remove hardcoded guest OS mappings

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


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

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

Commit b490da25ba57471d128426fd7ad4b347f4be in cloudstack's branch 
refs/heads/4.4 from [~amogh.vasekar]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b490da2 ]

CLOUDSTACK-6358: Remove hardcoded VMware mappings, handle snapshots

(cherry picked from commit a4b401f29f83f2f0b467a9d05b509f951b5a3bca)


 Remove hardcoded guest OS mappings
 --

 Key: CLOUDSTACK-6358
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6358
 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: Amogh Vasekar
Assignee: Amogh Vasekar
Priority: Critical
 Fix For: 4.4.0


 The guest OS to platform emulator mappings are hardcoded in the codebase.
 This needs to be removed so as to support dynamic addition of guest OS type



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6603) [Upgrade]DB Exception while Autoscale monitoring after upgrading from 4.3 to 4.4

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


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

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

Commit fc7d0b2a333e510619f14528a72e35bbf9ed7045 in cloudstack's branch 
refs/heads/4.4 from [~rajesh_battala]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fc7d0b2 ]

CLOUDSTACK-6603 [Upgrade]DB Exception while Autoscale monitoring after 
upgrading from 4.3 to 4.4

(cherry picked from commit c282bb3a1293fbbfdb306263ea52464862670fb3)


 [Upgrade]DB Exception while Autoscale monitoring after upgrading from 4.3 to 
 4.4
 

 Key: CLOUDSTACK-6603
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6603
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Upgrade
Affects Versions: 4.4.0
Reporter: manasaveloori
Assignee: Rajesh Battala
Priority: Blocker
 Fix For: 4.4.0

 Attachments: management-server.rar, mysqldump43.dmp, mysqldump44.dmp


 1. Deploy CS 4.3 with 2 zones using xen 6.1 and KVM hypervisor.
 2. Configured LB rules,firewall rules.
 3. Registered the template for 4.4 (using the naming convention 
 systemvm-xenserver-4.4,systemvm-kvm-4.4)
 4. Upgraded to 4.4
 Start the management server:
 Below are the observations:
 2014-05-05 05:05:13,567 DEBUG [c.c.s.StatsCollector] 
 (StatsCollector-4:ctx-e36f20e1) AutoScaling Monitor is running...
 2014-05-05 05:05:13,577 ERROR [c.c.s.StatsCollector] 
 (StatsCollector-4:ctx-e36f20e1) Error trying to monitor autoscaling
 com.cloud.utils.exception.CloudRuntimeException: DB Exception on: 
 com.mysql.jdbc.JDBC4PreparedStatement@5b140551: SELECT autoscale_vmgroups.id, 
 autoscale_vmgroups.uuid, autoscale_vmgroups.zone_id, 
 autoscale_vmgroups.domain_id, autoscale_vmgroups.account_id, 
 autoscale_vmgroups.load_balancer_id, autoscale_vmgroups.min_members, 
 autoscale_vmgroups.max_members, autoscale_vmgroups.member_port, 
 autoscale_vmgroups.interval, autoscale_vmgroups.last_interval, 
 autoscale_vmgroups.profile_id, autoscale_vmgroups.removed, 
 autoscale_vmgroups.created, autoscale_vmgroups.state, 
 autoscale_vmgroups.display FROM autoscale_vmgroups WHERE 
 autoscale_vmgroups.removed IS NULL
 at com.cloud.utils.db.GenericDaoBase.executeList(GenericDaoBase.java:1127)
 at com.cloud.utils.db.GenericDaoBase.listAll(GenericDaoBase.java:1150)
 at com.cloud.utils.db.GenericDaoBase.listAll(GenericDaoBase.java:1136)
 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:606)
 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.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
 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.$Proxy220.listAll(Unknown Source)
 at 
 com.cloud.server.StatsCollector$AutoScaleMonitor.runInContext(StatsCollector.java:673)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
 at

[jira] [Commented] (CLOUDSTACK-6710) [Automation] VM snapshot failing with NPE in vmware

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


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

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

Commit 04665ee2564ee924c3b6379a34b9bca8a25b94b5 in cloudstack's branch 
refs/heads/4.4 from [~amogh.vasekar]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=04665ee ]

CLOUDSTACK-6710: Add missing OS mappings

(cherry picked from commit ac92b3690304ff224e7e2530ea7d8e39f28a05c3)


 [Automation] VM snapshot failing with NPE in vmware
 ---

 Key: CLOUDSTACK-6710
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6710
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.4.0
 Environment: Vmware 5.0
 4.4-forward 
Reporter: Rayees Namathponnan
Assignee: Amogh Vasekar
Priority: Blocker
 Fix For: 4.4.0

 Attachments: management-server.rar


 Execute BVT 
 integration.smoke.test_vm_snapshots.TestVmSnapshot.test_01_create_vm_snapshots
 This test case creating VM snapshot in VMware; this is failing with below NPE 
 2014-05-19 13:12:00,378 DEBUG [c.c.v.VmWorkJobDispatcher] 
 (Work-Job-Executor-130:job-390/job-391) Run VM work job: 
 com.cloud.vm.snapshot.VmWorkCreateVMSn
 apshot for VM 62, job origin: 390
 2014-05-19 13:12:00,384 DEBUG [c.c.v.VmWorkJobHandlerProxy] 
 (Work-Job-Executor-130:job-390/job-391 ctx-538be870) Execute VM work job: 
 com.cloud.vm.snapsh
 ot.VmWorkCreateVMSnapshot{vmSnapshotId:1,quiesceVm:false,userId:2,accountId:2,vmId:62,handlerName:VMSnapshotManagerImpl}
 2014-05-19 13:12:00,517 DEBUG [c.c.v.s.VMSnapshotManagerImpl] 
 (Work-Job-Executor-130:job-390/job-391 ctx-538be870) Failed to create vm 
 snapshot: 1
 java.lang.NullPointerException
 at 
 org.apache.cloudstack.storage.vmsnapshot.DefaultVMSnapshotStrategy.takeVMSnapshot(DefaultVMSnapshotStrategy.java:139)
 at 
 com.cloud.vm.snapshot.VMSnapshotManagerImpl.orchestrateCreateVMSnapshot(VMSnapshotManagerImpl.java:422)
 at 
 com.cloud.vm.snapshot.VMSnapshotManagerImpl.orchestrateCreateVMSnapshot(VMSnapshotManagerImpl.java:1048)
 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:606)
 at 
 com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
 at 
 com.cloud.vm.snapshot.VMSnapshotManagerImpl.handleVmWorkJob(VMSnapshotManagerImpl.java:1072)
 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:606)
 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 com.sun.proxy.$Proxy182.handleVmWorkJob(Unknown Source)
 at 
 com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:496)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:453)
 at

[jira] [Resolved] (CLOUDSTACK-6775) [Automation]: Test case failure in test_iso.py

2014-06-10 Thread Girish Shilamkar (JIRA)


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

Girish Shilamkar resolved CLOUDSTACK-6775.
--

Resolution: Duplicate

 [Automation]: Test case failure in test_iso.py
 --

 Key: CLOUDSTACK-6775
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6775
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, KVM
Affects Versions: 4.4.0
Reporter: Harikrishna Patnala
Assignee: Girish Shilamkar
 Fix For: 4.4.0


 There is test case failure in test_non_contigiousvlan.py
 1)integration.smoke.test_non_contigiousvlan.TestUpdatePhysicalNetwork.test_extendPhysicalNetworkVlan
 Error Message
 Job failed: {jobprocstatus : 0, created : u'2014-05-26T13:36:06-0700', cmd : 
 u'org.apache.cloudstack.api.command.admin.network.UpdatePhysicalNetworkCmd', 
 userid : u'40470752-e504-11e3-af30-00163e5d4a0e', jobstatus : 2, jobid : 
 u'168af076-cd18-44f2-997d-bbb55b7c12ad', jobresultcode : 530, jobresulttype : 
 u'object', jobresult : {errorcode : 530, errortext : u'physicalnetwork 200 
 has allocated vnets in the range 4090-4095'}, accountid : 
 u'4046c30a-e504-11e3-af30-00163e5d4a0e'}
 Attached Test report and management server logs



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6055) [Automation] Firewall rule creation failing for portable public IP with error Failed to create firewall rule

2014-06-10 Thread Murali Reddy (JIRA)


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

Murali Reddy commented on CLOUDSTACK-6055:
--

This particular issue has been reported failing in Vmware environment 
previously also. On XenServer i belive this test case never failed.

Also, last when i checked i could not reproduce the issue. I will give it try 
one more time. On Next run when this test fails, it would be report if same use 
case succeeds when run manually.

 [Automation] Firewall rule creation failing for portable public IP with error 
 Failed to create firewall rule
 --

 Key: CLOUDSTACK-6055
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6055
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.4.0
 Environment: Observed yet on VMWare.
Reporter: Gaurav Aradhye
Assignee: Murali Reddy
  Labels: automation
 Fix For: 4.4.0

 Attachments: portableip-Firewall-MgtSrvrLog.txt


 Steps to reproduce:
 1) Add a portable public IP range
 2) Create an isolated network
 3) Acquire portable IP in the network
 4) Try to create firewall rule for the IP address
 Step 4 Fails.
 Management Server log attached.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6654) Configkey parameters are not validated

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


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

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

Commit 5bcd017de6f421a6125406120b39fb8602276dc7 in cloudstack's branch 
refs/heads/4.4-forward from [~saksham]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5bcd017 ]

CLOUDSTACK-6654: Configkey parameters are not validated


 Configkey parameters are not validated
 --

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


 There is no validation for the values of ConfigKey variables. So one can give 
 anything like -5.6 or “pqr” or ‘#*99abc’  as the value of cpu/memory/storage 
 over-provision factors or any other variables in ConfigKey framework.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-6886) Cannot add SDX Netscaler device

2014-06-10 Thread Pierre-Luc Dion (JIRA)

Pierre-Luc Dion created CLOUDSTACK-6886:
---

 Summary: Cannot add SDX Netscaler device
 Key: CLOUDSTACK-6886
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6886
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Devices
Affects Versions: 4.3.0
 Environment: CloudStack 4.3 build with noredist packages
Reporter: Pierre-Luc Dion


on CloudStack 4.3 with noredist packages, Adding a Netscaler device in Network 
Service Providers as NetScaler SDX LoadBalancer type failed with following 
error message:

Failed to enable ssl feature on load balancer due to null

Test perform using CloudStack webui.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6886) Cannot add SDX Netscaler device

2014-06-10 Thread Pierre-Luc Dion (JIRA)


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

Pierre-Luc Dion updated CLOUDSTACK-6886:


Attachment: cs4.3_SDXfail.png

 Cannot add SDX Netscaler device
 ---

 Key: CLOUDSTACK-6886
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6886
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Devices
Affects Versions: 4.3.0
 Environment: CloudStack 4.3 build with noredist packages
Reporter: Pierre-Luc Dion
 Attachments: cs4.3_SDXfail.png


 on CloudStack 4.3 with noredist packages, Adding a Netscaler device in 
 Network Service Providers as NetScaler SDX LoadBalancer type failed with 
 following error message:
 Failed to enable ssl feature on load balancer due to null
 Test perform using CloudStack webui.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6886) Cannot add SDX Netscaler device

2014-06-10 Thread Pierre-Luc Dion (JIRA)


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

Pierre-Luc Dion commented on CLOUDSTACK-6886:
-

{code}
2014-06-10 09:51:27,311 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(Job-Executor-39:ctx-10f9f920) Add job-685 into job monitoring
2014-06-10 09:51:27,311 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(Job-Executor-39:ctx-10f9f920) Executing AsyncJobVO {id:685, userId: 2, 
accountId: 2, instanceType: None, instanceId: null, cmd: 
com.cloud.api.commands.AddNetscalerLoadBalancerCmd, cmdInfo: 
{physicalnetworkid:a0091e19-63df-4147-abe7-da843444f656,sessionkey:tzSipsZZFnJzPJSz0UAxUTLNJtY\u003d,cmdEventType:PHYSICAL.LOADBALANCER.ADD,gslbprovider:false,ctxUserId:2,httpmethod:POST,gslbproviderpublicip:,password:nsroot,url:https://172.16.0.20?publicinterface\u003d1/1\u0026privateinterface\u003d1/2\u0026numretries\u003d2\u0026lbdevicededicated\u003dfalse,response:json,username:nsroot,networkdevicetype:NetscalerSDXLoadBalancer,gslbproviderprivateip:,ctxAccountId:2,ctxStartEventId:3420},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 6692297244834, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}
2014-06-10 09:51:28,113 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(Job-Executor-39:ctx-10f9f920) Complete async job-685, jobStatus: FAILED, 
resultCode: 530, result: 
org.apache.cloudstack.api.response.ExceptionResponse/null/{uuidList:[],errorcode:530,errortext:Failed
 to enable ssl feature on load balancer due to null}
{code}

 Cannot add SDX Netscaler device
 ---

 Key: CLOUDSTACK-6886
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6886
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Devices
Affects Versions: 4.3.0
 Environment: CloudStack 4.3 build with noredist packages
Reporter: Pierre-Luc Dion
 Attachments: cs4.3_SDXfail.png


 on CloudStack 4.3 with noredist packages, Adding a Netscaler device in 
 Network Service Providers as NetScaler SDX LoadBalancer type failed with 
 following error message:
 Failed to enable ssl feature on load balancer due to null
 Test perform using CloudStack webui.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-6887) [Automation] Test cases not deleting account after complete the test

2014-06-10 Thread Rayees Namathponnan (JIRA)

Rayees Namathponnan created CLOUDSTACK-6887:
---

 Summary: [Automation] Test cases not deleting account after 
complete the test 
 Key: CLOUDSTACK-6887
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6887
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Affects Versions: 4.4.0
Reporter: Rayees Namathponnan
 Fix For: 4.4.0


Still there are test cases not deleting account after complete the test, i can 
see below account exist in management server , after complete regression, 

As per management server log,these account are not even tried to delete the 
account 

1) test-account-TestDeployVmWithAffinityGroup-GTFNV7



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6887) [Automation] Test cases not deleting account after complete the test

2014-06-10 Thread Rayees Namathponnan (JIRA)


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

Rayees Namathponnan updated CLOUDSTACK-6887:


Description: 
Still there are test cases not deleting account after complete the test, i can 
see below account exist in management server , after complete regression, 

As per management server log,these account are not even tried to delete the 
account 

1) test-account-TestDeployVmWithAffinityGroup-GTFNV7
2) test-TestAccountSnapshotClean-C1M23S
3) test-TestSnapshotLimit-XWVZAT
4) test-TestVolumes-test_01_volume_iso_attach-C3KHZK
5) test-TestVolumes-test_create_volume_under_domain-9SC6RP
6) test-TestVpnUsage-test_01_snapshot_usage-QREFF2
7) test-TestVpnUsage-test_01_snapshot_usage-TBKTOK
8) 
test-TestVPCNetworkUpgrade-test_05_create_network_diff_account_1_network_offering-1KF0TL
9) 

  was:
Still there are test cases not deleting account after complete the test, i can 
see below account exist in management server , after complete regression, 

As per management server log,these account are not even tried to delete the 
account 

1) test-account-TestDeployVmWithAffinityGroup-GTFNV7


 [Automation] Test cases not deleting account after complete the test 
 -

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


 Still there are test cases not deleting account after complete the test, i 
 can see below account exist in management server , after complete regression, 
 As per management server log,these account are not even tried to delete the 
 account 
 1) test-account-TestDeployVmWithAffinityGroup-GTFNV7
 2) test-TestAccountSnapshotClean-C1M23S
 3) test-TestSnapshotLimit-XWVZAT
 4) test-TestVolumes-test_01_volume_iso_attach-C3KHZK
 5) test-TestVolumes-test_create_volume_under_domain-9SC6RP
 6) test-TestVpnUsage-test_01_snapshot_usage-QREFF2
 7) test-TestVpnUsage-test_01_snapshot_usage-TBKTOK
 8) 
 test-TestVPCNetworkUpgrade-test_05_create_network_diff_account_1_network_offering-1KF0TL
 9) 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6887) [Automation] Test cases not deleting account after complete the test

2014-06-10 Thread Rayees Namathponnan (JIRA)


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

Rayees Namathponnan updated CLOUDSTACK-6887:


Description: 
Still there are test cases not deleting account after complete the test, i can 
see below account exist in management server , after complete regression, 

As per management server log,these account are not even tried to delete the 
account 

1) test-account-TestDeployVmWithAffinityGroup-GTFNV7
2) test-TestAccountSnapshotClean-C1M23S
3) test-TestSnapshotLimit-XWVZAT
4) test-TestVolumes-test_01_volume_iso_attach-C3KHZK
5) test-TestVolumes-test_create_volume_under_domain-9SC6RP
6) test-TestVpnUsage-test_01_snapshot_usage-QREFF2
7) test-TestVpnUsage-test_01_snapshot_usage-TBKTOK
8) 
test-TestVPCNetworkUpgrade-test_05_create_network_diff_account_1_network_offering-1KF0TL
9) 
test-TestPortableIpTransferAcrossNetworks-test_create_portable_ip_range_non_root_admin-EAKO69
10) 
test-TestPortableIpTransferAcrossNetworks-test_disassociate_ip_address_other_account-CJJ0S6
11)test_add_remove_network_vm-TestUpdateVirtualMachineNIC-test_24_add_nw_different_domain-PKXXHF
12) test-account-TestVPCNetworkOperations-test_vpc_delete_account-Y28RMP
13) test-account-TestVPCNetworkOperations-test_vpc_force_delete_domain-NJTE7Y
14) 

  was:
Still there are test cases not deleting account after complete the test, i can 
see below account exist in management server , after complete regression, 

As per management server log,these account are not even tried to delete the 
account 

1) test-account-TestDeployVmWithAffinityGroup-GTFNV7
2) test-TestAccountSnapshotClean-C1M23S
3) test-TestSnapshotLimit-XWVZAT
4) test-TestVolumes-test_01_volume_iso_attach-C3KHZK
5) test-TestVolumes-test_create_volume_under_domain-9SC6RP
6) test-TestVpnUsage-test_01_snapshot_usage-QREFF2
7) test-TestVpnUsage-test_01_snapshot_usage-TBKTOK
8) 
test-TestVPCNetworkUpgrade-test_05_create_network_diff_account_1_network_offering-1KF0TL
9) 


 [Automation] Test cases not deleting account after complete the test 
 -

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


 Still there are test cases not deleting account after complete the test, i 
 can see below account exist in management server , after complete regression, 
 As per management server log,these account are not even tried to delete the 
 account 
 1) test-account-TestDeployVmWithAffinityGroup-GTFNV7
 2) test-TestAccountSnapshotClean-C1M23S
 3) test-TestSnapshotLimit-XWVZAT
 4) test-TestVolumes-test_01_volume_iso_attach-C3KHZK
 5) test-TestVolumes-test_create_volume_under_domain-9SC6RP
 6) test-TestVpnUsage-test_01_snapshot_usage-QREFF2
 7) test-TestVpnUsage-test_01_snapshot_usage-TBKTOK
 8) 
 test-TestVPCNetworkUpgrade-test_05_create_network_diff_account_1_network_offering-1KF0TL
 9) 
 test-TestPortableIpTransferAcrossNetworks-test_create_portable_ip_range_non_root_admin-EAKO69
 10) 
 test-TestPortableIpTransferAcrossNetworks-test_disassociate_ip_address_other_account-CJJ0S6
 11)test_add_remove_network_vm-TestUpdateVirtualMachineNIC-test_24_add_nw_different_domain-PKXXHF
 12) test-account-TestVPCNetworkOperations-test_vpc_delete_account-Y28RMP
 13) test-account-TestVPCNetworkOperations-test_vpc_force_delete_domain-NJTE7Y
 14) 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-6710) [Automation] VM snapshot failing with NPE in vmware

2014-06-10 Thread Amogh Vasekar (JIRA)


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

Amogh Vasekar resolved CLOUDSTACK-6710.
---

Resolution: Fixed

 [Automation] VM snapshot failing with NPE in vmware
 ---

 Key: CLOUDSTACK-6710
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6710
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.4.0
 Environment: Vmware 5.0
 4.4-forward 
Reporter: Rayees Namathponnan
Assignee: Amogh Vasekar
Priority: Blocker
 Fix For: 4.4.0

 Attachments: management-server.rar


 Execute BVT 
 integration.smoke.test_vm_snapshots.TestVmSnapshot.test_01_create_vm_snapshots
 This test case creating VM snapshot in VMware; this is failing with below NPE 
 2014-05-19 13:12:00,378 DEBUG [c.c.v.VmWorkJobDispatcher] 
 (Work-Job-Executor-130:job-390/job-391) Run VM work job: 
 com.cloud.vm.snapshot.VmWorkCreateVMSn
 apshot for VM 62, job origin: 390
 2014-05-19 13:12:00,384 DEBUG [c.c.v.VmWorkJobHandlerProxy] 
 (Work-Job-Executor-130:job-390/job-391 ctx-538be870) Execute VM work job: 
 com.cloud.vm.snapsh
 ot.VmWorkCreateVMSnapshot{vmSnapshotId:1,quiesceVm:false,userId:2,accountId:2,vmId:62,handlerName:VMSnapshotManagerImpl}
 2014-05-19 13:12:00,517 DEBUG [c.c.v.s.VMSnapshotManagerImpl] 
 (Work-Job-Executor-130:job-390/job-391 ctx-538be870) Failed to create vm 
 snapshot: 1
 java.lang.NullPointerException
 at 
 org.apache.cloudstack.storage.vmsnapshot.DefaultVMSnapshotStrategy.takeVMSnapshot(DefaultVMSnapshotStrategy.java:139)
 at 
 com.cloud.vm.snapshot.VMSnapshotManagerImpl.orchestrateCreateVMSnapshot(VMSnapshotManagerImpl.java:422)
 at 
 com.cloud.vm.snapshot.VMSnapshotManagerImpl.orchestrateCreateVMSnapshot(VMSnapshotManagerImpl.java:1048)
 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:606)
 at 
 com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
 at 
 com.cloud.vm.snapshot.VMSnapshotManagerImpl.handleVmWorkJob(VMSnapshotManagerImpl.java:1072)
 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:606)
 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 com.sun.proxy.$Proxy182.handleVmWorkJob(Unknown Source)
 at 
 com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:496)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:453)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at

[jira] [Resolved] (CLOUDSTACK-6358) Remove hardcoded guest OS mappings

2014-06-10 Thread Amogh Vasekar (JIRA)


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

Amogh Vasekar resolved CLOUDSTACK-6358.
---

Resolution: Fixed

 Remove hardcoded guest OS mappings
 --

 Key: CLOUDSTACK-6358
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6358
 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: Amogh Vasekar
Assignee: Amogh Vasekar
Priority: Critical
 Fix For: 4.4.0


 The guest OS to platform emulator mappings are hardcoded in the codebase.
 This needs to be removed so as to support dynamic addition of guest OS type



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6888) [Automation] Portable IP test cases not picking the ips from config file, always picking data from test case or test data file

2014-06-10 Thread Rayees Namathponnan (JIRA)


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

Rayees Namathponnan commented on CLOUDSTACK-6888:
-

Test cases fails with below error 


Error Message

Execute cmd: createportableiprange failed, due to: errorCode: 431, errorText:Ip 
 range: 10.223.252.196-10.223.252.197 overlaps with a portable IP range already 
configured in the region 1
  begin captured stdout  -
=== TestName: test_list_portable_ip_range | Status : EXCEPTION ===


-  end captured stdout  --
  begin captured logging  
test_disassociate_ip_address_services_enabled 
(integration.component.test_portable_ip.TestDisassociatePublicIp): DEBUG: 
Payload: {'apiKey': 
u'rv4IBxTIKzc6h-tY3uK6cR801RPQNpbw70XfDHRSl8K6ACvAAlRW6eGXHDhwcixa6xqp1TpuWhVpK88ilBrjQw',
 'id': u'b4004a91-d3df-47cd-bb8e-bed08c6e0a08', 'state': 'Disabled', 'command': 
'updateNetworkOffering', 'signature': '4Uy6LYRzRRoLtRda0ibMYCQuu6Q=', 
'response': 'json'}
test_disassociate_ip_address_services_enabled 
(integration.component.test_portable_ip.TestDisassociatePublicIp): DEBUG: 
Sending GET Cmd : updateNetworkOffering===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.223.49.195
requests.packages.urllib3.connectionpool: DEBUG: GET 
/client/api?apiKey=rv4IBxTIKzc6h-tY3uK6cR801RPQNpbw70XfDHRSl8K6ACvAAlRW6eGXHDhwcixa6xqp1TpuWhVpK88ilBrjQwid=b4004a91-d3df-47cd-bb8e-bed08c6e0a08state=Disabledcommand=updateNetworkOfferingsignature=4Uy6LYRzRRoLtRda0ibMYCQuu6Q%3Dresponse=json
 HTTP/1.1 200 1671
test_disassociate_ip_address_services_enabled 
(integration.component.test_portable_ip.TestDisassociatePublicIp): DEBUG: 
Response : {supportsstrechedl2subnet : False, specifyipranges : False, 
conservemode : False, name : u'Network offering portable ip-O06REA', service : 
[{name : u'Vpn', provider : [{name : u'VirtualRouter'}]}, {name : u'Dns', 
provider : [{name : u'VirtualRouter'}]}, {name : u'PortForwarding', provider : 
[{name : u'VirtualRouter'}]}, {capability : [{value : u'false', name : 
u'ElasticIp', canchooseservicecapability : False}, {value : u'false', name : 
u'AssociatePublicIP', canchooseservicecapability : False}], name : 
u'StaticNat', provider : [{name : u'VirtualRouter'}]}, {name : u'Dhcp', 
provider : [{name : u'VirtualRouter'}]}, {name : u'UserData', provider : [{name 
: u'VirtualRouter'}]}, {name : u'Firewall', provider : [{name : 
u'VirtualRouter'}]}, {capability : [{value : u'shared', name : 
u'SupportedLBIsolation', canchooseservicecapability : False}, {value : 
u'false', name : u'ElasticLb', canchooseservicecapability : False}, {value : 
u'false', name : u'InlineMode', canchooseservicecapability : False}], name : 
u'Lb', provider : [{name : u'VirtualRouter'}]}, {capability : [{value : 
u'peraccount', name : u'SupportedSourceNatTypes', canchooseservicecapability : 
False}, {value : u'false', name : u'RedundantRouter', 
canchooseservicecapability : False}], name : u'SourceNat', provider : [{name : 
u'VirtualRouter'}]}], networkrate : 200, guestiptype : u'Isolated', 
availability : u'Optional', traffictype : u'Guest', state : u'Disabled', 
ispersistent : False, displaytext : u'Network offering-VR services-30B14X', 
specifyvlan : False, id : u'b4004a91-d3df-47cd-bb8e-bed08c6e0a08', forvpc : 
False, serviceofferingid : u'c2046853-907c-4a3e-9cd6-ae38c481b451', isdefault : 
False, egressdefaultpolicy : True}
test_disassociate_ip_address_services_enabled 
(integration.component.test_portable_ip.TestDisassociatePublicIp): DEBUG: 
Payload: {'signature': 'M0g3euwxp8KMxazVDuwJc7EVsgw=', 'apiKey': 
u'rv4IBxTIKzc6h-tY3uK6cR801RPQNpbw70XfDHRSl8K6ACvAAlRW6eGXHDhwcixa6xqp1TpuWhVpK88ilBrjQw',
 'command': 'deleteAccount', 'id': u'8d5fddb3-6fde-44f5-a39d-cdbad7211d9f', 
'response': 'json'}

 [Automation] Portable IP test cases not picking the ips from config file, 
 always picking data from test case or test data file
 --

 Key: CLOUDSTACK-6888
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6888
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.4.0
Reporter: Rayees Namathponnan
Priority: Critical
 Fix For: 4.4.0


 i configured below information in config file,   but test case never pick 
 this during automation run, 
 portableIpRange: {
 gateway : 10.223.122.65,
 netmask : 255.255.255.192,
 startip : 10.223.122.120,
 endip   : 10.223.122.121,
 vlan: 2359

[jira] [Created] (CLOUDSTACK-6888) [Automation] Portable IP test cases not picking the ips from config file, always picking data from test case or test data file

2014-06-10 Thread Rayees Namathponnan (JIRA)

Rayees Namathponnan created CLOUDSTACK-6888:
---

 Summary: [Automation] Portable IP test cases not picking the ips 
from config file, always picking data from test case or test data file
 Key: CLOUDSTACK-6888
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6888
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Affects Versions: 4.4.0
Reporter: Rayees Namathponnan
Priority: Critical
 Fix For: 4.4.0


i configured below information in config file,   but test case never pick this 
during automation run, 

portableIpRange: {
gateway : 10.223.122.65,
netmask : 255.255.255.192,
startip : 10.223.122.120,
endip   : 10.223.122.121,
vlan: 2359
   }



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6862) [Automation] Test case TestDeployvGPUenabledVM.test_deploy_vgpu_enabled_vm faling during BVT

2014-06-10 Thread Rayees Namathponnan (JIRA)


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

Rayees Namathponnan commented on CLOUDSTACK-6862:
-

We need to skip this test for KVM 

 [Automation] Test case TestDeployvGPUenabledVM.test_deploy_vgpu_enabled_vm 
 faling during BVT 
 -

 Key: CLOUDSTACK-6862
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6862
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.4.0
Reporter: Rayees Namathponnan
Priority: Blocker
 Fix For: 4.4.0


 Test case 
 integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM.test_deploy_vgpu_enabled_vm
  failing in BVT 
 Error Message
 Execute cmd: createserviceoffering failed, due to: errorCode: 401, 
 errorText:unable to verify user credentials and/or request signature
   begin captured stdout  -
 === TestName: test_deploy_vgpu_enabled_vm | Status : EXCEPTION ===
 -  end captured stdout  --
   begin captured logging  
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: STARTED : TC: test_deploy_vgpu_enabled_vm :::
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Payload: {'apiKey': 
 u'8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5A',
  'command': 'listDomains', 'signature': '8Yh5KlFqCsxhD/NB2fOBHSPL1kI=', 
 'response': 'json'}
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Sending GET Cmd : listDomains===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 172.16.88.21
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?apiKey=8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5Acommand=listDomainsresponse=jsonsignature=8Yh5KlFqCsxhD%2FNB2fOBHSPL1kI%3D
  HTTP/1.1 200 159
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Response : [{path : u'ROOT', haschild : False, id : 
 u'6b3a436e-ef1f-11e3-a141-00163e189e44', name : u'ROOT', level : 0}]
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Payload: {'apiKey': 
 u'8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5A',
  'name': 'zone-xen', 'command': 'listZones', 'signature': 
 'Z7nIBao2vEVG1YiHM2kVrh6QcPY=', 'response': 'json'}
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Sending GET Cmd : listZones===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 172.16.88.21
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?response=jsonapiKey=8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5Acommand=listZonesname=zone-xensignature=Z7nIBao2vEVG1YiHM2kVrh6QcPY%3D
  HTTP/1.1 200 446
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Response : [{localstorageenabled : False, name : u'zone-xen', 
 guestcidraddress : u'10.1.1.0/24', tags : [], zonetoken : 
 u'562e3c93-9149-38c6-8555-de48e3e6c847', dns2 : u'8.8.4.4', dns1 : 
 u'8.8.8.8', securitygroupsenabled : False, allocationstate : u'Enabled', 
 internaldns1 : u'172.16.88.7', dhcpprovider : u'VirtualRouter', networktype : 
 u'Advanced', id : u'ad43d834-dc57-4da5-b3ae-0ef3f106192b', internaldns2 : 
 u'172.16.88.8'}]
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Payload: {'apiKey': 
 u'8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5A',
  'templatefilter': 'featured', 'command': 'listTemplates', 'signature': 
 'KGHcOyWgw042qhRsMQWkZ7VdUIM=', 'zoneid': 
 u'ad43d834-dc57-4da5-b3ae-0ef3f106192b', 'response': 'json'}
 test_deploy_vgpu_enabled_vm 
 (integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM): 
 DEBUG: Sending GET Cmd : listTemplates===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 172.16.88.21
 requests.packages.urllib3.connectionpool: DEBUG: GET

[jira] [Commented] (CLOUDSTACK-5907) KVM/CLVM volumes are shown as Ovm hypervisor

2014-06-10 Thread Tanner Danzey (JIRA)


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

Tanner Danzey commented on CLOUDSTACK-5907:
---

That's actually a far better way to remedy this, I'll have to see what I
can do. The patch I submitted is a little hacky (but it did get included!)


On Tue, Jun 3, 2014 at 1:04 PM, Dmitry Komarov (JIRA) j...@apache.org




-- 
*Tanner Danzey*
Systems Engineer
Northstar Technology Group
arkan...@gmail.com / tanner.dan...@northstar-tg.com
(701) 237-9096 x7122


 KVM/CLVM volumes are shown as Ovm hypervisor
 

 Key: CLOUDSTACK-5907
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5907
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API, KVM, Oracle VM (OVM), Storage Controller, UI
Affects Versions: 4.2.1, 4.3.0
 Environment: KVM, CLVM
Reporter: Nux
  Labels: clvm, kvm, ovm, storage
 Attachments: storage1.png, storage2.png


 It looks like ACS is showing KVM volumes on CLVM primary storage as being for 
 Oracle hypervisor.
 http://i.imgur.com/E4InCV2.png
 The API shows the same so it's not a UI glitch.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-6889) UI - create network offering - remove non-needed parameters from API call whose size might exceed limit in some cases.

2014-06-10 Thread Jessica Wang (JIRA)

Jessica Wang created CLOUDSTACK-6889:


 Summary: UI - create network offering - remove non-needed 
parameters from API call whose size might exceed limit in some cases.
 Key: CLOUDSTACK-6889
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6889
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Reporter: Jessica Wang
Assignee: Jessica Wang






--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6889) UI - create network offering - remove non-needed parameters from API call whose size might exceed limit in some cases.

2014-06-10 Thread Jessica Wang (JIRA)


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

Jessica Wang commented on CLOUDSTACK-6889:
--

https://issues.citrite.net/i#browse/ES-2177

 UI - create network offering - remove non-needed parameters from API call 
 whose size might exceed limit in some cases.
 --

 Key: CLOUDSTACK-6889
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6889
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Reporter: Jessica Wang
Assignee: Jessica Wang





--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6889) UI - create network offering - remove non-needed parameters from API call whose size might exceed limit in some cases.

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


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

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

Commit 64825549d2eb4e6c55b9cc2730e0ac895473f901 in cloudstack's branch 
refs/heads/4.4-forward from [~jessicawang]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6482554 ]

CLOUDSTACK-6889: UI - create network offering - remove non-needed parameters 
from API call whose size might exceed limit in some cases.


 UI - create network offering - remove non-needed parameters from API call 
 whose size might exceed limit in some cases.
 --

 Key: CLOUDSTACK-6889
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6889
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Reporter: Jessica Wang
Assignee: Jessica Wang





--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-6889) UI - create network offering - remove non-needed parameters from API call whose size might exceed limit in some cases.

2014-06-10 Thread Jessica Wang (JIRA)


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

Jessica Wang resolved CLOUDSTACK-6889.
--

Resolution: Fixed

 UI - create network offering - remove non-needed parameters from API call 
 whose size might exceed limit in some cases.
 --

 Key: CLOUDSTACK-6889
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6889
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Reporter: Jessica Wang
Assignee: Jessica Wang





--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6889) UI - create network offering - remove non-needed parameters from API call whose size might exceed limit in some cases.

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


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

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

Commit 9334f26084070dbd36fde97057a372b9d5517a91 in cloudstack's branch 
refs/heads/master from [~jessicawang]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9334f26 ]

CLOUDSTACK-6889: UI - create network offering - remove non-needed parameters 
from API call whose size might exceed limit in some cases.


 UI - create network offering - remove non-needed parameters from API call 
 whose size might exceed limit in some cases.
 --

 Key: CLOUDSTACK-6889
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6889
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Reporter: Jessica Wang
Assignee: Jessica Wang





--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Closed] (CLOUDSTACK-6889) UI - create network offering - remove non-needed parameters from API call whose size might exceed limit in some cases.

2014-06-10 Thread Jessica Wang (JIRA)


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

Jessica Wang closed CLOUDSTACK-6889.



 UI - create network offering - remove non-needed parameters from API call 
 whose size might exceed limit in some cases.
 --

 Key: CLOUDSTACK-6889
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6889
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Reporter: Jessica Wang
Assignee: Jessica Wang





--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (CLOUDSTACK-6889) UI - create network offering - remove non-needed parameters from API call whose size might exceed limit in some cases.

2014-06-10 Thread Jessica Wang (JIRA)


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

Jessica Wang edited comment on CLOUDSTACK-6889 at 6/10/14 10:07 PM:


https://issues.citrite.net/i#browse/ES-2177

https://issues.citrite.net/i#browse/CS-20251




was (Author: jessicawang):
https://issues.citrite.net/i#browse/ES-2177

 UI - create network offering - remove non-needed parameters from API call 
 whose size might exceed limit in some cases.
 --

 Key: CLOUDSTACK-6889
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6889
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Reporter: Jessica Wang
Assignee: Jessica Wang





--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-6859) Management Server PermGen run out of memory after some time due to class leak.

2014-06-10 Thread Min Chen (JIRA)


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

Min Chen resolved CLOUDSTACK-6859.
--

Resolution: Fixed

 Management Server PermGen run out of memory after some time due to class leak.
 --

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


 In our async callback framework, we are using cglib to create an Enhancer 
 class for each async callback setup. These new Enhancer classes are created 
 per each async operation, this is causing class leak, leading to PermGen out 
 of memory after MS is running for some time.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-6890) createVPC invoked by admin does not observe start flag.

2014-06-10 Thread Min Chen (JIRA)

Min Chen created CLOUDSTACK-6890:


 Summary: createVPC invoked by admin does not observe start flag.
 Key: CLOUDSTACK-6890
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6890
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: API
Affects Versions: 4.4.0
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
 Fix For: 4.4.0


When admin is invoking createVPC command, it will still start VPC even if the 
parameter start=false.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-6891) [Automation] - port 8096 is being used when executing the suite when admin’s keys are not generated before execution of the suite.

2014-06-10 Thread Sangeetha Hariharan (JIRA)

Sangeetha Hariharan created CLOUDSTACK-6891:
---

 Summary: [Automation] - port 8096 is being used when executing the 
suite when admin’s keys are not generated before execution of the suite.
 Key: CLOUDSTACK-6891
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6891
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: marvin
Affects Versions: 4.4.0
 Environment: Marvin builds from 4.4-forward branch
Reporter: Sangeetha Hariharan


port 8096 is being used for the entire suite in the following scenario:

api/secret key is not present for the admin user  and as part of executing a 
test suite , we generate the secret and api key for admin user.This happens 
when the very first test suite is executed after the setup is created and 
admin’s keys are not generated yet.

In __createApiClient method of cloudstackTestClient.py , mgmt_details.port is 
not set explicitly to “8080” ,  when there is a need to generate the keys. In 
such cases , we default to using port “8096” which is defined as part of the 
configuration file.





--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6890) createVPC invoked by admin does not observe start flag.

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


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

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

Commit 09a357fb90b48ed6e2725ea60e632a2ad5529f79 in cloudstack's branch 
refs/heads/4.4-forward from [~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=09a357f ]

CLOUDSTACK-6890:createVPC invoked by admin does not observe start flag.

 createVPC invoked by admin does not observe start flag.
 ---

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


 When admin is invoking createVPC command, it will still start VPC even if the 
 parameter start=false.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6890) createVPC invoked by admin does not observe start flag.

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


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

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

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

CLOUDSTACK-6890:createVPC invoked by admin does not observe start flag.


 createVPC invoked by admin does not observe start flag.
 ---

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


 When admin is invoking createVPC command, it will still start VPC even if the 
 parameter start=false.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6812) For storage type which does not support over provisioning ,over provisioning factor shold be 1

2014-06-10 Thread Saksham Srivastava (JIRA)


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

Saksham Srivastava commented on CLOUDSTACK-6812:


I agree with the non modifiable part.
I don't think we should be having a different default for non supported types. 
This is not consistent.
All pools should have a similar default value. 
In future if we start supporting other types, there should be a consistency 
across pools.

 For storage type which does not support over provisioning ,over provisioning 
 factor shold be 1 
 ---

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


 currently over provisioning is supported for only nfs and vmfs ,for storage 
 type like lvm, iscsi  over provisioning is not supported ,default value of 
 over provisioning factor should be 1 . and it should be non modifiable. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6886) Cannot add SDX Netscaler device

2014-06-10 Thread Rajesh Battala (JIRA)


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

Rajesh Battala commented on CLOUDSTACK-6886:


is license activated on the device?

 Cannot add SDX Netscaler device
 ---

 Key: CLOUDSTACK-6886
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6886
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Devices
Affects Versions: 4.3.0
 Environment: CloudStack 4.3 build with noredist packages
Reporter: Pierre-Luc Dion
 Attachments: cs4.3_SDXfail.png


 on CloudStack 4.3 with noredist packages, Adding a Netscaler device in 
 Network Service Providers as NetScaler SDX LoadBalancer type failed with 
 following error message:
 Failed to enable ssl feature on load balancer due to null
 Test perform using CloudStack webui.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (CLOUDSTACK-6887) [Automation] Test cases not deleting account after complete the test

2014-06-10 Thread Gaurav Aradhye (JIRA)


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

Gaurav Aradhye reassigned CLOUDSTACK-6887:
--

Assignee: Gaurav Aradhye

 [Automation] Test cases not deleting account after complete the test 
 -

 Key: CLOUDSTACK-6887
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6887
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.4.0
Reporter: Rayees Namathponnan
Assignee: Gaurav Aradhye
 Fix For: 4.4.0


 Still there are test cases not deleting account after complete the test, i 
 can see below account exist in management server , after complete regression, 
 As per management server log,these account are not even tried to delete the 
 account 
 1) test-account-TestDeployVmWithAffinityGroup-GTFNV7
 2) test-TestAccountSnapshotClean-C1M23S
 3) test-TestSnapshotLimit-XWVZAT
 4) test-TestVolumes-test_01_volume_iso_attach-C3KHZK
 5) test-TestVolumes-test_create_volume_under_domain-9SC6RP
 6) test-TestVpnUsage-test_01_snapshot_usage-QREFF2
 7) test-TestVpnUsage-test_01_snapshot_usage-TBKTOK
 8) 
 test-TestVPCNetworkUpgrade-test_05_create_network_diff_account_1_network_offering-1KF0TL
 9) 
 test-TestPortableIpTransferAcrossNetworks-test_create_portable_ip_range_non_root_admin-EAKO69
 10) 
 test-TestPortableIpTransferAcrossNetworks-test_disassociate_ip_address_other_account-CJJ0S6
 11)test_add_remove_network_vm-TestUpdateVirtualMachineNIC-test_24_add_nw_different_domain-PKXXHF
 12) test-account-TestVPCNetworkOperations-test_vpc_delete_account-Y28RMP
 13) test-account-TestVPCNetworkOperations-test_vpc_force_delete_domain-NJTE7Y
 14) test-account-TestVPCNetworkOperations-test_vpc_force_delete_domain-9MLF0N
 15) test-TestVPC-test_15_deploy_vm_2-1I5L2M
 16) DoA-TestVPC-test_18_create_net_for_user_diff_domain_by_doadmin-80A4XM
 17) test-TestUserLogin-test_01_non_root_admin_Privileges-MCQ3HG
 18) 
 test-TestProjectSuspendActivate-test_08_cleanup_after_project_delete-MT8L6G



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6780) integration.component.test_portable_ip.TestDisassociatePublicIp.test_disassociate_ip_address_other_account failed during cleanup

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


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

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

Commit 0190c936689fc252e51b7c412283c128b5386b24 in cloudstack's branch 
refs/heads/4.4-forward from [~ashutoshk]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0190c93 ]

CLOUDSTACK-6780: Resolved cleanup issue in portable ip test cases


 integration.component.test_portable_ip.TestDisassociatePublicIp.test_disassociate_ip_address_other_account
  failed during cleanup
 

 Key: CLOUDSTACK-6780
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6780
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.4.0
 Environment: VMware
Reporter: Ashutosk Kelkar
Assignee: Ashutosk Kelkar
  Labels: automation
 Fix For: 4.4.0


 Warning: Exception during cleanup : Job failed: {jobprocstatus : 0, created : 
 u'2014-05-26T14:19:26-0700', cmd : 
 u'org.apache.cloudstack.api.command.admin.region.DeletePortableIpRangeCmd', 
 userid : u'7fff39d0-e506-11e3-a257-52b2d980df8a', jobstatus : 2, jobid : 
 u'2e7ff9e0-b012-42d2-bb9d-46ff18d4325d', jobresultcode : 530, jobresulttype : 
 u'object', jobresult : {errorcode : 530, errortext : uCan't delete portable 
 IP range as there are IP's assigned.}, accountid : 
 u'7fff2cec-e506-11e3-a257-52b2d980df8a'}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6702) [Windows] Give Details to admin as messages When system properties are changed

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


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

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

Commit 23280a47b800fb434b1fa0d7ee0401a6777dec39 in cloudstack's branch 
refs/heads/master from [~damoder.reddy]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=23280a4 ]

CLOUDSTACK-6702 : [Windows]Due to Progress bar changes mysql path was not 
getting read. Fixing the same.

Signed-off-by: Abhinandan Prateek aprat...@apache.org


 [Windows] Give Details to admin as messages When system properties are changed
 --

 Key: CLOUDSTACK-6702
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6702
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup
Affects Versions: 4.5.0
Reporter: Damodar Reddy T
Assignee: Damodar Reddy T
 Fix For: 4.5.0


 1. Give necessary progress bar messages to admin before changing the system 
 properties like environment varibales, firewall rules etc..
 2. Move all titles and descriptions to a property file or move to build 
 properties



--
This message was sent by Atlassian JIRA
(v6.2#6252)

55 matches

Mail list logo