date:20130606


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

Wei Zhou commented on CLOUDSTACK-2823:
--

Testing result for new systemvm-kvm:
(1) systemvm can not get message from /dev/vport0p1 on its first run.
(2) systemvm can get messages from /dev/vport0p1 on later run.

I am not sure whether it is a CentOS 6.4 issue, as the kernel version of CentOS 
is 2.6.32 and some articles on Internet mentioned that virtio serial was 
supported from 2.6.34.

Workaround is sending the message some times, like this:


diff --git 
a/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
 
b/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
index bab53bc..62bb5eb 100755
--- 
a/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
+++ 
b/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
@@ -3374,7 +3374,14 @@ ServerResource {

 // pass cmdline info to system vms
 if (vmSpec.getType() != VirtualMachine.Type.User) {
-passCmdLine(vmName, vmSpec.getBootArgs() );
+for (int count = 0; count  10; count ++) {
+try {
+Thread.sleep(5000);
+} catch (InterruptedException e) {
+s_logger.trace(Ignoring InterruptedException., e);
+}
+passCmdLine(vmName, vmSpec.getBootArgs());
+}
 }

 state = State.Running;


 SystemVMs start fail and have no HA
 ---

 Key: CLOUDSTACK-2823
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2823
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.0
 Environment: CentOS 6.4, KVM
 CloudStack master
Reporter: Wei Zhou
Assignee: Marcus Sorensen

 Host:
 [root@cs-kvm015 ~]# virsh version
 Compiled against library: libvirt 0.10.2
 Using library: libvirt 0.10.2
 Using API: QEMU 0.10.2
 Running hypervisor: QEMU 0.12.1
 Network:
 em0 - cloudbr0 (Guest, Public), Guest: 172.16.61.0/24, Public: 10.11.11.0/24 
 (Can not connect outside)
 em1.103 - cloudbr1 (Management, Storage) , IP: 192.168.103.*
 Issue descripion
 (1) SystemVMs (SSVM, CPVM) start fails , and have no IP (Public, guest, 
 management)
 (2) After I destroyed SystemVM, no new SystemVM will be created automatically.
 This issue only exists on master branch
 Deploy 4.1 successfully, and SystemVms work well. 

--
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-2288) NPE while creating volume from snapshot when the primary storage is in maintenance state

2013-06-06 Thread Sanjay Tripathi (JIRA)


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

Sanjay Tripathi reassigned CLOUDSTACK-2288:
---

Assignee: Sanjay Tripathi

 NPE while creating volume from snapshot when the primary storage is in 
 maintenance state
 

 Key: CLOUDSTACK-2288
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2288
 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: Sailaja Mada
Assignee: Sanjay Tripathi
 Fix For: 4.2.0


 Setup: Advanced Networking Zone, Xen 6.1 , MS - RHEL 6.3 
 Steps:
 1. Deploy instance as ROOT admin
 2. Create the snapshot for the ROOT volume of this instance 
 3. Put the only available primary storage to maintenance
 4. Try to create the volume from this snapshot. 
 Observation:
 NPE while creating volume from snapshot when the primary storage is in 
 maintenance state
 2013-04-30 12:05:56,653 DEBUG [cloud.api.ApiServlet] (catalina-exec-16:null) 
 ===END===  10.144.6.19 -- GET  
 command=createVolumeresponse=jsonsessionkey=mTrNgYbkndiHLZNAV%2BoAAzDOQFw%3Dsnapshotid=79b17cda-71f7-4be9-9e7c-bedcb73a7106name=newsnapvol1_=1367303886423
 2013-04-30 12:05:56,658 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-1:job-73) Executing 
 org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd for job-73
 2013-04-30 12:05:56,755 DEBUG [cloud.storage.StorageManagerImpl] 
 (Job-Executor-1:job-73) Storage pool garbage collector found 0 templates to 
 clean up in storage pool: PS1
 2013-04-30 12:05:56,767 DEBUG [cloud.storage.StorageManagerImpl] 
 (Job-Executor-1:job-73) Secondary storage garbage collector found 0 templates 
 to cleanup on secondary storage host: 
 nfs://10.102.192.100/cpg_vol/sailaja/masterxenss
 2013-04-30 12:05:56,819 WARN  [cloud.storage.StorageManagerImpl] 
 (Job-Executor-1:job-73) Failed to cleanup snapshots for volume 15 due to can 
 not find secondary storage VM agent for data center 1
 2013-04-30 12:05:56,840 WARN  [cloud.storage.StorageManagerImpl] 
 (Job-Executor-1:job-73) Failed to cleanup snapshots for volume 18 due to can 
 not find secondary storage VM agent for data center 1
 2013-04-30 12:05:56,874 DEBUG [cloud.storage.StorageManagerImpl] 
 (Job-Executor-1:job-73) Secondary storage garbage collector found 0 templates 
 to cleanup on secondary storage host: 
 nfs://10.102.192.100/cpg_vol/sailaja/masterxenss
 2013-04-30 12:05:56,890 DEBUG [allocator.impl.UserConcentratedAllocator] 
 (Job-Executor-1:job-73) There are no pods with enough memory/CPU capacity in 
 zone Advzone1
 2013-04-30 12:05:56,946 DEBUG [cloud.storage.VolumeManagerImpl] 
 (Job-Executor-1:job-73) Failed to create volume: 28
 java.lang.NullPointerException
 at 
 com.cloud.storage.VolumeManagerImpl.createVolumeFromSnapshot(VolumeManagerImpl.java:537)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 com.cloud.storage.VolumeManagerImpl.createVolumeFromSnapshot(VolumeManagerImpl.java:597)
 at 
 com.cloud.storage.VolumeManagerImpl.createVolume(VolumeManagerImpl.java:1014)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 com.cloud.storage.VolumeManagerImpl.createVolume(VolumeManagerImpl.java:180)
 at 
 org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd.execute(CreateVolumeCmd.java:168)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
 at 
 com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at java.lang.Thread.run(Thread.java:679)
 2013-04-30 12:05:57,019 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-1:job-73) Complete async job-73, jobStatus: 2, resultCode: 530, 
 result: Error Code: 530 Error text: Failed to create a volume
 2013-04-30 12:05:59,699 DEBUG [cloud.api.ApiServlet] (catalina-exec-12:null) 
 ===START===  10.144.6.19 -- GET  
 command=queryAsyncJobResultjobId=bdd08ea3-cf7f-4369-9778-c32e6267ffe1response=jsonsessionkey=mTrNgYbkndiHLZNAV%2BoAAzDOQFw%3D_=1367303889729
 2013-04-30 12:05:59,729 DEBUG

[jira] [Commented] (CLOUDSTACK-2823) SystemVMs start fail and have no HA

2013-06-06 Thread ASF subversion and git services (JIRA)


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

Wei Zhou commented on CLOUDSTACK-2823:
--

As the kernel versions of CentOS 
(http://en.wikipedia.org/wiki/CentOS#Versioning) are before 2.6.34, maybe we 
need to add a patch for it.

-Wei

 SystemVMs start fail and have no HA
 ---

 Key: CLOUDSTACK-2823
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2823
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.0
 Environment: CentOS 6.4, KVM
 CloudStack master
Reporter: Wei Zhou
Assignee: Marcus Sorensen

 Host:
 [root@cs-kvm015 ~]# virsh version
 Compiled against library: libvirt 0.10.2
 Using library: libvirt 0.10.2
 Using API: QEMU 0.10.2
 Running hypervisor: QEMU 0.12.1
 Network:
 em0 - cloudbr0 (Guest, Public), Guest: 172.16.61.0/24, Public: 10.11.11.0/24 
 (Can not connect outside)
 em1.103 - cloudbr1 (Management, Storage) , IP: 192.168.103.*
 Issue descripion
 (1) SystemVMs (SSVM, CPVM) start fails , and have no IP (Public, guest, 
 management)
 (2) After I destroyed SystemVM, no new SystemVM will be created automatically.
 This issue only exists on master branch
 Deploy 4.1 successfully, and SystemVms work well. 

--
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-2867) Cannot add multiple vmware zones in vCenter


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

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

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

CLOUDSTACK-2867 Cannot add multiple vmware zones in vCenter

Checking guid in database, if association of DC to zone exists already.


 Cannot add multiple vmware zones in vCenter
 ---

 Key: CLOUDSTACK-2867
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2867
 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: VMWare cloudstack deployment.
Reporter: Venkata Siva Vijayendra Bhamidipati
Assignee: Sateesh Chodapuneedi

 Create a datacenter in vmware, say dc1, add a cluster to it, say cluster1, 
 add one or more hosts to cluster1. Add a zone in cloudstack, and provide 
 dc1/cluster1 info for it. It'll go through fine. Next, create dc2, cluster2 
 in vCenter with new host(s). Attempt to add a new zone in cloudstack 
 providing dc2/cluster2 info. It will fail with the following exception:
 INFO  [cloud.configuration.ConfigurationManagerImpl] 
 (94321089@qtp-1454176402-24:) adding a new subnet to the network 209
 WARN  [admin.zone.AddVmwareDcCmd] (1538955034@qtp-1454176402-23:) Exception:
 com.cloud.exception.ResourceInUseException: This DC is already part of other 
 CloudStack zone(s). Cannot add this DC to more zones.
 at 
 com.cloud.hypervisor.vmware.manager.VmwareManagerImpl.addVmwareDatacenter(VmwareManagerImpl.java:952)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 org.apache.cloudstack.api.command.admin.zone.AddVmwareDcCmd.execute(AddVmwareDcCmd.java:97)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
 at com.cloud.api.ApiServer.queueCommand(ApiServer.java:528)
 at com.cloud.api.ApiServer.handleRequest(ApiServer.java:371)
 at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:304)
 at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
 at 
 org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
 at 
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401)
 at 
 org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
 at 
 org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
 at 
 org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
 at 
 org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
 at 
 org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
 at 
 org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
 at 
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
 at org.mortbay.jetty.Server.handle(Server.java:326)
 at 
 org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
 at 
 org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
 at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
 at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
 at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
 at 
 org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
 at 
 org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
 INFO  [cloud.api.ApiServer] (1538955034@qtp-1454176402-23:) This DC is 
 already part of other CloudStack zone(s). Cannot add this DC to more zones.
 INFO  [vmware.resource.VmwareResource] (DirectAgent-100:10.223.74.132) 
 Executing resource NetworkUsageCommand
 It looks like the CustomFieldDef[] cloud.zone key is getting defined globally 
 for all DCs. So once it's set to true, it's probably getting read as true for 
 new DCs as well. Or probably it's just that we're reading it wrongly in the 
 mgmt server (doesn't look like that's the case though).

--
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-2867) Cannot add multiple vmware zones in vCenter

2013-06-06 Thread Sateesh Chodapuneedi (JIRA)


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

Sateesh Chodapuneedi resolved CLOUDSTACK-2867.
--

Resolution: Fixed

 Cannot add multiple vmware zones in vCenter
 ---

 Key: CLOUDSTACK-2867
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2867
 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: VMWare cloudstack deployment.
Reporter: Venkata Siva Vijayendra Bhamidipati
Assignee: Sateesh Chodapuneedi

 Create a datacenter in vmware, say dc1, add a cluster to it, say cluster1, 
 add one or more hosts to cluster1. Add a zone in cloudstack, and provide 
 dc1/cluster1 info for it. It'll go through fine. Next, create dc2, cluster2 
 in vCenter with new host(s). Attempt to add a new zone in cloudstack 
 providing dc2/cluster2 info. It will fail with the following exception:
 INFO  [cloud.configuration.ConfigurationManagerImpl] 
 (94321089@qtp-1454176402-24:) adding a new subnet to the network 209
 WARN  [admin.zone.AddVmwareDcCmd] (1538955034@qtp-1454176402-23:) Exception:
 com.cloud.exception.ResourceInUseException: This DC is already part of other 
 CloudStack zone(s). Cannot add this DC to more zones.
 at 
 com.cloud.hypervisor.vmware.manager.VmwareManagerImpl.addVmwareDatacenter(VmwareManagerImpl.java:952)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 org.apache.cloudstack.api.command.admin.zone.AddVmwareDcCmd.execute(AddVmwareDcCmd.java:97)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
 at com.cloud.api.ApiServer.queueCommand(ApiServer.java:528)
 at com.cloud.api.ApiServer.handleRequest(ApiServer.java:371)
 at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:304)
 at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
 at 
 org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
 at 
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401)
 at 
 org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
 at 
 org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
 at 
 org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
 at 
 org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
 at 
 org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
 at 
 org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
 at 
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
 at org.mortbay.jetty.Server.handle(Server.java:326)
 at 
 org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
 at 
 org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
 at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
 at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
 at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
 at 
 org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
 at 
 org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
 INFO  [cloud.api.ApiServer] (1538955034@qtp-1454176402-23:) This DC is 
 already part of other CloudStack zone(s). Cannot add this DC to more zones.
 INFO  [vmware.resource.VmwareResource] (DirectAgent-100:10.223.74.132) 
 Executing resource NetworkUsageCommand
 It looks like the CustomFieldDef[] cloud.zone key is getting defined globally 
 for all DCs. So once it's set to true, it's probably getting read as true for 
 new DCs as well. Or probably it's just that we're reading it wrongly in the 
 mgmt server (doesn't look like that's the case though).

--
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-2873) [UI] Dedicating resources to accounts is using incorrect parameter for account name.

2013-06-06 Thread Saksham Srivastava (JIRA)

Saksham Srivastava created CLOUDSTACK-2873:
--

 Summary: [UI] Dedicating resources to accounts is using incorrect 
parameter for account name.
 Key: CLOUDSTACK-2873
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2873
 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: Saksham Srivastava


When dedicating resources to account, the correct parameter for account name in 
API is 'account'.
From Firebug logs, UI is using 'accountId' instead of 'account':

GET 
/client/api?command=dedicatePodpodId=40f90446-e812-4b23-a097-9af3faebe47bdomainId=b45bc01f-a1a5-4ebe-bc9f-0f59e6ac0756accountId=a1response=jsonsessionkey=%2FBZKXpzZahheAravXzxlxV9bQfg%3D_=1370511380506

GET 
/client/api?command=dedicateClusterclusterId=9f999ae8-3732-478c-b0a6-e14ac72a9057domainId=b45bc01f-a1a5-4ebe-bc9f-0f59e6ac0756accountId=a1response=jsonsessionkey=%2FBZKXpzZahheAravXzxlxV9bQfg%3D_=1370512023268

--
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-2734) [SXM][UI]: storage pools which are not suitable for migration should not be listed for a volume

2013-06-06 Thread Devdeep Singh (JIRA)

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

Devdeep Singh resolved CLOUDSTACK-2734.
---

Resolution: Not A Problem

This is by design. We list out all the storage pools to which a volume can be
migrated, but the pools with which the tags don't match are marked as
unsuitable. The api can only be used by root admins and she may choose to
migrate a volume to a pool even though it may be unsuitable. For example, when
only pools marked a unsuitable are available. We want to leave that decision to
the admin.

When hosts for migration are listed, unsuitable hosts get listed there too.

[SXM][UI]: storage pools which are not suitable for migration should not be
listed for a volume
---

Key: CLOUDSTACK-2734
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2734
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: Srikanteswararao Talluri
Assignee: Devdeep Singh
Priority: Critical
Fix For: 4.2.0

Steps to reproduce:
1. Add primary storage pool P1 and P2 with tags testpool and P3, P4 without
any tags
2. create a disk offering D1 to use this tag testpool
3. create a volume V1 by selecting disk offering D1.
4. Now,click on the migrateVolume
Step 4, lists all primary storage pools but it shows P1 P2 as suitable and
P3P4 as not suitable.
Expected behaviour:
When P3 and P4 are not suitable for migration, don't show them at all.

--
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-2805) [VMware] addVmwareDc fails with NPE when non-existent DC name is passed to the API

2013-06-06 Thread Sateesh Chodapuneedi (JIRA)


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

Sateesh Chodapuneedi resolved CLOUDSTACK-2805.
--

Resolution: Fixed

 [VMware] addVmwareDc fails with NPE when non-existent DC name is passed to 
 the API
 --

 Key: CLOUDSTACK-2805
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2805
 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 # b4969c4af5264879ccbec01b65b6c94886fc79d4
