date:20130822


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

Sateesh Chodapuneedi reassigned CLOUDSTACK-4435:


Assignee: Sateesh Chodapuneedi

 [VMWARE]System VM's are failed to start with Nexus enabled Zone 
 

 Key: CLOUDSTACK-4435
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4435
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Devices, VMware
Affects Versions: 4.2.1
Reporter: Sailaja Mada
Assignee: Sateesh Chodapuneedi
Priority: Blocker
 Fix For: 4.2.1

 Attachments: issuenexus.rar


 Steps:
 1. Upgraded from 3.0.7 to 4.2 ( VMWARE Zone with Standard vSwitch)
 2. Enable Nexus global config variable
 3. Tried to add new Zone with VMWARE Nexus enabled
 4. Added two physical networks ( 1 - Mgmt - vSwitch0,,vmwaresvs 2- Public  
 guest - sailajanewpp,,nexusdvs)
 5. Provided VSM details while adding cluster
 Observation:
 System VM's are failed to start with Nexus enabled Zone saying Nexus details 
 can not be retrieved from DB. 
 2013-08-22 00:37:01,732 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null) 
 ===START===  10.101.255.30 -- GET  
 command=queryAsyncJobResultjobId=921f4c19-a655-4234-82c4-66efcbe73933response=jsonsessionkey=CNY1grUrySJwTE%2BpFM3btn1i4Xs%3D_=1377112271133
 2013-08-22 00:37:01,782 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null) 
 ===END===  10.101.255.30 -- GET  
 command=queryAsyncJobResultjobId=921f4c19-a655-4234-82c4-66efcbe73933response=jsonsessionkey=CNY1grUrySJwTE%2BpFM3btn1i4Xs%3D_=1377112271133
 2013-08-22 00:37:02,170 WARN  [vmware.resource.VmwareResource] 
 (DirectAgent-128:10.102.192.18) StartCommand failed due to Exception: 
 java.lang.Exception
 Message: Failed to retrieve required credentials of Nexus VSM from database.
 java.lang.Exception: Failed to retrieve required credentials of Nexus VSM 
 from database.
 at 
 com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.getValidatedVsmCredentials(HypervisorHostHelper.java:183)
 at 
 com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.createPortProfile(HypervisorHostHelper.java:201)
 at 
 com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:584)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:3308)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2904)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:514)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at java.lang.Thread.run(Thread.java:679)
 2013-08-22 00:37:02,196 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-128:null) Seq 14-773455885: Cancelling because one of the 
 answers is false and it is stop on error.
 2013-08-22 00:37:02,196 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-128:null) Seq 14-773455885: Response Received:
 2013-08-22 00:37:02,199 DEBUG [agent.transport.Request] 
 (DirectAgent-128:null) Seq 14-773455885: Processing:  { Ans: , MgmtId: 
 187767034175903, via: 14, Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.StartAnswer:{vm:{id:30,name:s-30-VM,bootloader:HVM,type:SecondaryStorageVm,cpus:1,minSpeed:500,maxSpeed:500,minRam:268435456,maxRam:268435456,hostName:s-30-VM,arch:x86_64,os:Debian
  GNU/Linux 5.0 (32-bit),bootArgs: template=domP type=secstorage 
 host=10.102.192.207 port=8250 name=s-30-VM zone=3 pod=3 guid=s-30-VM 
 resource=com.cloud.storage.resource.PremiumSecondaryStorageResource 
 instance=SecStorage sslcopy=true role=templateProcessor mtu=1500 
 eth2ip=10.102.196.220 eth2mask=255.255.255.0 gateway=10.102.196.1 
 public.network.device=eth2 eth0mask=0.0.0.0 eth0ip=0.0.0.0 
 eth1ip=10.102.195.150 eth1mask=255.255.252.0 mgmtcidr=10.102.192.0/22 
 localgw=10.102.192.1 private.network.device=eth1 eth3ip=10.102.195.152 
 eth3mask=255.255.252.0 storageip=10.102.195.152

[jira] [Created] (CLOUDSTACK-4439) Document vSphere HA host tag limitation

2013-08-22 Thread Kirk Kosinski (JIRA)

Kirk Kosinski created CLOUDSTACK-4439:
-

 Summary: Document vSphere HA host tag limitation
 Key: CLOUDSTACK-4439
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4439
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Doc
Affects Versions: 4.2.0
Reporter: Kirk Kosinski
Priority: Minor


If host tags are configured in CloudStack for VM placement in a vSphere 
cluster, they will be ignored by the native vSphere HA. The result is that in 
an HA event, vSphere HA might boot a VM on hosts that CloudStack would not use 
due to host tags. I cannot find an explanation of this and it should be 
documented.

--
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-3877) Unable to Resize Volume (kvm, vmware)

2013-08-22 Thread Rajesh Battala (JIRA)


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

Rajesh Battala closed CLOUDSTACK-3877.
--


 Unable to Resize Volume (kvm, vmware)
 -

 Key: CLOUDSTACK-3877
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3877
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, Storage Controller
Affects Versions: 4.1.1, 4.2.0
 Environment: kvm, 4.2 code.
 instances running on Kvm. and volumes attached and present in cluster scope 
 primary storage
Reporter: Rajesh Battala
Assignee: Rajesh Battala
Priority: Blocker
 Fix For: 4.1.1, 4.2.0


 ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-8:job-40 = [ 
 89b9f53d-abaa-47fe-91ba-13795b647a2b ]) Unexpected exception while executing 
 org.apache.cloudstack.api.command.user.volume.ResizeVolumeCmd
 com.cloud.exception.InvalidParameterValueException: Can't resize a volume 
 that has never been attached, not sure which hypervisor type. Recreate volume 
 to resize.
 at 
 com.cloud.storage.VolumeManagerImpl.resizeVolume(VolumeManagerImpl.java:1108)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 com.cloud.storage.VolumeManagerImpl.resizeVolume(VolumeManagerImpl.java:185)
 at 
 org.apache.cloudstack.api.command.user.volume.ResizeVolumeCmd.execute(ResizeVolumeCmd.java:137)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
 at 
 com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at java.lang.Thread.run(Thread.java:722)

--
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-4440) CloudStack should handle native VMware HA for virtual routers

2013-08-22 Thread Kirk Kosinski (JIRA)

Kirk Kosinski created CLOUDSTACK-4440:
-

 Summary: CloudStack should handle native VMware HA for virtual 
routers
 Key: CLOUDSTACK-4440
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4440
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Doc, Management Server
Affects Versions: 4.2.0
Reporter: Kirk Kosinski
Priority: Minor


Currently when a virtual router is rebooted by native VMware HA in vSphere, it 
will lose its network and iptables configuration and cause connectivity 
problems for VMs. Resolving this requires manual intervention by the CloudStack 
administrator; the router must be rebooted, or the network restarted.

This behavior is not ideal and will prolong downtime caused by an HA event, and 
there is no point for the non-functional virtual router to even be running. 
CloudStack should handle this situation gracefully by reconfiguring a virtual 
router that is successfully rebooted by VMware HA. 

In the meantime this limitation should be documented.

--
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-4437) Fix iso usage event count to match the number of image stores


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

Srikanteswararao Talluri updated CLOUDSTACK-4437:
-

Assignee: Srikanteswararao Talluri

 Fix iso usage event count to match the number of image stores
 -

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


 Check ISO.CREATE event in events table
   begin captured logging  
 testclient.testcase.TestISOUsage: DEBUG: Deleting ISO with ID: 
 e99eaac5-8ab3-454b-978b-09f0255dc399
 testclient.testcase.TestISOUsage: DEBUG: select project_account_id from 
 projects where uuid = '361e1eba-cdc9-4568-8738-ef209afc66f0';
 testclient.testcase.TestISOUsage: DEBUG: select type from usage_event where 
 account_id = '369';
 testclient.testcase.TestISOUsage: DEBUG: Query result: [(u'ISO.CREATE',), 
 (u'ISO.CREATE',), (u'ISO.DELETE',), (u'ISO.DELETE',)]
 -  end captured logging  -
 Stacktrace
 Traceback (most recent call last):
   File /usr/local/lib/python2.7/unittest/case.py, line 318, in run
 testMethod()
   File /root/cloudstack/test/integration/component/test_project_usage.py, 
 line 977, in test_01_ISO_usage
 Check ISO.CREATE event in events table
   File /usr/local/lib/python2.7/unittest/case.py, line 494, in assertEqual
 assertion_func(first, second, msg=msg)
   File /usr/local/lib/python2.7/unittest/case.py, line 487, in 
 _baseAssertEqual
 raise self.failureException(msg)
 AssertionError: Check ISO.CREATE event in events table
   begin captured logging  
 testclient.testcase.TestISOUsage: DEBUG: Deleting ISO with ID: 
 e99eaac5-8ab3-454b-978b-09f0255dc399
 testclient.testcase.TestISOUsage: DEBUG: select project_account_id from 
 projects where uuid = '361e1eba-cdc9-4568-8738-ef209afc66f0';
 testclient.testcase.TestISOUsage: DEBUG: select type from usage_event where 
 account_id = '369';
 testclient.testcase.TestISOUsage: DEBUG: Query result: [(u'ISO.CREATE',), 
 (u'ISO.CREATE',), (u'ISO.DELETE',), (u'ISO.DELETE',)]
 -  end captured logging  -

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

[jira] [Closed] (CLOUDSTACK-4090) [Upgrade] System VM's are failed to start on a new zone(VMWARE Nexus Zone) which is created after upgrade


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

Sailaja Mada closed CLOUDSTACK-4090.



This issue is not observed with 305 Patch A - 307 - 4.2 path  307 - 4.2 
path.

Hence closing the bug. 

 [Upgrade] System VM's are failed to start on a new zone(VMWARE Nexus Zone) 
 which is created after upgrade 
 --

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

 Attachments: apilog.log, Bforeupgraedecloud-backup.dmp, 
 postupgradecloud-backup.dmp


 Steps:
 1. Upgraded from 305 Patch A to 4.2 with Xenserver Zone
 2. Enabled Nexus global config value 
 3. Configure one more Adv zone with VMWARE cluster with Nexus 1000v Switch 
 enabled 
 4. Seeded secondary storage with new 4.2 vMWARE template (vh7)
 Physical network 1 : 
 Mgmt Traffic label name  - vSwitch0,,vmwaresvs 
 Physical network 1 : 
 Public  Guest Traffic label name  - nexuspp91,,nexusdvs
 Observation:System VM's are failed to start on a new zone(VMWARE Nexus Zone) 
 which is created after upgrade 
 After upgrade I have enabled Nexus vSwtich and configured zone with Nexus 
 cluster.  Now system VM’s are coming up now : I I am using vh7 template) - 
 2013-08-05 21:01:52,084 DEBUG 
 [network.router.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:null) Found 0 networks to update RvR status.
 2013-08-05 21:01:52,091 DEBUG [storage.motion.AncientDataMotionStrategy] 
 (consoleproxy-1:null) copyAsync inspecting src type TEMPLATE copyAsync 
 inspecting dest type TEMPLATE
 2013-08-05 21:01:52,174 DEBUG [agent.transport.Request] (consoleproxy-1:null) 
 Seq 8-268894239: Sending  { Cmd , MgmtId: 7674049379768, via: 8, Ver: v1, 
 Flags: 100011, 
 [{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/1/8/,origUrl:http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova,uuid:8,id:8,format:OVA,accountId:1,checksum:7137e453f950079ea2ba6feaafd939e8,hvm:false,displayText:SystemVM
  Template 
 (vSphere),imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.102.192.100/cpg_vol/sailaja/vmwaress1/,_role:Image}},name:routing-8,hypervisorType:VMware}},destTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{origUrl:http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova,uuid:8,id:8,format:OVA,accountId:1,checksum:7137e453f950079ea2ba6feaafd939e8,hvm:false,displayText:SystemVM
  Template 
 (vSphere),imageDataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:55e6d095-7e22-3f4a-b533-874a9fede8df,id:202,poolType:NetworkFilesystem,host:10.102.192.100,path:/cpg_vol/sailaja/vmwareps1,port:2049}},name:routing-8,hypervisorType:VMware}},executeInSequence:false,wait:10800}}]
  }
 2013-08-05 21:01:52,175 DEBUG [agent.transport.Request] (consoleproxy-1:null) 
 Seq 8-268894239: Executing:  { Cmd , MgmtId: 7674049379768, via: 8, Ver: v1, 
 Flags: 100011, 
 [{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/1/8/,origUrl:http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova,uuid:8,id:8,format:OVA,accountId:1,checksum:7137e453f950079ea2ba6feaafd939e8,hvm:false,displayText:SystemVM
  Template 
 (vSphere),imageDataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.102.192.100/cpg_vol/sailaja/vmwaress1/,_role:Image}},name:routing-8,hypervisorType:VMware}},destTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{origUrl:http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova,uuid:8,id:8,format:OVA,accountId:1,checksum:7137e453f950079ea2ba6feaafd939e8,hvm:false,displayText:SystemVM
  Template 
 (vSphere),imageDataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:55e6d095-7e22-3f4a-b533-874a9fede8df,id:202,poolType:NetworkFilesystem,host:10.102.192.100,path:/cpg_vol/sailaja/vmwareps1,port:2049}},name:routing-8,hypervisorType:VMware}},executeInSequence:false,wait:10800}}]
  }
 2013-08-05 21:01:52,186 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-204:null) Seq 8-268894239: Executing request
 2013-08-05 21:01:52,318 DEBUG 
 [network.router.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:null) Found 5 routers to update status.
 2013-08-05 21:01:52,323 DEBUG 
 [network.router.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:null) Found 0 networks to update RvR

[jira] [Created] (CLOUDSTACK-4441) test_02_deploy_ha_vm_from_iso test needs a usable ISO in the services dictionary

Srikanteswararao Talluri created CLOUDSTACK-4441:


 Summary: test_02_deploy_ha_vm_from_iso test needs a usable ISO in 
the services dictionary
 Key: CLOUDSTACK-4441
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4441
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Test
Affects Versions: 4.2.1
Reporter: Srikanteswararao Talluri
 Fix For: 4.2.1


VM deployment from ISO is failing

Execute cmd: asyncquery failed, due to: {errorcode : 533, errortext : u'Unable 
to create a deployment for VM[User|03cedf48-f467-4940-99d1-ea3a35236ee2]'}
  begin captured logging  
testclient.testcase.TestDeployHaEnabledVM: DEBUG: Registered ISO: testISO
testclient.testcase.TestDeployHaEnabledVM: DEBUG: Deploying instance in the 
account: test-7R7739
-  end captured logging  -
Stacktrace

Traceback (most recent call last):
  File /usr/local/lib/python2.7/unittest/case.py, line 318, in run
testMethod()
  File /root/cloudstack/test/integration/component/test_stopped_vm.py, line 
965, in test_02_deploy_ha_vm_from_iso
startvm=True
  File /usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py, 
line 388, in create
virtual_machine = apiclient.deployVirtualMachine(cmd, method=method)
  File 
/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
 line 1177, in deployVirtualMachine
response = self.connection.marvin_request(command, response_type=response, 
method=method)
  File /usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, 
line 230, in marvin_request
response = self.poll(asyncJobId, response_type)
  File /usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, 
line 91, in poll
asyncquery, asyncResonse.jobresult)
cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode : 
533, errortext : u'Unable to create a deployment for 
VM[User|03cedf48-f467-4940-99d1-ea3a35236ee2]'}
  begin captured logging  
testclient.testcase.TestDeployHaEnabledVM: DEBUG: Registered ISO: testISO
testclient.testcase.TestDeployHaEnabledVM: DEBUG: Deploying instance in the 
account: test-7R7739

--
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-4414) [VMWARE] System VM's are failed to start with new Nexus enabled Zone after upgrade (Nexus Details provided are not stored in DB)

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


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

Sailaja Mada closed CLOUDSTACK-4414.



With the fix provided , Nexus 1000v Switch details are available in the DB.

