date:20130822

Sailaja Mada created CLOUDSTACK-4443:


 Summary: [VMWARE]Failed to deploy VM's on VMWARE Standard vSwitch 
Legacy Zone after upgrade 
 Key: CLOUDSTACK-4443
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4443
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Upgrade, VMware
Affects Versions: 4.2.0
Reporter: Sailaja Mada
Priority: Blocker


Steps:

With 307,

1. Configure Adv Zone using Standard vSwitch with VMWARE cluster (Single 
Physical Network and all the traffics - Mgmt,guest,public) on this default 
network ( vSwitch0) 
2. Upgraded from 307 to 4.2 
3. Tried to depoy new VM on this zone which was created in 307. 

Observation:
Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after upgrade 

2013-08-22 12:22:09,336 DEBUG [vmware.resource.VmwareResource] 
(DirectAgent-50:10.102.192.20) Prepare volume at new device 
{"capacityInKB":0,"key":-2,"backing":{"diskMode":"persistent","fileName":"[3adda133ecae3cd894716de45b81a560]
 
i-4-32-VM/ROOT-32.vmdk","datastore":{"value":"datastore-11157","type":"Datastore"}},"connectable":{"startConnected":true,"allowGuestControl":false,"connected":true},"controllerKey":200,"unitNumber":1}
2013-08-22 12:22:09,337 INFO  [vmware.resource.VmwareResource] 
(DirectAgent-50:10.102.192.20) Prepare NIC device based on NicTO: 
{"deviceId":0,"networkRateMbps":200,"defaultNic":true,"uuid":"057f0e6e-7ca5-4715-9551-c827f9f61ea8","ip":"10.1.1.74","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:28:84:00:04","dns1":"10.103.128.15","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://782","isolationUri":"vlan://782","isSecurityGroupEnabled":false}
2013-08-22 12:22:09,348 INFO  [vmware.resource.VmwareResource] 
(DirectAgent-50:10.102.192.20) Prepare network on vmwaresvs P[epp0:untagged] 
with name prefix: cloud.guest
2013-08-22 12:22:09,427 ERROR [vmware.mo.HypervisorHostHelper] 
(DirectAgent-50:10.102.192.20) Unable to find vSwitchepp0
2013-08-22 12:22:09,444 WARN  [vmware.resource.VmwareResource] 
(DirectAgent-50:10.102.192.20) StartCommand failed due to Exception: 
java.lang.Exception
Message: Unable to find vSwitchepp0

java.lang.Exception: Unable to find vSwitchepp0
at 
com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:904)
at 
com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:3292)
at 
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2904)
at 
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:514)
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-08-22 12:22:09,467 DEBUG [agent.manager.DirectAgentAttache] 
(DirectAgent-50:null) Seq 7-1913981379: Response Received:
2013-08-22 12:22:09,470 DEBUG [agent.transport.Request] (DirectAgent-50:null) 
Seq 7-1913981379: Processing:  { Ans: , MgmtId: 187767034175903, via: 7, Ver: 
v1, Flags: 10, 
[{"com.cloud.agent.api.StartAnswer":{"vm":{"id":32,"name":"i-4-32-VM","bootloader":"HVM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,"maxRam":536870912,"hostName":"newinstance1","arch":"x86_64","os":"CentOS
 5.3 
(64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"85cf3117ab67ecba","params":{"rootDiskController":"ide","nicAdapter":"E1000","nestedVirtualizationFlag":"false"},"uuid":"8157294c-b9c6-4589-9727-dffdcf64a8f7","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"8beca59d-c43f-4dc1-8f51-2df6d438286d","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"3adda133-ecae-3cd8-9471-6de45b81a560","id":204,"poolType":"NetworkFilesystem","host":"10.102.192.100","path":"/cpg_vol/sailaja/legacyps1","port":2049}},"name":"ROOT-32","size":2147483648,"path":"ROOT-32","volumeId":86,"vmName":"i-4-32-VM","accountId":4,"format":"OVA","id":86,"hypervisorType":"VMware"}},"diskSeq":0,"type":"ROOT"},{"

[jira] [Commented] (CLOUDSTACK-4443) [VMWARE]Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after upgrade


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

Sailaja Mada commented on CLOUDSTACK-4443:
--

mysql> select * from cluster_details;
+++---++
| id | cluster_id | name  | value   
   |
+++---++
|  1 |  3 | username  | administrator   
   |
|  2 |  3 | password  | +7KYUtTYcD/94cvMn1TpGNHIMFSyDBDZ
   |
|  3 |  3 | url   | http://10.102.192.248/307dc/307c
   |
|  5 |  4 | username  | administrator   
   |
|  6 |  4 | password  | XdGoKeak3LvJuOWlQ+fkgJSTFRewjast
   |
|  7 |  4 | url   | 
http://10.102.192.248/legacydc/legacyc |
|  9 |  3 | guestvswitchtype  | vmwaresvs   
   |
| 10 |  3 | publicvswitchtype | vmwaresvs   
   |
| 11 |  3 | guestvswitchtype  | vmwaresvs   
   |
| 12 |  3 | publicvswitchtype | vmwaresvs   
   |
| 13 |  4 | guestvswitchtype  | vmwaresvs   
   |
| 14 |  4 | publicvswitchtype | vmwaresvs   
   |
| 15 |  1 | cpuOvercommitRatio| 1   
   |
| 16 |  1 | memoryOvercommitRatio | 1   
   |
| 17 |  2 | cpuOvercommitRatio| 1   
   |
| 18 |  2 | memoryOvercommitRatio | 1   
   |
| 19 |  3 | cpuOvercommitRatio| 1   
   |
| 20 |  3 | memoryOvercommitRatio | 1   
   |
| 21 |  4 | cpuOvercommitRatio| 1   
   |
| 22 |  4 | memoryOvercommitRatio | 1   
   |
| 23 |  5 | cpuOvercommitRatio| 1   
   |
| 24 |  5 | memoryOvercommitRatio | 1   
   |
| 41 |  6 | memoryOvercommitRatio | 1   
   |
| 42 |  6 | username  | administrator   
   |
| 43 |  6 | guestvswitchtype  | nexusdvs
   |
| 44 |  6 | publicvswitchname | sailajanewpp
   |
| 45 |  6 | publicvswitchtype | nexusdvs
   |
| 46 |  6 | cpuOvercommitRatio| 1   
   |
| 47 |  6 | password  | rtVnBPymDsbDKn3PdDmqD4uxvMgr2Uhw
   |
| 48 |  6 | guestvswitchname  | sailajanewpp
   |
| 49 |  6 | url   | 
http://10.102.192.248/campodc/campoc   |
| 51 |  3 | NativeHA  | false   
   |
| 52 |  4 | NativeHA  | false   
   |
| 54 |  6 | NativeHA  | false   
   |


> [VMWARE]Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after 
> upgrade 
> ---
>
> Key: CLOUDSTACK-4443
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4443
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Upgrade, VMware
>Affects Versions: 4.2.0
>Reporter: Sailaja Mada
>Priority: Blocker
>
> Steps:
> With 307,
> 1. Configure Adv Zone using Standard vSwitch with VMWARE cluster (Single 
> Physical Network and all the traffics - Mgmt,guest,public) on this default 
> network ( vSwitch0) 
> 2. Upgraded from 307 to 4.2 
> 3. Tried to depoy new VM on this zone which was created in 307. 
> Observation:
> Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after upgrade 
> 2013-08-22 12:22:09,336 DEBUG [vmware.resource.VmwareResource] 
> (DirectAgent-50:10.102.192.20) Prepare volume at new device 
> {"capacityInKB":0,"key":-2,"backing":{"diskMode":"persistent","fileName":"[3adda133ecae3cd894716de45b81a560]
>  
> i-4-32-VM/ROOT-32.vmdk","datastore":{"value":"datastore-11157","type":"Datastore"}},"connectable":{"startConnected":true,"allowGuestControl":false,"connected":true},"controllerKey":200,"unitNumber":1}
> 2013-08-22 12:22:09,337 INFO  [vmware.resource.VmwareResource] 
> (DirectAgent-50:

[jira] [Updated] (CLOUDSTACK-4443) [VMWARE]Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after upgrade


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

Sailaja Mada updated CLOUDSTACK-4443:
-

Fix Version/s: 4.2.1

> [VMWARE]Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after 
> upgrade 
> ---
>
> Key: CLOUDSTACK-4443
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4443
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Upgrade, VMware
>Affects Versions: 4.2.1
>Reporter: Sailaja Mada
>Priority: Blocker
> Fix For: 4.2.1
>
> Attachments: deployvmlogs.rar
>
>
> Steps:
> With 307,
> 1. Configure Adv Zone using Standard vSwitch with VMWARE cluster (Single 
> Physical Network and all the traffics - Mgmt,guest,public) on this default 
> network ( vSwitch0) 
> 2. Upgraded from 307 to 4.2 
> 3. Tried to depoy new VM on this zone which was created in 307. 
> Observation:
> Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after upgrade 
> 2013-08-22 12:22:09,336 DEBUG [vmware.resource.VmwareResource] 
> (DirectAgent-50:10.102.192.20) Prepare volume at new device 
> {"capacityInKB":0,"key":-2,"backing":{"diskMode":"persistent","fileName":"[3adda133ecae3cd894716de45b81a560]
>  
> i-4-32-VM/ROOT-32.vmdk","datastore":{"value":"datastore-11157","type":"Datastore"}},"connectable":{"startConnected":true,"allowGuestControl":false,"connected":true},"controllerKey":200,"unitNumber":1}
> 2013-08-22 12:22:09,337 INFO  [vmware.resource.VmwareResource] 
> (DirectAgent-50:10.102.192.20) Prepare NIC device based on NicTO: 
> {"deviceId":0,"networkRateMbps":200,"defaultNic":true,"uuid":"057f0e6e-7ca5-4715-9551-c827f9f61ea8","ip":"10.1.1.74","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:28:84:00:04","dns1":"10.103.128.15","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://782","isolationUri":"vlan://782","isSecurityGroupEnabled":false}
> 2013-08-22 12:22:09,348 INFO  [vmware.resource.VmwareResource] 
> (DirectAgent-50:10.102.192.20) Prepare network on vmwaresvs P[epp0:untagged] 
> with name prefix: cloud.guest
> 2013-08-22 12:22:09,427 ERROR [vmware.mo.HypervisorHostHelper] 
> (DirectAgent-50:10.102.192.20) Unable to find vSwitchepp0
> 2013-08-22 12:22:09,444 WARN  [vmware.resource.VmwareResource] 
> (DirectAgent-50:10.102.192.20) StartCommand failed due to Exception: 
> java.lang.Exception
> Message: Unable to find vSwitchepp0
> java.lang.Exception: Unable to find vSwitchepp0
> at 
> com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:904)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:3292)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2904)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:514)
> 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-08-22 12:22:09,467 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-50:null) Seq 7-1913981379: Response Received:
> 2013-08-22 12:22:09,470 DEBUG [agent.transport.Request] (DirectAgent-50:null) 
> Seq 7-1913981379: Processing:  { Ans: , MgmtId: 187767034175903, via: 7, Ver: 
> v1, Flags: 10, 
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":32,"name":"i-4-32-VM","bootloader":"HVM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,"maxRam":536870912,"hostName":"newinstance1","arch":"x86_64","os":"CentOS
>  5.3 
> (64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"85cf3117ab67ecba","params":{"rootDiskController":"ide","nicAdapter":"E1000","nestedVirtualizationFlag":"false"},"uuid":"8157294c-b9c6-4589-9727-dffdcf64a8f7","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"8beca59d-c43f-4dc1-8f51-2df6d438286d","vo

[jira] [Updated] (CLOUDSTACK-4443) [VMWARE]Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after upgrade


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

Sailaja Mada updated CLOUDSTACK-4443:
-

Affects Version/s: (was: 4.2.0)
   4.2.1

> [VMWARE]Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after 
> upgrade 
> ---
>
> Key: CLOUDSTACK-4443
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4443
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Upgrade, VMware
>Affects Versions: 4.2.1
>Reporter: Sailaja Mada
>Priority: Blocker
> Attachments: deployvmlogs.rar
>
>
> Steps:
> With 307,
> 1. Configure Adv Zone using Standard vSwitch with VMWARE cluster (Single 
> Physical Network and all the traffics - Mgmt,guest,public) on this default 
> network ( vSwitch0) 
> 2. Upgraded from 307 to 4.2 
> 3. Tried to depoy new VM on this zone which was created in 307. 
> Observation:
> Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after upgrade 
> 2013-08-22 12:22:09,336 DEBUG [vmware.resource.VmwareResource] 
> (DirectAgent-50:10.102.192.20) Prepare volume at new device 
> {"capacityInKB":0,"key":-2,"backing":{"diskMode":"persistent","fileName":"[3adda133ecae3cd894716de45b81a560]
>  
> i-4-32-VM/ROOT-32.vmdk","datastore":{"value":"datastore-11157","type":"Datastore"}},"connectable":{"startConnected":true,"allowGuestControl":false,"connected":true},"controllerKey":200,"unitNumber":1}
> 2013-08-22 12:22:09,337 INFO  [vmware.resource.VmwareResource] 
> (DirectAgent-50:10.102.192.20) Prepare NIC device based on NicTO: 
> {"deviceId":0,"networkRateMbps":200,"defaultNic":true,"uuid":"057f0e6e-7ca5-4715-9551-c827f9f61ea8","ip":"10.1.1.74","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:28:84:00:04","dns1":"10.103.128.15","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://782","isolationUri":"vlan://782","isSecurityGroupEnabled":false}
> 2013-08-22 12:22:09,348 INFO  [vmware.resource.VmwareResource] 
> (DirectAgent-50:10.102.192.20) Prepare network on vmwaresvs P[epp0:untagged] 
> with name prefix: cloud.guest
> 2013-08-22 12:22:09,427 ERROR [vmware.mo.HypervisorHostHelper] 
> (DirectAgent-50:10.102.192.20) Unable to find vSwitchepp0
> 2013-08-22 12:22:09,444 WARN  [vmware.resource.VmwareResource] 
> (DirectAgent-50:10.102.192.20) StartCommand failed due to Exception: 
> java.lang.Exception
> Message: Unable to find vSwitchepp0
> java.lang.Exception: Unable to find vSwitchepp0
> at 
> com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:904)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:3292)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2904)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:514)
> 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-08-22 12:22:09,467 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-50:null) Seq 7-1913981379: Response Received:
> 2013-08-22 12:22:09,470 DEBUG [agent.transport.Request] (DirectAgent-50:null) 
> Seq 7-1913981379: Processing:  { Ans: , MgmtId: 187767034175903, via: 7, Ver: 
> v1, Flags: 10, 
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":32,"name":"i-4-32-VM","bootloader":"HVM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,"maxRam":536870912,"hostName":"newinstance1","arch":"x86_64","os":"CentOS
>  5.3 
> (64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"85cf3117ab67ecba","params":{"rootDiskController":"ide","nicAdapter":"E1000","nestedVirtualizationFlag":"false"},"uuid":"8157294c-b9c6-4589-9727-dffdcf64a8f7","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"8beca59d-c43f-4dc1-8f51-2df6

[jira] [Updated] (CLOUDSTACK-4443) [VMWARE]Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after upgrade

2013-08-22 Thread ASF subversion and git services (JIRA)


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

Sailaja Mada updated CLOUDSTACK-4443:
-

Attachment: deployvmlogs.rar

> [VMWARE]Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after 
> upgrade 
> ---
>
> Key: CLOUDSTACK-4443
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4443
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Upgrade, VMware
>Affects Versions: 4.2.1
>Reporter: Sailaja Mada
>Priority: Blocker
> Fix For: 4.2.1
>
> Attachments: deployvmlogs.rar
>
>
> Steps:
> With 307,
> 1. Configure Adv Zone using Standard vSwitch with VMWARE cluster (Single 
> Physical Network and all the traffics - Mgmt,guest,public) on this default 
> network ( vSwitch0) 
> 2. Upgraded from 307 to 4.2 
> 3. Tried to depoy new VM on this zone which was created in 307. 
> Observation:
> Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after upgrade 
> 2013-08-22 12:22:09,336 DEBUG [vmware.resource.VmwareResource] 
> (DirectAgent-50:10.102.192.20) Prepare volume at new device 
> {"capacityInKB":0,"key":-2,"backing":{"diskMode":"persistent","fileName":"[3adda133ecae3cd894716de45b81a560]
>  
> i-4-32-VM/ROOT-32.vmdk","datastore":{"value":"datastore-11157","type":"Datastore"}},"connectable":{"startConnected":true,"allowGuestControl":false,"connected":true},"controllerKey":200,"unitNumber":1}
> 2013-08-22 12:22:09,337 INFO  [vmware.resource.VmwareResource] 
> (DirectAgent-50:10.102.192.20) Prepare NIC device based on NicTO: 
> {"deviceId":0,"networkRateMbps":200,"defaultNic":true,"uuid":"057f0e6e-7ca5-4715-9551-c827f9f61ea8","ip":"10.1.1.74","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:28:84:00:04","dns1":"10.103.128.15","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://782","isolationUri":"vlan://782","isSecurityGroupEnabled":false}
> 2013-08-22 12:22:09,348 INFO  [vmware.resource.VmwareResource] 
> (DirectAgent-50:10.102.192.20) Prepare network on vmwaresvs P[epp0:untagged] 
> with name prefix: cloud.guest
> 2013-08-22 12:22:09,427 ERROR [vmware.mo.HypervisorHostHelper] 
> (DirectAgent-50:10.102.192.20) Unable to find vSwitchepp0
> 2013-08-22 12:22:09,444 WARN  [vmware.resource.VmwareResource] 
> (DirectAgent-50:10.102.192.20) StartCommand failed due to Exception: 
> java.lang.Exception
> Message: Unable to find vSwitchepp0
> java.lang.Exception: Unable to find vSwitchepp0
> at 
> com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:904)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:3292)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2904)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:514)
> 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-08-22 12:22:09,467 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-50:null) Seq 7-1913981379: Response Received:
> 2013-08-22 12:22:09,470 DEBUG [agent.transport.Request] (DirectAgent-50:null) 
> Seq 7-1913981379: Processing:  { Ans: , MgmtId: 187767034175903, via: 7, Ver: 
> v1, Flags: 10, 
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":32,"name":"i-4-32-VM","bootloader":"HVM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,"maxRam":536870912,"hostName":"newinstance1","arch":"x86_64","os":"CentOS
>  5.3 
> (64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"85cf3117ab67ecba","params":{"rootDiskController":"ide","nicAdapter":"E1000","nestedVirtualizationFlag":"false"},"uuid":"8157294c-b9c6-4589-9727-dffdcf64a8f7","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"8beca59d-c43f-4dc1-8f51-2df6d4382

[jira] [Commented] (CLOUDSTACK-4433) [VMware]Registration of template using the downloaded template URL is failing.


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

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

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

CLOUDSTACK-4433:[VMware]Registration of template using the downloaded
template URL is failing.
(cherry picked from commit 885a161b62f985dd83c95f4524af4823cc261043)

Signed-off-by: animesh 


> [VMware]Registration of template using the downloaded template URL is failing.
> --
>
> Key: CLOUDSTACK-4433
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4433
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller
>Affects Versions: 4.2.0
>Reporter: Min Chen
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.2.0
>
>
> Steps:
> 1. Create a snapshot of root volume before upgrade.(after upgrade also)
> 2. Create template from snapshot.
> 3. Extract the template .
> 4. Now register the template with the URL popped up in step3
> Observation:
> Registration failed with “ Failed post download script: 
> com.cloud.exception.InternalErrorException: Unable to locate OVF file in 
> template package directory: 
> /mnt/SecStorage/0e8da06e-0788-3efb-86a6-b0705a2205d3/template/tmpl/2/214there 
> is no OVF file”
> But UI shows success. Notifications shows success.
> 2013-08-21 20:04:02,399 DEBUG [agent.transport.Request] 
> (AgentManager-Handler-1:null) Seq 3-1960707392: Processing: { Ans: , MgmtId: 
> 7067804893289, via: 3, Ver: v1, Flags: 10, 
> [{"com.cloud.agent.api.storage.DownloadAnswer":{"jobId":"5a011db0-5ae2-4aad-a62b-7363e3305ddb","downloadPct":100,"errorString":"Failed
>  post download script: com.cloud.exception.InternalErrorException: Unable to 
> locate OVF file in template package directory: 
> /mnt/SecStorage/0e8da06e-0788-3efb-86a6-b0705a2205d3/template/tmpl/2/214","downloadStatus":"DOWNLOAD_ERROR","downloadPath":"/mnt/SecStorage/0e8da06e-0788-3efb-86a6-b0705a2205d3/template/tmpl/2/214/dnld6321683521470213167tmp_","installPath":"template/tmpl/2/214/ba5a8103-58fe-3196-a3fd-440e1fe4d508.ova","templateSize":0,"templatePhySicalSize":0,"checkSum":"82cea0b543ed2c4d5047b0bb7457c53f","result":true,"details":"Failed
>  post download script: com.cloud.exception.InternalErrorException: Unable to 
> locate OVF file in template package directory: 
> /mnt/SecStorage/0e8da06e-0788-3efb-86a6-b0705a2205d3/template/tmpl/2/214","wait":0}}]
>  }
> 2013-08-21 20:04:10,896 DEBUG [agent.manager.AgentManagerImpl] 
> (AgentManager-Handler-4:null) SeqA 4-10323: Processing Seq 4-10323: { Cmd , 
> MgmtId: -1, via: 4, Ver: v1, Flags: 11, 
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
>  \"connections\": []\n}","wait":0}}] }

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

[jira] [Commented] (CLOUDSTACK-770) documentation on nTier Apps 2.0

2013-08-22 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on CLOUDSTACK-770:


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

CLOUDSTACK-770 ntier review comments


> documentation on nTier Apps 2.0
> ---
>
> Key: CLOUDSTACK-770
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-770
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Doc
>Reporter: Radhika Nair
>Assignee: Sudha Ponnaganti
> Fix For: 4.2.0
>
> Attachments: Apache_CloudStack-4.2.0-Admin_Guide-en-US.zip
>
>
> doc for nTier Apps 2.0

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

[jira] [Commented] (CLOUDSTACK-770) documentation on nTier Apps 2.0

2013-08-22 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on CLOUDSTACK-770:


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

CLOUDSTACK-770 ntier review comments


> documentation on nTier Apps 2.0
> ---
>
> Key: CLOUDSTACK-770
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-770
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Doc
>Reporter: Radhika Nair
>Assignee: Sudha Ponnaganti
> Fix For: 4.2.0
>
> Attachments: Apache_CloudStack-4.2.0-Admin_Guide-en-US.zip
>
>
> doc for nTier Apps 2.0

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

[jira] [Commented] (CLOUDSTACK-770) documentation on nTier Apps 2.0

2013-08-22 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on CLOUDSTACK-770:


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

CLOUDSTACK-770 ntier review comments


> documentation on nTier Apps 2.0
> ---
>
> Key: CLOUDSTACK-770
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-770
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Doc
>Reporter: Radhika Nair
>Assignee: Sudha Ponnaganti
> Fix For: 4.2.0
>
> Attachments: Apache_CloudStack-4.2.0-Admin_Guide-en-US.zip
>
>
> doc for nTier Apps 2.0

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

[jira] [Created] (CLOUDSTACK-4445) CLONE - [UI]Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter

Sailaja Mada created CLOUDSTACK-4445:


 Summary: CLONE - [UI]Edit Icon is used for Dedicate host / Add or 
Remove VMWARE Datacenter 
 Key: CLOUDSTACK-4445
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4445
 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: Sailaja Mada
Assignee: Brian Federle
 Fix For: 4.2.0


Observation :

Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter .

Expected behavior :

We should have icons to identify these new options separately. 



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

[jira] [Updated] (CLOUDSTACK-4445) [UI]Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter Chrome Browser


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

Sailaja Mada updated CLOUDSTACK-4445:
-

Summary:  [UI]Edit Icon is used for Dedicate host / Add or Remove VMWARE 
Datacenter Chrome Browser  (was: CLONE - [UI]Edit Icon is used for Dedicate 
host / Add or Remove VMWARE Datacenter )

>  [UI]Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter 
> Chrome Browser
> -
>
> Key: CLOUDSTACK-4445
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4445
> 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: Sailaja Mada
>Assignee: Brian Federle
> Fix For: 4.2.0
>
>
> Observation :
> Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter .
> Expected behavior :
> We should have icons to identify these new options separately. 

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

[jira] [Updated] (CLOUDSTACK-4445) [UI]Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter Chrome Browser


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

Sailaja Mada updated CLOUDSTACK-4445:
-

Attachment: dedicatezone1.png
dedicatePOD1.png
dedicatehost1.png
dedicatecluster1.png
addremovedc.png

>  [UI]Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter 
> Chrome Browser
> -
>
> Key: CLOUDSTACK-4445
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4445
> 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: Sailaja Mada
>Assignee: Brian Federle
> Fix For: 4.2.0
>
> Attachments: addremovedc.png, dedicatecluster1.png, 
> dedicatehost1.png, dedicatePOD1.png, dedicatezone1.png
>
>
> Observation :
> Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter .
> Expected behavior :
> We should have icons to identify these new options separately. 

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

[jira] [Updated] (CLOUDSTACK-4445) [UI]Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter with Chrome Browser


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

Sailaja Mada updated CLOUDSTACK-4445:
-

Fix Version/s: (was: 4.2.0)
   4.2.1

>  [UI]Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter 
> with Chrome Browser
> --
>
> Key: CLOUDSTACK-4445
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4445
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.2.1
>Reporter: Sailaja Mada
>Assignee: Brian Federle
> Fix For: 4.2.1
>
> Attachments: addremovedc.png, dedicatecluster1.png, 
> dedicatehost1.png, dedicatePOD1.png, dedicatezone1.png
>
>
> Observation :
> Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter .
> Expected behavior :
> We should have icons to identify these new options separately. 

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

[jira] [Updated] (CLOUDSTACK-4445) [UI]Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter with Chrome Browser


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

Sailaja Mada updated CLOUDSTACK-4445:
-

Affects Version/s: (was: 4.2.0)
   4.2.1

>  [UI]Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter 
> with Chrome Browser
> --
>
> Key: CLOUDSTACK-4445
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4445
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.2.1
>Reporter: Sailaja Mada
>Assignee: Brian Federle
> Fix For: 4.2.0
>
> Attachments: addremovedc.png, dedicatecluster1.png, 
> dedicatehost1.png, dedicatePOD1.png, dedicatezone1.png
>
>
> Observation :
> Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter .
> Expected behavior :
> We should have icons to identify these new options separately. 

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

[jira] [Updated] (CLOUDSTACK-4445) [UI]Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter with Chrome Browser


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

Sailaja Mada updated CLOUDSTACK-4445:
-

Summary:  [UI]Edit Icon is used for Dedicate host / Add or Remove VMWARE 
Datacenter with Chrome Browser  (was:  [UI]Edit Icon is used for Dedicate host 
/ Add or Remove VMWARE Datacenter Chrome Browser)

>  [UI]Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter 
> with Chrome Browser
> --
>
> Key: CLOUDSTACK-4445
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4445
> 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: Sailaja Mada
>Assignee: Brian Federle
> Fix For: 4.2.0
>
> Attachments: addremovedc.png, dedicatecluster1.png, 
> dedicatehost1.png, dedicatePOD1.png, dedicatezone1.png
>
>
> Observation :
> Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter .
> Expected behavior :
> We should have icons to identify these new options separately. 

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

[jira] [Commented] (CLOUDSTACK-4445) [UI]Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter with Chrome Browser


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

Sailaja Mada commented on CLOUDSTACK-4445:
--

This is fixed with Firefox browser as part of the bug fix CLOUDSTACK-3391 . 
Cloned the same defect to fix for Chrome also.

>  [UI]Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter 
> with Chrome Browser
> --
>
> Key: CLOUDSTACK-4445
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4445
> 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: Sailaja Mada
>Assignee: Brian Federle
> Fix For: 4.2.0
>
> Attachments: addremovedc.png, dedicatecluster1.png, 
> dedicatehost1.png, dedicatePOD1.png, dedicatezone1.png
>
>
> Observation :
> Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter .
> Expected behavior :
> We should have icons to identify these new options separately. 

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

[jira] [Assigned] (CLOUDSTACK-4443) [VMWARE]Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after upgrade

2013-08-22 Thread Sateesh Chodapuneedi (JIRA)


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

Sateesh Chodapuneedi reassigned CLOUDSTACK-4443:


Assignee: Sateesh Chodapuneedi

> [VMWARE]Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after 
> upgrade 
> ---
>
> Key: CLOUDSTACK-4443
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4443
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Upgrade, VMware
>Affects Versions: 4.2.1
>Reporter: Sailaja Mada
>Assignee: Sateesh Chodapuneedi
>Priority: Blocker
> Fix For: 4.2.1
>
> Attachments: deployvmlogs.rar
>
>
> Steps:
> With 307,
> 1. Configure Adv Zone using Standard vSwitch with VMWARE cluster (Single 
> Physical Network and all the traffics - Mgmt,guest,public) on this default 
> network ( vSwitch0) 
> 2. Upgraded from 307 to 4.2 
> 3. Tried to depoy new VM on this zone which was created in 307. 
> Observation:
> Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after upgrade 
> 2013-08-22 12:22:09,336 DEBUG [vmware.resource.VmwareResource] 
> (DirectAgent-50:10.102.192.20) Prepare volume at new device 
> {"capacityInKB":0,"key":-2,"backing":{"diskMode":"persistent","fileName":"[3adda133ecae3cd894716de45b81a560]
>  
> i-4-32-VM/ROOT-32.vmdk","datastore":{"value":"datastore-11157","type":"Datastore"}},"connectable":{"startConnected":true,"allowGuestControl":false,"connected":true},"controllerKey":200,"unitNumber":1}
> 2013-08-22 12:22:09,337 INFO  [vmware.resource.VmwareResource] 
> (DirectAgent-50:10.102.192.20) Prepare NIC device based on NicTO: 
> {"deviceId":0,"networkRateMbps":200,"defaultNic":true,"uuid":"057f0e6e-7ca5-4715-9551-c827f9f61ea8","ip":"10.1.1.74","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:28:84:00:04","dns1":"10.103.128.15","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://782","isolationUri":"vlan://782","isSecurityGroupEnabled":false}
> 2013-08-22 12:22:09,348 INFO  [vmware.resource.VmwareResource] 
> (DirectAgent-50:10.102.192.20) Prepare network on vmwaresvs P[epp0:untagged] 
> with name prefix: cloud.guest
> 2013-08-22 12:22:09,427 ERROR [vmware.mo.HypervisorHostHelper] 
> (DirectAgent-50:10.102.192.20) Unable to find vSwitchepp0
> 2013-08-22 12:22:09,444 WARN  [vmware.resource.VmwareResource] 
> (DirectAgent-50:10.102.192.20) StartCommand failed due to Exception: 
> java.lang.Exception
> Message: Unable to find vSwitchepp0
> java.lang.Exception: Unable to find vSwitchepp0
> at 
> com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:904)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:3292)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2904)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:514)
> 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-08-22 12:22:09,467 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-50:null) Seq 7-1913981379: Response Received:
> 2013-08-22 12:22:09,470 DEBUG [agent.transport.Request] (DirectAgent-50:null) 
> Seq 7-1913981379: Processing:  { Ans: , MgmtId: 187767034175903, via: 7, Ver: 
> v1, Flags: 10, 
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":32,"name":"i-4-32-VM","bootloader":"HVM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,"maxRam":536870912,"hostName":"newinstance1","arch":"x86_64","os":"CentOS
>  5.3 
> (64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"85cf3117ab67ecba","params":{"rootDiskController":"ide","nicAdapter":"E1000","nestedVirtualizationFlag":"false"},"uuid":"8157294c-b9c6-4589-9727-dffdcf64a8f7","disks":[{"data":{"org.apache.cloudstack.s

[jira] [Resolved] (CLOUDSTACK-4437) Fix iso usage event count to match the number of image stores


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

Srikanteswararao Talluri resolved CLOUDSTACK-4437.
--

Resolution: Fixed

> Fix iso usage event count to match the number of image stores
> -
>
> Key: CLOUDSTACK-4437
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4437
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Test
>Affects Versions: 4.2.1
>Reporter: Srikanteswararao Talluri
>Assignee: Srikanteswararao Talluri
> Fix For: 4.2.1
>
>
> Check ISO.CREATE event in events table
>  >> begin captured logging << 
> testclient.testcase.TestISOUsage: DEBUG: Deleting ISO with ID: 
> e99eaac5-8ab3-454b-978b-09f0255dc399
> testclient.testcase.TestISOUsage: DEBUG: select project_account_id from 
> projects where uuid = '361e1eba-cdc9-4568-8738-ef209afc66f0';
> testclient.testcase.TestISOUsage: DEBUG: select type from usage_event where 
> account_id = '369';
> testclient.testcase.TestISOUsage: DEBUG: Query result: [(u'ISO.CREATE',), 
> (u'ISO.CREATE',), (u'ISO.DELETE',), (u'ISO.DELETE',)]
> - >> end captured logging << -
> Stacktrace
> Traceback (most recent call last):
>   File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
>   File "/root/cloudstack/test/integration/component/test_project_usage.py", 
> line 977, in test_01_ISO_usage
> "Check ISO.CREATE event in events table"
>   File "/usr/local/lib/python2.7/unittest/case.py", line 494, in assertEqual
> assertion_func(first, second, msg=msg)
>   File "/usr/local/lib/python2.7/unittest/case.py", line 487, in 
> _baseAssertEqual
> raise self.failureException(msg)
> AssertionError: Check ISO.CREATE event in events table
>  >> begin captured logging << 
> testclient.testcase.TestISOUsage: DEBUG: Deleting ISO with ID: 
> e99eaac5-8ab3-454b-978b-09f0255dc399
> testclient.testcase.TestISOUsage: DEBUG: select project_account_id from 
> projects where uuid = '361e1eba-cdc9-4568-8738-ef209afc66f0';
> testclient.testcase.TestISOUsage: DEBUG: select type from usage_event where 
> account_id = '369';
> testclient.testcase.TestISOUsage: DEBUG: Query result: [(u'ISO.CREATE',), 
> (u'ISO.CREATE',), (u'ISO.DELETE',), (u'ISO.DELETE',)]
> - >> end captured logging << -

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

[jira] [Closed] (CLOUDSTACK-4437) Fix iso usage event count to match the number of image stores


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

Srikanteswararao Talluri closed CLOUDSTACK-4437.



> Fix iso usage event count to match the number of image stores
> -
>
> Key: CLOUDSTACK-4437
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4437
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Test
>Affects Versions: 4.2.1
>Reporter: Srikanteswararao Talluri
>Assignee: Srikanteswararao Talluri
> Fix For: 4.2.1
>
>
> Check ISO.CREATE event in events table
>  >> begin captured logging << 
> testclient.testcase.TestISOUsage: DEBUG: Deleting ISO with ID: 
> e99eaac5-8ab3-454b-978b-09f0255dc399
> testclient.testcase.TestISOUsage: DEBUG: select project_account_id from 
> projects where uuid = '361e1eba-cdc9-4568-8738-ef209afc66f0';
> testclient.testcase.TestISOUsage: DEBUG: select type from usage_event where 
> account_id = '369';
> testclient.testcase.TestISOUsage: DEBUG: Query result: [(u'ISO.CREATE',), 
> (u'ISO.CREATE',), (u'ISO.DELETE',), (u'ISO.DELETE',)]
> - >> end captured logging << -
> Stacktrace
> Traceback (most recent call last):
>   File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
>   File "/root/cloudstack/test/integration/component/test_project_usage.py", 
> line 977, in test_01_ISO_usage
> "Check ISO.CREATE event in events table"
>   File "/usr/local/lib/python2.7/unittest/case.py", line 494, in assertEqual
> assertion_func(first, second, msg=msg)
>   File "/usr/local/lib/python2.7/unittest/case.py", line 487, in 
> _baseAssertEqual
> raise self.failureException(msg)
> AssertionError: Check ISO.CREATE event in events table
>  >> begin captured logging << 
> testclient.testcase.TestISOUsage: DEBUG: Deleting ISO with ID: 
> e99eaac5-8ab3-454b-978b-09f0255dc399
> testclient.testcase.TestISOUsage: DEBUG: select project_account_id from 
> projects where uuid = '361e1eba-cdc9-4568-8738-ef209afc66f0';
> testclient.testcase.TestISOUsage: DEBUG: select type from usage_event where 
> account_id = '369';
> testclient.testcase.TestISOUsage: DEBUG: Query result: [(u'ISO.CREATE',), 
> (u'ISO.CREATE',), (u'ISO.DELETE',), (u'ISO.DELETE',)]
> - >> end captured logging << -

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

[jira] [Assigned] (CLOUDSTACK-2471) test_host_high_availability.py refers to non-existent library method wait_for_vm

2013-08-22 Thread Prasanna Santhanam (JIRA)


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

Prasanna Santhanam reassigned CLOUDSTACK-2471:
--

Assignee: Prasanna Santhanam

> test_host_high_availability.py refers to non-existent library method 
> wait_for_vm
> 
>
> Key: CLOUDSTACK-2471
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2471
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Test
>Affects Versions: 4.2.0
>Reporter: Prasanna Santhanam
>Assignee: Prasanna Santhanam
> Fix For: 4.2.0
>
>
> test_host_high_availability.py:
>  #verify the VM live migration happened to another running host
> self.debug("Waiting for VM to come up")
> wait_for_vm( <--does not exist in common.py
> self.apiclient,
> virtualmachineid=vm_with_ha_disabled.id,
> interval=timeout
> )
> 

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

[jira] [Resolved] (CLOUDSTACK-4257) [Automation] test_storage_motion test cases failed during with unexpected result in listStoragePool API call

2013-08-22 Thread Saksham Srivastava (JIRA)


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

Saksham Srivastava resolved CLOUDSTACK-4257.


Resolution: Fixed

> [Automation] test_storage_motion test cases failed during with unexpected 
> result in listStoragePool API call
> 
>
> Key: CLOUDSTACK-4257
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4257
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Test
>Affects Versions: 4.2.0
> Environment: Automation 
>Reporter: Rayees Namathponnan
>Assignee: Saksham Srivastava
> Fix For: 4.2.0
>
>
> Test case 
> integration.component.test_storage_motion.TestStorageMotion.test_02_migrate_volume
>  failed during   api call liststorage pool with unexpected result
> Error Message
> Check list storage pools response for valid list
> Stacktrace
> Traceback (most recent call last):
>   File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
>   File 
> "/Repo_30X/ipcl/cloudstack/test/integration/component/test_storage_motion.py",
>  line 265, in test_02_migrate_volume
> "Check list storage pools response for valid list"
>   File "/usr/local/lib/python2.7/unittest/case.py", line 494, in assertEqual
> assertion_func(first, second, msg=msg)
>   File "/usr/local/lib/python2.7/unittest/case.py", line 487, in 
> _baseAssertEqual
> raise self.failureException(msg)
> AssertionError: Check list storage pools response for valid list

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

[jira] [Created] (CLOUDSTACK-4446) AWSAPI server fails to start because of error in bean creation.

2013-08-22 Thread Likitha Shetty (JIRA)

Likitha Shetty created CLOUDSTACK-4446:
--

 Summary: AWSAPI server fails to start because of error in bean 
creation.
 Key: CLOUDSTACK-4446
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4446
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: AWSAPI
Affects Versions: 4.2.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Blocker
 Fix For: 4.2.1


Run mvn -Pawsapi -pl :cloud-awsapi jetty:run

Jetty server will fail to start because of failures in bean creation.

Aug 20, 2013 3:01:57 PM org.springframework.web.context.ContextLoader 
initWebApplicationContext 
SEVERE: Context initialization failed 
org.springframework.beans.factory.BeanCreationException: Error creating bean 
with name 'userContextInitializer': Injection of autowired dependencies failed; 
nested exception is org.springframework.beans.factory.BeanCreationException: 
Could not autowire field: private com.cloud.user.AccountService 
com.cloud.user.UserContextInitializer._accountMgr; nested exception is 
org.springframework.beans.factory.NoSuchBeanDefinitionException: No matching 
bean of type [com.cloud.user.AccountService] found for dependency: expected at 
least 1 bean which qualifies as autowire candidate for this dependency. 
Dependency annotations: {@javax.inject.Inject()} 
at 
org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:287)
 
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1106)
 
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:517)
 
at 
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
 
at 
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
 
at 
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)
 
at 
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)
 
