date:20130522


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

Rajesh Battala commented on CLOUDSTACK-2398:


Thanks prasanna for committing the patch

 [Automation] SSVM test /usr/local/cloud/systemvm/ssvm-check.sh failed with 
 permission error 
 --

 Key: CLOUDSTACK-2398
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2398
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Template
Affects Versions: 4.2.0
 Environment: Master branch build 
 KVM 
Reporter: Rayees Namathponnan
Assignee: Rajesh Battala
Priority: Blocker
 Fix For: 4.2.0


 Step 1 : Create build from  master branch and configure advanced zone 
 Step 2 : Login to SSVM and run the scipt 
 /usr/local/cloud/systemvm/ssvm-check.sh
 Result :
 SSVM test failed with permission error 
 root@s-83-VM:~# /usr/local/cloud/systemvm/ssvm-check.sh
 
 First DNS server is  10.223.110.254
 PING 10.223.110.254 (10.223.110.254): 56 data bytes
 64 bytes from 10.223.110.254: icmp_seq=0 ttl=61 time=1.223 ms
 64 bytes from 10.223.110.254: icmp_seq=1 ttl=61 time=1.029 ms
 --- 10.223.110.254 ping statistics ---
 2 packets transmitted, 2 packets received, 0% packet loss
 round-trip min/avg/max/stddev = 1.029/1.126/1.223/0.097 ms
 Good: Can ping DNS server
 
 Good: DNS resolves download.cloud.com
 
 NFS is currently mounted
 Mount point is /var/lib/nfs/rpc_pipefs
 touch: cannot touch `/var/lib/nfs/rpc_pipefs/foo': Permission denied
 ERROR: Cannot write to mount point
 You need to export with norootsquash
 Mount point is /mnt/SecStorage/f075e82d-2e08-36c6-b6ba-25b692666b98
 Good: Can write to mount point
 
 Management server is 10.223.49.195. Checking connectivity.
 Good: Can connect to management server port 8250
 
 Good: Java process is running
 
 Tests Complete. Look for ERROR or WARNING above.
 root@s-83-VM:~#
 Note :
  SSVM test cases failing due to this 
 This test case passed on May 4th build
  This environement created with latest available template in 
  Jenkins.cloudstack.org

--
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-2398) [Automation] SSVM test /usr/local/cloud/systemvm/ssvm-check.sh failed with permission error


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

Rajesh Battala closed CLOUDSTACK-2398.
--


 [Automation] SSVM test /usr/local/cloud/systemvm/ssvm-check.sh failed with 
 permission error 
 --

 Key: CLOUDSTACK-2398
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2398
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Template
Affects Versions: 4.2.0
 Environment: Master branch build 
 KVM 
Reporter: Rayees Namathponnan
Assignee: Rajesh Battala
Priority: Blocker
 Fix For: 4.2.0


 Step 1 : Create build from  master branch and configure advanced zone 
 Step 2 : Login to SSVM and run the scipt 
 /usr/local/cloud/systemvm/ssvm-check.sh
 Result :
 SSVM test failed with permission error 
 root@s-83-VM:~# /usr/local/cloud/systemvm/ssvm-check.sh
 
 First DNS server is  10.223.110.254
 PING 10.223.110.254 (10.223.110.254): 56 data bytes
 64 bytes from 10.223.110.254: icmp_seq=0 ttl=61 time=1.223 ms
 64 bytes from 10.223.110.254: icmp_seq=1 ttl=61 time=1.029 ms
 --- 10.223.110.254 ping statistics ---
 2 packets transmitted, 2 packets received, 0% packet loss
 round-trip min/avg/max/stddev = 1.029/1.126/1.223/0.097 ms
 Good: Can ping DNS server
 
 Good: DNS resolves download.cloud.com
 
 NFS is currently mounted
 Mount point is /var/lib/nfs/rpc_pipefs
 touch: cannot touch `/var/lib/nfs/rpc_pipefs/foo': Permission denied
 ERROR: Cannot write to mount point
 You need to export with norootsquash
 Mount point is /mnt/SecStorage/f075e82d-2e08-36c6-b6ba-25b692666b98
 Good: Can write to mount point
 
 Management server is 10.223.49.195. Checking connectivity.
 Good: Can connect to management server port 8250
 
 Good: Java process is running
 
 Tests Complete. Look for ERROR or WARNING above.
 root@s-83-VM:~#
 Note :
  SSVM test cases failing due to this 
 This test case passed on May 4th build
  This environement created with latest available template in 
  Jenkins.cloudstack.org

--
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-2398) [Automation] SSVM test /usr/local/cloud/systemvm/ssvm-check.sh failed with permission error

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


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

Rajesh Battala resolved CLOUDSTACK-2398.


Resolution: Fixed

 [Automation] SSVM test /usr/local/cloud/systemvm/ssvm-check.sh failed with 
 permission error 
 --

 Key: CLOUDSTACK-2398
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2398
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Template
Affects Versions: 4.2.0
 Environment: Master branch build 
 KVM 
Reporter: Rayees Namathponnan
Assignee: Rajesh Battala
Priority: Blocker
 Fix For: 4.2.0


 Step 1 : Create build from  master branch and configure advanced zone 
 Step 2 : Login to SSVM and run the scipt 
 /usr/local/cloud/systemvm/ssvm-check.sh
 Result :
 SSVM test failed with permission error 
 root@s-83-VM:~# /usr/local/cloud/systemvm/ssvm-check.sh
 
 First DNS server is  10.223.110.254
 PING 10.223.110.254 (10.223.110.254): 56 data bytes
 64 bytes from 10.223.110.254: icmp_seq=0 ttl=61 time=1.223 ms
 64 bytes from 10.223.110.254: icmp_seq=1 ttl=61 time=1.029 ms
 --- 10.223.110.254 ping statistics ---
 2 packets transmitted, 2 packets received, 0% packet loss
 round-trip min/avg/max/stddev = 1.029/1.126/1.223/0.097 ms
 Good: Can ping DNS server
 
 Good: DNS resolves download.cloud.com
 
 NFS is currently mounted
 Mount point is /var/lib/nfs/rpc_pipefs
 touch: cannot touch `/var/lib/nfs/rpc_pipefs/foo': Permission denied
 ERROR: Cannot write to mount point
 You need to export with norootsquash
 Mount point is /mnt/SecStorage/f075e82d-2e08-36c6-b6ba-25b692666b98
 Good: Can write to mount point
 
 Management server is 10.223.49.195. Checking connectivity.
 Good: Can connect to management server port 8250
 
 Good: Java process is running
 
 Tests Complete. Look for ERROR or WARNING above.
 root@s-83-VM:~#
 Note :
  SSVM test cases failing due to this 
 This test case passed on May 4th build
  This environement created with latest available template in 
  Jenkins.cloudstack.org

--
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-2585) Failed to apply new PF rules after deleting the existing PF Rule with Cisco VNMC Provider


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

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

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

CLOUDSTACK-2585: Failed to apply new PF rules after deleting the existing PF 
Rule with Cisco VNMC Provider
Each rule created in VNMC under a policy object needs to have an unique order 
value. Rules are evaluated based on this value.
Eariler order was computed based on the rule count under a policy object. This 
resulted in duplicate order value when rules get
deleted and recreated. Changed the logic to compute order based on the CS db id 
of the rule which is unique.


 Failed to apply new PF rules after deleting the existing PF Rule with Cisco 
 VNMC Provider
 -

 Key: CLOUDSTACK-2585
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2585
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.2.0
Reporter: Sailaja Mada
Assignee: Koushik Das
Priority: Critical

 Setup: Advanced Networking Zone with Nexus VMWARE Cluster 
 Steps:
 1. Create Guest network with Cisco VNMC provider as 
 Firewall/PF/SourceNAT/Static NAT provider offering
 2. Deploy VM using this guest network
 3. Acquire new public IP and configure PF (22-22),PF(80-80) with TCP ,53 to 
 53 (UDP) rule
 4. Create 10.x cidr firewall rule from Source NAT IP
 5. Delete (22-22) PF rule from the public IP
 6. Try to create new PF rule (22-22) or any other.  
 Observation:
 It failed to  apply new PF rules after deleting the existing PF Rule 
 Exception:
 2013-05-20 16:45:33,646 ERROR [network.resource.CiscoVnmcResource] 
 (DirectAgent-359:null) SetPortForwardingRulesCommand failed due to Policy has 
 two rules 
 org-root/org-vlan-808/org-VDC-vlan-808/natpol-PF-vlan-808-10-102-196-232/rule-Rule-vlan-808-15,
  
 org-root/org-vlan-808/org-VDC-vlan-808/natpol-PF-vlan-808-10-102-196-232/rule-Rule-vlan-808-16
  with same order 102
 com.cloud.utils.exception.ExecutionException: Policy has two rules 
 org-root/org-vlan-808/org-VDC-vlan-808/natpol-PF-vlan-808-10-102-196-232/rule-Rule-vlan-808-15,
  
 org-root/org-vlan-808/org-VDC-vlan-808/natpol-PF-vlan-808-10-102-196-232/rule-Rule-vlan-808-16
  with same order 102
 at 
 com.cloud.network.cisco.CiscoVnmcConnectionImpl.verifySuccess(CiscoVnmcConnectionImpl.java:1370)
 at 
 com.cloud.network.cisco.CiscoVnmcConnectionImpl.createTenantVDCPFRule(CiscoVnmcConnectionImpl.java:1028)
 at 
 com.cloud.network.resource.CiscoVnmcResource.execute(CiscoVnmcResource.java:573)
 at 
 com.cloud.network.resource.CiscoVnmcResource.execute(CiscoVnmcResource.java:508)
 at 
 com.cloud.network.resource.CiscoVnmcResource.executeRequest(CiscoVnmcResource.java:100)
 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-05-20 16:45:33,647 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-359:null) Seq 5-1754464294: Response Received:
 2013-05-20 16:45:33,647 DEBUG [agent.transport.Request] 
 (DirectAgent-359:null) Seq 5-1754464294: Processing:  { Ans: , MgmtId: 
 214053811722752, via: 5, Ver: v1, Flags: 10, 
 [{Answer:{result:false,details:SetPortForwardingRulesCommand failed 
 due to Policy has two rules 
 org-root/org-vlan-808/org-VDC-vlan-808/natpol-PF-vlan-808-10-102-196-232/rule-Rule-vlan-808-15,
  
 org-root/org-vlan-808/org-VDC-vlan-808/natpol-PF-vlan-808-10-102-196-232/rule-Rule-vlan-808-16
  with same order 102,wait:0}}] }
 2013-05-20 16:45:33,647 DEBUG [agent.transport.Request] 
 (Job-Executor-81:job-48) Seq 5-1754464294: Received:  { Ans: , MgmtId: 
 214053811722752, via: 5, Ver: v1, Flags: 10, { Answer } }
 2013-05-20 16:45:33,647 DEBUG

[jira] [Updated] (CLOUDSTACK-2585) Failed to apply new PF rules after deleting the existing PF Rule with Cisco VNMC Provider

2013-05-22 Thread Koushik Das (JIRA)


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

Koushik Das updated CLOUDSTACK-2585:


Fix Version/s: 4.2.0

 Failed to apply new PF rules after deleting the existing PF Rule with Cisco 
 VNMC Provider
 -

 Key: CLOUDSTACK-2585
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2585
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.2.0
Reporter: Sailaja Mada
Assignee: Koushik Das
Priority: Critical
 Fix For: 4.2.0


 Setup: Advanced Networking Zone with Nexus VMWARE Cluster 
 Steps:
 1. Create Guest network with Cisco VNMC provider as 
 Firewall/PF/SourceNAT/Static NAT provider offering
 2. Deploy VM using this guest network
 3. Acquire new public IP and configure PF (22-22),PF(80-80) with TCP ,53 to 
 53 (UDP) rule
 4. Create 10.x cidr firewall rule from Source NAT IP
 5. Delete (22-22) PF rule from the public IP
 6. Try to create new PF rule (22-22) or any other.  
 Observation:
 It failed to  apply new PF rules after deleting the existing PF Rule 
 Exception:
 2013-05-20 16:45:33,646 ERROR [network.resource.CiscoVnmcResource] 
 (DirectAgent-359:null) SetPortForwardingRulesCommand failed due to Policy has 
 two rules 
 org-root/org-vlan-808/org-VDC-vlan-808/natpol-PF-vlan-808-10-102-196-232/rule-Rule-vlan-808-15,
  
 org-root/org-vlan-808/org-VDC-vlan-808/natpol-PF-vlan-808-10-102-196-232/rule-Rule-vlan-808-16
  with same order 102
 com.cloud.utils.exception.ExecutionException: Policy has two rules 
 org-root/org-vlan-808/org-VDC-vlan-808/natpol-PF-vlan-808-10-102-196-232/rule-Rule-vlan-808-15,
  
 org-root/org-vlan-808/org-VDC-vlan-808/natpol-PF-vlan-808-10-102-196-232/rule-Rule-vlan-808-16
  with same order 102
 at 
 com.cloud.network.cisco.CiscoVnmcConnectionImpl.verifySuccess(CiscoVnmcConnectionImpl.java:1370)
 at 
 com.cloud.network.cisco.CiscoVnmcConnectionImpl.createTenantVDCPFRule(CiscoVnmcConnectionImpl.java:1028)
 at 
 com.cloud.network.resource.CiscoVnmcResource.execute(CiscoVnmcResource.java:573)
 at 
 com.cloud.network.resource.CiscoVnmcResource.execute(CiscoVnmcResource.java:508)
 at 
 com.cloud.network.resource.CiscoVnmcResource.executeRequest(CiscoVnmcResource.java:100)
 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-05-20 16:45:33,647 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-359:null) Seq 5-1754464294: Response Received:
 2013-05-20 16:45:33,647 DEBUG [agent.transport.Request] 
 (DirectAgent-359:null) Seq 5-1754464294: Processing:  { Ans: , MgmtId: 
 214053811722752, via: 5, Ver: v1, Flags: 10, 
 [{Answer:{result:false,details:SetPortForwardingRulesCommand failed 
 due to Policy has two rules 
 org-root/org-vlan-808/org-VDC-vlan-808/natpol-PF-vlan-808-10-102-196-232/rule-Rule-vlan-808-15,
  
 org-root/org-vlan-808/org-VDC-vlan-808/natpol-PF-vlan-808-10-102-196-232/rule-Rule-vlan-808-16
  with same order 102,wait:0}}] }
 2013-05-20 16:45:33,647 DEBUG [agent.transport.Request] 
 (Job-Executor-81:job-48) Seq 5-1754464294: Received:  { Ans: , MgmtId: 
 214053811722752, via: 5, Ver: v1, Flags: 10, { Answer } }
 2013-05-20 16:45:33,647 DEBUG [agent.manager.AgentManagerImpl] 
 (Job-Executor-81:job-48) Details from executing class 
 com.cloud.agent.api.routing.SetPortForwardingRulesCommand: 
 SetPortForwardingRulesCommand failed due to Policy has two rules 
 org-root/org-vlan-808/org-VDC-vlan-808/natpol-PF-vlan-808-10-102-196-232/rule-Rule-vlan-808-15,
  
 org-root/org-vlan-808/org-VDC-vlan-808/natpol-PF-vlan-808-10-102-196-232/rule-Rule-vlan-808-16
  with same order 102
 2013-05-20 16:45:33,647 ERROR [network.element.CiscoVnmcElement] 
 (Job-Executor-81:job-48) Unable to apply port forwarding rules to Cisco ASA 
 1000v appliance due to: SetPortForwardingRulesCommand failed due to Policy 
 has two rules

[jira] [Created] (CLOUDSTACK-2618) Nicira NVP Nat Rules implementation is not compatible with NVP version 3.x.x

Hugo Trippaers created CLOUDSTACK-2618:
--

 Summary: Nicira NVP Nat Rules implementation is not compatible 
with NVP version 3.x.x
 Key: CLOUDSTACK-2618
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2618
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Devices
Affects Versions: 4.1.0
Reporter: Hugo Trippaers
Assignee: Hugo Trippaers
 Fix For: 4.1.0


Nicira released version 3.x.x a while ago which made some changes to the API 
regarding the configuration of NAT rules.

The NiciraNvpApi needs to be modified to adapt these changes. NiciraNvpApi will 
not be backwards compatible for this change as no version of CloudStack with 
the features has been released so we can safely support only the 3.x.x versions 
of NVP.

--
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-2618) Nicira NVP Nat Rules implementation is not compatible with NVP version 3.x.x


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

Hugo Trippaers commented on CLOUDSTACK-2618:


Fixed in master with commit 4e090796408152af5c06ce72f346ee9ea5d4d404

 Nicira NVP Nat Rules implementation is not compatible with NVP version 3.x.x
 

 Key: CLOUDSTACK-2618
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2618
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Devices
Affects Versions: 4.1.0
Reporter: Hugo Trippaers
Assignee: Hugo Trippaers
 Fix For: 4.1.0


 Nicira released version 3.x.x a while ago which made some changes to the API 
 regarding the configuration of NAT rules.
 The NiciraNvpApi needs to be modified to adapt these changes. NiciraNvpApi 
 will not be backwards compatible for this change as no version of CloudStack 
 with the features has been released so we can safely support only the 3.x.x 
 versions of NVP.

--
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-2619) Volume created from Snapshot does not attach to the VM.fails with NPE.

2013-05-22 Thread Kiran Koneti (JIRA)

Kiran Koneti created CLOUDSTACK-2619:


 Summary: Volume created from Snapshot does not attach to the 
VM.fails with NPE.
 Key: CLOUDSTACK-2619
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2619
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Volumes
Affects Versions: 4.2.0
Reporter: Kiran Koneti
Priority: Critical
 Fix For: 4.2.0


1)Create a VMware Advanced Zone setup.
2)Once the Builtin template is downloaded then created a Vm and took snapshot 
for the same.
3)Created a volume from the snapshot created in the step 2.
4) I see the volume creation was successful in the UI.
5)Tried to check the volume details but couldn't find it either in primary nor 
in secondary storage.
6)Observed the Volumes details in the DB and it shows state as allocated and 
the Location as Null.

*** 6. row ***
id: 6
account_id: 2
 domain_id: 1
   pool_id: NULL
  last_pool_id: NULL
   instance_id: NULL
 device_id: NULL
  name: CreatedVolume
  uuid: 858d9047-899b-4d2a-95fe-d1ac33154aa8
  size: 2147483648
folder: NULL
  path: c394b91e99774acd8e9c30f890d3
pod_id: NULL
data_center_id: 1
iscsi_name: NULL
   host_ip: NULL
   volume_type: DATADISK
 pool_type: NULL
  disk_offering_id: 2
   template_id: 7
first_snapshot_backup_uuid: NULL
   recreatable: 0
   created: 2013-05-22 14:18:28
  attached: NULL
   updated: 2013-05-22 14:18:28
   removed: NULL
 state: Allocated
chain_info: NULL
  update_count: 0
 disk_type: NULL
display_volume: 1
6 rows in set (0.00 sec)

Then I tried to attach this volume to a VM and it fails with an NPE as 
mentioned below

2013-05-22 20:16:02,983 DEBUG [agent.transport.Request] (DirectAgent-202:null) 
Seq 1-1002242356: Processing:  { Ans: , MgmtId: 6703101771911, via: 1, Ver: v1, 
Flags: 110, 
[{storage.CreateAnswer:{volume:{id:6,name:CreatedVolume,mountPoint:/export/home/kiran/p1,path:a300f5598c63435c948deb4cc313a4b7,size:2147483648,type:DATADISK,storagePoolType:NetworkFilesystem,storagePoolUuid:b4825bd6-2b6d-33ef-b324-bfbbec982716,deviceId:0},requestTemplateReload:false,result:true,wait:0}}]
 }
2013-05-22 20:16:02,985 DEBUG [agent.transport.Request] 
(Job-Executor-17:job-17) Seq 1-1002242356: Received:  { Ans: , MgmtId: 
6703101771911, via: 1, Ver: v1, Flags: 110, { CreateAnswer } }
2013-05-22 20:16:02,990 DEBUG [agent.manager.AgentAttache] 
(DirectAgent-202:null) Seq 1-1002242356: No more commands found
2013-05-22 20:16:03,062 ERROR [cloud.async.AsyncJobManagerImpl] 
(Job-Executor-17:job-17) Unexpected exception while executing 
org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
java.lang.NullPointerException
at 
com.cloud.storage.VolumeManagerImpl.needMoveVolume(VolumeManagerImpl.java:1500)
at 
com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1730)
at 
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at 
org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:122)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
at 
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
2013-05-22 20:16:03,065 DEBUG [cloud.async.AsyncJobManagerImpl] 
(Job-Executor-17:job-17) Complete async job-17, jobStatus: 2, resultCode: 530, 
result: Error Code: 530 Error text: null


Attaching the management server logs.

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

[jira] [Resolved] (CLOUDSTACK-2472) test_project_limits.py : Unresolved reference to max_value


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

Girish Shilamkar resolved CLOUDSTACK-2472.
--

Resolution: Fixed

 test_project_limits.py : Unresolved reference to max_value
 --

 Key: CLOUDSTACK-2472
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2472
 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: Girish Shilamkar
Priority: Critical
 Fix For: 4.2.0


 def test_01_project_limits(self):
 with self.assertRaises(Exception):
 self.debug(
 Attempting to update project: %s resource limit to: %s 
 % (
 project.id,
 max_value
 ))

--
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-2472) test_project_limits.py : Unresolved reference to max_value


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

Girish Shilamkar closed CLOUDSTACK-2472.



 test_project_limits.py : Unresolved reference to max_value
 --

 Key: CLOUDSTACK-2472
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2472
 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: Girish Shilamkar
Priority: Critical
 Fix For: 4.2.0


 def test_01_project_limits(self):
 with self.assertRaises(Exception):
 self.debug(
 Attempting to update project: %s resource limit to: %s 
 % (
 project.id,
 max_value
 ))

--
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-2473) test_vpc_network.py : unresolved reference to vm_3

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


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

Girish Shilamkar resolved CLOUDSTACK-2473.
--

Resolution: Fixed

 test_vpc_network.py : unresolved reference to vm_3
 --

 Key: CLOUDSTACK-2473
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2473
 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: Girish Shilamkar
Priority: Critical
 Fix For: 4.2.0


   self.debug(Checking if we can SSH into VM using NAT rule?)
 try:
 ssh_3 = vm_3.get_ssh_client( -unresolved reference
 ipaddress=public_ip_3.ipaddress.ipaddress,
 reconnect=True,
 port=self.services[natrule][publicport]
 )
 self.debug(SSH into VM is successfully)

--
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-2577) Marvin listPortForwardingRules API file has spurious class definition


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

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

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

CLOUDSTACK-2577: Fix exception handling for listPortForwarding API

listPortForwarding API returns an exception if the PF is deleted.
Changed testcases to handle this exception.

Signed-off-by: Girish Shilamkar gir...@clogeny.com
Signed-off-by: Prasanna Santhanam t...@apache.org


 Marvin listPortForwardingRules API file has spurious class definition
 -

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

 Tests using listportforwardingrules are failing with latest marvin.
 listportforwardingrules failed, due to: errorCode: 431, errorText:Unable to 
 execute API command listportforwardingrules due to invalid value. Invalid 
 parameter id value=c9373d55-3d01-480d-98dc-2365d3927378 due to incorrect long 
 value format, or entity does not exist or due to incorrect parameter 
 annotation for the field in api cmd class.
 I checked the  listPortForwardingRules.py and found that class tags was 
 added to this file resulting in the above failure.

--
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-2577) Marvin listPortForwardingRules API file has spurious class definition


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

Girish Shilamkar resolved CLOUDSTACK-2577.
--

Resolution: Fixed

 Marvin listPortForwardingRules API file has spurious class definition
 -

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

 Tests using listportforwardingrules are failing with latest marvin.
 listportforwardingrules failed, due to: errorCode: 431, errorText:Unable to 
 execute API command listportforwardingrules due to invalid value. Invalid 
 parameter id value=c9373d55-3d01-480d-98dc-2365d3927378 due to incorrect long 
 value format, or entity does not exist or due to incorrect parameter 
 annotation for the field in api cmd class.
 I checked the  listPortForwardingRules.py and found that class tags was 
 added to this file resulting in the above failure.

--
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-2577) Marvin listPortForwardingRules API file has spurious class definition

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


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

Girish Shilamkar closed CLOUDSTACK-2577.



 Marvin listPortForwardingRules API file has spurious class definition
 -

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

 Tests using listportforwardingrules are failing with latest marvin.
 listportforwardingrules failed, due to: errorCode: 431, errorText:Unable to 
 execute API command listportforwardingrules due to invalid value. Invalid 
 parameter id value=c9373d55-3d01-480d-98dc-2365d3927378 due to incorrect long 
 value format, or entity does not exist or due to incorrect parameter 
 annotation for the field in api cmd class.
 I checked the  listPortForwardingRules.py and found that class tags was 
 added to this file resulting in the above failure.

--
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-2606) [Multiple_IP_Ranges]Syntax error in dnsmasq config file

2013-05-22 Thread Sanjeev N (JIRA)


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

Sanjeev N closed CLOUDSTACK-2606.
-


Verified on latest master build: CloudStack-non-OSS-MASTER-394-rhel6.3.tar.gz

Works fine.

 [Multiple_IP_Ranges]Syntax error in dnsmasq config file
 ---

 Key: CLOUDSTACK-2606
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2606
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.0
 Environment: Latest build from master branch: 
 CloudStack-non-OSS-MASTER-389-rhel6.3.tar.gz
Reporter: Sanjeev N
Assignee: Bharat Kumar
Priority: Blocker
 Fix For: 4.2.0


 Syntax error in dnsmasq config file while deploying vm in a new subnet
 Steps to Reproduce:
 =
 1.Bring up CS in basic zone with xen61 server.
 2.Add guest ip range in a different cidr compared to what was given during 
 zone deployment.
 3.Try to deploy vm using the ip address from new cidr
 Expected Result:
 ==
 When CS tries to deploy guest vm with the ip from new CIDR an ip alias should 
 be created on domR and dnsmosq conf should be updated with new cidr info and 
 dnsmasq should be reloaded.
 Actual Result:
 
 On domR ip alias was created but observed syntax error in dnsmasq.conf file 
 due to which dnsmosq reload failed and vm deployment also failed.
 Observations:
 ===
 Log snippet from SMlog on xenserver:
 [11043] 2013-05-21 10:58:12.504281  ['bin/bash', 
 '/opt/xensource/bin/createipAlias.sh', '169.254.2.135', 
 '18:10.147.43.132:255.255.255.192-']
 [11043] 2013-05-21 10:58:12.672381   VMOPS exit  createipAlias 
 [11069] 2013-05-21 10:58:12.885267   VMOPS enter  createFileInDomr 
 
 [11069] 2013-05-21 10:58:12.885349  ['mktemp']
 [11069] 2013-05-21 10:58:12.893460pread SUCCESS
 [11069] 2013-05-21 10:58:12.893615  ['scp', '-P', '3922', '-q', '-o', 
 'StrictHostKeyChecking=no', '-i', '/root/.ssh/id_rsa.cloud', 
 '/tmp/tmp.wFgGq11070', 'root@169.254.2.135:/tmp/169-254-2-135.cfg']
 [11069] 2013-05-21 10:58:13.023282pread SUCCESS
 [11069] 2013-05-21 10:58:13.023388  ['rm', '/tmp/tmp.wFgGq11070']
 [11069] 2013-05-21 10:58:13.031616pread SUCCESS
 [11069] 2013-05-21 10:58:13.031712   VMOPS exit  createFileInDomr 
 [11076] 2013-05-21 10:58:13.148401   VMOPS enter  configdnsmasq 
 [11076] 2013-05-21 10:58:13.148491  ['ssh', '-p', '3922', '-q', '-o', 
 'StrictHostKeyChecking=no', '-i', '/root/.ssh/id_rsa.cloud', 
 'root@169.254.2.135', '/root/dnsmasq.sh', '/tmp/169-254-2-135.cfg']
 [11076] 2013-05-21 10:58:13.332322  FAILED in util.pread: (rc 2) stdout: 
 '/tmp/169-254-2-135.cfg
 Restarting DNS forwarder and DHCP server: configuration syntax check failed!
 could not configure dnsmasq
 reverting to the old config
 Restarting DNS forwarder and DHCP server: configuration syntax check failed!
 ', stderr: '+ cp /etc/dnsmasq.conf /etc/dnsmasq.conf.bak
 + echo /tmp/169-254-2-135.cfg
 + cp /tmp/169-254-2-135.cfg /etc/dnsmasq.conf
 + service dnsmasq restart
 + result=1
 + '[' 1 -ne 0 ']'
 + echo 'could not configure dnsmasq'
 + echo 'reverting to the old config'
 + cp /etc/dnsmasq.config.bak /etc/dnsmasq.conf
 cp: cannot stat `/etc/dnsmasq.config.bak': No such file or directory
 + service dnsmasq restart
 + exit 2
 '
 [11076] 2013-05-21 10:58:13.332471  failed to config dnsmasq server
 2.Ran dnsmasq --test on dnsmasq.conf file and found syntax error 
 dhcp-option=6,10.103.128.16,10.103.128.16,*
 Syntax check on dnsmasq.conf failed because of the * at the end of the line 
 and failed to load the config.