INSERT INTO `virtual_supervisor_module` VALUES 
(1,NULL,0,NULL,'admin','sItvYSekow8kCjP9TinwuXW44hDxnoAK','10.102.192.81',0,0,0,0,0,NULL,NULL,'Enabled');
/*!4 ALTER TABLE `virtual_supervisor_module` ENABLE KEYS */;


But System VM's are still failing to start while trying to retrieve Nexus 
1000v(VSM) details from DB).

New ticket is created for this. Closing this.



 [VMWARE] System VM's are failed to start with new Nexus enabled Zone after 
 upgrade  (Nexus Details provided are not stored in DB) 
 --

 Key: CLOUDSTACK-4414
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4414
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Devices, Upgrade, VMware
Affects Versions: 4.2.0
Reporter: Sailaja Mada
Assignee: Sateesh Chodapuneedi
Priority: Blocker
 Fix For: 4.2.0

 Attachments: alllogs.rar


 Steps: 
 1. Upgraded from 3.0.7 to 4.2 ( VMWARE Zone with Standard vSwitch)
 2. Enable Nexus global config variable
 3. Tried to add new Zone with VMWARE Nexus enabled
 4. Added two physical networks ( 1 - Mgmt - vSwitch0,,vmwaresvs 2- Public  
 guest - sailajanewpp,,nexusdvs)
 5. Provided VSM details while adding cluster
 Observation:
 System VM's are failed to start with Nexus enabled Zone saying Nexus details 
 can not be retrieved from DB.
 2013-08-20 15:52:15,497 INFO [vmware.resource.VmwareResource] 
 (DirectAgent-345:10.102.192.18) Prepare NIC device based on NicTO: 
 {deviceId:2,networkRateMbps:-1,defaultNic:true,uuid:3ad57763-dfe8-467a-b21d-07de6ff64135,ip:10.102.196.221,netmask:255.255.255.0,gateway:10.102.196.1,mac:06:62:f8:00:00:08,dns1:10.103.128.15,broadcastType:Vlan,type:Public,broadcastUri:vlan://100,isolationUri:vlan://100,isSecurityGroupEnabled:false,name:sailajanewpp,,nexusdvs}
 2013-08-20 15:52:15,500 INFO [vmware.resource.VmwareResource] 
 (DirectAgent-345:10.102.192.18) Prepare network on nexusdvs 
 P[sailajanewpp:untagged] with name prefix: cloud.public
 2013-08-20 15:52:15,508 INFO [vmware.mo.HypervisorHostHelper] 
 (DirectAgent-345:10.102.192.18) Found Ethernet port profile sailajanewpp
 2013-08-20 15:52:15,512 INFO [vmware.mo.HypervisorHostHelper] 
 (DirectAgent-345:10.102.192.18) Port profile 
 cloud.public.100.0.1-sailajanewpp not found.
 2013-08-20 15:52:15,512 ERROR [vmware.mo.HypervisorHostHelper] 
 (DirectAgent-345:10.102.192.18) Failed to retrieve required credentials of 
 Nexus VSM from database.
 2013-08-20 15:52:15,513 WARN [vmware.resource.VmwareResource] 
 (DirectAgent-345:10.102.192.18) StartCommand failed due to Exception: 
 java.lang.Exception
 Message: Failed to retrieve required credentials of Nexus VSM from database.
 java.lang.Exception: Failed to retrieve required credentials of Nexus VSM 
 from database.
 at 
 com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.getValidatedVsmCredentials(HypervisorHostHelper.java:183)
 at 
 com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.createPortProfile(HypervisorHostHelper.java:201)
 at 
 com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:584)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:3308)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2904)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:514)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at java.lang.Thread.run(Thread.java:679)
 2013-08-20 15:52:15,515 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-345:null) Seq 10-374145270: Cancelling because one of the 
 answers is false

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

2013-08-22 Thread Dave Cahill (JIRA)

Dave Cahill created CLOUDSTACK-4442:
---

 Summary: Source NAT not applied when network starts up
 Key: CLOUDSTACK-4442
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4442
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Network Devices
Affects Versions: 4.2.0
Reporter: Dave Cahill
Priority: Blocker
 Fix For: 4.2.0


Create a network with Source NAT but no static NAT, and no firewall rules 
applied.

Observed behavior:
Source NAT is not applied when the first VM is launched (when network is 
implemented)

Expected:
Source NAT enabled at network implement time

Network devices:
Should affect all network devices; verified in 2 separate environments, one 
with Virtual Router only, one MidoNet only

Further information:
This bug seems to be a result of this change:
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=server/src/com/cloud/network/NetworkManagerImpl.java;h=2b53565297dc7bd96c6102cdc1c90cb166e9e704;hp=dac6a3a42e75324a963997e17e076f4020a7103e;hb=fe568fe;hpb=c7f26583a26eb7e4f15feafc292ec9576df61a8d

The above change was made as a fix for CLOUDSTACK-234.

If the user enables Static NAT, Source NAT will be applied as a side effect.







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

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


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

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

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

CLOUDSTACK-4428: kvm.snapshot.enabled flag shouldn't affect detached volumes, 
or volumes attached to the vm in Stopped/Destroyed state
(cherry picked from commit 97cb0093c82b1032ccc4ecad838d4c65c3bf99d2)

Signed-off-by: animesh anim...@apache.org


 kvm.snapshot.enabled flag should be taken to account only when snapshot is 
 being created for Running vm
 -

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


 We used to have a problem for KVM snapshot creation when createSnapshot is 
 called for the volume of the Running vm. As a fix for that, 
 kvm.snapshot.enabled flag was introduced. But when this flag set to fase, it 
 doesn't allow snapshot creation even for detached volumes (the area where the 
 problem didn't even exist).
 Suggested fix: kvm.snapshot.enabled should affect only case when the snapshot 
 is being created for the volume a) that is attached to the vm b) the vm is 
 running/starting/stopping states only

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

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

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


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

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

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

CLOUDSTACK-4428: UI  volume  when hypervisor is KVM and kvm.snapshot.enabled 
configuration is false, still show Take Snapshot option if VM State is Stopped.
(cherry picked from commit 57070b1dc2cc725b5cdab516eee6a935165e1f12)

Signed-off-by: animesh anim...@apache.org


 kvm.snapshot.enabled flag should be taken to account only when snapshot is 
 being created for Running vm
 -

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


 We used to have a problem for KVM snapshot creation when createSnapshot is 
 called for the volume of the Running vm. As a fix for that, 
 kvm.snapshot.enabled flag was introduced. But when this flag set to fase, it 
 doesn't allow snapshot creation even for detached volumes (the area where the 
 problem didn't even exist).
 Suggested fix: kvm.snapshot.enabled should affect only case when the snapshot 
 is being created for the volume a) that is attached to the vm b) the vm is 
 running/starting/stopping states only

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

[jira] [Commented] (CLOUDSTACK-867) Document Scaling up CPU and RAM for running VMs

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


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

ASF subversion and git services commented on CLOUDSTACK-867:


Commit bd5f6e039a85a1a2b0ca709d6157d2e4548a2af1 in branch refs/heads/4.2 from 
[~jessica.tomec...@citrix.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bd5f6e0 ]

CLOUDSTACK-867. DOC. Fix how-to steps for updating an existing VM to have 
dynamic scaling capability.
(cherry picked from commit 2f491963b87d0013f51a5ddfad7ef1b8b4a2110c)

Signed-off-by: animesh anim...@apache.org


 Document Scaling up CPU and RAM for running VMs 
 

 Key: CLOUDSTACK-867
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-867
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Reporter: Radhika Nair
Assignee: Jessica Tomechak
 Fix For: 4.2.0

 Attachments: Dynamically_Scalable.jpg, Global_Settings.jpg, 
 zone_Settings .jpg


 Document Scaling up CPU and RAM for running VMs 

--
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-4429) Generate API Reference doc for next release

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

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

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

Commit 057705e4f220113c81dfec03ca1b0820170ba183 in branch refs/heads/4.2 from
[~jessica.tomec...@citrix.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=057705e ]

CLOUDSTACK-4429. DOC. Fix broken link in header of API Reference TOC page. The
link pointed to the Developer's Guide on the old doc site. Changed to point to
the new doc site. Does not point to a specific doc version, so this text can be
re-used without change for future software releases.
(cherry picked from commit aeb962ad13dba2f67ed582862e47657ef89b28b6)

Signed-off-by: animesh anim...@apache.org

Generate API Reference doc for next release
---

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

Someone needs to take care of running the API Reference doc build,
sanity-checking the result, and posting it on the web. API Reference is
posted at http://cloudstack.apache.org/docs/api/index.html. This is
auto-generated from the code using a procedure documented in the project wiki
at
https://cwiki.apache.org/confluence/display/CLOUDSTACK/How+To+Generate+CloudStack+API+Documentation.

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

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

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


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

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

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

CLOUDSTACK-4442: Include a test for creating networks with sourcenat only

The test attempts to create a network with offering serving only
dhcp,dns and sourcenat. However the source NAT functionality itself
isn't tested as reported in the bug. So the test will pass.

TODO: come up with a way to test source nat without enabling additional
services for pf/staticnat

Signed-off-by: Prasanna Santhanam t...@apache.org
(cherry picked from commit 79df10ee24840dc7fe8fdb4ccbde240658a109fc)


 Source NAT not applied when network starts up
 -

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


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

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

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

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


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

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

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

CLOUDSTACK-4437: Fix iso usage event count to match the number of image stores

Signed-off-by: Prasanna Santhanam t...@apache.org


 Fix iso usage event count to match the number of image stores
 -

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


 Check ISO.CREATE event in events table
   begin captured logging  
 testclient.testcase.TestISOUsage: DEBUG: Deleting ISO with ID: 
 e99eaac5-8ab3-454b-978b-09f0255dc399
 testclient.testcase.TestISOUsage: DEBUG: select project_account_id from 
 projects where uuid = '361e1eba-cdc9-4568-8738-ef209afc66f0';
 testclient.testcase.TestISOUsage: DEBUG: select type from usage_event where 
 account_id = '369';
 testclient.testcase.TestISOUsage: DEBUG: Query result: [(u'ISO.CREATE',), 
 (u'ISO.CREATE',), (u'ISO.DELETE',), (u'ISO.DELETE',)]
 -  end captured logging  -
 Stacktrace
 Traceback (most recent call last):
   File /usr/local/lib/python2.7/unittest/case.py, line 318, in run
 testMethod()
   File /root/cloudstack/test/integration/component/test_project_usage.py, 
 line 977, in test_01_ISO_usage
 Check ISO.CREATE event in events table
   File /usr/local/lib/python2.7/unittest/case.py, line 494, in assertEqual
 assertion_func(first, second, msg=msg)
   File /usr/local/lib/python2.7/unittest/case.py, line 487, in 
 _baseAssertEqual
 raise self.failureException(msg)
 AssertionError: Check ISO.CREATE event in events table
   begin captured logging  
 testclient.testcase.TestISOUsage: DEBUG: Deleting ISO with ID: 
 e99eaac5-8ab3-454b-978b-09f0255dc399
 testclient.testcase.TestISOUsage: DEBUG: select project_account_id from 
 projects where uuid = '361e1eba-cdc9-4568-8738-ef209afc66f0';
 testclient.testcase.TestISOUsage: DEBUG: select type from usage_event where 
 account_id = '369';
 testclient.testcase.TestISOUsage: DEBUG: Query result: [(u'ISO.CREATE',), 
 (u'ISO.CREATE',), (u'ISO.DELETE',), (u'ISO.DELETE',)]
 -  end captured logging  -

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

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

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


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

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

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

CLOUDSTACK-4442: Include a test for creating networks with sourcenat only

The test attempts to create a network with offering serving only
dhcp,dns and sourcenat. However the source NAT functionality itself
isn't tested as reported in the bug. So the test will pass.

TODO: come up with a way to test source nat without enabling additional
services for pf/staticnat

Signed-off-by: Prasanna Santhanam t...@apache.org


 Source NAT not applied when network starts up
 -

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


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

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

[jira] [Updated] (CLOUDSTACK-2425) fix test_network script for the BVT failures

2013-08-22 Thread Prasanna Santhanam (JIRA)


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

Prasanna Santhanam updated CLOUDSTACK-2425:
---

Issue Type: Test  (was: Bug)

 fix test_network script for the BVT failures
 

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


 fix test_network script for the BVT failures

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

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

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


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

ASF subversion and git services commented on CLOUDSTACK-770:


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

CLOUDSTACK-770 ntier review comments


 documentation on nTier Apps 2.0
 ---

 Key: CLOUDSTACK-770
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-770
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Reporter: Radhika Nair
Assignee: Sudha Ponnaganti
 Fix For: 4.2.0

 Attachments: Apache_CloudStack-4.2.0-Admin_Guide-en-US.zip


 doc for nTier Apps 2.0

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

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

Sailaja Mada created CLOUDSTACK-4443:


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


Steps:

With 307,

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

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

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

