[jira] [Closed] (CLOUDSTACK-4922) Vmware :agent is not up in system VM using 64 bit system VM templates

2013-11-18 Thread shweta agarwal (JIRA)

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

shweta agarwal closed CLOUDSTACK-4922.
--


Verified . fixed

 Vmware :agent is not up in system VM using 64 bit system VM  templates
 --

 Key: CLOUDSTACK-4922
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4922
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: VMware
Affects Versions: 4.2.1
 Environment: advance Vmware 5.1 version zone with 64 bit system Vm  
 templates available at :
 http://download.cloud.com/templates/4.2/64bit/systemvmtemplate64.ova
Reporter: shweta agarwal
Assignee: Sateesh Chodapuneedi
Priority: Blocker
 Fix For: 4.2.1

 Attachments: 70-persistent-cd.rules, cloud.dmp, 
 management-server.log.tar.gz, ssvm.jpg


 Repro steps:
 Installed Ms
 Seeded the 64 bit systemVm template for vmware in secondary storage
 Created an advanced zone
 SSVM and CPVM are up but agent has not started
 Bug:
 Agent on System Vm has not started as a result Template download failed
 MS log shows :
 2013-10-22 14:51:56,796 INFO  [storage.endpoint.DefaultEndPointSelector] 
 (StatsCollector-1:null) No running ssvm is found, so command will be sent to 
 LocalHostEndPoint
 attaching Ms logs and Database dumps
 attached SSVM log as jpeg
  file
 Findings by Jaypal 
 in SSVM with 64 bit template cdrom1 and xvdd   is missed under /dev location
 May be systemvm.iso patch got failed because4 of it .



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (CLOUDSTACK-4973) CLONE - Specified keyboard language is not showing as default in consoleView passed during deployVM

2013-11-18 Thread Sanjay Tripathi (JIRA)

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

Sanjay Tripathi updated CLOUDSTACK-4973:


Priority: Critical  (was: Major)

 CLONE - Specified keyboard language is not showing as default in consoleView 
 passed during deployVM
 ---

 Key: CLOUDSTACK-4973
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4973
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: VNC Proxy
Affects Versions: 4.1.0, 4.2.0
Reporter: Sanjay Tripathi
Assignee: Sanjay Tripathi
Priority: Critical
 Fix For: 4.3.0


 While deploying a VM, user passes the keyboard parameter to specify the 
 default language for that VM but in the consoleView, the default language 
 selected is en-us irrespective of the default language of the VM. 
 To change the language, user has to navigate through the dropdown menu 
 provided in consoleView.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Created] (CLOUDSTACK-5193) [Hyper-V] VHDs not deleted post VM destroy and expunge

2013-11-18 Thread Sowmya Krishnan (JIRA)
Sowmya Krishnan created CLOUDSTACK-5193:
---

 Summary: [Hyper-V] VHDs not deleted post VM destroy and expunge
 Key: CLOUDSTACK-5193
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5193
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server, Storage Controller
Affects Versions: 4.3.0
 Environment: Hyper-V
Reporter: Sowmya Krishnan
Priority: Critical
 Fix For: 4.3.0


Create a VM with local/shared storage offering.
Destroy the VM with expunge = true or destroy and wait for VM to expunge.

Although VM is destroyed and volume is marked removed in cloud DB, it is not 
removed from the hypervisor disk. I don't find .storage.command.DeleteCommand 
being triggered as part of the Destroy VM.

As seen below, vhd corresponding to VM i-2-27-VM still resides in the host:

C:\Users\Public\Documents\Hyper-V\Virtual hard disksdir /W ROOT-27.vhd
 Volume in drive C has no label.
 Volume Serial Number is 7C16-4C80

 Directory of C:\Users\Public\Documents\Hyper-V\Virtual hard disks

ROOT-27.vhd
   1 File(s)  3,120,370,688 bytes
   0 Dir(s)  892,863,770,624 bytes free

C:\Users\Public\Documents\Hyper-V\Virtual hard disks

SQL output for the destroyed VM volume:

mysql select * from volumes where id = 28\G
*** 1. row ***
id: 28
account_id: 2
 domain_id: 1
   pool_id: 1
  last_pool_id: NULL
   instance_id: 27
 device_id: 0
  name: ROOT-27
  uuid: fe491447-52fb-413e-a7a0-339c573f154f
  size: 1073741824
folder: NULL
  path: NULL
pod_id: NULL
data_center_id: 1
iscsi_name: NULL
   host_ip: NULL
   volume_type: ROOT
 pool_type: NULL
  disk_offering_id: 13
   template_id: 204
first_snapshot_backup_uuid: NULL
   recreatable: 0
   created: 2013-11-18 09:22:46
  attached: NULL
   updated: 2013-11-18 09:27:03
   removed: 2013-11-18 09:27:03
 state: Destroy
chain_info: NULL
  update_count: 4
 disk_type: NULL
vm_snapshot_chain_size: NULL
iso_id: NULL
display_volume: 1
format: NULL
  min_iops: NULL
  max_iops: NULL
 hv_ss_reserve: NULL
1 row in set (0.00 sec)




--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (CLOUDSTACK-5193) [Hyper-V] VHDs not deleted post VM destroy and expunge

2013-11-18 Thread Sowmya Krishnan (JIRA)

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

Sowmya Krishnan updated CLOUDSTACK-5193:


Attachment: destroyvm.log

Attaching destroy VM logs

 [Hyper-V] VHDs not deleted post VM destroy and expunge
 --

 Key: CLOUDSTACK-5193
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5193
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, Storage Controller
Affects Versions: 4.3.0
 Environment: Hyper-V
Reporter: Sowmya Krishnan
Priority: Critical
 Fix For: 4.3.0

 Attachments: destroyvm.log


 Create a VM with local/shared storage offering.
 Destroy the VM with expunge = true or destroy and wait for VM to expunge.
 Although VM is destroyed and volume is marked removed in cloud DB, it is not 
 removed from the hypervisor disk. I don't find .storage.command.DeleteCommand 
 being triggered as part of the Destroy VM.
 As seen below, vhd corresponding to VM i-2-27-VM still resides in the host:
 C:\Users\Public\Documents\Hyper-V\Virtual hard disksdir /W ROOT-27.vhd
  Volume in drive C has no label.
  Volume Serial Number is 7C16-4C80
  Directory of C:\Users\Public\Documents\Hyper-V\Virtual hard disks
 ROOT-27.vhd
1 File(s)  3,120,370,688 bytes
0 Dir(s)  892,863,770,624 bytes free
 C:\Users\Public\Documents\Hyper-V\Virtual hard disks
 SQL output for the destroyed VM volume:
 mysql select * from volumes where id = 28\G
 *** 1. row ***
 id: 28
 account_id: 2
  domain_id: 1
pool_id: 1
   last_pool_id: NULL
instance_id: 27
  device_id: 0
   name: ROOT-27
   uuid: fe491447-52fb-413e-a7a0-339c573f154f
   size: 1073741824
 folder: NULL
   path: NULL
 pod_id: NULL
 data_center_id: 1
 iscsi_name: NULL
host_ip: NULL
volume_type: ROOT
  pool_type: NULL
   disk_offering_id: 13
template_id: 204
 first_snapshot_backup_uuid: NULL
recreatable: 0
created: 2013-11-18 09:22:46
   attached: NULL
updated: 2013-11-18 09:27:03
removed: 2013-11-18 09:27:03
  state: Destroy
 chain_info: NULL
   update_count: 4
  disk_type: NULL
 vm_snapshot_chain_size: NULL
 iso_id: NULL
 display_volume: 1
 format: NULL
   min_iops: NULL
   max_iops: NULL
  hv_ss_reserve: NULL
 1 row in set (0.00 sec)



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CLOUDSTACK-5193) [Hyper-V] VHDs not deleted post VM destroy and expunge

2013-11-18 Thread Sowmya Krishnan (JIRA)

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

Sowmya Krishnan commented on CLOUDSTACK-5193:
-

Although the volume was created, logs seem to imply it was never created:
2013-11-18 14:57:03,924 DEBUG [o.a.c.e.o.VolumeOrchestrator] 
(Job-Executor-9:ctx-a09a4752 ctx-8f2bee4c) Cleaning storage for vm: 27
2013-11-18 14:57:03,939 DEBUG [o.a.c.s.v.VolumeServiceImpl] 
(Job-Executor-9:ctx-a09a4752 ctx-8f2bee4c) Marking volume that was never 
created as destroyed: Vol[28|vm=27|ROOT]
2013-11-18 14:57:03,944 DEBUG [c.c.v.VirtualMachineManagerImpl] 
(Job-Executor-9:ctx-a09a4752 ctx-8f2bee4c) Expunged VM[User|testvm]

 [Hyper-V] VHDs not deleted post VM destroy and expunge
 --

 Key: CLOUDSTACK-5193
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5193
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, Storage Controller
Affects Versions: 4.3.0
 Environment: Hyper-V
Reporter: Sowmya Krishnan
Priority: Critical
 Fix For: 4.3.0

 Attachments: destroyvm.log


 Create a VM with local/shared storage offering.
 Destroy the VM with expunge = true or destroy and wait for VM to expunge.
 Although VM is destroyed and volume is marked removed in cloud DB, it is not 
 removed from the hypervisor disk. I don't find .storage.command.DeleteCommand 
 being triggered as part of the Destroy VM.
 As seen below, vhd corresponding to VM i-2-27-VM still resides in the host:
 C:\Users\Public\Documents\Hyper-V\Virtual hard disksdir /W ROOT-27.vhd
  Volume in drive C has no label.
  Volume Serial Number is 7C16-4C80
  Directory of C:\Users\Public\Documents\Hyper-V\Virtual hard disks
 ROOT-27.vhd
1 File(s)  3,120,370,688 bytes
0 Dir(s)  892,863,770,624 bytes free
 C:\Users\Public\Documents\Hyper-V\Virtual hard disks
 SQL output for the destroyed VM volume:
 mysql select * from volumes where id = 28\G
 *** 1. row ***
 id: 28
 account_id: 2
  domain_id: 1
pool_id: 1
   last_pool_id: NULL
instance_id: 27
  device_id: 0
   name: ROOT-27
   uuid: fe491447-52fb-413e-a7a0-339c573f154f
   size: 1073741824
 folder: NULL
   path: NULL
 pod_id: NULL
 data_center_id: 1
 iscsi_name: NULL
host_ip: NULL
volume_type: ROOT
  pool_type: NULL
   disk_offering_id: 13
template_id: 204
 first_snapshot_backup_uuid: NULL
recreatable: 0
created: 2013-11-18 09:22:46
   attached: NULL
updated: 2013-11-18 09:27:03
removed: 2013-11-18 09:27:03
  state: Destroy
 chain_info: NULL
   update_count: 4
  disk_type: NULL
 vm_snapshot_chain_size: NULL
 iso_id: NULL
 display_volume: 1
 format: NULL
   min_iops: NULL
   max_iops: NULL
  hv_ss_reserve: NULL
 1 row in set (0.00 sec)



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (CLOUDSTACK-5193) [Hyper-V] VHDs not deleted post VM destroy and expunge

2013-11-18 Thread Sowmya Krishnan (JIRA)

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

Sowmya Krishnan updated CLOUDSTACK-5193:


Labels: hyper-V,  (was: )

 [Hyper-V] VHDs not deleted post VM destroy and expunge
 --

 Key: CLOUDSTACK-5193
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5193
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller, Management Server, Storage 
 Controller
Affects Versions: 4.3.0
 Environment: Hyper-V
Reporter: Sowmya Krishnan
Priority: Critical
  Labels: hyper-V,
 Fix For: 4.3.0

 Attachments: destroyvm.log


 Create a VM with local/shared storage offering.
 Destroy the VM with expunge = true or destroy and wait for VM to expunge.
 Although VM is destroyed and volume is marked removed in cloud DB, it is not 
 removed from the hypervisor disk. I don't find .storage.command.DeleteCommand 
 being triggered as part of the Destroy VM.
 As seen below, vhd corresponding to VM i-2-27-VM still resides in the host:
 C:\Users\Public\Documents\Hyper-V\Virtual hard disksdir /W ROOT-27.vhd
  Volume in drive C has no label.
  Volume Serial Number is 7C16-4C80
  Directory of C:\Users\Public\Documents\Hyper-V\Virtual hard disks
 ROOT-27.vhd