Reporter: venkata swamybabu budumuru
Assignee: Sateesh Chodapuneedi
Priority: Minor
 Fix For: 4.2.0

 Attachments: logs.tgz


 Steps to reproduce :
 1. Have the latest CS setup ready and installed
 2. Try to setup advanced zone with vmware cluster
 3. execute the addVmwareDc API with name parameter set to a DC value that 
 doesn't exist on vCenter.
 Observations:
 (i) It fails with the following NPE in the mgmt server logs
 Here is the api that was executed :
 http://10.147.59.194:8096/api?command=addVmwareDcname=Zone1zoneId=1username=administratorpassword=password_123url=http://10.147.60.13/Infra/Cluster1response=json
 snippet from mgmt server log:
 013-06-03 09:03:08,808 DEBUG [cloud.consoleproxy.ConsoleProxyManagerImpl] 
 (consoleproxy-1:null) Skip capacity scan due to there is no Primary Storage 
 UPintenance mode
 2013-06-03 09:03:10,655 DEBUG [vmware.resource.VmwareContextFactory] 
 (ApiServer-4:null) initialize VmwareContext. url: 
 https://10.147.60.13/sdk/vimService, username: administrator, password: 
 p***
 2013-06-03 09:03:12,304 DEBUG 
 [network.router.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:null) Found 0 routers to update status.
 2013-06-03 09:03:12,307 DEBUG 
 [network.router.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:null) Found 0 networks to update RvR status.
 2013-06-03 09:03:12,411 DEBUG 
 [network.router.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:null) Found 0 routers to update status.
 2013-06-03 09:03:12,414 DEBUG 
 [network.router.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:null) Found 0 networks to update RvR status.
 2013-06-03 09:03:26,955 ERROR [vmware.manager.VmwareManagerImpl] 
 (ApiServer-4:null) VMware DC discovery failed due to : Exception: 
 java.lang.NullPointerException
 Message: null
 2013-06-03 09:03:26,980 INFO  [cloud.api.ApiServer] (ApiServer-4:null) VMware 
 DC discovery failed due to : Exception: java.lang.NullPointerException
 Message: null
 2013-06-03 09:03:26,982 ERROR [cloud.api.ApiServer] (ApiServer-4:null) error!
 java.lang.IllegalArgumentException: Line break in reason phrase.
 at 
 org.apache.http.message.BasicHttpResponse.setReasonPhrase(BasicHttpResponse.java:159)
 at com.cloud.api.ApiServer.writeResponse(ApiServer.java:887)
 at com.cloud.api.ApiServer.handle(ApiServer.java:304)
 at 
 org.apache.http.protocol.HttpService.doService(HttpService.java:375)
 at 
 org.apache.http.protocol.HttpService.handleRequest(HttpService.java:290)
 at com.cloud.api.ApiServer$WorkerTask.run(ApiServer.java:988)
 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)
 (ii) when the same API is executed with correct DC name then everything goes 
 fine.
 http://10.147.59.194:8096/api?command=addVmwareDcname=InfrazoneId=1username=administratorpassword=password_123url=http://10.147.60.13/Infra/Cluster1
 Attaching all the mgmt server logs and db dump to the bug.

--
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-2805) [VMware] addVmwareDc fails with NPE when non-existent DC name is passed to the API

2013-06-06 Thread ASF subversion and git services (JIRA)


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

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

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

CLOUDSTACK-2805 [VMware] addVmwareDc fails with NPE when non-existent DC name 
is passed to the API
Made vcenter as required parameter to addVmwareDc API.
Removed stale parameter url from addVmwareDc API.
Improved Exception handling, logging remote exception details.


 [VMware] addVmwareDc fails with NPE when non-existent DC name is passed to 
 the API
 --

 Key: CLOUDSTACK-2805
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2805
 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 # b4969c4af5264879ccbec01b65b6c94886fc79d4
Reporter: venkata swamybabu budumuru
Assignee: Sateesh Chodapuneedi
Priority: Minor
 Fix For: 4.2.0

 Attachments: logs.tgz


 Steps to reproduce :
 1. Have the latest CS setup ready and installed
 2. Try to setup advanced zone with vmware cluster
 3. execute the addVmwareDc API with name parameter set to a DC value that 
 doesn't exist on vCenter.
 Observations:
 (i) It fails with the following NPE in the mgmt server logs
 Here is the api that was executed :
 http://10.147.59.194:8096/api?command=addVmwareDcname=Zone1zoneId=1username=administratorpassword=password_123url=http://10.147.60.13/Infra/Cluster1response=json
 snippet from mgmt server log:
 013-06-03 09:03:08,808 DEBUG [cloud.consoleproxy.ConsoleProxyManagerImpl] 
 (consoleproxy-1:null) Skip capacity scan due to there is no Primary Storage 
 UPintenance mode
 2013-06-03 09:03:10,655 DEBUG [vmware.resource.VmwareContextFactory] 
 (ApiServer-4:null) initialize VmwareContext. url: 
 https://10.147.60.13/sdk/vimService, username: administrator, password: 
 p***
 2013-06-03 09:03:12,304 DEBUG 
 [network.router.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:null) Found 0 routers to update status.
 2013-06-03 09:03:12,307 DEBUG 
 [network.router.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:null) Found 0 networks to update RvR status.
 2013-06-03 09:03:12,411 DEBUG 
 [network.router.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:null) Found 0 routers to update status.
 2013-06-03 09:03:12,414 DEBUG 
 [network.router.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:null) Found 0 networks to update RvR status.
 2013-06-03 09:03:26,955 ERROR [vmware.manager.VmwareManagerImpl] 
 (ApiServer-4:null) VMware DC discovery failed due to : Exception: 
 java.lang.NullPointerException
 Message: null
 2013-06-03 09:03:26,980 INFO  [cloud.api.ApiServer] (ApiServer-4:null) VMware 
 DC discovery failed due to : Exception: java.lang.NullPointerException
 Message: null
 2013-06-03 09:03:26,982 ERROR [cloud.api.ApiServer] (ApiServer-4:null) error!
 java.lang.IllegalArgumentException: Line break in reason phrase.
 at 
 org.apache.http.message.BasicHttpResponse.setReasonPhrase(BasicHttpResponse.java:159)
 at com.cloud.api.ApiServer.writeResponse(ApiServer.java:887)
 at com.cloud.api.ApiServer.handle(ApiServer.java:304)
 at 
 org.apache.http.protocol.HttpService.doService(HttpService.java:375)
 at 
 org.apache.http.protocol.HttpService.handleRequest(HttpService.java:290)
 at com.cloud.api.ApiServer$WorkerTask.run(ApiServer.java:988)
 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)
 (ii) when the same API is executed with correct DC name then everything goes 
 fine.
 http://10.147.59.194:8096/api?command=addVmwareDcname=InfrazoneId=1username=administratorpassword=password_123url=http://10.147.60.13/Infra/Cluster1
 Attaching all the mgmt server logs and db dump to the bug.

--
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-1986) Key translation fails for the Japanese keyboard keys ¥_,\ |, Muhenkan, Henkan, Hiragana/Katakana, Kanji Key Caps Loc

2013-06-06 Thread Minying Bao (JIRA)

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

Minying Bao commented on CLOUDSTACK-1986:
-

Update the Actual Result as follows

The Japanese keyboard keys ￥｜ー, \_ろ are not working well in Hiragana,Katakana
KANA input methods.

Key translation fails for the Japanese keyboard keys ¥_,\ |, Muhenkan,
Henkan, Hiragana/Katakana, Kanji Key Caps Loc
--

Key: CLOUDSTACK-1986
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1986
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: VNC Proxy
Affects Versions: 4.0.2
Environment: Build No.#133
(CloudStack-non-OSS-MASTER-133-rhel6.3.tar.gz)
XenServer6.1 for Host Server, CentOS6.3 for NFS server and CloudStack-Mgr
Server, Win7-x86 for Client machine.
Reporter: Karthikeyan Ravichandran
Fix For: 4.2.0

Steps
1. Setup the CloudStack environments with build 4.2#133.
2. Bring Japanese Win-7 x86 VM.
3. Access the VM via Console Proxy from the Japanese client machine connected
to Japanese Keyboard.
4. Hit all the keys with Japanese localized keyboard.
Expected Result
All the keys should work fine.
Actual Result
The Japanese keyboard keys ¥_,\ |, Muhenkan, Henkan, Hiragana/Katakana are
not working even after possible key translations tried.
Note: Caps Lock Kanji key works well in IE browser after key translation,
but not working well in Firefox browser.

[jira] [Commented] (CLOUDSTACK-2823) SystemVMs start fail and have no HA


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

Wei Zhou commented on CLOUDSTACK-2823:
--

Same issue in Redhat Community:

https://bugzilla.redhat.com/show_bug.cgi?id=729923
[virtio-serial] First message is not delivered after connected to 
virtio-port[NEEDINFO] 

it mentions:
Rebuild the qemu-kvm package 0.12.1.2-2.295 with this patch 
[http://git.qemu.org/?p=qemu.git;a=commit;h=ed8e5a85a1741147ce06932b478a509ce3407061]
 solves the issue.

After I upgrade qemu from 0.12.1.2 (default in CentOS 6.4) to 1.2.1, this issue 
does not exist any more.

-Wei

 SystemVMs start fail and have no HA
 ---

 Key: CLOUDSTACK-2823
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2823
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.0
 Environment: CentOS 6.4, KVM
 CloudStack master
Reporter: Wei Zhou
Assignee: Marcus Sorensen

 Host:
 [root@cs-kvm015 ~]# virsh version
 Compiled against library: libvirt 0.10.2
 Using library: libvirt 0.10.2
 Using API: QEMU 0.10.2
 Running hypervisor: QEMU 0.12.1
 Network:
 em0 - cloudbr0 (Guest, Public), Guest: 172.16.61.0/24, Public: 10.11.11.0/24 
 (Can not connect outside)
 em1.103 - cloudbr1 (Management, Storage) , IP: 192.168.103.*
 Issue descripion
 (1) SystemVMs (SSVM, CPVM) start fails , and have no IP (Public, guest, 
 management)
 (2) After I destroyed SystemVM, no new SystemVM will be created automatically.
 This issue only exists on master branch
 Deploy 4.1 successfully, and SystemVms work well. 

--
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-2823) SystemVMs start fail and have no HA


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

Wei Zhou updated CLOUDSTACK-2823:
-

Priority: Critical  (was: Major)

 SystemVMs start fail and have no HA
 ---

 Key: CLOUDSTACK-2823
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2823
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.0
 Environment: CentOS 6.4, KVM
 CloudStack master
Reporter: Wei Zhou
Assignee: Marcus Sorensen
Priority: Critical

 Host:
 [root@cs-kvm015 ~]# virsh version
 Compiled against library: libvirt 0.10.2
 Using library: libvirt 0.10.2
 Using API: QEMU 0.10.2
 Running hypervisor: QEMU 0.12.1
 Network:
 em0 - cloudbr0 (Guest, Public), Guest: 172.16.61.0/24, Public: 10.11.11.0/24 
 (Can not connect outside)
 em1.103 - cloudbr1 (Management, Storage) , IP: 192.168.103.*
 Issue descripion
 (1) SystemVMs (SSVM, CPVM) start fails , and have no IP (Public, guest, 
 management)
 (2) After I destroyed SystemVM, no new SystemVM will be created automatically.
 This issue only exists on master branch
 Deploy 4.1 successfully, and SystemVms work well. 

--
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-1892) [Upgrade 4.0 to 4.2] After upgrading from 4.0 to 4.2 a user network is not able to acquire IPs


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

Likitha Shetty reassigned CLOUDSTACK-1892:
--

Assignee: Likitha Shetty

 [Upgrade 4.0 to 4.2] After upgrading from 4.0 to 4.2  a user network is not 
 able to acquire IPs
 ---

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

 Attachments: upgrade ip aloocation.jpg


 Steps :
 =
 1. Upgrade CS from 4.0 to 4.2
 2. Create a user account.
 3. Login to the user account and create a network
 4. Acquire IPs for the network
 Expected behaviour:
 
 IPs should be acquired successfully
 Observed behaviour :
 
 IP acuisition fails with  unable to figure out zone to assign IPs 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] [Assigned] (CLOUDSTACK-2170) NPE while updating the updatePhysicalNetwork to enable state with invalid ID

2013-06-06 Thread ASF subversion and git services (JIRA)


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

Likitha Shetty reassigned CLOUDSTACK-2170:
--

Assignee: Likitha Shetty

 NPE while updating the updatePhysicalNetwork  to enable state with invalid ID
 -

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


 Setup: Advanced Networking Zone with Nexus, MS : RHEL 6.3
 Steps:
 1. Add VNMC provider to cloudstack:
 http://localhost/client/api?command=addNetworkServiceProviderphysicalnetworkid=200name=CiscoVnmc
 2) Tried to update the above provider state as enabled: 
 (http://10.102.192.194:8096/client/api?command=updatePhysicalNetworkid=4state=Enabled)
  
 Observation: 
 NPE while updating the updatePhysicalNetwork  to enable state with invalid ID 
 2013-04-24 16:41:19,108 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-12:job-12) Executing 
 org.apache.cloudstack.api.command.admin.network.UpdatePhysicalNetworkCmd for 
 job-12
 2013-04-24 16:41:19,147 ERROR [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-12:job-12) Unexpected exception while executing 
 org.apache.cloudstack.api.command.admin.network.UpdatePhysicalNetworkCmd
 java.lang.NullPointerException
 at 
 com.cloud.utils.AnnotationHelper.getTableName(AnnotationHelper.java:34)
 at 
 com.cloud.utils.exception.CloudRuntimeException.addProxyObject(CloudRuntimeException.java:59)
 at 
 com.cloud.network.NetworkServiceImpl.updatePhysicalNetwork(NetworkServiceImpl.java:2301)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 org.apache.cloudstack.api.command.admin.network.UpdatePhysicalNetworkCmd.execute(UpdatePhysicalNetworkCmd.java:104)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
 at 
 com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at java.lang.Thread.run(Thread.java:679)
 2013-04-24 16:41:19,148 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-12:job-12) Complete async job-12, jobStatus: 2, resultCode: 
 530, result: Error Code: 530 Error text: null
 2013-04-24 16:41:23,502 DEBUG [cloud.server.StatsCollector] 
 (StatsCollector-1:null) VmStatsCollector is running...
 This XML file does not appear to have any style information associated with 
 it. The document tree is shown below.
   queryasyncjobresultresponse 
 cloud-stack-version=4.2.0-SNAPSHOTaccountid1daa4ce0-acca-11e2-8b37-c2ae49691a00/accountiduserid1dac1908-acca-11e2-8b37-c2ae49691a00/useridcmdorg.apache.cloudstack.api.command.admin.network.UpdatePhysicalNetworkCmd/cmdjobstatus2/jobstatusjobprocstatus0/jobprocstatusjobresultcode530/jobresultcodejobresulttypeobject/jobresulttypejobresulterrorcode530/errorcodeerrortextCommand
  failed due to Internal Server 
 Error/errortext/jobresultcreated2013-04-24T16:41:19+0530/createdjobid6e7887c1-83da-4d02-98e7-2cc36949364b/jobid/queryasyncjobresultresponse

--
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-2872) ubuntu 12.4 kvm issue CS 4.1 libvirt complaint and not able to start systemvm

2013-06-06 Thread David Nalley (JIRA)


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

David Nalley updated CLOUDSTACK-2872:
-

Fix Version/s: 4.1.1

  ubuntu 12.4 kvm issue CS 4.1 libvirt complaint and not able to start systemvm
 --

 Key: CLOUDSTACK-2872
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2872
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.1.0
 Environment: Ubuntu 12.04 host libvirt 0.98
Reporter: Philippe Van Hecke
 Fix For: 4.1.1


 I upgraded our test environemen(4.0.2) to 4.1
 and we have the following issue with libvirtd
  virDomainTimerDefParseXML:4630 : internal error unknown timer name
 'kvmclock'
 After an upgrade of libvirt to 
 version 1.0.2 from following ppa ppa:pfak/backports
 https://launchpad.net/~pfak/+archive/backports
 The problem was solved.

--
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-659) Enable storage xenmotion support in XenServer 6.1

2013-06-06 Thread Ram Ganesh (JIRA)


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

Ram Ganesh resolved CLOUDSTACK-659.
---

Resolution: Fixed

 Enable storage xenmotion support in XenServer 6.1
 -

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


 XenServer introduced support for Storage XenMotion in the latest version 
 (6.1). Storage XenMotion allows VMs to be moved from one host to another, 
 where the VMs are not located on storage shared between the two hosts. It 
 provides the option to live migrate a VM’s disks along with the VM itself. It 
 is now possible to migrate a VM from one resource pool to another, or to 
 migrate a VM whose disks are on local storage, or even to migrate a VM’s 
 disks from one storage repository to another, all while the VM is running.
 This issue is to track this feature request.
 Release Planning:
 Dev list discussions:
   http://markmail.org/message/numdk6pdab2hekdp
   http://markmail.org/message/cskrdafitghy7o6q
 Functional Spec: 
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Enabling+Storage+XenMotion+for+XenServer
 Feature branch: via reviewboard