java.lang.Exception: Unable to find vSwitchepp0
at 
com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:904)
at 
com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:3292)
at 
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2904)
at 
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:514)
at 
com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
2013-08-22 12:22:09,467 DEBUG [agent.manager.DirectAgentAttache] 
(DirectAgent-50:null) Seq 7-1913981379: Response Received:
2013-08-22 12:22:09,470 DEBUG [agent.transport.Request] (DirectAgent-50:null) 
Seq 7-1913981379: Processing:  { Ans: , MgmtId: 187767034175903, via: 7, Ver: 
v1, Flags: 10, 
[{com.cloud.agent.api.StartAnswer:{vm:{id:32,name:i-4-32-VM,bootloader:HVM,type:User,cpus:1,minSpeed:500,maxSpeed:500,minRam:536870912,maxRam:536870912,hostName:newinstance1,arch:x86_64,os:CentOS
 5.3

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


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

Sailaja Mada commented on CLOUDSTACK-4443:
--

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


 [VMWARE]Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after 
 upgrade 
 ---

 Key: CLOUDSTACK-4443
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4443
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Upgrade, VMware
Affects Versions: 4.2.0
Reporter: Sailaja Mada
Priority: Blocker

 Steps:
 With 307,
 1. Configure Adv Zone using Standard vSwitch with VMWARE cluster (Single 
 Physical Network and all the traffics - Mgmt,guest,public) on this default 
 network ( vSwitch0) 
 2. Upgraded from 307 to 4.2 
 3. Tried to depoy new VM on this zone which was created in 307. 
 Observation:
 Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after upgrade 
 2013-08-22 12:22:09,336 DEBUG [vmware.resource.VmwareResource] 
 (DirectAgent-50:10.102.192.20) Prepare volume at new device 
 {capacityInKB:0,key:-2,backing:{diskMode:persistent,fileName:[3adda133ecae3cd894716de45b81a560]
  
 i-4-32-VM/ROOT-32.vmdk,datastore:{value:datastore-11157,type:Datastore}},connectable:{startConnected:true,allowGuestControl:false,connected:true},controllerKey:200,unitNumber:1}
 2013-08-22 12:22:09,337 INFO  [vmware.resource.VmwareResource] 
 (DirectAgent-50:10.102.192.20) Prepare NIC device based on NicTO:

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


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

Sailaja Mada updated CLOUDSTACK-4443:
-

Fix Version/s: 4.2.1

 [VMWARE]Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after 
 upgrade 
 ---

 Key: CLOUDSTACK-4443
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4443
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Upgrade, VMware
Affects Versions: 4.2.1
Reporter: Sailaja Mada
Priority: Blocker
 Fix For: 4.2.1

 Attachments: deployvmlogs.rar


 Steps:
 With 307,
 1. Configure Adv Zone using Standard vSwitch with VMWARE cluster (Single 
 Physical Network and all the traffics - Mgmt,guest,public) on this default 
 network ( vSwitch0) 
 2. Upgraded from 307 to 4.2 
 3. Tried to depoy new VM on this zone which was created in 307. 
 Observation:
 Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after upgrade 
 2013-08-22 12:22:09,336 DEBUG [vmware.resource.VmwareResource] 
 (DirectAgent-50:10.102.192.20) Prepare volume at new device 
 {capacityInKB:0,key:-2,backing:{diskMode:persistent,fileName:[3adda133ecae3cd894716de45b81a560]
  
 i-4-32-VM/ROOT-32.vmdk,datastore:{value:datastore-11157,type:Datastore}},connectable:{startConnected:true,allowGuestControl:false,connected:true},controllerKey:200,unitNumber:1}
 2013-08-22 12:22:09,337 INFO  [vmware.resource.VmwareResource] 
 (DirectAgent-50:10.102.192.20) Prepare NIC device based on NicTO: 
 {deviceId:0,networkRateMbps:200,defaultNic:true,uuid:057f0e6e-7ca5-4715-9551-c827f9f61ea8,ip:10.1.1.74,netmask:255.255.255.0,gateway:10.1.1.1,mac:02:00:28:84:00:04,dns1:10.103.128.15,broadcastType:Vlan,type:Guest,broadcastUri:vlan://782,isolationUri:vlan://782,isSecurityGroupEnabled:false}
 2013-08-22 12:22:09,348 INFO  [vmware.resource.VmwareResource] 
 (DirectAgent-50:10.102.192.20) Prepare network on vmwaresvs P[epp0:untagged] 
 with name prefix: cloud.guest
 2013-08-22 12:22:09,427 ERROR [vmware.mo.HypervisorHostHelper] 
 (DirectAgent-50:10.102.192.20) Unable to find vSwitchepp0
 2013-08-22 12:22:09,444 WARN  [vmware.resource.VmwareResource] 
 (DirectAgent-50:10.102.192.20) StartCommand failed due to Exception: 
 java.lang.Exception
 Message: Unable to find vSwitchepp0
 java.lang.Exception: Unable to find vSwitchepp0
 at 
 com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:904)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:3292)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2904)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:514)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at java.lang.Thread.run(Thread.java:679)
 2013-08-22 12:22:09,467 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-50:null) Seq 7-1913981379: Response Received:
 2013-08-22 12:22:09,470 DEBUG [agent.transport.Request] (DirectAgent-50:null) 
 Seq 7-1913981379: Processing:  { Ans: , MgmtId: 187767034175903, via: 7, Ver: 
 v1, Flags: 10, 
 [{com.cloud.agent.api.StartAnswer:{vm:{id:32,name:i-4-32-VM,bootloader:HVM,type:User,cpus:1,minSpeed:500,maxSpeed:500,minRam:536870912,maxRam:536870912,hostName:newinstance1,arch:x86_64,os:CentOS
  5.3

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


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

Sailaja Mada updated CLOUDSTACK-4443:
-

Affects Version/s: (was: 4.2.0)
   4.2.1

 [VMWARE]Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after 
 upgrade 
 ---

 Key: CLOUDSTACK-4443
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4443
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Upgrade, VMware
Affects Versions: 4.2.1
Reporter: Sailaja Mada
Priority: Blocker
 Attachments: deployvmlogs.rar


 Steps:
 With 307,
 1. Configure Adv Zone using Standard vSwitch with VMWARE cluster (Single 
 Physical Network and all the traffics - Mgmt,guest,public) on this default 
 network ( vSwitch0) 
 2. Upgraded from 307 to 4.2 
 3. Tried to depoy new VM on this zone which was created in 307. 
 Observation:
 Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after upgrade 
 2013-08-22 12:22:09,336 DEBUG [vmware.resource.VmwareResource] 
 (DirectAgent-50:10.102.192.20) Prepare volume at new device 
 {capacityInKB:0,key:-2,backing:{diskMode:persistent,fileName:[3adda133ecae3cd894716de45b81a560]
  
 i-4-32-VM/ROOT-32.vmdk,datastore:{value:datastore-11157,type:Datastore}},connectable:{startConnected:true,allowGuestControl:false,connected:true},controllerKey:200,unitNumber:1}
 2013-08-22 12:22:09,337 INFO  [vmware.resource.VmwareResource] 
 (DirectAgent-50:10.102.192.20) Prepare NIC device based on NicTO: 
 {deviceId:0,networkRateMbps:200,defaultNic:true,uuid:057f0e6e-7ca5-4715-9551-c827f9f61ea8,ip:10.1.1.74,netmask:255.255.255.0,gateway:10.1.1.1,mac:02:00:28:84:00:04,dns1:10.103.128.15,broadcastType:Vlan,type:Guest,broadcastUri:vlan://782,isolationUri:vlan://782,isSecurityGroupEnabled:false}
 2013-08-22 12:22:09,348 INFO  [vmware.resource.VmwareResource] 
 (DirectAgent-50:10.102.192.20) Prepare network on vmwaresvs P[epp0:untagged] 
 with name prefix: cloud.guest
 2013-08-22 12:22:09,427 ERROR [vmware.mo.HypervisorHostHelper] 
 (DirectAgent-50:10.102.192.20) Unable to find vSwitchepp0
 2013-08-22 12:22:09,444 WARN  [vmware.resource.VmwareResource] 
 (DirectAgent-50:10.102.192.20) StartCommand failed due to Exception: 
 java.lang.Exception
 Message: Unable to find vSwitchepp0
 java.lang.Exception: Unable to find vSwitchepp0
 at 
 com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:904)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:3292)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2904)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:514)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at java.lang.Thread.run(Thread.java:679)
 2013-08-22 12:22:09,467 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-50:null) Seq 7-1913981379: Response Received:
 2013-08-22 12:22:09,470 DEBUG [agent.transport.Request] (DirectAgent-50:null) 
 Seq 7-1913981379: Processing:  { Ans: , MgmtId: 187767034175903, via: 7, Ver: 
 v1, Flags: 10, 
 [{com.cloud.agent.api.StartAnswer:{vm:{id:32,name:i-4-32-VM,bootloader:HVM,type:User,cpus:1,minSpeed:500,maxSpeed:500,minRam:536870912,maxRam:536870912,hostName:newinstance1,arch:x86_64,os:CentOS
  5.3

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

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


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

Sailaja Mada updated CLOUDSTACK-4443:
-

Attachment: deployvmlogs.rar

 [VMWARE]Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after 
 upgrade 
 ---

 Key: CLOUDSTACK-4443
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4443
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Upgrade, VMware
Affects Versions: 4.2.1
Reporter: Sailaja Mada
Priority: Blocker
 Fix For: 4.2.1

 Attachments: deployvmlogs.rar


 Steps:
 With 307,
 1. Configure Adv Zone using Standard vSwitch with VMWARE cluster (Single 
 Physical Network and all the traffics - Mgmt,guest,public) on this default 
 network ( vSwitch0) 
 2. Upgraded from 307 to 4.2 
 3. Tried to depoy new VM on this zone which was created in 307. 
 Observation:
 Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after upgrade 
 2013-08-22 12:22:09,336 DEBUG [vmware.resource.VmwareResource] 
 (DirectAgent-50:10.102.192.20) Prepare volume at new device 
 {capacityInKB:0,key:-2,backing:{diskMode:persistent,fileName:[3adda133ecae3cd894716de45b81a560]
  
 i-4-32-VM/ROOT-32.vmdk,datastore:{value:datastore-11157,type:Datastore}},connectable:{startConnected:true,allowGuestControl:false,connected:true},controllerKey:200,unitNumber:1}
 2013-08-22 12:22:09,337 INFO  [vmware.resource.VmwareResource] 
 (DirectAgent-50:10.102.192.20) Prepare NIC device based on NicTO: 
 {deviceId:0,networkRateMbps:200,defaultNic:true,uuid:057f0e6e-7ca5-4715-9551-c827f9f61ea8,ip:10.1.1.74,netmask:255.255.255.0,gateway:10.1.1.1,mac:02:00:28:84:00:04,dns1:10.103.128.15,broadcastType:Vlan,type:Guest,broadcastUri:vlan://782,isolationUri:vlan://782,isSecurityGroupEnabled:false}
 2013-08-22 12:22:09,348 INFO  [vmware.resource.VmwareResource] 
 (DirectAgent-50:10.102.192.20) Prepare network on vmwaresvs P[epp0:untagged] 
 with name prefix: cloud.guest
 2013-08-22 12:22:09,427 ERROR [vmware.mo.HypervisorHostHelper] 
 (DirectAgent-50:10.102.192.20) Unable to find vSwitchepp0
 2013-08-22 12:22:09,444 WARN  [vmware.resource.VmwareResource] 
 (DirectAgent-50:10.102.192.20) StartCommand failed due to Exception: 
 java.lang.Exception
 Message: Unable to find vSwitchepp0
 java.lang.Exception: Unable to find vSwitchepp0
 at 
 com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:904)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:3292)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2904)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:514)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at java.lang.Thread.run(Thread.java:679)
 2013-08-22 12:22:09,467 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-50:null) Seq 7-1913981379: Response Received:
 2013-08-22 12:22:09,470 DEBUG [agent.transport.Request] (DirectAgent-50:null) 
 Seq 7-1913981379: Processing:  { Ans: , MgmtId: 187767034175903, via: 7, Ver: 
 v1, Flags: 10, 
 [{com.cloud.agent.api.StartAnswer:{vm:{id:32,name:i-4-32-VM,bootloader:HVM,type:User,cpus:1,minSpeed:500,maxSpeed:500,minRam:536870912,maxRam:536870912,hostName:newinstance1,arch:x86_64,os:CentOS
  5.3

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


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

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

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

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

Signed-off-by: animesh anim...@apache.org


 [VMware]Registration of template using the downloaded template URL is failing.
 --

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


 Steps:
 1. Create a snapshot of root volume before upgrade.(after upgrade also)
 2. Create template from snapshot.
 3. Extract the template .
 4. Now register the template with the URL popped up in step3
 Observation:
 Registration failed with “ Failed post download script: 
 com.cloud.exception.InternalErrorException: Unable to locate OVF file in 
 template package directory: 
 /mnt/SecStorage/0e8da06e-0788-3efb-86a6-b0705a2205d3/template/tmpl/2/214there 
 is no OVF file”
 But UI shows success. Notifications shows success.
 2013-08-21 20:04:02,399 DEBUG [agent.transport.Request] 
 (AgentManager-Handler-1:null) Seq 3-1960707392: Processing: { Ans: , MgmtId: 
 7067804893289, via: 3, Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.storage.DownloadAnswer:{jobId:5a011db0-5ae2-4aad-a62b-7363e3305ddb,downloadPct:100,errorString:Failed
  post download script: com.cloud.exception.InternalErrorException: Unable to 
 locate OVF file in template package directory: 
 /mnt/SecStorage/0e8da06e-0788-3efb-86a6-b0705a2205d3/template/tmpl/2/214,downloadStatus:DOWNLOAD_ERROR,downloadPath:/mnt/SecStorage/0e8da06e-0788-3efb-86a6-b0705a2205d3/template/tmpl/2/214/dnld6321683521470213167tmp_,installPath:template/tmpl/2/214/ba5a8103-58fe-3196-a3fd-440e1fe4d508.ova,templateSize:0,templatePhySicalSize:0,checkSum:82cea0b543ed2c4d5047b0bb7457c53f,result:true,details:Failed
  post download script: com.cloud.exception.InternalErrorException: Unable to 
 locate OVF file in template package directory: 
 /mnt/SecStorage/0e8da06e-0788-3efb-86a6-b0705a2205d3/template/tmpl/2/214,wait:0}}]
  }
 2013-08-21 20:04:10,896 DEBUG [agent.manager.AgentManagerImpl] 
 (AgentManager-Handler-4:null) SeqA 4-10323: Processing Seq 4-10323: { Cmd , 
 MgmtId: -1, via: 4, Ver: v1, Flags: 11, 
 [{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:2,_loadInfo:{\n
  \connections\: []\n},wait:0}}] }

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

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

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


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

ASF subversion and git services commented on CLOUDSTACK-770:


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

CLOUDSTACK-770 ntier review comments


 documentation on nTier Apps 2.0
 ---

 Key: CLOUDSTACK-770
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-770
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Reporter: Radhika Nair
Assignee: Sudha Ponnaganti
 Fix For: 4.2.0

 Attachments: Apache_CloudStack-4.2.0-Admin_Guide-en-US.zip


 doc for nTier Apps 2.0

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

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

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


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

ASF subversion and git services commented on CLOUDSTACK-770:


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

CLOUDSTACK-770 ntier review comments


 documentation on nTier Apps 2.0
 ---

 Key: CLOUDSTACK-770
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-770
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Reporter: Radhika Nair
Assignee: Sudha Ponnaganti
 Fix For: 4.2.0

 Attachments: Apache_CloudStack-4.2.0-Admin_Guide-en-US.zip


 doc for nTier Apps 2.0

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

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

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


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

ASF subversion and git services commented on CLOUDSTACK-770:


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

CLOUDSTACK-770 ntier review comments


 documentation on nTier Apps 2.0
 ---

 Key: CLOUDSTACK-770
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-770
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Reporter: Radhika Nair
Assignee: Sudha Ponnaganti
 Fix For: 4.2.0

 Attachments: Apache_CloudStack-4.2.0-Admin_Guide-en-US.zip


 doc for nTier Apps 2.0

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

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

Sailaja Mada created CLOUDSTACK-4445:


 Summary: CLONE - [UI]Edit Icon is used for Dedicate host / Add or 
Remove VMWARE Datacenter 
 Key: CLOUDSTACK-4445
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4445
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.2.0
Reporter: Sailaja Mada
Assignee: Brian Federle
 Fix For: 4.2.0


Observation :

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

Expected behavior :

We should have icons to identify these new options separately. 



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

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


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

Sailaja Mada updated CLOUDSTACK-4445:
-

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

  [UI]Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter 
 Chrome Browser
 -

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

 Attachments: addremovedc.png, dedicatecluster1.png, 
 dedicatehost1.png, dedicatePOD1.png, dedicatezone1.png


 Observation :
 Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter .
 Expected behavior :
 We should have icons to identify these new options separately. 

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

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


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

Sailaja Mada updated CLOUDSTACK-4445:
-

Fix Version/s: (was: 4.2.0)
   4.2.1

  [UI]Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter 
 with Chrome Browser
 --

 Key: CLOUDSTACK-4445
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4445
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.2.1
Reporter: Sailaja Mada
Assignee: Brian Federle
 Fix For: 4.2.1

 Attachments: addremovedc.png, dedicatecluster1.png, 
 dedicatehost1.png, dedicatePOD1.png, dedicatezone1.png


 Observation :
 Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter .
 Expected behavior :
 We should have icons to identify these new options separately. 

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

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


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

Sailaja Mada updated CLOUDSTACK-4445:
-

Affects Version/s: (was: 4.2.0)
   4.2.1

  [UI]Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter 
 with Chrome Browser
 --

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

 Attachments: addremovedc.png, dedicatecluster1.png, 
 dedicatehost1.png, dedicatePOD1.png, dedicatezone1.png


 Observation :
 Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter .
 Expected behavior :
 We should have icons to identify these new options separately. 

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

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


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

Sailaja Mada updated CLOUDSTACK-4445:
-

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

  [UI]Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter 
 with Chrome Browser
 --

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

 Attachments: addremovedc.png, dedicatecluster1.png, 
 dedicatehost1.png, dedicatePOD1.png, dedicatezone1.png


 Observation :
 Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter .
 Expected behavior :
 We should have icons to identify these new options separately. 

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

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


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

Sailaja Mada commented on CLOUDSTACK-4445:
--

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

  [UI]Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter 
 with Chrome Browser
 --

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

 Attachments: addremovedc.png, dedicatecluster1.png, 
 dedicatehost1.png, dedicatePOD1.png, dedicatezone1.png


 Observation :
 Edit Icon is used for Dedicate host / Add or Remove VMWARE Datacenter .
 Expected behavior :
 We should have icons to identify these new options separately. 

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

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


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

Sateesh Chodapuneedi reassigned CLOUDSTACK-4443:


Assignee: Sateesh Chodapuneedi

 [VMWARE]Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after 
 upgrade 
 ---

 Key: CLOUDSTACK-4443
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4443
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Upgrade, VMware
Affects Versions: 4.2.1
Reporter: Sailaja Mada
Assignee: Sateesh Chodapuneedi
Priority: Blocker
 Fix For: 4.2.1

 Attachments: deployvmlogs.rar


 Steps:
 With 307,
 1. Configure Adv Zone using Standard vSwitch with VMWARE cluster (Single 
 Physical Network and all the traffics - Mgmt,guest,public) on this default 
 network ( vSwitch0) 
 2. Upgraded from 307 to 4.2 
 3. Tried to depoy new VM on this zone which was created in 307. 
 Observation:
 Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after upgrade 
 2013-08-22 12:22:09,336 DEBUG [vmware.resource.VmwareResource] 
 (DirectAgent-50:10.102.192.20) Prepare volume at new device 
 {capacityInKB:0,key:-2,backing:{diskMode:persistent,fileName:[3adda133ecae3cd894716de45b81a560]
  
 i-4-32-VM/ROOT-32.vmdk,datastore:{value:datastore-11157,type:Datastore}},connectable:{startConnected:true,allowGuestControl:false,connected:true},controllerKey:200,unitNumber:1}
 2013-08-22 12:22:09,337 INFO  [vmware.resource.VmwareResource] 
 (DirectAgent-50:10.102.192.20) Prepare NIC device based on NicTO: 
 {deviceId:0,networkRateMbps:200,defaultNic:true,uuid:057f0e6e-7ca5-4715-9551-c827f9f61ea8,ip:10.1.1.74,netmask:255.255.255.0,gateway:10.1.1.1,mac:02:00:28:84:00:04,dns1:10.103.128.15,broadcastType:Vlan,type:Guest,broadcastUri:vlan://782,isolationUri:vlan://782,isSecurityGroupEnabled:false}
 2013-08-22 12:22:09,348 INFO  [vmware.resource.VmwareResource] 
 (DirectAgent-50:10.102.192.20) Prepare network on vmwaresvs P[epp0:untagged] 
 with name prefix: cloud.guest
 2013-08-22 12:22:09,427 ERROR [vmware.mo.HypervisorHostHelper] 
 (DirectAgent-50:10.102.192.20) Unable to find vSwitchepp0
 2013-08-22 12:22:09,444 WARN  [vmware.resource.VmwareResource] 
 (DirectAgent-50:10.102.192.20) StartCommand failed due to Exception: 
 java.lang.Exception
 Message: Unable to find vSwitchepp0
 java.lang.Exception: Unable to find vSwitchepp0
 at 
 com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:904)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:3292)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2904)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:514)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at java.lang.Thread.run(Thread.java:679)
 2013-08-22 12:22:09,467 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-50:null) Seq 7-1913981379: Response Received:
 2013-08-22 12:22:09,470 DEBUG [agent.transport.Request] (DirectAgent-50:null) 
 Seq 7-1913981379: Processing:  { Ans: , MgmtId: 187767034175903, via: 7, Ver: 
 v1, Flags: 10, 
 [{com.cloud.agent.api.StartAnswer:{vm:{id:32,name:i-4-32-VM,bootloader:HVM,type:User,cpus:1,minSpeed:500,maxSpeed:500,minRam:536870912,maxRam:536870912,hostName:newinstance1,arch:x86_64,os:CentOS
  5.3

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


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

Srikanteswararao Talluri resolved CLOUDSTACK-4437.
--

Resolution: Fixed

 Fix iso usage event count to match the number of image stores
 -

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


 Check ISO.CREATE event in events table
   begin captured logging  
 testclient.testcase.TestISOUsage: DEBUG: Deleting ISO with ID: 
 e99eaac5-8ab3-454b-978b-09f0255dc399
 testclient.testcase.TestISOUsage: DEBUG: select project_account_id from 
 projects where uuid = '361e1eba-cdc9-4568-8738-ef209afc66f0';
 testclient.testcase.TestISOUsage: DEBUG: select type from usage_event where 
 account_id = '369';
 testclient.testcase.TestISOUsage: DEBUG: Query result: [(u'ISO.CREATE',), 
 (u'ISO.CREATE',), (u'ISO.DELETE',), (u'ISO.DELETE',)]
 -  end captured logging  -
 Stacktrace
 Traceback (most recent call last):
   File /usr/local/lib/python2.7/unittest/case.py, line 318, in run
 testMethod()
   File /root/cloudstack/test/integration/component/test_project_usage.py, 
 line 977, in test_01_ISO_usage
 Check ISO.CREATE event in events table
   File /usr/local/lib/python2.7/unittest/case.py, line 494, in assertEqual
 assertion_func(first, second, msg=msg)
   File /usr/local/lib/python2.7/unittest/case.py, line 487, in 
 _baseAssertEqual
 raise self.failureException(msg)
 AssertionError: Check ISO.CREATE event in events table
   begin captured logging  
 testclient.testcase.TestISOUsage: DEBUG: Deleting ISO with ID: 
 e99eaac5-8ab3-454b-978b-09f0255dc399
 testclient.testcase.TestISOUsage: DEBUG: select project_account_id from 
 projects where uuid = '361e1eba-cdc9-4568-8738-ef209afc66f0';
 testclient.testcase.TestISOUsage: DEBUG: select type from usage_event where 
 account_id = '369';
 testclient.testcase.TestISOUsage: DEBUG: Query result: [(u'ISO.CREATE',), 
 (u'ISO.CREATE',), (u'ISO.DELETE',), (u'ISO.DELETE',)]
 -  end captured logging  -

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

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


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

Srikanteswararao Talluri closed CLOUDSTACK-4437.



 Fix iso usage event count to match the number of image stores
 -

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


 Check ISO.CREATE event in events table
   begin captured logging  
 testclient.testcase.TestISOUsage: DEBUG: Deleting ISO with ID: 
 e99eaac5-8ab3-454b-978b-09f0255dc399
 testclient.testcase.TestISOUsage: DEBUG: select project_account_id from 
 projects where uuid = '361e1eba-cdc9-4568-8738-ef209afc66f0';
 testclient.testcase.TestISOUsage: DEBUG: select type from usage_event where 
 account_id = '369';
 testclient.testcase.TestISOUsage: DEBUG: Query result: [(u'ISO.CREATE',), 
 (u'ISO.CREATE',), (u'ISO.DELETE',), (u'ISO.DELETE',)]
 -  end captured logging  -
 Stacktrace
 Traceback (most recent call last):
   File /usr/local/lib/python2.7/unittest/case.py, line 318, in run
 testMethod()
   File /root/cloudstack/test/integration/component/test_project_usage.py, 
 line 977, in test_01_ISO_usage
 Check ISO.CREATE event in events table
   File /usr/local/lib/python2.7/unittest/case.py, line 494, in assertEqual
 assertion_func(first, second, msg=msg)
   File /usr/local/lib/python2.7/unittest/case.py, line 487, in 
 _baseAssertEqual
 raise self.failureException(msg)
 AssertionError: Check ISO.CREATE event in events table
   begin captured logging  
 testclient.testcase.TestISOUsage: DEBUG: Deleting ISO with ID: 
 e99eaac5-8ab3-454b-978b-09f0255dc399
 testclient.testcase.TestISOUsage: DEBUG: select project_account_id from 
 projects where uuid = '361e1eba-cdc9-4568-8738-ef209afc66f0';
 testclient.testcase.TestISOUsage: DEBUG: select type from usage_event where 
 account_id = '369';
 testclient.testcase.TestISOUsage: DEBUG: Query result: [(u'ISO.CREATE',), 
 (u'ISO.CREATE',), (u'ISO.DELETE',), (u'ISO.DELETE',)]
 -  end captured logging  -

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

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

2013-08-22 Thread Prasanna Santhanam (JIRA)


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

Prasanna Santhanam reassigned CLOUDSTACK-2471:
--

Assignee: Prasanna Santhanam

 test_host_high_availability.py refers to non-existent library method 
 wait_for_vm
 

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


 test_host_high_availability.py:
  #verify the VM live migration happened to another running host
 self.debug(Waiting for VM to come up)
 wait_for_vm( --does not exist in common.py
 self.apiclient,
 virtualmachineid=vm_with_ha_disabled.id,
 interval=timeout
 )
 

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

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

2013-08-22 Thread Saksham Srivastava (JIRA)


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

Saksham Srivastava resolved CLOUDSTACK-4257.


Resolution: Fixed

 [Automation] test_storage_motion test cases failed during with unexpected 
 result in listStoragePool API call
 

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


 Test case 
 integration.component.test_storage_motion.TestStorageMotion.test_02_migrate_volume
  failed during   api call liststorage pool with unexpected result
 Error Message
 Check list storage pools response for valid list
 Stacktrace
 Traceback (most recent call last):
   File /usr/local/lib/python2.7/unittest/case.py, line 318, in run
 testMethod()
   File 
 /Repo_30X/ipcl/cloudstack/test/integration/component/test_storage_motion.py,
  line 265, in test_02_migrate_volume
 Check list storage pools response for valid list
   File /usr/local/lib/python2.7/unittest/case.py, line 494, in assertEqual
 assertion_func(first, second, msg=msg)
   File /usr/local/lib/python2.7/unittest/case.py, line 487, in 
 _baseAssertEqual
 raise self.failureException(msg)
 AssertionError: Check list storage pools response for valid list

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

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

2013-08-22 Thread Likitha Shetty (JIRA)

Likitha Shetty created CLOUDSTACK-4446:
--

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


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

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

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

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

2013-08-22 Thread Saksham Srivastava (JIRA)


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

Saksham Srivastava commented on CLOUDSTACK-4021:


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

 [Automation] 
 TestExplicitDedication.test_01_deploy_vm_with_explicit_dedication failed to 
 deploy VM
 --

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


 Test case 
 integration.component.test_explicit_dedication.TestExplicitDedication.test_01_deploy_vm_with_explicit_dedication
  failing automation runs 
 Error Message
 Execute cmd: asyncquery failed, due to: {errorcode : 533, errortext : 
 u'Unable to create a deployment for 
 VM[User|dec11341-27b0-4fc9-86f4-7570037a456c], Please check the affinity 
 groups provided, there may not be sufficient capacity to follow them'}
 Stacktrace
 Traceback (most recent call last):
   File /usr/local/lib/python2.7/unittest/case.py, line 318, in run
 testMethod()
   File 
 /Repo_30X/ipcl/cloudstack/test/integration/component/test_explicit_dedication.py,
  line 204, in test_01_deploy_vm_with_explicit_dedication
 mode=self.services[mode]
   File 
 /usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py, line 
 388, in create
 virtual_machine = apiclient.deployVirtualMachine(cmd, method=method)
   File 
 /usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
  line 614, in deployVirtualMachine
 response = self.connection.marvin_request(command, 
 response_type=response, method=method)
   File 
 /usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line 
 230, in marvin_request
 response = self.poll(asyncJobId, response_type)
   File 
 /usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line 
 91, in poll
 asyncquery, asyncResonse.jobresult)
 cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode : 
 533, errortext : u'Unable to create a deployment for 
 VM[User|dec11341-27b0-4fc9-86f4-7570037a456c], Please check the affinity 
 groups provided, there may not be sufficient capacity to follow them'}
 Looks like test case trying to create VM eventhough there is no host with 
 emplty VM 

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

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

2013-08-22 Thread Murali Reddy (JIRA)


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

Murali Reddy reassigned CLOUDSTACK-4442:


Assignee: Murali Reddy

 Source NAT not applied when network starts up
 -

 Key: CLOUDSTACK-4442
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4442
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Devices
Affects Versions: 4.2.0
Reporter: Dave Cahill
Assignee: Murali Reddy
Priority: Blocker
 Fix For: 4.2.0


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

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

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

2013-08-22 Thread Likitha Shetty (JIRA)


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

Likitha Shetty commented on CLOUDSTACK-4446:


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

 AWSAPI server fails to start because of error in bean creation.
 ---

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


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

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

Srikanteswararao Talluri created CLOUDSTACK-4447:


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


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

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


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





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

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

2013-08-22 Thread Sanjeev N (JIRA)


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

Sanjeev N closed CLOUDSTACK-4400.
-


Verified with latest build. Works fine.

 [object_store_refactor] Three entries for one template in template_store_ref 
 when MS was restarting during template download
 

 Key: CLOUDSTACK-4400
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4400
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Storage Controller, Template
Affects Versions: 4.2.0
 Environment: Latest build from ACS 4.2 branch
Reporter: Sanjeev N
Assignee: Min Chen
Priority: Critical
 Fix For: 4.2.0

 Attachments: cloud.dmp, management-server.rar


 Three entries for one template in template_store_ref when MS was restarting 
 during template download.
 Restarting management server when the template download was in progress, 
 created three entries in template_store_ref table for the same template and 
 in UI tamplate Ready is set to No even though it is downloaded to S3
 Steps to Reproduce:
 
 1.Bring up CS with two or three zones
 2.Register template any one of the zones 
 3.Restart the management server when the template download was in progres
 Result:
 =
 After restart template sync initiated template download via all the SSVMs and 
 created multiple intries in the template_store_ref for the same template. 
 In UI template is not showing as ready even though it is download to S3 via 
 one of the ssvms.
 Observations:
 =
 After management server restart, it found template 208 is not downlaoded
 2013-08-19 08:54:01,695 INFO  [storage.image.TemplateServiceImpl] 
 (AgentConnectTaskPool-3:null) Template Sync did not find 
 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d on image store 3, may request 
 download based on available hypervisor types
 2013-08-19 08:54:01,709 INFO  [storage.image.TemplateServiceImpl] 
 (AgentConnectTaskPool-3:null) Removing leftover template 
 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d entry from template store table
 2013-08-19 08:54:01,722 INFO  [storage.image.TemplateServiceImpl] 
 (AgentConnectTaskPool-6:null) Template Sync did not find 
 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d on image store 3, may request 
 download based on available hypervisor types
 2013-08-19 08:54:01,722 INFO  [storage.image.TemplateServiceImpl] 
 (AgentConnectTaskPool-6:null) Removing leftover template 
 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d entry from template store table
 2013-08-19 08:54:01,735 INFO  [storage.image.TemplateServiceImpl] 
 (AgentConnectTaskPool-4:null) Template Sync did not find 
 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d on image store 3, may request 
 download based on available hypervisor types
 2013-08-19 08:54:01,735 INFO  [storage.image.TemplateServiceImpl] 
 (AgentConnectTaskPool-4:null) Removing leftover template 
 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d entry from template store table
 2013-08-19 08:54:01,747 INFO  [storage.image.TemplateServiceImpl] 
 (AgentConnectTaskPool-6:null) Downloading template 
 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d to image store imagestore
 2013-08-19 08:54:01,751 INFO  [storage.image.TemplateServiceImpl] 
 (AgentConnectTaskPool-4:null) Downloading template 
 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d to image store imagestore
 2013-08-19 08:54:01,753 INFO  [storage.image.TemplateServiceImpl] 
 (AgentConnectTaskPool-3:null) Downloading template 
 208-2-0fe7ea1d-5e21-33cd-b328-e4510821608d to image store imagestore
 2013-08-19 08:54:02,068 DEBUG [storage.image.TemplateDataFactoryImpl] 
 (AgentConnectTaskPool-4:null) template 208 is already in store:3, type:Image
 2013-08-19 08:54:02,080 DEBUG [storage.image.TemplateDataFactoryImpl] 
 (AgentConnectTaskPool-3:null) template 208 is already in store:3, type:Image
 2013-08-19 08:54:02,069 DEBUG [storage.image.TemplateDataFactoryImpl] 
 (AgentConnectTaskPool-6:null) template 208 is already in store:3, type:Image
 2013-08-19 08:54:02,163 DEBUG [storage.image.BaseImageStoreDriverImpl] 
 (AgentConnectTaskPool-6:null) Downloading template to data store 3
 2013-08-19 08:54:02,164 DEBUG [storage.image.BaseImageStoreDriverImpl] 
 (AgentConnectTaskPool-4:null) Downloading template to data store 3
 2013-08-19 08:54:02,219 DEBUG [agent.transport.Request] 
 (AgentConnectTaskPool-3:null) Seq 3-1325465607: Sending  { Cmd , MgmtId: 
 6615759585382, via: 3, Ver: v1, Flags: 100111, 
 [{com.cloud.agent.api.ReadyCommand:{dcId:1,hostId:3,wait:0}}] }
 2013-08-19 08:54:02,233 DEBUG [agent.transport.Request] 
 (AgentManager-Handler-3:null) Seq 3-1325465607:

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

2013-08-22 Thread Likitha Shetty (JIRA)


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

Likitha Shetty updated CLOUDSTACK-4446:
---

Status: Ready To Review  (was: In Progress)

 AWSAPI server fails to start because of error in bean creation.
 ---

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


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

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


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

Srikanteswararao Talluri updated CLOUDSTACK-4447:
-

Assignee: Srikanteswararao Talluri

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

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


 routers tests are failing if there is a shared network exists in the physical 
 network.
 Fix would be to listRouters for that account of type 'Isolated'.
 following two tests are failing because of the above mentioned problem:
 integration.component.test_routers.TestRouterServices.test_01_AdvancedZoneRouterServices
 integration.component.test_routers.TestRouterServices.test_02_NetworkGarbageCollection

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

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


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

Srikanteswararao Talluri updated CLOUDSTACK-4448:
-

Assignee: Srikanteswararao Talluri

 test_03_RouterStartOnVmDeploy is failing due to pre-existing VMs state
 --

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


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

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

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

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

Srikanteswararao Talluri created CLOUDSTACK-4448:


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


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



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

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

2013-08-22 Thread Nitin Mehta (JIRA)


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

Nitin Mehta closed CLOUDSTACK-3039.
---


 Failed to attach volumes for clusters with id  127
 ---

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


 Failed to attach volumes for clusters with id  128 
 The reason is because we use Java == than the equals for comparing Long 
 object. This operation works till 127 because of JVM optimization where it 
 precreates objects from -127 to 128 and passes the same reference instead of 
 creating a new instance every time

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

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

2013-08-22 Thread Nitin Mehta (JIRA)


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

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

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

  was (Author: nitinme):
With the object store code checked in, dont need to check this any more.
  
 Failed to attach volumes for clusters with id  127
 ---

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


 Failed to attach volumes for clusters with id  128 
 The reason is because we use Java == than the equals for comparing Long 
 object. This operation works till 127 because of JVM optimization where it 
 precreates objects from -127 to 128 and passes the same reference instead of 
 creating a new instance every time

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

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

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

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

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

CLOUDSTACK-4185 vmware steps for upgrade paths

[DOC][upgrade][2.2.14 to 4.2][vmware]Need to encrypt the vCenter password
manually and add to the cluster_details table and vmware_data_center table
after upgrade.
---

Key: CLOUDSTACK-4185
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4185
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Doc
Affects Versions: 4.2.0
Reporter: Abhinav Roy
Assignee: Radhika Nair
Fix For: 4.2.0

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

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

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

Sateesh Chodapuneedi commented on CLOUDSTACK-4438:
--

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

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

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

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

Improve documentation for traffic labels configuration KVM, vSphere, and
XenServer
--

Key: CLOUDSTACK-4438
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4438
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Doc
Affects Versions: 4.2.0
Reporter: Kirk Kosinski
Labels: installguide, kvm, networking, vsphere, xenserver

The installation guide currently has a Physical Networking Setup for
XenServer section (see CLOUDSTACK-661). There should be corresponding
sections for KVM and vSphere, and the XenServer section can use some slight
improvements.
For KVM, the traffic labels defined in CloudStack should correspond to the
bridge name on the hypervisor, and for vSphere the traffic labels should
correspond to the vSwitch name.
For vSphere, a VLAN ID can be included for management traffic (see
CLOUDSTACK-3870). There are some references to this currently but no clear
explanation. The syntax is (currently) vSwitch_Name,VLAN_ID, for
example vSwitch0,100 for vSwitch0 and VLAN ID 100. This might change if
CLOUDSTACK-3398 is implemented.
Considering that vSphere supports a VLAN ID for management traffic, in the
XenServer section it would be wise to explicitly state that management server
traffic must not be put on a VLAN. This is explained in the XenServer
documentation but is commonly misunderstood.

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

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

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

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

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

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

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

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

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

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

2013-08-22 Thread Radhika Nair (JIRA)


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

Radhika Nair reassigned CLOUDSTACK-770:
---

Assignee: Radhika Nair  (was: Sudha Ponnaganti)

 documentation on nTier Apps 2.0
 ---

 Key: CLOUDSTACK-770
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-770
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Reporter: Radhika Nair
Assignee: Radhika Nair
 Fix For: 4.2.0

 Attachments: Apache_CloudStack-4.2.0-Admin_Guide-en-US.zip


 doc for nTier Apps 2.0

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

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

2013-08-22 Thread Radhika Nair (JIRA)


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

Radhika Nair resolved CLOUDSTACK-770.
-

Resolution: Fixed

 documentation on nTier Apps 2.0
 ---

 Key: CLOUDSTACK-770
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-770
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Reporter: Radhika Nair
Assignee: Sudha Ponnaganti
 Fix For: 4.2.0

 Attachments: Apache_CloudStack-4.2.0-Admin_Guide-en-US.zip


 doc for nTier Apps 2.0

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

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

Sanjay Tripathi created CLOUDSTACK-4449:
---

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


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



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



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

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

Sanjay Tripathi created CLOUDSTACK-4450:
---

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


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



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



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

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

2013-08-22 Thread Devdeep Singh (JIRA)


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

Devdeep Singh resolved CLOUDSTACK-4449.
---

Resolution: Duplicate

Looks like 2 bugs got created for the same issue.

 Possibility of /tmp/xapilog filling up the Root disk on Xenserver 
 --

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


 CloudStack installs /opt/xensource/sm/hostvmstats.py script into XenServer. 
 And the script keeps outputting the log into /tmp/xapilog. Now the log is 
 being huge size (Almost 120MBytes) since the file has no architecture to 
 delete/compress. 
 The info logged in /opt/xensource/sm/hostvmstats.py is not much useful. There 
 are few cases in the past where CloudPlatform was contributing to Root 
 filesystem being full on xenserver. We need to make sure either we 
 delete/overwrite the file /tmp/xapilog in Xenserver.

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

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


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

Sanjay Tripathi updated CLOUDSTACK-4450:


Status: Ready To Review  (was: In Progress)

 Possibility of /tmp/xapilog filling up the Root disk on Xenserver 
 --

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


 CloudStack installs /opt/xensource/sm/hostvmstats.py script into XenServer. 
 And the script keeps outputting the log into /tmp/xapilog. Now the log is 
 being huge size (Almost 120MBytes) since the file has no architecture to 
 delete/compress. 
 The info logged in /opt/xensource/sm/hostvmstats.py is not much useful. There 
 are few cases in the past where CloudStack was contributing to Root 
 filesystem being full on xenserver. We need to make sure either we 
 delete/overwrite/rotate the file /tmp/xapilog in Xenserver.

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

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


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

Sanjay Tripathi commented on CLOUDSTACK-4450:
-

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

 Possibility of /tmp/xapilog filling up the Root disk on Xenserver 
 --

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


 CloudStack installs /opt/xensource/sm/hostvmstats.py script into XenServer. 
 And the script keeps outputting the log into /tmp/xapilog. Now the log is 
 being huge size (Almost 120MBytes) since the file has no architecture to 
 delete/compress. 
 The info logged in /opt/xensource/sm/hostvmstats.py is not much useful. There 
 are few cases in the past where CloudStack was contributing to Root 
 filesystem being full on xenserver. We need to make sure either we 
 delete/overwrite/rotate the file /tmp/xapilog in Xenserver.

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

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

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

Sanjay Tripathi reassigned CLOUDSTACK-4434:
---

Assignee: Sanjay Tripathi

EN: Ubuntu: Direct input - _ , ? /, keyboard / ,keyboard - keys are
not working well for the US keyboard.
-

Key: CLOUDSTACK-4434
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4434
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: VNC Proxy
Affects Versions: 4.2.0
Environment: Environment
Build#CloudPlatform-4.2-465(CloudPlatform-4.2-465-rhel6.3.tar.gz)
XenServer6.1 for Host Server
CentOS6.3 for NFS, CS-Mgr Servers.
Client Browser: Ubuntu-Firefox23.0, Win7-Firefox23.0, Win7-Chrome, Win7-IE,
Mac-Safari
Reporter: Minying Bao
Assignee: Sanjay Tripathi
Priority: Critical
Fix For: 4.2.0

Attachments: EN_Ubuntu VM_Outputting Endless.jpg

Repro Steps
1. Setup the CloudStack environments with build 4.2#465.
2. Bring ubuntu VM.
3. Access the VM via Console Proxy from the Ubuntu client machine connected
to US Keyboard.
4. Hit all the keys with US keyboard.
Expected Result
All the keys should work fine.
Actual Result
First time, press the - _ , ? /, keyboard / ,keyboard - keys.
It seemed that the output for those keys will keep on outputting endless.
Even if we have stopped pressing the key. (Refer to attached screenshot.)
We could press Enter to stop the endless outputting.
Then, try to press the four keys again, the keys were not working at all.
Client/Browser Info.
Ubuntu-FF23.0 - Fail
Win7-FF22.0 - Fail
Win7-Chrome - Fail
Win7-IE - Fail
Mac-Safari - Fail

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

2013-08-22 Thread sebastien goasguen (JIRA)

sebastien goasguen created CLOUDSTACK-4451:
--

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


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

but it's required:

Try calling it with cloudmonkey without any arguments.

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


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

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

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

Sanjay Tripathi updated CLOUDSTACK-4434:

Fix Version/s: (was: 4.2.0)
4.2.1

EN: Ubuntu: Direct input - _ , ? /, keyboard / ,keyboard - keys are
not working well for the US keyboard.
-

Attachments: EN_Ubuntu VM_Outputting Endless.jpg

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

2013-08-22 Thread Paul Angus (JIRA)


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

Paul Angus commented on CLOUDSTACK-3535:


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

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


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


 No HA actions are performed when a KVM host goes offline
 

 Key: CLOUDSTACK-3535
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3535
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Hypervisor Controller, KVM, Management Server
Affects Versions: 4.1.0, 4.1.1, 4.2.0
 Environment: KVM (CentOS 6.3) with CloudStack 4.1
Reporter: Paul Angus
Assignee: edison su
Priority: Blocker
 Fix For: 4.2.0

 Attachments: extract-management-server.log.2013-08-09, 
 KVM-HA-4.1.1.2013-08-09-v1.patch, management-server.log.Agent


 If a KVM host 'goes down', CloudStack does not perform HA for instances which 
 are marked as HA enabled on that host (including system VMs)
 CloudStack does not show the host as disconnected.

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

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


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

Gaurav Aradhye commented on CLOUDSTACK-4452:


Adding a patch for this in few mins.

 test_snapshots.py - The method used to check whether snapshot exists on 
 secondary storage is wrong
 --

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


 Following test case failing due to this:
 1. test_01_createVM_snapshotTemplate
 2. test_02_snapshot_data_disk
 3. test_04_delete_snapshot
 The method (is_snapshot_on_nfs) used to check whether snapshot exists on 
 secondary storage is wrong. Currently it's trying to match the name of 
 snapshot present on the storage with the UUID of snapshot. There's no 
 relation between the name of snapshot on storage and it's UUID or snapshot 
 ID. Hence it shoould only check if the snapshot is present in the directory 
 -- snapshots/account/volume/directory/ in SSVM

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

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

Gaurav Aradhye created CLOUDSTACK-4452:
--

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


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

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

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

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


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

Gaurav Aradhye updated CLOUDSTACK-4452:
---

Comment: was deleted

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

 test_snapshots.py - The method used to check whether snapshot exists on 
 secondary storage is wrong
 --

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


 Following test case failing due to this:
 1. test_01_createVM_snapshotTemplate
 2. test_02_snapshot_data_disk
 3. test_04_delete_snapshot
 The method (is_snapshot_on_nfs) used to check whether snapshot exists on 
 secondary storage is wrong. Currently it's trying to match the name of 
 snapshot present on the storage with the UUID of snapshot. There's no 
 relation between the name of snapshot on storage and it's UUID or snapshot 
 ID. Hence it shoould only check if the snapshot is present in the directory 
 -- snapshots/account/volume/directory/ in SSVM

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

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


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

Gaurav Aradhye commented on CLOUDSTACK-4452:


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

 test_snapshots.py - The method used to check whether snapshot exists on 
 secondary storage is wrong
 --

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


 Following test case failing due to this:
 1. test_01_createVM_snapshotTemplate
 2. test_02_snapshot_data_disk
 3. test_04_delete_snapshot
 The method (is_snapshot_on_nfs) used to check whether snapshot exists on 
 secondary storage is wrong. Currently it's trying to match the name of 
 snapshot present on the storage with the UUID of snapshot. There's no 
 relation between the name of snapshot on storage and it's UUID or snapshot 
 ID. Hence it shoould only check if the snapshot is present in the directory 
 -- snapshots/account/volume/directory/ in SSVM

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

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


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

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

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

  was (Author: gauravaradhye):
Added patch
//reviews.apache.org/r/13736/
  
 test_snapshots.py - The method used to check whether snapshot exists on 
 secondary storage is wrong
 --

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


 Following test case failing due to this:
 1. test_01_createVM_snapshotTemplate
 2. test_02_snapshot_data_disk
 3. test_04_delete_snapshot
 The method (is_snapshot_on_nfs) used to check whether snapshot exists on 
 secondary storage is wrong. Currently it's trying to match the name of 
 snapshot present on the storage with the UUID of snapshot. There's no 
 relation between the name of snapshot on storage and it's UUID or snapshot 
 ID. Hence it shoould only check if the snapshot is present in the directory 
 -- snapshots/account/volume/directory/ in SSVM

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

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

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


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

Gaurav Aradhye resolved CLOUDSTACK-4452.


Resolution: Fixed

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

 test_snapshots.py - The method used to check whether snapshot exists on 
 secondary storage is wrong
 --

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


 Following test case failing due to this:
 1. test_01_createVM_snapshotTemplate
 2. test_02_snapshot_data_disk
 3. test_04_delete_snapshot
 The method (is_snapshot_on_nfs) used to check whether snapshot exists on 
 secondary storage is wrong. Currently it's trying to match the name of 
 snapshot present on the storage with the UUID of snapshot. There's no 
 relation between the name of snapshot on storage and it's UUID or snapshot 
 ID. Hence it shoould only check if the snapshot is present in the directory 
 -- snapshots/account/volume/directory/ in SSVM

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

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

2013-08-22 Thread Kishan Kavala (JIRA)


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

Kishan Kavala reopened CLOUDSTACK-4115:
---


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

 [upgrade][2.2.14 to 4.2]After upgrade the ESX 4.1 host ends up in 
 disconnected state with EncryptionOperationNotPossibleException
 -

 Key: CLOUDSTACK-4115
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4115
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Upgrade, VMware
Affects Versions: 4.2.0
 Environment: upgrade from 2.2.14 to 4.2 on CentOS 5.6 management srver
 ESX 4.1 host
Reporter: Abhinav Roy
Assignee: Kishan Kavala
Priority: Blocker
 Fix For: 4.2.0

 Attachments: CS-4115.zip, DB_DUMP_Cloud_after_upgrade.dmp, 
 DB_DUMP_Cloud_before_upgrade.dmp, management-server-after_upgrade.log, 
 management-server-before_upgrade.log


 Steps :
 
 1. Deploy a CS advanced zone setup with CS 2.2.14
 2. Do some configurations.
 3. upgrade to 4.2, then run cloudstack-setup-encryption and start management 
 server
 Expected behaviour:
 ===
 The upgrade should go through and the host should stay connected 
 Observed behaviour :
 ===
 The host ends up in disconnected state after upgrade .
 2013-08-06 21:37:01,972 DEBUG [agent.manager.ClusteredAgentManagerImpl] 
 (ClusteredAgentManager Timer:null) Loading directly connected host 
 1(10.102.192.17)
 2013-08-06 21:37:02,060 DEBUG [utils.crypt.DBEncryptionUtil] 
 (ClusteredAgentManager Timer:null) Error while decrypting: freebsd*123
 2013-08-06 21:37:02,061 DEBUG [cloud.host.Status] (ClusteredAgentManager 
 Timer:null) Transition:[Resource state = Enabled, Agent event = 
 AgentDisconnected, Host id = 1, name = 10.102.192.17]
 2013-08-06 21:37:02,071 DEBUG [cloud.host.Status] (ClusteredAgentManager 
 Timer:null) Agent status update: [id = 1; name = 10.102.192.17; old status = 
 Disconnected; event = AgentDisconnected; new status = Disconnected; old 
 update count = 4; new update count = 5]
 2013-08-06 21:37:02,071 WARN  [agent.manager.ClusteredAgentManagerImpl] 
 (ClusteredAgentManager Timer:null)  can not load directly connected host 
 1(10.102.192.17) due to
 org.jasypt.exceptions.EncryptionOperationNotPossibleException
 at 
 org.jasypt.encryption.pbe.StandardPBEByteEncryptor.decrypt(StandardPBEByteEncryptor.java:918)
 at 
 org.jasypt.encryption.pbe.StandardPBEStringEncryptor.decrypt(StandardPBEStringEncryptor.java:725)
 at 
 com.cloud.utils.crypt.DBEncryptionUtil.decrypt(DBEncryptionUtil.java:65)
 at 
 com.cloud.dc.ClusterDetailsDaoImpl.findDetails(ClusterDetailsDaoImpl.java:81)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 com.cloud.hypervisor.vmware.VmwareServerDiscoverer.buildConfigParams(VmwareServerDiscoverer.java:730)
 at 
 com.cloud.hypervisor.vmware.VmwareServerDiscoverer.reloadResource(VmwareServerDiscoverer.java:760)
 at 
 com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:743)
 at 
 com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:209)
 at 
 com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:175)
 at 
 com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:93)
 at 
 com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.run(ClusteredAgentManagerImpl.java:225)
 at java.util.TimerThread.mainLoop(Timer.java:534)
 at java.util.TimerThread.run(Timer.java:484)

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

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


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

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

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

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


 [upgrade][2.2.14 to 4.2]After upgrade the ESX 4.1 host ends up in 
 disconnected state with EncryptionOperationNotPossibleException
 -

 Key: CLOUDSTACK-4115
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4115
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Upgrade, VMware
Affects Versions: 4.2.0
 Environment: upgrade from 2.2.14 to 4.2 on CentOS 5.6 management srver
 ESX 4.1 host
Reporter: Abhinav Roy
Assignee: Kishan Kavala
Priority: Blocker
 Fix For: 4.2.0

 Attachments: CS-4115.zip, DB_DUMP_Cloud_after_upgrade.dmp, 
 DB_DUMP_Cloud_before_upgrade.dmp, management-server-after_upgrade.log, 
 management-server-before_upgrade.log


 Steps :
 
 1. Deploy a CS advanced zone setup with CS 2.2.14
 2. Do some configurations.
 3. upgrade to 4.2, then run cloudstack-setup-encryption and start management 
 server
 Expected behaviour:
 ===
 The upgrade should go through and the host should stay connected 
 Observed behaviour :
 ===
 The host ends up in disconnected state after upgrade .
 2013-08-06 21:37:01,972 DEBUG [agent.manager.ClusteredAgentManagerImpl] 
 (ClusteredAgentManager Timer:null) Loading directly connected host 
 1(10.102.192.17)
 2013-08-06 21:37:02,060 DEBUG [utils.crypt.DBEncryptionUtil] 
 (ClusteredAgentManager Timer:null) Error while decrypting: freebsd*123
 2013-08-06 21:37:02,061 DEBUG [cloud.host.Status] (ClusteredAgentManager 
 Timer:null) Transition:[Resource state = Enabled, Agent event = 
 AgentDisconnected, Host id = 1, name = 10.102.192.17]
 2013-08-06 21:37:02,071 DEBUG [cloud.host.Status] (ClusteredAgentManager 
 Timer:null) Agent status update: [id = 1; name = 10.102.192.17; old status = 
 Disconnected; event = AgentDisconnected; new status = Disconnected; old 
 update count = 4; new update count = 5]
 2013-08-06 21:37:02,071 WARN  [agent.manager.ClusteredAgentManagerImpl] 
 (ClusteredAgentManager Timer:null)  can not load directly connected host 
 1(10.102.192.17) due to
 org.jasypt.exceptions.EncryptionOperationNotPossibleException
 at 
 org.jasypt.encryption.pbe.StandardPBEByteEncryptor.decrypt(StandardPBEByteEncryptor.java:918)
 at 
 org.jasypt.encryption.pbe.StandardPBEStringEncryptor.decrypt(StandardPBEStringEncryptor.java:725)
 at 
 com.cloud.utils.crypt.DBEncryptionUtil.decrypt(DBEncryptionUtil.java:65)
 at 
 com.cloud.dc.ClusterDetailsDaoImpl.findDetails(ClusterDetailsDaoImpl.java:81)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 com.cloud.hypervisor.vmware.VmwareServerDiscoverer.buildConfigParams(VmwareServerDiscoverer.java:730)
 at 
 com.cloud.hypervisor.vmware.VmwareServerDiscoverer.reloadResource(VmwareServerDiscoverer.java:760)
 at 
 com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:743)
 at 
 com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:209)
 at 
 com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:175)
 at 
 com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:93)
 at 
 com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.run(ClusteredAgentManagerImpl.java:225)
 at java.util.TimerThread.mainLoop(Timer.java:534)
 at java.util.TimerThread.run(Timer.java:484)

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

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

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


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

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

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

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


 [upgrade][2.2.14 to 4.2]After upgrade the ESX 4.1 host ends up in 
 disconnected state with EncryptionOperationNotPossibleException
 -

 Key: CLOUDSTACK-4115
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4115
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Upgrade, VMware
Affects Versions: 4.2.0
 Environment: upgrade from 2.2.14 to 4.2 on CentOS 5.6 management srver
 ESX 4.1 host