--
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-2360) [GSLB] listnetscalerloadbalancerresponse is not including any information about GSLB status


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

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

Commit 62d320454a5487dac27631d380cd0cc0e2492e22 in branch refs/heads/master 
from Murali Reddy muralimmre...@gmail.com
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=62d3204 ]

CLOUDSTACK-2360: listnetscalerloadbalancerresponse is not including any
information about GSLB status

adds the infomration if NetScaler is provisioned as GSLB service
provider


 [GSLB] listnetscalerloadbalancerresponse is not including any information 
 about GSLB status 
 

 Key: CLOUDSTACK-2360
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2360
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.2.0
 Environment: commit # 09af15035b9febe6f55e73a1389f950ab042564f
Reporter: venkata swamybabu budumuru
Assignee: Murali Reddy
Priority: Minor
 Fix For: 4.2.0

 Attachments: Screen Shot 2013-05-07 at 8.32.33 PM.png


 Steps to reproduce :
 1. Have at least one zone added with Netscaler which is enabled for GSLB
 2. Try the API listNetscalerLoadBalancers
 Observations :
 (i) Response doesn't say anything about whether it is enabled for GSLB or not 
 hence, there is no easy for admin to find out which is enabled for GSLB.
  _1367938505962
 command   listNetscalerLoadBalancers
 lbdeviceid5aa83e8a-05b5-45f4-9365-a2ee5dae633f
 response  json
 sessionkeyeWjPdeePdoTOvEGKCeGKzZQxqCc=
 { listnetscalerloadbalancerresponse : { count:1 ,netscalerloadbalancer 
 : [  
 {lbdeviceid:5aa83e8a-05b5-45f4-9365-a2ee5dae633f,physicalnetworkid:a7d374d6-fc84-4b16-8be4-9778230cbaac,provider:Netscaler,lbdevicename:NetscalerVPXLoadBalancer,lbdevicestate:Enabled,lbdevicecapacity:50,lbdevicededicated:false,ipaddress:10.147.44.5,podids:[]}
  ] } }
 Attaching the screenshot of the same.

--
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-2360) [GSLB] listnetscalerloadbalancerresponse is not including any information about GSLB status

2013-05-22 Thread Murali Reddy (JIRA)


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

Murali Reddy reassigned CLOUDSTACK-2360:


Assignee: Jessica Wang  (was: Murali Reddy)


Jessica can you please expose new parameters in the UI?

Netscaler response will have 'gslbprovider', 'gslbproviderpublicip', 
'gslbproviderprivateip' with commit 62d320454a5487dac27631d380cd0cc0e2492e22. 
Response would look like below

{ listnetscalerloadbalancerresponse : { count:1 ,netscalerloadbalancer : 
[  
{lbdeviceid:19587c18-edb2-4cb3-86f6-94c167fc5284,physicalnetworkid:0ce9bc63-82cd-46bc-bcf0-7a4fe05cd326,provider:Netscaler,lbdevicename:NetscalerVPXLoadBalancer,lbdevicestate:Enabled,lbdevicecapacity:100,lbdevicededicated:false,ipaddress:10.147.28.198,gslbprovider:true,gslbproviderpublicip:10.147.28.196,gslbproviderprivateip:10.147.28.196,podids:[]}
 ] } }

 [GSLB] listnetscalerloadbalancerresponse is not including any information 
 about GSLB status 
 

 Key: CLOUDSTACK-2360
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2360
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.2.0
 Environment: commit # 09af15035b9febe6f55e73a1389f950ab042564f
Reporter: venkata swamybabu budumuru
Assignee: Jessica Wang
Priority: Minor
 Fix For: 4.2.0

 Attachments: Screen Shot 2013-05-07 at 8.32.33 PM.png


 Steps to reproduce :
 1. Have at least one zone added with Netscaler which is enabled for GSLB
 2. Try the API listNetscalerLoadBalancers
 Observations :
 (i) Response doesn't say anything about whether it is enabled for GSLB or not 
 hence, there is no easy for admin to find out which is enabled for GSLB.
  _1367938505962
 command   listNetscalerLoadBalancers
 lbdeviceid5aa83e8a-05b5-45f4-9365-a2ee5dae633f
 response  json
 sessionkeyeWjPdeePdoTOvEGKCeGKzZQxqCc=
 { listnetscalerloadbalancerresponse : { count:1 ,netscalerloadbalancer 
 : [  
 {lbdeviceid:5aa83e8a-05b5-45f4-9365-a2ee5dae633f,physicalnetworkid:a7d374d6-fc84-4b16-8be4-9778230cbaac,provider:Netscaler,lbdevicename:NetscalerVPXLoadBalancer,lbdevicestate:Enabled,lbdevicecapacity:50,lbdevicededicated:false,ipaddress:10.147.44.5,podids:[]}
  ] } }
 Attaching the screenshot of the same.

--
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-2622) createipAlias.sh/deleteipAliash.sh should not be allowed with Isolated Guest Networks

2013-05-22 Thread Sailaja Mada (JIRA)


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

Sailaja Mada updated CLOUDSTACK-2622:
-

Fix Version/s: 4.2.0

 createipAlias.sh/deleteipAliash.sh should not be allowed with Isolated Guest 
 Networks 
 --

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


 Setup:  Advanced Networking Zone - VLAN Isolation 
 Steps:
 1. Configured Advanced Networking zone with VLAN isolation 
 2. Create Guest network with default isolated network offering
 3. Deploy VM using this network.
 Observation.
 1. While deploying the network , Observed that 
 createipAlias.sh/deleteipAliash.sh  scripts are being executed and  it failed 
 with script not found errors.
 These scripts are added for the feature : CLOUDSTACK-702: Multiple ip ranges 
 in different subnets.
 This feature is for adding Guest IP range in Basic Zone,Shared Network, 
 Advanced Zone with SG.
 These scripts  should not be allowed with Isolated Guest Networks 
 2013-05-22 11:28:30,046 INFO  [vmware.resource.VmwareResource] 
 (DirectAgent-293:10.102.192.18) Executing resource NetworkUsageCommand
 2013-05-22 11:28:31,312 INFO  [vmware.resource.VmwareResource] 
 (DirectAgent-293:10.102.192.18) Executing deleteipAlias command: 
 {routerip:10.0.64.209,deleteIpAliasTOs:[],createIpAliasTos:[],accessDetails:{router.guest.ip:10.0.64.209,zone.network.type:Advanced,router.name:r-5-VM,router.ip:10.102.195.142},wait:0}
 2013-05-22 11:28:31,312 DEBUG [vmware.resource.VmwareResource] 
 (DirectAgent-293:10.102.192.18) Run command on domR 10.102.195.142, 
 /root/deleteipAlias 10.102.195.142
 2013-05-22 11:28:31,312 DEBUG [vmware.resource.VmwareResource] 
 (DirectAgent-293:10.102.192.18) Use router's private IP for SSH control. IP : 
 10.102.195.142
 2013-05-22 11:28:32,251 DEBUG [cloud.server.StatsCollector] 
 (StatsCollector-1:null) VmStatsCollector is running...
 2013-05-22 11:28:32,264 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-326:null) Seq 1-1877950679: Executing request
 2013-05-22 11:28:32,372 DEBUG [vmware.mo.HostMO] 
 (DirectAgent-326:10.102.192.18) find VM i-3-4-VM on host
 2013-05-22 11:28:32,372 DEBUG [vmware.mo.HostMO] 
 (DirectAgent-326:10.102.192.18) load VM cache on host
 2013-05-22 11:28:32,389 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-326:null) Seq 1-1877950679: Response Received:
 2013-05-22 11:28:32,389 DEBUG [agent.transport.Request] 
 (StatsCollector-1:null) Seq 1-1877950679: Received:  { Ans: , MgmtId: 
 214053811722752, via: 1, Ver: v1, Flags: 10, { GetVmStatsAnswer } }
 2013-05-22 11:28:32,576 ERROR [utils.ssh.SshHelper] 
 (DirectAgent-293:10.102.192.18) SSH execution of command 
 /root/deleteipAlias.sh 10.102.195.142   has an error status code in return. 
 result output: bash: /root/deleteipAlias.sh: No such file or directory
 2013-05-22 11:28:32,577 ERROR [vmware.resource.VmwareResource] 
 (DirectAgent-293:10.102.192.18) ipAlias command on domr 10.102.195.142 
 failed, message: bash: /root/deleteipAlias.sh: No such file or directory

--
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-2623) AWSAPI - Translate CS error to appropriate AWS EC2 error codes

2013-05-22 Thread Likitha Shetty (JIRA)

Likitha Shetty created CLOUDSTACK-2623:
--

 Summary: AWSAPI - Translate CS error to appropriate AWS EC2 error 
codes
 Key: CLOUDSTACK-2623
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2623
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: AWSAPI
Affects Versions: 4.1.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
 Fix For: 4.2.0


When CS AWSAPI errors out for any API the error code is CS error code and not 
AWS EC2 error codes.
Translate the CS error to AWS EC2 error codes whenever applicable for all 
supported AWS EC2 APIs in CS.

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

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

2013-05-22 Thread Likitha Shetty (JIRA)

Likitha Shetty created CLOUDSTACK-2624:
--

 Summary: AWSAPI - Support ModifyInstanceAttribute API
 Key: CLOUDSTACK-2624
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2624
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: AWSAPI
Affects Versions: 4.1.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
 Fix For: 4.2.0


It is not possible to change the resources assigned to a VM using the AWS API 
since we do not currently support ModifyInstanceAttribute API in CS AWSAPI

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

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

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


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

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

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

CLOUDSTACK-2623. Provide appropriate AWS EC2 error codes in error thrown by CS 
AWSAPI. Since CS has very few generic errorcode groups, in AWSAPI parse the 
response message and translate the CS error to AWS EC2 error code.
Provide support for the following error codes -
AuthFailure, DependencyViolation, IncorrectState, InvalidAMIID.NotFound, 
InvalidAttachment.NotFound, InvalidDevice.InUse, InvalidFilter, 
InvalidGroup.Duplicate, InvalidGroup.InUse, InvalidGroup.NotFound
InvalidInstanceID.NotFound, InvalidKeyPair.Duplicate, InvalidKeyPair.Format, 
InvalidKeyPair.NotFound, InvalidParameterCombinatio, InvalidParameterValue, 
InvalidPermission.Duplicate, InvalidPermission.Malformed
InvalidSnapshot.NotFound, InvalidVolume.NotFound, InvalidVolumeID.Duplicate, 
InvalidZone.NotFound, MissingParameter, UnsupportedOperation, 
SignatureDoesNotMatch, InternalError, AddressLimitExceeded, 
InstanceLimitExceeded
VolumeLimitExceeded, Unavailable, ResourceLimitExceeded

CLOUDSTACK-2624. Support ModifyInstanceAttribute API in AWSAPI.
2 AWS instance attributes will be supported, 'InstanceType' and 'UserData'
As per AWS EC2, to modify both the attributes, the instance must be stopped. If 
not throw 'IncorrectInstanceState' error


 AWSAPI - Translate CS error to appropriate AWS EC2 error codes
 --

 Key: CLOUDSTACK-2623
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2623
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: AWSAPI
Affects Versions: 4.1.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
 Fix For: 4.2.0


 When CS AWSAPI errors out for any API the error code is CS error code and not 
 AWS EC2 error codes.
 Translate the CS error to AWS EC2 error codes whenever applicable for all 
 supported AWS EC2 APIs in CS.

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

[jira] [Resolved] (CLOUDSTACK-2602) XenServerStorageMotionStrategy returns true for canHandle even though hosts are of different hypervisor type.

2013-05-22 Thread Devdeep Singh (JIRA)


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

Devdeep Singh resolved CLOUDSTACK-2602.
---

Resolution: Fixed

 XenServerStorageMotionStrategy returns true for canHandle even though hosts 
 are of different hypervisor type.
 -

 Key: CLOUDSTACK-2602
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2602
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Storage Controller, XenServer
Affects Versions: 4.2.0
Reporter: Sateesh Chodapuneedi
Assignee: Devdeep Singh
 Fix For: 4.2.0


 XenServerStorageMotionStrategy returns true for canHandle even though hosts 
 are of different hypervisor type. Due to thie live migration of VM with 
 storage fails for other hypervisors with UnsupportedAnswer exception.

--
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-2625) Duplicate usage records when listing large number of records

2013-05-22 Thread Kishan Kavala (JIRA)

Kishan Kavala created CLOUDSTACK-2625:
-

 Summary: Duplicate usage records when listing large number of 
records
 Key: CLOUDSTACK-2625
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2625
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Usage
Reporter: Kishan Kavala
 Fix For: 4.2.0


listUsageRecords sorts results by start_date. Using pagination, sa,ple mysql 
query is as follows.

SELECT cloud_usage.id, cloud_usage.zone_id, cloud_usage.account_id,
cloud_usage.domain_id, cloud_usage.description, cloud_usage.usage_display,
cloud_usage.usage_type, cloud_usage.raw_usage, cloud_usage.vm_instance_id,
cloud_usage.vm_name, cloud_usage.offering_id, cloud_usage.template_id,
cloud_usage.usage_id, cloud_usage.type, cloud_usage.size,
cloud_usage.virtual_size, cloud_usage.network_id, cloud_usage.start_date,
cloud_usage.end_date FROM cloud_usage WHERE cloud_usage.usage_type = 9  AND
cloud_usage.start_date BETWEEN '2012-01-01 00:00:00' AND '2013-01-31 23:59:59' 
AND cloud_usage.end_date BETWEEN '2012-01-01 00:00:00' AND '2013-01-31
23:59:59'  ORDER BY cloud_usage.start_date DESC  LIMIT 18000, 2000