--
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-2872) ubuntu 12.4 kvm issue CS 4.1 libvirt complaint and not able to start systemvm

2013-06-06 Thread David Nalley (JIRA)


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

David Nalley updated CLOUDSTACK-2872:
-

Priority: Blocker  (was: Major)

  ubuntu 12.4 kvm issue CS 4.1 libvirt complaint and not able to start systemvm
 --

 Key: CLOUDSTACK-2872
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2872
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.1.0
 Environment: Ubuntu 12.04 host libvirt 0.98
Reporter: Philippe Van Hecke
Priority: Blocker
 Fix For: 4.1.1


 I upgraded our test environemen(4.0.2) to 4.1
 and we have the following issue with libvirtd
  virDomainTimerDefParseXML:4630 : internal error unknown timer name
 'kvmclock'
 After an upgrade of libvirt to 
 version 1.0.2 from following ppa ppa:pfak/backports
 https://launchpad.net/~pfak/+archive/backports
 The problem was solved.

--
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-2288) NPE while creating volume from snapshot when the primary storage is in maintenance state

2013-06-06 Thread Sanjay Tripathi (JIRA)


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

Sanjay Tripathi updated CLOUDSTACK-2288:


Status: Ready To Review  (was: In Progress)

 NPE while creating volume from snapshot when the primary storage is in 
 maintenance state
 

 Key: CLOUDSTACK-2288
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2288
 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: Sailaja Mada
Assignee: Sanjay Tripathi
 Fix For: 4.2.0


 Setup: Advanced Networking Zone, Xen 6.1 , MS - RHEL 6.3 
 Steps:
 1. Deploy instance as ROOT admin
 2. Create the snapshot for the ROOT volume of this instance 
 3. Put the only available primary storage to maintenance
 4. Try to create the volume from this snapshot. 
 Observation:
 NPE while creating volume from snapshot when the primary storage is in 
 maintenance state
 2013-04-30 12:05:56,653 DEBUG [cloud.api.ApiServlet] (catalina-exec-16:null) 
 ===END===  10.144.6.19 -- GET  
 command=createVolumeresponse=jsonsessionkey=mTrNgYbkndiHLZNAV%2BoAAzDOQFw%3Dsnapshotid=79b17cda-71f7-4be9-9e7c-bedcb73a7106name=newsnapvol1_=1367303886423
 2013-04-30 12:05:56,658 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-1:job-73) Executing 
 org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd for job-73
 2013-04-30 12:05:56,755 DEBUG [cloud.storage.StorageManagerImpl] 
 (Job-Executor-1:job-73) Storage pool garbage collector found 0 templates to 
 clean up in storage pool: PS1
 2013-04-30 12:05:56,767 DEBUG [cloud.storage.StorageManagerImpl] 
 (Job-Executor-1:job-73) Secondary storage garbage collector found 0 templates 
 to cleanup on secondary storage host: 
 nfs://10.102.192.100/cpg_vol/sailaja/masterxenss
 2013-04-30 12:05:56,819 WARN  [cloud.storage.StorageManagerImpl] 
 (Job-Executor-1:job-73) Failed to cleanup snapshots for volume 15 due to can 
 not find secondary storage VM agent for data center 1
 2013-04-30 12:05:56,840 WARN  [cloud.storage.StorageManagerImpl] 
 (Job-Executor-1:job-73) Failed to cleanup snapshots for volume 18 due to can 
 not find secondary storage VM agent for data center 1
 2013-04-30 12:05:56,874 DEBUG [cloud.storage.StorageManagerImpl] 
 (Job-Executor-1:job-73) Secondary storage garbage collector found 0 templates 
 to cleanup on secondary storage host: 
 nfs://10.102.192.100/cpg_vol/sailaja/masterxenss
 2013-04-30 12:05:56,890 DEBUG [allocator.impl.UserConcentratedAllocator] 
 (Job-Executor-1:job-73) There are no pods with enough memory/CPU capacity in 
 zone Advzone1
 2013-04-30 12:05:56,946 DEBUG [cloud.storage.VolumeManagerImpl] 
 (Job-Executor-1:job-73) Failed to create volume: 28
 java.lang.NullPointerException
 at 
 com.cloud.storage.VolumeManagerImpl.createVolumeFromSnapshot(VolumeManagerImpl.java:537)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 com.cloud.storage.VolumeManagerImpl.createVolumeFromSnapshot(VolumeManagerImpl.java:597)
 at 
 com.cloud.storage.VolumeManagerImpl.createVolume(VolumeManagerImpl.java:1014)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 com.cloud.storage.VolumeManagerImpl.createVolume(VolumeManagerImpl.java:180)
 at 
 org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd.execute(CreateVolumeCmd.java:168)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
 at 
 com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at java.lang.Thread.run(Thread.java:679)
 2013-04-30 12:05:57,019 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-1:job-73) Complete async job-73, jobStatus: 2, resultCode: 530, 
 result: Error Code: 530 Error text: Failed to create a volume
 2013-04-30 12:05:59,699 DEBUG [cloud.api.ApiServlet] (catalina-exec-12:null) 
 ===START===  10.144.6.19 -- GET  
 command=queryAsyncJobResultjobId=bdd08ea3-cf7f-4369-9778-c32e6267ffe1response=jsonsessionkey=mTrNgYbkndiHLZNAV%2BoAAzDOQFw%3D_=1367303889729
 2013-04-30

[jira] [Commented] (CLOUDSTACK-2675) Missing network_id on restarting/host adding to a new shared network

2013-06-06 Thread Tomasz Zieba (JIRA)


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

Tomasz Zieba commented on CLOUDSTACK-2675:
--

This issue has been solved in version 4.1.0.



 Missing network_id on restarting/host adding to a new shared network
 

 Key: CLOUDSTACK-2675
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2675
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.0.2
 Environment: CloudStack 4.0.2, 
Reporter: Tomasz Zieba

 I have got the same situation as follows: 
 http://mail-archives.apache.org/mod_mbox/cloudstack-users/201304.mbox/%3c4b77b928-a3c5-4742-8ac3-652af4a7c...@ringplus.net%3E

--
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-2675) Missing network_id on restarting/host adding to a new shared network

2013-06-06 Thread Tomasz Zieba (JIRA)


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

Tomasz Zieba closed CLOUDSTACK-2675.


   Resolution: Fixed
Fix Version/s: 4.1.0

This issue has been solved in version 4.1.0.


 Missing network_id on restarting/host adding to a new shared network
 

 Key: CLOUDSTACK-2675
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2675
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.0.2
 Environment: CloudStack 4.0.2, 
Reporter: Tomasz Zieba
 Fix For: 4.1.0


 I have got the same situation as follows: 
 http://mail-archives.apache.org/mod_mbox/cloudstack-users/201304.mbox/%3c4b77b928-a3c5-4742-8ac3-652af4a7c...@ringplus.net%3E

--
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-2873) [UI] Dedicating resources to accounts is using incorrect parameter for account name.


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

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

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

CLOUDSTACK-2873: Passing account name for explicit dedication


 [UI] Dedicating resources to accounts is using incorrect parameter for 
 account name.
 

 Key: CLOUDSTACK-2873
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2873
 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: Saksham Srivastava

 When dedicating resources to account, the correct parameter for account name 
 in API is 'account'.
 From Firebug logs, UI is using 'accountId' instead of 'account':
 GET 
 /client/api?command=dedicatePodpodId=40f90446-e812-4b23-a097-9af3faebe47bdomainId=b45bc01f-a1a5-4ebe-bc9f-0f59e6ac0756accountId=a1response=jsonsessionkey=%2FBZKXpzZahheAravXzxlxV9bQfg%3D_=1370511380506
 GET 
 /client/api?command=dedicateClusterclusterId=9f999ae8-3732-478c-b0a6-e14ac72a9057domainId=b45bc01f-a1a5-4ebe-bc9f-0f59e6ac0756accountId=a1response=jsonsessionkey=%2FBZKXpzZahheAravXzxlxV9bQfg%3D_=1370512023268

--
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-2873) [UI] Dedicating resources to accounts is using incorrect parameter for account name.

2013-06-06 Thread Pranav Saxena (JIRA)


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

Pranav Saxena resolved CLOUDSTACK-2873.
---

   Resolution: Fixed
Fix Version/s: 4.2.0

 [UI] Dedicating resources to accounts is using incorrect parameter for 
 account name.
 

 Key: CLOUDSTACK-2873
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2873
 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: Saksham Srivastava
Assignee: Pranav Saxena
 Fix For: 4.2.0


 When dedicating resources to account, the correct parameter for account name 
 in API is 'account'.
 From Firebug logs, UI is using 'accountId' instead of 'account':
 GET 
 /client/api?command=dedicatePodpodId=40f90446-e812-4b23-a097-9af3faebe47bdomainId=b45bc01f-a1a5-4ebe-bc9f-0f59e6ac0756accountId=a1response=jsonsessionkey=%2FBZKXpzZahheAravXzxlxV9bQfg%3D_=1370511380506
 GET 
 /client/api?command=dedicateClusterclusterId=9f999ae8-3732-478c-b0a6-e14ac72a9057domainId=b45bc01f-a1a5-4ebe-bc9f-0f59e6ac0756accountId=a1response=jsonsessionkey=%2FBZKXpzZahheAravXzxlxV9bQfg%3D_=1370512023268

--
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-2873) [UI] Dedicating resources to accounts is using incorrect parameter for account name.

2013-06-06 Thread Pranav Saxena (JIRA)


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

Pranav Saxena reassigned CLOUDSTACK-2873:
-

Assignee: Pranav Saxena

 [UI] Dedicating resources to accounts is using incorrect parameter for 
 account name.
 

 Key: CLOUDSTACK-2873
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2873
 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: Saksham Srivastava
Assignee: Pranav Saxena

 When dedicating resources to account, the correct parameter for account name 
 in API is 'account'.
 From Firebug logs, UI is using 'accountId' instead of 'account':
 GET 
 /client/api?command=dedicatePodpodId=40f90446-e812-4b23-a097-9af3faebe47bdomainId=b45bc01f-a1a5-4ebe-bc9f-0f59e6ac0756accountId=a1response=jsonsessionkey=%2FBZKXpzZahheAravXzxlxV9bQfg%3D_=1370511380506
 GET 
 /client/api?command=dedicateClusterclusterId=9f999ae8-3732-478c-b0a6-e14ac72a9057domainId=b45bc01f-a1a5-4ebe-bc9f-0f59e6ac0756accountId=a1response=jsonsessionkey=%2FBZKXpzZahheAravXzxlxV9bQfg%3D_=1370512023268

--
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-2874) fix the upgrade for the deployment with F5/SRX combination prior to 3.0 release

2013-06-06 Thread Murali Reddy (JIRA)

Murali Reddy created CLOUDSTACK-2874:


 Summary: fix the upgrade for the deployment with F5/SRX 
combination prior to 3.0 release
 Key: CLOUDSTACK-2874
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2874
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: pre-4.0.0
Reporter: Murali Reddy
Assignee: Murali Reddy
 Fix For: 4.2.0


Prior to 3.0, deployments had to have combination of F5 and SRX providing load 
balancing and firewall services if external devices need to be used. So the 
deployments were either using virtual router providing FW/LB services or F5/SRX 
combination.

3.0 introduced notion of network offering and concept of service and service 
provider. On upgrade, deployments with F5 and SRX, needed to be fit into the 
network offering and network service and provider paradigm.

Fix should include following

- add F5 network service provider into a physical network if there if F5 
deployed in the zone
- add instance of F5 network service provider
- add SRX network service provider into a physical network if there if SRX 
deployed in the zone
- add instance of SRX network service provider
- upgrade all the guest networks to network offering 'Isolated with external 
providers


--
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-2874) fix the upgrade for the deployment with F5/SRX combination prior to 3.0 release

2013-06-06 Thread ASF subversion and git services (JIRA)


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

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

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

CLOUDSTACK-2874: fix the upgrade for the deployment with F5/SRX
combination prior to 3.0 release

Fix does following:

- add F5 network service provider into a physical network if there if F5
  deployed in the zone

- add instance of F5 network service provider

- add SRX network service provider into a physical network if there if
  SRX deployed in the zone

- add instance of SRX network service provider

- upgrade all the guest networks to network offering 'Isolated with
  external providers


 fix the upgrade for the deployment with F5/SRX combination prior to 3.0 
 release
 ---

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


 Prior to 3.0, deployments had to have combination of F5 and SRX providing 
 load balancing and firewall services if external devices need to be used. So 
 the deployments were either using virtual router providing FW/LB services or 
 F5/SRX combination.
 3.0 introduced notion of network offering and concept of service and service 
 provider. On upgrade, deployments with F5 and SRX, needed to be fit into the 
 network offering and network service and provider paradigm.
 Fix should include following
 - add F5 network service provider into a physical network if there if F5 
 deployed in the zone
 - add instance of F5 network service provider
 - add SRX network service provider into a physical network if there if SRX 
 deployed in the zone
 - add instance of SRX network service provider
 - upgrade all the guest networks to network offering 'Isolated with external 
 providers

--
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-2874) fix the upgrade for the deployment with F5/SRX combination prior to 3.0 release

2013-06-06 Thread Murali Reddy (JIRA)


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

Murali Reddy resolved CLOUDSTACK-2874.
--

Resolution: Fixed

 fix the upgrade for the deployment with F5/SRX combination prior to 3.0 
 release
 ---

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


 Prior to 3.0, deployments had to have combination of F5 and SRX providing 
 load balancing and firewall services if external devices need to be used. So 
 the deployments were either using virtual router providing FW/LB services or 
 F5/SRX combination.
 3.0 introduced notion of network offering and concept of service and service 
 provider. On upgrade, deployments with F5 and SRX, needed to be fit into the 
 network offering and network service and provider paradigm.
 Fix should include following
 - add F5 network service provider into a physical network if there if F5 
 deployed in the zone
 - add instance of F5 network service provider
 - add SRX network service provider into a physical network if there if SRX 
 deployed in the zone
 - add instance of SRX network service provider
 - upgrade all the guest networks to network offering 'Isolated with external 
 providers

--
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-2866) [Automation] Unable to start a VM due to concurrent operation

2013-06-06 Thread Devdeep Singh (JIRA)


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

Devdeep Singh reassigned CLOUDSTACK-2866:
-