at 
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
 
at 
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:609)
 
at 
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:918)
 
at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:469)
 
at 
org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:383)
 
at 
org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:283)
 
at 
org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:111)
 
at 
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3972)
 
at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:4467) 
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) 
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) 
at 
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526) 
at 
org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041) 
at 
org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964) 
at 
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502) 
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277) 
at 
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321) 
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
 
at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) 
at org.apache.catalina.core.StandardHost.start(StandardHost.java:722) 
at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) 
at 
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) 
at 
org.apache.catalina.core.StandardService.start(StandardService.java:516) 
at 
org.apache.catalina.core.StandardServer.start(StandardServer.java:710) 
at org.apache.catalina.startup.Catalina.start(Catalina.java:593) 
at sun.reflect.NativeMethodAccessorImpl.invoke0(

[jira] [Commented] (CLOUDSTACK-4021) [Automation] TestExplicitDedication.test_01_deploy_vm_with_explicit_dedication failed to deploy VM

2013-08-22 Thread Saksham Srivastava (JIRA)


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

Saksham Srivastava commented on CLOUDSTACK-4021:


There is a review request for the issue at https://reviews.apache.org/r/13560/
The explicit dedication flow has been changed, the fix on rb is according to 
the new changes.

> [Automation] 
> TestExplicitDedication.test_01_deploy_vm_with_explicit_dedication failed to 
> deploy VM
> --
>
> Key: CLOUDSTACK-4021
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4021
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Affects Versions: 4.2.0
> Environment: Automation
>Reporter: Rayees Namathponnan
>Assignee: Saksham Srivastava
> Fix For: 4.2.0
>
>
> Test case 
> "integration.component.test_explicit_dedication.TestExplicitDedication.test_01_deploy_vm_with_explicit_dedication"
>  failing automation runs 
> Error Message
> Execute cmd: asyncquery failed, due to: {errorcode : 533, errortext : 
> u'Unable to create a deployment for 
> VM[User|dec11341-27b0-4fc9-86f4-7570037a456c], Please check the affinity 
> groups provided, there may not be sufficient capacity to follow them'}
> Stacktrace
> Traceback (most recent call last):
>   File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
>   File 
> "/Repo_30X/ipcl/cloudstack/test/integration/component/test_explicit_dedication.py",
>  line 204, in test_01_deploy_vm_with_explicit_dedication
> mode=self.services["mode"]
>   File 
> "/usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py", line 
> 388, in create
> virtual_machine = apiclient.deployVirtualMachine(cmd, method=method)
>   File 
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
>  line 614, in deployVirtualMachine
> response = self.connection.marvin_request(command, 
> response_type=response, method=method)
>   File 
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line 
> 230, in marvin_request
> response = self.poll(asyncJobId, response_type)
>   File 
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line 
> 91, in poll
> "asyncquery", asyncResonse.jobresult)
> cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode : 
> 533, errortext : u'Unable to create a deployment for 
> VM[User|dec11341-27b0-4fc9-86f4-7570037a456c], Please check the affinity 
> groups provided, there may not be sufficient capacity to follow them'}
> Looks like test case trying to create VM eventhough there is no host with 
> emplty VM 

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

[jira] [Assigned] (CLOUDSTACK-4442) Source NAT not applied when network starts up

2013-08-22 Thread Murali Reddy (JIRA)


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

Murali Reddy reassigned CLOUDSTACK-4442:


Assignee: Murali Reddy

> Source NAT not applied when network starts up
> -
>
> Key: CLOUDSTACK-4442
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4442
> 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
>Reporter: Dave Cahill
>Assignee: Murali Reddy
>Priority: Blocker
> Fix For: 4.2.0
>
>
> Create a network with Source NAT but no static NAT, and no firewall rules 
> applied.
> Observed behavior:
> Source NAT is not applied when the first VM is launched (when network is 
> implemented)
> Expected:
> Source NAT enabled at network implement time
> Network devices:
> Should affect all network devices; verified in 2 separate environments, one 
> with Virtual Router only, one MidoNet only
> Further information:
> This bug seems to be a result of this change:
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=server/src/com/cloud/network/NetworkManagerImpl.java;h=2b53565297dc7bd96c6102cdc1c90cb166e9e704;hp=dac6a3a42e75324a963997e17e076f4020a7103e;hb=fe568fe;hpb=c7f26583a26eb7e4f15feafc292ec9576df61a8d
> The above change was made as a fix for CLOUDSTACK-234.
> If the user enables Static NAT, Source NAT will be applied as a side effect.

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

[jira] [Commented] (CLOUDSTACK-4446) AWSAPI server fails to start because of error in bean creation.

2013-08-22 Thread Likitha Shetty (JIRA)


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

Likitha Shetty commented on CLOUDSTACK-4446:


https://reviews.apache.org/r/13732/

> AWSAPI server fails to start because of error in bean creation.
> ---
>
> Key: CLOUDSTACK-4446
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4446
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: AWSAPI
>Affects Versions: 4.2.0
>Reporter: Likitha Shetty
>Assignee: Likitha Shetty
>Priority: Blocker
> Fix For: 4.2.1
>
>
> Run mvn -Pawsapi -pl :cloud-awsapi jetty:run
> Jetty server will fail to start because of failures in bean creation.
> Aug 20, 2013 3:01:57 PM org.springframework.web.context.ContextLoader 
> initWebApplicationContext 
> SEVERE: Context initialization failed 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'userContextInitializer': Injection of autowired dependencies 
> failed; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Could not autowire 
> field: private com.cloud.user.AccountService 
> com.cloud.user.UserContextInitializer._accountMgr; nested exception is 
> org.springframework.beans.factory.NoSuchBeanDefinitionException: No matching 
> bean of type [com.cloud.user.AccountService] found for dependency: expected 
> at least 1 bean which qualifies as autowire candidate for this dependency. 
> Dependency annotations: {@javax.inject.Inject()} 
> at 
> org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:287)
>  
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1106)
>  
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:517)
>  
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
>  
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
>  
> at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)
>  
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)
>  
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
>  
> at 
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:609)
>  
> at 
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:918)
>  
> at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:469)
>  
> at 
> org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:383)
>  
> at 
> org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:283)
>  
> at 
> org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:111)
>  
> at 
> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3972)
>  
> at 
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4467) 
> at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
>  
> at 
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) 
> at 
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526) 
> at 
> org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041) 
> at 
> org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964) 
> at 
> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502) 
> at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277) 
> at 
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321) 
> at 
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
>  
> at 
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) 
> at org.apache.catalina.core.StandardHost.start(StandardHost.java:72

[jira] [Created] (CLOUDSTACK-4447) routers tests are failing if there is a shared network exists in the physical network

Srikanteswararao Talluri created CLOUDSTACK-4447:


 Summary: routers tests are failing if there is a shared network 
exists in the physical network
 Key: CLOUDSTACK-4447
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4447
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Test
Affects Versions: 4.2.1
Reporter: Srikanteswararao Talluri
 Fix For: 4.2.1


routers tests are failing if there is a shared network exists in the physical 
network.

Fix would be to listRouters for that account of type 'Isolated'.


following two tests are failing because of the above mentioned problem:
integration.component.test_routers.TestRouterServices.test_01_AdvancedZoneRouterServices
integration.component.test_routers.TestRouterServices.test_02_NetworkGarbageCollection





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

[jira] [Closed] (CLOUDSTACK-4400) [object_store_refactor] Three entries for one template in template_store_ref when MS was restarting during template download

2013-08-22 Thread Sanjeev N (JIRA)


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

Sanjeev N closed CLOUDSTACK-4400.
-


Verified with latest build. Works fine.

> [object_store_refactor] Three entries for one template in template_store_ref 
> when MS was restarting during template download
> 
>
> Key: CLOUDSTACK-4400
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4400
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller, Template
>Affects Versions: 4.2.0
> Environment: Latest build from ACS 4.2 branch
>Reporter: Sanjeev N
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: cloud.dmp, management-server.rar
>
>
> Three entries for one template in template_store_ref when MS was restarting 
> during template download.
> Restarting management server when the template download was in progress, 
> created three entries in template_store_ref table for the same template and 
> in UI tamplate Ready is set to No even though it is downloaded to S3
> Steps to Reproduce:
> 
> 1.Bring up CS with two or three zones
> 2.Register template any one of the zones 
> 3.Restart the management server when the template download was in progres
> Result:
> =
> After restart template sync initiated template download via all the SSVMs and 
> created multiple intries in the template_store_ref for the same template. 
> In UI template is not showing as ready even though it is download to S3 via 
> one of the ssvms.
> Observations:
> =
> After management server restart, it found template 208 is not downlaoded
> 2013-08-19 08:54:01,695 INFO  [storage.image.TemplateServiceImpl] 
> (AgentConnectTaskPool-3:null) Template Sync did not find 
> 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d on image store 3, may request 
> download based on available hypervisor types
> 2013-08-19 08:54:01,709 INFO  [storage.image.TemplateServiceImpl] 
> (AgentConnectTaskPool-3:null) Removing leftover template 
> 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d entry from template store table
> 2013-08-19 08:54:01,722 INFO  [storage.image.TemplateServiceImpl] 
> (AgentConnectTaskPool-6:null) Template Sync did not find 
> 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d on image store 3, may request 
> download based on available hypervisor types
> 2013-08-19 08:54:01,722 INFO  [storage.image.TemplateServiceImpl] 
> (AgentConnectTaskPool-6:null) Removing leftover template 
> 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d entry from template store table
> 2013-08-19 08:54:01,735 INFO  [storage.image.TemplateServiceImpl] 
> (AgentConnectTaskPool-4:null) Template Sync did not find 
> 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d on image store 3, may request 
> download based on available hypervisor types
> 2013-08-19 08:54:01,735 INFO  [storage.image.TemplateServiceImpl] 
> (AgentConnectTaskPool-4:null) Removing leftover template 
> 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d entry from template store table
> 2013-08-19 08:54:01,747 INFO  [storage.image.TemplateServiceImpl] 
> (AgentConnectTaskPool-6:null) Downloading template 
> 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d to image store imagestore
> 2013-08-19 08:54:01,751 INFO  [storage.image.TemplateServiceImpl] 
> (AgentConnectTaskPool-4:null) Downloading template 
> 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d to image store imagestore
> 2013-08-19 08:54:01,753 INFO  [storage.image.TemplateServiceImpl] 
> (AgentConnectTaskPool-3:null) Downloading template 
> 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d to image store imagestore
> 2013-08-19 08:54:02,068 DEBUG [storage.image.TemplateDataFactoryImpl] 
> (AgentConnectTaskPool-4:null) template 208 is already in store:3, type:Image
> 2013-08-19 08:54:02,080 DEBUG [storage.image.TemplateDataFactoryImpl] 
> (AgentConnectTaskPool-3:null) template 208 is already in store:3, type:Image
> 2013-08-19 08:54:02,069 DEBUG [storage.image.TemplateDataFactoryImpl] 
> (AgentConnectTaskPool-6:null) template 208 is already in store:3, type:Image
> 2013-08-19 08:54:02,163 DEBUG [storage.image.BaseImageStoreDriverImpl] 
> (AgentConnectTaskPool-6:null) Downloading template to data store 3
> 2013-08-19 08:54:02,164 DEBUG [storage.image.BaseImageStoreDriverImpl] 
> (AgentConnectTaskPool-4:null) Downloading template to data store 3
> 2013-08-19 08:54:02,219 DEBUG [agent.transport.Request] 
> (AgentConnectTaskPool-3:null) Seq 3-1325465607: Sending  { Cmd , MgmtId: 
> 6615759585382, via: 3, Ver: v1, Flags: 100111, 
> [{"com.cloud.agent.api.ReadyCommand":{"dcId":1,"hostId":3,"wait":0}}] }
> 2013-08-19 08:54:0

[jira] [Updated] (CLOUDSTACK-4446) AWSAPI server fails to start because of error in bean creation.

2013-08-22 Thread Likitha Shetty (JIRA)


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

Likitha Shetty updated CLOUDSTACK-4446:
---

Status: Ready To Review  (was: In Progress)

> AWSAPI server fails to start because of error in bean creation.
> ---
>
> Key: CLOUDSTACK-4446
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4446
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: AWSAPI
>Affects Versions: 4.2.0
>Reporter: Likitha Shetty
>Assignee: Likitha Shetty
>Priority: Blocker
> Fix For: 4.2.1
>
>
> Run mvn -Pawsapi -pl :cloud-awsapi jetty:run
> Jetty server will fail to start because of failures in bean creation.
> Aug 20, 2013 3:01:57 PM org.springframework.web.context.ContextLoader 
> initWebApplicationContext 
> SEVERE: Context initialization failed 
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 'userContextInitializer': Injection of autowired dependencies 
> failed; nested exception is 
> org.springframework.beans.factory.BeanCreationException: Could not autowire 
> field: private com.cloud.user.AccountService 
> com.cloud.user.UserContextInitializer._accountMgr; nested exception is 
> org.springframework.beans.factory.NoSuchBeanDefinitionException: No matching 
> bean of type [com.cloud.user.AccountService] found for dependency: expected 
> at least 1 bean which qualifies as autowire candidate for this dependency. 
> Dependency annotations: {@javax.inject.Inject()} 
> at 
> org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:287)
>  
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1106)
>  
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:517)
>  
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
>  
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
>  
> at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)
>  
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)
>  
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
>  
> at 
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:609)
>  
> at 
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:918)
>  
> at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:469)
>  
> at 
> org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:383)
>  
> at 
> org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:283)
>  
> at 
> org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:111)
>  
> at 
> org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3972)
>  
> at 
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4467) 
> at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
>  
> at 
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) 
> at 
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526) 
> at 
> org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041) 
> at 
> org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964) 
> at 
> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502) 
> at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277) 
> at 
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321) 
> at 
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
>  
> at 
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) 
> at org.apache.catalina.core.StandardHost.start(StandardHost.java:722) 
> at 
> org.apache.catalina.core.ContainerBas

