[jira] [Commented] (CLOUDSTACK-6036) CloudStack stops the machine for no reason
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911371#comment-13911371
]
Koushik Das commented on CLOUDSTACK-6036:
-
Please upload the MS logs for this issue.
> CloudStack stops the machine for no reason
> ---
>
> Key: CLOUDSTACK-6036
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6036
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.1
> Environment: ACS 4.2.1 after upgrade from 3.0.2
> XCP 1.1
>Reporter: Tomasz Zieba
>Assignee: Koushik Das
>Priority: Critical
> Fix For: 4.4.0
>
>
> After the upgrade from version 3.0.2 to 4.2.1 appeared very strange error
> associated with self-stopping machine after changing the offering.
> Steps to reproduce:
> 1. Running instance of the machine
> 2. Stop with the operating system
> 3. Change offering of machine
> 4. Start the machine
> 5. Waiting for 10 minutes
> 6. CloudStack stops the machine for no reason
> 7. Restart the machine
> In the logs you can find information:
> 2014-02-05 06:27:00,974 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-316:null) 11. The VM i-41-824-VM is in Running state
> 2014-02-05 06:27:00,974 DEBUG [agent.transport.Request]
> (DirectAgent-316:null) Seq 50-1756626952: Processing: { Ans: , MgmtId:
> 160544475005497, via: 50, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.ClusterSyncAnswer":{"_clusterId":2,"_newStates":{"i-41-824-VM":{"t":"f32a4fee-b64e-4868-9c52-2a27e32d4c0e","u":"Running","v":"viridian:true;acpi:true;apic:true;pae:true;nx:false;timeoffset:0;cores-per-socket:4"}},"_isExecuted":false,"result":true,"wait":0}}]
> }
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Sending { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Executing: { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,383 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 9. The VM i-41-824-VM is in Stopping state
> 2014-02-05 06:36:27,625 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 10. The VM i-41-824-VM is in Stopped state
> You will notice that the stop of the machine corresponds to the component
> HA-Worker.
> Such operation after the upgrade is complicating work of users.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6036) CloudStack stops the machine for no reason
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Farrington updated CLOUDSTACK-6036:
Attachment: management-server.log.2014-02-20.gz
the instance was i-8-137-VM
> CloudStack stops the machine for no reason
> ---
>
> Key: CLOUDSTACK-6036
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6036
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.1
> Environment: ACS 4.2.1 after upgrade from 3.0.2
> XCP 1.1
>Reporter: Tomasz Zieba
>Assignee: Koushik Das
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: management-server.log.2014-02-20.gz
>
>
> After the upgrade from version 3.0.2 to 4.2.1 appeared very strange error
> associated with self-stopping machine after changing the offering.
> Steps to reproduce:
> 1. Running instance of the machine
> 2. Stop with the operating system
> 3. Change offering of machine
> 4. Start the machine
> 5. Waiting for 10 minutes
> 6. CloudStack stops the machine for no reason
> 7. Restart the machine
> In the logs you can find information:
> 2014-02-05 06:27:00,974 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-316:null) 11. The VM i-41-824-VM is in Running state
> 2014-02-05 06:27:00,974 DEBUG [agent.transport.Request]
> (DirectAgent-316:null) Seq 50-1756626952: Processing: { Ans: , MgmtId:
> 160544475005497, via: 50, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.ClusterSyncAnswer":{"_clusterId":2,"_newStates":{"i-41-824-VM":{"t":"f32a4fee-b64e-4868-9c52-2a27e32d4c0e","u":"Running","v":"viridian:true;acpi:true;apic:true;pae:true;nx:false;timeoffset:0;cores-per-socket:4"}},"_isExecuted":false,"result":true,"wait":0}}]
> }
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Sending { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Executing: { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,383 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 9. The VM i-41-824-VM is in Stopping state
> 2014-02-05 06:36:27,625 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 10. The VM i-41-824-VM is in Stopped state
> You will notice that the stop of the machine corresponds to the component
> HA-Worker.
> Such operation after the upgrade is complicating work of users.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6036) CloudStack stops the machine for no reason
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911379#comment-13911379
]
Ryan Farrington commented on CLOUDSTACK-6036:
-
hopefully these logs give you what you need.
> CloudStack stops the machine for no reason
> ---
>
> Key: CLOUDSTACK-6036
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6036
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.1
> Environment: ACS 4.2.1 after upgrade from 3.0.2
> XCP 1.1
>Reporter: Tomasz Zieba
>Assignee: Koushik Das
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: management-server.log.2014-02-20.gz
>
>
> After the upgrade from version 3.0.2 to 4.2.1 appeared very strange error
> associated with self-stopping machine after changing the offering.
> Steps to reproduce:
> 1. Running instance of the machine
> 2. Stop with the operating system
> 3. Change offering of machine
> 4. Start the machine
> 5. Waiting for 10 minutes
> 6. CloudStack stops the machine for no reason
> 7. Restart the machine
> In the logs you can find information:
> 2014-02-05 06:27:00,974 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-316:null) 11. The VM i-41-824-VM is in Running state
> 2014-02-05 06:27:00,974 DEBUG [agent.transport.Request]
> (DirectAgent-316:null) Seq 50-1756626952: Processing: { Ans: , MgmtId:
> 160544475005497, via: 50, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.ClusterSyncAnswer":{"_clusterId":2,"_newStates":{"i-41-824-VM":{"t":"f32a4fee-b64e-4868-9c52-2a27e32d4c0e","u":"Running","v":"viridian:true;acpi:true;apic:true;pae:true;nx:false;timeoffset:0;cores-per-socket:4"}},"_isExecuted":false,"result":true,"wait":0}}]
> }
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Sending { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Executing: { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,383 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 9. The VM i-41-824-VM is in Stopping state
> 2014-02-05 06:36:27,625 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 10. The VM i-41-824-VM is in Stopped state
> You will notice that the stop of the machine corresponds to the component
> HA-Worker.
> Such operation after the upgrade is complicating work of users.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6036) CloudStack stops the machine for no reason
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911384#comment-13911384
]
Koushik Das commented on CLOUDSTACK-6036:
-
Checked the logs, couldn't find any references to i-8-137-VM. Is this the
correct logs?
> CloudStack stops the machine for no reason
> ---
>
> Key: CLOUDSTACK-6036
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6036
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.1
> Environment: ACS 4.2.1 after upgrade from 3.0.2
> XCP 1.1
>Reporter: Tomasz Zieba
>Assignee: Koushik Das
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: management-server.log.2014-02-20.gz
>
>
> After the upgrade from version 3.0.2 to 4.2.1 appeared very strange error
> associated with self-stopping machine after changing the offering.
> Steps to reproduce:
> 1. Running instance of the machine
> 2. Stop with the operating system
> 3. Change offering of machine
> 4. Start the machine
> 5. Waiting for 10 minutes
> 6. CloudStack stops the machine for no reason
> 7. Restart the machine
> In the logs you can find information:
> 2014-02-05 06:27:00,974 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-316:null) 11. The VM i-41-824-VM is in Running state
> 2014-02-05 06:27:00,974 DEBUG [agent.transport.Request]
> (DirectAgent-316:null) Seq 50-1756626952: Processing: { Ans: , MgmtId:
> 160544475005497, via: 50, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.ClusterSyncAnswer":{"_clusterId":2,"_newStates":{"i-41-824-VM":{"t":"f32a4fee-b64e-4868-9c52-2a27e32d4c0e","u":"Running","v":"viridian:true;acpi:true;apic:true;pae:true;nx:false;timeoffset:0;cores-per-socket:4"}},"_isExecuted":false,"result":true,"wait":0}}]
> }
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Sending { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Executing: { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,383 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 9. The VM i-41-824-VM is in Stopping state
> 2014-02-05 06:36:27,625 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 10. The VM i-41-824-VM is in Stopped state
> You will notice that the stop of the machine corresponds to the component
> HA-Worker.
> Such operation after the upgrade is complicating work of users.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5075) issue with destroy vm with local storage ; Unable to update vm disk statistics for vm: 42 from host: 1 java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koushik Das updated CLOUDSTACK-5075:
Fix Version/s: 4.4.0
> issue with destroy vm with local storage ; Unable to update vm disk
> statistics for vm: 42 from host: 1 java.lang.IndexOutOfBoundsException:
> Index: 0, Size: 0
> --
>
> Key: CLOUDSTACK-5075
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5075
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Storage Controller
>Affects Versions: 4.2.1
>Reporter: prashant kumar mishra
> Fix For: 4.3.0
>
> Attachments: Logs_Db.rar
>
>
> Steps to reproduce
> ---
> 1-Prepare a CS with kvm hypervisor
> 2-deploy a vm either in cluster wide or in zone wide PS
> 3-create a data volume on local storage
> 4-Attache it to vm
> 5-try to destroy vm
> Expected
> --
> vm should get destroyed
> Actual
> -
> vms are getting destroyed with warnings in logs
> Logs
> -
> 2013-11-07 12:51:17,432 DEBUG [agent.manager.AgentManagerImpl]
> (Job-Executor-75:job-197 = [ b73a5588-48f3-445e-b5e0-f39e54d18293 ]) Details
> from executing class com.cloud.agent.api.GetVmDiskStatsCommand:
> 2013-11-07 12:51:17,439 DEBUG [db.Transaction.Transaction]
> (Job-Executor-75:job-197 = [ b73a5588-48f3-445e-b5e0-f39e54d18293 ]) Rolling
> back the transaction: Time = 7 Name =
> -AsyncJobManagerImpl$1.run:494-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRun:334-FutureTask.run:166-ThreadPoolExecutor.runWorker:1110-ThreadPoolExecutor$Worker.run:603-Thread.run:679;
> called by
> -Transaction.rollback:897-UserVmManagerImpl.collectVmDiskStatistics:3632-UserVmManagerImpl.prepareStop:5034-VirtualMachineManagerImpl.advanceStop:1258-VirtualMachineManagerImpl.destroy:1402-VMEntityManagerImpl.destroyVirtualMachine:259-VirtualMachineEntityImpl.destroy:225-UserVmManagerImpl.destroyVm:3484-UserVmManagerImpl.destroyVm:2005-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-DestroyVMCmd.execute:112-ApiDispatcher.dispatch:158
> 2013-11-07 12:51:17,443 WARN [cloud.vm.UserVmManagerImpl]
> (Job-Executor-75:job-197 = [ b73a5588-48f3-445e-b5e0-f39e54d18293 ]) Unable
> to update vm disk statistics for vm: 48 from host: 1
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:571)
> at java.util.ArrayList.get(ArrayList.java:349)
> at
> com.cloud.vm.UserVmManagerImpl.collectVmDiskStatistics(UserVmManagerImpl.java:3557)
> at
> com.cloud.vm.UserVmManagerImpl.prepareStop(UserVmManagerImpl.java:5034)
> at
> com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1258)
> at
> com.cloud.vm.VirtualMachineManagerImpl.destroy(VirtualMachineManagerImpl.java:1402)
> at
> org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.destroyVirtualMachine(VMEntityManagerImpl.java:259)
> at
> org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.destroy(VirtualMachineEntityImpl.java:225)
> at
> com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:3484)
> at
> com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:2005)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.vm.DestroyVMCmd.execute(DestroyVMCmd.java:112)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-11-07 12:51:17,448 DEBUG [agent.transport.Request]
> (Job-Executor-75:job-197 = [ b73a5588-48f3-445e-b5e0-f39e54d18293 ]) Seq
> 1-1089012365: Sending { Cmd , MgmtId: 6959054979131, via: 1, Ver: v1, Flags:
> 100011,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"vmName":"i-2-48-VM","wait":0}}]
> }
> 2013-11-07 12:51:17,476 DEBUG [cloud.api.ApiServlet] (catalina-exec-20:null)
> ===S
[jira] [Assigned] (CLOUDSTACK-5075) issue with destroy vm with local storage ; Unable to update vm disk statistics for vm: 42 from host: 1 java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koushik Das reassigned CLOUDSTACK-5075:
---
Assignee: Koushik Das
> issue with destroy vm with local storage ; Unable to update vm disk
> statistics for vm: 42 from host: 1 java.lang.IndexOutOfBoundsException:
> Index: 0, Size: 0
> --
>
> Key: CLOUDSTACK-5075
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5075
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Storage Controller
>Affects Versions: 4.2.1
>Reporter: prashant kumar mishra
>Assignee: Koushik Das
> Fix For: 4.3.0
>
> Attachments: Logs_Db.rar
>
>
> Steps to reproduce
> ---
> 1-Prepare a CS with kvm hypervisor
> 2-deploy a vm either in cluster wide or in zone wide PS
> 3-create a data volume on local storage
> 4-Attache it to vm
> 5-try to destroy vm
> Expected
> --
> vm should get destroyed
> Actual
> -
> vms are getting destroyed with warnings in logs
> Logs
> -
> 2013-11-07 12:51:17,432 DEBUG [agent.manager.AgentManagerImpl]
> (Job-Executor-75:job-197 = [ b73a5588-48f3-445e-b5e0-f39e54d18293 ]) Details
> from executing class com.cloud.agent.api.GetVmDiskStatsCommand:
> 2013-11-07 12:51:17,439 DEBUG [db.Transaction.Transaction]
> (Job-Executor-75:job-197 = [ b73a5588-48f3-445e-b5e0-f39e54d18293 ]) Rolling
> back the transaction: Time = 7 Name =
> -AsyncJobManagerImpl$1.run:494-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRun:334-FutureTask.run:166-ThreadPoolExecutor.runWorker:1110-ThreadPoolExecutor$Worker.run:603-Thread.run:679;
> called by
> -Transaction.rollback:897-UserVmManagerImpl.collectVmDiskStatistics:3632-UserVmManagerImpl.prepareStop:5034-VirtualMachineManagerImpl.advanceStop:1258-VirtualMachineManagerImpl.destroy:1402-VMEntityManagerImpl.destroyVirtualMachine:259-VirtualMachineEntityImpl.destroy:225-UserVmManagerImpl.destroyVm:3484-UserVmManagerImpl.destroyVm:2005-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-DestroyVMCmd.execute:112-ApiDispatcher.dispatch:158
> 2013-11-07 12:51:17,443 WARN [cloud.vm.UserVmManagerImpl]
> (Job-Executor-75:job-197 = [ b73a5588-48f3-445e-b5e0-f39e54d18293 ]) Unable
> to update vm disk statistics for vm: 48 from host: 1
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:571)
> at java.util.ArrayList.get(ArrayList.java:349)
> at
> com.cloud.vm.UserVmManagerImpl.collectVmDiskStatistics(UserVmManagerImpl.java:3557)
> at
> com.cloud.vm.UserVmManagerImpl.prepareStop(UserVmManagerImpl.java:5034)
> at
> com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1258)
> at
> com.cloud.vm.VirtualMachineManagerImpl.destroy(VirtualMachineManagerImpl.java:1402)
> at
> org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.destroyVirtualMachine(VMEntityManagerImpl.java:259)
> at
> org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.destroy(VirtualMachineEntityImpl.java:225)
> at
> com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:3484)
> at
> com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:2005)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.vm.DestroyVMCmd.execute(DestroyVMCmd.java:112)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-11-07 12:51:17,448 DEBUG [agent.transport.Request]
> (Job-Executor-75:job-197 = [ b73a5588-48f3-445e-b5e0-f39e54d18293 ]) Seq
> 1-1089012365: Sending { Cmd , MgmtId: 6959054979131, via: 1, Ver: v1, Flags:
> 100011,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"vmName":"i-2-48-VM","wait":0}}]
> }
> 2013-11-07 12:51:17,476 DEBUG [cloud.api.A
[jira] [Updated] (CLOUDSTACK-5075) issue with destroy vm with local storage ; Unable to update vm disk statistics for vm: 42 from host: 1 java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koushik Das updated CLOUDSTACK-5075:
Fix Version/s: (was: 4.4.0)
4.3.0
> issue with destroy vm with local storage ; Unable to update vm disk
> statistics for vm: 42 from host: 1 java.lang.IndexOutOfBoundsException:
> Index: 0, Size: 0
> --
>
> Key: CLOUDSTACK-5075
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5075
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Storage Controller
>Affects Versions: 4.2.1
>Reporter: prashant kumar mishra
>Assignee: Koushik Das
> Fix For: 4.3.0
>
> Attachments: Logs_Db.rar
>
>
> Steps to reproduce
> ---
> 1-Prepare a CS with kvm hypervisor
> 2-deploy a vm either in cluster wide or in zone wide PS
> 3-create a data volume on local storage
> 4-Attache it to vm
> 5-try to destroy vm
> Expected
> --
> vm should get destroyed
> Actual
> -
> vms are getting destroyed with warnings in logs
> Logs
> -
> 2013-11-07 12:51:17,432 DEBUG [agent.manager.AgentManagerImpl]
> (Job-Executor-75:job-197 = [ b73a5588-48f3-445e-b5e0-f39e54d18293 ]) Details
> from executing class com.cloud.agent.api.GetVmDiskStatsCommand:
> 2013-11-07 12:51:17,439 DEBUG [db.Transaction.Transaction]
> (Job-Executor-75:job-197 = [ b73a5588-48f3-445e-b5e0-f39e54d18293 ]) Rolling
> back the transaction: Time = 7 Name =
> -AsyncJobManagerImpl$1.run:494-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRun:334-FutureTask.run:166-ThreadPoolExecutor.runWorker:1110-ThreadPoolExecutor$Worker.run:603-Thread.run:679;
> called by
> -Transaction.rollback:897-UserVmManagerImpl.collectVmDiskStatistics:3632-UserVmManagerImpl.prepareStop:5034-VirtualMachineManagerImpl.advanceStop:1258-VirtualMachineManagerImpl.destroy:1402-VMEntityManagerImpl.destroyVirtualMachine:259-VirtualMachineEntityImpl.destroy:225-UserVmManagerImpl.destroyVm:3484-UserVmManagerImpl.destroyVm:2005-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-DestroyVMCmd.execute:112-ApiDispatcher.dispatch:158
> 2013-11-07 12:51:17,443 WARN [cloud.vm.UserVmManagerImpl]
> (Job-Executor-75:job-197 = [ b73a5588-48f3-445e-b5e0-f39e54d18293 ]) Unable
> to update vm disk statistics for vm: 48 from host: 1
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:571)
> at java.util.ArrayList.get(ArrayList.java:349)
> at
> com.cloud.vm.UserVmManagerImpl.collectVmDiskStatistics(UserVmManagerImpl.java:3557)
> at
> com.cloud.vm.UserVmManagerImpl.prepareStop(UserVmManagerImpl.java:5034)
> at
> com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1258)
> at
> com.cloud.vm.VirtualMachineManagerImpl.destroy(VirtualMachineManagerImpl.java:1402)
> at
> org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.destroyVirtualMachine(VMEntityManagerImpl.java:259)
> at
> org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.destroy(VirtualMachineEntityImpl.java:225)
> at
> com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:3484)
> at
> com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:2005)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.vm.DestroyVMCmd.execute(DestroyVMCmd.java:112)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-11-07 12:51:17,448 DEBUG [agent.transport.Request]
> (Job-Executor-75:job-197 = [ b73a5588-48f3-445e-b5e0-f39e54d18293 ]) Seq
> 1-1089012365: Sending { Cmd , MgmtId: 6959054979131, via: 1, Ver: v1, Flags:
> 100011,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"vmName":"i-2-48-VM","wait":0}}]
> }
> 2013-11-07 12
[jira] [Commented] (CLOUDSTACK-5075) issue with destroy vm with local storage ; Unable to update vm disk statistics for vm: 42 from host: 1 java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911390#comment-13911390 ] Koushik Das commented on CLOUDSTACK-5075: - Didn't see the issue in 4.3 branch. From the logs doesn't look related to KVM. Tried the following: 1. Deployed a vm on cluster wide storage 2. Created a data volume on local storage 3. Attached it to the vm in step 1 4. Destroyed the vm Vm got destroyed without getting any warnings in logs. > issue with destroy vm with local storage ; Unable to update vm disk > statistics for vm: 42 from host: 1 java.lang.IndexOutOfBoundsException: > Index: 0, Size: 0 > -- > > Key: CLOUDSTACK-5075 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5075 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Storage Controller >Affects Versions: 4.2.1 >Reporter: prashant kumar mishra >Assignee: Koushik Das > Fix For: 4.3.0 > > Attachments: Logs_Db.rar > > > Steps to reproduce > --- > 1-Prepare a CS with kvm hypervisor > 2-deploy a vm either in cluster wide or in zone wide PS > 3-create a data volume on local storage > 4-Attache it to vm > 5-try to destroy vm > Expected > -- > vm should get destroyed > Actual > - > vms are getting destroyed with warnings in logs > Logs > - > 2013-11-07 12:51:17,432 DEBUG [agent.manager.AgentManagerImpl] > (Job-Executor-75:job-197 = [ b73a5588-48f3-445e-b5e0-f39e54d18293 ]) Details > from executing class com.cloud.agent.api.GetVmDiskStatsCommand: > 2013-11-07 12:51:17,439 DEBUG [db.Transaction.Transaction] > (Job-Executor-75:job-197 = [ b73a5588-48f3-445e-b5e0-f39e54d18293 ]) Rolling > back the transaction: Time = 7 Name = > -AsyncJobManagerImpl$1.run:494-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRun:334-FutureTask.run:166-ThreadPoolExecutor.runWorker:1110-ThreadPoolExecutor$Worker.run:603-Thread.run:679; > called by > -Transaction.rollback:897-UserVmManagerImpl.collectVmDiskStatistics:3632-UserVmManagerImpl.prepareStop:5034-VirtualMachineManagerImpl.advanceStop:1258-VirtualMachineManagerImpl.destroy:1402-VMEntityManagerImpl.destroyVirtualMachine:259-VirtualMachineEntityImpl.destroy:225-UserVmManagerImpl.destroyVm:3484-UserVmManagerImpl.destroyVm:2005-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-DestroyVMCmd.execute:112-ApiDispatcher.dispatch:158 > 2013-11-07 12:51:17,443 WARN [cloud.vm.UserVmManagerImpl] > (Job-Executor-75:job-197 = [ b73a5588-48f3-445e-b5e0-f39e54d18293 ]) Unable > to update vm disk statistics for vm: 48 from host: 1 > java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 > at java.util.ArrayList.rangeCheck(ArrayList.java:571) > at java.util.ArrayList.get(ArrayList.java:349) > at > com.cloud.vm.UserVmManagerImpl.collectVmDiskStatistics(UserVmManagerImpl.java:3557) > at > com.cloud.vm.UserVmManagerImpl.prepareStop(UserVmManagerImpl.java:5034) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1258) > at > com.cloud.vm.VirtualMachineManagerImpl.destroy(VirtualMachineManagerImpl.java:1402) > at > org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.destroyVirtualMachine(VMEntityManagerImpl.java:259) > at > org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.destroy(VirtualMachineEntityImpl.java:225) > at > com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:3484) > at > com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:2005) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) > at > org.apache.cloudstack.api.command.user.vm.DestroyVMCmd.execute(DestroyVMCmd.java:112) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) > at > com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) > 2013-11-07 12:51:17,448 DEBUG [agent.transport.Request] > (Job-Ex
[jira] [Resolved] (CLOUDSTACK-5075) issue with destroy vm with local storage ; Unable to update vm disk statistics for vm: 42 from host: 1 java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koushik Das resolved CLOUDSTACK-5075.
-
Resolution: Fixed
> issue with destroy vm with local storage ; Unable to update vm disk
> statistics for vm: 42 from host: 1 java.lang.IndexOutOfBoundsException:
> Index: 0, Size: 0
> --
>
> Key: CLOUDSTACK-5075
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5075
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Storage Controller
>Affects Versions: 4.2.1
>Reporter: prashant kumar mishra
>Assignee: Koushik Das
> Fix For: 4.3.0
>
> Attachments: Logs_Db.rar
>
>
> Steps to reproduce
> ---
> 1-Prepare a CS with kvm hypervisor
> 2-deploy a vm either in cluster wide or in zone wide PS
> 3-create a data volume on local storage
> 4-Attache it to vm
> 5-try to destroy vm
> Expected
> --
> vm should get destroyed
> Actual
> -
> vms are getting destroyed with warnings in logs
> Logs
> -
> 2013-11-07 12:51:17,432 DEBUG [agent.manager.AgentManagerImpl]
> (Job-Executor-75:job-197 = [ b73a5588-48f3-445e-b5e0-f39e54d18293 ]) Details
> from executing class com.cloud.agent.api.GetVmDiskStatsCommand:
> 2013-11-07 12:51:17,439 DEBUG [db.Transaction.Transaction]
> (Job-Executor-75:job-197 = [ b73a5588-48f3-445e-b5e0-f39e54d18293 ]) Rolling
> back the transaction: Time = 7 Name =
> -AsyncJobManagerImpl$1.run:494-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRun:334-FutureTask.run:166-ThreadPoolExecutor.runWorker:1110-ThreadPoolExecutor$Worker.run:603-Thread.run:679;
> called by
> -Transaction.rollback:897-UserVmManagerImpl.collectVmDiskStatistics:3632-UserVmManagerImpl.prepareStop:5034-VirtualMachineManagerImpl.advanceStop:1258-VirtualMachineManagerImpl.destroy:1402-VMEntityManagerImpl.destroyVirtualMachine:259-VirtualMachineEntityImpl.destroy:225-UserVmManagerImpl.destroyVm:3484-UserVmManagerImpl.destroyVm:2005-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-DestroyVMCmd.execute:112-ApiDispatcher.dispatch:158
> 2013-11-07 12:51:17,443 WARN [cloud.vm.UserVmManagerImpl]
> (Job-Executor-75:job-197 = [ b73a5588-48f3-445e-b5e0-f39e54d18293 ]) Unable
> to update vm disk statistics for vm: 48 from host: 1
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:571)
> at java.util.ArrayList.get(ArrayList.java:349)
> at
> com.cloud.vm.UserVmManagerImpl.collectVmDiskStatistics(UserVmManagerImpl.java:3557)
> at
> com.cloud.vm.UserVmManagerImpl.prepareStop(UserVmManagerImpl.java:5034)
> at
> com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1258)
> at
> com.cloud.vm.VirtualMachineManagerImpl.destroy(VirtualMachineManagerImpl.java:1402)
> at
> org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.destroyVirtualMachine(VMEntityManagerImpl.java:259)
> at
> org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.destroy(VirtualMachineEntityImpl.java:225)
> at
> com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:3484)
> at
> com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:2005)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.vm.DestroyVMCmd.execute(DestroyVMCmd.java:112)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-11-07 12:51:17,448 DEBUG [agent.transport.Request]
> (Job-Executor-75:job-197 = [ b73a5588-48f3-445e-b5e0-f39e54d18293 ]) Seq
> 1-1089012365: Sending { Cmd , MgmtId: 6959054979131, via: 1, Ver: v1, Flags:
> 100011,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"vmName":"i-2-48-VM","wait":0}}]
> }
> 2013-11-07 12:51:17,476 DEBUG [cloud.api.ApiServle
[jira] [Commented] (CLOUDSTACK-6067) UI does not list routers matched by search string
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911426#comment-13911426 ] Remi Bergsma commented on CLOUDSTACK-6067: -- This happens also on the 'Infrastructure' overview page where it displays the number of routers for the project. It does the same two api calls and does a count. This results in all projects having their own router(s) counted + all project routers. > UI does not list routers matched by search string > - > > Key: CLOUDSTACK-6067 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6067 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.1 >Reporter: Rutger te Nijenhuis >Priority: Trivial > > While searching for virtual routers on a specific keyword, the gui returns > the matched search and all project routers. Keyword isn't applied to second > api call listing the project routers: > api?command=listRouters&listAll=true&page=1&pagesize=20&keyword=r-1313&response=json&sessionkey=qjeqwijeo12@*($(!*kjsij&_=1392044881273 > /client > api?command=listRouters&listAll=true&page=1&pagesize=20&projectid=-1&response=json&sessionkey=qjeqwijeo12@*($(!*kjsij&_=1392044881446 > /client -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-4666) VM created under projects don't show up in admin instances, or under hosts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911431#comment-13911431 ] Remi Bergsma commented on CLOUDSTACK-4666: -- Alena, Danny, The UI does list the project routers (by making 2 api calls as you said) but for instances/virtual machines this is not the case. It would make sense to have the same behavior. As an admin I would like to see what is still running on a given host, for example when I want to decommission a cluster. Could you please add the 2nd API call (projectid=-1) so that all instances are showed to the admin? Thanks! Remi > VM created under projects don't show up in admin instances, or under hosts > -- > > Key: CLOUDSTACK-4666 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4666 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.1.0 > Environment: CentOS release 6.4 (Final) >Reporter: danny webb > Attachments: hosts_view_instances.png, instances_tab.png, > only_in_project_view.png > > > If you create a VM via the API that is assigned to a project it the VM isn't > viewable anywhere except in the project view. Even for the admin user. > Places you can't see them in the UI: > Admin -> Instances > Admin -> Infrastructure -> Hosts -> Hostname -> View Instances > User -> Instances > this is problematic because you have no way of gauging the overall > utilisation of hosts without being able to see all hosts assigned to them. > It seems to me that assigning a VM to a project shouldn't remove it from the > overall instances list. You should be able as a user be able to have the > overall view of instances regardless of project in the instances view as long > as you are a member of that project. If you need to get granular with what > VMs are assigned to what projects you can do that via the project view. And > the admin should definitely be able to see all instances in the instances > page without having to delve into the project view and trying to find the > host. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6058) Update the java binding used to the latest one that came with XenServer 6.2 sp1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911462#comment-13911462 ] ASF subversion and git services commented on CLOUDSTACK-6058: - Commit 505da760e065450f52f3a22649bd648af8f9c854 in cloudstack's branch refs/heads/master from [~sanjay.tripathi] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=505da76 ] CLOUDSTACK-6058: XenServer 6.2sp1 xenapi customization as per CloudStack resource code. Signed-off-by: Hugo Trippaers > Update the java binding used to the latest one that came with XenServer 6.2 > sp1 > --- > > Key: CLOUDSTACK-6058 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6058 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Sanjay Tripathi >Assignee: Sanjay Tripathi > Fix For: 4.4.0 > > > With the latest release of XenServer (6.2sp1), updated java binding are > available. The bindings used in cloudstack need to be updated with the same. > Cloudstack currently makes customizations to these bindings. These > customizations also need to be ported. These bindings are also needed for > adding support new features that are available with XenServer 6.2sp1; vGPU > etc. > Release Planning: > Dev list discussion: N/A > Functional Spec: N/A > Feature Branch: reviewboard > Docs shouldn't change > QA will happen as part of the overall release testing -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6058) Update the java binding used to the latest one that came with XenServer 6.2 sp1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911461#comment-13911461 ] ASF subversion and git services commented on CLOUDSTACK-6058: - Commit 2ff9abadf6e6af835f2835ea09e1d8b5421800d0 in cloudstack's branch refs/heads/master from [~sanjay.tripathi] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2ff9aba ] CLOUDSTACK-6058: New XenServer 6.2sp1 SDKs This commit replaces old XenServer SDKs with lastet XenServer release i.e. 6.2sp1 SDKs. This SDK also includes new class "VGPU" to support vGPU functionality in XenServer. Signed-off-by: Hugo Trippaers > Update the java binding used to the latest one that came with XenServer 6.2 > sp1 > --- > > Key: CLOUDSTACK-6058 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6058 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Sanjay Tripathi >Assignee: Sanjay Tripathi > Fix For: 4.4.0 > > > With the latest release of XenServer (6.2sp1), updated java binding are > available. The bindings used in cloudstack need to be updated with the same. > Cloudstack currently makes customizations to these bindings. These > customizations also need to be ported. These bindings are also needed for > adding support new features that are available with XenServer 6.2sp1; vGPU > etc. > Release Planning: > Dev list discussion: N/A > Functional Spec: N/A > Feature Branch: reviewboard > Docs shouldn't change > QA will happen as part of the overall release testing -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5075) issue with destroy vm with local storage ; Unable to update vm disk statistics for vm: 42 from host: 1 java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
prashant kumar mishra closed CLOUDSTACK-5075.
-
tested on kvm setup , destroyCmd went smoothly
> issue with destroy vm with local storage ; Unable to update vm disk
> statistics for vm: 42 from host: 1 java.lang.IndexOutOfBoundsException:
> Index: 0, Size: 0
> --
>
> Key: CLOUDSTACK-5075
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5075
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Storage Controller
>Affects Versions: 4.2.1
>Reporter: prashant kumar mishra
>Assignee: Koushik Das
> Fix For: 4.3.0
>
> Attachments: Logs_Db.rar
>
>
> Steps to reproduce
> ---
> 1-Prepare a CS with kvm hypervisor
> 2-deploy a vm either in cluster wide or in zone wide PS
> 3-create a data volume on local storage
> 4-Attache it to vm
> 5-try to destroy vm
> Expected
> --
> vm should get destroyed
> Actual
> -
> vms are getting destroyed with warnings in logs
> Logs
> -
> 2013-11-07 12:51:17,432 DEBUG [agent.manager.AgentManagerImpl]
> (Job-Executor-75:job-197 = [ b73a5588-48f3-445e-b5e0-f39e54d18293 ]) Details
> from executing class com.cloud.agent.api.GetVmDiskStatsCommand:
> 2013-11-07 12:51:17,439 DEBUG [db.Transaction.Transaction]
> (Job-Executor-75:job-197 = [ b73a5588-48f3-445e-b5e0-f39e54d18293 ]) Rolling
> back the transaction: Time = 7 Name =
> -AsyncJobManagerImpl$1.run:494-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRun:334-FutureTask.run:166-ThreadPoolExecutor.runWorker:1110-ThreadPoolExecutor$Worker.run:603-Thread.run:679;
> called by
> -Transaction.rollback:897-UserVmManagerImpl.collectVmDiskStatistics:3632-UserVmManagerImpl.prepareStop:5034-VirtualMachineManagerImpl.advanceStop:1258-VirtualMachineManagerImpl.destroy:1402-VMEntityManagerImpl.destroyVirtualMachine:259-VirtualMachineEntityImpl.destroy:225-UserVmManagerImpl.destroyVm:3484-UserVmManagerImpl.destroyVm:2005-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-DestroyVMCmd.execute:112-ApiDispatcher.dispatch:158
> 2013-11-07 12:51:17,443 WARN [cloud.vm.UserVmManagerImpl]
> (Job-Executor-75:job-197 = [ b73a5588-48f3-445e-b5e0-f39e54d18293 ]) Unable
> to update vm disk statistics for vm: 48 from host: 1
> java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:571)
> at java.util.ArrayList.get(ArrayList.java:349)
> at
> com.cloud.vm.UserVmManagerImpl.collectVmDiskStatistics(UserVmManagerImpl.java:3557)
> at
> com.cloud.vm.UserVmManagerImpl.prepareStop(UserVmManagerImpl.java:5034)
> at
> com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1258)
> at
> com.cloud.vm.VirtualMachineManagerImpl.destroy(VirtualMachineManagerImpl.java:1402)
> at
> org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.destroyVirtualMachine(VMEntityManagerImpl.java:259)
> at
> org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.destroy(VirtualMachineEntityImpl.java:225)
> at
> com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:3484)
> at
> com.cloud.vm.UserVmManagerImpl.destroyVm(UserVmManagerImpl.java:2005)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.vm.DestroyVMCmd.execute(DestroyVMCmd.java:112)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-11-07 12:51:17,448 DEBUG [agent.transport.Request]
> (Job-Executor-75:job-197 = [ b73a5588-48f3-445e-b5e0-f39e54d18293 ]) Seq
> 1-1089012365: Sending { Cmd , MgmtId: 6959054979131, via: 1, Ver: v1, Flags:
> 100011,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"vmName":"i-2-48-VM","wait":0}}]
> }
> 2013-11
[jira] [Commented] (CLOUDSTACK-4606) HA does not kick on Routing VM hanging on kernel panic.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911485#comment-13911485
]
Remi Bergsma commented on CLOUDSTACK-4606:
--
Wouldn't it be easiest to have the virtual router reboot itself in case of a
kernel panic after, say, 10 seconds?
/etc/sysctl.conf:
kernel.panic = 10
The backup node will then take over. Or if it's non-HA, it will work again
after the reboot.
> HA does not kick on Routing VM hanging on kernel panic.
> ---
>
> Key: CLOUDSTACK-4606
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4606
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.1.1
>Reporter: Roeland Kuipers
>
> If a routing VM hangs on kernel panic. It will never be recovered by the HA
> process of Cloudstack.
> In this case the Virtual Router cannot be accessed anymore over link-local
> and/or management address and cannot be managed anymore.
> We think HA should reboot a router when this occurs.
> See also CLOUDSTACK-4607 and CLOUDSTACK-4605
> Errors observed while hanging:
> 013-09-04 18:57:42,108 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-446:null) callHostPlugin failed for cmd: routerProxy with args
> args: vpc_netusage.sh 169.254.3.166 -l 95.142.107.111 -g, due to Failed to
> create input stream: Read timed out
> com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for
> cmd: routerProxy with args args: vpc_netusage.sh 169.254.3.166 -l
> 95.142.107.111 -g, due to Failed to create input stream: Read timed out
> 2013-09-04 18:57:42,109 DEBUG [agent.transport.Request]
> (DirectAgent-446:null) Seq 105-1580215291: Processing: { Ans: , MgmtId:
> 345052370017, via: 105, Ver: v1, Flags: 10,
> [{"NetworkUsageAnswer":{"result":false,"details":"Exception:
> com.cloud.utils.exception.CloudRuntimeException\nMessage: callHostPlugin
> failed for cmd: routerProxy with args args: vpc_netusage.sh 169.254.3.166 -l
> 95.142.107.111 -g, due to Failed to create input stream: Read timed
> out\nStack: com.cloud.utils.exception.CloudRuntimeException: callHostPlugin
> failed for cmd: routerProxy with args args: vpc_netusage.sh 169.254.3.166 -l
> 95.142.107.111 -g, due to Failed to create input stream: Read timed
> out\n\tat
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.callHostPlugin(CitrixResourceBase.java:3745)\n\tat
>
> com.cloud.hypervisor.xen.resource.XenServer56Resource.VPCNetworkUsage(XenServer56Resource.java:186)\n\tat
>
> com.cloud.hypervisor.xen.resource.XenServer56Resource.execute(XenServer56Resource.java:211)\n\tat
>
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:71)\n\tat
>
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:191)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)\n\tat
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)\n\tat
> java.util.concurrent.FutureTask.run(FutureTask.java:138)\n\tat
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)\n\tat
> java.lang.Thread.run(Thread.java:662)\n","wait":0}}] }
> Message: callHostPlugin failed for cmd: routerProxy with args args:
> vpc_netusage.sh 169.254.3.166 -l 95.142.107.111 -g, due to Failed to create
> input stream: Read timed out
> Stack: com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed
> for cmd: routerProxy with args args: vpc_netusage.sh 169.254.3.166 -l
> 95.142.107.111 -g, due to Failed to create input stream: Read timed out
> Message: callHostPlugin failed for cmd: routerProxy with args args:
> vpc_netusage.sh 169.254.3.166 -l 95.142.107.111 -g, due to Failed to create
> input stream: Read timed out
> Stack: com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed
> for cmd: routerProxy with args args: vpc_netusage.sh 169.254.3.166 -l
> 95.142.107.111 -g, due to Failed to create input stream: Read timed out
> 2013-09-04 19:08:20,909 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-367:null) callHostPlugin failed for cmd: routerProxy with args
> args: vpc_netusage.sh 169.254.3.166 -l 95.142.107.111 -g, due to Failed to
> create input stream: Read timed out
> com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for
> cmd: r
[jira] [Updated] (CLOUDSTACK-5641) Local disk usage on host don't show up in the admin's webui
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Namita Chaudhari updated CLOUDSTACK-5641: - Attachment: CS_master_5641.JPG > Local disk usage on host don't show up in the admin's webui > --- > > Key: CLOUDSTACK-5641 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5641 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Nitin Mehta > Attachments: CS_master_5641.JPG > > > Local disk usage on host don't show up in the admin's webui. > I have local storage enabled in the environment. I have VMs on the storage > but since upgrading to 4.2 the UI does not show space utilization on the > local storage. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-6058) Update the java binding used to the latest one that came with XenServer 6.2 sp1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi resolved CLOUDSTACK-6058. - Resolution: Fixed > Update the java binding used to the latest one that came with XenServer 6.2 > sp1 > --- > > Key: CLOUDSTACK-6058 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6058 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Sanjay Tripathi >Assignee: Sanjay Tripathi > Fix For: 4.4.0 > > > With the latest release of XenServer (6.2sp1), updated java binding are > available. The bindings used in cloudstack need to be updated with the same. > Cloudstack currently makes customizations to these bindings. These > customizations also need to be ported. These bindings are also needed for > adding support new features that are available with XenServer 6.2sp1; vGPU > etc. > Release Planning: > Dev list discussion: N/A > Functional Spec: N/A > Feature Branch: reviewboard > Docs shouldn't change > QA will happen as part of the overall release testing -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6168) vm.instancename.flag inefficient
JF Vincent created CLOUDSTACK-6168: -- Summary: vm.instancename.flag inefficient Key: CLOUDSTACK-6168 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6168 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: Cloudstack 4.2.1 on Reporter: JF Vincent Fix For: Future -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6168) vm.instancename.flag inefficient
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] JF Vincent updated CLOUDSTACK-6168: --- Description: have set vm.instancename.flag to YES, restarted the management server -> started a new instance in my KVM zone with or without any display name => no change on instance name on hypervisor. -> started a new instance in my vCenter zone with a display name madrid. Instance name on ESXi is just madrid and not i-xx--madrid. Regards JF > vm.instancename.flag inefficient > > > Key: CLOUDSTACK-6168 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6168 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 > Environment: Cloudstack 4.2.1 on >Reporter: JF Vincent > Fix For: Future > > > have set vm.instancename.flag to YES, restarted the management server > -> started a new instance in my KVM zone with or without any display name => > no change on instance name on hypervisor. > -> started a new instance in my vCenter zone with a display name madrid. > Instance name on ESXi is just madrid and not i-xx--madrid. > Regards > JF -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5641) Local disk usage on host don't show up in the admin's webui
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911575#comment-13911575 ] Namita Chaudhari commented on CLOUDSTACK-5641: -- In storage pool view, when the capacity_type = 3, the disk_used_capacity is NULL, but the local storage displayed on the UI is not affected. mysql> select * from storage_pool_view \G; *** 1. row *** id: 1 uuid: 9f3f9262-3f77-09cc-2df7-0d8475676260 name: devcloud Local Storage status: Up path: ext pool_type: EXT host_address: 192.168.56.10 created: 2013-10-30 13:11:02 removed: NULL capacity_bytes: 158533136384 capacity_iops: NULL scope: HOST hypervisor: NULL storage_provider_name: DefaultPrimary cluster_id: 1 cluster_uuid: a07d10c6-8108-4aa5-b5b7-cb455589e815 cluster_name: test000 cluster_type: CloudManaged data_center_id: 1 data_center_uuid: eb093781-6728-470a-89e9-1b2ba0d99742 data_center_name: DevCloud0 data_center_type: Basic pod_id: 1 pod_uuid: db4ed361-cc29-480c-a57a-d2490ee74ce2 pod_name: test00 tag: NULL disk_used_capacity: null disk_reserved_capacity: NULL job_id: NULL job_uuid: NULL job_status: NULL job_account_id: NULL 1 row in set (0.00 sec) > Local disk usage on host don't show up in the admin's webui > --- > > Key: CLOUDSTACK-5641 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5641 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Nitin Mehta > Attachments: CS_master_5641.JPG > > > Local disk usage on host don't show up in the admin's webui. > I have local storage enabled in the environment. I have VMs on the storage > but since upgrading to 4.2 the UI does not show space utilization on the > local storage. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Issue Comment Deleted] (CLOUDSTACK-5641) Local disk usage on host don't show up in the admin's webui
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Namita Chaudhari updated CLOUDSTACK-5641: - Comment: was deleted (was: In storage pool view, when the capacity_type = 3, the disk_used_capacity is NULL, but the local storage displayed on the UI is not affected. mysql> select * from storage_pool_view \G; *** 1. row *** id: 1 uuid: 9f3f9262-3f77-09cc-2df7-0d8475676260 name: devcloud Local Storage status: Up path: ext pool_type: EXT host_address: 192.168.56.10 created: 2013-10-30 13:11:02 removed: NULL capacity_bytes: 158533136384 capacity_iops: NULL scope: HOST hypervisor: NULL storage_provider_name: DefaultPrimary cluster_id: 1 cluster_uuid: a07d10c6-8108-4aa5-b5b7-cb455589e815 cluster_name: test000 cluster_type: CloudManaged data_center_id: 1 data_center_uuid: eb093781-6728-470a-89e9-1b2ba0d99742 data_center_name: DevCloud0 data_center_type: Basic pod_id: 1 pod_uuid: db4ed361-cc29-480c-a57a-d2490ee74ce2 pod_name: test00 tag: NULL disk_used_capacity: null disk_reserved_capacity: NULL job_id: NULL job_uuid: NULL job_status: NULL job_account_id: NULL 1 row in set (0.00 sec)) > Local disk usage on host don't show up in the admin's webui > --- > > Key: CLOUDSTACK-5641 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5641 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Nitin Mehta > Attachments: CS_master_5641.JPG > > > Local disk usage on host don't show up in the admin's webui. > I have local storage enabled in the environment. I have VMs on the storage > but since upgrading to 4.2 the UI does not show space utilization on the > local storage. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5641) Local disk usage on host don't show up in the admin's webui
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911586#comment-13911586 ] Namita Chaudhari commented on CLOUDSTACK-5641: -- In storage pool view, when the capacity_type = 3, the disk_used_capacity is NULL, but the local storage displayed on the UI is not affected. mysql> select * from storage_pool_view \G; id: 1 uuid: 9f3f9262-3f77-09cc-2df7-0d8475676260 name: devcloud Local Storage status: Up path: ext pool_type: EXT host_address: 192.168.56.10 created: 2013-10-30 13:11:02 removed: NULL capacity_bytes: 158533136384 capacity_iops: NULL scope: HOST hypervisor: NULL storage_provider_name: DefaultPrimary cluster_id: 1 cluster_uuid: a07d10c6-8108-4aa5-b5b7-cb455589e815 cluster_name: test000 cluster_type: CloudManaged data_center_id: 1 data_center_uuid: eb093781-6728-470a-89e9-1b2ba0d99742 data_center_name: DevCloud0 data_center_type: Basic pod_id: 1 pod_uuid: db4ed361-cc29-480c-a57a-d2490ee74ce2 pod_name: test00 tag: NULL disk_used_capacity: NULL disk_reserved_capacity: NULL job_id: NULL job_uuid: NULL job_status: NULL job_account_id: NULL 1 row in set (0.00 sec) > Local disk usage on host don't show up in the admin's webui > --- > > Key: CLOUDSTACK-5641 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5641 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Nitin Mehta > Attachments: CS_master_5641.JPG > > > Local disk usage on host don't show up in the admin's webui. > I have local storage enabled in the environment. I have VMs on the storage > but since upgrading to 4.2 the UI does not show space utilization on the > local storage. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5641) Local disk usage on host don't show up in the admin's webui
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911588#comment-13911588 ] Namita Chaudhari commented on CLOUDSTACK-5641: -- In storage pool view, when the capacity_type = 3, the disk_used_capacity is NULL, but the local storage displayed on the UI is not affected. mysql> select * from storage_pool_view \G; id: 1 uuid: 9f3f9262-3f77-09cc-2df7-0d8475676260 name: devcloud Local Storage status: Up path: ext pool_type: EXT host_address: 192.168.56.10 created: 2013-10-30 13:11:02 removed: NULL capacity_bytes: 158533136384 capacity_iops: NULL scope: HOST hypervisor: NULL storage_provider_name: DefaultPrimary cluster_id: 1 cluster_uuid: a07d10c6-8108-4aa5-b5b7-cb455589e815 cluster_name: test000 cluster_type: CloudManaged data_center_id: 1 data_center_uuid: eb093781-6728-470a-89e9-1b2ba0d99742 data_center_name: DevCloud0 data_center_type: Basic pod_id: 1 pod_uuid: db4ed361-cc29-480c-a57a-d2490ee74ce2 pod_name: test00 tag: NULL disk_used_capacity: NULL disk_reserved_capacity: NULL job_id: NULL job_uuid: NULL job_status: NULL job_account_id: NULL 1 row in set (0.00 sec) > Local disk usage on host don't show up in the admin's webui > --- > > Key: CLOUDSTACK-5641 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5641 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Nitin Mehta > Attachments: CS_master_5641.JPG > > > Local disk usage on host don't show up in the admin's webui. > I have local storage enabled in the environment. I have VMs on the storage > but since upgrading to 4.2 the UI does not show space utilization on the > local storage. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (CLOUDSTACK-5641) Local disk usage on host don't show up in the admin's webui
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911586#comment-13911586 ] Namita Chaudhari edited comment on CLOUDSTACK-5641 at 2/25/14 1:51 PM: --- In storage pool view, when the capacity_type = 3, the disk_used_capacity is NULL, but the local storage displayed on the UI is not affected. mysql> select * from storage_pool_view \G;\ *** 1. row *** id: 1 uuid: 9f3f9262-3f77-09cc-2df7-0d8475676260 name: devcloud Local Storage status: Up path: ext pool_type: EXT host_address: 192.168.56.10 created: 2013-10-30 13:11:02 removed: NULL capacity_bytes: 158533136384 capacity_iops: NULL scope: HOST hypervisor: NULL storage_provider_name: DefaultPrimary cluster_id: 1 cluster_uuid: a07d10c6-8108-4aa5-b5b7-cb455589e815 cluster_name: test000 cluster_type: CloudManaged data_center_id: 1 data_center_uuid: eb093781-6728-470a-89e9-1b2ba0d99742 data_center_name: DevCloud0 data_center_type: Basic pod_id: 1 pod_uuid: db4ed361-cc29-480c-a57a-d2490ee74ce2 pod_name: test00 tag: NULL disk_used_capacity: NULL disk_reserved_capacity: NULL job_id: NULL job_uuid: NULL job_status: NULL job_account_id: NULL 1 row in set (0.00 sec) was (Author: namita.chaudh...@sungard.com): In storage pool view, when the capacity_type = 3, the disk_used_capacity is NULL, but the local storage displayed on the UI is not affected. mysql> select * from storage_pool_view \G; id: 1 uuid: 9f3f9262-3f77-09cc-2df7-0d8475676260 name: devcloud Local Storage status: Up path: ext pool_type: EXT host_address: 192.168.56.10 created: 2013-10-30 13:11:02 removed: NULL capacity_bytes: 158533136384 capacity_iops: NULL scope: HOST hypervisor: NULL storage_provider_name: DefaultPrimary cluster_id: 1 cluster_uuid: a07d10c6-8108-4aa5-b5b7-cb455589e815 cluster_name: test000 cluster_type: CloudManaged data_center_id: 1 data_center_uuid: eb093781-6728-470a-89e9-1b2ba0d99742 data_center_name: DevCloud0 data_center_type: Basic pod_id: 1 pod_uuid: db4ed361-cc29-480c-a57a-d2490ee74ce2 pod_name: test00 tag: NULL disk_used_capacity: NULL disk_reserved_capacity: NULL job_id: NULL job_uuid: NULL job_status: NULL job_account_id: NULL 1 row in set (0.00 sec) > Local disk usage on host don't show up in the admin's webui > --- > > Key: CLOUDSTACK-5641 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5641 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Nitin Mehta > Attachments: CS_master_5641.JPG > > > Local disk usage on host don't show up in the admin's webui. > I have local storage enabled in the environment. I have VMs on the storage > but since upgrading to 4.2 the UI does not show space utilization on the > local storage. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Issue Comment Deleted] (CLOUDSTACK-5641) Local disk usage on host don't show up in the admin's webui
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Namita Chaudhari updated CLOUDSTACK-5641: - Comment: was deleted (was: In storage pool view, when the capacity_type = 3, the disk_used_capacity is NULL, but the local storage displayed on the UI is not affected. mysql> select * from storage_pool_view \G;\ *** 1. row *** id: 1 uuid: 9f3f9262-3f77-09cc-2df7-0d8475676260 name: devcloud Local Storage status: Up path: ext pool_type: EXT host_address: 192.168.56.10 created: 2013-10-30 13:11:02 removed: NULL capacity_bytes: 158533136384 capacity_iops: NULL scope: HOST hypervisor: NULL storage_provider_name: DefaultPrimary cluster_id: 1 cluster_uuid: a07d10c6-8108-4aa5-b5b7-cb455589e815 cluster_name: test000 cluster_type: CloudManaged data_center_id: 1 data_center_uuid: eb093781-6728-470a-89e9-1b2ba0d99742 data_center_name: DevCloud0 data_center_type: Basic pod_id: 1 pod_uuid: db4ed361-cc29-480c-a57a-d2490ee74ce2 pod_name: test00 tag: NULL disk_used_capacity: NULL disk_reserved_capacity: NULL job_id: NULL job_uuid: NULL job_status: NULL job_account_id: NULL 1 row in set (0.00 sec)) > Local disk usage on host don't show up in the admin's webui > --- > > Key: CLOUDSTACK-5641 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5641 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Nitin Mehta > Attachments: CS_master_5641.JPG > > > Local disk usage on host don't show up in the admin's webui. > I have local storage enabled in the environment. I have VMs on the storage > but since upgrading to 4.2 the UI does not show space utilization on the > local storage. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6168) vm.instancename.flag inefficient
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911648#comment-13911648 ] Wei Zhou commented on CLOUDSTACK-6168: -- This is related to CLOUDSTACK-778. I have the same question on KVM. > vm.instancename.flag inefficient > > > Key: CLOUDSTACK-6168 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6168 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 > Environment: Cloudstack 4.2.1 on >Reporter: JF Vincent > Fix For: Future > > > have set vm.instancename.flag to YES, restarted the management server > -> started a new instance in my KVM zone with or without any display name => > no change on instance name on hypervisor. > -> started a new instance in my vCenter zone with a display name madrid. > Instance name on ESXi is just madrid and not i-xx--madrid. > Regards > JF -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6036) CloudStack stops the machine for no reason
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Farrington updated CLOUDSTACK-6036:
Attachment: management-server.log.2014-02-19.gz
sorry uploaded the wrong day. The entries for the instance is near the end of
the day.
> CloudStack stops the machine for no reason
> ---
>
> Key: CLOUDSTACK-6036
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6036
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.1
> Environment: ACS 4.2.1 after upgrade from 3.0.2
> XCP 1.1
>Reporter: Tomasz Zieba
>Assignee: Koushik Das
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: management-server.log.2014-02-19.gz,
> management-server.log.2014-02-20.gz
>
>
> After the upgrade from version 3.0.2 to 4.2.1 appeared very strange error
> associated with self-stopping machine after changing the offering.
> Steps to reproduce:
> 1. Running instance of the machine
> 2. Stop with the operating system
> 3. Change offering of machine
> 4. Start the machine
> 5. Waiting for 10 minutes
> 6. CloudStack stops the machine for no reason
> 7. Restart the machine
> In the logs you can find information:
> 2014-02-05 06:27:00,974 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-316:null) 11. The VM i-41-824-VM is in Running state
> 2014-02-05 06:27:00,974 DEBUG [agent.transport.Request]
> (DirectAgent-316:null) Seq 50-1756626952: Processing: { Ans: , MgmtId:
> 160544475005497, via: 50, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.ClusterSyncAnswer":{"_clusterId":2,"_newStates":{"i-41-824-VM":{"t":"f32a4fee-b64e-4868-9c52-2a27e32d4c0e","u":"Running","v":"viridian:true;acpi:true;apic:true;pae:true;nx:false;timeoffset:0;cores-per-socket:4"}},"_isExecuted":false,"result":true,"wait":0}}]
> }
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Sending { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Executing: { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,383 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 9. The VM i-41-824-VM is in Stopping state
> 2014-02-05 06:36:27,625 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 10. The VM i-41-824-VM is in Stopped state
> You will notice that the stop of the machine corresponds to the component
> HA-Worker.
> Such operation after the upgrade is complicating work of users.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6169) assignVirtualMachine leaves associated tags assigned to old account
Marcus Sorensen created CLOUDSTACK-6169: --- Summary: assignVirtualMachine leaves associated tags assigned to old account Key: CLOUDSTACK-6169 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6169 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.2.0, 4.3.0, 4.4.0 Reporter: Marcus Sorensen Fix For: 4.4.0 I'm not 100% sure this is a bug, but it seems so. If you move a virtual machine between accounts via 'assignVirtualMachine', then list the virtual machine, any associated resource tags show the old account/domainid. This is confusing, but could also be a bad information leak -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6036) CloudStack stops the machine for no reason
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomasz Zieba updated CLOUDSTACK-6036:
-
Attachment: management-server.log.2014-02-24.txt
> CloudStack stops the machine for no reason
> ---
>
> Key: CLOUDSTACK-6036
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6036
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.1
> Environment: ACS 4.2.1 after upgrade from 3.0.2
> XCP 1.1
>Reporter: Tomasz Zieba
>Assignee: Koushik Das
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: management-server.log.2014-02-19.gz,
> management-server.log.2014-02-20.gz, management-server.log.2014-02-24.txt
>
>
> After the upgrade from version 3.0.2 to 4.2.1 appeared very strange error
> associated with self-stopping machine after changing the offering.
> Steps to reproduce:
> 1. Running instance of the machine
> 2. Stop with the operating system
> 3. Change offering of machine
> 4. Start the machine
> 5. Waiting for 10 minutes
> 6. CloudStack stops the machine for no reason
> 7. Restart the machine
> In the logs you can find information:
> 2014-02-05 06:27:00,974 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-316:null) 11. The VM i-41-824-VM is in Running state
> 2014-02-05 06:27:00,974 DEBUG [agent.transport.Request]
> (DirectAgent-316:null) Seq 50-1756626952: Processing: { Ans: , MgmtId:
> 160544475005497, via: 50, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.ClusterSyncAnswer":{"_clusterId":2,"_newStates":{"i-41-824-VM":{"t":"f32a4fee-b64e-4868-9c52-2a27e32d4c0e","u":"Running","v":"viridian:true;acpi:true;apic:true;pae:true;nx:false;timeoffset:0;cores-per-socket:4"}},"_isExecuted":false,"result":true,"wait":0}}]
> }
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Sending { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Executing: { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,383 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 9. The VM i-41-824-VM is in Stopping state
> 2014-02-05 06:36:27,625 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 10. The VM i-41-824-VM is in Stopped state
> You will notice that the stop of the machine corresponds to the component
> HA-Worker.
> Such operation after the upgrade is complicating work of users.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6036) CloudStack stops the machine for no reason
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomasz Zieba updated CLOUDSTACK-6036:
-
Environment:
ACS 4.2.1 after upgrade from 3.0.2
ACS 4.2.1 clean install
XCP 1.1
was:
ACS 4.2.1 after upgrade from 3.0.2
XCP 1.1
> CloudStack stops the machine for no reason
> ---
>
> Key: CLOUDSTACK-6036
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6036
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.1
> Environment: ACS 4.2.1 after upgrade from 3.0.2
> ACS 4.2.1 clean install
> XCP 1.1
>Reporter: Tomasz Zieba
>Assignee: Koushik Das
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: management-server.log.2014-02-19.gz,
> management-server.log.2014-02-20.gz, management-server.log.2014-02-24.txt
>
>
> After the upgrade from version 3.0.2 to 4.2.1 appeared very strange error
> associated with self-stopping machine after changing the offering.
> Steps to reproduce:
> 1. Running instance of the machine
> 2. Stop with the operating system
> 3. Change offering of machine
> 4. Start the machine
> 5. Waiting for 10 minutes
> 6. CloudStack stops the machine for no reason
> 7. Restart the machine
> In the logs you can find information:
> 2014-02-05 06:27:00,974 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-316:null) 11. The VM i-41-824-VM is in Running state
> 2014-02-05 06:27:00,974 DEBUG [agent.transport.Request]
> (DirectAgent-316:null) Seq 50-1756626952: Processing: { Ans: , MgmtId:
> 160544475005497, via: 50, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.ClusterSyncAnswer":{"_clusterId":2,"_newStates":{"i-41-824-VM":{"t":"f32a4fee-b64e-4868-9c52-2a27e32d4c0e","u":"Running","v":"viridian:true;acpi:true;apic:true;pae:true;nx:false;timeoffset:0;cores-per-socket:4"}},"_isExecuted":false,"result":true,"wait":0}}]
> }
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Sending { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Executing: { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,383 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 9. The VM i-41-824-VM is in Stopping state
> 2014-02-05 06:36:27,625 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 10. The VM i-41-824-VM is in Stopped state
> You will notice that the stop of the machine corresponds to the component
> HA-Worker.
> Such operation after the upgrade is complicating work of users.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Reopened] (CLOUDSTACK-6036) CloudStack stops the machine for no reason
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomasz Zieba reopened CLOUDSTACK-6036:
--
Steps to reproduce on ASC 4.2.1 (clean install) and on ASC 4.2.1 (upgrade from
3.0.2)
1. Running instance of the machine
1a) create script which delay stopping by 10 minutes
2. Stop VM
You can see in management-server.log.2014-02-24 any details.
Very strange thing is that:
a) when machine stopping process is delay'ed - HA-Worker take very dangerous
process - Stop was unsuccessful. Rescheduling. This is connected with "Unable
to update VM" status in DB.
b) consequently machine is stopped after 10 minutes but HA-Worker has a
rescheduled process of stopping machine.
c) so when you are starting a machine next time - it starts very well - but for
few minutes machine is stopped by reschduled process.
Details in attachement.
> CloudStack stops the machine for no reason
> ---
>
> Key: CLOUDSTACK-6036
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6036
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.1
> Environment: ACS 4.2.1 after upgrade from 3.0.2
> XCP 1.1
>Reporter: Tomasz Zieba
>Assignee: Koushik Das
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: management-server.log.2014-02-19.gz,
> management-server.log.2014-02-20.gz, management-server.log.2014-02-24.txt
>
>
> After the upgrade from version 3.0.2 to 4.2.1 appeared very strange error
> associated with self-stopping machine after changing the offering.
> Steps to reproduce:
> 1. Running instance of the machine
> 2. Stop with the operating system
> 3. Change offering of machine
> 4. Start the machine
> 5. Waiting for 10 minutes
> 6. CloudStack stops the machine for no reason
> 7. Restart the machine
> In the logs you can find information:
> 2014-02-05 06:27:00,974 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-316:null) 11. The VM i-41-824-VM is in Running state
> 2014-02-05 06:27:00,974 DEBUG [agent.transport.Request]
> (DirectAgent-316:null) Seq 50-1756626952: Processing: { Ans: , MgmtId:
> 160544475005497, via: 50, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.ClusterSyncAnswer":{"_clusterId":2,"_newStates":{"i-41-824-VM":{"t":"f32a4fee-b64e-4868-9c52-2a27e32d4c0e","u":"Running","v":"viridian:true;acpi:true;apic:true;pae:true;nx:false;timeoffset:0;cores-per-socket:4"}},"_isExecuted":false,"result":true,"wait":0}}]
> }
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:27:00,981 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (DirectAgent-316:null) VM i-41-824-VM: cs state = Running and realState =
> Running
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Sending { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,240 DEBUG [agent.transport.Request]
> (HA-Worker-1:work-1511) Seq 51-1374970375: Executing: { Cmd , MgmtId:
> 160544475005497, via: 51, Ver: v1, Flags: 100111,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":true,"vmName":"i-41-824-VM","wait":0}}]
> }
> 2014-02-05 06:36:01,383 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 9. The VM i-41-824-VM is in Stopping state
> 2014-02-05 06:36:27,625 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-150:null) 10. The VM i-41-824-VM is in Stopped state
> You will notice that the stop of the machine corresponds to the component
> HA-Worker.
> Such operation after the upgrade is complicating work of users.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5663) API:MS: Network with NULL CIDR raises NPE for createNetwork and listNetwork
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk updated CLOUDSTACK-5663: -- Assignee: Saurav Lahiri > API:MS: Network with NULL CIDR raises NPE for createNetwork and listNetwork > --- > > Key: CLOUDSTACK-5663 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5663 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server >Affects Versions: 4.2.0 > Environment: NA >Reporter: Parth Jagirdar >Assignee: Saurav Lahiri >Priority: Critical > > A Zone creation without CIDR is allowed for Shared networks. > And CIDR is not a required param for Create Network API. > In such a case listNetworks and createNetworks will raise NPE. > ERROR [cloud.api.ApiServer] (catalina-exec-13:null) unhandled exception > executing api command: listNetworks > java.lang.NullPointerException > at > com.cloud.network.NetworkModelImpl.getAvailableIps(NetworkModelImpl.java:1694) > at > com.cloud.network.NetworkModelImpl.canUseForDeploy(NetworkModelImpl.java:585) > at com.cloud.api.ApiDBUtils.canUseForDeploy(ApiDBUtils.java:1147) > at > com.cloud.api.ApiResponseHelper.createNetworkResponse(ApiResponseHelper.java:2259) > at > org.apache.cloudstack.api.command.user.network.ListNetworksCmd.execute(ListNetworksCmd.java:157) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:514) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:372) > at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:305) > at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) > at > org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889) > at > org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721) > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:724) > 2013-12-26 14:50:05,336 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null) > ===END=== 10.215.2.19 -- GET > command=listNetworks&response=json&sessionkey=umV%2F%2Fe90IumPgdOknf1aBRF0kLE%3D&listAll=true&page=1&pagesize=20&_=1388098205177 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-6170) Support managed storage for root disks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Tutkowski reassigned CLOUDSTACK-6170: -- Assignee: Mike Tutkowski > Support managed storage for root disks > -- > > Key: CLOUDSTACK-6170 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6170 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.4.0 > Environment: I expect to support managed storage for root disks on > XenServer and ESX (KVM is targeted for 4.5). >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski > Fix For: 4.4.0 > > > Cloud environments have a need for guaranteed storage performance. By this I > mean having the ability to specify a minimum and maximum number of IOPS on a > volume-by-volume basis. > I added support for this for XenServer and ESX in 4.2 for data disks. > I added support for this for KVM in 4.3 for data disks. > It is my intent to add support for this for XenServer and ESX in 4.4 for root > disks (with subsequent support for root disks on KVM expected in 4.5). > This will require minor changes in the SolidFire (storage) plug-in. > The main changes are expected to occur in CloudStack logic that controls > hypervisors and additions to the way root-volume orchestration happens. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6170) Support managed storage for root disks
Mike Tutkowski created CLOUDSTACK-6170: -- Summary: Support managed storage for root disks Key: CLOUDSTACK-6170 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6170 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Environment: I expect to support managed storage for root disks on XenServer and ESX (KVM is targeted for 4.5). Reporter: Mike Tutkowski Fix For: 4.4.0 Cloud environments have a need for guaranteed storage performance. By this I mean having the ability to specify a minimum and maximum number of IOPS on a volume-by-volume basis. I added support for this for XenServer and ESX in 4.2 for data disks. I added support for this for KVM in 4.3 for data disks. It is my intent to add support for this for XenServer and ESX in 4.4 for root disks (with subsequent support for root disks on KVM expected in 4.5). This will require minor changes in the SolidFire (storage) plug-in. The main changes are expected to occur in CloudStack logic that controls hypervisors and additions to the way root-volume orchestration happens. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6170) Support managed storage for root disks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Tutkowski updated CLOUDSTACK-6170: --- Description: Cloud environments have a need for guaranteed storage performance. By this I mean having the ability to specify a minimum and maximum number of IOPS on a volume-by-volume basis. I added support for this for XenServer and ESX in 4.2 for data disks. I added support for this for KVM in 4.3 for data disks. It is my intent to add support for this for XenServer and ESX in 4.4 for root disks (with subsequent support for root disks on KVM expected in 4.5). The main changes are expected to occur in CloudStack logic that controls hypervisors and additions to the way root-volume orchestration happens. This will also require minor changes in the SolidFire (storage) plug-in. was: Cloud environments have a need for guaranteed storage performance. By this I mean having the ability to specify a minimum and maximum number of IOPS on a volume-by-volume basis. I added support for this for XenServer and ESX in 4.2 for data disks. I added support for this for KVM in 4.3 for data disks. It is my intent to add support for this for XenServer and ESX in 4.4 for root disks (with subsequent support for root disks on KVM expected in 4.5). This will require minor changes in the SolidFire (storage) plug-in. The main changes are expected to occur in CloudStack logic that controls hypervisors and additions to the way root-volume orchestration happens. > Support managed storage for root disks > -- > > Key: CLOUDSTACK-6170 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6170 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.4.0 > Environment: I expect to support managed storage for root disks on > XenServer and ESX (KVM is targeted for 4.5). >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski > Fix For: 4.4.0 > > > Cloud environments have a need for guaranteed storage performance. By this I > mean having the ability to specify a minimum and maximum number of IOPS on a > volume-by-volume basis. > I added support for this for XenServer and ESX in 4.2 for data disks. > I added support for this for KVM in 4.3 for data disks. > It is my intent to add support for this for XenServer and ESX in 4.4 for root > disks (with subsequent support for root disks on KVM expected in 4.5). > The main changes are expected to occur in CloudStack logic that controls > hypervisors and additions to the way root-volume orchestration happens. > This will also require minor changes in the SolidFire (storage) plug-in. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-6157) devcloud setup db functionality broken by mysql dependency cleanup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Kinsella closed CLOUDSTACK-6157. - > devcloud setup db functionality broken by mysql dependency cleanup > -- > > Key: CLOUDSTACK-6157 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6157 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: DevCloud >Reporter: John Kinsella >Priority: Blocker > Fix For: 4.3.0 > > > With the removal of mysql compile-time dependencies, maven is no longer able > to manipulate the devcloud database without developer supplying the mysql > JDBC connector and configuring classpath appropriately. > Need to either update documentation, or come up with a legally acceptable > technical solution. > Expected result: > Successfully deployed devcloud db > Actual result: > mvn -P developer -pl developer,tools/devcloud -Ddeploydb > ... > > Running query: drop database if exists `cloud` > SQL exception in trying initDB: java.sql.SQLException: No suitable driver > found for jdbc:mysql://localhost:3306/ -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-6157) devcloud setup db functionality broken by mysql dependency cleanup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Kinsella resolved CLOUDSTACK-6157. --- Resolution: Fixed Hugo fixed this in the following commits on master: e883877c7a6f9df04b572afd4ee5f10d265bcc3a afc188cb5c72e316975799c95529e8692ddcb94b > devcloud setup db functionality broken by mysql dependency cleanup > -- > > Key: CLOUDSTACK-6157 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6157 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: DevCloud >Reporter: John Kinsella >Priority: Blocker > Fix For: 4.3.0 > > > With the removal of mysql compile-time dependencies, maven is no longer able > to manipulate the devcloud database without developer supplying the mysql > JDBC connector and configuring classpath appropriately. > Need to either update documentation, or come up with a legally acceptable > technical solution. > Expected result: > Successfully deployed devcloud db > Actual result: > mvn -P developer -pl developer,tools/devcloud -Ddeploydb > ... > > Running query: drop database if exists `cloud` > SQL exception in trying initDB: java.sql.SQLException: No suitable driver > found for jdbc:mysql://localhost:3306/ -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6162) support OVS as connectivity service provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13911997#comment-13911997 ] ASF subversion and git services commented on CLOUDSTACK-6162: - Commit 80738cce053871d078c12e758eda7f1418bbfd8a in cloudstack's branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=80738cc ] BUG-ID: CLOUDSTACK-6162: UI > zone > physical network > service provider > add OVS. Reviewed-by: Brian > support OVS as connectivity service provider > > > Key: CLOUDSTACK-6162 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6162 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: 4.3.0 > > > Below UI changes are needed to enable OVS as connectivity provider while > creating network offering. > Below changes are required: > 1) In the drop down box for 'Connectivity' service provider in the network > offering dialog box, expose Ovs as provider. And corresponding API call would > be: > http://192.168.20.112:8080/client/api?command=createNetworkOffering&sessionkey=0YutiBb19VkXgepJYf/wq2Wii4Q=&name=ovs-connectivity-offering&displayText=ovs-connectivity-offering&guestIpType=Isolated&lbType=publicLb&servicecapabilitylist[0].service=SourceNat&servicecapabilitylist[0].capabilitytype=SupportedSourceNatTypes&servicecapabilitylist[0].capabilityvalue=peraccount&servicecapabilitylist[1].service=lb&servicecapabilitylist[1].capabilitytype=SupportedLbIsolation&servicecapabilitylist[1].capabilityvalue=dedicated&availability=Optional&egresspolicy=ALLOW&state=Creating&status=Creating&allocationstate=Creating&supportedServices=Dhcp,Dns,Firewall,Lb,SourceNat,StaticNat,PortForwarding,Connectivity&specifyIpRanges=false&specifyVlan=false&isPersistent=false&conservemode=false&serviceProviderList[0].service=Dhcp&serviceProviderList[0].provider=VirtualRouter&serviceProviderList[1].service=Dns&serviceProviderList[1].provider=VirtualRouter&serviceProviderList[2].service=Firewall&serviceProviderList[2].provider=VirtualRouter&serviceProviderList[3].service=Lb&serviceProviderList[3].provider=VirtualRouter&serviceProviderList[4].service=SourceNat&serviceProviderList[4].provider=VirtualRouter&serviceProviderList[5].service=StaticNat&serviceProviderList[5].provider=VirtualRouter&serviceProviderList[6].service=PortForwarding&serviceProviderList[6].provider=VirtualRouter&serviceProviderList[7].service=Connectivity&serviceProviderList[7].provider=Ovs&egressdefaultpolicy=true&traffictype=GUEST > Notice > 'serviceProviderList[7].service=Connectivity&serviceProviderList[7].provider=Ovs&' > in the api fired. > 2) in the list of network service providers on a physical network display OVS > 3) enable OVS provider -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6162) support OVS as connectivity service provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13912001#comment-13912001 ] Jessica Wang commented on CLOUDSTACK-6162: -- commit 962bdda522fca400b55f9a6191ae2bebb86caaf5 Author: Jessica Wang Date: Tue Feb 25 12:05:55 2014 -0800 BUG-ID: CLOUDSTACK-6162: UI > zone > physical network > service provider > a Reviewed-by: Brian branch: ccp-4.3 > support OVS as connectivity service provider > > > Key: CLOUDSTACK-6162 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6162 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: 4.3.0 > > > Below UI changes are needed to enable OVS as connectivity provider while > creating network offering. > Below changes are required: > 1) In the drop down box for 'Connectivity' service provider in the network > offering dialog box, expose Ovs as provider. And corresponding API call would > be: > http://192.168.20.112:8080/client/api?command=createNetworkOffering&sessionkey=0YutiBb19VkXgepJYf/wq2Wii4Q=&name=ovs-connectivity-offering&displayText=ovs-connectivity-offering&guestIpType=Isolated&lbType=publicLb&servicecapabilitylist[0].service=SourceNat&servicecapabilitylist[0].capabilitytype=SupportedSourceNatTypes&servicecapabilitylist[0].capabilityvalue=peraccount&servicecapabilitylist[1].service=lb&servicecapabilitylist[1].capabilitytype=SupportedLbIsolation&servicecapabilitylist[1].capabilityvalue=dedicated&availability=Optional&egresspolicy=ALLOW&state=Creating&status=Creating&allocationstate=Creating&supportedServices=Dhcp,Dns,Firewall,Lb,SourceNat,StaticNat,PortForwarding,Connectivity&specifyIpRanges=false&specifyVlan=false&isPersistent=false&conservemode=false&serviceProviderList[0].service=Dhcp&serviceProviderList[0].provider=VirtualRouter&serviceProviderList[1].service=Dns&serviceProviderList[1].provider=VirtualRouter&serviceProviderList[2].service=Firewall&serviceProviderList[2].provider=VirtualRouter&serviceProviderList[3].service=Lb&serviceProviderList[3].provider=VirtualRouter&serviceProviderList[4].service=SourceNat&serviceProviderList[4].provider=VirtualRouter&serviceProviderList[5].service=StaticNat&serviceProviderList[5].provider=VirtualRouter&serviceProviderList[6].service=PortForwarding&serviceProviderList[6].provider=VirtualRouter&serviceProviderList[7].service=Connectivity&serviceProviderList[7].provider=Ovs&egressdefaultpolicy=true&traffictype=GUEST > Notice > 'serviceProviderList[7].service=Connectivity&serviceProviderList[7].provider=Ovs&' > in the api fired. > 2) in the list of network service providers on a physical network display OVS > 3) enable OVS provider -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6162) support OVS as connectivity service provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-6162: - Attachment: jessica-2014-02-25.PNG > support OVS as connectivity service provider > > > Key: CLOUDSTACK-6162 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6162 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: 4.3.0 > > Attachments: jessica-2014-02-25.PNG > > > Below UI changes are needed to enable OVS as connectivity provider while > creating network offering. > Below changes are required: > 1) In the drop down box for 'Connectivity' service provider in the network > offering dialog box, expose Ovs as provider. And corresponding API call would > be: > http://192.168.20.112:8080/client/api?command=createNetworkOffering&sessionkey=0YutiBb19VkXgepJYf/wq2Wii4Q=&name=ovs-connectivity-offering&displayText=ovs-connectivity-offering&guestIpType=Isolated&lbType=publicLb&servicecapabilitylist[0].service=SourceNat&servicecapabilitylist[0].capabilitytype=SupportedSourceNatTypes&servicecapabilitylist[0].capabilityvalue=peraccount&servicecapabilitylist[1].service=lb&servicecapabilitylist[1].capabilitytype=SupportedLbIsolation&servicecapabilitylist[1].capabilityvalue=dedicated&availability=Optional&egresspolicy=ALLOW&state=Creating&status=Creating&allocationstate=Creating&supportedServices=Dhcp,Dns,Firewall,Lb,SourceNat,StaticNat,PortForwarding,Connectivity&specifyIpRanges=false&specifyVlan=false&isPersistent=false&conservemode=false&serviceProviderList[0].service=Dhcp&serviceProviderList[0].provider=VirtualRouter&serviceProviderList[1].service=Dns&serviceProviderList[1].provider=VirtualRouter&serviceProviderList[2].service=Firewall&serviceProviderList[2].provider=VirtualRouter&serviceProviderList[3].service=Lb&serviceProviderList[3].provider=VirtualRouter&serviceProviderList[4].service=SourceNat&serviceProviderList[4].provider=VirtualRouter&serviceProviderList[5].service=StaticNat&serviceProviderList[5].provider=VirtualRouter&serviceProviderList[6].service=PortForwarding&serviceProviderList[6].provider=VirtualRouter&serviceProviderList[7].service=Connectivity&serviceProviderList[7].provider=Ovs&egressdefaultpolicy=true&traffictype=GUEST > Notice > 'serviceProviderList[7].service=Connectivity&serviceProviderList[7].provider=Ovs&' > in the api fired. > 2) in the list of network service providers on a physical network display OVS > 3) enable OVS provider -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6162) support OVS as connectivity service provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-6162: - Attachment: jessica-2014-02-25B.PNG > support OVS as connectivity service provider > > > Key: CLOUDSTACK-6162 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6162 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: 4.3.0 > > Attachments: jessica-2014-02-25.PNG, jessica-2014-02-25B.PNG > > > Below UI changes are needed to enable OVS as connectivity provider while > creating network offering. > Below changes are required: > 1) In the drop down box for 'Connectivity' service provider in the network > offering dialog box, expose Ovs as provider. And corresponding API call would > be: > http://192.168.20.112:8080/client/api?command=createNetworkOffering&sessionkey=0YutiBb19VkXgepJYf/wq2Wii4Q=&name=ovs-connectivity-offering&displayText=ovs-connectivity-offering&guestIpType=Isolated&lbType=publicLb&servicecapabilitylist[0].service=SourceNat&servicecapabilitylist[0].capabilitytype=SupportedSourceNatTypes&servicecapabilitylist[0].capabilityvalue=peraccount&servicecapabilitylist[1].service=lb&servicecapabilitylist[1].capabilitytype=SupportedLbIsolation&servicecapabilitylist[1].capabilityvalue=dedicated&availability=Optional&egresspolicy=ALLOW&state=Creating&status=Creating&allocationstate=Creating&supportedServices=Dhcp,Dns,Firewall,Lb,SourceNat,StaticNat,PortForwarding,Connectivity&specifyIpRanges=false&specifyVlan=false&isPersistent=false&conservemode=false&serviceProviderList[0].service=Dhcp&serviceProviderList[0].provider=VirtualRouter&serviceProviderList[1].service=Dns&serviceProviderList[1].provider=VirtualRouter&serviceProviderList[2].service=Firewall&serviceProviderList[2].provider=VirtualRouter&serviceProviderList[3].service=Lb&serviceProviderList[3].provider=VirtualRouter&serviceProviderList[4].service=SourceNat&serviceProviderList[4].provider=VirtualRouter&serviceProviderList[5].service=StaticNat&serviceProviderList[5].provider=VirtualRouter&serviceProviderList[6].service=PortForwarding&serviceProviderList[6].provider=VirtualRouter&serviceProviderList[7].service=Connectivity&serviceProviderList[7].provider=Ovs&egressdefaultpolicy=true&traffictype=GUEST > Notice > 'serviceProviderList[7].service=Connectivity&serviceProviderList[7].provider=Ovs&' > in the api fired. > 2) in the list of network service providers on a physical network display OVS > 3) enable OVS provider -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6162) support OVS as connectivity service provider
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13912017#comment-13912017
]
Jessica Wang commented on CLOUDSTACK-6162:
--
Murali,
I've checked in UI change for 2) and 3).
(as in my attachment "jessica-2014-02-25")
However, I'm unable to test it because of lack of your server-side change (i.e.
listNetworkServiceProviders API to return "OVS" provider.). As you can see in
my attachment "jessica_2014-02-25B", detail view of OVS is empty because API
doesn't return anything:
http://10.215.3.26:8080/client/api?command=listNetworkServiceProviders&physicalnetworkid=cead3415-8350-4f0f-a94b-4db5a60a9909&name=OVS&response=json&sessionkey=XhIpbU2eaiC47iml%2BHCTmZJA9vg%3D&_=1393360114012
{
"listnetworkserviceprovidersresponse": {}
}
Jessica
> support OVS as connectivity service provider
>
>
> Key: CLOUDSTACK-6162
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6162
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.3.0
>Reporter: Murali Reddy
>Assignee: Murali Reddy
> Fix For: 4.3.0
>
> Attachments: jessica-2014-02-25.PNG, jessica-2014-02-25B.PNG
>
>
> Below UI changes are needed to enable OVS as connectivity provider while
> creating network offering.
> Below changes are required:
> 1) In the drop down box for 'Connectivity' service provider in the network
> offering dialog box, expose Ovs as provider. And corresponding API call would
> be:
> http://192.168.20.112:8080/client/api?command=createNetworkOffering&sessionkey=0YutiBb19VkXgepJYf/wq2Wii4Q=&name=ovs-connectivity-offering&displayText=ovs-connectivity-offering&guestIpType=Isolated&lbType=publicLb&servicecapabilitylist[0].service=SourceNat&servicecapabilitylist[0].capabilitytype=SupportedSourceNatTypes&servicecapabilitylist[0].capabilityvalue=peraccount&servicecapabilitylist[1].service=lb&servicecapabilitylist[1].capabilitytype=SupportedLbIsolation&servicecapabilitylist[1].capabilityvalue=dedicated&availability=Optional&egresspolicy=ALLOW&state=Creating&status=Creating&allocationstate=Creating&supportedServices=Dhcp,Dns,Firewall,Lb,SourceNat,StaticNat,PortForwarding,Connectivity&specifyIpRanges=false&specifyVlan=false&isPersistent=false&conservemode=false&serviceProviderList[0].service=Dhcp&serviceProviderList[0].provider=VirtualRouter&serviceProviderList[1].service=Dns&serviceProviderList[1].provider=VirtualRouter&serviceProviderList[2].service=Firewall&serviceProviderList[2].provider=VirtualRouter&serviceProviderList[3].service=Lb&serviceProviderList[3].provider=VirtualRouter&serviceProviderList[4].service=SourceNat&serviceProviderList[4].provider=VirtualRouter&serviceProviderList[5].service=StaticNat&serviceProviderList[5].provider=VirtualRouter&serviceProviderList[6].service=PortForwarding&serviceProviderList[6].provider=VirtualRouter&serviceProviderList[7].service=Connectivity&serviceProviderList[7].provider=Ovs&egressdefaultpolicy=true&traffictype=GUEST
> Notice
> 'serviceProviderList[7].service=Connectivity&serviceProviderList[7].provider=Ovs&'
> in the api fired.
> 2) in the list of network service providers on a physical network display OVS
> 3) enable OVS provider
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6156) Retired maven repo breaking awsapi build and RPM packaging
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Nalley updated CLOUDSTACK-6156: - Priority: Blocker (was: Critical) > Retired maven repo breaking awsapi build and RPM packaging > -- > > Key: CLOUDSTACK-6156 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6156 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: AWSAPI >Affects Versions: 4.2.0, 4.3.0 >Reporter: John Kinsella >Assignee: John Kinsella >Priority: Blocker > > The awsapi sub-project depends on several jars from Apache Axis-Rampart. > The Rampart poms have a broken maven repo hard-coded into them: > http://shibboleth.internet2.edu/downloads/maven2/ > Which does not return a 404 when maven attempts to fetch a jar, but HTTP 200. > *golf clap* > Rampart is aware of this (see RAMPART-393) but the fix won't be released > until version 1.7, whenever that is. > CLOUDSTACK-744 shows we hit this before for opensaml, although I'm not sure > when the rampart jars started erroring out. > From my research so far, looks like rampart isn't being used and the rampart > dependencies can be removed from the pom... > Steps to reproduce (On a clean system with no cached maven repo, and not > using a maven repo mirror): > mvn -P awsapi > Expected results: > Happily built awsapi package > Actual results: > ... > Downloaded: > http://repo.maven.apache.org/maven2/org/apache/rampart/rampart-policy/1.5.1/rampart-policy-1.5.1.pom > (3 KB at 116.1 KB/sec) > Downloading: > http://shibboleth.internet2.edu/downloads/maven2/org/apache/rampart/rampart-policy/1.5.1/rampart-policy-1.5.1.pom > Feb 21, 2014 12:18:31 PM > org.apache.maven.wagon.providers.http.httpclient.client.protocol.ResponseProcessCookies > processCookies > WARNING: Invalid cookie header: "Set-Cookie: django_language=en-us; > expires=time.struct_time(tm_year=2015, tm_mon=2, tm_mday=21, tm_hour=15, > tm_min=18, tm_sec=33, tm_wday=5, tm_yday=52, tm_isdst=0); Max-Age=31536000; > Path=/". Unable to parse expires attribute: time.struct_time(tm_year=2015, > tm_mon=2, tm_mday=21, tm_hour=15, tm_min=18, tm_sec=33, tm_wday=5, > tm_yday=52, tm_isdst=0) > Feb 21, 2014 12:18:32 PM > org.apache.maven.wagon.providers.http.httpclient.client.protocol.ResponseProcessCookies > processCookies > WARNING: Invalid cookie header: "Set-Cookie: django_language=en-us; > expires=time.struct_time(tm_year=2015, tm_mon=2, tm_mday=21, tm_hour=15, > tm_min=18, tm_sec=33, tm_wday=5, tm_yday=52, tm_isdst=0); Max-Age=31536000; > Path=/". Unable to parse expires attribute: time.struct_time(tm_year=2015, > tm_mon=2, tm_mday=21, tm_hour=15, tm_min=18, tm_sec=33, tm_wday=5, > tm_yday=52, tm_isdst=0) > Feb 21, 2014 12:18:32 PM > org.apache.maven.wagon.providers.http.httpclient.client.protocol.ResponseProcessCookies > processCookies > ... > [WARNING] Invalid POM for org.apache.rampart:rampart-policy:jar:1.5.1, > transitive dependencies (if any) will not be available, enable debug logging > for more details > etc, etc -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-6015) Write Sellenium tests for the UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yichi Lu reassigned CLOUDSTACK-6015: Assignee: Yichi Lu > Write Sellenium tests for the UI > > > Key: CLOUDSTACK-6015 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6015 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.4.0 >Reporter: sebastien goasguen >Assignee: Yichi Lu > Labels: gsoc2014 > > To increase tests coverage for CloudStack we need to write a test suite for > the UI. Using Sellenium we can write these tests for multiple browsers and > export everything in Python. > http://docs.seleniumhq.org > These will be used with the unittest and the integration tests to make > CloudStack higher quality. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-2697) cluster id in alert message is null {alertType:: 1 // dataCenterId:: 1 // podId:: 1 // clusterId:: null }
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Girish Chaudhari reassigned CLOUDSTACK-2697:
Assignee: Girish Chaudhari
> cluster id in alert message is null {alertType:: 1 // dataCenterId:: 1 //
> podId:: 1 // clusterId:: null }
> -
>
> Key: CLOUDSTACK-2697
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2697
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
>Reporter: prashant kumar mishra
>Assignee: Girish Chaudhari
>Priority: Minor
> Fix For: 4.3.0
>
> Attachments: logs.rar
>
>
> Cluster id should not be null in Alert message.
> Snippet of log
>
> 2013-05-27 13:13:19,879 WARN [apache.cloudstack.alerts]
> (CapacityChecker:null) alertType:: 1 // dataCenterId:: 1 // podId:: 1 //
> clusterId:: null // message:: System Alert: Low Unallocated CPU in cluster
> cluster pod pod of availability zone pod
> 2013-05-27 13:13:19,890 DEBUG [cloud.alert.AlertManagerImpl]
> (CapacityChecker:null) Have already sent: 1 emails for alert type '1' --
> skipping send email
> 2013-05-27 13:13:19,954 DEBUG [cloud.alert.AlertManagerImpl]
> (CapacityChecker:null) System Alert: Low Unallocated CPU in cluster cluster2
> pod pod of availability zone pod
> 2013-05-27 13:13:19,954 DEBUG [cloud.alert.AlertManagerImpl]
> (CapacityChecker:null) Unallocated CPU is low, total: 9576 Mhz, used: 2000
> Mhz (20.89%)
> 2013-05-27 13:13:19,955 WARN [apache.cloudstack.alerts]
> (CapacityChecker:null) alertType:: 1 // dataCenterId:: 1 // podId:: 1 //
> clusterId:: null // message:: System Alert: Low Unallocated CPU in cluster
> cluster2 pod pod of availability zone pod
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5674) [Automation]: Enhancements to accommodate multiple regression runs on a single CS server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13912526#comment-13912526 ] ASF subversion and git services commented on CLOUDSTACK-5674: - Commit 23e059b1b903bff84155a116432ef02bfd078d9d in cloudstack's branch refs/heads/marvin from [~santhoshe] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=23e059b ] CLOUDSTACK-5674: Added few changes for CLOUDSTACK-567 > [Automation]: Enhancements to accommodate multiple regression runs on a > single CS server > > > Key: CLOUDSTACK-5674 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5674 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, marvin >Reporter: Santhosh Kumar Edukulla >Assignee: Santhosh Kumar Edukulla > > 1. Currently, we will not be able to run multiple regression runs on a given > CS server either sequentially\parallelly reason being few hard codings done > at various places. > 2. So, the idea is to run complete regression\automation test suites at one > stretch on a given setup post deployDC. We deploy multiple zones with > different hypervisor type in each zone. > 3. Tests should cut down time and run across multiple zones with different > hypervisor type in each zone, post deployment > 3. The fixes and new changes should incorporate to take care to run suites > parallelly if we wanted or sequentially for various test suites like > vmware,xen,kvm etc on single CS machine without disturbing\redeploying and > installing the new CS instance. > Phase1: We will make framework\marvin changes. > Phase2: Incorporate test module changes for these. > Adding this ticket to track these changes. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-567) Integration Test: Test for Copy Zone has hardcoded destination id
[ https://issues.apache.org/jira/browse/CLOUDSTACK-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13912527#comment-13912527 ] ASF subversion and git services commented on CLOUDSTACK-567: Commit 23e059b1b903bff84155a116432ef02bfd078d9d in cloudstack's branch refs/heads/marvin from [~santhoshe] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=23e059b ] CLOUDSTACK-5674: Added few changes for CLOUDSTACK-567 > Integration Test: Test for Copy Zone has hardcoded destination id > - > > Key: CLOUDSTACK-567 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-567 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Test >Affects Versions: 4.0.0 >Reporter: Prasanna Santhanam >Assignee: Prasanna Santhanam > > The smoke and integration tests for copying image (template/iso) between > zones assumes the destination id is always 2 which is incorrect since all > entities are now based on uuid. Furthermore the listTemplates response needs > to resolve the template to be in READY state to ensure that the image was > copied over successfully. > Here's the review request that corrects this: > https://reviews.apache.org/r/8082/ -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6171) Cloudstack:KVM:: Snapshot stuck in Creating Status forever.
Rohit Kumar created CLOUDSTACK-6171:
---
Summary: Cloudstack:KVM:: Snapshot stuck in Creating Status
forever.
Key: CLOUDSTACK-6171
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6171
Project: CloudStack
Issue Type: Task
Security Level: Public (Anyone can view this level - this is the default.)
Components: Infra, Install and Setup, KVM, Management Server
Affects Versions: 4.2.0, 4.2.1
Environment: RHEL 6.4
Reporter: Rohit Kumar
Priority: Blocker
Hi,
I am working on CloudStack infrastructure service to build our organization
framework.
For this purpose, RHEL 6.4, Cloudstack 4.2.1 and KVM are being used.
I have been working around for long to figure out the below mentioned Issue but
unfortunately could not.
Issue: Snapshot gets stuck in the state "Creating" forever.
Impact: Couldn't get the snapshot consequently and thus, the instance from the
CloudStack's UI could not be started/Stopped.
Please see below trace from Management Server log which I think is the reason
behind this.
me":"ROOT-13","path":"ec5692cb-7758-4618-b589-09cb71e45dba","size":21474836480,"type":"ROOT","storagePoolType":"NetworkFilesystem","storagePoolUuid":"d41d4103-a11d-3160-8a3b-6469c574a93f","deviceId":0},{"id":19,"name":"DATA-13","path":"8017ac65-b52b-450b-937f-d92178de2f34","size":21474836480,"type":"DATADISK","storagePoolType":"NetworkFilesystem","storagePoolUuid":"d41d4103-a11d-3160-8a3b-6469c574a93f","deviceId":1}],"target":{"id":13,"snapshotName":"i-2-13-VM_VS_20140225120244","type":"Disk","current":false,"description":"new"},"vmName":"i-2-13-VM","guestOSType":"Red
Hat Enterprise Linux 6.4 (64-bit)","wait":1800}}] }
2014-02-25 17:32:45,254 DEBUG [agent.transport.Request]
(AgentManager-Handler-11:null) Seq 1-2016739514: Processing: { Ans: , MgmtId:
181122461670954, via: 1, Ver: v1, Flags: 10,
[{"com.cloud.agent.api.UnsupportedAnswer":{"result":false,"details":"Unsupported
command issued:com.cloud.agent.api.CreateVMSnapshotCommand. Are you sure you
got the right type of server?","wait":0}}] }
2014-02-25 17:32:45,254 DEBUG [agent.transport.Request] (Job-Executor-2:job-143
= [ 8ebc7ede-829d-473b-b909-a397f4c83490 ]) Seq 1-2016739514: Received: { Ans:
, MgmtId: 181122461670954, via: 1, Ver: v1, Flags: 10, { UnsupportedAnswer } }
2014-02-25 17:32:45,254 WARN [agent.manager.AgentManagerImpl]
(Job-Executor-2:job-143 = [ 8ebc7ede-829d-473b-b909-a397f4c83490 ]) Unsupported
Command: Unsupported command
issued:com.cloud.agent.api.CreateVMSnapshotCommand. Are you sure you got the
right type of server?
2014-02-25 17:32:45,254 ERROR [vm.snapshot.VMSnapshotManagerImpl]
(Job-Executor-2:job-143 = [ 8ebc7ede-829d-473b-b909-a397f4c83490 ]) Create vm
snapshot i-2-13-VM_VS_20140225120244 failed for vm: i-2-13-VM due to
com.cloud.agent.api.UnsupportedAnswer cannot be cast to
com.cloud.agent.api.CreateVMSnapshotAnswer
2014-02-25 17:32:45,265 DEBUG [cloud.api.ApiServlet] (catalina-exec-11:null)
===START=== 192.168.125.241 -- GET
command=listOsTypes&response=json&sessionkey=bP1MluiO7KMYb3krOwtD1IpG0b0%3D&_=1393329472271
2014-02-25 17:32:45,324 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null)
===START=== 192.168.125.241 -- GET
command=listTags&response=json&sessionkey=bP1MluiO7KMYb3krOwtD1IpG0b0%3D&resourceId=340c69ae-f3a0-4966-aa0b-c799e944404f&resourceType=UserVm&listAll=true&_=1393329472305
2014-02-25 17:32:45,330 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null)
===END=== 192.168.125.241 -- GET
command=listTags&response=json&sessionkey=bP1MluiO7KMYb3krOwtD1IpG0b0%3D&resourceId=340c69ae-f3a0-4966-aa0b-c799e944404f&resourceType=UserVm&listAll=true&_=1393329472305
2014-02-25 17:32:45,373 DEBUG [cloud.api.ApiServlet] (catalina-exec-11:null)
===END=== 192.168.125.241 -- GET
command=listOsTypes&response=json&sessionkey=bP1MluiO7KMYb3krOwtD1IpG0b0%3D&_=1393329472271
2014-02-25 17:32:45,419 ERROR [cloud.async.AsyncJobManagerImpl]
(Job-Executor-2:job-143 = [ 8ebc7ede-829d-473b-b909-a397f4c83490 ]) Unexpected
exception while executing
org.apache.cloudstack.api.command.user.vmsnapshot.CreateVMSnapshotCmd
com.cloud.utils.exception.CloudRuntimeException:
com.cloud.agent.api.UnsupportedAnswer cannot be cast to
com.cloud.agent.api.CreateVMSnapshotAnswer
at
com.cloud.vm.snapshot.VMSnapshotManagerImpl.createVmSnapshotInternal(VMSnapshotManagerImpl.java:406)
at
com.cloud.vm.snapshot.VMSnapshotManagerImpl.creatVMSnapshot(VMSnapshotManagerImpl.java:356)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
org.apache.cloudstack.api.command.user.vmsnapshot.CreateVMSnapshotCmd.execute(CreateVMSnapshotCmd.java:100)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
at
com.cloud.async.AsyncJobManag
[jira] [Closed] (CLOUDSTACK-5647) Adding F5 device to network service provider fails with NoClassDefFoundError
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanjeev N closed CLOUDSTACK-5647.
-
Works fine with the fix.
> Adding F5 device to network service provider fails with NoClassDefFoundError
>
>
> Key: CLOUDSTACK-5647
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5647
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller, Network Devices
>Affects Versions: 4.3.0
> Environment: Latest build from 4.3 with commit :
> 4b2b6544255ee7fe12b4b4732cacd08e4ee6a1b7
> Network: Advanced
>Reporter: Sanjeev N
>Assignee: Murali Reddy
>Priority: Blocker
> Fix For: 4.3.0
>
> Attachments: management-server.rar
>
>
> [Hyper-v] Adding F5 device to network service providers fails with
> NoClassDefFoundError
> Steps to Reproduce:
> =
> 1.Bring up CS in advanced zone with Hyper-v cluster
> 2.Go to Home->Infrastructure->Zones->Adv->Physical Network 1->Network Service
> Providers from UI
> 3.Try to add F5 device
> Result:
> ==
> Adding F5 device fails with following error:
> 2013-12-26 12:08:02,144 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-24:ctx-7a6a5fed) ===START=== 10.146.0.134 -- POST
> command=addF5LoadBalancer&physicalnetworkid=9dbdb202-2f29-4d93-be19-20e70c4eb085&username=admin&networkdevicetype=F5BigIpLoadBalancer&url=https%3A%2F%2F10.147.40.192%3Fpublicinterface%3D1.1%26privateinterface%3D1.2%26numretries%3D2%26lbdevicededicated%3Dfalse&response=json&sessionkey=wNiOWZzu7DZ8g1onQ0P8HZkTmtw%3D
> 2013-12-26 12:08:02,401 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-24:ctx-7a6a5fed ctx-2d9e9f38) submit async job-59, details:
> AsyncJobVO {id:59, userId: 2, accountId: 2, instanceType: None, instanceId:
> null, cmd: com.cloud.api.commands.AddF5LoadBalancerCmd, cmdInfo:
> {"physicalnetworkid":"9dbdb202-2f29-4d93-be19-20e70c4eb085","response":"json","sessionkey":"wNiOWZzu7DZ8g1onQ0P8HZkTmtw\u003d","username":"admin","cmdEventType":"PHYSICAL.LOADBALANCER.ADD","ctxUserId":"2","networkdevicetype":"F5BigIpLoadBalancer","httpmethod":"POST","ctxAccountId":"2","ctxStartEventId":"190","password":"password","url":"https://10.147.40.192?publicinterface\u003d1.1\u0026privateinterface\u003d1.2\u0026numretries\u003d2\u0026lbdevicededicated\u003dfalse"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 132129494109518, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2013-12-26 12:08:02,402 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (Job-Executor-53:ctx-f2fca977) Add job-59 into job monitoring
> 2013-12-26 12:08:02,403 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (Job-Executor-53:ctx-f2fca977) Executing AsyncJobVO {id:59, userId: 2,
> accountId: 2, instanceType: None, instanceId: null, cmd:
> com.cloud.api.commands.AddF5LoadBalancerCmd, cmdInfo:
> {"physicalnetworkid":"9dbdb202-2f29-4d93-be19-20e70c4eb085","response":"json","sessionkey":"wNiOWZzu7DZ8g1onQ0P8HZkTmtw\u003d","username":"admin","cmdEventType":"PHYSICAL.LOADBALANCER.ADD","ctxUserId":"2","networkdevicetype":"F5BigIpLoadBalancer","httpmethod":"POST","ctxAccountId":"2","ctxStartEventId":"190","password":"password","url":"https://10.147.40.192?publicinterface\u003d1.1\u0026privateinterface\u003d1.2\u0026numretries\u003d2\u0026lbdevicededicated\u003dfalse"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 132129494109518, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2013-12-26 12:08:02,403 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-24:ctx-7a6a5fed ctx-2d9e9f38) ===END=== 10.146.0.134 -- POST
> command=addF5LoadBalancer&physicalnetworkid=9dbdb202-2f29-4d93-be19-20e70c4eb085&username=admin&networkdevicetype=F5BigIpLoadBalancer&url=https%3A%2F%2F10.147.40.192%3Fpublicinterface%3D1.1%26privateinterface%3D1.2%26numretries%3D2%26lbdevicededicated%3Dfalse&response=json&sessionkey=wNiOWZzu7DZ8g1onQ0P8HZkTmtw%3D
> 2013-12-26 12:08:02,529 ERROR [c.c.a.ApiAsyncJobDispatcher]
> (Job-Executor-53:ctx-f2fca977) Unexpected exception while executing
> com.cloud.api.commands.AddF5LoadBalancerCmd
> java.lang.NoClassDefFoundError:
> org/apache/commons/discovery/tools/DiscoverSingleton
> at
> org.apache.axis.components.logger.LogFactory$1.run(LogFactory.java:45)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.axis.components.logger.LogFactory.getLogFactory(LogFactory.java:41)
> at
> org.apache.axis.components.logger.LogFactory.(LogFactory.java:33)
> at
> org.apache.axis.handlers.BasicHandler.(BasicH
[jira] [Closed] (CLOUDSTACK-5657) [Hyper-v] vm live migration does not work if the Cloudstack Hyper-v Agen runs with "Local System" Log On"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N closed CLOUDSTACK-5657. - Now the agent gives an option to provide account details while installing. It does not accept the user details if they are not part of Hyper-v admin group and admin group on the host. Works fine. > [Hyper-v] vm live migration does not work if the Cloudstack Hyper-v Agen runs > with "Local System" Log On" > - > > Key: CLOUDSTACK-5657 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5657 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Affects Versions: 4.3.0 > Environment: latest build from 4.3 > Hypervisor: Hyperv > Storage: SMB for both primary and secondary >Reporter: Sanjeev N >Assignee: Devdeep Singh >Priority: Critical > Labels: hyper-V,, hyper-v, hyperv > Fix For: 4.3.0 > > > [Hyper-v] vm live migration does not work if the Cloudstack Hyper-v Agen runs > with "Local System" Log On" > CloudStack to communicate with Hyper-v server we run CloudStack-Hyperv Agent > as a service in Windows2012R2 (Hyperv) Server. By default this service would > run with "Local System" Log On. However vm live migration fails with > authentication issues if this service runs with "Local System" Log on. So we > need to stop this service and change the Log On account to domain user and > start the service for the live migration to work. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5562) management-server.log file does not get created with cloud user hence logging fails
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N closed CLOUDSTACK-5562. - Not seeing the issue anymore. Hence closing the bug. > management-server.log file does not get created with cloud user hence logging > fails > --- > > Key: CLOUDSTACK-5562 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5562 > 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: Latest build from 4.3 with commit > 197ef921f7b3c80998359f376fe045b13558633c >Reporter: Sanjeev N >Assignee: Saksham Srivastava >Priority: Critical > Fix For: 4.3.0 > > > management-server.log file does not get created with cloud user hence logging > fails > Steps to Reproduce; > > 1. Install management server with latest build > 2.Create zone > We don't see any log messages inside management server log file since it got > created with root user and has the file permissions as follows: > -rw-r--r--.1 root root 16899871 Dec 19 15:05 > /var/log/cloudstack/management/management-server.log > After changing the permissions I could see the messages getting logged in > inside that file. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5611) Can't create shared network with the same vlan being userd for Public Traffic but with different IP range
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N closed CLOUDSTACK-5611. - Closing based on the comments from Murali. > Can't create shared network with the same vlan being userd for Public Traffic > but with different IP range > -- > > Key: CLOUDSTACK-5611 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5611 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server >Affects Versions: 4.3.0 > Environment: Latest build from 4.3 branch with > commit:d462db4ae5c30e677d5810111f9ea5ca6812bce2 >Reporter: Sanjeev N >Assignee: Murali Reddy >Priority: Critical > Fix For: 4.3.0 > > > Can't create shared network with the same vlan being userd for Public Traffic > but with different IP range > Steps to Reproduce: > = > 1.Bring up CS in advanced zone with Hypev cluster > 2.Use tagged vlan ip range say: 10.147.48.0/24 with range 10.147.48.3-20 for > public traffic with vlan id 48. > 3.Deploy couple of guest vms. > 4.Try to create a shared network with vlan 48 with ip range from 10.147.48.30 > to 10.147.48.40. > Expected Result: > === > Should be allowed to create shared network with the vlan same as public > traffic. > Actual Result: > === > Shared network creation failed with the following error: > The IP range with tag: vlan://48 in zone Adv has overlapped with the subnet. > Please specify a different gateway/netmask. > CS should not allow to create multiple shared networks with CIDR/subnet, but > should be ok to allow shared network and public traffic in the same subnet > without overlapping IP ranges. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6146) subsequent migration fails as cloud stack renames files after 1st migration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13912581#comment-13912581 ] ASF subversion and git services commented on CLOUDSTACK-6146: - Commit 8cb03ddb2387c7aebf20dc0aa011e41f227e9f68 in cloudstack's branch refs/heads/4.3-forward from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8cb03dd ] CLOUDSTACK-6146. [VMware] [ESXi 5.5] Live VM migration of an already migrated VM (with storage) across clusters fails In vCenter 5.5, once a volume is migrated the VMDKs are renamed to match the name of the VM. Update volume path for every volume belonging to the VM to the corresponding new disk filename. > subsequent migration fails as cloud stack renames files after 1st migration > --- > > Key: CLOUDSTACK-6146 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6146 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 > Environment: ESXi 5.5 >Reporter: praveena palaniswamy >Assignee: Likitha Shetty >Priority: Critical > Fix For: 4.3.0 > > > CLoudplatform/Cloudstack, renames the files after first successful migration > and therefore, subsequent migration fails. This happens with > CloudPlatform 4.3 > Hypervisor: ESXi5.5 > 1.File name gets renamed after migration, which inturn fails subsequent > migrations (CLOUDSTACK issue) > a.Before migration of data disk the contents of VM folder can be seen > below > [root@host148 i-2-3-VM]# ls -l > total 40060 > -rw---. 1 root root 3221225472 Feb 13 2014 > 7868703c4e8345a58d568ece092baa0e-flat.vmdk > -rw---. 1 root root518 Feb 13 06:05 > 7868703c4e8345a58d568ece092baa0e.vmdk > [root@host148 i-2-3-VM]# > b.After migration, cloudstack renames the file name > 7868703c4e8345a58d568ece092baa0e.vmdk to i-2-3-VM_2.vmdk > [root@host148 i-2-3-VM]# ls -l > total 19072 > -rw---. 1 root root 3221225472 Feb 13 2014 i-2-3-VM_2-flat.vmdk > -rw---. 1 root root519 Feb 13 2014 i-2-3-VM_2.vmdk > [root@host148 i-2-3-VM]# > c.So when we call the migration for the second time, cloudstack looks for > the file “7868703c4e8345a58d568ece092baa0e.vmdk” and it does not find it and > migration fails. > d.Be it from netapp to non-netapp, or netapp to netapp, all the > subsequent migration fails with the following message > 2014-02-13 06:17:57,399 ERROR [c.c.h.v.r.VmwareResource] > (DirectAgent-415:ctx-33da787a 10.61.166.68) Catch Exception > java.lang.Exception due to java.lang.Exception: No such disk device: > 7868703c4e8345a58d568ece092baa0e.vmdk > java.lang.Exception: No such disk device: > 7868703c4e8345a58d568ece092baa0e.vmdk > at > com.cloud.hypervisor.vmware.resource.VmwareResource.getVirtualDiskInfo(VmwareResource.java:4420) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:4397) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:454) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > 2014-02-13 06:17:57,400 DEBUG [c.c.a.m.DirectAgentAttache] > (DirectAgent-415:ctx-33da787a) Seq 1-2016020265: Response Received: > 2014-02-13 06:17:57,401 DEBUG [c.c.a.t.Request] > (DirectAgent
[jira] [Commented] (CLOUDSTACK-6146) subsequent migration fails as cloud stack renames files after 1st migration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13912580#comment-13912580 ] ASF subversion and git services commented on CLOUDSTACK-6146: - Commit c652ff45dffaafa1cb0de29103e90fe936382028 in cloudstack's branch refs/heads/4.3-forward from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c652ff4 ] CLOUDSTACK-6146. [VMware] [ESXi 5.5] Live storage migration of an already migrated volume fails In vCenter 5.5, once a volume is migrated the VMDKs are renamed to match the name of the VM. If a volume has been renamed upon migration update its volumePath to that of the new disk filename. > subsequent migration fails as cloud stack renames files after 1st migration > --- > > Key: CLOUDSTACK-6146 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6146 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 > Environment: ESXi 5.5 >Reporter: praveena palaniswamy >Assignee: Likitha Shetty >Priority: Critical > Fix For: 4.3.0 > > > CLoudplatform/Cloudstack, renames the files after first successful migration > and therefore, subsequent migration fails. This happens with > CloudPlatform 4.3 > Hypervisor: ESXi5.5 > 1.File name gets renamed after migration, which inturn fails subsequent > migrations (CLOUDSTACK issue) > a.Before migration of data disk the contents of VM folder can be seen > below > [root@host148 i-2-3-VM]# ls -l > total 40060 > -rw---. 1 root root 3221225472 Feb 13 2014 > 7868703c4e8345a58d568ece092baa0e-flat.vmdk > -rw---. 1 root root518 Feb 13 06:05 > 7868703c4e8345a58d568ece092baa0e.vmdk > [root@host148 i-2-3-VM]# > b.After migration, cloudstack renames the file name > 7868703c4e8345a58d568ece092baa0e.vmdk to i-2-3-VM_2.vmdk > [root@host148 i-2-3-VM]# ls -l > total 19072 > -rw---. 1 root root 3221225472 Feb 13 2014 i-2-3-VM_2-flat.vmdk > -rw---. 1 root root519 Feb 13 2014 i-2-3-VM_2.vmdk > [root@host148 i-2-3-VM]# > c.So when we call the migration for the second time, cloudstack looks for > the file “7868703c4e8345a58d568ece092baa0e.vmdk” and it does not find it and > migration fails. > d.Be it from netapp to non-netapp, or netapp to netapp, all the > subsequent migration fails with the following message > 2014-02-13 06:17:57,399 ERROR [c.c.h.v.r.VmwareResource] > (DirectAgent-415:ctx-33da787a 10.61.166.68) Catch Exception > java.lang.Exception due to java.lang.Exception: No such disk device: > 7868703c4e8345a58d568ece092baa0e.vmdk > java.lang.Exception: No such disk device: > 7868703c4e8345a58d568ece092baa0e.vmdk > at > com.cloud.hypervisor.vmware.resource.VmwareResource.getVirtualDiskInfo(VmwareResource.java:4420) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:4397) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:454) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > 2014-02-13 06:17:57,400 DEBUG [c.c.a.m.DirectAgentAttache] > (DirectAgent-415:ctx-33da787a) Seq 1-2016020265: Response Received: > 2014-02-13 06:17:57,401 DEBUG [c.c.a.t.Request] > (DirectAgent-415:ctx-33da787a)
[jira] [Commented] (CLOUDSTACK-6146) subsequent migration fails as cloud stack renames files after 1st migration
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13912582#comment-13912582
]
Likitha Shetty commented on CLOUDSTACK-6146:
Reason for this VMDK filename changes during storage motion in vCenter 5.5
refer -
http://cormachogan.com/2013/12/03/vsphere-5-5-storage-enhancement-part-6-rename-files-using-svmotion/#more-2419
> subsequent migration fails as cloud stack renames files after 1st migration
> ---
>
> Key: CLOUDSTACK-6146
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6146
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.3.0
> Environment: ESXi 5.5
>Reporter: praveena palaniswamy
>Assignee: Likitha Shetty
>Priority: Critical
> Fix For: 4.3.0
>
>
> CLoudplatform/Cloudstack, renames the files after first successful migration
> and therefore, subsequent migration fails. This happens with
> CloudPlatform 4.3
> Hypervisor: ESXi5.5
> 1.File name gets renamed after migration, which inturn fails subsequent
> migrations (CLOUDSTACK issue)
> a.Before migration of data disk the contents of VM folder can be seen
> below
> [root@host148 i-2-3-VM]# ls -l
> total 40060
> -rw---. 1 root root 3221225472 Feb 13 2014
> 7868703c4e8345a58d568ece092baa0e-flat.vmdk
> -rw---. 1 root root518 Feb 13 06:05
> 7868703c4e8345a58d568ece092baa0e.vmdk
> [root@host148 i-2-3-VM]#
> b.After migration, cloudstack renames the file name
> 7868703c4e8345a58d568ece092baa0e.vmdk to i-2-3-VM_2.vmdk
> [root@host148 i-2-3-VM]# ls -l
> total 19072
> -rw---. 1 root root 3221225472 Feb 13 2014 i-2-3-VM_2-flat.vmdk
> -rw---. 1 root root519 Feb 13 2014 i-2-3-VM_2.vmdk
> [root@host148 i-2-3-VM]#
> c.So when we call the migration for the second time, cloudstack looks for
> the file “7868703c4e8345a58d568ece092baa0e.vmdk” and it does not find it and
> migration fails.
> d.Be it from netapp to non-netapp, or netapp to netapp, all the
> subsequent migration fails with the following message
> 2014-02-13 06:17:57,399 ERROR [c.c.h.v.r.VmwareResource]
> (DirectAgent-415:ctx-33da787a 10.61.166.68) Catch Exception
> java.lang.Exception due to java.lang.Exception: No such disk device:
> 7868703c4e8345a58d568ece092baa0e.vmdk
> java.lang.Exception: No such disk device:
> 7868703c4e8345a58d568ece092baa0e.vmdk
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.getVirtualDiskInfo(VmwareResource.java:4420)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:4397)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:454)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> 2014-02-13 06:17:57,400 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-415:ctx-33da787a) Seq 1-2016020265: Response Received:
> 2014-02-13 06:17:57,401 DEBUG [c.c.a.t.Request]
> (DirectAgent-415:ctx-33da787a) Seq 1-2016020265: Processing: { Ans: ,
> MgmtId: 52230907924, via: 1, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.storage.MigrateVolumeAnswer":{"result":false,"details":"Catch
> Exception java.lang.Exception due to java.lang.Exception: No such disk
> device: 7868703c4e8345a58d568ece092baa0e.vmdk","wait":0
[jira] [Closed] (CLOUDSTACK-5401) VM migration during host maintenance fails if pool.storage.capacity.disablethreshold is lowered
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] manasaveloori closed CLOUDSTACK-5401. - Closing the issue based on Prachi comments. Also...the threshold check is not done for user VMsVerified.Closing it > VM migration during host maintenance fails if > pool.storage.capacity.disablethreshold is lowered > --- > > Key: CLOUDSTACK-5401 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5401 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.1, 4.3.0 >Reporter: Prachi Damle >Assignee: Prachi Damle >Priority: Critical > Fix For: 4.3.0 > > Attachments: management-server.rar > > > 1. Create a 2 host XS 6.0.2 cluster (H1 and H2) > 2. Create 6 or more VMs such that they get created in H1 > 3. Lower pool.storage.capacity.disablethreshold to 0.1 (default is 0.85) > 4. Put H1 into maintenance. Some or all guest VMs fail to migrate to H2 > 2013-11-25 15:41:12,098 DEBUG [cloud.deploy.FirstFitPlanner] > (HA-Worker-3:work-28) The specified cluster is in avoid set, returning. > 2013-11-25 15:41:12,098 DEBUG [cloud.vm.VirtualMachineManagerImpl] > (HA-Worker-3:work-28) Unable to find destination for migrating the vm > VM[User|z1V6] > 2013-11-25 15:41:12,098 WARN [cloud.ha.HighAvailabilityManagerImpl] > (HA-Worker-3:work-28) Insufficient capacity for migrating a VM. > 2013-11-25 15:41:12,099 DEBUG [cloud.resource.ResourceManagerImpl] > (HA-Worker-3:work-28) No next resource state for host 5 while current state > is ErrorInMaintenance with event UnableToMigrate > com.cloud.utils.fsm.NoTransitionException: No next resource state found for > current state =ErrorInMaintenance event =UnableToMigrate > at > com.cloud.resource.ResourceManagerImpl.resourceStateTransitTo(ResourceManagerImpl.java:1178) > at > com.cloud.resource.ResourceManagerImpl.maintenanceFailed(ResourceManagerImpl.java:2313) > at > com.cloud.ha.HighAvailabilityManagerImpl.migrate(HighAvailabilityManagerImpl.java:610) > at > com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.run(HighAvailabilityManagerImpl.java:858) > 2013-11-25 15:41:12,100 INFO [cloud.ha.HighAvailabilityManagerImpl] > (HA-Worker-3:work-28) Rescheduling HAWork[28-Migration-9-Running-Migrating] > to try again at Mon Nov 25 15:43:14 PST 2013 > 2013-11-25 15:41:12,100 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (HA-Worker-4:work-29) Checking suitable pools for volume (Id, Type): (13,ROOT) > 2013-11-25 15:41:12,100 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (HA-Worker-4:work-29) We need to allocate new storagepool for this volume > 2013-11-25 15:41:12,102 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (HA-Worker-4:work-29) Calling StoragePoolAllocators to find suitable pools > 2013-11-25 15:41:12,103 DEBUG [storage.allocator.LocalStoragePoolAllocator] > (HA-Worker-4:work-29) LocalStoragePoolAllocator trying to find storage pool > to fit the vm > 2013-11-25 15:41:12,103 DEBUG > [storage.allocator.ClusterScopeStoragePoolAllocator] (HA-Worker-4:work-29) > ClusterScopeStoragePoolAllocator looking for storage pool > 2013-11-25 15:41:12,103 DEBUG > [storage.allocator.ClusterScopeStoragePoolAllocator] (HA-Worker-4:work-29) > Looking for pools in dc: 1 pod:1 cluster:1 > 2013-11-25 15:41:12,107 DEBUG > [storage.allocator.AbstractStoragePoolAllocator] (HA-Worker-4:work-29) > Checking if storage pool is suitable, name: null ,poolId: 200 > 2013-11-25 15:41:12,111 DEBUG [cloud.storage.StorageManagerImpl] > (HA-Worker-4:work-29) Checking pool 200 for storage, totalSize: > 11810778316800, usedBytes: 9755417411584, usedPct: 0.8259758290194649, > disable threshold: 0.1 > 2013-11-25 15:41:12,111 DEBUG [cloud.storage.StorageManagerImpl] > (HA-Worker-4:work-29) Insufficient space on pool: 200 since its usage > percentage: 0.8259758290194649 has crossed the > pool.storage.capacity.disablethreshold: 0.1 > 2013-11-25 15:41:12,111 DEBUG > [storage.allocator.ClusterScopeStoragePoolAllocator] (HA-Worker-4:work-29) > ClusterScopeStoragePoolAllocator returning 0 suitable storage pools > 2013-11-25 15:41:12,111 DEBUG > [storage.allocator.ZoneWideStoragePoolAllocator] (HA-Worker-4:work-29) > ZoneWideStoragePoolAllocator to find storage pool > 2013-11-25 15:41:12,113 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (HA-Worker-4:work-29) No suitable pools found for volume: Vol[13|vm=12|ROOT] > under cluster: 1 > 2013-11-25 15:41:12,113 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] > (HA-Worker-4:work-29) No suitable pools found > 2013-11-25 15:41:12,113 DEBUG [cloud.deploy.DeploymentPlanningMan