Assignee: Devdeep Singh

 [Automation]  Unable to start a VM due to concurrent operation
 --

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


 Steps to reproduce:
 1. deploy first VM in an account
 2. try to stope the VM created in step1
 3. stop the DomR
 4. try to deploy another VM in the same account.
  ===START===  10.151.133.42 -- GET  
 command=deployVirtualMachinezoneId=9aaae1c8-294c-41f0-b392-90086e814b53templateId=b4a014e8-ce23-11e2-afec-06b27059hypervisor=XenServerserviceOfferingId=eefcc446-8827-4bb3-b97f-0877ece9223enetworkIds=b98534fc-25b5-4834-9bc4-7c05d8b23ab9response=jsonsessionkey=gzAU%2FyMzZz0IoXpemIT8%2Fh4mPVg%3D_=1370460715197
 2013-06-06 06:26:05,128 DEBUG [cloud.api.ApiDispatcher] 
 (catalina-exec-9:null) InfrastructureEntity name 
 is:com.cloud.offering.ServiceOffering
 2013-06-06 06:26:05,131 DEBUG [cloud.api.ApiDispatcher] 
 (catalina-exec-9:null) ControlledEntity name 
 is:com.cloud.template.VirtualMachineTemplate
 2013-06-06 06:26:05,136 DEBUG [cloud.api.ApiDispatcher] 
 (catalina-exec-9:null) ControlledEntity name is:com.cloud.network.Network
 2013-06-06 06:26:05,160 DEBUG [cloud.network.NetworkModelImpl] 
 (catalina-exec-9:null) Service SecurityGroup is not supported in the network 
 id=348
 2013-06-06 06:26:05,176 DEBUG [cloud.api.ApiServlet] (catalina-exec-22:null) 
 ===START===  10.151.133.42 -- GET  
 command=queryAsyncJobResultjobId=79b7efa2-0f7d-4d29-87ae-974921a3df46response=jsonsessionkey=gzAU%2FyMzZz0IoXpemIT8%2Fh4mPVg%3D_=1370460715254
 2013-06-06 06:26:05,183 DEBUG [cloud.vm.UserVmManagerImpl] 
 (catalina-exec-9:null) Allocating in the DB for vm
 2013-06-06 06:26:05,216 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-391:null) Seq 1-1287849575: Response Received:
 2013-06-06 06:26:05,223 DEBUG [agent.transport.Request] 
 (StatsCollector-1:null) Seq 1-1287849575: Received:  { Ans: , MgmtId: 
 7363452993625, via: 1, Ver: v1, Flags: 10, { GetHostStatsAnswer } }
 2013-06-06 06:26:05,240 DEBUG [cloud.api.ApiServlet] (catalina-exec-22:null) 
 ===END===  10.151.133.42 -- GET  
 command=queryAsyncJobResultjobId=79b7efa2-0f7d-4d29-87ae-974921a3df46response=jsonsessionkey=gzAU%2FyMzZz0IoXpemIT8%2Fh4mPVg%3D_=1370460715254
 2013-06-06 06:26:05,242 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (catalina-exec-9:null) Allocating entries for VM: 
 VM[User|76fceaae-f450-4b84-8191-75ddd1242fe8]
 2013-06-06 06:26:05,245 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (catalina-exec-9:null) Allocating nics for 
 VM[User|76fceaae-f450-4b84-8191-75ddd1242fe8]
 2013-06-06 06:26:05,246 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-118:null) Seq 2-654640756: Executing request
 2013-06-06 06:26:05,259 DEBUG [cloud.network.NetworkManagerImpl] 
 (catalina-exec-9:null) Allocating nic for vm 
 VM[User|76fceaae-f450-4b84-8191-75ddd1242fe8] in network Ntwk[348|Guest|8] 
 with requested profile NicProfile[0-0-null-null-null
 2013-06-06 06:26:05,283 DEBUG [cloud.network.NetworkModelImpl] 
 (catalina-exec-9:null) Service SecurityGroup is not supported in the network 
 id=348
 2013-06-06 06:26:05,286 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (catalina-exec-9:null) Allocating disks for 
 VM[User|76fceaae-f450-4b84-8191-75ddd1242fe8]
 2013-06-06 06:26:05,304 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (catalina-exec-9:null) Allocation completed for VM: 
 VM[User|76fceaae-f450-4b84-8191-75ddd1242fe8]
 2013-06-06 06:26:05,305 DEBUG [cloud.vm.UserVmManagerImpl] 
 (catalina-exec-9:null) Successfully allocated DB entry for 
 VM[User|76fceaae-f450-4b84-8191-75ddd1242fe8]
 2013-06-06 06:26:05,350 DEBUG [cloud.network.NetworkModelImpl] 
 (catalina-exec-9:null) Service SecurityGroup is not supported in the network 
 id=348
 2013-06-06 06:26:05,358 DEBUG [cloud.network.NetworkModelImpl] 
 (catalina-exec-9:null) Service SecurityGroup is not supported in the network 
 id=348
 2013-06-06 06:26:05,364 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-232:null) Seq 1-1287849576: Response Received:
 2013-06-06 06:26:05,365 DEBUG [agent.transport.Request] 
 (DirectAgent-232:null) Seq 1-1287849576: Processing:  { Ans: , MgmtId: 
 7363452993625, via: 1, Ver: v1, Flags: 10, 
 [{CheckRouterAnswer:{state:BACKUP,isBumped:false,result:true,details:Status:
  BACKUPBumped: NO,wait:0}}] }
 2013-06-06

[jira] [Resolved] (CLOUDSTACK-2866) [Automation] Unable to start a VM due to concurrent operation

2013-06-06 Thread Devdeep Singh (JIRA)


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

Devdeep Singh resolved CLOUDSTACK-2866.
---

Resolution: Not A Problem

The only way I could reproduce the stack trace given in the bug was.
1. Deploy an instance for an account. The router vm also gets created.
2. Stop the instance.
3. Stop the router vm for the account (only admin can do it) and immediately 
put a request for deploying a vm of the same account. The router vm should 
still be in stopping state while the request for new instance deployment is 
placed.

Since an instance deployment request is placed, ms looks for a router vm of the 
account and if it doesn't find any in running state it tries to start one. 
Since the router vm is actually in stopping state the concurrent exception is 
throw and the stack trace given in the bug gets logged.

However, this doesn't actually fail the vm deployment request. Cloudstack 
retries vm deployment and it goes through next time. So this doesn't cause any 
problem, but an exception does get logged.

Kindly, reopen the bug if it causes vm deployment to fail.

 [Automation]  Unable to start a VM due to concurrent operation
 --

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


 Steps to reproduce:
 1. deploy first VM in an account
 2. try to stope the VM created in step1
 3. stop the DomR
 4. try to deploy another VM in the same account.
  ===START===  10.151.133.42 -- GET  
 command=deployVirtualMachinezoneId=9aaae1c8-294c-41f0-b392-90086e814b53templateId=b4a014e8-ce23-11e2-afec-06b27059hypervisor=XenServerserviceOfferingId=eefcc446-8827-4bb3-b97f-0877ece9223enetworkIds=b98534fc-25b5-4834-9bc4-7c05d8b23ab9response=jsonsessionkey=gzAU%2FyMzZz0IoXpemIT8%2Fh4mPVg%3D_=1370460715197
 2013-06-06 06:26:05,128 DEBUG [cloud.api.ApiDispatcher] 
 (catalina-exec-9:null) InfrastructureEntity name 
 is:com.cloud.offering.ServiceOffering
 2013-06-06 06:26:05,131 DEBUG [cloud.api.ApiDispatcher] 
 (catalina-exec-9:null) ControlledEntity name 
 is:com.cloud.template.VirtualMachineTemplate
 2013-06-06 06:26:05,136 DEBUG [cloud.api.ApiDispatcher] 
 (catalina-exec-9:null) ControlledEntity name is:com.cloud.network.Network
 2013-06-06 06:26:05,160 DEBUG [cloud.network.NetworkModelImpl] 
 (catalina-exec-9:null) Service SecurityGroup is not supported in the network 
 id=348
 2013-06-06 06:26:05,176 DEBUG [cloud.api.ApiServlet] (catalina-exec-22:null) 
 ===START===  10.151.133.42 -- GET  
 command=queryAsyncJobResultjobId=79b7efa2-0f7d-4d29-87ae-974921a3df46response=jsonsessionkey=gzAU%2FyMzZz0IoXpemIT8%2Fh4mPVg%3D_=1370460715254
 2013-06-06 06:26:05,183 DEBUG [cloud.vm.UserVmManagerImpl] 
 (catalina-exec-9:null) Allocating in the DB for vm
 2013-06-06 06:26:05,216 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-391:null) Seq 1-1287849575: Response Received:
 2013-06-06 06:26:05,223 DEBUG [agent.transport.Request] 
 (StatsCollector-1:null) Seq 1-1287849575: Received:  { Ans: , MgmtId: 
 7363452993625, via: 1, Ver: v1, Flags: 10, { GetHostStatsAnswer } }
 2013-06-06 06:26:05,240 DEBUG [cloud.api.ApiServlet] (catalina-exec-22:null) 
 ===END===  10.151.133.42 -- GET  
 command=queryAsyncJobResultjobId=79b7efa2-0f7d-4d29-87ae-974921a3df46response=jsonsessionkey=gzAU%2FyMzZz0IoXpemIT8%2Fh4mPVg%3D_=1370460715254
 2013-06-06 06:26:05,242 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (catalina-exec-9:null) Allocating entries for VM: 
 VM[User|76fceaae-f450-4b84-8191-75ddd1242fe8]
 2013-06-06 06:26:05,245 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (catalina-exec-9:null) Allocating nics for 
 VM[User|76fceaae-f450-4b84-8191-75ddd1242fe8]
 2013-06-06 06:26:05,246 DEBUG [agent.manager.DirectAgentAttache] 
 (DirectAgent-118:null) Seq 2-654640756: Executing request
 2013-06-06 06:26:05,259 DEBUG [cloud.network.NetworkManagerImpl] 
 (catalina-exec-9:null) Allocating nic for vm 
 VM[User|76fceaae-f450-4b84-8191-75ddd1242fe8] in network Ntwk[348|Guest|8] 
 with requested profile NicProfile[0-0-null-null-null
 2013-06-06 06:26:05,283 DEBUG [cloud.network.NetworkModelImpl] 
 (catalina-exec-9:null) Service SecurityGroup is not supported in the network 
 id=348
 2013-06-06 06:26:05,286 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (catalina-exec-9:null) Allocating disks for 
 VM[User|76fceaae-f450-4b84-8191-75ddd1242fe8]
 2013-06-06 06:26:05,304 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (catalina-exec-9:null) Allocation completed

[jira] [Created] (CLOUDSTACK-2875) VM password is not correct after deployment and resetpassword on KVM

Wei Zhou created CLOUDSTACK-2875:


 Summary: VM password is not correct after deployment and 
resetpassword on KVM
 Key: CLOUDSTACK-2875
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2875
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.2.0
 Environment: CentOS 6.4

Reporter: Wei Zhou


After fixed CLOUDSTACK-2823, the systemvms are running finally.

A new issue is that I can not log in the VM (Ubuntu 12.04 64bit) as the 
password is not correct, even after reset password. The IP and hostname are 
correct in VM.

systemvm from 
http://jenkins.cloudstack.org/job/build-systemvm-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvmtemplate-2013-06-04-master-kvm.qcow2.bz2


--
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-2876) QA: Validate UK, Japanese and Chinese Key board support

2013-06-06 Thread Sudha Ponnaganti (JIRA)

Sudha Ponnaganti created CLOUDSTACK-2876:


 Summary: QA: Validate UK, Japanese and Chinese Key board support
 Key: CLOUDSTACK-2876
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2876
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.2.0
Reporter: Sudha Ponnaganti
 Fix For: 4.2.0




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

[jira] [Created] (CLOUDSTACK-2877) Setup development environment

2013-06-06 Thread Ian Duffy (JIRA)

Ian Duffy created CLOUDSTACK-2877:
-

 Summary: Setup development environment
 Key: CLOUDSTACK-2877
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2877
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public (Anyone can view this level - this is the default.)
 Environment: Centos 6.4 and DevCloud
Reporter: Ian Duffy
Assignee: Ian Duffy


Setup Virtualbox.

Install CentOS VM, this will be used as the development environment. Install 
required dev tools and pull down the cloudstack source.

Import devcloud and check that it runs ok.

Build cloudstack on the development environment. Deploy it and check that the 
devcloud is successfully added as a host.

Create another CentOS VM, install and do the required configuration for 
OpenLDAP. Configure cloudstack to use LDAP auth. Test login of LDAP user. 

--
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-2833) Build dev environment with CS lastest code + XCP 1.6


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

tuna updated CLOUDSTACK-2833:
-

Due Date: 6/Jun/13  (was: 9/Jun/13)
 Summary: Build dev environment with CS lastest code + XCP 1.6  (was: 
Deploy CS with Nicira NVP, Midonet Plugin)

 Build dev environment with CS lastest code + XCP 1.6
 

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


 Try to using Nicira NVP, Midonet plugin. Then compare with the native SDN 
 controller. I'll make some document on Wiki.

--
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-2878) Try using native SDN controller with XCP 1.6

tuna created CLOUDSTACK-2878:


 Summary: Try using native SDN controller with XCP 1.6
 Key: CLOUDSTACK-2878
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2878
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: tuna
Assignee: tuna




--
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-2833) Build dev environment with CS lastest code + XCP 1.6


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

tuna resolved CLOUDSTACK-2833.
--

Resolution: Fixed

 Build dev environment with CS lastest code + XCP 1.6
 

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


 Try to using Nicira NVP, Midonet plugin. Then compare with the native SDN 
 controller. I'll make some document on Wiki.

--
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-2879) Try using Nicira NVP plugin

2013-06-06 Thread ASF subversion and git services (JIRA)

tuna created CLOUDSTACK-2879:


 Summary: Try using Nicira NVP plugin
 Key: CLOUDSTACK-2879
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2879
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: tuna
Assignee: tuna




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

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


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

ASF subversion and git services commented on CLOUDSTACK-747:


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

CLOUDSTACK-747: Internal LB detailView - Assigned VMs tab - Assign VMs action - 
fix a bug that select VM view failed to show VMs.


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

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


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

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

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

2013-06-06 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on CLOUDSTACK-747:


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

CLOUDSTACK-747: Internal LB detailView - Assigned VMs tab - add source port, 
instance port to listView.


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

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


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

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

[jira] [Created] (CLOUDSTACK-2880) [UI] Failed to add Vmware Data Center in zone

Rayees Namathponnan created CLOUDSTACK-2880:
---

 Summary: [UI] Failed to add Vmware Data Center in zone 
 Key: CLOUDSTACK-2880
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2880
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.2.0
 Environment: Master 
Hyper visor : VMware
Reporter: Rayees Namathponnan
 Fix For: 4.2.0


Steps to reproduce 

Step1 : Create Advanced zone in vmware
Step 2 : Add add Vmware Data Center in zone 

Actual result 

Failed to add DataCenter to zone, its failed with error 

Unable to execute API command addvmwaredc due to missing parameter vcenter



--
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-2880) [UI] Failed to add Vmware Data Center in zone


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

Rayees Namathponnan commented on CLOUDSTACK-2880:
-

By using below command , i can add DC to Zone 

http://10.223.49.197:8096/?command=addVmwareDcname=SC-CLOUD-QA03zoneId=750344ac-61a7-4c54-abab-784c63871825username=Administratorpassword=Passw0rdvcenter=10.223.240.165url=http%3A%2F%2F10.223.240.165%2FSC-CLOUD-QA03%2Fc2response=json

 [UI] Failed to add Vmware Data Center in zone 
 

 Key: CLOUDSTACK-2880
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2880
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.2.0
 Environment: Master 
 Hyper visor : VMware
Reporter: Rayees Namathponnan
 Fix For: 4.2.0


 Steps to reproduce 
 Step1 : Create Advanced zone in vmware
 Step 2 : Add add Vmware Data Center in zone 
 Actual result 
 Failed to add DataCenter to zone, its failed with error 
 Unable to execute API command addvmwaredc due to missing parameter vcenter

--
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-2880) [UI] Failed to add Vmware Data Center in zone

2013-06-06 Thread ASF subversion and git services (JIRA)


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

Rayees Namathponnan commented on CLOUDSTACK-2880:
-

This is part feature https://issues.apache.org/jira/browse/CLOUDSTACK-2782


 [UI] Failed to add Vmware Data Center in zone 
 

 Key: CLOUDSTACK-2880
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2880
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.2.0
 Environment: Master 
 Hyper visor : VMware
Reporter: Rayees Namathponnan
 Fix For: 4.2.0


 Steps to reproduce 
 Step1 : Create Advanced zone in vmware
 Step 2 : Add add Vmware Data Center in zone 
 Actual result 
 Failed to add DataCenter to zone, its failed with error 
 Unable to execute API command addvmwaredc due to missing parameter vcenter

--
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-2880) [UI] Failed to add Vmware Data Center in zone

2013-06-06 Thread Jessica Wang (JIRA)


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

Jessica Wang reassigned CLOUDSTACK-2880:


Assignee: Jessica Wang

 [UI] Failed to add Vmware Data Center in zone 
 

 Key: CLOUDSTACK-2880
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2880
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.2.0
 Environment: Master 
 Hyper visor : VMware
Reporter: Rayees Namathponnan
Assignee: Jessica Wang
 Fix For: 4.2.0


 Steps to reproduce 
 Step1 : Create Advanced zone in vmware
 Step 2 : Add add Vmware Data Center in zone 
 Actual result 
 Failed to add DataCenter to zone, its failed with error 
 Unable to execute API command addvmwaredc due to missing parameter vcenter

--
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-2880) [UI] Failed to add Vmware Data Center in zone

2013-06-06 Thread Jessica Wang (JIRA)


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

Jessica Wang resolved CLOUDSTACK-2880.
--

Resolution: Fixed

 [UI] Failed to add Vmware Data Center in zone 
 

 Key: CLOUDSTACK-2880
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2880
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.2.0
 Environment: Master 
 Hyper visor : VMware
Reporter: Rayees Namathponnan
Assignee: Jessica Wang
 Fix For: 4.2.0


 Steps to reproduce 
 Step1 : Create Advanced zone in vmware
 Step 2 : Add add Vmware Data Center in zone 
 Actual result 
 Failed to add DataCenter to zone, its failed with error 
 Unable to execute API command addvmwaredc due to missing parameter vcenter

--
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-2880) [UI] Failed to add Vmware Data Center in zone


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

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

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

CLOUDSTACK-2880: UI - zone detail - add VMware DC action - replace URL field 
with vcenter field and make vcenter required.


 [UI] Failed to add Vmware Data Center in zone 
 

 Key: CLOUDSTACK-2880
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2880
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.2.0
 Environment: Master 
 Hyper visor : VMware
Reporter: Rayees Namathponnan
 Fix For: 4.2.0


 Steps to reproduce 
 Step1 : Create Advanced zone in vmware
 Step 2 : Add add Vmware Data Center in zone 
 Actual result 
 Failed to add DataCenter to zone, its failed with error 
 Unable to execute API command addvmwaredc due to missing parameter vcenter

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

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