1 File(s)  3,120,370,688 bytes
0 Dir(s)  892,863,770,624 bytes free
 C:\Users\Public\Documents\Hyper-V\Virtual hard disks
 SQL output for the destroyed VM volume:
 mysql select * from volumes where id = 28\G
 *** 1. row ***
 id: 28
 account_id: 2
  domain_id: 1
pool_id: 1
   last_pool_id: NULL
instance_id: 27
  device_id: 0
   name: ROOT-27
   uuid: fe491447-52fb-413e-a7a0-339c573f154f
   size: 1073741824
 folder: NULL
   path: NULL
 pod_id: NULL
 data_center_id: 1
 iscsi_name: NULL
host_ip: NULL
volume_type: ROOT
  pool_type: NULL
   disk_offering_id: 13
template_id: 204
 first_snapshot_backup_uuid: NULL
recreatable: 0
created: 2013-11-18 09:22:46
   attached: NULL
updated: 2013-11-18 09:27:03
removed: 2013-11-18 09:27:03
  state: Destroy
 chain_info: NULL
   update_count: 4
  disk_type: NULL
 vm_snapshot_chain_size: NULL
 iso_id: NULL
 display_volume: 1
 format: NULL
   min_iops: NULL
   max_iops: NULL
  hv_ss_reserve: NULL
 1 row in set (0.00 sec)



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (CLOUDSTACK-5193) [Hyper-V] VHDs not deleted post VM destroy and expunge

2013-11-18 Thread Sowmya Krishnan (JIRA)

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

Sowmya Krishnan updated CLOUDSTACK-5193:


Component/s: Hypervisor Controller

 [Hyper-V] VHDs not deleted post VM destroy and expunge
 --

 Key: CLOUDSTACK-5193
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5193
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller, Management Server, Storage 
 Controller
Affects Versions: 4.3.0
 Environment: Hyper-V
Reporter: Sowmya Krishnan
Priority: Critical
  Labels: hyper-V,
 Fix For: 4.3.0

 Attachments: destroyvm.log


 Create a VM with local/shared storage offering.
 Destroy the VM with expunge = true or destroy and wait for VM to expunge.
 Although VM is destroyed and volume is marked removed in cloud DB, it is not 
 removed from the hypervisor disk. I don't find .storage.command.DeleteCommand 
 being triggered as part of the Destroy VM.
 As seen below, vhd corresponding to VM i-2-27-VM still resides in the host:
 C:\Users\Public\Documents\Hyper-V\Virtual hard disksdir /W ROOT-27.vhd
  Volume in drive C has no label.
  Volume Serial Number is 7C16-4C80
  Directory of C:\Users\Public\Documents\Hyper-V\Virtual hard disks
 ROOT-27.vhd
1 File(s)  3,120,370,688 bytes
0 Dir(s)  892,863,770,624 bytes free
 C:\Users\Public\Documents\Hyper-V\Virtual hard disks
 SQL output for the destroyed VM volume:
 mysql select * from volumes where id = 28\G
 *** 1. row ***
 id: 28
 account_id: 2
  domain_id: 1
pool_id: 1
   last_pool_id: NULL
instance_id: 27
  device_id: 0
   name: ROOT-27
   uuid: fe491447-52fb-413e-a7a0-339c573f154f
   size: 1073741824
 folder: NULL
   path: NULL
 pod_id: NULL
 data_center_id: 1
 iscsi_name: NULL
host_ip: NULL
volume_type: ROOT
  pool_type: NULL
   disk_offering_id: 13
template_id: 204
 first_snapshot_backup_uuid: NULL
recreatable: 0
created: 2013-11-18 09:22:46
   attached: NULL
updated: 2013-11-18 09:27:03
removed: 2013-11-18 09:27:03
  state: Destroy
 chain_info: NULL
   update_count: 4
  disk_type: NULL
 vm_snapshot_chain_size: NULL
 iso_id: NULL
 display_volume: 1
 format: NULL
   min_iops: NULL
   max_iops: NULL
  hv_ss_reserve: NULL
 1 row in set (0.00 sec)



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Created] (CLOUDSTACK-5194) portable_ip - Test cases fail while creating portable ip range if cleanup did not happen gracefully in earlier test cases' execution

2013-11-18 Thread Gaurav Aradhye (JIRA)
Gaurav Aradhye created CLOUDSTACK-5194:
--

 Summary: portable_ip - Test cases fail while creating portable ip 
range if cleanup did not happen gracefully in earlier test cases' execution
 Key: CLOUDSTACK-5194
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5194
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Affects Versions: 4.3.0
Reporter: Gaurav Aradhye
Assignee: Gaurav Aradhye
 Fix For: 4.3.0


If some test case fails with exception and the portable ip range does not get 
deleted in cleanup, then all the successive test cases fail with following 
error:
createportableiprange failed, due to: errorCode: 431, errorText:Ip  range: 
x.x.x.x -x.x.x.x overlaps with a portable IP range already configured in the 
region x



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Created] (CLOUDSTACK-5195) UI exception misleads when the DB failure happens at the time of VM creation.

2013-11-18 Thread Kiran Koneti (JIRA)
Kiran Koneti created CLOUDSTACK-5195:


 Summary: UI exception misleads when the DB failure happens at the 
time of VM creation.
 Key: CLOUDSTACK-5195
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5195
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Install and Setup
Affects Versions: 4.3.0
Reporter: Kiran Koneti
 Fix For: 4.3.0


UI exception misleads when the DB failure happens at the time of VM 
creation.The exception says the VM creation failed due to insufficient 
capacity,This is the same message observed when any of the system resources get 
exhausted.There should be some other message saying that the DB was not 
reachable as we observe the below error message in the management server logs 

16:03:15,928 ERROR [c.c.v.VirtualMachineManagerImpl] 
(Job-Executor-14:ctx-82a89feb ctx-317a42d4) Failed to start instance 
VM[User|VM2]
com.cloud.utils.exception.CloudRuntimeException: SQL Exception on inquiry
at com.cloud.utils.db.Merovingian2.isLocked(Merovingian2.java:232)
at com.cloud.utils.db.Merovingian2.owns(Merovingian2.java:377)
at com.cloud.utils.db.Merovingian2.acquire(Merovingian2.java:126)
at com.cloud.utils.db.TransactionLegacy.lock(TransactionLegacy.java:385)
at 
com.cloud.utils.db.GenericDaoBase.acquireInLockTable(GenericDaoBase.java:1001)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:33)
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 $Proxy33.acquireInLockTable(Unknown Source)
at 
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.findOrDeployVirtualRouterInGuestNetwork(VirtualNetworkApplianceManagerImpl.java:1306)
at 
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.deployVirtualRouterInGuestNetwork(VirtualNetworkApplianceManagerImpl.java:1841)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:616)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy241.deployVirtualRouterInGuestNetwork(Unknown Source)
at 
com.cloud.network.element.VirtualRouterElement.prepare(VirtualRouterElement.java:221)
at 
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareElement(NetworkOrchestrator.java:1158)
at 
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNic(NetworkOrchestrator.java:1292)
at 
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1228)
at 
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:826)
at 
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:510)
at 
org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:227)
at 

[jira] [Closed] (CLOUDSTACK-3360) user can not Delete his own ISO in case of project

2013-11-18 Thread shweta agarwal (JIRA)

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

shweta agarwal closed CLOUDSTACK-3360.
--


Verified . Fixed

 user can not Delete his own ISO in case of project 
 ---

 Key: CLOUDSTACK-3360
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3360
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Projects
Affects Versions: 4.2.0
 Environment: build:
 CloudPlatform-4.2-144-rhel6.3
Reporter: shweta agarwal
Assignee: Sanjay Tripathi
 Fix For: 4.2.0


 Repro steps:
 1. Create a domain and some accounts /user in that domain
 2. Create a project in that domain
 3. Create a private/ public ISO in the project
 4. Delete the self created ISO
 Bug: gets message in case of public iso
 Domain Admin and regular users can modify only their own Public templates
 MS snippet:
 013-07-04 17:20:18,820 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-21:job-26) Executing 
 org.apache.cloudstack.api.command.user.iso.DeleteIsoCmd for job-26
 2013-07-04 17:20:18,866 ERROR [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-21:job-26) Unexpected exception while executing 
 org.apache.cloudstack.api.command.user.iso.DeleteIsoCmd
 com.cloud.exception.PermissionDeniedException: Domain Admin and regular users 
 can modify only their own Public templates
 at com.cloud.acl.DomainChecker.checkAccess(DomainChecker.java:113)
 at 
 com.cloud.user.AccountManagerImpl.checkAccess(AccountManagerImpl.java:403)
 at 
 com.cloud.template.TemplateManagerImpl.deleteIso(TemplateManagerImpl.java:1478)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 org.apache.cloudstack.api.command.user.iso.DeleteIsoCmd.execute(DeleteIsoCmd.java:110)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
 at 
 com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:679)
 2013-07-04 17:20:18,868 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-21:job-26) Complete async job-26, jobStatus: 2, resultCode: 
 530, result: Error Code: 530 Error text: Domain Admin and regular users can 
 modify only their own Public templates
 2013-07-04 17:20:20,607 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-323:null) Ping from 1
 2013-07-04 17:20:22,077 DEBUG [cloud.api.ApiServlet] (catalina-exec-20:null) 
 ===START===  10.146.0.12 -- GET  
 command=queryAsyncJobResultjobId=49e17cf5-d860-4b58-8c86-1867be1b22f4response=jsonsessionkey=8rczMjm4sfljFOEi6dL2xT631sc%3Dprojectid=a548b266-18e5-4f36
 Bug : gets message in case of private iso :Unable to delete iso . Permission 
 denied.
 2013-07-04 17:23:17,383 ERROR [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-23:job-28) Unexpected exception while executing 
 org.apache.cloudstack.api.command.user.iso.DeleteIsoCmd
 com.cloud.exception.PermissionDeniedException: Unable to delete iso . 
 Permission denied.
 at 
 com.cloud.template.TemplateAdapterBase.accountAndUserValidation(TemplateAdapterBase.java:302)
 at 
 com.cloud.template.TemplateAdapterBase.prepareDelete(TemplateAdapterBase.java:372)
 at 
 com.cloud.template.HypervisorTemplateAdapter.prepareDelete(HypervisorTemplateAdapter.java:419)
 at 
 com.cloud.template.TemplateManagerImpl.deleteIso(TemplateManagerImpl.java:1494)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 org.apache.cloudstack.api.command.user.iso.DeleteIsoCmd.execute(DeleteIsoCmd.java:110)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
 at 
 com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
 at 
 

[jira] [Created] (CLOUDSTACK-5196) SSH to VM fails when done through portable public ip associated through NAT Rule

2013-11-18 Thread Ashutosk Kelkar (JIRA)
Ashutosk Kelkar created CLOUDSTACK-5196:
---

 Summary: SSH to VM fails when done through portable public ip 
associated through NAT Rule
 Key: CLOUDSTACK-5196
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5196
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Controller
Affects Versions: 4.3.0
Reporter: Ashutosk Kelkar
 Fix For: 4.3.0


Deploy a VM
Acquire a portable IP in the network of VM and open the firewall and create NAT 
rule associating the portable ip with the VM.
Try to SSH to the VM through portable ip.

SSH fails.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Created] (CLOUDSTACK-5197) test_portable_ip.py - test cases fail with Exception while SSHing : Connection Failed

2013-11-18 Thread Ashutosk Kelkar (JIRA)
Ashutosk Kelkar created CLOUDSTACK-5197:
---

 Summary: test_portable_ip.py - test cases fail with Exception 
while SSHing : Connection Failed
 Key: CLOUDSTACK-5197
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5197
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Affects Versions: 4.3.0
Reporter: Ashutosk Kelkar
Assignee: Ashutosk Kelkar
 Fix For: 4.3.0


Following test cases fail with the same error:

TestAssociatePublicIp.test_associate_ip_address_services_enable_disable
TestPortableIpTransferAcrossNetworks.test_list_portable_ip_range_non_root_admin



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Created] (CLOUDSTACK-5198) Cannot register SSH key through the ReST API

