[jira] [Commented] (CLOUDSTACK-7931) Setting Null for global network throttling params doesn't trigger suitable error, fails silently
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215864#comment-14215864 ] ASF subversion and git services commented on CLOUDSTACK-7931: - Commit b008d78b57d318336e8e36091e64d19966ea518b in cloudstack's branch refs/heads/master from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b008d78 ] CLOUDSTACK-7930, CLOUDSTACK-7931: Do not allow to set invalid values for global settings which are of type integer and float This closes #41 Setting Null for global network throttling params doesn't trigger suitable error, fails silently Key: CLOUDSTACK-7931 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7931 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.5.0 Set global configs network.throttling.rate and vm.network.throttling.rate to NULL value. Then launch VM in a new network Result = VM fails to launch but it fails without any ERROR logs or suitable exceptions. A corresponding INFO log seems to have nothing but null Generally, for few global configs NULL is an acceptable value in some cases. If this is not the case, then we should not allow to set such a value for the config. The API should error out suitably. This is one issue. Further, it should throw an appropriate error when the deploy VM fails to design network. The error in this case is not handled suitably and there's nothing in ERROR logs as well. Looking at the below logs, it's impossible to figure out the reason for the failure of deploy VM. So at some point, if a user inadvertently sets it to NULL, neither does the updateConfiguration API result in error nor does the deployVirtualMachine throw a suitable error. Here's the log: 2014-11-13 13:29:15,584 DEBUG [c.c.a.ApiServlet] (catalina-exec-18:ctx-285ce7d9) ===START=== 10.144.7.5 – GET command=createNetworkresponse=jsonsessionkey=6ZKk3l0f4pdKU1yfDZxwF31YgCM%3DnetworkOfferingId=e8746c6b-e945-4084-9290-37cea253e262name=newtest1displayText=newtest1zoneId=b642a92a-3480-4818-99bf-6546a28df624_=1415866216789 2014-11-13 13:29:15,617 DEBUG [o.a.c.n.c.m.ContrailGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Refusing to design this network 2014-11-13 13:29:15,617 DEBUG [c.c.n.g.MidoNetGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) design called 2014-11-13 13:29:15,618 DEBUG [c.c.n.g.MidoNetGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Refusing to design this network, the physical isolation type is not MIDO 2014-11-13 13:29:15,619 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Refusing to design this network 2014-11-13 13:29:15,620 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Refusing to design this network 2014-11-13 13:29:15,621 DEBUG [c.c.n.g.OvsGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Refusing to design this network 2014-11-13 13:29:15,644 DEBUG [o.a.c.n.g.SspGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) SSP not configured to be active 2014-11-13 13:29:15,645 DEBUG [c.c.n.g.BrocadeVcsGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Refusing to design this network 2014-11-13 13:29:15,646 DEBUG [c.c.n.g.NuageVspGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Refusing to design this network 2014-11-13 13:29:15,648 DEBUG [o.a.c.e.o.NetworkOrchestrator] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Releasing lock for Acct[467a4f66-698f-11e4-be18-42407779c24b-admin] 2014-11-13 13:29:15,688 DEBUG [c.c.a.ApiServlet] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) ===END=== 10.144.7.5 – GET command=createNetworkresponse=jsonsessionkey=6ZKk3l0f4pdKU1yfDZxwF31YgCM%3DnetworkOfferingId=e8746c6b-e945-4084-9290-37cea253e262name=newtest1displayText=newtest1zoneId=b642a92a-3480-4818-99bf-6546a28df624_=1415866216789 2014-11-13 13:29:15,727 DEBUG [c.c.a.ApiServlet] (catalina-exec-9:ctx-54781545) ===START=== 10.144.7.5 – GET command=deployVirtualMachineresponse=jsonsessionkey=6ZKk3l0f4pdKU1yfDZxwF31YgCM%3Dzoneid=b642a92a-3480-4818-99bf-6546a28df624templateid=f7df5ef0-698e-11e4-be18-42407779c24bhypervisor=XenServerserviceofferingid=04840780-04d0-4b41-847a-dda08ad460f4iptonetworklist%5B0%5D.networkid=c0e24f7a-fe03-4a3b-a11e-ab29150b803bdisplayname=throttlingvm1name=throttlingvm1_=1415866216945 2014-11-13 13:29:15,753 DEBUG [c.c.n.NetworkModelImpl] (catalina-exec-9:ctx-54781545 ctx-e87f4810) Service SecurityGroup is
[jira] [Commented] (CLOUDSTACK-7930) Do not allow to set invalid values for global settings which are of type Integer, Float
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215863#comment-14215863 ] ASF subversion and git services commented on CLOUDSTACK-7930: - Commit b008d78b57d318336e8e36091e64d19966ea518b in cloudstack's branch refs/heads/master from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b008d78 ] CLOUDSTACK-7930, CLOUDSTACK-7931: Do not allow to set invalid values for global settings which are of type integer and float This closes #41 Do not allow to set invalid values for global settings which are of type Integer, Float --- Key: CLOUDSTACK-7930 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7930 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.5.0 Setting Integer/Float/Boolean to invalid values results in NullPointerException, NumberFormatException later in code. In case of network.throttling.rate parameter set to null results in deploy VM failure with message of null and no other exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7932) [Hyper-V] Wrong semantics for isVmAlive() method in HypervInvestigator
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215867#comment-14215867 ] ASF subversion and git services commented on CLOUDSTACK-7932: - Commit 055f6ad318466ed88ed07085f4facc152038b25c in cloudstack's branch refs/heads/master from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=055f6ad ] CLOUDSTACK-7932: Fixed wrong semantics for isVmAlive() method in HypervInvestigator Findbugs will report error on this as it is expecting true/false for Boolean value. But we have diffrent meaning for null so it is false positive case from findbug This closes #39 [Hyper-V] Wrong semantics for isVmAlive() method in HypervInvestigator -- Key: CLOUDSTACK-7932 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7932 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Fix For: 4.5.0 The isVmAlive() method should return null when it is unable to conclusively determine if the VM is alive or not. I ran some tests using Simulator and found that HypervInvestigator determined that VM is not alive. How can HypervInvestigator determine status of a VM running on Simulator or any other HV? 2014-11-15 13:35:21,692 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) HypervInvestigator found VM[SecondaryStorageVm|s-1-VM]to be alive? false Full logs for the HA worker thread 2014-11-15 13:35:21,642 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) Processing HAWork[1-HA-1-Running-Investigating] 2014-11-15 13:35:21,648 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) HA on VM[SecondaryStorageVm|s-1-VM] 2014-11-15 13:35:21,658 DEBUG [c.c.h.CheckOnAgentInvestigator] (HA-Worker-1:ctx-e0b5183c work-1) Unable to reach the agent for VM[SecondaryStorageVm|s-1-VM]: Resource [Host:1] is unreachable: Host 1: Host with specified id is not in the right state: Down 2014-11-15 13:35:21,659 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) SimpleInvestigator found VM[SecondaryStorageVm|s-1-VM]to be alive? null 2014-11-15 13:35:21,659 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) XenServerInvestigator found VM[SecondaryStorageVm|s-1-VM]to be alive? null 2014-11-15 13:35:21,659 DEBUG [c.c.h.UserVmDomRInvestigator] (HA-Worker-1:ctx-e0b5183c work-1) Not a User Vm, unable to determine state of VM[SecondaryStorageVm|s-1-VM] returning null 2014-11-15 13:35:21,659 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) PingInvestigator found VM[SecondaryStorageVm|s-1-VM]to be alive? null 2014-11-15 13:35:21,659 DEBUG [c.c.h.ManagementIPSystemVMInvestigator] (HA-Worker-1:ctx-e0b5183c work-1) Testing if VM[SecondaryStorageVm|s-1-VM] is alive 2014-11-15 13:35:21,670 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 2-5786281096240955453: Sending { Cmd , MgmtId: 1, via: 2(SimulatedAgent.08984ca6-967c-49b0-84c1-968076cd6992), Ver: v1, Flags: 100011, [{com.cloud.agent.api.PingTestCommand:{_computingHostIp:172.16.15.74,wait:20}}] } 2014-11-15 13:35:21,670 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 2-5786281096240955453: Executing: { Cmd , MgmtId: 1, via: 2(SimulatedAgent.08984ca6-967c-49b0-84c1-968076cd6992), Ver: v1, Flags: 100011, [{com.cloud.agent.api.PingTestCommand:{_computingHostIp:172.16.15.74,wait:20}}] } 2014-11-15 13:35:21,675 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 2-5786281096240955453: Received: { Ans: , MgmtId: 1, via: 2, Ver: v1, Flags: 10, { Answer } } 2014-11-15 13:35:21,675 DEBUG [c.c.h.AbstractInvestigatorImpl] (HA-Worker-1:ctx-e0b5183c work-1) host (172.16.15.74) cannot be pinged, returning null ('I don't know') 2014-11-15 13:35:21,678 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 3-248260929458798725: Sending { Cmd , MgmtId: 1, via: 3(SimulatedAgent.9bcff565-4ae7-492a-8e39-30d11f1cbbd7), Ver: v1, Flags: 100011, [{com.cloud.agent.api.PingTestCommand:{_computingHostIp:172.16.15.74,wait:20}}] } 2014-11-15 13:35:21,679 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 3-248260929458798725: Executing: { Cmd , MgmtId: 1, via: 3(SimulatedAgent.9bcff565-4ae7-492a-8e39-30d11f1cbbd7), Ver: v1, Flags: 100011, [{com.cloud.agent.api.PingTestCommand:{_computingHostIp:172.16.15.74,wait:20}}] } 2014-11-15 13:35:21,691 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 3-248260929458798725: Received: { Ans: , MgmtId: 1, via: 3, Ver: v1, Flags:
[jira] [Commented] (CLOUDSTACK-7929) Unhandled exception when setting negative value for throttling rate while creating network offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215869#comment-14215869 ] ASF subversion and git services commented on CLOUDSTACK-7929: - Commit 31876fb5886362d15e6bd770a3afd16c0ca07da1 in cloudstack's branch refs/heads/master from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=31876fb ] CLOUDSTACK-7929: While creating network offering if one specifies negative value for network rate then we will convert that value to 0 i.e. unlimited This closes #40 Unhandled exception when setting negative value for throttling rate while creating network offering --- Key: CLOUDSTACK-7929 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7929 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Fix For: 4.5.0 Steps Create a network offering and specify -1 for network throttling rate. Result = Exception is not handled properly throwing a DB exception exposing the DB column names in the Logs and UI. Expected Result = -1 is generally an acceptable input for signifying infinite values or not applicable values. So we should allow -1 and translate it appropriately as no throttling applied. Or if we don't, we should handle the input correctly and throw a suitable error message for the user. Following is the exception seen presently in the logs (or through UI): [{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] } 2014-11-13 13:58:31,414 DEBUG [c.c.a.ApiServlet] (catalina-exec-8:ctx-ac230e40) ===START=== 10.144.7.5 – POST command=createNetworkOfferingresponse=jsonsessionkey=vL5F3A1A1pr98OOTv7eei G2jvBI%3D 2014-11-13 13:58:31,428 DEBUG [c.c.c.ConfigurationManagerImpl] (catalina-exec-8:ctx-ac230e40 ctx-60a6474c) Adding Firewall service with provider VirtualRouter 2014-11-13 13:58:31,432 DEBUG [c.c.c.ConfigurationManagerImpl] (catalina-exec-8:ctx-ac230e40 ctx-60a6474c) Adding network offering [Network Offering [0-Guest-test] 2014-11-13 13:58:31,435 DEBUG [c.c.u.d.T.Transaction] (catalina-exec-8:ctx-ac230e40 ctx-60a6474c) Rolling back the transaction: Time = 3 Name = catalina-exec-8; called by -TransactionLegac y.rollback:902-TransactionLegacy.removeUpTo:845-TransactionLegacy.close:669-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke :91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy79.persist:-1-ConfigurationManagerImpl$11.doInTransaction:4218-ConfigurationManagerImpl$11.doInTransaction:420 9-Transaction$2.doInTransaction:57 2014-11-13 13:58:31,442 ERROR [c.c.a.ApiServer] (catalina-exec-8:ctx-ac230e40 ctx-60a6474c) unhandled exception executing api command: [Ljava.lang.String;@61bc5278 com.cloud.utils.exception.CloudRuntimeException: DB Exception on: com.mysql.jdbc.JDBC4PreparedStatement@27a103c3: INSERT INTO network_offerings (network_offerings.name, network_offerings.un ique_name, network_offerings.display_text, network_offerings.nw_rate, network_offerings.mc_rate, network_offerings.traffic_type, network_offerings.specify_vlan, network_offerings.system_onl y, network_offerings.service_offering_id, network_offerings.tags, network_offerings.default, network_offerings.availability, network_offerings.state, network_offerings.created, network_offe rings.guest_type, network_offerings.dedicated_lb_service, network_offerings.shared_source_nat_service, network_offerings.specify_ip_ranges, network_offerings.sort_key, network_offerings.uui d, network_offerings.redundant_router_service, network_offerings.conserve_mode, network_offerings.elastic_ip_service, network_offerings.eip_associate_public_ip, network_offerings.elastic_lb _service, network_offerings.inline, network_offerings.is_persistent, network_offerings.egress_default_policy, network_offerings.concurrent_connections, network_offerings.keep_alive_enabled, network_offerings.supports_streched_l2, network_offerings.internal_lb, network_offerings.public_lb) VALUES (_binary'test', _binary'test', _binary'test', -1, 10, 'Guest', 0, 0, null, null, 0, 'Optional', 'Disabled', '2014-11-13 08:28:31', 'Isolated', 0, 0, 0, 0, _binary'f8bf35f5-dd77-4fa8-83ff-af1f1e85ece3', 0, 1, 0, 0, 0, 0, 0, 1, null, 0, 0, 0, 0) at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1400) at com.cloud.offerings.dao.NetworkOfferingDaoImpl.persist(NetworkOfferingDaoImpl.java:181) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
[jira] [Commented] (CLOUDSTACK-7747) VM Snapshot - Support only for vm revert cases that will not result in VM state change
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215907#comment-14215907 ] ASF subversion and git services commented on CLOUDSTACK-7747: - Commit f43ffb9a0f71f380f896e1e5c581725e9c08faab in cloudstack's branch refs/heads/4.5 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f43ffb9 ] CLOUDSTACK-7688, CLOUDSTACK-7747: restricted various operations for VM with VM snapshots which breaks VM snapshots. Now they are informed that they cannot perform the operation. To perform operation they have to remove VM snapshots of VM. VM Snapshot - Support only for vm revert cases that will not result in VM state change -- Key: CLOUDSTACK-7747 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7747 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Currently we extend support for all the possible combinations .In cases were the Vm start changes from “Stopped” to “Running”, CS does not account for this VM’s capacity and VM start does not use our allocators. Following will be the only configuration we would have to support: 1.Revert a Running VM to a Disk and Memory Snapshot ( with and without quiesce option). 1.Revert a Stopped VM to a Disk Snapshot ( with and without quiesce option). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7703) Cloudstack server endless loop when trying to create a volume while storage pool is full
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215909#comment-14215909 ] ASF subversion and git services commented on CLOUDSTACK-7703: - Commit ae199b6ce7634ef702243c20800937c8a3ab4b14 in cloudstack's branch refs/heads/4.5 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ae199b6 ] CLOUDSTACK-7703, CLOUDSTACK-7752: Fixed deployment planner stuck in infinite loop. If we create VM with shared service offering and attach disk with local disk offering, and one of storage pool is full(cannot be allocated) and other is not full then we are not putting the cluster in avoid list which is causing this infinite loop. Fixed by putting the cluster in avoid list even if one of the storage pool is full(cannot be allocated) Cloudstack server endless loop when trying to create a volume while storage pool is full Key: CLOUDSTACK-7703 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7703 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: Centos 6.5 Reporter: JF Vincent Assignee: Anshul Gangwar Priority: Critical Fix For: 4.5.0 When trying to create a VM, and thus a volume for it and the primary storage is full (over 90%), the managament server enter in and endless loop (extract below) and we have to restart it to exit this loop. 2014-10-14 11:39:20,701 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found for volume: Vol[5436|vm=5855|DATADISK] under cluster: 2 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable storagePools found under this Cluster: 2 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Could not find suitable Deployment Destination for this VM under any clusters, returning. 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Searching all possible resources under this Zone: 2 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Listing clusters in order of aggregate capacity, that have (atleast one host with) enough CPU and RAM capacity under this Zone: 2 2014-10-14 11:39:20,707 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Removing from the clusterId list these clusters from avoid set: [] 2014-10-14 11:39:20,714 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Checking resources in Cluster: 2 under Pod: 2 2014-10-14 11:39:20,714 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking for hosts in dc: 2 pod:2 cluster:2 2014-10-14 11:39:20,716 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) FirstFitAllocator has 3 hosts to check for allocation: [Host[-79-Routing], Host[-89-Routing], Host[-77-Routing]] 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Found 3 hosts for allocation after prioritization: [Host[-79-Routing], Host[-89-Routing], Host[-77-Routing]] 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking for speed=500Mhz, Ram=500 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host: 79 has cpu capability (cpu:8, speed:2399) to support requested CPU: 1 and requested speed: 500 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Checking if host: 79 has enough capacity for requested CPU: 500 and requested RAM: 524288000 , cpuOverprovisioningFactor: 4.0 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Hosts's actual total CPU: 19192 and CPU after applying overprovisioning: 76768 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f
[jira] [Commented] (CLOUDSTACK-7752) Management Server goes in infinite loop while creating a vm with tagged local data disk when the pool is not tagged
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215910#comment-14215910 ] ASF subversion and git services commented on CLOUDSTACK-7752: - Commit ae199b6ce7634ef702243c20800937c8a3ab4b14 in cloudstack's branch refs/heads/4.5 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ae199b6 ] CLOUDSTACK-7703, CLOUDSTACK-7752: Fixed deployment planner stuck in infinite loop. If we create VM with shared service offering and attach disk with local disk offering, and one of storage pool is full(cannot be allocated) and other is not full then we are not putting the cluster in avoid list which is causing this infinite loop. Fixed by putting the cluster in avoid list even if one of the storage pool is full(cannot be allocated) Management Server goes in infinite loop while creating a vm with tagged local data disk when the pool is not tagged --- Key: CLOUDSTACK-7752 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7752 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Steps to reproduce: Setup must have a single cluster with both local and shared storage. 1) Create a local disk offering and tag it T1 2) Deploy vm with shared root disk and local data disk Management server goes in an infinite loop. The vm is never started/expunged. Also this causes vmops.log size to go very high. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7767) [Events] All events are not generated for snapshot creation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215908#comment-14215908 ] ASF subversion and git services commented on CLOUDSTACK-7767: - Commit c04cdae60bc9a10f584c2f0b591aa5a5d9c7e3e4 in cloudstack's branch refs/heads/4.5 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c04cdae ] CLOUDSTACK-7767: fixed events are not generated for snapshot creation [Events] All events are not generated for snapshot creation --- Key: CLOUDSTACK-7767 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7767 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Snapshot Affects Versions: 4.5.0 Environment: Latest build from 4.5 with commit [root@BPKxDmS ~]# cloudstack-sccs 562c89544e80dcd61ae5fd179eb8546de2598b33 Reporter: Sanjeev N Assignee: Anshul Gangwar Priority: Critical Fix For: 4.5.0 Attachments: cloud.dmp, management-server.rar [Events] All events are not generated for snapshot creation Steps to Reproduce: === 1.Bring up CS with latest build from 4.5 2.Deploy a vm using cent os template 3.Take a snapshot on the root disk of the vm 4.Verify the cloud.events table for the snapshot events We could see events with states created,sheduled,started and completed for vm,volume and template whereas there is only one event with state scheduled for snapshot creation. So by looking at the events user will not be able to find out whether the snaphot creation is completed of not. Following is the DB snippet: mysql select id,uuid,type,state,description from event where type in (SNAPSHOT.CREATE,VM.CREATE,VOLUME.CREATE,TEMPLATE.CREATE); +-+--+-+---++ | id | uuid | type| state | description | +-+--+-+---++ | 189 | 1f48cbef-648e-4728-9eb1-5178bea3b4fd | SNAPSHOT.CREATE | Scheduled | creating snapshot for volume: 10 | | 207 | 9162ed93-bd6c-4e78-8f4a-1836859f5009 | SNAPSHOT.CREATE | Scheduled | creating snapshot for volume: 15 | | 208 | 261b95a7-0a4d-45cd-9922-3cde8640ab02 | SNAPSHOT.CREATE | Scheduled | creating snapshot for volume: 15 | | 212 | e80e1383-944b-4ac9-bc86-70511de86c94 | SNAPSHOT.CREATE | Scheduled | creating snapshot for volume: 15 | | 168 | 518e4ae7-e506-4b93-a8b5-696777b91706 | TEMPLATE.CREATE | Completed | Successfully completed creating template. Id: 202 name: cent53 | | 193 | 3d20409e-a9e5-438a-9a00-2deb23ee87fe | TEMPLATE.CREATE | Created | Successfully created entity for creating template | | 194 | 528f823e-b817-4b9a-8935-2f57ac5a4c9b | TEMPLATE.CREATE | Scheduled | creating template: fromSnapRoot10 | | 195 | 9ab1d914-9f30-4a3d-8070-1fdce6827f6d | TEMPLATE.CREATE | Started | creating template. Template Id: 203 from snapshot Id: 1 | | 196 | d2676d55-84c8-4486-9aca-0f3eda74a4a7 | TEMPLATE.CREATE | Completed | Successfully completed creating template. Template Id: 203 from snapshot Id: 1 | | 154 | 3b9207d6-d120-4762-b9e3-423f849870d6 | VM.CREATE | Created | Successfully created entity for deploying Vm. Vm Id: 8 | | 155 | 7c47beb2-e105-478f-9575-e3ab1b2709ec | VM.CREATE | Scheduled | starting Vm. Vm Id: 8 | | 156 | 27718b57-b679-412b-b983-0f9cf7757930 | VM.CREATE | Started | starting Vm. Vm Id: 8 | | 159 | 6b5bece5-bfab-41c0-906e-8fbec2ddd2bf | VM.CREATE | Completed | Successfully completed starting Vm. Vm Id: 8 | | 170 | 66412dc3-fc03-4a2d-b796-807bd6ec096f | VM.CREATE | Created | Successfully created entity for deploying Vm. Vm Id: 10 | | 171 | a6c91812-9218-451c-a801-60652089ba7b | VM.CREATE | Scheduled | starting Vm. Vm Id: 10 | | 172 |
[jira] [Commented] (CLOUDSTACK-7688) Do not allow various operations which breaks VM Snapshots
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215906#comment-14215906 ] ASF subversion and git services commented on CLOUDSTACK-7688: - Commit f43ffb9a0f71f380f896e1e5c581725e9c08faab in cloudstack's branch refs/heads/4.5 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f43ffb9 ] CLOUDSTACK-7688, CLOUDSTACK-7747: restricted various operations for VM with VM snapshots which breaks VM snapshots. Now they are informed that they cannot perform the operation. To perform operation they have to remove VM snapshots of VM. Do not allow various operations which breaks VM Snapshots - Key: CLOUDSTACK-7688 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7688 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Anshul Gangwar Assignee: Anshul Gangwar Fix For: 4.5.0 VM snapshots stops working when following operations are performed on VM with VM snapshots 1. Volumes of VM are migrated to other storage 2. Add and remove NIC to/from VM 3. Attach and Detach volume to VM 4. Scale up/down of VM(change service offering) 5. Volume snapshot which is not major use case in this scenario 6. Resize volume 7. Live migration of VM which involves storage migration -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7758) Although API calls are failing, events tab shows them as successful
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215927#comment-14215927 ] ASF subversion and git services commented on CLOUDSTACK-7758: - Commit 44d12330b9d7494ad392e0549ffbdc7100130f86 in cloudstack's branch refs/heads/4.5 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=44d1233 ] CLOUDSTACK-7758: Fixed although api calls are failing, event tab shows them as successful This closes #29 Although API calls are failing, events tab shows them as successful --- Key: CLOUDSTACK-7758 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7758 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.5.0 Like Deployment of VM is failing. But event tab shows them as Successfully completed starting VM. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7930) Do not allow to set invalid values for global settings which are of type Integer, Float
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215929#comment-14215929 ] ASF subversion and git services commented on CLOUDSTACK-7930: - Commit 8307dd9105cdb70a0fe09c059bacfcec43a29024 in cloudstack's branch refs/heads/4.5 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8307dd9 ] CLOUDSTACK-7930, CLOUDSTACK-7931: Do not allow to set invalid values for global settings which are of type integer and float This closes #41 Do not allow to set invalid values for global settings which are of type Integer, Float --- Key: CLOUDSTACK-7930 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7930 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.5.0 Setting Integer/Float/Boolean to invalid values results in NullPointerException, NumberFormatException later in code. In case of network.throttling.rate parameter set to null results in deploy VM failure with message of null and no other exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7932) [Hyper-V] Wrong semantics for isVmAlive() method in HypervInvestigator
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215931#comment-14215931 ] ASF subversion and git services commented on CLOUDSTACK-7932: - Commit 4d583a4a71313d9f62438818c9d657a7c4a5d43d in cloudstack's branch refs/heads/4.5 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4d583a4 ] CLOUDSTACK-7932: Fixed wrong semantics for isVmAlive() method in HypervInvestigator Findbugs will report error on this as it is expecting true/false for Boolean value. But we have diffrent meaning for null so it is false positive case from findbug This closes #39 [Hyper-V] Wrong semantics for isVmAlive() method in HypervInvestigator -- Key: CLOUDSTACK-7932 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7932 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Fix For: 4.5.0 The isVmAlive() method should return null when it is unable to conclusively determine if the VM is alive or not. I ran some tests using Simulator and found that HypervInvestigator determined that VM is not alive. How can HypervInvestigator determine status of a VM running on Simulator or any other HV? 2014-11-15 13:35:21,692 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) HypervInvestigator found VM[SecondaryStorageVm|s-1-VM]to be alive? false Full logs for the HA worker thread 2014-11-15 13:35:21,642 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) Processing HAWork[1-HA-1-Running-Investigating] 2014-11-15 13:35:21,648 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) HA on VM[SecondaryStorageVm|s-1-VM] 2014-11-15 13:35:21,658 DEBUG [c.c.h.CheckOnAgentInvestigator] (HA-Worker-1:ctx-e0b5183c work-1) Unable to reach the agent for VM[SecondaryStorageVm|s-1-VM]: Resource [Host:1] is unreachable: Host 1: Host with specified id is not in the right state: Down 2014-11-15 13:35:21,659 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) SimpleInvestigator found VM[SecondaryStorageVm|s-1-VM]to be alive? null 2014-11-15 13:35:21,659 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) XenServerInvestigator found VM[SecondaryStorageVm|s-1-VM]to be alive? null 2014-11-15 13:35:21,659 DEBUG [c.c.h.UserVmDomRInvestigator] (HA-Worker-1:ctx-e0b5183c work-1) Not a User Vm, unable to determine state of VM[SecondaryStorageVm|s-1-VM] returning null 2014-11-15 13:35:21,659 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) PingInvestigator found VM[SecondaryStorageVm|s-1-VM]to be alive? null 2014-11-15 13:35:21,659 DEBUG [c.c.h.ManagementIPSystemVMInvestigator] (HA-Worker-1:ctx-e0b5183c work-1) Testing if VM[SecondaryStorageVm|s-1-VM] is alive 2014-11-15 13:35:21,670 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 2-5786281096240955453: Sending { Cmd , MgmtId: 1, via: 2(SimulatedAgent.08984ca6-967c-49b0-84c1-968076cd6992), Ver: v1, Flags: 100011, [{com.cloud.agent.api.PingTestCommand:{_computingHostIp:172.16.15.74,wait:20}}] } 2014-11-15 13:35:21,670 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 2-5786281096240955453: Executing: { Cmd , MgmtId: 1, via: 2(SimulatedAgent.08984ca6-967c-49b0-84c1-968076cd6992), Ver: v1, Flags: 100011, [{com.cloud.agent.api.PingTestCommand:{_computingHostIp:172.16.15.74,wait:20}}] } 2014-11-15 13:35:21,675 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 2-5786281096240955453: Received: { Ans: , MgmtId: 1, via: 2, Ver: v1, Flags: 10, { Answer } } 2014-11-15 13:35:21,675 DEBUG [c.c.h.AbstractInvestigatorImpl] (HA-Worker-1:ctx-e0b5183c work-1) host (172.16.15.74) cannot be pinged, returning null ('I don't know') 2014-11-15 13:35:21,678 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 3-248260929458798725: Sending { Cmd , MgmtId: 1, via: 3(SimulatedAgent.9bcff565-4ae7-492a-8e39-30d11f1cbbd7), Ver: v1, Flags: 100011, [{com.cloud.agent.api.PingTestCommand:{_computingHostIp:172.16.15.74,wait:20}}] } 2014-11-15 13:35:21,679 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 3-248260929458798725: Executing: { Cmd , MgmtId: 1, via: 3(SimulatedAgent.9bcff565-4ae7-492a-8e39-30d11f1cbbd7), Ver: v1, Flags: 100011, [{com.cloud.agent.api.PingTestCommand:{_computingHostIp:172.16.15.74,wait:20}}] } 2014-11-15 13:35:21,691 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 3-248260929458798725: Received: { Ans: , MgmtId: 1, via: 3, Ver: v1, Flags: 10, {
[jira] [Commented] (CLOUDSTACK-7541) Volume gets created with the size mentioned in the custom disk offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215928#comment-14215928 ] ASF subversion and git services commented on CLOUDSTACK-7541: - Commit 4721e66d0e2ed89836286f1654a30a3568b284b6 in cloudstack's branch refs/heads/4.5 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4721e66 ] CLOUDSTACK-7541: Added restriction to not allow custom disk offering with disksize UI doesn't allow but with API we were able to create custom disk offering with disk size which was causing this issue This closes #28 Volume gets created with the size mentioned in the custom disk offering Key: CLOUDSTACK-7541 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7541 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Volumes Affects Versions: 4.5.0 Environment: latest build from 4.5 with commit 932ea253eb8c65821503ab9db301073cdb2a413e Reporter: Sanjeev N Assignee: Anshul Gangwar Priority: Critical Fix For: 4.5.0 Attachments: cloud.dmp, management-server.rar Volume gets created with the size mentioned in the custom disk offering Steps to reproduce: == 1.Bring up cs with latest build 2.Create custom disk offering with disk size say 2 3.Create data disk using this offering and provide disk size as 1 while creating data disk Expected Result: == Since the disk offering is of type custom , volume should be created with size given during volume creation instead of taking it from the disk offering. If the disk offering is custom then the volume creation must ignore the size given in the offering and should create volume with size provide while creating volume. Actual Result: === Disk got created with size mentioned in disk offering rather than the size given during volume creation time. Observations: === http://10.147.38.153:8096/client/api?command=createDiskOfferingisMirrored=falsename=customdisplaytext=customstorageType=sharedcacheMode=noneprovisioningType=thincustomized=truedisksize=2 { creatediskofferingresponse : { diskoffering : {id:2ddb8b79-9592-4b8c-8bd9-3d32c582873b,name:custom,displaytext:custom,disksize:2,created:2014-09-12T23:33:24+0530,iscustomized:true,storagetype:shared,provisioningtype:thin,displayoffering:true} } } http://10.147.38.153:8080/client/api?command=createVolumeresponse=jsonsessionkey=USf4e%2BpnzNiyWyq1PCeDFswjB%2BU%3Dname=customzoneId=2c67c83e-b8c3-42d0-a37b-b37287ac84dddiskOfferingId=2ddb8b79-9592-4b8c-8bd9-3d32c582873bsize=1_=1410525928417 { queryasyncjobresultresponse : {accountid:638d4e82-341f-11e4-a4c9-06097e23,userid:638d5ddc-341f-11e4-a4c9-06097e23,cmd:org.apache.cloudstack.api.command.admin.volume.CreateVolumeCmdByAdmin,jobstatus:1,jobprocstatus:0,jobresultcode:0,jobresulttype:object,jobresult:{volume:{id:42f24df4-b4ae-4b4c-80ce-ea1b5daf12bd,name:custom,zoneid:2c67c83e-b8c3-42d0-a37b-b37287ac84dd,zonename:zone1,type:DATADISK,provisioningtype:thin,size:2147483648,created:2014-09-12T23:34:32+0530,state:Allocated,account:admin,domainid:2caca782-341f-11e4-a4c9-06097e23,domain:ROOT,storagetype:shared,hypervisor:None,diskofferingid:2ddb8b79-9592-4b8c-8bd9-3d32c582873b,diskofferingname:custom,diskofferingdisplaytext:custom,destroyed:false,isextractable:true,tags:[],displayvolume:true,quiescevm:false,jobid:edf1a066-63b0-400b-bf15-4f77bf659206,jobstatus:0}},jobinstancetype:Volume,jobinstanceid:42f24df4-b4ae-4b4c-80ce-ea1b5daf12bd,created:2014-09-12T23:34:32+0530,jobid:edf1a066-63b0-400b-bf15-4f77bf659206} } -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7931) Setting Null for global network throttling params doesn't trigger suitable error, fails silently
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215930#comment-14215930 ] ASF subversion and git services commented on CLOUDSTACK-7931: - Commit 8307dd9105cdb70a0fe09c059bacfcec43a29024 in cloudstack's branch refs/heads/4.5 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8307dd9 ] CLOUDSTACK-7930, CLOUDSTACK-7931: Do not allow to set invalid values for global settings which are of type integer and float This closes #41 Setting Null for global network throttling params doesn't trigger suitable error, fails silently Key: CLOUDSTACK-7931 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7931 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.5.0 Set global configs network.throttling.rate and vm.network.throttling.rate to NULL value. Then launch VM in a new network Result = VM fails to launch but it fails without any ERROR logs or suitable exceptions. A corresponding INFO log seems to have nothing but null Generally, for few global configs NULL is an acceptable value in some cases. If this is not the case, then we should not allow to set such a value for the config. The API should error out suitably. This is one issue. Further, it should throw an appropriate error when the deploy VM fails to design network. The error in this case is not handled suitably and there's nothing in ERROR logs as well. Looking at the below logs, it's impossible to figure out the reason for the failure of deploy VM. So at some point, if a user inadvertently sets it to NULL, neither does the updateConfiguration API result in error nor does the deployVirtualMachine throw a suitable error. Here's the log: 2014-11-13 13:29:15,584 DEBUG [c.c.a.ApiServlet] (catalina-exec-18:ctx-285ce7d9) ===START=== 10.144.7.5 – GET command=createNetworkresponse=jsonsessionkey=6ZKk3l0f4pdKU1yfDZxwF31YgCM%3DnetworkOfferingId=e8746c6b-e945-4084-9290-37cea253e262name=newtest1displayText=newtest1zoneId=b642a92a-3480-4818-99bf-6546a28df624_=1415866216789 2014-11-13 13:29:15,617 DEBUG [o.a.c.n.c.m.ContrailGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Refusing to design this network 2014-11-13 13:29:15,617 DEBUG [c.c.n.g.MidoNetGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) design called 2014-11-13 13:29:15,618 DEBUG [c.c.n.g.MidoNetGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Refusing to design this network, the physical isolation type is not MIDO 2014-11-13 13:29:15,619 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Refusing to design this network 2014-11-13 13:29:15,620 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Refusing to design this network 2014-11-13 13:29:15,621 DEBUG [c.c.n.g.OvsGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Refusing to design this network 2014-11-13 13:29:15,644 DEBUG [o.a.c.n.g.SspGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) SSP not configured to be active 2014-11-13 13:29:15,645 DEBUG [c.c.n.g.BrocadeVcsGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Refusing to design this network 2014-11-13 13:29:15,646 DEBUG [c.c.n.g.NuageVspGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Refusing to design this network 2014-11-13 13:29:15,648 DEBUG [o.a.c.e.o.NetworkOrchestrator] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Releasing lock for Acct[467a4f66-698f-11e4-be18-42407779c24b-admin] 2014-11-13 13:29:15,688 DEBUG [c.c.a.ApiServlet] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) ===END=== 10.144.7.5 – GET command=createNetworkresponse=jsonsessionkey=6ZKk3l0f4pdKU1yfDZxwF31YgCM%3DnetworkOfferingId=e8746c6b-e945-4084-9290-37cea253e262name=newtest1displayText=newtest1zoneId=b642a92a-3480-4818-99bf-6546a28df624_=1415866216789 2014-11-13 13:29:15,727 DEBUG [c.c.a.ApiServlet] (catalina-exec-9:ctx-54781545) ===START=== 10.144.7.5 – GET command=deployVirtualMachineresponse=jsonsessionkey=6ZKk3l0f4pdKU1yfDZxwF31YgCM%3Dzoneid=b642a92a-3480-4818-99bf-6546a28df624templateid=f7df5ef0-698e-11e4-be18-42407779c24bhypervisor=XenServerserviceofferingid=04840780-04d0-4b41-847a-dda08ad460f4iptonetworklist%5B0%5D.networkid=c0e24f7a-fe03-4a3b-a11e-ab29150b803bdisplayname=throttlingvm1name=throttlingvm1_=1415866216945 2014-11-13 13:29:15,753 DEBUG [c.c.n.NetworkModelImpl] (catalina-exec-9:ctx-54781545 ctx-e87f4810) Service SecurityGroup is not
[jira] [Commented] (CLOUDSTACK-7929) Unhandled exception when setting negative value for throttling rate while creating network offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215932#comment-14215932 ] ASF subversion and git services commented on CLOUDSTACK-7929: - Commit 9c328cb9ddd6aa3d9d14ec5efb190ed2a46dc4df in cloudstack's branch refs/heads/4.5 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9c328cb ] CLOUDSTACK-7929: While creating network offering if one specifies negative value for network rate then we will convert that value to 0 i.e. unlimited This closes #40 Unhandled exception when setting negative value for throttling rate while creating network offering --- Key: CLOUDSTACK-7929 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7929 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Fix For: 4.5.0 Steps Create a network offering and specify -1 for network throttling rate. Result = Exception is not handled properly throwing a DB exception exposing the DB column names in the Logs and UI. Expected Result = -1 is generally an acceptable input for signifying infinite values or not applicable values. So we should allow -1 and translate it appropriately as no throttling applied. Or if we don't, we should handle the input correctly and throw a suitable error message for the user. Following is the exception seen presently in the logs (or through UI): [{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] } 2014-11-13 13:58:31,414 DEBUG [c.c.a.ApiServlet] (catalina-exec-8:ctx-ac230e40) ===START=== 10.144.7.5 – POST command=createNetworkOfferingresponse=jsonsessionkey=vL5F3A1A1pr98OOTv7eei G2jvBI%3D 2014-11-13 13:58:31,428 DEBUG [c.c.c.ConfigurationManagerImpl] (catalina-exec-8:ctx-ac230e40 ctx-60a6474c) Adding Firewall service with provider VirtualRouter 2014-11-13 13:58:31,432 DEBUG [c.c.c.ConfigurationManagerImpl] (catalina-exec-8:ctx-ac230e40 ctx-60a6474c) Adding network offering [Network Offering [0-Guest-test] 2014-11-13 13:58:31,435 DEBUG [c.c.u.d.T.Transaction] (catalina-exec-8:ctx-ac230e40 ctx-60a6474c) Rolling back the transaction: Time = 3 Name = catalina-exec-8; called by -TransactionLegac y.rollback:902-TransactionLegacy.removeUpTo:845-TransactionLegacy.close:669-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke :91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy79.persist:-1-ConfigurationManagerImpl$11.doInTransaction:4218-ConfigurationManagerImpl$11.doInTransaction:420 9-Transaction$2.doInTransaction:57 2014-11-13 13:58:31,442 ERROR [c.c.a.ApiServer] (catalina-exec-8:ctx-ac230e40 ctx-60a6474c) unhandled exception executing api command: [Ljava.lang.String;@61bc5278 com.cloud.utils.exception.CloudRuntimeException: DB Exception on: com.mysql.jdbc.JDBC4PreparedStatement@27a103c3: INSERT INTO network_offerings (network_offerings.name, network_offerings.un ique_name, network_offerings.display_text, network_offerings.nw_rate, network_offerings.mc_rate, network_offerings.traffic_type, network_offerings.specify_vlan, network_offerings.system_onl y, network_offerings.service_offering_id, network_offerings.tags, network_offerings.default, network_offerings.availability, network_offerings.state, network_offerings.created, network_offe rings.guest_type, network_offerings.dedicated_lb_service, network_offerings.shared_source_nat_service, network_offerings.specify_ip_ranges, network_offerings.sort_key, network_offerings.uui d, network_offerings.redundant_router_service, network_offerings.conserve_mode, network_offerings.elastic_ip_service, network_offerings.eip_associate_public_ip, network_offerings.elastic_lb _service, network_offerings.inline, network_offerings.is_persistent, network_offerings.egress_default_policy, network_offerings.concurrent_connections, network_offerings.keep_alive_enabled, network_offerings.supports_streched_l2, network_offerings.internal_lb, network_offerings.public_lb) VALUES (_binary'test', _binary'test', _binary'test', -1, 10, 'Guest', 0, 0, null, null, 0, 'Optional', 'Disabled', '2014-11-13 08:28:31', 'Isolated', 0, 0, 0, 0, _binary'f8bf35f5-dd77-4fa8-83ff-af1f1e85ece3', 0, 1, 0, 0, 0, 0, 0, 1, null, 0, 0, 0, 0) at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1400) at com.cloud.offerings.dao.NetworkOfferingDaoImpl.persist(NetworkOfferingDaoImpl.java:181) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
[jira] [Commented] (CLOUDSTACK-7929) Unhandled exception when setting negative value for throttling rate while creating network offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215940#comment-14215940 ] ASF GitHub Bot commented on CLOUDSTACK-7929: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/40 Unhandled exception when setting negative value for throttling rate while creating network offering --- Key: CLOUDSTACK-7929 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7929 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Fix For: 4.5.0 Steps Create a network offering and specify -1 for network throttling rate. Result = Exception is not handled properly throwing a DB exception exposing the DB column names in the Logs and UI. Expected Result = -1 is generally an acceptable input for signifying infinite values or not applicable values. So we should allow -1 and translate it appropriately as no throttling applied. Or if we don't, we should handle the input correctly and throw a suitable error message for the user. Following is the exception seen presently in the logs (or through UI): [{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] } 2014-11-13 13:58:31,414 DEBUG [c.c.a.ApiServlet] (catalina-exec-8:ctx-ac230e40) ===START=== 10.144.7.5 – POST command=createNetworkOfferingresponse=jsonsessionkey=vL5F3A1A1pr98OOTv7eei G2jvBI%3D 2014-11-13 13:58:31,428 DEBUG [c.c.c.ConfigurationManagerImpl] (catalina-exec-8:ctx-ac230e40 ctx-60a6474c) Adding Firewall service with provider VirtualRouter 2014-11-13 13:58:31,432 DEBUG [c.c.c.ConfigurationManagerImpl] (catalina-exec-8:ctx-ac230e40 ctx-60a6474c) Adding network offering [Network Offering [0-Guest-test] 2014-11-13 13:58:31,435 DEBUG [c.c.u.d.T.Transaction] (catalina-exec-8:ctx-ac230e40 ctx-60a6474c) Rolling back the transaction: Time = 3 Name = catalina-exec-8; called by -TransactionLegac y.rollback:902-TransactionLegacy.removeUpTo:845-TransactionLegacy.close:669-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke :91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy79.persist:-1-ConfigurationManagerImpl$11.doInTransaction:4218-ConfigurationManagerImpl$11.doInTransaction:420 9-Transaction$2.doInTransaction:57 2014-11-13 13:58:31,442 ERROR [c.c.a.ApiServer] (catalina-exec-8:ctx-ac230e40 ctx-60a6474c) unhandled exception executing api command: [Ljava.lang.String;@61bc5278 com.cloud.utils.exception.CloudRuntimeException: DB Exception on: com.mysql.jdbc.JDBC4PreparedStatement@27a103c3: INSERT INTO network_offerings (network_offerings.name, network_offerings.un ique_name, network_offerings.display_text, network_offerings.nw_rate, network_offerings.mc_rate, network_offerings.traffic_type, network_offerings.specify_vlan, network_offerings.system_onl y, network_offerings.service_offering_id, network_offerings.tags, network_offerings.default, network_offerings.availability, network_offerings.state, network_offerings.created, network_offe rings.guest_type, network_offerings.dedicated_lb_service, network_offerings.shared_source_nat_service, network_offerings.specify_ip_ranges, network_offerings.sort_key, network_offerings.uui d, network_offerings.redundant_router_service, network_offerings.conserve_mode, network_offerings.elastic_ip_service, network_offerings.eip_associate_public_ip, network_offerings.elastic_lb _service, network_offerings.inline, network_offerings.is_persistent, network_offerings.egress_default_policy, network_offerings.concurrent_connections, network_offerings.keep_alive_enabled, network_offerings.supports_streched_l2, network_offerings.internal_lb, network_offerings.public_lb) VALUES (_binary'test', _binary'test', _binary'test', -1, 10, 'Guest', 0, 0, null, null, 0, 'Optional', 'Disabled', '2014-11-13 08:28:31', 'Isolated', 0, 0, 0, 0, _binary'f8bf35f5-dd77-4fa8-83ff-af1f1e85ece3', 0, 1, 0, 0, 0, 0, 0, 1, null, 0, 0, 0, 0) at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1400) at com.cloud.offerings.dao.NetworkOfferingDaoImpl.persist(NetworkOfferingDaoImpl.java:181) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at
[jira] [Commented] (CLOUDSTACK-7930) Do not allow to set invalid values for global settings which are of type Integer, Float
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215939#comment-14215939 ] ASF GitHub Bot commented on CLOUDSTACK-7930: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/41 Do not allow to set invalid values for global settings which are of type Integer, Float --- Key: CLOUDSTACK-7930 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7930 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.5.0 Setting Integer/Float/Boolean to invalid values results in NullPointerException, NumberFormatException later in code. In case of network.throttling.rate parameter set to null results in deploy VM failure with message of null and no other exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7932) [Hyper-V] Wrong semantics for isVmAlive() method in HypervInvestigator
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215938#comment-14215938 ] ASF GitHub Bot commented on CLOUDSTACK-7932: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/39 [Hyper-V] Wrong semantics for isVmAlive() method in HypervInvestigator -- Key: CLOUDSTACK-7932 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7932 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Fix For: 4.5.0 The isVmAlive() method should return null when it is unable to conclusively determine if the VM is alive or not. I ran some tests using Simulator and found that HypervInvestigator determined that VM is not alive. How can HypervInvestigator determine status of a VM running on Simulator or any other HV? 2014-11-15 13:35:21,692 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) HypervInvestigator found VM[SecondaryStorageVm|s-1-VM]to be alive? false Full logs for the HA worker thread 2014-11-15 13:35:21,642 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) Processing HAWork[1-HA-1-Running-Investigating] 2014-11-15 13:35:21,648 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) HA on VM[SecondaryStorageVm|s-1-VM] 2014-11-15 13:35:21,658 DEBUG [c.c.h.CheckOnAgentInvestigator] (HA-Worker-1:ctx-e0b5183c work-1) Unable to reach the agent for VM[SecondaryStorageVm|s-1-VM]: Resource [Host:1] is unreachable: Host 1: Host with specified id is not in the right state: Down 2014-11-15 13:35:21,659 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) SimpleInvestigator found VM[SecondaryStorageVm|s-1-VM]to be alive? null 2014-11-15 13:35:21,659 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) XenServerInvestigator found VM[SecondaryStorageVm|s-1-VM]to be alive? null 2014-11-15 13:35:21,659 DEBUG [c.c.h.UserVmDomRInvestigator] (HA-Worker-1:ctx-e0b5183c work-1) Not a User Vm, unable to determine state of VM[SecondaryStorageVm|s-1-VM] returning null 2014-11-15 13:35:21,659 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) PingInvestigator found VM[SecondaryStorageVm|s-1-VM]to be alive? null 2014-11-15 13:35:21,659 DEBUG [c.c.h.ManagementIPSystemVMInvestigator] (HA-Worker-1:ctx-e0b5183c work-1) Testing if VM[SecondaryStorageVm|s-1-VM] is alive 2014-11-15 13:35:21,670 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 2-5786281096240955453: Sending { Cmd , MgmtId: 1, via: 2(SimulatedAgent.08984ca6-967c-49b0-84c1-968076cd6992), Ver: v1, Flags: 100011, [{com.cloud.agent.api.PingTestCommand:{_computingHostIp:172.16.15.74,wait:20}}] } 2014-11-15 13:35:21,670 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 2-5786281096240955453: Executing: { Cmd , MgmtId: 1, via: 2(SimulatedAgent.08984ca6-967c-49b0-84c1-968076cd6992), Ver: v1, Flags: 100011, [{com.cloud.agent.api.PingTestCommand:{_computingHostIp:172.16.15.74,wait:20}}] } 2014-11-15 13:35:21,675 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 2-5786281096240955453: Received: { Ans: , MgmtId: 1, via: 2, Ver: v1, Flags: 10, { Answer } } 2014-11-15 13:35:21,675 DEBUG [c.c.h.AbstractInvestigatorImpl] (HA-Worker-1:ctx-e0b5183c work-1) host (172.16.15.74) cannot be pinged, returning null ('I don't know') 2014-11-15 13:35:21,678 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 3-248260929458798725: Sending { Cmd , MgmtId: 1, via: 3(SimulatedAgent.9bcff565-4ae7-492a-8e39-30d11f1cbbd7), Ver: v1, Flags: 100011, [{com.cloud.agent.api.PingTestCommand:{_computingHostIp:172.16.15.74,wait:20}}] } 2014-11-15 13:35:21,679 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 3-248260929458798725: Executing: { Cmd , MgmtId: 1, via: 3(SimulatedAgent.9bcff565-4ae7-492a-8e39-30d11f1cbbd7), Ver: v1, Flags: 100011, [{com.cloud.agent.api.PingTestCommand:{_computingHostIp:172.16.15.74,wait:20}}] } 2014-11-15 13:35:21,691 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 3-248260929458798725: Received: { Ans: , MgmtId: 1, via: 3, Ver: v1, Flags: 10, { Answer } } 2014-11-15 13:35:21,691 DEBUG [c.c.h.AbstractInvestigatorImpl] (HA-Worker-1:ctx-e0b5183c work-1) host (172.16.15.74) cannot be pinged, returning null ('I don't know') 2014-11-15 13:35:21,691 DEBUG [c.c.h.ManagementIPSystemVMInvestigator] (HA-Worker-1:ctx-e0b5183c work-1) unable to determine state of VM[SecondaryStorageVm|s-1-VM] returning null 2014-11-15
[jira] [Resolved] (CLOUDSTACK-7930) Do not allow to set invalid values for global settings which are of type Integer, Float
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-7930. Resolution: Fixed Do not allow to set invalid values for global settings which are of type Integer, Float --- Key: CLOUDSTACK-7930 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7930 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.5.0 Setting Integer/Float/Boolean to invalid values results in NullPointerException, NumberFormatException later in code. In case of network.throttling.rate parameter set to null results in deploy VM failure with message of null and no other exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7931) Setting Null for global network throttling params doesn't trigger suitable error, fails silently
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-7931. Resolution: Fixed Setting Null for global network throttling params doesn't trigger suitable error, fails silently Key: CLOUDSTACK-7931 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7931 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.5.0 Set global configs network.throttling.rate and vm.network.throttling.rate to NULL value. Then launch VM in a new network Result = VM fails to launch but it fails without any ERROR logs or suitable exceptions. A corresponding INFO log seems to have nothing but null Generally, for few global configs NULL is an acceptable value in some cases. If this is not the case, then we should not allow to set such a value for the config. The API should error out suitably. This is one issue. Further, it should throw an appropriate error when the deploy VM fails to design network. The error in this case is not handled suitably and there's nothing in ERROR logs as well. Looking at the below logs, it's impossible to figure out the reason for the failure of deploy VM. So at some point, if a user inadvertently sets it to NULL, neither does the updateConfiguration API result in error nor does the deployVirtualMachine throw a suitable error. Here's the log: 2014-11-13 13:29:15,584 DEBUG [c.c.a.ApiServlet] (catalina-exec-18:ctx-285ce7d9) ===START=== 10.144.7.5 – GET command=createNetworkresponse=jsonsessionkey=6ZKk3l0f4pdKU1yfDZxwF31YgCM%3DnetworkOfferingId=e8746c6b-e945-4084-9290-37cea253e262name=newtest1displayText=newtest1zoneId=b642a92a-3480-4818-99bf-6546a28df624_=1415866216789 2014-11-13 13:29:15,617 DEBUG [o.a.c.n.c.m.ContrailGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Refusing to design this network 2014-11-13 13:29:15,617 DEBUG [c.c.n.g.MidoNetGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) design called 2014-11-13 13:29:15,618 DEBUG [c.c.n.g.MidoNetGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Refusing to design this network, the physical isolation type is not MIDO 2014-11-13 13:29:15,619 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Refusing to design this network 2014-11-13 13:29:15,620 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Refusing to design this network 2014-11-13 13:29:15,621 DEBUG [c.c.n.g.OvsGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Refusing to design this network 2014-11-13 13:29:15,644 DEBUG [o.a.c.n.g.SspGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) SSP not configured to be active 2014-11-13 13:29:15,645 DEBUG [c.c.n.g.BrocadeVcsGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Refusing to design this network 2014-11-13 13:29:15,646 DEBUG [c.c.n.g.NuageVspGuestNetworkGuru] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Refusing to design this network 2014-11-13 13:29:15,648 DEBUG [o.a.c.e.o.NetworkOrchestrator] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) Releasing lock for Acct[467a4f66-698f-11e4-be18-42407779c24b-admin] 2014-11-13 13:29:15,688 DEBUG [c.c.a.ApiServlet] (catalina-exec-18:ctx-285ce7d9 ctx-5245ccb7) ===END=== 10.144.7.5 – GET command=createNetworkresponse=jsonsessionkey=6ZKk3l0f4pdKU1yfDZxwF31YgCM%3DnetworkOfferingId=e8746c6b-e945-4084-9290-37cea253e262name=newtest1displayText=newtest1zoneId=b642a92a-3480-4818-99bf-6546a28df624_=1415866216789 2014-11-13 13:29:15,727 DEBUG [c.c.a.ApiServlet] (catalina-exec-9:ctx-54781545) ===START=== 10.144.7.5 – GET command=deployVirtualMachineresponse=jsonsessionkey=6ZKk3l0f4pdKU1yfDZxwF31YgCM%3Dzoneid=b642a92a-3480-4818-99bf-6546a28df624templateid=f7df5ef0-698e-11e4-be18-42407779c24bhypervisor=XenServerserviceofferingid=04840780-04d0-4b41-847a-dda08ad460f4iptonetworklist%5B0%5D.networkid=c0e24f7a-fe03-4a3b-a11e-ab29150b803bdisplayname=throttlingvm1name=throttlingvm1_=1415866216945 2014-11-13 13:29:15,753 DEBUG [c.c.n.NetworkModelImpl] (catalina-exec-9:ctx-54781545 ctx-e87f4810) Service SecurityGroup is not supported in the network id=209 2014-11-13 13:29:15,777 DEBUG [c.c.v.UserVmManagerImpl] (catalina-exec-9:ctx-54781545 ctx-e87f4810) Allocating in the DB for vm 2014-11-13 13:29:15,793 DEBUG [c.c.v.VirtualMachineManagerImpl] (catalina-exec-9:ctx-54781545 ctx-e87f4810) Allocating entries for VM: VM[User|i-2-22-VM] 2014-11-13 13:29:15,794 DEBUG
[jira] [Resolved] (CLOUDSTACK-7758) Although API calls are failing, events tab shows them as successful
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-7758. Resolution: Fixed Although API calls are failing, events tab shows them as successful --- Key: CLOUDSTACK-7758 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7758 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.5.0 Like Deployment of VM is failing. But event tab shows them as Successfully completed starting VM. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7752) Management Server goes in infinite loop while creating a vm with tagged local data disk when the pool is not tagged
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-7752. Resolution: Fixed Management Server goes in infinite loop while creating a vm with tagged local data disk when the pool is not tagged --- Key: CLOUDSTACK-7752 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7752 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Steps to reproduce: Setup must have a single cluster with both local and shared storage. 1) Create a local disk offering and tag it T1 2) Deploy vm with shared root disk and local data disk Management server goes in an infinite loop. The vm is never started/expunged. Also this causes vmops.log size to go very high. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7930) Do not allow to set invalid values for global settings which are of type Integer, Float
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215949#comment-14215949 ] ASF GitHub Bot commented on CLOUDSTACK-7930: Github user karuturi commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/41#discussion_r20492616 --- Diff: server/src/com/cloud/configuration/ConfigurationManagerImpl.java --- @@ -725,6 +725,21 @@ private String validateConfigurationValue(String name, String value, String scop type = c.getType(); } +String errMsg = null; +try { +if (type.equals(Integer.class)) { +errMsg = There was error in trying to parse value: + value + . Please enter a valid integer value for parameter + name; +Integer.parseInt(value); +} else if (type.equals(Float.class)) { +errMsg = There was error in trying to parse value: + value + . Please enter a valid float value for parameter + name; +Float.parseFloat(value); --- End diff -- I understand that it will fail during parsing. But, we can string replace , with Do not allow to set invalid values for global settings which are of type Integer, Float --- Key: CLOUDSTACK-7930 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7930 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.5.0 Setting Integer/Float/Boolean to invalid values results in NullPointerException, NumberFormatException later in code. In case of network.throttling.rate parameter set to null results in deploy VM failure with message of null and no other exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7767) [Events] All events are not generated for snapshot creation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-7767. Resolution: Fixed [Events] All events are not generated for snapshot creation --- Key: CLOUDSTACK-7767 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7767 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Snapshot Affects Versions: 4.5.0 Environment: Latest build from 4.5 with commit [root@BPKxDmS ~]# cloudstack-sccs 562c89544e80dcd61ae5fd179eb8546de2598b33 Reporter: Sanjeev N Assignee: Anshul Gangwar Priority: Critical Fix For: 4.5.0 Attachments: cloud.dmp, management-server.rar [Events] All events are not generated for snapshot creation Steps to Reproduce: === 1.Bring up CS with latest build from 4.5 2.Deploy a vm using cent os template 3.Take a snapshot on the root disk of the vm 4.Verify the cloud.events table for the snapshot events We could see events with states created,sheduled,started and completed for vm,volume and template whereas there is only one event with state scheduled for snapshot creation. So by looking at the events user will not be able to find out whether the snaphot creation is completed of not. Following is the DB snippet: mysql select id,uuid,type,state,description from event where type in (SNAPSHOT.CREATE,VM.CREATE,VOLUME.CREATE,TEMPLATE.CREATE); +-+--+-+---++ | id | uuid | type| state | description | +-+--+-+---++ | 189 | 1f48cbef-648e-4728-9eb1-5178bea3b4fd | SNAPSHOT.CREATE | Scheduled | creating snapshot for volume: 10 | | 207 | 9162ed93-bd6c-4e78-8f4a-1836859f5009 | SNAPSHOT.CREATE | Scheduled | creating snapshot for volume: 15 | | 208 | 261b95a7-0a4d-45cd-9922-3cde8640ab02 | SNAPSHOT.CREATE | Scheduled | creating snapshot for volume: 15 | | 212 | e80e1383-944b-4ac9-bc86-70511de86c94 | SNAPSHOT.CREATE | Scheduled | creating snapshot for volume: 15 | | 168 | 518e4ae7-e506-4b93-a8b5-696777b91706 | TEMPLATE.CREATE | Completed | Successfully completed creating template. Id: 202 name: cent53 | | 193 | 3d20409e-a9e5-438a-9a00-2deb23ee87fe | TEMPLATE.CREATE | Created | Successfully created entity for creating template | | 194 | 528f823e-b817-4b9a-8935-2f57ac5a4c9b | TEMPLATE.CREATE | Scheduled | creating template: fromSnapRoot10 | | 195 | 9ab1d914-9f30-4a3d-8070-1fdce6827f6d | TEMPLATE.CREATE | Started | creating template. Template Id: 203 from snapshot Id: 1 | | 196 | d2676d55-84c8-4486-9aca-0f3eda74a4a7 | TEMPLATE.CREATE | Completed | Successfully completed creating template. Template Id: 203 from snapshot Id: 1 | | 154 | 3b9207d6-d120-4762-b9e3-423f849870d6 | VM.CREATE | Created | Successfully created entity for deploying Vm. Vm Id: 8 | | 155 | 7c47beb2-e105-478f-9575-e3ab1b2709ec | VM.CREATE | Scheduled | starting Vm. Vm Id: 8 | | 156 | 27718b57-b679-412b-b983-0f9cf7757930 | VM.CREATE | Started | starting Vm. Vm Id: 8 | | 159 | 6b5bece5-bfab-41c0-906e-8fbec2ddd2bf | VM.CREATE | Completed | Successfully completed starting Vm. Vm Id: 8 | | 170 | 66412dc3-fc03-4a2d-b796-807bd6ec096f | VM.CREATE | Created | Successfully created entity for deploying Vm. Vm Id: 10 | | 171 | a6c91812-9218-451c-a801-60652089ba7b | VM.CREATE | Scheduled | starting Vm. Vm Id: 10 | | 172 | 3f0cd706-ac3d-48a5-b4f9-a51d96e95dca | VM.CREATE | Started | starting Vm. Vm Id: 10 | | 175 | dde1bff2-5f68-43a9-a090-10718c3a14f3 | VM.CREATE | Completed | Successfully completed starting Vm. Vm Id: 10 | | 180 |
[jira] [Resolved] (CLOUDSTACK-7703) Cloudstack server endless loop when trying to create a volume while storage pool is full
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-7703. Resolution: Fixed Cloudstack server endless loop when trying to create a volume while storage pool is full Key: CLOUDSTACK-7703 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7703 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: Centos 6.5 Reporter: JF Vincent Assignee: Anshul Gangwar Priority: Critical Fix For: 4.5.0 When trying to create a VM, and thus a volume for it and the primary storage is full (over 90%), the managament server enter in and endless loop (extract below) and we have to restart it to exit this loop. 2014-10-14 11:39:20,701 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found for volume: Vol[5436|vm=5855|DATADISK] under cluster: 2 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable storagePools found under this Cluster: 2 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Could not find suitable Deployment Destination for this VM under any clusters, returning. 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Searching all possible resources under this Zone: 2 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Listing clusters in order of aggregate capacity, that have (atleast one host with) enough CPU and RAM capacity under this Zone: 2 2014-10-14 11:39:20,707 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Removing from the clusterId list these clusters from avoid set: [] 2014-10-14 11:39:20,714 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Checking resources in Cluster: 2 under Pod: 2 2014-10-14 11:39:20,714 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking for hosts in dc: 2 pod:2 cluster:2 2014-10-14 11:39:20,716 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) FirstFitAllocator has 3 hosts to check for allocation: [Host[-79-Routing], Host[-89-Routing], Host[-77-Routing]] 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Found 3 hosts for allocation after prioritization: [Host[-79-Routing], Host[-89-Routing], Host[-77-Routing]] 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking for speed=500Mhz, Ram=500 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host: 79 has cpu capability (cpu:8, speed:2399) to support requested CPU: 1 and requested speed: 500 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Checking if host: 79 has enough capacity for requested CPU: 500 and requested RAM: 524288000 , cpuOverprovisioningFactor: 4.0 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Hosts's actual total CPU: 19192 and CPU after applying overprovisioning: 76768 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free CPU: 57268 , Requested CPU: 500 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free RAM: 93916725248 , Requested RAM: 524288000 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host has enough CPU and RAM available 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) STATS: Can alloc CPU from host: 79, used: 19000, reserved: 500, actual total: 19192, total with
[jira] [Resolved] (CLOUDSTACK-7747) VM Snapshot - Support only for vm revert cases that will not result in VM state change
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-7747. Resolution: Fixed VM Snapshot - Support only for vm revert cases that will not result in VM state change -- Key: CLOUDSTACK-7747 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7747 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Currently we extend support for all the possible combinations .In cases were the Vm start changes from “Stopped” to “Running”, CS does not account for this VM’s capacity and VM start does not use our allocators. Following will be the only configuration we would have to support: 1.Revert a Running VM to a Disk and Memory Snapshot ( with and without quiesce option). 1.Revert a Stopped VM to a Disk Snapshot ( with and without quiesce option). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7541) Volume gets created with the size mentioned in the custom disk offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-7541. Resolution: Fixed Volume gets created with the size mentioned in the custom disk offering Key: CLOUDSTACK-7541 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7541 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Volumes Affects Versions: 4.5.0 Environment: latest build from 4.5 with commit 932ea253eb8c65821503ab9db301073cdb2a413e Reporter: Sanjeev N Assignee: Anshul Gangwar Priority: Critical Fix For: 4.5.0 Attachments: cloud.dmp, management-server.rar Volume gets created with the size mentioned in the custom disk offering Steps to reproduce: == 1.Bring up cs with latest build 2.Create custom disk offering with disk size say 2 3.Create data disk using this offering and provide disk size as 1 while creating data disk Expected Result: == Since the disk offering is of type custom , volume should be created with size given during volume creation instead of taking it from the disk offering. If the disk offering is custom then the volume creation must ignore the size given in the offering and should create volume with size provide while creating volume. Actual Result: === Disk got created with size mentioned in disk offering rather than the size given during volume creation time. Observations: === http://10.147.38.153:8096/client/api?command=createDiskOfferingisMirrored=falsename=customdisplaytext=customstorageType=sharedcacheMode=noneprovisioningType=thincustomized=truedisksize=2 { creatediskofferingresponse : { diskoffering : {id:2ddb8b79-9592-4b8c-8bd9-3d32c582873b,name:custom,displaytext:custom,disksize:2,created:2014-09-12T23:33:24+0530,iscustomized:true,storagetype:shared,provisioningtype:thin,displayoffering:true} } } http://10.147.38.153:8080/client/api?command=createVolumeresponse=jsonsessionkey=USf4e%2BpnzNiyWyq1PCeDFswjB%2BU%3Dname=customzoneId=2c67c83e-b8c3-42d0-a37b-b37287ac84dddiskOfferingId=2ddb8b79-9592-4b8c-8bd9-3d32c582873bsize=1_=1410525928417 { queryasyncjobresultresponse : {accountid:638d4e82-341f-11e4-a4c9-06097e23,userid:638d5ddc-341f-11e4-a4c9-06097e23,cmd:org.apache.cloudstack.api.command.admin.volume.CreateVolumeCmdByAdmin,jobstatus:1,jobprocstatus:0,jobresultcode:0,jobresulttype:object,jobresult:{volume:{id:42f24df4-b4ae-4b4c-80ce-ea1b5daf12bd,name:custom,zoneid:2c67c83e-b8c3-42d0-a37b-b37287ac84dd,zonename:zone1,type:DATADISK,provisioningtype:thin,size:2147483648,created:2014-09-12T23:34:32+0530,state:Allocated,account:admin,domainid:2caca782-341f-11e4-a4c9-06097e23,domain:ROOT,storagetype:shared,hypervisor:None,diskofferingid:2ddb8b79-9592-4b8c-8bd9-3d32c582873b,diskofferingname:custom,diskofferingdisplaytext:custom,destroyed:false,isextractable:true,tags:[],displayvolume:true,quiescevm:false,jobid:edf1a066-63b0-400b-bf15-4f77bf659206,jobstatus:0}},jobinstancetype:Volume,jobinstanceid:42f24df4-b4ae-4b4c-80ce-ea1b5daf12bd,created:2014-09-12T23:34:32+0530,jobid:edf1a066-63b0-400b-bf15-4f77bf659206} } -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7620) Put SNMP MIB file for snmp-alerts plugin in git repo
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-7620. Resolution: Fixed Put SNMP MIB file for snmp-alerts plugin in git repo Key: CLOUDSTACK-7620 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7620 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Currently it is available at https://cwiki.apache.org/confluence/download/attachments/30747160/CS-ROOT-MIB.mib?version=1modificationDate=1362442825000api=v2 for download. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7932) [Hyper-V] Wrong semantics for isVmAlive() method in HypervInvestigator
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-7932. Resolution: Fixed [Hyper-V] Wrong semantics for isVmAlive() method in HypervInvestigator -- Key: CLOUDSTACK-7932 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7932 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Fix For: 4.5.0 The isVmAlive() method should return null when it is unable to conclusively determine if the VM is alive or not. I ran some tests using Simulator and found that HypervInvestigator determined that VM is not alive. How can HypervInvestigator determine status of a VM running on Simulator or any other HV? 2014-11-15 13:35:21,692 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) HypervInvestigator found VM[SecondaryStorageVm|s-1-VM]to be alive? false Full logs for the HA worker thread 2014-11-15 13:35:21,642 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) Processing HAWork[1-HA-1-Running-Investigating] 2014-11-15 13:35:21,648 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) HA on VM[SecondaryStorageVm|s-1-VM] 2014-11-15 13:35:21,658 DEBUG [c.c.h.CheckOnAgentInvestigator] (HA-Worker-1:ctx-e0b5183c work-1) Unable to reach the agent for VM[SecondaryStorageVm|s-1-VM]: Resource [Host:1] is unreachable: Host 1: Host with specified id is not in the right state: Down 2014-11-15 13:35:21,659 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) SimpleInvestigator found VM[SecondaryStorageVm|s-1-VM]to be alive? null 2014-11-15 13:35:21,659 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) XenServerInvestigator found VM[SecondaryStorageVm|s-1-VM]to be alive? null 2014-11-15 13:35:21,659 DEBUG [c.c.h.UserVmDomRInvestigator] (HA-Worker-1:ctx-e0b5183c work-1) Not a User Vm, unable to determine state of VM[SecondaryStorageVm|s-1-VM] returning null 2014-11-15 13:35:21,659 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) PingInvestigator found VM[SecondaryStorageVm|s-1-VM]to be alive? null 2014-11-15 13:35:21,659 DEBUG [c.c.h.ManagementIPSystemVMInvestigator] (HA-Worker-1:ctx-e0b5183c work-1) Testing if VM[SecondaryStorageVm|s-1-VM] is alive 2014-11-15 13:35:21,670 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 2-5786281096240955453: Sending { Cmd , MgmtId: 1, via: 2(SimulatedAgent.08984ca6-967c-49b0-84c1-968076cd6992), Ver: v1, Flags: 100011, [{com.cloud.agent.api.PingTestCommand:{_computingHostIp:172.16.15.74,wait:20}}] } 2014-11-15 13:35:21,670 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 2-5786281096240955453: Executing: { Cmd , MgmtId: 1, via: 2(SimulatedAgent.08984ca6-967c-49b0-84c1-968076cd6992), Ver: v1, Flags: 100011, [{com.cloud.agent.api.PingTestCommand:{_computingHostIp:172.16.15.74,wait:20}}] } 2014-11-15 13:35:21,675 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 2-5786281096240955453: Received: { Ans: , MgmtId: 1, via: 2, Ver: v1, Flags: 10, { Answer } } 2014-11-15 13:35:21,675 DEBUG [c.c.h.AbstractInvestigatorImpl] (HA-Worker-1:ctx-e0b5183c work-1) host (172.16.15.74) cannot be pinged, returning null ('I don't know') 2014-11-15 13:35:21,678 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 3-248260929458798725: Sending { Cmd , MgmtId: 1, via: 3(SimulatedAgent.9bcff565-4ae7-492a-8e39-30d11f1cbbd7), Ver: v1, Flags: 100011, [{com.cloud.agent.api.PingTestCommand:{_computingHostIp:172.16.15.74,wait:20}}] } 2014-11-15 13:35:21,679 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 3-248260929458798725: Executing: { Cmd , MgmtId: 1, via: 3(SimulatedAgent.9bcff565-4ae7-492a-8e39-30d11f1cbbd7), Ver: v1, Flags: 100011, [{com.cloud.agent.api.PingTestCommand:{_computingHostIp:172.16.15.74,wait:20}}] } 2014-11-15 13:35:21,691 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 3-248260929458798725: Received: { Ans: , MgmtId: 1, via: 3, Ver: v1, Flags: 10, { Answer } } 2014-11-15 13:35:21,691 DEBUG [c.c.h.AbstractInvestigatorImpl] (HA-Worker-1:ctx-e0b5183c work-1) host (172.16.15.74) cannot be pinged, returning null ('I don't know') 2014-11-15 13:35:21,691 DEBUG [c.c.h.ManagementIPSystemVMInvestigator] (HA-Worker-1:ctx-e0b5183c work-1) unable to determine state of VM[SecondaryStorageVm|s-1-VM] returning null 2014-11-15 13:35:21,691 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) ManagementIPSysVMInvestigator found
[jira] [Resolved] (CLOUDSTACK-7929) Unhandled exception when setting negative value for throttling rate while creating network offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-7929. Resolution: Fixed Unhandled exception when setting negative value for throttling rate while creating network offering --- Key: CLOUDSTACK-7929 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7929 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Fix For: 4.5.0 Steps Create a network offering and specify -1 for network throttling rate. Result = Exception is not handled properly throwing a DB exception exposing the DB column names in the Logs and UI. Expected Result = -1 is generally an acceptable input for signifying infinite values or not applicable values. So we should allow -1 and translate it appropriately as no throttling applied. Or if we don't, we should handle the input correctly and throw a suitable error message for the user. Following is the exception seen presently in the logs (or through UI): [{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] } 2014-11-13 13:58:31,414 DEBUG [c.c.a.ApiServlet] (catalina-exec-8:ctx-ac230e40) ===START=== 10.144.7.5 – POST command=createNetworkOfferingresponse=jsonsessionkey=vL5F3A1A1pr98OOTv7eei G2jvBI%3D 2014-11-13 13:58:31,428 DEBUG [c.c.c.ConfigurationManagerImpl] (catalina-exec-8:ctx-ac230e40 ctx-60a6474c) Adding Firewall service with provider VirtualRouter 2014-11-13 13:58:31,432 DEBUG [c.c.c.ConfigurationManagerImpl] (catalina-exec-8:ctx-ac230e40 ctx-60a6474c) Adding network offering [Network Offering [0-Guest-test] 2014-11-13 13:58:31,435 DEBUG [c.c.u.d.T.Transaction] (catalina-exec-8:ctx-ac230e40 ctx-60a6474c) Rolling back the transaction: Time = 3 Name = catalina-exec-8; called by -TransactionLegac y.rollback:902-TransactionLegacy.removeUpTo:845-TransactionLegacy.close:669-TransactionContextInterceptor.invoke:36-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke :91-ReflectiveMethodInvocation.proceed:172-JdkDynamicAopProxy.invoke:204-$Proxy79.persist:-1-ConfigurationManagerImpl$11.doInTransaction:4218-ConfigurationManagerImpl$11.doInTransaction:420 9-Transaction$2.doInTransaction:57 2014-11-13 13:58:31,442 ERROR [c.c.a.ApiServer] (catalina-exec-8:ctx-ac230e40 ctx-60a6474c) unhandled exception executing api command: [Ljava.lang.String;@61bc5278 com.cloud.utils.exception.CloudRuntimeException: DB Exception on: com.mysql.jdbc.JDBC4PreparedStatement@27a103c3: INSERT INTO network_offerings (network_offerings.name, network_offerings.un ique_name, network_offerings.display_text, network_offerings.nw_rate, network_offerings.mc_rate, network_offerings.traffic_type, network_offerings.specify_vlan, network_offerings.system_onl y, network_offerings.service_offering_id, network_offerings.tags, network_offerings.default, network_offerings.availability, network_offerings.state, network_offerings.created, network_offe rings.guest_type, network_offerings.dedicated_lb_service, network_offerings.shared_source_nat_service, network_offerings.specify_ip_ranges, network_offerings.sort_key, network_offerings.uui d, network_offerings.redundant_router_service, network_offerings.conserve_mode, network_offerings.elastic_ip_service, network_offerings.eip_associate_public_ip, network_offerings.elastic_lb _service, network_offerings.inline, network_offerings.is_persistent, network_offerings.egress_default_policy, network_offerings.concurrent_connections, network_offerings.keep_alive_enabled, network_offerings.supports_streched_l2, network_offerings.internal_lb, network_offerings.public_lb) VALUES (_binary'test', _binary'test', _binary'test', -1, 10, 'Guest', 0, 0, null, null, 0, 'Optional', 'Disabled', '2014-11-13 08:28:31', 'Isolated', 0, 0, 0, 0, _binary'f8bf35f5-dd77-4fa8-83ff-af1f1e85ece3', 0, 1, 0, 0, 0, 0, 0, 1, null, 0, 0, 0, 0) at com.cloud.utils.db.GenericDaoBase.persist(GenericDaoBase.java:1400) at com.cloud.offerings.dao.NetworkOfferingDaoImpl.persist(NetworkOfferingDaoImpl.java:181) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at
[jira] [Resolved] (CLOUDSTACK-7688) Do not allow various operations which breaks VM Snapshots
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-7688. Resolution: Fixed Do not allow various operations which breaks VM Snapshots - Key: CLOUDSTACK-7688 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7688 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Anshul Gangwar Assignee: Anshul Gangwar Fix For: 4.5.0 VM snapshots stops working when following operations are performed on VM with VM snapshots 1. Volumes of VM are migrated to other storage 2. Add and remove NIC to/from VM 3. Attach and Detach volume to VM 4. Scale up/down of VM(change service offering) 5. Volume snapshot which is not major use case in this scenario 6. Resize volume 7. Live migration of VM which involves storage migration -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7930) Do not allow to set invalid values for global settings which are of type Integer, Float
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215960#comment-14215960 ] ASF GitHub Bot commented on CLOUDSTACK-7930: Github user karuturi commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/41#discussion_r20492860 --- Diff: server/src/com/cloud/configuration/ConfigurationManagerImpl.java --- @@ -725,6 +725,21 @@ private String validateConfigurationValue(String name, String value, String scop type = c.getType(); } +String errMsg = null; +try { +if (type.equals(Integer.class)) { +errMsg = There was error in trying to parse value: + value + . Please enter a valid integer value for parameter + name; +Integer.parseInt(value); +} else if (type.equals(Float.class)) { +errMsg = There was error in trying to parse value: + value + . Please enter a valid float value for parameter + name; +Float.parseFloat(value); +} +} catch (Exception e) { --- End diff -- catching top level exception and swallowing the stacktrace makes it really difficult during debugging. For end user, we anyway wont show the exception but only the message. Do not allow to set invalid values for global settings which are of type Integer, Float --- Key: CLOUDSTACK-7930 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7930 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.5.0 Setting Integer/Float/Boolean to invalid values results in NullPointerException, NumberFormatException later in code. In case of network.throttling.rate parameter set to null results in deploy VM failure with message of null and no other exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7932) [Hyper-V] Wrong semantics for isVmAlive() method in HypervInvestigator
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14215962#comment-14215962 ] ASF GitHub Bot commented on CLOUDSTACK-7932: Github user karuturi commented on the pull request: https://github.com/apache/cloudstack/pull/39#issuecomment-63441065 I dont see a case when it could return false then. [Hyper-V] Wrong semantics for isVmAlive() method in HypervInvestigator -- Key: CLOUDSTACK-7932 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7932 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Fix For: 4.5.0 The isVmAlive() method should return null when it is unable to conclusively determine if the VM is alive or not. I ran some tests using Simulator and found that HypervInvestigator determined that VM is not alive. How can HypervInvestigator determine status of a VM running on Simulator or any other HV? 2014-11-15 13:35:21,692 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) HypervInvestigator found VM[SecondaryStorageVm|s-1-VM]to be alive? false Full logs for the HA worker thread 2014-11-15 13:35:21,642 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) Processing HAWork[1-HA-1-Running-Investigating] 2014-11-15 13:35:21,648 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) HA on VM[SecondaryStorageVm|s-1-VM] 2014-11-15 13:35:21,658 DEBUG [c.c.h.CheckOnAgentInvestigator] (HA-Worker-1:ctx-e0b5183c work-1) Unable to reach the agent for VM[SecondaryStorageVm|s-1-VM]: Resource [Host:1] is unreachable: Host 1: Host with specified id is not in the right state: Down 2014-11-15 13:35:21,659 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) SimpleInvestigator found VM[SecondaryStorageVm|s-1-VM]to be alive? null 2014-11-15 13:35:21,659 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) XenServerInvestigator found VM[SecondaryStorageVm|s-1-VM]to be alive? null 2014-11-15 13:35:21,659 DEBUG [c.c.h.UserVmDomRInvestigator] (HA-Worker-1:ctx-e0b5183c work-1) Not a User Vm, unable to determine state of VM[SecondaryStorageVm|s-1-VM] returning null 2014-11-15 13:35:21,659 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-1:ctx-e0b5183c work-1) PingInvestigator found VM[SecondaryStorageVm|s-1-VM]to be alive? null 2014-11-15 13:35:21,659 DEBUG [c.c.h.ManagementIPSystemVMInvestigator] (HA-Worker-1:ctx-e0b5183c work-1) Testing if VM[SecondaryStorageVm|s-1-VM] is alive 2014-11-15 13:35:21,670 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 2-5786281096240955453: Sending { Cmd , MgmtId: 1, via: 2(SimulatedAgent.08984ca6-967c-49b0-84c1-968076cd6992), Ver: v1, Flags: 100011, [{com.cloud.agent.api.PingTestCommand:{_computingHostIp:172.16.15.74,wait:20}}] } 2014-11-15 13:35:21,670 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 2-5786281096240955453: Executing: { Cmd , MgmtId: 1, via: 2(SimulatedAgent.08984ca6-967c-49b0-84c1-968076cd6992), Ver: v1, Flags: 100011, [{com.cloud.agent.api.PingTestCommand:{_computingHostIp:172.16.15.74,wait:20}}] } 2014-11-15 13:35:21,675 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 2-5786281096240955453: Received: { Ans: , MgmtId: 1, via: 2, Ver: v1, Flags: 10, { Answer } } 2014-11-15 13:35:21,675 DEBUG [c.c.h.AbstractInvestigatorImpl] (HA-Worker-1:ctx-e0b5183c work-1) host (172.16.15.74) cannot be pinged, returning null ('I don't know') 2014-11-15 13:35:21,678 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 3-248260929458798725: Sending { Cmd , MgmtId: 1, via: 3(SimulatedAgent.9bcff565-4ae7-492a-8e39-30d11f1cbbd7), Ver: v1, Flags: 100011, [{com.cloud.agent.api.PingTestCommand:{_computingHostIp:172.16.15.74,wait:20}}] } 2014-11-15 13:35:21,679 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 3-248260929458798725: Executing: { Cmd , MgmtId: 1, via: 3(SimulatedAgent.9bcff565-4ae7-492a-8e39-30d11f1cbbd7), Ver: v1, Flags: 100011, [{com.cloud.agent.api.PingTestCommand:{_computingHostIp:172.16.15.74,wait:20}}] } 2014-11-15 13:35:21,691 DEBUG [c.c.a.t.Request] (HA-Worker-1:ctx-e0b5183c work-1) Seq 3-248260929458798725: Received: { Ans: , MgmtId: 1, via: 3, Ver: v1, Flags: 10, { Answer } } 2014-11-15 13:35:21,691 DEBUG [c.c.h.AbstractInvestigatorImpl] (HA-Worker-1:ctx-e0b5183c work-1) host (172.16.15.74) cannot be pinged, returning null ('I don't know') 2014-11-15 13:35:21,691 DEBUG [c.c.h.ManagementIPSystemVMInvestigator] (HA-Worker-1:ctx-e0b5183c work-1)
[jira] [Created] (CLOUDSTACK-7934) Cleanup issues in test_escalations_volumes.py
Ashutosk Kelkar created CLOUDSTACK-7934: --- Summary: Cleanup issues in test_escalations_volumes.py Key: CLOUDSTACK-7934 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7934 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Fix For: 4.5.0 Following test cases are failing during the cleanup operation. test_05_volume_snapshot test_10_volume_snapshots_pagination test_13_volume_custom_disk_size -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CLOUDSTACK-7383) [LXC][UI] dont show vm snapshot button in UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal reopened CLOUDSTACK-7383: still see bot take vm snapshot option and view vm snapshot option in instance-details view [LXC][UI] dont show vm snapshot button in UI Key: CLOUDSTACK-7383 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7383 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Jessica Wang Priority: Critical Fix For: 4.5.0 Attachments: vmsnap.png Repro steps: Vm snapshot is not supported in LXC so we should not show VM snapshot option in UI in instance tab , the way we do it for KVM .We dont show VM snapshot button in cae of KVM vm. Attaching snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7383) [LXC][UI] dont show vm snapshot button in UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal updated CLOUDSTACK-7383: --- Attachment: lxc.png [LXC][UI] dont show vm snapshot button in UI Key: CLOUDSTACK-7383 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7383 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Jessica Wang Priority: Critical Fix For: 4.5.0 Attachments: lxc.png, vmsnap.png Repro steps: Vm snapshot is not supported in LXC so we should not show VM snapshot option in UI in instance tab , the way we do it for KVM .We dont show VM snapshot button in cae of KVM vm. Attaching snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7460) [LXC][RHEl7] Agent installaion fails if Management server is already installed on the same machine
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damodar Reddy T updated CLOUDSTACK-7460: Priority: Minor (was: Major) [LXC][RHEl7] Agent installaion fails if Management server is already installed on the same machine -- Key: CLOUDSTACK-7460 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7460 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup, KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Damodar Reddy T Priority: Minor Fix For: Future Repro steps: on rhel 7 Machine. First install MS and try installing Agent on the same machine Bug: Agent installation will fail with following error : Transaction check error: file /var/log/cloudstack/agent from install of cloudstack-agent-4.5.0-SNAPSHOT.el7.x86_64 conflicts with file from package cloudstack-management-4.5.0-SNAPSHOT.el7.x86_64 Error Summary - Done -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7935) keep colons in the request to ACS
Remi Bergsma created CLOUDSTACK-7935: Summary: keep colons in the request to ACS Key: CLOUDSTACK-7935 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7935 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Cloudmonkey Reporter: Remi Bergsma Priority: Minor We run into an interesting issue with CloudMonkey today. Before 5.3 this worked, now it doesn't any more. Creating a private gateway on our SDN platform (lswitch instead of vlan id): (mccp_admin) create privategateway vpcid=da18a1a9-66da-427a-b2e6-bee31f08419e networkofferingid=222a66eb-626b-46e7-8ea0-1e2a1b80cff4 vlan=lswitch:d3b79b6a-eb65-47f6-982f-e78f18f8b7b1 gateway=10.71.25.3 ipaddress=10.71.25.12 netmask=255.255.255.192 Returns: Error Error: string 'lswitch%3Ad3b79b6a-eb65-47f6-982f-e78f18f8b7b1' has an unknown BroadcastDomainType. In the CloudStack logs: s=10.71.25.12netmask=255.255.255.192networkofferingid=222a66eb-626b-46e7-8ea0-1e2a1b80cff4response=jsonsignatureversion=3vlan=lswitch%253Ad3b79b6a-eb65-47f6-982f-e78f18f8b7b1vpcid=da18a1a9-66da-427a-b2e6-bee31f08419esignature=TuyC3d900X%2B88P6zJwz4NcN1RxY%3D 2014-11-17 14:32:26,178 DEBUG [c.c.n.v.VpcManagerImpl] (catalina-exec-10:ctx-b5bcc469 ctx-279b581f ctx-115c60e7) Creating Private gateway for VPC [VPC [483-SBP_VPC_MDMS] 2014-11-17 14:32:26,185 ERROR [c.c.a.ApiServer] (catalina-exec-10:ctx-b5bcc469 ctx-279b581f ctx-115c60e7) unhandled exception executing api command: createPrivateGateway com.cloud.utils.exception.CloudRuntimeException: string 'lswitch%3Ad3b79b6a-eb65-47f6-982f-e78f18f8b7b1' has an unknown BroadcastDomainType. It seems CloudMonkey replaces the : with %3A resulting in an invalid request. See this pull request for a solution that works: https://github.com/apache/cloudstack-cloudmonkey/pull/1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7935) keep colons in the request to ACS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14216122#comment-14216122 ] ASF GitHub Bot commented on CLOUDSTACK-7935: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack-cloudmonkey/pull/1#issuecomment-63460966 Created CLOUDSTACK-7935 for documentation purposes. See: https://issues.apache.org/jira/browse/CLOUDSTACK-7935 You can close this issue when you merge this change. Thanks! Remi keep colons in the request to ACS - Key: CLOUDSTACK-7935 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7935 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Cloudmonkey Reporter: Remi Bergsma Priority: Minor We run into an interesting issue with CloudMonkey today. Before 5.3 this worked, now it doesn't any more. Creating a private gateway on our SDN platform (lswitch instead of vlan id): (mccp_admin) create privategateway vpcid=da18a1a9-66da-427a-b2e6-bee31f08419e networkofferingid=222a66eb-626b-46e7-8ea0-1e2a1b80cff4 vlan=lswitch:d3b79b6a-eb65-47f6-982f-e78f18f8b7b1 gateway=10.71.25.3 ipaddress=10.71.25.12 netmask=255.255.255.192 Returns: Error Error: string 'lswitch%3Ad3b79b6a-eb65-47f6-982f-e78f18f8b7b1' has an unknown BroadcastDomainType. In the CloudStack logs: s=10.71.25.12netmask=255.255.255.192networkofferingid=222a66eb-626b-46e7-8ea0-1e2a1b80cff4response=jsonsignatureversion=3vlan=lswitch%253Ad3b79b6a-eb65-47f6-982f-e78f18f8b7b1vpcid=da18a1a9-66da-427a-b2e6-bee31f08419esignature=TuyC3d900X%2B88P6zJwz4NcN1RxY%3D 2014-11-17 14:32:26,178 DEBUG [c.c.n.v.VpcManagerImpl] (catalina-exec-10:ctx-b5bcc469 ctx-279b581f ctx-115c60e7) Creating Private gateway for VPC [VPC [483-SBP_VPC_MDMS] 2014-11-17 14:32:26,185 ERROR [c.c.a.ApiServer] (catalina-exec-10:ctx-b5bcc469 ctx-279b581f ctx-115c60e7) unhandled exception executing api command: createPrivateGateway com.cloud.utils.exception.CloudRuntimeException: string 'lswitch%3Ad3b79b6a-eb65-47f6-982f-e78f18f8b7b1' has an unknown BroadcastDomainType. It seems CloudMonkey replaces the : with %3A resulting in an invalid request. See this pull request for a solution that works: https://github.com/apache/cloudstack-cloudmonkey/pull/1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7515) [LXC] user VM is getting different mac than the one with router for the same VM in case of shared network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7515. -- [LXC] user VM is getting different mac than the one with router for the same VM in case of shared network -- Key: CLOUDSTACK-7515 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7515 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM, Network Controller Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Fix For: 4.5.0 Attachments: agen-user-vm.tar.gz, agent-router.tar.gz, management-server.log.2014-09-08.gz Repro steps: 1. Create a advanced zone with LXC hosts having 2 clusters .one cluster having one host and other having two host .all host are LXC 2. Create a shared Network 3. Create a VM using only shared network as default network Bug: Notice mac address that VM has is different than the one Router has for the same vm router VM shows cat /etc/dhcphosts.txt 06:2e:70:00:00:1d,set:10_147_31_148,10.147.31.148,VM-bb8425ca-d97a-48dc-a69d-7ceb3ba454e2,infinite 06:b7:8a:00:00:18,set:10_147_31_143,10.147.31.143,VM-afcdd0b3-59e0-4104-8fe8-f12b344c6336,infinite 06:45:08:00:00:19,set:10_147_31_144,10.147.31.144,VM-ef2bbfd7-59d1-4e43-97fb-1a1ac233be9b,infinite 06:e2:c6:00:00:1b,set:10_147_31_146,10.147.31.146,VM-f0e8245a-b382-45d7-a01d-e63c111fbef5,infinite For USER VM with IP 10.147.31.144 router has mac06:45:08:00:00:19 but VM has mac 06:4d:15:46:f3:c6 Ifconfig on VM shows ifconfig eth0: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 inet6 fe80::44d:15ff:fe46:f3c6 prefixlen 64 scopeid 0x20link ether 06:4d:15:46:f3:c6 txqueuelen 1000 (Ethernet) RX packets 1938 bytes 414054 (404.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 14 bytes 2700 (2.6 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73UP,LOOPBACK,RUNNING mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10host loop txqueuelen 0 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Additional information : dumpxml of LXC vm shows same mac which is available with router Notice even IP is not set for such VMs Attaching Ms and agent logs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7935) keep colons in the request to ACS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma closed CLOUDSTACK-7935. keep colons in the request to ACS - Key: CLOUDSTACK-7935 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7935 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Cloudmonkey Reporter: Remi Bergsma Priority: Minor We run into an interesting issue with CloudMonkey today. Before 5.3 this worked, now it doesn't any more. Creating a private gateway on our SDN platform (lswitch instead of vlan id): (mccp_admin) create privategateway vpcid=da18a1a9-66da-427a-b2e6-bee31f08419e networkofferingid=222a66eb-626b-46e7-8ea0-1e2a1b80cff4 vlan=lswitch:d3b79b6a-eb65-47f6-982f-e78f18f8b7b1 gateway=10.71.25.3 ipaddress=10.71.25.12 netmask=255.255.255.192 Returns: Error Error: string 'lswitch%3Ad3b79b6a-eb65-47f6-982f-e78f18f8b7b1' has an unknown BroadcastDomainType. In the CloudStack logs: s=10.71.25.12netmask=255.255.255.192networkofferingid=222a66eb-626b-46e7-8ea0-1e2a1b80cff4response=jsonsignatureversion=3vlan=lswitch%253Ad3b79b6a-eb65-47f6-982f-e78f18f8b7b1vpcid=da18a1a9-66da-427a-b2e6-bee31f08419esignature=TuyC3d900X%2B88P6zJwz4NcN1RxY%3D 2014-11-17 14:32:26,178 DEBUG [c.c.n.v.VpcManagerImpl] (catalina-exec-10:ctx-b5bcc469 ctx-279b581f ctx-115c60e7) Creating Private gateway for VPC [VPC [483-SBP_VPC_MDMS] 2014-11-17 14:32:26,185 ERROR [c.c.a.ApiServer] (catalina-exec-10:ctx-b5bcc469 ctx-279b581f ctx-115c60e7) unhandled exception executing api command: createPrivateGateway com.cloud.utils.exception.CloudRuntimeException: string 'lswitch%3Ad3b79b6a-eb65-47f6-982f-e78f18f8b7b1' has an unknown BroadcastDomainType. It seems CloudMonkey replaces the : with %3A resulting in an invalid request. See this pull request for a solution that works: https://github.com/apache/cloudstack-cloudmonkey/pull/1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7935) keep colons in the request to ACS
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Remi Bergsma resolved CLOUDSTACK-7935. -- Resolution: Fixed Fixed by: https://git-wip-us.apache.org/repos/asf?p=cloudstack-cloudmonkey.git;a=commitdiff;h=18feb8074e47042470185dc74744dc075e43a7b6 keep colons in the request to ACS - Key: CLOUDSTACK-7935 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7935 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Cloudmonkey Reporter: Remi Bergsma Priority: Minor We run into an interesting issue with CloudMonkey today. Before 5.3 this worked, now it doesn't any more. Creating a private gateway on our SDN platform (lswitch instead of vlan id): (mccp_admin) create privategateway vpcid=da18a1a9-66da-427a-b2e6-bee31f08419e networkofferingid=222a66eb-626b-46e7-8ea0-1e2a1b80cff4 vlan=lswitch:d3b79b6a-eb65-47f6-982f-e78f18f8b7b1 gateway=10.71.25.3 ipaddress=10.71.25.12 netmask=255.255.255.192 Returns: Error Error: string 'lswitch%3Ad3b79b6a-eb65-47f6-982f-e78f18f8b7b1' has an unknown BroadcastDomainType. In the CloudStack logs: s=10.71.25.12netmask=255.255.255.192networkofferingid=222a66eb-626b-46e7-8ea0-1e2a1b80cff4response=jsonsignatureversion=3vlan=lswitch%253Ad3b79b6a-eb65-47f6-982f-e78f18f8b7b1vpcid=da18a1a9-66da-427a-b2e6-bee31f08419esignature=TuyC3d900X%2B88P6zJwz4NcN1RxY%3D 2014-11-17 14:32:26,178 DEBUG [c.c.n.v.VpcManagerImpl] (catalina-exec-10:ctx-b5bcc469 ctx-279b581f ctx-115c60e7) Creating Private gateway for VPC [VPC [483-SBP_VPC_MDMS] 2014-11-17 14:32:26,185 ERROR [c.c.a.ApiServer] (catalina-exec-10:ctx-b5bcc469 ctx-279b581f ctx-115c60e7) unhandled exception executing api command: createPrivateGateway com.cloud.utils.exception.CloudRuntimeException: string 'lswitch%3Ad3b79b6a-eb65-47f6-982f-e78f18f8b7b1' has an unknown BroadcastDomainType. It seems CloudMonkey replaces the : with %3A resulting in an invalid request. See this pull request for a solution that works: https://github.com/apache/cloudstack-cloudmonkey/pull/1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6624) Unable to create new Network Offerings via UI with Specify VLAN option set
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14216345#comment-14216345 ] Rohit Yadav commented on CLOUDSTACK-6624: - Hi [~jessicawang], thanks and please go ahead to help fix it. Please backport changes to the 4.3 branch as well, or do it for 4.5/master and I can help with backporting to 4.3 and 4.4. Unable to create new Network Offerings via UI with Specify VLAN option set -- Key: CLOUDSTACK-6624 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6624 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: Geoff Higgibottom Assignee: Rohit Yadav Priority: Critical Labels: UI Fix For: 4.3.1 When creating a new network offering with the Specify VLAN option set, the Specify IP Option should also be set automatically. The UI is no longer sending this parameter in the API string so the Network Offering has an invalid configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7857) CitrixResourceBase wrongly calculates total memory on hosts with a lot of memory and large Dom0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14216355#comment-14216355 ] Joris van Lieshout commented on CLOUDSTACK-7857: I'm not too familiar with mem overhead on other hypervisors. You would think the formula would be some what the same. I understand that ACS has to be as flexible as possible but what if the logic of calculating free mem is moved to the hypervisor plugin so the logic in calculating can be specific but the outcome used by generic processes the same? I'm not a developer so my apologies if my comment does not make any sense. In the end any hypervisor should be able to provide some information about available memory, either by calculation of with a direct metric. Perhaps this will always be something hypervisor specifies...? CitrixResourceBase wrongly calculates total memory on hosts with a lot of memory and large Dom0 --- Key: CLOUDSTACK-7857 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7857 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: Future, 4.3.0, 4.4.0, 4.5.0, 4.3.1, 4.4.1, 4.6.0 Reporter: Joris van Lieshout Priority: Blocker We have hosts with 256GB memory and 4GB dom0. During startup ACS calculates available memory using this formula: CitrixResourceBase.java protected void fillHostInfo ram = (long) ((ram - dom0Ram - _xs_memory_used) * _xs_virtualization_factor); In our situation: ram = 274841497600 dom0Ram = 4269801472 _xs_memory_used = 128 * 1024 * 1024L = 134217728 _xs_virtualization_factor = 63.0/64.0 = 0,984375 (274841497600 - 4269801472 - 134217728) * 0,984375 = 266211892800 This is in fact not the actual amount of memory available for instances. The difference in our situation is a little less then 1GB. On this particular hypervisor Dom0+Xen uses about 9GB. As the comment above the definition of XsMemoryUsed allready stated it's time to review this logic. //Hypervisor specific params with generic value, may need to be overridden for specific versions The effect of this bug is that when you put a hypervisor in maintenance it might try to move instances (usually small instances (1GB)) to a host that in fact does not have enought free memory. This exception is thrown: ERROR [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-3:ctx-09aca6e9 work-8981) Terminating HAWork[8981-Migration-4482-Running-Migrating] com.cloud.utils.exception.CloudRuntimeException: Unable to migrate due to Catch Exception com.cloud.utils.exception.CloudRuntimeException: Migration failed due to com.cloud.utils.exception.CloudRuntim eException: Unable to migrate VM(r-4482-VM) from host(6805d06c-4d5b-4438-a245-7915e93041d9) due to Task failed! Task record: uuid: 645b63c8-1426-b412-7b6a-13d61ee7ab2e nameLabel: Async.VM.pool_migrate nameDescription: allowedOperations: [] currentOperations: {} created: Thu Nov 06 13:44:14 CET 2014 finished: Thu Nov 06 13:44:14 CET 2014 status: failure residentOn: com.xensource.xenapi.Host@b42882c6 progress: 1.0 type: none/ result: errorInfo: [HOST_NOT_ENOUGH_FREE_MEMORY, 272629760, 263131136] otherConfig: {} subtaskOf: com.xensource.xenapi.Task@aaf13f6f subtasks: [] at com.cloud.vm.VirtualMachineManagerImpl.migrate(VirtualMachineManagerImpl.java:1840) at com.cloud.vm.VirtualMachineManagerImpl.migrateAway(VirtualMachineManagerImpl.java:2214) at com.cloud.ha.HighAvailabilityManagerImpl.migrate(HighAvailabilityManagerImpl.java:610) at com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.runWithContext(HighAvailabilityManagerImpl.java:865) at com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.access$000(HighAvailabilityManagerImpl.java:822) at com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread$1.run(HighAvailabilityManagerImpl.java:834) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.run(HighAvailabilityManagerImpl.java:831) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7613) [UI]CPU Sockets page does not display XenServer 6.5 Information
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Mada updated CLOUDSTACK-7613: - Attachment: sailajacloud_usage.sql sailajacloud.sql [UI]CPU Sockets page does not display XenServer 6.5 Information --- Key: CLOUDSTACK-7613 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7613 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: Sailaja Mada Assignee: Sailaja Mada Fix For: 4.5.0 Attachments: listCPUsocktesUI.png, sailajacloud.sql, sailajacloud_usage.sql Steps: 1. Install and configure Adv zone with XS 6.5 2. Tried to view CPU Sockets page from Infrastructure page Observation: 1. It is calling list hosts by XenServer hypervisor and its receiving the count 2 for XS 6.5. But its displayed in the UI. Attached snap. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7613) [UI]CPU Sockets page does not display XenServer 6.5 Information
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailaja Mada updated CLOUDSTACK-7613: - Assignee: Jessica Wang (was: Sailaja Mada) [UI]CPU Sockets page does not display XenServer 6.5 Information --- Key: CLOUDSTACK-7613 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7613 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: Sailaja Mada Assignee: Jessica Wang Fix For: 4.5.0 Attachments: listCPUsocktesUI.png, sailajacloud.sql, sailajacloud_usage.sql Steps: 1. Install and configure Adv zone with XS 6.5 2. Tried to view CPU Sockets page from Infrastructure page Observation: 1. It is calling list hosts by XenServer hypervisor and its receiving the count 2 for XS 6.5. But its displayed in the UI. Attached snap. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7498) [UI] Register ISO option is failing to invoke ISO registration page with ReferenceError: osTypeObjs is not defined
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang reassigned CLOUDSTACK-7498: Assignee: Jessica Wang (was: Brian Federle) [UI] Register ISO option is failing to invoke ISO registration page with ReferenceError: osTypeObjs is not defined -- Key: CLOUDSTACK-7498 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7498 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: Sailaja Mada Assignee: Jessica Wang Priority: Critical Attachments: RegisterISOFailing.png, registerisoUI.png Steps: 1. Install 4.5 cloudstack 2. Access Management Server UI and tried register ISO Observations : 1. It is not invoking Register ISO page and failing with ReferenceError: osTypeObjs is not defined Attached the screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7498) [UI] Register ISO option is failing to invoke ISO registration page with ReferenceError: osTypeObjs is not defined
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14216698#comment-14216698 ] ASF subversion and git services commented on CLOUDSTACK-7498: - Commit ade2517a4783526f7ad9c22714beb2b71a3c2051 in cloudstack's branch refs/heads/4.5 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ade2517 ] CLOUDSTACK-7498: UI ISO Register ISO action a javascript error osTypeObjs is not defined comes and goes. [UI] Register ISO option is failing to invoke ISO registration page with ReferenceError: osTypeObjs is not defined -- Key: CLOUDSTACK-7498 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7498 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: Sailaja Mada Assignee: Jessica Wang Priority: Critical Attachments: RegisterISOFailing.png, registerisoUI.png Steps: 1. Install 4.5 cloudstack 2. Access Management Server UI and tried register ISO Observations : 1. It is not invoking Register ISO page and failing with ReferenceError: osTypeObjs is not defined Attached the screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7498) [UI] Register ISO option is failing to invoke ISO registration page with ReferenceError: osTypeObjs is not defined
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14216699#comment-14216699 ] ASF subversion and git services commented on CLOUDSTACK-7498: - Commit 0e2299d933e732465cc6968bf72e817c6058a630 in cloudstack's branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0e2299d ] CLOUDSTACK-7498: UI ISO Register ISO action a javascript error osTypeObjs is not defined comes and goes. [UI] Register ISO option is failing to invoke ISO registration page with ReferenceError: osTypeObjs is not defined -- Key: CLOUDSTACK-7498 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7498 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: Sailaja Mada Assignee: Jessica Wang Priority: Critical Attachments: RegisterISOFailing.png, registerisoUI.png Steps: 1. Install 4.5 cloudstack 2. Access Management Server UI and tried register ISO Observations : 1. It is not invoking Register ISO page and failing with ReferenceError: osTypeObjs is not defined Attached the screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7498) [UI] Register ISO option is failing to invoke ISO registration page with ReferenceError: osTypeObjs is not defined
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-7498. -- Resolution: Fixed [UI] Register ISO option is failing to invoke ISO registration page with ReferenceError: osTypeObjs is not defined -- Key: CLOUDSTACK-7498 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7498 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: Sailaja Mada Assignee: Jessica Wang Priority: Critical Attachments: RegisterISOFailing.png, registerisoUI.png Steps: 1. Install 4.5 cloudstack 2. Access Management Server UI and tried register ISO Observations : 1. It is not invoking Register ISO page and failing with ReferenceError: osTypeObjs is not defined Attached the screenshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7936) System VM's are getting stuck in starting mode after Hypervisor reboot
Dusan Batas created CLOUDSTACK-7936: --- Summary: System VM's are getting stuck in starting mode after Hypervisor reboot Key: CLOUDSTACK-7936 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7936 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.1.1 Environment: Xenserver 6.2 SP1, Cloudstack 4.4.1 on CentOS 6.4 (x86_64) Reporter: Dusan Batas once a Xenserver 6.2 (running system VMs) gets rebooted, Infrastructure - Sytem VMs will show VM State=Starting and Agent State=Disconnected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6624) Unable to create new Network Offerings via UI with Specify VLAN option set
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14216860#comment-14216860 ] ASF subversion and git services commented on CLOUDSTACK-6624: - Commit a4ebc31d9c6ca6d0a4778602280e84394737e139 in cloudstack's branch refs/heads/4.5 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a4ebc31 ] CLOUDSTACK-6624: UI create network offering cloudStack does NOT support specifyIpRanges for isolated network - fix a bug that wrongly sends specifyIpRanges=true to createNetworkOffering API. Unable to create new Network Offerings via UI with Specify VLAN option set -- Key: CLOUDSTACK-6624 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6624 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: Geoff Higgibottom Assignee: Rohit Yadav Priority: Critical Labels: UI Fix For: 4.3.1 When creating a new network offering with the Specify VLAN option set, the Specify IP Option should also be set automatically. The UI is no longer sending this parameter in the API string so the Network Offering has an invalid configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6624) Unable to create new Network Offerings via UI with Specify VLAN option set
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14216861#comment-14216861 ] ASF subversion and git services commented on CLOUDSTACK-6624: - Commit 880ab4392dd251c87af60660f623f9f07ee17c03 in cloudstack's branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=880ab43 ] CLOUDSTACK-6624: UI create network offering cloudStack does NOT support specifyIpRanges for isolated network - fix a bug that wrongly sends specifyIpRanges=true to createNetworkOffering API. Unable to create new Network Offerings via UI with Specify VLAN option set -- Key: CLOUDSTACK-6624 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6624 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: Geoff Higgibottom Assignee: Rohit Yadav Priority: Critical Labels: UI Fix For: 4.3.1 When creating a new network offering with the Specify VLAN option set, the Specify IP Option should also be set automatically. The UI is no longer sending this parameter in the API string so the Network Offering has an invalid configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6624) Unable to create new Network Offerings via UI with Specify VLAN option set
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14216870#comment-14216870 ] Jessica Wang commented on CLOUDSTACK-6624: -- Rohit, I just fixed it in 4.5 branch and master branch. Please backport it to 4.3 and 4.4 branch. thank you. Jessica Unable to create new Network Offerings via UI with Specify VLAN option set -- Key: CLOUDSTACK-6624 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6624 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: Geoff Higgibottom Assignee: Rohit Yadav Priority: Critical Labels: UI Fix For: 4.3.1 When creating a new network offering with the Specify VLAN option set, the Specify IP Option should also be set automatically. The UI is no longer sending this parameter in the API string so the Network Offering has an invalid configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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=14216920#comment-14216920 ] ASF subversion and git services commented on CLOUDSTACK-5426: - Commit 968ca060eea66ba7fe1853c6685069fe8b63b8f2 in cloudstack's branch refs/heads/4.5 from [~prachidamle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=968ca06 ] CLOUDSTACK-5853 cannot deploy vm with differing service storage tag and data disk storage tag Changes: - Reverting Marcus's fix since this issue has already fixed by https://issues.apache.org/jira/browse/CLOUDSTACK-5426 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.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5853) cannot deploy vm with differing service storage tag and data disk storage tag
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14216919#comment-14216919 ] ASF subversion and git services commented on CLOUDSTACK-5853: - Commit 968ca060eea66ba7fe1853c6685069fe8b63b8f2 in cloudstack's branch refs/heads/4.5 from [~prachidamle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=968ca06 ] CLOUDSTACK-5853 cannot deploy vm with differing service storage tag and data disk storage tag Changes: - Reverting Marcus's fix since this issue has already fixed by https://issues.apache.org/jira/browse/CLOUDSTACK-5426 cannot deploy vm with differing service storage tag and data disk storage tag - Key: CLOUDSTACK-5853 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5853 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.3.0, 4.4.0 Reporter: Marcus Sorensen Assignee: Prachi Damle Priority: Critical Fix For: 4.4.0, 4.5.0 Create two storage pools, one with storage tag X, one with storage tag Y. Create a service offering with storage tag X. Create a disk offering with storage tag Y. Attempt to deploy a virtual machine with a datadisk, using given offerings, it fails. Deployment planner keeps a global object 'avoid'. It loops through each volume to be created, asking storage allocators for matching pools, passing this avoid object. First disk matches a pool or pools, adds ALL other pools to avoid object, then deployment planner attaches matching pools to a list for that disk. Second disk matches a pool, adds all other pools to avoid object, then deployment planner says wait, matching pool is in avoid, can't use it. Oops. In fact, at this point ALL pools are in avoid (unless there are other pools that have both tags). Need to remove matching pool from the avoid set during each select phase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7559) After migrating root volume to other cluster wide storage, start VM is not running the VM with root disk from new storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14216918#comment-14216918 ] ASF subversion and git services commented on CLOUDSTACK-7559: - Commit 7f548940450887e691b3c10b5487a49f0d75b63c in cloudstack's branch refs/heads/4.5 from [~prachidamle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7f54894 ] CLOUDSTACK-7559 After migrating root volume to other cluster wide storage, start VM is not running the VM with root disk from new storage. Changes: - During VM start, do not use the last host Id, if the host's cluster does not match the cluster provided in the deployment plan. After migrating root volume to other cluster wide storage, start VM is not running the VM with root disk from new storage. -- Key: CLOUDSTACK-7559 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7559 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.5.0 Environment: 1zone ,1pod, 2 clusters with ESXi HV each cluster wide primary storage. Reporter: manasaveloori Assignee: Prachi Damle Priority: Critical Fix For: 4.5.0 Attachments: management-server.log.rar 1. 2 clusters C1 and C2 with PS1 and PS2(cluster wide both) 2. Deploy a VM with data disk under cluster C1. 3. stop the VM and detach the data disk. 4. Migrate the root volume to PS2. 5. Start the VM. Observed : Initially vm deployment failed and then root volume migrated back to PS1 and then VM started. Observed the following in MS logs: 2014-09-15 17:02:07,096 ERROR [c.c.v.VmWorkJobHandlerProxy] (Work-Job-Executor-18:ctx-a3ba0611 job-911/job-912 ctx-769e4a3b) Invocation exception, caused by: com.cloud.exception.ResourceUnavailableException: Resource [Cluster:1] is unreachable: Root volume is ready in different cluster, Deployment plan provided cannot be satisfied, unable to create a deployment for VM[User|i-2-59-VM] Attaching the Mslogs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7559) After migrating root volume to other cluster wide storage, start VM is not running the VM with root disk from new storage.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Damle resolved CLOUDSTACK-7559. -- Resolution: Fixed After migrating root volume to other cluster wide storage, start VM is not running the VM with root disk from new storage. -- Key: CLOUDSTACK-7559 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7559 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.5.0 Environment: 1zone ,1pod, 2 clusters with ESXi HV each cluster wide primary storage. Reporter: manasaveloori Assignee: Prachi Damle Priority: Critical Fix For: 4.5.0 Attachments: management-server.log.rar 1. 2 clusters C1 and C2 with PS1 and PS2(cluster wide both) 2. Deploy a VM with data disk under cluster C1. 3. stop the VM and detach the data disk. 4. Migrate the root volume to PS2. 5. Start the VM. Observed : Initially vm deployment failed and then root volume migrated back to PS1 and then VM started. Observed the following in MS logs: 2014-09-15 17:02:07,096 ERROR [c.c.v.VmWorkJobHandlerProxy] (Work-Job-Executor-18:ctx-a3ba0611 job-911/job-912 ctx-769e4a3b) Invocation exception, caused by: com.cloud.exception.ResourceUnavailableException: Resource [Cluster:1] is unreachable: Root volume is ready in different cluster, Deployment plan provided cannot be satisfied, unable to create a deployment for VM[User|i-2-59-VM] Attaching the Mslogs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-5853) cannot deploy vm with differing service storage tag and data disk storage tag
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Damle resolved CLOUDSTACK-5853. -- Resolution: Fixed Fix by Marcus has been reverted. This issue is already fixed by https://issues.apache.org/jira/browse/CLOUDSTACK-5426 cannot deploy vm with differing service storage tag and data disk storage tag - Key: CLOUDSTACK-5853 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5853 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.3.0, 4.4.0 Reporter: Marcus Sorensen Assignee: Prachi Damle Priority: Critical Fix For: 4.4.0, 4.5.0 Create two storage pools, one with storage tag X, one with storage tag Y. Create a service offering with storage tag X. Create a disk offering with storage tag Y. Attempt to deploy a virtual machine with a datadisk, using given offerings, it fails. Deployment planner keeps a global object 'avoid'. It loops through each volume to be created, asking storage allocators for matching pools, passing this avoid object. First disk matches a pool or pools, adds ALL other pools to avoid object, then deployment planner attaches matching pools to a list for that disk. Second disk matches a pool, adds all other pools to avoid object, then deployment planner says wait, matching pool is in avoid, can't use it. Oops. In fact, at this point ALL pools are in avoid (unless there are other pools that have both tags). Need to remove matching pool from the avoid set during each select phase. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7746) Baremetal related script erros seen on router console
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14217007#comment-14217007 ] Sudha Ponnaganti commented on CLOUDSTACK-7746: -- Can this be fixed? Baremetal related script erros seen on router console - Key: CLOUDSTACK-7746 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7746 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Environment: Build from master Reporter: Sangeetha Hariharan Assignee: frank zhang Priority: Critical Fix For: 4.5.0 Attachments: router.png Baremetal related script erros seen on router console. Advanced zone set up with 3 xenserver hosts in a cluster. When logging into the console view of router , following script errors are seen: /opt/cloud/bin/baremetal-vr.py:159: SyntaxWarning : name 'server' is assigned to before glocal declaration. .. Attached is the screen shot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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 ] Animesh Chaturvedi updated CLOUDSTACK-3607: --- Assignee: Amogh Vasekar 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: Amogh Vasekar Fix For: 4.4.0, 4.5.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.3.4#6332)
[jira] [Updated] (CLOUDSTACK-3952) Persist VR nic details in DB for additional public ranges
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-3952: --- Assignee: Kishan Kavala Persist VR nic details in DB for additional public ranges - Key: CLOUDSTACK-3952 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3952 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Reporter: Kishan Kavala Assignee: Kishan Kavala Fix For: 4.4.0, 4.5.0 For non-vpcs VR, nics are dynamically created for addtional IP ranges with different Vlan. Prepare fro migration doesn't setup the destination host correctly due to this and migration fails. Temporary workaround was added as part of CLOUDSTACK-3439 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=14217072#comment-14217072 ] Amogh Vasekar commented on CLOUDSTACK-3607: --- Fixed already as a part of guest OS changes. mysql select * from guest_os_hypervisor where guest_os_id not in (select id from guest_os); Empty set (0.01 sec) The table is now used for guest OS mappings coming from DB rather than hardcoded 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: Amogh Vasekar Fix For: 4.4.0, 4.5.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.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6719) OVS:VPC:UI wizard allowing to add non OVS enabled network to distributed VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-6719: --- Fix Version/s: (was: 4.5.0) Future OVS:VPC:UI wizard allowing to add non OVS enabled network to distributed VPC Key: CLOUDSTACK-6719 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6719 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Reporter: sadhu suresh Fix For: Future problem:OVS:VPC:UI: Add new tier wizard allowing to add non OVS enabled network to VPC created with OVS+distributed VPC VR Steps to Reprodude: 1.Bring up CS in advanced zon 2.create a vpc offering with OVS and along with other all supported services 3. create a VPC with above network offering 4.try to create non ovs network(i.e network created default isolated vpc offering) on ovs based VPC. actual result: allowing to add non OVS enabled network to OVS enabled VPC expected result: it should not allow to add non OVS enabled network to OVS enabled VPC. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (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 ] Amogh Vasekar resolved CLOUDSTACK-3607. --- Resolution: Fixed 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: Amogh Vasekar Fix For: 4.4.0, 4.5.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.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6881) MS:IPv4 Incorrect IPv4 address as iptonetworklist param raises insufficient address capacity
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-6881: --- Fix Version/s: (was: 4.5.0) Future MS:IPv4 Incorrect IPv4 address as iptonetworklist param raises insufficient address capacity Key: CLOUDSTACK-6881 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6881 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Reporter: Parth Jagirdar Fix For: Future We need a mechanism to validate 0's followed by a number in IPv4 addressing. To reproduce, deploy a VM with static IPv4 where there is a single digit number followed by a 0. Example, 10.2.2.02 API should return an appropriate error, This validation can be performed using JS as a preventive method. Refer to following.. Observed in dual stack. 2014-06-09 11:44:47,608 DEBUG [o.a.c.i.RoleBasedEntityAccessChecker] (catalina-exec-7:ctx-8d87d71b ctx-fc6ae1da) IAM access check for 2-null-null-SystemCapability from cache: true 2014-06-09 11:44:47,608 DEBUG [c.c.u.AccountManagerImpl] (catalina-exec-7:ctx-8d87d71b ctx-fc6ae1da) Root Access granted to Acct[298be2e2-df9d-11e3-98fe-ced18bec4952-admin] by RoleBasedEntityAccessChecker 2014-06-09 11:44:47,609 DEBUG [o.a.c.i.RoleBasedEntityAccessChecker] (catalina-exec-7:ctx-8d87d71b ctx-fc6ae1da) IAM access check for 2-null-null-DomainCapability from cache: false 2014-06-09 11:44:47,610 DEBUG [o.a.c.i.RoleBasedEntityAccessChecker] (catalina-exec-7:ctx-8d87d71b ctx-fc6ae1da) IAM access check for 2-null-null-DomainResourceCapability from cache: false 2014-06-09 11:44:47,611 DEBUG [c.c.n.NetworkModelImpl] (catalina-exec-7:ctx-8d87d71b ctx-fc6ae1da) Service SecurityGroup is not supported in the network id=222 2014-06-09 11:44:47,626 DEBUG [c.c.v.UserVmManagerImpl] (catalina-exec-7:ctx-8d87d71b ctx-fc6ae1da) Allocating in the DB for vm 2014-06-09 11:44:47,636 DEBUG [c.c.v.VirtualMachineManagerImpl] (catalina-exec-7:ctx-8d87d71b ctx-fc6ae1da) Allocating entries for VM: VM[User|i-2-143-VM] 2014-06-09 11:44:47,637 DEBUG [c.c.v.VirtualMachineManagerImpl] (catalina-exec-7:ctx-8d87d71b ctx-fc6ae1da) Allocating nics for VM[User|i-2-143-VM] 2014-06-09 11:44:47,638 DEBUG [o.a.c.e.o.NetworkOrchestrator] (catalina-exec-7:ctx-8d87d71b ctx-fc6ae1da) Allocating nic for vm VM[User|i-2-143-VM] in network Ntwk[6c04eff1-972d-4119-bd97-e26c39d2bc0c|Guest|7] with requested profile NicProfile[0-0-null-null-null 2014-06-09 11:44:47,640 WARN [c.c.n.IpAddressManagerImpl] (catalina-exec-7:ctx-8d87d71b ctx-fc6ae1da) Unable to get ip adress in zone id=1, vlanId id=[1, 21], network id=222: requested ip 10.2.2.09 is not available 2014-06-09 11:44:47,641 DEBUG [c.c.u.d.T.Transaction] (catalina-exec-7:ctx-8d87d71b ctx-fc6ae1da) Rolling back the transaction: Time = 21 Name = catalina-exec-7; called by -TransactionLegacy.rollback:903-TransactionLegacy.removeUpTo:846-TransactionLegacy.close:670-Transaction.execute:41-IpAddressManagerImpl.fetchNewPublicIp:661-IpAddressManagerImpl.assignPublicIpAddress:648-IpAddressManagerImpl$11.doInTransactionWithoutResult:1853-TransactionCallbackWithExceptionNoReturn.doInTransaction:25-TransactionCallbackWithExceptionNoReturn.doInTransaction:21-Transaction.execute:37-IpAddressManagerImpl.allocateDirectIp:1831-DirectNetworkGuru$1.doInTransactionWithoutResult:246 2014-06-09 11:44:47,650 INFO [o.a.c.a.c.u.v.DeployVMCmd] (catalina-exec-7:ctx-8d87d71b ctx-fc6ae1da) com.cloud.exception.InsufficientAddressCapacityException: Insufficient address capacityScope=interface com.cloud.dc.DataCenter; id=1 2014-06-09 11:44:47,650 TRACE [o.a.c.a.c.u.v.DeployVMCmd] (catalina-exec-7:ctx-8d87d71b ctx-fc6ae1da) Insufficient address capacity com.cloud.exception.InsufficientAddressCapacityException: Insufficient address capacityScope=interface com.cloud.dc.DataCenter; id=1 at com.cloud.network.IpAddressManagerImpl$2.doInTransaction(IpAddressManagerImpl.java:750) at com.cloud.network.IpAddressManagerImpl$2.doInTransaction(IpAddressManagerImpl.java:661) at com.cloud.utils.db.Transaction.execute(Transaction.java:37) at com.cloud.network.IpAddressManagerImpl.fetchNewPublicIp(IpAddressManagerImpl.java:661) at com.cloud.network.IpAddressManagerImpl.assignPublicIpAddress(IpAddressManagerImpl.java:648) at com.cloud.network.IpAddressManagerImpl$11.doInTransactionWithoutResult(IpAddressManagerImpl.java:1853) at
[jira] [Updated] (CLOUDSTACK-7375) [UI] RBD not available under list of protocols for primary storage during zone creation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-7375: --- Fix Version/s: (was: 4.5.0) Future [UI] RBD not available under list of protocols for primary storage during zone creation --- Key: CLOUDSTACK-7375 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7375 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: Pavan Kumar Bandarupally Fix For: Future Attachments: screenshot-1.jpg Currently cloudstack supports CEPH storage as primary store without a requirement for another NFS store before adding CEPH storage. But during zone creation, we don't see RBD under protocol list for primary storage addition wizard. Please see attached image. Expected: - There should be RBD protocol so that user can add a CEPH primary store during zone creation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7703) Cloudstack server endless loop when trying to create a volume while storage pool is full
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14217110#comment-14217110 ] Marcus Sorensen commented on CLOUDSTACK-7703: - Thanks for the fixes. I wonder if this while loop should be bounded, as over time we seem to have hit a bunch of scenarios where we end up in an infinite loop in this part of the code. Maybe change while(true) to be tunable to max retries via a counter, or determine if we have already iterated over all possible combinations by pulling the total number of clusters, or something. Cloudstack server endless loop when trying to create a volume while storage pool is full Key: CLOUDSTACK-7703 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7703 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: Centos 6.5 Reporter: JF Vincent Assignee: Anshul Gangwar Priority: Critical Fix For: 4.5.0 When trying to create a VM, and thus a volume for it and the primary storage is full (over 90%), the managament server enter in and endless loop (extract below) and we have to restart it to exit this loop. 2014-10-14 11:39:20,701 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found for volume: Vol[5436|vm=5855|DATADISK] under cluster: 2 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable pools found 2014-10-14 11:39:20,702 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) No suitable storagePools found under this Cluster: 2 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Could not find suitable Deployment Destination for this VM under any clusters, returning. 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Searching all possible resources under this Zone: 2 2014-10-14 11:39:20,705 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Listing clusters in order of aggregate capacity, that have (atleast one host with) enough CPU and RAM capacity under this Zone: 2 2014-10-14 11:39:20,707 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Removing from the clusterId list these clusters from avoid set: [] 2014-10-14 11:39:20,714 DEBUG [cloud.deploy.DeploymentPlanningManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c) Checking resources in Cluster: 2 under Pod: 2 2014-10-14 11:39:20,714 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking for hosts in dc: 2 pod:2 cluster:2 2014-10-14 11:39:20,716 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) FirstFitAllocator has 3 hosts to check for allocation: [Host[-79-Routing], Host[-89-Routing], Host[-77-Routing]] 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Found 3 hosts for allocation after prioritization: [Host[-79-Routing], Host[-89-Routing], Host[-77-Routing]] 2014-10-14 11:39:20,717 DEBUG [allocator.impl.FirstFitAllocator] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Looking for speed=500Mhz, Ram=500 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Host: 79 has cpu capability (cpu:8, speed:2399) to support requested CPU: 1 and requested speed: 500 2014-10-14 11:39:20,720 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Checking if host: 79 has enough capacity for requested CPU: 500 and requested RAM: 524288000 , cpuOverprovisioningFactor: 4.0 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Hosts's actual total CPU: 19192 and CPU after applying overprovisioning: 76768 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free CPU: 57268 , Requested CPU: 500 2014-10-14 11:39:20,721 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-10:ctx-02d42f8f ctx-e581af2c FirstFitRoutingAllocator) Free RAM: 93916725248 , Requested RAM: 524288000
[jira] [Resolved] (CLOUDSTACK-5395) When backup snapshot fails becasue of backup.snapshot.wait time exceeding , the vhd entries form the primary store is not getting cleared.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Xu resolved CLOUDSTACK-5395. Resolution: Won't Fix When backup snapshot fails becasue of backup.snapshot.wait time exceeding , the vhd entries form the primary store is not getting cleared. -- Key: CLOUDSTACK-5395 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5395 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: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: Anthony Xu Fix For: 4.4.0, 4.5.0 Attachments: 1205logs.rar Steps to reproduce the problem: Deploy 5 Vms in each of the hosts with 10 GB , so we start with 10 Vms. We will be constantly writing to the ROOT volume. Change the backup.snapshot.wait to 10 mts and restart management server. Start concurrent snapshots for ROOT volumes of all the Vms. After 10 mts , the snapshots fail. They are present in the database in CreatedOnPrimary state. Vhd entries from the primary store fails to be cleaned up once the backsnapshpot job fails. In this case ,API fails with - Failed to create snapshot due to an internal error creating snapshot for volume 81 . We should be able to present a more meaningful error message in this case. Expected Behavior: We should be able to clean up the Vhd entries from the primary store when the backsnapshpot job fails. In such cases , instead of select * from snapshot_store_ref; 702 |1 | 355 | 2013-12-06 01:25:43 | NULL | NULL | Primary|0 | 0 | 0 | 2eedb23e-6c3f-4cae-832b-8ddb67c1fc60| Ready | 2 | 0 | 2013-12-06 01:25:44 |81 | | 703 |1 | 356 | 2013-12-06 01:25:43 | NULL | NULL | Primary|0 | 0 | 0 | 9d88bc01-9406-41ad-a134-e74dc1457954| Ready | 2 | 0 | 2013-12-06 01:26:12 |80 | | 704 |1 | 357 | 2013-12-06 01:25:43 | NULL | NULL | Primary|0 | 0 | 0 | 2667f2bc-6086-4ec3-a88d-20811eabde91| Ready | 2 | 0 | 2013-12-06 01:26:08 |79 | | 705 |1 | 358 | 2013-12-06 01:25:44 | NULL | NULL | Primary|0 | 0 | 0 | 522b2296-6960-46f2-af7d-10ddfbede1da| Ready | 2 | 0 | 2013-12-06 01:26:45 |78 | | 706 |1 | 359 | 2013-12-06 01:25:44 | NULL | NULL | Primary|0 | 0 | 0 | 3b94fa9d-a5a5-4441-8f9f-275dcef90368| Ready | 2 | 0 | 2013-12-06 01:26:04 |77 | | 707 |1 | 360 | 2013-12-06 01:25:44 | NULL | NULL | Primary|0 | 0 | 0 | 1ec1d5ef-177f-4da4-8464-f0c6d71a4e84| Ready | 2 | 0 | 2013-12-06 01:25:59 |76 | | 708 |1 | 361 | 2013-12-06 01:25:44 | NULL | NULL | Primary|0 | 0 | 0 | 324e7552-b42a-4660-90d6-62015a7a478e| Ready | 2 | 0 | 2013-12-06 01:26:21 |75 | | 709 |1 | 362 | 2013-12-06 01:25:44 | NULL | NULL | Primary|0 | 0 | 0 | 65bd522c-c2c8-471a-be37-095558d058f2| Ready | 2 | 0 | 2013-12-06 01:26:16 |74 | | 710 |1 | 363 | 2013-12-06 01:25:44 | NULL | NULL | Primary|0 | 0 | 0 | d45ca6c7-7284-4150-907c-9499e9737c47| Ready | 2 | 0 | 2013-12-06 01:25:46 |73 | | 711 |1 | 364 | 2013-12-06 01:25:44 | NULL | NULL | Primary|0 | 0 | 0 | 4422f362-0be5-4a10-b172-45678d56f807| Ready | 2 | 0 | 2013-12-06 01:25:55 |72 | | 712 |1 | 365 | 2013-12-06 01:25:44 | NULL | NULL | Primary|0 | 0 | 0 | 89ffd430-3c03-45d2-9c48-9384636b9cd8| Ready | 2 | 0 | 2013-12-06 01:26:01 |71 | | 714 |1 | 366 | 2013-12-06 01:25:45 | NULL | NULL | Primary|0 | 0 | 0 |
[jira] [Commented] (CLOUDSTACK-5395) When backup snapshot fails becasue of backup.snapshot.wait time exceeding , the vhd entries form the primary store is not getting cleared.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14217117#comment-14217117 ] Anthony Xu commented on CLOUDSTACK-5395: if backup snapshot times out, and XS cancel task doesn't work, CCP can't destroy the snapshot right now because it is being used, CCP will try to delete this snapshot next time CCP creates another snapshot and the old snapshot backup is done. Anthony When backup snapshot fails becasue of backup.snapshot.wait time exceeding , the vhd entries form the primary store is not getting cleared. -- Key: CLOUDSTACK-5395 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5395 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: Build from 4.3 Reporter: Sangeetha Hariharan Assignee: Anthony Xu Fix For: 4.4.0, 4.5.0 Attachments: 1205logs.rar Steps to reproduce the problem: Deploy 5 Vms in each of the hosts with 10 GB , so we start with 10 Vms. We will be constantly writing to the ROOT volume. Change the backup.snapshot.wait to 10 mts and restart management server. Start concurrent snapshots for ROOT volumes of all the Vms. After 10 mts , the snapshots fail. They are present in the database in CreatedOnPrimary state. Vhd entries from the primary store fails to be cleaned up once the backsnapshpot job fails. In this case ,API fails with - Failed to create snapshot due to an internal error creating snapshot for volume 81 . We should be able to present a more meaningful error message in this case. Expected Behavior: We should be able to clean up the Vhd entries from the primary store when the backsnapshpot job fails. In such cases , instead of select * from snapshot_store_ref; 702 |1 | 355 | 2013-12-06 01:25:43 | NULL | NULL | Primary|0 | 0 | 0 | 2eedb23e-6c3f-4cae-832b-8ddb67c1fc60| Ready | 2 | 0 | 2013-12-06 01:25:44 |81 | | 703 |1 | 356 | 2013-12-06 01:25:43 | NULL | NULL | Primary|0 | 0 | 0 | 9d88bc01-9406-41ad-a134-e74dc1457954| Ready | 2 | 0 | 2013-12-06 01:26:12 |80 | | 704 |1 | 357 | 2013-12-06 01:25:43 | NULL | NULL | Primary|0 | 0 | 0 | 2667f2bc-6086-4ec3-a88d-20811eabde91| Ready | 2 | 0 | 2013-12-06 01:26:08 |79 | | 705 |1 | 358 | 2013-12-06 01:25:44 | NULL | NULL | Primary|0 | 0 | 0 | 522b2296-6960-46f2-af7d-10ddfbede1da| Ready | 2 | 0 | 2013-12-06 01:26:45 |78 | | 706 |1 | 359 | 2013-12-06 01:25:44 | NULL | NULL | Primary|0 | 0 | 0 | 3b94fa9d-a5a5-4441-8f9f-275dcef90368| Ready | 2 | 0 | 2013-12-06 01:26:04 |77 | | 707 |1 | 360 | 2013-12-06 01:25:44 | NULL | NULL | Primary|0 | 0 | 0 | 1ec1d5ef-177f-4da4-8464-f0c6d71a4e84| Ready | 2 | 0 | 2013-12-06 01:25:59 |76 | | 708 |1 | 361 | 2013-12-06 01:25:44 | NULL | NULL | Primary|0 | 0 | 0 | 324e7552-b42a-4660-90d6-62015a7a478e| Ready | 2 | 0 | 2013-12-06 01:26:21 |75 | | 709 |1 | 362 | 2013-12-06 01:25:44 | NULL | NULL | Primary|0 | 0 | 0 | 65bd522c-c2c8-471a-be37-095558d058f2| Ready | 2 | 0 | 2013-12-06 01:26:16 |74 | | 710 |1 | 363 | 2013-12-06 01:25:44 | NULL | NULL | Primary|0 | 0 | 0 | d45ca6c7-7284-4150-907c-9499e9737c47| Ready | 2 | 0 | 2013-12-06 01:25:46 |73 | | 711 |1 | 364 | 2013-12-06 01:25:44 | NULL | NULL | Primary|0 | 0 | 0 | 4422f362-0be5-4a10-b172-45678d56f807| Ready | 2 | 0 | 2013-12-06 01:25:55 |72 | | 712 |1 | 365 | 2013-12-06 01:25:44 | NULL | NULL | Primary|0 | 0 |
[jira] [Resolved] (CLOUDSTACK-7918) Can't deploy VM from SUSE Linux Enterprise Server 12 (64-bit) ISO in XS 6.5
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Xu resolved CLOUDSTACK-7918. Resolution: Fixed CLOUDSTACK-7918: guest os name changes from 'SUSE Linux Enterprise Server 12 (experimental)' to 'SUSE Linux Enterprise Server 12 (64-bit)' in latest XS 5.6 , changed the guest OS mapping to fix it. Can't deploy VM from SUSE Linux Enterprise Server 12 (64-bit) ISO in XS 6.5 --- Key: CLOUDSTACK-7918 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7918 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Anthony Xu Assignee: Anthony Xu Priority: Critical Fix For: 4.5.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7752) Management Server goes in infinite loop while creating a vm with tagged local data disk when the pool is not tagged
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14217134#comment-14217134 ] ilya musayev commented on CLOUDSTACK-7752: -- Anshul, Please kindly commit to 4.3 and 4.4 branch, we are seeing this issue as well and will work with Citrix through the support channels. Thanks ilya Management Server goes in infinite loop while creating a vm with tagged local data disk when the pool is not tagged --- Key: CLOUDSTACK-7752 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7752 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Steps to reproduce: Setup must have a single cluster with both local and shared storage. 1) Create a local disk offering and tag it T1 2) Deploy vm with shared root disk and local data disk Management server goes in an infinite loop. The vm is never started/expunged. Also this causes vmops.log size to go very high. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-6459) Unable to enable maintenance mode on a Primary storage that crashed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Xu resolved CLOUDSTACK-6459. Resolution: Invalid primary storage maintenance mode is used to prevent new volume deployment on this primary storage and migrate the volumes in this primary storage to other primary storage. if primary storage is crashed, we can't put this primary storage in maintenance mode, this is expected behavior Unable to enable maintenance mode on a Primary storage that crashed --- Key: CLOUDSTACK-6459 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6459 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Reporter: Chandan Purushothama Assignee: Anthony Xu Priority: Critical Fix For: 4.4.0, 4.5.0 Attachments: kern.zip, management-server.log.2014-04-18.gz, mysql_cloudstack_dump.zip Primary storage in my setup got powered off. I am not able to enable maintenance mode on this primary storage. Enabling maintenance mode on the primary storage fails with the following error. It eventually timed out after trying many times 2014-04-18 16:43:50,020 DEBUG [c.c.a.ApiServlet] (catalina-exec-1:ctx-bd92e323 ctx-7d4c2498) ===END=== 10.214.5.40 -- GET command=queryAsyncJobResultjobId=62f6830a-c409-4449-a9c5-6a35b7b9fbedresponse=jsonsessionkey=WBpwG%2FryPRNNB1GRuHqam1zbtS8%3D_=1397865006850 2014-04-18 16:43:50,495 DEBUG [c.c.a.m.AgentManagerImpl] (AgentManager-Handler-9:null) SeqA 2-792: Processing Seq 2-792: { Cmd , MgmtId: -1, via: 2, Ver: v1, Flags: 11, [{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:1,_loadInfo:{\n \connections\: []\n},wait:0}}] } 2014-04-18 16:43:50,504 DEBUG [c.c.a.m.AgentManagerImpl] (AgentManager-Handler-9:null) SeqA 2-792: Sending Seq 2-792: { Ans: , MgmtId: 6638073284439, via: 2, Ver: v1, Flags: 100010, [{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] } 2014-04-18 16:43:52,539 WARN [c.c.h.x.r.CitrixResourceBase] (DirectAgent-143:ctx-16ea61bc) Async 600 seconds timeout for task com.xensource.xenapi.Task@8aa497e8 2014-04-18 16:43:52,563 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-143:ctx-16ea61bc) unable to destroy task(com.xensource.xenapi.Task@8aa497e8) on host(0d2ea73b-12c0-433c-b1c3-e1f193e68f6e) due to You gave an invalid object reference. The object may have recently been deleted. The class parameter gives the type of reference given, and the handle parameter echoes the bad value given. 2014-04-18 16:43:52,564 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-143:ctx-16ea61bc) Catch exception com.cloud.utils.exception.CloudRuntimeException when stop VM:i-3-3-DR due to com.cloud.utils.exception.CloudRuntimeException: Shutdown VM catch HandleInvalid and VM is not in HALTED state 2014-04-18 16:43:52,569 DEBUG [c.c.h.x.r.CitrixResourceBase] (DirectAgent-143:ctx-16ea61bc) 10. The VM i-3-3-DR is in Running state 2014-04-18 16:43:52,572 DEBUG [c.c.a.m.DirectAgentAttache] (DirectAgent-143:ctx-16ea61bc) Seq 1-2385781902599520418: Response Received: 2014-04-18 16:43:52,573 DEBUG [c.c.a.t.Request] (DirectAgent-143:ctx-16ea61bc) Seq 1-2385781902599520418: Processing: { Ans: , MgmtId: 6638073284439, via: 1, Ver: v1, Flags: 10, [{com.cloud.agent.api.StopAnswer:{platform:viridian:true;acpi:1;apic:true;pae:true;nx:true,result:false,details:Catch exception com.cloud.utils.exception.CloudRuntimeException when stop VM:i-3-3-DR due to com.cloud.utils.exception.CloudRuntimeException: Shutdown VM catch HandleInvalid and VM is not in HALTED state,wait:0}}] } 2014-04-18 16:43:52,576 DEBUG [c.c.a.t.Request] (Work-Job-Executor-2:job-30/job-31 ctx-191e1825) Seq 1-2385781902599520418: Received: { Ans: , MgmtId: 6638073284439, via: 1, Ver: v1, Flags: 10, { StopAnswer } } 2014-04-18 16:43:52,591 WARN [c.c.v.VirtualMachineManagerImpl] (Work-Job-Executor-2:job-30/job-31 ctx-191e1825) Unable to stop vm VM[User|i-3-3-DR] 2014-04-18 16:43:52,616 DEBUG [c.c.c.CapacityManagerImpl] (Work-Job-Executor-2:job-30/job-31 ctx-191e1825) VM state transitted from :Stopping to Running with event: OperationFailedvm's original host id: 1 new host id: 1 host id before state transition: 1 2014-04-18 16:43:52,616 ERROR [c.c.v.VmWorkJobHandlerProxy] (Work-Job-Executor-2:job-30/job-31 ctx-191e1825) Invocation exception, caused by: com.cloud.utils.exception.CloudRuntimeException: Unable to stop VM[User|i-3-3-DR] 2014-04-18 16:43:52,617 INFO [c.c.v.VmWorkJobHandlerProxy] (Work-Job-Executor-2:job-30/job-31 ctx-191e1825) Rethrow exception
[jira] [Commented] (CLOUDSTACK-7928) [Automation] Fix the script test_vpc_vm_life_cycle.py - Network Rules Validation fails when VPC VR is Stopped as per design
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14217141#comment-14217141 ] ASF subversion and git services commented on CLOUDSTACK-7928: - Commit 20a8852db1f55242e5526856bdfcc43d3eee4f4a in cloudstack's branch refs/heads/master from [~chandanp] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=20a8852 ] CLOUDSTACK-7928 : Fixed the script 'test_vpc_vm_life_cycle.py' - Removed the Invalid test cases for Stopped VPC VR Scenario [Automation] Fix the script test_vpc_vm_life_cycle.py - Network Rules Validation fails when VPC VR is Stopped as per design - Key: CLOUDSTACK-7928 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7928 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Chandan Purushothama Fix For: 4.5.0 Following Test Cases currently fail in TestVMLifeCycleStoppedVPCVR Test Suite: test_07_migrate_instance_in_network test_08_user_data test_09_meta_data test_10_expunge_instance_in_network The test cases fail for the obvious reason since the VPC VR is stopped. The Stopped VPCVR doesnt allow the traffic to or from the Guest VMs. Hence the test cases are not valid to be tested in such a scenario and should be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-5800) While creating a VM from template (which is created based on existing newly created vm) getting error as Unable to deploy vm base on template due to of insufficien
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Xu resolved CLOUDSTACK-5800. Resolution: Cannot Reproduce can't reproduce this issue, my best guess is the secondary storage is not in shape, maybe in Read Only mode. While creating a VM from template (which is created based on existing newly created vm) getting error as Unable to deploy vm base on template due to of insufficient server capicity - Key: CLOUDSTACK-5800 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5800 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Template, XenServer Affects Versions: 4.3.0 Environment: CENTOS 6.4,WIN2012,ACS 4.3.0, Reporter: rashid Assignee: Anthony Xu Fix For: 4.4.0, 4.5.0 While creating a vm from template INFO [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-5:ctx-c259052d) Add job-46 into job monitoring INFO [o.a.c.s.v.VolumeServiceImpl] (Job-Executor-5:ctx-c259052d ctx-506ea49e) lock is acquired for VMTemplateStoragePool 7 WARN [o.a.c.alerts] (CapacityChecker:ctx-374c70b5) alertType:: 24 // dataCenterId:: 1 // podId:: null // clusterId:: null // message:: System Alert: Number of unallocated shared network IPs is low in availability zone NEWZONE WARN [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-32c31ce6) Task (job-45) has been pending for 104 seconds WARN [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-32c31ce6) Task (job-46) has been pending for 103 seconds WARN [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-92c2ed53) Task (job-45) has been pending for 164 seconds WARN [o.a.c.f.j.i.AsyncJobMonitor] (Timer-2:ctx-92c2ed53) Task (job-46) has been pending for 163 seconds WARN [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-4:ctx-f87acd3c) destoryVDIbyNameLabel failed due to there are 0 VDIs with name cloud-377c12f4-a8e9-491a-8cba-34b9532455f8 WARN [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-4:ctx-f87acd3c) failed to set hidden to 0 /var/run/sr-mount/ab820f54-badd-db21-f758-0abcb47ea4d7/b0246f72-9bda-4f29-981f-548f4b7a9f6c.vhd WARN [c.c.h.x.r.XenServerStorageProcessor] (DirectAgent-4:ctx-f87acd3c) Catch Exception com.cloud.utils.exception.CloudRuntimeException for template + due to com.cloud.utils.exception.CloudRuntimeException: failed to set hidden to 0 /var/run/sr-mount/ab820f54-badd-db21-f758-0abcb47ea4d7/b0246f72-9bda-4f29-981f-548f4b7a9f6c.vhd com.cloud.utils.exception.CloudRuntimeException: failed to set hidden to 0 /var/run/sr-mount/ab820f54-badd-db21-f758-0abcb47ea4d7/b0246f72-9bda-4f29-981f-548f4b7a9f6c.vhd at com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copy_vhd_from_secondarystorage(XenServerStorageProcessor.java:858) at com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.copyTemplateToPrimaryStorage(XenServerStorageProcessor.java:928) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:75) at com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:50) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:609) at com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59) at com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) at
[jira] [Commented] (CLOUDSTACK-5324) error message not proper when start VM fails because router requires upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14217392#comment-14217392 ] ASF subversion and git services commented on CLOUDSTACK-5324: - Commit 4e896938ee6aac3945c9bf0d9e67423482e87be4 in cloudstack's branch refs/heads/master from [~kishan] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4e89693 ] BUG-ID: CLOUDSTACK-5324 when router requires upgrade throw ResourceUnavailableException with scope VirtualRouter. API willl return generic Network Unavailable error. Reviewed-By: Damoder error message not proper when start VM fails because router requires upgrade - Key: CLOUDSTACK-5324 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5324 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.3.0 Reporter: shweta agarwal Assignee: Kishan Kavala Fix For: 4.4.0, 4.5.0 Repro steps: Create a VM on 3.07 setup Upgrade to 4.3.0 but dont upgrade routers Stop user VM Start user VM Bug: Error message shows Unable to start a VM due to concurrent operation Expectation : Error message should show router requires upgrade MS log snippet : 2013-12-02 12:28:09,029 ERROR [c.c.v.VirtualMachineManagerImpl] (Job-Executor-9:ctx-1bf286cd ctx-4cabd091) Failed to start instance VM[User|f01ae0d5-23b3-44c4-9e8d-9df9245874be] com.cloud.utils.exception.CloudRuntimeException: Router requires upgrade. Unable to send command to router:4 at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.sendCommandsToRouter(VirtualNetworkApplianceManagerImpl.java:3437) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl$7.execute(VirtualNetworkApplianceManagerImpl.java:2873) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:3722) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyDhcpEntry(VirtualNetworkApplianceManagerImpl.java:2865) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:622) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy239.applyDhcpEntry(Unknown Source) at com.cloud.network.element.VirtualRouterElement.addDhcpEntry(VirtualRouterElement.java:914) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareElement(NetworkOrchestrator.java:1171) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNic(NetworkOrchestrator.java:1293) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1229) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:899) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:706) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:552) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:236) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3465) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:1921) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:622)
[jira] [Resolved] (CLOUDSTACK-5324) error message not proper when start VM fails because router requires upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala resolved CLOUDSTACK-5324. --- Resolution: Fixed error message not proper when start VM fails because router requires upgrade - Key: CLOUDSTACK-5324 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5324 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.3.0 Reporter: shweta agarwal Assignee: Kishan Kavala Fix For: 4.4.0, 4.5.0 Repro steps: Create a VM on 3.07 setup Upgrade to 4.3.0 but dont upgrade routers Stop user VM Start user VM Bug: Error message shows Unable to start a VM due to concurrent operation Expectation : Error message should show router requires upgrade MS log snippet : 2013-12-02 12:28:09,029 ERROR [c.c.v.VirtualMachineManagerImpl] (Job-Executor-9:ctx-1bf286cd ctx-4cabd091) Failed to start instance VM[User|f01ae0d5-23b3-44c4-9e8d-9df9245874be] com.cloud.utils.exception.CloudRuntimeException: Router requires upgrade. Unable to send command to router:4 at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.sendCommandsToRouter(VirtualNetworkApplianceManagerImpl.java:3437) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl$7.execute(VirtualNetworkApplianceManagerImpl.java:2873) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:3722) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyDhcpEntry(VirtualNetworkApplianceManagerImpl.java:2865) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:622) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy239.applyDhcpEntry(Unknown Source) at com.cloud.network.element.VirtualRouterElement.addDhcpEntry(VirtualRouterElement.java:914) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareElement(NetworkOrchestrator.java:1171) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNic(NetworkOrchestrator.java:1293) at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1229) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:899) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:706) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:552) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:236) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3465) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:1921) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:622) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at
[jira] [Commented] (CLOUDSTACK-7752) Management Server goes in infinite loop while creating a vm with tagged local data disk when the pool is not tagged
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14217402#comment-14217402 ] Anshul Gangwar commented on CLOUDSTACK-7752: I have added the patch https://reviews.apache.org/r/28213/ on review board for 4.3 and 4.4 branch. Someone with commit rights can apply it to those branches. Management Server goes in infinite loop while creating a vm with tagged local data disk when the pool is not tagged --- Key: CLOUDSTACK-7752 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7752 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Steps to reproduce: Setup must have a single cluster with both local and shared storage. 1) Create a local disk offering and tag it T1 2) Deploy vm with shared root disk and local data disk Management server goes in an infinite loop. The vm is never started/expunged. Also this causes vmops.log size to go very high. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7938) Automation: Create different section in test_data.py for configurable data and make changes in test cases accordingly
Gaurav Aradhye created CLOUDSTACK-7938: -- Summary: Automation: Create different section in test_data.py for configurable data and make changes in test cases accordingly Key: CLOUDSTACK-7938 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7938 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.5.0 Automation: Create different section in test_data.py for configurable data and make changes in test cases accordingly Currently we have some value in config such as portable IP data and also netscaler data. Move this to new section so that we know which data needs to be changed according to the setup -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7939) when a template is deleted an copied over again the removed column is not updated properly.
Bharat Kumar created CLOUDSTACK-7939: Summary: when a template is deleted an copied over again the removed column is not updated properly. Key: CLOUDSTACK-7939 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7939 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Bharat Kumar Assignee: Bharat Kumar -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7939) when a template is deleted and copied over again the removed column is not updated properly.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7939: - Summary: when a template is deleted and copied over again the removed column is not updated properly. (was: when a template is deleted an copied over again the removed column is not updated properly.) when a template is deleted and copied over again the removed column is not updated properly. Key: CLOUDSTACK-7939 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7939 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Bharat Kumar Assignee: Bharat Kumar -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7700) Volume Snapshot Async Job returns Success for a failed operation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sadhu suresh updated CLOUDSTACK-7700: - Description: Setup : Single zone , two clusters , one host in each cluster , have cluster wide storages and one zone wide primary storage Steps: 1. Install and configure Adv zone with Vmware 5.5 and CCP 4.3.0.1 setup 2. Deploy VM with DATA disk using Zonewide storage tagged offering and ensure that root and data disk of this VM are placed in ZWPS 3. Stop the VM and Try to create Volume snapshots till it gets failed. Observation: 1. It failed to create snapshot due to some temporary network issues . But It is returning success for a failed operation. 2014-10-13 17:39:52,365 DEBUG [c.c.v.VmWorkJobHandlerProxy] (Work-Job-Executor-12:ctx-9c1911cf job-36/job-37 ctx-14ac0075) Done executing VM work job: com.cloud.storage.VmWorkTakeVolumeSnapshot {volumeId:4,policyId:0,snapshotId:7,quiesceVm:false,userId:2,accountId:3,vmId:3,handlerName:VolumeApiServiceImpl} 2014-10-13 17:39:52,365 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (Work-Job-Executor-12:ctx-9c1911cf job-36/job-37 ctx-14ac0075) Complete async job-37, jobStatus: SUCCEEDED, resultCode: 0, result: rO0ABXNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAABw 2014-10-13 17:39:52,375 DEBUG [c.c.v.VmWorkJobDispatcher] (Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Done with run of VM work job: com.cloud.storage.VmWorkTakeVolumeSnapshot for VM 3, job origin: 36 2014-10-13 17:39:52,375 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Done executing com.cloud.storage.VmWorkTakeVolumeSnapshot for job-37 2014-10-13 17:39:52,392 DEBUG [o.a.c.f.j.i.SyncQueueManagerImpl] (Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Sync queue (3) is currently empty 2014-10-13 17:39:52,393 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Remove job-37 from job monitoring 2014-10-13 17:39:52,395 DEBUG [c.c.a.ApiResponseHelper] (API-Job-Executor-21:ctx-d9e77f3d job-36 ctx-16075f77) Unable to find info for image store snapshot with uuid 91fec32b-77f1-42af-909d-acca69772581 2014-10-13 17:39:52,396 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (API-Job-Executor-21:ctx-d9e77f3d job-36 ctx-16075f77) Complete async job-36, jobStatus: SUCCEEDED, resultCode: 0, result: org.apache.cloudstack.api.response.SnapshotResponse/snapshot/ {id:91fec32b-77f1-42af-909d-acca69772581,account:cdcuser1,domainid:0dc68c16-49d3-47ef-9ae2-40e043d3fe81,domain:cdc,snapshottype:MANUAL,volumeid:5097706f-97d6-4133-b010-3c803bca66cf,volumename:DATA-3,volumetype:DATADISK,created:2014-10-13T17:39:43+0530,name:cdcuserinst1_DATA-3_20141013120943,intervaltype:MANUAL,state:Error,tags:[],revertable:false} 2014-10-13 17:39:52,417 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (API-Job-Executor-21:ctx-d9e77f3d job-36) Done executing org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd for job-36 was: Setup : Single zone , two clusters , one host in each cluster , have cluster wide storages and one zone wide primary storage Steps: 1. Install and configure Adv zone with Vmware 5.5 and CCP 4.3.0.1 IDCF branch setup 2. Deploy VM with DATA disk using Zonewide storage tagged offering and ensure that root and data disk of this VM are placed in ZWPS 3. Stop the VM and Try to create Volume snapshots till it gets failed. Observation: 1. It failed to create snapshot due to some temporary network issues . But It is returning success for a failed operation. 2014-10-13 17:39:52,365 DEBUG [c.c.v.VmWorkJobHandlerProxy] (Work-Job-Executor-12:ctx-9c1911cf job-36/job-37 ctx-14ac0075) Done executing VM work job: com.cloud.storage.VmWorkTakeVolumeSnapshot {volumeId:4,policyId:0,snapshotId:7,quiesceVm:false,userId:2,accountId:3,vmId:3,handlerName:VolumeApiServiceImpl} 2014-10-13 17:39:52,365 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (Work-Job-Executor-12:ctx-9c1911cf job-36/job-37 ctx-14ac0075) Complete async job-37, jobStatus: SUCCEEDED, resultCode: 0, result: rO0ABXNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAABw 2014-10-13 17:39:52,375 DEBUG [c.c.v.VmWorkJobDispatcher] (Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Done with run of VM work job: com.cloud.storage.VmWorkTakeVolumeSnapshot for VM 3, job origin: 36 2014-10-13 17:39:52,375 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] (Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Done executing com.cloud.storage.VmWorkTakeVolumeSnapshot for job-37 2014-10-13 17:39:52,392 DEBUG [o.a.c.f.j.i.SyncQueueManagerImpl] (Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Sync queue (3) is currently empty 2014-10-13 17:39:52,393 INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Remove job-37 from job monitoring 2014-10-13
[jira] [Commented] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14217541#comment-14217541 ] Rajesh Battala commented on CLOUDSTACK-7364: I have verified on NS 10.1. I see the behaviour is same. The commands bind vlan public vlan to interface and then bind vlan to public ip address. I have verified these commands executed on 10.1 and 10.5. when checked NS resource java, we bind the public vlan to interfance and ip address. there is no version specific code changes or branches in code. here is output from 10.1 NS. Done show version NetScaler NS10.1: Build 126.12.nc, Date: May 13 2014, 07:39:11 Done show vlan 1) VLAN ID: 1 Link-local IPv6 addr: fe80::fc03:cdff:fe6f:9e52/64 Interfaces : 1/1 1/2 0/1 0/2 LO/1 2) VLAN ID: 100VLAN Alias Name: Interfaces : 1/1(T) IPs : 10.102.242.199 Mask: 255.255.254.0 3) VLAN ID: 458VLAN Alias Name: Interfaces : 1/2(T) IPs : 10.1.32.21 Mask: 255.255.240.0 Done these are commands gets executed in NS to bind vlan and ip address bind vlan 100 -IPAddres s 10.102.242.199 255.255.254.0 -devno 18120704 - Status Success Nov 19 00:18:48 local0.info 10.102.246.15 11/19/2014:00:18:48 GMT Cloud-VPX-10 0-PPE-0 : UI CMD_EXECUTED 153 0 : User nsroot - Remote_ip 10.102.192.251 - Command bind vlan 100 -ifnum 1/ 1 -tagged -devno 18153472 - Status Success us Success Nov 19 00:18:48 local0.info 10.102.246.15 11/19/2014:00:18:48 GMT Cloud-VPX-10 0-PPE-0 : UI CMD_EXECUTED 152 0 : User nsroot - Remote_ip 10.102.192.251 - Command bind vlan 100 -IPAddres s 10.102.242.199 255.255.254.0 -devno 18120704 - Status Success Nov 19 00:18:48 local0.info 10.102.246.15 11/19/2014:00:18:48 GMT Cloud-VPX-10 0-PPE-0 : UI CMD_EXECUTED 153 0 : User nsroot - Remote_ip 10.102.192.251 - Command bind vlan 100 -ifnum 1/ 1 -tagged -devno 18153472 - Status Success NetScaler won't create the Public VLAN and Bind the IP to it Key: CLOUDSTACK-7364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.4.0, 4.4.1 Reporter: Francois Gaudreault Assignee: Rajesh Battala Priority: Critical Attachments: management-server.log.debug.gz, screenshot-1.png, screenshot-2.png When adding a Load Balancing rule with the NetScaler, the provider will tag and bind the private IP to the appropriate interface. However, the behaviour for the Public Interface is different. It simply adds the IP untagged on all interfaces. This is wrong. The public VLAN should be tagged, and the VIP bound to the right VLAN tag to avoid unnecessary ARP on other VLANs. NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-7364. Resolution: Not a Problem NetScaler won't create the Public VLAN and Bind the IP to it Key: CLOUDSTACK-7364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.4.0, 4.4.1 Reporter: Francois Gaudreault Assignee: Rajesh Battala Priority: Critical Attachments: management-server.log.debug.gz, screenshot-1.png, screenshot-2.png When adding a Load Balancing rule with the NetScaler, the provider will tag and bind the private IP to the appropriate interface. However, the behaviour for the Public Interface is different. It simply adds the IP untagged on all interfaces. This is wrong. The public VLAN should be tagged, and the VIP bound to the right VLAN tag to avoid unnecessary ARP on other VLANs. NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)