start_date is not unique and when querying large datasets, multiple pages can 
return the same data.
ORDER BY cloud_usage.start_date doesn't create a stable sorted dataset.

Query should include id in ORDER BY to make it stable.




--
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-2625) Duplicate usage records when listing large number of records

2013-05-22 Thread Kishan Kavala (JIRA)


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

Kishan Kavala commented on CLOUDSTACK-2625:
---

Also, it is better to have order by asc. Records can change while querying 
subsequent pages. 

 Duplicate usage records when listing large number of records
 

 Key: CLOUDSTACK-2625
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2625
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Usage
Reporter: Kishan Kavala
 Fix For: 4.2.0


 listUsageRecords sorts results by start_date. Using pagination, sa,ple mysql 
 query is as follows.
 SELECT cloud_usage.id, cloud_usage.zone_id, cloud_usage.account_id,
 cloud_usage.domain_id, cloud_usage.description, cloud_usage.usage_display,
 cloud_usage.usage_type, cloud_usage.raw_usage, cloud_usage.vm_instance_id,
 cloud_usage.vm_name, cloud_usage.offering_id, cloud_usage.template_id,
 cloud_usage.usage_id, cloud_usage.type, cloud_usage.size,
 cloud_usage.virtual_size, cloud_usage.network_id, cloud_usage.start_date,
 cloud_usage.end_date FROM cloud_usage WHERE cloud_usage.usage_type = 9  AND
 cloud_usage.start_date BETWEEN '2012-01-01 00:00:00' AND '2013-01-31 
 23:59:59' 
 AND cloud_usage.end_date BETWEEN '2012-01-01 00:00:00' AND '2013-01-31
 23:59:59'  ORDER BY cloud_usage.start_date DESC  LIMIT 18000, 2000
 start_date is not unique and when querying large datasets, multiple pages can 
 return the same data.
 ORDER BY cloud_usage.start_date doesn't create a stable sorted dataset.
 Query should include id in ORDER BY to make it stable.

--
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-2330) [Automation]QEMU domains crash and report to be tainted


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

Rajesh Battala commented on CLOUDSTACK-2330:


I had cleaned the primary storage and setup cloudstack with KVM only.
System VM's came up without any issues and Instance got deployed.
I had observed Tainted  warnings in libvirtd log but they are not causing any 
issues. Setup is working fine on the latest master.

Attaching the screenshot. 

 [Automation]QEMU domains crash and report to be tainted
 ---

 Key: CLOUDSTACK-2330
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2330
 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: KVM, 
 Master build
Reporter: Rayees Namathponnan
Assignee: Rajesh Battala
Priority: Blocker
 Fix For: 4.2.0

 Attachments: CLOUDSTACK-2330.rar, CLOUDSTACK-2330.zip


 Automation running on KVM with advanced zone,VR deployment failing during 
 automation run
 Observed  below error in MS log,  attaching MS and agent log
 2013-05-04 13:43:13,032 DEBUG 
 [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-99:job-369) 
 Reapplying vm data (userData and metaData) entries as a part of domR
 VM[DomainRouter|r-155-VM] start...
 2013-05-04 13:43:13,040 DEBUG [agent.transport.Request] 
 (Job-Executor-99:job-369) Seq 4-98894092: Sending  { Cmd , MgmtId: 
 29066118877352, via: 4, Ver: v1, Flags: 100111, [{Sta
 rtCommand:{vm:{id:155,name:r-155-VM,type:DomainRouter,cpus:1,minSpeed:500,maxSpeed:500,minRam:134217728,maxRam:134217728,arch:x86_64,os:Debian
  GNU/
 Linux 5.0 (32-bit),bootArgs: template=domP name=r-155-VM 
 eth2ip=10.223.122.89 eth2mask=255.255.255.192 gateway=10.223.122.65 
 eth0ip=10.1.1.1 eth0mask=255.255.255.0 domain=cs
 2auto.advanced dhcprange=10.1.1.1 eth1ip=169.254.3.220 eth1mask=255.255.0.0 
 type=router disable_rp_filter=true 
 dns1=72.52.126.11,rebootOnCrash:false,enableHA:true,limitCpu
 Use:false,vncPassword:a3b0c243e954e90e,params:{},uuid:f114bcc5-1f3f-4fcb-85f7-3ed9d40467dc,disks:[{id:155,name:ROOT-155,size:741212160,type:ROOT,storag
 ePoolType:NetworkFilesystem,storagePoolUuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,deviceId:0}],nics:[{deviceId:2,networkRateMbps:200,defaultNic:true,uuid:1dee
 a081-1ca4-4af5-ba98-bdac0dac722f,ip:10.223.122.89,netmask:255.255.255.192,gateway:10.223.122.65,mac:06:31:6c:00:00:52,dns1:72.52.126.11,broadcastType:Vla
 n,type:Public,broadcastUri:vlan://1221,isolationUri:vlan://1221,isSecurityGroupEnabled:false},{deviceId:0,networkRateMbps:200,defaultNic:false,uuid:abb44
 284-bbc9-41e6-a1d5-53b2a9256ee6,ip:10.1.1.1,netmask:255.255.255.0,mac:02:00:71:47:00:02,dns1:72.52.126.11,broadcastType:Vlan,type:Guest,broadcastUri:
 vlan://2354,isolationUri:vlan://2354,isSecurityGroupEnabled:false},{deviceId:1,networkRateMbps:-1,defaultNic:false,uuid:8b060664-4c4f-4f0f-bffc-87871cbab662,ip
 :169.254.3.220,netmask:255.255.0.0,gateway:169.254.0.1,mac:0e:00:a9:fe:03:dc,broadcastType:LinkLocal,type:Control,isSecurityGroupEnabled:false}]},hostI
 p:10.223.50.66,wait:0}},{check.CheckSshCommand:{ip:169.254.3.220,port:3922,interval:6,retries:100,name:r-155-VM,wait:0}},{GetDomRVersionCmd:{accessDeta
 ils:{router.ip:169.254.3.220,router.name:r-155-VM},wait:0}},{},{routing.IpAssocCommand:{ipAddresses:[{accountId:2,publicIp:10.223.122.89,sourceNat:true,a
 dd:true,oneToOneNat:false,firstIP:true,vlanId:1221,vlanGateway:10.223.122.65,vlanNetmask:255.255.255.192,vifMacAddress:06:bb:60:00:00:52,networkRate:200,
 trafficType:Public}],accessDetails:{router.guest.ip:10.1.1.1,zone.network.type:Advanced,router.ip:169.254.3.220,router.name:r-155-VM},wait:0}}]
  }
 2013-05-04 13:43:13,306 DEBUG [agent.transport.Request] 
 (AgentManager-Handler-10:null) Seq 4-98894092: Processing:  { Ans: , MgmtId: 
 29066118877352, via: 4, Ver: v1, Flags: 110,
  
 [{Answer:{result:false,details:com.cloud.utils.exception.CloudRuntimeException:
  org.libvirt.LibvirtException: invalid argument: 
 virStorageVolLookupByName\n\tat com.cloud
 .hypervisor.kvm.storage.LibvirtStorageAdaptor.getVolume(LibvirtStorageAdaptor.java:95)\n\tat
  
 com.cloud.hypervisor.kvm.storage.LibvirtStorageAdaptor.getPhysicalDisk(LibvirtStorag
 eAdaptor.java:390)\n\tat 
 com.cloud.hypervisor.kvm.storage.LibvirtStoragePool.getPhysicalDisk(LibvirtStoragePool.java:123)\n\tat
  com.cloud.hypervisor.kvm.resource.LibvirtComputin
 gResource.createVbd(LibvirtComputingResource.java:3323)\n\tat 
 com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3214)\n\tat
  com.cl

[jira] [Updated] (CLOUDSTACK-2330) [Automation]QEMU domains crash and report to be tainted


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

Rajesh Battala updated CLOUDSTACK-2330:
---

Attachment: deployKVM.png

 [Automation]QEMU domains crash and report to be tainted
 ---

 Key: CLOUDSTACK-2330
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2330
 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: KVM, 
 Master build
Reporter: Rayees Namathponnan
Assignee: Rajesh Battala
Priority: Blocker
 Fix For: 4.2.0

 Attachments: CLOUDSTACK-2330.rar, CLOUDSTACK-2330.zip, deployKVM.png


 Automation running on KVM with advanced zone,VR deployment failing during 
 automation run
 Observed  below error in MS log,  attaching MS and agent log
 2013-05-04 13:43:13,032 DEBUG 
 [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-99:job-369) 
 Reapplying vm data (userData and metaData) entries as a part of domR
 VM[DomainRouter|r-155-VM] start...
 2013-05-04 13:43:13,040 DEBUG [agent.transport.Request] 
 (Job-Executor-99:job-369) Seq 4-98894092: Sending  { Cmd , MgmtId: 
 29066118877352, via: 4, Ver: v1, Flags: 100111, [{Sta
 rtCommand:{vm:{id:155,name:r-155-VM,type:DomainRouter,cpus:1,minSpeed:500,maxSpeed:500,minRam:134217728,maxRam:134217728,arch:x86_64,os:Debian
  GNU/
 Linux 5.0 (32-bit),bootArgs: template=domP name=r-155-VM 
 eth2ip=10.223.122.89 eth2mask=255.255.255.192 gateway=10.223.122.65 
 eth0ip=10.1.1.1 eth0mask=255.255.255.0 domain=cs
 2auto.advanced dhcprange=10.1.1.1 eth1ip=169.254.3.220 eth1mask=255.255.0.0 
 type=router disable_rp_filter=true 
 dns1=72.52.126.11,rebootOnCrash:false,enableHA:true,limitCpu
 Use:false,vncPassword:a3b0c243e954e90e,params:{},uuid:f114bcc5-1f3f-4fcb-85f7-3ed9d40467dc,disks:[{id:155,name:ROOT-155,size:741212160,type:ROOT,storag
 ePoolType:NetworkFilesystem,storagePoolUuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,deviceId:0}],nics:[{deviceId:2,networkRateMbps:200,defaultNic:true,uuid:1dee
 a081-1ca4-4af5-ba98-bdac0dac722f,ip:10.223.122.89,netmask:255.255.255.192,gateway:10.223.122.65,mac:06:31:6c:00:00:52,dns1:72.52.126.11,broadcastType:Vla
 n,type:Public,broadcastUri:vlan://1221,isolationUri:vlan://1221,isSecurityGroupEnabled:false},{deviceId:0,networkRateMbps:200,defaultNic:false,uuid:abb44
 284-bbc9-41e6-a1d5-53b2a9256ee6,ip:10.1.1.1,netmask:255.255.255.0,mac:02:00:71:47:00:02,dns1:72.52.126.11,broadcastType:Vlan,type:Guest,broadcastUri:
 vlan://2354,isolationUri:vlan://2354,isSecurityGroupEnabled:false},{deviceId:1,networkRateMbps:-1,defaultNic:false,uuid:8b060664-4c4f-4f0f-bffc-87871cbab662,ip
 :169.254.3.220,netmask:255.255.0.0,gateway:169.254.0.1,mac:0e:00:a9:fe:03:dc,broadcastType:LinkLocal,type:Control,isSecurityGroupEnabled:false}]},hostI
 p:10.223.50.66,wait:0}},{check.CheckSshCommand:{ip:169.254.3.220,port:3922,interval:6,retries:100,name:r-155-VM,wait:0}},{GetDomRVersionCmd:{accessDeta
 ils:{router.ip:169.254.3.220,router.name:r-155-VM},wait:0}},{},{routing.IpAssocCommand:{ipAddresses:[{accountId:2,publicIp:10.223.122.89,sourceNat:true,a
 dd:true,oneToOneNat:false,firstIP:true,vlanId:1221,vlanGateway:10.223.122.65,vlanNetmask:255.255.255.192,vifMacAddress:06:bb:60:00:00:52,networkRate:200,
 trafficType:Public}],accessDetails:{router.guest.ip:10.1.1.1,zone.network.type:Advanced,router.ip:169.254.3.220,router.name:r-155-VM},wait:0}}]
  }
 2013-05-04 13:43:13,306 DEBUG [agent.transport.Request] 
 (AgentManager-Handler-10:null) Seq 4-98894092: Processing:  { Ans: , MgmtId: 
 29066118877352, via: 4, Ver: v1, Flags: 110,
  
 [{Answer:{result:false,details:com.cloud.utils.exception.CloudRuntimeException:
  org.libvirt.LibvirtException: invalid argument: 
 virStorageVolLookupByName\n\tat com.cloud
 .hypervisor.kvm.storage.LibvirtStorageAdaptor.getVolume(LibvirtStorageAdaptor.java:95)\n\tat
  
 com.cloud.hypervisor.kvm.storage.LibvirtStorageAdaptor.getPhysicalDisk(LibvirtStorag
 eAdaptor.java:390)\n\tat 
 com.cloud.hypervisor.kvm.storage.LibvirtStoragePool.getPhysicalDisk(LibvirtStoragePool.java:123)\n\tat
  com.cloud.hypervisor.kvm.resource.LibvirtComputin
 gResource.createVbd(LibvirtComputingResource.java:3323)\n\tat 
 com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3214)\n\tat
  com.cl
 oud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1172)\n\tat
  com.cloud.agent.Agent.processRequest(Agent.java:525)\n\tat com.clou
 d.agent.Agent$AgentRequestHandler.doTask(Agent.java:852)\n\tat 
 com.cloud.utils.nio.Task.run(Task.java:83)\n\tat 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecu

[jira] [Resolved] (CLOUDSTACK-2330) [Automation]QEMU domains crash and report to be tainted

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


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

Rajesh Battala resolved CLOUDSTACK-2330.


Resolution: Cannot Reproduce

Not able to reproduce on a clean setup.

 [Automation]QEMU domains crash and report to be tainted
 ---

 Key: CLOUDSTACK-2330
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2330
 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: KVM, 
 Master build
Reporter: Rayees Namathponnan
Assignee: Rajesh Battala
Priority: Blocker
 Fix For: 4.2.0

 Attachments: CLOUDSTACK-2330.rar, CLOUDSTACK-2330.zip, deployKVM.png


 Automation running on KVM with advanced zone,VR deployment failing during 
 automation run
 Observed  below error in MS log,  attaching MS and agent log
 2013-05-04 13:43:13,032 DEBUG 
 [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-99:job-369) 
 Reapplying vm data (userData and metaData) entries as a part of domR
 VM[DomainRouter|r-155-VM] start...
 2013-05-04 13:43:13,040 DEBUG [agent.transport.Request] 
 (Job-Executor-99:job-369) Seq 4-98894092: Sending  { Cmd , MgmtId: 
 29066118877352, via: 4, Ver: v1, Flags: 100111, [{Sta
 rtCommand:{vm:{id:155,name:r-155-VM,type:DomainRouter,cpus:1,minSpeed:500,maxSpeed:500,minRam:134217728,maxRam:134217728,arch:x86_64,os:Debian
  GNU/
 Linux 5.0 (32-bit),bootArgs: template=domP name=r-155-VM 
 eth2ip=10.223.122.89 eth2mask=255.255.255.192 gateway=10.223.122.65 
 eth0ip=10.1.1.1 eth0mask=255.255.255.0 domain=cs
 2auto.advanced dhcprange=10.1.1.1 eth1ip=169.254.3.220 eth1mask=255.255.0.0 
 type=router disable_rp_filter=true 
 dns1=72.52.126.11,rebootOnCrash:false,enableHA:true,limitCpu
 Use:false,vncPassword:a3b0c243e954e90e,params:{},uuid:f114bcc5-1f3f-4fcb-85f7-3ed9d40467dc,disks:[{id:155,name:ROOT-155,size:741212160,type:ROOT,storag
 ePoolType:NetworkFilesystem,storagePoolUuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,deviceId:0}],nics:[{deviceId:2,networkRateMbps:200,defaultNic:true,uuid:1dee
 a081-1ca4-4af5-ba98-bdac0dac722f,ip:10.223.122.89,netmask:255.255.255.192,gateway:10.223.122.65,mac:06:31:6c:00:00:52,dns1:72.52.126.11,broadcastType:Vla
 n,type:Public,broadcastUri:vlan://1221,isolationUri:vlan://1221,isSecurityGroupEnabled:false},{deviceId:0,networkRateMbps:200,defaultNic:false,uuid:abb44
 284-bbc9-41e6-a1d5-53b2a9256ee6,ip:10.1.1.1,netmask:255.255.255.0,mac:02:00:71:47:00:02,dns1:72.52.126.11,broadcastType:Vlan,type:Guest,broadcastUri:
 vlan://2354,isolationUri:vlan://2354,isSecurityGroupEnabled:false},{deviceId:1,networkRateMbps:-1,defaultNic:false,uuid:8b060664-4c4f-4f0f-bffc-87871cbab662,ip
 :169.254.3.220,netmask:255.255.0.0,gateway:169.254.0.1,mac:0e:00:a9:fe:03:dc,broadcastType:LinkLocal,type:Control,isSecurityGroupEnabled:false}]},hostI
 p:10.223.50.66,wait:0}},{check.CheckSshCommand:{ip:169.254.3.220,port:3922,interval:6,retries:100,name:r-155-VM,wait:0}},{GetDomRVersionCmd:{accessDeta
 ils:{router.ip:169.254.3.220,router.name:r-155-VM},wait:0}},{},{routing.IpAssocCommand:{ipAddresses:[{accountId:2,publicIp:10.223.122.89,sourceNat:true,a
 dd:true,oneToOneNat:false,firstIP:true,vlanId:1221,vlanGateway:10.223.122.65,vlanNetmask:255.255.255.192,vifMacAddress:06:bb:60:00:00:52,networkRate:200,
 trafficType:Public}],accessDetails:{router.guest.ip:10.1.1.1,zone.network.type:Advanced,router.ip:169.254.3.220,router.name:r-155-VM},wait:0}}]
  }
 2013-05-04 13:43:13,306 DEBUG [agent.transport.Request] 
 (AgentManager-Handler-10:null) Seq 4-98894092: Processing:  { Ans: , MgmtId: 
 29066118877352, via: 4, Ver: v1, Flags: 110,
  
 [{Answer:{result:false,details:com.cloud.utils.exception.CloudRuntimeException:
  org.libvirt.LibvirtException: invalid argument: 
 virStorageVolLookupByName\n\tat com.cloud
 .hypervisor.kvm.storage.LibvirtStorageAdaptor.getVolume(LibvirtStorageAdaptor.java:95)\n\tat
  
 com.cloud.hypervisor.kvm.storage.LibvirtStorageAdaptor.getPhysicalDisk(LibvirtStorag
 eAdaptor.java:390)\n\tat 
 com.cloud.hypervisor.kvm.storage.LibvirtStoragePool.getPhysicalDisk(LibvirtStoragePool.java:123)\n\tat
  com.cloud.hypervisor.kvm.resource.LibvirtComputin
 gResource.createVbd(LibvirtComputingResource.java:3323)\n\tat 
 com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3214)\n\tat
  com.cl
 oud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1172)\n\tat
  com.cloud.agent.Agent.processRequest(Agent.java:525)\n\tat com.clou
 d.agent.Agent$AgentRequestHandler.doTask(Agent.java:852)\n\tat 
 com.cloud.utils.nio.Task.run(Task.java:83)\n\tat

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

2013-05-22 Thread Likitha Shetty (JIRA)


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

Likitha Shetty resolved CLOUDSTACK-2624.


Resolution: Fixed

commit-id: 9a33fd181ffb9d3220edefd1f8d928915b09028a
branch: master

 AWSAPI - Support ModifyInstanceAttribute API
 

 Key: CLOUDSTACK-2624
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2624
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: AWSAPI
Affects Versions: 4.1.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
 Fix For: 4.2.0


 It is not possible to change the resources assigned to a VM using the AWS API 
 since we do not currently support ModifyInstanceAttribute API in CS AWSAPI

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

[jira] [Resolved] (CLOUDSTACK-2553) NTier: Permit Case insensitive Actions for ACL Rules

2013-05-22 Thread Kishan Kavala (JIRA)


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

Kishan Kavala resolved CLOUDSTACK-2553.
---

Resolution: Fixed

 NTier: Permit Case insensitive Actions for ACL Rules
 

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


 allow action had to be specified as Allow during the creation of ACL Rule
 ===
 Observations:
 ===
 2013-05-17 00:49:22,169 DEBUG [cloud.api.ApiServlet] (catalina-exec-4:null) 
 ===START===  10.216.50.223 -- GET  
 command=createNetworkACLprotocol=tcpaclid=62132cc2-bdf0-4248-8b81-7188f38d50e3action=allowcidrlist=10.223.110.232/32startport=22endport=80response=jsonsessionkey=FdsUPSO6Hn50i9jBn9rk91%2BTcyk%3D_=1368776784544
 2013-05-17 00:49:22,207 DEBUG [cloud.user.AccountManagerImpl] 
 (catalina-exec-4:null) Access to Acct[3-atoms] granted to Acct[3-atoms] by 
 DomainChecker_EnhancerByCloudStack_fcb6b9a3
 2013-05-17 00:49:22,210 DEBUG [cloud.user.AccountManagerImpl] 
 (catalina-exec-4:null) Access to [VPC [1-Atoms-VPC-1] granted to 
 Acct[3-atoms] by DomainChecker_EnhancerByCloudStack_fcb6b9a3
 2013-05-17 00:49:22,211 INFO  [cloud.api.ApiServer] (catalina-exec-4:null) 
 Invalid action. Allowed actions are Allow and Deny
 2013-05-17 00:49:22,212 DEBUG [cloud.api.ApiServlet] (catalina-exec-4:null) 
 ===END===  10.216.50.223 -- GET  
 command=createNetworkACLprotocol=tcpaclid=62132cc2-bdf0-4248-8b81-7188f38d50e3action=allowcidrlist=10.223.110.232/32startport=22endport=80response=jsonsessionkey=FdsUPSO6Hn50i9jBn9rk91%2BTcyk%3D_=1368776784544

--
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-681) Dedicate Pod, Cluster or Host to a domain


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

ASF subversion and git services commented on CLOUDSTACK-681:


Commit 49e39e51f2bd39c1e5cd60389f4433d58f9415bc in branch 
refs/heads/vmware-datamodel from [~pranav.sax...@citrix.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=49e39e5 ]

CLOUDSTACK-681:Implicit Dedication UI support


 Dedicate Pod, Cluster or Host to a domain
 -

 Key: CLOUDSTACK-681
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-681
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: pre-4.0.0
Reporter: deepti dohare
Assignee: Devdeep Singh
 Fix For: 4.2.0


 Currently in CloudStack architecture, domains can have dedicated zones but 
 not pods, clusters or hosts. Dedicating a zone might be very expensive 
 offering for an end users, whereas dedicating a pod, cluster or a host may be 
 more economical. 
 This feature will allow Root-Admin to dedicate resources to a specific domain 
 that needs private infrastructure for additional security or performance 
 guarantees.
 Requirements described at: 
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Private+Host%2C+Cluster%2C+Pod
 Release Planning: 
 Dev List Discussion: 
 http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/201212.mbox/browser
 Functional Spec: 
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dedicated+Resources+-+Private+pod%2C+cluster%2C+host+Functional+Spec
 Feature Branch: Will come in as reviews

--
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-2568) ACS41 regression in storage subsystem (seen with local storage and 2 or more hosts)

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


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

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

Commit dce42581710ce3613f4bf765d713fab9552747ca in branch 
refs/heads/vmware-datamodel from Prachi Damle pra...@cloud.com
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=dce4258 ]

CLOUDSTACK-2568: ACS41 regression in storage subsystem (seen with local storage 
and 2 or more hosts)

Changes:
- In VolumeReservationVO, the  getter method of a column had a typo, causing us 
to create a wrong searchbuilder. It was searching over the 'id' column instead 
of 'vm_reservation_id' causing
- This bug was causing the vm deployment to choose a wrong pool during 
deployment since the search was choosing incorrectly
- This bug in the GenericSearchBuilder is also fixed - if the getter method 
does not use the standard 'get' or 'is' prefix, one should annotate that method 
using
 @Column(name = column_name) and indicate which column this method refers 
to. This will cause the GenericSearchBuilder to identify the field correctly.


 ACS41 regression in storage subsystem (seen with local storage and 2 or more 
 hosts)
 ---

 Key: CLOUDSTACK-2568
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2568
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.1.0
 Environment: RHES64 as in OEL64. Install from RPM built from latest 
 GIT on OEL64.
 2 or more KVM hypervisors with local storage in one cluster that has one 
 primary NFS storage pool.
Reporter: Ove Ewerlid
Assignee: Prachi Damle
Priority: Blocker
 Fix For: 4.1.0

 Attachments: var-log-cloudstack-management.tar.gz


 ACS402 works with no issues when tested in exactly the setup where ACS41 
 fails.
 Identical configuration (the same setup program is used for testing both 
 versions).
 In ACS410 startVM fails if and only if the advanceStart: log line picks a 
 poolID that is not valid.
 E.g., the poolID reported in this logline appears random across a large 
 number of tests.
 If a poolID that can not be reached by the host selected for deployment, the 
 startVM fails.
 This is blocking upgrade from 4.0 to 4.1 since there is no  reliable way to 
 start VMs that have been deployed. If a deployed VM fails to start, giving 
 the startVM command multiple times, will eventually make the VM start.
 The more hosts there are, the less likely it is a startVM will succeed. It is 
 less likely that the poolID is correct.
 The below log portion conveys how the VM has a correct Deployment 
 Destination reported and the advanceStart reports a poolID that is different 
 and since the selected hypervisor can not reach the poolID the startVM fails.
 The bug never triggers if there is only one KVM with local storage since the 
 poolId can not be wrong, there is just one (and the NFS pool is always valid).
 ---
 2013-05-20 06:49:29,477 DEBUG [cloud.deploy.FirstFitPlanner] 
 (Job-Executor-34:job-34) Found a potential host id: 1 name: 
 vm3-net0-s0-14.test.devops and associated storage pools for this VM
 2013-05-20 06:49:29,478 DEBUG [cloud.deploy.FirstFitPlanner] 
 (Job-Executor-34:job-34) Returning Deployment Destination: 
 Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type--Pool(Id))]
  : Dest[Zone(1)-Pod(1)-Cluster(1)-Host\
 (1)-Storage(Volume(10|ROOT--Pool(200), Volume(11|DATADISK--Pool(200))]
 2013-05-20 06:49:29,495 DEBUG [cloud.capacity.CapacityManagerImpl] 
 (Job-Executor-34:job-34) VM state transitted from :Stopped to Starting with 
 event: StartRequestedvm's original host id: null new host id: null host id 
 before state trans\
 ition: null
 2013-05-20 06:49:29,495 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (Job-Executor-34:job-34) Successfully transitioned to start state for 
 VM[User|testvm-a] reservation id = e644d55e-3627-4395-9f89-639e6fc2f261
 2013-05-20 06:49:29,502 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (Job-Executor-34:job-34) Trying to deploy VM, vm has dcId: 1 and podId: null
 2013-05-20 06:49:29,502 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (Job-Executor-34:job-34) advanceStart: DeploymentPlan is provided, using 
 dcId:1, podId: 1, clusterId: 1, hostId: 1, poolId: 201
 2013-05-20 06:49:29,502 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (Job-Executor-34:job-34) Deploy avoids pods: null, clusters: null, hosts: null
 2013-05-20 06:49:29,504 DEBUG [cloud.deploy.FirstFitPlanner] 
 (Job-Executor-34:job-34) DeploymentPlanner allocation algorithm: random
 2013-05-20 06:49:29,504

[jira] [Commented] (CLOUDSTACK-2618) Nicira NVP Nat Rules implementation is not compatible with NVP version 3.x.x


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

Hugo Trippaers commented on CLOUDSTACK-2618:


Commit in 4.1 79fd49c18135afc6b48c7037954384a710a638ff

 Nicira NVP Nat Rules implementation is not compatible with NVP version 3.x.x
 

 Key: CLOUDSTACK-2618
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2618
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Devices
Affects Versions: 4.1.0
Reporter: Hugo Trippaers
Assignee: Hugo Trippaers
 Fix For: 4.1.0


 Nicira released version 3.x.x a while ago which made some changes to the API 
 regarding the configuration of NAT rules.
 The NiciraNvpApi needs to be modified to adapt these changes. NiciraNvpApi 
 will not be backwards compatible for this change as no version of CloudStack 
 with the features has been released so we can safely support only the 3.x.x 
 versions of NVP.

--
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-2618) Nicira NVP Nat Rules implementation is not compatible with NVP version 3.x.x


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

Hugo Trippaers resolved CLOUDSTACK-2618.


Resolution: Fixed

 Nicira NVP Nat Rules implementation is not compatible with NVP version 3.x.x
 

 Key: CLOUDSTACK-2618
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2618
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Devices
Affects Versions: 4.1.0
Reporter: Hugo Trippaers
Assignee: Hugo Trippaers
 Fix For: 4.1.0


 Nicira released version 3.x.x a while ago which made some changes to the API 
 regarding the configuration of NAT rules.
 The NiciraNvpApi needs to be modified to adapt these changes. NiciraNvpApi 
 will not be backwards compatible for this change as no version of CloudStack 
 with the features has been released so we can safely support only the 3.x.x 
 versions of NVP.

--
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-2618) Nicira NVP Nat Rules implementation is not compatible with NVP version 3.x.x

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


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

Hugo Trippaers closed CLOUDSTACK-2618.
--


 Nicira NVP Nat Rules implementation is not compatible with NVP version 3.x.x
 

 Key: CLOUDSTACK-2618
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2618
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Devices
Affects Versions: 4.1.0
Reporter: Hugo Trippaers
Assignee: Hugo Trippaers
 Fix For: 4.1.0


 Nicira released version 3.x.x a while ago which made some changes to the API 
 regarding the configuration of NAT rules.
 The NiciraNvpApi needs to be modified to adapt these changes. NiciraNvpApi 
 will not be backwards compatible for this change as no version of CloudStack 
 with the features has been released so we can safely support only the 3.x.x 
 versions of NVP.

--
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-105) /tmp/stream-unix.####.###### stale sockets causing inodes to run out on Xenserver

2013-05-22 Thread Kevin Kluge (JIRA)

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

Kevin Kluge updated CLOUDSTACK-105:
---

Component/s: (was: XenServer)
Third-Party Bugs

/tmp/stream-unix..## stale sockets causing inodes to run out on
Xenserver
-

Key: CLOUDSTACK-105
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-105
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Third-Party Bugs
Affects Versions: pre-4.0.0
Environment: Xenserver 6.0.2
Cloudstack 3.0.2
Reporter: Caleb Call
Assignee: Devdeep Singh
Fix For: 4.1.0

Attachments: messages

We came across an interesting issue in one of our clusters. We ran out of
inodes on all of our cluster members (since when does this happen in 2012?).
When this happened, it in turn made the / filesystem a read-only filesystem
which in turn made all the hosts go in to emergency maintenance mode and as a
result get marked down by Cloudstack. We found that it was caused by
hundreds of thousands of stale socket files in /tmp named
stream-unix..##. To resolve the issue, we had to delete those
stale socket files (find /tmp -name *stream* -mtime +7 -exec rm -v {} \;),
then kill and restart xapi, then correct the emergency maintenance mode.
These hosts had only been up for 45 days before this issue occurred.
In our scouring of the interwebs, the only other instance we've been able to
find of this (or similar) happening is in the same setup we are currently
running. Xenserver 6.0.2 with CS 3.0.2. Do these stream-unix sockets have
anything to do with Cloudstack? I would think if this was a Xenserver issue
(bug), there would be a lot more on the internet about this happening. For a
temporary workaround, we've added a cronjob to cleanup these files but we'd
really like to address the actual issue that's causing these sockets to
become stale and not get cleaned-up.

--
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-105) /tmp/stream-unix.####.###### stale sockets causing inodes to run out on Xenserver

2013-05-22 Thread Kevin Kluge (JIRA)

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

Kevin Kluge commented on CLOUDSTACK-105:

Jason's comment from Dec 5 strongly suggests this is a XenServer 6.0.2 bug. I
have raised the issue with the XenServer engineers. I do not have a public bug
ticket to share.

I don't think there is much that CloudStack can do about this issue so I have
moved it to the Third Party bug component. It would be helpful if we were able
to determine that people running XS 6.1.0 did or did not see this. I never
heard of this in XS 5.6.* so I suspect it is new for XS 6.0.*.

/tmp/stream-unix..## stale sockets causing inodes to run out on
Xenserver
-

Attachments: messages

[jira] [Commented] (CLOUDSTACK-2516) Create User API compability broken now


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

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

Commit bf8b09834fbeb0e67bdf52299ed2d0812844b665 in branch refs/heads/4.1 from 
Chip Childers chipchild...@apache.org
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bf8b098 ]

