[jira] [Updated] (CLOUDSTACK-5660) Migrate vm live migration succeeds but throws error as Failed to migrate the system vm
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Devdeep Singh updated CLOUDSTACK-5660:
--
Priority: Critical (was: Major)
Migrate vm live migration succeeds but throws error as Failed to migrate
the system vm
--
Key: CLOUDSTACK-5660
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5660
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller
Affects Versions: 4.3.0
Environment: Latest build from 4.3 branch with commit:
bf7601e9b86b7ea66026ac3ac94cd145e9912864
Reporter: Sanjeev N
Assignee: Devdeep Singh
Priority: Critical
Fix For: 4.4.0
[Hyper-v] Migrate vm live migration succeeds but throws error as Failed to
migrate the system vm
Steps to Reproduce:
1.Bring up CS in advanced zone with at-least two hyper-v hosts in the cluster.
2.Deploy one guest vm with default cent os template
3.Live Migrate any vm (system /guest ) to another host.
Result:
==
VM Migration to another host succeeds but the migrate job retuns failure as
follows :2013-12-27 19:19:49,143 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-15:ctx-9065306c) Complete async job-19, jobStatus: FAILED,
resultCode: 530, result:
org.apache.cloudstack.api.response.ExceptionResponse/null/{uuidList:[],errorcode:530,errortext:Failed
to migrate the system vm}
2013-12-27 19:19:49,208 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-15:ctx-9065306c) Done executing
org.apache.cloudstack.api.command.admin.systemvm.MigrateSystemVMCmd for
job-19
Does not throw any exception but throws error in UI and MS log . This might
confuse the user.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5660) Migrate vm live migration succeeds but throws error as Failed to migrate the system vm
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Devdeep Singh updated CLOUDSTACK-5660:
--
Fix Version/s: (was: 4.3.0)
4.4.0
Migrate vm live migration succeeds but throws error as Failed to migrate
the system vm
--
Key: CLOUDSTACK-5660
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5660
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller
Affects Versions: 4.3.0
Environment: Latest build from 4.3 branch with commit:
bf7601e9b86b7ea66026ac3ac94cd145e9912864
Reporter: Sanjeev N
Assignee: Devdeep Singh
Fix For: 4.4.0
[Hyper-v] Migrate vm live migration succeeds but throws error as Failed to
migrate the system vm
Steps to Reproduce:
1.Bring up CS in advanced zone with at-least two hyper-v hosts in the cluster.
2.Deploy one guest vm with default cent os template
3.Live Migrate any vm (system /guest ) to another host.
Result:
==
VM Migration to another host succeeds but the migrate job retuns failure as
follows :2013-12-27 19:19:49,143 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-15:ctx-9065306c) Complete async job-19, jobStatus: FAILED,
resultCode: 530, result:
org.apache.cloudstack.api.response.ExceptionResponse/null/{uuidList:[],errorcode:530,errortext:Failed
to migrate the system vm}
2013-12-27 19:19:49,208 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-15:ctx-9065306c) Done executing
org.apache.cloudstack.api.command.admin.systemvm.MigrateSystemVMCmd for
job-19
Does not throw any exception but throws error in UI and MS log . This might
confuse the user.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5631) [Automation]setup related failures in tests
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Girish Shilamkar resolved CLOUDSTACK-5631.
--
Resolution: Cannot Reproduce
Not seen in last run.
[Automation]setup related failures in tests
---
Key: CLOUDSTACK-5631
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5631
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.3.0
Environment: xenserver 62
advanced zone
Reporter: Srikanteswararao Talluri
Assignee: Srikanteswararao Talluri
Fix For: 4.3.0
Creating this bug as a place holder for the following failures, needs further
analysis,
1 .ContextSuite context=TestVMLifeCycleDiffHosts:setup FAILED
Warning: Exception during setup : Execute cmd: asyncquery failed, due to:
{errorcode : 533, errortext : u'Unable to create a deployment for
VM[User|QA-a6fff610-f343-4a6f-8a9f-c220b6ae075c]'}
2. ContextSuite context=TestBaseImageUpdate:setupFAILED Execute cmd:
asyncquery failed, due to: {errorcode : 530, errortext : u'Unable to start a
VM due to insufficient capacity'}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5908) Fail to add VXLAN network to instance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13877338#comment-13877338 ] Nux commented on CLOUDSTACK-5908: - Hello Toshiaki, Indeed this was the problem as Marcus Sorensen advised me on the ml, there was no IP address set on the bridge, had no idea this is required but now it does make sense for it to be. More tests to come. Thanks for you help! Fail to add VXLAN network to instance - Key: CLOUDSTACK-5908 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5908 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM, Network Controller Affects Versions: 4.3.0 Environment: CentOS 6.5 HV, KVM #modinfo vxlan filename: /lib/modules/2.6.32-431.3.1.el6.x86_64/kernel/drivers/net/vxlan.ko alias: rtnl-link-vxlan author: Stephen Hemminger step...@networkplumber.org version:0.1 license:GPL srcversion: 1732128C5C4FB8CAE4A5C8B depends: vermagic: 2.6.32-431.3.1.el6.x86_64 SMP mod_unload modversions parm: udp_port:Destination UDP port (ushort) parm: log_ecn_error:Log packets received with corrupted ECN (bool) Reporter: Nux Labels: kvm, network, vxlan Hello, I can successfully add a network with VXLAN in ACS 4.3.0, however a VM will not start with it added. Relevant log: 2014-01-19 13:23:22,750 DEBUG [cloud.agent.Agent] (agentRequest-Handler-4:null) Processing command: com.cloud.agent.api.StartCommand 2014-01-19 13:23:23,460 DEBUG [kvm.resource.BridgeVifDriver] (agentRequest-Handler-4:null) nic=[Nic:Guest-10.11.12.13-vxlan://5161] 2014-01-19 13:23:23,461 DEBUG [kvm.resource.BridgeVifDriver] (agentRequest-Handler-4:null) creating a vNet dev and bridge for guest traffic per traff ic label cloudbr1 2014-01-19 13:23:23,461 DEBUG [kvm.resource.BridgeVifDriver] (agentRequest-Handler-4:null) Executing: /usr/share/cloudstack-common/scripts/vm/network /vnet/modifyvxlan.sh -v 5161 -p eth1 -b brvx-5161 -o add 2014-01-19 13:23:23,483 DEBUG [kvm.resource.BridgeVifDriver] (agentRequest-Handler-4:null) Exit value is 1 2014-01-19 13:23:23,483 DEBUG [kvm.resource.BridgeVifDriver] (agentRequest-Handler-4:null) Failed to find vxlan multicast source ip address on brif: cloudbr1. 2014-01-19 13:23:23,484 WARN [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-4:null) InternalErrorException com.cloud.exception.InternalErrorException: Failed to create vnet 5161: Failed to find vxlan multicast source ip address on brif: cloudbr1. at com.cloud.hypervisor.kvm.resource.BridgeVifDriver.createVnet(BridgeVifDriver.java:200) at com.cloud.hypervisor.kvm.resource.BridgeVifDriver.createVnetBr(BridgeVifDriver.java:180) at com.cloud.hypervisor.kvm.resource.BridgeVifDriver.plug(BridgeVifDriver.java:113) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.createVif(LibvirtComputingResource.java:3841) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.createVifs(LibvirtComputingResource.java:3592) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3619) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1301) at com.cloud.agent.Agent.processRequest(Agent.java:498) at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:806) at com.cloud.utils.nio.Task.run(Task.java:83) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:701) 2014-01-19 13:23:23,484 DEBUG [kvm.storage.KVMStoragePoolManager] (agentRequest-Handler-4:null) Disconnecting disk 5589b5ce-f0be-4ad3-8f99-b83316d5b1 45 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-5915) [AWSAPI] Instance launch is inconsistent if there are deleted service offerings
Likitha Shetty created CLOUDSTACK-5915: -- Summary: [AWSAPI] Instance launch is inconsistent if there are deleted service offerings Key: CLOUDSTACK-5915 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5915 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: AWSAPI Affects Versions: 4.2.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.4.0 Create a custom compute-offering by the name 'm1.small', delete the offering and create a new one by the same name 'm1.small'. Now repeatedly try to launch instances using ec2-run-instances. Sometimes the launch will fail with error ' Unable to find service offering by id' -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5915) [AWSAPI] Instance launch is inconsistent if there are deleted service offerings
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13877357#comment-13877357 ] ASF subversion and git services commented on CLOUDSTACK-5915: - Commit 226b74913134af6e541001159519cc2fcfc1ec21 in branch refs/heads/master from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=226b749 ] CLOUDSTACK-5915. [AWSAPI] Instance launch is inconsistent if there are deleted service offerings Use CS API listServiceOfferingsCmd to retrieve appropriate service offerings [AWSAPI] Instance launch is inconsistent if there are deleted service offerings Key: CLOUDSTACK-5915 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5915 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: AWSAPI Affects Versions: 4.2.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.4.0 Create a custom compute-offering by the name 'm1.small', delete the offering and create a new one by the same name 'm1.small'. Now repeatedly try to launch instances using ec2-run-instances. Sometimes the launch will fail with error ' Unable to find service offering by id' -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5915) [AWSAPI] Instance launch is inconsistent if there are deleted service offerings
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Likitha Shetty resolved CLOUDSTACK-5915. Resolution: Fixed [AWSAPI] Instance launch is inconsistent if there are deleted service offerings Key: CLOUDSTACK-5915 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5915 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: AWSAPI Affects Versions: 4.2.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.4.0 Create a custom compute-offering by the name 'm1.small', delete the offering and create a new one by the same name 'm1.small'. Now repeatedly try to launch instances using ec2-run-instances. Sometimes the launch will fail with error ' Unable to find service offering by id' -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-5916) associateIpAddress leaves an IP in allocating state
Saksham Srivastava created CLOUDSTACK-5916: -- Summary: associateIpAddress leaves an IP in allocating state Key: CLOUDSTACK-5916 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5916 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.4.0 Environment: 4.3, Xenserver Reporter: Saksham Srivastava Assignee: Saksham Srivastava associateIpAddress leaves an IP in allocating state (user_ip_address table), although the API command is executed on incorrectly. Steps to repro : 1) create a vpc tier. 2) Execute associateIpAddress API on the vpc tier but do not specify the vpc id. #cloudmonkey associate ipaddress networkid=09ffc45f-beba-4690-8be7-425891915d44 Async job ea020246-d0e8-4e58-ac84-fccb55c3b646 failed Error 530, Can't assign ip to the network directly when network belongs to VPC.Specify vpcId to associate ip address to VPC accountid = a6ba35b3-7e76-11e3-8490-7614eba325e6 cmd = org.apache.cloudstack.api.command.user.address.AssociateIPAddrCmd created = 2014-01-21T10:46:46+0530 jobid = ea020246-d0e8-4e58-ac84-fccb55c3b646 jobprocstatus = 0 jobresult: errorcode = 530 errortext = Can't assign ip to the network directly when network belongs to VPC.Specify vpcId to associate ip address to VPC jobresultcode = 530 jobresulttype = object jobstatus = 2 userid = a6ba5844-7e76-11e3-8490-7614eba325e6 Expected behavior: There should be no allocation of IP . Actual behaviour: The public IP remains in 'Allocating' state -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5868) Default templates are still referring to older templates in DB
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13877383#comment-13877383 ] ASF subversion and git services commented on CLOUDSTACK-5868: - Commit 0e7146268da8e27d4785db2a5fe8d94912bddcd8 in branch refs/heads/master from [~sateeshc] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0e714626 ] CLOUDSTACK-5868 Default templates are still referring to older templates in DB Updated URL and bits for 64-bit system vm template for VMware. Signed-off-by: Sateesh Chodapuneedi sate...@apache.org Default templates are still referring to older templates in DB -- Key: CLOUDSTACK-5868 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5868 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Template Affects Versions: 4.3.0 Environment: All HVs Reporter: Sudha Ponnaganti Assignee: Sateesh Chodapuneedi Priority: Blocker Fix For: 4.3.0 Default template location is referring to older templates. Need to switch to 4.3 ++---+--+++-+ | id | name | bits | url | type | hypervisor_type | ++---+--+++-+ | 1 | SystemVM Template (XenServer) | 32 | http://download.cloud.com/templates/4.2/systemvmtemplate-2013-07-12-master-xen.vhd.bz2 | SYSTEM | XenServer | | 8 | SystemVM Template (vSphere) | 32 | http://download.cloud.com/templates/4.2/systemvmtemplate-4.2-vh7.ova | SYSTEM | VMware | ++---+--+++-+ -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-2232) Automation: Add automation for Persistent networks without running a VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashutosk Kelkar reassigned CLOUDSTACK-2232: --- Assignee: Ashutosk Kelkar Automation: Add automation for Persistent networks without running a VM Key: CLOUDSTACK-2232 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2232 Project: CloudStack Issue Type: Sub-task Security Level: Public(Anyone can view this level - this is the default.) Reporter: Sudha Ponnaganti Assignee: Ashutosk Kelkar Fix For: 4.3.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-5917) Import/Export Firewall Rules/Templates
Ronald Higgins created CLOUDSTACK-5917: -- Summary: Import/Export Firewall Rules/Templates Key: CLOUDSTACK-5917 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5917 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: Future Reporter: Ronald Higgins Priority: Minor Ability to import / export firewall rulesets to assist in managing large ACL's. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-5918) Need to document it in release note
prashant kumar mishra created CLOUDSTACK-5918: - Summary: Need to document it in release note Key: CLOUDSTACK-5918 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5918 Project: CloudStack Issue Type: Sub-task Security Level: Public (Anyone can view this level - this is the default.) Components: Doc Affects Versions: 4.3.0 Reporter: prashant kumar mishra register system vm mplate with name 1-systemvm-vmware-4.3 2-systemvm-kvm-4.3 3-systemvm-xenserver-4.3 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5918) Need to document it in release note
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-5918: -- Priority: Critical (was: Major) Need to document it in release note --- Key: CLOUDSTACK-5918 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5918 Project: CloudStack Issue Type: Sub-task Security Level: Public(Anyone can view this level - this is the default.) Components: Doc Affects Versions: 4.3.0 Reporter: prashant kumar mishra Priority: Critical Fix For: 4.3.0 register system vm mplate with name 1-systemvm-vmware-4.3 2-systemvm-kvm-4.3 3-systemvm-xenserver-4.3 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5707) Hitting multiple exceptions when the Vsphere client is upgraded to 5.5 from 5.1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] manasaveloori closed CLOUDSTACK-5707. - Verified the Vcenter upgrade from 5.1 to 5.5.Working fine. Hence closing the issue. Hitting multiple exceptions when the Vsphere client is upgraded to 5.5 from 5.1 --- Key: CLOUDSTACK-5707 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5707 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.3.0 Environment: Upgraded the CS 4.2.1 to 4.3 with ESXi5.1 using Vsphere client 5.1 Upgraded the Vsphere client to 5.5 Reporter: manasaveloori Assignee: Likitha Shetty Priority: Critical Fix For: 4.3.0 Attachments: management-server.rar Steps followed: 1.Deployed CS 4.2.1 GA build with ESXi5.1(using Vsphere 5.1 client) 2.Deployed some VMs. 3.Upgraded the CS to 4.3. 4.Now unmanaged the cluster, kept the host in maintenance . 5.Upgraded the Vsphere client to 5.5 (http://www.vmadmin.co.uk/vmware/36-virtualcenter/284-vsphere4to5upgradevcenter41to5) 6.Manage the cluster and cancelled the maintenance mode on host. 7.Host is connected. Observing the following exceptions in Ms logs: 014-01-01 20:03:35,467 DEBUG [c.c.s.StatsCollector] (StatsCollector-3:ctx-a4d2e607) StorageCollector is running... 2014-01-01 20:03:35,497 INFO [c.c.a.m.AgentAttache] (StatsCollector-3:ctx-a4d2e607) Seq 2-1062210638: Unable to send due to Resource [Host:2] is unreachable: Host 2: Channel is closed 2014-01-01 20:03:35,497 DEBUG [c.c.a.m.AgentAttache] (StatsCollector-3:ctx-a4d2e607) Seq 2-1062210638: Cancelling. 2014-01-01 20:03:35,498 DEBUG [o.a.c.s.RemoteHostEndPoint] (StatsCollector-3:ctx-a4d2e607) Failed to send command, due to Agent:2, com.cloud.exception.AgentUnavailableException: Resource [Host:2] is unreachable: Host 2: Channel is closed 2014-01-01 20:03:35,498 ERROR [c.c.s.StatsCollector] (StatsCollector-3:ctx-a4d2e607) Error trying to retrieve storage stats com.cloud.utils.exception.CloudRuntimeException: Failed to send command, due to Agent:2, com.cloud.exception.AgentUnavailableException: Resource [Host:2] is unreachable: Host 2: Channel is closed at org.apache.cloudstack.storage.RemoteHostEndPoint.sendMessage(RemoteHostEndPoint.java:116) at com.cloud.server.StatsCollector$StorageCollector.runInContext(StatsCollector.java:550) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) 2014-01-01 20:03:35,506 DEBUG [c.c.s.StatsCollector] (StatsCollector-1:ctx-df84e56c) HostStatsCollector is running... 2014-01-01 20:03:35,534 DEBUG [c.c.a.m.DirectAgentAttache] (DirectAgent-374:ctx-c3b00e50) Seq 4-378077280: Executing request 2014-01-01 20:03:35,638 ERROR [c.c.h.v.r.VmwareResource] (DirectAgent-374:ctx-c3b00e50 10.147.40.28) Unable to execute GetHostStatsCommand due to Exception: javax.xml.ws.soap.SOAPFaultException Message: The session is not authenticated. javax.xml.ws.soap.SOAPFaultException: The session is not authenticated. at com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) at com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) at
[jira] [Updated] (CLOUDSTACK-5916) associateIpAddress leaves an IP in allocating state
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saksham Srivastava updated CLOUDSTACK-5916: --- Status: Reviewable (was: In Progress) associateIpAddress leaves an IP in allocating state Key: CLOUDSTACK-5916 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5916 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.4.0 Environment: 4.3, Xenserver Reporter: Saksham Srivastava Assignee: Saksham Srivastava associateIpAddress leaves an IP in allocating state (user_ip_address table), although the API command is executed on incorrectly. Steps to repro : 1) create a vpc tier. 2) Execute associateIpAddress API on the vpc tier but do not specify the vpc id. #cloudmonkey associate ipaddress networkid=09ffc45f-beba-4690-8be7-425891915d44 Async job ea020246-d0e8-4e58-ac84-fccb55c3b646 failed Error 530, Can't assign ip to the network directly when network belongs to VPC.Specify vpcId to associate ip address to VPC accountid = a6ba35b3-7e76-11e3-8490-7614eba325e6 cmd = org.apache.cloudstack.api.command.user.address.AssociateIPAddrCmd created = 2014-01-21T10:46:46+0530 jobid = ea020246-d0e8-4e58-ac84-fccb55c3b646 jobprocstatus = 0 jobresult: errorcode = 530 errortext = Can't assign ip to the network directly when network belongs to VPC.Specify vpcId to associate ip address to VPC jobresultcode = 530 jobresulttype = object jobstatus = 2 userid = a6ba5844-7e76-11e3-8490-7614eba325e6 Expected behavior: There should be no allocation of IP . Actual behaviour: The public IP remains in 'Allocating' state -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5916) associateIpAddress leaves an IP in allocating state
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13877413#comment-13877413 ] Saksham Srivastava commented on CLOUDSTACK-5916: Fix available for review at https://reviews.apache.org/r/17142/ associateIpAddress leaves an IP in allocating state Key: CLOUDSTACK-5916 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5916 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.4.0 Environment: 4.3, Xenserver Reporter: Saksham Srivastava Assignee: Saksham Srivastava associateIpAddress leaves an IP in allocating state (user_ip_address table), although the API command is executed on incorrectly. Steps to repro : 1) create a vpc tier. 2) Execute associateIpAddress API on the vpc tier but do not specify the vpc id. #cloudmonkey associate ipaddress networkid=09ffc45f-beba-4690-8be7-425891915d44 Async job ea020246-d0e8-4e58-ac84-fccb55c3b646 failed Error 530, Can't assign ip to the network directly when network belongs to VPC.Specify vpcId to associate ip address to VPC accountid = a6ba35b3-7e76-11e3-8490-7614eba325e6 cmd = org.apache.cloudstack.api.command.user.address.AssociateIPAddrCmd created = 2014-01-21T10:46:46+0530 jobid = ea020246-d0e8-4e58-ac84-fccb55c3b646 jobprocstatus = 0 jobresult: errorcode = 530 errortext = Can't assign ip to the network directly when network belongs to VPC.Specify vpcId to associate ip address to VPC jobresultcode = 530 jobresulttype = object jobstatus = 2 userid = a6ba5844-7e76-11e3-8490-7614eba325e6 Expected behavior: There should be no allocation of IP . Actual behaviour: The public IP remains in 'Allocating' state -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5914) Unable to copy a template to primary storage, due java version in SSVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinandan Prateek updated CLOUDSTACK-5914: --- Assignee: Abhinandan Prateek Unable to copy a template to primary storage, due java version in SSVM -- Key: CLOUDSTACK-5914 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5914 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM, VMware Affects Versions: 4.2.0 Environment: vCenter version: 5.0 update 1a (Build 755629) 4.2 32 bits SystemVM templates Reporter: Abhinandan Prateek Assignee: Abhinandan Prateek Priority: Critical Fix For: 4.3.0 The symptoms of this incompatibility issue is that vCenter session will be left invalid right after the vSphere 5.x API has successfully logged in our session to vCenter, it can caused a number of NPE or other exceptions due to it. replacing it with a right JRE version can fix the problem. The problem happens in a lower JRE version 1.6.2x, it works fine with higher 1.6.4x version. The following messages are seen over and over in the log: 2013-10-17 11:06:00,120 DEBUG [agent.manager.AgentManagerImpl] (AgentTaskPool-13:null) Simulating start for resource c964ujp.int.thomsonreuters.com id 54 2013-10-17 11:06:00,120 DEBUG [agent.manager.ClusteredAgentManagerImpl] (ClusteredAgentManager Timer:null) Loading directly connected host 55(c599zht.int.thomsonreuters.com) 2013-10-17 11:06:00,128 DEBUG [agent.manager.DirectAgentAttache] (DirectAgent-286:null) Seq 32-361103401: Executing request 2013-10-17 11:06:00,141 DEBUG [vmware.resource.VmwareContextFactory] (ClusteredAgentManager Timer:null) initialize VmwareContext. url: https://C479REM.mgmt.tlrg.com/sdk/vimService, username: cloudstack, password: C* 2013-10-17 11:06:00,240 ERROR [vmware.resource.VmwareResource] (AgentTaskPool-13:null) VmwareResource intialize() failed due to : Exception: java.lang.NullPointerException Message: null -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5914) Unable to copy a template to primary storage, due java version in SSVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinandan Prateek updated CLOUDSTACK-5914: --- Priority: Major (was: Critical) Unable to copy a template to primary storage, due java version in SSVM -- Key: CLOUDSTACK-5914 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5914 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM, VMware Affects Versions: 4.2.0 Environment: vCenter version: 5.0 update 1a (Build 755629) 4.2 32 bits SystemVM templates Reporter: Abhinandan Prateek Assignee: Abhinandan Prateek Fix For: 4.3.0 The symptoms of this incompatibility issue is that vCenter session will be left invalid right after the vSphere 5.x API has successfully logged in our session to vCenter, it can caused a number of NPE or other exceptions due to it. replacing it with a right JRE version can fix the problem. The problem happens in a lower JRE version 1.6.2x, it works fine with higher 1.6.4x version. The following messages are seen over and over in the log: 2013-10-17 11:06:00,120 DEBUG [agent.manager.AgentManagerImpl] (AgentTaskPool-13:null) Simulating start for resource c964ujp.int.thomsonreuters.com id 54 2013-10-17 11:06:00,120 DEBUG [agent.manager.ClusteredAgentManagerImpl] (ClusteredAgentManager Timer:null) Loading directly connected host 55(c599zht.int.thomsonreuters.com) 2013-10-17 11:06:00,128 DEBUG [agent.manager.DirectAgentAttache] (DirectAgent-286:null) Seq 32-361103401: Executing request 2013-10-17 11:06:00,141 DEBUG [vmware.resource.VmwareContextFactory] (ClusteredAgentManager Timer:null) initialize VmwareContext. url: https://C479REM.mgmt.tlrg.com/sdk/vimService, username: cloudstack, password: C* 2013-10-17 11:06:00,240 ERROR [vmware.resource.VmwareResource] (AgentTaskPool-13:null) VmwareResource intialize() failed due to : Exception: java.lang.NullPointerException Message: null -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5914) Unable to copy a template to primary storage, due java version in SSVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13877422#comment-13877422 ] Abhinandan Prateek commented on CLOUDSTACK-5914: Reducing the priority to major as it is not easily reproducible and affects only a particular version of VMWare. Unable to copy a template to primary storage, due java version in SSVM -- Key: CLOUDSTACK-5914 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5914 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM, VMware Affects Versions: 4.2.0 Environment: vCenter version: 5.0 update 1a (Build 755629) 4.2 32 bits SystemVM templates Reporter: Abhinandan Prateek Assignee: Abhinandan Prateek Fix For: 4.3.0 The symptoms of this incompatibility issue is that vCenter session will be left invalid right after the vSphere 5.x API has successfully logged in our session to vCenter, it can caused a number of NPE or other exceptions due to it. replacing it with a right JRE version can fix the problem. The problem happens in a lower JRE version 1.6.2x, it works fine with higher 1.6.4x version. The following messages are seen over and over in the log: 2013-10-17 11:06:00,120 DEBUG [agent.manager.AgentManagerImpl] (AgentTaskPool-13:null) Simulating start for resource c964ujp.int.thomsonreuters.com id 54 2013-10-17 11:06:00,120 DEBUG [agent.manager.ClusteredAgentManagerImpl] (ClusteredAgentManager Timer:null) Loading directly connected host 55(c599zht.int.thomsonreuters.com) 2013-10-17 11:06:00,128 DEBUG [agent.manager.DirectAgentAttache] (DirectAgent-286:null) Seq 32-361103401: Executing request 2013-10-17 11:06:00,141 DEBUG [vmware.resource.VmwareContextFactory] (ClusteredAgentManager Timer:null) initialize VmwareContext. url: https://C479REM.mgmt.tlrg.com/sdk/vimService, username: cloudstack, password: C* 2013-10-17 11:06:00,240 ERROR [vmware.resource.VmwareResource] (AgentTaskPool-13:null) VmwareResource intialize() failed due to : Exception: java.lang.NullPointerException Message: null -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-5919) Add Removed field and/or versioning and/or rollback on Firewall/Nat/FB rules
Roeland Kuipers created CLOUDSTACK-5919: --- Summary: Add Removed field and/or versioning and/or rollback on Firewall/Nat/FB rules Key: CLOUDSTACK-5919 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5919 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Reporter: Roeland Kuipers Fix For: Future To power of an IaaS cloud is that everything can be automated like network changes. This comes with a huge risk in case of human error or malfunctioning code. For example a cookbook which contains a bug and instead of adding a rule removes all fw/nat/lb rules. Currently this means that if you cannot restore this from your cfg mgmt system that you need to restore these rules from a database backup, which is a somewhat lengthy and complex process. A way to mitigate this risk is to add a removed field to the fw/nat/lb rules tables. This seams common practice on a lot of CS tables. But not on these specific tables. A nicer implementation would be to add a versioning system behind these configurations. This might look like a corner case but unfortunately this is real live experience. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5232) Unauthenticated API allows Admin password reset
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-5232: --- Security: Public (was: Non-Public) Unauthenticated API allows Admin password reset --- Key: CLOUDSTACK-5232 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5232 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.0 Reporter: John Kinsella Assignee: Alena Prokharchyk Priority: Critical Fix For: 4.3.0 The unauthenticated API allows a caller to reset CCP administrator passwords. This presents a security risk because it allows for privilege escalation attacks. First, if the unauthenticated API is listening on the network (instead of locally) than any user on the network can reset admin passwords. If, the API is only listening locally, then any user with access to the local box can reset admin passwords. This would allow them to access other hosts within the CloudStack deployment. While it may be important to provide a recovery mechanism for admin passwords that have been lost or hijacked, such a solution needs to be secure. We should either remove this feature from the Unauthenticated API, or provide a solution that is less open to abuse. Identified by: Demetrius Tsitrelis from Citrix CVSS Score: 7.2 (AV:L/AC:L/Au:N/C:C/I:C/A:C) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5232) Unauthenticated API allows Admin password reset
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13877742#comment-13877742 ] Animesh Chaturvedi commented on CLOUDSTACK-5232: Alena can you commit your patch into 4.3 and master Unauthenticated API allows Admin password reset --- Key: CLOUDSTACK-5232 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5232 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.0 Reporter: John Kinsella Assignee: Alena Prokharchyk Priority: Critical Fix For: 4.3.0 The unauthenticated API allows a caller to reset CCP administrator passwords. This presents a security risk because it allows for privilege escalation attacks. First, if the unauthenticated API is listening on the network (instead of locally) than any user on the network can reset admin passwords. If, the API is only listening locally, then any user with access to the local box can reset admin passwords. This would allow them to access other hosts within the CloudStack deployment. While it may be important to provide a recovery mechanism for admin passwords that have been lost or hijacked, such a solution needs to be secure. We should either remove this feature from the Unauthenticated API, or provide a solution that is less open to abuse. Identified by: Demetrius Tsitrelis from Citrix CVSS Score: 7.2 (AV:L/AC:L/Au:N/C:C/I:C/A:C) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-5920) CloudStack IAM Plugin feature
Prachi Damle created CLOUDSTACK-5920: Summary: CloudStack IAM Plugin feature Key: CLOUDSTACK-5920 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5920 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API, Management Server Affects Versions: 4.3.0 Reporter: Prachi Damle Assignee: Prachi Damle Fix For: 4.4.0 Currently CloudStack provides very limited IAM services and there are several drawbacks within those services: - Offers few roles out of the box (user and admin) with prebaked access control for these roles. There is no way to create additional roles with customized permissions. - Some resources have access control baked into them. E.g., shared networks, projects etc. - We have to create special dedicate APIs to grant permissions to resources. - Also it should be based on a plugin model to be possible to integrate with other RBAC implementations say using AD/LDAP in future Goal for this feature would be to address these limitations and offer true IAM services in a phased manner. As a first phase, we need to separate out the current access control into a separate component and create a standard access check mechanism to be used by the API layer. Also the read/listing APIs need to be refactored accordingly to consider the role based access granting. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5884) traffic tag ignored on second physical network with guest traffic type
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13877782#comment-13877782 ] ASF subversion and git services commented on CLOUDSTACK-5884: - Commit d4e069ecc8708ca37785a82fa8c6442d47363974 in branch refs/heads/master from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d4e069e ] Fix noredist build issue Introduced by: commit ac65f8fddf182534a2dbea81c7e155b80e7c98ea Author: Hugo Trippaers htrippa...@schubergphilis.com Date: Mon Jan 20 18:03:02 2014 +0100 CLOUDSTACK-5884 make getTargetSwitch(NicTO nicTo) do all the work to select switch name, type and vlan token. Change preference to use the tags set on the physical network. traffic tag ignored on second physical network with guest traffic type -- Key: CLOUDSTACK-5884 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5884 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Hugo Trippaers Assignee: Animesh Chaturvedi Priority: Blocker Fix For: 4.3.0 When a vmware environment is created with two physical networks that both have the guest traffic type. The switch tag set on the second physical network will be ignored and the switch from the first physical network will be used. This is a problem for some of the SDN implementations that often coexist with a vlan based guest network on another physical network. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-5921) S3 security key is stored in DB unencrypted
Min Chen created CLOUDSTACK-5921: Summary: S3 security key is stored in DB unencrypted Key: CLOUDSTACK-5921 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5921 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.0 Reporter: Min Chen Priority: Critical Fix For: 4.3.0 When we add a S3 as secondary storage, S3 secret key is stored in DB as unencrypted, this is not secure. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5921) S3 security key is stored in DB unencrypted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13877923#comment-13877923 ] ASF subversion and git services commented on CLOUDSTACK-5921: - Commit afb8a79321ca3a5356e332f28038b58a8d1d040c in branch refs/heads/4.3 from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=afb8a79 ] CLOUDSTACK-5921: S3 security key is stored in DB unencrypted S3 security key is stored in DB unencrypted --- Key: CLOUDSTACK-5921 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5921 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.0 Reporter: Min Chen Priority: Critical Fix For: 4.3.0 When we add a S3 as secondary storage, S3 secret key is stored in DB as unencrypted, this is not secure. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-4875) VMWARE: vCenter 5.5 - SYSTEM VM: Unable to create deployment for VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudha Ponnaganti closed CLOUDSTACK-4875.
VMWARE: vCenter 5.5 - SYSTEM VM: Unable to create deployment for VM
---
Key: CLOUDSTACK-4875
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4875
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: SystemVM, VMware
Affects Versions: 4.2.1
Environment: Master with vCenter 5.5 / ESXi 5.5
Reporter: Parth Jagirdar
Assignee: Likitha Shetty
Priority: Blocker
Fix For: 4.3.0
Attachments: VC5.5.jpg, catalina.out, management-server.log
Unable to launch system VM's
See attached logs
2013-10-15 13:31:40,061 DEBUG [cloud.storage.VolumeManagerImpl]
(consoleproxy-1:null) Unable to create
Vol[2|vm=2|ROOT]:java.lang.RuntimeException: File
[803eb6157bb83df98d96c4da27252fa8] ROOT-2/ROOT-2.vmdk was not found
2013-10-15 13:31:40,061 INFO [cloud.vm.VirtualMachineManagerImpl]
(consoleproxy-1:null) Unable to contact resource.
com.cloud.exception.StorageUnavailableException: Resource [StoragePool:1] is
unreachable: Unable to create Vol[2|vm=2|ROOT]:java.lang.RuntimeException:
File [803eb6157bb83df98d96c4da27252fa8] ROOT-2/ROOT-2.vmdk was not found
at
com.cloud.storage.VolumeManagerImpl.recreateVolume(VolumeManagerImpl.java:2566)
at
com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2617)
at
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:889)
at
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:578)
at
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:571)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:556)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:928)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1672)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:157)
at
com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111)
at
com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:33)
at
com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:81)
at com.cloud.vm.SystemVmLoadScanner$1.run(SystemVmLoadScanner.java:72)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
2013-10-15 13:31:40,068 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(consoleproxy-1:null) Cleaning up resources for the vm
VM[ConsoleProxy|v-2-VM] in Starting state
type TEMPLATE copyAsync inspecting dest type VOLUME
2013-10-15 13:33:00,630 DEBUG [agent.transport.Request] (secstorage-1:null)
Seq 1-401276957: Waiting for Seq 401276956 Scheduling: { Cmd , MgmtId:
15929225863658, via: 1, Ver: v1, Flags: 100111,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:b8766e32c0c838539a8f75c2cc62a30b,origUrl:http://download.cloud.com/templates/4.2/systemvmtemplate-4.2-vh7.ova,uuid:e1eb1bf2-35c3-11e3-a10c-0e7ccfd961ea,id:8,format:OVA,accountId:1,checksum:8fde62b1089e5844a9cd3b9b953f9596,hvm:false,displayText:SystemVM
Template
[jira] [Resolved] (CLOUDSTACK-5921) S3 security key is stored in DB unencrypted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-5921. -- Resolution: Fixed S3 security key is stored in DB unencrypted --- Key: CLOUDSTACK-5921 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5921 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.0 Reporter: Min Chen Priority: Critical Fix For: 4.3.0 When we add a S3 as secondary storage, S3 secret key is stored in DB as unencrypted, this is not secure. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-4875) VMWARE: vCenter 5.5 - SYSTEM VM: Unable to create deployment for VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13877933#comment-13877933
]
Parth Jagirdar commented on CLOUDSTACK-4875:
I am currently OoO, Returning on 27th Jan 2014.
Please contact Sudha Ponnaganti
(sudha.ponnaga...@citrix.commailto:sudha.ponnaga...@citrix.com), if anything
requires urgent attention.
Thanks,
Parth Jagirdar
VMWARE: vCenter 5.5 - SYSTEM VM: Unable to create deployment for VM
---
Key: CLOUDSTACK-4875
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4875
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: SystemVM, VMware
Affects Versions: 4.2.1
Environment: Master with vCenter 5.5 / ESXi 5.5
Reporter: Parth Jagirdar
Assignee: Likitha Shetty
Priority: Blocker
Fix For: 4.3.0
Attachments: VC5.5.jpg, catalina.out, management-server.log
Unable to launch system VM's
See attached logs
2013-10-15 13:31:40,061 DEBUG [cloud.storage.VolumeManagerImpl]
(consoleproxy-1:null) Unable to create
Vol[2|vm=2|ROOT]:java.lang.RuntimeException: File
[803eb6157bb83df98d96c4da27252fa8] ROOT-2/ROOT-2.vmdk was not found
2013-10-15 13:31:40,061 INFO [cloud.vm.VirtualMachineManagerImpl]
(consoleproxy-1:null) Unable to contact resource.
com.cloud.exception.StorageUnavailableException: Resource [StoragePool:1] is
unreachable: Unable to create Vol[2|vm=2|ROOT]:java.lang.RuntimeException:
File [803eb6157bb83df98d96c4da27252fa8] ROOT-2/ROOT-2.vmdk was not found
at
com.cloud.storage.VolumeManagerImpl.recreateVolume(VolumeManagerImpl.java:2566)
at
com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2617)
at
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:889)
at
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:578)
at
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:571)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:556)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:928)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1672)
at
com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:157)
at
com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111)
at
com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:33)
at
com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:81)
at com.cloud.vm.SystemVmLoadScanner$1.run(SystemVmLoadScanner.java:72)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
2013-10-15 13:31:40,068 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(consoleproxy-1:null) Cleaning up resources for the vm
VM[ConsoleProxy|v-2-VM] in Starting state
type TEMPLATE copyAsync inspecting dest type VOLUME
2013-10-15 13:33:00,630 DEBUG [agent.transport.Request] (secstorage-1:null)
Seq 1-401276957: Waiting for Seq 401276956 Scheduling: { Cmd , MgmtId:
15929225863658, via: 1, Ver: v1, Flags: 100111,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:b8766e32c0c838539a8f75c2cc62a30b,origUrl:http://download.cloud.com/templates/4.2/systemvmtemplate-4.2-vh7.ova,uuid:e1eb1bf2-35c3-11e3-a10c-0e7ccfd961ea,id:8,format:OVA,accountId:1,checksum:8fde62b1089e5844a9cd3b9b953f9596,hvm:false,displayText:SystemVM
Template
[jira] [Commented] (CLOUDSTACK-5921) S3 security key is stored in DB unencrypted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13877938#comment-13877938 ] ASF subversion and git services commented on CLOUDSTACK-5921: - Commit c0da0a884a1cf7655c751b9d02e4994bf0fd0d2e in branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c0da0a8 ] CLOUDSTACK-5921:S3 security key is stored in DB unencrypted S3 security key is stored in DB unencrypted --- Key: CLOUDSTACK-5921 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5921 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.0 Reporter: Min Chen Priority: Critical Fix For: 4.3.0 When we add a S3 as secondary storage, S3 secret key is stored in DB as unencrypted, this is not secure. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-5922) Incorrect handling RHEL guests
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen reassigned CLOUDSTACK-5922: Assignee: Min Chen Incorrect handling RHEL guests --- Key: CLOUDSTACK-5922 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5922 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.2.1 Reporter: Min Chen Assignee: Min Chen Fix For: 4.3.0 The issue is easily reproducible by deploying a VM with Rhel 6.0 template. Once the VM is deployed you can see that the OS type is sent to Other in the Vcenter. When selecting 'Ubuntu 12.04 64-bit' the VM get created similarly to RHEL with incorrect OS type. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-5922) Incorrect handling RHEL guests
Min Chen created CLOUDSTACK-5922: Summary: Incorrect handling RHEL guests Key: CLOUDSTACK-5922 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5922 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.2.1 Reporter: Min Chen Fix For: 4.3.0 The issue is easily reproducible by deploying a VM with Rhel 6.0 template. Once the VM is deployed you can see that the OS type is sent to Other in the Vcenter. When selecting 'Ubuntu 12.04 64-bit' the VM get created similarly to RHEL with incorrect OS type. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5922) Incorrect handling RHEL guests
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878053#comment-13878053 ] ASF subversion and git services commented on CLOUDSTACK-5922: - Commit f4312664293b9c7fe5ac01a400b37cdb48ce6d2e in branch refs/heads/4.3 from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f431266 ] CLOUDSTACK-5922:Incorrect handling RHEL guests in Vmware. Incorrect handling RHEL guests --- Key: CLOUDSTACK-5922 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5922 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.2.1 Reporter: Min Chen Assignee: Min Chen Fix For: 4.3.0 The issue is easily reproducible by deploying a VM with Rhel 6.0 template. Once the VM is deployed you can see that the OS type is sent to Other in the Vcenter. When selecting 'Ubuntu 12.04 64-bit' the VM get created similarly to RHEL with incorrect OS type. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5922) Incorrect handling RHEL guests
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878064#comment-13878064 ] ASF subversion and git services commented on CLOUDSTACK-5922: - Commit 252913374a4998076dafbd6691cad687368d7fd8 in branch refs/heads/4.2 from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2529133 ] CLOUDSTACK-5922:Incorrect handling RHEL guests in Vmware. Incorrect handling RHEL guests --- Key: CLOUDSTACK-5922 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5922 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.2.1 Reporter: Min Chen Assignee: Min Chen Fix For: 4.3.0 The issue is easily reproducible by deploying a VM with Rhel 6.0 template. Once the VM is deployed you can see that the OS type is sent to Other in the Vcenter. When selecting 'Ubuntu 12.04 64-bit' the VM get created similarly to RHEL with incorrect OS type. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5922) Incorrect handling RHEL guests
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-5922. -- Resolution: Fixed Incorrect handling RHEL guests --- Key: CLOUDSTACK-5922 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5922 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.2.1 Reporter: Min Chen Assignee: Min Chen Fix For: 4.3.0 The issue is easily reproducible by deploying a VM with Rhel 6.0 template. Once the VM is deployed you can see that the OS type is sent to Other in the Vcenter. When selecting 'Ubuntu 12.04 64-bit' the VM get created similarly to RHEL with incorrect OS type. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5922) Incorrect handling RHEL guests
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878072#comment-13878072 ] ASF subversion and git services commented on CLOUDSTACK-5922: - Commit 747462b6acaccb242a6809fc2837b406f547cba4 in branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=747462b ] CLOUDSTACK-5922:Incorrect handling RHEL guests. Incorrect handling RHEL guests --- Key: CLOUDSTACK-5922 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5922 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.2.1 Reporter: Min Chen Assignee: Min Chen Fix For: 4.3.0 The issue is easily reproducible by deploying a VM with Rhel 6.0 template. Once the VM is deployed you can see that the OS type is sent to Other in the Vcenter. When selecting 'Ubuntu 12.04 64-bit' the VM get created similarly to RHEL with incorrect OS type. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-5923) XS/CS integration improvement, CS doesn't do master switch for XS
Anthony Xu created CLOUDSTACK-5923: -- Summary: XS/CS integration improvement, CS doesn't do master switch for XS Key: CLOUDSTACK-5923 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5923 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Environment: CS doesn't do master switch for XS any more, CS will depend on XS HA to do master switch, XS HA needs to be enabled. Reporter: Anthony Xu Assignee: Anthony Xu Fix For: 4.3.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5923) XS/CS integration improvement, CS doesn't do master switch for XS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878148#comment-13878148 ] ASF subversion and git services commented on CLOUDSTACK-5923: - Commit af5f3d5676793c7c4d8fee2735fd00b1aebf366a in branch refs/heads/4.3 from [~anthonyxu] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=af5f3d5 ] CLOUDSTACK-5923: CS doesn't do master switch for XS any more, CS will depend on XS HA to do master switch, XS HA needs to be enabled. XS/CS integration improvement, CS doesn't do master switch for XS - Key: CLOUDSTACK-5923 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5923 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Environment: CS doesn't do master switch for XS any more, CS will depend on XS HA to do master switch, XS HA needs to be enabled. Reporter: Anthony Xu Assignee: Anthony Xu Fix For: 4.3.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5923) XS/CS integration improvement, CS doesn't do master switch for XS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Xu resolved CLOUDSTACK-5923. Resolution: Fixed commit af5f3d5676793c7c4d8fee2735fd00b1aebf366a Author: Anthony Xu anthony...@citrix.com Date: Tue Jan 21 17:55:09 2014 -0800 CLOUDSTACK-5923: CS doesn't do master switch for XS any more, CS will depend on XS HA to do master switch, XS HA needs to be enabled. XS/CS integration improvement, CS doesn't do master switch for XS - Key: CLOUDSTACK-5923 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5923 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Environment: CS doesn't do master switch for XS any more, CS will depend on XS HA to do master switch, XS HA needs to be enabled. Reporter: Anthony Xu Assignee: Anthony Xu Fix For: 4.3.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5923) XS/CS integration improvement, CS doesn't do master switch for XS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878186#comment-13878186 ] ASF subversion and git services commented on CLOUDSTACK-5923: - Commit b79f949e1bd9d62b3ebcce424608cb4b22e69897 in branch refs/heads/master from [~anthonyxu] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b79f949 ] CLOUDSTACK-5923: CS doesn't do master switch for XS any more, CS will depend on XS HA to do master switch, XS HA needs to be enabled. Conflicts: plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/discoverer/XcpServerDiscoverer.java plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServerConnectionPool.java XS/CS integration improvement, CS doesn't do master switch for XS - Key: CLOUDSTACK-5923 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5923 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Environment: CS doesn't do master switch for XS any more, CS will depend on XS HA to do master switch, XS HA needs to be enabled. Reporter: Anthony Xu Assignee: Anthony Xu Fix For: 4.3.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5779) Consolidate all the VR commands execution to one resource
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878187#comment-13878187 ] ASF subversion and git services commented on CLOUDSTACK-5779: - Commit 1767ddac77ecc32bb649905259723b914f7b20d3 in branch refs/heads/master from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1767dda ] CLOUDSTACK-5779: Update vmdata command in Vmware To use Gson rather than copy a file to it, follow the same as Xen and KVM. Consolidate all the VR commands execution to one resource - Key: CLOUDSTACK-5779 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5779 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Reporter: Sheng Yang Assignee: Sheng Yang Priority: Critical Fix For: 4.4.0 Currently when anyone add one command to VR(which happened very frequently these days), they need to modify every hypervisor resources to accommodate the new command, which is really inconvenient as well as bug prone, since e.g. the parameters formation would be duplicate across the hypervisors. This improvement would make all VR commands to be executed by only one resource, and in the future, any new command/improvement or bug fixes to VR resource would only need to be done once in the VR resource. This would be done through: 1. Use routeProxy script for all VR commands, no more standalone script for each VR scripts in the host. All VR command scripts would be moved to /opt/cloud/bin for this purpose as well. 2. Every hypervisor would provide an executor to VR resource, to execute the command in giving hypervisor. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-4827) Build failed on 4.2/4.3
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-4827: --- Summary: Build failed on 4.2/4.3 (was: Build failed on 4.2) Build failed on 4.2/4.3 --- Key: CLOUDSTACK-4827 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4827 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Wei Zhou Assignee: Wei Zhou Fix For: 4.2.1 Some guys [1][2] build cloudstack 4.2 source code failed for the following error: [INFO] BUILD FAILURE [INFO] [INFO] Total time: 13:26.004s [INFO] Finished at: Thu Oct 03 10:07:41 CEST 2013 [INFO] Final Memory: 37M/146M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile) on project cloud-plugin-hypervisor-xen: Compilation failure: Compilation failure: [ERROR] /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java:[890,16] cannot find symbol [ERROR] symbol : variable lockingMode [ERROR] location: class com.xensource.xenapi.VIF.Record [ERROR] /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java:[890,36] cannot find symbol [ERROR] symbol : variable VifLockingMode [ERROR] location: class com.xensource.xenapi.Types [ERROR] /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java:[1099,12] cannot find symbol [ERROR] symbol : variable lockingMode [ERROR] location: class com.xensource.xenapi.VIF.Record [ERROR] /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java:[1099,32] cannot find symbol [ERROR] symbol : variable VifLockingMode [ERROR] location: class com.xensource.xenapi.Types [ERROR] /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java:[4869,20] cannot find symbol [ERROR] symbol : variable lockingMode [ERROR] location: class com.xensource.xenapi.VIF.Record [ERROR] /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java:[4869,40] cannot find symbol [ERROR] symbol : variable VifLockingMode [ERROR] location: class com.xensource.xenapi.Types [ERROR] /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer610Resource.java:[160,43] cannot find symbol [ERROR] symbol : method migrateReceive(com.xensource.xenapi.Connection,com.xensource.xenapi.Network,java.util.Mapjava.lang.String,java.lang.String) [ERROR] location: class com.xensource.xenapi.Host [ERROR] /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer610Resource.java:[175,30] cannot find symbol [ERROR] symbol : method assertCanMigrateAsync(com.xensource.xenapi.Connection,java.util.Mapjava.lang.String,java.lang.String,boolean,java.util.Mapcom.xensource.xenapi.VDI, com.xensource.xenapi.SR ,java.util.Mapcom.xensource.xenapi.VIF,com.xensource.xenapi.Network,java.util.Mapjava.lang.String,java.lang.String) [ERROR] location: class com.xensource.xenapi.VM [ERROR] /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer610Resource.java:[189,30] cannot find symbol [ERROR] symbol : method migrateSendAsync(com.xensource.xenapi.Connection,java.util.Mapjava.lang.String,java.lang.String,boolean,java.util.Mapcom.xensource.xenapi.VDI, com.xensource.xenapi.SR ,java.util.Mapcom.xensource.xenapi.VIF,com.xensource.xenapi.Network,java.util.Mapjava.lang.String,java.lang.String) [ERROR] location: class com.xensource.xenapi.VM [ERROR] /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer610Resource.java:[251,43] cannot find symbol [ERROR] symbol : method
[jira] [Reopened] (CLOUDSTACK-4827) Build failed on 4.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi reopened CLOUDSTACK-4827: This happened again when I was building 4.3 RC build_asf.sh script needs to be fixed Build failed on 4.2 --- Key: CLOUDSTACK-4827 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4827 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Wei Zhou Assignee: Wei Zhou Fix For: 4.2.1 Some guys [1][2] build cloudstack 4.2 source code failed for the following error: [INFO] BUILD FAILURE [INFO] [INFO] Total time: 13:26.004s [INFO] Finished at: Thu Oct 03 10:07:41 CEST 2013 [INFO] Final Memory: 37M/146M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile) on project cloud-plugin-hypervisor-xen: Compilation failure: Compilation failure: [ERROR] /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java:[890,16] cannot find symbol [ERROR] symbol : variable lockingMode [ERROR] location: class com.xensource.xenapi.VIF.Record [ERROR] /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java:[890,36] cannot find symbol [ERROR] symbol : variable VifLockingMode [ERROR] location: class com.xensource.xenapi.Types [ERROR] /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java:[1099,12] cannot find symbol [ERROR] symbol : variable lockingMode [ERROR] location: class com.xensource.xenapi.VIF.Record [ERROR] /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java:[1099,32] cannot find symbol [ERROR] symbol : variable VifLockingMode [ERROR] location: class com.xensource.xenapi.Types [ERROR] /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java:[4869,20] cannot find symbol [ERROR] symbol : variable lockingMode [ERROR] location: class com.xensource.xenapi.VIF.Record [ERROR] /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java:[4869,40] cannot find symbol [ERROR] symbol : variable VifLockingMode [ERROR] location: class com.xensource.xenapi.Types [ERROR] /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer610Resource.java:[160,43] cannot find symbol [ERROR] symbol : method migrateReceive(com.xensource.xenapi.Connection,com.xensource.xenapi.Network,java.util.Mapjava.lang.String,java.lang.String) [ERROR] location: class com.xensource.xenapi.Host [ERROR] /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer610Resource.java:[175,30] cannot find symbol [ERROR] symbol : method assertCanMigrateAsync(com.xensource.xenapi.Connection,java.util.Mapjava.lang.String,java.lang.String,boolean,java.util.Mapcom.xensource.xenapi.VDI, com.xensource.xenapi.SR ,java.util.Mapcom.xensource.xenapi.VIF,com.xensource.xenapi.Network,java.util.Mapjava.lang.String,java.lang.String) [ERROR] location: class com.xensource.xenapi.VM [ERROR] /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer610Resource.java:[189,30] cannot find symbol [ERROR] symbol : method migrateSendAsync(com.xensource.xenapi.Connection,java.util.Mapjava.lang.String,java.lang.String,boolean,java.util.Mapcom.xensource.xenapi.VDI, com.xensource.xenapi.SR ,java.util.Mapcom.xensource.xenapi.VIF,com.xensource.xenapi.Network,java.util.Mapjava.lang.String,java.lang.String) [ERROR] location: class com.xensource.xenapi.VM [ERROR] /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer610Resource.java:[251,43] cannot find symbol [ERROR] symbol : method
[jira] [Commented] (CLOUDSTACK-5614) [UI] improvements for Report Sockets
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878273#comment-13878273 ] Harikrishna Patnala commented on CLOUDSTACK-5614: - Hi, It does not take hypervisorversion parameter in API but in the response we have hypervisorversion using which we can filter from the list. listhostsresponse cloud-stack-version=4.3.0-SNAPSHOT count1/count host ... hypervisorversion6.2.0/hypervisorversion ... -Harikrishna [UI] improvements for Report Sockets Key: CLOUDSTACK-5614 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5614 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: Kiran Koneti Assignee: Jessica Wang Priority: Critical Fix For: 4.3.0 Attachments: InfraTab.jpg, Number_of_sockets.jpg The below mentioned improvements are requested for the report sockets. 1)UI Icon in the infrastructure tab. The current implementation of the Infrastructure tab is attached as screenshot InfraTab.jpg whcih shows that all the other tab links has some image in the box related to it ,So please add some image to the sockets which would make the UI look good. 2)number of sockets in the Sockets tab. The current implementation of number of sockets is attached as the screen shot Number_of_sockets.jpg in which the number of sockets for all the hosts is listed as 0 for the hosts which are not added and also not supported.in th egiven screenshot you can see the number of hypervisor hosts are 2 and the sockets number is 0.It is listed so because the number of sockets for the hyper-V is not yet implemented.So the number of sockets should be either N/A of just -(hyphen) for the hypervisors which we doesn't support. 3)Seperate List should be maintained for Xenserver 6.2 version and versions prior to that. We support the Report sockets only for the Xen 6.2 version and not for the versions prior to that.So we have to have 2 columns one for Xenserver 6.2 for which we can list number of hosts and number of sockets and other one saying just Xenserver where we report only the number of hosts and the number of sockets should be either N/A or -(hyphen). 4)Report the socket information in the Host information UI also. When we navigate to the Infrastructure--Hosts --(hostname/IP) for the host details we don't have a UI column for the Number of sockets this info is displayed in the API output ,So fetch the data fro the api and display it in the UI. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-5924) noticed qemu error in the logs during vms rules cleanup
sadhu suresh created CLOUDSTACK-5924:
Summary: noticed qemu error in the logs during vms rules cleanup
Key: CLOUDSTACK-5924
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5924
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: KVM
Affects Versions: 4.3.0
Reporter: sadhu suresh
Assignee: Jayapal Reddy
Priority: Minor
noticed below errors in the host logs during vms rules cleanup
steps:
put host in maintenance mode
check the host logs
Received response: Seq 4-1355: { Ans: , MgmtId: 7322717913215, via: 4, Ver:
v1, Flags: 100010,
[{com.cloud.agent.api.PingAnswer:{_command:{hostType:Routing,hostId:4,wait:0},result:true,wait:0}}]
}
2014-01-21 07:20:04,268 DEBUG [kvm.resource.KVMHAMonitor] (Thread-1355:null)
Found NFS storage pool 81c8c822-016d-374f-b44b-18d84ba54499 in libvirt,
continuing
2014-01-21 07:20:04,269 DEBUG [kvm.resource.KVMHAMonitor] (Thread-1355:null)
Executing:
/usr/share/cloudstack-common/scripts/vm/hypervisor/kvm/kvmheartbeat.sh -i
10.147.28.7 -p /export/home/sadhu/felton/primtest -m
/mnt/81c8c822-016d-374f-b44b-18d84ba54499 -h 10.147.40.26
2014-01-21 07:20:04,287 DEBUG [kvm.resource.KVMHAMonitor] (Thread-1355:null)
Execution is successful.
2014-01-21 07:20:22,428 DEBUG [kvm.resource.LibvirtComputingResource]
(Agent-Handler-3:null) Executing:
/usr/share/cloudstack-common/scripts/vm/network/security_group.py cleanup_rules
2014-01-21 07:20:24,984 DEBUG [kvm.resource.LibvirtComputingResource]
(Agent-Handler-3:null) Execution is successful.
2014-01-21 07:20:24,985 DEBUG [kvm.resource.LibvirtComputingResource]
(Agent-Handler-3:null) libvir: QEMU error : Domain not found: no domain with
matching name 'i-2-10-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-2-10-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-2-8-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-2-8-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-3-3-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-3-3-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-2-7-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-2-7-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-2-9-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-2-9-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-5-13-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-5-13-VM-ips'
2014-01-21 07:20:24,986 DEBUG [cloud.agent.Agent] (Agent-Handler-3:null) Watch
Sent: Seq 4-329908226: { Ans: , MgmtId: 7322717913215, via: 4, Ver: v1, Flags:
10, [{com.cloud.agent.api.Answer:{result:true,details:,wait:0}}] }
2014-01-21 07:21:01,715 DEBUG [kvm.resource.LibvirtComputingResource]
(UgentTask-5:null) Executing:
/usr/share/cloudstack-common/scripts/vm/network/security_group.py
get_rule_logs_for_vms
2014-01-21 07:21:01,973 DEBUG [cloud.agent.Agent] (agentRequest-Handler-3:null)
Processing command: com.cloud.agent.api.GetVmStatsCommand
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Reopened] (CLOUDSTACK-5614) [UI] improvements for Report Sockets
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kiran Koneti reopened CLOUDSTACK-5614: -- reopening this as per Hari's comments for the Xenserver issue as it would be misleading the customer if socket count and host count doesn't match for the Xenserver case. [UI] improvements for Report Sockets Key: CLOUDSTACK-5614 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5614 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: Kiran Koneti Assignee: Jessica Wang Priority: Critical Fix For: 4.3.0 Attachments: InfraTab.jpg, Number_of_sockets.jpg The below mentioned improvements are requested for the report sockets. 1)UI Icon in the infrastructure tab. The current implementation of the Infrastructure tab is attached as screenshot InfraTab.jpg whcih shows that all the other tab links has some image in the box related to it ,So please add some image to the sockets which would make the UI look good. 2)number of sockets in the Sockets tab. The current implementation of number of sockets is attached as the screen shot Number_of_sockets.jpg in which the number of sockets for all the hosts is listed as 0 for the hosts which are not added and also not supported.in th egiven screenshot you can see the number of hypervisor hosts are 2 and the sockets number is 0.It is listed so because the number of sockets for the hyper-V is not yet implemented.So the number of sockets should be either N/A of just -(hyphen) for the hypervisors which we doesn't support. 3)Seperate List should be maintained for Xenserver 6.2 version and versions prior to that. We support the Report sockets only for the Xen 6.2 version and not for the versions prior to that.So we have to have 2 columns one for Xenserver 6.2 for which we can list number of hosts and number of sockets and other one saying just Xenserver where we report only the number of hosts and the number of sockets should be either N/A or -(hyphen). 4)Report the socket information in the Host information UI also. When we navigate to the Infrastructure--Hosts --(hostname/IP) for the host details we don't have a UI column for the Number of sockets this info is displayed in the API output ,So fetch the data fro the api and display it in the UI. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5924) noticed qemu error in the logs during vms rules cleanup
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878291#comment-13878291
]
ASF subversion and git services commented on CLOUDSTACK-5924:
-
Commit 86124138a1a9129dedaf0f73fcd570156bfe53f6 in branch refs/heads/master
from [~jayapal]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8612413 ]
CLOUDSTACK-5924: Correcting regex to get vm names exactly from ebtables chains
noticed qemu error in the logs during vms rules cleanup
---
Key: CLOUDSTACK-5924
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5924
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: 4.3.0
Reporter: sadhu suresh
Assignee: Jayapal Reddy
Priority: Minor
noticed below errors in the host logs during vms rules cleanup
steps:
put host in maintenance mode
check the host logs
Received response: Seq 4-1355: { Ans: , MgmtId: 7322717913215, via: 4, Ver:
v1, Flags: 100010,
[{com.cloud.agent.api.PingAnswer:{_command:{hostType:Routing,hostId:4,wait:0},result:true,wait:0}}]
}
2014-01-21 07:20:04,268 DEBUG [kvm.resource.KVMHAMonitor] (Thread-1355:null)
Found NFS storage pool 81c8c822-016d-374f-b44b-18d84ba54499 in libvirt,
continuing
2014-01-21 07:20:04,269 DEBUG [kvm.resource.KVMHAMonitor] (Thread-1355:null)
Executing:
/usr/share/cloudstack-common/scripts/vm/hypervisor/kvm/kvmheartbeat.sh -i
10.147.28.7 -p /export/home/sadhu/felton/primtest -m
/mnt/81c8c822-016d-374f-b44b-18d84ba54499 -h 10.147.40.26
2014-01-21 07:20:04,287 DEBUG [kvm.resource.KVMHAMonitor] (Thread-1355:null)
Execution is successful.
2014-01-21 07:20:22,428 DEBUG [kvm.resource.LibvirtComputingResource]
(Agent-Handler-3:null) Executing:
/usr/share/cloudstack-common/scripts/vm/network/security_group.py
cleanup_rules
2014-01-21 07:20:24,984 DEBUG [kvm.resource.LibvirtComputingResource]
(Agent-Handler-3:null) Execution is successful.
2014-01-21 07:20:24,985 DEBUG [kvm.resource.LibvirtComputingResource]
(Agent-Handler-3:null) libvir: QEMU error : Domain not found: no domain with
matching name 'i-2-10-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-2-10-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-2-8-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-2-8-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-3-3-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-3-3-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-2-7-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-2-7-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-2-9-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-2-9-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-5-13-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-5-13-VM-ips'
2014-01-21 07:20:24,986 DEBUG [cloud.agent.Agent] (Agent-Handler-3:null)
Watch Sent: Seq 4-329908226: { Ans: , MgmtId: 7322717913215, via: 4, Ver:
v1, Flags: 10,
[{com.cloud.agent.api.Answer:{result:true,details:,wait:0}}] }
2014-01-21 07:21:01,715 DEBUG [kvm.resource.LibvirtComputingResource]
(UgentTask-5:null) Executing:
/usr/share/cloudstack-common/scripts/vm/network/security_group.py
get_rule_logs_for_vms
2014-01-21 07:21:01,973 DEBUG [cloud.agent.Agent]
(agentRequest-Handler-3:null) Processing command:
com.cloud.agent.api.GetVmStatsCommand
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5924) noticed qemu error in the logs during vms rules cleanup
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878296#comment-13878296
]
ASF subversion and git services commented on CLOUDSTACK-5924:
-
Commit 2f2a2dcd4656b49da33b884af6f1f8918d1354f3 in branch refs/heads/4.3 from
[~jayapal]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2f2a2dc ]
CLOUDSTACK-5924: updating regex to get vm names exactly from ebtables chains
noticed qemu error in the logs during vms rules cleanup
---
Key: CLOUDSTACK-5924
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5924
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: 4.3.0
Reporter: sadhu suresh
Assignee: Jayapal Reddy
Priority: Minor
noticed below errors in the host logs during vms rules cleanup
steps:
put host in maintenance mode
check the host logs
Received response: Seq 4-1355: { Ans: , MgmtId: 7322717913215, via: 4, Ver:
v1, Flags: 100010,
[{com.cloud.agent.api.PingAnswer:{_command:{hostType:Routing,hostId:4,wait:0},result:true,wait:0}}]
}
2014-01-21 07:20:04,268 DEBUG [kvm.resource.KVMHAMonitor] (Thread-1355:null)
Found NFS storage pool 81c8c822-016d-374f-b44b-18d84ba54499 in libvirt,
continuing
2014-01-21 07:20:04,269 DEBUG [kvm.resource.KVMHAMonitor] (Thread-1355:null)
Executing:
/usr/share/cloudstack-common/scripts/vm/hypervisor/kvm/kvmheartbeat.sh -i
10.147.28.7 -p /export/home/sadhu/felton/primtest -m
/mnt/81c8c822-016d-374f-b44b-18d84ba54499 -h 10.147.40.26
2014-01-21 07:20:04,287 DEBUG [kvm.resource.KVMHAMonitor] (Thread-1355:null)
Execution is successful.
2014-01-21 07:20:22,428 DEBUG [kvm.resource.LibvirtComputingResource]
(Agent-Handler-3:null) Executing:
/usr/share/cloudstack-common/scripts/vm/network/security_group.py
cleanup_rules
2014-01-21 07:20:24,984 DEBUG [kvm.resource.LibvirtComputingResource]
(Agent-Handler-3:null) Execution is successful.
2014-01-21 07:20:24,985 DEBUG [kvm.resource.LibvirtComputingResource]
(Agent-Handler-3:null) libvir: QEMU error : Domain not found: no domain with
matching name 'i-2-10-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-2-10-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-2-8-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-2-8-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-3-3-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-3-3-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-2-7-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-2-7-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-2-9-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-2-9-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-5-13-VM-ips'
libvir: QEMU error : Domain not found: no domain with matching name
'i-5-13-VM-ips'
2014-01-21 07:20:24,986 DEBUG [cloud.agent.Agent] (Agent-Handler-3:null)
Watch Sent: Seq 4-329908226: { Ans: , MgmtId: 7322717913215, via: 4, Ver:
v1, Flags: 10,
[{com.cloud.agent.api.Answer:{result:true,details:,wait:0}}] }
2014-01-21 07:21:01,715 DEBUG [kvm.resource.LibvirtComputingResource]
(UgentTask-5:null) Executing:
/usr/share/cloudstack-common/scripts/vm/network/security_group.py
get_rule_logs_for_vms
2014-01-21 07:21:01,973 DEBUG [cloud.agent.Agent]
(agentRequest-Handler-3:null) Processing command:
com.cloud.agent.api.GetVmStatsCommand
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5435) ldap params are not encrypted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kiran Koneti closed CLOUDSTACK-5435. The params are encrypted in the latest 4.3 hence closing the defect. ldap params are not encrypted - Key: CLOUDSTACK-5435 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5435 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Rajani Karuturi Assignee: Rajani Karuturi Priority: Critical Labels: ldap Fix For: Future, 4.3.0 ldap global params in configuration table are not encrypted. These were encrypted in 4.2 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-5925) [Automation] Testsuites changes for multiple regression runs on single CS server
Girish Shilamkar created CLOUDSTACK-5925: Summary: [Automation] Testsuites changes for multiple regression runs on single CS server Key: CLOUDSTACK-5925 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5925 Project: CloudStack Issue Type: Sub-task Security Level: Public (Anyone can view this level - this is the default.) Reporter: Girish Shilamkar Assignee: Girish Shilamkar This tasks involves two things: 1. Test data will moved from services class to config dir 2. Update get_zone, get_template functionalities as per changed marvin. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5925) [Automation] Testsuites changes for multiple regression runs on single CS server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878336#comment-13878336 ] ASF subversion and git services commented on CLOUDSTACK-5925: - Commit 6a2cc9fbd0e2943132d3c8b8f729d8470331dc20 in branch refs/heads/marvin from [~gpshilamkar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6a2cc9f ] CLOUDSTACK-5925: Moved test data from testsuites to marvin/config Also merged redundant testdata as they were found. [Automation] Testsuites changes for multiple regression runs on single CS server Key: CLOUDSTACK-5925 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5925 Project: CloudStack Issue Type: Sub-task Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, marvin Reporter: Girish Shilamkar Assignee: Girish Shilamkar This tasks involves two things: 1. Test data will moved from services class to config dir 2. Update get_zone, get_template functionalities as per changed marvin. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5674) [Automation]: Enhancements to accommodate multiple regression runs on a single CS server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878334#comment-13878334 ] ASF subversion and git services commented on CLOUDSTACK-5674: - Commit 939327561192eba7f21f6d5acb0119278984b510 in branch refs/heads/marvin from [~santhoshe] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9393275 ] CLOUDSTACK-5674: Added Fix for CLOUDSTACK-5674,5498,5500 and other issues as part of cleanup [Automation]: Enhancements to accommodate multiple regression runs on a single CS server Key: CLOUDSTACK-5674 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5674 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, marvin Reporter: Santhosh Kumar Edukulla Assignee: Santhosh Kumar Edukulla 1. Currently, we will not be able to run multiple regression runs on a given CS server either sequentially\parallelly reason being few hard codings done at various places. 2. So, the idea is to run complete regression\automation test suites at one stretch on a given setup post deployDC. 3. The fixes and new changes should incorporate to take care to run suites parallelly if we wanted or sequentially for various test suites like vmware,xen,kvm etc on single CS machine without disturbing\redeploying and installing the new CS instance. Phase1: We will make framework\marvin changes. Phase2: Incorporate test module changes for these. Adding this ticket to track these changes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5674) [Automation]: Enhancements to accommodate multiple regression runs on a single CS server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878335#comment-13878335 ] ASF subversion and git services commented on CLOUDSTACK-5674: - Commit 939327561192eba7f21f6d5acb0119278984b510 in branch refs/heads/marvin from [~santhoshe] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9393275 ] CLOUDSTACK-5674: Added Fix for CLOUDSTACK-5674,5498,5500 and other issues as part of cleanup [Automation]: Enhancements to accommodate multiple regression runs on a single CS server Key: CLOUDSTACK-5674 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5674 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, marvin Reporter: Santhosh Kumar Edukulla Assignee: Santhosh Kumar Edukulla 1. Currently, we will not be able to run multiple regression runs on a given CS server either sequentially\parallelly reason being few hard codings done at various places. 2. So, the idea is to run complete regression\automation test suites at one stretch on a given setup post deployDC. 3. The fixes and new changes should incorporate to take care to run suites parallelly if we wanted or sequentially for various test suites like vmware,xen,kvm etc on single CS machine without disturbing\redeploying and installing the new CS instance. Phase1: We will make framework\marvin changes. Phase2: Incorporate test module changes for these. Adding this ticket to track these changes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5925) [Automation] Testsuites changes for multiple regression runs on single CS server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878351#comment-13878351 ] Girish Shilamkar commented on CLOUDSTACK-5925: -- Change to move test data into marvin/config committed. [Automation] Testsuites changes for multiple regression runs on single CS server Key: CLOUDSTACK-5925 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5925 Project: CloudStack Issue Type: Sub-task Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, marvin Reporter: Girish Shilamkar Assignee: Girish Shilamkar This tasks involves two things: 1. Test data will moved from services class to config dir 2. Update get_zone, get_template functionalities as per changed marvin. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5883) unable to copy vmware routing template to primary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13878361#comment-13878361 ] praveena palaniswamy commented on CLOUDSTACK-5883: -- I am working with the latest code base (4.3) with Vmware Vsphere 5.1 and 5.5 and in both environments, I face the same error even after using the latest template from jenkins server parsing HTTP request for method importVApp on object of type vim.ResourcePool at line 1, column 0 at com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) at com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:129) at com.sun.proxy.$Proxy390.importVApp(Unknown Source) at com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.importVmFromOVF(HypervisorHostHelper.java:1336) at com.cloud.hypervisor.vmware.mo.HostMO.importVmFromOVF(HostMO.java:752) at com.cloud.storage.resource.VmwareStorageProcessor.copyTemplateFromSecondaryToPrimary(VmwareStorageProcessor.java:161) at com.cloud.storage.resource.VmwareStorageProcessor.copyTemplateToPrimaryStorage(VmwareStorageProcessor.java:221) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:75) at com.cloud.storage.resource.VmwareStorageSubsystemCommandHandler.execute(VmwareStorageSubsystemCommandHandler.java:160) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:50) at com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:550) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) INFO [o.a.c.s.v.VolumeServiceImpl] (secstorage-1:ctx-a74d3356) releasing lock for VMTemplateStoragePool 8 WARN [c.c.u.d.Merovingian2] (secstorage-1:ctx-a74d3356) Was unable to find lock for the key template_spool_ref8 and thread id 1940175072 INFO [c.c.v.VirtualMachineManagerImpl] (secstorage-1:ctx-a74d3356) Unable to contact resource. com.cloud.exception.StorageUnavailableException: Resource [StoragePool:1] is unreachable: Unable to create Vol[4|vm=4|ROOT]:Unable to copy template to primary storage due to exception:Exception: javax.xml.ws.soap.SOAPFaultException Message: Required parameter spec is missing while parsing call information for method ImportVApp at line 1, column 110 while parsing SOAP body at line 1, column 102 while parsing SOAP envelope at line 1, column 38 while parsing HTTP request for method importVApp on object of type vim.ResourcePool at line 1, column 0 at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.recreateVolume(VolumeOrchestrator.java:1193) at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.prepare(VolumeOrchestrator.java:1245) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:962) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:745) at
