date:20141118


[ 
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

2014-11-18 Thread Ashutosk Kelkar (JIRA)

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

2014-11-18 Thread shweta agarwal (JIRA)


 [ 
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

2014-11-18 Thread shweta agarwal (JIRA)


 [ 
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

2014-11-18 Thread Damodar Reddy T (JIRA)


 [ 
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

2014-11-18 Thread Remi Bergsma (JIRA)

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

2014-11-18 Thread ASF subversion and git services (JIRA)


[ 
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

2014-11-18 Thread shweta agarwal (JIRA)


 [ 
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

2014-11-18 Thread Remi Bergsma (JIRA)


 [ 
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

2014-11-18 Thread Remi Bergsma (JIRA)


 [ 
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

2014-11-18 Thread Rohit Yadav (JIRA)


[ 
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

2014-11-18 Thread Joris van Lieshout (JIRA)


[ 
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

2014-11-18 Thread Sailaja Mada (JIRA)


 [ 
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

2014-11-18 Thread Sailaja Mada (JIRA)


 [ 
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

2014-11-18 Thread Jessica Wang (JIRA)


 [ 
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

2014-11-18 Thread ASF subversion and git services (JIRA)


[ 
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

2014-11-18 Thread Jessica Wang (JIRA)


 [ 
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

2014-11-18 Thread Dusan Batas (JIRA)

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

2014-11-18 Thread ASF subversion and git services (JIRA)


[ 
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

2014-11-18 Thread ASF subversion and git services (JIRA)


[ 
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

2014-11-18 Thread Jessica Wang (JIRA)


[ 
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

2014-11-18 Thread ASF subversion and git services (JIRA)


[ 
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

2014-11-18 Thread ASF subversion and git services (JIRA)

[
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.

2014-11-18 Thread ASF subversion and git services (JIRA)

[
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.

2014-11-18 Thread Prachi Damle (JIRA)

[
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.
--

Attachments: management-server.log.rar

--
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

2014-11-18 Thread Prachi Damle (JIRA)

[
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
-

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-7746) Baremetal related script erros seen on router console

2014-11-18 Thread Sudha Ponnaganti (JIRA)


[ 
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

2014-11-18 Thread Amogh Vasekar (JIRA)


[ 
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

2014-11-18 Thread Amogh Vasekar (JIRA)


 [ 
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

2014-11-18 Thread Marcus Sorensen (JIRA)


[ 
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

2014-11-18 Thread ilya musayev (JIRA)


[ 
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

2014-11-18 Thread ASF subversion and git services (JIRA)


 [ 
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

2014-11-18 Thread ASF subversion and git services (JIRA)


 [ 
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

2014-11-18 Thread Kishan Kavala (JIRA)


 [ 
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