Reporter: Abhinav Roy
Assignee: Kishan Kavala
Priority: Blocker
 Fix For: 4.2.0

 Attachments: CS-4115.zip, DB_DUMP_Cloud_after_upgrade.dmp, 
 DB_DUMP_Cloud_before_upgrade.dmp, management-server-after_upgrade.log, 
 management-server-before_upgrade.log


 Steps :
 
 1. Deploy a CS advanced zone setup with CS 2.2.14
 2. Do some configurations.
 3. upgrade to 4.2, then run cloudstack-setup-encryption and start management 
 server
 Expected behaviour:
 ===
 The upgrade should go through and the host should stay connected 
 Observed behaviour :
 ===
 The host ends up in disconnected state after upgrade .
 2013-08-06 21:37:01,972 DEBUG [agent.manager.ClusteredAgentManagerImpl] 
 (ClusteredAgentManager Timer:null) Loading directly connected host 
 1(10.102.192.17)
 2013-08-06 21:37:02,060 DEBUG [utils.crypt.DBEncryptionUtil] 
 (ClusteredAgentManager Timer:null) Error while decrypting: freebsd*123
 2013-08-06 21:37:02,061 DEBUG [cloud.host.Status] (ClusteredAgentManager 
 Timer:null) Transition:[Resource state = Enabled, Agent event = 
 AgentDisconnected, Host id = 1, name = 10.102.192.17]
 2013-08-06 21:37:02,071 DEBUG [cloud.host.Status] (ClusteredAgentManager 
 Timer:null) Agent status update: [id = 1; name = 10.102.192.17; old status = 
 Disconnected; event = AgentDisconnected; new status = Disconnected; old 
 update count = 4; new update count = 5]
 2013-08-06 21:37:02,071 WARN  [agent.manager.ClusteredAgentManagerImpl] 
 (ClusteredAgentManager Timer:null)  can not load directly connected host 
 1(10.102.192.17) due to
 org.jasypt.exceptions.EncryptionOperationNotPossibleException
 at 
 org.jasypt.encryption.pbe.StandardPBEByteEncryptor.decrypt(StandardPBEByteEncryptor.java:918)
 at 
 org.jasypt.encryption.pbe.StandardPBEStringEncryptor.decrypt(StandardPBEStringEncryptor.java:725)
 at 
 com.cloud.utils.crypt.DBEncryptionUtil.decrypt(DBEncryptionUtil.java:65)
 at 
 com.cloud.dc.ClusterDetailsDaoImpl.findDetails(ClusterDetailsDaoImpl.java:81)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 com.cloud.hypervisor.vmware.VmwareServerDiscoverer.buildConfigParams(VmwareServerDiscoverer.java:730)
 at 
 com.cloud.hypervisor.vmware.VmwareServerDiscoverer.reloadResource(VmwareServerDiscoverer.java:760)
 at 
 com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:743)
 at 
 com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:209)
 at 
 com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:175)
 at 
 com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:93)
 at 
 com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.run(ClusteredAgentManagerImpl.java:225)
 at java.util.TimerThread.mainLoop(Timer.java:534)
 at java.util.TimerThread.run(Timer.java:484)

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

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