2013-11-18 Thread Christophe (JIRA)
Christophe created CLOUDSTACK-5198:
--

 Summary: Cannot register SSH key through the ReST API
 Key: CLOUDSTACK-5198
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5198
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: API, Management Server
Affects Versions: 4.1.0
Reporter: Christophe
Priority: Critical


I get a strange error with CS 4.1: User Key Error : Received value for 
parameter publickey is invalid, contains illegal ASCII non-printable characters
I used that with CS 3. Is there any issue about ssk key registration through 
the rest API?

It looks like the problem was introduced by 
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ed06c16 and quite 
similar to https://issues.apache.org/jira/browse/CLOUDSTACK-3362.

Thanks for any help (fix, workaround),
Christophe.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CLOUDSTACK-5079) listConfigurations for cluster is resulting in NPE

2013-11-18 Thread Yichi Lu (JIRA)

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

Yichi Lu commented on CLOUDSTACK-5079:
--

a review request (15633) submitted

 listConfigurations for cluster is resulting in NPE
 --

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


 API issued: 
 http://ms:8080/client/api?command=listConfigurationsclusterid=e3ab8dc1-f8df-4a4f-b42b-51867e36ab76response=jsonsessionkey=8CRucersMGM2I7SCzeT9nYHls34%3Dpage=1pageSize=20listAll=true_=1383845615692
  ===START===  10.101.255.73 -- GET  
 command=listConfigurationsclusterid=e3ab8dc1-f8df-4a4f-b42b-51867e36ab76response=jsonsessionkey=8CRucersMGM2I7SCzeT9nYHls34%3Dpage=1pageSize=20listAll=true_=1383845615692
 2013-11-08 04:24:41,742 ERROR [c.c.a.ApiServer] 
 (catalina-exec-19:ctx-2380ad6b ctx-5d5d232e) unhandled exception executing 
 api command: listConfigurations
 java.lang.NullPointerException
   at 
 com.cloud.server.ConfigurationServerImpl.getConfigListByScope(ConfigurationServerImpl.java:778)
   at 
 com.cloud.server.ManagementServerImpl.searchForConfigurations(ManagementServerImpl.java:1675)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:616)
   at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
   at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
   at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
   at 
 org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
   at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
   at 
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
   at $Proxy222.searchForConfigurations(Unknown Source)
   at 
 org.apache.cloudstack.api.command.admin.config.ListCfgsByCmd.execute(ListCfgsByCmd.java:115)
   at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161)
   at com.cloud.api.ApiServer.queueCommand(ApiServer.java:527)
   at com.cloud.api.ApiServer.handleRequest(ApiServer.java:370)
   at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:322)
   at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52)
   at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114)
   at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
   at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
   at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
   at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:111)
   at com.cloud.api.ApiServlet.doGet(ApiServlet.java:73)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
   at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
   at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
   at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
   at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
   at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
   at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
   at 
 org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
   at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
   at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
   at 
 org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
   at 
 org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721)
   at 
 

[jira] [Commented] (CLOUDSTACK-5044) Configuration Framework Issue

2013-11-18 Thread Yichi Lu (JIRA)

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

Yichi Lu commented on CLOUDSTACK-5044:
--

The source of this bug could be the same one as 5079.

 Configuration Framework Issue
 -

 Key: CLOUDSTACK-5044
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5044
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
 Environment: Mac OS X 10.8.3
Reporter: Mike Tutkowski
 Fix For: 4.3.0


 When you click on the Settings tab of a cluster, an error is displayed in its 
 table:
 http://i.imgur.com/k7oPoEp.jpg
 From the MS console:
 ERROR [c.c.a.ApiServer] (1243517273@qtp-1404190447-6:ctx-a7d38106 
 ctx-82029652) unhandled exception executing api command: listConfigurations
 java.lang.NullPointerException
   at 
 com.cloud.server.ConfigurationServerImpl.getConfigListByScope(ConfigurationServerImpl.java:778)
   at 
 com.cloud.server.ManagementServerImpl.searchForConfigurations(ManagementServerImpl.java:1674)
   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.$Proxy233.searchForConfigurations(Unknown Source)
   at 
 org.apache.cloudstack.api.command.admin.config.ListCfgsByCmd.execute(ListCfgsByCmd.java:115)
   at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161)
   at com.cloud.api.ApiServer.queueCommand(ApiServer.java:527)
   at com.cloud.api.ApiServer.handleRequest(ApiServer.java:370)
   at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:322)
   at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52)
   at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114)
   at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
   at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
   at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
   at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:111)
   at com.cloud.api.ApiServlet.doGet(ApiServlet.java:73)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
   at 
 org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
   at 
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401)
   at 
 org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
   at 
 org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
   at 
 org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
   at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
   at 
 org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
   at 
 org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
   at 
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
   at org.mortbay.jetty.Server.handle(Server.java:326)
   at 
 org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
   at 
 org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
   at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
   at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
   at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
   at 
 org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
   at 
 

[jira] [Closed] (CLOUDSTACK-4924) AcountCleanup: never release the ip address if the network failed to delete

2013-11-18 Thread Sudha Ponnaganti (JIRA)

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

Sudha Ponnaganti closed CLOUDSTACK-4924.



 AcountCleanup: never release the ip address if the network failed to delete
 ---

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


 During the account cleanup process, cloudStack code:
 destroys the networks
 calls ipRelease for the account ip addresses. This call was added to cover 
 the Basic zone scenario when there are public ips assigned to the account 
 exist, and they have to be de-allocated explicitly w/o calling the 
 destroyNetwork
 Bug: ipRelease call should never be made in the accountCleanup thread when 
 the destroyNetwork call failed. Otherwise you end up with the public ips 
 still programmed on the VR that wasn't destroyed, and released in the DB.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Closed] (CLOUDSTACK-4060) [UI] When the only sg is default, it should be selected automatically.

2013-11-18 Thread Sudha Ponnaganti (JIRA)

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

Sudha Ponnaganti closed CLOUDSTACK-4060.



 [UI] When the only sg is default, it should be selected automatically.
 --

 Key: CLOUDSTACK-4060
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4060
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.2.0
Reporter: Ahmad Emneina
Assignee: Jessica Wang
 Fix For: 4.2.1


 When the only sg is default, it should be selected automatically. even when 
 deploying and def sec group isnt selected, the vm is deployed to that 
 security group.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Closed] (CLOUDSTACK-4058) [UI] Under host details we show ACS version and not host version

2013-11-18 Thread Sudha Ponnaganti (JIRA)

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

Sudha Ponnaganti closed CLOUDSTACK-4058.



 [UI] Under host details we show ACS version and not host version
 

 Key: CLOUDSTACK-4058
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4058
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, UI, VMware
Affects Versions: 4.2.0
Reporter: Ahmad Emneina
Assignee: Jessica Wang
 Fix For: 4.2.1

 Attachments: jessica_UI_change_1.jpg


 On the host details pane, version shows cloudstack version and not esxi 
 version.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CLOUDSTACK-4894) [UI] destroyVm API: add support to force expunge the vm immediately

2013-11-18 Thread Sudha Ponnaganti (JIRA)

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

Sudha Ponnaganti commented on CLOUDSTACK-4894:
--

validated - closing

 [UI] destroyVm API: add support to force expunge the vm immediately 
 

 Key: CLOUDSTACK-4894
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4894
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API, UI
Affects Versions: 4.2.0
Reporter: Alena Prokharchyk
Assignee: Jessica Wang
 Fix For: 4.2.1


 When destroyVM API is called, the vm gets destroyed only in the DB. The 
 actual expunge is being taken care later on by expunge thread (configured 
 using expunge.interval and expunge.delay params). As we keep on getting the 
 requests on adding a support for forceful expunge - when vm is expunged 
 immediately after the call is made - it would make sense to introduce some 
 flag to destroyVm command, controlling the behavior.
 So destroyVm will get new parameter - expunge (boolean, false by default). 
 When true is passed as a value, the vm will be expunged right away.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Closed] (CLOUDSTACK-4894) [UI] destroyVm API: add support to force expunge the vm immediately

2013-11-18 Thread Sudha Ponnaganti (JIRA)

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

Sudha Ponnaganti closed CLOUDSTACK-4894.



 [UI] destroyVm API: add support to force expunge the vm immediately 
 

 Key: CLOUDSTACK-4894
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4894
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API, UI
Affects Versions: 4.2.0
Reporter: Alena Prokharchyk
Assignee: Jessica Wang
 Fix For: 4.2.1


 When destroyVM API is called, the vm gets destroyed only in the DB. The 
 actual expunge is being taken care later on by expunge thread (configured 
 using expunge.interval and expunge.delay params). As we keep on getting the 
 requests on adding a support for forceful expunge - when vm is expunged 
 immediately after the call is made - it would make sense to introduce some 
 flag to destroyVm command, controlling the behavior.
 So destroyVm will get new parameter - expunge (boolean, false by default). 
 When true is passed as a value, the vm will be expunged right away.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Closed] (CLOUDSTACK-5082) 3.0.6 to ASF 4.2.1 Upgrade: alert.smtp.timeout and alert.smtp.connectiontimeout configuration parameters are missing on the Upgraded Setup

2013-11-18 Thread Sudha Ponnaganti (JIRA)

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

Sudha Ponnaganti closed CLOUDSTACK-5082.



validated in 4.2.1

 3.0.6 to ASF 4.2.1 Upgrade: alert.smtp.timeout and 
 alert.smtp.connectiontimeout configuration parameters are missing on the 
 Upgraded Setup
 --

 Key: CLOUDSTACK-5082
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5082
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Upgrade
Affects Versions: 4.2.1
Reporter: Chandan Purushothama
Assignee: Anshul Gangwar
Priority: Critical
 Fix For: 4.2.1


 The following parameters are missing on the Upgraded Setup.
 mysql select * from configuration where name like alert.smtp.%timeout;
 +--+--+---+--+---+---+
 | category | instance | component | name | 
 value | description   
 |
 +--+--+---+--+---+---+
 | Alert| DEFAULT  | management-server | alert.smtp.connectiontimeout | 
 3 | Socket connection timeout value in milliseconds. -1 for infinite 
 timeout. |
 | Alert| DEFAULT  | management-server | alert.smtp.timeout   | 
 3 | Socket I/O timeout value in milliseconds. -1 for infinite timeout.
 |
 +--+--+---+--+---+---+
 2 rows in set (0.00 sec)



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Closed] (CLOUDSTACK-5083) 3.0.6 to ASF 4.2.1 Upgrade: baremetal.ipmi.lan.interface configuration parameter are missing on the Upgraded Setup

2013-11-18 Thread Sudha Ponnaganti (JIRA)

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

Sudha Ponnaganti closed CLOUDSTACK-5083.



validated in 4.2.1

 3.0.6 to ASF 4.2.1 Upgrade: baremetal.ipmi.lan.interface configuration 
 parameter are missing on the Upgraded Setup
 

 Key: CLOUDSTACK-5083
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5083
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Upgrade
Affects Versions: 4.2.1
Reporter: Chandan Purushothama
Assignee: frank zhang
Priority: Critical
 Fix For: 4.2.1


 The following parameters are missing on the Upgraded Setup. 
 mysql select * from configuration where name like baremetal%;
 +--+--+---+--+-++
 | category | instance | component | name | 
 value   | description 
   
  |
 +--+--+---+--+-++
 | Advanced | DEFAULT  | management-server | baremetal.ipmi.lan.interface | 
 default | option specified in -I option of impitool. candidates are: 
 open/bmc/lipmi/lan/lanplus/free/imb, see ipmitool man page for details. 
 default valule 'default' means using default option of ipmitool |
 +--+--+---+--+-++
 1 row in set (0.00 sec)



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Closed] (CLOUDSTACK-4936) System VM's Agent goes to disconnected state but VM state still up when they are stopped manually.

2013-11-18 Thread Sudha Ponnaganti (JIRA)

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

