[jira] [Commented] (CLOUDSTACK-4903) [Automation] MS failed to start in 4.2.1 branch build
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14222746#comment-14222746 ] Alireza Eskandari commented on CLOUDSTACK-4903: --- I face with this problem on CS 4.3.1 and solve it! I found out that CS can not resolve servers hostname, so I set appropriate entry in /etc/hosts (in CentOS) and restart cloudstack-management. > [Automation] MS failed to start in 4.2.1 branch build > - > > Key: CLOUDSTACK-4903 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4903 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.2.1 >Reporter: Rayees Namathponnan >Assignee: Prachi Damle >Priority: Blocker > Fix For: 4.2.1 > > Attachments: CLOUDSTACK-4903.rar > > > Steps to reproduce > Step 1 : Create RPM build and install MS > Step 2 : Start MS and login > Actual result > Failed to login to management server, management server hang at below > location in MS log > 2013-10-20 10:59:10,748 INFO [utils.component.ComponentContext] (main:null) > Starting > com.cloud.bridge.persist.dao.BucketPolicyDaoImpl_EnhancerByCloudStack_2f857036 > 2013-10-20 10:59:10,749 INFO [utils.component.ComponentContext] (main:null) > Starting > com.cloud.bridge.persist.dao.SObjectItemDaoImpl_EnhancerByCloudStack_139827ff > 2013-10-20 10:59:10,749 INFO [utils.component.ComponentContext] (main:null) > Starting > com.cloud.bridge.persist.dao.MHostMountDaoImpl_EnhancerByCloudStack_689b5c0e > 2013-10-20 10:59:10,749 INFO [utils.component.ComponentContext] (main:null) > Starting > com.cloud.bridge.persist.dao.MHostDaoImpl_EnhancerByCloudStack_da837e4f > 2013-10-20 10:59:10,749 INFO [utils.component.ComponentContext] (main:null) > Starting > com.cloud.bridge.persist.dao.MultiPartUploadsDaoImpl_EnhancerByCloudStack_95f8237c > 2013-10-20 10:59:10,749 INFO [utils.component.ComponentContext] (main:null) > Starting > com.cloud.bridge.persist.dao.SBucketDaoImpl_EnhancerByCloudStack_67346047 > 2013-10-20 10:59:10,749 INFO [utils.component.ComponentContext] (main:null) > Starting > com.cloud.bridge.persist.dao.SAclDaoImpl_EnhancerByCloudStack_da2338c3 > 2013-10-20 10:59:10,749 INFO [utils.component.ComponentContext] (main:null) > Starting > com.cloud.bridge.persist.dao.CloudStackSvcOfferingDaoImpl_EnhancerByCloudStack_61483a61 > 2013-10-20 10:59:10,749 INFO [utils.component.ComponentContext] (main:null) > Starting > com.cloud.bridge.persist.dao.MultiPartPartsDaoImpl_EnhancerByCloudStack_61f24dfe > 2013-10-20 10:59:10,749 INFO [utils.component.ComponentContext] (main:null) > Starting > com.cloud.bridge.persist.dao.SHostDaoImpl_EnhancerByCloudStack_315f499 > 2013-10-20 10:59:10,749 INFO [utils.component.ComponentContext] (main:null) > Starting > com.cloud.bridge.persist.dao.SObjectDaoImpl_EnhancerByCloudStack_e9f0648a > 2013-10-20 10:59:10,750 INFO [utils.component.ComponentContext] (main:null) > Starting > com.cloud.bridge.persist.dao.CloudStackUserDaoImpl_EnhancerByCloudStack_e53ee9e4 > 2013-10-20 10:59:10,750 INFO [utils.component.ComponentContext] (main:null) > Starting > com.cloud.bridge.service.core.ec2.EC2Engine_EnhancerByCloudStack_3c7d493a > 2013-10-20 10:59:10,750 INFO [utils.component.ComponentContext] (main:null) > Starting > com.cloud.bridge.service.controller.s3.ServiceProvider_EnhancerByCloudStack_67ade3af > If you try to login, you will get below error > 2013-10-20 10:59:10,748 INFO [utils.component.ComponentContext] (main:null) > Starting > com.cloud.bridge.persist.dao.BucketPolicyDaoImpl_EnhancerByCloudStack_2f857036 > 2013-10-20 10:59:10,749 INFO [utils.component.ComponentContext] (main:null) > Starting > com.cloud.bridge.persist.dao.SObjectItemDaoImpl_EnhancerByCloudStack_139827ff > 2013-10-20 10:59:10,749 INFO [utils.component.ComponentContext] (main:null) > Starting > com.cloud.bridge.persist.dao.MHostMountDaoImpl_EnhancerByCloudStack_689b5c0e > 2013-10-20 10:59:10,749 INFO [utils.component.ComponentContext] (main:null) > Starting > com.cloud.bridge.persist.dao.MHostDaoImpl_EnhancerByCloudStack_da837e4f > 2013-10-20 10:59:10,749 INFO [utils.component.ComponentContext] (main:null) > Starting > com.cloud.bridge.persist.dao.MultiPartUploadsDaoImpl_EnhancerByCloudStack_95f8237c > 2013-10-20 10:59:10,749 INFO [utils.component.ComponentContext] (main:null) > Starting > com.cloud.bridge.persist.dao.SBucketDaoImpl_EnhancerByCloudStack_67346047 > 2013-10-20 10:59:10,749 INFO [utils.component.ComponentContext] (main:null) > Starting > com.cloud.bridge.persist.dao.SAclDaoImpl_EnhancerByCloudStack_da2338c3 > 2013-10-20 10:59:10,749 INFO [utils.
[jira] [Commented] (CLOUDSTACK-5696) [Vmsync]- Stopped state of VM is not synced to CS when VM is stopped outside of CS.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14222919#comment-14222919 ] Alireza Eskandari commented on CLOUDSTACK-5696: --- I test for this bug in CS 4.3.1 from ShapeBlue.com RPMs. Steps that I follow: - I turn off vm from vCenter - In CS VM state is still running - I restarted cloudstack-management service - VM state is still Runnig in CS after service restart - I click on "Stop Instance" in CS (while VM is stopped in vCenter) - VM state changes to Stopped in CS - I turn on VM from CS - Again I turn it off from vCenter and its state in CS is "Running" In the following link I put catalina and management-server logs from where I restarted the management-server: https://www.dropbox.com/s/h8wovb79hhh3zb3/log.tar.gz?dl=0 > [Vmsync]- Stopped state of VM is not synced to CS when VM is stopped outside > of CS. > --- > > Key: CLOUDSTACK-5696 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5696 > 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: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Kelven Yang >Priority: Critical > Fix For: 4.4.0 > > Attachments: management-server.rar > > > Pre Req: > Have few Vms deployed using Cloudstack. > Steps: > Outside of Cloudstack ,Stop VM > Vm continues to remain in "Running" state in CS , even though the change in > state is detected. > Following exception seen in management server logs: > 2013-12-26 17:02:10,026 DEBUG [c.c.v.VirtualMachineManagerImpl] > (DirectAgent-77:ctx-c28d9506) VM i-3-8-MyTestVM: cs state = Running and realSt > ate = Stopped > 2013-12-26 17:02:10,027 DEBUG [c.c.v.VirtualMachineManagerImpl] > (DirectAgent-77:ctx-c28d9506) VM i-3-8-MyTestVM: cs state = Running and realSt > ate = Stopped > 2013-12-26 17:02:10,027 DEBUG [c.c.h.HighAvailabilityManagerImpl] > (DirectAgent-77:ctx-c28d9506) VM does not require investigation so I'm marki > ng it as Stopped: VM[User|TestVM-tiny-host-1ps-0-1] > 2013-12-26 17:02:10,027 WARN [o.a.c.alerts] (DirectAgent-77:ctx-c28d9506) > alertType:: 8 // dataCenterId:: 1 // podId:: 1 // clusterId:: null > // message:: VM (name: TestVM-tiny-host-1ps-0-1, id: 8) stopped unexpectedly > on host id:1, availability zone id:1, pod id:1 > 2013-12-26 17:02:10,032 DEBUG [c.c.h.HighAvailabilityManagerImpl] > (DirectAgent-77:ctx-c28d9506) VM is not HA enabled so we're done. > 2013-12-26 17:02:10,032 WARN [c.c.a.m.DirectAgentAttache] > (DirectAgent-77:ctx-c28d9506) Seq 1-799145986: Exception caught > java.lang.NullPointerException > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1235) > at > com.cloud.ha.HighAvailabilityManagerImpl.scheduleRestart(HighAvailabilityManagerImpl.java:346) > at > com.cloud.vm.VirtualMachineManagerImpl.compareState(VirtualMachineManagerImpl.java:2686) > at > com.cloud.vm.VirtualMachineManagerImpl.deltaSync(VirtualMachineManagerImpl.java:2320) > at > com.cloud.vm.VirtualMachineManagerImpl.processAnswers(VirtualMachineManagerImpl.java:2797) > at com.cloud.agent.manager.AgentAttache.processAnswers(AgentAttache.java:296) > at > com.cloud.agent.manager.ClusteredDirectAgentAttache.processAnswers(ClusteredDirectAgentAttache.java:65) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:242) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thre
[jira] [Commented] (CLOUDSTACK-5696) [Vmsync]- Stopped state of VM is not synced to CS when VM is stopped outside of CS.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14229810#comment-14229810 ] Alireza Eskandari commented on CLOUDSTACK-5696: --- I build and test shapeblue patches on 4.3 until commit 0e0827f07c47289dc210dd50551c4c6df26d0573 but this bug is still exist. > [Vmsync]- Stopped state of VM is not synced to CS when VM is stopped outside > of CS. > --- > > Key: CLOUDSTACK-5696 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5696 > 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: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Kelven Yang >Priority: Critical > Fix For: 4.4.0 > > Attachments: management-server.rar > > > Pre Req: > Have few Vms deployed using Cloudstack. > Steps: > Outside of Cloudstack ,Stop VM > Vm continues to remain in "Running" state in CS , even though the change in > state is detected. > Following exception seen in management server logs: > 2013-12-26 17:02:10,026 DEBUG [c.c.v.VirtualMachineManagerImpl] > (DirectAgent-77:ctx-c28d9506) VM i-3-8-MyTestVM: cs state = Running and realSt > ate = Stopped > 2013-12-26 17:02:10,027 DEBUG [c.c.v.VirtualMachineManagerImpl] > (DirectAgent-77:ctx-c28d9506) VM i-3-8-MyTestVM: cs state = Running and realSt > ate = Stopped > 2013-12-26 17:02:10,027 DEBUG [c.c.h.HighAvailabilityManagerImpl] > (DirectAgent-77:ctx-c28d9506) VM does not require investigation so I'm marki > ng it as Stopped: VM[User|TestVM-tiny-host-1ps-0-1] > 2013-12-26 17:02:10,027 WARN [o.a.c.alerts] (DirectAgent-77:ctx-c28d9506) > alertType:: 8 // dataCenterId:: 1 // podId:: 1 // clusterId:: null > // message:: VM (name: TestVM-tiny-host-1ps-0-1, id: 8) stopped unexpectedly > on host id:1, availability zone id:1, pod id:1 > 2013-12-26 17:02:10,032 DEBUG [c.c.h.HighAvailabilityManagerImpl] > (DirectAgent-77:ctx-c28d9506) VM is not HA enabled so we're done. > 2013-12-26 17:02:10,032 WARN [c.c.a.m.DirectAgentAttache] > (DirectAgent-77:ctx-c28d9506) Seq 1-799145986: Exception caught > java.lang.NullPointerException > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1235) > at > com.cloud.ha.HighAvailabilityManagerImpl.scheduleRestart(HighAvailabilityManagerImpl.java:346) > at > com.cloud.vm.VirtualMachineManagerImpl.compareState(VirtualMachineManagerImpl.java:2686) > at > com.cloud.vm.VirtualMachineManagerImpl.deltaSync(VirtualMachineManagerImpl.java:2320) > at > com.cloud.vm.VirtualMachineManagerImpl.processAnswers(VirtualMachineManagerImpl.java:2797) > at com.cloud.agent.manager.AgentAttache.processAnswers(AgentAttache.java:296) > at > com.cloud.agent.manager.ClusteredDirectAgentAttache.processAnswers(ClusteredDirectAgentAttache.java:65) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:242) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8009) A secure password manager
Alireza Eskandari created CLOUDSTACK-8009: - Summary: A secure password manager Key: CLOUDSTACK-8009 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8009 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.4.0, 4.3.0, 4.2.0, 4.1.0, 4.0.0, 4.5.0 Reporter: Alireza Eskandari Password management service uses plain text for transferring password over network. In shared networks other instances can sniff traffics on port 8080 and see newly created passwords. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8019) Can't see custom service offering in the list of available service offerings
Alireza Eskandari created CLOUDSTACK-8019: - Summary: Can't see custom service offering in the list of available service offerings Key: CLOUDSTACK-8019 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8019 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.4.0, 4.3.0 Reporter: Alireza Eskandari Priority: Minor I create a Custom service offering (that I can change CPU and RAM later) I create an instance based on this service offering After VM deployment, I want to change service offering. In the dropdown of available service offering I don't see my custom service offering because it is already applied to this instance but I should use it again for its custom nature. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8019) Can't see custom service offering in the list of available service offerings
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14234273#comment-14234273 ] Alireza Eskandari commented on CLOUDSTACK-8019: --- I'm talking about a service offering that I create by myself which I select "Custom" in its configuration. > Can't see custom service offering in the list of available service offerings > - > > Key: CLOUDSTACK-8019 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8019 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0, 4.4.0 >Reporter: Alireza Eskandari >Priority: Minor > Labels: custom, offering, service, ui > > I create a Custom service offering (that I can change CPU and RAM later) > I create an instance based on this service offering > After VM deployment, I want to change service offering. > In the dropdown of available service offering I don't see my custom service > offering because it is already applied to this instance but I should use it > again for its custom nature. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8019) Can't see custom service offering in the list of available service offerings
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14234324#comment-14234324 ] Alireza Eskandari commented on CLOUDSTACK-8019: --- look at API doc for create service offering: http://cloudstack.apache.org/docs/api/apidocs-4.3/root_admin/createServiceOffering.html You can see "iscustomized" option In change service offering: http://cloudstack.apache.org/docs/api/apidocs-4.3/root_admin/changeServiceForVirtualMachine.html you see "details" that you can set amount of ram and cpu. > Can't see custom service offering in the list of available service offerings > - > > Key: CLOUDSTACK-8019 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8019 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0, 4.4.0 >Reporter: Alireza Eskandari >Priority: Minor > Labels: custom, offering, service, ui > > I create a Custom service offering (that I can change CPU and RAM later) > I create an instance based on this service offering > After VM deployment, I want to change service offering. > In the dropdown of available service offering I don't see my custom service > offering because it is already applied to this instance but I should use it > again for its custom nature. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5696) [Vmsync]- Stopped state of VM is not synced to CS when VM is stopped outside of CS.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14236337#comment-14236337 ] Alireza Eskandari commented on CLOUDSTACK-5696: --- For faster debugging: Please look at line 1993 in management-server.log and line 2279 in catalina.out These lines in where vmsync should work but it doesn't! Here is the log files: https://www.dropbox.com/s/h8wovb79hhh3zb3/log.tar.gz?dl=0 > [Vmsync]- Stopped state of VM is not synced to CS when VM is stopped outside > of CS. > --- > > Key: CLOUDSTACK-5696 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5696 > 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: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Kelven Yang >Priority: Critical > Fix For: 4.4.0 > > Attachments: management-server.rar > > > Pre Req: > Have few Vms deployed using Cloudstack. > Steps: > Outside of Cloudstack ,Stop VM > Vm continues to remain in "Running" state in CS , even though the change in > state is detected. > Following exception seen in management server logs: > 2013-12-26 17:02:10,026 DEBUG [c.c.v.VirtualMachineManagerImpl] > (DirectAgent-77:ctx-c28d9506) VM i-3-8-MyTestVM: cs state = Running and realSt > ate = Stopped > 2013-12-26 17:02:10,027 DEBUG [c.c.v.VirtualMachineManagerImpl] > (DirectAgent-77:ctx-c28d9506) VM i-3-8-MyTestVM: cs state = Running and realSt > ate = Stopped > 2013-12-26 17:02:10,027 DEBUG [c.c.h.HighAvailabilityManagerImpl] > (DirectAgent-77:ctx-c28d9506) VM does not require investigation so I'm marki > ng it as Stopped: VM[User|TestVM-tiny-host-1ps-0-1] > 2013-12-26 17:02:10,027 WARN [o.a.c.alerts] (DirectAgent-77:ctx-c28d9506) > alertType:: 8 // dataCenterId:: 1 // podId:: 1 // clusterId:: null > // message:: VM (name: TestVM-tiny-host-1ps-0-1, id: 8) stopped unexpectedly > on host id:1, availability zone id:1, pod id:1 > 2013-12-26 17:02:10,032 DEBUG [c.c.h.HighAvailabilityManagerImpl] > (DirectAgent-77:ctx-c28d9506) VM is not HA enabled so we're done. > 2013-12-26 17:02:10,032 WARN [c.c.a.m.DirectAgentAttache] > (DirectAgent-77:ctx-c28d9506) Seq 1-799145986: Exception caught > java.lang.NullPointerException > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1235) > at > com.cloud.ha.HighAvailabilityManagerImpl.scheduleRestart(HighAvailabilityManagerImpl.java:346) > at > com.cloud.vm.VirtualMachineManagerImpl.compareState(VirtualMachineManagerImpl.java:2686) > at > com.cloud.vm.VirtualMachineManagerImpl.deltaSync(VirtualMachineManagerImpl.java:2320) > at > com.cloud.vm.VirtualMachineManagerImpl.processAnswers(VirtualMachineManagerImpl.java:2797) > at com.cloud.agent.manager.AgentAttache.processAnswers(AgentAttache.java:296) > at > com.cloud.agent.manager.ClusteredDirectAgentAttache.processAnswers(ClusteredDirectAgentAttache.java:65) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:242) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-5696) [Vmsync]- Stopped state of VM is not synced to CS when VM is stopped outside of CS.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14236337#comment-14236337 ] Alireza Eskandari edited comment on CLOUDSTACK-5696 at 12/6/14 12:06 AM: - For faster debugging: Please look at line 1993 in management-server.log and line 2279 in catalina.out These lines are where vmsync should work but it doesn't! Here is the log files: https://www.dropbox.com/s/h8wovb79hhh3zb3/log.tar.gz?dl=0 was (Author: alireza): For faster debugging: Please look at line 1993 in management-server.log and line 2279 in catalina.out These lines in where vmsync should work but it doesn't! Here is the log files: https://www.dropbox.com/s/h8wovb79hhh3zb3/log.tar.gz?dl=0 > [Vmsync]- Stopped state of VM is not synced to CS when VM is stopped outside > of CS. > --- > > Key: CLOUDSTACK-5696 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5696 > 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: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Kelven Yang >Priority: Critical > Fix For: 4.4.0 > > Attachments: management-server.rar > > > Pre Req: > Have few Vms deployed using Cloudstack. > Steps: > Outside of Cloudstack ,Stop VM > Vm continues to remain in "Running" state in CS , even though the change in > state is detected. > Following exception seen in management server logs: > 2013-12-26 17:02:10,026 DEBUG [c.c.v.VirtualMachineManagerImpl] > (DirectAgent-77:ctx-c28d9506) VM i-3-8-MyTestVM: cs state = Running and realSt > ate = Stopped > 2013-12-26 17:02:10,027 DEBUG [c.c.v.VirtualMachineManagerImpl] > (DirectAgent-77:ctx-c28d9506) VM i-3-8-MyTestVM: cs state = Running and realSt > ate = Stopped > 2013-12-26 17:02:10,027 DEBUG [c.c.h.HighAvailabilityManagerImpl] > (DirectAgent-77:ctx-c28d9506) VM does not require investigation so I'm marki > ng it as Stopped: VM[User|TestVM-tiny-host-1ps-0-1] > 2013-12-26 17:02:10,027 WARN [o.a.c.alerts] (DirectAgent-77:ctx-c28d9506) > alertType:: 8 // dataCenterId:: 1 // podId:: 1 // clusterId:: null > // message:: VM (name: TestVM-tiny-host-1ps-0-1, id: 8) stopped unexpectedly > on host id:1, availability zone id:1, pod id:1 > 2013-12-26 17:02:10,032 DEBUG [c.c.h.HighAvailabilityManagerImpl] > (DirectAgent-77:ctx-c28d9506) VM is not HA enabled so we're done. > 2013-12-26 17:02:10,032 WARN [c.c.a.m.DirectAgentAttache] > (DirectAgent-77:ctx-c28d9506) Seq 1-799145986: Exception caught > java.lang.NullPointerException > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1235) > at > com.cloud.ha.HighAvailabilityManagerImpl.scheduleRestart(HighAvailabilityManagerImpl.java:346) > at > com.cloud.vm.VirtualMachineManagerImpl.compareState(VirtualMachineManagerImpl.java:2686) > at > com.cloud.vm.VirtualMachineManagerImpl.deltaSync(VirtualMachineManagerImpl.java:2320) > at > com.cloud.vm.VirtualMachineManagerImpl.processAnswers(VirtualMachineManagerImpl.java:2797) > at com.cloud.agent.manager.AgentAttache.processAnswers(AgentAttache.java:296) > at > com.cloud.agent.manager.ClusteredDirectAgentAttache.processAnswers(ClusteredDirectAgentAttache.java:65) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:242) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) -- This message was sent by Atlassian JIRA
[jira] [Created] (CLOUDSTACK-9994) Changing default network in multihomed VM
Alireza Eskandari created CLOUDSTACK-9994: - Summary: Changing default network in multihomed VM Key: CLOUDSTACK-9994 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9994 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: SystemVM, Virtual Router Affects Versions: 4.9.2.0 Reporter: Alireza Eskandari Environment: - vCenter 6.0u3 - CloudStack 4.9.2.0 (Shapeblue) Steps to reproduce: - Create a new VM on a single network - Attach a new NIC from other network - Change default network to new NIC Expected result: I expect that the default gateway of VM changes to new network. Actual result: The default gateway of VM remains unchanged. Rebooting VM doesn't help. Removing of non-default NIC (former default NIC) results in connection loss because of lack of default route on new default NIC. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CLOUDSTACK-9995) Orphaned primary storage after removing zone
Alireza Eskandari created CLOUDSTACK-9995: - Summary: Orphaned primary storage after removing zone Key: CLOUDSTACK-9995 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9995 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.9.2.0 Reporter: Alireza Eskandari Priority: Minor Environment: - vCenter 6.0u3 - CloudStack 4.9.2.0 (Shapeblue) Steps to reproduce: - Create a working zone - Try to remove the zone Expected result: - CloudStack leads you to remove all resources belongs to the zone completely. Actual result: - You can skip removing primary storage so you will face with an orphaned primary storage which you can not remove it at all. Workaround: 1- From database, set "removed" field of "cloud.data_center" table to NULL 2- Remove the primary storage 3- Remove the zone -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CLOUDSTACK-10033) updateResourceCount wrong result with dynamic compute offerings
Alireza Eskandari created CLOUDSTACK-10033: -- Summary: updateResourceCount wrong result with dynamic compute offerings Key: CLOUDSTACK-10033 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10033 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API, Management Server, Usage Affects Versions: 4.9.2.0 Reporter: Alireza Eskandari Environment: - vCenter 6.0u3 - CloudStack 4.9.2.0 (Shapeblue) Steps to reproduce: - Create VM with dynamic compute offering - Call "updateResourceCount" for related account - Call "listAccounts" to view resource statistic for related account Expected result: - Correct values for "memorytotal" and "cputotal" Actual result: - CloudStack return zero for "memorytotal" and "cputotal" for each VM with dynamic compute offerings -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CLOUDSTACK-10033) updateResourceCount wrong result with dynamic compute offerings
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alireza Eskandari updated CLOUDSTACK-10033: --- Affects Version/s: 4.9.0 > updateResourceCount wrong result with dynamic compute offerings > --- > > Key: CLOUDSTACK-10033 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10033 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server, Usage >Affects Versions: 4.9.0, 4.9.2.0 >Reporter: Alireza Eskandari > > Environment: > - vCenter 6.0u3 > - CloudStack 4.9.2.0 (Shapeblue) > Steps to reproduce: > - Create VM with dynamic compute offering > - Call "updateResourceCount" for related account > - Call "listAccounts" to view resource statistic for related account > Expected result: > - Correct values for "memorytotal" and "cputotal" > Actual result: > - CloudStack return zero for "memorytotal" and "cputotal" for each VM with > dynamic compute offerings -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CLOUDSTACK-10062) Worng SSL certificate for SSVM in server mode
Alireza Eskandari created CLOUDSTACK-10062: -- Summary: Worng SSL certificate for SSVM in server mode Key: CLOUDSTACK-10062 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10062 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.10.0.0, 4.9.0, 4.9.2.0 Reporter: Alireza Eskandari SSVM represents worng SSL certificate to clients when they want download iso/template. The SSL is a self signed certificate which is issued for "systemvm". I investigate about the problem and found the cause: Enabling SSL for SSVM triggers "/usr/local/cloud/systemvm/config_ssl.sh". "config_ssl.sh" edits some parameters in "/etc/apache2/sites-available/default-ssl". But "/etc/init.d/cloud-early-config" uses "/etc/apache2/vhost.template" to create "/etc/apache2/sites-enabled/vhost-.conf" and don't use "/etc/apache2/sites-available/default-ssl" -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CLOUDSTACK-10084) Primary Storage Allocated goes beyond 100% by resizing disk volumes
Alireza Eskandari created CLOUDSTACK-10084: -- Summary: Primary Storage Allocated goes beyond 100% by resizing disk volumes Key: CLOUDSTACK-10084 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10084 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.9.0, 4.9.2.0 Reporter: Alireza Eskandari Environment: - vCenter 5.5u3 - CloudStack 4.9.2.0 (Shapeblue) Steps to reproduce: - Primary storage is nearly full so CloudStack don't let me to create a new VM - I can resize existing root and data disk with out limitation Expected result: - CloudStack shows an error that the primary storage is full and can not increase the size of disks Actual result: - CloudStack resizes disk beyond 100% of primary storage capacity -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CLOUDSTACK-10084) "Primary Storage Allocated" goes beyond 100% by resizing disk volumes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alireza Eskandari updated CLOUDSTACK-10084: --- Summary: "Primary Storage Allocated" goes beyond 100% by resizing disk volumes (was: Primary Storage Allocated goes beyond 100% by resizing disk volumes) > "Primary Storage Allocated" goes beyond 100% by resizing disk volumes > - > > Key: CLOUDSTACK-10084 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10084 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.9.0, 4.9.2.0 >Reporter: Alireza Eskandari > > Environment: > - vCenter 5.5u3 > - CloudStack 4.9.2.0 (Shapeblue) > Steps to reproduce: > - Primary storage is nearly full so CloudStack don't let me to create a new > VM > - I can resize existing root and data disk with out limitation > Expected result: > - CloudStack shows an error that the primary storage is full and can not > increase the size of disks > Actual result: > - CloudStack resizes disk beyond 100% of primary storage capacity -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CLOUDSTACK-10084) "Primary Storage Allocated" goes beyond 100% by resizing disk volumes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alireza Eskandari updated CLOUDSTACK-10084: --- Description: Environment: - vCenter 5.5u3 - CloudStack 4.9.2.0 (Shapeblue) Steps to reproduce: - Primary storage is nearly full so CloudStack don't let me to create a new VM - I can resize existing root and data disk without limitation Expected result: - CloudStack shows an error that the primary storage is full and can not increase the size of disks Actual result: - CloudStack resizes disk beyond 100% of primary storage capacity was: Environment: - vCenter 5.5u3 - CloudStack 4.9.2.0 (Shapeblue) Steps to reproduce: - Primary storage is nearly full so CloudStack don't let me to create a new VM - I can resize existing root and data disk with out limitation Expected result: - CloudStack shows an error that the primary storage is full and can not increase the size of disks Actual result: - CloudStack resizes disk beyond 100% of primary storage capacity > "Primary Storage Allocated" goes beyond 100% by resizing disk volumes > - > > Key: CLOUDSTACK-10084 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10084 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.9.0, 4.9.2.0 >Reporter: Alireza Eskandari > > Environment: > - vCenter 5.5u3 > - CloudStack 4.9.2.0 (Shapeblue) > Steps to reproduce: > - Primary storage is nearly full so CloudStack don't let me to create a new > VM > - I can resize existing root and data disk without limitation > Expected result: > - CloudStack shows an error that the primary storage is full and can not > increase the size of disks > Actual result: > - CloudStack resizes disk beyond 100% of primary storage capacity -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CLOUDSTACK-10186) No database selected for the transaction
Alireza Eskandari created CLOUDSTACK-10186: -- Summary: No database selected for the transaction Key: CLOUDSTACK-10186 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10186 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.9.3.0 Reporter: Alireza Eskandari Environment: - A cluster of CS 4.9.3 with 2 nodes on CentOS 6 - A cluster of MariaDB with 3 nodes in multi-master mode with Galera I want to use MySQL-HA solution of CloudStack. When I stop the first DB server, I get the below exception frequently instead of switching to other DB server. 2017-11-21 10:37:35,641 WARN [c.c.c.d.ManagementServerHostDaoImpl] (Cluster-Heartbeat-1:ctx-a32c78be) (logid:c9227f75) Unexpected exception, com.cloud.utils.exception.CloudRuntimeException: No database selected for the transaction at com.cloud.utils.db.TransactionLegacy.getConnection(TransactionLegacy.java:580) at com.cloud.utils.db.TransactionLegacy.prepareStatement(TransactionLegacy.java:467) at com.cloud.utils.db.TransactionLegacy.prepareAutoCloseStatement(TransactionLegacy.java:460) at com.cloud.cluster.dao.ManagementServerHostDaoImpl.update(ManagementServerHostDaoImpl.java:134) at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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 com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy201.update(Unknown Source) at com.cloud.cluster.ClusterManagerImpl$4.runInContext(ClusterManagerImpl.java:554) 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:473) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:622) at java.lang.Thread.run(Thread.java:748) 2017-11-21 10:37:35,641 ERROR [c.c.c.ClusterManagerImpl] (Cluster-Heartbeat-1:ctx-a32c78be) (logid:c9227f75) Unexpected exception in cluster heartbeat java.lang.RuntimeException: No database selected for the transaction at com.cloud.cluster.dao.ManagementServerHostDaoImpl.update(ManagementServerHostDaoImpl.java:148) at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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 com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) at org.springfr
[jira] [Updated] (CLOUDSTACK-10186) No database selected for the transaction
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alireza Eskandari updated CLOUDSTACK-10186: --- Description: Environment: - A cluster of CS 4.9.3 with 2 nodes on CentOS 6 - A cluster of MariaDB with 3 nodes in multi-master mode with Galera I want to use MySQL-HA solution of CloudStack. When I stop the first DB server, I get the below exception frequently instead of switching to other DB server. 2017-11-21 10:37:35,641 WARN [c.c.c.d.ManagementServerHostDaoImpl] (Cluster-Heartbeat-1:ctx-a32c78be) (logid:c9227f75) Unexpected exception, com.cloud.utils.exception.CloudRuntimeException: No database selected for the transaction at com.cloud.utils.db.TransactionLegacy.getConnection(TransactionLegacy.java:580) at com.cloud.utils.db.TransactionLegacy.prepareStatement(TransactionLegacy.java:467) at com.cloud.utils.db.TransactionLegacy.prepareAutoCloseStatement(TransactionLegacy.java:460) at com.cloud.cluster.dao.ManagementServerHostDaoImpl.update(ManagementServerHostDaoImpl.java:134) at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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 com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy201.update(Unknown Source) at com.cloud.cluster.ClusterManagerImpl$4.runInContext(ClusterManagerImpl.java:554) 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:473) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:622) at java.lang.Thread.run(Thread.java:748) 2017-11-21 10:37:35,641 ERROR [c.c.c.ClusterManagerImpl] (Cluster-Heartbeat-1:ctx-a32c78be) (logid:c9227f75) Unexpected exception in cluster heartbeat java.lang.RuntimeException: No database selected for the transaction at com.cloud.cluster.dao.ManagementServerHostDaoImpl.update(ManagementServerHostDaoImpl.java:148) at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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 com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocat
[jira] [Updated] (CLOUDSTACK-10186) No database selected for the transaction
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alireza Eskandari updated CLOUDSTACK-10186: --- Description: Environment: - A cluster of CS 4.9.3 with 2 nodes on CentOS 6 - A cluster of MariaDB with 3 nodes in multi-master mode with Galera I want to use MySQL-HA solution of CloudStack. When I stop the first DB server, I get the below exception frequently instead of switching to other DB server. 2017-11-21 10:37:35,641 WARN [c.c.c.d.ManagementServerHostDaoImpl] (Cluster-Heartbeat-1:ctx-a32c78be) (logid:c9227f75) Unexpected exception, com.cloud.utils.exception.CloudRuntimeException: No database selected for the transaction at com.cloud.utils.db.TransactionLegacy.getConnection(TransactionLegacy.java:580) at com.cloud.utils.db.TransactionLegacy.prepareStatement(TransactionLegacy.java:467) at com.cloud.utils.db.TransactionLegacy.prepareAutoCloseStatement(TransactionLegacy.java:460) at com.cloud.cluster.dao.ManagementServerHostDaoImpl.update(ManagementServerHostDaoImpl.java:134) at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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 com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy201.update(Unknown Source) at com.cloud.cluster.ClusterManagerImpl$4.runInContext(ClusterManagerImpl.java:554) 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:473) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:622) at java.lang.Thread.run(Thread.java:748) 2017-11-21 10:37:35,641 ERROR [c.c.c.ClusterManagerImpl] (Cluster-Heartbeat-1:ctx-a32c78be) (logid:c9227f75) Unexpected exception in cluster heartbeat java.lang.RuntimeException: No database selected for the transaction at com.cloud.cluster.dao.ManagementServerHostDaoImpl.update(ManagementServerHostDaoImpl.java:148) at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) 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 com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocat
[jira] [Created] (CLOUDSTACK-10192) Using SSL for database and JMX simultaneously
Alireza Eskandari created CLOUDSTACK-10192: -- Summary: Using SSL for database and JMX simultaneously Key: CLOUDSTACK-10192 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10192 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.9.3.0 Reporter: Alireza Eskandari Environment: CloudStack 4.9.3.0 MariaDB Cluster on Galera Java 1.7.0_151 CentOS 6.9 I'm using MariaDB over SSL so CloudStack communicate to its database securely. I can use JMX remote without SSL but when I try to enable SSL on JMX traffic, I can't start CloudStack. Here is JAVA_OPTS in tomcat6.conf: JAVA_OPTS="-Djava.awt.headless=true -Xmx2g -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/cloudstack/management/ -XX:PermSize=512M -XX:MaxPermSize=800m -Djava.security.properties=/etc/cloudstack/management/java.security.ciphers -Dcom.sun.management.jmxremote -Djava.rmi.server.hostname=CLST01.cloud.local -Dcom.sun.management.jmxremote.port=45219 -Dcom.sun.management.jmxremote.authenticate=true -Dcom.sun.management.jmxremote.password.file=/etc/cloudstack/management/jmxremote.password -Dcom.sun.management.jmxremote.access.file=/etc/cloudstack/management/jmxremote.access -Dcom.sun.management.jmxremote.ssl=true -Djavax.net.ssl.keyStore=/etc/ssl/certs/jmx/clst01.keystore -Djavax.net.ssl.keyStorePassword=xxx" This is content of catalina.out: INFO [c.c.u.d.T.Transaction] (main:null) (logid:) Is Data Base High Availiability enabled? Ans : true INFO [c.c.u.d.T.Transaction] (main:null) (logid:) The slaves configured for Cloud Data base is/are : csdb02.cloud.local ERROR [c.c.u.d.Merovingian2] (main:null) (logid:) Unable to get a new db connection com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Cannot connect to MySQL server on csdb1.cloud.local:3306. Make sure that there is a MySQL server running on the machine/port you are trying to connect to and that the machine this software is running on is able to connect to this host/port (i.e. not firewalled). Also make sure that the server has not been started with the --skip-networking flag. at sun.reflect.GeneratedConstructorAccessor39.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) at com.mysql.jdbc.Util.getInstance(Util.java:386) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1013) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:987) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:982) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:927) at com.mysql.jdbc.ConnectionImpl.(ConnectionImpl.java:825) at com.mysql.jdbc.JDBC4Connection.(JDBC4Connection.java:49) at sun.reflect.GeneratedConstructorAccessor33.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:381) at com.mysql.jdbc.LoadBalancingConnectionProxy.createConnectionForHost(LoadBalancingConnectionProxy.java:376) at com.cloud.utils.db.StaticStrategy.pickConnection(StaticStrategy.java:77) at com.mysql.jdbc.LoadBalancingConnectionProxy.pickNewConnection(LoadBalancingConnectionProxy.java:593) at com.mysql.jdbc.FailoverConnectionProxy.failOver(FailoverConnectionProxy.java:186) at com.mysql.jdbc.FailoverConnectionProxy.pickNewConnection(FailoverConnectionProxy.java:171) at com.mysql.jdbc.LoadBalancingConnectionProxy.(LoadBalancingConnectionProxy.java:329) at com.mysql.jdbc.FailoverConnectionProxy.(FailoverConnectionProxy.java:66) at com.mysql.jdbc.NonRegisteringDriver.connectFailover(NonRegisteringDriver.java:382) at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:301) at java.sql.DriverManager.getConnection(DriverManager.java:571) at java.sql.DriverManager.getConnection(DriverManager.java:215) at org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:75) at org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:582) at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1188) at org.apache.commons.dbcp.PoolingDataSource.getConnection
[jira] [Updated] (CLOUDSTACK-10192) Using SSL for database and JMX simultaneously
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alireza Eskandari updated CLOUDSTACK-10192: --- Description: Environment: CloudStack 4.9.3.0 MariaDB Cluster on Galera Java 1.7.0_151 CentOS 6.9 I'm using MariaDB over SSL so CloudStack communicate to its database securely. I can use JMX remote without SSL but when I try to enable SSL on JMX traffic, I can't start CloudStack. When I disable SSL connection for database traffic, I can use JMX over SSL without problem. Here is JAVA_OPTS in tomcat6.conf: JAVA_OPTS="-Djava.awt.headless=true -Xmx2g -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log/cloudstack/management/ -XX:PermSize=512M -XX:MaxPermSize=800m -Djava.security.properties=/etc/cloudstack/management/java.security.ciphers -Dcom.sun.management.jmxremote -Djava.rmi.server.hostname=CLST01.cloud.local -Dcom.sun.management.jmxremote.port=45219 -Dcom.sun.management.jmxremote.authenticate=true -Dcom.sun.management.jmxremote.password.file=/etc/cloudstack/management/jmxremote.password -Dcom.sun.management.jmxremote.access.file=/etc/cloudstack/management/jmxremote.access -Dcom.sun.management.jmxremote.ssl=true -Djavax.net.ssl.keyStore=/etc/ssl/certs/jmx/clst01.keystore -Djavax.net.ssl.keyStorePassword=xxx" This is content of catalina.out: INFO [c.c.u.d.T.Transaction] (main:null) (logid:) Is Data Base High Availiability enabled? Ans : true INFO [c.c.u.d.T.Transaction] (main:null) (logid:) The slaves configured for Cloud Data base is/are : csdb02.cloud.local ERROR [c.c.u.d.Merovingian2] (main:null) (logid:) Unable to get a new db connection com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Cannot connect to MySQL server on csdb1.cloud.local:3306. Make sure that there is a MySQL server running on the machine/port you are trying to connect to and that the machine this software is running on is able to connect to this host/port (i.e. not firewalled). Also make sure that the server has not been started with the --skip-networking flag. at sun.reflect.GeneratedConstructorAccessor39.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) at com.mysql.jdbc.Util.getInstance(Util.java:386) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1013) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:987) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:982) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:927) at com.mysql.jdbc.ConnectionImpl.(ConnectionImpl.java:825) at com.mysql.jdbc.JDBC4Connection.(JDBC4Connection.java:49) at sun.reflect.GeneratedConstructorAccessor33.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:381) at com.mysql.jdbc.LoadBalancingConnectionProxy.createConnectionForHost(LoadBalancingConnectionProxy.java:376) at com.cloud.utils.db.StaticStrategy.pickConnection(StaticStrategy.java:77) at com.mysql.jdbc.LoadBalancingConnectionProxy.pickNewConnection(LoadBalancingConnectionProxy.java:593) at com.mysql.jdbc.FailoverConnectionProxy.failOver(FailoverConnectionProxy.java:186) at com.mysql.jdbc.FailoverConnectionProxy.pickNewConnection(FailoverConnectionProxy.java:171) at com.mysql.jdbc.LoadBalancingConnectionProxy.(LoadBalancingConnectionProxy.java:329) at com.mysql.jdbc.FailoverConnectionProxy.(FailoverConnectionProxy.java:66) at com.mysql.jdbc.NonRegisteringDriver.connectFailover(NonRegisteringDriver.java:382) at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:301) at java.sql.DriverManager.getConnection(DriverManager.java:571) at java.sql.DriverManager.getConnection(DriverManager.java:215) at org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:75) at org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:582) at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:1188) at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:106) at com.cloud.utils.db.TransactionLegacy.getStandaloneConnectionWithException(TransactionLegacy.java:212) at com.cloud.utils.db.Merovingian2.(Meroving
[jira] [Created] (CLOUDSTACK-10401) Jobs stuck in pending state
Alireza Eskandari created CLOUDSTACK-10401: -- Summary: Jobs stuck in pending state Key: CLOUDSTACK-10401 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10401 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, VMware Affects Versions: 4.9.3.0 Reporter: Alireza Eskandari Attachments: logs.txt Environment: CS 4.9.3.1 on CentOS 6 with vCenter 5.5 When I try to create new VM or even start or stop existing VMs, the related jobs stuck in pending state and nothing happened in vCenter. This bug make my cloud totaly unusable. Logs are attached [^logs.txt] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10401) Jobs stuck in pending state
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alireza Eskandari updated CLOUDSTACK-10401: --- Description: Environment: CS 4.9.3.1 on CentOS 6 with vCenter 5.5 When I try to create new VM or even start or stop existing VMs, the related jobs stuck in pending state and nothing happens in vCenter. This bug make my cloud totaly unusable. Logs are attached [^logs.txt] ^As you can see in log file I try to create a VM and then I get "job-57349"^ ^In line 179 "DeploymentPlanningManagerImpl" return its result but after that nothing happens!^ was: Environment: CS 4.9.3.1 on CentOS 6 with vCenter 5.5 When I try to create new VM or even start or stop existing VMs, the related jobs stuck in pending state and nothing happened in vCenter. This bug make my cloud totaly unusable. Logs are attached [^logs.txt] > Jobs stuck in pending state > --- > > Key: CLOUDSTACK-10401 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10401 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, VMware >Affects Versions: 4.9.3.0 >Reporter: Alireza Eskandari >Priority: Blocker > Attachments: logs.txt > > > Environment: > CS 4.9.3.1 on CentOS 6 with vCenter 5.5 > When I try to create new VM or even start or stop existing VMs, the related > jobs stuck in pending state and nothing happens in vCenter. > This bug make my cloud totaly unusable. > Logs are attached > [^logs.txt] > ^As you can see in log file I try to create a VM and then I get "job-57349"^ > ^In line 179 "DeploymentPlanningManagerImpl" return its result but after that > nothing happens!^ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10401) Jobs stuck in pending state
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alireza Eskandari updated CLOUDSTACK-10401: --- Affects Version/s: 4.11 > Jobs stuck in pending state > --- > > Key: CLOUDSTACK-10401 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10401 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, VMware >Affects Versions: 4.9.3.0, 4.11 >Reporter: Alireza Eskandari >Priority: Blocker > Attachments: logs.txt > > > Environment: > CS 4.9.3.1 on CentOS 6 with vCenter 5.5 > When I try to create new VM or even start or stop existing VMs, the related > jobs stuck in pending state and nothing happens in vCenter. > This bug make my cloud totaly unusable. > Logs are attached > [^logs.txt] > ^As you can see in log file I try to create a VM and then I get "job-57349"^ > ^In line 179 "DeploymentPlanningManagerImpl" return its result but after that > nothing happens!^ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10401) Jobs stuck in pending state
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16750117#comment-16750117 ] Alireza Eskandari commented on CLOUDSTACK-10401: Update: I have upgraded my CS from 4.9.3.1 to 4.11.2.0 but the problem exists. After investigating database I guess these 3 tables could lock my CloudStack. * op_ha_work * op_lock * vm_work_job So I delete all of those tables rows and problem fixed. Here is content of those tables: MySQL [cloud]> select * from op_ha_work; ++-+---+-+-++-+-+---+-+---+-+-+ | id | instance_id | type | vm_type | state | mgmt_server_id | host_id | created | tried | taken | step | time_to_try | updated | ++-+---+-+-++-+-+---+-+---+-+-+ | 16 | 546 | Migration | User | Running | 345051240548 | 91 | 2019-01-20 12:10:07 | 2 | 2019-01-23 10:21:21 | Migrating | 1511890258 | 12 | | 37 | 631 | Migration | User | Running | 345051240548 | 91 | 2019-01-20 12:10:07 | 1 | 2019-01-23 09:38:26 | Done | 1511890258 | 4 | | 40 | 633 | Migration | User | Running | 345051240548 | 91 | 2019-01-20 12:10:07 | 1 | 2019-01-23 10:21:21 | Migrating | 1511890258 | 3 | | 43 | 671 | Migration | User | Running | 345051240548 | 91 | 2019-01-20 12:10:07 | 2 | 2019-01-23 10:24:23 | Migrating | 1511952155 | 4 | | 46 | 691 | Migration | User | Running | NULL | 91 | 2019-01-20 12:10:07 | 2 | NULL | Migrating | 1511952155 | 7 | | 48 | 631 | Migration | User | Running | 345051240548 | 94 | 2019-01-23 09:38:26 | 0 | 2019-01-23 10:21:21 | Migrating | 1511949518 | 10 | | 51 | 546 | Migration | User | Running | 345051240548 | 94 | 2019-01-23 09:38:26 | 0 | 2019-01-23 10:21:23 | Migrating | 1511949518 | 16 | ++-+---+-+-++-+-+---+-+---+-+-+ 7 rows in set (0.00 sec) MySQL [cloud]> select * from op_lock; ++--+-++-+-+ | key | mac | ip | thread | acquired_on | waiters | ++--+-++-+-+ | vm_instance546 | 345051240548 | HA-Worker-4 | 1198190978 | 2019-01-23 10:21:21 | 0 | | vm_instance631 | 345051240548 | HA-Worker-1 | 2092627389 | 2019-01-23 10:21:21 | 1 | | vm_instance633 | 345051240548 | HA-Worker-0 | 770823 | 2019-01-23 10:21:21 | 0 | ++--+-++-+-+ 3 rows in set (0.00 sec) MySQL [cloud]> select * from vm_work_job; +---+--+--++ | id | step | vm_type | vm_instance_id | +---+--+--++ | 57262 | Prepare | Instance | 691 | | 57268 | Starting | Instance | 748 | | 57396 | Filed | Instance | 691 | | 57399 | Filed | Instance | 546 | | 57402 | Filed | Instance | 631 | | 57405 | Filed | Instance | 671 | | 57408 | Filed | Instance | 633 | +---+--+--++ 7 rows in set (0.01 sec) > Jobs stuck in pending state > --- > > Key: CLOUDSTACK-10401 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10401 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, VMware >Affects Versions: 4.9.3.0, 4.11 >Reporter: Alireza Eskandari >Priority: Blocker > Attachments: logs.txt > > > Environment: > CS 4.9.3.1 on CentOS 6 with vCenter 5.5 > When I try to create new VM or even start or stop existing VMs, the related > jobs stuck in pending state and nothing happens in vCenter. > This bug make my cloud totaly unusable. > Logs are attached > [^logs.txt] > ^As you can see in log file I try to create a VM and then I get "job-57349"^ > ^In line 179 "DeploymentPlanningManagerImpl" return its result but after that > nothing happens!^ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CLOUDSTACK-10401) Jobs stuck in pending state
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16750117#comment-16750117 ] Alireza Eskandari edited comment on CLOUDSTACK-10401 at 1/23/19 3:21 PM: - Update: I have upgraded my CS from 4.9.3.1 to 4.11.2.0 but the problem exists. After investigating database I guess these 3 tables could lock my CloudStack. * op_ha_work * op_lock * vm_work_job So I delete all of those tables rows and problem fixed. Here is content of those tables: MySQL [cloud]> select * from op_ha_work; |id|instance_id|type|vm_type|state|mgmt_server_id|host_id|created|tried|taken|step|time_to_try|updated| |16|546|Migration|User|Running|345051240548|91|2019-01-20 12:10:07|2|2019-01-23 10:21:21|Migrating|1511890258|12| |37|631|Migration|User|Running|345051240548|91|2019-01-20 12:10:07|1|2019-01-23 09:38:26|Done|1511890258|4| |40|633|Migration|User|Running|345051240548|91|2019-01-20 12:10:07|1|2019-01-23 10:21:21|Migrating|1511890258|3| |43|671|Migration|User|Running|345051240548|91|2019-01-20 12:10:07|2|2019-01-23 10:24:23|Migrating|1511952155|4| |46|691|Migration|User|Running|NULL|91|2019-01-20 12:10:07|2|NULL|Migrating|1511952155|7| |48|631|Migration|User|Running|345051240548|94|2019-01-23 09:38:26|0|2019-01-23 10:21:21|Migrating|1511949518|10| |51|546|Migration|User|Running|345051240548|94|2019-01-23 09:38:26|0|2019-01-23 10:21:23|Migrating|1511949518|16| MySQL [cloud]> select * from op_lock; |key|mac|ip|thread|acquired_on|waiters| |vm_instance546|345051240548|HA-Worker-4|1198190978|2019-01-23 10:21:21|0| |vm_instance631|345051240548|HA-Worker-1|2092627389|2019-01-23 10:21:21|1| |vm_instance633|345051240548|HA-Worker-0|770823|2019-01-23 10:21:21|0| MySQL [cloud]> select * from vm_work_job; |id|step|vm_type|vm_instance_id| |57262|Prepare|Instance|691| |57268|Starting|Instance|748| |57396|Filed|Instance|691| |57399|Filed|Instance|546| |57402|Filed|Instance|631| |57405|Filed|Instance|671| |57408|Filed|Instance|633| was (Author: alireza): Update: I have upgraded my CS from 4.9.3.1 to 4.11.2.0 but the problem exists. After investigating database I guess these 3 tables could lock my CloudStack. * op_ha_work * op_lock * vm_work_job So I delete all of those tables rows and problem fixed. Here is content of those tables: MySQL [cloud]> select * from op_ha_work; ++-+---+-+-++-+-+---+-+---+-+-+ | id | instance_id | type | vm_type | state | mgmt_server_id | host_id | created | tried | taken | step | time_to_try | updated | ++-+---+-+-++-+-+---+-+---+-+-+ | 16 | 546 | Migration | User | Running | 345051240548 | 91 | 2019-01-20 12:10:07 | 2 | 2019-01-23 10:21:21 | Migrating | 1511890258 | 12 | | 37 | 631 | Migration | User | Running | 345051240548 | 91 | 2019-01-20 12:10:07 | 1 | 2019-01-23 09:38:26 | Done | 1511890258 | 4 | | 40 | 633 | Migration | User | Running | 345051240548 | 91 | 2019-01-20 12:10:07 | 1 | 2019-01-23 10:21:21 | Migrating | 1511890258 | 3 | | 43 | 671 | Migration | User | Running | 345051240548 | 91 | 2019-01-20 12:10:07 | 2 | 2019-01-23 10:24:23 | Migrating | 1511952155 | 4 | | 46 | 691 | Migration | User | Running | NULL | 91 | 2019-01-20 12:10:07 | 2 | NULL | Migrating | 1511952155 | 7 | | 48 | 631 | Migration | User | Running | 345051240548 | 94 | 2019-01-23 09:38:26 | 0 | 2019-01-23 10:21:21 | Migrating | 1511949518 | 10 | | 51 | 546 | Migration | User | Running | 345051240548 | 94 | 2019-01-23 09:38:26 | 0 | 2019-01-23 10:21:23 | Migrating | 1511949518 | 16 | ++-+---+-+-++-+-+---+-+---+-+-+ 7 rows in set (0.00 sec) MySQL [cloud]> select * from op_lock; ++--+-++-+-+ | key | mac | ip | thread | acquired_on | waiters | ++--+-++-+-+ | vm_instance546 | 345051240548 | HA-Worker-4 | 1198190978 | 2019-01-23 10:21:21 | 0 | | vm_instance631 | 345051240548 | HA-Worker-1 | 2092627389 | 2019-01-23 10:21:21 | 1 | | vm_instance633 | 345051240548 | HA-Worker-0 | 770823 | 2019-01-23 10:21:21 | 0 | ++--+-++-+-+ 3 rows in set (0.00 sec) MySQL [cloud]> select * from vm_work_job; +---+--+--++ | id | step | vm_type | vm_instance_id | +---+--+--++ | 57262 | Prepare | Instance | 691 | | 57268 | Starting | Instance | 748
[jira] [Updated] (CLOUDSTACK-7149) Issues with deployment of Cloudstack with dvSwitch on vmware vSphere 5.5
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alireza Eskandari updated CLOUDSTACK-7149: -- Attachment: (was: logs.txt) > Issues with deployment of Cloudstack with dvSwitch on vmware vSphere 5.5 > > > Key: CLOUDSTACK-7149 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7149 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Install and Setup, Network > Controller, VMware >Affects Versions: 4.3.0 > Environment: vCenter 5.5 > 2 x ESXi 5.5 as hosts >Reporter: Alireza Eskandari >Priority: Critical > Labels: 4.3.0, dvSwitch, vmware > Attachments: logs.txt > > Original Estimate: 336h > Remaining Estimate: 336h > > I can't deploy Zone with vmware hypervisor on dvSwitch. After I set > configurations, Cloudstack starts to create Zone, Pod, cluster and etc. and > everything looks normal but CS could not set any configuration on dvSwitch. > CS begins to create system VMs but after cloning of system VMs completed, CS > delete them because of unsuccessful dvSwitch configuration and recreate a new > one. > But when I try to deploy on Standard vSwitch, everything works well without > problem. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7149) Issues with deployment of Cloudstack with dvSwitch on vmware vSphere 5.5
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alireza Eskandari updated CLOUDSTACK-7149:
--
Description:
I can't deploy Zone with vmware hypervisor on dvSwitch. After I set
configurations, Cloudstack starts to create Zone, Pod, cluster and etc. and
everything looks normal but CS could not set any configuration on dvSwitch.
CS begins to create system VMs but after cloning of system VMs completed, CS
delete them because of unsuccessful dvSwitch configuration and recreate a new
one.
But when I try to deploy on Standard vSwitch, everything works well without
problem.
was:
I can't deploy Zone with vmware hypervisor on dvSwitch. After I set
configurations, Cloudstack starts to create Zone, Pod, cluster and etc. and
everything looks normal but CS could not set any configuration on dvSwitch.
CS begins to create system VMs but after cloning of system VMs completed, CS
delete them because of unsuccessful dvSwitch configuration and recreate a new
one.
But when I try to deploy on Standard vSwitch, everything works well without
problem.
2014-07-08 14:44:39,764 DEBUG [c.c.h.v.r.VmwareResource]
(DirectAgent-411:ctx-86a12e4e 172.16.71.54) Prepare volume at new device
{"capacityInKB":0,"key":-2,"backing":{"diskMode":"persistent","fileName":"[SharedStorageCS]
s-54-VM/ROOT-54-01.vmdk","datastore":{"value":"datastore-14","type":"Datastore"}},"connectable":{"startConnected":true,"allowGuestControl":false,"connected":true},"controllerKey":200,"unitNumber":1}
2014-07-08 14:44:39,764 DEBUG [c.c.h.v.r.VmwareResource]
(DirectAgent-411:ctx-86a12e4e 172.16.71.54) VM s-54-VM will be started with NIC
device type: E1000
2014-07-08 14:44:39,764 INFO [c.c.h.v.r.VmwareResource]
(DirectAgent-411:ctx-86a12e4e 172.16.71.54) Prepare NIC device based on NicTO:
{"deviceId":0,"networkRateMbps":-1,"defaultNic":false,"uuid":"53f70468-065a-484b-b6b5-9148d4ea9b52","mac":"02:00:16:fa:00:36","broadcastType":"LinkLocal","type":"Control","isSecurityGroupEnabled":false,"name":"vSwitch0,,vmwaresvs"}
2014-07-08 14:44:39,773 INFO [c.c.h.v.r.VmwareResource]
(DirectAgent-411:ctx-86a12e4e 172.16.71.54) Prepare network on vmwaresvs null
with name prefix: cloud.private
2014-07-08 14:44:39,773 WARN [c.c.h.v.r.VmwareResource]
(DirectAgent-411:ctx-86a12e4e 172.16.71.54) Unrecognized broadcast type in
VmwareResource, type: LinkLocal. Use vlan info from labeling: untagged
2014-07-08 14:44:39,773 INFO [c.c.h.v.m.HypervisorHostHelper]
(DirectAgent-411:ctx-86a12e4e 172.16.71.54) Detected vswitch name as undefined.
Defaulting to vSwitch0
2014-07-08 14:44:39,916 INFO [c.c.h.v.m.HypervisorHostHelper]
(DirectAgent-411:ctx-86a12e4e 172.16.71.54) Network
cloud.private.untagged.0.1-vSwitch0 is ready on vSwitch vSwitch0
2014-07-08 14:44:39,916 INFO [c.c.h.v.r.VmwareResource]
(DirectAgent-411:ctx-86a12e4e 172.16.71.54) Preparing NIC device on network
cloud.private.untagged.0.1-vSwitch0
2014-07-08 14:44:39,916 DEBUG [c.c.h.v.r.VmwareResource]
(DirectAgent-411:ctx-86a12e4e 172.16.71.54) Prepare NIC at new device
{"operation":"ADD","device":{"addressType":"Manual","macAddress":"02:00:16:fa:00:36","key":-3,"backing":{"network":{"value":"network-23","type":"Network"},"deviceName":"cloud.private.untagged.0.1-vSwitch0"},"connectable":{"startConnected":true,"allowGuestControl":true,"connected":true},"unitNumber":0}}
2014-07-08 14:44:39,917 INFO [c.c.h.v.r.VmwareResource]
(DirectAgent-411:ctx-86a12e4e 172.16.71.54) Prepare NIC device based on NicTO:
{"deviceId":1,"networkRateMbps":-1,"defaultNic":false,"uuid":"eaa2b684-0ec0-47c2-be20-f138d0790856","ip":"172.16.71.62","netmask":"255.255.255.0","gateway":"172.16.71.1","mac":"06:fc:6e:00:00:02","broadcastType":"Native","type":"Management","isSecurityGroupEnabled":false,"name":"vSwitch0,,vmwaresvs"}
2014-07-08 14:44:39,925 INFO [c.c.h.v.r.VmwareResource]
(DirectAgent-411:ctx-86a12e4e 172.16.71.54) Prepare network on vmwaresvs null
with name prefix: cloud.private
2014-07-08 14:44:39,926 INFO [c.c.h.v.m.HypervisorHostHelper]
(DirectAgent-411:ctx-86a12e4e 172.16.71.54) Detected vswitch name as undefined.
Defaulting to vSwitch0
2014-07-08 14:44:40,063 INFO [c.c.h.v.m.HypervisorHostHelper]
(DirectAgent-411:ctx-86a12e4e 172.16.71.54) Network
cloud.private.untagged.0.1-vSwitch0 is ready on vSwitch vSwitch0
2014-07-08 14:44:40,063 INFO [c.c.h.v.r.VmwareResource]
(DirectAgent-411:ctx-86a12e4e 172.16.71.54) Preparing NIC device on network
cloud.private.untagged.0.1-vSwitch0
2014-07-08 14:44:40,064 DEBUG [c.c.h.v.r.VmwareResource]
(DirectAgent-411:ctx-86a12e4e 172.16.71.54) Prepare NIC at new device
{"operation":"ADD","device":{"addressType":"Manual","macAddress":"06:fc:6e:00:00:02","key":-4,"backing":{"network":{"value":"network-23","type":"Network"},"deviceName":"cloud.private.untagged.0.1-vSwitch0"},"connectable":{"startConnected":true,"allowGuestControl":t
[jira] [Updated] (CLOUDSTACK-7149) Issues with deployment of Cloudstack with dvSwitch on vmware vSphere 5.5
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alireza Eskandari updated CLOUDSTACK-7149: -- Attachment: (was: logs.txt) > Issues with deployment of Cloudstack with dvSwitch on vmware vSphere 5.5 > > > Key: CLOUDSTACK-7149 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7149 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Install and Setup, Network > Controller, VMware >Affects Versions: 4.3.0 > Environment: vCenter 5.5 > 2 x ESXi 5.5 as hosts >Reporter: Alireza Eskandari >Priority: Critical > Labels: 4.3.0, dvSwitch, vmware > Attachments: logs.txt > > Original Estimate: 336h > Remaining Estimate: 336h > > I can't deploy Zone with vmware hypervisor on dvSwitch. After I set > configurations, Cloudstack starts to create Zone, Pod, cluster and etc. and > everything looks normal but CS could not set any configuration on dvSwitch. > CS begins to create system VMs but after cloning of system VMs completed, CS > delete them because of unsuccessful dvSwitch configuration and recreate a new > one. > But when I try to deploy on Standard vSwitch, everything works well without > problem. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-2574) Release note pdf link
Alireza Eskandari created CLOUDSTACK-2574: - Summary: Release note pdf link Key: CLOUDSTACK-2574 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2574 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Doc Affects Versions: 4.0.2 Reporter: Alireza Eskandari Priority: Trivial PDF link for release note of 4.0.2 is not correct. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-7591) Dynamic scaling doesn't work in CloudStack 4.4 with vmware
Alireza Eskandari created CLOUDSTACK-7591: - Summary: Dynamic scaling doesn't work in CloudStack 4.4 with vmware Key: CLOUDSTACK-7591 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7591 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, VMware Affects Versions: 4.4.0 Reporter: Alireza Eskandari Priority: Critical In cloudstack 4.4 with vSphere 5.5, I create a CentOS 6 instance with dynamic scalability enabled with this resources: RAM: 512MB , CPU:1 core - 500MHz After I scale this instance to below resources I got "Failed to scale the VM": RAM: 1024MB , CPU:1 core - 1000MHz I don't face with above issue in cloudstack 4.3 ERROR [c.c.h.v.r.VmwareResource] (DirectAgent-116:ctx-abd65263 10.10.171.156) Unexpected exception: com.cloud.utils.exception.CloudRuntimeException: Memory of VM i-2-14-VM cannot be scaled to 1024MB. Requested memory limit is beyond the hotadd memory limit for this VM at the moment is 512MB. at com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:1261) at com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:471) 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.run(FutureTask.java:262) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7591) Dynamic scaling doesn't work in CloudStack 4.4 with vmware
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alireza Eskandari updated CLOUDSTACK-7591: -- Attachment: log.txt Detailed logs > Dynamic scaling doesn't work in CloudStack 4.4 with vmware > -- > > Key: CLOUDSTACK-7591 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7591 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, VMware >Affects Versions: 4.4.0 >Reporter: Alireza Eskandari >Priority: Critical > Labels: 4.4, dynamic, scaling, vmware > Attachments: log.txt > > > In cloudstack 4.4 with vSphere 5.5, I create a CentOS 6 instance with dynamic > scalability enabled with this resources: > RAM: 512MB , CPU:1 core - 500MHz > After I scale this instance to below resources I got "Failed to scale the VM": > RAM: 1024MB , CPU:1 core - 1000MHz > I don't face with above issue in cloudstack 4.3 > ERROR [c.c.h.v.r.VmwareResource] (DirectAgent-116:ctx-abd65263 10.10.171.156) > Unexpected exception: > com.cloud.utils.exception.CloudRuntimeException: Memory of VM i-2-14-VM > cannot be scaled to 1024MB. Requested memory limit is beyond the hotadd > memory limit for this VM at the moment is 512MB. > at > com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:1261) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:471) > 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.run(FutureTask.java:262) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7592) Dynamically Scalablity state doesn't update after restoring the VM.
Alireza Eskandari created CLOUDSTACK-7592: - Summary: Dynamically Scalablity state doesn't update after restoring the VM. Key: CLOUDSTACK-7592 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7592 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 Reporter: Alireza Eskandari 1- Create a new instance from a template that is dynamically scalable. 2- Restore the created instance to a new template that is NOT dynamically scalable. (API: restoreVirtualMachine) 3- You see in instance details that "Dynamically Scalable = Yes" but it should be updated to "No" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7149) Issues with deployment of Cloudstack with dvSwitch on vmware vSphere 5.5
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alireza Eskandari updated CLOUDSTACK-7149: -- Fix Version/s: 4.3.2 > Issues with deployment of Cloudstack with dvSwitch on vmware vSphere 5.5 > > > Key: CLOUDSTACK-7149 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7149 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Install and Setup, Network > Controller, VMware >Affects Versions: 4.3.0 > Environment: vCenter 5.5 > 2 x ESXi 5.5 as hosts >Reporter: Alireza Eskandari >Priority: Critical > Labels: 4.3.0, dvSwitch, vmware > Fix For: 4.3.2 > > Attachments: logs.txt > > Original Estimate: 336h > Remaining Estimate: 336h > > I can't deploy Zone with vmware hypervisor on dvSwitch. After I set > configurations, Cloudstack starts to create Zone, Pod, cluster and etc. and > everything looks normal but CS could not set any configuration on dvSwitch. > CS begins to create system VMs but after cloning of system VMs completed, CS > delete them because of unsuccessful dvSwitch configuration and recreate a new > one. > But when I try to deploy on Standard vSwitch, everything works well without > problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7591) Dynamic scaling doesn't work in CloudStack 4.4 with vmware
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14712976#comment-14712976
]
Alireza Eskandari commented on CLOUDSTACK-7591:
---
I found the reason.
Problem originated from wrong data in "guest_os" table. For example (in CS
4.5.2) when you use "CentOS 6 (64-bit)" with id of 249 as your OS on VMWare,
you can't find related record in "guest_os_hypervisor" table for VMWare.
(guest_os_id column with value of 249 is only mapped to Xenserver but there is
no record for VMWare) so VMWare consider this vm as "otherGuest".
The above problem is the reason of 2 other problems:
1- You can't do dynamic scale on this vm because vmware sets maximum hotadd
memory limit equal to its actual amount of RAM. ("otherGuest" aren't
dynamically scalable)
2- The request for mounting "vmware-tools.iso" on this vm fails. ("otherGuest"
doesn't have vmware-tools).
Thanks
> Dynamic scaling doesn't work in CloudStack 4.4 with vmware
> --
>
> Key: CLOUDSTACK-7591
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7591
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, VMware
>Affects Versions: 4.4.0, 4.5.0
>Reporter: Alireza Eskandari
>Priority: Critical
> Labels: 4.4, dynamic, scaling, vmware
> Attachments: acs45.log, log.txt
>
>
> In cloudstack 4.4 with vSphere 5.5, I create a CentOS 6 instance with dynamic
> scalability enabled with this resources:
> RAM: 512MB , CPU:1 core - 500MHz
> After I scale this instance to below resources I got "Failed to scale the VM":
> RAM: 1024MB , CPU:1 core - 1000MHz
> I don't face with above issue in cloudstack 4.3
> ERROR [c.c.h.v.r.VmwareResource] (DirectAgent-116:ctx-abd65263 10.10.171.156)
> Unexpected exception:
> com.cloud.utils.exception.CloudRuntimeException: Memory of VM i-2-14-VM
> cannot be scaled to 1024MB. Requested memory limit is beyond the hotadd
> memory limit for this VM at the moment is 512MB.
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:1261)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:471)
> 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.run(FutureTask.java:262)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7591) Dynamic scaling doesn't work in CloudStack 4.4 with vmware
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alireza Eskandari updated CLOUDSTACK-7591: -- Affects Version/s: 4.4.1 4.4.2 4.4.3 4.5.1 4.4.4 4.5.2 > Dynamic scaling doesn't work in CloudStack 4.4 with vmware > -- > > Key: CLOUDSTACK-7591 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7591 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, VMware >Affects Versions: 4.4.0, 4.5.0, 4.4.1, 4.4.2, 4.4.3, 4.5.1, 4.4.4, 4.5.2 >Reporter: Alireza Eskandari >Priority: Critical > Labels: 4.4, dynamic, scaling, vmware > Attachments: acs45.log, log.txt > > > In cloudstack 4.4 with vSphere 5.5, I create a CentOS 6 instance with dynamic > scalability enabled with this resources: > RAM: 512MB , CPU:1 core - 500MHz > After I scale this instance to below resources I got "Failed to scale the VM": > RAM: 1024MB , CPU:1 core - 1000MHz > I don't face with above issue in cloudstack 4.3 > ERROR [c.c.h.v.r.VmwareResource] (DirectAgent-116:ctx-abd65263 10.10.171.156) > Unexpected exception: > com.cloud.utils.exception.CloudRuntimeException: Memory of VM i-2-14-VM > cannot be scaled to 1024MB. Requested memory limit is beyond the hotadd > memory limit for this VM at the moment is 512MB. > at > com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:1261) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:471) > 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.run(FutureTask.java:262) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7149) Issues with deployment of Cloudstack with dvSwitch on vmware vSphere 5.5
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alireza Eskandari resolved CLOUDSTACK-7149. --- Resolution: Fixed > Issues with deployment of Cloudstack with dvSwitch on vmware vSphere 5.5 > > > Key: CLOUDSTACK-7149 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7149 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Install and Setup, Network > Controller, VMware >Affects Versions: 4.3.0 > Environment: vCenter 5.5 > 2 x ESXi 5.5 as hosts >Reporter: Alireza Eskandari >Priority: Critical > Labels: 4.3.0, dvSwitch, vmware > Fix For: 4.3.2 > > Attachments: logs.txt > > Original Estimate: 336h > Remaining Estimate: 336h > > I can't deploy Zone with vmware hypervisor on dvSwitch. After I set > configurations, Cloudstack starts to create Zone, Pod, cluster and etc. and > everything looks normal but CS could not set any configuration on dvSwitch. > CS begins to create system VMs but after cloning of system VMs completed, CS > delete them because of unsuccessful dvSwitch configuration and recreate a new > one. > But when I try to deploy on Standard vSwitch, everything works well without > problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