2013-08-22 Thread Prasanna Santhanam (JIRA)

Prasanna Santhanam created CLOUDSTACK-4453:
--

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


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

result = get_process_status(
host.ipaddress,

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

In this case :

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

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

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



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

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

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


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

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

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

CLOUDSTACK-4453: fetch host credentials from marvin config

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

Signed-off-by: Prasanna Santhanam t...@apache.org
(cherry picked from commit 4b546ce85d40098ade69c575316e76e25a422a12)


 Routers test use VM credentials as host credentials
 ---

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

 In test_routers.py (in smoke and component) we do the following,
 result = get_process_status(
 host.ipaddress,
 
 self.services['virtual_machine'][publicport],
 self.vm_1.username,
 self.vm_1.password,
 router.linklocalip,
 service dnsmasq status
 )
 In this case :
 host.ipaddress is the IP address of the XenServer host.
 self.services['virtual_machine'][publicport] is 22 (SSH port)
 self.vm_1.username / password are the username and password of the VM 
 instance created for this test.
 The call that fails in get_process_status is this:
 ssh = remoteSSHClient(hostip, port, username, password)
 In this case it seems the test is trying to create a SSH connection to the
 XS host using the username / password of the VM instance (which will fail
 because the XS host has a different password)

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

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

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


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

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

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

CLOUDSTACK-4453: fetch host credentials from marvin config

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

Signed-off-by: Prasanna Santhanam t...@apache.org


 Routers test use VM credentials as host credentials
 ---

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

 In test_routers.py (in smoke and component) we do the following,
 result = get_process_status(
 host.ipaddress,
 
 self.services['virtual_machine'][publicport],
 self.vm_1.username,
 self.vm_1.password,
 router.linklocalip,
 service dnsmasq status
 )
 In this case :
 host.ipaddress is the IP address of the XenServer host.
 self.services['virtual_machine'][publicport] is 22 (SSH port)
 self.vm_1.username / password are the username and password of the VM 
 instance created for this test.
 The call that fails in get_process_status is this:
 ssh = remoteSSHClient(hostip, port, username, password)
 In this case it seems the test is trying to create a SSH connection to the
 XS host using the username / password of the VM instance (which will fail
 because the XS host has a different password)

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

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

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


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

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

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

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

fixing the buid break introduced with prev commit for this bug


 Source NAT not applied when network starts up
 -

 Key: CLOUDSTACK-4442
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4442
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Devices
Affects Versions: 4.2.0
Reporter: Dave Cahill
Assignee: Murali Reddy
Priority: Blocker
 Fix For: 4.2.0


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

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

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

2013-08-22 Thread Sheng Yang (JIRA)


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

Sheng Yang reassigned CLOUDSTACK-3424:
--

Assignee: Sheng Yang

 IPV6 - When a Vm is expunged and a new Vm is deployed with the same name , 
 /etc/dhchosts.txt has 2 entries with the same name.
 --

 Key: CLOUDSTACK-3424
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3424
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.0
 Environment: Build from master-6-17-stable
Reporter: Sangeetha Hariharan
Assignee: Sheng Yang
Priority: Critical
 Fix For: 4.2.0

 Attachments: management-server.log


 IPV6 - When a Vm is expunged and a new Vm is deployed with the same name , 
 /etc/dhchosts.txt has 2 entries with the same name
 Steps to reproduce the problem:
 Create a ipv6 network.
 Deploy a Vm with name - test456.
 Destroy this VM. Wait for it to be expunged.
 Deploy another Vm with same name - test456.
 We see that there are 2 entries in the router with the same name test456 
 resolving to 2 different ipv6 addresses.
 root@r-17-VM:~# cat /etc/dhcphosts.txt
 id:00:03:00:01:06:4e:de:00:00:2f,[fc00:3:1370::744f],test123,infinite
 id:00:03:00:01:06:75:46:00:00:31,[fc00:3:1370::34ed],test456,infinite
 id:00:03:00:01:06:e4:ae:00:00:32,[fc00:3:1370::ae4b],testyoyo,infinite
 id:00:03:00:01:06:96:aa:00:00:33,[fc00:3:1370::34ed],testyoyo1,infinite
 id:00:03:00:01:06:cb:88:00:00:34,[fc00:3:1370::6eb2],test456,infinite
 root@r-17-VM:~#
 Attaching management server logs:
 Have 2 entries for the same name is a problem.
 Is it also a problem to have the same ipv6 address associated with 2 
 different vms with different Vm names ( 1 expunged and 1 active , in my case 
 test456 which is expunged and testyoyo1 which is active) ?

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

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

2013-08-22 Thread Ram Ganesh (JIRA)


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

Ram Ganesh commented on CLOUDSTACK-4115:


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

 [upgrade][2.2.14 to 4.2]After upgrade the ESX 4.1 host ends up in 
 disconnected state with EncryptionOperationNotPossibleException
 -

 Key: CLOUDSTACK-4115
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4115
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Upgrade, VMware
Affects Versions: 4.2.0
 Environment: upgrade from 2.2.14 to 4.2 on CentOS 5.6 management srver
 ESX 4.1 host
Reporter: Abhinav Roy
Assignee: Kishan Kavala
Priority: Blocker
 Fix For: 4.2.0

 Attachments: CS-4115.zip, DB_DUMP_Cloud_after_upgrade.dmp, 
 DB_DUMP_Cloud_before_upgrade.dmp, management-server-after_upgrade.log, 
 management-server-before_upgrade.log


 Steps :
 
 1. Deploy a CS advanced zone setup with CS 2.2.14
 2. Do some configurations.
 3. upgrade to 4.2, then run cloudstack-setup-encryption and start management 
 server
 Expected behaviour:
 ===
 The upgrade should go through and the host should stay connected 
 Observed behaviour :
 ===
 The host ends up in disconnected state after upgrade .
 2013-08-06 21:37:01,972 DEBUG [agent.manager.ClusteredAgentManagerImpl] 
 (ClusteredAgentManager Timer:null) Loading directly connected host 
 1(10.102.192.17)
 2013-08-06 21:37:02,060 DEBUG [utils.crypt.DBEncryptionUtil] 
 (ClusteredAgentManager Timer:null) Error while decrypting: freebsd*123
 2013-08-06 21:37:02,061 DEBUG [cloud.host.Status] (ClusteredAgentManager 
 Timer:null) Transition:[Resource state = Enabled, Agent event = 
 AgentDisconnected, Host id = 1, name = 10.102.192.17]
 2013-08-06 21:37:02,071 DEBUG [cloud.host.Status] (ClusteredAgentManager 
 Timer:null) Agent status update: [id = 1; name = 10.102.192.17; old status = 
 Disconnected; event = AgentDisconnected; new status = Disconnected; old 
 update count = 4; new update count = 5]
 2013-08-06 21:37:02,071 WARN  [agent.manager.ClusteredAgentManagerImpl] 
 (ClusteredAgentManager Timer:null)  can not load directly connected host 
 1(10.102.192.17) due to
 org.jasypt.exceptions.EncryptionOperationNotPossibleException
 at 
 org.jasypt.encryption.pbe.StandardPBEByteEncryptor.decrypt(StandardPBEByteEncryptor.java:918)
 at 
 org.jasypt.encryption.pbe.StandardPBEStringEncryptor.decrypt(StandardPBEStringEncryptor.java:725)
 at 
 com.cloud.utils.crypt.DBEncryptionUtil.decrypt(DBEncryptionUtil.java:65)
 at 
 com.cloud.dc.ClusterDetailsDaoImpl.findDetails(ClusterDetailsDaoImpl.java:81)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 com.cloud.hypervisor.vmware.VmwareServerDiscoverer.buildConfigParams(VmwareServerDiscoverer.java:730)
 at 
 com.cloud.hypervisor.vmware.VmwareServerDiscoverer.reloadResource(VmwareServerDiscoverer.java:760)
 at 
 com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:743)
 at 
 com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:209)
 at 
 com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:175)
 at 
 com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:93)
 at 
 com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.run(ClusteredAgentManagerImpl.java:225)
 at java.util.TimerThread.mainLoop(Timer.java:534)
 at java.util.TimerThread.run(Timer.java:484)

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

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

