[jira] [Closed] (CLOUDSTACK-3156) needs proper message for failing Add nic command when vmware tools is not installed or not running
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal closed CLOUDSTACK-3156.
--
> needs proper message for failing Add nic command when vmware tools is not
> installed or not running
> --
>
> Key: CLOUDSTACK-3156
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3156
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller, VMware
>Affects Versions: 4.2.0
> Environment: build:
> CloudPlatform-4.2-117-rhel6.3.tar.gz
>Reporter: shweta agarwal
>Assignee: Likitha Shetty
> Fix For: 4.3.0
>
>
> Repro steps:
> 1. Create a VMware zone
> 2. Create a centos VM on vmware zone
> 3. Create a network
> 4. Add this network to the VM
> Bug:
> Nic addition failed message is displayed without telling the cause for failure
> Expectation:
> Nic addition failed message should be displayed along with proper message of
> vmware tools is not installed or not running, cannot add nic to vm i-2-37-VM
> MS log clearly shows Reason for failure
> 2013-06-24 18:01:53,961 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-57:null) Seq 5-1643680454: Response Received:
> 2013-06-24 18:01:53,961 DEBUG [agent.transport.Request]
> (StatsCollector-3:null) Seq 5-1643680454: Received: { Ans: , MgmtId:
> 7159676928023, via: 5, Ver: v1, Flags: 10, { GetHostStatsAnswer } }
> 2013-06-24 18:01:53,968 DEBUG [vmware.resource.VmwareResource]
> (DirectAgent-138:10.147.40.24) vmware tools is not installed or not running,
> cannot add nic to vm i-2-37-VM
> 2013-06-24 18:01:53,976 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-138:null) Seq 5-1643680455: Response Received:
> 2013-06-24 18:01:53,976 DEBUG [agent.transport.Request]
> (DirectAgent-138:null) Seq 5-1643680455: Processing: { Ans: , MgmtId:
> 7159676928023, via: 5, Ver: v1, Flags: 110,
> [{"PlugNicAnswer":{"result":false,"details":"Unable to execute PlugNicCommand
> due to vmware tools is not installed or not running, cannot add nic to vm
> i-2-37-VM","wait":0}}] }
> 2013-06-24 18:01:53,977 DEBUG [agent.transport.Request]
> (Job-Executor-8:job-120) Seq 5-1643680455: Received: { Ans: , MgmtId:
> 7159676928023, via: 5, Ver: v1, Flags: 110, { PlugNicAnswer } }
> 2013-06-24 18:01:53,977 WARN [cloud.vm.UserVmManagerImpl]
> (Job-Executor-8:job-120) Unable to plug nic for VM[User|vmware] due to: due
> to: Unable to execute PlugNicCommand due to vmware tools is not installed or
> not running, cannot add nic to vm i-2-37-VM
> 2013-06-24 18:01:53,985 WARN [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-8:job-120) Failed to plug nic to the vm VM[User|vmware] in
> network Ntwk[226|Guest|8]
> 2013-06-24 18:01:53,978 DEBUG [agent.manager.AgentAttache]
> (DirectAgent-138:null) Seq 5-1643680455: No more commands found
> 2013-06-24 18:01:54,006 DEBUG [cloud.network.NetworkModelImpl]
> (Job-Executor-8:job-120) Service SecurityGroup is not supported in the
> network id=226
> 2013-06-24 18:01:54,027 DEBUG [cloud.network.NetworkManagerImpl]
> (Job-Executor-8:job-120) Removed nic id=97
> 2013-06-24 18:01:54,029 DEBUG [cloud.network.NetworkManagerImpl]
> (Job-Executor-8:job-120) Revoving nic secondary ip entry ...
> 2013-06-24 18:01:54,030 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-8:job-120) Unexpected exception while executing
> org.apache.cloudstack.api.command.user.vm.AddNicToVMCmd
> com.cloud.utils.exception.CloudRuntimeException: Unable to add NIC to
> VM[User|vmware]
> at
> com.cloud.vm.UserVmManagerImpl.addNicToVirtualMachine(UserVmManagerImpl.java:899)
> at
> org.apache.cloudstack.api.command.user.vm.AddNicToVMCmd.execute(AddNicToVMCmd.java:109)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:679)
> 2013-06-24 18:01:54,039 DEBUG [cloud.server.StatsCollector]
> (StatsCollector-3:null) StorageCollector is running...
> 2013-06-24 18:01:54,054 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-8:job-120) Complete async job-120, jobStatus: 2, resultCode:
> 530, result: Error Code: 530 Error text: Unable to a
[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-tabpanel&focusedCommentId=13905083#comment-13905083 ] ASF subversion and git services commented on CLOUDSTACK-5674: - Commit 47c5b638817784c68c77e4f2dcbfb9ae5d3d6ae9 in cloudstack's branch refs/heads/marvin from [~gpshilamkar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=47c5b63 ] CLOUDSTACK-5674: Fixed all BVTs and some marvin functions > [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] [Created] (CLOUDSTACK-6139) System.vm.use.local.storage global setting to zone setting
Rutger te Nijenhuis created CLOUDSTACK-6139: --- Summary: System.vm.use.local.storage global setting to zone setting Key: CLOUDSTACK-6139 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6139 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: Future Reporter: Rutger te Nijenhuis Move the global setting "system.vm.usr.local.storage - Indicates whether to use local storage pools or shared storage pools for system VMs." to zone level. Cloudstack allows local storage to be enabled at a per zone setting from zone details. The system VM's will however end up on either shared of local storage according to the global settings. Moving this setting to the zone level enables you to run zones with only local storage next to zones with only shared storage. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-6139) System.vm.use.local.storage global setting to zone setting
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wilder Rodrigues reassigned CLOUDSTACK-6139: Assignee: Wilder Rodrigues > System.vm.use.local.storage global setting to zone setting > -- > > Key: CLOUDSTACK-6139 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6139 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Affects Versions: Future >Reporter: Rutger te Nijenhuis >Assignee: Wilder Rodrigues > > Move the global setting "system.vm.usr.local.storage - Indicates whether to > use local storage pools or shared storage pools for system VMs." to zone > level. Cloudstack allows local storage to be enabled at a per zone setting > from zone details. The system VM's will however end up on either shared of > local storage according to the global settings. Moving this setting to the > zone level enables you to run zones with only local storage next to zones > with only shared storage. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6096) Using eject on Windows will prevent attaching ISO to the instance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13905794#comment-13905794 ] Francois Gaudreault commented on CLOUDSTACK-6096: - Also impact 4.3.0. > Using eject on Windows will prevent attaching ISO to the instance > - > > Key: CLOUDSTACK-6096 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6096 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server >Affects Versions: 4.2.1, 4.3.0 >Reporter: Francois Gaudreault > > Seen on 4.2.1 with XS6.2 SP1 with Windows 2008 template. > If you deploy a Windows template, and you attach an ISO to the instance, and > then you click on Eject from Windows, you will be able to detach the ISO from > CloudStack, but the SR on XenServer will remain. That will prevent a user to > re-attach the same or any other ISO to this instance. > The error we see when we try to reattach the ISO is misleading since it talks > about the URL not being found instead of the real cause. > 2014-02-12 20:13:44,060 DEBUG [agent.manager.DirectAgentAttache] > (DirectAgent-454:null) Seq 1-1166937279: Executing request > 2014-02-12 20:13:44,182 WARN [xen.resource.CitrixResourceBase] > (DirectAgent-454:null) can not getVDIbyLocationandSR > 223-2-d0e89fa1-fcaf-3180-ae86-5aeab5d7a8b1.iso > 2014-02-12 20:13:44,183 WARN [xen.resource.XenServerStorageProcessor] > (DirectAgent-454:null) Failed to attach iso: > com.cloud.utils.exception.CloudRuntimeException: Could not find ISO with URL: > To recover from this, I had to SSH to the XenServer Hypervisor, lazy unmount > the stuck SR, and remove it. Then I was able to reattach the ISO again. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6096) Using eject on Windows will prevent attaching ISO to the instance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francois Gaudreault updated CLOUDSTACK-6096: Affects Version/s: 4.3.0 > Using eject on Windows will prevent attaching ISO to the instance > - > > Key: CLOUDSTACK-6096 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6096 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server >Affects Versions: 4.2.1, 4.3.0 >Reporter: Francois Gaudreault > > Seen on 4.2.1 with XS6.2 SP1 with Windows 2008 template. > If you deploy a Windows template, and you attach an ISO to the instance, and > then you click on Eject from Windows, you will be able to detach the ISO from > CloudStack, but the SR on XenServer will remain. That will prevent a user to > re-attach the same or any other ISO to this instance. > The error we see when we try to reattach the ISO is misleading since it talks > about the URL not being found instead of the real cause. > 2014-02-12 20:13:44,060 DEBUG [agent.manager.DirectAgentAttache] > (DirectAgent-454:null) Seq 1-1166937279: Executing request > 2014-02-12 20:13:44,182 WARN [xen.resource.CitrixResourceBase] > (DirectAgent-454:null) can not getVDIbyLocationandSR > 223-2-d0e89fa1-fcaf-3180-ae86-5aeab5d7a8b1.iso > 2014-02-12 20:13:44,183 WARN [xen.resource.XenServerStorageProcessor] > (DirectAgent-454:null) Failed to attach iso: > com.cloud.utils.exception.CloudRuntimeException: Could not find ISO with URL: > To recover from this, I had to SSH to the XenServer Hypervisor, lazy unmount > the stuck SR, and remove it. Then I was able to reattach the ISO again. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6015) Write Sellenium tests for the UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13905877#comment-13905877 ] Yichi Lu commented on CLOUDSTACK-6015: -- https://reviews.apache.org/r/18277/ > Write Sellenium tests for the UI > > > Key: CLOUDSTACK-6015 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6015 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.4.0 >Reporter: sebastien goasguen > Labels: gsoc2014 > > To increase tests coverage for CloudStack we need to write a test suite for > the UI. Using Sellenium we can write these tests for multiple browsers and > export everything in Python. > http://docs.seleniumhq.org > These will be used with the unittest and the integration tests to make > CloudStack higher quality. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5883) unable to copy vmware routing template to primary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13905936#comment-13905936 ] Sudha Ponnaganti commented on CLOUDSTACK-5883: -- Praveena, The template you are using is incorrect. You need to use the one from download.cloud.com thanks /sudha > unable to copy vmware routing template to primary storage > - > > Key: CLOUDSTACK-5883 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5883 > 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: CloudStack > branch 4.3, 9ed4ab731fc5d722e3e0b819958ec8a2f4beccdb > vCenter vApp: vSphere 5.1 > Hypervisor: VMware ESXi, 5.1.0, 799733 >Reporter: Hugo Trippaers >Assignee: Animesh Chaturvedi >Priority: Blocker > Fix For: 4.3.0 > > > The following error is observed while doing a clean installation: > 2014-01-16 10:22:00,521 ERROR [c.c.s.r.VmwareStorageProcessor] > (DirectAgent-6:ctx-a6667180 10.200.23.49) Unable to copy templa > te to primary storage due to exception:Exception: > javax.xml.ws.soap.SOAPFaultException > Message: > Required parameter spec is missing > while parsing call information for method ImportVApp > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method importVApp > on object of type vim.ResourcePool > at line 1, column 0 > javax.xml.ws.soap.SOAPFaultException: > Required parameter spec is missing > while parsing call information for method ImportVApp > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method importVApp > on object of type vim.ResourcePool > at line 1, column 0 > at > com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5883) unable to copy vmware routing template to primary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13906190#comment-13906190 ] Hugo Trippaers commented on CLOUDSTACK-5883: Sudha, The build procedure in the source code should produce a valid template, are you using an image that was build using alternative means for the QA tests? You should be using the latest template from the jenkins,buildacloud.org in the release branch for all tests. > unable to copy vmware routing template to primary storage > - > > Key: CLOUDSTACK-5883 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5883 > 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: CloudStack > branch 4.3, 9ed4ab731fc5d722e3e0b819958ec8a2f4beccdb > vCenter vApp: vSphere 5.1 > Hypervisor: VMware ESXi, 5.1.0, 799733 >Reporter: Hugo Trippaers >Assignee: Animesh Chaturvedi >Priority: Blocker > Fix For: 4.3.0 > > > The following error is observed while doing a clean installation: > 2014-01-16 10:22:00,521 ERROR [c.c.s.r.VmwareStorageProcessor] > (DirectAgent-6:ctx-a6667180 10.200.23.49) Unable to copy templa > te to primary storage due to exception:Exception: > javax.xml.ws.soap.SOAPFaultException > Message: > Required parameter spec is missing > while parsing call information for method ImportVApp > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method importVApp > on object of type vim.ResourcePool > at line 1, column 0 > javax.xml.ws.soap.SOAPFaultException: > Required parameter spec is missing > while parsing call information for method ImportVApp > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method importVApp > on object of type vim.ResourcePool > at line 1, column 0 > at > com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (CLOUDSTACK-5883) unable to copy vmware routing template to primary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13906190#comment-13906190 ] Hugo Trippaers edited comment on CLOUDSTACK-5883 at 2/19/14 10:14 PM: -- Sudha, The build procedure in the source code should produce a valid template, are you using an image that was build using alternative means for the QA tests? You should be using the latest template from the jenkins,buildacloud.org in the release branch for all tests. Praveena, Do you happen to have the cloud.log from the secondary storage VM? That one should have the real error that indicates what is wrong with the template. I'll try to reproduce it as well. was (Author: htrippaers): Sudha, The build procedure in the source code should produce a valid template, are you using an image that was build using alternative means for the QA tests? You should be using the latest template from the jenkins,buildacloud.org in the release branch for all tests. > unable to copy vmware routing template to primary storage > - > > Key: CLOUDSTACK-5883 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5883 > 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: CloudStack > branch 4.3, 9ed4ab731fc5d722e3e0b819958ec8a2f4beccdb > vCenter vApp: vSphere 5.1 > Hypervisor: VMware ESXi, 5.1.0, 799733 >Reporter: Hugo Trippaers >Assignee: Animesh Chaturvedi >Priority: Blocker > Fix For: 4.3.0 > > > The following error is observed while doing a clean installation: > 2014-01-16 10:22:00,521 ERROR [c.c.s.r.VmwareStorageProcessor] > (DirectAgent-6:ctx-a6667180 10.200.23.49) Unable to copy templa > te to primary storage due to exception:Exception: > javax.xml.ws.soap.SOAPFaultException > Message: > Required parameter spec is missing > while parsing call information for method ImportVApp > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method importVApp > on object of type vim.ResourcePool > at line 1, column 0 > javax.xml.ws.soap.SOAPFaultException: > Required parameter spec is missing > while parsing call information for method ImportVApp > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method importVApp > on object of type vim.ResourcePool > at line 1, column 0 > at > com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6140) UI - template - detailView - move fields that are used more often to the top.
Jessica Wang created CLOUDSTACK-6140: Summary: UI - template - detailView - move fields that are used more often to the top. Key: CLOUDSTACK-6140 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6140 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Reporter: Jessica Wang Assignee: Jessica Wang -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-6140) UI - template - detailView - move fields that are used more often to the top.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang closed CLOUDSTACK-6140. > UI - template - detailView - move fields that are used more often to the top. > - > > Key: CLOUDSTACK-6140 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6140 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Jessica Wang > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-6140) UI - template - detailView - move fields that are used more often to the top.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-6140. -- Resolution: Fixed > UI - template - detailView - move fields that are used more often to the top. > - > > Key: CLOUDSTACK-6140 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6140 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Jessica Wang > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6140) UI - template - detailView - move fields that are used more often to the top.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13906274#comment-13906274 ] ASF subversion and git services commented on CLOUDSTACK-6140: - Commit c93b0967ef5278049d0940566eb455b38d3e5cbe in cloudstack's branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c93b096 ] CLOUDSTACK-6140: UI - template - detailView - move fields that are used more often to the top. > UI - template - detailView - move fields that are used more often to the top. > - > > Key: CLOUDSTACK-6140 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6140 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Jessica Wang > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5883) unable to copy vmware routing template to primary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13906280#comment-13906280 ] Rayees Namathponnan commented on CLOUDSTACK-5883: - I tested this issue with latest 4.3 build commit 307ad15bb68179129b8eadeaed115f5d088adfd9 I used template http://download.cloud.com/templates/4.3/systemvm64template-2014-01-14-master-vmware.ova and ESXi and Vcenter 5.1 I didnt observed the issue reported in this defect, > unable to copy vmware routing template to primary storage > - > > Key: CLOUDSTACK-5883 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5883 > 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: CloudStack > branch 4.3, 9ed4ab731fc5d722e3e0b819958ec8a2f4beccdb > vCenter vApp: vSphere 5.1 > Hypervisor: VMware ESXi, 5.1.0, 799733 >Reporter: Hugo Trippaers >Assignee: Animesh Chaturvedi >Priority: Blocker > Fix For: 4.3.0 > > > The following error is observed while doing a clean installation: > 2014-01-16 10:22:00,521 ERROR [c.c.s.r.VmwareStorageProcessor] > (DirectAgent-6:ctx-a6667180 10.200.23.49) Unable to copy templa > te to primary storage due to exception:Exception: > javax.xml.ws.soap.SOAPFaultException > Message: > Required parameter spec is missing > while parsing call information for method ImportVApp > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method importVApp > on object of type vim.ResourcePool > at line 1, column 0 > javax.xml.ws.soap.SOAPFaultException: > Required parameter spec is missing > while parsing call information for method ImportVApp > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method importVApp > on object of type vim.ResourcePool > at line 1, column 0 > at > com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5883) unable to copy vmware routing template to primary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13906286#comment-13906286 ] Rayees Namathponnan commented on CLOUDSTACK-5883: - Hi Hugo, Vmware template are not built from jenkins.cloud.org, for vmware there are some manual steps required please see the docs https://cwiki.apache.org/confluence/display/CLOUDSTACK/Build+Your+Own+SystemVM+Templates > unable to copy vmware routing template to primary storage > - > > Key: CLOUDSTACK-5883 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5883 > 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: CloudStack > branch 4.3, 9ed4ab731fc5d722e3e0b819958ec8a2f4beccdb > vCenter vApp: vSphere 5.1 > Hypervisor: VMware ESXi, 5.1.0, 799733 >Reporter: Hugo Trippaers >Assignee: Animesh Chaturvedi >Priority: Blocker > Fix For: 4.3.0 > > > The following error is observed while doing a clean installation: > 2014-01-16 10:22:00,521 ERROR [c.c.s.r.VmwareStorageProcessor] > (DirectAgent-6:ctx-a6667180 10.200.23.49) Unable to copy templa > te to primary storage due to exception:Exception: > javax.xml.ws.soap.SOAPFaultException > Message: > Required parameter spec is missing > while parsing call information for method ImportVApp > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method importVApp > on object of type vim.ResourcePool > at line 1, column 0 > javax.xml.ws.soap.SOAPFaultException: > Required parameter spec is missing > while parsing call information for method ImportVApp > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method importVApp > on object of type vim.ResourcePool > at line 1, column 0 > at > com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5883) unable to copy vmware routing template to primary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13906329#comment-13906329 ] Animesh Chaturvedi commented on CLOUDSTACK-5883: Hugo, We had fixed the templates to be used in 4.3 and reflected the links in database after uploading to download.cloud.com Here are the links: HyperV: http://download.cloud.com/templates/4.3/systemvm64template-2013-12-23-hyperv.vhd.bz2 KVM: http://download.cloud.com/templates/4.3/systemvm64template-2014-01-14-master-kvm.qcow2.bz2 VMWare: http://download.cloud.com/templates/4.3/systemvm64template-2014-01-14-master-vmware.ova Xen: http://download.cloud.com/templates/4.3/systemvm64template-2014-01-14-master-xen.vhd.bz2 Unless there is a discussed change that requires updating the templates we use these published templates. > unable to copy vmware routing template to primary storage > - > > Key: CLOUDSTACK-5883 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5883 > 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: CloudStack > branch 4.3, 9ed4ab731fc5d722e3e0b819958ec8a2f4beccdb > vCenter vApp: vSphere 5.1 > Hypervisor: VMware ESXi, 5.1.0, 799733 >Reporter: Hugo Trippaers >Assignee: Animesh Chaturvedi >Priority: Blocker > Fix For: 4.3.0 > > > The following error is observed while doing a clean installation: > 2014-01-16 10:22:00,521 ERROR [c.c.s.r.VmwareStorageProcessor] > (DirectAgent-6:ctx-a6667180 10.200.23.49) Unable to copy templa > te to primary storage due to exception:Exception: > javax.xml.ws.soap.SOAPFaultException > Message: > Required parameter spec is missing > while parsing call information for method ImportVApp > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method importVApp > on object of type vim.ResourcePool > at line 1, column 0 > javax.xml.ws.soap.SOAPFaultException: > Required parameter spec is missing > while parsing call information for method ImportVApp > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method importVApp > on object of type vim.ResourcePool > at line 1, column 0 > at > com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6096) Using eject on Windows will prevent attaching ISO to the instance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta updated CLOUDSTACK-6096: Fix Version/s: 4.4.0 > Using eject on Windows will prevent attaching ISO to the instance > - > > Key: CLOUDSTACK-6096 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6096 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server >Affects Versions: 4.2.1, 4.3.0 >Reporter: Francois Gaudreault > Fix For: 4.4.0 > > > Seen on 4.2.1 with XS6.2 SP1 with Windows 2008 template. > If you deploy a Windows template, and you attach an ISO to the instance, and > then you click on Eject from Windows, you will be able to detach the ISO from > CloudStack, but the SR on XenServer will remain. That will prevent a user to > re-attach the same or any other ISO to this instance. > The error we see when we try to reattach the ISO is misleading since it talks > about the URL not being found instead of the real cause. > 2014-02-12 20:13:44,060 DEBUG [agent.manager.DirectAgentAttache] > (DirectAgent-454:null) Seq 1-1166937279: Executing request > 2014-02-12 20:13:44,182 WARN [xen.resource.CitrixResourceBase] > (DirectAgent-454:null) can not getVDIbyLocationandSR > 223-2-d0e89fa1-fcaf-3180-ae86-5aeab5d7a8b1.iso > 2014-02-12 20:13:44,183 WARN [xen.resource.XenServerStorageProcessor] > (DirectAgent-454:null) Failed to attach iso: > com.cloud.utils.exception.CloudRuntimeException: Could not find ISO with URL: > To recover from this, I had to SSH to the XenServer Hypervisor, lazy unmount > the stuck SR, and remove it. Then I was able to reattach the ISO again. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6141) Failed to "backup" snapshot when using S3 secondary storage
Toshio Iwasaki created CLOUDSTACK-6141:
--
Summary: Failed to "backup" snapshot when using S3 secondary
storage
Key: CLOUDSTACK-6141
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6141
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Snapshot
Affects Versions: 4.2.1
Environment: CentOS 6.5/S3 secondary storage/NFS primary
storage/qemu-img 0.12.1
Reporter: Toshio Iwasaki
Priority: Minor
it seems that
"/usr/share/cloudstack-common/scripts/storage/qcow2/managesnapshot.sh" isn't
working with qemu-img 0.12.1.
==
backup_snapshot()
:
$qemu_img convert -f qcow2 -O qcow2 -s $snapshotname $disk $destPath/$destName
>& /dev/null
==
qemu-img(ver 0.12.1) don't recognize "-s" argument.
- managementserver.log
2014-02-19 09:34:49,155 DEBUG [agent.transport.Request]
(AgentManager-Handler-13:null) Seq 8-1727727724: Processing: { Ans: , MgmtId:
18005771460084, via: 8, Ver: v1, Flags: 110,
[{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"result":false,"details":"Failed
to backup 6005d4e1-b053-4339-ace5-5a1ba333b645 for disk
/mnt/58e3a408-13e7-3621-8141-78dc653fed07/5fba40b9-c299-4c79-898c-cad18d41cae8
to /mnt/d858e5dd-42f4-3bca-be0c-b667a5322b4e/snapshots/2/58","wait":0}}] }
and agent.log
2014-02-19 09:34:41,843 DEBUG [kvm.storage.KVMStorageProcessor]
(agentRequest-Handler-3:null) Executing:
/usr/share/cloudstack-common/scripts/storage/qcow2/managesnapshot.sh -b
/mnt/58e3a408-13e7-3621-8141-78dc653fed07/5fba40b9-c299-4c79-898c-cad18d41cae8
-n 6005d4e1-b053-4339-ace5-5a1ba333b645 -p
/mnt/d858e5dd-42f4-3bca-be0c-b667a5322b4e/snapshots/2/58 -t
6005d4e1-b053-4339-ace5-5a1ba333b645
2014-02-19 09:34:41,964 DEBUG [kvm.storage.KVMStorageProcessor]
(agentRequest-Handler-3:null) Exit value is 2
2014-02-19 09:34:41,965 DEBUG [kvm.storage.KVMStorageProcessor]
(agentRequest-Handler-3:null) Failed to backup
6005d4e1-b053-4339-ace5-5a1ba333b645 for disk
/mnt/58e3a408-13e7-3621-8141-78dc653fed07/5fba40b9-c299-4c79-898c-cad18d41cae8
to /mnt/d858e5dd-42f4-3bca-be0c-b667a5322b4e/snapshots/2/58
2014-02-19 09:34:41,965 DEBUG [kvm.storage.KVMStorageProcessor]
(agentRequest-Handler-3:null) Failed to backup snaptshot: Failed to backup
6005d4e1-b053-4339-ace5-5a1ba333b645 for disk
/mnt/58e3a408-13e7-3621-8141-78dc653fed07/5fba40b9-c299-4c79-898c-cad18d41cae8
to /mnt/d858e5dd-42f4-3bca-be0c-b667a5322b4e/snapshots/2/58
#I'm afraid that im not good at english...
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-4744) updateVolume needs more changes in the context of "Ability to have better control over first class objects in CS" feature
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta updated CLOUDSTACK-4744: Description: updateVolume was enhanced with "path" parameter as a part of the "Ability to have better control over first class objects in CS" feature. It allows Admin to change path for the volume assuming that the admin knows volume location/name on the primary storage. In addition to that, following fields have to be updatable as well: * state * pool_id (primary storage id) * chaininfo was: updateVolume was enhanced with "path" parameter as a part of the "Ability to have better control over first class objects in CS" feature. It allows Admin to change path for the volume assuming that the admin knows volume location/name on the primary storage. In addition to that, following fields have to be updatable as well: * state * pool_id (primary storage id) > updateVolume needs more changes in the context of "Ability to have better > control over first class objects in CS" feature > - > > Key: CLOUDSTACK-4744 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4744 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Alena Prokharchyk >Assignee: Alena Prokharchyk > Fix For: Future > > > updateVolume was enhanced with "path" parameter as a part of the "Ability to > have better control over first class objects in CS" feature. It allows Admin > to change path for the volume assuming that the admin knows volume > location/name on the primary storage. > In addition to that, following fields have to be updatable as well: > * state > * pool_id (primary storage id) > * chaininfo -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-4744) updateVolume needs more changes in the context of "Ability to have better control over first class objects in CS" feature
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13906485#comment-13906485 ] ASF subversion and git services commented on CLOUDSTACK-4744: - Commit c171e2c3e430a8ddb27b54eabf1156f987ddc180 in cloudstack's branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c171e2c ] CLOUDSTACK-4744: Enhance root admin API updateVolume with chaininfo parameter as a part of "Better control over first party objects" feature. > updateVolume needs more changes in the context of "Ability to have better > control over first class objects in CS" feature > - > > Key: CLOUDSTACK-4744 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4744 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Alena Prokharchyk >Assignee: Alena Prokharchyk > Fix For: 4.4.0 > > > updateVolume was enhanced with "path" parameter as a part of the "Ability to > have better control over first class objects in CS" feature. It allows Admin > to change path for the volume assuming that the admin knows volume > location/name on the primary storage. > In addition to that, following fields have to be updatable as well: > * state > * pool_id (primary storage id) > * chaininfo -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-4744) updateVolume needs more changes in the context of "Ability to have better control over first class objects in CS" feature
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta updated CLOUDSTACK-4744: Fix Version/s: (was: Future) 4.4.0 > updateVolume needs more changes in the context of "Ability to have better > control over first class objects in CS" feature > - > > Key: CLOUDSTACK-4744 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4744 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Alena Prokharchyk >Assignee: Alena Prokharchyk > Fix For: 4.4.0 > > > updateVolume was enhanced with "path" parameter as a part of the "Ability to > have better control over first class objects in CS" feature. It allows Admin > to change path for the volume assuming that the admin knows volume > location/name on the primary storage. > In addition to that, following fields have to be updatable as well: > * state > * pool_id (primary storage id) > * chaininfo -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6047) Make Virtual Router to aggregate execution of commands
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13906571#comment-13906571 ] ASF subversion and git services commented on CLOUDSTACK-6047: - Commit 8b341b0639b1947a71df29d409948eb96e238499 in cloudstack's branch refs/heads/master from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8b341b0 ] CLOUDSTACK-6047: Add generic wrapper for group answer needed commands > Make Virtual Router to aggregate execution of commands > -- > > Key: CLOUDSTACK-6047 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6047 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller, Virtual Router >Reporter: Sheng Yang >Assignee: Sheng Yang >Priority: Blocker > Fix For: 4.4.0 > > > Currently VR has an scalability issue during the large deployment. Everytime > when VR need to be re-create or reboot, CloudStack would send lots of > programming commands to it. VR would treat them as individual commands then > execute them. In large deployment, it would take tens of minutes or even > hours to complete all the necessary updates, like setup DHCP and programming > firewall. > For example, in the past, everytime we setup DHCP in VR, we need to restart > dnsmasq service for every programming, which is very time consuming. Though > we've introduced a way to reload without restart dnsmasq, but the same issue > existed with apache2 and other services as well. And every SSH to VR would > also time consuming. > The new approach of reprogramming VR, would help greatly on this issue, and > hopefully great reduce the VR programming time. It would introduce a > mechanism to "aggregate" the commands to be executed, and do it in one batch > inside VR. And restart the related services(if necesary) only after the whole > batch is completed. The configuration would be transfer to VR in one piece as > well, eliminate any unnecessary ssh. > We would expect in such scenario, most configuration would only be text > update and involve no more time consuming operations. We would leave every > possible time consuming operation to the end of execution of aggregated > commands. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6047) Make Virtual Router to aggregate execution of commands
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13906569#comment-13906569 ] ASF subversion and git services commented on CLOUDSTACK-6047: - Commit ebf7ee40b11cf50c99d7699100ea8d98862fb6e9 in cloudstack's branch refs/heads/master from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ebf7ee4 ] CLOUDSTACK-6047: Generalize execution in VirtualRoutingResource > Make Virtual Router to aggregate execution of commands > -- > > Key: CLOUDSTACK-6047 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6047 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller, Virtual Router >Reporter: Sheng Yang >Assignee: Sheng Yang >Priority: Blocker > Fix For: 4.4.0 > > > Currently VR has an scalability issue during the large deployment. Everytime > when VR need to be re-create or reboot, CloudStack would send lots of > programming commands to it. VR would treat them as individual commands then > execute them. In large deployment, it would take tens of minutes or even > hours to complete all the necessary updates, like setup DHCP and programming > firewall. > For example, in the past, everytime we setup DHCP in VR, we need to restart > dnsmasq service for every programming, which is very time consuming. Though > we've introduced a way to reload without restart dnsmasq, but the same issue > existed with apache2 and other services as well. And every SSH to VR would > also time consuming. > The new approach of reprogramming VR, would help greatly on this issue, and > hopefully great reduce the VR programming time. It would introduce a > mechanism to "aggregate" the commands to be executed, and do it in one batch > inside VR. And restart the related services(if necesary) only after the whole > batch is completed. The configuration would be transfer to VR in one piece as > well, eliminate any unnecessary ssh. > We would expect in such scenario, most configuration would only be text > update and involve no more time consuming operations. We would leave every > possible time consuming operation to the end of execution of aggregated > commands. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6047) Make Virtual Router to aggregate execution of commands
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13906572#comment-13906572 ] ASF subversion and git services commented on CLOUDSTACK-6047: - Commit 711b3083701e8b9852714e1817a022f039bf3235 in cloudstack's branch refs/heads/master from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=711b308 ] CLOUDSTACK-6047: Introduce QueryCommand QueryCommand is a kind of command which request the state rather than configure. QueryCommands need to be executed immediately and cannot be aggregated. > Make Virtual Router to aggregate execution of commands > -- > > Key: CLOUDSTACK-6047 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6047 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller, Virtual Router >Reporter: Sheng Yang >Assignee: Sheng Yang >Priority: Blocker > Fix For: 4.4.0 > > > Currently VR has an scalability issue during the large deployment. Everytime > when VR need to be re-create or reboot, CloudStack would send lots of > programming commands to it. VR would treat them as individual commands then > execute them. In large deployment, it would take tens of minutes or even > hours to complete all the necessary updates, like setup DHCP and programming > firewall. > For example, in the past, everytime we setup DHCP in VR, we need to restart > dnsmasq service for every programming, which is very time consuming. Though > we've introduced a way to reload without restart dnsmasq, but the same issue > existed with apache2 and other services as well. And every SSH to VR would > also time consuming. > The new approach of reprogramming VR, would help greatly on this issue, and > hopefully great reduce the VR programming time. It would introduce a > mechanism to "aggregate" the commands to be executed, and do it in one batch > inside VR. And restart the related services(if necesary) only after the whole > batch is completed. The configuration would be transfer to VR in one piece as > well, eliminate any unnecessary ssh. > We would expect in such scenario, most configuration would only be text > update and involve no more time consuming operations. We would leave every > possible time consuming operation to the end of execution of aggregated > commands. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6047) Make Virtual Router to aggregate execution of commands
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13906570#comment-13906570 ] ASF subversion and git services commented on CLOUDSTACK-6047: - Commit 43b414416c7d25945079d0c105343d83455146f3 in cloudstack's branch refs/heads/master from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=43b4144 ] CLOUDSTACK-6047: Introduce GroupedAnswer In some cases, Network Element need multiple answer in one, then introduced e.g. IpAssocAnswer, SetFirewallAnswer, etc. But in fact they are basically the same. So introduce GroupedAnswer for them. > Make Virtual Router to aggregate execution of commands > -- > > Key: CLOUDSTACK-6047 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6047 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller, Virtual Router >Reporter: Sheng Yang >Assignee: Sheng Yang >Priority: Blocker > Fix For: 4.4.0 > > > Currently VR has an scalability issue during the large deployment. Everytime > when VR need to be re-create or reboot, CloudStack would send lots of > programming commands to it. VR would treat them as individual commands then > execute them. In large deployment, it would take tens of minutes or even > hours to complete all the necessary updates, like setup DHCP and programming > firewall. > For example, in the past, everytime we setup DHCP in VR, we need to restart > dnsmasq service for every programming, which is very time consuming. Though > we've introduced a way to reload without restart dnsmasq, but the same issue > existed with apache2 and other services as well. And every SSH to VR would > also time consuming. > The new approach of reprogramming VR, would help greatly on this issue, and > hopefully great reduce the VR programming time. It would introduce a > mechanism to "aggregate" the commands to be executed, and do it in one batch > inside VR. And restart the related services(if necesary) only after the whole > batch is completed. The configuration would be transfer to VR in one piece as > well, eliminate any unnecessary ssh. > We would expect in such scenario, most configuration would only be text > update and involve no more time consuming operations. We would leave every > possible time consuming operation to the end of execution of aggregated > commands. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6047) Make Virtual Router to aggregate execution of commands
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13906573#comment-13906573 ] ASF subversion and git services commented on CLOUDSTACK-6047: - Commit 3bbbda887f182443c266a43e21cf2b6918acf08f in cloudstack's branch refs/heads/master from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3bbbda8 ] CLOUDSTACK-6047: Introduce VR resource unit test > Make Virtual Router to aggregate execution of commands > -- > > Key: CLOUDSTACK-6047 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6047 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller, Virtual Router >Reporter: Sheng Yang >Assignee: Sheng Yang >Priority: Blocker > Fix For: 4.4.0 > > > Currently VR has an scalability issue during the large deployment. Everytime > when VR need to be re-create or reboot, CloudStack would send lots of > programming commands to it. VR would treat them as individual commands then > execute them. In large deployment, it would take tens of minutes or even > hours to complete all the necessary updates, like setup DHCP and programming > firewall. > For example, in the past, everytime we setup DHCP in VR, we need to restart > dnsmasq service for every programming, which is very time consuming. Though > we've introduced a way to reload without restart dnsmasq, but the same issue > existed with apache2 and other services as well. And every SSH to VR would > also time consuming. > The new approach of reprogramming VR, would help greatly on this issue, and > hopefully great reduce the VR programming time. It would introduce a > mechanism to "aggregate" the commands to be executed, and do it in one batch > inside VR. And restart the related services(if necesary) only after the whole > batch is completed. The configuration would be transfer to VR in one piece as > well, eliminate any unnecessary ssh. > We would expect in such scenario, most configuration would only be text > update and involve no more time consuming operations. We would leave every > possible time consuming operation to the end of execution of aggregated > commands. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6036) CloudStack stops the machine for no reason
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13906577#comment-13906577
]
Ryan Farrington commented on CLOUDSTACK-6036:
-
We are experiencing the same thing.
> CloudStack stops the machine for no reason
> ---
>
> Key: CLOUDSTACK-6036
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6036
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.1
> Environment: ACS 4.2.1 after upgrade from 3.0.2
> XCP 1.1
>Reporter: Tomasz Zieba
>Priority: Critical
>
> After the upgrade from version 3.0.2 to 4.2.1 appeared very strange error
> associated with self-stopping machine after changing the offering.
> Steps to reproduce:
> 1. Running instance of the machine
> 2. Stop with the operating system
> 3. Change offering of machine
> 4. Start the machine
> 5. Waiting for 10 minutes
> 6. CloudStack stops the machine for no reason
> 7. Restart the machine
> In the logs you can find information:
> 2014-02-05 06:27:00,974 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-316:null) 11. The VM i-41-824-VM is in Running state
> 2014-02-05 06:27:00,974 DEBUG [agent.transport.Request]
> (DirectAgent-316:null) Seq 50-1756626952: Processing: { Ans: , MgmtId:
> 160544475005497, via: 50, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.ClusterSyncAnswer":{"_clusterId":2,"_newStates":{"i-41-824-VM":{"t":"f32a4fee-b64e-4868-9c52-2a27e32d4c0e","u":"Running","v":"viridian:true;acpi:true;apic:true;pae:true;nx:false;timeoffset:0;cores-per-socket:4"}},"_isExecuted":false,"result":true,"wait":0}}]
> }
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Sending { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Executing: { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,383 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 9. The VM i-41-824-VM is in Stopping state
> 2014-02-05 06:36:27,625 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 10. The VM i-41-824-VM is in Stopped state
> You will notice that the stop of the machine corresponds to the component
> HA-Worker.
> Such operation after the upgrade is complicating work of users.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6128) Clean up over-permissive filesystem grants in Cloudstack
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13906582#comment-13906582
]
John Kinsella commented on CLOUDSTACK-6128:
---
Just noticed snapshots and volumes directories on secondary storage are also
777. Making a note here in case it's not spotted in the code.
> Clean up over-permissive filesystem grants in Cloudstack
>
>
> Key: CLOUDSTACK-6128
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6128
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: John Kinsella
> Labels: security
> Fix For: 4.4.0
>
>
> It's not uncommon to find Java code and scripts in ACS that are
> over-permissive in their attempts to grant UNIX filesystem permissions. The
> following is an example from
> com.cloud.hypervisor.vmware.manager.VmwareManagerImpl.prepareSecondaryStorage:
> script.add("-R", "777", mountPoint);
> We should understand and document the UNIX user, group, and filesystem
> ownership requirements. If we truely need wide-open filesystem permissions,
> that too should be documented.
> Also, the code should not be blindly attempting to change filesystem
> permissions and ignoring the result of the attempts. Code should first check
> to see if a change is necessary, then make the necessary change, and then
> inspect the results, not display an error that may or may not impact proper
> execution of the system.
> ;)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-3272) EventBus: add global config parameters to specify which category of events are published on event bus.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sonal Ojha reassigned CLOUDSTACK-3272: -- Assignee: Sonal Ojha > EventBus: add global config parameters to specify which category of events > are published on event bus. > -- > > Key: CLOUDSTACK-3272 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3272 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.1.0 >Reporter: Murali Reddy >Assignee: Sonal Ojha > Fix For: 4.3.0 > > > EventBus: add global config parameters to specify which category of events > are published on event bus. > Fix would need a boolean global config for each event category. > For e.g, if global config 'publish.action.events' is set to false then on > event bug action events are not published. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6047) Make Virtual Router to aggregate execution of commands
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13906617#comment-13906617 ] ASF subversion and git services commented on CLOUDSTACK-6047: - Commit d429be75a72d426be5f17b36c55024cbed3432bd in cloudstack's branch refs/heads/master from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d429be7 ] CLOUDSTACK-6047: Fix fail to enable VPN > Make Virtual Router to aggregate execution of commands > -- > > Key: CLOUDSTACK-6047 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6047 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller, Virtual Router >Reporter: Sheng Yang >Assignee: Sheng Yang >Priority: Blocker > Fix For: 4.4.0 > > > Currently VR has an scalability issue during the large deployment. Everytime > when VR need to be re-create or reboot, CloudStack would send lots of > programming commands to it. VR would treat them as individual commands then > execute them. In large deployment, it would take tens of minutes or even > hours to complete all the necessary updates, like setup DHCP and programming > firewall. > For example, in the past, everytime we setup DHCP in VR, we need to restart > dnsmasq service for every programming, which is very time consuming. Though > we've introduced a way to reload without restart dnsmasq, but the same issue > existed with apache2 and other services as well. And every SSH to VR would > also time consuming. > The new approach of reprogramming VR, would help greatly on this issue, and > hopefully great reduce the VR programming time. It would introduce a > mechanism to "aggregate" the commands to be executed, and do it in one batch > inside VR. And restart the related services(if necesary) only after the whole > batch is completed. The configuration would be transfer to VR in one piece as > well, eliminate any unnecessary ssh. > We would expect in such scenario, most configuration would only be text > update and involve no more time consuming operations. We would leave every > possible time consuming operation to the end of execution of aggregated > commands. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (CLOUDSTACK-6036) CloudStack stops the machine for no reason
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13906577#comment-13906577
]
Ryan Farrington edited comment on CLOUDSTACK-6036 at 2/20/14 5:09 AM:
--
We are experiencing the same thing. After a little research the catalina.out
showed that the request was coming from the clients IP.
was (Author: gwyden):
We are experiencing the same thing.
> CloudStack stops the machine for no reason
> ---
>
> Key: CLOUDSTACK-6036
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6036
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.1
> Environment: ACS 4.2.1 after upgrade from 3.0.2
> XCP 1.1
>Reporter: Tomasz Zieba
>Priority: Critical
>
> After the upgrade from version 3.0.2 to 4.2.1 appeared very strange error
> associated with self-stopping machine after changing the offering.
> Steps to reproduce:
> 1. Running instance of the machine
> 2. Stop with the operating system
> 3. Change offering of machine
> 4. Start the machine
> 5. Waiting for 10 minutes
> 6. CloudStack stops the machine for no reason
> 7. Restart the machine
> In the logs you can find information:
> 2014-02-05 06:27:00,974 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-316:null) 11. The VM i-41-824-VM is in Running state
> 2014-02-05 06:27:00,974 DEBUG [agent.transport.Request]
> (DirectAgent-316:null) Seq 50-1756626952: Processing: { Ans: , MgmtId:
> 160544475005497, via: 50, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.ClusterSyncAnswer":{"_clusterId":2,"_newStates":{"i-41-824-VM":{"t":"f32a4fee-b64e-4868-9c52-2a27e32d4c0e","u":"Running","v":"viridian:true;acpi:true;apic:true;pae:true;nx:false;timeoffset:0;cores-per-socket:4"}},"_isExecuted":false,"result":true,"wait":0}}]
> }
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Sending { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Executing: { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,383 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 9. The VM i-41-824-VM is in Stopping state
> 2014-02-05 06:36:27,625 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 10. The VM i-41-824-VM is in Stopped state
> You will notice that the stop of the machine corresponds to the component
> HA-Worker.
> Such operation after the upgrade is complicating work of users.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6047) Make Virtual Router to aggregate execution of commands
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13906627#comment-13906627 ] ASF subversion and git services commented on CLOUDSTACK-6047: - Commit ca683958d831f19b94e57c234b9bf2946a52cc16 in cloudstack's branch refs/heads/master from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ca68395 ] CLOUDSTACK-6047: Fix typo > Make Virtual Router to aggregate execution of commands > -- > > Key: CLOUDSTACK-6047 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6047 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller, Virtual Router >Reporter: Sheng Yang >Assignee: Sheng Yang >Priority: Blocker > Fix For: 4.4.0 > > > Currently VR has an scalability issue during the large deployment. Everytime > when VR need to be re-create or reboot, CloudStack would send lots of > programming commands to it. VR would treat them as individual commands then > execute them. In large deployment, it would take tens of minutes or even > hours to complete all the necessary updates, like setup DHCP and programming > firewall. > For example, in the past, everytime we setup DHCP in VR, we need to restart > dnsmasq service for every programming, which is very time consuming. Though > we've introduced a way to reload without restart dnsmasq, but the same issue > existed with apache2 and other services as well. And every SSH to VR would > also time consuming. > The new approach of reprogramming VR, would help greatly on this issue, and > hopefully great reduce the VR programming time. It would introduce a > mechanism to "aggregate" the commands to be executed, and do it in one batch > inside VR. And restart the related services(if necesary) only after the whole > batch is completed. The configuration would be transfer to VR in one piece as > well, eliminate any unnecessary ssh. > We would expect in such scenario, most configuration would only be text > update and involve no more time consuming operations. We would leave every > possible time consuming operation to the end of execution of aggregated > commands. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-6035) error when displaying firewall rules
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Namita Chaudhari reassigned CLOUDSTACK-6035: Assignee: Namita Chaudhari > error when displaying firewall rules > > > Key: CLOUDSTACK-6035 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6035 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.1 > Environment: ACS 4.2.1 after upgrade from 3.0.2 >Reporter: Tomasz Zieba >Assignee: Namita Chaudhari > Attachments: cloudstack_ui_firewall_error.JPG > > > After upgrade from 3.0.2 to 4.2.1. > In version 4.2.1 there was an error when displaying firewall rules. > If the number of rules is too high UI displays an error (screenshot > attached). > In the illustrated case it is 26 rules. > There wasn't this bug in 3.0.2 version. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6142) Zone Wide Primary Store in Hyper-V
Rajesh Battala created CLOUDSTACK-6142: -- Summary: Zone Wide Primary Store in Hyper-V Key: CLOUDSTACK-6142 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6142 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.4.0 Reporter: Rajesh Battala Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-6130) [Automation] listPublicAdress is failing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hugo Trippaers reassigned CLOUDSTACK-6130: -- Assignee: Hugo Trippaers > [Automation] listPublicAdress is failing > - > > Key: CLOUDSTACK-6130 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6130 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.4.0 > Environment: xenserver 6.2, advanced zone >Reporter: Srikanteswararao Talluri >Assignee: Hugo Trippaers >Priority: Blocker > Fix For: 4.4.0 > > > List PublicAddress call is resulting in following error: > listpublicipaddresses failed, due to: errorCode: 530, errorText:DB Exception > on: com.mysql.jdbc.JDBC4PreparedStatement@4847303b: SELECT COUNT(*) FROM > user_ip_address INNER JOIN account ON user_ip_address.account_id=account.id > INNER JOIN vlan ON user_ip_address.vlan_db_id=vlan.id WHERE > user_ip_address.account_id=5 AND user_ip_address.allocated IS NOT NULL AND > (account.type != 'VirtualNetwork' ) AND (vlan.vlan_type = ** NOT SPECIFIED ** > ) > Link to automated test failure: > http://jenkins.buildacloud.org/view/cloudstack-qa-master/job/test-smoke-matrix-master/5/suite=test_network/testReport/integration.smoke.test_network/TestReleaseIP/test_releaseIP/ -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6143) Storage Live-Migration support for Hyper-V
Rajesh Battala created CLOUDSTACK-6143: -- Summary: Storage Live-Migration support for Hyper-V Key: CLOUDSTACK-6143 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6143 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.4.0 Reporter: Rajesh Battala Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6144) HA for guest VMs running Hyper-V
Rajesh Battala created CLOUDSTACK-6144: -- Summary: HA for guest VMs running Hyper-V Key: CLOUDSTACK-6144 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6144 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.4.0 Reporter: Rajesh Battala Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