Sudha Ponnaganti closed CLOUDSTACK-4936.



 System VM's Agent goes to disconnected state but VM state still up when they 
 are stopped manually.
 --

 Key: CLOUDSTACK-4936
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4936
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: SystemVM
Affects Versions: 4.2.1
Reporter: Kiran Koneti
Assignee: Koushik Das
Priority: Critical
 Fix For: 4.2.1

 Attachments: management-server.zip


 Steps are as below:
 1)Installed the CS using the Trail install.(MS Centos 6.2 and Hypervisor Xen 
 5.6sp2 + CSP installed)
 2)once the setup is up and system Vm's came up tried to deploy Some VM's and 
 the VM deployment was successful.
 3)Tried to stop the SSVM and CPVM the Stop command is passed to the 
 hypervisor and the VM's are sopped in the Hypervisor .
 4)But the cloudstack UI pops with a message unable to stop the VM and updates 
 the status as follows in UI.
 5)The VM state is UP but the Agent state shows disconnected.
 The Management server logs are as below:
 2013-10-23 16:49:07,476 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (catalina-exec-19:null) submit async job-212 = [ 
 fec03341-1c65-4752-8f62-21bffa5bc178 ], details: AsyncJobVO {id:212, userId: 
 2, accountId: 2, sessionKey: null, instanceType: SystemVm, instanceId: 3, 
 cmd: org.apache.cloudstack.api.command.admin.systemvm.StopSystemVmCmd, 
 cmdOriginator: null, cmdInfo: 
 {response:json,id:ffe2558d-516f-4d06-94fe-be20ad83cede,sessionkey:eEEdlU+E7L8Kb1Op0S4B1PIyhUE\u003d,cmdEventType:SSVM.STOP,ctxUserId:2,httpmethod:GET,_:1382527274866,ctxAccountId:2,ctxStartEventId:966},
  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
 processStatus: 0, resultCode: 0, result: null, initMsid: 233845173167606, 
 completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
 2013-10-23 16:49:07,477 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-120:job-212 = [ fec03341-1c65-4752-8f62-21bffa5bc178 ]) 
 Executing org.apache.cloudstack.api.command.admin.systemvm.StopSystemVmCmd 
 for job-212 = [ fec03341-1c65-4752-8f62-21bffa5bc178 ]
 2013-10-23 16:49:07,478 DEBUG [cloud.api.ApiServlet] (catalina-exec-19:null) 
 ===END===  10.252.192.62 -- GET  
 command=stopSystemVmid=ffe2558d-516f-4d06-94fe-be20ad83cederesponse=jsonsessionkey=eEEdlU%2BE7L8Kb1Op0S4B1PIyhUE%3D_=1382527274866
 2013-10-23 16:49:07,551 DEBUG [cloud.capacity.CapacityManagerImpl] 
 (Job-Executor-120:job-212 = [ fec03341-1c65-4752-8f62-21bffa5bc178 ]) VM 
 state transitted from :Running to Stopping with event: StopRequestedvm's 
 original host id: 1 new host id: 1 host id before state transition: 1
 2013-10-23 16:49:07,553 DEBUG [agent.transport.Request] 
 (Job-Executor-120:job-212 = [ fec03341-1c65-4752-8f62-21bffa5bc178 ]) Seq 
 1-964559712: Sending  { Cmd , MgmtId: 233845173167606, via: 1, Ver: v1, 
 Flags: 100111, 
 [{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:true,vmName:s-3-VM,wait:0}}]
  }
 2013-10-23 16:49:07,553 DEBUG [agent.transport.Request] 
 (Job-Executor-120:job-212 = [ fec03341-1c65-4752-8f62-21bffa5bc178 ]) Seq 
 1-964559712: Executing:  { Cmd , MgmtId: 233845173167606, via: 1, Ver: v1, 
 Flags: 100111, 
 [{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:true,vmName:s-3-VM,wait:0}}]
  }
 2013-10-23 16:49:07,553 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-17:null) Seq 1-964559712: Executing request
 2013-10-23 16:49:07,653 DEBUG [xen.resource.CitrixResourceBase] 
 (DirectAgent-17:null) 9. The VM s-3-VM is in Stopping state
 2013-10-23 16:49:07,935 INFO  [xen.resource.CitrixResourceBase] 
 (DirectAgent-17:null) Removed  network rules for vm s-3-VM
 2013-10-23 16:49:08,288 DEBUG [agent.manager.AgentManagerImpl] 
 (AgentManager-Handler-9:null) SeqA 5-25: Processing Seq 5-25:  { Cmd , 
 MgmtId: -1, via: 5, Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:4,_loadInfo:{\n
   \connections\: []\n},wait:0}}] }
 2013-10-23 16:49:08,368 DEBUG [agent.manager.AgentManagerImpl] 
 (AgentManager-Handler-9:null) SeqA 5-25: Sending Seq 5-25:  { Ans: , MgmtId: 
 233845173167606, via: 5, Ver: v1, Flags: 100010, 
 [{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
 2013-10-23 16:49:09,162 DEBUG [agent.manager.AgentManagerImpl] 
 (AgentManager-Handler-15:null) SeqA 4--1: Processing Seq 4--1:  { Cmd , 
 MgmtId: -1, via: 4, Ver: v1, Flags: 111, 
 [{com.cloud.agent.api.ShutdownCommand:{reason:sig.kill,wait:0}}] }
 2013-10-23 16:49:09,162 INFO  

[jira] [Closed] (CLOUDSTACK-5084) 3.0.6 to ASF 4.2.1 Upgrade: vmware.hung.wokervm.timeout and vmware.vcenter.session.timeout configuration parameters are missing on the Upgraded Setup

2013-11-18 Thread Sudha Ponnaganti (JIRA)

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

Sudha Ponnaganti closed CLOUDSTACK-5084.



fixed in 4.2.1

 3.0.6 to ASF 4.2.1 Upgrade: vmware.hung.wokervm.timeout and 
 vmware.vcenter.session.timeout configuration parameters are missing on the 
 Upgraded Setup
 -

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


 The following parameters are missing on the Upgraded Setup. 
 mysql select * from configuration where name like vmware%timeout;
 +--+--+---++---+--+
 | category | instance | component | name   | 
 value | description  |
 +--+--+---++---+--+
 | Advanced | DEFAULT  | management-server | vmware.hung.wokervm.timeout| 
 7200  | Worker VM timeout in seconds |
 | Advanced | DEFAULT  | management-server | vmware.vcenter.session.timeout | 
 600   | VMware client timeout in seconds |
 +--+--+---++---+--+
 2 rows in set (0.01 sec)



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Closed] (CLOUDSTACK-4525) [Automation] Deploy VM failing due race condition in KVM ; Delete template and create volume from the same template

2013-11-18 Thread Sudha Ponnaganti (JIRA)

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

Sudha Ponnaganti closed CLOUDSTACK-4525.



 [Automation] Deploy VM failing due race condition in KVM ; Delete template 
 and create volume from the same template
 ---

 Key: CLOUDSTACK-4525
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4525
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, KVM
Affects Versions: 4.2.0
 Environment: Automation
 KVM
Reporter: Rayees Namathponnan
Assignee: edison su
Priority: Critical
 Fix For: 4.2.1

 Attachments: KVM_Regression_27_Aug_Agent.rar, 
 KVM_Regression_27_Aug_MS.rar


 This issue observed during regression test, few deployment failed; delete 
 template from primary storage and create volume from the same template 
 happens same time; then deployment will failed
 Observed below error in MS log
 2013-08-27 03:06:48,567 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null) 
 ===START===  10.223.240.194 -- GET  
 signature=mP4tF8pK8yEV%2F7PbOLTBfVvXaFY%3DapiKey=uzYh-lz4WfBC_2V9IEDRZX4KDd1G7oCoVZkXTlKIyro
 2OeHVLwI70XLEUsIur0teiJoLNEvJGK_YPb3GareqHgcommand=queryAsyncJobResultresponse=jsonjobid=eedf8879-e2c0-453c-8b6c-0fb67b6b4f62
 2013-08-27 03:06:48,582 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null) 
 ===END===  10.223.240.194 -- GET  
 signature=mP4tF8pK8yEV%2F7PbOLTBfVvXaFY%3DapiKey=uzYh-lz4WfBC_2V9IEDRZX4KDd1G7oCoVZkXTlKIyro2O
 eHVLwI70XLEUsIur0teiJoLNEvJGK_YPb3GareqHgcommand=queryAsyncJobResultresponse=jsonjobid=eedf8879-e2c0-453c-8b6c-0fb67b6b4f62
 2013-08-27 03:06:48,887 DEBUG [cloud.api.ApiServlet] (catalina-exec-5:null) 
 ===START===  10.223.240.194 -- GET  
 signature=AvltVJOEtkR6vGWGhYLKqRXmkxo%3DapiKey=uzYh-lz4WfBC_2V9IEDRZX4KDd1G7oCoVZkXTlKIyro2Oe
 HVLwI70XLEUsIur0teiJoLNEvJGK_YPb3GareqHgcommand=queryAsyncJobResultresponse=jsonjobid=82e670d1-6078-4491-afd2-7aa2fa2c4d54
 2013-08-27 03:06:48,902 DEBUG [cloud.api.ApiServlet] (catalina-exec-5:null) 
 ===END===  10.223.240.194 -- GET  
 signature=AvltVJOEtkR6vGWGhYLKqRXmkxo%3DapiKey=uzYh-lz4WfBC_2V9IEDRZX4KDd1G7oCoVZkXTlKIyro2OeHV
 LwI70XLEUsIur0teiJoLNEvJGK_YPb3GareqHgcommand=queryAsyncJobResultresponse=jsonjobid=82e670d1-6078-4491-afd2-7aa2fa2c4d54
 2013-08-27 03:06:49,065 DEBUG [agent.transport.Request] 
 (AgentManager-Handler-10:null) Seq 1-497093089: Processing:  { Ans: , MgmtId: 
 29066118877352, via: 1, Ver: v1, Flags: 110, [{com.cloud.agent.api.Answ
 er:{result:false,details:com.cloud.utils.exception.CloudRuntimeException:
  com.cloud.utils.exception.CloudRuntimeException: 
 org.libvirt.LibvirtException: cannot stat file '/mnt/fff90cb5-06dd-33b3-8815-
 d78c08ca01d9/0c93e206-679a-4a96-8c6f-c45d5ee463df': No such file or 
 directory\n\tat 
 com.cloud.hypervisor.kvm.storage.KVMStoragePoolManager.getPhysicalDisk(KVMStoragePoolManager.java:166)\n\tat
  com.cloud.hyp
 ervisor.kvm.resource.LibvirtComputingResource.createVbd(LibvirtComputingResource.java:3650)\n\tat
  
 com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3519)\n\tat
 com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1252)\n\tat
  com.cloud.agent.Agent.processRequest(Agent.java:525)\n\tat 
 com.cloud.agent.Agent$AgentReq
 uestHandler.doTask(Agent.java:852)\n\tat 
 com.cloud.utils.nio.Task.run(Task.java:83)\n\tat 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)\n\tat
  java.util.concurrent.ThreadPoo
 lExecutor$Worker.run(ThreadPoolExecutor.java:603)\n\tat 
 java.lang.Thread.run(Thread.java:679)\n,wait:0}}] }
 2013-08-27 03:06:49,066 DEBUG [agent.manager.AgentAttache] 
 (AgentManager-Handler-10:null) Seq 1-497093090: Sending now.  is current 
 sequence.
 2013-08-27 03:06:49,066 DEBUG [agent.transport.Request] 
 (Job-Executor-130:job-702 = [ 6b532b5e-ea40-4f66-97bc-5fe9259899e1 ]) Seq 
 1-497093089: Received:  { Ans: , MgmtId: 29066118877352, via: 1, Ver: v1, Fl
 ags: 110, { Answer } }
 2013-08-27 03:06:49,070 ERROR [cloud.vm.VirtualMachineManagerImpl] 
 (Job-Executor-130:job-702 = [ 6b532b5e-ea40-4f66-97bc-5fe9259899e1 ]) Failed 
 to start instance VM[User|1a1361fc-31dc-4f5f-ae80-09917b636dd1
 ]
 com.cloud.utils.exception.CloudRuntimeException: Unable to get answer that is 
 of class com.cloud.agent.api.StartAnswer
 at com.cloud.agent.manager.Commands.getAnswer(Commands.java:80)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:917)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:575)
 at 
 

[jira] [Closed] (CLOUDSTACK-5136) Domain admin cannot create accounts/users.

2013-11-18 Thread Wei Zhou (JIRA)

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