2013-08-22 Thread Sudha Ponnaganti (JIRA)


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

Sudha Ponnaganti updated CLOUDSTACK-4430:
-

Assignee: Kelven Yang

 [Automation][vmware] Failed to deploy vm, if one host is down in a cluster
 --

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

 Attachments: management-server.log.2013-08-20.gz, 
 management-server.rar


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

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

2013-08-22 Thread Sudha Ponnaganti (JIRA)


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

Sudha Ponnaganti commented on CLOUDSTACK-4428:
--

Testing will be done on 4.2.1

 kvm.snapshot.enabled flag should be taken to account only when snapshot is 
 being created for Running vm
 -

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


 We used to have a problem for KVM snapshot creation when createSnapshot is 
 called for the volume of the Running vm. As a fix for that, 
 kvm.snapshot.enabled flag was introduced. But when this flag set to fase, it 
 doesn't allow snapshot creation even for detached volumes (the area where the 
 problem didn't even exist).
 Suggested fix: kvm.snapshot.enabled should affect only case when the snapshot 
 is being created for the volume a) that is attached to the vm b) the vm is 
 running/starting/stopping states only

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

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

2013-08-22 Thread Sudha Ponnaganti (JIRA)


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

Sudha Ponnaganti updated CLOUDSTACK-4428:
-