[jira] [Updated] (CLOUDSTACK-4447) routers tests are failing if there is a shared network exists in the physical network


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

Srikanteswararao Talluri updated CLOUDSTACK-4447:
-

Assignee: Srikanteswararao Talluri

> routers tests are failing if there is a shared network exists in the physical 
> network
> -
>
> Key: CLOUDSTACK-4447
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4447
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Test
>Affects Versions: 4.2.1
>Reporter: Srikanteswararao Talluri
>Assignee: Srikanteswararao Talluri
> Fix For: 4.2.1
>
>
> routers tests are failing if there is a shared network exists in the physical 
> network.
> Fix would be to listRouters for that account of type 'Isolated'.
> following two tests are failing because of the above mentioned problem:
> integration.component.test_routers.TestRouterServices.test_01_AdvancedZoneRouterServices
> integration.component.test_routers.TestRouterServices.test_02_NetworkGarbageCollection

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

[jira] [Closed] (CLOUDSTACK-4372) [XenServer] Commands info which are executed via xenserver are not logged in SMlog

2013-08-22 Thread Sanjeev N (JIRA)


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

Sanjeev N closed CLOUDSTACK-4372.
-


Not able to reproduce it. I will reopen if I see this issue again.

> [XenServer] Commands info which are executed via xenserver are not logged in 
> SMlog
> --
>
> Key: CLOUDSTACK-4372
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4372
> 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.0
> Environment: Latest build from ACS 4.2 branch
> XenServer: 6.2
>Reporter: Sanjeev N
>Assignee: Devdeep Singh
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.rar, messages, SMlog, xensource.log
>
>
> ll
> Any command info wich CS executes via xenserver is supposed to be logged in 
> SMlog.
> But in my setup after bringing up setup , initially messages for logged in 
> SMlog but after sometime I didn't see any updates in the SMlog. 
> Usually SMlog rotation happens quite frequently but this time I din't see any 
> update in SMlog after certain point of time.
> Whatever the commands CS executes via xenserver will be logged in SMlog but I 
> don't see them after some time. Looks like some issue with SMlog rotation.
> I tried to create snapshots on multiple data disks after immediately brining 
> up my setup with few guest vms.
> For first snapshot I could see the logging info in SMlog. But for the next 
> snapshots I dint see any info in SMlog.
> 2013-08-16 08:59:09,066 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-20:job-20 = [ be35359a-ccc0-41d1-b1e0-ddbaa357d570 ]) Executing 
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd for job-20 
> = [ be35359a-ccc0-41d1-b1e0-ddbaa357d570 ]
> 2013-08-16 08:59:09,099 INFO  [user.snapshot.CreateSnapshotCmd] 
> (Job-Executor-20:job-20 = [ be35359a-ccc0-41d1-b1e0-ddbaa357d570 ]) VOLSS: 
> createSnapshotCmd starts:1376657949099
> 2013-08-16 08:59:09,149 DEBUG [agent.transport.Request] 
> (Job-Executor-20:job-20 = [ be35359a-ccc0-41d1-b1e0-ddbaa357d570 ]) Seq 
> 1-2011234581: Sending  { Cmd , MgmtId: 6615759585382, via: 1, Ver: v1, Flags: 
> 100011, 
> [{"org.apache.cloudstack.storage.command.CreateObjectCommand":{"data":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"volume":{"uuid":"ed6dc51d-713b-400d-9006-8256b9cb9e82","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"c65a038a-750c-3b4f-bf26-7ce3b74e1c85","id":2,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/sanjeev/pri_xen_os","port":2049}},"name":"test","size":5368709120,"path":"d700bb94-7489-4c80-9099-e8b484794c6e","volumeId":7,"vmName":"i-2-5-VM","accountId":2,"format":"VHD","id":7,"hypervisorType":"XenServer"},"dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"c65a038a-750c-3b4f-bf26-7ce3b74e1c85","id":2,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/sanjeev/pri_xen_os","port":2049}},"vmName":"i-2-5-VM","name":"vm2-xen_test_20130816125908","hypervisorType":"XenServer","id":4}},"wait":0}}]
>  }
> 2013-08-16 08:59:09,149 DEBUG [agent.transport.Request] 
> (Job-Executor-20:job-20 = [ be35359a-ccc0-41d1-b1e0-ddbaa357d570 ]) Seq 
> 1-2011234581: Executing:  { Cmd , MgmtId: 6615759585382, via: 1, Ver: v1, 
> Flags: 100011, 
> [{"org.apache.cloudstack.storage.command.CreateObjectCommand":{"data":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"volume":{"uuid":"ed6dc51d-713b-400d-9006-8256b9cb9e82","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"c65a038a-750c-3b4f-bf26-7ce3b74e1c85","id":2,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/sanjeev/pri_xen_os","port":2049}},"name":"test","size":5368709120,"path":"d700bb94-7489-4c80-9099-e8b484794c6e","volumeId":7,"vmName":"i-2-5-VM","accountId":2,"format":"VHD","id":7,"hypervisorType":"XenServer"},"dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"c65a038a-750c-3b4f-bf26-7ce3b74e1c85","id":2,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/sanjeev/pri_xen_os","port":2049}},"vmName":"i-2-5-VM","name":"vm2-xen_test_20130816125908","hypervisorType":"XenServer","id":4}},"wait":0}}]
>  }
> createSnapshotCmd was executed via 1 , here 1 is the xenserver host.
> mysql> select id,name,hypervisor_type  from host where id=1;
> ++-+-+
> | id | name| hypervisor_type |
> ++-+-+
> |  1 | Rack1Pod1Host14 | XenServer   |
> ++---

[jira] [Updated] (CLOUDSTACK-4448) test_03_RouterStartOnVmDeploy is failing due to pre-existing VMs state


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

Srikanteswararao Talluri updated CLOUDSTACK-4448:
-

Assignee: Srikanteswararao Talluri

> test_03_RouterStartOnVmDeploy is failing due to pre-existing VMs state
> --
>
> Key: CLOUDSTACK-4448
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4448
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Test
>Affects Versions: 4.2.1
>Reporter: Srikanteswararao Talluri
>Assignee: Srikanteswararao Talluri
> Fix For: 4.2.1
>
>
> test_03_RouterStartOnVmDeploy expects all the pre-existing VMs to be in 
> stopped state but it doesn't ensure all the VMs are stopped when it starts. 
> It relies on the previous tests to stop the VMs and if the previous test 
> fails, this test will also fail.

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

[jira] [Created] (CLOUDSTACK-4448) test_03_RouterStartOnVmDeploy is failing due to pre-existing VMs state

2013-08-22 Thread ASF subversion and git services (JIRA)

Srikanteswararao Talluri created CLOUDSTACK-4448:


 Summary: test_03_RouterStartOnVmDeploy is failing due to 
pre-existing VMs state
 Key: CLOUDSTACK-4448
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4448
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Test
Affects Versions: 4.2.1
Reporter: Srikanteswararao Talluri
 Fix For: 4.2.1


test_03_RouterStartOnVmDeploy expects all the pre-existing VMs to be in stopped 
state but it doesn't ensure all the VMs are stopped when it starts. It relies 
on the previous tests to stop the VMs and if the previous test fails, this test 
will also fail.



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

[jira] [Closed] (CLOUDSTACK-3039) Failed to attach volumes for clusters with id > 127

2013-08-22 Thread Nitin Mehta (JIRA)


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

Nitin Mehta closed CLOUDSTACK-3039.
---


> Failed to attach volumes for clusters with id > 127
> ---
>
> Key: CLOUDSTACK-3039
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3039
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.2.0
>Reporter: Nitin Mehta
>Assignee: Nitin Mehta
> Fix For: 4.2.0
>
>
> Failed to attach volumes for clusters with id > 128 
> The reason is because we use Java == than the equals for comparing Long 
> object. This operation works till 127 because of JVM optimization where it 
> precreates objects from -127 to 128 and passes the same reference instead of 
> creating a new instance every time

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

[jira] [Comment Edited] (CLOUDSTACK-3039) Failed to attach volumes for clusters with id > 127

2013-08-22 Thread Nitin Mehta (JIRA)


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

Nitin Mehta edited comment on CLOUDSTACK-3039 at 8/22/13 10:45 AM:
---

With the object store code checked in, the old code is thrown away and in the 
new code we are doing it right way

  was (Author: nitinme):
With the object store code checked in, dont need to check this any more.
  
> Failed to attach volumes for clusters with id > 127
> ---
>
> Key: CLOUDSTACK-3039
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3039
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.2.0
>Reporter: Nitin Mehta
>Assignee: Nitin Mehta
> Fix For: 4.2.0
>
>
> Failed to attach volumes for clusters with id > 128 
> The reason is because we use Java == than the equals for comparing Long 
> object. This operation works till 127 because of JVM optimization where it 
> precreates objects from -127 to 128 and passes the same reference instead of 
> creating a new instance every time

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

[jira] [Commented] (CLOUDSTACK-4185) [DOC][upgrade][2.2.14 to 4.2][vmware]Need to encrypt the vCenter password manually and add to the cluster_details table and vmware_data_center table after upgrade.


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

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

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

CLOUDSTACK-4185 vmware steps for upgrade paths


