[jira] [Created] (CLOUDSTACK-5412) Zone Creation Wizard mislabels CIFS Server
Donal Lafferty created CLOUDSTACK-5412: -- Summary: Zone Creation Wizard mislabels CIFS Server Key: CLOUDSTACK-5412 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5412 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Website Affects Versions: 4.3.0 Reporter: Donal Lafferty Assignee: Devdeep Singh Priority: Minor Under secondary storage tab, if you select SMB/cifs, it asks you for the NFS Server. This should say SMB/cifs server. Also, cifs should be capitalised, e.g. CIFS. See http://en.wikipedia.org/wiki/Server_Message_Block -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5412) Zone Creation Wizard mislabels CIFS Server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Devdeep Singh updated CLOUDSTACK-5412: -- Assignee: (was: Devdeep Singh) Zone Creation Wizard mislabels CIFS Server -- Key: CLOUDSTACK-5412 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5412 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Website Affects Versions: 4.3.0 Reporter: Donal Lafferty Priority: Minor Under secondary storage tab, if you select SMB/cifs, it asks you for the NFS Server. This should say SMB/cifs server. Also, cifs should be capitalised, e.g. CIFS. See http://en.wikipedia.org/wiki/Server_Message_Block -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5345) dont show upgrade router to new template if the router is already upgraded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinandan Prateek updated CLOUDSTACK-5345: --- Assignee: Jessica Wang (was: Kishan Kavala) dont show upgrade router to new template if the router is already upgraded -- Key: CLOUDSTACK-5345 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5345 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: shweta agarwal Assignee: Jessica Wang Fix For: 4.3.0 Attachments: upgrade router.jpg Repro steps : if routers are already upgraded to new system VM template don't show upgrade router to new template action item. Applicable for group by zone/pod cluster also. i.e if all the VRs in a pod/cluster/zone are upgraded and requires upgrade comes is no t hen don't show upgrade router to new template action button. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-3607) guest_os_hypervisor table has values that are not registered in guest_os table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi updated CLOUDSTACK-3607: Assignee: Abhinandan Prateek (was: Sanjay Tripathi) guest_os_hypervisor table has values that are not registered in guest_os table -- Key: CLOUDSTACK-3607 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3607 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Reporter: Chandan Purushothama Assignee: Abhinandan Prateek Priority: Critical Fix For: 4.3.0 mysql select * from guest_os_hypervisor where guest_os_id not in (select id from guest_os); +-+-++-+ | id | hypervisor_type | guest_os_name | guest_os_id | +-+-++-+ | 128 | VmWare | Red Hat Enterprise Linux 6(32-bit) | 204 | | 129 | VmWare | Red Hat Enterprise Linux 6(64-bit) | 205 | +-+-++-+ 2 rows in set (0.07 sec) -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-3608) guest_os_hypervisor table has repeated mappings of hypervisor and guest OS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi updated CLOUDSTACK-3608: Assignee: Abhinandan Prateek (was: Sanjay Tripathi) guest_os_hypervisor table has repeated mappings of hypervisor and guest OS Key: CLOUDSTACK-3608 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3608 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Reporter: Chandan Purushothama Assignee: Abhinandan Prateek Priority: Critical Fix For: 4.3.0 mysql select hypervisor_type,guest_os_name,guest_os_id from guest_os_hypervisor where guest_os_id in (165,166,167,168); +-+--+-+ | hypervisor_type | guest_os_name| guest_os_id | +-+--+-+ | XenServer | Windows 8 (32-bit) | 165 | | XenServer | Windows 8 (64-bit) | 166 | | XenServer | Windows Server 2012 (64-bit) | 167 | | XenServer | Windows Server 8 (64-bit)| 168 | | VmWare | Windows 8 (32-bit) | 165 | | VmWare | Windows 8 (64-bit) | 166 | | VmWare | Windows Server 2012 (64-bit) | 167 | | VmWare | Windows Server 8 (64-bit)| 168 | | VmWare | Windows 8 (32-bit) | 165 | | VmWare | Windows 8 (64-bit) | 166 | | VmWare | Windows Server 2012 (64-bit) | 167 | | VmWare | Windows Server 8 (64-bit)| 168 | | XenServer | Windows 8 (32-bit) | 165 | | XenServer | Windows 8 (64-bit) | 166 | | XenServer | Windows Server 2012 (64-bit) | 167 | | XenServer | Windows Server 8 (64-bit)| 168 | +-+--+-+ 16 rows in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5135) install_path column in snapshot_store_ref table does not have the extension of the file
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harikrishna Patnala resolved CLOUDSTACK-5135. - Resolution: Not A Problem install_path column in snapshot_store_ref table does not have the extension of the file --- Key: CLOUDSTACK-5135 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5135 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Snapshot Affects Versions: 4.3.0 Environment: All 3 hypervisors Reporter: Gaurav Aradhye Assignee: Harikrishna Patnala Priority: Critical Fix For: 4.3.0 login to mysql fire command select * from snapshot_store_ref where store_role='Image' Check the install_path column. This does not have the extension for the file but if you check the same snapshot on the nfs server, the same file will have the extension based on from which hypervisor the snapshot is created. This mismatch creates trouble while checking if the snapshot exists on the nfs by mounting the nfs using the path obtained from the database. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5413) [Automation]: Misc Changes
Santhosh Kumar Edukulla created CLOUDSTACK-5413: --- Summary: [Automation]: Misc Changes Key: CLOUDSTACK-5413 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5413 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation, marvin Reporter: Santhosh Kumar Edukulla Assignee: Santhosh Kumar Edukulla 1. Currently, there was an issue with logging formatter under marvin. Proper format messages are not getting printed. Fixed that. 2. There were few references in existing cfg files for earlier used logger node. Removed them and added new logger node as part of pending clean up. 3. Added TestCase started and the result accordingly to runlog. This will simplify to see the test case starting , sequence of steps and final result including timestamps for test case run. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5403) Shared network - None of PF, LB rules work after router restart, firewall rules dropped from iptables post restart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843066#comment-13843066 ] Jayapal Reddy commented on CLOUDSTACK-5403: --- Hi, From the logs it is observed that the the server it is not started by default. By default on VR the haproxy daemon should run, pid file get create created. Can you please make sure with the hyper router template there is no issues with haproxy daemon start. SSH execution of command /root/loadbalancer.sh -i 10.102.195.178 -f /tmp/10_102_195_178.cfg -a 10.102.196.240:888:, -s 10.102.196.238:8081:0/0:,, has an error status code in return. result output: mv: cannot stat `/var/run/haproxy.pid': No such file or directory cat: /var/run/haproxy.pid.old: No such file or directory kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec] [WARNING] 339/184353 (3747) : config : 'option forwardfor' ignored for proxy '10_102_196_240-888' as it requires HTTP mode. [WARNING] 339/184353 (3747) : config : 'option forceclose' ignored for proxy '10_102_196_240-888' as it requires HTTP mode. [ALERT] 339/184353 (3747) : Starting proxy 10_102_196_240-888: cannot bind socket cat: /var/run/haproxy.pid.old: No such file or directory kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec] mv: cannot stat `/var/run/haproxy.pid.old': No such file or directory 2013-12-06 17:14:17,313 ERROR [c.c.h.h.r.HypervDirectConnectResource] (DirectAgent-398:ctx-fe77f054) LoadBalancerConfigCommand on domain router 10.102.195.178 failed. message: mv: cannot stat `/var/run/haproxy.pid': No such file or directory cat: /var/run/haproxy.pid.old: No such file or directory kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec] [WARNING] 339/184353 (3747) : config : 'option forwardfor' ignored for proxy '10_102_196_240-888' as it requires HTTP mode. [WARNING] 339/184353 (3747) : config : 'option forceclose' ignored for proxy '10_102_196_240-888' as it requires HTTP mode. [ALERT] 339/184353 (3747) : Starting proxy 10_102_196_240-888: cannot bind socket cat: /var/run/haproxy.pid.old: No such file or directory kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec] mv: cannot stat `/var/run/haproxy.pid.old': No such file or directory Shared network - None of PF, LB rules work after router restart, firewall rules dropped from iptables post restart -- Key: CLOUDSTACK-5403 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5403 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.3.0 Environment: Advanced zone, shared network on Hyper-V Reporter: Sowmya Krishnan Assignee: Devdeep Singh Priority: Critical Labels: hyper-V, Fix For: 4.3.0 Attachments: iptables_after_restart.gz, iptables_before_restart.gz, restart_vr.log.gz, restart_vr_agent.log.log None of PF, LB or firewall rules work after router is restarted in shared network, advanced zone Steps: Create a shared network in advanced zone Acquire IP Create PF and corresponding Firewall rule Acquire another IP Create LB and corresponding Firewall rule Ensure all the rules work Restart router Check all rules Result: None of PF or LB rules work after router restart I've tested this only in Hypev-V so far. I'll update the bug in case I am able to test in any other hypervisor as well. The following rules are dropped from iptables FORWARD chain after restart: ACCEPT tcp -- anywhere shareduser1vm1 state RELATED,ESTABLISHED /* 10.102.196.239:888:888 */ ACCEPT tcp -- anywhere shareduser1vm1 tcp dpt:http state NEW /* 10.102.196.239:888:888 */ So also the firewall rules corresponding to the LB rule source ip The rules themselves exist in DB though: mysql select * from firewall_rules; ++--+---++--++--+++---++--+-+---+---+-+--++--+ | id | uuid | ip_address_id | start_port | end_port | state | protocol | purpose| account_id | domain_id | network_id | xid | created | icmp_code | icmp_type | related | type | vpc_id | traffic_type |
[jira] [Comment Edited] (CLOUDSTACK-5403) Shared network - None of PF, LB rules work after router restart, firewall rules dropped from iptables post restart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843066#comment-13843066 ] Jayapal Reddy edited comment on CLOUDSTACK-5403 at 12/9/13 11:21 AM: - Hi, From the logs it is observed that the the server it is not started by default. By default on VR the haproxy daemon should run, pid file get create created. Can you please make sure with the hyper router template there is no issues with haproxy daemon start. logs: SSH execution of command /root/loadbalancer.sh -i 10.102.195.178 -f /tmp/10_102_195_178.cfg -a 10.102.196.240:888:, -s 10.102.196.238:8081:0/0:,, has an error status code in return. result output: mv: cannot stat `/var/run/haproxy.pid': No such file or directory cat: /var/run/haproxy.pid.old: No such file or directory kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec] [WARNING] 339/184353 (3747) : config : 'option forwardfor' ignored for proxy '10_102_196_240-888' as it requires HTTP mode. [WARNING] 339/184353 (3747) : config : 'option forceclose' ignored for proxy '10_102_196_240-888' as it requires HTTP mode. [ALERT] 339/184353 (3747) : Starting proxy 10_102_196_240-888: cannot bind socket cat: /var/run/haproxy.pid.old: No such file or directory kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec] mv: cannot stat `/var/run/haproxy.pid.old': No such file or directory 2013-12-06 17:14:17,313 ERROR [c.c.h.h.r.HypervDirectConnectResource] (DirectAgent-398:ctx-fe77f054) LoadBalancerConfigCommand on domain router 10.102.195.178 failed. message: mv: cannot stat `/var/run/haproxy.pid': No such file or directory cat: /var/run/haproxy.pid.old: No such file or directory kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec] [WARNING] 339/184353 (3747) : config : 'option forwardfor' ignored for proxy '10_102_196_240-888' as it requires HTTP mode. [WARNING] 339/184353 (3747) : config : 'option forceclose' ignored for proxy '10_102_196_240-888' as it requires HTTP mode. [ALERT] 339/184353 (3747) : Starting proxy 10_102_196_240-888: cannot bind socket cat: /var/run/haproxy.pid.old: No such file or directory kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec] mv: cannot stat `/var/run/haproxy.pid.old': No such file or directory was (Author: jayapal): Hi, From the logs it is observed that the the server it is not started by default. By default on VR the haproxy daemon should run, pid file get create created. Can you please make sure with the hyper router template there is no issues with haproxy daemon start. SSH execution of command /root/loadbalancer.sh -i 10.102.195.178 -f /tmp/10_102_195_178.cfg -a 10.102.196.240:888:, -s 10.102.196.238:8081:0/0:,, has an error status code in return. result output: mv: cannot stat `/var/run/haproxy.pid': No such file or directory cat: /var/run/haproxy.pid.old: No such file or directory kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec] [WARNING] 339/184353 (3747) : config : 'option forwardfor' ignored for proxy '10_102_196_240-888' as it requires HTTP mode. [WARNING] 339/184353 (3747) : config : 'option forceclose' ignored for proxy '10_102_196_240-888' as it requires HTTP mode. [ALERT] 339/184353 (3747) : Starting proxy 10_102_196_240-888: cannot bind socket cat: /var/run/haproxy.pid.old: No such file or directory kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec] mv: cannot stat `/var/run/haproxy.pid.old': No such file or directory 2013-12-06 17:14:17,313 ERROR [c.c.h.h.r.HypervDirectConnectResource] (DirectAgent-398:ctx-fe77f054) LoadBalancerConfigCommand on domain router 10.102.195.178 failed. message: mv: cannot stat `/var/run/haproxy.pid': No such file or directory cat: /var/run/haproxy.pid.old: No such file or directory kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec] [WARNING] 339/184353 (3747) : config : 'option forwardfor' ignored for proxy '10_102_196_240-888' as it requires HTTP mode. [WARNING] 339/184353 (3747) : config : 'option forceclose' ignored for proxy '10_102_196_240-888' as it requires HTTP mode. [ALERT] 339/184353 (3747) : Starting proxy 10_102_196_240-888: cannot bind socket cat: /var/run/haproxy.pid.old: No such file or directory kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec] mv: cannot stat `/var/run/haproxy.pid.old': No such file or directory Shared network - None of PF, LB rules work after router restart, firewall rules dropped from iptables post restart -- Key:
[jira] [Created] (CLOUDSTACK-5414) With NFS Image Store migrated to S3 an error is thrown in creation of Virtual Router
Pavan Kumar Bandarupally created CLOUDSTACK-5414: Summary: With NFS Image Store migrated to S3 an error is thrown in creation of Virtual Router Key: CLOUDSTACK-5414 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5414 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.3.0 Environment: Management Server: 4.3 Host: VmWare or Xenserver Reporter: Pavan Kumar Bandarupally Priority: Critical Fix For: 4.3.0 Attachments: management-server.log After NFS store is migrated to S3 store, creation of an instance, after adding the S3 store, throws an error saying systemVM template that is required to create virtual router is not available in the S3 store and is being downloaded to S3 The systemVM template is being downloaded from download.cloud.com/etc… The systemVm template is already on NFS Image Store and NFS Primary Store using which SSVM and CPVM were already created. Repro Steps: 1) Create an advanced zone with an NFS secondary store and enable the zone. 2) Wait till the system VMs (except Virtual Router) SSVM and CPVM are created. 3) Now migrate the NFS secondary store to S3 (using prepareObjectStoreForMigration option). The store will be converted to Staging Store. 4) Add an S3 secondary store 5) Now try to deploy an instance using a downloaded (default CentOS or other) template. 6) An error will be thrown Expected: -- The instance should be deployed successfully, as the Virtual Router can be created using the SystemVm template already on the NFS Staging store. Actual: - An error will be thrown saying that the template required for creation of VR is not yet downloaded. Attached Management Server logs. Exception: === com.cloud.utils.exception.CloudRuntimeException: Template 8 has not been completely downloaded to zone 1 at com.cloud.template.TemplateManagerImpl.getTemplateSize(TemplateManagerImpl.java:1715) 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:616) 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 $Proxy159.getTemplateSize(Unknown Source) at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.allocateTemplatedVolume(VolumeOrchestrator.java:638) at com.cloud.vm.VirtualMachineManagerImpl$1.doInTransactionWithoutResult(VirtualMachineManagerImpl.java:401) at com.cloud.utils.db.TransactionCallbackWithExceptionNoReturn.doInTransaction(TransactionCallbackWithExceptionNoReturn.java:25) at com.cloud.utils.db.TransactionCallbackWithExceptionNoReturn.doInTransaction(TransactionCallbackWithExceptionNoReturn.java:21) at com.cloud.utils.db.Transaction.execute(Transaction.java:37) at com.cloud.vm.VirtualMachineManagerImpl.allocate(VirtualMachineManagerImpl.java:379) at com.cloud.vm.VirtualMachineManagerImpl.allocate(VirtualMachineManagerImpl.java:418) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.deployRouter(VirtualNetworkApplianceManagerImpl.java:1542) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.findOrDeployVirtualRouterInGuestNetwork(VirtualNetworkApplianceManagerImpl.java:1429) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.deployVirtualRouterInGuestNetwork(VirtualNetworkApplianceManagerImpl.java:1842) 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:616) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at
[jira] [Updated] (CLOUDSTACK-5414) With NFS Image Store migrated to S3 an error is thrown in creation of Virtual Router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavan Kumar Bandarupally updated CLOUDSTACK-5414: - Attachment: management-server.log With NFS Image Store migrated to S3 an error is thrown in creation of Virtual Router Key: CLOUDSTACK-5414 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5414 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.3.0 Environment: Management Server: 4.3 Host: VmWare or Xenserver Reporter: Pavan Kumar Bandarupally Priority: Critical Fix For: 4.3.0 Attachments: management-server.log After NFS store is migrated to S3 store, creation of an instance, after adding the S3 store, throws an error saying systemVM template that is required to create virtual router is not available in the S3 store and is being downloaded to S3 The systemVM template is being downloaded from download.cloud.com/etc… The systemVm template is already on NFS Image Store and NFS Primary Store using which SSVM and CPVM were already created. Repro Steps: 1) Create an advanced zone with an NFS secondary store and enable the zone. 2) Wait till the system VMs (except Virtual Router) SSVM and CPVM are created. 3) Now migrate the NFS secondary store to S3 (using prepareObjectStoreForMigration option). The store will be converted to Staging Store. 4) Add an S3 secondary store 5) Now try to deploy an instance using a downloaded (default CentOS or other) template. 6) An error will be thrown Expected: -- The instance should be deployed successfully, as the Virtual Router can be created using the SystemVm template already on the NFS Staging store. Actual: - An error will be thrown saying that the template required for creation of VR is not yet downloaded. Attached Management Server logs. Exception: === com.cloud.utils.exception.CloudRuntimeException: Template 8 has not been completely downloaded to zone 1 at com.cloud.template.TemplateManagerImpl.getTemplateSize(TemplateManagerImpl.java:1715) 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:616) 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 $Proxy159.getTemplateSize(Unknown Source) at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.allocateTemplatedVolume(VolumeOrchestrator.java:638) at com.cloud.vm.VirtualMachineManagerImpl$1.doInTransactionWithoutResult(VirtualMachineManagerImpl.java:401) at com.cloud.utils.db.TransactionCallbackWithExceptionNoReturn.doInTransaction(TransactionCallbackWithExceptionNoReturn.java:25) at com.cloud.utils.db.TransactionCallbackWithExceptionNoReturn.doInTransaction(TransactionCallbackWithExceptionNoReturn.java:21) at com.cloud.utils.db.Transaction.execute(Transaction.java:37) at com.cloud.vm.VirtualMachineManagerImpl.allocate(VirtualMachineManagerImpl.java:379) at com.cloud.vm.VirtualMachineManagerImpl.allocate(VirtualMachineManagerImpl.java:418) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.deployRouter(VirtualNetworkApplianceManagerImpl.java:1542) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.findOrDeployVirtualRouterInGuestNetwork(VirtualNetworkApplianceManagerImpl.java:1429) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.deployVirtualRouterInGuestNetwork(VirtualNetworkApplianceManagerImpl.java:1842) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at
[jira] [Created] (CLOUDSTACK-5415) SMB/cifs path should tell user to start with slash
Donal Lafferty created CLOUDSTACK-5415:
--
Summary: SMB/cifs path should tell user to start with slash
Key: CLOUDSTACK-5415
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5415
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Website
Reporter: Donal Lafferty
Assignee: Devdeep Singh
Priority: Minor
Using client to add secondary storage.
Use the SMB/cifs option.
This asks for server name and path; however, it should tell user that ath must
start with slash ('/').
Why? If you don't lead with '/', the command files with not feedback. You
have to inspect the log file, which is a pain.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5278) Egress Firewall rules clarifications
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayapal Reddy updated CLOUDSTACK-5278: -- Attachment: diff.txt This attached diff file is tested on VR and SRX. Can you use these changes for your palo alto and make changes in palo alto resource layer. Let me know if you see any issues. Thanks, Jayapal Egress Firewall rules clarifications Key: CLOUDSTACK-5278 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5278 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Will Stevens Assignee: Jayapal Reddy Priority: Critical Fix For: 4.3.0 Attachments: diff.txt, diff.txt These issues may also exist in the 4.2 branch, but I am currently testing/working on the 4.3 branch. I believe these bugs were introduced with the change to the Network Service Offering to add the 'Default egress policy' dropdown. https://issues.apache.org/jira/browse/CLOUDSTACK-1578 I am trying to resolve the bugs this change introduced in the Palo Alto plugin. There are two types of Egress rules (from what I can tell). - FirewallRule.FirewallRuleType.System : this appears to be set up by the system on network creation to correspond to the global network default allow/deny egress rule. - FirewallRule.FirewallRuleType.User : any rule that a user creates through the UI will get this type. There are bugs associated with both of the options in the dropdown (allow and deny). Case: 'deny' - When the network is setup, it does not try to create the global deny rule for the network, but it appears to register that it exists. Instead, when the first egress rule is created by a user, the system sees both the 'system' and 'user' rules, so it will create both rules then. Case: both 'allow' and 'deny' - The clean up of the network global 'system' egress rules are never done. So when a network is deleted, it will leave an orphaned egress rule associated with the previous network's cidr. This is bound to cause many issues. - Even worse, it appears that the ID for the network global 'system' egress rule is hardcoded to '0'. Every time I try to spin up a new network it will attempt to create a rule with a '0' ID, but since one already exists with that ID, there is a config collision. In my case (Palo Alto), the second rule with the same ID gets ignored because it checks to see if the rule exists and it gets a 'yes' back because the previous network has an egress rule with that ID already. Let me know if you have additional questions... -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5416) [VMware] Not able to add seventh disk to VM in an upgraded setup
Likitha Shetty created CLOUDSTACK-5416: -- Summary: [VMware] Not able to add seventh disk to VM in an upgraded setup Key: CLOUDSTACK-5416 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5416 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Storage Controller, VMware Affects Versions: 4.2.1 Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.3.0 Setup --- Upgraded to 4.2.1 Management-server log -- 2013-11-25 10:49:18,532 ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-14:job-400 = [ 97adfe9c-225d-4699-a9b8-175ecac2e5c7 ]) Unexpected exception while executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd com.cloud.exception.InvalidParameterValueException: The specified VM already has the maximum number of data disks (6). Please specify another VM. at com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1793) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:122) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) Database entry --- Limit is still set to 6 for all versions of vSphere: mysql select - id,uuid,hypervisor_type,hypervisor_version,max_data_volumes_limit from - hypervisor_capabilities where hypervisor_type = 'VMware'; --- id uuidhypervisor_type hypervisor_version max_data_volumes_limit --- 10 10 VMware 4.0 6 11 11 VMware 4.1 6 12 12 VMware 5.0 6 13 13 VMware 5.1 6 99 VMware default 6 -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-4973) CLONE - Specified keyboard language is not showing as default in consoleView passed during deployVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843082#comment-13843082 ] Sanjay Tripathi commented on CLOUDSTACK-4973: - Fix is available for review at: https://reviews.apache.org/r/16128/ CLONE - Specified keyboard language is not showing as default in consoleView passed during deployVM --- Key: CLOUDSTACK-4973 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4973 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VNC Proxy Affects Versions: 4.1.0, 4.2.0 Reporter: Sanjay Tripathi Assignee: Sanjay Tripathi Priority: Critical Fix For: 4.3.0 While deploying a VM, user passes the keyboard parameter to specify the default language for that VM but in the consoleView, the default language selected is en-us irrespective of the default language of the VM. To change the language, user has to navigate through the dropdown menu provided in consoleView. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-4973) CLONE - Specified keyboard language is not showing as default in consoleView passed during deployVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi updated CLOUDSTACK-4973: Status: Ready To Review (was: In Progress) CLONE - Specified keyboard language is not showing as default in consoleView passed during deployVM --- Key: CLOUDSTACK-4973 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4973 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: VNC Proxy Affects Versions: 4.1.0, 4.2.0 Reporter: Sanjay Tripathi Assignee: Sanjay Tripathi Priority: Critical Fix For: 4.3.0 While deploying a VM, user passes the keyboard parameter to specify the default language for that VM but in the consoleView, the default language selected is en-us irrespective of the default language of the VM. To change the language, user has to navigate through the dropdown menu provided in consoleView. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5416) [VMware] Not able to add seventh disk to VM in an upgraded setup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843085#comment-13843085 ] ASF subversion and git services commented on CLOUDSTACK-5416: - Commit 13faa4dd924794b928dd48ea4502e901be538bcb in branch refs/heads/4.3 from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=13faa4d ] CLOUDSTACK-5416. [VMware] Not able to add seventh disk to VM in an upgraded setup. [VMware] Not able to add seventh disk to VM in an upgraded setup Key: CLOUDSTACK-5416 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5416 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller, VMware Affects Versions: 4.2.1 Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.3.0 Setup --- Upgraded to 4.2.1 Management-server log -- 2013-11-25 10:49:18,532 ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-14:job-400 = [ 97adfe9c-225d-4699-a9b8-175ecac2e5c7 ]) Unexpected exception while executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd com.cloud.exception.InvalidParameterValueException: The specified VM already has the maximum number of data disks (6). Please specify another VM. at com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1793) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:122) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) Database entry --- Limit is still set to 6 for all versions of vSphere: mysql select - id,uuid,hypervisor_type,hypervisor_version,max_data_volumes_limit from - hypervisor_capabilities where hypervisor_type = 'VMware'; --- id uuidhypervisor_type hypervisor_version max_data_volumes_limit --- 10 10 VMware 4.0 6 11 11 VMware 4.1 6 12 12 VMware 5.0 6 13 13 VMware 5.1 6 9 9 VMware default 6 -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5416) [VMware] Not able to add seventh disk to VM in an upgraded setup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843087#comment-13843087 ] ASF subversion and git services commented on CLOUDSTACK-5416: - Commit eaa278d1196b233dfd8970ae8a8f07b957e066fb in branch refs/heads/master from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=eaa278d ] CLOUDSTACK-5416. [VMware] Not able to add seventh disk to VM in an upgraded setup. [VMware] Not able to add seventh disk to VM in an upgraded setup Key: CLOUDSTACK-5416 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5416 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller, VMware Affects Versions: 4.2.1 Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.3.0 Setup --- Upgraded to 4.2.1 Management-server log -- 2013-11-25 10:49:18,532 ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-14:job-400 = [ 97adfe9c-225d-4699-a9b8-175ecac2e5c7 ]) Unexpected exception while executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd com.cloud.exception.InvalidParameterValueException: The specified VM already has the maximum number of data disks (6). Please specify another VM. at com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1793) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:122) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) Database entry --- Limit is still set to 6 for all versions of vSphere: mysql select - id,uuid,hypervisor_type,hypervisor_version,max_data_volumes_limit from - hypervisor_capabilities where hypervisor_type = 'VMware'; --- id uuidhypervisor_type hypervisor_version max_data_volumes_limit --- 10 10 VMware 4.0 6 11 11 VMware 4.1 6 12 12 VMware 5.0 6 13 13 VMware 5.1 6 9 9 VMware default 6 -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5416) [VMware] Not able to add seventh disk to VM in an upgraded setup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Likitha Shetty resolved CLOUDSTACK-5416. Resolution: Fixed [VMware] Not able to add seventh disk to VM in an upgraded setup Key: CLOUDSTACK-5416 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5416 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller, VMware Affects Versions: 4.2.1 Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.3.0 Setup --- Upgraded to 4.2.1 Management-server log -- 2013-11-25 10:49:18,532 ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-14:job-400 = [ 97adfe9c-225d-4699-a9b8-175ecac2e5c7 ]) Unexpected exception while executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd com.cloud.exception.InvalidParameterValueException: The specified VM already has the maximum number of data disks (6). Please specify another VM. at com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1793) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:122) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) Database entry --- Limit is still set to 6 for all versions of vSphere: mysql select - id,uuid,hypervisor_type,hypervisor_version,max_data_volumes_limit from - hypervisor_capabilities where hypervisor_type = 'VMware'; --- id uuidhypervisor_type hypervisor_version max_data_volumes_limit --- 10 10 VMware 4.0 6 11 11 VMware 4.1 6 12 12 VMware 5.0 6 13 13 VMware 5.1 6 9 9 VMware default 6 -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5417) On network restart for external devices egress rules configured with old CIDR
Jayapal Reddy created CLOUDSTACK-5417: - Summary: On network restart for external devices egress rules configured with old CIDR Key: CLOUDSTACK-5417 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5417 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Reporter: Jayapal Reddy Fix For: 4.3.0 1. configure egress rule on SRX guest network without CIDR. firewall rules cidr table stores the guest network CIDR for the egress firewall rule 2. Restart the network. On network restart guest network CIDR will be changed. 3. Egress rules get configured with old CIDR. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5418) createtmplt.sh@207 complains about isCifs parameter
Donal Lafferty created CLOUDSTACK-5418: -- Summary: createtmplt.sh@207 complains about isCifs parameter Key: CLOUDSTACK-5418 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5418 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Donal Lafferty Assignee: Rajesh Battala use createtmplt.sh to preseed the system VM template for Hyper-V. When command runs, it complains about the isCifs parameter E.g. # Pre-seed the system VM template, because it is not enough to insert it into the database ./client/target/generated-webapp/WEB-INF/classes/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/qc_secondary -u http://10.70.176.4/pub/systemvmtemplate-hyper-v-20131205.vhd -h hyperv -F -o localhost ... runs, but generates following text: File ./client/target/generated-webapp/WEB-INF/classes/scripts/storage/secondary/999d9e4b-27b8-472c-a2b2-220e719c39f0.vhd does not appear to be compressed ./client/target/generated-webapp/WEB-INF/classes/scripts/storage/secondary/createtmplt.sh: line 207: [: isCifs: integer expression expected -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5418) createtmplt.sh@207 complains about isCifs parameter
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Lafferty updated CLOUDSTACK-5418: --- Assignee: (was: Rajesh Battala) createtmplt.sh@207 complains about isCifs parameter --- Key: CLOUDSTACK-5418 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5418 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Donal Lafferty use createtmplt.sh to preseed the system VM template for Hyper-V. When command runs, it complains about the isCifs parameter E.g. # Pre-seed the system VM template, because it is not enough to insert it into the database ./client/target/generated-webapp/WEB-INF/classes/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/qc_secondary -u http://10.70.176.4/pub/systemvmtemplate-hyper-v-20131205.vhd -h hyperv -F -o localhost ... runs, but generates following text: File ./client/target/generated-webapp/WEB-INF/classes/scripts/storage/secondary/999d9e4b-27b8-472c-a2b2-220e719c39f0.vhd does not appear to be compressed ./client/target/generated-webapp/WEB-INF/classes/scripts/storage/secondary/createtmplt.sh: line 207: [: isCifs: integer expression expected -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-3968) [VMWAREDVS] Distributed Portgroups are not deleted when guest networks are removed/User Account of this network is removed from cloudstack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-3968: - Fix Version/s: (was: 4.3.0) 4.4.0 [VMWAREDVS] Distributed Portgroups are not deleted when guest networks are removed/User Account of this network is removed from cloudstack -- Key: CLOUDSTACK-3968 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3968 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Reporter: Sailaja Mada Assignee: Sateesh Chodapuneedi Priority: Critical Fix For: 4.4.0 Attachments: dvswitchsnap.png Setup: VMWARE with DVSwitch 1. Configure Adv Zone with DVSwitch enabled VMWARE cluster 2. Create an account and deploy VM using default offering guest network. 3. Delete this account. With this all the resources of this account gets removed from cloudstack Observation: But from vCenter dv Switch, the distributed port groups configured for this account guest networks will not get removed. Expected results: All the configurations created by cloudstack should get cleaned up as part of smooth removal. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5408) [Automation] Failed to deploy vm in vmware environment with error due to java.io.IOException: Cannot run program mount: java.io.IOException: error=12, Cannot allo
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sateesh Chodapuneedi updated CLOUDSTACK-5408:
-
Priority: Critical (was: Blocker)
[Automation] Failed to deploy vm in vmware environment with error due to
java.io.IOException: Cannot run program mount: java.io.IOException:
error=12, Cannot allocate memory
--
Key: CLOUDSTACK-5408
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5408
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: VMware
Affects Versions: 4.3.0
Environment: vmware 5.0 update 3
64 bit template
Reporter: Rayees Namathponnan
Assignee: Sateesh Chodapuneedi
Priority: Critical
Fix For: 4.3.0
Attachments: CLOUDSTACK-5408.rar
Steps to reproduce
Create advanced zone in vmware
use 64 bit template
deploy VM
Result
SSVM are crated
Routers are created
VM deployment failed with below error
yStorageResource.mountUri(NfsSecondaryStorageResource.java:2293)\n\tat
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.getRootDir(NfsSecondaryStorageResource.java:1934)\n\tat
com.cloud.storage.resource.VmwareSecondaryStorageResourceHandler.getMountPoint(VmwareSecondaryStorageResourceHandler.java:311)\n\tat
com.cloud.storage.resource.VmwareStorageProcessor.copyTemplateFromSecondaryToPrimary(VmwareStorageProcessor.java:131)\n\tat
com.cloud.storage.resource.VmwareStorageProcessor.copyTemplateToPrimaryStorage(VmwareStorageProcessor.java:221)\n\tat
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:75)\n\tat
com.cloud.storage.resource.VmwareStorageSubsystemCommandHandler.execute(VmwareStorageSubsystemCommandHandler.java:155)\n\tat
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:50)\n\tat
com.cloud.storage.resource.VmwareSecondaryStorageResourceHandler.executeRequest(VmwareSecondaryStorageResourceHandler.java:101)\n\tat
com.cloud.storage.resource.PremiumSecondaryStorageResource.executeRequest(PremiumSecondaryStorageResource.java:56)\n\tat
com.cloud.agent.Agent.processRequest(Agent.java:498)\n\tat
com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:806)\n\tat
com.cloud.utils.nio.Task.run(Task.java:83)\n\tat
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)\n\tat
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n\tat
java.lang.Thread.run(Thread.java:679)\nCaused by: java.io.IOException:
java.io.IOException: error=12, Cannot allocate memory\n\tat
java.lang.UNIXProcess.init(UNIXProcess.java:164)\n\tat
java.lang.ProcessImpl.start(ProcessImpl.java:81)\n\tat
java.lang.ProcessBuilder.start(ProcessBuilder.java:470)\n\t... 20
more\n\n,wait:0}}] }
2013-12-07 14:07:59,776 DEBUG [c.c.a.t.Request] (Job-Executor-23:ctx-f22d6e84
ctx-b6c94672) Seq 5-137756744: Received: { Ans: , MgmtId: 90928106758026,
via: 5, Ver: v1, Flags: 10, { CopyCmdAnswer } }
2013-12-07 14:07:59,791 INFO [o.a.c.s.v.VolumeServiceImpl]
(Job-Executor-23:ctx-f22d6e84 ctx-b6c94672) releasing lock for
VMTemplateStoragePool 9
2013-12-07 14:07:59,791 WARN [c.c.u.d.Merovingian2]
(Job-Executor-23:ctx-f22d6e84 ctx-b6c94672) Was unable to find lock for the
key template_spool_ref9 and thread id 1402045270
2013-12-07 14:07:59,791 DEBUG [o.a.c.e.o.VolumeOrchestrator]
(Job-Executor-23:ctx-f22d6e84 ctx-b6c94672) Unable to create
Vol[8|vm=8|ROOT]:Unable to copy template to primary storage due to
exception:Exception: com.cloud.utils.exception.CloudRuntimeException
Message: GetRootDir for
nfs://10.223.240.164:/home/common/automation/SC-CLOUD-QA03/secondary1 failed
due to com.cloud.utils.exception.CloudRuntimeException: Unable to mount
10.223.240.164:/home/common/automation/SC-CLOUD-QA03/secondary1 at
/mnt/SecStorage/c6ec0966-00ab-3817-8a96-e8f4c3e03269 due to
java.io.IOException: Cannot run program mount: java.io.IOException:
error=12, Cannot allocate memory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:488)
at com.cloud.utils.script.Script.execute(Script.java:177)
at com.cloud.utils.script.Script.execute(Script.java:155)
at
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.attemptMount(NfsSecondaryStorageResource.java:2374)
at
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.mount(NfsSecondaryStorageResource.java:2331)
at
[jira] [Commented] (CLOUDSTACK-5408) [Automation] Failed to deploy vm in vmware environment with error due to java.io.IOException: Cannot run program mount: java.io.IOException: error=12, Cannot al
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843111#comment-13843111
]
Sateesh Chodapuneedi commented on CLOUDSTACK-5408:
--
SSVM based on 64bit system template needed more memory. Need to analyze more to
see which processes are adding to the higher memory foot print here.
One work around for this is as follows,
1) Create a system offering with same attributes as that of Secondary storage
system offering except that memory is 512MB or more instead of 256MB.
2) Enable the global configuration setting enable.dynamic.scale.vm setting it
to true.
3) Restart management server
4) Scale up SSVM to the system offering created in step-1
5) Reboot SSVM OR follow step-6
6) When scaling memory or CPU for a Linux VM on VMware, you might need to run
scripts in addition to the other steps mentioned above. For more information,
see following link in the VMware Knowledge Base. Link -
http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=1012764
Reducing severity to critical from blocker as work around exists.
[Automation] Failed to deploy vm in vmware environment with error due to
java.io.IOException: Cannot run program mount: java.io.IOException:
error=12, Cannot allocate memory
--
Key: CLOUDSTACK-5408
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5408
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: VMware
Affects Versions: 4.3.0
Environment: vmware 5.0 update 3
64 bit template
Reporter: Rayees Namathponnan
Assignee: Sateesh Chodapuneedi
Priority: Blocker
Fix For: 4.3.0
Attachments: CLOUDSTACK-5408.rar
Steps to reproduce
Create advanced zone in vmware
use 64 bit template
deploy VM
Result
SSVM are crated
Routers are created
VM deployment failed with below error
yStorageResource.mountUri(NfsSecondaryStorageResource.java:2293)\n\tat
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.getRootDir(NfsSecondaryStorageResource.java:1934)\n\tat
com.cloud.storage.resource.VmwareSecondaryStorageResourceHandler.getMountPoint(VmwareSecondaryStorageResourceHandler.java:311)\n\tat
com.cloud.storage.resource.VmwareStorageProcessor.copyTemplateFromSecondaryToPrimary(VmwareStorageProcessor.java:131)\n\tat
com.cloud.storage.resource.VmwareStorageProcessor.copyTemplateToPrimaryStorage(VmwareStorageProcessor.java:221)\n\tat
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:75)\n\tat
com.cloud.storage.resource.VmwareStorageSubsystemCommandHandler.execute(VmwareStorageSubsystemCommandHandler.java:155)\n\tat
com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:50)\n\tat
com.cloud.storage.resource.VmwareSecondaryStorageResourceHandler.executeRequest(VmwareSecondaryStorageResourceHandler.java:101)\n\tat
com.cloud.storage.resource.PremiumSecondaryStorageResource.executeRequest(PremiumSecondaryStorageResource.java:56)\n\tat
com.cloud.agent.Agent.processRequest(Agent.java:498)\n\tat
com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:806)\n\tat
com.cloud.utils.nio.Task.run(Task.java:83)\n\tat
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)\n\tat
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n\tat
java.lang.Thread.run(Thread.java:679)\nCaused by: java.io.IOException:
java.io.IOException: error=12, Cannot allocate memory\n\tat
java.lang.UNIXProcess.init(UNIXProcess.java:164)\n\tat
java.lang.ProcessImpl.start(ProcessImpl.java:81)\n\tat
java.lang.ProcessBuilder.start(ProcessBuilder.java:470)\n\t... 20
more\n\n,wait:0}}] }
2013-12-07 14:07:59,776 DEBUG [c.c.a.t.Request] (Job-Executor-23:ctx-f22d6e84
ctx-b6c94672) Seq 5-137756744: Received: { Ans: , MgmtId: 90928106758026,
via: 5, Ver: v1, Flags: 10, { CopyCmdAnswer } }
2013-12-07 14:07:59,791 INFO [o.a.c.s.v.VolumeServiceImpl]
(Job-Executor-23:ctx-f22d6e84 ctx-b6c94672) releasing lock for
VMTemplateStoragePool 9
2013-12-07 14:07:59,791 WARN [c.c.u.d.Merovingian2]
(Job-Executor-23:ctx-f22d6e84 ctx-b6c94672) Was unable to find lock for the
key template_spool_ref9 and thread id 1402045270
2013-12-07 14:07:59,791 DEBUG [o.a.c.e.o.VolumeOrchestrator]
(Job-Executor-23:ctx-f22d6e84 ctx-b6c94672) Unable to create
Vol[8|vm=8|ROOT]:Unable to copy template to primary storage due to
[jira] [Created] (CLOUDSTACK-5419) missing parameters in configuration table and to clean unused parameters
Harikrishna Patnala created CLOUDSTACK-5419: --- Summary: missing parameters in configuration table and to clean unused parameters Key: CLOUDSTACK-5419 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5419 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Harikrishna Patnala Assignee: Harikrishna Patnala Fix For: 4.3.0, 4.4.0 Following parameters are unused which were introduced in 3.0.6. xen.update.url, update.check.interval, baremetal_dhcp_devices, host.updates.enable Following parameters are missing upon upgrade from 3.0.6 to 4.3 vmsnapshot.create.wait, vmsnapshot.max -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5419) missing parameters in configuration table and to remove unused parameters
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harikrishna Patnala updated CLOUDSTACK-5419: Summary: missing parameters in configuration table and to remove unused parameters (was: missing parameters in configuration table and to clean unused parameters) missing parameters in configuration table and to remove unused parameters - Key: CLOUDSTACK-5419 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5419 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Harikrishna Patnala Assignee: Harikrishna Patnala Fix For: 4.3.0, 4.4.0 Following parameters are unused which were introduced in 3.0.6. xen.update.url, update.check.interval, baremetal_dhcp_devices, host.updates.enable Following parameters are missing upon upgrade from 3.0.6 to 4.3 vmsnapshot.create.wait, vmsnapshot.max -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5419) missing parameters in configuration table and to remove unused parameters
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harikrishna Patnala updated CLOUDSTACK-5419: Status: Ready To Review (was: In Progress) missing parameters in configuration table and to remove unused parameters - Key: CLOUDSTACK-5419 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5419 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Harikrishna Patnala Assignee: Harikrishna Patnala Fix For: 4.3.0, 4.4.0 Following parameters are unused which were introduced in 3.0.6. xen.update.url, update.check.interval, baremetal_dhcp_devices, host.updates.enable Following parameters are missing upon upgrade from 3.0.6 to 4.3 vmsnapshot.create.wait, vmsnapshot.max -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5420) Hyper-V host does not transition to maintenance mode
Donal Lafferty created CLOUDSTACK-5420:
--
Summary: Hyper-V host does not transition to maintenance mode
Key: CLOUDSTACK-5420
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5420
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Hypervisor Controller
Affects Versions: 4.3.0
Reporter: Donal Lafferty
I'm trying to remove a zone, because the networking API calls did not work
properly.
The first step to removing the Hyper-V cluster is to remove its hosts. This
requires they be put into maintenance mode. However, the transition to
maintenance mode never completes.
Can't see any exceptions in the vmops.log file, and the MaintainCommand on the
agent does not complain. E.g.
2013-12-09 05:00:54,200 [25] INFO HypervResource.HypervResourceController
[3fba50e8-fcc5-4e80-88b8-105521336c9e] - com.cloud.agent.api.MaintainCommand{
contextMap: {},
wait: 0
}
2013-12-09 05:00:54,201 [25] INFO HypervResource.HypervResourceController
[3fba50e8-fcc5-4e80-88b8-105521336c9e] - {
com.cloud.agent.api.MaintainAnswer: {
result: true,
details: success - NOP for MaintainCommand,
_reconnect: false,
contextMap: {}
}
}
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5364) Egress firewall rule test cases failed with error More than one isolated network is present for the account in the zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843153#comment-13843153 ] ASF subversion and git services commented on CLOUDSTACK-5364: - Commit 71aa2c0881760b8df75b6b8110833fb850c04317 in branch refs/heads/master from [~gpshilamkar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=71aa2c0 ] CLOUDSTACK-5364: Fail the test incase cleanup is not successful Egress firewall rule test cases failed with error More than one isolated network is present for the account in the zone - Key: CLOUDSTACK-5364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5364 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: Observed on KVM advanced zone Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Labels: automation Fix For: 4.3.0 The test cases failed with the error because the network from earlier test cases did not get deleted. Following test cases failed: test_11_egress_fr11 test_11_1_egress_fr11 -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5364) Egress firewall rule test cases failed with error More than one isolated network is present for the account in the zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843155#comment-13843155 ] ASF subversion and git services commented on CLOUDSTACK-5364: - Commit 0533001feb60bf03ef3839774b6ce515f3694857 in branch refs/heads/4.3 from [~gpshilamkar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0533001 ] CLOUDSTACK-5364: Fail the test incase cleanup is not successful Egress firewall rule test cases failed with error More than one isolated network is present for the account in the zone - Key: CLOUDSTACK-5364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5364 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: Observed on KVM advanced zone Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Labels: automation Fix For: 4.3.0 The test cases failed with the error because the network from earlier test cases did not get deleted. Following test cases failed: test_11_egress_fr11 test_11_1_egress_fr11 -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5364) Egress firewall rule test cases failed with error More than one isolated network is present for the account in the zone
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843160#comment-13843160 ] ASF subversion and git services commented on CLOUDSTACK-5364: - Commit 66b7b7e25c8cbc73b5c33ffc87303045913b491b in branch refs/heads/4.2 from [~gpshilamkar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=66b7b7e ] CLOUDSTACK-5364: Fail the test incase cleanup is not successful Egress firewall rule test cases failed with error More than one isolated network is present for the account in the zone - Key: CLOUDSTACK-5364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5364 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: Observed on KVM advanced zone Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Labels: automation Fix For: 4.3.0 The test cases failed with the error because the network from earlier test cases did not get deleted. Following test cases failed: test_11_egress_fr11 test_11_1_egress_fr11 -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5421) VLAN untagged - Advanced networking
Gaspare Silvestri created CLOUDSTACK-5421: - Summary: VLAN untagged - Advanced networking Key: CLOUDSTACK-5421 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5421 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Environment: CloudStack 4.2 + VMware vSphere 5.1 Reporter: Gaspare Silvestri We are currently not able to add the untagged option, by using the UI, when specifying the VLAN_ID field, during the advanced networking configuration. Cloudstack Network Add guest network VLAN ID = untagged -- Operation not permitted. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5269) [Automation] test_shared_networks failed to import get_free_vlan and failed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843176#comment-13843176 ] ASF subversion and git services commented on CLOUDSTACK-5269: - Commit 5cbda8b64a127090a255fdfdf188b84e5ed53c74 in branch refs/heads/master from [~santhoshe] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5cbda8b ] CLOUDSTACK-5269: Fix nose failures. [Automation] test_shared_networks failed to import get_free_vlan and failed -- Key: CLOUDSTACK-5269 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5269 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: Basic zone Automation Reporter: Rayees Namathponnan Assignee: Santhosh Kumar Edukulla Fix For: 4.3.0 Steps to reproduce execute test_shared_networks.py in basic zone; test case failed to execute with below error + nosetests --with-xunit --xunit-file=test_shared_networks.xml --with-marvin --marvin-config=/hudson/scripts/bvt_basic_sg_kvm.cfg /Repo_30X/ipcl/cloudstack/test//integration/component/test_shared_networks.py --load -a tags=sg -a tags=basic ERROR == ERROR: Failure: ImportError (cannot import name get_free_vlan) -- Traceback (most recent call last): File /usr/local/lib/python2.7/site-packages/nose/case.py, line 132, in run self.beforeTest(result) File /usr/local/lib/python2.7/site-packages/nose/case.py, line 74, in beforeTest beforeTest(self.test) File /usr/local/lib/python2.7/site-packages/nose/proxy.py, line 117, in beforeTest self.plugins.beforeTest(self.test) File /usr/local/lib/python2.7/site-packages/nose/plugins/manager.py, line 99, in __call__ return self.call(*arg, **kw) File /usr/local/lib/python2.7/site-packages/nose/plugins/manager.py, line 167, in simple result = meth(*arg, **kw) File /usr/local/lib/python2.7/site-packages/marvin/marvinPlugin.py, line 130, in beforeTest self.testclient.identifier = '-'.join([self.identifier, self.testName]) TypeError: sequence item 0: expected string, NoneType found -- Ran 0 tests in 0.023s FAILED (errors=1) -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5269) [Automation] test_shared_networks failed to import get_free_vlan and failed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843178#comment-13843178 ] ASF subversion and git services commented on CLOUDSTACK-5269: - Commit 6b5402bbff9fc6aedd27033316b8ad988a21dd60 in branch refs/heads/4.3 from [~santhoshe] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6b5402b ] CLOUDSTACK-5269: Fix nose failures. [Automation] test_shared_networks failed to import get_free_vlan and failed -- Key: CLOUDSTACK-5269 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5269 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: Basic zone Automation Reporter: Rayees Namathponnan Assignee: Santhosh Kumar Edukulla Fix For: 4.3.0 Steps to reproduce execute test_shared_networks.py in basic zone; test case failed to execute with below error + nosetests --with-xunit --xunit-file=test_shared_networks.xml --with-marvin --marvin-config=/hudson/scripts/bvt_basic_sg_kvm.cfg /Repo_30X/ipcl/cloudstack/test//integration/component/test_shared_networks.py --load -a tags=sg -a tags=basic ERROR == ERROR: Failure: ImportError (cannot import name get_free_vlan) -- Traceback (most recent call last): File /usr/local/lib/python2.7/site-packages/nose/case.py, line 132, in run self.beforeTest(result) File /usr/local/lib/python2.7/site-packages/nose/case.py, line 74, in beforeTest beforeTest(self.test) File /usr/local/lib/python2.7/site-packages/nose/proxy.py, line 117, in beforeTest self.plugins.beforeTest(self.test) File /usr/local/lib/python2.7/site-packages/nose/plugins/manager.py, line 99, in __call__ return self.call(*arg, **kw) File /usr/local/lib/python2.7/site-packages/nose/plugins/manager.py, line 167, in simple result = meth(*arg, **kw) File /usr/local/lib/python2.7/site-packages/marvin/marvinPlugin.py, line 130, in beforeTest self.testclient.identifier = '-'.join([self.identifier, self.testName]) TypeError: sequence item 0: expected string, NoneType found -- Ran 0 tests in 0.023s FAILED (errors=1) -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5269) [Automation] test_shared_networks failed to import get_free_vlan and failed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843179#comment-13843179 ] ASF subversion and git services commented on CLOUDSTACK-5269: - Commit 2597dad20af4620ac9338f24f1f9a262e8295dac in branch refs/heads/4.2 from [~santhoshe] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2597dad ] CLOUDSTACK-5269: Fix nose failures. [Automation] test_shared_networks failed to import get_free_vlan and failed -- Key: CLOUDSTACK-5269 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5269 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Environment: Basic zone Automation Reporter: Rayees Namathponnan Assignee: Santhosh Kumar Edukulla Fix For: 4.3.0 Steps to reproduce execute test_shared_networks.py in basic zone; test case failed to execute with below error + nosetests --with-xunit --xunit-file=test_shared_networks.xml --with-marvin --marvin-config=/hudson/scripts/bvt_basic_sg_kvm.cfg /Repo_30X/ipcl/cloudstack/test//integration/component/test_shared_networks.py --load -a tags=sg -a tags=basic ERROR == ERROR: Failure: ImportError (cannot import name get_free_vlan) -- Traceback (most recent call last): File /usr/local/lib/python2.7/site-packages/nose/case.py, line 132, in run self.beforeTest(result) File /usr/local/lib/python2.7/site-packages/nose/case.py, line 74, in beforeTest beforeTest(self.test) File /usr/local/lib/python2.7/site-packages/nose/proxy.py, line 117, in beforeTest self.plugins.beforeTest(self.test) File /usr/local/lib/python2.7/site-packages/nose/plugins/manager.py, line 99, in __call__ return self.call(*arg, **kw) File /usr/local/lib/python2.7/site-packages/nose/plugins/manager.py, line 167, in simple result = meth(*arg, **kw) File /usr/local/lib/python2.7/site-packages/marvin/marvinPlugin.py, line 130, in beforeTest self.testclient.identifier = '-'.join([self.identifier, self.testName]) TypeError: sequence item 0: expected string, NoneType found -- Ran 0 tests in 0.023s FAILED (errors=1) -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5413) [Automation]: Misc Changes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843184#comment-13843184 ] ASF subversion and git services commented on CLOUDSTACK-5413: - Commit 391395f14017b3524c16d6fa6b287e212bc2cdcd in branch refs/heads/4.3 from [~santhoshe] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=391395f ] CLOUDSTACK-5413: Fixed bug CLOUDSTACK-5413 [Automation]: Misc Changes -- Key: CLOUDSTACK-5413 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5413 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, marvin Reporter: Santhosh Kumar Edukulla Assignee: Santhosh Kumar Edukulla 1. Currently, there was an issue with logging formatter under marvin. Proper format messages are not getting printed. Fixed that. 2. There were few references in existing cfg files for earlier used logger node. Removed them and added new logger node as part of pending clean up. 3. Added TC information started, flow and the result accordingly to runlog. This will simplify to see the test case starting , sequence of steps and final result including timestamps for test case run while debugging. 4. Added few changes to dump the exception throwing tc's to the explicit exception file. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5413) [Automation]: Misc Changes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843187#comment-13843187 ] ASF subversion and git services commented on CLOUDSTACK-5413: - Commit 275682d31ceecf6dcabf8448ca9fcb68cf54cde3 in branch refs/heads/4.2 from [~santhoshe] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=275682d ] CLOUDSTACK-5413: Fixed bug CLOUDSTACK-5413 [Automation]: Misc Changes -- Key: CLOUDSTACK-5413 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5413 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, marvin Reporter: Santhosh Kumar Edukulla Assignee: Santhosh Kumar Edukulla 1. Currently, there was an issue with logging formatter under marvin. Proper format messages are not getting printed. Fixed that. 2. There were few references in existing cfg files for earlier used logger node. Removed them and added new logger node as part of pending clean up. 3. Added TC information started, flow and the result accordingly to runlog. This will simplify to see the test case starting , sequence of steps and final result including timestamps for test case run while debugging. 4. Added few changes to dump the exception throwing tc's to the explicit exception file. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5413) [Automation]: Misc Changes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843183#comment-13843183 ] ASF subversion and git services commented on CLOUDSTACK-5413: - Commit 391395f14017b3524c16d6fa6b287e212bc2cdcd in branch refs/heads/4.3 from [~santhoshe] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=391395f ] CLOUDSTACK-5413: Fixed bug CLOUDSTACK-5413 [Automation]: Misc Changes -- Key: CLOUDSTACK-5413 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5413 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, marvin Reporter: Santhosh Kumar Edukulla Assignee: Santhosh Kumar Edukulla 1. Currently, there was an issue with logging formatter under marvin. Proper format messages are not getting printed. Fixed that. 2. There were few references in existing cfg files for earlier used logger node. Removed them and added new logger node as part of pending clean up. 3. Added TC information started, flow and the result accordingly to runlog. This will simplify to see the test case starting , sequence of steps and final result including timestamps for test case run while debugging. 4. Added few changes to dump the exception throwing tc's to the explicit exception file. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5413) [Automation]: Misc Changes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843185#comment-13843185 ] ASF subversion and git services commented on CLOUDSTACK-5413: - Commit 6b70a6db94c5c2459acd8946c7ff0600ccb3b55d in branch refs/heads/master from [~santhoshe] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6b70a6d ] CLOUDSTACK-5413: Fixed bug CLOUDSTACK-5413 [Automation]: Misc Changes -- Key: CLOUDSTACK-5413 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5413 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, marvin Reporter: Santhosh Kumar Edukulla Assignee: Santhosh Kumar Edukulla 1. Currently, there was an issue with logging formatter under marvin. Proper format messages are not getting printed. Fixed that. 2. There were few references in existing cfg files for earlier used logger node. Removed them and added new logger node as part of pending clean up. 3. Added TC information started, flow and the result accordingly to runlog. This will simplify to see the test case starting , sequence of steps and final result including timestamps for test case run while debugging. 4. Added few changes to dump the exception throwing tc's to the explicit exception file. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5413) [Automation]: Misc Changes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843188#comment-13843188 ] ASF subversion and git services commented on CLOUDSTACK-5413: - Commit 275682d31ceecf6dcabf8448ca9fcb68cf54cde3 in branch refs/heads/4.2 from [~santhoshe] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=275682d ] CLOUDSTACK-5413: Fixed bug CLOUDSTACK-5413 [Automation]: Misc Changes -- Key: CLOUDSTACK-5413 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5413 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, marvin Reporter: Santhosh Kumar Edukulla Assignee: Santhosh Kumar Edukulla 1. Currently, there was an issue with logging formatter under marvin. Proper format messages are not getting printed. Fixed that. 2. There were few references in existing cfg files for earlier used logger node. Removed them and added new logger node as part of pending clean up. 3. Added TC information started, flow and the result accordingly to runlog. This will simplify to see the test case starting , sequence of steps and final result including timestamps for test case run while debugging. 4. Added few changes to dump the exception throwing tc's to the explicit exception file. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5413) [Automation]: Misc Changes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843186#comment-13843186 ] ASF subversion and git services commented on CLOUDSTACK-5413: - Commit 6b70a6db94c5c2459acd8946c7ff0600ccb3b55d in branch refs/heads/master from [~santhoshe] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6b70a6d ] CLOUDSTACK-5413: Fixed bug CLOUDSTACK-5413 [Automation]: Misc Changes -- Key: CLOUDSTACK-5413 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5413 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, marvin Reporter: Santhosh Kumar Edukulla Assignee: Santhosh Kumar Edukulla 1. Currently, there was an issue with logging formatter under marvin. Proper format messages are not getting printed. Fixed that. 2. There were few references in existing cfg files for earlier used logger node. Removed them and added new logger node as part of pending clean up. 3. Added TC information started, flow and the result accordingly to runlog. This will simplify to see the test case starting , sequence of steps and final result including timestamps for test case run while debugging. 4. Added few changes to dump the exception throwing tc's to the explicit exception file. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5079) listConfigurations for cluster is resulting in NPE
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843229#comment-13843229 ] Yichi Lu commented on CLOUDSTACK-5079: -- Harikrishna: Should I just discard what I did? Please advise (I am quite new). Yichi On Tue, Nov 26, 2013 at 12:34 AM, Harikrishna Patnala (JIRA) listConfigurations for cluster is resulting in NPE -- Key: CLOUDSTACK-5079 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5079 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Srikanteswararao Talluri Assignee: Harikrishna Patnala Priority: Critical Fix For: 4.3.0 API issued: http://ms:8080/client/api?command=listConfigurationsclusterid=e3ab8dc1-f8df-4a4f-b42b-51867e36ab76response=jsonsessionkey=8CRucersMGM2I7SCzeT9nYHls34%3Dpage=1pageSize=20listAll=true_=1383845615692 ===START=== 10.101.255.73 -- GET command=listConfigurationsclusterid=e3ab8dc1-f8df-4a4f-b42b-51867e36ab76response=jsonsessionkey=8CRucersMGM2I7SCzeT9nYHls34%3Dpage=1pageSize=20listAll=true_=1383845615692 2013-11-08 04:24:41,742 ERROR [c.c.a.ApiServer] (catalina-exec-19:ctx-2380ad6b ctx-5d5d232e) unhandled exception executing api command: listConfigurations java.lang.NullPointerException at com.cloud.server.ConfigurationServerImpl.getConfigListByScope(ConfigurationServerImpl.java:778) at com.cloud.server.ManagementServerImpl.searchForConfigurations(ManagementServerImpl.java:1675) 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:616) 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 $Proxy222.searchForConfigurations(Unknown Source) at org.apache.cloudstack.api.command.admin.config.ListCfgsByCmd.execute(ListCfgsByCmd.java:115) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:527) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:370) at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:322) at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52) at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114) 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:111) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:73) 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
[jira] [Commented] (CLOUDSTACK-5145) ListNetworkACL API should list ACLs owned by the user only
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843238#comment-13843238 ] ASF subversion and git services commented on CLOUDSTACK-5145: - Commit c2d5ed2ec91e4116b5daaf718f93102e2ed5a309 in branch refs/heads/4.2 from [~kishan] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c2d5ed2 ] CLOUDSTACK-5145 : Added permission checks while listing network ACLs and acl Items. Users will be able to list items that they have access to. Conflicts: server/src/com/cloud/network/vpc/NetworkACLServiceImpl.java server/test/com/cloud/vpc/NetworkACLServiceTest.java ListNetworkACL API should list ACLs owned by the user only -- Key: CLOUDSTACK-5145 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5145 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala Assignee: Kishan Kavala Priority: Blocker Fix For: 4.2.1, 4.3.0 ListNetworkACL API should filter ACLs by caller and list ACLs which can be accessed by the user only. If API call is not called with a networkid or other filter, every ACL in the system is dumped, which is both a performance issue and a security issue. If a networkid is provided, but the network doesn't have an ACL list or any ACL items attached, the same issue occurs. Likewise, listNetworkACLLists gives access to see non-owned lists, which in turn gives vpc ids for non-owned resources. Example: 1. Set up a zone 2. Create a VPC or network as admin 3. Create an ACL list for the network 4. Create a new domain and unprivileged user 5. Generate API keys for user 6. Issue a 'listNetworkACLs' API call. You should see the ACL list items from the admin-owned list 7. Issue a 'listNetworkACLLists' API call referencing aclid from non-owned acl item. You should see the acl list info and which vpc it belongs to. 8. Listing the vpc attached to the acl list properly stops with an 'unauthorized' response as step 7 above should. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-3190) action events message published on 'event bus' should have the UUID of the entity for which event generated and event type
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Ough resolved CLOUDSTACK-3190. --- Resolution: Fixed action events message published on 'event bus' should have the UUID of the entity for which event generated and event type -- Key: CLOUDSTACK-3190 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3190 Project: CloudStack Issue Type: Task Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.1.0 Environment: action events message published on 'event bus' should have the UUID of the entity for which event generated and entity type details. as well Events bus framework with current AMQP default implementation, has routing key with format 'Eventsource.EventCategory.EventType.EntityType.EntityUUID'. For action events, EntityUUDI is not populated. Fix would required to ensure entity UUID is used in forming the routing key. Reporter: Murali Reddy Assignee: Alex Ough Labels: newbie -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5145) ListNetworkACL API should list ACLs owned by the user only
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843291#comment-13843291 ] ASF subversion and git services commented on CLOUDSTACK-5145: - Commit 33ff20e1c31b18d7618f04b672cce0b8f110d7dc in branch refs/heads/4.3 from [~kishan] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=33ff20e ] CLOUDSTACK-5145 : Added permission checks while listing network ACLs and acl Items. Users will be able to list items that they have access to. ListNetworkACL API should list ACLs owned by the user only -- Key: CLOUDSTACK-5145 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5145 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala Assignee: Kishan Kavala Priority: Blocker Fix For: 4.2.1, 4.3.0 ListNetworkACL API should filter ACLs by caller and list ACLs which can be accessed by the user only. If API call is not called with a networkid or other filter, every ACL in the system is dumped, which is both a performance issue and a security issue. If a networkid is provided, but the network doesn't have an ACL list or any ACL items attached, the same issue occurs. Likewise, listNetworkACLLists gives access to see non-owned lists, which in turn gives vpc ids for non-owned resources. Example: 1. Set up a zone 2. Create a VPC or network as admin 3. Create an ACL list for the network 4. Create a new domain and unprivileged user 5. Generate API keys for user 6. Issue a 'listNetworkACLs' API call. You should see the ACL list items from the admin-owned list 7. Issue a 'listNetworkACLLists' API call referencing aclid from non-owned acl item. You should see the acl list info and which vpc it belongs to. 8. Listing the vpc attached to the acl list properly stops with an 'unauthorized' response as step 7 above should. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5145) ListNetworkACL API should list ACLs owned by the user only
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843293#comment-13843293 ] ASF subversion and git services commented on CLOUDSTACK-5145: - Commit 587f5876217f268646f6fe03c9f57f5796400aa6 in branch refs/heads/master from [~kishan] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=587f587 ] CLOUDSTACK-5145 : Added permission checks while listing network ACLs and acl Items. Users will be able to list items that they have access to. Conflicts: api/src/com/cloud/network/vpc/NetworkACLService.java api/src/org/apache/cloudstack/api/command/user/network/ListNetworkACLListsCmd.java server/src/com/cloud/network/vpc/NetworkACLServiceImpl.java server/test/com/cloud/vpc/NetworkACLServiceTest.java ListNetworkACL API should list ACLs owned by the user only -- Key: CLOUDSTACK-5145 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5145 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala Assignee: Kishan Kavala Priority: Blocker Fix For: 4.2.1, 4.3.0 ListNetworkACL API should filter ACLs by caller and list ACLs which can be accessed by the user only. If API call is not called with a networkid or other filter, every ACL in the system is dumped, which is both a performance issue and a security issue. If a networkid is provided, but the network doesn't have an ACL list or any ACL items attached, the same issue occurs. Likewise, listNetworkACLLists gives access to see non-owned lists, which in turn gives vpc ids for non-owned resources. Example: 1. Set up a zone 2. Create a VPC or network as admin 3. Create an ACL list for the network 4. Create a new domain and unprivileged user 5. Generate API keys for user 6. Issue a 'listNetworkACLs' API call. You should see the ACL list items from the admin-owned list 7. Issue a 'listNetworkACLLists' API call referencing aclid from non-owned acl item. You should see the acl list info and which vpc it belongs to. 8. Listing the vpc attached to the acl list properly stops with an 'unauthorized' response as step 7 above should. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5145) ListNetworkACL API should list ACLs owned by the user only
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala resolved CLOUDSTACK-5145. --- Resolution: Fixed ListNetworkACL API should list ACLs owned by the user only -- Key: CLOUDSTACK-5145 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5145 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Kishan Kavala Assignee: Kishan Kavala Priority: Blocker Fix For: 4.2.1, 4.3.0 ListNetworkACL API should filter ACLs by caller and list ACLs which can be accessed by the user only. If API call is not called with a networkid or other filter, every ACL in the system is dumped, which is both a performance issue and a security issue. If a networkid is provided, but the network doesn't have an ACL list or any ACL items attached, the same issue occurs. Likewise, listNetworkACLLists gives access to see non-owned lists, which in turn gives vpc ids for non-owned resources. Example: 1. Set up a zone 2. Create a VPC or network as admin 3. Create an ACL list for the network 4. Create a new domain and unprivileged user 5. Generate API keys for user 6. Issue a 'listNetworkACLs' API call. You should see the ACL list items from the admin-owned list 7. Issue a 'listNetworkACLLists' API call referencing aclid from non-owned acl item. You should see the acl list info and which vpc it belongs to. 8. Listing the vpc attached to the acl list properly stops with an 'unauthorized' response as step 7 above should. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5061) Cloudstack doesn't consider storage overprovisioning factor when using thin Provisioning over VMWare VMFS datastores
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843314#comment-13843314
]
Noel King commented on CLOUDSTACK-5061:
---
Hi
I see this fix, but I am wondering if there is a path missing for this fix?
From what I can read in the code from the StatsController it triggers based on
the storage.stats.interval time interval. This is calling the
StorageController? which has the following code which can set the
pool.setCapacityBytes without containing the over provisioning factor?
I had identified the issue raised here in version 4.1.1 which I am using on
VMWare and as a consequence looked to see if I could update the database
manually to handle this op_host_capacity and storage_pool tables, however I
believe the StorageController is the class that keeps resetting my updated
database values. My investigation is a little hard as I am just reading
through the code to understand the paths potentially impacting the issue raised
here.
I know this issues is closed and I can raise a new one if the correct procedure
in such a situation.
= StatsController StorageController run()
Answer answer = _storageManager.sendToPool(pool, command);
if (answer != null
answer.getResult()) {
storagePoolStats.put(pool.getId(), (StorageStats)answer);
// Seems like we have
dynamically updated the pool size since the prev. size and the current do not
match
if
(_storagePoolStats.get(poolId)!= null
_storagePoolStats.get(poolId).getCapacityBytes() !=
((StorageStats)answer).getCapacityBytes()){
pool.setCapacityBytes(((StorageStats)answer).getCapacityBytes());
_storagePoolDao.update(pool.getId(), pool);
}
}
=
Thanks
Noel
Cloudstack doesn't consider storage overprovisioning factor when using thin
Provisioning over VMWare VMFS datastores
Key: CLOUDSTACK-5061
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5061
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller
Affects Versions: 4.2.0
Reporter: Sateesh Chodapuneedi
Assignee: Sateesh Chodapuneedi
Priority: Critical
Fix For: 4.2.1
Cloudstack does not let us to create new VMs as it cannot calculate a free
space correctly when using Thin Provisioning with VMware. It calculates space
from the size of the volumes rather then what is truly utilized on the SAN.
DETAILS
===
1. DB
mysql select p.name, p.pool_type, p.used_bytes, p.capacity_bytes,
sum(v.size) as volumes_allocated from volumes v join storage_pool p on
v.pool_id=p.id where v.removed is null group by v.pool_id;
-
name pool_type used_bytes capacity_bytes volumes_allocated
-
PrimaryStorage1 VMFS 804432904192 1023812829184 940446842880
PrimaryStorage2 VMFS 901673648128 1023812829184 347791687680
-
2 rows in set (0.01 sec)
2. vCenter reports as the datastore size, storage allocated, and storage used
Capacity : 953.50GB
Provisioned Space : 944.76GB
Free Space : 751.60GB
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5422) Changing XenServer Tools Version 6.1 + doesnt work
Tomasz Zieba created CLOUDSTACK-5422: Summary: Changing XenServer Tools Version 6.1 + doesnt work Key: CLOUDSTACK-5422 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5422 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.1 Environment: CloudStack 4.2.1 Reporter: Tomasz Zieba Priority: Blocker The situation is very similar to CLOUDSTACK-3806 and refers to the option XenServer Tools Version 6.1 + in Instances menu. Checking / unchecking this option when Instance does not affect the operation of the system. The problem identical to CLOUDSTACK-3806. The database does not change the corresponding field. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-3267) scaling up vm is failing on xen6.0.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843322#comment-13843322 ] Nitin Mehta commented on CLOUDSTACK-3267: - Adam - you are setting the vm's new service offering allowed by the static max - (memory-dynamic-max(4294967296) = memory-static-max(2147483648) scaling up vm is failing on xen6.0.2 Key: CLOUDSTACK-3267 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3267 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Reporter: prashant kumar mishra Assignee: Nitin Mehta Priority: Critical Fix For: 4.2.0 Attachments: Logs_DB.rar vm scaleup is failing on xen6.0.2(with and without hot fixes) steps to reproduce --- 1-prepare a xen 6.0.2 host (license+hostfixes) 2-Create a CS setup in advance networking mode 3-deploy a vm with small service offeirng and default template 4-try scaling up to medium instance Expected scaling up should be successful Actual Scaling up failed at com.cloud.vm.VirtualMachineManagerImpl.reConfigureVm(VirtualMachineManagerImpl.java:3260) at com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1211) at com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1090) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.vm.ScaleVMCmd.execute(ScaleVMCmd.java:92) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) 2013-06-28 10:35:05,081 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-1:job-15) Complete async job-15, jobStatus: 2, resultCode: 530, result: Error Code: 530 Error text: Unable to scale vm due to Catch exception com.cloud.utils.exception.CloudRuntimeException when scaling VM:i-2-3-VM due to com.cloud.utils.exception.CloudRuntimeException: Cannot scale up the vm because of memory constraint violation: 0 = memory-static-min = memory-dynamic-min = memory-dynamic-max = memory-static-max -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5098) [UI] Zone view is showing Add VMware Datacenter button even though zone is already associated with a data center
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843372#comment-13843372 ] Sateesh Chodapuneedi commented on CLOUDSTACK-5098: -- I could reproduce the issue. Even though zone1 is associated with VMware DC, we still see “Add Vmware Datacenter” button for that zone. I ran listVmwareDcs API as follows and received following response with Vmware DC associated with specific zone. Query - http://MSIP:8096/?command=listVmwareDcszoneid=f78cee8c-955a-4b72-95d1-b7360f9e4754 Response – listvmwaredcsresponse cloud-stack-version=4.2.1 count1/count VMwareDC id6d84100c-ae55-4e99-a309-2e3881e74fe1/id zoneid1/zoneid namedcdemo/name vcenter10.102.192.248/vcenter /VMwareDC /listvmwaredcsresponse [UI] Zone view is showing Add VMware Datacenter button even though zone is already associated with a data center -- Key: CLOUDSTACK-5098 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5098 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.1 Reporter: Sailaja Mada Assignee: Sateesh Chodapuneedi Priority: Critical Fix For: 4.3.0 Attachments: apilog.log, management-server.log Steps: 1. Enable Nexus flag at the global level 2. Tried to configure the Adv zone with VMWARE hypervisor with out specifying Nexus vSwitch details while adding the cluster. With this Cluster addition failed . So i have cancelled the zone configuration. Now tried below steps: 1) Removed Pod and then tried to remove zone . It failed saying The zone is not deletable because there are VMware datacenters associated with this zone. Remove VMware DC from this zone. 2) There is no Remove DC option , When i go to Zone details in the UI Observation: 1) Entries in vmware_data_center and vmware_data_center_zone_map are not cleaned up when there is a failure to add the cluster 2) So with this issue when i try to add the cluster , it is failing saying This data center is already part of other Cloudstack Zone So when there is a failure to add cluster for any reason , we should remove the addDC association in the DB aswell. I did delete the rows from vmware_data_center and vmware_data_center_zone_map , Then i was able to reuse the Datacenter -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5098) [UI] Zone view is showing Add VMware Datacenter button even though zone is already associated with a data center
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sateesh Chodapuneedi updated CLOUDSTACK-5098: - Assignee: Jessica Wang (was: Sateesh Chodapuneedi) [UI] Zone view is showing Add VMware Datacenter button even though zone is already associated with a data center -- Key: CLOUDSTACK-5098 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5098 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.1 Reporter: Sailaja Mada Assignee: Jessica Wang Priority: Critical Fix For: 4.3.0 Attachments: apilog.log, management-server.log Steps: 1. Enable Nexus flag at the global level 2. Tried to configure the Adv zone with VMWARE hypervisor with out specifying Nexus vSwitch details while adding the cluster. With this Cluster addition failed . So i have cancelled the zone configuration. Now tried below steps: 1) Removed Pod and then tried to remove zone . It failed saying The zone is not deletable because there are VMware datacenters associated with this zone. Remove VMware DC from this zone. 2) There is no Remove DC option , When i go to Zone details in the UI Observation: 1) Entries in vmware_data_center and vmware_data_center_zone_map are not cleaned up when there is a failure to add the cluster 2) So with this issue when i try to add the cluster , it is failing saying This data center is already part of other Cloudstack Zone So when there is a failure to add cluster for any reason , we should remove the addDC association in the DB aswell. I did delete the rows from vmware_data_center and vmware_data_center_zone_map , Then i was able to reuse the Datacenter -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Assigned] (CLOUDSTACK-5423) [Automation] : deployAndRun and TestCaseExecuteEngine needs modification
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla reassigned CLOUDSTACK-5423: --- Assignee: Santhosh Kumar Edukulla [Automation] : deployAndRun and TestCaseExecuteEngine needs modification Key: CLOUDSTACK-5423 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5423 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, marvin Environment: The two mentioned files requires modification as part of enhancements done to marvin , deployDataCenter etc. Some cleaning is as well required as part of it. Reporter: Santhosh Kumar Edukulla Assignee: Santhosh Kumar Edukulla -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5423) [Automation] : deployAndRun and TestCaseExecuteEngine needs modification
Santhosh Kumar Edukulla created CLOUDSTACK-5423: --- Summary: [Automation] : deployAndRun and TestCaseExecuteEngine needs modification Key: CLOUDSTACK-5423 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5423 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation, marvin Environment: The two mentioned files requires modification as part of enhancements done to marvin , deployDataCenter etc. Some cleaning is as well required as part of it. Reporter: Santhosh Kumar Edukulla -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Issue Comment Deleted] (CLOUDSTACK-5061) Cloudstack doesn't consider storage overprovisioning factor when using thin Provisioning over VMWare VMFS datastores
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noel King updated CLOUDSTACK-5061:
--
Comment: was deleted
(was: Hi
I see this fix, but I am wondering if there is a path missing for this fix?
From what I can read in the code from the StatsController it triggers based on
the storage.stats.interval time interval. This is calling the
StorageController? which has the following code which can set the
pool.setCapacityBytes without containing the over provisioning factor?
I had identified the issue raised here in version 4.1.1 which I am using on
VMWare and as a consequence looked to see if I could update the database
manually to handle this op_host_capacity and storage_pool tables, however I
believe the StorageController is the class that keeps resetting my updated
database values. My investigation is a little hard as I am just reading
through the code to understand the paths potentially impacting the issue raised
here.
I know this issues is closed and I can raise a new one if the correct procedure
in such a situation.
= StatsController StorageController run()
Answer answer = _storageManager.sendToPool(pool, command);
if (answer != null
answer.getResult()) {
storagePoolStats.put(pool.getId(), (StorageStats)answer);
// Seems like we have
dynamically updated the pool size since the prev. size and the current do not
match
if
(_storagePoolStats.get(poolId)!= null
_storagePoolStats.get(poolId).getCapacityBytes() !=
((StorageStats)answer).getCapacityBytes()){
pool.setCapacityBytes(((StorageStats)answer).getCapacityBytes());
_storagePoolDao.update(pool.getId(), pool);
}
}
=
Thanks
Noel)
Cloudstack doesn't consider storage overprovisioning factor when using thin
Provisioning over VMWare VMFS datastores
Key: CLOUDSTACK-5061
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5061
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller
Affects Versions: 4.2.0
Reporter: Sateesh Chodapuneedi
Assignee: Sateesh Chodapuneedi
Priority: Critical
Fix For: 4.2.1
Cloudstack does not let us to create new VMs as it cannot calculate a free
space correctly when using Thin Provisioning with VMware. It calculates space
from the size of the volumes rather then what is truly utilized on the SAN.
DETAILS
===
1. DB
mysql select p.name, p.pool_type, p.used_bytes, p.capacity_bytes,
sum(v.size) as volumes_allocated from volumes v join storage_pool p on
v.pool_id=p.id where v.removed is null group by v.pool_id;
-
name pool_type used_bytes capacity_bytes volumes_allocated
-
PrimaryStorage1 VMFS 804432904192 1023812829184 940446842880
PrimaryStorage2 VMFS 901673648128 1023812829184 347791687680
-
2 rows in set (0.01 sec)
2. vCenter reports as the datastore size, storage allocated, and storage used
Capacity : 953.50GB
Provisioned Space : 944.76GB
Free Space : 751.60GB
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5423) [Automation] : deployAndRun and TestCaseExecuteEngine needs modification
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla updated CLOUDSTACK-5423: Environment: (was: The two mentioned files requires modification as part of enhancements done to marvin , deployDataCenter etc. Some cleaning is as well required as part of it.) [Automation] : deployAndRun and TestCaseExecuteEngine needs modification Key: CLOUDSTACK-5423 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5423 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, marvin Reporter: Santhosh Kumar Edukulla Assignee: Santhosh Kumar Edukulla -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5423) [Automation] : deployAndRun and TestCaseExecuteEngine needs modification
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla updated CLOUDSTACK-5423: Description: https://issues.apache.org/jira/browse/CLOUDSTACK-5423 [Automation] : deployAndRun and TestCaseExecuteEngine needs modification Key: CLOUDSTACK-5423 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5423 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, marvin Reporter: Santhosh Kumar Edukulla Assignee: Santhosh Kumar Edukulla https://issues.apache.org/jira/browse/CLOUDSTACK-5423 -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-3267) scaling up vm is failing on xen6.0.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843395#comment-13843395 ] Adam commented on CLOUDSTACK-3267: -- Hello Nitin; - I actually went a head and filed a new bug. All details on the link: https://issues.apache.org/jira/browse/CLOUDSTACK-5306 - I did this test on Windows Server 2008 R2 and centos 6.3 (both cases it failed) I tried with couple different service offerings. - The VM in this example comes with 2GB memory and I'm trying scale it to 4GB. I'm not sure what you mean by memory-static-max. Thank you; Adam scaling up vm is failing on xen6.0.2 Key: CLOUDSTACK-3267 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3267 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Reporter: prashant kumar mishra Assignee: Nitin Mehta Priority: Critical Fix For: 4.2.0 Attachments: Logs_DB.rar vm scaleup is failing on xen6.0.2(with and without hot fixes) steps to reproduce --- 1-prepare a xen 6.0.2 host (license+hostfixes) 2-Create a CS setup in advance networking mode 3-deploy a vm with small service offeirng and default template 4-try scaling up to medium instance Expected scaling up should be successful Actual Scaling up failed at com.cloud.vm.VirtualMachineManagerImpl.reConfigureVm(VirtualMachineManagerImpl.java:3260) at com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1211) at com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1090) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.vm.ScaleVMCmd.execute(ScaleVMCmd.java:92) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) 2013-06-28 10:35:05,081 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-1:job-15) Complete async job-15, jobStatus: 2, resultCode: 530, result: Error Code: 530 Error text: Unable to scale vm due to Catch exception com.cloud.utils.exception.CloudRuntimeException when scaling VM:i-2-3-VM due to com.cloud.utils.exception.CloudRuntimeException: Cannot scale up the vm because of memory constraint violation: 0 = memory-static-min = memory-dynamic-min = memory-dynamic-max = memory-static-max -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5423) [Automation] : deployAndRun and TestCaseExecuteEngine needs modification
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla updated CLOUDSTACK-5423: Description: As part of recent changes to marvin, mentioned files requires some changes. Some cleaning is as well required for these two files (was: https://issues.apache.org/jira/browse/CLOUDSTACK-5423) [Automation] : deployAndRun and TestCaseExecuteEngine needs modification Key: CLOUDSTACK-5423 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5423 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, marvin Reporter: Santhosh Kumar Edukulla Assignee: Santhosh Kumar Edukulla As part of recent changes to marvin, mentioned files requires some changes. Some cleaning is as well required for these two files -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5350) [Automation] Failed to attach volume to VM, if the vm is created with option startvm=false
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843438#comment-13843438 ] frank zhang commented on CLOUDSTACK-5350: - Rayees, How to rerun this to get a db dump? [Automation] Failed to attach volume to VM, if the vm is created with option startvm=false -- Key: CLOUDSTACK-5350 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5350 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Volumes Affects Versions: 4.3.0 Environment: KVM (RHEL 6.3) Branch : 4.3 Reporter: Rayees Namathponnan Assignee: frank zhang Priority: Blocker Fix For: 4.3.0 Regression automation failure test_stopped_vm.py:test_04_deploy_startvm_false_attach_volume Steps to reproduce # Validate the following: 1. deploy Vm with the startvm=false. Attach volume to the instance 2. listVM command should return the deployed VM.State of this VM should be Stopped. 3. Attach volume should be successful Actual Result Attach volume failed with below error 2013-12-03 08:45:50,190 DEBUG [o.a.c.s.a.ZoneWideStoragePoolAllocator] (Job-Executor-8:ctx-780454c7 ctx-c09f3d6f) List of pools in ascending order of number of volumes for account id: 516 is: [] 2013-12-03 08:45:50,190 WARN [o.a.c.e.o.VolumeOrchestrator] (Job-Executor-8:ctx-780454c7 ctx-c09f3d6f) Unable to find suitable primary storage whe n creating volume DataDisk 2013-12-03 08:45:50,208 ERROR [c.c.a.ApiAsyncJobDispatcher] (Job-Executor-8:ctx-780454c7) Unexpected exception while executing org.apache.cloudstac k.api.command.user.volume.AttachVolumeCmd com.cloud.utils.exception.CloudRuntimeException: Unable to find suitable primary storage when creating volume DataDisk at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolume(VolumeOrchestrator.java:399) at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolumeOnPrimaryStorage(VolumeOrchestrator.java:697) at com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1086) at sun.reflect.GeneratedMethodAccessor681.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) 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 $Proxy232.attachVolumeToVM(Unknown Source) at org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:123) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) at com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109) at com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66) 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.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:520) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at
[jira] [Commented] (CLOUDSTACK-5350) [Automation] Failed to attach volume to VM, if the vm is created with option startvm=false
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843466#comment-13843466 ] Rayees Namathponnan commented on CLOUDSTACK-5350: - Similar issues reported in https://issues.apache.org/jira/browse/CLOUDSTACK-4244 https://issues.apache.org/jira/browse/CLOUDSTACK-3759 [Automation] Failed to attach volume to VM, if the vm is created with option startvm=false -- Key: CLOUDSTACK-5350 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5350 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Volumes Affects Versions: 4.3.0 Environment: KVM (RHEL 6.3) Branch : 4.3 Reporter: Rayees Namathponnan Assignee: frank zhang Priority: Blocker Fix For: 4.3.0 Regression automation failure test_stopped_vm.py:test_04_deploy_startvm_false_attach_volume Steps to reproduce # Validate the following: 1. deploy Vm with the startvm=false. Attach volume to the instance 2. listVM command should return the deployed VM.State of this VM should be Stopped. 3. Attach volume should be successful Actual Result Attach volume failed with below error 2013-12-03 08:45:50,190 DEBUG [o.a.c.s.a.ZoneWideStoragePoolAllocator] (Job-Executor-8:ctx-780454c7 ctx-c09f3d6f) List of pools in ascending order of number of volumes for account id: 516 is: [] 2013-12-03 08:45:50,190 WARN [o.a.c.e.o.VolumeOrchestrator] (Job-Executor-8:ctx-780454c7 ctx-c09f3d6f) Unable to find suitable primary storage whe n creating volume DataDisk 2013-12-03 08:45:50,208 ERROR [c.c.a.ApiAsyncJobDispatcher] (Job-Executor-8:ctx-780454c7) Unexpected exception while executing org.apache.cloudstac k.api.command.user.volume.AttachVolumeCmd com.cloud.utils.exception.CloudRuntimeException: Unable to find suitable primary storage when creating volume DataDisk at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolume(VolumeOrchestrator.java:399) at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolumeOnPrimaryStorage(VolumeOrchestrator.java:697) at com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1086) at sun.reflect.GeneratedMethodAccessor681.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) 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 $Proxy232.attachVolumeToVM(Unknown Source) at org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:123) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) at com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109) at com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66) 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.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:520) 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
[jira] [Created] (CLOUDSTACK-5424) site-to-site VPN VR-to-VR shows 0 for user's network-VPC site-to-site VPN pane even when user has existent site-to-stie VPN
angeline shen created CLOUDSTACK-5424: - Summary: site-to-site VPN VR-to-VRshows 0 for user's network-VPC site-to-site VPN pane even when user has existent site-to-stie VPN Key: CLOUDSTACK-5424 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5424 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Environment: MS rhel 6.4 12/5/13 latest build 97 host XS 6.2 Reporter: angeline shen Attachments: v3.png, v4.png, v5.png, v6.png 1. admin login, creates vpc1, Router site-to-site VPNS, create VPN customer gateway d1user login, creates vpc2, Router site-to-site VPNS, create VPN customer gateway 2. admin login, admin's vpc, networkRouter site-to-site VPNS pane shows '1' for admin's existent site-to-site VPNS admin login, d1user's vpc, networkRouter site-to-site VPNS pane shows '0' for d1user's existent site-to-site VPNS -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5424) site-to-site VPN VR-to-VR shows 0 for user's network-VPC site-to-site VPN pane even when user has existent site-to-stie VPN
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angeline shen updated CLOUDSTACK-5424: -- Attachment: v6.png v5.png v4.png v3.png site-to-site VPN VR-to-VRshows 0 for user's network-VPC site-to-site VPN pane even when user has existent site-to-stie VPN --- Key: CLOUDSTACK-5424 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5424 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Environment: MS rhel 6.4 12/5/13 latest build 97 host XS 6.2 Reporter: angeline shen Attachments: v3.png, v4.png, v5.png, v6.png 1. admin login, creates vpc1, Router site-to-site VPNS, create VPN customer gateway d1user login, creates vpc2, Router site-to-site VPNS, create VPN customer gateway 2. admin login, admin's vpc, networkRouter site-to-site VPNS pane shows '1' for admin's existent site-to-site VPNS admin login, d1user's vpc, networkRouter site-to-site VPNS pane shows '0' for d1user's existent site-to-site VPNS -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5278) Egress Firewall rules clarifications
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843495#comment-13843495 ] Will Stevens commented on CLOUDSTACK-5278: -- Sorry for the delay getting back to you. I had some issues getting my dev environment back up and running after pulling the latest 4.3 branch. Yes, I have tested your diff with my code and the latest code on 4.3 and everything works fine in my plugin. I will be posting a bug for my plugin with my patch to fix it a little later this afternoon. Thanks for the hard work, Will Egress Firewall rules clarifications Key: CLOUDSTACK-5278 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5278 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Will Stevens Assignee: Jayapal Reddy Priority: Critical Fix For: 4.3.0 Attachments: diff.txt, diff.txt These issues may also exist in the 4.2 branch, but I am currently testing/working on the 4.3 branch. I believe these bugs were introduced with the change to the Network Service Offering to add the 'Default egress policy' dropdown. https://issues.apache.org/jira/browse/CLOUDSTACK-1578 I am trying to resolve the bugs this change introduced in the Palo Alto plugin. There are two types of Egress rules (from what I can tell). - FirewallRule.FirewallRuleType.System : this appears to be set up by the system on network creation to correspond to the global network default allow/deny egress rule. - FirewallRule.FirewallRuleType.User : any rule that a user creates through the UI will get this type. There are bugs associated with both of the options in the dropdown (allow and deny). Case: 'deny' - When the network is setup, it does not try to create the global deny rule for the network, but it appears to register that it exists. Instead, when the first egress rule is created by a user, the system sees both the 'system' and 'user' rules, so it will create both rules then. Case: both 'allow' and 'deny' - The clean up of the network global 'system' egress rules are never done. So when a network is deleted, it will leave an orphaned egress rule associated with the previous network's cidr. This is bound to cause many issues. - Even worse, it appears that the ID for the network global 'system' egress rule is hardcoded to '0'. Every time I try to spin up a new network it will attempt to create a rule with a '0' ID, but since one already exists with that ID, there is a config collision. In my case (Palo Alto), the second rule with the same ID gets ignored because it checks to see if the rule exists and it gets a 'yes' back because the previous network has an egress rule with that ID already. Let me know if you have additional questions... -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5425) Egress firewall rules are broken in the Palo Alto plugin
Will Stevens created CLOUDSTACK-5425: Summary: Egress firewall rules are broken in the Palo Alto plugin Key: CLOUDSTACK-5425 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5425 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Will Stevens Assignee: Will Stevens Priority: Critical Fix For: 4.3.0 The introduction of the ability to setup a default egress firewall rule in the network service offering broke the Palo Alto plugin. This bug/patch fixes the issues with egress rules in the Palo Alto plugin. In addition, I have removed API commands that I had implemented which are not needed... eg: addExternalFirewall deleteExternalFirewall listExternalFirewalls -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5425) Egress firewall rules are broken in the Palo Alto plugin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Stevens updated CLOUDSTACK-5425: - Attachment: fixed-egress-rules.patch This patch fixes the egress firewall functionality in the Palo Alto plugin. Egress firewall rules are broken in the Palo Alto plugin Key: CLOUDSTACK-5425 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5425 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Will Stevens Assignee: Will Stevens Priority: Critical Fix For: 4.3.0 Attachments: fixed-egress-rules.patch The introduction of the ability to setup a default egress firewall rule in the network service offering broke the Palo Alto plugin. This bug/patch fixes the issues with egress rules in the Palo Alto plugin. In addition, I have removed API commands that I had implemented which are not needed... eg: addExternalFirewall deleteExternalFirewall listExternalFirewalls -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Comment Edited] (CLOUDSTACK-5425) Egress firewall rules are broken in the Palo Alto plugin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843553#comment-13843553 ] Will Stevens edited comment on CLOUDSTACK-5425 at 12/9/13 9:06 PM: --- This patch fixes the egress firewall functionality in the Palo Alto plugin. This patch is for the 4.3 branch. I will test it on master to see if I need to add another patch for master. Hopefully this patch will work on both master and 4.3... was (Author: wstevens): This patch fixes the egress firewall functionality in the Palo Alto plugin. Egress firewall rules are broken in the Palo Alto plugin Key: CLOUDSTACK-5425 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5425 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Will Stevens Assignee: Will Stevens Priority: Critical Fix For: 4.3.0 Attachments: fixed-egress-rules.patch The introduction of the ability to setup a default egress firewall rule in the network service offering broke the Palo Alto plugin. This bug/patch fixes the issues with egress rules in the Palo Alto plugin. In addition, I have removed API commands that I had implemented which are not needed... eg: addExternalFirewall deleteExternalFirewall listExternalFirewalls -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5426) Cannot deploy instance having multiple volumes that use different storage tags for storage pools in same cluster
Prachi Damle created CLOUDSTACK-5426: Summary: Cannot deploy instance having multiple volumes that use different storage tags for storage pools in same cluster Key: CLOUDSTACK-5426 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5426 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0, 4.2.1, 4.3.0 Reporter: Prachi Damle Assignee: Prachi Damle Priority: Critical Fix For: 4.3.0 This issue can be observed when VM being deployed has multiple volumes (=2) where 2 adjacent volumes are to be created with 2 different disk offerings with different storage tags. Ex: 1. VM1 has 2 volumes root volume 1 data volume. 2. root volume is to be created using a disk offering with storage tag 'root_disk' 3. data volume is to be created using a disk offering with storage tag 'data_disk' 4. There exists a cluster wide storage pool suitable for root volume with storage tag 'root_disk' 5. There exists a cluster wide storage pool suitable for data volume with storage tag 'data_disk' The deploy VM fails in this case. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5426) Cannot deploy instance having multiple volumes that use different storage tags for storage pools in same cluster
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843626#comment-13843626 ] ASF subversion and git services commented on CLOUDSTACK-5426: - Commit 6df86db2309db2b93b1001db42b5f797dd445a63 in branch refs/heads/4.3 from [~prachidamle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6df86db ] CLOUDSTACK-5426: Cannot deploy instance having multiple volumes that use different storage tags for storage pools in same cluster Changes: - We need to reset the avoid set to its original state while calling the storage pool allocators for each volume. - This will prevent affecting allocation of the disks due to the avoid set output of the prior disk allocations. Cannot deploy instance having multiple volumes that use different storage tags for storage pools in same cluster Key: CLOUDSTACK-5426 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5426 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0, 4.2.1, 4.3.0 Reporter: Prachi Damle Assignee: Prachi Damle Priority: Critical Fix For: 4.3.0 This issue can be observed when VM being deployed has multiple volumes (=2) where 2 adjacent volumes are to be created with 2 different disk offerings with different storage tags. Ex: 1. VM1 has 2 volumes root volume 1 data volume. 2. root volume is to be created using a disk offering with storage tag 'root_disk' 3. data volume is to be created using a disk offering with storage tag 'data_disk' 4. There exists a cluster wide storage pool suitable for root volume with storage tag 'root_disk' 5. There exists a cluster wide storage pool suitable for data volume with storage tag 'data_disk' The deploy VM fails in this case. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5426) Cannot deploy instance having multiple volumes that use different storage tags for storage pools in same cluster
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Damle resolved CLOUDSTACK-5426. -- Resolution: Fixed Cannot deploy instance having multiple volumes that use different storage tags for storage pools in same cluster Key: CLOUDSTACK-5426 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5426 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0, 4.2.1, 4.3.0 Reporter: Prachi Damle Assignee: Prachi Damle Priority: Critical Fix For: 4.3.0 This issue can be observed when VM being deployed has multiple volumes (=2) where 2 adjacent volumes are to be created with 2 different disk offerings with different storage tags. Ex: 1. VM1 has 2 volumes root volume 1 data volume. 2. root volume is to be created using a disk offering with storage tag 'root_disk' 3. data volume is to be created using a disk offering with storage tag 'data_disk' 4. There exists a cluster wide storage pool suitable for root volume with storage tag 'root_disk' 5. There exists a cluster wide storage pool suitable for data volume with storage tag 'data_disk' The deploy VM fails in this case. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5350) [Automation] Failed to attach volume to VM, if the vm is created with option startvm=false
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843646#comment-13843646 ] ASF subversion and git services commented on CLOUDSTACK-5350: - Commit c0724349a6761f64bfd8d37c96d82f863bfc6adb in branch refs/heads/4.3 from [~frank.zhang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c072434 ] CloudStackCLOUDSTACK-5350 [Automation] Failed to attach volume to VM, if the vm is created with option startvm=false duplicate of https://issues.apache.org/jira/browse/CLOUDSTACK-4244 merge the fix to 4.3 [Automation] Failed to attach volume to VM, if the vm is created with option startvm=false -- Key: CLOUDSTACK-5350 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5350 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Volumes Affects Versions: 4.3.0 Environment: KVM (RHEL 6.3) Branch : 4.3 Reporter: Rayees Namathponnan Assignee: frank zhang Priority: Blocker Fix For: 4.3.0 Regression automation failure test_stopped_vm.py:test_04_deploy_startvm_false_attach_volume Steps to reproduce # Validate the following: 1. deploy Vm with the startvm=false. Attach volume to the instance 2. listVM command should return the deployed VM.State of this VM should be Stopped. 3. Attach volume should be successful Actual Result Attach volume failed with below error 2013-12-03 08:45:50,190 DEBUG [o.a.c.s.a.ZoneWideStoragePoolAllocator] (Job-Executor-8:ctx-780454c7 ctx-c09f3d6f) List of pools in ascending order of number of volumes for account id: 516 is: [] 2013-12-03 08:45:50,190 WARN [o.a.c.e.o.VolumeOrchestrator] (Job-Executor-8:ctx-780454c7 ctx-c09f3d6f) Unable to find suitable primary storage whe n creating volume DataDisk 2013-12-03 08:45:50,208 ERROR [c.c.a.ApiAsyncJobDispatcher] (Job-Executor-8:ctx-780454c7) Unexpected exception while executing org.apache.cloudstac k.api.command.user.volume.AttachVolumeCmd com.cloud.utils.exception.CloudRuntimeException: Unable to find suitable primary storage when creating volume DataDisk at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolume(VolumeOrchestrator.java:399) at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolumeOnPrimaryStorage(VolumeOrchestrator.java:697) at com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1086) at sun.reflect.GeneratedMethodAccessor681.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) 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 $Proxy232.attachVolumeToVM(Unknown Source) at org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:123) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) at com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109) at com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66) 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.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:520) at
[jira] [Commented] (CLOUDSTACK-4244) Unable to attach a volume to a VM deployed in Stopped (startvm=false) state
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843647#comment-13843647 ] ASF subversion and git services commented on CLOUDSTACK-4244: - Commit c0724349a6761f64bfd8d37c96d82f863bfc6adb in branch refs/heads/4.3 from [~frank.zhang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c072434 ] CloudStackCLOUDSTACK-5350 [Automation] Failed to attach volume to VM, if the vm is created with option startvm=false duplicate of https://issues.apache.org/jira/browse/CLOUDSTACK-4244 merge the fix to 4.3 Unable to attach a volume to a VM deployed in Stopped (startvm=false) state --- Key: CLOUDSTACK-4244 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4244 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Prasanna Santhanam Assignee: Likitha Shetty Priority: Critical Fix For: 4.2.0 Attachments: attachvolume.log.tar.bz2 Steps to reproduce: 1. Deploy a Virtual Machine in stopped state (startvm=False) 2. Create a Volume from any standard disk offering 3. attach aforementioned volume to your stopped VM Expect: Volume attach should be successfull Observed: Attach volume fails 2013-08-12 11:46:50,076 ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-7:job-14 = [ 870294b5-d4c8-46c7-9e33-c1142f87364a ]) Unexpected exception while executing org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd com.cloud.utils.exception.CloudRuntimeException: Unable to find storage pool when create volumeDataDisk at com.cloud.storage.VolumeManagerImpl.createVolume(VolumeManagerImpl.java:677) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at com.cloud.storage.VolumeManagerImpl.createVolumeOnPrimaryStorage(VolumeManagerImpl.java:1538) at com.cloud.storage.VolumeManagerImpl.attachVolumeToVM(VolumeManagerImpl.java:1840) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:122) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) at java.lang.Thread.run(Thread.java:680) Attaching management server logs -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5191) [Automation] test case TestRevokeEgressRule.test_revoke_egress_rule failed to ping outside and failed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-5191: --- Issue Type: Test (was: Bug) [Automation] test case TestRevokeEgressRule.test_revoke_egress_rule failed to ping outside and failed -- Key: CLOUDSTACK-5191 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5191 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Rayees Namathponnan Assignee: Girish Shilamkar Labels: automation,, product, x Fix For: 4.3.0 Test case integration.component.test_egress_rules.TestRevokeEgressRule.test_revoke_egress_rule failed in KVM basic zone setup Test cases failed while ping outside from VM, observed below error in log Stacktrace File /usr/local/lib/python2.7/unittest/case.py, line 318, in run testMethod() File /Repo_30X/ipcl/cloudstack/test/integration/component/test_egress_rules.py, line 1067, in test_revoke_egress_rule Ping to outside world from VM should be successful File /usr/local/lib/python2.7/unittest/case.py, line 494, in assertEqual assertion_func(first, second, msg=msg) File /usr/local/lib/python2.7/unittest/case.py, line 487, in _baseAssertEqual raise self.failureException(msg) Ping to outside world from VM should be successful begin captured logging test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: Created security group with ID: 020865e7-d87b-4da9-b157-c315dc42e33d test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: Authorizing ingress rule for sec group ID: 020865e7-d87b-4da9-b157-c315dc42e33d for ssh access test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: Authorizing egress rule for sec group ID: 020865e7-d87b-4da9-b157-c315dc42e33d for ssh access test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: Deploying VM in account: test-TestStartStopVMWithEgressRule-test_multiple_account_egress_rule_negative-Q4UAPL test_revoke_egress_rule (integration.component.test_egress_rules.TestRevokeEgressRule): DEBUG: SSH into VM: 10.223.250.230 sshClient: DEBUG: SSH Connection: Host:10.223.250.230 User:root Port:22 sshClient: DEBUG: SSH Connection: Host:10.223.250.230 User:root Port:22 sshClient: DEBUG: SSH Connection: Host:10.223.250.230 User:root Port:22 sshClient: DEBUG: SSH Connection: Host:10.223.250.230 User:root Port:22 paramiko.transport: DEBUG: starting thread (client mode): 0xd9d0ad0L paramiko.transport: INFO: Connected (version 2.0, client OpenSSH_4.3) paramiko.transport: DEBUG: kex algos:['diffie-hellman-group-exchange-sha1', 'diffie-hellman-group14-sha1', 'diffie-hellman-group1-sha1'] server key:['ssh-rsa', 'ssh-dss'] client encrypt:['aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour', 'aes192-cbc', 'aes256-cbc', 'rijndael-...@lysator.liu.se', 'aes128-ctr', 'aes192-ctr', 'aes256-ctr'] server encrypt:['aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour', 'aes192-cbc', 'aes256-cbc', 'rijndael-...@lysator.liu.se', 'aes128-ctr', 'aes192-ctr', 'aes256-ctr'] client mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160', 'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] server mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160', 'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] client compress:['none', 'z...@openssh.com'] server compress:['none', 'z...@openssh.com'] client lang:[''] server lang:[''] kex follows?False paramiko.transport: DEBUG: Ciphers agreed: local=aes128-ctr, remote=aes128-ctr paramiko.transport: DEBUG: using kex diffie-hellman-group1-sha1; server key type ssh-rsa; cipher: local aes128-ctr, remote aes128-ctr; mac: local hmac-sha1, remote hmac-sha1; compression: local none, remote none paramiko.transport: DEBUG: Switch to new keys ... paramiko.transport: DEBUG: Adding ssh-rsa host key for 10.223.250.230: 0f8b3ff9dc4dce10340227dab3cac032 paramiko.transport: DEBUG: Trying discovered key a0114fddd71936946702c57069b4175b in /root/.ssh/id_rsa paramiko.transport: DEBUG: userauth is OK paramiko.transport: INFO: Authentication (publickey) failed. paramiko.transport: DEBUG: userauth is OK paramiko.transport:
[jira] [Resolved] (CLOUDSTACK-5350) [Automation] Failed to attach volume to VM, if the vm is created with option startvm=false
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] frank zhang resolved CLOUDSTACK-5350. - Resolution: Duplicate [Automation] Failed to attach volume to VM, if the vm is created with option startvm=false -- Key: CLOUDSTACK-5350 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5350 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Volumes Affects Versions: 4.3.0 Environment: KVM (RHEL 6.3) Branch : 4.3 Reporter: Rayees Namathponnan Assignee: frank zhang Priority: Blocker Fix For: 4.3.0 Regression automation failure test_stopped_vm.py:test_04_deploy_startvm_false_attach_volume Steps to reproduce # Validate the following: 1. deploy Vm with the startvm=false. Attach volume to the instance 2. listVM command should return the deployed VM.State of this VM should be Stopped. 3. Attach volume should be successful Actual Result Attach volume failed with below error 2013-12-03 08:45:50,190 DEBUG [o.a.c.s.a.ZoneWideStoragePoolAllocator] (Job-Executor-8:ctx-780454c7 ctx-c09f3d6f) List of pools in ascending order of number of volumes for account id: 516 is: [] 2013-12-03 08:45:50,190 WARN [o.a.c.e.o.VolumeOrchestrator] (Job-Executor-8:ctx-780454c7 ctx-c09f3d6f) Unable to find suitable primary storage whe n creating volume DataDisk 2013-12-03 08:45:50,208 ERROR [c.c.a.ApiAsyncJobDispatcher] (Job-Executor-8:ctx-780454c7) Unexpected exception while executing org.apache.cloudstac k.api.command.user.volume.AttachVolumeCmd com.cloud.utils.exception.CloudRuntimeException: Unable to find suitable primary storage when creating volume DataDisk at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolume(VolumeOrchestrator.java:399) at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolumeOnPrimaryStorage(VolumeOrchestrator.java:697) at com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1086) at sun.reflect.GeneratedMethodAccessor681.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) 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 $Proxy232.attachVolumeToVM(Unknown Source) at org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd.execute(AttachVolumeCmd.java:123) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) at com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109) at com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66) 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.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:520) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at
[jira] [Commented] (CLOUDSTACK-3664) scaling up vms is not considering parameter cluster.(memory/cpu).allocated.capacity.disablethreshold
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843650#comment-13843650 ] ASF subversion and git services commented on CLOUDSTACK-3664: - Commit 5d9335fcc32733777963db33022eb14c3c1d16d2 in branch refs/heads/4.3 from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5d9335f ] CLOUDSTACK-3664: scaling up vms was not considering parameter cluster.(memory/cpu).allocated.capacity.disablethreshold. Fixed it Also added overprovisioning factor retrieval at the cluster level for host capacity check scaling up vms is not considering parameter cluster.(memory/cpu).allocated.capacity.disablethreshold --- Key: CLOUDSTACK-3664 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3664 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Environment: xen 4.2 Reporter: prashant kumar mishra Assignee: Nitin Mehta Fix For: 4.3.0 Attachments: Logs_DB.rar, screenshot-1.jpg steps to reproduce 1-prepare a CS setup with xen 6.1 2-set cluster.memory.allocated.capacity.disablethreshold to some lower value say 0.2 3-deploy some vms until unless deployment fails because of threshold value. 4-Try to scale up vms Expected -- scaling up should get failed because threshold value Actual -- scaling up is successful DB mysql select *from cluster_details; ++++---+ | id | cluster_id | name | value | ++++---+ | 1 | 1 | cpuOvercommitRatio | 1.0 | | 2 | 1 | memoryOvercommitRatio | 1.0 | | 3 | 1 | cluster.memory.allocated.capacity.disablethreshold | 0.2 | ++++---+ -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5389) [Automation] Race Condition : Failed to find storage pool during router deployment in KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843655#comment-13843655 ] Animesh Chaturvedi commented on CLOUDSTACK-5389: Can someone with KVM experience check on this issue [Automation] Race Condition : Failed to find storage pool during router deployment in KVM - Key: CLOUDSTACK-5389 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5389 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: Branch : 4.3 Environment : KVM (RHEL 6.3) Reporter: Rayees Namathponnan Priority: Critical Fix For: 4.3.0 Attachments: Agent1.rar, Agent2.rar, Mslog.rar This issue is observed during automation run; 6 test cases cases are executing in parallel in automation environment; random deployment failure observed during automation run due to No suitable storagePools found under this Cluster: 1 2 primary storages are already configured in zone1; it as enough space too observed below error in ms log 2013-12-05 10:10:36,274 DEBUG [c.c.a.m.a.i.FirstFitAllocator] (Job-Executor-98:ctx-fe814e55 ctx-e2685be8 FirstFitRoutingAllocator) Found a suitable host, adding to list: 2 2013-12-05 10:10:36,274 DEBUG [c.c.a.m.a.i.FirstFitAllocator] (Job-Executor-98:ctx-fe814e55 ctx-e2685be8 FirstFitRoutingAllocator) Host Allocator returning 2 suitable hosts 2013-12-05 10:10:36,275 DEBUG [c.c.d.DeploymentPlanningManagerImpl] (Job-Executor-98:ctx-fe814e55 ctx-e2685be8) Checking suitable pools for volume (Id, Type): (1291,ROOT) 2013-12-05 10:10:36,275 DEBUG [c.c.d.DeploymentPlanningManagerImpl] (Job-Executor-98:ctx-fe814e55 ctx-e2685be8) We need to allocate new storagepool for this volume 2013-12-05 10:10:36,277 DEBUG [c.c.d.DeploymentPlanningManagerImpl] (Job-Executor-98:ctx-fe814e55 ctx-e2685be8) Calling StoragePoolAllocators to find suitable pools 2013-12-05 10:10:36,278 DEBUG [o.a.c.s.a.LocalStoragePoolAllocator] (Job-Executor-98:ctx-fe814e55 ctx-e2685be8) LocalStoragePoolAllocator trying to find storage pool to fit the vm 2013-12-05 10:10:36,278 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] (Job-Executor-98:ctx-fe814e55 ctx-e2685be8) ClusterScopeStoragePoolAllocator looking for storage pool 2013-12-05 10:10:36,278 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] (Job-Executor-98:ctx-fe814e55 ctx-e2685be8) Looking for pools in dc: 1 pod:1 cluster:1 having tags:[host1] 2013-12-05 10:10:36,282 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] (Job-Executor-98:ctx-fe814e55 ctx-e2685be8) No storage pools available for shared volume allocation, returning 2013-12-05 10:10:36,287 DEBUG [o.a.c.s.a.AbstractStoragePoolAllocator] (Job-Executor-98:ctx-fe814e55 ctx-e2685be8) List of pools in ascending order of number of volumes for account id: 683 is: [1, 4, 2] 2013-12-05 10:10:36,287 DEBUG [o.a.c.s.a.ZoneWideStoragePoolAllocator] (Job-Executor-98:ctx-fe814e55 ctx-e2685be8) ZoneWideStoragePoolAllocator to find storage pool 2013-12-05 10:10:36,290 DEBUG [o.a.c.s.a.ZoneWideStoragePoolAllocator] (Job-Executor-98:ctx-fe814e55 ctx-e2685be8) List of pools in ascending order of number of volumes for account id: 683 is: [] 2013-12-05 10:10:36,290 DEBUG [c.c.d.DeploymentPlanningManagerImpl] (Job-Executor-98:ctx-fe814e55 ctx-e2685be8) No suitable pools found for volume: Vol[1291|vm=1179|ROOT] under cluster: 1 2013-12-05 10:10:36,290 DEBUG [c.c.d.DeploymentPlanningManagerImpl] (Job-Executor-98:ctx-fe814e55 ctx-e2685be8) No suitable pools found 2013-12-05 10:10:36,291 DEBUG [c.c.d.DeploymentPlanningManagerImpl] (Job-Executor-98:ctx-fe814e55 ctx-e2685be8) No suitable storagePools found under this Cluster: 1 2013-12-05 10:10:36,294 DEBUG [c.c.d.DeploymentPlanningManagerImpl] (Job-Executor-98:ctx-fe814e55 ctx-e2685be8) Could not find suitable Deployment Destination for this VM under any clusters, returning. 2013-12-05 10:10:36,294 DEBUG [c.c.d.FirstFitPlanner] (Job-Executor-98:ctx-fe814e55 ctx-e2685be8) Searching all possible resources under this Zone: 1 2013-12-05 10:10:36,295 DEBUG [c.c.d.FirstFitPlanner] (Job-Executor-98:ctx-fe814e55 ctx-e2685be8) Listing clusters in order of aggregate capacity, that have (atleast one host with) enough CPU and RAM capacity under this Zone: 1 2013-12-05 10:10:36,298 DEBUG [c.c.d.FirstFitPlanner] (Job-Executor-98:ctx-fe814e55 ctx-e2685be8) Removing from the clusterId list these clusters from avoid set: [1] 2013-12-05 10:10:36,300 DEBUG [c.c.d.FirstFitPlanner] (Job-Executor-98:ctx-fe814e55 ctx-e2685be8) No clusters
[jira] [Updated] (CLOUDSTACK-5393) [Automation] Failed to create snapshot from ROOT volume in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-5393:
---
Assignee: Jayapal Reddy
[Automation] Failed to create snapshot from ROOT volume in KVM
--
Key: CLOUDSTACK-5393
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5393
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Snapshot
Affects Versions: 4.3.0
Environment: KVM (RHEL 6.3)
Branch : 4.3
Reporter: Rayees Namathponnan
Assignee: Jayapal Reddy
Fix For: 4.3.0
Attachments: agent1.rar, agent2.rar, management-server.rar, ssvm.rar
Steps to reproduce
1) Create advanced zone in KVM
2) Deploy VM
3 ) Stop VM
4 ) Create snapshot from root volume
Snapshot creation failed with below exception
2013-12-05 15:39:44,194 DEBUG [c.c.a.t.Request] (Job-Executor-64:ctx-1b710e00
ctx-3cf3df4e) Seq 1-1244399478: Received: { Ans: , MgmtId: 29066118877352,
via: 1, Ver: v1, Flags: 10, { CreateObjectAnswer } }
2013-12-05 15:39:44,284 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
(Job-Executor-64:ctx-1b710e00 ctx-3cf3df4e) copyAsync inspecting src type
SNAPSHOT copyAsync inspecting dest type SNAPSHOT
2013-12-05 15:39:44,332 DEBUG [c.c.a.t.Request] (Job-Executor-64:ctx-1b710e00
ctx-3cf3df4e) Seq 2-332864214: Sending { Cmd , MgmtId: 29066118877352, via:
2(Rack2Host12.lab.vmops.com), Ver: v1, Flags: 100011, [{org.apache.cl
oudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:/mnt/fff90cb5-06dd-33b3-8815-d78c08ca01d9/a44ddf93-9fa2-497f-aff6-cf4951128215/8f7d268f-1a96-4d70-9c48-cb7f6cc935a8
,volume:{uuid:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesyst
em,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08
ca01d9}},name:ROOT-919,size:8589934592,path:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeId:988,vmName:i-2-919-QA,accountId:2,format:QCOW2,id:988,deviceId:0,hypervisorType:KVM},parentSnapshotPath
:/mnt/fff90cb5-06dd-33b3-8815-d78c08ca01d9/a44ddf93-9fa2-497f-aff6-cf4951128215/d43b61bc-4ade-4753-b1d9-c0398388147d,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08ca01d9}},vmName:i-2-919-QA,name:QA-eb54bbfa-12d5-49b5-808f-864dddedc1fd_ROOT-919_20131205233943,hypervisorType:KVM,id:54,quiescevm:false}},destTO:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:snapshots/2/988,volume:{uuid:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08ca01d9}},name:ROOT-919,size:8589934592,path:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeId:988,vmName:i-2-919-QA,accountId:2,format:QCOW2,id:988,deviceId:0,hypervisorType:KVM},dataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.223.110.232:/export/home/rayees/SC_QA_AUTO4/secondary,_role:Image}},vmName:i-2-919-QA,name:QA-eb54bbfa-12d5-49b5-808f-864dddedc1fd_ROOT-919_20131205233943,hypervisorType:KVM,id:54,quiescevm:false}},executeInSequence:false,wait:21600}}]
}
2013-12-05 15:39:44,501 DEBUG [c.c.a.t.Request]
(StatsCollector-3:ctx-3ac54662) Seq 1-1244399477: Received: { Ans: , MgmtId:
29066118877352, via: 1, Ver: v1, Flags: 10, { GetVmStatsAnswer } }
2013-12-05 15:39:44,900 DEBUG [c.c.a.t.Request] (AgentManager-Handler-1:null)
Seq 2-332864214: Processing: { Ans: , MgmtId: 29066118877352, via: 2, Ver:
v1, Flags: 10,
[{org.apache.cloudstack.storage.command.CopyCmdAnswer:{result:false,details:/usr/share/cloudstack-common/scripts/storage/qcow2/managesnapshot.sh:
line 178: 26840 Floating point exception(core dumped) $qemu_img convert -f
qcow2 -O qcow2 -s $snapshotname $disk $destPath/$destName /dev/nullFailed
to backup 8f7d268f-1a96-4d70-9c48-cb7f6cc935a8 for disk
/mnt/fff90cb5-06dd-33b3-8815-d78c08ca01d9/a44ddf93-9fa2-497f-aff6-cf4951128215
to
[jira] [Commented] (CLOUDSTACK-5393) [Automation] Failed to create snapshot from ROOT volume in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843657#comment-13843657
]
Animesh Chaturvedi commented on CLOUDSTACK-5393:
Jayapal can you check this issue?
[Automation] Failed to create snapshot from ROOT volume in KVM
--
Key: CLOUDSTACK-5393
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5393
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Snapshot
Affects Versions: 4.3.0
Environment: KVM (RHEL 6.3)
Branch : 4.3
Reporter: Rayees Namathponnan
Assignee: Jayapal Reddy
Fix For: 4.3.0
Attachments: agent1.rar, agent2.rar, management-server.rar, ssvm.rar
Steps to reproduce
1) Create advanced zone in KVM
2) Deploy VM
3 ) Stop VM
4 ) Create snapshot from root volume
Snapshot creation failed with below exception
2013-12-05 15:39:44,194 DEBUG [c.c.a.t.Request] (Job-Executor-64:ctx-1b710e00
ctx-3cf3df4e) Seq 1-1244399478: Received: { Ans: , MgmtId: 29066118877352,
via: 1, Ver: v1, Flags: 10, { CreateObjectAnswer } }
2013-12-05 15:39:44,284 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
(Job-Executor-64:ctx-1b710e00 ctx-3cf3df4e) copyAsync inspecting src type
SNAPSHOT copyAsync inspecting dest type SNAPSHOT
2013-12-05 15:39:44,332 DEBUG [c.c.a.t.Request] (Job-Executor-64:ctx-1b710e00
ctx-3cf3df4e) Seq 2-332864214: Sending { Cmd , MgmtId: 29066118877352, via:
2(Rack2Host12.lab.vmops.com), Ver: v1, Flags: 100011, [{org.apache.cl
oudstack.storage.command.CopyCommand:{srcTO:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:/mnt/fff90cb5-06dd-33b3-8815-d78c08ca01d9/a44ddf93-9fa2-497f-aff6-cf4951128215/8f7d268f-1a96-4d70-9c48-cb7f6cc935a8
,volume:{uuid:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesyst
em,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08
ca01d9}},name:ROOT-919,size:8589934592,path:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeId:988,vmName:i-2-919-QA,accountId:2,format:QCOW2,id:988,deviceId:0,hypervisorType:KVM},parentSnapshotPath
:/mnt/fff90cb5-06dd-33b3-8815-d78c08ca01d9/a44ddf93-9fa2-497f-aff6-cf4951128215/d43b61bc-4ade-4753-b1d9-c0398388147d,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08ca01d9}},vmName:i-2-919-QA,name:QA-eb54bbfa-12d5-49b5-808f-864dddedc1fd_ROOT-919_20131205233943,hypervisorType:KVM,id:54,quiescevm:false}},destTO:{org.apache.cloudstack.storage.to.SnapshotObjectTO:{path:snapshots/2/988,volume:{uuid:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:fff90cb5-06dd-33b3-8815-d78c08ca01d9,id:1,poolType:NetworkFilesystem,host:10.223.110.232,path:/export/home/rayees/SC_QA_AUTO4/primary,port:2049,url:NetworkFilesystem://10.223.110.232//export/home/rayees/SC_QA_AUTO4/primary/?ROLE=PrimarySTOREUUID=fff90cb5-06dd-33b3-8815-d78c08ca01d9}},name:ROOT-919,size:8589934592,path:a44ddf93-9fa2-497f-aff6-cf4951128215,volumeId:988,vmName:i-2-919-QA,accountId:2,format:QCOW2,id:988,deviceId:0,hypervisorType:KVM},dataStore:{com.cloud.agent.api.to.NfsTO:{_url:nfs://10.223.110.232:/export/home/rayees/SC_QA_AUTO4/secondary,_role:Image}},vmName:i-2-919-QA,name:QA-eb54bbfa-12d5-49b5-808f-864dddedc1fd_ROOT-919_20131205233943,hypervisorType:KVM,id:54,quiescevm:false}},executeInSequence:false,wait:21600}}]
}
2013-12-05 15:39:44,501 DEBUG [c.c.a.t.Request]
(StatsCollector-3:ctx-3ac54662) Seq 1-1244399477: Received: { Ans: , MgmtId:
29066118877352, via: 1, Ver: v1, Flags: 10, { GetVmStatsAnswer } }
2013-12-05 15:39:44,900 DEBUG [c.c.a.t.Request] (AgentManager-Handler-1:null)
Seq 2-332864214: Processing: { Ans: , MgmtId: 29066118877352, via: 2, Ver:
v1, Flags: 10,
[{org.apache.cloudstack.storage.command.CopyCmdAnswer:{result:false,details:/usr/share/cloudstack-common/scripts/storage/qcow2/managesnapshot.sh:
line 178: 26840 Floating point exception(core dumped) $qemu_img convert -f
qcow2 -O qcow2 -s $snapshotname $disk $destPath/$destName /dev/nullFailed
to backup 8f7d268f-1a96-4d70-9c48-cb7f6cc935a8 for disk
[jira] [Resolved] (CLOUDSTACK-4542) [Automation] Failed to apply DHCP entry in VR and deployment failed
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi resolved CLOUDSTACK-4542.
Resolution: Cannot Reproduce
Rayees reopen if this you can reproduce again
[Automation] Failed to apply DHCP entry in VR and deployment failed
Key: CLOUDSTACK-4542
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4542
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.2.0
Environment: 4.2-forward
Automation environment on KVM
Reporter: Rayees Namathponnan
Assignee: Sheng Yang
Fix For: 4.3.0
Attachments: BVT_KVM_Sep_27.rar, KVM_Regression_28_Aug_Agent.rar,
KVM_Regression_28_Aug_MS.rar
This issue found in automation run, observed while running the test case
integration.component.test_vpc_vms_deployment.TestVMDeployVPC.test_02_deploy_vms_delete_network
Router failed to apply DHCP entry then router deployment reported as failed
Observed below error in MS log, attached log search for r-183-QA
2013-08-27 22:56:30,877 DEBUG [agent.transport.Request]
(AgentManager-Handler-4:null) Seq 2-654837610: Processing: { Ans: , MgmtId:
29066118877352, via: 2, Ver: v1, Flags: 110,
[{com.cloud.agent.api.Answer:{result:false,details:ssh: connect to
host 169.254.1.219 port 3922: Connection timed out,wait:0}}] }
2013-08-27 22:56:30,877 DEBUG [agent.manager.AgentAttache]
(AgentManager-Handler-4:null) Seq 2-654837611: Sending now. is current
sequence.
2013-08-27 22:56:30,877 DEBUG [agent.transport.Request]
(Job-Executor-84:job-806 = [ 558e7c87-b3fb-444e-b5e9-85c3789a1318 ]) Seq
2-654837610: Received: { Ans: , MgmtId: 29066118877352, via: 2, Ver: v1,
Flags: 110, { Answer } }
2013-08-27 22:56:30,878 INFO [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-84:job-806 = [ 558e7c87-b3fb-444e-b5e9-85c3789a1318 ]) Unable
to contact resource.
com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is
unreachable: Unable to apply dhcp entry on router
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:3808)
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyDhcpEntry(VirtualNetworkApplianceManagerImpl.java:2919)
at
com.cloud.network.element.VirtualRouterElement.addDhcpEntry(VirtualRouterElement.java:898)
at
com.cloud.network.NetworkManagerImpl.prepareElement(NetworkManagerImpl.java:2070)
at
com.cloud.network.NetworkManagerImpl.prepareNic(NetworkManagerImpl.java:2191)
at
com.cloud.network.NetworkManagerImpl.prepare(NetworkManagerImpl.java:2127)
at
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:886)
at
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:578)
at
org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:227)
at
org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209)
at
com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3406)
at
com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2966)
at
com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2952)
at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at
org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:420)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
at
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
2013-08-27 22:56:30,882 DEBUG [cloud.vm.VirtualMachineManagerImpl]
(Job-Executor-84:job-806 = [ 558e7c87-b3fb-444e-b5e9-85c3789a1318 ]) Cleaning
up resources for the vm VM[User|df06b516-d40a-4dfa-9b77-4612bed9660e] in
Starting state
2013-08-27 22:56:30,883 DEBUG [agent.transport.Request]
(Job-Executor-84:job-806 = [ 558e7c87-b3fb-444e-b5e9-85c3789a1318 ]) Seq
[jira] [Resolved] (CLOUDSTACK-5295) [Automation] Router deployment failed with null pointer exception, while calling VirtualNetworkApplianceManagerImpl.getVpnCidr
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi resolved CLOUDSTACK-5295. Resolution: Fixed Rayees reopen if this is still an issue [Automation] Router deployment failed with null pointer exception, while calling VirtualNetworkApplianceManagerImpl.getVpnCidr --- Key: CLOUDSTACK-5295 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5295 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Rayees Namathponnan Assignee: Sheng Yang Priority: Blocker Fix For: 4.3.0 Attachments: agent1.rar, agent2.rar, management-server.log.2013-11-26.gz, management-server.rar This issue observed in autoamtion environment; many router deployment failed below error 2013-11-27 02:34:02,194 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Sending network shutdown to VirtualRouter 2013-11-27 02:34:02,196 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Stopping router VM[DomainRouter|r-586-QA] 2013-11-27 02:34:02,198 DEBUG [c.c.v.VirtualMachineManagerImpl] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) VM is already stopped: VM[DomainRouter|r-586-QA] 2013-11-27 02:34:02,200 DEBUG [c.c.a.ApiServlet] (catalina-exec-7:ctx-436ed958) ===START=== 10.223.240.194 -- GET signature=DFJW4CnPHf9BbR%2BTYevb%2FA8%2BZpM%3DapiKey=1fASWWJnTkiQdjWWd9ex6s pm2-D7xsAQvkXh8vBMHIay-aW6dYeUqWsBoAcK-jkfQKPvBaDJLQDEDra4cfGfaAcommand=queryAsyncJobResultresponse=jsonjobid=cb269b12-6c73-44dd-82aa-1303bf3d33fb 2013-11-27 02:34:02,204 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Network id=489 is shutdown successfully, cleaning up corresponding resources now. 2013-11-27 02:34:02,209 DEBUG [c.c.n.g.GuestNetworkGuru] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Releasing vnet for the network id=489 2013-11-27 02:34:02,221 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Lock is released for network Ntwk[489|Guest|8] as a part of network shutdown 2013-11-27 02:34:02,222 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Lock is released for network id 489 as a part of network implement 2013-11-27 02:34:02,222 INFO [c.c.v.VirtualMachineManagerImpl] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Unable to contact resource. com.cloud.exception.AgentUnavailableException: Resource [Host:2] is unreachable: Host 2: Unable to start instance due to null at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1011) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:706) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.start(VirtualNetworkApplianceManagerImpl.java:2667) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startVirtualRouter(VirtualNetworkApplianceManagerImpl.java:1767) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startRouters(VirtualNetworkApplianceManagerImpl.java:1867) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.deployVirtualRouterInGuestNetwork(VirtualNetworkApplianceManagerImpl.java:1845) at sun.reflect.GeneratedMethodAccessor300.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetwork(NetworkOrchestrator.java:960) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1222) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:899) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:706) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:552) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:227) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3465) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3046) at
[jira] [Resolved] (CLOUDSTACK-5295) [Automation] Router deployment failed with null pointer exception, while calling VirtualNetworkApplianceManagerImpl.getVpnCidr
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi resolved CLOUDSTACK-5295. Resolution: Cannot Reproduce [Automation] Router deployment failed with null pointer exception, while calling VirtualNetworkApplianceManagerImpl.getVpnCidr --- Key: CLOUDSTACK-5295 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5295 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Rayees Namathponnan Assignee: Sheng Yang Priority: Blocker Fix For: 4.3.0 Attachments: agent1.rar, agent2.rar, management-server.log.2013-11-26.gz, management-server.rar This issue observed in autoamtion environment; many router deployment failed below error 2013-11-27 02:34:02,194 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Sending network shutdown to VirtualRouter 2013-11-27 02:34:02,196 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Stopping router VM[DomainRouter|r-586-QA] 2013-11-27 02:34:02,198 DEBUG [c.c.v.VirtualMachineManagerImpl] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) VM is already stopped: VM[DomainRouter|r-586-QA] 2013-11-27 02:34:02,200 DEBUG [c.c.a.ApiServlet] (catalina-exec-7:ctx-436ed958) ===START=== 10.223.240.194 -- GET signature=DFJW4CnPHf9BbR%2BTYevb%2FA8%2BZpM%3DapiKey=1fASWWJnTkiQdjWWd9ex6s pm2-D7xsAQvkXh8vBMHIay-aW6dYeUqWsBoAcK-jkfQKPvBaDJLQDEDra4cfGfaAcommand=queryAsyncJobResultresponse=jsonjobid=cb269b12-6c73-44dd-82aa-1303bf3d33fb 2013-11-27 02:34:02,204 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Network id=489 is shutdown successfully, cleaning up corresponding resources now. 2013-11-27 02:34:02,209 DEBUG [c.c.n.g.GuestNetworkGuru] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Releasing vnet for the network id=489 2013-11-27 02:34:02,221 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Lock is released for network Ntwk[489|Guest|8] as a part of network shutdown 2013-11-27 02:34:02,222 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Lock is released for network id 489 as a part of network implement 2013-11-27 02:34:02,222 INFO [c.c.v.VirtualMachineManagerImpl] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Unable to contact resource. com.cloud.exception.AgentUnavailableException: Resource [Host:2] is unreachable: Host 2: Unable to start instance due to null at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1011) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:706) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.start(VirtualNetworkApplianceManagerImpl.java:2667) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startVirtualRouter(VirtualNetworkApplianceManagerImpl.java:1767) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startRouters(VirtualNetworkApplianceManagerImpl.java:1867) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.deployVirtualRouterInGuestNetwork(VirtualNetworkApplianceManagerImpl.java:1845) at sun.reflect.GeneratedMethodAccessor300.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetwork(NetworkOrchestrator.java:960) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1222) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:899) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:706) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:552) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:227) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3465) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3046) at
[jira] [Reopened] (CLOUDSTACK-5295) [Automation] Router deployment failed with null pointer exception, while calling VirtualNetworkApplianceManagerImpl.getVpnCidr
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi reopened CLOUDSTACK-5295: [Automation] Router deployment failed with null pointer exception, while calling VirtualNetworkApplianceManagerImpl.getVpnCidr --- Key: CLOUDSTACK-5295 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5295 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Rayees Namathponnan Assignee: Sheng Yang Priority: Blocker Fix For: 4.3.0 Attachments: agent1.rar, agent2.rar, management-server.log.2013-11-26.gz, management-server.rar This issue observed in autoamtion environment; many router deployment failed below error 2013-11-27 02:34:02,194 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Sending network shutdown to VirtualRouter 2013-11-27 02:34:02,196 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Stopping router VM[DomainRouter|r-586-QA] 2013-11-27 02:34:02,198 DEBUG [c.c.v.VirtualMachineManagerImpl] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) VM is already stopped: VM[DomainRouter|r-586-QA] 2013-11-27 02:34:02,200 DEBUG [c.c.a.ApiServlet] (catalina-exec-7:ctx-436ed958) ===START=== 10.223.240.194 -- GET signature=DFJW4CnPHf9BbR%2BTYevb%2FA8%2BZpM%3DapiKey=1fASWWJnTkiQdjWWd9ex6s pm2-D7xsAQvkXh8vBMHIay-aW6dYeUqWsBoAcK-jkfQKPvBaDJLQDEDra4cfGfaAcommand=queryAsyncJobResultresponse=jsonjobid=cb269b12-6c73-44dd-82aa-1303bf3d33fb 2013-11-27 02:34:02,204 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Network id=489 is shutdown successfully, cleaning up corresponding resources now. 2013-11-27 02:34:02,209 DEBUG [c.c.n.g.GuestNetworkGuru] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Releasing vnet for the network id=489 2013-11-27 02:34:02,221 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Lock is released for network Ntwk[489|Guest|8] as a part of network shutdown 2013-11-27 02:34:02,222 DEBUG [o.a.c.e.o.NetworkOrchestrator] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Lock is released for network id 489 as a part of network implement 2013-11-27 02:34:02,222 INFO [c.c.v.VirtualMachineManagerImpl] (Job-Executor-36:ctx-73116225 ctx-d59c6c54) Unable to contact resource. com.cloud.exception.AgentUnavailableException: Resource [Host:2] is unreachable: Host 2: Unable to start instance due to null at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1011) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:706) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.start(VirtualNetworkApplianceManagerImpl.java:2667) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startVirtualRouter(VirtualNetworkApplianceManagerImpl.java:1767) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startRouters(VirtualNetworkApplianceManagerImpl.java:1867) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.deployVirtualRouterInGuestNetwork(VirtualNetworkApplianceManagerImpl.java:1845) at sun.reflect.GeneratedMethodAccessor300.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.implementNetwork(NetworkOrchestrator.java:960) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1222) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:899) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:706) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:552) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:227) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3465) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3046) at
[jira] [Closed] (CLOUDSTACK-4952) [event framework] The topic grammar - eventSource.eventCategory.eventType.resourceType.resourceUuid is incorrect, eventType.resourceType should swap
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti closed CLOUDSTACK-4952. [event framework] The topic grammar - eventSource.eventCategory.eventType.resourceType.resourceUuid is incorrect, eventType.resourceType should swap - Key: CLOUDSTACK-4952 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4952 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Nitin Mehta Fix For: 4.3.0 -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-3664) scaling up vms is not considering parameter cluster.(memory/cpu).allocated.capacity.disablethreshold
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843666#comment-13843666 ] ASF subversion and git services commented on CLOUDSTACK-3664: - Commit ebbc9292f3530d060dfab2de376307a810ce01e6 in branch refs/heads/4.3 from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ebbc929 ] CLOUDSTACK-3664: scaling up vms was not considering parameter cluster.(memory/cpu).allocated.capacity.disablethreshold. Fixed it Also added overprovisioning factor retrieval at the cluster level for host capacity check scaling up vms is not considering parameter cluster.(memory/cpu).allocated.capacity.disablethreshold --- Key: CLOUDSTACK-3664 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3664 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Environment: xen 4.2 Reporter: prashant kumar mishra Assignee: Nitin Mehta Fix For: 4.3.0 Attachments: Logs_DB.rar, screenshot-1.jpg steps to reproduce 1-prepare a CS setup with xen 6.1 2-set cluster.memory.allocated.capacity.disablethreshold to some lower value say 0.2 3-deploy some vms until unless deployment fails because of threshold value. 4-Try to scale up vms Expected -- scaling up should get failed because threshold value Actual -- scaling up is successful DB mysql select *from cluster_details; ++++---+ | id | cluster_id | name | value | ++++---+ | 1 | 1 | cpuOvercommitRatio | 1.0 | | 2 | 1 | memoryOvercommitRatio | 1.0 | | 3 | 1 | cluster.memory.allocated.capacity.disablethreshold | 0.2 | ++++---+ -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Closed] (CLOUDSTACK-3281) StartCommand carries VolumeObjectTO with format field of NULL
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Lafferty closed CLOUDSTACK-3281.
--
Verified correct operation with integration test that involved creating a
Hyper-V zone.
StartCommand carries VolumeObjectTO with format field of NULL
-
Key: CLOUDSTACK-3281
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3281
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller
Affects Versions: Future
Environment: Hyper-V cluster
Reporter: Donal Lafferty
Assignee: Devdeep Singh
Labels: hyper-V,
Fix For: 4.3.0
Disk image format is missing from VolumeObjectTO in StartCommand. Not clear
whether Hypervisor needs to set this in the CopyCmdAnswer returned when the
volume is created, if the hypervisor is never to use the format when looking
up an image or if there is a bug in the system.
Sample command:
{
vm: {
id: 2,
name: v-2-VM,
type: ConsoleProxy,
cpus: 1,
minSpeed: 500,
maxSpeed: 500,
minRam: 1073741824,
maxRam: 1073741824,
arch: i686,
os: Debian GNU/Linux 5.0 (32-bit),
bootArgs: template=domP type=consoleproxy host=10.80.3.83 port=8250
name=v-2-VM premium=true zone=1 pod=1 guid=Proxy.2 proxy_vm=2
disable_rp_filter=true eth2ip=10.70.176.125 eth2mask=255.255.240.0
gateway=10.70.176.1 eth0ip=169.254.1.121 eth0mask=255.255.0.0
eth1ip=10.70.176.96 eth1mask=255.255.240.0 mgmtcidr=10.80.2.0/23
localgw=10.70.176.1 internaldns1=10.70.176.118 internaldns2=10.70.160.66
dns1=4.4.4.4,
rebootOnCrash: false,
enableHA: false,
limitCpuUse: false,
enableDynamicallyScaleVm: false,
vncPassword: ce12c56d3290de94,
params: {},
uuid: 89384857-b45d-47c0-8c7e-b011b0fcb118,
disks: [
{
data: {
org.apache.cloudstack.storage.to.VolumeObjectTO: {
uuid: 35a079e4-7767-47d1-8629-72d32c866a08,
volumeType: ROOT,
dataStore: {
org.apache.cloudstack.storage.to.PrimaryDataStoreTO: {
uuid: 700b99d8-36e7-3f0c-b362-44f1c773241b-HypervResource,
id: 1,
poolType: Filesystem,
host: 10.70.176.29,
path: E:\\Disks\\,
port: 0
}
},
name: ROOT-2,
size: 140616708,
volumeId: 2,
vmName: v-2-VM,
accountId: 1,
id: 2
}
},
diskSeq: 0,
type: ROOT
}
],
nics: [
{
deviceId: 2,
networkRateMbps: -1,
defaultNic: true,
uuid: 022f8487-aba2-441b-85dd-3a68c3614fec,
ip: 10.70.176.125,
netmask: 255.255.240.0,
gateway: 10.70.176.1,
mac: 06:9d:26:00:00:0c,
dns1: 4.4.4.4,
broadcastType: Vlan,
type: Public,
broadcastUri: vlan://untagged,
isolationUri: vlan://untagged,
isSecurityGroupEnabled: false
},
{
deviceId: 0,
networkRateMbps: -1,
defaultNic: false,
uuid: 4fbb6713-de1e-4930-a944-6b5685c4ac62,
ip: 169.254.1.121,
netmask: 255.255.0.0,
gateway: 169.254.0.1,
mac: 0e:00:a9:fe:01:79,
broadcastType: LinkLocal,
type: Control,
isSecurityGroupEnabled: false
},
{
deviceId: 1,
networkRateMbps: -1,
defaultNic: false,
uuid: 2eeefa17-429e-47a5-bf41-bfa4742b712c,
ip: 10.70.176.96,
netmask: 255.255.240.0,
gateway: 10.70.176.1,
mac: 06:26:ae:00:00:07,
broadcastType: Native,
type: Management,
isSecurityGroupEnabled: false
}
]
},
hostIp: 10.70.176.29,
executeInSequence: false,
contextMap: {},
wait: 0
}
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-4428) [UI] kvm.snapshot.enabled flag should be taken to account only when snapshot is being created for Running vm
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843684#comment-13843684 ] ASF subversion and git services commented on CLOUDSTACK-4428: - Commit 1db19c3d52ae028a17c724ad85a2c6a07050893c in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1db19c3 ] CLOUDSTACK-4428: KVMsnapshoteanbled property in listCapabilities API response has been renamed. Here is corresponding UI change. [UI] kvm.snapshot.enabled flag should be taken to account only when snapshot is being created for Running vm -- Key: CLOUDSTACK-4428 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4428 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: Alena Prokharchyk Assignee: Jessica Wang Priority: Critical Fix For: 4.3.0 Attachments: snapshot.png We used to have a problem for KVM snapshot creation when createSnapshot is called for the volume of the Running vm. As a fix for that, kvm.snapshot.enabled flag was introduced. But when this flag set to fase, it doesn't allow snapshot creation even for detached volumes (the area where the problem didn't even exist). Suggested fix: kvm.snapshot.enabled should affect only case when the snapshot is being created for the volume a) that is attached to the vm b) the vm is running/starting/stopping states only -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-4428) [UI] kvm.snapshot.enabled flag should be taken to account only when snapshot is being created for Running vm
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843683#comment-13843683 ] ASF subversion and git services commented on CLOUDSTACK-4428: - Commit 409cbd4c7abff2a982fdced36f21e7ca5d5f5629 in branch refs/heads/4.3 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=409cbd4 ] CLOUDSTACK-4428: KVMsnapshoteanbled property in listCapabilities API response has been renamed. Here is corresponding UI change. [UI] kvm.snapshot.enabled flag should be taken to account only when snapshot is being created for Running vm -- Key: CLOUDSTACK-4428 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4428 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: Alena Prokharchyk Assignee: Jessica Wang Priority: Critical Fix For: 4.3.0 Attachments: snapshot.png We used to have a problem for KVM snapshot creation when createSnapshot is called for the volume of the Running vm. As a fix for that, kvm.snapshot.enabled flag was introduced. But when this flag set to fase, it doesn't allow snapshot creation even for detached volumes (the area where the problem didn't even exist). Suggested fix: kvm.snapshot.enabled should affect only case when the snapshot is being created for the volume a) that is attached to the vm b) the vm is running/starting/stopping states only -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5425) Egress firewall rules are broken in the Palo Alto plugin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Stevens updated CLOUDSTACK-5425: - Attachment: fixed-egress-rules-master.patch This is the same patch as the other, but for master branch instead of 4.3 Egress firewall rules are broken in the Palo Alto plugin Key: CLOUDSTACK-5425 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5425 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Will Stevens Assignee: Will Stevens Priority: Critical Fix For: 4.3.0 Attachments: fixed-egress-rules-master.patch, fixed-egress-rules.patch The introduction of the ability to setup a default egress firewall rule in the network service offering broke the Palo Alto plugin. This bug/patch fixes the issues with egress rules in the Palo Alto plugin. In addition, I have removed API commands that I had implemented which are not needed... eg: addExternalFirewall deleteExternalFirewall listExternalFirewalls -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Comment Edited] (CLOUDSTACK-5425) Egress firewall rules are broken in the Palo Alto plugin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843692#comment-13843692 ] Will Stevens edited comment on CLOUDSTACK-5425 at 12/9/13 11:33 PM: This is the same patch as the other, but for master branch instead of 4.3 4.3 branch: fixed-egress-rules.patch master: fixed-egress-rules-master.patch was (Author: wstevens): This is the same patch as the other, but for master branch instead of 4.3 Egress firewall rules are broken in the Palo Alto plugin Key: CLOUDSTACK-5425 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5425 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Will Stevens Assignee: Will Stevens Priority: Critical Fix For: 4.3.0 Attachments: fixed-egress-rules-master.patch, fixed-egress-rules.patch The introduction of the ability to setup a default egress firewall rule in the network service offering broke the Palo Alto plugin. This bug/patch fixes the issues with egress rules in the Palo Alto plugin. In addition, I have removed API commands that I had implemented which are not needed... eg: addExternalFirewall deleteExternalFirewall listExternalFirewalls -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5426) Cannot deploy instance having multiple volumes that use different storage tags for storage pools in same cluster
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843700#comment-13843700 ] ASF subversion and git services commented on CLOUDSTACK-5426: - Commit 5618a44ed0089e43ec24847b0b7db5c7e754fdb7 in branch refs/heads/master from [~prachidamle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5618a44 ] CLOUDSTACK-5426: Cannot deploy instance having multiple volumes that use different storage tags for storage pools in same cluster Changes: - We need to reset the avoid set to its original state while calling the storage pool allocators for each volume. - This will prevent affecting allocation of the disks due to the avoid set output of the prior disk allocations. Conflicts: server/src/com/cloud/deploy/DeploymentPlanningManagerImpl.java Cannot deploy instance having multiple volumes that use different storage tags for storage pools in same cluster Key: CLOUDSTACK-5426 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5426 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0, 4.2.1, 4.3.0 Reporter: Prachi Damle Assignee: Prachi Damle Priority: Critical Fix For: 4.3.0 This issue can be observed when VM being deployed has multiple volumes (=2) where 2 adjacent volumes are to be created with 2 different disk offerings with different storage tags. Ex: 1. VM1 has 2 volumes root volume 1 data volume. 2. root volume is to be created using a disk offering with storage tag 'root_disk' 3. data volume is to be created using a disk offering with storage tag 'data_disk' 4. There exists a cluster wide storage pool suitable for root volume with storage tag 'root_disk' 5. There exists a cluster wide storage pool suitable for data volume with storage tag 'data_disk' The deploy VM fails in this case. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5426) Cannot deploy instance having multiple volumes that use different storage tags for storage pools in same cluster
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843701#comment-13843701 ] ASF subversion and git services commented on CLOUDSTACK-5426: - Commit 4a9da0376046bb5eb5dcf67c3e2c4cb7501dc5f8 in branch refs/heads/master from [~prachidamle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4a9da03 ] CLOUDSTACK-5426 Cannot deploy instance having multiple volumes that use different storage tags for storage pools in same cluster Fixing the Imports missing Cannot deploy instance having multiple volumes that use different storage tags for storage pools in same cluster Key: CLOUDSTACK-5426 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5426 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0, 4.2.1, 4.3.0 Reporter: Prachi Damle Assignee: Prachi Damle Priority: Critical Fix For: 4.3.0 This issue can be observed when VM being deployed has multiple volumes (=2) where 2 adjacent volumes are to be created with 2 different disk offerings with different storage tags. Ex: 1. VM1 has 2 volumes root volume 1 data volume. 2. root volume is to be created using a disk offering with storage tag 'root_disk' 3. data volume is to be created using a disk offering with storage tag 'data_disk' 4. There exists a cluster wide storage pool suitable for root volume with storage tag 'root_disk' 5. There exists a cluster wide storage pool suitable for data volume with storage tag 'data_disk' The deploy VM fails in this case. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-3664) scaling up vms is not considering parameter cluster.(memory/cpu).allocated.capacity.disablethreshold
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta resolved CLOUDSTACK-3664. - Resolution: Fixed scaling up vms is not considering parameter cluster.(memory/cpu).allocated.capacity.disablethreshold --- Key: CLOUDSTACK-3664 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3664 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Environment: xen 4.2 Reporter: prashant kumar mishra Assignee: Nitin Mehta Fix For: 4.3.0 Attachments: Logs_DB.rar, screenshot-1.jpg steps to reproduce 1-prepare a CS setup with xen 6.1 2-set cluster.memory.allocated.capacity.disablethreshold to some lower value say 0.2 3-deploy some vms until unless deployment fails because of threshold value. 4-Try to scale up vms Expected -- scaling up should get failed because threshold value Actual -- scaling up is successful DB mysql select *from cluster_details; ++++---+ | id | cluster_id | name | value | ++++---+ | 1 | 1 | cpuOvercommitRatio | 1.0 | | 2 | 1 | memoryOvercommitRatio | 1.0 | | 3 | 1 | cluster.memory.allocated.capacity.disablethreshold | 0.2 | ++++---+ -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-3664) scaling up vms is not considering parameter cluster.(memory/cpu).allocated.capacity.disablethreshold
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta updated CLOUDSTACK-3664: Priority: Critical (was: Major) scaling up vms is not considering parameter cluster.(memory/cpu).allocated.capacity.disablethreshold --- Key: CLOUDSTACK-3664 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3664 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Environment: xen 4.2 Reporter: prashant kumar mishra Assignee: Nitin Mehta Priority: Critical Fix For: 4.3.0 Attachments: Logs_DB.rar, screenshot-1.jpg steps to reproduce 1-prepare a CS setup with xen 6.1 2-set cluster.memory.allocated.capacity.disablethreshold to some lower value say 0.2 3-deploy some vms until unless deployment fails because of threshold value. 4-Try to scale up vms Expected -- scaling up should get failed because threshold value Actual -- scaling up is successful DB mysql select *from cluster_details; ++++---+ | id | cluster_id | name | value | ++++---+ | 1 | 1 | cpuOvercommitRatio | 1.0 | | 2 | 1 | memoryOvercommitRatio | 1.0 | | 3 | 1 | cluster.memory.allocated.capacity.disablethreshold | 0.2 | ++++---+ -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-3664) scaling up vms is not considering parameter cluster.(memory/cpu).allocated.capacity.disablethreshold
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843703#comment-13843703 ] ASF subversion and git services commented on CLOUDSTACK-3664: - Commit e79350d256cbd2bb64393ddae453c815b5a68339 in branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e79350d ] CLOUDSTACK-3664: scaling up vms was not considering parameter cluster.(memory/cpu).allocated.capacity.disablethreshold. Fixed it Also added overprovisioning factor retrieval at the cluster level for host capacity check scaling up vms is not considering parameter cluster.(memory/cpu).allocated.capacity.disablethreshold --- Key: CLOUDSTACK-3664 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3664 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Environment: xen 4.2 Reporter: prashant kumar mishra Assignee: Nitin Mehta Fix For: 4.3.0 Attachments: Logs_DB.rar, screenshot-1.jpg steps to reproduce 1-prepare a CS setup with xen 6.1 2-set cluster.memory.allocated.capacity.disablethreshold to some lower value say 0.2 3-deploy some vms until unless deployment fails because of threshold value. 4-Try to scale up vms Expected -- scaling up should get failed because threshold value Actual -- scaling up is successful DB mysql select *from cluster_details; ++++---+ | id | cluster_id | name | value | ++++---+ | 1 | 1 | cpuOvercommitRatio | 1.0 | | 2 | 1 | memoryOvercommitRatio | 1.0 | | 3 | 1 | cluster.memory.allocated.capacity.disablethreshold | 0.2 | ++++---+ -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5427) Scaling vm and trying to scale to same host not considering overprovisioning ratios for cluster
Nitin Mehta created CLOUDSTACK-5427: --- Summary: Scaling vm and trying to scale to same host not considering overprovisioning ratios for cluster Key: CLOUDSTACK-5427 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5427 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Priority: Critical Fix For: 4.3.0 Scaling vm and trying to scale to same host is not considering overprovisioning ratios for cluster -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5427) Scaling vm and trying to scale to same host not considering overprovisioning ratios for cluster
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta resolved CLOUDSTACK-5427. - Resolution: Fixed Scaling vm and trying to scale to same host not considering overprovisioning ratios for cluster --- Key: CLOUDSTACK-5427 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5427 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Priority: Critical Fix For: 4.3.0 Scaling vm and trying to scale to same host is not considering overprovisioning ratios for cluster -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5098) [UI] Zone view is showing Add VMware Datacenter button even though zone is already associated with a data center
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843708#comment-13843708
]
Jessica Wang commented on CLOUDSTACK-5098:
--
Sateesh,
I just checked your URL(http://10.102.192.116:8080/client/).
“Add Vmware Datacenter” button shows because your zone doesn’t have any cluster
that has VMware hypervisor:
http://10.102.192.116:8080/client/api?command=listClustersresponse=jsonsessionkey=3y9FPkRcJRQ6qQanKKaX2c5fa%2Bo%3Dzoneid=f78cee8c-955a-4b72-95d1-b7360f9e4754_=1386631596006
{ listclustersresponse : { } }
So, UI doesn’t call listVmwareDcs API at all.
UI only calls listVmwareDcs API when listClusters API response includes a
cluster(or clusters) that has VMware hypervisor.
Because when listClusters API response does not include any cluster that has
VMware hypervisor, UI will presume the zone does not use VMware, therefore,
there is no reason to call listVmwareDcs API.
Jessica
[UI] Zone view is showing Add VMware Datacenter button even though zone is
already associated with a data center
--
Key: CLOUDSTACK-5098
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5098
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API
Affects Versions: 4.2.1
Reporter: Sailaja Mada
Assignee: Jessica Wang
Priority: Critical
Fix For: 4.3.0
Attachments: apilog.log, management-server.log
Steps:
1. Enable Nexus flag at the global level
2. Tried to configure the Adv zone with VMWARE hypervisor with out specifying
Nexus vSwitch details while adding the cluster.
With this Cluster addition failed . So i have cancelled the zone
configuration.
Now tried below steps:
1) Removed Pod and then tried to remove zone . It failed saying The zone is
not deletable because there are VMware datacenters associated with this zone.
Remove VMware DC from this zone.
2) There is no Remove DC option , When i go to Zone details in the UI
Observation:
1) Entries in vmware_data_center and vmware_data_center_zone_map are not
cleaned up when there is a failure to add the cluster
2) So with this issue when i try to add the cluster , it is failing saying
This data center is already part of other Cloudstack Zone
So when there is a failure to add cluster for any reason , we should remove
the addDC association in the DB aswell.
I did delete the rows from vmware_data_center and vmware_data_center_zone_map
, Then i was able to reuse the Datacenter
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5427) Scaling vm and trying to scale to same host not considering overprovisioning ratios for cluster
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843707#comment-13843707 ] Nitin Mehta commented on CLOUDSTACK-5427: - Commit 5d9335fcc32733777963db33022eb14c3c1d16d2 in branch refs/heads/4.3 from Nitin Mehta [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5d9335f ] CLOUDSTACK-3664: scaling up vms was not considering parameter cluster.(memory/cpu).allocated.capacity.disablethreshold. Fixed it Also added overprovisioning factor retrieval at the cluster level for host capacity check Commit e79350d256cbd2bb64393ddae453c815b5a68339 in branch refs/heads/master from Nitin Mehta [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e79350d ] CLOUDSTACK-3664: scaling up vms was not considering parameter cluster.(memory/cpu).allocated.capacity.disablethreshold. Fixed it Also added overprovisioning factor retrieval at the cluster level for host capacity check Scaling vm and trying to scale to same host not considering overprovisioning ratios for cluster --- Key: CLOUDSTACK-5427 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5427 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Priority: Critical Fix For: 4.3.0 Scaling vm and trying to scale to same host is not considering overprovisioning ratios for cluster -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5098) [UI] Zone view is showing Add VMware Datacenter button even though zone is already associated with a data center
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13843722#comment-13843722 ] Jessica Wang commented on CLOUDSTACK-5098: -- Sateesh, Because when listClusters API response does not include any cluster that has VMware hypervisor, UI will presume the zone does not use VMware, therefore, there is no reason to call listVmwareDcs API. UI has this criterion because listVmwareDcs API is only available in non-oss build, but not oss-build. And there is no way to tell whether management server is running in an oss build or non-oss build. If UI calls listVmwareDcs API in an oss build, an error “this API doesn’t exist” will throw (which a lot of people complaint annoying and confusing). That’s why I made zone detail page to check whether the zone has a VMware cluster first. Jessica [UI] Zone view is showing Add VMware Datacenter button even though zone is already associated with a data center -- Key: CLOUDSTACK-5098 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5098 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.1 Reporter: Sailaja Mada Assignee: Jessica Wang Priority: Critical Fix For: 4.3.0 Attachments: apilog.log, management-server.log Steps: 1. Enable Nexus flag at the global level 2. Tried to configure the Adv zone with VMWARE hypervisor with out specifying Nexus vSwitch details while adding the cluster. With this Cluster addition failed . So i have cancelled the zone configuration. Now tried below steps: 1) Removed Pod and then tried to remove zone . It failed saying The zone is not deletable because there are VMware datacenters associated with this zone. Remove VMware DC from this zone. 2) There is no Remove DC option , When i go to Zone details in the UI Observation: 1) Entries in vmware_data_center and vmware_data_center_zone_map are not cleaned up when there is a failure to add the cluster 2) So with this issue when i try to add the cluster , it is failing saying This data center is already part of other Cloudstack Zone So when there is a failure to add cluster for any reason , we should remove the addDC association in the DB aswell. I did delete the rows from vmware_data_center and vmware_data_center_zone_map , Then i was able to reuse the Datacenter -- This message was sent by Atlassian JIRA (v6.1.4#6159)
