[jira] [Updated] (CLOUDSTACK-5578) KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-5578: -- Summary: KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary (was: KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary.) > KVM - Network down - When the host looses network connectivity , reboot stuck > while unmounting primary > -- > > Key: CLOUDSTACK-5578 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5578 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.5.0 > > Attachments: DisconnectedHost.png, kvm-hostdisconnect.rar > > > KVM - Network down - When the host looses network connectivity , it is not > able to fence itself. > Steps to reproduce the problem: > Set up - Advanced zone with 2 Rhel 6.3 hosts in cluster. > Deploy ~10 Vms. > Simulate network disconnect on the host ( ifdown em1) > Host gets marked as "Down" and all the Vms gets HA-ed to the other host. > On the KVM host which lost connectivity , attempt to shutdown itself fails. > It was not able to umount the primary store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5578) KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-5578: -- Summary: KVM - Network down - When the host looses network connectivity , reboot stuck while unmounting primary. (was: KVM - Network down - When the host looses network connectivity , it is not able to fence itself.) > KVM - Network down - When the host looses network connectivity , reboot stuck > while unmounting primary. > --- > > Key: CLOUDSTACK-5578 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5578 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.5.0 > > Attachments: DisconnectedHost.png, kvm-hostdisconnect.rar > > > KVM - Network down - When the host looses network connectivity , it is not > able to fence itself. > Steps to reproduce the problem: > Set up - Advanced zone with 2 Rhel 6.3 hosts in cluster. > Deploy ~10 Vms. > Simulate network disconnect on the host ( ifdown em1) > Host gets marked as "Down" and all the Vms gets HA-ed to the other host. > On the KVM host which lost connectivity , attempt to shutdown itself fails. > It was not able to umount the primary store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5324) error message not proper when start VM fails because router requires upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-5324: -- Summary: error message not proper when start VM fails because router requires upgrade (was: error message not proper when start VM fails because router reuires upgrade) > error message not proper when start VM fails because router requires upgrade > - > > Key: CLOUDSTACK-5324 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5324 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.3.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala > Fix For: 4.4.0, 4.5.0 > > > Repro steps: > Create a VM on 3.07 setup > Upgrade to 4.3.0 but dont upgrade routers > Stop user VM > Start user VM > Bug: > Error message shows "Unable to start a VM due to concurrent operation > Expectation : > Error message should show " router requires upgrade " > MS log snippet : > 2013-12-02 12:28:09,029 ERROR [c.c.v.VirtualMachineManagerImpl] > (Job-Executor-9:ctx-1bf286cd ctx-4cabd091) Failed to start instance > VM[User|f01ae0d5-23b3-44c4-9e8d-9df9245874be] > com.cloud.utils.exception.CloudRuntimeException: Router requires upgrade. > Unable to send command to router:4 > at > com.cloud.network.router.VirtualNetworkApplianceManagerImpl.sendCommandsToRouter(VirtualNetworkApplianceManagerImpl.java:3437) > at > com.cloud.network.router.VirtualNetworkApplianceManagerImpl$7.execute(VirtualNetworkApplianceManagerImpl.java:2873) > at > com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:3722) > at > com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyDhcpEntry(VirtualNetworkApplianceManagerImpl.java:2865) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:622) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy239.applyDhcpEntry(Unknown Source) > at > com.cloud.network.element.VirtualRouterElement.addDhcpEntry(VirtualRouterElement.java:914) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareElement(NetworkOrchestrator.java:1171) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNic(NetworkOrchestrator.java:1293) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1229) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:899) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:706) > at > com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:552) > at > org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:236) > at > org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) > at > com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3465) > at > com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:1921) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:622) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(
[jira] [Updated] (CLOUDSTACK-7300) Cannot create Snapshot on KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7300: - Status: Reviewable (was: In Progress) > Cannot create Snapshot on KVM > - > > Key: CLOUDSTACK-7300 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7300 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Snapshot >Affects Versions: 4.4.0 > Environment: KVM on CentOS >Reporter: Prieur Leary >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.4.1 > > > Cannot create volume Snapshots on KVM. > 1. Creating a Snapshot says successful. > 2. When viewing the actual Snapshot, it shows "Error" status. > 3. Management Server Logs the error below. > 4. It seems the Snapshot is attempting to be copied to a path that is not > mounted (Sec Storage Snapshots). > 5. Have restarted Agent, SSVM, and management server. Has not corrected. > -- > 2014-08-09 14:31:18,321 DEBUG [c.c.s.s.SnapshotManagerImpl] > (Work-Job-Executor-12:ctx-013228d1 job-95851/job-95852 ctx-38207feb) Failed > to create snapshot > com.cloud.utils.exception.CloudRuntimeException: Failed to backup > c498663d-5986-4ee1-a864-bf99a7fab48d for disk > /mnt/cdad7fd2-36fe-37f3-bba2-04acb043ea78/f07a87ad-b5c9-4932-9328-0ebd67967f04 > to /m$ > at > org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.backupSnapshot(SnapshotServiceImpl.java:282) > at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.backupSnapshot(XenserverSnapshotStrategy.java:137) > at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:300) > at > com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:922) > 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:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy178.takeSnapshot(Unknown Source) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1738) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2475) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.Del > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy178.takeSnapshot(Unknown Source) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1738) > at > com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2475) > 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:606) > at > com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) > at > com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2483) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at
[jira] [Resolved] (CLOUDSTACK-7004) [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-7004. -- Resolution: Cannot Reproduce > [Automation] [KVM] Deploying a VM with rootdisksize less than the size of > template does not fail > > > Key: CLOUDSTACK-7004 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7004 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Automation, KVM >Affects Versions: 4.4.0 > Environment: KVM >Reporter: Gaurav Aradhye >Assignee: Bharat Kumar > Labels: api, automation, kvm > Fix For: 4.5.0 > > > Deploy a VM with parameter rootdisksize less than the template size. > API should throw error for this but it succeeds. > Although the root disk size of deployed VM is equal to template size in this > case, but this operation should throw error and VM should not be deployed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7004) [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7004: - Fix Version/s: (was: 4.4.0) > [Automation] [KVM] Deploying a VM with rootdisksize less than the size of > template does not fail > > > Key: CLOUDSTACK-7004 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7004 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Automation, KVM >Affects Versions: 4.4.0 > Environment: KVM >Reporter: Gaurav Aradhye >Assignee: Bharat Kumar > Labels: api, automation, kvm > Fix For: 4.5.0 > > > Deploy a VM with parameter rootdisksize less than the template size. > API should throw error for this but it succeeds. > Although the root disk size of deployed VM is equal to template size in this > case, but this operation should throw error and VM should not be deployed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7922) CLONE - [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7922: - Fix Version/s: (was: 4.5.0) > CLONE - [Automation] [KVM] Deploying a VM with rootdisksize less than the > size of template does not fail > > > Key: CLOUDSTACK-7922 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7922 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Automation, KVM >Affects Versions: 4.4.0 > Environment: KVM >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Labels: api, automation, kvm > Fix For: 4.4.0 > > > Deploy a VM with parameter rootdisksize less than the template size. > API should throw error for this but it succeeds. > Although the root disk size of deployed VM is equal to template size in this > case, but this operation should throw error and VM should not be deployed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7922) CLONE - [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail
Bharat Kumar created CLOUDSTACK-7922: Summary: CLONE - [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail Key: CLOUDSTACK-7922 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7922 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API, Automation, KVM Affects Versions: 4.4.0 Environment: KVM Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.4.0, 4.5.0 Deploy a VM with parameter rootdisksize less than the template size. API should throw error for this but it succeeds. Although the root disk size of deployed VM is equal to template size in this case, but this operation should throw error and VM should not be deployed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7921) Add Template Refresh Option
Michael Phillips created CLOUDSTACK-7921: Summary: Add Template Refresh Option Key: CLOUDSTACK-7921 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7921 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Reporter: Michael Phillips I. Proposal I would like to propose a new function in which we have the ability to refresh a template. OS templates need to be refreshed every so often to update things like OS patches and software. II. Current Method Currently the only way to refresh a template is to delete the old template, then upload the new template. III. The issue There are 3rd party apps out there, such as hostbill, that use cloudstack for vm provisioning. When a template is created it seems the template gets assigned a unique GUID in the database. When you refresh the template by deleting and re-uploading, the new template has a new GUID which breaks any connections to the old template. IV. How to possibly solve Have a new function to refresh a template. Refreshing the template would reuse all the info from the old template, but would just replace the templates disk file with the new one. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7602) [Automation] Unable to Delete Network if VM in that network is in Error State
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sheng Yang closed CLOUDSTACK-7602.
--
Resolution: Won't Fix
The transition steps defined that VM have to be expunged, even for error state.
It's by design.
s_fsm.addTransition(new Transition(State.Error,
VirtualMachine.Event.DestroyRequested, State.Expunging, null));
s_fsm.addTransition(new Transition(State.Error,
VirtualMachine.Event.ExpungeOperation, State.Expunging, null));
> [Automation] Unable to Delete Network if VM in that network is in Error State
> -
>
> Key: CLOUDSTACK-7602
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7602
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Sheng Yang
>Priority: Critical
> Fix For: 4.5.0
>
>
> *Unable to Delete Network: Job Information*
> {noformat}
> 2014-09-21 14:38:24,308 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-17:ctx-9b725e1f ctx-b0e7426d ctx-bbfcaa45) submit async
> job-1958, details: AsyncJobVO {id:1958, userId: 2, accountId: 2,
> instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.network.DeleteNetworkCmd, cmdInfo:
> {"id":"0029ccf7-f8e6-4b6d-ab63-7c67b44806f6","response":"json","ctxDetails":"{\"com.cloud.network.Network\":\"0029ccf7-f8e6-4b6d-ab63-7c67b44806f6\"}","cmdEventType":"NETWORK.DELETE","ctxUserId":"2","httpmethod":"GET","uuid":"0029ccf7-f8e6-4b6d-ab63-7c67b44806f6","ctxAccountId":"2","ctxStartEventId":"6339","apiKey":"mLrTCdYRf3-d4xO7DnO-QXw1Uqrdae1uxenHTEPj_ulDpIYTaujsXwkNzARz222s6M4xChsTAE2W-TUur5bKNQ","signature":"l+/5Sc1Vu4dbLXfFKXoz3lCLJeE\u003d"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 16226561876200, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-09-21 14:38:24,309 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-96:ctx-cc8b54bc job-1958) Add job-1958 into job monitoring
> 2014-09-21 14:38:24,309 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-96:ctx-cc8b54bc job-1958) Executing AsyncJobVO {id:1958,
> userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.network.DeleteNetworkCmd, cmdInfo:
> {"id":"0029ccf7-f8e6-4b6d-ab63-7c67b44806f6","response":"json","ctxDetails":"{\"com.cloud.network.Network\":\"0029ccf7-f8e6-4b6d-ab63-7c67b44806f6\"}","cmdEventType":"NETWORK.DELETE","ctxUserId":"2","httpmethod":"GET","uuid":"0029ccf7-f8e6-4b6d-ab63-7c67b44806f6","ctxAccountId":"2","ctxStartEventId":"6339","apiKey":"mLrTCdYRf3-d4xO7DnO-QXw1Uqrdae1uxenHTEPj_ulDpIYTaujsXwkNzARz222s6M4xChsTAE2W-TUur5bKNQ","signature":"l+/5Sc1Vu4dbLXfFKXoz3lCLJeE\u003d"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 16226561876200, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-09-21 14:38:24,309 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-17:ctx-9b725e1f ctx-b0e7426d ctx-bbfcaa45) ===END===
> 10.81.29.29 -- GET
> id=0029ccf7-f8e6-4b6d-ab63-7c67b44806f6&apiKey=mLrTCdYRf3-d4xO7DnO-QXw1Uqrdae1uxenHTEPj_ulDpIYTaujsXwkNzARz222s6M4xChsTAE2W-TUur5bKNQ&command=deleteNetwork&response=json&signature=l%2B%2F5Sc1Vu4dbLXfFKXoz3lCLJeE%3D
> 2014-09-21 14:38:24,313 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-19:ctx-ae6b8223) ===START=== 10.81.29.29 -- GET
> jobid=e66d3b42-a80b-44e6-88ca-6187a0a59805&apiKey=mLrTCdYRf3-d4xO7DnO-QXw1Uqrdae1uxenHTEPj_ulDpIYTaujsXwkNzARz222s6M4xChsTAE2W-TUur5bKNQ&command=queryAsyncJobResult&response=json&signature=HbvmeX6dxeewpVSQEf2XtK32TTo%3D
> 2014-09-21 14:38:24,338 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-19:ctx-ae6b8223 ctx-323291e2 ctx-9a4b6c85) ===END===
> 10.81.29.29 -- GET
> jobid=e66d3b42-a80b-44e6-88ca-6187a0a59805&apiKey=mLrTCdYRf3-d4xO7DnO-QXw1Uqrdae1uxenHTEPj_ulDpIYTaujsXwkNzARz222s6M4xChsTAE2W-TUur5bKNQ&command=queryAsyncJobResult&response=json&signature=HbvmeX6dxeewpVSQEf2XtK32TTo%3D
> 2014-09-21 14:38:24,342 WARN [o.a.c.e.o.NetworkOrchestrator]
> (API-Job-Executor-96:ctx-cc8b54bc job-1958 ctx-9572a853) Can't delete the
> network, not all user vms are expunged. Vm VM[User|i-115-279-VM] is in Error
> state
> 2014-09-21 14:38:24,354 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-96:ctx-cc8b54bc job-1958) Complete async job-1958,
> jobStatus: FAILED, resultCode: 530, result:
> org.apache.cloudstack.api.response.ExceptionResponse/null/{"uuidList":[],"errorcode":530,"errortext":"Failed
> to delete network"}
> 2014-09-21 14:38:24,355 DEBUG [o.a.
[jira] [Resolved] (CLOUDSTACK-6718) [OVS][UI] Isolated network offering (non-vpc) creation page shows ovs as the service provider for services other than "VirtualNetworking"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang resolved CLOUDSTACK-6718. Resolution: Not a Problem Commit d935d3865aa2a4fb39709f6943f02f9f5a422aff and following ones add these features to OVS element. > [OVS][UI] Isolated network offering (non-vpc) creation page shows ovs as the > service provider for services other than "VirtualNetworking" > - > > Key: CLOUDSTACK-6718 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6718 > 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: Latest build from 4.4 with commit > e6961fd21bb6d793302c234d0f409f66dc498072 >Reporter: Sanjeev N >Assignee: Sheng Yang >Priority: Critical > Labels: ovs, ui > Fix For: 4.4.0, 4.5.0 > > Attachments: ovs_no.PNG > > > [OVS][UI] Isolated network offering (non-vpc) creation page shows ovs as the > service provider for services other than "VirtualNetworking" > Steps to Reprodude: > > 1.Bring up CS in advanced zone > 2.In UI navigate to Service Offerings -> Network Offerings-> and click > on Add Network Offering and choose Guest Type as Isolated. > 3.In Supported Services section in Network offering creation page the drop > down list for LB,StaticNAT and PF services show OVS as one of the supported > service providers > But OVS does not support those services. > Attaching screen shot to describe the issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7920) NPE in Volume sync causing ssvm agent to not connect
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta resolved CLOUDSTACK-7920. - Resolution: Fixed > NPE in Volume sync causing ssvm agent to not connect > - > > Key: CLOUDSTACK-7920 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7920 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Critical > Fix For: 4.6.0 > > > NPE in Volume sync causing ssvm agent to not connect -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7176) vmware:default route is wrongly configured when deploy a vm with multiple networks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang resolved CLOUDSTACK-7176. Resolution: Won't Fix I don't think it's reasonable case that put a VM into two SAME CIDR network. Both network are 10.1.1.1/24, routing information wouldn't able to tell which 10.1.1.1 you want to access. > vmware:default route is wrongly configured when deploy a vm with multiple > networks > -- > > Key: CLOUDSTACK-7176 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7176 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: sadhu suresh >Assignee: Sheng Yang > Fix For: 4.5.0 > > > 1.create 2 isolated networks from UI > 2.deploy a vm by selecting the above 2 network and making second network as > default network. > 3.Once VM is deployed ,from UI select the default network(i.e network 2) and > configured the portforwarding/firewall rules on port 22 > 4. check ssh access to guestvm(10.1.1.36) > actual result: > unable to ssh to guest vm and when we check the route table , the gateway > is point to eth1 interface instead of pointing to eth0 > due to this when we ssh to guest vm and it fail to due to connection refused > . > [root@VM-63a1e50b-a2a6-478a-b4d9-86173b9c3b36 ~]# route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric RefUse Iface > 10.1.1.00.0.0.0 255.255.255.0 U 0 00 eth0 > 10.1.1.00.0.0.0 255.255.255.0 U 0 00 eth1 > 169.254.0.0 0.0.0.0 255.255.0.0 U 0 00 eth1 > 0.0.0.0 10.1.1.10.0.0.0 UG0 00 eth1 > [root@VM-63a1e50b-a2a6-478a-b4d9-86173b9c3b36 ~]# ifconfig -a > eth0 Link encap:Ethernet HWaddr 02:00:62:EB:00:01 > inet addr:10.1.1.36 Bcast:10.1.1.255 Mask:255.255.255.0 > inet6 addr: fe80::62ff:feeb:1/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:551 errors:0 dropped:0 overruns:0 frame:0 > TX packets:436 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:53694 (52.4 KiB) TX bytes:57105 (55.7 KiB) > Base address:0x2000 Memory:d102-d104 > eth1 Link encap:Ethernet HWaddr 02:00:5E:D9:00:01 > inet addr:10.1.1.48 Bcast:10.1.1.255 Mask:255.255.255.0 > inet6 addr: fe80::5eff:fed9:1/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:119 errors:0 dropped:0 overruns:0 frame:0 > TX packets:509 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:7906 (7.7 KiB) TX bytes:43829 (42.8 KiB) > Base address:0x2040 Memory:d104-d106 > loLink encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:32 errors:0 dropped:0 overruns:0 frame:0 > TX packets:32 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:4334 (4.2 KiB) TX bytes:4334 (4.2 KiB) > sit0 Link encap:IPv6-in-IPv4 > NOARP MTU:1480 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > NIC 1 (Default) > IDd66e7992-136b-4f10-9d76-48813347871b > Network Name two > Type Isolated > IP Address10.1.1.36 > Gateway 10.1.1.1 > Netmask 255.255.255.0 > IPv6 IP Address > IPv6 Gateway > IPv6 CIDR > Is DefaultYes > NIC 2 > > > IDbb49621f-a1f3-40fc-8416-a295c390a7c7 > Network Name one111 > Type Isolated > IP Address10.1.1.48 > Gateway 10.1.1.1 > Netmask 255.255.255.0 > IPv6 IP Address > IPv6 Gateway > IPv6 CIDR > Is DefaultNo -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7920) NPE in Volume sync causing ssvm agent to not connect
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14213136#comment-14213136 ] ASF subversion and git services commented on CLOUDSTACK-7920: - Commit 5213401ace08f4a5247a325e9d99a4a66bd7df11 in cloudstack's branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5213401 ] CLOUDSTACK-7920: NPE in the payload was causing the ssvm agent to not connect, fix it and also make sure that template/volume sync are robust that exceptions do not cause ssvm agent disconnect issues. > NPE in Volume sync causing ssvm agent to not connect > - > > Key: CLOUDSTACK-7920 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7920 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Critical > Fix For: 4.6.0 > > > NPE in Volume sync causing ssvm agent to not connect -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7920) NPE in Volume sync causing ssvm agent to not connect
Nitin Mehta created CLOUDSTACK-7920: --- Summary: NPE in Volume sync causing ssvm agent to not connect Key: CLOUDSTACK-7920 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7920 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.6.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Priority: Critical Fix For: 4.6.0 NPE in Volume sync causing ssvm agent to not connect -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6718) [OVS][UI] Isolated network offering (non-vpc) creation page shows ovs as the service provider for services other than "VirtualNetworking"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14213032#comment-14213032 ] Sheng Yang commented on CLOUDSTACK-6718: I do see code handling pf/lb/static nat in OvsElement.java, why it's not supported? > [OVS][UI] Isolated network offering (non-vpc) creation page shows ovs as the > service provider for services other than "VirtualNetworking" > - > > Key: CLOUDSTACK-6718 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6718 > 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: Latest build from 4.4 with commit > e6961fd21bb6d793302c234d0f409f66dc498072 >Reporter: Sanjeev N >Assignee: Sheng Yang >Priority: Critical > Labels: ovs, ui > Fix For: 4.4.0, 4.5.0 > > Attachments: ovs_no.PNG > > > [OVS][UI] Isolated network offering (non-vpc) creation page shows ovs as the > service provider for services other than "VirtualNetworking" > Steps to Reprodude: > > 1.Bring up CS in advanced zone > 2.In UI navigate to Service Offerings -> Network Offerings-> and click > on Add Network Offering and choose Guest Type as Isolated. > 3.In Supported Services section in Network offering creation page the drop > down list for LB,StaticNAT and PF services show OVS as one of the supported > service providers > But OVS does not support those services. > Attaching screen shot to describe the issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7919) In vmware, when host crashed and the VR migrated because of HA, Vmsync didnt notice a change in the state and so didnt reprogram the VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta resolved CLOUDSTACK-7919. - Resolution: Fixed > In vmware, when host crashed and the VR migrated because of HA, Vmsync didnt > notice a change in the state and so didnt reprogram the VR > --- > > Key: CLOUDSTACK-7919 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7919 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Critical > Fix For: 4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7857) CitrixResourceBase wrongly calculates total memory on hosts with a lot of memory and large Dom0
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14213016#comment-14213016
]
Anthony Xu commented on CLOUDSTACK-7857:
_xs_memory_used is used as memory virtualization overhead in this XS host, but
the memory overhead varies a lot depending on the total host free memory, VM
density, VM memory size, VM guest OS type ...
to me, there seems no way to know the precise memory virtualization overhead
before you use the host to run VMs,
There are two ways CloudStack provides to mitigate this,
1. retry mechanism,
cloudstack uses retry in many places, like deployVM, startVM, migrateVM,
2. threshold,
cluster.memory.allocated.capacity.disablethreshold
you can use this per-cluster configuration to configure the free memory which
can be used by CloudStack.
If you have other thought on this, please share with us.
Anthony
> CitrixResourceBase wrongly calculates total memory on hosts with a lot of
> memory and large Dom0
> ---
>
> Key: CLOUDSTACK-7857
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7857
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: Future, 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1, 4.6.0
>Reporter: Joris van Lieshout
>Priority: Blocker
>
> We have hosts with 256GB memory and 4GB dom0. During startup ACS calculates
> available memory using this formula:
> CitrixResourceBase.java
> protected void fillHostInfo
> ram = (long) ((ram - dom0Ram - _xs_memory_used) *
> _xs_virtualization_factor);
> In our situation:
> ram = 274841497600
> dom0Ram = 4269801472
> _xs_memory_used = 128 * 1024 * 1024L = 134217728
> _xs_virtualization_factor = 63.0/64.0 = 0,984375
> (274841497600 - 4269801472 - 134217728) * 0,984375 = 266211892800
> This is in fact not the actual amount of memory available for instances. The
> difference in our situation is a little less then 1GB. On this particular
> hypervisor Dom0+Xen uses about 9GB.
> As the comment above the definition of XsMemoryUsed allready stated it's time
> to review this logic.
> "//Hypervisor specific params with generic value, may need to be overridden
> for specific versions"
> The effect of this bug is that when you put a hypervisor in maintenance it
> might try to move instances (usually small instances (<1GB)) to a host that
> in fact does not have enought free memory.
> This exception is thrown:
> ERROR [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-3:ctx-09aca6e9
> work-8981) Terminating HAWork[8981-Migration-4482-Running-Migrating]
> com.cloud.utils.exception.CloudRuntimeException: Unable to migrate due to
> Catch Exception com.cloud.utils.exception.CloudRuntimeException: Migration
> failed due to com.cloud.utils.exception.CloudRuntim
> eException: Unable to migrate VM(r-4482-VM) from
> host(6805d06c-4d5b-4438-a245-7915e93041d9) due to Task failed! Task record:
> uuid: 645b63c8-1426-b412-7b6a-13d61ee7ab2e
>nameLabel: Async.VM.pool_migrate
> nameDescription:
>allowedOperations: []
>currentOperations: {}
> created: Thu Nov 06 13:44:14 CET 2014
> finished: Thu Nov 06 13:44:14 CET 2014
> status: failure
> residentOn: com.xensource.xenapi.Host@b42882c6
> progress: 1.0
> type:
> result:
>errorInfo: [HOST_NOT_ENOUGH_FREE_MEMORY, 272629760, 263131136]
> otherConfig: {}
>subtaskOf: com.xensource.xenapi.Task@aaf13f6f
> subtasks: []
> at
> com.cloud.vm.VirtualMachineManagerImpl.migrate(VirtualMachineManagerImpl.java:1840)
> at
> com.cloud.vm.VirtualMachineManagerImpl.migrateAway(VirtualMachineManagerImpl.java:2214)
> at
> com.cloud.ha.HighAvailabilityManagerImpl.migrate(HighAvailabilityManagerImpl.java:610)
> at
> com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.runWithContext(HighAvailabilityManagerImpl.java:865)
> at
> com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.access$000(HighAvailabilityManagerImpl.java:822)
> at
> com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread$1.run(HighAvailabilityManagerImpl.java:834)
> 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.ha.HighAvailabilityManagerIm
[jira] [Resolved] (CLOUDSTACK-6473) Debian 7 Virtual Router ip_conntrack_max not set at boot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang resolved CLOUDSTACK-6473. Resolution: Duplicate > Debian 7 Virtual Router ip_conntrack_max not set at boot > > > Key: CLOUDSTACK-6473 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6473 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.3.0 > Environment: XenServer 6.2 > CloudStack 4.3.0 > Debian 7 SystemVM/Virtual Router >Reporter: Logan B >Assignee: Sheng Yang > Fix For: 4.5.0 > > > The Problem: > The Debian 7 Virtual Router VMs for XenServer experiences intermittent > connectivity problems. This affects all VMs behind the virtual router in > various ways: SSH failures, Apache connections fail, etc. > This issue also affects various function within CloudStack that attempt to > connect to the Virtual Router (updating firewall rules, NAT, etc.) > The Cause: > It appears that the issues is being caused by a low default limit for the > net.ipv4.netfilter.ip_conntrack_max sysctl. The issue can be easily > diagnosed in /var/log/messages: > Apr 22 15:45:34 r-5602-VM kernel: [ 1085.117498] nf_conntrack: table full, > dropping packet. > Apr 22 15:45:34 r-5602-VM kernel: [ 1085.133095] nf_conntrack: table full, > dropping packet. > Apr 22 15:45:34 r-5602-VM kernel: [ 1085.145440] nf_conntrack: table full, > dropping packet. > The default setting for ip_conntrack_max is '3796': > # sysctl net.ipv4.netfilter.ip_conntrack_max > net.ipv4.netfilter.ip_conntrack_max = 3796 > As per /etc/sysctl.conf this setting should be '100': > net.ipv4.netfilter.ip_conntrack_max=100 > It would appear that this setting is not being correctly applied when the > virtual router boots. > The Solution: > - A temporary workaround is to manually set the ip_conntrack_max sysctl to > the correct value: > # sysctl -w net.ipv4.netfilter.ip_conntrack_max=100 > It's likely that this sysctl is being run at boot before the module is > loaded, so it doesn't take effect. There are various solutions suggested > around the web, any of which should work fine. > To resolve this problem a new System VM template should be created. I'm > assuming this can be done in between CloudStack releases. I know there is > supposed to be a new template released to fix the HeartBleed vulnerability, > so this would be a good fix to include with that updated template. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7919) In vmware, when host crashed and the VR migrated because of HA, Vmsync didnt notice a change in the state and so didnt reprogram the VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta updated CLOUDSTACK-7919: Summary: In vmware, when host crashed and the VR migrated because of HA, Vmsync didnt notice a change in the state and so didnt reprogram the VR (was: In vmware, when host crashed and the VR migrated because of HA Vmsync couldnt notice a change in the state (logs pasted above by me) and so didnt reprogram the VR) > In vmware, when host crashed and the VR migrated because of HA, Vmsync didnt > notice a change in the state and so didnt reprogram the VR > --- > > Key: CLOUDSTACK-7919 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7919 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Critical > Fix For: 4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7919) In vmware, when host crashed and the VR migrated because of HA, Vmsync didnt notice a change in the state and so didnt reprogram the VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212978#comment-14212978 ] ASF subversion and git services commented on CLOUDSTACK-7919: - Commit 39a671dfd889148d69d2f75285d194a4705c35cc in cloudstack's branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=39a671d ] CLOUDSTACK-7919: If there is an out of band movement for the VR, irrespective of the fact that came as out of band live migrate or HA, reboot the router to make sure the router has all the rules configured. > In vmware, when host crashed and the VR migrated because of HA, Vmsync didnt > notice a change in the state and so didnt reprogram the VR > --- > > Key: CLOUDSTACK-7919 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7919 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Nitin Mehta >Assignee: Nitin Mehta >Priority: Critical > Fix For: 4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7919) In vmware, when host crashed and the VR migrated because of HA Vmsync couldnt notice a change in the state (logs pasted above by me) and so didnt reprogram the VR
Nitin Mehta created CLOUDSTACK-7919: --- Summary: In vmware, when host crashed and the VR migrated because of HA Vmsync couldnt notice a change in the state (logs pasted above by me) and so didnt reprogram the VR Key: CLOUDSTACK-7919 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7919 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.6.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Priority: Critical Fix For: 4.6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7918) Can't deploy VM from SUSE Linux Enterprise Server 12 (64-bit) ISO in XS 6.5
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212968#comment-14212968 ] ASF subversion and git services commented on CLOUDSTACK-7918: - Commit 425a6b01d60b88016c23a1126960375b00d97069 in cloudstack's branch refs/heads/4.5 from [~anthonyxu] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=425a6b0 ] CLOUDSTACK-7918: guest os name changes from 'SUSE Linux Enterprise Server 12 (experimental)' to 'SUSE Linux Enterprise Server 12 (64-bit)' in latest XS 5.6 , changed the guest OS mapping to fix it. > Can't deploy VM from SUSE Linux Enterprise Server 12 (64-bit) ISO in XS 6.5 > --- > > Key: CLOUDSTACK-7918 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7918 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.0 >Reporter: Anthony Xu >Assignee: Anthony Xu >Priority: Critical > Fix For: 4.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7918) Can't deploy VM from SUSE Linux Enterprise Server 12 (64-bit) ISO in XS 6.5
Anthony Xu created CLOUDSTACK-7918: -- Summary: Can't deploy VM from SUSE Linux Enterprise Server 12 (64-bit) ISO in XS 6.5 Key: CLOUDSTACK-7918 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7918 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Anthony Xu Assignee: Anthony Xu Priority: Critical Fix For: 4.5.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6697) update BigSwitch network plugin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212930#comment-14212930 ] Kuang-Ching Wang commented on CLOUDSTACK-6697: -- [~animeshc], indeed, this is targeted for 4.6. Thanks for pointing this out - I updated the version. I am working on the code and [~htrippaers] is reviewing the code. > update BigSwitch network plugin > --- > > Key: CLOUDSTACK-6697 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6697 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.6.0 >Reporter: Kuang-Ching Wang > Fix For: 4.6.0 > > > In CLOUDSTACK-733 a network plugin was created for the BVS application of the > Big Switch SDN controller. Since then, the application has evolved and have > various changes in its implementation. This issue is created to update the > plugin so as to be compatible with the latest controller. > This issue is not expected to affect any Cloudstack workflow. The fix will > make sure correct operation of all the previously supported functions. > See CLOUDSTACK-733 for reference. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7773) CLONE - UI - listServiceOfferings API needs to be able to take virtualmachineid of SystemVM and return service offerings available for the vm to change service offe
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-7773. -- Resolution: Fixed > CLONE - UI - listServiceOfferings API needs to be able to take > virtualmachineid of SystemVM and return service offerings available for the > vm to change service offering > > > Key: CLOUDSTACK-7773 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7773 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 > Environment: listServiceOfferings API needs to be able to take > virtualmachineid of SystemVM and returns service offerings available for the > vm to change service offering. If vm is running only scale up service > offering should be presented. If vm is stopped all service offering should be > shown. >Reporter: Nitin Mehta >Assignee: Jessica Wang > Fix For: 4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7773) CLONE - UI - listServiceOfferings API needs to be able to take virtualmachineid of SystemVM and return service offerings available for the vm to change service offeri
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang closed CLOUDSTACK-7773. > CLONE - UI - listServiceOfferings API needs to be able to take > virtualmachineid of SystemVM and return service offerings available for the > vm to change service offering > > > Key: CLOUDSTACK-7773 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7773 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 > Environment: listServiceOfferings API needs to be able to take > virtualmachineid of SystemVM and returns service offerings available for the > vm to change service offering. If vm is running only scale up service > offering should be presented. If vm is stopped all service offering should be > shown. >Reporter: Nitin Mehta >Assignee: Jessica Wang > Fix For: 4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6697) update BigSwitch network plugin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kuang-Ching Wang updated CLOUDSTACK-6697: - Fix Version/s: (was: 4.5.0) 4.6.0 > update BigSwitch network plugin > --- > > Key: CLOUDSTACK-6697 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6697 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.6.0 >Reporter: Kuang-Ching Wang > Fix For: 4.6.0 > > > In CLOUDSTACK-733 a network plugin was created for the BVS application of the > Big Switch SDN controller. Since then, the application has evolved and have > various changes in its implementation. This issue is created to update the > plugin so as to be compatible with the latest controller. > This issue is not expected to affect any Cloudstack workflow. The fix will > make sure correct operation of all the previously supported functions. > See CLOUDSTACK-733 for reference. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6697) update BigSwitch network plugin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kuang-Ching Wang updated CLOUDSTACK-6697: - Affects Version/s: (was: 4.5.0) 4.6.0 > update BigSwitch network plugin > --- > > Key: CLOUDSTACK-6697 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6697 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.6.0 >Reporter: Kuang-Ching Wang > Fix For: 4.6.0 > > > In CLOUDSTACK-733 a network plugin was created for the BVS application of the > Big Switch SDN controller. Since then, the application has evolved and have > various changes in its implementation. This issue is created to update the > plugin so as to be compatible with the latest controller. > This issue is not expected to affect any Cloudstack workflow. The fix will > make sure correct operation of all the previously supported functions. > See CLOUDSTACK-733 for reference. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7773) CLONE - UI - listServiceOfferings API needs to be able to take virtualmachineid of SystemVM and return service offerings available for the vm to change service off
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212915#comment-14212915 ] ASF subversion and git services commented on CLOUDSTACK-7773: - Commit 2d4e87973d7d20009efe2199aaf69c7d35279d03 in cloudstack's branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2d4e879 ] CLOUDSTACK-7773: UI > Infrastructure > SystemVMs, Routers > Change Service Offering > service offerings dropdown > populate only service offerings that the VM is allowed to change to. i.e. exclude service offerings that the VM is not allowed to change to. > CLONE - UI - listServiceOfferings API needs to be able to take > virtualmachineid of SystemVM and return service offerings available for the > vm to change service offering > > > Key: CLOUDSTACK-7773 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7773 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 > Environment: listServiceOfferings API needs to be able to take > virtualmachineid of SystemVM and returns service offerings available for the > vm to change service offering. If vm is running only scale up service > offering should be presented. If vm is stopped all service offering should be > shown. >Reporter: Nitin Mehta >Assignee: Jessica Wang > Fix For: 4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7907) UI heavily broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212908#comment-14212908 ] ilya musayev commented on CLOUDSTACK-7907: -- This happens to me as well, i will see if i can track the issue through firebug. > UI heavily broken > - > > Key: CLOUDSTACK-7907 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7907 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0, 4.4.1 > Environment: not relevant >Reporter: Andrija Panic >Priority: Critical > Labels: ui > > (A serious one, that we encounter pretty often): > Issue: I start new VM deloyment wizard, choose template etc at the end > when I click the finish, when the job should be sent to MGMT server - simply > nothing happens - so ajax does't get executed at all, no litle circle > spinning etc - no logs in mgmt server, simply ajax doesn't get > executed...Same behaviour sometimes happen when I click on "Configure" on the > VPC. > I confirmed behaviour in acs 4.3.0 and I'm still checking in 4.4.1, but I > doubt anything has changed > OR > 2) > (not a big issue, however very annoying): > I filter instances by some account/domain, then click on some instance (view > it's properties or whatever), than in the breadcrumb I click back on > "instances", and instead of being show the page with all the filtered > instances, I get back to the home page of ACS... > So it doesn't really happens always, but randomly, with different browsers, > clearing all cache etc... > The issue here is that nothing get's logged to MGMT log at all... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7916) Generate Alerts if System VMs cannot be started
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta resolved CLOUDSTACK-7916. - Resolution: Fixed > Generate Alerts if System VMs cannot be started > --- > > Key: CLOUDSTACK-7916 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7916 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Nitin Mehta >Priority: Critical > Fix For: 4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7916) Generate Alerts if System VMs cannot be started
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212866#comment-14212866 ] ASF subversion and git services commented on CLOUDSTACK-7916: - Commit e87bb20d0c73e6f46f1352e271afec3961067542 in cloudstack's branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e87bb20 ] CLOUDSTACK-7916: Generate Alerts if System VMs cannot be started. > Generate Alerts if System VMs cannot be started > --- > > Key: CLOUDSTACK-7916 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7916 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Nitin Mehta >Priority: Critical > Fix For: 4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7916) Generate Alerts if System VMs cannot be started
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212839#comment-14212839 ] ASF subversion and git services commented on CLOUDSTACK-7916: - Commit 3907bc6f9d2b4a61a4d0b32e5c1a15d95210531e in cloudstack's branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3907bc6 ] CLOUDSTACK-7916: Generate Alerts if System VMs cannot be started. > Generate Alerts if System VMs cannot be started > --- > > Key: CLOUDSTACK-7916 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7916 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Nitin Mehta >Priority: Critical > Fix For: 4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (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:all-tabpanel ] Nitin Mehta updated CLOUDSTACK-6698: Fix Version/s: (was: 4.5.0) 4.6.0 > 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.6.0 > > -- 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-tabpanel&focusedCommentId=14212818#comment-14212818 ] Nitin Mehta commented on CLOUDSTACK-6698: - Punting for 4.6 since this seem to be critical > 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.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7645) Many instances of "???label.*???"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212739#comment-14212739 ] ASF subversion and git services commented on CLOUDSTACK-7645: - Commit a49e24095850980ed008d9be8b4c5430977297dc in cloudstack's branch refs/heads/master from [~mihaelas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a49e240 ] CLOUDSTACK-7645: Use the localization function _l() instead of dictionary directly > Many instances of "???label.*???" > - > > Key: CLOUDSTACK-7645 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7645 > 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: Stephen Turner >Assignee: Mihaela Stoica >Priority: Critical > Fix For: 4.5.0, 4.6.0 > > Attachments: label.app.name.png > > > We have many instances of "\?\?\?label.*\?\?\?" in the UI, including strings > I know were correct recently. (For example, I saw it on the certificate > upload UI, which was recently rewritten). > I think something is wrong with the mechanism rather than individual > translations, so rather than creating a bug for each one, I have bundled them > together in this ticket. Individual tickets are linked from here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7916) Generate Alerts if System VMs cannot be started
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212737#comment-14212737 ] Nitin Mehta commented on CLOUDSTACK-7916: - If CPVM or SSVM cannot be started due to certain reasons (for instance low resource availability) then this requires the user to review the log files. Desired Output: Generate an alert of High Severity in case CPVM or SSVM cannot be started and provide a readable message giving the reason for the same > Generate Alerts if System VMs cannot be started > --- > > Key: CLOUDSTACK-7916 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7916 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Nitin Mehta >Priority: Critical > Fix For: 4.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CLOUDSTACK-7821) Non-NAT OSX client cannot connect to VPN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sheng Yang reopened CLOUDSTACK-7821:
> Non-NAT OSX client cannot connect to VPN
>
>
> Key: CLOUDSTACK-7821
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7821
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Sheng Yang
>Assignee: Sheng Yang
>Priority: Critical
>
> OpenSwan would have this error message in auth.log:
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: responding
> to Main Mode from unknown peer 10.215.3.6
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: transition
> from state STATE_MAIN_R0 to state STATE_MAIN_R1
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> STATE_MAIN_R1: sent MR1, expecting MI2
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): no NAT
> detected
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: transition
> from state STATE_MAIN_R1 to state STATE_MAIN_R2
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> STATE_MAIN_R2: sent MR2, expecting MI3
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: ignoring
> informational payload, type IPSEC_INITIAL_CONTACT msgid=
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: Main mode
> peer ID is ID_IPV4_ADDR: '10.215.3.6'
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: transition
> from state STATE_MAIN_R2 to state STATE_MAIN_R3
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: new NAT
> mapping for #1, was 10.215.3.6:500, now 10.215.3.6:4500
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> STATE_MAIN_R3: sent MR3, ISAKMP SA established
> {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha group=modp1024}
> Oct 31 00:13:12 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/0
> Oct 31 00:13:12 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #2:
> ENCAPSULATION_MODE_UDP_TRANSPORT_RFC must only be used if NAT-Traversal is
> detected
> Oct 31 00:13:12 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #2: sending
> encrypted notification BAD_PROPOSAL_SYNTAX to 10.215.3.6:4500
> Oct 31 00:13:15 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/54694
> Oct 31 00:13:15 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #3:
> ENCAPSULATION_MODE_UDP_TRANSPORT_RFC must only be used if NAT-Traversal is
> detected
> Oct 31 00:13:15 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #3: sending
> encrypted notification BAD_PROPOSAL_SYNTAX to 10.215.3.6:4500
> Oct 31 00:13:18 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/54694
> Oct 31 00:13:18 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #4:
> ENCAPSULATION_MODE_UDP_TRANSPORT_RFC must only be used if NAT-Traversal is
> detected
> Oct 31 00:13:18 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #4: sending
> encrypted notification BAD_PROPOSAL_SYNTAX to 10.215.3.6:4500
> Oct 31 00:13:21 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/54694
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7821) Non-NAT OSX client cannot connect to VPN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sheng Yang updated CLOUDSTACK-7821:
---
Fix Version/s: (was: 4.5.0)
> Non-NAT OSX client cannot connect to VPN
>
>
> Key: CLOUDSTACK-7821
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7821
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Sheng Yang
>Assignee: Sheng Yang
>Priority: Critical
>
> OpenSwan would have this error message in auth.log:
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: responding
> to Main Mode from unknown peer 10.215.3.6
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: transition
> from state STATE_MAIN_R0 to state STATE_MAIN_R1
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> STATE_MAIN_R1: sent MR1, expecting MI2
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): no NAT
> detected
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: transition
> from state STATE_MAIN_R1 to state STATE_MAIN_R2
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> STATE_MAIN_R2: sent MR2, expecting MI3
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: ignoring
> informational payload, type IPSEC_INITIAL_CONTACT msgid=
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: Main mode
> peer ID is ID_IPV4_ADDR: '10.215.3.6'
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: transition
> from state STATE_MAIN_R2 to state STATE_MAIN_R3
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: new NAT
> mapping for #1, was 10.215.3.6:500, now 10.215.3.6:4500
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> STATE_MAIN_R3: sent MR3, ISAKMP SA established
> {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha group=modp1024}
> Oct 31 00:13:12 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/0
> Oct 31 00:13:12 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #2:
> ENCAPSULATION_MODE_UDP_TRANSPORT_RFC must only be used if NAT-Traversal is
> detected
> Oct 31 00:13:12 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #2: sending
> encrypted notification BAD_PROPOSAL_SYNTAX to 10.215.3.6:4500
> Oct 31 00:13:15 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/54694
> Oct 31 00:13:15 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #3:
> ENCAPSULATION_MODE_UDP_TRANSPORT_RFC must only be used if NAT-Traversal is
> detected
> Oct 31 00:13:15 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #3: sending
> encrypted notification BAD_PROPOSAL_SYNTAX to 10.215.3.6:4500
> Oct 31 00:13:18 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/54694
> Oct 31 00:13:18 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #4:
> ENCAPSULATION_MODE_UDP_TRANSPORT_RFC must only be used if NAT-Traversal is
> detected
> Oct 31 00:13:18 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #4: sending
> encrypted notification BAD_PROPOSAL_SYNTAX to 10.215.3.6:4500
> Oct 31 00:13:21 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/54694
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7821) Non-NAT OSX client cannot connect to VPN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212727#comment-14212727
]
ASF subversion and git services commented on CLOUDSTACK-7821:
-
Commit fd03091c811992764d5ab27f7a9e3e9be4889616 in cloudstack's branch
refs/heads/master from [~yasker]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fd03091 ]
Revert "CLOUDSTACK-7821: Fix OSX cannot connect to VPN due to wrongly declaim
ENCAPSULATION_MODE_UDP_TRANSPORT_RFC"
This reverts commit e1c788ca3c69a8c8c2041c7b106f76fa49332888.
This breaks Windows 7 client.
> Non-NAT OSX client cannot connect to VPN
>
>
> Key: CLOUDSTACK-7821
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7821
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Sheng Yang
>Assignee: Sheng Yang
>Priority: Critical
> Fix For: 4.5.0
>
>
> OpenSwan would have this error message in auth.log:
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: responding
> to Main Mode from unknown peer 10.215.3.6
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: transition
> from state STATE_MAIN_R0 to state STATE_MAIN_R1
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> STATE_MAIN_R1: sent MR1, expecting MI2
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): no NAT
> detected
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: transition
> from state STATE_MAIN_R1 to state STATE_MAIN_R2
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> STATE_MAIN_R2: sent MR2, expecting MI3
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: ignoring
> informational payload, type IPSEC_INITIAL_CONTACT msgid=
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: Main mode
> peer ID is ID_IPV4_ADDR: '10.215.3.6'
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: transition
> from state STATE_MAIN_R2 to state STATE_MAIN_R3
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: new NAT
> mapping for #1, was 10.215.3.6:500, now 10.215.3.6:4500
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> STATE_MAIN_R3: sent MR3, ISAKMP SA established
> {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha group=modp1024}
> Oct 31 00:13:12 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/0
> Oct 31 00:13:12 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #2:
> ENCAPSULATION_MODE_UDP_TRANSPORT_RFC must only be used if NAT-Traversal is
> detected
> Oct 31 00:13:12 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #2: sending
> encrypted notification BAD_PROPOSAL_SYNTAX to 10.215.3.6:4500
> Oct 31 00:13:15 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/54694
> Oct 31 00:13:15 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #3:
> ENCAPSULATION_MODE_UDP_TRANSPORT_RFC must only be used if NAT-Traversal is
> detected
> Oct 31 00:13:15 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #3: sending
> encrypted notification BAD_PROPOSAL_SYNTAX to 10.215.3.6:4500
> Oct 31 00:13:18 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/54694
> Oct 31 00:13:18 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #4:
> ENCAPSULATION_MODE_UDP_TRANSPORT_RFC must only be used if NAT-Traversal is
> detected
> Oct 31 00:13:18 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #4: sending
> encrypted notification BAD_PROPOSAL_SYNTAX to 10.215.3.6:4500
> Oct 31 00:13:21 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/54694
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7821) Non-NAT OSX client cannot connect to VPN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212726#comment-14212726
]
ASF subversion and git services commented on CLOUDSTACK-7821:
-
Commit 2d3b3376e37faeec3ed62a58750819dc7630260c in cloudstack's branch
refs/heads/4.5 from [~yasker]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2d3b337 ]
Revert "CLOUDSTACK-7821: Fix OSX cannot connect to VPN due to wrongly declaim
ENCAPSULATION_MODE_UDP_TRANSPORT_RFC"
This reverts commit e1c788ca3c69a8c8c2041c7b106f76fa49332888.
It breaks Windows 7 client.
> Non-NAT OSX client cannot connect to VPN
>
>
> Key: CLOUDSTACK-7821
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7821
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Sheng Yang
>Assignee: Sheng Yang
>Priority: Critical
> Fix For: 4.5.0
>
>
> OpenSwan would have this error message in auth.log:
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: responding
> to Main Mode from unknown peer 10.215.3.6
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: transition
> from state STATE_MAIN_R0 to state STATE_MAIN_R1
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> STATE_MAIN_R1: sent MR1, expecting MI2
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): no NAT
> detected
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: transition
> from state STATE_MAIN_R1 to state STATE_MAIN_R2
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> STATE_MAIN_R2: sent MR2, expecting MI3
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: ignoring
> informational payload, type IPSEC_INITIAL_CONTACT msgid=
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: Main mode
> peer ID is ID_IPV4_ADDR: '10.215.3.6'
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: transition
> from state STATE_MAIN_R2 to state STATE_MAIN_R3
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: new NAT
> mapping for #1, was 10.215.3.6:500, now 10.215.3.6:4500
> Oct 31 00:13:11 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1:
> STATE_MAIN_R3: sent MR3, ISAKMP SA established
> {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha group=modp1024}
> Oct 31 00:13:12 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/0
> Oct 31 00:13:12 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #2:
> ENCAPSULATION_MODE_UDP_TRANSPORT_RFC must only be used if NAT-Traversal is
> detected
> Oct 31 00:13:12 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #2: sending
> encrypted notification BAD_PROPOSAL_SYNTAX to 10.215.3.6:4500
> Oct 31 00:13:15 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/54694
> Oct 31 00:13:15 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #3:
> ENCAPSULATION_MODE_UDP_TRANSPORT_RFC must only be used if NAT-Traversal is
> detected
> Oct 31 00:13:15 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #3: sending
> encrypted notification BAD_PROPOSAL_SYNTAX to 10.215.3.6:4500
> Oct 31 00:13:18 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/54694
> Oct 31 00:13:18 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #4:
> ENCAPSULATION_MODE_UDP_TRANSPORT_RFC must only be used if NAT-Traversal is
> detected
> Oct 31 00:13:18 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #4: sending
> encrypted notification BAD_PROPOSAL_SYNTAX to 10.215.3.6:4500
> Oct 31 00:13:21 r-13-VM pluto[4717]: "L2TP-PSK"[1] 10.215.3.6 #1: the peer
> proposed: 10.223.161.22/32:17/1701 -> 10.215.3.6/32:17/54694
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7917) Load Balancer Rule is not validated when updating LB
Daniel Vega Simoes created CLOUDSTACK-7917: -- Summary: Load Balancer Rule is not validated when updating LB Key: CLOUDSTACK-7917 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7917 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: Daniel Vega Simoes When updating a load balancer rule, the rule is updated without being previously validated with the LB provider. This can lead to invalid load balancing rules on the provider equipment. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7916) Generate Alerts if System VMs cannot be started
Nitin Mehta created CLOUDSTACK-7916: --- Summary: Generate Alerts if System VMs cannot be started Key: CLOUDSTACK-7916 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7916 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.6.0 Reporter: Nitin Mehta Priority: Critical Fix For: 4.6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7915) Remove hard-coded values for Load Balancer algorithms in UI
Daniel Vega Simoes created CLOUDSTACK-7915: -- Summary: Remove hard-coded values for Load Balancer algorithms in UI Key: CLOUDSTACK-7915 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7915 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: Daniel Vega Simoes Algorithm listing for Load Balancer Rules is hard-coded (round robin, least conn, source). They should be loaded dynamically from the load balancer capabilities. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7907) UI heavily broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212528#comment-14212528 ] Andrija Panic commented on CLOUDSTACK-7907: --- Hi Stephen, thanks for geting back to me. What seems to me is that sometimes when there are network latencies (wireless) the first bug occurs...I will try to see when we encounter these issues again, and will try to capture then as you suggested. Regarding the second bug (breadcrumb) - even if you don't filter instances (so just click on Instances in the main menu on the left) and get to properties of some VM, then click back on the Instances in the breadcrumb - you get homepage... - I did not manage to understand when/why this occurs so far...but will also try to catch that with firebug... Thanks > UI heavily broken > - > > Key: CLOUDSTACK-7907 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7907 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0, 4.4.1 > Environment: not relevant >Reporter: Andrija Panic >Priority: Critical > Labels: ui > > (A serious one, that we encounter pretty often): > Issue: I start new VM deloyment wizard, choose template etc at the end > when I click the finish, when the job should be sent to MGMT server - simply > nothing happens - so ajax does't get executed at all, no litle circle > spinning etc - no logs in mgmt server, simply ajax doesn't get > executed...Same behaviour sometimes happen when I click on "Configure" on the > VPC. > I confirmed behaviour in acs 4.3.0 and I'm still checking in 4.4.1, but I > doubt anything has changed > OR > 2) > (not a big issue, however very annoying): > I filter instances by some account/domain, then click on some instance (view > it's properties or whatever), than in the breadcrumb I click back on > "instances", and instead of being show the page with all the filtered > instances, I get back to the home page of ACS... > So it doesn't really happens always, but randomly, with different browsers, > clearing all cache etc... > The issue here is that nothing get's logged to MGMT log at all... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7907) UI heavily broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212518#comment-14212518 ] Stephen Turner commented on CLOUDSTACK-7907: Thank you for the report, Andrija. I know someone else on the cloudstack-dev mailing list also said they'd seen this, but I talked to all the Citrix UI developers and none of them had ever seen it or heard of it. Do you have any more details? Are there particular environments, or sequences of actions, that make it more likely to happen? (E.g., slow/fast network, click through slow/fast? ...). We suspect there must be a Javascript error, so if you can make it happen, could you open up Firebug (in Firefox) or Chrome Developer Tools (in Chrome) and send a screenshot showing the error? Thank you. > UI heavily broken > - > > Key: CLOUDSTACK-7907 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7907 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0, 4.4.1 > Environment: not relevant >Reporter: Andrija Panic >Priority: Critical > Labels: ui > > (A serious one, that we encounter pretty often): > Issue: I start new VM deloyment wizard, choose template etc at the end > when I click the finish, when the job should be sent to MGMT server - simply > nothing happens - so ajax does't get executed at all, no litle circle > spinning etc - no logs in mgmt server, simply ajax doesn't get > executed...Same behaviour sometimes happen when I click on "Configure" on the > VPC. > I confirmed behaviour in acs 4.3.0 and I'm still checking in 4.4.1, but I > doubt anything has changed > OR > 2) > (not a big issue, however very annoying): > I filter instances by some account/domain, then click on some instance (view > it's properties or whatever), than in the breadcrumb I click back on > "instances", and instead of being show the page with all the filtered > instances, I get back to the home page of ACS... > So it doesn't really happens always, but randomly, with different browsers, > clearing all cache etc... > The issue here is that nothing get's logged to MGMT log at all... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6243) [Doc] Document XS-CS Integration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212396#comment-14212396 ] Rohit Yadav commented on CLOUDSTACK-6243: - Should we document this soon? 4.4.0 was out and this critical information was not published. This changes how we do XenServer upgrades with the change. > [Doc] Document XS-CS Integration > > > Key: CLOUDSTACK-6243 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6243 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Radhika Nair > Fix For: 4.4.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-3528) [UI]list calls are in the processing state forever with invalid name provided with Account name search filter
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabor Apati-Nagy resolved CLOUDSTACK-3528. -- Resolution: Fixed > [UI]list calls are in the processing state forever with invalid name provided > with Account name search filter > -- > > Key: CLOUDSTACK-3528 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3528 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 >Reporter: Sailaja Mada >Assignee: Gabor Apati-Nagy > Fix For: 4.6.0 > > Attachments: UIlistevents.png, UIlistinstances.png, UIlistvolumes.png > > > Steps: > 1. Access Instances page > 2. Click on Search Filter options > 3. Provide wrong account name and tried to search instances owned by this > account > 4. It failed with message saying no instances were found. But UI remains in > the processing state forever > This behavior is observed with other list calls , EX: List Events, List > Volumes ( All with invalid account name in the search filter) > Note: Attached snapshots. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7874) "CPU (in MHz)" does not make sense
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212348#comment-14212348 ] Stephen Turner commented on CLOUDSTACK-7874: We can change it, but I'd like to understand what it actually does in each hypervisor first, to make sure we get it right this time. What API calls does it actual call in XenServer? > "CPU (in MHz)" does not make sense > -- > > Key: CLOUDSTACK-7874 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7874 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, UI >Affects Versions: 4.4.1 > Environment: CentOS 6 x86_64 mgmt + HVs >Reporter: Nux > Labels: UI, cpu, cpuspeed > > Hello, > This "CPU (in MHz)" description when adding a new Service Offering does not > make much sense and is misleading. > As far as I know this is the "cpu weight" Xen feature to determine CPU > access/time priority; it should be presented as such or it should be > determined automatically based on Core count. > In my particular setup I have edited classes/resources/messages.properties > and modified it as follows: > label.cpu.mhz=CPU priority (same number as cores) > Is this something that could be changed? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7720) No IP Address Validation for Acquire new secondary IP
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabor Apati-Nagy closed CLOUDSTACK-7720. > No IP Address Validation for Acquire new secondary IP > - > > Key: CLOUDSTACK-7720 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7720 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Gabor Apati-Nagy >Assignee: Gabor Apati-Nagy >Priority: Minor > Fix For: 4.5.0 > > > Steps: > 1. Go to Instances --> NICs tab. > 2. Click on the View Secondary IPs > 3. Click on Acquire new secondary IP > There is No IP address validation for "Acquire new secondary IP". > Additionally, this field should be a required field. Clicking "Ok" generates > an IP, but it can be confusing to the end user. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7720) No IP Address Validation for Acquire new secondary IP
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabor Apati-Nagy resolved CLOUDSTACK-7720. -- Resolution: Fixed > No IP Address Validation for Acquire new secondary IP > - > > Key: CLOUDSTACK-7720 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7720 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Gabor Apati-Nagy >Assignee: Gabor Apati-Nagy >Priority: Minor > Fix For: 4.5.0 > > > Steps: > 1. Go to Instances --> NICs tab. > 2. Click on the View Secondary IPs > 3. Click on Acquire new secondary IP > There is No IP address validation for "Acquire new secondary IP". > Additionally, this field should be a required field. Clicking "Ok" generates > an IP, but it can be confusing to the end user. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7783) Blank page after login
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212347#comment-14212347 ] Stephen Turner commented on CLOUDSTACK-7783: 4.0.0 is a rather old version now. Do you see this on later versions? > Blank page after login > -- > > Key: CLOUDSTACK-7783 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7783 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.0.0 > Environment: Linux Firefox 32.0.3 and Linux Chrome 38.0.2125.101 >Reporter: Sergio Soto Núñez >Priority: Critical > Labels: language, web > > Access to http://:8080/client, set user and passwod. > Blank page appears after logging if you don't select a language. > Only a message is shown in js console: > ReferenceError: dictionary is not defined -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7645) Many instances of "???label.*???"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mihaela Stoica resolved CLOUDSTACK-7645. Resolution: Fixed Fix Version/s: 4.6.0 > Many instances of "???label.*???" > - > > Key: CLOUDSTACK-7645 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7645 > 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: Stephen Turner >Assignee: Mihaela Stoica >Priority: Critical > Fix For: 4.5.0, 4.6.0 > > Attachments: label.app.name.png > > > We have many instances of "\?\?\?label.*\?\?\?" in the UI, including strings > I know were correct recently. (For example, I saw it on the certificate > upload UI, which was recently rewritten). > I think something is wrong with the mechanism rather than individual > translations, so rather than creating a bug for each one, I have bundled them > together in this ticket. Individual tickets are linked from here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CLOUDSTACK-5578) KVM - Network down - When the host looses network connectivity , it is not able to fence itself.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeetha Hariharan reopened CLOUDSTACK-5578: - Hi Kishan, This is a problem that KVM host is not able to reboot itself which is the expected behavior. The host is attempting to reboot which fails . Is it possible to make the host forcefully reboot in such cases? Thanks Sangeetha > KVM - Network down - When the host looses network connectivity , it is not > able to fence itself. > > > Key: CLOUDSTACK-5578 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5578 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.5.0 > > Attachments: DisconnectedHost.png, kvm-hostdisconnect.rar > > > KVM - Network down - When the host looses network connectivity , it is not > able to fence itself. > Steps to reproduce the problem: > Set up - Advanced zone with 2 Rhel 6.3 hosts in cluster. > Deploy ~10 Vms. > Simulate network disconnect on the host ( ifdown em1) > Host gets marked as "Down" and all the Vms gets HA-ed to the other host. > On the KVM host which lost connectivity , attempt to shutdown itself fails. > It was not able to umount the primary store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-5578) KVM - Network down - When the host looses network connectivity , it is not able to fence itself.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala resolved CLOUDSTACK-5578. --- Resolution: Not a Problem > KVM - Network down - When the host looses network connectivity , it is not > able to fence itself. > > > Key: CLOUDSTACK-5578 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5578 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.5.0 > > Attachments: DisconnectedHost.png, kvm-hostdisconnect.rar > > > KVM - Network down - When the host looses network connectivity , it is not > able to fence itself. > Steps to reproduce the problem: > Set up - Advanced zone with 2 Rhel 6.3 hosts in cluster. > Deploy ~10 Vms. > Simulate network disconnect on the host ( ifdown em1) > Host gets marked as "Down" and all the Vms gets HA-ed to the other host. > On the KVM host which lost connectivity , attempt to shutdown itself fails. > It was not able to umount the primary store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5578) KVM - Network down - When the host looses network connectivity , it is not able to fence itself.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212217#comment-14212217 ] Kishan Kavala commented on CLOUDSTACK-5578: --- KVM fence command does heartbeat check on primary storage. When network is not available Fence command will fail. This is expected. > KVM - Network down - When the host looses network connectivity , it is not > able to fence itself. > > > Key: CLOUDSTACK-5578 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5578 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.5.0 > > Attachments: DisconnectedHost.png, kvm-hostdisconnect.rar > > > KVM - Network down - When the host looses network connectivity , it is not > able to fence itself. > Steps to reproduce the problem: > Set up - Advanced zone with 2 Rhel 6.3 hosts in cluster. > Deploy ~10 Vms. > Simulate network disconnect on the host ( ifdown em1) > Host gets marked as "Down" and all the Vms gets HA-ed to the other host. > On the KVM host which lost connectivity , attempt to shutdown itself fails. > It was not able to umount the primary store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5785) VM display name cell not updated upon detaching volume from VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212213#comment-14212213 ] ASF subversion and git services commented on CLOUDSTACK-5785: - Commit d9e94717b5db251b2a888b485fc695dae2ee2e59 in cloudstack's branch refs/heads/4.3 from [~csuich2] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d9e9471 ] CLOUDSTACK-5785: VM display name cell not updated upon detaching volume from VM (cherry picked from commit ea29adb7b96d31a07f6528c79f57847a43175966) Signed-off-by: Rohit Yadav > VM display name cell not updated upon detaching volume from VM > -- > > Key: CLOUDSTACK-5785 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5785 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 > Environment: Mac OS X 10.8.3 > Chrome 31.0.1650.63 >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski > Fix For: 4.4.0 > > Attachments: Detach Volume.png > > > In the Storage tab of the GUI, I detached a volume from a VM. > The process was successful; however, the GUI did not update properly. > After the detach has completed, the VM display name cell in the appropriate > row should be empty, but I noticed it still contained the name of the VM the > volume was attached to. > I have included a screen shot. > One point of note is that the GUI seems to update just fine when attaching a > volume to a VM. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7250) [vCenter 5.5] SourceNAT,StaticNAT and Portfowrding is not working with Vmware DVS in vCenter 5.5
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212211#comment-14212211
]
ASF subversion and git services commented on CLOUDSTACK-7250:
-
Commit 1d7adf52161f3a6ec1d6609ac70f3086c79d8a41 in cloudstack's branch
refs/heads/4.3 from [~sateeshc]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1d7adf5 ]
CLOUDSTACK-7250 [vCenter 5.5] SourceNAT,StaticNAT and Portfowrding is not
working with Vmware DVS in vCenter 5.5
Change in vCenter 5.5 API from prior versions forced code change in CloudStack.
Update property value of property "VirtualE1000.deviceInfo.summary" is
accommodated now.
Signed-off-by: Sateesh Chodapuneedi
(cherry picked from commit dfa607fb443cbd0c3f2c264c2abfa9f1844a16ce)
Signed-off-by: Rohit Yadav
Conflicts:
vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java
> [vCenter 5.5] SourceNAT,StaticNAT and Portfowrding is not working with Vmware
> DVS in vCenter 5.5
>
>
> Key: CLOUDSTACK-7250
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7250
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Affects Versions: 4.2.0, 4.2.1, 4.3.0, 4.4.0, 4.3.1
> Environment: vCenter 5.5
> CloudStack version 4.2 or later until 4.5
>Reporter: Sateesh Chodapuneedi
>Assignee: Sateesh Chodapuneedi
> Fix For: 4.5.0
>
>
> Cloudstack is unable to get the VIF information for the VR's and the IPASSOC
> commands are failing.
> I installed CloudStack 4.3 fresh (no upgrade).
> The installation was finished without a problem.
> SSVM and CPVM was created.
> The first VM was created, but the following problems occurred.
> -I can't ping internet site's IP address (for example google.com)
> -An error occurs when I set StaticNAT or Portfowrding
> The error is "Failed to apply port forwarding rule"
> Also seeing following errors,
> 2014-08-05 08:42:58,086 INFO [vmware.resource.VmwareResource]
> (DirectAgent-366:10.102.192.3) Executing resource IPAssocCommand:
> {"ipAddresses":[
> {"accountId":2,"publicIp":"10.102.196.147","sourceNat":true,"add":true,"oneToOneNat":false,"firstIP":true,"vlanId":"100","vlanGateway":"10.102.196.1","vlanNetmask":"255.255.255.0","vifMacAddress":"06:a5:a8:00:00:13","networkRate":200,"trafficType":"Public","networkName":"dvSwitch0,,vmwaredvs"}
> ],"accessDetails":
> {"router.guest.ip":"10.1.1.1","zone.network.type":"Advanced","router.ip":"10.102.194.139","router.name":"r-4-VM"}
> ,"wait":0}
> 2014-08-05 08:42:58,108 DEBUG [vmware.resource.VmwareResource]
> (DirectAgent-366:10.102.192.3) Use router's private IP for SSH control. IP :
> 10.102.194.139
> 2014-08-05 08:42:58,108 DEBUG [vmware.mo.HostMO]
> (DirectAgent-366:10.102.192.3) find VM r-4-VM on host
> 2014-08-05 08:42:58,109 INFO [vmware.mo.HostMO]
> (DirectAgent-366:10.102.192.3) VM r-4-VM not found in host cache
> 2014-08-05 08:42:58,109 DEBUG [vmware.mo.HostMO]
> (DirectAgent-366:10.102.192.3) load VM cache on host
> 2014-08-05 08:42:58,151 DEBUG [vmware.resource.VmwareResource]
> (DirectAgent-366:10.102.192.3) Find public NIC index, public network name:
> cloud.public.100, index: -1
> 2014-08-05 08:42:58,151 DEBUG [vmware.resource.VmwareResource]
> (DirectAgent-366:10.102.192.3) Plug new NIC to associate10.102.194.139 to
> 10.102.196.147
> 2014-08-05 08:42:58,199 INFO [vmware.mo.HypervisorHostHelper]
> (DirectAgent-366:10.102.192.3) Found distributed vSwitch
> com.vmware.vim25.ManagedObjectReference@1d30d21
> 2014-08-05 08:42:58,210 INFO [vmware.mo.HypervisorHostHelper]
> (DirectAgent-366:10.102.192.3) Found Distributed Virtual Port group
> cloud.public.100.0.1-dvSwitch0
> 2014-08-05 08:42:58,233 INFO [vmware.mo.HypervisorHostHelper]
> (DirectAgent-366:10.102.192.3) Updating Distributed Virtual Port group
> cloud.public.100.0.1-dvSwitch0
> 2014-08-05 08:42:58,482 DEBUG [vmware.mo.HypervisorHostHelper]
> (DirectAgent-366:10.102.192.3) Added custom field : cloud.gc.dvp
> 2014-08-05 08:42:59,272 DEBUG [cloud.api.ApiServlet]
> (20680265@qtp-27965857-15:null) ===START=== 10.140.6.50 – GET
> command=queryAsyncJobResult&jobId=4434d615-986a-41de-9813-65b2a10e4ea0&response=json&sessionkey=Irg0Tdoo%2Fb0rwRJrBDaHLjdhIXo%3D&_=1407228207738
> 2014-08-05 08:42:59,306 DEBUG [cloud.api.ApiServlet]
> (20680265@qtp-27965857-15:null) ===END=== 10.140.6.50 – GET
> command=queryAsyncJobResult&jobId=4434d615-986a-41de-9813-65b2a10e4ea0&response=json&sessionkey=Irg0Tdoo%2Fb0rwRJrBDaHLjdhIXo%3D&_=1407228207738
> 2014-08-05 08:42:59,317 ERROR [vmware.resource.VmwareResource]
> (DirectAgent-366:10.102.192.3) Failed to find DomR VIF to
> ass
[jira] [Commented] (CLOUDSTACK-6011) NPE when detach is called on a deleted volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212214#comment-14212214 ] ASF subversion and git services commented on CLOUDSTACK-6011: - Commit e2fd4ef42c92f64353b2830f5f19e5b32eafd3fa in cloudstack's branch refs/heads/4.3 from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e2fd4ef ] CLOUDSTACK-6011 . When detach is called on a deleted volume, avoid the NPE and throw an appropriate exception instead (cherry picked from commit f4a96d4c853bd4f60539b9b9e9218b42640652a9) Signed-off-by: Rohit Yadav > NPE when detach is called on a deleted volume > - > > Key: CLOUDSTACK-6011 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6011 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.3.0 >Reporter: Likitha Shetty >Assignee: Likitha Shetty >Priority: Minor > Fix For: 4.4.0 > > > Invoke detach volume api command on a deleted volume > Observed -> NullPointerException > Expected -> InvalidParamaterValueException -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6652) CLONE - [Automation] Vmware- System's StartCommand failed with "NumberFormatException" while using VMware DVS
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212212#comment-14212212
]
ASF subversion and git services commented on CLOUDSTACK-6652:
-
Commit 17676d6bb96a473facddba69be0809884db70d66 in cloudstack's branch
refs/heads/4.3 from [~sateeshc]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=17676d6 ]
CLOUDSTACK-6652 CLONE - [Automation] Vmware- System's StartCommand failed with
"NumberFormatException" while using VMware DVS
vlan id format was like "vlan://" instead of just "". This causes
numberformatexception while converting the vlan id to integer form from string
form. this was fixed for standard vswitch in bug Cloudstack-5046. now fixed for
other 2 cases of dvswitch as well as pvlan.
Signed-off-by: Sateesh Chodapuneedi
(cherry picked from commit a605ca09cd3e40a8f25ae3e36ce37f1f24ac489b)
Signed-off-by: Rohit Yadav
> CLONE - [Automation] Vmware- System's StartCommand failed with
> "NumberFormatException" while using VMware DVS
> --
>
> Key: CLOUDSTACK-6652
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6652
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, VMware
>Affects Versions: 4.3.0
> Environment: vmware ; 5.0
> branch : master (4.3)
>Reporter: Sateesh Chodapuneedi
>Assignee: Min Chen
>Priority: Blocker
> Fix For: 4.5.0
>
>
> Create build from master branch; deploy advance zone in vmware setup
> system vms are not getting created, observed NumberFormatException in ms log
> 2013-11-05 11:03:50,915 INFO [c.c.h.v.r.VmwareResource]
> (DirectAgent-45:ctx-a29b989d 10.223.250.130) Prepare NIC device based on
> NicTO:
> {"deviceId":2,"networkRateMbps":-1,"defaultNic":true,"uuid":"6f144332-f9e1-4ff6-9c15-d628272c2645","ip":"10.223.243.2","netmask":"255.255.255.192","gateway":"10.223.243.1","mac":"06:61:3a:00:00:3b","dns1":"8.8.8.8","broadcastType":"Vlan","type":"Public","broadcastUri":"vlan://510","isolationUri":"vlan://510","isSecurityGroupEnabled":false}
> 2013-11-05 11:03:50,930 INFO [c.c.h.v.r.VmwareResource]
> (DirectAgent-45:ctx-a29b989d 10.223.250.130) Prepare network on vmwaresvs
> P[vSwitch0:untagged] with name prefix: cloud.public
> 2013-11-05 11:03:50,970 WARN [c.c.h.v.r.VmwareResource]
> (DirectAgent-45:ctx-a29b989d 10.223.250.130) StartCommand failed due to
> Exception: java.lang.NumberFormatException
> Message: null
> java.lang.NumberFormatException: null
> at java.lang.Integer.parseInt(Integer.java:454)
> at java.lang.Integer.parseInt(Integer.java:527)
> at
> com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.prepareNetwork(HypervisorHostHelper.java:940)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.prepareNetworkFromNicInfo(VmwareResource.java:3533)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2880)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:519)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> 2013-11-05 11:03:50,973 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-45:ctx-a29b989d) Seq 2-1387069469: Cancelling because one of the
> answers is false and it is stop on error.
> 2013-11-05 11:03:50,973 DEBUG
[jira] [Created] (CLOUDSTACK-7914) Ability to control the promiscuous mode settings for the ESXi vSwitch port group for an isolated network
David Williams created CLOUDSTACK-7914: -- Summary: Ability to control the promiscuous mode settings for the ESXi vSwitch port group for an isolated network Key: CLOUDSTACK-7914 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7914 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Reporter: David Williams Priority: Minor It would be nice if users could configure the following settings for their self provisioned isolated networks via the ACS GUI/API: 1. Enable/disable promiscuous mode on the vSwitch port group for the isolated network 2. Enable/disable "MAC Address changes" on the vSwitch port group for the isolated network 3. Enable/disable "Forged transmits" on the vSwitch port group for the isolated network This would allow carp to work. e.g. see this pfsense page: https://doc.pfsense.org/index.php/CARP_Configuration_Troubleshooting#ESX_VDS_Promisc_Workaround -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7355) [automation] test_netscaler_configs.py uses hardcoded NetScaler credentials
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212152#comment-14212152 ] ASF subversion and git services commented on CLOUDSTACK-7355: - Commit 44663a868b73587338b174460ca36c05db9fad05 in cloudstack's branch refs/heads/master from SrikanteswaraRao Talluri [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=44663a8 ] Merge branch '4.5' * 4.5: CLOUDSTACK-7355 - test_netscaler_configs.py uses hardcoded NetScaler credentials > [automation] test_netscaler_configs.py uses hardcoded NetScaler credentials > --- > > Key: CLOUDSTACK-7355 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7355 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Affects Versions: Future, 4.5.0 >Reporter: Doug Clark >Assignee: Doug Clark > Fix For: 4.5.0 > > > test_netscaler_configs.py uses hardcoded NetScaler credentials. This makes > it impossible to execute this code without first editing it. > Suggest adding the NetScaler credentials to Marvin test_data -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7355) [automation] test_netscaler_configs.py uses hardcoded NetScaler credentials
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212151#comment-14212151 ] ASF subversion and git services commented on CLOUDSTACK-7355: - Commit 3609f604473a5b61aec016786ba2dd671e2bd56e in cloudstack's branch refs/heads/master from [~dougcl] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3609f60 ] CLOUDSTACK-7355 - test_netscaler_configs.py uses hardcoded NetScaler credentials Refactored code to use test_data instead of hardcoded NetScaler credentials Refactored code to remove large scale duplication Fixed some minor logic error in the existing tests This patch has not added or removed any of the original test-cases. Signed-off-by: SrikanteswaraRao Talluri > [automation] test_netscaler_configs.py uses hardcoded NetScaler credentials > --- > > Key: CLOUDSTACK-7355 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7355 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Affects Versions: Future, 4.5.0 >Reporter: Doug Clark >Assignee: Doug Clark > Fix For: 4.5.0 > > > test_netscaler_configs.py uses hardcoded NetScaler credentials. This makes > it impossible to execute this code without first editing it. > Suggest adding the NetScaler credentials to Marvin test_data -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7355) [automation] test_netscaler_configs.py uses hardcoded NetScaler credentials
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212149#comment-14212149 ] ASF subversion and git services commented on CLOUDSTACK-7355: - Commit 3609f604473a5b61aec016786ba2dd671e2bd56e in cloudstack's branch refs/heads/4.5 from [~dougcl] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3609f60 ] CLOUDSTACK-7355 - test_netscaler_configs.py uses hardcoded NetScaler credentials Refactored code to use test_data instead of hardcoded NetScaler credentials Refactored code to remove large scale duplication Fixed some minor logic error in the existing tests This patch has not added or removed any of the original test-cases. Signed-off-by: SrikanteswaraRao Talluri > [automation] test_netscaler_configs.py uses hardcoded NetScaler credentials > --- > > Key: CLOUDSTACK-7355 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7355 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Affects Versions: Future, 4.5.0 >Reporter: Doug Clark >Assignee: Doug Clark > Fix For: 4.5.0 > > > test_netscaler_configs.py uses hardcoded NetScaler credentials. This makes > it impossible to execute this code without first editing it. > Suggest adding the NetScaler credentials to Marvin test_data -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7860) [Automation] Fix the script "test_eip_elb.py" - Hardcoded NetScaler IP Address present in the script
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212144#comment-14212144
]
ASF subversion and git services commented on CLOUDSTACK-7860:
-
Commit 0fd5475593a29862587d73eabecf4e718f0bc5b8 in cloudstack's branch
refs/heads/master from SrikanteswaraRao Talluri
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0fd5475 ]
Merge branch '4.5'
* 4.5:
CLOUDSTACK-7885 : Fixed the script '/maint/test_vpc_host_maintenance.py'
CLOUDSTACK-7860: test_eip_elb.py - Move Netscler info out of the test case.
Read it from config. Fix attribute error. Fix pep8 issues. Fix imports.
> [Automation] Fix the script "test_eip_elb.py" - Hardcoded NetScaler IP
> Address present in the script
>
>
> Key: CLOUDSTACK-7860
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7860
> 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: Gaurav Aradhye
>Priority: Critical
> Fix For: 4.5.0
>
>
> Currently the script uses the following dictionary for netscaler IP Address
> information:
> "netscaler": {
>"ipaddress": '10.147.40.100',
>"username": 'nsroot',
>"password": 'nsroot'
> },
> Script needs to be corrected to query for the Netscaler in the setup using
> CloudStack API and use the procured netscaler information in the testcases in
> the script.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7885) [Automation] Fix the script "/maint/test_vpc_host_maintenance" - Router will not get automatically Started due to Host maintenance operations
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212143#comment-14212143 ] ASF subversion and git services commented on CLOUDSTACK-7885: - Commit 0fd5475593a29862587d73eabecf4e718f0bc5b8 in cloudstack's branch refs/heads/master from SrikanteswaraRao Talluri [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0fd5475 ] Merge branch '4.5' * 4.5: CLOUDSTACK-7885 : Fixed the script '/maint/test_vpc_host_maintenance.py' CLOUDSTACK-7860: test_eip_elb.py - Move Netscler info out of the test case. Read it from config. Fix attribute error. Fix pep8 issues. Fix imports. > [Automation] Fix the script "/maint/test_vpc_host_maintenance" - Router will > not get automatically Started due to Host maintenance operations > - > > Key: CLOUDSTACK-7885 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7885 > 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: Chandan Purushothama >Priority: Critical > Fix For: 4.5.0 > > > I see that Router is stopped consciously in the setup() method in the test > suite. The test cases check if the Router is in Running state. I checked with > Sheng and he mentioned that a Stopped Router will not get automatically > started due Host Maintenance Use Cases. Hence stop command should be removed > from the setup() Method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7885) [Automation] Fix the script "/maint/test_vpc_host_maintenance" - Router will not get automatically Started due to Host maintenance operations
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212142#comment-14212142 ] ASF subversion and git services commented on CLOUDSTACK-7885: - Commit f92fa4257a0261a72e36571c65d0c20fa17c0b9f in cloudstack's branch refs/heads/master from [~chandanp] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f92fa42 ] CLOUDSTACK-7885 : Fixed the script '/maint/test_vpc_host_maintenance.py' Signed-off-by: SrikanteswaraRao Talluri > [Automation] Fix the script "/maint/test_vpc_host_maintenance" - Router will > not get automatically Started due to Host maintenance operations > - > > Key: CLOUDSTACK-7885 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7885 > 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: Chandan Purushothama >Priority: Critical > Fix For: 4.5.0 > > > I see that Router is stopped consciously in the setup() method in the test > suite. The test cases check if the Router is in Running state. I checked with > Sheng and he mentioned that a Stopped Router will not get automatically > started due Host Maintenance Use Cases. Hence stop command should be removed > from the setup() Method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7860) [Automation] Fix the script "test_eip_elb.py" - Hardcoded NetScaler IP Address present in the script
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212141#comment-14212141
]
ASF subversion and git services commented on CLOUDSTACK-7860:
-
Commit 2bfddc55b8e886323173fe56d6735472a9da5f69 in cloudstack's branch
refs/heads/master from [~gauravaradhye]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2bfddc5 ]
CLOUDSTACK-7860: test_eip_elb.py - Move Netscler info out of the test case.
Read it from config. Fix attribute error. Fix pep8 issues. Fix imports.
Signed-off-by: SrikanteswaraRao Talluri
> [Automation] Fix the script "test_eip_elb.py" - Hardcoded NetScaler IP
> Address present in the script
>
>
> Key: CLOUDSTACK-7860
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7860
> 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: Gaurav Aradhye
>Priority: Critical
> Fix For: 4.5.0
>
>
> Currently the script uses the following dictionary for netscaler IP Address
> information:
> "netscaler": {
>"ipaddress": '10.147.40.100',
>"username": 'nsroot',
>"password": 'nsroot'
> },
> Script needs to be corrected to query for the Netscaler in the setup using
> CloudStack API and use the procured netscaler information in the testcases in
> the script.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7885) [Automation] Fix the script "/maint/test_vpc_host_maintenance" - Router will not get automatically Started due to Host maintenance operations
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212138#comment-14212138 ] ASF subversion and git services commented on CLOUDSTACK-7885: - Commit f92fa4257a0261a72e36571c65d0c20fa17c0b9f in cloudstack's branch refs/heads/4.5 from [~chandanp] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f92fa42 ] CLOUDSTACK-7885 : Fixed the script '/maint/test_vpc_host_maintenance.py' Signed-off-by: SrikanteswaraRao Talluri > [Automation] Fix the script "/maint/test_vpc_host_maintenance" - Router will > not get automatically Started due to Host maintenance operations > - > > Key: CLOUDSTACK-7885 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7885 > 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: Chandan Purushothama >Priority: Critical > Fix For: 4.5.0 > > > I see that Router is stopped consciously in the setup() method in the test > suite. The test cases check if the Router is in Running state. I checked with > Sheng and he mentioned that a Stopped Router will not get automatically > started due Host Maintenance Use Cases. Hence stop command should be removed > from the setup() Method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7860) [Automation] Fix the script "test_eip_elb.py" - Hardcoded NetScaler IP Address present in the script
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212128#comment-14212128
]
ASF subversion and git services commented on CLOUDSTACK-7860:
-
Commit 2bfddc55b8e886323173fe56d6735472a9da5f69 in cloudstack's branch
refs/heads/4.5 from [~gauravaradhye]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2bfddc5 ]
CLOUDSTACK-7860: test_eip_elb.py - Move Netscler info out of the test case.
Read it from config. Fix attribute error. Fix pep8 issues. Fix imports.
Signed-off-by: SrikanteswaraRao Talluri
> [Automation] Fix the script "test_eip_elb.py" - Hardcoded NetScaler IP
> Address present in the script
>
>
> Key: CLOUDSTACK-7860
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7860
> 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: Gaurav Aradhye
>Priority: Critical
> Fix For: 4.5.0
>
>
> Currently the script uses the following dictionary for netscaler IP Address
> information:
> "netscaler": {
>"ipaddress": '10.147.40.100',
>"username": 'nsroot',
>"password": 'nsroot'
> },
> Script needs to be corrected to query for the Netscaler in the setup using
> CloudStack API and use the procured netscaler information in the testcases in
> the script.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-245) VPC ACLs are not stored and programmed consistently
[ https://issues.apache.org/jira/browse/CLOUDSTACK-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-245: - Fix Version/s: (was: 4.5.0) (was: 4.4.0) Future > VPC ACLs are not stored and programmed consistently > --- > > Key: CLOUDSTACK-245 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-245 > 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 >Reporter: David Noland >Assignee: Kishan Kavala >Priority: Minor > Fix For: Future > > > If user specifies 1.2.3.4/24 as the CIDR for an ACL the firewall rule is > being programmed as 1.2.3.0/24. Both CIDRs are correct, but it's inconsistent > to store one thing in the database and program the firewall using another > rule. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7484) [LXC] meaningful message neededcwhen trying to attach a data disk on nfs to a LXC VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kishan Kavala updated CLOUDSTACK-7484:
--
Fix Version/s: (was: 4.5.0)
Future
> [LXC] meaningful message neededcwhen trying to attach a data disk on nfs to a
> LXC VM
>
>
> Key: CLOUDSTACK-7484
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7484
> 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
>Priority: Minor
> Fix For: Future
>
>
> Repro steps:
> Create a LXC VM
> Create a data disk on nfs storage
> Attach the created disk to LXC VM
> Bug:
> We gets message unexpected exception
> Expected Result :
> 1. Message should be more meaningful
> 2. We see exception raised in MS logs which should not be the case. we should
> handle it gracefully.
> Ms log hows :
> 2014-09-04 10:45:33,826 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-75:ctx-4a189e50 job-324/job-325 ctx-b838130b) Seq
> 4-433471464134412663: Sending { Cmd , MgmtId: 233845178472723, via:
> 4(Rack3Pod1Host49), Ver: v1, Flags: 100011,
> [{"org.apache.cloudstack.storage.command.AttachCommand":{"disk":{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"47e710d5-c35f-4926-9be9-351f5f6a9955","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"dfa2ec3c-d133-3284-8583-0a0845aa4424","id":1,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/shweta/goleta.lxc.primary","port":2049,"url":"NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary/?ROLE=Primary&STOREUUID=dfa2ec3c-d133-3284-8583-0a0845aa4424"}},"name":"Gunjan
>
> Das","size":5368709120,"path":"47e710d5-c35f-4926-9be9-351f5f6a9955","volumeId":23,"accountId":2,"format":"QCOW2","provisioningType":"THIN","id":23,"hypervisorType":"LXC"}},"diskSeq":1,"path":"47e710d5-c35f-4926-9be9-351f5f6a9955","type":"DATADISK","_details":{"managed":"false","storagePort":"2049","storageHost":"10.147.28.7","volumeSize":"5368709120"}},"vmName":"i-2-18-VM","inSeq":false,"wait":0}}]
> }
> 2014-09-04 10:45:33,898 DEBUG [c.c.a.t.Request]
> (AgentManager-Handler-3:ctx-66f694f1) Seq 4-433471464134412663: Processing:
> { Ans: , MgmtId: 233845178472723, via: 4, Ver: v1, Flags: 10,
> [{"org.apache.cloudstack.storage.command.AttachAnswer":{"result":false,"details":"org.libvirt.LibvirtException:
> unsupported configuration: Can't setup disk for non-block
> device","wait":0}}] }
> 2014-09-04 10:45:33,898 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-75:ctx-4a189e50 job-324/job-325 ctx-b838130b) Seq
> 4-433471464134412663: Received: { Ans: , MgmtId: 233845178472723, via: 4,
> Ver: v1, Flags: 10, { AttachAnswer } }
> 2014-09-04 10:45:33,900 ERROR [c.c.v.VmWorkJobHandlerProxy]
> (Work-Job-Executor-75:ctx-4a189e50 job-324/job-325 ctx-b838130b) Invocation
> exception, caused by: com.cloud.utils.exception.CloudRuntimeException: Failed
> to attach volume Gunjan Das to VM VM-b5938b03-420e-4f6c-8d60-2e0e086cd08b;
> org.libvirt.LibvirtException: unsupported configuration: Can't setup disk for
> non-block device
> 2014-09-04 10:45:33,900 INFO [c.c.v.VmWorkJobHandlerProxy]
> (Work-Job-Executor-75:ctx-4a189e50 job-324/job-325 ctx-b838130b) Rethrow
> exception com.cloud.utils.exception.CloudRuntimeException: Failed to attach
> volume Gunjan Das to VM VM-b5938b03-420e-4f6c-8d60-2e0e086cd08b;
> org.libvirt.LibvirtException: unsupported configuration: Can't setup disk for
> non-block device
> 2014-09-04 10:45:33,900 DEBUG [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-75:ctx-4a189e50 job-324/job-325) Done with run of VM work
> job: com.cloud.storage.VmWorkAttachVolume for VM 18, job origin: 324
> 2014-09-04 10:45:33,900 ERROR [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-75:ctx-4a189e50 job-324/job-325) Unable to complete
> AsyncJobVO {id:325, userId: 2, accountId: 2, instanceType: null, instanceId:
> null, cmd: com.cloud.storage.VmWorkAttachVolume, cmdInfo:
> rO0ABXNyACRjb20uY2xvdWQuc3RvcmFnZS5WbVdvcmtBdHRhY2hWb2x1bWUHra_5YYfiHAIAAkwACGRldmljZUlkdAAQTGphdmEvbGFuZy9Mb25nO0wACHZvbHVtZUlkcQB-AAF4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACABJ0ABRWb2x1bWVBcGlTZXJ2aWNlSW1wbHNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAXNxAH4ABgAX,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 233845178472723, completeMsid: null, lastUpdated:
[jira] [Updated] (CLOUDSTACK-7501) System VM fails to move from one cluster to another cluster when hypervisor type differs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-7501: -- Assignee: Bharat Kumar (was: Kishan Kavala) > System VM fails to move from one cluster to another cluster when hypervisor > type differs > > > Key: CLOUDSTACK-7501 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7501 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.5.0 > > Attachments: Ms.tar.gz > > > Repro steps: > 1. Create a LXC advance zone setup with one LXC cluster > 2. When system vms are up .add one more KVM cluster > 3. Put LXC host to maintenance > Bug: > System VM is not coming up on KVM cluster > Expected result: > System VMs should come up on KVM cluster > Ms log shows : > Cluster: 2 has HyperVisorType that does not match the VM, skipping this > cluster > which should not be the case in case of SSVM and CPVM > attaching MS logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7004) [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212097#comment-14212097 ] Bharat Kumar commented on CLOUDSTACK-7004: -- could not reproduce on 4.5 > [Automation] [KVM] Deploying a VM with rootdisksize less than the size of > template does not fail > > > Key: CLOUDSTACK-7004 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7004 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Automation, KVM >Affects Versions: 4.4.0 > Environment: KVM >Reporter: Gaurav Aradhye >Assignee: Bharat Kumar > Labels: api, automation, kvm > Fix For: 4.4.0, 4.5.0 > > > Deploy a VM with parameter rootdisksize less than the template size. > API should throw error for this but it succeeds. > Although the root disk size of deployed VM is equal to template size in this > case, but this operation should throw error and VM should not be deployed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6761) Destroying an Instance that has a Static NAT bound, the security policy is removed and the firewall filter term is removed however the proxy-arp entry is not
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212099#comment-14212099 ] ASF subversion and git services commented on CLOUDSTACK-6761: - Commit d81b67939fc7290e4026e037c313a12bbe9bd762 in cloudstack's branch refs/heads/4.3 from Jayapal [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d81b679 ] CLOUDSTACK-6761: Fixed removing proxy arp rule on deleting static nat or PF rule on ip The proxy-arp add/del is done on firewall rule add/del. The proxy-arp rule is deleted only when there is no static nat or dest nat rule is not using the ip. When there is static nat or PF and firewall rule a. Delete firewall rule. It skips delete proxy-arp because the rule is used by static nat rule. b. After deleting fw rule if we disable static nat there is no way to delete proxy-arp rule. On VM expunge we are deleting firewall rules first then static nat rules. This caused the stale proxy-arp rules. With this fix adding/deleting proxy arp rule on static nat/PF rule add/del. (cherry picked from commit 19668713ed2f12e61f538a238422d7dfd4841009) Signed-off-by: Rohit Yadav > Destroying an Instance that has a Static NAT bound, the security policy is > removed and the firewall filter term is removed however the proxy-arp entry > is not > - > > Key: CLOUDSTACK-6761 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6761 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.0.0 >Reporter: Jayapal Reddy >Assignee: Jayapal Reddy > Fix For: 4.4.0 > > > When destroying an Instance that has a Static NAT bound, the security policy > is removed and the firewall filter term is removed however the proxy-arp > entry is not > This causing issue when network is configured with SRX and load balancer. > For the same ip responses comes for two devices depending on who receives > first. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7484) [LXC] meaningful message neededcwhen trying to attach a data disk on nfs to a LXC VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212083#comment-14212083
]
Kishan Kavala commented on CLOUDSTACK-7484:
---
Logs now say:
Caused by: com.cloud.utils.exception.CloudRuntimeException: Unable to find
suitable primary storage when creating volume d1
at
org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolume(VolumeOrchestrator.java:468)
at
org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolumeOnPrimaryStorage(VolumeOrchestrator.java:774)
at
com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:1204)
at
com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:2586)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43
> [LXC] meaningful message neededcwhen trying to attach a data disk on nfs to a
> LXC VM
>
>
> Key: CLOUDSTACK-7484
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7484
> 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
>Priority: Minor
> Fix For: 4.5.0
>
>
> Repro steps:
> Create a LXC VM
> Create a data disk on nfs storage
> Attach the created disk to LXC VM
> Bug:
> We gets message unexpected exception
> Expected Result :
> 1. Message should be more meaningful
> 2. We see exception raised in MS logs which should not be the case. we should
> handle it gracefully.
> Ms log hows :
> 2014-09-04 10:45:33,826 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-75:ctx-4a189e50 job-324/job-325 ctx-b838130b) Seq
> 4-433471464134412663: Sending { Cmd , MgmtId: 233845178472723, via:
> 4(Rack3Pod1Host49), Ver: v1, Flags: 100011,
> [{"org.apache.cloudstack.storage.command.AttachCommand":{"disk":{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"47e710d5-c35f-4926-9be9-351f5f6a9955","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"dfa2ec3c-d133-3284-8583-0a0845aa4424","id":1,"poolType":"NetworkFilesystem","host":"10.147.28.7","path":"/export/home/shweta/goleta.lxc.primary","port":2049,"url":"NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary/?ROLE=Primary&STOREUUID=dfa2ec3c-d133-3284-8583-0a0845aa4424"}},"name":"Gunjan
>
> Das","size":5368709120,"path":"47e710d5-c35f-4926-9be9-351f5f6a9955","volumeId":23,"accountId":2,"format":"QCOW2","provisioningType":"THIN","id":23,"hypervisorType":"LXC"}},"diskSeq":1,"path":"47e710d5-c35f-4926-9be9-351f5f6a9955","type":"DATADISK","_details":{"managed":"false","storagePort":"2049","storageHost":"10.147.28.7","volumeSize":"5368709120"}},"vmName":"i-2-18-VM","inSeq":false,"wait":0}}]
> }
> 2014-09-04 10:45:33,898 DEBUG [c.c.a.t.Request]
> (AgentManager-Handler-3:ctx-66f694f1) Seq 4-433471464134412663: Processing:
> { Ans: , MgmtId: 233845178472723, via: 4, Ver: v1, Flags: 10,
> [{"org.apache.cloudstack.storage.command.AttachAnswer":{"result":false,"details":"org.libvirt.LibvirtException:
> unsupported configuration: Can't setup disk for non-block
> device","wait":0}}] }
> 2014-09-04 10:45:33,898 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-75:ctx-4a189e50 job-324/job-325 ctx-b838130b) Seq
> 4-433471464134412663: Received: { Ans: , MgmtId: 233845178472723, via: 4,
> Ver: v1, Flags: 10, { AttachAnswer } }
> 2014-09-04 10:45:33,900 ERROR [c.c.v.VmWorkJobHandlerProxy]
> (Work-Job-Executor-75:ctx-4a189e50 job-324/job-325 ctx-b838130b) Invocation
> exception, caused by: com.cloud.utils.exception.CloudRuntimeException: Failed
> to attach volume Gunjan Das to VM VM-b5938b03-420e-4f6c-8d60-2e0e086cd08b;
> org.libvirt.LibvirtException: unsupported configuration: Can't setup disk for
> non-block device
> 2014-09-04 10:45:33,900 INFO [c.c.v.VmWorkJobHandlerProxy]
> (Work-Job-Executor-75:ctx-4a189e50 job-324/job-325 ctx-b838130b) Rethrow
> exception com.cloud.utils.exception.CloudRuntimeException: Failed to attach
> volume Gunjan Das to VM VM-b5938b03-420e-4f6c-8d60-2e0e086cd08b;
> org.libvirt.LibvirtException: unsupported configuration: Can't setup disk for
> non-block device
> 2014-09-04 10:45:33,900 DEBUG [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-75:ctx-4a189e50 job-324/job-325) Done with run of VM work
> job: com.cloud.storage.VmWorkAttachVolume for VM 18, job origin: 324
> 2014-09-04 10:4
[jira] [Updated] (CLOUDSTACK-252) UpdateNetwork Operation on a guest network that is currently using Virtual Router for Lb services to a network offering that uses "F5" for Lb services Fails due to My
[ https://issues.apache.org/jira/browse/CLOUDSTACK-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-252: - Assignee: Jayapal Reddy (was: Kishan Kavala) > UpdateNetwork Operation on a guest network that is currently using Virtual > Router for Lb services to a network offering that uses "F5" for Lb services > Fails due to MySQLIntegrityConstraintViolationException. > --- > > Key: CLOUDSTACK-252 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-252 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: pre-4.0.0 >Reporter: Chandan Purushothama >Assignee: Jayapal Reddy > Fix For: 4.4.0, 4.5.0 > > Attachments: managementserverlog_mysqldumps.zip > > > === > Steps to Reproduce: > === > 1. On an Advanced Zone with two physical networks, create a guest network > from a network offering with services as mentioned below > mysql> select * from network_offerings where id=13 \G > *** 1. row *** >id: 13 > name: Network-SNAT-guest1 > uuid: 277b7b7a-8aeb-46f8-94e9-e83de34912a8 > unique_name: Network-SNAT-guest1 > display_text: Network-SNAT-guest1 > nw_rate: 500 > mc_rate: 10 > traffic_type: Guest > tags: guest1 > system_only: 0 > specify_vlan: 0 > service_offering_id: NULL > conserve_mode: 0 > created: 2012-09-26 18:43:35 > removed: NULL > default: 0 > availability: Optional > dedicated_lb_service: 1 > shared_source_nat_service: 0 > sort_key: 0 > redundant_router_service: 0 > state: Enabled >guest_type: Isolated >elastic_ip_service: 0 >elastic_lb_service: 0 > specify_ip_ranges: 0 > 1 row in set (0.00 sec) > mysql> select * from ntwk_offering_service_map where network_offering_id=13; > ++-++---+-+ > | id | network_offering_id | service| provider | created > | > ++-++---+-+ > | 48 | 13 | Dhcp | VirtualRouter | 2012-09-26 > 18:43:35 | > | 51 | 13 | Dns| VirtualRouter | 2012-09-26 > 18:43:35 | > | 52 | 13 | Firewall | VirtualRouter | 2012-09-26 > 18:43:35 | > | 49 | 13 | Lb | VirtualRouter | 2012-09-26 > 18:43:35 | > | 50 | 13 | PortForwarding | VirtualRouter | 2012-09-26 > 18:43:35 | > | 53 | 13 | SourceNat | VirtualRouter | 2012-09-26 > 18:43:35 | > | 46 | 13 | StaticNat | VirtualRouter | 2012-09-26 > 18:43:35 | > | 54 | 13 | UserData | VirtualRouter | 2012-09-26 > 18:43:35 | > | 47 | 13 | Vpn| VirtualRouter | 2012-09-26 > 18:43:35 | > ++-++---+-+ > 9 rows in set (0.00 sec) > mysql> > 2, Deploy three VMs on a guest network that is created from the above > mentioned network offering. > 3. Create a Load balancing rule servicing the VMs on the guest network. > 4. Stop All the VMs and UpdateNetwork to the Network offering with services > as mentioned below. Notice that the LB Service is provided by F5 in the new > network offering. > mysql> select * from network_offerings where id=18 \G > *** 1. row *** >id: 18 > name: Network-F5-guest1 > uuid: 5c7746b8-e29f-4a74-8369-e88647081053 > unique_name: Network-F5-guest1 > display_text: Network-F5-guest1 > nw_rate: 535 > mc_rate: 10 > traffic_type: Guest > tags: guest1 > system_only: 0 > specify_vlan: 0 > service_offering_id: NULL > conserve_mode: 0 > created: 2012-09-27 01:13:38 > removed: NULL > default: 0 > availability: Optional > dedicated_lb_service: 0 > shared_source_nat_service: 0 > sort_key: 0 > redundant_route
[jira] [Updated] (CLOUDSTACK-3952) Persist VR nic details in DB for additional public ranges
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-3952: -- Assignee: (was: Kishan Kavala) > Persist VR nic details in DB for additional public ranges > - > > Key: CLOUDSTACK-3952 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3952 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Reporter: Kishan Kavala > Fix For: 4.4.0, 4.5.0 > > > For non-vpcs VR, nics are dynamically created for addtional IP ranges with > different Vlan. Prepare fro migration doesn't setup the destination host > correctly due to this and migration fails. > Temporary workaround was added as part of CLOUDSTACK-3439 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-3952) Persist VR nic details in DB for additional public ranges
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212026#comment-14212026 ] Kishan Kavala commented on CLOUDSTACK-3952: --- Temporary workaround was added as part of CLOUDSTACK-3439 > Persist VR nic details in DB for additional public ranges > - > > Key: CLOUDSTACK-3952 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3952 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Reporter: Kishan Kavala >Assignee: Kishan Kavala > Fix For: 4.4.0, 4.5.0 > > > For non-vpcs VR, nics are dynamically created for addtional IP ranges with > different Vlan. Prepare fro migration doesn't setup the destination host > correctly due to this and migration fails. > Temporary workaround was added as part of CLOUDSTACK-3439 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7004) [Automation] [KVM] Deploying a VM with rootdisksize less than the size of template does not fail
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-7004: -- Assignee: Bharat Kumar (was: Kishan Kavala) > [Automation] [KVM] Deploying a VM with rootdisksize less than the size of > template does not fail > > > Key: CLOUDSTACK-7004 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7004 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Automation, KVM >Affects Versions: 4.4.0 > Environment: KVM >Reporter: Gaurav Aradhye >Assignee: Bharat Kumar > Labels: api, automation, kvm > Fix For: 4.4.0, 4.5.0 > > > Deploy a VM with parameter rootdisksize less than the template size. > API should throw error for this but it succeeds. > Although the root disk size of deployed VM is equal to template size in this > case, but this operation should throw error and VM should not be deployed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7877) The NET.IPRELEASE events are not added to usage_event on IP range deletion from Physical Networks
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damodar Reddy T updated CLOUDSTACK-7877:
Status: Reviewable (was: In Progress)
> The NET.IPRELEASE events are not added to usage_event on IP range deletion
> from Physical Networks
> -
>
> Key: CLOUDSTACK-7877
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7877
> 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, 4.3.1
>Reporter: Damodar Reddy T
>Assignee: Damodar Reddy T
> Fix For: 4.5.0
>
>
> The NET.IPRELEASE events are not added to usage_event on IP range deletion
> from Physical Networks
> Repro steps:
> ===
> - Create a zone with Advanced Networking (non Basic)
> - Navigate to Physical Networks
> - Created an IP Range for a physical network and before clicking “Add”,
> choose to “Add Account”.
> - The range was created and in the cloud database, in the cloud.usage_event
> table the following events are created:
> {noformat}
> mysql> select id,type,account_id,created,resource_name from cloud.usage_event;
> ++-++-+---+
> | id | type| account_id | created |
> resource_name |
> ++-++-+---+
> (...)
> | 19 | NET.IPASSIGN| 4| 2014-09-12 07:57:36 |
> 91.198.163.10 |
> | 20 | NET.IPASSIGN| 4 | 2014-09-12 07:57:36 |
> 91.198.163.11 |
> | 21 | NET.IPASSIGN| 4 | 2014-09-12 07:57:36 |
> 91.198.163.12 |
> | 22 | NET.IPASSIGN| 4 | 2014-09-12 07:57:36 |
> 91.198.163.13 |
> | 23 | NET.IPASSIGN| 4 | 2014-09-12 07:57:36 |
> 91.198.163.14 |
> | 24 | NET.IPASSIGN| 4 | 2014-09-12 07:57:36 |
> 91.198.163.15 |
> | 25 | NET.IPASSIGN| 4 | 2014-09-12 07:57:36 |
> 91.198.163.16 |
> | 26 | NET.IPASSIGN| 4| 2014-09-12 07:57:36 |
> 91.198.163.17 |
> | 27 | NET.IPASSIGN| 4 | 2014-09-12 07:57:36 |
> 91.198.163.18 |
> | 28 | NET.IPASSIGN| 4 | 2014-09-12 07:57:36 |
> 91.198.163.19 |
> | 29 | NET.IPASSIGN| 4 | 2014-09-12 07:57:36 |
> 91.198.163.20 |
> ++-++-+---+
> {noformat}
> - As you can see it’s assigned to the account_id=4
> - Now, I’ve removed the IP range from the UI and checked the database again.
> - noticed that no records have been added to the table, whereas I’d expect
> NET.IPRELEASE to have been inserted there for each IP address.
> As a result, the Usage doesn't release the IP in the usage_ip_address
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7642) [Upgrade]java.lang.ClassNotFoundException after upgrading to 4.5 from 4.3.0 with Xenserver HV.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Devdeep Singh resolved CLOUDSTACK-7642. --- Resolution: Fixed > [Upgrade]java.lang.ClassNotFoundException after upgrading to 4.5 from 4.3.0 > with Xenserver HV. > -- > > Key: CLOUDSTACK-7642 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7642 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.5.0 > Environment: upgrade from 4.3.0 to 4.5 using Xen server 6.2 >Reporter: manasaveloori >Assignee: Devdeep Singh >Priority: Blocker > Fix For: 4.5.0 > > Attachments: management-server.rar, mysqldump4.5.rar, > mysqldumpBeforeUp.rar > > > 1. Deployed 4.3.0 CS with 1zone,1 pod,1cluster,2 Xen 6.2 HVs using 4.3.0 > build. > 2. Registered the 4.5 template as "systemvm-xenserver-4.5" > 3. Upgraded to 4.5 and started the MS. > Observation: > Observed the following exception in MS logs .Hosts went into disconnected > stated. > 2014-09-29 13:45:26,849 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] > (ClusteredAgentManager Timer:ctx-7b268e53) Loading directly connected host > 1(Rack1Pod1Host29) > 2014-09-29 13:45:26,851 WARN [c.c.r.DiscovererBase] (ClusteredAgentManager > Timer:ctx-7b268e53) Unable to find class > com.cloud.hypervisor.xen.resource.XenServer620Resource > java.lang.ClassNotFoundException: > com.cloud.hypervisor.xen.resource.XenServer620Resource > at > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1484) > at > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1329) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:186) > at > com.cloud.resource.DiscovererBase.getResource(DiscovererBase.java:89) > at > com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:150) > at > com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:680) > at > com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:219) > at > com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:185) > at > com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:99) > at > com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.runInContext(ClusteredAgentManagerImpl.java:235) > at > org.apache.cloudstack.managed.context.ManagedContextTimerTask$1.runInContext(ManagedContextTimerTask.java:30) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > org.apache.cloudstack.managed.context.ManagedContextTimerTask.run(ManagedContextTimerTask.java:27) > at java.util.TimerThread.mainLoop(Timer.java:555) > at java.util.TimerThread.run(Timer.java:505) > 2014-09-29 13:45:26,852 WARN [c.c.a.m.AgentManagerImpl] > (ClusteredAgentManager Timer:ctx-7b268e53) Unable to load the resource: 1 > 2014-09-29 13:45:26,853 DEBUG [c.c.h.Status] (ClusteredAgentManager > Timer:ctx-7b268e53) Transition:[Resource state = Enabled, Agent event = > AgentDisconnected, Host id = 1, name = Rack1Pod1Host29] > Attaching the dumps and logs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7877) The NET.IPRELEASE events are not added to usage_event on IP range deletion from Physical Networks
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damodar Reddy T resolved CLOUDSTACK-7877.
-
Resolution: Fixed
> The NET.IPRELEASE events are not added to usage_event on IP range deletion
> from Physical Networks
> -
>
> Key: CLOUDSTACK-7877
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7877
> 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, 4.3.1
>Reporter: Damodar Reddy T
>Assignee: Damodar Reddy T
> Fix For: 4.5.0
>
>
> The NET.IPRELEASE events are not added to usage_event on IP range deletion
> from Physical Networks
> Repro steps:
> ===
> - Create a zone with Advanced Networking (non Basic)
> - Navigate to Physical Networks
> - Created an IP Range for a physical network and before clicking “Add”,
> choose to “Add Account”.
> - The range was created and in the cloud database, in the cloud.usage_event
> table the following events are created:
> {noformat}
> mysql> select id,type,account_id,created,resource_name from cloud.usage_event;
> ++-++-+---+
> | id | type| account_id | created |
> resource_name |
> ++-++-+---+
> (...)
> | 19 | NET.IPASSIGN| 4| 2014-09-12 07:57:36 |
> 91.198.163.10 |
> | 20 | NET.IPASSIGN| 4 | 2014-09-12 07:57:36 |
> 91.198.163.11 |
> | 21 | NET.IPASSIGN| 4 | 2014-09-12 07:57:36 |
> 91.198.163.12 |
> | 22 | NET.IPASSIGN| 4 | 2014-09-12 07:57:36 |
> 91.198.163.13 |
> | 23 | NET.IPASSIGN| 4 | 2014-09-12 07:57:36 |
> 91.198.163.14 |
> | 24 | NET.IPASSIGN| 4 | 2014-09-12 07:57:36 |
> 91.198.163.15 |
> | 25 | NET.IPASSIGN| 4 | 2014-09-12 07:57:36 |
> 91.198.163.16 |
> | 26 | NET.IPASSIGN| 4| 2014-09-12 07:57:36 |
> 91.198.163.17 |
> | 27 | NET.IPASSIGN| 4 | 2014-09-12 07:57:36 |
> 91.198.163.18 |
> | 28 | NET.IPASSIGN| 4 | 2014-09-12 07:57:36 |
> 91.198.163.19 |
> | 29 | NET.IPASSIGN| 4 | 2014-09-12 07:57:36 |
> 91.198.163.20 |
> ++-++-+---+
> {noformat}
> - As you can see it’s assigned to the account_id=4
> - Now, I’ve removed the IP range from the UI and checked the database again.
> - noticed that no records have been added to the table, whereas I’d expect
> NET.IPRELEASE to have been inserted there for each IP address.
> As a result, the Usage doesn't release the IP in the usage_ip_address
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7908) Addition of userid field to vm_instance table to identify user that created the VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212018#comment-14212018 ] Rohit Yadav commented on CLOUDSTACK-7908: - Fixing only this use-case is easy to do, but the general issue here is that all CloudStack entities (VMs, networks, volumes, etc) are owned by accounts and not user. The general fix would require more effort and would require us to add/change/refactor the ownership from account to user (IDs). This is under discussion on the dev ML. WIP branch: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/useraccount-refactoring > Addition of userid field to vm_instance table to identify user that created > the VM > -- > > Key: CLOUDSTACK-7908 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7908 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 > Environment: 4.3.0 >Reporter: David Williams >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.5.0, 4.6.0 > > > It would be handy/helpful if the userid of the user that created a VM was > recorded in the database in the vm_instance table. Currently, the only way I > know of to find the user that deployed a VM is by checking the logs. There's > an owner field in the vm_instance table but this seems to be the account ID > of the account the user belongs to. > By being able to find the user that deployed a VM, it makes VM cleanups much > easier since you know who to contact for each VM to check if it can be > deleted. A similar thing in the other tables for the other resources would be > useful too when trying to cleanup networks and volumes, etc. Also, if this > change went ahead, then the API and GUI could be changed also to show the > user details for the VM when listing the VM's details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7642) [Upgrade]java.lang.ClassNotFoundException after upgrading to 4.5 from 4.3.0 with Xenserver HV.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212016#comment-14212016 ] ASF subversion and git services commented on CLOUDSTACK-7642: - Commit a782495c68c2b27dff2d659ec87a0ec90c9ceb02 in cloudstack's branch refs/heads/master from [~devdeep] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a782495 ] CLOUDSTACK-7642. Class not found exception after upgrading from 4.3 to 4.5 on a XenServer hypervisor setup. The resource path has changed for xenserver resources in 4.5. On an upgraded setup the db entries in host table for the resource path needs to be updated. Made a fix in the upgrade script. > [Upgrade]java.lang.ClassNotFoundException after upgrading to 4.5 from 4.3.0 > with Xenserver HV. > -- > > Key: CLOUDSTACK-7642 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7642 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.5.0 > Environment: upgrade from 4.3.0 to 4.5 using Xen server 6.2 >Reporter: manasaveloori >Assignee: Devdeep Singh >Priority: Blocker > Fix For: 4.5.0 > > Attachments: management-server.rar, mysqldump4.5.rar, > mysqldumpBeforeUp.rar > > > 1. Deployed 4.3.0 CS with 1zone,1 pod,1cluster,2 Xen 6.2 HVs using 4.3.0 > build. > 2. Registered the 4.5 template as "systemvm-xenserver-4.5" > 3. Upgraded to 4.5 and started the MS. > Observation: > Observed the following exception in MS logs .Hosts went into disconnected > stated. > 2014-09-29 13:45:26,849 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] > (ClusteredAgentManager Timer:ctx-7b268e53) Loading directly connected host > 1(Rack1Pod1Host29) > 2014-09-29 13:45:26,851 WARN [c.c.r.DiscovererBase] (ClusteredAgentManager > Timer:ctx-7b268e53) Unable to find class > com.cloud.hypervisor.xen.resource.XenServer620Resource > java.lang.ClassNotFoundException: > com.cloud.hypervisor.xen.resource.XenServer620Resource > at > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1484) > at > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1329) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:186) > at > com.cloud.resource.DiscovererBase.getResource(DiscovererBase.java:89) > at > com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:150) > at > com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:680) > at > com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:219) > at > com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:185) > at > com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:99) > at > com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.runInContext(ClusteredAgentManagerImpl.java:235) > at > org.apache.cloudstack.managed.context.ManagedContextTimerTask$1.runInContext(ManagedContextTimerTask.java:30) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > org.apache.cloudstack.managed.context.ManagedContextTimerTask.run(ManagedContextTimerTask.java:27) > at java.util.TimerThread.mainLoop(Timer.java:555) > at java.util.TimerThread.run(Timer.java:505) > 2014-09-29 13:45:26,852 WARN [c.c.a.m.AgentManagerImpl] > (ClusteredAgentManager Timer:ctx-7b268e53) Unable to load the resource: 1 > 2014-09-29 13:45:26,853 DEBUG [c.c.h.Status] (ClusteredAgentManager > Timer:ctx-7b268e53) Transition:[Resource state = Enabled, Agent event = > AgentDisconnected, Host id = 1, name = Rack1Pod1Host29] > Attaching the dumps and logs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7642) [Upgrade]java.lang.ClassNotFoundException after upgrading to 4.5 from 4.3.0 with Xenserver HV.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212008#comment-14212008 ] ASF subversion and git services commented on CLOUDSTACK-7642: - Commit a782495c68c2b27dff2d659ec87a0ec90c9ceb02 in cloudstack's branch refs/heads/4.5 from [~devdeep] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a782495 ] CLOUDSTACK-7642. Class not found exception after upgrading from 4.3 to 4.5 on a XenServer hypervisor setup. The resource path has changed for xenserver resources in 4.5. On an upgraded setup the db entries in host table for the resource path needs to be updated. Made a fix in the upgrade script. > [Upgrade]java.lang.ClassNotFoundException after upgrading to 4.5 from 4.3.0 > with Xenserver HV. > -- > > Key: CLOUDSTACK-7642 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7642 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.5.0 > Environment: upgrade from 4.3.0 to 4.5 using Xen server 6.2 >Reporter: manasaveloori >Assignee: Devdeep Singh >Priority: Blocker > Fix For: 4.5.0 > > Attachments: management-server.rar, mysqldump4.5.rar, > mysqldumpBeforeUp.rar > > > 1. Deployed 4.3.0 CS with 1zone,1 pod,1cluster,2 Xen 6.2 HVs using 4.3.0 > build. > 2. Registered the 4.5 template as "systemvm-xenserver-4.5" > 3. Upgraded to 4.5 and started the MS. > Observation: > Observed the following exception in MS logs .Hosts went into disconnected > stated. > 2014-09-29 13:45:26,849 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] > (ClusteredAgentManager Timer:ctx-7b268e53) Loading directly connected host > 1(Rack1Pod1Host29) > 2014-09-29 13:45:26,851 WARN [c.c.r.DiscovererBase] (ClusteredAgentManager > Timer:ctx-7b268e53) Unable to find class > com.cloud.hypervisor.xen.resource.XenServer620Resource > java.lang.ClassNotFoundException: > com.cloud.hypervisor.xen.resource.XenServer620Resource > at > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1484) > at > org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1329) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:186) > at > com.cloud.resource.DiscovererBase.getResource(DiscovererBase.java:89) > at > com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:150) > at > com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:680) > at > com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:219) > at > com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:185) > at > com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:99) > at > com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.runInContext(ClusteredAgentManagerImpl.java:235) > at > org.apache.cloudstack.managed.context.ManagedContextTimerTask$1.runInContext(ManagedContextTimerTask.java:30) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > org.apache.cloudstack.managed.context.ManagedContextTimerTask.run(ManagedContextTimerTask.java:27) > at java.util.TimerThread.mainLoop(Timer.java:555) > at java.util.TimerThread.run(Timer.java:505) > 2014-09-29 13:45:26,852 WARN [c.c.a.m.AgentManagerImpl] > (ClusteredAgentManager Timer:ctx-7b268e53) Unable to load the resource: 1 > 2014-09-29 13:45:26,853 DEBUG [c.c.h.Status] (ClusteredAgentManager > Timer:ctx-7b268e53) Transition:[Resource state = Enabled, Agent event = > AgentDisconnected, Host id = 1, name = Rack1Pod1Host29] > Attaching the dumps and logs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