CLOUDSTACK-2516: Documenting the required components.xml change to deal
with the authenticator behavior changes in 4.1


 Create User API compability broken now
 --

 Key: CLOUDSTACK-2516
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2516
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.1.0, 4.2.0
Reporter: Chip Childers
Assignee: Kishan Kavala
Priority: Blocker
 Fix For: 4.1.0, 4.2.0


 From email thread:
 On Wed, May 15, 2013 at 04:22:14PM +0200, Ove Ewerlid wrote:
  NB; The 402/410 deployments are on RHES64(OEL64) via RPMs built from
  latest git repos.
  /Ove
  
  On 05/15/2013 03:02 PM, Ove Ewerlid wrote:
  Hi!
  
  When testing a deploy script, that works as expected with 4.0.2, on 4.1
  I noticed that there was a need to pass plaintext passwords to
  createUser, rather then the documented MD5 hash. When passing MD5 hash,
  the password gets double MD5:hashed in 41.
  
  There is new code in 4.1 that encodes password using the authenticator
  plugins (encode method);
  
  cloudstack.4.1/server/src/com/cloud/user/AccountManagerImpl.java
  
  ...
  String encodedPassword = null;
   for (UserAuthenticator  authenticator : _userAuthenticators) {
   encodedPassword = authenticator.encode(password);
   if (encodedPassword != null) {
   break;
   }
   }
  ...
  
  The 41 API docs still notes that an MD5 hash shall be passed in.
  What am I missing here?
  
  /Ove

--
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-2516) Create User API compability broken now

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


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

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

Commit e720e8a1a62722c2c032aafe00848079fbd92a03 in branch refs/heads/master 
from Chip Childers chipchild...@apache.org
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e720e8a ]

CLOUDSTACK-2516: Adding upgrade steps to deal with authenticator changes


 Create User API compability broken now
 --

 Key: CLOUDSTACK-2516
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2516
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.1.0, 4.2.0
Reporter: Chip Childers
Assignee: Kishan Kavala
Priority: Blocker
 Fix For: 4.1.0, 4.2.0


 From email thread:
 On Wed, May 15, 2013 at 04:22:14PM +0200, Ove Ewerlid wrote:
  NB; The 402/410 deployments are on RHES64(OEL64) via RPMs built from
  latest git repos.
  /Ove
  
  On 05/15/2013 03:02 PM, Ove Ewerlid wrote:
  Hi!
  
  When testing a deploy script, that works as expected with 4.0.2, on 4.1
  I noticed that there was a need to pass plaintext passwords to
  createUser, rather then the documented MD5 hash. When passing MD5 hash,
  the password gets double MD5:hashed in 41.
  
  There is new code in 4.1 that encodes password using the authenticator
  plugins (encode method);
  
  cloudstack.4.1/server/src/com/cloud/user/AccountManagerImpl.java
  
  ...
  String encodedPassword = null;
   for (UserAuthenticator  authenticator : _userAuthenticators) {
   encodedPassword = authenticator.encode(password);
   if (encodedPassword != null) {
   break;
   }
   }
  ...
  
  The 41 API docs still notes that an MD5 hash shall be passed in.
  What am I missing here?
  
  /Ove

--
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-2626) Automation: multiple IP ranges

2013-05-22 Thread Sudha Ponnaganti (JIRA)

Sudha Ponnaganti created CLOUDSTACK-2626:


 Summary: Automation: multiple IP ranges
 Key: CLOUDSTACK-2626
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2626
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.2.0
Reporter: Sudha Ponnaganti
 Fix For: 4.2.0




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

[jira] [Commented] (CLOUDSTACK-105) /tmp/stream-unix.####.###### stale sockets causing inodes to run out on Xenserver

2013-05-22 Thread Stephen Turner (JIRA)

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

Stephen Turner commented on CLOUDSTACK-105:
---

Could someone who can reproduce this attach a XenServer bugtool (aka Server
Status Report from XenCenter) taken immediately after it occurs? That will
enable us to track this down. Thank you.

/tmp/stream-unix..## stale sockets causing inodes to run out on
Xenserver
-

Attachments: messages

[jira] [Commented] (CLOUDSTACK-2354) Unable to create Windows VMs using ISO

2013-05-22 Thread Stephen Turner (JIRA)

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

Stephen Turner commented on CLOUDSTACK-2354:

Could someone who can reproduce this attach a XenServer bugtool (aka Server
Status Report from XenCenter) taken immediately after it occurs? That will help
us on the XenServer team track this down why this occurs. Thank you.

Unable to create Windows VMs using ISO
--

Key: CLOUDSTACK-2354
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2354
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: ISO
Affects Versions: 4.2.0
Environment: Build No.#256
(CloudStack-non-OSS-MASTER-256-rhel6.3.tar.gz)
XenServer6.1 for Host Server, CentOS6.3 for NFS server and CloudStack-Mgr
Server.
Reporter: Minying Bao
Assignee: Harikrishna Patnala
Priority: Blocker
Fix For: 4.2.0

Attachments: ISO_Win8.jpg, ISO_XP-Auto-Shutdown.JPG.jpg,
ISO_XP_State.JPG.jpg, management-server.log

Repro Steps
Setup the cloudstack environment as normal. (Configured NFS CS-Mgr Servers)
Launch browser, start CloudStack WebConsole and finish to build a cloud step
by step. (It should use workaround of build#256 when building a cloud.)
Register the ISOs to the CloudStack as follows Win7, Win8, 2k8R2, XP. Wait
for Status showing Successfully Installed.
Add instances from all above ISOs.
Expected Result
All the instances should be added successfully, and all the related VMs
should be launched successfully on XenServer Host.
Actual Result
Unable to create Windows VMs using ISO.
VMs based on the Win8/Win7 ISOs - WebConsole show Error (refer to
screenshot ISO_Win8.jpg)
VMs based on the XP/W2k8r2 ISO - WebConsole show Running - Auto-shutdown
during the OS installation - WebConsole show Stopped (refer to screenshots
ISO_XP-Auto-Shutdown.JPG and ISO_XP_State.JPG )

[jira] [Commented] (CLOUDSTACK-105) /tmp/stream-unix.####.###### stale sockets causing inodes to run out on Xenserver

2013-05-22 Thread Caleb Call (JIRA)


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

Caleb Call commented on CLOUDSTACK-105:
---

I'll be happy to attach the dump but this isn't something that just happens.  
It's constantly happening.  In order to avoid our servers from crashing, we 
have to have a cronjob that removes any of these files that are older than a 
couple days old.  I also don't think this is necessarily a Xenserver bug, maybe 
a Xenserver under CloudStack as without joining Xenserver to CloudStack, this 
never happens.  Once it's joined, it starts happening.  I'm also have a 
suspicion it's being caused by this script /etc/xapi.d/plugins/vmops and in 
particular, this part of that script (sorry, I'm sure jira is going to munge 
this output):

 def setLinkLocalIP(session, args):
brName = args['brName']
try:
cmd = [ip, route, del, 169.254.0.0/16]
txt = util.pread2(cmd)
except:
txt = ''
try:
cmd = [ifconfig, brName, 169.254.0.1, netmask, 255.255.0.0]
txt = util.pread2(cmd)
except:
try:
cmd = ['cat', '/etc/xensource/network.conf']
result = util.pread2(cmd)
except:
return 'can not cat network.conf'

if result.lower() == bridge:
try:
cmd = [brctl, addbr, brName]
txt = util.pread2(cmd)
except:
pass

else:
try:
cmd = [ovs-vsctl, add-br, brName]
txt = util.pread2(cmd)
except:
pass

try:
cmd = [ifconfig, brName, 169.254.0.1, netmask, 255.255.0.0]
txt = util.pread2(cmd)
except:
pass
try:
cmd = [ip, route, add, 169.254.0.0/16, dev, brName, src, 
169.254.0.1]
txt = util.pread2(cmd)
except:
txt = ''
txt = 'success'
return txt

 /tmp/stream-unix..## stale sockets causing inodes to run out on 
 Xenserver
 -

 Key: CLOUDSTACK-105
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-105
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Third-Party Bugs
Affects Versions: pre-4.0.0
 Environment: Xenserver 6.0.2
 Cloudstack 3.0.2
Reporter: Caleb Call
Assignee: Devdeep Singh
 Fix For: 4.1.0

 Attachments: messages


 We came across an interesting issue in one of our clusters.  We ran out of 
 inodes on all of our cluster members (since when does this happen in 2012?).  
 When this happened, it in turn made the / filesystem a read-only filesystem 
 which in turn made all the hosts go in to emergency maintenance mode and as a 
 result get marked down by Cloudstack.  We found that it was caused by 
 hundreds of thousands of stale socket files in /tmp named 
 stream-unix..##.  To resolve the issue, we had to delete those 
 stale socket files (find /tmp -name *stream* -mtime +7 -exec rm -v {} \;), 
 then kill and restart xapi, then correct the emergency maintenance mode.  
 These hosts had only been up for 45 days before this issue occurred.  
 In our scouring of the interwebs, the only other instance we've been able to 
 find of this (or similar) happening is in the same setup we are currently 
 running. Xenserver 6.0.2 with CS 3.0.2.  Do these stream-unix sockets have 
 anything to do with Cloudstack?  I would think if this was a Xenserver issue 
 (bug), there would be a lot more on the internet about this happening.  For a 
 temporary workaround, we've added a cronjob to cleanup these files but we'd 
 really like to address the actual issue that's causing these sockets to 
 become stale and not get cleaned-up.

--
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-747) nTier Apps 2.0 : Internal Load Balancing between the VPC tiers

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


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

