[jira] [Created] (CLOUDSTACK-7169) VR_Rolling_Upgarde: command execution order changed when we restart the network
sadhu suresh created CLOUDSTACK-7169: Summary: VR_Rolling_Upgarde: command execution order changed when we restart the network Key: CLOUDSTACK-7169 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7169 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 Priority: Critical when we reboot the VR, the order is proper (i.e ip assoc first then later firewall rule next) but when restart the network ,the order has changed i.e we are programming firewall before ipassoc. 1.configure advanced zone with vmware 2.deploy a vm 3.acquire a public IP and configure the LB rule 4. restart the router 5. once the router is up ,check the command execution order 6.again perform the network restart 7.check the configured order actual result: step 4:(incase of router restart) - the order is ok as per expected (i.e programming firewall after ipassoc) Step 6:(restart network) Here order has changed and it s programming firewall rule before ipassoc please check the VR*.cfg root@cen62307 ~]# cat VR-18351526-c087-48b9-8f8b-10b2c3f8a07e.cfg #Apache CloudStack Virtual Router Config File 1.0 /opt/cloud/bin/firewall_ingress.sh -F -a 10.147.49.200:tcp:22:22:0.0.0.0/0:, /opt/cloud/bin/ipassoc.sh -A -s -f -l 10.147.49.189/24 -c eth2 -g 10.147.49.1 /opt/cloud/bin/ipassoc.sh -A -l 10.147.49.200/24 -c eth2 -g 10.147.49.1 /etc/haproxy/haproxy.cfg.new.1406117121933 global log 127.0.0.1:3914 local0 warning maxconn 4096 maxpipes 1024 chroot /var/lib/haproxy user haproxy group haproxy daemon defaults log global modetcp option dontlognull retries 3 option redispatch option forwardfor option forceclose timeout connect5000 timeout client 5 timeout server 5 listen stats_on_public 10.147.49.189:8081 mode http option httpclose stats enable stats uri /admin?stats stats realm Haproxy\ Statistics stats authadmin1:AdMiN123 listen 10_147_49_189-22 10.147.49.189:22 balance roundrobin server 10_147_49_189-22_0 10.1.1.2:22 check listen 10_147_49_200-22 10.147.49.200:22 balance roundrobin server 10_147_49_200-22_0 10.1.1.105:22 check /opt/cloud/bin/loadbalancer.sh -i 10.147.41.29 -f /etc/haproxy/haproxy.cfg.new.1406117121933 -a 10.147.49.189:22:,10.147.49.200:22:, -s 10.147.49.189:8081:0/0:,, /opt/cloud/bin/ipassoc.sh -A -s -f -l 10.147.49.189/24 -c eth2 -g 10.147.49.1
[jira] [Created] (CLOUDSTACK-7170) [Automation] Failed to add KVM agent with master
Rayees Namathponnan created CLOUDSTACK-7170: --- Summary: [Automation] Failed to add KVM agent with master Key: CLOUDSTACK-7170 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7170 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Environment: KVM - RHEL 6.3 Master Reporter: Rayees Namathponnan Priority: Blocker Fix For: 4.5.0 This issue observed in automation setup, failed add KVM agent Might be regressed after https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=173909e99d85cfcc85b017bc426950f9f16fddf0 MS log --- 2014-07-23 00:49:18,307 WARN [c.c.r.ResourceManagerImpl] (catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Unable to find the server resources at http://10.223.50.66 2014-07-23 00:49:18,310 INFO [c.c.u.e.CSExceptionErrorCode] (catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Could not find exception: com.cloud.exception.DiscoveryException in error code list for exceptions 2014-07-23 00:49:18,310 WARN [o.a.c.a.c.a.h.AddHostCmd] (catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Exception: com.cloud.exception.DiscoveryException: Unable to add the host at com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:790) at com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:585) 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.$Proxy148.discoverHosts(Unknown Source) at org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.java:142) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:694) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:517) at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:317) at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:77) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:889) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:721) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2268) at java.util.concurrent.ThreadPoolExecutor.runWorker(Thread
[jira] [Updated] (CLOUDSTACK-7170) [Automation] Failed to add KVM agent with master
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-7170: Attachment: July_23_KVM.rar > [Automation] Failed to add KVM agent with master > -- > > Key: CLOUDSTACK-7170 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7170 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 > Environment: KVM - RHEL 6.3 > Master >Reporter: Rayees Namathponnan >Priority: Blocker > Fix For: 4.5.0 > > Attachments: July_23_KVM.rar > > > This issue observed in automation setup, failed add KVM agent > Might be regressed after > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=173909e99d85cfcc85b017bc426950f9f16fddf0 > MS log > --- > 2014-07-23 00:49:18,307 WARN [c.c.r.ResourceManagerImpl] > (catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Unable to find the > server resources at http://10.223.50.66 > 2014-07-23 00:49:18,310 INFO [c.c.u.e.CSExceptionErrorCode] > (catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Could not find > exception: com.cloud.exception.DiscoveryException in error code list for > exceptions > 2014-07-23 00:49:18,310 WARN [o.a.c.a.c.a.h.AddHostCmd] > (catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Exception: > com.cloud.exception.DiscoveryException: Unable to add the host > at > com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:790) > at > com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:585) > 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.$Proxy148.discoverHosts(Unknown Source) > at > org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.java:142) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:694) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:517) > at > com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:317) > at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118) >at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115) > at com.cloud.api.ApiServlet.doGet(ApiServlet.java:77) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.
[jira] [Updated] (CLOUDSTACK-4587) VM is failing to deploy on a Legacy zone after adding zone wide primary storage and moving cluster wide primary storage to maintenance mode
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ram Ganesh updated CLOUDSTACK-4587: --- Assignee: Likitha Shetty > VM is failing to deploy on a Legacy zone after adding zone wide primary > storage and moving cluster wide primary storage to maintenance mode > > > Key: CLOUDSTACK-4587 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4587 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.1 >Reporter: Sailaja Mada >Assignee: Likitha Shetty > Fix For: 4.4.0 > > Attachments: failureloigs.rar, logs.rar, vmdeploylogs.rar > > > Steps: > 1. Upgraded from 307 to 4.2 using VMWARE Cluster with Cluster level primary > storage > 2. Add Zone wide primary storage after upgrade > 3. Move the cluster level scope storage to Maintenance mode > 4. Try to deploy new VM. > Observation: > VM is failing to deploy on a Legacy zone after adding zone wide primary > storage and moving cluster wide primary storage to maintenance mode > 2013-09-01 14:21:10,323 DEBUG [cloud.network.NetworkManagerImpl] > (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) Network > id=207 is already implemented > 2013-09-01 14:21:10,354 DEBUG [network.guru.PodBasedNetworkGuru] > (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) > Allocated a nic > NicProfile[119-35-4a8f547b-7bff-4b3f-ba10-b0146af4d1bb-10.102.195.111-null > for VM[DomainRouter|r-35-VM] > 2013-09-01 14:21:10,390 DEBUG [cloud.storage.VolumeManagerImpl] > (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) > Checking if we need to prepare 1 volumes for VM[DomainRouter|r-35-VM] > 2013-09-01 14:21:10,400 DEBUG [storage.image.TemplateDataFactoryImpl] > (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) > template 203 is already in store:2, type:Image > 2013-09-01 14:21:10,409 DEBUG [storage.image.TemplateDataFactoryImpl] > (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) > template 203 is already in store:203, type:Primary > 2013-09-01 14:21:10,410 DEBUG [storage.volume.VolumeServiceImpl] > (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) Found > template 203-2-3cfe22ca-3a33-39a0-bf5e-0dab154869fd in storage pool 203 with > VMTemplateStoragePool id: 11 > 2013-09-01 14:21:10,421 DEBUG [storage.volume.VolumeServiceImpl] > (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) Acquire > lock on VMTemplateStoragePool 11 with timeout 3600 seconds > 2013-09-01 14:21:10,423 INFO [storage.volume.VolumeServiceImpl] > (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) lock is > acquired for VMTemplateStoragePool 11 > 2013-09-01 14:21:10,431 DEBUG [storage.motion.AncientDataMotionStrategy] > (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) > copyAsync inspecting src type TEMPLATE copyAsync inspecting dest type TEMPLATE > 2013-09-01 14:21:10,519 DEBUG [storage.motion.AncientDataMotionStrategy] > (Job-Executor-119:job-199 = [ 4837d9ec-d365-4653-960c-83fa1dc4fa87 ]) copy > object failed: > java.lang.NullPointerException > at > org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyObject(AncientDataMotionStrategy.java:210) > at > org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:411) > at > org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:55) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.createBaseImageAsync(VolumeServiceImpl.java:440) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.createVolumeFromTemplateAsync(VolumeServiceImpl.java:569) > at > com.cloud.storage.VolumeManagerImpl.recreateVolume(VolumeManagerImpl.java:2536) > at > com.cloud.storage.VolumeManagerImpl.prepare(VolumeManagerImpl.java:2592) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:888) > at > com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:578) > at > com.cloud.network.router.VirtualNetworkApplianceManagerImpl.start(VirtualNetworkApplianceManagerImpl.java:2740) > at > com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startVirtualRouter(VirtualNetworkApplianceManagerImpl.java:1872) > at > com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startRouters(VirtualNetworkApplianceManagerImpl.java:1972) >
[jira] [Created] (CLOUDSTACK-7171) not getting console of user vm via virsh on kvm
shweta agarwal created CLOUDSTACK-7171: -- Summary: not getting console of user vm via virsh on kvm Key: CLOUDSTACK-7171 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7171 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Environment: KMV host on centos6.2 advance zone Reporter: shweta agarwal Priority: Critical Fix For: 4.5.0 Repro steps: Create a KVM(centos6.2) advance zone setup . Once everything is uop created a user vm with default centos 5.5 template On KVM host try to access console of this user vm via vrish Bug : Nothing happens I even tried registering ubuntu template and created a ubuntu VM still not able to access console via virsh for ubuntu VM as well But able to access console via virsh for system vms , CPVM, SSVM, router vm Attaching MS logs and kvm logs for the same -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7171) not getting console of user vm via virsh on kvm
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7171: --- Attachment: kvmhostlog.tar.gz MSlog.tar.gz build CloudPlatform-4.5.0-78-rhel6.3.tar.gz > not getting console of user vm via virsh on kvm > --- > > Key: CLOUDSTACK-7171 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7171 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 > Environment: KMV host on centos6.2 > advance zone >Reporter: shweta agarwal >Priority: Critical > Fix For: 4.5.0 > > Attachments: MSlog.tar.gz, kvmhostlog.tar.gz > > > Repro steps: > Create a KVM(centos6.2) advance zone setup . Once everything is uop created a > user vm with default centos 5.5 template > On KVM host try to access console of this user vm via vrish > Bug : > Nothing happens > I even tried registering ubuntu template and created a ubuntu VM still not > able to access console via virsh for ubuntu VM as well > But able to access console via virsh for system vms , CPVM, SSVM, router vm > Attaching MS logs and kvm logs for the same -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-6924) Exceptions are thrown when a data disk on local storage is attached/migrated to a clusterwide primary storage, zonewide primary storage or to local storage on anoth
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajesh Battala reassigned CLOUDSTACK-6924:
--
Assignee: Rajesh Battala
> Exceptions are thrown when a data disk on local storage is attached/migrated
> to a clusterwide primary storage, zonewide primary storage or to local
> storage on another host
> ---
>
> Key: CLOUDSTACK-6924
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6924
> 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
> Environment: Hyperv Setup with local storage, cluster wide primary
> storage and zone wide primary storage
>Reporter: Abhinav Roy
>Assignee: Rajesh Battala
> Fix For: 4.4.0
>
>
> Steps :
>
> 1. Deploy a hyperv Setup with multiple clusters having local storage, cluster
> wide primary storage and zone wide primary storage.
> 2. Deploy VMs with datadisk
> v1 on local storage on host1, v2 on cwps and v3 on zwps, v4 on local
> storage on host2
> 3. Detach the data disk from v1 and attach to v2 or v3 or v4
> Expected behavior :
> =
> Since the migration of a data disk on local storage to cpws , zwps or local
> storage on another host is not supported, we should error out the operation
> with appropriate error msg and should not throw any exception.
> Observed behavior :
> =
> Expecptions are thrown during these operations :
> MS logs when with conflicting Host and Cluster scope :
> ---
> 2014-06-17 15:11:47,303 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-18:ctx-fb917520) ===START=== 10.144.6.9 -- GET
> command=attachVolume&id=8fcefeed-9606-45a0-a482-48a52554ecd1&virtualMachineId=89612a65-8398-4a61-92b4-2431b9adbe52&response=json&sessionkey=usW3Wz8dQ4fHD24kCe9r5A27Tbc%3D&_=1402997805674
> 2014-06-17 15:11:47,348 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-18:ctx-fb917520 ctx-0622857b) submit async job-93, details:
> AsyncJobVO {id:93, userId: 2, accountId: 2, instanceType: Volume, instanceId:
> 23, cmd:
> org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin,
> cmdInfo:
> {"response":"json","id":"8fcefeed-9606-45a0-a482-48a52554ecd1","sessionkey":"usW3Wz8dQ4fHD24kCe9r5A27Tbc\u003d","ctxDetails":"{\"com.cloud.storage.Volume\":\"8fcefeed-9606-45a0-a482-48a52554ecd1\",\"com.cloud.vm.VirtualMachine\":\"89612a65-8398-4a61-92b4-2431b9adbe52\"}","cmdEventType":"VOLUME.ATTACH","ctxUserId":"2","virtualMachineId":"89612a65-8398-4a61-92b4-2431b9adbe52","httpmethod":"GET","_":"1402997805674","uuid":"8fcefeed-9606-45a0-a482-48a52554ecd1","ctxAccountId":"2","ctxStartEventId":"189"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-06-17 15:11:47,349 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-18:ctx-fb917520 ctx-0622857b) ===END=== 10.144.6.9 -- GET
> command=attachVolume&id=8fcefeed-9606-45a0-a482-48a52554ecd1&virtualMachineId=89612a65-8398-4a61-92b4-2431b9adbe52&response=json&sessionkey=usW3Wz8dQ4fHD24kCe9r5A27Tbc%3D&_=1402997805674
> 2014-06-17 15:11:47,354 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-60:ctx-daa38c1b job-93) Add job-93 into job monitoring
> 2014-06-17 15:11:47,354 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-60:ctx-daa38c1b job-93) Executing AsyncJobVO {id:93,
> userId: 2, accountId: 2, instanceType: Volume, instanceId: 23, cmd:
> org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin,
> cmdInfo:
> {"response":"json","id":"8fcefeed-9606-45a0-a482-48a52554ecd1","sessionkey":"usW3Wz8dQ4fHD24kCe9r5A27Tbc\u003d","ctxDetails":"{\"com.cloud.storage.Volume\":\"8fcefeed-9606-45a0-a482-48a52554ecd1\",\"com.cloud.vm.VirtualMachine\":\"89612a65-8398-4a61-92b4-2431b9adbe52\"}","cmdEventType":"VOLUME.ATTACH","ctxUserId":"2","virtualMachineId":"89612a65-8398-4a61-92b4-2431b9adbe52","httpmethod":"GET","_":"1402997805674","uuid":"8fcefeed-9606-45a0-a482-48a52554ecd1","ctxAccountId":"2","ctxStartEventId":"189"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-06-17 15:11:47,372 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-60:ctx-daa38c1b job-93 ctx-9c523ebe) Sync job-94 execution
> on object VmWorkJobQueue.12
> 2014-06-17 15:11:47,375 DEBUG [c.c.s.VolumeApiService
[jira] [Created] (CLOUDSTACK-7172) not getting Console view of vms in KVM
shweta agarwal created CLOUDSTACK-7172:
--
Summary: not getting Console view of vms in KVM
Key: CLOUDSTACK-7172
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7172
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: KVM
Affects Versions: 4.5.0
Environment: KVM advance zone on build
CloudPlatform-4.5.0-78-rhel6.3.tar.gz
Reporter: shweta agarwal
Priority: Critical
Fix For: 4.5.0
Repro steps:
1. Create an advacne zone with KVM host .
2. Once system vms are up and running try accessing console view of vm
Bug :
Console view not coming up getting message The connection was reset
Ms log shows :
014-07-23 04:38:06,662 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-5:null) Ping from 3
2014-07-23 04:38:09,002 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-4:null) SeqA 2-9868: Processing Seq 2-9868: { Cmd ,
MgmtId: -1, via: 2, Ver: v1, Flags: 11,
[{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":1,"_loadInfo":"{\n
\"connections\": []\n}","wait":0}}] }
2014-07-23 04:38:09,049 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-4:null) SeqA 2-9868: Sending Seq 2-9868: { Ans: ,
MgmtId: 233845177509765, via: 2, Ver: v1, Flags: 100010,
[{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
2014-07-23 04:38:18,964 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-13:null) SeqA 2-9869: Processing Seq 2-9869: { Cmd ,
MgmtId: -1, via: 2, Ver: v1, Flags: 11,
[{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":1,"_loadInfo":"{\n
\"connections\": []\n}","wait":0}}] }
2014-07-23 04:38:19,034 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-13:null) SeqA 2-9869: Sending Seq 2-9869: { Ans: ,
MgmtId: 233845177509765, via: 2, Ver: v1, Flags: 100010,
[{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
2014-07-23 04:38:21,992 DEBUG [c.c.s.StatsCollector]
(StatsCollector-4:ctx-a44d6b26) AutoScaling Monitor is running...
2014-07-23 04:38:27,328 DEBUG [c.c.c.ConsoleProxyManagerImpl]
(consoleproxy-1:ctx-2fbab117) Zone 1 is ready to launch console proxy
2014-07-23 04:38:27,451 DEBUG [o.a.c.s.SecondaryStorageManagerImpl]
(secstorage-1:ctx-99b6542a) Zone 1 is ready to launch secondary storage VM
2014-07-23 04:38:28,964 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-20:null) SeqA 2-9870: Processing Seq 2-9870: { Cmd ,
MgmtId: -1, via: 2, Ver: v1, Flags: 11,
[{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":1,"_loadInfo":"{\n
\"connections\": []\n}","wait":0}}] }
2014-07-23 04:38:29,029 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-20:null) SeqA 2-9870: Sending Seq 2-9870: { Ans: ,
MgmtId: 233845177509765, via: 2, Ver: v1, Flags: 100010,
[{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
attaching agent and MS logs
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7172) not getting Console view of vms in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal updated CLOUDSTACK-7172:
---
Attachment: MSlog.tar.gz
kvmhostlog.tar.gz
> not getting Console view of vms in KVM
> ---
>
> Key: CLOUDSTACK-7172
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7172
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.5.0
> Environment: KVM advance zone on build
> CloudPlatform-4.5.0-78-rhel6.3.tar.gz
>Reporter: shweta agarwal
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: MSlog.tar.gz, kvmhostlog.tar.gz
>
>
> Repro steps:
> 1. Create an advacne zone with KVM host .
> 2. Once system vms are up and running try accessing console view of vm
> Bug :
> Console view not coming up getting message The connection was reset
> Ms log shows :
> 014-07-23 04:38:06,662 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-5:null) Ping from 3
> 2014-07-23 04:38:09,002 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-4:null) SeqA 2-9868: Processing Seq 2-9868: { Cmd ,
> MgmtId: -1, via: 2, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":1,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2014-07-23 04:38:09,049 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-4:null) SeqA 2-9868: Sending Seq 2-9868: { Ans: ,
> MgmtId: 233845177509765, via: 2, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2014-07-23 04:38:18,964 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-13:null) SeqA 2-9869: Processing Seq 2-9869: { Cmd ,
> MgmtId: -1, via: 2, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":1,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2014-07-23 04:38:19,034 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-13:null) SeqA 2-9869: Sending Seq 2-9869: { Ans: ,
> MgmtId: 233845177509765, via: 2, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2014-07-23 04:38:21,992 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-4:ctx-a44d6b26) AutoScaling Monitor is running...
> 2014-07-23 04:38:27,328 DEBUG [c.c.c.ConsoleProxyManagerImpl]
> (consoleproxy-1:ctx-2fbab117) Zone 1 is ready to launch console proxy
> 2014-07-23 04:38:27,451 DEBUG [o.a.c.s.SecondaryStorageManagerImpl]
> (secstorage-1:ctx-99b6542a) Zone 1 is ready to launch secondary storage VM
> 2014-07-23 04:38:28,964 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-20:null) SeqA 2-9870: Processing Seq 2-9870: { Cmd ,
> MgmtId: -1, via: 2, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":1,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2014-07-23 04:38:29,029 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-20:null) SeqA 2-9870: Sending Seq 2-9870: { Ans: ,
> MgmtId: 233845177509765, via: 2, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> attaching agent and MS logs
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-3265) [UI] [Health Check for NS LB]Failure to create a lb health check policy returns a API response in the UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-3265: --- Summary: [UI] [Health Check for NS LB]Failure to create a lb health check policy returns a API response in the UI (was: [Health Check for NS LB]Failure to create a lb health check policy returns a API response in the UI) > [UI] [Health Check for NS LB]Failure to create a lb health check policy > returns a API response in the UI > > > Key: CLOUDSTACK-3265 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3265 > 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: Abhinav Roy >Priority: Minor > Fix For: 4.4.0 > > Attachments: lb healthchecks.jpg > > > Steps: > > 1. Create a LB rule with VR as LB provider. > 2. Attach VMs to the LB rule. > 3. Create Health check policy for that rule > Expected behaviour: > === > 1. Since VR is not the supported provider for LB health checks the policy > creation should fail gracefully. > Observed behaviour: > == > 1. The policy creation fails as expected but the API response is turned in > the UI which should not happen. A proper failure message should be displayed > instead. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6823) Brocade Network plugin to orchestrate Brocade VDX switches
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14071535#comment-14071535 ] ASF subversion and git services commented on CLOUDSTACK-6823: - Commit 628d8e66f77053de9819436739325720710175ed in cloudstack's branch refs/heads/master from [~rsabharw] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=628d8e6 ] CLOUDSTACK-6823 : First code drop for Brocade Network plugin to orchestrate Brocade VDX switches for L2 connectivity Signed-off-by: Hugo Trippaers > Brocade Network plugin to orchestrate Brocade VDX switches > -- > > Key: CLOUDSTACK-6823 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6823 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.4.0 > Environment: •CloudStack supported KVM Hypervisor, VMWare, > XenServer > • Brocade VDX switches running Network Operating System 5.0 or above. The > following models are supported: > o VDX 8770, VDX 8770-8, VDX 8770-4, VDX 6740 and VDX 6740T >Reporter: Ritu Sabharwal >Assignee: Ritu Sabharwal > Labels: Brocade > Fix For: 4.5.0 > > > This plugin is focused on providing L2 services initially with other services > coming in later. This feature is about a CloudStack network-guru plugin to > automatically orchestrate Brocade’s switches to provide tenant isolation via > VLAN. When isolated networks are created from CloudStack and allocated VLAN, > a port profile is created on the switch for the network with the VLAN profile > for the allocated VLAN which defines the VLAN membership for the overall port > profile. When a VM is created and attached to the network, the VMs MAC > address is associated with the port profile of the network. The port profile > is applied to the switch when the MAC address is learned. When the VM is > deleted, the VMs MAC address is disassociated from the port profile of the > network. When an isolated Network is deleted, the port-profile for the > network is deleted from the switches. The plugin also implements the > capability to monitor the availability of the switch when it is configured > first time. If there are no isolated Networks using the physical switch, the > monitoring capability is disabled for the switch. > The Brocade Network Plugin orchestrates Brocade’s switches using REST APIs. > The plugin uses pre-configured properties file to provide the details of > Brocade switches (IP Address, UserName, Password). In order to find out which > switches are connected to the hypervisor hosts, the plugin uses the > properties file to specify the pod to switch mapping. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-7044) [Automation] Remove "getPortableIpRangeServices" from common.py and move portableIpRange information to test_data.py
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashutosk Kelkar resolved CLOUDSTACK-7044.
-
Resolution: Fixed
> [Automation] Remove "getPortableIpRangeServices" from common.py and move
> portableIpRange information to test_data.py
>
>
> Key: CLOUDSTACK-7044
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7044
> 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: Ashutosk Kelkar
> Fix For: 4.5.0
>
>
> We do not have cloudstack config files present in the code. Hence anyone new
> who wants to run the test_portable_ip.py test cases do not have any
> information about what needs to be provided in the config file for the tests
> execution. Pushing such data to test_data.py gives an idea about what data
> should be used.
> Kindly remove the below method from common.py and add the data to
> test_data.py. Please remove the method references from test_portable_ip.py
> too.
> def getPortableIpRangeServices(config):
> """ Reads config values related to portable ip and fills up
> services accordingly"""
> services = {}
> attributeError = False
> if config.portableIpRange.startip:
> services["startip"] = config.portableIpRange.startip
> else:
> attributeError = True
> if config.portableIpRange.endip:
> services["endip"] = config.portableIpRange.endip
> else:
> attributeError = True
> if config.portableIpRange.netmask:
> services["netmask"] = config.portableIpRange.netmask
> else:
> attributeError = True
> if config.portableIpRange.gateway:
> services["gateway"] = config.portableIpRange.gateway
> else:
> attributeError = True
> if config.portableIpRange.vlan:
> services["vlan"] = config.portableIpRange.vlan
> if attributeError:
> services = FAILED
> return services
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CLOUDSTACK-7173) Resizing of data volume is throwing java NPE
shweta agarwal created CLOUDSTACK-7173:
--
Summary: Resizing of data volume is throwing java NPE
Key: CLOUDSTACK-7173
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7173
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Volumes
Affects Versions: 4.5.0
Reporter: shweta agarwal
Priority: Critical
Fix For: 4.5.0
Repro steps :
1. Create a Vm with data disk
2 . try to resize the data disk
Bug :
Resize will fail Ms log shows :
2014-07-23 05:34:53,366 ERROR [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-5:ctx-2f1038c6 job-300/job-301) Unable to complete
AsyncJobVO {id:301, userId: 2, accountId: 2, instanceType: null, instanceId:
null, cmd: com.cloud.storage.VmWorkResizeVolume, cmdInfo:
rO0ABXNyACRjb20uY2xvdWQuc3RvcmFnZS5WbVdvcmtSZXNpemVWb2x1bWVU03zH0Fe-ggIAB0oAC2N1cnJlbnRTaXplSgAHbmV3U2l6ZVoACHNocmlua09rSgAIdm9sdW1lSWRMAApuZXdNYXhJb3BzdAAQTGphdmEvbGFuZy9Mb25nO0wACm5ld01pbklvcHNxAH4AAUwAFG5ld1NlcnZpY2VPZmZlcmluZ0lkcQB-AAF4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACACZ0ABRWb2x1bWVBcGlTZXJ2aWNlSW1wbAFABQAAACtwcHNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAABA,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 233845177509765, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Wed Jul 23 05:34:53 EDT 2014}, job origin:300
java.lang.NullPointerException
at
com.cloud.storage.VmWorkResizeVolume.getNewMinIops(VmWorkResizeVolume.java:59)
at
com.cloud.storage.VolumeApiServiceImpl.orchestrateResizeVolume(VolumeApiServiceImpl.java:2630)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at
com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2654)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy183.handleVmWorkJob(Unknown Source)
at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:507)
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.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:464)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
2014-07-23 05:34:53,369 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-5:ctx-2f1038c6
[jira] [Updated] (CLOUDSTACK-7172) not getting Console view of vms in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhinandan Prateek updated CLOUDSTACK-7172:
---
Assignee: Murali Reddy
> not getting Console view of vms in KVM
> ---
>
> Key: CLOUDSTACK-7172
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7172
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.5.0
> Environment: KVM advance zone on build
> CloudPlatform-4.5.0-78-rhel6.3.tar.gz
>Reporter: shweta agarwal
>Assignee: Murali Reddy
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: MSlog.tar.gz, kvmhostlog.tar.gz
>
>
> Repro steps:
> 1. Create an advacne zone with KVM host .
> 2. Once system vms are up and running try accessing console view of vm
> Bug :
> Console view not coming up getting message The connection was reset
> Ms log shows :
> 014-07-23 04:38:06,662 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-5:null) Ping from 3
> 2014-07-23 04:38:09,002 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-4:null) SeqA 2-9868: Processing Seq 2-9868: { Cmd ,
> MgmtId: -1, via: 2, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":1,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2014-07-23 04:38:09,049 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-4:null) SeqA 2-9868: Sending Seq 2-9868: { Ans: ,
> MgmtId: 233845177509765, via: 2, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2014-07-23 04:38:18,964 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-13:null) SeqA 2-9869: Processing Seq 2-9869: { Cmd ,
> MgmtId: -1, via: 2, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":1,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2014-07-23 04:38:19,034 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-13:null) SeqA 2-9869: Sending Seq 2-9869: { Ans: ,
> MgmtId: 233845177509765, via: 2, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2014-07-23 04:38:21,992 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-4:ctx-a44d6b26) AutoScaling Monitor is running...
> 2014-07-23 04:38:27,328 DEBUG [c.c.c.ConsoleProxyManagerImpl]
> (consoleproxy-1:ctx-2fbab117) Zone 1 is ready to launch console proxy
> 2014-07-23 04:38:27,451 DEBUG [o.a.c.s.SecondaryStorageManagerImpl]
> (secstorage-1:ctx-99b6542a) Zone 1 is ready to launch secondary storage VM
> 2014-07-23 04:38:28,964 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-20:null) SeqA 2-9870: Processing Seq 2-9870: { Cmd ,
> MgmtId: -1, via: 2, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":1,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2014-07-23 04:38:29,029 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-20:null) SeqA 2-9870: Sending Seq 2-9870: { Ans: ,
> MgmtId: 233845177509765, via: 2, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> attaching agent and MS logs
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7171) not getting console of user vm via virsh on kvm
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinandan Prateek updated CLOUDSTACK-7171: --- Assignee: Murali Reddy > not getting console of user vm via virsh on kvm > --- > > Key: CLOUDSTACK-7171 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7171 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 > Environment: KMV host on centos6.2 > advance zone >Reporter: shweta agarwal >Assignee: Murali Reddy >Priority: Critical > Fix For: 4.5.0 > > Attachments: MSlog.tar.gz, kvmhostlog.tar.gz > > > Repro steps: > Create a KVM(centos6.2) advance zone setup . Once everything is uop created a > user vm with default centos 5.5 template > On KVM host try to access console of this user vm via vrish > Bug : > Nothing happens > I even tried registering ubuntu template and created a ubuntu VM still not > able to access console via virsh for ubuntu VM as well > But able to access console via virsh for system vms , CPVM, SSVM, router vm > Attaching MS logs and kvm logs for the same -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6924) Exceptions are thrown when a data disk on local storage is attached/migrated to a clusterwide primary storage, zonewide primary storage or to local storage on anothe
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajesh Battala updated CLOUDSTACK-6924:
---
Assignee: (was: Rajesh Battala)
> Exceptions are thrown when a data disk on local storage is attached/migrated
> to a clusterwide primary storage, zonewide primary storage or to local
> storage on another host
> ---
>
> Key: CLOUDSTACK-6924
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6924
> 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
> Environment: Hyperv Setup with local storage, cluster wide primary
> storage and zone wide primary storage
>Reporter: Abhinav Roy
> Fix For: 4.4.0
>
>
> Steps :
>
> 1. Deploy a hyperv Setup with multiple clusters having local storage, cluster
> wide primary storage and zone wide primary storage.
> 2. Deploy VMs with datadisk
> v1 on local storage on host1, v2 on cwps and v3 on zwps, v4 on local
> storage on host2
> 3. Detach the data disk from v1 and attach to v2 or v3 or v4
> Expected behavior :
> =
> Since the migration of a data disk on local storage to cpws , zwps or local
> storage on another host is not supported, we should error out the operation
> with appropriate error msg and should not throw any exception.
> Observed behavior :
> =
> Expecptions are thrown during these operations :
> MS logs when with conflicting Host and Cluster scope :
> ---
> 2014-06-17 15:11:47,303 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-18:ctx-fb917520) ===START=== 10.144.6.9 -- GET
> command=attachVolume&id=8fcefeed-9606-45a0-a482-48a52554ecd1&virtualMachineId=89612a65-8398-4a61-92b4-2431b9adbe52&response=json&sessionkey=usW3Wz8dQ4fHD24kCe9r5A27Tbc%3D&_=1402997805674
> 2014-06-17 15:11:47,348 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-18:ctx-fb917520 ctx-0622857b) submit async job-93, details:
> AsyncJobVO {id:93, userId: 2, accountId: 2, instanceType: Volume, instanceId:
> 23, cmd:
> org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin,
> cmdInfo:
> {"response":"json","id":"8fcefeed-9606-45a0-a482-48a52554ecd1","sessionkey":"usW3Wz8dQ4fHD24kCe9r5A27Tbc\u003d","ctxDetails":"{\"com.cloud.storage.Volume\":\"8fcefeed-9606-45a0-a482-48a52554ecd1\",\"com.cloud.vm.VirtualMachine\":\"89612a65-8398-4a61-92b4-2431b9adbe52\"}","cmdEventType":"VOLUME.ATTACH","ctxUserId":"2","virtualMachineId":"89612a65-8398-4a61-92b4-2431b9adbe52","httpmethod":"GET","_":"1402997805674","uuid":"8fcefeed-9606-45a0-a482-48a52554ecd1","ctxAccountId":"2","ctxStartEventId":"189"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-06-17 15:11:47,349 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-18:ctx-fb917520 ctx-0622857b) ===END=== 10.144.6.9 -- GET
> command=attachVolume&id=8fcefeed-9606-45a0-a482-48a52554ecd1&virtualMachineId=89612a65-8398-4a61-92b4-2431b9adbe52&response=json&sessionkey=usW3Wz8dQ4fHD24kCe9r5A27Tbc%3D&_=1402997805674
> 2014-06-17 15:11:47,354 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (API-Job-Executor-60:ctx-daa38c1b job-93) Add job-93 into job monitoring
> 2014-06-17 15:11:47,354 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-60:ctx-daa38c1b job-93) Executing AsyncJobVO {id:93,
> userId: 2, accountId: 2, instanceType: Volume, instanceId: 23, cmd:
> org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin,
> cmdInfo:
> {"response":"json","id":"8fcefeed-9606-45a0-a482-48a52554ecd1","sessionkey":"usW3Wz8dQ4fHD24kCe9r5A27Tbc\u003d","ctxDetails":"{\"com.cloud.storage.Volume\":\"8fcefeed-9606-45a0-a482-48a52554ecd1\",\"com.cloud.vm.VirtualMachine\":\"89612a65-8398-4a61-92b4-2431b9adbe52\"}","cmdEventType":"VOLUME.ATTACH","ctxUserId":"2","virtualMachineId":"89612a65-8398-4a61-92b4-2431b9adbe52","httpmethod":"GET","_":"1402997805674","uuid":"8fcefeed-9606-45a0-a482-48a52554ecd1","ctxAccountId":"2","ctxStartEventId":"189"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-06-17 15:11:47,372 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-60:ctx-daa38c1b job-93 ctx-9c523ebe) Sync job-94 execution
> on object VmWorkJobQueue.12
> 2014-06-17 15:11:47,375 DEBUG [c.c.s.VolumeApiServiceImpl]
> (API-Job-Executor-60:ctx
[jira] [Commented] (CLOUDSTACK-7170) [Automation] Failed to add KVM agent with master
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14071627#comment-14071627
]
Alex Brett commented on CLOUDSTACK-7170:
I'm seeing the same problem, I note in the logs I have I can see a couple of
connection attempts from the agent being closed, with some SSL warnings, e.g.:
{noformat}
2014-07-23 10:36:39,107 WARN [c.c.u.n.Link] (AgentManager-Selector:null) SSL:
Fail to find the generated keystore. Loading fail-safe one to continue.
2014-07-23 10:36:39,452 INFO [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-2:null) Connection from /10.220.163.38 closed but no
cleanup was done.
{noformat}
> [Automation] Failed to add KVM agent with master
> --
>
> Key: CLOUDSTACK-7170
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7170
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.5.0
> Environment: KVM - RHEL 6.3
> Master
>Reporter: Rayees Namathponnan
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: July_23_KVM.rar
>
>
> This issue observed in automation setup, failed add KVM agent
> Might be regressed after
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=173909e99d85cfcc85b017bc426950f9f16fddf0
> MS log
> ---
> 2014-07-23 00:49:18,307 WARN [c.c.r.ResourceManagerImpl]
> (catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Unable to find the
> server resources at http://10.223.50.66
> 2014-07-23 00:49:18,310 INFO [c.c.u.e.CSExceptionErrorCode]
> (catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Could not find
> exception: com.cloud.exception.DiscoveryException in error code list for
> exceptions
> 2014-07-23 00:49:18,310 WARN [o.a.c.a.c.a.h.AddHostCmd]
> (catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Exception:
> com.cloud.exception.DiscoveryException: Unable to add the host
> at
> com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:790)
> at
> com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:585)
> 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.$Proxy148.discoverHosts(Unknown Source)
> at
> org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.java:142)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
> at com.cloud.api.ApiServer.queueCommand(ApiServer.java:694)
> at com.cloud.api.ApiServer.handleRequest(ApiServer.java:517)
> at
> com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:317)
> at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118)
>at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115)
> at com.cloud.api.ApiServlet.doGet(ApiServlet.java:77)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at
> org.apache.catalina.core.Stand
[jira] [Commented] (CLOUDSTACK-7170) [Automation] Failed to add KVM agent with master
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14071629#comment-14071629
]
Alex Brett commented on CLOUDSTACK-7170:
This may also be affecting communication from the system VMs to the management
server, as on a XenServer setup they aren't communicating, and similar log
entries are observed:
{noformat}
2014-07-23 10:51:59,591 WARN [c.c.u.n.Link] (AgentManager-Selector:null) SSL:
Fail to find the generated keystore. Loading fail-safe one to continue.
2014-07-23 10:52:01,317 WARN [c.c.u.n.Link] (AgentManager-Selector:null) SSL:
Fail to find the generated keystore. Loading fail-safe one to continue.
2014-07-23 10:52:01,494 INFO [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-3:null) Connection from /10.220.165.112 closed but no
cleanup was done.
2014-07-23 10:52:01,497 INFO [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-4:null) Connection from /10.220.165.113 closed but no
cleanup was done.
{noformat}
> [Automation] Failed to add KVM agent with master
> --
>
> Key: CLOUDSTACK-7170
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7170
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.5.0
> Environment: KVM - RHEL 6.3
> Master
>Reporter: Rayees Namathponnan
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: July_23_KVM.rar
>
>
> This issue observed in automation setup, failed add KVM agent
> Might be regressed after
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=173909e99d85cfcc85b017bc426950f9f16fddf0
> MS log
> ---
> 2014-07-23 00:49:18,307 WARN [c.c.r.ResourceManagerImpl]
> (catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Unable to find the
> server resources at http://10.223.50.66
> 2014-07-23 00:49:18,310 INFO [c.c.u.e.CSExceptionErrorCode]
> (catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Could not find
> exception: com.cloud.exception.DiscoveryException in error code list for
> exceptions
> 2014-07-23 00:49:18,310 WARN [o.a.c.a.c.a.h.AddHostCmd]
> (catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Exception:
> com.cloud.exception.DiscoveryException: Unable to add the host
> at
> com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:790)
> at
> com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:585)
> 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.$Proxy148.discoverHosts(Unknown Source)
> at
> org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.java:142)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
> at com.cloud.api.ApiServer.queueCommand(ApiServer.java:694)
> at com.cloud.api.ApiServer.handleRequest(ApiServer.java:517)
> at
> com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:317)
> at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118)
>at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115)
> at com.cloud.api.ApiServlet.doGet(ApiServlet.java:77)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at
> org.apache.catalina.cor
[jira] [Commented] (CLOUDSTACK-7170) [Automation] Failed to add KVM agent with master
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14071632#comment-14071632
]
Alex Brett commented on CLOUDSTACK-7170:
Changes that I can see between a working build and a failing one (I'll see if I
can narrow this down a bit):
{noformat}
commit d3af2dbecacf260acda9f84a51a42838cc0f798c
Author: Will Stevens
Date: Tue Jul 22 17:28:01 2014 -0400
CLOUDSTACK-6886 - Fixed the issue created by the SSL feature with the SDX:
commit 173909e99d85cfcc85b017bc426950f9f16fddf0
Author: Wido den Hollander
Date: Tue Jul 22 22:28:34 2014 +0200
CLOUDSTACK-6181: Allow RBD volumes to be resized
We don't need an external script to investigate the format of the RBD
volume,
we only have to ask Libvirt to resize the volume and that will ask librbd to
do so.
commit 2c0765195a4a01ee51973c48d0561261d4fb01c6
Author: Gaurav Aradhye
Date: Tue Jul 22 04:23:10 2014 -0400
CLOUDSTACK-7147: Resolving test script issue in test_ip_reservation.py
commit 613eb12104af5c27935091127a1a19941f96e336
Author: Ashutosh K
Date: Tue Jul 22 04:57:46 2014 -0400
CLOUDSTACK-7044: Portable IP Range test case changes - reading portable ip
range from test_data.py file
commit 981becc73585c9a789b377e18af623c325b0bc7f
Author: Ashutosh K
Date: Tue Jul 22 05:05:47 2014 -0400
CLOUDSTACK-7148: Adding missing list method
commit 45888e214c949d1e48d800339b366c42a7990641
Author: Ashutosh K
Date: Mon Jul 21 03:15:07 2014 -0400
CLOUDSTACK-7137: Resolving cleanup issue in
test_escalations_securitygroups.py
commit 3b32732459730bfd4848678c95c27e2eb653cc04
Author: Min Chen
Date: Tue Jul 22 09:47:27 2014 -0700
CLOUDSTACK-7162:queryAsyncJobResult api does not return jobinstanceid.
commit 1d2124dcbf48d15d23ddbdea23a29f0ab21be6f3
Author: Hugo Trippaers
Date: Tue Jul 22 17:43:49 2014 +0200
Fix NPE reported on IRC, provide the user an informative error message
commit 4523490d44160b054de9e943f72db1d0ce06054a
Author: Santhosh Edukulla
Date: Mon Jul 21 20:49:03 2014 +0530
Fixed Coverity Issues reported
Signed-off-by: Santhosh Edukulla
commit 7d3f381d9476fec5dc7ba1cada8294bcb2df0ffa
Author: Kishan Kavala
Date: Tue Jul 22 17:50:16 2014 +0530
Set mapped device path while detaching rbd disk
commit 4bf321bd034f179c1ac9dda111fbb5e1034fadd0
Author: Hugo Trippaers
Date: Tue Jul 22 13:11:46 2014 +0200
Fix equality check using != on objects
Cleanup in the code, removing dead code
commit 28333664159dd618682b0b07352782af641d295d
Author: Hugo Trippaers
Date: Tue Jul 22 13:11:11 2014 +0200
Remove dead code
commit 70e68be4f32538b7965e916cce1f51334fadbbd5
Author: Hugo Trippaers
Date: Tue Jul 22 13:10:26 2014 +0200
Fix string encoding problem reported by coverity
commit 493fd170543658ac7602e230a336985c59e8e1a1
Author: Likitha Shetty
Date: Mon Jul 14 15:04:37 2014 +0530
CLOUDSTACK-7152. Attaching datadisk to VMs that have VM snapshot throws
'Unexpected exception'.
Like with other API commands, ensure input parameter validation for
AttachVolume happens outside the job queue.
commit b3e4c6d6dc9bf57aa880ab100a76027b2a12053d
Author: Likitha Shetty
Date: Tue Jul 22 09:48:20 2014 +0530
CLOUDSTACK-7150. [VMware] Global config 'vm.instancename' is not honored.
If global config 'vm.instancename' is set to true, VM name in vCenter
should be '-'.
commit 4596ae9aac81ecec2c1de95950da431e7490b95d
Author: sanjeev
Date: Thu Jul 17 17:19:04 2014 +0530
Changed delete method signature inside VirtualMachine class. From 4.3
onwards vm destroy has expunge parameter to expunge the vm immediately.
Signed-off-by: sanjeev
Signed-off-by: Santhosh Edukulla
commit 88f35179ef90dc4f7696b6fe2e8ee7ca4d00586c
Author: Girish Shilamkar
Date: Mon Jul 21 19:10:34 2014 -0400
Revert "CLOUDSTACK-7130: Adding BugId to failed test cases"
This reverts commit 24da72f37395a6bb612ea1d073db0155289cf000.
{noformat}
> [Automation] Failed to add KVM agent with master
> --
>
> Key: CLOUDSTACK-7170
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7170
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.5.0
> Environment: KVM - RHEL 6.3
> Master
>Reporter: Rayees Namathponnan
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: July_23_KVM.rar
>
>
> This issue observed in automation setup, failed add KVM agent
> Might be regressed after
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=173909e99d85cfcc85b017bc426950f9f16fddf0
> MS log
> ---
> 2014-07-23 00:49:18,307 WARN [c.c.r.Resour
[jira] [Updated] (CLOUDSTACK-7168) [Automation]Management Server connection with System VMs (SSVM and CPVM) gets closed and System VMs cannot perform their operations
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-7168: Summary: [Automation]Management Server connection with System VMs (SSVM and CPVM) gets closed and System VMs cannot perform their operations (was: Management Server connection with System VMs (SSVM and CPVM) gets closed and System VMs cannot perform their operations) > [Automation]Management Server connection with System VMs (SSVM and CPVM) gets > closed and System VMs cannot perform their operations > --- > > Key: CLOUDSTACK-7168 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7168 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, XenServer >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Amogh Vasekar >Priority: Blocker > Fix For: 4.5.0 > > Attachments: management-server.zip > > > After deployment of 4.5 Cloudstack setup. System VMs get deployed > successfully. But the connection between management server and system vms > gets closed. This happened on both the zones on my setup. > > Management Server Log: > > 2014-07-22 16:21:45,155 INFO [c.c.a.m.AgentManagerImpl] > (AgentManager-Handler-7:null) Connection from /10.223.57.88 closed but no > cleanup was done. > 2014-07-22 16:21:48,265 DEBUG [c.c.a.ApiServlet] > (catalina-exec-10:ctx-b0a5c72a) ===START=== 10.216.51.74 -- GET > command=listVolumes&response=json&sessionkey=7PVfBDi0Ka28miYXWJKSUv2%2Fiqg%3D&listAll=true&page=1&pagesize=20&_=1406071442911 > 2014-07-22 16:21:48,305 DEBUG [c.c.a.ApiServlet] > (catalina-exec-10:ctx-b0a5c72a ctx-0cacdb59) ===END=== 10.216.51.74 -- GET > command=listVolumes&response=json&sessionkey=7PVfBDi0Ka28miYXWJKSUv2%2Fiqg%3D&listAll=true&page=1&pagesize=20&_=1406071442911 > 2014-07-22 16:21:49,882 DEBUG [c.c.a.ApiServlet] > (catalina-exec-11:ctx-45196a92) ===START=== 10.216.51.74 -- GET > command=listVirtualMachines&response=json&sessionkey=7PVfBDi0Ka28miYXWJKSUv2%2Fiqg%3D&listAll=true&page=1&pagesize=20&_=1406071444564 > 2014-07-22 16:21:49,920 DEBUG [c.c.a.ApiServlet] > (catalina-exec-11:ctx-45196a92 ctx-5eb663f6) ===END=== 10.216.51.74 -- GET > command=listVirtualMachines&response=json&sessionkey=7PVfBDi0Ka28miYXWJKSUv2%2Fiqg%3D&listAll=true&page=1&pagesize=20&_=1406071444564 > 2014-07-22 16:21:50,656 INFO [c.c.a.m.AgentManagerImpl] > (AgentManager-Handler-9:null) Connection from /10.223.57.86 closed but no > cleanup was done. > == > Bug Impact: > == > 1. No Console view (Management Server connection to CPVM gets closed) > 2. No Template download (Management Server connection to SSVM gets closed) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7168) [Automation]Management Server connection with System VMs (SSVM and CPVM) gets closed and System VMs cannot perform their operations
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14071633#comment-14071633 ] Alex Brett commented on CLOUDSTACK-7168: This may also be the cause of CLOUDSTACK-7170 > [Automation]Management Server connection with System VMs (SSVM and CPVM) gets > closed and System VMs cannot perform their operations > --- > > Key: CLOUDSTACK-7168 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7168 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, XenServer >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Amogh Vasekar >Priority: Blocker > Fix For: 4.5.0 > > Attachments: management-server.zip > > > After deployment of 4.5 Cloudstack setup. System VMs get deployed > successfully. But the connection between management server and system vms > gets closed. This happened on both the zones on my setup. > > Management Server Log: > > 2014-07-22 16:21:45,155 INFO [c.c.a.m.AgentManagerImpl] > (AgentManager-Handler-7:null) Connection from /10.223.57.88 closed but no > cleanup was done. > 2014-07-22 16:21:48,265 DEBUG [c.c.a.ApiServlet] > (catalina-exec-10:ctx-b0a5c72a) ===START=== 10.216.51.74 -- GET > command=listVolumes&response=json&sessionkey=7PVfBDi0Ka28miYXWJKSUv2%2Fiqg%3D&listAll=true&page=1&pagesize=20&_=1406071442911 > 2014-07-22 16:21:48,305 DEBUG [c.c.a.ApiServlet] > (catalina-exec-10:ctx-b0a5c72a ctx-0cacdb59) ===END=== 10.216.51.74 -- GET > command=listVolumes&response=json&sessionkey=7PVfBDi0Ka28miYXWJKSUv2%2Fiqg%3D&listAll=true&page=1&pagesize=20&_=1406071442911 > 2014-07-22 16:21:49,882 DEBUG [c.c.a.ApiServlet] > (catalina-exec-11:ctx-45196a92) ===START=== 10.216.51.74 -- GET > command=listVirtualMachines&response=json&sessionkey=7PVfBDi0Ka28miYXWJKSUv2%2Fiqg%3D&listAll=true&page=1&pagesize=20&_=1406071444564 > 2014-07-22 16:21:49,920 DEBUG [c.c.a.ApiServlet] > (catalina-exec-11:ctx-45196a92 ctx-5eb663f6) ===END=== 10.216.51.74 -- GET > command=listVirtualMachines&response=json&sessionkey=7PVfBDi0Ka28miYXWJKSUv2%2Fiqg%3D&listAll=true&page=1&pagesize=20&_=1406071444564 > 2014-07-22 16:21:50,656 INFO [c.c.a.m.AgentManagerImpl] > (AgentManager-Handler-9:null) Connection from /10.223.57.86 closed but no > cleanup was done. > == > Bug Impact: > == > 1. No Console view (Management Server connection to CPVM gets closed) > 2. No Template download (Management Server connection to SSVM gets closed) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7173) Resizing of data volume is throwing java NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal updated CLOUDSTACK-7173:
---
Attachment: log.tar.gz
> Resizing of data volume is throwing java NPE
>
>
> Key: CLOUDSTACK-7173
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7173
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Volumes
>Affects Versions: 4.5.0
>Reporter: shweta agarwal
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: log.tar.gz
>
>
> Repro steps :
> 1. Create a Vm with data disk
> 2 . try to resize the data disk
> Bug :
> Resize will fail Ms log shows :
> 2014-07-23 05:34:53,366 ERROR [c.c.v.VmWorkJobDispatcher]
> (Work-Job-Executor-5:ctx-2f1038c6 job-300/job-301) Unable to complete
> AsyncJobVO {id:301, userId: 2, accountId: 2, instanceType: null, instanceId:
> null, cmd: com.cloud.storage.VmWorkResizeVolume, cmdInfo:
> rO0ABXNyACRjb20uY2xvdWQuc3RvcmFnZS5WbVdvcmtSZXNpemVWb2x1bWVU03zH0Fe-ggIAB0oAC2N1cnJlbnRTaXplSgAHbmV3U2l6ZVoACHNocmlua09rSgAIdm9sdW1lSWRMAApuZXdNYXhJb3BzdAAQTGphdmEvbGFuZy9Mb25nO0wACm5ld01pbklvcHNxAH4AAUwAFG5ld1NlcnZpY2VPZmZlcmluZ0lkcQB-AAF4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACACZ0ABRWb2x1bWVBcGlTZXJ2aWNlSW1wbAFABQAAACtwcHNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAABA,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 233845177509765, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Wed Jul 23 05:34:53 EDT 2014}, job origin:300
> java.lang.NullPointerException
> at
> com.cloud.storage.VmWorkResizeVolume.getNewMinIops(VmWorkResizeVolume.java:59)
> at
> com.cloud.storage.VolumeApiServiceImpl.orchestrateResizeVolume(VolumeApiServiceImpl.java:2630)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at
> com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2654)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at $Proxy183.handleVmWorkJob(Unknown Source)
> at
> com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:507)
> 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.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:464)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concur
[jira] [Created] (CLOUDSTACK-7174) [VMware] Recreating System VMs fails if global config 'vm.instancename' is set to true
Likitha Shetty created CLOUDSTACK-7174:
--
Summary: [VMware] Recreating System VMs fails if global config
'vm.instancename' is set to true
Key: CLOUDSTACK-7174
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7174
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: VMware
Affects Versions: 4.5.0
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Priority: Critical
Fix For: 4.5.0
Steps to reproduce
1. Set the global config 'vm.instancename' to true
2. Destroy SSVM
3. New SSVM fails to start with the below error
{noformat}
2014-07-23 16:49:10,768 WARN [c.c.h.v.r.VmwareResource]
(DirectAgent-5:ctx-7050a6c8 10.102.192.7, job-478/job-487, cmd: StartCommand)
StartCommand failed due to Exception: java.lang.Exception
Message: Failed to find the newly create or relocated VM. vmName: s-27-VM
java.lang.Exception: Failed to find the newly create or relocated VM. vmName:
s-27-VM
at
com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:1419)
at
com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:462)
at
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:294)
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)
2014-07-23 16:49:10,778 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-5:ctx-7050a6c8) Seq 1-1545579097118212119: Cancelling because one
of the answers is false and it is stop on error.
{noformat}
This is a regression caused by a recent commit -
5143fe404bc82dfe42b832c661b4e98a0d9ebfa8
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (CLOUDSTACK-7170) [Automation] Failed to add KVM agent with master
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14071632#comment-14071632
]
Alex Brett edited comment on CLOUDSTACK-7170 at 7/23/14 12:03 PM:
--
Changes that I can see between a working build and a failing one (I'll see if I
can narrow this down a bit):
{noformat}
commit d3af2dbecacf260acda9f84a51a42838cc0f798c
Author: Will Stevens
Date: Tue Jul 22 17:28:01 2014 -0400
CLOUDSTACK-6886 - Fixed the issue created by the SSL feature with the SDX:
commit 173909e99d85cfcc85b017bc426950f9f16fddf0
Author: Wido den Hollander
Date: Tue Jul 22 22:28:34 2014 +0200
CLOUDSTACK-6181: Allow RBD volumes to be resized
We don't need an external script to investigate the format of the RBD
volume,
we only have to ask Libvirt to resize the volume and that will ask librbd to
do so.
commit 2c0765195a4a01ee51973c48d0561261d4fb01c6
Author: Gaurav Aradhye
Date: Tue Jul 22 04:23:10 2014 -0400
CLOUDSTACK-7147: Resolving test script issue in test_ip_reservation.py
commit 613eb12104af5c27935091127a1a19941f96e336
Author: Ashutosh K
Date: Tue Jul 22 04:57:46 2014 -0400
CLOUDSTACK-7044: Portable IP Range test case changes - reading portable ip
range from test_data.py file
commit 981becc73585c9a789b377e18af623c325b0bc7f
Author: Ashutosh K
Date: Tue Jul 22 05:05:47 2014 -0400
CLOUDSTACK-7148: Adding missing list method
commit 45888e214c949d1e48d800339b366c42a7990641
Author: Ashutosh K
Date: Mon Jul 21 03:15:07 2014 -0400
CLOUDSTACK-7137: Resolving cleanup issue in
test_escalations_securitygroups.py
commit 3b32732459730bfd4848678c95c27e2eb653cc04
Author: Min Chen
Date: Tue Jul 22 09:47:27 2014 -0700
CLOUDSTACK-7162:queryAsyncJobResult api does not return jobinstanceid.
commit 1d2124dcbf48d15d23ddbdea23a29f0ab21be6f3
Author: Hugo Trippaers
Date: Tue Jul 22 17:43:49 2014 +0200
Fix NPE reported on IRC, provide the user an informative error message
commit 4523490d44160b054de9e943f72db1d0ce06054a
Author: Santhosh Edukulla
Date: Mon Jul 21 20:49:03 2014 +0530
Fixed Coverity Issues reported
Signed-off-by: Santhosh Edukulla
{noformat}
was (Author: alexbre):
Changes that I can see between a working build and a failing one (I'll see if I
can narrow this down a bit):
{noformat}
commit d3af2dbecacf260acda9f84a51a42838cc0f798c
Author: Will Stevens
Date: Tue Jul 22 17:28:01 2014 -0400
CLOUDSTACK-6886 - Fixed the issue created by the SSL feature with the SDX:
commit 173909e99d85cfcc85b017bc426950f9f16fddf0
Author: Wido den Hollander
Date: Tue Jul 22 22:28:34 2014 +0200
CLOUDSTACK-6181: Allow RBD volumes to be resized
We don't need an external script to investigate the format of the RBD
volume,
we only have to ask Libvirt to resize the volume and that will ask librbd to
do so.
commit 2c0765195a4a01ee51973c48d0561261d4fb01c6
Author: Gaurav Aradhye
Date: Tue Jul 22 04:23:10 2014 -0400
CLOUDSTACK-7147: Resolving test script issue in test_ip_reservation.py
commit 613eb12104af5c27935091127a1a19941f96e336
Author: Ashutosh K
Date: Tue Jul 22 04:57:46 2014 -0400
CLOUDSTACK-7044: Portable IP Range test case changes - reading portable ip
range from test_data.py file
commit 981becc73585c9a789b377e18af623c325b0bc7f
Author: Ashutosh K
Date: Tue Jul 22 05:05:47 2014 -0400
CLOUDSTACK-7148: Adding missing list method
commit 45888e214c949d1e48d800339b366c42a7990641
Author: Ashutosh K
Date: Mon Jul 21 03:15:07 2014 -0400
CLOUDSTACK-7137: Resolving cleanup issue in
test_escalations_securitygroups.py
commit 3b32732459730bfd4848678c95c27e2eb653cc04
Author: Min Chen
Date: Tue Jul 22 09:47:27 2014 -0700
CLOUDSTACK-7162:queryAsyncJobResult api does not return jobinstanceid.
commit 1d2124dcbf48d15d23ddbdea23a29f0ab21be6f3
Author: Hugo Trippaers
Date: Tue Jul 22 17:43:49 2014 +0200
Fix NPE reported on IRC, provide the user an informative error message
commit 4523490d44160b054de9e943f72db1d0ce06054a
Author: Santhosh Edukulla
Date: Mon Jul 21 20:49:03 2014 +0530
Fixed Coverity Issues reported
Signed-off-by: Santhosh Edukulla
commit 7d3f381d9476fec5dc7ba1cada8294bcb2df0ffa
Author: Kishan Kavala
Date: Tue Jul 22 17:50:16 2014 +0530
Set mapped device path while detaching rbd disk
commit 4bf321bd034f179c1ac9dda111fbb5e1034fadd0
Author: Hugo Trippaers
Date: Tue Jul 22 13:11:46 2014 +0200
Fix equality check using != on objects
Cleanup in the code, removing dead code
commit 28333664159dd618682b0b07352782af641d295d
Author: Hugo Trippaers
Date: Tue Jul 22 13:11:11 2014 +0200
Remove dead code
commit 70e68be4f32538b7965e916cce1f51334fadbbd5
Author: Hugo Trippaers
Date: Tue Jul 22 13:10:26 2014 +0200
Fix string encoding problem reported by coverity
commit 493fd1705436
[jira] [Comment Edited] (CLOUDSTACK-7170) [Automation] Failed to add KVM agent with master
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14071632#comment-14071632
]
Alex Brett edited comment on CLOUDSTACK-7170 at 7/23/14 12:37 PM:
--
Changes that I can see between a working build and a failing one:
{noformat}
commit 3b32732459730bfd4848678c95c27e2eb653cc04
Author: Min Chen
Date: Tue Jul 22 09:47:27 2014 -0700
CLOUDSTACK-7162:queryAsyncJobResult api does not return jobinstanceid.
commit 1d2124dcbf48d15d23ddbdea23a29f0ab21be6f3
Author: Hugo Trippaers
Date: Tue Jul 22 17:43:49 2014 +0200
Fix NPE reported on IRC, provide the user an informative error message
commit 4523490d44160b054de9e943f72db1d0ce06054a
Author: Santhosh Edukulla
Date: Mon Jul 21 20:49:03 2014 +0530
Fixed Coverity Issues reported
Signed-off-by: Santhosh Edukulla
{noformat}
was (Author: alexbre):
Changes that I can see between a working build and a failing one (I'll see if I
can narrow this down a bit):
{noformat}
commit d3af2dbecacf260acda9f84a51a42838cc0f798c
Author: Will Stevens
Date: Tue Jul 22 17:28:01 2014 -0400
CLOUDSTACK-6886 - Fixed the issue created by the SSL feature with the SDX:
commit 173909e99d85cfcc85b017bc426950f9f16fddf0
Author: Wido den Hollander
Date: Tue Jul 22 22:28:34 2014 +0200
CLOUDSTACK-6181: Allow RBD volumes to be resized
We don't need an external script to investigate the format of the RBD
volume,
we only have to ask Libvirt to resize the volume and that will ask librbd to
do so.
commit 2c0765195a4a01ee51973c48d0561261d4fb01c6
Author: Gaurav Aradhye
Date: Tue Jul 22 04:23:10 2014 -0400
CLOUDSTACK-7147: Resolving test script issue in test_ip_reservation.py
commit 613eb12104af5c27935091127a1a19941f96e336
Author: Ashutosh K
Date: Tue Jul 22 04:57:46 2014 -0400
CLOUDSTACK-7044: Portable IP Range test case changes - reading portable ip
range from test_data.py file
commit 981becc73585c9a789b377e18af623c325b0bc7f
Author: Ashutosh K
Date: Tue Jul 22 05:05:47 2014 -0400
CLOUDSTACK-7148: Adding missing list method
commit 45888e214c949d1e48d800339b366c42a7990641
Author: Ashutosh K
Date: Mon Jul 21 03:15:07 2014 -0400
CLOUDSTACK-7137: Resolving cleanup issue in
test_escalations_securitygroups.py
commit 3b32732459730bfd4848678c95c27e2eb653cc04
Author: Min Chen
Date: Tue Jul 22 09:47:27 2014 -0700
CLOUDSTACK-7162:queryAsyncJobResult api does not return jobinstanceid.
commit 1d2124dcbf48d15d23ddbdea23a29f0ab21be6f3
Author: Hugo Trippaers
Date: Tue Jul 22 17:43:49 2014 +0200
Fix NPE reported on IRC, provide the user an informative error message
commit 4523490d44160b054de9e943f72db1d0ce06054a
Author: Santhosh Edukulla
Date: Mon Jul 21 20:49:03 2014 +0530
Fixed Coverity Issues reported
Signed-off-by: Santhosh Edukulla
{noformat}
> [Automation] Failed to add KVM agent with master
> --
>
> Key: CLOUDSTACK-7170
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7170
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.5.0
> Environment: KVM - RHEL 6.3
> Master
>Reporter: Rayees Namathponnan
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: July_23_KVM.rar
>
>
> This issue observed in automation setup, failed add KVM agent
> Might be regressed after
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=173909e99d85cfcc85b017bc426950f9f16fddf0
> MS log
> ---
> 2014-07-23 00:49:18,307 WARN [c.c.r.ResourceManagerImpl]
> (catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Unable to find the
> server resources at http://10.223.50.66
> 2014-07-23 00:49:18,310 INFO [c.c.u.e.CSExceptionErrorCode]
> (catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Could not find
> exception: com.cloud.exception.DiscoveryException in error code list for
> exceptions
> 2014-07-23 00:49:18,310 WARN [o.a.c.a.c.a.h.AddHostCmd]
> (catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Exception:
> com.cloud.exception.DiscoveryException: Unable to add the host
> at
> com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:790)
> at
> com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:585)
> 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
[jira] [Commented] (CLOUDSTACK-5986) dnsmasq racy condition result in dnsmasq failed to handout IP address
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14071677#comment-14071677 ] ASF subversion and git services commented on CLOUDSTACK-5986: - Commit 9f4f9211d0aecbfeadfa626b6202109f40200125 in cloudstack's branch refs/heads/master from sanjeev [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9f4f921 ] CLOUDSTACK-5986: Test scipt to verify the fix in isolated network for non-vpc networks Signed-off-by: sanjeev > dnsmasq racy condition result in dnsmasq failed to handout IP address > - > > Key: CLOUDSTACK-5986 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5986 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.2.0, 4.2.1 >Reporter: Sheng Yang >Assignee: Sheng Yang >Priority: Critical > Fix For: 4.2.1, 4.3.0 > > > In the past, dnsmasq.leases is managed by cloudstack, and would be updated > after new entry is added(and the entry with same IP or host would be removed). > In 4.2, we introduced dhcp_release try to speed up the dnsmasq reload > process, thus result in this issue. > So in this scenario: > 1. VM1 would create entry: "mac A, IP A, host A" > 2. VM2 would create entry: "mac B, IP B, host B" > 3. VM1 destroyed and VM 2 destroyed, no change to lease file, two records > still existed. > 4. VM1 created with IP B: "mac C, IP B, host A". > At this time, lease file would only contain: "mac C, IP B, host A", because > the original entries would be removed by either IP match or host name match. > In fact dnsmasq still holds lease of IP A with mac A in memory, but record is > already removed from lease file by cloudstack. The lease file is out of sync > now. > 5. VM2 recreated with IP A, dhcp_release would be used to release the lease. > But there is no "mac A, IP A" record in the lease file, so dhcp_release > failed. > So result in dnsmasq cannot handle out the IP A to new mac D, because dnsmasq > was still holding lease for IP A with mac A and haven't been released yet. > So it only happened when user create and destroy different VMs which share > the same name but get different IPs. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-7170) [Automation] Failed to add KVM agent with master
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala reassigned CLOUDSTACK-7170: - Assignee: Kishan Kavala > [Automation] Failed to add KVM agent with master > -- > > Key: CLOUDSTACK-7170 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7170 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 > Environment: KVM - RHEL 6.3 > Master >Reporter: Rayees Namathponnan >Assignee: Kishan Kavala >Priority: Blocker > Fix For: 4.5.0 > > Attachments: July_23_KVM.rar > > > This issue observed in automation setup, failed add KVM agent > Might be regressed after > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=173909e99d85cfcc85b017bc426950f9f16fddf0 > MS log > --- > 2014-07-23 00:49:18,307 WARN [c.c.r.ResourceManagerImpl] > (catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Unable to find the > server resources at http://10.223.50.66 > 2014-07-23 00:49:18,310 INFO [c.c.u.e.CSExceptionErrorCode] > (catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Could not find > exception: com.cloud.exception.DiscoveryException in error code list for > exceptions > 2014-07-23 00:49:18,310 WARN [o.a.c.a.c.a.h.AddHostCmd] > (catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Exception: > com.cloud.exception.DiscoveryException: Unable to add the host > at > com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:790) > at > com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:585) > 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.$Proxy148.discoverHosts(Unknown Source) > at > org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.java:142) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:694) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:517) > at > com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:317) > at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118) >at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115) > at com.cloud.api.ApiServlet.doGet(ApiServlet.java:77) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catali
[jira] [Commented] (CLOUDSTACK-7170) [Automation] Failed to add KVM agent with master
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14072117#comment-14072117
]
Alex Brett commented on CLOUDSTACK-7170:
Narrowed down even further to:
{noformat}
commit 4523490d44160b054de9e943f72db1d0ce06054a
Author: Santhosh Edukulla
Date: Mon Jul 21 20:49:03 2014 +0530
Fixed Coverity Issues reported
Signed-off-by: Santhosh Edukulla
{noformat}
> [Automation] Failed to add KVM agent with master
> --
>
> Key: CLOUDSTACK-7170
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7170
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.5.0
> Environment: KVM - RHEL 6.3
> Master
>Reporter: Rayees Namathponnan
>Assignee: Kishan Kavala
>Priority: Blocker
> Fix For: 4.5.0
>
> Attachments: July_23_KVM.rar
>
>
> This issue observed in automation setup, failed add KVM agent
> Might be regressed after
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=173909e99d85cfcc85b017bc426950f9f16fddf0
> MS log
> ---
> 2014-07-23 00:49:18,307 WARN [c.c.r.ResourceManagerImpl]
> (catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Unable to find the
> server resources at http://10.223.50.66
> 2014-07-23 00:49:18,310 INFO [c.c.u.e.CSExceptionErrorCode]
> (catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Could not find
> exception: com.cloud.exception.DiscoveryException in error code list for
> exceptions
> 2014-07-23 00:49:18,310 WARN [o.a.c.a.c.a.h.AddHostCmd]
> (catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Exception:
> com.cloud.exception.DiscoveryException: Unable to add the host
> at
> com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:790)
> at
> com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:585)
> 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.$Proxy148.discoverHosts(Unknown Source)
> at
> org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.java:142)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
> at com.cloud.api.ApiServer.queueCommand(ApiServer.java:694)
> at com.cloud.api.ApiServer.handleRequest(ApiServer.java:517)
> at
> com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:317)
> at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118)
>at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115)
> at com.cloud.api.ApiServlet.doGet(ApiServlet.java:77)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at
> org.apache.catalina.valves.ErrorRepo
[jira] [Commented] (CLOUDSTACK-7168) [Automation]Management Server connection with System VMs (SSVM and CPVM) gets closed and System VMs cannot perform their operations
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14072153#comment-14072153 ] ASF subversion and git services commented on CLOUDSTACK-7168: - Commit c804660c74f08008be4f71607681c83d31f3cc55 in cloudstack's branch refs/heads/master from [~amogh.vasekar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c804660 ] CLOUDSTACK-7168: Revert "Fixed Coverity Issues reported" that broke CI This reverts commit 4523490d44160b054de9e943f72db1d0ce06054a. > [Automation]Management Server connection with System VMs (SSVM and CPVM) gets > closed and System VMs cannot perform their operations > --- > > Key: CLOUDSTACK-7168 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7168 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, XenServer >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Amogh Vasekar >Priority: Blocker > Fix For: 4.5.0 > > Attachments: management-server.zip > > > After deployment of 4.5 Cloudstack setup. System VMs get deployed > successfully. But the connection between management server and system vms > gets closed. This happened on both the zones on my setup. > > Management Server Log: > > 2014-07-22 16:21:45,155 INFO [c.c.a.m.AgentManagerImpl] > (AgentManager-Handler-7:null) Connection from /10.223.57.88 closed but no > cleanup was done. > 2014-07-22 16:21:48,265 DEBUG [c.c.a.ApiServlet] > (catalina-exec-10:ctx-b0a5c72a) ===START=== 10.216.51.74 -- GET > command=listVolumes&response=json&sessionkey=7PVfBDi0Ka28miYXWJKSUv2%2Fiqg%3D&listAll=true&page=1&pagesize=20&_=1406071442911 > 2014-07-22 16:21:48,305 DEBUG [c.c.a.ApiServlet] > (catalina-exec-10:ctx-b0a5c72a ctx-0cacdb59) ===END=== 10.216.51.74 -- GET > command=listVolumes&response=json&sessionkey=7PVfBDi0Ka28miYXWJKSUv2%2Fiqg%3D&listAll=true&page=1&pagesize=20&_=1406071442911 > 2014-07-22 16:21:49,882 DEBUG [c.c.a.ApiServlet] > (catalina-exec-11:ctx-45196a92) ===START=== 10.216.51.74 -- GET > command=listVirtualMachines&response=json&sessionkey=7PVfBDi0Ka28miYXWJKSUv2%2Fiqg%3D&listAll=true&page=1&pagesize=20&_=1406071444564 > 2014-07-22 16:21:49,920 DEBUG [c.c.a.ApiServlet] > (catalina-exec-11:ctx-45196a92 ctx-5eb663f6) ===END=== 10.216.51.74 -- GET > command=listVirtualMachines&response=json&sessionkey=7PVfBDi0Ka28miYXWJKSUv2%2Fiqg%3D&listAll=true&page=1&pagesize=20&_=1406071444564 > 2014-07-22 16:21:50,656 INFO [c.c.a.m.AgentManagerImpl] > (AgentManager-Handler-9:null) Connection from /10.223.57.86 closed but no > cleanup was done. > == > Bug Impact: > == > 1. No Console view (Management Server connection to CPVM gets closed) > 2. No Template download (Management Server connection to SSVM gets closed) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6991) VM does not get expunged even after waiting for 10 times the expunge interval time
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk resolved CLOUDSTACK-6991. --- Resolution: Cannot Reproduce Can't reproduce on the latest 4.4 branch 5ee7bf1be0fbbdf13067d82e556d25da575955b1. All the vms get expunged successfully. Gaurav, please reopen the bug if you see it fails for some specific use case. Attach the log upon reopening it. > VM does not get expunged even after waiting for 10 times the expunge interval > time > -- > > Key: CLOUDSTACK-6991 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6991 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, KVM >Affects Versions: 4.4.0 > Environment: Observed on KVM >Reporter: Gaurav Aradhye >Assignee: Alena Prokharchyk > Labels: automation > Fix For: 4.4.0 > > > Create a VM and destroy it. > VM should get expunged after expunge interval, but it stays in "Destroyed" > state. > test_09_expunge_vm failing due to this. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-7168) [Automation]Management Server connection with System VMs (SSVM and CPVM) gets closed and System VMs cannot perform their operations
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chandan Purushothama closed CLOUDSTACK-7168. Resolution: Fixed Verified on 4.5 setup > [Automation]Management Server connection with System VMs (SSVM and CPVM) gets > closed and System VMs cannot perform their operations > --- > > Key: CLOUDSTACK-7168 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7168 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, XenServer >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Amogh Vasekar >Priority: Blocker > Fix For: 4.5.0 > > Attachments: management-server.zip > > > After deployment of 4.5 Cloudstack setup. System VMs get deployed > successfully. But the connection between management server and system vms > gets closed. This happened on both the zones on my setup. > > Management Server Log: > > 2014-07-22 16:21:45,155 INFO [c.c.a.m.AgentManagerImpl] > (AgentManager-Handler-7:null) Connection from /10.223.57.88 closed but no > cleanup was done. > 2014-07-22 16:21:48,265 DEBUG [c.c.a.ApiServlet] > (catalina-exec-10:ctx-b0a5c72a) ===START=== 10.216.51.74 -- GET > command=listVolumes&response=json&sessionkey=7PVfBDi0Ka28miYXWJKSUv2%2Fiqg%3D&listAll=true&page=1&pagesize=20&_=1406071442911 > 2014-07-22 16:21:48,305 DEBUG [c.c.a.ApiServlet] > (catalina-exec-10:ctx-b0a5c72a ctx-0cacdb59) ===END=== 10.216.51.74 -- GET > command=listVolumes&response=json&sessionkey=7PVfBDi0Ka28miYXWJKSUv2%2Fiqg%3D&listAll=true&page=1&pagesize=20&_=1406071442911 > 2014-07-22 16:21:49,882 DEBUG [c.c.a.ApiServlet] > (catalina-exec-11:ctx-45196a92) ===START=== 10.216.51.74 -- GET > command=listVirtualMachines&response=json&sessionkey=7PVfBDi0Ka28miYXWJKSUv2%2Fiqg%3D&listAll=true&page=1&pagesize=20&_=1406071444564 > 2014-07-22 16:21:49,920 DEBUG [c.c.a.ApiServlet] > (catalina-exec-11:ctx-45196a92 ctx-5eb663f6) ===END=== 10.216.51.74 -- GET > command=listVirtualMachines&response=json&sessionkey=7PVfBDi0Ka28miYXWJKSUv2%2Fiqg%3D&listAll=true&page=1&pagesize=20&_=1406071444564 > 2014-07-22 16:21:50,656 INFO [c.c.a.m.AgentManagerImpl] > (AgentManager-Handler-9:null) Connection from /10.223.57.86 closed but no > cleanup was done. > == > Bug Impact: > == > 1. No Console view (Management Server connection to CPVM gets closed) > 2. No Template download (Management Server connection to SSVM gets closed) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6866) First Class object hiding feature is not working for VirtualMachine and Networks resources
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk resolved CLOUDSTACK-6866. --- Resolution: Not a Problem This is by design. 1) User can never see resources marked with display=false flag. 2) Admin can see the resources set with display=false, only when display=false is passed to the corresponding API call. Rules are explained in this ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-6436 > First Class object hiding feature is not working for VirtualMachine and > Networks resources > -- > > Key: CLOUDSTACK-6866 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6866 > 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: Observed it on 4.4 branch. >Reporter: Girish Chaudhari > > Using Admin user, the Display flag can be applied for Virtual Machine and > Networks resources. But when the list API get called on the respective > resources, it is returning wrong results. The object get hided from normal > users as well from Admin user. > I haven't check rest of the mentioned first class resources yet. > Expected results: > The resource which is marked with Display flag as '0' (False) should be hided > from normal user only, not from the Admin user -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-969) api: zone response lists vlan in it as "vlan range of zone" but the vlan belongs to physical network
[
https://issues.apache.org/jira/browse/CLOUDSTACK-969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alena Prokharchyk reassigned CLOUDSTACK-969:
Assignee: Alena Prokharchyk
> api: zone response lists vlan in it as "vlan range of zone" but the vlan
> belongs to physical network
>
>
> Key: CLOUDSTACK-969
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-969
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.0.0
>Reporter: Prasanna Santhanam
>Assignee: Alena Prokharchyk
>Priority: Minor
> Labels: marvin
> Fix For: 4.4.0
>
>
> While looking through CLOUDSTACK-968 I notice that the ZoneResponse.java
> still contains the vlan that used to be part of 2.2. This vlan now belongs to
> the PhysicalNetworkResponse.java. Right now shows up in Marvin's response
> classes for createZoneResponse
> public class ZoneResponse extends BaseResponse {
> . ..
> @SerializedName(ApiConstants.VLAN) @Param(description="the vlan range of
> the zone")
> private String vlan;
> ..
> }
> public class PhysicalNetworkResponse extends BaseResponse {
> ...
> @SerializedName(ApiConstants.VLAN) @Param(description="the vlan of the
> physical network")
> private String vlan;
> ...
> }
> On Fri, Jan 11, 2013 at 10:50 AM, Marcus Sorensen wrote
> It seems that if I set a vlan range for a zone, marvin attempts to
> set that vlan range for every physical network defined for the zone. So the
> first one succeeds, the second one fails. The vlan property should be moved
> up to be a member of the physical network as far as marvin is concerned.
> We're in the process of making changes that allow you to use the same vlan
> numbers on different physical networks anyway, since it's possible that you
> can have completely separate infrastructure on each nic
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-375) Unable to delete physical network - because there are other networks attached
[
https://issues.apache.org/jira/browse/CLOUDSTACK-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alena Prokharchyk resolved CLOUDSTACK-375.
--
Resolution: Fixed
The behavior was fixed some time ago. Right now all guest networks belonging to
the physical network, get deleted automatically once deletePhysicalNetwork is
called.
> Unable to delete physical network - because there are other networks attached
> -
>
> Key: CLOUDSTACK-375
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-375
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.0.0, 4.1.0, 4.2.0
> Environment: CS 4.1
> CentOS6.3
>Reporter: ilya musayev
> Labels: Network
> Fix For: 4.4.0
>
>
> Unable to delete physical network - because there are other networks attached
> Attempted to do a complete cleanup of the setup and start fresh.. I was able
> to delete hosts, cluster and pod but when i get to delete the Zone, i need to
> first delete the Physical Network. The physical network has other networks
> under L2/L3 switch (Guest, Management and Storage) with no IP addresses
> assigned or visible.
> When i attempt to delete the Physical Network, i get the error "The Physical
> Network is not deletable because there are networks associated to this
> physical network"
> 2012-10-18 18:40:56,824 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-4:null) submit async job-21, details: AsyncJobVO {id:21,
> userId: 2, accountId: 2, sessionKey: null, instanceType: PhysicalNetwork,
> instanceId: null, cmd: com.cloud.api.commands.DeletePhysicalNetworkCmd,
> cmdOriginator: null, cmdInfo:
> {"id":"b44e7b2c-27bc-41c7-837c-f0c37a9a85d6","response":"json","sessionkey":"f8xnTzQ2eSRR33zf93kijnlDg+w\u003d","ctxUserId":"2","_":"1350600056737","ctxAccountId":"2","ctxStartEventId":"85"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 345051904793,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2012-10-18 18:40:56,843 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-1:job-21) Executing
> com.cloud.api.commands.DeletePhysicalNetworkCmd for job-21
> 2012-10-18 18:40:56,923 ERROR [cloud.api.ApiDispatcher]
> (Job-Executor-1:job-21) Exception while executing DeletePhysicalNetworkCmd:
> com.cloud.utils.exception.CloudRuntimeException: The Physical Network is not
> deletable because there are networks associated to this physical network
> at
> com.cloud.network.NetworkManagerImpl.checkIfPhysicalNetworkIsDeletable(NetworkManagerImpl.java:5541)
> at
> com.cloud.network.NetworkManagerImpl.deletePhysicalNetwork(NetworkManagerImpl.java:5434)
> at
> com.cloud.utils.component.ComponentLocator$InterceptorDispatcher.intercept(ComponentLocator.java:1231)
> at
> com.cloud.api.commands.DeletePhysicalNetworkCmd.execute(DeletePhysicalNetworkCmd.java:74)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:138)
> at
> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:432)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> I however cannot delete the other networks or anything underneath those
> networks - nothing is available that can be deleted.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7165) [Automation] NPE observed during restart and expunge VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk updated CLOUDSTACK-7165: -- Priority: Critical (was: Blocker) > [Automation] NPE observed during restart and expunge VM > > > Key: CLOUDSTACK-7165 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7165 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 > Environment: KVM (RHEL 6.3) >Reporter: Rayees Namathponnan >Assignee: edison su >Priority: Critical > Fix For: 4.5.0 > > Attachments: Jully_22_KVM.rar > > > This issue is observed with latest automation run . NPE observed during > restart abd expunge VM > 2014-07-22 10:52:34,081 DEBUG [c.c.a.ApiServlet] > (catalina-exec-10:ctx-06101cd2) ===START=== 10.150.19.7 -- GET > command=expungeVirtualMachine&id=f991f7fa-1376-486b-be92-894638942c14&response=json&sessionkey=HKY1QrnQ2q8iKG%2FGN%2FaRArKCny4%3D&_=1406051549738 > 2014-07-22 10:52:34,099 ERROR [c.c.a.ApiServer] > (catalina-exec-10:ctx-06101cd2 ctx-e8e32432) unhandled exception executing > api command: [Ljava.lang.String;@23210413 > java.lang.NullPointerException > at > com.cloud.user.AccountManagerImpl.checkAccess(AccountManagerImpl.java:494) > at > com.cloud.user.AccountManagerImpl.checkAccess(AccountManagerImpl.java:482) > at sun.reflect.GeneratedMethodAccessor146.invoke(Unknown Source) > 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.$Proxy102.checkAccess(Unknown Source) > at > com.cloud.api.dispatch.ParamProcessWorker.doAccessChecks(ParamProcessWorker.java:232) > at > com.cloud.api.dispatch.ParamProcessWorker.processParameters(ParamProcessWorker.java:217) > at > com.cloud.api.dispatch.ParamProcessWorker.handle(ParamProcessWorker.java:89) > at > com.cloud.api.dispatch.DispatchChain.dispatch(DispatchChain.java:37) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:635) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:517) > at > com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:317) > at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115) > at com.cloud.api.ApiServlet.doGet(ApiServlet.java:77) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) > at > org.apache.coyote.http11.Http11NioProcessor.process(
[jira] [Commented] (CLOUDSTACK-7165) [Automation] NPE observed during restart and expunge VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14072505#comment-14072505 ] Alena Prokharchyk commented on CLOUDSTACK-7165: --- Reducing the priority to Critical as this problem is a race condition, and doesn't block any other operations. The problem happens when do the access check for the VM's owner, and the vm's owner is removed right before the check was performed. > [Automation] NPE observed during restart and expunge VM > > > Key: CLOUDSTACK-7165 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7165 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 > Environment: KVM (RHEL 6.3) >Reporter: Rayees Namathponnan >Assignee: edison su >Priority: Critical > Fix For: 4.5.0 > > Attachments: Jully_22_KVM.rar > > > This issue is observed with latest automation run . NPE observed during > restart abd expunge VM > 2014-07-22 10:52:34,081 DEBUG [c.c.a.ApiServlet] > (catalina-exec-10:ctx-06101cd2) ===START=== 10.150.19.7 -- GET > command=expungeVirtualMachine&id=f991f7fa-1376-486b-be92-894638942c14&response=json&sessionkey=HKY1QrnQ2q8iKG%2FGN%2FaRArKCny4%3D&_=1406051549738 > 2014-07-22 10:52:34,099 ERROR [c.c.a.ApiServer] > (catalina-exec-10:ctx-06101cd2 ctx-e8e32432) unhandled exception executing > api command: [Ljava.lang.String;@23210413 > java.lang.NullPointerException > at > com.cloud.user.AccountManagerImpl.checkAccess(AccountManagerImpl.java:494) > at > com.cloud.user.AccountManagerImpl.checkAccess(AccountManagerImpl.java:482) > at sun.reflect.GeneratedMethodAccessor146.invoke(Unknown Source) > 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.$Proxy102.checkAccess(Unknown Source) > at > com.cloud.api.dispatch.ParamProcessWorker.doAccessChecks(ParamProcessWorker.java:232) > at > com.cloud.api.dispatch.ParamProcessWorker.processParameters(ParamProcessWorker.java:217) > at > com.cloud.api.dispatch.ParamProcessWorker.handle(ParamProcessWorker.java:89) > at > com.cloud.api.dispatch.DispatchChain.dispatch(DispatchChain.java:37) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:635) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:517) > at > com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:317) > at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115) > at com.cloud.api.ApiServlet.doGet(ApiServlet.java:77) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.j
[jira] [Commented] (CLOUDSTACK-969) api: zone response lists vlan in it as "vlan range of zone" but the vlan belongs to physical network
[
https://issues.apache.org/jira/browse/CLOUDSTACK-969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14072531#comment-14072531
]
ASF subversion and git services commented on CLOUDSTACK-969:
Commit 351cc829e3dbdd27c740b8e4a0e8c3afa6252ff1 in cloudstack's branch
refs/heads/master from [~alena1108]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=351cc82 ]
CLOUDSTACK-969: Zone response - removed vlan from the zoneResponse as this
field was moved to PhysicalNetworkResponse around 3 releases ago
> api: zone response lists vlan in it as "vlan range of zone" but the vlan
> belongs to physical network
>
>
> Key: CLOUDSTACK-969
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-969
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.0.0
>Reporter: Prasanna Santhanam
>Assignee: Alena Prokharchyk
>Priority: Minor
> Labels: marvin
> Fix For: 4.4.0
>
>
> While looking through CLOUDSTACK-968 I notice that the ZoneResponse.java
> still contains the vlan that used to be part of 2.2. This vlan now belongs to
> the PhysicalNetworkResponse.java. Right now shows up in Marvin's response
> classes for createZoneResponse
> public class ZoneResponse extends BaseResponse {
> . ..
> @SerializedName(ApiConstants.VLAN) @Param(description="the vlan range of
> the zone")
> private String vlan;
> ..
> }
> public class PhysicalNetworkResponse extends BaseResponse {
> ...
> @SerializedName(ApiConstants.VLAN) @Param(description="the vlan of the
> physical network")
> private String vlan;
> ...
> }
> On Fri, Jan 11, 2013 at 10:50 AM, Marcus Sorensen wrote
> It seems that if I set a vlan range for a zone, marvin attempts to
> set that vlan range for every physical network defined for the zone. So the
> first one succeeds, the second one fails. The vlan property should be moved
> up to be a member of the physical network as far as marvin is concerned.
> We're in the process of making changes that allow you to use the same vlan
> numbers on different physical networks anyway, since it's possible that you
> can have completely separate infrastructure on each nic
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-969) api: zone response lists vlan in it as "vlan range of zone" but the vlan belongs to physical network
[
https://issues.apache.org/jira/browse/CLOUDSTACK-969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alena Prokharchyk resolved CLOUDSTACK-969.
--
Resolution: Fixed
Fixed with 351cc829e3dbdd27c740b8e4a0e8c3afa6252ff1
> api: zone response lists vlan in it as "vlan range of zone" but the vlan
> belongs to physical network
>
>
> Key: CLOUDSTACK-969
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-969
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.0.0
>Reporter: Prasanna Santhanam
>Assignee: Alena Prokharchyk
>Priority: Minor
> Labels: marvin
> Fix For: 4.4.0
>
>
> While looking through CLOUDSTACK-968 I notice that the ZoneResponse.java
> still contains the vlan that used to be part of 2.2. This vlan now belongs to
> the PhysicalNetworkResponse.java. Right now shows up in Marvin's response
> classes for createZoneResponse
> public class ZoneResponse extends BaseResponse {
> . ..
> @SerializedName(ApiConstants.VLAN) @Param(description="the vlan range of
> the zone")
> private String vlan;
> ..
> }
> public class PhysicalNetworkResponse extends BaseResponse {
> ...
> @SerializedName(ApiConstants.VLAN) @Param(description="the vlan of the
> physical network")
> private String vlan;
> ...
> }
> On Fri, Jan 11, 2013 at 10:50 AM, Marcus Sorensen wrote
> It seems that if I set a vlan range for a zone, marvin attempts to
> set that vlan range for every physical network defined for the zone. So the
> first one succeeds, the second one fails. The vlan property should be moved
> up to be a member of the physical network as far as marvin is concerned.
> We're in the process of making changes that allow you to use the same vlan
> numbers on different physical networks anyway, since it's possible that you
> can have completely separate infrastructure on each nic
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CLOUDSTACK-7175) Domain Id is exposed in error message when cross domain access is attempted when listing Vms.
Min Chen created CLOUDSTACK-7175: Summary: Domain Id is exposed in error message when cross domain access is attempted when listing Vms. Key: CLOUDSTACK-7175 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7175 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: IAM Affects Versions: 4.2.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 Domain Id is exposed in error message when cross domain access is attempted when listing Vms. Steps to reproduce the problem: Following listVirtualMachines when passing a domain Id that the caller does not have access permissions that exposes domain Id. In such cases , only uuid of the domain should be presented to the user: Scenario 1: GET http:///client/api?command=listVirtualMachines&domainId=ac6dfd54-c1ad-401d-8bbf-de1c77795a60&account=testD1-TestVMList-GEFMGD&listAll=true&apiKey=Hv0VKnmBjXhyRMKZ7ixI51gG-iqHqRVTp1xCCLU2-gTnZwhuUNWsa4zZLYZWWLD5lEhvwe05tJKJVa9NeS5REw&signature=UtajpNj839fVNm8tZkNMdJJoRCM%3D \n\n current Time: Fri Apr 11 11:01:23 PDT 2014 4314350could not find account testD1-TestVMList-GEFMGD in domain ac6dfd54-c1ad-401d-8bbf-de1c77795a60Connection to 10.223.49.6 8080 port [tcp/webcache] succeeded! GET http:///client/api?command=listVirtualMachines&domainId=ca50d169-bbb2-4f2d-b61a-963151ade5ed&account=testD1-TestVMList-GEFMGD&listAll=true&apiKey=Hv0VKnmBjXhyRMKZ7ixI51gG-iqHqRVTp1xCCLU2-gTnZwhuUNWsa4zZLYZWWLD5lEhvwe05tJKJVa9NeS5REw&signature=gMDWL4B7jI%2Bm5sDlR47atlJlMao%3D \n\n current Time: Fri Apr 11 11:01:23 PDT 2014 5314365Acct[c913ca88-30de-4ce7-9160-cce514314e4f-testD1-TestVMList-3VK254] does not have permission to operate within domain id=9Connection to 10.223.49.6 8080 port [tcp/webcache] succeeded! GET http:///client/api?command=listVirtualMachines&domainId=ca50d169-bbb2-4f2d-b61a-963151ade5ed&listAll=true&apiKey=Hv0VKnmBjXhyRMKZ7ixI51gG-iqHqRVTp1xCCLU2-gTnZwhuUNWsa4zZLYZWWLD5lEhvwe05tJKJVa9NeS5REw&signature=nvUKFsegTkIhdPH39%2BulAYjiCac%3D \n\n current Time: Fri Apr 11 11:01:21 PDT 2014 5314365Acct[cf5d6b37-4e26-406c-9b32-15bc3bf71095-testD1-TestVMList-3VK254] does not have permission to operate within domain id=9Connection to 10.223.49.6 8080 port [tcp/webcache] succeeded! -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-7175) Domain Id is exposed in error message when cross domain access is attempted when listing Vms.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-7175. -- Resolution: Fixed > Domain Id is exposed in error message when cross domain access is attempted > when listing Vms. > - > > Key: CLOUDSTACK-7175 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7175 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: IAM >Affects Versions: 4.2.0 >Reporter: Min Chen >Assignee: Min Chen >Priority: Critical > Fix For: 4.5.0 > > > Domain Id is exposed in error message when cross domain access is attempted > when listing Vms. > Steps to reproduce the problem: > Following listVirtualMachines when passing a domain Id that the caller does > not have access permissions that exposes domain Id. In such cases , only uuid > of the domain should be presented to the user: > Scenario 1: > GET > http:///client/api?command=listVirtualMachines&domainId=ac6dfd54-c1ad-401d-8bbf-de1c77795a60&account=testD1-TestVMList-GEFMGD&listAll=true&apiKey=Hv0VKnmBjXhyRMKZ7ixI51gG-iqHqRVTp1xCCLU2-gTnZwhuUNWsa4zZLYZWWLD5lEhvwe05tJKJVa9NeS5REw&signature=UtajpNj839fVNm8tZkNMdJJoRCM%3D > \n\n > current Time: Fri Apr 11 11:01:23 PDT 2014 > cloud-stack-version="4.4.0-SNAPSHOT">4314350could > not find account testD1-TestVMList-GEFMGD in domain > ac6dfd54-c1ad-401d-8bbf-de1c77795a60Connection > to 10.223.49.6 8080 port [tcp/webcache] succeeded! > GET > http:///client/api?command=listVirtualMachines&domainId=ca50d169-bbb2-4f2d-b61a-963151ade5ed&account=testD1-TestVMList-GEFMGD&listAll=true&apiKey=Hv0VKnmBjXhyRMKZ7ixI51gG-iqHqRVTp1xCCLU2-gTnZwhuUNWsa4zZLYZWWLD5lEhvwe05tJKJVa9NeS5REw&signature=gMDWL4B7jI%2Bm5sDlR47atlJlMao%3D > \n\n > current Time: Fri Apr 11 11:01:23 PDT 2014 > cloud-stack-version="4.4.0-SNAPSHOT">5314365Acct[c913ca88-30de-4ce7-9160-cce514314e4f-testD1-TestVMList-3VK254] > does not have permission to operate within domain > id=9Connection to 10.223.49.6 8080 > port [tcp/webcache] succeeded! > GET > http:///client/api?command=listVirtualMachines&domainId=ca50d169-bbb2-4f2d-b61a-963151ade5ed&listAll=true&apiKey=Hv0VKnmBjXhyRMKZ7ixI51gG-iqHqRVTp1xCCLU2-gTnZwhuUNWsa4zZLYZWWLD5lEhvwe05tJKJVa9NeS5REw&signature=nvUKFsegTkIhdPH39%2BulAYjiCac%3D > \n\n > current Time: Fri Apr 11 11:01:21 PDT 2014 > cloud-stack-version="4.4.0-SNAPSHOT">5314365Acct[cf5d6b37-4e26-406c-9b32-15bc3bf71095-testD1-TestVMList-3VK254] > does not have permission to operate within domain > id=9Connection to 10.223.49.6 8080 > port [tcp/webcache] succeeded! -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7175) Domain Id is exposed in error message when cross domain access is attempted when listing Vms.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14072646#comment-14072646 ] ASF subversion and git services commented on CLOUDSTACK-7175: - Commit e6ead3176c2132d38283dc404ae601506e278a34 in cloudstack's branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e6ead31 ] CLOUDSTACK-7175:Domain Id is exposed in error message when cross domain access is attempted when listing Vms. > Domain Id is exposed in error message when cross domain access is attempted > when listing Vms. > - > > Key: CLOUDSTACK-7175 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7175 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: IAM >Affects Versions: 4.2.0 >Reporter: Min Chen >Assignee: Min Chen >Priority: Critical > Fix For: 4.5.0 > > > Domain Id is exposed in error message when cross domain access is attempted > when listing Vms. > Steps to reproduce the problem: > Following listVirtualMachines when passing a domain Id that the caller does > not have access permissions that exposes domain Id. In such cases , only uuid > of the domain should be presented to the user: > Scenario 1: > GET > http:///client/api?command=listVirtualMachines&domainId=ac6dfd54-c1ad-401d-8bbf-de1c77795a60&account=testD1-TestVMList-GEFMGD&listAll=true&apiKey=Hv0VKnmBjXhyRMKZ7ixI51gG-iqHqRVTp1xCCLU2-gTnZwhuUNWsa4zZLYZWWLD5lEhvwe05tJKJVa9NeS5REw&signature=UtajpNj839fVNm8tZkNMdJJoRCM%3D > \n\n > current Time: Fri Apr 11 11:01:23 PDT 2014 > cloud-stack-version="4.4.0-SNAPSHOT">4314350could > not find account testD1-TestVMList-GEFMGD in domain > ac6dfd54-c1ad-401d-8bbf-de1c77795a60Connection > to 10.223.49.6 8080 port [tcp/webcache] succeeded! > GET > http:///client/api?command=listVirtualMachines&domainId=ca50d169-bbb2-4f2d-b61a-963151ade5ed&account=testD1-TestVMList-GEFMGD&listAll=true&apiKey=Hv0VKnmBjXhyRMKZ7ixI51gG-iqHqRVTp1xCCLU2-gTnZwhuUNWsa4zZLYZWWLD5lEhvwe05tJKJVa9NeS5REw&signature=gMDWL4B7jI%2Bm5sDlR47atlJlMao%3D > \n\n > current Time: Fri Apr 11 11:01:23 PDT 2014 > cloud-stack-version="4.4.0-SNAPSHOT">5314365Acct[c913ca88-30de-4ce7-9160-cce514314e4f-testD1-TestVMList-3VK254] > does not have permission to operate within domain > id=9Connection to 10.223.49.6 8080 > port [tcp/webcache] succeeded! > GET > http:///client/api?command=listVirtualMachines&domainId=ca50d169-bbb2-4f2d-b61a-963151ade5ed&listAll=true&apiKey=Hv0VKnmBjXhyRMKZ7ixI51gG-iqHqRVTp1xCCLU2-gTnZwhuUNWsa4zZLYZWWLD5lEhvwe05tJKJVa9NeS5REw&signature=nvUKFsegTkIhdPH39%2BulAYjiCac%3D > \n\n > current Time: Fri Apr 11 11:01:21 PDT 2014 > cloud-stack-version="4.4.0-SNAPSHOT">5314365Acct[cf5d6b37-4e26-406c-9b32-15bc3bf71095-testD1-TestVMList-3VK254] > does not have permission to operate within domain > id=9Connection to 10.223.49.6 8080 > port [tcp/webcache] succeeded! -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7176) vmware:default route is wrongly configured when deploy a vm with multiple networks
sadhu suresh created CLOUDSTACK-7176: Summary: 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 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) ID d66e7992-136b-4f10-9d76-48813347871b Network Nametwo TypeIsolated IP Address 10.1.1.36 Gateway 10.1.1.1 Netmask 255.255.255.0 IPv6 IP Address IPv6 Gateway IPv6 CIDR Is Default Yes NIC 2 ID bb49621f-a1f3-40fc-8416-a295c390a7c7 Network Nameone111 TypeIsolated IP Address 10.1.1.48 Gateway 10.1.1.1 Netmask 255.255.255.0 IPv6 IP Address IPv6 Gateway IPv6 CIDR Is Default No -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7177) AlertSyslogAppender does not honor a non-default port specified in syslog host parameter
Anshul Gangwar created CLOUDSTACK-7177: -- Summary: AlertSyslogAppender does not honor a non-default port specified in syslog host parameter Key: CLOUDSTACK-7177 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7177 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Reporter: Anshul Gangwar Assignee: Anshul Gangwar The AlertSyslogAppender does not currently honor a port number specified as part of the sysloghost parameter in log4j-cloud.xml (like so: IP:Port). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5999) Virtual Router does not start if Guest VM is rebooted from CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14072834#comment-14072834 ] ASF subversion and git services commented on CLOUDSTACK-5999: - Commit 0f85e649b64b38cf80bc1e86ac15b206bef65117 in cloudstack's branch refs/heads/master from [~saksham] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0f85e64 ] CLOUDSTACK-5999: Virtual Router does not start if Guest VM is rebooted from CloudStack > Virtual Router does not start if Guest VM is rebooted from CloudStack > - > > Key: CLOUDSTACK-5999 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5999 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Saksham Srivastava >Assignee: Saksham Srivastava > Labels: S1 > Fix For: 4.4.0 > > > When a guest is rebooted from CloudStack, if the virtual router managing the > guest network of that guest is down, CloudStack will not start the virtual > router > However the router is started in case the guest vm is stopped and then > started. -- This message was sent by Atlassian JIRA (v6.2#6252)