Wei Zhou closed CLOUDSTACK-5136.



 Domain admin cannot create accounts/users.
 --

 Key: CLOUDSTACK-5136
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5136
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API
Affects Versions: 4.2.0
Reporter: David Matteson
Assignee: Wei Zhou
  Labels: API, admin, features
 Fix For: Future


 Currently a Domain Admin cannot create accounts. This means that allowing 
 Reselling of CloudStack services is not really viable at the moment since any 
 Resellers won't be able to create accounts for their customers, unless we 
 give that Reseller ROOT admin access. Which is obviously not ideal.
 Since Domain Admin already exists as an established access level, and adding 
 more functionality that they currently don't have would possibly negatively 
 impact people who are relying on it in production, perhaps a new level of 
 admin is needed between Domain and ROOT?
 This new tier that would facilitate Reseller accounts would need everything 
 Domain Admins have plus CreateAccount/CreateUser for their domain and Usage 
 Record access for their domain.
 Obviously even better than this would be an admin tier where you could 
 specify what they had access to but that's obviously more complicated.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Closed] (CLOUDSTACK-5076) (Upgrade) reboot VM failed after bridge name change

2013-11-18 Thread Wei Zhou (JIRA)

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

Wei Zhou closed CLOUDSTACK-5076.



 (Upgrade) reboot VM failed after bridge name change
 ---

 Key: CLOUDSTACK-5076
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5076
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.0
Reporter: Wei Zhou
Assignee: Wei Zhou
Priority: Critical
 Fix For: 4.2.1, 4.3.0


 After fix the migration issue (CLOUDSTACK-4405), the bridge name changed from 
 cloudVirBr* to breth*-*.
 This cause an Libvirt Exception when we want to reboot the VMs. The vms will 
 change to Stopped state after the failure.
 agent.log
 2013-11-07 13:39:15,637 WARN  [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-1:null) Failed to create vm
 org.libvirt.LibvirtException: Cannot get interface MTU on 'cloudVirBr108': No 
 such device
 at org.libvirt.ErrorHandler.processError(Unknown Source)
 at org.libvirt.Connect.processError(Unknown Source)
 at org.libvirt.Connect.domainCreateXML(Unknown Source)
 at 
 com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1159)
 at 
 com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.rebootVM(LibvirtComputingResource.java:4441)
 at 
 com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3177)
 at 
 com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1193)
 at com.cloud.agent.Agent.processRequest(Agent.java:525)
 at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852)
 at com.cloud.utils.nio.Task.run(Task.java:83)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:679)
 management-server.log
 2013-11-07 13:30:44,642 DEBUG [agent.transport.Request] 
 (Job-Executor-8:job-52 = [ edb83cb9-0fd5-4ef4-b94d-e3b1328da153 ]) Seq 
 2-1940521013: Sending  { Cmd , MgmtId: 345051517871, via: 2, Ver: v1, Flags: 
 100111, 
 [{com.cloud.agent.api.RebootCommand:{vmName:i-3-5-VM,wait:0}}] }
 2013-11-07 13:30:46,924 DEBUG [agent.transport.Request] 
 (AgentManager-Handler-1:null) Seq 2-1940521013: Processing:  { Ans: , MgmtId: 
 345051517871, via: 2, Ver: v1, Flags: 110, 
 [{com.cloud.agent.api.RebootAnswer:{result:false,details:Cannot get 
 interface MTU on 'cloudVirBr108': No such device,wait:0}}] }
 2013-11-07 13:30:46,925 DEBUG [agent.manager.AgentAttache] 
 (AgentManager-Handler-1:null) Seq 2-1940521013: No more commands found
 2013-11-07 13:30:46,925 DEBUG [agent.transport.Request] 
 (Job-Executor-8:job-52 = [ edb83cb9-0fd5-4ef4-b94d-e3b1328da153 ]) Seq 
 2-1940521013: Received:  { Ans: , MgmtId: 345051517871, via: 2, Ver: v1, 
 Flags: 110, { RebootAnswer } }
 2013-11-07 13:30:46,925 INFO  [cloud.vm.VirtualMachineManagerImpl] 
 (Job-Executor-8:job-52 = [ edb83cb9-0fd5-4ef4-b94d-e3b1328da153 ]) Unable to 
 reboot VM VM[User|i-3-5-VM] on Host[-2-Routing] due to Cannot get interface 
 MTU on 'cloudVirBr108': No such device
 2013-11-07 13:30:46,933 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-8:job-52 = [ edb83cb9-0fd5-4ef4-b94d-e3b1328da153 ]) Complete 
 async job-52 = [ edb83cb9-0fd5-4ef4-b94d-e3b1328da153 ], jobStatus: 2, 
 resultCode: 530, result: Error Code: 530 Error text: Failed to reboot vm 
 instance
 2013-11-07 13:30:47,497 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null) 
 ===START===  10.4.27.126 -- GET  
 command=queryAsyncJobResultjobId=edb83cb9-0fd5-4ef4-b94d-e3b1328da153response=jsonsessionkey=jnt7NMN9fLkjpIcVKKeNJvMk%2Fjk%3D_=1383827956139
 2013-11-07 13:30:47,510 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (catalina-exec-1:null) Async job-52 = [ edb83cb9-0fd5-4ef4-b94d-e3b1328da153 
 ] completed



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Closed] (CLOUDSTACK-4987) Able to add isolated network belonging to an account to a virtual machine belonging to different account

2013-11-18 Thread Wei Zhou (JIRA)

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

Wei Zhou closed CLOUDSTACK-4987.



 Able to add isolated network belonging to an account to a virtual machine 
 belonging to different account
 

 Key: CLOUDSTACK-4987
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4987
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Devices
Affects Versions: 4.2.0, 4.3.0
 Environment: Observed on KVM. Did not test on Xen and VMware yet.
Reporter: Gaurav Aradhye
Assignee: Wei Zhou
 Fix For: 4.2.1, 4.3.0


 1. Deploy an instance in an account
 2. Create an isolated network in different account
 3. Add this isolated network to the VM (both belong to different accounts 
 within same domain)
 As per the test plan - Test case no. 18 
 (https://cwiki.apache.org/confluence/display/CLOUDSTACK/Add+Remove+networks+to+VM+Test+cases),
  API should fail in this case.
 But it has been observed that network gets added successfully and new NIC can 
 be seen in VM's NICs list for this network.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Closed] (CLOUDSTACK-4831) Ability for root admin or domain admin to create a network for another user under their domain in the UI

2013-11-18 Thread Wei Zhou (JIRA)

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

Wei Zhou closed CLOUDSTACK-4831.



 Ability for root admin or domain admin to create a network for another user 
 under their domain in the UI
 

 Key: CLOUDSTACK-4831
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4831
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, UI
Affects Versions: 4.2.0
Reporter: Chris Sciarrino
Assignee: Wei Zhou
Priority: Minor
 Fix For: 4.2.1, 4.3.0


 The root admin or domain admin should have an option in the UI to create a 
 network for an account under them. 
 The use case I am looking at is in the UI: deploy an instance as admin, 
 create a network for another account, assign the instance to the other 
 account (CLOUDSTACK-4796) using the newly created network as the destination 
 networkid, create the necessary port forwarding rules. The end user should 
 not have to configure the network so it needs to be able to be created from 
 the admin accounts.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Closed] (CLOUDSTACK-4830) Allow creation of users and accounts by domain admin in UI

2013-11-18 Thread Wei Zhou (JIRA)

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

Wei Zhou closed CLOUDSTACK-4830.



 Allow creation of users and accounts by domain admin in UI
 --

 Key: CLOUDSTACK-4830
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4830
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, UI
Affects Versions: 4.2.0
Reporter: Chris Sciarrino
Assignee: Wei Zhou
 Fix For: 4.2.1, 4.3.0


 A domain administrator should have the ability in the UI to create and remove 
 accounts under their domain as well as reset user passwords. These requests 
 should not have to go through the root admin.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Closed] (CLOUDSTACK-4505) expungeDestroyedVirtualMachine API call

2013-11-18 Thread Wei Zhou (JIRA)

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

Wei Zhou closed CLOUDSTACK-4505.



 expungeDestroyedVirtualMachine API call
 ---

 Key: CLOUDSTACK-4505
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4505
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API
Affects Versions: 4.2.0
Reporter: David Matteson
Assignee: Wei Zhou
 Fix For: 4.3.0


 We want to provide users a long recovery time before expunging their VMs 
 automatically. Recovery is a great feature. But the problem is that users 
 cannot deploy a new VM with the same hostname or IP address as a Destroyed VM 
 which has not yet been expunged.
 So it would be great to have an API call that lets users say No I really 
 don't want to recover that VM, please delete it so I can deploy a new one.
 expungeDestroyedVirtualMachine would be called with a single vmid to specify 
 which Destroyed VM should be cleared, and of course it would only work on a 
 VM which is in Destroyed state already.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Closed] (CLOUDSTACK-4931) observed NPE with new system vm template

2013-11-18 Thread Wei Zhou (JIRA)

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

Wei Zhou closed CLOUDSTACK-4931.



 observed NPE with new system vm template
 

 Key: CLOUDSTACK-4931
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4931
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, XenServer
Affects Versions: 4.2.1
 Environment: commit :2a914cb3c4ff61c5d29733cac77dca67030b
 hypervisor: Xen6.0.2
 MS server is on rhel6.4
Reporter: prashant kumar mishra
Assignee: Wei Zhou
 Fix For: 4.3.0

 Attachments: Logs_Db.rar


 template
 -
 http://download.cloud.com/templates/4.2/64bit/systemvmtemplate64-2013-07-15-master-xen.vhd.bz2
 Observed NPE for  SSVM and CPVM  before they came up successfully  with new 
 64 bit template
 Logs
 ---
 2013-10-23 06:41:11,221 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (DirectAgent-19:null) VM s-1-VM: cs state = Starting and realState = Running
 2013-10-23 06:41:11,224 WARN  [agent.manager.DirectAgentAttache] 
 (DirectAgent-19:null) Seq 1-1495007236: Exception caught
 java.lang.NullPointerException
 at com.cloud.vm.dao.UserVmDaoImpl.loadDetails(UserVmDaoImpl.java:338)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.compareState(VirtualMachineManagerImpl.java:2473)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.deltaSync(VirtualMachineManagerImpl.java:2175)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.processAnswers(VirtualMachineManagerImpl.java:2689)
 at 
 com.cloud.agent.manager.AgentAttache.processAnswers(AgentAttache.java:287)
 at 
 com.cloud.agent.manager.ClusteredDirectAgentAttache.processAnswers(ClusteredDirectAgentAttache.java:65)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:212)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at 
 java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
 at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at java.lang.Thread.run(Thread.java:722)



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Closed] (CLOUDSTACK-4888) API:UCS:NPE Refresh blades on a decommissioned chassis results in NPE

2013-11-18 Thread Parth Jagirdar (JIRA)

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

Parth Jagirdar closed CLOUDSTACK-4888.
--


Verified.

 API:UCS:NPE Refresh blades on a decommissioned chassis results in NPE
 -

 Key: CLOUDSTACK-4888
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4888
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API, UCS
Affects Versions: 4.2.0
 Environment: UCS
