[jira] [Commented] (CLOUDSTACK-1815) Document new default password encoding mechanism, SHA256Salt
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13751025#comment-13751025 ] ASF subversion and git services commented on CLOUDSTACK-1815: - Commit d0ad80530f9f7a62464497a7d39ccd63958463a1 in branch refs/heads/4.2-forward from [~radhikap] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d0ad805 ] review comments for CLOUDSTACK-1815 > Document new default password encoding mechanism, SHA256Salt > > > Key: CLOUDSTACK-1815 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1815 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Reporter: Jessica Tomechak >Assignee: Radhika Nair >Priority: Minor > Fix For: 4.2.0 > > Attachments: Apache_CloudStack-4.2.0-Installation_Guide-en-US.pdf > > -- 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-4491) test_netscaler_config.TestGuestNetworkShutDown missing netscaler addition
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13751020#comment-13751020 ] ASF subversion and git services commented on CLOUDSTACK-4491: - Commit 6334b738d048591c6ded39f9ad3f448a2454b03d in branch refs/heads/master from [~sowmyak] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6334b73 ] CLOUDSTACK-4491: Added missing NS setup Signed-off-by: venkataswamybabu budumuru (cherry picked from commit 239281a401f09df9519bb8e8637c2060b9be019b) > test_netscaler_config.TestGuestNetworkShutDown missing netscaler addition > - > > Key: CLOUDSTACK-4491 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4491 > 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: Test with netscaler as lb >Reporter: Sowmya Krishnan >Assignee: Sowmya Krishnan > Fix For: 4.2.1 > > > test_netscaler_config -> ClassTestGuestNetworkShutDown is missing netscaler > addition. We are creating an offering with NS as LB and hence fails during > deploy VM -- 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-4491) test_netscaler_config.TestGuestNetworkShutDown missing netscaler addition
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13751019#comment-13751019 ] ASF subversion and git services commented on CLOUDSTACK-4491: - Commit 239281a401f09df9519bb8e8637c2060b9be019b in branch refs/heads/4.2-forward from [~sowmyak] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=239281a ] CLOUDSTACK-4491: Added missing NS setup Signed-off-by: venkataswamybabu budumuru > test_netscaler_config.TestGuestNetworkShutDown missing netscaler addition > - > > Key: CLOUDSTACK-4491 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4491 > 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: Test with netscaler as lb >Reporter: Sowmya Krishnan >Assignee: Sowmya Krishnan > Fix For: 4.2.1 > > > test_netscaler_config -> ClassTestGuestNetworkShutDown is missing netscaler > addition. We are creating an offering with NS as LB and hence fails during > deploy VM -- 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-4303) [Automation] test_egress_fw_rules test cases failed to except script and tests failed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam reassigned CLOUDSTACK-4303: -- Assignee: Jayapal Reddy (was: Prasanna Santhanam) Hey Jayapal, can you take a quick look to see if this a failure in CS? > [Automation] test_egress_fw_rules test cases failed to except script and > tests failed > -- > > Key: CLOUDSTACK-4303 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4303 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Infra >Reporter: Rayees Namathponnan >Assignee: Jayapal Reddy >Priority: Critical > > Test cases from integration.component.test_egress_fw_rules.TestEgressFWRules > fails > test cases expecting script @ /tmp/expect_scrip, this should be handled in > test case, > Stacktrace > File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run > testMethod() > File > "/Repo_30X/ipcl/cloudstack/test/integration/component/test_egress_fw_rules.py", > line 51, in test_wrap_exception_log > raise e > Script result is ['bash: /tmp/expect_script.exp: /usr/bin/expect: bad > interpreter: No such file or directory'] is not matching with ['100'] > >> begin captured logging << > testclient.testcase.TestEgressFWRules: DEBUG: Creating network with network > offering: 0bd6212f-b34c-4f7a-a84f-0c172bee6ac8 > testclient.testcase.TestEgressFWRules: DEBUG: Created network with ID: > ef2626c2-6849-43e7-8418-0c89ed528d62 > testclient.testcase.TestEgressFWRules: DEBUG: Deploying instance in the > account: test-SSFX20 > testclient.testcase.TestEgressFWRules: DEBUG: Deployed instance in account: > test-SSFX20 > testclient.testcase.TestEgressFWRules: DEBUG: expect_script>> > #!/usr/bin/expect > spawn ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o > LogLevel=quiet -i /root/.ssh/id_rsa.cloud -p 3922 root@169.254.3.141 > expect "root@r-342-QA:~#" > send "ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o > LogLevel=quiet root@10.1.1.215 ping -c 1 www.google.com; exit $? > " > expect "root@10.1.1.215's password: " > send "password > " > interact >
[jira] [Updated] (CLOUDSTACK-4303) [Automation] test_egress_fw_rules test cases failed to except script and tests failed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam updated CLOUDSTACK-4303: --- Component/s: Network Controller > [Automation] test_egress_fw_rules test cases failed to except script and > tests failed > -- > > Key: CLOUDSTACK-4303 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4303 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Infra, Network Controller >Reporter: Rayees Namathponnan >Assignee: Jayapal Reddy >Priority: Critical > > Test cases from integration.component.test_egress_fw_rules.TestEgressFWRules > fails > test cases expecting script @ /tmp/expect_scrip, this should be handled in > test case, > Stacktrace > File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run > testMethod() > File > "/Repo_30X/ipcl/cloudstack/test/integration/component/test_egress_fw_rules.py", > line 51, in test_wrap_exception_log > raise e > Script result is ['bash: /tmp/expect_script.exp: /usr/bin/expect: bad > interpreter: No such file or directory'] is not matching with ['100'] > >> begin captured logging << > testclient.testcase.TestEgressFWRules: DEBUG: Creating network with network > offering: 0bd6212f-b34c-4f7a-a84f-0c172bee6ac8 > testclient.testcase.TestEgressFWRules: DEBUG: Created network with ID: > ef2626c2-6849-43e7-8418-0c89ed528d62 > testclient.testcase.TestEgressFWRules: DEBUG: Deploying instance in the > account: test-SSFX20 > testclient.testcase.TestEgressFWRules: DEBUG: Deployed instance in account: > test-SSFX20 > testclient.testcase.TestEgressFWRules: DEBUG: expect_script>> > #!/usr/bin/expect > spawn ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o > LogLevel=quiet -i /root/.ssh/id_rsa.cloud -p 3922 root@169.254.3.141 > expect "root@r-342-QA:~#" > send "ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o > LogLevel=quiet root@10.1.1.215 ping -c 1 www.google.com; exit $? > " > expect "root@10.1.1.215's password: " > send "password > " > interact >
[jira] [Resolved] (CLOUDSTACK-3806) OS Preference can not be set
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-3806. Resolution: Fixed It was setting OS preference correctly, The problem was in host_view. It was using the wrong id for join parameter. It was using host_details.id instead of host_details.host_id. Hence the parameter was not getting updated correctly in view. > OS Preference can not be set > > > Key: CLOUDSTACK-3806 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3806 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 > Environment: Typical instalation of CloudStack 4.1 >Reporter: Tomasz Zieba >Assignee: Anshul Gangwar > > You can not change OS Preference on Infrastructure-> Hosts -> Host . > After edit host and select OS-Preference - for example Windows and click > Apply You can see change. > But after refresh site OS Preference is back to None. -- 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-2808) Documentation on Assigning a VLAN ID to a network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13751006#comment-13751006 ] ASF subversion and git services commented on CLOUDSTACK-2808: - Commit 1f46bc3fb09aead2cf1744d358fea7adba7df6e1 in branch refs/heads/4.2-forward from [~radhikap] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1f46bc3 ] review comments for CLOUDSTACK-2808, CLOUDSTACK-769 > Documentation on Assigning a VLAN ID to a network > - > > Key: CLOUDSTACK-2808 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2808 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Reporter: Radhika Nair >Assignee: Radhika Nair > Fix For: 4.2.0 > > Attachments: Apache_CloudStack-4.2.0-Admin_Guide-en-US.pdf > > -- 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-769) Documentation for nTier Apps 2.0 : Internal LB
[ https://issues.apache.org/jira/browse/CLOUDSTACK-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13751007#comment-13751007 ] ASF subversion and git services commented on CLOUDSTACK-769: Commit 1f46bc3fb09aead2cf1744d358fea7adba7df6e1 in branch refs/heads/4.2-forward from [~radhikap] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1f46bc3 ] review comments for CLOUDSTACK-2808, CLOUDSTACK-769 > Documentation for nTier Apps 2.0 : Internal LB > --- > > Key: CLOUDSTACK-769 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-769 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Reporter: Radhika Nair >Assignee: Radhika Nair > Fix For: 4.2.0 > > Attachments: Apache_CloudStack-4.2.0-Admin_Guide-en-US.pdf > > > documentation for nTier Apps 2.0 : Internal LB > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Internal+Load+Balancing+between+VPC+tiers -- 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-4303) [Automation] test_egress_fw_rules test cases failed to except script and tests failed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13751005#comment-13751005 ] Ashutosk Kelkar commented on CLOUDSTACK-4303: - This is not an issue with the script. As per discussion I had with Jayapal, when egress policy is false public network should not be accessible from VM therefore script expects [100] i.e. 100% packet loss when it pings the public network. But it seems public network is accessible, returns [0] i.e. 0% packet loss. > [Automation] test_egress_fw_rules test cases failed to except script and > tests failed > -- > > Key: CLOUDSTACK-4303 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4303 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Infra >Reporter: Rayees Namathponnan >Assignee: Prasanna Santhanam >Priority: Critical > > Test cases from integration.component.test_egress_fw_rules.TestEgressFWRules > fails > test cases expecting script @ /tmp/expect_scrip, this should be handled in > test case, > Stacktrace > File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run > testMethod() > File > "/Repo_30X/ipcl/cloudstack/test/integration/component/test_egress_fw_rules.py", > line 51, in test_wrap_exception_log > raise e > Script result is ['bash: /tmp/expect_script.exp: /usr/bin/expect: bad > interpreter: No such file or directory'] is not matching with ['100'] > >> begin captured logging << > testclient.testcase.TestEgressFWRules: DEBUG: Creating network with network > offering: 0bd6212f-b34c-4f7a-a84f-0c172bee6ac8 > testclient.testcase.TestEgressFWRules: DEBUG: Created network with ID: > ef2626c2-6849-43e7-8418-0c89ed528d62 > testclient.testcase.TestEgressFWRules: DEBUG: Deploying instance in the > account: test-SSFX20 > testclient.testcase.TestEgressFWRules: DEBUG: Deployed instance in account: > test-SSFX20 > testclient.testcase.TestEgressFWRules: DEBUG: expect_script>> > #!/usr/bin/expect > spawn ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o > LogLevel=quiet -i /root/.ssh/id_rsa.cloud -p 3922 root@169.254.3.141 > expect "root@r-342-QA:~#" > send "ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o > LogLevel=quiet root@10.1.1.215 ping -c 1 www.google.com; exit $? > " > expect "root@10.1.1.215's password: " > send "password > " > interact >
[jira] [Commented] (CLOUDSTACK-3806) OS Preference can not be set
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13751004#comment-13751004 ] ASF subversion and git services commented on CLOUDSTACK-3806: - Commit bdbdfd401b0fcd40244e6aedf2ae853853e75e1a in branch refs/heads/master from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bdbdfd4 ] CLOUDSTACK-3806: There was error in host_view sql, it was using host_details.id for join instead host_details.host_id Signed-off-by: Sateesh Chodapuneedi > OS Preference can not be set > > > Key: CLOUDSTACK-3806 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3806 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.1.0 > Environment: Typical instalation of CloudStack 4.1 >Reporter: Tomasz Zieba >Assignee: Anshul Gangwar > > You can not change OS Preference on Infrastructure-> Hosts -> Host . > After edit host and select OS-Preference - for example Windows and click > Apply You can see change. > But after refresh site OS Preference is back to None. -- 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-4453) Routers test use VM credentials as host credentials
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam closed CLOUDSTACK-4453. -- http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-smoke-matrix/suite=test_routers/776/ > Routers test use VM credentials as host credentials > --- > > Key: CLOUDSTACK-4453 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4453 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Prasanna Santhanam >Assignee: Prasanna Santhanam >Priority: Critical > > In test_routers.py (in smoke and component) we do the following, > result = get_process_status( > host.ipaddress, > > self.services['virtual_machine']["publicport"], > self.vm_1.username, > self.vm_1.password, > router.linklocalip, > "service dnsmasq status" > ) > In this case : > host.ipaddress is the IP address of the XenServer host. > self.services['virtual_machine']["publicport"] is 22 (SSH port) > self.vm_1.username / password are the username and password of the VM > instance created for this test. > The call that fails in get_process_status is this: > ssh = remoteSSHClient(hostip, port, username, password) > In this case it seems the test is trying to create a SSH connection to the > XS host using the username / password of the VM instance (which will fail > because the XS host has a different password) -- 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-4453) Routers test use VM credentials as host credentials
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam resolved CLOUDSTACK-4453. Resolution: Fixed > Routers test use VM credentials as host credentials > --- > > Key: CLOUDSTACK-4453 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4453 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Prasanna Santhanam >Assignee: Prasanna Santhanam >Priority: Critical > > In test_routers.py (in smoke and component) we do the following, > result = get_process_status( > host.ipaddress, > > self.services['virtual_machine']["publicport"], > self.vm_1.username, > self.vm_1.password, > router.linklocalip, > "service dnsmasq status" > ) > In this case : > host.ipaddress is the IP address of the XenServer host. > self.services['virtual_machine']["publicport"] is 22 (SSH port) > self.vm_1.username / password are the username and password of the VM > instance created for this test. > The call that fails in get_process_status is this: > ssh = remoteSSHClient(hostip, port, username, password) > In this case it seems the test is trying to create a SSH connection to the > XS host using the username / password of the VM instance (which will fail > because the XS host has a different password) -- 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-4453) Routers test use VM credentials as host credentials
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam reassigned CLOUDSTACK-4453: -- Assignee: Prasanna Santhanam > Routers test use VM credentials as host credentials > --- > > Key: CLOUDSTACK-4453 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4453 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Prasanna Santhanam >Assignee: Prasanna Santhanam >Priority: Critical > > In test_routers.py (in smoke and component) we do the following, > result = get_process_status( > host.ipaddress, > > self.services['virtual_machine']["publicport"], > self.vm_1.username, > self.vm_1.password, > router.linklocalip, > "service dnsmasq status" > ) > In this case : > host.ipaddress is the IP address of the XenServer host. > self.services['virtual_machine']["publicport"] is 22 (SSH port) > self.vm_1.username / password are the username and password of the VM > instance created for this test. > The call that fails in get_process_status is this: > ssh = remoteSSHClient(hostip, port, username, password) > In this case it seems the test is trying to create a SSH connection to the > XS host using the username / password of the VM instance (which will fail > because the XS host has a different password) -- 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-2808) Documentation on Assigning a VLAN ID to a network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750995#comment-13750995 ] ASF subversion and git services commented on CLOUDSTACK-2808: - Commit 030fe5b6624bf4e22e02306cea0982c310566acf in branch refs/heads/master from [~radhikap] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=030fe5b ] review comments for CLOUDSTACK-2808, CLOUDSTACK-769 > Documentation on Assigning a VLAN ID to a network > - > > Key: CLOUDSTACK-2808 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2808 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Reporter: Radhika Nair >Assignee: Radhika Nair > Fix For: 4.2.0 > > Attachments: Apache_CloudStack-4.2.0-Admin_Guide-en-US.pdf > > -- 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-2808) Documentation on Assigning a VLAN ID to a network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750993#comment-13750993 ] ASF subversion and git services commented on CLOUDSTACK-2808: - Commit fe6e0390f87abd53fd35158584a9bb5bef789935 in branch refs/heads/master from [~radhikap] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fe6e039 ] review comments for CLOUDSTACK-2808, CLOUDSTACK-769 > Documentation on Assigning a VLAN ID to a network > - > > Key: CLOUDSTACK-2808 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2808 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Reporter: Radhika Nair >Assignee: Radhika Nair > Fix For: 4.2.0 > > Attachments: Apache_CloudStack-4.2.0-Admin_Guide-en-US.pdf > > -- 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-769) Documentation for nTier Apps 2.0 : Internal LB
[ https://issues.apache.org/jira/browse/CLOUDSTACK-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750996#comment-13750996 ] ASF subversion and git services commented on CLOUDSTACK-769: Commit 030fe5b6624bf4e22e02306cea0982c310566acf in branch refs/heads/master from [~radhikap] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=030fe5b ] review comments for CLOUDSTACK-2808, CLOUDSTACK-769 > Documentation for nTier Apps 2.0 : Internal LB > --- > > Key: CLOUDSTACK-769 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-769 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Reporter: Radhika Nair >Assignee: Radhika Nair > Fix For: 4.2.0 > > Attachments: Apache_CloudStack-4.2.0-Admin_Guide-en-US.pdf > > > documentation for nTier Apps 2.0 : Internal LB > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Internal+Load+Balancing+between+VPC+tiers -- 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-769) Documentation for nTier Apps 2.0 : Internal LB
[ https://issues.apache.org/jira/browse/CLOUDSTACK-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750994#comment-13750994 ] ASF subversion and git services commented on CLOUDSTACK-769: Commit fe6e0390f87abd53fd35158584a9bb5bef789935 in branch refs/heads/master from [~radhikap] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fe6e039 ] review comments for CLOUDSTACK-2808, CLOUDSTACK-769 > Documentation for nTier Apps 2.0 : Internal LB > --- > > Key: CLOUDSTACK-769 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-769 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Reporter: Radhika Nair >Assignee: Radhika Nair > Fix For: 4.2.0 > > Attachments: Apache_CloudStack-4.2.0-Admin_Guide-en-US.pdf > > > documentation for nTier Apps 2.0 : Internal LB > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Internal+Load+Balancing+between+VPC+tiers -- 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-4489) [object_store_refactor] First snapshot on disk after upgrade is not incremental if there was a snapshot taken before upgrade for the disk
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N reopened CLOUDSTACK-4489: --- Following are the reasons for reopening the bug: 1.We were tracking the snapshot on primary storage using path attribute in snapshots table. 2.Taking full snapshot after upgrade will consume lot of time and space which is not desired 3.AKAIK unless admin/user explicitly deletes the snapshot there is no way snapshot gets deleted from primary storage. > [object_store_refactor] First snapshot on disk after upgrade is not > incremental if there was a snapshot taken before upgrade for the disk > - > > Key: CLOUDSTACK-4489 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4489 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot, Storage Controller, XenServer >Affects Versions: 4.2.1 > Environment: Build is from commit > :a6bf80216466ada185de7e04d3e64be4e25c11a7 > Upgrade from 3.0.6 to 4.2 > Cluster: Xen >Reporter: Sanjeev N >Assignee: edison su >Priority: Critical > Fix For: 4.2.1 > > Attachments: cloud.dmp, management-server.log, > management-server.log.2013-08-23.gz > > > First snapshot on disk after upgrade is not incremental if there was a > snapshot taken before upgrade for the disk > Steps to reproduce: > === > 1.Install 3.0.6 and bring up CS with xen cluster > 2.Deploy guest vm with both root and data disk > 3.Create a snapshot on data disk > 4.Upgrade to 4.2 > 5.After upgrade again take snapshot on the same data disk > Result: > == > Snapshot created was full snapshot. > Observations: > === > In snapshot_store_ref table parent_snapshot_id was set to 0. Created another > snapshot on the same data disk for which parent_snapshot_id was set to the > snapshot_id taken after the upgrade. > mysql> select id,snapshot_id,volume_id,parent_snapshot_id,install_path from > snapshot_store_ref where volume_id=11 and store_role='Image'; > +-+-+---++-+ > | id | snapshot_id | volume_id | parent_snapshot_id | install_path > | > +-+-+---++-+ > | 1 | 1 |11 | 0 | > snapshots/2/11/eb957385-d67e-4338-8f24-831a392dba0e | > | 227 | 115 |11 | 0 | > snapshots/2/11/2900f706-c6b8-4ab0-ab5a-a3a4b40d709b | > | 229 | 116 |11 |115 | > snapshots/2/11/2900f706-c6b8-4ab0-ab5a-a3a4b40d709b | > +-+-+---++-+ > snapshot_id 1 was taken before upgrade, 115 and 116 were taken after upgrade. > For snapshot 115 parent_snapshot_id is 0 and snapshot size is same as > snapshot 1 i.e. it's a full snapshot. > 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] [Assigned] (CLOUDSTACK-4511) [Automation] Test case smoke.test_routers:TestRouterServices failed due attribute 'config' in KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prasanna Santhanam reassigned CLOUDSTACK-4511: -- Assignee: Rayees Namathponnan (was: Prasanna Santhanam) Can you add some more investigation on this? I'm unable to reproduce this. Ideally, the property self.config is not dependant on the hypervisor. > [Automation] Test case smoke.test_routers:TestRouterServices failed due > attribute 'config' in KVM > -- > > Key: CLOUDSTACK-4511 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4511 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Test >Reporter: Rayees Namathponnan >Assignee: Rayees Namathponnan > > Test case fails after the last two check-in 4.2-forward branch > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=history;f=test/integration/smoke/test_routers.py;h=02686664ded049473346b407a60609fb8d149dee;hb=refs/heads/4.2-forward > Test case failed with below error; issue observed in KVM env > 'TestRouterServices' object has no attribute 'config' > >> begin captured logging << > testclient.testcase.TestRouterServices: DEBUG: Restarting network with ID: > 0cdb5da4-7d9f-49f8-9e41-9fa7c8c1e94a, Network state: Implemented > - >> 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/smoke/test_routers.py", > line 488, in test_04_restart_network_wo_cleanup > host.user, host.passwd = get_host_credentials(self.config, host.ipaddress) > 'TestRouterServices' object has no attribute 'config' > >> begin captured logging << > testclient.testcase.TestRouterServices: DEBUG: Restarting network with ID: > 0cdb5da4-7d9f-49f8-9e41-9fa7c8c1e94a, Network state: Implemented > - >> 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] [Commented] (CLOUDSTACK-4513) [Vmware] new mapping vmware datacenter cloudstack zone - Host in second cluster in DC put in maintenance mode, CPVM and guest VMs that were migrated failed to com
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750982#comment-13750982 ] Animesh Chaturvedi commented on CLOUDSTACK-4513: Can you post the logs ASAP? > [Vmware] new mapping vmware datacenter cloudstack zone - Host in second > cluster in DC put in maintenance mode, CPVM and guest VMs that were migrated > failed to come up > --- > > Key: CLOUDSTACK-4513 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4513 > 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: MS10.223.195.52 build 479 > host ESXi 5.0 >Reporter: angeline shen >Priority: Critical > Fix For: 4.2.1 > > Attachments: Screenshot-CloudPlatform™ - Mozilla Firefox-1.png, > Screenshot-CloudPlatform™ - Mozilla Firefox.png > > > 1. > Vcenter CPP 4.2. > VC1 - DC1 - C1 - H1 zone1 - C1 - H1 10.223.51.2 > H2 H2 > 10.223.51.3 > PS2 cluster > primary storage > > C2 - H3C2 - H3 10.223.51.4 > PS3 cluster > primary storage > PS1 zone > primary storage > PSZ4 zone > primary storage > 2. H310.223.51.4 has SSVM CPVM and VMs i-2-8i-2-6 > VRs and other guest VMs were on Hosts H1 and H3 > 3. Put H3 in maintenance mode. > Result: > VMs i-2-6-VM and i-2-8-VM went into STOP state. Try to start both VMs. > These remain in > 'Starting' state . > New SSVM s-14-VM created.. Old SSVM s-10-VM remained in expunging and > disconnected state > CPVM v-11-VM remain in STOP and disconnected state. Cannot be started > -- 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-4503) hitting java npe in snapshot creation after upgrade from 3.0.4 to 4.2
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhinandan Prateek reassigned CLOUDSTACK-4503:
--
Assignee: edison su (was: Nitin Mehta)
> hitting java npe in snapshot creation after upgrade from 3.0.4 to 4.2
> -
>
> Key: CLOUDSTACK-4503
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4503
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Snapshot, Upgrade, XenServer
>Affects Versions: 4.2.1
> Environment: upgraded from 3.0.4 to 4.2 with one xen 6.0.2 host
>Reporter: shweta agarwal
>Assignee: edison su
>Priority: Blocker
> Fix For: 4.2.1
>
> Attachments: freshsetup_Logs_DB.rar, snapshot.tar.gz
>
>
> creating snapshot is failing with exception :
> 2013-08-26 06:44:05,729 DEBUG [agent.transport.Request]
> (Job-Executor-6:job-206 = [ 2e2ffe00-c590-41ef-a63e-7dac6046e53c ]) Seq
> 1-519045381: Received: { Ans: , MgmtId: 6819569205345, via: 1, Ver: v1,
> Flags: 10, { CopyCmdAnswer } }
> 2013-08-26 06:44:05,749 DEBUG [storage.snapshot.SnapshotServiceImpl]
> (Job-Executor-6:job-206 = [ 2e2ffe00-c590-41ef-a63e-7dac6046e53c ]) Failed to
> update snapshot state
> java.lang.NullPointerException
> at
> org.apache.cloudstack.storage.snapshot.SnapshotObject.processEvent(SnapshotObject.java:268)
> at
> org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.copySnapshotAsyncCallback(SnapshotServiceImpl.java:316)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.dispatch(AsyncCallbackDispatcher.java:142)
> at
> org.apache.cloudstack.framework.async.InplaceAsyncCallbackDriver.performCompletionCallback(InplaceAsyncCallbackDriver.java:26)
> at
> org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.complete(AsyncCallbackDispatcher.java:120)
> at
> org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:423)
> at
> org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:55)
> at
> org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:266)
> at
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:138)
> at
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:264)
> at
> com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:1013)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1281)
> at
> com.cloud.storage.VolumeManagerImpl.takeSnapshot(VolumeManagerImpl.java:2703)
> at
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd.execute(CreateSnapshotCmd.java:170)
> 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-26 06:44:05,753 DEBUG [storage.snapshot.SnapshotManagerImpl]
> (Job-Executor-6:job-206 = [ 2e2ffe00-c590-41ef-a63e-7dac6046e53c ]) Failed to
> create snapshot
> com.cloud.utils.exception.CloudRuntimeException:
> java.lang.NullPointerException
> at
> org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:281)
> at
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:138)
> at
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:264)
> a
[jira] [Updated] (CLOUDSTACK-1593) Document syslog enhancements
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-1593: - Assignee: sadhu suresh (was: Sudha Ponnaganti) > Document syslog enhancements > > > Key: CLOUDSTACK-1593 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1593 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.2.0 >Reporter: Jessica Tomechak >Assignee: sadhu suresh >Priority: Minor > Fix For: 4.2.0 > > > The feature can be enabled or disabled. Need to document this configuration > setting, and tell which is the default: disabled. -- 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-864) Document Zone-wide primary storage target
[ https://issues.apache.org/jira/browse/CLOUDSTACK-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-864: Assignee: Srikanteswararao Talluri (was: Sudha Ponnaganti) > Document Zone-wide primary storage target > - > > Key: CLOUDSTACK-864 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-864 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Reporter: Radhika Nair >Assignee: Srikanteswararao Talluri > Fix For: 4.2.0 > > > Document Zone-wide primary storage target -- 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-3390) Documentation for Mapping CloudStack Zone and VMWare Datacenter
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-3390: - Assignee: angeline shen (was: Sudha Ponnaganti) > Documentation for Mapping CloudStack Zone and VMWare Datacenter > --- > > Key: CLOUDSTACK-3390 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3390 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc, VMware >Reporter: Radhika Nair >Assignee: angeline shen > Fix For: 4.2.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] [Commented] (CLOUDSTACK-4510) Move Netscaler related tests to appropriate test suites
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750973#comment-13750973 ] ASF subversion and git services commented on CLOUDSTACK-4510: - Commit f1c6535f6ee0e5f9b4e6a3435ad2c1dd322a8074 in branch refs/heads/master from [~sowmyak] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f1c6535 ] CLOUDSTACK-4510 Move NS scripts to appropriate suites and related common.py fixes Signed-off-by: Prasanna Santhanam (cherry picked from commit f7df3ef9f1d6127d5438e58af7dccfbd1f58461c) > Move Netscaler related tests to appropriate test suites > --- > > Key: CLOUDSTACK-4510 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4510 > 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: Marvin >Reporter: Sowmya Krishnan >Assignee: Sowmya Krishnan > Fix For: 4.2.1 > > > Move netscaler scripts to appropriate test suites so that they are separated > out and easy to handle. > For ex: There are few NS tests in test_network_off.py like TestNwOffNetscaler > which can be moved to test_netscaler_nw_off where its more relevant. -- 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-4510) Move Netscaler related tests to appropriate test suites
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750974#comment-13750974 ] ASF subversion and git services commented on CLOUDSTACK-4510: - Commit f7df3ef9f1d6127d5438e58af7dccfbd1f58461c in branch refs/heads/4.2-forward from [~sowmyak] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f7df3ef ] CLOUDSTACK-4510 Move NS scripts to appropriate suites and related common.py fixes Signed-off-by: Prasanna Santhanam > Move Netscaler related tests to appropriate test suites > --- > > Key: CLOUDSTACK-4510 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4510 > 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: Marvin >Reporter: Sowmya Krishnan >Assignee: Sowmya Krishnan > Fix For: 4.2.1 > > > Move netscaler scripts to appropriate test suites so that they are separated > out and easy to handle. > For ex: There are few NS tests in test_network_off.py like TestNwOffNetscaler > which can be moved to test_netscaler_nw_off where its more relevant. -- 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-4503) hitting java npe in snapshot creation after upgrade from 3.0.4 to 4.2
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750972#comment-13750972
]
prashant kumar mishra commented on CLOUDSTACK-4503:
---
commit 81d489dc9439ec039175b86922a74ea692e6fb6b
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=81d489dc9439ec039175b86922a74ea692e6fb6b
> hitting java npe in snapshot creation after upgrade from 3.0.4 to 4.2
> -
>
> Key: CLOUDSTACK-4503
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4503
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Snapshot, Upgrade, XenServer
>Affects Versions: 4.2.1
> Environment: upgraded from 3.0.4 to 4.2 with one xen 6.0.2 host
>Reporter: shweta agarwal
>Assignee: Nitin Mehta
>Priority: Blocker
> Fix For: 4.2.1
>
> Attachments: freshsetup_Logs_DB.rar, snapshot.tar.gz
>
>
> creating snapshot is failing with exception :
> 2013-08-26 06:44:05,729 DEBUG [agent.transport.Request]
> (Job-Executor-6:job-206 = [ 2e2ffe00-c590-41ef-a63e-7dac6046e53c ]) Seq
> 1-519045381: Received: { Ans: , MgmtId: 6819569205345, via: 1, Ver: v1,
> Flags: 10, { CopyCmdAnswer } }
> 2013-08-26 06:44:05,749 DEBUG [storage.snapshot.SnapshotServiceImpl]
> (Job-Executor-6:job-206 = [ 2e2ffe00-c590-41ef-a63e-7dac6046e53c ]) Failed to
> update snapshot state
> java.lang.NullPointerException
> at
> org.apache.cloudstack.storage.snapshot.SnapshotObject.processEvent(SnapshotObject.java:268)
> at
> org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.copySnapshotAsyncCallback(SnapshotServiceImpl.java:316)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.dispatch(AsyncCallbackDispatcher.java:142)
> at
> org.apache.cloudstack.framework.async.InplaceAsyncCallbackDriver.performCompletionCallback(InplaceAsyncCallbackDriver.java:26)
> at
> org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.complete(AsyncCallbackDispatcher.java:120)
> at
> org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:423)
> at
> org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:55)
> at
> org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:266)
> at
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:138)
> at
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:264)
> at
> com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:1013)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1281)
> at
> com.cloud.storage.VolumeManagerImpl.takeSnapshot(VolumeManagerImpl.java:2703)
> at
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd.execute(CreateSnapshotCmd.java:170)
> 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-26 06:44:05,753 DEBUG [storage.snapshot.SnapshotManagerImpl]
> (Job-Executor-6:job-206 = [ 2e2ffe00-c590-41ef-a63e-7dac6046e53c ]) Failed to
> create snapshot
> com.cloud.utils.exception.CloudRuntimeException:
> java.lang.NullPointerException
> at
> org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:281)
> at
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupS
[jira] [Updated] (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 ] Animesh Chaturvedi updated CLOUDSTACK-4471: --- Summary: [Vmware] Error Instances leaving ROOT Volumes in expunging state and not getting updated as removed evenafter having the instances expunged (was: Error Instances leaving ROOT Volumes in expunging state and not getting updated as removed evenafter having the instances expunged) > [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 >Affects Versions: 4.2.1 >Reporter: Sailaja Mada >Assignee: edison su >Priority: Critical > Fix For: 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-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 ] Animesh Chaturvedi updated CLOUDSTACK-4471: --- Component/s: VMware > [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: edison su >Priority: Critical > Fix For: 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] [Reopened] (CLOUDSTACK-4504) VM creation ISD fainling using the Ubuntu ISO.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanjeev N reopened CLOUDSTACK-4504:
---
Observed with xen6.1 and 6.2
> VM creation ISD fainling using the Ubuntu ISO.
> --
>
> Key: CLOUDSTACK-4504
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4504
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Install and Setup
>Affects Versions: 4.2.1
>Reporter: Kiran Koneti
>Priority: Blocker
> Fix For: 4.2.1
>
> Attachments: management-server.zip
>
>
> 1)Registered a Ubuntu 10.04 32 bit in the CS.
> 2)Tried to create a VM using the ISO then observed the below error message
> "2013-08-26 21:28:58,345 DEBUG [agent.transport.Request]
> (AgentManager-Handler-14:null) Seq 3-347996257: Processing: { Ans: , MgmtId:
> 6703101771911, via: 3, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.storage.DownloadAnswer":{"jobId":"565318cc-d0b4-4365-aea2-044dedb938ea","downloadPct":100,"errorString":"Download
> success, starting install
> ","downloadStatus":"DOWNLOAD_IN_PROGRESS","downloadPath":"/mnt/SecStorage/ec67adf1-b86c-3674-ad7f-46ddd34d104f/template/tmpl/2/202/dnld2917500853441314915tmp_","installPath":"template/tmpl/2/202/202-2-c006beb1-8a48-3ac2-b4d5-af1b6c940b5e.iso","templateSize":0,"templatePhySicalSize":0,"checkSum":"27aa354b8088527ffcd32007b51b25bf","result":true,"details":"Download
> success, starting install ","wait":0}}] }
> 2013-08-26 21:29:00,477 DEBUG [cloud.server.StatsCollector]
> (StatsCollector-1:null) StorageCollector is running...
> ^C
> [root@Kiran-RHEl631 setup]# vi
> /var/log/cloudstack/management/management-server.log
> status: failure
> residentOn: com.xensource.xenapi.Host@e79e523d
> progress: 1.0
> type:
> result:
>errorInfo: [INTERNAL_ERROR, xenopsd internal error:
> XenguestHelper.Xenctrl_dom_linux_build_failure(2, " elf_xen_note_check:
> ERROR: Will only load images built \\\"")]
> otherConfig: {}
>subtaskOf: com.xensource.xenapi.Task@aaf13f6f
> subtasks: []
> com.cloud.utils.exception.CloudRuntimeException: Unable to start VM(i-2-3-VM)
> on host(fe1fce23-4155-4831-b669-a99988cd3259) due to Task failed! Task
> record: uuid: d7d77fe7-2d04-35a2-df1f-200ca1a80bbc
>nameLabel: Async.VM.start_on
> nameDescription:
>allowedOperations: []
>currentOperations: {}
> created: Mon Aug 26 12:06:14 IST 2013
> finished: Mon Aug 26 12:06:17 IST 2013
> status: failure
> residentOn: com.xensource.xenapi.Host@e79e523d
> progress: 1.0
> type:
> result:
>errorInfo: [INTERNAL_ERROR, xenopsd internal error:
> XenguestHelper.Xenctrl_dom_linux_build_failure(2, " elf_xen_note_check:
> ERROR: Will only load images built \\\"")]
> otherConfig: {}
>subtaskOf: com.xensource.xenapi.Task@aaf13f6f
> subtasks: []
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.startVM(CitrixResourceBase.java:3717)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1636)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:553)
> at
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:73)
> at
> com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:104)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)"
> Atatching the MS logs for additional debugging.
> The DB table entries for the Ubuntu templates for the Xen are as below:
> mysql> select * from guest_os_hypervisor where guest_os_id in (select id from
> guest_os where display_name like '%ubu%');
> +-+-+-+-+
> | id | hypervisor_type | guest_os_name | guest_os_id |
> +-+-+-+-+
> | 79 | XenServer | Other install media | 59 |
> | 80 | XenServer | Other install media | 100 |
> | 83 | XenServer | Other install media | 121 |
> | 84 | XenServer | Other install media | 126 |
> | 85 | XenServer | Other install media | 122 |
> | 86 | XenServer | Other install media | 127 |
> | 87 | XenServer | Other
[jira] [Commented] (CLOUDSTACK-4503) hitting java npe in snapshot creation after upgrade from 3.0.4 to 4.2
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750968#comment-13750968
]
Nitin Mehta commented on CLOUDSTACK-4503:
-
Can you provide the commit at which this build is taken ?
> hitting java npe in snapshot creation after upgrade from 3.0.4 to 4.2
> -
>
> Key: CLOUDSTACK-4503
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4503
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Snapshot, Upgrade, XenServer
>Affects Versions: 4.2.1
> Environment: upgraded from 3.0.4 to 4.2 with one xen 6.0.2 host
>Reporter: shweta agarwal
>Assignee: Nitin Mehta
>Priority: Blocker
> Fix For: 4.2.1
>
> Attachments: freshsetup_Logs_DB.rar, snapshot.tar.gz
>
>
> creating snapshot is failing with exception :
> 2013-08-26 06:44:05,729 DEBUG [agent.transport.Request]
> (Job-Executor-6:job-206 = [ 2e2ffe00-c590-41ef-a63e-7dac6046e53c ]) Seq
> 1-519045381: Received: { Ans: , MgmtId: 6819569205345, via: 1, Ver: v1,
> Flags: 10, { CopyCmdAnswer } }
> 2013-08-26 06:44:05,749 DEBUG [storage.snapshot.SnapshotServiceImpl]
> (Job-Executor-6:job-206 = [ 2e2ffe00-c590-41ef-a63e-7dac6046e53c ]) Failed to
> update snapshot state
> java.lang.NullPointerException
> at
> org.apache.cloudstack.storage.snapshot.SnapshotObject.processEvent(SnapshotObject.java:268)
> at
> org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.copySnapshotAsyncCallback(SnapshotServiceImpl.java:316)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.dispatch(AsyncCallbackDispatcher.java:142)
> at
> org.apache.cloudstack.framework.async.InplaceAsyncCallbackDriver.performCompletionCallback(InplaceAsyncCallbackDriver.java:26)
> at
> org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.complete(AsyncCallbackDispatcher.java:120)
> at
> org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:423)
> at
> org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:55)
> at
> org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:266)
> at
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:138)
> at
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:264)
> at
> com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:1013)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1281)
> at
> com.cloud.storage.VolumeManagerImpl.takeSnapshot(VolumeManagerImpl.java:2703)
> at
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd.execute(CreateSnapshotCmd.java:170)
> 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-26 06:44:05,753 DEBUG [storage.snapshot.SnapshotManagerImpl]
> (Job-Executor-6:job-206 = [ 2e2ffe00-c590-41ef-a63e-7dac6046e53c ]) Failed to
> create snapshot
> com.cloud.utils.exception.CloudRuntimeException:
> java.lang.NullPointerException
> at
> org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:281)
> at
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:138)
> at
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStra
[jira] [Resolved] (CLOUDSTACK-4495) systemVM template URL is pointing to old template location in upgrade file
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi resolved CLOUDSTACK-4495. Resolution: Fixed > systemVM template URL is pointing to old template location in upgrade file > -- > > Key: CLOUDSTACK-4495 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4495 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.2.0 >Reporter: Sanjay Tripathi >Assignee: Sanjay Tripathi >Priority: Critical > Fix For: 4.2.1 > > > SystemVM template URL for XenServer hypervisor is pointing to old template > location in the Upgrade410to420.java file. -- 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-4509) [upgrade][CS 4.1 to CS 4.2] Not able to see the UI after upgrade from CS 4.1 to CS 4.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-4509: Assignee: Rayees Namathponnan > [upgrade][CS 4.1 to CS 4.2] Not able to see the UI after upgrade from CS 4.1 > to CS 4.2 > -- > > Key: CLOUDSTACK-4509 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4509 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup, Management Server, UI >Affects Versions: 4.2.0 >Reporter: Abhinav Roy >Assignee: Rayees Namathponnan >Priority: Blocker > Fix For: 4.2.1 > > Attachments: CS41-CS42_UI.jpg, CS-4509.zip > > > Steps: > > 1. Deploy CS 4.1 advanced zone with XEN. > 2. Create VMs. > 3. Upgrade to 4.2 > Expected behaviour : > > The db upgrade should be successful, UI should be available and system vms > should come up > Observed behaviour : > == > The db upgrade is successful and system vms come up but no UI is seen at all. > I am able to fire the APIs and they are working fine. There is no error with > respect to that in the logs also. > I have restarted the management server several times but that also doesn't > help. > Attaching snapshot with firebug logs -- 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-4482) getVMPassword() API call does not retuen password for Vms that are deployed with password enabled templates.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750962#comment-13750962
]
Harikrishna Patnala commented on CLOUDSTACK-4482:
-
This is expected behavior.
We save the encrypted password only if the VM got assigned with a SSH public
key.
The password is encrypted with ssh public key and stored in the DB. When
getVMPassword API is called it gets the encrypted password and user needs to
decrypt that with ssh private key.
We may need to improve the error message in this case.
> getVMPassword() API call does not retuen password for Vms that are deployed
> with password enabled templates.
>
>
> Key: CLOUDSTACK-4482
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4482
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
>Reporter: Sangeetha Hariharan
>Assignee: Harikrishna Patnala
> Fix For: 4.2.1
>
>
> Steps to reproduce the problem:
> Provision a VM with password enabled templates.
> Use getVMPassword() to get the password for this use VM.
> We get the following error message - "No password for VM with specified id
> found"
> http://10.223.131.169:8080/client/api?command=getVMPassword&id=a974c8ab-e779-4de6-a1d1-26ac5c9c39cd&response=json&sessionkey=ciq%2FaAgf6%2Br1BiuGeyU2%2Fjic23s%3D&_=1377293331315
> { "getvmpasswordresponse" :
> {"uuidList":[{"uuid":"a974c8ab-e779-4de6-a1d1-26ac5c9c39cd","description":"vmId"}],"errorcode":431,"cserrorcode":4350,"errortext":"No
> password for VM with specified id found."} }
> Management server logs:
> 2013-08-23 14:18:03,240 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null)
> ===START=== 10.215.3.9 -- GET
> command=getVMPassword&id=a974c8ab-e779-4de6-a1d1-26ac5c9c39cd&response=json&sessionkey=ciq%2FaAgf6%2Br1BiuGeyU2%2Fjic23s%3D&_=1377293331315
> 2013-08-23 14:18:03,251 DEBUG [cloud.user.AccountManagerImpl]
> (catalina-exec-25:null) Access to VM[User|pass-2] granted to
> Acct[806a5eea-3861-4224-bfc4-59f0fc46a1af-tan] by
> DomainChecker_EnhancerByCloudStack_be12c9e3
> 2013-08-23 14:18:03,253 INFO [cloud.api.ApiServer] (catalina-exec-25:null)
> No password for VM with specified id found.
> 2013-08-23 14:18:03,253 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null)
> ===END=== 10.215.3.9 -- GET
> command=getVMPassword&id=a974c8ab-e779-4de6-a1d1-26ac5c9c39cd&response=json&sessionkey=ciq%2FaAgf6%2Br1BiuGeyU2%2Fjic23s%3D&_=1377293331315
> Response when deploying the Vm has password field which I am able to use
> successfully to log into the Vm:
> |
> org.apache.cloudstack.api.response.UserVmResponse/virtualmachine/{"id":"a974c8ab-e779-4de6-a1d1-26ac5c9c39cd","name":"pass-2","displayname":"pass-2","account":"tan","domainid":"1e424c36-0b6e-11e3-bc0b-06715428","domain":"ROOT","created":"2013-08-23T11:17:08-0700","state":"Running","haenable":false,"zoneid":"93368e7c-db1b-4344-8777-2a6e0507c2ba","zonename":"zone1","templateid":"dd5c6bb5-602a-4cc4-9328-a26096294cf7","templatename":"password-template","templatedisplaytext":"password-template","passwordenabled":true,"serviceofferingid":"e83c2f9a-cbdc-46dc-8743-c76f3c270e99","serviceofferingname":"tiny1","cpunumber":1,"cpuspeed":50,"memory":124,"guestosid":"1e4bb9ce-0b6e-11e3-bc0b-06715428","rootdeviceid":0,"rootdevicetype":"ROOT","securitygroup":[],"password":"rJ3aivjax","nic":[{"id":"e9ed3363-1573-4f59-b2cb-a32c8a3c023d","networkid":"95528f66-22f8-4932-86b6-96b1183d5693","networkname":"tan","netmask":"255.255.255.0","gateway":"10.1.1.1","ipaddress":"10.1.1.149","isolationuri":"vlan://2309","broadcasturi":"vlan://2309","traffictype":"Guest","type":"Isolated","isdefault":true,"macaddress":"02:00:4e:ad:00:28"}],"hypervisor":"VMware","tags":[],"affinitygroup":[],"displayvm":true,"isdynamicallyscalable":false,"jobid":"850e7775-be7a-4216-b515-dcfc320b2260","jobstatus":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] [Resolved] (CLOUDSTACK-4501) system vm not coming up in vmware ESX4.1 after upgrade from 3.0.4 to 4.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-4501. -- Resolution: Invalid > system vm not coming up in vmware ESX4.1 after upgrade from 3.0.4 to 4.2 > > > Key: CLOUDSTACK-4501 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4501 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade, VMware >Affects Versions: 4.2.1 > Environment: upgrade from 3.0.4 patch 1 to 4.2 > with vmware EXI 4.1 >Reporter: shweta agarwal >Assignee: Min Chen >Priority: Blocker > Fix For: 4.2.1 > > Attachments: cloud-after-upgrade.dmp, cloud.dmp, > management-server.log.tar.gz > > > did an upgrade from 3.0.4 patch 1to 4.2 with two advance zone one vmware4.2 > and one xen 6.0.2 > Now after upgrade system vm for vmware not coming up . hitting exception : > 013-08-26 05:36:05,392 ERROR [storage.resource.VmwareStorageProcessor] > (DirectAgent-15:10.147.40.27) Unable to copy template to primary storage due > to exception:Exception: javax.xml.ws.soap.SOAPFaultException > Message: > Required parameter spec is missing > while parsing call information for method ImportVApp > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method importVApp > on object of type vim.ResourcePool > at line 1, column 0 > javax.xml.ws.soap.SOAPFaultException: > Required parameter spec is missing > while parsing call information for method ImportVApp > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method importVApp > on object of type vim.ResourcePool > at line 1, column 0 > at > com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) > at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107) > at sun.proxy.$Proxy91.importVApp(Unknown Source) > at > com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.importVmFromOVF(HypervisorHostHelper.java:1321) > at > com.cloud.hypervisor.vmware.mo.HostMO.importVmFromOVF(HostMO.java:736) -- 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-4501) system vm not coming up in vmware ESX4.1 after upgrade from 3.0.4 to 4.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750948#comment-13750948 ] Min Chen commented on CLOUDSTACK-4501: -- Thanks Chandan for the clarification. shweta, can you please try with correct system vm template? > system vm not coming up in vmware ESX4.1 after upgrade from 3.0.4 to 4.2 > > > Key: CLOUDSTACK-4501 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4501 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade, VMware >Affects Versions: 4.2.1 > Environment: upgrade from 3.0.4 patch 1 to 4.2 > with vmware EXI 4.1 >Reporter: shweta agarwal >Assignee: Min Chen >Priority: Blocker > Fix For: 4.2.1 > > Attachments: cloud-after-upgrade.dmp, cloud.dmp, > management-server.log.tar.gz > > > did an upgrade from 3.0.4 patch 1to 4.2 with two advance zone one vmware4.2 > and one xen 6.0.2 > Now after upgrade system vm for vmware not coming up . hitting exception : > 013-08-26 05:36:05,392 ERROR [storage.resource.VmwareStorageProcessor] > (DirectAgent-15:10.147.40.27) Unable to copy template to primary storage due > to exception:Exception: javax.xml.ws.soap.SOAPFaultException > Message: > Required parameter spec is missing > while parsing call information for method ImportVApp > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method importVApp > on object of type vim.ResourcePool > at line 1, column 0 > javax.xml.ws.soap.SOAPFaultException: > Required parameter spec is missing > while parsing call information for method ImportVApp > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method importVApp > on object of type vim.ResourcePool > at line 1, column 0 > at > com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) > at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107) > at sun.proxy.$Proxy91.importVApp(Unknown Source) > at > com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.importVmFromOVF(HypervisorHostHelper.java:1321) > at > com.cloud.hypervisor.vmware.mo.HostMO.importVmFromOVF(HostMO.java:736) -- 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-4501) system vm not coming up in vmware ESX4.1 after upgrade from 3.0.4 to 4.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750949#comment-13750949 ] Min Chen commented on CLOUDSTACK-4501: -- Mark it as invalid due to wrong system vm template is used. > system vm not coming up in vmware ESX4.1 after upgrade from 3.0.4 to 4.2 > > > Key: CLOUDSTACK-4501 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4501 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade, VMware >Affects Versions: 4.2.1 > Environment: upgrade from 3.0.4 patch 1 to 4.2 > with vmware EXI 4.1 >Reporter: shweta agarwal >Assignee: Min Chen >Priority: Blocker > Fix For: 4.2.1 > > Attachments: cloud-after-upgrade.dmp, cloud.dmp, > management-server.log.tar.gz > > > did an upgrade from 3.0.4 patch 1to 4.2 with two advance zone one vmware4.2 > and one xen 6.0.2 > Now after upgrade system vm for vmware not coming up . hitting exception : > 013-08-26 05:36:05,392 ERROR [storage.resource.VmwareStorageProcessor] > (DirectAgent-15:10.147.40.27) Unable to copy template to primary storage due > to exception:Exception: javax.xml.ws.soap.SOAPFaultException > Message: > Required parameter spec is missing > while parsing call information for method ImportVApp > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method importVApp > on object of type vim.ResourcePool > at line 1, column 0 > javax.xml.ws.soap.SOAPFaultException: > Required parameter spec is missing > while parsing call information for method ImportVApp > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method importVApp > on object of type vim.ResourcePool > at line 1, column 0 > at > com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) > at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107) > at sun.proxy.$Proxy91.importVApp(Unknown Source) > at > com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.importVmFromOVF(HypervisorHostHelper.java:1321) > at > com.cloud.hypervisor.vmware.mo.HostMO.importVmFromOVF(HostMO.java:736) -- 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-4482) getVMPassword() API call does not retuen password for Vms that are deployed with password enabled templates.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhinandan Prateek reassigned CLOUDSTACK-4482:
--
Assignee: Harikrishna Patnala
> getVMPassword() API call does not retuen password for Vms that are deployed
> with password enabled templates.
>
>
> Key: CLOUDSTACK-4482
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4482
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
>Reporter: Sangeetha Hariharan
>Assignee: Harikrishna Patnala
> Fix For: 4.2.1
>
>
> Steps to reproduce the problem:
> Provision a VM with password enabled templates.
> Use getVMPassword() to get the password for this use VM.
> We get the following error message - "No password for VM with specified id
> found"
> http://10.223.131.169:8080/client/api?command=getVMPassword&id=a974c8ab-e779-4de6-a1d1-26ac5c9c39cd&response=json&sessionkey=ciq%2FaAgf6%2Br1BiuGeyU2%2Fjic23s%3D&_=1377293331315
> { "getvmpasswordresponse" :
> {"uuidList":[{"uuid":"a974c8ab-e779-4de6-a1d1-26ac5c9c39cd","description":"vmId"}],"errorcode":431,"cserrorcode":4350,"errortext":"No
> password for VM with specified id found."} }
> Management server logs:
> 2013-08-23 14:18:03,240 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null)
> ===START=== 10.215.3.9 -- GET
> command=getVMPassword&id=a974c8ab-e779-4de6-a1d1-26ac5c9c39cd&response=json&sessionkey=ciq%2FaAgf6%2Br1BiuGeyU2%2Fjic23s%3D&_=1377293331315
> 2013-08-23 14:18:03,251 DEBUG [cloud.user.AccountManagerImpl]
> (catalina-exec-25:null) Access to VM[User|pass-2] granted to
> Acct[806a5eea-3861-4224-bfc4-59f0fc46a1af-tan] by
> DomainChecker_EnhancerByCloudStack_be12c9e3
> 2013-08-23 14:18:03,253 INFO [cloud.api.ApiServer] (catalina-exec-25:null)
> No password for VM with specified id found.
> 2013-08-23 14:18:03,253 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null)
> ===END=== 10.215.3.9 -- GET
> command=getVMPassword&id=a974c8ab-e779-4de6-a1d1-26ac5c9c39cd&response=json&sessionkey=ciq%2FaAgf6%2Br1BiuGeyU2%2Fjic23s%3D&_=1377293331315
> Response when deploying the Vm has password field which I am able to use
> successfully to log into the Vm:
> |
> org.apache.cloudstack.api.response.UserVmResponse/virtualmachine/{"id":"a974c8ab-e779-4de6-a1d1-26ac5c9c39cd","name":"pass-2","displayname":"pass-2","account":"tan","domainid":"1e424c36-0b6e-11e3-bc0b-06715428","domain":"ROOT","created":"2013-08-23T11:17:08-0700","state":"Running","haenable":false,"zoneid":"93368e7c-db1b-4344-8777-2a6e0507c2ba","zonename":"zone1","templateid":"dd5c6bb5-602a-4cc4-9328-a26096294cf7","templatename":"password-template","templatedisplaytext":"password-template","passwordenabled":true,"serviceofferingid":"e83c2f9a-cbdc-46dc-8743-c76f3c270e99","serviceofferingname":"tiny1","cpunumber":1,"cpuspeed":50,"memory":124,"guestosid":"1e4bb9ce-0b6e-11e3-bc0b-06715428","rootdeviceid":0,"rootdevicetype":"ROOT","securitygroup":[],"password":"rJ3aivjax","nic":[{"id":"e9ed3363-1573-4f59-b2cb-a32c8a3c023d","networkid":"95528f66-22f8-4932-86b6-96b1183d5693","networkname":"tan","netmask":"255.255.255.0","gateway":"10.1.1.1","ipaddress":"10.1.1.149","isolationuri":"vlan://2309","broadcasturi":"vlan://2309","traffictype":"Guest","type":"Isolated","isdefault":true,"macaddress":"02:00:4e:ad:00:28"}],"hypervisor":"VMware","tags":[],"affinitygroup":[],"displayvm":true,"isdynamicallyscalable":false,"jobid":"850e7775-be7a-4216-b515-dcfc320b2260","jobstatus":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] [Assigned] (CLOUDSTACK-4503) hitting java npe in snapshot creation after upgrade from 3.0.4 to 4.2
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhinandan Prateek reassigned CLOUDSTACK-4503:
--
Assignee: Nitin Mehta
> hitting java npe in snapshot creation after upgrade from 3.0.4 to 4.2
> -
>
> Key: CLOUDSTACK-4503
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4503
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Snapshot, Upgrade, XenServer
>Affects Versions: 4.2.1
> Environment: upgraded from 3.0.4 to 4.2 with one xen 6.0.2 host
>Reporter: shweta agarwal
>Assignee: Nitin Mehta
>Priority: Blocker
> Fix For: 4.2.1
>
> Attachments: freshsetup_Logs_DB.rar, snapshot.tar.gz
>
>
> creating snapshot is failing with exception :
> 2013-08-26 06:44:05,729 DEBUG [agent.transport.Request]
> (Job-Executor-6:job-206 = [ 2e2ffe00-c590-41ef-a63e-7dac6046e53c ]) Seq
> 1-519045381: Received: { Ans: , MgmtId: 6819569205345, via: 1, Ver: v1,
> Flags: 10, { CopyCmdAnswer } }
> 2013-08-26 06:44:05,749 DEBUG [storage.snapshot.SnapshotServiceImpl]
> (Job-Executor-6:job-206 = [ 2e2ffe00-c590-41ef-a63e-7dac6046e53c ]) Failed to
> update snapshot state
> java.lang.NullPointerException
> at
> org.apache.cloudstack.storage.snapshot.SnapshotObject.processEvent(SnapshotObject.java:268)
> at
> org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.copySnapshotAsyncCallback(SnapshotServiceImpl.java:316)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.dispatch(AsyncCallbackDispatcher.java:142)
> at
> org.apache.cloudstack.framework.async.InplaceAsyncCallbackDriver.performCompletionCallback(InplaceAsyncCallbackDriver.java:26)
> at
> org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.complete(AsyncCallbackDispatcher.java:120)
> at
> org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:423)
> at
> org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:55)
> at
> org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:266)
> at
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:138)
> at
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:264)
> at
> com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:1013)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1281)
> at
> com.cloud.storage.VolumeManagerImpl.takeSnapshot(VolumeManagerImpl.java:2703)
> at
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd.execute(CreateSnapshotCmd.java:170)
> 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-26 06:44:05,753 DEBUG [storage.snapshot.SnapshotManagerImpl]
> (Job-Executor-6:job-206 = [ 2e2ffe00-c590-41ef-a63e-7dac6046e53c ]) Failed to
> create snapshot
> com.cloud.utils.exception.CloudRuntimeException:
> java.lang.NullPointerException
> at
> org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:281)
> at
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:138)
> at
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:264)
> at
> com.cloud.s
[jira] [Updated] (CLOUDSTACK-4513) [Vmware] new mapping vmware datacenter cloudstack zone - Host in second cluster in DC put in maintenance mode, CPVM and guest VMs that were migrated failed to come
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-4513: - Fix Version/s: (was: 4.2.0) 4.2.1 > [Vmware] new mapping vmware datacenter cloudstack zone - Host in second > cluster in DC put in maintenance mode, CPVM and guest VMs that were migrated > failed to come up > --- > > Key: CLOUDSTACK-4513 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4513 > 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: MS10.223.195.52 build 479 > host ESXi 5.0 >Reporter: angeline shen >Priority: Critical > Fix For: 4.2.1 > > Attachments: Screenshot-CloudPlatform™ - Mozilla Firefox-1.png, > Screenshot-CloudPlatform™ - Mozilla Firefox.png > > > 1. > Vcenter CPP 4.2. > VC1 - DC1 - C1 - H1 zone1 - C1 - H1 10.223.51.2 > H2 H2 > 10.223.51.3 > PS2 cluster > primary storage > > C2 - H3C2 - H3 10.223.51.4 > PS3 cluster > primary storage > PS1 zone > primary storage > PSZ4 zone > primary storage > 2. H310.223.51.4 has SSVM CPVM and VMs i-2-8i-2-6 > VRs and other guest VMs were on Hosts H1 and H3 > 3. Put H3 in maintenance mode. > Result: > VMs i-2-6-VM and i-2-8-VM went into STOP state. Try to start both VMs. > These remain in > 'Starting' state . > New SSVM s-14-VM created.. Old SSVM s-10-VM remained in expunging and > disconnected state > CPVM v-11-VM remain in STOP and disconnected state. Cannot be started > -- 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-4513) [Vmware] new mapping vmware datacenter cloudstack zone - Host in second cluster in DC put in maintenance mode, CPVM and guest VMs that were migrated failed to come
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angeline shen updated CLOUDSTACK-4513: -- Attachment: Screenshot-CloudPlatform™ - Mozilla Firefox-1.png Screenshot-CloudPlatform™ - Mozilla Firefox.png > [Vmware] new mapping vmware datacenter cloudstack zone - Host in second > cluster in DC put in maintenance mode, CPVM and guest VMs that were migrated > failed to come up > --- > > Key: CLOUDSTACK-4513 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4513 > 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: MS10.223.195.52 build 479 > host ESXi 5.0 >Reporter: angeline shen >Priority: Critical > Fix For: 4.2.0 > > Attachments: Screenshot-CloudPlatform™ - Mozilla Firefox-1.png, > Screenshot-CloudPlatform™ - Mozilla Firefox.png > > > 1. > Vcenter CPP 4.2. > VC1 - DC1 - C1 - H1 zone1 - C1 - H1 10.223.51.2 > H2 H2 > 10.223.51.3 > PS2 cluster > primary storage > > C2 - H3C2 - H3 10.223.51.4 > PS3 cluster > primary storage > PS1 zone > primary storage > PSZ4 zone > primary storage > 2. H310.223.51.4 has SSVM CPVM and VMs i-2-8i-2-6 > VRs and other guest VMs were on Hosts H1 and H3 > 3. Put H3 in maintenance mode. > Result: > VMs i-2-6-VM and i-2-8-VM went into STOP state. Cannot be started > New SSVM s-14-VM created.. Old SSVM s-10-VM remained in expunging and > disconnected state > CPVM v-11-VM remain in STOP and disconnected state. Cannot be started > -- 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-4513) [Vmware] new mapping vmware datacenter cloudstack zone - Host in second cluster in DC put in maintenance mode, CPVM and guest VMs that were migrated failed to come
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angeline shen updated CLOUDSTACK-4513: -- Description: 1. Vcenter CPP 4.2. VC1 - DC1 - C1 - H1 zone1 - C1 - H1 10.223.51.2 H2 H2 10.223.51.3 PS2 cluster primary storage C2 - H3C2 - H3 10.223.51.4 PS3 cluster primary storage PS1 zone primary storage PSZ4 zone primary storage 2. H310.223.51.4 has SSVM CPVM and VMs i-2-8i-2-6 VRs and other guest VMs were on Hosts H1 and H3 3. Put H3 in maintenance mode. Result: VMs i-2-6-VM and i-2-8-VM went into STOP state. Try to start both VMs. These remain in 'Starting' state . New SSVM s-14-VM created.. Old SSVM s-10-VM remained in expunging and disconnected state CPVM v-11-VM remain in STOP and disconnected state. Cannot be started was: 1. Vcenter CPP 4.2. VC1 - DC1 - C1 - H1 zone1 - C1 - H1 10.223.51.2 H2 H2 10.223.51.3 PS2 cluster primary storage C2 - H3C2 - H3 10.223.51.4 PS3 cluster primary storage PS1 zone primary storage PSZ4 zone primary storage 2. H310.223.51.4 has SSVM CPVM and VMs i-2-8i-2-6 VRs and other guest VMs were on Hosts H1 and H3 3. Put H3 in maintenance mode. Result: VMs i-2-6-VM and i-2-8-VM went into STOP state. Cannot be started New SSVM s-14-VM created.. Old SSVM s-10-VM remained in expunging and disconnected state CPVM v-11-VM remain in STOP and disconnected state. Cannot be started > [Vmware] new mapping vmware datacenter cloudstack zone - Host in second > cluster in DC put in maintenance mode, CPVM and guest VMs that were migrated > failed to come up > --- > > Key: CLOUDSTACK-4513 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4513 > 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: MS10.223.195.52 build 479 > host ESXi 5.0 >Reporter: angeline shen >Priority: Critical > Fix For: 4.2.0 > > Attachments: Screenshot-CloudPlatform™ - Mozilla Firefox-1.png, > Screenshot-CloudPlatform™ - Mozilla Firefox.png > > > 1. > Vcenter CPP 4.2. > VC1 - DC1 - C1 - H1 zone1 - C1 - H1 10.223.51.2 > H2 H2 > 10.223.51.3 > PS2 cluster > primary storage > > C2 - H3C2 - H3 10.223.51.4 > PS3 cluster > primary storage > PS1 zone > primary storage > PSZ4 zone > primary storage > 2. H310.223.51.4 has SSVM CPVM and VMs i-2-8i-2-6 > VRs and other guest VMs were on Hosts H1 and H3 > 3. Put H3 in maintenance mode. > Result: > VMs i-2-6-VM and i-2-8-VM went into STOP state. Try to start both VMs. > These remain in > 'Starting' state . > New SSVM s-14-VM created.. Old SSVM s-10-VM remained in expunging and > disconnected state > CPVM v-11-VM remain in STOP and disconnected state. Cannot be started > -- 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-4513) [Vmware] new mapping vmware datacenter cloudstack zone - Host in second cluster in DC put in maintenance mode, CPVM and guest VMs that were migrated failed to come
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angeline shen updated CLOUDSTACK-4513: -- Description: 1. Vcenter CPP 4.2. VC1 - DC1 - C1 - H1 zone1 - C1 - H1 10.223.51.2 H2 H2 10.223.51.3 PS2 cluster primary storage C2 - H3C2 - H3 10.223.51.4 PS3 cluster primary storage PS1 zone primary storage PSZ4 zone primary storage 2. H310.223.51.4 has SSVM CPVM and VMs i-2-8i-2-6 VRs and other guest VMs were on Hosts H1 and H3 3. Put H3 in maintenance mode. Result: VMs i-2-6-VM and i-2-8-VM went into STOP state. Cannot be started New SSVM s-14-VM created.. Old SSVM s-10-VM remained in expunging and disconnected state CPVM v-11-VM remain in STOP and disconnected state. Cannot be started Environment: MS10.223.195.52 build 479 host ESXi 5.0 Affects Version/s: 4.2.0 Fix Version/s: 4.2.0 Summary: [Vmware] new mapping vmware datacenter cloudstack zone - Host in second cluster in DC put in maintenance mode, CPVM and guest VMs that were migrated failed to come up (was: [Vmware] new mapping vmware datacenter cloudstack zone - Host in second cluster in DC put in maintenance mode, CP) > [Vmware] new mapping vmware datacenter cloudstack zone - Host in second > cluster in DC put in maintenance mode, CPVM and guest VMs that were migrated > failed to come up > --- > > Key: CLOUDSTACK-4513 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4513 > 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: MS10.223.195.52 build 479 > host ESXi 5.0 >Reporter: angeline shen >Priority: Critical > Fix For: 4.2.0 > > > 1. > Vcenter CPP 4.2. > VC1 - DC1 - C1 - H1 zone1 - C1 - H1 10.223.51.2 > H2 H2 > 10.223.51.3 > PS2 cluster > primary storage > > C2 - H3C2 - H3 10.223.51.4 > PS3 cluster > primary storage > PS1 zone > primary storage > PSZ4 zone > primary storage > 2. H310.223.51.4 has SSVM CPVM and VMs i-2-8i-2-6 > VRs and other guest VMs were on Hosts H1 and H3 > 3. Put H3 in maintenance mode. > Result: > VMs i-2-6-VM and i-2-8-VM went into STOP state. Cannot be started > New SSVM s-14-VM created.. Old SSVM s-10-VM remained in expunging and > disconnected state > CPVM v-11-VM remain in STOP and disconnected state. Cannot be started > -- 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-4513) [Vmware] new mapping vmware datacenter cloudstack zone - Host in second cluster in DC put in maintenance mode, CP
angeline shen created CLOUDSTACK-4513: - Summary: [Vmware] new mapping vmware datacenter cloudstack zone - Host in second cluster in DC put in maintenance mode, CP Key: CLOUDSTACK-4513 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4513 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Reporter: angeline shen Priority: Critical -- 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-4464) Parallel deployment - Vmware - When deploying 30 parallel Vms , Vm fails to get deployed due to "StartCommand failed due to Exception: javax.xml.ws.soap.SOAPFaultEx
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelven Yang resolved CLOUDSTACK-4464. - Resolution: Fixed Please retry with this commit commit 046a8a889a3338ff86914b42eded316596ab5e6a Author: Kelven Yang Date: Mon Aug 26 17:45:54 2013 -0700 Custom field for vm instance name needs to be ensured in vCenter schema update when ESX host is connected > Parallel deployment - Vmware - When deploying 30 parallel Vms , Vm fails to > get deployed due to "StartCommand failed due to Exception: > javax.xml.ws.soap.SOAPFaultException" > > > Key: CLOUDSTACK-4464 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4464 > 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: Build from 4.2-forward >Reporter: Sangeetha Hariharan >Assignee: Kelven Yang >Priority: Blocker > Fix For: 4.2.1 > > Attachments: management-server.log > > > Parallel deployment - Vmware - When deploying 30 parallel Vms , Vm fails to > get deployed due to "StartCommand failed due to Exception: > javax.xml.ws.soap.SOAPFaultException" > Steps to reproduce the problem: > Set up - Advanced zone with 1 Vmware 5.0.0 Esxi host. > Deploy 30 Vms in parallel. > 5 out of 30 vms deployed in parallel , fail due to > "javax.xml.ws.soap.SOAPFaultException". > Management server logs shows the following exception: > 2013-08-22 15:57:22,603 WARN [vmware.resource.VmwareResource] > (DirectAgent-91:10.223.58.66) StartCommand failed due to Exception: > javax.xml.ws.soap.SOAPFaultException > Message: The object has already been deleted or has not been completely > created > javax.xml.ws.soap.SOAPFaultException: The object has already been deleted or > has not been completely created > at > com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) > at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107) > at $Proxy81.retrieveProperties(Unknown Source) > at > com.cloud.hypervisor.vmware.util.VmwareClient.retrieveMoRefProperties(VmwareClient.java:271) > at > com.cloud.hypervisor.vmware.util.VmwareClient.getDynamicProperty(VmwareClient.java:226) > at > com.cloud.hypervisor.vmware.mo.BaseMO.getCustomFieldValue(BaseMO.java:129) > at com.cloud.hypervisor.vmware.mo.HostMO.loadVmCache(HostMO.java:528) > at > com.cloud.hypervisor.vmware.mo.HostMO.findVmOnHyperHost(HostMO.java:488) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2667) > 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$101(ScheduledThreadPoolExecutor.java:165) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) -- 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-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:comment-tabpanel&focusedCommentId=13750877#comment-13750877
]
Kelven Yang commented on CLOUDSTACK-4430:
-
This is a regresion from object_store refactoring that caused one feature
missed in 4.2
In vmware, when template is deployed to primary storage, it will be assigned a
owner host, and when the owner host is down, we need to deploy another copy of
the template to a different host.
This will be fixed after other issues have been taken care of
> [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: Kelven Yang
>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":"SystemV
[jira] [Resolved] (CLOUDSTACK-4358) [Automation] [vmware] Few VM deployment failed with IndexOutOfBoundsException at "VolumeManagerImpl.java:2534"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelven Yang resolved CLOUDSTACK-4358.
-
Resolution: Fixed
I believe IndexOutOfBoundsException issue is fixed by VMware session keep-alive
mechanism.
"Few VM deployment failed" may be caused by various reasons, if you see
automation failures like this, find the related exception both in management
server log and SSVM log and file bug separately.
> [Automation] [vmware] Few VM deployment failed with IndexOutOfBoundsException
> at "VolumeManagerImpl.java:2534"
> --
>
> Key: CLOUDSTACK-4358
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4358
> 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
>Reporter: Rayees Namathponnan
>Assignee: Kelven Yang
>Priority: Blocker
> Fix For: 4.2.1
>
> Attachments: CLOUDSTACK-4358_Log2.rar, CLOUDSTACK-4358.rar,
> management-server.log.2013-08-19.gz
>
>
> This issue observed while executing test case
> integration.component.test_stopped_vm.TestDeployVMFromTemplate.test_deploy_vm_password_enabled
> VM deployment failed with below error in MS
> 2013-08-15 06:25:04,040 DEBUG [storage.volume.VolumeServiceImpl]
> (Job-Executor-151:job-1405 = [ 0c22bfca-fc58-42a0-a5eb-23def296accf ])
> Acquire lock on VMTemplateStoragePool 11 with timeout 3600 seconds
> 2013-08-15 06:25:04,041 INFO [storage.volume.VolumeServiceImpl]
> (Job-Executor-151:job-1405 = [ 0c22bfca-fc58-42a0-a5eb-23def296accf ]) lock
> is acquired for VMTemplateStoragePool 11
> 2013-08-15 06:25:04,051 DEBUG [storage.motion.AncientDataMotionStrategy]
> (Job-Executor-151:job-1405 = [ 0c22bfca-fc58-42a0-a5eb-23def296accf ])
> copyAsync inspecting src type TEMPLATE copyAsync inspecting dest type TEMPLATE
> 2013-08-15 06:25:04,065 DEBUG [agent.transport.Request]
> (Job-Executor-151:job-1405 = [ 0c22bfca-fc58-42a0-a5eb-23def296accf ]) Seq
> 9-1658651433: Sending { Cmd , MgmtId: 90928106758026, via: 9, Ver: v1,
> Flags: 100011, [{"org.apache.cloud
> stack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/282/230/3e85ab63-d22b-33b3-9e5e-e246b7413fff.ova","origUrl":"http://nfs1.lab.vmops.com/templates/ubuntu/ubuntu-12.04.
> 1-desktop-i386-nest-13.02.04.ova","uuid":"74cf2a78-5935-4c31-baca-d237f4fcf974","id":230,"format":"OVA","accountId":282,"checksum":"63d4a4350424504f416fcd989b6ef1b2","hvm":true,"displayText":"Cent
> OS Template","imageDataStore":{"com.clou
> d.agent.api.to.NfsTO":{"_url":"nfs://10.223.110.232:/export/home/automation/SC-CLOUD-QA03/secondary1","_role":"Image"}},"name":"230-282-0c4f6793-b7ab-334a-9a13-41f5580cdf90","hypervisorType":"VMware"}},"destTO":{"org.apache.cloudstack.st
> orage.to.TemplateObjectTO":{"origUrl":"http://nfs1.lab.vmops.com/templates/ubuntu/ubuntu-12.04.1-desktop-i386-nest-13.02.04.ova","uuid":"74cf2a78-5935-4c31-baca-d237f4fcf974","id":230,"format":"OVA","accountId":282,"checksum":"63d4a43504
> 24504f416fcd989b6ef1b2","hvm":true,"displayText":"Cent OS
> Template","imageDataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"4faf04c2-6dd8-3025-b43f-65d32cc49d02","id":1,"poolType":"NetworkFilesystem","host":"10.2
> 23.110.232","path":"/export/home/automation/SC-CLOUD-QA03/primary1","port":2049}},"name":"230-282-0c4f6793-b7ab-334a-9a13-41f5580cdf90","hypervisorType":"VMware"}},"executeInSequence":false,"wait":10800}}]
> }
> 2013-08-15 06:25:04,099 DEBUG [agent.transport.Request]
> (AgentManager-Handler-3:null) Seq 9-1658651433: Processing: { Ans: , MgmtId:
> 90928106758026, via: 9, Ver: v1, Flags: 10,
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"r
> esult":false,"details":"Unable to copy template to primary storage due to
> exception:Exception: java.lang.IndexOutOfBoundsException\nMessage: Index: 0,
> Size: 0\n","wait":0}}] }
> 2013-08-15 06:25:04,100 DEBUG [agent.transport.Request]
> (Job-Executor-151:job-1405 = [ 0c22bfca-fc58-42a0-a5eb-23def296accf ]) Seq
> 9-1658651433: Received: { Ans: , MgmtId: 90928106758026, via: 9, Ver: v1,
> Flags: 10, { CopyCmdAnswer } }
> 2013-08-15 06:25:04,108 INFO [storage.volume.VolumeServiceImpl]
> (Job-Executor-151:job-1405 = [ 0c22bfca-fc58-42a0-a5eb-23def296accf ])
> releasing lock for VMTemplateStoragePool 11
> 2013-08-15 06:25:04,108 WARN [utils.db.Merovingian2]
> (Job-Executor-151:job-1405 = [ 0c22bfca-fc58-42a0-a5eb-23def296accf ]) Was
> unable to find lock for the key template_spool_ref11 and thread id 557745274
> 2013-08-15 06:25:04,108 DEBUG [cloud.storage.VolumeManagerImp
[jira] [Commented] (CLOUDSTACK-3237) [vmware][SM] Migrate volume is failing when there are snapshots for that volume
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750855#comment-13750855
]
ASF subversion and git services commented on CLOUDSTACK-3237:
-
Commit 046a8a889a3338ff86914b42eded316596ab5e6a in branch
refs/heads/4.2-forward from [~kelveny]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=046a8a8 ]
CLOUDSTACK-3237: add disk chain sync logic to handle out-of-band chain changes
that could happen in storage live migration and VM snapshot operations
> [vmware][SM] Migrate volume is failing when there are snapshots for that
> volume
> ---
>
> Key: CLOUDSTACK-3237
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3237
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Volumes
>Affects Versions: 4.2.0
> Environment: vmware,
>Reporter: Srikanteswararao Talluri
>Assignee: Kelven Yang
>Priority: Blocker
> Fix For: 4.2.1
>
> Attachments: mgmt_27.log.zip
>
>
> Steps to reproduce:
> 1. create a VM
> 2. take snapshot of root volume of VM
> 3. migrate root volume to a suitable storage pool
> ===START=== 10.101.255.87 -- GET
> command=findStoragePoolsForMigration&id=f7c12988-61a8-49dc-a5d3-cd8653744a8e&response=json&sessionkey=dfd5NAw2qEmBOi3931kcin3eZtQ%3D&_=1372333879848
> 2013-06-27 22:46:36,408 DEBUG [storage.allocator.LocalStoragePoolAllocator]
> (catalina-exec-14:null) LocalStoragePoolAllocator trying to find storage pool
> to fit the vm
> 2013-06-27 22:46:36,410 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator] (catalina-exec-14:null)
> ClusterScopeStoragePoolAllocator looking for storage pool
> 2013-06-27 22:46:36,410 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator] (catalina-exec-14:null)
> Looking for pools in dc: 1 pod:1 cluster:1
> 2013-06-27 22:46:36,419 DEBUG
> [storage.allocator.AbstractStoragePoolAllocator] (catalina-exec-14:null)
> Checking if storage pool is suitable, name: null ,poolId: 1
> 2013-06-27 22:46:36,419 DEBUG
> [storage.allocator.AbstractStoragePoolAllocator] (catalina-exec-14:null)
> StoragePool is in avoid set, skipping this pool
> 2013-06-27 22:46:36,421 DEBUG
> [storage.allocator.AbstractStoragePoolAllocator] (catalina-exec-14:null)
> Checking if storage pool is suitable, name: null ,poolId: 3
> 2013-06-27 22:46:36,429 DEBUG [cloud.storage.StorageManagerImpl]
> (catalina-exec-14:null) Checking pool 3 for storage, totalSize:
> 590228480, usedBytes: 3490243883008, usedPct: 0.5913377617779474, disable
> threshold: 0.85
> 2013-06-27 22:46:36,461 DEBUG [cloud.storage.StorageManagerImpl]
> (catalina-exec-14:null) Checking pool: 3 for volume allocation
> [Vol[4|vm=4|ROOT]], maxSize : 1180456960, totalAllocatedSize :
> 23622320128, askingSize : 0, allocated disable threshold: 0.85
> 2013-06-27 22:46:36,464 DEBUG
> [storage.allocator.AbstractStoragePoolAllocator] (catalina-exec-14:null)
> Checking if storage pool is suitable, name: null ,poolId: 5
> 2013-06-27 22:46:36,471 DEBUG [cloud.storage.StorageManagerImpl]
> (catalina-exec-14:null) Checking pool 5 for storage, totalSize:
> 590228480, usedBytes: 3490243883008, usedPct: 0.5913377617779474, disable
> threshold: 0.85
> 2013-06-27 22:46:36,492 DEBUG [cloud.storage.StorageManagerImpl]
> (catalina-exec-14:null) Checking pool: 5 for volume allocation
> [Vol[4|vm=4|ROOT]], maxSize : 1180456960, totalAllocatedSize :
> 35433480192, askingSize : 0, allocated disable threshold: 0.85
> 2013-06-27 22:46:36,492 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator] (catalina-exec-14:null)
> FirstFitStoragePoolAllocator returning 2 suitable storage pools
> 2013-06-27 22:46:36,506 DEBUG [cloud.api.ApiServlet] (catalina-exec-14:null)
> ===END=== 10.101.255.87 -- GET
> command=findStoragePoolsForMigration&id=f7c12988-61a8-49dc-a5d3-cd8653744a8e&response=json&sessionkey=dfd5NAw2qEmBOi3931kcin3eZtQ%3D&_=1372333879848
> 2013-06-27 22:46:39,967 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-9:null) Ping from 4
> 2013-06-27 22:46:40,804 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-11:null) SeqA 3-10940: Processing Seq 3-10940: { Cmd ,
> MgmtId: -1, via: 3, Ver: v1, Flags: 11,
> [{"ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2013-06-27 22:46:40,813 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-11:null) SeqA 3-10940: Sending Seq 3-10940: { Ans: ,
> MgmtId: 7566222426160, via: 3, Ver: v1, Flags: 100010,
> [{"AgentControlAnswer":{"result":true,"wait":0}}] }
> 2013-06-27 22:46:41,
[jira] [Resolved] (CLOUDSTACK-3237) [vmware][SM] Migrate volume is failing when there are snapshots for that volume
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelven Yang resolved CLOUDSTACK-3237.
-
Resolution: Fixed
> [vmware][SM] Migrate volume is failing when there are snapshots for that
> volume
> ---
>
> Key: CLOUDSTACK-3237
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3237
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Volumes
>Affects Versions: 4.2.0
> Environment: vmware,
>Reporter: Srikanteswararao Talluri
>Assignee: Kelven Yang
>Priority: Blocker
> Fix For: 4.2.1
>
> Attachments: mgmt_27.log.zip
>
>
> Steps to reproduce:
> 1. create a VM
> 2. take snapshot of root volume of VM
> 3. migrate root volume to a suitable storage pool
> ===START=== 10.101.255.87 -- GET
> command=findStoragePoolsForMigration&id=f7c12988-61a8-49dc-a5d3-cd8653744a8e&response=json&sessionkey=dfd5NAw2qEmBOi3931kcin3eZtQ%3D&_=1372333879848
> 2013-06-27 22:46:36,408 DEBUG [storage.allocator.LocalStoragePoolAllocator]
> (catalina-exec-14:null) LocalStoragePoolAllocator trying to find storage pool
> to fit the vm
> 2013-06-27 22:46:36,410 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator] (catalina-exec-14:null)
> ClusterScopeStoragePoolAllocator looking for storage pool
> 2013-06-27 22:46:36,410 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator] (catalina-exec-14:null)
> Looking for pools in dc: 1 pod:1 cluster:1
> 2013-06-27 22:46:36,419 DEBUG
> [storage.allocator.AbstractStoragePoolAllocator] (catalina-exec-14:null)
> Checking if storage pool is suitable, name: null ,poolId: 1
> 2013-06-27 22:46:36,419 DEBUG
> [storage.allocator.AbstractStoragePoolAllocator] (catalina-exec-14:null)
> StoragePool is in avoid set, skipping this pool
> 2013-06-27 22:46:36,421 DEBUG
> [storage.allocator.AbstractStoragePoolAllocator] (catalina-exec-14:null)
> Checking if storage pool is suitable, name: null ,poolId: 3
> 2013-06-27 22:46:36,429 DEBUG [cloud.storage.StorageManagerImpl]
> (catalina-exec-14:null) Checking pool 3 for storage, totalSize:
> 590228480, usedBytes: 3490243883008, usedPct: 0.5913377617779474, disable
> threshold: 0.85
> 2013-06-27 22:46:36,461 DEBUG [cloud.storage.StorageManagerImpl]
> (catalina-exec-14:null) Checking pool: 3 for volume allocation
> [Vol[4|vm=4|ROOT]], maxSize : 1180456960, totalAllocatedSize :
> 23622320128, askingSize : 0, allocated disable threshold: 0.85
> 2013-06-27 22:46:36,464 DEBUG
> [storage.allocator.AbstractStoragePoolAllocator] (catalina-exec-14:null)
> Checking if storage pool is suitable, name: null ,poolId: 5
> 2013-06-27 22:46:36,471 DEBUG [cloud.storage.StorageManagerImpl]
> (catalina-exec-14:null) Checking pool 5 for storage, totalSize:
> 590228480, usedBytes: 3490243883008, usedPct: 0.5913377617779474, disable
> threshold: 0.85
> 2013-06-27 22:46:36,492 DEBUG [cloud.storage.StorageManagerImpl]
> (catalina-exec-14:null) Checking pool: 5 for volume allocation
> [Vol[4|vm=4|ROOT]], maxSize : 1180456960, totalAllocatedSize :
> 35433480192, askingSize : 0, allocated disable threshold: 0.85
> 2013-06-27 22:46:36,492 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator] (catalina-exec-14:null)
> FirstFitStoragePoolAllocator returning 2 suitable storage pools
> 2013-06-27 22:46:36,506 DEBUG [cloud.api.ApiServlet] (catalina-exec-14:null)
> ===END=== 10.101.255.87 -- GET
> command=findStoragePoolsForMigration&id=f7c12988-61a8-49dc-a5d3-cd8653744a8e&response=json&sessionkey=dfd5NAw2qEmBOi3931kcin3eZtQ%3D&_=1372333879848
> 2013-06-27 22:46:39,967 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-9:null) Ping from 4
> 2013-06-27 22:46:40,804 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-11:null) SeqA 3-10940: Processing Seq 3-10940: { Cmd ,
> MgmtId: -1, via: 3, Ver: v1, Flags: 11,
> [{"ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2013-06-27 22:46:40,813 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-11:null) SeqA 3-10940: Sending Seq 3-10940: { Ans: ,
> MgmtId: 7566222426160, via: 3, Ver: v1, Flags: 100010,
> [{"AgentControlAnswer":{"result":true,"wait":0}}] }
> 2013-06-27 22:46:41,091 DEBUG [cloud.api.ApiServlet] (catalina-exec-18:null)
> ===START=== 10.101.255.87 -- GET
> command=migrateVolume&livemigrate=true&storageid=e690ef30-851c-33b0-a1b3-38fd7fa4c40c&volumeid=f7c12988-61a8-49dc-a5d3-cd8653744a8e&response=json&sessionkey=dfd5NAw2qEmBOi3931kcin3eZtQ%3D&_=1372333884566
> 2013-06-27 22:46:41,135 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-18:null) submit async
[jira] [Commented] (CLOUDSTACK-4488) There have some error on bandwidth limits. vm's network speed is 800kbyte/s.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750849#comment-13750849
]
terryye commented on CLOUDSTACK-4488:
-
plugins\hypervisors\kvm\src\com\cloud\hypervisor\kvm\resource\LibvirtVMDef.java
public void defBridgeNet(String brName, String targetBrName,
String macAddr, nicModel model, Integer networkRateKBps) {
_netType = guestNetType.BRIDGE;
_sourceName = brName;
_networkName = targetBrName;
_macAddr = macAddr;
_model = model;
_networkRateKBps = 0;
public void defPrivateNet(String networkName, String targetName,
String macAddr, nicModel model, Integer networkRateKBps) {
_netType = guestNetType.NETWORK;
_sourceName = networkName;
_networkName = targetName;
_macAddr = macAddr;
_model = model;
_networkRateKBps = 0;
if do it ,the network speed is no limited.
> There have some error on bandwidth limits. vm's network speed is 800kbyte/s.
>
>
> Key: CLOUDSTACK-4488
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4488
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Hypervisor Controller, KVM, Network Controller
>Affects Versions: 4.1.2
> Environment: ubuntu1204 kvm
>Reporter: terryye
> Labels: bandwidth, kvm, limits
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> Global configs
> network.throttling.rate 4
>
> vm.network.throttling.rate4
> rate limits is not set.
> But i test the vm to another nfs ,speed is so poor.
> Using wget to test ,the speed is similar.
> so i edit the global config,but it seems not any role.
> when i set it to 1,the vm can not be created.
> agent log is :
> 2013-08-25 15:07:54,032 WARN [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-3:null) Exception
> org.libvirt.LibvirtException: internal error cannot set bandwidth limits on
> vnet0
> at org.libvirt.ErrorHandler.processError(Unknown Source)
> at org.libvirt.Connect.processError(Unknown Source)
> at org.libvirt.Connect.domainCreateXML(Unknown Source)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startDomain(LibvirtComputingResource.java:1012)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3148)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1128)
> at com.cloud.agent.Agent.processRequest(Agent.java:525)
> at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852)
> at com.cloud.utils.nio.Task.run(Task.java:83)
> 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-25 15:08:05,252 WARN [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-1:null) Exception
> org.libvirt.LibvirtException: internal error cannot set bandwidth limits on
> vnet0
> at org.libvirt.ErrorHandler.processError(Unknown Source)
> at org.libvirt.Connect.processError(Unknown Source)
> at org.libvirt.Connect.domainCreateXML(Unknown Source)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startDomain(LibvirtComputingResource.java:1012)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3148)
> at
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1128)
> at com.cloud.agent.Agent.processRequest(Agent.java:525)
> at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852)
> at com.cloud.utils.nio.Task.run(Task.java:83)
> 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)
--
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-4454) object_store - Not able to delete secondary storage when existing snapshots are deleted.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeetha Hariharan closed CLOUDSTACK-4454. --- Tested with latest build from 4.2-forward. We are able to successfully delete secondary storage when all existing snapshots are deleted. > object_store - Not able to delete secondary storage when existing snapshots > are deleted. > > > Key: CLOUDSTACK-4454 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4454 > 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: Build from 4.2 >Reporter: Sangeetha Hariharan >Assignee: Min Chen >Priority: Critical > Fix For: 4.2.0, 4.2.1 > > > object_store - Not able to delete secondary storage when existing snapshots > are deleted. > Steps to reproduce the problem: > Have a zone with 2 NSF secondary stores - ss1 and ss2. > Deploy few Vms and take few snapshots. > Delete all the snapshots that reside in ss2. > Now try to delete ss2. > Deletion fails with following error message: > "Cannot delete image store with active snapshots backup!" > Management server logs: > 2013-08-22 10:13:35,466 DEBUG [cloud.api.ApiServlet] (catalina-exec-12:null) > ===START=== 10.215.3.9 > -- GET command=deleteImageStore&id=7b7ed196-fa00-4cd8-a606 > > -b743cd64cfd9&response=json&sessionkey=pk9TsSw2pRHDZg2GsRmnZYONBKU%3D&_=13771920 > 39022 > 2013-08-22 10:13:35,475 INFO [cloud.api.ApiServer] (catalina-exec-12:null) > Cannot delete image store with active snapshots backup! > mysql> select * from image_store; > ++--+-+--+---++---+---+--+--+-+-+++ > | id | name | image_provider_name | protocol | url >| data_center_id | scope | role | uuid > | parent | created > | removed | total_size | used_bytes | > ++--+-+--+---++---+---+--+--+-+-+++ > | 1 | ss1 | NFS | nfs | > nfs://10.223.110.232/export/home/sangeetha/42-ipv6/secondary/ | > 1 | ZONE | Image | cb921af8-83fa-4b04-a1fd-2a0970e3d16d | > 036a3728-d869-3d9a-b590-bd8cbf5b2c14 | 2013-08-20 21:52:22 | NULL| > NULL | NULL | > | 2 | ss2 | NFS | nfs | > nfs://10.223.110.232/export/home/sangeetha/42-ipv6/secondary2 | > 1 | ZONE | Image | 7b7ed196-fa00-4cd8-a606-b743cd64cfd9 | > 0653a328-9bb3-321c-943d-f5164eb2d62f | 2013-08-21 23:46:45 | NULL| > NULL | NULL | > | 3 | ss3 | NFS | nfs | > nfs://10.223.110.232/export/home/sangeetha/42-ipv6/secondary3 | > 1 | ZONE | Image | 4598a3fd-7b69-4e3f-9178-36799b5755b1 | > 71490b8f-f8fd-3f54-b280-ded7eebee441 | 2013-08-22 17:17:57 | NULL| > NULL | NULL | > ++--+-+--+---++---+---+--+--+-+-+++ > 3 rows in set (0.00 sec) > mysql> select store_id , store_role, snapshot_id , state from > snapshot_store_ref; > +--++-+---+ > | store_id | store_role | snapshot_id | state | > +--++-+---+ > |1 | Image | 1 | Ready | > |1 | Primary| 2 | Ready | > |1 | Image | 2 | Ready | > |1 | Primary| 3 | Destroyed | > |2 | Image | 3 | Destroyed | > |1 | Primary| 4 | Destroyed | > |2 | Image | 4 | Destroyed | > +--++-+---+ > 7 rows in set (0.03 sec) > mysql> -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrato
[jira] [Commented] (CLOUDSTACK-4459) [Automation] Vm deployment failed in KVM with missing storage pool error
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750839#comment-13750839
]
ASF subversion and git services commented on CLOUDSTACK-4459:
-
Commit 58786079706c85e3b0f331301e81fa560edb0cb0 in branch refs/heads/4.2 from
[~edison]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5878607 ]
CLOUDSTACK-4459:
Libvirt reports:
org.libvirt.LibvirtException: Storage volume not found: no storage vol
with matching name
in some cases, if the volume is created on one kvm host, while accessed
from other host.
It's possible due to concurrent access(read/write) storage.
The current fix is to try serveral times, and wait for 30 seconds for
each retry.
If the issue still there, then need to sync the storage pool access
> [Automation] Vm deployment failed in KVM with missing storage pool error
> -
>
> Key: CLOUDSTACK-4459
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4459
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, KVM
>Affects Versions: 4.2.0
> Environment: Automation
> KVM
>Reporter: Rayees Namathponnan
>Assignee: edison su
>Priority: Critical
> Fix For: 4.2.0, 4.2.1
>
> Attachments: CLOUDSTACK-4457_Agent.rar, CLOUDSTACK-4457_MS.rar,
> KVM_Regression_24_Aug_Agent.rar, KVM_Regression_24_Aug_MS.rar
>
>
> This is observed during automation; few VM deployment failed due to missing
> storage pool;
> See the error from MS
> 2013-08-21 19:55:29,239 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-23:job-40 = [ 5244a122-13cb-4480-976f-d464c1e461fb ]) Start
> completed for VM VM[User|1ce406e5-67c5-43fc-8284-8190bf29c42c]
> 2013-08-21 19:55:29,285 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-23:job-40 = [ 5244a122-13cb-4480-976f-d464c1e461fb ]) Complete
> async job-40 = [ 5244a122-13cb-4480-976f-d464c1e461fb ], jobStatus: 1,
> resultCode: 0, result:
> org.apache.cloudstack.api.response.UserVmResponse@d912e1d
> 2013-08-21 19:55:29,289 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-23:job-40 = [ 5244a122-13cb-4480-976f-d464c1e461fb ]) Done
> executing org.apache.cloudstack.api.command.user.vm.DeployVMCmd for job-40 =
> [ 5244a122-13cb-4480-976f-d464c1e461fb ]
> 2013-08-21 19:55:29,400 DEBUG [agent.transport.Request]
> (AgentManager-Handler-6:null) Seq 2-861536310: Processing: { Ans: , MgmtId:
> 29066118877352, via: 2, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"com.cloud.utils.exception.CloudRuntimeException:
> org.libvirt.LibvirtException: Storage volume not found: no storage vol with
> matching name '8acfcc0f-5389-4d9a-8072-3494b8eb0197'\n\tat
> com.cloud.hypervisor.kvm.storage.LibvirtStorageAdaptor.getVolume(LibvirtStorageAdaptor.java:111)\n\tat
>
> com.cloud.hypervisor.kvm.storage.LibvirtStorageAdaptor.getPhysicalDisk(LibvirtStorageAdaptor.java:411)\n\tat
>
> com.cloud.hypervisor.kvm.storage.LibvirtStoragePool.getPhysicalDisk(LibvirtStoragePool.java:123)\n\tat
>
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.createVbd(LibvirtComputingResource.java:3650)\n\tat
>
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3519)\n\tat
>
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1252)\n\tat
> com.cloud.agent.Agent.processRequest(Agent.java:525)\n\tat
> com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852)\n\tat
> com.cloud.utils.nio.Task.run(Task.java:83)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n\tat
> java.lang.Thread.run(Thread.java:679)\n","wait":0}}] }
> 2013-08-21 19:55:29,401 DEBUG [agent.transport.Request]
> (Job-Executor-24:job-41 = [ 30ed2109-5ffd-455f-8ad7-3eeff366d9f5 ]) Seq
> 2-861536310: Received: { Ans: , MgmtId: 29066118877352, via: 2, Ver: v1,
> Flags: 10, { Answer } }
> 2013-08-21 19:55:29,404 ERROR [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-24:job-41 = [ 30ed2109-5ffd-455f-8ad7-3eeff366d9f5 ]) Failed to
> start instance VM[User|76e3d7a7-825e-49d2-b663-783b65081d43]
> com.cloud.utils.exception.CloudRuntimeException: Unable to get answer that is
> of class com.cloud.agent.api.StartAnswer
> at com.cloud.agent.manager.Commands.getAnswer(Commands.java:80)
> at
> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:917)
> at
> com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachi
[jira] [Commented] (CLOUDSTACK-4459) [Automation] Vm deployment failed in KVM with missing storage pool error
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750840#comment-13750840
]
ASF subversion and git services commented on CLOUDSTACK-4459:
-
Commit 816772a001f48f0b8f79a89242de2bc38aef8ca4 in branch
refs/heads/4.2-forward from [~edison]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=816772a ]
CLOUDSTACK-4459:
Libvirt reports:
org.libvirt.LibvirtException: Storage volume not found: no storage vol
with matching name
in some cases, if the volume is created on one kvm host, while accessed
from other host.
It's possible due to concurrent access(read/write) storage.
The current fix is to try serveral times, and wait for 30 seconds for
each retry.
If the issue still there, then need to sync the storage pool access
> [Automation] Vm deployment failed in KVM with missing storage pool error
> -
>
> Key: CLOUDSTACK-4459
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4459
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, KVM
>Affects Versions: 4.2.0
> Environment: Automation
> KVM
>Reporter: Rayees Namathponnan
>Assignee: edison su
>Priority: Critical
> Fix For: 4.2.0, 4.2.1
>
> Attachments: CLOUDSTACK-4457_Agent.rar, CLOUDSTACK-4457_MS.rar,
> KVM_Regression_24_Aug_Agent.rar, KVM_Regression_24_Aug_MS.rar
>
>
> This is observed during automation; few VM deployment failed due to missing
> storage pool;
> See the error from MS
> 2013-08-21 19:55:29,239 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-23:job-40 = [ 5244a122-13cb-4480-976f-d464c1e461fb ]) Start
> completed for VM VM[User|1ce406e5-67c5-43fc-8284-8190bf29c42c]
> 2013-08-21 19:55:29,285 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-23:job-40 = [ 5244a122-13cb-4480-976f-d464c1e461fb ]) Complete
> async job-40 = [ 5244a122-13cb-4480-976f-d464c1e461fb ], jobStatus: 1,
> resultCode: 0, result:
> org.apache.cloudstack.api.response.UserVmResponse@d912e1d
> 2013-08-21 19:55:29,289 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-23:job-40 = [ 5244a122-13cb-4480-976f-d464c1e461fb ]) Done
> executing org.apache.cloudstack.api.command.user.vm.DeployVMCmd for job-40 =
> [ 5244a122-13cb-4480-976f-d464c1e461fb ]
> 2013-08-21 19:55:29,400 DEBUG [agent.transport.Request]
> (AgentManager-Handler-6:null) Seq 2-861536310: Processing: { Ans: , MgmtId:
> 29066118877352, via: 2, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"com.cloud.utils.exception.CloudRuntimeException:
> org.libvirt.LibvirtException: Storage volume not found: no storage vol with
> matching name '8acfcc0f-5389-4d9a-8072-3494b8eb0197'\n\tat
> com.cloud.hypervisor.kvm.storage.LibvirtStorageAdaptor.getVolume(LibvirtStorageAdaptor.java:111)\n\tat
>
> com.cloud.hypervisor.kvm.storage.LibvirtStorageAdaptor.getPhysicalDisk(LibvirtStorageAdaptor.java:411)\n\tat
>
> com.cloud.hypervisor.kvm.storage.LibvirtStoragePool.getPhysicalDisk(LibvirtStoragePool.java:123)\n\tat
>
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.createVbd(LibvirtComputingResource.java:3650)\n\tat
>
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3519)\n\tat
>
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1252)\n\tat
> com.cloud.agent.Agent.processRequest(Agent.java:525)\n\tat
> com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852)\n\tat
> com.cloud.utils.nio.Task.run(Task.java:83)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n\tat
> java.lang.Thread.run(Thread.java:679)\n","wait":0}}] }
> 2013-08-21 19:55:29,401 DEBUG [agent.transport.Request]
> (Job-Executor-24:job-41 = [ 30ed2109-5ffd-455f-8ad7-3eeff366d9f5 ]) Seq
> 2-861536310: Received: { Ans: , MgmtId: 29066118877352, via: 2, Ver: v1,
> Flags: 10, { Answer } }
> 2013-08-21 19:55:29,404 ERROR [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-24:job-41 = [ 30ed2109-5ffd-455f-8ad7-3eeff366d9f5 ]) Failed to
> start instance VM[User|76e3d7a7-825e-49d2-b663-783b65081d43]
> com.cloud.utils.exception.CloudRuntimeException: Unable to get answer that is
> of class com.cloud.agent.api.StartAnswer
> at com.cloud.agent.manager.Commands.getAnswer(Commands.java:80)
> at
> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:917)
> at
> com.cloud.vm.VirtualMachineManagerImpl.start(Virt
[jira] [Resolved] (CLOUDSTACK-4484) Vmware - Not able to fetch userdata from guest Vms using http:///latest/user-data
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
frank zhang resolved CLOUDSTACK-4484.
-
Resolution: Fixed
> Vmware - Not able to fetch userdata from guest Vms using
> http:///latest/user-data
> -
>
> Key: CLOUDSTACK-4484
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4484
> 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, 4.2.1
> Environment: Build from 4.2-forward
>Reporter: Sangeetha Hariharan
>Assignee: frank zhang
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: management-server.rar
>
>
> Not able to fetch userdata from guest Vms using
> http:///latest/user-data
> Set up:
> Advanced zone set up with vmware host.
> Steps to reproduce the problem:
> Deploy Vm using user data.
> Vm deployment succeeds.
> From with in the guest Vm , try to access the user data using
> http:///latest/user-data.
> [root@dd-1 ~]# wget http://10.1.1.1/latest/user-data
> --19:58:29-- http://10.1.1.1/latest/user-data
> Connecting to 10.1.1.1:80... connected.
> HTTP request sent, awaiting response... 404 Not Found
> 19:58:29 ERROR 404: Not Found.
> [root@dd-1 ~]#
> On the router , we do not see /var/www/html/userdata/ file.
> In my case guest ip address is 10.1.1.45.
> Note- For all instances which were deployed with no userdata , i see
> /var/www/html/userdata//user-data which are empty. In case
> of Vms deployed with userdata , this file is not being created.
> deployVirtualMachine() api call used:
> 2013-08-23 15:26:07,078 DEBUG [cloud.api.ApiServlet] (catalina-exec-7:null)
> ===START=== 10.215.3.28 -- GET
> command=deployVirtualMachine&zoneId=93368e7c-db1b-4344-8777-2a6e0507c2ba&templateId=dd5c6bb5-602a-4cc4-9328-a26096294cf7&hypervisor=XenServer&serviceOfferingId=e83c2f9a-cbdc-46dc-8743-c76f3c270e99&networkIds=95528f66-22f8-4932-86b6-96b1183d5693&response=json&name=dd-1&displayName=dd-1&userdata=aGVsbG8gaG93IHIgdSA/IEkgYW0gZmluZSAuLi51IG9rID8=&apiKey=2aLe3o6TVY7286zbAJSCqbmhHlhaKU4at9HqUGbLoImE9SzR6Ys6tyWEbkCcDJDH-_Z5RlutsOYhMql2kixZpw&signature=s6Dvwr%2F8vEvqONyJKGmQKETcDVo%3D
> Management server log indicating that the user-data progarmming succeeds:
> 2013-08-23 15:26:08,123 DEBUG [vmware.resource.VmwareResource]
> (DirectAgent-162:10.223.58.66) Use router's private IP for SSH control.
> IP : 10.223.58.70
> 2013-08-23 15:26:08,123 DEBUG [vmware.resource.VmwareResource]
> (DirectAgent-162:10.223.58.66) Run vm_data command on domain router 10.2
> 23.58.70, data: routerIP
> 10.223.58.70
> vmIP
> 10.1.1.45
> userdata,user-data
> aGVsbG8gaG93IHIgdSA/IEkgYW0gZmluZSAuLi51IG9rID8
> metadata,service-offering
> tiny1
> metadata,availability-zone
> zone1
> metadata,local-ipv4
> 10.1.1.45
> metadata,local-hostname
> dd-1
> metadata,public-ipv4
> 10.223.138.68
> metadata,public-hostname
> 10.223.138.68
> metadata,instance-id
> eb6adb2c-576c-4722-bb89-a52f2ad49fb3
> metadata,vm-id
> eb6adb2c-576c-4722-bb89-a52f2ad49fb3
> metadata,public-keys
> none
> metadata,cloud-identifier
> CloudStack-{c9bcecaa-a61a-4192-9df2-4b7c8a9d1294}
> 2013-08-23 15:26:09,983 INFO [vmware.resource.VmwareResource]
> (DirectAgent-162:10.223.58.66) vm_data command on domain router 10.223.58.70
> completed
--
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-4484) Vmware - Not able to fetch userdata from guest Vms using http:///latest/user-data
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750822#comment-13750822
]
ASF subversion and git services commented on CLOUDSTACK-4484:
-
Commit 64f9f0cee602a28777ce2c04d1b340d2da61d034 in branch refs/heads/master
from [~frank.zhang]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=64f9f0c ]
CloudStack CLOUDSTACK-4484
Vmware - Not able to fetch userdata from guest Vms using
http:///latest/user-data
> Vmware - Not able to fetch userdata from guest Vms using
> http:///latest/user-data
> -
>
> Key: CLOUDSTACK-4484
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4484
> 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, 4.2.1
> Environment: Build from 4.2-forward
>Reporter: Sangeetha Hariharan
>Assignee: frank zhang
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: management-server.rar
>
>
> Not able to fetch userdata from guest Vms using
> http:///latest/user-data
> Set up:
> Advanced zone set up with vmware host.
> Steps to reproduce the problem:
> Deploy Vm using user data.
> Vm deployment succeeds.
> From with in the guest Vm , try to access the user data using
> http:///latest/user-data.
> [root@dd-1 ~]# wget http://10.1.1.1/latest/user-data
> --19:58:29-- http://10.1.1.1/latest/user-data
> Connecting to 10.1.1.1:80... connected.
> HTTP request sent, awaiting response... 404 Not Found
> 19:58:29 ERROR 404: Not Found.
> [root@dd-1 ~]#
> On the router , we do not see /var/www/html/userdata/ file.
> In my case guest ip address is 10.1.1.45.
> Note- For all instances which were deployed with no userdata , i see
> /var/www/html/userdata//user-data which are empty. In case
> of Vms deployed with userdata , this file is not being created.
> deployVirtualMachine() api call used:
> 2013-08-23 15:26:07,078 DEBUG [cloud.api.ApiServlet] (catalina-exec-7:null)
> ===START=== 10.215.3.28 -- GET
> command=deployVirtualMachine&zoneId=93368e7c-db1b-4344-8777-2a6e0507c2ba&templateId=dd5c6bb5-602a-4cc4-9328-a26096294cf7&hypervisor=XenServer&serviceOfferingId=e83c2f9a-cbdc-46dc-8743-c76f3c270e99&networkIds=95528f66-22f8-4932-86b6-96b1183d5693&response=json&name=dd-1&displayName=dd-1&userdata=aGVsbG8gaG93IHIgdSA/IEkgYW0gZmluZSAuLi51IG9rID8=&apiKey=2aLe3o6TVY7286zbAJSCqbmhHlhaKU4at9HqUGbLoImE9SzR6Ys6tyWEbkCcDJDH-_Z5RlutsOYhMql2kixZpw&signature=s6Dvwr%2F8vEvqONyJKGmQKETcDVo%3D
> Management server log indicating that the user-data progarmming succeeds:
> 2013-08-23 15:26:08,123 DEBUG [vmware.resource.VmwareResource]
> (DirectAgent-162:10.223.58.66) Use router's private IP for SSH control.
> IP : 10.223.58.70
> 2013-08-23 15:26:08,123 DEBUG [vmware.resource.VmwareResource]
> (DirectAgent-162:10.223.58.66) Run vm_data command on domain router 10.2
> 23.58.70, data: routerIP
> 10.223.58.70
> vmIP
> 10.1.1.45
> userdata,user-data
> aGVsbG8gaG93IHIgdSA/IEkgYW0gZmluZSAuLi51IG9rID8
> metadata,service-offering
> tiny1
> metadata,availability-zone
> zone1
> metadata,local-ipv4
> 10.1.1.45
> metadata,local-hostname
> dd-1
> metadata,public-ipv4
> 10.223.138.68
> metadata,public-hostname
> 10.223.138.68
> metadata,instance-id
> eb6adb2c-576c-4722-bb89-a52f2ad49fb3
> metadata,vm-id
> eb6adb2c-576c-4722-bb89-a52f2ad49fb3
> metadata,public-keys
> none
> metadata,cloud-identifier
> CloudStack-{c9bcecaa-a61a-4192-9df2-4b7c8a9d1294}
> 2013-08-23 15:26:09,983 INFO [vmware.resource.VmwareResource]
> (DirectAgent-162:10.223.58.66) vm_data command on domain router 10.223.58.70
> completed
--
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-4484) Vmware - Not able to fetch userdata from guest Vms using http:///latest/user-data
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750821#comment-13750821
]
ASF subversion and git services commented on CLOUDSTACK-4484:
-
Commit 697cc2e397a8d6ff0d293587877dfb3033d87c26 in branch
refs/heads/4.2-forward from [~frank.zhang]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=697cc2e ]
CloudStack CLOUDSTACK-4484
Vmware - Not able to fetch userdata from guest Vms using
http:///latest/user-data
> Vmware - Not able to fetch userdata from guest Vms using
> http:///latest/user-data
> -
>
> Key: CLOUDSTACK-4484
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4484
> 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, 4.2.1
> Environment: Build from 4.2-forward
>Reporter: Sangeetha Hariharan
>Assignee: frank zhang
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: management-server.rar
>
>
> Not able to fetch userdata from guest Vms using
> http:///latest/user-data
> Set up:
> Advanced zone set up with vmware host.
> Steps to reproduce the problem:
> Deploy Vm using user data.
> Vm deployment succeeds.
> From with in the guest Vm , try to access the user data using
> http:///latest/user-data.
> [root@dd-1 ~]# wget http://10.1.1.1/latest/user-data
> --19:58:29-- http://10.1.1.1/latest/user-data
> Connecting to 10.1.1.1:80... connected.
> HTTP request sent, awaiting response... 404 Not Found
> 19:58:29 ERROR 404: Not Found.
> [root@dd-1 ~]#
> On the router , we do not see /var/www/html/userdata/ file.
> In my case guest ip address is 10.1.1.45.
> Note- For all instances which were deployed with no userdata , i see
> /var/www/html/userdata//user-data which are empty. In case
> of Vms deployed with userdata , this file is not being created.
> deployVirtualMachine() api call used:
> 2013-08-23 15:26:07,078 DEBUG [cloud.api.ApiServlet] (catalina-exec-7:null)
> ===START=== 10.215.3.28 -- GET
> command=deployVirtualMachine&zoneId=93368e7c-db1b-4344-8777-2a6e0507c2ba&templateId=dd5c6bb5-602a-4cc4-9328-a26096294cf7&hypervisor=XenServer&serviceOfferingId=e83c2f9a-cbdc-46dc-8743-c76f3c270e99&networkIds=95528f66-22f8-4932-86b6-96b1183d5693&response=json&name=dd-1&displayName=dd-1&userdata=aGVsbG8gaG93IHIgdSA/IEkgYW0gZmluZSAuLi51IG9rID8=&apiKey=2aLe3o6TVY7286zbAJSCqbmhHlhaKU4at9HqUGbLoImE9SzR6Ys6tyWEbkCcDJDH-_Z5RlutsOYhMql2kixZpw&signature=s6Dvwr%2F8vEvqONyJKGmQKETcDVo%3D
> Management server log indicating that the user-data progarmming succeeds:
> 2013-08-23 15:26:08,123 DEBUG [vmware.resource.VmwareResource]
> (DirectAgent-162:10.223.58.66) Use router's private IP for SSH control.
> IP : 10.223.58.70
> 2013-08-23 15:26:08,123 DEBUG [vmware.resource.VmwareResource]
> (DirectAgent-162:10.223.58.66) Run vm_data command on domain router 10.2
> 23.58.70, data: routerIP
> 10.223.58.70
> vmIP
> 10.1.1.45
> userdata,user-data
> aGVsbG8gaG93IHIgdSA/IEkgYW0gZmluZSAuLi51IG9rID8
> metadata,service-offering
> tiny1
> metadata,availability-zone
> zone1
> metadata,local-ipv4
> 10.1.1.45
> metadata,local-hostname
> dd-1
> metadata,public-ipv4
> 10.223.138.68
> metadata,public-hostname
> 10.223.138.68
> metadata,instance-id
> eb6adb2c-576c-4722-bb89-a52f2ad49fb3
> metadata,vm-id
> eb6adb2c-576c-4722-bb89-a52f2ad49fb3
> metadata,public-keys
> none
> metadata,cloud-identifier
> CloudStack-{c9bcecaa-a61a-4192-9df2-4b7c8a9d1294}
> 2013-08-23 15:26:09,983 INFO [vmware.resource.VmwareResource]
> (DirectAgent-162:10.223.58.66) vm_data command on domain router 10.223.58.70
> completed
--
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-4501) system vm not coming up in vmware ESX4.1 after upgrade from 3.0.4 to 4.2
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750816#comment-13750816
]
Chandan Purushothama commented on CLOUDSTACK-4501:
--
As per the uploaded management server logs,I see the following Information:
2013-08-26 06:25:57,156 DEBUG [agent.transport.Request] (consoleproxy-1:null)
Seq 5-493420819: Sending { Cmd , MgmtId: 6819569205345, via: 5, Ver: v1,
Flags: 100011,
[{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/2/207//4f054271-bfde-3461-835b-b6a27a2e7c82.ova","origUrl":"http://nfs1.lab.vmops.com/templates/campo_qa/systemvmtemplate-4.2-vh8.ova","uuid":"f1d1528c-7880-49ad-888e-9b995821a1ea","id":207,"format":"OVA","accountId":2,"checksum":"c1548a3ae84b17a56c40056af6b40378","hvm":true,"displayText":"systemvm-vmware-4.2","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.147.28.7/export/home/shweta/304patch1.vmware.secondary","_role":"Image"}},"name":"207-2-86bbddd0-7412-33c7-9bee-ced34a09d4ff","hypervisorType":"VMware"}},"destTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"origUrl":"http://nfs1.lab.vmops.com/templates/campo_qa/systemvmtemplate-4.2-vh8.ova","uuid":"f1d1528c-7880-49ad-888e-9b995821a1ea","id":207,"format":"OVA","accountId":2,"checksum":"c1548a3ae84b17a56c40056af6b40378","hvm":true,"displayText":"systemvm-vmware-4.2","imageDataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"d9a91dba-343e-38dc-bbe1-69a3f57fd335","id":201,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/shweta/304patch1.vmware.primary","port":2049}},"name":"207-2-86bbddd0-7412-33c7-9bee-ced34a09d4ff","hypervisorType":"VMware"}},"executeInSequence":false,"wait":10800}}]
}
The 4.2 System VM Template URL shows:
http://nfs1.lab.vmops.com/templates/campo_qa/systemvmtemplate-4.2-vh8.ova
As per http://wiki-ccp.citrix.com/display/dev/Campo+SystemVM+templates , that
System VM Template is compatible only with ESX 5.* . For ESXi 4.1, System VM
Template is at
http://download.cloud.com/templates/4.2/systemvmtemplate-4.2-vh7.ova
Thank you,
Chandan.
> system vm not coming up in vmware ESX4.1 after upgrade from 3.0.4 to 4.2
>
>
> Key: CLOUDSTACK-4501
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4501
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Upgrade, VMware
>Affects Versions: 4.2.1
> Environment: upgrade from 3.0.4 patch 1 to 4.2
> with vmware EXI 4.1
>Reporter: shweta agarwal
>Assignee: Min Chen
>Priority: Blocker
> Fix For: 4.2.1
>
> Attachments: cloud-after-upgrade.dmp, cloud.dmp,
> management-server.log.tar.gz
>
>
> did an upgrade from 3.0.4 patch 1to 4.2 with two advance zone one vmware4.2
> and one xen 6.0.2
> Now after upgrade system vm for vmware not coming up . hitting exception :
> 013-08-26 05:36:05,392 ERROR [storage.resource.VmwareStorageProcessor]
> (DirectAgent-15:10.147.40.27) Unable to copy template to primary storage due
> to exception:Exception: javax.xml.ws.soap.SOAPFaultException
> Message:
> Required parameter spec is missing
> while parsing call information for method ImportVApp
> at line 1, column 110
> while parsing SOAP body
> at line 1, column 102
> while parsing SOAP envelope
> at line 1, column 38
> while parsing HTTP request for method importVApp
> on object of type vim.ResourcePool
> at line 1, column 0
> javax.xml.ws.soap.SOAPFaultException:
> Required parameter spec is missing
> while parsing call information for method ImportVApp
> at line 1, column 110
> while parsing SOAP body
> at line 1, column 102
> while parsing SOAP envelope
> at line 1, column 38
> while parsing HTTP request for method importVApp
> on object of type vim.ResourcePool
> at line 1, column 0
> at
> com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178)
> at
> com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119)
> at
> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108)
> at
> com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
> at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
> at sun.proxy.$Proxy91.importVApp(Unknown Source)
> at
> com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.importVmFromOVF(HypervisorHostHelper.java:1321)
> at
> com.cloud.hypervisor.vmware.mo.HostMO.importVmFromOVF(HostMO.java:736)
--
This message is automatically generated by JIRA
[jira] [Commented] (CLOUDSTACK-4501) system vm not coming up in vmware ESX4.1 after upgrade from 3.0.4 to 4.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750802#comment-13750802 ] Min Chen commented on CLOUDSTACK-4501: -- The error indicated that resource pool owned by the hypervisor host is null, which is very abnormal. Chandan has an upgrade setup using ESX 5.0, which does not have this issue. I will need the vmware setup and VCenter/Esx to debug this further. > system vm not coming up in vmware ESX4.1 after upgrade from 3.0.4 to 4.2 > > > Key: CLOUDSTACK-4501 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4501 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade, VMware >Affects Versions: 4.2.1 > Environment: upgrade from 3.0.4 patch 1 to 4.2 > with vmware EXI 4.1 >Reporter: shweta agarwal >Assignee: Min Chen >Priority: Blocker > Fix For: 4.2.1 > > Attachments: cloud-after-upgrade.dmp, cloud.dmp, > management-server.log.tar.gz > > > did an upgrade from 3.0.4 patch 1to 4.2 with two advance zone one vmware4.2 > and one xen 6.0.2 > Now after upgrade system vm for vmware not coming up . hitting exception : > 013-08-26 05:36:05,392 ERROR [storage.resource.VmwareStorageProcessor] > (DirectAgent-15:10.147.40.27) Unable to copy template to primary storage due > to exception:Exception: javax.xml.ws.soap.SOAPFaultException > Message: > Required parameter spec is missing > while parsing call information for method ImportVApp > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method importVApp > on object of type vim.ResourcePool > at line 1, column 0 > javax.xml.ws.soap.SOAPFaultException: > Required parameter spec is missing > while parsing call information for method ImportVApp > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method importVApp > on object of type vim.ResourcePool > at line 1, column 0 > at > com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) > at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107) > at sun.proxy.$Proxy91.importVApp(Unknown Source) > at > com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.importVmFromOVF(HypervisorHostHelper.java:1321) > at > com.cloud.hypervisor.vmware.mo.HostMO.importVmFromOVF(HostMO.java:736) -- 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-4464) Parallel deployment - Vmware - When deploying 30 parallel Vms , Vm fails to get deployed due to "StartCommand failed due to Exception: javax.xml.ws.soap.SOAPFaultE
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750796#comment-13750796 ] Min Chen commented on CLOUDSTACK-4464: -- Custom VM name feature implementation has some problem: 1. custom field "cloud.vm.internal.name" is not initialized in VmwareResource. 2. The way we get vm custom name in HostMO.loadVmCache is ineffective. Kelven has fixed #1 and will check in so that QA can re-try to see if we can reproduce this exception. > Parallel deployment - Vmware - When deploying 30 parallel Vms , Vm fails to > get deployed due to "StartCommand failed due to Exception: > javax.xml.ws.soap.SOAPFaultException" > > > Key: CLOUDSTACK-4464 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4464 > 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: Build from 4.2-forward >Reporter: Sangeetha Hariharan >Assignee: Min Chen >Priority: Blocker > Fix For: 4.2.1 > > Attachments: management-server.log > > > Parallel deployment - Vmware - When deploying 30 parallel Vms , Vm fails to > get deployed due to "StartCommand failed due to Exception: > javax.xml.ws.soap.SOAPFaultException" > Steps to reproduce the problem: > Set up - Advanced zone with 1 Vmware 5.0.0 Esxi host. > Deploy 30 Vms in parallel. > 5 out of 30 vms deployed in parallel , fail due to > "javax.xml.ws.soap.SOAPFaultException". > Management server logs shows the following exception: > 2013-08-22 15:57:22,603 WARN [vmware.resource.VmwareResource] > (DirectAgent-91:10.223.58.66) StartCommand failed due to Exception: > javax.xml.ws.soap.SOAPFaultException > Message: The object has already been deleted or has not been completely > created > javax.xml.ws.soap.SOAPFaultException: The object has already been deleted or > has not been completely created > at > com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) > at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107) > at $Proxy81.retrieveProperties(Unknown Source) > at > com.cloud.hypervisor.vmware.util.VmwareClient.retrieveMoRefProperties(VmwareClient.java:271) > at > com.cloud.hypervisor.vmware.util.VmwareClient.getDynamicProperty(VmwareClient.java:226) > at > com.cloud.hypervisor.vmware.mo.BaseMO.getCustomFieldValue(BaseMO.java:129) > at com.cloud.hypervisor.vmware.mo.HostMO.loadVmCache(HostMO.java:528) > at > com.cloud.hypervisor.vmware.mo.HostMO.findVmOnHyperHost(HostMO.java:488) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2667) > 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$101(ScheduledThreadPoolExecutor.java:165) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) -- 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-4464) Parallel deployment - Vmware - When deploying 30 parallel Vms , Vm fails to get deployed due to "StartCommand failed due to Exception: javax.xml.ws.soap.SOAPFaultExc
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen updated CLOUDSTACK-4464: - Assignee: Kelven Yang (was: Min Chen) > Parallel deployment - Vmware - When deploying 30 parallel Vms , Vm fails to > get deployed due to "StartCommand failed due to Exception: > javax.xml.ws.soap.SOAPFaultException" > > > Key: CLOUDSTACK-4464 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4464 > 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: Build from 4.2-forward >Reporter: Sangeetha Hariharan >Assignee: Kelven Yang >Priority: Blocker > Fix For: 4.2.1 > > Attachments: management-server.log > > > Parallel deployment - Vmware - When deploying 30 parallel Vms , Vm fails to > get deployed due to "StartCommand failed due to Exception: > javax.xml.ws.soap.SOAPFaultException" > Steps to reproduce the problem: > Set up - Advanced zone with 1 Vmware 5.0.0 Esxi host. > Deploy 30 Vms in parallel. > 5 out of 30 vms deployed in parallel , fail due to > "javax.xml.ws.soap.SOAPFaultException". > Management server logs shows the following exception: > 2013-08-22 15:57:22,603 WARN [vmware.resource.VmwareResource] > (DirectAgent-91:10.223.58.66) StartCommand failed due to Exception: > javax.xml.ws.soap.SOAPFaultException > Message: The object has already been deleted or has not been completely > created > javax.xml.ws.soap.SOAPFaultException: The object has already been deleted or > has not been completely created > at > com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) > at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107) > at $Proxy81.retrieveProperties(Unknown Source) > at > com.cloud.hypervisor.vmware.util.VmwareClient.retrieveMoRefProperties(VmwareClient.java:271) > at > com.cloud.hypervisor.vmware.util.VmwareClient.getDynamicProperty(VmwareClient.java:226) > at > com.cloud.hypervisor.vmware.mo.BaseMO.getCustomFieldValue(BaseMO.java:129) > at com.cloud.hypervisor.vmware.mo.HostMO.loadVmCache(HostMO.java:528) > at > com.cloud.hypervisor.vmware.mo.HostMO.findVmOnHyperHost(HostMO.java:488) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2667) > 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$101(ScheduledThreadPoolExecutor.java:165) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) -- 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-4464) Parallel deployment - Vmware - When deploying 30 parallel Vms , Vm fails to get deployed due to "StartCommand failed due to Exception: javax.xml.ws.soap.SOAPFaultEx
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen reassigned CLOUDSTACK-4464: Assignee: Min Chen > Parallel deployment - Vmware - When deploying 30 parallel Vms , Vm fails to > get deployed due to "StartCommand failed due to Exception: > javax.xml.ws.soap.SOAPFaultException" > > > Key: CLOUDSTACK-4464 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4464 > 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: Build from 4.2-forward >Reporter: Sangeetha Hariharan >Assignee: Min Chen >Priority: Blocker > Fix For: 4.2.1 > > Attachments: management-server.log > > > Parallel deployment - Vmware - When deploying 30 parallel Vms , Vm fails to > get deployed due to "StartCommand failed due to Exception: > javax.xml.ws.soap.SOAPFaultException" > Steps to reproduce the problem: > Set up - Advanced zone with 1 Vmware 5.0.0 Esxi host. > Deploy 30 Vms in parallel. > 5 out of 30 vms deployed in parallel , fail due to > "javax.xml.ws.soap.SOAPFaultException". > Management server logs shows the following exception: > 2013-08-22 15:57:22,603 WARN [vmware.resource.VmwareResource] > (DirectAgent-91:10.223.58.66) StartCommand failed due to Exception: > javax.xml.ws.soap.SOAPFaultException > Message: The object has already been deleted or has not been completely > created > javax.xml.ws.soap.SOAPFaultException: The object has already been deleted or > has not been completely created > at > com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) > at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107) > at $Proxy81.retrieveProperties(Unknown Source) > at > com.cloud.hypervisor.vmware.util.VmwareClient.retrieveMoRefProperties(VmwareClient.java:271) > at > com.cloud.hypervisor.vmware.util.VmwareClient.getDynamicProperty(VmwareClient.java:226) > at > com.cloud.hypervisor.vmware.mo.BaseMO.getCustomFieldValue(BaseMO.java:129) > at com.cloud.hypervisor.vmware.mo.HostMO.loadVmCache(HostMO.java:528) > at > com.cloud.hypervisor.vmware.mo.HostMO.findVmOnHyperHost(HostMO.java:488) > at > com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2667) > 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$101(ScheduledThreadPoolExecutor.java:165) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) -- 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-4508) [UI] Nexus VSM details should be mandatory when Switch type Nexus is selected with override traffic labels provided for Public / Guest Traffic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750779#comment-13750779 ] ASF subversion and git services commented on CLOUDSTACK-4508: - Commit 89b54596f8ea455d8b1ff764ecb56e464551d873 in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=89b5459 ] CLOUDSTACK-4508: UI > Infrastructure > clusters > add cluster dialog > hide both required NexusVSM fields and optional NexusVSM fields when hypervisor is not VMware. > [UI] Nexus VSM details should be mandatory when Switch type Nexus is selected > with override traffic labels provided for Public / Guest Traffic > --- > > Key: CLOUDSTACK-4508 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4508 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Brian Federle >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.2.0 > > Attachments: vsmfields.png > > > Observation: > 1. When Nexus global config is set to true , we enable Nexus details to be > provided while adding cluster > 2. With DATACenter to Zone mapping feature, we mandate only Cluster name to > be added with Add Cluster. > But while adding cluster if Swtich type Nexus is selected with override > traffic labels provided for Public / Guest Traffic , we have to make Nexus > details as mandatory . > Nexus VSM details should be mandatory when Switch type Nexus is selected with > override traffic labels provided for Public / Guest Traffic > Reason; If we do not mandate them even though Switch type Nexus is selected > with override traffic labels provided for Public / Guest Traffic , Admin may > miss to provide as its not mandatory and It becomes a useless cluster > without Nexus details. -- 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-4508) [UI] Nexus VSM details should be mandatory when Switch type Nexus is selected with override traffic labels provided for Public / Guest Traffic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750781#comment-13750781 ] ASF subversion and git services commented on CLOUDSTACK-4508: - Commit 29f55d956b86b5c57f45ef416d9eeab34d00888e in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=29f55d9 ] CLOUDSTACK-4508: UI > Infrastructure > clusters > add cluster dialog > make NexusVSM fields required only when Override Traffic is checked AND vSwitch Type is "Cisco Nexus 1000v Distributed Virtual Switch". > [UI] Nexus VSM details should be mandatory when Switch type Nexus is selected > with override traffic labels provided for Public / Guest Traffic > --- > > Key: CLOUDSTACK-4508 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4508 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Brian Federle >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.2.0 > > Attachments: vsmfields.png > > > Observation: > 1. When Nexus global config is set to true , we enable Nexus details to be > provided while adding cluster > 2. With DATACenter to Zone mapping feature, we mandate only Cluster name to > be added with Add Cluster. > But while adding cluster if Swtich type Nexus is selected with override > traffic labels provided for Public / Guest Traffic , we have to make Nexus > details as mandatory . > Nexus VSM details should be mandatory when Switch type Nexus is selected with > override traffic labels provided for Public / Guest Traffic > Reason; If we do not mandate them even though Switch type Nexus is selected > with override traffic labels provided for Public / Guest Traffic , Admin may > miss to provide as its not mandatory and It becomes a useless cluster > without Nexus details. -- 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-4508) [UI] Nexus VSM details should be mandatory when Switch type Nexus is selected with override traffic labels provided for Public / Guest Traffic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750780#comment-13750780 ] ASF subversion and git services commented on CLOUDSTACK-4508: - Commit 9cf510af02f1e90c46189d76820fc1655aed229d in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9cf510a ] CLOUDSTACK-4508: UI > Infrastructure > clusters > add cluster dialog > VSM fields > pass only value of visible VSM fields to API call. > [UI] Nexus VSM details should be mandatory when Switch type Nexus is selected > with override traffic labels provided for Public / Guest Traffic > --- > > Key: CLOUDSTACK-4508 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4508 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Brian Federle >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.2.0 > > Attachments: vsmfields.png > > > Observation: > 1. When Nexus global config is set to true , we enable Nexus details to be > provided while adding cluster > 2. With DATACenter to Zone mapping feature, we mandate only Cluster name to > be added with Add Cluster. > But while adding cluster if Swtich type Nexus is selected with override > traffic labels provided for Public / Guest Traffic , we have to make Nexus > details as mandatory . > Nexus VSM details should be mandatory when Switch type Nexus is selected with > override traffic labels provided for Public / Guest Traffic > Reason; If we do not mandate them even though Switch type Nexus is selected > with override traffic labels provided for Public / Guest Traffic , Admin may > miss to provide as its not mandatory and It becomes a useless cluster > without Nexus details. -- 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-4508) [UI] Nexus VSM details should be mandatory when Switch type Nexus is selected with override traffic labels provided for Public / Guest Traffic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-4508. -- Resolution: Fixed > [UI] Nexus VSM details should be mandatory when Switch type Nexus is selected > with override traffic labels provided for Public / Guest Traffic > --- > > Key: CLOUDSTACK-4508 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4508 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Brian Federle >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.2.0 > > Attachments: vsmfields.png > > > Observation: > 1. When Nexus global config is set to true , we enable Nexus details to be > provided while adding cluster > 2. With DATACenter to Zone mapping feature, we mandate only Cluster name to > be added with Add Cluster. > But while adding cluster if Swtich type Nexus is selected with override > traffic labels provided for Public / Guest Traffic , we have to make Nexus > details as mandatory . > Nexus VSM details should be mandatory when Switch type Nexus is selected with > override traffic labels provided for Public / Guest Traffic > Reason; If we do not mandate them even though Switch type Nexus is selected > with override traffic labels provided for Public / Guest Traffic , Admin may > miss to provide as its not mandatory and It becomes a useless cluster > without Nexus details. -- 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-4508) [UI] Nexus VSM details should be mandatory when Switch type Nexus is selected with override traffic labels provided for Public / Guest Traffic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750775#comment-13750775 ] ASF subversion and git services commented on CLOUDSTACK-4508: - Commit 9fc905383d132d0bb3abfd22109123df7d4355ec in branch refs/heads/4.2-forward from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9fc9053 ] CLOUDSTACK-4508: UI > Infrastructure > clusters > add cluster dialog > VSM fields > pass only value of visible VSM fields to API call. > [UI] Nexus VSM details should be mandatory when Switch type Nexus is selected > with override traffic labels provided for Public / Guest Traffic > --- > > Key: CLOUDSTACK-4508 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4508 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Brian Federle >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.2.0 > > Attachments: vsmfields.png > > > Observation: > 1. When Nexus global config is set to true , we enable Nexus details to be > provided while adding cluster > 2. With DATACenter to Zone mapping feature, we mandate only Cluster name to > be added with Add Cluster. > But while adding cluster if Swtich type Nexus is selected with override > traffic labels provided for Public / Guest Traffic , we have to make Nexus > details as mandatory . > Nexus VSM details should be mandatory when Switch type Nexus is selected with > override traffic labels provided for Public / Guest Traffic > Reason; If we do not mandate them even though Switch type Nexus is selected > with override traffic labels provided for Public / Guest Traffic , Admin may > miss to provide as its not mandatory and It becomes a useless cluster > without Nexus details. -- 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-4508) [UI] Nexus VSM details should be mandatory when Switch type Nexus is selected with override traffic labels provided for Public / Guest Traffic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750776#comment-13750776 ] ASF subversion and git services commented on CLOUDSTACK-4508: - Commit 202e57a772017488293e0fcf183ae762439dbaaa in branch refs/heads/4.2-forward from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=202e57a ] CLOUDSTACK-4508: UI > Infrastructure > clusters > add cluster dialog > make NexusVSM fields required only when Override Traffic is checked AND vSwitch Type is "Cisco Nexus 1000v Distributed Virtual Switch". > [UI] Nexus VSM details should be mandatory when Switch type Nexus is selected > with override traffic labels provided for Public / Guest Traffic > --- > > Key: CLOUDSTACK-4508 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4508 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Brian Federle >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.2.0 > > Attachments: vsmfields.png > > > Observation: > 1. When Nexus global config is set to true , we enable Nexus details to be > provided while adding cluster > 2. With DATACenter to Zone mapping feature, we mandate only Cluster name to > be added with Add Cluster. > But while adding cluster if Swtich type Nexus is selected with override > traffic labels provided for Public / Guest Traffic , we have to make Nexus > details as mandatory . > Nexus VSM details should be mandatory when Switch type Nexus is selected with > override traffic labels provided for Public / Guest Traffic > Reason; If we do not mandate them even though Switch type Nexus is selected > with override traffic labels provided for Public / Guest Traffic , Admin may > miss to provide as its not mandatory and It becomes a useless cluster > without Nexus details. -- 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-4508) [UI] Nexus VSM details should be mandatory when Switch type Nexus is selected with override traffic labels provided for Public / Guest Traffic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750774#comment-13750774 ] ASF subversion and git services commented on CLOUDSTACK-4508: - Commit 5b93398c120edcb8591117cd460020ad3963971e in branch refs/heads/4.2-forward from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5b93398 ] CLOUDSTACK-4508: UI > Infrastructure > clusters > add cluster dialog > hide both required NexusVSM fields and optional NexusVSM fields when hypervisor is not VMware. > [UI] Nexus VSM details should be mandatory when Switch type Nexus is selected > with override traffic labels provided for Public / Guest Traffic > --- > > Key: CLOUDSTACK-4508 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4508 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Brian Federle >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.2.0 > > Attachments: vsmfields.png > > > Observation: > 1. When Nexus global config is set to true , we enable Nexus details to be > provided while adding cluster > 2. With DATACenter to Zone mapping feature, we mandate only Cluster name to > be added with Add Cluster. > But while adding cluster if Swtich type Nexus is selected with override > traffic labels provided for Public / Guest Traffic , we have to make Nexus > details as mandatory . > Nexus VSM details should be mandatory when Switch type Nexus is selected with > override traffic labels provided for Public / Guest Traffic > Reason; If we do not mandate them even though Switch type Nexus is selected > with override traffic labels provided for Public / Guest Traffic , Admin may > miss to provide as its not mandatory and It becomes a useless cluster > without Nexus details. -- 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-4508) [UI] Nexus VSM details should be mandatory when Switch type Nexus is selected with override traffic labels provided for Public / Guest Traffic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750777#comment-13750777 ] ASF subversion and git services commented on CLOUDSTACK-4508: - Commit ef7dbf230a3036cc60b3f0f3d8fe24e03342ae16 in branch refs/heads/4.2-forward from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ef7dbf2 ] CLOUDSTACK-4508 (WIP): Conditionally make VSM fields required If VSM is active, and either traffic overrides are checked, make VSM fields required. ** This creates new VSM fields, with '_req' appended to end of ID. API calls need to be changes to account for this. > [UI] Nexus VSM details should be mandatory when Switch type Nexus is selected > with override traffic labels provided for Public / Guest Traffic > --- > > Key: CLOUDSTACK-4508 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4508 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Brian Federle >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.2.0 > > Attachments: vsmfields.png > > > Observation: > 1. When Nexus global config is set to true , we enable Nexus details to be > provided while adding cluster > 2. With DATACenter to Zone mapping feature, we mandate only Cluster name to > be added with Add Cluster. > But while adding cluster if Swtich type Nexus is selected with override > traffic labels provided for Public / Guest Traffic , we have to make Nexus > details as mandatory . > Nexus VSM details should be mandatory when Switch type Nexus is selected with > override traffic labels provided for Public / Guest Traffic > Reason; If we do not mandate them even though Switch type Nexus is selected > with override traffic labels provided for Public / Guest Traffic , Admin may > miss to provide as its not mandatory and It becomes a useless cluster > without Nexus details. -- 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-4484) Vmware - Not able to fetch userdata from guest Vms using http:///latest/user-data
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
frank zhang reopened CLOUDSTACK-4484:
-
> Vmware - Not able to fetch userdata from guest Vms using
> http:///latest/user-data
> -
>
> Key: CLOUDSTACK-4484
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4484
> 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, 4.2.1
> Environment: Build from 4.2-forward
>Reporter: Sangeetha Hariharan
>Assignee: frank zhang
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: management-server.rar
>
>
> Not able to fetch userdata from guest Vms using
> http:///latest/user-data
> Set up:
> Advanced zone set up with vmware host.
> Steps to reproduce the problem:
> Deploy Vm using user data.
> Vm deployment succeeds.
> From with in the guest Vm , try to access the user data using
> http:///latest/user-data.
> [root@dd-1 ~]# wget http://10.1.1.1/latest/user-data
> --19:58:29-- http://10.1.1.1/latest/user-data
> Connecting to 10.1.1.1:80... connected.
> HTTP request sent, awaiting response... 404 Not Found
> 19:58:29 ERROR 404: Not Found.
> [root@dd-1 ~]#
> On the router , we do not see /var/www/html/userdata/ file.
> In my case guest ip address is 10.1.1.45.
> Note- For all instances which were deployed with no userdata , i see
> /var/www/html/userdata//user-data which are empty. In case
> of Vms deployed with userdata , this file is not being created.
> deployVirtualMachine() api call used:
> 2013-08-23 15:26:07,078 DEBUG [cloud.api.ApiServlet] (catalina-exec-7:null)
> ===START=== 10.215.3.28 -- GET
> command=deployVirtualMachine&zoneId=93368e7c-db1b-4344-8777-2a6e0507c2ba&templateId=dd5c6bb5-602a-4cc4-9328-a26096294cf7&hypervisor=XenServer&serviceOfferingId=e83c2f9a-cbdc-46dc-8743-c76f3c270e99&networkIds=95528f66-22f8-4932-86b6-96b1183d5693&response=json&name=dd-1&displayName=dd-1&userdata=aGVsbG8gaG93IHIgdSA/IEkgYW0gZmluZSAuLi51IG9rID8=&apiKey=2aLe3o6TVY7286zbAJSCqbmhHlhaKU4at9HqUGbLoImE9SzR6Ys6tyWEbkCcDJDH-_Z5RlutsOYhMql2kixZpw&signature=s6Dvwr%2F8vEvqONyJKGmQKETcDVo%3D
> Management server log indicating that the user-data progarmming succeeds:
> 2013-08-23 15:26:08,123 DEBUG [vmware.resource.VmwareResource]
> (DirectAgent-162:10.223.58.66) Use router's private IP for SSH control.
> IP : 10.223.58.70
> 2013-08-23 15:26:08,123 DEBUG [vmware.resource.VmwareResource]
> (DirectAgent-162:10.223.58.66) Run vm_data command on domain router 10.2
> 23.58.70, data: routerIP
> 10.223.58.70
> vmIP
> 10.1.1.45
> userdata,user-data
> aGVsbG8gaG93IHIgdSA/IEkgYW0gZmluZSAuLi51IG9rID8
> metadata,service-offering
> tiny1
> metadata,availability-zone
> zone1
> metadata,local-ipv4
> 10.1.1.45
> metadata,local-hostname
> dd-1
> metadata,public-ipv4
> 10.223.138.68
> metadata,public-hostname
> 10.223.138.68
> metadata,instance-id
> eb6adb2c-576c-4722-bb89-a52f2ad49fb3
> metadata,vm-id
> eb6adb2c-576c-4722-bb89-a52f2ad49fb3
> metadata,public-keys
> none
> metadata,cloud-identifier
> CloudStack-{c9bcecaa-a61a-4192-9df2-4b7c8a9d1294}
> 2013-08-23 15:26:09,983 INFO [vmware.resource.VmwareResource]
> (DirectAgent-162:10.223.58.66) vm_data command on domain router 10.223.58.70
> completed
--
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-4512) [VMWARE] Deployment of User VM Fails on the ESXi host due to CPU Resources unavailability
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chandan Purushothama updated CLOUDSTACK-4512:
-
Summary: [VMWARE] Deployment of User VM Fails on the ESXi host due to CPU
Resources unavailability (was: [VMWARE] Deployment of User VM Fails)
> [VMWARE] Deployment of User VM Fails on the ESXi host due to CPU Resources
> unavailability
> -
>
> Key: CLOUDSTACK-4512
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4512
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, VMware
>Affects Versions: 4.2.0
>Reporter: Chandan Purushothama
>Priority: Blocker
> Fix For: 4.2.1
>
> Attachments: hostd.zip, management-server.zip
>
>
>
> Steps to Reproduce:
>
> 1. Deploy a VM using the default CentOS Template.
> ===
> Observation:
> ===
> Observe that the error complains about CPU Resources on the ESXi host, while
> the host has more than enough CPU Resources to service the VM.
> On the Management Server Log:
> 2013-08-26 16:01:51,808 WARN [vmware.resource.VmwareResource]
> (DirectAgent-151:10.223.57.66) StartCommand failed due to Exception:
> java.lang.RuntimeException
> Message: The available CPU resources in the parent resource pool are
> insufficient for the operation.
> java.lang.RuntimeException: The available CPU resources in the parent
> resource pool are insufficient for the operation.
> at
> com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:378)
> at
> com.cloud.hypervisor.vmware.mo.VirtualMachineMO.powerOn(VirtualMachineMO.java:188)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:3099)
> 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$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-08-26 16:01:51,812 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-151:null) Seq 5-746390325: Response Received:
> 2013-08-26 16:01:51,814 DEBUG [agent.transport.Request]
> (DirectAgent-151:null) Seq 5-746390325: Processing: { Ans: , MgmtId:
> 7471666038533, via: 5, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":27,"name":"i-9-27-VMWARERETEST","bootloader":"HVM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,"maxRam":536870912,"hostName":"Boron-VM-1","arch":"x86_64","os":"CentOS
> 5.3
> (64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"f12649cca76b879d","params":{"rootDiskController":"ide","nicAdapter":"E1000","nestedVirtualizationFlag":"false"},"uuid":"79201226-48cf-43d9-9d20-50a3a8d4c7aa","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"d0467aeb-0774-4aaa-99cd-80a4843d7ffd","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"96bc10ee-70b3-3d20-a60c-c068a024b3a7","id":201,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/chandan/307PB-195-103/primary2","port":2049}},"name":"ROOT-27","size":2147483648,"path":"ROOT-27","volumeId":38,"vmName":"i-9-27-VMWARERETEST","accountId":9,"format":"OVA","id":38,"hypervisorType":"VMware"}},"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":"2ce1f4ba-2420-4060-81bd-da30ef53fcd9","ip":"10.1.1.157","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:74:1d:00:01","dns1":"8.8.8.8","dns2":"8.8.4.4","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://2600","isolationUri":"vlan://2600","isSecurityGroupEnabled":false}]},"result":false,"details":"S
[jira] [Updated] (CLOUDSTACK-4512) [VMWARE] Deployment of User VM Fails on the ESXi host due to CPU Resources unavailability
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chandan Purushothama updated CLOUDSTACK-4512:
-
Priority: Major (was: Blocker)
> [VMWARE] Deployment of User VM Fails on the ESXi host due to CPU Resources
> unavailability
> -
>
> Key: CLOUDSTACK-4512
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4512
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, VMware
>Affects Versions: 4.2.0
>Reporter: Chandan Purushothama
> Fix For: 4.2.1
>
> Attachments: hostd.zip, management-server.zip
>
>
>
> Steps to Reproduce:
>
> 1. Deploy a VM using the default CentOS Template.
> ===
> Observation:
> ===
> Observe that the error complains about CPU Resources on the ESXi host, while
> the host has more than enough CPU Resources to service the VM.
> On the Management Server Log:
> 2013-08-26 16:01:51,808 WARN [vmware.resource.VmwareResource]
> (DirectAgent-151:10.223.57.66) StartCommand failed due to Exception:
> java.lang.RuntimeException
> Message: The available CPU resources in the parent resource pool are
> insufficient for the operation.
> java.lang.RuntimeException: The available CPU resources in the parent
> resource pool are insufficient for the operation.
> at
> com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:378)
> at
> com.cloud.hypervisor.vmware.mo.VirtualMachineMO.powerOn(VirtualMachineMO.java:188)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:3099)
> 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$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-08-26 16:01:51,812 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-151:null) Seq 5-746390325: Response Received:
> 2013-08-26 16:01:51,814 DEBUG [agent.transport.Request]
> (DirectAgent-151:null) Seq 5-746390325: Processing: { Ans: , MgmtId:
> 7471666038533, via: 5, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":27,"name":"i-9-27-VMWARERETEST","bootloader":"HVM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,"maxRam":536870912,"hostName":"Boron-VM-1","arch":"x86_64","os":"CentOS
> 5.3
> (64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"f12649cca76b879d","params":{"rootDiskController":"ide","nicAdapter":"E1000","nestedVirtualizationFlag":"false"},"uuid":"79201226-48cf-43d9-9d20-50a3a8d4c7aa","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"d0467aeb-0774-4aaa-99cd-80a4843d7ffd","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"96bc10ee-70b3-3d20-a60c-c068a024b3a7","id":201,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/chandan/307PB-195-103/primary2","port":2049}},"name":"ROOT-27","size":2147483648,"path":"ROOT-27","volumeId":38,"vmName":"i-9-27-VMWARERETEST","accountId":9,"format":"OVA","id":38,"hypervisorType":"VMware"}},"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":"2ce1f4ba-2420-4060-81bd-da30ef53fcd9","ip":"10.1.1.157","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:74:1d:00:01","dns1":"8.8.8.8","dns2":"8.8.4.4","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://2600","isolationUri":"vlan://2600","isSecurityGroupEnabled":false}]},"result":false,"details":"StartCommand
> failed due to Exception: java.lang.RuntimeException\nMessage: The available
> CPU resources in the parent resource pool are insu
[jira] [Commented] (CLOUDSTACK-4512) [VMWARE] Deployment of User VM Fails on the ESXi host due to CPU Resources unavailability
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750752#comment-13750752
]
Chandan Purushothama commented on CLOUDSTACK-4512:
--
CloudStack management server should have prevented this scenario before failing
on the ESXi host.
> [VMWARE] Deployment of User VM Fails on the ESXi host due to CPU Resources
> unavailability
> -
>
> Key: CLOUDSTACK-4512
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4512
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, VMware
>Affects Versions: 4.2.0
>Reporter: Chandan Purushothama
> Fix For: 4.2.1
>
> Attachments: hostd.zip, management-server.zip
>
>
>
> Steps to Reproduce:
>
> 1. Deploy a VM using the default CentOS Template.
> ===
> Observation:
> ===
> Observe that the error complains about CPU Resources on the ESXi host, while
> the host has more than enough CPU Resources to service the VM.
> On the Management Server Log:
> 2013-08-26 16:01:51,808 WARN [vmware.resource.VmwareResource]
> (DirectAgent-151:10.223.57.66) StartCommand failed due to Exception:
> java.lang.RuntimeException
> Message: The available CPU resources in the parent resource pool are
> insufficient for the operation.
> java.lang.RuntimeException: The available CPU resources in the parent
> resource pool are insufficient for the operation.
> at
> com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:378)
> at
> com.cloud.hypervisor.vmware.mo.VirtualMachineMO.powerOn(VirtualMachineMO.java:188)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:3099)
> 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$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-08-26 16:01:51,812 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-151:null) Seq 5-746390325: Response Received:
> 2013-08-26 16:01:51,814 DEBUG [agent.transport.Request]
> (DirectAgent-151:null) Seq 5-746390325: Processing: { Ans: , MgmtId:
> 7471666038533, via: 5, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":27,"name":"i-9-27-VMWARERETEST","bootloader":"HVM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,"maxRam":536870912,"hostName":"Boron-VM-1","arch":"x86_64","os":"CentOS
> 5.3
> (64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"f12649cca76b879d","params":{"rootDiskController":"ide","nicAdapter":"E1000","nestedVirtualizationFlag":"false"},"uuid":"79201226-48cf-43d9-9d20-50a3a8d4c7aa","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"d0467aeb-0774-4aaa-99cd-80a4843d7ffd","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"96bc10ee-70b3-3d20-a60c-c068a024b3a7","id":201,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/chandan/307PB-195-103/primary2","port":2049}},"name":"ROOT-27","size":2147483648,"path":"ROOT-27","volumeId":38,"vmName":"i-9-27-VMWARERETEST","accountId":9,"format":"OVA","id":38,"hypervisorType":"VMware"}},"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":"2ce1f4ba-2420-4060-81bd-da30ef53fcd9","ip":"10.1.1.157","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:74:1d:00:01","dns1":"8.8.8.8","dns2":"8.8.4.4","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://2600","isolationUri":"vlan://2600","isSecurityGroupEnabled":false}]},"result":false,"details":"StartCommand
[jira] [Commented] (CLOUDSTACK-3405) execute.in.sequence.hypervisor.commands and execute.in.sequence.network.element.commands should be set to "true" by default.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750746#comment-13750746 ] ASF subversion and git services commented on CLOUDSTACK-3405: - Commit 9103984d349927a87b0683048dda2d8004e6854f in branch refs/heads/4.2 from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9103984 ] CLOUDSTACK-3405: execute.in.sequence.hypervisor.commands and execute.in.sequence.network.element.commands should be set to "true" by default. > execute.in.sequence.hypervisor.commands and > execute.in.sequence.network.element.commands should be set to "true" by > default. > > > Key: CLOUDSTACK-3405 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3405 > 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: Build from master >Reporter: Sangeetha Hariharan >Assignee: Min Chen > Fix For: 4.2.0 > > > execute.in.sequence.hypervisor.commands and > execute.in.sequence.network.element.commands should be set to "true" by > default. > Currently , execute.in.sequence.hypervisor.commands and > execute.in.sequence.network.element.commands should be set to "false" 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-4427) UI: Duplicate cluster entries are listed in "Add Host" Box
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750743#comment-13750743
]
ASF subversion and git services commented on CLOUDSTACK-4427:
-
Commit f662e9897ac15bee47e4db0f518deef17ee98f5c in branch refs/heads/4.2 from
[~bfederle]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f662e98 ]
CLOUDSTACK-4427: Fix non-async API call causing duplicate rows.
> UI: Duplicate cluster entries are listed in "Add Host" Box
> --
>
> Key: CLOUDSTACK-4427
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4427
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.2.0
>Reporter: Chandan Purushothama
>Assignee: Brian Federle
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: this_bug_is_caused_by_the_circled_code.jpg,
> UICapture35.png
>
>
> Fire bug shows that ListClusters API got fired twice.
> APIs fired:
> http://10.223.195.103:8080/client/api?command=listClusters&podid=396cf834-8509-4c25-bbf0-b143e6ba4fc1&response=json&sessionkey=N3nXAzdTKo%2FKBXT5x5JBCyHf%2Fmg%3D&_=1377121326648
> { "listclustersresponse" : { "count":2 ,"cluster" : [
> {"id":"75a87c14-f8c0-4552-a117-8a7bb22840f0","name":"10.223.52.61/VMDC/clus1","podid":"396cf834-8509-4c25-bbf0-b143e6ba4fc1","podname":"POD-1","zoneid":"97fb6e7c-25fa-4ce6-bf25-c4d20a1e7a5a","zonename":"ZONE-VMWARERETEST","hypervisortype":"VMware","clustertype":"ExternalManaged","allocationstate":"Enabled","managedstate":"Managed","cpuovercommitratio":"1","memoryovercommitratio":"1"},
>
> {"id":"7b105fba-3b23-44fd-9c1b-32c58a343a52","name":"10.223.52.61/ANOTHERVMDC/clus3","podid":"396cf834-8509-4c25-bbf0-b143e6ba4fc1","podname":"POD-1","zoneid":"97fb6e7c-25fa-4ce6-bf25-c4d20a1e7a5a","zonename":"ZONE-VMWARERETEST","hypervisortype":"VMware","clustertype":"ExternalManaged","allocationstate":"Enabled","managedstate":"Managed","cpuovercommitratio":"1","memoryovercommitratio":"1"}
> ] } }
> http://10.223.195.103:8080/client/api?command=listClusters&podid=396cf834-8509-4c25-bbf0-b143e6ba4fc1&response=json&sessionkey=N3nXAzdTKo%2FKBXT5x5JBCyHf%2Fmg%3D&_=1377121326658
> { "listclustersresponse" : { "count":2 ,"cluster" : [
> {"id":"75a87c14-f8c0-4552-a117-8a7bb22840f0","name":"10.223.52.61/VMDC/clus1","podid":"396cf834-8509-4c25-bbf0-b143e6ba4fc1","podname":"POD-1","zoneid":"97fb6e7c-25fa-4ce6-bf25-c4d20a1e7a5a","zonename":"ZONE-VMWARERETEST","hypervisortype":"VMware","clustertype":"ExternalManaged","allocationstate":"Enabled","managedstate":"Managed","cpuovercommitratio":"1","memoryovercommitratio":"1"},
>
> {"id":"7b105fba-3b23-44fd-9c1b-32c58a343a52","name":"10.223.52.61/ANOTHERVMDC/clus3","podid":"396cf834-8509-4c25-bbf0-b143e6ba4fc1","podname":"POD-1","zoneid":"97fb6e7c-25fa-4ce6-bf25-c4d20a1e7a5a","zonename":"ZONE-VMWARERETEST","hypervisortype":"VMware","clustertype":"ExternalManaged","allocationstate":"Enabled","managedstate":"Managed","cpuovercommitratio":"1","memoryovercommitratio":"1"}
> ] } }
--
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-4495) systemVM template URL is pointing to old template location in upgrade file
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750741#comment-13750741 ] ASF subversion and git services commented on CLOUDSTACK-4495: - Commit 208507a42a4db252dc3d7cf299c146315423a071 in branch refs/heads/4.2 from [~sanjay.tripathi] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=208507a ] CLOUDSTACK-4495: systemVM template URL is pointing to old template location in upgrade file. SystemVM template URL for XenServer hypervisor is pointing to old template location in the Upgrade410to420.java file. > systemVM template URL is pointing to old template location in upgrade file > -- > > Key: CLOUDSTACK-4495 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4495 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.2.0 >Reporter: Sanjay Tripathi >Assignee: Sanjay Tripathi >Priority: Critical > Fix For: 4.2.1 > > > SystemVM template URL for XenServer hypervisor is pointing to old template > location in the Upgrade410to420.java file. -- 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-4334) Document storage image store plugin framework
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750742#comment-13750742 ] ASF subversion and git services commented on CLOUDSTACK-4334: - Commit 171681b6a4c2b6338ff351330d7d119daaddb65c in branch refs/heads/4.2 from [~jessica.tomec...@citrix.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=171681b ] CLOUDSTACK-4334. DOC. Fix missing license header. > Document storage image store plugin framework > - > > Key: CLOUDSTACK-4334 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4334 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.2.0 >Reporter: Jessica Tomechak >Assignee: Sudha Ponnaganti > Fix For: 4.2.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] [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=13750740#comment-13750740
]
ASF subversion and git services commented on CLOUDSTACK-4492:
-
Commit ad6fc9f680618701b84ccd66f12b06928ad6b718 in branch refs/heads/4.2 from
[~edison]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ad6fc9f ]
CLOUDSTACK-4492: DB upgrade for volume state, from UploadOp to Uploaded
> [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
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: cloud.dmp, 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(AsyncJob
[jira] [Updated] (CLOUDSTACK-4512) [VMWARE] Deployment of User VM Fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chandan Purushothama updated CLOUDSTACK-4512:
-
Attachment: hostd.zip
management-server.zip
> [VMWARE] Deployment of User VM Fails
>
>
> Key: CLOUDSTACK-4512
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4512
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, VMware
>Affects Versions: 4.2.0
>Reporter: Chandan Purushothama
>Priority: Blocker
> Fix For: 4.2.1
>
> Attachments: hostd.zip, management-server.zip
>
>
>
> Steps to Reproduce:
>
> 1. Deploy a VM using the default CentOS Template.
> ===
> Observation:
> ===
> Observe that the error complains about CPU Resources on the ESXi host, while
> the host has more than enough CPU Resources to service the VM.
> On the Management Server Log:
> 2013-08-26 16:01:51,808 WARN [vmware.resource.VmwareResource]
> (DirectAgent-151:10.223.57.66) StartCommand failed due to Exception:
> java.lang.RuntimeException
> Message: The available CPU resources in the parent resource pool are
> insufficient for the operation.
> java.lang.RuntimeException: The available CPU resources in the parent
> resource pool are insufficient for the operation.
> at
> com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:378)
> at
> com.cloud.hypervisor.vmware.mo.VirtualMachineMO.powerOn(VirtualMachineMO.java:188)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:3099)
> 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$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-08-26 16:01:51,812 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-151:null) Seq 5-746390325: Response Received:
> 2013-08-26 16:01:51,814 DEBUG [agent.transport.Request]
> (DirectAgent-151:null) Seq 5-746390325: Processing: { Ans: , MgmtId:
> 7471666038533, via: 5, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":27,"name":"i-9-27-VMWARERETEST","bootloader":"HVM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,"maxRam":536870912,"hostName":"Boron-VM-1","arch":"x86_64","os":"CentOS
> 5.3
> (64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"f12649cca76b879d","params":{"rootDiskController":"ide","nicAdapter":"E1000","nestedVirtualizationFlag":"false"},"uuid":"79201226-48cf-43d9-9d20-50a3a8d4c7aa","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"d0467aeb-0774-4aaa-99cd-80a4843d7ffd","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"96bc10ee-70b3-3d20-a60c-c068a024b3a7","id":201,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/chandan/307PB-195-103/primary2","port":2049}},"name":"ROOT-27","size":2147483648,"path":"ROOT-27","volumeId":38,"vmName":"i-9-27-VMWARERETEST","accountId":9,"format":"OVA","id":38,"hypervisorType":"VMware"}},"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":"2ce1f4ba-2420-4060-81bd-da30ef53fcd9","ip":"10.1.1.157","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:74:1d:00:01","dns1":"8.8.8.8","dns2":"8.8.4.4","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://2600","isolationUri":"vlan://2600","isSecurityGroupEnabled":false}]},"result":false,"details":"StartCommand
> failed due to Exception: java.lang.RuntimeException\nMessage: The available
> CPU resources in the parent resource pool are insufficient for the
> operation.\n","wait":0}}] }
>
[jira] [Created] (CLOUDSTACK-4512) [VMWARE] Deployment of User VM Fails
Chandan Purushothama created CLOUDSTACK-4512:
Summary: [VMWARE] Deployment of User VM Fails
Key: CLOUDSTACK-4512
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4512
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server, VMware
Affects Versions: 4.2.0
Reporter: Chandan Purushothama
Priority: Blocker
Fix For: 4.2.1
Steps to Reproduce:
1. Deploy a VM using the default CentOS Template.
===
Observation:
===
Observe that the error complains about CPU Resources on the ESXi host, while
the host has more than enough CPU Resources to service the VM.
On the Management Server Log:
2013-08-26 16:01:51,808 WARN [vmware.resource.VmwareResource]
(DirectAgent-151:10.223.57.66) StartCommand failed due to Exception:
java.lang.RuntimeException
Message: The available CPU resources in the parent resource pool are
insufficient for the operation.
java.lang.RuntimeException: The available CPU resources in the parent resource
pool are insufficient for the operation.
at
com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:378)
at
com.cloud.hypervisor.vmware.mo.VirtualMachineMO.powerOn(VirtualMachineMO.java:188)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:3099)
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$101(ScheduledThreadPoolExecutor.java:165)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
2013-08-26 16:01:51,812 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-151:null) Seq 5-746390325: Response Received:
2013-08-26 16:01:51,814 DEBUG [agent.transport.Request] (DirectAgent-151:null)
Seq 5-746390325: Processing: { Ans: , MgmtId: 7471666038533, via: 5, Ver: v1,
Flags: 10,
[{"com.cloud.agent.api.StartAnswer":{"vm":{"id":27,"name":"i-9-27-VMWARERETEST","bootloader":"HVM","type":"User","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,"maxRam":536870912,"hostName":"Boron-VM-1","arch":"x86_64","os":"CentOS
5.3
(64-bit)","bootArgs":"","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"f12649cca76b879d","params":{"rootDiskController":"ide","nicAdapter":"E1000","nestedVirtualizationFlag":"false"},"uuid":"79201226-48cf-43d9-9d20-50a3a8d4c7aa","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"d0467aeb-0774-4aaa-99cd-80a4843d7ffd","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"96bc10ee-70b3-3d20-a60c-c068a024b3a7","id":201,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/chandan/307PB-195-103/primary2","port":2049}},"name":"ROOT-27","size":2147483648,"path":"ROOT-27","volumeId":38,"vmName":"i-9-27-VMWARERETEST","accountId":9,"format":"OVA","id":38,"hypervisorType":"VMware"}},"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":"2ce1f4ba-2420-4060-81bd-da30ef53fcd9","ip":"10.1.1.157","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:74:1d:00:01","dns1":"8.8.8.8","dns2":"8.8.4.4","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://2600","isolationUri":"vlan://2600","isSecurityGroupEnabled":false}]},"result":false,"details":"StartCommand
failed due to Exception: java.lang.RuntimeException\nMessage: The available
CPU resources in the parent resource pool are insufficient for the
operation.\n","wait":0}}] }
2013-08-26 16:01:51,814 DEBUG [agent.transport.Request]
(Job-Executor-25:job-125 = [ bb63450c-35de-4f1f-b81b-1ac3482f ]) Seq
5-746390325: Received: { Ans: , MgmtId: 7471666038533, via: 5, Ver: v1, Flags:
10, { StartAnswer } }
2013-08-26 16:01:51,820 INFO [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-25:job-125 = [ bb63450c-35de-4f1f-b81b-1ac3482f ]) Unable to
start VM
[jira] [Commented] (CLOUDSTACK-772) Document VMware vNetwork Distributed Virtual Switch support in CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750694#comment-13750694 ] ASF subversion and git services commented on CLOUDSTACK-772: Commit 2cfb4136be70db5ab30608cd8d43bd4aad97ea81 in branch refs/heads/master from [~jessica.tomec...@citrix.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2cfb413 ] CLOUDSTACK-772. DOC. Fix typo to fix doc build. > Document VMware vNetwork Distributed Virtual Switch support in CloudStack > - > > Key: CLOUDSTACK-772 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-772 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Reporter: Radhika Nair >Assignee: Radhika Nair > Fix For: 4.2.0 > > > Create documentation for VMware vNetwork Distributed Virtual Switch support > in CloudStack -- 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-3405) execute.in.sequence.hypervisor.commands and execute.in.sequence.network.element.commands should be set to "true" by default.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-3405. -- Resolution: Fixed > execute.in.sequence.hypervisor.commands and > execute.in.sequence.network.element.commands should be set to "true" by > default. > > > Key: CLOUDSTACK-3405 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3405 > 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: Build from master >Reporter: Sangeetha Hariharan >Assignee: Min Chen > Fix For: 4.2.0 > > > execute.in.sequence.hypervisor.commands and > execute.in.sequence.network.element.commands should be set to "true" by > default. > Currently , execute.in.sequence.hypervisor.commands and > execute.in.sequence.network.element.commands should be set to "false" 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-3405) execute.in.sequence.hypervisor.commands and execute.in.sequence.network.element.commands should be set to "true" by default.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750690#comment-13750690 ] Min Chen commented on CLOUDSTACK-3405: -- We need more testing done for parallel deployment on Vmware, so for 4.2, we default this to true. > execute.in.sequence.hypervisor.commands and > execute.in.sequence.network.element.commands should be set to "true" by > default. > > > Key: CLOUDSTACK-3405 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3405 > 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: Build from master >Reporter: Sangeetha Hariharan >Assignee: Min Chen > Fix For: 4.2.0 > > > execute.in.sequence.hypervisor.commands and > execute.in.sequence.network.element.commands should be set to "true" by > default. > Currently , execute.in.sequence.hypervisor.commands and > execute.in.sequence.network.element.commands should be set to "false" 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] [Resolved] (CLOUDSTACK-4489) [object_store_refactor] First snapshot on disk after upgrade is not incremental if there was a snapshot taken before upgrade for the disk
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su resolved CLOUDSTACK-4489. --- Resolution: Won't Fix 4.2 code will track the snapshot on primary storage, if there is no snapshot created on primary storage, then the next snapshot will be full snapshot. In pre-4.2 code, we didn't track that, and the snapshot may already been destroyed on primary storage, so it's difficult for me to restore the behavior. And as a bonus, after upgrade, the snapshot is always been full snapshot, we can make sure, no matter what happened during the upgrade procedure, the snapshot will always work, as it's always start from full snapshot after upgrade to 4.2. > [object_store_refactor] First snapshot on disk after upgrade is not > incremental if there was a snapshot taken before upgrade for the disk > - > > Key: CLOUDSTACK-4489 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4489 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot, Storage Controller, XenServer >Affects Versions: 4.2.1 > Environment: Build is from commit > :a6bf80216466ada185de7e04d3e64be4e25c11a7 > Upgrade from 3.0.6 to 4.2 > Cluster: Xen >Reporter: Sanjeev N >Assignee: edison su >Priority: Critical > Fix For: 4.2.1 > > Attachments: cloud.dmp, management-server.log, > management-server.log.2013-08-23.gz > > > First snapshot on disk after upgrade is not incremental if there was a > snapshot taken before upgrade for the disk > Steps to reproduce: > === > 1.Install 3.0.6 and bring up CS with xen cluster > 2.Deploy guest vm with both root and data disk > 3.Create a snapshot on data disk > 4.Upgrade to 4.2 > 5.After upgrade again take snapshot on the same data disk > Result: > == > Snapshot created was full snapshot. > Observations: > === > In snapshot_store_ref table parent_snapshot_id was set to 0. Created another > snapshot on the same data disk for which parent_snapshot_id was set to the > snapshot_id taken after the upgrade. > mysql> select id,snapshot_id,volume_id,parent_snapshot_id,install_path from > snapshot_store_ref where volume_id=11 and store_role='Image'; > +-+-+---++-+ > | id | snapshot_id | volume_id | parent_snapshot_id | install_path > | > +-+-+---++-+ > | 1 | 1 |11 | 0 | > snapshots/2/11/eb957385-d67e-4338-8f24-831a392dba0e | > | 227 | 115 |11 | 0 | > snapshots/2/11/2900f706-c6b8-4ab0-ab5a-a3a4b40d709b | > | 229 | 116 |11 |115 | > snapshots/2/11/2900f706-c6b8-4ab0-ab5a-a3a4b40d709b | > +-+-+---++-+ > snapshot_id 1 was taken before upgrade, 115 and 116 were taken after upgrade. > For snapshot 115 parent_snapshot_id is 0 and snapshot size is same as > snapshot 1 i.e. it's a full snapshot. > 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] [Commented] (CLOUDSTACK-4258) [Automation] test case from TestRouterServices failed with unexpected result in list network call
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750691#comment-13750691 ] Sheng Yang commented on CLOUDSTACK-4258: It's passed in the recent run. > [Automation] test case from TestRouterServices failed with unexpected result > in list network call > -- > > Key: CLOUDSTACK-4258 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4258 > 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 >Priority: Critical > Fix For: 4.2.0 > > > Below test cases failed from TestRouterServices suite, test cases failed > while calling ListNetwork > integration.component.test_routers.TestRouterServices.test_01_AdvancedZoneRouterServices > integration.component.test_routers.TestRouterServices.test_02_NetworkGarbageCollection > integration.component.test_routers.TestRouterServices.test_03_RouterStartOnVmDeploy > Observed below error in automation log > Error Message > Check list network response for network state > >> begin captured logging << > testclient.testcase.TestRouterServices: DEBUG: Router ID: > 85fadb9d-37d2-4508-888e-e6110f9c0e41 & Router state: Running > testclient.testcase.TestRouterServices: DEBUG: Network ID: > f6f192c0-0842-4532-aeb9-71bf2e1bf4b9 & Network state: Implemented > - >> 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_routers.py", line > 237, in test_01_AdvancedZoneRouterServices > "Check list network response for network state" > File "/usr/local/lib/python2.7/unittest/case.py", line 784, in assertIn > self.fail(self._formatMessage(msg, standardMsg)) > File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail > raise self.failureException(msg) > Check list network response for network state > >> begin captured logging << > testclient.testcase.TestRouterServices: DEBUG: Router ID: > 85fadb9d-37d2-4508-888e-e6110f9c0e41 & Router state: Running > testclient.testcase.TestRouterServices: DEBUG: Network ID: > f6f192c0-0842-4532-aeb9-71bf2e1bf4b9 & Network state: Implemented > - >> 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] [Commented] (CLOUDSTACK-3405) execute.in.sequence.hypervisor.commands and execute.in.sequence.network.element.commands should be set to "true" by default.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750684#comment-13750684 ] ASF subversion and git services commented on CLOUDSTACK-3405: - Commit 5a11fe77bae1966c986e541e484ae3d56485d78f in branch refs/heads/4.2-forward from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5a11fe7 ] CLOUDSTACK-3405: execute.in.sequence.hypervisor.commands and execute.in.sequence.network.element.commands should be set to "true" by default. > execute.in.sequence.hypervisor.commands and > execute.in.sequence.network.element.commands should be set to "true" by > default. > > > Key: CLOUDSTACK-3405 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3405 > 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: Build from master >Reporter: Sangeetha Hariharan >Assignee: Min Chen > Fix For: 4.2.0 > > > execute.in.sequence.hypervisor.commands and > execute.in.sequence.network.element.commands should be set to "true" by > default. > Currently , execute.in.sequence.hypervisor.commands and > execute.in.sequence.network.element.commands should be set to "false" 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-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=13750679#comment-13750679
]
ASF subversion and git services commented on CLOUDSTACK-4492:
-
Commit ad6fc9f680618701b84ccd66f12b06928ad6b718 in branch
refs/heads/4.2-forward from [~edison]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ad6fc9f ]
CLOUDSTACK-4492: DB upgrade for volume state, from UploadOp to Uploaded
> [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
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: cloud.dmp, 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(
[jira] [Resolved] (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
]
edison su resolved CLOUDSTACK-4492.
---
Resolution: Fixed
> [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
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: cloud.dmp, 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:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWork
[jira] [Commented] (CLOUDSTACK-4495) systemVM template URL is pointing to old template location in upgrade file
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750678#comment-13750678 ] ASF subversion and git services commented on CLOUDSTACK-4495: - Commit 208507a42a4db252dc3d7cf299c146315423a071 in branch refs/heads/4.2-forward from [~sanjay.tripathi] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=208507a ] CLOUDSTACK-4495: systemVM template URL is pointing to old template location in upgrade file. SystemVM template URL for XenServer hypervisor is pointing to old template location in the Upgrade410to420.java file. > systemVM template URL is pointing to old template location in upgrade file > -- > > Key: CLOUDSTACK-4495 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4495 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.2.0 >Reporter: Sanjay Tripathi >Assignee: Sanjay Tripathi >Priority: Critical > Fix For: 4.2.1 > > > SystemVM template URL for XenServer hypervisor is pointing to old template > location in the Upgrade410to420.java file. -- 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] [Comment Edited] (CLOUDSTACK-4482) getVMPassword() API call does not retuen password for Vms that are deployed with password enabled templates.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750662#comment-13750662
]
Prachi Damle edited comment on CLOUDSTACK-4482 at 8/26/13 10:32 PM:
There is a workaround for this usecase where one can call the
resetPasswordForVirtualMachine API and get a new password to access the VM.
I think this issue seems to be a Major, since a workaround exists.
was (Author: prachidamle):
There is a workaround for this usecase where one can call the
resetPasswordForVirtualMachine API and get a new password to access the VM.
Reducing the priority to Major.
> getVMPassword() API call does not retuen password for Vms that are deployed
> with password enabled templates.
>
>
> Key: CLOUDSTACK-4482
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4482
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
>Reporter: Sangeetha Hariharan
>Priority: Critical
> Fix For: 4.2.1
>
>
> Steps to reproduce the problem:
> Provision a VM with password enabled templates.
> Use getVMPassword() to get the password for this use VM.
> We get the following error message - "No password for VM with specified id
> found"
> http://10.223.131.169:8080/client/api?command=getVMPassword&id=a974c8ab-e779-4de6-a1d1-26ac5c9c39cd&response=json&sessionkey=ciq%2FaAgf6%2Br1BiuGeyU2%2Fjic23s%3D&_=1377293331315
> { "getvmpasswordresponse" :
> {"uuidList":[{"uuid":"a974c8ab-e779-4de6-a1d1-26ac5c9c39cd","description":"vmId"}],"errorcode":431,"cserrorcode":4350,"errortext":"No
> password for VM with specified id found."} }
> Management server logs:
> 2013-08-23 14:18:03,240 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null)
> ===START=== 10.215.3.9 -- GET
> command=getVMPassword&id=a974c8ab-e779-4de6-a1d1-26ac5c9c39cd&response=json&sessionkey=ciq%2FaAgf6%2Br1BiuGeyU2%2Fjic23s%3D&_=1377293331315
> 2013-08-23 14:18:03,251 DEBUG [cloud.user.AccountManagerImpl]
> (catalina-exec-25:null) Access to VM[User|pass-2] granted to
> Acct[806a5eea-3861-4224-bfc4-59f0fc46a1af-tan] by
> DomainChecker_EnhancerByCloudStack_be12c9e3
> 2013-08-23 14:18:03,253 INFO [cloud.api.ApiServer] (catalina-exec-25:null)
> No password for VM with specified id found.
> 2013-08-23 14:18:03,253 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null)
> ===END=== 10.215.3.9 -- GET
> command=getVMPassword&id=a974c8ab-e779-4de6-a1d1-26ac5c9c39cd&response=json&sessionkey=ciq%2FaAgf6%2Br1BiuGeyU2%2Fjic23s%3D&_=1377293331315
> Response when deploying the Vm has password field which I am able to use
> successfully to log into the Vm:
> |
> org.apache.cloudstack.api.response.UserVmResponse/virtualmachine/{"id":"a974c8ab-e779-4de6-a1d1-26ac5c9c39cd","name":"pass-2","displayname":"pass-2","account":"tan","domainid":"1e424c36-0b6e-11e3-bc0b-06715428","domain":"ROOT","created":"2013-08-23T11:17:08-0700","state":"Running","haenable":false,"zoneid":"93368e7c-db1b-4344-8777-2a6e0507c2ba","zonename":"zone1","templateid":"dd5c6bb5-602a-4cc4-9328-a26096294cf7","templatename":"password-template","templatedisplaytext":"password-template","passwordenabled":true,"serviceofferingid":"e83c2f9a-cbdc-46dc-8743-c76f3c270e99","serviceofferingname":"tiny1","cpunumber":1,"cpuspeed":50,"memory":124,"guestosid":"1e4bb9ce-0b6e-11e3-bc0b-06715428","rootdeviceid":0,"rootdevicetype":"ROOT","securitygroup":[],"password":"rJ3aivjax","nic":[{"id":"e9ed3363-1573-4f59-b2cb-a32c8a3c023d","networkid":"95528f66-22f8-4932-86b6-96b1183d5693","networkname":"tan","netmask":"255.255.255.0","gateway":"10.1.1.1","ipaddress":"10.1.1.149","isolationuri":"vlan://2309","broadcasturi":"vlan://2309","traffictype":"Guest","type":"Isolated","isdefault":true,"macaddress":"02:00:4e:ad:00:28"}],"hypervisor":"VMware","tags":[],"affinitygroup":[],"displayvm":true,"isdynamicallyscalable":false,"jobid":"850e7775-be7a-4216-b515-dcfc320b2260","jobstatus":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] [Commented] (CLOUDSTACK-4482) getVMPassword() API call does not retuen password for Vms that are deployed with password enabled templates.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750662#comment-13750662
]
Prachi Damle commented on CLOUDSTACK-4482:
--
There is a workaround for this usecase where one can call the
resetPasswordForVirtualMachine API and get a new password to access the VM.
Reducing the priority to Major.
> getVMPassword() API call does not retuen password for Vms that are deployed
> with password enabled templates.
>
>
> Key: CLOUDSTACK-4482
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4482
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
>Reporter: Sangeetha Hariharan
>Priority: Critical
> Fix For: 4.2.1
>
>
> Steps to reproduce the problem:
> Provision a VM with password enabled templates.
> Use getVMPassword() to get the password for this use VM.
> We get the following error message - "No password for VM with specified id
> found"
> http://10.223.131.169:8080/client/api?command=getVMPassword&id=a974c8ab-e779-4de6-a1d1-26ac5c9c39cd&response=json&sessionkey=ciq%2FaAgf6%2Br1BiuGeyU2%2Fjic23s%3D&_=1377293331315
> { "getvmpasswordresponse" :
> {"uuidList":[{"uuid":"a974c8ab-e779-4de6-a1d1-26ac5c9c39cd","description":"vmId"}],"errorcode":431,"cserrorcode":4350,"errortext":"No
> password for VM with specified id found."} }
> Management server logs:
> 2013-08-23 14:18:03,240 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null)
> ===START=== 10.215.3.9 -- GET
> command=getVMPassword&id=a974c8ab-e779-4de6-a1d1-26ac5c9c39cd&response=json&sessionkey=ciq%2FaAgf6%2Br1BiuGeyU2%2Fjic23s%3D&_=1377293331315
> 2013-08-23 14:18:03,251 DEBUG [cloud.user.AccountManagerImpl]
> (catalina-exec-25:null) Access to VM[User|pass-2] granted to
> Acct[806a5eea-3861-4224-bfc4-59f0fc46a1af-tan] by
> DomainChecker_EnhancerByCloudStack_be12c9e3
> 2013-08-23 14:18:03,253 INFO [cloud.api.ApiServer] (catalina-exec-25:null)
> No password for VM with specified id found.
> 2013-08-23 14:18:03,253 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null)
> ===END=== 10.215.3.9 -- GET
> command=getVMPassword&id=a974c8ab-e779-4de6-a1d1-26ac5c9c39cd&response=json&sessionkey=ciq%2FaAgf6%2Br1BiuGeyU2%2Fjic23s%3D&_=1377293331315
> Response when deploying the Vm has password field which I am able to use
> successfully to log into the Vm:
> |
> org.apache.cloudstack.api.response.UserVmResponse/virtualmachine/{"id":"a974c8ab-e779-4de6-a1d1-26ac5c9c39cd","name":"pass-2","displayname":"pass-2","account":"tan","domainid":"1e424c36-0b6e-11e3-bc0b-06715428","domain":"ROOT","created":"2013-08-23T11:17:08-0700","state":"Running","haenable":false,"zoneid":"93368e7c-db1b-4344-8777-2a6e0507c2ba","zonename":"zone1","templateid":"dd5c6bb5-602a-4cc4-9328-a26096294cf7","templatename":"password-template","templatedisplaytext":"password-template","passwordenabled":true,"serviceofferingid":"e83c2f9a-cbdc-46dc-8743-c76f3c270e99","serviceofferingname":"tiny1","cpunumber":1,"cpuspeed":50,"memory":124,"guestosid":"1e4bb9ce-0b6e-11e3-bc0b-06715428","rootdeviceid":0,"rootdevicetype":"ROOT","securitygroup":[],"password":"rJ3aivjax","nic":[{"id":"e9ed3363-1573-4f59-b2cb-a32c8a3c023d","networkid":"95528f66-22f8-4932-86b6-96b1183d5693","networkname":"tan","netmask":"255.255.255.0","gateway":"10.1.1.1","ipaddress":"10.1.1.149","isolationuri":"vlan://2309","broadcasturi":"vlan://2309","traffictype":"Guest","type":"Isolated","isdefault":true,"macaddress":"02:00:4e:ad:00:28"}],"hypervisor":"VMware","tags":[],"affinitygroup":[],"displayvm":true,"isdynamicallyscalable":false,"jobid":"850e7775-be7a-4216-b515-dcfc320b2260","jobstatus":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] [Commented] (CLOUDSTACK-4334) Document storage image store plugin framework
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750664#comment-13750664 ] ASF subversion and git services commented on CLOUDSTACK-4334: - Commit 171681b6a4c2b6338ff351330d7d119daaddb65c in branch refs/heads/4.2-forward from [~jessica.tomec...@citrix.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=171681b ] CLOUDSTACK-4334. DOC. Fix missing license header. > Document storage image store plugin framework > - > > Key: CLOUDSTACK-4334 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4334 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.2.0 >Reporter: Jessica Tomechak >Assignee: Sudha Ponnaganti > Fix For: 4.2.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] [Updated] (CLOUDSTACK-4482) getVMPassword() API call does not retuen password for Vms that are deployed with password enabled templates.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prachi Damle updated CLOUDSTACK-4482:
-
Priority: Major (was: Critical)
> getVMPassword() API call does not retuen password for Vms that are deployed
> with password enabled templates.
>
>
> Key: CLOUDSTACK-4482
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4482
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
>Reporter: Sangeetha Hariharan
> Fix For: 4.2.1
>
>
> Steps to reproduce the problem:
> Provision a VM with password enabled templates.
> Use getVMPassword() to get the password for this use VM.
> We get the following error message - "No password for VM with specified id
> found"
> http://10.223.131.169:8080/client/api?command=getVMPassword&id=a974c8ab-e779-4de6-a1d1-26ac5c9c39cd&response=json&sessionkey=ciq%2FaAgf6%2Br1BiuGeyU2%2Fjic23s%3D&_=1377293331315
> { "getvmpasswordresponse" :
> {"uuidList":[{"uuid":"a974c8ab-e779-4de6-a1d1-26ac5c9c39cd","description":"vmId"}],"errorcode":431,"cserrorcode":4350,"errortext":"No
> password for VM with specified id found."} }
> Management server logs:
> 2013-08-23 14:18:03,240 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null)
> ===START=== 10.215.3.9 -- GET
> command=getVMPassword&id=a974c8ab-e779-4de6-a1d1-26ac5c9c39cd&response=json&sessionkey=ciq%2FaAgf6%2Br1BiuGeyU2%2Fjic23s%3D&_=1377293331315
> 2013-08-23 14:18:03,251 DEBUG [cloud.user.AccountManagerImpl]
> (catalina-exec-25:null) Access to VM[User|pass-2] granted to
> Acct[806a5eea-3861-4224-bfc4-59f0fc46a1af-tan] by
> DomainChecker_EnhancerByCloudStack_be12c9e3
> 2013-08-23 14:18:03,253 INFO [cloud.api.ApiServer] (catalina-exec-25:null)
> No password for VM with specified id found.
> 2013-08-23 14:18:03,253 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null)
> ===END=== 10.215.3.9 -- GET
> command=getVMPassword&id=a974c8ab-e779-4de6-a1d1-26ac5c9c39cd&response=json&sessionkey=ciq%2FaAgf6%2Br1BiuGeyU2%2Fjic23s%3D&_=1377293331315
> Response when deploying the Vm has password field which I am able to use
> successfully to log into the Vm:
> |
> org.apache.cloudstack.api.response.UserVmResponse/virtualmachine/{"id":"a974c8ab-e779-4de6-a1d1-26ac5c9c39cd","name":"pass-2","displayname":"pass-2","account":"tan","domainid":"1e424c36-0b6e-11e3-bc0b-06715428","domain":"ROOT","created":"2013-08-23T11:17:08-0700","state":"Running","haenable":false,"zoneid":"93368e7c-db1b-4344-8777-2a6e0507c2ba","zonename":"zone1","templateid":"dd5c6bb5-602a-4cc4-9328-a26096294cf7","templatename":"password-template","templatedisplaytext":"password-template","passwordenabled":true,"serviceofferingid":"e83c2f9a-cbdc-46dc-8743-c76f3c270e99","serviceofferingname":"tiny1","cpunumber":1,"cpuspeed":50,"memory":124,"guestosid":"1e4bb9ce-0b6e-11e3-bc0b-06715428","rootdeviceid":0,"rootdevicetype":"ROOT","securitygroup":[],"password":"rJ3aivjax","nic":[{"id":"e9ed3363-1573-4f59-b2cb-a32c8a3c023d","networkid":"95528f66-22f8-4932-86b6-96b1183d5693","networkname":"tan","netmask":"255.255.255.0","gateway":"10.1.1.1","ipaddress":"10.1.1.149","isolationuri":"vlan://2309","broadcasturi":"vlan://2309","traffictype":"Guest","type":"Isolated","isdefault":true,"macaddress":"02:00:4e:ad:00:28"}],"hypervisor":"VMware","tags":[],"affinitygroup":[],"displayvm":true,"isdynamicallyscalable":false,"jobid":"850e7775-be7a-4216-b515-dcfc320b2260","jobstatus":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] [Assigned] (CLOUDSTACK-3405) execute.in.sequence.hypervisor.commands and execute.in.sequence.network.element.commands should be set to "true" by default.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen reassigned CLOUDSTACK-3405: Assignee: Min Chen > execute.in.sequence.hypervisor.commands and > execute.in.sequence.network.element.commands should be set to "true" by > default. > > > Key: CLOUDSTACK-3405 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3405 > 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: Build from master >Reporter: Sangeetha Hariharan >Assignee: Min Chen > Fix For: 4.2.0 > > > execute.in.sequence.hypervisor.commands and > execute.in.sequence.network.element.commands should be set to "true" by > default. > Currently , execute.in.sequence.hypervisor.commands and > execute.in.sequence.network.element.commands should be set to "false" 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] [Resolved] (CLOUDSTACK-4484) Vmware - Not able to fetch userdata from guest Vms using http:///latest/user-data
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
frank zhang resolved CLOUDSTACK-4484.
-
Resolution: Invalid
the userdata you use is invalid encoded.
try:
userdata='aGFkZmFhZGZhZHNm' which is encoded from 'hadfaadfadsf'
> Vmware - Not able to fetch userdata from guest Vms using
> http:///latest/user-data
> -
>
> Key: CLOUDSTACK-4484
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4484
> 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, 4.2.1
> Environment: Build from 4.2-forward
>Reporter: Sangeetha Hariharan
>Assignee: frank zhang
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: management-server.rar
>
>
> Not able to fetch userdata from guest Vms using
> http:///latest/user-data
> Set up:
> Advanced zone set up with vmware host.
> Steps to reproduce the problem:
> Deploy Vm using user data.
> Vm deployment succeeds.
> From with in the guest Vm , try to access the user data using
> http:///latest/user-data.
> [root@dd-1 ~]# wget http://10.1.1.1/latest/user-data
> --19:58:29-- http://10.1.1.1/latest/user-data
> Connecting to 10.1.1.1:80... connected.
> HTTP request sent, awaiting response... 404 Not Found
> 19:58:29 ERROR 404: Not Found.
> [root@dd-1 ~]#
> On the router , we do not see /var/www/html/userdata/ file.
> In my case guest ip address is 10.1.1.45.
> Note- For all instances which were deployed with no userdata , i see
> /var/www/html/userdata//user-data which are empty. In case
> of Vms deployed with userdata , this file is not being created.
> deployVirtualMachine() api call used:
> 2013-08-23 15:26:07,078 DEBUG [cloud.api.ApiServlet] (catalina-exec-7:null)
> ===START=== 10.215.3.28 -- GET
> command=deployVirtualMachine&zoneId=93368e7c-db1b-4344-8777-2a6e0507c2ba&templateId=dd5c6bb5-602a-4cc4-9328-a26096294cf7&hypervisor=XenServer&serviceOfferingId=e83c2f9a-cbdc-46dc-8743-c76f3c270e99&networkIds=95528f66-22f8-4932-86b6-96b1183d5693&response=json&name=dd-1&displayName=dd-1&userdata=aGVsbG8gaG93IHIgdSA/IEkgYW0gZmluZSAuLi51IG9rID8=&apiKey=2aLe3o6TVY7286zbAJSCqbmhHlhaKU4at9HqUGbLoImE9SzR6Ys6tyWEbkCcDJDH-_Z5RlutsOYhMql2kixZpw&signature=s6Dvwr%2F8vEvqONyJKGmQKETcDVo%3D
> Management server log indicating that the user-data progarmming succeeds:
> 2013-08-23 15:26:08,123 DEBUG [vmware.resource.VmwareResource]
> (DirectAgent-162:10.223.58.66) Use router's private IP for SSH control.
> IP : 10.223.58.70
> 2013-08-23 15:26:08,123 DEBUG [vmware.resource.VmwareResource]
> (DirectAgent-162:10.223.58.66) Run vm_data command on domain router 10.2
> 23.58.70, data: routerIP
> 10.223.58.70
> vmIP
> 10.1.1.45
> userdata,user-data
> aGVsbG8gaG93IHIgdSA/IEkgYW0gZmluZSAuLi51IG9rID8
> metadata,service-offering
> tiny1
> metadata,availability-zone
> zone1
> metadata,local-ipv4
> 10.1.1.45
> metadata,local-hostname
> dd-1
> metadata,public-ipv4
> 10.223.138.68
> metadata,public-hostname
> 10.223.138.68
> metadata,instance-id
> eb6adb2c-576c-4722-bb89-a52f2ad49fb3
> metadata,vm-id
> eb6adb2c-576c-4722-bb89-a52f2ad49fb3
> metadata,public-keys
> none
> metadata,cloud-identifier
> CloudStack-{c9bcecaa-a61a-4192-9df2-4b7c8a9d1294}
> 2013-08-23 15:26:09,983 INFO [vmware.resource.VmwareResource]
> (DirectAgent-162:10.223.58.66) vm_data command on domain router 10.223.58.70
> completed
--
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-4334) Document storage image store plugin framework
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750661#comment-13750661 ] ASF subversion and git services commented on CLOUDSTACK-4334: - Commit fd67ea2073acb4b53024a951c1c09a6ec8f87e16 in branch refs/heads/master from [~jessica.tomec...@citrix.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fd67ea2 ] CLOUDSTACK-4334. DOC. Fix missing license header. > Document storage image store plugin framework > - > > Key: CLOUDSTACK-4334 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4334 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.2.0 >Reporter: Jessica Tomechak >Assignee: Sudha Ponnaganti > Fix For: 4.2.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] [Reopened] (CLOUDSTACK-3405) execute.in.sequence.hypervisor.commands and execute.in.sequence.network.element.commands should be set to "true" by default.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeetha Hariharan reopened CLOUDSTACK-3405: - Assignee: (was: Alena Prokharchyk) > execute.in.sequence.hypervisor.commands and > execute.in.sequence.network.element.commands should be set to "true" by > default. > > > Key: CLOUDSTACK-3405 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3405 > 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: Build from master >Reporter: Sangeetha Hariharan > Fix For: 4.2.0 > > > execute.in.sequence.hypervisor.commands and > execute.in.sequence.network.element.commands should be set to "true" by > default. > Currently , execute.in.sequence.hypervisor.commands and > execute.in.sequence.network.element.commands should be set to "false" 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] [Assigned] (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 reassigned CLOUDSTACK-4475: - Assignee: edison su (was: Rajesh Battala) > [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 >Priority: Critical > 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 | DefaultPri
[jira] [Resolved] (CLOUDSTACK-4503) hitting java npe in snapshot creation after upgrade from 3.0.4 to 4.2
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
edison su resolved CLOUDSTACK-4503.
---
Resolution: Fixed
> hitting java npe in snapshot creation after upgrade from 3.0.4 to 4.2
> -
>
> Key: CLOUDSTACK-4503
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4503
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Snapshot, Upgrade, XenServer
>Affects Versions: 4.2.1
> Environment: upgraded from 3.0.4 to 4.2 with one xen 6.0.2 host
>Reporter: shweta agarwal
>Priority: Blocker
> Fix For: 4.2.1
>
> Attachments: freshsetup_Logs_DB.rar, snapshot.tar.gz
>
>
> creating snapshot is failing with exception :
> 2013-08-26 06:44:05,729 DEBUG [agent.transport.Request]
> (Job-Executor-6:job-206 = [ 2e2ffe00-c590-41ef-a63e-7dac6046e53c ]) Seq
> 1-519045381: Received: { Ans: , MgmtId: 6819569205345, via: 1, Ver: v1,
> Flags: 10, { CopyCmdAnswer } }
> 2013-08-26 06:44:05,749 DEBUG [storage.snapshot.SnapshotServiceImpl]
> (Job-Executor-6:job-206 = [ 2e2ffe00-c590-41ef-a63e-7dac6046e53c ]) Failed to
> update snapshot state
> java.lang.NullPointerException
> at
> org.apache.cloudstack.storage.snapshot.SnapshotObject.processEvent(SnapshotObject.java:268)
> at
> org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.copySnapshotAsyncCallback(SnapshotServiceImpl.java:316)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at
> org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.dispatch(AsyncCallbackDispatcher.java:142)
> at
> org.apache.cloudstack.framework.async.InplaceAsyncCallbackDriver.performCompletionCallback(InplaceAsyncCallbackDriver.java:26)
> at
> org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.complete(AsyncCallbackDispatcher.java:120)
> at
> org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:423)
> at
> org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:55)
> at
> org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:266)
> at
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:138)
> at
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:264)
> at
> com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:1013)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1281)
> at
> com.cloud.storage.VolumeManagerImpl.takeSnapshot(VolumeManagerImpl.java:2703)
> at
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd.execute(CreateSnapshotCmd.java:170)
> 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-26 06:44:05,753 DEBUG [storage.snapshot.SnapshotManagerImpl]
> (Job-Executor-6:job-206 = [ 2e2ffe00-c590-41ef-a63e-7dac6046e53c ]) Failed to
> create snapshot
> com.cloud.utils.exception.CloudRuntimeException:
> java.lang.NullPointerException
> at
> org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:281)
> at
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:138)
> at
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:264)
> at
> com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotMana
[jira] [Commented] (CLOUDSTACK-4427) UI: Duplicate cluster entries are listed in "Add Host" Box
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13750631#comment-13750631
]
ASF subversion and git services commented on CLOUDSTACK-4427:
-
Commit f662e9897ac15bee47e4db0f518deef17ee98f5c in branch
refs/heads/4.2-forward from [~bfederle]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f662e98 ]
CLOUDSTACK-4427: Fix non-async API call causing duplicate rows.
> UI: Duplicate cluster entries are listed in "Add Host" Box
> --
>
> Key: CLOUDSTACK-4427
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4427
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.2.0
>Reporter: Chandan Purushothama
>Assignee: Brian Federle
>Priority: Critical
> Fix For: 4.2.1
>
> Attachments: this_bug_is_caused_by_the_circled_code.jpg,
> UICapture35.png
>
>
> Fire bug shows that ListClusters API got fired twice.
> APIs fired:
> http://10.223.195.103:8080/client/api?command=listClusters&podid=396cf834-8509-4c25-bbf0-b143e6ba4fc1&response=json&sessionkey=N3nXAzdTKo%2FKBXT5x5JBCyHf%2Fmg%3D&_=1377121326648
> { "listclustersresponse" : { "count":2 ,"cluster" : [
> {"id":"75a87c14-f8c0-4552-a117-8a7bb22840f0","name":"10.223.52.61/VMDC/clus1","podid":"396cf834-8509-4c25-bbf0-b143e6ba4fc1","podname":"POD-1","zoneid":"97fb6e7c-25fa-4ce6-bf25-c4d20a1e7a5a","zonename":"ZONE-VMWARERETEST","hypervisortype":"VMware","clustertype":"ExternalManaged","allocationstate":"Enabled","managedstate":"Managed","cpuovercommitratio":"1","memoryovercommitratio":"1"},
>
> {"id":"7b105fba-3b23-44fd-9c1b-32c58a343a52","name":"10.223.52.61/ANOTHERVMDC/clus3","podid":"396cf834-8509-4c25-bbf0-b143e6ba4fc1","podname":"POD-1","zoneid":"97fb6e7c-25fa-4ce6-bf25-c4d20a1e7a5a","zonename":"ZONE-VMWARERETEST","hypervisortype":"VMware","clustertype":"ExternalManaged","allocationstate":"Enabled","managedstate":"Managed","cpuovercommitratio":"1","memoryovercommitratio":"1"}
> ] } }
> http://10.223.195.103:8080/client/api?command=listClusters&podid=396cf834-8509-4c25-bbf0-b143e6ba4fc1&response=json&sessionkey=N3nXAzdTKo%2FKBXT5x5JBCyHf%2Fmg%3D&_=1377121326658
> { "listclustersresponse" : { "count":2 ,"cluster" : [
> {"id":"75a87c14-f8c0-4552-a117-8a7bb22840f0","name":"10.223.52.61/VMDC/clus1","podid":"396cf834-8509-4c25-bbf0-b143e6ba4fc1","podname":"POD-1","zoneid":"97fb6e7c-25fa-4ce6-bf25-c4d20a1e7a5a","zonename":"ZONE-VMWARERETEST","hypervisortype":"VMware","clustertype":"ExternalManaged","allocationstate":"Enabled","managedstate":"Managed","cpuovercommitratio":"1","memoryovercommitratio":"1"},
>
> {"id":"7b105fba-3b23-44fd-9c1b-32c58a343a52","name":"10.223.52.61/ANOTHERVMDC/clus3","podid":"396cf834-8509-4c25-bbf0-b143e6ba4fc1","podname":"POD-1","zoneid":"97fb6e7c-25fa-4ce6-bf25-c4d20a1e7a5a","zonename":"ZONE-VMWARERETEST","hypervisortype":"VMware","clustertype":"ExternalManaged","allocationstate":"Enabled","managedstate":"Managed","cpuovercommitratio":"1","memoryovercommitratio":"1"}
> ] } }
--
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
