[jira] [Created] (CLOUDSTACK-7763) Reservations for VMware VMs remain after dynamic scaling completes
Bharat Kumar created CLOUDSTACK-7763: Summary: Reservations for VMware VMs remain after dynamic scaling completes Key: CLOUDSTACK-7763 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7763 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.5.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.5.0 When using the dynamic scaling feature for VMware VMs, a reservation is configured on the VM, however it is not removed once the scaling completes successfully. This is happening even though vmware.reserve.cpu/mem parameters are false for the cluster and in Global Settings. The reservation is removed if you subsequently stop/start the VM. REPRO STEPS == 1) Deploy a VM from a dynamically scalable template. 2) When it is up and running, notice the lack of any configured reservations. 3) Scale up the VM by changing to a Compute Offering with more CPU/RAM. 4) After it succeeds, notice the reservations are still applied. 5) Stop and start the VM. 6) Notice that the reservations have been removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7760) Data disk size is not considering for primary storage resource limit check
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7760: - Status: Reviewable (was: In Progress) > Data disk size is not considering for primary storage resource limit check > -- > > Key: CLOUDSTACK-7760 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7760 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.5.0 > > > During VM deployment and while choosing CUSTOM disk offering for data disk, > the size of the data disk is not considered for checking resource limit of > primary storage. > size += _diskOfferingDao.findById(diskOfferingId).getDiskSize(); > _resourceLimitMgr.checkResourceLimit(owner, ResourceType.primary_storage, new > Long (size)); > getDiskSize() method returns 0 in case of custom disk offering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7761) [Automation] Rebooting System VMs - VMs are getting stopped and started instead of reboot
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Xu resolved CLOUDSTACK-7761.
Resolution: Fixed
commit 0141b37784805b1a55bc450affa282897889e9b9
Author: Anthony Xu
Date: Tue Oct 21 17:11:44 2014 -0700
CLOUDSTACK-7761:
Revert "when system VM ping times out, stop system VM"
This reverts commit ee23be1942001ab732cfb3ad50fa24163cb88a48.
> [Automation] Rebooting System VMs - VMs are getting stopped and started
> instead of reboot
> -
>
> Key: CLOUDSTACK-7761
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7761
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Anthony Xu
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.zip
>
>
> Rebooting System VM using cases are failing on the automation as shown below:
> *Error Message*
> Check Private IP after reboot with that of before reboot
> *Stacktrace*
> File "/usr/lib/python2.7/unittest/case.py", line 332, in run
> testMethod()
> File "/root/cloudstack/test/integration/smoke/test_ssvm.py", line 725, in
> test_07_reboot_ssvm
> "Check Private IP after reboot with that of before reboot"
> File "/usr/lib/python2.7/unittest/case.py", line 516, in assertEqual
> assertion_func(first, second, msg=msg)
> File "/usr/lib/python2.7/unittest/case.py", line 927, in
> assertMultiLineEqual
> self.fail(self._formatMessage(msg, standardMsg))
> File "/usr/lib/python2.7/unittest/case.py", line 413, in fail
> raise self.failureException(msg)
> 'Check Private IP after reboot with that of before reboot\n
> On further analysis, we found that the reboot command is actually calling
> Stopcommand in the later part of the job. This results in the change in
> private ip address.
> {noformat}
> 2014-10-21 17:06:35,451 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-21:ctx-f76226cf) ===START=== 10.220.135.30 -- GET
> response=json&apiKey=8zS-PDiww66KLa3apG55n-SpVbHRv7o4m1yTKiJTghk3NmbsfVAcE_Y1ymDuc-7huYpOW1Q221BgVCCQXcy_Zg&command=rebootSystemVm&id=0d3261c0-18af-4f4f-8052-78398ea3d319&signature=TXvdc%2FRdiaOYDVvVKjoo%2FYaoMho%3D
> 2014-10-21 17:06:35,476 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-21:ctx-f76226cf ctx-64e39462 ctx-47749a02) submit async
> job-547, details: AsyncJobVO {id:547, userId: 2, accountId: 2, instanceType:
> SystemVm, instanceId: 2, cmd:
> org.apache.cloudstack.api.command.admin.systemvm.RebootSystemVmCmd, cmdInfo:
> {"response":"json","id":"0d3261c0-18af-4f4f-8052-78398ea3d319","ctxDetails":"{\"com.cloud.vm.VirtualMachine\":\"0d3261c0-18af-4f4f-8052-78398ea3d319\"}","cmdEventType":"PROXY.REBOOT","ctxUserId":"2","httpmethod":"GET","uuid":"0d3261c0-18af-4f4f-8052-78398ea3d319","ctxAccountId":"2","ctxStartEventId":"1702","apiKey":"8zS-PDiww66KLa3apG55n-SpVbHRv7o4m1yTKiJTghk3NmbsfVAcE_Y1ymDuc-7huYpOW1Q221BgVCCQXcy_Zg","signature":"TXvdc/RdiaOYDVvVKjoo/YaoMho\u003d"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 59825535280071, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-10-21 17:06:35,476 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-44:ctx-7d84e64c job-547) Add job-547 into job monitoring
> 2014-10-21 17:06:35,476 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-44:ctx-7d84e64c job-547) Executing AsyncJobVO {id:547,
> userId: 2, accountId: 2, instanceType: SystemVm, instanceId: 2, cmd:
> org.apache.cloudstack.api.command.admin.systemvm.RebootSystemVmCmd, cmdInfo:
> {"response":"json","id":"0d3261c0-18af-4f4f-8052-78398ea3d319","ctxDetails":"{\"com.cloud.vm.VirtualMachine\":\"0d3261c0-18af-4f4f-8052-78398ea3d319\"}","cmdEventType":"PROXY.REBOOT","ctxUserId":"2","httpmethod":"GET","uuid":"0d3261c0-18af-4f4f-8052-78398ea3d319","ctxAccountId":"2","ctxStartEventId":"1702","apiKey":"8zS-PDiww66KLa3apG55n-SpVbHRv7o4m1yTKiJTghk3NmbsfVAcE_Y1ymDuc-7huYpOW1Q221BgVCCQXcy_Zg","signature":"TXvdc/RdiaOYDVvVKjoo/YaoMho\u003d"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 59825535280071, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-10-21 17:06:35,477 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-21:ctx-f76226cf ctx-64e39462 ctx-47749a02) ===END===
> 10.220.135.30 -- GET
> response=json&apiKey=8zS-PDiww66KLa3apG55n-SpVbHRv7o4m1yTKiJTghk3NmbsfVAcE_Y1ymDuc-7huYpOW1Q221BgVCCQXcy_Zg&command=rebootSystemVm&id=0d3261c0-18af-4f4f-8052-78398ea3d319&signature=TXvdc%2FRdiaOYDVvVKjoo%2FYaoMho%3D
[jira] [Commented] (CLOUDSTACK-7761) [Automation] Rebooting System VMs - VMs are getting stopped and started instead of reboot
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14179395#comment-14179395
]
ASF subversion and git services commented on CLOUDSTACK-7761:
-
Commit 0141b37784805b1a55bc450affa282897889e9b9 in cloudstack's branch
refs/heads/4.5 from [~anthonyxu]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0141b37 ]
CLOUDSTACK-7761:
Revert "when system VM ping times out, stop system VM"
This reverts commit ee23be1942001ab732cfb3ad50fa24163cb88a48.
> [Automation] Rebooting System VMs - VMs are getting stopped and started
> instead of reboot
> -
>
> Key: CLOUDSTACK-7761
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7761
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Anthony Xu
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.zip
>
>
> Rebooting System VM using cases are failing on the automation as shown below:
> *Error Message*
> Check Private IP after reboot with that of before reboot
> *Stacktrace*
> File "/usr/lib/python2.7/unittest/case.py", line 332, in run
> testMethod()
> File "/root/cloudstack/test/integration/smoke/test_ssvm.py", line 725, in
> test_07_reboot_ssvm
> "Check Private IP after reboot with that of before reboot"
> File "/usr/lib/python2.7/unittest/case.py", line 516, in assertEqual
> assertion_func(first, second, msg=msg)
> File "/usr/lib/python2.7/unittest/case.py", line 927, in
> assertMultiLineEqual
> self.fail(self._formatMessage(msg, standardMsg))
> File "/usr/lib/python2.7/unittest/case.py", line 413, in fail
> raise self.failureException(msg)
> 'Check Private IP after reboot with that of before reboot\n
> On further analysis, we found that the reboot command is actually calling
> Stopcommand in the later part of the job. This results in the change in
> private ip address.
> {noformat}
> 2014-10-21 17:06:35,451 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-21:ctx-f76226cf) ===START=== 10.220.135.30 -- GET
> response=json&apiKey=8zS-PDiww66KLa3apG55n-SpVbHRv7o4m1yTKiJTghk3NmbsfVAcE_Y1ymDuc-7huYpOW1Q221BgVCCQXcy_Zg&command=rebootSystemVm&id=0d3261c0-18af-4f4f-8052-78398ea3d319&signature=TXvdc%2FRdiaOYDVvVKjoo%2FYaoMho%3D
> 2014-10-21 17:06:35,476 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-21:ctx-f76226cf ctx-64e39462 ctx-47749a02) submit async
> job-547, details: AsyncJobVO {id:547, userId: 2, accountId: 2, instanceType:
> SystemVm, instanceId: 2, cmd:
> org.apache.cloudstack.api.command.admin.systemvm.RebootSystemVmCmd, cmdInfo:
> {"response":"json","id":"0d3261c0-18af-4f4f-8052-78398ea3d319","ctxDetails":"{\"com.cloud.vm.VirtualMachine\":\"0d3261c0-18af-4f4f-8052-78398ea3d319\"}","cmdEventType":"PROXY.REBOOT","ctxUserId":"2","httpmethod":"GET","uuid":"0d3261c0-18af-4f4f-8052-78398ea3d319","ctxAccountId":"2","ctxStartEventId":"1702","apiKey":"8zS-PDiww66KLa3apG55n-SpVbHRv7o4m1yTKiJTghk3NmbsfVAcE_Y1ymDuc-7huYpOW1Q221BgVCCQXcy_Zg","signature":"TXvdc/RdiaOYDVvVKjoo/YaoMho\u003d"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 59825535280071, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-10-21 17:06:35,476 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-44:ctx-7d84e64c job-547) Add job-547 into job monitoring
> 2014-10-21 17:06:35,476 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-44:ctx-7d84e64c job-547) Executing AsyncJobVO {id:547,
> userId: 2, accountId: 2, instanceType: SystemVm, instanceId: 2, cmd:
> org.apache.cloudstack.api.command.admin.systemvm.RebootSystemVmCmd, cmdInfo:
> {"response":"json","id":"0d3261c0-18af-4f4f-8052-78398ea3d319","ctxDetails":"{\"com.cloud.vm.VirtualMachine\":\"0d3261c0-18af-4f4f-8052-78398ea3d319\"}","cmdEventType":"PROXY.REBOOT","ctxUserId":"2","httpmethod":"GET","uuid":"0d3261c0-18af-4f4f-8052-78398ea3d319","ctxAccountId":"2","ctxStartEventId":"1702","apiKey":"8zS-PDiww66KLa3apG55n-SpVbHRv7o4m1yTKiJTghk3NmbsfVAcE_Y1ymDuc-7huYpOW1Q221BgVCCQXcy_Zg","signature":"TXvdc/RdiaOYDVvVKjoo/YaoMho\u003d"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 59825535280071, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-10-21 17:06:35,477 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-21:ctx-f76226cf ctx-64e39462 ctx-47749a02) ===END===
> 10.220.135.30 -- GET
> response=json&apiKey=8zS-PDiww66KLa3apG55n-SpVbHRv7o4m1yTKiJTghk3NmbsfVAcE_Y1ymDuc-
[jira] [Commented] (CLOUDSTACK-7761) [Automation] Rebooting System VMs - VMs are getting stopped and started instead of reboot
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14179396#comment-14179396
]
ASF subversion and git services commented on CLOUDSTACK-7761:
-
Commit 70112bd1457aafb64fc03f75e20a5330082a0468 in cloudstack's branch
refs/heads/master from [~anthonyxu]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=70112bd ]
CLOUDSTACK-7761:
Revert "when system VM ping times out, stop system VM"
This reverts commit ee23be1942001ab732cfb3ad50fa24163cb88a48.
> [Automation] Rebooting System VMs - VMs are getting stopped and started
> instead of reboot
> -
>
> Key: CLOUDSTACK-7761
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7761
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Anthony Xu
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.zip
>
>
> Rebooting System VM using cases are failing on the automation as shown below:
> *Error Message*
> Check Private IP after reboot with that of before reboot
> *Stacktrace*
> File "/usr/lib/python2.7/unittest/case.py", line 332, in run
> testMethod()
> File "/root/cloudstack/test/integration/smoke/test_ssvm.py", line 725, in
> test_07_reboot_ssvm
> "Check Private IP after reboot with that of before reboot"
> File "/usr/lib/python2.7/unittest/case.py", line 516, in assertEqual
> assertion_func(first, second, msg=msg)
> File "/usr/lib/python2.7/unittest/case.py", line 927, in
> assertMultiLineEqual
> self.fail(self._formatMessage(msg, standardMsg))
> File "/usr/lib/python2.7/unittest/case.py", line 413, in fail
> raise self.failureException(msg)
> 'Check Private IP after reboot with that of before reboot\n
> On further analysis, we found that the reboot command is actually calling
> Stopcommand in the later part of the job. This results in the change in
> private ip address.
> {noformat}
> 2014-10-21 17:06:35,451 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-21:ctx-f76226cf) ===START=== 10.220.135.30 -- GET
> response=json&apiKey=8zS-PDiww66KLa3apG55n-SpVbHRv7o4m1yTKiJTghk3NmbsfVAcE_Y1ymDuc-7huYpOW1Q221BgVCCQXcy_Zg&command=rebootSystemVm&id=0d3261c0-18af-4f4f-8052-78398ea3d319&signature=TXvdc%2FRdiaOYDVvVKjoo%2FYaoMho%3D
> 2014-10-21 17:06:35,476 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-21:ctx-f76226cf ctx-64e39462 ctx-47749a02) submit async
> job-547, details: AsyncJobVO {id:547, userId: 2, accountId: 2, instanceType:
> SystemVm, instanceId: 2, cmd:
> org.apache.cloudstack.api.command.admin.systemvm.RebootSystemVmCmd, cmdInfo:
> {"response":"json","id":"0d3261c0-18af-4f4f-8052-78398ea3d319","ctxDetails":"{\"com.cloud.vm.VirtualMachine\":\"0d3261c0-18af-4f4f-8052-78398ea3d319\"}","cmdEventType":"PROXY.REBOOT","ctxUserId":"2","httpmethod":"GET","uuid":"0d3261c0-18af-4f4f-8052-78398ea3d319","ctxAccountId":"2","ctxStartEventId":"1702","apiKey":"8zS-PDiww66KLa3apG55n-SpVbHRv7o4m1yTKiJTghk3NmbsfVAcE_Y1ymDuc-7huYpOW1Q221BgVCCQXcy_Zg","signature":"TXvdc/RdiaOYDVvVKjoo/YaoMho\u003d"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 59825535280071, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-10-21 17:06:35,476 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-44:ctx-7d84e64c job-547) Add job-547 into job monitoring
> 2014-10-21 17:06:35,476 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-44:ctx-7d84e64c job-547) Executing AsyncJobVO {id:547,
> userId: 2, accountId: 2, instanceType: SystemVm, instanceId: 2, cmd:
> org.apache.cloudstack.api.command.admin.systemvm.RebootSystemVmCmd, cmdInfo:
> {"response":"json","id":"0d3261c0-18af-4f4f-8052-78398ea3d319","ctxDetails":"{\"com.cloud.vm.VirtualMachine\":\"0d3261c0-18af-4f4f-8052-78398ea3d319\"}","cmdEventType":"PROXY.REBOOT","ctxUserId":"2","httpmethod":"GET","uuid":"0d3261c0-18af-4f4f-8052-78398ea3d319","ctxAccountId":"2","ctxStartEventId":"1702","apiKey":"8zS-PDiww66KLa3apG55n-SpVbHRv7o4m1yTKiJTghk3NmbsfVAcE_Y1ymDuc-7huYpOW1Q221BgVCCQXcy_Zg","signature":"TXvdc/RdiaOYDVvVKjoo/YaoMho\u003d"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 59825535280071, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-10-21 17:06:35,477 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-21:ctx-f76226cf ctx-64e39462 ctx-47749a02) ===END===
> 10.220.135.30 -- GET
> response=json&apiKey=8zS-PDiww66KLa3apG55n-SpVbHRv7o4m1yTKiJTghk3NmbsfVAcE_Y1ymD
[jira] [Commented] (CLOUDSTACK-7762) [Automation] - Fix test failure for test_02_revert_vm_snapshots in smoke/test_vm_snapshots.py
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14179267#comment-14179267
]
ASF subversion and git services commented on CLOUDSTACK-7762:
-
Commit f510ef995baaa9addefc22ff0330cd51dee1dd95 in cloudstack's branch
refs/heads/master from [~sangeethah]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f510ef9 ]
CLOUDSTACK-7762 -[Automation] - Fix test failure for
test_02_revert_vm_snapshots in smoke/test_vm_snapshots.py
> [Automation] - Fix test failure for test_02_revert_vm_snapshots in
> smoke/test_vm_snapshots.py
> ---
>
> Key: CLOUDSTACK-7762
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7762
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Test
>Affects Versions: 4.5.0
> Environment: Build from master
>Reporter: Sangeetha Hariharan
> Fix For: 4.5.0
>
>
> test_02_revert_vm_snapshots in smoke/test_vm_snapshots.py fails in BVT runs
> with the following exception:
> 2014-10-20 16:41:00,497 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-120:ctx-83b738d9 job-459) Add job-459 into job monitoring
> 2014-10-20 16:41:00,497 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-120:ctx-83b738d9 job-459) Executing AsyncJobVO {id:459,
> userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.admin.vmsnapshot.RevertToVMSnapshotCmdByAdmin,
> cmdInfo:
> {"response":"json","ctxDetails":"{\"com.cloud.vm.snapshot.VMSnapshot\":\"12280973-a1e4-43e3-80b3-3afacd607909\"}","cmdEventType":"VMSNAPSHOT.REVERTTO","ctxUserId":"2","httpmethod":"GET","vmsnapshotid":"12280973-a1e4-43e3-80b3-3afacd607909","ctxAccountId":"2","ctxStartEventId":"1406","apiKey":"aJwkScf5ziRwz8gKQ9HB0Ce6hSsTJTUtmUDUQ_U2teV3vVmuLQRLad8xqAgr7CrFOEQbywdVpKSt2yC_ORXLYg","signature":"cYBxgg8eBfktovmCaHYox2xoTE8\u003d"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 11489258594360, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-10-20 16:41:00,529 ERROR [c.c.a.ApiAsyncJobDispatcher]
> (API-Job-Executor-120:ctx-83b738d9 job-459) Unexpected exception while
> executing
> org.apache.cloudstack.api.command.admin.vmsnapshot.RevertToVMSnapshotCmdByAdmin
> com.cloud.exception.InvalidParameterValueException: VM Snapshot revert not
> allowed. This will result in VM state change. You can revert running VM to
> disk and memory type snapshot and stopped VM to disk type snapshot
> at
> com.cloud.vm.snapshot.VMSnapshotManagerImpl.revertToSnapshot(VMSnapshotManagerImpl.java:581)
> 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)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7762) [Automation] - Fix test failure for test_02_revert_vm_snapshots in smoke/test_vm_snapshots.py
Sangeetha Hariharan created CLOUDSTACK-7762:
---
Summary: [Automation] - Fix test failure for
test_02_revert_vm_snapshots in smoke/test_vm_snapshots.py
Key: CLOUDSTACK-7762
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7762
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Test
Affects Versions: 4.5.0
Environment: Build from master
Reporter: Sangeetha Hariharan
Fix For: 4.5.0
test_02_revert_vm_snapshots in smoke/test_vm_snapshots.py fails in BVT runs
with the following exception:
2014-10-20 16:41:00,497 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-120:ctx-83b738d9 job-459) Add job-459 into job monitoring
2014-10-20 16:41:00,497 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-120:ctx-83b738d9 job-459) Executing AsyncJobVO {id:459,
userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd:
org.apache.cloudstack.api.command.admin.vmsnapshot.RevertToVMSnapshotCmdByAdmin,
cmdInfo:
{"response":"json","ctxDetails":"{\"com.cloud.vm.snapshot.VMSnapshot\":\"12280973-a1e4-43e3-80b3-3afacd607909\"}","cmdEventType":"VMSNAPSHOT.REVERTTO","ctxUserId":"2","httpmethod":"GET","vmsnapshotid":"12280973-a1e4-43e3-80b3-3afacd607909","ctxAccountId":"2","ctxStartEventId":"1406","apiKey":"aJwkScf5ziRwz8gKQ9HB0Ce6hSsTJTUtmUDUQ_U2teV3vVmuLQRLad8xqAgr7CrFOEQbywdVpKSt2yC_ORXLYg","signature":"cYBxgg8eBfktovmCaHYox2xoTE8\u003d"},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 11489258594360, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-10-20 16:41:00,529 ERROR [c.c.a.ApiAsyncJobDispatcher]
(API-Job-Executor-120:ctx-83b738d9 job-459) Unexpected exception while
executing
org.apache.cloudstack.api.command.admin.vmsnapshot.RevertToVMSnapshotCmdByAdmin
com.cloud.exception.InvalidParameterValueException: VM Snapshot revert not
allowed. This will result in VM state change. You can revert running VM to disk
and memory type snapshot and stopped VM to disk type snapshot
at
com.cloud.vm.snapshot.VMSnapshotManagerImpl.revertToSnapshot(VMSnapshotManagerImpl.java:581)
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)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (CLOUDSTACK-4201) listServiceOfferings API needs to be able to take virtualmachineid of SystemVM and return service offerings available for the vm to change service offe
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta updated CLOUDSTACK-4201: Comment: was deleted (was: This is a good to have but not a critical. Downgrading the priority to Major and moving it to 4.6 ) > listServiceOfferings API needs to be able to take virtualmachineid of > SystemVM and return service offerings available for the vm to change service > offering > --- > > Key: CLOUDSTACK-4201 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4201 > 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: listServiceOfferings API needs to be able to take > virtualmachineid of SystemVM and returns service offerings available for the > vm to change service offering. If vm is running only scale up service > offering should be presented. If vm is stopped all service offering should be > shown. >Reporter: Nitin Mehta >Assignee: Nitin Mehta > Fix For: 4.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7761) [Automation] Rebooting System VMs - VMs are getting stopped and started instead of reboot
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chandan Purushothama updated CLOUDSTACK-7761:
-
Attachment: management-server.zip
> [Automation] Rebooting System VMs - VMs are getting stopped and started
> instead of reboot
> -
>
> Key: CLOUDSTACK-7761
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7761
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Anthony Xu
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.zip
>
>
> Rebooting System VM using cases are failing on the automation as shown below:
> *Error Message*
> Check Private IP after reboot with that of before reboot
> *Stacktrace*
> File "/usr/lib/python2.7/unittest/case.py", line 332, in run
> testMethod()
> File "/root/cloudstack/test/integration/smoke/test_ssvm.py", line 725, in
> test_07_reboot_ssvm
> "Check Private IP after reboot with that of before reboot"
> File "/usr/lib/python2.7/unittest/case.py", line 516, in assertEqual
> assertion_func(first, second, msg=msg)
> File "/usr/lib/python2.7/unittest/case.py", line 927, in
> assertMultiLineEqual
> self.fail(self._formatMessage(msg, standardMsg))
> File "/usr/lib/python2.7/unittest/case.py", line 413, in fail
> raise self.failureException(msg)
> 'Check Private IP after reboot with that of before reboot\n
> On further analysis, we found that the reboot command is actually calling
> Stopcommand in the later part of the job. This results in the change in
> private ip address.
> {noformat}
> 2014-10-21 17:06:35,451 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-21:ctx-f76226cf) ===START=== 10.220.135.30 -- GET
> response=json&apiKey=8zS-PDiww66KLa3apG55n-SpVbHRv7o4m1yTKiJTghk3NmbsfVAcE_Y1ymDuc-7huYpOW1Q221BgVCCQXcy_Zg&command=rebootSystemVm&id=0d3261c0-18af-4f4f-8052-78398ea3d319&signature=TXvdc%2FRdiaOYDVvVKjoo%2FYaoMho%3D
> 2014-10-21 17:06:35,476 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-21:ctx-f76226cf ctx-64e39462 ctx-47749a02) submit async
> job-547, details: AsyncJobVO {id:547, userId: 2, accountId: 2, instanceType:
> SystemVm, instanceId: 2, cmd:
> org.apache.cloudstack.api.command.admin.systemvm.RebootSystemVmCmd, cmdInfo:
> {"response":"json","id":"0d3261c0-18af-4f4f-8052-78398ea3d319","ctxDetails":"{\"com.cloud.vm.VirtualMachine\":\"0d3261c0-18af-4f4f-8052-78398ea3d319\"}","cmdEventType":"PROXY.REBOOT","ctxUserId":"2","httpmethod":"GET","uuid":"0d3261c0-18af-4f4f-8052-78398ea3d319","ctxAccountId":"2","ctxStartEventId":"1702","apiKey":"8zS-PDiww66KLa3apG55n-SpVbHRv7o4m1yTKiJTghk3NmbsfVAcE_Y1ymDuc-7huYpOW1Q221BgVCCQXcy_Zg","signature":"TXvdc/RdiaOYDVvVKjoo/YaoMho\u003d"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 59825535280071, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-10-21 17:06:35,476 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-44:ctx-7d84e64c job-547) Add job-547 into job monitoring
> 2014-10-21 17:06:35,476 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-44:ctx-7d84e64c job-547) Executing AsyncJobVO {id:547,
> userId: 2, accountId: 2, instanceType: SystemVm, instanceId: 2, cmd:
> org.apache.cloudstack.api.command.admin.systemvm.RebootSystemVmCmd, cmdInfo:
> {"response":"json","id":"0d3261c0-18af-4f4f-8052-78398ea3d319","ctxDetails":"{\"com.cloud.vm.VirtualMachine\":\"0d3261c0-18af-4f4f-8052-78398ea3d319\"}","cmdEventType":"PROXY.REBOOT","ctxUserId":"2","httpmethod":"GET","uuid":"0d3261c0-18af-4f4f-8052-78398ea3d319","ctxAccountId":"2","ctxStartEventId":"1702","apiKey":"8zS-PDiww66KLa3apG55n-SpVbHRv7o4m1yTKiJTghk3NmbsfVAcE_Y1ymDuc-7huYpOW1Q221BgVCCQXcy_Zg","signature":"TXvdc/RdiaOYDVvVKjoo/YaoMho\u003d"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 59825535280071, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-10-21 17:06:35,477 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-21:ctx-f76226cf ctx-64e39462 ctx-47749a02) ===END===
> 10.220.135.30 -- GET
> response=json&apiKey=8zS-PDiww66KLa3apG55n-SpVbHRv7o4m1yTKiJTghk3NmbsfVAcE_Y1ymDuc-7huYpOW1Q221BgVCCQXcy_Zg&command=rebootSystemVm&id=0d3261c0-18af-4f4f-8052-78398ea3d319&signature=TXvdc%2FRdiaOYDVvVKjoo%2FYaoMho%3D
> 2014-10-21 17:06:35,483 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-18:ctx-a631c521) ===START=== 10.220.135.30 -- GET
> jobid=89c344f2-54de-40b7-b1ea-2a9f5b573a4e&apiKey=8zS-PDiww66KLa3apG55n-SpVbHRv7o4m1yTKiJTghk3Nmbsf
[jira] [Created] (CLOUDSTACK-7761) [Automation] Rebooting System VMs - VMs are getting stopped and started instead of reboot
Chandan Purushothama created CLOUDSTACK-7761:
Summary: [Automation] Rebooting System VMs - VMs are getting
stopped and started instead of reboot
Key: CLOUDSTACK-7761
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7761
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Anthony Xu
Priority: Critical
Fix For: 4.5.0
Rebooting System VM using cases are failing on the automation as shown below:
*Error Message*
Check Private IP after reboot with that of before reboot
*Stacktrace*
File "/usr/lib/python2.7/unittest/case.py", line 332, in run
testMethod()
File "/root/cloudstack/test/integration/smoke/test_ssvm.py", line 725, in
test_07_reboot_ssvm
"Check Private IP after reboot with that of before reboot"
File "/usr/lib/python2.7/unittest/case.py", line 516, in assertEqual
assertion_func(first, second, msg=msg)
File "/usr/lib/python2.7/unittest/case.py", line 927, in assertMultiLineEqual
self.fail(self._formatMessage(msg, standardMsg))
File "/usr/lib/python2.7/unittest/case.py", line 413, in fail
raise self.failureException(msg)
'Check Private IP after reboot with that of before reboot\n
On further analysis, we found that the reboot command is actually calling
Stopcommand in the later part of the job. This results in the change in private
ip address.
{noformat}
2014-10-21 17:06:35,451 DEBUG [c.c.a.ApiServlet]
(catalina-exec-21:ctx-f76226cf) ===START=== 10.220.135.30 -- GET
response=json&apiKey=8zS-PDiww66KLa3apG55n-SpVbHRv7o4m1yTKiJTghk3NmbsfVAcE_Y1ymDuc-7huYpOW1Q221BgVCCQXcy_Zg&command=rebootSystemVm&id=0d3261c0-18af-4f4f-8052-78398ea3d319&signature=TXvdc%2FRdiaOYDVvVKjoo%2FYaoMho%3D
2014-10-21 17:06:35,476 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-21:ctx-f76226cf ctx-64e39462 ctx-47749a02) submit async job-547,
details: AsyncJobVO {id:547, userId: 2, accountId: 2, instanceType: SystemVm,
instanceId: 2, cmd:
org.apache.cloudstack.api.command.admin.systemvm.RebootSystemVmCmd, cmdInfo:
{"response":"json","id":"0d3261c0-18af-4f4f-8052-78398ea3d319","ctxDetails":"{\"com.cloud.vm.VirtualMachine\":\"0d3261c0-18af-4f4f-8052-78398ea3d319\"}","cmdEventType":"PROXY.REBOOT","ctxUserId":"2","httpmethod":"GET","uuid":"0d3261c0-18af-4f4f-8052-78398ea3d319","ctxAccountId":"2","ctxStartEventId":"1702","apiKey":"8zS-PDiww66KLa3apG55n-SpVbHRv7o4m1yTKiJTghk3NmbsfVAcE_Y1ymDuc-7huYpOW1Q221BgVCCQXcy_Zg","signature":"TXvdc/RdiaOYDVvVKjoo/YaoMho\u003d"},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 59825535280071, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-10-21 17:06:35,476 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-44:ctx-7d84e64c job-547) Add job-547 into job monitoring
2014-10-21 17:06:35,476 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-44:ctx-7d84e64c job-547) Executing AsyncJobVO {id:547,
userId: 2, accountId: 2, instanceType: SystemVm, instanceId: 2, cmd:
org.apache.cloudstack.api.command.admin.systemvm.RebootSystemVmCmd, cmdInfo:
{"response":"json","id":"0d3261c0-18af-4f4f-8052-78398ea3d319","ctxDetails":"{\"com.cloud.vm.VirtualMachine\":\"0d3261c0-18af-4f4f-8052-78398ea3d319\"}","cmdEventType":"PROXY.REBOOT","ctxUserId":"2","httpmethod":"GET","uuid":"0d3261c0-18af-4f4f-8052-78398ea3d319","ctxAccountId":"2","ctxStartEventId":"1702","apiKey":"8zS-PDiww66KLa3apG55n-SpVbHRv7o4m1yTKiJTghk3NmbsfVAcE_Y1ymDuc-7huYpOW1Q221BgVCCQXcy_Zg","signature":"TXvdc/RdiaOYDVvVKjoo/YaoMho\u003d"},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 59825535280071, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-10-21 17:06:35,477 DEBUG [c.c.a.ApiServlet] (catalina-exec-21:ctx-f76226cf
ctx-64e39462 ctx-47749a02) ===END=== 10.220.135.30 -- GET
response=json&apiKey=8zS-PDiww66KLa3apG55n-SpVbHRv7o4m1yTKiJTghk3NmbsfVAcE_Y1ymDuc-7huYpOW1Q221BgVCCQXcy_Zg&command=rebootSystemVm&id=0d3261c0-18af-4f4f-8052-78398ea3d319&signature=TXvdc%2FRdiaOYDVvVKjoo%2FYaoMho%3D
2014-10-21 17:06:35,483 DEBUG [c.c.a.ApiServlet]
(catalina-exec-18:ctx-a631c521) ===START=== 10.220.135.30 -- GET
jobid=89c344f2-54de-40b7-b1ea-2a9f5b573a4e&apiKey=8zS-PDiww66KLa3apG55n-SpVbHRv7o4m1yTKiJTghk3NmbsfVAcE_Y1ymDuc-7huYpOW1Q221BgVCCQXcy_Zg&command=queryAsyncJobResult&response=json&signature=9GRPDgWSdAC0UuqA0wooTnJ%2FMZc%3D
2014-10-21 17:06:35,504 DEBUG [c.c.a.t.Request]
(API-Job-Executor-44:ctx-7d84e64c job-547 ctx-dfce25f5) Seq
2-7242632625741890164: Sending { Cmd , MgmtId: 59825535280071, via:
2(cl09-A-08), Ver: v1, Flags: 100111,
[{"com.cloud.agent.api.RebootCommand":{"vmName":"v-2-VM","wai
[jira] [Commented] (CLOUDSTACK-7754) 'vm_template.source_template_id' of Template created from Snapshot was NULL
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14178793#comment-14178793 ] Nitin Mehta commented on CLOUDSTACK-7754: - Issue - Templates source_template_id is null when it is created from Snapshot with its corresponding volume removed. Fix - When looking for the source template search for the volume including removed. Also clean up the code since it had boilerplate code and was updating db after creating the snapshot record instead of doing it in one go. QA notes - Repro steps - Steps: i) Create instance A ii) Take snapshot A from instance A iii) Create template 1 from snapshot A iv) Delete instance A and make sure the vm and its volume are expunged. v) Create template 2 from snapshot A Test result: The issue occurred to template 2 which was created after instance A was deleted. After the fix you should see the source_Template_id set in the vm_template table for this use case. For sanity reasons make sure source_Template_id is never null > 'vm_template.source_template_id' of Template created from Snapshot was NULL > > > Key: CLOUDSTACK-7754 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7754 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.5.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Critical > Fix For: 4.5.0 > > > Here is the procedure to reproduce the issue. This is consistent on my > environment. > Steps: > i) Create instance A > ii) Take snapshot A from instance A > iii) Create template 1 from snapshot A > iv) Delete instance A > v) Create template 2 from snapshot A > Test result: > The issue occurred to template 2 which was created after instance A was > deleted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7754) 'vm_template.source_template_id' of Template created from Snapshot was NULL
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14178632#comment-14178632 ] ASF subversion and git services commented on CLOUDSTACK-7754: - Commit e1a993d37b1bf9be24edd46f6d3566826692f853 in cloudstack's branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e1a993d ] CLOUDSTACK-7754: Templates source_template_id is null when it is created from Snapshot with its corresponding volume removed. Fix it by searching for volumes including removed. Also bring the logic of setting source template id to create() method than execute which was wrongly put in. > 'vm_template.source_template_id' of Template created from Snapshot was NULL > > > Key: CLOUDSTACK-7754 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7754 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.5.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Critical > Fix For: 4.5.0 > > > Here is the procedure to reproduce the issue. This is consistent on my > environment. > Steps: > i) Create instance A > ii) Take snapshot A from instance A > iii) Create template 1 from snapshot A > iv) Delete instance A > v) Create template 2 from snapshot A > Test result: > The issue occurred to template 2 which was created after instance A was > deleted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7660) Enhance system vm template to support baremetal
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14178505#comment-14178505 ] Nux commented on CLOUDSTACK-7660: - Curious, what would be the primary use case of this? Is SSVM the issue or it's the VR? What problems have people hit? > Enhance system vm template to support baremetal > --- > > Key: CLOUDSTACK-7660 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7660 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.5.0 >Reporter: frank zhang >Assignee: Harikrishna Patnala > Fix For: 4.5.0 > > > Two things need doing: > 1. pip install flask when building template > 2. merge 7 disk partitions to single one -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6378) SSL: Fail to find the generated keystore.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-6378: -- Assignee: (was: Kishan Kavala) > SSL: Fail to find the generated keystore. > - > > Key: CLOUDSTACK-6378 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6378 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.1, 4.3.0, 4.4.0 > Environment: Confirmed this is an issue on centos 6.5 and ubuntu > 12.04 on both versions of Cloudstack 4.2.1 and 4.3.0 >Reporter: Michael Phillips >Priority: Minor > > The logs on versions 4.2.1 and 4.3.0 get filled with the following error: > WARN [c.c.u.n.Link] (AgentManager-Selector:null) SSL: Fail to find the > generated keystore. Loading fail-safe one to continue. > In 4.2.1, the fix was to rename cloudmanagementserver.keystore, to > cloud.keystore then restart cloudstack. > In 4.3.0, the system by default does not create the file named > cloudmanagementserver.keystore. You now have to create the keystore file by > running "sudo keytool -genkey -keystore", then name the file cloud.keystore. > This error is reproducible, and confirmed by other users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6093) [Automation] test_vpc_network_lbrules.py fail with error as cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext : u'Failed to
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kishan Kavala updated CLOUDSTACK-6093:
--
Assignee: (was: Kishan Kavala)
> [Automation] test_vpc_network_lbrules.py fail with error as
> cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode :
> 530, errortext : u'Failed to create VPC'}
> --
>
> Key: CLOUDSTACK-6093
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6093
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: marvin
>Affects Versions: 4.2.0
> Environment: CloudPlatform 4.2.0 on Red Hat Enterprise Linux Server
> release 6.4 (Santiago)
>Reporter: Dhananjay D Pathak
> Fix For: 4.5.0
>
> Attachments: failed_plus_exceptions.txt, results.txt, runinfo.txt
>
>
> Marvin Test cloudstack/test/integration/component/test_vpc_network_lbrules.py
> fails with error as described bellow (log files are attached):
> Test case no 210 and 227: List Load Balancing Rules belonging to a VPC ... ok
> Test Create LB rules for 1 network which is part of a two/multiple virtual
> networks of a ... ERROR
> Test case no 222 : Create LB rules for a two/multiple virtual networks of a
> ... ERROR
> Test case no 222 : Create LB rules for a two/multiple virtual networks of a
> ... ERROR
> Test case no 214 : Delete few(not all) LB rules for a single virtual network
> of a ... ERROR
> Test Delete few(not all) LB rules for a single virtual network of ... ERROR
> Test Delete all LB rules for a single virtual network of a ... ERROR
> Test Delete all LB rules for a single virtual network of a ... ERROR
> Test User should not be allowed to create a LB rule for a VM that belongs to
> a different VPC. ... ERROR
> Test User should not be allowed to create a LB rule for a VM that does not
> belong to any VPC. ... ERROR
> Test case no 217 and 236: User should not be allowed to create a LB rule for
> a ... ok
> Test User should not be allowed to create a LB rule on an Ipaddress that
> Source Nat enabled. ... ok
> Test User should not be allowed to create a LB rule on an Ipaddress that
> already has a PF rule. ... FAIL
> Test User should not be allowed to create a LB rule on an Ipaddress that
> already has a Static Nat rule. ... ok
> Test release Ip address that has a LB rule assigned to it. ... ERROR
> ==
> ERROR: Test Create LB rules for 1 network which is part of a two/multiple
> virtual networks of a
> --
> Traceback (most recent call last):
> File
> "/DataDisk/temp/cloudstack/test/integration/component/test_vpc_network_lbrules.py",
> line 246, in setUp
> domainid=self.account.domainid
> File
> "/usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py", line
> 3114, in create
> return VPC(apiclient.createVPC(cmd).__dict__)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 1988, in createVPC
> response = self.connection.marvinRequest(command, response_type=response,
> method=method)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line
> 280, in marvinRequest
> response = self.poll(asyncJobId, response_type)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line
> 86, in poll
> "asyncquery", asyncResonse.jobresult)
> cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode :
> 530, errortext : u'Failed to create VPC'}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-6122) LXC 2.0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala resolved CLOUDSTACK-6122. --- Resolution: Fixed > LXC 2.0 > --- > > Key: CLOUDSTACK-6122 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6122 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Kishan Kavala > > LXC support was added to CloudStack in 4.2 release. The objective of this > feature is to enhance LXC support by adding more features. > Features: > - Support data disk while creating container > - Support attach/detach data disk > - Support Ceph storage > - Migrate volume of a stopped container > - Create template from ROOT volume > - Attach/Detach an ISO to a container > - Launch container from ISO > - Console Access > I'll create sub-tickets for each of the above items -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7008) LXC: Native snapshot support
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-7008: -- Assignee: (was: Kishan Kavala) > LXC: Native snapshot support > > > Key: CLOUDSTACK-7008 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7008 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Affects Versions: 4.5.0 >Reporter: Abhinandan Prateek > Fix For: Future > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-2853) Cloudstack copies xenserver scripts while adding host even the server is KVM host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-2853: -- Assignee: (was: Kishan Kavala) > Cloudstack copies xenserver scripts while adding host even the server is KVM > host > - > > Key: CLOUDSTACK-2853 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2853 > 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: master build >Reporter: Sanjeev N > Fix For: 4.4.0 > > > Cloudstack copies xenserver scripts while adding host even the server is KVM > host > 1.Create a zone with cluster kvm and add at least one kvm host. > 2.After the host addition is successful login to the hypervisor and check > the scripts at following location: > /usr/share/cloudstack-common/scripts/vm/hypervisor/ > I could see all the xenserver related scripts at > /usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-797) Remove or fix unknown classes in cloud-api
[ https://issues.apache.org/jira/browse/CLOUDSTACK-797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-797: - Assignee: (was: Kishan Kavala) > Remove or fix unknown classes in cloud-api > -- > > Key: CLOUDSTACK-797 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-797 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Rohit Yadav > Fix For: Future > > > The following cmd classes exists under cloud-api, there are not being used > nor there are mentioned in apidocs. The issue is to verify them and if they > are not needed remove them. > api/src/com/cloud/api/commands//CreatePrivateNetworkCmd.java > api/src/com/cloud/api/commands//DestroyConsoleProxyCmd.java > api/src/com/cloud/api/commands//ListRecurringSnapshotScheduleCmd.java -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7004) [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-7004: -- Assignee: (was: Kishan Kavala) > [Automation] [KVM] Deploying a VM with rootdisksize less than the size of > template does not fail > > > Key: CLOUDSTACK-7004 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7004 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Automation, KVM >Affects Versions: 4.4.0 > Environment: KVM >Reporter: Gaurav Aradhye > Labels: api, automation, kvm > Fix For: 4.4.0 > > > Deploy a VM with parameter rootdisksize less than the template size. > API should throw error for this but it succeeds. > Although the root disk size of deployed VM is equal to template size in this > case, but this operation should throw error and VM should not be deployed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5324) error message not proper when start VM fails because router reuires upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-5324: -- Assignee: (was: Kishan Kavala) > error message not proper when start VM fails because router reuires upgrade > > > Key: CLOUDSTACK-5324 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5324 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.3.0 >Reporter: shweta agarwal > Fix For: 4.4.0 > > > Repro steps: > Create a VM on 3.07 setup > Upgrade to 4.3.0 but dont upgrade routers > Stop user VM > Start user VM > Bug: > Error message shows "Unable to start a VM due to concurrent operation > Expectation : > Error message should show " router requires upgrade " > MS log snippet : > 2013-12-02 12:28:09,029 ERROR [c.c.v.VirtualMachineManagerImpl] > (Job-Executor-9:ctx-1bf286cd ctx-4cabd091) Failed to start instance > VM[User|f01ae0d5-23b3-44c4-9e8d-9df9245874be] > com.cloud.utils.exception.CloudRuntimeException: Router requires upgrade. > Unable to send command to router:4 > at > com.cloud.network.router.VirtualNetworkApplianceManagerImpl.sendCommandsToRouter(VirtualNetworkApplianceManagerImpl.java:3437) > at > com.cloud.network.router.VirtualNetworkApplianceManagerImpl$7.execute(VirtualNetworkApplianceManagerImpl.java:2873) > at > com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:3722) > at > com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyDhcpEntry(VirtualNetworkApplianceManagerImpl.java:2865) > 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:622) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy239.applyDhcpEntry(Unknown Source) > at > com.cloud.network.element.VirtualRouterElement.addDhcpEntry(VirtualRouterElement.java:914) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareElement(NetworkOrchestrator.java:1171) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNic(NetworkOrchestrator.java:1293) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1229) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:899) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:706) > at > com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:552) > at > org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:236) > at > org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) > at > com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3465) > at > com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:1921) > 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:622) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > com.cloud.
[jira] [Updated] (CLOUDSTACK-4990) Console Proxy cannot proxy LXC console
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-4990: -- Assignee: (was: Kishan Kavala) > Console Proxy cannot proxy LXC console > -- > > Key: CLOUDSTACK-4990 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4990 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Francois Gaudreault > > LXC resource agent issue. > When I try to check the console from CS: > 2013-10-29 10:07:42,079 WARN [cloud.agent.Agent] > (agentRequest-Handler-4:null) Caught: > java.lang.NullPointerException > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:2711) > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1216) > at com.cloud.agent.Agent.processRequest(Agent.java:525) > at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852) > at com.cloud.utils.nio.Task.run(Task.java:83) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > This is the error on the CS side: > 2013-10-29 10:12:58,215 DEBUG [agent.manager.AgentManagerImpl] > (catalina-exec-16:null) Details from executing class > com.cloud.agent.api.GetVncPortCommand: java.lang.NullPointerException > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:2711) > at > com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1216) > at com.cloud.agent.Agent.processRequest(Agent.java:525) > at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852) > at com.cloud.utils.nio.Task.run(Task.java:83) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > 2013-10-29 10:12:58,215 ERROR [cloud.servlet.ConsoleProxyServlet] > (catalina-exec-16:null) Unexepected exception in ConsoleProxyServlet > java.lang.ClassCastException: com.cloud.agent.api.Answer cannot be cast to > com.cloud.agent.api.GetVncPortAnswer > at > com.cloud.server.ManagementServerImpl.getVncPort(ManagementServerImpl.java:2193) > at > com.cloud.servlet.ConsoleProxyServlet.composeConsoleAccessUrl(ConsoleProxyServlet.java:381) > at > com.cloud.servlet.ConsoleProxyServlet.handleAccessRequest(ConsoleProxyServlet.java:269) > at > com.cloud.servlet.ConsoleProxyServlet.doGet(ConsoleProxyServlet.java:171) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) > at > org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889) > at > org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721) > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2268) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:679) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-1412) listUsageRecords will loop data if requested page is beyond what is available
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-1412: -- Assignee: (was: Kishan Kavala) > listUsageRecords will loop data if requested page is beyond what is available > - > > Key: CLOUDSTACK-1412 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1412 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.0.0 > Environment: CentOS 6.3 x86_64 >Reporter: David Matteson > Labels: API > > When calling listUsageRecords requesting a page beyond what is available will > cause the returned data to loop back to the beginning. This appears to go on > indefinitely. > For example, if there are 3 pages of results matching the date range and > given criteria, and I request page 4, I will get page 1's data again. Page 5 > returns page 2, and so on ad infinitum. > The preferred behavior (at least from my perspective) would be requesting a > page beyond what is available returns null. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7501) System VM fails to move from one cluster to another cluster when hypervisor type differs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-7501: -- Assignee: (was: Kishan Kavala) > System VM fails to move from one cluster to another cluster when hypervisor > type differs > > > Key: CLOUDSTACK-7501 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7501 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Priority: Critical > Fix For: 4.5.0 > > Attachments: Ms.tar.gz > > > Repro steps: > 1. Create a LXC advance zone setup with one LXC cluster > 2. When system vms are up .add one more KVM cluster > 3. Put LXC host to maintenance > Bug: > System VM is not coming up on KVM cluster > Expected result: > System VMs should come up on KVM cluster > Ms log shows : > Cluster: 2 has HyperVisorType that does not match the VM, skipping this > cluster > which should not be the case in case of SSVM and CPVM > attaching MS logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7660) Enhance system vm template to support baremetal
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14178481#comment-14178481 ] ASF subversion and git services commented on CLOUDSTACK-7660: - Commit 14c820ae02dceb94b6c61deb79694be77253b52a in cloudstack's branch refs/heads/baremetal-systemvm from [~harikrishna.patnala] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=14c820a ] CLOUDSTACK-7660: Enhance system vm template to support baremetal Installed Package flask and merged the disk partition > Enhance system vm template to support baremetal > --- > > Key: CLOUDSTACK-7660 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7660 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.5.0 >Reporter: frank zhang >Assignee: Harikrishna Patnala > Fix For: 4.5.0 > > > Two things need doing: > 1. pip install flask when building template > 2. merge 7 disk partitions to single one -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7749) AsyncJob GC thread cannot purge queue items that have been blocking for too long if exception is thrown in expunging some unfinished or completed old jobs, this wi
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14178478#comment-14178478
]
ASF subversion and git services commented on CLOUDSTACK-7749:
-
Commit 248e4fbdacb1372da94cbcf49ca23a14c8c9b514 in cloudstack's branch
refs/heads/baremetal-systemvm from [~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=248e4fb ]
CLOUDSTACK-7749: AsyncJob GC thread cannot purge queue items that have been
blocking for too long if exception is thrown in expunging some unfinished or
completed old jobs, this will make some future jobs stuck.
> AsyncJob GC thread cannot purge queue items that have been blocking for too
> long if exception is thrown in expunging some unfinished or completed old
> jobs, this will make some future jobs stuck.
> --
>
> Key: CLOUDSTACK-7749
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7749
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.3.0
>Reporter: Min Chen
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.5.0
>
>
> AsyncJobManager has a GC thread to clean up some unfinished job and complete
> jobs that are too old. In this same thread, we are also forcefully cancel
> blocking queue items if they've been staying there for too long. Currently if
> there is an exception thrown in expunging one job, for example, like the one
> below:
> 2014-10-14 17:57:26,347 INFO [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-67ae4177) Expunging unfinished job AsyncJobVO
> {id:18443, userId: 60, accountId: 69, instanceType: null, instanc eId: null,
> cmd: com.cloud.vm.VmWorkStart, cmdInfo:
> rO0ABXNyABhjb20uY2xvdWQudm0uVm1Xb3JrU3RhcnR9cMGsvxz73gIACkoABGRjSWRMAAZhdm9pZHN0ADBMY29tL2Nsb3VkL2RlcGxveS9EZXBsb3ltZW50UGxhbm5lciRFeGNsdWRlTGlzdDtMAAljb
>
> HVzdGVySWR0ABBMamF2YS9sYW5nL0xvbmc7TAAGaG9zdElkcQB-AAJMAAtqb3VybmFsTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO0wAEXBoeXNpY2FsTmV0d29ya0lkcQB-AAJMAAVwb2RJZHEAfgACTAAGcG9vbElkcQB-AAJMAAlyYXdQYXJhbXN0AA9MamF2YS91dGlsL
>
> 01hcDtMAA1yZXNlcnZhdGlvbklkcQB-AAN4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1lcQB-AAN4cABFADwCdXQAGVZpcnR1YWxNYWNoaW5lTWFuY
>
> WdlckltcGwAAHBwcHBwcHBzcgARamF2YS51dGlsLkhhc2hNYXAFB9rBwxZg0QMAAkYACmxvYWRGYWN0b3JJAAl0aHJlc2hvbGR4cD9MdwgQAXQAClZtUGFzc3dvcmR0ABxyTzBBQlhRQURuTmhkbVZrWDNCaGMzTjNiM0preHA,
> cmdVersi on: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
> result: null, initMsid: 244536014864905, completeMsid: null, lastUpdated:
> null, lastPolled: null, created: Wed Aug 20 18:14:13 EDT 2014}
> 2014-10-14 17:57:26,350 DEBUG [c.c.u.d.T.Transaction]
> (AsyncJobMgr-Heartbeat-1:ctx-67ae4177) Rolling back the transaction: Time = 2
> Name = AsyncJobMgr-Heartbeat-1; called by -TransactionLegacy.rollback:8
> 96-TransactionLegacy.removeUpTo:839-TransactionLegacy.close:663-TransactionContextInterceptor.invoke:35-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocat
> ion.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy151.expunge:-1-AsyncJobManagerImpl$8.doInTransactionWithoutResult:802-TransactionCallbackNoReturn.doInTransaction:25-Transaction$2.doInTransaction:49
> 2014-10-14 17:57:26,368 ERROR [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-67ae4177) Unexpected exception when trying to
> execute queue item,
> com.cloud.utils.exception.CloudRuntimeException: DB Exception on:
> com.mysql.jdbc.JDBC4PreparedStatement@39fdfb52: DELETE FROM async_job WHERE
> async_job.id= 18443
> at com.cloud.utils.db.GenericDaoBase.expunge(GenericDaoBase.java:1144)
> at sun.reflect.GeneratedMethodAccessor247.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:622)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at
> com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:33)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at
> org.springframework.aop.in
[jira] [Commented] (CLOUDSTACK-7754) 'vm_template.source_template_id' of Template created from Snapshot was NULL
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14178480#comment-14178480 ] ASF subversion and git services commented on CLOUDSTACK-7754: - Commit a72580def0b555f479fbaa093cf4f8d95a8ea756 in cloudstack's branch refs/heads/baremetal-systemvm from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a72580d ] CLOUDSTACK-7754: Templates source_template_id is null when it is created from Snapshot with its corresponding volume removed. Fix it by searching for volumes including removed. (cherry picked from commit 287ff83552081cd91c68af6214016ca4cc4cc040) > 'vm_template.source_template_id' of Template created from Snapshot was NULL > > > Key: CLOUDSTACK-7754 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7754 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.5.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Critical > Fix For: 4.5.0 > > > Here is the procedure to reproduce the issue. This is consistent on my > environment. > Steps: > i) Create instance A > ii) Take snapshot A from instance A > iii) Create template 1 from snapshot A > iv) Delete instance A > v) Create template 2 from snapshot A > Test result: > The issue occurred to template 2 which was created after instance A was > deleted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5576) RemoteVPNonVPC : Label needs to be changed to "Enable Remote Access VPN"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14178479#comment-14178479 ] ASF subversion and git services commented on CLOUDSTACK-5576: - Commit 3db112f75c3e2391bce896c868095f3444e43451 in cloudstack's branch refs/heads/baremetal-systemvm from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3db112f ] CLOUDSTACK-5576: UI > IP Address > EnableVPN, DisableVPN: change label. > RemoteVPNonVPC : Label needs to be changed to "Enable Remote Access VPN" > - > > Key: CLOUDSTACK-5576 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5576 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Chandan Purushothama >Assignee: Jessica Wang >Priority: Minor > Labels: DEVREV > Fix For: 4.5.0 > > Attachments: 2014-10-17-jessica1.jpg, 2014-10-17-jessica2.jpg, > UICapture38.png > > > The corresponding UI Screenshot has been attached to the bug report. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7760) Data disk size is not considering for primary storage resource limit check
Bharat Kumar created CLOUDSTACK-7760: Summary: Data disk size is not considering for primary storage resource limit check Key: CLOUDSTACK-7760 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7760 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.5.0 During VM deployment and while choosing CUSTOM disk offering for data disk, the size of the data disk is not considered for checking resource limit of primary storage. size += _diskOfferingDao.findById(diskOfferingId).getDiskSize(); _resourceLimitMgr.checkResourceLimit(owner, ResourceType.primary_storage, new Long (size)); getDiskSize() method returns 0 in case of custom disk offering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7759) [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjeev N updated CLOUDSTACK-7759: -- Attachment: management-server.rar Attached MS log > [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start > > > Key: CLOUDSTACK-7759 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7759 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 > Environment: Latest build from 4.5 >Reporter: Sanjeev N >Priority: Critical > Fix For: 4.5.0 > > Attachments: management-server.rar > > > [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start > Steps to Reproduce: > === > 1.Create CS 4.5 setup using vmware cluster > 2.Wait for the system vms to come up > Observations: > == > During system vms start up we see lot of > javax.xml.ws.soap.SOAPFaultExceptions in the MS log file > 2014-10-21 21:17:28,104 WARN [c.c.h.v.m.HttpNfcLeaseMO] (Thread-29:null) > Unexpected exception > javax.xml.ws.soap.SOAPFaultException: A specified parameter was not correct. > percent > at > com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) > at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:129) > at $Proxy413.httpNfcLeaseProgress(Unknown Source) > at > com.cloud.hypervisor.vmware.mo.HttpNfcLeaseMO.updateLeaseProgress(HttpNfcLeaseMO.java:104) > at > com.cloud.hypervisor.vmware.mo.HttpNfcLeaseMO$ProgressReporter.run(HttpNfcLeaseMO.java:163) > But these exceptions disappear when the system vms are up and running. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7759) [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start
Sanjeev N created CLOUDSTACK-7759: - Summary: [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start Key: CLOUDSTACK-7759 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7759 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Environment: Latest build from 4.5 Reporter: Sanjeev N Priority: Critical Fix For: 4.5.0 [VMWare]javax.xml.ws.soap.SOAPFaultException during system vms start Steps to Reproduce: === 1.Create CS 4.5 setup using vmware cluster 2.Wait for the system vms to come up Observations: == During system vms start up we see lot of javax.xml.ws.soap.SOAPFaultExceptions in the MS log file 2014-10-21 21:17:28,104 WARN [c.c.h.v.m.HttpNfcLeaseMO] (Thread-29:null) Unexpected exception javax.xml.ws.soap.SOAPFaultException: A specified parameter was not correct. percent at com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) at com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78) at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:129) at $Proxy413.httpNfcLeaseProgress(Unknown Source) at com.cloud.hypervisor.vmware.mo.HttpNfcLeaseMO.updateLeaseProgress(HttpNfcLeaseMO.java:104) at com.cloud.hypervisor.vmware.mo.HttpNfcLeaseMO$ProgressReporter.run(HttpNfcLeaseMO.java:163) But these exceptions disappear when the system vms are up and running. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-3477) resizeDataVolume doesn't return proper error message when trying to shrink volume on KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-3477: -- Component/s: KVM > resizeDataVolume doesn't return proper error message when trying to shrink > volume on KVM > > > Key: CLOUDSTACK-3477 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3477 > 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 > Environment: Management Server: RHEL 6.3 > KVM : Rhel 6.3 >Reporter: Pavan Kumar Bandarupally >Priority: Minor > Fix For: 4.4.0 > > Attachments: jessica_example1.jpg > > > Shrink of QCOW2 data volumes is not supported. When user tries to shrink data > volume of a VM on KVM, there is no error returned by the CloudStack UI. In > the UI task (shrink data volume) will be completed successfully. > The task should not be shown as successful as the operation is not supported > by code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-2605) [UI] Add Network to VM Command button should not be displayed for VMs belonging to Basic Zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-2605: -- Summary: [UI] Add Network to VM Command button should not be displayed for VMs belonging to Basic Zone (was: Add Network to VM Command button should not be displayed for VMs belonging to Basic Zone) > [UI] Add Network to VM Command button should not be displayed for VMs > belonging to Basic Zone > -- > > Key: CLOUDSTACK-2605 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2605 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 >Reporter: shweta agarwal >Priority: Minor > Fix For: 4.4.0 > > > Add Network to VM feature is only applicable to advanced zone so if a VM is > deployed in Basic Zone then in Nic tab of VM it should not show Add Nic to VM > Command button. Anyway when user is trying to add Network its getting error > "A NIC already exists for VM in network" so its better and cleaner if we just > dont show add network to VM command button f VM belongs to basic zone -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7582) Not able to remove tag from prinmary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saksham Srivastava reassigned CLOUDSTACK-7582: -- Assignee: Saksham Srivastava > Not able to remove tag from prinmary storage > > > Key: CLOUDSTACK-7582 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7582 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.5.0 >Reporter: prashant kumar mishra >Assignee: Saksham Srivastava > Fix For: 4.5.0 > > > steps to reproduce > == > 1-update storage tags > 2-try to remove tag by passing empty value > expected: > > tags should be removed > actual > > storage tag is not getting removed > API > === > http://10.147.59.173:8096/client/api?command=updateStoragePool&id=f672eae0-b400-3767-808f-b787a5c04d5f&tags=&capacitybytes=5497558138880&response=xml > cloud-stack-version="4.5.0-SNAPSHOT">f672eae0-b400-3767-808f-b787a5c04d5fd5e96cca-0985-49fe-a777-49b257278c8amanasaprimaryVMw10.147.28.7/export/home/manasa/primaryVMw2014-09-12T11:26:37+0530NetworkFilesystem549755813888042949672962696516272128abUpZONEVMware -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7582) Not able to remove tag from prinmary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-7582: -- Component/s: Storage Controller > Not able to remove tag from prinmary storage > > > Key: CLOUDSTACK-7582 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7582 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.5.0 >Reporter: prashant kumar mishra > Fix For: 4.5.0 > > > steps to reproduce > == > 1-update storage tags > 2-try to remove tag by passing empty value > expected: > > tags should be removed > actual > > storage tag is not getting removed > API > === > http://10.147.59.173:8096/client/api?command=updateStoragePool&id=f672eae0-b400-3767-808f-b787a5c04d5f&tags=&capacitybytes=5497558138880&response=xml > cloud-stack-version="4.5.0-SNAPSHOT">f672eae0-b400-3767-808f-b787a5c04d5fd5e96cca-0985-49fe-a777-49b257278c8amanasaprimaryVMw10.147.28.7/export/home/manasa/primaryVMw2014-09-12T11:26:37+0530NetworkFilesystem549755813888042949672962696516272128abUpZONEVMware -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7537) RBD pool secret should be masked in logs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala reassigned CLOUDSTACK-7537: - Assignee: Kishan Kavala > RBD pool secret should be masked in logs > > > Key: CLOUDSTACK-7537 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7537 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Kishan Kavala > Fix For: 4.5.0 > > > RBD pool authentication secret key is logged in plain text in management > server and agent logs at the following places: > - While adding pool to MS > - When MS send modifyStorage pool command to agent > secret should not be visible in plain text. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7512) Failing to destroy eth0/bond0 on xenserver hv
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kishan Kavala updated CLOUDSTACK-7512:
--
Component/s: XenServer
> Failing to destroy eth0/bond0 on xenserver hv
> -
>
> Key: CLOUDSTACK-7512
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7512
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: XenServer
>Affects Versions: 4.4.0
> Environment: XenServer release 6.1.0-59235p (xenenterprise)
> Management server: CentOS release 6.4 (Final)
> Cloudstack rpms:
> cloudstack-management-4.4.0-NONOSS_3.el6.x86_64
> cloudstack-common-4.4.0-NONOSS_3.el6.x86_64
> cloudstack-cli-4.4.0-NONOSS_3.el6.x86_64
> cloudstack-usage-4.4.0-NONOSS_3.el6.x86_64
> cloudstack-awsapi-4.4.0-NONOSS_3.el6.x86_64
>Reporter: Justyn Shull
>
> We are seeing several log messages like "failed to destory VLAN eth0" similar
> to this one:
> {quote}
> # grep 'ctx-d0cb1a4e' /var/log/cloudstack/management/management-server.log
> 2014-09-08 00:16:24,492 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-423:ctx-d0cb1a4e) Seq 28-4995617886660728088: Executing request
> 2014-09-08 00:16:24,581 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-423:ctx-d0cb1a4e) 9. The VM i-1847-6367-VM is in Stopping state
> 2014-09-08 00:16:38,328 INFO [c.c.h.x.r.XenServer56Resource]
> (DirectAgent-423:ctx-d0cb1a4e) Catch
> com.xensource.xenapi.Types$InternalError: failed to destory VLAN eth0 on host
> 9fcb2c68-6483-4ef9-8842-0b87151346d0 due to The server failed to handle your
> request, due to an internal error. The given message may give details useful
> for debugging the problem.
> 2014-09-08 00:16:39,308 INFO [c.c.h.x.r.XenServer56Resource]
> (DirectAgent-423:ctx-d0cb1a4e) Catch
> com.xensource.xenapi.Types$InternalError: failed to destory VLAN eth0 on host
> 9fcb2c68-6483-4ef9-8842-0b87151346d0 due to The server failed to handle your
> request, due to an internal error. The given message may give details useful
> for debugging the problem.
> 2014-09-08 00:16:39,308 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-423:ctx-d0cb1a4e) 10. The VM i-1847-6367-VM is in Stopped state
> 2014-09-08 00:16:39,308 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-423:ctx-d0cb1a4e) Seq 28-4995617886660728088: Response Received:
> 2014-09-08 00:16:39,309 DEBUG [c.c.a.m.ClusteredAgentManagerImpl]
> (DirectAgent-423:ctx-d0cb1a4e) Seq 28-4995617886660728088: MgmtId
> 33862771676063: Resp: Routing to peer
> 2014-09-08 00:16:39,309 DEBUG [c.c.a.m.AgentAttache]
> (DirectAgent-423:ctx-d0cb1a4e) Seq 28-4995617886660728088: No more commands
> found
> {quote}
> On the hypervisor in question, eth0 is used with vlans. xenbr0 has eth0 in
> it, but any other bridges shown by "brctl show" only have eth0.X for
> whichever vlan it is using.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7318) [LXC][UI] processing wheel continue to spin even after error messaage during VM snapshot creation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala reassigned CLOUDSTACK-7318: - Assignee: Kishan Kavala > [LXC][UI] processing wheel continue to spin even after error messaage during > VM snapshot creation > - > > Key: CLOUDSTACK-7318 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7318 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala > Fix For: 4.5.0 > > Attachments: processingwheel.png > > > Repro steps: > Create a LXC VM > When VM is running try to createa VM snapshot > Bug: > Notice you get message VM snapshot is not enabled for hypervisor type: LXC > but spinnign wheel continue to spin . attaching snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7291) LXC: Mgmt server/agent keeps killing systemvms
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-7291: -- Affects Version/s: (was: 4.5.0) > LXC: Mgmt server/agent keeps killing systemvms > -- > > Key: CLOUDSTACK-7291 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7291 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0, 4.3.1 >Reporter: Rohit Yadav > Fix For: 4.3.1 > > > Followed installation and setup docs of 4.3, was unable to get LXC to work on > Ubuntu 14.04/trusty. The systemvms kept coming up and result from > ssvm_check.sh was good and it was able to reach mgmt server /host, even then > mgmt server complained that it was unable to contact agent on the systemvm > (ping), while the agent would gracefully shutdown the systemvm (by killing > them). > Relevant log: > 2014-08-07 19:52:26,294 INFO [c.c.u.e.CSExceptionErrorCode] > (secstorage-1:ctx-fc57ef43) Could not find exception: > com.cloud.exception.OperationTimedoutException in error code list for > exceptions > 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] > (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host > Host[-1-Routing] > 2014-08-07 19:52:26,295 DEBUG [c.c.a.m.AgentAttache] > (consoleproxy-1:ctx-e123fa9c) Seq 1-51249205: Cancelling. > 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] > (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host > Host[-1-Routing] > 2014-08-07 19:52:26,303 DEBUG [c.c.h.Status] (AgentTaskPool-13:ctx-0b35e679) > Transition:[Resource state = Enabled, Agent event = ShutdownRequested, Host > id = 1, name = bluebox1.bhaisaab.org] > 2014-08-07 19:52:26,311 DEBUG [c.c.h.HighAvailabilityManagerImpl] > (secstorage-1:ctx-fc57ef43) Scheduled > HAWork[12-CheckStop-2-Starting-Scheduled] > 2014-08-07 19:52:26,314 WARN [c.c.s.s.SecondaryStorageManagerImpl] > (secstorage-1:ctx-fc57ef43) Exception while trying to start secondary storage > vm > com.cloud.exception.AgentUnavailableException: Resource [Host:1] is > unreachable: Host 1: Unable to start s-2-VM > >---at > >com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1051) > >---at > >com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761) > >---at > >com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:745) > >---at > >com.cloud.storage.secondary.SecondaryStorageManagerImpl.startSecStorageVm(SecondaryStorageManagerImpl.java:261) > >---at > >com.cloud.storage.secondary.SecondaryStorageManagerImpl.allocCapacity(SecondaryStorageManagerImpl.java:694) > >---at > >com.cloud.storage.secondary.SecondaryStorageManagerImpl.expandPool(SecondaryStorageManagerImpl.java:1278) > >---at > >com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:123) > >---at > >com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:50) > >---at > >com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111) > ... > ... > ... > Caused by: com.cloud.exception.OperationTimedoutException: Commands 51249206 > to Host 1 timed out after 3600 > >---at com.cloud.agent.manager.AgentAttache.send(AgentAttache.java:439) > > > >---at > >com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:394) > >---at > >com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:920) > >---at > >com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:989) > >---... 24 more > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6765) unable to create primary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-6765: -- Component/s: XenServer > unable to create primary storage > > > Key: CLOUDSTACK-6765 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6765 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.4.0 >Reporter: Daan Hoogland > Attachments: vmops-primstor-failure.log > > > in cs 4.4 pre-rc on xenserver 6.0.2: > when adding a primary storage using marvin an error is thrown: > Traceback (most recent call last): > File "./setup.py", line 69, in > primid = primstorutil.createPrimaryStorage(conn,zoneid=zoneid, > podid=podid, clusterid=xenclusterid, name="Xen Primary Storage", > url="nfs://10.200.23.31/volumes/mccd_volume1/primary_storage") > File > "/cygdrive/c/Users/dhoogland/cloudstack/cs-test-utils/bin/primaryStorageCommand.py", > line 38, in createPrimaryStorage > resp = conn.marvin_request(createPrimary) > File "/usr/lib/python2.7/site-packages/marvin/cloudstackConnection.py", > line 222, in marvin_request > response = jsonHelper.getResultObj(response.json(), response_type) > File "/usr/lib/python2.7/site-packages/marvin/jsonHelper.py", line 148, in > getResultObj > raise cloudstackException.cloudstackAPIException(respname, errMsg) > marvin.cloudstackException.cloudstackAPIException: Execute cmd: > createstoragepool failed, due to: errorCode: 530, errorText:None > the server output shows: > WARN [c.c.h.x.r.CitrixResourceBase] (DirectAgent-8:ctx-7829bd03) Catch > Exception com.cloud.utils.exception.CloudRuntimeException, create StoragePool > failed due to com.cloud.utils.exception.CloudRuntimeException: Unable to > create NFS SR Pool[1|10.200.23.31:2049|/volumes/mccd_volume1/primary_storage] > on host:8545fcea-9758-4e97-8f52-83e4f37cc7f2 pool: > 10.200.23.31/volumes/mccd_volume1/primary_storage > com.cloud.utils.exception.CloudRuntimeException: Unable to create NFS SR > Pool[1|10.200.23.31:2049|/volumes/mccd_volume1/primary_storage] > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.getNfsSR(CitrixResourceBase.java:6183) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:5125) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:474) > at > com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:61) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) > at java.util.concurrent.FutureTask.run(Unknown Source) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown > Source) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown > Source) > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > at java.lang.Thread.run(Unknown Source) > Caused by: SR_BACKEND_FAILURE_40The SR scan failed > [opterr=uuid=6a52feb4-c27d-4c36-8e5c-78ba364d9307] > at com.xensource.xenapi.Types.checkResponse(Types.java:2006) > at com.xensource.xenapi.Connection.dispatch(Connection.java:350) > at > com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:456) > at com.xensource.xenapi.SR.scan(SR.java:1051) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.getNfsSR(CitrixResourceBase.java:6180) > ... 16 more > WARN [o.a.c.s.d.l.CloudStackPrimaryDataStoreLifeCycleImpl] > (1326853303@qtp-1366828871-0:ctx-457b75a4 ctx-324d7984 ctx-8a6af5a5) Can not > create storage pool through host 1 due to Catch Exception > com.cloud.utils.exception.CloudRuntimeException, create StoragePool failed > due to com.cloud.utils.exception.CloudRuntimeException: Unable to create NFS > SR Pool[1|10.200.2
[jira] [Updated] (CLOUDSTACK-6690) [UI] ListView while assigning VM to internal LB rule in VPC is not valid.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kishan Kavala updated CLOUDSTACK-6690:
--
Summary: [UI] ListView while assigning VM to internal LB rule in VPC is
not valid. (was: ListView while assigning VM to internal LB rule in VPC is
not valid.)
> [UI] ListView while assigning VM to internal LB rule in VPC is not valid.
> --
>
> Key: CLOUDSTACK-6690
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6690
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.3.0, 4.4.0
>Reporter: manasaveloori
> Fix For: 4.4.0
>
> Attachments: Listview.jpg
>
>
> 1. Create VPC.
> 2. Create a tier network with network offering having support for internal LB.
> 3. Deploy a VM under this tier network.
> 3. VPC->tier->internal LBCon figure internal LB.
> 4. Now assign the VM to internal LB.
> While assigning we are haviing 2 options to select the VM.
> Listview on left hand side is not valid.
> Assigning the VM by using the Listview does not configure the lb rule:
> Logs
> 2014-05-16 16:00:58,946 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-12:job-444) Executing AsyncJobVO {id:444, userId: 2,
> accountId: 2, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.loadbalancer.AssignToLoadBalancerRuleCmd,
> cmdInfo:
> {"response":"json","id":"c2ca8600-0cf9-44a0-8443-da5c743cbd49","sessionkey":"e9nTmi2e/Ci2Oy/hkABO5FRlkI8\u003d","cmdEventType":"LB.ASSIGN.TO.RULE","virtualmachineids":"","ctxUserId":"2","httpmethod":"GET","_":"1400236258357","ctxAccountId":"2","ctxStartEventId":"541"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 7322717913215, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-05-16 16:00:59,016 WARN [c.c.n.l.LoadBalancingRulesManagerImpl]
> (API-Job-Executor-12:job-444 ctx-723e9aab) List of vms to assign to the lb,
> is empty
> 2014-05-16 16:00:59,029 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-12:job-444) Complete async job-444, jobStatus: FAILED,
> resultCode: 530, result:
> org.apache.cloudstack.api.response.ExceptionResponse/null/{"uuidList":[],"errorcode":530,"errortext":"Failed
> to assign load balancer rule"}
> 2014-05-16 16:00:59,042 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-12:job-444) Done executing
> org.apache.cloudstack.api.command.user.loadbalancer.AssignToLoadBalancerRuleCmd
> for job-444
> Attaching the screen shot for the same.
> Able to assign VM to internal LB uisng the select button on right hand side.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6220) Cloudstack agent fails to start due to broken init script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-6220: -- Labels: KVM agent (was: agent) > Cloudstack agent fails to start due to broken init script > - > > Key: CLOUDSTACK-6220 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6220 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.4.0 > Environment: CentOS 6.5 KVM/libvirt >Reporter: Nux > Labels: KVM, agent > > Hello, > On 4.4 `service cloudstack-agent start` fails with: > # service cloudstack-agent start > Starting Cloud Agent: > touch: cannot touch `/var/lock/subsys//etc/init.d/cloudstack-agent': No such > file or directory > /etc/init.d/cloudstack-agent used to have this which worked fine: > whatami=cloudstack-agent > SHORTNAME="$whatami" > Now it has been replaced with this which fails: > SHORTNAME="$0" > A possible solution is to replace "$0" with `basename "$0"` -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5800) While creating a VM from template (which is created based on existing newly created vm) getting error as Unable to deploy vm base on template due to of insufficient
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-5800: -- Component/s: (was: API) XenServer > While creating a VM from template (which is created based on existing newly > created vm) getting error as Unable to deploy vm base on template due to of > insufficient server capicity > - > > Key: CLOUDSTACK-5800 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5800 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template, XenServer >Affects Versions: 4.3.0 > Environment: CENTOS 6.4,WIN2012,ACS 4.3.0, >Reporter: rashid > Fix For: 4.4.0 > > > While creating a vm from template > INFO [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-5:ctx-c259052d) Add job-46 > into job monitoring > INFO [o.a.c.s.v.VolumeServiceImpl] (Job-Executor-5:ctx-c259052d > ctx-506ea49e) lock is acquired for VMTemplateStoragePool 7 > WARN [o.a.c.alerts] (CapacityChecker:ctx-374c70b5) alertType:: 24 // > dataCenterId:: 1 // podId:: null // clusterId:: null // message:: System > Alert: Number of unallocated shared network IPs is low in availability zone > NEWZONE > WARN [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-32c31ce6) Task (job-45) has > been pending for 104 seconds > WARN [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-32c31ce6) Task (job-46) has > been pending for 103 seconds > WARN [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-92c2ed53) Task (job-45) has > been pending for 164 seconds > WARN [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-92c2ed53) Task (job-46) has > been pending for 163 seconds > WARN [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-4:ctx-f87acd3c) > destoryVDIbyNameLabel failed due to there are 0 VDIs with name > cloud-377c12f4-a8e9-491a-8cba-34b9532455f8 > WARN [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-4:ctx-f87acd3c) > failed to set hidden to 0 > /var/run/sr-mount/ab820f54-badd-db21-f758-0abcb47ea4d7/b0246f72-9bda-4f29-981f-548f4b7a9f6c.vhd > WARN [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-4:ctx-f87acd3c) > Catch Exception com.cloud.utils.exception.CloudRuntimeException for template > + due to com.cloud.utils.exception.CloudRuntimeException: failed to set > hidden to 0 > /var/run/sr-mount/ab820f54-badd-db21-f758-0abcb47ea4d7/b0246f72-9bda-4f29-981f-548f4b7a9f6c.vhd > com.cloud.utils.exception.CloudRuntimeException: failed to set hidden to 0 > /var/run/sr-mount/ab820f54-badd-db21-f758-0abcb47ea4d7/b0246f72-9bda-4f29-981f-548f4b7a9f6c.vhd > at > com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copy_vhd_from_secondarystorage(XenServerStorageProcessor.java:858) > at > com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copyTemplateToPrimaryStorage(XenServerStorageProcessor.java:928) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:75) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:50) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:609) > at > com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59) > at > com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPo
[jira] [Updated] (CLOUDSTACK-5700) [Vmsync] - kvm- "paused" state of Vm is not synced to CS.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-5700: -- Component/s: KVM > [Vmsync] - kvm- "paused" state of Vm is not synced to CS. > - > > Key: CLOUDSTACK-5700 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5700 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan > Fix For: 4.4.0 > > > [Vmsync] - kvm - "paused" state of Vm is not synced to CS. > Steps to reproduce the problem: > PreReq: > Have few Vms deployed using Cloudstack. > Steps: > Outside of Cloudstack , Suspend an existing VM using the following command: > virsh suspend > Vmsync does not detect the "paused" state of a VM. CS reports the real state > of this VM as "running" > 2013-12-31 18:44:20,977 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) Found 6 VMs for host 2 > 2013-12-31 18:44:20,990 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) VM i-3-3-VM: cs state = Running and > realState = Running > 2013-12-31 18:44:20,997 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) VM i-3-3-VM: cs state = Running and > realState = Running > 2013-12-31 18:44:20,997 DEBUG [c.c.v.VirtualMachineManagerImpl] > (AgentConnectTaskPool-4:ctx-daf59377) Both states are Running for > VM[User|TestVM-1] > [root@Rack3Host14 ~]# virsh list > IdName State > > 2 r-4-VM running > 5 i-3-6-VM running > 6 i-3-5-VM running > 7 s-9-VM running > 9 i-3-8-VM running > 10i-3-3-VM paused -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5583) vmopsSnapshot plug-in (XenServer) does not return an error when it should
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-5583: -- Component/s: Snapshot > vmopsSnapshot plug-in (XenServer) does not return an error when it should > - > > Key: CLOUDSTACK-5583 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5583 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot, Xen >Affects Versions: 4.3.0 > Environment: XenServer 6.1 >Reporter: Mike Tutkowski > Fix For: 4.4.0 > > > I tried to revert a VM snapshot and one of my storage repositories had an > insufficient amount of space. The plug-in did not return an error message (it > returned "0"). > From the XenServer vmopsSnapshot plug-in's revert_memory_snapshot method: > [root@XenServer-6 ~]# xe snapshot-revert > snapshot-uuid=82e33f6d-59f3-a26d-4171-d51cd58716d8 > Error code: SR_BACKEND_FAILURE_44 > Error parameters: , There is insufficient space, > An error should be returned from the plug-in instead of "0". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7541) Volume gets created with the size mentioned in the custom disk offering
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anshul Gangwar reassigned CLOUDSTACK-7541:
--
Assignee: Anshul Gangwar
> Volume gets created with the size mentioned in the custom disk offering
>
>
> Key: CLOUDSTACK-7541
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7541
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Volumes
>Affects Versions: 4.5.0
> Environment: latest build from 4.5 with commit
> 932ea253eb8c65821503ab9db301073cdb2a413e
>Reporter: Sanjeev N
>Assignee: Anshul Gangwar
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: cloud.dmp, management-server.rar
>
>
> Volume gets created with the size mentioned in the custom disk offering
> Steps to reproduce:
> ==
> 1.Bring up cs with latest build
> 2.Create custom disk offering with disk size say 2
> 3.Create data disk using this offering and provide disk size as 1 while
> creating data disk
> Expected Result:
> ==
> Since the disk offering is of type custom , volume should be created with
> size given during volume creation instead of taking it from the disk offering.
> If the disk offering is custom then the volume creation must ignore the size
> given in the offering and should create volume with size provide while
> creating volume.
> Actual Result:
> ===
> Disk got created with size mentioned in disk offering rather than the size
> given during volume creation time.
> Observations:
> ===
> http://10.147.38.153:8096/client/api?command=createDiskOffering&isMirrored=false&name=custom&displaytext=custom&storageType=shared&cacheMode=none&provisioningType=thin&customized=true&disksize=2
> { "creatediskofferingresponse" : { "diskoffering" :
> {"id":"2ddb8b79-9592-4b8c-8bd9-3d32c582873b","name":"custom","displaytext":"custom","disksize":2,"created":"2014-09-12T23:33:24+0530","iscustomized":true,"storagetype":"shared","provisioningtype":"thin","displayoffering":true}
> } }
> http://10.147.38.153:8080/client/api?command=createVolume&response=json&sessionkey=USf4e%2BpnzNiyWyq1PCeDFswjB%2BU%3D&name=custom&zoneId=2c67c83e-b8c3-42d0-a37b-b37287ac84dd&diskOfferingId=2ddb8b79-9592-4b8c-8bd9-3d32c582873b&size=1&_=1410525928417
> { "queryasyncjobresultresponse" :
> {"accountid":"638d4e82-341f-11e4-a4c9-06097e23","userid":"638d5ddc-341f-11e4-a4c9-06097e23","cmd":"org.apache.cloudstack.api.command.admin.volume.CreateVolumeCmdByAdmin","jobstatus":1,"jobprocstatus":0,"jobresultcode":0,"jobresulttype":"object","jobresult":{"volume":{"id":"42f24df4-b4ae-4b4c-80ce-ea1b5daf12bd","name":"custom","zoneid":"2c67c83e-b8c3-42d0-a37b-b37287ac84dd","zonename":"zone1","type":"DATADISK","provisioningtype":"thin","size":2147483648,"created":"2014-09-12T23:34:32+0530","state":"Allocated","account":"admin","domainid":"2caca782-341f-11e4-a4c9-06097e23","domain":"ROOT","storagetype":"shared","hypervisor":"None","diskofferingid":"2ddb8b79-9592-4b8c-8bd9-3d32c582873b","diskofferingname":"custom","diskofferingdisplaytext":"custom","destroyed":false,"isextractable":true,"tags":[],"displayvolume":true,"quiescevm":false,"jobid":"edf1a066-63b0-400b-bf15-4f77bf659206","jobstatus":0}},"jobinstancetype":"Volume","jobinstanceid":"42f24df4-b4ae-4b4c-80ce-ea1b5daf12bd","created":"2014-09-12T23:34:32+0530","jobid":"edf1a066-63b0-400b-bf15-4f77bf659206"}
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7758) Although API calls are failing, events tab shows them as successful
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar updated CLOUDSTACK-7758: --- Priority: Critical (was: Major) > Although API calls are failing, events tab shows them as successful > --- > > Key: CLOUDSTACK-7758 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7758 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar >Priority: Critical > Fix For: 4.5.0 > > > Like Deployment of VM is failing. But event tab shows them as "Successfully > completed starting VM". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7758) Although API calls are failing, events tab shows them as successful
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar updated CLOUDSTACK-7758: --- Fix Version/s: 4.5.0 > Although API calls are failing, events tab shows them as successful > --- > > Key: CLOUDSTACK-7758 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7758 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar > Fix For: 4.5.0 > > > Like Deployment of VM is failing. But event tab shows them as "Successfully > completed starting VM". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7758) Although API calls are failing, events tab shows them as successful
Anshul Gangwar created CLOUDSTACK-7758: -- Summary: Although API calls are failing, events tab shows them as successful Key: CLOUDSTACK-7758 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7758 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Like Deployment of VM is failing. But event tab shows them as "Successfully completed starting VM". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7757) CloudStack don't remove VM from VMware
Denis Finko created CLOUDSTACK-7757:
---
Summary: CloudStack don't remove VM from VMware
Key: CLOUDSTACK-7757
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7757
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.2.1
Environment: VMware ESXi 5.1.0
Reporter: Denis Finko
Hello CloudStack community,
I have found a lot of old VMs that were removed from CloudStack but still
present in VMware. After that I created 6 similar VMs in CloudStack and tried
to remove then from user interface with 'Expunge' mark:
http://take.ms/vZ4AE
I was surprised that only 3 VMs from 6 were removed from VMware:
---+---++
name | removed time | Is VM was removed from VMware
---+---++
test-2010-3 | 07:46:53| NO
---+---++
test-2010-4 | 07:49:45| YES
---+---++
test-2010-5 | 07:55:32| YES
---+---++
test-2110-1 | 07:57:08| NO
---+---++
test-2110-2 | 08:00:44| NO
---+---++
test-2110-3 | 08:03:06| YES
---+---++
I have checked management-server.log for 'test-2110-2 ' and 'test-2110-3' VMs
and their looks similar:
logs for test-2110-2 (that VM wasn't removed from VMware environment):
2014-10-21 04:00:44,190 DEBUG [cloud.async.AsyncJobManagerImpl]
(ajp-20400-5:null) submit async job-7170 = [
b37ded66-33f7-4782-a36a-b7559d7d1462 ], details: AsyncJobVO {id:7170, userId:
2, accountId: 2, sessionKey: null, instanceType: VirtualMachine, instanceId:
2185, cmd: org.apache.cloudstack.api.command.user.vm.DestroyVMCmd,
cmdOriginator: null, cmdInfo:
{"id":"b84498ba-bd20-4390-b239-0123fa566cac","response":"json","sessionkey":"vjRevp3+g1aH20gH0JkG8EVRSfg\u005d","cmdEventType":"VM.DESTROY","ctxUserId":"2","httpmethod":"GET","_":"1413878444174","ctxAccountId":"2","expunge":"true","ctxStartEventId":"407103"},
cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
processStatus: 0, resultCode: 0, result: null, initMsid: 345048632606,
completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2014-10-21 04:00:44,190 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-28:job-7170 = [ b37ded66-33f7-4782-a36a-b7559d7d1462 ]) Executing
org.apache.cloudstack.api.command.user.vm.DestroyVMCmd for job-7170 = [
b37ded66-33f7-4782-a36a-b7559d7d1462 ]
2014-10-21 04:00:44,213 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-28:job-7170 = [ b37ded66-33f7-4782-a36a-b7559d7d1462 ])
Destroying vm VM[User|test-2110-2]
2014-10-21 04:00:44,213 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-28:job-7170 = [ b37ded66-33f7-4782-a36a-b7559d7d1462 ]) VM is
already stopped: VM[User|test-2110-2]
2014-10-21 04:00:44,223 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-28:job-7170 = [ b37ded66-33f7-4782-a36a-b7559d7d1462 ]) VM state
transitted from :Stopped to Destroyed with event: DestroyRequestedvm's original
host id: 22 new host id: null host id before state transition: null
2014-10-21 04:00:44,231 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-28:job-7170 = [ b37ded66-33f7-4782-a36a-b7559d7d1462 ]) Hosts's
actual total CPU: 67168 and CPU after applying overprovisioning: 67168
2014-10-21 04:00:44,231 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-28:job-7170 = [ b37ded66-33f7-4782-a36a-b7559d7d1462 ]) Hosts's
actual total RAM: 137391218688 and RAM after applying overprovisioning:
137391218688
2014-10-21 04:00:44,231 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-28:job-7170 = [ b37ded66-33f7-4782-a36a-b7559d7d1462 ]) release
cpu from host: 22, old used: 56486,reserved: 1000, actual total: 67168, total
with overprovisioning: 67168; new used: 56486,reserved:0; movedfromreserved:
true,moveToReserveredfalse
2014-10-21 04:00:44,231 DEBUG [cloud.capacity.CapacityManagerImpl]
(Job-Executor-28:job-7170 = [ b37ded66-33f7-4782-a36a-b7559d7d1462 ]) release
mem from host: 22, old used: 44023414784,reserved: 2147483648, total:
137391218688; new used: 44023414784,reserved:0; movedfromreserved:
true,moveToReserveredfalse
2014-10-21 04:00:44,256 DEBUG [cloud.vm.VirtualMachineManagerImpl]
[jira] [Updated] (CLOUDSTACK-7756) ClouStack calculate wrong allocated Primary Storage size
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Finko updated CLOUDSTACK-7756: Description: Hello CloudStack community, I have found that in my environment CloudStack provide wrong data for Allocated Disk Space on SATA storage. CloudStack UI displayed: Disk Total 5.00 TB Disk Allocated7.49 TB I have looked to VMware side and found absolutely different data: Capacity: 5.00 TB Provisioned Space: 4.68 TB Free Space:3.70 TB 7.49 - 4.68 = 2.81 TB (CloudStack show allocated disk space on 2.81 TB more) That's data that I can get from database: mysql> select id,name,status,capacity_bytes,capacity_iops,tag,disk_used_capacity,disk_reserved_capacity from storage_pool_view where id=2 \G 1. row -- id: 2 name: SATA1 status: Up capacity_bytes: 5497289703424 capacity_iops: NULL tag: sata disk_used_capacity: 8235717357961 disk_reserved_capacity: 0 1 row in set (0.00 sec) mysql> mysql> select v.state, sum(v.size) from volumes v, vm_instance vm, vm_root_disk_tags d where v.instance_id=vm.id and d.vm_id=vm.id and d.root_disk_tag like 'sata' group by v.state; +---+---+ | state | sum(v.size) | +---+---+ | Destroy | 664646189056 | | Expunged | 5396626407424 | | Expunging | 2147483648 | | Ready| 402653184 | +---+---+ 4 rows in set (0.01 sec) I guess that the 'Ready' disk space = 402653184 it's 'Provisioned Space' in VMware. But what is 'Disk Allocated' size in CloludStack that equal to 7.49 TB ??? How CloudStack calculate that data??? This issue is similar to this which also wasn't resolved: http://comments.gmane.org/gmane.comp.apache.cloudstack.user/13848 was: Hello CloudStack community, I have found that in my environment CloudStack provide wrong data for Allocated Disk Space on SATA storage. CloudStack UI displayed: Disk Total 5.00 TB Disk Allocated7.49 TB I have looked to VMware side and found absolutely different data: Capacity: 5.00 TB Provisioned Space: 4.68 TB Free Space:3.70 TB 7.49 - 4.68 = 2.81 TB (CloudStack show allocated disk space on 2.81 TB more) That's data that I can get from database: mysql> select id,uuid,name,status,capacity_bytes,capacity_iops,tag,disk_used_capacity,disk_reserved_capacity from storage_pool_view where id=2 \G 1. row -- id: 2 uuid: 092b4b6e-481d-35b4-9b14-7178612a1535 name: SATA1 status: Up capacity_bytes: 5497289703424 capacity_iops: NULL tag: sata disk_used_capacity: 8235717357961 disk_reserved_capacity: 0 1 row in set (0.00 sec) mysql> mysql> select v.state, sum(v.size) from volumes v, vm_instance vm, vm_root_disk_tags d where v.instance_id=vm.id and d.vm_id=vm.id and d.root_disk_tag like 'sata' group by v.state; +---+---+ | state | sum(v.size) | +---+---+ | Destroy | 664646189056 | | Expunged | 5396626407424 | | Expunging | 2147483648 | | Ready| 402653184 | +---+---+ 4 rows in set (0.01 sec) I guess that the 'Ready' disk space = 402653184 it's 'Provisioned Space' in VMware. But what is 'Disk Allocated' size in CloludStack that equal to 7.49 TB ??? How CloudStack calculate that data??? This issue is similar to this which also wasn't resolved: http://comments.gmane.org/gmane.comp.apache.cloudstack.user/13848 > ClouStack calculate wrong allocated Primary Storage size > > > Key: CLOUDSTACK-7756 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7756 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.1 > Environment: VMware ESXi 5.1.0 >Reporter: Denis Finko > > Hello CloudStack community, > I have found that in my environment CloudStack provide wrong data for > Allocated Disk Space on SATA storage. > CloudStack UI displayed: > Disk Total 5.00 TB > Disk Allocated7.49 TB > I have looked to VMware side and found absolutely different data: > Capacity: 5.00 TB > Provisioned Space: 4.68 TB > Free Space:3.70 TB > 7.49 - 4.68 = 2.81 TB (CloudStack show allocated disk space on 2.81 TB more) > That's data that I can get from database: > mysql> select > id,name,status,capacity_bytes,capacity_iops,tag,disk_used_capacity,disk_reserved_capacity > from storage_pool_view where id=2 \G > 1. row > -- >
[jira] [Updated] (CLOUDSTACK-7756) ClouStack calculate wrong allocated Primary Storage size
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Finko updated CLOUDSTACK-7756: Description: Hello CloudStack community, I have found that in my environment CloudStack provide wrong data for Allocated Disk Space on SATA storage. CloudStack UI displayed: Disk Total 5.00 TB Disk Allocated7.49 TB I have looked to VMware side and found absolutely different data: Capacity: 5.00 TB Provisioned Space: 4.68 TB Free Space:3.70 TB 7.49 - 4.68 = 2.81 TB (CloudStack show allocated disk space on 2.81 TB more) That's data that I can get from database: mysql> select id,uuid,name,status,capacity_bytes,capacity_iops,tag,disk_used_capacity,disk_reserved_capacity from storage_pool_view where id=2 \G 1. row -- id: 2 uuid: 092b4b6e-481d-35b4-9b14-7178612a1535 name: SATA1 status: Up capacity_bytes: 5497289703424 capacity_iops: NULL tag: sata disk_used_capacity: 8235717357961 disk_reserved_capacity: 0 1 row in set (0.00 sec) mysql> mysql> select v.state, sum(v.size) from volumes v, vm_instance vm, vm_root_disk_tags d where v.instance_id=vm.id and d.vm_id=vm.id and d.root_disk_tag like 'sata' group by v.state; +---+---+ | state | sum(v.size) | +---+---+ | Destroy | 664646189056 | | Expunged | 5396626407424 | | Expunging | 2147483648 | | Ready| 402653184 | +---+---+ 4 rows in set (0.01 sec) I guess that the 'Ready' disk space = 402653184 it's 'Provisioned Space' in VMware. But what is 'Disk Allocated' size in CloludStack that equal to 7.49 TB ??? How CloudStack calculate that data??? This issue is similar to this which also wasn't resolved: http://comments.gmane.org/gmane.comp.apache.cloudstack.user/13848 was: Hello CloudStack community, I have found that in my environment CloudStack provide wrong data for Allocated Disk Space on SATA storage. CloudStack UI displayed: Disk Total 5.00 TB Disk Allocated7.49 TB I have looked to VMware side and found absolutely different data: Capacity: 5.00 TB Provisioned Space: 4.68 TB Free Space:3.70 TB 7.49 - 4.68 = 2.81 TB (CloudStack show allocated disk space on 2.81 TB more) That's data that I can get from database: mysql> select id,uuid,name,status,capacity_bytes,capacity_iops,tag,disk_used_capacity,disk_reserved_capacity from storage_pool_view where id=2 \G 1. row -- id: 2 uuid: 096b3b6e-481d-33b4-9b34-7178612a2535 name: SATA1 status: Up capacity_bytes: 5497289703424 capacity_iops: NULL tag: sata disk_used_capacity: 8235717357961 disk_reserved_capacity: 0 1 row in set (0.00 sec) mysql> mysql> select v.state, sum(v.size) from volumes v, vm_instance vm, vm_root_disk_tags d where v.instance_id=vm.id and d.vm_id=vm.id and d.root_disk_tag like 'sata' group by v.state; +---+---+ | state | sum(v.size) | +---+---+ | Destroy | 664646189056 | | Expunged | 5396626407424 | | Expunging | 2147483648 | | Ready| 402653184 | +---+---+ 4 rows in set (0.01 sec) I guess that the 'Ready' disk space = 402653184 it's 'Provisioned Space' in VMware. But what is 'Disk Allocated' size in CloludStack that equal to 7.49 TB ??? How CloudStack calculate that data??? This issue is similar to this which also wasn't resolved: http://comments.gmane.org/gmane.comp.apache.cloudstack.user/13848 > ClouStack calculate wrong allocated Primary Storage size > > > Key: CLOUDSTACK-7756 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7756 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.1 > Environment: VMware ESXi 5.1.0 >Reporter: Denis Finko > > Hello CloudStack community, > I have found that in my environment CloudStack provide wrong data for > Allocated Disk Space on SATA storage. > CloudStack UI displayed: > Disk Total 5.00 TB > Disk Allocated7.49 TB > I have looked to VMware side and found absolutely different data: > Capacity: 5.00 TB > Provisioned Space: 4.68 TB > Free Space:3.70 TB > 7.49 - 4.68 = 2.81 TB (CloudStack show allocated disk space on 2.81 TB more) > That's data that I can get from database: > mysql> select > id,uuid,name,status,capacity_bytes,capacity_iops,tag,disk_used_capacity,disk_reserved_capacity > from storage_pool_view where id=2 \G > ---
[jira] [Updated] (CLOUDSTACK-7756) ClouStack calculate wrong allocated Primary Storage size
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Finko updated CLOUDSTACK-7756: Description: Hello CloudStack community, I have found that in my environment CloudStack provide wrong data for Allocated Disk Space on SATA storage. CloudStack UI displayed: Disk Total 5.00 TB Disk Allocated7.49 TB I have looked to VMware side and found absolutely different data: Capacity: 5.00 TB Provisioned Space: 4.68 TB Free Space:3.70 TB 7.49 - 4.68 = 2.81 TB (CloudStack show allocated disk space on 2.81 TB more) That's data that I can get from database: mysql> select id,uuid,name,status,capacity_bytes,capacity_iops,tag,disk_used_capacity,disk_reserved_capacity from storage_pool_view where id=2 \G 1. row -- id: 2 uuid: 096b3b6e-481d-33b4-9b34-7178612a2535 name: SATA1 status: Up capacity_bytes: 5497289703424 capacity_iops: NULL tag: sata disk_used_capacity: 8235717357961 disk_reserved_capacity: 0 1 row in set (0.00 sec) mysql> mysql> select v.state, sum(v.size) from volumes v, vm_instance vm, vm_root_disk_tags d where v.instance_id=vm.id and d.vm_id=vm.id and d.root_disk_tag like 'sata' group by v.state; +---+---+ | state | sum(v.size) | +---+---+ | Destroy | 664646189056 | | Expunged | 5396626407424 | | Expunging | 2147483648 | | Ready| 402653184 | +---+---+ 4 rows in set (0.01 sec) I guess that the 'Ready' disk space = 402653184 it's 'Provisioned Space' in VMware. But what is 'Disk Allocated' size in CloludStack that equal to 7.49 TB ??? How CloudStack calculate that data??? This issue is similar to this which also wasn't resolved: http://comments.gmane.org/gmane.comp.apache.cloudstack.user/13848 was: Hello CloudStack community, I have found that in my environment CloudStack provide wrong data for Allocated Disk Space on SATA storage. CloudStack UI displayed: Disk Total 5.00 TB Disk Allocated7.49 TB I have looked to VMware side and found absolutely different data: Capacity: 5.00 TB Provisioned Space: 4.68 TB Free Space:3.70 TB 7.49 - 4.68 = 2.81 TB (CloudStack show allocated disk space on 2.81 TB more) That's data that I can get from database: mysql> select id,uuid,name,status,capacity_bytes,capacity_iops,tag,disk_used_capacity,disk_reserved_capacity from storage_pool_view where id=2 \G 1. row id: 2 uuid: 096b3b6e-481d-33b4-9b34-7178612a2535 name: SATA1 status: Up capacity_bytes: 5497289703424 capacity_iops: NULL tag: sata disk_used_capacity: 8235717357961 disk_reserved_capacity: 0 1 row in set (0.00 sec) mysql> mysql> select v.state, sum(v.size) from volumes v, vm_instance vm, vm_root_disk_tags d where v.instance_id=vm.id and d.vm_id=vm.id and d.root_disk_tag like 'sata' group by v.state; +---+---+ | state | sum(v.size) | +---+---+ | Destroy | 664646189056 | | Expunged | 5396626407424 | | Expunging | 2147483648 | | Ready| 402653184 | +---+---+ 4 rows in set (0.01 sec) I guess that the 'Ready' disk space = 402653184 it's 'Provisioned Space' in VMware. But what is 'Disk Allocated' size in CloludStack that equal to 7.49 TB ??? How CloudStack calculate that data??? This issue is similar to this which also wasn't resolved: http://comments.gmane.org/gmane.comp.apache.cloudstack.user/13848 > ClouStack calculate wrong allocated Primary Storage size > > > Key: CLOUDSTACK-7756 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7756 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.1 > Environment: VMware ESXi 5.1.0 >Reporter: Denis Finko > > Hello CloudStack community, > I have found that in my environment CloudStack provide wrong data for > Allocated Disk Space on SATA storage. > CloudStack UI displayed: > Disk Total 5.00 TB > Disk Allocated7.49 TB > I have looked to VMware side and found absolutely different data: > Capacity: 5.00 TB > Provisioned Space: 4.68 TB > Free Space:3.70 TB > 7.49 - 4.68 = 2.81 TB (CloudStack show allocated disk space on 2.81 TB more) > That's data that I can get from database: > mysql> select > id,uuid,name,status,capacity_bytes,capacity_iops,tag,disk_used_capacity,disk_reserved_capacity > from storage_pool_view where id=2 \G > 1. row > ---
[jira] [Updated] (CLOUDSTACK-7756) ClouStack calculate wrong allocated Primary Storage size
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Finko updated CLOUDSTACK-7756: Description: Hello CloudStack community, I have found that in my environment CloudStack provide wrong data for Allocated Disk Space on SATA storage. CloudStack UI displayed: Disk Total 5.00 TB Disk Allocated7.49 TB I have looked to VMware side and found absolutely different data: Capacity: 5.00 TB Provisioned Space: 4.68 TB Free Space:3.70 TB 7.49 - 4.68 = 2.81 TB (CloudStack show allocated disk space on 2.81 TB more) That's data that I can get from database: mysql> select id,uuid,name,status,capacity_bytes,capacity_iops,tag,disk_used_capacity,disk_reserved_capacity from storage_pool_view where id=2 \G *** 1. row id: 2 uuid: 096b3b6e-481d-33b4-9b34-7178612a2535 name: SATA1 status: Up capacity_bytes: 5497289703424 capacity_iops: NULL tag: sata disk_used_capacity: 8235717357961 disk_reserved_capacity: 0 1 row in set (0.00 sec) mysql> mysql> select v.state, sum(v.size) from volumes v, vm_instance vm, vm_root_disk_tags d where v.instance_id=vm.id and d.vm_id=vm.id and d.root_disk_tag like 'sata' group by v.state; +---+---+ | state | sum(v.size) | +---+---+ | Destroy | 664646189056 | | Expunged | 5396626407424 | | Expunging | 2147483648 | | Ready| 402653184 | +---+---+ 4 rows in set (0.01 sec) I guess that the 'Ready' disk space = 402653184 it's 'Provisioned Space' in VMware. But what is 'Disk Allocated' size in CloludStack that equal to 7.49 TB ??? How CloudStack calculate that data??? This issue is similar to this which also wasn't resolved: http://comments.gmane.org/gmane.comp.apache.cloudstack.user/13848 was: Hello CloudStack community, I have found that in my environment CloudStack provide wrong data for Allocated Disk Space on SATA storage. CloudStack UI displayed: Disk Total 5.00 TB Disk Allocated7.49 TB I have looked to VMware side and found absolutely different data: Capacity: 5.00 TB Provisioned Space: 4.68 TB Free Space:3.70 TB 7.49 - 4.68 = 2.81 TB (CloudStack show allocated disk space on 2.81 TB more) That's data that I can get from database: mysql> select id,uuid,name,status,capacity_bytes,capacity_iops,tag,disk_used_capacity,disk_reserved_capacity from storage_pool_view where id=2 \G id: 2 uuid: 096b3b6e-481d-33b4-9b34-7178612a2535 name: SATA1 status: Up capacity_bytes: 5497289703424 capacity_iops: NULL tag: sata disk_used_capacity: 8235717357961 disk_reserved_capacity: 0 1 row in set (0.00 sec) mysql> mysql> select v.state, sum(v.size) from volumes v, vm_instance vm, vm_root_disk_tags d where v.instance_id=vm.id and d.vm_id=vm.id and d.root_disk_tag like 'sata' group by v.state; +---+---+ | state | sum(v.size) | +---+---+ | Destroy | 664646189056 | | Expunged | 5396626407424 | | Expunging | 2147483648 | | Ready| 402653184 | +---+---+ 4 rows in set (0.01 sec) I guess that the 'Ready' disk space = 402653184 it's 'Provisioned Space' in VMware. But what is 'Disk Allocated' size in CloludStack that equal to 7.49 TB ??? How CloudStack calculate that data??? This issue is similar to this which also wasn't resolved: http://comments.gmane.org/gmane.comp.apache.cloudstack.user/13848 > ClouStack calculate wrong allocated Primary Storage size > > > Key: CLOUDSTACK-7756 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7756 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.1 > Environment: VMware ESXi 5.1.0 >Reporter: Denis Finko > > Hello CloudStack community, > I have found that in my environment CloudStack provide wrong data for > Allocated Disk Space on SATA storage. > CloudStack UI displayed: > Disk Total 5.00 TB > Disk Allocated7.49 TB > I have looked to VMware side and found absolutely different data: > Capacity: 5.00 TB > Provisioned Space: 4.68 TB > Free Space:3.70 TB > 7.49 - 4.68 = 2.81 TB (CloudStack show allocated disk space on 2.81 TB more) > That's data that I can get from database: > mysql> select > id,uuid,name,status,capacity_bytes,capacity_iops,tag,disk_used_capacity,disk_reserved_capacity > from storage_pool_view where id=2 \G > *** 1. row > id: 2 > uuid: 096b3b6e-481d-33b4-9b34-7178612a2535 > name: SATA1 > status: Up > capacity_bytes: 5497289703424 > capacity_iops: N
[jira] [Updated] (CLOUDSTACK-7756) ClouStack calculate wrong allocated Primary Storage size
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Finko updated CLOUDSTACK-7756: Description: Hello CloudStack community, I have found that in my environment CloudStack provide wrong data for Allocated Disk Space on SATA storage. CloudStack UI displayed: Disk Total 5.00 TB Disk Allocated7.49 TB I have looked to VMware side and found absolutely different data: Capacity: 5.00 TB Provisioned Space: 4.68 TB Free Space:3.70 TB 7.49 - 4.68 = 2.81 TB (CloudStack show allocated disk space on 2.81 TB more) That's data that I can get from database: mysql> select id,uuid,name,status,capacity_bytes,capacity_iops,tag,disk_used_capacity,disk_reserved_capacity from storage_pool_view where id=2 \G 1. row id: 2 uuid: 096b3b6e-481d-33b4-9b34-7178612a2535 name: SATA1 status: Up capacity_bytes: 5497289703424 capacity_iops: NULL tag: sata disk_used_capacity: 8235717357961 disk_reserved_capacity: 0 1 row in set (0.00 sec) mysql> mysql> select v.state, sum(v.size) from volumes v, vm_instance vm, vm_root_disk_tags d where v.instance_id=vm.id and d.vm_id=vm.id and d.root_disk_tag like 'sata' group by v.state; +---+---+ | state | sum(v.size) | +---+---+ | Destroy | 664646189056 | | Expunged | 5396626407424 | | Expunging | 2147483648 | | Ready| 402653184 | +---+---+ 4 rows in set (0.01 sec) I guess that the 'Ready' disk space = 402653184 it's 'Provisioned Space' in VMware. But what is 'Disk Allocated' size in CloludStack that equal to 7.49 TB ??? How CloudStack calculate that data??? This issue is similar to this which also wasn't resolved: http://comments.gmane.org/gmane.comp.apache.cloudstack.user/13848 was: Hello CloudStack community, I have found that in my environment CloudStack provide wrong data for Allocated Disk Space on SATA storage. CloudStack UI displayed: Disk Total 5.00 TB Disk Allocated7.49 TB I have looked to VMware side and found absolutely different data: Capacity: 5.00 TB Provisioned Space: 4.68 TB Free Space:3.70 TB 7.49 - 4.68 = 2.81 TB (CloudStack show allocated disk space on 2.81 TB more) That's data that I can get from database: mysql> select id,uuid,name,status,capacity_bytes,capacity_iops,tag,disk_used_capacity,disk_reserved_capacity from storage_pool_view where id=2 \G *** 1. row id: 2 uuid: 096b3b6e-481d-33b4-9b34-7178612a2535 name: SATA1 status: Up capacity_bytes: 5497289703424 capacity_iops: NULL tag: sata disk_used_capacity: 8235717357961 disk_reserved_capacity: 0 1 row in set (0.00 sec) mysql> mysql> select v.state, sum(v.size) from volumes v, vm_instance vm, vm_root_disk_tags d where v.instance_id=vm.id and d.vm_id=vm.id and d.root_disk_tag like 'sata' group by v.state; +---+---+ | state | sum(v.size) | +---+---+ | Destroy | 664646189056 | | Expunged | 5396626407424 | | Expunging | 2147483648 | | Ready| 402653184 | +---+---+ 4 rows in set (0.01 sec) I guess that the 'Ready' disk space = 402653184 it's 'Provisioned Space' in VMware. But what is 'Disk Allocated' size in CloludStack that equal to 7.49 TB ??? How CloudStack calculate that data??? This issue is similar to this which also wasn't resolved: http://comments.gmane.org/gmane.comp.apache.cloudstack.user/13848 > ClouStack calculate wrong allocated Primary Storage size > > > Key: CLOUDSTACK-7756 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7756 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.1 > Environment: VMware ESXi 5.1.0 >Reporter: Denis Finko > > Hello CloudStack community, > I have found that in my environment CloudStack provide wrong data for > Allocated Disk Space on SATA storage. > CloudStack UI displayed: > Disk Total 5.00 TB > Disk Allocated7.49 TB > I have looked to VMware side and found absolutely different data: > Capacity: 5.00 TB > Provisioned Space: 4.68 TB > Free Space:3.70 TB > 7.49 - 4.68 = 2.81 TB (CloudStack show allocated disk space on 2.81 TB more) > That's data that I can get from database: > mysql> select > id,uuid,name,status,capacity_bytes,capacity_iops,tag,disk_used_capacity,disk_reserved_capacity > from storage_pool_view where id=2 \G > 1. row > id: 2 > uuid: 096b3b6e-481d-33b4-9b34-7178612a2535 > name: SATA1 > status:
[jira] [Updated] (CLOUDSTACK-7756) ClouStack calculate wrong allocated Primary Storage size
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Finko updated CLOUDSTACK-7756: Description: Hello CloudStack community, I have found that in my environment CloudStack provide wrong data for Allocated Disk Space on SATA storage. CloudStack UI displayed: Disk Total 5.00 TB Disk Allocated7.49 TB I have looked to VMware side and found absolutely different data: Capacity: 5.00 TB Provisioned Space: 4.68 TB Free Space:3.70 TB 7.49 - 4.68 = 2.81 TB (CloudStack show allocated disk space on 2.81 TB more) That's data that I can get from database: mysql> select id,uuid,name,status,capacity_bytes,capacity_iops,tag,disk_used_capacity,disk_reserved_capacity from storage_pool_view where id=2 \G *** 1. row *** id: 2 uuid: 096b3b6e-481d-33b4-9b34-7178612a2535 name: SATA1 status: Up capacity_bytes: 5497289703424 capacity_iops: NULL tag: sata disk_used_capacity: 8235717357961 disk_reserved_capacity: 0 1 row in set (0.00 sec) mysql> mysql> select v.state, sum(v.size) from volumes v, vm_instance vm, vm_root_disk_tags d where v.instance_id=vm.id and d.vm_id=vm.id and d.root_disk_tag like 'sata' group by v.state; +---+---+ | state | sum(v.size) | +---+---+ | Destroy | 664646189056 | | Expunged | 5396626407424 | | Expunging | 2147483648 | | Ready| 402653184 | +---+---+ 4 rows in set (0.01 sec) I guess that the 'Ready' disk space = 402653184 it's 'Provisioned Space' in VMware. But what is 'Disk Allocated' size in CloludStack that equal to 7.49 TB ??? How CloudStack calculate that data??? This issue is similar to this which also wasn't resolved: http://comments.gmane.org/gmane.comp.apache.cloudstack.user/13848 was: Hello CloudStack community, I have found that in my environment CloudStack provide wrong data for Allocated Disk Space on SATA storage. CloudStack UI displayed: Disk Total 5.00 TB Disk Allocated7.49 TB I have looked to VMware side and found absolutely different data: Capacity: 5.00 TB Provisioned Space: 4.68 TB Free Space:3.70 TB 7.49 - 4.68 = 2.81 TB (CloudStack show allocated disk space on 2.81 TB more) That's data that I can get from database: mysql> select id,uuid,name,status,capacity_bytes,capacity_iops,tag,disk_used_capacity,disk_reserved_capacity from storage_pool_view where id=2 \G *** 1. row *** id: 2 uuid: 096b3b6e-481d-33b4-9b34-7178612a2535 name: SATA1 status: Up capacity_bytes: 5497289703424 capacity_iops: NULL tag: sata disk_used_capacity: 8235717357961 disk_reserved_capacity: 0 1 row in set (0.00 sec) mysql> mysql> select v.state, sum(v.size) from volumes v, vm_instance vm, vm_root_disk_tags d where v.instance_id=vm.id and d.vm_id=vm.id and d.root_disk_tag like 'sata' group by v.state; +---+---+ | state | sum(v.size) | +---+---+ | Destroy | 664646189056 | | Expunged | 5396626407424 | | Expunging | 2147483648 | | Ready| 402653184 | +---+---+ 4 rows in set (0.01 sec) I guess that the 'Ready' disk space = 402653184 it's 'Provisioned Space' in VMware. But what is 'Disk Allocated' size in CloludStack that equal to 7.49 TB ??? How CloudStack calculate that data??? This issue is similar to this which also wasn't resolved: http://comments.gmane.org/gmane.comp.apache.cloudstack.user/13848 > ClouStack calculate wrong allocated Primary Storage size > > > Key: CLOUDSTACK-7756 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7756 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.1 > Environment: VMware ESXi 5.1.0 >Reporter: Denis Finko > > Hello CloudStack community, > I have found that in my environment CloudStack provide wrong data for > Allocated Disk Space on SATA storage. > CloudStack UI displayed: > Disk Total 5.00 TB > Disk Allocated7.49 TB > I have looked to VMware side and found absolutely different data: > Capacity: 5.00 TB > Provisioned Space: 4.68 TB > Free Space:3.70 TB > 7.49 - 4.68 = 2.81 TB (CloudStack show allocated disk space on 2.81 TB more) > That's data that I can get from database: > mysql> select > id,uuid,name,status,capacity_bytes,capacity_iops,tag,disk_used_capacity,disk_reserved_capacity > fro
[jira] [Updated] (CLOUDSTACK-7756) ClouStack calculate wrong allocated Primary Storage size
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Finko updated CLOUDSTACK-7756: Description: Hello CloudStack community, I have found that in my environment CloudStack provide wrong data for Allocated Disk Space on SATA storage. CloudStack UI displayed: Disk Total 5.00 TB Disk Allocated7.49 TB I have looked to VMware side and found absolutely different data: Capacity: 5.00 TB Provisioned Space: 4.68 TB Free Space:3.70 TB 7.49 - 4.68 = 2.81 TB (CloudStack show allocated disk space on 2.81 TB more) That's data that I can get from database: mysql> select id,uuid,name,status,capacity_bytes,capacity_iops,tag,disk_used_capacity,disk_reserved_capacity from storage_pool_view where id=2 \G id: 2 uuid: 096b3b6e-481d-33b4-9b34-7178612a2535 name: SATA1 status: Up capacity_bytes: 5497289703424 capacity_iops: NULL tag: sata disk_used_capacity: 8235717357961 disk_reserved_capacity: 0 1 row in set (0.00 sec) mysql> mysql> select v.state, sum(v.size) from volumes v, vm_instance vm, vm_root_disk_tags d where v.instance_id=vm.id and d.vm_id=vm.id and d.root_disk_tag like 'sata' group by v.state; +---+---+ | state | sum(v.size) | +---+---+ | Destroy | 664646189056 | | Expunged | 5396626407424 | | Expunging | 2147483648 | | Ready| 402653184 | +---+---+ 4 rows in set (0.01 sec) I guess that the 'Ready' disk space = 402653184 it's 'Provisioned Space' in VMware. But what is 'Disk Allocated' size in CloludStack that equal to 7.49 TB ??? How CloudStack calculate that data??? This issue is similar to this which also wasn't resolved: http://comments.gmane.org/gmane.comp.apache.cloudstack.user/13848 was: Hello CloudStack community, I have found that in my environment CloudStack provide wrong data for Allocated Disk Space on SATA storage. CloudStack UI displayed: Disk Total 5.00 TB Disk Allocated7.49 TB I have looked to VMware side and found absolutely different data: Capacity: 5.00 TB Provisioned Space: 4.68 TB Free Space:3.70 TB 7.49 - 4.68 = 2.81 TB (CloudStack show allocated disk space on 2.81 TB more) That's data that I can get from database: mysql> select id,uuid,name,status,capacity_bytes,capacity_iops,tag,disk_used_capacity,disk_reserved_capacity from storage_pool_view where id=2 \G *** 1. row *** id: 2 uuid: 096b3b6e-481d-33b4-9b34-7178612a2535 name: SATA1 status: Up capacity_bytes: 5497289703424 capacity_iops: NULL tag: sata disk_used_capacity: 8235717357961 disk_reserved_capacity: 0 1 row in set (0.00 sec) mysql> mysql> select v.state, sum(v.size) from volumes v, vm_instance vm, vm_root_disk_tags d where v.instance_id=vm.id and d.vm_id=vm.id and d.root_disk_tag like 'sata' group by v.state; +---+---+ | state | sum(v.size) | +---+---+ | Destroy | 664646189056 | | Expunged | 5396626407424 | | Expunging | 2147483648 | | Ready| 402653184 | +---+---+ 4 rows in set (0.01 sec) I guess that the 'Ready' disk space = 402653184 it's 'Provisioned Space' in VMware. But what is 'Disk Allocated' size in CloludStack that equal to 7.49 TB ??? How CloudStack calculate that data??? This issue is similar to this which also wasn't resolved: http://comments.gmane.org/gmane.comp.apache.cloudstack.user/13848 > ClouStack calculate wrong allocated Primary Storage size > > > Key: CLOUDSTACK-7756 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7756 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.1 > Environment: VMware ESXi 5.1.0 >Reporter: Denis Finko > > Hello CloudStack community, > I have found that in my environment CloudStack provide wrong data for > Allocated Disk Space on SATA storage. > CloudStack UI displayed: > Disk Total 5.00 TB > Disk Allocated7.49 TB > I have looked to VMware side and found absolutely different data: > Capacity: 5.00 TB > Provisioned Space: 4.68 TB > Free Space:3.70 TB > 7.49 - 4.68 = 2.81 TB (CloudStack show allocated disk space on 2.81 TB more) > That's data that I can get from database: > mysql> select > id,uuid,name,status,capacity_bytes,capacity_iops,tag,disk_used_capacity,disk_reserved_capacity > from storage_pool_view where id=2 \G > id: 2 > uuid: 096b3b6e-481d-33b4-9b34-7178612a2535 > name: SATA1 > status: Up > capacity_bytes: 5497289703424 > capacity_iops: NULL > tag:
[jira] [Created] (CLOUDSTACK-7756) ClouStack calculate wrong allocated Primary Storage size
Denis Finko created CLOUDSTACK-7756: --- Summary: ClouStack calculate wrong allocated Primary Storage size Key: CLOUDSTACK-7756 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7756 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.2.1 Environment: VMware ESXi 5.1.0 Reporter: Denis Finko Hello CloudStack community, I have found that in my environment CloudStack provide wrong data for Allocated Disk Space on SATA storage. CloudStack UI displayed: Disk Total 5.00 TB Disk Allocated7.49 TB I have looked to VMware side and found absolutely different data: Capacity: 5.00 TB Provisioned Space: 4.68 TB Free Space:3.70 TB 7.49 - 4.68 = 2.81 TB (CloudStack show allocated disk space on 2.81 TB more) That's data that I can get from database: mysql> select id,uuid,name,status,capacity_bytes,capacity_iops,tag,disk_used_capacity,disk_reserved_capacity from storage_pool_view where id=2 \G *** 1. row *** id: 2 uuid: 096b3b6e-481d-33b4-9b34-7178612a2535 name: SATA1 status: Up capacity_bytes: 5497289703424 capacity_iops: NULL tag: sata disk_used_capacity: 8235717357961 disk_reserved_capacity: 0 1 row in set (0.00 sec) mysql> mysql> select v.state, sum(v.size) from volumes v, vm_instance vm, vm_root_disk_tags d where v.instance_id=vm.id and d.vm_id=vm.id and d.root_disk_tag like 'sata' group by v.state; +---+---+ | state | sum(v.size) | +---+---+ | Destroy | 664646189056 | | Expunged | 5396626407424 | | Expunging | 2147483648 | | Ready| 402653184 | +---+---+ 4 rows in set (0.01 sec) I guess that the 'Ready' disk space = 402653184 it's 'Provisioned Space' in VMware. But what is 'Disk Allocated' size in CloludStack that equal to 7.49 TB ??? How CloudStack calculate that data??? This issue is similar to this which also wasn't resolved: http://comments.gmane.org/gmane.comp.apache.cloudstack.user/13848 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7755) Systems VMs restarting continuously on KVM host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavan Kumar Bandarupally updated CLOUDSTACK-7755: - Attachment: management-server.log agent.log > Systems VMs restarting continuously on KVM host > --- > > Key: CLOUDSTACK-7755 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7755 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, SystemVM >Affects Versions: 4.5.0 > Environment: Latest 4.5 build. with kvm host. >Reporter: Pavan Kumar Bandarupally >Priority: Blocker > Fix For: 4.5.0 > > Attachments: agent.log, management-server.log > > > After initial zone creation the system VMs are up for some time and are > continuously rebooting for some reason. There is no exception in the logs at > all. There is just a VM start command and start answer. > We can't do any operations if the system VMs are rebooting continuously. > Attached MS log. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7755) Systems VMs restarting continuously on KVM host
Pavan Kumar Bandarupally created CLOUDSTACK-7755: Summary: Systems VMs restarting continuously on KVM host Key: CLOUDSTACK-7755 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7755 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM, SystemVM Affects Versions: 4.5.0 Environment: Latest 4.5 build. with kvm host. Reporter: Pavan Kumar Bandarupally Priority: Blocker Fix For: 4.5.0 After initial zone creation the system VMs are up for some time and are continuously rebooting for some reason. There is no exception in the logs at all. There is just a VM start command and start answer. We can't do any operations if the system VMs are rebooting continuously. Attached MS log. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
