[jira] [Commented] (CLOUDSTACK-4308) [Snapshot][KVM] UI - KVM.snapshot.enabled=FALSE UI should not allow setup recurring snapshot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13739092#comment-13739092 ] Fang Wang commented on CLOUDSTACK-4308: --- commit f9090e45aecbfaf02c9feb3a393d6c63e38ff503 Author: Fang Wang Date: Tue Aug 13 17:15:33 2013 -0700 cloudstack-4308 Add API listCapabilities for KVMSnapshotEnabled so that UI can use it for recurring snapshot. (4.2 branch) > [Snapshot][KVM] UI - KVM.snapshot.enabled=FALSE UI should not allow setup > recurring snapshot > - > > Key: CLOUDSTACK-4308 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4308 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.2.0 > Environment: 4.2 MS, hypervisor: KVM, >Reporter: Fang Wang >Assignee: Fang Wang > Fix For: 4.2.0 > > > KVM: the default snapshot setting for 4.2 MS has a global flag: > kvm.snapshot.enabled > default value is set to FALSE. > With this default setting, we should disable the recurring snapshot from UI. -- 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-4308) [Snapshot][KVM] UI - KVM.snapshot.enabled=FALSE UI should not allow setup recurring snapshot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13739091#comment-13739091 ] Fang Wang commented on CLOUDSTACK-4308: --- post the fix to review board: https://reviews.apache.org/r/13547/ > [Snapshot][KVM] UI - KVM.snapshot.enabled=FALSE UI should not allow setup > recurring snapshot > - > > Key: CLOUDSTACK-4308 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4308 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.2.0 > Environment: 4.2 MS, hypervisor: KVM, >Reporter: Fang Wang >Assignee: Fang Wang > Fix For: 4.2.0 > > > KVM: the default snapshot setting for 4.2 MS has a global flag: > kvm.snapshot.enabled > default value is set to FALSE. > With this default setting, we should disable the recurring snapshot from UI. -- 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-4308) [Snapshot][KVM] UI - KVM.snapshot.enabled=FALSE UI should not allow setup recurring snapshot
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13738957#comment-13738957
]
Fang Wang commented on CLOUDSTACK-4308:
---
Fix has 2 parts: API and UI.
1. Volume page (where "recurring snapshot" option and "take snapshot" option
are) is available to regular user.
However, regular user doesn't have access to listConfigurations API.
So, regular user is unable to get "KVM.snapshot.enabled" through
listConfigurations API.
API developer needs to extend listCapabilities API (which regular user has
access to) to return "KVM.snapshot.enabled".
Extend the current API return to:
to:
http://10.216.133.43:8080/client/api?command=listCapabilities&response=json&sessionkey=2mqGb2%2FZIiIIkC3oVK%2FkrgxgxZU%3D&_=1375225192771
{
"listcapabilitiesresponse": {
"capability": {
"securitygroupsenabled": false,
"cloudstackversion": "4.2.0-SNAPSHOT",
"userpublictemplateenabled": true,
"supportELB": "false",
"projectinviterequired": false,
"allowusercreateprojects": true,
"customdiskofferingmaxsize": 1024,
"KVMsnapshotenabled": true/false <=== new property
}
}
}
> [Snapshot][KVM] UI - KVM.snapshot.enabled=FALSE UI should not allow setup
> recurring snapshot
> -
>
> Key: CLOUDSTACK-4308
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4308
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.2.0
> Environment: 4.2 MS, hypervisor: KVM,
>Reporter: Fang Wang
>Assignee: Fang Wang
> Fix For: 4.2.0
>
>
> KVM: the default snapshot setting for 4.2 MS has a global flag:
> kvm.snapshot.enabled
> default value is set to FALSE.
> With this default setting, we should disable the recurring snapshot from UI.
--
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-4308) [Snapshot][KVM] UI - KVM.snapshot.enabled=FALSE UI should not allow setup recurring snapshot
Fang Wang created CLOUDSTACK-4308: - Summary: [Snapshot][KVM] UI - KVM.snapshot.enabled=FALSE UI should not allow setup recurring snapshot Key: CLOUDSTACK-4308 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4308 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.0 Environment: 4.2 MS, hypervisor: KVM, Reporter: Fang Wang Assignee: Fang Wang Fix For: 4.2.0 KVM: the default snapshot setting for 4.2 MS has a global flag: kvm.snapshot.enabled default value is set to FALSE. With this default setting, we should disable the recurring snapshot from UI. -- 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-3759) [Automation] Attach volume on a vm deployed with startvm=False fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fang Wang updated CLOUDSTACK-3759:
--
Status: Ready To Review (was: In Progress)
> [Automation] Attach volume on a vm deployed with startvm=False fails
>
>
> Key: CLOUDSTACK-3759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3759
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.2.0
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: attachvolumefail.log
>
>
> Test cases failed from integration.component.test_stopped_vm.TestDeployVM
> Steps to reproduce
> --
> Step 1 : Create a VM from command line with start state is false
> Step 2 : Create a volume and attach the volume to stopped VM
> Actual Result
> Volume attachment failed;
> Observed below error automation test log
>
> attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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_stopped_vm.py",
> line 611, in test_06_deploy_startvm_attach_detach
> self.fail("Attach volume failed!")
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> Attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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] [Resolved] (CLOUDSTACK-3759) [Automation] Attach volume on a vm deployed with startvm=False fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fang Wang resolved CLOUDSTACK-3759.
---
Resolution: Fixed
Resolve it
> [Automation] Attach volume on a vm deployed with startvm=False fails
>
>
> Key: CLOUDSTACK-3759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3759
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.2.0
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: attachvolumefail.log
>
>
> Test cases failed from integration.component.test_stopped_vm.TestDeployVM
> Steps to reproduce
> --
> Step 1 : Create a VM from command line with start state is false
> Step 2 : Create a volume and attach the volume to stopped VM
> Actual Result
> Volume attachment failed;
> Observed below error automation test log
>
> attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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_stopped_vm.py",
> line 611, in test_06_deploy_startvm_attach_detach
> self.fail("Attach volume failed!")
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> Attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> end captured logging << -
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-3759) [Automation] Attach volume on a vm deployed with startvm=False fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fang Wang closed CLOUDSTACK-3759.
-
Resolution: Fixed
fix needs to be reviewed:
https://reviews.apache.org/r/13459/
For 4.2,
commit 29ebc2baae80f0bd908ad852db102147faa71ca0
Author: Fang Wang
Date: Fri Aug 9 17:40:28 2013 -0700
CLOUDSTACK-3759 Delayed creating the volume in this case. iOTherwise the
null hostID caused bug.
> [Automation] Attach volume on a vm deployed with startvm=False fails
>
>
> Key: CLOUDSTACK-3759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3759
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.2.0
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: attachvolumefail.log
>
>
> Test cases failed from integration.component.test_stopped_vm.TestDeployVM
> Steps to reproduce
> --
> Step 1 : Create a VM from command line with start state is false
> Step 2 : Create a volume and attach the volume to stopped VM
> Actual Result
> Volume attachment failed;
> Observed below error automation test log
>
> attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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_stopped_vm.py",
> line 611, in test_06_deploy_startvm_attach_detach
> self.fail("Attach volume failed!")
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> Attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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] [Reopened] (CLOUDSTACK-3759) [Automation] Attach volume on a vm deployed with startvm=False fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fang Wang reopened CLOUDSTACK-3759:
---
> [Automation] Attach volume on a vm deployed with startvm=False fails
>
>
> Key: CLOUDSTACK-3759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3759
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.2.0
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: attachvolumefail.log
>
>
> Test cases failed from integration.component.test_stopped_vm.TestDeployVM
> Steps to reproduce
> --
> Step 1 : Create a VM from command line with start state is false
> Step 2 : Create a volume and attach the volume to stopped VM
> Actual Result
> Volume attachment failed;
> Observed below error automation test log
>
> attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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_stopped_vm.py",
> line 611, in test_06_deploy_startvm_attach_detach
> self.fail("Attach volume failed!")
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> Attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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-3759) [Automation] Attach volume on a vm deployed with startvm=False fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13735553#comment-13735553
]
Fang Wang commented on CLOUDSTACK-3759:
---
>From the log, it does not seem to be realted to the VM state for this latest
>error.
What is your environment? Can you provide more set up info? I'll see if we can
reproduce it
> [Automation] Attach volume on a vm deployed with startvm=False fails
>
>
> Key: CLOUDSTACK-3759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3759
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.2.0
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: attachvolumefail.log
>
>
> Test cases failed from integration.component.test_stopped_vm.TestDeployVM
> Steps to reproduce
> --
> Step 1 : Create a VM from command line with start state is false
> Step 2 : Create a volume and attach the volume to stopped VM
> Actual Result
> Volume attachment failed;
> Observed below error automation test log
>
> attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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_stopped_vm.py",
> line 611, in test_06_deploy_startvm_attach_detach
> self.fail("Attach volume failed!")
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> Attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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-3759) [Automation] Attach volume on a vm deployed with startvm=False fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13735494#comment-13735494
]
Fang Wang commented on CLOUDSTACK-3759:
---
RAyees, what is the error msg and log you encountered? Thanks.
> [Automation] Attach volume on a vm deployed with startvm=False fails
>
>
> Key: CLOUDSTACK-3759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3759
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.2.0
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: attachvolumefail.log
>
>
> Test cases failed from integration.component.test_stopped_vm.TestDeployVM
> Steps to reproduce
> --
> Step 1 : Create a VM from command line with start state is false
> Step 2 : Create a volume and attach the volume to stopped VM
> Actual Result
> Volume attachment failed;
> Observed below error automation test log
>
> attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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_stopped_vm.py",
> line 611, in test_06_deploy_startvm_attach_detach
> self.fail("Attach volume failed!")
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> Attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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] [Comment Edited] (CLOUDSTACK-3759) [Automation] Attach volume on a vm deployed with startvm=False fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13735494#comment-13735494
]
Fang Wang edited comment on CLOUDSTACK-3759 at 8/9/13 11:23 PM:
Rayees, what is the error msg and log you encountered? Thanks.
was (Author: fangw):
RAyees, what is the error msg and log you encountered? Thanks.
> [Automation] Attach volume on a vm deployed with startvm=False fails
>
>
> Key: CLOUDSTACK-3759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3759
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.2.0
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: attachvolumefail.log
>
>
> Test cases failed from integration.component.test_stopped_vm.TestDeployVM
> Steps to reproduce
> --
> Step 1 : Create a VM from command line with start state is false
> Step 2 : Create a volume and attach the volume to stopped VM
> Actual Result
> Volume attachment failed;
> Observed below error automation test log
>
> attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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_stopped_vm.py",
> line 611, in test_06_deploy_startvm_attach_detach
> self.fail("Attach volume failed!")
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> Attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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] [Updated] (CLOUDSTACK-3788) [KVM] Weekly Snapshot got stuck in "Allocated State"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fang Wang updated CLOUDSTACK-3788: -- Priority: Major (was: Critical) > [KVM] Weekly Snapshot got stuck in "Allocated State" > > > Key: CLOUDSTACK-3788 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3788 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot >Affects Versions: 4.2.0 >Reporter: Chandan Purushothama >Assignee: Fang Wang > Fix For: 4.2.0 > > Attachments: management-server.log.2013-07-23.gz, > mysql_cloudstack_dump.zip > > > Weekly Snapshot stuck in Allocated State: > mysql> select * from snapshots where name like > "Atoms-VM-1_ROOT-6_20130723235146"; > ++++---+---+--+---+--+--+--+---+--++-+-++--++--+-+-+---+ > | id | data_center_id | account_id | domain_id | volume_id | disk_offering_id > | status| path | name | uuid >| snapshot_type | type_description | size | created >| removed | backup_snap_id | swift_id | sechost_id | prev_snap_id | > hypervisor_type | version | s3_id | > ++++---+---+--+---+--+--+--+---+--++-+-++--++--+-+-+---+ > | 24 | 1 | 3 | 1 | 6 |1 > | Destroyed | NULL | Atoms-VM-1_ROOT-6_20130723235146 | > 08a0d2aa-9635-41cd-ba54-5367303bceac | 3 | HOURLY | > 147456 | 2013-07-23 23:51:46 | NULL| NULL | NULL | > NULL | NULL | KVM | 2.2 | NULL | > | 25 | 1 | 3 | 1 | 6 |1 > | Allocated | NULL | Atoms-VM-1_ROOT-6_20130723235146 | > 1e24a056-be38-4b55-845b-a5672b9fa93c | 5 | WEEKLY | > 147456 | 2013-07-23 23:51:46 | NULL| NULL | NULL | > NULL | NULL | KVM | 2.2 | NULL | > ++++---+---+--+---+--+--+--+---+--++-+-++--++--+-+-+---+ > 2 rows in set (0.04 sec) > Attached Management Server logs and cloud database dump -- 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-3788) [KVM] Weekly Snapshot got stuck in "Allocated State"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13732885#comment-13732885 ] Fang Wang commented on CLOUDSTACK-3788: --- I changed the priority of the bug. We could have a better error reporting mechanism for this type of operation. > [KVM] Weekly Snapshot got stuck in "Allocated State" > > > Key: CLOUDSTACK-3788 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3788 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot >Affects Versions: 4.2.0 >Reporter: Chandan Purushothama >Assignee: Fang Wang > Fix For: 4.2.0 > > Attachments: management-server.log.2013-07-23.gz, > mysql_cloudstack_dump.zip > > > Weekly Snapshot stuck in Allocated State: > mysql> select * from snapshots where name like > "Atoms-VM-1_ROOT-6_20130723235146"; > ++++---+---+--+---+--+--+--+---+--++-+-++--++--+-+-+---+ > | id | data_center_id | account_id | domain_id | volume_id | disk_offering_id > | status| path | name | uuid >| snapshot_type | type_description | size | created >| removed | backup_snap_id | swift_id | sechost_id | prev_snap_id | > hypervisor_type | version | s3_id | > ++++---+---+--+---+--+--+--+---+--++-+-++--++--+-+-+---+ > | 24 | 1 | 3 | 1 | 6 |1 > | Destroyed | NULL | Atoms-VM-1_ROOT-6_20130723235146 | > 08a0d2aa-9635-41cd-ba54-5367303bceac | 3 | HOURLY | > 147456 | 2013-07-23 23:51:46 | NULL| NULL | NULL | > NULL | NULL | KVM | 2.2 | NULL | > | 25 | 1 | 3 | 1 | 6 |1 > | Allocated | NULL | Atoms-VM-1_ROOT-6_20130723235146 | > 1e24a056-be38-4b55-845b-a5672b9fa93c | 5 | WEEKLY | > 147456 | 2013-07-23 23:51:46 | NULL| NULL | NULL | > NULL | NULL | KVM | 2.2 | NULL | > ++++---+---+--+---+--+--+--+---+--++-+-++--++--+-+-+---+ > 2 rows in set (0.04 sec) > Attached Management Server logs and cloud database dump -- 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-3788) [KVM] Weekly Snapshot got stuck in "Allocated State"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fang Wang resolved CLOUDSTACK-3788. --- Resolution: Won't Fix The hourly snapshot and weekly snapshot occurred at the same time, which caused one stuck. We would not recommend users to take hourly and weekly snapshots at the same time. We could have better error reporting scheme for this operation. But it is not a critical issue. > [KVM] Weekly Snapshot got stuck in "Allocated State" > > > Key: CLOUDSTACK-3788 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3788 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot >Affects Versions: 4.2.0 >Reporter: Chandan Purushothama >Assignee: Fang Wang >Priority: Critical > Fix For: 4.2.0 > > Attachments: management-server.log.2013-07-23.gz, > mysql_cloudstack_dump.zip > > > Weekly Snapshot stuck in Allocated State: > mysql> select * from snapshots where name like > "Atoms-VM-1_ROOT-6_20130723235146"; > ++++---+---+--+---+--+--+--+---+--++-+-++--++--+-+-+---+ > | id | data_center_id | account_id | domain_id | volume_id | disk_offering_id > | status| path | name | uuid >| snapshot_type | type_description | size | created >| removed | backup_snap_id | swift_id | sechost_id | prev_snap_id | > hypervisor_type | version | s3_id | > ++++---+---+--+---+--+--+--+---+--++-+-++--++--+-+-+---+ > | 24 | 1 | 3 | 1 | 6 |1 > | Destroyed | NULL | Atoms-VM-1_ROOT-6_20130723235146 | > 08a0d2aa-9635-41cd-ba54-5367303bceac | 3 | HOURLY | > 147456 | 2013-07-23 23:51:46 | NULL| NULL | NULL | > NULL | NULL | KVM | 2.2 | NULL | > | 25 | 1 | 3 | 1 | 6 |1 > | Allocated | NULL | Atoms-VM-1_ROOT-6_20130723235146 | > 1e24a056-be38-4b55-845b-a5672b9fa93c | 5 | WEEKLY | > 147456 | 2013-07-23 23:51:46 | NULL| NULL | NULL | > NULL | NULL | KVM | 2.2 | NULL | > ++++---+---+--+---+--+--+--+---+--++-+-++--++--+-+-+---+ > 2 rows in set (0.04 sec) > Attached Management Server logs and cloud database dump -- 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-3788) [KVM] Weekly Snapshot got stuck in "Allocated State"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13732840#comment-13732840
]
Fang Wang edited comment on CLOUDSTACK-3788 at 8/7/13 10:25 PM:
Can you reproduce it now?
I looked at the log and the source code, the source code at
XenserverSnapshotStrategy.java, and SnapshotManagerImpl.java
got changed.
>From the log, there is a snpshot got stuck at deleteSnapshot command. It shows
>destroyed in DB, but it failed:
2013-07-23 18:52:33,744 DEBUG [agent.transport.Request] (Job-Executor-66:job-95
= [ 669b527b-d1ab-4726-9a22-8363aff5dee4 ]) Seq 3-1039532574: Sending { Cmd ,
MgmtId: 7471666038533, via: 3, Ver: v1, Flags: 100011,
[{"org.apache.cloudstack.storage.command.DeleteCommand":{"data":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"snapshots/3/6/28192719-5193-4e92-8b0a-92b66b1f4a6a","volume":{"uuid":"031802d8-c10a-4038-9acf-b86eba54b647","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"ef3dea99-0a1b-35b9-87ec-d8cabe7ed9c1","id":1,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/chandan/campocr-195-103/primarykvm","port":2049}},"name":"ROOT-6","size":147456,"path":"906ec8f4-e625-4943-aedd-aff3444150b9","volumeId":6,"vmName":"i-3-6-JULYLAST","accountId":3,"format":"QCOW2","id":6},"dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.223.110.232/export/home/chandan/campocr-195-103/secondary/","_role":"Image"}},"vmName":"i-3-6-JULYLAST","name":"Atoms-VM-1_ROOT-6_20130723235146","hypervisorType":"KVM","id":24}},"wait":0}}]
}
2013-07-23 18:52:34,741 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-5:null) SeqA 2-11944: Processing Seq 2-11944: { Cmd ,
MgmtId: -1, via: 2, Ver: v1, Flags: 11,
[{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
\"connections\": []\n}","wait":0}}] }
2013-07-23 18:52:34,745 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-5:null) SeqA 2-11944: Sending Seq 2-11944: { Ans: ,
MgmtId: 7471666038533, via: 2, Ver: v1, Flags: 100010,
[{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
2013-07-23 18:52:37,598 DEBUG [agent.transport.Request]
(AgentManager-Handler-3:null) Seq 3-1039532574: Processing: { Ans: , MgmtId:
7471666038533, via: 3, Ver: v1, Flags: 10,
[{"com.cloud.agent.api.Answer":{"result":true,"wait":0}}] }
2013-07-23 18:52:37,598 DEBUG [agent.transport.Request] (Job-Executor-66:job-95
= [ 669b527b-d1ab-4726-9a22-8363aff5dee4 ]) Seq 3-1039532574: Received: { Ans:
, MgmtId: 7471666038533, via: 3, Ver: v1, Flags: 10, { Answer } }
2013-07-23 18:52:37,611 DEBUG [storage.snapshot.XenserverSnapshotStrategy]
(Job-Executor-66:job-95 = [ 669b527b-d1ab-4726-9a22-8363aff5dee4 ]) Failed to
delete snapshot:
java.lang.NullPointerException
at
org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.deleteSnapshot(XenserverSnapshotStrategy.java:192)
at
com.cloud.storage.snapshot.SnapshotManagerImpl.deleteSnapshot(SnapshotManagerImpl.java:496)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
>From the DB, the 2 snapshots you created were at the same time: 2013-07-23
>23:51:46
I would suggest do hourly and the weekly snapshot at different time slots, not
at the same time.
was (Author: fangw):
Can you reproduce it now?
I looked at the log and the source code, the source code at
XenserverSnapshotStrategy.java, and SnapshotManagerImpl.java
got changed.
>From the log, there is a snpshot got stuck at deleteSnapshot command. It shows
>destroyed in DB, but it failed:
2013-07-23 18:52:33,744 DEBUG [agent.transport.Request] (Job-Executor-66:job-95
= [ 669b527b-d1ab-4726-9a22-8363aff5dee4 ]) Seq 3-1039532574: Sending { Cmd ,
MgmtId: 7471666038533, via: 3, Ver: v1, Flags: 100011,
[{"org.apache.cloudstack.storage.command.DeleteCommand":{"data":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"snapshots/3/6/28192719-5193-4e92-8b0a-92b66b1f4a6a","volume":{"uuid":"031802d8-c10a-4038-9acf-b86eba54b647","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"ef3dea99-0a1b-35b9-87ec-d8cabe7ed9c1","id":1,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/chandan/campocr-195-103/primarykvm","port":2049}},"name":"ROOT-6","size":147456,"path":"906ec8f4-e625-4943-aedd-aff3444150b9","volumeId":6,"vmName":"i-3-6-JULYLAST","accountId":3,"format":"QCOW2","id":6},"dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.223.110.232/export/home/chandan/campocr-195-103/secondary/","_role":"Image"}},"vmName":"i-3-6-JULYLAST","name":"Atoms-VM-1_ROOT-6_20130723235146","hypervisorType":"KVM","id":24}},"wait":0}}]
}
20
[jira] [Commented] (CLOUDSTACK-3788) [KVM] Weekly Snapshot got stuck in "Allocated State"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13732840#comment-13732840
]
Fang Wang commented on CLOUDSTACK-3788:
---
Can you reproduce it now?
I looked at the log and the source code, the source code at
XenserverSnapshotStrategy.java, and SnapshotManagerImpl.java
got changed.
>From the log, there is a snpshot got stuck at deleteSnapshot command. It shows
>destroyed in DB, but it failed:
2013-07-23 18:52:33,744 DEBUG [agent.transport.Request] (Job-Executor-66:job-95
= [ 669b527b-d1ab-4726-9a22-8363aff5dee4 ]) Seq 3-1039532574: Sending { Cmd ,
MgmtId: 7471666038533, via: 3, Ver: v1, Flags: 100011,
[{"org.apache.cloudstack.storage.command.DeleteCommand":{"data":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"snapshots/3/6/28192719-5193-4e92-8b0a-92b66b1f4a6a","volume":{"uuid":"031802d8-c10a-4038-9acf-b86eba54b647","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"ef3dea99-0a1b-35b9-87ec-d8cabe7ed9c1","id":1,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/chandan/campocr-195-103/primarykvm","port":2049}},"name":"ROOT-6","size":147456,"path":"906ec8f4-e625-4943-aedd-aff3444150b9","volumeId":6,"vmName":"i-3-6-JULYLAST","accountId":3,"format":"QCOW2","id":6},"dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.223.110.232/export/home/chandan/campocr-195-103/secondary/","_role":"Image"}},"vmName":"i-3-6-JULYLAST","name":"Atoms-VM-1_ROOT-6_20130723235146","hypervisorType":"KVM","id":24}},"wait":0}}]
}
2013-07-23 18:52:34,741 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-5:null) SeqA 2-11944: Processing Seq 2-11944: { Cmd ,
MgmtId: -1, via: 2, Ver: v1, Flags: 11,
[{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":2,"_loadInfo":"{\n
\"connections\": []\n}","wait":0}}] }
2013-07-23 18:52:34,745 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-5:null) SeqA 2-11944: Sending Seq 2-11944: { Ans: ,
MgmtId: 7471666038533, via: 2, Ver: v1, Flags: 100010,
[{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
2013-07-23 18:52:37,598 DEBUG [agent.transport.Request]
(AgentManager-Handler-3:null) Seq 3-1039532574: Processing: { Ans: , MgmtId:
7471666038533, via: 3, Ver: v1, Flags: 10,
[{"com.cloud.agent.api.Answer":{"result":true,"wait":0}}] }
2013-07-23 18:52:37,598 DEBUG [agent.transport.Request] (Job-Executor-66:job-95
= [ 669b527b-d1ab-4726-9a22-8363aff5dee4 ]) Seq 3-1039532574: Received: { Ans:
, MgmtId: 7471666038533, via: 3, Ver: v1, Flags: 10, { Answer } }
2013-07-23 18:52:37,611 DEBUG [storage.snapshot.XenserverSnapshotStrategy]
(Job-Executor-66:job-95 = [ 669b527b-d1ab-4726-9a22-8363aff5dee4 ]) Failed to
delete snapshot:
java.lang.NullPointerException
at
org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.deleteSnapshot(XenserverSnapshotStrategy.java:192)
at
com.cloud.storage.snapshot.SnapshotManagerImpl.deleteSnapshot(SnapshotManagerImpl.java:496)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
>From the DB, the 2 snapshots you created were at the same time: 2013-07-23
>23:51:46
I would suggest to do hourly and the weekly snapshot at the different time, not
at the same time slot.
> [KVM] Weekly Snapshot got stuck in "Allocated State"
>
>
> Key: CLOUDSTACK-3788
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3788
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Snapshot
>Affects Versions: 4.2.0
>Reporter: Chandan Purushothama
>Assignee: Fang Wang
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.log.2013-07-23.gz,
> mysql_cloudstack_dump.zip
>
>
> Weekly Snapshot stuck in Allocated State:
> mysql> select * from snapshots where name like
> "Atoms-VM-1_ROOT-6_20130723235146";
> ++++---+---+--+---+--+--+--+---+--++-+-++--++--+-+-+---+
> | id | data_center_id | account_id | domain_id | volume_id | disk_offering_id
> | status| path | name | uuid
>| snapshot_type | type_description | size | created
>| removed | backup_snap_id | swift_id | sechost_id | prev_snap_id |
> hypervisor_type | vers
[jira] [Updated] (CLOUDSTACK-3788) [KVM] Weekly Snapshot got stuck in "Allocated State"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fang Wang updated CLOUDSTACK-3788: -- Status: Ready To Review (was: In Progress) > [KVM] Weekly Snapshot got stuck in "Allocated State" > > > Key: CLOUDSTACK-3788 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3788 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot >Affects Versions: 4.2.0 >Reporter: Chandan Purushothama >Assignee: Fang Wang >Priority: Critical > Fix For: 4.2.0 > > Attachments: management-server.log.2013-07-23.gz, > mysql_cloudstack_dump.zip > > > Weekly Snapshot stuck in Allocated State: > mysql> select * from snapshots where name like > "Atoms-VM-1_ROOT-6_20130723235146"; > ++++---+---+--+---+--+--+--+---+--++-+-++--++--+-+-+---+ > | id | data_center_id | account_id | domain_id | volume_id | disk_offering_id > | status| path | name | uuid >| snapshot_type | type_description | size | created >| removed | backup_snap_id | swift_id | sechost_id | prev_snap_id | > hypervisor_type | version | s3_id | > ++++---+---+--+---+--+--+--+---+--++-+-++--++--+-+-+---+ > | 24 | 1 | 3 | 1 | 6 |1 > | Destroyed | NULL | Atoms-VM-1_ROOT-6_20130723235146 | > 08a0d2aa-9635-41cd-ba54-5367303bceac | 3 | HOURLY | > 147456 | 2013-07-23 23:51:46 | NULL| NULL | NULL | > NULL | NULL | KVM | 2.2 | NULL | > | 25 | 1 | 3 | 1 | 6 |1 > | Allocated | NULL | Atoms-VM-1_ROOT-6_20130723235146 | > 1e24a056-be38-4b55-845b-a5672b9fa93c | 5 | WEEKLY | > 147456 | 2013-07-23 23:51:46 | NULL| NULL | NULL | > NULL | NULL | KVM | 2.2 | NULL | > ++++---+---+--+---+--+--+--+---+--++-+-++--++--+-+-+---+ > 2 rows in set (0.04 sec) > Attached Management Server logs and cloud database dump -- 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-3788) [KVM] Weekly Snapshot got stuck in "Allocated State"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13732694#comment-13732694 ] Fang Wang commented on CLOUDSTACK-3788: --- Chandan: 1. do you still see this bug? 2. When the weekly snapshot was taken, was there another snapshot in progress? > [KVM] Weekly Snapshot got stuck in "Allocated State" > > > Key: CLOUDSTACK-3788 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3788 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot >Affects Versions: 4.2.0 >Reporter: Chandan Purushothama >Assignee: Fang Wang >Priority: Critical > Fix For: 4.2.0 > > Attachments: management-server.log.2013-07-23.gz, > mysql_cloudstack_dump.zip > > > Weekly Snapshot stuck in Allocated State: > mysql> select * from snapshots where name like > "Atoms-VM-1_ROOT-6_20130723235146"; > ++++---+---+--+---+--+--+--+---+--++-+-++--++--+-+-+---+ > | id | data_center_id | account_id | domain_id | volume_id | disk_offering_id > | status| path | name | uuid >| snapshot_type | type_description | size | created >| removed | backup_snap_id | swift_id | sechost_id | prev_snap_id | > hypervisor_type | version | s3_id | > ++++---+---+--+---+--+--+--+---+--++-+-++--++--+-+-+---+ > | 24 | 1 | 3 | 1 | 6 |1 > | Destroyed | NULL | Atoms-VM-1_ROOT-6_20130723235146 | > 08a0d2aa-9635-41cd-ba54-5367303bceac | 3 | HOURLY | > 147456 | 2013-07-23 23:51:46 | NULL| NULL | NULL | > NULL | NULL | KVM | 2.2 | NULL | > | 25 | 1 | 3 | 1 | 6 |1 > | Allocated | NULL | Atoms-VM-1_ROOT-6_20130723235146 | > 1e24a056-be38-4b55-845b-a5672b9fa93c | 5 | WEEKLY | > 147456 | 2013-07-23 23:51:46 | NULL| NULL | NULL | > NULL | NULL | KVM | 2.2 | NULL | > ++++---+---+--+---+--+--+--+---+--++-+-++--++--+-+-+---+ > 2 rows in set (0.04 sec) > Attached Management Server logs and cloud database dump -- 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-3759) [Automation] Attach volume on a vm deployed with startvm=False fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13731434#comment-13731434
]
Fang Wang commented on CLOUDSTACK-3759:
---
Thanks Prasanna, I'll look at it
> [Automation] Attach volume on a vm deployed with startvm=False fails
>
>
> Key: CLOUDSTACK-3759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3759
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.2.0
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: attachvolumefail.log
>
>
> Test cases failed from integration.component.test_stopped_vm.TestDeployVM
> Steps to reproduce
> --
> Step 1 : Create a VM from command line with start state is false
> Step 2 : Create a volume and attach the volume to stopped VM
> Actual Result
> Volume attachment failed;
> Observed below error automation test log
>
> attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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_stopped_vm.py",
> line 611, in test_06_deploy_startvm_attach_detach
> self.fail("Attach volume failed!")
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> Attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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] [Updated] (CLOUDSTACK-3673) [Automation] integration.component.test_snapshots , 1 test case failed
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fang Wang updated CLOUDSTACK-3673:
--
Summary: [Automation] integration.component.test_snapshots , 1 test case
failed (was: [Automation] integration.component.test_snapshots , 6 test cases
failed due to multiple reasons.)
> [Automation] integration.component.test_snapshots , 1 test case failed
> ---
>
> Key: CLOUDSTACK-3673
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3673
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, VMware
>Affects Versions: 4.2.0
> Environment: VMWARE
>Reporter: Parth Jagirdar
>Assignee: Fang Wang
> Fix For: 4.2.0
>
> Attachments: VMware_Adv.7z
>
>
> integration.component.test_snapshots.TestCreateVMSnapshotTemplate.test_01_createVM_snapshotTemplate
> (from nosetests)
> Failing for the past 4 builds (Since #64 )
> Took 4 min 50 sec.
> add description
> Error Message
> Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext :
> u'Failed to create template'}
> >> begin captured logging <<
> testclient.testcase.TestCreateVMSnapshotTemplate: DEBUG: Created VM with ID:
> f7b1fba3-e8ff-4014-9731-66a9bc59
> testclient.testcase.TestCreateVMSnapshotTemplate: DEBUG: Snapshot created: ID
> - 517f7f6e-1ad0-4e56-8ebb-e905324f43dd
> testclient.testcase.TestCreateVMSnapshotTemplate: DEBUG: select
> backup_snap_id, account_id, volume_id from snapshots where uuid =
> '517f7f6e-1ad0-4e56-8ebb-e905324f43dd';
> - >> end captured logging << -
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
> File
> "/data/Repo2/qa/cloudstack/test/integration/component/test_snapshots.py",
> line 1164, in test_01_createVM_snapshotTemplate
> self.services["templates"]
> File
> "/usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py", line
> 878, in create_from_snapshot
> return Template(apiclient.createTemplate(cmd).__dict__)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 720, in createTemplate
> response = self.connection.marvin_request(command,
> response_type=response, method=method)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line
> 230, in marvin_request
> response = self.poll(asyncJobId, response_type)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line
> 91, in poll
> "asyncquery", asyncResonse.jobresult)
> Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext :
> u'Failed to create template'}
> >> begin captured logging <<
> testclient.testcase.TestCreateVMSnapshotTemplate: DEBUG: Created VM with ID:
> f7b1fba3-e8ff-4014-9731-66a9bc59
> testclient.testcase.TestCreateVMSnapshotTemplate: DEBUG: Snapshot created: ID
> - 517f7f6e-1ad0-4e56-8ebb-e905324f43dd
> testclient.testcase.TestCreateVMSnapshotTemplate: DEBUG: select
> backup_snap_id, account_id, volume_id from snapshots where uuid =
> '517f7f6e-1ad0-4e56-8ebb-e905324f43dd';
> - >> end captured logging << -
> integration.component.test_snapshots.TestSnapshots.test_01_volume_from_snapshot
> (from nosetests)
> Failing for the past 1 build (Since #67 )
> Took 1 min 27 sec.
> add description
> Error Message
> 'zoneid'
> >> begin captured logging <<
> testclient.testcase.TestSnapshots: DEBUG: Created volume with ID:
> 069711ba-d9a5-4546-8c81-14298d0d055e
> testclient.testcase.TestSnapshots: DEBUG: Attach volume:
> 069711ba-d9a5-4546-8c81-14298d0d055e to VM:
> a0c02243-6df4-4eff-8ce3-291df77917c6
> paramiko.transport: DEBUG: starting thread (client mode): 0x18395210L
> paramiko.transport: INFO: Connected (version 2.0, client OpenSSH_4.3)
> paramiko.transport: DEBUG: kex algos:['diffie-hellman-group-exchange-sha1',
> 'diffie-hellman-group14-sha1', 'diffie-hellman-group1-sha1'] server
> key:['ssh-rsa', 'ssh-dss'] client encrypt:['aes128-cbc', '3des-cbc',
> 'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour',
> 'aes192-cbc', 'aes256-cbc', 'rijndael-...@lysator.liu.se', 'aes128-ctr',
> 'aes192-ctr', 'aes256-ctr'] server encrypt:['aes128-cbc', '3des-cbc',
> 'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour',
> 'aes192-cbc', 'aes256-cbc', 'rijndael-...@lysator.liu.se', 'aes128-ctr',
> 'aes192-ctr', 'aes256-ctr'] client mac:['hmac-md5', 'hmac-sha1',
> 'hmac-ripemd160', 'hmac-ripemd
[jira] [Commented] (CLOUDSTACK-3673) [Automation] integration.component.test_snapshots , 6 test cases failed due to multiple reasons.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13731424#comment-13731424
]
Fang Wang commented on CLOUDSTACK-3673:
---
I verified and rerun manually the 6 tests above. Test 1, 3, 4, 5. 6 are running
fine. Please rerun the test, with the newer 4.2, those 5 tests passed manually.
Test 2 failed:
# Validate the following
#1. Create a virtual machine and data volume
#2. Attach data volume to VM
#3. Login to machine; create temp/test directories on data volume
#4. Snapshot the Volume
#5. Create another Volume from snapshot --- Note: failed to create
volume;
#6. Mount/Attach volume to another server
#7. Compare data
At step 5, it failed to create a new volume from the snapshot. I will
investigate this error.
> [Automation] integration.component.test_snapshots , 6 test cases failed due
> to multiple reasons.
>
>
> Key: CLOUDSTACK-3673
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3673
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, VMware
>Affects Versions: 4.2.0
> Environment: VMWARE
>Reporter: Parth Jagirdar
>Assignee: Fang Wang
> Fix For: 4.2.0
>
> Attachments: VMware_Adv.7z
>
>
> integration.component.test_snapshots.TestCreateVMSnapshotTemplate.test_01_createVM_snapshotTemplate
> (from nosetests)
> Failing for the past 4 builds (Since #64 )
> Took 4 min 50 sec.
> add description
> Error Message
> Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext :
> u'Failed to create template'}
> >> begin captured logging <<
> testclient.testcase.TestCreateVMSnapshotTemplate: DEBUG: Created VM with ID:
> f7b1fba3-e8ff-4014-9731-66a9bc59
> testclient.testcase.TestCreateVMSnapshotTemplate: DEBUG: Snapshot created: ID
> - 517f7f6e-1ad0-4e56-8ebb-e905324f43dd
> testclient.testcase.TestCreateVMSnapshotTemplate: DEBUG: select
> backup_snap_id, account_id, volume_id from snapshots where uuid =
> '517f7f6e-1ad0-4e56-8ebb-e905324f43dd';
> - >> end captured logging << -
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
> File
> "/data/Repo2/qa/cloudstack/test/integration/component/test_snapshots.py",
> line 1164, in test_01_createVM_snapshotTemplate
> self.services["templates"]
> File
> "/usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py", line
> 878, in create_from_snapshot
> return Template(apiclient.createTemplate(cmd).__dict__)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 720, in createTemplate
> response = self.connection.marvin_request(command,
> response_type=response, method=method)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line
> 230, in marvin_request
> response = self.poll(asyncJobId, response_type)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line
> 91, in poll
> "asyncquery", asyncResonse.jobresult)
> Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext :
> u'Failed to create template'}
> >> begin captured logging <<
> testclient.testcase.TestCreateVMSnapshotTemplate: DEBUG: Created VM with ID:
> f7b1fba3-e8ff-4014-9731-66a9bc59
> testclient.testcase.TestCreateVMSnapshotTemplate: DEBUG: Snapshot created: ID
> - 517f7f6e-1ad0-4e56-8ebb-e905324f43dd
> testclient.testcase.TestCreateVMSnapshotTemplate: DEBUG: select
> backup_snap_id, account_id, volume_id from snapshots where uuid =
> '517f7f6e-1ad0-4e56-8ebb-e905324f43dd';
> - >> end captured logging << -
> integration.component.test_snapshots.TestSnapshots.test_01_volume_from_snapshot
> (from nosetests)
> Failing for the past 1 build (Since #67 )
> Took 1 min 27 sec.
> add description
> Error Message
> 'zoneid'
> >> begin captured logging <<
> testclient.testcase.TestSnapshots: DEBUG: Created volume with ID:
> 069711ba-d9a5-4546-8c81-14298d0d055e
> testclient.testcase.TestSnapshots: DEBUG: Attach volume:
> 069711ba-d9a5-4546-8c81-14298d0d055e to VM:
> a0c02243-6df4-4eff-8ce3-291df77917c6
> paramiko.transport: DEBUG: starting thread (client mode): 0x18395210L
> paramiko.transport: INFO: Connected (version 2.0, client OpenSSH_4.3)
> paramiko.transport: DEBUG: kex algos:['diffie-hellman-group-exchange-sha1',
> 'diffie-hellman
[jira] [Commented] (CLOUDSTACK-3673) [Automation] integration.component.test_snapshots , 1 test case failed
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13731426#comment-13731426
]
Fang Wang commented on CLOUDSTACK-3673:
---
I updated the bug title accordingly as well.
> [Automation] integration.component.test_snapshots , 1 test case failed
> ---
>
> Key: CLOUDSTACK-3673
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3673
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, VMware
>Affects Versions: 4.2.0
> Environment: VMWARE
>Reporter: Parth Jagirdar
>Assignee: Fang Wang
> Fix For: 4.2.0
>
> Attachments: VMware_Adv.7z
>
>
> integration.component.test_snapshots.TestCreateVMSnapshotTemplate.test_01_createVM_snapshotTemplate
> (from nosetests)
> Failing for the past 4 builds (Since #64 )
> Took 4 min 50 sec.
> add description
> Error Message
> Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext :
> u'Failed to create template'}
> >> begin captured logging <<
> testclient.testcase.TestCreateVMSnapshotTemplate: DEBUG: Created VM with ID:
> f7b1fba3-e8ff-4014-9731-66a9bc59
> testclient.testcase.TestCreateVMSnapshotTemplate: DEBUG: Snapshot created: ID
> - 517f7f6e-1ad0-4e56-8ebb-e905324f43dd
> testclient.testcase.TestCreateVMSnapshotTemplate: DEBUG: select
> backup_snap_id, account_id, volume_id from snapshots where uuid =
> '517f7f6e-1ad0-4e56-8ebb-e905324f43dd';
> - >> end captured logging << -
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
> File
> "/data/Repo2/qa/cloudstack/test/integration/component/test_snapshots.py",
> line 1164, in test_01_createVM_snapshotTemplate
> self.services["templates"]
> File
> "/usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py", line
> 878, in create_from_snapshot
> return Template(apiclient.createTemplate(cmd).__dict__)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 720, in createTemplate
> response = self.connection.marvin_request(command,
> response_type=response, method=method)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line
> 230, in marvin_request
> response = self.poll(asyncJobId, response_type)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line
> 91, in poll
> "asyncquery", asyncResonse.jobresult)
> Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext :
> u'Failed to create template'}
> >> begin captured logging <<
> testclient.testcase.TestCreateVMSnapshotTemplate: DEBUG: Created VM with ID:
> f7b1fba3-e8ff-4014-9731-66a9bc59
> testclient.testcase.TestCreateVMSnapshotTemplate: DEBUG: Snapshot created: ID
> - 517f7f6e-1ad0-4e56-8ebb-e905324f43dd
> testclient.testcase.TestCreateVMSnapshotTemplate: DEBUG: select
> backup_snap_id, account_id, volume_id from snapshots where uuid =
> '517f7f6e-1ad0-4e56-8ebb-e905324f43dd';
> - >> end captured logging << -
> integration.component.test_snapshots.TestSnapshots.test_01_volume_from_snapshot
> (from nosetests)
> Failing for the past 1 build (Since #67 )
> Took 1 min 27 sec.
> add description
> Error Message
> 'zoneid'
> >> begin captured logging <<
> testclient.testcase.TestSnapshots: DEBUG: Created volume with ID:
> 069711ba-d9a5-4546-8c81-14298d0d055e
> testclient.testcase.TestSnapshots: DEBUG: Attach volume:
> 069711ba-d9a5-4546-8c81-14298d0d055e to VM:
> a0c02243-6df4-4eff-8ce3-291df77917c6
> paramiko.transport: DEBUG: starting thread (client mode): 0x18395210L
> paramiko.transport: INFO: Connected (version 2.0, client OpenSSH_4.3)
> paramiko.transport: DEBUG: kex algos:['diffie-hellman-group-exchange-sha1',
> 'diffie-hellman-group14-sha1', 'diffie-hellman-group1-sha1'] server
> key:['ssh-rsa', 'ssh-dss'] client encrypt:['aes128-cbc', '3des-cbc',
> 'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour',
> 'aes192-cbc', 'aes256-cbc', 'rijndael-...@lysator.liu.se', 'aes128-ctr',
> 'aes192-ctr', 'aes256-ctr'] server encrypt:['aes128-cbc', '3des-cbc',
> 'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour',
> 'aes192-cbc', 'aes256-cbc', 'rijndael-...@lysator.liu.se', 'aes128-ctr',
> 'aes192-ctr', 'aes256-ctr'] client mac:['hmac-md5', 'hmac-sha1',
> 'hmac-ripemd160', 'hmac-ripemd...@openssh.com', 'hmac-sha1-96',
> 'hmac-md5-96'] server mac:['hmac-md5', 'h
[jira] [Updated] (CLOUDSTACK-4033) template creation from snapshot failed after upgrade getting NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fang Wang updated CLOUDSTACK-4033:
--
Assignee: (was: Fang Wang)
> template creation from snapshot failed after upgrade getting NPE
>
>
> Key: CLOUDSTACK-4033
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4033
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Upgrade
>Affects Versions: 4.2.0
> Environment: upgrade 3.0.3 to 4.2 with advanced zone and KVM host
>Reporter: shweta agarwal
>Priority: Blocker
>
> Repro steps :
> 1.Created a volume before upgrade
> 2. Trying to create a template of that volume
> bug:
> Hitting exception java NPE
> 2013-08-02 10:51:25,454 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null)
> ===END=== 10.146.0.13 -- GET
> command=createTemplate&response=json&sessionkey=Zyi8PabGY6x6PizqWhq%2B2C%2Ba6ow%3D&snapshotid=acff0a0f-232f-4a44-bc64-30bbc9fc63fd&name=from+snapshot&displayText=from+snapshot&osTypeId=7830e08c-95b9-4649-8ad9-fd17fca2145a&isPublic=true&passwordEnabled=false&isdynamicallyscalable=false&_=1375420884718
> 2013-08-02 10:51:25,472 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-144:job-307 = [ 6043417d-ce77-4477-af18-1c190e57cfcb ])
> Executing org.apache.cloudstack.api.command.user.template.CreateTemplateCmd
> for job-307 = [ 6043417d-ce77-4477-af18-1c190e57cfcb ]
> 2013-08-02 10:51:25,542 DEBUG [storage.image.TemplateDataFactoryImpl]
> (Job-Executor-144:job-307 = [ 6043417d-ce77-4477-af18-1c190e57cfcb ])
> template 213 is already in store:2, type:Image
> 2013-08-02 10:51:25,795 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-144:job-307 = [ 6043417d-ce77-4477-af18-1c190e57cfcb ])
> Unexpected exception while executing
> org.apache.cloudstack.api.command.user.template.CreateTemplateCmd
> java.lang.NullPointerException
> at
> org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:45)
> at
> org.apache.cloudstack.storage.image.TemplateServiceImpl.copyAsync(TemplateServiceImpl.java:549)
> at
> org.apache.cloudstack.storage.image.TemplateServiceImpl.createTemplateFromSnapshotAsync(TemplateServiceImpl.java:556)
> at
> com.cloud.template.TemplateManagerImpl.createPrivateTemplate(TemplateManagerImpl.java:1358)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.template.CreateTemplateCmd.execute(CreateTemplateCmd.java:263)
> 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-02 10:51:25,799 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-144:job-307 = [ 6043417d-ce77-4477-af18-1c190e57cfcb ])
> Complete async job-307 = [ 6043417d-ce77-4477-af18-1c190e57cfcb ], jobStatus:
> 2, resultCode: 530, result: Error Code: 530 Error text: null
> 2013-08-02 10:51:27,559 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-3:null) SeqA 11-5096: Processing Seq 11-5096: { Cmd ,
> MgmtId: -1, via: 11, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":68,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2013-08-02 10:51:27,577 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-3:null) SeqA 11-5096: Sending Seq 11-5096: { Ans: ,
> MgmtId: 7181084655717, via: 11, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
>
>
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-4033) template creation from snapshot failed after upgrade getting NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fang Wang updated CLOUDSTACK-4033:
--
Assignee: Fang Wang
> template creation from snapshot failed after upgrade getting NPE
>
>
> Key: CLOUDSTACK-4033
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4033
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Upgrade
>Affects Versions: 4.2.0
> Environment: upgrade 3.0.3 to 4.2 with advanced zone and KVM host
>Reporter: shweta agarwal
>Assignee: Fang Wang
>Priority: Blocker
>
> Repro steps :
> 1.Created a volume before upgrade
> 2. Trying to create a template of that volume
> bug:
> Hitting exception java NPE
> 2013-08-02 10:51:25,454 DEBUG [cloud.api.ApiServlet] (catalina-exec-1:null)
> ===END=== 10.146.0.13 -- GET
> command=createTemplate&response=json&sessionkey=Zyi8PabGY6x6PizqWhq%2B2C%2Ba6ow%3D&snapshotid=acff0a0f-232f-4a44-bc64-30bbc9fc63fd&name=from+snapshot&displayText=from+snapshot&osTypeId=7830e08c-95b9-4649-8ad9-fd17fca2145a&isPublic=true&passwordEnabled=false&isdynamicallyscalable=false&_=1375420884718
> 2013-08-02 10:51:25,472 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-144:job-307 = [ 6043417d-ce77-4477-af18-1c190e57cfcb ])
> Executing org.apache.cloudstack.api.command.user.template.CreateTemplateCmd
> for job-307 = [ 6043417d-ce77-4477-af18-1c190e57cfcb ]
> 2013-08-02 10:51:25,542 DEBUG [storage.image.TemplateDataFactoryImpl]
> (Job-Executor-144:job-307 = [ 6043417d-ce77-4477-af18-1c190e57cfcb ])
> template 213 is already in store:2, type:Image
> 2013-08-02 10:51:25,795 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-144:job-307 = [ 6043417d-ce77-4477-af18-1c190e57cfcb ])
> Unexpected exception while executing
> org.apache.cloudstack.api.command.user.template.CreateTemplateCmd
> java.lang.NullPointerException
> at
> org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:45)
> at
> org.apache.cloudstack.storage.image.TemplateServiceImpl.copyAsync(TemplateServiceImpl.java:549)
> at
> org.apache.cloudstack.storage.image.TemplateServiceImpl.createTemplateFromSnapshotAsync(TemplateServiceImpl.java:556)
> at
> com.cloud.template.TemplateManagerImpl.createPrivateTemplate(TemplateManagerImpl.java:1358)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.template.CreateTemplateCmd.execute(CreateTemplateCmd.java:263)
> 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-02 10:51:25,799 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-144:job-307 = [ 6043417d-ce77-4477-af18-1c190e57cfcb ])
> Complete async job-307 = [ 6043417d-ce77-4477-af18-1c190e57cfcb ], jobStatus:
> 2, resultCode: 530, result: Error Code: 530 Error text: null
> 2013-08-02 10:51:27,559 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-3:null) SeqA 11-5096: Processing Seq 11-5096: { Cmd ,
> MgmtId: -1, via: 11, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":68,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2013-08-02 10:51:27,577 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-3:null) SeqA 11-5096: Sending Seq 11-5096: { Ans: ,
> MgmtId: 7181084655717, via: 11, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
>
>
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-3790) KVM - Fail to create hourly daily weekly monthly recurring snapshot : pool is already active
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fang Wang resolved CLOUDSTACK-3790.
---
Resolution: Fixed
> KVM - Fail to create hourly daily weekly monthly recurring snapshot : pool is
> already active
> -
>
> Key: CLOUDSTACK-3790
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3790
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: MS build
> CloudPlatform-4.2-275-rhel6.3.tar.gzCloudPlatform-4.2-246-rhel6.3.tar.gz
> host KVM buildCloudPlatform-4.2-275-rhel6.3.tar.gz
> CloudPlatform-4.2-246-rhel6.3.tar.gz
>Reporter: angeline shen
>Assignee: Fang Wang
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.log.2013-07-23.gz,
> management-server.log.2013-07-25.gz, management-server.log.2013-07-26.gz,
> management-server.log.gz, management-server.log.gz, Screenshot-CloudPlatform™
> - Mozilla Firefox-1.png, Screenshot-CloudPlatform™ - Mozilla Firefox-1.png,
> Screenshot-CloudPlatform™ - Mozilla Firefox-1.png, Screenshot-CloudPlatform™
> - Mozilla Firefox-2.png, Screenshot-CloudPlatform™ - Mozilla Firefox-3.png,
> Screenshot-CloudPlatform™ - Mozilla Firefox.png
>
>
> 1. advance zone. domain: d1domain admin: d1domain domain: d2
> user : d2user
> 2. login : admin . create VPC network & VMs with DATA disk
>login: d1domain. create VPC network & VMs with DATA disk
>login: d2user. create VPC network & VMs with DATA disk
> 3. login as each of above users.
> . setup HOURLY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at 50 minutes pass
> the hour.
> .setup DAILY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at 6:50 pm
> . setup WEEKLY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at Saturday 6:50 pm
> . setup MONTHLY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at 27th day of the
> month at 6:50 pm
>
> Result:
> some HOURLY, DAILY, MONTHLY snapshots generated with status CreateOnPrimary
> ,
> Failed to create snapshot due to pool is already active .
> some WEEKLY snapshots generated with status Allocated.
> 2013-07-23 22:04:49,920 DEBUG [agent.transport.Request]
> (Job-Executor-42:job-56 = [ 3def22de-176e-45a7-b72b-98aaef57b906 ]) Seq
> 1-1490617925: Sending { Cmd , MgmtId: 6655051826959, via: 1, Ver: v1, Flags:
> 100011, [{"or
> g.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"/mnt/79884886-a3ee-31a7-856c-805e18c48f88/b52e5c2b-fc3e-4292-bda5-cb961efb94c7/c733fc4e-4d16-481f-9
> e20-2ed2519d6b3d","volume":{"uuid":"a39f007b-b014-4e6c-a3fa-8bce7a9ba213","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"79884886-a3ee-31a7-856c-805e18c48f88","id":1,"poo
> lType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/angie/primary/kvm63","port":2049}},"name":"ROOT-13","size":147456,"path":"b52e5c2b-fc3e-4292-bda5-cb961efb94c7","volumeId":15,"vmName":"i-4-13-VM",
> "accountId":4,"format":"QCOW2","id":15},"parentSnapshotPath":"/mnt/79884886-a3ee-31a7-856c-805e18c48f88/b52e5c2b-fc3e-4292-bda5-cb961efb94c7/29669eb5-1525-4745-81c4-6ca6ad239af0","dataStore":{"org.apache.cloudstack.stor
> age.to.PrimaryDataStoreTO":{"uuid":"79884886-a3ee-31a7-856c-805e18c48f88","id":1,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/angie/primary/kvm63","port":2049}},"vmName":"i-4-13-VM","name"
> :"z1vpc3G3d2userV32_ROOT-13_20130724050449","hypervisorType":"None","id":28}},"destTO":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"snapshots/4/15","volume":{"uuid":"a39f007b-b014-4e6c-a3fa-8bce7a9ba213
> ","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"79884886-a3ee-31a7-856c-805e18c48f88","id":1,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/
> angie/primary/kvm63","port":2049}},"name":"ROOT-13","size":147456,"path":"b52e5c2b-fc3e-4292-bda5-cb961efb94c7","volumeId":15,"vmName":"i-4-13-VM","accountId":4,"format":"QCOW2","id":15},"parentSnapshotPath":"snapshots/
> 4/15/29669eb5-1525-4745-81c4-6ca6ad239af0","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.223.110.232/export/home/angie/secondary/kvm63","_role":"Image"}},"
[jira] [Commented] (CLOUDSTACK-3790) KVM - Fail to create hourly daily weekly monthly recurring snapshot : pool is already active
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13730123#comment-13730123
]
Fang Wang commented on CLOUDSTACK-3790:
---
Operation issue: we do not want to take 2 snapshots to the same volume at the
same time.
> KVM - Fail to create hourly daily weekly monthly recurring snapshot : pool is
> already active
> -
>
> Key: CLOUDSTACK-3790
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3790
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: MS build
> CloudPlatform-4.2-275-rhel6.3.tar.gzCloudPlatform-4.2-246-rhel6.3.tar.gz
> host KVM buildCloudPlatform-4.2-275-rhel6.3.tar.gz
> CloudPlatform-4.2-246-rhel6.3.tar.gz
>Reporter: angeline shen
>Assignee: Fang Wang
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.log.2013-07-23.gz,
> management-server.log.2013-07-25.gz, management-server.log.2013-07-26.gz,
> management-server.log.gz, management-server.log.gz, Screenshot-CloudPlatform™
> - Mozilla Firefox-1.png, Screenshot-CloudPlatform™ - Mozilla Firefox-1.png,
> Screenshot-CloudPlatform™ - Mozilla Firefox-1.png, Screenshot-CloudPlatform™
> - Mozilla Firefox-2.png, Screenshot-CloudPlatform™ - Mozilla Firefox-3.png,
> Screenshot-CloudPlatform™ - Mozilla Firefox.png
>
>
> 1. advance zone. domain: d1domain admin: d1domain domain: d2
> user : d2user
> 2. login : admin . create VPC network & VMs with DATA disk
>login: d1domain. create VPC network & VMs with DATA disk
>login: d2user. create VPC network & VMs with DATA disk
> 3. login as each of above users.
> . setup HOURLY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at 50 minutes pass
> the hour.
> .setup DAILY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at 6:50 pm
> . setup WEEKLY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at Saturday 6:50 pm
> . setup MONTHLY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at 27th day of the
> month at 6:50 pm
>
> Result:
> some HOURLY, DAILY, MONTHLY snapshots generated with status CreateOnPrimary
> ,
> Failed to create snapshot due to pool is already active .
> some WEEKLY snapshots generated with status Allocated.
> 2013-07-23 22:04:49,920 DEBUG [agent.transport.Request]
> (Job-Executor-42:job-56 = [ 3def22de-176e-45a7-b72b-98aaef57b906 ]) Seq
> 1-1490617925: Sending { Cmd , MgmtId: 6655051826959, via: 1, Ver: v1, Flags:
> 100011, [{"or
> g.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"/mnt/79884886-a3ee-31a7-856c-805e18c48f88/b52e5c2b-fc3e-4292-bda5-cb961efb94c7/c733fc4e-4d16-481f-9
> e20-2ed2519d6b3d","volume":{"uuid":"a39f007b-b014-4e6c-a3fa-8bce7a9ba213","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"79884886-a3ee-31a7-856c-805e18c48f88","id":1,"poo
> lType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/angie/primary/kvm63","port":2049}},"name":"ROOT-13","size":147456,"path":"b52e5c2b-fc3e-4292-bda5-cb961efb94c7","volumeId":15,"vmName":"i-4-13-VM",
> "accountId":4,"format":"QCOW2","id":15},"parentSnapshotPath":"/mnt/79884886-a3ee-31a7-856c-805e18c48f88/b52e5c2b-fc3e-4292-bda5-cb961efb94c7/29669eb5-1525-4745-81c4-6ca6ad239af0","dataStore":{"org.apache.cloudstack.stor
> age.to.PrimaryDataStoreTO":{"uuid":"79884886-a3ee-31a7-856c-805e18c48f88","id":1,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/angie/primary/kvm63","port":2049}},"vmName":"i-4-13-VM","name"
> :"z1vpc3G3d2userV32_ROOT-13_20130724050449","hypervisorType":"None","id":28}},"destTO":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"snapshots/4/15","volume":{"uuid":"a39f007b-b014-4e6c-a3fa-8bce7a9ba213
> ","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"79884886-a3ee-31a7-856c-805e18c48f88","id":1,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/
> angie/primary/kvm63","port":2049}},"name":"ROOT-13","size":147456,"path":"b52e5c2b-fc3e-4292-bda5-cb961efb94c7","volumeId":15,"vmName":"i-4-13-VM","accountId":4,"format":"QCOW2","id":15},"parentSnapshotPath":"snapshots/
> 4/15/29669eb5-1525-4745-81c4-6ca6ad
[jira] [Commented] (CLOUDSTACK-3790) KVM - Fail to create hourly daily weekly monthly recurring snapshot : pool is already active
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13730124#comment-13730124
]
Fang Wang commented on CLOUDSTACK-3790:
---
The state stuck at "Allocated state", It is a dup of 3788. I use 3788 to track
the issue,
> KVM - Fail to create hourly daily weekly monthly recurring snapshot : pool is
> already active
> -
>
> Key: CLOUDSTACK-3790
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3790
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: MS build
> CloudPlatform-4.2-275-rhel6.3.tar.gzCloudPlatform-4.2-246-rhel6.3.tar.gz
> host KVM buildCloudPlatform-4.2-275-rhel6.3.tar.gz
> CloudPlatform-4.2-246-rhel6.3.tar.gz
>Reporter: angeline shen
>Assignee: Fang Wang
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.log.2013-07-23.gz,
> management-server.log.2013-07-25.gz, management-server.log.2013-07-26.gz,
> management-server.log.gz, management-server.log.gz, Screenshot-CloudPlatform™
> - Mozilla Firefox-1.png, Screenshot-CloudPlatform™ - Mozilla Firefox-1.png,
> Screenshot-CloudPlatform™ - Mozilla Firefox-1.png, Screenshot-CloudPlatform™
> - Mozilla Firefox-2.png, Screenshot-CloudPlatform™ - Mozilla Firefox-3.png,
> Screenshot-CloudPlatform™ - Mozilla Firefox.png
>
>
> 1. advance zone. domain: d1domain admin: d1domain domain: d2
> user : d2user
> 2. login : admin . create VPC network & VMs with DATA disk
>login: d1domain. create VPC network & VMs with DATA disk
>login: d2user. create VPC network & VMs with DATA disk
> 3. login as each of above users.
> . setup HOURLY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at 50 minutes pass
> the hour.
> .setup DAILY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at 6:50 pm
> . setup WEEKLY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at Saturday 6:50 pm
> . setup MONTHLY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at 27th day of the
> month at 6:50 pm
>
> Result:
> some HOURLY, DAILY, MONTHLY snapshots generated with status CreateOnPrimary
> ,
> Failed to create snapshot due to pool is already active .
> some WEEKLY snapshots generated with status Allocated.
> 2013-07-23 22:04:49,920 DEBUG [agent.transport.Request]
> (Job-Executor-42:job-56 = [ 3def22de-176e-45a7-b72b-98aaef57b906 ]) Seq
> 1-1490617925: Sending { Cmd , MgmtId: 6655051826959, via: 1, Ver: v1, Flags:
> 100011, [{"or
> g.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"/mnt/79884886-a3ee-31a7-856c-805e18c48f88/b52e5c2b-fc3e-4292-bda5-cb961efb94c7/c733fc4e-4d16-481f-9
> e20-2ed2519d6b3d","volume":{"uuid":"a39f007b-b014-4e6c-a3fa-8bce7a9ba213","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"79884886-a3ee-31a7-856c-805e18c48f88","id":1,"poo
> lType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/angie/primary/kvm63","port":2049}},"name":"ROOT-13","size":147456,"path":"b52e5c2b-fc3e-4292-bda5-cb961efb94c7","volumeId":15,"vmName":"i-4-13-VM",
> "accountId":4,"format":"QCOW2","id":15},"parentSnapshotPath":"/mnt/79884886-a3ee-31a7-856c-805e18c48f88/b52e5c2b-fc3e-4292-bda5-cb961efb94c7/29669eb5-1525-4745-81c4-6ca6ad239af0","dataStore":{"org.apache.cloudstack.stor
> age.to.PrimaryDataStoreTO":{"uuid":"79884886-a3ee-31a7-856c-805e18c48f88","id":1,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/angie/primary/kvm63","port":2049}},"vmName":"i-4-13-VM","name"
> :"z1vpc3G3d2userV32_ROOT-13_20130724050449","hypervisorType":"None","id":28}},"destTO":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"snapshots/4/15","volume":{"uuid":"a39f007b-b014-4e6c-a3fa-8bce7a9ba213
> ","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"79884886-a3ee-31a7-856c-805e18c48f88","id":1,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/
> angie/primary/kvm63","port":2049}},"name":"ROOT-13","size":147456,"path":"b52e5c2b-fc3e-4292-bda5-cb961efb94c7","volumeId":15,"vmName":"i-4-13-VM","accountId":4,"format":"QCOW2","id":15},"parentSnapshotPath":"snapshots/
> 4/15/29669eb5-1525-4745-81c4-6ca6a
[jira] [Updated] (CLOUDSTACK-3430) volume migration on zone wide primary storage pool failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fang Wang updated CLOUDSTACK-3430:
--
Assignee: Sateesh Chodapuneedi (was: Fang Wang)
> volume migration on zone wide primary storage pool failing
> --
>
> Key: CLOUDSTACK-3430
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3430
> 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: vmware on cloudstack master
>Reporter: Venkata Siva Vijayendra Bhamidipati
>Assignee: Sateesh Chodapuneedi
>
> Create a zone with zone wide primary storage.
> Bring up system VMs, create a guest VM.
> Add another zone wide primary storage to the zone.
> Attempt to migrate the root volume of the guest VM from its current zone wide
> primary storage to the new zone wide primary storage. The operation fails,
> and the logs show the following trace:
> 2013-07-09 08:36:29,943 DEBUG [cloud.api.ApiServlet]
> (1754543106@qtp-481326697-2:null) ===START=== 10.217.252.54 -- GET
> command=findStoragePoolsForMigration&id=d0cd5d41-f395-48d9-8bd6-3886f4f76c3e&response=json&sessionkey=PWQxaW5CBGIDG7HYLOQBdAk3RJg%3D&_=1373407310956
> 2013-07-09 08:36:30,492 DEBUG [storage.allocator.LocalStoragePoolAllocator]
> (1754543106@qtp-481326697-2:null) LocalStoragePoolAllocator trying to find
> storage pool to fit the vm
> 2013-07-09 08:36:30,496 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator]
> (1754543106@qtp-481326697-2:null) ClusterScopeStoragePoolAllocator looking
> for storage pool
> 2013-07-09 08:36:30,497 DEBUG
> [storage.allocator.ZoneWideStoragePoolAllocator]
> (1754543106@qtp-481326697-2:null) ZoneWideStoragePoolAllocator to find
> storage pool
> 2013-07-09 08:36:30,660 DEBUG [cloud.storage.StorageManagerImpl]
> (1754543106@qtp-481326697-2:null) Checking pool 1 for storage, totalSize:
> 11810778316800, usedBytes: 8451350200320, usedPct: 0.7155625119386544,
> disable threshold: 0.85
> 2013-07-09 08:36:30,791 DEBUG [cloud.storage.StorageManagerImpl]
> (1754543106@qtp-481326697-2:null) Checking pool: 1 for volume allocation
> [Vol[10|vm=5|ROOT]], maxSize : 23621556633600, totalAllocatedSize : 0,
> askingSize : 0, allocated disable threshold: 0.85
> 2013-07-09 08:36:30,842 DEBUG [cloud.storage.StorageManagerImpl]
> (1754543106@qtp-481326697-2:null) Checking pool 2 for storage, totalSize:
> 11810778316800, usedBytes: 8451350200320, usedPct: 0.7155625119386544,
> disable threshold: 0.85
> 2013-07-09 08:36:30,878 DEBUG [cloud.storage.StorageManagerImpl]
> (1754543106@qtp-481326697-2:null) Checking pool: 2 for volume allocation
> [Vol[10|vm=5|ROOT]], maxSize : 23621556633600, totalAllocatedSize : 0,
> askingSize : 0, allocated disable threshold: 0.85
> 2013-07-09 08:36:31,204 DEBUG [cloud.api.ApiServlet]
> (1754543106@qtp-481326697-2:null) ===END=== 10.217.252.54 -- GET
> command=findStoragePoolsForMigration&id=d0cd5d41-f395-48d9-8bd6-3886f4f76c3e&response=json&sessionkey=PWQxaW5CBGIDG7HYLOQBdAk3RJg%3D&_=1373407310956
> 2013-07-09 08:36:33,437 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-29:null) Ping from 1
> 2013-07-09 08:36:33,671 DEBUG [cloud.api.ApiServlet]
> (1754543106@qtp-481326697-2:null) ===START=== 10.217.252.54 -- GET
> command=migrateVolume&livemigrate=true&storageid=d867446f-73d6-365c-bf50-27fdde7e2a6b&volumeid=d0cd5d41-f395-48d9-8bd6-3886f4f76c3e&response=json&sessionkey=PWQxaW5CBGIDG7HYLOQBdAk3RJg%3D&_=1373407314785
> 2013-07-09 08:36:33,906 DEBUG [cloud.async.AsyncJobManagerImpl]
> (1754543106@qtp-481326697-2:null) submit async job-24, details: AsyncJobVO
> {id:24, userId: 2, accountId: 2, sessionKey: null, instanceType: None,
> instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd,
> cmdOriginator: null, cmdInfo:
> {"response":"json","sessionkey":"PWQxaW5CBGIDG7HYLOQBdAk3RJg\u003d","cmdEventType":"VOLUME.MIGRATE","ctxUserId":"2","storageid":"d867446f-73d6-365c-bf50-27fdde7e2a6b","livemigrate":"true","httpmethod":"GET","volumeid":"d0cd5d41-f395-48d9-8bd6-3886f4f76c3e","_":"1373407314785","ctxAccountId":"2","ctxStartEventId":"92"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 52241838869,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-07-09 08:36:33,937 DEBUG [cloud.api.ApiServlet]
> (1754543106@qtp-481326697-2:null) ===END=== 10.217.252.54 -- GET
> command=migrateVolume&livemigrate=true&storageid=d867446f-73d6-365c-bf50-27fdde7e2a6b&volumeid=d0cd5d41-f395-48d9-8bd6-3886f4f76c3e&response=json&sessionkey=PWQxaW5CBGIDG7HYLOQBdAk3RJg%3D&_=137340731
[jira] [Resolved] (CLOUDSTACK-2524) Protect VNC port with password on KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fang Wang resolved CLOUDSTACK-2524. --- Resolution: Fixed > Protect VNC port with password on KVM > - > > Key: CLOUDSTACK-2524 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2524 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Fang Wang >Assignee: Fang Wang > > This is a best-practice security enhancement. > VNC port without password can be restricted to CPVM IP addresses or the > management network. That is what has been recommended so far, with protection > out of band of CloudStack. > With this enhancement CloudStack will be capable of using a password to > access VNC services on the KVM host. Then there would less need to protect > the management network out-of-band . -- 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-2524) Protect VNC port with password on KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13730120#comment-13730120 ] Fang Wang commented on CLOUDSTACK-2524: --- Submitted into the code already. > Protect VNC port with password on KVM > - > > Key: CLOUDSTACK-2524 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2524 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Fang Wang >Assignee: Fang Wang > > This is a best-practice security enhancement. > VNC port without password can be restricted to CPVM IP addresses or the > management network. That is what has been recommended so far, with protection > out of band of CloudStack. > With this enhancement CloudStack will be capable of using a password to > access VNC services on the KVM host. Then there would less need to protect > the management network out-of-band . -- 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-3759) [Automation] Attach volume on a vm deployed with startvm=False fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13726733#comment-13726733
]
Fang Wang edited comment on CLOUDSTACK-3759 at 8/1/13 6:47 PM:
---
Yes, Prasanna, I know manual test won't cause the bug.
(see my comment: Fang Wang added a comment - 25/Jul/13 22:59
manual test through UI works; only for API test, when set deployVM=stopped )
it only occurred by the API command setting the VM in stopped.
I fixed the issue after the findings, to fix the issue which could cause
exception with the VM state being STOPPED at deploy time, and by running a BVT
test with the fix, we can tell if it works. I'll run a BVT test myself.
was (Author: fangw):
Yes, Prasanna, I know manual test won't cause the bug.
(see my comment: Fang Wang added a comment - 25/Jul/13 22:59
manual test through UI works; only for API test, when set deployVM=stopped )
it only occurred by the API command setting the VM in stopped. I fixed the
issue after the findings, and by running a BVT test with the fix, we can tell
if it works. I'll run a BVT test myself.
> [Automation] Attach volume on a vm deployed with startvm=False fails
>
>
> Key: CLOUDSTACK-3759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3759
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.2.0
> Environment: KVM
> Automation
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: CLOUDSTACK-3759.rar
>
>
> Test cases failed from integration.component.test_stopped_vm.TestDeployVM
> Steps to reproduce
> --
> Step 1 : Create a VM from command line with start state is false
> Step 2 : Create a volume and attach the volume to stopped VM
> Actual Result
> Volume attachment failed;
> Observed below error automation test log
>
> attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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_stopped_vm.py",
> line 611, in test_06_deploy_startvm_attach_detach
> self.fail("Attach volume failed!")
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> Attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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] [Comment Edited] (CLOUDSTACK-3759) [Automation] Attach volume on a vm deployed with startvm=False fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13726733#comment-13726733
]
Fang Wang edited comment on CLOUDSTACK-3759 at 8/1/13 6:45 PM:
---
Yes, Prasanna, I know manual test won't cause the bug.
(see my comment: Fang Wang added a comment - 25/Jul/13 22:59
manual test through UI works; only for API test, when set deployVM=stopped )
it only occurred by the API command setting the VM in stopped. I fixed the
issue after the findings, and by running a BVT test with the fix, we can tell
if it works. I'll run a BVT test myself.
was (Author: fangw):
Yes, PRasanna, I know manual test won't cause the bug.
(see my comment: Fang Wang added a comment - 25/Jul/13 22:59
manual test through UI works; only for API test, when set deployVM=stopped )
it only occurred by the API command setting the VM in stopped. I fixed the
issue after the findings, and by running a BVT test with the fix, we can tell
if it works. I'll run a BVT test myself.
> [Automation] Attach volume on a vm deployed with startvm=False fails
>
>
> Key: CLOUDSTACK-3759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3759
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.2.0
> Environment: KVM
> Automation
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: CLOUDSTACK-3759.rar
>
>
> Test cases failed from integration.component.test_stopped_vm.TestDeployVM
> Steps to reproduce
> --
> Step 1 : Create a VM from command line with start state is false
> Step 2 : Create a volume and attach the volume to stopped VM
> Actual Result
> Volume attachment failed;
> Observed below error automation test log
>
> attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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_stopped_vm.py",
> line 611, in test_06_deploy_startvm_attach_detach
> self.fail("Attach volume failed!")
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> Attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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-3759) [Automation] Attach volume on a vm deployed with startvm=False fails
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13726733#comment-13726733
]
Fang Wang commented on CLOUDSTACK-3759:
---
Yes, PRasanna, I know manual test won't cause the bug.
(see my comment: Fang Wang added a comment - 25/Jul/13 22:59
manual test through UI works; only for API test, when set deployVM=stopped )
it only occurred by the API command setting the VM in stopped. I fixed the
issue after the findings, and by running a BVT test with the fix, we can tell
if it works. I'll run a BVT test myself.
> [Automation] Attach volume on a vm deployed with startvm=False fails
>
>
> Key: CLOUDSTACK-3759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3759
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.2.0
> Environment: KVM
> Automation
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: CLOUDSTACK-3759.rar
>
>
> Test cases failed from integration.component.test_stopped_vm.TestDeployVM
> Steps to reproduce
> --
> Step 1 : Create a VM from command line with start state is false
> Step 2 : Create a volume and attach the volume to stopped VM
> Actual Result
> Volume attachment failed;
> Observed below error automation test log
>
> attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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_stopped_vm.py",
> line 611, in test_06_deploy_startvm_attach_detach
> self.fail("Attach volume failed!")
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> Attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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-3790) KVM - Fail to create hourly daily weekly monthly recurring snapshot : pool is already active
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13724662#comment-13724662
]
Fang Wang commented on CLOUDSTACK-3790:
---
I checked the agent log on the host, and the snapshot schedule you set up.
The snapshot schedule you set up, at the hour, there are 2 snapshots taken.
While the 1st snapshot is taken,
the 2nd one is attempting to be taken and backed up to secondary storage. the
NFS mount/umount fails, because the mount point is in use.
For recurring snapshot, we do not need to take 2 snapshots at the same time.
> KVM - Fail to create hourly daily weekly monthly recurring snapshot : pool is
> already active
> -
>
> Key: CLOUDSTACK-3790
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3790
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: MS build
> CloudPlatform-4.2-275-rhel6.3.tar.gzCloudPlatform-4.2-246-rhel6.3.tar.gz
> host KVM buildCloudPlatform-4.2-275-rhel6.3.tar.gz
> CloudPlatform-4.2-246-rhel6.3.tar.gz
>Reporter: angeline shen
>Assignee: Fang Wang
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.log.2013-07-23.gz,
> management-server.log.2013-07-25.gz, management-server.log.2013-07-26.gz,
> management-server.log.gz, management-server.log.gz, Screenshot-CloudPlatform™
> - Mozilla Firefox-1.png, Screenshot-CloudPlatform™ - Mozilla Firefox-1.png,
> Screenshot-CloudPlatform™ - Mozilla Firefox-1.png, Screenshot-CloudPlatform™
> - Mozilla Firefox-2.png, Screenshot-CloudPlatform™ - Mozilla Firefox-3.png,
> Screenshot-CloudPlatform™ - Mozilla Firefox.png
>
>
> 1. advance zone. domain: d1domain admin: d1domain domain: d2
> user : d2user
> 2. login : admin . create VPC network & VMs with DATA disk
>login: d1domain. create VPC network & VMs with DATA disk
>login: d2user. create VPC network & VMs with DATA disk
> 3. login as each of above users.
> . setup HOURLY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at 50 minutes pass
> the hour.
> .setup DAILY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at 6:50 pm
> . setup WEEKLY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at Saturday 6:50 pm
> . setup MONTHLY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at 27th day of the
> month at 6:50 pm
>
> Result:
> some HOURLY, DAILY, MONTHLY snapshots generated with status CreateOnPrimary
> ,
> Failed to create snapshot due to pool is already active .
> some WEEKLY snapshots generated with status Allocated.
> 2013-07-23 22:04:49,920 DEBUG [agent.transport.Request]
> (Job-Executor-42:job-56 = [ 3def22de-176e-45a7-b72b-98aaef57b906 ]) Seq
> 1-1490617925: Sending { Cmd , MgmtId: 6655051826959, via: 1, Ver: v1, Flags:
> 100011, [{"or
> g.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"/mnt/79884886-a3ee-31a7-856c-805e18c48f88/b52e5c2b-fc3e-4292-bda5-cb961efb94c7/c733fc4e-4d16-481f-9
> e20-2ed2519d6b3d","volume":{"uuid":"a39f007b-b014-4e6c-a3fa-8bce7a9ba213","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"79884886-a3ee-31a7-856c-805e18c48f88","id":1,"poo
> lType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/angie/primary/kvm63","port":2049}},"name":"ROOT-13","size":147456,"path":"b52e5c2b-fc3e-4292-bda5-cb961efb94c7","volumeId":15,"vmName":"i-4-13-VM",
> "accountId":4,"format":"QCOW2","id":15},"parentSnapshotPath":"/mnt/79884886-a3ee-31a7-856c-805e18c48f88/b52e5c2b-fc3e-4292-bda5-cb961efb94c7/29669eb5-1525-4745-81c4-6ca6ad239af0","dataStore":{"org.apache.cloudstack.stor
> age.to.PrimaryDataStoreTO":{"uuid":"79884886-a3ee-31a7-856c-805e18c48f88","id":1,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/angie/primary/kvm63","port":2049}},"vmName":"i-4-13-VM","name"
> :"z1vpc3G3d2userV32_ROOT-13_20130724050449","hypervisorType":"None","id":28}},"destTO":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"snapshots/4/15","volume":{"uuid":"a39f007b-b014-4e6c-a3fa-8bce7a9ba213
> ","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"79884886-a3ee-31a7-856c-805e18c48f88","id":1,"poolType":"NetworkFile
[jira] [Commented] (CLOUDSTACK-3788) [KVM] Weekly Snapshot got stuck in "Allocated State"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13723287#comment-13723287 ] Fang Wang commented on CLOUDSTACK-3788: --- it occurs in cs-3790 also. I am debugging both of them on a KVM host now. These 2 bugs are related. > [KVM] Weekly Snapshot got stuck in "Allocated State" > > > Key: CLOUDSTACK-3788 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3788 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot >Affects Versions: 4.2.0 >Reporter: Chandan Purushothama >Assignee: Fang Wang >Priority: Critical > Fix For: 4.2.0 > > Attachments: management-server.log.2013-07-23.gz, > mysql_cloudstack_dump.zip > > > Weekly Snapshot stuck in Allocated State: > mysql> select * from snapshots where name like > "Atoms-VM-1_ROOT-6_20130723235146"; > ++++---+---+--+---+--+--+--+---+--++-+-++--++--+-+-+---+ > | id | data_center_id | account_id | domain_id | volume_id | disk_offering_id > | status| path | name | uuid >| snapshot_type | type_description | size | created >| removed | backup_snap_id | swift_id | sechost_id | prev_snap_id | > hypervisor_type | version | s3_id | > ++++---+---+--+---+--+--+--+---+--++-+-++--++--+-+-+---+ > | 24 | 1 | 3 | 1 | 6 |1 > | Destroyed | NULL | Atoms-VM-1_ROOT-6_20130723235146 | > 08a0d2aa-9635-41cd-ba54-5367303bceac | 3 | HOURLY | > 147456 | 2013-07-23 23:51:46 | NULL| NULL | NULL | > NULL | NULL | KVM | 2.2 | NULL | > | 25 | 1 | 3 | 1 | 6 |1 > | Allocated | NULL | Atoms-VM-1_ROOT-6_20130723235146 | > 1e24a056-be38-4b55-845b-a5672b9fa93c | 5 | WEEKLY | > 147456 | 2013-07-23 23:51:46 | NULL| NULL | NULL | > NULL | NULL | KVM | 2.2 | NULL | > ++++---+---+--+---+--+--+--+---+--++-+-++--++--+-+-+---+ > 2 rows in set (0.04 sec) > Attached Management Server logs and cloud database dump -- 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-3790) KVM - Fail to create hourly daily weekly monthly recurring snapshot : pool is already active
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13723286#comment-13723286
]
Fang Wang commented on CLOUDSTACK-3790:
---
So far, it looks ok, I have not encountered it yet.
> KVM - Fail to create hourly daily weekly monthly recurring snapshot : pool is
> already active
> -
>
> Key: CLOUDSTACK-3790
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3790
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: MS build
> CloudPlatform-4.2-275-rhel6.3.tar.gzCloudPlatform-4.2-246-rhel6.3.tar.gz
> host KVM buildCloudPlatform-4.2-275-rhel6.3.tar.gz
> CloudPlatform-4.2-246-rhel6.3.tar.gz
>Reporter: angeline shen
>Assignee: Fang Wang
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.log.2013-07-23.gz,
> management-server.log.2013-07-25.gz, management-server.log.2013-07-26.gz,
> management-server.log.gz, management-server.log.gz, Screenshot-CloudPlatform™
> - Mozilla Firefox-1.png, Screenshot-CloudPlatform™ - Mozilla Firefox-1.png,
> Screenshot-CloudPlatform™ - Mozilla Firefox-1.png, Screenshot-CloudPlatform™
> - Mozilla Firefox-2.png, Screenshot-CloudPlatform™ - Mozilla Firefox-3.png,
> Screenshot-CloudPlatform™ - Mozilla Firefox.png
>
>
> 1. advance zone. domain: d1domain admin: d1domain domain: d2
> user : d2user
> 2. login : admin . create VPC network & VMs with DATA disk
>login: d1domain. create VPC network & VMs with DATA disk
>login: d2user. create VPC network & VMs with DATA disk
> 3. login as each of above users.
> . setup HOURLY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at 50 minutes pass
> the hour.
> .setup DAILY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at 6:50 pm
> . setup WEEKLY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at Saturday 6:50 pm
> . setup MONTHLY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at 27th day of the
> month at 6:50 pm
>
> Result:
> some HOURLY, DAILY, MONTHLY snapshots generated with status CreateOnPrimary
> ,
> Failed to create snapshot due to pool is already active .
> some WEEKLY snapshots generated with status Allocated.
> 2013-07-23 22:04:49,920 DEBUG [agent.transport.Request]
> (Job-Executor-42:job-56 = [ 3def22de-176e-45a7-b72b-98aaef57b906 ]) Seq
> 1-1490617925: Sending { Cmd , MgmtId: 6655051826959, via: 1, Ver: v1, Flags:
> 100011, [{"or
> g.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"/mnt/79884886-a3ee-31a7-856c-805e18c48f88/b52e5c2b-fc3e-4292-bda5-cb961efb94c7/c733fc4e-4d16-481f-9
> e20-2ed2519d6b3d","volume":{"uuid":"a39f007b-b014-4e6c-a3fa-8bce7a9ba213","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"79884886-a3ee-31a7-856c-805e18c48f88","id":1,"poo
> lType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/angie/primary/kvm63","port":2049}},"name":"ROOT-13","size":147456,"path":"b52e5c2b-fc3e-4292-bda5-cb961efb94c7","volumeId":15,"vmName":"i-4-13-VM",
> "accountId":4,"format":"QCOW2","id":15},"parentSnapshotPath":"/mnt/79884886-a3ee-31a7-856c-805e18c48f88/b52e5c2b-fc3e-4292-bda5-cb961efb94c7/29669eb5-1525-4745-81c4-6ca6ad239af0","dataStore":{"org.apache.cloudstack.stor
> age.to.PrimaryDataStoreTO":{"uuid":"79884886-a3ee-31a7-856c-805e18c48f88","id":1,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/angie/primary/kvm63","port":2049}},"vmName":"i-4-13-VM","name"
> :"z1vpc3G3d2userV32_ROOT-13_20130724050449","hypervisorType":"None","id":28}},"destTO":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"snapshots/4/15","volume":{"uuid":"a39f007b-b014-4e6c-a3fa-8bce7a9ba213
> ","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"79884886-a3ee-31a7-856c-805e18c48f88","id":1,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/
> angie/primary/kvm63","port":2049}},"name":"ROOT-13","size":147456,"path":"b52e5c2b-fc3e-4292-bda5-cb961efb94c7","volumeId":15,"vmName":"i-4-13-VM","accountId":4,"format":"QCOW2","id":15},"parentSnapshotPath":"snapshots/
> 4/15/29669eb5-1525-4745-81c4-6ca6ad239af0","dataStore":{"com.cloud.agent.
[jira] [Commented] (CLOUDSTACK-3790) KVM - Fail to create hourly daily weekly monthly recurring snapshot : pool is already active
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13723284#comment-13723284
]
Fang Wang commented on CLOUDSTACK-3790:
---
I turned on the debug on your kvm host, and will try to catch it when it
occurs.
> KVM - Fail to create hourly daily weekly monthly recurring snapshot : pool is
> already active
> -
>
> Key: CLOUDSTACK-3790
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3790
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: MS build
> CloudPlatform-4.2-275-rhel6.3.tar.gzCloudPlatform-4.2-246-rhel6.3.tar.gz
> host KVM buildCloudPlatform-4.2-275-rhel6.3.tar.gz
> CloudPlatform-4.2-246-rhel6.3.tar.gz
>Reporter: angeline shen
>Assignee: Fang Wang
>Priority: Critical
> Fix For: 4.2.0
>
> Attachments: management-server.log.2013-07-23.gz,
> management-server.log.2013-07-25.gz, management-server.log.2013-07-26.gz,
> management-server.log.gz, management-server.log.gz, Screenshot-CloudPlatform™
> - Mozilla Firefox-1.png, Screenshot-CloudPlatform™ - Mozilla Firefox-1.png,
> Screenshot-CloudPlatform™ - Mozilla Firefox-1.png, Screenshot-CloudPlatform™
> - Mozilla Firefox-2.png, Screenshot-CloudPlatform™ - Mozilla Firefox-3.png,
> Screenshot-CloudPlatform™ - Mozilla Firefox.png
>
>
> 1. advance zone. domain: d1domain admin: d1domain domain: d2
> user : d2user
> 2. login : admin . create VPC network & VMs with DATA disk
>login: d1domain. create VPC network & VMs with DATA disk
>login: d2user. create VPC network & VMs with DATA disk
> 3. login as each of above users.
> . setup HOURLY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at 50 minutes pass
> the hour.
> .setup DAILY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at 6:50 pm
> . setup WEEKLY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at Saturday 6:50 pm
> . setup MONTHLY recurring snapshots for all ROOT and DATA disks
> to same recurring schedule,for example , all at 27th day of the
> month at 6:50 pm
>
> Result:
> some HOURLY, DAILY, MONTHLY snapshots generated with status CreateOnPrimary
> ,
> Failed to create snapshot due to pool is already active .
> some WEEKLY snapshots generated with status Allocated.
> 2013-07-23 22:04:49,920 DEBUG [agent.transport.Request]
> (Job-Executor-42:job-56 = [ 3def22de-176e-45a7-b72b-98aaef57b906 ]) Seq
> 1-1490617925: Sending { Cmd , MgmtId: 6655051826959, via: 1, Ver: v1, Flags:
> 100011, [{"or
> g.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"/mnt/79884886-a3ee-31a7-856c-805e18c48f88/b52e5c2b-fc3e-4292-bda5-cb961efb94c7/c733fc4e-4d16-481f-9
> e20-2ed2519d6b3d","volume":{"uuid":"a39f007b-b014-4e6c-a3fa-8bce7a9ba213","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"79884886-a3ee-31a7-856c-805e18c48f88","id":1,"poo
> lType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/angie/primary/kvm63","port":2049}},"name":"ROOT-13","size":147456,"path":"b52e5c2b-fc3e-4292-bda5-cb961efb94c7","volumeId":15,"vmName":"i-4-13-VM",
> "accountId":4,"format":"QCOW2","id":15},"parentSnapshotPath":"/mnt/79884886-a3ee-31a7-856c-805e18c48f88/b52e5c2b-fc3e-4292-bda5-cb961efb94c7/29669eb5-1525-4745-81c4-6ca6ad239af0","dataStore":{"org.apache.cloudstack.stor
> age.to.PrimaryDataStoreTO":{"uuid":"79884886-a3ee-31a7-856c-805e18c48f88","id":1,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/angie/primary/kvm63","port":2049}},"vmName":"i-4-13-VM","name"
> :"z1vpc3G3d2userV32_ROOT-13_20130724050449","hypervisorType":"None","id":28}},"destTO":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"snapshots/4/15","volume":{"uuid":"a39f007b-b014-4e6c-a3fa-8bce7a9ba213
> ","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"79884886-a3ee-31a7-856c-805e18c48f88","id":1,"poolType":"NetworkFilesystem","host":"10.223.110.232","path":"/export/home/
> angie/primary/kvm63","port":2049}},"name":"ROOT-13","size":147456,"path":"b52e5c2b-fc3e-4292-bda5-cb961efb94c7","volumeId":15,"vmName":"i-4-13-VM","accountId":4,"format":"QCOW2","id":15},"parentSnapshotPath":"snapshots/
> 4/15/29669eb5-1525-4745-81c4-6ca6ad239af0
[jira] [Updated] (CLOUDSTACK-3759) [Automation] Failed to attach volume to VM, while vm are in stopped state
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fang Wang updated CLOUDSTACK-3759:
--
Status: Ready To Review (was: In Progress)
> [Automation] Failed to attach volume to VM, while vm are in stopped state
> --
>
> Key: CLOUDSTACK-3759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3759
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.2.0
> Environment: KVM
> Automation
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: CLOUDSTACK-3759.rar
>
>
> Test cases failed from integration.component.test_stopped_vm.TestDeployVM
> Steps to reproduce
> --
> Step 1 : Create a VM from command line with start state is false
> Step 2 : Create a volume and attach the volume to stopped VM
> Actual Result
> Volume attachment failed;
> Observed below error automation test log
>
> attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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_stopped_vm.py",
> line 611, in test_06_deploy_startvm_attach_detach
> self.fail("Attach volume failed!")
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> Attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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-3759) [Automation] Failed to attach volume to VM, while vm are in stopped state
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13722935#comment-13722935
]
Fang Wang commented on CLOUDSTACK-3759:
---
The patch is not in yet. Edison, would you help check in the patch? thanks.
> [Automation] Failed to attach volume to VM, while vm are in stopped state
> --
>
> Key: CLOUDSTACK-3759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3759
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.2.0
> Environment: KVM
> Automation
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: CLOUDSTACK-3759.rar
>
>
> Test cases failed from integration.component.test_stopped_vm.TestDeployVM
> Steps to reproduce
> --
> Step 1 : Create a VM from command line with start state is false
> Step 2 : Create a volume and attach the volume to stopped VM
> Actual Result
> Volume attachment failed;
> Observed below error automation test log
>
> attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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_stopped_vm.py",
> line 611, in test_06_deploy_startvm_attach_detach
> self.fail("Attach volume failed!")
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> Attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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-671) Volume snapshot enhancements for VMware
[ https://issues.apache.org/jira/browse/CLOUDSTACK-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13721436#comment-13721436 ] Fang Wang commented on CLOUDSTACK-671: -- Submitted the code patch for review, and pushed in by Kelven to master: commit f1012410503edf4f7fd624ecf4f5004bea0ac9a1 Author: Kelven Yang Date: Wed May 1 17:40:23 2013 -0700 Apply patch for https://reviews.apache.org/r/10892/ > Volume snapshot enhancements for VMware > --- > > Key: CLOUDSTACK-671 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-671 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Hari Kannan >Assignee: Fang Wang > Fix For: 4.2.0 > > > Requirements : > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Volume+snapshot+enhancements+for+VMware > Functional Spec: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+VMware+volume+snapshot+improvements -- 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-3430) volume migration on zone wide primary storage pool failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fang Wang updated CLOUDSTACK-3430:
--
Assignee: Fang Wang
> volume migration on zone wide primary storage pool failing
> --
>
> Key: CLOUDSTACK-3430
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3430
> 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: vmware on cloudstack master
>Reporter: Venkata Siva Vijayendra Bhamidipati
>Assignee: Fang Wang
>
> Create a zone with zone wide primary storage.
> Bring up system VMs, create a guest VM.
> Add another zone wide primary storage to the zone.
> Attempt to migrate the root volume of the guest VM from its current zone wide
> primary storage to the new zone wide primary storage. The operation fails,
> and the logs show the following trace:
> 2013-07-09 08:36:29,943 DEBUG [cloud.api.ApiServlet]
> (1754543106@qtp-481326697-2:null) ===START=== 10.217.252.54 -- GET
> command=findStoragePoolsForMigration&id=d0cd5d41-f395-48d9-8bd6-3886f4f76c3e&response=json&sessionkey=PWQxaW5CBGIDG7HYLOQBdAk3RJg%3D&_=1373407310956
> 2013-07-09 08:36:30,492 DEBUG [storage.allocator.LocalStoragePoolAllocator]
> (1754543106@qtp-481326697-2:null) LocalStoragePoolAllocator trying to find
> storage pool to fit the vm
> 2013-07-09 08:36:30,496 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator]
> (1754543106@qtp-481326697-2:null) ClusterScopeStoragePoolAllocator looking
> for storage pool
> 2013-07-09 08:36:30,497 DEBUG
> [storage.allocator.ZoneWideStoragePoolAllocator]
> (1754543106@qtp-481326697-2:null) ZoneWideStoragePoolAllocator to find
> storage pool
> 2013-07-09 08:36:30,660 DEBUG [cloud.storage.StorageManagerImpl]
> (1754543106@qtp-481326697-2:null) Checking pool 1 for storage, totalSize:
> 11810778316800, usedBytes: 8451350200320, usedPct: 0.7155625119386544,
> disable threshold: 0.85
> 2013-07-09 08:36:30,791 DEBUG [cloud.storage.StorageManagerImpl]
> (1754543106@qtp-481326697-2:null) Checking pool: 1 for volume allocation
> [Vol[10|vm=5|ROOT]], maxSize : 23621556633600, totalAllocatedSize : 0,
> askingSize : 0, allocated disable threshold: 0.85
> 2013-07-09 08:36:30,842 DEBUG [cloud.storage.StorageManagerImpl]
> (1754543106@qtp-481326697-2:null) Checking pool 2 for storage, totalSize:
> 11810778316800, usedBytes: 8451350200320, usedPct: 0.7155625119386544,
> disable threshold: 0.85
> 2013-07-09 08:36:30,878 DEBUG [cloud.storage.StorageManagerImpl]
> (1754543106@qtp-481326697-2:null) Checking pool: 2 for volume allocation
> [Vol[10|vm=5|ROOT]], maxSize : 23621556633600, totalAllocatedSize : 0,
> askingSize : 0, allocated disable threshold: 0.85
> 2013-07-09 08:36:31,204 DEBUG [cloud.api.ApiServlet]
> (1754543106@qtp-481326697-2:null) ===END=== 10.217.252.54 -- GET
> command=findStoragePoolsForMigration&id=d0cd5d41-f395-48d9-8bd6-3886f4f76c3e&response=json&sessionkey=PWQxaW5CBGIDG7HYLOQBdAk3RJg%3D&_=1373407310956
> 2013-07-09 08:36:33,437 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-29:null) Ping from 1
> 2013-07-09 08:36:33,671 DEBUG [cloud.api.ApiServlet]
> (1754543106@qtp-481326697-2:null) ===START=== 10.217.252.54 -- GET
> command=migrateVolume&livemigrate=true&storageid=d867446f-73d6-365c-bf50-27fdde7e2a6b&volumeid=d0cd5d41-f395-48d9-8bd6-3886f4f76c3e&response=json&sessionkey=PWQxaW5CBGIDG7HYLOQBdAk3RJg%3D&_=1373407314785
> 2013-07-09 08:36:33,906 DEBUG [cloud.async.AsyncJobManagerImpl]
> (1754543106@qtp-481326697-2:null) submit async job-24, details: AsyncJobVO
> {id:24, userId: 2, accountId: 2, sessionKey: null, instanceType: None,
> instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd,
> cmdOriginator: null, cmdInfo:
> {"response":"json","sessionkey":"PWQxaW5CBGIDG7HYLOQBdAk3RJg\u003d","cmdEventType":"VOLUME.MIGRATE","ctxUserId":"2","storageid":"d867446f-73d6-365c-bf50-27fdde7e2a6b","livemigrate":"true","httpmethod":"GET","volumeid":"d0cd5d41-f395-48d9-8bd6-3886f4f76c3e","_":"1373407314785","ctxAccountId":"2","ctxStartEventId":"92"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 52241838869,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-07-09 08:36:33,937 DEBUG [cloud.api.ApiServlet]
> (1754543106@qtp-481326697-2:null) ===END=== 10.217.252.54 -- GET
> command=migrateVolume&livemigrate=true&storageid=d867446f-73d6-365c-bf50-27fdde7e2a6b&volumeid=d0cd5d41-f395-48d9-8bd6-3886f4f76c3e&response=json&sessionkey=PWQxaW5CBGIDG7HYLOQBdAk3RJg%3D&_=1373407314785
> 2013-07-09 08:36:34,045 DEBUG [cl
[jira] [Commented] (CLOUDSTACK-671) Volume snapshot enhancements for VMware
[ https://issues.apache.org/jira/browse/CLOUDSTACK-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13721429#comment-13721429 ] Fang Wang commented on CLOUDSTACK-671: -- checked into master on 5/2/2013. . https://reviews.apache.org/r/10892/ > Volume snapshot enhancements for VMware > --- > > Key: CLOUDSTACK-671 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-671 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Hari Kannan >Assignee: Fang Wang > Fix For: 4.2.0 > > > Requirements : > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Volume+snapshot+enhancements+for+VMware > Functional Spec: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+VMware+volume+snapshot+improvements -- 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-3430) volume migration on zone wide primary storage pool failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13721409#comment-13721409
]
Fang Wang commented on CLOUDSTACK-3430:
---
This is not a major issue. I checked with Vijay, and the problem may be solved.
Sateesh should be the better person to take a look.
> volume migration on zone wide primary storage pool failing
> --
>
> Key: CLOUDSTACK-3430
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3430
> 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: vmware on cloudstack master
>Reporter: Venkata Siva Vijayendra Bhamidipati
>
> Create a zone with zone wide primary storage.
> Bring up system VMs, create a guest VM.
> Add another zone wide primary storage to the zone.
> Attempt to migrate the root volume of the guest VM from its current zone wide
> primary storage to the new zone wide primary storage. The operation fails,
> and the logs show the following trace:
> 2013-07-09 08:36:29,943 DEBUG [cloud.api.ApiServlet]
> (1754543106@qtp-481326697-2:null) ===START=== 10.217.252.54 -- GET
> command=findStoragePoolsForMigration&id=d0cd5d41-f395-48d9-8bd6-3886f4f76c3e&response=json&sessionkey=PWQxaW5CBGIDG7HYLOQBdAk3RJg%3D&_=1373407310956
> 2013-07-09 08:36:30,492 DEBUG [storage.allocator.LocalStoragePoolAllocator]
> (1754543106@qtp-481326697-2:null) LocalStoragePoolAllocator trying to find
> storage pool to fit the vm
> 2013-07-09 08:36:30,496 DEBUG
> [storage.allocator.ClusterScopeStoragePoolAllocator]
> (1754543106@qtp-481326697-2:null) ClusterScopeStoragePoolAllocator looking
> for storage pool
> 2013-07-09 08:36:30,497 DEBUG
> [storage.allocator.ZoneWideStoragePoolAllocator]
> (1754543106@qtp-481326697-2:null) ZoneWideStoragePoolAllocator to find
> storage pool
> 2013-07-09 08:36:30,660 DEBUG [cloud.storage.StorageManagerImpl]
> (1754543106@qtp-481326697-2:null) Checking pool 1 for storage, totalSize:
> 11810778316800, usedBytes: 8451350200320, usedPct: 0.7155625119386544,
> disable threshold: 0.85
> 2013-07-09 08:36:30,791 DEBUG [cloud.storage.StorageManagerImpl]
> (1754543106@qtp-481326697-2:null) Checking pool: 1 for volume allocation
> [Vol[10|vm=5|ROOT]], maxSize : 23621556633600, totalAllocatedSize : 0,
> askingSize : 0, allocated disable threshold: 0.85
> 2013-07-09 08:36:30,842 DEBUG [cloud.storage.StorageManagerImpl]
> (1754543106@qtp-481326697-2:null) Checking pool 2 for storage, totalSize:
> 11810778316800, usedBytes: 8451350200320, usedPct: 0.7155625119386544,
> disable threshold: 0.85
> 2013-07-09 08:36:30,878 DEBUG [cloud.storage.StorageManagerImpl]
> (1754543106@qtp-481326697-2:null) Checking pool: 2 for volume allocation
> [Vol[10|vm=5|ROOT]], maxSize : 23621556633600, totalAllocatedSize : 0,
> askingSize : 0, allocated disable threshold: 0.85
> 2013-07-09 08:36:31,204 DEBUG [cloud.api.ApiServlet]
> (1754543106@qtp-481326697-2:null) ===END=== 10.217.252.54 -- GET
> command=findStoragePoolsForMigration&id=d0cd5d41-f395-48d9-8bd6-3886f4f76c3e&response=json&sessionkey=PWQxaW5CBGIDG7HYLOQBdAk3RJg%3D&_=1373407310956
> 2013-07-09 08:36:33,437 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-29:null) Ping from 1
> 2013-07-09 08:36:33,671 DEBUG [cloud.api.ApiServlet]
> (1754543106@qtp-481326697-2:null) ===START=== 10.217.252.54 -- GET
> command=migrateVolume&livemigrate=true&storageid=d867446f-73d6-365c-bf50-27fdde7e2a6b&volumeid=d0cd5d41-f395-48d9-8bd6-3886f4f76c3e&response=json&sessionkey=PWQxaW5CBGIDG7HYLOQBdAk3RJg%3D&_=1373407314785
> 2013-07-09 08:36:33,906 DEBUG [cloud.async.AsyncJobManagerImpl]
> (1754543106@qtp-481326697-2:null) submit async job-24, details: AsyncJobVO
> {id:24, userId: 2, accountId: 2, sessionKey: null, instanceType: None,
> instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.volume.MigrateVolumeCmd,
> cmdOriginator: null, cmdInfo:
> {"response":"json","sessionkey":"PWQxaW5CBGIDG7HYLOQBdAk3RJg\u003d","cmdEventType":"VOLUME.MIGRATE","ctxUserId":"2","storageid":"d867446f-73d6-365c-bf50-27fdde7e2a6b","livemigrate":"true","httpmethod":"GET","volumeid":"d0cd5d41-f395-48d9-8bd6-3886f4f76c3e","_":"1373407314785","ctxAccountId":"2","ctxStartEventId":"92"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 52241838869,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-07-09 08:36:33,937 DEBUG [cloud.api.ApiServlet]
> (1754543106@qtp-481326697-2:null) ===END=== 10.217.252.54 -- GET
> command=migrateVolume&livemigrate=true&storageid=d867446f-73d6-365c-bf50-27fdde7e2a6b&volumei
[jira] [Commented] (CLOUDSTACK-3759) [Automation] Failed to attach volume to VM, while vm are in stopped state
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13720217#comment-13720217
]
Fang Wang commented on CLOUDSTACK-3759:
---
commit a57c5b4f7cde78e8ad8f98481fdcb5a10acd3de8
Author: Fang Wang
Date: Thu Jul 25 16:03:56 2013 -0700
CLOUDSTACK-3759 [Automation] Failed to attach volume to VM, while vm are in
stopped state
Fix the null pointer.
Post the fix to the review board: https://reviews.apache.org/r/12958/
> [Automation] Failed to attach volume to VM, while vm are in stopped state
> --
>
> Key: CLOUDSTACK-3759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3759
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.2.0
> Environment: KVM
> Automation
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: CLOUDSTACK-3759.rar
>
>
> Test cases failed from integration.component.test_stopped_vm.TestDeployVM
> Steps to reproduce
> --
> Step 1 : Create a VM from command line with start state is false
> Step 2 : Create a volume and attach the volume to stopped VM
> Actual Result
> Volume attachment failed;
> Observed below error automation test log
>
> attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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_stopped_vm.py",
> line 611, in test_06_deploy_startvm_attach_detach
> self.fail("Attach volume failed!")
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> Attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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] [Resolved] (CLOUDSTACK-3759) [Automation] Failed to attach volume to VM, while vm are in stopped state
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fang Wang resolved CLOUDSTACK-3759.
---
Resolution: Fixed
checkin the fix to 4.2.0 and post to the review board.
> [Automation] Failed to attach volume to VM, while vm are in stopped state
> --
>
> Key: CLOUDSTACK-3759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3759
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.2.0
> Environment: KVM
> Automation
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: CLOUDSTACK-3759.rar
>
>
> Test cases failed from integration.component.test_stopped_vm.TestDeployVM
> Steps to reproduce
> --
> Step 1 : Create a VM from command line with start state is false
> Step 2 : Create a volume and attach the volume to stopped VM
> Actual Result
> Volume attachment failed;
> Observed below error automation test log
>
> attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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_stopped_vm.py",
> line 611, in test_06_deploy_startvm_attach_detach
> self.fail("Attach volume failed!")
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> Attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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-3759) [Automation] Failed to attach volume to VM, while vm are in stopped state
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13720119#comment-13720119
]
Fang Wang commented on CLOUDSTACK-3759:
---
manual test through UI works; only for API test, when set deployVM=stopped
> [Automation] Failed to attach volume to VM, while vm are in stopped state
> --
>
> Key: CLOUDSTACK-3759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3759
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.2.0
> Environment: KVM
> Automation
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: CLOUDSTACK-3759.rar
>
>
> Test cases failed from integration.component.test_stopped_vm.TestDeployVM
> Steps to reproduce
> --
> Step 1 : Create a VM from command line with start state is false
> Step 2 : Create a volume and attach the volume to stopped VM
> Actual Result
> Volume attachment failed;
> Observed below error automation test log
>
> attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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_stopped_vm.py",
> line 611, in test_06_deploy_startvm_attach_detach
> self.fail("Attach volume failed!")
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> Attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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-3759) [Automation] Failed to attach volume to VM, while vm are in stopped state
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13719148#comment-13719148
]
Fang Wang commented on CLOUDSTACK-3759:
---
Rayees,
I did a manually test:
1. create a new VM instance (fang-vm1) (on the zone 2 on your machine);
2. Create a new vol (fang-vol1);
3. wait for the VM come up, then stop the VM;
4. after the VM stop completes, I did a vol attach, and it works. no error
> [Automation] Failed to attach volume to VM, while vm are in stopped state
> --
>
> Key: CLOUDSTACK-3759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3759
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.2.0
> Environment: KVM
> Automation
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: CLOUDSTACK-3759.rar
>
>
> Test cases failed from integration.component.test_stopped_vm.TestDeployVM
> This issue is reproducible manually;
> Steps to reproduce
> --
> Step 1 : Create a VM
> Step 2 : Stop VM
> Step 3 : Create a volume and attach the volume to stoped VM
> Actual Result
> Volume attachment failed;
> Observed below error automation test log
>
> attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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_stopped_vm.py",
> line 611, in test_06_deploy_startvm_attach_detach
> self.fail("Attach volume failed!")
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> Attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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] [Updated] (CLOUDSTACK-3759) [Automation] Failed to attach volume to VM, while vm are in stopped state
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fang Wang updated CLOUDSTACK-3759:
--
Assignee: Fang Wang
> [Automation] Failed to attach volume to VM, while vm are in stopped state
> --
>
> Key: CLOUDSTACK-3759
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3759
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.2.0
> Environment: KVM
> Automation
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
>
> Test cases failed from integration.component.test_stopped_vm.TestDeployVM
> This issue is reproducible manually;
> Steps to reproduce
> --
> Step 1 : Create a VM
> Step 2 : Stop VM
> Step 3 : Create a volume and attach the volume to stoped VM
> Actual Result
> Volume attachment failed;
> Observed below error automation test log
>
> attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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_stopped_vm.py",
> line 611, in test_06_deploy_startvm_attach_detach
> self.fail("Attach volume failed!")
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> Attach volume failed!
> >> begin captured logging <<
> testclient.testcase.TestDeployVM: DEBUG: Deploying instance in the account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Deployed instance in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Verify listVirtualMachines response
> for virtual machine: c90e1365-702a-4a68-86d6-f5d75437b623
> testclient.testcase.TestDeployVM: DEBUG: Creating a volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Created volume in account:
> test-S35RTQ
> testclient.testcase.TestDeployVM: DEBUG: Attaching volume to instance:
> c90e1365-702a-4a68-86d6-f5d75437b623
> - >> 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] [Updated] (CLOUDSTACK-2904) After volume migration on Vmware, taking a snapshot, and then volume migration fails on this new volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fang Wang updated CLOUDSTACK-2904: -- Assignee: Sateesh Chodapuneedi (was: Fang Wang) > After volume migration on Vmware, taking a snapshot, and then volume > migration fails on this new volume > --- > > Key: CLOUDSTACK-2904 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2904 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Environment: master build, or vmware-storage-migration branch with > Vmware host >Reporter: Fang Wang >Assignee: Sateesh Chodapuneedi >Priority: Critical > > Create a simple VM with a root volume. > Migrate the root volume to another primary storage. > we see four vmdk files getting created in the VM folder on the new primary. > Two are uuid-delta.vmdk and uuid.vmdk style files. The other two are the > ROOT-x-y-delta.vmdk and ROOT-x-y.vmdk files. > take a snapshot of the root volume via the cloudstack GUI. What we see is > that the ROOT-x-y* files are getting deleted from the VM folder in the new > primary. Additionally, the VM’s root disk is getting changed to the other > uuid.vmdk file. > when we now attempt to migrate this volume again, it will fail saying that it > cannot find the ROOT-x-y disk. -- 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-3788) [KVM] Weekly Snapshot got stuck in "Allocated State"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fang Wang updated CLOUDSTACK-3788: -- Assignee: Fang Wang > [KVM] Weekly Snapshot got stuck in "Allocated State" > > > Key: CLOUDSTACK-3788 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3788 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot >Affects Versions: 4.2.0 >Reporter: Chandan Purushothama >Assignee: Fang Wang >Priority: Critical > Fix For: 4.2.0 > > Attachments: management-server.log.2013-07-23.gz, > mysql_cloudstack_dump.zip > > > Weekly Snapshot stuck in Allocated State: > mysql> select * from snapshots where name like > "Atoms-VM-1_ROOT-6_20130723235146"; > ++++---+---+--+---+--+--+--+---+--++-+-++--++--+-+-+---+ > | id | data_center_id | account_id | domain_id | volume_id | disk_offering_id > | status| path | name | uuid >| snapshot_type | type_description | size | created >| removed | backup_snap_id | swift_id | sechost_id | prev_snap_id | > hypervisor_type | version | s3_id | > ++++---+---+--+---+--+--+--+---+--++-+-++--++--+-+-+---+ > | 24 | 1 | 3 | 1 | 6 |1 > | Destroyed | NULL | Atoms-VM-1_ROOT-6_20130723235146 | > 08a0d2aa-9635-41cd-ba54-5367303bceac | 3 | HOURLY | > 147456 | 2013-07-23 23:51:46 | NULL| NULL | NULL | > NULL | NULL | KVM | 2.2 | NULL | > | 25 | 1 | 3 | 1 | 6 |1 > | Allocated | NULL | Atoms-VM-1_ROOT-6_20130723235146 | > 1e24a056-be38-4b55-845b-a5672b9fa93c | 5 | WEEKLY | > 147456 | 2013-07-23 23:51:46 | NULL| NULL | NULL | > NULL | NULL | KVM | 2.2 | NULL | > ++++---+---+--+---+--+--+--+---+--++-+-++--++--+-+-+---+ > 2 rows in set (0.04 sec) > Attached Management Server logs and cloud database dump -- 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-2725) [Automation] Re-attaching volume on VM failing in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13718964#comment-13718964
]
Fang Wang commented on CLOUDSTACK-2725:
---
Delay will not help. Delay is to make sure the VM are in the correct state,
which is already checked in the code.
We should add tis in the doc, so that with this libvirt exception, users know
to check the hotplug on the VM.
> [Automation] Re-attaching volume on VM failing in KVM
> -
>
> Key: CLOUDSTACK-2725
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2725
> 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: Automation environment KVM
> Found in master also (8d1189c2ae87216bc1c4a1443f75e9a8629abdc2)
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
> Fix For: 4.2.0
>
> Attachments: CLOUDSTACK-2725.rar
>
>
> Below two test case failing from BVT
> integration.smoke.test_volumes.TestVolumes.test_08_resize_volume
> integration.smoke.test_volumes.TestVolumes.test_09_delete_detached_volume
> Steps to reproduce
> Step 1 : Create an account, service offering, create volume, create VM
> Step 2 : Attach volume to VM ,
> Step 3 : Detach volume
> Step 4 : Attach volume to VM again
> Actual result
> Attachment failed with below error
> 2013-05-28 13:45:39,101 DEBUG [agent.transport.Request]
> (Job-Executor-98:job-1246) Seq 5-258539658: Rec
> eived: { Ans: , MgmtId: 29066118877352, via: 5, Ver: v1, Flags: 10, {
> AttachAnswer } }
> 2013-05-28 13:45:39,106 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-98:job-1246) Unexpected e
> xception while executing
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
> com.cloud.utils.exception.CloudRuntimeException: Failed to attach volume:
> TestDiskServ to VM: ce79edb6-
> a306-4ac4-95e4-6202800f691e; org.libvirt.LibvirtException: internal error
> unable to execute QEMU comman
> d '__com.redhat_drive_add': Duplicate ID 'drive-virtio-disk1' for drive
> at
> com.cloud.storage.VolumeManagerImpl.sendAttachVolumeCommand(VolumeManagerImpl.java:1583)
> at
> com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1788)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercep
> t(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:1
> 22)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-05-28 13:45:39,107 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-98:job-1246) Complete asy
> nc job-1246, jobStatus: 2, resultCode: 530, result: Error Code: 530 Error
> text: Failed to attach volume
> : TestDiskServ to VM: ce79edb6-a306-4ac4-95e4-6202800f691e;
> org.libvirt.LibvirtException: internal erro
>
--
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-2725) [Automation] Re-attaching volume on VM failing in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13717769#comment-13717769
]
Fang Wang edited comment on CLOUDSTACK-2725 at 7/24/13 1:29 AM:
I was about to add the chek of the vm state in the code,. And found we already
have the check before we attach the volume to the VM:
We did check if the VM is in running or stopped state, otherwise, the command
execution exited.
So for Edison's test case, after we detach a data disk, and then attach the
same data disk, out of the many data disks,
it is due to the hotplug is not supported on the VM.
was (Author: fangw):
I was about to add the chek of the vm state in the code,. And found we
already ahev the check before we attach the volume to the VM:
We did check if the VM is in running or stopped state, otherwise, the command
execution exited.
So for Edison's test case, after we detach a data disk, and then attach the
same disk disk, out of the many data disks,
it is due to the hutplug is not supported on the VM.
> [Automation] Re-attaching volume on VM failing in KVM
> -
>
> Key: CLOUDSTACK-2725
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2725
> 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: Automation environment KVM
> Found in master also (8d1189c2ae87216bc1c4a1443f75e9a8629abdc2)
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
> Fix For: 4.2.0
>
> Attachments: CLOUDSTACK-2725.rar
>
>
> Below two test case failing from BVT
> integration.smoke.test_volumes.TestVolumes.test_08_resize_volume
> integration.smoke.test_volumes.TestVolumes.test_09_delete_detached_volume
> Steps to reproduce
> Step 1 : Create an account, service offering, create volume, create VM
> Step 2 : Attach volume to VM ,
> Step 3 : Detach volume
> Step 4 : Attach volume to VM again
> Actual result
> Attachment failed with below error
> 2013-05-28 13:45:39,101 DEBUG [agent.transport.Request]
> (Job-Executor-98:job-1246) Seq 5-258539658: Rec
> eived: { Ans: , MgmtId: 29066118877352, via: 5, Ver: v1, Flags: 10, {
> AttachAnswer } }
> 2013-05-28 13:45:39,106 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-98:job-1246) Unexpected e
> xception while executing
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
> com.cloud.utils.exception.CloudRuntimeException: Failed to attach volume:
> TestDiskServ to VM: ce79edb6-
> a306-4ac4-95e4-6202800f691e; org.libvirt.LibvirtException: internal error
> unable to execute QEMU comman
> d '__com.redhat_drive_add': Duplicate ID 'drive-virtio-disk1' for drive
> at
> com.cloud.storage.VolumeManagerImpl.sendAttachVolumeCommand(VolumeManagerImpl.java:1583)
> at
> com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1788)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercep
> t(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:1
> 22)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-05-28 13:45:39,107 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-98:job-1246) Complete asy
> nc job-1246, jobStatus: 2, resultCode: 530, result: Error Code: 530 Error
> text: Failed to attach volume
> : TestDiskServ to VM: ce79edb6-a306-4ac4-95e4-6202800f691e;
> org.libvirt.LibvirtException: internal erro
>
--
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-2725) [Automation] Re-attaching volume on VM failing in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13717769#comment-13717769
]
Fang Wang commented on CLOUDSTACK-2725:
---
I was about to add the chek of the vm state in the code,. And found we already
ahev the check before we attach the volume to the VM:
We did check if the VM is in running or stopped state, otherwise, the command
execution exited.
So for Edison's test case, after we detach a data disk, and then attach the
same disk disk, out of the many data disks,
it is due to the hutplug is not supported on the VM.
> [Automation] Re-attaching volume on VM failing in KVM
> -
>
> Key: CLOUDSTACK-2725
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2725
> 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: Automation environment KVM
> Found in master also (8d1189c2ae87216bc1c4a1443f75e9a8629abdc2)
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
> Fix For: 4.2.0
>
> Attachments: CLOUDSTACK-2725.rar
>
>
> Below two test case failing from BVT
> integration.smoke.test_volumes.TestVolumes.test_08_resize_volume
> integration.smoke.test_volumes.TestVolumes.test_09_delete_detached_volume
> Steps to reproduce
> Step 1 : Create an account, service offering, create volume, create VM
> Step 2 : Attach volume to VM ,
> Step 3 : Detach volume
> Step 4 : Attach volume to VM again
> Actual result
> Attachment failed with below error
> 2013-05-28 13:45:39,101 DEBUG [agent.transport.Request]
> (Job-Executor-98:job-1246) Seq 5-258539658: Rec
> eived: { Ans: , MgmtId: 29066118877352, via: 5, Ver: v1, Flags: 10, {
> AttachAnswer } }
> 2013-05-28 13:45:39,106 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-98:job-1246) Unexpected e
> xception while executing
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
> com.cloud.utils.exception.CloudRuntimeException: Failed to attach volume:
> TestDiskServ to VM: ce79edb6-
> a306-4ac4-95e4-6202800f691e; org.libvirt.LibvirtException: internal error
> unable to execute QEMU comman
> d '__com.redhat_drive_add': Duplicate ID 'drive-virtio-disk1' for drive
> at
> com.cloud.storage.VolumeManagerImpl.sendAttachVolumeCommand(VolumeManagerImpl.java:1583)
> at
> com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1788)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercep
> t(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:1
> 22)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-05-28 13:45:39,107 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-98:job-1246) Complete asy
> nc job-1246, jobStatus: 2, resultCode: 530, result: Error Code: 530 Error
> text: Failed to attach volume
> : TestDiskServ to VM: ce79edb6-a306-4ac4-95e4-6202800f691e;
> org.libvirt.LibvirtException: internal erro
>
--
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-636) API refactoring -- Annotate api cmd classes with @ACL appropriately
[ https://issues.apache.org/jira/browse/CLOUDSTACK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fang Wang updated CLOUDSTACK-636: - Fix Version/s: (was: 4.2.0) Future > API refactoring -- Annotate api cmd classes with @ACL appropriately > --- > > Key: CLOUDSTACK-636 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-636 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.1.0 >Reporter: Fang Wang >Assignee: Fang Wang > Fix For: Future > > > The aim is to refactor and clean up the spaghetti acl and (db) validation > code from api layer using the @ACL. > Release Planning: > Dev list discussion: http://markmail.org/message/gqm677dazg443wio > Functional Spec: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+API+refactoring > Feature Branch: api_refactoring > Documentation changes: N/A > QA: part of testing CLOUDSTACK-638 -- 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-636) API refactoring -- Annotate api cmd classes with @ACL appropriately
[ https://issues.apache.org/jira/browse/CLOUDSTACK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13715795#comment-13715795 ] Fang Wang commented on CLOUDSTACK-636: -- We made the @ACL annotation changes for api commands mostly in 4.1.0. Will move it out to future release if we need to do more work in this area. > API refactoring -- Annotate api cmd classes with @ACL appropriately > --- > > Key: CLOUDSTACK-636 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-636 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.1.0 >Reporter: Fang Wang >Assignee: Fang Wang > Fix For: 4.2.0 > > > The aim is to refactor and clean up the spaghetti acl and (db) validation > code from api layer using the @ACL. > Release Planning: > Dev list discussion: http://markmail.org/message/gqm677dazg443wio > Functional Spec: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+API+refactoring > Feature Branch: api_refactoring > Documentation changes: N/A > QA: part of testing CLOUDSTACK-638 -- 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-3604) [Automation][BVT] Failed to create template from root volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fang Wang resolved CLOUDSTACK-3604. --- Resolution: Fixed Change the umask on your MS node, or run it under "root". > [Automation][BVT] Failed to create template from root volume > > > Key: CLOUDSTACK-3604 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3604 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.2.0 > Environment: VMware > branch 4.2 >Reporter: Rayees Namathponnan >Assignee: Fang Wang >Priority: Blocker > Fix For: 4.2.0 > > Attachments: CLOUDSTACK-3604.rar > > > BVT test case cloudstack/test/integration/smoke/test_templates.py failed > To reproduce this manually, create a template from vm's root volume. it > failed with below error > ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-22:job-1610 = [ > 07ba278a-ccc2-4481-ab3a-562fe58df847 ]) Unexpected exception while executing > org.apache.cloudstack.api.command.user.template.CreateTemplateCmd > com.cloud.utils.exception.CloudRuntimeException: Failed to create > templateCreatePrivateTemplateFromVolumeCommand exception: > java.lang.Exception: unable to prepare template directory: > template/tmpl/417/228, storage: > nfs://10.223.110.232:/export/home/automation/SC-CLOUD-QA03/secondary1, error > msg: mkdir: cannot create directory > `/var/cloudstack/mnt/VM/90928106758026.1ecaaabf/template/tmpl/417': > Permission denied > com.cloud.storage.resource.VmwareStorageProcessor.createTemplateFromVolume(VmwareStorageProcessor.java:492) > com.cloud.storage.resource.VmwareStorageProcessor.createTemplateFromVolume(VmwareStorageProcessor.java:576) > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:81) > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:49) > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:565) > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > java.util.concurrent.FutureTask.run(FutureTask.java:166) > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > java.lang.Thread.run(Thread.java:722) > at > com.cloud.template.TemplateManagerImpl.createPrivateTemplate(TemplateManagerImpl.java:1372) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) > at > org.apache.cloudstack.api.command.user.template.CreateTemplateCmd.execute(CreateTemplateCmd.java:256) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) > at > com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) -- 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-3604) [Automation][BVT] Failed to create template from root volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13711895#comment-13711895 ] Fang Wang commented on CLOUDSTACK-3604: --- it is a set up issue. With another developer's set up, I can't reproduce the problem and it works fine. We found the root cause of this problem: the template directory requires "root" privilage to do write. drwxr-xr-x. 9 root root 4096 Jul 17 16:14 tmpl In your set up, you are running as user "cloud" which does not have permission to write in that dir. and create a directory and write to it caused the permission denied error. I verified it manually, loging as "cloud", I can't do a mkdir : -sh-4.1$ pwd /var/cloudstack/mnt/VM/90928106758026.1ecaaabf/template/tmpl -sh-4.1$ ls 1 101 14 17 406 411 81 -sh-4.1$ mkdir 2 mkdir: cannot create directory `2': Permission denied > [Automation][BVT] Failed to create template from root volume > > > Key: CLOUDSTACK-3604 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3604 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.2.0 > Environment: VMware > branch 4.2 >Reporter: Rayees Namathponnan >Assignee: Fang Wang >Priority: Blocker > Fix For: 4.2.0 > > Attachments: CLOUDSTACK-3604.rar > > > BVT test case cloudstack/test/integration/smoke/test_templates.py failed > To reproduce this manually, create a template from vm's root volume. it > failed with below error > ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-22:job-1610 = [ > 07ba278a-ccc2-4481-ab3a-562fe58df847 ]) Unexpected exception while executing > org.apache.cloudstack.api.command.user.template.CreateTemplateCmd > com.cloud.utils.exception.CloudRuntimeException: Failed to create > templateCreatePrivateTemplateFromVolumeCommand exception: > java.lang.Exception: unable to prepare template directory: > template/tmpl/417/228, storage: > nfs://10.223.110.232:/export/home/automation/SC-CLOUD-QA03/secondary1, error > msg: mkdir: cannot create directory > `/var/cloudstack/mnt/VM/90928106758026.1ecaaabf/template/tmpl/417': > Permission denied > com.cloud.storage.resource.VmwareStorageProcessor.createTemplateFromVolume(VmwareStorageProcessor.java:492) > com.cloud.storage.resource.VmwareStorageProcessor.createTemplateFromVolume(VmwareStorageProcessor.java:576) > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:81) > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:49) > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:565) > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > java.util.concurrent.FutureTask.run(FutureTask.java:166) > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > java.lang.Thread.run(Thread.java:722) > at > com.cloud.template.TemplateManagerImpl.createPrivateTemplate(TemplateManagerImpl.java:1372) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) > at > org.apache.cloudstack.api.command.user.template.CreateTemplateCmd.execute(CreateTemplateCmd.java:256) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) > at > com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) -- 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-3599) [Automation] [BVT] Unable to attach volume to VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13711845#comment-13711845
]
Fang Wang commented on CLOUDSTACK-3599:
---
Rayees, what does this test do?
I manually test it on your MS, and I created a new volume, 5GB, and then attach
it to a VM, testVM, it succeeds.
I did not encounter any error.
Vijay tried it on his MS with 4.2 and master, also just created a new volume,
then attach it to a VM. it succeeds without a problem.
These are all done manually.
> [Automation] [BVT] Unable to attach volume to VM
>
>
> Key: CLOUDSTACK-3599
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3599
> 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
> 4.2 branch
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
>
> Volume test cases from BVT suite failed in VMware
> integration.smoke.test_volumes.TestCreateVolume.test_01_create_volume
> Observer below NPE while calling API createVolumeCallback
> ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-70:job-62 = [
> 28d50ad1-0d29-4679-9095-a3e0ac997e9a ]) Unexpected exception while executing
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
> java.lang.RuntimeException: InvocationTargetException when invoking RPC
> callback for command: createVolumeCallback
> at
> org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.dispatch(AsyncCallbackDispatcher.java:148)
> 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.datastore.driver.CloudStackPrimaryDataStoreDriverImpl.createAsync(CloudStackPrimaryDataStoreDriverImpl.java:122)
> at
> org.apache.cloudstack.storage.volume.VolumeServiceImpl.createVolumeAsync(VolumeServiceImpl.java:170)
> at
> com.cloud.storage.VolumeManagerImpl.createVolume(VolumeManagerImpl.java:703)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> com.cloud.storage.VolumeManagerImpl.createVolumeOnPrimaryStorage(VolumeManagerImpl.java:1542)
> at
> com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1828)
> 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.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.reflect.InvocationTargetException
> 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:601)
> at
> org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.dispatch(AsyncCallbackDispatcher.java:142)
> ... 26 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.cloudstack.storage.volume.VolumeObject.processEvent(VolumeObject.java:482)
> at
> org.apache.cloudstack.storage.volume.VolumeServiceImpl.createVolumeCallback(VolumeServiceImpl.java:180)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ... 30 more
> INFO [vmware.mo.HypervisorHostHelper] (DirectAgent-289:10.223.250.131) Blank
> VM: i-11-14-VM is ready for use
> INFO [vmware.resource.VmwareResource] (DirectAgent-289:10.223.250.131)
> Prepare NIC device based on NicTO:
> {"deviceId":0,"networkRateMbps":200,"defaultNic":true,"uuid":"b7f53ef0-196b-4647-8327-4bc53c46b
[jira] [Commented] (CLOUDSTACK-3599) [Automation] [BVT] Unable to attach volume to VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13711848#comment-13711848
]
Fang Wang commented on CLOUDSTACK-3599:
---
I can't manually reproduce the problem, when I do:
1. create a new volume;
2. attach the vol to a VM
> [Automation] [BVT] Unable to attach volume to VM
>
>
> Key: CLOUDSTACK-3599
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3599
> 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
> 4.2 branch
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
>
> Volume test cases from BVT suite failed in VMware
> integration.smoke.test_volumes.TestCreateVolume.test_01_create_volume
> Observer below NPE while calling API createVolumeCallback
> ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-70:job-62 = [
> 28d50ad1-0d29-4679-9095-a3e0ac997e9a ]) Unexpected exception while executing
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
> java.lang.RuntimeException: InvocationTargetException when invoking RPC
> callback for command: createVolumeCallback
> at
> org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.dispatch(AsyncCallbackDispatcher.java:148)
> 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.datastore.driver.CloudStackPrimaryDataStoreDriverImpl.createAsync(CloudStackPrimaryDataStoreDriverImpl.java:122)
> at
> org.apache.cloudstack.storage.volume.VolumeServiceImpl.createVolumeAsync(VolumeServiceImpl.java:170)
> at
> com.cloud.storage.VolumeManagerImpl.createVolume(VolumeManagerImpl.java:703)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> com.cloud.storage.VolumeManagerImpl.createVolumeOnPrimaryStorage(VolumeManagerImpl.java:1542)
> at
> com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1828)
> 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.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.reflect.InvocationTargetException
> 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:601)
> at
> org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.dispatch(AsyncCallbackDispatcher.java:142)
> ... 26 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.cloudstack.storage.volume.VolumeObject.processEvent(VolumeObject.java:482)
> at
> org.apache.cloudstack.storage.volume.VolumeServiceImpl.createVolumeCallback(VolumeServiceImpl.java:180)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ... 30 more
> INFO [vmware.mo.HypervisorHostHelper] (DirectAgent-289:10.223.250.131) Blank
> VM: i-11-14-VM is ready for use
> INFO [vmware.resource.VmwareResource] (DirectAgent-289:10.223.250.131)
> Prepare NIC device based on NicTO:
> {"deviceId":0,"networkRateMbps":200,"defaultNic":true,"uuid":"b7f53ef0-196b-4647-8327-4bc53c46b18a","ip":"10.1.1.50","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:36:ef:00:01","dns1":"8.8.8.8","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://3196","isolationUri":"vlan://3196","isSecurityGroupEnabled":false}
-
[jira] [Commented] (CLOUDSTACK-3470) [KVM] CopyCommand is not implemented in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13711819#comment-13711819
]
Fang Wang commented on CLOUDSTACK-3470:
---
The support volume migration for KVM, this is a new feature. I do not think we
will do
it for this release.
> [KVM] CopyCommand is not implemented in KVM
> ---
>
> Key: CLOUDSTACK-3470
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3470
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API, KVM
>Affects Versions: 4.2.0
>Reporter: Rajesh Battala
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
>
> while performing Volume Migrate from one ZWPS, to another ZWPS using KVM.
> copyVolumeBetweenPools method is triggering the CopyCommand to copy the
> volume from store to another.
> This CopyCommand is sent to KVM Agent to execute the operation of copying
> volume from Src Store to Dest Store.
> Issue is: CopyCommand is not implemented in KVM Resouce, hence failing the
> migration of Volumes
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Request:Seq 4-2091581770: { Cmd , MgmtId:
> 235715300172635, via: 4, Ver: v1, Flags: 100111,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"63d241ad-d372-40fc-b770-7661902ff52d","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"f0802731-62fe-3a85-b81a-98ae47e845cf","id":2,"poolType":"NetworkFilesystem","host":"10.102.192.100","path":"/cpg_vol/rajesh/zwps1","port":2049}},"name":"vol3","size":0,"path":"00ff0a7a-95a8-4809-a334-f8a0d9aa3db2","volumeId":13,"accountId":2,"format":"QCOW2","id":13}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"63d241ad-d372-40fc-b770-7661902ff52d","volumeType":"DATADISK","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.102.192.100/cpg_vol/rajesh/secondary","_role":"Image"}},"name":"vol3","size":0,"path":"volumes/2/13","volumeId":13,"accountId":2,"format":"QCOW2","id":13}},"wait":10800}}]
> }
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Processing command:
> org.apache.cloudstack.storage.command.CopyCommand
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Response: unsupported
> commandorg.apache.cloudstack.storage.command.CopyCommand
> 2013-07-11 15:48:59,780 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Seq 4-2091581770: { Ans: , MgmtId:
> 235715300172635, via: 4, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.UnsupportedAnswer":{"result":false,"details":"Unsupported
> command issued:org.apache.cloudstack.storage.command.CopyCommand. Are you
> sure you got the right type of server?","wait":0}}] }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-3470) [KVM] CopyCommand is not implemented in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fang Wang resolved CLOUDSTACK-3470.
---
Resolution: Won't Fix
Fix Version/s: (was: 4.2.0)
Future
We will not implement this new feature for this release.
I change it to future release. We need marketing requirement.
> [KVM] CopyCommand is not implemented in KVM
> ---
>
> Key: CLOUDSTACK-3470
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3470
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API, KVM
>Affects Versions: 4.2.0
>Reporter: Rajesh Battala
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: Future
>
>
> while performing Volume Migrate from one ZWPS, to another ZWPS using KVM.
> copyVolumeBetweenPools method is triggering the CopyCommand to copy the
> volume from store to another.
> This CopyCommand is sent to KVM Agent to execute the operation of copying
> volume from Src Store to Dest Store.
> Issue is: CopyCommand is not implemented in KVM Resouce, hence failing the
> migration of Volumes
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Request:Seq 4-2091581770: { Cmd , MgmtId:
> 235715300172635, via: 4, Ver: v1, Flags: 100111,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"63d241ad-d372-40fc-b770-7661902ff52d","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"f0802731-62fe-3a85-b81a-98ae47e845cf","id":2,"poolType":"NetworkFilesystem","host":"10.102.192.100","path":"/cpg_vol/rajesh/zwps1","port":2049}},"name":"vol3","size":0,"path":"00ff0a7a-95a8-4809-a334-f8a0d9aa3db2","volumeId":13,"accountId":2,"format":"QCOW2","id":13}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"63d241ad-d372-40fc-b770-7661902ff52d","volumeType":"DATADISK","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.102.192.100/cpg_vol/rajesh/secondary","_role":"Image"}},"name":"vol3","size":0,"path":"volumes/2/13","volumeId":13,"accountId":2,"format":"QCOW2","id":13}},"wait":10800}}]
> }
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Processing command:
> org.apache.cloudstack.storage.command.CopyCommand
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Response: unsupported
> commandorg.apache.cloudstack.storage.command.CopyCommand
> 2013-07-11 15:48:59,780 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Seq 4-2091581770: { Ans: , MgmtId:
> 235715300172635, via: 4, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.UnsupportedAnswer":{"result":false,"details":"Unsupported
> command issued:org.apache.cloudstack.storage.command.CopyCommand. Are you
> sure you got the right type of server?","wait":0}}] }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-732) Add back KVM snapshot support
[ https://issues.apache.org/jira/browse/CLOUDSTACK-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13711806#comment-13711806 ] Fang Wang commented on CLOUDSTACK-732: -- commit eb3e8861b56a9699a7b5dccc45db067061d6e384 Author: Fang Wang Date: Wed Jul 17 15:25:23 2013 -0700 CLOUDSTACK-732 Add disk snapshot for KVM 6.3, add the flag in CS. check in to release 4.2. review board: https://reviews.apache.org/r/12712/ > Add back KVM snapshot support > - > > Key: CLOUDSTACK-732 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-732 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.0.0 > Environment: RHEL 6.3 >Reporter: edison su >Assignee: Fang Wang >Priority: Critical > Fix For: 4.2.0 > > > In the latest KVM(on both RHEL 6.3 and Ubuntu 12.04), it supports external > snapshot. We need to investigate the status of external snapshot, as far as I > know, it still doesn't support disk-only snapshot(taking snapshot will pause > VM for a long time, e.g. few minutes). > 1. testing external snapshot: take an external snapshot instead of default > qcow2 internal snapshot, then back it up into backup storage. Only need to > test with libvirt snapshot API, if it works, then works, no need to hack on > the qemu-kvm. > 2. test how long it will pause a VM during taking snapshot. from link [2] and > [3], only qemu-kvm-rhev supports disk-only snapshot, not sure ubuntu 12.04 > supports it or not. We need to investigate on the issue. > If item 1 and item 2(disk-only snapshot) works, then we can support default > kvm qcow2 snapshot again. > The link: > [1] > http://kashyapc.wordpress.com/2011/10/04/snapshotting-with-libvirt-for-qcow2-images/ > [2] > http://www.linux-kvm.com/content/first-look-virtual-machine-online-disk-snapshots-coming-fedora-18 > [3] http://www.redhat.com/archives/libvir-list/2012-July/msg00782.html -- 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-3604) [Automation][BVT] Failed to create template from root volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13711768#comment-13711768 ] Fang Wang commented on CLOUDSTACK-3604: --- This is a DUP of 3413. > [Automation][BVT] Failed to create template from root volume > > > Key: CLOUDSTACK-3604 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3604 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.2.0 > Environment: VMware > branch 4.2 >Reporter: Rayees Namathponnan >Assignee: Fang Wang >Priority: Blocker > Fix For: 4.2.0 > > Attachments: CLOUDSTACK-3604.rar > > > BVT test case cloudstack/test/integration/smoke/test_templates.py failed > To reproduce this manually, create a template from vm's root volume. it > failed with below error > ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-22:job-1610 = [ > 07ba278a-ccc2-4481-ab3a-562fe58df847 ]) Unexpected exception while executing > org.apache.cloudstack.api.command.user.template.CreateTemplateCmd > com.cloud.utils.exception.CloudRuntimeException: Failed to create > templateCreatePrivateTemplateFromVolumeCommand exception: > java.lang.Exception: unable to prepare template directory: > template/tmpl/417/228, storage: > nfs://10.223.110.232:/export/home/automation/SC-CLOUD-QA03/secondary1, error > msg: mkdir: cannot create directory > `/var/cloudstack/mnt/VM/90928106758026.1ecaaabf/template/tmpl/417': > Permission denied > com.cloud.storage.resource.VmwareStorageProcessor.createTemplateFromVolume(VmwareStorageProcessor.java:492) > com.cloud.storage.resource.VmwareStorageProcessor.createTemplateFromVolume(VmwareStorageProcessor.java:576) > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:81) > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:49) > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:565) > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > java.util.concurrent.FutureTask.run(FutureTask.java:166) > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > java.lang.Thread.run(Thread.java:722) > at > com.cloud.template.TemplateManagerImpl.createPrivateTemplate(TemplateManagerImpl.java:1372) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) > at > org.apache.cloudstack.api.command.user.template.CreateTemplateCmd.execute(CreateTemplateCmd.java:256) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) > at > com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) -- 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-3604) [Automation][BVT] Failed to create template from root volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13711765#comment-13711765 ] Fang Wang commented on CLOUDSTACK-3604: --- This is the same bug as cloudstack-3413. > [Automation][BVT] Failed to create template from root volume > > > Key: CLOUDSTACK-3604 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3604 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.2.0 > Environment: VMware > branch 4.2 >Reporter: Rayees Namathponnan >Priority: Blocker > Fix For: 4.2.0 > > Attachments: CLOUDSTACK-3604.rar > > > BVT test case cloudstack/test/integration/smoke/test_templates.py failed > To reproduce this manually, create a template from vm's root volume. it > failed with below error > ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-22:job-1610 = [ > 07ba278a-ccc2-4481-ab3a-562fe58df847 ]) Unexpected exception while executing > org.apache.cloudstack.api.command.user.template.CreateTemplateCmd > com.cloud.utils.exception.CloudRuntimeException: Failed to create > templateCreatePrivateTemplateFromVolumeCommand exception: > java.lang.Exception: unable to prepare template directory: > template/tmpl/417/228, storage: > nfs://10.223.110.232:/export/home/automation/SC-CLOUD-QA03/secondary1, error > msg: mkdir: cannot create directory > `/var/cloudstack/mnt/VM/90928106758026.1ecaaabf/template/tmpl/417': > Permission denied > com.cloud.storage.resource.VmwareStorageProcessor.createTemplateFromVolume(VmwareStorageProcessor.java:492) > com.cloud.storage.resource.VmwareStorageProcessor.createTemplateFromVolume(VmwareStorageProcessor.java:576) > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:81) > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:49) > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:565) > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > java.util.concurrent.FutureTask.run(FutureTask.java:166) > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > java.lang.Thread.run(Thread.java:722) > at > com.cloud.template.TemplateManagerImpl.createPrivateTemplate(TemplateManagerImpl.java:1372) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) > at > org.apache.cloudstack.api.command.user.template.CreateTemplateCmd.execute(CreateTemplateCmd.java:256) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) > at > com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) -- 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-3604) [Automation][BVT] Failed to create template from root volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fang Wang updated CLOUDSTACK-3604: -- Assignee: Fang Wang > [Automation][BVT] Failed to create template from root volume > > > Key: CLOUDSTACK-3604 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3604 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.2.0 > Environment: VMware > branch 4.2 >Reporter: Rayees Namathponnan >Assignee: Fang Wang >Priority: Blocker > Fix For: 4.2.0 > > Attachments: CLOUDSTACK-3604.rar > > > BVT test case cloudstack/test/integration/smoke/test_templates.py failed > To reproduce this manually, create a template from vm's root volume. it > failed with below error > ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-22:job-1610 = [ > 07ba278a-ccc2-4481-ab3a-562fe58df847 ]) Unexpected exception while executing > org.apache.cloudstack.api.command.user.template.CreateTemplateCmd > com.cloud.utils.exception.CloudRuntimeException: Failed to create > templateCreatePrivateTemplateFromVolumeCommand exception: > java.lang.Exception: unable to prepare template directory: > template/tmpl/417/228, storage: > nfs://10.223.110.232:/export/home/automation/SC-CLOUD-QA03/secondary1, error > msg: mkdir: cannot create directory > `/var/cloudstack/mnt/VM/90928106758026.1ecaaabf/template/tmpl/417': > Permission denied > com.cloud.storage.resource.VmwareStorageProcessor.createTemplateFromVolume(VmwareStorageProcessor.java:492) > com.cloud.storage.resource.VmwareStorageProcessor.createTemplateFromVolume(VmwareStorageProcessor.java:576) > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:81) > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:49) > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:565) > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > java.util.concurrent.FutureTask.run(FutureTask.java:166) > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > java.lang.Thread.run(Thread.java:722) > at > com.cloud.template.TemplateManagerImpl.createPrivateTemplate(TemplateManagerImpl.java:1372) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) > at > org.apache.cloudstack.api.command.user.template.CreateTemplateCmd.execute(CreateTemplateCmd.java:256) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) > at > com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) -- 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-3604) [Automation][BVT] Failed to create template from root volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13711750#comment-13711750 ] Fang Wang commented on CLOUDSTACK-3604: --- This is a set up problem, the permission gets denied to create the directory for the template: nfs://10.223.110.232:/export/home/automation/SC-CLOUD-QA03/secondary1, error msg: mkdir: cannot create directory `/var/cloudstack/mnt/VM/90928106758026.1ecaaabf/template/tmpl/417': Permission denied on the host, do we have the correct permission? > [Automation][BVT] Failed to create template from root volume > > > Key: CLOUDSTACK-3604 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3604 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.2.0 > Environment: VMware > branch 4.2 >Reporter: Rayees Namathponnan >Priority: Blocker > Fix For: 4.2.0 > > Attachments: CLOUDSTACK-3604.rar > > > BVT test case cloudstack/test/integration/smoke/test_templates.py failed > To reproduce this manually, create a template from vm's root volume. it > failed with below error > ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-22:job-1610 = [ > 07ba278a-ccc2-4481-ab3a-562fe58df847 ]) Unexpected exception while executing > org.apache.cloudstack.api.command.user.template.CreateTemplateCmd > com.cloud.utils.exception.CloudRuntimeException: Failed to create > templateCreatePrivateTemplateFromVolumeCommand exception: > java.lang.Exception: unable to prepare template directory: > template/tmpl/417/228, storage: > nfs://10.223.110.232:/export/home/automation/SC-CLOUD-QA03/secondary1, error > msg: mkdir: cannot create directory > `/var/cloudstack/mnt/VM/90928106758026.1ecaaabf/template/tmpl/417': > Permission denied > com.cloud.storage.resource.VmwareStorageProcessor.createTemplateFromVolume(VmwareStorageProcessor.java:492) > com.cloud.storage.resource.VmwareStorageProcessor.createTemplateFromVolume(VmwareStorageProcessor.java:576) > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:81) > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:49) > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:565) > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186) > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > java.util.concurrent.FutureTask.run(FutureTask.java:166) > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > java.lang.Thread.run(Thread.java:722) > at > com.cloud.template.TemplateManagerImpl.createPrivateTemplate(TemplateManagerImpl.java:1372) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) > at > org.apache.cloudstack.api.command.user.template.CreateTemplateCmd.execute(CreateTemplateCmd.java:256) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) > at > com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) -- 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-732) Add back KVM snapshot support
[ https://issues.apache.org/jira/browse/CLOUDSTACK-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13711625#comment-13711625 ] Fang Wang commented on CLOUDSTACK-732: -- This is for RHEL 6.3. > Add back KVM snapshot support > - > > Key: CLOUDSTACK-732 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-732 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.0.0 > Environment: RHEL 6.3 >Reporter: edison su >Assignee: Fang Wang >Priority: Critical > Fix For: 4.2.0 > > > In the latest KVM(on both RHEL 6.3 and Ubuntu 12.04), it supports external > snapshot. We need to investigate the status of external snapshot, as far as I > know, it still doesn't support disk-only snapshot(taking snapshot will pause > VM for a long time, e.g. few minutes). > 1. testing external snapshot: take an external snapshot instead of default > qcow2 internal snapshot, then back it up into backup storage. Only need to > test with libvirt snapshot API, if it works, then works, no need to hack on > the qemu-kvm. > 2. test how long it will pause a VM during taking snapshot. from link [2] and > [3], only qemu-kvm-rhev supports disk-only snapshot, not sure ubuntu 12.04 > supports it or not. We need to investigate on the issue. > If item 1 and item 2(disk-only snapshot) works, then we can support default > kvm qcow2 snapshot again. > The link: > [1] > http://kashyapc.wordpress.com/2011/10/04/snapshotting-with-libvirt-for-qcow2-images/ > [2] > http://www.linux-kvm.com/content/first-look-virtual-machine-online-disk-snapshots-coming-fedora-18 > [3] http://www.redhat.com/archives/libvir-list/2012-July/msg00782.html -- 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-732) Add back KVM snapshot support
[ https://issues.apache.org/jira/browse/CLOUDSTACK-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13711623#comment-13711623 ] Fang Wang commented on CLOUDSTACK-732: -- For Cloudstack, vm snapshot and volume snapshot are two different mechanism. This feature is tracking the volume snapshot, or we could call it disk backup for cloudstack, since it does disk backup. Currently disk snapshot is not supported by cloudstack for KVM. 1. for 4.2, we will add a "KVM.snapshot.enabled" global flag under the "Global Settings" in cloudstack UI; the default value is "false" to turn off the snapshot, which is the current default behavior without this flag; 2. If users want to turn on this flag, they need to install the new qemu rpm patch, and turn on this flag; 3. for upgrade, if users did use this disk snapshot feature before upgrade, after the upgrade to 4.2, the flag will be set to TRUE; they then need to install the qemu patch; 4.. The qemu rpm patches will be submitted in a separate packaging patch. Any suggestion where we should put it? I am thinking of the "packaging" directory. thanks. > Add back KVM snapshot support > - > > Key: CLOUDSTACK-732 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-732 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.0.0 > Environment: RHEL 6.3 >Reporter: edison su >Assignee: Fang Wang >Priority: Critical > Fix For: 4.2.0 > > > In the latest KVM(on both RHEL 6.3 and Ubuntu 12.04), it supports external > snapshot. We need to investigate the status of external snapshot, as far as I > know, it still doesn't support disk-only snapshot(taking snapshot will pause > VM for a long time, e.g. few minutes). > 1. testing external snapshot: take an external snapshot instead of default > qcow2 internal snapshot, then back it up into backup storage. Only need to > test with libvirt snapshot API, if it works, then works, no need to hack on > the qemu-kvm. > 2. test how long it will pause a VM during taking snapshot. from link [2] and > [3], only qemu-kvm-rhev supports disk-only snapshot, not sure ubuntu 12.04 > supports it or not. We need to investigate on the issue. > If item 1 and item 2(disk-only snapshot) works, then we can support default > kvm qcow2 snapshot again. > The link: > [1] > http://kashyapc.wordpress.com/2011/10/04/snapshotting-with-libvirt-for-qcow2-images/ > [2] > http://www.linux-kvm.com/content/first-look-virtual-machine-online-disk-snapshots-coming-fedora-18 > [3] http://www.redhat.com/archives/libvir-list/2012-July/msg00782.html -- 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-3566) Not able to create snapshot for KVM host -- backup snapshot fails
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fang Wang resolved CLOUDSTACK-3566. --- Resolution: Fixed > Not able to create snapshot for KVM host -- backup snapshot fails > - > > Key: CLOUDSTACK-3566 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3566 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Fang Wang >Assignee: Fang Wang >Priority: Critical > Fix For: 4.2.0 > > > create snapshot result in snapshot remaining on primary storage and not > backup to secondary storage for KVM. -- 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-3566) Not able to create snapshot for KVM host -- backup snapshot fails
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fang Wang reopened CLOUDSTACK-3566: --- Fix is in, QA will close it. > Not able to create snapshot for KVM host -- backup snapshot fails > - > > Key: CLOUDSTACK-3566 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3566 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Fang Wang >Assignee: Fang Wang >Priority: Critical > Fix For: 4.2.0 > > > create snapshot result in snapshot remaining on primary storage and not > backup to secondary storage for KVM. -- 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-3566) Not able to create snapshot for KVM host -- backup snapshot fails
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13710416#comment-13710416 ] Fang Wang commented on CLOUDSTACK-3566: --- https://reviews.apache.org/r/12591/ > Not able to create snapshot for KVM host -- backup snapshot fails > - > > Key: CLOUDSTACK-3566 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3566 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Fang Wang >Assignee: Fang Wang >Priority: Critical > Fix For: 4.2.0 > > > create snapshot result in snapshot remaining on primary storage and not > backup to secondary storage for KVM. -- 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-3566) Not able to create snapshot for KVM host -- backup snapshot fails
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fang Wang closed CLOUDSTACK-3566. - Resolution: Fixed check fix in 4.2.0: commit c45595f1ce3276ba7949f6b9dc01ae990dcd9766 Author: Fang Wang Date: Tue Jul 16 15:19:42 2013 -0700 CLOUDSTACK-3566: Not able to create snapshot for KVM host -- backup snapshot fails > Not able to create snapshot for KVM host -- backup snapshot fails > - > > Key: CLOUDSTACK-3566 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3566 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Fang Wang >Assignee: Fang Wang >Priority: Critical > Fix For: 4.2.0 > > > create snapshot result in snapshot remaining on primary storage and not > backup to secondary storage for KVM. -- 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-3566) Not able to create snapshot for KVM host -- backup snapshot fails
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fang Wang updated CLOUDSTACK-3566: -- Summary: Not able to create snapshot for KVM host -- backup snapshot fails (was: Not able to create snapshot for KVM host) > Not able to create snapshot for KVM host -- backup snapshot fails > - > > Key: CLOUDSTACK-3566 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3566 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Fang Wang >Assignee: Fang Wang >Priority: Critical > Fix For: 4.2.0 > > > create snapshot result in snapshot remaining on primary storage and not > backup to secondary storage for KVM. -- 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-3566) Not able to create snapshot for KVM host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fang Wang updated CLOUDSTACK-3566: -- Priority: Critical (was: Blocker) > Not able to create snapshot for KVM host > > > Key: CLOUDSTACK-3566 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3566 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Fang Wang >Assignee: Fang Wang >Priority: Critical > Fix For: 4.2.0 > > > create snapshot result in snapshot remaining on primary storage and not > backup to secondary storage for KVM. -- 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-3566) Not able to create snapshot for KVM host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fang Wang updated CLOUDSTACK-3566: -- Priority: Blocker (was: Critical) > Not able to create snapshot for KVM host > > > Key: CLOUDSTACK-3566 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3566 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Fang Wang >Assignee: Fang Wang >Priority: Blocker > Fix For: 4.2.0 > > > create snapshot result in snapshot remaining on primary storage and not > backup to secondary storage for KVM. -- 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-3566) Not able to create snapshot for KVM host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fang Wang updated CLOUDSTACK-3566: -- Description: create snapshot result in snapshot remaining on primary storage and not backup to secondary storage for KVM. was: hostcreate snapshot result in snapshot remaining on primary storage and not backup to secondary storage for KVMFor KVM, snapshot got created on primary but not backed up to secondary storage. > Not able to create snapshot for KVM host > > > Key: CLOUDSTACK-3566 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3566 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Fang Wang >Assignee: Fang Wang >Priority: Critical > Fix For: 4.2.0 > > > create snapshot result in snapshot remaining on primary storage and not > backup to secondary storage for KVM. -- 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-3566) Not able to create snapshot for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fang Wang updated CLOUDSTACK-3566: -- Summary: Not able to create snapshot for KVM (was: create snapshot result in snapshot remaining on primary storage and not backup to secondary storage for KVM) > Not able to create snapshot for KVM > > > Key: CLOUDSTACK-3566 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3566 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Fang Wang >Assignee: Fang Wang >Priority: Critical > Fix For: 4.2.0 > > > For KVM, snapshot got created on primary but not backed up to secondary > storage. -- 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-3566) Not able to create snapshot for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fang Wang updated CLOUDSTACK-3566: -- Description: hostcreate snapshot result in snapshot remaining on primary storage and not backup to secondary storage for KVMFor KVM, snapshot got created on primary but not backed up to secondary storage. was: For KVM, snapshot got created on primary but not backed up to secondary storage. > Not able to create snapshot for KVM > > > Key: CLOUDSTACK-3566 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3566 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Fang Wang >Assignee: Fang Wang >Priority: Critical > Fix For: 4.2.0 > > > hostcreate snapshot result in snapshot remaining on primary storage and not > backup to secondary storage for KVMFor KVM, snapshot got created on primary > but not backed up to secondary storage. -- 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-3566) Not able to create snapshot for KVM host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fang Wang updated CLOUDSTACK-3566: -- Summary: Not able to create snapshot for KVM host (was: Not able to create snapshot for KVM ) > Not able to create snapshot for KVM host > > > Key: CLOUDSTACK-3566 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3566 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Fang Wang >Assignee: Fang Wang >Priority: Critical > Fix For: 4.2.0 > > > hostcreate snapshot result in snapshot remaining on primary storage and not > backup to secondary storage for KVMFor KVM, snapshot got created on primary > but not backed up to secondary storage. -- 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-3566) create snapshot result in snapshot remaining on primary storage and not backup to secondary storage for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fang Wang updated CLOUDSTACK-3566: -- Description: For KVM, snapshot got created on primary but not backed up to secondary storage. > create snapshot result in snapshot remaining on primary storage and not > backup to secondary storage for KVM > > > Key: CLOUDSTACK-3566 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3566 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Fang Wang >Assignee: Fang Wang >Priority: Critical > Fix For: 4.2.0 > > > For KVM, snapshot got created on primary but not backed up to secondary > storage. -- 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-3566) create snapshot result in snapshot remaining on primary storage and not backup to secondary storage for KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13710341#comment-13710341
]
Fang Wang commented on CLOUDSTACK-3566:
---
Both Kishan and Angie encountered this problem for KVM host:
> 2013-07-16 20:24:01,895 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-
> 4:null) Request:Seq 3-1936982191: { Cmd , MgmtId: 101318455136477,
> via: 3,
> Ver: v1, Flags: 100011,
> [{"org.apache.cloudstack.storage.command.CreateObjectCommand":{"data"
> :{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"volume":{"uuid":"
> 6031b289-2ec2-4dd2-9280-
> 424d662e2c91","volumeType":"DATADISK","dataStore":{"org.apache.cloudst
> ack.storage.to.PrimaryDataStoreTO":{"uuid":"c81a7053-7722-3341-bdaf-
> 9bc53062b75d","id":3,"poolType":"NetworkFilesystem","host":"10.147.28.
> 7",
> "path":"/export/home/kishan/primary30","port":2049}},"name":"v1","size":
> 0,"path":"61f23cfc-7a31-48c9-bc75-
> 4f28e16fd74a","volumeId":36,"vmName":"i-2-31-
> VM","accountId":2,"format":"QCOW2","id":36},"dataStore":{"org.apache.c
> lo
> udstack.storage.to.PrimaryDataStoreTO":{"uuid":"c81a7053-7722-3341-bda
> f-
> 9bc53062b75d","id":3,"poolType":"NetworkFilesystem","host":"10.147.28.
> 7",
> "path":"/export/home/kishan/primary30","port":2049}},"vmName":"i-2-31-
> VM","name":"48dfd37f-f4fb-4f17-9a45-
> 1ffbb6b78adc_v1_20130716144512","hypervisorType":"KVM","id":6}},"wait":
> 0}}] }
> 2013-07-16 20:24:01,895 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-
> 4:null) Processing command:
> org.apache.cloudstack.storage.command.CreateObjectCommand
> 2013-07-16 20:24:02,123 DEBUG [kvm.storage.KVMStorageProcessor]
> (agentRequest-Handler-4:null) a00b-
> 4d35-444a-a7fc-cbafda28575d
> 48dfd37f-
> f4fb-4f17-9a45-1ffbb6b78adc
> 2013-07-16 20:24:02,514 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-
> 4:null) Seq 3-1936982191: { Ans: , MgmtId: 101318455136477, via: 3,
> Ver: v1,
> Flags: 10,
> [{"org.apache.cloudstack.storage.command.CreateObjectAnswer":{"data":{"
> org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"/mnt/c81a7
> 0
> 53-7722-3341-bdaf-9bc53062b75d/61f23cfc-7a31-48c9-bc75-
> 4f28e16fd74a/a00b-4d35-444a-a7fc-
> cbafda28575d","id":0}},"result":true,"wait":0}}] }
> 2013-07-16 20:24:02,883 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-
> 5:null) Request:Seq 3-1936982192: { Cmd , MgmtId: 101318455136477,
> via: 3,
> Ver: v1, Flags: 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.
> apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"/mnt/c81a7053-
> 7722-3341-bdaf-9bc53062b75d/61f23cfc-7a31-48c9-bc75-
> 4f28e16fd74a/a00b-4d35-444a-a7fc-
> cbafda28575d","volume":{"uuid":"6031b289-2ec2-4dd2-9280-
> 424d662e2c91","volumeType":"DATADISK","dataStore":{"org.apache.cloudst
> ack.storage.to.PrimaryDataStoreTO":{"uuid":"c81a7053-7722-3341-bdaf-
> 9bc53062b75d","id":3,"poolType":"NetworkFilesystem","host":"10.147.28.
> 7",
> "path":"/export/home/kishan/primary30","port":2049}},"name":"v1","size":
> 0,"path":"61f23cfc-7a31-48c9-bc75-
> 4f28e16fd74a","volumeId":36,"vmName":"i-2-31-
> VM","accountId":2,"format":"QCOW2","id":36},"dataStore":{"org.apache.c
> lo
> udstack.storage.to.PrimaryDataStoreTO":{"uuid":"c81a7053-7722-3341-bda
> f-
> 9bc53062b75d","id":3,"poolType":"NetworkFilesystem","host":"10.147.28.
> 7",
> "path":"/export/home/kishan/primary30","port":2049}},"vmName":"i-2-31-
> VM","name":"48dfd37f-f4fb-4f17-9a45-
> 1ffbb6b78adc_v1_20130716144512","hypervisorType":"KVM","id":6}},"destT
> O":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"path":"snaps
> ho
> ts/2/36","volume":{"uuid":"6031b289-2ec2-4dd2-9280-
> 424d662e2c91","volumeType":"DATADISK","dataStore":{"org.apache.cloudst
> ack.storage.to.PrimaryDataStoreTO":{"uuid":"c81a7053-7722-3341-bdaf-
> 9bc53062b75d","id":3,"poolType":"NetworkFilesystem","host":"10.147.28.
> 7",
> "path":"/export/home/kishan/primary30","port":2049}},"name":"v1","size":
> 0,"path":"61f23cfc-7a31-48c9-bc75-
> 4f28e16fd74a","volumeId":36,"vmName":"i-2-31-
> VM","accountId":2,"format":"QCOW2","id":36},"dataStore":{"com.cloud.ag
> e
> nt.api.to.NfsTO":{"_url":"nfs://10.147.28.7/export/home/kishan/secondary"
> ,"_role":"Image"}},"vmName":"i-2-31-VM","name":"48dfd37f-f4fb-4f17-
> 9a45-
> 1ffbb6b78adc_v1_20130716144512","hypervisorType":"KVM","id":6}},"execu
> teInSequence":false,"wait":21600}}] }
> 2013-07-16 20:24:02,883 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-
> 5:null) Processing command:
> org.apache.cloudstack.storage.command.CopyCommand
> 2013-07-16 20:24:02,887 DEBUG [kvm.storage.LibvirtStorageAdaptor]
> (agentRequest-Handler-5:null) createStoragePool didn't find existing
> running
> pool: org.libvirt.LibvirtException: Storage pool not found: no pool
> with matching uuid, need to create it
> 2013-07-16 20:24:02,887 DEBUG [kvm.storage.LibvirtStorageAdapto
[jira] [Created] (CLOUDSTACK-3566) create snapshot result in snapshot remaining on primary storage and not backup to secondary storage for KVM
Fang Wang created CLOUDSTACK-3566: - Summary: create snapshot result in snapshot remaining on primary storage and not backup to secondary storage for KVM Key: CLOUDSTACK-3566 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3566 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Fang Wang Assignee: Fang Wang Priority: Critical 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-2725) [Automation] Re-attaching volume on VM failing in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13707585#comment-13707585
]
Fang Wang commented on CLOUDSTACK-2725:
---
The bug was reproduced by the smoke test and I checked the libvirt log, libvirt
reported an error:
So
2013-07-12 05:53:10.458+: 5739: error : qemuMonitorJSONCheckError:355 :
internal error unable to execute QEMU command '__com.redhat_drive_add':
Duplicate ID 'drive-virtio-disk1' for drive
2013-07-12 05:53:16.001+: 5743: error : qemuMonitorJSONCheckError:355 :
internal error unable to execute QEMU command '__com.redhat_drive_add':
Duplicate ID 'drive-virtio-disk1' for drive
2013-07-12 05:53:16.862+: 5738: error :
qemuProcessFindDomainDiskByAlias:406 : internal error no disk found with alias
it seems after the detach, and then attach, the same device id is used, but the
driver did not think the original one is detached yet.
It is a libvirt issue.
> [Automation] Re-attaching volume on VM failing in KVM
> -
>
> Key: CLOUDSTACK-2725
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2725
> 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: Automation environment KVM
> Found in master also (8d1189c2ae87216bc1c4a1443f75e9a8629abdc2)
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: CLOUDSTACK-2725.rar
>
>
> Below two test case failing from BVT
> integration.smoke.test_volumes.TestVolumes.test_08_resize_volume
> integration.smoke.test_volumes.TestVolumes.test_09_delete_detached_volume
> Steps to reproduce
> Step 1 : Create an account, service offering, create volume, create VM
> Step 2 : Attach volume to VM ,
> Step 3 : Detach volume
> Step 4 : Attach volume to VM again
> Actual result
> Attachment failed with below error
> 2013-05-28 13:45:39,101 DEBUG [agent.transport.Request]
> (Job-Executor-98:job-1246) Seq 5-258539658: Rec
> eived: { Ans: , MgmtId: 29066118877352, via: 5, Ver: v1, Flags: 10, {
> AttachAnswer } }
> 2013-05-28 13:45:39,106 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-98:job-1246) Unexpected e
> xception while executing
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
> com.cloud.utils.exception.CloudRuntimeException: Failed to attach volume:
> TestDiskServ to VM: ce79edb6-
> a306-4ac4-95e4-6202800f691e; org.libvirt.LibvirtException: internal error
> unable to execute QEMU comman
> d '__com.redhat_drive_add': Duplicate ID 'drive-virtio-disk1' for drive
> at
> com.cloud.storage.VolumeManagerImpl.sendAttachVolumeCommand(VolumeManagerImpl.java:1583)
> at
> com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1788)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercep
> t(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:1
> 22)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-05-28 13:45:39,107 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-98:job-1246) Complete asy
> nc job-1246, jobStatus: 2, resultCode: 530, result: Error Code: 530 Error
> text: Failed to attach volume
> : TestDiskServ to VM: ce79edb6-a306-4ac4-95e4-6202800f691e;
> org.libvirt.LibvirtException: internal erro
--
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-3470) [KVM] CopyCommand is not implemented in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fang Wang updated CLOUDSTACK-3470:
--
Assignee: Fang Wang
> [KVM] CopyCommand is not implemented in KVM
> ---
>
> Key: CLOUDSTACK-3470
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3470
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API, KVM
>Affects Versions: 4.2.0
>Reporter: Rajesh Battala
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
>
> while performing Volume Migrate from one ZWPS, to another ZWPS using KVM.
> copyVolumeBetweenPools method is triggering the CopyCommand to copy the
> volume from store to another.
> This CopyCommand is sent to KVM Agent to execute the operation of copying
> volume from Src Store to Dest Store.
> Issue is: CopyCommand is not implemented in KVM Resouce, hence failing the
> migration of Volumes
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Request:Seq 4-2091581770: { Cmd , MgmtId:
> 235715300172635, via: 4, Ver: v1, Flags: 100111,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"63d241ad-d372-40fc-b770-7661902ff52d","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"f0802731-62fe-3a85-b81a-98ae47e845cf","id":2,"poolType":"NetworkFilesystem","host":"10.102.192.100","path":"/cpg_vol/rajesh/zwps1","port":2049}},"name":"vol3","size":0,"path":"00ff0a7a-95a8-4809-a334-f8a0d9aa3db2","volumeId":13,"accountId":2,"format":"QCOW2","id":13}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"63d241ad-d372-40fc-b770-7661902ff52d","volumeType":"DATADISK","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.102.192.100/cpg_vol/rajesh/secondary","_role":"Image"}},"name":"vol3","size":0,"path":"volumes/2/13","volumeId":13,"accountId":2,"format":"QCOW2","id":13}},"wait":10800}}]
> }
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Processing command:
> org.apache.cloudstack.storage.command.CopyCommand
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Response: unsupported
> commandorg.apache.cloudstack.storage.command.CopyCommand
> 2013-07-11 15:48:59,780 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Seq 4-2091581770: { Ans: , MgmtId:
> 235715300172635, via: 4, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.UnsupportedAnswer":{"result":false,"details":"Unsupported
> command issued:org.apache.cloudstack.storage.command.CopyCommand. Are you
> sure you got the right type of server?","wait":0}}] }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CLOUDSTACK-3470) [KVM] CopyCommand is not implemented in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fang Wang reopened CLOUDSTACK-3470:
---
This is to support the volume migration feature on KVM
> [KVM] CopyCommand is not implemented in KVM
> ---
>
> Key: CLOUDSTACK-3470
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3470
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API, KVM
>Affects Versions: 4.2.0
>Reporter: Rajesh Battala
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
>
> while performing Volume Migrate from one ZWPS, to another ZWPS using KVM.
> copyVolumeBetweenPools method is triggering the CopyCommand to copy the
> volume from store to another.
> This CopyCommand is sent to KVM Agent to execute the operation of copying
> volume from Src Store to Dest Store.
> Issue is: CopyCommand is not implemented in KVM Resouce, hence failing the
> migration of Volumes
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Request:Seq 4-2091581770: { Cmd , MgmtId:
> 235715300172635, via: 4, Ver: v1, Flags: 100111,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"63d241ad-d372-40fc-b770-7661902ff52d","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"f0802731-62fe-3a85-b81a-98ae47e845cf","id":2,"poolType":"NetworkFilesystem","host":"10.102.192.100","path":"/cpg_vol/rajesh/zwps1","port":2049}},"name":"vol3","size":0,"path":"00ff0a7a-95a8-4809-a334-f8a0d9aa3db2","volumeId":13,"accountId":2,"format":"QCOW2","id":13}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"63d241ad-d372-40fc-b770-7661902ff52d","volumeType":"DATADISK","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.102.192.100/cpg_vol/rajesh/secondary","_role":"Image"}},"name":"vol3","size":0,"path":"volumes/2/13","volumeId":13,"accountId":2,"format":"QCOW2","id":13}},"wait":10800}}]
> }
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Processing command:
> org.apache.cloudstack.storage.command.CopyCommand
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Response: unsupported
> commandorg.apache.cloudstack.storage.command.CopyCommand
> 2013-07-11 15:48:59,780 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Seq 4-2091581770: { Ans: , MgmtId:
> 235715300172635, via: 4, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.UnsupportedAnswer":{"result":false,"details":"Unsupported
> command issued:org.apache.cloudstack.storage.command.CopyCommand. Are you
> sure you got the right type of server?","wait":0}}] }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-3470) [KVM] CopyCommand is not implemented in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fang Wang updated CLOUDSTACK-3470:
--
Assignee: (was: Fang Wang)
> [KVM] CopyCommand is not implemented in KVM
> ---
>
> Key: CLOUDSTACK-3470
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3470
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API, KVM
>Affects Versions: 4.2.0
>Reporter: Rajesh Battala
>Priority: Blocker
> Fix For: 4.2.0
>
>
> while performing Volume Migrate from one ZWPS, to another ZWPS using KVM.
> copyVolumeBetweenPools method is triggering the CopyCommand to copy the
> volume from store to another.
> This CopyCommand is sent to KVM Agent to execute the operation of copying
> volume from Src Store to Dest Store.
> Issue is: CopyCommand is not implemented in KVM Resouce, hence failing the
> migration of Volumes
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Request:Seq 4-2091581770: { Cmd , MgmtId:
> 235715300172635, via: 4, Ver: v1, Flags: 100111,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"63d241ad-d372-40fc-b770-7661902ff52d","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"f0802731-62fe-3a85-b81a-98ae47e845cf","id":2,"poolType":"NetworkFilesystem","host":"10.102.192.100","path":"/cpg_vol/rajesh/zwps1","port":2049}},"name":"vol3","size":0,"path":"00ff0a7a-95a8-4809-a334-f8a0d9aa3db2","volumeId":13,"accountId":2,"format":"QCOW2","id":13}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"63d241ad-d372-40fc-b770-7661902ff52d","volumeType":"DATADISK","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.102.192.100/cpg_vol/rajesh/secondary","_role":"Image"}},"name":"vol3","size":0,"path":"volumes/2/13","volumeId":13,"accountId":2,"format":"QCOW2","id":13}},"wait":10800}}]
> }
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Processing command:
> org.apache.cloudstack.storage.command.CopyCommand
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Response: unsupported
> commandorg.apache.cloudstack.storage.command.CopyCommand
> 2013-07-11 15:48:59,780 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Seq 4-2091581770: { Ans: , MgmtId:
> 235715300172635, via: 4, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.UnsupportedAnswer":{"result":false,"details":"Unsupported
> command issued:org.apache.cloudstack.storage.command.CopyCommand. Are you
> sure you got the right type of server?","wait":0}}] }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2725) [Automation] Re-attaching volume on VM failing in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13707233#comment-13707233
]
Fang Wang commented on CLOUDSTACK-2725:
---
sorry I did it at wonr bug
> [Automation] Re-attaching volume on VM failing in KVM
> -
>
> Key: CLOUDSTACK-2725
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2725
> 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: Automation environment KVM
> Found in master also (8d1189c2ae87216bc1c4a1443f75e9a8629abdc2)
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: CLOUDSTACK-2725.rar
>
>
> Below two test case failing from BVT
> integration.smoke.test_volumes.TestVolumes.test_08_resize_volume
> integration.smoke.test_volumes.TestVolumes.test_09_delete_detached_volume
> Steps to reproduce
> Step 1 : Create an account, service offering, create volume, create VM
> Step 2 : Attach volume to VM ,
> Step 3 : Detach volume
> Step 4 : Attach volume to VM again
> Actual result
> Attachment failed with below error
> 2013-05-28 13:45:39,101 DEBUG [agent.transport.Request]
> (Job-Executor-98:job-1246) Seq 5-258539658: Rec
> eived: { Ans: , MgmtId: 29066118877352, via: 5, Ver: v1, Flags: 10, {
> AttachAnswer } }
> 2013-05-28 13:45:39,106 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-98:job-1246) Unexpected e
> xception while executing
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
> com.cloud.utils.exception.CloudRuntimeException: Failed to attach volume:
> TestDiskServ to VM: ce79edb6-
> a306-4ac4-95e4-6202800f691e; org.libvirt.LibvirtException: internal error
> unable to execute QEMU comman
> d '__com.redhat_drive_add': Duplicate ID 'drive-virtio-disk1' for drive
> at
> com.cloud.storage.VolumeManagerImpl.sendAttachVolumeCommand(VolumeManagerImpl.java:1583)
> at
> com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1788)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercep
> t(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:1
> 22)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-05-28 13:45:39,107 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-98:job-1246) Complete asy
> nc job-1246, jobStatus: 2, resultCode: 530, result: Error Code: 530 Error
> text: Failed to attach volume
> : TestDiskServ to VM: ce79edb6-a306-4ac4-95e4-6202800f691e;
> org.libvirt.LibvirtException: internal erro
--
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-2725) [Automation] Re-attaching volume on VM failing in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fang Wang reopened CLOUDSTACK-2725:
---
I did a mistake , ignore my previsous comment, for the wrong bug
> [Automation] Re-attaching volume on VM failing in KVM
> -
>
> Key: CLOUDSTACK-2725
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2725
> 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: Automation environment KVM
> Found in master also (8d1189c2ae87216bc1c4a1443f75e9a8629abdc2)
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: CLOUDSTACK-2725.rar
>
>
> Below two test case failing from BVT
> integration.smoke.test_volumes.TestVolumes.test_08_resize_volume
> integration.smoke.test_volumes.TestVolumes.test_09_delete_detached_volume
> Steps to reproduce
> Step 1 : Create an account, service offering, create volume, create VM
> Step 2 : Attach volume to VM ,
> Step 3 : Detach volume
> Step 4 : Attach volume to VM again
> Actual result
> Attachment failed with below error
> 2013-05-28 13:45:39,101 DEBUG [agent.transport.Request]
> (Job-Executor-98:job-1246) Seq 5-258539658: Rec
> eived: { Ans: , MgmtId: 29066118877352, via: 5, Ver: v1, Flags: 10, {
> AttachAnswer } }
> 2013-05-28 13:45:39,106 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-98:job-1246) Unexpected e
> xception while executing
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
> com.cloud.utils.exception.CloudRuntimeException: Failed to attach volume:
> TestDiskServ to VM: ce79edb6-
> a306-4ac4-95e4-6202800f691e; org.libvirt.LibvirtException: internal error
> unable to execute QEMU comman
> d '__com.redhat_drive_add': Duplicate ID 'drive-virtio-disk1' for drive
> at
> com.cloud.storage.VolumeManagerImpl.sendAttachVolumeCommand(VolumeManagerImpl.java:1583)
> at
> com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1788)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercep
> t(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:1
> 22)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-05-28 13:45:39,107 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-98:job-1246) Complete asy
> nc job-1246, jobStatus: 2, resultCode: 530, result: Error Code: 530 Error
> text: Failed to attach volume
> : TestDiskServ to VM: ce79edb6-a306-4ac4-95e4-6202800f691e;
> org.libvirt.LibvirtException: internal erro
--
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-2725) [Automation] Re-attaching volume on VM failing in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fang Wang closed CLOUDSTACK-2725.
-
Resolution: Unresolved
This is to support the volume migration on KVM.
> [Automation] Re-attaching volume on VM failing in KVM
> -
>
> Key: CLOUDSTACK-2725
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2725
> 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: Automation environment KVM
> Found in master also (8d1189c2ae87216bc1c4a1443f75e9a8629abdc2)
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: CLOUDSTACK-2725.rar
>
>
> Below two test case failing from BVT
> integration.smoke.test_volumes.TestVolumes.test_08_resize_volume
> integration.smoke.test_volumes.TestVolumes.test_09_delete_detached_volume
> Steps to reproduce
> Step 1 : Create an account, service offering, create volume, create VM
> Step 2 : Attach volume to VM ,
> Step 3 : Detach volume
> Step 4 : Attach volume to VM again
> Actual result
> Attachment failed with below error
> 2013-05-28 13:45:39,101 DEBUG [agent.transport.Request]
> (Job-Executor-98:job-1246) Seq 5-258539658: Rec
> eived: { Ans: , MgmtId: 29066118877352, via: 5, Ver: v1, Flags: 10, {
> AttachAnswer } }
> 2013-05-28 13:45:39,106 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-98:job-1246) Unexpected e
> xception while executing
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
> com.cloud.utils.exception.CloudRuntimeException: Failed to attach volume:
> TestDiskServ to VM: ce79edb6-
> a306-4ac4-95e4-6202800f691e; org.libvirt.LibvirtException: internal error
> unable to execute QEMU comman
> d '__com.redhat_drive_add': Duplicate ID 'drive-virtio-disk1' for drive
> at
> com.cloud.storage.VolumeManagerImpl.sendAttachVolumeCommand(VolumeManagerImpl.java:1583)
> at
> com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1788)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercep
> t(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:1
> 22)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-05-28 13:45:39,107 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-98:job-1246) Complete asy
> nc job-1246, jobStatus: 2, resultCode: 530, result: Error Code: 530 Error
> text: Failed to attach volume
> : TestDiskServ to VM: ce79edb6-a306-4ac4-95e4-6202800f691e;
> org.libvirt.LibvirtException: internal erro
--
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-3470) [KVM] CopyCommand is not implemented in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13707202#comment-13707202
]
Fang Wang commented on CLOUDSTACK-3470:
---
Volume migration is not supported on KVM yet.
> [KVM] CopyCommand is not implemented in KVM
> ---
>
> Key: CLOUDSTACK-3470
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3470
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API, KVM
>Affects Versions: 4.2.0
>Reporter: Rajesh Battala
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
>
> while performing Volume Migrate from one ZWPS, to another ZWPS using KVM.
> copyVolumeBetweenPools method is triggering the CopyCommand to copy the
> volume from store to another.
> This CopyCommand is sent to KVM Agent to execute the operation of copying
> volume from Src Store to Dest Store.
> Issue is: CopyCommand is not implemented in KVM Resouce, hence failing the
> migration of Volumes
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Request:Seq 4-2091581770: { Cmd , MgmtId:
> 235715300172635, via: 4, Ver: v1, Flags: 100111,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"63d241ad-d372-40fc-b770-7661902ff52d","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"f0802731-62fe-3a85-b81a-98ae47e845cf","id":2,"poolType":"NetworkFilesystem","host":"10.102.192.100","path":"/cpg_vol/rajesh/zwps1","port":2049}},"name":"vol3","size":0,"path":"00ff0a7a-95a8-4809-a334-f8a0d9aa3db2","volumeId":13,"accountId":2,"format":"QCOW2","id":13}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"63d241ad-d372-40fc-b770-7661902ff52d","volumeType":"DATADISK","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.102.192.100/cpg_vol/rajesh/secondary","_role":"Image"}},"name":"vol3","size":0,"path":"volumes/2/13","volumeId":13,"accountId":2,"format":"QCOW2","id":13}},"wait":10800}}]
> }
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Processing command:
> org.apache.cloudstack.storage.command.CopyCommand
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Response: unsupported
> commandorg.apache.cloudstack.storage.command.CopyCommand
> 2013-07-11 15:48:59,780 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Seq 4-2091581770: { Ans: , MgmtId:
> 235715300172635, via: 4, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.UnsupportedAnswer":{"result":false,"details":"Unsupported
> command issued:org.apache.cloudstack.storage.command.CopyCommand. Are you
> sure you got the right type of server?","wait":0}}] }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-3470) [KVM] CopyCommand is not implemented in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fang Wang resolved CLOUDSTACK-3470.
---
Resolution: Won't Fix
> [KVM] CopyCommand is not implemented in KVM
> ---
>
> Key: CLOUDSTACK-3470
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3470
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API, KVM
>Affects Versions: 4.2.0
>Reporter: Rajesh Battala
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
>
> while performing Volume Migrate from one ZWPS, to another ZWPS using KVM.
> copyVolumeBetweenPools method is triggering the CopyCommand to copy the
> volume from store to another.
> This CopyCommand is sent to KVM Agent to execute the operation of copying
> volume from Src Store to Dest Store.
> Issue is: CopyCommand is not implemented in KVM Resouce, hence failing the
> migration of Volumes
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Request:Seq 4-2091581770: { Cmd , MgmtId:
> 235715300172635, via: 4, Ver: v1, Flags: 100111,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"63d241ad-d372-40fc-b770-7661902ff52d","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"f0802731-62fe-3a85-b81a-98ae47e845cf","id":2,"poolType":"NetworkFilesystem","host":"10.102.192.100","path":"/cpg_vol/rajesh/zwps1","port":2049}},"name":"vol3","size":0,"path":"00ff0a7a-95a8-4809-a334-f8a0d9aa3db2","volumeId":13,"accountId":2,"format":"QCOW2","id":13}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"63d241ad-d372-40fc-b770-7661902ff52d","volumeType":"DATADISK","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.102.192.100/cpg_vol/rajesh/secondary","_role":"Image"}},"name":"vol3","size":0,"path":"volumes/2/13","volumeId":13,"accountId":2,"format":"QCOW2","id":13}},"wait":10800}}]
> }
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Processing command:
> org.apache.cloudstack.storage.command.CopyCommand
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Response: unsupported
> commandorg.apache.cloudstack.storage.command.CopyCommand
> 2013-07-11 15:48:59,780 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Seq 4-2091581770: { Ans: , MgmtId:
> 235715300172635, via: 4, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.UnsupportedAnswer":{"result":false,"details":"Unsupported
> command issued:org.apache.cloudstack.storage.command.CopyCommand. Are you
> sure you got the right type of server?","wait":0}}] }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-3470) [KVM] CopyCommand is not implemented in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fang Wang updated CLOUDSTACK-3470:
--
Assignee: Fang Wang
> [KVM] CopyCommand is not implemented in KVM
> ---
>
> Key: CLOUDSTACK-3470
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3470
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API, KVM
>Affects Versions: 4.2.0
>Reporter: Rajesh Battala
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
>
> while performing Volume Migrate from one ZWPS, to another ZWPS using KVM.
> copyVolumeBetweenPools method is triggering the CopyCommand to copy the
> volume from store to another.
> This CopyCommand is sent to KVM Agent to execute the operation of copying
> volume from Src Store to Dest Store.
> Issue is: CopyCommand is not implemented in KVM Resouce, hence failing the
> migration of Volumes
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Request:Seq 4-2091581770: { Cmd , MgmtId:
> 235715300172635, via: 4, Ver: v1, Flags: 100111,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"63d241ad-d372-40fc-b770-7661902ff52d","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"f0802731-62fe-3a85-b81a-98ae47e845cf","id":2,"poolType":"NetworkFilesystem","host":"10.102.192.100","path":"/cpg_vol/rajesh/zwps1","port":2049}},"name":"vol3","size":0,"path":"00ff0a7a-95a8-4809-a334-f8a0d9aa3db2","volumeId":13,"accountId":2,"format":"QCOW2","id":13}},"destTO":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"63d241ad-d372-40fc-b770-7661902ff52d","volumeType":"DATADISK","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.102.192.100/cpg_vol/rajesh/secondary","_role":"Image"}},"name":"vol3","size":0,"path":"volumes/2/13","volumeId":13,"accountId":2,"format":"QCOW2","id":13}},"wait":10800}}]
> }
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Processing command:
> org.apache.cloudstack.storage.command.CopyCommand
> 2013-07-11 15:48:59,778 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Response: unsupported
> commandorg.apache.cloudstack.storage.command.CopyCommand
> 2013-07-11 15:48:59,780 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-5:null) Seq 4-2091581770: { Ans: , MgmtId:
> 235715300172635, via: 4, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.UnsupportedAnswer":{"result":false,"details":"Unsupported
> command issued:org.apache.cloudstack.storage.command.CopyCommand. Are you
> sure you got the right type of server?","wait":0}}] }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2725) [Automation] Re-attaching volume on VM failing in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fang Wang updated CLOUDSTACK-2725:
--
Assignee: Fang Wang (was: Girish Shilamkar)
> [Automation] Re-attaching volume on VM failing in KVM
> -
>
> Key: CLOUDSTACK-2725
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2725
> 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: Automation environment KVM
> Found in master also (8d1189c2ae87216bc1c4a1443f75e9a8629abdc2)
>Reporter: Rayees Namathponnan
>Assignee: Fang Wang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: CLOUDSTACK-2725.rar
>
>
> Below two test case failing from BVT
> integration.smoke.test_volumes.TestVolumes.test_08_resize_volume
> integration.smoke.test_volumes.TestVolumes.test_09_delete_detached_volume
> Steps to reproduce
> Step 1 : Create an account, service offering, create volume, create VM
> Step 2 : Attach volume to VM ,
> Step 3 : Detach volume
> Step 4 : Attach volume to VM again
> Actual result
> Attachment failed with below error
> 2013-05-28 13:45:39,101 DEBUG [agent.transport.Request]
> (Job-Executor-98:job-1246) Seq 5-258539658: Rec
> eived: { Ans: , MgmtId: 29066118877352, via: 5, Ver: v1, Flags: 10, {
> AttachAnswer } }
> 2013-05-28 13:45:39,106 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-98:job-1246) Unexpected e
> xception while executing
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd
> com.cloud.utils.exception.CloudRuntimeException: Failed to attach volume:
> TestDiskServ to VM: ce79edb6-
> a306-4ac4-95e4-6202800f691e; org.libvirt.LibvirtException: internal error
> unable to execute QEMU comman
> d '__com.redhat_drive_add': Duplicate ID 'drive-virtio-disk1' for drive
> at
> com.cloud.storage.VolumeManagerImpl.sendAttachVolumeCommand(VolumeManagerImpl.java:1583)
> at
> com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1788)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercep
> t(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:1
> 22)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-05-28 13:45:39,107 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-98:job-1246) Complete asy
> nc job-1246, jobStatus: 2, resultCode: 530, result: Error Code: 530 Error
> text: Failed to attach volume
> : TestDiskServ to VM: ce79edb6-a306-4ac4-95e4-6202800f691e;
> org.libvirt.LibvirtException: internal erro
--
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-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=13703970#comment-13703970
]
Fang Wang commented on CLOUDSTACK-3237:
---
The volume path is inconsistent inside the DB table and the config file.
> [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: Sateesh Chodapuneedi
>Priority: Blocker
> Fix For: 4.2.0
>
> 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%
[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=13695958#comment-13695958
]
Fang Wang commented on CLOUDSTACK-3237:
---
Which version of MS you are testing with?
1. the observation I got, I used an older version of CS before the Object Store
code is in;
2. I am testing the newer MS version with the object store in, the path problem
we saw may have different behavior.
> [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
>Priority: Blocker
> Fix For: 4.2.0
>
> 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
[jira] [Commented] (CLOUDSTACK-3238) creating template from snapshot fails in vmware
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13695930#comment-13695930
]
Fang Wang commented on CLOUDSTACK-3238:
---
After the object store code is in, this function needs to be pulled in and
rewritten.
> creating template from snapshot fails in vmware
> ---
>
> Key: CLOUDSTACK-3238
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3238
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Template, VMware
>Affects Versions: 4.2.0
> Environment: vmware advanced zone with cluster level primary storage
>Reporter: shweta agarwal
>Assignee: edison su
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: cloud.out, management-server.zip
>
>
> Repro steps:
> Create a VM
> create a snapshot of root disk of the VM
> Create a template from the backed up snapshot
> Bug:
> hittting exception:
> 2013-06-27 17:16:10,912 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-13:null) submit async job-371, details: AsyncJobVO {id:371,
> userId: 2, accountId: 2, sessionKey: null, instanceType: Template,
> instanceId: 228, cmd:
> org.apache.cloudstack.api.command.user.template.CreateTemplateCmd,
> cmdOriginator: null, cmdInfo:
> {"sessionkey":"u7fuCDtJanfTR6ObPknZNoA9z6c\u003d","ctxUserId":"2","httpmethod":"GET","osTypeId":"9e1b6a5c-d98f-11e2-95e7-0682fe17","isPublic":"false","response":"json","id":"228","displayText":"admin","snapshotid":"045d12f4-257b-4c28-b975-1b594fd9b2a6","passwordEnabled":"false","name":"admin","_":"1372333569675","ctxAccountId":"2","ctxStartEventId":"1426"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 7159676928023,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-06-27 17:16:10,915 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null)
> ===END=== 10.146.0.12 -- GET
> command=createTemplate&response=json&sessionkey=u7fuCDtJanfTR6ObPknZNoA9z6c%3D&snapshotid=045d12f4-257b-4c28-b975-1b594fd9b2a6&name=admin&displayText=admin&osTypeId=9e1b6a5c-d98f-11e2-95e7-0682fe17&isPublic=false&passwordEnabled=false&_=1372333569675
> 2013-06-27 17:16:10,980 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-56:job-371) Executing
> org.apache.cloudstack.api.command.user.template.CreateTemplateCmd for job-371
> 2013-06-27 17:16:11,186 DEBUG [cloud.template.TemplateManagerImpl]
> (Job-Executor-56:job-371) Failed to create
> templatejava.lang.NullPointerException
> 2013-06-27 17:16:11,265 ERROR [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-56:job-371) Unexpected exception while executing
> org.apache.cloudstack.api.command.user.template.CreateTemplateCmd
> com.cloud.utils.exception.CloudRuntimeException: Failed to create
> templatejava.lang.NullPointerException
> at
> com.cloud.template.TemplateManagerImpl.createPrivateTemplate(TemplateManagerImpl.java:1770)
> at
> com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at
> org.apache.cloudstack.api.command.user.template.CreateTemplateCmd.execute(CreateTemplateCmd.java:256)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
> 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-06-27 17:16:11,268 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-56:job-371) Complete async job-371, jobStatus: 2, resultCode:
> 530, result: Error Code: 530 Error text: Failed to create
> templatejava.lang.NullPointerException
> 2013-06-27 17:16:11,270 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-422:null) Seq 1-646158771: Response Received:
> 2013-06-27 17:16:11,271 DEBUG [agent.transport.Request]
> (StatsCollector-2:null) Seq 1-646158771: Received: { Ans: , MgmtId:
> 7159676928023, via: 1, Ver: v1, Flags: 10, { GetStorageStatsAnswer } }
> 2013-06-27 17:16:11,283 DEBUG [agent.manager.DirectAgentAttache] (DirectA
> Attaching MS log and ssvm logs for the same
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please
[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=13695928#comment-13695928
]
Fang Wang commented on CLOUDSTACK-3237:
---
There is an issue for volume migration for a snapshot volume, a volume created
from a snapshot.
I tried your scenerio, if I do a simple snapshot, then migration, it works ok;
1. take a snapshot of a root volume;
2. migrate the vol; -- this work ok;
3. take a snapshot again;
4. migrate -- this will fail; the reason is after the third step, the
original ROOT disk no longer in the expected directory.
The DB path is incorrect.
> [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
>Priority: Blocker
> Fix For: 4.2.0
>
> 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,"
[jira] [Commented] (CLOUDSTACK-2384) Template created from snapshot or root disk is not displayed in the templates view in VMware setup.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13695133#comment-13695133 ] Fang Wang commented on CLOUDSTACK-2384: --- Checked in the fix to master and submitted the review request: https://reviews.apache.org/r/12143/ commit e2f2b3be483cd7846f9f7829eff0af06e4ee633c Author: Fang Wang Date: Thu Jun 27 15:31:28 2013 -0700 CLOUDSTACK-2384: Template created from snapshot error. > Template created from snapshot or root disk is not displayed in the templates > view in VMware setup. > --- > > Key: CLOUDSTACK-2384 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2384 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot >Affects Versions: 4.2.0 > Environment: Vmware >Reporter: Kiran Koneti >Assignee: Fang Wang >Priority: Blocker > Fix For: 4.2.0 > > > The below are the steps followed. > I created a VM with a root disk and data disk using the windows 2012 and > windows 8 32bit ISO's. > Case 1: > In the case 1 stopped the windows 2012 machine and created the template the > aysnc job shows completed for the same case but the template is not displayed > in the UI. > I waited for longer time i.e almost 1 day then I was able to see the same in > the UI of the templates view. > The DB details for the same still shows allocated and all the details are as > below: > *** 20. row *** > id: 210 > unique_name: 221a6cfd2-f609-3cb6-a879-afdc47ca2c43 >name: Winserve8 >uuid: 0efb17b3-13d0-4e25-bb9b-709a4e71f584 > public: 1 >featured: 1 >type: USER > hvm: 1 >bits: 64 > url: NULL > format: OVA > created: 2013-05-07 15:44:19 > removed: NULL > account_id: 2 >checksum: 93418461b411aa5559bc978a9b0d73f3 >display_text: Winserve8 > enable_password: 0 > enable_sshkey: 0 > guest_os_id: 168 >bootable: 1 > prepopulate: 0 > cross_zones: 0 > extractable: 1 > hypervisor_type: VMware > source_template_id: 204 >template_tag: NULL >sort_key: 0 >size: NULL > state: Allocated >update_count: 0 > updated: NULL > image_data_store_id: 1 > I initially observed only the ovf file and later after a day I was able to > see the .vmdk,.ova and also templates.properties file. > Case2: > In the case 2 I took a snapshot of the windows 2012 root disk. > from this snapshot I tried to create a template then I observed the similar > behaviour. > investigating into deep I found that the secondary storage has only the .ovf > file and the details of the snapshot are as below: > "*** 21. row *** > id: 211 > unique_name: 272531697-0e83-3556-8a7f-346aa8d58beb >name: CreatedfromSnapshot >uuid: d110660c-48cf-4362-875a-e3ae068ef89d > public: 1 >featured: 0 >type: USER > hvm: 1 >bits: 64 > url: NULL > format: RAW > created: 2013-05-08 14:25:04 > removed: NULL > account_id: 2 >checksum: NULL >display_text: win8server > enable_password: 0 > enable_sshkey: 0 > guest_os_id: 168 >bootable: 1 > prepopulate: 0 > cross_zones: 0 > extractable: 0 > hypervisor_type: VMware > source_template_id: 204 >template_tag: NULL >sort_key: 0 >size: NULL > state: Allocated >update_count: 0 > updated: NULL > image_data_store_id: 1" > I observed the same behaviour even with the centos 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] [Resolved] (CLOUDSTACK-2384) Template created from snapshot or root disk is not displayed in the templates view in VMware setup.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fang Wang resolved CLOUDSTACK-2384. --- Resolution: Fixed > Template created from snapshot or root disk is not displayed in the templates > view in VMware setup. > --- > > Key: CLOUDSTACK-2384 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2384 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot >Affects Versions: 4.2.0 > Environment: Vmware >Reporter: Kiran Koneti >Assignee: Fang Wang >Priority: Blocker > Fix For: 4.2.0 > > > The below are the steps followed. > I created a VM with a root disk and data disk using the windows 2012 and > windows 8 32bit ISO's. > Case 1: > In the case 1 stopped the windows 2012 machine and created the template the > aysnc job shows completed for the same case but the template is not displayed > in the UI. > I waited for longer time i.e almost 1 day then I was able to see the same in > the UI of the templates view. > The DB details for the same still shows allocated and all the details are as > below: > *** 20. row *** > id: 210 > unique_name: 221a6cfd2-f609-3cb6-a879-afdc47ca2c43 >name: Winserve8 >uuid: 0efb17b3-13d0-4e25-bb9b-709a4e71f584 > public: 1 >featured: 1 >type: USER > hvm: 1 >bits: 64 > url: NULL > format: OVA > created: 2013-05-07 15:44:19 > removed: NULL > account_id: 2 >checksum: 93418461b411aa5559bc978a9b0d73f3 >display_text: Winserve8 > enable_password: 0 > enable_sshkey: 0 > guest_os_id: 168 >bootable: 1 > prepopulate: 0 > cross_zones: 0 > extractable: 1 > hypervisor_type: VMware > source_template_id: 204 >template_tag: NULL >sort_key: 0 >size: NULL > state: Allocated >update_count: 0 > updated: NULL > image_data_store_id: 1 > I initially observed only the ovf file and later after a day I was able to > see the .vmdk,.ova and also templates.properties file. > Case2: > In the case 2 I took a snapshot of the windows 2012 root disk. > from this snapshot I tried to create a template then I observed the similar > behaviour. > investigating into deep I found that the secondary storage has only the .ovf > file and the details of the snapshot are as below: > "*** 21. row *** > id: 211 > unique_name: 272531697-0e83-3556-8a7f-346aa8d58beb >name: CreatedfromSnapshot >uuid: d110660c-48cf-4362-875a-e3ae068ef89d > public: 1 >featured: 0 >type: USER > hvm: 1 >bits: 64 > url: NULL > format: RAW > created: 2013-05-08 14:25:04 > removed: NULL > account_id: 2 >checksum: NULL >display_text: win8server > enable_password: 0 > enable_sshkey: 0 > guest_os_id: 168 >bootable: 1 > prepopulate: 0 > cross_zones: 0 > extractable: 0 > hypervisor_type: VMware > source_template_id: 204 >template_tag: NULL >sort_key: 0 >size: NULL > state: Allocated >update_count: 0 > updated: NULL > image_data_store_id: 1" > I observed the same behaviour even with the centos 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-2384) Template created from snapshot or root disk is not displayed in the templates view in VMware setup.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13694926#comment-13694926 ] Fang Wang commented on CLOUDSTACK-2384: --- Kiran, thanks. Yes, the code path got changed, and now the vmdk file failed. somehow someone changed the uuid of the backup snapshot, and now the name of the vmdk files got messed up. I'll fix it. No need to wait for the vmdk file to show up, it does not have correct name path, so it won't show up in this version (The version without object store yet). > Template created from snapshot or root disk is not displayed in the templates > view in VMware setup. > --- > > Key: CLOUDSTACK-2384 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2384 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot >Affects Versions: 4.2.0 > Environment: Vmware >Reporter: Kiran Koneti >Assignee: Fang Wang >Priority: Blocker > Fix For: 4.2.0 > > > The below are the steps followed. > I created a VM with a root disk and data disk using the windows 2012 and > windows 8 32bit ISO's. > Case 1: > In the case 1 stopped the windows 2012 machine and created the template the > aysnc job shows completed for the same case but the template is not displayed > in the UI. > I waited for longer time i.e almost 1 day then I was able to see the same in > the UI of the templates view. > The DB details for the same still shows allocated and all the details are as > below: > *** 20. row *** > id: 210 > unique_name: 221a6cfd2-f609-3cb6-a879-afdc47ca2c43 >name: Winserve8 >uuid: 0efb17b3-13d0-4e25-bb9b-709a4e71f584 > public: 1 >featured: 1 >type: USER > hvm: 1 >bits: 64 > url: NULL > format: OVA > created: 2013-05-07 15:44:19 > removed: NULL > account_id: 2 >checksum: 93418461b411aa5559bc978a9b0d73f3 >display_text: Winserve8 > enable_password: 0 > enable_sshkey: 0 > guest_os_id: 168 >bootable: 1 > prepopulate: 0 > cross_zones: 0 > extractable: 1 > hypervisor_type: VMware > source_template_id: 204 >template_tag: NULL >sort_key: 0 >size: NULL > state: Allocated >update_count: 0 > updated: NULL > image_data_store_id: 1 > I initially observed only the ovf file and later after a day I was able to > see the .vmdk,.ova and also templates.properties file. > Case2: > In the case 2 I took a snapshot of the windows 2012 root disk. > from this snapshot I tried to create a template then I observed the similar > behaviour. > investigating into deep I found that the secondary storage has only the .ovf > file and the details of the snapshot are as below: > "*** 21. row *** > id: 211 > unique_name: 272531697-0e83-3556-8a7f-346aa8d58beb >name: CreatedfromSnapshot >uuid: d110660c-48cf-4362-875a-e3ae068ef89d > public: 1 >featured: 0 >type: USER > hvm: 1 >bits: 64 > url: NULL > format: RAW > created: 2013-05-08 14:25:04 > removed: NULL > account_id: 2 >checksum: NULL >display_text: win8server > enable_password: 0 > enable_sshkey: 0 > guest_os_id: 168 >bootable: 1 > prepopulate: 0 > cross_zones: 0 > extractable: 0 > hypervisor_type: VMware > source_template_id: 204 >template_tag: NULL >sort_key: 0 >size: NULL > state: Allocated >update_count: 0 > updated: NULL > image_data_store_id: 1" > I observed the same behaviour even with the centos 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
