[jira] [Closed] (CLOUDSTACK-4836) Restart network with cleanup=true won't reprogram remote access VPN users in the VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N closed CLOUDSTACK-4836. - Verified with latest build from 4.2.1. Now restart network with cleanup=true is reprogramming the vpn users. Following is the log snippet from SMlog during network restart : Nov 6 09:26:38 localhost SM: [2089] VMOPS enter routerProxy Nov 6 09:26:38 localhost SM: [2089] ['/bin/bash', '/opt/xensource/bin/router_proxy.sh', 'vpn_l2tp.sh', '169.254.2.29', '-u', 'test,test'] Nov 6 09:26:40 localhost SM: [2089] pread SUCCESS Nov 6 09:26:40 localhost SM: [2089] VMOPS exit routerProxy Nov 6 09:26:40 localhost SM: [2101] VMOPS enter routerProxy Nov 6 09:26:40 localhost SM: [2101] ['/bin/bash', '/opt/xensource/bin/router_proxy.sh', 'vpn_l2tp.sh', '169.254.2.29', '-u', 'test2,test2'] Nov 6 09:26:40 localhost SM: [2101] pread SUCCESS Nov 6 09:26:40 localhost SM: [2101] VMOPS exit routerProxy Nov 6 09:26:40 localhost SM: [2122] VMOPS enter routerProxy Nov 6 09:26:40 localhost SM: [2122] ['/bin/bash', '/opt/xensource/bin/router_proxy.sh', 'vpn_l2tp.sh', '169.254.2.29', '-r', '10.1.2.2-10.1.2.8', '-p', 'yBObVj44apyDa8g4HJg6wbqu', '-s', '10.147.45.17', '-l', '10.1.2.1', '-c', ''] Nov 6 09:26:42 localhost SM: [2122] pread SUCCESS Nov 6 09:26:42 localhost SM: [2122] VMOPS exit routerProxy > Restart network with cleanup=true won't reprogram remote access VPN users in > the VR > --- > > Key: CLOUDSTACK-4836 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4836 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 >Reporter: Sheng Yang >Assignee: Sheng Yang >Priority: Critical > Fix For: 4.2.1 > > > After restart network with cleanup=true, there is no programming of VPN users > of the new user, thus remote access VPN function is broken. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5054) vm migration involving storage migration fails with exception " The object has already been deleted or has not been completely created "
shweta agarwal created CLOUDSTACK-5054:
--
Summary: vm migration involving storage migration fails with
exception " The object has already been deleted or has not been completely
created "
Key: CLOUDSTACK-5054
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5054
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Upgrade, VMware
Affects Versions: 4.2.1
Environment: upgraded from 3.0.6 patch E to 4.2.1 with one advance
vmware zone (EXI5.1) and two cluster . Each cluster is n different VCenter
Reporter: shweta agarwal
Priority: Critical
Repro steps:
Created A VM
trying Vm migariton involving storage migration
BUg:
VM migrations fails with exception :
2013-11-06 14:46:43,790 WARN [vmware.resource.VmwareResource]
(DirectAgent-164:10.147.40.24) MigrationCommand failed due to Exception:
javax.xml.ws.soap.SOAPFaultException
Message: The object has already been deleted or has not been completely created
javax.xml.ws.soap.SOAPFaultException: The object has already been deleted or
has not been completely created
at
com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)
at
com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119)
at
com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
at
com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
at sun.proxy.$Proxy90.retrieveProperties(Unknown Source)
at
com.cloud.hypervisor.vmware.mo.DatacenterMO.getOwnerDatacenter(DatacenterMO.java:311)
at
com.cloud.hypervisor.vmware.mo.HostMO.getHyperHostDatacenter(HostMO.java:215)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:4215)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:461)
at
com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:679)
2013-11-06 14:46:43,798 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-164:null) Seq 4-951522009: Response Received:
2013-11-06 14:46:43,799 DEBUG [agent.transport.Request] (DirectAgent-164:null)
Seq 4-951522009: Processing: { Ans: , MgmtId: 6709611331648, via: 4, Ver: v1,
Flags: 110,
[{"com.cloud.agent.api.MigrateWithStorageAnswer":{"result":false,"details":"Exception:
javax.xml.ws.soap.SOAPFaultException\nMessage: The object has already been
deleted or has not been completely created\nStack:
javax.xml.ws.soap.SOAPFaultException: The object has already been deleted or
has not been completely created\n\tat
com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)\n\tat
com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119)\n\tat
com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)\n\tat
com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)\n\tat
com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)\n\tat
sun.proxy.$Proxy90.retrieveProperties(Unknown Source)\n\tat
com.cloud.hypervisor.vmware.mo.DatacenterMO.getOwnerDatacenter(DatacenterMO.java:311)\n\tat
com.cloud.hypervisor.vmware.mo.HostMO.getHyperHostDatacenter(HostMO.java:215)\n\tat
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:4215)\n\tat
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:461)\n\tat
com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)\n\tat
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)\n\tat
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)\n\tat
java.util.concurrent.FutureTask.run(FutureTask.java:166)\n\tat
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)\n\tat
java.util.concurrent.ScheduledTh
[jira] [Updated] (CLOUDSTACK-5054) vm migration involving storage migration on vmware fails with exception " The object has already been deleted or has not been completely created "
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal updated CLOUDSTACK-5054:
---
Summary: vm migration involving storage migration on vmware fails with
exception " The object has already been deleted or has not been completely
created " (was: vm migration involving storage migration fails with exception
" The object has already been deleted or has not been completely created ")
> vm migration involving storage migration on vmware fails with exception " The
> object has already been deleted or has not been completely created "
> --
>
> Key: CLOUDSTACK-5054
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5054
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Upgrade, VMware
>Affects Versions: 4.2.1
> Environment: upgraded from 3.0.6 patch E to 4.2.1 with one advance
> vmware zone (EXI5.1) and two cluster . Each cluster is n different VCenter
>Reporter: shweta agarwal
>Priority: Critical
>
> Repro steps:
> Created A VM
> trying Vm migariton involving storage migration
> BUg:
> VM migrations fails with exception :
> 2013-11-06 14:46:43,790 WARN [vmware.resource.VmwareResource]
> (DirectAgent-164:10.147.40.24) MigrationCommand failed due to Exception:
> javax.xml.ws.soap.SOAPFaultException
> Message: The object has already been deleted or has not been completely
> created
> javax.xml.ws.soap.SOAPFaultException: The object has already been deleted or
> has not been completely created
> at
> com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)
> at
> com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119)
> at
> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
> at
> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
> at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
> at sun.proxy.$Proxy90.retrieveProperties(Unknown Source)
> at
> com.cloud.hypervisor.vmware.mo.DatacenterMO.getOwnerDatacenter(DatacenterMO.java:311)
> at
> com.cloud.hypervisor.vmware.mo.HostMO.getHyperHostDatacenter(HostMO.java:215)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:4215)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:461)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:679)
> 2013-11-06 14:46:43,798 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-164:null) Seq 4-951522009: Response Received:
> 2013-11-06 14:46:43,799 DEBUG [agent.transport.Request]
> (DirectAgent-164:null) Seq 4-951522009: Processing: { Ans: , MgmtId:
> 6709611331648, via: 4, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.MigrateWithStorageAnswer":{"result":false,"details":"Exception:
> javax.xml.ws.soap.SOAPFaultException\nMessage: The object has already been
> deleted or has not been completely created\nStack:
> javax.xml.ws.soap.SOAPFaultException: The object has already been deleted or
> has not been completely created\n\tat
> com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)\n\tat
>
> com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119)\n\tat
>
> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)\n\tat
>
> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)\n\tat
> com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)\n\tat
> sun.proxy.$Proxy90.retrieveProperties(Unknown Source)\n\tat
> com.cloud.hypervisor.vmware.mo.DatacenterMO.getOwnerDatacenter(DatacenterMO.java:311)\n\tat
>
> com.cloud.hyperv
[jira] [Updated] (CLOUDSTACK-5054) vm migration involving storage migration on vmware fails with exception " The object has already been deleted or has not been completely created "
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal updated CLOUDSTACK-5054:
---
Attachment: cloud.dmp
management-server.log.tar.gz
cloud-after.dmp
> vm migration involving storage migration on vmware fails with exception " The
> object has already been deleted or has not been completely created "
> --
>
> Key: CLOUDSTACK-5054
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5054
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Upgrade, VMware
>Affects Versions: 4.2.1
> Environment: upgraded from 3.0.6 patch E to 4.2.1 with one advance
> vmware zone (EXI5.1) and two cluster . Each cluster is n different VCenter
>Reporter: shweta agarwal
>Priority: Critical
> Attachments: cloud-after.dmp, cloud.dmp, management-server.log.tar.gz
>
>
> Repro steps:
> Created A VM
> trying Vm migariton involving storage migration
> BUg:
> VM migrations fails with exception :
> 2013-11-06 14:46:43,790 WARN [vmware.resource.VmwareResource]
> (DirectAgent-164:10.147.40.24) MigrationCommand failed due to Exception:
> javax.xml.ws.soap.SOAPFaultException
> Message: The object has already been deleted or has not been completely
> created
> javax.xml.ws.soap.SOAPFaultException: The object has already been deleted or
> has not been completely created
> at
> com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)
> at
> com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119)
> at
> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
> at
> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
> at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
> at sun.proxy.$Proxy90.retrieveProperties(Unknown Source)
> at
> com.cloud.hypervisor.vmware.mo.DatacenterMO.getOwnerDatacenter(DatacenterMO.java:311)
> at
> com.cloud.hypervisor.vmware.mo.HostMO.getHyperHostDatacenter(HostMO.java:215)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:4215)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:461)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:679)
> 2013-11-06 14:46:43,798 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-164:null) Seq 4-951522009: Response Received:
> 2013-11-06 14:46:43,799 DEBUG [agent.transport.Request]
> (DirectAgent-164:null) Seq 4-951522009: Processing: { Ans: , MgmtId:
> 6709611331648, via: 4, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.MigrateWithStorageAnswer":{"result":false,"details":"Exception:
> javax.xml.ws.soap.SOAPFaultException\nMessage: The object has already been
> deleted or has not been completely created\nStack:
> javax.xml.ws.soap.SOAPFaultException: The object has already been deleted or
> has not been completely created\n\tat
> com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)\n\tat
>
> com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119)\n\tat
>
> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)\n\tat
>
> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)\n\tat
> com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)\n\tat
> sun.proxy.$Proxy90.retrieveProperties(Unknown Source)\n\tat
> com.cloud.hypervisor.vmware.mo.DatacenterMO.getOwnerDatacenter(DatacenterMO.java:311)\n\tat
>
> com.cloud.hypervisor.vmware.mo.HostMO.getHyperHostDatacenter(HostMO.java:215)\n\tat
>
> com.cloud.hypervisor.vmware.resource.VmwareResour
[jira] [Resolved] (CLOUDSTACK-5015) snapshot deletion fails as part of account cleanup on upgraded setup
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Harikrishna Patnala resolved CLOUDSTACK-5015.
-
Resolution: Not A Problem
During account cleanup we first delete the entire directory of snapshots
corresponding to a volume in that account. After this we retry deleting the
snapshots one by one and mark them as destroyed. During this second try we are
logging the exception("snapshot directory 'X' doesn't exist") in DEBUG mode.
> snapshot deletion fails as part of account cleanup on upgraded setup
>
>
> Key: CLOUDSTACK-5015
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5015
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Snapshot, Upgrade
>Affects Versions: 4.2.1
> Environment: 3.0.7 patch E to 4.2.1 upgrade with xen6.0.2 advance zone
>Reporter: shweta agarwal
>Assignee: Harikrishna Patnala
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: cloud.dmp, cloud_after.dmp, management-server.log.tar.gz
>
>
> Repro steps:
> Create a 3.0.7 setup
> create an account
> create some manual and recurring snapshots in this account .
> Upgrade to 4.2.1
> Delete the account
> MS log shows
> 2013-10-31 03:36:13,151 INFO [cloud.user.AccountManagerImpl]
> (Job-Executor-116:job-214 = [ fbae6bed-a270-4fd2-af84-db70c23966ef ])
> deleteAccount: Released 0 dedicated guest vlan ranges from account 5
> 2013-10-31 03:36:13,159 DEBUG [agent.transport.Request]
> (Job-Executor-114:job-212 = [ 4f683d9e-112a-4197-967f-532264c18dd7 ]) Seq
> 3-495256722: Sending { Cmd , MgmtId: 6826313646254, via: 3, Ver: v1, Flags:
> 100011,
> [{"org.apache.cloudstack.storage.command.DeleteCommand":{"data":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"snapshots/3/24/94f36b90-c52a-45a2-a0b7-0d53a444d9cc","volume":{"uuid":"dc4b65b3-630e-4504-98b2-28aa091d61cf","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"338e8952-c068-3fb4-90bd-bdf995d55d32","id":200,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/shweta/307.xen.primary1","port":2049}},"name":"DATA-12","size":5368709120,"path":"ce0d9b0c-bdc2-49e5-9e68-82c705a28114","volumeId":24,"accountId":3,"format":"VHD","id":24,"hypervisorType":"XenServer"},"dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.147.28.7/export/home/shweta/307.xen.secondary1","_role":"Image"}},"name":"fe357200-3975-482e-a594-797e5c8f972a_DATA-12_20131031050911","hypervisorType":"XenServer","id":50}},"wait":0}}]
> }
> 2013-10-31 03:36:13,213 DEBUG [agent.transport.Request]
> (AgentManager-Handler-14:null) Seq 3-495256722: Processing: { Ans: , MgmtId:
> 6826313646254, via: 3, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"snapshot directory
> 24 doesn't exist","wait":0}}] }
> 2013-10-31 03:36:13,213 DEBUG [agent.transport.Request]
> (Job-Executor-114:job-212 = [ 4f683d9e-112a-4197-967f-532264c18dd7 ]) Seq
> 3-495256722: Received: { Ans: , MgmtId: 6826313646254, via: 3, Ver: v1,
> Flags: 10, { Answer } }
> 2013-10-31 03:36:13,214 DEBUG [storage.snapshot.SnapshotServiceImpl]
> (Job-Executor-114:job-212 = [ 4f683d9e-112a-4197-967f-532264c18dd7 ]) delete
> snapshot failedsnapshot directory 24 doesn't exist
> 2013-10-31 03:36:13,241 DEBUG [storage.snapshot.XenserverSnapshotStrategy]
> (Job-Executor-114:job-212 = [ 4f683d9e-112a-4197-967f-532264c18dd7 ]) delete
> snapshot failed:
> com.cloud.utils.exception.CloudRuntimeException: snapshot directory 24
> doesn't exist
> at
> org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.deleteSnapshot(SnapshotServiceImpl.java:369)
> at
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.deleteSnapshotChain(XenserverSnapshotStrategy.java:173)
> at
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.deleteSnapshot(XenserverSnapshotStrategy.java:225)
> at
> com.cloud.storage.snapshot.SnapshotManagerImpl.deleteSnapshotDirsForAccount(SnapshotManagerImpl.java:684)
> at
> com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:584)
> at
> com.cloud.user.AccountManagerImpl.deleteAccount(AccountManagerImpl.java:547)
> at
> com.cloud.user.AccountManagerImpl.deleteUserAccount(AccountManagerImpl.java:1276)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.region.RegionManagerImpl.deleteUserAccount(RegionManagerImpl.java:206)
> at
> org.apache.cloudstack.region.RegionSer
[jira] [Created] (CLOUDSTACK-5055) host went in Error in maintenance mode ;unable to migrate vms
prashant kumar mishra created CLOUDSTACK-5055:
-
Summary: host went in Error in maintenance mode ;unable to migrate
vms
Key: CLOUDSTACK-5055
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5055
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: KVM, Management Server
Affects Versions: 4.2.0
Reporter: prashant kumar mishra
Steps to reproduce
-
-
1-preapare CS setup with kvm(rhel6.2) say host1
2-set execute.in.sequence.hypervisor.commands and
execute.in.sequence.network.element.commands to false
3-deploye 32 vms
4-add one more host say host 2in cluster
5-try to put host1 in maintenance mode
Expected
---
Host1 should go in maintenance mode
Actual
-
Host1 stuck in "Error In maintenance" state and few vms got migrated to host2
Logs
2013-11-06 09:53:27,424 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-8:null) Seq 4-2144927817: Unable to find listener.
2013-11-06 09:53:27,426 DEBUG [vm.dao.VMInstanceDaoImpl] (HA-Worker-4:work-34)
Unable to update VM[User|f66d29c2-2cd2-4715-ae31-5e43cea707bf]: DB
Data={Host=1; State=Running; updated=7; time=Wed Nov 06 09:53:27 EST 2013} New
Data: {Host=1; State=Stopping; updated=6; time=Wed Nov 06 09:53:27 EST 2013}
Stale Data: {Host=1; State=Running; updated=5; time=Wed Nov 06 09:53:25 EST
2013}
2013-11-06 09:53:27,435 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(HA-Worker-4:work-34) Unable to stop VM due to VM is being operated on.
2013-11-06 09:53:27,435 WARN [cloud.ha.HighAvailabilityManagerImpl]
(HA-Worker-4:work-34) Unable to migrate vm from 1
2013-11-06 09:53:27,432 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
(HA-Worker-3:work-38) DeploymentPlanner allocation algorithm:
com.cloud.deploy.FirstFitPlanner_EnhancerByCloudStack_e995abc3@d603051
2013-11-06 09:53:27,435 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
(HA-Worker-3:work-38) Trying to allocate a host and storage pools from dc:1,
pod:1,cluster:1, requested cpu: 200, requested ram: 134217728
2013-11-06 09:53:27,435 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
(HA-Worker-3:work-38) Is ROOT volume READY (pool already allocated)?: No
2013-11-06 09:53:27,435 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
(HA-Worker-3:work-38) This VM has last host_id specified, trying to choose the
same host: 1
2013-11-06 09:53:27,437 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
(HA-Worker-3:work-38) The last host of this VM is in avoid set
2013-11-06 09:53:27,437 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
(HA-Worker-3:work-38) Cannot choose the last host to deploy this VM
2013-11-06 09:53:27,437 DEBUG [cloud.deploy.FirstFitPlanner]
(HA-Worker-3:work-38) Searching resources only under specified Cluster: 1
2013-11-06 09:53:27,440 DEBUG [cloud.resource.ResourceManagerImpl]
(HA-Worker-4:work-34) No next resource state for host 1 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:602)
at
com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.run(HighAvailabilityManagerImpl.java:858)
2013-11-06 09:53:27,451 DEBUG [agent.transport.Request]
(AgentManager-Handler-10:null) Seq 1-1113784382: Processing: { Ans: , MgmtId:
6959054979131, via: 1, Ver: v1, Flags: 110,
[{"com.cloud.agent.api.MigrateAnswer":{"result":false,"details":"Cannot recv
data: Connection reset by peer","wait":0}}] }
2013-11-06 09:53:27,451 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-10:null) Seq 1-1113784382: No more commands found
2013-11-06 09:53:27,451 DEBUG [agent.transport.Request] (HA-Worker-0:work-35)
Seq 1-1113784382: Received: { Ans: , MgmtId: 6959054979131, via: 1, Ver: v1,
Flags: 110, { MigrateAnswer } }
2013-11-06 09:53:27,451 ERROR [cloud.vm.VirtualMachineManagerImpl]
(HA-Worker-0:work-35) Unable to migrate due to Cannot recv data: Connection
reset by peer
2013-11-06 09:53:27,452 INFO [cloud.vm.VirtualMachineManagerImpl]
(HA-Worker-0:work-35) Migration was unsuccessful. Cleaning up:
VM[User|b363903f-992c-412a-ab8d-a9bb15e23a51]
2013-11-06 09:53:27,449 DEBUG [agent.transport.Request]
(AgentManager-Handler-9:null) Seq 4-2144927816: Processing: { Ans: , MgmtId:
6959054979131, via: 4, Ver: v1, Flags: 110,
[{"com.cloud.agent.api.PrepareForMigrationAnswer":{"result":true,"wait":0}}] }
2013-11-06 09:53:27,452 DEBUG [agen
[jira] [Updated] (CLOUDSTACK-5055) host went in Error in maintenance mode ;unable to migrate vms
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
prashant kumar mishra updated CLOUDSTACK-5055:
--
Description:
Steps to reproduce
-
-
1-preapare CS setup with kvm(rhel6.2) say host1
2-set execute.in.sequence.hypervisor.commands and
execute.in.sequence.network.element.commands to false
3-deploye 32 vms
4-add one more host say host 2in cluster
5-try to put host1 in maintenance mode
Expected
---
Host1 should go in maintenance mode
Actual
-
Host1 stuck in "Error In maintenance" state and few vms got migrated to host2
My observation
-
1-i tried same with 3 vms user vms and system vms , enabling maintenance
worked properly ,
2-I saw this issue only when there are large number(32+) vms are there in a host
Logs
2013-11-06 09:53:27,424 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-8:null) Seq 4-2144927817: Unable to find listener.
2013-11-06 09:53:27,426 DEBUG [vm.dao.VMInstanceDaoImpl] (HA-Worker-4:work-34)
Unable to update VM[User|f66d29c2-2cd2-4715-ae31-5e43cea707bf]: DB
Data={Host=1; State=Running; updated=7; time=Wed Nov 06 09:53:27 EST 2013} New
Data: {Host=1; State=Stopping; updated=6; time=Wed Nov 06 09:53:27 EST 2013}
Stale Data: {Host=1; State=Running; updated=5; time=Wed Nov 06 09:53:25 EST
2013}
2013-11-06 09:53:27,435 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(HA-Worker-4:work-34) Unable to stop VM due to VM is being operated on.
2013-11-06 09:53:27,435 WARN [cloud.ha.HighAvailabilityManagerImpl]
(HA-Worker-4:work-34) Unable to migrate vm from 1
2013-11-06 09:53:27,432 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
(HA-Worker-3:work-38) DeploymentPlanner allocation algorithm:
com.cloud.deploy.FirstFitPlanner_EnhancerByCloudStack_e995abc3@d603051
2013-11-06 09:53:27,435 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
(HA-Worker-3:work-38) Trying to allocate a host and storage pools from dc:1,
pod:1,cluster:1, requested cpu: 200, requested ram: 134217728
2013-11-06 09:53:27,435 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
(HA-Worker-3:work-38) Is ROOT volume READY (pool already allocated)?: No
2013-11-06 09:53:27,435 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
(HA-Worker-3:work-38) This VM has last host_id specified, trying to choose the
same host: 1
2013-11-06 09:53:27,437 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
(HA-Worker-3:work-38) The last host of this VM is in avoid set
2013-11-06 09:53:27,437 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
(HA-Worker-3:work-38) Cannot choose the last host to deploy this VM
2013-11-06 09:53:27,437 DEBUG [cloud.deploy.FirstFitPlanner]
(HA-Worker-3:work-38) Searching resources only under specified Cluster: 1
2013-11-06 09:53:27,440 DEBUG [cloud.resource.ResourceManagerImpl]
(HA-Worker-4:work-34) No next resource state for host 1 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:602)
at
com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.run(HighAvailabilityManagerImpl.java:858)
2013-11-06 09:53:27,451 DEBUG [agent.transport.Request]
(AgentManager-Handler-10:null) Seq 1-1113784382: Processing: { Ans: , MgmtId:
6959054979131, via: 1, Ver: v1, Flags: 110,
[{"com.cloud.agent.api.MigrateAnswer":{"result":false,"details":"Cannot recv
data: Connection reset by peer","wait":0}}] }
2013-11-06 09:53:27,451 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-10:null) Seq 1-1113784382: No more commands found
2013-11-06 09:53:27,451 DEBUG [agent.transport.Request] (HA-Worker-0:work-35)
Seq 1-1113784382: Received: { Ans: , MgmtId: 6959054979131, via: 1, Ver: v1,
Flags: 110, { MigrateAnswer } }
2013-11-06 09:53:27,451 ERROR [cloud.vm.VirtualMachineManagerImpl]
(HA-Worker-0:work-35) Unable to migrate due to Cannot recv data: Connection
reset by peer
2013-11-06 09:53:27,452 INFO [cloud.vm.VirtualMachineManagerImpl]
(HA-Worker-0:work-35) Migration was unsuccessful. Cleaning up:
VM[User|b363903f-992c-412a-ab8d-a9bb15e23a51]
2013-11-06 09:53:27,449 DEBUG [agent.transport.Request]
(AgentManager-Handler-9:null) Seq 4-2144927816: Processing: { Ans: , MgmtId:
6959054979131, via: 4, Ver: v1, Flags: 110,
[{"com.cloud.agent.api.PrepareForMigrationAnswer":{"result":true,"wait":0}}] }
2013-11-06 09:53:27,452 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-9:null) Seq 4-2144927816: No more commands found
[jira] [Updated] (CLOUDSTACK-5055) host went in Error in maintenance mode ;unable to migrate vms
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
prashant kumar mishra updated CLOUDSTACK-5055:
--
Attachment: Agent_MS_Logs.rar
> host went in Error in maintenance mode ;unable to migrate vms
> -
>
> Key: CLOUDSTACK-5055
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5055
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Management Server
>Affects Versions: 4.2.0
>Reporter: prashant kumar mishra
> Attachments: Agent_MS_Logs.rar
>
>
> Steps to reproduce
> -
> -
> 1-preapare CS setup with kvm(rhel6.2) say host1
> 2-set execute.in.sequence.hypervisor.commands and
> execute.in.sequence.network.element.commands to false
> 3-deploye 32 vms
> 4-add one more host say host 2in cluster
> 5-try to put host1 in maintenance mode
> Expected
> ---
> Host1 should go in maintenance mode
> Actual
> -
> Host1 stuck in "Error In maintenance" state and few vms got migrated to host2
> My observation
> -
> 1-i tried same with 3 vms user vms and system vms , enabling maintenance
> worked properly ,
> 2-I saw this issue only when there are large number(32+) vms are there in a
> host
> Logs
>
> 2013-11-06 09:53:27,424 DEBUG [agent.manager.AgentAttache]
> (AgentManager-Handler-8:null) Seq 4-2144927817: Unable to find listener.
> 2013-11-06 09:53:27,426 DEBUG [vm.dao.VMInstanceDaoImpl]
> (HA-Worker-4:work-34) Unable to update
> VM[User|f66d29c2-2cd2-4715-ae31-5e43cea707bf]: DB Data={Host=1;
> State=Running; updated=7; time=Wed Nov 06 09:53:27 EST 2013} New Data:
> {Host=1; State=Stopping; updated=6; time=Wed Nov 06 09:53:27 EST 2013} Stale
> Data: {Host=1; State=Running; updated=5; time=Wed Nov 06 09:53:25 EST 2013}
> 2013-11-06 09:53:27,435 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (HA-Worker-4:work-34) Unable to stop VM due to VM is being operated on.
> 2013-11-06 09:53:27,435 WARN [cloud.ha.HighAvailabilityManagerImpl]
> (HA-Worker-4:work-34) Unable to migrate vm from 1
> 2013-11-06 09:53:27,432 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
> (HA-Worker-3:work-38) DeploymentPlanner allocation algorithm:
> com.cloud.deploy.FirstFitPlanner_EnhancerByCloudStack_e995abc3@d603051
> 2013-11-06 09:53:27,435 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
> (HA-Worker-3:work-38) Trying to allocate a host and storage pools from dc:1,
> pod:1,cluster:1, requested cpu: 200, requested ram: 134217728
> 2013-11-06 09:53:27,435 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
> (HA-Worker-3:work-38) Is ROOT volume READY (pool already allocated)?: No
> 2013-11-06 09:53:27,435 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
> (HA-Worker-3:work-38) This VM has last host_id specified, trying to choose
> the same host: 1
> 2013-11-06 09:53:27,437 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
> (HA-Worker-3:work-38) The last host of this VM is in avoid set
> 2013-11-06 09:53:27,437 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
> (HA-Worker-3:work-38) Cannot choose the last host to deploy this VM
> 2013-11-06 09:53:27,437 DEBUG [cloud.deploy.FirstFitPlanner]
> (HA-Worker-3:work-38) Searching resources only under specified Cluster: 1
> 2013-11-06 09:53:27,440 DEBUG [cloud.resource.ResourceManagerImpl]
> (HA-Worker-4:work-34) No next resource state for host 1 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:602)
> at
> com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.run(HighAvailabilityManagerImpl.java:858)
> 2013-11-06 09:53:27,451 DEBUG [agent.transport.Request]
> (AgentManager-Handler-10:null) Seq 1-1113784382: Processing: { Ans: ,
> MgmtId: 6959054979131, via: 1, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.MigrateAnswer":{"result":false,"details":"Cannot recv
> data: Connection reset by peer","wait":0}}] }
> 2013-11-06 09:53:27,451 DEBUG [agent.manager.AgentAttache]
> (AgentManager-Handler-10:null) Seq 1-1113784382: No more commands found
> 2013-11-06 09:53:27,451 DEBUG [agent.transport.Request] (HA-Worker-0:work-35)
> Seq 1-1113784382: Received: { Ans: , MgmtId: 6959054979131, via: 1, Ver: v1,
> Flags: 110, { MigrateAnswer } }
> 2013-1
[jira] [Updated] (CLOUDSTACK-5055) host went in Error in maintenance state ;unable to migrate vms
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
prashant kumar mishra updated CLOUDSTACK-5055:
--
Summary: host went in Error in maintenance state ;unable to migrate vms
(was: host went in Error in maintenance mode ;unable to migrate vms)
> host went in Error in maintenance state ;unable to migrate vms
> --
>
> Key: CLOUDSTACK-5055
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5055
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Management Server
>Affects Versions: 4.2.0
>Reporter: prashant kumar mishra
> Attachments: Agent_MS_Logs.rar
>
>
> Steps to reproduce
> -
> -
> 1-preapare CS setup with kvm(rhel6.2) say host1
> 2-set execute.in.sequence.hypervisor.commands and
> execute.in.sequence.network.element.commands to false
> 3-deploye 32 vms
> 4-add one more host say host 2in cluster
> 5-try to put host1 in maintenance mode
> Expected
> ---
> Host1 should go in maintenance mode
> Actual
> -
> Host1 stuck in "Error In maintenance" state and few vms got migrated to host2
> My observation
> -
> 1-i tried same with 3 vms user vms and system vms , enabling maintenance
> worked properly ,
> 2-I saw this issue only when there are large number(32+) vms are there in a
> host
> Logs
>
> 2013-11-06 09:53:27,424 DEBUG [agent.manager.AgentAttache]
> (AgentManager-Handler-8:null) Seq 4-2144927817: Unable to find listener.
> 2013-11-06 09:53:27,426 DEBUG [vm.dao.VMInstanceDaoImpl]
> (HA-Worker-4:work-34) Unable to update
> VM[User|f66d29c2-2cd2-4715-ae31-5e43cea707bf]: DB Data={Host=1;
> State=Running; updated=7; time=Wed Nov 06 09:53:27 EST 2013} New Data:
> {Host=1; State=Stopping; updated=6; time=Wed Nov 06 09:53:27 EST 2013} Stale
> Data: {Host=1; State=Running; updated=5; time=Wed Nov 06 09:53:25 EST 2013}
> 2013-11-06 09:53:27,435 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (HA-Worker-4:work-34) Unable to stop VM due to VM is being operated on.
> 2013-11-06 09:53:27,435 WARN [cloud.ha.HighAvailabilityManagerImpl]
> (HA-Worker-4:work-34) Unable to migrate vm from 1
> 2013-11-06 09:53:27,432 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
> (HA-Worker-3:work-38) DeploymentPlanner allocation algorithm:
> com.cloud.deploy.FirstFitPlanner_EnhancerByCloudStack_e995abc3@d603051
> 2013-11-06 09:53:27,435 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
> (HA-Worker-3:work-38) Trying to allocate a host and storage pools from dc:1,
> pod:1,cluster:1, requested cpu: 200, requested ram: 134217728
> 2013-11-06 09:53:27,435 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
> (HA-Worker-3:work-38) Is ROOT volume READY (pool already allocated)?: No
> 2013-11-06 09:53:27,435 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
> (HA-Worker-3:work-38) This VM has last host_id specified, trying to choose
> the same host: 1
> 2013-11-06 09:53:27,437 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
> (HA-Worker-3:work-38) The last host of this VM is in avoid set
> 2013-11-06 09:53:27,437 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl]
> (HA-Worker-3:work-38) Cannot choose the last host to deploy this VM
> 2013-11-06 09:53:27,437 DEBUG [cloud.deploy.FirstFitPlanner]
> (HA-Worker-3:work-38) Searching resources only under specified Cluster: 1
> 2013-11-06 09:53:27,440 DEBUG [cloud.resource.ResourceManagerImpl]
> (HA-Worker-4:work-34) No next resource state for host 1 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:602)
> at
> com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.run(HighAvailabilityManagerImpl.java:858)
> 2013-11-06 09:53:27,451 DEBUG [agent.transport.Request]
> (AgentManager-Handler-10:null) Seq 1-1113784382: Processing: { Ans: ,
> MgmtId: 6959054979131, via: 1, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.MigrateAnswer":{"result":false,"details":"Cannot recv
> data: Connection reset by peer","wait":0}}] }
> 2013-11-06 09:53:27,451 DEBUG [agent.manager.AgentAttache]
> (AgentManager-Handler-10:null) Seq 1-1113784382: No more commands found
> 2013-11-06 09:53:27,451 DEBUG [agent.transport.Request] (HA-Worker-0:work-35)
> Seq 1-
[jira] [Commented] (CLOUDSTACK-4550) [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have migration work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814771#comment-13814771 ] Wei Zhou commented on CLOUDSTACK-4550: -- hayou, Did you test on released 4.2.0, or 4.2.1 branch? > [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have > migration work > -- > > Key: CLOUDSTACK-4550 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4550 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc, KVM, Upgrade >Affects Versions: 4.2.0 >Reporter: Prasanna Santhanam >Priority: Critical > > See CLOUDSTACK-4405 for the original bug. This is the doc to be prepared as > part of upgrade in release notes once the fix for the bug is verified to work > After network bridges being renamed from cloudVirBrVLAN to brem1-VLAN to > support the same VLAN on multiple physical networks the migration of VMs from > hosts prior the upgrade to the ones added after the upgrade will fail. > In order to fix this rename the bridges is required to allow migration to > work. > This can be done by running the cloudstack-agent-upgrade script. The original > bug is still undergoing testing, but these are the initial instructions -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4128) [Object_store_Refactor] System VMs start up should check for existence of staging secondary storage in a zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-4128: -- Attachment: CS-4128.PNG > [Object_store_Refactor] System VMs start up should check for existence of > staging secondary storage in a zone > -- > > Key: CLOUDSTACK-4128 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4128 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 > Environment: Latest build from ACS 4.2 Branch > Storage: S3 for secondary storage >Reporter: Sanjeev N >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.2.1 > > Attachments: CS-4128.PNG, S3-UI.PNG, cloud.dmp, > jessica_2013_09_12.jpg, jessica_2013_09_17.sql, jessica_2013_09_17_A.jpg, > jessica_2013_09_17_B.jpg, jessica_2013_09_17_C.jpg, jessica_2013_09_17_D.jpg, > jessica_2013_09_17_E.jpg, jessica_2013_10_25.PNG, management-server.rar > > > System VMs start up should check for existence of stating secondary storage > in a zone. > With current implementation, adding secondary storage is optional during zone > creation wizard. > This issue will come in the following scenario: > === > 1.Add s3 storage > 2.Create a zone and skip adding secondary storage during zone creation(Since > S3 is already added before zone creation) > 3.Enable zone > After enabling the zone CS tries to bring up system vms and will fail since > there is no staging secondary storage. After adding staging storage system > vms will come up successfully. > Workaround is at step3 don't enable the zone until we add staging secondary > storage. Enable zone after adding staging secondary storage. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (CLOUDSTACK-4128) [Object_store_Refactor] System VMs start up should check for existence of staging secondary storage in a zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N closed CLOUDSTACK-4128. - Verified on the latest 4.2.1build with commit:544d1594f0e65365daa5390688b2e126750ea4f5 Now UI does not give an option to uncheck adding NFS staging storage while adding S3 based secondary storage during zone creation. Attaching working screen shot. Closing the issue. > [Object_store_Refactor] System VMs start up should check for existence of > staging secondary storage in a zone > -- > > Key: CLOUDSTACK-4128 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4128 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 > Environment: Latest build from ACS 4.2 Branch > Storage: S3 for secondary storage >Reporter: Sanjeev N >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.2.1 > > Attachments: CS-4128.PNG, S3-UI.PNG, cloud.dmp, > jessica_2013_09_12.jpg, jessica_2013_09_17.sql, jessica_2013_09_17_A.jpg, > jessica_2013_09_17_B.jpg, jessica_2013_09_17_C.jpg, jessica_2013_09_17_D.jpg, > jessica_2013_09_17_E.jpg, jessica_2013_10_25.PNG, management-server.rar > > > System VMs start up should check for existence of stating secondary storage > in a zone. > With current implementation, adding secondary storage is optional during zone > creation wizard. > This issue will come in the following scenario: > === > 1.Add s3 storage > 2.Create a zone and skip adding secondary storage during zone creation(Since > S3 is already added before zone creation) > 3.Enable zone > After enabling the zone CS tries to bring up system vms and will fail since > there is no staging secondary storage. After adding staging storage system > vms will come up successfully. > Workaround is at step3 don't enable the zone until we add staging secondary > storage. Enable zone after adding staging secondary storage. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5053) No Qemu-KVM module dependency error message is displayed (if not present)while installing KVM agent using ACS4.2 build
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814790#comment-13814790 ] manasaveloori commented on CLOUDSTACK-5053: --- doc link http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/Installation_Guide/index.html > No Qemu-KVM module dependency error message is displayed (if not > present)while installing KVM agent using ACS4.2 build > -- > > Key: CLOUDSTACK-5053 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5053 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.2.0 >Reporter: manasaveloori >Priority: Critical > > Install KVM agent as per the ACS doc. > Libvirtd will be installed as a part of agent installation.Qemu-kvm will > not get installed.so lsmod | grep kvm will not list kvm module .Also > /etc/sysconfig/modules will not list KVM_modules. > There is no dependency error/warning displayed while doing yum install > cloudstack-agent. > So the KVM host addition to CS fails. > Steps followed: > Did yum install kvm. > Now lsmod and /etc/sysconfig/modules will have kvm modules. > Now install cloudstack agent. > KVM host gets added to CS successfully. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5056) Cleaning up SSH library
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla updated CLOUDSTACK-5056: Description: Logging this bug to track issues with ssh library of marvin: 1. The library in it current form has some issues. As part of that, did clean up of the code. 2. Added tcp timeout flag as an additional parameter to help establish the tcp connections and retry if failed. It retries even otherwise failed. 3. Renamed few variables and maintained uniform usage and convention. 4. Added few new member functions runCommand,createConnection 5. Current, way of creating connection and raising exception from constructor along with return was removed and added a new way of handling it. 6. Currently, result list was returned for execute command, but we dont know the status of command execution, whether the output contains error or output etc. Now, provided more information in the return with new implementation. 7. Added few codes for proper return status. TODO: 1. Remove establishing connection from constructor altogether. This will effect the current modules using it. 2. Need to change is_server_ssh_ready function for proper and adequate checks, currently the name and functionality is little different. It can add more adequate checks before returning ssh object. was: 1. The library in it current form has some issues. As part of that, did clean up of the code. 2. Added tcp timeout flag as an additional parameter to help establish the tcp connections and retry if failed. It retries even otherwise failed. 3. Renamed few variables and maintained uniform usage and convention. 4. Added few new member functions runCommand,createConnection 5. Current, way of creating connection and raising exception from constructor along with return was removed and added a new way of handling it. 6. Currently, result list was returned for execute command, but we dont know the status of command execution, whether the output contains error or output etc. Now, provided more information in the return with new implementation. 7. Added few codes for proper return status. TODO: 1. Remove establishing connection from constructor altogether. This will effect the current modules using it. 2. Need to change is_server_ssh_ready function for proper and adequate checks, currently the name and functionality is little different. It can add more adequate checks before returning ssh object. > Cleaning up SSH library > --- > > Key: CLOUDSTACK-5056 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5056 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, marvin >Reporter: Santhosh Kumar Edukulla > > Logging this bug to track issues with ssh library of marvin: > 1. The library in it current form has some issues. As part of that, did clean > up of the code. > 2. Added tcp timeout flag as an additional parameter to help establish the > tcp connections and retry if failed. It retries even otherwise failed. > 3. Renamed few variables and maintained uniform usage and convention. > 4. Added few new member functions runCommand,createConnection > 5. Current, way of creating connection and raising exception from constructor > along with return was removed and added a new way of handling it. > 6. Currently, result list was returned for execute command, but we dont know > the status of command execution, whether the output contains error or output > etc. Now, provided more information in the return with new implementation. > 7. Added few codes for proper return status. > TODO: > 1. Remove establishing connection from constructor altogether. This will > effect the current modules using it. > 2. Need to change is_server_ssh_ready function for proper and adequate > checks, currently the name and functionality is little different. It can add > more adequate checks before returning ssh object. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5056) Cleaning up SSH library
Santhosh Kumar Edukulla created CLOUDSTACK-5056: --- Summary: Cleaning up SSH library Key: CLOUDSTACK-5056 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5056 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation, marvin Reporter: Santhosh Kumar Edukulla 1. The library in it current form has some issues. As part of that, did clean up of the code. 2. Added tcp timeout flag as an additional parameter to help establish the tcp connections and retry if failed. It retries even otherwise failed. 3. Renamed few variables and maintained uniform usage and convention. 4. Added few new member functions runCommand,createConnection 5. Current, way of creating connection and raising exception from constructor along with return was removed and added a new way of handling it. 6. Currently, result list was returned for execute command, but we dont know the status of command execution, whether the output contains error or output etc. Now, provided more information in the return with new implementation. 7. Added few codes for proper return status. TODO: 1. Remove establishing connection from constructor altogether. This will effect the current modules using it. 2. Need to change is_server_ssh_ready function for proper and adequate checks, currently the name and functionality is little different. It can add more adequate checks before returning ssh object. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5057) test_vpc_vm_life_cycle.TestVMLifeCycleSharedNwVPC.test_06_recover_instance_in_network failing due to dependency on test case ordering
Gaurav Aradhye created CLOUDSTACK-5057: -- Summary: test_vpc_vm_life_cycle.TestVMLifeCycleSharedNwVPC.test_06_recover_instance_in_network failing due to dependency on test case ordering Key: CLOUDSTACK-5057 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5057 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.3.0 test_vpc_vm_life_cycle.TestVMLifeCycleSharedNwVPC.test_06_recover_instance_in_network fails while recovering the virtual machine because the virtual machine is destroyed in previous test case. Dependency in the test cases should be removed. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4550) [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have migration work
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814808#comment-13814808
]
hayou commented on CLOUDSTACK-4550:
---
I test it on 4.2.1.
On 4.2.0 , its works cause you don't have this scripts :
'/etc/libvirt/hooks/qemu'
Here is my change :
{quote}
-newBrName="br" + phyDev + "-" + vlanId
+newBrName="cloudVirBr" + vlanId
{quote}
> [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have
> migration work
> --
>
> Key: CLOUDSTACK-4550
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4550
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Doc, KVM, Upgrade
>Affects Versions: 4.2.0
>Reporter: Prasanna Santhanam
>Priority: Critical
>
> See CLOUDSTACK-4405 for the original bug. This is the doc to be prepared as
> part of upgrade in release notes once the fix for the bug is verified to work
> After network bridges being renamed from cloudVirBrVLAN to brem1-VLAN to
> support the same VLAN on multiple physical networks the migration of VMs from
> hosts prior the upgrade to the ones added after the upgrade will fail.
> In order to fix this rename the bridges is required to allow migration to
> work.
> This can be done by running the cloudstack-agent-upgrade script. The original
> bug is still undergoing testing, but these are the initial instructions
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-5056) Cleaning up SSH library
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla reassigned CLOUDSTACK-5056: --- Assignee: Santhosh Kumar Edukulla > Cleaning up SSH library > --- > > Key: CLOUDSTACK-5056 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5056 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, marvin >Reporter: Santhosh Kumar Edukulla >Assignee: Santhosh Kumar Edukulla > > Logging this bug to track issues with ssh library of marvin: > 1. The library in it current form has some issues. As part of that, did clean > up of the code. > 2. Added tcp timeout flag as an additional parameter to help establish the > tcp connections and retry if failed. It retries even otherwise failed. > 3. Renamed few variables and maintained uniform usage and convention. > 4. Added few new member functions runCommand,createConnection > 5. Current, way of creating connection and raising exception from constructor > along with return was removed and added a new way of handling it. > 6. Currently, result list was returned for execute command, but we dont know > the status of command execution, whether the output contains error or output > etc. Now, provided more information in the return with new implementation. > 7. Added few codes for proper return status. > TODO: > 1. Remove establishing connection from constructor altogether. This will > effect the current modules using it. > 2. Need to change is_server_ssh_ready function for proper and adequate > checks, currently the name and functionality is little different. It can add > more adequate checks before returning ssh object. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5056) Cleaning up SSH library
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814816#comment-13814816 ] Santhosh Kumar Edukulla commented on CLOUDSTACK-5056: - Added fix with commit id:955be00bcd578d527a0305e25bbdc375254ce896 > Cleaning up SSH library > --- > > Key: CLOUDSTACK-5056 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5056 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, marvin >Reporter: Santhosh Kumar Edukulla >Assignee: Santhosh Kumar Edukulla > > Logging this bug to track issues with ssh library of marvin: > 1. The library in it current form has some issues. As part of that, did clean > up of the code. > 2. Added tcp timeout flag as an additional parameter to help establish the > tcp connections and retry if failed. It retries even otherwise failed. > 3. Renamed few variables and maintained uniform usage and convention. > 4. Added few new member functions runCommand,createConnection > 5. Current, way of creating connection and raising exception from constructor > along with return was removed and added a new way of handling it. > 6. Currently, result list was returned for execute command, but we dont know > the status of command execution, whether the output contains error or output > etc. Now, provided more information in the return with new implementation. > 7. Added few codes for proper return status. > TODO: > 1. Remove establishing connection from constructor altogether. This will > effect the current modules using it. > 2. Need to change is_server_ssh_ready function for proper and adequate > checks, currently the name and functionality is little different. It can add > more adequate checks before returning ssh object. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4550) [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have migration work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814825#comment-13814825 ] Wei Zhou commented on CLOUDSTACK-4550: -- What is the output of the following commands? brctl delbr brbond0-100 /usr/bin/cloudstack-agent-upgrade > [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have > migration work > -- > > Key: CLOUDSTACK-4550 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4550 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc, KVM, Upgrade >Affects Versions: 4.2.0 >Reporter: Prasanna Santhanam >Priority: Critical > > See CLOUDSTACK-4405 for the original bug. This is the doc to be prepared as > part of upgrade in release notes once the fix for the bug is verified to work > After network bridges being renamed from cloudVirBrVLAN to brem1-VLAN to > support the same VLAN on multiple physical networks the migration of VMs from > hosts prior the upgrade to the ones added after the upgrade will fail. > In order to fix this rename the bridges is required to allow migration to > work. > This can be done by running the cloudstack-agent-upgrade script. The original > bug is still undergoing testing, but these are the initial instructions -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4817) Backup snapshot on Xen should take global setting s3.multipart.enabled.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814827#comment-13814827 ] Pavan Kumar Bandarupally commented on CLOUDSTACK-4817: -- It is actually changed to s3.singleupload.max.size from s3.multipart.enabled. The current global setting will determine the size (ceiling 5GB) below which single part will be used. > Backup snapshot on Xen should take global setting s3.multipart.enabled. > --- > > Key: CLOUDSTACK-4817 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4817 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.0 > Environment: XenServer >Reporter: Min Chen >Assignee: edison su >Priority: Critical > Fix For: 4.2.1 > > > Currently backsnapshot to S3 on Xen only used single part upload in s3xen > plugin code, which will result in failure in case of snapshot is > 5GB. We > need that plugin code to check the configuration setting s3.multipart.enabled > to choose multipart or singlepart upload. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4816) provide configurable option to choose single vs multipart upload to S3 object storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814829#comment-13814829 ] Pavan Kumar Bandarupally commented on CLOUDSTACK-4816: -- A new global setting s3.singleupload.max.size is added, which determines the size (cap 5GB) below which single part is to be used for uploading. > provide configurable option to choose single vs multipart upload to S3 object > storage > -- > > Key: CLOUDSTACK-4816 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4816 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.0 >Reporter: Min Chen >Assignee: Min Chen >Priority: Critical > Fix For: 4.2.1 > > > In 4.2, we only supports multipart upload for registering templates and > uploading volumes to object storage in secondary storage. The value of > multi-part is for network failure and throughput when you are going to a > remote storage. But with local storage (local to the DC) customers may prefer > single upload. Also, for templates you know the full size of the object > upfront and don't really need a multipart upload. > Some object storage vendors may prefer that this can be configured. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4976) BSOD for windows VMs on XenServer host upgrade from 5.6 SP2 to 6.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814831#comment-13814831 ] Pavan Kumar Bandarupally commented on CLOUDSTACK-4976: -- Verified on latest build and it works fine. > BSOD for windows VMs on XenServer host upgrade from 5.6 SP2 to 6.2 > -- > > Key: CLOUDSTACK-4976 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4976 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Affects Versions: 4.2.1 > Environment: Before Upgrade: > CS: 3.0.7 Patch_B > XS: 5.6 SP2 > After Upgrade: > CS: 4.2.1 > XS: 6.2 >Reporter: Pavan Kumar Bandarupally >Assignee: Anthony Xu >Priority: Critical > Fix For: 4.2.1 > > Attachments: PVDriver_BSOD.jpg > > > Upgraded 3.0.7 Patch_B to 4.2.1 and later upgraded XS host from 5.6 SP2 to > 6.2. > A windows 2k8R2 instance that was created before upgrade had 5.6 PV drivers > installed. After upgrade when we try to restart the VM, a BSOD occurs and the > VM reverts to system recovery screen. > Attached screenshot. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (CLOUDSTACK-4976) BSOD for windows VMs on XenServer host upgrade from 5.6 SP2 to 6.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavan Kumar Bandarupally closed CLOUDSTACK-4976. > BSOD for windows VMs on XenServer host upgrade from 5.6 SP2 to 6.2 > -- > > Key: CLOUDSTACK-4976 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4976 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Affects Versions: 4.2.1 > Environment: Before Upgrade: > CS: 3.0.7 Patch_B > XS: 5.6 SP2 > After Upgrade: > CS: 4.2.1 > XS: 6.2 >Reporter: Pavan Kumar Bandarupally >Assignee: Anthony Xu >Priority: Critical > Fix For: 4.2.1 > > Attachments: PVDriver_BSOD.jpg > > > Upgraded 3.0.7 Patch_B to 4.2.1 and later upgraded XS host from 5.6 SP2 to > 6.2. > A windows 2k8R2 instance that was created before upgrade had 5.6 PV drivers > installed. After upgrade when we try to restart the VM, a BSOD occurs and the > VM reverts to system recovery screen. > Attached screenshot. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4839) Install Guide, section 3.5, provides wrong list of .deb packages
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814833#comment-13814833 ] manasaveloori commented on CLOUDSTACK-4839: --- Verified in the ACS4.2 Install guide Doc. In the following line "7" is removed. This command will build the following debian packages. You should have all of the following: > Install Guide, section 3.5, provides wrong list of .deb packages > > > Key: CLOUDSTACK-4839 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4839 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.2.0 >Reporter: Donal Lafferty >Assignee: Prasanna Santhanam > Fix For: 4.2.0, 4.2.1 > > > See > http://stackoverflow.com/questions/19240323/cloudstack-created-7-debian-package-instead-of-16-why -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-4593) [VMWARE] [Upgrade]Livestorage Migration & VM Snapshot features are not fully functional after upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ram Ganesh updated CLOUDSTACK-4593: --- Fix Version/s: 4.3.0 > [VMWARE] [Upgrade]Livestorage Migration & VM Snapshot features are not fully > functional after upgrade > -- > > Key: CLOUDSTACK-4593 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4593 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, Upgrade, VMware >Affects Versions: 4.2.1 >Reporter: Sailaja Mada > Fix For: 4.3.0 > > Attachments: apilogs.rar, clouddbback.dmp, mgmtlogs.rar > > > Steps: > Upgraded setup : > 307 Setup with 2 clusters ( Cluster1 – 2 ESXi 5.0 hosts , Cluster2 – Esxi 4.1 > host) > 1.11 Vm’s deployed with 2 VM’s in stopped state > 2.VM’s with ROOT volume, 2 DATA volumes, 3 DATA volumes > 3.Snapshots , Template / volumes from this snapshot > 4.Detached volumes > 5.Empty volumes which are not attached to any instance > 6.Cluster with 2 primary storage's > Upgraded to 4.2 > I got into below failures with VM Snapshot if tried without Stop/Start of the > VM Post upgrade : > 2013-09-02 21:35:36,733 WARN [vmware.resource.VmwareResource] > (DirectAgent-320:10.102.192.23) StartCommand failed due to Exception: > java.lang.RuntimeException > Message: File was not found > java.lang.RuntimeException: File was not found > at > com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:378) > at > com.cloud.hypervisor.vmware.mo.VirtualMachineMO.powerOn(VirtualMachineMO.java:188) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2966) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:519) > at > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) > 2013-09-02 21:35:36,742 DEBUG [agent.manager.DirectAgentAttache] > (DirectAgent-320:null) Seq 6-949618439: Response Received: > 2013-09-02 21:35:43,972 INFO [storage.volume.VolumeServiceImpl] > (Job-Executor-75:job-151 = [ 3e8e2327-7c56-45ea-a653-ee5b89d75d57 ]) Volume > 52 is not referred anywhere, remove it from volumes table > 2013-09-02 21:35:43,981 ERROR [cloud.storage.VolumeManagerImpl] > (Job-Executor-75:job-151 = [ 3e8e2327-7c56-45ea-a653-ee5b89d75d57 ]) migrate > volume failed:copy volume from primary to secondary failed due to exception: > Exception: java.lang.Exception > Message: Unable to find related disk device for volume. volume path: > ROOT-14-30-04 > 2013-09-02 21:35:43,990 INFO [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-75:job-151 = [ 3e8e2327-7c56-45ea-a653-ee5b89d75d57 ]) Unable > to contact resource. > com.cloud.exception.StorageUnavailableException: Resource [StoragePool:203] > is unreachable: migrate volume failed: copy volume from primary to secondary > failed due to exception: Exception: java.lang.Exception > Message: Unable to find related disk device for volume. volume path: > ROOT-14-30-04 > at > com.cloud.storage.VolumeManagerImpl.migrateVolume(VolumeManagerImpl.java:2254) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) > at > com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2590) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:888) > at > com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:578) > at > org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:237) > at > org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) > at > com.cloud.vm.UserVmManagerImpl.startV
[jira] [Created] (CLOUDSTACK-5058) Enable allocation of a template to a domain and optionally its subdomains
Octavian Popescu created CLOUDSTACK-5058: Summary: Enable allocation of a template to a domain and optionally its subdomains Key: CLOUDSTACK-5058 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5058 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: Template Reporter: Octavian Popescu When creating a new template please provide the option to allocate it to a domain and optionally to its subdomains. Once allocated, only those domains should be able to access the template. This is a critical feature for shared cloud environments. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4736) Monitering services in virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814863#comment-13814863 ] ASF subversion and git services commented on CLOUDSTACK-4736: - Commit 88170f9a79de55168d49a3c9ef60770d1d032a8b in branch refs/heads/master from [~jayapal] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=88170f9 ] CLOUDSTACK-4736 Monitoring service kvm vmware resource changes > Monitering services in virtual router > - > > Key: CLOUDSTACK-4736 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4736 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Reporter: Jayapal Reddy >Assignee: Jayapal Reddy > Fix For: 4.3.0 > > > The feature is about monitoring all the services rendered by the virtual > router, ensure that the services are running through the life time of the VR. > On service failure: > 1. Generate an alert and event indicating failure > 2. Restart the service > Services to be monitored: > DHCP, DNS, haproxy, password server etc. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4994) [VMware] Unable to attach VMwareToolsInstallerISO, unable to scale VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814869#comment-13814869
]
Likitha Shetty commented on CLOUDSTACK-4994:
The issue here is that we cannot attach VMwareToolsInstallerISO to a VM that
has CentOS 6.1, CentOS 6.2 or CentOS 6.3.
In CloudStack when VMs are installed from templates/ISO s that have the one of
the mentioned as the guest operating system, then the VM that is launched in
vCenter has the OS marked as 'Other'. And if the OS is not recognized then
VMware throws an error saying 'No VMware Tools package is available. The VMware
Tools package is not available for this guest operating system.'
Angie, can you confirm that with CentOS 6.3 attaching the VmwareInstallerISO
worked ? (Step 4)
> [VMware] Unable to attach VMwareToolsInstallerISO, unable to scale VM
> -
>
> Key: CLOUDSTACK-4994
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4994
> 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: MS 10.223.50.3
> http://repo-ccp.citrix.com/releases/ASF/rhel/6.4/4.2/CloudPlatform-4.2.1-28-rhel6.4.tar.gz
> host ESXi 5.1 Vcenter 5.1
>Reporter: angeline shen
>Assignee: Likitha Shetty
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: Screenshot-CloudPlatform™ - Mozilla Firefox-1.png,
> Screenshot-CloudPlatform™ - Mozilla Firefox-2.png, Screenshot-CloudPlatform™
> - Mozilla Firefox.png, Screenshot.png, management-server.log.gz
>
>
> advance zone. global parameter enable.dynamic.scale.vm=true
> 1. register ISO :
> http://nfs1.lab.vmops.com/isos_64bit/CentOS-6.1-x86_64-bin-DVD1.iso
> Deploy VM1 with ISO. Install OS.
> Failed to attach ‘VMware tools installerISO’
> 2013-10-29 18:24:49,622 DEBUG [agent.transport.Request]
> (StatsCollector-1:null) Seq 2-2116223057: Received: { Ans: , MgmtId:
> 206915885077197, via: 2, Ver: v1, Flags: 10, { GetStorageStatsAnswer } }
> 2013-10-29 18:24:49,728 ERROR [storage.resource.VmwareStorageProcessor]
> (DirectAgent-29:10.223.51.3) AttachIsoCommand(attach) failed due to
> Exception: javax.xml.ws.soap.SOAPFaultException
> Message: The required VMware Tools ISO image does not exist or is
> inaccessible.
> javax.xml.ws.soap.SOAPFaultException: The required VMware Tools ISO image
> does not exist or is inaccessible.
> at
> com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)
> at
> com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119)
> at
> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
> at
> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
> at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:129)
> at $Proxy91.mountToolsInstaller(Unknown Source)
> at
> com.cloud.hypervisor.vmware.mo.VirtualMachineMO.mountToolsInstaller(VirtualMachineMO.java:2279)
> at
> com.cloud.storage.resource.VmwareStorageProcessor.attachIso(VmwareStorageProcessor.java:1318)
> at
> com.cloud.storage.resource.VmwareStorageProcessor.attachIso(VmwareStorageProcessor.java:1183)
> at
> com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:127)
> at
> com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:55)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:559)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> 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)
> 2013-10-29 18:24:49,729 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-29:null) Seq 2-2116223058: Response Received:
> 2013-10-29 18:24:49,729 DEBUG [agen
[jira] [Updated] (CLOUDSTACK-4550) [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have migration work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] hayou updated CLOUDSTACK-4550: -- Attachment: bridge.jpg > [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have > migration work > -- > > Key: CLOUDSTACK-4550 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4550 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc, KVM, Upgrade >Affects Versions: 4.2.0 >Reporter: Prasanna Santhanam >Priority: Critical > Attachments: bridge.jpg > > > See CLOUDSTACK-4405 for the original bug. This is the doc to be prepared as > part of upgrade in release notes once the fix for the bug is verified to work > After network bridges being renamed from cloudVirBrVLAN to brem1-VLAN to > support the same VLAN on multiple physical networks the migration of VMs from > hosts prior the upgrade to the ones added after the upgrade will fail. > In order to fix this rename the bridges is required to allow migration to > work. > This can be done by running the cloudstack-agent-upgrade script. The original > bug is still undergoing testing, but these are the initial instructions -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5051) [Automation] vmware - Copy template to primary storage failed with NPE, and vm deployment failed
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Likitha Shetty resolved CLOUDSTACK-5051.
Resolution: Fixed
> [Automation] vmware - Copy template to primary storage failed with NPE, and
> vm deployment failed
> --
>
> Key: CLOUDSTACK-5051
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5051
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Template, VMware
>Affects Versions: 4.3.0
> Environment: vmware 5.0
> build : master 4.3.0
>Reporter: Rayees Namathponnan
>Assignee: Likitha Shetty
> Fix For: 4.3.0
>
> Attachments: CLOUDSTACK-5051.rar
>
>
> steps to reproduce
> create build from master branch, create advance zone, then deploy VM
> Actual result
> During router deployment, failed to copy template from primary storage and
> router deployment failed
> observed below NPE in ms log
> 2013-11-05 17:55:32,867 DEBUG [c.c.a.t.Request]
> (AgentManager-Handler-14:null) Seq 5-1852899341: Processing: { Ans: ,
> MgmtId: 90928106758026, via: 5, Ver: v1, Flag
> s: 10,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"result":false,"details":"Unable
> to copy template to primary storage due to exception:Exception: jav
> a.lang.NullPointerException\nMessage: null\n","wait":0}}] }
> 2013-11-05 17:55:32,867 DEBUG [c.c.a.t.Request] (Job-Executor-2:ctx-7de85510
> ctx-e51fa7a1) Seq 5-1852899341: Received: { Ans: , MgmtId: 90928106758026,
> via: 5, Ver
> : v1, Flags: 10, { CopyCmdAnswer } }
> 2013-11-05 17:55:32,878 INFO [o.a.c.s.v.VolumeServiceImpl]
> (Job-Executor-2:ctx-7de85510 ctx-e51fa7a1) releasing lock for
> VMTemplateStoragePool 4
> 2013-11-05 17:55:32,878 WARN [c.c.u.d.Merovingian2]
> (Job-Executor-2:ctx-7de85510 ctx-e51fa7a1) Was unable to find lock for the
> key template_spool_ref4 and thread i
> d 2009240553
> 2013-11-05 17:55:32,879 DEBUG [o.a.c.e.o.VolumeOrchestrator]
> (Job-Executor-2:ctx-7de85510 ctx-e51fa7a1) Unable to create
> Vol[5|vm=6|ROOT]:Unable to copy template to
> primary storage due to exception:Exception: java.lang.NullPointerException
> Message: null
> 2013-11-05 17:55:32,879 INFO [c.c.v.VirtualMachineManagerImpl]
> (Job-Executor-2:ctx-7de85510 ctx-e51fa7a1) Unable to contact resource.
> com.cloud.exception.StorageUnavailableException: Resource [StoragePool:2] is
> unreachable: Unable to create Vol[5|vm=6|ROOT]:Unable to copy template to
> primary stora
> ge due to exception:Exception: java.lang.NullPointerException
> Message: null
> at
> org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.recreateVolume(VolumeOrchestrator.java:1069)
> at
> org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.prepare(VolumeOrchestrator.java:)
> at
> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:828)
> at
> com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:510)
> at
> org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:227)
> at
> org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3409)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2990)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2976)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> :
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5051) [Automation] vmware - Copy template to primary storage failed with NPE, and vm deployment failed
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814888#comment-13814888
]
ASF subversion and git services commented on CLOUDSTACK-5051:
-
Commit f03dcdab19afbb358467e1e42dfb3a225ef6b446 in branch refs/heads/master
from [~likithas]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f03dcda ]
[CLOUDSTACK-5051] Revert "CLOUDSTACK-3715. Socket timeout error is observed in
VMware setup if a VMware task (RelocateVM_Task, CloneVM_Task etc.) takes more
than 10 minutes. Making this value configurable to allow admins to modify the
timeout if required. It defaults to the current value i.e. 10 minutes."
This reverts commit 3a9150017339fa9447e7e30b854ccd3351695dcc.
Conflicts:
plugins/hypervisors/vmware/src/com/cloud/storage/resource/VmwareSecondaryStorageContextFactory.java
> [Automation] vmware - Copy template to primary storage failed with NPE, and
> vm deployment failed
> --
>
> Key: CLOUDSTACK-5051
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5051
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Template, VMware
>Affects Versions: 4.3.0
> Environment: vmware 5.0
> build : master 4.3.0
>Reporter: Rayees Namathponnan
>Assignee: Likitha Shetty
> Fix For: 4.3.0
>
> Attachments: CLOUDSTACK-5051.rar
>
>
> steps to reproduce
> create build from master branch, create advance zone, then deploy VM
> Actual result
> During router deployment, failed to copy template from primary storage and
> router deployment failed
> observed below NPE in ms log
> 2013-11-05 17:55:32,867 DEBUG [c.c.a.t.Request]
> (AgentManager-Handler-14:null) Seq 5-1852899341: Processing: { Ans: ,
> MgmtId: 90928106758026, via: 5, Ver: v1, Flag
> s: 10,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"result":false,"details":"Unable
> to copy template to primary storage due to exception:Exception: jav
> a.lang.NullPointerException\nMessage: null\n","wait":0}}] }
> 2013-11-05 17:55:32,867 DEBUG [c.c.a.t.Request] (Job-Executor-2:ctx-7de85510
> ctx-e51fa7a1) Seq 5-1852899341: Received: { Ans: , MgmtId: 90928106758026,
> via: 5, Ver
> : v1, Flags: 10, { CopyCmdAnswer } }
> 2013-11-05 17:55:32,878 INFO [o.a.c.s.v.VolumeServiceImpl]
> (Job-Executor-2:ctx-7de85510 ctx-e51fa7a1) releasing lock for
> VMTemplateStoragePool 4
> 2013-11-05 17:55:32,878 WARN [c.c.u.d.Merovingian2]
> (Job-Executor-2:ctx-7de85510 ctx-e51fa7a1) Was unable to find lock for the
> key template_spool_ref4 and thread i
> d 2009240553
> 2013-11-05 17:55:32,879 DEBUG [o.a.c.e.o.VolumeOrchestrator]
> (Job-Executor-2:ctx-7de85510 ctx-e51fa7a1) Unable to create
> Vol[5|vm=6|ROOT]:Unable to copy template to
> primary storage due to exception:Exception: java.lang.NullPointerException
> Message: null
> 2013-11-05 17:55:32,879 INFO [c.c.v.VirtualMachineManagerImpl]
> (Job-Executor-2:ctx-7de85510 ctx-e51fa7a1) Unable to contact resource.
> com.cloud.exception.StorageUnavailableException: Resource [StoragePool:2] is
> unreachable: Unable to create Vol[5|vm=6|ROOT]:Unable to copy template to
> primary stora
> ge due to exception:Exception: java.lang.NullPointerException
> Message: null
> at
> org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.recreateVolume(VolumeOrchestrator.java:1069)
> at
> org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.prepare(VolumeOrchestrator.java:)
> at
> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:828)
> at
> com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:510)
> at
> org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:227)
> at
> org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3409)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2990)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2976)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(A
[jira] [Commented] (CLOUDSTACK-4550) [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have migration work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814887#comment-13814887 ] hayou commented on CLOUDSTACK-4550: --- # brctl delbr brbond0-100 bridge brbond0-100 doesn't exist; can't delete it and : /usr/bin/cloudstack-agent-upgrade ( screenshot ) > [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have > migration work > -- > > Key: CLOUDSTACK-4550 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4550 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc, KVM, Upgrade >Affects Versions: 4.2.0 >Reporter: Prasanna Santhanam >Priority: Critical > Attachments: bridge.jpg > > > See CLOUDSTACK-4405 for the original bug. This is the doc to be prepared as > part of upgrade in release notes once the fix for the bug is verified to work > After network bridges being renamed from cloudVirBrVLAN to brem1-VLAN to > support the same VLAN on multiple physical networks the migration of VMs from > hosts prior the upgrade to the ones added after the upgrade will fail. > In order to fix this rename the bridges is required to allow migration to > work. > This can be done by running the cloudstack-agent-upgrade script. The original > bug is still undergoing testing, but these are the initial instructions -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-3715) Live Migration of Virtual instances operation is getting timedout
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814889#comment-13814889
]
ASF subversion and git services commented on CLOUDSTACK-3715:
-
Commit f03dcdab19afbb358467e1e42dfb3a225ef6b446 in branch refs/heads/master
from [~likithas]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f03dcda ]
[CLOUDSTACK-5051] Revert "CLOUDSTACK-3715. Socket timeout error is observed in
VMware setup if a VMware task (RelocateVM_Task, CloneVM_Task etc.) takes more
than 10 minutes. Making this value configurable to allow admins to modify the
timeout if required. It defaults to the current value i.e. 10 minutes."
This reverts commit 3a9150017339fa9447e7e30b854ccd3351695dcc.
Conflicts:
plugins/hypervisors/vmware/src/com/cloud/storage/resource/VmwareSecondaryStorageContextFactory.java
> Live Migration of Virtual instances operation is getting timedout
> --
>
> Key: CLOUDSTACK-3715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3715
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, VMware
>Affects Versions: 4.2.0
>Reporter: Sailaja Mada
>Assignee: Likitha Shetty
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: 195113management-server.log.gz,
> 195117management-server.log.gz, apilog.log, cloud-backup.dmp.gz,
> cloud-backup.sql.gz, management-server.log, migrationlogs.rar
>
>
> Setup: Multinode Management setup.
> Steps:
> 1. Configure Adv Zone with 2 VMWARE clusters each with one hosts with Zone
> wide primary storage ( Standard vSwitch cluster)
> 2. Deploy VM using User account
> 3. Tried to Live migrate VM from cluster1 (host 1) to Cluster 2 (host2 )
> Observation:
> 1. Migration took very log time and finally failed saying operation timed out
> :
> 2013-07-22 17:46:06,288 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-40:job-133 = [ 4a2f6d84-236d-4bdd-a2e5-72fa336e0274 ]) VM state
> transitted from :Migrating to Running with event: OperationFailedvm's
> original host id: 4 new host id: 4 host id before state transition: 1
> 2013-07-22 17:46:06,292 INFO [vmware.resource.VmwareResource]
> (DirectAgent-421:10.102.192.18) VM i-4-9-VM is no longer in vSphere
> 2013-07-22 17:46:06,293 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-421:null) Seq 1-1311245319: Response Received:
> 2013-07-22 17:46:06,294 DEBUG [agent.transport.Request]
> (DirectAgent-421:null) Seq 1-1311245319: Processing: { Ans: , MgmtId:
> 94838926819810, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.StopAnswer":{"vncPort":0,"result":true,"details":"VM
> i-4-9-VM is no longer in vSphere","wait":0}}] }
> 2013-07-22 17:46:06,294 DEBUG [agent.manager.AgentAttache]
> (DirectAgent-421:null) Seq 1-1311245319: Unable to find listener.
> 2013-07-22 17:46:06,307 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-40:job-133 = [ 4a2f6d84-236d-4bdd-a2e5-72fa336e0274 ]) Hosts's
> actual total CPU: 9572 and CPU after applying overprovisioning: 9572
> 2013-07-22 17:46:06,307 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-40:job-133 = [ 4a2f6d84-236d-4bdd-a2e5-72fa336e0274 ]) Hosts's
> actual total RAM: 17166258176 and RAM after applying overprovisioning:
> 17166258176
> 2013-07-22 17:46:06,307 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-40:job-133 = [ 4a2f6d84-236d-4bdd-a2e5-72fa336e0274 ]) release
> cpu from host: 1, old used: 2000,reserved: 0, actual total: 9572, total with
> overprovisioning: 9572; new used: 200,reserved:0; movedfromreserved:
> false,moveToReserveredfalse
> 2013-07-22 17:46:06,307 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-40:job-133 = [ 4a2f6d84-236d-4bdd-a2e5-72fa336e0274 ]) release
> mem from host: 1, old used: 2013265920,reserved: 0, total: 17166258176; new
> used: 2013265920,reserved:0; movedfromreserved: false,moveToReserveredfalse
> 2013-07-22 17:46:06,345 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-40:job-133 = [ 4a2f6d84-236d-4bdd-a2e5-72fa336e0274 ])
> Unexpected exception while executing
> org.apache.cloudstack.api.command.admin.vm.MigrateVirtualMachineWithVolumeCmd
> com.cloud.utils.exception.CloudRuntimeException: Failed to migrated vm
> VM[User|newuser1i1] along with its volumes.
> com.cloud.exception.AgentUnavailableException: Resource [Host:1] is
> unreachable: Host 1: Operation timed out on storage motion for
> VM[User|newuser1i1]
> at
> com.cloud.storage.VolumeManagerImpl.migrateVolumes(VolumeManagerImpl.java:2263)
> at
> com.cloud.vm.VirtualMachineManagerImpl.migrateWithStorage(VirtualMachineManagerImp
[jira] [Reopened] (CLOUDSTACK-3715) Live Migration of Virtual instances operation is getting timedout
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Likitha Shetty reopened CLOUDSTACK-3715:
Reopening this bug as the commit made to fix this issue has been reverted
> Live Migration of Virtual instances operation is getting timedout
> --
>
> Key: CLOUDSTACK-3715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3715
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, VMware
>Affects Versions: 4.2.0
>Reporter: Sailaja Mada
>Assignee: Likitha Shetty
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: 195113management-server.log.gz,
> 195117management-server.log.gz, apilog.log, cloud-backup.dmp.gz,
> cloud-backup.sql.gz, management-server.log, migrationlogs.rar
>
>
> Setup: Multinode Management setup.
> Steps:
> 1. Configure Adv Zone with 2 VMWARE clusters each with one hosts with Zone
> wide primary storage ( Standard vSwitch cluster)
> 2. Deploy VM using User account
> 3. Tried to Live migrate VM from cluster1 (host 1) to Cluster 2 (host2 )
> Observation:
> 1. Migration took very log time and finally failed saying operation timed out
> :
> 2013-07-22 17:46:06,288 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-40:job-133 = [ 4a2f6d84-236d-4bdd-a2e5-72fa336e0274 ]) VM state
> transitted from :Migrating to Running with event: OperationFailedvm's
> original host id: 4 new host id: 4 host id before state transition: 1
> 2013-07-22 17:46:06,292 INFO [vmware.resource.VmwareResource]
> (DirectAgent-421:10.102.192.18) VM i-4-9-VM is no longer in vSphere
> 2013-07-22 17:46:06,293 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-421:null) Seq 1-1311245319: Response Received:
> 2013-07-22 17:46:06,294 DEBUG [agent.transport.Request]
> (DirectAgent-421:null) Seq 1-1311245319: Processing: { Ans: , MgmtId:
> 94838926819810, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.StopAnswer":{"vncPort":0,"result":true,"details":"VM
> i-4-9-VM is no longer in vSphere","wait":0}}] }
> 2013-07-22 17:46:06,294 DEBUG [agent.manager.AgentAttache]
> (DirectAgent-421:null) Seq 1-1311245319: Unable to find listener.
> 2013-07-22 17:46:06,307 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-40:job-133 = [ 4a2f6d84-236d-4bdd-a2e5-72fa336e0274 ]) Hosts's
> actual total CPU: 9572 and CPU after applying overprovisioning: 9572
> 2013-07-22 17:46:06,307 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-40:job-133 = [ 4a2f6d84-236d-4bdd-a2e5-72fa336e0274 ]) Hosts's
> actual total RAM: 17166258176 and RAM after applying overprovisioning:
> 17166258176
> 2013-07-22 17:46:06,307 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-40:job-133 = [ 4a2f6d84-236d-4bdd-a2e5-72fa336e0274 ]) release
> cpu from host: 1, old used: 2000,reserved: 0, actual total: 9572, total with
> overprovisioning: 9572; new used: 200,reserved:0; movedfromreserved:
> false,moveToReserveredfalse
> 2013-07-22 17:46:06,307 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-40:job-133 = [ 4a2f6d84-236d-4bdd-a2e5-72fa336e0274 ]) release
> mem from host: 1, old used: 2013265920,reserved: 0, total: 17166258176; new
> used: 2013265920,reserved:0; movedfromreserved: false,moveToReserveredfalse
> 2013-07-22 17:46:06,345 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-40:job-133 = [ 4a2f6d84-236d-4bdd-a2e5-72fa336e0274 ])
> Unexpected exception while executing
> org.apache.cloudstack.api.command.admin.vm.MigrateVirtualMachineWithVolumeCmd
> com.cloud.utils.exception.CloudRuntimeException: Failed to migrated vm
> VM[User|newuser1i1] along with its volumes.
> com.cloud.exception.AgentUnavailableException: Resource [Host:1] is
> unreachable: Host 1: Operation timed out on storage motion for
> VM[User|newuser1i1]
> at
> com.cloud.storage.VolumeManagerImpl.migrateVolumes(VolumeManagerImpl.java:2263)
> at
> com.cloud.vm.VirtualMachineManagerImpl.migrateWithStorage(VirtualMachineManagerImpl.java:1780)
> at
> com.cloud.vm.UserVmManagerImpl.migrateVirtualMachineWithVolume(UserVmManagerImpl.java:4046)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.admin.vm.MigrateVirtualMachineWithVolumeCmd.execute(MigrateVirtualMachineWithVolumeCmd.java:137)
> 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)
>
[jira] [Commented] (CLOUDSTACK-4550) [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have migration work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814900#comment-13814900 ] Wei Zhou commented on CLOUDSTACK-4550: -- It looks good. The vm should use brbond0-100, not brbond0.100-100. It could be a misconfiguration. What is the guest.network.device in agent.properties? > [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have > migration work > -- > > Key: CLOUDSTACK-4550 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4550 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc, KVM, Upgrade >Affects Versions: 4.2.0 >Reporter: Prasanna Santhanam >Priority: Critical > Attachments: bridge.jpg > > > See CLOUDSTACK-4405 for the original bug. This is the doc to be prepared as > part of upgrade in release notes once the fix for the bug is verified to work > After network bridges being renamed from cloudVirBrVLAN to brem1-VLAN to > support the same VLAN on multiple physical networks the migration of VMs from > hosts prior the upgrade to the ones added after the upgrade will fail. > In order to fix this rename the bridges is required to allow migration to > work. > This can be done by running the cloudstack-agent-upgrade script. The original > bug is still undergoing testing, but these are the initial instructions -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5059) Incorrect provisioning on virtual switches instead of dvSwitches
Octavian Popescu created CLOUDSTACK-5059:
Summary: Incorrect provisioning on virtual switches instead of
dvSwitches
Key: CLOUDSTACK-5059
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5059
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Octavian Popescu
Scenario:
Two physical networks with guest type traffic. One uses vSS, the other vDS. All
provisioning goes to vSS even though network tags are being used inside network
offerings and the networks are being created specifically to use vDS.
Log entries:
Information is received correctly but the network is being prepared using
vmwaresvs.
2013-10-29 15:25:52,249 INFO [vmware.resource.VmwareResource]
(DirectAgent-373:inth1-vdc-pvh03.pargar.cp.vdc) Prepare NIC device based on
NicTO:
{"deviceId":0,"networkRateMbps":2000,"defaultNic":true,"uuid":"c845ba28-1980-4f32-838a-13aa4953464d","ip":"10.122.29.225","netmask":"255.255.254.0","gateway":"10.122.28.1","mac":"06:f0:be:00:03:6b","dns1":"8.8.8.8","dns2":"8.8.4.4","broadcastType":"Pvlan","type":"Guest","broadcastUri":"pvlan://1100-i1101","isolationUri":"vlan://1100","isSecurityGroupEnabled":false,"name":"dvSwitch_OOB,1100,vmwaredvs"}
2013-10-29 15:25:52,252 INFO [vmware.resource.VmwareResource]
(DirectAgent-373:inth1-vdc-pvh03.pargar.cp.vdc) Prepare network on vmwaresvs
P[vSwitch0:untagged] with name prefix: cloud.guest
2013-10-29 15:25:52,349 INFO [vmware.mo.HypervisorHostHelper]
(DirectAgent-373:inth1-vdc-pvh03.pargar.cp.vdc) Network
cloud.guest.1100.2000.1-vSwitch0 is ready on vSwitch vSwitch0
2013-10-29 15:25:52,350 INFO [vmware.resource.VmwareResource]
(DirectAgent-373:inth1-vdc-pvh03.pargar.cp.vdc) Preparing NIC device on network
cloud.guest.1100.2000.1-vSwitch0
2013-10-29 15:25:52,350 DEBUG [vmware.resource.VmwareResource]
(DirectAgent-373:inth1-vdc-pvh03.pargar.cp.vdc) Prepare NIC at new device
{"operation":"ADD","device":{"addressType":"Manual","macAddress":"06:f0:be:00:03:6b","key":-3,"backing":{"network":{"value":"network-681","type":"Network"},"deviceName":"cloud.guest.1100.2000.1-vSwitch0"},"connectable":{"startConnected":true,"allowGuestControl":true,"connected":true},"unitNumber":0}}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5059) Incorrect provisioning on virtual switches instead of dvSwitches
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Octavian Popescu updated CLOUDSTACK-5059:
-
Description:
Scenario:
Two physical networks with guest type traffic. One uses vSS, the other vDS. All
provisioning goes to vSS even though network tags are being used inside network
offerings and the networks are being created specifically to use vDS.
Log entries:
Information is received correctly but the network is being prepared using
vmwaresvs.
2013-10-29 15:25:52,249 INFO [vmware.resource.VmwareResource]
(DirectAgent-373:) Prepare NIC device based on NicTO:
{"deviceId":0,"networkRateMbps":2000,"defaultNic":true,"uuid":"c845ba28-1980-4f32-838a-13aa4953464d","ip":"10.122.29.225","netmask":"255.255.254.0","gateway":"10.122.28.1","mac":"06:f0:be:00:03:6b","dns1":"8.8.8.8","dns2":"8.8.4.4","broadcastType":"Pvlan","type":"Guest","broadcastUri":"pvlan://1100-i1101","isolationUri":"vlan://1100","isSecurityGroupEnabled":false,"name":"dvSwitch_OOB,1100,vmwaredvs"}
2013-10-29 15:25:52,252 INFO [vmware.resource.VmwareResource]
(DirectAgent-373:) Prepare network on vmwaresvs P[vSwitch0:untagged] with
name prefix: cloud.guest
2013-10-29 15:25:52,349 INFO [vmware.mo.HypervisorHostHelper]
(DirectAgent-373:) Network cloud.guest.1100.2000.1-vSwitch0 is ready on
vSwitch vSwitch0
2013-10-29 15:25:52,350 INFO [vmware.resource.VmwareResource]
(DirectAgent-373:) Preparing NIC device on network
cloud.guest.1100.2000.1-vSwitch0
2013-10-29 15:25:52,350 DEBUG [vmware.resource.VmwareResource]
(DirectAgent-373:) Prepare NIC at new device
{"operation":"ADD","device":{"addressType":"Manual","macAddress":"06:f0:be:00:03:6b","key":-3,"backing":{"network":{"value":"network-681","type":"Network"},"deviceName":"cloud.guest.1100.2000.1-vSwitch0"},"connectable":{"startConnected":true,"allowGuestControl":true,"connected":true},"unitNumber":0}}
was:
Scenario:
Two physical networks with guest type traffic. One uses vSS, the other vDS. All
provisioning goes to vSS even though network tags are being used inside network
offerings and the networks are being created specifically to use vDS.
Log entries:
Information is received correctly but the network is being prepared using
vmwaresvs.
2013-10-29 15:25:52,249 INFO [vmware.resource.VmwareResource]
(DirectAgent-373:inth1-vdc-pvh03.pargar.cp.vdc) Prepare NIC device based on
NicTO:
{"deviceId":0,"networkRateMbps":2000,"defaultNic":true,"uuid":"c845ba28-1980-4f32-838a-13aa4953464d","ip":"10.122.29.225","netmask":"255.255.254.0","gateway":"10.122.28.1","mac":"06:f0:be:00:03:6b","dns1":"8.8.8.8","dns2":"8.8.4.4","broadcastType":"Pvlan","type":"Guest","broadcastUri":"pvlan://1100-i1101","isolationUri":"vlan://1100","isSecurityGroupEnabled":false,"name":"dvSwitch_OOB,1100,vmwaredvs"}
2013-10-29 15:25:52,252 INFO [vmware.resource.VmwareResource]
(DirectAgent-373:inth1-vdc-pvh03.pargar.cp.vdc) Prepare network on vmwaresvs
P[vSwitch0:untagged] with name prefix: cloud.guest
2013-10-29 15:25:52,349 INFO [vmware.mo.HypervisorHostHelper]
(DirectAgent-373:inth1-vdc-pvh03.pargar.cp.vdc) Network
cloud.guest.1100.2000.1-vSwitch0 is ready on vSwitch vSwitch0
2013-10-29 15:25:52,350 INFO [vmware.resource.VmwareResource]
(DirectAgent-373:inth1-vdc-pvh03.pargar.cp.vdc) Preparing NIC device on network
cloud.guest.1100.2000.1-vSwitch0
2013-10-29 15:25:52,350 DEBUG [vmware.resource.VmwareResource]
(DirectAgent-373:inth1-vdc-pvh03.pargar.cp.vdc) Prepare NIC at new device
{"operation":"ADD","device":{"addressType":"Manual","macAddress":"06:f0:be:00:03:6b","key":-3,"backing":{"network":{"value":"network-681","type":"Network"},"deviceName":"cloud.guest.1100.2000.1-vSwitch0"},"connectable":{"startConnected":true,"allowGuestControl":true,"connected":true},"unitNumber":0}}
> Incorrect provisioning on virtual switches instead of dvSwitches
>
>
> Key: CLOUDSTACK-5059
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5059
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Octavian Popescu
>
> Scenario:
> Two physical networks with guest type traffic. One uses vSS, the other vDS.
> All provisioning goes to vSS even though network tags are being used inside
> network offerings and the networks are being created specifically to use vDS.
> Log entries:
> Information is received correctly but the network is being prepared using
> vmwaresvs.
> 2013-10-29 15:25:52,249 INFO [vmware.resource.VmwareResource]
> (DirectAgent-373:) Prepare NIC device based on NicTO:
> {"deviceId":0,"networkRateMbps":2000,"defaultNic":true,"uuid":"c845ba28-1980-4f32-838a-13aa4953464d","ip":"10.122.29.225","netmask":"255.255.254.0","gateway":"10.122
[jira] [Commented] (CLOUDSTACK-3715) Live Migration of Virtual instances operation is getting timedout
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814931#comment-13814931
]
ASF subversion and git services commented on CLOUDSTACK-3715:
-
Commit 9a8dddac2fff5e51bd59db57ac58ae98fa8a2b6a in branch refs/heads/4.2 from
[~likithas]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9a8ddda ]
Revert "CLOUDSTACK-3715. Socket timeout error is observed in VMware setup if a
VMware task (RelocateVM_Task, CloneVM_Task etc.) takes more than 10 minutes.
Making this value configurable to allow admins to modify the timeout if
required. It defaults to the current value i.e. 10 minutes."
This reverts commit 0a1012817a71245cc65d34fb9adbbd4ec910f9b2.
> Live Migration of Virtual instances operation is getting timedout
> --
>
> Key: CLOUDSTACK-3715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3715
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, VMware
>Affects Versions: 4.2.0
>Reporter: Sailaja Mada
>Assignee: Likitha Shetty
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: 195113management-server.log.gz,
> 195117management-server.log.gz, apilog.log, cloud-backup.dmp.gz,
> cloud-backup.sql.gz, management-server.log, migrationlogs.rar
>
>
> Setup: Multinode Management setup.
> Steps:
> 1. Configure Adv Zone with 2 VMWARE clusters each with one hosts with Zone
> wide primary storage ( Standard vSwitch cluster)
> 2. Deploy VM using User account
> 3. Tried to Live migrate VM from cluster1 (host 1) to Cluster 2 (host2 )
> Observation:
> 1. Migration took very log time and finally failed saying operation timed out
> :
> 2013-07-22 17:46:06,288 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-40:job-133 = [ 4a2f6d84-236d-4bdd-a2e5-72fa336e0274 ]) VM state
> transitted from :Migrating to Running with event: OperationFailedvm's
> original host id: 4 new host id: 4 host id before state transition: 1
> 2013-07-22 17:46:06,292 INFO [vmware.resource.VmwareResource]
> (DirectAgent-421:10.102.192.18) VM i-4-9-VM is no longer in vSphere
> 2013-07-22 17:46:06,293 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-421:null) Seq 1-1311245319: Response Received:
> 2013-07-22 17:46:06,294 DEBUG [agent.transport.Request]
> (DirectAgent-421:null) Seq 1-1311245319: Processing: { Ans: , MgmtId:
> 94838926819810, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.StopAnswer":{"vncPort":0,"result":true,"details":"VM
> i-4-9-VM is no longer in vSphere","wait":0}}] }
> 2013-07-22 17:46:06,294 DEBUG [agent.manager.AgentAttache]
> (DirectAgent-421:null) Seq 1-1311245319: Unable to find listener.
> 2013-07-22 17:46:06,307 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-40:job-133 = [ 4a2f6d84-236d-4bdd-a2e5-72fa336e0274 ]) Hosts's
> actual total CPU: 9572 and CPU after applying overprovisioning: 9572
> 2013-07-22 17:46:06,307 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-40:job-133 = [ 4a2f6d84-236d-4bdd-a2e5-72fa336e0274 ]) Hosts's
> actual total RAM: 17166258176 and RAM after applying overprovisioning:
> 17166258176
> 2013-07-22 17:46:06,307 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-40:job-133 = [ 4a2f6d84-236d-4bdd-a2e5-72fa336e0274 ]) release
> cpu from host: 1, old used: 2000,reserved: 0, actual total: 9572, total with
> overprovisioning: 9572; new used: 200,reserved:0; movedfromreserved:
> false,moveToReserveredfalse
> 2013-07-22 17:46:06,307 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-40:job-133 = [ 4a2f6d84-236d-4bdd-a2e5-72fa336e0274 ]) release
> mem from host: 1, old used: 2013265920,reserved: 0, total: 17166258176; new
> used: 2013265920,reserved:0; movedfromreserved: false,moveToReserveredfalse
> 2013-07-22 17:46:06,345 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-40:job-133 = [ 4a2f6d84-236d-4bdd-a2e5-72fa336e0274 ])
> Unexpected exception while executing
> org.apache.cloudstack.api.command.admin.vm.MigrateVirtualMachineWithVolumeCmd
> com.cloud.utils.exception.CloudRuntimeException: Failed to migrated vm
> VM[User|newuser1i1] along with its volumes.
> com.cloud.exception.AgentUnavailableException: Resource [Host:1] is
> unreachable: Host 1: Operation timed out on storage motion for
> VM[User|newuser1i1]
> at
> com.cloud.storage.VolumeManagerImpl.migrateVolumes(VolumeManagerImpl.java:2263)
> at
> com.cloud.vm.VirtualMachineManagerImpl.migrateWithStorage(VirtualMachineManagerImpl.java:1780)
> at
> com.cloud.vm.UserVmManagerImpl.migrateVirtualMachineWithVolume(UserVmManagerImpl.java:4046)
> at
> com.cl
[jira] [Commented] (CLOUDSTACK-4550) [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have migration work
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814945#comment-13814945
]
hayou commented on CLOUDSTACK-4550:
---
not really Wei Zhou ;).
I have the same error on my management :
{quote}
2013-11-06 16:02:15,989 ERROR [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-163:job-399 = [ a47926cf-d712-4bc1-926b-3a8ac43d9e40 ]) Unable to
migrate due to Cannot get interface MTU on 'brbond0.110-110': No such device
{quote}
I type /usr/bin/cloudstack-agent-upgrade on my 2 hypervisors then reboot.
Here is my agent properties :
{quote}
guest.network.device=cloudVirBr100
workers=5
private.network.device=cloudVirBr100
port=8250
resource=com.cloud.hypervisor.kvm.resource.LibvirtComputingResource
pod=1
network.bridge.name.schema=3.0
zone=1
guid=8b928279-d5af-30a9-bc27-6e872a065372
cluster=1
public.network.device=cloudVirBrPub
local.storage.uuid=9342a19c-7822-4a4b-9e83-543742528a81
domr.scripts.dir=scripts/network/domr/kvm
host=172.
LibvirtComputingResource.id=4
{quote}
> [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have
> migration work
> --
>
> Key: CLOUDSTACK-4550
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4550
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Doc, KVM, Upgrade
>Affects Versions: 4.2.0
>Reporter: Prasanna Santhanam
>Priority: Critical
> Attachments: bridge.jpg
>
>
> See CLOUDSTACK-4405 for the original bug. This is the doc to be prepared as
> part of upgrade in release notes once the fix for the bug is verified to work
> After network bridges being renamed from cloudVirBrVLAN to brem1-VLAN to
> support the same VLAN on multiple physical networks the migration of VMs from
> hosts prior the upgrade to the ones added after the upgrade will fail.
> In order to fix this rename the bridges is required to allow migration to
> work.
> This can be done by running the cloudstack-agent-upgrade script. The original
> bug is still undergoing testing, but these are the initial instructions
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4036) UI remains in procesing state and queryAsyncJobResult geting called repeatedly for scaleSystemVm
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814954#comment-13814954 ] Tomasz Zieba commented on CLOUDSTACK-4036: -- The same situation but in another environment: - CitrixXen 6.2 - CloudStack 4.2 Process: live migration systemvm's (routers, secondary vm, console proxy) to another host. Live migration has been done properly but UI never shows that task is finished. Example logs: 2013-11-06 16:03:15,894 DEBUG [cloud.api.ApiServlet] (catalina-exec-24:null) ===END=== 172.16.5.107 -- GET command=queryAsyncJobResult&jobId=dfef21c0-9f20-4aca-87ff-0b736e5e1088&response=json&sessionkey=%2Fm5C3Az7CTH5ZCK2%2FW9znaOOE3w%3D&_=1383750202498 2013-11-06 16:03:18,871 DEBUG [cloud.api.ApiServlet] (catalina-exec-3:null) ===START=== 172.16.5.107 -- GET command=queryAsyncJobResult&jobId=dfef21c0-9f20-4aca-87ff-0b736e5e1088&response=json&sessionkey=%2Fm5C3Az7CTH5ZCK2%2FW9znaOOE3w%3D&_=1383750205498 2013-11-06 16:03:18,892 DEBUG [cloud.async.AsyncJobManagerImpl] (catalina-exec-3:null) Async job-35 = [ dfef21c0-9f20-4aca-87ff-0b736e5e1088 ] completed 2013-11-06 16:03:18,900 DEBUG [cloud.api.ApiServlet] (catalina-exec-3:null) ===END=== 172.16.5.107 -- GET command=queryAsyncJobResult&jobId=dfef21c0-9f20-4aca-87ff-0b736e5e1088&response=json&sessionkey=%2Fm5C3Az7CTH5ZCK2%2FW9znaOOE3w%3D&_=1383750205498 2013-11-06 16:03:21,865 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null) ===START=== 172.16.5.107 -- GET command=queryAsyncJobResult&jobId=dfef21c0-9f20-4aca-87ff-0b736e5e1088&response=json&sessionkey=%2Fm5C3Az7CTH5ZCK2%2FW9znaOOE3w%3D&_=1383750208498 2013-11-06 16:03:21,887 DEBUG [cloud.async.AsyncJobManagerImpl] (catalina-exec-1:null) Async job-35 = [ dfef21c0-9f20-4aca-87ff-0b736e5e1088 ] completed 2013-11-06 16:03:21,895 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null) ===END=== 172.16.5.107 -- GET command=queryAsyncJobResult&jobId=dfef21c0-9f20-4aca-87ff-0b736e5e1088&response=json&sessionkey=%2Fm5C3Az7CTH5ZCK2%2FW9znaOOE3w%3D&_=1383750208498 2013-11-06 16:03:24,872 DEBUG [cloud.api.ApiServlet] (catalina-exec-4:null) ===START=== 172.16.5.107 -- GET command=queryAsyncJobResult&jobId=dfef21c0-9f20-4aca-87ff-0b736e5e1088&response=json&sessionkey=%2Fm5C3Az7CTH5ZCK2%2FW9znaOOE3w%3D&_=1383750211498 2013-11-06 16:03:24,893 DEBUG [cloud.async.AsyncJobManagerImpl] (catalina-exec-4:null) Async job-35 = [ dfef21c0-9f20-4aca-87ff-0b736e5e1088 ] completed 2013-11-06 16:03:24,901 DEBUG [cloud.api.ApiServlet] (catalina-exec-4:null) ===END=== 172.16.5.107 -- GET command=queryAsyncJobResult&jobId=dfef21c0-9f20-4aca-87ff-0b736e5e1088&response=json&sessionkey=%2Fm5C3Az7CTH5ZCK2%2FW9znaOOE3w%3D&_=1383750211498 2013-11-06 16:03:27,871 DEBUG [cloud.api.ApiServlet] (catalina-exec-5:null) ===START=== 172.16.5.107 -- GET command=queryAsyncJobResult&jobId=dfef21c0-9f20-4aca-87ff-0b736e5e1088&response=json&sessionkey=%2Fm5C3Az7CTH5ZCK2%2FW9znaOOE3w%3D&_=1383750214498 2013-11-06 16:03:27,892 DEBUG [cloud.async.AsyncJobManagerImpl] (catalina-exec-5:null) Async job-35 = [ dfef21c0-9f20-4aca-87ff-0b736e5e1088 ] completed 2013-11-06 16:03:27,902 DEBUG [cloud.api.ApiServlet] (catalina-exec-5:null) ===END=== 172.16.5.107 -- GET command=queryAsyncJobResult&jobId=dfef21c0-9f20-4aca-87ff-0b736e5e1088&response=json&sessionkey=%2Fm5C3Az7CTH5ZCK2%2FW9znaOOE3w%3D&_=1383750214498 2013-11-06 16:03:30,879 DEBUG [cloud.api.ApiServlet] (catalina-exec-6:null) ===START=== 172.16.5.107 -- GET command=queryAsyncJobResult&jobId=dfef21c0-9f20-4aca-87ff-0b736e5e1088&response=json&sessionkey=%2Fm5C3Az7CTH5ZCK2%2FW9znaOOE3w%3D&_=1383750217498 2013-11-06 16:03:30,901 DEBUG [cloud.async.AsyncJobManagerImpl] (catalina-exec-6:null) Async job-35 = [ dfef21c0-9f20-4aca-87ff-0b736e5e1088 ] completed 2013-11-06 16:03:30,910 DEBUG [cloud.api.ApiServlet] (catalina-exec-6:null) ===END=== 172.16.5.107 -- GET command=queryAsyncJobResult&jobId=dfef21c0-9f20-4aca-87ff-0b736e5e1088&response=json&sessionkey=%2Fm5C3Az7CTH5ZCK2%2FW9znaOOE3w%3D&_=1383750217498 > UI remains in procesing state and queryAsyncJobResult geting called > repeatedly for scaleSystemVm > > > Key: CLOUDSTACK-4036 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4036 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra >Priority: Critical > Fix For: 4.2.1 > > Attachments: Logs_DB.rar, screenshot-1.jpg > > > Steps to reproduce > == > 1-preapre a CS setup with esxi5.1 > 2-create a SO for ssvm > 3-try scale up ssvm > Expected > -- > UI should not b
[jira] [Commented] (CLOUDSTACK-4550) [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have migration work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814956#comment-13814956 ] Wei ZHOU commented on CLOUDSTACK-4550: -- The guest.network.device and private.network.device should be something like cloudbr0 or cloudbr1 Please follow the official documents. 2013/11/6 hayou (JIRA) > [DOC] When upgrading KVM agents to 4.2(.1?) perform bridge renaming to have > migration work > -- > > Key: CLOUDSTACK-4550 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4550 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc, KVM, Upgrade >Affects Versions: 4.2.0 >Reporter: Prasanna Santhanam >Priority: Critical > Attachments: bridge.jpg > > > See CLOUDSTACK-4405 for the original bug. This is the doc to be prepared as > part of upgrade in release notes once the fix for the bug is verified to work > After network bridges being renamed from cloudVirBrVLAN to brem1-VLAN to > support the same VLAN on multiple physical networks the migration of VMs from > hosts prior the upgrade to the ones added after the upgrade will fail. > In order to fix this rename the bridges is required to allow migration to > work. > This can be done by running the cloudstack-agent-upgrade script. The original > bug is still undergoing testing, but these are the initial instructions -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5060) [Monitoring] verify shared networks VR for monitoring service
Jayapal Reddy created CLOUDSTACK-5060: - Summary: [Monitoring] verify shared networks VR for monitoring service Key: CLOUDSTACK-5060 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5060 Project: CloudStack Issue Type: Sub-task Security Level: Public (Anyone can view this level - this is the default.) Components: Network Devices Affects Versions: 4.3.0 Reporter: Jayapal Reddy Assignee: Jayapal Reddy Fix For: 4.3.0 Test and incorporate changes if needed for shared networks. The code changes should work for shared network with minor changes. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5023) Deleting Port Forwarding Rule fails when generating usage events are enabled
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815001#comment-13815001
]
David Grizzanti commented on CLOUDSTACK-5023:
-
Should this get merged into master as well?
> Deleting Port Forwarding Rule fails when generating usage events are enabled
>
>
> Key: CLOUDSTACK-5023
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5023
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.2.0
>Reporter: David Grizzanti
>Assignee: David Grizzanti
> Fix For: 4.1.1, Future
>
>
> When generating usage events are enabled (using RabbitMQEventBus bean
> configuration), deleting a port forwarding rule fails to delete the rule.
> What you see as a response from the API call is:
> { "queryasyncjobresultresponse" :
> {"accountid":"3f91b297-26e4-11e3-96f6-9e300504069a","userid":"3f91e743-26e4-11e3-96f6-9e300504069a","cmd":"org.apache.cloudstack.api.command.user.firewall.DeletePortForwardingRuleCmd","jobstatus":2,"jobprocstatus":0,"jobresultcode":530,"jobresulttype":"object","jobresult":{"errorcode":530,"errortext":"Command
> failed due to Internal Server
> Error"},"created":"2013-11-01T11:31:02-0400","jobid":"a82a2ecb-2bcd-4f86-9d40-c4c9f0d85f6f"}
> }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CLOUDSTACK-1579) List view widget: Support actions on multiple rows
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Federle updated CLOUDSTACK-1579: -- Issue Type: Improvement (was: New Feature) > List view widget: Support actions on multiple rows > -- > > Key: CLOUDSTACK-1579 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1579 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Brian Federle >Assignee: Brian Federle > Fix For: 4.3.0 > > Attachments: Screen Shot 2013-08-30 at 8.46.11 AM.png, Screen Shot > 2013-08-30 at 8.46.29 AM.png, Screen Shot 2013-08-30 at 8.46.36 AM.png > > Original Estimate: 144h > Remaining Estimate: 144h > > Currently, actions can only be executed manually, 1 row at a time. Need to > implement ability to select multiple list view items, and perform actions on > them at once: > -Adds checkboxes to the left side of the list view > -If 1 or more rows are checked, adds toolbar menu under table header with > supported actions to apply to all selected rows > Technical requirements: > -Need design for new layout and UX for executing multi-row actions > -Refactor list view widget code to support selection of multiple list items, > and passing multiple items of data to API call code. > -Change API calls to support multiple row objects passed though the context > object, in all sections where it is useful: > -- Instances page > -- Events/alerts (for deleting multiple events/alerts) > -- Storage page > -- etc. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5061) Cloudstack doesn't consider storage overprovisioning factor when using thin Provisioning over VMWare VMFS datastores
Sateesh Chodapuneedi created CLOUDSTACK-5061: Summary: Cloudstack doesn't consider storage overprovisioning factor when using thin Provisioning over VMWare VMFS datastores Key: CLOUDSTACK-5061 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5061 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.0 Reporter: Sateesh Chodapuneedi Assignee: Sateesh Chodapuneedi Fix For: 4.2.1 Cloudstack does not let us to create new VMs as it cannot calculate a free space correctly when using Thin Provisioning with VMware. It calculates space from the size of the volumes rather then what is truly utilized on the SAN. DETAILS === 1. DB mysql> select p.name, p.pool_type, p.used_bytes, p.capacity_bytes, sum(v.size) as volumes_allocated from volumes v join storage_pool p on v.pool_id=p.id where v.removed is null group by v.pool_id; - name pool_type used_bytes capacity_bytes volumes_allocated - PrimaryStorage1 VMFS 804432904192 1023812829184 940446842880 PrimaryStorage2 VMFS 901673648128 1023812829184 347791687680 - 2 rows in set (0.01 sec) 2. vCenter reports as the datastore size, storage allocated, and storage used Capacity : 953.50GB Provisioned Space : 944.76GB Free Space : 751.60GB -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (CLOUDSTACK-4964) Cisco VNMC: Nexus password gets logged in MS logs during guest n/w implementation with VNMC provider
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sailaja Mada closed CLOUDSTACK-4964.
This is fixed now.Hence closing the bug.
2013-11-06 22:58:01,102 DEBUG [agent.transport.Request] (Job-Executor-25:job-25
= [ 8aa81287-dd33-4c5c-a523-8ac583c6b170 ]) Seq 2-665059331: Sending { Cmd ,
MgmtId: 94838926819810, via: 2, Ver: v1, Flags: 100011,
[{"com.cloud.agent.api.ConfigureNexusVsmForAsaCommand":{"_vlanId":785,"_ipAddress":"10.0.0.1","_vsmUsername":"admin","_vsmIp":"10.102.192.72","_asaInPortProfile":"asa-in","wait":0}}]
}
2013-11-06 22:58:01,103 DEBUG [agent.transport.Request] (Job-Executor-25:job-25
= [ 8aa81287-dd33-4c5c-a523-8ac583c6b170 ]) Seq 2-665059331: Executing: { Cmd ,
MgmtId: 94838926819810, via: 2, Ver: v1, Flags: 100011,
[{"com.cloud.agent.api.ConfigureNexusVsmForAsaCommand":{"_vlanId":785,"_ipAddress":"10.0.0.1","_vsmUsername":"admin","_vsmIp":"10.102.192.72","_asaInPortProfile":"asa-in","wait":0}}]
}
2013-11-06 22:58:01,103 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-290:null) Seq 2-665059331: Executing request
> Cisco VNMC: Nexus password gets logged in MS logs during guest n/w
> implementation with VNMC provider
>
>
> Key: CLOUDSTACK-4964
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4964
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller
>Affects Versions: 4.2.0
>Reporter: Koushik Das
>Assignee: Koushik Das
> Fix For: 4.2.1
>
>
> Setup : Advanced Networking with VMWARE Nexus, ASA firewall
> Steps:
> 1. Create Guest Network with Cisco VNMC provider
> 3. Try to deploy VM using this guest network.
> Observation:
> 1. During network implementation, CS tries to create Vservice node and
> updates the inside port profile.
> 2. Nexus credentails are logged in clear text while updating inside port
> profile with Vservice node
> 2013-05-27 11:07:21,138 DEBUG [agent.transport.Request]
> (catalina-exec-6:null) Seq 5-1442250786: Sending { Cmd , MgmtId:
> 214053811722752, via: 5, Ver: v1, Flags: 100011,
> [{"ConfigureNexusVsmForAsaCommand":{"_vlanId":809,"_ipAddress":"10.0.64.1","_vsmUsername":"admin","_vsmPassword":"Freebsd@123","_vsmIp":"10.102.192.71","_asaInPortProfile":"asa-in","wait":0}}]
> }
> 2013-05-27 11:07:21,138 DEBUG [agent.transport.Request]
> (catalina-exec-6:null) Seq 5-1442250786: Executing: { Cmd , MgmtId:
> 214053811722752, via: 5, Ver: v1, Flags: 100011,
> [{"ConfigureNexusVsmForAsaCommand":{"_vlanId":809,"_ipAddress":"10.0.64.1","_vsmUsername":"admin","_vsmPassword":"Freebsd@123","_vsmIp":"10.102.192.71","_asaInPortProfile":"asa-in","wait":0}}]
> }
> 2013-05-27 11:07:21,138 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-146:null) Seq 5-1442250786: Executing request
> 2013-05-27 11:07:21,317 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-11:null) Ping from 3
> 2013-05-27 11:07:21,505 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-13:null) Ping from 4
> 2013-05-27 11:07:21,727 DEBUG [network.resource.CiscoVnmcResource]
> (DirectAgent-146:null) Connected to Cisco VSM 10.102.192.71
> 2013-05-27 11:07:23,747 DEBUG [network.resource.CiscoVnmcResource]
> (DirectAgent-146:null) Created vservice node for ASA appliance in Cisco VSM
> for vlan 809
> 2013-05-27 11:07:26,918 DEBUG [network.resource.CiscoVnmcResource]
> (DirectAgent-146:null) Updated inside port profile for ASA appliance in Cisco
> VSM with new vlan 809
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5061) Cloudstack doesn't consider storage overprovisioning factor when using thin Provisioning over VMWare VMFS datastores
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-5061: - Priority: Critical (was: Major) > Cloudstack doesn't consider storage overprovisioning factor when using thin > Provisioning over VMWare VMFS datastores > > > Key: CLOUDSTACK-5061 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5061 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.0 >Reporter: Sateesh Chodapuneedi >Assignee: Sateesh Chodapuneedi >Priority: Critical > Fix For: 4.2.1 > > > Cloudstack does not let us to create new VMs as it cannot calculate a free > space correctly when using Thin Provisioning with VMware. It calculates space > from the size of the volumes rather then what is truly utilized on the SAN. > DETAILS > === > 1. DB > mysql> select p.name, p.pool_type, p.used_bytes, p.capacity_bytes, > sum(v.size) as volumes_allocated from volumes v join storage_pool p on > v.pool_id=p.id where v.removed is null group by v.pool_id; > - > name pool_type used_bytes capacity_bytes volumes_allocated > - > PrimaryStorage1 VMFS 804432904192 1023812829184 940446842880 > PrimaryStorage2 VMFS 901673648128 1023812829184 347791687680 > - > 2 rows in set (0.01 sec) > 2. vCenter reports as the datastore size, storage allocated, and storage used > Capacity : 953.50GB > Provisioned Space : 944.76GB > Free Space : 751.60GB -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-904) CloudStack export the CPU as a socket not core
[ https://issues.apache.org/jira/browse/CLOUDSTACK-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815060#comment-13815060 ] Arnaud G commented on CLOUDSTACK-904: - Seems that the problem was closed for Xen (see CLOUDSTACK-3501) but for KVM there is no progress. This feature is critical in order to have Windows server with more than 4 cores. The lack of export of a correct topology is a blocking point. It is currently not possible to create "big" (more than for 4 cores/socket) Windows Server VM on Cloudstack+KVM Should we close this and reopen a feature request? > CloudStack export the CPU as a socket not core > -- > > Key: CLOUDSTACK-904 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-904 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: pre-4.0.0, 4.0.0 >Reporter: Ahmad Saif > > I've a VM that's running (Windows 2008 Standard R2 64bit) which was working > on a 4 cores offer. when I upgraded the service offer to 8 cores and checked > the VM I noticed that it still have only 4 cores !! > I dig a little bit on the windows machine itself, and found that it see the > CPUs as sockets not cores and this version of windows support only up to 4 > cores. > when I checked the vm XML file on the host I saw that the CPU is exported as > following : > 8 > and it should be exported as following: > 1 > > > otherwise in such systems where you are limited with the sockets number you > cannot have the required service offer. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (CLOUDSTACK-4688) UCS:UI: queryAsyncJobResult keeps getting fired upon an unsuccessfull profile association
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Parth Jagirdar closed CLOUDSTACK-4688.
--
Verified.
> UCS:UI: queryAsyncJobResult keeps getting fired upon an unsuccessfull profile
> association
> -
>
> Key: CLOUDSTACK-4688
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4688
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UCS, UI
>Affects Versions: 4.2.1
>Reporter: Parth Jagirdar
>Assignee: frank zhang
> Attachments: UCS-UI_Query.png
>
>
> 2013-09-16 14:33:04,801 DEBUG [cloud.api.ApiServlet] (catalina-exec-15:null)
> ===START=== 10.215.2.19 -- GET
> command=queryAsyncJobResult&jobId=cb17e5c3-64a4-4c37-bdf7-e03cdadeb618&response=json&sessionkey=K1TUaBBWENJHygmfpHhm0sdUeSo%
> 3D&_=1379368164145
> 2013-09-16 14:33:04,811 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-15:null) Async job-13 = [ cb17e5c3-64a4-4c37-bdf7-e03cdadeb618
> ] completed
> 2013-09-16 14:33:04,815 DEBUG [cloud.api.ApiServlet] (catalina-exec-15:null)
> ===END=== 10.215.2.19 -- GET
> command=queryAsyncJobResult&jobId=cb17e5c3-64a4-4c37-bdf7-e03cdadeb618&response=json&sessionkey=K1TUaBBWENJHygmfpHhm0sdUeSo%3D
> &_=1379368164145
> 2013-09-16 14:33:07,174 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-15:null) SeqA 3-1252: Processing Seq 3-1252: { Cmd ,
> MgmtId: -1, via: 3, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{
> "_proxyVmId":2,"_loadInfo":"{\n \"connections\": []\n}","wait":0}}] }
> 2013-09-16 14:33:07,179 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-15:null) SeqA 3-1252: Sending Seq 3-1252: { Ans: ,
> MgmtId: 6788531356733, via: 3, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer"
> :{"result":true,"wait":0}}] }
> 2013-09-16 14:33:07,876 DEBUG [cloud.api.ApiServlet] (catalina-exec-24:null)
> ===START=== 10.215.2.19 -- GET
> command=queryAsyncJobResult&jobId=cb17e5c3-64a4-4c37-bdf7-e03cdadeb618&response=json&sessionkey=K1TUaBBWENJHygmfpHhm0sdUeSo%
> 3D&_=1379368167154
> 2013-09-16 14:33:07,885 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-24:null) Async job-13 = [ cb17e5c3-64a4-4c37-bdf7-e03cdadeb618
> ] completed
> 2013-09-16 14:33:07,888 DEBUG [cloud.api.ApiServlet] (catalina-exec-24:null)
> ===END=== 10.215.2.19 -- GET
> command=queryAsyncJobResult&jobId=cb17e5c3-64a4-4c37-bdf7-e03cdadeb618&response=json&sessionkey=K1TUaBBWENJHygmfpHhm0sdUeSo%3D
> &_=1379368167154
> 2013-09-16 14:33:10,834 DEBUG [cloud.api.ApiServlet] (catalina-exec-17:null)
> ===START=== 10.215.2.19 -- GET
> command=queryAsyncJobResult&jobId=cb17e5c3-64a4-4c37-bdf7-e03cdadeb618&response=json&sessionkey=K1TUaBBWENJHygmfpHhm0sdUeSo%
> 3D&_=1379368170178
> 2013-09-16 14:33:10,844 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-17:null) Async job-13 = [ cb17e5c3-64a4-4c37-bdf7-e03cdadeb618
> ] completed
> 2013-09-16 14:33:10,848 DEBUG [cloud.api.ApiServlet] (catalina-exec-17:null)
> ===END=== 10.215.2.19 -- GET
> command=queryAsyncJobResult&jobId=cb17e5c3-64a4-4c37-bdf7-e03cdadeb618&response=json&sessionkey=K1TUaBBWENJHygmfpHhm0sdUeSo%3D
> &_=1379368170178
> 2013-09-16 14:33:13,952 DEBUG [cloud.api.ApiServlet] (catalina-exec-5:null)
> ===START=== 10.215.2.19 -- GET
> command=queryAsyncJobResult&jobId=cb17e5c3-64a4-4c37-bdf7-e03cdadeb618&response=json&sessionkey=K1TUaBBWENJHygmfpHhm0sdUeSo%3
> D&_=1379368173208
> 2013-09-16 14:33:13,961 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-5:null) Async job-13 = [ cb17e5c3-64a4-4c37-bdf7-e03cdadeb618
> ] completed
> 2013-09-16 14:33:13,964 DEBUG [cloud.api.ApiServlet] (catalina-exec-5:null)
> ===END=== 10.215.2.19 -- GET
> command=queryAsyncJobResult&jobId=cb17e5c3-64a4-4c37-bdf7-e03cdadeb618&response=json&sessionkey=K1TUaBBWENJHygmfpHhm0sdUeSo%3D&
> _=1379368173208
> 2013-09-16 14:33:15,862 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-2:null) Ping from 4
> 2013-09-16 14:33:16,921 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null)
> ===START=== 10.215.2.19 -- GET
> command=queryAsyncJobResult&jobId=cb17e5c3-64a4-4c37-bdf7-e03cdadeb618&response=json&sessionkey=K1TUaBBWENJHygmfpHhm0sdUeSo%3
> D&_=1379368176233
> 2013-09-16 14:33:16,930 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-1:null) Async job-13 = [ cb17e5c3-64a4-4c37-bdf7-e03cdadeb618
> ] completed
> 2013-09-16 14:33:16,933 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null)
> ===END=== 10.215.2.19 -- GET
> command=queryAsyncJobResult&jobId=cb17e5c3-64a4-4c37-bdf7-e03cdadeb618&response=json&sessionkey=K1TUaBBWENJHygmfpHhm0sdUeSo%3D&
> _=1379368176233
> 2013
[jira] [Closed] (CLOUDSTACK-3285) UCS: Need support for HTTP redirects and HTTPS Certificate handling
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar closed CLOUDSTACK-3285. -- Assignee: (was: Amogh Vasekar) Verified. > UCS: Need support for HTTP redirects and HTTPS Certificate handling > --- > > Key: CLOUDSTACK-3285 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3285 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UCS >Affects Versions: 4.2.0 > Environment: Master; Basic Bare-metal and UCS >Reporter: Parth Jagirdar >Priority: Critical > Fix For: 4.2.1 > > > By default UCS has HTTP to HTTPs redirect enabled. > At which point, addUcsManager fails with following error. > 2013-06-28 14:19:57,020 DEBUG [cloud.api.ApiServlet] (catalina-exec-20:null) > ===START=== 10.217.252.127 -- GET > command=addUcsManager&zoneid=d92cc843-8c50-4f57-9c07-1041bf859f8d&name=ucsmanager&url=10.223.184.2&username=admin&response=json&sessionkey=NiAtOI4sZHTkTJ37Y4jz0ntaeYg%3D&_=1372454390205 > 2013-06-28 14:19:57,256 WARN [cloudstack.api.AddUcsManagerCmd] > (catalina-exec-20:null) Exception: > com.cloud.utils.exception.CloudRuntimeException: Cannot get cookie > at > com.cloud.ucs.manager.UcsManagerImpl.getCookie(UcsManagerImpl.java:174) > at > com.cloud.ucs.manager.UcsManagerImpl.listBlades(UcsManagerImpl.java:179) > at > com.cloud.ucs.manager.UcsManagerImpl.discoverBlades(UcsManagerImpl.java:123) > at > com.cloud.ucs.manager.UcsManagerImpl.addUcsManager(UcsManagerImpl.java:154) > at > org.apache.cloudstack.api.AddUcsManagerCmd.execute(AddUcsManagerCmd.java:68) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:528) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:371) > at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:304) > 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:2268) > 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) > Caused by: com.cloud.utils.exception.CloudRuntimeException: Call failed: > > > 302 Found > > Found > The document has moved https://10.223.184.2/nuova";>here. > > at com.cloud.ucs.manager.UcsHttpClient.call(UcsHttpClient.java:50) > at > com.cloud.ucs.manager.UcsManagerImpl.getCookie(UcsManagerImpl.java:166) > ... 26 more > Caused by: com.cloud.utils.exception.CloudRuntimeException: Call failed: > > > 302 Found > > Found > The document has moved https://10.223.184.2/nuova";>here. > > at com.cloud.ucs.manager.UcsHttpClient.call(UcsHttpClient.java:41) > ... 27 more > 2013-06-28 14:19:57,257 INFO [cloud.api.ApiServer] (catalina-exec-20:null) > Cannot get cookie > 2013-06-28 14:19:57,258 DEBUG [cloud.api.ApiServlet] (catalina-exec-20:null) > ===END=== 10.217.252.127 -- GET > command=addUcsManager&zoneid=d92cc843-8c50-4f57-9c07-1041bf859f8d&name=ucsmanager&url=10.223.184.2&username=admin&response=json&sessionkey=NiAtOI4sZHTkTJ37Y4jz0ntaeYg%3D&_=1372454390205 > 2013-06-28 14:20:02,479 DEBUG [cloud.server.StatsCollector] > (StatsCollector-2:null) HostStat
[jira] [Commented] (CLOUDSTACK-5061) Cloudstack doesn't consider storage overprovisioning factor when using thin Provisioning over VMWare VMFS datastores
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815066#comment-13815066 ] ASF subversion and git services commented on CLOUDSTACK-5061: - Commit 2210f1b0e49f15bfba4ec613546d69977003 in branch refs/heads/4.2 from [~sateeshc] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2210f1b ] CLOUDSTACK-5061 - Cloudstack doesn't consider storage overprovisioning factor when using thin Provisioning over VMWare VMFS datastores Fix is use the storage overprovisioning factor (global configuration parameter "storage.overprovisioning.factor") to calculate total provisioning capacity for storage space allocation over VMFS based storage pools as well. There are two level of thin provisioning provided in VMware, storage level and file-level (VMDK) thin provisioning. in CloudStack, all volumes are provisioned with thin VMDK format, so at hypervisor level, we ALWAYS do thin provisioning. If storage vendor has the ability to provide storage level thin provisioning in addition to VMDK thin provisioning, it is also allowed since it is transparent to Cloudstack. Signed-off-by: Sateesh Chodapuneedi > Cloudstack doesn't consider storage overprovisioning factor when using thin > Provisioning over VMWare VMFS datastores > > > Key: CLOUDSTACK-5061 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5061 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.0 >Reporter: Sateesh Chodapuneedi >Assignee: Sateesh Chodapuneedi >Priority: Critical > Fix For: 4.2.1 > > > Cloudstack does not let us to create new VMs as it cannot calculate a free > space correctly when using Thin Provisioning with VMware. It calculates space > from the size of the volumes rather then what is truly utilized on the SAN. > DETAILS > === > 1. DB > mysql> select p.name, p.pool_type, p.used_bytes, p.capacity_bytes, > sum(v.size) as volumes_allocated from volumes v join storage_pool p on > v.pool_id=p.id where v.removed is null group by v.pool_id; > - > name pool_type used_bytes capacity_bytes volumes_allocated > - > PrimaryStorage1 VMFS 804432904192 1023812829184 940446842880 > PrimaryStorage2 VMFS 901673648128 1023812829184 347791687680 > - > 2 rows in set (0.01 sec) > 2. vCenter reports as the datastore size, storage allocated, and storage used > Capacity : 953.50GB > Provisioned Space : 944.76GB > Free Space : 751.60GB -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5061) Cloudstack doesn't consider storage overprovisioning factor when using thin Provisioning over VMWare VMFS datastores
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi resolved CLOUDSTACK-5061. -- Resolution: Fixed > Cloudstack doesn't consider storage overprovisioning factor when using thin > Provisioning over VMWare VMFS datastores > > > Key: CLOUDSTACK-5061 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5061 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.0 >Reporter: Sateesh Chodapuneedi >Assignee: Sateesh Chodapuneedi >Priority: Critical > Fix For: 4.2.1 > > > Cloudstack does not let us to create new VMs as it cannot calculate a free > space correctly when using Thin Provisioning with VMware. It calculates space > from the size of the volumes rather then what is truly utilized on the SAN. > DETAILS > === > 1. DB > mysql> select p.name, p.pool_type, p.used_bytes, p.capacity_bytes, > sum(v.size) as volumes_allocated from volumes v join storage_pool p on > v.pool_id=p.id where v.removed is null group by v.pool_id; > - > name pool_type used_bytes capacity_bytes volumes_allocated > - > PrimaryStorage1 VMFS 804432904192 1023812829184 940446842880 > PrimaryStorage2 VMFS 901673648128 1023812829184 347791687680 > - > 2 rows in set (0.01 sec) > 2. vCenter reports as the datastore size, storage allocated, and storage used > Capacity : 953.50GB > Provisioned Space : 944.76GB > Free Space : 751.60GB -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5062) Deleting Load Balancing Rule fails when generating usage events are enabled
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815073#comment-13815073 ] David Grizzanti commented on CLOUDSTACK-5062: - After looking into this, it appears the same as CLOUDSTACK-5023 as I stated above, will submit a patch. > Deleting Load Balancing Rule fails when generating usage events are enabled > --- > > Key: CLOUDSTACK-5062 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5062 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: David Grizzanti >Assignee: David Grizzanti > > When generating usage events are enabled (using RabbitMQEventBus bean > configuration), deleting a load balancing rule fails to delete the rule. > This is almost identical to CLOUDSTACK-5023 (except that was for port > forwarding) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5062) Deleting Load Balancing Rule fails when generating usage events are enabled
David Grizzanti created CLOUDSTACK-5062: --- Summary: Deleting Load Balancing Rule fails when generating usage events are enabled Key: CLOUDSTACK-5062 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5062 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: David Grizzanti Assignee: David Grizzanti When generating usage events are enabled (using RabbitMQEventBus bean configuration), deleting a load balancing rule fails to delete the rule. This is almost identical to CLOUDSTACK-5023 (except that was for port forwarding) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5061) Cloudstack doesn't consider storage overprovisioning factor when using thin Provisioning over VMWare VMFS datastores
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815081#comment-13815081 ] ASF subversion and git services commented on CLOUDSTACK-5061: - Commit 40a78393235f44bb0f96b8055fc11139c8866915 in branch refs/heads/master from [~sateeshc] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=40a7839 ] CLOUDSTACK-5061 - Cloudstack doesn't consider storage overprovisioning factor when using thin Provisioning over VMWare VMFS datastores Fix is use the storage overprovisioning factor (global configuration parameter "storage.overprovisioning.factor") to calculate total provisioning capacity for storage space allocation over VMFS based storage pools as well. There are two level of thin provisioning provided in VMware, storage level and file-level (VMDK) thin provisioning. in CloudStack, all volumes are provisioned with thin VMDK format, so at hypervisor level, we ALWAYS do thin provisioning. If storage vendor has the ability to provide storage level thin provisioning in addition to VMDK thin provisioning, it is also allowed since it is transparent to Cloudstack. Signed-off-by: Sateesh Chodapuneedi > Cloudstack doesn't consider storage overprovisioning factor when using thin > Provisioning over VMWare VMFS datastores > > > Key: CLOUDSTACK-5061 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5061 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.0 >Reporter: Sateesh Chodapuneedi >Assignee: Sateesh Chodapuneedi >Priority: Critical > Fix For: 4.2.1 > > > Cloudstack does not let us to create new VMs as it cannot calculate a free > space correctly when using Thin Provisioning with VMware. It calculates space > from the size of the volumes rather then what is truly utilized on the SAN. > DETAILS > === > 1. DB > mysql> select p.name, p.pool_type, p.used_bytes, p.capacity_bytes, > sum(v.size) as volumes_allocated from volumes v join storage_pool p on > v.pool_id=p.id where v.removed is null group by v.pool_id; > - > name pool_type used_bytes capacity_bytes volumes_allocated > - > PrimaryStorage1 VMFS 804432904192 1023812829184 940446842880 > PrimaryStorage2 VMFS 901673648128 1023812829184 347791687680 > - > 2 rows in set (0.01 sec) > 2. vCenter reports as the datastore size, storage allocated, and storage used > Capacity : 953.50GB > Provisioned Space : 944.76GB > Free Space : 751.60GB -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (CLOUDSTACK-3672) [Automation] integration.component.test_tags 4 test cases failed due to multiple reasons
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan closed CLOUDSTACK-3672.
---
Not found in latest runs
> [Automation] integration.component.test_tags 4 test cases failed due to
> multiple reasons
> -
>
> Key: CLOUDSTACK-3672
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3672
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, VMware
>Affects Versions: 4.2.0
> Environment: VMWARE
>Reporter: Parth Jagirdar
>Assignee: Prasanna Santhanam
> Attachments: VMware_Adv.7z
>
>
> integration.component.test_tags.TestResourceTags.test_04_vpn_tag (from
> nosetests)
> Failing for the past 1 build (Since #67 )
> Took 21 sec.
> add description
> Error Message
> Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext :
> u'Invalid resource type VPN'}
> >> begin captured logging <<
> testclient.testcase.TestResourceTags: DEBUG: Fetching the network details for
> account: test-DZT1BA
> testclient.testcase.TestResourceTags: DEBUG: Network for the account:
> test-DZT1BA is test-DZT1BA-network
> testclient.testcase.TestResourceTags: DEBUG: Associating public IP for
> network: 5fc01c94-8b7d-4286-9b4f-aee0caa3a961
> testclient.testcase.TestResourceTags: DEBUG: Creating VPN with public NAT IP:
> 10.223.243.14
> testclient.testcase.TestResourceTags: DEBUG: Creating a tag for VPN rule
> - >> end captured logging << -
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
> File "/data/Repo2/qa/cloudstack/test/integration/component/test_tags.py",
> line 785, in test_04_vpn_tag
> tags={'protocol': 'L2TP'}
> File
> "/usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py", line
> 2802, in create
> return Tag(apiclient.createTags(cmd).__dict__)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 2075, in createTags
> response = self.connection.marvin_request(command,
> response_type=response, method=method)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line
> 230, in marvin_request
> response = self.poll(asyncJobId, response_type)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line
> 91, in poll
> "asyncquery", asyncResonse.jobresult)
> Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext :
> u'Invalid resource type VPN'}
> >> begin captured logging <<
> testclient.testcase.TestResourceTags: DEBUG: Fetching the network details for
> account: test-DZT1BA
> testclient.testcase.TestResourceTags: DEBUG: Network for the account:
> test-DZT1BA is test-DZT1BA-network
> testclient.testcase.TestResourceTags: DEBUG: Associating public IP for
> network: 5fc01c94-8b7d-4286-9b4f-aee0caa3a961
> testclient.testcase.TestResourceTags: DEBUG: Creating VPN with public NAT IP:
> 10.223.243.14
> testclient.testcase.TestResourceTags: DEBUG: Creating a tag for VPN rule
> - >> end captured logging << -
> integration.component.test_tags.TestResourceTags.test_06_template_tag (from
> nosetests)
> Failing for the past 1 build (Since #67 )
> Took 1 min 15 sec.
> add description
> Error Message
> Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext :
> u"Failed to create templateCreatePrivateTemplateFromVolumeCommand exception:
> java.lang.Exception: unable to prepare template directory:
> template/tmpl/33/208, storage:
> nfs://10.223.110.232:/export/home/automation/SC-CLOUD-QA03/secondary1, error
> msg: mkdir: cannot create directory
> `/var/cloudstack/mnt/VM/90928106758026.16683e49/template/tmpl/33': Permission
> denied\ncom.cloud.storage.resource.VmwareStorageProcessor.createTemplateFromVolume(VmwareStorageProcessor.java:492)\ncom.cloud.storage.resource.VmwareStorageProcessor.createTemplateFromVolume(VmwareStorageProcessor.java:576)\ncom.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:81)\ncom.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:49)\ncom.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:565)\ncom.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)\njava.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)\njava.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)\n
[jira] [Closed] (CLOUDSTACK-3675) [Automation] TestVMPasswordEnabled>:setup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan closed CLOUDSTACK-3675. --- Not found this issue in latest runs > [Automation] TestVMPasswordEnabled>:setup --- > > Key: CLOUDSTACK-3675 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3675 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Test >Affects Versions: 4.2.0 > Environment: VMWARE >Reporter: Parth Jagirdar >Assignee: Gaurav Aradhye > Fix For: 4.2.0 > > Attachments: VMware_Adv.7z > > > :setup (from nosetests) > Failing for the past 54 builds (Since #14 ) > Took 0 ms. > add description > Error Message > 'small' > Stacktrace > Traceback (most recent call last): > File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 208, in > run > self.setUp() > File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 291, in > setUp > self.setupContext(ancestor) > File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 314, in > setupContext > try_run(context, names) > File "/usr/local/lib/python2.7/site-packages/nose/util.py", line 469, in > try_run > return func() > File > "/data/Repo2/qa/cloudstack/test/integration/component/test_vm_passwdenabled.py", > line 109, in setUpClass > cls.services["small"], > KeyError: 'small' -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (CLOUDSTACK-3676) [Automation] integration.component.test_usage, 2 test cases failed due to setup and permission issue
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan closed CLOUDSTACK-3676.
---
Not found this issue with latest runs
> [Automation] integration.component.test_usage, 2 test cases failed due to
> setup and permission issue
>
>
> Key: CLOUDSTACK-3676
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3676
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, VMware
>Affects Versions: 4.2.0
> Environment: VMWARE
>Reporter: Parth Jagirdar
>Assignee: Rayees Namathponnan
> Attachments: VMware_Adv.7z
>
>
> integration.component.test_usage.TestTemplateUsage.test_01_template_usage
> (from nosetests)
> Failing for the past 4 builds (Since #64 )
> Took 5.3 sec.
> add description
> Error Message
> Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext :
> u"Failed to create templateCreatePrivateTemplateFromVolumeCommand exception:
> java.lang.Exception: unable to prepare template directory:
> template/tmpl/207/226, storage:
> nfs://10.223.110.232:/export/home/automation/SC-CLOUD-QA03/secondary1, error
> msg: mkdir: cannot create directory
> `/var/cloudstack/mnt/VM/90928106758026.16683e49/template/tmpl/207':
> Permission
> denied\ncom.cloud.storage.resource.VmwareStorageProcessor.createTemplateFromVolume(VmwareStorageProcessor.java:492)\ncom.cloud.storage.resource.VmwareStorageProcessor.createTemplateFromVolume(VmwareStorageProcessor.java:576)\ncom.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:81)\ncom.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:49)\ncom.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:565)\ncom.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)\njava.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)\njava.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)\njava.util.concurrent.FutureTask.run(FutureTask.java:166)\njava.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)\njava.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)\njava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)\njava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)\njava.lang.Thread.run(Thread.java:722)\n"}
> Stacktrace
> Traceback (most recent call last):
> File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
> File "/data/Repo2/qa/cloudstack/test/integration/component/test_usage.py",
> line 720, in test_01_template_usage
> self.volume.id
> File
> "/usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py", line
> 793, in create
> return Template(apiclient.createTemplate(cmd).__dict__)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 720, in createTemplate
> response = self.connection.marvin_request(command,
> response_type=response, method=method)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line
> 230, in marvin_request
> response = self.poll(asyncJobId, response_type)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line
> 91, in poll
> "asyncquery", asyncResonse.jobresult)
> cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode :
> 530, errortext : u"Failed to create
> templateCreatePrivateTemplateFromVolumeCommand exception:
> java.lang.Exception: unable to prepare template directory:
> template/tmpl/207/226, storage:
> nfs://10.223.110.232:/export/home/automation/SC-CLOUD-QA03/secondary1, error
> msg: mkdir: cannot create directory
> `/var/cloudstack/mnt/VM/90928106758026.16683e49/template/tmpl/207':
> Permission
> denied\ncom.cloud.storage.resource.VmwareStorageProcessor.createTemplateFromVolume(VmwareStorageProcessor.java:492)\ncom.cloud.storage.resource.VmwareStorageProcessor.createTemplateFromVolume(VmwareStorageProcessor.java:576)\ncom.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:81)\ncom.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:49)\ncom.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:565)\ncom.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.ja
[jira] [Closed] (CLOUDSTACK-3645) [Automation] test_netscaler_nw_off, 5 test cases failed due to Failed to find OS type with description: Cent OS 5.3 (64 bit)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan closed CLOUDSTACK-3645. --- Not found in latest runs > [Automation] test_netscaler_nw_off, 5 test cases failed due to Failed to find > OS type with description: Cent OS 5.3 (64 bit) > > > Key: CLOUDSTACK-3645 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3645 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.2.0 > Environment: KVM >Reporter: Parth Jagirdar >Assignee: Sowmya Krishnan > Attachments: KVM_Advanced.zip > > > :setup (from > nosetests) > Failing for the past 78 builds (Since #9 ) > Took 10 sec. > add description > Error Message > Failed to find OS type with description: Cent OS 5.3 (64 bit) > Stacktrace > Traceback (most recent call last): > File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 208, in > run > self.setUp() > File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 291, in > setUp > self.setupContext(ancestor) > File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 314, in > setupContext > try_run(context, names) > File "/usr/local/lib/python2.7/site-packages/nose/util.py", line 469, in > try_run > return func() > File > "/Repo_30X/ipcl/cloudstack/test/integration/component/test_netscaler_nw_off.py", > line 532, in setUpClass > cls.services["ostype"] > File > "/usr/local/lib/python2.7/site-packages/marvin/integration/lib/common.py", > line 120, in get_template > "Failed to find OS type with description: %s" % ostype) > Exception: Failed to find OS type with description: Cent OS 5.3 (64 bit > :setup (from nosetests) > Failing for the past 78 builds (Since #9 ) > Took 10 sec. > add description > Error Message > Failed to find OS type with description: Cent OS 5.3 (64 bit) > Stacktrace > Traceback (most recent call last): > File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 208, in > run > self.setUp() > File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 291, in > setUp > self.setupContext(ancestor) > File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 314, in > setupContext > try_run(context, names) > File "/usr/local/lib/python2.7/site-packages/nose/util.py", line 469, in > try_run > return func() > File > "/Repo_30X/ipcl/cloudstack/test/integration/component/test_netscaler_nw_off.py", > line 1983, in setUpClass > cls.services["ostype"] > File > "/usr/local/lib/python2.7/site-packages/marvin/integration/lib/common.py", > line 120, in get_template > "Failed to find OS type with description: %s" % ostype) > Exception: Failed to find OS type with description: Cent OS 5.3 (64 bit) > :setup (from > nosetests) > Failing for the past 78 builds (Since #9 ) > Took 10 sec. > add description > Error Message > Failed to find OS type with description: Cent OS 5.3 (64 bit) > Stacktrace > Traceback (most recent call last): > File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 208, in > run > self.setUp() > File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 291, in > setUp > self.setupContext(ancestor) > File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 314, in > setupContext > try_run(context, names) > File "/usr/local/lib/python2.7/site-packages/nose/util.py", line 469, in > try_run > return func() > File > "/Repo_30X/ipcl/cloudstack/test/integration/component/test_netscaler_nw_off.py", > line 1089, in setUpClass > cls.services["ostype"] > File > "/usr/local/lib/python2.7/site-packages/marvin/integration/lib/common.py", > line 120, in get_template > "Failed to find OS type with description: %s" % ostype) > Exception: Failed to find OS type with description: Cent OS 5.3 (64 bit) > and few more... -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (CLOUDSTACK-3678) [Automation] integration.component.test_shared_networks 7 test cases failed due to multiple reasons
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan closed CLOUDSTACK-3678.
---
> [Automation] integration.component.test_shared_networks 7 test cases failed
> due to multiple reasons
> ---
>
> Key: CLOUDSTACK-3678
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3678
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.2.0
> Environment: VMWARE
>Reporter: Parth Jagirdar
>Assignee: Prasanna Santhanam
>Priority: Critical
> Attachments: VMware_Adv.7z
>
>
> integration.component.test_shared_networks.TestSharedNetworks.test_createSharedNetwork_All
> (from nosetests)
> Failing for the past 4 builds (Since #64 )
> Took 2 min 42 sec.
> add description
> Error Message
> Warning: Exception during cleanup : Execute cmd: deletenetworkoffering
> failed, due to: errorCode: 431, errorText:Can't delete network offering 20 as
> its used by 1 networks. To make the network offering unavaiable, disable it
> >> begin captured logging <<
> testclient.testcase.TestSharedNetworks: DEBUG: Admin type account created:
> admin-XABU1-SED3BB
> testclient.testcase.TestSharedNetworks: DEBUG: User type account created:
> admin-XABU1-5MP8O4
> testclient.testcase.TestSharedNetworks: DEBUG: Physical network found:
> 3a53fe96-e86f-403a-b69b-4b3aa14a920f
> testclient.testcase.TestSharedNetworks: DEBUG: Shared Network offering
> created: 0133b118-b653-4648-841b-30812b982bf4
> testclient.testcase.TestSharedNetworks: DEBUG: Shared Network created for
> scope domain: 7dbe5de8-d6b0-434b-806f-8dae05190b96
> testclient.testcase.TestSharedNetworks: DEBUG: Virtual Machine created:
> fb678c5e-975a-4ec3-b581-177bdaab949f
> testclient.testcase.TestSharedNetworks: DEBUG: Virtual Machine created:
> f3cf9a22-8d6f-4e5b-b900-ca79ae645efe
> - >> end captured logging << -
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 345, in run
> self.tearDown()
> File
> "/data/Repo2/qa/cloudstack/test/integration/component/test_shared_networks.py",
> line 202, in tearDown
> raise Exception("Warning: Exception during cleanup : %s" % e)
> Warning: Exception during cleanup : Execute cmd: deletenetworkoffering
> failed, due to: errorCode: 431, errorText:Can't delete network offering 20 as
> its used by 1 networks. To make the network offering unavaiable, disable it
> >> begin captured logging <<
> testclient.testcase.TestSharedNetworks: DEBUG: Admin type account created:
> admin-XABU1-SED3BB
> testclient.testcase.TestSharedNetworks: DEBUG: User type account created:
> admin-XABU1-5MP8O4
> testclient.testcase.TestSharedNetworks: DEBUG: Physical network found:
> 3a53fe96-e86f-403a-b69b-4b3aa14a920f
> testclient.testcase.TestSharedNetworks: DEBUG: Shared Network offering
> created: 0133b118-b653-4648-841b-30812b982bf4
> testclient.testcase.TestSharedNetworks: DEBUG: Shared Network created for
> scope domain: 7dbe5de8-d6b0-434b-806f-8dae05190b96
> testclient.testcase.TestSharedNetworks: DEBUG: Virtual Machine created:
> fb678c5e-975a-4ec3-b581-177bdaab949f
> testclient.testcase.TestSharedNetworks: DEBUG: Virtual Machine created:
> f3cf9a22-8d6f-4e5b-b900-ca79ae645efe
> - >> end captured logging << -
> integration.component.test_shared_networks.TestSharedNetworks.test_createSharedNetwork_accountSpecific
> (from nosetests)
> Failing for the past 4 builds (Since #64 )
> Took 0.63 sec.
> add description
> Error Message
> Execute cmd: createnetwork failed, due to: errorCode: 431, errorText:There is
> a isolated/shared network with vlan id: 1200 already exists in zone 1
> >> begin captured logging <<
> testclient.testcase.TestSharedNetworks: DEBUG: Admin type account created:
> admin-XABU1-YWLITU
> testclient.testcase.TestSharedNetworks: DEBUG: User type account created:
> admin-XABU1-OCV65Q
> testclient.testcase.TestSharedNetworks: DEBUG: Physical Network found:
> 3a53fe96-e86f-403a-b69b-4b3aa14a920f
> testclient.testcase.TestSharedNetworks: DEBUG: Shared Network Offering
> created: f2c5f051-8731-47bd-9f45-ce8240282d87
> - >> end captured logging << -
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
> File
> "/data/Repo2/qa/cloudstack/test/integration/component/test_shared_networks.py",
> line 1033, in test_createSharedNetwork_accountSpecific
> zoneid
[jira] [Commented] (CLOUDSTACK-3675) [Automation] TestVMPasswordEnabled>:setup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815106#comment-13815106 ] Sudha Ponnaganti commented on CLOUDSTACK-3675: -- I am OOO from 11/04 through 11/08. Accessible through email. > [Automation] TestVMPasswordEnabled>:setup --- > > Key: CLOUDSTACK-3675 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3675 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Test >Affects Versions: 4.2.0 > Environment: VMWARE >Reporter: Parth Jagirdar >Assignee: Gaurav Aradhye > Fix For: 4.2.0 > > Attachments: VMware_Adv.7z > > > :setup (from nosetests) > Failing for the past 54 builds (Since #14 ) > Took 0 ms. > add description > Error Message > 'small' > Stacktrace > Traceback (most recent call last): > File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 208, in > run > self.setUp() > File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 291, in > setUp > self.setupContext(ancestor) > File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 314, in > setupContext > try_run(context, names) > File "/usr/local/lib/python2.7/site-packages/nose/util.py", line 469, in > try_run > return func() > File > "/data/Repo2/qa/cloudstack/test/integration/component/test_vm_passwdenabled.py", > line 109, in setUpClass > cls.services["small"], > KeyError: 'small' -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4736) Monitering services in virtual router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815128#comment-13815128 ] Animesh Chaturvedi commented on CLOUDSTACK-4736: Should this issue be resolved now? > Monitering services in virtual router > - > > Key: CLOUDSTACK-4736 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4736 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Reporter: Jayapal Reddy >Assignee: Jayapal Reddy > Fix For: 4.3.0 > > > The feature is about monitoring all the services rendered by the virtual > router, ensure that the services are running through the life time of the VR. > On service failure: > 1. Generate an alert and event indicating failure > 2. Restart the service > Services to be monitored: > DHCP, DNS, haproxy, password server etc. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4938) Add account password confirmation broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815136#comment-13815136 ] Brian Federle commented on CLOUDSTACK-4938: --- Ian, I think the issue may be that there are 2 different forms that are conditionally shown. Do you know if both forms are present in the DOM? If so, if they both have password fields then the validation may be conflicting. Maybe double check that is the case first. > Add account password confirmation broken > > > Key: CLOUDSTACK-4938 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4938 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 >Reporter: Brian Federle >Assignee: Ian Duffy >Priority: Blocker > Fix For: 4.3.0 > > > Currently the password confirmation field is not validating, even if the > confirmation value is correct. The validation needs to be fixed, otherwise > the add account dialog will not execute. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (CLOUDSTACK-4938) Add account password confirmation broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815136#comment-13815136 ] Brian Federle edited comment on CLOUDSTACK-4938 at 11/6/13 6:45 PM: Ian, I think the issue may be that there are 2 different forms that are conditionally shown. Do you know if both forms are present in the DOM? If so, if they both have password fields then the validation may be conflicting. Maybe double check that is/isn't the case first. was (Author: bfederle): Ian, I think the issue may be that there are 2 different forms that are conditionally shown. Do you know if both forms are present in the DOM? If so, if they both have password fields then the validation may be conflicting. Maybe double check that is the case first. > Add account password confirmation broken > > > Key: CLOUDSTACK-4938 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4938 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 >Reporter: Brian Federle >Assignee: Ian Duffy >Priority: Blocker > Fix For: 4.3.0 > > > Currently the password confirmation field is not validating, even if the > confirmation value is correct. The validation needs to be fixed, otherwise > the add account dialog will not execute. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4938) Add account password confirmation broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815164#comment-13815164 ] Brian Federle commented on CLOUDSTACK-4938: --- Also, with the latest master see if you are even able to reproduce the issue anymore. It seems to be working for me. > Add account password confirmation broken > > > Key: CLOUDSTACK-4938 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4938 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 >Reporter: Brian Federle >Assignee: Ian Duffy >Priority: Blocker > Fix For: 4.3.0 > > > Currently the password confirmation field is not validating, even if the > confirmation value is correct. The validation needs to be fixed, otherwise > the add account dialog will not execute. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5023) Deleting Port Forwarding Rule fails when generating usage events are enabled
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815166#comment-13815166
]
David Grizzanti commented on CLOUDSTACK-5023:
-
Will test on master and submit a separate patch.
> Deleting Port Forwarding Rule fails when generating usage events are enabled
>
>
> Key: CLOUDSTACK-5023
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5023
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.2.0
>Reporter: David Grizzanti
>Assignee: David Grizzanti
> Fix For: 4.1.1, Future
>
>
> When generating usage events are enabled (using RabbitMQEventBus bean
> configuration), deleting a port forwarding rule fails to delete the rule.
> What you see as a response from the API call is:
> { "queryasyncjobresultresponse" :
> {"accountid":"3f91b297-26e4-11e3-96f6-9e300504069a","userid":"3f91e743-26e4-11e3-96f6-9e300504069a","cmd":"org.apache.cloudstack.api.command.user.firewall.DeletePortForwardingRuleCmd","jobstatus":2,"jobprocstatus":0,"jobresultcode":530,"jobresulttype":"object","jobresult":{"errorcode":530,"errortext":"Command
> failed due to Internal Server
> Error"},"created":"2013-11-01T11:31:02-0400","jobid":"a82a2ecb-2bcd-4f86-9d40-c4c9f0d85f6f"}
> }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Issue Comment Deleted] (CLOUDSTACK-5023) Deleting Port Forwarding Rule fails when generating usage events are enabled
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Grizzanti updated CLOUDSTACK-5023:
Comment: was deleted
(was: Should this get merged into master as well?)
> Deleting Port Forwarding Rule fails when generating usage events are enabled
>
>
> Key: CLOUDSTACK-5023
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5023
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.2.0
>Reporter: David Grizzanti
>Assignee: David Grizzanti
> Fix For: 4.1.1, Future
>
>
> When generating usage events are enabled (using RabbitMQEventBus bean
> configuration), deleting a port forwarding rule fails to delete the rule.
> What you see as a response from the API call is:
> { "queryasyncjobresultresponse" :
> {"accountid":"3f91b297-26e4-11e3-96f6-9e300504069a","userid":"3f91e743-26e4-11e3-96f6-9e300504069a","cmd":"org.apache.cloudstack.api.command.user.firewall.DeletePortForwardingRuleCmd","jobstatus":2,"jobprocstatus":0,"jobresultcode":530,"jobresulttype":"object","jobresult":{"errorcode":530,"errortext":"Command
> failed due to Internal Server
> Error"},"created":"2013-11-01T11:31:02-0400","jobid":"a82a2ecb-2bcd-4f86-9d40-c4c9f0d85f6f"}
> }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5048) UI shouldn't show AutoScale button when setting up LB using Virtual Router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815200#comment-13815200 ] ASF subversion and git services commented on CLOUDSTACK-5048: - Commit 5e9dea1fc59b87f12dcac98b5d41d89d63fd2d55 in branch refs/heads/4.2 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5e9dea1 ] CLOUDSTACK-5048: UI > VPC section > Create Load Balancing rule > hide Autoscale button since Autoscale is not supported in VPC. > UI shouldn't show AutoScale button when setting up LB using Virtual Router > --- > > Key: CLOUDSTACK-5048 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5048 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Jessica Wang >Assignee: Jessica Wang > Fix For: 4.2.1 > > > AutoScale is only supported on Netscaler, but not on Virtual Router. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (CLOUDSTACK-4938) Add account password confirmation broken
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815208#comment-13815208
]
Ian Duffy edited comment on CLOUDSTACK-4938 at 11/6/13 7:42 PM:
Hi Brian,
Just took a quick look there.
At first It seemed to be working based on your first comment.
However after messing about with it a bit more I can see the issue. You were
correct about the ID being duplicated within the DOM.
If you click on "Add Account" and then hit cancel a input field of id password
is inserted onto the DOM. It does not disappear on cancel. On opening the "Add
Account" screen again and launching document.querySelectorAll("#password");
from my javascript console it reveals that there are now two boxes matching id
password. Again, on hitting cancel results in a clone of accounts-wizard being
inserted.
The zone-wizard and instance wizard clone themselves as well.
was (Author: imduffy15):
Hi Brian,
Just took a quick look there.
At first It seemed to be working based on your first comment.
However after messing about with it a bit more I can see the issue. You were
correct about the ID being duplicated within the DOM.
If you click on "Add Account" and then hit cancel a input field of id password
is inserted onto the DOM. It does not disappear on cancel. On opening the "Add
Account" screen again and launching document.querySelectorAll("#password");
from my javascript console it reveals that there are now two boxes matching id
password. Again, on hitting cancel results in a clone of accounts-wizard being
inserted.
The zone-wizard and instance wizard clone.
> Add account password confirmation broken
>
>
> Key: CLOUDSTACK-4938
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4938
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.3.0
>Reporter: Brian Federle
>Assignee: Ian Duffy
>Priority: Blocker
> Fix For: 4.3.0
>
>
> Currently the password confirmation field is not validating, even if the
> confirmation value is correct. The validation needs to be fixed, otherwise
> the add account dialog will not execute.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4938) Add account password confirmation broken
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815208#comment-13815208
]
Ian Duffy commented on CLOUDSTACK-4938:
---
Hi Brian,
Just took a quick look there.
At first It seemed to be working based on your first comment.
However after messing about with it a bit more I can see the issue. You were
correct about the ID being duplicated within the DOM.
If you click on "Add Account" and then hit cancel a input field of id password
is inserted onto the DOM. It does not disappear on cancel. On opening the "Add
Account" screen again and launching document.querySelectorAll("#password");
from my javascript console it reveals that there are now two boxes matching id
password. Again, on hitting cancel results in a clone of accounts-wizard being
inserted.
The zone-wizard and instance wizard clone.
> Add account password confirmation broken
>
>
> Key: CLOUDSTACK-4938
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4938
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.3.0
>Reporter: Brian Federle
>Assignee: Ian Duffy
>Priority: Blocker
> Fix For: 4.3.0
>
>
> Currently the password confirmation field is not validating, even if the
> confirmation value is correct. The validation needs to be fixed, otherwise
> the add account dialog will not execute.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CLOUDSTACK-5063) [Automation] Compute offering should not shown in disk offering section
Rayees Namathponnan created CLOUDSTACK-5063:
---
Summary: [Automation] Compute offering should not shown in disk
offering section
Key: CLOUDSTACK-5063
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5063
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: VMware, Volumes
Affects Versions: 4.3.0
Environment: vmware
build : master
Reporter: Rayees Namathponnan
Fix For: 4.3.0
Steps to reproduce
Step 1 : Deploy advanced zone with master build
Step 2 : Create compute offering "TestComputeOffer"
Step 3 : Select Disk offering from UI
Actual Result
Bunch of exception trough here, and compute offering "TestComputeOffer"
showing in disk offering selection, getting below error if you select
"TestComputeOffer"
Status
Unable to execute API command listdiskofferings due to invalid value. Invalid
parameter id value=e20a534c-90d3-41ac-97a1-3c950eca5026 due to incorrect long
value format, or entity does not exist or due to incorrect parameter annotation
for the field in api cmd class.
Firebug logs
curl
'http://10.223.49.197:8080/client/api?command=listDiskOfferings&response=json&sessionkey=053%2FqCLYjvx8EaEpzqaVwy1I9gg%3D&id=e20a534c-90d3-41ac-97a1-3c950eca5026&_=1383767126407'
-H 'Host: 10.223.49.197:8080' -H 'User-Agent: Mozilla/5.0 (Windows NT 6.1;
WOW64; rv:24.0) Gecko/20100101 Firefox/24.0' -H 'Accept: application/json,
text/javascript, */*; q=0.01' -H 'Accept-Language: en-US,en;q=0.5' -H
'Accept-Encoding: gzip, deflate' -H 'X-Requested-With: XMLHttpRequest' -H
'Referer: http://10.223.49.197:8080/client/' -H 'Cookie:
sessionKey=053%252FqCLYjvx8EaEpzqaVwy1I9gg%253D; username=admin; account=admin;
domainid=7ac0abbc-46fe-11e3-8950-52b2d980df8a; role=1;
userfullname=admin%20cloud; userid=ac94efae-46fe-11e3-8950-52b2d980df8a;
capabilities=%5Bobject%20Object%5D; supportELB=false;
regionsecondaryenabled=false; userpublictemplateenabled=true;
userProjectsEnabled=true; JSESSIONID=90C790837D922F2E6E0E4FFDE95C4982'
{ "listdiskofferingsresponse" :
{"uuidList":[],"errorcode":431,"cserrorcode":,"errortext":"Unable to
execute API command listdiskofferings due to invalid value. Invalid parameter
id value=e20a534c-90d3-41ac-97a1-3c950eca5026 due to incorrect long value
format, or entity does not exist or due to incorrect parameter annotation for
the field in api cmd class."} }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5063) [Automation] Compute offering should not shown in disk offering section
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan updated CLOUDSTACK-5063:
Attachment: CLOUDSTACK-5063.rar
> [Automation] Compute offering should not shown in disk offering section
>
>
> Key: CLOUDSTACK-5063
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5063
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware, Volumes
>Affects Versions: 4.3.0
> Environment: vmware
> build : master
>Reporter: Rayees Namathponnan
> Fix For: 4.3.0
>
> Attachments: CLOUDSTACK-5063.rar
>
>
> Steps to reproduce
> Step 1 : Deploy advanced zone with master build
> Step 2 : Create compute offering "TestComputeOffer"
> Step 3 : Select Disk offering from UI
> Actual Result
> Bunch of exception trough here, and compute offering "TestComputeOffer"
> showing in disk offering selection, getting below error if you select
> "TestComputeOffer"
> Status
> Unable to execute API command listdiskofferings due to invalid value. Invalid
> parameter id value=e20a534c-90d3-41ac-97a1-3c950eca5026 due to incorrect long
> value format, or entity does not exist or due to incorrect parameter
> annotation for the field in api cmd class.
> Firebug logs
>
> curl
> 'http://10.223.49.197:8080/client/api?command=listDiskOfferings&response=json&sessionkey=053%2FqCLYjvx8EaEpzqaVwy1I9gg%3D&id=e20a534c-90d3-41ac-97a1-3c950eca5026&_=1383767126407'
> -H 'Host: 10.223.49.197:8080' -H 'User-Agent: Mozilla/5.0 (Windows NT 6.1;
> WOW64; rv:24.0) Gecko/20100101 Firefox/24.0' -H 'Accept: application/json,
> text/javascript, */*; q=0.01' -H 'Accept-Language: en-US,en;q=0.5' -H
> 'Accept-Encoding: gzip, deflate' -H 'X-Requested-With: XMLHttpRequest' -H
> 'Referer: http://10.223.49.197:8080/client/' -H 'Cookie:
> sessionKey=053%252FqCLYjvx8EaEpzqaVwy1I9gg%253D; username=admin;
> account=admin; domainid=7ac0abbc-46fe-11e3-8950-52b2d980df8a; role=1;
> userfullname=admin%20cloud; userid=ac94efae-46fe-11e3-8950-52b2d980df8a;
> capabilities=%5Bobject%20Object%5D; supportELB=false;
> regionsecondaryenabled=false; userpublictemplateenabled=true;
> userProjectsEnabled=true; JSESSIONID=90C790837D922F2E6E0E4FFDE95C4982'
> { "listdiskofferingsresponse" :
> {"uuidList":[],"errorcode":431,"cserrorcode":,"errortext":"Unable to
> execute API command listdiskofferings due to invalid value. Invalid parameter
> id value=e20a534c-90d3-41ac-97a1-3c950eca5026 due to incorrect long value
> format, or entity does not exist or due to incorrect parameter annotation for
> the field in api cmd class."} }
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-904) CloudStack export the CPU as a socket not core
[ https://issues.apache.org/jira/browse/CLOUDSTACK-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815245#comment-13815245 ] René Diepstraten commented on CLOUDSTACK-904: - That seems good to me. In any case, this should be solved. It requires some discussion about how it should be implemented and, if it should be possible to both configure sockets and cores, may require changes in the gui as well. Therefore a feature request seems a right choice to me. [ https://issues.apache.org/jira/browse/CLOUDSTACK-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815060#comment-13815060] Arnaud G commented on CLOUDSTACK-904: - Seems that the problem was closed for Xen (see CLOUDSTACK-3501) but for KVM there is no progress. This feature is critical in order to have Windows server with more than 4 cores. The lack of export of a correct topology is a blocking point. It is currently not possible to create "big" (more than for 4 cores/socket) Windows Server VM on Cloudstack+KVM Should we close this and reopen a feature request? default.) working on a 4 cores offer. when I upgraded the service offer to 8 cores and checked the VM I noticed that it still have only 4 cores !! the CPUs as sockets not cores and this version of windows support only up to 4 cores. as following : you cannot have the required service offer. -- This message was sent by Atlassian JIRA (v6.1#6144) > CloudStack export the CPU as a socket not core > -- > > Key: CLOUDSTACK-904 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-904 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: pre-4.0.0, 4.0.0 >Reporter: Ahmad Saif > > I've a VM that's running (Windows 2008 Standard R2 64bit) which was working > on a 4 cores offer. when I upgraded the service offer to 8 cores and checked > the VM I noticed that it still have only 4 cores !! > I dig a little bit on the windows machine itself, and found that it see the > CPUs as sockets not cores and this version of windows support only up to 4 > cores. > when I checked the vm XML file on the host I saw that the CPU is exported as > following : > 8 > and it should be exported as following: > 1 > > > otherwise in such systems where you are limited with the sockets number you > cannot have the required service offer. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5037) UI - Pop up a warning message when user is changing over provisioning factor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815247#comment-13815247 ] ASF subversion and git services commented on CLOUDSTACK-5037: - Commit 72156775437c64006db722bbebeca20b8780d2fd in branch refs/heads/4.2 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7215677 ] CLOUDSTACK-5037: UI > Infrastructure > clusters > Settings tab > when "cpu.overprovisioning.factor" or "mem.overprovisioning.factor" is changed, pop up a warning message "Please note - you are changing the over provisioning factor for a cluster with vms running. Please refer to the admin guide to understand the capacity calculation." > UI - Pop up a warning message when user is changing over provisioning factor > > > Key: CLOUDSTACK-5037 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5037 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta >Assignee: Jessica Wang > Fix For: 4.2.1 > > > UI - Pop up a warning message when user is changing cpu/memory over > provisioning factor for cluster and that cluster has vms deployed. Following > should be the message. > "Please note - you are changing the over provisioning factor for a cluster > with vms running. Please refer to the admin guide to understand the capacity > calculation." -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5037) UI - Pop up a warning message when user is changing over provisioning factor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-5037. -- Resolution: Fixed > UI - Pop up a warning message when user is changing over provisioning factor > > > Key: CLOUDSTACK-5037 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5037 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta >Assignee: Jessica Wang > Fix For: 4.2.1 > > > UI - Pop up a warning message when user is changing cpu/memory over > provisioning factor for cluster and that cluster has vms deployed. Following > should be the message. > "Please note - you are changing the over provisioning factor for a cluster > with vms running. Please refer to the admin guide to understand the capacity > calculation." -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5048) UI shouldn't show AutoScale button when setting up LB using Virtual Router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815260#comment-13815260 ] ASF subversion and git services commented on CLOUDSTACK-5048: - Commit ff0bfe209c3f211d57acc2d2b5027bae134b7072 in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ff0bfe2 ] CLOUDSTACK-5048: UI > Create Load Balancing rule > hide Autoscale button if LB provider is not Netscaler since Autoscale is only supported on Netscaler, but not on other provider like VirtualRouter. > UI shouldn't show AutoScale button when setting up LB using Virtual Router > --- > > Key: CLOUDSTACK-5048 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5048 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Jessica Wang >Assignee: Jessica Wang > Fix For: 4.2.1 > > > AutoScale is only supported on Netscaler, but not on Virtual Router. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5048) UI shouldn't show AutoScale button when setting up LB using Virtual Router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815262#comment-13815262 ] ASF subversion and git services commented on CLOUDSTACK-5048: - Commit 2018e1a5880227f76a93503b3b9db4b30e4836a8 in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2018e1a ] CLOUDSTACK-5048: UI > VPC section > Create Load Balancing rule > hide Autoscale button since Autoscale is not supported in VPC. > UI shouldn't show AutoScale button when setting up LB using Virtual Router > --- > > Key: CLOUDSTACK-5048 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5048 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Jessica Wang >Assignee: Jessica Wang > Fix For: 4.2.1 > > > AutoScale is only supported on Netscaler, but not on Virtual Router. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5037) UI - Pop up a warning message when user is changing over provisioning factor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815264#comment-13815264 ] ASF subversion and git services commented on CLOUDSTACK-5037: - Commit 7b44c97a25bdfd715d425a3f952da0fd1628a717 in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7b44c97 ] CLOUDSTACK-5037: UI > Infrastructure > clusters > Settings tab > when "cpu.overprovisioning.factor" or "mem.overprovisioning.factor" is changed, pop up a warning message "Please note - you are changing the over provisioning factor for a cluster with vms running. Please refer to the admin guide to understand the capacity calculation." > UI - Pop up a warning message when user is changing over provisioning factor > > > Key: CLOUDSTACK-5037 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5037 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta >Assignee: Jessica Wang > Fix For: 4.2.1 > > > UI - Pop up a warning message when user is changing cpu/memory over > provisioning factor for cluster and that cluster has vms deployed. Following > should be the message. > "Please note - you are changing the over provisioning factor for a cluster > with vms running. Please refer to the admin guide to understand the capacity > calculation." -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5064) Add a "user preferences" link to ACS UI
John Kinsella created CLOUDSTACK-5064: - Summary: Add a "user preferences" link to ACS UI Key: CLOUDSTACK-5064 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5064 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.2.0 Reporter: John Kinsella Users sometimes are confused on how to change their user/password info within the ACS UI. A "user preferences" link near the top of the page that links to the current user's details page would be useful. Example thread on subject: http://mail-archives.apache.org/mod_mbox/cloudstack-users/201311.mbox/browser -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5049) [Automation] Vm migration failed in kvm with error "Unable to migrate due to Domain not found"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815365#comment-13815365 ] Yoshikazu Nojima commented on CLOUDSTACK-5049: -- It seems this ticket duplicates to CLOUDSTACK-5039, which I reported. I sent ReviewRequest ( https://reviews.apache.org/r/15238/ ). Is there anyone who can review and merge it? > [Automation] Vm migration failed in kvm with error "Unable to migrate due to > Domain not found" > -- > > Key: CLOUDSTACK-5049 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5049 > 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: KVM (rhel 6.3) > branch : 4.3 master >Reporter: Rayees Namathponnan >Priority: Blocker > Fix For: 4.3.0 > > Attachments: CLOUDSTACK-5047.rar > > > Steps to reproduce > 1 ) Create advanced zone with 2host in kvm > 2) Deploy vm on, first host > 3) migrate this vm to another host > Actual result > Host migration failed with below error > reserved:0; movedfromreserved: false,moveToReserveredfalse > 2013-11-05 15:19:31,665 ERROR [c.c.a.ApiAsyncJobDispatcher] > (Job-Executor-133:ctx-58343dc5) Unexpected exception while executing > org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd > com.cloud.utils.exception.CloudRuntimeException: Unable to migrate due to > Domain not found: no domain with matching uuid > 'd55da0aa-4be9-39c5-a83b-c3954b185d84' > at > com.cloud.vm.VirtualMachineManagerImpl.migrate(VirtualMachineManagerImpl.java:1577) > at > com.cloud.vm.VirtualMachineManagerImpl.migrate(VirtualMachineManagerImpl.java:1485) > at > com.cloud.vm.UserVmManagerImpl.migrateVirtualMachine(UserVmManagerImpl.java:4039) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at $Proxy168.migrateVirtualMachine(Unknown Source) > at > org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd.execute(MigrateVMCmd.java:148) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) > at > com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109) > at > com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66) > 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 > com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:520) > 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) >
[jira] [Resolved] (CLOUDSTACK-5038) Upgrade to 4.2 - used cpu is getting bumped up when the over provisioning factor > 1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta resolved CLOUDSTACK-5038. - Resolution: Fixed > Upgrade to 4.2 - used cpu is getting bumped up when the over provisioning > factor > 1 > > > Key: CLOUDSTACK-5038 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5038 > 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 >Assignee: Nitin Mehta > Fix For: 4.2.1 > > > Upgrade to 4.2 - used cpu is getting bumped up when the over provisioning > factor > 1. > Provide a code/sql fix. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (CLOUDSTACK-1749) Used Master Branch System VM Template: Cloud agent service running on Secondary Storage VM and Console Proxy VM is named as cloud.com service
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chandan Purushothama closed CLOUDSTACK-1749. Verified on the 64-bit System VM Template. > Used Master Branch System VM Template: Cloud agent service running on > Secondary Storage VM and Console Proxy VM is named as cloud.com service > - > > Key: CLOUDSTACK-1749 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1749 > 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: Chandan Purushothama >Assignee: Wei Zhou > Fix For: 4.2.1 > > > == > Steps to Reproduce the Bug: > == > Use the system VM Templates present at > http://jenkins.cloudstack.org/view/master/job/build-systemvm-master/lastSuccessfulBuild/artifact/tools/appliance/dist/ > > === > Observations: > =[== > root@s-1-VM:~# service cloud status > cloud.com service (type=secstorage) is running: process id: 3370 > root@s-1-VM:~# > root@v-2-VM:~# service cloud status > cloud.com service (type=consoleproxy) is running: process id: 2966 > root@v-2-VM:~# -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CLOUDSTACK-5065) KVM snapshot doesn't take VM snapshot if the VM is running
edison su created CLOUDSTACK-5065:
-
Summary: KVM snapshot doesn't take VM snapshot if the VM is running
Key: CLOUDSTACK-5065
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5065
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: KVM
Affects Versions: 4.0.0
Reporter: edison su
Assignee: edison su
Priority: Blocker
Fix For: 4.2.1
Due to this line in kvmstorageprocessor:
if (state == DomainInfo.DomainState.VIR_DOMAIN_RUNNING &&
!primaryStorage.isExternalSnapshot()) {
Right now, only primary storage type is filesystem(a.k.a local storage), then
take vm snapshot, otherwise, always take volume snapshot, which is not working
for the default kvm binary.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (CLOUDSTACK-5066) Existed remote access VPN got dropped when adding new VPN users
Sheng Yang created CLOUDSTACK-5066: -- Summary: Existed remote access VPN got dropped when adding new VPN users Key: CLOUDSTACK-5066 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5066 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Sheng Yang Assignee: Sheng Yang Fix For: 4.2.1, 4.3.0 Repro steps: 1. Add a VPN connection 2. Create VPN user 3. Use this user to connect to the created VPN connection 4. Add /delete any other user Bug: VPN connection created in step 3 will be disconnected Expected result: VPN connection should not disconnect when the user with which we have connected is not touched in any ways. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5066) Existed remote access VPN got dropped when adding new VPN users
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang resolved CLOUDSTACK-5066. Resolution: Fixed QA please verify the fix. > Existed remote access VPN got dropped when adding new VPN users > --- > > Key: CLOUDSTACK-5066 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5066 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Sheng Yang >Assignee: Sheng Yang >Priority: Critical > Fix For: 4.2.1, 4.3.0 > > > Repro steps: > 1. Add a VPN connection > 2. Create VPN user > 3. Use this user to connect to the created VPN connection > 4. Add /delete any other user > Bug: > VPN connection created in step 3 will be disconnected > Expected result: > VPN connection should not disconnect when the user with which we have > connected is not touched in any ways. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5066) Existed remote access VPN got dropped when adding new VPN users
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815440#comment-13815440 ] ASF subversion and git services commented on CLOUDSTACK-5066: - Commit 004efe1c0fe0e5cd1a947e7711cd2020d8ae5423 in branch refs/heads/4.2 from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=004efe1 ] CLOUDSTACK-5066: Don't remove the current VPN users when updating If one VPN user and password is existed in current setup, then don't touch it, otherwise would result in this user's existing connection be dropped. > Existed remote access VPN got dropped when adding new VPN users > --- > > Key: CLOUDSTACK-5066 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5066 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Sheng Yang >Assignee: Sheng Yang > Fix For: 4.2.1, 4.3.0 > > > Repro steps: > 1. Add a VPN connection > 2. Create VPN user > 3. Use this user to connect to the created VPN connection > 4. Add /delete any other user > Bug: > VPN connection created in step 3 will be disconnected > Expected result: > VPN connection should not disconnect when the user with which we have > connected is not touched in any ways. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5066) Existed remote access VPN got dropped when adding new VPN users
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang updated CLOUDSTACK-5066: --- Priority: Critical (was: Major) > Existed remote access VPN got dropped when adding new VPN users > --- > > Key: CLOUDSTACK-5066 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5066 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Sheng Yang >Assignee: Sheng Yang >Priority: Critical > Fix For: 4.2.1, 4.3.0 > > > Repro steps: > 1. Add a VPN connection > 2. Create VPN user > 3. Use this user to connect to the created VPN connection > 4. Add /delete any other user > Bug: > VPN connection created in step 3 will be disconnected > Expected result: > VPN connection should not disconnect when the user with which we have > connected is not touched in any ways. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5065) KVM snapshot doesn't take VM snapshot if the VM is running
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815445#comment-13815445
]
ASF subversion and git services commented on CLOUDSTACK-5065:
-
Commit 4f9af26bea0c6d1da915df654b006c9235d1b866 in branch refs/heads/4.2 from
[~edison]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4f9af26 ]
CLOUDSTACK-5065: isExternalSnapshot should return true for CLVM and RBD only
> KVM snapshot doesn't take VM snapshot if the VM is running
> --
>
> Key: CLOUDSTACK-5065
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5065
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.0.0
>Reporter: edison su
>Assignee: edison su
>Priority: Blocker
> Fix For: 4.2.1
>
>
> Due to this line in kvmstorageprocessor:
> if (state == DomainInfo.DomainState.VIR_DOMAIN_RUNNING &&
> !primaryStorage.isExternalSnapshot()) {
> Right now, only primary storage type is filesystem(a.k.a local storage), then
> take vm snapshot, otherwise, always take volume snapshot, which is not
> working for the default kvm binary.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5066) Existed remote access VPN got dropped when adding new VPN users
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815441#comment-13815441 ] ASF subversion and git services commented on CLOUDSTACK-5066: - Commit 27ce69fd556991f8860444c78efd1d329d57f852 in branch refs/heads/master from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=27ce69f ] CLOUDSTACK-5066: Don't remove the current VPN users when updating If one VPN user and password is existed in current setup, then don't touch it, otherwise would result in this user's existing connection be dropped. > Existed remote access VPN got dropped when adding new VPN users > --- > > Key: CLOUDSTACK-5066 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5066 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Sheng Yang >Assignee: Sheng Yang >Priority: Critical > Fix For: 4.2.1, 4.3.0 > > > Repro steps: > 1. Add a VPN connection > 2. Create VPN user > 3. Use this user to connect to the created VPN connection > 4. Add /delete any other user > Bug: > VPN connection created in step 3 will be disconnected > Expected result: > VPN connection should not disconnect when the user with which we have > connected is not touched in any ways. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-5065) KVM snapshot doesn't take VM snapshot if the VM is running
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
edison su resolved CLOUDSTACK-5065.
---
Resolution: Fixed
How to verify the issue:
Without the fix, on the kvm host, it will call managesnapshot.sh to take
snapshot if the primary storage is NFS.
With the fix: it will call libvirt's api to create snapshot, you will see log
message s, like: , in agent.log
> KVM snapshot doesn't take VM snapshot if the VM is running
> --
>
> Key: CLOUDSTACK-5065
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5065
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.0.0
>Reporter: edison su
>Assignee: edison su
>Priority: Blocker
> Fix For: 4.2.1
>
>
> Due to this line in kvmstorageprocessor:
> if (state == DomainInfo.DomainState.VIR_DOMAIN_RUNNING &&
> !primaryStorage.isExternalSnapshot()) {
> Right now, only primary storage type is filesystem(a.k.a local storage), then
> take vm snapshot, otherwise, always take volume snapshot, which is not
> working for the default kvm binary.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Assigned] (CLOUDSTACK-4979) DeployVM: automatically generated hostName is not RFC compliant
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alena Prokharchyk reassigned CLOUDSTACK-4979:
-
Assignee: Alena Prokharchyk (was: Kelven Yang)
> DeployVM: automatically generated hostName is not RFC compliant
> ---
>
> Key: CLOUDSTACK-4979
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4979
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.2.0
>Reporter: Alena Prokharchyk
>Assignee: Alena Prokharchyk
> Fix For: Future
>
>
> When no hostName is passed in to the deployVM call, we generate random UUID.
> But this uuid is not compliant with RFC for the hostName as it always starts
> with the digit. Here are all the rules for the hostName:
> // must be between 1 and 63 characters long and may contain only the ASCII
> letters 'a' through 'z' (in a
> // case-insensitive manner),
> // the digits '0' through '9', and the hyphen ('-').
> // Can not start with a hyphen and digit, and must not end with a
> hyphen
> // If it's a host name, don't allow to start with digit
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Resolved] (CLOUDSTACK-4979) DeployVM: automatically generated hostName is not RFC compliant
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alena Prokharchyk resolved CLOUDSTACK-4979.
---
Resolution: Fixed
Fixed with fac22936f645ee0ca2b8a7cdd0c7fa21e8c35666
> DeployVM: automatically generated hostName is not RFC compliant
> ---
>
> Key: CLOUDSTACK-4979
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4979
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.2.0
>Reporter: Alena Prokharchyk
>Assignee: Alena Prokharchyk
> Fix For: Future
>
>
> When no hostName is passed in to the deployVM call, we generate random UUID.
> But this uuid is not compliant with RFC for the hostName as it always starts
> with the digit. Here are all the rules for the hostName:
> // must be between 1 and 63 characters long and may contain only the ASCII
> letters 'a' through 'z' (in a
> // case-insensitive manner),
> // the digits '0' through '9', and the hyphen ('-').
> // Can not start with a hyphen and digit, and must not end with a
> hyphen
> // If it's a host name, don't allow to start with digit
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4979) DeployVM: automatically generated hostName is not RFC compliant
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815453#comment-13815453
]
ASF subversion and git services commented on CLOUDSTACK-4979:
-
Commit fac22936f645ee0ca2b8a7cdd0c7fa21e8c35666 in branch refs/heads/master
from [~alena1108]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fac2293 ]
CLOUDSTACK-4979: if no hostName is passed to deployVm call, automatically
generated hostName follows the pattern -.
Example: VM-a6c6457e-e4d0-486f-a392-9239be9b36f5
> DeployVM: automatically generated hostName is not RFC compliant
> ---
>
> Key: CLOUDSTACK-4979
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4979
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.2.0
>Reporter: Alena Prokharchyk
>Assignee: Alena Prokharchyk
> Fix For: Future
>
>
> When no hostName is passed in to the deployVM call, we generate random UUID.
> But this uuid is not compliant with RFC for the hostName as it always starts
> with the digit. Here are all the rules for the hostName:
> // must be between 1 and 63 characters long and may contain only the ASCII
> letters 'a' through 'z' (in a
> // case-insensitive manner),
> // the digits '0' through '9', and the hyphen ('-').
> // Can not start with a hyphen and digit, and must not end with a
> hyphen
> // If it's a host name, don't allow to start with digit
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5037) UI - Pop up a warning message when user is changing over provisioning factor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815461#comment-13815461 ] ASF subversion and git services commented on CLOUDSTACK-5037: - Commit fc7489a2813315322766a6dda17cec2e4a7d8130 in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fc7489a ] CLOUDSTACK-5037: UI > Infrastructure > clusters > Settings tab > when "cpu.overprovisioning.factor" or "mem.overprovisioning.factor" is changed, pop up a warning message > change text. > UI - Pop up a warning message when user is changing over provisioning factor > > > Key: CLOUDSTACK-5037 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5037 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta >Assignee: Jessica Wang > Fix For: 4.2.1 > > > UI - Pop up a warning message when user is changing cpu/memory over > provisioning factor for cluster and that cluster has vms deployed. Following > should be the message. > "Please note - you are changing the over provisioning factor for a cluster > with vms running. Please refer to the admin guide to understand the capacity > calculation." -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-5037) UI - Pop up a warning message when user is changing over provisioning factor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815462#comment-13815462 ] ASF subversion and git services commented on CLOUDSTACK-5037: - Commit 7bce498c19e9cf5f1c734d7fa5dccc0948cbeeba in branch refs/heads/4.2 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7bce498 ] CLOUDSTACK-5037: UI > Infrastructure > clusters > Settings tab > when "cpu.overprovisioning.factor" or "mem.overprovisioning.factor" is changed, pop up a warning message > change text. > UI - Pop up a warning message when user is changing over provisioning factor > > > Key: CLOUDSTACK-5037 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5037 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta >Assignee: Jessica Wang > Fix For: 4.2.1 > > > UI - Pop up a warning message when user is changing cpu/memory over > provisioning factor for cluster and that cluster has vms deployed. Following > should be the message. > "Please note - you are changing the over provisioning factor for a cluster > with vms running. Please refer to the admin guide to understand the capacity > calculation." -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4979) DeployVM: automatically generated hostName is not RFC compliant
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815487#comment-13815487
]
ASF subversion and git services commented on CLOUDSTACK-4979:
-
Commit 6d7674982afcd636542f5591b77f704f0b42b379 in branch refs/heads/master
from [~alena1108]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6d76749 ]
CLOUDSTACK-4979: fix hostName for VmWare vms to follow the same logic
> DeployVM: automatically generated hostName is not RFC compliant
> ---
>
> Key: CLOUDSTACK-4979
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4979
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.2.0
>Reporter: Alena Prokharchyk
>Assignee: Alena Prokharchyk
> Fix For: Future
>
>
> When no hostName is passed in to the deployVM call, we generate random UUID.
> But this uuid is not compliant with RFC for the hostName as it always starts
> with the digit. Here are all the rules for the hostName:
> // must be between 1 and 63 characters long and may contain only the ASCII
> letters 'a' through 'z' (in a
> // case-insensitive manner),
> // the digits '0' through '9', and the hyphen ('-').
> // Can not start with a hyphen and digit, and must not end with a
> hyphen
> // If it's a host name, don't allow to start with digit
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CLOUDSTACK-5067) two NICs connected to Public network exist in VR
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yoshikazu Nojima updated CLOUDSTACK-5067:
-
Description:
* "ip addr" output of VR
root@r-7-VM:~# ip addr
1: lo: mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether 02:00:05:6c:00:04 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.1/24 brd 172.16.0.255 scope global eth0
inet6 fe80::5ff:fe6c:4/64 scope link
valid_lft forever preferred_lft forever
3: eth1: mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether 0e:00:a9:fe:00:c1 brd ff:ff:ff:ff:ff:ff
inet 169.254.0.193/16 brd 169.254.255.255 scope global eth1
inet6 fe80::c00:a9ff:fefe:c1/64 scope link
valid_lft forever preferred_lft forever
4: eth2: mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether 06:6a:92:00:00:0d brd ff:ff:ff:ff:ff:ff
inet 198.172.17.243/24 brd 198.172.17.255 scope global eth2
inet6 fe80::46a:92ff:fe00:d/64 scope link
valid_lft forever preferred_lft forever
5: eth3: mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether 06:96:7a:00:00:0d brd ff:ff:ff:ff:ff:ff
inet 198.172.17.243/24 brd 198.172.17.255 scope global eth3
inet6 fe80::496:7aff:fe00:d/64 scope link
valid_lft forever preferred_lft forever
Two NICs connected to Public network exist in VR.
It seems eth3 is unnecessary NIC.
It has same MAC addr as eth2 has. It's weird.
was:
h3. "ip addr" output of VR
{noformat}
root@r-7-VM:~# ip addr
1: lo: mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether 02:00:05:6c:00:04 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.1/24 brd 172.16.0.255 scope global eth0
inet6 fe80::5ff:fe6c:4/64 scope link
valid_lft forever preferred_lft forever
3: eth1: mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether 0e:00:a9:fe:00:c1 brd ff:ff:ff:ff:ff:ff
inet 169.254.0.193/16 brd 169.254.255.255 scope global eth1
inet6 fe80::c00:a9ff:fefe:c1/64 scope link
valid_lft forever preferred_lft forever
4: eth2: mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether 06:6a:92:00:00:0d brd ff:ff:ff:ff:ff:ff
inet 198.172.17.243/24 brd 198.172.17.255 scope global eth2
inet6 fe80::46a:92ff:fe00:d/64 scope link
valid_lft forever preferred_lft forever
5: eth3: mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether 06:96:7a:00:00:0d brd ff:ff:ff:ff:ff:ff
inet 198.172.17.243/24 brd 198.172.17.255 scope global eth3
inet6 fe80::496:7aff:fe00:d/64 scope link
valid_lft forever preferred_lft forever
{noformat}
Two NICs connected to Public network exist in VR.
It seems eth3 is unnecessary NIC.
It has same MAC addr as eth2 has. It's weird.
> two NICs connected to Public network exist in VR
>
>
> Key: CLOUDSTACK-5067
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5067
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.3.0
>Reporter: Yoshikazu Nojima
>Assignee: Yoshikazu Nojima
>
> * "ip addr" output of VR
> root@r-7-VM:~# ip addr
> 1: lo: mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> inet6 ::1/128 scope host
>valid_lft forever preferred_lft forever
> 2: eth0: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 02:00:05:6c:00:04 brd ff:ff:ff:ff:ff:ff
> inet 172.16.0.1/24 brd 172.16.0.255 scope global eth0
> inet6 fe80::5ff:fe6c:4/64 scope link
>valid_lft forever preferred_lft forever
> 3: eth1: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 0e:00:a9:fe:00:c1 brd ff:ff:ff:ff:ff:ff
> inet 169.254.0.193/16 brd 169.254.255.255 scope global eth1
> inet6 fe80::c00:a9ff:fefe:c1/64 scope link
>valid_lft forever preferred_lft forever
> 4: eth2: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 06:6a:92:00:00:0d brd ff:ff:ff:ff:ff:ff
> inet 198.172.17.243/24 brd 198.172.17.255 scope global eth2
> inet6 fe80::46a:92ff:fe00:d/64 scope link
>valid_lft forever preferred_lft forever
> 5: eth3: mtu 1500 qdisc pfifo_fast state UP
> qlen 1000
> link/ether 06:96:7a:00:00:0d brd ff:ff:ff:ff:ff:ff
> inet 198.172.17.243/24 brd 198.172.17.255 scope global eth3
> inet6 fe80::
[jira] [Created] (CLOUDSTACK-5067) two NICs connected to Public network exist in VR
Yoshikazu Nojima created CLOUDSTACK-5067:
Summary: two NICs connected to Public network exist in VR
Key: CLOUDSTACK-5067
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5067
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: KVM
Affects Versions: 4.3.0
Reporter: Yoshikazu Nojima
Assignee: Yoshikazu Nojima
h3. "ip addr" output of VR
{noformat}
root@r-7-VM:~# ip addr
1: lo: mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether 02:00:05:6c:00:04 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.1/24 brd 172.16.0.255 scope global eth0
inet6 fe80::5ff:fe6c:4/64 scope link
valid_lft forever preferred_lft forever
3: eth1: mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether 0e:00:a9:fe:00:c1 brd ff:ff:ff:ff:ff:ff
inet 169.254.0.193/16 brd 169.254.255.255 scope global eth1
inet6 fe80::c00:a9ff:fefe:c1/64 scope link
valid_lft forever preferred_lft forever
4: eth2: mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether 06:6a:92:00:00:0d brd ff:ff:ff:ff:ff:ff
inet 198.172.17.243/24 brd 198.172.17.255 scope global eth2
inet6 fe80::46a:92ff:fe00:d/64 scope link
valid_lft forever preferred_lft forever
5: eth3: mtu 1500 qdisc pfifo_fast state UP
qlen 1000
link/ether 06:96:7a:00:00:0d brd ff:ff:ff:ff:ff:ff
inet 198.172.17.243/24 brd 198.172.17.255 scope global eth3
inet6 fe80::496:7aff:fe00:d/64 scope link
valid_lft forever preferred_lft forever
{noformat}
Two NICs connected to Public network exist in VR.
It seems eth3 is unnecessary NIC.
It has same MAC addr as eth2 has. It's weird.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CLOUDSTACK-4793) Improve VR Upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815497#comment-13815497 ] ASF subversion and git services commented on CLOUDSTACK-4793: - Commit 6916665623135e88f34ff1f8797cf5391911e3cd in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6916665 ] CLOUDSTACK-4793: UI > Infrastructure > Virtual Routers > detail tab > add Requires Upgrade field to reflect new parameter requiresupgrade in API response. > Improve VR Upgrade > -- > > Key: CLOUDSTACK-4793 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4793 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Kishan Kavala > Fix For: 4.3.0 > > > Give admin control to sequence the upgrade of the cloud by: > Infrastructure hierarchy: by Cluster, Pod, and Zone etc. > Administrative hierarchy: by Tenant or Domain > Minimize service interruption to users > Improve the speed of the upgrade time by making as many upgrade operations in > parallel as possible -- This message was sent by Atlassian JIRA (v6.1#6144)