Reporter: Parth Jagirdar
Assignee: frank zhang
Priority: Critical
 Fix For: 4.2.1


 Expecting an appropriate error.
 When refresh blades is issues on a decommissioned chassis.
 2013-10-17 13:52:26,432 DEBUG [cloud.api.ApiServlet] (catalina-exec-6:null) 
 ===START===  10.215.2.19 -- GET  
 command=refreshUcsBladesresponse=jsonsessionkey=e0Kgb2hcBQPMXSe5O%2FDeRH8v2%2B8%3Ducsmanagerid=f185ae78-08cb-4a06-a3c8-47c3d2afa896_=1382043146927
 2013-10-17 13:52:26,451 DEBUG [ucs.manager.UcsHttpClient] 
 (catalina-exec-6:null) UCS call: configResolveClass 
 cookie=1382042998/2e94d89b-026b-4fbd-be82-489759483570 
 inHierarchical=false classId=computeBlade /
 2013-10-17 13:52:26,458 WARN  [ucs.manager.UcsManagerImpl] 
 (catalina-exec-6:null) null
 java.lang.NullPointerException
 at 
 com.cloud.ucs.structure.ComputeBlade.fromXmlObject(ComputeBlade.java:62)
 at 
 com.cloud.ucs.structure.ComputeBlade.fromXmString(ComputeBlade.java:55)
 at 
 com.cloud.ucs.manager.UcsManagerImpl.listBlades(UcsManagerImpl.java:285)
 at 
 com.cloud.ucs.manager.UcsManagerImpl.access$100(UcsManagerImpl.java:65)
 at 
 com.cloud.ucs.manager.UcsManagerImpl$SyncBladesThread.syncBlades(UcsManagerImpl.java:141)
 at 
 com.cloud.ucs.manager.UcsManagerImpl$SyncBladesThread.run(UcsManagerImpl.java:156)
 at 
 com.cloud.ucs.manager.UcsManagerImpl.refreshBlades(UcsManagerImpl.java:624)
 at 
 org.apache.cloudstack.api.RefreshUcsBladesCmd.execute(RefreshUcsBladesCmd.java:42)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
 at com.cloud.api.ApiServer.queueCommand(ApiServer.java:514)
 at com.cloud.api.ApiServer.handleRequest(ApiServer.java:372)
 at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:305)
 at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
 at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
 at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 at 
 org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
 at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
 at 
 org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
 at 
 org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721)
 at 
 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2274)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:679)
 2013-10-17 13:52:26,468 DEBUG [ucs.manager.UcsHttpClient] 
 (catalina-exec-6:null) UCS call: configResolveClass 
 cookie=1382042998/2e94d89b-026b-4fbd-be82-489759483570 
 inHierarchical=false classId=computeBlade /
 2013-10-17 13:52:26,471 WARN  [cloudstack.api.RefreshUcsBladesCmd] 
 (catalina-exec-6:null) unhandled exception:
 java.lang.NullPointerException
 at 
 com.cloud.ucs.structure.ComputeBlade.fromXmlObject(ComputeBlade.java:62)
 at 
 com.cloud.ucs.structure.ComputeBlade.fromXmString(ComputeBlade.java:55)
 at 
 com.cloud.ucs.manager.UcsManagerImpl.listBlades(UcsManagerImpl.java:285)
 at 
 com.cloud.ucs.manager.UcsManagerImpl.refreshBlades(UcsManagerImpl.java:627)
 at 
 org.apache.cloudstack.api.RefreshUcsBladesCmd.execute(RefreshUcsBladesCmd.java:42)
 at 

[jira] [Closed] (CLOUDSTACK-4953) VMsnapshot - Revert VM from running/stopped to a disk+memory snapshot DOES NOT result in running state

2013-11-18 Thread angeline shen (JIRA)

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

angeline shen closed CLOUDSTACK-4953.
-


 VMsnapshot - Revert VM from running/stopped to a disk+memory snapshot DOES 
 NOT  result in running state
 ---

 Key: CLOUDSTACK-4953
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4953
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.1
 Environment: MS   10.223.130.59internal  build 758  rhel6.3
 host  XS 6.0.2 + patches
Reporter: angeline shen
Assignee: Anthony Xu
Priority: Critical
 Fix For: 4.2.1

 Attachments: management-server.log.gz, vm1.png


 1. Advance zone.  Deploy VM1. 
 2. VM1   add files.   Create VM1SS2 Disk+mem
 VM1 at VM1SS2add filesCreate VM1SS3  Disk+mem
 VM1 at VM1SS3add filesCreate  VM1SS4 Disk 
 VM1 at VM1SS4add filesCreate  VM1SS5 Disk 
 
 3. VM1  at VM1SS4. VM1 in stop state. Revert to VM1SS3.  
 result:   VM1   in stop state
 4. VM1 at VM1SS4. VM1 in running state.   Revert to VM1SS3.
 result:   VM1 in running state
 5. VM1 at VM1SS2. VM1 in stop state.  Revert to VM1SS3
 result:   VM1 in stop state
 Conclusion:VMsnapshot - Revert VM from running/stopped to a disk+memory 
 snapshot DOES NOT  result in running state.
 It result in the VM state before the Revert.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Created] (CLOUDSTACK-5199) Cannot restart VM after taking a VM snapshot of an existing VM or reverting a VM snapshot

2013-11-18 Thread Stephen Lamb (JIRA)
Stephen Lamb created CLOUDSTACK-5199:


 Summary: Cannot restart VM after taking a VM snapshot of an 
existing VM or reverting a VM snapshot
 Key: CLOUDSTACK-5199
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5199
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: VMware
Affects Versions: 4.2.0
Reporter: Stephen Lamb
Priority: Blocker


If I create a VM snapshot or try to revert a VM snapshot, if the VM is stopped 
for any reason, it cannot be started again. Attempting to start the VM fails 
with the following error: Unable to create a deployment for VM [User|MyVM]. If 
I delete the VM snapshot, the VM starts without problems.

Environment:
Cloudstack 4.2
VMWare 5.1
Individual VMs are running Ubuntu 12.4



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Closed] (CLOUDSTACK-4994) [VMware] Unable to attach VMwareToolsInstallerISO, unable to scale VM

2013-11-18 Thread angeline shen (JIRA)

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

angeline shen closed CLOUDSTACK-4994.
-


Verified  dixon GA

 [VMware] Unable to attach VMwareToolsInstallerISO, unable to scale VM
 -

 Key: CLOUDSTACK-4994
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4994
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.1
 Environment: MS   10.223.50.3   
 http://repo-ccp.citrix.com/releases/ASF/rhel/6.4/4.2/CloudPlatform-4.2.1-28-rhel6.4.tar.gz
 host ESXi 5.1 Vcenter 5.1 
Reporter: angeline shen
Assignee: Likitha Shetty
Priority: Critical
 Fix For: 4.2.1

 Attachments: Screenshot-CloudPlatform™ - Mozilla Firefox-1.png, 
 Screenshot-CloudPlatform™ - Mozilla Firefox-2.png, Screenshot-CloudPlatform™ 
 - Mozilla Firefox.png, Screenshot.png, management-server.log.gz


  advance zone.  global parameter enable.dynamic.scale.vm=true
 1.  register ISO :
 http://nfs1.lab.vmops.com/isos_64bit/CentOS-6.1-x86_64-bin-DVD1.iso 
 Deploy VM1 with ISO. Install OS.
 Failed to attach ‘VMware tools installerISO’
 2013-10-29 18:24:49,622 DEBUG [agent.transport.Request] 
 (StatsCollector-1:null) Seq 2-2116223057: Received:  { Ans: , MgmtId: 
 206915885077197, via: 2, Ver: v1, Flags: 10, { GetStorageStatsAnswer } }
 2013-10-29 18:24:49,728 ERROR [storage.resource.VmwareStorageProcessor] 
 (DirectAgent-29:10.223.51.3) AttachIsoCommand(attach) failed due to 
 Exception: javax.xml.ws.soap.SOAPFaultException
 Message: The required VMware Tools ISO image does not exist or is 
 inaccessible.
 javax.xml.ws.soap.SOAPFaultException: The required VMware Tools ISO image 
 does not exist or is inaccessible.
 at 
 com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)
 at 
 com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119)
 at 
 com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
 at 
 com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
 at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:129)
 at $Proxy91.mountToolsInstaller(Unknown Source)
 at 
 com.cloud.hypervisor.vmware.mo.VirtualMachineMO.mountToolsInstaller(VirtualMachineMO.java:2279)
 at 
 com.cloud.storage.resource.VmwareStorageProcessor.attachIso(VmwareStorageProcessor.java:1318)
 at 
 com.cloud.storage.resource.VmwareStorageProcessor.attachIso(VmwareStorageProcessor.java:1183)
 at 
 com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:127)
 at 
 com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:55)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:559)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at java.lang.Thread.run(Thread.java:722)
 2013-10-29 18:24:49,729 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-29:null) Seq 2-2116223058: Response Received: 
 2013-10-29 18:24:49,729 DEBUG [agent.transport.Request] (DirectAgent-29:null) 
 Seq 2-2116223058: Processing:  { Ans: , MgmtId: 206915885077197, via: 2, Ver: 
 v1, Flags: 10, [{org.apache.cloudstack.storage.command.AttachAnswe
 r:{result:false,details:AttachIsoCommand(attach) failed due to 
 Exception: javax.xml.ws.soap.SOAPFaultException\nMessage: The required VMware 
 Tools ISO image does not exist or is inaccessible.\n,wait:0}}] }
 2013-10-29 18:24:49,729 DEBUG [agent.transport.Request] 
 (Job-Executor-12:job-123 = [ e06af7a0-21cc-478a-910e-a135f39a289b ]) Seq 
 2-2116223058: Received:  { Ans: , MgmtId: 206915885077197, via: 2, Ver: v1, 
 Flags: 10, { Attac
 hAnswer } }
 2013-10-29 18:24:49,730 DEBUG [agent.manager.AgentManagerImpl] 
 

[jira] [Commented] (CLOUDSTACK-4793) Improve VR Upgrade

2013-11-18 Thread ASF subversion and git services (JIRA)

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

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

Commit 9a97c064be976b1a32a26116a0de3cfeb8e14244 in branch refs/heads/4.3 from 
[~jessicawang]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9a97c06 ]

CLOUDSTACK-4793: UI  Virtual Routers  Advanced Search  add cluster dropdown 
since API now supports it.


 Improve VR Upgrade
 --

 Key: CLOUDSTACK-4793
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4793
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Kishan Kavala
Assignee: Kishan Kavala
 Fix For: 4.3.0

 Attachments: jessica_UI_change_1.jpg, jessica_UI_change_2.jpg


 Give admin control to sequence the upgrade of the cloud by:
   Infrastructure hierarchy: by Cluster, Pod, and Zone etc.
   Administrative hierarchy: by Tenant or Domain 
 Minimize service interruption to users
 Improve the speed of the upgrade time by making as many upgrade operations in 
 parallel as possible



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CLOUDSTACK-4793) Improve VR Upgrade

2013-11-18 Thread ASF subversion and git services (JIRA)

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

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

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

CLOUDSTACK-4793: UI  Virtual Routers  Advanced Search  add cluster dropdown 
since API now supports it.


 Improve VR Upgrade
 --

 Key: CLOUDSTACK-4793
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4793
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Kishan Kavala
Assignee: Kishan Kavala
 Fix For: 4.3.0

 Attachments: jessica_UI_change_1.jpg, jessica_UI_change_2.jpg


 Give admin control to sequence the upgrade of the cloud by:
   Infrastructure hierarchy: by Cluster, Pod, and Zone etc.
   Administrative hierarchy: by Tenant or Domain 
 Minimize service interruption to users
 Improve the speed of the upgrade time by making as many upgrade operations in 
 parallel as possible



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Resolved] (CLOUDSTACK-4860) [VMware] Vcenter 5.5 ESXi 5.5 hosts SSVM CPVM fail to come up to running state

2013-11-18 Thread angeline shen (JIRA)

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

angeline shen resolved CLOUDSTACK-4860.
---

Resolution: Fixed

Issue verified to be fixed in Dixon GA

 [VMware] Vcenter 5.5  ESXi 5.5 hosts  SSVM CPVM fail to come up to running 
 state
 

 Key: CLOUDSTACK-4860
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4860
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.1
 Environment: Vcenter5.5ESXi hosts 5.5
 MS 10.223.130.59CloudPlatform-4.2.1-724-rhel6.3.tar.gz 
 ESXi hosts5.5