Assignee: angeline shen  (was: Alena Prokharchyk)

 kvm.snapshot.enabled flag should be taken to account only when snapshot is 
 being created for Running vm
 -

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


 We used to have a problem for KVM snapshot creation when createSnapshot is 
 called for the volume of the Running vm. As a fix for that, 
 kvm.snapshot.enabled flag was introduced. But when this flag set to fase, it 
 doesn't allow snapshot creation even for detached volumes (the area where the 
 problem didn't even exist).
 Suggested fix: kvm.snapshot.enabled should affect only case when the snapshot 
 is being created for the volume a) that is attached to the vm b) the vm is 
 running/starting/stopping states only

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

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


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

Animesh Chaturvedi updated CLOUDSTACK-4239:
---

Fix Version/s: (was: 4.2.0)
   4.2.1

Tagging for 4.2.1

 [vmware]Snapshot creation on ESX 4.1 host fails with BackupSnapshotCommand 
 exception: javax.xml.ws.soap.SOAPFaultException
 

 Key: CLOUDSTACK-4239
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4239
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Snapshot, VMware
Affects Versions: 4.2.0
 Environment: Host : Esx 4.1
 MS : Rhel 6.3
 Fresh install 4.2
Reporter: Abhinav Roy
Assignee: Kelven Yang
Priority: Critical
 Fix For: 4.2.1

 Attachments: CS-4239.zip, ssvm-logs.zip


 Steps :
 =
 1. Deploy CS 4.2 advanced zone setup with ESX 4.1 host.
 2. Deploy VMs and try to create snapshots.
 Expected behaviour :
 =
 The snapshot creation should be successful
 Observed behaviour :
 =
 Snapshot creation fails with 
 2013-08-12 00:09:19,309 DEBUG [storage.snapshot.SnapshotManagerImpl] 
 (Job-Executor-9:job-26 = [ 253f12b5-6217-4928-9f14-3c4a8007f5f9 ]) Failed to 
 create snapshot
 com.cloud.utils.exception.CloudRuntimeException: BackupSnapshotCommand 
 exception: javax.xml.ws.soap.SOAPFaultException
 at 
 org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:286)
 at 
 org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:137)
 at 
 org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:256)
 at 
 com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:1004)
 at 
 org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1256)
 at 
 com.cloud.storage.VolumeManagerImpl.takeSnapshot(VolumeManagerImpl.java:2674)
 at 
 org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd.execute(CreateSnapshotCmd.java:170)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
 at 
 com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:679)
 2013-08-12 00:09:19,318 DEBUG [storage.volume.VolumeServiceImpl] 
 (Job-Executor-9:job-26 = [ 253f12b5-6217-4928-9f14-3c4a8007f5f9 ]) Take 
 snapshot: 20 failed: com.cloud.utils.exception.CloudRuntimeException: Failed 
 to create snapshot
 2013-08-12 00:09:19,324 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-9:job-26 = [ 253f12b5-6217-4928-9f14-3c4a8007f5f9 ]) Complete 
 async job-26 = [ 253f12b5-6217-4928-9f14-3c4a8007f5f9 ], jobStatus: 2, 
 resultCode: 530, result: Error Code: 530 Error text: Failed to create 
 snapshot due to an internal error creating snapshot for volume 20

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

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


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

Animesh Chaturvedi updated CLOUDSTACK-4358:
---

Fix Version/s: (was: 4.2.0)
   4.2.1

Tagging for 4.2.1

 [Automation] [vmware] Few VM deployment failed with IndexOutOfBoundsException 
 at VolumeManagerImpl.java:2534
 --

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

 Attachments: CLOUDSTACK-4358_Log2.rar, CLOUDSTACK-4358.rar, 
 management-server.log.2013-08-19.gz


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

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


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

Animesh Chaturvedi updated CLOUDSTACK-4443:
---


Tagging for 4.2.1

 [VMWARE]Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after 
 upgrade 
 ---

 Key: CLOUDSTACK-4443
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4443
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Upgrade, VMware
Affects Versions: 4.2.1
Reporter: Sailaja Mada
Assignee: Sateesh Chodapuneedi
Priority: Blocker
 Fix For: 4.2.1

 Attachments: deployvmlogs.rar


 Steps:
 With 307,
 1. Configure Adv Zone using Standard vSwitch with VMWARE cluster (Single 
 Physical Network and all the traffics - Mgmt,guest,public) on this default 
 network ( vSwitch0) 
 2. Upgraded from 307 to 4.2 
 3. Tried to depoy new VM on this zone which was created in 307. 
 Observation:
 Failed to deploy VM's on VMWARE Standard vSwitch Legacy Zone after upgrade 
 2013-08-22 12:22:09,336 DEBUG [vmware.resource.VmwareResource] 
 (DirectAgent-50:10.102.192.20) Prepare volume at new device 
 {capacityInKB:0,key:-2,backing:{diskMode:persistent,fileName:[3adda133ecae3cd894716de45b81a560]
  
 i-4-32-VM/ROOT-32.vmdk,datastore:{value:datastore-11157,type:Datastore}},connectable:{startConnected:true,allowGuestControl:false,connected:true},controllerKey:200,unitNumber:1}
 2013-08-22 12:22:09,337 INFO  [vmware.resource.VmwareResource] 
 (DirectAgent-50:10.102.192.20) Prepare NIC device based on NicTO: 
 {deviceId:0,networkRateMbps:200,defaultNic:true,uuid:057f0e6e-7ca5-4715-9551-c827f9f61ea8,ip:10.1.1.74,netmask:255.255.255.0,gateway:10.1.1.1,mac:02:00:28:84:00:04,dns1:10.103.128.15,broadcastType:Vlan,type:Guest,broadcastUri:vlan://782,isolationUri:vlan://782,isSecurityGroupEnabled:false}
 2013-08-22 12:22:09,348 INFO  [vmware.resource.VmwareResource] 
 (DirectAgent-50:10.102.192.20) Prepare network on vmwaresvs P[epp0:untagged] 
 with name prefix: cloud.guest
 2013-08-22 12:22:09,427 ERROR [vmware.mo.HypervisorHostHelper] 
 (DirectAgent-50:10.102.192.20) Unable to find vSwitchepp0
 2013-08-22 12:22:09,444 WARN  [vmware.resource.VmwareResource] 
 (DirectAgent-50:10.102.192.20) StartCommand failed due to Exception: 
 java.lang.Exception
 Message: Unable to find vSwitchepp0
 java.lang.Exception: Unable to find vSwitchepp0
 at 
 com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:904)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:3292)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2904)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:514)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at java.lang.Thread.run(Thread.java:679)
 2013-08-22 12:22:09,467 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-50:null) Seq 7-1913981379: Response Received:
 2013-08-22 12:22:09,470 DEBUG [agent.transport.Request] (DirectAgent-50:null) 
 Seq 7-1913981379: Processing:  { Ans: , MgmtId: 187767034175903, via: 7, Ver: 
 v1, Flags: 10, 
 [{com.cloud.agent.api.StartAnswer:{vm:{id:32,name:i-4-32-VM,bootloader:HVM,type:User,cpus:1,minSpeed:500,maxSpeed:500,minRam:536870912,maxRam:536870912,hostName:newinstance1,arch:x86_64,os:CentOS
  5.3

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


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

Animesh Chaturvedi updated CLOUDSTACK-3237:
---

Fix Version/s: (was: 4.2.0)
   4.2.1

Tagging for 4.2.1

 [vmware][SM] Migrate volume is failing when there are snapshots for that 
 volume
 ---

 Key: CLOUDSTACK-3237
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3237
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Volumes
Affects Versions: 4.2.0
 Environment: vmware, 
Reporter: Srikanteswararao Talluri
Assignee: Kelven Yang
Priority: Blocker
 Fix For: 4.2.1

 Attachments: mgmt_27.log.zip


 Steps to reproduce:
 1. create a VM 
 2. take snapshot of root volume of VM
 3. migrate root volume to a suitable storage pool
 ===START===  10.101.255.87 -- GET  
 command=findStoragePoolsForMigrationid=f7c12988-61a8-49dc-a5d3-cd8653744a8eresponse=jsonsessionkey=dfd5NAw2qEmBOi3931kcin3eZtQ%3D_=1372333879848
 2013-06-27 22:46:36,408 DEBUG [storage.allocator.LocalStoragePoolAllocator] 
 (catalina-exec-14:null) LocalStoragePoolAllocator trying to find storage pool 
 to fit the vm
 2013-06-27 22:46:36,410 DEBUG 
 [storage.allocator.ClusterScopeStoragePoolAllocator] (catalina-exec-14:null) 
 ClusterScopeStoragePoolAllocator looking for storage pool
 2013-06-27 22:46:36,410 DEBUG 
 [storage.allocator.ClusterScopeStoragePoolAllocator] (catalina-exec-14:null) 
 Looking for pools in dc: 1  pod:1  cluster:1
 2013-06-27 22:46:36,419 DEBUG 
 [storage.allocator.AbstractStoragePoolAllocator] (catalina-exec-14:null) 
 Checking if storage pool is suitable, name: null ,poolId: 1
 2013-06-27 22:46:36,419 DEBUG 
 [storage.allocator.AbstractStoragePoolAllocator] (catalina-exec-14:null) 
 StoragePool is in avoid set, skipping this pool
 2013-06-27 22:46:36,421 DEBUG 
 [storage.allocator.AbstractStoragePoolAllocator] (catalina-exec-14:null) 
 Checking if storage pool is suitable, name: null ,poolId: 3
 2013-06-27 22:46:36,429 DEBUG [cloud.storage.StorageManagerImpl] 
 (catalina-exec-14:null) Checking pool 3 for storage, totalSize: 
 590228480, usedBytes: 3490243883008, usedPct: 0.5913377617779474, disable 
 threshold: 0.85
 2013-06-27 22:46:36,461 DEBUG [cloud.storage.StorageManagerImpl] 
 (catalina-exec-14:null) Checking pool: 3 for volume allocation 
 [Vol[4|vm=4|ROOT]], maxSize : 1180456960, totalAllocatedSize : 
 23622320128, askingSize : 0, allocated disable threshold: 0.85
 2013-06-27 22:46:36,464 DEBUG 
 [storage.allocator.AbstractStoragePoolAllocator] (catalina-exec-14:null) 
 Checking if storage pool is suitable, name: null ,poolId: 5
 2013-06-27 22:46:36,471 DEBUG [cloud.storage.StorageManagerImpl] 
 (catalina-exec-14:null) Checking pool 5 for storage, totalSize: 
 590228480, usedBytes: 3490243883008, usedPct: 0.5913377617779474, disable 
 threshold: 0.85
 2013-06-27 22:46:36,492 DEBUG [cloud.storage.StorageManagerImpl] 
 (catalina-exec-14:null) Checking pool: 5 for volume allocation 
 [Vol[4|vm=4|ROOT]], maxSize : 1180456960, totalAllocatedSize : 
 35433480192, askingSize : 0, allocated disable threshold: 0.85
 2013-06-27 22:46:36,492 DEBUG 
 [storage.allocator.ClusterScopeStoragePoolAllocator] (catalina-exec-14:null) 
 FirstFitStoragePoolAllocator returning 2 suitable storage pools
 2013-06-27 22:46:36,506 DEBUG [cloud.api.ApiServlet] (catalina-exec-14:null) 
 ===END===  10.101.255.87 -- GET  
 command=findStoragePoolsForMigrationid=f7c12988-61a8-49dc-a5d3-cd8653744a8eresponse=jsonsessionkey=dfd5NAw2qEmBOi3931kcin3eZtQ%3D_=1372333879848
 2013-06-27 22:46:39,967 DEBUG [agent.manager.AgentManagerImpl] 
 (AgentManager-Handler-9:null) Ping from 4
 2013-06-27 22:46:40,804 DEBUG [agent.manager.AgentManagerImpl] 
 (AgentManager-Handler-11:null) SeqA 3-10940: Processing Seq 3-10940:  { Cmd , 
 MgmtId: -1, via: 3, Ver: v1, Flags: 11, 
 [{ConsoleProxyLoadReportCommand:{_proxyVmId:2,_loadInfo:{\n  
 \connections\: []\n},wait:0}}] }
 2013-06-27 22:46:40,813 DEBUG [agent.manager.AgentManagerImpl] 
 (AgentManager-Handler-11:null) SeqA 3-10940: Sending Seq 3-10940:  { Ans: , 
 MgmtId: 7566222426160, via: 3, Ver: v1, Flags: 100010, 
 [{AgentControlAnswer:{result:true,wait:0}}] }
 2013-06-27 22:46:41,091 DEBUG [cloud.api.ApiServlet] (catalina-exec-18:null) 
 ===START===  10.101.255.87 -- GET  
 command=migrateVolumelivemigrate=truestorageid=e690ef30-851c-33b0-a1b3-38fd7fa4c40cvolumeid=f7c12988-61a8-49dc-a5d3-cd8653744a8eresponse=jsonsessionkey=dfd5NAw2qEmBOi3931kcin3eZtQ%3D_=1372333884566
 2013-06-27 22:46:41,135 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (catalina-exec-18:null) submit async job-42, details: AsyncJobVO

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


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

Animesh Chaturvedi updated CLOUDSTACK-4435:
---


Tagging for 4.2.1

 [VMWARE]System VM's are failed to start with Nexus enabled Zone 
 

 Key: CLOUDSTACK-4435
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4435
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Devices, VMware
Affects Versions: 4.2.1
Reporter: Sailaja Mada
Assignee: Sateesh Chodapuneedi
Priority: Blocker
 Fix For: 4.2.1

 Attachments: issuenexus.rar


 Steps:
 1. Upgraded from 3.0.7 to 4.2 ( VMWARE Zone with Standard vSwitch)
 2. Enable Nexus global config variable
 3. Tried to add new Zone with VMWARE Nexus enabled
 4. Added two physical networks ( 1 - Mgmt - vSwitch0,,vmwaresvs 2- Public  
 guest - sailajanewpp,,nexusdvs)
 5. Provided VSM details while adding cluster
 Observation:
 System VM's are failed to start with Nexus enabled Zone saying Nexus details 
 can not be retrieved from DB. 
 2013-08-22 00:37:01,732 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null) 
 ===START===  10.101.255.30 -- GET  
 command=queryAsyncJobResultjobId=921f4c19-a655-4234-82c4-66efcbe73933response=jsonsessionkey=CNY1grUrySJwTE%2BpFM3btn1i4Xs%3D_=1377112271133
 2013-08-22 00:37:01,782 DEBUG [cloud.api.ApiServlet] (catalina-exec-2:null) 
 ===END===  10.101.255.30 -- GET  
 command=queryAsyncJobResultjobId=921f4c19-a655-4234-82c4-66efcbe73933response=jsonsessionkey=CNY1grUrySJwTE%2BpFM3btn1i4Xs%3D_=1377112271133
 2013-08-22 00:37:02,170 WARN  [vmware.resource.VmwareResource] 
 (DirectAgent-128:10.102.192.18) StartCommand failed due to Exception: 
 java.lang.Exception
 Message: Failed to retrieve required credentials of Nexus VSM from database.
 java.lang.Exception: Failed to retrieve required credentials of Nexus VSM 
 from database.
 at 
 com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.getValidatedVsmCredentials(HypervisorHostHelper.java:183)
 at 
 com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.createPortProfile(HypervisorHostHelper.java:201)
 at 
 com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:584)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:3308)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2904)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:514)
 at 
 com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at java.lang.Thread.run(Thread.java:679)
 2013-08-22 00:37:02,196 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-128:null) Seq 14-773455885: Cancelling because one of the 
 answers is false and it is stop on error.
 2013-08-22 00:37:02,196 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-128:null) Seq 14-773455885: Response Received:
 2013-08-22 00:37:02,199 DEBUG [agent.transport.Request] 
 (DirectAgent-128:null) Seq 14-773455885: Processing:  { Ans: , MgmtId: 
 187767034175903, via: 14, Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.StartAnswer:{vm:{id:30,name:s-30-VM,bootloader:HVM,type:SecondaryStorageVm,cpus:1,minSpeed:500,maxSpeed:500,minRam:268435456,maxRam:268435456,hostName:s-30-VM,arch:x86_64,os:Debian
  GNU/Linux 5.0 (32-bit),bootArgs: template=domP type=secstorage 
 host=10.102.192.207 port=8250 name=s-30-VM zone=3 pod=3 guid=s-30-VM 
 resource=com.cloud.storage.resource.PremiumSecondaryStorageResource 
 instance=SecStorage sslcopy=true role=templateProcessor mtu=1500 
 eth2ip=10.102.196.220 eth2mask=255.255.255.0 gateway=10.102.196.1 
 public.network.device=eth2 eth0mask=0.0.0.0 eth0ip=0.0.0.0 
 eth1ip=10.102.195.150 eth1mask=255.255.252.0 mgmtcidr=10.102.192.0/22 
 localgw=10.102.192.1 private.network.device=eth1 eth3ip=10.102.195.152 
 eth3mask=255.255.252.0 storageip=10.102.195.152

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


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

Animesh Chaturvedi updated CLOUDSTACK-4432:
---


Tagging for 4.2.1

 [VMWare] NPE thrown during VM Deployment
 

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

 Attachments: management-server.zip


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

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


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

Animesh Chaturvedi updated CLOUDSTACK-3010:
---

Fix Version/s: (was: 4.2.0)
   4.2.1

Tagging for 4.2.1

 [VMWare] [SharedNetworkWithServices] router VM deployment fails with error 
 Message: Invalid configuration for device '2'.
 ---

 Key: CLOUDSTACK-3010
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3010
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: VMware
Affects Versions: 4.2.0
 Environment: commit # 971c40d98e07ab6cddb8e6db5095c1acea935815
Reporter: venkata swamybabu budumuru
Assignee: Venkata Siva Vijayendra Bhamidipati
Priority: Critical
 Fix For: 4.2.1

 Attachments: logs.setup1.tgz, logs.setup2.tgz, logs.tgz


 Steps to reproduce :
 1. Have latest CloudStack setup with advanced zone using VMware cluster (1 
 host added to the cluster)
 2. create a shared network with all services enabled
 mysql select * from network_offerings where id=14\G
 *** 1. row ***
id: 14
  name: CustomSharedOffering
  uuid: dbee9234-e443-4f00-827e-e9258bb0c209
   unique_name: CustomSharedOffering
  display_text: CustomSharedOffering
   nw_rate: NULL
   mc_rate: 10
  traffic_type: Guest
  tags: NULL
   system_only: 0
  specify_vlan: 1
   service_offering_id: NULL
 conserve_mode: 0
   created: 2013-06-14 14:34:10
   removed: NULL
   default: 0
  availability: Optional
  dedicated_lb_service: 1
 shared_source_nat_service: 0
  sort_key: 0
  redundant_router_service: 0
 state: Enabled
guest_type: Shared
elastic_ip_service: 0
   eip_associate_public_ip: 0
elastic_lb_service: 0
 specify_ip_ranges: 1
inline: 0
 is_persistent: 0
   internal_lb: 0
 public_lb: 1
 mysql select * from ntwk_offering_service_map where network_offering_id=14;
 ++-++---+-+
 | id | network_offering_id | service| provider  | created 
 |
 ++-++---+-+
 | 48 |  14 | Dhcp   | VirtualRouter | 2013-06-14 
 14:34:10 |
 | 52 |  14 | Dns| VirtualRouter | 2013-06-14 
 14:34:10 |
 | 51 |  14 | Firewall   | VirtualRouter | 2013-06-14 
 14:34:10 |
 | 49 |  14 | Lb | VirtualRouter | 2013-06-14 
 14:34:10 |
 | 53 |  14 | PortForwarding | VirtualRouter | 2013-06-14 
 14:34:10 |
 | 46 |  14 | SourceNat  | VirtualRouter | 2013-06-14 
 14:34:10 |
 | 50 |  14 | StaticNat  | VirtualRouter | 2013-06-14 
 14:34:10 |
 | 47 |  14 | UserData   | VirtualRouter | 2013-06-14 
 14:34:10 |
 ++-++---+-+
 3. create a Network using the above offering
 4. Login as non-ROOT domain user and try to deploy VM using the above network.
 Observations:
 (i) deployment failed with the following error. 
 2013-06-14 11:49:53,743 DEBUG [vmware.mo.HostMO] 
 (DirectAgent-29:10.147.40.12) find VM r-27-VM on host
 2013-06-14 11:49:53,743 DEBUG [vmware.mo.HostMO] 
 (DirectAgent-29:10.147.40.12) VM r-27-VM found in host cache
 2013-06-14 11:49:53,764 INFO  [vmware.resource.VmwareResource] 
 (DirectAgent-29:10.147.40.12) Configure VNC port for VM r-27-VM, port: 5914, 
 host: 10.147.40.12
 2013-06-14 11:49:53,889 WARN  [vmware.resource.VmwareResource] 
 (DirectAgent-29:10.147.40.12) StartCommand failed due to Exception: 
 java.lang.RuntimeException
 Message: Invalid configuration for device '2'.
 java.lang.RuntimeException: Invalid configuration for device '2'.
 at 
 com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:291)
 at 
 com.cloud.hypervisor.vmware.mo.VirtualMachineMO.configureVm(VirtualMachineMO.java:832)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2674)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:474)
 at

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


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

