[jira] [Commented] (CLOUDSTACK-7535) [Automation][HyperV] SSH Client tries to connect to the private Guest IP Address instead of Public IP Address
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131155#comment-14131155
]
Sanjeev N commented on CLOUDSTACK-7535:
---
Hi Chandan,
Script is trying to ssh to the public IP address but inside the script while
printing the error message in case of ssh failure it is using VM's nic ip
address instead of ssh ip address .
try:
ssh_client = self.virtual_machine.get_ssh_client()
except Exception as e:
self.fail(SSH failed for virtual machine: %s - %s %
(self.virtual_machine.ipaddress, e))
In self.fail method vm ipaddress is being used insted of nat ip address.
[Automation][HyperV] SSH Client tries to connect to the private Guest IP
Address instead of Public IP Address
-
Key: CLOUDSTACK-7535
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7535
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Sanjeev N
Priority: Critical
Fix For: 4.5.0
Following two BVT Testcases in two different test suites fail with the same
root cause:
1. test_04_change_offering_small in test_service_offerings.py
2. test_10_attachAndDetach_iso
{noformat}
2014-09-09 05:33:30,778 - DEBUG - Sending GET Cmd :
listVirtualMachines===
2014-09-09 05:33:30,807 - DEBUG - Response : [{domain : u'ROOT', domainid :
u'9df0ddd4-37d3-11e4-a979-ba3c937e668f', haenable : False, templatename :
u'CentOS 6.4(64-bit) GUI (Hyperv)', securitygroup : [], zoneid :
u'd41a93cd-7b6c-432b-9ad4-eb89d8b6e95c', cpunumber : 1, ostypeid : 182,
passwordenabled : False, instancename : u'i-23-43-VM', id :
u'21ca01e4-e737-4a06-a560-5c558387acb0', networkkbswrite : 1, hostname :
u'10.220.163.50', displayvm : True, state : u'Running', guestosid :
u'9e0ec9f2-37d3-11e4-a979-ba3c937e668f', cpuused : u'9%', memory : 256,
serviceofferingid : u'a178853a-56fb-484a-992c-30af0d3ef72b', zonename :
u'XenRT-Zone-0', isdynamicallyscalable : False, displayname : u'testserver',
tags : [], nic : [{networkid : u'e46b21a7-e4a3-4a10-ae1b-bce7a9d1d90e',
macaddress : u'02:00:34:f7:00:01', isolationuri : u'vlan://3027', type :
u'Isolated', broadcasturi : u'vlan://3027', traffictype : u'Guest', netmask :
u'255.255.255.0', ipaddress : u'192.168.200.120', id :
u'970f3e6a-c36c-485d-a891-c89cc743f969', networkname :
u'test-a-TestServiceOfferings-test_01_create_service_offering-MSR9BE-network',
gateway : u'192.168.200.1', isdefault : True}], cpuspeed : 100, templateid :
u'9df665f6-37d3-11e4-a979-ba3c937e668f', affinitygroup : [], account :
u'test-a-TestServiceOfferings-test_01_create_service_offering-MSR9BE', hostid
: u'e0e128e6-3efc-4080-8d50-c710d33854b8', name :
u'VM-21ca01e4-e737-4a06-a560-5c558387acb0', networkkbsread : 1, created :
u'2014-09-09T05:27:17+', hypervisor : u'Hyperv', rootdevicetype :
u'ROOT', rootdeviceid : 0, serviceofferingname : u'Small Instance',
templatedisplaytext : u'CentOS 6.4 (64-bit) GUI (Hyperv)'}]
2014-09-09 05:33:30,807 - DEBUG - VM state: Running
2014-09-09 05:44:34,402 - CRITICAL - FAILED: test_04_change_offering_small:
['Traceback (most recent call last):\n', ' File
/usr/lib/python2.7/unittest/case.py, line 332, in run\ntestMethod()\n',
' File /root/cloudstack/test/integration/smoke/test_service_offerings.py,
line 326, in test_04_change_offering_small\n
(self.medium_virtual_machine.ipaddress, e)\n', ' File
/usr/lib/python2.7/unittest/case.py, line 413, in fail\nraise
self.failureException(msg)\n', 'AssertionError: SSH Access failed for
*192.168.200.120: SSH connection has Failed.* Waited 600s. Error is SSH
Connection Failed\n']
2014-09-09 05:44:34,412 - DEBUG - TestCaseName:
test_04_change_offering_small; Time Taken: 678 Seconds; StartTime: Tue Sep 9
05:33:15 2014; EndTime: Tue Sep 9 05:44:34 2014; Result: FAILED
{noformat}
{noformat}
014-09-09 05:37:23,158 - CRITICAL - FAILED: test_10_attachAndDetach_iso:
['Traceback (most recent call last):\n', ' File
/usr/lib/python2.7/unittest/case.py, line 332, in run\ntestMethod()\n',
' File /root/cloudstack/test/integration/smoke/test_vm_life_cycle.py, line
692, in test_10_attachAndDetach_iso\n(self.virtual_machine.ipaddress,
e))\n', ' File /usr/lib/python2.7/unittest/case.py, line 413, in fail\n
raise self.failureException(msg)\n', 'AssertionError: SSH failed for virtual
machine: 192.168.200.149 - SSH connection has Failed. Waited 600s. Error is
SSH Connection Failed\n']
2014-09-09 05:37:23,166 -
[jira] [Commented] (CLOUDSTACK-6460) Migration of CLVM volumes to another primary storage fail
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131212#comment-14131212
]
darrentang commented on CLOUDSTACK-6460:
Anybody test it for cloudstack 4.3?
cloudstack-6460.patch doesn't work for cloudstack 4.3
Migration of CLVM volumes to another primary storage fail
-
Key: CLOUDSTACK-6460
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6460
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Volumes
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
Environment: KVM clusters with fiber channel SAN storage, CLVM volumes
Reporter: Salvatore Sciacco
Attachments: cloudstack-6460.patch, cloudstack-6460_44.patch
ACS version: 4.2.1
Hypervisors: KVM
Storage pool type: CLVM
Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary
storage pool fail. I've enabled debug on the agents side and I think there is
a problem with the format type conversion
Volume on database had format QCOW2
these are the parameters for the first step (CLVM - NFS):
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:
uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
{quote}
Those commads are translated into the agent:
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing:
/bin/bash -c cp -f /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
/mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
{quote}
With the result that the output file isn't a qcow2 file but a raw partition,
which in turn make the next step fail.
(NFS - CLVM)
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
info
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
convert -f qcow2 -O raw
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
/dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not
open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to
convert
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was:
qemu-img: Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
{quote}
If I change on the database the format of the volume to RAW the effect is
even worse as data is lost in the process!
These are the parameter for the first step (CLVM = NFS)
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:655d6965-b3f3-4118-a970d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450
,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-4024450VM,accountId:402,format:RAW,id:5937,hypervisorType:KVM
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
[jira] [Created] (CLOUDSTACK-7538) Can not remove the vm nic due to there is another vm with same internal ip having port forwording rule
Wei Zhou created CLOUDSTACK-7538: Summary: Can not remove the vm nic due to there is another vm with same internal ip having port forwording rule Key: CLOUDSTACK-7538 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7538 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Wei Zhou Assignee: Wei Zhou When I tried to remove a nic from a VM, an exception raised: 2014-09-08 10:07:12,847 ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-109:job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ]) Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.RemoveNicFromVMCmd com.cloud.utils.exception.CloudRuntimeException: Failed to remove nic from VM[User|CentOS65] in Ntwk[300|Guest|1], nic has associated Port forwarding or Load balancer or Static NAT rules. at com.cloud.vm.VirtualMachineManagerImpl.removeNicFromVm(VirtualMachineManagerImpl.java:3129) at com.cloud.vm.UserVmManagerImpl.removeNicFromVirtualMachine(UserVmManagerImpl.java:1068) at org.apache.cloudstack.api.command.user.vm.RemoveNicFromVMCmd.execute(RemoveNicFromVMCmd.java:103) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:701) 2014-09-08 10:07:12,849 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-109:job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ]) Complete async job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ], jobStatus: 2, resultCode: 530, result: Error Code: 530 Error text: Failed to remove nic from VM[User|CentOS65] in Ntwk[300|Guest|1], nic has associated Port forwarding or Load balancer or Static NAT rules. This is because there is another vm (with same internal ip) having port forward rules . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7538) Can not remove the vm nic due to there is another vm with same internal ip having port forwording rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Zhou updated CLOUDSTACK-7538: - Affects Version/s: 4.5.0 4.4.0 Can not remove the vm nic due to there is another vm with same internal ip having port forwording rule -- Key: CLOUDSTACK-7538 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7538 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0, 4.5.0 Reporter: Wei Zhou Assignee: Wei Zhou Fix For: 4.5.0, 4.4.1 When I tried to remove a nic from a VM, an exception raised: 2014-09-08 10:07:12,847 ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-109:job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ]) Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.RemoveNicFromVMCmd com.cloud.utils.exception.CloudRuntimeException: Failed to remove nic from VM[User|CentOS65] in Ntwk[300|Guest|1], nic has associated Port forwarding or Load balancer or Static NAT rules. at com.cloud.vm.VirtualMachineManagerImpl.removeNicFromVm(VirtualMachineManagerImpl.java:3129) at com.cloud.vm.UserVmManagerImpl.removeNicFromVirtualMachine(UserVmManagerImpl.java:1068) at org.apache.cloudstack.api.command.user.vm.RemoveNicFromVMCmd.execute(RemoveNicFromVMCmd.java:103) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:701) 2014-09-08 10:07:12,849 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-109:job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ]) Complete async job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ], jobStatus: 2, resultCode: 530, result: Error Code: 530 Error text: Failed to remove nic from VM[User|CentOS65] in Ntwk[300|Guest|1], nic has associated Port forwarding or Load balancer or Static NAT rules. This is because there is another vm (with same internal ip) having port forward rules . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7538) Can not remove the vm nic due to there is another vm with same internal ip having port forwording rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Zhou updated CLOUDSTACK-7538: - Fix Version/s: 4.4.1 4.5.0 Can not remove the vm nic due to there is another vm with same internal ip having port forwording rule -- Key: CLOUDSTACK-7538 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7538 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0, 4.5.0 Reporter: Wei Zhou Assignee: Wei Zhou Fix For: 4.5.0, 4.4.1 When I tried to remove a nic from a VM, an exception raised: 2014-09-08 10:07:12,847 ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-109:job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ]) Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.RemoveNicFromVMCmd com.cloud.utils.exception.CloudRuntimeException: Failed to remove nic from VM[User|CentOS65] in Ntwk[300|Guest|1], nic has associated Port forwarding or Load balancer or Static NAT rules. at com.cloud.vm.VirtualMachineManagerImpl.removeNicFromVm(VirtualMachineManagerImpl.java:3129) at com.cloud.vm.UserVmManagerImpl.removeNicFromVirtualMachine(UserVmManagerImpl.java:1068) at org.apache.cloudstack.api.command.user.vm.RemoveNicFromVMCmd.execute(RemoveNicFromVMCmd.java:103) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:701) 2014-09-08 10:07:12,849 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-109:job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ]) Complete async job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ], jobStatus: 2, resultCode: 530, result: Error Code: 530 Error text: Failed to remove nic from VM[User|CentOS65] in Ntwk[300|Guest|1], nic has associated Port forwarding or Load balancer or Static NAT rules. This is because there is another vm (with same internal ip) having port forward rules . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6570) API breakage of the UpdateUser API call
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland closed CLOUDSTACK-6570. - no news is good news? API breakage of the UpdateUser API call --- Key: CLOUDSTACK-6570 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6570 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Environment: Any, the UpdateUser API call is environment independent Reporter: Ove Ewerlid Assignee: Daan Hoogland Priority: Blocker Labels: easyfix Fix For: 4.4.0, 4.5.0 44 adds USER_API_KEY in ./api/src/org/apache/cloudstack/api/ApiConstants.java and changes the value of API_KEY. Since API_KEY value is exposed in the UpdateUser API, the API breaks. Up until 4.3, KEYs to UpdateUser were passed via parameters; * userapikey * usersecretkey with 44 this changes to; * apikey * usersecretkey -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7538) Can not remove the vm nic due to there is another vm with same internal ip having port forwording rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131279#comment-14131279 ] Saksham Srivastava commented on CLOUDSTACK-7538: https://issues.apache.org/jira/browse/CLOUDSTACK-6223 had tried to fix the issue, but I don't think the fix was complete. The query should be include networkid IMO. Can not remove the vm nic due to there is another vm with same internal ip having port forwording rule -- Key: CLOUDSTACK-7538 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7538 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0, 4.5.0 Reporter: Wei Zhou Assignee: Wei Zhou Fix For: 4.5.0, 4.4.1 When I tried to remove a nic from a VM, an exception raised: 2014-09-08 10:07:12,847 ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-109:job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ]) Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.RemoveNicFromVMCmd com.cloud.utils.exception.CloudRuntimeException: Failed to remove nic from VM[User|CentOS65] in Ntwk[300|Guest|1], nic has associated Port forwarding or Load balancer or Static NAT rules. at com.cloud.vm.VirtualMachineManagerImpl.removeNicFromVm(VirtualMachineManagerImpl.java:3129) at com.cloud.vm.UserVmManagerImpl.removeNicFromVirtualMachine(UserVmManagerImpl.java:1068) at org.apache.cloudstack.api.command.user.vm.RemoveNicFromVMCmd.execute(RemoveNicFromVMCmd.java:103) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:701) 2014-09-08 10:07:12,849 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-109:job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ]) Complete async job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ], jobStatus: 2, resultCode: 530, result: Error Code: 530 Error text: Failed to remove nic from VM[User|CentOS65] in Ntwk[300|Guest|1], nic has associated Port forwarding or Load balancer or Static NAT rules. This is because there is another vm (with same internal ip) having port forward rules . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6549) 4.4-forward: Management Server fails to start
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland closed CLOUDSTACK-6549. - tested 4.4-forward: Management Server fails to start - Key: CLOUDSTACK-6549 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6549 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Reporter: Prachi Damle Assignee: Daan Hoogland Priority: Blocker Fix For: 4.4.0 4.4-forward: Management Server fails to start Commit 3852afa717dc147ef9dc19d7b3801c341f321e77 that broke it. NetworkACLItemCidrsDao out of NetworkACLItemDao, but you forgot to add that into spring context xml file. You may need to add that into cloud-engine/schema/resources/META-INF/cloudstack/core/spring-engine-schema-core-daos-context.xml. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7538) Can not remove the vm nic due to there is another vm with same internal ip having port forwording rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131279#comment-14131279 ] Saksham Srivastava edited comment on CLOUDSTACK-7538 at 9/12/14 8:45 AM: - https://issues.apache.org/jira/browse/CLOUDSTACK-6223 had tried to fix the issue, but I don't think the fix was complete. The query should include networkid IMO. was (Author: saksham): https://issues.apache.org/jira/browse/CLOUDSTACK-6223 had tried to fix the issue, but I don't think the fix was complete. The query should be include networkid IMO. Can not remove the vm nic due to there is another vm with same internal ip having port forwording rule -- Key: CLOUDSTACK-7538 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7538 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0, 4.5.0 Reporter: Wei Zhou Assignee: Wei Zhou Fix For: 4.5.0, 4.4.1 When I tried to remove a nic from a VM, an exception raised: 2014-09-08 10:07:12,847 ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-109:job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ]) Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.RemoveNicFromVMCmd com.cloud.utils.exception.CloudRuntimeException: Failed to remove nic from VM[User|CentOS65] in Ntwk[300|Guest|1], nic has associated Port forwarding or Load balancer or Static NAT rules. at com.cloud.vm.VirtualMachineManagerImpl.removeNicFromVm(VirtualMachineManagerImpl.java:3129) at com.cloud.vm.UserVmManagerImpl.removeNicFromVirtualMachine(UserVmManagerImpl.java:1068) at org.apache.cloudstack.api.command.user.vm.RemoveNicFromVMCmd.execute(RemoveNicFromVMCmd.java:103) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:701) 2014-09-08 10:07:12,849 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-109:job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ]) Complete async job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ], jobStatus: 2, resultCode: 530, result: Error Code: 530 Error text: Failed to remove nic from VM[User|CentOS65] in Ntwk[300|Guest|1], nic has associated Port forwarding or Load balancer or Static NAT rules. This is because there is another vm (with same internal ip) having port forward rules . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6100) second private gateway on same nicira based network gets sourcenat even when not specified
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland closed CLOUDSTACK-6100. - no issue anymore second private gateway on same nicira based network gets sourcenat even when not specified -- Key: CLOUDSTACK-6100 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6100 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Daan Hoogland Fix For: 4.3.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6069) can't create privatgateway with vlan in a mixed network env
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland closed CLOUDSTACK-6069. - beautifying this behaviour is a new issue in itself can't create privatgateway with vlan in a mixed network env --- Key: CLOUDSTACK-6069 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6069 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller, Xen Affects Versions: 4.3.0 Environment: 1 zone, 1 pod, 1 cluster, 2 hosts (xen 6.0.2) 2 physnets - physnet 1 vlan based (Public, Guest(tagged vlan-based), Management, Storage) - physnet 2 nicira based (Guest (tagged nicira-based)) Reporter: Daan Hoogland Assignee: Daan Hoogland creating a private gateway on a vpc with a vlan fails. I get a 530 server error using marvin to create the net. in 4.2.1 this didn't happen 4.2.1 code (succeeding): 2014-02-10 15:43:45,621 DEBUG [xen.resource.CitrixResourceBase] (DirectAgent-4:null) Creating VLAN 322 on host 10.200.23.41 on device tunnel0 4.3.0 code (failing) 2014-02-10 17:33:51,083 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-4:ctx-6d5f0cd4) Creating VLAN 322 on host 10.200.23.42 on device tunnel0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6020) createPortForwardingRule failes for vmguestip above 127.255.255.255
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daan Hoogland closed CLOUDSTACK-6020.
-
no idea if ipv6 addresses can be smaller then or equal to (2L *
Integer.MAX_VALUE + 1)
if so open an issue and put it on my name; closing
createPortForwardingRule failes for vmguestip above 127.255.255.255
---
Key: CLOUDSTACK-6020
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6020
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API
Affects Versions: pre-4.0.0, 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0,
Future, 4.2.1, 4.1.2, 4.3.0, 4.4.0
Reporter: Joris van Lieshout
Assignee: Daan Hoogland
command=createPortForwardingRuleresponse=jsonsessionkey=FmHQb9oGmgKlM4ihB%2Fb2ik7p35E%3Dipaddressid=d29bebfe-edc1-406f-b4ed-7a49c6e7ee1fprivateport=80privateendport=80publicport=80publicendport=80protocol=tcpvirtualmachineid=cc5c9dc4-3eeb-4533-994a-0e2636a48a60openfirewall=falsevmguestip=192.168.1.30networkid=5e56227c-83c0-4b85-8a27-53343e806d12_=1391510423905
vmguestip=192.168.1.30
api/src/org/apache/cloudstack/api/command/user/firewall/CreatePortForwardingRuleCmd.java
@Parameter(name = ApiConstants.VM_GUEST_IP, type = CommandType.STRING,
required = false,
description = VM guest nic Secondary ip address for the port forwarding
rule)
private String vmSecondaryIp;
@Override
public void create() {
// cidr list parameter is deprecated
if (cidrlist != null) {
throw new InvalidParameterValueException(Parameter cidrList is
deprecated; if you need to open firewall rule for the specific cidr, please
refer to createFirewallRule command);
}
Ip privateIp = getVmSecondaryIp();
if (privateIp != null) {
if ( !privateIp.isIp4()) {
throw new InvalidParameterValueException(Invalid vm ip
address);
}
}
try {
PortForwardingRule result =
_rulesService.createPortForwardingRule(this, virtualMachineId, privateIp,
getOpenFirewall());
setEntityId(result.getId());
setEntityUuid(result.getUuid());
} catch (NetworkRuleConflictException ex) {
s_logger.info(Network rule conflict: , ex);
s_logger.trace(Network Rule Conflict: , ex);
throw new
ServerApiException(ApiErrorCode.NETWORK_RULE_CONFLICT_ERROR, ex.getMessage());
}
}
utils/src/com/cloud/utils/net/Ip.java
public boolean isIp4() {
return ip Integer.MAX_VALUE;
}
public Ip(String ip) {
this.ip = NetUtils.ip2Long(ip);
}
=== ip2long for 192.168.1.30 = 3232235806
=== Integer.MAX_VALUE = 231-1 = 2147483647
3232235806 (192.168.1.30) is therefore bigger then MAX_VALUE making isIp4()
return FALSE and throwing a InvalidParameterValueException…
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7538) Can not remove the vm nic due to there is another vm with same internal ip having port forwording rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131288#comment-14131288 ] Wei Zhou commented on CLOUDSTACK-7538: -- Hi Saksham, Thanks. good to hear that. I did not see any commit for fix this issue, so I thought nobody is working on this. I will close this issue. I Agree with your comment. But it looks a bit complicated, as there is no network_id in port_forward_rules table. -Wei Can not remove the vm nic due to there is another vm with same internal ip having port forwording rule -- Key: CLOUDSTACK-7538 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7538 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0, 4.5.0 Reporter: Wei Zhou Assignee: Wei Zhou Fix For: 4.5.0, 4.4.1 When I tried to remove a nic from a VM, an exception raised: 2014-09-08 10:07:12,847 ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-109:job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ]) Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.RemoveNicFromVMCmd com.cloud.utils.exception.CloudRuntimeException: Failed to remove nic from VM[User|CentOS65] in Ntwk[300|Guest|1], nic has associated Port forwarding or Load balancer or Static NAT rules. at com.cloud.vm.VirtualMachineManagerImpl.removeNicFromVm(VirtualMachineManagerImpl.java:3129) at com.cloud.vm.UserVmManagerImpl.removeNicFromVirtualMachine(UserVmManagerImpl.java:1068) at org.apache.cloudstack.api.command.user.vm.RemoveNicFromVMCmd.execute(RemoveNicFromVMCmd.java:103) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:701) 2014-09-08 10:07:12,849 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-109:job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ]) Complete async job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ], jobStatus: 2, resultCode: 530, result: Error Code: 530 Error text: Failed to remove nic from VM[User|CentOS65] in Ntwk[300|Guest|1], nic has associated Port forwarding or Load balancer or Static NAT rules. This is because there is another vm (with same internal ip) having port forward rules . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-5979) nicira service offering with sourcenat fails
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland closed CLOUDSTACK-5979. - AFAICT nicira service offering with sourcenat fails Key: CLOUDSTACK-5979 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5979 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Devices Affects Versions: 4.3.0 Reporter: Daan Hoogland Assignee: Daan Hoogland Fix For: 4.3.0 Setup: XenServer 6.2 hypervisors Nicira 4.0.0 CloudStack 4.3.0 Testcase: Network Offering Nicira-l3 (dhcp, dns, userdata: vrouter static nat, source nat, port forward,connectivity: niciranvp) Create network using Nicira-l3 offering Deploy virtual machine using default template in Nicira-l3 offering - FAILED Stacktrace: 2014-01-29 15:54:11,584 ERROR [c.c.v.VirtualMachineManagerImpl] (Job-Executor-22:ctx-1677e42a ctx-abf178de) Failed to start instanc e VM[User|nicira-l3-host] java.lang.NumberFormatException: For input string: vlan://317 at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Long.parseLong(Long.java:441) at java.lang.Long.parseLong(Long.java:483) at com.cloud.network.element.NiciraNvpElement.implement(NiciraNvpElement.java:262) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetworkElementsAndResources(NetworkOrchestrator. java:1053) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-5886) 4.2.1 upgrade fails on acl migration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland closed CLOUDSTACK-5886. - 4.2.1 upgrade fails on acl migration Key: CLOUDSTACK-5886 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5886 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.1 Reporter: Daan Hoogland Assignee: Daan Hoogland Fix For: 4.3.0 On upgrading from 4.1.1 to 4.2.1 a bug happens during the migration of firewall_rules_cidrs.source_cidr to network_acl_item.cidr. The source_cidrs are concatenated into a 255 width field. We are using cidr lists that are way longer. As a quick fix we can now set the size of the field to 2048. a quick test learns us that the field is truncated as it is saved in the db. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-5979) nicira service offering with sourcenat fails
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131287#comment-14131287 ] Daan Hoogland edited comment on CLOUDSTACK-5979 at 9/12/14 8:51 AM: AFAICT (tested in production environment) was (Author: dahn): AFAICT nicira service offering with sourcenat fails Key: CLOUDSTACK-5979 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5979 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Devices Affects Versions: 4.3.0 Reporter: Daan Hoogland Assignee: Daan Hoogland Fix For: 4.3.0 Setup: XenServer 6.2 hypervisors Nicira 4.0.0 CloudStack 4.3.0 Testcase: Network Offering Nicira-l3 (dhcp, dns, userdata: vrouter static nat, source nat, port forward,connectivity: niciranvp) Create network using Nicira-l3 offering Deploy virtual machine using default template in Nicira-l3 offering - FAILED Stacktrace: 2014-01-29 15:54:11,584 ERROR [c.c.v.VirtualMachineManagerImpl] (Job-Executor-22:ctx-1677e42a ctx-abf178de) Failed to start instanc e VM[User|nicira-l3-host] java.lang.NumberFormatException: For input string: vlan://317 at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Long.parseLong(Long.java:441) at java.lang.Long.parseLong(Long.java:483) at com.cloud.network.element.NiciraNvpElement.implement(NiciraNvpElement.java:262) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetworkElementsAndResources(NetworkOrchestrator. java:1053) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7538) Can not remove the vm nic due to there is another vm with same internal ip having port forwording rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Zhou closed CLOUDSTACK-7538. Resolution: Fixed Can not remove the vm nic due to there is another vm with same internal ip having port forwording rule -- Key: CLOUDSTACK-7538 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7538 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0, 4.5.0 Reporter: Wei Zhou Assignee: Wei Zhou Fix For: 4.5.0, 4.4.1 When I tried to remove a nic from a VM, an exception raised: 2014-09-08 10:07:12,847 ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-109:job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ]) Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.RemoveNicFromVMCmd com.cloud.utils.exception.CloudRuntimeException: Failed to remove nic from VM[User|CentOS65] in Ntwk[300|Guest|1], nic has associated Port forwarding or Load balancer or Static NAT rules. at com.cloud.vm.VirtualMachineManagerImpl.removeNicFromVm(VirtualMachineManagerImpl.java:3129) at com.cloud.vm.UserVmManagerImpl.removeNicFromVirtualMachine(UserVmManagerImpl.java:1068) at org.apache.cloudstack.api.command.user.vm.RemoveNicFromVMCmd.execute(RemoveNicFromVMCmd.java:103) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:701) 2014-09-08 10:07:12,849 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-109:job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ]) Complete async job-11939 = [ 5c3c0d5b-6b48-45fe-ad36-a0aea13479c4 ], jobStatus: 2, resultCode: 530, result: Error Code: 530 Error text: Failed to remove nic from VM[User|CentOS65] in Ntwk[300|Guest|1], nic has associated Port forwarding or Load balancer or Static NAT rules. This is because there is another vm (with same internal ip) having port forward rules . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-5502) [Automation] createVlanIpRange API failing, if you pass VLAN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daan Hoogland closed CLOUDSTACK-5502.
-
tested in production systems around the world :P
[Automation] createVlanIpRange API failing, if you pass VLAN
-
Key: CLOUDSTACK-5502
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5502
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Affects Versions: 4.3.0
Environment: KVM Basic Zone with SG
Reporter: Rayees Namathponnan
Assignee: Daan Hoogland
Priority: Blocker
Fix For: 4.3.0
This issue found in KVM basic zone with SG automation run; test cases from
below suite filed
integration.component.test_multiple_ip_ranges.
Steps to reproduce
Step 1 : Create basic zone with SG
Step 2 : Crete IP VLAN Range with below command (pass vlan=untagged)
http://xxx..xxx.xxx:8096/?command=createVlanIpRangegateway=10.223.251.1forvirtualnetwork=falsestartip=10.223.251.3podid=0253bcbf-e636-4776-9e8c-216b70d195a2zoneid=a9912aa8-a231-44d9-a70b-9d53e6db2d27netmask=255.255.255.192vlan=untagged
Result;
API command failed with error
{ createvlaniprangeresponse :
{uuidList:[],errorcode:431,cserrorcode:4350,errortext:Vlan doesn't
match vlan of the network} }
this API command works only, if you are not passing any VLAN
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-4347) modify planning and provisioning code to accept a lswitch network for a vpc gateway
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland closed CLOUDSTACK-4347. - no-op modify planning and provisioning code to accept a lswitch network for a vpc gateway --- Key: CLOUDSTACK-4347 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4347 Project: CloudStack Issue Type: Sub-task Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller, Network Devices Reporter: Daan Hoogland Assignee: Daan Hoogland Fix For: 4.3.0 modify planning and provisioning code to accept a lswitch network for a vpc gateway -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-4347) modify planning and provisioning code to accept a lswitch network for a vpc gateway
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-4347: -- Fix Version/s: (was: Future) 4.3.0 modify planning and provisioning code to accept a lswitch network for a vpc gateway --- Key: CLOUDSTACK-4347 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4347 Project: CloudStack Issue Type: Sub-task Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller, Network Devices Reporter: Daan Hoogland Assignee: Daan Hoogland Fix For: 4.3.0 modify planning and provisioning code to accept a lswitch network for a vpc gateway -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6020) createPortForwardingRule failes for vmguestip above 127.255.255.255
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daan Hoogland updated CLOUDSTACK-6020:
--
Fix Version/s: 4.4.0
createPortForwardingRule failes for vmguestip above 127.255.255.255
---
Key: CLOUDSTACK-6020
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6020
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API
Affects Versions: pre-4.0.0, 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0,
Future, 4.2.1, 4.1.2, 4.3.0, 4.4.0
Reporter: Joris van Lieshout
Assignee: Daan Hoogland
Fix For: 4.4.0
command=createPortForwardingRuleresponse=jsonsessionkey=FmHQb9oGmgKlM4ihB%2Fb2ik7p35E%3Dipaddressid=d29bebfe-edc1-406f-b4ed-7a49c6e7ee1fprivateport=80privateendport=80publicport=80publicendport=80protocol=tcpvirtualmachineid=cc5c9dc4-3eeb-4533-994a-0e2636a48a60openfirewall=falsevmguestip=192.168.1.30networkid=5e56227c-83c0-4b85-8a27-53343e806d12_=1391510423905
vmguestip=192.168.1.30
api/src/org/apache/cloudstack/api/command/user/firewall/CreatePortForwardingRuleCmd.java
@Parameter(name = ApiConstants.VM_GUEST_IP, type = CommandType.STRING,
required = false,
description = VM guest nic Secondary ip address for the port forwarding
rule)
private String vmSecondaryIp;
@Override
public void create() {
// cidr list parameter is deprecated
if (cidrlist != null) {
throw new InvalidParameterValueException(Parameter cidrList is
deprecated; if you need to open firewall rule for the specific cidr, please
refer to createFirewallRule command);
}
Ip privateIp = getVmSecondaryIp();
if (privateIp != null) {
if ( !privateIp.isIp4()) {
throw new InvalidParameterValueException(Invalid vm ip
address);
}
}
try {
PortForwardingRule result =
_rulesService.createPortForwardingRule(this, virtualMachineId, privateIp,
getOpenFirewall());
setEntityId(result.getId());
setEntityUuid(result.getUuid());
} catch (NetworkRuleConflictException ex) {
s_logger.info(Network rule conflict: , ex);
s_logger.trace(Network Rule Conflict: , ex);
throw new
ServerApiException(ApiErrorCode.NETWORK_RULE_CONFLICT_ERROR, ex.getMessage());
}
}
utils/src/com/cloud/utils/net/Ip.java
public boolean isIp4() {
return ip Integer.MAX_VALUE;
}
public Ip(String ip) {
this.ip = NetUtils.ip2Long(ip);
}
=== ip2long for 192.168.1.30 = 3232235806
=== Integer.MAX_VALUE = 231-1 = 2147483647
3232235806 (192.168.1.30) is therefore bigger then MAX_VALUE making isIp4()
return FALSE and throwing a InvalidParameterValueException…
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7277) [Hyper-V] Remove the Hyper-V Agent service dependency on english locale to sync VMs properly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-7277. -- [Hyper-V] Remove the Hyper-V Agent service dependency on english locale to sync VMs properly Key: CLOUDSTACK-7277 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7277 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Reporter: Anshul Gangwar Assignee: Anshul Gangwar [Hyper-V] if the Hyper-V Agent service is running with different locale other than english then the vms are not syncing up properly and are reported in power off state -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7503) [Hyper-V] Logging meaningless response string from Hyper-v Agent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-7503. -- [Hyper-V] Logging meaningless response string from Hyper-v Agent Key: CLOUDSTACK-7503 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7503 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Logging meaningless response string from Hyper-v Agent -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CLOUDSTACK-6069) can't create privatgateway with vlan in a mixed network env
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland reopened CLOUDSTACK-6069: --- should be closed as won't fix or not an issue or such can't create privatgateway with vlan in a mixed network env --- Key: CLOUDSTACK-6069 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6069 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller, Xen Affects Versions: 4.3.0 Environment: 1 zone, 1 pod, 1 cluster, 2 hosts (xen 6.0.2) 2 physnets - physnet 1 vlan based (Public, Guest(tagged vlan-based), Management, Storage) - physnet 2 nicira based (Guest (tagged nicira-based)) Reporter: Daan Hoogland Assignee: Daan Hoogland creating a private gateway on a vpc with a vlan fails. I get a 530 server error using marvin to create the net. in 4.2.1 this didn't happen 4.2.1 code (succeeding): 2014-02-10 15:43:45,621 DEBUG [xen.resource.CitrixResourceBase] (DirectAgent-4:null) Creating VLAN 322 on host 10.200.23.41 on device tunnel0 4.3.0 code (failing) 2014-02-10 17:33:51,083 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-4:ctx-6d5f0cd4) Creating VLAN 322 on host 10.200.23.42 on device tunnel0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7234) [Hyper-V] Stop sending SMB credentials to Hyper-V Agent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-7234. -- [Hyper-V] Stop sending SMB credentials to Hyper-V Agent --- Key: CLOUDSTACK-7234 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7234 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar We no longer uses SMB credentials on Hyper-V Agent so we are stopping to send SMB credentials to Hyper-V -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7236) [Hyper-V] improve logging in HostVmStateReportCommand in Hyper-V Agent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-7236. -- now logging the response returned to management server [Hyper-V] improve logging in HostVmStateReportCommand in Hyper-V Agent -- Key: CLOUDSTACK-7236 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7236 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar improve logging in HostVmStateReportCommand in Hyper-V Agent. Currently it is not logging what is returned in the answer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7235) [Hyper-V] ModifyStoragePoolCommand returns unsupported command answer if provided wrong path
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-7235. -- [Hyper-V] ModifyStoragePoolCommand returns unsupported command answer if provided wrong path Key: CLOUDSTACK-7235 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7235 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar ModifyStoragePoolCommand returns unsupported command answer if provided wrong path -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7220) [Hyper-V] Hyper-V Agent is broken in 4.4 branch
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-7220. -- [Hyper-V] Hyper-V Agent is broken in 4.4 branch --- Key: CLOUDSTACK-7220 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7220 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Blocker While cherry picking commits are not applied in correct order -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6069) can't create privatgateway with vlan in a mixed network env
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland closed CLOUDSTACK-6069. - Resolution: Later can't create privatgateway with vlan in a mixed network env --- Key: CLOUDSTACK-6069 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6069 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller, Xen Affects Versions: 4.3.0 Environment: 1 zone, 1 pod, 1 cluster, 2 hosts (xen 6.0.2) 2 physnets - physnet 1 vlan based (Public, Guest(tagged vlan-based), Management, Storage) - physnet 2 nicira based (Guest (tagged nicira-based)) Reporter: Daan Hoogland Assignee: Daan Hoogland creating a private gateway on a vpc with a vlan fails. I get a 530 server error using marvin to create the net. in 4.2.1 this didn't happen 4.2.1 code (succeeding): 2014-02-10 15:43:45,621 DEBUG [xen.resource.CitrixResourceBase] (DirectAgent-4:null) Creating VLAN 322 on host 10.200.23.41 on device tunnel0 4.3.0 code (failing) 2014-02-10 17:33:51,083 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-4:ctx-6d5f0cd4) Creating VLAN 322 on host 10.200.23.42 on device tunnel0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6968) Allow Cluster scope volumes to attach to any VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-6968. -- Allow Cluster scope volumes to attach to any VM --- Key: CLOUDSTACK-6968 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6968 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 Currently cluster scope volumes are failed to attach to VM if the vm is not in same cluster as volumes. This will relax that restriction. This makes more sense as we allow zone wide primary store to attach to any VM. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6965) Fix for CLOUDSTACK-6935 introduces the NullPointerException in ZoneWideStorageAllocator filter method
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-6965. -- Fix for CLOUDSTACK-6935 introduces the NullPointerException in ZoneWideStorageAllocator filter method - Key: CLOUDSTACK-6965 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6965 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 CLOUDSTACK-6935 has introduced the NullPointerException in code. Since ZoneWideStoragePoolAllocator's filter method has been removed it is using AbstractStoragePoolAllocator's filter method. In the filter method there is check for cluster's hypervisor type and and disk profile hypervisor type. But cluster is null for ZoneWideStoragePool and Hence the exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7177) AlertSyslogAppender does not honor a non-default port specified in syslog host parameter
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-7177. -- AlertSyslogAppender does not honor a non-default port specified in syslog host parameter - Key: CLOUDSTACK-7177 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7177 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Reporter: Anshul Gangwar Assignee: Anshul Gangwar The AlertSyslogAppender does not currently honor a port number specified as part of the sysloghost parameter in log4j-cloud.xml (like so: IP:Port). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6620) [Hyper-v] when all vms on host are deleted from outside, then there is null pointer exception in hyperv agent in getting vmstats
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-6620. -- [Hyper-v] when all vms on host are deleted from outside, then there is null pointer exception in hyperv agent in getting vmstats Key: CLOUDSTACK-6620 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6620 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.4.0 [Hyper-v] when all vms on host are deleted from outside, then there is null pointer exception in hyperv agent in getting vm stats -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6663) [Hyper-V] Agent fails to start on some setups if last nic on host in nic list doesn't contain unicast address
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-6663. -- [Hyper-V] Agent fails to start on some setups if last nic on host in nic list doesn't contain unicast address - Key: CLOUDSTACK-6663 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6663 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 Before starting Hyper-V agent we initialize HypervResourceController. We try to initialize it with IP address 0.0.0.0. We try to get nic info of 0.0.0.0. To get nic info we iterate through all nics and return the last NIC in the list if it doesn't match with any IP address. So in case last NIC doesn't have unicastAddress, Hyper-V agent will fail to start. We don't need IP address during initialization. It get initialized with startupcommand later -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6615) 4.4 build is failing due to commit 882bf079fa1886c9feab0948066a02c1cb6cd86a
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-6615. -- 4.4 build is failing due to commit 882bf079fa1886c9feab0948066a02c1cb6cd86a --- Key: CLOUDSTACK-6615 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6615 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Anshul Gangwar Assignee: Sonal Ojha Priority: Blocker 4.4 build is failing due to commit 882bf079fa1886c9feab0948066a02c1cb6cd86a. There is compilation failure as s_configDao variable is not declared in AlertGenerator class. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6504) [hyper-v] remove unnecessary warnings while building hyper-v agent code
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-6504. -- [hyper-v] remove unnecessary warnings while building hyper-v agent code --- Key: CLOUDSTACK-6504 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6504 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar There are some unnecessary warnings in building hyper-v agent code. Like field is never used etc -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6411) [hyper-v] some files are not loading in visual studio due to license header at top making them unparsable
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-6411. -- [hyper-v] some files are not loading in visual studio due to license header at top making them unparsable - Key: CLOUDSTACK-6411 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6411 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar [hyper-v] some files are not loading in visual studio due to license header at top making them unparsable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6470) [Hyper-v] while stopping vm hyper-v agent, vm is not gracefully shutdown
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-6470. -- [Hyper-v] while stopping vm hyper-v agent, vm is not gracefully shutdown Key: CLOUDSTACK-6470 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6470 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar When we stop VM in case of hyper-v, then it is always force shutdowned i.e. turn off. Even if the integartion services are istalled in hyper-v. Directly turning of VM may result in corruption of disk. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-4345) centralize broadcast uri functionality in enum BroadcastDomainType
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland closed CLOUDSTACK-4345. - part of nicira private gateways solution. centralize broadcast uri functionality in enum BroadcastDomainType -- Key: CLOUDSTACK-4345 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4345 Project: CloudStack Issue Type: Sub-task Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller, Network Devices Reporter: Daan Hoogland Assignee: Daan Hoogland centralize broadcast uri functionality in enum BroadcastDomainType, so that generic calls can be done on broadcast uris independent of their type. This will help smoothing the path towards plugging vpc gateways to sdn networks -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6401) [Hyper-v] Host state is always shown as down when agent is down even when it is up
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-6401. -- [Hyper-v] Host state is always shown as down when agent is down even when it is up -- Key: CLOUDSTACK-6401 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6401 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar [Hyper-v] Host state is always shown as down when agent is down even when it is up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6400) [Hyper-V][VMSync]Occasionally VM is not deleted from back-end when it is stopped from Hyper-V manager and then destroyed-expunged from CS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-6400. -- [Hyper-V][VMSync]Occasionally VM is not deleted from back-end when it is stopped from Hyper-V manager and then destroyed-expunged from CS - Key: CLOUDSTACK-6400 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6400 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar [Hyper-V][VMSync]Occasionally VM is not deleted from back-end when it is stopped from Hyper-V manager and then destroyed-expunged from CS -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6399) [Hyper-V][VMSync] VMSync thread does not run if all the VMs on a host are stopped from outside CS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-6399. -- [Hyper-V][VMSync] VMSync thread does not run if all the VMs on a host are stopped from outside CS - Key: CLOUDSTACK-6399 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6399 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 [Hyper-V][VMSync] VMSync thread does not run if all the VMs on a host are stopped from outside CS -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6326) [Hyper-V] Password visible in plain text in some of commands in Hyper-v Agent logs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-6326. -- [Hyper-V] Password visible in plain text in some of commands in Hyper-v Agent logs -- Key: CLOUDSTACK-6326 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6326 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 Password visible in plain text in some of commands in Hyper-v Agent logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6398) [Hyper-V] [VMSync] Change auto shutdown and startup actions of VMs to shutdown and nothing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-6398. -- [Hyper-V] [VMSync] Change auto shutdown and startup actions of VMs to shutdown and nothing -- Key: CLOUDSTACK-6398 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6398 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Change auto shutdown and startup actions to shutdown and nothing so that they are consistent with Cloudstack auto shutdown and startup behavior -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-4328) Make mode http option httpclose in HAproxy.conf configurable on port 80
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland closed CLOUDSTACK-4328. - Make mode http option httpclose in HAproxy.conf configurable on port 80 - Key: CLOUDSTACK-4328 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4328 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.2.0 Reporter: Roeland Kuipers Assignee: Daan Hoogland Fix For: 4.3.0 By default CS configures mode http option http when it detects a rule on public port 80. In most situations this is perfectly OK, but we hit a specific situation where this has negative impact on performance. In this case a Varnish implementation which needs to run on port 80 and cannot run on an alternative port. We could imagine this could be an issue for other CS users too. Besides this also the maxconnections needs to be raised but this has already been address by CS-2997, which is also the inspiration to make the http mode configurable. next several other related options need to be set maxpipes 20480 # sugestion is to set it to 1/4 of max connection and do this automatically (if needed this can be altered later nokqueue nopoll and the following set option forwardfor option forceclose be changed into no option forceclose Details on the performance difference below. So we like to see this http modeon port 80 configurable. e.g. httpmode false-true on the API See also CS-2997 and the following commits: dd33abffbe3b7c5b615e8f64b1824a720329dd0d [dd33abf] 954e1978130b3cfb0c73f2f1506d94440f478f01 [954e197] Performance testing details: with ‘mode http en option httpclose’ on de load-balancing rule: 9:34 root@w6 /home/erwin/src/wrk ./wrk -c 1000 -t 20 -d 20 http://x/imgbase0/imagebase/thumb/FC/2/7/0/8/1004004013338072.jpg Running 20s test @ http://x/imgbase0/imagebase/thumb/FC/2/7/0/8/1004004013338072.jpg 20 threads and 1000 connections Thread Stats Avg Stdev Max +/- Stdev Latency 6.21s 6.30s 15.87s82.30% Req/Sec43.61 37.81 371.00 78.61% 16452 requests in 20.01s, 146.60MB read Socket errors: connect 0, read 8, write 309, timeout 4753 Requests/sec:822.03 Transfer/sec: 7.33MB - without: 9:33 root@w6 /home/erwin/src/wrk ./wrk -c 1000 -t 20 -d 20 http://x/imgbase0/imagebase/thumb/FC/2/7/0/8/1004004013338072.jpg Running 20s test @ http://x/imgbase0/imagebase/thumb/FC/2/7/0/8/1004004013338072.jpg 20 threads and 1000 connections Thread Stats Avg Stdev Max +/- Stdev Latency 240.62ms1.28s 12.19s97.80% Req/Sec 545.98181.96 1.46k74.70% 29 requests in 20.00s, 1.92GB read Socket errors: connect 0, read 53, write 43, timeout 791 Requests/sec: 11109.45 Transfer/sec: 98.09MB -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6288) [Hyper-v] Change default ImageFormat to vhdx for hyper-v and allow registration of vhdx format templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-6288. -- [Hyper-v] Change default ImageFormat to vhdx for hyper-v and allow registration of vhdx format templates - Key: CLOUDSTACK-6288 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6288 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Anshul Gangwar Assignee: Anshul Gangwar Fix For: 4.4.0 Currently Hyper-V supports vhd Image Format for templates and volumes. Now change default ImageFormat to vhdx for hyper-v and allow registration of vhdx format templates. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6289) [Hyper-V] Storage migration failing in case of hyper-v if there are multiple disks attached to VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-6289. -- [Hyper-V] Storage migration failing in case of hyper-v if there are multiple disks attached to VM - Key: CLOUDSTACK-6289 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6289 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Anshul Gangwar Assignee: Anshul Gangwar Fix For: 4.4.0 [Hyper-V] Storage migration failing in case of hyper-v if there are multiple disks attached to VM -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6315) Password visible in plan text during volume migration.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anshul Gangwar closed CLOUDSTACK-6315.
--
Password visible in plan text during volume migration.
--
Key: CLOUDSTACK-6315
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6315
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller, Storage Controller
Affects Versions: 4.3.0
Environment: Management server CentOS 6.3 x86_64, with Hyperv
hypervisor
Reporter: Tejas
Assignee: Anshul Gangwar
Labels: security
During volume Migration form one Primary Storage to another, password was
visible in plan text.
2014-03-28 17:53:39,059 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-216:ctx-89b9eb84) POST response is
[{org.apache.cloudstack.storage.command.CopyCmdAnswer:{result:true,details:null,newData:{org.apache.cloudstack.storage.to.VolumeObjectTO:{dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:7890d244-e307-320e-ac42-f90e925b32b8,id:5,poolType:SMB,host:10.129.150.24,path:/vol_cifs?user=administratordomain=nw.com,port:445,url:SMB://10.129.150.24//vol_cifs?user=administratordomain=nw.com/?ROLE=PrimarySTOREUUID=7890d244-e307-320e-ac42-f90e925b32b8}},format:VHD,name:ROOT-7,path:\\10.129.150.24\vol_cifs\ROOT-7.vhd,uuid:ca572e34-ffa6-4cce-bb24-44c989b4156e,size:10737418240,primaryDataStore:{host:10.129.150.24,uri:cifs://10.129.150.24/vol_cifs?user=administratordomain=nw.com,_role:null,Path:\\10.129.150.24/vol_cifs,UncPath:\\10.129.150.24/vol_cifs,User:administrator,Password:C1sco123,Domain:nw.com,isLocal:false},nfsDataStore:null,FullFileName:\\10.129.150.24\vol_cifs\ROOT-7.vhd}},contextMap:{}}}]
2014-03-28 17:53:39,060 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-216:ctx-89b9eb84) executeRequest received response
[Lcom.cloud.agent.api.Answer;@31c91ca
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6325) [Hyper-v] clean bin and object folder when building hyper-v agent with mono
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-6325. -- [Hyper-v] clean bin and object folder when building hyper-v agent with mono --- Key: CLOUDSTACK-6325 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6325 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Anshul Gangwar Assignee: Anshul Gangwar Fix For: 4.4.0 Currently when we build hyper-v agent with mono, then bin and obj directories are not removed. This may result in use of stale dlls in some cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6267) [Hyper-v] Unblock SMB as Zone wide primary storage for hyperv
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-6267. -- [Hyper-v] Unblock SMB as Zone wide primary storage for hyperv - Key: CLOUDSTACK-6267 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6267 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.4.0 Unblock SMB as Zone wide primary storage for hyperv -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6108) Network throttling for the VM's running on Hyper-V
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-6108. -- Network throttling for the VM's running on Hyper-V -- Key: CLOUDSTACK-6108 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6108 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Anshul Gangwar Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6287) While adding Secondary storage as SMB/CIFS in CS 4.3 Domain controller password appears in plan text in key/pair value.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-6287. -- While adding Secondary storage as SMB/CIFS in CS 4.3 Domain controller password appears in plan text in key/pair value. --- Key: CLOUDSTACK-6287 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6287 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Storage Controller Affects Versions: 4.3.0 Environment: CentOS 6.3 x64-64, Hyperv hypervisor Reporter: Tejas Assignee: Anshul Gangwar Priority: Critical Labels: security While adding Secondary storage as SMB/CIFS in CS 4.3 Domain controller password appears in plan text in key/pair value. Logs are as below, 2014-03-27 09:49:47,611 INFO [o.a.c.s.d.l.CloudStackImageStoreLifeCycleImpl] (catalina-exec-12:ctx-bd85f47b ctx-df8f3444) Trying to add a new data store at cifs://10.129.151.61/Secondary to data center 1 2014-03-27 09:49:47,977 DEBUG [c.c.a.ApiServlet] (catalina-exec-12:ctx-bd85f47b ctx-df8f3444) ===END=== 10.129.150.62 -- GET command=addImageStoreresponse=jsonsessionkey=pjC%2B%2FjnddbFmQI7MtdDgo%2Bf5JmQ%3Dname=Secondaryprovider=SMBzoneid=5e5a7fee-9e4e-47df-86fa-c19da8240e84url=cifs%3A%2F%2F10.129.151.61%2FSecondarydetails%5B0%5D.key=userdetails%5B0%5D.value=administratordetails%5B1%5D.key=passworddetails%5B1%5D.value=C1sco123details%5B2%5D.key=domaindetails%5B2%5D.value=nw.com_=1395893875835 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4328) Make mode http option httpclose in HAproxy.conf configurable on port 80
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131307#comment-14131307 ] Roeland Kuipers commented on CLOUDSTACK-4328: - L.S. Currently I am enjoying my holiday until the 21st of september. I won't be reading my email. In case of urgency, give me a ring or send me a txt message. Or contact Arjan Eriks via: aer...@schubergphilis.com / +31207506500 Kind Regards, Roeland Kuipers Schuberg Philis Boeingavenue 271 1119 PD Schiphol-Rijk schubergphilis.com +31 207506526 +31 614008097 Make mode http option httpclose in HAproxy.conf configurable on port 80 - Key: CLOUDSTACK-4328 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4328 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.2.0 Reporter: Roeland Kuipers Assignee: Daan Hoogland Fix For: 4.3.0 By default CS configures mode http option http when it detects a rule on public port 80. In most situations this is perfectly OK, but we hit a specific situation where this has negative impact on performance. In this case a Varnish implementation which needs to run on port 80 and cannot run on an alternative port. We could imagine this could be an issue for other CS users too. Besides this also the maxconnections needs to be raised but this has already been address by CS-2997, which is also the inspiration to make the http mode configurable. next several other related options need to be set maxpipes 20480 # sugestion is to set it to 1/4 of max connection and do this automatically (if needed this can be altered later nokqueue nopoll and the following set option forwardfor option forceclose be changed into no option forceclose Details on the performance difference below. So we like to see this http modeon port 80 configurable. e.g. httpmode false-true on the API See also CS-2997 and the following commits: dd33abffbe3b7c5b615e8f64b1824a720329dd0d [dd33abf] 954e1978130b3cfb0c73f2f1506d94440f478f01 [954e197] Performance testing details: with ‘mode http en option httpclose’ on de load-balancing rule: 9:34 root@w6 /home/erwin/src/wrk ./wrk -c 1000 -t 20 -d 20 http://x/imgbase0/imagebase/thumb/FC/2/7/0/8/1004004013338072.jpg Running 20s test @ http://x/imgbase0/imagebase/thumb/FC/2/7/0/8/1004004013338072.jpg 20 threads and 1000 connections Thread Stats Avg Stdev Max +/- Stdev Latency 6.21s 6.30s 15.87s82.30% Req/Sec43.61 37.81 371.00 78.61% 16452 requests in 20.01s, 146.60MB read Socket errors: connect 0, read 8, write 309, timeout 4753 Requests/sec:822.03 Transfer/sec: 7.33MB - without: 9:33 root@w6 /home/erwin/src/wrk ./wrk -c 1000 -t 20 -d 20 http://x/imgbase0/imagebase/thumb/FC/2/7/0/8/1004004013338072.jpg Running 20s test @ http://x/imgbase0/imagebase/thumb/FC/2/7/0/8/1004004013338072.jpg 20 threads and 1000 connections Thread Stats Avg Stdev Max +/- Stdev Latency 240.62ms1.28s 12.19s97.80% Req/Sec 545.98181.96 1.46k74.70% 29 requests in 20.00s, 1.92GB read Socket errors: connect 0, read 53, write 43, timeout 791 Requests/sec: 11109.45 Transfer/sec: 98.09MB -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6054) [Hyper-v] vmsync is not working for hyperv
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-6054. -- [Hyper-v] vmsync is not working for hyperv -- Key: CLOUDSTACK-6054 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6054 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.3.0 Reporter: Anshul Gangwar Assignee: Anshul Gangwar Fix For: 4.3.0 vmsync is not working for hyperv -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6262) [hyper-v] network throttling rate are not honored in hyperv
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-6262. -- [hyper-v] network throttling rate are not honored in hyperv --- Key: CLOUDSTACK-6262 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6262 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.4.0 Reporter: Anshul Gangwar Assignee: Anshul Gangwar Fix For: 4.4.0 [hyper-v] network throttling rate are not honored in hyperv. Currently there is no limit set on hyper-v guest VMs data transfer rate. They have unlimited bandwidth. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-5705) [Hyper-V] Thumbnail for console of hyperv is not working
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-5705. -- [Hyper-V] Thumbnail for console of hyperv is not working Key: CLOUDSTACK-5705 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5705 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Labels: hyper-V, Fix For: 4.3.0 Thumbnail for console of hyperv is not working -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-5703) [Hyper-V] Put the hard coded rdp server port value in host details
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-5703. -- [Hyper-V] Put the hard coded rdp server port value in host details -- Key: CLOUDSTACK-5703 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5703 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Labels: hyper-V, -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-5880) Communication between management server and hyper-v agent should be secure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-5880. -- Communication between management server and hyper-v agent should be secure -- Key: CLOUDSTACK-5880 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5880 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: Devdeep Singh Assignee: Anshul Gangwar Priority: Critical Fix For: 4.3.0 Currently the hyper-v agent and management server talk over http. Communication between mgmt server and HyperV Agent running in hyperv host should be secured using say SSL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-5702) [Hyper-V] Mouse doesn't work for Console
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-5702. -- [Hyper-V] Mouse doesn't work for Console Key: CLOUDSTACK-5702 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5702 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Labels: hyper-V, mouse keys are not working for console on hyperv -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-4959) CLONE - Invalid SMTP breaks HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-4959. -- CLONE - Invalid SMTP breaks HA -- Key: CLOUDSTACK-4959 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4959 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.3.0 Putting an invalid smtp ip in alert.smtp.host can potentially stop HA from working. If the smtp ip is listening but does not send a proper HELO HA hangs and will not proceed. It seems as if the code (agent.manager.AgentManagerImpl) doesn't receive a timeout it will not proceed. I tried putting a bogus ip in alert.smtp.host but HA worked fine. I believe we need to make HA independent of smtp alerts or at least put in a timeout so HA proceeds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-4956) CLONE - Add global configuration parameters for SMTP timeout
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-4956. -- CLONE - Add global configuration parameters for SMTP timeout Key: CLOUDSTACK-4956 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4956 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.3.0 Make the SMTP connection Timeout and socket timeout value configurable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-5143) CLONE - 3.0.6 to ASF 4.2.1 Upgrade: alert.smtp.timeout and alert.smtp.connectiontimeout configuration parameters are missing on the Upgraded Setup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-5143. -- CLONE - 3.0.6 to ASF 4.2.1 Upgrade: alert.smtp.timeout and alert.smtp.connectiontimeout configuration parameters are missing on the Upgraded Setup -- Key: CLOUDSTACK-5143 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5143 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: Future Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.3.0 The following parameters are missing on the Upgraded Setup. mysql select * from configuration where name like alert.smtp.%timeout; +--+--+---+--+---+---+ | category | instance | component | name | value | description | +--+--+---+--+---+---+ | Alert| DEFAULT | management-server | alert.smtp.connectiontimeout | 3 | Socket connection timeout value in milliseconds. -1 for infinite timeout. | | Alert| DEFAULT | management-server | alert.smtp.timeout | 3 | Socket I/O timeout value in milliseconds. -1 for infinite timeout. | +--+--+---+--+---+---+ 2 rows in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-5549) [HyperV] hyper agent installer should be in single msi file
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-5549. -- [HyperV] hyper agent installer should be in single msi file Key: CLOUDSTACK-5549 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5549 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.3.0 Environment: hyperv branch 4:3 Reporter: Rayees Namathponnan Assignee: Anshul Gangwar Priority: Critical Fix For: 4.3.0 follow below doc to create hyperV agent https://cwiki.apache.org/confluence/display/CLOUDSTACK/Creating+Hyperv+Agent+Installer Below 3 files gets created for agent installation CloudStackAgentSetup.msi CloudStackAgentSetup.wixpdb cab1.cab We should package CloudStackAgentSetup.wixpdb and cab1.cab into CloudStackAgentSetup.msi itself -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-4792) Invalid SMTP breaks HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-4792. -- Invalid SMTP breaks HA -- Key: CLOUDSTACK-4792 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4792 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.2.1 Putting an invalid smtp ip in alert.smtp.host can potentially stop HA from working. If the smtp ip is listening but does not send a proper HELO HA hangs and will not proceed. It seems as if the code (agent.manager.AgentManagerImpl) doesn't receive a timeout it will not proceed. I tried putting a bogus ip in alert.smtp.host but HA worked fine. I believe we need to make HA independent of smtp alerts or at least put in a timeout so HA proceeds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-4715) ispersistent parameter is missing in networkoffering create method in marvin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-4715. -- ispersistent parameter is missing in networkoffering create method in marvin Key: CLOUDSTACK-4715 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4715 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: marvin Reporter: Anshul Gangwar Assignee: Anshul Gangwar ispersistent parameter is missing in networkoffering create method in marvin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-3593) Wrong Resource capacity for primary storage (Double the amount)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar closed CLOUDSTACK-3593. -- Wrong Resource capacity for primary storage (Double the amount) Key: CLOUDSTACK-3593 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3593 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.1.0 Environment: Ubuntu / Xenserver 6.0.2 with CS 4.1 Reporter: Dean Kamali Assignee: Anshul Gangwar Using CS 4.1 with NFS as primary storage, I have created a 2TB Lun, however when checking available resources it shows 4TB -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-4085) create VpcGateways of different VPCs in the same (lswitch) network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland closed CLOUDSTACK-4085. - some gotchas: private gateway networks are guestnetworks and share some functionality with those. In these cases we would want gateway/route/endpoint for routing. The private gateway table (vpc_gateways) needs to be updated for that, modelled after network_acl_item_cidrs extended with routes. create VpcGateways of different VPCs in the same (lswitch) network -- Key: CLOUDSTACK-4085 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4085 Project: CloudStack Issue Type: Sub-task Security Level: Public(Anyone can view this level - this is the default.) Reporter: Daan Hoogland Assignee: Daan Hoogland Fix For: Future, 4.3.0 When creating a gateway for a VPC one might want to add it to the same network as other vpc gateways, to create (an application landscape within) a network without running into interface limitations on virtual machines. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6926) Usage service fails to start when java 1.6 is not installed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131334#comment-14131334 ] ASF subversion and git services commented on CLOUDSTACK-6926: - Commit fa1156092eb341850c207742d4ac5a3677c97d00 in cloudstack's branch refs/heads/master from [~rajanik] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fa11560 ] CLOUDSTACK-6926 setting java_home from installed java changed the order of preference to check for java first. Usage server rpm installs JRE 1.7. In the case where JDK 1.6 is already installed, java version would be 1.7 but, javac would be 1.6 If javac is given preference, usage server fails to start in this case. Usage service fails to start when java 1.6 is not installed --- Key: CLOUDSTACK-6926 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6926 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup, Usage Affects Versions: 4.2.1 Reporter: Rajani Karuturi Assignee: Rajani Karuturi was able to start only after editing JDK_DIRS in /etc/init.d/cloudstack-usage it is searching only 1.6 java install directories by default -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6223) removeNicFromVirtualMachine fails if another instance in another domain has a nic with the same ip and a forwarding rule configured on it
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131340#comment-14131340
]
Daan Hoogland commented on CLOUDSTACK-6223:
---
guess I forgot. doing it now
removeNicFromVirtualMachine fails if another instance in another domain has a
nic with the same ip and a forwarding rule configured on it
-
Key: CLOUDSTACK-6223
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6223
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Affects Versions: 4.2.1
Reporter: Joris van Lieshout
Assignee: upendra moturi
Priority: Blocker
Fix For: 4.4.0
When removeNicFromVirtualMachine is called for a nic on an instance the code
below is evaluated. This piece of code searches for portforwarding rules
across all domains. If another instance exists that has a nic with the same
ip and a forwarding rule the search returns 1 and the
removeNicFromVirtualMachine call failed.
server/src/com/cloud/network/rules/RulesManagerImpl.java
@Override
public ListFirewallRuleVO listAssociatedRulesForGuestNic(Nic nic){
ListFirewallRuleVO result = new ArrayListFirewallRuleVO();
// add PF rules
result.addAll(_portForwardingDao.listByDestIpAddr(nic.getIp4Address()));
// add static NAT rules
Stack trace:
2014-03-11 15:24:04,944 ERROR [cloud.async.AsyncJobManagerImpl]
(Job-Executor-102:job-193607 = [ 30e81de3-2a00-49f2-8d80-545a765e4c1e ])
Unexpected exception while executing
org.apache.cloudstack.api.command.user.vm.RemoveNicFromVMCmd
com.cloud.utils.exception.CloudRuntimeException: Failed to remove nic from
VM[User|zzz1] in Ntwk[994|Guest|14], nic has associated Port forwarding or
Load balancer or Static NAT rules.
at
com.cloud.vm.VirtualMachineManagerImpl.removeNicFromVm(VirtualMachineManagerImpl.java:3058)
at
com.cloud.vm.UserVmManagerImpl.removeNicFromVirtualMachine(UserVmManagerImpl.java:1031)
at
org.apache.cloudstack.api.command.user.vm.RemoveNicFromVMCmd.execute(RemoveNicFromVMCmd.java:103)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
at
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6223) removeNicFromVirtualMachine fails if another instance in another domain has a nic with the same ip and a forwarding rule configured on it
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131341#comment-14131341
]
ASF subversion and git services commented on CLOUDSTACK-6223:
-
Commit 213bdbde35e273b2c40d421071e46f2af6de729c in cloudstack's branch
refs/heads/4.4 from [~Upendra]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=213bdbd ]
CLOUDSTACK-6223. removeNicFromVirtualMachine fails if another instance in
another domain has a nic with the same ip and a forwarding rule configured on it
Signed-off-by: Daan Hoogland d...@onecht.net
(cherry picked from commit e9af5f44ae080da3f191cba57b55747801c3100e)
removeNicFromVirtualMachine fails if another instance in another domain has a
nic with the same ip and a forwarding rule configured on it
-
Key: CLOUDSTACK-6223
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6223
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Affects Versions: 4.2.1
Reporter: Joris van Lieshout
Assignee: upendra moturi
Priority: Blocker
Fix For: 4.4.0
When removeNicFromVirtualMachine is called for a nic on an instance the code
below is evaluated. This piece of code searches for portforwarding rules
across all domains. If another instance exists that has a nic with the same
ip and a forwarding rule the search returns 1 and the
removeNicFromVirtualMachine call failed.
server/src/com/cloud/network/rules/RulesManagerImpl.java
@Override
public ListFirewallRuleVO listAssociatedRulesForGuestNic(Nic nic){
ListFirewallRuleVO result = new ArrayListFirewallRuleVO();
// add PF rules
result.addAll(_portForwardingDao.listByDestIpAddr(nic.getIp4Address()));
// add static NAT rules
Stack trace:
2014-03-11 15:24:04,944 ERROR [cloud.async.AsyncJobManagerImpl]
(Job-Executor-102:job-193607 = [ 30e81de3-2a00-49f2-8d80-545a765e4c1e ])
Unexpected exception while executing
org.apache.cloudstack.api.command.user.vm.RemoveNicFromVMCmd
com.cloud.utils.exception.CloudRuntimeException: Failed to remove nic from
VM[User|zzz1] in Ntwk[994|Guest|14], nic has associated Port forwarding or
Load balancer or Static NAT rules.
at
com.cloud.vm.VirtualMachineManagerImpl.removeNicFromVm(VirtualMachineManagerImpl.java:3058)
at
com.cloud.vm.UserVmManagerImpl.removeNicFromVirtualMachine(UserVmManagerImpl.java:1031)
at
org.apache.cloudstack.api.command.user.vm.RemoveNicFromVMCmd.execute(RemoveNicFromVMCmd.java:103)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
at
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7412) Can't create proper template from VM on S3 secondary storage environment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akihiko Ota updated CLOUDSTACK-7412: Affects Version/s: 4.5.0 4.4.0 Future Can't create proper template from VM on S3 secondary storage environment Key: CLOUDSTACK-7412 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7412 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: Future, 4.2.1, 4.3.0, 4.4.0, 4.5.0 Environment: CloudStack 4.3.0 on CentOS 6.5. KVM Hypervisor. using S3 provider as socondary storage. The storage system is using RADOS. using local storage as primary storage. Reporter: Akihiko Ota When I create more than one templates from an existing virtual machine, the second and the subsequent template is created the same as first one. It doesn't occur in the case of using NFS secondary storage. So I guess this is the S3 provider specific issue. This could reproduce as following procedure. (1) create a virtual machine (name foo tentatively), and modify some files on ROOT volume of foo. (2) stop foo. and create template template-foo.1 from ROOT volume of foo. (3) reboot (not re-create) foo, and modify some files on ROOT volume again. (4) stop foo. and create template template-foo.2 from ROOT volume of foo. I expect that template-foo.2 keeps (3)'s changes. But template-foo.2 is the same as template-foo.1. (3)'s changes are not recorded. As of (4), CloudStack outputs the following DEBUG message to cloudstack-management.log. 2014-08-07 19:23:20,094 DEBUG [o.a.c.s.c.m.StorageCacheManagerImpl] (Job-Executor-58:ctx-b00fbe22 ctx-6339bae6) there is already one in the cache store When creating templates on NFS secondary storage environment, this message is not output. This issue also exists on CloudStack 4.2.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7412) Can't create proper template from VM on S3 secondary storage environment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akihiko Ota updated CLOUDSTACK-7412: Component/s: Template Storage Controller Can't create proper template from VM on S3 secondary storage environment Key: CLOUDSTACK-7412 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7412 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller, Template Affects Versions: Future, 4.2.1, 4.3.0, 4.4.0, 4.5.0 Environment: CloudStack 4.3.0 on CentOS 6.5. KVM Hypervisor. using S3 provider as socondary storage. The storage system is using RADOS. using local storage as primary storage. Reporter: Akihiko Ota When I create more than one templates from an existing virtual machine, the second and the subsequent template is created the same as first one. It doesn't occur in the case of using NFS secondary storage. So I guess this is the S3 provider specific issue. This could reproduce as following procedure. (1) create a virtual machine (name foo tentatively), and modify some files on ROOT volume of foo. (2) stop foo. and create template template-foo.1 from ROOT volume of foo. (3) reboot (not re-create) foo, and modify some files on ROOT volume again. (4) stop foo. and create template template-foo.2 from ROOT volume of foo. I expect that template-foo.2 keeps (3)'s changes. But template-foo.2 is the same as template-foo.1. (3)'s changes are not recorded. As of (4), CloudStack outputs the following DEBUG message to cloudstack-management.log. 2014-08-07 19:23:20,094 DEBUG [o.a.c.s.c.m.StorageCacheManagerImpl] (Job-Executor-58:ctx-b00fbe22 ctx-6339bae6) there is already one in the cache store When creating templates on NFS secondary storage environment, this message is not output. This issue also exists on CloudStack 4.2.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7343) cannot create Instance from template using Swift as secondary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland resolved CLOUDSTACK-7343. --- Resolution: Fixed Fix Version/s: (was: 4.4.1) applied to 4.4 branch cannot create Instance from template using Swift as secondary storage - Key: CLOUDSTACK-7343 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7343 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0, 4.4.1 Environment: acs4.4.1-snapshot Reporter: Pierre-Luc Dion Assignee: Pierre-Luc Dion Priority: Minor Labels: swift Attachments: cloud.log_fromtemplate Fail to create Instance from Template or ISOS when using Swift as secondary storage. The templates is show as ready in Cloudstack UI, when creating the new instance the template is created on the staging NFS share at the SSVM, but the vm will still fail to create. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7343) cannot create Instance from template using Swift as secondary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-7343: -- Fix Version/s: 4.4.1 cannot create Instance from template using Swift as secondary storage - Key: CLOUDSTACK-7343 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7343 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0, 4.4.1 Environment: acs4.4.1-snapshot Reporter: Pierre-Luc Dion Assignee: Pierre-Luc Dion Priority: Minor Labels: swift Attachments: cloud.log_fromtemplate Fail to create Instance from Template or ISOS when using Swift as secondary storage. The templates is show as ready in Cloudstack UI, when creating the new instance the template is created on the staging NFS share at the SSVM, but the vm will still fail to create. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6698) listResourceDetals - normal user able to list details not belonging to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131359#comment-14131359 ] Daan Hoogland commented on CLOUDSTACK-6698: --- Nitin, can you gave an ATA on this (regarding releasing a 4.4.1)? thanks listResourceDetals - normal user able to list details not belonging to it - Key: CLOUDSTACK-6698 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6698 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Priority: Critical Fix For: 4.5.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7397) [LXC][Rhel7] add libcgroup-tools dependency in agent installation on rhel7
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7397. -- [LXC][Rhel7] add libcgroup-tools dependency in agent installation on rhel7 -- Key: CLOUDSTACK-7397 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7397 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Doc Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Blocker Fix For: 4.5.0 [LXC][Rhel7] add libcgroup-tools dependency in agent installation on rhel7 for more details http://docs.fedoraproject.org/en-US/Fedora/16/html/Resource_Management_Guide/ch-Using_Control_Groups.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7116) unable to add KVM host to MS with error java.lang.UnsupportedClassVersionError: com/cloud/agent/AgentShell : Unsupported major.minor version 51.0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7116. -- unable to add KVM host to MS with error java.lang.UnsupportedClassVersionError: com/cloud/agent/AgentShell : Unsupported major.minor version 51.0 - Key: CLOUDSTACK-7116 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7116 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Damodar Reddy T Priority: Blocker Fix For: 4.5.0 Attachments: cloudstack-agent.err, management-server.log.tar.gz Repro steps: 1. Create a KVM host on rhel 6.3 As I used following build http://repo-ccp.citrix.com/releases/ASF/rhel/6.3/master/CloudPlatform-4.5.0-57-rhel6.3.tar.gz so i need to install jsvc outside of cloudstack for which I have done the following step: yum install java-gcj-compat rpm -Uvh ftp://rpmfind.net/linux/centos/6.5/os/x86_64/Packages/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm and then I installed agent Once agent installation is complete I tried to add this KVM host to MS and host addition failed with MS logs showing 2014-07-16 06:09:19,082 DEBUG [c.c.h.k.d.LibvirtServerDiscoverer] (catalina-exec-7:ctx-ec9fe1d8 ctx-949d2702) Timeout, to wait for the host connecting to mgt svr, assuming it is failed 2014-07-16 06:09:19,083 WARN [c.c.r.ResourceManagerImpl] (catalina-exec-7:ctx-ec9fe1d8 ctx-949d2702) Unable to find the server resources at http://10.147.40.23 2014-07-16 06:09:19,084 INFO [c.c.u.e.CSExceptionErrorCode] (catalina-exec-7:ctx-ec9fe1d8 ctx-949d2702) Could not find exception: com.cloud.exception.DiscoveryException in error code list for exceptions 2014-07-16 06:09:19,084 WARN [o.a.c.a.c.a.h.AddHostCmd] (catalina-exec-7:ctx-ec9fe1d8 ctx-949d2702) Exception: com.cloud.exception.DiscoveryException: Unable to add the host at com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:791) at com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:586) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.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 $Proxy148.discoverHosts(Unknown Source) at org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.java:142) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:694) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:517) at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:317) at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115) at com.cloud.api.ApiServlet.doPost(ApiServlet.java:82) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) 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
[jira] [Closed] (CLOUDSTACK-7316) hitting java.lang.reflect.InvocationTargetException while starting usage server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7316. -- Resolution: Fixed hitting java.lang.reflect.InvocationTargetException while starting usage server --- Key: CLOUDSTACK-7316 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7316 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Usage Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Damodar Reddy T Priority: Blocker Fix For: 4.5.0 Attachments: usage.tar.gz Repro steps: Install MS and usage server Start MS and usage server Bug: Usage server will stop after starting usage log shows : java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243) Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'vmDiskUsageParser': Injection of autowired dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Could not autowire field: private com.cloud.usage.dao.UsageDao com.cloud.usage.parser.VmDiskUsageParser._usageDao; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'usageDaoImpl' defined in URL [jar:file:/usr/share/cloudstack-usage/lib/cloud-engine-schema-4.5.0-SNAPSHOT.jar!/com/cloud/usage/dao/UsageDaoImpl.class]: BeanPostProcessor before instantiation of bean failed; nested exception is net.sf.cglib.core.CodeGenerationException: java.lang.ExceptionInInitializerError--null at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:288) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1116) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:295) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223) at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:628) at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479) at org.springframework.context.support.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:139) at org.springframework.context.support.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:83) at com.cloud.usage.UsageServer.start(UsageServer.java:57) ... 5 more Caused by: org.springframework.beans.factory.BeanCreationException: Could not autowire field: private com.cloud.usage.dao.UsageDao com.cloud.usage.parser.VmDiskUsageParser._usageDao; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'usageDaoImpl' defined in URL [jar:file:/usr/share/cloudstack-usage/lib/cloud-engine-schema-4.5.0-SNAPSHOT.jar!/com/cloud/usage/dao/UsageDaoImpl.class]: BeanPostProcessor before instantiation of bean failed; nested exception is net.sf.cglib.core.CodeGenerationException: java.lang.ExceptionInInitializerError--null at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:514) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7171) not getting console of user vm via virsh on kvm
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7171: --- Priority: Minor (was: Blocker) not getting console of user vm via virsh on kvm --- Key: CLOUDSTACK-7171 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7171 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Environment: KMV host on centos6.2 advance zone Reporter: shweta agarwal Assignee: Murali Reddy Priority: Minor Fix For: 4.5.0 Attachments: MSlog.tar.gz, kvmhostlog.tar.gz Repro steps: Create a KVM(centos6.2) advance zone setup . Once everything is uop created a user vm with default centos 5.5 template On KVM host try to access console of this user vm via vrish Bug : Nothing happens I even tried registering ubuntu template and created a ubuntu VM still not able to access console via virsh for ubuntu VM as well But able to access console via virsh for system vms , CPVM, SSVM, router vm Attaching MS logs and kvm logs for the same -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7252) [LXC] VM not starting for first time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7252. -- Resolution: Fixed [LXC] VM not starting for first time Key: CLOUDSTACK-7252 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7252 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Fix For: 4.5.0 Repro steps: Create a LXC zone using LXC host on rhel 6.x register a LXC template Create a VM when VM is running try accessing vm console using virsh Bug : console view shows : Connected to domain i-2-15-VM Escape character is ^] Welcome to CentOS Starting udev: /bin/mknod: `/dev/loop0': Operation not permitted /bin/chown: cannot access `/dev/loop0': No such file or directory /bin/mknod: `/dev/loop1': Operation not permitted /bin/chown: cannot access `/dev/loop1': No such file or directory /bin/mknod: `/dev/loop2': Operation not permitted /bin/chown: cannot access `/dev/loop2': No such file or directory /bin/mknod: `/dev/loop3': Operation not permitted /bin/chown: cannot access `/dev/loop3': No such file or directory /bin/mknod: `/dev/loop4': Operation not permitted /bin/chown: cannot access `/dev/loop4': No such file or directory /bin/mknod: `/dev/loop5': Operation not permitted /bin/chown: cannot access `/dev/loop5': No such file or directory /bin/mknod: `/dev/loop6': Operation not permitted /bin/chown: cannot access `/dev/loop6': No such file or directory /bin/mknod: `/dev/loop7': Operation not permitted /bin/chown: cannot access `/dev/loop7': No such file or directory /bin/mknod: `/dev/lp0': Operation not permitted /bin/chown: cannot access `/dev/lp0': No such file or directory /bin/mknod: `/dev/lp1': Operation not permitted /bin/chown: cannot access `/dev/lp1': No such file or directory /bin/mknod: `/dev/lp2': Operation not permitted /bin/chown: cannot access `/dev/lp2': No such file or directory /bin/mknod: `/dev/lp3': Operation not permitted /bin/chown: cannot access `/dev/lp3': No such file or directory /bin/mknod: `/dev/net/tun': Operation not permitted /bin/mknod: `/dev/ppp': Operation not permitted /bin/mknod: `/dev/fuse': Operation not permitted /sbin/start_udev: line 269: /proc/sys/kernel/hotplug: Read-only file system /sbin/start_udev: line 299: /etc/sysconfig/network: No such file or directory [ OK ] Setting hostname Rack1Pod1Host23: [ OK ] Checking filesystems WARNING: couldn't open /etc/fstab: No such file or directory [ OK ] warning: can't open /etc/fstab: No such file or directory mount: can't find / in /etc/fstab or /etc/mtab Mounting local filesystems: warning: can't open /etc/fstab: No such file or directory [ OK ] Enabling /etc/fstab swaps: swapon: /etc/fstab: open failed: No such file or directory [FAILED] Additional info : do a stop /start of VM and VM starts correctly -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7314) [LXC] getting libvirt exception while stopping VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7314. -- Resolution: Fixed [LXC] getting libvirt exception while stopping VM - Key: CLOUDSTACK-7314 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7314 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Fix For: 4.5.0 Attachments: agent.log Repro steps: 1. Create a LXC VM 2. Stop the VM Bug: Even though VM stops Agent log show exception Failed to stop VM :i-2-71-VM : org.libvirt.LibvirtException: Mount namespaces are not available on this platform: Function not implemented at org.libvirt.ErrorHandler.processError(Unknown Source) at org.libvirt.Connect.processError(Unknown Source) at org.libvirt.Domain.processError(Unknown Source) at org.libvirt.Domain.shutdown(Unknown Source) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.stopVM(LibvirtComputingResource.java:4566) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.stopVM(LibvirtComputingResource.java:4505) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3478) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1262) at com.cloud.agent.Agent.processRequest(Agent.java:501) at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:808) at com.cloud.utils.nio.Task.run(Task.java:84) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7401) [LXC] storage migration for LXC VMs are failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal closed CLOUDSTACK-7401.
--
Resolution: Fixed
[LXC] storage migration for LXC VMs are failing
---
Key: CLOUDSTACK-7401
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7401
Project: CloudStack
Issue Type: Improvement
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Fix For: 4.5.0
Repro steps :
Create a LXC VM in a zone having two primary shared storage
stop the vm
Migrate the root disk of VM to another Primary storage
Bug:
migration fails with java NPE
Expection :
either enable storage migration or gracefully handle it by giving proper
message
MS log shows :
2014-08-22 16:37:03,606 DEBUG [o.a.c.s.c.a.StorageCacheRandomAllocator]
(Work-Job-Executor-117:ctx-b8749277 job-640/job-641 ctx-3675a1df) Can't find
staging storage in zone: 2
2014-08-22 16:37:03,662 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-117:ctx-b8749277 job-640/job-641 ctx-3675a1df) Seq
2-5838635441909144321: Sending { Cmd , MgmtId: 233845178472597, via:
2(Rack3Pod1Host42), Ver: v1, Flags: 100011,
[{org.apache.cloudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:1317fed3-0666-45b4-8849-0316206c58e7,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:2a4208e2-8f5e-3b6a-bede-315c90250d0a,id:6,poolType:NetworkFilesystem,host:10.147.28.7,path:/export/home/shweta/goleta.lxc.primary1,port:2049,url:NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary1/?ROLE=PrimarySTOREUUID=2a4208e2-8f5e-3b6a-bede-315c90250d0a}},name:ROOT-76,size:550604800,path:1317fed3-0666-45b4-8849-0316206c58e7,volumeId:80,vmName:i-2-76-VM,accountId:2,provisioningType:THIN,id:80,deviceId:0,hypervisorType:LXC}},destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:1317fed3-0666-45b4-8849-0316206c58e7,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.147.28.7/export/home/shweta/goleta.lxc.secondary,_role:Image}},name:ROOT-76,size:550604800,path:volumes/2/80,volumeId:80,vmName:i-2-76-VM,accountId:2,provisioningType:THIN,id:80,deviceId:0,hypervisorType:LXC}},executeInSequence:false,options:{},wait:10800}}]
}
2014-08-22 16:37:03,665 DEBUG [c.c.a.t.Request] (AgentManager-Handler-2:null)
Seq 2-5838635441909144321: Processing: { Ans: , MgmtId: 233845178472597,
via: 2, Ver: v1, Flags: 10,
[{com.cloud.agent.api.Answer:{result:false,details:java.lang.NullPointerException\n\tat
com.cloud.hypervisor.kvm.storage.KVMStorageProcessor.copyVolumeFromPrimaryToSecondary(KVMStorageProcessor.java:438)\n\tat
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:89)\n\tat
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:53)\n\tat
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1356)\n\tat
com.cloud.agent.Agent.processRequest(Agent.java:503)\n\tat
com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:810)\n\tat
com.cloud.utils.nio.Task.run(Task.java:84)\n\tat
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)\n\tat
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n\tat
java.lang.Thread.run(Thread.java:744)\n,wait:0}}] }
2014-08-22 16:37:03,665 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-117:ctx-b8749277 job-640/job-641 ctx-3675a1df) Seq
2-5838635441909144321: Received: { Ans: , MgmtId: 233845178472597, via: 2,
Ver: v1, Flags: 10, { Answer } }
2014-08-22 16:37:03,665 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
(Work-Job-Executor-117:ctx-b8749277 job-640/job-641 ctx-3675a1df) copy to
image store failed: java.lang.NullPointerException
at
com.cloud.hypervisor.kvm.storage.KVMStorageProcessor.copyVolumeFromPrimaryToSecondary(KVMStorageProcessor.java:438)
at
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:89)
at
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:53)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1356)
at com.cloud.agent.Agent.processRequest(Agent.java:503)
at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:810)
at com.cloud.utils.nio.Task.run(Task.java:84)
at
[jira] [Created] (CLOUDSTACK-7539) [S3] Parallel deployment makes reference count of a cache in nfs secondary staging store negative(-1)
Hiroki Ohashi created CLOUDSTACK-7539:
-
Summary: [S3] Parallel deployment makes reference count of a cache
in nfs secondary staging store negative(-1)
Key: CLOUDSTACK-7539
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7539
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Storage Controller, Template
Affects Versions: Future, 4.3.0, 4.4.0, 4.5.0
Environment: OS: CentOS 6.5
CloudStack Version: 4.3.0
Hypervisor: KVM
Primary Storage: Local Storage
Secondary Storage: S3(RADOS)
Zone:Advanced
Reporter: Hiroki Ohashi
Priority: Critical
When we create some instances in parallel in an environment shown above, an
exception like ([#2]) happens. After that, reference count of a cache in NFS
Secondary Staging Store(SSS) becomes negative([#3]).
In this situcation, we can't use a template used for creating the instances
because negative reference count will cause another
exception([#4]). Furthermore, template caches in NFS SSS aren't cleaned up.
I think this is related to CLOUDSTACK-6236. I'm using CloudStack 4.3.0 branch.
The code was applied a patch of CLOUDSTACK-6236 to and also fixed about volume
reference count setter problem by myself. But the reference count problem still
happens.
Conditions to trigger
- A cache of a template isn't on NFS SSS.
- Choose compute offering that occupies all resources in a host.(ex. Use all
cores and almost all memory)
- Create multiple instances ([#1]).
Other behaviors
- Management server inserts multiple entries for template cache(ImageCache)
to cloud.template_store_ref.
- SSVM probably downloads same template from S3 and creates multiple caches
to NFS SSS concurrently. Sometimes, SSVM retries download and cache creation.
(1)
{anchor:1}
{noformat}
#! /bin/bash
COMPUTE_OFFERING=b6fc0598-6903-48cc-b894-ead3bb0e39f5
TEMPLATE=ef1d5a8e-5951-4036-a236-fe2d47224fe4
ZONE=23156857-4722-4fc4-86d4-a12ca1028197
NETWORK=4ba56179-f7b9-4560-a00e-80c946856ff8
KEYPAIR=mykey
NAME1=test-template-error-0003
NAME2=test-template-error-0004
cloudmonkey deploy virtualmachine serviceofferingid=${COMPUTE_OFFERING}
templateid=${TEMPLATE} zoneid=${ZONE} networkids=${NETWORK}
displayname=${NAME1} name=${NAME1} keypair=${KEYPAIR}
sleep 1
cloudmonkey deploy virtualmachine serviceofferingid=${COMPUTE_OFFERING}
templateid=${TEMPLATE} zoneid=${ZONE} networkids=${NETWORK}
displayname=${NAME2} name=${NAME2} keypair=${KEYPAIR}
{noformat}
(2)
{anchor:2}
{noformat}
2014-09-10 17:22:51,249 DEBUG [c.c.a.t.Request] (AgentManager-Handler-5:null)
Seq 171-1789133096: Processing: { Ans: , MgmtId: 98532524288, via: 171, Ver:
v1, Flags: 10,
[{org.apache.cloudstack.storage.command.CopyCmdAnswer:{newData:{org.apache.cloudstack.storage.to.TemplateObjectTO:{path:template/tmpl/3/330/22e69a40-0916-4d11-a07a-63d38e76887f.qcow2,id:0,accountId:0,hvm:false,name:22e69a40-0916-4d11-a07a-63d38e76887f.qcow2,size:14340259840,physicalSize:14340259840}},result:true,wait:0}}]
}
2014-09-10 17:22:51,249 DEBUG [c.c.a.t.Request] (Job-Executor-162:ctx-4a2eb345
ctx-fbf59f27) Seq 171-1789133096: Received: { Ans: , MgmtId: 98532524288, via:
171, Ver: v1, Flags: 10, { CopyCmdAnswer } }
2014-09-10 17:22:51,257 DEBUG [o.a.c.s.i.s.TemplateObject]
(Job-Executor-162:ctx-4a2eb345 ctx-fbf59f27) failed to update state
com.cloud.utils.fsm.NoTransitionException: Unable to transition to a new state
from Allocated via OperationSuccessed
at com.cloud.utils.fsm.StateMachine2.getNextState(StateMachine2.java:83)
at com.cloud.utils.fsm.StateMachine2.transitTo(StateMachine2.java:100)
at
org.apache.cloudstack.storage.datastore.ObjectInDataStoreManagerImpl.update(ObjectInDataStoreManagerImpl.java:297)
at
org.apache.cloudstack.storage.image.store.TemplateObject.processEvent(TemplateObject.java:225)
at
org.apache.cloudstack.storage.cache.manager.StorageCacheManagerImpl.createCacheObject(StorageCacheManagerImpl.java:240)
at
org.apache.cloudstack.storage.cache.manager.StorageCacheManagerImpl.createCacheObject(StorageCacheManagerImpl.java:267)
at
org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyObject(AncientDataMotionStrategy.java:165)
at
org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:428)
at
org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:70)
at
org.apache.cloudstack.storage.volume.VolumeServiceImpl.createBaseImageAsync(VolumeServiceImpl.java:473)
at
org.apache.cloudstack.storage.volume.VolumeServiceImpl.createVolumeFromTemplateAsync(VolumeServiceImpl.java:604)
at
[jira] [Closed] (CLOUDSTACK-4832) marvin requires cert when passing through https connections
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland closed CLOUDSTACK-4832. - marvin requires cert when passing through https connections --- Key: CLOUDSTACK-4832 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4832 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: Future Environment: dev Reporter: Daan Hoogland Assignee: Daan Hoogland Priority: Trivial Fix For: Future when working in dev or test envs with self signed certificates marvin won't work due to certificate validation. This seems overkill for a testtool. http.request get and post methods will be called with option verify=False -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7540) S2SVpnConnections:CheckRouterTask is fails with NullPointer exception
Jayapal Reddy created CLOUDSTACK-7540:
-
Summary: S2SVpnConnections:CheckRouterTask is fails with
NullPointer exception
Key: CLOUDSTACK-7540
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7540
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Network Controller
Affects Versions: 4.2.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
Fix For: 4.5.0
CheckRouterTask is failing with NullPointer exception and log is filling with
with this messages continuously
1. Create two VPCs
2. Create VPN customer gateway
3. Create VPN connection
When router is checking for vpn status getting NPE.
MS log:
Content of management log:
[c.c.a.t.Request] (StatsCollector-2:ctx-30b6f162) Seq 1-2611524833921479961:
Received: { Ans: , MgmtId: 7175246184473, via: 1, Ver: v1, Flags: 10,
{ GetStorageStatsAnswer } }
2014-07-01 15:10:31,002 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-287:ctx-67faca60) Seq 5-6290684254506525415: Executing request
2014-07-01 15:10:31,299 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-287:ctx-67faca60) Seq 5-6290684254506525415: Response Received:
2014-07-01 15:10:31,300 DEBUG [c.c.a.t.Request] (StatsCollector-2:ctx-30b6f162)
Seq 5-6290684254506525415: Received: { Ans: , MgmtId: 7175246184473, via: 5,
Ver: v1, Flags: 10, { GetStorageStatsAnswer }
}
2014-07-01 15:10:49,681 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(RouterStatusMonitor-1:ctx-b706b798) Found 9 routers to update status.
2014-07-01 15:10:49,692 DEBUG [c.c.a.t.Request]
(RouterStatusMonitor-1:ctx-b706b798) Seq 5-6290684254506525416: Sending { Cmd ,
MgmtId: 7175246184473, via: 5(Rack1Pod1Host9), Ver: v1, Flags: 100111,
[{com.cloud.agent.api.CheckS2SVpnConnectionsCommand:{vpnIps:[10.147.49.120],accessDetails:
{router.name:r-238-VM,router.ip:169.254.3.241}
,wait:30}}] }
2014-07-01 15:10:49,693 DEBUG [c.c.a.t.Request]
(RouterStatusMonitor-1:ctx-b706b798) Seq 5-6290684254506525416: Executing: {
Cmd , MgmtId: 7175246184473, via: 5(Rack1Pod1Host9), Ver: v1, Flags: 100111,
[{com.cloud.agent.api.CheckS2SVpnConnectionsCommand:{vpnIps:[10.147.49.120],accessDetails:
{router.name:r-238-VM,router.ip:169.254.3.241}
,wait:30}}] }
2014-07-01 15:10:49,693 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-288:ctx-328fc667) Seq 5-6290684254506525416: Executing request
2014-07-01 15:10:49,693 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-288:ctx-328fc667) Executing command in VR:
/opt/cloud/bin/router_proxy.sh checkbatchs2svpn.sh 169.254.3.241 10.147.49.120
2014-07-01 15:10:50,080 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-288:ctx-328fc667) Seq 5-6290684254506525416: Response Received:
2014-07-01 15:10:50,081 DEBUG [c.c.a.t.Request] (DirectAgent-288:ctx-328fc667)
Seq 5-6290684254506525416: Processing: { Ans: , MgmtId: 7175246184473, via: 5,
Ver: v1, Flags: 110,
[{com.cloud.agent.api.CheckS2SVpnConnectionsAnswer:{ipToConnected:{},ipToDetail:{},details:whack:
Pluto is not running (no
\/var/run/pluto/pluto.ctl\)\n10.147.49.120:11:ISAKMP SA NOT found but
checking IPsec;IPsec SA not found;Site-to-site VPN have not
connected,result:true,wait:0}}] }
2014-07-01 15:10:50,081 DEBUG [c.c.a.t.Request]
(RouterStatusMonitor-1:ctx-b706b798) Seq 5-6290684254506525416: Received: {
Ans: , MgmtId: 7175246184473, via: 5, Ver: v1, Flags: 110,
{ CheckS2SVpnConnectionsAnswer }
}
2014-07-01 15:10:50,081 DEBUG [c.c.a.m.AgentManagerImpl]
(RouterStatusMonitor-1:ctx-b706b798) Details from executing class
com.cloud.agent.api.CheckS2SVpnConnectionsCommand: whack: Pluto is not running
(no /var/run/pluto/pluto.ctl)
10.147.49.120:11:ISAKMP SA NOT found but checking IPsec;IPsec SA not
found;Site-to-site VPN have not connected
2014-07-01 15:10:50,084 DEBUG [c.c.a.m.AgentAttache]
(DirectAgent-288:ctx-328fc667) Seq 5-6290684254506525416: No more commands found
2014-07-01 15:10:50,091 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(RouterStatusMonitor-1:ctx-b706b798) Fail to complete the CheckRouterTask!
java.lang.NullPointerException
at
com.cloud.agent.api.CheckS2SVpnConnectionsAnswer.isConnected(CheckS2SVpnConnectionsAnswer.java:60)
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.updateSite2SiteVpnConnectionState(VirtualNetworkApplianceManagerImpl.java:1124)
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl$CheckRouterTask.runInContext(VirtualNetworkApplianceManagerImpl.java:1368)
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
[jira] [Created] (CLOUDSTACK-7541) Volume gets created with the size mentioned in the custom disk offering
Sanjeev N created CLOUDSTACK-7541:
-
Summary: 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
Priority: Critical
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=createDiskOfferingisMirrored=falsename=customdisplaytext=customstorageType=sharedcacheMode=noneprovisioningType=thincustomized=truedisksize=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=createVolumeresponse=jsonsessionkey=USf4e%2BpnzNiyWyq1PCeDFswjB%2BU%3Dname=customzoneId=2c67c83e-b8c3-42d0-a37b-b37287ac84dddiskOfferingId=2ddb8b79-9592-4b8c-8bd9-3d32c582873bsize=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-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
]
Sanjeev N updated CLOUDSTACK-7541:
--
Attachment: cloud.dmp
management-server.rar
Attache MS log file and cloud db dump.
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
Priority: Critical
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=createDiskOfferingisMirrored=falsename=customdisplaytext=customstorageType=sharedcacheMode=noneprovisioningType=thincustomized=truedisksize=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=createVolumeresponse=jsonsessionkey=USf4e%2BpnzNiyWyq1PCeDFswjB%2BU%3Dname=customzoneId=2c67c83e-b8c3-42d0-a37b-b37287ac84dddiskOfferingId=2ddb8b79-9592-4b8c-8bd9-3d32c582873bsize=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] [Commented] (CLOUDSTACK-6460) Migration of CLVM volumes to another primary storage fail
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131507#comment-14131507
]
Simon Weller commented on CLOUDSTACK-6460:
--
darrentang,
We're running 4.3 with this patch. Can you be a bit more specific when you say
it doesn't work?
Are you having problems applying the patch, or does a successful patch and
rebuild not fix the problem for you?
- Si
Migration of CLVM volumes to another primary storage fail
-
Key: CLOUDSTACK-6460
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6460
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Volumes
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
Environment: KVM clusters with fiber channel SAN storage, CLVM volumes
Reporter: Salvatore Sciacco
Attachments: cloudstack-6460.patch, cloudstack-6460_44.patch
ACS version: 4.2.1
Hypervisors: KVM
Storage pool type: CLVM
Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary
storage pool fail. I've enabled debug on the agents side and I think there is
a problem with the format type conversion
Volume on database had format QCOW2
these are the parameters for the first step (CLVM - NFS):
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:
uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
{quote}
Those commads are translated into the agent:
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing:
/bin/bash -c cp -f /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
/mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
{quote}
With the result that the output file isn't a qcow2 file but a raw partition,
which in turn make the next step fail.
(NFS - CLVM)
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
info
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
convert -f qcow2 -O raw
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
/dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not
open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to
convert
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was:
qemu-img: Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
{quote}
If I change on the database the format of the volume to RAW the effect is
even worse as data is lost in the process!
These are the parameter for the first step (CLVM = NFS)
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:655d6965-b3f3-4118-a970d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450
,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-4024450VM,accountId:402,format:RAW,id:5937,hypervisorType:KVM
[jira] [Commented] (CLOUDSTACK-6460) Migration of CLVM volumes to another primary storage fail
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131613#comment-14131613
]
darrentang commented on CLOUDSTACK-6460:
I mean: Maybe this patch is ok for migration base on clvm+kvm. but there is
still have some trouble ?
i'm trying to migration linux-vm from ClusterA to ClusterB,base on clvm+kvm.
Migration is done, no error ,everything is fine.and than , start vm, open the
console ,i got this message :no bootable device (system fails to boot)
output is converted to qcow2(CLVM-NFS):
qemu-img convert -f raw -O qcow2
/dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
/mnt/b8311c72-fe75-3832-98fc-975445028a12/01ab129f-aaf6-4b1a-8e2a-093bee0b811c.raw
maybe should be converted to raw :
qemu-img convert -f raw -O raw
/dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
/mnt/b8311c72-fe75-3832-98fc-975445028a12/01ab129f-aaf6-4b1a-8e2a-093bee0b811c.raw
If changed the output is converted to raw( by my manually, backing old lv and
converted to raw before migration start.), when migration is done,start vm,
system succes to boot.
Is that the case?
Migration of CLVM volumes to another primary storage fail
-
Key: CLOUDSTACK-6460
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6460
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Volumes
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
Environment: KVM clusters with fiber channel SAN storage, CLVM volumes
Reporter: Salvatore Sciacco
Attachments: cloudstack-6460.patch, cloudstack-6460_44.patch
ACS version: 4.2.1
Hypervisors: KVM
Storage pool type: CLVM
Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary
storage pool fail. I've enabled debug on the agents side and I think there is
a problem with the format type conversion
Volume on database had format QCOW2
these are the parameters for the first step (CLVM - NFS):
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:
uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
{quote}
Those commads are translated into the agent:
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing:
/bin/bash -c cp -f /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
/mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
{quote}
With the result that the output file isn't a qcow2 file but a raw partition,
which in turn make the next step fail.
(NFS - CLVM)
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
info
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
convert -f qcow2 -O raw
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
/dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not
open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to
convert
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was:
qemu-img: Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
[jira] [Commented] (CLOUDSTACK-6460) Migration of CLVM volumes to another primary storage fail
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14131620#comment-14131620
]
Simon Weller commented on CLOUDSTACK-6460:
--
I'll take a look and see if I can figure out what's going on.
Migration of CLVM volumes to another primary storage fail
-
Key: CLOUDSTACK-6460
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6460
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Volumes
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
Environment: KVM clusters with fiber channel SAN storage, CLVM volumes
Reporter: Salvatore Sciacco
Attachments: cloudstack-6460.patch, cloudstack-6460_44.patch
ACS version: 4.2.1
Hypervisors: KVM
Storage pool type: CLVM
Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary
storage pool fail. I've enabled debug on the agents side and I think there is
a problem with the format type conversion
Volume on database had format QCOW2
these are the parameters for the first step (CLVM - NFS):
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:
uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
{quote}
Those commads are translated into the agent:
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing:
/bin/bash -c cp -f /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
/mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
{quote}
With the result that the output file isn't a qcow2 file but a raw partition,
which in turn make the next step fail.
(NFS - CLVM)
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
info
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
convert -f qcow2 -O raw
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
/dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not
open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to
convert
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was:
qemu-img: Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
{quote}
If I change on the database the format of the volume to RAW the effect is
even worse as data is lost in the process!
These are the parameter for the first step (CLVM = NFS)
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:655d6965-b3f3-4118-a970d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450
,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-4024450VM,accountId:402,format:RAW,id:5937,hypervisorType:KVM
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
[jira] [Comment Edited] (CLOUDSTACK-6840) [OVS][UI] Ovs provider should not be displayed in NetworkServiceProviders if the physical network isolation type is VLAN
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14130344#comment-14130344 ] Jessica Wang edited comment on CLOUDSTACK-6840 at 9/12/14 5:59 PM: --- From: Sanjeev Neelarapu Sent: Thursday, September 11, 2014 10:18 PM To: Jessica Wang Subject: RE: CS-6840 was filed with respect to SDN feature. Here OVS refers to SDN provider. However we are not supporting SDN in Goleta. Jessica, Add it to advanced zone alone. -Sanjeev == From: Jessica Wang Sent: Thursday, September 11, 2014 10:59 PM To: Sanjeev Neelarapu Subject: RE: CS-6840 was filed with respect to SDN feature. Here OVS refers to SDN provider. However we are not supporting SDN in Goleta. Sanjeev, Okay, I’ll remove it from both Advanced zone and Basic Zone. Another question: When we support it for the next release, should I add it back to Advanced zone or Basic zone or both? Jessica == From: Sanjeev Neelarapu Sent: Wednesday, September 10, 2014 10:13 PM To: Jessica Wang Subject: RE: CS-6840 was filed with respect to SDN feature. Here OVS refers to SDN provider. However we are not supporting SDN in Goleta. Yes == From: Jessica Wang Sent: Wednesday, September 10, 2014 11:45 PM To: Sanjeev Neelarapu Subject: CS-6840 was filed with respect to SDN feature. Here OVS refers to SDN provider. However we are not supporting SDN in Goleta. Sanjeev, So, should I remove OVS from both Advanced zone and Basic zone in Goleta release? Jessica == From: Sanjeev Neelarapu Sent: Tuesday, September 09, 2014 9:45 PM To: Jessica Wang Subject: RE: Sanjeev, Is OVS only supported in Basic zone? Hi Jessica, CS-6840 was filed with respect to SDN feature. Here OVS refers to SDN provider. However we are not supporting SDN in Goleta. Thanks, Sanjeev == From: Jessica Wang Sent: Wednesday, September 10, 2014 4:30 AM To: Sanjeev Neelarapu Subject: Sanjeev, Is OVS only supported in Basic zone? Sanjeev, Is OVS only supported in Basic zone? Or OVS is supported in both Basic zone and Advanced zone? https://issues.apache.org/jira/browse/CLOUDSTACK-6840 Jessica was (Author: jessicawang): From: Sanjeev Neelarapu Sent: Wednesday, September 10, 2014 10:13 PM To: Jessica Wang Subject: RE: CS-6840 was filed with respect to SDN feature. Here OVS refers to SDN provider. However we are not supporting SDN in Goleta. Yes = From: Jessica Wang Sent: Wednesday, September 10, 2014 11:45 PM To: Sanjeev Neelarapu Subject: CS-6840 was filed with respect to SDN feature. Here OVS refers to SDN provider. However we are not supporting SDN in Goleta. Sanjeev, So, should I remove OVS from both Advanced zone and Basic zone in Goleta release? Jessica = From: Sanjeev Neelarapu Sent: Tuesday, September 09, 2014 9:45 PM To: Jessica Wang Subject: RE: Sanjeev, Is OVS only supported in Basic zone? Hi Jessica, CS-6840 was filed with respect to SDN feature. Here OVS refers to SDN provider. However we are not supporting SDN in Goleta. Thanks, Sanjeev [OVS][UI] Ovs provider should not be displayed in NetworkServiceProviders if the physical network isolation type is VLAN Key: CLOUDSTACK-6840 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6840 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.4.0 Environment: Latest build from 4.4. with commit 32bbc84db99d0e5f7f9b2a3fb41e4e783a2de350 Reporter: Sanjeev N Assignee: Jessica Wang Priority: Critical Labels: ovs Fix For: 4.5.0 Attachments: ovs_vlan.PNG [OVS][UI] Ovs provider should not be displayed in NetworkServiceProviders if the physical network isolation type is VLAN Steps to reproduce: == 1.Bring up CS in advanced zone with xen cluster 2.While creating physical network during zone creation choose VLAN as the isolation type 3.From UI navigate to Home-Infrastructure-Zones-CS-GRE-Physical Network 1-Network Service Providers Result: == NetworkServiceProviders page shows OVS as one of the providers and by default is in disabled state. Whereas
[jira] [Updated] (CLOUDSTACK-6460) Migration of CLVM volumes to another primary storage fail
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Weller updated CLOUDSTACK-6460:
-
Attachment: CLOUDSTACK-6460-darrentang.patch
Test patch for darrentang.
Migration of CLVM volumes to another primary storage fail
-
Key: CLOUDSTACK-6460
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6460
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Volumes
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
Environment: KVM clusters with fiber channel SAN storage, CLVM volumes
Reporter: Salvatore Sciacco
Attachments: CLOUDSTACK-6460-darrentang.patch, cloudstack-6460.patch,
cloudstack-6460_44.patch
ACS version: 4.2.1
Hypervisors: KVM
Storage pool type: CLVM
Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary
storage pool fail. I've enabled debug on the agents side and I think there is
a problem with the format type conversion
Volume on database had format QCOW2
these are the parameters for the first step (CLVM - NFS):
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:
uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
{quote}
Those commads are translated into the agent:
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing:
/bin/bash -c cp -f /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
/mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
{quote}
With the result that the output file isn't a qcow2 file but a raw partition,
which in turn make the next step fail.
(NFS - CLVM)
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
info
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
convert -f qcow2 -O raw
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
/dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not
open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to
convert
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was:
qemu-img: Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
{quote}
If I change on the database the format of the volume to RAW the effect is
even worse as data is lost in the process!
These are the parameter for the first step (CLVM = NFS)
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:655d6965-b3f3-4118-a970d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450
,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-4024450VM,accountId:402,format:RAW,id:5937,hypervisorType:KVM
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
[jira] [Commented] (CLOUDSTACK-6460) Migration of CLVM volumes to another primary storage fail
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14132110#comment-14132110
]
Simon Weller commented on CLOUDSTACK-6460:
--
darrentang,
I've uploaded a patch for you to test. All I've tested thus far is that is
compiles, but I haven't done a feature test yet with your issue. I'll try and
get to that this weekend, but I didn't want to hold you up if you have time to
test yourself.
The patch is against the 4.3 source tarball.
- Si
Migration of CLVM volumes to another primary storage fail
-
Key: CLOUDSTACK-6460
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6460
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM, Volumes
Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0
Environment: KVM clusters with fiber channel SAN storage, CLVM volumes
Reporter: Salvatore Sciacco
Attachments: CLOUDSTACK-6460-darrentang.patch, cloudstack-6460.patch,
cloudstack-6460_44.patch
ACS version: 4.2.1
Hypervisors: KVM
Storage pool type: CLVM
Since we upgraded from 4.1 to 4.2.1 moving volumes to a different primary
storage pool fail. I've enabled debug on the agents side and I think there is
a problem with the format type conversion
Volume on database had format QCOW2
these are the parameters for the first step (CLVM - NFS):
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:
uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:uuid:655d6965-b3f3-4118-a970-d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450,size:5368709120,path:39a25daf-23a1-4b65-99ac-fb98469ac197,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
destTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{com.cloud.agent.api.to.NfsTO:
_url:nfs://192.168.11.6/home/a1iwstack,_role:Image},name:ROOT-4450,size:5368709120,path:volumes/402/5937,volumeId:5937,vmName:i-402-4450-VM,accountId:402,format:QCOW2,id:5937,hypervisorType:KVM}
{quote}
Those commads are translated into the agent:
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing: qemu-img
info /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Execution is
successful.
DEBUG [utils.script.Script] (agentRequest-Handler-1:null) Executing:
/bin/bash -c cp -f /dev/FC10KY1/39a25daf-23a1-4b65-99ac-fb98469ac197
/mnt/b8311c72-fe75-3832-98fc-975445028a12/5c713376-c418-478c-8a31-89c4181cb48e.qcow2
{quote}
With the result that the output file isn't a qcow2 file but a raw partition,
which in turn make the next step fail.
(NFS - CLVM)
{quote}
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
info
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Execution is successful.
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Executing: qemu-img
convert -f qcow2 -O raw
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
/dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66
DEBUG [utils.script.Script] (agentRequest-Handler-2:) Exit value is 1
DEBUG [utils.script.Script] (agentRequest-Handler-2:) qemu-img: Could not
open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
ERROR [kvm.storage.LibvirtStorageAdaptor] (agentRequest-Handler-2:) Failed to
convert
/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2
to /dev/FCSTORAGE/da162325-467b-4e78-af07-4bad85470d66 the error was:
qemu-img: Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'qemu-img:
Could not open
'/mnt/b8311c72-fe75-3832-98fc-975445028a12/b9303d8d-cd51-4b6c-a244-43c405df4238.qcow2'
{quote}
If I change on the database the format of the volume to RAW the effect is
even worse as data is lost in the process!
These are the parameter for the first step (CLVM = NFS)
{quote}
srcTO:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:cda46430-52d7-4bf0-b0c2-adfc78dd011c,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:655d6965-b3f3-4118-a970d50cf6afc365,id:211,poolType:CLVM,host:localhost,path:/FC10KY1,port:0,name:ROOT-4450
[jira] [Updated] (CLOUDSTACK-7497) [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-7497: - Attachment: screenshot1.PNG [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC --- Key: CLOUDSTACK-7497 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7497 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: Jessica Wang Priority: Blocker Fix For: 4.5.0 Attachments: MS.tar.gz, cloud.dmp, screenshot1.PNG Repro steps: Create a LXC zone with 2 cluster one LXc and one KVM Create VM with LXC template Bug: Deploy vm fails as hypervisor type is passed as KVM 014-09-05 14:06:09,520 DEBUG [c.c.a.ApiServlet] (catalina-exec-8:ctx-7b5dcb24) ===START=== 10.146.0.131 -- GET command=deployVirtualMachineresponse=jsonsessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3Dzoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82atemplateid=2175190d-212a-4078-aedb-d25e4ddcdeb3hypervisor=KVMserviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810baffinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48_=1409906169711 2014-09-05 14:06:09,581 INFO [c.c.a.ApiServer] (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) Hypervisor passed to the deployVm call, is different from the hypervisor type of the template 2014-09-05 14:06:09,582 DEBUG [c.c.a.ApiServlet] (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) ===END=== 10.146.0.131 -- GET command=deployVirtualMachineresponse=jsonsessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3Dzoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82atemplateid=2175190d-212a-4078-aedb-d25e4ddcdeb3hypervisor=KVMserviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810baffinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48_=1409906169711 2014-09-05 14:06:12,573 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-6de2885c) Zone 2 is ready to launch secondary storage VM 2014-09-05 14:06:12,689 DEBUG [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-a134b2b7) Zone 2 is ready to launch console proxy -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7497) [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang reassigned CLOUDSTACK-7497: Assignee: shweta agarwal (was: Jessica Wang) Shweta, I just visited your web site. Which template did you choose in attachment screenshot1? Jessica [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC --- Key: CLOUDSTACK-7497 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7497 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: shweta agarwal Priority: Blocker Fix For: 4.5.0 Attachments: MS.tar.gz, cloud.dmp, screenshot1.PNG Repro steps: Create a LXC zone with 2 cluster one LXc and one KVM Create VM with LXC template Bug: Deploy vm fails as hypervisor type is passed as KVM 014-09-05 14:06:09,520 DEBUG [c.c.a.ApiServlet] (catalina-exec-8:ctx-7b5dcb24) ===START=== 10.146.0.131 -- GET command=deployVirtualMachineresponse=jsonsessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3Dzoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82atemplateid=2175190d-212a-4078-aedb-d25e4ddcdeb3hypervisor=KVMserviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810baffinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48_=1409906169711 2014-09-05 14:06:09,581 INFO [c.c.a.ApiServer] (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) Hypervisor passed to the deployVm call, is different from the hypervisor type of the template 2014-09-05 14:06:09,582 DEBUG [c.c.a.ApiServlet] (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) ===END=== 10.146.0.131 -- GET command=deployVirtualMachineresponse=jsonsessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3Dzoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82atemplateid=2175190d-212a-4078-aedb-d25e4ddcdeb3hypervisor=KVMserviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810baffinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48_=1409906169711 2014-09-05 14:06:12,573 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-6de2885c) Zone 2 is ready to launch secondary storage VM 2014-09-05 14:06:12,689 DEBUG [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-a134b2b7) Zone 2 is ready to launch console proxy -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7518) SSVM stop/start is not initiating the download for Partially downloaded ISO's
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-7518: --- Assignee: edison su SSVM stop/start is not initiating the download for Partially downloaded ISO's -- Key: CLOUDSTACK-7518 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7518 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Template, XenServer Affects Versions: 4.5.0 Reporter: Sailaja Mada Assignee: edison su Priority: Critical Fix For: 4.5.0 Attachments: isologs.zip, ssvmlogs.zip Setup: 1. Configure Adv Zone with XS 6.5 2. Register Windows 2012 ISO , Waited for it to download 20% 3. Stop SSVM 4. ISO details gets the status as SSVM Agent disconnected 5. Start SSVM Observation: SSVM stop/start is not initiating the download for Partially downloaded templates/ISO's -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7497) [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14132194#comment-14132194 ] Jessica Wang edited comment on CLOUDSTACK-7497 at 9/12/14 10:08 PM: Shweta, I just visited your web site. Which template did you choose in attachment screenshot1? (1) http://10.147.28.7/templates/lxc/rhel-7-loaded-x86_64.tar.gz; or (2) http://10.147.28.7/templates/lxc-templates/Centos6-final.tar.gz; or (3) http://10.147.28.7/releases/2.2.0/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2; ? Jessica was (Author: jessicawang): Shweta, I just visited your web site. Which template did you choose in attachment screenshot1? Jessica [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC --- Key: CLOUDSTACK-7497 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7497 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: shweta agarwal Priority: Blocker Fix For: 4.5.0 Attachments: MS.tar.gz, cloud.dmp, screenshot1.PNG Repro steps: Create a LXC zone with 2 cluster one LXc and one KVM Create VM with LXC template Bug: Deploy vm fails as hypervisor type is passed as KVM 014-09-05 14:06:09,520 DEBUG [c.c.a.ApiServlet] (catalina-exec-8:ctx-7b5dcb24) ===START=== 10.146.0.131 -- GET command=deployVirtualMachineresponse=jsonsessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3Dzoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82atemplateid=2175190d-212a-4078-aedb-d25e4ddcdeb3hypervisor=KVMserviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810baffinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48_=1409906169711 2014-09-05 14:06:09,581 INFO [c.c.a.ApiServer] (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) Hypervisor passed to the deployVm call, is different from the hypervisor type of the template 2014-09-05 14:06:09,582 DEBUG [c.c.a.ApiServlet] (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) ===END=== 10.146.0.131 -- GET command=deployVirtualMachineresponse=jsonsessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3Dzoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82atemplateid=2175190d-212a-4078-aedb-d25e4ddcdeb3hypervisor=KVMserviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810baffinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48_=1409906169711 2014-09-05 14:06:12,573 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-6de2885c) Zone 2 is ready to launch secondary storage VM 2014-09-05 14:06:12,689 DEBUG [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-a134b2b7) Zone 2 is ready to launch console proxy -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7497) [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14132194#comment-14132194 ] Jessica Wang edited comment on CLOUDSTACK-7497 at 9/12/14 10:29 PM: Shweta, I just visited your web site. Which template did you choose in attachment shweta_website? (1) http://10.147.28.7/templates/lxc/rhel-7-loaded-x86_64.tar.gz; or (2) http://10.147.28.7/templates/lxc-templates/Centos6-final.tar.gz; or (3) http://10.147.28.7/releases/2.2.0/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2; ? Jessica was (Author: jessicawang): Shweta, I just visited your web site. Which template did you choose in attachment screenshot1? (1) http://10.147.28.7/templates/lxc/rhel-7-loaded-x86_64.tar.gz; or (2) http://10.147.28.7/templates/lxc-templates/Centos6-final.tar.gz; or (3) http://10.147.28.7/releases/2.2.0/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2; ? Jessica [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC --- Key: CLOUDSTACK-7497 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7497 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: shweta agarwal Priority: Blocker Fix For: 4.5.0 Attachments: MS.tar.gz, cloud.dmp, shweta_website.PNG Repro steps: Create a LXC zone with 2 cluster one LXc and one KVM Create VM with LXC template Bug: Deploy vm fails as hypervisor type is passed as KVM 014-09-05 14:06:09,520 DEBUG [c.c.a.ApiServlet] (catalina-exec-8:ctx-7b5dcb24) ===START=== 10.146.0.131 -- GET command=deployVirtualMachineresponse=jsonsessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3Dzoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82atemplateid=2175190d-212a-4078-aedb-d25e4ddcdeb3hypervisor=KVMserviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810baffinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48_=1409906169711 2014-09-05 14:06:09,581 INFO [c.c.a.ApiServer] (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) Hypervisor passed to the deployVm call, is different from the hypervisor type of the template 2014-09-05 14:06:09,582 DEBUG [c.c.a.ApiServlet] (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) ===END=== 10.146.0.131 -- GET command=deployVirtualMachineresponse=jsonsessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3Dzoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82atemplateid=2175190d-212a-4078-aedb-d25e4ddcdeb3hypervisor=KVMserviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810baffinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48_=1409906169711 2014-09-05 14:06:12,573 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-6de2885c) Zone 2 is ready to launch secondary storage VM 2014-09-05 14:06:12,689 DEBUG [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-a134b2b7) Zone 2 is ready to launch console proxy -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7497) [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-7497: - Attachment: shweta_website.PNG [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC --- Key: CLOUDSTACK-7497 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7497 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: shweta agarwal Priority: Blocker Fix For: 4.5.0 Attachments: MS.tar.gz, cloud.dmp, shweta_website.PNG Repro steps: Create a LXC zone with 2 cluster one LXc and one KVM Create VM with LXC template Bug: Deploy vm fails as hypervisor type is passed as KVM 014-09-05 14:06:09,520 DEBUG [c.c.a.ApiServlet] (catalina-exec-8:ctx-7b5dcb24) ===START=== 10.146.0.131 -- GET command=deployVirtualMachineresponse=jsonsessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3Dzoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82atemplateid=2175190d-212a-4078-aedb-d25e4ddcdeb3hypervisor=KVMserviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810baffinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48_=1409906169711 2014-09-05 14:06:09,581 INFO [c.c.a.ApiServer] (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) Hypervisor passed to the deployVm call, is different from the hypervisor type of the template 2014-09-05 14:06:09,582 DEBUG [c.c.a.ApiServlet] (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) ===END=== 10.146.0.131 -- GET command=deployVirtualMachineresponse=jsonsessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3Dzoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82atemplateid=2175190d-212a-4078-aedb-d25e4ddcdeb3hypervisor=KVMserviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810baffinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48_=1409906169711 2014-09-05 14:06:12,573 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-6de2885c) Zone 2 is ready to launch secondary storage VM 2014-09-05 14:06:12,689 DEBUG [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-a134b2b7) Zone 2 is ready to launch console proxy -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7497) [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14132194#comment-14132194 ] Jessica Wang edited comment on CLOUDSTACK-7497 at 9/12/14 10:29 PM: Shweta, I just visited your web site. Which template did you choose in attachment shweta_website.PNG? (1) http://10.147.28.7/templates/lxc/rhel-7-loaded-x86_64.tar.gz; or (2) http://10.147.28.7/templates/lxc-templates/Centos6-final.tar.gz; or (3) http://10.147.28.7/releases/2.2.0/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2; ? Jessica was (Author: jessicawang): Shweta, I just visited your web site. Which template did you choose in attachment shweta_website? (1) http://10.147.28.7/templates/lxc/rhel-7-loaded-x86_64.tar.gz; or (2) http://10.147.28.7/templates/lxc-templates/Centos6-final.tar.gz; or (3) http://10.147.28.7/releases/2.2.0/eec2209b-9875-3c8d-92be-c001bd8a0faf.qcow2.bz2; ? Jessica [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC --- Key: CLOUDSTACK-7497 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7497 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: shweta agarwal Priority: Blocker Fix For: 4.5.0 Attachments: MS.tar.gz, cloud.dmp, shweta_website.PNG Repro steps: Create a LXC zone with 2 cluster one LXc and one KVM Create VM with LXC template Bug: Deploy vm fails as hypervisor type is passed as KVM 014-09-05 14:06:09,520 DEBUG [c.c.a.ApiServlet] (catalina-exec-8:ctx-7b5dcb24) ===START=== 10.146.0.131 -- GET command=deployVirtualMachineresponse=jsonsessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3Dzoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82atemplateid=2175190d-212a-4078-aedb-d25e4ddcdeb3hypervisor=KVMserviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810baffinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48_=1409906169711 2014-09-05 14:06:09,581 INFO [c.c.a.ApiServer] (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) Hypervisor passed to the deployVm call, is different from the hypervisor type of the template 2014-09-05 14:06:09,582 DEBUG [c.c.a.ApiServlet] (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) ===END=== 10.146.0.131 -- GET command=deployVirtualMachineresponse=jsonsessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3Dzoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82atemplateid=2175190d-212a-4078-aedb-d25e4ddcdeb3hypervisor=KVMserviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810baffinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48_=1409906169711 2014-09-05 14:06:12,573 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-6de2885c) Zone 2 is ready to launch secondary storage VM 2014-09-05 14:06:12,689 DEBUG [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-a134b2b7) Zone 2 is ready to launch console proxy -- This message was sent by Atlassian JIRA (v6.3.4#6332)