ASF subversion and git services commented on CLOUDSTACK-747:


Commit c7976b668586181267bf9d8ceba50d194fd96d1c in branch refs/heads/master 
from Jessica Wang jessicaw...@apache.org
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c7976b6 ]

CLOUDSTACK-747: internal LB in VPC - remove module internalLbProvider since 
internalLbVm section has been added in system.js


  nTier Apps 2.0 : Internal Load Balancing between the VPC tiers
 ---

 Key: CLOUDSTACK-747
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-747
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Reporter: Kishan Kavala
Assignee: Brian Federle
 Fix For: 4.2.0


 This item is sub task (2.2) of 
 https://issues.apache.org/jira/browse/CLOUDSTACK-621 
 Currently, Load Balancing VPC VR is only supported on one of the Tiers of an 
 nTier Application. With this release, CloudStack should support load 
 balancing on all tiers of an nTier application.
 Use Case: Users would like to deploy a multi-tier application with the VR 
 load balancing each of the tiers. As a result, users would be able to provide 
 flexibility and elasticity at each tier of their application

--
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-105) /tmp/stream-unix.####.###### stale sockets causing inodes to run out on Xenserver

2013-05-22 Thread Stephen Turner (JIRA)

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

Stephen Turner commented on CLOUDSTACK-105:
---

Thanks for that, Caleb. We'll look into that.

/tmp/stream-unix..## stale sockets causing inodes to run out on
Xenserver
-

Attachments: messages

[jira] [Commented] (CLOUDSTACK-747) nTier Apps 2.0 : Internal Load Balancing between the VPC tiers

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


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

ASF subversion and git services commented on CLOUDSTACK-747:


Commit 8acdd6f4369c334727ac44b519015cd9bd4d25e2 in branch 
refs/heads/ui-vpc-redesign from Jessica Wang jessicaw...@apache.org
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8acdd6f ]

CLOUDSTACK-747: internal LB in VPC - remove module internalLbProvider since 
internalLbVm section has been added in system.js


  nTier Apps 2.0 : Internal Load Balancing between the VPC tiers
 ---

 Key: CLOUDSTACK-747
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-747
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Reporter: Kishan Kavala
Assignee: Brian Federle
 Fix For: 4.2.0


 This item is sub task (2.2) of 
 https://issues.apache.org/jira/browse/CLOUDSTACK-621 
 Currently, Load Balancing VPC VR is only supported on one of the Tiers of an 
 nTier Application. With this release, CloudStack should support load 
 balancing on all tiers of an nTier application.
 Use Case: Users would like to deploy a multi-tier application with the VR 
 load balancing each of the tiers. As a result, users would be able to provide 
 flexibility and elasticity at each tier of their application

--
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-747) nTier Apps 2.0 : Internal Load Balancing between the VPC tiers

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


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

ASF subversion and git services commented on CLOUDSTACK-747:


Commit a0e75c12cd62541f750e9ff556d7b570483dbf72 in branch 
refs/heads/ui-vpc-redesign from Jessica Wang jessicaw...@apache.org
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a0e75c1 ]

CLOUDSTACK-747: internal LB in VPC - fix a bug that Source IP Address column 
was not filled after Add Internal LB action was complete.


  nTier Apps 2.0 : Internal Load Balancing between the VPC tiers
 ---

 Key: CLOUDSTACK-747
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-747
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Reporter: Kishan Kavala
Assignee: Brian Federle
 Fix For: 4.2.0


 This item is sub task (2.2) of 
 https://issues.apache.org/jira/browse/CLOUDSTACK-621 
 Currently, Load Balancing VPC VR is only supported on one of the Tiers of an 
 nTier Application. With this release, CloudStack should support load 
 balancing on all tiers of an nTier application.
 Use Case: Users would like to deploy a multi-tier application with the VR 
 load balancing each of the tiers. As a result, users would be able to provide 
 flexibility and elasticity at each tier of their application

--
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-105) /tmp/stream-unix.####.###### stale sockets causing inodes to run out on Xenserver

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


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

ASF subversion and git services commented on CLOUDSTACK-105:


Commit c342fa69a827a00aa3297a6cc9f6a15e7f711cd9 in branch refs/heads/4.1 from 
[~anthonyxu]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c342fa6 ]

CLOUDSTACK-105,

  there is a trailing '\n' after 'bridge', need to remove it before checking if 
XS is in bridge mode or ovs mode


 /tmp/stream-unix..## stale sockets causing inodes to run out on 
 Xenserver
 -

 Key: CLOUDSTACK-105
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-105
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Third-Party Bugs
Affects Versions: pre-4.0.0
 Environment: Xenserver 6.0.2
 Cloudstack 3.0.2
Reporter: Caleb Call
Assignee: Devdeep Singh
 Fix For: 4.1.0

 Attachments: messages


 We came across an interesting issue in one of our clusters.  We ran out of 
 inodes on all of our cluster members (since when does this happen in 2012?).  
 When this happened, it in turn made the / filesystem a read-only filesystem 
 which in turn made all the hosts go in to emergency maintenance mode and as a 
 result get marked down by Cloudstack.  We found that it was caused by 
 hundreds of thousands of stale socket files in /tmp named 
 stream-unix..##.  To resolve the issue, we had to delete those 
 stale socket files (find /tmp -name *stream* -mtime +7 -exec rm -v {} \;), 
 then kill and restart xapi, then correct the emergency maintenance mode.  
 These hosts had only been up for 45 days before this issue occurred.  
 In our scouring of the interwebs, the only other instance we've been able to 
 find of this (or similar) happening is in the same setup we are currently 
 running. Xenserver 6.0.2 with CS 3.0.2.  Do these stream-unix sockets have 
 anything to do with Cloudstack?  I would think if this was a Xenserver issue 
 (bug), there would be a lot more on the internet about this happening.  For a 
 temporary workaround, we've added a cronjob to cleanup these files but we'd 
 really like to address the actual issue that's causing these sockets to 
 become stale and not get cleaned-up.

--
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-105) /tmp/stream-unix.####.###### stale sockets causing inodes to run out on Xenserver

2013-05-22 Thread Anthony Xu (JIRA)


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

Anthony Xu commented on CLOUDSTACK-105:
---

Caleb,

Can you check if above checkin fixes this issue?  you can manaually patch 
/etc/xapi.d/plugins/vmops in your XS host.


--- a/scripts/vm/hypervisor/xenserver/vmops
+++ b/scripts/vm/hypervisor/xenserver/vmops
@@ -267,7 +267,7 @@ def setLinkLocalIP(session, args):
 except:
 return 'can not cat network.conf'

-if result.lower() == bridge:
+if result.lower().strip() == bridge:
 try:
 cmd = [brctl, addbr, brName]
 txt = util.pread2(cmd)


Anthony

 /tmp/stream-unix..## stale sockets causing inodes to run out on 
 Xenserver
 -

 Key: CLOUDSTACK-105
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-105
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Third-Party Bugs
Affects Versions: pre-4.0.0
 Environment: Xenserver 6.0.2
 Cloudstack 3.0.2
Reporter: Caleb Call
Assignee: Devdeep Singh
 Fix For: 4.1.0

 Attachments: messages


 We came across an interesting issue in one of our clusters.  We ran out of 
 inodes on all of our cluster members (since when does this happen in 2012?).  
 When this happened, it in turn made the / filesystem a read-only filesystem 
 which in turn made all the hosts go in to emergency maintenance mode and as a 
 result get marked down by Cloudstack.  We found that it was caused by 
 hundreds of thousands of stale socket files in /tmp named 
 stream-unix..##.  To resolve the issue, we had to delete those 
 stale socket files (find /tmp -name *stream* -mtime +7 -exec rm -v {} \;), 
 then kill and restart xapi, then correct the emergency maintenance mode.  
 These hosts had only been up for 45 days before this issue occurred.  
 In our scouring of the interwebs, the only other instance we've been able to 
 find of this (or similar) happening is in the same setup we are currently 
 running. Xenserver 6.0.2 with CS 3.0.2.  Do these stream-unix sockets have 
 anything to do with Cloudstack?  I would think if this was a Xenserver issue 
 (bug), there would be a lot more on the internet about this happening.  For a 
 temporary workaround, we've added a cronjob to cleanup these files but we'd 
 really like to address the actual issue that's causing these sockets to 
 become stale and not get cleaned-up.

--
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-2627) [Automation] Failed to disassociate ip address from network

2013-05-22 Thread Rayees Namathponnan (JIRA)

Rayees Namathponnan created CLOUDSTACK-2627:
---

 Summary: [Automation] Failed to disassociate ip address from 
network 
 Key: CLOUDSTACK-2627
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2627
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Controller
Affects Versions: 4.2.0
 Environment: Master build : Commit 
fd4c0bfa9076dcc47094a9803fc943f87925b99e
BVT 
Reporter: Rayees Namathponnan
 Fix For: 4.2.0


Steps to reproduce 

Execute BVT test 
integration.smoke.test_network.TestPublicIP.test_public_ip_admin_account
integration.smoke.test_network.TestPublicIP.test_public_ip_user_account

or 

Step 1 : Create new Network and acquire and IP
Step 2 : Delete newly acquired IP 

Result 

Delete IP address failed with error  Failed to disassociate ip address


2013-05-22 14:28:52,703 DEBUG [cloud.network.NetworkManagerImpl] 
(Job-Executor-24:job-1048) Released a public ip id=22
2013-05-22 14:28:52,708 DEBUG [cloud.async.AsyncJobManagerImpl] 
(Job-Executor-24:job-1048) Complete async job-1048, jobStatus: 2, resultCode: 
530, result: Error Code: 530 Error text: Failed to disassociate ip address
2013-05-22 14:28:52,719 DEBUG [cloud.async.SyncQueueManagerImpl] 
(Job-Executor-24:job-1048) Sync queue (134) is currently empty
2013-05-22 14:28:52,721 DEBUG [cloud.api.ApiServlet] (catalina-exec-12:null) 
===START===  10.216.133.67 -- GET  
command=queryAsyncJobResultjobId=7ac61258-66be-4285-80a0-93c16f843528response=jsonsessionkey=MYbBTIXQgKsW5dsSt7QGen4WcTA%3D_=1369247245682




--
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-2627) [Automation] Failed to disassociate ip address from network

2013-05-22 Thread Rayees Namathponnan (JIRA)


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

Rayees Namathponnan updated CLOUDSTACK-2627:


Attachment: CLOUDSTACK-2627.rar

 [Automation] Failed to disassociate ip address from network 
 

 Key: CLOUDSTACK-2627
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2627
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.2.0
 Environment: Master build : Commit 
 fd4c0bfa9076dcc47094a9803fc943f87925b99e
 BVT 
Reporter: Rayees Namathponnan
 Fix For: 4.2.0

 Attachments: CLOUDSTACK-2627.rar


 Steps to reproduce 
 Execute BVT test 
 integration.smoke.test_network.TestPublicIP.test_public_ip_admin_account
 integration.smoke.test_network.TestPublicIP.test_public_ip_user_account
 or 
 Step 1 : Create new Network and acquire and IP
 Step 2 : Delete newly acquired IP 
 Result 
 Delete IP address failed with error  Failed to disassociate ip address
 2013-05-22 14:28:52,703 DEBUG [cloud.network.NetworkManagerImpl] 
 (Job-Executor-24:job-1048) Released a public ip id=22
 2013-05-22 14:28:52,708 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-24:job-1048) Complete async job-1048, jobStatus: 2, resultCode: 
 530, result: Error Code: 530 Error text: Failed to disassociate ip address
 2013-05-22 14:28:52,719 DEBUG [cloud.async.SyncQueueManagerImpl] 
 (Job-Executor-24:job-1048) Sync queue (134) is currently empty
 2013-05-22 14:28:52,721 DEBUG [cloud.api.ApiServlet] (catalina-exec-12:null) 
 ===START===  10.216.133.67 -- GET  
 command=queryAsyncJobResultjobId=7ac61258-66be-4285-80a0-93c16f843528response=jsonsessionkey=MYbBTIXQgKsW5dsSt7QGen4WcTA%3D_=1369247245682

--
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-105) /tmp/stream-unix.####.###### stale sockets causing inodes to run out on Xenserver

2013-05-22 Thread Anthony Xu (JIRA)

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

Anthony Xu commented on CLOUDSTACK-105:
---

BTW , you need to switch to bridge mode if you want to use Security Group.
Execute below in XS host,
xe-switch-network-backend bridge

/tmp/stream-unix..## stale sockets causing inodes to run out on
Xenserver
-

Attachments: messages

[jira] [Commented] (CLOUDSTACK-747) nTier Apps 2.0 : Internal Load Balancing between the VPC tiers

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


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

ASF subversion and git services commented on CLOUDSTACK-747:


Commit c7976b668586181267bf9d8ceba50d194fd96d1c in branch 
refs/heads/ui-vpc-redesign from Jessica Wang jessicaw...@apache.org
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c7976b6 ]

CLOUDSTACK-747: internal LB in VPC - remove module internalLbProvider since 
internalLbVm section has been added in system.js


  nTier Apps 2.0 : Internal Load Balancing between the VPC tiers
 ---

 Key: CLOUDSTACK-747
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-747
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Reporter: Kishan Kavala
Assignee: Brian Federle
 Fix For: 4.2.0


 This item is sub task (2.2) of 
 https://issues.apache.org/jira/browse/CLOUDSTACK-621 
 Currently, Load Balancing VPC VR is only supported on one of the Tiers of an 
 nTier Application. With this release, CloudStack should support load 
 balancing on all tiers of an nTier application.
 Use Case: Users would like to deploy a multi-tier application with the VR 
 load balancing each of the tiers. As a result, users would be able to provide 
 flexibility and elasticity at each tier of their application

--
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-747) nTier Apps 2.0 : Internal Load Balancing between the VPC tiers

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


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

ASF subversion and git services commented on CLOUDSTACK-747:


Commit c7b902024c321776bc1d00cf23dcf91793cda1d7 in branch 
refs/heads/ui-vpc-redesign from Jessica Wang jessicaw...@apache.org
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c7b9020 ]

CLOUDSTACK-747: internalLb in VPC - Infrastructure menu - network service 
provider - add InternalLbVm. Clicking it will lead to a screen that can 
enable/disable provider and have instances tab that can start/stop LB Instance.


  nTier Apps 2.0 : Internal Load Balancing between the VPC tiers
 ---

 Key: CLOUDSTACK-747
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-747
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Reporter: Kishan Kavala
Assignee: Brian Federle
 Fix For: 4.2.0


 This item is sub task (2.2) of 
 https://issues.apache.org/jira/browse/CLOUDSTACK-621 
 Currently, Load Balancing VPC VR is only supported on one of the Tiers of an 
 nTier Application. With this release, CloudStack should support load 
 balancing on all tiers of an nTier application.
 Use Case: Users would like to deploy a multi-tier application with the VR 
 load balancing each of the tiers. As a result, users would be able to provide 
 flexibility and elasticity at each tier of their application

--
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-747) nTier Apps 2.0 : Internal Load Balancing between the VPC tiers

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


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

ASF subversion and git services commented on CLOUDSTACK-747:


Commit 29574267c9776aed5d17d2495602f03bfb4c3487 in branch 
refs/heads/ui-vpc-redesign from Jessica Wang jessicaw...@apache.org
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2957426 ]

CLOUDSTACK-747: UI - create network offering - default sourceNat type as per 
account instead of per zone.


  nTier Apps 2.0 : Internal Load Balancing between the VPC tiers
 ---

 Key: CLOUDSTACK-747
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-747
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Reporter: Kishan Kavala
Assignee: Brian Federle
 Fix For: 4.2.0


 This item is sub task (2.2) of 
 https://issues.apache.org/jira/browse/CLOUDSTACK-621 
 Currently, Load Balancing VPC VR is only supported on one of the Tiers of an 
 nTier Application. With this release, CloudStack should support load 
 balancing on all tiers of an nTier application.
 Use Case: Users would like to deploy a multi-tier application with the VR 
 load balancing each of the tiers. As a result, users would be able to provide 
 flexibility and elasticity at each tier of their application

--
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-2516) Create User API compability broken now

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


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

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

Commit e720e8a1a62722c2c032aafe00848079fbd92a03 in branch 
refs/heads/ui-vpc-redesign from Chip Childers chipchild...@apache.org
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e720e8a ]

CLOUDSTACK-2516: Adding upgrade steps to deal with authenticator changes


 Create User API compability broken now
 --

 Key: CLOUDSTACK-2516
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2516
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.1.0, 4.2.0
Reporter: Chip Childers
Assignee: Kishan Kavala
Priority: Blocker
 Fix For: 4.1.0, 4.2.0


 From email thread:
 On Wed, May 15, 2013 at 04:22:14PM +0200, Ove Ewerlid wrote:
  NB; The 402/410 deployments are on RHES64(OEL64) via RPMs built from
  latest git repos.
  /Ove
  
  On 05/15/2013 03:02 PM, Ove Ewerlid wrote:
  Hi!
  
  When testing a deploy script, that works as expected with 4.0.2, on 4.1
  I noticed that there was a need to pass plaintext passwords to
  createUser, rather then the documented MD5 hash. When passing MD5 hash,
  the password gets double MD5:hashed in 41.
  
  There is new code in 4.1 that encodes password using the authenticator
  plugins (encode method);
  
  cloudstack.4.1/server/src/com/cloud/user/AccountManagerImpl.java
  
  ...
  String encodedPassword = null;
   for (UserAuthenticator  authenticator : _userAuthenticators) {
   encodedPassword = authenticator.encode(password);
   if (encodedPassword != null) {
   break;
   }
   }
  ...
  
  The 41 API docs still notes that an MD5 hash shall be passed in.
  What am I missing here?
  
  /Ove

--
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-2568) ACS41 regression in storage subsystem (seen with local storage and 2 or more hosts)

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


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

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

Commit 78186c3b0201ecf55779b3f4bb6a3105fec1288d in branch refs/heads/4.1 from 
[~prachidamle]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=78186c3 ]

CLOUDSTACK-2568: ACS41 regression in storage subsystem (seen with local storage 
and 2 or more hosts)

Patch for 4.1, changes:
- In VolumeReservationVO, the getter method of a column had a typo, causing us 
to create a wrong searchbuilder. It was searching over the 'id' column instead 
of 'vm_reservation_id' causing
- This bug was causing the vm deployment to choose a wrong pool during 
deployment since the search was choosing incorrectly
- This bug in the GenericSearchBuilder is also fixed - if the getter method 
does not use the standard 'get' or 'is' prefix, one should annotate that method 
using
 @Column(name = column_name) and indicate which column this method refers 
to. This will cause the GenericSearchBuilder to identify the field correctly.
- Also, let planner search for pools instead of selecting the one reserved - 
because there is no way currently to pass multiple pool information to the 
planner and this may cause issues when a VM has multiple disks.

Signed-off-by: Chip Childers chip.child...@gmail.com


 ACS41 regression in storage subsystem (seen with local storage and 2 or more 
 hosts)
 ---

 Key: CLOUDSTACK-2568
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2568
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.1.0
 Environment: RHES64 as in OEL64. Install from RPM built from latest 
 GIT on OEL64.
 2 or more KVM hypervisors with local storage in one cluster that has one 
 primary NFS storage pool.
