[jira] [Closed] (CLOUDSTACK-5720) [upgrad]Live migration is failing ;java.lang.NullPointerException
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
prashant kumar mishra closed CLOUDSTACK-5720.
-
[upgrad]Live migration is failing ;java.lang.NullPointerException
-
Key: CLOUDSTACK-5720
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5720
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.3.0
Environment: hyp:xen6.2
Reporter: prashant kumar mishra
Assignee: Kelven Yang
Priority: Critical
Fix For: 4.3.0
Attachments: Logs_DB.rar
STEPS TO REPO
==
1-prepare a ACS 4.2 setup +two xen6.2 host in a cluster
2-deploy some vms
3-upgrade it to 4.3
4-try to migrate
EXPECTED
===
Migration should be successful
ACTUAL
===
Migration is failing because NPE
LOG
014-01-02 12:04:43,865 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(AsyncJobMgr-Heartbeat-1:ctx-e8b68d56) Schedule queued job-47
2014-01-02 12:04:43,880 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Job-Executor-14:ctx-ad5bbb25) Add job-47 into job monitoring
2014-01-02 12:04:43,882 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-14:ctx-ad5bbb25) Executing AsyncJobVO {id:47, userId: 2,
accountId: 2, instanceType: null, instanceId: null, cmd:
com.cloud.vm.VmWorkMigrate, cmdInfo:
rO0ABXNyABpjb20uY2xvdWQudm0uVm1Xb3JrTWlncmF0ZRdxQXtPtzYqAgAGSgAJc3JjSG9zdElkTAAJY2x1c3RlcklkdAAQTGphdmEvbGFuZy9Mb25nO0wABmhvc3RJZHEAfgABTAAFcG9kSWRxAH4AAUwAB3N0b3JhZ2V0AA9MamF2YS91dGlsL01hcDtMAAZ6b25lSWRxAH4AAXhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIABXQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAXNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAXNxAH4ABwAEcQB-AAlwcQB-AAk,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 7145449848920, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Thu Jan 02 12:04:42 EST 2014}
2014-01-02 12:04:43,882 DEBUG [c.c.v.VmWorkJobDispatcher]
(Job-Executor-14:ctx-ad5bbb25) Run VM work job: com.cloud.vm.VmWorkMigrate
2014-01-02 12:04:43,886 DEBUG [c.c.v.VmWorkJobHandlerProxy]
(Job-Executor-14:ctx-ad5bbb25 ctx-2899d402) Execute VM work job:
com.cloud.vm.VmWorkMigrate{zoneId:1,podId:1,clusterId:1,hostId:4,srcHostId:1,userId:2,accountId:2,vmId:5,handlerName:VirtualMachineManagerImpl}
2014-01-02 12:04:43,890 ERROR [c.c.v.VmWorkJobHandlerProxy]
(Job-Executor-14:ctx-ad5bbb25 ctx-2899d402) Invocation exception, caused by:
java.lang.NullPointerException
2014-01-02 12:04:43,891 ERROR [c.c.v.VmWorkJobDispatcher]
(Job-Executor-14:ctx-ad5bbb25 ctx-2899d402) Unable to complete AsyncJobVO
{id:47, userId: 2, accountId: 2, instanceType: null, instanceId: null, cmd:
com.cloud.vm.VmWorkMigrate, cmdInfo:
rO0ABXNyABpjb20uY2xvdWQudm0uVm1Xb3JrTWlncmF0ZRdxQXtPtzYqAgAGSgAJc3JjSG9zdElkTAAJY2x1c3RlcklkdAAQTGphdmEvbGFuZy9Mb25nO0wABmhvc3RJZHEAfgABTAAFcG9kSWRxAH4AAUwAB3N0b3JhZ2V0AA9MamF2YS91dGlsL01hcDtMAAZ6b25lSWRxAH4AAXhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIABXQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAXNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAXNxAH4ABwAEcQB-AAlwcQB-AAk,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 7145449848920, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Thu Jan 02 12:04:42 EST 2014}
java.lang.NullPointerException
at
com.cloud.vm.VmWorkMigrate.getDeployDestination(VmWorkMigrate.java:60)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrate(VirtualMachineManagerImpl.java:4758)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4855)
at
com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:99)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:522)
at
[jira] [Commented] (CLOUDSTACK-5720) [upgrad]Live migration is failing ;java.lang.NullPointerException
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896316#comment-13896316
]
prashant kumar mishra commented on CLOUDSTACK-5720:
---
since it is a duplicate issue closing it .
[upgrad]Live migration is failing ;java.lang.NullPointerException
-
Key: CLOUDSTACK-5720
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5720
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.3.0
Environment: hyp:xen6.2
Reporter: prashant kumar mishra
Assignee: Kelven Yang
Priority: Critical
Fix For: 4.3.0
Attachments: Logs_DB.rar
STEPS TO REPO
==
1-prepare a ACS 4.2 setup +two xen6.2 host in a cluster
2-deploy some vms
3-upgrade it to 4.3
4-try to migrate
EXPECTED
===
Migration should be successful
ACTUAL
===
Migration is failing because NPE
LOG
014-01-02 12:04:43,865 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(AsyncJobMgr-Heartbeat-1:ctx-e8b68d56) Schedule queued job-47
2014-01-02 12:04:43,880 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Job-Executor-14:ctx-ad5bbb25) Add job-47 into job monitoring
2014-01-02 12:04:43,882 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-14:ctx-ad5bbb25) Executing AsyncJobVO {id:47, userId: 2,
accountId: 2, instanceType: null, instanceId: null, cmd:
com.cloud.vm.VmWorkMigrate, cmdInfo:
rO0ABXNyABpjb20uY2xvdWQudm0uVm1Xb3JrTWlncmF0ZRdxQXtPtzYqAgAGSgAJc3JjSG9zdElkTAAJY2x1c3RlcklkdAAQTGphdmEvbGFuZy9Mb25nO0wABmhvc3RJZHEAfgABTAAFcG9kSWRxAH4AAUwAB3N0b3JhZ2V0AA9MamF2YS91dGlsL01hcDtMAAZ6b25lSWRxAH4AAXhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIABXQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAXNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAXNxAH4ABwAEcQB-AAlwcQB-AAk,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 7145449848920, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Thu Jan 02 12:04:42 EST 2014}
2014-01-02 12:04:43,882 DEBUG [c.c.v.VmWorkJobDispatcher]
(Job-Executor-14:ctx-ad5bbb25) Run VM work job: com.cloud.vm.VmWorkMigrate
2014-01-02 12:04:43,886 DEBUG [c.c.v.VmWorkJobHandlerProxy]
(Job-Executor-14:ctx-ad5bbb25 ctx-2899d402) Execute VM work job:
com.cloud.vm.VmWorkMigrate{zoneId:1,podId:1,clusterId:1,hostId:4,srcHostId:1,userId:2,accountId:2,vmId:5,handlerName:VirtualMachineManagerImpl}
2014-01-02 12:04:43,890 ERROR [c.c.v.VmWorkJobHandlerProxy]
(Job-Executor-14:ctx-ad5bbb25 ctx-2899d402) Invocation exception, caused by:
java.lang.NullPointerException
2014-01-02 12:04:43,891 ERROR [c.c.v.VmWorkJobDispatcher]
(Job-Executor-14:ctx-ad5bbb25 ctx-2899d402) Unable to complete AsyncJobVO
{id:47, userId: 2, accountId: 2, instanceType: null, instanceId: null, cmd:
com.cloud.vm.VmWorkMigrate, cmdInfo:
rO0ABXNyABpjb20uY2xvdWQudm0uVm1Xb3JrTWlncmF0ZRdxQXtPtzYqAgAGSgAJc3JjSG9zdElkTAAJY2x1c3RlcklkdAAQTGphdmEvbGFuZy9Mb25nO0wABmhvc3RJZHEAfgABTAAFcG9kSWRxAH4AAUwAB3N0b3JhZ2V0AA9MamF2YS91dGlsL01hcDtMAAZ6b25lSWRxAH4AAXhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIABXQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAXNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAXNxAH4ABwAEcQB-AAlwcQB-AAk,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 7145449848920, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Thu Jan 02 12:04:42 EST 2014}
java.lang.NullPointerException
at
com.cloud.vm.VmWorkMigrate.getDeployDestination(VmWorkMigrate.java:60)
at
com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrate(VirtualMachineManagerImpl.java:4758)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4855)
at
com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:99)
at
[jira] [Closed] (CLOUDSTACK-5361) Require UI changes,currently UI is not supporting custom system service offerings
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra closed CLOUDSTACK-5361. - Require UI changes,currently UI is not supporting custom system service offerings -- Key: CLOUDSTACK-5361 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5361 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: prashant kumar mishra Assignee: Jessica Wang Attachments: screenshot-1.jpg, screenshot-2.jpg Steps to reproduce 1-try to create a custom system service offering Expected AS we have custom check box for compute offering , we should have same for system SO Actual - There are no custom check box -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (CLOUDSTACK-5361) Require UI changes,currently UI is not supporting custom system service offerings
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896319#comment-13896319 ] prashant kumar mishra edited comment on CLOUDSTACK-5361 at 2/10/14 8:42 AM: as per Jessca's comment this feature is not supported for system vms so no need for UI changes , closing it was (Author: prashantkm): as per Jessca comment this feature is not supported for system vms so need for UI changes , closing it Require UI changes,currently UI is not supporting custom system service offerings -- Key: CLOUDSTACK-5361 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5361 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: prashant kumar mishra Assignee: Jessica Wang Attachments: screenshot-1.jpg, screenshot-2.jpg Steps to reproduce 1-try to create a custom system service offering Expected AS we have custom check box for compute offering , we should have same for system SO Actual - There are no custom check box -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5361) Require UI changes,currently UI is not supporting custom system service offerings
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896319#comment-13896319 ] prashant kumar mishra commented on CLOUDSTACK-5361: --- as per Jessca comment this feature is not supported for system vms so need for UI changes , closing it Require UI changes,currently UI is not supporting custom system service offerings -- Key: CLOUDSTACK-5361 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5361 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: prashant kumar mishra Assignee: Jessica Wang Attachments: screenshot-1.jpg, screenshot-2.jpg Steps to reproduce 1-try to create a custom system service offering Expected AS we have custom check box for compute offering , we should have same for system SO Actual - There are no custom check box -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-4137) KVM: After unmanaging cluster, manage cluster will not bring KVM hosts to UP state. cloud-agent on KVM hosts has to be restarted manually
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
prashant kumar mishra closed CLOUDSTACK-4137.
-
KVM: After unmanaging cluster, manage cluster will not bring KVM hosts to UP
state. cloud-agent on KVM hosts has to be restarted manually
-
Key: CLOUDSTACK-4137
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4137
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: 4.2.0
Environment: hypervisor : KVM
Reporter: prashant kumar mishra
Assignee: Kishan Kavala
Priority: Critical
Labels: ReleaseNote
Fix For: 4.2.1
Attachments: Logs_DB_Agent.rar
Steps to reproduce
---
1-prepare a CS -one cluster--one kvm(rhel6.3)
2-unmanage cluster
3-manage cluster
Expected
--
Host should come up , in running state
Actual
--
Host remain in Disconnect state
My observation
---
1-after host went in disconnect state i performed host maintenance mode
then cancel maintenance mode and host came up
2-restart cloud-agent on the kvm hosts bring the hosts to UP state
Logs:
--
2013-08-07 20:14:16,999 DEBUG [cloud.api.ApiServlet] (catalina-exec-23:null)
===START=== 10.252.192.53 -- GET
command=updateClusterid=854b547a-fbee-4eed-895d-b8ea96d1cc23managedstate=Unmanagedresponse=jsonsessionkey=vOfsgLOiksyXg%2B23XuFp6maNm1I%3D_=1375867173396
2013-08-07 20:14:17,031 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-2042691611: Sending { Cmd , MgmtId:
6703101771911, via: 1, Ver: v1, Flags: 100111,
[{com.cloud.agent.api.MaintainCommand:{wait:0}}] }
2013-08-07 20:14:17,038 DEBUG [agent.transport.Request]
(AgentManager-Handler-7:null) Seq 1-2042691611: Processing: { Ans: , MgmtId:
6703101771911, via: 1, Ver: v1, Flags: 110,
[{com.cloud.agent.api.MaintainAnswer:{willMigrate:true,result:true,wait:0}}]
}
2013-08-07 20:14:17,038 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-7:null) Seq 1-2042691611: No more commands found
2013-08-07 20:14:17,038 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-2042691611: Received: { Ans: , MgmtId:
6703101771911, via: 1, Ver: v1, Flags: 110, { MaintainAnswer } }
2013-08-07 20:14:17,039 INFO [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Host 1 is disconnecting with event ShutdownRequested
2013-08-07 20:14:17,051 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) The next status of agent 1is Disconnected, current
status is Up
2013-08-07 20:14:17,051 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Deregistering link for 1 with state Disconnected
2013-08-07 20:14:17,051 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Remove Agent : 1
2013-08-07 20:14:17,052 DEBUG [agent.manager.ConnectedAgentAttache]
(AgentTaskPool-4:null) Processing Disconnect.
2013-08-07 20:14:17,052 DEBUG [agent.manager.AgentAttache]
(AgentTaskPool-4:null) Seq 1-2042691586: Sending disconnect to class
com.cloud.network.security.SecurityGroupListener
2013-08-07 20:14:17,052 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.hypervisor.xen.discoverer.XcpServerDiscoverer_EnhancerByCloudStack_eccb8bca
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.deploy.DeploymentPlanningManagerImpl_EnhancerByCloudStack_b3901640
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.network.NetworkManagerImpl_EnhancerByCloudStack_c52127d3
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.storage.secondary.SecondaryStorageListener
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.hypervisor.vmware.manager.VmwareManagerImpl_EnhancerByCloudStack_5c9626cd
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.network.security.SecurityGroupListener
2013-08-07 20:14:17,053 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
com.cloud.storage.listener.StoragePoolMonitor
2013-08-07 20:14:17,054 DEBUG [agent.manager.AgentManagerImpl]
(AgentTaskPool-4:null) Sending Disconnect to listener:
[jira] [Commented] (CLOUDSTACK-6040) Failed to configure PF on vm secondary ip for shared network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896334#comment-13896334 ] ASF subversion and git services commented on CLOUDSTACK-6040: - Commit 37c4015d4dd3786496331db44cf65b12df9d50f2 in branch refs/heads/master from [~jayapal] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=37c4015 ] CLOUDSTACK-6040: Updated the ip addr validation in create port forwarding Failed to configure PF on vm secondary ip for shared network Key: CLOUDSTACK-6040 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6040 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.1 Reporter: Jayapal Reddy Assignee: Jayapal Reddy Priority: Critical Fix For: 4.3.0 Configuring PF on vm secondary ip failed for shared network with ip range 192.168.x.x -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-6040) Failed to configure PF on vm secondary ip for shared network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayapal Reddy resolved CLOUDSTACK-6040. --- Resolution: Fixed Failed to configure PF on vm secondary ip for shared network Key: CLOUDSTACK-6040 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6040 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.1 Reporter: Jayapal Reddy Assignee: Jayapal Reddy Priority: Critical Fix For: 4.3.0 Configuring PF on vm secondary ip failed for shared network with ip range 192.168.x.x -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5877) listTemplates does not sort based on sort_key
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kiran Koneti closed CLOUDSTACK-5877. Verified this in the latest 4.3 Build hence closing the defect listTemplates does not sort based on sort_key - Key: CLOUDSTACK-5877 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5877 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.0 Reporter: Min Chen Assignee: Min Chen Fix For: 4.3.0 Login to UI Click on template tab and sort the templates Try to filter the templates. The changes will not be saved as modified earlier. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5967) Virtual router in OVS network fails to start with error from XenServer: VM_REQUIRES_NETWORK
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Murali Reddy resolved CLOUDSTACK-5967.
--
Resolution: Fixed
Commit, fixes two aspects.
- Ignore exception caused on VIF.Plug into Dom0.
- introduce OVS as provider for 'Connectivity' service
Virtual router in OVS network fails to start with error from XenServer:
VM_REQUIRES_NETWORK
---
Key: CLOUDSTACK-5967
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5967
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.3.0
Environment: CloudStack 4.3 with XenServer 6.2
GRE tunnel based advanced network
Reporter: Paul Angus
Assignee: Murali Reddy
Priority: Blocker
Fix For: 4.3.0
Virtual Router start fails with error VM_REQUIRES_NETWORK when using GRE
tunnel encapsulation.
Tunnel is created on XenServer (OVSTunnel194)
virtual router appears briefly then dissappears and insufficient capacity
error is returned by cloudstack
2014-01-28 16:17:09,829 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Job-Executor-12:ctx-3a256248 ctx-58300764) Creating monitoring services on
VM[DomainRouter|r-12-VM] start...
2014-01-28 16:17:09,842 DEBUG [c.c.a.t.Request] (Job-Executor-12:ctx-3a256248
ctx-58300764) Seq 2-232063002: Sending { Cmd , MgmtId: 345049362040, via:
2(localhost.localdomain), Ver: v1, Flags: 100011,
[{com.cloud.agent.api.StartCommand:{vm:{id:12,name:r-12-VM,bootloader:PyGrub,type:DomainRouter,cpus:1,minSpeed:125,maxSpeed:500,minRam:134217728,maxRam:134217728,arch:x86_64,os:Debian
GNU/Linux 7(32-bit),bootArgs: template=domP name=r-12-VM
eth2ip=192.168.1.53 eth2mask=255.255.255.0 gateway=192.168.1.254
eth0ip=10.1.1.1 eth0mask=255.255.255.0 domain=cs2cloud.internal
dhcprange=10.1.1.1 eth1ip=169.254.0.255 eth1mask=255.255.0.0 type=router
disable_rp_filter=true
[jira] [Commented] (CLOUDSTACK-5967) Virtual router in OVS network fails to start with error from XenServer: VM_REQUIRES_NETWORK
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896390#comment-13896390
]
Paul Angus commented on CLOUDSTACK-5967:
Is this in RC4?
Regards,
Paul Angus
Cloud Architect
S: +44 20 3603 0540 | M: +447711418784 | T: @CloudyAngus
paul.an...@shapeblue.com
Virtual router in OVS network fails to start with error from XenServer:
VM_REQUIRES_NETWORK
---
Key: CLOUDSTACK-5967
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5967
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Network Controller
Affects Versions: 4.3.0
Environment: CloudStack 4.3 with XenServer 6.2
GRE tunnel based advanced network
Reporter: Paul Angus
Assignee: Murali Reddy
Priority: Blocker
Fix For: 4.3.0
Virtual Router start fails with error VM_REQUIRES_NETWORK when using GRE
tunnel encapsulation.
Tunnel is created on XenServer (OVSTunnel194)
virtual router appears briefly then dissappears and insufficient capacity
error is returned by cloudstack
2014-01-28 16:17:09,829 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(Job-Executor-12:ctx-3a256248 ctx-58300764) Creating monitoring services on
VM[DomainRouter|r-12-VM] start...
2014-01-28 16:17:09,842 DEBUG [c.c.a.t.Request] (Job-Executor-12:ctx-3a256248
ctx-58300764) Seq 2-232063002: Sending { Cmd , MgmtId: 345049362040, via:
2(localhost.localdomain), Ver: v1, Flags: 100011,
[{com.cloud.agent.api.StartCommand:{vm:{id:12,name:r-12-VM,bootloader:PyGrub,type:DomainRouter,cpus:1,minSpeed:125,maxSpeed:500,minRam:134217728,maxRam:134217728,arch:x86_64,os:Debian
GNU/Linux 7(32-bit),bootArgs: template=domP name=r-12-VM
eth2ip=192.168.1.53 eth2mask=255.255.255.0 gateway=192.168.1.254
eth0ip=10.1.1.1 eth0mask=255.255.255.0 domain=cs2cloud.internal
dhcprange=10.1.1.1 eth1ip=169.254.0.255 eth1mask=255.255.0.0 type=router
disable_rp_filter=true
[jira] [Closed] (CLOUDSTACK-3664) scaling up vms is not considering parameter cluster.(memory/cpu).allocated.capacity.disablethreshold
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra closed CLOUDSTACK-3664. - tested , passed scaling up vms is not considering parameter cluster.(memory/cpu).allocated.capacity.disablethreshold --- Key: CLOUDSTACK-3664 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3664 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0, 4.3.0 Environment: xen 4.2 Reporter: prashant kumar mishra Assignee: Nitin Mehta Priority: Critical Fix For: 4.3.0 Attachments: Logs_DB.rar, screenshot-1.jpg steps to reproduce 1-prepare a CS setup with xen 6.1 2-set cluster.memory.allocated.capacity.disablethreshold to some lower value say 0.2 3-deploy some vms until unless deployment fails because of threshold value. 4-Try to scale up vms Expected -- scaling up should get failed because threshold value Actual -- scaling up is successful DB mysql select *from cluster_details; ++++---+ | id | cluster_id | name | value | ++++---+ | 1 | 1 | cpuOvercommitRatio | 1.0 | | 2 | 1 | memoryOvercommitRatio | 1.0 | | 3 | 1 | cluster.memory.allocated.capacity.disablethreshold | 0.2 | ++++---+ -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5002) unable to destroy vm ;VM destroy failed in Stop i-2-59-VM Command due to You gave an invalid object reference. The object may have recently been deleted.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
prashant kumar mishra closed CLOUDSTACK-5002.
-
pass
unable to destroy vm ;VM destroy failed in Stop i-2-59-VM Command due to You
gave an invalid object reference. The object may have recently been deleted.
---
Key: CLOUDSTACK-5002
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5002
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server, XenServer
Affects Versions: 4.2.1
Reporter: prashant kumar mishra
Assignee: Koushik Das
Priority: Critical
Fix For: 4.3.0
Attachments: MS_xen_DB.rar, SMlog
steps to reproduce
---
1-prepare CS setup with xen 6.1
2-set execute.in.sequence.hypervisor.commands and
execute.in.sequence.network.element.commands to false
3-Restart MS
4-deploy 35 vms parallelly with default centOS template
5-try to destroy all uservms using script
Expected
-
All vms should get destroyed
Actual
7 vms went in stopped state
Logs
---
2013-10-30 10:22:35,406 DEBUG [agent.transport.Request]
(Job-Executor-93:job-244 = [ 539bf83c-67bb-4d4a-a8e2-837a8d85cb4d ]) Seq
3-125567535: Sending { Cmd , MgmtId: 7484181839895, via: 3, Ver: v1, Flags:
100011,
[{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:false,vmName:i-2-59-VM,wait:0}}]
}
2013-10-30 10:22:35,406 DEBUG [agent.transport.Request]
(Job-Executor-93:job-244 = [ 539bf83c-67bb-4d4a-a8e2-837a8d85cb4d ]) Seq
3-125567535: Executing: { Cmd , MgmtId: 7484181839895, via: 3, Ver: v1,
Flags: 100011,
[{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:false,vmName:i-2-59-VM,wait:0}}]
}
2013-10-30 10:22:36,050 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-68:null) 9. The VM i-2-59-VM is in Stopping state
013-10-30 10:22:39,747 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(DirectAgent-490:null) VM i-2-59-VM: cs state = Stopping and realState =
Running
2013-10-30 10:22:39,747 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(DirectAgent-490:null) VM i-2-59-VM: cs state = Stopping and realState =
Running
2013-10-30 10:32:36,831 WARN [xen.resource.CitrixResourceBase]
(DirectAgent-68:null) Async 600 seconds timeout for task
com.xensource.xenapi.Task@53bab0c6
2013-10-30 10:32:36,843 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-68:null) Unable to cleanShutdown VM(i-2-59-VM) on
host(7f8a4f8f-1c15-4b7a-95cf-1f64b09ce674) due to Async 600 seconds timeout
for task com.xensource.xenapi.Task@53bab0c6
2013-10-30 10:42:05,852 DEBUG [agent.transport.Request] (HA-Worker-4:work-40)
Seq 3-125567622: Sending { Cmd , MgmtId: 7484181839895, via: 3, Ver: v1,
Flags: 100011,
[{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:false,vmName:i-2-59-VM,wait:0}}]
}
2013-10-30 10:42:05,853 DEBUG [agent.transport.Request] (HA-Worker-4:work-40)
Seq 3-125567622: Executing: { Cmd , MgmtId: 7484181839895, via: 3, Ver: v1,
Flags: 100011,
[{com.cloud.agent.api.StopCommand:{isProxy:false,executeInSequence:false,vmName:i-2-59-VM,wait:0}}]
}
013-10-30 10:42:05,991 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-218:null) 9. The VM i-2-59-VM is in Stopping state
2013-10-30 10:42:05,997 WARN [xen.resource.CitrixResourceBase]
(DirectAgent-152:null) VM destroy failed in Stop i-2-67-VM Command due to You
gave an invalid object reference. The object may have recently been deleted.
The class parameter gives the type of reference given, and the handle
parameter echoes the bad value given.
You gave an invalid object reference. The object may have recently been
deleted. The class parameter gives the type of reference given, and the
handle parameter echoes the bad value given.
at com.xensource.xenapi.Types.checkResponse(Types.java:209)
at com.xensource.xenapi.Connection.dispatch(Connection.java:368)
at
com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909)
at com.xensource.xenapi.VM.getPowerState(VM.java:746)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:4011)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:500)
at
com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
at
[jira] [Closed] (CLOUDSTACK-5749) volume live migration is failing ;org.apache.cloudstack.api.response.ExceptionResponse/null/{uuidList:[],errorcode:530,errortext:Failed to migrate volume}
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
prashant kumar mishra closed CLOUDSTACK-5749.
-
checked on xen setup did not see this issue
volume live migration is failing
;org.apache.cloudstack.api.response.ExceptionResponse/null/{uuidList:[],errorcode:530,errortext:Failed
to migrate volume}
--
Key: CLOUDSTACK-5749
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5749
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.3.0
Environment: hyp:xen6.2
Reporter: prashant kumar mishra
Assignee: Kelven Yang
Priority: Critical
Fix For: 4.3.0
Attachments: Log_DB_ssvm.rar
I saw this error in upgraded setup not sure if it exist in fresh CS-4.3
setup also.
Steps to reproduce
===
1-preapre a ACS 4.2 setup with xen6.2
2-upgrade it to CS4.3
3-deploy a vm using default template
4-add a primary storage
5-crate a volume
6-add volume to instance created in step 3
7-try to migrate volume to newly added primary storage
Expected
===
volume migration should be successful
Actual
=
volume migration is failing
Log:
===
2014-01-03 07:17:00,618 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-18:ctx-1353ad92 ctx-c2dcabd7) submit async job-78, details:
AsyncJobVO {id:78, userId: 2, accountId: 2, instanceType: None, instanceId:
null, cmd: org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd,
cmdInfo:
{response:json,sessionkey:iB7oDA5zlPV6nT97WFR8vxIjZi8\u003d,cmdEventType:VOLUME.MIGRATE,ctxUserId:2,storageid:61944541-60c3-3d79-999b-db96ab0e7dc6,livemigrate:true,httpmethod:GET,_:1388732216160,volumeid:8117d17f-3b83-4685-99fd-a64205b32732,ctxAccountId:2,ctxStartEventId:175},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 7145449848920, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-01-03 07:17:00,621 DEBUG [c.c.a.ApiServlet]
(catalina-exec-18:ctx-1353ad92 ctx-c2dcabd7) ===END=== 10.252.192.25 -- GET
command=migrateVolumelivemigrate=truestorageid=61944541-60c3-3d79-999b-db96ab0e7dc6volumeid=8117d17f-3b83-4685-99fd-a64205b32732response=jsonsessionkey=iB7oDA5zlPV6nT97WFR8vxIjZi8%3D_=1388732216160
2014-01-03 07:17:00,623 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Job-Executor-56:ctx-ac65175b) Add job-78 into job monitoring
2014-01-03 07:17:00,624 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-56:ctx-ac65175b) Executing AsyncJobVO {id:78, userId: 2,
accountId: 2, instanceType: None, instanceId: null, cmd:
org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd, cmdInfo:
{response:json,sessionkey:iB7oDA5zlPV6nT97WFR8vxIjZi8\u003d,cmdEventType:VOLUME.MIGRATE,ctxUserId:2,storageid:61944541-60c3-3d79-999b-db96ab0e7dc6,livemigrate:true,httpmethod:GET,_:1388732216160,volumeid:8117d17f-3b83-4685-99fd-a64205b32732,ctxAccountId:2,ctxStartEventId:175},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 7145449848920, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-01-03 07:17:00,661 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-56:ctx-ac65175b ctx-c2dcabd7) Sync job-79 execution on object
VmWorkJobQueue.3
2014-01-03 07:17:01,860 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(AsyncJobMgr-Heartbeat-1:ctx-8f61216d) Execute sync-queue item:
SyncQueueItemVO {id:23, queueId: 17, contentType: AsyncJob, contentId: 79,
lastProcessMsid: null, lastprocessNumber: null, lastProcessTime: null,
created: Fri Jan 03 07:17:00 EST 2014}
2014-01-03 07:17:01,863 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(AsyncJobMgr-Heartbeat-1:ctx-8f61216d) Schedule queued job-79
2014-01-03 07:17:01,879 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Job-Executor-57:ctx-da52aa8b) Add job-79 into job monitoring
2014-01-03 07:17:01,880 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-57:ctx-da52aa8b) Executing AsyncJobVO {id:79, userId: 2,
accountId: 2, instanceType: null, instanceId: null, cmd:
com.cloud.storage.VmWorkMigrateVolume, cmdInfo:
rO0ABXNyACVjb20uY2xvdWQuc3RvcmFnZS5WbVdvcmtNaWdyYXRlVm9sdW1l-CXzb7zvU-YCAANKAApkZXN0UG9vbElkWgALbGl2ZU1pZ3JhdGVKAAh2b2x1bWVJZHhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIAA3QAFFZvbHVtZUFwaVNlcnZpY2VJbXBsAAMBAA0,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null,
[jira] [Closed] (CLOUDSTACK-5817) [Dev Setup]Deploy Db is failing on master and 4.3
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra closed CLOUDSTACK-5817. - tested , passed [Dev Setup]Deploy Db is failing on master and 4.3 - Key: CLOUDSTACK-5817 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5817 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: prashant kumar mishra Assignee: Harikrishna Patnala Priority: Blocker Fix For: 4.3.0 Ddeploydb is failing on master and 4.3 branch . For branch 4.2 it is working fine [root@localhost cloudstack]# mvn -P developer -pl developer -Ddeploydb [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building Apache CloudStack Developer Mode 4.4.0-SNAPSHOT [INFO] [INFO] [INFO] --- properties-maven-plugin:1.0-alpha-2:read-project-properties (default) @ cloud-developer --- [INFO] [INFO] --- maven-remote-resources-plugin:1.3:process (default) @ cloud-developer --- [INFO] [INFO] --- maven-antrun-plugin:1.7:run (default) @ cloud-developer --- [INFO] Executing tasks main: [INFO] Executed tasks [INFO] [INFO] exec-maven-plugin:1.2.1:java (create-schema) @ cloud-developer [INFO] [INFO] exec-maven-plugin:1.2.1:java (create-schema) @ cloud-developer [INFO] [INFO] --- exec-maven-plugin:1.2.1:java (create-schema) @ cloud-developer --- log4j:WARN No appenders could be found for logger (org.springframework.core.env.StandardEnvironment). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. WARNING: Provided file does not exist: /root/cloudstack/developer/developer-prefill.sql.override Initializing database=cloud with host=localhost port=3306 username=root password= Running query: drop database if exists `cloud` Running query: create database `cloud` Running query: GRANT ALL ON cloud.* to 'root'@`localhost` identified by '' Running query: GRANT ALL ON cloud.* to 'root'@`%` identified by '' Initializing database=cloud_usage with host=localhost port=3306 username=root password= Running query: drop database if exists `cloud_usage` Running query: create database `cloud_usage` Running query: GRANT ALL ON cloud_usage.* to 'root'@`localhost` identified by '' Running query: GRANT ALL ON cloud_usage.* to 'root'@`%` identified by '' Initializing database=cloudbridge with host=localhost port=3306 username=root password= Running query: drop database if exists `cloudbridge` Running query: create database `cloudbridge` Running query: GRANT ALL ON cloudbridge.* to 'root'@`localhost` identified by '' Running query: GRANT ALL ON cloudbridge.* to 'root'@`%` identified by '' Processing SQL file at /root/cloudstack/developer/target/db/create-schema.sql Processing SQL file at /root/cloudstack/developer/target/db/create-schema-premium.sql Processing SQL file at /root/cloudstack/developer/target/db/templates.sql Processing SQL file at /root/cloudstack/developer/target/db/cloudbridge_schema.sql Processing SQL file at /root/cloudstack/developer/target/db/cloudbridge_multipart.sql Processing SQL file at /root/cloudstack/developer/target/db/cloudbridge_index.sql Processing SQL file at /root/cloudstack/developer/target/db/cloudbridge_multipart_alter.sql Processing SQL file at /root/cloudstack/developer/target/db/cloudbridge_bucketpolicy.sql Processing SQL file at /root/cloudstack/developer/target/db/cloudbridge_policy_alter.sql Processing SQL file at /root/cloudstack/developer/target/db/cloudbridge_offering.sql Processing SQL file at /root/cloudstack/developer/target/db/cloudbridge_offering_alter.sql Processing SQL file at /root/cloudstack/developer/developer-prefill.sql Processing upgrade: com.cloud.upgrade.DatabaseUpgradeChecker [WARNING] java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at
[jira] [Created] (CLOUDSTACK-6066) [Automation] Migrate test cases are failing with assertion error when sufficient no. of hosts not present
Gaurav Aradhye created CLOUDSTACK-6066: -- Summary: [Automation] Migrate test cases are failing with assertion error when sufficient no. of hosts not present Key: CLOUDSTACK-6066 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6066 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Test Affects Versions: 4.4.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.4.0 Migrate test cases in test_vm_life_cycle are failing with assertion error when at least 2 hosts are not present in the setup. To do: 1) Skip test case instead of failing with assertion error in such condition 2) Put condition for KVM that two hosts should be present in the same cluster because live migration between two hosts of different clusters is not supported in KVM. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6065) No HA for shutdown VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896636#comment-13896636
]
prashant kumar mishra commented on CLOUDSTACK-6065:
---
i tried same scenario , UI shows vm is in stop state , but CS did not tried to
start it on other host
logs:
===
2014-02-10 14:01:59,372 INFO [c.c.v.VirtualMachineManagerImpl]
(AgentManager-Handler-6:null) VM i-2-3-VM is sync-ed to at Stopped state
according to power-off report from hypervisor
2014-02-10 14:01:59,383 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-6:null) SeqA 4-10: Sending Seq 4-10: { Ans: , MgmtId:
7145449848920, via: 4, Ver: v1, Flags: 100010,
[{com.cloud.agent.api.PingAnswer:{_command:{newGroupStates:{},newStates:{i-2-3-VM:Stopped},_hostVmStateReport:{i-2-3-VM:{state:PowerOff,host:Rack1Pod1Host7}},_gatewayAccessible:true,_vnetAccessible:true,hostType:Routing,hostId:4,wait:0},result:true,wait:0}}]
}
No HA for shutdown VM
-
Key: CLOUDSTACK-6065
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6065
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server, UI
Affects Versions: 4.3.0
Environment: CentOS 6.5 Mgmt HVs, KVM
Reporter: Nux
Labels: ha, kvm
I create a service offering with HA, launch a VM with it.
I stop the VM from its console or SSH by issuing `poweroff` and the VM is not
started back on.
This is what I see in the management log:
http://fpaste.org/75667/67633139/raw/
The UI keeps showing this VM as Running.
However, if I force a reboot of its hypervisor ACS does do the right thing
and starts the VM on another HV.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Comment Edited] (CLOUDSTACK-6065) No HA for shutdown VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896636#comment-13896636
]
prashant kumar mishra edited comment on CLOUDSTACK-6065 at 2/10/14 3:06 PM:
i tried same scenario , UI shows vm state correctly (stop state) . CS did not
tried to start it on other host
logs:
===
2014-02-10 14:01:59,372 INFO [c.c.v.VirtualMachineManagerImpl]
(AgentManager-Handler-6:null) VM i-2-3-VM is sync-ed to at Stopped state
according to power-off report from hypervisor
2014-02-10 14:01:59,383 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-6:null) SeqA 4-10: Sending Seq 4-10: { Ans: , MgmtId:
7145449848920, via: 4, Ver: v1, Flags: 100010,
[{com.cloud.agent.api.PingAnswer:{_command:{newGroupStates:{},newStates:{i-2-3-VM:Stopped},_hostVmStateReport:{i-2-3-VM:{state:PowerOff,host:Rack1Pod1Host7}},_gatewayAccessible:true,_vnetAccessible:true,hostType:Routing,hostId:4,wait:0},result:true,wait:0}}]
}
was (Author: prashantkm):
i tried same scenario , UI shows vm is in stop state , but CS did not tried to
start it on other host
logs:
===
2014-02-10 14:01:59,372 INFO [c.c.v.VirtualMachineManagerImpl]
(AgentManager-Handler-6:null) VM i-2-3-VM is sync-ed to at Stopped state
according to power-off report from hypervisor
2014-02-10 14:01:59,383 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-6:null) SeqA 4-10: Sending Seq 4-10: { Ans: , MgmtId:
7145449848920, via: 4, Ver: v1, Flags: 100010,
[{com.cloud.agent.api.PingAnswer:{_command:{newGroupStates:{},newStates:{i-2-3-VM:Stopped},_hostVmStateReport:{i-2-3-VM:{state:PowerOff,host:Rack1Pod1Host7}},_gatewayAccessible:true,_vnetAccessible:true,hostType:Routing,hostId:4,wait:0},result:true,wait:0}}]
}
No HA for shutdown VM
-
Key: CLOUDSTACK-6065
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6065
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server, UI
Affects Versions: 4.3.0
Environment: CentOS 6.5 Mgmt HVs, KVM
Reporter: Nux
Labels: ha, kvm
I create a service offering with HA, launch a VM with it.
I stop the VM from its console or SSH by issuing `poweroff` and the VM is not
started back on.
This is what I see in the management log:
http://fpaste.org/75667/67633139/raw/
The UI keeps showing this VM as Running.
However, if I force a reboot of its hypervisor ACS does do the right thing
and starts the VM on another HV.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6065) No HA for shutdown VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896653#comment-13896653 ] Wei Zhou commented on CLOUDSTACK-6065: -- In my point of view, HA means vm will restart if it is stopped unexpectedly, for example, the host which vm is running on is enforced to power off It you stop the vm, the vm will not start. No HA for shutdown VM - Key: CLOUDSTACK-6065 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6065 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, UI Affects Versions: 4.3.0 Environment: CentOS 6.5 Mgmt HVs, KVM Reporter: Nux Labels: ha, kvm I create a service offering with HA, launch a VM with it. I stop the VM from its console or SSH by issuing `poweroff` and the VM is not started back on. This is what I see in the management log: http://fpaste.org/75667/67633139/raw/ The UI keeps showing this VM as Running. However, if I force a reboot of its hypervisor ACS does do the right thing and starts the VM on another HV. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6067) UI does not list routers matched by search string
Rutger te Nijenhuis created CLOUDSTACK-6067: --- Summary: UI does not list routers matched by search string Key: CLOUDSTACK-6067 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6067 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.2.1 Reporter: Rutger te Nijenhuis Priority: Trivial While searching for virtual routers on a specific keyword, the gui returns the matched search and all project routers. Keyword isn't applied to second api call listing the project routers: api?command=listRouterslistAll=truepage=1pagesize=20keyword=r-1313response=jsonsessionkey=qjeqwijeo12@*($(!*kjsij_=1392044881273 /client api?command=listRouterslistAll=truepage=1pagesize=20projectid=-1response=jsonsessionkey=qjeqwijeo12@*($(!*kjsij_=1392044881446 /client -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6065) No HA for shutdown VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896693#comment-13896693 ] Nux commented on CLOUDSTACK-6065: - Wei, The docs say When an HA-enabled VM crashes, CloudStack detects the crash and restarts the VM automatically within the same Availability Zone.. If I poweroff the VM from within or `virsh destroy` it on the HV, according to the above Cloudstack should restart it. No HA for shutdown VM - Key: CLOUDSTACK-6065 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6065 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, UI Affects Versions: 4.3.0 Environment: CentOS 6.5 Mgmt HVs, KVM Reporter: Nux Labels: ha, kvm I create a service offering with HA, launch a VM with it. I stop the VM from its console or SSH by issuing `poweroff` and the VM is not started back on. This is what I see in the management log: http://fpaste.org/75667/67633139/raw/ The UI keeps showing this VM as Running. However, if I force a reboot of its hypervisor ACS does do the right thing and starts the VM on another HV. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6068) service/disk_offering_details: display flag should be set to true by default
Alena Prokharchyk created CLOUDSTACK-6068: - Summary: service/disk_offering_details: display flag should be set to true by default Key: CLOUDSTACK-6068 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6068 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Priority: Critical Fix For: 4.3.0 There are 2 tables where details for service/disk offering details are stored: service_offering_details and disk_offering_details. Each table has display field (boolean) - if set to false, the detail will be displayed to admin only. Bug: initially the default value of the db field was set to false, so all the details were saved with 0 flag (although admin didn't intend it). But the API was working w/o checking this field before, so details with 0 were returned to the user. Then this API bug was fixed, and the details stopped returning to the user. Fix: we have to set the display flag to be 1 by default. Only when its defined otherwise in the API, this flag should be set to 0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-6068) service/disk_offering_details: display flag should be set to true by default
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk resolved CLOUDSTACK-6068. --- Resolution: Fixed Fixed with 01ab29cadcbca578c0c26eafaf1dc1509046aa64 service/disk_offering_details: display flag should be set to true by default Key: CLOUDSTACK-6068 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6068 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Priority: Critical Fix For: 4.3.0 There are 2 tables where details for service/disk offering details are stored: service_offering_details and disk_offering_details. Each table has display field (boolean) - if set to false, the detail will be displayed to admin only. Bug: initially the default value of the db field was set to false, so all the details were saved with 0 flag (although admin didn't intend it). But the API was working w/o checking this field before, so details with 0 were returned to the user. Then this API bug was fixed, and the details stopped returning to the user. Fix: we have to set the display flag to be 1 by default. Only when its defined otherwise in the API, this flag should be set to 0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6068) service/disk_offering_details: display flag should be set to true by default
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896827#comment-13896827 ] ASF subversion and git services commented on CLOUDSTACK-6068: - Commit aff22869cc18bcfb0845af2624fdd2afeabb3787 in branch refs/heads/4.3-forward from [~alena1108] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=aff2286 ] CLOUDSTACK-6068: set display flag to true in service/disk_offering_details tables service/disk_offering_details: display flag should be set to true by default Key: CLOUDSTACK-6068 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6068 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Priority: Critical Fix For: 4.3.0 There are 2 tables where details for service/disk offering details are stored: service_offering_details and disk_offering_details. Each table has display field (boolean) - if set to false, the detail will be displayed to admin only. Bug: initially the default value of the db field was set to false, so all the details were saved with 0 flag (although admin didn't intend it). But the API was working w/o checking this field before, so details with 0 were returned to the user. Then this API bug was fixed, and the details stopped returning to the user. Fix: we have to set the display flag to be 1 by default. Only when its defined otherwise in the API, this flag should be set to 0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5909) [UI] remove the rootdisksize text box from the deployvm wizard UI.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896830#comment-13896830 ] Animesh Chaturvedi commented on CLOUDSTACK-5909: Jessica can you check into this [UI] remove the rootdisksize text box from the deployvm wizard UI. -- Key: CLOUDSTACK-5909 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5909 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: Bharat Kumar Fix For: 4.3.0 The root disk resize feature i not in for this release so we need to remove the root disk size text box form the deployvm wizard. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6065) No HA for shutdown VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896842#comment-13896842 ] edison su commented on CLOUDSTACK-6065: --- It's a bug in vm sync: 2014-02-09 17:38:43,962 DEBUG [c.c.v.VirtualMachineManagerImpl] (AgentManager-Handler-14:null) VM i-2-13-VM: cs state = Running and realState = Stopped 2014-02-09 17:38:43,962 DEBUG [c.c.v.VirtualMachineManagerImpl] (AgentManager-Handler-14:null) VM i-2-13-VM: cs state = Running and realState = Stopped 2014-02-09 17:38:43,962 DEBUG [c.c.h.HighAvailabilityManagerImpl] (AgentManager-Handler-14:null) VM does not require investigation so I'm marking it as Stopped: VM[User|ha1] 2014-02-09 17:38:43,962 WARN [o.a.c.f.j.AsyncJobExecutionContext] (AgentManager-Handler-14:null) Job is executed without a context, setup psudo job for the executing thread 2014-02-09 17:38:43,962 WARN [c.c.a.m.AgentManagerImpl] (AgentManager-Handler-14:null) Caught: java.lang.NullPointerException at org.apache.cloudstack.framework.jobs.AsyncJobExecutionContext.getCurrentExecutionContext(AsyncJobExecutionContext.java:172) at com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1299) at com.cloud.ha.HighAvailabilityManagerImpl.scheduleRestart(HighAvailabilityManagerImpl.java:346) at com.cloud.vm.VirtualMachineManagerImpl.compareState(VirtualMachineManagerImpl.java:2816) at com.cloud.vm.VirtualMachineManagerImpl.deltaHostSync(VirtualMachineManagerImpl.java:2422) at com.cloud.vm.VirtualMachineManagerImpl.processCommands(VirtualMachineManagerImpl.java:2952) at com.cloud.agent.manager.AgentManagerImpl.handleCommands(AgentManagerImpl.java:292) at com.cloud.agent.manager.AgentManagerImpl$AgentHandler.processRequest(AgentManagerImpl.java:1184) at com.cloud.agent.manager.AgentManagerImpl$AgentHandler.doTask(AgentManagerImpl.java:1270) at com.cloud.agent.manager.ClusteredAgentManagerImpl$ClusteredAgentHandler.doTask(ClusteredAgentManagerImpl.java:677) 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) No HA for shutdown VM - Key: CLOUDSTACK-6065 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6065 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, UI Affects Versions: 4.3.0 Environment: CentOS 6.5 Mgmt HVs, KVM Reporter: Nux Labels: ha, kvm I create a service offering with HA, launch a VM with it. I stop the VM from its console or SSH by issuing `poweroff` and the VM is not started back on. This is what I see in the management log: http://fpaste.org/75667/67633139/raw/ The UI keeps showing this VM as Running. However, if I force a reboot of its hypervisor ACS does do the right thing and starts the VM on another HV. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6065) No HA for shutdown VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nux updated CLOUDSTACK-6065: Priority: Critical (was: Major) No HA for shutdown VM - Key: CLOUDSTACK-6065 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6065 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, UI Affects Versions: 4.3.0 Environment: CentOS 6.5 Mgmt HVs, KVM Reporter: Nux Priority: Critical Labels: ha, kvm I create a service offering with HA, launch a VM with it. I stop the VM from its console or SSH by issuing `poweroff` and the VM is not started back on. This is what I see in the management log: http://fpaste.org/75667/67633139/raw/ The UI keeps showing this VM as Running. However, if I force a reboot of its hypervisor ACS does do the right thing and starts the VM on another HV. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6065) No HA for shutdown VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896870#comment-13896870 ] Nux commented on CLOUDSTACK-6065: - Thanks, I've changed status to Critical. No HA for shutdown VM - Key: CLOUDSTACK-6065 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6065 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, UI Affects Versions: 4.3.0 Environment: CentOS 6.5 Mgmt HVs, KVM Reporter: Nux Priority: Critical Labels: ha, kvm I create a service offering with HA, launch a VM with it. I stop the VM from its console or SSH by issuing `poweroff` and the VM is not started back on. This is what I see in the management log: http://fpaste.org/75667/67633139/raw/ The UI keeps showing this VM as Running. However, if I force a reboot of its hypervisor ACS does do the right thing and starts the VM on another HV. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6065) No HA for shutdown VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-6065: --- Assignee: Kelven Yang No HA for shutdown VM - Key: CLOUDSTACK-6065 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6065 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, UI Affects Versions: 4.3.0 Environment: CentOS 6.5 Mgmt HVs, KVM Reporter: Nux Assignee: Kelven Yang Priority: Critical Labels: ha, kvm I create a service offering with HA, launch a VM with it. I stop the VM from its console or SSH by issuing `poweroff` and the VM is not started back on. This is what I see in the management log: http://fpaste.org/75667/67633139/raw/ The UI keeps showing this VM as Running. However, if I force a reboot of its hypervisor ACS does do the right thing and starts the VM on another HV. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6065) No HA for shutdown VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13896879#comment-13896879 ] sadhu suresh commented on CLOUDSTACK-6065: -- Due to following bug its fail to perform HA CLOUDSTACK-5713vmsync:KVM:NPE when agentmanager tries to update the destroyed vm state during vmsync Also A VM is scheduled for HA when the following conditions occur. - A host is found to be Down. - A host is disconnected for more than 30 minutes (time is configurable). - An agent for a host reports that a VM has stopped running. - VMs that have been stuck at the Starting state for more than an hour. - A management server determined that its peer has gone down and is unwinding any VM that the peer was trying to start. - A management server on restart is unwinding any VM that it itself was trying to start. No HA for shutdown VM - Key: CLOUDSTACK-6065 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6065 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, UI Affects Versions: 4.3.0 Environment: CentOS 6.5 Mgmt HVs, KVM Reporter: Nux Assignee: Kelven Yang Priority: Critical Labels: ha, kvm I create a service offering with HA, launch a VM with it. I stop the VM from its console or SSH by issuing `poweroff` and the VM is not started back on. This is what I see in the management log: http://fpaste.org/75667/67633139/raw/ The UI keeps showing this VM as Running. However, if I force a reboot of its hypervisor ACS does do the right thing and starts the VM on another HV. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6069) can't create privatgateway with vlan in a mixed network env
Daan Hoogland created CLOUDSTACK-6069: - Summary: can't create privatgateway with vlan in a mixed network env Key: CLOUDSTACK-6069 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6069 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller, Xen Affects Versions: 4.3.0 Environment: 1 zone, 1 pod, 1 cluster, 2 hosts (xen 6.0.2) 2 physnets - physnet 1 vlan based (Public, Guest(tagged vlan-based), Management, Storage) - physnet 2 nicira based (Guest (tagged nicira-based)) Reporter: Daan Hoogland creating a private gateway on a vpc with a vlan fails. I get a 530 server error. in 4.2.1 this didn't happen 4.2.1 code (succeeding): 2014-02-10 15:43:45,621 DEBUG [xen.resource.CitrixResourceBase] (DirectAgent-4:null) Creating VLAN 322 on host 10.200.23.41 on device tunnel0 4.3.0 code (failing) 2014-02-10 17:33:51,083 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-4:ctx-6d5f0cd4) Creating VLAN 322 on host 10.200.23.42 on device tunnel0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6069) can't create privatgateway with vlan in a mixed network env
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-6069: -- Description: creating a private gateway on a vpc with a vlan fails. I get a 530 server error using marvin to create the net. in 4.2.1 this didn't happen 4.2.1 code (succeeding): 2014-02-10 15:43:45,621 DEBUG [xen.resource.CitrixResourceBase] (DirectAgent-4:null) Creating VLAN 322 on host 10.200.23.41 on device tunnel0 4.3.0 code (failing) 2014-02-10 17:33:51,083 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-4:ctx-6d5f0cd4) Creating VLAN 322 on host 10.200.23.42 on device tunnel0 was: creating a private gateway on a vpc with a vlan fails. I get a 530 server error. in 4.2.1 this didn't happen 4.2.1 code (succeeding): 2014-02-10 15:43:45,621 DEBUG [xen.resource.CitrixResourceBase] (DirectAgent-4:null) Creating VLAN 322 on host 10.200.23.41 on device tunnel0 4.3.0 code (failing) 2014-02-10 17:33:51,083 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-4:ctx-6d5f0cd4) Creating VLAN 322 on host 10.200.23.42 on device tunnel0 can't create privatgateway with vlan in a mixed network env --- Key: CLOUDSTACK-6069 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6069 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller, Xen Affects Versions: 4.3.0 Environment: 1 zone, 1 pod, 1 cluster, 2 hosts (xen 6.0.2) 2 physnets - physnet 1 vlan based (Public, Guest(tagged vlan-based), Management, Storage) - physnet 2 nicira based (Guest (tagged nicira-based)) Reporter: Daan Hoogland creating a private gateway on a vpc with a vlan fails. I get a 530 server error using marvin to create the net. in 4.2.1 this didn't happen 4.2.1 code (succeeding): 2014-02-10 15:43:45,621 DEBUG [xen.resource.CitrixResourceBase] (DirectAgent-4:null) Creating VLAN 322 on host 10.200.23.41 on device tunnel0 4.3.0 code (failing) 2014-02-10 17:33:51,083 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-4:ctx-6d5f0cd4) Creating VLAN 322 on host 10.200.23.42 on device tunnel0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6070) Contrail:Static NAT: Unable to create virtual-machine-interface
Parth Jagirdar created CLOUDSTACK-6070:
--
Summary: Contrail:Static NAT: Unable to create
virtual-machine-interface
Key: CLOUDSTACK-6070
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6070
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: API, Contrail
Affects Versions: 4.2.1
Environment: Contrail, Xen
Reporter: Parth Jagirdar
Priority: Critical
Fix For: 4.2.1
Acquire IP, Enable Static NAT,
Choose a VM and following exception is raised. Although NAt does get enabled.
2014-02-10 10:20:21,975 INFO [n.j.c.a.ApiConnector]
(catalina-exec-11:ctx-8730afff ctx-f70574dc) Request: POST,
/virtual-machine-interfaces,
{virtual-machine-interface:{virtual_machine_interface_mac_addresses:{mac_address:[06:e4:2a:00:00:35]},virtual_network_refs:[{to:[default-domain,default-project,__default_Public__],attr:null,href:null,uuid:null}],name:s-11-VM-2,uuid:07c6bdac-7be4-4d88-83ef-6f5ffe2f8b19,fq_name:[s-11-VM,s-11-VM-2],parent_type:virtual-machine}}
2014-02-10 10:20:21,997 INFO [n.j.c.a.ApiConnector]
(catalina-exec-11:ctx-8730afff ctx-f70574dc) Response Status: HTTP/1.1 400
Bad Request
2014-02-10 10:20:21,997 ERROR [n.j.c.a.ApiConnector]
(catalina-exec-11:ctx-8730afff ctx-f70574dc) create api request failed: Bad
Request
2014-02-10 10:20:21,998 ERROR [n.j.c.a.ApiConnector]
(catalina-exec-11:ctx-8730afff ctx-f70574dc) Failure message:
!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
html
head
titleError: 400 Bad Request/title
style type=text/css
html {background-color: #eee; font-family: sans;}
body {background-color: #fff; border: 1px solid #ddd;
padding: 15px; margin: 15px;}
pre {background-color: #eee; border: 1px solid #ddd; padding:
5px;}
/style
/head
body
h1Error: 400 Bad Request/h1
pSorry, the requested URL
tt#039;http://10.223.58.3:8082/virtual-machine-interfaces#039;/tt
caused an error:/p
preParent [u#039;s-11-VM#039;] type virtual-machine does not
exist/pre
/body
/html
2014-02-10 10:20:21,998 WARN [o.a.c.n.c.m.ContrailManager]
(catalina-exec-11:ctx-8730afff ctx-f70574dc) virtual-network update:
com.cloud.exception.InternalErrorException: Unable to create
virtual-machine-interface 07c6bdac-7be4-4d88-83ef-6f5ffe2f8b19
at
org.apache.cloudstack.network.contrail.model.VMInterfaceModel.update(VMInterfaceModel.java:229)
at
org.apache.cloudstack.network.contrail.model.VirtualNetworkModel.update(VirtualNetworkModel.java:305)
at
org.apache.cloudstack.network.contrail.management.ContrailManagerImpl.lookupPublicNetworkModel(ContrailManagerImpl.java:781)
at
org.apache.cloudstack.network.contrail.management.ContrailManagerImpl.createFloatingIp(ContrailManagerImpl.java:791)
at
org.apache.cloudstack.network.contrail.management.ContrailElementImpl.applyIps(ContrailElementImpl.java:345)
at
com.cloud.network.IpAddressManagerImpl.applyIpAssociations(IpAddressManagerImpl.java:976)
at
com.cloud.network.IpAddressManagerImpl.applyStaticNats(IpAddressManagerImpl.java:1756)
at
com.cloud.network.rules.RulesManagerImpl.applyStaticNatForIp(RulesManagerImpl.java:1324)
at
com.cloud.network.rules.RulesManagerImpl.enableStaticNat(RulesManagerImpl.java:602)
at
com.cloud.network.rules.RulesManagerImpl.enableStaticNat(RulesManagerImpl.java:446)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:622)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:109)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
[jira] [Assigned] (CLOUDSTACK-5909) [UI] remove the rootdisksize text box from the deployvm wizard UI.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang reassigned CLOUDSTACK-5909: Assignee: Brian Federle [UI] remove the rootdisksize text box from the deployvm wizard UI. -- Key: CLOUDSTACK-5909 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5909 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: Bharat Kumar Assignee: Brian Federle Fix For: 4.3.0 The root disk resize feature i not in for this release so we need to remove the root disk size text box form the deployvm wizard. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5909) [UI] remove the rootdisksize text box from the deployvm wizard UI.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Federle resolved CLOUDSTACK-5909. --- Resolution: Fixed commit 8fec09ba481fbd3b8c2a9e4d31ef06f113b037cb Author: Brian Federle brian.fede...@citrix.com Date: Fri Jan 24 10:47:26 2014 -0800 Disable root disk size field -- not supported in backend [UI] remove the rootdisksize text box from the deployvm wizard UI. -- Key: CLOUDSTACK-5909 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5909 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: Bharat Kumar Assignee: Brian Federle Fix For: 4.3.0 The root disk resize feature i not in for this release so we need to remove the root disk size text box form the deployvm wizard. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6071) Contrail:MS:DB: DBSync exceptions in MS log
Parth Jagirdar created CLOUDSTACK-6071:
--
Summary: Contrail:MS:DB: DBSync exceptions in MS log
Key: CLOUDSTACK-6071
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6071
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Contrail, Management Server
Affects Versions: 4.2.1
Environment: Contrail
Reporter: Parth Jagirdar
Priority: Critical
Fix For: 4.2.1
MS Log,
2014-02-10 12:23:31,122 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 200 OK
2014-02-10 12:23:31,122 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: GET, /floating-ip-pool/33b357b3-4f88-4ae6-af86-fb86afa3
2014-02-10 12:23:31,125 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 200 OK
2014-02-10 12:23:31,126 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: GET, /floating-ip/6a6fa311-e5a0-4dfb-b289-cbad2122a756
2014-02-10 12:23:31,129 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 200 OK
2014-02-10 12:23:31,130 DEBUG [o.a.c.n.c.m.DBSyncGeneric] (DBSyncTimer:null)
Generic db sync : FloatingIp
2014-02-10 12:23:31,141 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: GET, /virtual-network/e6c067bc-bc63-4613-a7af-84d0182ff6d2
2014-02-10 12:23:31,150 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 200 OK
2014-02-10 12:23:31,155 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: PUT, /virtual-network/e6c067bc-bc63-4613-a7af-84d0182ff6d2,
{virtual-network:{virtual_network_properties:{extend_to_external_routers:false,network_id:4},route_target_list:{route_target:[target:64512:1002,target:64512:1002,target:64512:1002,target:64512:1002,target:64512:1002,target:64512:1002,target:64512:1002]},network_ipam_refs:[{to:[default-domain,default-project,default-network-ipam],attr:{ipam_subnets:[{subnet:{ip_prefix:10.223.138.64,ip_prefix_len:26},default_gateway:10.223.138.65}]},href:null,uuid:null}],floating_ip_pools:[{to:[default-domain,default-project,__default_Public__,PublicIpPool],attr:null,href:http://10.223.58.3:8082/floating-ip-pool/33b357b3-4f88-4ae6-af86-fb86afa3,uuid:33b357b3-4f88-4ae6-af86-fb86afa3}],routing_instances:[{to:[default-domain,default-project,__default_Public__,__default_Public__],attr:null,href:http://10.223.58.3:8082/routing-instance/74769566-dfce-4b6d-bbb5-db772bccb2f9,uuid:74769566-dfce-4b6d-bbb5-db772bccb2f9}],name:__default_Public__,uuid:e6c067bc-bc63-4613-a7af-84d0182ff6d2,fq_name:[default-domain,default-project,__default_Public__],parent_type:project,parent_uuid:fafebf0e-5d9c-4c99-928d-25ab65bd7ebc}}
2014-02-10 12:23:31,193 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 200 OK
2014-02-10 12:23:31,194 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: GET, /virtual-machine-interface/07c6bdac-7be4-4d88-83ef-6f5ffe2f8b19
2014-02-10 12:23:31,198 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 404 Not Found
2014-02-10 12:23:31,199 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: POST, /virtual-machine-interfaces,
{virtual-machine-interface:{virtual_machine_interface_mac_addresses:{mac_address:[06:e4:2a:00:00:35]},virtual_network_refs:[{to:[default-domain,default-project,__default_Public__],attr:null,href:null,uuid:null}],name:s-11-VM-2,uuid:07c6bdac-7be4-4d88-83ef-6f5ffe2f8b19,fq_name:[s-11-VM,s-11-VM-2],parent_type:virtual-machine}}
2014-02-10 12:23:31,205 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 400 Bad Request
2014-02-10 12:23:31,205 ERROR [n.j.c.a.ApiConnector] (DBSyncTimer:null) create
api request failed: Bad Request
2014-02-10 12:23:31,206 ERROR [n.j.c.a.ApiConnector] (DBSyncTimer:null) Failure
message:
!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
html
head
titleError: 400 Bad Request/title
style type=text/css
html {background-color: #eee; font-family: sans;}
body {background-color: #fff; border: 1px solid #ddd;
padding: 15px; margin: 15px;}
pre {background-color: #eee; border: 1px solid #ddd; padding:
5px;}
/style
/head
body
h1Error: 400 Bad Request/h1
pSorry, the requested URL
tt#039;http://10.223.58.3:8082/virtual-machine-interfaces#039;/tt
caused an error:/p
preParent [u#039;s-11-VM#039;] type virtual-machine does not
exist/pre
/body
/html
2014-02-10 12:23:31,206 WARN [o.a.c.n.c.m.ContrailManager] (DBSyncTimer:null)
virtual-network update:
com.cloud.exception.InternalErrorException: Unable to create
virtual-machine-interface 07c6bdac-7be4-4d88-83ef-6f5ffe2f8b19
at
[jira] [Created] (CLOUDSTACK-6072) vxlan networks not deallocating vnet ids
Marcus Sorensen created CLOUDSTACK-6072:
---
Summary: vxlan networks not deallocating vnet ids
Key: CLOUDSTACK-6072
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6072
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server
Affects Versions: 4.3.0, 4.4.0
Reporter: Marcus Sorensen
Assignee: Yoshikazu Nojima
I noticed that we ran out of vxlan ids in our dev environment. It seems perhaps
due to calling 'super' in our shutdown method, but the 'super' method filters
out vxlan domain types.
./plugins/network-elements/vxlan/src/com/cloud/network/guru/VxlanGuestNetworkGuru.java
@Override
public void shutdown(NetworkProfile profile, NetworkOffering offering) {
NetworkVO networkObject = _networkDao.findById(profile.getId());
if (networkObject.getBroadcastDomainType() != BroadcastDomainType.Vxlan
|| networkObject.getBroadcastUri() == null) {
s_logger.warn(BroadcastUri is empty or incorrect for guestnetwork
+ networkObject.getDisplayText());
return;
}
super.shutdown(profile, offering);
}
server/src/com/cloud/network/guru/GuestNetworkGuru.java
@Override
public void shutdown(NetworkProfile profile, NetworkOffering offering) {
if (profile.getBroadcastDomainType() == BroadcastDomainType.Vlan
profile.getBroadcastUri() != null
!offering.getSpecifyVlan()) {
s_logger.debug(Releasing vnet for the network id= + profile.getId());
_dcDao.releaseVnet(profile.getBroadcastUri().getHost(),
profile.getDataCenterId(),
profile.getPhysicalNetworkId(), profile.getAccountId(),
profile.getReservationId());
ActionEventUtils.onCompletedActionEvent(UserContext.current().getCallerUserId(),
profile.getAccountId(),
EventVO.LEVEL_INFO, EventTypes.EVENT_ZONE_VLAN_RELEASE,
Released Zone Vlan:
+ profile.getBroadcastUri().getHost() + for Network: +
profile.getId(), 0);
}
profile.setBroadcastUri(null);
}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6071) Contrail:MS:DB: DBSync exceptions in MS log
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897087#comment-13897087
]
Parth Jagirdar commented on CLOUDSTACK-6071:
This was observed after a addNic attempt was made, (Which failed due to PV
Drivers not available).
Contrail:MS:DB: DBSync exceptions in MS log
---
Key: CLOUDSTACK-6071
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6071
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Contrail, Management Server
Affects Versions: 4.2.1
Environment: Contrail
Reporter: Parth Jagirdar
Priority: Critical
Fix For: 4.2.1
MS Log,
2014-02-10 12:23:31,122 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 200 OK
2014-02-10 12:23:31,122 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: GET, /floating-ip-pool/33b357b3-4f88-4ae6-af86-fb86afa3
2014-02-10 12:23:31,125 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 200 OK
2014-02-10 12:23:31,126 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: GET, /floating-ip/6a6fa311-e5a0-4dfb-b289-cbad2122a756
2014-02-10 12:23:31,129 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 200 OK
2014-02-10 12:23:31,130 DEBUG [o.a.c.n.c.m.DBSyncGeneric] (DBSyncTimer:null)
Generic db sync : FloatingIp
2014-02-10 12:23:31,141 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: GET, /virtual-network/e6c067bc-bc63-4613-a7af-84d0182ff6d2
2014-02-10 12:23:31,150 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 200 OK
2014-02-10 12:23:31,155 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: PUT, /virtual-network/e6c067bc-bc63-4613-a7af-84d0182ff6d2,
{virtual-network:{virtual_network_properties:{extend_to_external_routers:false,network_id:4},route_target_list:{route_target:[target:64512:1002,target:64512:1002,target:64512:1002,target:64512:1002,target:64512:1002,target:64512:1002,target:64512:1002]},network_ipam_refs:[{to:[default-domain,default-project,default-network-ipam],attr:{ipam_subnets:[{subnet:{ip_prefix:10.223.138.64,ip_prefix_len:26},default_gateway:10.223.138.65}]},href:null,uuid:null}],floating_ip_pools:[{to:[default-domain,default-project,__default_Public__,PublicIpPool],attr:null,href:http://10.223.58.3:8082/floating-ip-pool/33b357b3-4f88-4ae6-af86-fb86afa3,uuid:33b357b3-4f88-4ae6-af86-fb86afa3}],routing_instances:[{to:[default-domain,default-project,__default_Public__,__default_Public__],attr:null,href:http://10.223.58.3:8082/routing-instance/74769566-dfce-4b6d-bbb5-db772bccb2f9,uuid:74769566-dfce-4b6d-bbb5-db772bccb2f9}],name:__default_Public__,uuid:e6c067bc-bc63-4613-a7af-84d0182ff6d2,fq_name:[default-domain,default-project,__default_Public__],parent_type:project,parent_uuid:fafebf0e-5d9c-4c99-928d-25ab65bd7ebc}}
2014-02-10 12:23:31,193 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 200 OK
2014-02-10 12:23:31,194 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: GET, /virtual-machine-interface/07c6bdac-7be4-4d88-83ef-6f5ffe2f8b19
2014-02-10 12:23:31,198 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 404 Not Found
2014-02-10 12:23:31,199 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Request: POST, /virtual-machine-interfaces,
{virtual-machine-interface:{virtual_machine_interface_mac_addresses:{mac_address:[06:e4:2a:00:00:35]},virtual_network_refs:[{to:[default-domain,default-project,__default_Public__],attr:null,href:null,uuid:null}],name:s-11-VM-2,uuid:07c6bdac-7be4-4d88-83ef-6f5ffe2f8b19,fq_name:[s-11-VM,s-11-VM-2],parent_type:virtual-machine}}
2014-02-10 12:23:31,205 INFO [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Response Status: HTTP/1.1 400 Bad Request
2014-02-10 12:23:31,205 ERROR [n.j.c.a.ApiConnector] (DBSyncTimer:null)
create api request failed: Bad Request
2014-02-10 12:23:31,206 ERROR [n.j.c.a.ApiConnector] (DBSyncTimer:null)
Failure message:
!DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN
html
head
titleError: 400 Bad Request/title
style type=text/css
html {background-color: #eee; font-family: sans;}
body {background-color: #fff; border: 1px solid #ddd;
padding: 15px; margin: 15px;}
pre {background-color: #eee; border: 1px solid #ddd; padding:
5px;}
/style
/head
body
h1Error: 400 Bad Request/h1
pSorry, the requested URL
tt#039;http://10.223.58.3:8082/virtual-machine-interfaces#039;/tt
caused an error:/p
[jira] [Commented] (CLOUDSTACK-5773) Contrail:MS: Restart network fails with Unable to restart a running SDN network
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897280#comment-13897280
]
Parth Jagirdar commented on CLOUDSTACK-5773:
still observed.
Contrail:MS: Restart network fails with Unable to restart a running SDN
network
---
Key: CLOUDSTACK-5773
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5773
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Contrail, Management Server
Affects Versions: 4.2.0
Environment: Contrail
Reporter: Parth Jagirdar
Priority: Critical
Restart network fails with Unable to restart a running SDN network
2014-01-03 14:48:11,907 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-27:job-39 = [ 4e217deb-844a-45f2-9e2a-183a3344de2e ]) job
org.apache.cloudstack.api.command.user.network.RestartNetworkCmd for job-39 =
[ 4e217deb-844a-45f2-9e2a-183a3344de2e ] was queued, processing the queue.
2014-01-03 14:48:11,913 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-27:job-39 = [ 4e217deb-844a-45f2-9e2a-183a3344de2e ]) Executing
sync queue item: SyncQueueItemVO {id:19, queueId: 9, contentType: AsyncJob,
contentId: 39, lastProcessMsid: 86780043846508, lastprocessNumber: 5,
lastProcessTime: Fri Jan 03 14:48:11 PST 2014, created: Fri Jan 03 14:48:11
PST 2014}
2014-01-03 14:48:11,915 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-27:job-39 = [ 4e217deb-844a-45f2-9e2a-183a3344de2e ]) Schedule
queued job-39 = [ 4e217deb-844a-45f2-9e2a-183a3344de2e ]
2014-01-03 14:48:11,921 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-28:job-39 = [ 4e217deb-844a-45f2-9e2a-183a3344de2e ]) Executing
org.apache.cloudstack.api.command.user.network.RestartNetworkCmd for job-39 =
[ 4e217deb-844a-45f2-9e2a-183a3344de2e ]
2014-01-03 14:48:11,921 DEBUG [cloud.async.SyncQueueManagerImpl]
(Job-Executor-27:job-39 = [ 4e217deb-844a-45f2-9e2a-183a3344de2e ]) There is
a pending process in sync queue(id: 9)
2014-01-03 14:48:11,954 DEBUG
[contrail.management.EventUtils$EventInterceptor] (Job-Executor-28:job-39 = [
4e217deb-844a-45f2-9e2a-183a3344de2e ]) interceptException
2014-01-03 14:48:11,954 ERROR [cloud.async.AsyncJobManagerImpl]
(Job-Executor-28:job-39 = [ 4e217deb-844a-45f2-9e2a-183a3344de2e ])
Unexpected exception while executing
org.apache.cloudstack.api.command.user.network.RestartNetworkCmd
java.security.InvalidParameterException: Unable to restart a running SDN
network.
at
com.cloud.network.NetworkServiceImpl.restartNetwork(NetworkServiceImpl.java:1799)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
org.apache.cloudstack.api.command.user.network.RestartNetworkCmd.execute(RestartNetworkCmd.java:92)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
at
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
2014-01-03 14:48:11,956 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-28:job-39 = [ 4e217deb-844a-45f2-9e2a-183a3344de2e ]) Complete
async job-39 = [ 4e217deb-844a-45f2-9e2a-183a3344de2e ], jobStatus: 2,
resultCode: 530, result: Error Code: 530 Error text: Unable to restart a
running SDN network.
2014-01-03 14:48:11,968 DEBUG [cloud.async.SyncQueueManagerImpl]
(Job-Executor-28:job-39 = [ 4e217deb-844a-45f2-9e2a-183a3344de2e ]) Sync
queue (9) is currently empty
2014-01-03 14:48:11,969 WARN [cloud.async.AsyncJobManagerImpl]
(Job-Executor-28:job-39 = [ 4e217deb-844a-45f2-9e2a-183a3344de2e ]) Unable to
unregister active job [ 39 ] = [ 4e217deb-844a-45f2-9e2a-183a3344de2e ] from
JMX monitoring
2014-01-03 14:48:13,297 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-12:null) SeqA 2-83810: Processing Seq 2-83810: { Cmd ,
MgmtId: -1, via: 2, Ver: v1, Flags: 11,
[{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:2,_loadInfo:{\n
\connections\: []\n},wait:0}}] }
2014-01-03 14:48:13,301 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-12:null) SeqA 2-83810: Sending Seq 2-83810: { Ans: ,
MgmtId: 86780043846508, via: 2, Ver:
[jira] [Updated] (CLOUDSTACK-5777) Contrail:MS: Rebooting Xen host results in disconnected SR
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Parth Jagirdar updated CLOUDSTACK-5777:
---
Priority: Blocker (was: Major)
While SR does not gets disconnected,
Pushing severity to blocker due to following observations.
1) It takes multiple connect attempts before xenserver host joins the pool
again.
2) Starting VM's on that Xenserver hosts migrates them to another host in pool.
3) Upon migration VM fails to start.
2014-02-10 14:28:56,633 WARN [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-427:ctx-8d999b63) Error while collecting disk stats from :
You gave an invalid object reference. The object may have recently been
deleted. The class parameter gives the type of reference given, and the handle
parameter echoes the bad value given.
at com.xensource.xenapi.Types.checkResponse(Types.java:209)
at com.xensource.xenapi.Connection.dispatch(Connection.java:368)
at
com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909)
at com.xensource.xenapi.VBDMetrics.getIoReadKbs(VBDMetrics.java:210)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.getVmStats(CitrixResourceBase.java:2841)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:2741)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:493)
at
com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
at
com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106)
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$101(ScheduledThreadPoolExecutor.java:165)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
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-02-10 14:28:56,635 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-427:ctx-8d999b63) Seq 2-1390027689: Response Received:
2014-02-10 14:28:56,635 DEBUG [c.c.a.t.Request] (StatsCollector-3:ctx-c97c67c1)
Seq 2-1390027689: Received: { Ans: , MgmtId: 214151488957798, via: 2, Ver: v1,
Flags: 10, { GetVmStatsAnswer } }
2014-02-10 14:28:56,992 DEBUG [c.c.s.StatsCollector]
(StatsCollector-2:ctx-4810db50) HostStatsCollector is running...
2014-02-10 14:28:57,002 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-19:ctx-25a37896) Seq 1-1759117329: Executing request
2014-02-10 14:28:57,231 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-19:ctx-25a37896) Seq 1-1759117329: Response Received:
2014-02-10 14:28:57,231 DEBUG [c.c.a.t.Request] (StatsCollector-2:ctx-4810db50)
Seq 1-1759117329: Received: { Ans: , MgmtId: 214151488957798, via: 1, Ver: v1,
Flags: 10, { GetHostStatsAnswer } }
2014-02-10 14:28:57,240 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-55:ctx-06ca3a2c) Seq 2-1390027690: Executing request
2014-02-10 14:28:57,420 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-55:ctx-06ca3a2c) Seq 2-1390027690: Response Received:
2014-02-10 14:28:57,421 DEBUG [c.c.a.t.Request] (StatsCollector-2:ctx-4810db50)
Seq 2-1390027690: Received: { Ans: , MgmtId: 214151488957798, via: 2, Ver: v1,
Flags: 10, { GetHostStatsAnswer } }
2014-02-10 14:28:58,757 DEBUG [c.c.a.ApiServlet] (catalina-exec-9:ctx-381be003)
===START=== 10.215.2.19 -- GET
command=listZonesid=cce32d06-91d9-47f0-90b5-766416d6add2response=jsonsessionkey=gJbfxiFXGjIJTBqBPlcyevZSM1g%3D_=1392076043914
Contrail:MS: Rebooting Xen host results in disconnected SR
--
Key: CLOUDSTACK-5777
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5777
[jira] [Commented] (CLOUDSTACK-6072) vxlan networks not deallocating vnet ids
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897331#comment-13897331
]
Yoshikazu Nojima commented on CLOUDSTACK-6072:
--
Marcus, Thank you for let me know.
Your assumption seems correct.
I will try to reproduce the bug, and fix it.
vxlan networks not deallocating vnet ids
Key: CLOUDSTACK-6072
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6072
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.3.0, 4.4.0
Reporter: Marcus Sorensen
Assignee: Yoshikazu Nojima
I noticed that we ran out of vxlan ids in our dev environment. It seems
perhaps due to calling 'super' in our shutdown method, but the 'super' method
filters out vxlan domain types.
./plugins/network-elements/vxlan/src/com/cloud/network/guru/VxlanGuestNetworkGuru.java
@Override
public void shutdown(NetworkProfile profile, NetworkOffering offering) {
NetworkVO networkObject = _networkDao.findById(profile.getId());
if (networkObject.getBroadcastDomainType() !=
BroadcastDomainType.Vxlan || networkObject.getBroadcastUri() == null) {
s_logger.warn(BroadcastUri is empty or incorrect for
guestnetwork + networkObject.getDisplayText());
return;
}
super.shutdown(profile, offering);
}
server/src/com/cloud/network/guru/GuestNetworkGuru.java
@Override
public void shutdown(NetworkProfile profile, NetworkOffering offering) {
if (profile.getBroadcastDomainType() == BroadcastDomainType.Vlan
profile.getBroadcastUri() != null
!offering.getSpecifyVlan()) {
s_logger.debug(Releasing vnet for the network id= +
profile.getId());
_dcDao.releaseVnet(profile.getBroadcastUri().getHost(),
profile.getDataCenterId(),
profile.getPhysicalNetworkId(), profile.getAccountId(),
profile.getReservationId());
ActionEventUtils.onCompletedActionEvent(UserContext.current().getCallerUserId(),
profile.getAccountId(),
EventVO.LEVEL_INFO, EventTypes.EVENT_ZONE_VLAN_RELEASE,
Released Zone Vlan:
+ profile.getBroadcastUri().getHost() + for Network:
+ profile.getId(), 0);
}
profile.setBroadcastUri(null);
}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6068) service/disk_offering_details: display flag should be set to true by default
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897398#comment-13897398 ] ASF subversion and git services commented on CLOUDSTACK-6068: - Commit 1cfbfab8162b82b30d797d4805112a75cfef3ce0 in branch refs/heads/4.3-forward from [~alena1108] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1cfbfab ] CLOUDSTACK-6068: set display flag to true in service/disk_offering_details tables service/disk_offering_details: display flag should be set to true by default Key: CLOUDSTACK-6068 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6068 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Priority: Critical Fix For: 4.3.0 There are 2 tables where details for service/disk offering details are stored: service_offering_details and disk_offering_details. Each table has display field (boolean) - if set to false, the detail will be displayed to admin only. Bug: initially the default value of the db field was set to false, so all the details were saved with 0 flag (although admin didn't intend it). But the API was working w/o checking this field before, so details with 0 were returned to the user. Then this API bug was fixed, and the details stopped returning to the user. Fix: we have to set the display flag to be 1 by default. Only when its defined otherwise in the API, this flag should be set to 0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6074) [Doc] System Implementation Guide
Radhika Nair created CLOUDSTACK-6074: Summary: [Doc] System Implementation Guide Key: CLOUDSTACK-6074 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6074 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Doc Reporter: Radhika Nair Priority: Minor Requirement from Iliyas Shirol, InMobi. System Implementation Guide which has all the set of activities and tracks everything while deploying a private cloud. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5519) [VMWARE] Cancel vCenter tasks if the task invoked by CloudStack failes with timeout error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kiran Koneti closed CLOUDSTACK-5519. The Vcenter operation is canceled once the operation is timed out in the CS. Hence closing the defect. [VMWARE] Cancel vCenter tasks if the task invoked by CloudStack failes with timeout error - Key: CLOUDSTACK-5519 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5519 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.2.1 Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.3.0 If a vCenter task takes more than 20 minutes(default vCenter session timeout) to complete, then CS errors out with Socket timeout exception but the the task continues to run in vCenter. Since there is mismatch in the state of the task between CloudStack and vCenter, If a task times out in Cloudstack we should cancel the running task in vCenter. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5332) Network offering don't use new system offering for router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kiran Koneti closed CLOUDSTACK-5332. Verified with the new 4.3 build and the correct offering is selected,hence closing the issue. Network offering don't use new system offering for router - Key: CLOUDSTACK-5332 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5332 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: CloudStack 4.2.0 CitrixXen 6.2 Reporter: Tomasz Zieba Assignee: Jessica Wang Fix For: 4.3.0 Reproduction steps: 1. Create new system offering for Virtual Router. 2. Create new Network Offering. From System Offering for Router dropdown list choose VirtualRouter offering you've created in first step. 3. Try to deploy VM choosing newly created network offering. Bug Created network still runs a Virtual Router based on default offering. In database we can see that network offering is related to default system offering for router. Expected result Created network should use new System Offering for Virtual Router. We think that this is a problem with GUI or sql insert query, because in sql table named Network_Offering in the column named Service_Offering_ID is null value (default for this column). -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5761) consoleproxy.session.max parameter is not honored in spinning up extra CPVMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N closed CLOUDSTACK-5761. - closing based on the comments from Kelven. consoleproxy.session.max parameter is not honored in spinning up extra CPVMs Key: CLOUDSTACK-5761 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5761 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.3branch with commit : 95b6a7b96dab1c77e25987d6fe6003b4447281f1 Reporter: Sanjeev N Assignee: Kelven Yang Priority: Critical Labels: hyper-V,, hyper-v, hyperv Fix For: 4.3.0 Attachments: management-server.rar [Hyper-v] consoleproxy.session.max parameter is not honored in spinning up extra CPVMs Steps to reproduce: 1.Bring up CS in advanced zone with Hyper-v cluster 2.Wait for the system vms to comeup 3.Deploy few guest vms 4.Open console view sessions for two guest vms 5. Set consoleproxy.session.max=2 and restart MS 6.Open console view for another vm Result: == Immediately continuous CPVMs spin up strated one after the other until the resources were available even though there were only 3 console view sessions opened. mysql select id,name,instance_name,state from vm_instance where name like v%VM; ++-+---+-+ | id | name| instance_name | state | ++-+---+-+ | 2 | v-2-VM | v-2-VM| Running | | 13 | v-13-VM | v-13-VM | Running | | 14 | v-14-VM | v-14-VM | Running | | 15 | v-15-VM | v-15-VM | Running | | 16 | v-16-VM | v-16-VM | Running | ++-+---+-+ 5 rows in set (0.00 sec) v-2-VM was the initial vm before restarting MS. Immediately after MS restart all the remaining cpvms spinned up. Observations: === I closed all the console view sessions and destroyed all the cpvms except the v-2-VM. Again CS started creating CPVMs even though there were no console view sessions opened. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5814) [Hyper-v] Nic hot plug-in does not happen if public IP is acquired from different vlan
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanjeev N closed CLOUDSTACK-5814.
-
Closing since it duplicates
https://issues.apache.org/jira/browse/CLOUDSTACK-5561
[Hyper-v] Nic hot plug-in does not happen if public IP is acquired from
different vlan
--
Key: CLOUDSTACK-5814
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5814
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller, Network Controller
Affects Versions: 4.3.0
Environment: Latest build from 4.3 branch with commit:
6f309b8a87d3376950a60234d399c6e3749ad1c7
Reporter: Sanjeev N
Priority: Critical
Labels: hyper-V,, hyper-v, hyperv
Fix For: 4.3.0
Attachments: management-server.rar
[Hyper-v] Nic hot plug-in does not happen if public IP is acquired from
different vlan
Steps to reproduce:
1.Bring up CS in advanced zone with hyper-v cluster
2.Create isolated guest network and deploy few vms in the network
3.Exhaust all the public IP addresses present in the zone (in user_ip_address
table set the allocated=now())
4.Add new public IP range in new vlan and new subnet
5.Acquire one ip address from the new ip range and configure PF and assign
one vm deployed at step2
Expected Result:
=
since the IP address acquired at step5 is from different vlan nic hot plug-in
should happen on the VR and the acquired ip address should be configured on
this new nic
Actual Result:
===
Nic hot plug-in does not happen and the acquired ip is configured on the
existing public interface which is eth2 on VR.
Following is the ip addr show command output from VR:
root@r-4-VM:~# ip addr show
1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether 02:00:67:79:00:02 brd ff:ff:ff:ff:ff:ff
inet 10.1.1.1/24 brd 10.1.1.255 scope global eth0
inet6 fe80::67ff:fe79:2/64 scope link
valid_lft forever preferred_lft forever
3: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether 02:00:57:ab:00:05 brd ff:ff:ff:ff:ff:ff
inet 10.147.40.230/23 brd 10.147.41.255 scope global eth1
inet6 fe80::57ff:feab:5/64 scope link
valid_lft forever preferred_lft forever
4: eth2: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether 06:78:3c:00:00:17 brd ff:ff:ff:ff:ff:ff
inet 10.147.48.5/24 brd 10.147.48.255 scope global eth2
inet 10.147.31.240/24 brd 10.147.31.255 scope global eth2
inet6 fe80::478:3cff:fe00:17/64 scope link
valid_lft forever preferred_lft forever
Log snippet from MS log :
2014-01-07 11:29:36,252 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-10:ctx-c9945336 ctx-4a2f8773) submit async job-62, details:
AsyncJobVO {id:62, userId: 2, accountId: 2, instanceType: IpAddress,
instanceId: 19, cmd:
org.apache.cloudstack.api.command.user.address.AssociateIPAddrCmd, cmdInfo:
{id:19,response:json,sessionkey:Yc2RY308FJ0FALdFfefofIWKnKY\u003d,cmdEventType:NET.IPASSIGN,ctxUserId:2,httpmethod:GET,_:1389074372490,ctxAccountId:2,networkid:d2b7326e-99f9-453e-9535-f6982da49e2f,ctxStartEventId:160},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 132129494109518, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-01-07 11:29:36,253 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Job-Executor-30:ctx-17a9f9c9) Add job-62 into job monitoring
2014-01-07 11:29:36,253 DEBUG [c.c.a.ApiServlet]
(catalina-exec-10:ctx-c9945336 ctx-4a2f8773) ===END=== 10.146.0.133 -- GET
command=associateIpAddressresponse=jsonsessionkey=Yc2RY308FJ0FALdFfefofIWKnKY%3Dnetworkid=d2b7326e-99f9-453e-9535-f6982da49e2f_=1389074372490
2014-01-07 11:29:36,256 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-30:ctx-17a9f9c9) Executing AsyncJobVO {id:62, userId: 2,
accountId: 2, instanceType: IpAddress, instanceId: 19, cmd:
org.apache.cloudstack.api.command.user.address.AssociateIPAddrCmd, cmdInfo:
{id:19,response:json,sessionkey:Yc2RY308FJ0FALdFfefofIWKnKY\u003d,cmdEventType:NET.IPASSIGN,ctxUserId:2,httpmethod:GET,_:1389074372490,ctxAccountId:2,networkid:d2b7326e-99f9-453e-9535-f6982da49e2f,ctxStartEventId:160},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode:
[jira] [Closed] (CLOUDSTACK-5644) [Hyper-v] VM live migration fails if IP address is given as primary storage server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N closed CLOUDSTACK-5644. - Closing based on the comments from Devdeep. [Hyper-v] VM live migration fails if IP address is given as primary storage server -- Key: CLOUDSTACK-5644 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5644 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Doc, Hypervisor Controller Affects Versions: 4.3.0 Environment: Hypervisor: Hyperv Storage: SMB for both primary and secondary storage Reporter: Sanjeev N Priority: Critical Labels: hyper-V,, hyper-v, hyperv Fix For: 4.3.0 [Hyper-v] VM live migration fails if IP address is given as primary storage server. In CS while adding primary storage server we can specify either the IP address of the SMB server or the Domain name . However if the storage server is domain joined then vm live migration only works if the domain name of the server is given while adding Primary Storage in the CS. And the domain name is case sensitive. Eg: If the primary storage domain name is : Host13 and domain is BLR then in CS give the storage details in the same way. If we specify the Server as host13 storage will be mounted on the hosts properly, but while migrating the vm the Domain joined hosts in the cluster will not get the access to the root disks present in the primary storage. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6054) [Hyper-v] vmsync is not working for hyperv
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897576#comment-13897576 ] ASF subversion and git services commented on CLOUDSTACK-6054: - Commit eef65ac776de171d83f9f532ac2dda6902117178 in branch refs/heads/4.3-forward from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=eef65ac ] CLOUDSTACK-6054: Changes for making vmsync work for hyper-v. Made changes to PingCommand and StartupCommand to return the state of all vms on the host. [Hyper-v] vmsync is not working for hyperv -- Key: CLOUDSTACK-6054 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6054 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 Reporter: Anshul Gangwar Assignee: Anshul Gangwar Fix For: 4.3.0 vmsync is not working for hyperv -- 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=13897592#comment-13897592 ] ASF subversion and git services commented on CLOUDSTACK-5674: - Commit 995e3f5b5d71d5f52d18e0c3260b8624e6b6251c in branch refs/heads/marvin from [~gpshilamkar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=995e3f5 ] Revert CLOUDSTACK-5674: Few new fixes This reverts commit 3493f17bad3b8b57778b62d464c5e7f910351cc0. [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. We deploy multiple zones with different hypervisor type in each zone. 3. Tests should cut down time and run across multiple zones with different hypervisor type in each zone, post deployment 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-6054) [Hyper-v] vmsync is not working for hyperv
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13897602#comment-13897602 ] ASF subversion and git services commented on CLOUDSTACK-6054: - Commit b86d45b0036482cfc9c9fc55f62954a1b9599188 in branch refs/heads/master from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b86d45b ] CLOUDSTACK-6054: Changes for making vmsync work for hyper-v. Made changes to PingCommand and StartupCommand to return the state of all vms on the host. [Hyper-v] vmsync is not working for hyperv -- Key: CLOUDSTACK-6054 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6054 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 Reporter: Anshul Gangwar Assignee: Anshul Gangwar Fix For: 4.3.0 vmsync is not working for hyperv -- This message was sent by Atlassian JIRA (v6.1.5#6160)