Animesh Chaturvedi updated CLOUDSTACK-4430:
---


Tagging for 4.2.1

 [Automation][vmware] Failed to deploy vm, if one host is down in a cluster
 --

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

 Attachments: management-server.log.2013-08-20.gz, 
 management-server.rar


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

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


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

Animesh Chaturvedi updated CLOUDSTACK-4413:
---

Fix Version/s: (was: 4.2.0)
   4.2.1

Tagging for 4.2.1

 [UI]IPV6 - Not able to extend Ipv6 range for an existing ipv6 network.
 --

 Key: CLOUDSTACK-4413
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4413
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.0
 Environment: Build form 4.2
Reporter: Sangeetha Hariharan
Priority: Critical
 Fix For: 4.2.1


 Steps to reproduce the problem:
 Create a ipv6 network by providing only ipv6 parameters.
 Now Try to extend the IPV6 range for this network by providing IPV6 Start 
 IP and IPV6 End IP.
 Following error message is presented to the user
 Gateway, netmask and zoneId have to be passed in for virtual and direct 
 untagged networks
 2013-08-20 16:12:04,370 INFO  [cloud.api.ApiServer] (catalina-exec-6:null) 
 (userId=2 accountId=2 sessionId=5D69ED7832AC98EC474EEB4026D0C139) 
 10.217.252.50 -- GET 
 command=createVlanIpRangeforVirtualNetwork=falsenetworkid=e77c9b30-e577-45d3-9110-e35d2d5d660cstartipv6=fc00:3:1363::11endipv6=fc00:3:1363::20response=jsonsessionkey=gx5ogg5IT%2FtLKkL8O8ygTWaHIPk%3D_=1377040741242
  431 Gateway, netmask and zoneId have to be passed in for virtual and direct 
 untagged networks
 Expected Result:
 We should be able to  extend the IPV6 range for an existing network by 
 providing only IPV6 Start IP and IPV6 End IP.

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

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

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


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

venkata swamybabu budumuru commented on CLOUDSTACK-3010:


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


 [VMWare] [SharedNetworkWithServices] router VM deployment fails with error 
 Message: Invalid configuration for device '2'.
 ---

 Key: CLOUDSTACK-3010
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3010
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: VMware
Affects Versions: 4.2.0
 Environment: commit # 971c40d98e07ab6cddb8e6db5095c1acea935815
Reporter: venkata swamybabu budumuru
Assignee: Venkata Siva Vijayendra Bhamidipati
Priority: Critical
 Fix For: 4.2.1

 Attachments: logs.setup1.tgz, logs.setup2.tgz, logs.tgz


 Steps to reproduce :
 1. Have latest CloudStack setup with advanced zone using VMware cluster (1 
 host added to the cluster)
 2. create a shared network with all services enabled
 mysql select * from network_offerings where id=14\G
 *** 1. row ***
id: 14
  name: CustomSharedOffering
  uuid: dbee9234-e443-4f00-827e-e9258bb0c209
   unique_name: CustomSharedOffering
  display_text: CustomSharedOffering
   nw_rate: NULL
   mc_rate: 10
  traffic_type: Guest
  tags: NULL
   system_only: 0
  specify_vlan: 1
   service_offering_id: NULL
 conserve_mode: 0
   created: 2013-06-14 14:34:10
   removed: NULL
   default: 0
  availability: Optional
  dedicated_lb_service: 1
 shared_source_nat_service: 0
  sort_key: 0
  redundant_router_service: 0
 state: Enabled
guest_type: Shared
elastic_ip_service: 0
   eip_associate_public_ip: 0
elastic_lb_service: 0
 specify_ip_ranges: 1
inline: 0
 is_persistent: 0
   internal_lb: 0
 public_lb: 1
 mysql select * from ntwk_offering_service_map where network_offering_id=14;
 ++-++---+-+
 | id | network_offering_id | service| provider  | created 
 |
 ++-++---+-+
 | 48 |  14 | Dhcp   | VirtualRouter | 2013-06-14 
 14:34:10 |
 | 52 |  14 | Dns| VirtualRouter | 2013-06-14 
 14:34:10 |
 | 51 |  14 | Firewall   | VirtualRouter | 2013-06-14 
 14:34:10 |
 | 49 |  14 | Lb | VirtualRouter | 2013-06-14 
 14:34:10 |
 | 53 |  14 | PortForwarding | VirtualRouter | 2013-06-14 
 14:34:10 |
 | 46 |  14 | SourceNat  | VirtualRouter | 2013-06-14 
 14:34:10 |
 | 50 |  14 | StaticNat  | VirtualRouter | 2013-06-14 
 14:34:10 |
 | 47 |  14 | UserData   | VirtualRouter | 2013-06-14 
 14:34:10 |
 ++-++---+-+
 3. create a Network using the above offering
 4. Login as non-ROOT domain user and try to deploy VM using the above network.
 Observations:
 (i) deployment failed with the following error. 
 2013-06-14 11:49:53,743 DEBUG [vmware.mo.HostMO] 
 (DirectAgent-29:10.147.40.12) find VM r-27-VM on host
 2013-06-14 11:49:53,743 DEBUG [vmware.mo.HostMO] 
 (DirectAgent-29:10.147.40.12) VM r-27-VM found in host cache
 2013-06-14 11:49:53,764 INFO  [vmware.resource.VmwareResource] 
 (DirectAgent-29:10.147.40.12) Configure VNC port for VM r-27-VM, port: 5914, 
 host: 10.147.40.12
 2013-06-14 11:49:53,889 WARN  [vmware.resource.VmwareResource] 
 (DirectAgent-29:10.147.40.12) StartCommand failed due to Exception: 
 java.lang.RuntimeException
 Message: Invalid configuration for device '2'.
 java.lang.RuntimeException: Invalid configuration for device '2'.
 at 
 com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:291)
 at 
 com.cloud.hypervisor.vmware.mo.VirtualMachineMO.configureVm(VirtualMachineMO.java:832)
 at 
 com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2674)
 at

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


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

Animesh Chaturvedi updated CLOUDSTACK-3424:
---

Fix Version/s: (was: 4.2.0)
   4.2.1

Tagging for 4.2.1

 IPV6 - When a Vm is expunged and a new Vm is deployed with the same name , 
 /etc/dhchosts.txt has 2 entries with the same name.
 --

 Key: CLOUDSTACK-3424
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3424
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.0
 Environment: Build from master-6-17-stable
Reporter: Sangeetha Hariharan
Assignee: Sheng Yang
Priority: Critical
 Fix For: 4.2.1

 Attachments: management-server.log


 IPV6 - When a Vm is expunged and a new Vm is deployed with the same name , 
 /etc/dhchosts.txt has 2 entries with the same name
 Steps to reproduce the problem:
 Create a ipv6 network.
 Deploy a Vm with name - test456.
 Destroy this VM. Wait for it to be expunged.
 Deploy another Vm with same name - test456.
 We see that there are 2 entries in the router with the same name test456 
 resolving to 2 different ipv6 addresses.
 root@r-17-VM:~# cat /etc/dhcphosts.txt
 id:00:03:00:01:06:4e:de:00:00:2f,[fc00:3:1370::744f],test123,infinite
 id:00:03:00:01:06:75:46:00:00:31,[fc00:3:1370::34ed],test456,infinite
 id:00:03:00:01:06:e4:ae:00:00:32,[fc00:3:1370::ae4b],testyoyo,infinite
 id:00:03:00:01:06:96:aa:00:00:33,[fc00:3:1370::34ed],testyoyo1,infinite
 id:00:03:00:01:06:cb:88:00:00:34,[fc00:3:1370::6eb2],test456,infinite
 root@r-17-VM:~#
 Attaching management server logs:
 Have 2 entries for the same name is a problem.
 Is it also a problem to have the same ipv6 address associated with 2 
 different vms with different Vm names ( 1 expunged and 1 active , in my case 
 test456 which is expunged and testyoyo1 which is active) ?

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

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


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

Animesh Chaturvedi updated CLOUDSTACK-1365:
---

Fix Version/s: (was: 4.2.0)
   4.2.1

Tagging for 4.2.1

 UI support for baremetal PXE server
 ---

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

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


 Baremetal PXE needs a page to add device
 the API is AddBaremetalKickStartPxeCmd
 please contact frank for details

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

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


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

Animesh Chaturvedi updated CLOUDSTACK-1364:
---

Fix Version/s: (was: 4.2.0)
   4.2.1

Tagging for 4.2.1

 UI support for baremetal DHCP server
 

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

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


 Baremetal DHCP needs a page to add device
 the API is AddBaremetalDhcpCmd
 please contact frank for details

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

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