Reporter: Ove Ewerlid
Assignee: Prachi Damle
Priority: Blocker
 Fix For: 4.1.0

 Attachments: var-log-cloudstack-management.tar.gz


 ACS402 works with no issues when tested in exactly the setup where ACS41 
 fails.
 Identical configuration (the same setup program is used for testing both 
 versions).
 In ACS410 startVM fails if and only if the advanceStart: log line picks a 
 poolID that is not valid.
 E.g., the poolID reported in this logline appears random across a large 
 number of tests.
 If a poolID that can not be reached by the host selected for deployment, the 
 startVM fails.
 This is blocking upgrade from 4.0 to 4.1 since there is no  reliable way to 
 start VMs that have been deployed. If a deployed VM fails to start, giving 
 the startVM command multiple times, will eventually make the VM start.
 The more hosts there are, the less likely it is a startVM will succeed. It is 
 less likely that the poolID is correct.
 The below log portion conveys how the VM has a correct Deployment 
 Destination reported and the advanceStart reports a poolID that is different 
 and since the selected hypervisor can not reach the poolID the startVM fails.
 The bug never triggers if there is only one KVM with local storage since the 
 poolId can not be wrong, there is just one (and the NFS pool is always valid).
 ---
 2013-05-20 06:49:29,477 DEBUG [cloud.deploy.FirstFitPlanner] 
 (Job-Executor-34:job-34) Found a potential host id: 1 name: 
 vm3-net0-s0-14.test.devops and associated storage pools for this VM
 2013-05-20 06:49:29,478 DEBUG [cloud.deploy.FirstFitPlanner] 
 (Job-Executor-34:job-34) Returning Deployment Destination: 
 Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type--Pool(Id))]
  : Dest[Zone(1)-Pod(1)-Cluster(1)-Host\
 (1)-Storage(Volume(10|ROOT--Pool(200), Volume(11|DATADISK--Pool(200))]
 2013-05-20 06:49:29,495 DEBUG [cloud.capacity.CapacityManagerImpl] 
 (Job-Executor-34:job-34) VM state transitted from :Stopped to Starting with 
 event: StartRequestedvm's original host id: null new host id: null host id 
 before state trans\
 ition: null
 2013-05-20 06:49:29,495 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (Job-Executor-34:job-34) Successfully transitioned to start state for 
 VM[User|testvm-a] reservation id = e644d55e-3627-4395-9f89-639e6fc2f261
 2013-05-20 06:49:29,502 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (Job-Executor-34:job-34) Trying to deploy VM, vm has dcId: 1 and podId: null
 2013-05-20 06:49:29,502 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (Job-Executor-34:job-34) advanceStart: DeploymentPlan is provided, using 
 dcId:1, podId: 1, clusterId: 1, hostId: 1, poolId: 201
 2013-05-20 06:49:29,502 DEBUG

[jira] [Resolved] (CLOUDSTACK-2568) ACS41 regression in storage subsystem (seen with local storage and 2 or more hosts)

2013-05-22 Thread Chip Childers (JIRA)


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

Chip Childers resolved CLOUDSTACK-2568.
---

Resolution: Fixed

applied to 4.1 now

 ACS41 regression in storage subsystem (seen with local storage and 2 or more 
 hosts)
 ---

 Key: CLOUDSTACK-2568
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2568
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.1.0
 Environment: RHES64 as in OEL64. Install from RPM built from latest 
 GIT on OEL64.
 2 or more KVM hypervisors with local storage in one cluster that has one 
 primary NFS storage pool.
Reporter: Ove Ewerlid
Assignee: Prachi Damle
Priority: Blocker
 Fix For: 4.1.0

 Attachments: var-log-cloudstack-management.tar.gz


 ACS402 works with no issues when tested in exactly the setup where ACS41 
 fails.
 Identical configuration (the same setup program is used for testing both 
 versions).
 In ACS410 startVM fails if and only if the advanceStart: log line picks a 
 poolID that is not valid.
 E.g., the poolID reported in this logline appears random across a large 
 number of tests.
 If a poolID that can not be reached by the host selected for deployment, the 
 startVM fails.
 This is blocking upgrade from 4.0 to 4.1 since there is no  reliable way to 
 start VMs that have been deployed. If a deployed VM fails to start, giving 
 the startVM command multiple times, will eventually make the VM start.
 The more hosts there are, the less likely it is a startVM will succeed. It is 
 less likely that the poolID is correct.
 The below log portion conveys how the VM has a correct Deployment 
 Destination reported and the advanceStart reports a poolID that is different 
 and since the selected hypervisor can not reach the poolID the startVM fails.
 The bug never triggers if there is only one KVM with local storage since the 
 poolId can not be wrong, there is just one (and the NFS pool is always valid).
 ---
 2013-05-20 06:49:29,477 DEBUG [cloud.deploy.FirstFitPlanner] 
 (Job-Executor-34:job-34) Found a potential host id: 1 name: 
 vm3-net0-s0-14.test.devops and associated storage pools for this VM
 2013-05-20 06:49:29,478 DEBUG [cloud.deploy.FirstFitPlanner] 
 (Job-Executor-34:job-34) Returning Deployment Destination: 
 Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type--Pool(Id))]
  : Dest[Zone(1)-Pod(1)-Cluster(1)-Host\
 (1)-Storage(Volume(10|ROOT--Pool(200), Volume(11|DATADISK--Pool(200))]
 2013-05-20 06:49:29,495 DEBUG [cloud.capacity.CapacityManagerImpl] 
 (Job-Executor-34:job-34) VM state transitted from :Stopped to Starting with 
 event: StartRequestedvm's original host id: null new host id: null host id 
 before state trans\
 ition: null
 2013-05-20 06:49:29,495 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (Job-Executor-34:job-34) Successfully transitioned to start state for 
 VM[User|testvm-a] reservation id = e644d55e-3627-4395-9f89-639e6fc2f261
 2013-05-20 06:49:29,502 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (Job-Executor-34:job-34) Trying to deploy VM, vm has dcId: 1 and podId: null
 2013-05-20 06:49:29,502 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (Job-Executor-34:job-34) advanceStart: DeploymentPlan is provided, using 
 dcId:1, podId: 1, clusterId: 1, hostId: 1, poolId: 201
 2013-05-20 06:49:29,502 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (Job-Executor-34:job-34) Deploy avoids pods: null, clusters: null, hosts: null
 2013-05-20 06:49:29,504 DEBUG [cloud.deploy.FirstFitPlanner] 
 (Job-Executor-34:job-34) DeploymentPlanner allocation algorithm: random
 2013-05-20 06:49:29,504 DEBUG [cloud.deploy.FirstFitPlanner] 
 (Job-Executor-34:job-34) Trying to allocate a host and storage pools from 
 dc:1, pod:1,cluster:1, requested cpu: 4000, requested ram: 2147483648
 2013-05-20 06:49:29,504 DEBUG [cloud.deploy.FirstFitPlanner] 
 (Job-Executor-34:job-34) Is ROOT volume READY (pool already allocated)?: Yes
 2013-05-20 06:49:29,504 DEBUG [cloud.deploy.FirstFitPlanner] 
 (Job-Executor-34:job-34) DeploymentPlan has host_id specified, making no 
 checks on this host, looks like admin test: 1
 2013-05-20 06:49:29,505 DEBUG [cloud.deploy.FirstFitPlanner] 
 (Job-Executor-34:job-34) Looking for suitable pools for this host under zone: 
 1, pod: 1, cluster: 1
 2013-05-20 06:49:29,506 DEBUG [cloud.deploy.FirstFitPlanner] 
 (Job-Executor-34:job-34) Checking suitable pools for volume (Id, Type): 
 (10,ROOT)
 2013-05-20 06:49:29,506 DEBUG [cloud.deploy.FirstFitPlanner] 
 (Job-Executor-34:job-34) Volume has pool(201) already allocated, checking if 
 pool can be reused,

[jira] [Commented] (CLOUDSTACK-2215) ACS41 SSVM does not use allocated storage ip range

2013-05-22 Thread ilya musayev (JIRA)


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

ilya musayev commented on CLOUDSTACK-2215:
--

i've blown away my setup and recreating it today and tomorrow (i need to jump 
through the hoops, hence the delay)

The question i would like to ask, for your setup

1) Did you use wizard or APIs to add a zone

2) Did you add basic or advanced zone

3) Did you define public and guest ip space before the zone was activated and 
SSVM was deployed?

Thanks
ilya


 ACS41 SSVM does not use allocated storage ip range
 --

 Key: CLOUDSTACK-2215
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2215
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller, Storage Controller
Affects Versions: 4.0.1, 4.0.2, 4.1.0
 Environment: ACS4.1 as of 04/15/13 - i know its 10 days old, but i've 
 not seen fixes for this yet.
 VMWare vSphere 5.0 with Advanced Network
Reporter: ilya musayev
Priority: Blocker
  Labels: Network, SSVM

 Create Advanced Network Zone, assign a range of IPs to storage network, also 
 predefine public range. 
 The Secondary Storage VM gets the IPs of Public Networks and not whats its 
 been given. In my example, i've defined two public networks - with very small 
 ip range (4 on each). I noticed that SSVM took 2 IPs from Public Network A, 
 and 1 IP from Public Network B. 
 If you have stringent setup and you need to allocate IPs as designed and 
 setup firewall rules, one would expect to setup firewall rules on storage ip 
 range, thinking that SSVM is going to use the IP from that range, however, 
 instead - it uses public ip range.

--
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-747) nTier Apps 2.0 : Internal Load Balancing between the VPC tiers

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


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

ASF subversion and git services commented on CLOUDSTACK-747:


Commit ff58052d2cd5f2ed821bef04c18960ef0d18fac2 in branch 
refs/heads/ui-vpc-redesign from Jessica Wang jessicaw...@apache.org
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ff58052 ]

CLOUDSTACK-747: internal LB in VPC - internal LB detailView - add rules tab, 
assignedVMs tab.


  nTier Apps 2.0 : Internal Load Balancing between the VPC tiers
 ---

 Key: CLOUDSTACK-747
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-747
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Reporter: Kishan Kavala
Assignee: Brian Federle
 Fix For: 4.2.0


 This item is sub task (2.2) of 
 https://issues.apache.org/jira/browse/CLOUDSTACK-621 
 Currently, Load Balancing VPC VR is only supported on one of the Tiers of an 
 nTier Application. With this release, CloudStack should support load 
 balancing on all tiers of an nTier application.
 Use Case: Users would like to deploy a multi-tier application with the VR 
 load balancing each of the tiers. As a result, users would be able to provide 
 flexibility and elasticity at each tier of their application

--
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-2628) listLoadBalancerRules API needs to be able to take in networkid

2013-05-22 Thread Jessica Wang (JIRA)

Jessica Wang created CLOUDSTACK-2628:


 Summary: listLoadBalancerRules API needs to be able to take in 
networkid
 Key: CLOUDSTACK-2628
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2628
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Jessica Wang
Priority: Critical


For VPC redesign feature, we need to be able to list public load balancers in 
tier level (i.e. network level).
So, listLoadBalancerRules API has to be able to take in networkid and return 
load balancer rules under that network.


--
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-2628) listLoadBalancerRules API, listPortForwardingRules API need to be able to take in networkid

2013-05-22 Thread Jessica Wang (JIRA)


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

Jessica Wang updated CLOUDSTACK-2628:
-

Description: 
For VPC redesign feature, we need to be able to list public load balancers in 
tier level (i.e. network level).
So, listLoadBalancerRules API has to be able to take in networkid and return 
load balancer rules under that network.

Same is listPortForwardingRules, we need to be able to list port forwarding 
rules in tier level (i.e. network level).
So, listPortForwardingRules API has to be able to take in networkid and return 
port forwarding rules under that network.


  was:
For VPC redesign feature, we need to be able to list public load balancers in 
tier level (i.e. network level).
So, listLoadBalancerRules API has to be able to take in networkid and return 
load balancer rules under that network.


Summary: listLoadBalancerRules API, listPortForwardingRules API need to 
be able to take in networkid  (was: listLoadBalancerRules API needs to be able 
to take in networkid)

 listLoadBalancerRules API, listPortForwardingRules API need to be able to 
 take in networkid
 ---

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

 For VPC redesign feature, we need to be able to list public load balancers in 
 tier level (i.e. network level).
 So, listLoadBalancerRules API has to be able to take in networkid and return 
 load balancer rules under that network.
 Same is listPortForwardingRules, we need to be able to list port forwarding 
 rules in tier level (i.e. network level).
 So, listPortForwardingRules API has to be able to take in networkid and 
 return port forwarding rules under that network.

--
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-2584) [Object_Store_Refactor] Failed to create template from stopped guest vm's root disk


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

Min Chen resolved CLOUDSTACK-2584.
--

Resolution: Fixed

Fixed with both commits.

 [Object_Store_Refactor] Failed to create template from stopped guest vm's 
 root disk
 ---

 Key: CLOUDSTACK-2584
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2584
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Template
Affects Versions: 4.2.0
 Environment: Build from object_store branch
Reporter: Sanjeev N
Assignee: edison su
Priority: Critical
 Fix For: 4.2.0

 Attachments: management-server.rar


 [Object_Store_Refactor] Failed to create template from stopped guest vm's 
 root disk
 Steps to reproduce:
 
 1.Bring up CS in advanced zone with S3 as the secondary storage provider
 2.Deploy guest vm with default cent os template downloaded after system vms 
 are up
 3.Stop the guest vm and try to take template from the root volume of the 
 guest vm deployed above
 Observations:
 
 Observed following exception while taking template:
 2013-05-20 12:33:23,481 DEBUG [cloud.api.ApiServlet] (catalina-exec-15:null) 
 ===START===  10.146.0.15 -- GET  
 command=createTemplateresponse=jsonsessionkey=R6B02dSeoRFzL6CVp2PX3UbfsGg%3DvolumeId=135a3df1-20e1-4b4b-a433-86976ddc9218name=root3displayText=root3osTypeId=6d6b2f3e-c0bf-11e2-8198-06ab465fisPublic=truepasswordEnabled=falseisfeatured=true_=1369047892340
 2013-05-20 12:33:23,711 DEBUG [cloud.template.TemplateManagerImpl] 
 (catalina-exec-15:null) This template is getting created from other template, 
 setting source template Id to: 5
 2013-05-20 12:33:23,763 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (catalina-exec-15:null) submit async job-19, details: AsyncJobVO {id:19, 
 userId: 2, accountId: 2, sessionKey: null, instanceType: Template, 
 instanceId: 205, cmd: 
 org.apache.cloudstack.api.command.user.template.CreateTemplateCmd, 
 cmdOriginator: null, cmdInfo: 
 {sessionkey:R6B02dSeoRFzL6CVp2PX3UbfsGg\u003d,volumeId:135a3df1-20e1-4b4b-a433-86976ddc9218,ctxUserId:2,httpmethod:GET,osTypeId:6d6b2f3e-c0bf-11e2-8198-06ab465f,isPublic:true,isfeatured:true,response:json,id:205,displayText:root3,passwordEnabled:false,name:root3,_:1369047892340,ctxAccountId:2,ctxStartEventId:75},
  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
 processStatus: 0, resultCode: 0, result: null, initMsid: 7332683579487, 
 completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
 2013-05-20 12:33:23,766 DEBUG [cloud.api.ApiServlet] (catalina-exec-15:null) 
 ===END===  10.146.0.15 -- GET  
 command=createTemplateresponse=jsonsessionkey=R6B02dSeoRFzL6CVp2PX3UbfsGg%3DvolumeId=135a3df1-20e1-4b4b-a433-86976ddc9218name=root3displayText=root3osTypeId=6d6b2f3e-c0bf-11e2-8198-06ab465fisPublic=truepasswordEnabled=falseisfeatured=true_=1369047892340
 2013-05-20 12:33:23,774 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-6:job-19) Executing 
 org.apache.cloudstack.api.command.user.template.CreateTemplateCmd for job-19
 2013-05-20 12:33:23,853 DEBUG [cloud.template.TemplateManagerImpl] 
 (Job-Executor-6:job-19) Failed to create 
 templatecom.cloud.utils.exception.CloudRuntimeException: Can't find cache 
 storage in zone: null
 2013-05-20 12:33:23,857 DEBUG [db.Transaction.Transaction] 
 (Job-Executor-6:job-19) Rolling back the transaction: Time = 3 Name =  
 -AsyncJobManagerImpl$1.run:401-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRun:334-FutureTask.run:166-ThreadPoolExecutor.runWorker:1146-ThreadPoolExecutor$Worker.run:615-Thread.run:679;
  called by 
 -Transaction.rollback:890-Transaction.removeUpTo:833-Transaction.close:657-TransactionContextBuilder.interceptException:63-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:133-TemplateManagerImpl.createPrivateTemplate:1433-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-CreateTemplateCmd.execute:258-ApiDispatcher.dispatch:155-AsyncJobManagerImpl$1.run:437-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRun:334
 2013-05-20 12:33:23,867 ERROR [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-6:job-19) Unexpected exception while executing 
 org.apache.cloudstack.api.command.user.template.CreateTemplateCmd
 com.cloud.utils.exception.CloudRuntimeException: DB Exception on: 
 com.mysql.jdbc.JDBC4PreparedStatement@6265c4a7: DELETE FROM vm_template WHERE 
 vm_template.id= 205
 at com.cloud.utils.db.GenericDaoBase.expunge(GenericDaoBase.java:1137)
 at

[jira] [Created] (CLOUDSTACK-2629) ListRouters with networkid throws exception

Min Chen created CLOUDSTACK-2629:


 Summary: ListRouters with networkid throws exception
 Key: CLOUDSTACK-2629
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2629
 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: Min Chen
Assignee: Min Chen
 Fix For: 4.2.0


Passing networkid parameter for listRouters api, it will throw exception:

unhandled exception executing api command: listInternalLoadBalancerVMs
java.lang.NullPointerException
at com.cloud.utils.db.SearchCriteria.findJoin(SearchCriteria.java:204)
at 
com.cloud.utils.db.SearchCriteria.setJoinParameters(SearchCriteria.java:223)
at 
com.cloud.api.query.QueryManagerImpl.searchForRoutersInternal(QueryManagerImpl.java:1098)
at 
com.cloud.api.query.QueryManagerImpl.searchForInternalLbVms(QueryManagerImpl.java:998)
at 
org.apache.cloudstack.api.command.admin.internallb.ListInternalLBVMsCmd.execute(ListInternalLBVMsCmd.java:147)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:519)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:369)
at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:304)
at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511

--
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-2629) ListRouters with networkid throws exception


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

Min Chen resolved CLOUDSTACK-2629.
--

Resolution: Fixed

 ListRouters with networkid throws exception
 ---

 Key: CLOUDSTACK-2629
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2629
 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: Min Chen
Assignee: Min Chen
 Fix For: 4.2.0


 Passing networkid parameter for listRouters api, it will throw exception:
 unhandled exception executing api command: listInternalLoadBalancerVMs
 java.lang.NullPointerException
   at com.cloud.utils.db.SearchCriteria.findJoin(SearchCriteria.java:204)
   at 
 com.cloud.utils.db.SearchCriteria.setJoinParameters(SearchCriteria.java:223)
   at 
 com.cloud.api.query.QueryManagerImpl.searchForRoutersInternal(QueryManagerImpl.java:1098)
   at 
 com.cloud.api.query.QueryManagerImpl.searchForInternalLbVms(QueryManagerImpl.java:998)
   at 
 org.apache.cloudstack.api.command.admin.internallb.ListInternalLBVMsCmd.execute(ListInternalLBVMsCmd.java:147)
   at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
   at com.cloud.api.ApiServer.queueCommand(ApiServer.java:519)
   at com.cloud.api.ApiServer.handleRequest(ApiServer.java:369)
   at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:304)
   at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
   at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511

--
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-1813) QuickCloud - faster cloud startup

2013-05-22 Thread Chiradeep Vittal (JIRA)


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

Chiradeep Vittal resolved CLOUDSTACK-1813.
--

Resolution: Fixed

Commits are
bf56403d828aa50c0650cc41cdc51aae79b1c19e
2e6c65fd34dc5f4f885c12a4e5469b505975685d
271d232d620f27c6b8b10bc85f849563c528e3ae
778a59fbf6bc8957771718123079bd8a2707affa
5ff8bcaa2e16035197c6d58bb212ba1696411dce
936973aff7ba372abe442a7a40e112219fba7570
c5b11df6b78dd755acc4141dc2063608e581996d
a806ce43d32e8d5ac064b79dd623c01be4489126
1d70b9ea77fd1e9fce98f7d9cd5fd92cfe444c39
21b4635948152710935ba420cee50b823fd7a2b4
3d78019e571677f1b2ac87acebe6192f2a4fa96c
790d2ce82ef6b1ac910124c8c9ab519e2431e622
16790446e51645dc3e2623ebf57f88e0cfe2c89c
e7983b2569abe0304a0b8d720c4c85c4561a


 QuickCloud - faster cloud startup
 -

 Key: CLOUDSTACK-1813
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1813
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller, Storage Controller
Reporter: Chiradeep Vittal
Assignee: Chiradeep Vittal
 Fix For: 4.2.0


 https://cwiki.apache.org/confluence/display/CLOUDSTACK/QuickCloud
 To enable a cloud to boot with services managed and running on 
 non-cloudstack-managed servers
 To enable a development environment based on DevCloud (QuickCloud) that 
 eschews the use of system vms
 To allow the cloud administrator to choose to provide these services the 
 old way after booting in the QuickCloud fashion

--
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-2630) Object_Store_Refactor - Snapshots - There is no delta snapshots being created for subsequent snapshots when multiple snapshots are taken for root /data volumes.

Sangeetha Hariharan created CLOUDSTACK-2630:
---

 Summary: Object_Store_Refactor - Snapshots - There is no delta 
snapshots being created for subsequent snapshots when multiple  snapshots are 
taken for root /data volumes.
 Key: CLOUDSTACK-2630
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2630
 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 object store
Reporter: Sangeetha Hariharan
Priority: Blocker
 Fix For: 4.2.0


Object_Store_Refactor - Snapshots - There is no delta syncs being created for 
subsequent snapshots when multiple  snapshots are taken for root /data volumes

Steps to reproduce the problem:

Deploy a Vm with root and data disk.

Take 1 snapshot of root volume.
Do some changes to the root volume like create files.

Take another snapshot of root volume.

Notice that the 2nd snapshot taken is not a delta snapshot.

[root@nfs2 3]# ls -ltr
total 2607572
-rw-r--r-- 1 root root 1863848448 May 22 15:28 
aecfd50d-c5f7-4270-96af-ccef8d040854.vhd
-rw-r--r-- 1 root root 1865949696 May 22 15:33 
d9d89b01-a82c-41b0-a440-3bb807beac6e.vhd
[root@nfs2 3]#


Take 1 snapshot of data volume.
Do some changes to the data volume like create files.

Take another snapshot of data volume.

Notice that the 2nd snapshot taken is not a delta snapshot.