2013-06-06 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on CLOUDSTACK-747:


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

CLOUDSTACK-747: Internal LB detailView - Assigned VMs tab - Assign VMs action - 
listView will be freshed in widget level after action is done. Therefore, 
remove refresh from application level.


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

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


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

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

[jira] [Created] (CLOUDSTACK-2881) PVLAN - vmware dvswitch - VM stop result in VM

angeline shen created CLOUDSTACK-2881:
-

 Summary: PVLAN - vmware dvswitch - VM stop result in VM
 Key: CLOUDSTACK-2881
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2881
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: angeline shen




--
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-2881) PVLAN - vmware dvswitch - VM stop result in VM remains in Stopping state


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

angeline shen updated CLOUDSTACK-2881:
--

  Component/s: Management Server
Fix Version/s: 4.2.0
 Assignee: Venkata Siva Vijayendra Bhamidipati
 Priority: Critical  (was: Major)
  Description: 
1. zone with two PVLAN networks   
2. deploy VMs in both PVLANs.   
Confirm VMs in same PVLAN cannot connect to each other.
confirm VMs in 1 PVLAN can reach  VMs in  other PVLAN.  VMs can reach 
outside world
3. Stop VMs in both PVLANs.

Result:VMS  remain in Stopping state.
2013-06-06 12:45:05,238 DEBUG [cloud.async.AsyncJobManagerImpl] 
(Job-Executor-23:job-23) Executing 
org.apache.cloudstack.api.command.user.vm.StopVMCmd for job-23
2013-06-06 12:45:05,239 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null) 
===END===  10.216.133.70 -- GET  
command=stopVirtualMachineid=89b5f080-29ee-40b2-9fa4-e844afd2fe81forced=falseresponse=jsonsessionkey=KdfMcbJgtOTr1WGs4CGQD4ckw2c%3D_=1370548159473
2013-06-06 12:45:05,244 DEBUG [cloud.api.ApiDispatcher] 
(Job-Executor-23:job-23) ControlledEntity name is:com.cloud.vm.VirtualMachine
2013-06-06 12:45:05,247 DEBUG [cloud.api.ApiDispatcher] 
(Job-Executor-23:job-23) ControlledEntity name is:com.cloud.uservm.UserVm
2013-06-06 12:45:05,248 DEBUG [cloud.api.ApiDispatcher] 
(Job-Executor-23:job-23) ControlledEntity name 
is:com.cloud.network.router.VirtualRouter
2013-06-06 12:45:05,328 DEBUG [cloud.capacity.CapacityManagerImpl] 
(Job-Executor-23:job-23) VM state transitted from :Running to Stopping with 
event: StopRequestedvm's original host id: 2 new host id: 2 host id before 
state transition: 2
2013-06-06 12:45:05,362 ERROR [cloud.async.AsyncJobManagerImpl] 
(Job-Executor-23:job-23) Unexpected exception while executing 
org.apache.cloudstack.api.command.user.vm.StopVMCmd
java.lang.ClassCastException: 
com.cloud.vm.VMInstanceVO$$EnhancerByCGLIB$$a77eface cannot be cast to 
com.cloud.vm.UserVmVO
at 
com.cloud.vm.UserVmManagerImpl.prepareStop(UserVmManagerImpl.java:4712)
at 
com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1168)
at 
com.cloud.vm.VirtualMachineManagerImpl.stop(VirtualMachineManagerImpl.java:974)
at 
org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.stopvirtualmachine(VMEntityManagerImpl.java:257)
at 
org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.stop(VirtualMachineEntityImpl.java:214)
at 
com.cloud.vm.UserVmManagerImpl.stopVirtualMachine(UserVmManagerImpl.java:3152)
at 
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at 
org.apache.cloudstack.api.command.user.vm.StopVMCmd.execute(StopVMCmd.java:117)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
at 
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
2013-06-06 12:45:05,363 DEBUG [cloud.async.AsyncJobManagerImpl] 
(Job-Executor-23:job-23) Complete async job-23, jobStatus: 2, resultCode: 530, 
result: Error Code: 530 Error text: 
com.cloud.vm.VMInstanceVO$$EnhancerByCGLIB$$a77eface cannot be cast to 
com.cloud.vm.UserVmVO
2013-06-06 12:45:08,264 DEBUG [cloud.api.ApiServlet] (catalina-exec-14:null) 
===START===  10.216.133.70 -- GET  
command=queryAsyncJobResultjobId=d8c6d17e-ffd3-460f-a663-d228df90bcf7response=jsonsessionkey=KdfMcbJgtOTr1WGs4CGQD4ckw2c%3D_=1370548162583
2013-06-06 12:45:08,277 DEBUG [cloud.async.AsyncJobManagerImpl] 
(catalina-exec-14:null) Async job-23 completed
2013-06-06 12:45:08,282 DEBUG [cloud.api.ApiServlet] (catalina-exec-14:null) 
===END===  10.216.133.70 -- GET  comm

  Environment: 
MS   ASF 2.0  build  CloudStack-non-OSS-MASTER-452-rhel6.3.tar.gz
vcenter   ESXi 5.0   hosts
Affects Version/s: 4.2.0
  Summary: PVLAN - vmware dvswitch - VM stop result in VM remains 
in Stopping state  (was: PVLAN - vmware dvswitch - VM stop result in VM)

 PVLAN - vmware dvswitch - VM stop result in VM remains in Stopping state
 

 Key: CLOUDSTACK-2881
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2881
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this

[jira] [Created] (CLOUDSTACK-2882) Test case test_vm_life_cycle.TestVMLifeCycle.test_10_attachAndDetach_iso failing due to wrong mount point in KVM

2013-06-06 Thread ASF subversion and git services (JIRA)

Rayees Namathponnan created CLOUDSTACK-2882:
---

 Summary: Test case 
test_vm_life_cycle.TestVMLifeCycle.test_10_attachAndDetach_iso failing due to 
wrong mount point in KVM
 Key: CLOUDSTACK-2882
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2882
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Affects Versions: 4.2.0
 Environment: Automation - BVT 
Reporter: Rayees Namathponnan
Assignee: Girish Shilamkar
 Fix For: 4.2.0


Test case test_vm_life_cycle.TestVMLifeCycle.test_10_attachAndDetach_iso 
failing due to wrong mount point in KVM

Test case failing with below error

paramiko.transport: INFO: Secsh channel 3 opened.
paramiko.transport: DEBUG: [chan 3] Sesch channel 3 request ok
sshClient: DEBUG: {Cmd: mount -rt iso9660 /dev/xvdd /mnt/tmp via Host: 
10.208.10.22} {returns: ['mount: special device /dev/xvdd does not exist']}


http://jenkins.cloudstack.org/view/cloudstack-qa/job/test-smoke-matrix/389/suite=test_vm_life_cycle/testReport/integration.smoke.test_vm_life_cycle/TestVMLifeCycle/test_10_attachAndDetach_iso/

--
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-2875) VM password is not correct after deployment and resetpassword on KVM


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

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

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

CLOUDSTACK-2875: allow port 8080 on virtual router so that vm can get password 
from virtual router


 VM password is not correct after deployment and resetpassword on KVM
 

 Key: CLOUDSTACK-2875
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2875
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.0
 Environment: CentOS 6.4
Reporter: Wei Zhou

 After fixed CLOUDSTACK-2823, the systemvms are running finally.
 A new issue is that I can not log in the VM (Ubuntu 12.04 64bit) as the 
 password is not correct, even after reset password. The IP and hostname are 
 correct in VM.
 systemvm from 
 http://jenkins.cloudstack.org/job/build-systemvm-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvmtemplate-2013-06-04-master-kvm.qcow2.bz2

--
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-2875) VM password is not correct after deployment and resetpassword on KVM


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

Wei Zhou closed CLOUDSTACK-2875.


Resolution: Fixed
  Assignee: Wei Zhou

 VM password is not correct after deployment and resetpassword on KVM
 

 Key: CLOUDSTACK-2875
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2875
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.2.0
 Environment: CentOS 6.4
Reporter: Wei Zhou
Assignee: Wei Zhou

 After fixed CLOUDSTACK-2823, the systemvms are running finally.
 A new issue is that I can not log in the VM (Ubuntu 12.04 64bit) as the 
 password is not correct, even after reset password. The IP and hostname are 
 correct in VM.
 systemvm from 
 http://jenkins.cloudstack.org/job/build-systemvm-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvmtemplate-2013-06-04-master-kvm.qcow2.bz2

--
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-2881) PVLAN - vmware dvswitch - VM stop result in VM remains in Stopping state


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

Wei Zhou commented on CLOUDSTACK-2881:
--

angeline ,

I think it duplicates CLOUDSTACK-2865 which has been fixed.
Could you test the latest source code?

-Wei

 PVLAN - vmware dvswitch - VM stop result in VM remains in Stopping state
 

 Key: CLOUDSTACK-2881
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2881
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.0
 Environment: MS   ASF 2.0  build  
 CloudStack-non-OSS-MASTER-452-rhel6.3.tar.gz
 vcenter   ESXi 5.0   hosts
Reporter: angeline shen
Assignee: Venkata Siva Vijayendra Bhamidipati
Priority: Critical
 Fix For: 4.2.0

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


 1. zone with two PVLAN networks   
 2. deploy VMs in both PVLANs.   
 Confirm VMs in same PVLAN cannot connect to each other.
 confirm VMs in 1 PVLAN can reach  VMs in  other PVLAN.  VMs can reach 
 outside world
 3. Stop VMs in both PVLANs.
 Result:VMS  remain in Stopping state.
 2013-06-06 12:45:05,238 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-23:job-23) Executing 
 org.apache.cloudstack.api.command.user.vm.StopVMCmd for job-23
 2013-06-06 12:45:05,239 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null) 
 ===END===  10.216.133.70 -- GET  
 command=stopVirtualMachineid=89b5f080-29ee-40b2-9fa4-e844afd2fe81forced=falseresponse=jsonsessionkey=KdfMcbJgtOTr1WGs4CGQD4ckw2c%3D_=1370548159473
 2013-06-06 12:45:05,244 DEBUG [cloud.api.ApiDispatcher] 
 (Job-Executor-23:job-23) ControlledEntity name is:com.cloud.vm.VirtualMachine
 2013-06-06 12:45:05,247 DEBUG [cloud.api.ApiDispatcher] 
 (Job-Executor-23:job-23) ControlledEntity name is:com.cloud.uservm.UserVm
 2013-06-06 12:45:05,248 DEBUG [cloud.api.ApiDispatcher] 
 (Job-Executor-23:job-23) ControlledEntity name 
 is:com.cloud.network.router.VirtualRouter
 2013-06-06 12:45:05,328 DEBUG [cloud.capacity.CapacityManagerImpl] 
 (Job-Executor-23:job-23) VM state transitted from :Running to Stopping with 
 event: StopRequestedvm's original host id: 2 new host id: 2 host id before 
 state transition: 2
 2013-06-06 12:45:05,362 ERROR [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-23:job-23) Unexpected exception while executing 
 org.apache.cloudstack.api.command.user.vm.StopVMCmd
 java.lang.ClassCastException: 
 com.cloud.vm.VMInstanceVO$$EnhancerByCGLIB$$a77eface cannot be cast to 
 com.cloud.vm.UserVmVO
 at 
 com.cloud.vm.UserVmManagerImpl.prepareStop(UserVmManagerImpl.java:4712)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1168)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.stop(VirtualMachineManagerImpl.java:974)
 at 
 org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.stopvirtualmachine(VMEntityManagerImpl.java:257)
 at 
 org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.stop(VirtualMachineEntityImpl.java:214)
 at 
 com.cloud.vm.UserVmManagerImpl.stopVirtualMachine(UserVmManagerImpl.java:3152)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 org.apache.cloudstack.api.command.user.vm.StopVMCmd.execute(StopVMCmd.java:117)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
 at 
 com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at java.lang.Thread.run(Thread.java:679)
 2013-06-06 12:45:05,363 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-23:job-23) Complete async job-23, jobStatus: 2, resultCode: 
 530, result: Error Code: 530 Error text: 
 com.cloud.vm.VMInstanceVO$$EnhancerByCGLIB$$a77eface cannot be cast to 
 com.cloud.vm.UserVmVO
 2013-06-06 12:45:08,264 DEBUG [cloud.api.ApiServlet] (catalina-exec-14:null) 
 ===START===  10.216.133.70 -- GET

[jira] [Closed] (CLOUDSTACK-2865) [Automation]stopVirtualMachine is failing


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

Wei Zhou closed CLOUDSTACK-2865.


Resolution: Fixed
  Assignee: Wei Zhou

 [Automation]stopVirtualMachine is failing 
 --

 Key: CLOUDSTACK-2865
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2865
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.0
Reporter: Srikanteswararao Talluri
Assignee: Wei Zhou
Priority: Blocker
  Labels: automation
 Fix For: 4.2.0


 Steps to reproduce:
 1. Try to stop a virtual machine
  ===START===  10.151.133.42 -- GET  
 command=stopVirtualMachineid=693d7075-e928-4c91-9fca-2ce3331da03aforced=falseresponse=jsonsessionkey=gzAU%2FyMzZz0IoXpemIT8%2Fh4mPVg%3D_=1370460359301
 2013-06-06 06:20:09,248 DEBUG [cloud.api.ApiDispatcher] 
 (catalina-exec-12:null) ControlledEntity name is:com.cloud.vm.VirtualMachine
 2013-06-06 06:20:09,252 DEBUG [cloud.api.ApiDispatcher] 
 (catalina-exec-12:null) ControlledEntity name is:com.cloud.uservm.UserVm
 2013-06-06 06:20:09,254 DEBUG [cloud.api.ApiDispatcher] 
 (catalina-exec-12:null) ControlledEntity name 
 is:com.cloud.network.router.VirtualRouter
 2013-06-06 06:20:09,284 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-75:job-631) Executing 
 org.apache.cloudstack.api.command.user.vm.StopVMCmd for job-631
 2013-06-06 06:20:09,287 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (catalina-exec-12:null) submit async job-631, details: AsyncJobVO {id:631, 
 userId: 2, accountId: 2, sessionKey: null, instanceType: VirtualMachine, 
 instanceId: 189, cmd: org.apache.cloudstack.api.command.user.vm.StopVMCmd, 
 cmdOriginator: null, cmdInfo: 
 {id:693d7075-e928-4c91-9fca-2ce3331da03a,response:json,sessionkey:gzAU/yMzZz0IoXpemIT8/h4mPVg\u003d,ctxUserId:2,httpmethod:GET,_:1370460359301,ctxAccountId:2,ctxStartEventId:2984,forced:false},
  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
 processStatus: 0, resultCode: 0, result: null, initMsid: 7363452993625, 
 completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
 2013-06-06 06:20:09,293 DEBUG [cloud.api.ApiServlet] (catalina-exec-12:null) 
 ===END===  10.151.133.42 -- GET  
 command=stopVirtualMachineid=693d7075-e928-4c91-9fca-2ce3331da03aforced=falseresponse=jsonsessionkey=gzAU%2FyMzZz0IoXpemIT8%2Fh4mPVg%3D_=1370460359301
 2013-06-06 06:20:09,297 DEBUG [cloud.api.ApiDispatcher] 
 (Job-Executor-75:job-631) ControlledEntity name is:com.cloud.vm.VirtualMachine
 2013-06-06 06:20:09,300 DEBUG [cloud.api.ApiDispatcher] 
 (Job-Executor-75:job-631) ControlledEntity name is:com.cloud.uservm.UserVm
 2013-06-06 06:20:09,302 DEBUG [cloud.api.ApiDispatcher] 
 (Job-Executor-75:job-631) ControlledEntity name 
 is:com.cloud.network.router.VirtualRouter
 2013-06-06 06:20:09,352 DEBUG [cloud.capacity.CapacityManagerImpl] 
 (Job-Executor-75:job-631) VM state transitted from :Running to Stopping with 
 event: StopRequestedvm's original host id: 1 new host id: 1 host id before 
 state transition: 1
 2013-06-06 06:20:09,362 ERROR [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-75:job-631) Unexpected exception while executing 
 org.apache.cloudstack.api.command.user.vm.StopVMCmd
 java.lang.ClassCastException: 
 com.cloud.vm.VMInstanceVO$$EnhancerByCGLIB$$b6431cbe cannot be cast to 
 com.cloud.vm.UserVmVO
 at 
 com.cloud.vm.UserVmManagerImpl.prepareStop(UserVmManagerImpl.java:4712)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1168)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.stop(VirtualMachineManagerImpl.java:974)
 at 
 org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.stopvirtualmachine(VMEntityManagerImpl.java:257)
 at 
 org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.stop(VirtualMachineEntityImpl.java:214)
 at 
 com.cloud.vm.UserVmManagerImpl.stopVirtualMachine(UserVmManagerImpl.java:3152)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 org.apache.cloudstack.api.command.user.vm.StopVMCmd.execute(StopVMCmd.java:117)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
 at 
 com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at