> [DOC][upgrade][2.2.14 to 4.2][vmware]Need to encrypt the vCenter password 
> manually and add to the cluster_details table and vmware_data_center table 
> after upgrade.
> ---
>
> Key: CLOUDSTACK-4185
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4185
> 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: Abhinav Roy
>Assignee: Radhika Nair
> Fix For: 4.2.0
>
>
> In the release notes where we document about the upgrades from 2.2.x to 4.2 
> on ESXi hosts, we need to document this.
> =
> 1. upgrade from 2.2.14 to 4.2 using "U" in install.sh script.
> 2. run cloudstack-setup-encrytpion 
> Now, generate the encrypted equivalent of your vCenter password ..
> 3.  java -classpath /usr/share/cloudstack-common/lib/jasypt-1.9.0.jar 
> org.jasypt.intf.cli.JasyptPBEStringEncryptionCLI encrypt.sh 
> input="_your_vCenter_password_" password="`cat 
> /etc/cloudstack/management/key`" verbose=false
> Store the output from this step, we need to add this in cluster_details table 
> and vmware_data_center tables in place of the plaintext password.
> 4. Find the id of the correct row of cluster_details to update... i.e. the 
> row with the plain text password:
> select * from cloud.cluster_details;
> 5. update the plain text password with the encrypted one (be very careful to 
> update the correct row):
> update cloud.cluster_details set value = '_ciphertext_from_step_3_' where 
> id = _id_from_step_4_;
> 6. Check the table again to confirm it looks good:
> select * from cloud.cluster_details;
> 7. Find the id of the correct row of vmware_data_center to update... i.e. the 
> row with the plain text password:
> select * from cloud.vmware_data_center;
> 8. update the plain text password with the encrypted one (be very careful to 
> update the correct row):
> update cloud.vmware_data_center set password = '_ciphertext_from_step_3_' 
> where id = _id_from_step_7_;
> 9. Check the table again to confirm it looks good:
>select * from cloud.vmware_data_center;
> 10. Start the cloudstack management server
>service cloudstack-management start

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

[jira] [Commented] (CLOUDSTACK-4438) Improve documentation for traffic labels configuration KVM, vSphere, and XenServer

2013-08-22 Thread Sateesh Chodapuneedi (JIRA)


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

Sateesh Chodapuneedi commented on CLOUDSTACK-4438:
--

CLOUDSTACK-3398 talks about UI improvement to reflect the enhancement done for 
traffic label. As part of implementing vDS support in cloudstack, vmware 
traffic label is added one more field. It is vswitch type. Please find more 
about traffic label format can be found in FS with very detailed description of 
the label with examples.

Following is from FS at 
https://cwiki.apache.org/CLOUDSTACK/integration-of-cloudstack-with-vmware-dvs.html

See point (2) in section - Architecture and Design description

•   Traffic label format is [["Name of 
vSwitch/dvSwitch/EthernetPortProfile"][,["VLAN ID"][,["vSwitch Type" 
1.  Description
2.  All the 3 fields are optional
3.  Default values for the 3 fields are as below 
1.  1st field - Represents the name of virtual/distributed virtual switch 
at vCenter. The default value assumed would depend upon the type of virtual 
switch. Defaults values are as follows. 
1.  vSwitch0 if type of virtual switch is "VMware vNetwork Standard virtual 
switch"
2.  dvSwitch0 if type of virtual switch is "VMware vNetwork distributed 
virtual switch"
3.  epp0 if type of virtual switch is "Cisco Nexus 1000v distributed 
virtual switch"
2.  2nd field - VLAN ID to be used for this traffic where ever applicable. 
This field would be used for only public traffic as of now. In case of guest 
traffic this field would be ignored and could be left empty for guest traffic. 
1.  By default empty string would be assumed which translates to untagged 
VLAN for that specific traffic type.
3.  3rd field - Type of virtual switch specified as string. Possible valid 
values are vmwaredvs, vmwaresvs, nexusdvs. Each translates as follows. 
1.  "vmwaresvs" represents "VMware vNetwork Standard virtual switch"
2.  "vmwaredvs" represents "VMware vNetwork distributed virtual switch"
3.  "nexusdvs" represents "Cisco Nexus 1000v distributed virtual switch"
4.  If nothing is specified (left empty) that means zone level default 
virtual switch (based on value of global parameters) would be assumed. 
Following are the global configuration parameters. 
1.  vmware.use.dvswitch - This should be true to enable any kind (VMware 
DVS / Cisco Nexus 1000v DVS) of distributed virtual switch in cloudstack 
deployment. If this is false that means default virtual switch in that 
cloudstack deployment is "standard virtual switch" only.
2.  vmware.use.nexus.vswitch - This parameter would be ignored unless 
"vmware.use.dvswitch" is true. Set this to "true" to enable Cisco Nexus 1000v 
distributed virtual switch in a cloudstack deployment.
4.  As per above mentioned format, furnishing few possible values for 
networkLabel, 
1.  "" (empty string)
2.  dvSwitch0
3.  dvSwitch0,200
4.  dvSwitch0,300,vmwaredvs
5.  myEthernetPortProfile,,nexusdvs
6.  dvSwitch0,,vmwaredvs



> Improve documentation for traffic labels configuration KVM, vSphere, and 
> XenServer
> --
>
> Key: CLOUDSTACK-4438
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4438
> 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: Kirk Kosinski
>  Labels: installguide, kvm, networking, vsphere, xenserver
>
> The installation guide currently has a "Physical Networking Setup for 
> XenServer" section (see CLOUDSTACK-661). There should be corresponding 
> sections for KVM and vSphere, and the XenServer section can use some slight 
> improvements.
> For KVM, the traffic labels defined in CloudStack should correspond to the 
> bridge name on the hypervisor, and for vSphere the traffic labels should 
> correspond to the vSwitch name. 
> For vSphere, a VLAN ID can be included for management traffic (see 
> CLOUDSTACK-3870). There are some references to this currently but no clear 
> explanation. The syntax is (currently) ",", for 
> example "vSwitch0,100" for vSwitch0 and VLAN ID 100. This might change if 
> CLOUDSTACK-3398 is implemented.
> Considering that vSphere supports a VLAN ID for management traffic, in the 
> XenServer section it would be wise to explicitly state that management server 
> traffic must not be put on a VLAN. This is explained in the XenServer 
> documentation but is commonly misunderstood.

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

[jira] [Comment Edited] (CLOUDSTACK-4438) Improve documentation for traffic labels configuration KVM, vSphere, and XenServer

2013-08-22 Thread Sateesh Chodapuneedi (JIRA)

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

Sateesh Chodapuneedi edited comment on CLOUDSTACK-4438 at 8/22/13 11:20 AM:

CLOUDSTACK-3398/CLOUDSTACK-4089 talks about UI improvement to reflect the
enhancement done for traffic label. As part of implementing vDS support in
cloudstack, vmware traffic label is added one more field. It is vswitch type.
Please find more about traffic label format can be found in FS with very
detailed description of the label with examples.

Following is from FS at
https://cwiki.apache.org/CLOUDSTACK/integration-of-cloudstack-with-vmware-dvs.html

See point (2) in section - Architecture and Design description

• Traffic label format is [["Name of
vSwitch/dvSwitch/EthernetPortProfile"][,["VLAN ID"][,["vSwitch Type"
1. Description
2. All the 3 fields are optional
3. Default values for the 3 fields are as below
1. 1st field - Represents the name of virtual/distributed virtual switch
at vCenter. The default value assumed would depend upon the type of virtual
switch. Defaults values are as follows.
1. vSwitch0 if type of virtual switch is "VMware vNetwork Standard virtual
switch"
2. dvSwitch0 if type of virtual switch is "VMware vNetwork distributed
virtual switch"
3. epp0 if type of virtual switch is "Cisco Nexus 1000v distributed
virtual switch"
2. 2nd field - VLAN ID to be used for this traffic where ever applicable.
This field would be used for only public traffic as of now. In case of guest
traffic this field would be ignored and could be left empty for guest traffic.
1. By default empty string would be assumed which translates to untagged
VLAN for that specific traffic type.
3. 3rd field - Type of virtual switch specified as string. Possible valid
values are vmwaredvs, vmwaresvs, nexusdvs. Each translates as follows.
1. "vmwaresvs" represents "VMware vNetwork Standard virtual switch"
2. "vmwaredvs" represents "VMware vNetwork distributed virtual switch"
3. "nexusdvs" represents "Cisco Nexus 1000v distributed virtual switch"
4. If nothing is specified (left empty) that means zone level default
virtual switch (based on value of global parameters) would be assumed.
Following are the global configuration parameters.
1. vmware.use.dvswitch - This should be true to enable any kind (VMware
DVS / Cisco Nexus 1000v DVS) of distributed virtual switch in cloudstack
deployment. If this is false that means default virtual switch in that
cloudstack deployment is "standard virtual switch" only.
2. vmware.use.nexus.vswitch - This parameter would be ignored unless
"vmware.use.dvswitch" is true. Set this to "true" to enable Cisco Nexus 1000v
distributed virtual switch in a cloudstack deployment.
4. As per above mentioned format, furnishing few possible values for
networkLabel,
1. "" (empty string)
2. dvSwitch0
3. dvSwitch0,200
4. dvSwitch0,300,vmwaredvs
5. myEthernetPortProfile,,nexusdvs
6. dvSwitch0,,vmwaredvs

was (Author: sateeshc):
CLOUDSTACK-3398 talks about UI improvement to reflect the enhancement done
for traffic label. As part of implementing vDS support in cloudstack, vmware
traffic label is added one more field. It is vswitch type. Please find more
about traffic label format can be found in FS with very detailed description of
the label with examples.

Following is from FS at
https://cwiki.apache.org/CLOUDSTACK/integration-of-cloudstack-with-vmware-dvs.html

See point (2) in section - Architecture and Design description

[jira] [Assigned] (CLOUDSTACK-770) documentation on nTier Apps 2.0

2013-08-22 Thread Radhika Nair (JIRA)


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

Radhika Nair reassigned CLOUDSTACK-770:
---

Assignee: Radhika Nair  (was: Sudha Ponnaganti)

> documentation on nTier Apps 2.0
> ---
>
> Key: CLOUDSTACK-770
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-770
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Doc
>Reporter: Radhika Nair
>Assignee: Radhika Nair
> Fix For: 4.2.0
>
> Attachments: Apache_CloudStack-4.2.0-Admin_Guide-en-US.zip
>
>
> doc for nTier Apps 2.0

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

[jira] [Resolved] (CLOUDSTACK-770) documentation on nTier Apps 2.0

2013-08-22 Thread Radhika Nair (JIRA)


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

Radhika Nair resolved CLOUDSTACK-770.
-

Resolution: Fixed

> documentation on nTier Apps 2.0
> ---
>
> Key: CLOUDSTACK-770
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-770
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Doc
>Reporter: Radhika Nair
>Assignee: Sudha Ponnaganti
> Fix For: 4.2.0
>
> Attachments: Apache_CloudStack-4.2.0-Admin_Guide-en-US.zip
>
>
> doc for nTier Apps 2.0

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

[jira] [Created] (CLOUDSTACK-4449) Possibility of /tmp/xapilog filling up the Root disk on Xenserver

Sanjay Tripathi created CLOUDSTACK-4449:
---

 Summary: Possibility of /tmp/xapilog filling up the Root disk on 
Xenserver 
 Key: CLOUDSTACK-4449
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4449
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: XenServer
Affects Versions: 4.2.0
Reporter: Sanjay Tripathi
Assignee: Sanjay Tripathi
 Fix For: 4.2.1


CloudStack installs "/opt/xensource/sm/hostvmstats.py" script into XenServer. 
And the script keeps outputting the log into "/tmp/xapilog." Now the log is 
being huge size (Almost 120MBytes) since the file has no architecture to 
delete/compress. 



The info logged in /opt/xensource/sm/hostvmstats.py is not much useful. There 
are few cases in the past where CloudPlatform was contributing to Root 
filesystem being full on xenserver. We need to make sure either we 
delete/overwrite the file /tmp/xapilog in Xenserver.



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

[jira] [Created] (CLOUDSTACK-4450) Possibility of /tmp/xapilog filling up the Root disk on Xenserver

Sanjay Tripathi created CLOUDSTACK-4450:
---

 Summary: Possibility of /tmp/xapilog filling up the Root disk on 
Xenserver 
 Key: CLOUDSTACK-4450
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4450
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: XenServer
Affects Versions: 4.2.0
Reporter: Sanjay Tripathi
Assignee: Sanjay Tripathi
 Fix For: 4.2.1


CloudStack installs "/opt/xensource/sm/hostvmstats.py" script into XenServer. 
And the script keeps outputting the log into "/tmp/xapilog." Now the log is 
being huge size (Almost 120MBytes) since the file has no architecture to 
delete/compress. 



The info logged in /opt/xensource/sm/hostvmstats.py is not much useful. There 
are few cases in the past where CloudStack was contributing to Root filesystem 
being full on xenserver. We need to make sure either we delete/overwrite/rotate 
the file /tmp/xapilog in Xenserver.



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

[jira] [Resolved] (CLOUDSTACK-4449) Possibility of /tmp/xapilog filling up the Root disk on Xenserver

2013-08-22 Thread Devdeep Singh (JIRA)


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

Devdeep Singh resolved CLOUDSTACK-4449.
---

Resolution: Duplicate

Looks like 2 bugs got created for the same issue.

> Possibility of /tmp/xapilog filling up the Root disk on Xenserver 
> --
>
> Key: CLOUDSTACK-4449
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4449
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: XenServer
>Affects Versions: 4.2.0
>Reporter: Sanjay Tripathi
>Assignee: Sanjay Tripathi
> Fix For: 4.2.1
>
>
> CloudStack installs "/opt/xensource/sm/hostvmstats.py" script into XenServer. 
> And the script keeps outputting the log into "/tmp/xapilog." Now the log is 
> being huge size (Almost 120MBytes) since the file has no architecture to 
> delete/compress. 
> The info logged in /opt/xensource/sm/hostvmstats.py is not much useful. There 
> are few cases in the past where CloudPlatform was contributing to Root 
> filesystem being full on xenserver. We need to make sure either we 
> delete/overwrite the file /tmp/xapilog in Xenserver.

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

[jira] [Updated] (CLOUDSTACK-4450) Possibility of /tmp/xapilog filling up the Root disk on Xenserver


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

Sanjay Tripathi updated CLOUDSTACK-4450:


Status: Ready To Review  (was: In Progress)

> Possibility of /tmp/xapilog filling up the Root disk on Xenserver 
> --
>
> Key: CLOUDSTACK-4450
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4450
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: XenServer
>Affects Versions: 4.2.0
>Reporter: Sanjay Tripathi
>Assignee: Sanjay Tripathi
> Fix For: 4.2.1
>
>
> CloudStack installs "/opt/xensource/sm/hostvmstats.py" script into XenServer. 
> And the script keeps outputting the log into "/tmp/xapilog." Now the log is 
> being huge size (Almost 120MBytes) since the file has no architecture to 
> delete/compress. 
> The info logged in /opt/xensource/sm/hostvmstats.py is not much useful. There 
> are few cases in the past where CloudStack was contributing to Root 
> filesystem being full on xenserver. We need to make sure either we 
> delete/overwrite/rotate the file /tmp/xapilog in Xenserver.

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

[jira] [Commented] (CLOUDSTACK-4450) Possibility of /tmp/xapilog filling up the Root disk on Xenserver


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

Sanjay Tripathi commented on CLOUDSTACK-4450:
-

Fix is available for review at: https://reviews.apache.org/r/13735/

> Possibility of /tmp/xapilog filling up the Root disk on Xenserver 
> --
>
> Key: CLOUDSTACK-4450
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4450
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: XenServer
>Affects Versions: 4.2.0
>Reporter: Sanjay Tripathi
>Assignee: Sanjay Tripathi
> Fix For: 4.2.1
>
>
> CloudStack installs "/opt/xensource/sm/hostvmstats.py" script into XenServer. 
> And the script keeps outputting the log into "/tmp/xapilog." Now the log is 
> being huge size (Almost 120MBytes) since the file has no architecture to 
> delete/compress. 
> The info logged in /opt/xensource/sm/hostvmstats.py is not much useful. There 
> are few cases in the past where CloudStack was contributing to Root 
> filesystem being full on xenserver. We need to make sure either we 
> delete/overwrite/rotate the file /tmp/xapilog in Xenserver.

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

[jira] [Assigned] (CLOUDSTACK-4434) EN: Ubuntu: Direct input "- _ ", "? /", "keyboard /" ,"keyboard -" keys are not working well for the US keyboard.


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

Sanjay Tripathi reassigned CLOUDSTACK-4434:
---

Assignee: Sanjay Tripathi

> EN: Ubuntu: Direct input "- _ ", "? /", "keyboard /" ,"keyboard -" keys are 
> not working well for the US keyboard.
> -
>
> Key: CLOUDSTACK-4434
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4434
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VNC Proxy
>Affects Versions: 4.2.0
> Environment: Environment
> Build#CloudPlatform-4.2-465(CloudPlatform-4.2-465-rhel6.3.tar.gz) 
> XenServer6.1 for Host Server
> CentOS6.3 for NFS, CS-Mgr Servers.
> Client & Browser: Ubuntu-Firefox23.0, Win7-Firefox23.0, Win7-Chrome, Win7-IE, 
> Mac-Safari
>Reporter: Minying Bao
>Assignee: Sanjay Tripathi
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: EN_Ubuntu VM_Outputting Endless.jpg
>
>
> Repro Steps
> 1. Setup the CloudStack environments with build 4.2#465. 
> 2. Bring ubuntu VM. 
> 3. Access the VM via Console Proxy from the Ubuntu client machine connected 
> to US Keyboard. 
> 4. Hit all the keys with US keyboard.
> Expected Result
> All the keys should work fine.
> Actual Result
> First time, press the "- _ ", "? /", "keyboard /" ,"keyboard -" keys.
> It seemed that the output for those keys will keep on outputting endless. 
> Even if we have stopped pressing the key. (Refer to attached screenshot.)
> We could press "Enter" to stop the endless outputting.
> Then, try to press the four keys again, the keys were not working at all.
> Client/Browser Info.
> Ubuntu-FF23.0 -> Fail
> Win7-FF22.0 -> Fail
> Win7-Chrome -> Fail
> Win7-IE -> Fail
> Mac-Safari -> Fail

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

[jira] [Created] (CLOUDSTACK-4451) associateIPaddress requires zone id but apidoc says it's optional

2013-08-22 Thread sebastien goasguen (JIRA)

sebastien goasguen created CLOUDSTACK-4451:
--

 Summary: associateIPaddress requires zone id but apidoc says it's 
optional
 Key: CLOUDSTACK-4451
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4451
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: API
Affects Versions: 4.2.0
Reporter: sebastien goasguen
 Fix For: Future


apidoc for associateIPaddress says that zone id is optional:
http://cloudstack.apache.org/docs/api/apidocs-4.1/root_admin/associateIpAddress.html

but it's required:

Try calling it with cloudmonkey without any arguments.

Exception: {u'associateipaddressresponse': {u'errorcode': 431, u'uuidList': [], 
u'errortext': u'Unable to figure out zone to assign ip to'}}


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

[jira] [Updated] (CLOUDSTACK-4434) EN: Ubuntu: Direct input "- _ ", "? /", "keyboard /" ,"keyboard -" keys are not working well for the US keyboard.


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

Sanjay Tripathi updated CLOUDSTACK-4434:


Fix Version/s: (was: 4.2.0)
   4.2.1

> EN: Ubuntu: Direct input "- _ ", "? /", "keyboard /" ,"keyboard -" keys are 
> not working well for the US keyboard.
> -
>
> Key: CLOUDSTACK-4434
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4434
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VNC Proxy
>Affects Versions: 4.2.0
> Environment: Environment
> Build#CloudPlatform-4.2-465(CloudPlatform-4.2-465-rhel6.3.tar.gz) 
> XenServer6.1 for Host Server
> CentOS6.3 for NFS, CS-Mgr Servers.
> Client & Browser: Ubuntu-Firefox23.0, Win7-Firefox23.0, Win7-Chrome, Win7-IE, 
> Mac-Safari
>Reporter: Minying Bao
>Assignee: Sanjay Tripathi
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: EN_Ubuntu VM_Outputting Endless.jpg
>
>
> Repro Steps
> 1. Setup the CloudStack environments with build 4.2#465. 
> 2. Bring ubuntu VM. 
> 3. Access the VM via Console Proxy from the Ubuntu client machine connected 
> to US Keyboard. 
> 4. Hit all the keys with US keyboard.
> Expected Result
> All the keys should work fine.
> Actual Result
> First time, press the "- _ ", "? /", "keyboard /" ,"keyboard -" keys.
> It seemed that the output for those keys will keep on outputting endless. 
> Even if we have stopped pressing the key. (Refer to attached screenshot.)
> We could press "Enter" to stop the endless outputting.
> Then, try to press the four keys again, the keys were not working at all.
> Client/Browser Info.
> Ubuntu-FF23.0 -> Fail
> Win7-FF22.0 -> Fail
> Win7-Chrome -> Fail
> Win7-IE -> Fail
> Mac-Safari -> Fail

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

[jira] [Commented] (CLOUDSTACK-3535) No HA actions are performed when a KVM host goes offline

2013-08-22 Thread Paul Angus (JIRA)


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

Paul Angus commented on CLOUDSTACK-3535:


I've tested the HA functionality on KVM and found that it did not work.

CloudStack ssems unable to 'stop' the VM which was on a host that failed 
because the host is unavailable.  I waited an hour and the instance remained in 
the state 'stopping'.  I then restarted the host and the instance stopped, but 
5 hours later it hasn't restarted.


2013-08-22 08:35:09,802 INFO  [cloud.ha.HighAvailabilityManagerImpl] 
(HA-Worker-0:work-3) KVMInvestigator found VM[User|HA-Test1]to be alive? null
2013-08-22 08:35:09,802 DEBUG [cloud.ha.HighAvailabilityManagerImpl] 
(HA-Worker-0:work-3) Fencing off VM that we don't know the state of
2013-08-22 08:35:09,802 DEBUG [cloud.ha.XenServerFencer] (HA-Worker-0:work-3) 
Don't know how to fence non XenServer hosts KVM
2013-08-22 08:35:09,803 INFO  [cloud.ha.HighAvailabilityManagerImpl] 
(HA-Worker-0:work-3) Fencer null returned null
2013-08-22 08:35:09,807 DEBUG [agent.transport.Request] (HA-Worker-0:work-3) 
Seq 2-1715210012: Sending  { Cmd , MgmtId: 345049337494, via: 2, Ver: v1, 
Flags: 100011, 
[{"com.cloud.agent.api.FenceCommand":{"vmName":"i-2-42-VM","hostGuid":"fdf1e936-0373-389b-abef-a68e339ff910-LibvirtComputingResource","hostIp":"10.0.100.41","inSeq":false,"wait":0}}]
 }
2013-08-22 08:35:09,905 DEBUG [agent.transport.Request] 
(AgentManager-Handler-13:null) Seq 2-1715210012: Processing:  { Ans: , MgmtId: 
345049337494, via: 2, Ver: v1, Flags: 10, 
[{"com.cloud.agent.api.FenceAnswer":{"result":true,"wait":0}}] }
2013-08-22 08:35:09,905 DEBUG [agent.transport.Request] (HA-Worker-0:work-3) 
Seq 2-1715210012: Received:  { Ans: , MgmtId: 345049337494, via: 2, Ver: v1, 
Flags: 10, { FenceAnswer } }
2013-08-22 08:35:09,905 INFO  [cloud.ha.HighAvailabilityManagerImpl] 
(HA-Worker-0:work-3) Fencer KVMFenceBuilder returned true
2013-08-22 08:35:09,911 DEBUG [cloud.capacity.CapacityManagerImpl] 
(HA-Worker-0:work-3) VM state transitted from :Running to Stopping with event: 
StopRequestedvm's original host id: 5 new host id: 5 host id before state 
transition: 5
2013-08-22 08:35:09,916 WARN  [cloud.vm.VirtualMachineManagerImpl] 
(HA-Worker-0:work-3) Unable to stop vm, agent unavailable: 
com.cloud.exception.AgentUnavailableException: Resource [Host:5] is 
unreachable: Host 5: Host with specified id is not in the right state: Down
2013-08-22 08:35:09,916 WARN  [cloud.vm.VirtualMachineManagerImpl] 
(HA-Worker-0:work-3) Unable to actually stop VM[User|HA-Test1] but continue 
with release because it's a force stop
2013-08-22 08:35:09,920 ERROR [cloud.ha.HighAvailabilityManagerImpl] 
(HA-Worker-0:work-3) Terminating HAWork[3-HA-42-Running-Investigating]
com.cloud.utils.exception.CloudRuntimeException: Caught exception even though 
it should be handled.
at 
com.cloud.ha.HighAvailabilityManagerImpl.restart(HighAvailabilityManagerImpl.java:479)
at 
com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.run(HighAvailabilityManagerImpl.java:831)
Caused by: com.cloud.exception.AgentUnavailableException: Resource [Host:5] is 
unreachable: Host 5: Host with specified id is not in the right state: Down
at 
com.cloud.agent.manager.ClusteredAgentManagerImpl.getAttache(ClusteredAgentManagerImpl.java:540)
at 
com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:479)
at 
com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:439)
at 
com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1220)
at 
com.cloud.ha.HighAvailabilityManagerImpl.restart(HighAvailabilityManagerImpl.java:476)
... 1 more


> No HA actions are performed when a KVM host goes offline
> 
>
> Key: CLOUDSTACK-3535
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3535
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Hypervisor Controller, KVM, Management Server
>Affects Versions: 4.1.0, 4.1.1, 4.2.0
> Environment: KVM (CentOS 6.3) with CloudStack 4.1
>Reporter: Paul Angus
>Assignee: edison su
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: extract-management-server.log.2013-08-09, 
> KVM-HA-4.1.1.2013-08-09-v1.patch, management-server.log.Agent
>
>
> If a KVM host 'goes down', CloudStack does not perform HA for instances which 
> are marked as HA enabled on that host (including system VMs)
> CloudStack does not show the host as disconnected.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA admi

[jira] [Commented] (CLOUDSTACK-4452) test_snapshots.py - The method used to check whether snapshot exists on secondary storage is wrong


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

Gaurav Aradhye commented on CLOUDSTACK-4452:


Adding a patch for this in few mins.

> test_snapshots.py - The method used to check whether snapshot exists on 
> secondary storage is wrong
> --
>
> Key: CLOUDSTACK-4452
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4452
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Snapshot
>Affects Versions: 4.2.0
>Reporter: Gaurav Aradhye
>Assignee: Gaurav Aradhye
> Fix For: 4.2.0
>
>
> Following test case failing due to this:
> 1. test_01_createVM_snapshotTemplate
> 2. test_02_snapshot_data_disk
> 3. test_04_delete_snapshot
> The method (is_snapshot_on_nfs) used to check whether snapshot exists on 
> secondary storage is wrong. Currently it's trying to match the name of 
> snapshot present on the storage with the UUID of snapshot. There's no 
> relation between the name of snapshot on storage and it's UUID or snapshot 
> ID. Hence it shoould only check if the snapshot is present in the directory 
> --> snapshots/account/volume/directory/ in SSVM

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

[jira] [Created] (CLOUDSTACK-4452) test_snapshots.py - The method used to check whether snapshot exists on secondary storage is wrong

Gaurav Aradhye created CLOUDSTACK-4452:
--

 Summary: test_snapshots.py - The method used to check whether 
snapshot exists on secondary storage is wrong
 Key: CLOUDSTACK-4452
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4452
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Snapshot
Affects Versions: 4.2.0
Reporter: Gaurav Aradhye
Assignee: Gaurav Aradhye
 Fix For: 4.2.0


Following test case failing due to this:
1. test_01_createVM_snapshotTemplate
2. test_02_snapshot_data_disk
3. test_04_delete_snapshot

The method (is_snapshot_on_nfs) used to check whether snapshot exists on 
secondary storage is wrong. Currently it's trying to match the name of snapshot 
present on the storage with the UUID of snapshot. There's no relation between 
the name of snapshot on storage and it's UUID or snapshot ID. Hence it shoould 
only check if the snapshot is present in the directory --> 
snapshots/account/volume/directory/ in SSVM

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

[jira] [Issue Comment Deleted] (CLOUDSTACK-4452) test_snapshots.py - The method used to check whether snapshot exists on secondary storage is wrong


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

Gaurav Aradhye updated CLOUDSTACK-4452:
---

Comment: was deleted

(was: Added patch:
//reviews.apache.org/r/13736/)

> test_snapshots.py - The method used to check whether snapshot exists on 
> secondary storage is wrong
> --
>
> Key: CLOUDSTACK-4452
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4452
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Snapshot
>Affects Versions: 4.2.0
>Reporter: Gaurav Aradhye
>Assignee: Gaurav Aradhye
> Fix For: 4.2.0
>
>
> Following test case failing due to this:
> 1. test_01_createVM_snapshotTemplate
> 2. test_02_snapshot_data_disk
> 3. test_04_delete_snapshot
> The method (is_snapshot_on_nfs) used to check whether snapshot exists on 
> secondary storage is wrong. Currently it's trying to match the name of 
> snapshot present on the storage with the UUID of snapshot. There's no 
> relation between the name of snapshot on storage and it's UUID or snapshot 
> ID. Hence it shoould only check if the snapshot is present in the directory 
> --> snapshots/account/volume/directory/ in SSVM

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

[jira] [Commented] (CLOUDSTACK-4452) test_snapshots.py - The method used to check whether snapshot exists on secondary storage is wrong


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

Gaurav Aradhye commented on CLOUDSTACK-4452:


Added patch:
//reviews.apache.org/r/13736/

> test_snapshots.py - The method used to check whether snapshot exists on 
> secondary storage is wrong
> --
>
> Key: CLOUDSTACK-4452
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4452
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Snapshot
>Affects Versions: 4.2.0
>Reporter: Gaurav Aradhye
>Assignee: Gaurav Aradhye
> Fix For: 4.2.0
>
>
> Following test case failing due to this:
> 1. test_01_createVM_snapshotTemplate
> 2. test_02_snapshot_data_disk
> 3. test_04_delete_snapshot
> The method (is_snapshot_on_nfs) used to check whether snapshot exists on 
> secondary storage is wrong. Currently it's trying to match the name of 
> snapshot present on the storage with the UUID of snapshot. There's no 
> relation between the name of snapshot on storage and it's UUID or snapshot 
> ID. Hence it shoould only check if the snapshot is present in the directory 
> --> snapshots/account/volume/directory/ in SSVM

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

[jira] [Comment Edited] (CLOUDSTACK-4452) test_snapshots.py - The method used to check whether snapshot exists on secondary storage is wrong


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

Gaurav Aradhye edited comment on CLOUDSTACK-4452 at 8/22/13 1:13 PM:
-

Added patch
https://reviews.apache.org/r/13736/

  was (Author: gauravaradhye):
Added patch
//reviews.apache.org/r/13736/
  
> test_snapshots.py - The method used to check whether snapshot exists on 
> secondary storage is wrong
> --
>
> Key: CLOUDSTACK-4452
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4452
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Snapshot
>Affects Versions: 4.2.0
>Reporter: Gaurav Aradhye
>Assignee: Gaurav Aradhye
> Fix For: 4.2.0
>
>
> Following test case failing due to this:
> 1. test_01_createVM_snapshotTemplate
> 2. test_02_snapshot_data_disk
> 3. test_04_delete_snapshot
> The method (is_snapshot_on_nfs) used to check whether snapshot exists on 
> secondary storage is wrong. Currently it's trying to match the name of 
> snapshot present on the storage with the UUID of snapshot. There's no 
> relation between the name of snapshot on storage and it's UUID or snapshot 
> ID. Hence it shoould only check if the snapshot is present in the directory 
> --> snapshots/account/volume/directory/ in SSVM

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

[jira] [Resolved] (CLOUDSTACK-4452) test_snapshots.py - The method used to check whether snapshot exists on secondary storage is wrong

2013-08-22 Thread ASF subversion and git services (JIRA)


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

Gaurav Aradhye resolved CLOUDSTACK-4452.


Resolution: Fixed

Added patch
//reviews.apache.org/r/13736/

> test_snapshots.py - The method used to check whether snapshot exists on 
> secondary storage is wrong
> --
>
> Key: CLOUDSTACK-4452
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4452
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Snapshot
>Affects Versions: 4.2.0
>Reporter: Gaurav Aradhye
>Assignee: Gaurav Aradhye
> Fix For: 4.2.0
>
>
> Following test case failing due to this:
> 1. test_01_createVM_snapshotTemplate
> 2. test_02_snapshot_data_disk
> 3. test_04_delete_snapshot
> The method (is_snapshot_on_nfs) used to check whether snapshot exists on 
> secondary storage is wrong. Currently it's trying to match the name of 
> snapshot present on the storage with the UUID of snapshot. There's no 
> relation between the name of snapshot on storage and it's UUID or snapshot 
> ID. Hence it shoould only check if the snapshot is present in the directory 
> --> snapshots/account/volume/directory/ in SSVM

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

[jira] [Commented] (CLOUDSTACK-4442) Source NAT not applied when network starts up


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

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

Commit a0f23d0f94a825d0370e79f5e81f9bdc52cb8b93 in branch 
refs/heads/4.2-forward from [~murali.reddy]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a0f23d0 ]

CLOUDSTACK-4442: Source NAT not applied when network starts up

ensure on network implement/restart/shutdown an ip assoc is sent so that
source nat ip is associated with source nat service provider.


> Source NAT not applied when network starts up
> -
>
> Key: CLOUDSTACK-4442
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4442
> 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
>Reporter: Dave Cahill
>Assignee: Murali Reddy
>Priority: Blocker
> Fix For: 4.2.0
>
>
> Create a network with Source NAT but no static NAT, and no firewall rules 
> applied.
> Observed behavior:
> Source NAT is not applied when the first VM is launched (when network is 
> implemented)
> Expected:
> Source NAT enabled at network implement time
> Network devices:
> Should affect all network devices; verified in 2 separate environments, one 
> with Virtual Router only, one MidoNet only
> Further information:
> This bug seems to be a result of this change:
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=server/src/com/cloud/network/NetworkManagerImpl.java;h=2b53565297dc7bd96c6102cdc1c90cb166e9e704;hp=dac6a3a42e75324a963997e17e076f4020a7103e;hb=fe568fe;hpb=c7f26583a26eb7e4f15feafc292ec9576df61a8d
> The above change was made as a fix for CLOUDSTACK-234.
> If the user enables Static NAT, Source NAT will be applied as a side effect.

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

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

2013-08-22 Thread Kishan Kavala (JIRA)


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

Kishan Kavala reopened CLOUDSTACK-4115:
---


Reopening to avoid workaround for upgrades from versions earlier than 3.0.5 and 
4.0

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

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

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

2013-08-22 Thread ASF subversion and git services (JIRA)


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

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

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

CLOUDSTACK-4115 : Encrypt password in cluster_details table. This fix is to 
handle upgrades from versions earlier than 3.0.5 and 4.0. Upgrade was not 
handled when the cluster_details password encryption was introduced.


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

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

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

2013-08-22 Thread ASF subversion and git services (JIRA)


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

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

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

CLOUDSTACK-4115 : Encrypt password in cluster_details table. This fix is to 
handle upgrades from versions earlier than 3.0.5 and 4.0. Upgrade was not 
handled when the cluster_details password encryption was introduced.


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

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

[jira] [Created] (CLOUDSTACK-4453) Routers test use VM credentials as host credentials

2013-08-22 Thread Prasanna Santhanam (JIRA)

Prasanna Santhanam created CLOUDSTACK-4453:
--

 Summary: Routers test use VM credentials as host credentials
 Key: CLOUDSTACK-4453
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4453
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Prasanna Santhanam
Priority: Critical


In test_routers.py (in smoke and component) we do the following,

result = get_process_status(
host.ipaddress,

self.services['virtual_machine']["publicport"],
self.vm_1.username,
self.vm_1.password,
router.linklocalip,
"service dnsmasq status"
)

In this case :

host.ipaddress is the IP address of the XenServer host.
self.services['virtual_machine']["publicport"] is 22 (SSH port)
self.vm_1.username / password are the username and password of the VM instance 
created for this test.

The call that fails in get_process_status is this:
ssh = remoteSSHClient(hostip, port, username, password)

In this case it seems the test is trying to create a SSH connection to the
XS host using the username / password of the VM instance (which will fail
because the XS host has a different password)



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

[jira] [Commented] (CLOUDSTACK-4453) Routers test use VM credentials as host credentials

2013-08-22 Thread ASF subversion and git services (JIRA)


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

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

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

CLOUDSTACK-4453: fetch host credentials from marvin config

Tests would fetch the credentials for the host to hop into router to
check for essential services. Each test would require to put in the host
information into the test data. Instead fetch the credential information
from the marvin configuration file.

Signed-off-by: Prasanna Santhanam 
(cherry picked from commit 4b546ce85d40098ade69c575316e76e25a422a12)


> Routers test use VM credentials as host credentials
> ---
>
> Key: CLOUDSTACK-4453
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4453
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Prasanna Santhanam
>Priority: Critical
>
> In test_routers.py (in smoke and component) we do the following,
> result = get_process_status(
> host.ipaddress,
> 
> self.services['virtual_machine']["publicport"],
> self.vm_1.username,
> self.vm_1.password,
> router.linklocalip,
> "service dnsmasq status"
> )
> In this case :
> host.ipaddress is the IP address of the XenServer host.
> self.services['virtual_machine']["publicport"] is 22 (SSH port)
> self.vm_1.username / password are the username and password of the VM 
> instance created for this test.
> The call that fails in get_process_status is this:
> ssh = remoteSSHClient(hostip, port, username, password)
> In this case it seems the test is trying to create a SSH connection to the
> XS host using the username / password of the VM instance (which will fail
> because the XS host has a different password)

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

[jira] [Commented] (CLOUDSTACK-4453) Routers test use VM credentials as host credentials

2013-08-22 Thread ASF subversion and git services (JIRA)


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

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

Commit 69f6f49ae1bb6655107245f8327f7fe1afa33f9f in branch 
refs/heads/4.2-forward from [~tsp]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=69f6f49 ]

CLOUDSTACK-4453: fetch host credentials from marvin config

Tests would fetch the credentials for the host to hop into router to
check for essential services. Each test would require to put in the host
information into the test data. Instead fetch the credential information
from the marvin configuration file.

Signed-off-by: Prasanna Santhanam 


> Routers test use VM credentials as host credentials
> ---
>
> Key: CLOUDSTACK-4453
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4453
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Prasanna Santhanam
>Priority: Critical
>
> In test_routers.py (in smoke and component) we do the following,
> result = get_process_status(
> host.ipaddress,
> 
> self.services['virtual_machine']["publicport"],
> self.vm_1.username,
> self.vm_1.password,
> router.linklocalip,
> "service dnsmasq status"
> )
> In this case :
> host.ipaddress is the IP address of the XenServer host.
> self.services['virtual_machine']["publicport"] is 22 (SSH port)
> self.vm_1.username / password are the username and password of the VM 
> instance created for this test.
> The call that fails in get_process_status is this:
> ssh = remoteSSHClient(hostip, port, username, password)
> In this case it seems the test is trying to create a SSH connection to the
> XS host using the username / password of the VM instance (which will fail
> because the XS host has a different password)

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

[jira] [Commented] (CLOUDSTACK-4442) Source NAT not applied when network starts up

2013-08-22 Thread ASF subversion and git services (JIRA)


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

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

Commit 255c8473db7da27014a8e35d06ad133d1ce71d1f in branch 
refs/heads/4.2-forward from [~murali.reddy]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=255c847 ]

CLOUDSTACK-4442: Source NAT not applied when network starts up

fixing the buid break introduced with prev commit for this bug


> Source NAT not applied when network starts up
> -
>
> Key: CLOUDSTACK-4442
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4442
> 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
>Reporter: Dave Cahill
>Assignee: Murali Reddy
>Priority: Blocker
> Fix For: 4.2.0
>
>
> Create a network with Source NAT but no static NAT, and no firewall rules 
> applied.
> Observed behavior:
> Source NAT is not applied when the first VM is launched (when network is 
> implemented)
> Expected:
> Source NAT enabled at network implement time
> Network devices:
> Should affect all network devices; verified in 2 separate environments, one 
> with Virtual Router only, one MidoNet only
> Further information:
> This bug seems to be a result of this change:
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=server/src/com/cloud/network/NetworkManagerImpl.java;h=2b53565297dc7bd96c6102cdc1c90cb166e9e704;hp=dac6a3a42e75324a963997e17e076f4020a7103e;hb=fe568fe;hpb=c7f26583a26eb7e4f15feafc292ec9576df61a8d
> The above change was made as a fix for CLOUDSTACK-234.
> If the user enables Static NAT, Source NAT will be applied as a side effect.

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

[jira] [Assigned] (CLOUDSTACK-3424) IPV6 - When a Vm is expunged and a new Vm is deployed with the same name , /etc/dhchosts.txt has 2 entries with the same name.

2013-08-22 Thread Sheng Yang (JIRA)


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

Sheng Yang reassigned CLOUDSTACK-3424:
--

Assignee: Sheng Yang

> IPV6 - When a Vm is expunged and a new Vm is deployed with the same name , 
> /etc/dhchosts.txt has 2 entries with the same name.
> --
>
> Key: CLOUDSTACK-3424
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3424
> 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: Build from master-6-17-stable
>Reporter: Sangeetha Hariharan
>Assignee: Sheng Yang
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.log
>
>
> IPV6 - When a Vm is expunged and a new Vm is deployed with the same name , 
> /etc/dhchosts.txt has 2 entries with the same name
> Steps to reproduce the problem:
> Create a ipv6 network.
> Deploy a Vm with name - test456.
> Destroy this VM. Wait for it to be expunged.
> Deploy another Vm with same name - test456.
> We see that there are 2 entries in the router with the same name "test456" 
> resolving to 2 different ipv6 addresses.
> root@r-17-VM:~# cat /etc/dhcphosts.txt
> id:00:03:00:01:06:4e:de:00:00:2f,[fc00:3:1370::744f],test123,infinite
> id:00:03:00:01:06:75:46:00:00:31,[fc00:3:1370::34ed],test456,infinite
> id:00:03:00:01:06:e4:ae:00:00:32,[fc00:3:1370::ae4b],testyoyo,infinite
> id:00:03:00:01:06:96:aa:00:00:33,[fc00:3:1370::34ed],testyoyo1,infinite
> id:00:03:00:01:06:cb:88:00:00:34,[fc00:3:1370::6eb2],test456,infinite
> root@r-17-VM:~#
> Attaching management server logs:
> Have 2 entries for the same name is a problem.
> Is it also a problem to have the same ipv6 address associated with 2 
> different vms with different Vm names ( 1 expunged and 1 active , in my case 
> "test456" which is expunged and "testyoyo1" which is active) ?

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

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

2013-08-22 Thread Ram Ganesh (JIRA)


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

Ram Ganesh commented on CLOUDSTACK-4115:


See commits to this bug. Should this bug be resolved now?

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

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

[jira] [Updated] (CLOUDSTACK-4430) [Automation][vmware] Failed to deploy vm, if one host is down in a cluster

2013-08-22 Thread Sudha Ponnaganti (JIRA)


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

Sudha Ponnaganti updated CLOUDSTACK-4430:
-

Assignee: Kelven Yang

> [Automation][vmware] Failed to deploy vm, if one host is down in a cluster
> --
>
> Key: CLOUDSTACK-4430
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4430
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Management Server, VMware
>Affects Versions: 4.2.0
> Environment: Automation
> vmware
>Reporter: Rayees Namathponnan
>Assignee: Kelven Yang
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: management-server.log.2013-08-20.gz, 
> management-server.rar
>
>
> This issue observed during automation run
> 1) Automation running with 2 zones (advanced ), both zone contions one 
> cluster;  first cluster  having 2 hosts (10.223.250.130 and 10.223.250.131) 
> and another cluster have 1  host.
> 2) Create vm one first zone;  
> 3) make one host (10.223.250.130) down from first zone 
> 4) deploy an another vm after the first zone is down
> Expected Behavior
> ---
> New vm should be deployed with first zone, on the second host (10.223.250.131)
> Actual Result 
> 
> VM deployment failed with below error
> 2013-08-21 15:49:49,125 DEBUG [cloud.storage.VolumeManagerImpl] 
> (Job-Executor-29:job-1549 = [ cf900a2a-6c83-4ddd-b898-e19c90cef0a6 ]) 
> Checking if we need to prepare 1 volumes for VM[DomainRouter|r-524-TestVM]
> 2013-08-21 15:49:49,131 DEBUG [storage.image.TemplateDataFactoryImpl] 
> (Job-Executor-29:job-1549 = [ cf900a2a-6c83-4ddd-b898-e19c90cef0a6 ]) 
> template 8 is already in store:2, type:Image
> 2013-08-21 15:49:49,155 DEBUG [storage.image.TemplateDataFactoryImpl] 
> (Job-Executor-29:job-1549 = [ cf900a2a-6c83-4ddd-b898-e19c90cef0a6 ]) 
> template 8 is already in store:1, type:Primary
> 2013-08-21 15:49:49,224 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-29:job-1549 = [ cf900a2a-6c83-4ddd-b898-e19c90cef0a6 ]) 
> copyAsync inspecting src type TEMPLATE copyAsync inspecting dest type VOLUME
> 2013-08-21 15:49:49,232 DEBUG [agent.transport.Request] 
> (Job-Executor-29:job-1549 = [ cf900a2a-6c83-4ddd-b898-e19c90cef0a6 ]) Seq 
> 3-1188243408: Sending  { Cmd , MgmtId: 90928106758026, via: 3, Ver: v1, 
> Flags: 100011, [{"org.apac
> he.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"d559e79dc94f3ceea16e841774053435","origUrl":"http://download.cloud.com/templates/4.2/systemvmtemplate-4.2-vh7.ova";
> ,"uuid":"426a759e-09ec-11e3-a733-52b2d980df8a","id":8,"format":"OVA","accountId":1,"checksum":"8fde62b1089e5844a9cd3b9b953f9596","hvm":false,"displayText":"SystemVM
>  Template (vSphere)","imageDataStore":{"org.apache.cloudstack.st
> orage.to.PrimaryDataStoreTO":{"uuid":"4faf04c2-6dd8-3025-b43f-65d32cc49d02","id":1,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/automation/SC-CLOUD-QA03/primary1","port":2049}},"name":"routing-8","
> hypervisorType":"VMware"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"3c7b36c7-a034-485b-b808-501e6b8a067a","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid"
> :"4faf04c2-6dd8-3025-b43f-65d32cc49d02","id":1,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/automation/SC-CLOUD-QA03/primary1","port":2049}},"name":"ROOT-524","size":2097152000,"volumeId":575,"vmNa
> me":"r-524-TestVM","accountId":2,"format":"OVA","id":575,"hypervisorType":"None"}},"executeInSequence":false,"wait":0}}]
>  }
> 2013-08-21 15:49:49,232 DEBUG [agent.transport.Request] 
> (Job-Executor-29:job-1549 = [ cf900a2a-6c83-4ddd-b898-e19c90cef0a6 ]) Seq 
> 3-1188243408: Executing:  { Cmd , MgmtId: 90928106758026, via: 3, Ver: v1, 
> Flags: 100011, [{"org.a
> pache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"d559e79dc94f3ceea16e841774053435","origUrl":"http://download.cloud.com/templates/4.2/systemvmtemplate-4.2-vh7.o
> va","uuid":"426a759e-09ec-11e3-a733-52b2d980df8a","id":8,"format":"OVA","accountId":1,"checksum":"8fde62b1089e5844a9cd3b9b953f9596","hvm":false,"displayText":"SystemVM
>  Template (vSphere)","imageDataStore":{"org.apache.cloudstack
> .storage.to.PrimaryDataStoreTO":{"uuid":"4faf04c2-6dd8-3025-b43f-65d32cc49d02","id":1,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/automation/SC-CLOUD-QA03/primary1","port":2049}},"name":"routing-8
> ","hypervisorType":"VMware"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeO

[jira] [Commented] (CLOUDSTACK-4428) "kvm.snapshot.enabled" flag should be taken to account only when snapshot is being created for Running vm

2013-08-22 Thread Sudha Ponnaganti (JIRA)


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

Sudha Ponnaganti commented on CLOUDSTACK-4428:
--

Testing will be done on 4.2.1

> "kvm.snapshot.enabled" flag should be taken to account only when snapshot is 
> being created for Running vm
> -
>
> Key: CLOUDSTACK-4428
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4428
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.2.0
>Reporter: Alena Prokharchyk
>Assignee: angeline shen
>Priority: Critical
> Fix For: 4.2.1
>
>
> We used to have a problem for KVM snapshot creation when createSnapshot is 
> called for the volume of the Running vm. As a fix for that, 
> kvm.snapshot.enabled flag was introduced. But when this flag set to fase, it 
> doesn't allow snapshot creation even for detached volumes (the area where the 
> problem didn't even exist).
> Suggested fix: kvm.snapshot.enabled should affect only case when the snapshot 
> is being created for the volume a) that is attached to the vm b) the vm is 
> running/starting/stopping states only

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

[jira] [Updated] (CLOUDSTACK-4428) "kvm.snapshot.enabled" flag should be taken to account only when snapshot is being created for Running vm

2013-08-22 Thread Sudha Ponnaganti (JIRA)


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

Sudha Ponnaganti updated CLOUDSTACK-4428:
-

Assignee: angeline shen  (was: Alena Prokharchyk)

> "kvm.snapshot.enabled" flag should be taken to account only when snapshot is 
> being created for Running vm
> -
>
> Key: CLOUDSTACK-4428
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4428
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.2.0
>Reporter: Alena Prokharchyk
>Assignee: angeline shen
>Priority: Critical
> Fix For: 4.2.1
>
>
> We used to have a problem for KVM snapshot creation when createSnapshot is 
> called for the volume of the Running vm. As a fix for that, 
> kvm.snapshot.enabled flag was introduced. But when this flag set to fase, it 
> doesn't allow snapshot creation even for detached volumes (the area where the 
> problem didn't even exist).
> Suggested fix: kvm.snapshot.enabled should affect only case when the snapshot 
> is being created for the volume a) that is attached to the vm b) the vm is 
> running/starting/stopping states only

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

[jira] [Updated] (CLOUDSTACK-4239) [vmware]Snapshot creation on ESX 4.1 host fails with "BackupSnapshotCommand exception: javax.xml.ws.soap.SOAPFaultException"


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

Animesh Chaturvedi updated CLOUDSTACK-4239:
---

Fix Version/s: (was: 4.2.0)
   4.2.1

Tagging for 4.2.1

> [vmware]Snapshot creation on ESX 4.1 host fails with "BackupSnapshotCommand 
> exception: javax.xml.ws.soap.SOAPFaultException"
> 
>
> Key: CLOUDSTACK-4239
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4239
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Snapshot, VMware
>Affects Versions: 4.2.0
> Environment: Host : Esx 4.1
> MS : Rhel 6.3
> Fresh install 4.2
>Reporter: Abhinav Roy
>Assignee: Kelven Yang
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: CS-4239.zip, ssvm-logs.zip
>
>
> Steps :
> =
> 1. Deploy CS 4.2 advanced zone setup with ESX 4.1 host.
> 2. Deploy VMs and try to create snapshots.
> Expected behaviour :
> =
> The snapshot creation should be successful
> Observed behaviour :
> =
> Snapshot creation fails with 
> 2013-08-12 00:09:19,309 DEBUG [storage.snapshot.SnapshotManagerImpl] 
> (Job-Executor-9:job-26 = [ 253f12b5-6217-4928-9f14-3c4a8007f5f9 ]) Failed to 
> create snapshot
> com.cloud.utils.exception.CloudRuntimeException: BackupSnapshotCommand 
> exception: javax.xml.ws.soap.SOAPFaultException
> at 
> org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:286)
> at 
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:137)
> at 
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:256)
> at 
> com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:1004)
> at 
> org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1256)
> at 
> com.cloud.storage.VolumeManagerImpl.takeSnapshot(VolumeManagerImpl.java:2674)
> at 
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd.execute(CreateSnapshotCmd.java:170)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at 
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:679)
> 2013-08-12 00:09:19,318 DEBUG [storage.volume.VolumeServiceImpl] 
> (Job-Executor-9:job-26 = [ 253f12b5-6217-4928-9f14-3c4a8007f5f9 ]) Take 
> snapshot: 20 failed: com.cloud.utils.exception.CloudRuntimeException: Failed 
> to create snapshot
> 2013-08-12 00:09:19,324 DEBUG [cloud.async.AsyncJobManagerImpl] 
> (Job-Executor-9:job-26 = [ 253f12b5-6217-4928-9f14-3c4a8007f5f9 ]) Complete 
> async job-26 = [ 253f12b5-6217-4928-9f14-3c4a8007f5f9 ], jobStatus: 2, 
> resultCode: 530, result: Error Code: 530 Error text: Failed to create 
> snapshot due to an internal error creating snapshot for volume 20

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

[jira] [Updated] (CLOUDSTACK-4358) [Automation] [vmware] Few VM deployment failed with IndexOutOfBoundsException at "VolumeManagerImpl.java:2534"


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

Animesh Chaturvedi updated CLOUDSTACK-4358:
---

Fix Version/s: (was: 4.2.0)
   4.2.1

Tagging for 4.2.1

> [Automation] [vmware] Few VM deployment failed with IndexOutOfBoundsException 
> at "VolumeManagerImpl.java:2534"
> --
>
> Key: CLOUDSTACK-4358
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4358
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, VMware
>Affects Versions: 4.2.0
>Reporter: Rayees Namathponnan
>Assignee: Kelven Yang
>Priority: Blocker
> Fix For: 4.2.1
>
> Attachments: CLOUDSTACK-4358_Log2.rar, CLOUDSTACK-4358.rar, 
> management-server.log.2013-08-19.gz
>
>
> This issue observed while executing test case  
> integration.component.test_stopped_vm.TestDeployVMFromTemplate.test_deploy_vm_password_enabled
> VM deployment failed with below error in MS
> 2013-08-15 06:25:04,040 DEBUG [storage.volume.VolumeServiceImpl] 
> (Job-Executor-151:job-1405 = [ 0c22bfca-fc58-42a0-a5eb-23def296accf ]) 
> Acquire lock on VMTemplateStoragePool 11 with timeout 3600 seconds
> 2013-08-15 06:25:04,041 INFO  [storage.volume.VolumeServiceImpl] 
> (Job-Executor-151:job-1405 = [ 0c22bfca-fc58-42a0-a5eb-23def296accf ]) lock 
> is acquired for VMTemplateStoragePool 11
> 2013-08-15 06:25:04,051 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-151:job-1405 = [ 0c22bfca-fc58-42a0-a5eb-23def296accf ]) 
> copyAsync inspecting src type TEMPLATE copyAsync inspecting dest type TEMPLATE
> 2013-08-15 06:25:04,065 DEBUG [agent.transport.Request] 
> (Job-Executor-151:job-1405 = [ 0c22bfca-fc58-42a0-a5eb-23def296accf ]) Seq 
> 9-1658651433: Sending  { Cmd , MgmtId: 90928106758026, via: 9, Ver: v1, 
> Flags: 100011, [{"org.apache.cloud
> stack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/282/230/3e85ab63-d22b-33b3-9e5e-e246b7413fff.ova","origUrl":"http://nfs1.lab.vmops.com/templates/ubuntu/ubuntu-12.04.
> 1-desktop-i386-nest-13.02.04.ova","uuid":"74cf2a78-5935-4c31-baca-d237f4fcf974","id":230,"format":"OVA","accountId":282,"checksum":"63d4a4350424504f416fcd989b6ef1b2","hvm":true,"displayText":"Cent
>  OS Template","imageDataStore":{"com.clou
> d.agent.api.to.NfsTO":{"_url":"nfs://10.223.110.232:/export/home/automation/SC-CLOUD-QA03/secondary1","_role":"Image"}},"name":"230-282-0c4f6793-b7ab-334a-9a13-41f5580cdf90","hypervisorType":"VMware"}},"destTO":{"org.apache.cloudstack.st
> orage.to.TemplateObjectTO":{"origUrl":"http://nfs1.lab.vmops.com/templates/ubuntu/ubuntu-12.04.1-desktop-i386-nest-13.02.04.ova","uuid":"74cf2a78-5935-4c31-baca-d237f4fcf974","id":230,"format":"OVA","accountId":282,"checksum":"63d4a43504
> 24504f416fcd989b6ef1b2","hvm":true,"displayText":"Cent OS 
> Template","imageDataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"4faf04c2-6dd8-3025-b43f-65d32cc49d02","id":1,"poolType":"NetworkFilesystem","host":"10.2
> 23.110.232","path":"/export/home/automation/SC-CLOUD-QA03/primary1","port":2049}},"name":"230-282-0c4f6793-b7ab-334a-9a13-41f5580cdf90","hypervisorType":"VMware"}},"executeInSequence":false,"wait":10800}}]
>  }
> 2013-08-15 06:25:04,099 DEBUG [agent.transport.Request] 
> (AgentManager-Handler-3:null) Seq 9-1658651433: Processing:  { Ans: , MgmtId: 
> 90928106758026, via: 9, Ver: v1, Flags: 10, 
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"r
> esult":false,"details":"Unable to copy template to primary storage due to 
> exception:Exception: java.lang.IndexOutOfBoundsException\nMessage: Index: 0, 
> Size: 0\n","wait":0}}] }
> 2013-08-15 06:25:04,100 DEBUG [agent.transport.Request] 
> (Job-Executor-151:job-1405 = [ 0c22bfca-fc58-42a0-a5eb-23def296accf ]) Seq 
> 9-1658651433: Received:  { Ans: , MgmtId: 90928106758026, via: 9, Ver: v1, 
> Flags: 10, { CopyCmdAnswer } }
> 2013-08-15 06:25:04,108 INFO  [storage.volume.VolumeServiceImpl] 
> (Job-Executor-151:job-1405 = [ 0c22bfca-fc58-42a0-a5eb-23def296accf ]) 
> releasing lock for VMTemplateStoragePool 11
> 2013-08-15 06:25:04,108 WARN  [utils.db.Merovingian2] 
> (Job-Executor-151:job-1405 = [ 0c22bfca-fc58-42a0-a5eb-23def296accf ]) Was 
> unable to find lock for the key template_spool_ref11 and thread id 557745274
> 2013-08-15 06:25:04,108 DEBUG [cloud.storage.VolumeManagerImpl] 
> (Job-Executor-151:job-1405 = [ 0c22bfca-fc58-42a0-a5eb-23def296accf ]) Unable 
> to create Vol[442|vm=388|ROOT]:Unable to copy template to primary storage due 
> to exception:Exce
> ption: java.lang.IndexOutOfBoundsExc

[jira] [Updated] (CLOUDSTACK-4443) [VMWARE]Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after upgrade


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

Animesh Chaturvedi updated CLOUDSTACK-4443:
---


Tagging for 4.2.1

> [VMWARE]Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after 
> upgrade 
> ---
>
> Key: CLOUDSTACK-4443
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4443
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Upgrade, VMware
>Affects Versions: 4.2.1
>Reporter: Sailaja Mada
>Assignee: Sateesh Chodapuneedi
>Priority: Blocker
> Fix For: 4.2.1
>
> Attachments: deployvmlogs.rar
>
>
> Steps:
> With 307,
> 1. Configure Adv Zone using Standard vSwitch with VMWARE cluster (Single 
> Physical Network and all the traffics - Mgmt,guest,public) on this default 
> network ( vSwitch0) 
> 2. Upgraded from 307 to 4.2 
> 3. Tried to depoy new VM on this zone which was created in 307. 
> Observation:
> Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after upgrade 
> 2013-08-22 12:22:09,336 DEBUG [vmware.resource.VmwareResource] 
> (DirectAgent-50:10.102.192.20) Prepare volume at new device 
> {"capacityInKB":0,"key":-2,"backing":{"diskMode":"persistent","fileName":"[3adda133ecae3cd894716de45b81a560]
>  
> i-4-32-VM/ROOT-32.vmdk","datastore":{"value":"datastore-11157","type":"Datastore"}},"connectable":{"startConnected":true,"allowGuestControl":false,"connected":true},"controllerKey":200,"unitNumber":1}
> 2013-08-22 12:22:09,337 INFO  [vmware.resource.VmwareResource] 
> (DirectAgent-50:10.102.192.20) Prepare NIC device based on NicTO: 
> {"deviceId":0,"networkRateMbps":200,"defaultNic":true,"uuid":"057f0e6e-7ca5-4715-9551-c827f9f61ea8","ip":"10.1.1.74","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:28:84:00:04","dns1":"10.103.128.15","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://782","isolationUri":"vlan://782","isSecurityGroupEnabled":false}
> 2013-08-22 12:22:09,348 INFO  [vmware.resource.VmwareResource] 
> (DirectAgent-50:10.102.192.20) Prepare network on vmwaresvs P[epp0:untagged] 
> with name prefix: cloud.guest
> 2013-08-22 12:22:09,427 ERROR [vmware.mo.HypervisorHostHelper] 
> (DirectAgent-50:10.102.192.20) Unable to find vSwitchepp0
> 2013-08-22 12:22:09,444 WARN  [vmware.resource.VmwareResource] 
> (DirectAgent-50:10.102.192.20) StartCommand failed due to Exception: 
> java.lang.Exception
> Message: Unable to find vSwitchepp0
> java.lang.Exception: Unable to find vSwitchepp0
> at 
> com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:904)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:3292)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2904)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:514)
> 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-08-22 12:22:09,467 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-50:null) Seq 7-1913981379: Response Received:
> 2013-08-22 12:22:09,470 DEBUG [agent.transport.Request] (DirectAgent-50:null) 
> Seq 7-1913981379: Processing:  { Ans: , MgmtId: 187767034175903, via: 7, Ver: 
> v1, Flags: 10, 
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":32,"name":"i-4-32-VM","bootloader":"HVM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,"maxRam":536870912,"hostName":"newinstance1","arch":"x86_64","os":"CentOS
>  5.3 
> (64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"85cf3117ab67ecba","params":{"rootDiskController":"ide","nicAdapter":"E1000","nestedVirtualizationFlag":"false"},"uuid":"8157294c-b9c6-4589-9727-dffdcf64a8f7","disks":[{"data":{"org.apache.cloudstack.storage.to.Volu

[jira] [Updated] (CLOUDSTACK-3237) [vmware][SM] Migrate volume is failing when there are snapshots for that volume


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

Animesh Chaturvedi updated CLOUDSTACK-3237:
---

Fix Version/s: (was: 4.2.0)
   4.2.1

Tagging for 4.2.1

> [vmware][SM] Migrate volume is failing when there are snapshots for that 
> volume
> ---
>
> Key: CLOUDSTACK-3237
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3237
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.2.0
> Environment: vmware, 
>Reporter: Srikanteswararao Talluri
>Assignee: Kelven Yang
>Priority: Blocker
> Fix For: 4.2.1
>
> Attachments: mgmt_27.log.zip
>
>
> Steps to reproduce:
> 1. create a VM 
> 2. take snapshot of root volume of VM
> 3. migrate root volume to a suitable storage pool
> ===START===  10.101.255.87 -- GET  
> command=findStoragePoolsForMigration&id=f7c12988-61a8-49dc-a5d3-cd8653744a8e&response=json&sessionkey=dfd5NAw2qEmBOi3931kcin3eZtQ%3D&_=1372333879848
> 2013-06-27 22:46:36,408 DEBUG [storage.allocator.LocalStoragePoolAllocator] 
> (catalina-exec-14:null) LocalStoragePoolAllocator trying to find storage pool 
> to fit the vm
> 2013-06-27 22:46:36,410 DEBUG 
> [storage.allocator.ClusterScopeStoragePoolAllocator] (catalina-exec-14:null) 
> ClusterScopeStoragePoolAllocator looking for storage pool
> 2013-06-27 22:46:36,410 DEBUG 
> [storage.allocator.ClusterScopeStoragePoolAllocator] (catalina-exec-14:null) 
> Looking for pools in dc: 1  pod:1  cluster:1
> 2013-06-27 22:46:36,419 DEBUG 
> [storage.allocator.AbstractStoragePoolAllocator] (catalina-exec-14:null) 
> Checking if storage pool is suitable, name: null ,poolId: 1
> 2013-06-27 22:46:36,419 DEBUG 
> [storage.allocator.AbstractStoragePoolAllocator] (catalina-exec-14:null) 
> StoragePool is in avoid set, skipping this pool
> 2013-06-27 22:46:36,421 DEBUG 
> [storage.allocator.AbstractStoragePoolAllocator] (catalina-exec-14:null) 
> Checking if storage pool is suitable, name: null ,poolId: 3
> 2013-06-27 22:46:36,429 DEBUG [cloud.storage.StorageManagerImpl] 
> (catalina-exec-14:null) Checking pool 3 for storage, totalSize: 
> 590228480, usedBytes: 3490243883008, usedPct: 0.5913377617779474, disable 
> threshold: 0.85
> 2013-06-27 22:46:36,461 DEBUG [cloud.storage.StorageManagerImpl] 
> (catalina-exec-14:null) Checking pool: 3 for volume allocation 
> [Vol[4|vm=4|ROOT]], maxSize : 1180456960, totalAllocatedSize : 
> 23622320128, askingSize : 0, allocated disable threshold: 0.85
> 2013-06-27 22:46:36,464 DEBUG 
> [storage.allocator.AbstractStoragePoolAllocator] (catalina-exec-14:null) 
> Checking if storage pool is suitable, name: null ,poolId: 5
> 2013-06-27 22:46:36,471 DEBUG [cloud.storage.StorageManagerImpl] 
> (catalina-exec-14:null) Checking pool 5 for storage, totalSize: 
> 590228480, usedBytes: 3490243883008, usedPct: 0.5913377617779474, disable 
> threshold: 0.85
> 2013-06-27 22:46:36,492 DEBUG [cloud.storage.StorageManagerImpl] 
> (catalina-exec-14:null) Checking pool: 5 for volume allocation 
> [Vol[4|vm=4|ROOT]], maxSize : 1180456960, totalAllocatedSize : 
> 35433480192, askingSize : 0, allocated disable threshold: 0.85
> 2013-06-27 22:46:36,492 DEBUG 
> [storage.allocator.ClusterScopeStoragePoolAllocator] (catalina-exec-14:null) 
> FirstFitStoragePoolAllocator returning 2 suitable storage pools
> 2013-06-27 22:46:36,506 DEBUG [cloud.api.ApiServlet] (catalina-exec-14:null) 
> ===END===  10.101.255.87 -- GET  
> command=findStoragePoolsForMigration&id=f7c12988-61a8-49dc-a5d3-cd8653744a8e&response=json&sessionkey=dfd5NAw2qEmBOi3931kcin3eZtQ%3D&_=1372333879848
> 2013-06-27 22:46:39,967 DEBUG [agent.manager.AgentManagerImpl] 
> (AgentManager-Handler-9:null) Ping from 4
> 2013-06-27 22:46:40,804 DEBUG [agent.manager.AgentManagerImpl] 
> (AgentManager-Handler-11:null) SeqA 3-10940: Processing Seq 3-10940:  { Cmd , 
> MgmtId: -1, via: 3, Ver: v1, Flags: 11, 
> [{"ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n  
> \"connections\": []\n}","wait":0}}] }
> 2013-06-27 22:46:40,813 DEBUG [agent.manager.AgentManagerImpl] 
> (AgentManager-Handler-11:null) SeqA 3-10940: Sending Seq 3-10940:  { Ans: , 
> MgmtId: 7566222426160, via: 3, Ver: v1, Flags: 100010, 
> [{"AgentControlAnswer":{"result":true,"wait":0}}] }
> 2013-06-27 22:46:41,091 DEBUG [cloud.api.ApiServlet] (catalina-exec-18:null) 
> ===START===  10.101.255.87 -- GET  
> command=migrateVolume&livemigrate=true&storageid=e690ef30-851c-33b0-a1b3-38fd7fa4c40c&volumeid=f7c12988-61a8-49dc-a5d3-cd8653744a8e&response=json&sessionkey=dfd5NAw2qEmBOi3931kcin3eZtQ%3D&_=1372333884566
> 2013-06-27 22:46:41,1

[jira] [Updated] (CLOUDSTACK-4435) [VMWARE]System VM's are failed to start with Nexus enabled Zone


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

Animesh Chaturvedi updated CLOUDSTACK-4435:
---


Tagging for 4.2.1

> [VMWARE]System VM's are failed to start with Nexus enabled Zone 
> 
>
> Key: CLOUDSTACK-4435
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4435
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Devices, VMware
>Affects Versions: 4.2.1
>Reporter: Sailaja Mada
>Assignee: Sateesh Chodapuneedi
>Priority: Blocker
> Fix For: 4.2.1
>
> Attachments: issuenexus.rar
>
>
> Steps:
> 1. Upgraded from 3.0.7 to 4.2 ( VMWARE Zone with Standard vSwitch)
> 2. Enable Nexus global config variable
> 3. Tried to add new Zone with VMWARE Nexus enabled
> 4. Added two physical networks ( 1 - Mgmt - vSwitch0,,vmwaresvs 2- Public & 
> guest -> sailajanewpp,,nexusdvs)
> 5. Provided VSM details while adding cluster
> Observation:
> System VM's are failed to start with Nexus enabled Zone saying Nexus details 
> can not be retrieved from DB. 
> 2013-08-22 00:37:01,732 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null) 
> ===START===  10.101.255.30 -- GET  
> command=queryAsyncJobResult&jobId=921f4c19-a655-4234-82c4-66efcbe73933&response=json&sessionkey=CNY1grUrySJwTE%2BpFM3btn1i4Xs%3D&_=1377112271133
> 2013-08-22 00:37:01,782 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null) 
> ===END===  10.101.255.30 -- GET  
> command=queryAsyncJobResult&jobId=921f4c19-a655-4234-82c4-66efcbe73933&response=json&sessionkey=CNY1grUrySJwTE%2BpFM3btn1i4Xs%3D&_=1377112271133
> 2013-08-22 00:37:02,170 WARN  [vmware.resource.VmwareResource] 
> (DirectAgent-128:10.102.192.18) StartCommand failed due to Exception: 
> java.lang.Exception
> Message: Failed to retrieve required credentials of Nexus VSM from database.
> java.lang.Exception: Failed to retrieve required credentials of Nexus VSM 
> from database.
> at 
> com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.getValidatedVsmCredentials(HypervisorHostHelper.java:183)
> at 
> com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.createPortProfile(HypervisorHostHelper.java:201)
> at 
> com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:584)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:3308)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2904)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:514)
> 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-08-22 00:37:02,196 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-128:null) Seq 14-773455885: Cancelling because one of the 
> answers is false and it is stop on error.
> 2013-08-22 00:37:02,196 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-128:null) Seq 14-773455885: Response Received:
> 2013-08-22 00:37:02,199 DEBUG [agent.transport.Request] 
> (DirectAgent-128:null) Seq 14-773455885: Processing:  { Ans: , MgmtId: 
> 187767034175903, via: 14, Ver: v1, Flags: 10, 
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":30,"name":"s-30-VM","bootloader":"HVM","type":"SecondaryStorageVm","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":268435456,"maxRam":268435456,"hostName":"s-30-VM","arch":"x86_64","os":"Debian
>  GNU/Linux 5.0 (32-bit)","bootArgs":" template=domP type=secstorage 
> host=10.102.192.207 port=8250 name=s-30-VM zone=3 pod=3 guid=s-30-VM 
> resource=com.cloud.storage.resource.PremiumSecondaryStorageResource 
> instance=SecStorage sslcopy=true role=templateProcessor mtu=1500 
> eth2ip=10.102.196.220 eth2mask=255.255.255.0 gateway=10.102.196.1 
> public.network.device=eth2 eth0mask=0.0.0.0 eth0ip=0.0.0.0 
> eth1ip=10.102.195.150 eth1mask=255.255.252.0 mgmtcidr=10.102.192.0/22 
> localg

[jira] [Updated] (CLOUDSTACK-4432) [VMWare] NPE thrown during VM Deployment


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

Animesh Chaturvedi updated CLOUDSTACK-4432:
---


Tagging for 4.2.1

> [VMWare] NPE thrown during VM Deployment
> 
>
> Key: CLOUDSTACK-4432
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4432
> 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: Chandan Purushothama
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: management-server.zip
>
>
> ===
> Observation:
> ===
> 2013-08-21 17:09:32,344 DEBUG [allocator.impl.FirstFitAllocator] 
> (Job-Executor-49:job-66 = [ 50b09c49-f155-4b59-b6a3-9c77394fe172 ] 
> FirstFitRoutingAllocator) Found a suitable host, adding to list: 10
> 2013-08-21 17:09:32,345 DEBUG [allocator.impl.FirstFitAllocator] 
> (Job-Executor-49:job-66 = [ 50b09c49-f155-4b59-b6a3-9c77394fe172 ] 
> FirstFitRoutingAllocator) Host Allocator returning 1 suitable hosts
> 2013-08-21 17:09:32,346 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] 
> (Job-Executor-49:job-66 = [ 50b09c49-f155-4b59-b6a3-9c77394fe172 ]) Checking 
> suitable pools for volume (Id, Type): (18,ROOT)
> 2013-08-21 17:09:32,346 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] 
> (Job-Executor-49:job-66 = [ 50b09c49-f155-4b59-b6a3-9c77394fe172 ]) We need 
> to allocate new storagepool for this volume
> 2013-08-21 17:09:32,347 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] 
> (Job-Executor-49:job-66 = [ 50b09c49-f155-4b59-b6a3-9c77394fe172 ]) Calling 
> StoragePoolAllocators to find suitable pools
> 2013-08-21 17:09:32,349 DEBUG [storage.allocator.LocalStoragePoolAllocator] 
> (Job-Executor-49:job-66 = [ 50b09c49-f155-4b59-b6a3-9c77394fe172 ]) 
> LocalStoragePoolAllocator trying to find storage pool to fit the vm
> 2013-08-21 17:09:32,349 DEBUG 
> [storage.allocator.ClusterScopeStoragePoolAllocator] (Job-Executor-49:job-66 
> = [ 50b09c49-f155-4b59-b6a3-9c77394fe172 ]) ClusterScopeStoragePoolAllocator 
> looking for storage pool
> 2013-08-21 17:09:32,349 DEBUG 
> [storage.allocator.ClusterScopeStoragePoolAllocator] (Job-Executor-49:job-66 
> = [ 50b09c49-f155-4b59-b6a3-9c77394fe172 ]) Looking for pools in dc: 1  pod:1 
>  cluster:6
> 2013-08-21 17:09:32,350 DEBUG 
> [storage.allocator.ClusterScopeStoragePoolAllocator] (Job-Executor-49:job-66 
> = [ 50b09c49-f155-4b59-b6a3-9c77394fe172 ]) No storage pools available for 
> shared volume allocation, returning
> 2013-08-21 17:09:32,350 DEBUG 
> [storage.allocator.ZoneWideStoragePoolAllocator] (Job-Executor-49:job-66 = [ 
> 50b09c49-f155-4b59-b6a3-9c77394fe172 ]) ZoneWideStoragePoolAllocator to find 
> storage pool
> 2013-08-21 17:09:32,353 DEBUG 
> [storage.allocator.GarbageCollectingStoragePoolAllocator] 
> (Job-Executor-49:job-66 = [ 50b09c49-f155-4b59-b6a3-9c77394fe172 ]) 
> GarbageCollectingStoragePoolAllocator looking for storage pool
> 2013-08-21 17:09:32,361 DEBUG [cloud.storage.StorageManagerImpl] 
> (Job-Executor-49:job-66 = [ 50b09c49-f155-4b59-b6a3-9c77394fe172 ]) Storage 
> pool garbage collector found 0 templates to clean up in storage pool: 
> vmware-primary-1
> 2013-08-21 17:09:32,365 DEBUG [cloud.storage.StorageManagerImpl] 
> (Job-Executor-49:job-66 = [ 50b09c49-f155-4b59-b6a3-9c77394fe172 ]) Storage 
> pool garbage collector found 1 templates to clean up in storage pool: 
> vmware-primary-2
> 2013-08-21 17:09:32,366 DEBUG [cloud.template.TemplateManagerImpl] 
> (Job-Executor-49:job-66 = [ 50b09c49-f155-4b59-b6a3-9c77394fe172 ]) Evicting 
> TmplPool[5-7-201-1bb6ddc2f6bf3f918ebd7ead6073aae5]
> 2013-08-21 17:09:32,368 DEBUG [agent.transport.Request] 
> (Job-Executor-49:job-66 = [ 50b09c49-f155-4b59-b6a3-9c77394fe172 ]) Seq 
> 5-357960810: Sending  { Cmd , MgmtId: 7471666038533, via: 5, Ver: v1, Flags: 
> 100111, 
> [{"com.cloud.agent.api.storage.DestroyCommand":{"volume":{"id":5,"mountPoint":"/export/home/chandan/307PB-195-103/primary2","path":"1bb6ddc2f6bf3f918ebd7ead6073aae5","size":0,"storagePoolType":"NetworkFilesystem","storagePoolUuid":"96bc10ee-70b3-3d20-a60c-c068a024b3a7","deviceId":0},"wait":0}}]
>  }
> 2013-08-21 17:09:32,369 DEBUG [agent.transport.Request] 
> (Job-Executor-49:job-66 = [ 50b09c49-f155-4b59-b6a3-9c77394fe172 ]) Seq 
> 5-357960810: Executing:  { Cmd , MgmtId: 7471666038533, via: 5, Ver: v1, 
> Flags: 100111, 
> [{"com.cloud.agent.api.storage.DestroyCommand":{"volume":{"id":5,"mountPoint":"/export/home/chandan/307PB-195-103/primary2","path":"1bb6ddc2f6bf3f918ebd7ead6073aae5","size":0,"storagePoolType":"NetworkFilesystem","storagePoolUuid":"96bc10ee-70b3-3d20-a60c-c068a024b3a7","deviceId":0},"wait":0}}]
>  }
> 2013-08-21 17:09:32,369 DEBUG [agent.manager.D

[jira] [Updated] (CLOUDSTACK-3010) [VMWare] [SharedNetworkWithServices] router VM deployment fails with error "Message: Invalid configuration for device '2'."


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

Animesh Chaturvedi updated CLOUDSTACK-3010:
---

Fix Version/s: (was: 4.2.0)
   4.2.1

Tagging for 4.2.1

> [VMWare] [SharedNetworkWithServices] router VM deployment fails with error 
> "Message: Invalid configuration for device '2'."
> ---
>
> Key: CLOUDSTACK-3010
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3010
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.2.0
> Environment: commit # 971c40d98e07ab6cddb8e6db5095c1acea935815
>Reporter: venkata swamybabu budumuru
>Assignee: Venkata Siva Vijayendra Bhamidipati
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: logs.setup1.tgz, logs.setup2.tgz, logs.tgz
>
>
> Steps to reproduce :
> 1. Have latest CloudStack setup with advanced zone using VMware cluster (1 
> host added to the cluster)
> 2. create a shared network with all services enabled
> mysql> select * from network_offerings where id=14\G
> *** 1. row ***
>id: 14
>  name: CustomSharedOffering
>  uuid: dbee9234-e443-4f00-827e-e9258bb0c209
>   unique_name: CustomSharedOffering
>  display_text: CustomSharedOffering
>   nw_rate: NULL
>   mc_rate: 10
>  traffic_type: Guest
>  tags: NULL
>   system_only: 0
>  specify_vlan: 1
>   service_offering_id: NULL
> conserve_mode: 0
>   created: 2013-06-14 14:34:10
>   removed: NULL
>   default: 0
>  availability: Optional
>  dedicated_lb_service: 1
> shared_source_nat_service: 0
>  sort_key: 0
>  redundant_router_service: 0
> state: Enabled
>guest_type: Shared
>elastic_ip_service: 0
>   eip_associate_public_ip: 0
>elastic_lb_service: 0
> specify_ip_ranges: 1
>inline: 0
> is_persistent: 0
>   internal_lb: 0
> public_lb: 1
> mysql> select * from ntwk_offering_service_map where network_offering_id=14;
> ++-++---+-+
> | id | network_offering_id | service| provider  | created 
> |
> ++-++---+-+
> | 48 |  14 | Dhcp   | VirtualRouter | 2013-06-14 
> 14:34:10 |
> | 52 |  14 | Dns| VirtualRouter | 2013-06-14 
> 14:34:10 |
> | 51 |  14 | Firewall   | VirtualRouter | 2013-06-14 
> 14:34:10 |
> | 49 |  14 | Lb | VirtualRouter | 2013-06-14 
> 14:34:10 |
> | 53 |  14 | PortForwarding | VirtualRouter | 2013-06-14 
> 14:34:10 |
> | 46 |  14 | SourceNat  | VirtualRouter | 2013-06-14 
> 14:34:10 |
> | 50 |  14 | StaticNat  | VirtualRouter | 2013-06-14 
> 14:34:10 |
> | 47 |  14 | UserData   | VirtualRouter | 2013-06-14 
> 14:34:10 |
> ++-++---+-+
> 3. create a Network using the above offering
> 4. Login as non-ROOT domain user and try to deploy VM using the above network.
> Observations:
> (i) deployment failed with the following error. 
> 2013-06-14 11:49:53,743 DEBUG [vmware.mo.HostMO] 
> (DirectAgent-29:10.147.40.12) find VM r-27-VM on host
> 2013-06-14 11:49:53,743 DEBUG [vmware.mo.HostMO] 
> (DirectAgent-29:10.147.40.12) VM r-27-VM found in host cache
> 2013-06-14 11:49:53,764 INFO  [vmware.resource.VmwareResource] 
> (DirectAgent-29:10.147.40.12) Configure VNC port for VM r-27-VM, port: 5914, 
> host: 10.147.40.12
> 2013-06-14 11:49:53,889 WARN  [vmware.resource.VmwareResource] 
> (DirectAgent-29:10.147.40.12) StartCommand failed due to Exception: 
> java.lang.RuntimeException
> Message: Invalid configuration for device '2'.
> java.lang.RuntimeException: Invalid configuration for device '2'.
> at 
> com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:291)
> at 
> com.cloud.hypervisor.vmware.mo.VirtualMachineMO.configureVm(VirtualMachineMO.java:832)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2674)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource

[jira] [Updated] (CLOUDSTACK-4430) [Automation][vmware] Failed to deploy vm, if one host is down in a cluster


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

Animesh Chaturvedi updated CLOUDSTACK-4430:
---


Tagging for 4.2.1

> [Automation][vmware] Failed to deploy vm, if one host is down in a cluster
> --
>
> Key: CLOUDSTACK-4430
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4430
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Management Server, VMware
>Affects Versions: 4.2.0
> Environment: Automation
> vmware
>Reporter: Rayees Namathponnan
>Assignee: Kelven Yang
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: management-server.log.2013-08-20.gz, 
> management-server.rar
>
>
> This issue observed during automation run
> 1) Automation running with 2 zones (advanced ), both zone contions one 
> cluster;  first cluster  having 2 hosts (10.223.250.130 and 10.223.250.131) 
> and another cluster have 1  host.
> 2) Create vm one first zone;  
> 3) make one host (10.223.250.130) down from first zone 
> 4) deploy an another vm after the first zone is down
> Expected Behavior
> ---
> New vm should be deployed with first zone, on the second host (10.223.250.131)
> Actual Result 
> 
> VM deployment failed with below error
> 2013-08-21 15:49:49,125 DEBUG [cloud.storage.VolumeManagerImpl] 
> (Job-Executor-29:job-1549 = [ cf900a2a-6c83-4ddd-b898-e19c90cef0a6 ]) 
> Checking if we need to prepare 1 volumes for VM[DomainRouter|r-524-TestVM]
> 2013-08-21 15:49:49,131 DEBUG [storage.image.TemplateDataFactoryImpl] 
> (Job-Executor-29:job-1549 = [ cf900a2a-6c83-4ddd-b898-e19c90cef0a6 ]) 
> template 8 is already in store:2, type:Image
> 2013-08-21 15:49:49,155 DEBUG [storage.image.TemplateDataFactoryImpl] 
> (Job-Executor-29:job-1549 = [ cf900a2a-6c83-4ddd-b898-e19c90cef0a6 ]) 
> template 8 is already in store:1, type:Primary
> 2013-08-21 15:49:49,224 DEBUG [storage.motion.AncientDataMotionStrategy] 
> (Job-Executor-29:job-1549 = [ cf900a2a-6c83-4ddd-b898-e19c90cef0a6 ]) 
> copyAsync inspecting src type TEMPLATE copyAsync inspecting dest type VOLUME
> 2013-08-21 15:49:49,232 DEBUG [agent.transport.Request] 
> (Job-Executor-29:job-1549 = [ cf900a2a-6c83-4ddd-b898-e19c90cef0a6 ]) Seq 
> 3-1188243408: Sending  { Cmd , MgmtId: 90928106758026, via: 3, Ver: v1, 
> Flags: 100011, [{"org.apac
> he.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"d559e79dc94f3ceea16e841774053435","origUrl":"http://download.cloud.com/templates/4.2/systemvmtemplate-4.2-vh7.ova";
> ,"uuid":"426a759e-09ec-11e3-a733-52b2d980df8a","id":8,"format":"OVA","accountId":1,"checksum":"8fde62b1089e5844a9cd3b9b953f9596","hvm":false,"displayText":"SystemVM
>  Template (vSphere)","imageDataStore":{"org.apache.cloudstack.st
> orage.to.PrimaryDataStoreTO":{"uuid":"4faf04c2-6dd8-3025-b43f-65d32cc49d02","id":1,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/automation/SC-CLOUD-QA03/primary1","port":2049}},"name":"routing-8","
> hypervisorType":"VMware"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"3c7b36c7-a034-485b-b808-501e6b8a067a","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid"
> :"4faf04c2-6dd8-3025-b43f-65d32cc49d02","id":1,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/automation/SC-CLOUD-QA03/primary1","port":2049}},"name":"ROOT-524","size":2097152000,"volumeId":575,"vmNa
> me":"r-524-TestVM","accountId":2,"format":"OVA","id":575,"hypervisorType":"None"}},"executeInSequence":false,"wait":0}}]
>  }
> 2013-08-21 15:49:49,232 DEBUG [agent.transport.Request] 
> (Job-Executor-29:job-1549 = [ cf900a2a-6c83-4ddd-b898-e19c90cef0a6 ]) Seq 
> 3-1188243408: Executing:  { Cmd , MgmtId: 90928106758026, via: 3, Ver: v1, 
> Flags: 100011, [{"org.a
> pache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"d559e79dc94f3ceea16e841774053435","origUrl":"http://download.cloud.com/templates/4.2/systemvmtemplate-4.2-vh7.o
> va","uuid":"426a759e-09ec-11e3-a733-52b2d980df8a","id":8,"format":"OVA","accountId":1,"checksum":"8fde62b1089e5844a9cd3b9b953f9596","hvm":false,"displayText":"SystemVM
>  Template (vSphere)","imageDataStore":{"org.apache.cloudstack
> .storage.to.PrimaryDataStoreTO":{"uuid":"4faf04c2-6dd8-3025-b43f-65d32cc49d02","id":1,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/automation/SC-CLOUD-QA03/primary1","port":2049}},"name":"routing-8
> ","hypervisorType":"VMware"}},"destTO":{"org.apache.cloudstack.storage.t

[jira] [Updated] (CLOUDSTACK-4413) [UI]IPV6 - Not able to extend Ipv6 range for an existing ipv6 network.


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

Animesh Chaturvedi updated CLOUDSTACK-4413:
---

Fix Version/s: (was: 4.2.0)
   4.2.1

Tagging for 4.2.1

> [UI]IPV6 - Not able to extend Ipv6 range for an existing ipv6 network.
> --
>
> Key: CLOUDSTACK-4413
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4413
> 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: Build form 4.2
>Reporter: Sangeetha Hariharan
>Priority: Critical
> Fix For: 4.2.1
>
>
> Steps to reproduce the problem:
> Create a ipv6 network by providing only ipv6 parameters.
> Now Try to extend the IPV6 range for this network by providing "IPV6 Start 
> IP" and "IPV6 End" IP.
> Following error message is presented to the user
> "Gateway, netmask and zoneId have to be passed in for virtual and direct 
> untagged networks"
> 2013-08-20 16:12:04,370 INFO  [cloud.api.ApiServer] (catalina-exec-6:null) 
> (userId=2 accountId=2 sessionId=5D69ED7832AC98EC474EEB4026D0C139) 
> 10.217.252.50 -- GET 
> command=createVlanIpRange&forVirtualNetwork=false&networkid=e77c9b30-e577-45d3-9110-e35d2d5d660c&startipv6=fc00:3:1363::11&endipv6=fc00:3:1363::20&response=json&sessionkey=gx5ogg5IT%2FtLKkL8O8ygTWaHIPk%3D&_=1377040741242
>  431 Gateway, netmask and zoneId have to be passed in for virtual and direct 
> untagged networks
> Expected Result:
> We should be able to  extend the IPV6 range for an existing network by 
> providing only "IPV6 Start IP" and "IPV6 End IP".

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

[jira] [Commented] (CLOUDSTACK-3010) [VMWare] [SharedNetworkWithServices] router VM deployment fails with error "Message: Invalid configuration for device '2'."

2013-08-22 Thread venkata swamybabu budumuru (JIRA)


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

venkata swamybabu budumuru commented on CLOUDSTACK-3010:


I will be OOO till 25th August. if anything urgent please contact 
sudha.ponnaga...@citrix.com. swamyb...@gmail.com


> [VMWare] [SharedNetworkWithServices] router VM deployment fails with error 
> "Message: Invalid configuration for device '2'."
> ---
>
> Key: CLOUDSTACK-3010
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3010
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.2.0
> Environment: commit # 971c40d98e07ab6cddb8e6db5095c1acea935815
>Reporter: venkata swamybabu budumuru
>Assignee: Venkata Siva Vijayendra Bhamidipati
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: logs.setup1.tgz, logs.setup2.tgz, logs.tgz
>
>
> Steps to reproduce :
> 1. Have latest CloudStack setup with advanced zone using VMware cluster (1 
> host added to the cluster)
> 2. create a shared network with all services enabled
> mysql> select * from network_offerings where id=14\G
> *** 1. row ***
>id: 14
>  name: CustomSharedOffering
>  uuid: dbee9234-e443-4f00-827e-e9258bb0c209
>   unique_name: CustomSharedOffering
>  display_text: CustomSharedOffering
>   nw_rate: NULL
>   mc_rate: 10
>  traffic_type: Guest
>  tags: NULL
>   system_only: 0
>  specify_vlan: 1
>   service_offering_id: NULL
> conserve_mode: 0
>   created: 2013-06-14 14:34:10
>   removed: NULL
>   default: 0
>  availability: Optional
>  dedicated_lb_service: 1
> shared_source_nat_service: 0
>  sort_key: 0
>  redundant_router_service: 0
> state: Enabled
>guest_type: Shared
>elastic_ip_service: 0
>   eip_associate_public_ip: 0
>elastic_lb_service: 0
> specify_ip_ranges: 1
>inline: 0
> is_persistent: 0
>   internal_lb: 0
> public_lb: 1
> mysql> select * from ntwk_offering_service_map where network_offering_id=14;
> ++-++---+-+
> | id | network_offering_id | service| provider  | created 
> |
> ++-++---+-+
> | 48 |  14 | Dhcp   | VirtualRouter | 2013-06-14 
> 14:34:10 |
> | 52 |  14 | Dns| VirtualRouter | 2013-06-14 
> 14:34:10 |
> | 51 |  14 | Firewall   | VirtualRouter | 2013-06-14 
> 14:34:10 |
> | 49 |  14 | Lb | VirtualRouter | 2013-06-14 
> 14:34:10 |
> | 53 |  14 | PortForwarding | VirtualRouter | 2013-06-14 
> 14:34:10 |
> | 46 |  14 | SourceNat  | VirtualRouter | 2013-06-14 
> 14:34:10 |
> | 50 |  14 | StaticNat  | VirtualRouter | 2013-06-14 
> 14:34:10 |
> | 47 |  14 | UserData   | VirtualRouter | 2013-06-14 
> 14:34:10 |
> ++-++---+-+
> 3. create a Network using the above offering
> 4. Login as non-ROOT domain user and try to deploy VM using the above network.
> Observations:
> (i) deployment failed with the following error. 
> 2013-06-14 11:49:53,743 DEBUG [vmware.mo.HostMO] 
> (DirectAgent-29:10.147.40.12) find VM r-27-VM on host
> 2013-06-14 11:49:53,743 DEBUG [vmware.mo.HostMO] 
> (DirectAgent-29:10.147.40.12) VM r-27-VM found in host cache
> 2013-06-14 11:49:53,764 INFO  [vmware.resource.VmwareResource] 
> (DirectAgent-29:10.147.40.12) Configure VNC port for VM r-27-VM, port: 5914, 
> host: 10.147.40.12
> 2013-06-14 11:49:53,889 WARN  [vmware.resource.VmwareResource] 
> (DirectAgent-29:10.147.40.12) StartCommand failed due to Exception: 
> java.lang.RuntimeException
> Message: Invalid configuration for device '2'.
> java.lang.RuntimeException: Invalid configuration for device '2'.
> at 
> com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:291)
> at 
> com.cloud.hypervisor.vmware.mo.VirtualMachineMO.configureVm(VirtualMachineMO.java:832)
> at 
> com.cloud.hypervisor.vmware.resource.Vmware

[jira] [Updated] (CLOUDSTACK-3424) IPV6 - When a Vm is expunged and a new Vm is deployed with the same name , /etc/dhchosts.txt has 2 entries with the same name.


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

Animesh Chaturvedi updated CLOUDSTACK-3424:
---

Fix Version/s: (was: 4.2.0)
   4.2.1

Tagging for 4.2.1

> IPV6 - When a Vm is expunged and a new Vm is deployed with the same name , 
> /etc/dhchosts.txt has 2 entries with the same name.
> --
>
> Key: CLOUDSTACK-3424
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3424
> 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: Build from master-6-17-stable
>Reporter: Sangeetha Hariharan
>Assignee: Sheng Yang
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: management-server.log
>
>
> IPV6 - When a Vm is expunged and a new Vm is deployed with the same name , 
> /etc/dhchosts.txt has 2 entries with the same name
> Steps to reproduce the problem:
> Create a ipv6 network.
> Deploy a Vm with name - test456.
> Destroy this VM. Wait for it to be expunged.
> Deploy another Vm with same name - test456.
> We see that there are 2 entries in the router with the same name "test456" 
> resolving to 2 different ipv6 addresses.
> root@r-17-VM:~# cat /etc/dhcphosts.txt
> id:00:03:00:01:06:4e:de:00:00:2f,[fc00:3:1370::744f],test123,infinite
> id:00:03:00:01:06:75:46:00:00:31,[fc00:3:1370::34ed],test456,infinite
> id:00:03:00:01:06:e4:ae:00:00:32,[fc00:3:1370::ae4b],testyoyo,infinite
> id:00:03:00:01:06:96:aa:00:00:33,[fc00:3:1370::34ed],testyoyo1,infinite
> id:00:03:00:01:06:cb:88:00:00:34,[fc00:3:1370::6eb2],test456,infinite
> root@r-17-VM:~#
> Attaching management server logs:
> Have 2 entries for the same name is a problem.
> Is it also a problem to have the same ipv6 address associated with 2 
> different vms with different Vm names ( 1 expunged and 1 active , in my case 
> "test456" which is expunged and "testyoyo1" which is active) ?

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

[jira] [Updated] (CLOUDSTACK-1365) UI support for baremetal PXE server


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

Animesh Chaturvedi updated CLOUDSTACK-1365:
---

Fix Version/s: (was: 4.2.0)
   4.2.1

Tagging for 4.2.1

> UI support for baremetal PXE server
> ---
>
> Key: CLOUDSTACK-1365
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1365
> 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: frank zhang
>Assignee: Jessica Wang
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: management-server.log.gz, Screenshot-CloudPlatform™ - 
> Mozilla Firefox-1.png
>
>
> Baremetal PXE needs a page to add device
> the API is AddBaremetalKickStartPxeCmd
> please contact frank for details

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

[jira] [Updated] (CLOUDSTACK-1364) UI support for baremetal DHCP server


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

Animesh Chaturvedi updated CLOUDSTACK-1364:
---

Fix Version/s: (was: 4.2.0)
   4.2.1

Tagging for 4.2.1

> UI support for baremetal DHCP server
> 
>
> Key: CLOUDSTACK-1364
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1364
> 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: frank zhang
>Assignee: frank zhang
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: management-server.log.gz, Screenshot-CloudPlatform™ - 
> Mozilla Firefox.png
>
>
> Baremetal DHCP needs a page to add device
> the API is AddBaremetalDhcpCmd
> please contact frank for details

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

[jira] [Updated] (CLOUDSTACK-4102) [UI] required ui changes for scaleup vm feature


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

Animesh Chaturvedi updated CLOUDSTACK-4102:
---

Fix Version/s: (was: 4.2.0)
   4.2.1

> [UI]  required ui changes for scaleup vm feature 
> -
>
> Key: CLOUDSTACK-4102
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4102
> 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: prashant kumar mishra
>Assignee: Jessica Wang
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: svm_changeSO.png, svm_scaleup.png, Systemvms.jpeg, 
> Uservms.jpeg, usr_scaleup.png, vmstop_msg_vmware.jpg
>
>
> Current scenario
> -
> we are using "Scale UP Virtual Machine" action button  to  change service 
> offering of a stopped vm and to scaleup SO of a running vm
> Require changes
> 
> 1:
> Action button "Change service offering"  should be removed
> WHY: because we are doing it using "scale UP virtual machine" action button
> 2:
> when vms are in stopped state we need to RENAME  Scale UP Virtual Machine 
> action button to Change service offering 
> WHY RENAME: because underlying API calls for Change service offering button 
> should be same as in Scale UP Virtual Machine
> WHY:because previous versions CS user  is familiar with change SO action 
> button , so its require to keep in that way to avoid confusion  
> 3:
> when vms are in running state UI should not show scale UP Virtual Machine 
> action button for hypervisor on which scaleup is not supported 
> -->scale up is not supported  on KVM
> -->not supported for system vms on xen 
> 4:
> please check screenshots for more details 

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

[jira] [Created] (CLOUDSTACK-4454) object_store - Not able to delete secondary storage when existing snapshots are deleted.

2013-08-22 Thread Sangeetha Hariharan (JIRA)

Sangeetha Hariharan created CLOUDSTACK-4454:
---

 Summary: object_store - Not able to delete secondary storage when 
existing snapshots are deleted.
 Key: CLOUDSTACK-4454
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4454
 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: Build from 4.2
Reporter: Sangeetha Hariharan
Priority: Critical
 Fix For: 4.2.1


object_store - Not able to delete secondary storage when existing snapshots are 
deleted.

Steps to reproduce the problem:

Have a zone with 2 NSF secondary stores - ss1 and ss2.
Deploy few Vms and take few snapshots.

Delete all the snapshots that reside in ss2.

Now try to delete ss2.

Deletion fails with following error message:
"Cannot delete image store with active snapshots backup!"

Management server logs:

2013-08-22 10:13:35,466 DEBUG [cloud.api.ApiServlet] (catalina-exec-12:null) 
===START===  10.215.3.9 -- 
GET  command=deleteImageStore&id=7b7ed196-fa00-4cd8-a606

-b743cd64cfd9&response=json&sessionkey=pk9TsSw2pRHDZg2GsRmnZYONBKU%3D&_=13771920
39022
2013-08-22 10:13:35,475 INFO  [cloud.api.ApiServer] (catalina-exec-12:null) 
Cannot delete image store with active snapshots backup!

mysql> select * from image_store;
++--+-+--+---++---+---+--+--+-+-+++
| id | name | image_provider_name | protocol | url  
 | data_center_id | scope | role  | uuid
 | parent   | created   
  | removed | total_size | used_bytes |
++--+-+--+---++---+---+--+--+-+-+++
|  1 | ss1  | NFS | nfs  | 
nfs://10.223.110.232/export/home/sangeetha/42-ipv6/secondary/ |  1 
| ZONE  | Image | cb921af8-83fa-4b04-a1fd-2a0970e3d16d | 
036a3728-d869-3d9a-b590-bd8cbf5b2c14 | 2013-08-20 21:52:22 | NULL|   
NULL |   NULL |
|  2 | ss2  | NFS | nfs  | 
nfs://10.223.110.232/export/home/sangeetha/42-ipv6/secondary2 |  1 
| ZONE  | Image | 7b7ed196-fa00-4cd8-a606-b743cd64cfd9 | 
0653a328-9bb3-321c-943d-f5164eb2d62f | 2013-08-21 23:46:45 | NULL|   
NULL |   NULL |
|  3 | ss3  | NFS | nfs  | 
nfs://10.223.110.232/export/home/sangeetha/42-ipv6/secondary3 |  1 
| ZONE  | Image | 4598a3fd-7b69-4e3f-9178-36799b5755b1 | 
71490b8f-f8fd-3f54-b280-ded7eebee441 | 2013-08-22 17:17:57 | NULL|   
NULL |   NULL |
++--+-+--+---++---+---+--+--+-+-+++
3 rows in set (0.00 sec)

mysql> select store_id , store_role, snapshot_id , state   from 
snapshot_store_ref;
+--++-+---+
| store_id | store_role | snapshot_id | state |
+--++-+---+
|1 | Image  |   1 | Ready |
|1 | Primary|   2 | Ready |
|1 | Image  |   2 | Ready |
|1 | Primary|   3 | Destroyed |
|2 | Image  |   3 | Destroyed |
|1 | Primary|   4 | Destroyed |
|2 | Image  |   4 | Destroyed |
+--++-+---+
7 rows in set (0.03 sec)

mysql>


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

[jira] [Commented] (CLOUDSTACK-1365) UI support for baremetal PXE server

2013-08-22 Thread Jessica Wang (JIRA)


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

Jessica Wang commented on CLOUDSTACK-1365:
--

angeline,

Please provide API calls of your first attempt(first attempt, not second 
attempt) to Add PXE server via UI. 

like this:

http://localhost:8080/client/api?command=addBaremetalPxeKickStartServer&response=json&sessionkey=jppekHkIO0ziJQbrENyumhifItY%3D
{
"addexternalpxeresponse": {
"jobid": "8c62423d-27da-4f9b-921f-2e8ac016d8b9"
}
}


and the last queryAsyncJobResult API call whose jobId matches and returned 
jobstatus is 0(success) or 2(fail), but not 1(not finished yet:

http://localhost:8080/client/api?command=queryAsyncJobResult&jobId=8c62423d-27da-4f9b-921f-2e8ac016d8b9&response=json&sessionkey=jppekHkIO0ziJQbrENyumhifItY%3D&_=1377193572477
{
"queryasyncjobresultresponse": {
"accountid": "f7462e2a-0aac-11e3-88a7-3c970e739c3e",
"userid": "f7465db4-0aac-11e3-88a7-3c970e739c3e",
"cmd": "org.apache.cloudstack.api.AddBaremetalKickStartPxeCmd",
"jobstatus": 2,
"jobprocstatus": 0,
"jobresultcode": 530,
"jobresulttype": "object",
"jobresult": {
"errorcode": 530,
"errortext": "No IP specified"
},
"created": "2013-08-22T10:46:09-0700",
"jobid": "8c62423d-27da-4f9b-921f-2e8ac016d8b9"
}
}

thank you.

Jessica


> UI support for baremetal PXE server
> ---
>
> Key: CLOUDSTACK-1365
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1365
> 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: frank zhang
>Assignee: Jessica Wang
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: management-server.log.gz, Screenshot-CloudPlatform™ - 
> Mozilla Firefox-1.png
>
>
> Baremetal PXE needs a page to add device
> the API is AddBaremetalKickStartPxeCmd
> please contact frank for details

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

[jira] [Assigned] (CLOUDSTACK-1365) UI support for baremetal PXE server

2013-08-22 Thread Jessica Wang (JIRA)


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

Jessica Wang reassigned CLOUDSTACK-1365:


Assignee: angeline shen  (was: Jessica Wang)

> UI support for baremetal PXE server
> ---
>
> Key: CLOUDSTACK-1365
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1365
> 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: frank zhang
>Assignee: angeline shen
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: management-server.log.gz, Screenshot-CloudPlatform™ - 
> Mozilla Firefox-1.png
>
>
> Baremetal PXE needs a page to add device
> the API is AddBaremetalKickStartPxeCmd
> please contact frank for details

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

[jira] [Commented] (CLOUDSTACK-4436) Virtual Router fails to start on RHEL6.2

2013-08-22 Thread Sheng Yang (JIRA)


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

Sheng Yang commented on CLOUDSTACK-4436:


No information show in the log. No way to tell what's wrong.

The most common mistake is ssh key is not updated then check ssh command 
failed. But the logs show no error in fact.

Please recheck and upload the right log.

> Virtual Router fails to start on RHEL6.2
> 
>
> Key: CLOUDSTACK-4436
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4436
> 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: Management Server is installed on RHEL 6.2 , Host: KVM 
> on RHEL 6.2
>Reporter: Pavan Kumar Bandarupally
>Priority: Blocker
> Fix For: 4.2.1
>
> Attachments: AgentLog.rar, MSLog.rar
>
>
> 4.2 ACS build is installed on RHEL 6.2 . Once the infrastructure is added and 
> zone is enabled the system VMs are brought up and are running. Once user 
> tries to create an instance an error is thrown. The Virtual router is not 
> started and because of that instance is not being created.
> The following exception is thrown:
> 2013-08-21 19:55:27,456 ERROR [cloud.vm.VirtualMachineManagerImpl] 
> (Job-Executor-13:job-13 = [ 4663f0b4-8fea-480c-8831-f989b646674d ]) Failed to 
> start instance VM[DomainRouter|r-4-VM]
> com.cloud.utils.exception.ExecutionException: Unable to start 
> VM[DomainRouter|r-4-VM] due to error in finalizeStart, not retrying
> at 
> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:949)
> at 
> com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:576)
> at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.start(VirtualNetworkApplianceManagerImpl.java:2740)
> at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startVirtualRouter(VirtualNetworkApplianceManagerImpl.java:1872)
> at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startRouters(VirtualNetworkApplianceManagerImpl.java:1972)
> at 
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.deployVirtualRouterInGuestNetwork(VirtualNetworkApplianceManagerImpl.java:1950)
> at 
> com.cloud.network.element.VirtualRouterElement.implement(VirtualRouterElement.java:188)
> at 
> com.cloud.network.NetworkManagerImpl.implementNetworkElementsAndResources(NetworkManagerImpl.java:2003)
> at 
> com.cloud.network.NetworkManagerImpl.implementNetwork(NetworkManagerImpl.java:1908)
> at 
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at 
> com.cloud.network.NetworkManagerImpl.prepare(NetworkManagerImpl.java:2089)
> at 
> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:884)
> at 
> com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:576)
> at 
> org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:227)
> at 
> org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209)
> at 
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3406)
> at 
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2966)
> at 
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2952)
> at 
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at 
> org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:420)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at 
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-08-21 19:55:27,471 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
> (Job-Executor-13:job-13 = [ 4663f0b4-8fea-480c-8831-f989b646674d ]) Cleaning 
> up resources for the vm VM[Dom

[jira] [Created] (CLOUDSTACK-4455) object_store - Template sync results in private templates being synced to all the secondary stores.

2013-08-22 Thread Sangeetha Hariharan (JIRA)

Sangeetha Hariharan created CLOUDSTACK-4455:
---

 Summary: object_store - Template sync results in private templates 
being synced to all the secondary stores.
 Key: CLOUDSTACK-4455
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4455
 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: Build from 4.2
Reporter: Sangeetha Hariharan
Priority: Critical
 Fix For: 4.2.1


object_store - Template sync results in private templates being synced to all 
the secondary stores.

Steps to reproduce the problem:

Have a zone with 1 NSF secondary store - ss1.
Register a private template.

Add another secondary store -ss2 to this zone.

Reboot SSVM (or restart management server) to trigger template sync.

This results in  private templates being synced to ss2.

Expected Behavior:

Only public templates and system templates need to be synced across multiple 
secondary stores.
Private templates should not be synced.


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

[jira] [Closed] (CLOUDSTACK-3574) Vmware - java.lang.NumberFormatException encountered when executing NetworkUsageCommand.

2013-08-22 Thread Sangeetha Hariharan (JIRA)


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

Sangeetha Hariharan closed CLOUDSTACK-3574.
---


Tested with latest build from 4.2.

There are no exceptions seen when executing the "NetworkUsageCommand".

Closing this issue.

> Vmware - java.lang.NumberFormatException encountered when executing 
> NetworkUsageCommand. 
> -
>
> Key: CLOUDSTACK-3574
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3574
> 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: Build from 4.2
>Reporter: Sangeetha Hariharan
>Assignee: Kishan Kavala
>Priority: Critical
> Fix For: 4.2.0
>
>
> Set up:
> Advanced zone set up with vmware ESXI 5.0 host.
> Deploy few Vms.
> Following exception is seen every 5 minutes when executing 
> NetworkUsageCommand. 
> 2013-07-16 15:37:46,837 INFO  [vmware.resource.VmwareResource] 
> (DirectAgent-10:10.223.57.66) Executing resource NetworkUsageCommand
> 2013-07-16 15:37:46,841 DEBUG [agent.manager.DirectAgentAttache] 
> (DirectAgent-11:null) Seq 1-227737619: Executing request
> 2013-07-16 15:37:46,841 INFO  [vmware.resource.VmwareResource] 
> (DirectAgent-11:10.223.57.66) Executing resource NetworkUsageCommand
> 2013-07-16 15:37:47,502 WARN  [vmware.resource.VmwareResource] 
> (DirectAgent-10:10.223.57.66) Unable to parse return from script return of 
> network usage command: java.lang.NumberFormatException: For input string: 
> "iptables"
> java.lang.NumberFormatException: For input string: "iptables"
> at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Long.parseLong(Long.java:438)
> at java.lang.Long.(Long.java:690)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.getNetworkStats(VmwareResource.java:6006)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:682)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:517)
> at 
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-07-16 15:37:47,579 WARN  [vmware.resource.VmwareResource] 
> (DirectAgent-11:10.223.57.66) Unable to parse return from script return of 
> network usage command: java.lang.NumberFormatException: For input string: 
> "iptables"
> java.lang.NumberFormatException: For input string: "iptables"
> at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Long.parseLong(Long.java:438)
> at java.lang.Long.(Long.java:690)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.getNetworkStats(VmwareResource.java:6006)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:682)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:517)
> at 
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-07-16 15:37:47,705 DEBUG [agent.manager.DirectAgentAttache]

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


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

Animesh Chaturvedi commented on CLOUDSTACK-4115:


I will cherry-pick the patch into 4.2 and the resolve the issue

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

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

[jira] [Commented] (CLOUDSTACK-1365) UI support for baremetal PXE server

2013-08-22 Thread frank zhang (JIRA)


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

frank zhang commented on CLOUDSTACK-1365:
-

no worry Jessica, I checked it looks like a server side bug

> UI support for baremetal PXE server
> ---
>
> Key: CLOUDSTACK-1365
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1365
> 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: frank zhang
>Assignee: angeline shen
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: management-server.log.gz, Screenshot-CloudPlatform™ - 
> Mozilla Firefox-1.png
>
>
> Baremetal PXE needs a page to add device
> the API is AddBaremetalKickStartPxeCmd
> please contact frank for details

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

[jira] [Resolved] (CLOUDSTACK-324) Cannot edit default security group rules, default security group blocks all inbound traffic.


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

Animesh Chaturvedi resolved CLOUDSTACK-324.
---

Resolution: Fixed

As per Edison it should be fixed, can you retest and re open if needed

> Cannot edit default security group rules, default security group blocks all 
> inbound traffic.
> 
>
> Key: CLOUDSTACK-324
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-324
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: pre-4.0.0
>Reporter: Max Clark
>Assignee: Wido den Hollander
>Priority: Critical
>  Labels: iptables, network, security
> Fix For: 4.2.0
>
>
> When configuring basic networking, by default the network is created with the 
> "DefaultSharedNetworkOffering". This offering does not have a security group. 
> No inbound traffic is allowed to the created VMs. Reading the AdminGuide 
> documentation:
> "Each CloudStack account comes with a default security group that denies all 
> inbound traffic and allows all outbound traffic. The default security group 
> can be modified so that all new VMs inherit some other desired set of rules."
> If a network is created without a security group, it shouldn't have a 
> security group and all inbound/outbound traffic should be allowed - or at the 
> very least the default security group should be able to be configured.
> http://www.cloudstack.com/forum/8-storage-and-networking/7054-vm-instance-cant-be-accessd-using-basic-networking.html?limit=6&start=6#7084

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

[jira] [Resolved] (CLOUDSTACK-4249) [KVM]ceph:showing wrong template size 755.64 TB(template created from snapshot)