[root@nfs2 8]# ls -ltr
total 13052
-rw-r--r-- 1 root root 153403904 May 22 13:53 
15f1706f-7a2a-45ba-96bc-d0dc520909f3.vhd
-rw-r--r-- 1 root root 153403904 May 22 13:54 
9047547a-a131-431a-b3f0-de1a3acb5117.vhd
-rw-r--r-- 1 root root 153403904 May 22 15:47 
6077e984-f7e3-4981-919d-25b0381fb563.vhd


management server logs:
2013-05-22 14:46:17,881 DEBUG [cloud.async.AsyncJobManagerImpl] 
(catalina-exec-21:null) submit async job-30, details: AsyncJobVO {id:30, 
userId: 2, accountId: 2, sessionKey: null, instanceType: Snapshot, instanceId: 
7, cmd: org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd, 
cmdOriginator: null, cmdInfo: 
{id:7,response:json,sessionkey:5LuVTJbq8L9whPX/rBchZgFpeGs\u003d,ctxUserId:2,httpmethod:GET,_:1369262605452,volumeid:127eb892-e435-4a13-a29a-5b9d3185face,ctxAccountId:2,ctxStartEventId:95},
 cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
processStatus: 0, resultCode: 0, result: null, initMsid: 206915885079359, 
completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2013-05-22 14:46:17,883 DEBUG [cloud.async.AsyncJobManagerImpl] 
(Job-Executor-7:job-30) Executing 
org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd for job-30
2013-05-22 14:46:17,915 INFO  [user.snapshot.CreateSnapshotCmd] 
(Job-Executor-7:job-30) VOLSS: createSnapshotCmd starts:1369259177915
2013-05-22 14:46:17,976 DEBUG [agent.transport.Request] (Job-Executor-7:job-30) 
Seq 1-375915079: Sending  { Cmd , MgmtId: 206915885079359, via: 1, Ver: v1, 
Flags: 100011, 
[{org.apache.cloudstack.storage.command.CreateObjectCommand:{data:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{volume:{uuid:127eb892-e435-4a13-a29a-5b9d3185face,volumeType:DATADISK,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:dbf7203e-d359-3179-a464-9900e126cdb0,id:3,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/sangeetha/campo-systemp-1/primary2,port:2049}},name:DATA-8,size:5368709120,path:4cfaf81f-e11b-42ae-a290-65e2e36fb099,volumeId:8,vmName:i-2-8-VM,accountId:2,id:8},dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:dbf7203e-d359-3179-a464-9900e126cdb0,id:3,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/sangeetha/campo-systemp-1/primary2,port:2049}},vmName:i-2-8-VM,name:data-123_DATA-8_20130522214617,hypervisorType:XenServer,id:7}},wait:0}}]
 }
2013-05-22 14:46:17,976 DEBUG [agent.transport.Request] (Job-Executor-7:job-30) 
Seq 1-375915079: Executing:  { Cmd , MgmtId: 206915885079359, via: 1, Ver: v1, 
Flags: 100011, 
[{org.apache.cloudstack.storage.command.CreateObjectCommand:{data:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{volume:{uuid:127eb892-e435-4a13-a29a-5b9d3185face,volumeType:DATADISK,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:dbf7203e-d359-3179-a464-9900e126cdb0,id:3,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/sangeetha/campo-systemp-1/primary2,port:2049}},name:DATA-8,size:5368709120,path:4cfaf81f-e11b-42ae-a290-65e2e36fb099,volumeId:8,vmName:i-2-8-VM,accountId:2,id:8},dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:dbf7203e-d359-3179-a464-9900e126cdb0,id:3,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/sangeetha/campo-systemp-1/primary2,port:2049}},vmName:i-2-8-VM,name:data-123_DATA-8_20130522214617,hypervisorType:XenServer,id:7}},wait:0}}]
 }

[jira] [Assigned] (CLOUDSTACK-2627) [Automation] Failed to disassociate ip address from network


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

Alena Prokharchyk reassigned CLOUDSTACK-2627:
-

Assignee: Alena Prokharchyk

 [Automation] Failed to disassociate ip address from network 
 

 Key: CLOUDSTACK-2627
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2627
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.2.0
 Environment: Master build : Commit 
 fd4c0bfa9076dcc47094a9803fc943f87925b99e
 BVT 
Reporter: Rayees Namathponnan
Assignee: Alena Prokharchyk
 Fix For: 4.2.0

 Attachments: CLOUDSTACK-2627.rar


 Steps to reproduce 
 Execute BVT test 
 integration.smoke.test_network.TestPublicIP.test_public_ip_admin_account
 integration.smoke.test_network.TestPublicIP.test_public_ip_user_account
 or 
 Step 1 : Create new Network and acquire and IP
 Step 2 : Delete newly acquired IP 
 Result 
 Delete IP address failed with error  Failed to disassociate ip address
 2013-05-22 14:28:52,703 DEBUG [cloud.network.NetworkManagerImpl] 
 (Job-Executor-24:job-1048) Released a public ip id=22
 2013-05-22 14:28:52,708 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-24:job-1048) Complete async job-1048, jobStatus: 2, resultCode: 
 530, result: Error Code: 530 Error text: Failed to disassociate ip address
 2013-05-22 14:28:52,719 DEBUG [cloud.async.SyncQueueManagerImpl] 
 (Job-Executor-24:job-1048) Sync queue (134) is currently empty
 2013-05-22 14:28:52,721 DEBUG [cloud.api.ApiServlet] (catalina-exec-12:null) 
 ===START===  10.216.133.67 -- GET  
 command=queryAsyncJobResultjobId=7ac61258-66be-4285-80a0-93c16f843528response=jsonsessionkey=MYbBTIXQgKsW5dsSt7QGen4WcTA%3D_=1369247245682

--
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-2632) [Automation] Failed to stop VR with null pointer exception

2013-05-22 Thread Rayees Namathponnan (JIRA)

Rayees Namathponnan created CLOUDSTACK-2632:
---

 Summary: [Automation] Failed to stop VR with null pointer 
exception 
 Key: CLOUDSTACK-2632
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2632
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Controller
Affects Versions: 4.2.0
 Environment: VMware
Master branch build (4.2.0)
Reporter: Rayees Namathponnan
Priority: Blocker
 Fix For: 4.2.0


This issue is observed in automation VMare environment 

Steps to reproduce 

Step 1 : Create an account 
Step 2 : login to account and create a VM 
Step 3 : Delete the account 

VR always shows in stoping state, and null pointer error exception 


pAnswer } }
2013-05-22 15:50:15,283 DEBUG [agent.manager.AgentAttache] 
(DirectAgent-236:null) Seq 4-826868349: No more commands found
2013-05-22 15:50:15,283 DEBUG 
[network.router.VirtualNetworkApplianceManagerImpl] (AccountChecker-1:null) 
Successfully updated user statistics as a part of domR 
VM[DomainRouter|r-127-QA] reboot/stop
2013-05-22 15:50:15,288 WARN  [cloud.network.NetworkManagerImpl] 
(AccountChecker-1:null) Unable to complete shutdown of the network elements due 
to element: VirtualRouter
java.lang.NullPointerException
at 
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.finalizeStop(VirtualNetworkApplianceManagerImpl.java:2612)
at 
com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.finalizeStop(VpcVirtualNetworkApplianceManagerImpl.java:1396)
at 
com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1179)
at 
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.stop(VirtualNetworkApplianceManagerImpl.java:2741)
at 
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.stop(VirtualNetworkApplianceManagerImpl.java:258)
at 
com.cloud.network.element.VirtualRouterElement.shutdown(VirtualRouterElement.java:657)
at 
com.cloud.network.NetworkManagerImpl.shutdownNetworkElementsAndResources(NetworkManagerImpl.java:2625)
at 
com.cloud.network.NetworkManagerImpl.shutdownNetwork(NetworkManagerImpl.java:2555)
at 
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at 
com.cloud.network.NetworkManagerImpl.destroyNetwork(NetworkManagerImpl.java:2684)
at 
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at 
com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:655)
at 
com.cloud.user.AccountManagerImpl$AccountCleanupTask.run(AccountManagerImpl.java:1460)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at 
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
2013-05-22 15:50:15,294 DEBUG [cloud.network.NetworkManagerImpl] 
(AccountChecker-1:null) Network is not not in the correct state to be 
destroyed: Implemented
2013-05-22 15:50:15,294 WARN  [cloud.user.AccountManagerImpl] 
(AccountChecker-1:null) Unable to destroy network Ntwk[278|Guest|8] as a part 
of account id=115 cleanup.



--
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-730) Site-to-Site VPN VR-to-VR


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

Sheng Yang updated CLOUDSTACK-730:
--

Fix Version/s: (was: 4.2.0)
   Future

 Site-to-Site VPN VR-to-VR
 -

 Key: CLOUDSTACK-730
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-730
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Manan Shah
Assignee: Sheng Yang
 Fix For: Future


 Creating a sub-task for the Site-to-Site VPN between two Virtual Routers. 
 Please see the main task for requirements.

--
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-703) Site-to-Site VPN 2.0 Enhancements


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

Sheng Yang updated CLOUDSTACK-703:
--

Fix Version/s: (was: 4.2.0)
   Future

 Site-to-Site VPN 2.0 Enhancements
 -

 Key: CLOUDSTACK-703
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-703
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Manan Shah
Assignee: Sheng Yang
 Fix For: Future


 Requirements described at:
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Site-to-Site+VPN+2.0
 Requirements discussion email thread link:
 http://markmail.org/search/?q=[ASFCS41]+Site-to-Site+2.0+enhancements+list%3Aorg.apache.incubator.cloudstack-dev

--
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-2633) Object_Store_Refactor - Even after a secondary store is deleted , it is being returned in the listImageStores() API.

Sangeetha Hariharan created CLOUDSTACK-2633:
---

 Summary: Object_Store_Refactor - Even after a secondary store is 
deleted , it is being returned in the listImageStores() API.
 Key: CLOUDSTACK-2633
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2633
 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 object_store
Reporter: Sangeetha Hariharan
 Fix For: 4.2.0


Object_Store_Refactor - Even after a secondary store is deleted , it is being 
returned in the listImageStores() API.

Steps to reproduce the problem:
Create couple of secondary storages.
Delete 1 of them.
Use listImageStores() command , to list all the secondary storages. 
The deleted secondary storage is listed

http://10.223.57.194:8080/client/api?command=listImageStoresresponse=jsonsessionkey=5LuVTJbq8L9whPX%2FrBchZgFpeGs%3Dtype=SecondaryStoragepage=1pageSize=20listAll=true_=1369263683503

{ listimagestoreresponse : { count:3 ,imagestore : [  
{id:c449842d-47e3-4694-aa6e-5e0ddc6890ab,zoneid:9c88115b-ff6e-47af-9033-e592da1f395c,zonename:zone1,name:nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary4,url:nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary4,protocol:nfs,providername:NFS,scope:ZONE,details:[]},
 
{id:4a2f25c9-3ae0-4b8c-9e13-4a821d262df8,zoneid:9c88115b-ff6e-47af-9033-e592da1f395c,zonename:zone1,name:nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary1,url:nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary1,protocol:nfs,providername:NFS,scope:ZONE,details:[]},
 
{id:4548f72a-3da4-4014-8330-80907a213fbc,zoneid:9c88115b-ff6e-47af-9033-e592da1f395c,zonename:zone1,name:nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary,url:nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary,protocol:nfs,providername:NFS,scope:ZONE,details:[]}
 ] } }


mysql select * from image_store;
++---+-+--+---++---+---+--+--+-+-++
| id | name  | 
image_provider_name | protocol | url
   | data_center_id | scope | role  | uuid  
   | parent   | created | 
removed | total_size |
++---+-+--+---++---+---+--+--+-+-++
|  1 | nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary  | 
NFS | nfs  | 
nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary  | 
 1 | ZONE  | Image | 4548f72a-3da4-4014-8330-80907a213fbc | 
6cbcf976-4416-3c80-8c9e-319590e1d160 | 2013-05-20 21:35:13 | NULL   
 |   NULL |
|  2 | nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary1 | 
NFS | nfs  | 
nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary1 | 
 1 | ZONE  | Image | 4a2f25c9-3ae0-4b8c-9e13-4a821d262df8 | 
b5e999f3-0f10-3b01-a6d5-64dee8bf4820 | 2013-05-20 21:47:42 | 2013-05-22 
20:13:08 |   NULL |
|  3 | nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary4 | 
NFS | nfs  | 
nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary4 | 
 1 | ZONE  | Image | c449842d-47e3-4694-aa6e-5e0ddc6890ab | 
ac7f749d-eb30-394b-8ef8-ab52dc2b5c7c | 2013-05-22 19:16:46 | 2013-05-22 
19:52:03 |   NULL |
++---+-+--+---++---+---+--+--+-+-++
3 rows in set (0.00 sec)


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

[jira] [Created] (CLOUDSTACK-2634) Object_Store_Refactor - When there are multiple secondary storages , all delta snapshots relating to volume should be created in the same secondary storage as the fi

Sangeetha Hariharan created CLOUDSTACK-2634:
---

 Summary: Object_Store_Refactor - When there are multiple secondary 
storages , all delta snapshots relating to volume should be created in the same 
secondary storage as the first snapshot.
 Key: CLOUDSTACK-2634
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2634
 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 object store.
Reporter: Sangeetha Hariharan
 Fix For: 4.2.0


Object_Store_Refactor - When there are multiple secondary storages, all delta 
snapshots relating to volume should be created in the same secondary storage as 
the first snapshot.

Currently this check does not exists.

--
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-2633) Object_Store_Refactor - Even after a secondary store is deleted , it is being returned in the listImageStores() API.


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

Min Chen reassigned CLOUDSTACK-2633:


Assignee: Min Chen

 Object_Store_Refactor - Even after a secondary store is deleted , it is being 
 returned in the listImageStores() API.
 

 Key: CLOUDSTACK-2633
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2633
 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 object_store
Reporter: Sangeetha Hariharan
Assignee: Min Chen
 Fix For: 4.2.0


 Object_Store_Refactor - Even after a secondary store is deleted , it is being 
 returned in the listImageStores() API.
 Steps to reproduce the problem:
 Create couple of secondary storages.
 Delete 1 of them.
 Use listImageStores() command , to list all the secondary storages. 
 The deleted secondary storage is listed
 http://10.223.57.194:8080/client/api?command=listImageStoresresponse=jsonsessionkey=5LuVTJbq8L9whPX%2FrBchZgFpeGs%3Dtype=SecondaryStoragepage=1pageSize=20listAll=true_=1369263683503
 { listimagestoreresponse : { count:3 ,imagestore : [  
 {id:c449842d-47e3-4694-aa6e-5e0ddc6890ab,zoneid:9c88115b-ff6e-47af-9033-e592da1f395c,zonename:zone1,name:nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary4,url:nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary4,protocol:nfs,providername:NFS,scope:ZONE,details:[]},
  
 {id:4a2f25c9-3ae0-4b8c-9e13-4a821d262df8,zoneid:9c88115b-ff6e-47af-9033-e592da1f395c,zonename:zone1,name:nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary1,url:nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary1,protocol:nfs,providername:NFS,scope:ZONE,details:[]},
  
 {id:4548f72a-3da4-4014-8330-80907a213fbc,zoneid:9c88115b-ff6e-47af-9033-e592da1f395c,zonename:zone1,name:nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary,url:nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary,protocol:nfs,providername:NFS,scope:ZONE,details:[]}
  ] } }
 mysql select * from image_store;
 ++---+-+--+---++---+---+--+--+-+-++
 | id | name  
 | image_provider_name | protocol | url
| data_center_id | scope | role  | uuid
  | parent   | created 
 | removed | total_size |
 ++---+-+--+---++---+---+--+--+-+-++
 |  1 | nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary  
 | NFS | nfs  | 
 nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary  |   
1 | ZONE  | Image | 4548f72a-3da4-4014-8330-80907a213fbc | 
 6cbcf976-4416-3c80-8c9e-319590e1d160 | 2013-05-20 21:35:13 | NULL 
|   NULL |
 |  2 | nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary1 
 | NFS | nfs  | 
 nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary1 |   
1 | ZONE  | Image | 4a2f25c9-3ae0-4b8c-9e13-4a821d262df8 | 
 b5e999f3-0f10-3b01-a6d5-64dee8bf4820 | 2013-05-20 21:47:42 | 2013-05-22 
 20:13:08 |   NULL |
 |  3 | nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary4 
 | NFS | nfs  | 
 nfs://10.223.110.232/export/home/sangeetha/campo-systemp-1/secondary4 |   
1 | ZONE  | Image | c449842d-47e3-4694-aa6e-5e0ddc6890ab | 
 ac7f749d-eb30-394b-8ef8-ab52dc2b5c7c | 2013-05-22 19:16:46 | 2013-05-22 
 19:52:03 |   NULL |
 ++---+-+--+---++---+---+--+--+-+-++
 3 rows in set (0.00

[jira] [Updated] (CLOUDSTACK-723) Enhanced baremetal servers support on Cisco UCS

2013-05-22 Thread Animesh Chaturvedi (JIRA)


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

Animesh Chaturvedi updated CLOUDSTACK-723:
--

Component/s: Baremetal

 Enhanced baremetal servers support on Cisco UCS
 ---

 Key: CLOUDSTACK-723
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-723
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Baremetal
Reporter: Hari Kannan
Assignee: frank zhang
 Fix For: 4.2.0


 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Enhanced+Baremetal+support+on+Cisco+UCS
 Release Planning: 
 Dev List Discussion: http://apache.markmail.org/thread/5f64jmbnwjwfeyj4
 Functional Spec: 
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cisco+UCS+Integration+functional+spec
  Feature Branch: master 
 Percent  complete : 80%

--
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-2634) Object_Store_Refactor - When there are multiple secondary storages , all delta snapshots relating to volume should be created in the same secondary storage as the f

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


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

Min Chen reassigned CLOUDSTACK-2634:


Assignee: Min Chen

 Object_Store_Refactor - When there are multiple secondary storages , all 
 delta snapshots relating to volume should be created in the same secondary 
 storage as the first snapshot.
 --

 Key: CLOUDSTACK-2634
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2634
 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 object store.
Reporter: Sangeetha Hariharan
Assignee: Min Chen
 Fix For: 4.2.0


 Object_Store_Refactor - When there are multiple secondary storages, all delta 
 snapshots relating to volume should be created in the same secondary storage 
 as the first snapshot.
 Currently this check does not exists.

--
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-2627) [Automation] Failed to disassociate ip address from network


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

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

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

CLOUDSTACK-2627: disassociate ip address - assign return value of 
releaseIpAddress backend call to the result returned to the API caller


 [Automation] Failed to disassociate ip address from network 
 

 Key: CLOUDSTACK-2627
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2627
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.2.0
 Environment: Master build : Commit 
 fd4c0bfa9076dcc47094a9803fc943f87925b99e
 BVT 
Reporter: Rayees Namathponnan
Assignee: Alena Prokharchyk
 Fix For: 4.2.0

 Attachments: CLOUDSTACK-2627.rar


 Steps to reproduce 
 Execute BVT test 
 integration.smoke.test_network.TestPublicIP.test_public_ip_admin_account
 integration.smoke.test_network.TestPublicIP.test_public_ip_user_account
 or 
 Step 1 : Create new Network and acquire and IP
 Step 2 : Delete newly acquired IP 
 Result 
 Delete IP address failed with error  Failed to disassociate ip address
 2013-05-22 14:28:52,703 DEBUG [cloud.network.NetworkManagerImpl] 
 (Job-Executor-24:job-1048) Released a public ip id=22
 2013-05-22 14:28:52,708 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-24:job-1048) Complete async job-1048, jobStatus: 2, resultCode: 
 530, result: Error Code: 530 Error text: Failed to disassociate ip address
 2013-05-22 14:28:52,719 DEBUG [cloud.async.SyncQueueManagerImpl] 
 (Job-Executor-24:job-1048) Sync queue (134) is currently empty
 2013-05-22 14:28:52,721 DEBUG [cloud.api.ApiServlet] (catalina-exec-12:null) 
 ===START===  10.216.133.67 -- GET  
 command=queryAsyncJobResultjobId=7ac61258-66be-4285-80a0-93c16f843528response=jsonsessionkey=MYbBTIXQgKsW5dsSt7QGen4WcTA%3D_=1369247245682

--
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-2627) [Automation] Failed to disassociate ip address from network


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

Alena Prokharchyk resolved CLOUDSTACK-2627.
---

Resolution: Fixed

Fixed with c52879b88c4cc418289e87927f5c10ddbfe62f82

 [Automation] Failed to disassociate ip address from network 
 

 Key: CLOUDSTACK-2627
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2627
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.2.0
 Environment: Master build : Commit 
 fd4c0bfa9076dcc47094a9803fc943f87925b99e
 BVT 