[jira] [Created] (CLOUDSTACK-2884) Test case test_service_offerings.py failing automation runs

Rayees Namathponnan created CLOUDSTACK-2884:
---

 Summary: Test case test_service_offerings.py failing automation 
runs 
 Key: CLOUDSTACK-2884
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2884
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Affects Versions: 4.2.0
 Environment: Master - Automation run 
Reporter: Rayees Namathponnan
Assignee: Girish Shilamkar
 Fix For: 4.2.0


Test case cloudstack/test/integration/smoke/test_service_offerings.py, line 
437, in test_04_change_offering_small  failing with below error 


  File /usr/local/lib/python2.7/unittest/case.py, line 318, in run
testMethod()
  File 
/Repo_30X/ipcl/cloudstack/test/integration/smoke/test_service_offerings.py, 
line 437, in test_04_change_offering_small
Check Memory(kb) for small offering
  File /usr/local/lib/python2.7/unittest/case.py, line 535, in 
assertAlmostEqual
if round(abs(second-first), places) == 0:
'str' object cannot be interpreted as an index



--
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-2884) Test case test_service_offerings.py:test_04_change_offering_small failing automation runs


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

Rayees Namathponnan updated CLOUDSTACK-2884:


Summary: Test case 
test_service_offerings.py:test_04_change_offering_small failing automation 
runs   (was: Test case test_service_offerings.py failing automation runs )

 Test case test_service_offerings.py:test_04_change_offering_small failing 
 automation runs 
 

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


 Test case cloudstack/test/integration/smoke/test_service_offerings.py, line 
 437, in test_04_change_offering_small  failing with below error 
   File /usr/local/lib/python2.7/unittest/case.py, line 318, in run
 testMethod()
   File 
 /Repo_30X/ipcl/cloudstack/test/integration/smoke/test_service_offerings.py, 
 line 437, in test_04_change_offering_small
 Check Memory(kb) for small offering
   File /usr/local/lib/python2.7/unittest/case.py, line 535, in 
 assertAlmostEqual
 if round(abs(second-first), places) == 0:
 'str' object cannot be interpreted as an index

--
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-2885) API listVirtualMachines - listvirtualmachinesresponse should include cpunumber and cpuspeed

2013-06-06 Thread ASF subversion and git services (JIRA)

angeline shen created CLOUDSTACK-2885:
-

 Summary: API  listVirtualMachines -  listvirtualmachinesresponse 
should include cpunumber  and cpuspeed 
 Key: CLOUDSTACK-2885
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2885
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: API
Affects Versions: 4.2.0
 Environment: MSASF 4.2build  
CloudStack-non-OSS-MASTER-452-rhel6.3.tar.gz
vmware   ESXi 5.0 hosts
Reporter: angeline shen
Priority: Critical
 Fix For: 4.2.0


1. advance zone with PVLAN setup.   add  hosts
2. deploy VMs.   
   UI:   select VMs  statistics 
Result:   Total CPU   shows  undefined x

API response does NOT include cpunumber  and cpuspeed 
  

API call:
http://10.223.50.3:8080/client/api?command=listVirtualMachinesdetails=statsid=648103d4-b3d8-401b-aaeb-5d6fdf75fbc7response=jsonsessionkey=RV1iRzQ3pg636vVZIwdbrJlAJXU%3D_=1370557934692


API response:
{ listvirtualmachinesresponse : { count:1 ,virtualmachine : [  
{id:648103d4-b3d8-401b-aaeb-5d6fdf75fbc7,name:vm1612V81,displayname:vm1612V81,account:admin,domainid:ec9a7ec4-ce3c-11e2-add9-f923bf56723a,domain:ROOT,created:2013-06-05T18:24:42-0700,state:Stopping,haenable:true,zoneid:e3158d1a-7f1b-4675-a2b6-e5fcaaf66c66,zonename:z1,zonetype:Advanced,hostid:1836a0d4-af1a-4ea2-9ccb-6e203b088b4c,hostname:10.223.81.40,cpuused:45%,networkkbsread:0,networkkbswrite:0,diskkbsread:0,diskkbswrite:0,diskioread:0,diskiowrite:0,guestosid:ed3b4142-ce3c-11e2-add9-f923bf56723a,securitygroup:[],nic:[],hypervisor:VMware,instancename:i-2-8-VM,tags:[],affinitygroup:[],displayvm:true}
 ] } }




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

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


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

ASF subversion and git services commented on CLOUDSTACK-747:


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

CLOUDSTACK-747: Internal LB detailView - Assigned VMs tab - Assign VMs action - 
Select VM view - refresh assignedVMs data by API call when popping up Select VM 
view.


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

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


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

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

[jira] [Created] (CLOUDSTACK-2886) PVLAN - vmware dvswitch - migrate VM to another primary storage fail

angeline shen created CLOUDSTACK-2886:
-

 Summary: PVLAN - vmware dvswitch - migrate VM to another primary 
storage fail
 Key: CLOUDSTACK-2886
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2886
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.2.0
 Environment: MS   ASF 2.0  build  
CloudStack-non-OSS-MASTER-452-rhel6.3.tar.gz
vcenter   ESXi 5.0   hosts
Reporter: angeline shen
Assignee: Venkata Siva Vijayendra Bhamidipati
Priority: Critical
 Fix For: 4.2.0


1. zone with two PVLAN networks   
2. deploy VMs in both PVLANs.   
Confirm VMs in same PVLAN cannot connect to each other.
confirm VMs in 1 PVLAN can reach  VMs in  other PVLAN.  VMs can reach 
outside world
3. Stop VMs in both PVLANs.
VM  migrate instance to another primary storage fail:

2013-06-06 16:11:53,579 DEBUG [cloud.api.ApiServlet] (catalina-exec-18:null) 
===START===  10.216.133.70 -- GET  
command=migrateVirtualMachinestorageid=a8e01df5-f763-3bd9-8f7c-5f40751e8397virtualmachineid=4eba5aeb-9309-4
9a7-be50-e31d8c5a9af7response=jsonsessionkey=RV1iRzQ3pg636vVZIwdbrJlAJXU%3D_=1370560567954
2013-06-06 16:11:53,644 DEBUG [cloud.async.AsyncJobManagerImpl] 
(catalina-exec-18:null) submit async job-36, details: AsyncJobVO {id:36, 
userId: 2, accountId: 2, sessionKey: null, instanceType: None, instanceId: 
null, cmd
: org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdOriginator: null, 
cmdInfo: 
{response:json,sessionkey:RV1iRzQ3pg636vVZIwdbrJlAJXU\u003d,virtualmachineid:4eba5aeb-9309-49a7-be50-e31d8c5a9af7,ctxUs
erId:2,storageid:a8e01df5-f763-3bd9-8f7c-5f40751e8397,httpmethod:GET,_:1370560567954,ctxAccountId:2,ctxStartEventId:138},
 cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, processSta
tus: 0, resultCode: 0, result: null, initMsid: 206915885077197, completeMsid: 
null, lastUpdated: null, lastPolled: null, created: null}
2013-06-06 16:11:53,646 DEBUG [cloud.async.AsyncJobManagerImpl] 
(Job-Executor-37:job-36) Executing 
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd for job-36
2013-06-06 16:11:53,647 DEBUG [cloud.api.ApiServlet] (catalina-exec-18:null) 
===END===  10.216.133.70 -- GET  
command=migrateVirtualMachinestorageid=a8e01df5-f763-3bd9-8f7c-5f40751e8397virtualmachineid=4eba5aeb-9309-49a
7-be50-e31d8c5a9af7response=jsonsessionkey=RV1iRzQ3pg636vVZIwdbrJlAJXU%3D_=1370560567954
2013-06-06 16:11:53,662 ERROR [cloud.async.AsyncJobManagerImpl] 
(Job-Executor-37:job-36) Unexpected exception while executing 
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd
java.lang.NullPointerException
at 
com.cloud.vm.UserVmManagerImpl.vmStorageMigration(UserVmManagerImpl.java:3782)
at 
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd.execute(MigrateVMCmd.java:149)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
at 
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
2013-06-06 16:11:53,666 DEBUG [cloud.async.AsyncJobManagerImpl] 
(Job-Executor-37:job-36) Complete async job-36, jobStatus: 2, resultCode: 530, 
result: Error Code: 530 Error text: null
2013-06-06 16:11:56,678 DEBUG [cloud.api.ApiServlet] (catalina-exec-15:null) 
===START===  10.216.133.70 -- GET  
command=queryAsyncJobResultjobId=829d4796-a852-4677-a2ca-f42c9ff431e6response=jsonsessionkey=RV1iRzQ3pg636
vVZIwdbrJlAJXU%3D_=1370560571051
2013-06-06 16:11:56,688 DEBUG [cloud.async.AsyncJobManagerImpl] 
(catalina-exec-15:null) Async job-36 completed
2013-06-06 16:11:56,692 DEBUG [cloud.api.ApiServlet] (catalina-exec-15:null) 
===END===  10.216.133.70 -- GET  
command=queryAsyncJobResultjobId=829d4796-a852-4677-a2ca-f42c9ff431e6response=jsonsessionkey=RV1iRzQ3pg636vV
ZIwdbrJlAJXU%3D_=1370560571051
2013-06-06 16:12:04,204 DEBUG [cloud.server.StatsCollector] 
(StatsCollector-1:null) StorageCollector is running...
2013-06-06 16:12:04,281 DEBUG [agent.transport.Request] (StatsCollector-1:




--
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-2886) PVLAN - vmware dvswitch - migrate VM to another primary storage fail


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

angeline shen updated CLOUDSTACK-2886:
--

Attachment: management-server.log.gz
Screenshot-CloudStack - Mozilla Firefox-6.png

 PVLAN - vmware dvswitch - migrate VM to another primary storage fail
 

 Key: CLOUDSTACK-2886
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2886
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.0
 Environment: MS   ASF 2.0  build  
 CloudStack-non-OSS-MASTER-452-rhel6.3.tar.gz
 vcenter   ESXi 5.0   hosts
Reporter: angeline shen
Assignee: Venkata Siva Vijayendra Bhamidipati
Priority: Critical
 Fix For: 4.2.0

 Attachments: management-server.log.gz, Screenshot-CloudStack - 
 Mozilla Firefox-6.png


 1. zone with two PVLAN networks   
 2. deploy VMs in both PVLANs.   
 Confirm VMs in same PVLAN cannot connect to each other.
 confirm VMs in 1 PVLAN can reach  VMs in  other PVLAN.  VMs can reach 
 outside world
 3. Stop VMs in both PVLANs.
 VM  migrate instance to another primary storage fail:
 2013-06-06 16:11:53,579 DEBUG [cloud.api.ApiServlet] (catalina-exec-18:null) 
 ===START===  10.216.133.70 -- GET  
 command=migrateVirtualMachinestorageid=a8e01df5-f763-3bd9-8f7c-5f40751e8397virtualmachineid=4eba5aeb-9309-4
 9a7-be50-e31d8c5a9af7response=jsonsessionkey=RV1iRzQ3pg636vVZIwdbrJlAJXU%3D_=1370560567954
 2013-06-06 16:11:53,644 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (catalina-exec-18:null) submit async job-36, details: AsyncJobVO {id:36, 
 userId: 2, accountId: 2, sessionKey: null, instanceType: None, instanceId: 
 null, cmd
 : org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdOriginator: 
 null, cmdInfo: 
 {response:json,sessionkey:RV1iRzQ3pg636vVZIwdbrJlAJXU\u003d,virtualmachineid:4eba5aeb-9309-49a7-be50-e31d8c5a9af7,ctxUs
 erId:2,storageid:a8e01df5-f763-3bd9-8f7c-5f40751e8397,httpmethod:GET,_:1370560567954,ctxAccountId:2,ctxStartEventId:138},
  cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, processSta
 tus: 0, resultCode: 0, result: null, initMsid: 206915885077197, completeMsid: 
 null, lastUpdated: null, lastPolled: null, created: null}
 2013-06-06 16:11:53,646 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-37:job-36) Executing 
 org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd for job-36
 2013-06-06 16:11:53,647 DEBUG [cloud.api.ApiServlet] (catalina-exec-18:null) 
 ===END===  10.216.133.70 -- GET  
 command=migrateVirtualMachinestorageid=a8e01df5-f763-3bd9-8f7c-5f40751e8397virtualmachineid=4eba5aeb-9309-49a
 7-be50-e31d8c5a9af7response=jsonsessionkey=RV1iRzQ3pg636vVZIwdbrJlAJXU%3D_=1370560567954
 2013-06-06 16:11:53,662 ERROR [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-37:job-36) Unexpected exception while executing 
 org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd
 java.lang.NullPointerException
 at 
 com.cloud.vm.UserVmManagerImpl.vmStorageMigration(UserVmManagerImpl.java:3782)
 at 
 org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd.execute(MigrateVMCmd.java:149)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
 at 
 com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 at java.lang.Thread.run(Thread.java:679)
 2013-06-06 16:11:53,666 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-37:job-36) Complete async job-36, jobStatus: 2, resultCode: 
 530, result: Error Code: 530 Error text: null
 2013-06-06 16:11:56,678 DEBUG [cloud.api.ApiServlet] (catalina-exec-15:null) 
 ===START===  10.216.133.70 -- GET  
 command=queryAsyncJobResultjobId=829d4796-a852-4677-a2ca-f42c9ff431e6response=jsonsessionkey=RV1iRzQ3pg636
 vVZIwdbrJlAJXU%3D_=1370560571051
 2013-06-06 16:11:56,688 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (catalina-exec-15:null) Async job-36 completed
 2013-06-06 16:11:56,692 DEBUG [cloud.api.ApiServlet] (catalina-exec-15:null) 
 ===END===  10.216.133.70 -- GET  
 command=queryAsyncJobResultjobId=829d4796-a852-4677-a2ca-f42c9ff431e6response=jsonsessionkey=RV1iRzQ3pg636vV
 ZIwdbrJlAJXU%3D_=1370560571051
 2013-06-06 16:12:04,204 DEBUG [cloud.server.StatsCollector]

[jira] [Created] (CLOUDSTACK-2887) PVLAN - vmware dvswitch - destroy VM fail with VM stuck in 'Stopping' state

angeline shen created CLOUDSTACK-2887:
-

 Summary: PVLAN - vmware dvswitch -  destroy VM fail with VM stuck 
in 'Stopping' state
 Key: CLOUDSTACK-2887
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2887
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.2.0
 Environment: MS ASF 2.0 build 
CloudStack-non-OSS-MASTER-452-rhel6.3.tar.gz
vcenter ESXi 5.0 hosts 
Reporter: angeline shen
Assignee: Venkata Siva Vijayendra Bhamidipati
Priority: Critical
 Fix For: 4.2.0


1. zone with two PVLAN networks
2. deploy VMs in both PVLANs.
Confirm VMs in same PVLAN cannot connect to each other.
confirm VMs in 1 PVLAN can reach VMs in other PVLAN. VMs can reach outside 
world
3. Destroy VMs in both PVLANs.

Result:VMS remain in Stopping state. 

