[jira] [Commented] (CLOUDSTACK-4582) [Upgrade] CloudStack-3.0.2-1-rhel6.2 -> CloudPlatform-4.2.0-1-rhel6.2 FAIL
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13755445#comment-13755445
]
Rajesh Battala commented on CLOUDSTACK-4582:
Error log is:
com.google.gson.JsonParseException: The JsonDeserializer
com.cloud.agent.transport.ArrayTypeAdaptor@80a54d6 failed to deserialize json
object
[{"StartupRoutingCommand":{"cpus":4,"speed":2261,"memory":16713564160,"dom0MinMemory":805306368,"poolSync":false,"vms":{"v-2-VM":{"state":"Running"},"s-1-VM":{"state":"Running"},"i-2-5-VM":{"state":"Running"},"i-2-3-VM":{"state":"Running"},"r-4-VM":{"state":"Running"}},"caps":"hvm,snapshot","pool":"/root","hypervisorType":"KVM","hostDetails":{"com.cloud.network.Networks.RouterPrivateIpStrategy":"HostLocal","Host.OS":"CentOS","Host.OS.Kernel.Version":"2.6.32-220.el6.x86_64","Host.OS.Version":"6.2"},"type":"Routing","dataCenter":"1","pod":"1","cluster":"1","guid":"dd69931f-1a53-359b-9a68-753ae6512880-LibvirtComputingResource","name":"Rack2Host18.lab.vmops.com","id":1,"version":"3.0.2.20120506222956","publicIpAddress":"10.223.51.3","publicNetmask":"255.255.255.192","publicMacAddress":"bc:30:5b:d4:60:af","privateIpAddress":"10.223.51.3","privateMacAddress":"bc:30:5b:d4:60:af","privateNetmask":"255.255.255.192","storageIpAddress":"10.223.51.3","storageNetmask":"255.255.255.192","storageMacAddress":"bc:30:5b:d4:60:af","resourceName":"LibvirtComputingResource","gatewayIpAddress":"10.223.51.1","contextMap":{},"wait":0}},{"StartupStorageCommand":{"totalSize":0,"poolInfo":{"uuid":"83ddb302-5354-4fa6-a894-870aee79bd24","host":"10.223.51.3","localPath":"/var/lib/libvirt/images/","hostPath":"/var/lib/libvirt/images/","poolType":"Filesystem","capacityBytes":227357442048,"availableBytes":2328178688},"resourceType":"STORAGE_POOL","hostDetails":{},"type":"Storage","dataCenter":"1","pod":"1","guid":"dd69931f-1a53-359b-9a68-753ae6512880-LibvirtComputingResource","name":"Rack2Host18.lab.vmops.com","id":1,"version":"3.0.2.20120506222956","resourceName":"LibvirtComputingResource","contextMap":{},"wait":0}}]
given the type class [Lcom.cloud.agent.api.Command;
at
com.google.gson.JsonDeserializerExceptionWrapper.deserialize(JsonDeserializerExceptionWrapper.java:64)
at
com.google.gson.JsonDeserializationVisitor.invokeCustomDeserializer(JsonDeserializationVisitor.java:92)
at
com.google.gson.JsonDeserializationVisitor.visitUsingCustomHandler(JsonDeserializationVisitor.java:80)
at com.google.gson.ObjectNavigator.accept(ObjectNavigator.java:101)
at
com.google.gson.JsonDeserializationContextDefault.fromJsonArray(JsonDeserializationContextDefault.java:67)
at
com.google.gson.JsonDeserializationContextDefault.deserialize(JsonDeserializationContextDefault.java:52)
at com.google.gson.Gson.fromJson(Gson.java:551)
at com.google.gson.Gson.fromJson(Gson.java:498)
at com.cloud.agent.transport.Request.getCommands(Request.java:235)
at
com.cloud.agent.manager.AgentManagerImpl$AgentHandler.processRequest(AgentManagerImpl.java:1195)
at
com.cloud.agent.manager.AgentManagerImpl$AgentHandler.doTask(AgentManagerImpl.java:1348)
at
com.cloud.agent.manager.ClusteredAgentManagerImpl$ClusteredAgentHandler.doTask(ClusteredAgentManagerImpl.java:666)
at com.cloud.utils.nio.Task.run(Task.java:83)
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: can't find
StartupRoutingCommand
at
com.cloud.agent.transport.ArrayTypeAdaptor.deserialize(ArrayTypeAdaptor.java:77)
at
com.cloud.agent.transport.ArrayTypeAdaptor.deserialize(ArrayTypeAdaptor.java:37)
at
com.google.gson.JsonDeserializerExceptionWrapper.deserialize(JsonDeserializerExceptionWrapper.java:51)
... 15 more
2013-08-30 22:22:28,852 WARN [utils.nio.Task] (AgentManager-Handler-2:null)
Caught the following exception but pushing on
com.google.gson.JsonParseException: The JsonDeserializer
com.cloud.agent.transport.ArrayTypeAdaptor@80a54d6 failed to deserialize json
object
[{"StartupRoutingCommand":{"cpus":4,"speed":2261,"memory":16713564160,"dom0MinMemory":805306368,"poolSync":false,"vms":{"v-2-VM":{"state":"Running"},"s-1-VM":{"state":"Running"},"i-2-5-VM":{"state":"Running"},"i-2-3-VM":{"state":"Running"},"r-4-VM":{"state":"Running"}},"caps":"hvm,snapshot","pool":"/root","hypervisorType":"KVM","hostDetails":{"com.cloud.network.Networks.RouterPrivateIpStrategy":"HostLocal","Host.OS":"CentOS","Host.OS.Kernel.Version":"2.6.32-220.el6.x86_64","Host.OS.Version":"6.2"},"type":"Routing","dataCenter":"1","pod":"1","cluster":"1","guid":"dd69931f-1a53-359b-9a68-753ae6512880-LibvirtComputingRes
[jira] [Updated] (CLOUDSTACK-4583) [Upgrade] CloudStack-3.0.4-1-rhel5 -> CloudPlatform-4.2.0-1-rhel5 FAIL
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angeline shen updated CLOUDSTACK-4583: -- Attachment: management-server.log.gz > [Upgrade] CloudStack-3.0.4-1-rhel5 -> CloudPlatform-4.2.0-1-rhel5FAIL > > > Key: CLOUDSTACK-4583 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4583 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 > Environment: MS 10.223.131.181rhel 5 > CloudStack-3.0.4-1-rhel5 > host KVM rhel 6.2 CloudStack-3.0.2-1-rhel6.2 10.223.51.3 > 10.223.51.4 >Reporter: angeline shen >Priority: Critical > Fix For: 4.2.0 > > Attachments: management-server.log.gz > > > ./install.sh > U Failed > --> Processing Dependency: jakarta-commons-daemon-jsvc for package: > cloudstack-usage > --> Processing Dependency: jsvc for package: cloudstack-usage > --> Finished Dependency Resolution > cloudstack-usage-4.2.0-1.el5.x86_64 from cloud-temp has depsolving problems > --> Missing Dependency: jsvc is needed by package > cloudstack-usage-4.2.0-1.el5.x86_64 (cloud-temp) > cloudstack-usage-4.2.0-1.el5.x86_64 from cloud-temp has depsolving problems > --> Missing Dependency: jakarta-commons-daemon-jsvc is needed by package > cloudstack-usage-4.2.0-1.el5.x86_64 (cloud-temp) > cloudstack-management-4.2.0-1.el5.x86_64 from cloud-temp has depsolving > problems > --> Missing Dependency: mysql-connector-java is needed by package > cloudstack-management-4.2.0-1.el5.x86_64 (cloud-temp) > Error: Missing Dependency: mysql-connector-java is needed by package > cloudstack-management-4.2.0-1.el5.x86_64 (cloud-temp) > Error: Missing Dependency: jsvc is needed by package > cloudstack-usage-4.2.0-1.el5.x86_64 (cloud-temp) > Error: Missing Dependency: jakarta-commons-daemon-jsvc is needed by package > cloudstack-usage-4.2.0-1.el5.x86_64 (cloud-temp) > You could try using --skip-broken to work around the problem > You could try running: package-cleanup --problems > package-cleanup --dupes > rpm -Va --nofiles --nodigest > The program package-cleanup is found in the yum-utils package. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4583) [Upgrade] CloudStack-3.0.4-1-rhel5 -> CloudPlatform-4.2.0-1-rhel5 FAIL
angeline shen created CLOUDSTACK-4583: - Summary: [Upgrade] CloudStack-3.0.4-1-rhel5 -> CloudPlatform-4.2.0-1-rhel5FAIL Key: CLOUDSTACK-4583 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4583 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: MS 10.223.131.181rhel 5 CloudStack-3.0.4-1-rhel5 host KVM rhel 6.2 CloudStack-3.0.2-1-rhel6.2 10.223.51.3 10.223.51.4 Reporter: angeline shen Priority: Critical Fix For: 4.2.0 ./install.sh > U Failed --> Processing Dependency: jakarta-commons-daemon-jsvc for package: cloudstack-usage --> Processing Dependency: jsvc for package: cloudstack-usage --> Finished Dependency Resolution cloudstack-usage-4.2.0-1.el5.x86_64 from cloud-temp has depsolving problems --> Missing Dependency: jsvc is needed by package cloudstack-usage-4.2.0-1.el5.x86_64 (cloud-temp) cloudstack-usage-4.2.0-1.el5.x86_64 from cloud-temp has depsolving problems --> Missing Dependency: jakarta-commons-daemon-jsvc is needed by package cloudstack-usage-4.2.0-1.el5.x86_64 (cloud-temp) cloudstack-management-4.2.0-1.el5.x86_64 from cloud-temp has depsolving problems --> Missing Dependency: mysql-connector-java is needed by package cloudstack-management-4.2.0-1.el5.x86_64 (cloud-temp) Error: Missing Dependency: mysql-connector-java is needed by package cloudstack-management-4.2.0-1.el5.x86_64 (cloud-temp) Error: Missing Dependency: jsvc is needed by package cloudstack-usage-4.2.0-1.el5.x86_64 (cloud-temp) Error: Missing Dependency: jakarta-commons-daemon-jsvc is needed by package cloudstack-usage-4.2.0-1.el5.x86_64 (cloud-temp) You could try using --skip-broken to work around the problem You could try running: package-cleanup --problems package-cleanup --dupes rpm -Va --nofiles --nodigest The program package-cleanup is found in the yum-utils package. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4582) [Upgrade] CloudStack-3.0.2-1-rhel6.2 -> CloudPlatform-4.2.0-1-rhel6.2 FAIL
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angeline shen updated CLOUDSTACK-4582: -- Attachment: management-server.log.gz > [Upgrade] CloudStack-3.0.2-1-rhel6.2 -> CloudPlatform-4.2.0-1-rhel6.2 > FAIL > --- > > Key: CLOUDSTACK-4582 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4582 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 > Environment: MS 10.223.195.99 rhel 6.2 > CloudStack-3.0.2-1-rhel6.2 > host rhel 6.2 KVM 10.223.51.3 10.223.51.4 > CloudStack-3.0.2-1-rhel6.2 > upgrade to CloudPlatform-4.2.0-1-rhel6.2 > 1. > M) Install the Management Server > A) Install the Agent > B) Install BareMetal Agent > S) Install the Usage Monitor > U) Upgrade the CloudPlatform packages installed on this computer > R) Stop any running CloudPlatform services and remove the CloudPlatform > packages from this computer > E) Remove the MySQL server (will not remove the MySQL databases) > Q) Quit > > U > Updating the CloudPlatform and its dependencies... > Loaded plugins: fastestmirror, security > Loading mirror speeds from cached hostfile > * base: centos.tcpdiag.net > * extras: mirror.chpc.utah.edu > * updates: yum.phx.singlehop.com > base > | 3.7 kB 00:00 > cloud-temp > | 1.3 kB 00:00 ... > cloud-temp/primary > | 2.4 kB 00:00 ... > cloud-temp > 6/6 > extras > | 3.4 kB 00:00 > rhel > | 4.0 kB 00:00 > updates > | 3.4 kB 00:00 > Setting up Update Process > Resolving Dependencies > --> Running transaction check > ---> Package cloud-client.x86_64 0:3.0.2-1.el6 will be obsoleted > ---> Package cloud-client-ui.x86_64 0:3.0.2-1.el6 will be obsoleted > ---> Package cloud-core.x86_64 0:3.0.2-1.el6 will be obsoleted > ---> Package cloud-daemonize.x86_64 0:3.0.2-1.el6 will be obsoleted > ---> Package cloud-deps.x86_64 0:3.0.2-1.el6 will be obsoleted > ---> Package cloud-python.x86_64 0:3.0.2-1.el6 will be obsoleted > ---> Package cloud-server.x86_64 0:3.0.2-1.el6 will be obsoleted > ---> Package cloud-setup.x86_64 0:3.0.2-1.el6 will be obsoleted > ---> Package cloud-usage.x86_64 0:3.0.2-1.el6 will be obsoleted > ---> Package cloud-utils.x86_64 0:3.0.2-1.el6 will be obsoleted > ---> Package cloudstack-common.x86_64 0:4.2.0-1.el6 will be obsoleting > ---> Package cloudstack-management.x86_64 0:4.2.0-1.el6 will be obsoleting > --> Processing Dependency: cloudstack-awsapi = 4.2.0 for package: > cloudstack-management-4.2.0-1.el6.x86_64 > --> Processing Dependency: mysql-connector-java for package: > cloudstack-management-4.2.0-1.el6.x86_64 > ---> Package cloudstack-usage.x86_64 0:4.2.0-1.el6 will be obsoleting > --> Processing Dependency: jsvc for package: > cloudstack-usage-4.2.0-1.el6.x86_64 > --> Processing Dependency: jakarta-commons-daemon-jsvc for package: > cloudstack-usage-4.2.0-1.el6.x86_64 > --> Running transaction check > ---> Package cloudstack-awsapi.x86_64 0:4.2.0-1.el6 will be installed > ---> Package jakarta-commons-daemon-jsvc.x86_64 1:1.0.1-8.9.el6 will be > installed > ---> Package mysql-connector-java.noarch 1:5.1.17-6.el6 will be installed > --> Processing Dependency: jta >= 1.0 for package: > 1:mysql-connector-java-5.1.17-6.el6.noarch > --> Processing Dependency: slf4j for package: > 1:mysql-connector-java-5.1.17-6.el6.noarch > --> Running transaction check > ---> Package geronimo-specs-compat.noarch 0:1.0-3.5.M2.el6 will be installed > --> Processing Dependency: geronimo-specs = 1.0-3.5.M2.el6 for package: > geronimo-specs-compat-1.0-3.5.M2.el6.noarch > ---> Package slf4j.noarch 0:1.5.8-8.el6 will be installed > --> Running transaction check > ---> Package geronimo-specs.noarch 0:1.0-3.5.M2.el6 will be installed > --> Processing Dependency: apache-tomcat-apis for package: > geronimo-specs-1.0-3.5.M2.el6.noarch > --> Running transaction check > ---> Package apache-tomcat-apis.noarch 0:0.1-1.el6 will be installed > --> Finished Dependency Resolution > Dependencies Resolved > ===
[jira] [Created] (CLOUDSTACK-4582) [Upgrade] CloudStack-3.0.2-1-rhel6.2 -> CloudPlatform-4.2.0-1-rhel6.2 FAIL
angeline shen created CLOUDSTACK-4582: - Summary: [Upgrade] CloudStack-3.0.2-1-rhel6.2 -> CloudPlatform-4.2.0-1-rhel6.2 FAIL Key: CLOUDSTACK-4582 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4582 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: MS 10.223.195.99 rhel 6.2 CloudStack-3.0.2-1-rhel6.2 host rhel 6.2 KVM 10.223.51.3 10.223.51.4 CloudStack-3.0.2-1-rhel6.2 upgrade to CloudPlatform-4.2.0-1-rhel6.2 1. M) Install the Management Server A) Install the Agent B) Install BareMetal Agent S) Install the Usage Monitor U) Upgrade the CloudPlatform packages installed on this computer R) Stop any running CloudPlatform services and remove the CloudPlatform packages from this computer E) Remove the MySQL server (will not remove the MySQL databases) Q) Quit > U Updating the CloudPlatform and its dependencies... Loaded plugins: fastestmirror, security Loading mirror speeds from cached hostfile * base: centos.tcpdiag.net * extras: mirror.chpc.utah.edu * updates: yum.phx.singlehop.com base | 3.7 kB 00:00 cloud-temp | 1.3 kB 00:00 ... cloud-temp/primary | 2.4 kB 00:00 ... cloud-temp 6/6 extras | 3.4 kB 00:00 rhel | 4.0 kB 00:00 updates | 3.4 kB 00:00 Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package cloud-client.x86_64 0:3.0.2-1.el6 will be obsoleted ---> Package cloud-client-ui.x86_64 0:3.0.2-1.el6 will be obsoleted ---> Package cloud-core.x86_64 0:3.0.2-1.el6 will be obsoleted ---> Package cloud-daemonize.x86_64 0:3.0.2-1.el6 will be obsoleted ---> Package cloud-deps.x86_64 0:3.0.2-1.el6 will be obsoleted ---> Package cloud-python.x86_64 0:3.0.2-1.el6 will be obsoleted ---> Package cloud-server.x86_64 0:3.0.2-1.el6 will be obsoleted ---> Package cloud-setup.x86_64 0:3.0.2-1.el6 will be obsoleted ---> Package cloud-usage.x86_64 0:3.0.2-1.el6 will be obsoleted ---> Package cloud-utils.x86_64 0:3.0.2-1.el6 will be obsoleted ---> Package cloudstack-common.x86_64 0:4.2.0-1.el6 will be obsoleting ---> Package cloudstack-management.x86_64 0:4.2.0-1.el6 will be obsoleting --> Processing Dependency: cloudstack-awsapi = 4.2.0 for package: cloudstack-management-4.2.0-1.el6.x86_64 --> Processing Dependency: mysql-connector-java for package: cloudstack-management-4.2.0-1.el6.x86_64 ---> Package cloudstack-usage.x86_64 0:4.2.0-1.el6 will be obsoleting --> Processing Dependency: jsvc for package: cloudstack-usage-4.2.0-1.el6.x86_64 --> Processing Dependency: jakarta-commons-daemon-jsvc for package: cloudstack-usage-4.2.0-1.el6.x86_64 --> Running transaction check ---> Package cloudstack-awsapi.x86_64 0:4.2.0-1.el6 will be installed ---> Package jakarta-commons-daemon-jsvc.x86_64 1:1.0.1-8.9.el6 will be installed ---> Package mysql-connector-java.noarch 1:5.1.17-6.el6 will be installed --> Processing Dependency: jta >= 1.0 for package: 1:mysql-connector-java-5.1.17-6.el6.noarch --> Processing Dependency: slf4j for package: 1:mysql-connector-java-5.1.17-6.el6.noarch --> Running transaction check ---> Package geronimo-specs-compat.noarch 0:1.0-3.5.M2.el6 will be installed --> Processing Dependency: geronimo-specs = 1.0-3.5.M2.el6 for package: geronimo-specs-compat-1.0-3.5.M2.el6.noarch ---> Package slf4j.noarch 0:1.5.8-8.el6 will be installed --> Running transaction check ---> Package geronimo-specs.noarch 0:1.0-3.5.M2.el6 will be installed --> Processing Dependency: apache-tomcat-apis for package: geronimo-specs-1.0-3.5.M2.el6.noarch --> Running transaction check ---> Package apache-tomcat-apis.noarch 0:0.1-1.el6 will be installed --> Finished Dependency Resolution Dependencies Resolved === Package ArchVersion Repository Size === Installing: cloudstack-commonx86_64 4.2.0-1.el6
[jira] [Updated] (CLOUDSTACK-4581) dissociate transferred public ip should succeed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4581: --- Affects Version/s: 4.2.0 > dissociate transferred public ip should succeed > --- > > Key: CLOUDSTACK-4581 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4581 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Prasanna Santhanam >Priority: Critical > > Steps for this automated test are in CLOUDSTACK-4575. Needs coverage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4581) dissociate transferred public ip should succeed
Prasanna Santhanam created CLOUDSTACK-4581: -- Summary: dissociate transferred public ip should succeed Key: CLOUDSTACK-4581 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4581 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Reporter: Prasanna Santhanam Priority: Critical Steps for this automated test are in CLOUDSTACK-4575. Needs coverage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-4579) [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able to deploy Vms with existing templates.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan closed CLOUDSTACK-4579.
---
Tested with latest build.
After upgrading from 2.2.14 -> 4.2 , we are able deploy new Vms with the
templates that were registered in 2.2.14.
> [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able to deploy Vms with
> existing templates.
> --
>
> Key: CLOUDSTACK-4579
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4579
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: Upgrade from 2.2.14 - > 4.2 with rhel 6.0 hosts.
>Reporter: Sangeetha Hariharan
>Priority: Blocker
> Fix For: 4.2.1
>
>
> Deploy a 2.2.14 setup with 2 rhel 6.0 hosts in cluster.
> Upgrade to 4.2.
> Deploy a new VM using an existing template.
> Vm deployment fails with following exception in the management server logs:
> 2013-08-31 00:02:35,408 DEBUG [agent.transport.Request]
> (AgentManager-Handler-4:null) Seq 2-1176895727: Processing: { Ans: , MgmtId:
> 6860035851996, via: 2, Ver: v1, Flags: 110,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"result":false,"details":"com.cloud.utils.exception.CloudRuntimeException:
> com.cloud.utils.exception.CloudRuntimeException: Can't find
> volume:/mnt/f691b1f4-e2a1-3777-8747-eda71b158aba/db0c5f4f-86d0-4aa6-9e06-ff91ad3a62ff","wait":0}}]
> }
> 2013-08-31 00:02:35,408 DEBUG [agent.manager.AgentAttache]
> (AgentManager-Handler-4:null) Seq 2-1176895727: No more commands found
> 2013-08-31 00:02:35,408 DEBUG [agent.transport.Request]
> (Job-Executor-11:job-35 = [ 4b0d3b97-1cc9-4edc-85d5-80cd7add0035 ]) Seq
> 2-1176895727: Received: { Ans: , MgmtId: 6860035851996, via: 2, Ver: v1,
> Flags: 110, { CopyCmdAnswer } }
> 2013-08-31 00:02:35,413 WARN
> [storage.datastore.ObjectInDataStoreManagerImpl] (Job-Executor-11:job-35 = [
> 4b0d3b97-1cc9-4edc-85d5-80cd7add0035 ]) Unsupported data object (VOLUME,
> org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@523f72ca), no
> need to delete from object in store ref table
> 2013-08-31 00:02:35,413 DEBUG [cloud.storage.VolumeManagerImpl]
> (Job-Executor-11:job-35 = [ 4b0d3b97-1cc9-4edc-85d5-80cd7add0035 ]) Unable to
> create Vol[17|vm=14|ROOT]:com.cloud.utils.exception.CloudRuntimeException:
> com.cloud.utils.exception.CloudRuntimeException: Can't find
> volume:/mnt/f691b1f4-e2a1-3777-8747-eda71b158aba/db0c5f4f-86d0-4aa6-9e06-ff91ad3a62ff
> 2013-08-31 00:02:35,413 INFO [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-11:job-35 = [ 4b0d3b97-1cc9-4edc-85d5-80cd7add0035 ]) Unable to
> contact resource.
> com.cloud.exception.StorageUnavailableException: Resource [StoragePool:200]
> is unreachable: Unable to create
> Vol[17|vm=14|ROOT]:com.cloud.utils.exception.CloudRuntimeException:
> com.cloud.utils.exception.CloudRuntimeException: Can't find
> volume:/mnt/f691b1f4-e2a1-3777-8747-eda71b158aba/db0c5f4f-86d0-4aa6-9e06-ff91ad3a62ff
> at
> com.cloud.storage.VolumeManagerImpl.recreateVolume(VolumeManagerImpl.java:2544)
> at
> com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2592)
> 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:227)
> at
> org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3406)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2966)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2952)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:420)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.Threa
[jira] [Closed] (CLOUDSTACK-4580) [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able to start existing Vms after stopping them.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan closed CLOUDSTACK-4580.
---
Tested with latest build.
After upgrading from 2.2.14 -> 4.2 , we are able to stop and start the Vms that
were deployed in 2.2.14.
> [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able to start existing Vms
> after stopping them.
> --
>
> Key: CLOUDSTACK-4580
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4580
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: Upgrade from 2.2.14 - 4.2
>Reporter: Sangeetha Hariharan
>Priority: Blocker
> Fix For: 4.2.1
>
>
> [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able to start existing Vms
> after stopping them.
> Have a 2.2.14 set with 2 KVM hosts - rhel 6.0 in cluster.
> Upgrade to 4.2
> Stop an existing Vm (that was deployed from 4.2)
> Not able to start Vm.
> Following exception seen in management server log:
> 2013-08-30 23:50:35,797 DEBUG [agent.transport.Request]
> (Job-Executor-10:job-34 = [ 9c59d52b-2d06-4241-a3e2-9970e3028f7
> 7 ]) Seq 1-1982333139: Sending { Cmd , MgmtId: 6860035851996, via: 1, Ver:
> v1, Flags: 100111, [{"com.cloud.agent.api.S
> tartCommand":{"vm":{"id":10,"name":"i-3-10-VM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,
> "maxRam":536870912,"arch":"x86_64","os":"CentOS 5.5
> (64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"lim
> itCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"5576a472a48abfb5","params":{"Message.ReservedCapacityFr
> eed.Flag":"false"},"uuid":"10","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"10","volume
> Type":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"f691b1f4-e2a1-3777-8747-eda71b
> 158aba","id":200,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/sangeetha/2214-kvm/primary
> ","port":2049}},"name":"ROOT-10","size":8589934592,"path":"9decf018-6da0-410d-9e8d-1b1f4b25e55a","volumeId":10,"vmName"
> :"i-3-10-VM","accountId":3,"format":"QCOW2","id":10,"hypervisorType":"KVM"}},"diskSeq":0,"type":"ROOT"},{"data":{"org.a
> pache.cloudstack.storage.to.TemplateObjectTO":{"id":0,"format":"ISO","accountId":0,"hvm":false}},"diskSeq":3,"type":"IS
> O"}],"nics":[{"deviceId":0,"networkRateMbps":200,"defaultNic":true,"uuid":"24","ip":"10.1.1.140","netmask":"255.255.255
> .0","gateway":"10.1.1.1","mac":"02:00:1a:5d:00:04","dns1":"72.52.126.11","dns2":"72.52.126.12","broadcastType":"Vlan","
> type":"Guest","broadcastUri":"vlan://2307","isolationUri":"vlan://2307","isSecurityGroupEnabled":false}]},"hostIp":"10.
> 223.58.66","executeInSequence":true,"wait":0}}] }
> 2013-08-30 23:50:35,936 DEBUG [agent.transport.Request]
> (AgentManager-Handler-5:null) Seq 1-1982333139: Processing: {
> Ans: , MgmtId: 6860035851996, via: 1, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":10,"name":"i
> -3-10-VM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,"maxRam":536870912,"arch":"x86_64","o
> s":"CentOS 5.5
> (64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallySca
> leVm":false,"vncPassword":"5576a472a48abfb5","vncAddr":"10.223.58.66","params":{"Message.ReservedCapacityFreed.Flag":"f
> alse"},"uuid":"10","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"10","volumeType":"ROOT"
> ,"dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"f691b1f4-e2a1-3777-8747-eda71b158aba","id"
> :200,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/sangeetha/2214-kvm/primary","port":204
> 9}},"name":"ROOT-10","size":8589934592,"path":"9decf018-6da0-410d-9e8d-1b1f4b25e55a","volumeId":10,"vmName":"i-3-10-VM"
> ,"accountId":3,"format":"QCOW2","id":10,"hypervisorType":"KVM"}},"diskSeq":0,"type":"ROOT"},{"data":{"org.apache.clouds
> tack.storage.to.TemplateObjectTO":{"id":0,"format":"ISO","accountId":0,"hvm":false}},"diskSeq":3,"type":"ISO"}],"nics":
> [{"deviceId":0,"networkRateMbps":200,"defaultNic":true,"uuid":"24","ip":"10.1.1.140","netmask":"255.255.255.0","gateway
> ":"10.1.1.1","mac":"02:00:1a:5d:00:04","dns1":"72.52.126.11","dns2":"72.52.126.12","broadcastType":"Vlan","type":"Guest
> ","broadcastUri":"vlan://2307","isolationUri":"vlan://2307","isSecurityGroupEnabled":false}]},"result":false,"details":
> "internal error malformed uuid element","wait":0}}] }
--
This message is automatically generated by JIRA.
If you think it was sent in
[jira] [Updated] (CLOUDSTACK-4575) [Portable IP] disassociating a transferred public IP is failing with exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4575: --- Labels: integration-test (was: ) > [Portable IP] disassociating a transferred public IP is failing with exception > -- > > Key: CLOUDSTACK-4575 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4575 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Reporter: Chiradeep Vittal >Assignee: Murali Reddy > Labels: integration-test > > Steps to reproduce: > 1. Have latest CloudStack with at least 2 advanced zone. > 2. Go to Regions -> local -> portable IP -> add an ip range like below > Gateway : 10.147.33.1 > startIp : 10.147.33.3 > endip : 10.147.33.10 > vlan : 33 > subnet : 255.255.255.128 > 3. login as a non-ROOT admin > username : dom1User1 > password : password > domain : dom1 > 4. create the following isolated networks in each zone > - Network1Zone1 > - Network1Zone2 > 5. deploy the following VMs in each network > - vm1Zone1 connected to Network1Zone1 > - vm1Zone2 connected to Network1Zone2 > 6. Acquire and associate a portable IP to Network1Zone1 > 7. enable staticNAT on the above portableIP and associate it to vm1Zone2 of > Network1Zone2 and add firewall rule for ssh port > Observations: > (i) portable IP got transferred from Zone1 to Network1Zone2 successfully and > able ssh to the portable IP without any issuees. > 8. disassociate above portable IP from Network1Zone2. > Observations: > (ii) sequence of things happened as mentioned below > - disassociate happened without any issues which cleaned the eth interface > from router etc.., but, > - it again initiated IPASSOC on its own for the same portable IP which > resulted in the following error and thus this IP stuck in release state > forever. > (iii) above behaviour made all further IPASSOCs to fail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4492) [object_store_ref] Attaching volume to a vm is failing after upgrade if the volume was uploaded before upgrade
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-4492:
---
Labels: ReleaseNote (was: )
> [object_store_ref] Attaching volume to a vm is failing after upgrade if the
> volume was uploaded before upgrade
> ---
>
> Key: CLOUDSTACK-4492
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4492
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, Volumes
>Affects Versions: 4.2.1
> Environment: Build is from commit
> :a6bf80216466ada185de7e04d3e64be4e25c11a7
> Upgrade from 3.0.6 to 4.2
>Reporter: Sanjeev N
>Assignee: edison su
> Labels: ReleaseNote
> Fix For: 4.2.1
>
> Attachments: cloud.dmp, cloud.dmp, management-server.rar,
> management-server.rar
>
>
> Failing to attach a volume to a vm after upgrade if it was uploaded before
> upgrade.
> Steps to Reproduce:
>
> 1.Bring up CS with VMWare cluster using 3.0.6 GA build
> 2.upload volume using API:
> http://10.147.59.126:8096/client/api?command=uploadVolume&format=OVA&name=cent53-upload-BU&url=http://10.147.28.7/templates/vmware/CentOS5.3-x86_64.ova&zoneid=9076c21d-d0c4-4cee-9820-2a551b65616e&account=admin&domainid=1
> 3.Upgrade to 4.2
> 4.Deploy one vm with root disk
> 5.Try to attach the volume uploaded at step2 to vm created above
> Result:
> =
> Attaching volume failed with InvalidParameterValueException
> Observations:
> ===
> Uploaded volume has state set to "UploadOp" in volumes table. However
> AttachVolumeCmd is checking for volume state to be either in Allocated, Ready
> or in Uploaded state. So attaching is failing.
> Following is the log snippet:
> 2013-08-26 01:36:30,254 DEBUG [cloud.api.ApiServlet] (catalina-exec-4:null)
> ===START=== 10.146.0.131 -- GET
> command=attachVolume&id=55cd0b1d-cf01-4fff-b6a1-d2d3f6d90d7e&virtualMachineId=ce3c8eb5-05f9-445b-ab74-68751e8a982a&response=json&sessionkey=u8uFWRNIgqqVZ%2B%2FBLCQbaSfZMCw%3D&_=1377495389690
> 2013-08-26 01:36:30,405 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-4:null) submit async job-189 = [
> 0a33a5ee-9c58-4791-a0e5-cf6a070d9fc1 ], details: AsyncJobVO {id:189, userId:
> 2, accountId: 2, sessionKey: null, instanceType: Volume, instanceId: 20, cmd:
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd, cmdOriginator:
> null, cmdInfo:
> {"response":"json","id":"55cd0b1d-cf01-4fff-b6a1-d2d3f6d90d7e","sessionkey":"u8uFWRNIgqqVZ+/BLCQbaSfZMCw\u003d","cmdEventType":"VOLUME.ATTACH","ctxUserId":"2","virtualMachineId":"ce3c8eb5-05f9-445b-ab74-68751e8a982a","httpmethod":"GET","_":"1377495389690","ctxAccountId":"2","ctxStartEventId":"2015"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-26 01:36:30,408 DEBUG [cloud.api.ApiServlet] (catalina-exec-4:null)
> ===END=== 10.146.0.131 -- GET
> command=attachVolume&id=55cd0b1d-cf01-4fff-b6a1-d2d3f6d90d7e&virtualMachineId=ce3c8eb5-05f9-445b-ab74-68751e8a982a&response=json&sessionkey=u8uFWRNIgqqVZ%2B%2FBLCQbaSfZMCw%3D&_=1377495389690
> 2013-08-26 01:36:30,410 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-157:job-189 = [ 0a33a5ee-9c58-4791-a0e5-cf6a070d9fc1 ])
> Executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd for
> job-189 = [ 0a33a5ee-9c58-4791-a0e5-cf6a070d9fc1 ]
> 2013-08-26 01:36:30,468 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-157:job-189 = [ 0a33a5ee-9c58-4791-a0e5-cf6a070d9fc1 ])
> Unexpected exception while executing
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
> com.cloud.exception.InvalidParameterValueException: Volume state must be in
> Allocated, Ready or in Uploaded state
> at
> com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1807)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:122)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:1
[jira] [Commented] (CLOUDSTACK-4492) [object_store_ref] Attaching volume to a vm is failing after upgrade if the volume was uploaded before upgrade
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13755421#comment-13755421
]
Animesh Chaturvedi commented on CLOUDSTACK-4492:
Shouldn't this be an issue even prior to upgrade?
> [object_store_ref] Attaching volume to a vm is failing after upgrade if the
> volume was uploaded before upgrade
> ---
>
> Key: CLOUDSTACK-4492
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4492
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, Volumes
>Affects Versions: 4.2.1
> Environment: Build is from commit
> :a6bf80216466ada185de7e04d3e64be4e25c11a7
> Upgrade from 3.0.6 to 4.2
>Reporter: Sanjeev N
>Assignee: edison su
> Fix For: 4.2.1
>
> Attachments: cloud.dmp, cloud.dmp, management-server.rar,
> management-server.rar
>
>
> Failing to attach a volume to a vm after upgrade if it was uploaded before
> upgrade.
> Steps to Reproduce:
>
> 1.Bring up CS with VMWare cluster using 3.0.6 GA build
> 2.upload volume using API:
> http://10.147.59.126:8096/client/api?command=uploadVolume&format=OVA&name=cent53-upload-BU&url=http://10.147.28.7/templates/vmware/CentOS5.3-x86_64.ova&zoneid=9076c21d-d0c4-4cee-9820-2a551b65616e&account=admin&domainid=1
> 3.Upgrade to 4.2
> 4.Deploy one vm with root disk
> 5.Try to attach the volume uploaded at step2 to vm created above
> Result:
> =
> Attaching volume failed with InvalidParameterValueException
> Observations:
> ===
> Uploaded volume has state set to "UploadOp" in volumes table. However
> AttachVolumeCmd is checking for volume state to be either in Allocated, Ready
> or in Uploaded state. So attaching is failing.
> Following is the log snippet:
> 2013-08-26 01:36:30,254 DEBUG [cloud.api.ApiServlet] (catalina-exec-4:null)
> ===START=== 10.146.0.131 -- GET
> command=attachVolume&id=55cd0b1d-cf01-4fff-b6a1-d2d3f6d90d7e&virtualMachineId=ce3c8eb5-05f9-445b-ab74-68751e8a982a&response=json&sessionkey=u8uFWRNIgqqVZ%2B%2FBLCQbaSfZMCw%3D&_=1377495389690
> 2013-08-26 01:36:30,405 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-4:null) submit async job-189 = [
> 0a33a5ee-9c58-4791-a0e5-cf6a070d9fc1 ], details: AsyncJobVO {id:189, userId:
> 2, accountId: 2, sessionKey: null, instanceType: Volume, instanceId: 20, cmd:
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd, cmdOriginator:
> null, cmdInfo:
> {"response":"json","id":"55cd0b1d-cf01-4fff-b6a1-d2d3f6d90d7e","sessionkey":"u8uFWRNIgqqVZ+/BLCQbaSfZMCw\u003d","cmdEventType":"VOLUME.ATTACH","ctxUserId":"2","virtualMachineId":"ce3c8eb5-05f9-445b-ab74-68751e8a982a","httpmethod":"GET","_":"1377495389690","ctxAccountId":"2","ctxStartEventId":"2015"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-26 01:36:30,408 DEBUG [cloud.api.ApiServlet] (catalina-exec-4:null)
> ===END=== 10.146.0.131 -- GET
> command=attachVolume&id=55cd0b1d-cf01-4fff-b6a1-d2d3f6d90d7e&virtualMachineId=ce3c8eb5-05f9-445b-ab74-68751e8a982a&response=json&sessionkey=u8uFWRNIgqqVZ%2B%2FBLCQbaSfZMCw%3D&_=1377495389690
> 2013-08-26 01:36:30,410 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-157:job-189 = [ 0a33a5ee-9c58-4791-a0e5-cf6a070d9fc1 ])
> Executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd for
> job-189 = [ 0a33a5ee-9c58-4791-a0e5-cf6a070d9fc1 ]
> 2013-08-26 01:36:30,468 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-157:job-189 = [ 0a33a5ee-9c58-4791-a0e5-cf6a070d9fc1 ])
> Unexpected exception while executing
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
> com.cloud.exception.InvalidParameterValueException: Volume state must be in
> Allocated, Ready or in Uploaded state
> at
> com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1807)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:122)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at j
[jira] [Assigned] (CLOUDSTACK-4575) [Portable IP] disassociating a transferred public IP is failing with exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy reassigned CLOUDSTACK-4575: Assignee: Murali Reddy > [Portable IP] disassociating a transferred public IP is failing with exception > -- > > Key: CLOUDSTACK-4575 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4575 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Reporter: Chiradeep Vittal >Assignee: Murali Reddy > > Steps to reproduce: > 1. Have latest CloudStack with at least 2 advanced zone. > 2. Go to Regions -> local -> portable IP -> add an ip range like below > Gateway : 10.147.33.1 > startIp : 10.147.33.3 > endip : 10.147.33.10 > vlan : 33 > subnet : 255.255.255.128 > 3. login as a non-ROOT admin > username : dom1User1 > password : password > domain : dom1 > 4. create the following isolated networks in each zone > - Network1Zone1 > - Network1Zone2 > 5. deploy the following VMs in each network > - vm1Zone1 connected to Network1Zone1 > - vm1Zone2 connected to Network1Zone2 > 6. Acquire and associate a portable IP to Network1Zone1 > 7. enable staticNAT on the above portableIP and associate it to vm1Zone2 of > Network1Zone2 and add firewall rule for ssh port > Observations: > (i) portable IP got transferred from Zone1 to Network1Zone2 successfully and > able ssh to the portable IP without any issuees. > 8. disassociate above portable IP from Network1Zone2. > Observations: > (ii) sequence of things happened as mentioned below > - disassociate happened without any issues which cleaned the eth interface > from router etc.., but, > - it again initiated IPASSOC on its own for the same portable IP which > resulted in the following error and thus this IP stuck in release state > forever. > (iii) above behaviour made all further IPASSOCs to fail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-3654) [Automation] test_redundant_router_deployment_planning.TestRvRDeploymentPlanning.test_RvR_multiprimarystorage failed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan closed CLOUDSTACK-3654. --- No failures from this suite Test RvR with multi clusters ... SKIP: The env don't have 2 clusters req for test Test RvR with multi hosts ... ok Test RvR with multi pods ... SKIP: The env don't have 2 pods req for test Test RvR with multi primary storage ... ok -- XML: /hudson/scripts/reruns/logs/reports/nosetests.xml -- Ran 4 tests in 919.845s OK (SKIP=2) > [Automation] > test_redundant_router_deployment_planning.TestRvRDeploymentPlanning.test_RvR_multiprimarystorage > failed > > > Key: CLOUDSTACK-3654 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3654 > 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: Rayees Namathponnan >Assignee: Prasanna Santhanam > Fix For: 4.2.0 > > > oth the routers should be in different storage pools > >> begin captured logging << > testclient.testcase.TestRvRDeploymentPlanning: DEBUG: Checking if the current > zone has multiple active pods in it.. > testclient.testcase.TestRvRDeploymentPlanning: DEBUG: Cheking if pod has > multiple clusters > testclient.testcase.TestRvRDeploymentPlanning: DEBUG: Cheking if cluster has > multiple storage pools > testclient.testcase.TestRvRDeploymentPlanning: DEBUG: disable all pods except > one! > testclient.testcase.TestRvRDeploymentPlanning: DEBUG: disable all clusters > except one! > testclient.testcase.TestRvRDeploymentPlanning: DEBUG: Creating network with > network offering: 202ba780-f52d-486f-8d4b-327939cb22e6 > testclient.testcase.TestRvRDeploymentPlanning: DEBUG: Created network with > ID: cc2a7fcb-d84d-4733-85fc-8ff99c830d3f > testclient.testcase.TestRvRDeploymentPlanning: DEBUG: Network state: Allocated > testclient.testcase.TestRvRDeploymentPlanning: DEBUG: Listing routers for > network: Test Network > testclient.testcase.TestRvRDeploymentPlanning: DEBUG: Retrieving the list of > hosts in the cluster > testclient.testcase.TestRvRDeploymentPlanning: DEBUG: Deploying VM in > account: test-XUFO53 > testclient.testcase.TestRvRDeploymentPlanning: DEBUG: Deployed VM in network: > cc2a7fcb-d84d-4733-85fc-8ff99c830d3f > testclient.testcase.TestRvRDeploymentPlanning: DEBUG: Listing routers for > network: Test Network > - >> end captured logging << - > Stacktrace > File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run > testMethod() > File > "/Repo_30X/ipcl/cloudstack/test/integration/component/test_redundant_router_deployment_planning.py", > line 736, in test_RvR_multiprimarystorage > "Both the routers should be in different storage pools" > File "/usr/local/lib/python2.7/unittest/case.py", line 503, in > assertNotEqual > raise self.failureException(msg) > Both the routers should be in different storage pools -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-3929) [Automation] Test case test_redundant_router_deployment_planning.TestRvRDeploymentPlanning failed global name 'unittest' is not defined
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan closed CLOUDSTACK-3929. --- No failure from this suite Test RvR with multi clusters ... SKIP: The env don't have 2 clusters req for test Test RvR with multi hosts ... ok Test RvR with multi pods ... SKIP: The env don't have 2 pods req for test Test RvR with multi primary storage ... ok -- XML: /hudson/scripts/reruns/logs/reports/nosetests.xml -- Ran 4 tests in 919.845s OK (SKIP=2) > [Automation] Test case > test_redundant_router_deployment_planning.TestRvRDeploymentPlanning failed > global name 'unittest' is not defined > --- > > Key: CLOUDSTACK-3929 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3929 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Test >Affects Versions: 4.2.0 > Environment: Automation >Reporter: Rayees Namathponnan >Assignee: Prasanna Santhanam > Fix For: 4.2.0 > > > Below two test cases failed with error global name 'unittest' is not defined > integration.component.test_redundant_router_deployment_planning.TestRvRDeploymentPlanning.test_RvR_multicluster > integration.component.test_redundant_router_deployment_planning.TestRvRDeploymentPlanning.test_RvR_multipods -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-4430) [Automation][vmware] Failed to deploy vm, if one host is down in a cluster
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Parth Jagirdar closed CLOUDSTACK-4430.
--
Verified in latest build,
2 Host same cluster then later one disconnected. Templates gets copied
successfully. New VM Deployment from old template succeeded.
> [Automation][vmware] Failed to deploy vm, if one host is down in a cluster
> --
>
> Key: CLOUDSTACK-4430
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4430
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Management Server, VMware
>Affects Versions: 4.2.0
> Environment: Automation
> vmware
>Reporter: Rayees Namathponnan
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: management-server.log.2013-08-20.gz,
> management-server.rar
>
>
> This issue observed during automation run
> 1) Automation running with 2 zones (advanced ), both zone contions one
> cluster; first cluster having 2 hosts (10.223.250.130 and 10.223.250.131)
> and another cluster have 1 host.
> 2) Create vm one first zone;
> 3) make one host (10.223.250.130) down from first zone
> 4) deploy an another vm after the first zone is down
> Expected Behavior
> ---
> New vm should be deployed with first zone, on the second host (10.223.250.131)
> Actual Result
>
> VM deployment failed with below error
> 2013-08-21 15:49:49,125 DEBUG [cloud.storage.VolumeManagerImpl]
> (Job-Executor-29:job-1549 = [ cf900a2a-6c83-4ddd-b898-e19c90cef0a6 ])
> Checking if we need to prepare 1 volumes for VM[DomainRouter|r-524-TestVM]
> 2013-08-21 15:49:49,131 DEBUG [storage.image.TemplateDataFactoryImpl]
> (Job-Executor-29:job-1549 = [ cf900a2a-6c83-4ddd-b898-e19c90cef0a6 ])
> template 8 is already in store:2, type:Image
> 2013-08-21 15:49:49,155 DEBUG [storage.image.TemplateDataFactoryImpl]
> (Job-Executor-29:job-1549 = [ cf900a2a-6c83-4ddd-b898-e19c90cef0a6 ])
> template 8 is already in store:1, type:Primary
> 2013-08-21 15:49:49,224 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-29:job-1549 = [ cf900a2a-6c83-4ddd-b898-e19c90cef0a6 ])
> copyAsync inspecting src type TEMPLATE copyAsync inspecting dest type VOLUME
> 2013-08-21 15:49:49,232 DEBUG [agent.transport.Request]
> (Job-Executor-29:job-1549 = [ cf900a2a-6c83-4ddd-b898-e19c90cef0a6 ]) Seq
> 3-1188243408: Sending { Cmd , MgmtId: 90928106758026, via: 3, Ver: v1,
> Flags: 100011, [{"org.apac
> he.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"d559e79dc94f3ceea16e841774053435","origUrl":"http://download.cloud.com/templates/4.2/systemvmtemplate-4.2-vh7.ova";
> ,"uuid":"426a759e-09ec-11e3-a733-52b2d980df8a","id":8,"format":"OVA","accountId":1,"checksum":"8fde62b1089e5844a9cd3b9b953f9596","hvm":false,"displayText":"SystemVM
> Template (vSphere)","imageDataStore":{"org.apache.cloudstack.st
> orage.to.PrimaryDataStoreTO":{"uuid":"4faf04c2-6dd8-3025-b43f-65d32cc49d02","id":1,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/automation/SC-CLOUD-QA03/primary1","port":2049}},"name":"routing-8","
> hypervisorType":"VMware"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"3c7b36c7-a034-485b-b808-501e6b8a067a","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid"
> :"4faf04c2-6dd8-3025-b43f-65d32cc49d02","id":1,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/automation/SC-CLOUD-QA03/primary1","port":2049}},"name":"ROOT-524","size":2097152000,"volumeId":575,"vmNa
> me":"r-524-TestVM","accountId":2,"format":"OVA","id":575,"hypervisorType":"None"}},"executeInSequence":false,"wait":0}}]
> }
> 2013-08-21 15:49:49,232 DEBUG [agent.transport.Request]
> (Job-Executor-29:job-1549 = [ cf900a2a-6c83-4ddd-b898-e19c90cef0a6 ]) Seq
> 3-1188243408: Executing: { Cmd , MgmtId: 90928106758026, via: 3, Ver: v1,
> Flags: 100011, [{"org.a
> pache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"d559e79dc94f3ceea16e841774053435","origUrl":"http://download.cloud.com/templates/4.2/systemvmtemplate-4.2-vh7.o
> va","uuid":"426a759e-09ec-11e3-a733-52b2d980df8a","id":8,"format":"OVA","accountId":1,"checksum":"8fde62b1089e5844a9cd3b9b953f9596","hvm":false,"displayText":"SystemVM
> Template (vSphere)","imageDataStore":{"org.apache.cloudstack
> .storage.to.PrimaryDataStoreTO":{"uuid":"4faf04c2-6dd8-3025-b43f-65d32cc49d02","id":1,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/automation/
[jira] [Resolved] (CLOUDSTACK-4580) [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able to start existing Vms after stopping them.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
edison su resolved CLOUDSTACK-4580.
---
Resolution: Fixed
fixed in ffc53e81e0de998f15a91b90eb05104402c4538c
> [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able to start existing Vms
> after stopping them.
> --
>
> Key: CLOUDSTACK-4580
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4580
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: Upgrade from 2.2.14 - 4.2
>Reporter: Sangeetha Hariharan
>Priority: Blocker
> Fix For: 4.2.1
>
>
> [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able to start existing Vms
> after stopping them.
> Have a 2.2.14 set with 2 KVM hosts - rhel 6.0 in cluster.
> Upgrade to 4.2
> Stop an existing Vm (that was deployed from 4.2)
> Not able to start Vm.
> Following exception seen in management server log:
> 2013-08-30 23:50:35,797 DEBUG [agent.transport.Request]
> (Job-Executor-10:job-34 = [ 9c59d52b-2d06-4241-a3e2-9970e3028f7
> 7 ]) Seq 1-1982333139: Sending { Cmd , MgmtId: 6860035851996, via: 1, Ver:
> v1, Flags: 100111, [{"com.cloud.agent.api.S
> tartCommand":{"vm":{"id":10,"name":"i-3-10-VM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,
> "maxRam":536870912,"arch":"x86_64","os":"CentOS 5.5
> (64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"lim
> itCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"5576a472a48abfb5","params":{"Message.ReservedCapacityFr
> eed.Flag":"false"},"uuid":"10","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"10","volume
> Type":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"f691b1f4-e2a1-3777-8747-eda71b
> 158aba","id":200,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/sangeetha/2214-kvm/primary
> ","port":2049}},"name":"ROOT-10","size":8589934592,"path":"9decf018-6da0-410d-9e8d-1b1f4b25e55a","volumeId":10,"vmName"
> :"i-3-10-VM","accountId":3,"format":"QCOW2","id":10,"hypervisorType":"KVM"}},"diskSeq":0,"type":"ROOT"},{"data":{"org.a
> pache.cloudstack.storage.to.TemplateObjectTO":{"id":0,"format":"ISO","accountId":0,"hvm":false}},"diskSeq":3,"type":"IS
> O"}],"nics":[{"deviceId":0,"networkRateMbps":200,"defaultNic":true,"uuid":"24","ip":"10.1.1.140","netmask":"255.255.255
> .0","gateway":"10.1.1.1","mac":"02:00:1a:5d:00:04","dns1":"72.52.126.11","dns2":"72.52.126.12","broadcastType":"Vlan","
> type":"Guest","broadcastUri":"vlan://2307","isolationUri":"vlan://2307","isSecurityGroupEnabled":false}]},"hostIp":"10.
> 223.58.66","executeInSequence":true,"wait":0}}] }
> 2013-08-30 23:50:35,936 DEBUG [agent.transport.Request]
> (AgentManager-Handler-5:null) Seq 1-1982333139: Processing: {
> Ans: , MgmtId: 6860035851996, via: 1, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":10,"name":"i
> -3-10-VM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,"maxRam":536870912,"arch":"x86_64","o
> s":"CentOS 5.5
> (64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallySca
> leVm":false,"vncPassword":"5576a472a48abfb5","vncAddr":"10.223.58.66","params":{"Message.ReservedCapacityFreed.Flag":"f
> alse"},"uuid":"10","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"10","volumeType":"ROOT"
> ,"dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"f691b1f4-e2a1-3777-8747-eda71b158aba","id"
> :200,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/sangeetha/2214-kvm/primary","port":204
> 9}},"name":"ROOT-10","size":8589934592,"path":"9decf018-6da0-410d-9e8d-1b1f4b25e55a","volumeId":10,"vmName":"i-3-10-VM"
> ,"accountId":3,"format":"QCOW2","id":10,"hypervisorType":"KVM"}},"diskSeq":0,"type":"ROOT"},{"data":{"org.apache.clouds
> tack.storage.to.TemplateObjectTO":{"id":0,"format":"ISO","accountId":0,"hvm":false}},"diskSeq":3,"type":"ISO"}],"nics":
> [{"deviceId":0,"networkRateMbps":200,"defaultNic":true,"uuid":"24","ip":"10.1.1.140","netmask":"255.255.255.0","gateway
> ":"10.1.1.1","mac":"02:00:1a:5d:00:04","dns1":"72.52.126.11","dns2":"72.52.126.12","broadcastType":"Vlan","type":"Guest
> ","broadcastUri":"vlan://2307","isolationUri":"vlan://2307","isSecurityGroupEnabled":false}]},"result":false,"details":
> "internal error malformed uuid element","wait":0}}] }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JI
[jira] [Resolved] (CLOUDSTACK-4579) [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able to deploy Vms with existing templates.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
edison su resolved CLOUDSTACK-4579.
---
Resolution: Fixed
fixed in ffc53e81e0de998f15a91b90eb05104402c4538c
> [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able to deploy Vms with
> existing templates.
> --
>
> Key: CLOUDSTACK-4579
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4579
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: Upgrade from 2.2.14 - > 4.2 with rhel 6.0 hosts.
>Reporter: Sangeetha Hariharan
>Priority: Blocker
> Fix For: 4.2.1
>
>
> Deploy a 2.2.14 setup with 2 rhel 6.0 hosts in cluster.
> Upgrade to 4.2.
> Deploy a new VM using an existing template.
> Vm deployment fails with following exception in the management server logs:
> 2013-08-31 00:02:35,408 DEBUG [agent.transport.Request]
> (AgentManager-Handler-4:null) Seq 2-1176895727: Processing: { Ans: , MgmtId:
> 6860035851996, via: 2, Ver: v1, Flags: 110,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"result":false,"details":"com.cloud.utils.exception.CloudRuntimeException:
> com.cloud.utils.exception.CloudRuntimeException: Can't find
> volume:/mnt/f691b1f4-e2a1-3777-8747-eda71b158aba/db0c5f4f-86d0-4aa6-9e06-ff91ad3a62ff","wait":0}}]
> }
> 2013-08-31 00:02:35,408 DEBUG [agent.manager.AgentAttache]
> (AgentManager-Handler-4:null) Seq 2-1176895727: No more commands found
> 2013-08-31 00:02:35,408 DEBUG [agent.transport.Request]
> (Job-Executor-11:job-35 = [ 4b0d3b97-1cc9-4edc-85d5-80cd7add0035 ]) Seq
> 2-1176895727: Received: { Ans: , MgmtId: 6860035851996, via: 2, Ver: v1,
> Flags: 110, { CopyCmdAnswer } }
> 2013-08-31 00:02:35,413 WARN
> [storage.datastore.ObjectInDataStoreManagerImpl] (Job-Executor-11:job-35 = [
> 4b0d3b97-1cc9-4edc-85d5-80cd7add0035 ]) Unsupported data object (VOLUME,
> org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@523f72ca), no
> need to delete from object in store ref table
> 2013-08-31 00:02:35,413 DEBUG [cloud.storage.VolumeManagerImpl]
> (Job-Executor-11:job-35 = [ 4b0d3b97-1cc9-4edc-85d5-80cd7add0035 ]) Unable to
> create Vol[17|vm=14|ROOT]:com.cloud.utils.exception.CloudRuntimeException:
> com.cloud.utils.exception.CloudRuntimeException: Can't find
> volume:/mnt/f691b1f4-e2a1-3777-8747-eda71b158aba/db0c5f4f-86d0-4aa6-9e06-ff91ad3a62ff
> 2013-08-31 00:02:35,413 INFO [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-11:job-35 = [ 4b0d3b97-1cc9-4edc-85d5-80cd7add0035 ]) Unable to
> contact resource.
> com.cloud.exception.StorageUnavailableException: Resource [StoragePool:200]
> is unreachable: Unable to create
> Vol[17|vm=14|ROOT]:com.cloud.utils.exception.CloudRuntimeException:
> com.cloud.utils.exception.CloudRuntimeException: Can't find
> volume:/mnt/f691b1f4-e2a1-3777-8747-eda71b158aba/db0c5f4f-86d0-4aa6-9e06-ff91ad3a62ff
> at
> com.cloud.storage.VolumeManagerImpl.recreateVolume(VolumeManagerImpl.java:2544)
> at
> com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2592)
> 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:227)
> at
> org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3406)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2966)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2952)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:420)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
> at
> java.util.concurr
[jira] [Updated] (CLOUDSTACK-4580) [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able to start existing Vms after stopping them.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan updated CLOUDSTACK-4580:
Fix Version/s: (was: 4.2.0)
4.2.1
> [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able to start existing Vms
> after stopping them.
> --
>
> Key: CLOUDSTACK-4580
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4580
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: Upgrade from 2.2.14 - 4.2
>Reporter: Sangeetha Hariharan
>Priority: Blocker
> Fix For: 4.2.1
>
>
> [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able to start existing Vms
> after stopping them.
> Have a 2.2.14 set with 2 KVM hosts - rhel 6.0 in cluster.
> Upgrade to 4.2
> Stop an existing Vm (that was deployed from 4.2)
> Not able to start Vm.
> Following exception seen in management server log:
> 2013-08-30 23:50:35,797 DEBUG [agent.transport.Request]
> (Job-Executor-10:job-34 = [ 9c59d52b-2d06-4241-a3e2-9970e3028f7
> 7 ]) Seq 1-1982333139: Sending { Cmd , MgmtId: 6860035851996, via: 1, Ver:
> v1, Flags: 100111, [{"com.cloud.agent.api.S
> tartCommand":{"vm":{"id":10,"name":"i-3-10-VM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,
> "maxRam":536870912,"arch":"x86_64","os":"CentOS 5.5
> (64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"lim
> itCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"5576a472a48abfb5","params":{"Message.ReservedCapacityFr
> eed.Flag":"false"},"uuid":"10","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"10","volume
> Type":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"f691b1f4-e2a1-3777-8747-eda71b
> 158aba","id":200,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/sangeetha/2214-kvm/primary
> ","port":2049}},"name":"ROOT-10","size":8589934592,"path":"9decf018-6da0-410d-9e8d-1b1f4b25e55a","volumeId":10,"vmName"
> :"i-3-10-VM","accountId":3,"format":"QCOW2","id":10,"hypervisorType":"KVM"}},"diskSeq":0,"type":"ROOT"},{"data":{"org.a
> pache.cloudstack.storage.to.TemplateObjectTO":{"id":0,"format":"ISO","accountId":0,"hvm":false}},"diskSeq":3,"type":"IS
> O"}],"nics":[{"deviceId":0,"networkRateMbps":200,"defaultNic":true,"uuid":"24","ip":"10.1.1.140","netmask":"255.255.255
> .0","gateway":"10.1.1.1","mac":"02:00:1a:5d:00:04","dns1":"72.52.126.11","dns2":"72.52.126.12","broadcastType":"Vlan","
> type":"Guest","broadcastUri":"vlan://2307","isolationUri":"vlan://2307","isSecurityGroupEnabled":false}]},"hostIp":"10.
> 223.58.66","executeInSequence":true,"wait":0}}] }
> 2013-08-30 23:50:35,936 DEBUG [agent.transport.Request]
> (AgentManager-Handler-5:null) Seq 1-1982333139: Processing: {
> Ans: , MgmtId: 6860035851996, via: 1, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":10,"name":"i
> -3-10-VM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,"maxRam":536870912,"arch":"x86_64","o
> s":"CentOS 5.5
> (64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallySca
> leVm":false,"vncPassword":"5576a472a48abfb5","vncAddr":"10.223.58.66","params":{"Message.ReservedCapacityFreed.Flag":"f
> alse"},"uuid":"10","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"10","volumeType":"ROOT"
> ,"dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"f691b1f4-e2a1-3777-8747-eda71b158aba","id"
> :200,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/sangeetha/2214-kvm/primary","port":204
> 9}},"name":"ROOT-10","size":8589934592,"path":"9decf018-6da0-410d-9e8d-1b1f4b25e55a","volumeId":10,"vmName":"i-3-10-VM"
> ,"accountId":3,"format":"QCOW2","id":10,"hypervisorType":"KVM"}},"diskSeq":0,"type":"ROOT"},{"data":{"org.apache.clouds
> tack.storage.to.TemplateObjectTO":{"id":0,"format":"ISO","accountId":0,"hvm":false}},"diskSeq":3,"type":"ISO"}],"nics":
> [{"deviceId":0,"networkRateMbps":200,"defaultNic":true,"uuid":"24","ip":"10.1.1.140","netmask":"255.255.255.0","gateway
> ":"10.1.1.1","mac":"02:00:1a:5d:00:04","dns1":"72.52.126.11","dns2":"72.52.126.12","broadcastType":"Vlan","type":"Guest
> ","broadcastUri":"vlan://2307","isolationUri":"vlan://2307","isSecurityGroupEnabled":false}]},"result":false,"details":
> "internal error malformed uuid element","wait":0}}] }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, se
[jira] [Updated] (CLOUDSTACK-4579) [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able to deploy Vms with existing templates.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan updated CLOUDSTACK-4579:
Fix Version/s: (was: 4.2.0)
4.2.1
> [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able to deploy Vms with
> existing templates.
> --
>
> Key: CLOUDSTACK-4579
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4579
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: Upgrade from 2.2.14 - > 4.2 with rhel 6.0 hosts.
>Reporter: Sangeetha Hariharan
>Priority: Blocker
> Fix For: 4.2.1
>
>
> Deploy a 2.2.14 setup with 2 rhel 6.0 hosts in cluster.
> Upgrade to 4.2.
> Deploy a new VM using an existing template.
> Vm deployment fails with following exception in the management server logs:
> 2013-08-31 00:02:35,408 DEBUG [agent.transport.Request]
> (AgentManager-Handler-4:null) Seq 2-1176895727: Processing: { Ans: , MgmtId:
> 6860035851996, via: 2, Ver: v1, Flags: 110,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"result":false,"details":"com.cloud.utils.exception.CloudRuntimeException:
> com.cloud.utils.exception.CloudRuntimeException: Can't find
> volume:/mnt/f691b1f4-e2a1-3777-8747-eda71b158aba/db0c5f4f-86d0-4aa6-9e06-ff91ad3a62ff","wait":0}}]
> }
> 2013-08-31 00:02:35,408 DEBUG [agent.manager.AgentAttache]
> (AgentManager-Handler-4:null) Seq 2-1176895727: No more commands found
> 2013-08-31 00:02:35,408 DEBUG [agent.transport.Request]
> (Job-Executor-11:job-35 = [ 4b0d3b97-1cc9-4edc-85d5-80cd7add0035 ]) Seq
> 2-1176895727: Received: { Ans: , MgmtId: 6860035851996, via: 2, Ver: v1,
> Flags: 110, { CopyCmdAnswer } }
> 2013-08-31 00:02:35,413 WARN
> [storage.datastore.ObjectInDataStoreManagerImpl] (Job-Executor-11:job-35 = [
> 4b0d3b97-1cc9-4edc-85d5-80cd7add0035 ]) Unsupported data object (VOLUME,
> org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@523f72ca), no
> need to delete from object in store ref table
> 2013-08-31 00:02:35,413 DEBUG [cloud.storage.VolumeManagerImpl]
> (Job-Executor-11:job-35 = [ 4b0d3b97-1cc9-4edc-85d5-80cd7add0035 ]) Unable to
> create Vol[17|vm=14|ROOT]:com.cloud.utils.exception.CloudRuntimeException:
> com.cloud.utils.exception.CloudRuntimeException: Can't find
> volume:/mnt/f691b1f4-e2a1-3777-8747-eda71b158aba/db0c5f4f-86d0-4aa6-9e06-ff91ad3a62ff
> 2013-08-31 00:02:35,413 INFO [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-11:job-35 = [ 4b0d3b97-1cc9-4edc-85d5-80cd7add0035 ]) Unable to
> contact resource.
> com.cloud.exception.StorageUnavailableException: Resource [StoragePool:200]
> is unreachable: Unable to create
> Vol[17|vm=14|ROOT]:com.cloud.utils.exception.CloudRuntimeException:
> com.cloud.utils.exception.CloudRuntimeException: Can't find
> volume:/mnt/f691b1f4-e2a1-3777-8747-eda71b158aba/db0c5f4f-86d0-4aa6-9e06-ff91ad3a62ff
> at
> com.cloud.storage.VolumeManagerImpl.recreateVolume(VolumeManagerImpl.java:2544)
> at
> com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2592)
> 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:227)
> at
> org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3406)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2966)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2952)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:420)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
> at
> java.util.concurrent.Th
[jira] [Updated] (CLOUDSTACK-4580) [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able to start existing Vms after stopping them.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan updated CLOUDSTACK-4580:
Assignee: (was: edison su)
> [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able to start existing Vms
> after stopping them.
> --
>
> Key: CLOUDSTACK-4580
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4580
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: Upgrade from 2.2.14 - 4.2
>Reporter: Sangeetha Hariharan
>Priority: Blocker
> Fix For: 4.2.0
>
>
> [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able to start existing Vms
> after stopping them.
> Have a 2.2.14 set with 2 KVM hosts - rhel 6.0 in cluster.
> Upgrade to 4.2
> Stop an existing Vm (that was deployed from 4.2)
> Not able to start Vm.
> Following exception seen in management server log:
> 2013-08-30 23:50:35,797 DEBUG [agent.transport.Request]
> (Job-Executor-10:job-34 = [ 9c59d52b-2d06-4241-a3e2-9970e3028f7
> 7 ]) Seq 1-1982333139: Sending { Cmd , MgmtId: 6860035851996, via: 1, Ver:
> v1, Flags: 100111, [{"com.cloud.agent.api.S
> tartCommand":{"vm":{"id":10,"name":"i-3-10-VM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,
> "maxRam":536870912,"arch":"x86_64","os":"CentOS 5.5
> (64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"lim
> itCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"5576a472a48abfb5","params":{"Message.ReservedCapacityFr
> eed.Flag":"false"},"uuid":"10","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"10","volume
> Type":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"f691b1f4-e2a1-3777-8747-eda71b
> 158aba","id":200,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/sangeetha/2214-kvm/primary
> ","port":2049}},"name":"ROOT-10","size":8589934592,"path":"9decf018-6da0-410d-9e8d-1b1f4b25e55a","volumeId":10,"vmName"
> :"i-3-10-VM","accountId":3,"format":"QCOW2","id":10,"hypervisorType":"KVM"}},"diskSeq":0,"type":"ROOT"},{"data":{"org.a
> pache.cloudstack.storage.to.TemplateObjectTO":{"id":0,"format":"ISO","accountId":0,"hvm":false}},"diskSeq":3,"type":"IS
> O"}],"nics":[{"deviceId":0,"networkRateMbps":200,"defaultNic":true,"uuid":"24","ip":"10.1.1.140","netmask":"255.255.255
> .0","gateway":"10.1.1.1","mac":"02:00:1a:5d:00:04","dns1":"72.52.126.11","dns2":"72.52.126.12","broadcastType":"Vlan","
> type":"Guest","broadcastUri":"vlan://2307","isolationUri":"vlan://2307","isSecurityGroupEnabled":false}]},"hostIp":"10.
> 223.58.66","executeInSequence":true,"wait":0}}] }
> 2013-08-30 23:50:35,936 DEBUG [agent.transport.Request]
> (AgentManager-Handler-5:null) Seq 1-1982333139: Processing: {
> Ans: , MgmtId: 6860035851996, via: 1, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":10,"name":"i
> -3-10-VM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,"maxRam":536870912,"arch":"x86_64","o
> s":"CentOS 5.5
> (64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallySca
> leVm":false,"vncPassword":"5576a472a48abfb5","vncAddr":"10.223.58.66","params":{"Message.ReservedCapacityFreed.Flag":"f
> alse"},"uuid":"10","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"10","volumeType":"ROOT"
> ,"dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"f691b1f4-e2a1-3777-8747-eda71b158aba","id"
> :200,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/sangeetha/2214-kvm/primary","port":204
> 9}},"name":"ROOT-10","size":8589934592,"path":"9decf018-6da0-410d-9e8d-1b1f4b25e55a","volumeId":10,"vmName":"i-3-10-VM"
> ,"accountId":3,"format":"QCOW2","id":10,"hypervisorType":"KVM"}},"diskSeq":0,"type":"ROOT"},{"data":{"org.apache.clouds
> tack.storage.to.TemplateObjectTO":{"id":0,"format":"ISO","accountId":0,"hvm":false}},"diskSeq":3,"type":"ISO"}],"nics":
> [{"deviceId":0,"networkRateMbps":200,"defaultNic":true,"uuid":"24","ip":"10.1.1.140","netmask":"255.255.255.0","gateway
> ":"10.1.1.1","mac":"02:00:1a:5d:00:04","dns1":"72.52.126.11","dns2":"72.52.126.12","broadcastType":"Vlan","type":"Guest
> ","broadcastUri":"vlan://2307","isolationUri":"vlan://2307","isSecurityGroupEnabled":false}]},"result":false,"details":
> "internal error malformed uuid element","wait":0}}] }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.co
[jira] [Updated] (CLOUDSTACK-4579) [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able to deploy Vms with existing templates.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan updated CLOUDSTACK-4579:
Assignee: (was: edison su)
> [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able to deploy Vms with
> existing templates.
> --
>
> Key: CLOUDSTACK-4579
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4579
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: Upgrade from 2.2.14 - > 4.2 with rhel 6.0 hosts.
>Reporter: Sangeetha Hariharan
>Priority: Blocker
> Fix For: 4.2.0
>
>
> Deploy a 2.2.14 setup with 2 rhel 6.0 hosts in cluster.
> Upgrade to 4.2.
> Deploy a new VM using an existing template.
> Vm deployment fails with following exception in the management server logs:
> 2013-08-31 00:02:35,408 DEBUG [agent.transport.Request]
> (AgentManager-Handler-4:null) Seq 2-1176895727: Processing: { Ans: , MgmtId:
> 6860035851996, via: 2, Ver: v1, Flags: 110,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"result":false,"details":"com.cloud.utils.exception.CloudRuntimeException:
> com.cloud.utils.exception.CloudRuntimeException: Can't find
> volume:/mnt/f691b1f4-e2a1-3777-8747-eda71b158aba/db0c5f4f-86d0-4aa6-9e06-ff91ad3a62ff","wait":0}}]
> }
> 2013-08-31 00:02:35,408 DEBUG [agent.manager.AgentAttache]
> (AgentManager-Handler-4:null) Seq 2-1176895727: No more commands found
> 2013-08-31 00:02:35,408 DEBUG [agent.transport.Request]
> (Job-Executor-11:job-35 = [ 4b0d3b97-1cc9-4edc-85d5-80cd7add0035 ]) Seq
> 2-1176895727: Received: { Ans: , MgmtId: 6860035851996, via: 2, Ver: v1,
> Flags: 110, { CopyCmdAnswer } }
> 2013-08-31 00:02:35,413 WARN
> [storage.datastore.ObjectInDataStoreManagerImpl] (Job-Executor-11:job-35 = [
> 4b0d3b97-1cc9-4edc-85d5-80cd7add0035 ]) Unsupported data object (VOLUME,
> org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@523f72ca), no
> need to delete from object in store ref table
> 2013-08-31 00:02:35,413 DEBUG [cloud.storage.VolumeManagerImpl]
> (Job-Executor-11:job-35 = [ 4b0d3b97-1cc9-4edc-85d5-80cd7add0035 ]) Unable to
> create Vol[17|vm=14|ROOT]:com.cloud.utils.exception.CloudRuntimeException:
> com.cloud.utils.exception.CloudRuntimeException: Can't find
> volume:/mnt/f691b1f4-e2a1-3777-8747-eda71b158aba/db0c5f4f-86d0-4aa6-9e06-ff91ad3a62ff
> 2013-08-31 00:02:35,413 INFO [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-11:job-35 = [ 4b0d3b97-1cc9-4edc-85d5-80cd7add0035 ]) Unable to
> contact resource.
> com.cloud.exception.StorageUnavailableException: Resource [StoragePool:200]
> is unreachable: Unable to create
> Vol[17|vm=14|ROOT]:com.cloud.utils.exception.CloudRuntimeException:
> com.cloud.utils.exception.CloudRuntimeException: Can't find
> volume:/mnt/f691b1f4-e2a1-3777-8747-eda71b158aba/db0c5f4f-86d0-4aa6-9e06-ff91ad3a62ff
> at
> com.cloud.storage.VolumeManagerImpl.recreateVolume(VolumeManagerImpl.java:2544)
> at
> com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2592)
> 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:227)
> at
> org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3406)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2966)
> at
> com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2952)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:420)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.ru
[jira] [Created] (CLOUDSTACK-4580) [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able to start existing Vms after stopping them.
Sangeetha Hariharan created CLOUDSTACK-4580:
---
Summary: [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able
to start existing Vms after stopping them.
Key: CLOUDSTACK-4580
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4580
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server
Affects Versions: 4.2.0
Environment: Upgrade from 2.2.14 - 4.2
Reporter: Sangeetha Hariharan
Assignee: edison su
Priority: Blocker
Fix For: 4.2.0
[Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able to start existing Vms
after stopping them.
Have a 2.2.14 set with 2 KVM hosts - rhel 6.0 in cluster.
Upgrade to 4.2
Stop an existing Vm (that was deployed from 4.2)
Not able to start Vm.
Following exception seen in management server log:
2013-08-30 23:50:35,797 DEBUG [agent.transport.Request] (Job-Executor-10:job-34
= [ 9c59d52b-2d06-4241-a3e2-9970e3028f7
7 ]) Seq 1-1982333139: Sending { Cmd , MgmtId: 6860035851996, via: 1, Ver: v1,
Flags: 100111, [{"com.cloud.agent.api.S
tartCommand":{"vm":{"id":10,"name":"i-3-10-VM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,
"maxRam":536870912,"arch":"x86_64","os":"CentOS 5.5
(64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"lim
itCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"5576a472a48abfb5","params":{"Message.ReservedCapacityFr
eed.Flag":"false"},"uuid":"10","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"10","volume
Type":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"f691b1f4-e2a1-3777-8747-eda71b
158aba","id":200,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/sangeetha/2214-kvm/primary
","port":2049}},"name":"ROOT-10","size":8589934592,"path":"9decf018-6da0-410d-9e8d-1b1f4b25e55a","volumeId":10,"vmName"
:"i-3-10-VM","accountId":3,"format":"QCOW2","id":10,"hypervisorType":"KVM"}},"diskSeq":0,"type":"ROOT"},{"data":{"org.a
pache.cloudstack.storage.to.TemplateObjectTO":{"id":0,"format":"ISO","accountId":0,"hvm":false}},"diskSeq":3,"type":"IS
O"}],"nics":[{"deviceId":0,"networkRateMbps":200,"defaultNic":true,"uuid":"24","ip":"10.1.1.140","netmask":"255.255.255
.0","gateway":"10.1.1.1","mac":"02:00:1a:5d:00:04","dns1":"72.52.126.11","dns2":"72.52.126.12","broadcastType":"Vlan","
type":"Guest","broadcastUri":"vlan://2307","isolationUri":"vlan://2307","isSecurityGroupEnabled":false}]},"hostIp":"10.
223.58.66","executeInSequence":true,"wait":0}}] }
2013-08-30 23:50:35,936 DEBUG [agent.transport.Request]
(AgentManager-Handler-5:null) Seq 1-1982333139: Processing: {
Ans: , MgmtId: 6860035851996, via: 1, Ver: v1, Flags: 110,
[{"com.cloud.agent.api.StartAnswer":{"vm":{"id":10,"name":"i
-3-10-VM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,"maxRam":536870912,"arch":"x86_64","o
s":"CentOS 5.5
(64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallySca
leVm":false,"vncPassword":"5576a472a48abfb5","vncAddr":"10.223.58.66","params":{"Message.ReservedCapacityFreed.Flag":"f
alse"},"uuid":"10","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"10","volumeType":"ROOT"
,"dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"f691b1f4-e2a1-3777-8747-eda71b158aba","id"
:200,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/sangeetha/2214-kvm/primary","port":204
9}},"name":"ROOT-10","size":8589934592,"path":"9decf018-6da0-410d-9e8d-1b1f4b25e55a","volumeId":10,"vmName":"i-3-10-VM"
,"accountId":3,"format":"QCOW2","id":10,"hypervisorType":"KVM"}},"diskSeq":0,"type":"ROOT"},{"data":{"org.apache.clouds
tack.storage.to.TemplateObjectTO":{"id":0,"format":"ISO","accountId":0,"hvm":false}},"diskSeq":3,"type":"ISO"}],"nics":
[{"deviceId":0,"networkRateMbps":200,"defaultNic":true,"uuid":"24","ip":"10.1.1.140","netmask":"255.255.255.0","gateway
":"10.1.1.1","mac":"02:00:1a:5d:00:04","dns1":"72.52.126.11","dns2":"72.52.126.12","broadcastType":"Vlan","type":"Guest
","broadcastUri":"vlan://2307","isolationUri":"vlan://2307","isSecurityGroupEnabled":false}]},"result":false,"details":
"internal error malformed uuid element","wait":0}}] }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4579) [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able to deploy Vms with existing templates.
Sangeetha Hariharan created CLOUDSTACK-4579:
---
Summary: [Upgrade 2.2.14 - 4.2][KVM] - After upgrade , Not able
to deploy Vms with existing templates.
Key: CLOUDSTACK-4579
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4579
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server
Affects Versions: 4.2.0
Environment: Upgrade from 2.2.14 - > 4.2 with rhel 6.0 hosts.
Reporter: Sangeetha Hariharan
Assignee: edison su
Priority: Blocker
Fix For: 4.2.0
Deploy a 2.2.14 setup with 2 rhel 6.0 hosts in cluster.
Upgrade to 4.2.
Deploy a new VM using an existing template.
Vm deployment fails with following exception in the management server logs:
2013-08-31 00:02:35,408 DEBUG [agent.transport.Request]
(AgentManager-Handler-4:null) Seq 2-1176895727: Processing: { Ans: , MgmtId:
6860035851996, via: 2, Ver: v1, Flags: 110,
[{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"result":false,"details":"com.cloud.utils.exception.CloudRuntimeException:
com.cloud.utils.exception.CloudRuntimeException: Can't find
volume:/mnt/f691b1f4-e2a1-3777-8747-eda71b158aba/db0c5f4f-86d0-4aa6-9e06-ff91ad3a62ff","wait":0}}]
}
2013-08-31 00:02:35,408 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-4:null) Seq 2-1176895727: No more commands found
2013-08-31 00:02:35,408 DEBUG [agent.transport.Request] (Job-Executor-11:job-35
= [ 4b0d3b97-1cc9-4edc-85d5-80cd7add0035 ]) Seq 2-1176895727: Received: { Ans:
, MgmtId: 6860035851996, via: 2, Ver: v1, Flags: 110, { CopyCmdAnswer } }
2013-08-31 00:02:35,413 WARN [storage.datastore.ObjectInDataStoreManagerImpl]
(Job-Executor-11:job-35 = [ 4b0d3b97-1cc9-4edc-85d5-80cd7add0035 ]) Unsupported
data object (VOLUME,
org.apache.cloudstack.storage.datastore.PrimaryDataStoreImpl@523f72ca), no need
to delete from object in store ref table
2013-08-31 00:02:35,413 DEBUG [cloud.storage.VolumeManagerImpl]
(Job-Executor-11:job-35 = [ 4b0d3b97-1cc9-4edc-85d5-80cd7add0035 ]) Unable to
create Vol[17|vm=14|ROOT]:com.cloud.utils.exception.CloudRuntimeException:
com.cloud.utils.exception.CloudRuntimeException: Can't find
volume:/mnt/f691b1f4-e2a1-3777-8747-eda71b158aba/db0c5f4f-86d0-4aa6-9e06-ff91ad3a62ff
2013-08-31 00:02:35,413 INFO [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-11:job-35 = [ 4b0d3b97-1cc9-4edc-85d5-80cd7add0035 ]) Unable to
contact resource.
com.cloud.exception.StorageUnavailableException: Resource [StoragePool:200] is
unreachable: Unable to create
Vol[17|vm=14|ROOT]:com.cloud.utils.exception.CloudRuntimeException:
com.cloud.utils.exception.CloudRuntimeException: Can't find
volume:/mnt/f691b1f4-e2a1-3777-8747-eda71b158aba/db0c5f4f-86d0-4aa6-9e06-ff91ad3a62ff
at
com.cloud.storage.VolumeManagerImpl.recreateVolume(VolumeManagerImpl.java:2544)
at
com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2592)
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:227)
at
org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209)
at
com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3406)
at
com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2966)
at
com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2952)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:420)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
at
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:679)
2013-08-31 00:02:35,418 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-11:job-35 = [ 4b0d3b97-1cc9-4edc-85d5-80cd7add0035 ]) Cleaning up
resources for the vm VM[User|test123] in Starting state
2013-08-31 00:02:35,420 DEBUG [agent.transport.Request] (Job-Executor-11:job-35
=
[jira] [Updated] (CLOUDSTACK-4578) [vmware]SSVM is not getting created if one host down from a cluster
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-4578: Description: Steps to reproduce Step 1 : Create vmware advanced zone with 2 host in a cluster (HA not enabled ) Step 2 : Check SSVM, in which host is running Step 3 : Shutdown the host, in where SSVM is running Expected Result New SSVM should be created on second host (Running Host) Actual result -- SSVM is not getting created on second host; Work around -- You need to forcefully stop SSVM trough API, then new SSVM gets created on second host We need to document this was: Steps to reproduce Step 1 : Create vmware advanced zone with 2 host in a cluster (HA not enabled ) Step 2 : Check SSVM, in which host is running Step 3 : Shutdown the host, in where SSVM is running Expected Result New SSVM should be created on second host (Running Host) Actual result -- SSVM is not getting created on second host; Work around -- You need to stop SSVM trough API, then new SSVM gets created on second host We need to document this > [vmware]SSVM is not getting created if one host down from a cluster > --- > > Key: CLOUDSTACK-4578 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4578 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0 > Environment: Vmware > 4.2.-forward >Reporter: Rayees Namathponnan > Fix For: 4.2.1 > > Attachments: CLOUDSTACK-4578.rar > > > Steps to reproduce > Step 1 : Create vmware advanced zone with 2 host in a cluster (HA not > enabled ) > Step 2 : Check SSVM, in which host is running > Step 3 : Shutdown the host, in where SSVM is running > Expected Result > > New SSVM should be created on second host (Running Host) > Actual result > -- > SSVM is not getting created on second host; > Work around > -- > You need to forcefully stop SSVM trough API, then new SSVM gets created on > second host > We need to document this -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4578) [vmware]SSVM is not getting created if one host down from a cluster
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-4578: Description: Steps to reproduce Step 1 : Create vmware advanced zone with 2 host in a cluster (HA not enabled ) Step 2 : Check SSVM, in which host is running Step 3 : Shutdown the host, in where SSVM is running Expected Result New SSVM should be created on second host (Running Host) Actual result -- SSVM is not getting created on second host; Work around -- You need to force fully stop SSVM trough API, then new SSVM gets created on second host We need to document this was: Steps to reproduce Step 1 : Create vmware advanced zone with 2 host in a cluster (HA not enabled ) Step 2 : Check SSVM, in which host is running Step 3 : Shutdown the host, in where SSVM is running Expected Result New SSVM should be created on second host (Running Host) Actual result -- SSVM is not getting created on second host; Work around -- You need to forcefully stop SSVM trough API, then new SSVM gets created on second host We need to document this > [vmware]SSVM is not getting created if one host down from a cluster > --- > > Key: CLOUDSTACK-4578 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4578 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0 > Environment: Vmware > 4.2.-forward >Reporter: Rayees Namathponnan > Fix For: 4.2.1 > > Attachments: CLOUDSTACK-4578.rar > > > Steps to reproduce > Step 1 : Create vmware advanced zone with 2 host in a cluster (HA not > enabled ) > Step 2 : Check SSVM, in which host is running > Step 3 : Shutdown the host, in where SSVM is running > Expected Result > > New SSVM should be created on second host (Running Host) > Actual result > -- > SSVM is not getting created on second host; > Work around > -- > You need to force fully stop SSVM trough API, then new SSVM gets created on > second host > We need to document this -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4578) [vmware]SSVM is not getting created if one host down from a cluster
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-4578: Attachment: CLOUDSTACK-4578.rar > [vmware]SSVM is not getting created if one host down from a cluster > --- > > Key: CLOUDSTACK-4578 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4578 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0 > Environment: Vmware > 4.2.-forward >Reporter: Rayees Namathponnan > Fix For: 4.2.1 > > Attachments: CLOUDSTACK-4578.rar > > > Steps to reproduce > Step 1 : Create vmware advanced zone with 2 host in a cluster (HA not > enabled ) > Step 2 : Check SSVM, in which host is running > Step 3 : Shutdown the host, in where SSVM is running > Expected Result > > New SSVM should be created on second host (Running Host) > Actual result > -- > SSVM is not getting created on second host; > Work around > -- > You need to stop SSVM trough API, then new SSVM gets created on second host > We need to document this -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4578) [vmware]SSVM is not getting created if one host down from a cluster
Rayees Namathponnan created CLOUDSTACK-4578: --- Summary: [vmware]SSVM is not getting created if one host down from a cluster Key: CLOUDSTACK-4578 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4578 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.2.0 Environment: Vmware 4.2.-forward Reporter: Rayees Namathponnan Fix For: 4.2.1 Steps to reproduce Step 1 : Create vmware advanced zone with 2 host in a cluster (HA not enabled ) Step 2 : Check SSVM, in which host is running Step 3 : Shutdown the host, in where SSVM is running Expected Result New SSVM should be created on second host (Running Host) Actual result -- SSVM is not getting created on second host; Work around -- You need to stop SSVM trough API, then new SSVM gets created on second host We need to document this -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4577) VMWare:Volumes: Unexpected exception while executing org.apache.cloudstack.api.command.user.volume.ResizeVolumeCmd java.lang.NullPointerException
Parth Jagirdar created CLOUDSTACK-4577:
--
Summary: VMWare:Volumes: Unexpected exception while executing
org.apache.cloudstack.api.command.user.volume.ResizeVolumeCmd
java.lang.NullPointerException
Key: CLOUDSTACK-4577
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4577
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: VMware, Volumes
Affects Versions: 4.2.1
Environment: VMWare,
5 Primary; 2 Zone wide and Rest Cluster.
Attach Data Disk and attempt a Re-size.
Reporter: Parth Jagirdar
Priority: Critical
Logs attached.
2013-08-30 16:12:14,513 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-8:null) SeqA 9-1571: Processing Seq 9-1571: { Cmd ,
MgmtId: -1, via: 9, Ver: v1, Flags: 11,
[{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":30,"_loadInfo":"{\n
\"connections\": []\n}","wait":0}}] }
2013-08-30 16:12:14,520 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-8:null) SeqA 9-1571: Sending Seq 9-1571: { Ans: ,
MgmtId: 7471666038533, via: 9, Ver: v1, Flags: 100010,
[{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
2013-08-30 16:12:18,099 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-10:null) Ping from 10
2013-08-30 16:12:24,514 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-11:null) SeqA 9-1572: Processing Seq 9-1572: { Cmd ,
MgmtId: -1, via: 9, Ver: v1, Flags: 11,
[{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":30,"_loadInfo":"{\n
\"connections\": []\n}","wait":0}}] }
2013-08-30 16:12:24,523 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-11:null) SeqA 9-1572: Sending Seq 9-1572: { Ans: ,
MgmtId: 7471666038533, via: 9, Ver: v1, Flags: 100010,
[{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
2013-08-30 16:12:34,514 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-12:null) SeqA 9-1573: Processing Seq 9-1573: { Cmd ,
MgmtId: -1, via: 9, Ver: v1, Flags: 11,
[{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":30,"_loadInfo":"{\n
\"connections\": []\n}","wait":0}}] }
2013-08-30 16:12:34,520 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-12:null) SeqA 9-1573: Sending Seq 9-1573: { Ans: ,
MgmtId: 7471666038533, via: 9, Ver: v1, Flags: 100010,
[{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
2013-08-30 16:12:34,839 DEBUG [cloud.server.StatsCollector]
(StatsCollector-1:null) HostStatsCollector is running...
2013-08-30 16:12:34,849 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-492:null) Seq 1-1168048937: Executing request
2013-08-30 16:12:34,877 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-492:null) Seq 1-1168048937: Response Received:
2013-08-30 16:12:34,877 DEBUG [agent.transport.Request] (StatsCollector-1:null)
Seq 1-1168048937: Received: { Ans: , MgmtId: 7471666038533, via: 1, Ver: v1,
Flags: 10, { GetHostStatsAnswer } }
2013-08-30 16:12:34,918 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-493:null) Seq 6-580518619: Executing request
2013-08-30 16:12:34,940 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-493:null) Seq 6-580518619: Response Received:
2013-08-30 16:12:34,940 DEBUG [agent.transport.Request] (StatsCollector-1:null)
Seq 6-580518619: Received: { Ans: , MgmtId: 7471666038533, via: 6, Ver: v1,
Flags: 10, { GetHostStatsAnswer } }
2013-08-30 16:12:34,957 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-494:null) Seq 8-2005992046: Executing request
2013-08-30 16:12:34,974 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-494:null) Seq 8-2005992046: Response Received:
2013-08-30 16:12:34,975 DEBUG [agent.transport.Request] (StatsCollector-1:null)
Seq 8-2005992046: Received: { Ans: , MgmtId: 7471666038533, via: 8, Ver: v1,
Flags: 10, { GetHostStatsAnswer } }
2013-08-30 16:12:35,099 DEBUG [storage.secondary.SecondaryStorageManagerImpl]
(secstorage-1:null) Zone 1 is ready to launch secondary storage VM
2013-08-30 16:12:35,261 DEBUG [cloud.consoleproxy.ConsoleProxyManagerImpl]
(consoleproxy-1:null) Zone 1 is ready to launch console proxy
2013-08-30 16:12:36,129 DEBUG
[network.router.VirtualNetworkApplianceManagerImpl]
(RouterStatusMonitor-1:null) Found 2 routers to update status.
2013-08-30 16:12:36,131 DEBUG
[network.router.VirtualNetworkApplianceManagerImpl]
(RouterStatusMonitor-1:null) Found 0 networks to update RvR status.
2013-08-30 16:12:36,229 DEBUG
[network.router.VirtualNetworkApplianceManagerImpl]
(RouterStatusMonitor-1:null) Found 2 routers to update status.
2013-08-30 16:12:36,230 DEBUG
[network.router.VirtualNetworkApplianceManagerImpl]
(RouterStatusMonitor-1:null) Found 0 networks to update RvR status.
2013-08-30 16:12:44,514 DEBUG
[jira] [Commented] (CLOUDSTACK-4475) [ZWPS] attaching an uploaded volume to a VM is always going to first primary storage added
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13754953#comment-13754953 ] edison su commented on CLOUDSTACK-4475: --- The main issue of this bug is: if cluster primary storage and zone wide primary storage are mixed together, the data disk by default will be created on cluster wide primary storage. If admin wants data disk been created on zone wide primary storage, then need to create a disk offering with the tag on zone wide primary storage. > [ZWPS] attaching an uploaded volume to a VM is always going to first primary > storage added > -- > > Key: CLOUDSTACK-4475 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4475 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc, Storage Controller >Affects Versions: 4.2.1 > Environment: vmware esxi 5.1 >Reporter: Srikanteswararao Talluri >Assignee: edison su > Labels: ReleaseNote > Fix For: 4.2.1 > > > Steps to reproduce: > == > 1. Have an advanced zone deployment with two cluster one host and one cluster > scoped primary storage each > 2. add two more zone wide primary storages > 3. create a deployment on zone scoped primary storage > 4. upload a volume. > 5. attach uploaded volume to VM created in step 3. > Observation: > = > While attaching volume, volume is always copied to first available primary > storage in the storage_pool table and as a result attaching a volume created > on cluster scoped primary storage to a VM with its root volume on zone wide > primary storage fails. > mysql> select * from storage_pool; > ++--+--+---+--++++---++--+---++-+-+-+-+---+-++-+---+ > | id | name | uuid | pool_type > | port | data_center_id | pod_id | cluster_id | used_bytes| > capacity_bytes | host_address | user_info | path > | created | removed | update_time | status | > storage_provider_name | scope | hypervisor | managed | capacity_iops | > ++--+--+---+--++++---++--+---++-+-+-+-+---+-++-+---+ > | 1 | primaryclus1 | 722e6181-8497-3d31-9933-a0a267ae376c | > NetworkFilesystem | 2049 | 1 | 1 | 1 | > 1678552014848 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/primary | 2013-08-23 12:11:12 | NULL > | NULL| Maintenance | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 2 | pimaryclu2 | 9fd9b0fc-c9fd-39b8-8d66-06372c5ff6d2 | > NetworkFilesystem | 2049 | 1 | 1 | 2 | > 1676566495232 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/clus1primary | 2013-08-23 12:18:14 | NULL > | NULL| Up | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 3 | clus1p2 | 22e0c3fe-a390-38fa-8ff7-e1d965a36309 | > NetworkFilesystem | 2049 | 1 | 1 | 1 | > 1660903886848 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/clus1p2 | 2013-08-23 14:30:32 | NULL > | NULL| Up | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 4 | clus1p3 | f2d9fb6b-c433-3c03-acf8-8f73eac48fae | > NetworkFilesystem | 2049 | 1 | 1 | 1 | > 1660901400576 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/clus1p3 | 2013-08-23 14:31:05 | NULL > | NULL| Up | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 5 | clus2p2 | 13bf579c-51f3-317b-893a-98ff6ca8f486 | > NetworkFilesystem | 2049 | 1 | 1 | 2 | > 1660900147200 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/clus2p2 | 2013-08-23 14:31:38 | NULL > | NULL| Up | DefaultPrimary| CLUSTER | NULL
[jira] [Updated] (CLOUDSTACK-4497) [doc] Update Installation Guide
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Tomechak updated CLOUDSTACK-4497: - Description: • Update the supported operating systems and hypervisor versions. • Where the current documentation directs you to run the script cloud-setup-databases, use the following name instead: cloudstack-setup-databases. • When seeding the system VM template, use the following new path to the script: /usr/share/ cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt. • The location of Management Server configuration and properties files is now /etc/cloudstack/ management/. For example, in database failover setup (an optional part of installation), where the current documentation shows /etc/cloud/management/db.properties, use the following path instead: /etc/cloudstack/management/db.properties. • The names of the Management Server and Usage Server services have changed to cloudstack- management and cloudstack-usage. Use this name in commands to start, stop, or restart these services. • System VM templates have changed. Be sure to download the latest templates from Location: To Be Supplied • The location of the Management Server log file is now /var/log/cloudstack/management/. • (XenServer only) The script cloud-setup-bonding.sh is now located at /usr/share/cloudstack- common/scripts/vm/hypervisor/xenserver/. • (XenServer only) In the procedure for upgrading XenServer versions, you copy some files from the Management Server to the XenServer host. The new location of these files on the Management Server is /usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver and /usr/share/cloudstack- common/scripts/vm/hypervisor/xenserver/xenserver60. • (KVM only) During network configuration, where the current documentation shows /etc/cloud/agent/agent.properties, use the following path instead: /etc/cloudstack/agent/agent.properties. • (KVM only) The location of the CloudPlatform KVM agent log file is now /var/log/cloudstack/agent/. • (KVM only) The location of configuration and properties files is now /etc/cloudstack/agent. • (KVM only) The name of the CloudPlatform agent script has changed to cloudstack-agent. Use this name if you need to stop or restart the agent on the KVM host. was: Update the supported operating systems and hypervisor versions. • Where the current documentation directs you to run the script cloud-setup-databases, use the following name instead: cloudstack-setup-databases. • When seeding the system VM template, use the following new path to the script: /usr/share/ cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt. • The location of Management Server configuration and properties files is now /etc/cloudstack/ management/. For example, in database failover setup (an optional part of installation), where the current documentation shows /etc/cloud/management/db.properties, use the following path instead: /etc/cloudstack/management/db.properties. • The names of the Management Server and Usage Server services have changed to cloudstack- management and cloudstack-usage. Use this name in commands to start, stop, or restart these services. • System VM templates have changed. Be sure to download the latest templates from Location: To Be Supplied • The location of the Management Server log file is now /var/log/cloudstack/management/. • (XenServer only) The script cloud-setup-bonding.sh is now located at /usr/share/cloudstack- common/scripts/vm/hypervisor/xenserver/. • (XenServer only) In the procedure for upgrading XenServer versions, you copy some files from the Management Server to the XenServer host. The new location of these files on the Management Server is /usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver and /usr/share/cloudstack- common/scripts/vm/hypervisor/xenserver/xenserver60. • (KVM only) During network configuration, where the current documentation shows /etc/cloud/agent/agent.properties, use the following path instead: /etc/cloudstack/agent/agent.properties. • (KVM only) The location of the CloudPlatform KVM agent log file is now /var/log/cloudstack/agent/. • (KVM only) The location of configuration and properties files is now /etc/cloudstack/agent. • (KVM only) The name of the CloudPlatform agent script has changed to cloudstack-agent. Use this name if you need to stop or restart the agent on the KVM host. > [doc] Update Installation Guide > --- > > Key: CLOUDSTACK-4497 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4497 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Reporter: Radhika Nair > > • Update the supported operating systems and
[jira] [Commented] (CLOUDSTACK-4475) [ZWPS] attaching an uploaded volume to a VM is always going to first primary storage added
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13755215#comment-13755215 ] Parth Jagirdar commented on CLOUDSTACK-4475: Mixed storage; migrate from cluster to zone wide; no storage pools are listed. > [ZWPS] attaching an uploaded volume to a VM is always going to first primary > storage added > -- > > Key: CLOUDSTACK-4475 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4475 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc, Storage Controller >Affects Versions: 4.2.1 > Environment: vmware esxi 5.1 >Reporter: Srikanteswararao Talluri >Assignee: edison su > Labels: ReleaseNote > Fix For: 4.2.1 > > > Steps to reproduce: > == > 1. Have an advanced zone deployment with two cluster one host and one cluster > scoped primary storage each > 2. add two more zone wide primary storages > 3. create a deployment on zone scoped primary storage > 4. upload a volume. > 5. attach uploaded volume to VM created in step 3. > Observation: > = > While attaching volume, volume is always copied to first available primary > storage in the storage_pool table and as a result attaching a volume created > on cluster scoped primary storage to a VM with its root volume on zone wide > primary storage fails. > mysql> select * from storage_pool; > ++--+--+---+--++++---++--+---++-+-+-+-+---+-++-+---+ > | id | name | uuid | pool_type > | port | data_center_id | pod_id | cluster_id | used_bytes| > capacity_bytes | host_address | user_info | path > | created | removed | update_time | status | > storage_provider_name | scope | hypervisor | managed | capacity_iops | > ++--+--+---+--++++---++--+---++-+-+-+-+---+-++-+---+ > | 1 | primaryclus1 | 722e6181-8497-3d31-9933-a0a267ae376c | > NetworkFilesystem | 2049 | 1 | 1 | 1 | > 1678552014848 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/primary | 2013-08-23 12:11:12 | NULL > | NULL| Maintenance | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 2 | pimaryclu2 | 9fd9b0fc-c9fd-39b8-8d66-06372c5ff6d2 | > NetworkFilesystem | 2049 | 1 | 1 | 2 | > 1676566495232 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/clus1primary | 2013-08-23 12:18:14 | NULL > | NULL| Up | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 3 | clus1p2 | 22e0c3fe-a390-38fa-8ff7-e1d965a36309 | > NetworkFilesystem | 2049 | 1 | 1 | 1 | > 1660903886848 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/clus1p2 | 2013-08-23 14:30:32 | NULL > | NULL| Up | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 4 | clus1p3 | f2d9fb6b-c433-3c03-acf8-8f73eac48fae | > NetworkFilesystem | 2049 | 1 | 1 | 1 | > 1660901400576 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/clus1p3 | 2013-08-23 14:31:05 | NULL > | NULL| Up | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 5 | clus2p2 | 13bf579c-51f3-317b-893a-98ff6ca8f486 | > NetworkFilesystem | 2049 | 1 | 1 | 2 | > 1660900147200 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/clus2p2 | 2013-08-23 14:31:38 | NULL > | NULL| Up | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 7 | clus2p3 | 294ae9ff-cb02-33a0-8f31-21fdd8ff34db | > NetworkFilesystem | 2049 | 1 | 1 | 2 | > 1660894195712 | 590228480 | 10.147.28.7 | NULL | > /export/h
[jira] [Closed] (CLOUDSTACK-4576) [Portable IP] disassociating a transferred public IP is failing with exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti closed CLOUDSTACK-4576. Duplicate of 4575. closing this one > [Portable IP] disassociating a transferred public IP is failing with exception > -- > > Key: CLOUDSTACK-4576 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4576 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.1 >Reporter: Sudha Ponnaganti >Assignee: Chiradeep Vittal >Priority: Critical > Fix For: 4.2.0, 4.2.1 > > > Steps to reproduce: > 1. Have latest CloudStack with at least 2 advanced zone. > 2. Go to Regions -> local -> portable IP -> add an ip range like below > Gateway : 10.147.33.1 > startIp : 10.147.33.3 > endip : 10.147.33.10 > vlan : 33 > subnet : 255.255.255.128 > 3. login as a non-ROOT admin > username : dom1User1 > password : password > domain : dom1 > 4. create the following isolated networks in each zone > - Network1Zone1 > - Network1Zone2 > 5. deploy the following VMs in each network > - vm1Zone1 connected to Network1Zone1 > - vm1Zone2 connected to Network1Zone2 > 6. Acquire and associate a portable IP to Network1Zone1 > 7. enable staticNAT on the above portableIP and associate it to vm1Zone2 of > Network1Zone2 and add firewall rule for ssh port > > Observations: > (i) portable IP got transferred from Zone1 to Network1Zone2 successfully and > able ssh to the portable IP without any issuees. > > 8. disassociate above portable IP from Network1Zone2. > Observations: > (ii) sequence of things happened as mentioned below > - disassociate happened without any issues which cleaned the eth interface > from router etc.., but, > - it again initiated IPASSOC on its own for the same portable IP which > resulted in the following error and thus this IP stuck in release state > forever. > > (iii) above behaviour made all further IPASSOCs to fail. > Attaching all the required logs along with db dump to the bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-4575) [Portable IP] disassociating a transferred public IP is failing with exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti resolved CLOUDSTACK-4575. -- Resolution: Fixed > [Portable IP] disassociating a transferred public IP is failing with exception > -- > > Key: CLOUDSTACK-4575 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4575 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Reporter: Chiradeep Vittal > > Steps to reproduce: > 1. Have latest CloudStack with at least 2 advanced zone. > 2. Go to Regions -> local -> portable IP -> add an ip range like below > Gateway : 10.147.33.1 > startIp : 10.147.33.3 > endip : 10.147.33.10 > vlan : 33 > subnet : 255.255.255.128 > 3. login as a non-ROOT admin > username : dom1User1 > password : password > domain : dom1 > 4. create the following isolated networks in each zone > - Network1Zone1 > - Network1Zone2 > 5. deploy the following VMs in each network > - vm1Zone1 connected to Network1Zone1 > - vm1Zone2 connected to Network1Zone2 > 6. Acquire and associate a portable IP to Network1Zone1 > 7. enable staticNAT on the above portableIP and associate it to vm1Zone2 of > Network1Zone2 and add firewall rule for ssh port > Observations: > (i) portable IP got transferred from Zone1 to Network1Zone2 successfully and > able ssh to the portable IP without any issuees. > 8. disassociate above portable IP from Network1Zone2. > Observations: > (ii) sequence of things happened as mentioned below > - disassociate happened without any issues which cleaned the eth interface > from router etc.., but, > - it again initiated IPASSOC on its own for the same portable IP which > resulted in the following error and thus this IP stuck in release state > forever. > (iii) above behaviour made all further IPASSOCs to fail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-3765) [packaging][document] unable to upgrade cp 4.2 build on centos5.5
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13755183#comment-13755183 ] frank zhang commented on CLOUDSTACK-3765: - at latest release note, I don't see instructions to install repos mentioned in this bug. That is when upgrade usage server on rhel5/centos5, user must do rpm -Uvh http://download.cloud.com/support/jsvc/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm before uggrade > [packaging][document] unable to upgrade cp 4.2 build on centos5.5 > - > > Key: CLOUDSTACK-3765 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3765 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc, Packaging >Affects Versions: 4.2.0 > Environment: Centos5.5 >Reporter: shweta agarwal >Assignee: frank zhang >Priority: Critical > Fix For: 4.2.0 > > Attachments: Apache_CloudStack-4.2.0-Release_Notes-en-US.pdf > > > When I am trying to install > http://repo-ccp.citrix.com/releases/ASF/rhel/5/4.2/CP4.2-dbupgrade-44-rhel5.tar.gz > > I am hitting JSVC dependency error > When I tried to install jsvc via rpm its also failing giving error > rpm -Uvh > http://mirror.centos.org/centos/6/os/x86_64/Packages/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > Retrieving > http://mirror.centos.org/centos/6/os/x86_64/Packages/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm > warning: /var/tmp/rpm-xfer.qxSLPS: Header V3 RSA/SHA256 signature: NOKEY, key > ID c105b9de > error: Failed dependencies: > rpmlib(FileDigests) <= 4.6.0-1 is needed by > jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64 > rpmlib(PayloadIsXz) <= 5.2-1 is needed by > jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64 > Centos 5.5 repo does not contain any jsvc package > Infact at rpmfind location also JSVC package only exists for centos6.4 > http://rpmfind.net/linux/rpm2html/search.php?query=jsvc -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4089) Provide a drop down to specify VLAN,Switch type, Traffic label name while configuring Zone(VMWARE)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13755181#comment-13755181 ] ASF subversion and git services commented on CLOUDSTACK-4089: - Commit 94cd470a0ae52ca79b703b251c973a465232366c in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=94cd470 ] CLOUDSTACK-4089: UI > zone wizard > VMware hypervisor > physical network > edit Public/Guest traffic type > vSwitchType dropdown > set default option upon configuration 'vmware.use.dvswtich' and 'vmware.use.nexus.vswitch'. > Provide a drop down to specify VLAN,Switch type, Traffic label name while > configuring Zone(VMWARE) > -- > > Key: CLOUDSTACK-4089 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4089 > 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: Sailaja Mada >Assignee: Jessica Wang > Fix For: 4.2.0 > > Attachments: 2013-08-06-A.jpg, > addClusterCmd_wrongDuplicateParameterNames.jpg, dropPN.png, > edit-traffic-type-vmware.jpg > > > Observation: > Setup: VMWARE > 1. While configuring Zone, During Physical network creation , currently > there is a text field to specify VLAN Id for the traffic , Traffic label > name & Switch type (vmwaresvs,vmwaredvs,nexusdvs) > 2. It is text field and there is a possibility of missing some of the > parameters. > 3. While adding cluster we have an option to specify the traffic label name > and drop down to select the Switch type. > This is the request to provide a drop down to specify VLAN,Switch type, > Traffic label name while configuring Zone(VMWARE). This will avoid a lot of > confusion between Zone vs Cluster level configuration. > It also simplifies the configuration process. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4089) Provide a drop down to specify VLAN,Switch type, Traffic label name while configuring Zone(VMWARE)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13755180#comment-13755180 ] ASF subversion and git services commented on CLOUDSTACK-4089: - Commit 8d60e4436bbc71f62c52b2d3861ecad1cd82596b in branch refs/heads/4.2-forward from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8d60e44 ] CLOUDSTACK-4089: UI > zone wizard > VMware hypervisor > physical network > edit Public/Guest traffic type > vSwitchType dropdown > set default option upon configuration 'vmware.use.dvswtich' and 'vmware.use.nexus.vswitch'. > Provide a drop down to specify VLAN,Switch type, Traffic label name while > configuring Zone(VMWARE) > -- > > Key: CLOUDSTACK-4089 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4089 > 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: Sailaja Mada >Assignee: Jessica Wang > Fix For: 4.2.0 > > Attachments: 2013-08-06-A.jpg, > addClusterCmd_wrongDuplicateParameterNames.jpg, dropPN.png, > edit-traffic-type-vmware.jpg > > > Observation: > Setup: VMWARE > 1. While configuring Zone, During Physical network creation , currently > there is a text field to specify VLAN Id for the traffic , Traffic label > name & Switch type (vmwaresvs,vmwaredvs,nexusdvs) > 2. It is text field and there is a possibility of missing some of the > parameters. > 3. While adding cluster we have an option to specify the traffic label name > and drop down to select the Switch type. > This is the request to provide a drop down to specify VLAN,Switch type, > Traffic label name while configuring Zone(VMWARE). This will avoid a lot of > confusion between Zone vs Cluster level configuration. > It also simplifies the configuration process. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4089) Provide a drop down to specify VLAN,Switch type, Traffic label name while configuring Zone(VMWARE)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13755201#comment-13755201 ] ASF subversion and git services commented on CLOUDSTACK-4089: - Commit e826956290c5788a5eb9dd774b64e5f1d8cc3a1f in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e826956 ] CLOUDSTACK-4089: UI > zone wizard > VMware hypervisor > physical network > edit traffic type > set default value for vSwitchName field upon selected vSwitchType. > Provide a drop down to specify VLAN,Switch type, Traffic label name while > configuring Zone(VMWARE) > -- > > Key: CLOUDSTACK-4089 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4089 > 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: Sailaja Mada >Assignee: Jessica Wang > Fix For: 4.2.0 > > Attachments: 2013-08-06-A.jpg, > addClusterCmd_wrongDuplicateParameterNames.jpg, dropPN.png, > edit-traffic-type-vmware.jpg > > > Observation: > Setup: VMWARE > 1. While configuring Zone, During Physical network creation , currently > there is a text field to specify VLAN Id for the traffic , Traffic label > name & Switch type (vmwaresvs,vmwaredvs,nexusdvs) > 2. It is text field and there is a possibility of missing some of the > parameters. > 3. While adding cluster we have an option to specify the traffic label name > and drop down to select the Switch type. > This is the request to provide a drop down to specify VLAN,Switch type, > Traffic label name while configuring Zone(VMWARE). This will avoid a lot of > confusion between Zone vs Cluster level configuration. > It also simplifies the configuration process. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CLOUDSTACK-4300) [DOC] [upgrade][2.2.14 to 4.2][KVM] system vms are not coming up after upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti reopened CLOUDSTACK-4300: -- Assignee: Jessica Tomechak (was: edison su) > [DOC] [upgrade][2.2.14 to 4.2][KVM] system vms are not coming up after upgrade > -- > > Key: CLOUDSTACK-4300 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4300 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc, KVM, SystemVM, Upgrade >Affects Versions: 4.2.0 > Environment: Host : KVM [CentOS 6.1] > MS : CentOS 6.1 > upgrade from 2.2.14 to 4.2 >Reporter: Abhinav Roy >Assignee: Jessica Tomechak >Priority: Blocker > Fix For: 4.2.0 > > Attachments: CS-4300.zip, re_CS-4300.zip > > > Steps : > > 1. Deploy a CS 2.2.14 advanced zone setup with KVM host. > 2. do some operations like create vm, snapshots, templates, domain, accounts > etc > 3. upgrade to 4.2 > Expected behaviour : > === > Upgrade should go fine and new system vms should come up > Observed behaviour : > == > Upgrade went fine but system vms don't come up, they stay in the starting > state. > Attaching management server logs, catalina logs, agent logs and DB dumps -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4089) Provide a drop down to specify VLAN,Switch type, Traffic label name while configuring Zone(VMWARE)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13755200#comment-13755200 ] ASF subversion and git services commented on CLOUDSTACK-4089: - Commit ff4f931cd8b29983b5ad82675ccc65b651839a62 in branch refs/heads/4.2-forward from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ff4f931 ] CLOUDSTACK-4089: UI > zone wizard > VMware hypervisor > physical network > edit traffic type > set default value for vSwitchName field upon selected vSwitchType. > Provide a drop down to specify VLAN,Switch type, Traffic label name while > configuring Zone(VMWARE) > -- > > Key: CLOUDSTACK-4089 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4089 > 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: Sailaja Mada >Assignee: Jessica Wang > Fix For: 4.2.0 > > Attachments: 2013-08-06-A.jpg, > addClusterCmd_wrongDuplicateParameterNames.jpg, dropPN.png, > edit-traffic-type-vmware.jpg > > > Observation: > Setup: VMWARE > 1. While configuring Zone, During Physical network creation , currently > there is a text field to specify VLAN Id for the traffic , Traffic label > name & Switch type (vmwaresvs,vmwaredvs,nexusdvs) > 2. It is text field and there is a possibility of missing some of the > parameters. > 3. While adding cluster we have an option to specify the traffic label name > and drop down to select the Switch type. > This is the request to provide a drop down to specify VLAN,Switch type, > Traffic label name while configuring Zone(VMWARE). This will avoid a lot of > confusion between Zone vs Cluster level configuration. > It also simplifies the configuration process. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4576) [Portable IP] disassociating a transferred public IP is failing with exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-4576: - Assignee: Chiradeep Vittal > [Portable IP] disassociating a transferred public IP is failing with exception > -- > > Key: CLOUDSTACK-4576 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4576 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.1 >Reporter: Sudha Ponnaganti >Assignee: Chiradeep Vittal >Priority: Critical > Fix For: 4.2.0, 4.2.1 > > > Steps to reproduce: > 1. Have latest CloudStack with at least 2 advanced zone. > 2. Go to Regions -> local -> portable IP -> add an ip range like below > Gateway : 10.147.33.1 > startIp : 10.147.33.3 > endip : 10.147.33.10 > vlan : 33 > subnet : 255.255.255.128 > 3. login as a non-ROOT admin > username : dom1User1 > password : password > domain : dom1 > 4. create the following isolated networks in each zone > - Network1Zone1 > - Network1Zone2 > 5. deploy the following VMs in each network > - vm1Zone1 connected to Network1Zone1 > - vm1Zone2 connected to Network1Zone2 > 6. Acquire and associate a portable IP to Network1Zone1 > 7. enable staticNAT on the above portableIP and associate it to vm1Zone2 of > Network1Zone2 and add firewall rule for ssh port > > Observations: > (i) portable IP got transferred from Zone1 to Network1Zone2 successfully and > able ssh to the portable IP without any issuees. > > 8. disassociate above portable IP from Network1Zone2. > Observations: > (ii) sequence of things happened as mentioned below > - disassociate happened without any issues which cleaned the eth interface > from router etc.., but, > - it again initiated IPASSOC on its own for the same portable IP which > resulted in the following error and thus this IP stuck in release state > forever. > > (iii) above behaviour made all further IPASSOCs to fail. > Attaching all the required logs along with db dump to the bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4300) [Doc] [upgrade][2.2.14 to 4.2][KVM] system vms are not coming up after upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-4300: - Summary: [Doc] [upgrade][2.2.14 to 4.2][KVM] system vms are not coming up after upgrade (was: [DOC] [upgrade][2.2.14 to 4.2][KVM] system vms are not coming up after upgrade) > [Doc] [upgrade][2.2.14 to 4.2][KVM] system vms are not coming up after upgrade > -- > > Key: CLOUDSTACK-4300 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4300 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc, KVM, SystemVM, Upgrade >Affects Versions: 4.2.0 > Environment: Host : KVM [CentOS 6.1] > MS : CentOS 6.1 > upgrade from 2.2.14 to 4.2 >Reporter: Abhinav Roy >Assignee: Jessica Tomechak >Priority: Blocker > Fix For: 4.2.0 > > Attachments: CS-4300.zip, re_CS-4300.zip > > > Steps : > > 1. Deploy a CS 2.2.14 advanced zone setup with KVM host. > 2. do some operations like create vm, snapshots, templates, domain, accounts > etc > 3. upgrade to 4.2 > Expected behaviour : > === > Upgrade should go fine and new system vms should come up > Observed behaviour : > == > Upgrade went fine but system vms don't come up, they stay in the starting > state. > Attaching management server logs, catalina logs, agent logs and DB dumps -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4190) [Object_store_refactor] volume should be deleted from staging storage after successfule volume migration
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13755198#comment-13755198
]
Min Chen commented on CLOUDSTACK-4190:
--
For VMware, we noticed that there are several places requiring cleanup of
staging storage object, which requires a generic approach to thoroughly fix
them, and cannot make it in 4.2.0. Edited fix version to 4.2.1.
> [Object_store_refactor] volume should be deleted from staging storage after
> successfule volume migration
>
>
> Key: CLOUDSTACK-4190
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4190
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, Volumes
>Affects Versions: 4.2.0
> Environment: Latest build from ACS 4.2 branch
> Storage: S3 for image store, NFS for secondary staging and primary storage
>Reporter: Sanjeev N
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: cloud.dmp, cloud.dmp, cloud.rar, management-server.rar,
> management-server.rar
>
>
> volume copied to secondary staging storage during volume migration should be
> deleted after migration.
> Steps to Reproduce:
> =
> 1.Bring up CS with xen cluster using S3 from image store, NFS for secondary
> staging and primary storage
> 2.Deploy guest vm using default cent os template with both Root and Data
> disks.
> 3.Add another NFS based primary storage to the cluster
> 4.Detach data disk from the vm
> 5.Migrate the data disk to the primary storage created at step3
> Result:
> ==
> Volume migration was successful. But the volume copied to secondary staging
> storage during migration process did not get deleted.
> Only volume from source primary storage got deleted.
> Observations:
>
> Following is the log snippet during volume migration:
> 2013-08-08 08:34:49,766 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null)
> ===START=== 10.146.0.20 -- GET
> command=migrateVolume&storageid=29a0c990-7100-3a8d-b570-ba9f84ca78bc&volumeid=e1eb0b93-3fba-4437-ad50-b12bf1d6f1ef&response=json&sessionkey=qXfe5TLEOA5koD0qobFirCKKbOY%3D&_=1375965252817
> 2013-08-08 08:34:49,954 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-13:null) submit async job-44 = [
> 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ], details: AsyncJobVO {id:44, userId:
> 2, accountId: 2, sessionKey: null, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd,
> cmdOriginator: null, cmdInfo:
> {"response":"json","sessionkey":"qXfe5TLEOA5koD0qobFirCKKbOY\u003d","cmdEventType":"VOLUME.MIGRATE","ctxUserId":"2","storageid":"29a0c990-7100-3a8d-b570-ba9f84ca78bc","httpmethod":"GET","volumeid":"e1eb0b93-3fba-4437-ad50-b12bf1d6f1ef","_":"1375965252817","ctxAccountId":"2","ctxStartEventId":"194"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-08 08:34:49,957 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null)
> ===END=== 10.146.0.20 -- GET
> command=migrateVolume&storageid=29a0c990-7100-3a8d-b570-ba9f84ca78bc&volumeid=e1eb0b93-3fba-4437-ad50-b12bf1d6f1ef&response=json&sessionkey=qXfe5TLEOA5koD0qobFirCKKbOY%3D&_=1375965252817
> 2013-08-08 08:34:49,961 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) Executing
> org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd for job-44 = [
> 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]
> 2013-08-08 08:34:50,032 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) copyAsync
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-08 08:34:50,061 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) copyAsync
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-08 08:34:50,083 DEBUG [agent.transport.Request]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) Seq
> 2-1303576995: Sending { Cmd , MgmtId: 6615759585382, via: 2, Ver: v1, Flags:
> 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"e1eb0b93-3fba-4437-ad50-b12bf1d6f1ef","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"c65a038a-750c-3b4f-bf26-7ce3b74e1c85","id":3,"poolType":"NetworkFi
[jira] [Updated] (CLOUDSTACK-4300) [upgrade][2.2.14 to 4.2][KVM] system vms are not coming up after upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-4300: - Component/s: Doc > [upgrade][2.2.14 to 4.2][KVM] system vms are not coming up after upgrade > > > Key: CLOUDSTACK-4300 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4300 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc, KVM, SystemVM, Upgrade >Affects Versions: 4.2.0 > Environment: Host : KVM [CentOS 6.1] > MS : CentOS 6.1 > upgrade from 2.2.14 to 4.2 >Reporter: Abhinav Roy >Assignee: edison su >Priority: Blocker > Fix For: 4.2.0 > > Attachments: CS-4300.zip, re_CS-4300.zip > > > Steps : > > 1. Deploy a CS 2.2.14 advanced zone setup with KVM host. > 2. do some operations like create vm, snapshots, templates, domain, accounts > etc > 3. upgrade to 4.2 > Expected behaviour : > === > Upgrade should go fine and new system vms should come up > Observed behaviour : > == > Upgrade went fine but system vms don't come up, they stay in the starting > state. > Attaching management server logs, catalina logs, agent logs and DB dumps -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4190) [Object_store_refactor] volume should be deleted from staging storage after successfule volume migration
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen updated CLOUDSTACK-4190:
-
Fix Version/s: (was: 4.2.0)
4.2.1
> [Object_store_refactor] volume should be deleted from staging storage after
> successfule volume migration
>
>
> Key: CLOUDSTACK-4190
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4190
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, Volumes
>Affects Versions: 4.2.0
> Environment: Latest build from ACS 4.2 branch
> Storage: S3 for image store, NFS for secondary staging and primary storage
>Reporter: Sanjeev N
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: cloud.dmp, cloud.dmp, cloud.rar, management-server.rar,
> management-server.rar
>
>
> volume copied to secondary staging storage during volume migration should be
> deleted after migration.
> Steps to Reproduce:
> =
> 1.Bring up CS with xen cluster using S3 from image store, NFS for secondary
> staging and primary storage
> 2.Deploy guest vm using default cent os template with both Root and Data
> disks.
> 3.Add another NFS based primary storage to the cluster
> 4.Detach data disk from the vm
> 5.Migrate the data disk to the primary storage created at step3
> Result:
> ==
> Volume migration was successful. But the volume copied to secondary staging
> storage during migration process did not get deleted.
> Only volume from source primary storage got deleted.
> Observations:
>
> Following is the log snippet during volume migration:
> 2013-08-08 08:34:49,766 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null)
> ===START=== 10.146.0.20 -- GET
> command=migrateVolume&storageid=29a0c990-7100-3a8d-b570-ba9f84ca78bc&volumeid=e1eb0b93-3fba-4437-ad50-b12bf1d6f1ef&response=json&sessionkey=qXfe5TLEOA5koD0qobFirCKKbOY%3D&_=1375965252817
> 2013-08-08 08:34:49,954 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-13:null) submit async job-44 = [
> 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ], details: AsyncJobVO {id:44, userId:
> 2, accountId: 2, sessionKey: null, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd,
> cmdOriginator: null, cmdInfo:
> {"response":"json","sessionkey":"qXfe5TLEOA5koD0qobFirCKKbOY\u003d","cmdEventType":"VOLUME.MIGRATE","ctxUserId":"2","storageid":"29a0c990-7100-3a8d-b570-ba9f84ca78bc","httpmethod":"GET","volumeid":"e1eb0b93-3fba-4437-ad50-b12bf1d6f1ef","_":"1375965252817","ctxAccountId":"2","ctxStartEventId":"194"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-08 08:34:49,957 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null)
> ===END=== 10.146.0.20 -- GET
> command=migrateVolume&storageid=29a0c990-7100-3a8d-b570-ba9f84ca78bc&volumeid=e1eb0b93-3fba-4437-ad50-b12bf1d6f1ef&response=json&sessionkey=qXfe5TLEOA5koD0qobFirCKKbOY%3D&_=1375965252817
> 2013-08-08 08:34:49,961 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) Executing
> org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd for job-44 = [
> 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]
> 2013-08-08 08:34:50,032 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) copyAsync
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-08 08:34:50,061 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) copyAsync
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-08 08:34:50,083 DEBUG [agent.transport.Request]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) Seq
> 2-1303576995: Sending { Cmd , MgmtId: 6615759585382, via: 2, Ver: v1, Flags:
> 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"e1eb0b93-3fba-4437-ad50-b12bf1d6f1ef","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"c65a038a-750c-3b4f-bf26-7ce3b74e1c85","id":3,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/sanjeev/pri_xen_os","port":2049}},"name":"cs-3416","size":5368709120,"path":"5a436a4d-5758-4699-b4d1-7276e1ceb4e5","volumeId":14,"accountId":2,"format":"VHD","id":14,"hyper
[jira] [Updated] (CLOUDSTACK-4300) [DOC] [upgrade][2.2.14 to 4.2][KVM] system vms are not coming up after upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-4300: - Summary: [DOC] [upgrade][2.2.14 to 4.2][KVM] system vms are not coming up after upgrade (was: [upgrade][2.2.14 to 4.2][KVM] system vms are not coming up after upgrade) > [DOC] [upgrade][2.2.14 to 4.2][KVM] system vms are not coming up after upgrade > -- > > Key: CLOUDSTACK-4300 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4300 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc, KVM, SystemVM, Upgrade >Affects Versions: 4.2.0 > Environment: Host : KVM [CentOS 6.1] > MS : CentOS 6.1 > upgrade from 2.2.14 to 4.2 >Reporter: Abhinav Roy >Assignee: edison su >Priority: Blocker > Fix For: 4.2.0 > > Attachments: CS-4300.zip, re_CS-4300.zip > > > Steps : > > 1. Deploy a CS 2.2.14 advanced zone setup with KVM host. > 2. do some operations like create vm, snapshots, templates, domain, accounts > etc > 3. upgrade to 4.2 > Expected behaviour : > === > Upgrade should go fine and new system vms should come up > Observed behaviour : > == > Upgrade went fine but system vms don't come up, they stay in the starting > state. > Attaching management server logs, catalina logs, agent logs and DB dumps -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-4576) [Portable IP] disassociating a transferred public IP is failing with exception
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudha Ponnaganti resolved CLOUDSTACK-4576.
--
Resolution: Fixed
commit a98eb12549a900c7f88acc68457957a4a955fecd
Author: Chiradeep Vittal
Date: Fri Aug 30 14:27:40 2013 -0700
CLOUDSTACK-4575: Portable IP: disassociating a transferred public IP fails
The code is excessively complicated and convoluted.
DisassociateIP ->
Revoke Rule -> {FW, PF{incl SNAT}, LB, RA VPN} ->
-> Send IpAssoc (false) to VR
Send all config to VR again
-> Send IpAssoc(false) to VR again < fails here since it
cannot find the VLAN for the IP since it is already gone
-> Mark Ip as released
The workaround fix would be to not throw an exception in CitrixResourceBase
if it is disassociate and the VLAN does not exist on the XS host.
Signed-off-by: Chiradeep Vittal
> [Portable IP] disassociating a transferred public IP is failing with exception
> --
>
> Key: CLOUDSTACK-4576
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4576
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller
>Affects Versions: 4.2.1
>Reporter: Sudha Ponnaganti
>Assignee: Chiradeep Vittal
>Priority: Critical
> Fix For: 4.2.0, 4.2.1
>
>
> Steps to reproduce:
> 1. Have latest CloudStack with at least 2 advanced zone.
> 2. Go to Regions -> local -> portable IP -> add an ip range like below
> Gateway : 10.147.33.1
> startIp : 10.147.33.3
> endip : 10.147.33.10
> vlan : 33
> subnet : 255.255.255.128
> 3. login as a non-ROOT admin
> username : dom1User1
> password : password
> domain : dom1
> 4. create the following isolated networks in each zone
> - Network1Zone1
> - Network1Zone2
> 5. deploy the following VMs in each network
> - vm1Zone1 connected to Network1Zone1
> - vm1Zone2 connected to Network1Zone2
> 6. Acquire and associate a portable IP to Network1Zone1
> 7. enable staticNAT on the above portableIP and associate it to vm1Zone2 of
> Network1Zone2 and add firewall rule for ssh port
>
> Observations:
> (i) portable IP got transferred from Zone1 to Network1Zone2 successfully and
> able ssh to the portable IP without any issuees.
>
> 8. disassociate above portable IP from Network1Zone2.
> Observations:
> (ii) sequence of things happened as mentioned below
> - disassociate happened without any issues which cleaned the eth interface
> from router etc.., but,
> - it again initiated IPASSOC on its own for the same portable IP which
> resulted in the following error and thus this IP stuck in release state
> forever.
>
> (iii) above behaviour made all further IPASSOCs to fail.
> Attaching all the required logs along with db dump to the bug.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CLOUDSTACK-4487) [Automation] Netscaler test cases failed due missing attribute 'network_offering'
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan reopened CLOUDSTACK-4487:
-
Still in review board
> [Automation] Netscaler test cases failed due missing attribute
> 'network_offering'
> -
>
> Key: CLOUDSTACK-4487
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4487
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.2.0
> Environment: Automaion
>Reporter: Rayees Namathponnan
>Assignee: Sowmya Krishnan
>Priority: Critical
> Fix For: 4.2.1
>
>
> Netscaler test cases failed with below error
> :setup (from nosetests)
> Failing for the past 2 builds (Since Unstable#17 )
> Took 0 ms.
> Error Message
> Warning: Exception during cleanup : type object 'TestLbAlgoLcRr' has no
> attribute 'network_offering'
> 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_netscaler_lb_algo.py",
> line 1052, in setUpClass
> cls.tearDownClass()
> File
> "/data/Repo2/qa/cloudstack/test/integration/component/test_netscaler_lb_algo.py",
> line 1073, in tearDownClass
> raise Exception("Warning: Exception during cleanup : %s" % e)
> Exception: Warning: Exception during cleanup : type object 'TestLbAlgoLcRr'
> has no attribute 'network_offering'
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4462) [Automation][vmware] Failed to find vmdk filed during deployment; and deployment failed
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13755193#comment-13755193
]
Rayees Namathponnan commented on CLOUDSTACK-4462:
-
Not found with last run , and closing this
> [Automation][vmware] Failed to find vmdk filed during deployment; and
> deployment failed
>
>
> Key: CLOUDSTACK-4462
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4462
> 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: Automation
> vmware
> found with 4.2.0-forward branch
>Reporter: Rayees Namathponnan
>Assignee: Kelven Yang
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: CLOUDSTACK-4462.rar
>
>
> During automation run, MS unable to find vmdk file and deployment failed.
> Observed below error in MS
> 2013-08-22 11:55:51,779 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null)
> ===END=== 10.223.240.195 -- GET
> signature=RPK2DwAB3%2FQ8uWNzeyn%2Fp72Ffcw%3D&apiKey=9QzLLT5rIGDi6assUgBQ6s-cdRtyblucm14vV5seHyG6NijTFPH
> y-4vU2HOoE157MdQOo8GjwghoBcQdhwZyBA&command=queryAsyncJobResult&response=json&jobid=8c43beaf-fcf6-4440-90a8-9da05b0312d3
> 2013-08-22 11:55:51,798 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-15:null) SeqA 7-8020: Sending Seq 7-8020: { Ans: ,
> MgmtId: 90928106758026, via: 7, Ver: v1, Flags: 100010, [{"com.cloud.agent.a
> pi.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2013-08-22 11:55:53,014 INFO [vmware.resource.VmwareResource]
> (DirectAgent-169:10.223.250.131) Trying to connect to 10.223.250.185
> 2013-08-22 11:55:53,015 INFO [vmware.resource.VmwareResource]
> (DirectAgent-169:10.223.250.131) Could not connect to 10.223.250.185 due to
> java.net.ConnectException: Connection refused
> 2013-08-22 11:55:53,454 WARN [vmware.resource.VmwareResource]
> (DirectAgent-306:10.223.250.130) StartCommand failed due to Exception:
> java.lang.RuntimeException
> Message: File [4faf04c26dd83025b43f65d32cc49d02] ROOT-421.vmdk was not found
> java.lang.RuntimeException: File [4faf04c26dd83025b43f65d32cc49d02]
> ROOT-421.vmdk was not found
> at
> com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:378)
> at
> com.cloud.hypervisor.vmware.mo.DatastoreMO.moveDatastoreFile(DatastoreMO.java:235)
> at
> com.cloud.storage.resource.VmwareStorageLayoutHelper.syncVolumeToVmDefaultFolder(VmwareStorageLayoutHelper.java:133)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2880)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:514)
> 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-08-22 11:55:53,465 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-306:null) Seq 2-542512498: Cancelling because one of the answers
> is false and it is stop on error.
> 2013-08-22 11:55:53,465 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-306:null) Seq 2-542512498: Response Received:
> 2013-08-22 11:55:53,466 DEBUG [agent.transport.Request]
> (DirectAgent-306:null) Seq 2-542512498: Processing: { Ans: , MgmtId:
> 90928106758026, via: 2, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":421,"name":"r-421-TestVM","bootloader":"HVM","type":"DomainRouter","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":134217728,"maxRam":134217728,"hostName":"r-421-TestVM","arch":"i686","os":"Debian
> GNU/Linux 5.0 (32-bit)","bootArgs":" vpccidr=10.1.1.1/16
> domain=test.domain.org dns1=8.8.8.8 template=domP name=r-421-TestVM
> eth0ip=10.223.250.178 eth0mask=255.255.255.192 mgmtcidr=10.223.49.192/26
> localgw=10.223.250.129 type=vpcrouter disable_rp_filter=true extra_pubnics=2
> nic_macs=02:00:1b:48:00:db","rebootOnCrash":false,"enableH
[jira] [Commented] (CLOUDSTACK-4190) [Object_store_refactor] volume should be deleted from staging storage after successfule volume migration
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13755185#comment-13755185
]
Parth Jagirdar commented on CLOUDSTACK-4190:
For Vmware, we have several places that didn't thoroughly clean up object in
NFS staging area, which needs a generic approach to clean up staging area
object. Can be done in post 4.2.0.
> [Object_store_refactor] volume should be deleted from staging storage after
> successfule volume migration
>
>
> Key: CLOUDSTACK-4190
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4190
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, Volumes
>Affects Versions: 4.2.0
> Environment: Latest build from ACS 4.2 branch
> Storage: S3 for image store, NFS for secondary staging and primary storage
>Reporter: Sanjeev N
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: cloud.dmp, cloud.dmp, cloud.rar, management-server.rar,
> management-server.rar
>
>
> volume copied to secondary staging storage during volume migration should be
> deleted after migration.
> Steps to Reproduce:
> =
> 1.Bring up CS with xen cluster using S3 from image store, NFS for secondary
> staging and primary storage
> 2.Deploy guest vm using default cent os template with both Root and Data
> disks.
> 3.Add another NFS based primary storage to the cluster
> 4.Detach data disk from the vm
> 5.Migrate the data disk to the primary storage created at step3
> Result:
> ==
> Volume migration was successful. But the volume copied to secondary staging
> storage during migration process did not get deleted.
> Only volume from source primary storage got deleted.
> Observations:
>
> Following is the log snippet during volume migration:
> 2013-08-08 08:34:49,766 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null)
> ===START=== 10.146.0.20 -- GET
> command=migrateVolume&storageid=29a0c990-7100-3a8d-b570-ba9f84ca78bc&volumeid=e1eb0b93-3fba-4437-ad50-b12bf1d6f1ef&response=json&sessionkey=qXfe5TLEOA5koD0qobFirCKKbOY%3D&_=1375965252817
> 2013-08-08 08:34:49,954 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-13:null) submit async job-44 = [
> 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ], details: AsyncJobVO {id:44, userId:
> 2, accountId: 2, sessionKey: null, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd,
> cmdOriginator: null, cmdInfo:
> {"response":"json","sessionkey":"qXfe5TLEOA5koD0qobFirCKKbOY\u003d","cmdEventType":"VOLUME.MIGRATE","ctxUserId":"2","storageid":"29a0c990-7100-3a8d-b570-ba9f84ca78bc","httpmethod":"GET","volumeid":"e1eb0b93-3fba-4437-ad50-b12bf1d6f1ef","_":"1375965252817","ctxAccountId":"2","ctxStartEventId":"194"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-08 08:34:49,957 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null)
> ===END=== 10.146.0.20 -- GET
> command=migrateVolume&storageid=29a0c990-7100-3a8d-b570-ba9f84ca78bc&volumeid=e1eb0b93-3fba-4437-ad50-b12bf1d6f1ef&response=json&sessionkey=qXfe5TLEOA5koD0qobFirCKKbOY%3D&_=1375965252817
> 2013-08-08 08:34:49,961 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) Executing
> org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd for job-44 = [
> 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]
> 2013-08-08 08:34:50,032 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) copyAsync
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-08 08:34:50,061 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) copyAsync
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-08 08:34:50,083 DEBUG [agent.transport.Request]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) Seq
> 2-1303576995: Sending { Cmd , MgmtId: 6615759585382, via: 2, Ver: v1, Flags:
> 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"e1eb0b93-3fba-4437-ad50-b12bf1d6f1ef","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"c65a038a-750c-3b4f-bf26-7ce3b74e1c85","id":3,"poolType":"NetworkFilesystem","host"
[jira] [Issue Comment Deleted] (CLOUDSTACK-4190) [Object_store_refactor] volume should be deleted from staging storage after successfule volume migration
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Parth Jagirdar updated CLOUDSTACK-4190:
---
Comment: was deleted
(was: For Vmware, we have several places that didn't thoroughly clean up object
in NFS staging area, which needs a generic approach to clean up staging area
object. Can be done in post 4.2.0.)
> [Object_store_refactor] volume should be deleted from staging storage after
> successfule volume migration
>
>
> Key: CLOUDSTACK-4190
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4190
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, Volumes
>Affects Versions: 4.2.0
> Environment: Latest build from ACS 4.2 branch
> Storage: S3 for image store, NFS for secondary staging and primary storage
>Reporter: Sanjeev N
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: cloud.dmp, cloud.dmp, cloud.rar, management-server.rar,
> management-server.rar
>
>
> volume copied to secondary staging storage during volume migration should be
> deleted after migration.
> Steps to Reproduce:
> =
> 1.Bring up CS with xen cluster using S3 from image store, NFS for secondary
> staging and primary storage
> 2.Deploy guest vm using default cent os template with both Root and Data
> disks.
> 3.Add another NFS based primary storage to the cluster
> 4.Detach data disk from the vm
> 5.Migrate the data disk to the primary storage created at step3
> Result:
> ==
> Volume migration was successful. But the volume copied to secondary staging
> storage during migration process did not get deleted.
> Only volume from source primary storage got deleted.
> Observations:
>
> Following is the log snippet during volume migration:
> 2013-08-08 08:34:49,766 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null)
> ===START=== 10.146.0.20 -- GET
> command=migrateVolume&storageid=29a0c990-7100-3a8d-b570-ba9f84ca78bc&volumeid=e1eb0b93-3fba-4437-ad50-b12bf1d6f1ef&response=json&sessionkey=qXfe5TLEOA5koD0qobFirCKKbOY%3D&_=1375965252817
> 2013-08-08 08:34:49,954 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-13:null) submit async job-44 = [
> 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ], details: AsyncJobVO {id:44, userId:
> 2, accountId: 2, sessionKey: null, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd,
> cmdOriginator: null, cmdInfo:
> {"response":"json","sessionkey":"qXfe5TLEOA5koD0qobFirCKKbOY\u003d","cmdEventType":"VOLUME.MIGRATE","ctxUserId":"2","storageid":"29a0c990-7100-3a8d-b570-ba9f84ca78bc","httpmethod":"GET","volumeid":"e1eb0b93-3fba-4437-ad50-b12bf1d6f1ef","_":"1375965252817","ctxAccountId":"2","ctxStartEventId":"194"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-08 08:34:49,957 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null)
> ===END=== 10.146.0.20 -- GET
> command=migrateVolume&storageid=29a0c990-7100-3a8d-b570-ba9f84ca78bc&volumeid=e1eb0b93-3fba-4437-ad50-b12bf1d6f1ef&response=json&sessionkey=qXfe5TLEOA5koD0qobFirCKKbOY%3D&_=1375965252817
> 2013-08-08 08:34:49,961 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) Executing
> org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd for job-44 = [
> 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]
> 2013-08-08 08:34:50,032 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) copyAsync
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-08 08:34:50,061 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) copyAsync
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-08 08:34:50,083 DEBUG [agent.transport.Request]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) Seq
> 2-1303576995: Sending { Cmd , MgmtId: 6615759585382, via: 2, Ver: v1, Flags:
> 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"e1eb0b93-3fba-4437-ad50-b12bf1d6f1ef","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"c65a038a-750c-3b4f-bf26-7ce3b74e1c85","id":3,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/
[jira] [Updated] (CLOUDSTACK-4576) [Portable IP] disassociating a transferred public IP is failing with exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-4576: - Affects Version/s: (was: 4.2.0) 4.2.1 > [Portable IP] disassociating a transferred public IP is failing with exception > -- > > Key: CLOUDSTACK-4576 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4576 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.1 >Reporter: Sudha Ponnaganti >Priority: Critical > Fix For: 4.2.0, 4.2.1 > > > Steps to reproduce: > 1. Have latest CloudStack with at least 2 advanced zone. > 2. Go to Regions -> local -> portable IP -> add an ip range like below > Gateway : 10.147.33.1 > startIp : 10.147.33.3 > endip : 10.147.33.10 > vlan : 33 > subnet : 255.255.255.128 > 3. login as a non-ROOT admin > username : dom1User1 > password : password > domain : dom1 > 4. create the following isolated networks in each zone > - Network1Zone1 > - Network1Zone2 > 5. deploy the following VMs in each network > - vm1Zone1 connected to Network1Zone1 > - vm1Zone2 connected to Network1Zone2 > 6. Acquire and associate a portable IP to Network1Zone1 > 7. enable staticNAT on the above portableIP and associate it to vm1Zone2 of > Network1Zone2 and add firewall rule for ssh port > > Observations: > (i) portable IP got transferred from Zone1 to Network1Zone2 successfully and > able ssh to the portable IP without any issuees. > > 8. disassociate above portable IP from Network1Zone2. > Observations: > (ii) sequence of things happened as mentioned below > - disassociate happened without any issues which cleaned the eth interface > from router etc.., but, > - it again initiated IPASSOC on its own for the same portable IP which > resulted in the following error and thus this IP stuck in release state > forever. > > (iii) above behaviour made all further IPASSOCs to fail. > Attaching all the required logs along with db dump to the bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4576) [Portable IP] disassociating a transferred public IP is failing with exception
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13755172#comment-13755172 ] Sudha Ponnaganti commented on CLOUDSTACK-4576: -- Few more scenarios covered : 1. enabling static nat and disassociated the ip using public IP range instead of portable ip range - works fine 2. enabling static nat on a portable IP to a vm with in the same network and disassociating - works fine 3. acquiring a portable IP in network1Zone1 and enabling static nat with a VM that exists in Network2Zone1 and disassociating IP - works fine. > [Portable IP] disassociating a transferred public IP is failing with exception > -- > > Key: CLOUDSTACK-4576 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4576 > 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: Sudha Ponnaganti >Priority: Critical > Fix For: 4.2.0, 4.2.1 > > > Steps to reproduce: > 1. Have latest CloudStack with at least 2 advanced zone. > 2. Go to Regions -> local -> portable IP -> add an ip range like below > Gateway : 10.147.33.1 > startIp : 10.147.33.3 > endip : 10.147.33.10 > vlan : 33 > subnet : 255.255.255.128 > 3. login as a non-ROOT admin > username : dom1User1 > password : password > domain : dom1 > 4. create the following isolated networks in each zone > - Network1Zone1 > - Network1Zone2 > 5. deploy the following VMs in each network > - vm1Zone1 connected to Network1Zone1 > - vm1Zone2 connected to Network1Zone2 > 6. Acquire and associate a portable IP to Network1Zone1 > 7. enable staticNAT on the above portableIP and associate it to vm1Zone2 of > Network1Zone2 and add firewall rule for ssh port > > Observations: > (i) portable IP got transferred from Zone1 to Network1Zone2 successfully and > able ssh to the portable IP without any issuees. > > 8. disassociate above portable IP from Network1Zone2. > Observations: > (ii) sequence of things happened as mentioned below > - disassociate happened without any issues which cleaned the eth interface > from router etc.., but, > - it again initiated IPASSOC on its own for the same portable IP which > resulted in the following error and thus this IP stuck in release state > forever. > > (iii) above behaviour made all further IPASSOCs to fail. > Attaching all the required logs along with db dump to the bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4576) [Portable IP] disassociating a transferred public IP is failing with exception
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13755163#comment-13755163
]
Sudha Ponnaganti commented on CLOUDSTACK-4576:
--
log snippet for disassociate IP address:
013-08-30 20:39:47,617 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null)
===START=== 10.252.192.43 -- GET
command=disassociateIpAddress&response=json&sessionkey=UAGLMmvHcEMPIoWbSRGxioeyA6Y%3D&id=f6c19cd2-cd72-4ae5-8f40-ae1687aea4ca&_=1377875402891
2013-08-30 20:39:47,628 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-270:null) Ping from 3
2013-08-30 20:39:47,653 DEBUG [cloud.async.AsyncJobManagerImpl]
(catalina-exec-1:null) submit async job-146 = [
52178d4b-b132-497f-8df8-6844a9e441b2 ], details: AsyncJobVO {id:146, userId: 3,
accountId: 3, sessionKey: null, instanceType: IpAddress, instanceId: 35, cmd:
org.apache.cloudstack.api.command.user.address.DisassociateIPAddrCmd,
cmdOriginator: null, cmdInfo:
{"response":"json","id":"f6c19cd2-cd72-4ae5-8f40-ae1687aea4ca","sessionkey":"UAGLMmvHcEMPIoWbSRGxioeyA6Y\u003d","cmdEventType":"PORTABLE.IPRELEASE","ctxUserId":"3","httpmethod":"GET","_":"1377875402891","ctxAccountId":"3","ctxStartEventId":"509"},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 7280707764394,
completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2013-08-30 20:39:47,656 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null)
===END=== 10.252.192.43 -- GET
command=disassociateIpAddress&response=json&sessionkey=UAGLMmvHcEMPIoWbSRGxioeyA6Y%3D&id=f6c19cd2-cd72-4ae5-8f40-ae1687aea4ca&_=1377875402891
2013-08-30 20:39:47,658 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-72:job-146 = [ 52178d4b-b132-497f-8df8-6844a9e441b2 ]) Executing
org.apache.cloudstack.api.command.user.address.DisassociateIPAddrCmd for
job-146 = [ 52178d4b-b132-497f-8df8-6844a9e441b2 ]
2013-08-30 20:39:47,682 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-72:job-146 = [ 52178d4b-b132-497f-8df8-6844a9e441b2 ]) Sync
job-146 = [ 52178d4b-b132-497f-8df8-6844a9e441b2 ] execution on object
network.214
2013-08-30 20:39:47,695 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-72:job-146 = [ 52178d4b-b132-497f-8df8-6844a9e441b2 ]) job
org.apache.cloudstack.api.command.user.address.DisassociateIPAddrCmd for
job-146 = [ 52178d4b-b132-497f-8df8-6844a9e441b2 ] was queued, processing the
queue.
2013-08-30 20:39:47,704 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-72:job-146 = [ 52178d4b-b132-497f-8df8-6844a9e441b2 ]) Executing
sync queue item: SyncQueueItemVO {id:83, queueId: 82, contentType: AsyncJob,
contentId: 146, lastProcessMsid: 7280707764394, lastprocessNumber: 2,
lastProcessTime: Fri Aug 30 20:39:47 IST 2013, created: Fri Aug 30 20:39:47 IST
2013}
2013-08-30 20:39:47,706 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-72:job-146 = [ 52178d4b-b132-497f-8df8-6844a9e441b2 ]) Schedule
queued job-146 = [ 52178d4b-b132-497f-8df8-6844a9e441b2 ]
2013-08-30 20:39:47,714 DEBUG [cloud.async.SyncQueueManagerImpl]
(Job-Executor-72:job-146 = [ 52178d4b-b132-497f-8df8-6844a9e441b2 ]) There is a
pending process in sync queue(id: 82)
2013-08-30 20:39:47,716 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-73:job-146 = [ 52178d4b-b132-497f-8df8-6844a9e441b2 ]) Executing
org.apache.cloudstack.api.command.user.address.DisassociateIPAddrCmd for
job-146 = [ 52178d4b-b132-497f-8df8-6844a9e441b2 ]
2013-08-30 20:39:47,741 DEBUG [cloud.user.AccountManagerImpl]
(Job-Executor-73:job-146 = [ 52178d4b-b132-497f-8df8-6844a9e441b2 ]) Access to
Ip[10.147.33.3-2] granted to
Acct[597f3956-cd84-4574-a5d7-1e09b9eed998-dom1Acc1] by
DomainChecker_EnhancerByCloudStack_b7983160
2013-08-30 20:39:47,744 DEBUG [cloud.network.NetworkManagerImpl]
(Job-Executor-73:job-146 = [ 52178d4b-b132-497f-8df8-6844a9e441b2 ]) Revoking
all Firewallrules as a part of public IP id=35 release...
2013-08-30 20:39:47,746 DEBUG [network.firewall.FirewallManagerImpl]
(Job-Executor-73:job-146 = [ 52178d4b-b132-497f-8df8-6844a9e441b2 ]) Releasing
1 firewall rules for ip id=35
2013-08-30 20:39:47,757 DEBUG [cloud.user.AccountManagerImpl]
(Job-Executor-73:job-146 = [ 52178d4b-b132-497f-8df8-6844a9e441b2 ]) Access to
Rule[18-Firewall-Active] granted to
Acct[597f3956-cd84-4574-a5d7-1e09b9eed998-dom1Acc1] by
DomainChecker_EnhancerByCloudStack_b7983160
2013-08-30 20:39:47,761 DEBUG [cloud.user.AccountManagerImpl]
(Job-Executor-73:job-146 = [ 52178d4b-b132-497f-8df8-6844a9e441b2 ]) Access to
Rule[18-Firewall-Active] granted to
Acct[597f3956-cd84-4574-a5d7-1e09b9eed998-dom1Acc1] by
DomainChecker_EnhancerByCloudStack_b7983160
2013-08-30 20:39:47,780 DEBUG [cloud.user.AccountManagerImpl]
(Job-Executor-73:job-146 = [ 52178d4b-b132-497f-8df8-6844a9e441b2 ]) Access to
Rule[18-Firewall-Revoke] granted
[jira] [Created] (CLOUDSTACK-4576) [Portable IP] disassociating a transferred public IP is failing with exception
Sudha Ponnaganti created CLOUDSTACK-4576: Summary: [Portable IP] disassociating a transferred public IP is failing with exception Key: CLOUDSTACK-4576 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4576 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: Sudha Ponnaganti Priority: Critical Fix For: 4.2.0, 4.2.1 Steps to reproduce: 1. Have latest CloudStack with at least 2 advanced zone. 2. Go to Regions -> local -> portable IP -> add an ip range like below Gateway : 10.147.33.1 startIp : 10.147.33.3 endip : 10.147.33.10 vlan : 33 subnet : 255.255.255.128 3. login as a non-ROOT admin username : dom1User1 password : password domain : dom1 4. create the following isolated networks in each zone - Network1Zone1 - Network1Zone2 5. deploy the following VMs in each network - vm1Zone1 connected to Network1Zone1 - vm1Zone2 connected to Network1Zone2 6. Acquire and associate a portable IP to Network1Zone1 7. enable staticNAT on the above portableIP and associate it to vm1Zone2 of Network1Zone2 and add firewall rule for ssh port Observations: (i) portable IP got transferred from Zone1 to Network1Zone2 successfully and able ssh to the portable IP without any issuees. 8. disassociate above portable IP from Network1Zone2. Observations: (ii) sequence of things happened as mentioned below - disassociate happened without any issues which cleaned the eth interface from router etc.., but, - it again initiated IPASSOC on its own for the same portable IP which resulted in the following error and thus this IP stuck in release state forever. (iii) above behaviour made all further IPASSOCs to fail. Attaching all the required logs along with db dump to the bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4575) [Portable IP] disassociating a transferred public IP is failing with exception
Chiradeep Vittal created CLOUDSTACK-4575: Summary: [Portable IP] disassociating a transferred public IP is failing with exception Key: CLOUDSTACK-4575 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4575 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Reporter: Chiradeep Vittal Steps to reproduce: 1. Have latest CloudStack with at least 2 advanced zone. 2. Go to Regions -> local -> portable IP -> add an ip range like below Gateway : 10.147.33.1 startIp : 10.147.33.3 endip : 10.147.33.10 vlan : 33 subnet : 255.255.255.128 3. login as a non-ROOT admin username : dom1User1 password : password domain : dom1 4. create the following isolated networks in each zone - Network1Zone1 - Network1Zone2 5. deploy the following VMs in each network - vm1Zone1 connected to Network1Zone1 - vm1Zone2 connected to Network1Zone2 6. Acquire and associate a portable IP to Network1Zone1 7. enable staticNAT on the above portableIP and associate it to vm1Zone2 of Network1Zone2 and add firewall rule for ssh port Observations: (i) portable IP got transferred from Zone1 to Network1Zone2 successfully and able ssh to the portable IP without any issuees. 8. disassociate above portable IP from Network1Zone2. Observations: (ii) sequence of things happened as mentioned below - disassociate happened without any issues which cleaned the eth interface from router etc.., but, - it again initiated IPASSOC on its own for the same portable IP which resulted in the following error and thus this IP stuck in release state forever. (iii) above behaviour made all further IPASSOCs to fail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4575) [Portable IP] disassociating a transferred public IP is failing with exception
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13755159#comment-13755159
]
ASF subversion and git services commented on CLOUDSTACK-4575:
-
Commit a98eb12549a900c7f88acc68457957a4a955fecd in branch
refs/heads/4.2-forward from [~chiradeep]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a98eb12 ]
CLOUDSTACK-4575: Portable IP: disassociating a transferred public IP fails
The code is excessively complicated and convoluted.
DisassociateIP ->
Revoke Rule -> {FW, PF{incl SNAT}, LB, RA VPN} ->
-> Send IpAssoc (false) to VR
Send all config to VR again
-> Send IpAssoc(false) to VR again < fails here since it cannot
find the VLAN for the IP since it is already gone
-> Mark Ip as released
The workaround fix would be to not throw an exception in CitrixResourceBase if
it is disassociate and the VLAN does not exist on the XS host.
Signed-off-by: Chiradeep Vittal
> [Portable IP] disassociating a transferred public IP is failing with exception
> --
>
> Key: CLOUDSTACK-4575
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4575
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller
>Reporter: Chiradeep Vittal
>
> Steps to reproduce:
> 1. Have latest CloudStack with at least 2 advanced zone.
> 2. Go to Regions -> local -> portable IP -> add an ip range like below
> Gateway : 10.147.33.1
> startIp : 10.147.33.3
> endip : 10.147.33.10
> vlan : 33
> subnet : 255.255.255.128
> 3. login as a non-ROOT admin
> username : dom1User1
> password : password
> domain : dom1
> 4. create the following isolated networks in each zone
> - Network1Zone1
> - Network1Zone2
> 5. deploy the following VMs in each network
> - vm1Zone1 connected to Network1Zone1
> - vm1Zone2 connected to Network1Zone2
> 6. Acquire and associate a portable IP to Network1Zone1
> 7. enable staticNAT on the above portableIP and associate it to vm1Zone2 of
> Network1Zone2 and add firewall rule for ssh port
> Observations:
> (i) portable IP got transferred from Zone1 to Network1Zone2 successfully and
> able ssh to the portable IP without any issuees.
> 8. disassociate above portable IP from Network1Zone2.
> Observations:
> (ii) sequence of things happened as mentioned below
> - disassociate happened without any issues which cleaned the eth interface
> from router etc.., but,
> - it again initiated IPASSOC on its own for the same portable IP which
> resulted in the following error and thus this IP stuck in release state
> forever.
> (iii) above behaviour made all further IPASSOCs to fail.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-3024) Test suite "test_host_high_availability" failed with error "Exception during cleanup : 'cloudConnection' object has no attribute 'close'"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan closed CLOUDSTACK-3024.
---
> Test suite "test_host_high_availability" failed with error "Exception during
> cleanup : 'cloudConnection' object has no attribute 'close'"
> -
>
> Key: CLOUDSTACK-3024
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3024
> 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: Automation
>Reporter: Rayees Namathponnan
>Assignee: Prasanna Santhanam
> Fix For: 4.2.0
>
>
> Test suite test_host_high_availability failed with error
> Warning: Exception during cleanup : 'cloudConnection' object has no attribute
> 'close'
> >> begin captured logging <<
> testclient.testcase.TestHostHighAvailability: DEBUG: Enabling maintenance
> mode for host dcc3383a-9ac7-44e1-b086-e279ce9c7390
> testclient.testcase.TestHostHighAvailability: DEBUG: Waiting for VM to come up
> - >> end captured logging << -
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 345, in run
> self.tearDown()
> File
> "/Repo_30X/ipcl/cloudstack/test/integration/component/test_host_high_availability.py",
> line 148, in tearDown
> raise Exception("Warning: Exception during cleanup : %s" % e)
> Warning: Exception during cleanup : 'cloudConnection' object has no attribute
> 'close'
> >> begin captured logging <<
> testclient.testcase.TestHostHighAvailability: DEBUG: Enabling maintenance
> mode for host dcc3383a-9ac7-44e1-b086-e279ce9c7390
> testclient.testcase.TestHostHighAvailability: DEBUG: Waiting for VM to come up
> - >> end captured logging << -
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-4456) [Automation] Vm deployment from template is failed; due to some race condition in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan closed CLOUDSTACK-4456.
---
Not found this issue in latest runs
> [Automation] Vm deployment from template is failed; due to some race
> condition in KVM
> -
>
> Key: CLOUDSTACK-4456
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4456
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, KVM, Management Server, Template
>Affects Versions: 4.2.0
> Environment: Automation
> 4.2
>Reporter: Rayees Namathponnan
>Assignee: edison su
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: CLOUDSTACK-4456.rar
>
>
> This issue observed during automation run, In attached log i can see multiple
> deployment failed due to same issue, here the once effected test case
> integration.component.test_blocker_bugs.TestTemplate.test_01_create_template
> Test case performing below operation
> 1) Create template from http url (ubuntu-10-04-64bit-server.qcow2)
> 2) Deploy vm from this template
> Actual Result
> -
> Deployment failed with below error; look like MS deleting template after
> creating the volume
> IN MS Search for job-899
> 2013-08-21 22:07:12,383 DEBUG [cloud.network.NetworkManagerImpl]
> (Job-Executor-66:job-899 = [ 461fc03f-6d0a-488f-9cf3-7cf1a537b26c ]) Asking
> BareMetalUserdata to prepare for
> Nic[194-188-97ae23d5-67ea-46c1-91e6-4e6ef35c22ae-10.223.250.231]
> 2013-08-21 22:07:12,389 DEBUG [cloud.storage.VolumeManagerImpl]
> (Job-Executor-66:job-899 = [ 461fc03f-6d0a-488f-9cf3-7cf1a537b26c ]) Checking
> if we need to prepare 1 volumes for
> VM[User|daf71095-b010-45f0-9e46-3bf51ee6a59c]
> 2013-08-21 22:07:12,389 DEBUG [cloud.storage.VolumeManagerImpl]
> (Job-Executor-66:job-899 = [ 461fc03f-6d0a-488f-9cf3-7cf1a537b26c ]) No need
> to recreate the volume: Vol[238|vm=188|ROOT], since it already has a pool
> assigned: 1, adding disk to VM
> 2013-08-21 22:07:12,408 DEBUG [agent.transport.Request]
> (Job-Executor-66:job-899 = [ 461fc03f-6d0a-488f-9cf3-7cf1a537b26c ]) Seq
> 2-949159112: Sending { Cmd , MgmtId: 73187150500751, via: 2, Ver: v1, Flags:
> 100011,
> [{"com.cloud.agent.api.StartCommand":{"vm":{"id":188,"name":"i-287-188-TestVM","type":"User","cpus":1,"minSpeed":100,"maxSpeed":100,"minRam":134217728,"maxRam":134217728,"arch":"x86_64","os":"CentOS
> 5.5
> (64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"a79bd4d41d554b1a","params":{"Message.ReservedCapacityFreed.Flag":"false"},"uuid":"daf71095-b010-45f0-9e46-3bf51ee6a59c","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"eba8fc74-aa6e-43a9-8dae-5501a0dd490f","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"9d41-b138-3a13-974c-fa506683da4d","id":1,"poolType":"NetworkFilesystem","host":"nfs1-ccp.citrix.com","path":"/home/common/automation/SC_QA_AUTO5/primary1","port":2049}},"name":"ROOT-188","size":5368709120,"path":"5ce3b7d0-07c1-4d3b-9c00-2c6ad8716635","volumeId":238,"vmName":"i-287-188-TestVM","accountId":287,"format":"QCOW2","id":238,"hypervisorType":"KVM"}},"diskSeq":0,"type":"ROOT"},{"data":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"id":0,"format":"ISO","accountId":0,"hvm":false}},"diskSeq":3,"type":"ISO"}],"nics":[{"deviceId":0,"networkRateMbps":200,"defaultNic":true,"uuid":"3cf9efdc-212d-46f6-b818-071450e602fd","ip":"10.223.250.231","netmask":"255.255.255.192","gateway":"10.223.250.193","mac":"06:5f:a0:00:00:24","dns1":"8.8.8.8","broadcastType":"Native","type":"Guest","broadcastUri":"vlan://untagged","isolationUri":"ec2://untagged","isSecurityGroupEnabled":true}]},"hostIp":"10.223.250.195","executeInSequence":false,"wait":0}}]
> }
> 2013-08-21 22:07:12,957 DEBUG [agent.transport.Request]
> (AgentManager-Handler-7:null) Seq 2-949159112: Processing: { Ans: , MgmtId:
> 73187150500751, via: 2, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":188,"name":"i-287-188-TestVM","type":"User","cpus":1,"minSpeed":100,"maxSpeed":100,"minRam":134217728,"maxRam":134217728,"arch":"x86_64","os":"CentOS
> 5.5
> (64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"a79bd4d41d554b1a","vncAddr":"10.223.250.195","params":{"Message.ReservedCapacityFreed.Flag":"false"},"uuid":"daf71095-b010-45f0-9e46-3bf51ee6a59c","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"eba8fc74-aa6e-43a9-8dae-5501a0dd490f","volumeType":
[jira] [Commented] (CLOUDSTACK-4534) [object_store_refactor] Deleting uploaded volume is not deleting the volume from backend
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13755062#comment-13755062 ] Min Chen commented on CLOUDSTACK-4534: -- I just verified, restart SSVM or restart MS will remove the uploaded volum from secondary storage. But the only issue here is that that destroyed volume is still showing up in the UI due to removed column is not set for this volume. > [object_store_refactor] Deleting uploaded volume is not deleting the volume > from backend > > > Key: CLOUDSTACK-4534 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4534 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, Volumes >Affects Versions: 4.2.1 > Environment: git rev-parse HEAD~5 > 1f46bc3fb09aead2cf1744d358fea7adba7df6e1 > Cluster: VMWare > Storage: NFS >Reporter: Sanjeev N > Fix For: 4.2.1 > > Attachments: cloud.dmp, cloud.dmp, management-server.rar, > management-server.rar > > > Deleting uploaded volume is not deleting the volume from backend and not > marking removed field in volumes table. > Steps to Reproduce: > > 1.Bring up CS with vmware cluster using NFS for both primary and secondary > storage > 2.Upload one volume using uploadVolume API > 3.When the volume is in "Uploaded" state try to delete the volume > Result: > == > from volume_store_ref volume entry got deleted but volume was not deleted > from secondary storage and removed filed was not set in volumes table. > Observations: > === > Log snippet from management server log file as follows: > 2013-08-28 03:18:08,269 DEBUG [cloud.api.ApiServlet] (catalina-exec-20:null) > ===START=== 10.146.0.131 -- GET > command=deleteVolume&id=e9ee6c0d-d149-4771-a494-6efda849b2ce&response=json&sessionkey=vNQ7kc2GdEuxzKje8MQ2xSAqbAQ%3D&_=1377674288184 > 2013-08-28 03:18:08,414 DEBUG [cloud.user.AccountManagerImpl] > (catalina-exec-20:null) Access granted to Acct[2-admin] to Domain:1/ by > AffinityGroupAccessChecker_EnhancerByCloudStack_86df51a8 > 2013-08-28 03:18:08,421 INFO [cloud.resourcelimit.ResourceLimitManagerImpl] > (catalina-exec-20:null) Discrepency in the resource count (original > count=77179526656 correct count = 78867689472) for type secondary_storage for > account ID 2 is fixed during resource count recalculation. > 2013-08-28 03:18:08,446 DEBUG [cloud.api.ApiServlet] (catalina-exec-20:null) > ===END=== 10.146.0.131 -- GET > command=deleteVolume&id=e9ee6c0d-d149-4771-a494-6efda849b2ce&response=json&sessionkey=vNQ7kc2GdEuxzKje8MQ2xSAqbAQ%3D&_=1377674288184 > 2013-08-28 03:18:32,766 DEBUG [cloud.storage.StorageManagerImpl] > (StorageManager-Scavenger-1:null) Storage pool garbage collector found 0 > templates to clean up in storage pool: pri_esx_306 > 2013-08-28 03:18:32,772 DEBUG [cloud.storage.StorageManagerImpl] > (StorageManager-Scavenger-1:null) Secondary storage garbage collector found 0 > templates to cleanup on template_store_ref for store: > 37f6be5b-0899-48b4-9fd8-1fe483f47c0e > 2013-08-28 03:18:32,774 DEBUG [cloud.storage.StorageManagerImpl] > (StorageManager-Scavenger-1:null) Secondary storage garbage collector found 0 > snapshots to cleanup on snapshot_store_ref for store: > 37f6be5b-0899-48b4-9fd8-1fe483f47c0e > 2013-08-28 03:18:32,776 DEBUG [cloud.storage.StorageManagerImpl] > (StorageManager-Scavenger-1:null) Secondary storage garbage collector found 1 > volumes to cleanup on volume_store_ref for store: > 37f6be5b-0899-48b4-9fd8-1fe483f47c0e > 2013-08-28 03:18:32,777 DEBUG [cloud.storage.StorageManagerImpl] > (StorageManager-Scavenger-1:null) Deleting volume store DB entry: > VolumeDataStore[2-20-2volumes/2/20/7e5778fd-c4bf-35b3-9e7a-9ab8500ab469.ova] > Volume in the backend: > [root@Rhel63-Sanjeev 20]# pwd > /tmp/nfs/sec_306/volumes/2/20 > [root@Rhel63-Sanjeev 20]# ls -l > total 898008 > -rwxrwxrwx+ 1 root root 459320832 Aug 27 13:57 > 7e5778fd-c4bf-35b3-9e7a-9ab8500ab469.ova > -rwxrwxrwx+ 1 root root 459312128 Sep 17 2010 CentOS5.3-x86_64-disk1.vmdk > -rwxrwxrwx+ 1 root root 147 Sep 17 2010 CentOS5.3-x86_64.mf > -rwxrwxrwx+ 1 root root 5340 Sep 17 2010 CentOS5.3-x86_64.ovf > -rwxrwxrwx+ 1 root root 340 Aug 27 13:58 volume.properties > [root@Rhel63-Sanjeev 20]# > Attaching management server log file and cloud db. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-1525) Add section on how to ssh in to system VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marty Sweet resolved CLOUDSTACK-1525. - Resolution: Fixed Applied to master and 4.2-forward https://reviews.apache.org/r/13798/ > Add section on how to ssh in to system VMs > -- > > Key: CLOUDSTACK-1525 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1525 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.0.0, 4.1.0 >Reporter: Jessica Tomechak >Assignee: Marty Sweet >Priority: Minor > Fix For: 4.2.0 > > > In the "Working with System VMs" section of the Admin Guide, there is no > "Accessing System VMs" section. There should be one, similar to the > "Accessing VMs" section in the earlier "Working with Virtual Machines" > section. You can access system VMs through the UI, in the Infrastructure tab. > You can also ssh in, using the following techniques. > To access a system VM directly over the network, use one of the following > techniques, depending on the hypervisor. > XenServer or KVM: > SSH in by using the link local IP address of the system VM. For example, in > the command below, substitute your own path to the private key used to log in > to the system VM and your own link local IP. > Run the following command on the XenServer or KVM host on which the system VM > is present: > # ssh -i -p 3922 > Now you can run commands on the system VM. For example, to check the software > version: > # cat /etc/cloudstack-release > The output should be like the following: > Cloudstack Release 4.0 Mon Feb 6 15:10:04 PST 2013 > ESXi: > SSH in using the private IP address of the system VM. For example, in the > command below, substitute your own path to the private key used to log in to > the system VM and your own private IP. > Run the following command on the Management Server: > # ssh -i -p 3922 > Now you can run commands on the system VM. For example, to check the software > version: > # cat /etc/cloudstack-release > The output should be like the following: > Cloudstack Release 4.0 Mon Feb 6 15:10:04 PST 2013 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-4572) findHostsForMigration API does not return correct host list
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Damle reassigned CLOUDSTACK-4572: Assignee: Saksham Srivastava (was: Prachi Damle) > findHostsForMigration API does not return correct host list > --- > > Key: CLOUDSTACK-4572 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4572 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Saksham Srivastava >Assignee: Saksham Srivastava > Fix For: 4.2.1 > > > Create multi cluster setup. > Tag host in one cluster with host tag t1. > Create a service offering using the host tag t1 > Deploy a vm using the tagged service offering. > Even if tagged/untagged hosts are available across different clusters the api > does not list correct hosts for migration for the deployed vm. > Expected behavior: > The api should return the list of suitable/unsuitable hosts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-4572) findHostsForMigration API does not return correct host list
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Damle resolved CLOUDSTACK-4572. -- Resolution: Fixed > findHostsForMigration API does not return correct host list > --- > > Key: CLOUDSTACK-4572 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4572 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Saksham Srivastava >Assignee: Prachi Damle > Fix For: 4.2.1 > > > Create multi cluster setup. > Tag host in one cluster with host tag t1. > Create a service offering using the host tag t1 > Deploy a vm using the tagged service offering. > Even if tagged/untagged hosts are available across different clusters the api > does not list correct hosts for migration for the deployed vm. > Expected behavior: > The api should return the list of suitable/unsuitable hosts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-4572) findHostsForMigration API does not return correct host list
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Damle reassigned CLOUDSTACK-4572: Assignee: Prachi Damle (was: Saksham Srivastava) > findHostsForMigration API does not return correct host list > --- > > Key: CLOUDSTACK-4572 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4572 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Saksham Srivastava >Assignee: Prachi Damle > Fix For: 4.2.1 > > > Create multi cluster setup. > Tag host in one cluster with host tag t1. > Create a service offering using the host tag t1 > Deploy a vm using the tagged service offering. > Even if tagged/untagged hosts are available across different clusters the api > does not list correct hosts for migration for the deployed vm. > Expected behavior: > The api should return the list of suitable/unsuitable hosts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4572) findHostsForMigration API does not return correct host list
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13755066#comment-13755066 ] ASF subversion and git services commented on CLOUDSTACK-4572: - Commit 6354604eedff0c5f4ddef4940ce02df80adb656c in branch refs/heads/4.2-forward from [~saksham] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6354604 ] CLOUDSTACK-4572: findHostsForMigration API does not return correct host list Changes: Expected behavior: The api should return the list of suitable/unsuitable hosts Added fix that creates a deep copy of the the variable allHosts and prevents faulty host list return. > findHostsForMigration API does not return correct host list > --- > > Key: CLOUDSTACK-4572 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4572 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Saksham Srivastava >Assignee: Saksham Srivastava > Fix For: 4.2.1 > > > Create multi cluster setup. > Tag host in one cluster with host tag t1. > Create a service offering using the host tag t1 > Deploy a vm using the tagged service offering. > Even if tagged/untagged hosts are available across different clusters the api > does not list correct hosts for migration for the deployed vm. > Expected behavior: > The api should return the list of suitable/unsuitable hosts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4475) [ZWPS] attaching an uploaded volume to a VM is always going to first primary storage added
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su updated CLOUDSTACK-4475: -- Status: Open (was: Ready To Review) > [ZWPS] attaching an uploaded volume to a VM is always going to first primary > storage added > -- > > Key: CLOUDSTACK-4475 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4475 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.1 > Environment: vmware esxi 5.1 >Reporter: Srikanteswararao Talluri >Assignee: edison su > Fix For: 4.2.1 > > > Steps to reproduce: > == > 1. Have an advanced zone deployment with two cluster one host and one cluster > scoped primary storage each > 2. add two more zone wide primary storages > 3. create a deployment on zone scoped primary storage > 4. upload a volume. > 5. attach uploaded volume to VM created in step 3. > Observation: > = > While attaching volume, volume is always copied to first available primary > storage in the storage_pool table and as a result attaching a volume created > on cluster scoped primary storage to a VM with its root volume on zone wide > primary storage fails. > mysql> select * from storage_pool; > ++--+--+---+--++++---++--+---++-+-+-+-+---+-++-+---+ > | id | name | uuid | pool_type > | port | data_center_id | pod_id | cluster_id | used_bytes| > capacity_bytes | host_address | user_info | path > | created | removed | update_time | status | > storage_provider_name | scope | hypervisor | managed | capacity_iops | > ++--+--+---+--++++---++--+---++-+-+-+-+---+-++-+---+ > | 1 | primaryclus1 | 722e6181-8497-3d31-9933-a0a267ae376c | > NetworkFilesystem | 2049 | 1 | 1 | 1 | > 1678552014848 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/primary | 2013-08-23 12:11:12 | NULL > | NULL| Maintenance | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 2 | pimaryclu2 | 9fd9b0fc-c9fd-39b8-8d66-06372c5ff6d2 | > NetworkFilesystem | 2049 | 1 | 1 | 2 | > 1676566495232 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/clus1primary | 2013-08-23 12:18:14 | NULL > | NULL| Up | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 3 | clus1p2 | 22e0c3fe-a390-38fa-8ff7-e1d965a36309 | > NetworkFilesystem | 2049 | 1 | 1 | 1 | > 1660903886848 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/clus1p2 | 2013-08-23 14:30:32 | NULL > | NULL| Up | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 4 | clus1p3 | f2d9fb6b-c433-3c03-acf8-8f73eac48fae | > NetworkFilesystem | 2049 | 1 | 1 | 1 | > 1660901400576 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/clus1p3 | 2013-08-23 14:31:05 | NULL > | NULL| Up | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 5 | clus2p2 | 13bf579c-51f3-317b-893a-98ff6ca8f486 | > NetworkFilesystem | 2049 | 1 | 1 | 2 | > 1660900147200 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/clus2p2 | 2013-08-23 14:31:38 | NULL > | NULL| Up | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 7 | clus2p3 | 294ae9ff-cb02-33a0-8f31-21fdd8ff34db | > NetworkFilesystem | 2049 | 1 | 1 | 2 | > 1660894195712 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/clus2p3 | 2013-08-23 14:33:03 | NULL > | NULL| Up | DefaultPrimary| CLUSTER | NULL | >
[jira] [Commented] (CLOUDSTACK-4089) Provide a drop down to specify VLAN,Switch type, Traffic label name while configuring Zone(VMWARE)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13754943#comment-13754943 ] Jessica Wang commented on CLOUDSTACK-4089: -- From: Sateesh Chodapuneedi Sent: Friday, August 30, 2013 10:31 AM To: Jessica Wang Cc: Ram Ganesh Subject: RE: If "vmware.use.dvswitch" is false and "vmware.use.nexus.vswitch" is true, then what is default vswitch type? (CLOUDSTACK-4089 Provide a drop down to specify VLAN,Switch type, Traffic label name while configuring Zone) Hi Jessica, >If "vmware.use.dvswitch" is false and "vmware.use.nexus.vswitch" is true, then >what is default vswitch type? If vmware.use.dvswitch is false then flag vmware.use.nexus.vswitch should be ignored. And in that case default vswitch is Standard vswitch. Regards, Sateesh > Provide a drop down to specify VLAN,Switch type, Traffic label name while > configuring Zone(VMWARE) > -- > > Key: CLOUDSTACK-4089 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4089 > 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: Sailaja Mada >Assignee: Jessica Wang > Fix For: 4.2.0 > > Attachments: 2013-08-06-A.jpg, > addClusterCmd_wrongDuplicateParameterNames.jpg, dropPN.png, > edit-traffic-type-vmware.jpg > > > Observation: > Setup: VMWARE > 1. While configuring Zone, During Physical network creation , currently > there is a text field to specify VLAN Id for the traffic , Traffic label > name & Switch type (vmwaresvs,vmwaredvs,nexusdvs) > 2. It is text field and there is a possibility of missing some of the > parameters. > 3. While adding cluster we have an option to specify the traffic label name > and drop down to select the Switch type. > This is the request to provide a drop down to specify VLAN,Switch type, > Traffic label name while configuring Zone(VMWARE). This will avoid a lot of > confusion between Zone vs Cluster level configuration. > It also simplifies the configuration process. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4574) MS:NPE: Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.DestroyVMCmd java.lang.NullPointerException
Parth Jagirdar created CLOUDSTACK-4574: -- Summary: MS:NPE: Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.DestroyVMCmd java.lang.NullPointerException Key: CLOUDSTACK-4574 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4574 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API, Management Server Affects Versions: 4.2.1 Environment: VMWare Reporter: Parth Jagirdar Attachments: destroyVM.txt NPE while attempting to destroy a VM. VM successfully gets destroyed but raises NPE in Logs. Logs attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4574) MS:NPE: Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.DestroyVMCmd java.lang.NullPointerException
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar updated CLOUDSTACK-4574: --- Attachment: destroyVM.txt > MS:NPE: Unexpected exception while executing > org.apache.cloudstack.api.command.user.vm.DestroyVMCmd > java.lang.NullPointerException > -- > > Key: CLOUDSTACK-4574 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4574 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server >Affects Versions: 4.2.1 > Environment: VMWare >Reporter: Parth Jagirdar > Attachments: destroyVM.txt > > > NPE while attempting to destroy a VM. > VM successfully gets destroyed but raises NPE in Logs. > Logs attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-3556) Add NIC icon is not appearing in UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13755033#comment-13755033 ] Marty Sweet commented on CLOUDSTACK-3556: - I have never seen this feature on CloudStack UI, although I know it is possible via the API. Could you give more details about this issue? Was the 'Add NIC' Icon already there in 4.0.2? Marty > Add NIC icon is not appearing in UI > --- > > Key: CLOUDSTACK-3556 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3556 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, UI >Affects Versions: 4.1.0, 4.1.1 > Environment: Ubuntu (KVM) >Reporter: Raafat Mhamed >Priority: Blocker > > After upgrading from version 4.0.2 to version 4.1 ,I can't see the ADD NIC > icon from interface tab. > check image http://postimg.org/image/ekb5olse9/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4190) [Object_store_refactor] volume should be deleted from staging storage after successfule volume migration
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13754987#comment-13754987
]
Sanjeev N commented on CLOUDSTACK-4190:
---
Also storage artifacts like snapshots and templates are not getting deleted
from staging storage when template was created from snapshot.
Following actions take place when template is created from snapshot:
1.Snapshot gets downloaded from S3 to snapshots directory in NFS staging storage
2.Then it gets copied to template directory in NFS staging storage
3.Finally it is uploaded to S3
After successful operation snapshot and template copied to staging storage (in
step1 and step2) should be deleted.
> [Object_store_refactor] volume should be deleted from staging storage after
> successfule volume migration
>
>
> Key: CLOUDSTACK-4190
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4190
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, Volumes
>Affects Versions: 4.2.0
> Environment: Latest build from ACS 4.2 branch
> Storage: S3 for image store, NFS for secondary staging and primary storage
>Reporter: Sanjeev N
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: cloud.dmp, cloud.dmp, cloud.rar, management-server.rar,
> management-server.rar
>
>
> volume copied to secondary staging storage during volume migration should be
> deleted after migration.
> Steps to Reproduce:
> =
> 1.Bring up CS with xen cluster using S3 from image store, NFS for secondary
> staging and primary storage
> 2.Deploy guest vm using default cent os template with both Root and Data
> disks.
> 3.Add another NFS based primary storage to the cluster
> 4.Detach data disk from the vm
> 5.Migrate the data disk to the primary storage created at step3
> Result:
> ==
> Volume migration was successful. But the volume copied to secondary staging
> storage during migration process did not get deleted.
> Only volume from source primary storage got deleted.
> Observations:
>
> Following is the log snippet during volume migration:
> 2013-08-08 08:34:49,766 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null)
> ===START=== 10.146.0.20 -- GET
> command=migrateVolume&storageid=29a0c990-7100-3a8d-b570-ba9f84ca78bc&volumeid=e1eb0b93-3fba-4437-ad50-b12bf1d6f1ef&response=json&sessionkey=qXfe5TLEOA5koD0qobFirCKKbOY%3D&_=1375965252817
> 2013-08-08 08:34:49,954 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-13:null) submit async job-44 = [
> 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ], details: AsyncJobVO {id:44, userId:
> 2, accountId: 2, sessionKey: null, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd,
> cmdOriginator: null, cmdInfo:
> {"response":"json","sessionkey":"qXfe5TLEOA5koD0qobFirCKKbOY\u003d","cmdEventType":"VOLUME.MIGRATE","ctxUserId":"2","storageid":"29a0c990-7100-3a8d-b570-ba9f84ca78bc","httpmethod":"GET","volumeid":"e1eb0b93-3fba-4437-ad50-b12bf1d6f1ef","_":"1375965252817","ctxAccountId":"2","ctxStartEventId":"194"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-08 08:34:49,957 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null)
> ===END=== 10.146.0.20 -- GET
> command=migrateVolume&storageid=29a0c990-7100-3a8d-b570-ba9f84ca78bc&volumeid=e1eb0b93-3fba-4437-ad50-b12bf1d6f1ef&response=json&sessionkey=qXfe5TLEOA5koD0qobFirCKKbOY%3D&_=1375965252817
> 2013-08-08 08:34:49,961 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) Executing
> org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd for job-44 = [
> 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]
> 2013-08-08 08:34:50,032 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) copyAsync
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-08 08:34:50,061 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) copyAsync
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-08 08:34:50,083 DEBUG [agent.transport.Request]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) Seq
> 2-1303576995: Sending { Cmd , MgmtId: 6615759585382, via: 2, Ver: v1, Flags:
> 100011,
> [{"org.apache.cloudstack.storage.com
[jira] [Resolved] (CLOUDSTACK-4362) VM's are failing to start after its DATA volume is migrated to other primary storage
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelven Yang resolved CLOUDSTACK-4362.
-
Resolution: Fixed
> VM's are failing to start after its DATA volume is migrated to other primary
> storage
> -
>
> Key: CLOUDSTACK-4362
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4362
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, VMware
>Affects Versions: 4.2.0
>Reporter: Sailaja Mada
>Assignee: Sateesh Chodapuneedi
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: alllogs.rar, apilog.log, apilog.log, db1.sql,
> management-server.log, management-server.log, ssvmlogs.rar
>
>
> Steps:
> 1. Configure Adv zone with 2 zone wide primary storage's
> 2. Create new account and Deploy instance using this account
> 3. Add new DATA volume and attach to this instance
> 4. Resize this volume from 5 GB to 7 GB
> 5. As admin, Migrate this volume from Storage 1 to Storage2 ( Zone wide
> primary)
> 6. Stop and Start this instance
> Observation:
> VM's are failing to start after its DATA volume is migrated to second zone
> wide primary storage
> 2013-08-16 12:04:48,465 DEBUG [cloud.storage.VolumeManagerImpl]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Checking
> if we need to prepare 2 volumes for VM[User|inst2]
> 2013-08-16 12:04:48,471 DEBUG [cloud.storage.VolumeManagerImpl]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Mismatch
> in storage pool Pool[1|NetworkFilesystem] assigned by deploymentPlanner and
> the one associated with volume Vol[14|vm=5|DATADISK]
> 2013-08-16 12:04:48,471 DEBUG [cloud.storage.VolumeManagerImpl]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Shared
> volume Vol[14|vm=5|DATADISK] will be migrated on storage pool
> Pool[1|NetworkFilesystem] assigned by deploymentPlanner
> 2013-08-16 12:04:48,524 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) copyAsync
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-16 12:04:48,528 DEBUG [cache.allocator.StorageCacheRandomAllocator]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Can't
> find staging storage in zone: 1
> 2013-08-16 12:04:48,591 DEBUG [agent.transport.Request]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Seq
> 3-1725105201: Sending { Cmd , MgmtId: 187767034175903, via: 3, Ver: v1,
> Flags: 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"b55516ba-da2e-454a-8cee-7d1a927ce25a","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"b33e996a-444e-3685-9070-0865067454c4","id":2,"poolType":"NetworkFilesystem","host":"10.102.192.100","path":"/cpg_vol/sailaja/sailajaps2","port":2049}},"name":"new32","size":7516192768,"path":"a04a400289624aad99ab92e7c089343d","volumeId":14,"vmName":"i-3-5-VM","accountId":3,"format":"OVA","id":14,"hypervisorType":"VMware"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"b55516ba-da2e-454a-8cee-7d1a927ce25a","volumeType":"DATADISK","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.102.192.100/cpg_vol/sailaja/sailajass1","_role":"Image"}},"name":"new32","size":7516192768,"path":"volumes/3/14","volumeId":14,"vmName":"i-3-5-VM","accountId":3,"format":"OVA","id":14,"hypervisorType":"VMware"}},"executeInSequence":false,"wait":10800}}]
> }
> 2013-08-16 12:04:48,700 DEBUG [agent.transport.Request]
> (AgentManager-Handler-1:null) Seq 3-1725105201: Processing: { Ans: , MgmtId:
> 187767034175903, via: 3, Ver: v1, Flags: 10,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"result":false,"details":"copy
> volume from primary to secondary failed due to exception: Exception:
> java.lang.NullPointerException\nMessage: null\n","wait":0}}] }
> 2013-08-16 12:04:48,702 DEBUG [agent.transport.Request]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Seq
> 3-1725105201: Received: { Ans: , MgmtId: 187767034175903, via: 3, Ver: v1,
> Flags: 10, { CopyCmdAnswer } }
> 2013-08-16 12:04:48,706 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) copy to
> image store failed: copy volume from primary to secondary failed due to
> exception: Exception: java.lang.NullPointerException
> Message: null
> 2013-08-16 12:04:48,728 DEBUG [storage.image.BaseImageStoreDriverImpl]
> (Job-Executor-37:job-74 = [ 0
[jira] [Commented] (CLOUDSTACK-4362) VM's are failing to start after its DATA volume is migrated to other primary storage
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13754980#comment-13754980
]
ASF subversion and git services commented on CLOUDSTACK-4362:
-
Commit e362f51f37b718466f2d80d9193e58e1fafcb8fb in branch
refs/heads/4.2-forward from [~kelveny]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e362f51 ]
CLOUDSTACK-4362: always honor vCenter on-disk meta data to work with live
migration better
> VM's are failing to start after its DATA volume is migrated to other primary
> storage
> -
>
> Key: CLOUDSTACK-4362
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4362
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, VMware
>Affects Versions: 4.2.0
>Reporter: Sailaja Mada
>Assignee: Sateesh Chodapuneedi
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: alllogs.rar, apilog.log, apilog.log, db1.sql,
> management-server.log, management-server.log, ssvmlogs.rar
>
>
> Steps:
> 1. Configure Adv zone with 2 zone wide primary storage's
> 2. Create new account and Deploy instance using this account
> 3. Add new DATA volume and attach to this instance
> 4. Resize this volume from 5 GB to 7 GB
> 5. As admin, Migrate this volume from Storage 1 to Storage2 ( Zone wide
> primary)
> 6. Stop and Start this instance
> Observation:
> VM's are failing to start after its DATA volume is migrated to second zone
> wide primary storage
> 2013-08-16 12:04:48,465 DEBUG [cloud.storage.VolumeManagerImpl]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Checking
> if we need to prepare 2 volumes for VM[User|inst2]
> 2013-08-16 12:04:48,471 DEBUG [cloud.storage.VolumeManagerImpl]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Mismatch
> in storage pool Pool[1|NetworkFilesystem] assigned by deploymentPlanner and
> the one associated with volume Vol[14|vm=5|DATADISK]
> 2013-08-16 12:04:48,471 DEBUG [cloud.storage.VolumeManagerImpl]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Shared
> volume Vol[14|vm=5|DATADISK] will be migrated on storage pool
> Pool[1|NetworkFilesystem] assigned by deploymentPlanner
> 2013-08-16 12:04:48,524 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) copyAsync
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-16 12:04:48,528 DEBUG [cache.allocator.StorageCacheRandomAllocator]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Can't
> find staging storage in zone: 1
> 2013-08-16 12:04:48,591 DEBUG [agent.transport.Request]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Seq
> 3-1725105201: Sending { Cmd , MgmtId: 187767034175903, via: 3, Ver: v1,
> Flags: 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"b55516ba-da2e-454a-8cee-7d1a927ce25a","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"b33e996a-444e-3685-9070-0865067454c4","id":2,"poolType":"NetworkFilesystem","host":"10.102.192.100","path":"/cpg_vol/sailaja/sailajaps2","port":2049}},"name":"new32","size":7516192768,"path":"a04a400289624aad99ab92e7c089343d","volumeId":14,"vmName":"i-3-5-VM","accountId":3,"format":"OVA","id":14,"hypervisorType":"VMware"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"b55516ba-da2e-454a-8cee-7d1a927ce25a","volumeType":"DATADISK","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.102.192.100/cpg_vol/sailaja/sailajass1","_role":"Image"}},"name":"new32","size":7516192768,"path":"volumes/3/14","volumeId":14,"vmName":"i-3-5-VM","accountId":3,"format":"OVA","id":14,"hypervisorType":"VMware"}},"executeInSequence":false,"wait":10800}}]
> }
> 2013-08-16 12:04:48,700 DEBUG [agent.transport.Request]
> (AgentManager-Handler-1:null) Seq 3-1725105201: Processing: { Ans: , MgmtId:
> 187767034175903, via: 3, Ver: v1, Flags: 10,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"result":false,"details":"copy
> volume from primary to secondary failed due to exception: Exception:
> java.lang.NullPointerException\nMessage: null\n","wait":0}}] }
> 2013-08-16 12:04:48,702 DEBUG [agent.transport.Request]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Seq
> 3-1725105201: Received: { Ans: , MgmtId: 187767034175903, via: 3, Ver: v1,
> Flags: 10, { CopyCmdAnswer } }
> 2013-08-16 12:04:48,706 DEBUG [storage.motion.AncientDat
[jira] [Updated] (CLOUDSTACK-4558) Add network offering UI problem
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marty Sweet updated CLOUDSTACK-4558: Component/s: UI > Add network offering UI problem > --- > > Key: CLOUDSTACK-4558 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4558 > 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: MacOS 10.8.4 / Macbook Pro >Reporter: Soheil Eizadi >Priority: Minor > > I have an overlapping window problem on a Modal Dialog box that is shown. > The problem happens on Safari, FireFox and Chrome on MacOS. I tried to > reproduce the problem on Win7 with IE but it worked fine there. > The window overlaps only if you create two offerings back to back. I create > one, enable service and go back > and create another one and I have the problem. > I have seen this UI problem when I was working on 4.2 and now that I have > merged to the latest trunk on 4.3, > I still see this problem. > Here is snapshot of the problem: > https://sites.google.com/site/opencloudstack/_/rsrc/1377725503233/home/Screen%20Shot%202013-08-28%20at%209.46.29%20AM.png -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-4539) [VMWARE] vmware.create.full.clone is set to true in upgraded setup;default nature of vms are full clone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chandan Purushothama closed CLOUDSTACK-4539. Verified it with 4.2 Build: 4.2 Upgraded Setup: mysql> select * from configuration where name like "%clone%"; +--+--+---+--+---+--+ | category | instance | component | name | value | description | +--+--+---+--+---+--+ | Advanced | DEFAULT | UserVmManager | vmware.create.full.clone | false | If set to true, creates VMs as full clones on ESX hypervisor | +--+--+---+--+---+--+ 1 row in set (0.00 sec) mysql> select * from version; ++--+-+--+ | id | version | updated | step | ++--+-+--+ | 1 | 3.0.6.20121222035904 | 2013-08-27 15:39:16 | Complete | | 2 | 3.0.7| 2013-08-29 23:59:19 | Complete | | 3 | 4.1.0| 2013-08-29 23:59:19 | Complete | | 4 | 4.2.0| 2013-08-29 23:59:19 | Complete | ++--+-+--+ 4 rows in set (0.01 sec) 4.2 Fresh Installation: mysql> select * from configuration where name like "%clone%"; +--+--+---+--+---+--+ | category | instance | component | name | value | description | +--+--+---+--+---+--+ | Advanced | DEFAULT | UserVmManager | vmware.create.full.clone | true | If set to true, creates VMs as full clones on ESX hypervisor | +--+--+---+--+---+--+ 1 row in set (0.00 sec) mysql> select * from version; ++-+-+--+ | id | version | updated | step | ++-+-+--+ | 1 | 4.0.0 | 2013-08-30 09:38:46 | Complete | | 2 | 4.1.0 | 2013-08-30 13:41:09 | Complete | | 3 | 4.2.0 | 2013-08-30 13:41:09 | Complete | ++-+-+--+ 3 rows in set (0.00 sec) > [VMWARE] vmware.create.full.clone is set to true in upgraded setup;default > nature of vms are full clone > --- > > Key: CLOUDSTACK-4539 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4539 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0 >Reporter: prashant kumar mishra >Assignee: Venkata Siva Vijayendra Bhamidipati >Priority: Critical > Fix For: 4.2.0, 4.2.1 > > Attachments: Logs_DB.rar > > > In upgraded setup vm should get deployed as linked clone ,default value of > global parameter vmware.create.full.clone should be false in upgraded setup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4570) Doc: service cloud-management wrongly named
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-4570: - Summary: Doc: service cloud-management wrongly named (was: service cloud-management wrongly named) > Doc: service cloud-management wrongly named > --- > > Key: CLOUDSTACK-4570 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4570 > 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: Pavan Kumar Bandarupally >Priority: Critical > Fix For: 4.2.0 > > > 4.2.6 LDAP User Authentication: Limitation > "service cloud-management restart" should be changed to "service > cloudstack-management restart" > Apart from that there is a minor spelling mistake in section "3.7. About > Secondary Storage" > In the last but one paragraph in that section , swift is misspelled as swoft. > The NFS storage in each zone acts as a staging area > through which all templates and other secondary storage data pass before > being forwarded to Swoft > or S3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4475) [ZWPS] attaching an uploaded volume to a VM is always going to first primary storage added
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ram Ganesh updated CLOUDSTACK-4475: --- Component/s: Doc > [ZWPS] attaching an uploaded volume to a VM is always going to first primary > storage added > -- > > Key: CLOUDSTACK-4475 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4475 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc, Storage Controller >Affects Versions: 4.2.1 > Environment: vmware esxi 5.1 >Reporter: Srikanteswararao Talluri >Assignee: edison su > Labels: ReleaseNote > Fix For: 4.2.1 > > > Steps to reproduce: > == > 1. Have an advanced zone deployment with two cluster one host and one cluster > scoped primary storage each > 2. add two more zone wide primary storages > 3. create a deployment on zone scoped primary storage > 4. upload a volume. > 5. attach uploaded volume to VM created in step 3. > Observation: > = > While attaching volume, volume is always copied to first available primary > storage in the storage_pool table and as a result attaching a volume created > on cluster scoped primary storage to a VM with its root volume on zone wide > primary storage fails. > mysql> select * from storage_pool; > ++--+--+---+--++++---++--+---++-+-+-+-+---+-++-+---+ > | id | name | uuid | pool_type > | port | data_center_id | pod_id | cluster_id | used_bytes| > capacity_bytes | host_address | user_info | path > | created | removed | update_time | status | > storage_provider_name | scope | hypervisor | managed | capacity_iops | > ++--+--+---+--++++---++--+---++-+-+-+-+---+-++-+---+ > | 1 | primaryclus1 | 722e6181-8497-3d31-9933-a0a267ae376c | > NetworkFilesystem | 2049 | 1 | 1 | 1 | > 1678552014848 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/primary | 2013-08-23 12:11:12 | NULL > | NULL| Maintenance | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 2 | pimaryclu2 | 9fd9b0fc-c9fd-39b8-8d66-06372c5ff6d2 | > NetworkFilesystem | 2049 | 1 | 1 | 2 | > 1676566495232 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/clus1primary | 2013-08-23 12:18:14 | NULL > | NULL| Up | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 3 | clus1p2 | 22e0c3fe-a390-38fa-8ff7-e1d965a36309 | > NetworkFilesystem | 2049 | 1 | 1 | 1 | > 1660903886848 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/clus1p2 | 2013-08-23 14:30:32 | NULL > | NULL| Up | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 4 | clus1p3 | f2d9fb6b-c433-3c03-acf8-8f73eac48fae | > NetworkFilesystem | 2049 | 1 | 1 | 1 | > 1660901400576 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/clus1p3 | 2013-08-23 14:31:05 | NULL > | NULL| Up | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 5 | clus2p2 | 13bf579c-51f3-317b-893a-98ff6ca8f486 | > NetworkFilesystem | 2049 | 1 | 1 | 2 | > 1660900147200 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/clus2p2 | 2013-08-23 14:31:38 | NULL > | NULL| Up | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 7 | clus2p3 | 294ae9ff-cb02-33a0-8f31-21fdd8ff34db | > NetworkFilesystem | 2049 | 1 | 1 | 2 | > 1660894195712 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/clus2p3 | 2013-08-23 14:33:03 | NULL > | NULL| Up | DefaultPrimary| CLUSTER
[jira] [Updated] (CLOUDSTACK-4475) [ZWPS] attaching an uploaded volume to a VM is always going to first primary storage added
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ram Ganesh updated CLOUDSTACK-4475: --- Labels: ReleaseNote (was: ) > [ZWPS] attaching an uploaded volume to a VM is always going to first primary > storage added > -- > > Key: CLOUDSTACK-4475 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4475 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.1 > Environment: vmware esxi 5.1 >Reporter: Srikanteswararao Talluri >Assignee: edison su > Labels: ReleaseNote > Fix For: 4.2.1 > > > Steps to reproduce: > == > 1. Have an advanced zone deployment with two cluster one host and one cluster > scoped primary storage each > 2. add two more zone wide primary storages > 3. create a deployment on zone scoped primary storage > 4. upload a volume. > 5. attach uploaded volume to VM created in step 3. > Observation: > = > While attaching volume, volume is always copied to first available primary > storage in the storage_pool table and as a result attaching a volume created > on cluster scoped primary storage to a VM with its root volume on zone wide > primary storage fails. > mysql> select * from storage_pool; > ++--+--+---+--++++---++--+---++-+-+-+-+---+-++-+---+ > | id | name | uuid | pool_type > | port | data_center_id | pod_id | cluster_id | used_bytes| > capacity_bytes | host_address | user_info | path > | created | removed | update_time | status | > storage_provider_name | scope | hypervisor | managed | capacity_iops | > ++--+--+---+--++++---++--+---++-+-+-+-+---+-++-+---+ > | 1 | primaryclus1 | 722e6181-8497-3d31-9933-a0a267ae376c | > NetworkFilesystem | 2049 | 1 | 1 | 1 | > 1678552014848 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/primary | 2013-08-23 12:11:12 | NULL > | NULL| Maintenance | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 2 | pimaryclu2 | 9fd9b0fc-c9fd-39b8-8d66-06372c5ff6d2 | > NetworkFilesystem | 2049 | 1 | 1 | 2 | > 1676566495232 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/clus1primary | 2013-08-23 12:18:14 | NULL > | NULL| Up | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 3 | clus1p2 | 22e0c3fe-a390-38fa-8ff7-e1d965a36309 | > NetworkFilesystem | 2049 | 1 | 1 | 1 | > 1660903886848 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/clus1p2 | 2013-08-23 14:30:32 | NULL > | NULL| Up | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 4 | clus1p3 | f2d9fb6b-c433-3c03-acf8-8f73eac48fae | > NetworkFilesystem | 2049 | 1 | 1 | 1 | > 1660901400576 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/clus1p3 | 2013-08-23 14:31:05 | NULL > | NULL| Up | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 5 | clus2p2 | 13bf579c-51f3-317b-893a-98ff6ca8f486 | > NetworkFilesystem | 2049 | 1 | 1 | 2 | > 1660900147200 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/clus2p2 | 2013-08-23 14:31:38 | NULL > | NULL| Up | DefaultPrimary| CLUSTER | NULL | > 0 | NULL | > | 7 | clus2p3 | 294ae9ff-cb02-33a0-8f31-21fdd8ff34db | > NetworkFilesystem | 2049 | 1 | 1 | 2 | > 1660894195712 | 590228480 | 10.147.28.7 | NULL | > /export/home/talluri/vmware.campo/clus2p3 | 2013-08-23 14:33:03 | NULL > | NULL| Up | DefaultPrimary| C
[jira] [Reopened] (CLOUDSTACK-4190) [Object_store_refactor] volume should be deleted from staging storage after successfule volume migration
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanjeev N reopened CLOUDSTACK-4190:
---
This issue is observed again in the latest build. Deleting volume copied to
staging storage during Extracting volume operation failed.
Tried this scenario in VMWare.
Log snippet from SSVM log:
2013-08-30 17:56:12,957 INFO [vmware.mo.VirtualMachineMO]
(agentRequest-Handler-5:null) volss: copy vmdk and ovf file starts 1377885372957
2013-08-30 17:56:12,958 INFO [vmware.mo.HypervisorHostHelper]
(agentRequest-Handler-5:null) Resolving host name in url through vCenter, url:
https://10.147.40.13/nfc/5207a809-22f9-1196-9a18-4d74877a2bd4/disk-0.vmdk
2013-08-30 17:56:12,958 INFO [vmware.mo.HypervisorHostHelper]
(agentRequest-Handler-5:null) host name in url is already in IP address, url:
https://10.147.40.13/nfc/5207a809-22f9-1196-9a18-4d74877a2bd4/disk-0.vmdk
2013-08-30 17:56:12,959 INFO [vmware.mo.VirtualMachineMO]
(agentRequest-Handler-5:null) Download VMDK file for export. url:
https://10.147.40.13/nfc/5207a809-22f9-1196-9a18-4d74877a2bd4/disk-0.vmdk
2013-08-30 17:56:12,975 INFO [vmware.util.VmwareContext]
(agentRequest-Handler-5:null) Connected, conn:
sun.net.www.protocol.https.DelegateHttpsURLConnection:https://10.147.40.13/nfc/5207a809-22f9-1196-9a18-4d74877a2bd4/disk-0.vmdk,
retry: 0
2013-08-30 17:56:22,512 INFO [storage.template.S3TemplateDownloader]
(s3-transfer-manager-worker-1:null) download completed
2013-08-30 17:56:22,514 INFO [storage.template.S3TemplateDownloader]
(s3-transfer-manager-worker-1:null) download completed
2013-08-30 17:56:22,514 INFO [storage.template.DownloadManagerImpl]
(pool-1-thread-4:null) Download Completion for jobId:
b9ae8901-5e24-4a0a-af8b-d4e54957e73f, status=DOWNLOAD_FINISHED
2013-08-30 17:59:28,805 INFO [vmware.mo.VirtualMachineMO]
(agentRequest-Handler-5:null) volss: copy vmdk and ovf file finishes
1377885568805
2013-08-30 17:59:28,806 INFO [vmware.mo.HttpNfcLeaseMO]
(agentRequest-Handler-5:null) close ProgressReporter, interrupt reporter runner
to let it quit
2013-08-30 17:59:28,806 INFO [vmware.mo.HttpNfcLeaseMO] (Thread-13:null)
ProgressReporter is interrupted, quiting
2013-08-30 17:59:28,837 INFO [vmware.mo.HttpNfcLeaseMO] (Thread-13:null)
ProgressReporter stopped
2013-08-30 17:59:35,540 DEBUG [cloud.agent.Agent] (agentRequest-Handler-5:null)
Seq 4-453574766: { Ans: , MgmtId: 6615759585382, via: 4, Ver: v1, Flags: 110,
[{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"newData":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"path":"volumes/2/8/4c7e8fc27a134a039b317bf0aa9382a5","accountId":0,"id":0}},"result":true,"wait":0}}]
}
2013-08-30 17:59:35,652 DEBUG [cloud.agent.Agent] (agentRequest-Handler-1:null)
Request:Seq 4-453574770: { Cmd , MgmtId: 6615759585382, via: 4, Ver: v1,
Flags: 100111,
[{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"3c4c5331-4764-4a13-8a96-cc4893bf6361","volumeType":"DATADISK","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.147.28.7/export/home/sanjeev/sec_xen_os","_role":"ImageCache"}},"name":"test","size":5368709120,"path":"volumes/2/8/4c7e8fc27a134a039b317bf0aa9382a5","volumeId":8,"accountId":2,"format":"OVA","id":8,"hypervisorType":"VMware"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"3c4c5331-4764-4a13-8a96-cc4893bf6361","volumeType":"DATADISK","dataStore":{"com.cloud.agent.api.to.S3TO":{"id":2,"uuid":"6074c28c-9ae5-43be-a45e-89489efe887c","endPoint":"10.147.29.56:8080","bucketName":"imagestore","httpsFlag":false,"created":"Aug
30, 2013 10:32:03
AM","enableRRS":false}},"name":"test","size":5368709120,"path":"volumes/2/8","volumeId":8,"accountId":2,"format":"OVA","id":8,"hypervisorType":"VMware"}},"executeInSequence":true,"wait":10800}}]
}
2013-08-30 17:59:35,652 DEBUG [cloud.agent.Agent] (agentRequest-Handler-1:null)
Processing command: org.apache.cloudstack.storage.command.CopyCommand
2013-08-30 17:59:35,660 DEBUG [vmware.manager.VmwareStorageManagerImpl]
(agentRequest-Handler-1:null) Executing: sudo sync
2013-08-30 17:59:35,995 DEBUG [vmware.manager.VmwareStorageManagerImpl]
(agentRequest-Handler-1:null) Execution is successful.
2013-08-30 17:59:35,995 INFO [vmware.manager.VmwareStorageManagerImpl]
(agentRequest-Handler-1:null) Package OVA with commmand: tar -cf
4c7e8fc27a134a039b317bf0aa9382a5.ova 4c7e8fc27a134a039b317bf0aa9382a5.ovf
4c7e8fc27a134a039b317bf0aa9382a5-disk0.vmdk
2013-08-30 17:59:35,995 DEBUG [vmware.manager.VmwareStorageManagerImpl]
(agentRequest-Handler-1:null) Executing: tar -cf
4c7e8fc27a134a039b317bf0aa9382a5.ova 4c7e8fc27a134a039b317bf0aa9382a5.ovf
4c7e8fc27a134a039b317bf0aa9382a5-disk0.vmdk
2013-08-30 17:59:36,068 DEBUG [vmware.manager.VmwareStorageManagerImpl]
(agentRequest-Handler-1:null) Execution is successful.
2013-08-30 17:59:36,0
[jira] [Updated] (CLOUDSTACK-4190) [Object_store_refactor] volume should be deleted from staging storage after successfule volume migration
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanjeev N updated CLOUDSTACK-4190:
--
Attachment: management-server.rar
cloud.rar
cloud.dmp
Attached latest management server log file, cloud.log from SSVM and cloud DB.
> [Object_store_refactor] volume should be deleted from staging storage after
> successfule volume migration
>
>
> Key: CLOUDSTACK-4190
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4190
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, Volumes
>Affects Versions: 4.2.0
> Environment: Latest build from ACS 4.2 branch
> Storage: S3 for image store, NFS for secondary staging and primary storage
>Reporter: Sanjeev N
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: cloud.dmp, cloud.dmp, cloud.rar, management-server.rar,
> management-server.rar
>
>
> volume copied to secondary staging storage during volume migration should be
> deleted after migration.
> Steps to Reproduce:
> =
> 1.Bring up CS with xen cluster using S3 from image store, NFS for secondary
> staging and primary storage
> 2.Deploy guest vm using default cent os template with both Root and Data
> disks.
> 3.Add another NFS based primary storage to the cluster
> 4.Detach data disk from the vm
> 5.Migrate the data disk to the primary storage created at step3
> Result:
> ==
> Volume migration was successful. But the volume copied to secondary staging
> storage during migration process did not get deleted.
> Only volume from source primary storage got deleted.
> Observations:
>
> Following is the log snippet during volume migration:
> 2013-08-08 08:34:49,766 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null)
> ===START=== 10.146.0.20 -- GET
> command=migrateVolume&storageid=29a0c990-7100-3a8d-b570-ba9f84ca78bc&volumeid=e1eb0b93-3fba-4437-ad50-b12bf1d6f1ef&response=json&sessionkey=qXfe5TLEOA5koD0qobFirCKKbOY%3D&_=1375965252817
> 2013-08-08 08:34:49,954 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-13:null) submit async job-44 = [
> 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ], details: AsyncJobVO {id:44, userId:
> 2, accountId: 2, sessionKey: null, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd,
> cmdOriginator: null, cmdInfo:
> {"response":"json","sessionkey":"qXfe5TLEOA5koD0qobFirCKKbOY\u003d","cmdEventType":"VOLUME.MIGRATE","ctxUserId":"2","storageid":"29a0c990-7100-3a8d-b570-ba9f84ca78bc","httpmethod":"GET","volumeid":"e1eb0b93-3fba-4437-ad50-b12bf1d6f1ef","_":"1375965252817","ctxAccountId":"2","ctxStartEventId":"194"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 6615759585382,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-08-08 08:34:49,957 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null)
> ===END=== 10.146.0.20 -- GET
> command=migrateVolume&storageid=29a0c990-7100-3a8d-b570-ba9f84ca78bc&volumeid=e1eb0b93-3fba-4437-ad50-b12bf1d6f1ef&response=json&sessionkey=qXfe5TLEOA5koD0qobFirCKKbOY%3D&_=1375965252817
> 2013-08-08 08:34:49,961 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) Executing
> org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd for job-44 = [
> 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]
> 2013-08-08 08:34:50,032 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) copyAsync
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-08 08:34:50,061 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) copyAsync
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-08 08:34:50,083 DEBUG [agent.transport.Request]
> (Job-Executor-45:job-44 = [ 3c1fd226-af63-47fe-9a5c-fc4770f1a6f5 ]) Seq
> 2-1303576995: Sending { Cmd , MgmtId: 6615759585382, via: 2, Ver: v1, Flags:
> 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"e1eb0b93-3fba-4437-ad50-b12bf1d6f1ef","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"c65a038a-750c-3b4f-bf26-7ce3b74e1c85","id":3,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/sanjeev/pri_xen_os","port":2049}},"name":"cs-3416"
[jira] [Commented] (CLOUDSTACK-4089) Provide a drop down to specify VLAN,Switch type, Traffic label name while configuring Zone(VMWARE)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13754962#comment-13754962 ] ASF subversion and git services commented on CLOUDSTACK-4089: - Commit 2c2ebee3f7395a6541088eefe91ceaa1b02c70d5 in branch refs/heads/4.2-forward from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2c2ebee ] CLOUDSTACK-4089: UI > zone wizard > hypervisor VMware > multiple physical networks > edit Public/Guest traffic type > fix a bug that vSwitch Type dropdown selection didn't remain after Public/Guest traffic type is dragged to another physical network. > Provide a drop down to specify VLAN,Switch type, Traffic label name while > configuring Zone(VMWARE) > -- > > Key: CLOUDSTACK-4089 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4089 > 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: Sailaja Mada >Assignee: Jessica Wang > Fix For: 4.2.0 > > Attachments: 2013-08-06-A.jpg, > addClusterCmd_wrongDuplicateParameterNames.jpg, dropPN.png, > edit-traffic-type-vmware.jpg > > > Observation: > Setup: VMWARE > 1. While configuring Zone, During Physical network creation , currently > there is a text field to specify VLAN Id for the traffic , Traffic label > name & Switch type (vmwaresvs,vmwaredvs,nexusdvs) > 2. It is text field and there is a possibility of missing some of the > parameters. > 3. While adding cluster we have an option to specify the traffic label name > and drop down to select the Switch type. > This is the request to provide a drop down to specify VLAN,Switch type, > Traffic label name while configuring Zone(VMWARE). This will avoid a lot of > confusion between Zone vs Cluster level configuration. > It also simplifies the configuration process. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4089) Provide a drop down to specify VLAN,Switch type, Traffic label name while configuring Zone(VMWARE)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13754970#comment-13754970 ] ASF subversion and git services commented on CLOUDSTACK-4089: - Commit 3b14b66b20e06b30005be169617637f3635aa89d in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3b14b66 ] CLOUDSTACK-4089: UI > zone wizard > hypervisor VMware > multiple physical networks > edit Public/Guest traffic type > fix a bug that vSwitch Type dropdown selection didn't remain after Public/Guest traffic type is dragged to another physical network. > Provide a drop down to specify VLAN,Switch type, Traffic label name while > configuring Zone(VMWARE) > -- > > Key: CLOUDSTACK-4089 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4089 > 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: Sailaja Mada >Assignee: Jessica Wang > Fix For: 4.2.0 > > Attachments: 2013-08-06-A.jpg, > addClusterCmd_wrongDuplicateParameterNames.jpg, dropPN.png, > edit-traffic-type-vmware.jpg > > > Observation: > Setup: VMWARE > 1. While configuring Zone, During Physical network creation , currently > there is a text field to specify VLAN Id for the traffic , Traffic label > name & Switch type (vmwaresvs,vmwaredvs,nexusdvs) > 2. It is text field and there is a possibility of missing some of the > parameters. > 3. While adding cluster we have an option to specify the traffic label name > and drop down to select the Switch type. > This is the request to provide a drop down to specify VLAN,Switch type, > Traffic label name while configuring Zone(VMWARE). This will avoid a lot of > confusion between Zone vs Cluster level configuration. > It also simplifies the configuration process. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4089) Provide a drop down to specify VLAN,Switch type, Traffic label name while configuring Zone(VMWARE)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Mada updated CLOUDSTACK-4089: - Fix Version/s: (was: Future) 4.2.0 > Provide a drop down to specify VLAN,Switch type, Traffic label name while > configuring Zone(VMWARE) > -- > > Key: CLOUDSTACK-4089 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4089 > 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: Sailaja Mada >Assignee: Jessica Wang > Fix For: 4.2.0 > > Attachments: 2013-08-06-A.jpg, > addClusterCmd_wrongDuplicateParameterNames.jpg, dropPN.png, > edit-traffic-type-vmware.jpg > > > Observation: > Setup: VMWARE > 1. While configuring Zone, During Physical network creation , currently > there is a text field to specify VLAN Id for the traffic , Traffic label > name & Switch type (vmwaresvs,vmwaredvs,nexusdvs) > 2. It is text field and there is a possibility of missing some of the > parameters. > 3. While adding cluster we have an option to specify the traffic label name > and drop down to select the Switch type. > This is the request to provide a drop down to specify VLAN,Switch type, > Traffic label name while configuring Zone(VMWARE). This will avoid a lot of > confusion between Zone vs Cluster level configuration. > It also simplifies the configuration process. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4572) findHostsForMigration API does not return correct host list
Saksham Srivastava created CLOUDSTACK-4572: -- Summary: findHostsForMigration API does not return correct host list Key: CLOUDSTACK-4572 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4572 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Saksham Srivastava Assignee: Saksham Srivastava Fix For: 4.2.1 Create multi cluster setup. Tag host in one cluster with host tag t1. Create a service offering using the host tag t1 Deploy a vm using the tagged service offering. Even if tagged/untagged hosts are available across different clusters the api does not list correct hosts for migration for the deployed vm. Expected behavior: The api should return the list of suitable/unsuitable hosts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4568) Need to add this to the release note of 4.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinandan Prateek updated CLOUDSTACK-4568: --- Fix Version/s: (was: 4.2.0) 4.2.1 > Need to add this to the release note of 4.2 > --- > > Key: CLOUDSTACK-4568 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4568 > 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: Bharat Kumar >Assignee: Jessica Tomechak > Labels: releasenotes > Fix For: 4.2.1 > > > After upgrade to 4.2 the mem.overporvisioning.factor and > cpu.overporvisioning.factor will be set to one that is the default value and > are at cluster level now. > In case if some one prior to the 4.2 was usign mem.overporvisioning.factor > and cpu.overporvisioning.factor after the upgrade these will be reset to one > and can be changed by editing the cluster settings. > All the clusters created after the upgrade will get created with the values > overcomit values specified at the global config by default. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4568) Need to add this to the release note of 4.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinandan Prateek updated CLOUDSTACK-4568: --- Assignee: Jessica Tomechak > Need to add this to the release note of 4.2 > --- > > Key: CLOUDSTACK-4568 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4568 > 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: Bharat Kumar >Assignee: Jessica Tomechak > Labels: releasenotes > Fix For: 4.2.0 > > > After upgrade to 4.2 the mem.overporvisioning.factor and > cpu.overporvisioning.factor will be set to one that is the default value and > are at cluster level now. > In case if some one prior to the 4.2 was usign mem.overporvisioning.factor > and cpu.overporvisioning.factor after the upgrade these will be reset to one > and can be changed by editing the cluster settings. > All the clusters created after the upgrade will get created with the values > overcomit values specified at the global config by default. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [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=13754891#comment-13754891 ] Prasanna Santhanam commented on CLOUDSTACK-4550: from Edison via http://markmail.org/message/sh6tzjchlsgs3ojd The main issue is related to guest network bridge name schema is changed, thus migrate vm, create new vm will have problem after upgraded to 4.2. If you are using basic network, then don't need to do the following steps. The proposed upgrade paths are: 1. Stick to old network name in 4.2. You can set "network.bridge.name.schema=3.0" in /etc/cloudstack/agent/agent.properties 2. Upgrade to new network name schema, need to do the following steps: a. Install 4.2 cloudstack agent on each kvm host b. Run "cloudstack-agent-upgrade". This script will upgrade all the existing bridge name to new bridge name. c. install a libvirt hook: c1. mkdir /etc/libvirt/hooks c2. cp /usr/share/cloudstack-agent/lib/libvirtqemuhook /etc/libvirt/hooks/qemu c3. chmod +x /etc/libvirt/hooks/qemu c4. service libvirtd restart c5. service cloudstack-agent restart The potential issues if you are using above upgrade path 2: 1. If you are using multiple physical bridges, other than the one specified in "guest.network.device" in /etc/cloudstack/agent/agent.properties, then the vm live migration may have problem. 2. Advanced zone with security group, wont' work. 3. may have old iptables rules left on kvm host, it shouldn't impact guest connectivity though. > [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 >Assignee: Jessica Tomechak >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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CLOUDSTACK-4362) VM's are failing to start after its DATA volume is migrated to other primary storage
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sailaja Mada reopened CLOUDSTACK-4362:
--
Tried with latest build. I still see this issue happening hence reopening the
defect :
2013-08-30 20:44:34,231 INFO [storage.resource.VmwareStorageProcessor]
(DirectAgent-149:10.102.192.23) Executing resource DestroyCommand:
{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"648b5c5d-1cab-4989-b615-41bc79768227","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"1f4e45b6-07ef-3349-8f95-6009b972184c","id":2,"poolType":"NetworkFilesystem","host":"10.102.192.100","path":"/cpg_vol/sailaja/newzwps1","port":2049}},"name":"ROOT-3","size":2147483648,"path":"ROOT-3","volumeId":13,"vmName":"i-3-3-VM","accountId":3,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[031590029a323361b699e44f6f4cdb90]
i-3-3-VM/ROOT-3.vmdk\"]}","format":"OVA","id":13,"hypervisorType":"VMware"}},"wait":0}
2013-08-30 20:44:34,279 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-149:null) Seq 4-1955201548: Response Received:
2013-08-30 20:44:34,279 DEBUG [agent.transport.Request] (DirectAgent-149:null)
Seq 4-1955201548: Processing: { Ans: , MgmtId: 94838926819810, via: 4, Ver:
v1, Flags: 10,
[{"com.cloud.agent.api.Answer":{"result":true,"details":"Success","wait":0}}] }
2013-08-30 20:44:34,280 DEBUG [agent.transport.Request] (Job-Executor-60:job-47
= [ 5ad42adc-2dc4-4369-997b-ced159d96680 ]) Seq 4-1955201548: Received: { Ans:
, MgmtId: 94838926819810, via: 4, Ver: v1, Flags: 10, { Answer } }
2013-08-30 20:44:34,294 INFO [storage.volume.VolumeServiceImpl]
(Job-Executor-60:job-47 = [ 5ad42adc-2dc4-4369-997b-ced159d96680 ]) Volume 13
is not referred anywhere, remove it from volumes table
2013-08-30 20:44:34,301 ERROR [cloud.storage.VolumeManagerImpl]
(Job-Executor-60:job-47 = [ 5ad42adc-2dc4-4369-997b-ced159d96680 ]) migrate
volume failed:copy volume secondary to primary failed due to exception:
Exception: javax.xml.ws.soap.SOAPFaultException
Message:
Required parameter spec is missing
while parsing call information for method ImportVApp
at line 1, column 110
while parsing SOAP body
at line 1, column 102
while parsing SOAP envelope
at line 1, column 38
while parsing HTTP request for method importVApp
on object of type vim.ResourcePool
at line 1, column 0
2013-08-30 20:44:34,302 INFO [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-60:job-47 = [ 5ad42adc-2dc4-4369-997b-ced159d96680 ]) Unable to
contact resource.
com.cloud.exception.StorageUnavailableException: Resource [StoragePool:2] is
unreachable: migrate volume failed: copy volume secondary to primary failed due
to exception: Exception: javax.xml.ws.soap.SOAPFaultException
Message:
Required parameter spec is missing
while parsing call information for method ImportVApp
at line 1, column 110
while parsing SOAP body
at line 1, column 102
while parsing SOAP envelope
at line 1, column 38
while parsing HTTP request for method importVApp
on object of type vim.ResourcePool
at line 1, column 0
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:227)
at
org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209)
at
com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3406)
at
com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:1948)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
org.apache.cloudstack.api.command.user.vm.StartVMCmd.execute(StartVMCmd.java:120)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
at
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thre
[jira] [Updated] (CLOUDSTACK-4362) VM's are failing to start after its DATA volume is migrated to other primary storage
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sailaja Mada updated CLOUDSTACK-4362:
-
Attachment: alllogs.rar
> VM's are failing to start after its DATA volume is migrated to other primary
> storage
> -
>
> Key: CLOUDSTACK-4362
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4362
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, VMware
>Affects Versions: 4.2.0
>Reporter: Sailaja Mada
>Assignee: Sateesh Chodapuneedi
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: alllogs.rar, apilog.log, db1.sql, management-server.log,
> ssvmlogs.rar
>
>
> Steps:
> 1. Configure Adv zone with 2 zone wide primary storage's
> 2. Create new account and Deploy instance using this account
> 3. Add new DATA volume and attach to this instance
> 4. Resize this volume from 5 GB to 7 GB
> 5. As admin, Migrate this volume from Storage 1 to Storage2 ( Zone wide
> primary)
> 6. Stop and Start this instance
> Observation:
> VM's are failing to start after its DATA volume is migrated to second zone
> wide primary storage
> 2013-08-16 12:04:48,465 DEBUG [cloud.storage.VolumeManagerImpl]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Checking
> if we need to prepare 2 volumes for VM[User|inst2]
> 2013-08-16 12:04:48,471 DEBUG [cloud.storage.VolumeManagerImpl]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Mismatch
> in storage pool Pool[1|NetworkFilesystem] assigned by deploymentPlanner and
> the one associated with volume Vol[14|vm=5|DATADISK]
> 2013-08-16 12:04:48,471 DEBUG [cloud.storage.VolumeManagerImpl]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Shared
> volume Vol[14|vm=5|DATADISK] will be migrated on storage pool
> Pool[1|NetworkFilesystem] assigned by deploymentPlanner
> 2013-08-16 12:04:48,524 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) copyAsync
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-16 12:04:48,528 DEBUG [cache.allocator.StorageCacheRandomAllocator]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Can't
> find staging storage in zone: 1
> 2013-08-16 12:04:48,591 DEBUG [agent.transport.Request]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Seq
> 3-1725105201: Sending { Cmd , MgmtId: 187767034175903, via: 3, Ver: v1,
> Flags: 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"b55516ba-da2e-454a-8cee-7d1a927ce25a","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"b33e996a-444e-3685-9070-0865067454c4","id":2,"poolType":"NetworkFilesystem","host":"10.102.192.100","path":"/cpg_vol/sailaja/sailajaps2","port":2049}},"name":"new32","size":7516192768,"path":"a04a400289624aad99ab92e7c089343d","volumeId":14,"vmName":"i-3-5-VM","accountId":3,"format":"OVA","id":14,"hypervisorType":"VMware"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"b55516ba-da2e-454a-8cee-7d1a927ce25a","volumeType":"DATADISK","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.102.192.100/cpg_vol/sailaja/sailajass1","_role":"Image"}},"name":"new32","size":7516192768,"path":"volumes/3/14","volumeId":14,"vmName":"i-3-5-VM","accountId":3,"format":"OVA","id":14,"hypervisorType":"VMware"}},"executeInSequence":false,"wait":10800}}]
> }
> 2013-08-16 12:04:48,700 DEBUG [agent.transport.Request]
> (AgentManager-Handler-1:null) Seq 3-1725105201: Processing: { Ans: , MgmtId:
> 187767034175903, via: 3, Ver: v1, Flags: 10,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"result":false,"details":"copy
> volume from primary to secondary failed due to exception: Exception:
> java.lang.NullPointerException\nMessage: null\n","wait":0}}] }
> 2013-08-16 12:04:48,702 DEBUG [agent.transport.Request]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Seq
> 3-1725105201: Received: { Ans: , MgmtId: 187767034175903, via: 3, Ver: v1,
> Flags: 10, { CopyCmdAnswer } }
> 2013-08-16 12:04:48,706 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) copy to
> image store failed: copy volume from primary to secondary failed due to
> exception: Exception: java.lang.NullPointerException
> Message: null
> 2013-08-16 12:04:48,728 DEBUG [storage.image.BaseImageStoreDriverImpl]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784f
[jira] [Closed] (CLOUDSTACK-2654) VPC UI Missing information
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Federle closed CLOUDSTACK-2654. - Resolution: Fixed This was just a placeholder; thus closing the bug. > VPC UI Missing information > --- > > Key: CLOUDSTACK-2654 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2654 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.0.2 >Reporter: Sonny Chhen >Assignee: Sonny Chhen > Labels: ui > Fix For: 4.2.0 > > Original Estimate: 168h > Remaining Estimate: 168h > > VPC UI needs to include information pertaining to new nTier features. > The look and feel needs to be modified to include the following information: > -Network ACL lists > -Internal load balancers > -Public load balancers > Additionally the structure of the chart needs to better reflect the new nTier > functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [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 ] Prasanna Santhanam updated CLOUDSTACK-4550: --- Description: 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 was: 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 rename the bridges to allow migration to work between host added before upgrade to those added after upgrade This can be done by running the cloudstack-agent-upgrade script > [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 >Assignee: Jessica Tomechak >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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-4471) [Vmware] Error Instances leaving ROOT Volumes in expunging state and not getting updated as removed evenafter having the instances expunged
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Mada closed CLOUDSTACK-4471. Regressed with latest builds. This is fixed now. Hence closing the bug. > [Vmware] Error Instances leaving ROOT Volumes in expunging state and not > getting updated as removed evenafter having the instances expunged > --- > > Key: CLOUDSTACK-4471 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4471 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, VMware >Affects Versions: 4.2.1 >Reporter: Sailaja Mada >Assignee: Likitha Shetty >Priority: Critical > Fix For: 4.2.0, 4.2.1 > > Attachments: errovolumedb.sql, mslogs.rar, volumelogs.rar > > > Steps: > 1.Configure Advzone with VMWARE > 2. Set the expunge interval to lesser value > 3. Enable storage.cleanup interval to lesser value > 4. There is a case where user instances failed to deploy and they are into > ERROR state > Obseravation: > 1. There is a root DISK created as part of this deployment. When VM got > expunged , these ROOT disks are moved to expunging state . But these are not > updated as removed. > 2. With that list Volumes we get to see all these volumes being displayed > fe7cc918-dd31-4925-9dd0-9917807d051aROOT-36efb00e64-4f4d-4582-818c-cb80446d5e5c307XenZone1ROOT01043592d-9df7-490b-a408-0dd7cdb802391043592d-9df7-490b-a408-0dd7cdb80239Expunging21474836482013-08-22T14:47:16+0530Allocatedvmwareuser1ca370a5c-0b19-4358-a757-58549a2c29edcdcsharedfalse3c1dacb5-6629-432b-b093-f260067a078chost13host13truefalse -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4362) VM's are failing to start after its DATA volume is migrated to other primary storage
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sailaja Mada updated CLOUDSTACK-4362:
-
Attachment: management-server.log
apilog.log
> VM's are failing to start after its DATA volume is migrated to other primary
> storage
> -
>
> Key: CLOUDSTACK-4362
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4362
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, VMware
>Affects Versions: 4.2.0
>Reporter: Sailaja Mada
>Assignee: Sateesh Chodapuneedi
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: alllogs.rar, apilog.log, apilog.log, db1.sql,
> management-server.log, management-server.log, ssvmlogs.rar
>
>
> Steps:
> 1. Configure Adv zone with 2 zone wide primary storage's
> 2. Create new account and Deploy instance using this account
> 3. Add new DATA volume and attach to this instance
> 4. Resize this volume from 5 GB to 7 GB
> 5. As admin, Migrate this volume from Storage 1 to Storage2 ( Zone wide
> primary)
> 6. Stop and Start this instance
> Observation:
> VM's are failing to start after its DATA volume is migrated to second zone
> wide primary storage
> 2013-08-16 12:04:48,465 DEBUG [cloud.storage.VolumeManagerImpl]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Checking
> if we need to prepare 2 volumes for VM[User|inst2]
> 2013-08-16 12:04:48,471 DEBUG [cloud.storage.VolumeManagerImpl]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Mismatch
> in storage pool Pool[1|NetworkFilesystem] assigned by deploymentPlanner and
> the one associated with volume Vol[14|vm=5|DATADISK]
> 2013-08-16 12:04:48,471 DEBUG [cloud.storage.VolumeManagerImpl]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Shared
> volume Vol[14|vm=5|DATADISK] will be migrated on storage pool
> Pool[1|NetworkFilesystem] assigned by deploymentPlanner
> 2013-08-16 12:04:48,524 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) copyAsync
> inspecting src type VOLUME copyAsync inspecting dest type VOLUME
> 2013-08-16 12:04:48,528 DEBUG [cache.allocator.StorageCacheRandomAllocator]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Can't
> find staging storage in zone: 1
> 2013-08-16 12:04:48,591 DEBUG [agent.transport.Request]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Seq
> 3-1725105201: Sending { Cmd , MgmtId: 187767034175903, via: 3, Ver: v1,
> Flags: 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"b55516ba-da2e-454a-8cee-7d1a927ce25a","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"b33e996a-444e-3685-9070-0865067454c4","id":2,"poolType":"NetworkFilesystem","host":"10.102.192.100","path":"/cpg_vol/sailaja/sailajaps2","port":2049}},"name":"new32","size":7516192768,"path":"a04a400289624aad99ab92e7c089343d","volumeId":14,"vmName":"i-3-5-VM","accountId":3,"format":"OVA","id":14,"hypervisorType":"VMware"}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"b55516ba-da2e-454a-8cee-7d1a927ce25a","volumeType":"DATADISK","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.102.192.100/cpg_vol/sailaja/sailajass1","_role":"Image"}},"name":"new32","size":7516192768,"path":"volumes/3/14","volumeId":14,"vmName":"i-3-5-VM","accountId":3,"format":"OVA","id":14,"hypervisorType":"VMware"}},"executeInSequence":false,"wait":10800}}]
> }
> 2013-08-16 12:04:48,700 DEBUG [agent.transport.Request]
> (AgentManager-Handler-1:null) Seq 3-1725105201: Processing: { Ans: , MgmtId:
> 187767034175903, via: 3, Ver: v1, Flags: 10,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"result":false,"details":"copy
> volume from primary to secondary failed due to exception: Exception:
> java.lang.NullPointerException\nMessage: null\n","wait":0}}] }
> 2013-08-16 12:04:48,702 DEBUG [agent.transport.Request]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) Seq
> 3-1725105201: Received: { Ans: , MgmtId: 187767034175903, via: 3, Ver: v1,
> Flags: 10, { CopyCmdAnswer } }
> 2013-08-16 12:04:48,706 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-37:job-74 = [ 039d4ba9-0507-4dea-b658-5a784fdc0588 ]) copy to
> image store failed: copy volume from primary to secondary failed due to
> exception: Exception: java.lang.NullPointerException
> Message: null
> 2013-08-16 12:04:48,728 DEBUG [storage.image.BaseImageStoreD
[jira] [Updated] (CLOUDSTACK-4572) findHostsForMigration API does not return correct host list
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saksham Srivastava updated CLOUDSTACK-4572: --- Status: Ready To Review (was: In Progress) > findHostsForMigration API does not return correct host list > --- > > Key: CLOUDSTACK-4572 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4572 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Saksham Srivastava >Assignee: Saksham Srivastava > Fix For: 4.2.1 > > > Create multi cluster setup. > Tag host in one cluster with host tag t1. > Create a service offering using the host tag t1 > Deploy a vm using the tagged service offering. > Even if tagged/untagged hosts are available across different clusters the api > does not list correct hosts for migration for the deployed vm. > Expected behavior: > The api should return the list of suitable/unsuitable hosts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-4572) findHostsForMigration API does not return correct host list
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13754879#comment-13754879 ] Saksham Srivastava commented on CLOUDSTACK-4572: Fix available for review at : https://reviews.apache.org/r/13911/ > findHostsForMigration API does not return correct host list > --- > > Key: CLOUDSTACK-4572 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4572 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Saksham Srivastava >Assignee: Saksham Srivastava > Fix For: 4.2.1 > > > Create multi cluster setup. > Tag host in one cluster with host tag t1. > Create a service offering using the host tag t1 > Deploy a vm using the tagged service offering. > Even if tagged/untagged hosts are available across different clusters the api > does not list correct hosts for migration for the deployed vm. > Expected behavior: > The api should return the list of suitable/unsuitable hosts. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [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=13754873#comment-13754873 ] Jessica Tomechak commented on CLOUDSTACK-4550: -- Not sure I understand the description given. Can anyone (Edison?) please explain this further. The description seems to say you have to rename the bridges after you rename the bridges. > [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 >Assignee: Jessica Tomechak >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 rename > the bridges to allow migration to work between host added before upgrade to > those added after upgrade > This can be done by running the cloudstack-agent-upgrade script -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4573) Aquire IP address above domain limit in VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4573: --- Labels: integration-test (was: ) > Aquire IP address above domain limit in VPC > --- > > Key: CLOUDSTACK-4573 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4573 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.1.1 >Reporter: Daan Hoogland > Labels: integration-test > > It is possible to aquire more public IP addresses than allowed according to > the domain limit, the steps are as followed: > user has a limit of 2 ips > domain has a limit of 5 ips > 1) create a VPC, this will aquire a public IP address for source nat > 2) create a network (not in the VPC) and aquire an IP address, we are now at > the max of two allowed public IP address > 3) create one or more networks on the VPC > 4) under IP addresses (VPC configuration) aquire IP address > We now have 3 IP addresses aquired, I tested more, I was allowed up to 7, at > which time there was no more free IP addresses available in cloudstack. > conclusion: the non VPC network is correctly adhering to the domain limit, > but the VPC is not, and IP addresses on the VPC are not counted for when > checking the domain limit. > Strange thing is though, that cloudstack is checking the IP limit during the > creation of a VPC, you cannot create a VPC when you have already reached your > IP limit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-4573) Aquire IP address above domain limit in VPC
Daan Hoogland created CLOUDSTACK-4573: - Summary: Aquire IP address above domain limit in VPC Key: CLOUDSTACK-4573 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4573 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.1.1 Reporter: Daan Hoogland It is possible to aquire more public IP addresses than allowed according to the domain limit, the steps are as followed: user has a limit of 2 ips domain has a limit of 5 ips 1) create a VPC, this will aquire a public IP address for source nat 2) create a network (not in the VPC) and aquire an IP address, we are now at the max of two allowed public IP address 3) create one or more networks on the VPC 4) under IP addresses (VPC configuration) aquire IP address We now have 3 IP addresses aquired, I tested more, I was allowed up to 7, at which time there was no more free IP addresses available in cloudstack. conclusion: the non VPC network is correctly adhering to the domain limit, but the VPC is not, and IP addresses on the VPC are not counted for when checking the domain limit. Strange thing is though, that cloudstack is checking the IP limit during the creation of a VPC, you cannot create a VPC when you have already reached your IP limit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-4357) [Automation] Failed to create snapshot in vmware, failed with SOAP Exception
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan closed CLOUDSTACK-4357.
---
Snapshot working with latest build
> [Automation] Failed to create snapshot in vmware, failed with SOAP Exception
>
>
> Key: CLOUDSTACK-4357
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4357
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Snapshot, VMware
>Affects Versions: 4.2.0
> Environment: 4.2 build
> Automation setup in vmware
>Reporter: Rayees Namathponnan
>Assignee: Kelven Yang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: CLOUDSTACK-4357.rar
>
>
> Create snapshot from volume in vmware, snapshot creation failed with below
> error
> result":true,"wait":0}}] }
> 2013-08-15 11:28:36,021 DEBUG [agent.transport.Request]
> (Job-Executor-132:job-2140 = [ 5e9e1e44-ab33-4b64-bd3b-5b6ab4e69389 ]) Seq
> 3-1674384702: Received: { Ans: , MgmtId: 90
> 928106758026, via: 3, Ver: v1, Flags: 10, {
> CreateObjectAnswer } }
> 2013-08-15 11:28:36,116 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-132:job-2140 = [ 5e9e1e44-ab33-4b64-bd3b-5b6ab4e69389 ])
> copyAsync inspecting src type S
>NAPSHOT copyAsync inspecting dest type SNAPSHOT
> 2013-08-15 11:28:36,205 DEBUG [agent.transport.Request]
> (Job-Executor-132:job-2140 = [ 5e9e1e44-ab33-4b64-bd3b-5b6ab4e69389 ]) Seq
> 9-1658651749: Sending { Cmd , MgmtId: 90928
> 106758026, via: 9, Ver: v1, Flags: 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"7e5f482
>
> 3-9341-4d82-84a2-885f690523a3","volume":{"uuid":"a3cb5568-9e7d-432b-b2b9-b7947fc34f2d","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{
>
> "uuid":"16c8ee2e-3f26-3062-8878-b7d6c53c5797","id":2,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/automation/SC-CLOUD-QA03/primary2","port":2049
>
> }},"name":"ROOT-585","size":2147483648,"path":"ROOT-585","volumeId":642,"vmName":"i-2-585-TestVM","accountId":2,"format":"OVA","id":642,"hypervisorType":"VMware"},"dataStore":
>
> {"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"16c8ee2e-3f26-3062-8878-b7d6c53c5797","id":2,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/ex
>
> port/home/automation/SC-CLOUD-QA03/primary2","port":2049}},"vmName":"i-2-585-TestVM","name":"ryzVM_ROOT-585_20130815182835","hypervisorType":"VMware","id":21}},"destTO":{"org.
>
> apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"snapshots/2/642","volume":{"uuid":"a3cb5568-9e7d-432b-b2b9-b7947fc34f2d","volumeType":"ROOT","dataStore":{"org.apache.c
>
> loudstack.storage.to.PrimaryDataStoreTO":{"uuid":"16c8ee2e-3f26-3062-8878-b7d6c53c5797","id":2,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/auto
>
> mation/SC-CLOUD-QA03/primary2","port":2049}},"name":"ROOT-585","size":2147483648,"path":"ROOT-585","volumeId":642,"vmName":"i-2-585-TestVM","accountId":2,"format":"OVA","id":6
>
> 42,"hypervisorType":"VMware"},"dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.223.110.232:/export/home/automation/SC-CLOUD-QA03/secondary1","_role":"Image"}},"vm
>
> Name":"i-2-585-TestVM","name":"ryzVM_ROOT-585_20130815182835","hypervisorType":"VMware","id":21}},"executeInSequence":false,"wait":21600}}]
> }
> 2013-08-15 11:28:36,459 DEBUG [agent.transport.Request]
> (AgentManager-Handler-6:null) Seq 9-1658651749: Processing: { Ans: , MgmtId:
> 90928106758026, via: 9, Ver: v1, Flags: 1
> 0,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"result":false,"details":"backup
> snapshot exception: Exception:
> javax.xml.ws.soap.SOAPFaultExceptio
[jira] [Reopened] (CLOUDSTACK-4335) [Automation] Test case test_deployVmSharedNetworkWithoutIpRange failed due subnet is overlapped with subnet in other network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan reopened CLOUDSTACK-4335: - Still fails with latest runs Execute cmd: createnetwork failed, due to: errorCode: 431, errorText:The IP range already has IPs that overlap with the new range. Please specify a different start IP/end IP. >> begin captured logging << testclient.testcase.TestSharedNetworkWithoutIp: DEBUG: Fetching default shared network offering from nw offerings testclient.testcase.TestSharedNetworkWithoutIp: DEBUG: Shared netwrk offering: DefaultSharedNetworkOffering testclient.testcase.TestSharedNetworkWithoutIp: DEBUG: Creating a network from shared network offering - >> end captured logging << - Stacktrace File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run testMethod() File "/Repo_30X/ipcl/cloudstack/test/integration/component/test_shared_network_offering.py", line 195, in test_deployVmSharedNetworkWithoutIpRange zoneid=self.zone.id File "/usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py", line 1959, in create return Network(apiclient.createNetwork(cmd).__dict__) File "/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py", line 1708, in createNetwork response = self.connection.marvin_request(command, response_type=response, method=method) File "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line 222, in marvin_request response = jsonHelper.getResultObj(response.json(), response_type) File "/usr/local/lib/python2.7/site-packages/marvin/jsonHelper.py", line 148, in getResultObj raise cloudstackException.cloudstackAPIException(respname, errMsg) Execute cmd: createnetwork failed, due to: errorCode: 431, errorText:The IP range already has IPs that overlap with the new range. Please specify a different start IP/end IP. >> begin captured logging << testclient.testcase.TestSharedNetworkWithoutIp: DEBUG: Fetching default shared network offering from nw offerings testclient.testcase.TestSharedNetworkWithoutIp: DEBUG: Shared netwrk offering: DefaultSharedNetworkOffering testclient.testcase.TestSharedNetworkWithoutIp: DEBUG: Creating a network from shared network offering - >> end captured logging << - > [Automation] Test case test_deployVmSharedNetworkWithoutIpRange failed due > subnet is overlapped with subnet in other network > -- > > Key: CLOUDSTACK-4335 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4335 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.2.0 > Environment: Automation >Reporter: Rayees Namathponnan >Priority: Critical > Fix For: 4.2.0 > > > Below test case failed > integration.component.test_shared_network_offering.TestSharedNetworkWithoutIp.test_deployVmSharedNetworkWithoutIpRange > Error Message > Execute cmd: createnetwork failed, due to: errorCode: 431, errorText:This > subnet is overlapped with subnet in other network 332 in zone Adv-KVM-Zone1 . > Please specify a different gateway/netmask. > >> begin captured logging << > testclient.testcase.TestSharedNetworkWithoutIp: DEBUG: Fetching default > shared network offering from nw offerings > testclient.testcase.TestSharedNetworkWithoutIp: DEBUG: Shared netwrk > offering: DefaultSharedNetworkOffering > testclient.testcase.TestSharedNetworkWithoutIp: DEBUG: Creating a network > from shared network offering > - >> end captured logging << - > Stacktrace > File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run > testMethod() > File > "/Repo_30X/ipcl/cloudstack/test/integration/component/test_shared_network_offering.py", > line 195, in test_deployVmSharedNetworkWithoutIpRange > zoneid=self.zone.id > File > "/usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py", line > 1940, in create > return Network(apiclient.createNetwork(cmd).__dict__) > File > "/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py", > line 1709, in createNetwork > response = self.connection.marvin_request(command, > response_type=response, method=method) > File > "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line > 222, in marvin_request > response = jsonHelper.getResultObj(response