Reporter: Rayees Namathponnan
Assignee: Alena Prokharchyk
 Fix For: 4.2.0

 Attachments: CLOUDSTACK-2627.rar


 Steps to reproduce 
 Execute BVT test 
 integration.smoke.test_network.TestPublicIP.test_public_ip_admin_account
 integration.smoke.test_network.TestPublicIP.test_public_ip_user_account
 or 
 Step 1 : Create new Network and acquire and IP
 Step 2 : Delete newly acquired IP 
 Result 
 Delete IP address failed with error  Failed to disassociate ip address
 2013-05-22 14:28:52,703 DEBUG [cloud.network.NetworkManagerImpl] 
 (Job-Executor-24:job-1048) Released a public ip id=22
 2013-05-22 14:28:52,708 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-24:job-1048) Complete async job-1048, jobStatus: 2, resultCode: 
 530, result: Error Code: 530 Error text: Failed to disassociate ip address
 2013-05-22 14:28:52,719 DEBUG [cloud.async.SyncQueueManagerImpl] 
 (Job-Executor-24:job-1048) Sync queue (134) is currently empty
 2013-05-22 14:28:52,721 DEBUG [cloud.api.ApiServlet] (catalina-exec-12:null) 
 ===START===  10.216.133.67 -- GET  
 command=queryAsyncJobResultjobId=7ac61258-66be-4285-80a0-93c16f843528response=jsonsessionkey=MYbBTIXQgKsW5dsSt7QGen4WcTA%3D_=1369247245682

--
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-2632) [Automation] Failed to stop VR with null pointer exception


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

Alena Prokharchyk commented on CLOUDSTACK-2632:
---

Related to pVlan functionality. 

 [Automation] Failed to stop VR with null pointer exception 
 ---

 Key: CLOUDSTACK-2632
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2632
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.2.0
 Environment: VMware
 Master branch build (4.2.0)
Reporter: Rayees Namathponnan
Priority: Blocker
 Fix For: 4.2.0


 This issue is observed in automation VMare environment 
 Steps to reproduce 
 Step 1 : Create an account 
 Step 2 : login to account and create a VM 
 Step 3 : Delete the account 
 VR always shows in stoping state, and null pointer error exception 
 pAnswer } }
 2013-05-22 15:50:15,283 DEBUG [agent.manager.AgentAttache] 
 (DirectAgent-236:null) Seq 4-826868349: No more commands found
 2013-05-22 15:50:15,283 DEBUG 
 [network.router.VirtualNetworkApplianceManagerImpl] (AccountChecker-1:null) 
 Successfully updated user statistics as a part of domR 
 VM[DomainRouter|r-127-QA] reboot/stop
 2013-05-22 15:50:15,288 WARN  [cloud.network.NetworkManagerImpl] 
 (AccountChecker-1:null) Unable to complete shutdown of the network elements 
 due to element: VirtualRouter
 java.lang.NullPointerException
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.finalizeStop(VirtualNetworkApplianceManagerImpl.java:2612)
 at 
 com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.finalizeStop(VpcVirtualNetworkApplianceManagerImpl.java:1396)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1179)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.stop(VirtualNetworkApplianceManagerImpl.java:2741)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.stop(VirtualNetworkApplianceManagerImpl.java:258)
 at 
 com.cloud.network.element.VirtualRouterElement.shutdown(VirtualRouterElement.java:657)
 at 
 com.cloud.network.NetworkManagerImpl.shutdownNetworkElementsAndResources(NetworkManagerImpl.java:2625)
 at 
 com.cloud.network.NetworkManagerImpl.shutdownNetwork(NetworkManagerImpl.java:2555)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 com.cloud.network.NetworkManagerImpl.destroyNetwork(NetworkManagerImpl.java:2684)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:655)
 at 
 com.cloud.user.AccountManagerImpl$AccountCleanupTask.run(AccountManagerImpl.java:1460)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at 
 java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
 at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at java.lang.Thread.run(Thread.java:722)
 2013-05-22 15:50:15,294 DEBUG [cloud.network.NetworkManagerImpl] 
 (AccountChecker-1:null) Network is not not in the correct state to be 
 destroyed: Implemented
 2013-05-22 15:50:15,294 WARN  [cloud.user.AccountManagerImpl] 
 (AccountChecker-1:null) Unable to destroy network Ntwk[278|Guest|8] as a part 
 of account id=115 cleanup.

--
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-2518) failed to create same private gateway in two different vpc


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

Alena Prokharchyk reassigned CLOUDSTACK-2518:
-

Assignee: Alena Prokharchyk

 failed to create same private gateway in two different vpc
 --

 Key: CLOUDSTACK-2518
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2518
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Reporter: Jayapal Reddy
Assignee: Alena Prokharchyk
 Fix For: 4.2.0


 Failed to create same private gateway in two different vpc because 
 a. the private networks in network table does not have vpc id.
 So private networks for the vpc not differentiated.
Network privateNetwork = 
 _networksDao.getPrivateNetwork(BroadcastDomainType.Vlan.toUri(vlan).toString(),
  cidr,
 networkOwnerId, pNtwk.getDataCenterId());
 if (privateNetwork == null) {
 b. cloudstack not creating two private networks of different vpc with same 
 vlan, cidr in zone.

--
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-2504) not able to create network offering with specify Vlan=true and sourcenat service selected


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

Alena Prokharchyk commented on CLOUDSTACK-2504:
---

This is the UI bug. UI should always pass specifyIpRanges=false for Isolated 
networks.

 not able to create network offering with specify Vlan=true and sourcenat 
 service selected
 -

 Key: CLOUDSTACK-2504
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2504
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.2.0
 Environment: build:
 CloudStack-non-OSS-MASTER-329-rhel6.3
Reporter: shweta agarwal
 Fix For: 4.2.0


 Repro steps:
 1.Goto network offerings tab
 2. Try to create network offering with specify vlan=true and sourcenat 
 service selected
 Bug:
 Gets message SpecifyIpRanges can only be true for Shared network offerings 
 and Isolated with no SourceNat service
 API : 
 http://10.147.59.212:8080/client/api?command=createNetworkOfferingresponse=jsonsessionkey=dNddt90WhymsHK2%2FNj9eD5fZbWk%3Dname=+mmdisplayText=mmguestIpType=IsolatedspecifyVlan=trueservicecapabilitylist%5B0%5D.service=SourceNatservicecapabilitylist%5B0%5D.capabilitytype=SupportedSourceNatTypesservicecapabilitylist%5B0%5D.capabilityvalue=peraccountavailability=Optionalstate=Creatingstatus=Creatingallocationstate=CreatingsupportedServices=SourceNatspecifyIpRanges=trueisPersistent=falseconservemode=falseserviceProviderList%5B0%5D.service=SourceNatserviceProviderList%5B0%5D.provider=VirtualRoutertraffictype=GUEST_=1368599334993
 Expected result:
 APi should set specifyIpRanges=true only when no SourceNat service is selected

--
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-2632) [Automation] Failed to stop VR with null pointer exception


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

Sheng Yang reassigned CLOUDSTACK-2632:
--

Assignee: Sheng Yang

 [Automation] Failed to stop VR with null pointer exception 
 ---

 Key: CLOUDSTACK-2632
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2632
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.2.0
 Environment: VMware
 Master branch build (4.2.0)
Reporter: Rayees Namathponnan
Assignee: Sheng Yang
Priority: Blocker
 Fix For: 4.2.0


 This issue is observed in automation VMare environment 
 Steps to reproduce 
 Step 1 : Create an account 
 Step 2 : login to account and create a VM 
 Step 3 : Delete the account 
 VR always shows in stoping state, and null pointer error exception 
 pAnswer } }
 2013-05-22 15:50:15,283 DEBUG [agent.manager.AgentAttache] 
 (DirectAgent-236:null) Seq 4-826868349: No more commands found
 2013-05-22 15:50:15,283 DEBUG 
 [network.router.VirtualNetworkApplianceManagerImpl] (AccountChecker-1:null) 
 Successfully updated user statistics as a part of domR 
 VM[DomainRouter|r-127-QA] reboot/stop
 2013-05-22 15:50:15,288 WARN  [cloud.network.NetworkManagerImpl] 
 (AccountChecker-1:null) Unable to complete shutdown of the network elements 
 due to element: VirtualRouter
 java.lang.NullPointerException
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.finalizeStop(VirtualNetworkApplianceManagerImpl.java:2612)
 at 
 com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.finalizeStop(VpcVirtualNetworkApplianceManagerImpl.java:1396)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1179)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.stop(VirtualNetworkApplianceManagerImpl.java:2741)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.stop(VirtualNetworkApplianceManagerImpl.java:258)
 at 
 com.cloud.network.element.VirtualRouterElement.shutdown(VirtualRouterElement.java:657)
 at 
 com.cloud.network.NetworkManagerImpl.shutdownNetworkElementsAndResources(NetworkManagerImpl.java:2625)
 at 
 com.cloud.network.NetworkManagerImpl.shutdownNetwork(NetworkManagerImpl.java:2555)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 com.cloud.network.NetworkManagerImpl.destroyNetwork(NetworkManagerImpl.java:2684)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:655)
 at 
 com.cloud.user.AccountManagerImpl$AccountCleanupTask.run(AccountManagerImpl.java:1460)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at 
 java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
 at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at java.lang.Thread.run(Thread.java:722)
 2013-05-22 15:50:15,294 DEBUG [cloud.network.NetworkManagerImpl] 
 (AccountChecker-1:null) Network is not not in the correct state to be 
 destroyed: Implemented
 2013-05-22 15:50:15,294 WARN  [cloud.user.AccountManagerImpl] 
 (AccountChecker-1:null) Unable to destroy network Ntwk[278|Guest|8] as a part 
 of account id=115 cleanup.

--
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-2579) NPE in Account Delete operations


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

Sheng Yang reassigned CLOUDSTACK-2579:
--

Assignee: Sheng Yang

 NPE in Account Delete operations
 

 Key: CLOUDSTACK-2579
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2579
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.0
Reporter: Prasanna Santhanam
Assignee: Sheng Yang
Priority: Critical
 Fix For: 4.2.0


 Account deletions are failing with an NPE: Resources pile up when the 
 accounts are not deleting.
 2013-05-20 10:01:09,597 WARN  [cloud.user.AccountManagerImpl] 
 (AccountChecker-1:null) Failed to cleanup account Acct[6-test-3JBO9I] due to 
 java.lang.NullPointerException
 at 
 com.cloud.vm.UserVmManagerImpl.finalizeStop(UserVmManagerImpl.java:3060)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1179)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:432)
 at com.cloud.vm.UserVmManagerImpl.expunge(UserVmManagerImpl.java:1413)
 at 
 com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:595)
 at 
 com.cloud.user.AccountManagerImpl$AccountCleanupTask.run(AccountManagerImpl.java:1443)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at 
 java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
 at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:679)

--
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-2632) [Automation] Failed to stop VR with null pointer exception


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

Sheng Yang resolved CLOUDSTACK-2632.


Resolution: Fixed

Fixed at:

commit 92ad6abab0063771dffaabb7c9d6d8256083c5be
Author: Sheng Yang sheng.y...@citrix.com
Date:   Tue May 21 14:46:31 2013 -0700

PVLAN: Fix NPE when VM are in allocated state

If vlan is not assigned for VM, nic.getBroadcastUri() would be null. Then 
just
ignore it.


 [Automation] Failed to stop VR with null pointer exception 
 ---

 Key: CLOUDSTACK-2632
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2632
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.2.0
 Environment: VMware
 Master branch build (4.2.0)
Reporter: Rayees Namathponnan
Assignee: Sheng Yang
Priority: Blocker
 Fix For: 4.2.0


 This issue is observed in automation VMare environment 
 Steps to reproduce 
 Step 1 : Create an account 
 Step 2 : login to account and create a VM 
 Step 3 : Delete the account 
 VR always shows in stoping state, and null pointer error exception 
 pAnswer } }
 2013-05-22 15:50:15,283 DEBUG [agent.manager.AgentAttache] 
 (DirectAgent-236:null) Seq 4-826868349: No more commands found
 2013-05-22 15:50:15,283 DEBUG 
 [network.router.VirtualNetworkApplianceManagerImpl] (AccountChecker-1:null) 
 Successfully updated user statistics as a part of domR 
 VM[DomainRouter|r-127-QA] reboot/stop
 2013-05-22 15:50:15,288 WARN  [cloud.network.NetworkManagerImpl] 
 (AccountChecker-1:null) Unable to complete shutdown of the network elements 
 due to element: VirtualRouter
 java.lang.NullPointerException
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.finalizeStop(VirtualNetworkApplianceManagerImpl.java:2612)
 at 
 com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.finalizeStop(VpcVirtualNetworkApplianceManagerImpl.java:1396)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1179)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.stop(VirtualNetworkApplianceManagerImpl.java:2741)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.stop(VirtualNetworkApplianceManagerImpl.java:258)
 at 
 com.cloud.network.element.VirtualRouterElement.shutdown(VirtualRouterElement.java:657)
 at 
 com.cloud.network.NetworkManagerImpl.shutdownNetworkElementsAndResources(NetworkManagerImpl.java:2625)
 at 
 com.cloud.network.NetworkManagerImpl.shutdownNetwork(NetworkManagerImpl.java:2555)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 com.cloud.network.NetworkManagerImpl.destroyNetwork(NetworkManagerImpl.java:2684)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:655)
 at 
 com.cloud.user.AccountManagerImpl$AccountCleanupTask.run(AccountManagerImpl.java:1460)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at 
 java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
 at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at java.lang.Thread.run(Thread.java:722)
 2013-05-22 15:50:15,294 DEBUG [cloud.network.NetworkManagerImpl] 
 (AccountChecker-1:null) Network is not not in the correct state to be 
 destroyed: Implemented
 2013-05-22 15:50:15,294 WARN  [cloud.user.AccountManagerImpl] 
 (AccountChecker-1:null) Unable to destroy network Ntwk[278|Guest|8] as a part 
 of account id=115 cleanup.

--
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-2580) [RVR] Failed to deploy Redundant Router VMs


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

Sheng Yang reassigned CLOUDSTACK-2580:
--

Assignee: Prachi Damle  (was: Sheng Yang)

It's new deploy planner's bug, assigned to Prachi.

 [RVR] Failed to deploy Redundant Router VMs
 ---

 Key: CLOUDSTACK-2580
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2580
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.2.0
 Environment: commit # 85d54cd1c088997dd08f0328984bee1a55703636
Reporter: venkata swamybabu budumuru
Assignee: Prachi Damle
Priority: Blocker
 Fix For: 4.2.0

 Attachments: additional_mgmt_server.log, logs.tgz


 Steps to reproduce :
 1. Have CloudStack setup with advanced zone having a VMware cluster with 1 
 host
 - Adv zone
 - 1 VMware cluster
 - 1 ESXi 5.1 host
 2. Create a network offering with RVR enabled 
 mysql select * from network_offerings where id=14\G
 *** 1. row ***
id: 14
  name: RVROffering
  uuid: 50fb0832-08b0-417b-ab2f-612a3cef9911
   unique_name: RVROffering
  display_text: RVROffering
   nw_rate: NULL
   mc_rate: 10
  traffic_type: Guest
  tags: NULL
   system_only: 0
  specify_vlan: 0
   service_offering_id: NULL
 conserve_mode: 0
   created: 2013-05-20 13:04:02
   removed: NULL
   default: 0
  availability: Optional
  dedicated_lb_service: 1
 shared_source_nat_service: 0
  sort_key: 0
  redundant_router_service: 1
 state: Enabled
guest_type: Isolated
elastic_ip_service: 0
   eip_associate_public_ip: 0
elastic_lb_service: 0
 specify_ip_ranges: 0
inline: 0
 is_persistent: 0
   internal_lb: 0
 public_lb: 1
 3. select * from networks where id=209\G
 mysql select * from networks where id=209\G
 *** 1. row ***
id: 209
  name: RVRNet1
  uuid: 2b031a8f-ec65-495c-9251-b9aa973334eb
  display_text: RVRNet1
  traffic_type: Guest
 broadcast_domain_type: Vlan
 broadcast_uri: vlan://904
   gateway: 10.1.1.1
  cidr: 10.1.1.0/24
  mode: Dhcp
   network_offering_id: 14
   physical_network_id: 201
data_center_id: 2
 guru_name: ExternalGuestNetworkGuru
 state: Implementing
   related: 209
 domain_id: 2
account_id: 3
  dns1: NULL
  dns2: NULL
 guru_data: NULL
set_fields: 0
  acl_type: Account
network_domain: cs3cloud.internal
reservation_id: 377f4a17-24c6-4bb3-9d08-f60e3d3782f1
guest_type: Isolated
  restart_required: 0
   created: 2013-05-20 13:05:09
   removed: NULL
 specify_ip_ranges: 0
vpc_id: NULL
   ip6_gateway: NULL
  ip6_cidr: NULL
  network_cidr: NULL
   display_network: 1
network_acl_id: NULL
 4. Create at least one non-ROOT domain user. Login as this user and try to 
 create a VM using the above network.
 Observations:
 (i) First router of the RVR setup (in this case r-13-VM) has come up fine.
 (ii) But, the second router failed saying the host is in avoid set and then 
 it kept on trying and it filled the log file with those entries for thousands 
 of times.
 Here is the log snippet from mgmt server 
   39355 2013-05-20 09:05:11,087 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (catalina-exec-21:null) submit async job-31, details: AsyncJobVO {id:31, 
 userId: 3, accountId: 3, sessionKey: null, instanceType: VirtualMachine, 
 instanceId: 12, cmd: org.apache.cloudstack.api.comma
 nd.user.vm.DeployVMCmd, cmdOriginator: null, cmdInfo: 
 {sessionkey:Mo6WUsz5nA2NAgP1DR+kefP4PM0\u003d,ctxUserId:3,serviceOfferingId:e26d4e7e-ceda-4f2d-bbf9-bbdb1f47cf5c,httpmethod:GET,zoneId:e078d6bf-8c54-4a20-a592-c56f7730e69e,templateId:5c
 
 c4feee-c12d-11e2-8a66-069f2caa,response:json,id:12,networkIds:2b031a8f-ec65-495c-9251-b9aa973334eb,hypervisor:VMware,name:VM1RVRZone2,_:1369035372563,ctxAccountId:3,ctxStartEventId:127,displayname:VM1RVRZone2},
  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
 processStatus: 0, resultCode: 0,

[jira] [Resolved] (CLOUDSTACK-1981) NPE's when accessing Management server while its coming up


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

Alena Prokharchyk resolved CLOUDSTACK-1981.
---

Resolution: Won't Fix

Resolving the issue as won't fix. There is no way to verify the login 
credentials when Account related components are not fully loaded. As long as 
you can't login with incorrect credentials, its fine. Seeing NPEs in the log is 
harmless.

 NPE's when accessing Management server while its coming up
 --

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


 Setup: Advanced Networking Zone with Xen 6.1 
 MS:  Rhel 6.3
 Steps:
 1. Stop Management Server [service cloudstack-management stop]
 2. Start Management server[service cloudstack-management start]
 3. Try to access Management server before its completely up 
 Observation:
 NPE's observed while accessing Management server while its coming up.
 2013-04-09 12:09:20,059 INFO  [utils.component.ComponentContext] (main:null) 
 Setup Spring Application context
 2013-04-09 12:09:21,173 DEBUG [utils.crypt.EncryptionSecretKeyChecker] 
 (main:null) Encryption Type: file
 2013-04-09 12:09:32,919 INFO  [cloud.serializer.GsonHelper] (main:null) 
 Default Builder inited.
 2013-04-09 12:09:34,681 INFO  [cloudstack.discovery.ApiDiscoveryServiceImpl] 
 (main:null) Api Discovery Service: Annotation, docstrings, api relation graph 
 processed in 433.24 ms
 2013-04-09 12:09:35,752 INFO  [cloud.api.ApiServer] (Thread-7:null) ApiServer 
 listening on port 8096
 2013-04-09 12:09:36,938 INFO  [hypervisor.vmware.VmwareServerDiscoverer] 
 (main:null) VmwareServerDiscoverer is constructed
 2013-04-09 12:09:37,327 INFO  [web.context.ContextLoader] (main:null) Root 
 WebApplicationContext: initialization completed in 24721 ms
 2013-04-09 12:09:37,357 INFO  [cloud.utils.LogUtils] (main:null) log4j 
 configuration found at /etc/cloudstack/management/log4j-cloud.xml
 2013-04-09 12:09:37,392 INFO  
 [factory.annotation.AutowiredAnnotationBeanPostProcessor] (main:null) JSR-330 
 'javax.inject.Inject' annotation found and supported for autowiring
 2013-04-09 12:09:37,947 INFO  
 [factory.annotation.AutowiredAnnotationBeanPostProcessor] 
 (catalina-exec-1:null) JSR-330 'javax.inject.Inject' annotation found and 
 supported for autowiring
 2013-04-09 12:09:38,031 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null) 
 ===START===  10.144.6.39 -- GET  
 command=listVirtualMachinesresponse=jsonsessionkey=PDaiFIZwxuXdaa%2FO9yAL2wwo4C4%3DlistAll=truepage=1pagesize=20_=1365489683621
 2013-04-09 12:09:38,054 ERROR [cloud.api.ApiServlet] (catalina-exec-1:null) 
 unknown exception writing api response
 java.lang.NullPointerException
 at 
 com.cloud.user.AccountManagerImpl.getSystemUser(AccountManagerImpl.java:279)
 at 
 com.cloud.user.AccountManagerImpl.getSystemUser(AccountManagerImpl.java:142)
 at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:238)
 at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
 at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
 at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 at 
 org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
 at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
 at 
 org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889)
 at 
 org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721)
 at 
 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2268)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at

[jira] [Created] (CLOUDSTACK-2635) Object_Store_Refactor - Snapshots - When snapshots get deleted , they are not marked as Removed in snapshots table.