2013-06-06 15:46:57,467 DEBUG [cloud.api.ApiServlet] (catalina-exec-10:null) 
===START===  10.216.133.70 -- GET  
command=destroyVirtualMachineid=c27541d9-f4d2-40fc-8fab-3edfadc4067eresponse=jsonsessionkey=RV1iRzQ3pg636vVZIwdb
rJlAJXU%3D_=1370559071830
2013-06-06 15:46:57,575 DEBUG [cloud.async.AsyncJobManagerImpl] 
(catalina-exec-10:null) submit async job-34, details: AsyncJobVO {id:34, 
userId: 2, accountId: 2, sessionKey: null, instanceType: VirtualMachine, 
instanceId: 12, c
md: org.apache.cloudstack.api.command.user.vm.DestroyVMCmd, cmdOriginator: 
null, cmdInfo: 
{response:json,id:c27541d9-f4d2-40fc-8fab-3edfadc4067e,sessionkey:RV1iRzQ3pg636vVZIwdbrJlAJXU\u003d,ctxUserId:2,httpmeth
od:GET,_:1370559071830,ctxAccountId:2,ctxStartEventId:132}, 
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
processStatus: 0, resultCode: 0, result: null, initMsid: 206915885077197, 
completeMsid
: null, lastUpdated: null, lastPolled: null, created: null}
2013-06-06 15:46:57,577 DEBUG [cloud.async.AsyncJobManagerImpl] 
(Job-Executor-34:job-34) Executing 
org.apache.cloudstack.api.command.user.vm.DestroyVMCmd for job-34
2013-06-06 15:46:57,578 DEBUG [cloud.api.ApiServlet] (catalina-exec-10:null) 
===END===  10.216.133.70 -- GET  
command=destroyVirtualMachineid=c27541d9-f4d2-40fc-8fab-3edfadc4067eresponse=jsonsessionkey=RV1iRzQ3pg636vVZIwdbrJlAJXU%3D_=1370559071830
2013-06-06 15:46:57,630 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
(Job-Executor-34:job-34) Destroying vm VM[User|vm1612V61]
2013-06-06 15:46:57,667 DEBUG [cloud.capacity.CapacityManagerImpl] 
(Job-Executor-34:job-34) VM state transitted from :Running to Stopping with 
event: StopRequestedvm's original host id: 1 new host id: 2 host id before 
state transition: 2
2013-06-06 15:46:57,702 ERROR [cloud.async.AsyncJobManagerImpl] 
(Job-Executor-34:job-34) Unexpected exception while executing 
org.apache.cloudstack.api.command.user.vm.DestroyVMCmd
java.lang.ClassCastException: 
com.cloud.vm.VMInstanceVO$$EnhancerByCGLIB$$a77eface cannot be cast to 
com.cloud.vm.UserVmVO
at 
com.cloud.vm.UserVmManagerImpl.prepareStop(UserVmManagerImpl.java:4712)
at 
com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1168)
at 
com.cloud.vm.VirtualMachineManagerImpl.destroy(VirtualMachineManagerImpl.java:1285)
at 
org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.destroyVirtualMachine(VMEntityManagerImpl.java:265)
at 
org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.destroy(VirtualMachineEntityImpl.java:225)
at com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:3385)
at com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:1898)
at 
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at 
org.apache.cloudstack.api.command.user.vm.DestroyVMCmd.execute(DestroyVMCmd.java:100)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
at 
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
2013-06-06 15:46:57,703 DEBUG [cloud.async.AsyncJobManagerImpl] 
(Job-Executor-34:job-34) Complete async job-34, jobStatus: 2, resultCode: 530, 
result: Error Code: 530 Error text: 
com.cloud.vm.VMInstanceVO$$EnhancerByCGLIB$$a77eface cannot be cast to 
com.cloud.vm.UserVmVO
2013-06-06 15:47:00,621 DEBUG

[jira] [Updated] (CLOUDSTACK-2887) PVLAN - vmware dvswitch - destroy VM fail with VM stuck in 'Stopping' state


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

angeline shen updated CLOUDSTACK-2887:
--

Attachment: management-server.log.gz

 PVLAN - vmware dvswitch -  destroy VM fail with VM stuck in 'Stopping' state
 

 Key: CLOUDSTACK-2887
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2887
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.0
 Environment: MS ASF 2.0 build 
 CloudStack-non-OSS-MASTER-452-rhel6.3.tar.gz
 vcenter ESXi 5.0 hosts 
Reporter: angeline shen
Assignee: Venkata Siva Vijayendra Bhamidipati
Priority: Critical
 Fix For: 4.2.0

 Attachments: management-server.log.gz


 1. zone with two PVLAN networks
 2. deploy VMs in both PVLANs.
 Confirm VMs in same PVLAN cannot connect to each other.
 confirm VMs in 1 PVLAN can reach VMs in other PVLAN. VMs can reach 
 outside world
 3. Destroy VMs in both PVLANs.
 Result:VMS remain in Stopping state. 
 2013-06-06 15:46:57,467 DEBUG [cloud.api.ApiServlet] (catalina-exec-10:null) 
 ===START===  10.216.133.70 -- GET  
 command=destroyVirtualMachineid=c27541d9-f4d2-40fc-8fab-3edfadc4067eresponse=jsonsessionkey=RV1iRzQ3pg636vVZIwdb
 rJlAJXU%3D_=1370559071830
 2013-06-06 15:46:57,575 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (catalina-exec-10:null) submit async job-34, details: AsyncJobVO {id:34, 
 userId: 2, accountId: 2, sessionKey: null, instanceType: VirtualMachine, 
 instanceId: 12, c
 md: org.apache.cloudstack.api.command.user.vm.DestroyVMCmd, cmdOriginator: 
 null, cmdInfo: 
 {response:json,id:c27541d9-f4d2-40fc-8fab-3edfadc4067e,sessionkey:RV1iRzQ3pg636vVZIwdbrJlAJXU\u003d,ctxUserId:2,httpmeth
 od:GET,_:1370559071830,ctxAccountId:2,ctxStartEventId:132}, 
 cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
 processStatus: 0, resultCode: 0, result: null, initMsid: 206915885077197, 
 completeMsid
 : null, lastUpdated: null, lastPolled: null, created: null}
 2013-06-06 15:46:57,577 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-34:job-34) Executing 
 org.apache.cloudstack.api.command.user.vm.DestroyVMCmd for job-34
 2013-06-06 15:46:57,578 DEBUG [cloud.api.ApiServlet] (catalina-exec-10:null) 
 ===END===  10.216.133.70 -- GET  
 command=destroyVirtualMachineid=c27541d9-f4d2-40fc-8fab-3edfadc4067eresponse=jsonsessionkey=RV1iRzQ3pg636vVZIwdbrJlAJXU%3D_=1370559071830
 2013-06-06 15:46:57,630 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (Job-Executor-34:job-34) Destroying vm VM[User|vm1612V61]
 2013-06-06 15:46:57,667 DEBUG [cloud.capacity.CapacityManagerImpl] 
 (Job-Executor-34:job-34) VM state transitted from :Running to Stopping with 
 event: StopRequestedvm's original host id: 1 new host id: 2 host id before 
 state transition: 2
 2013-06-06 15:46:57,702 ERROR [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-34:job-34) Unexpected exception while executing 
 org.apache.cloudstack.api.command.user.vm.DestroyVMCmd
 java.lang.ClassCastException: 
 com.cloud.vm.VMInstanceVO$$EnhancerByCGLIB$$a77eface cannot be cast to 
 com.cloud.vm.UserVmVO
 at 
 com.cloud.vm.UserVmManagerImpl.prepareStop(UserVmManagerImpl.java:4712)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1168)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.destroy(VirtualMachineManagerImpl.java:1285)
 at 
 org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.destroyVirtualMachine(VMEntityManagerImpl.java:265)
 at 
 org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.destroy(VirtualMachineEntityImpl.java:225)
 at 
 com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:3385)
 at 
 com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:1898)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 org.apache.cloudstack.api.command.user.vm.DestroyVMCmd.execute(DestroyVMCmd.java:100)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
 at 
 com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)

[jira] [Assigned] (CLOUDSTACK-2233) Automation: Add Remove network on a VM

2013-06-06 Thread Shane Witbeck (JIRA)


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

Shane Witbeck reassigned CLOUDSTACK-2233:
-

Assignee: Shane Witbeck

 Automation: Add Remove network on a VM
 --

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




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

[jira] [Updated] (CLOUDSTACK-2887) PVLAN - vmware dvswitch - destroy VM fail with VM stuck in 'Stopping' state


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

angeline shen updated CLOUDSTACK-2887:
--

Description: 

1. zone with two PVLAN networks
2. deploy VMs in both PVLANs.
Confirm VMs in same PVLAN cannot connect to each other.
confirm VMs in 1 PVLAN can reach VMs in other PVLAN. VMs can reach outside 
world
3. Destroy VMs in both PVLANs.

Result:VMS remain in Stopping state. 

2013-06-06 15:46:57,467 DEBUG [cloud.api.ApiServlet] (catalina-exec-10:null) 
===START===  10.216.133.70 -- GET  
command=destroyVirtualMachineid=c27541d9-f4d2-40fc-8fab-3edfadc4067eresponse=jsonsessionkey=RV1iRzQ3pg636vVZIwdb
rJlAJXU%3D_=1370559071830
2013-06-06 15:46:57,575 DEBUG [cloud.async.AsyncJobManagerImpl] 
(catalina-exec-10:null) submit async job-34, details: AsyncJobVO {id:34, 
userId: 2, accountId: 2, sessionKey: null, instanceType: VirtualMachine, 
instanceId: 12, c
md: org.apache.cloudstack.api.command.user.vm.DestroyVMCmd, cmdOriginator: 
null, cmdInfo: 
{response:json,id:c27541d9-f4d2-40fc-8fab-3edfadc4067e,sessionkey:RV1iRzQ3pg636vVZIwdbrJlAJXU\u003d,ctxUserId:2,httpmeth
od:GET,_:1370559071830,ctxAccountId:2,ctxStartEventId:132}, 
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
processStatus: 0, resultCode: 0, result: null, initMsid: 206915885077197, 
completeMsid
: null, lastUpdated: null, lastPolled: null, created: null}
2013-06-06 15:46:57,577 DEBUG [cloud.async.AsyncJobManagerImpl] 
(Job-Executor-34:job-34) Executing 
org.apache.cloudstack.api.command.user.vm.DestroyVMCmd for job-34
2013-06-06 15:46:57,578 DEBUG [cloud.api.ApiServlet] (catalina-exec-10:null) 
===END===  10.216.133.70 -- GET  
command=destroyVirtualMachineid=c27541d9-f4d2-40fc-8fab-3edfadc4067eresponse=jsonsessionkey=RV1iRzQ3pg636vVZIwdbrJlAJXU%3D_=1370559071830
2013-06-06 15:46:57,630 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
(Job-Executor-34:job-34) Destroying vm VM[User|vm1612V61]
2013-06-06 15:46:57,667 DEBUG [cloud.capacity.CapacityManagerImpl] 
(Job-Executor-34:job-34) VM state transitted from :Running to Stopping with 
event: StopRequestedvm's original host id: 1 new host id: 2 host id before 
state transition: 2
2013-06-06 15:46:57,702 ERROR [cloud.async.AsyncJobManagerImpl] 
(Job-Executor-34:job-34) Unexpected exception while executing 
org.apache.cloudstack.api.command.user.vm.DestroyVMCmd
java.lang.ClassCastException: 
com.cloud.vm.VMInstanceVO$$EnhancerByCGLIB$$a77eface cannot be cast to 
com.cloud.vm.UserVmVO
at 
com.cloud.vm.UserVmManagerImpl.prepareStop(UserVmManagerImpl.java:4712)
at 
com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1168)
at 
com.cloud.vm.VirtualMachineManagerImpl.destroy(VirtualMachineManagerImpl.java:1285)
at 
org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.destroyVirtualMachine(VMEntityManagerImpl.java:265)
at 
org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.destroy(VirtualMachineEntityImpl.java:225)
at com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:3385)
at com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:1898)
at 
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at 
org.apache.cloudstack.api.command.user.vm.DestroyVMCmd.execute(DestroyVMCmd.java:100)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
at 
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
2013-06-06 15:46:57,703 DEBUG [cloud.async.AsyncJobManagerImpl] 
(Job-Executor-34:job-34) Complete async job-34, jobStatus: 2, resultCode: 530, 
result: Error Code: 530 Error text: 
com.cloud.vm.VMInstanceVO$$EnhancerByCGLIB$$a77eface cannot be cast to 
com.cloud.vm.UserVmVO
2013-06-06 15:47:00,621 DEBUG [cloud.api.ApiServlet] (catalina-exec-20:null) 
===START===  10.216.133.70 -- GET  
command=queryAsyncJobResultjobId=f8a46980-8409-4ead-a209-a799e202f959response=jsonsessionkey=RV1iRzQ3pg636vVZIwdbrJlAJXU%3D_=1370559074987
2013-06-06 15:47:00,632 DEBUG [cloud.async.AsyncJobManagerImpl] 
(catalina-exec-20:null) Async job-34 completed
2013-06-06 15:47:00,636 DEBUG [cloud.api.ApiServlet] (catalina-exec-20:null) 
===END===  10.216.133.70 -- GET

[jira] [Updated] (CLOUDSTACK-2887) PVLAN - vmware dvswitch - destroy VM fail with VM stuck in 'Stopping' state

2013-06-06 Thread ASF subversion and git services (JIRA)


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

angeline shen updated CLOUDSTACK-2887:
--

Attachment: Screenshot-CloudStack - Mozilla Firefox-7.png
management-server.log.gz

 PVLAN - vmware dvswitch -  destroy VM fail with VM stuck in 'Stopping' state
 

 Key: CLOUDSTACK-2887
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2887
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.0
 Environment: MS ASF 2.0 build 
 CloudStack-non-OSS-MASTER-452-rhel6.3.tar.gz
 vcenter ESXi 5.0 hosts 
Reporter: angeline shen
Assignee: Venkata Siva Vijayendra Bhamidipati
Priority: Critical
 Fix For: 4.2.0

 Attachments: management-server.log.gz, management-server.log.gz, 
 Screenshot-CloudStack - Mozilla Firefox-7.png


 1. zone with two PVLAN networks
 2. deploy VMs in both PVLANs.
 Confirm VMs in same PVLAN cannot connect to each other.
 confirm VMs in 1 PVLAN can reach VMs in other PVLAN. VMs can reach 
 outside world
 3. Destroy VMs in both PVLANs.
 Result:VMS remain in Stopping state. 
 2013-06-06 15:46:57,467 DEBUG [cloud.api.ApiServlet] (catalina-exec-10:null) 
 ===START===  10.216.133.70 -- GET  
 command=destroyVirtualMachineid=c27541d9-f4d2-40fc-8fab-3edfadc4067eresponse=jsonsessionkey=RV1iRzQ3pg636vVZIwdb
 rJlAJXU%3D_=1370559071830
 2013-06-06 15:46:57,575 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (catalina-exec-10:null) submit async job-34, details: AsyncJobVO {id:34, 
 userId: 2, accountId: 2, sessionKey: null, instanceType: VirtualMachine, 
 instanceId: 12, c
 md: org.apache.cloudstack.api.command.user.vm.DestroyVMCmd, cmdOriginator: 
 null, cmdInfo: 
 {response:json,id:c27541d9-f4d2-40fc-8fab-3edfadc4067e,sessionkey:RV1iRzQ3pg636vVZIwdbrJlAJXU\u003d,ctxUserId:2,httpmeth
 od:GET,_:1370559071830,ctxAccountId:2,ctxStartEventId:132}, 
 cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0, 
 processStatus: 0, resultCode: 0, result: null, initMsid: 206915885077197, 
 completeMsid
 : null, lastUpdated: null, lastPolled: null, created: null}
 2013-06-06 15:46:57,577 DEBUG [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-34:job-34) Executing 
 org.apache.cloudstack.api.command.user.vm.DestroyVMCmd for job-34
 2013-06-06 15:46:57,578 DEBUG [cloud.api.ApiServlet] (catalina-exec-10:null) 
 ===END===  10.216.133.70 -- GET  
 command=destroyVirtualMachineid=c27541d9-f4d2-40fc-8fab-3edfadc4067eresponse=jsonsessionkey=RV1iRzQ3pg636vVZIwdbrJlAJXU%3D_=1370559071830
 2013-06-06 15:46:57,630 DEBUG [cloud.vm.VirtualMachineManagerImpl] 
 (Job-Executor-34:job-34) Destroying vm VM[User|vm1612V61]
 2013-06-06 15:46:57,667 DEBUG [cloud.capacity.CapacityManagerImpl] 
 (Job-Executor-34:job-34) VM state transitted from :Running to Stopping with 
 event: StopRequestedvm's original host id: 1 new host id: 2 host id before 
 state transition: 2
 2013-06-06 15:46:57,702 ERROR [cloud.async.AsyncJobManagerImpl] 
 (Job-Executor-34:job-34) Unexpected exception while executing 
 org.apache.cloudstack.api.command.user.vm.DestroyVMCmd
 java.lang.ClassCastException: 
 com.cloud.vm.VMInstanceVO$$EnhancerByCGLIB$$a77eface cannot be cast to 
 com.cloud.vm.UserVmVO
 at 
 com.cloud.vm.UserVmManagerImpl.prepareStop(UserVmManagerImpl.java:4712)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1168)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.destroy(VirtualMachineManagerImpl.java:1285)
 at 
 org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.destroyVirtualMachine(VMEntityManagerImpl.java:265)
 at 
 org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.destroy(VirtualMachineEntityImpl.java:225)
 at 
 com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:3385)
 at 
 com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:1898)
 at 
 com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at 
 org.apache.cloudstack.api.command.user.vm.DestroyVMCmd.execute(DestroyVMCmd.java:100)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
 at 
 com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at

[jira] [Commented] (CLOUDSTACK-1771) IPv6 - Network restart for a dual network , results in the ipv4 address of the router to be changed. After netwpork restart , name resolution of the Vms fail.

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

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

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