Reporter: angeline shen
Assignee: Kelven Yang
Priority: Blocker
 Fix For: 4.3.0

 Attachments: management-server.log.gz


 Vcenter5.5ESXi hosts 5.5
 MS 10.223.130.59CloudPlatform-4.2.1-724-rhel6.3.tar.gz 
 ESXi hosts5.5
 1. Deploy  advance   zone .CPVM   SSVM  fail to come up to running state.
 2013-10-11 17:47:15,238 ERROR [storage.resource.VmwareStorageProcessor] 
 (DirectAgent-35:10.223.251.66) Unable to copy template to primary storage due 
 to exception:Exception: javax.xml.ws.soap.SOAPFaultEx
 ception
 Message: 
 Required parameter spec is missing
 while parsing call information for method ImportVApp
 at line 1, column 110
 while parsing SOAP body
 at line 1, column 102
 while parsing SOAP envelope
 at line 1, column 38
 while parsing HTTP request for method importVApp
 on object of type vim.ResourcePool
 at line 1, column 0
 javax.xml.ws.soap.SOAPFaultException: 
 Required parameter spec is missing
 while parsing call information for method ImportVApp
 at line 1, column 110
 while parsing SOAP body
 at line 1, column 102
 while parsing SOAP envelope
 at line 1, column 38
 while parsing HTTP request for method importVApp
 on object of type vim.ResourcePool
 at line 1, column 0
 at 
 com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)
 at 
 com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119)
 at 
 com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
 at 
 com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
 at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
 at $Proxy90.importVApp(Unknown Source)
 at 
 com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.importVmFromOVF(HypervisorHostHelper.java:1340)
 at 
 com.cloud.hypervisor.vmware.mo.HostMO.importVmFromOVF(HostMO.java:749)
 at 
 com.cloud.storage.resource.VmwareStorageProcessor.copyTemplateFromSecondaryToPrimary(VmwareStorageProcessor.java:164)
 at 
 com.cloud.storage.resource.VmwareStorageProcessor.copyTemplateToPrimaryStorage(VmwareStorageProcessor.java:225)
 at 
 com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:70)
 at 
 com.cloud.storage.resource.VmwareStorageSubsystemCommandHandler.execute(VmwareStorageSubsystemCommandHandler.java:155)
 at 
 com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:49)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:559)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at java.lang.Thread.run(Thread.java:679)
 2013-10-11 17:47:15,239 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-35:null) Seq 1-1893532702: Response Received: 
 2013-10-11 17:47:15,239 DEBUG [agent.transport.Request] (DirectAgent-35:null) 
 Seq 1-1893532702: Processing:  { Ans: , MgmtId: 7692017993539, via: 1, Ver: 
 v1, Flags: 110, 
 [{org.apache.cloudstack.storage.command.CopyCmdAnswer:{result:false,details:Unable
  to copy template to primary storage due to exception:Exception: 
 

[jira] [Closed] (CLOUDSTACK-4860) [VMware] Vcenter 5.5 ESXi 5.5 hosts SSVM CPVM fail to come up to running state

2013-11-18 Thread angeline shen (JIRA)

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

angeline shen closed CLOUDSTACK-4860.
-


 [VMware] Vcenter 5.5  ESXi 5.5 hosts  SSVM CPVM fail to come up to running 
 state
 

 Key: CLOUDSTACK-4860
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4860
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.1
 Environment: Vcenter5.5ESXi hosts 5.5
 MS 10.223.130.59CloudPlatform-4.2.1-724-rhel6.3.tar.gz 
 ESXi hosts5.5
Reporter: angeline shen
Assignee: Kelven Yang
Priority: Blocker
 Fix For: 4.3.0

 Attachments: management-server.log.gz


 Vcenter5.5ESXi hosts 5.5
 MS 10.223.130.59CloudPlatform-4.2.1-724-rhel6.3.tar.gz 
 ESXi hosts5.5
 1. Deploy  advance   zone .CPVM   SSVM  fail to come up to running state.
 2013-10-11 17:47:15,238 ERROR [storage.resource.VmwareStorageProcessor] 
 (DirectAgent-35:10.223.251.66) Unable to copy template to primary storage due 
 to exception:Exception: javax.xml.ws.soap.SOAPFaultEx
 ception
 Message: 
 Required parameter spec is missing
 while parsing call information for method ImportVApp
 at line 1, column 110
 while parsing SOAP body
 at line 1, column 102
 while parsing SOAP envelope
 at line 1, column 38
 while parsing HTTP request for method importVApp
 on object of type vim.ResourcePool
 at line 1, column 0
 javax.xml.ws.soap.SOAPFaultException: 
 Required parameter spec is missing
 while parsing call information for method ImportVApp
 at line 1, column 110
 while parsing SOAP body
 at line 1, column 102
 while parsing SOAP envelope
 at line 1, column 38
 while parsing HTTP request for method importVApp
 on object of type vim.ResourcePool
 at line 1, column 0
 at 
 com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)
 at 
 com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119)
 at 
 com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
 at 
 com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
 at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
 at $Proxy90.importVApp(Unknown Source)
 at 
 com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.importVmFromOVF(HypervisorHostHelper.java:1340)
 at 
 com.cloud.hypervisor.vmware.mo.HostMO.importVmFromOVF(HostMO.java:749)
 at 
 com.cloud.storage.resource.VmwareStorageProcessor.copyTemplateFromSecondaryToPrimary(VmwareStorageProcessor.java:164)
 at 
 com.cloud.storage.resource.VmwareStorageProcessor.copyTemplateToPrimaryStorage(VmwareStorageProcessor.java:225)
 at 
 com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:70)
 at 
 com.cloud.storage.resource.VmwareStorageSubsystemCommandHandler.execute(VmwareStorageSubsystemCommandHandler.java:155)
 at 
 com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:49)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:559)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at java.lang.Thread.run(Thread.java:679)
 2013-10-11 17:47:15,239 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-35:null) Seq 1-1893532702: Response Received: 
 2013-10-11 17:47:15,239 DEBUG [agent.transport.Request] (DirectAgent-35:null) 
 Seq 1-1893532702: Processing:  { Ans: , MgmtId: 7692017993539, via: 1, Ver: 
 v1, Flags: 110, 
 [{org.apache.cloudstack.storage.command.CopyCmdAnswer:{result:false,details:Unable
  to copy template to primary storage due to exception:Exception: 
 javax.xml.ws.soap.SOAPFaultException\nMessage: \nRequired parameter 

[jira] [Closed] (CLOUDSTACK-4674) [baremetal] /usr/share/cloudstack-common/scripts/util/ipmi.py script need to recognize various ipmi version and BMC type of server

2013-11-18 Thread angeline shen (JIRA)

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

angeline shen closed CLOUDSTACK-4674.
-


Per  cheolsoo.p...@citrix.com

 [baremetal] /usr/share/cloudstack-common/scripts/util/ipmi.py script need to 
 recognize various ipmi version and BMC type of server
 --

 Key: CLOUDSTACK-4674
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4674
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.0
 Environment: MS   4.2  campo
 baremetal 
Reporter: angeline shen
Assignee: frank zhang
Priority: Critical
 Fix For: 4.2.1


 On MS:  ./usr/share/cloudstack-common/scripts/util/ipmi.py :
  o = ipmitool(-H, hostname, -U, usrname, -P, password, chassis, 
 bootdev, dev)
 need to include  -l   lanplus option :
 o = ipmitool(-H, hostname, -U, usrname, -P, password, -l, 
 lanplus,  chassis, bootdev, dev)



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Closed] (CLOUDSTACK-4670) [Baremetal] Cloudplatform BareMetal installation guide for CP 4.2

2013-11-18 Thread angeline shen (JIRA)

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

angeline shen closed CLOUDSTACK-4670.
-

Resolution: Fixed

verified

 [Baremetal] Cloudplatform BareMetal installation guide for CP 4.2
 -

 Key: CLOUDSTACK-4670
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4670
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.2.0
Reporter: angeline shen
Priority: Minor
 Fix For: 4.3.0


 Jessica:
 Cloudplatform BareMetal installation guide for CP 4.2:
 Section  titled 'Create a Bare Metal Template ' (page 19 - 20 )  should 
 be moved to after
 Section  titled 'Add the PXE Server and DHCP Server to Your Deployment'



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Closed] (CLOUDSTACK-4930) create template from snapshot fail

2013-11-18 Thread angeline shen (JIRA)

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

angeline shen closed CLOUDSTACK-4930.
-


verified dixon GA

  create template from snapshot fail
 ---

 Key: CLOUDSTACK-4930
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4930
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.1
 Environment: MS 10.223.130.59 
 CloudPlatform-4.2.1-758-rhel6.3.tar.gz
 host  XS  6.2  + patches
Reporter: angeline shen
Assignee: Nitin Mehta
Priority: Critical
 Fix For: 4.2.1

 Attachments: management-server.log.2013-10-22.gz


 1. advance zone.   Deploy VMs  with data disk
 2. take snapshots of root and data volumes
 3. create template from snapshot of root volume and data volume fail
 7692017993539, via: 3, Ver: v1, Flags: 100111, 
 [{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:snapshots/2/3/f3bc4020-4614-4a35-88f6-44a79b80d058,volume:{uuid:ff01e177-eac1-4f99-907b-380b02a85bfd,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:8db78175-66db-3225-8a6b-c7949bb1d96a,id:1,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/angie/primary/xendix64,port:2049}},name:ROOT-3,size:21474836480,path:b3279a8e-98f1-4136-947f-9d54cbbf546f,volumeId:3,vmName:i-2-3-VM,accountId:2,format:VHD,id:3,hypervisorType:XenServer},dataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.223.110.232/export/home/angie/secondary/xendix64,_role:Image}},vmName:i-2-3-VM,name:z1adminV1_ROOT-3_20131023043436,hypervisorType:XenServer,id:1}},destTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/2/202,uuid:a480bbc5-330e-4766-a8e5-b6d2725af7aa,id:202,format:RAW,accountId:2,hvm:true,displayText:tssroot3,imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.223.110.232/export/home/angie/secondary/xendix64,_role:Image}},name:2f629bb34-3ea1-3868-8371-e2b91f53802b,hypervisorType:XenServer}},executeInSequence:true,wait:10800}}]
  }
 2013-10-22 21:37:53,218 DEBUG [agent.transport.Request] 
 (AgentManager-Handler-5:null) Seq 3-2093678896: Processing:  { Ans: , MgmtId: 
 7692017993539, via: 3, Ver: v1, Flags: 110, 
 [{org.apache.cloudstack.storage.command.CopyCmdAnswer:{result:false,details:/usr/local/cloud/systemvm/scripts/storage/secondary/create_privatetemplate_from_snapshot_xen.sh:
  line 65: /bin/vhd-util: Permission denied30#failed to query 
 /mnt/SecStorage/3ac2be04-bacf-3741-ad92-465d1825cad0/snapshots/2/3/f3bc4020-4614-4a35-88f6-44a79b80d058.vhd,wait:0}}]
  }
 2013-10-22 21:37:53,219 DEBUG [agent.transport.Request] 
 (Job-Executor-16:job-16 = [ 97657177-e329-407a-bf71-2bdd17a3acc6 ]) Seq 
 3-2093678896: Received:  { Ans: , MgmtId: 7692017993539, via: 3, Ver: v1, 
 Flags: 110, { CopyCmdAnswer } }
 2013-10-22 21:37:53,222 DEBUG [agent.manager.AgentAttache] 
 (AgentManager-Handler-5:null) Seq 3-2093678896: No more commands found
 2013-10-22 21:37:53,236 DEBUG [cloud.template.TemplateManagerImpl] 
 (Job-Executor-16:job-16 = [ 97657177-e329-407a-bf71-2bdd17a3acc6 ]) Failed to 
 create 
 template/usr/local/cloud/systemvm/scripts/storage/secondary/create_privatetemplate_from_snapshot_xen.sh:
  line 65: /bin/vhd-util: Permission denied30#failed to query 
 /mnt/SecStorage/3ac2be04-bacf-3741-ad92-465d1825cad0/snapshots/2/3/f3bc4020-4614-4a35-88f6-44a79b80d058.vhd
 2013-10-22 21:37:53,302 ERROR [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-16:job-16 = [ 97657177-e329-407a-bf71-2bdd17a3acc6 ]) 
 Unexpected exception while executing 
 org.apache.cloudstack.api.command.user.template.CreateTemplateCmd
 com.cloud.utils.exception.CloudRuntimeException: Failed to create 
 template/usr/local/cloud/systemvm/scripts/storage/secondary/create_privatetemplate_from_snapshot_xen.sh:
  line 65: /bin/vhd-util: Permission denied30#failed to query 
 /mnt/SecStorage/3ac2be04-bacf-3741-ad92-465d1825cad0/snapshots/2/3/f3bc4020-4614-4a35-88f6-44a79b80d058.vhd
   at 
 com.cloud.template.TemplateManagerImpl.createPrivateTemplate(TemplateManagerImpl.java:1396)
   at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
   at 
 org.apache.cloudstack.api.command.user.template.CreateTemplateCmd.execute(CreateTemplateCmd.java:263)
   at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
   at 
 com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
   at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
   