CLOUDSTACK-1771: Fix ipv6 address for router

Now it won't change(as ipv4 address) after router is destroyed.

IPv6 - Network restart for a dual network , results in the ipv4 address of
the router to be changed. After netwpork restart , name resolution of the Vms
fail.
---

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

IPv6 - Network restart for a dual network , results in the ipv4 address of
the router to be changed. After netwpork restart , name resolution of the Vms
fail
Steps to reproduce the problem:
Pre Req:
1.Create Dual Stack Shared Network by passing ipv6 params and ipv4 params
2. Deploy few Vms in this network.
Steps:
1. Restart Network.
Expected Behavior:
After network restart , we should be able to access all the Vms within the
network using its name.
Actual Result:
After network restart , we are not able to access all the Vms within the
network using its name.
This is because of the ipv4 address of the router being changed after
network restart.
Router had ip address - 10.223.136.69
After reboot , Router now has ip address - 10.223.136.69
But the guest Vms still point to the routers old ipaddress - 10.223.136.69
for providing name resolution.
sangeetha@test123:~$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.223.136.69
nameserver 72.52.126.11
nameserver 72.52.126.12
search hello1361

[jira] [Resolved] (CLOUDSTACK-1771) IPv6 - Network restart for a dual network , results in the ipv4 address of the router to be changed. After netwpork restart , name resolution of the Vms fail.

2013-06-06 Thread Sheng Yang (JIRA)

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

Sheng Yang resolved CLOUDSTACK-1771.

Resolution: Fixed

IPv6 - Network restart for a dual network , results in the ipv4 address of
the router to be changed. After netwpork restart , name resolution of the Vms
fail.
---

[jira] [Created] (CLOUDSTACK-2888) PVLAN - Ubuntu 13.04 vmware - should not allow networks with different primary VLAN with same Secondary VLAN, same primary VLAN with different Secondary VLAN

angeline shen created CLOUDSTACK-2888:
-

 Summary: PVLAN - Ubuntu 13.04   vmware  - should not allow 
networks with different primary VLAN  with same Secondary VLAN, same primary 
VLAN with different Secondary VLAN 
 Key: CLOUDSTACK-2888
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2888
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.2.0
 Environment: MS ASF 4.2 build 
CloudStack-non-OSS-MASTER-452-rhel6.3.tar.gz
vmware ESXi 5.0 hosts 
ubuntu 13.04   hosts
Reporter: angeline shen
Assignee: Venkata Siva Vijayendra Bhamidipati
 Fix For: 4.2.0


Given:
pvlan1  = 1611svlan1 = 998
pvlan2  = 1612svlan2 = 997
nonexistent   svlan3 = 999

Following  PVLAN networks  SHOULD NOT HAVE BEEN ALLOWED to be created :

pvlan1 ,  svlan2 
pvlan1 ,  svlan3  
pvlan2 ,  svlan1
pvlan2 ,  svlan3

Result:   Above PVLAN networks were allowed to be created



--
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-2888) PVLAN - Ubuntu 13.04 vmware - should not allow networks with different primary VLAN with same Secondary VLAN, same primary VLAN with different Secondary VLAN


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

angeline shen updated CLOUDSTACK-2888:
--

Attachment: management-server.log.gz

 PVLAN - Ubuntu 13.04   vmware  - should not allow networks with different 
 primary VLAN  with same Secondary VLAN, same primary VLAN with different 
 Secondary VLAN 
 --

 Key: CLOUDSTACK-2888
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2888
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.0
 Environment: MS ASF 4.2 build 
 CloudStack-non-OSS-MASTER-452-rhel6.3.tar.gz
 vmware ESXi 5.0 hosts 
 ubuntu 13.04   hosts
Reporter: angeline shen
Assignee: Venkata Siva Vijayendra Bhamidipati
 Fix For: 4.2.0

 Attachments: management-server.log.gz


 Given:
 pvlan1  = 1611svlan1 = 998
 pvlan2  = 1612svlan2 = 997
 nonexistent   svlan3 = 999
 Following  PVLAN networks  SHOULD NOT HAVE BEEN ALLOWED to be created :
 pvlan1 ,  svlan2 
 pvlan1 ,  svlan3  
 pvlan2 ,  svlan1
 pvlan2 ,  svlan3
 Result:   Above PVLAN networks were allowed to be created

--
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-2775) PVLAN - Ubuntu 13.04 KVM openvswitch - VM cannot reach DHCP server, outside world


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

angeline shen closed CLOUDSTACK-2775.
-


verified bug fix

 PVLAN - Ubuntu 13.04 KVM  openvswitch - VM cannot reach DHCP server, outside 
 world
 --

 Key: CLOUDSTACK-2775
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2775
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.2.0
 Environment: MS ubuntu 13.04 KVM ACS 4.2 PVLAN build 417
 host ubuntu 13.04 KVM ACS 4.2 PVLAN build 22 
Reporter: angeline shen
Assignee: Sheng Yang
Priority: Critical
 Fix For: 4.2.0

 Attachments: management-server.log.gz


 1. advance zone. Add 2 hosts. Create PVLAN networks.
 2. VMs deployed on 1 host cannot reach DHCP server  outside wide.
VMs deployed on other host able to reach DHCP server  outside wide.
 Per Sheng's analysis  :
 root@ubuntu8161:~# ovs-ofctl show cloudbr0
 OFPT_FEATURES_REPLY (xid=0x1): dpid:bc305bd415d2
 n_tables:255, n_buffers:256
 capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
 actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC SET_DL_DST 
 SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE
 10(em1): addr:bc:30:5b:d4:15:d2
  config: 0
  state:  0
  current:1GB-FD COPPER AUTO_NEG
  advertised: 10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD AUTO_NEG
  supported:  10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-FD COPPER AUTO_NEG
  speed: 1000 Mbps now, 1000 Mbps max
 288(vnet1): addr:fe:58:38:00:00:03
  config: 0
  state:  0
  current:10MB-FD COPPER
  speed: 10 Mbps now, 100 Mbps max
 289(vnet2): addr:fe:fd:e6:00:00:08
  config: 0
  state:  0
  current:10MB-FD COPPER
  speed: 10 Mbps now, 100 Mbps max
 290(vnet3): addr:fe:0d:68:00:00:04
  config: 0
  state:  0
  current:10MB-FD COPPER
  speed: 10 Mbps now, 100 Mbps max
 291(vnet4): addr:fe:ca:c6:00:00:0e
  config: 0
  state:  0
  current:10MB-FD COPPER
  speed: 10 Mbps now, 100 Mbps max
 292(vnet6): addr:fe:3f:3a:00:00:0d
  config: 0
  state:  0
  current:10MB-FD COPPER
  speed: 10 Mbps now, 100 Mbps max
 293(vnet7): addr:fe:41:98:00:00:10
  config: 0
  state:  0
  current:10MB-FD COPPER
  speed: 10 Mbps now, 100 Mbps max
 LOCAL(cloudbr0): addr:bc:30:5b:d4:15:d2
 config: 0
  state:  0
  speed: 100 Mbps now, 100 Mbps max
 OFPT_GET_CONFIG_REPLY (xid=0x3): frags=normal miss_send_len=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] [Assigned] (CLOUDSTACK-2882) Test case test_vm_life_cycle.TestVMLifeCycle.test_10_attachAndDetach_iso failing due to wrong mount point in KVM

2013-06-06 Thread Prasanna Santhanam (JIRA)


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

Prasanna Santhanam reassigned CLOUDSTACK-2882:
--

Assignee: Prasanna Santhanam  (was: Girish Shilamkar)

 Test case test_vm_life_cycle.TestVMLifeCycle.test_10_attachAndDetach_iso 
 failing due to wrong mount point in KVM
 --

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


 Test case test_vm_life_cycle.TestVMLifeCycle.test_10_attachAndDetach_iso 
 failing due to wrong mount point in KVM
 Test case failing with below error
 paramiko.transport: INFO: Secsh channel 3 opened.
 paramiko.transport: DEBUG: [chan 3] Sesch channel 3 request ok
 sshClient: DEBUG: {Cmd: mount -rt iso9660 /dev/xvdd /mnt/tmp via Host: 
 10.208.10.22} {returns: ['mount: special device /dev/xvdd does not exist']}
 http://jenkins.cloudstack.org/view/cloudstack-qa/job/test-smoke-matrix/389/suite=test_vm_life_cycle/testReport/integration.smoke.test_vm_life_cycle/TestVMLifeCycle/test_10_attachAndDetach_iso/

--
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-308) ec2-describe-instances - Instance type is always retuned as m1.small


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

Likitha Shetty commented on CLOUDSTACK-308:
---

Will verify if the problem still exists once CLOUDSTACK-2862 is resolved

 ec2-describe-instances - Instance type is always retuned as m1.small
 --

 Key: CLOUDSTACK-308
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-308
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: AWSAPI
Affects Versions: pre-4.0.0
 Environment: [root@vmwasfmgmt management]# cloud-sccs
 Git Revision: 66daa1a2bc6e86adea265a8a0b8b512756c8f77c
 Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git
Reporter: Sangeetha Hariharan
Assignee: Likitha Shetty
 Fix For: 4.2.0


 ec2-describe-instances - Instance type is always retuned as m1.small
 Using ec2 API call , Deploy a VM using instance-type as m1.large
 Once instance is deployed , describe this instance using  
 ec2-describe-instances.
 Instance type is always retuned as m1.small
 [root@Host41-4 bin]# ./ec2-run-instances 6c7d0b07-9f04-4abd-8069-a4208870218e 
  --instance-type m1.large --connection-timeout 300 --request-timeout 00
 RESERVATION 84b79c96-93b1-474d-bf24-1a3f3b8e171d:hello  
 default
 INSTANCEac7703ca-68bc-437f-a687-45f7e0af7158
 6c7d0b07-9f04-4abd-8069-a4208870218erunning   
   m1.large   2012-10-09T22:39:39-0700ZONE-RHEL-ASF
monitoring- 10.223.59.59   
XenServer
 TAG instanceac7703ca-68bc-437f-a687-45f7e0af7158
 [root@Host41-4 bin]# ./ec2-describe-instances 
 ac7703ca-68bc-437f-a687-45f7e0af7158
 RESERVATION ac7703ca-68bc-437f-a687-45f7e0af7158
 84b79c96-93b1-474d-bf24-1a3f3b8e171d:hello  default
 INSTANCEac7703ca-68bc-437f-a687-45f7e0af7158
 6c7d0b07-9f04-4abd-8069-a4208870218erunning   
   m1.small   2012-10-09T22:39:39-0700ZONE-RHEL-ASF
monitoring- 10.223.59.59   
XenServer
 TAG instanceac7703ca-68bc-437f-a687-45f7e0af7158
 aws-api.logs:
 2012-10-09 22:47:08,829 DEBUG [auth.ec2.AuthenticationHandler] 
 (catalina-exec-int-3:null) X509 cert's uniqueId: EMAILADDRESS=ca, CN=ca, 
 OU=ca, O=ca, L=ca, ST=ca, C=CA, serial=11892681842750832289
 2012-10-09 22:47:08,832 DEBUG [bridge.service.UserContext] 
 (catalina-exec-int-3:null) initializing a new [anonymous] UserContext!
 2012-10-09 22:47:08,833 DEBUG [cloud.stack.CloudStackClient] 
 (catalina-exec-int-3:null) Cloud API call + 
 [http://127.0.0.1:8080/client/api?command=listVirtualMachinesid=ac7703ca-68bc-437f-a687-45f7e0af7158response=jsonlistall=trueapikey=9TAhE9nErO3FyFkA4sQIBcz6BwdjZL-J6whVeoQcNNDtzl2qbsHPaA_ebwEOU3X-sIE6ef2PGvuTPrEtdxLjewsignature=ELmVPZF1cvFSjkKCED%2F1mtjXTiw%3D]
 2012-10-09 22:47:08,853 DEBUG [cloud.stack.CloudStackClient] 
 (catalina-exec-int-3:null) Cloud API call + 
 [http://127.0.0.1:8080/client/api?command=listVirtualMachinesid=ac7703ca-68bc-437f-a687-45f7e0af7158response=jsonlistall=trueapikey=9TAhE9nErO3FyFkA4sQIBcz6BwdjZL-J6whVeoQcNNDtzl2qbsHPaA_ebwEOU3X-sIE6ef2PGvuTPrEtdxLjewsignature=ELmVPZF1cvFSjkKCED%2F1mtjXTiw%3D]
  returned: 
 {listvirtualmachinesresponse:{count:1,virtualmachine:[{id:ac7703ca-68bc-437f-a687-45f7e0af7158,name:ac7703ca-68bc-437f-a687-45f7e0af7158,displayname:ac7703ca-68bc-437f-a687-45f7e0af7158,account:hello,domainid:84b79c96-93b1-474d-bf24-1a3f3b8e171d,domain:ROOT,created:2012-10-09T22:39:39-0700,state:Running,haenable:false,zoneid:c2f29592-038e-4b7a-871c-34ae1c559439,zonename:ZONE-RHEL-ASF,templateid:6c7d0b07-9f04-4abd-8069-a4208870218e,templatename:CentOS
  5.6(64-bit) no GUI (XenServer),templatedisplaytext:CentOS 5.6(64-bit) no 
 GUI 
 (XenServer),passwordenabled:false,serviceofferingid:0c7970fc-b70c-460a-92e0-b4c4280f9d55,serviceofferingname:m1.large,cpunumber:1,cpuspeed:100,memory:124,cpuused:0.19%,networkkbsread:2,networkkbswrite:2,guestosid:b366c5fe-bfdf-47b5-b79f-103c6ce59e99,rootdeviceid:0,rootdevicetype:NetworkFilesystem,securitygroup:[{id:10b78f4f-91a6-47de-a4be-bf024b2a9948,name:default,description:Default
  Security 
 Group}],nic:[{id:98ab6001-f32f-4017-9376-72bdfcdb51fa,networkid:308de7fe-fe95-45cc-b1d7-3c440d501401,netmask:255.255.255.192,gateway:10.223.59.1,ipaddress:10.223.59.59,traffictype:Guest,type:Shared,isdefault:true,macaddress:06:1e:e2:00:00:12}],hypervisor:XenServer,tags:[]}]}}
 2012-10-09 22:47:08,856 WARN  [core.ec2.EC2Engine] (catalina-exec-int-3:null) 
 No instanceType match for

[jira] [Commented] (CLOUDSTACK-305) AWS APi - Rolling back the transaction seen in management server logs , everytime a soap call is made.


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

Likitha Shetty commented on CLOUDSTACK-305:
---

Will work on this bug once CLOUDSTACK-2862 is resolved

 AWS APi - Rolling back the transaction seen in management server logs , 
 everytime a soap call is made.
 

 Key: CLOUDSTACK-305
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-305
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: AWSAPI
Affects Versions: 4.0.0
 Environment: Tested with:
 [root@rhel63 ~]# cloud-sccs
 Git Revision: 1ead1730b42564036b8d4ad70d96433732c88bf7
 Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git
Reporter: Sangeetha Hariharan
Assignee: Likitha Shetty
 Fix For: 4.2.0


 AWS APi - Rolling back the transaction seen in management server logs , 
 everytime a soap call is made.
 Steps to reproduce the problem:
 Install management server.
 Enable enable.ec2.api global variable and restart management server.
 Register a user.
 As this user , make soap calls.
 Soap calls succeed.
 But I see these kinds of rollback statement in management server logs 
 everytime we make a soap call.
 2012-10-09 15:48:12,875 DEBUG [db.Transaction.Transaction] 
 (catalina-exec-int-9:null) Rolling back the transaction: Time = 1 Name =  
 -UserCredentialsDaoImpl.getByCertUniqueId:61-DatabaseCallback.intercept:34-AuthenticationHandler.invoke:118-Phase.invoke:318-AxisEngine.invoke:251-AxisEngine.receive:160-HTTPTransportUtils.processHTTPPostRequest:275-AxisServlet.doPost:133-HttpServlet.service:637-HttpServlet.service:717-ApplicationFilterChain.internalDoFilter:290-ApplicationFilterChain.doFilter:206;
  called by 
 -Transaction.rollback:887-Transaction.removeUpTo:830-Transaction.close:649-UserCredentialsDaoImpl.getByCertUniqueId:68-DatabaseCallback.intercept:34-AuthenticationHandler.invoke:118-Phase.invoke:318-AxisEngine.invoke:251-AxisEngine.receive:160-HTTPTransportUtils.processHTTPPostRequest:275-AxisServlet.doPost:133-HttpServlet.service:637

--
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-2889) test_07_resize_fail and test_08_resize_volume need to skip vmware automation runs