[jira] [Commented] (CLOUDSTACK-5194) portable_ip - Test cases fail while creating portable ip range if cleanup did not happen gracefully in earlier test cases' execution

2013-11-18 Thread ASF subversion and git services (JIRA)

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

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

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

CLOUDSTACK-5194: portable ip - Improving cleanup code to
 avoid cascading failures


 portable_ip - Test cases fail while creating portable ip range if cleanup did 
 not happen gracefully in earlier test cases' execution
 

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


 If some test case fails with exception and the portable ip range does not get 
 deleted in cleanup, then all the successive test cases fail with following 
 error:
 createportableiprange failed, due to: errorCode: 431, errorText:Ip  range: 
 x.x.x.x -x.x.x.x overlaps with a portable IP range already configured in the 
 region x



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CLOUDSTACK-5194) portable_ip - Test cases fail while creating portable ip range if cleanup did not happen gracefully in earlier test cases' execution

2013-11-18 Thread ASF subversion and git services (JIRA)

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

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

Commit 85d3be79d0665e1cca050d64982e64fb4008dd0b in branch refs/heads/4.3 from 
[~gauravaradhye]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=85d3be7 ]

CLOUDSTACK-5194: portable ip - Improving cleanup code to
 avoid cascading failures


 portable_ip - Test cases fail while creating portable ip range if cleanup did 
 not happen gracefully in earlier test cases' execution
 

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


 If some test case fails with exception and the portable ip range does not get 
 deleted in cleanup, then all the successive test cases fail with following 
 error:
 createportableiprange failed, due to: errorCode: 431, errorText:Ip  range: 
 x.x.x.x -x.x.x.x overlaps with a portable IP range already configured in the 
 region x



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CLOUDSTACK-5194) portable_ip - Test cases fail while creating portable ip range if cleanup did not happen gracefully in earlier test cases' execution

2013-11-18 Thread ASF subversion and git services (JIRA)

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

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

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

CLOUDSTACK-5194: portable ip - Improving cleanup code to
 avoid cascading failures


 portable_ip - Test cases fail while creating portable ip range if cleanup did 
 not happen gracefully in earlier test cases' execution
 

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


 If some test case fails with exception and the portable ip range does not get 
 deleted in cleanup, then all the successive test cases fail with following 
 error:
 createportableiprange failed, due to: errorCode: 431, errorText:Ip  range: 
 x.x.x.x -x.x.x.x overlaps with a portable IP range already configured in the 
 region x



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Created] (CLOUDSTACK-5200) UI displays wrong values for the socket information and number of hosts.

2013-11-18 Thread Kiran Koneti (JIRA)
Kiran Koneti created CLOUDSTACK-5200:


 Summary: UI displays wrong values for the socket information and 
number of hosts.
 Key: CLOUDSTACK-5200
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5200
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.3.0
Reporter: Kiran Koneti
Priority: Critical
 Fix For: 4.3.0
 Attachments: Socket_info.jpg

In the infrastructure tab view of the CS when we click the Sockets tab it 
always displays a constant value of 3 for all the hosts and unknown under the 
sockets value.In my current setup i have only one Xen server with single socket 
but it still shows the same value.
The api output displays the correct value but the UI has the different value.

The API output is as below:
listhostsresponse cloud-stack-version=4.3.0-SNAPSHOT
count1/count
host
idb7d32c8c-9872-4b74-864b-665e65d46442/id
nameRack1Pod1Host9/name
stateUp/state
typeRouting/type
ipaddress10.147.40.9/ipaddress
zoneidff337566-43f4-4caf-99a4-79808d3bdef1/zoneid
zonenameZ1/zonename
podid72a86797-7aa8-413d-9a81-f52b0907cf28/podid
podnamePod1/podname
version4.3.0-SNAPSHOT/version
hypervisorXenServer/hypervisor
cpusockets1/cpusockets
cpunumber4/cpunumber
cpuspeed2394/cpuspeed
cpuallocated0%/cpuallocated
cpuused0.06%/cpuused
cpuwithoverprovisioning9576.0/cpuwithoverprovisioning
networkkbsread3976/networkkbsread
networkkbswrite24403/networkkbswrite
memorytotal16001266176/memorytotal
memoryallocated2550136832/memoryallocated
memoryused3687684/memoryused
capabilities
xen-3.0-x86_64 , xen-3.0-x86_32p , hvm-3.0-x86_32 , hvm-3.0-x86_32p , 
hvm-3.0-x86_64
/capabilities
lastpinged1970-01-16T21:08:33+0530/lastpinged
managementserverid7614406590488/managementserverid
clusterid83d22057-ddaf-44f3-a90b-c64237d49521/clusterid
clusternameC1/clustername
clustertypeCloudManaged/clustertype
islocalstorageactivefalse/islocalstorageactive
created2013-11-18T15:34:31+0530/created
events
AgentConnected; HostDown; AgentDisconnected; PingTimeout; StartAgentRebalance; 
ShutdownRequested; Remove; ManagementServerDown; Ping
/events
resourcestateEnabled/resourcestate
hypervisorversion6.2.0/hypervisorversion
hahostfalse/hahost
/host
/listhostsresponse

Attaching the UI screen shot for the same.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Updated] (CLOUDSTACK-5200) UI displays wrong values for the socket information and number of hosts.

2013-11-18 Thread Kiran Koneti (JIRA)

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

Kiran Koneti updated CLOUDSTACK-5200:
-

Attachment: Socket_info.jpg

 UI displays wrong values for the socket information and number of hosts.
 

 Key: CLOUDSTACK-5200
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5200
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.3.0
Reporter: Kiran Koneti
Priority: Critical
 Fix For: 4.3.0

 Attachments: Socket_info.jpg


 In the infrastructure tab view of the CS when we click the Sockets tab it 
 always displays a constant value of 3 for all the hosts and unknown under the 
 sockets value.In my current setup i have only one Xen server with single 
 socket but it still shows the same value.
 The api output displays the correct value but the UI has the different value.
 The API output is as below:
 listhostsresponse cloud-stack-version=4.3.0-SNAPSHOT
 count1/count
 host
 idb7d32c8c-9872-4b74-864b-665e65d46442/id
 nameRack1Pod1Host9/name
 stateUp/state
 typeRouting/type
 ipaddress10.147.40.9/ipaddress
 zoneidff337566-43f4-4caf-99a4-79808d3bdef1/zoneid
 zonenameZ1/zonename
 podid72a86797-7aa8-413d-9a81-f52b0907cf28/podid
 podnamePod1/podname
 version4.3.0-SNAPSHOT/version
 hypervisorXenServer/hypervisor
 cpusockets1/cpusockets
 cpunumber4/cpunumber
 cpuspeed2394/cpuspeed
 cpuallocated0%/cpuallocated
 cpuused0.06%/cpuused
 cpuwithoverprovisioning9576.0/cpuwithoverprovisioning
 networkkbsread3976/networkkbsread
 networkkbswrite24403/networkkbswrite
 memorytotal16001266176/memorytotal
 memoryallocated2550136832/memoryallocated
 memoryused3687684/memoryused
 capabilities
 xen-3.0-x86_64 , xen-3.0-x86_32p , hvm-3.0-x86_32 , hvm-3.0-x86_32p , 
 hvm-3.0-x86_64
 /capabilities
 lastpinged1970-01-16T21:08:33+0530/lastpinged
 managementserverid7614406590488/managementserverid
 clusterid83d22057-ddaf-44f3-a90b-c64237d49521/clusterid
 clusternameC1/clustername
 clustertypeCloudManaged/clustertype
 islocalstorageactivefalse/islocalstorageactive
 created2013-11-18T15:34:31+0530/created
 events
 AgentConnected; HostDown; AgentDisconnected; PingTimeout; 
 StartAgentRebalance; ShutdownRequested; Remove; ManagementServerDown; Ping
 /events
 resourcestateEnabled/resourcestate
 hypervisorversion6.2.0/hypervisorversion
 hahostfalse/hahost
 /host
 /listhostsresponse
 Attaching the UI screen shot for the same.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Resolved] (CLOUDSTACK-5165) [Monitoring] verify shared networks VR for monitoring service

2013-11-18 Thread Jayapal Reddy (JIRA)

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

Jayapal Reddy resolved CLOUDSTACK-5165.
---

Resolution: Fixed

Verified in shared and basic zone shared network.
The monitor service is running on the router.

 [Monitoring] verify shared networks VR for monitoring service
 -

 Key: CLOUDSTACK-5165
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5165
 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
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.3.0


 Test and incorporate changes if needed for shared networks. 
 The code changes should work for shared network with minor changes.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Closed] (CLOUDSTACK-5165) [Monitoring] verify shared networks VR for monitoring service

2013-11-18 Thread Jayapal Reddy (JIRA)

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

Jayapal Reddy closed CLOUDSTACK-5165.
-


 [Monitoring] verify shared networks VR for monitoring service
 -

 Key: CLOUDSTACK-5165
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5165
 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
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.3.0


 Test and incorporate changes if needed for shared networks. 
 The code changes should work for shared network with minor changes.



--
This message was sent by Atlassian JIRA
(v6.1#6144)


[jira] [Commented] (CLOUDSTACK-5200) UI displays wrong values for the socket information and number of hosts.

2013-11-18 Thread Harikrishna Patnala (JIRA)

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

Harikrishna Patnala commented on CLOUDSTACK-5200:
-

The API called from UI has wrong parameter hypervisortype. It is hypervisor

Correct API call,
http://localhost:8080/client/api?command=listHostshypervisor=xenserversessionkey=uMjdI0ko3GbIkvPk3GLSnn7zNTY%3Dpage=1pageSize=20type=routinglistAll=true_=1382505530956

 UI displays wrong values for the socket information and number of hosts.
 

 Key: CLOUDSTACK-5200
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5200
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.3.0
Reporter: Kiran Koneti
Priority: Critical
 Fix For: 4.3.0

 Attachments: Socket_info.jpg


 In the infrastructure tab view of the CS when we click the Sockets tab it 
 always displays a constant value of 3 for all the hosts and unknown under the 
 sockets value.In my current setup i have only one Xen server with single 
 socket but it still shows the same value.
 The api output displays the correct value but the UI has the different value.
 The API output is as below:
 listhostsresponse cloud-stack-version=4.3.0-SNAPSHOT
 count1/count
 host
 idb7d32c8c-9872-4b74-864b-665e65d46442/id
 nameRack1Pod1Host9/name
 stateUp/state
 typeRouting/type
 ipaddress10.147.40.9/ipaddress
 zoneidff337566-43f4-4caf-99a4-79808d3bdef1/zoneid
 zonenameZ1/zonename
 podid72a86797-7aa8-413d-9a81-f52b0907cf28/podid
 podnamePod1/podname
 version4.3.0-SNAPSHOT/version
 hypervisorXenServer/hypervisor
 cpusockets1/cpusockets
 cpunumber4/cpunumber
 cpuspeed2394/cpuspeed
 cpuallocated0%/cpuallocated
 cpuused0.06%/cpuused
 cpuwithoverprovisioning9576.0/cpuwithoverprovisioning
 networkkbsread3976/networkkbsread
 networkkbswrite24403/networkkbswrite
 memorytotal16001266176/memorytotal
 memoryallocated2550136832/memoryallocated
 memoryused3687684/memoryused
 capabilities
 xen-3.0-x86_64 , xen-3.0-x86_32p , hvm-3.0-x86_32 , hvm-3.0-x86_32p , 
 hvm-3.0-x86_64
 /capabilities
 lastpinged1970-01-16T21:08:33+0530/lastpinged
 managementserverid7614406590488/managementserverid
 clusterid83d22057-ddaf-44f3-a90b-c64237d49521/clusterid
 clusternameC1/clustername
 clustertypeCloudManaged/clustertype
 islocalstorageactivefalse/islocalstorageactive
 created2013-11-18T15:34:31+0530/created
 events
 AgentConnected; HostDown; AgentDisconnected; PingTimeout; 
 StartAgentRebalance; ShutdownRequested; Remove; ManagementServerDown; Ping
 /events
 resourcestateEnabled/resourcestate
 hypervisorversion6.2.0/hypervisorversion
 hahostfalse/hahost
 /host
 /listhostsresponse
 Attaching the UI screen shot for the same.



--
This message was sent by Atlassian JIRA
(v6.1#6144)