[jira] [Commented] (CLOUDSTACK-6453) [GPU] Windows 2012 Server instance created with vGPU offering is not coming up after installing PV drivers
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980789#comment-13980789 ] Sanjay Tripathi commented on CLOUDSTACK-6453: - The following scenario is working: 1) Deploy Windows 2012 VM with non-vGPU service offering. 2) Install PV drivers 3) Change service offering to the one with vGPU. VM comes up fine after that. For scenario, to install PV drivers after VM with vGPU offering, i am not sure if it a cloudstack bug; from logs, more likely it looks like XenServer issue. I am investigating it and I'll update the ticket once i get more details. [GPU] Windows 2012 Server instance created with vGPU offering is not coming up after installing PV drivers -- Key: CLOUDSTACK-6453 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6453 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, XenServer Affects Versions: 4.4.0 Reporter: Sailaja Mada Assignee: Sanjay Tripathi Priority: Blocker Fix For: 4.4.0 Attachments: SMlog, gpulogs.zip Steps: 1. Install and Configure Adv zone using Xen 6.2.5 which has GRID K2 2. Create Service Offering using K2 - K200 profile of vGPU 3. Deploy windows 2012 instance with ISO using K200 vGPU profile offering 4. Install Windows 2012 instance and install PV drivers 5. During PV driver installation Windows 2012 server went for reboot. Observation: 1. After reboot, Windows 2012 Server instance created with vGPU offering is not coming up after installing PV drivers 2. It remained in stopped state. 3. Tried to start instance manually , Cloudstack says Instance started and instance moved to running state. But XenServer failed to start the instance. 4. Later Cloudstack also marked the instance in stopped state. Attached detailed logs -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6504) [hyper-v] remove unnecessary warnings while building hyper-v agent code
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980811#comment-13980811 ] ASF subversion and git services commented on CLOUDSTACK-6504: - Commit 66f8e0e1b5c81cbfde926c0c65c4d5969767cab9 in cloudstack's branch refs/heads/4.4-forward from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=66f8e0e ] CLOUDSTACK-6504: removed warnings coming in building hyper-v agent code [hyper-v] remove unnecessary warnings while building hyper-v agent code --- Key: CLOUDSTACK-6504 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6504 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar There are some unnecessary warnings in building hyper-v agent code. Like field is never used etc -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6470) [Hyper-v] while stopping vm hyper-v agent, vm is not gracefully shutdown
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980810#comment-13980810 ] ASF subversion and git services commented on CLOUDSTACK-6470: - Commit 4a85e2226436c62e781db3449d262cb385b977c1 in cloudstack's branch refs/heads/4.4-forward from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4a85e22 ] CLOUDSTACK-6470: while stopping vm in hyper-v, now we are first trying to shutdown it gracefully before turning it off forcefully [Hyper-v] while stopping vm hyper-v agent, vm is not gracefully shutdown Key: CLOUDSTACK-6470 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6470 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar When we stop VM in case of hyper-v, then it is always force shutdowned i.e. turn off. Even if the integartion services are istalled in hyper-v. Directly turning of VM may result in corruption of disk. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6505) bridge gets reset for cluster level OVS network.
Murali Reddy created CLOUDSTACK-6505: Summary: bridge gets reset for cluster level OVS network. Key: CLOUDSTACK-6505 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6505 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Murali Reddy Assignee: Murali Reddy Fix For: 4.4.0 This is regression introduced by below commit. commit faf52530cc9ff5827825eefe1c09b2887d0a0883 Author: Murali Reddy muralimmre...@gmail.com Date: Tue Apr 8 19:04:06 2014 +0530 CLOUDSTACK-6356: OVS: tunnel networks does not work across the XenServer clusers To make internal network work across the cluster, above fix introduced logic to plug/un-plug VIF in dom0 connected to OVS internal nework. this logic would ensure there is a bridge created on each host. But this logic should execute only once to created bridge. Currently its executing multiple times resulting in bridge to be recreated and hence loosing all the open flow rules. configured. Fix for this bug should ensure we only create bridge once on each for the OVS tunnel network. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6498) [Automation] unable to start management server after restart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srikanteswararao Talluri updated CLOUDSTACK-6498: - Attachment: cloud.sql cloud database dump [Automation] unable to start management server after restart Key: CLOUDSTACK-6498 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6498 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: advanced zone xenserer 6.2 Reporter: Srikanteswararao Talluri Assignee: Harikrishna Patnala Priority: Blocker Fix For: 4.5.0 Attachments: cloud.sql, log.tar.gz on the daily automation environment, After the zone is deployed , system VMs came up fine. After setting few global settings, I tried to restart management server, it never came up again. I could see some db exceptions related to duplicate keys. I will attach management server logs to this bug for your reference. Caught SQLException when inserting system account com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry '1' for key 'PRIMARY' at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) at com.mysql.jdbc.Util.getInstance(Util.java:386) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1040) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3597) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3529) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1990) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2151) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2625) at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2119) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2415) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2333) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2318) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) 14761,2-9 96% -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6498) [Automation] unable to start management server after restart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980820#comment-13980820 ] Srikanteswararao Talluri commented on CLOUDSTACK-6498: -- Management server was rebooted using service cloudstack-management stop;service cloudstack-management start [Automation] unable to start management server after restart Key: CLOUDSTACK-6498 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6498 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: advanced zone xenserer 6.2 Reporter: Srikanteswararao Talluri Assignee: Harikrishna Patnala Priority: Blocker Fix For: 4.5.0 Attachments: cloud.sql, log.tar.gz on the daily automation environment, After the zone is deployed , system VMs came up fine. After setting few global settings, I tried to restart management server, it never came up again. I could see some db exceptions related to duplicate keys. I will attach management server logs to this bug for your reference. Caught SQLException when inserting system account com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry '1' for key 'PRIMARY' at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) at com.mysql.jdbc.Util.getInstance(Util.java:386) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1040) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3597) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3529) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1990) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2151) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2625) at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2119) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2415) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2333) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2318) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) 14761,2-9 96% -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6506) [UI-Loadbalancing]Improper display of VMs/IPs while adding the VMs to LB rule.
manasaveloori created CLOUDSTACK-6506: - Summary: [UI-Loadbalancing]Improper display of VMs/IPs while adding the VMs to LB rule. Key: CLOUDSTACK-6506 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6506 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.4.0 Reporter: manasaveloori Fix For: 4.4.0 1. Deploy 2 VMs VM1 and VM2. 2. Add secondary IPs to both VMs. 3. Create LB rule and add both VMs including primary and secondary IPS. 4. Now click on “add” button beside LB rule .It will display nothing as there are no more VMs/Ips to add. 5. Remove one of the VMs ip from LB rule say primary ip of VM1 is removed. 6. Now when we click on “add” button ,UI should list VM1 with its primary IP in the list. 7. Issue1In step 6 UI is not displaying the VM with ip list if it is already added and removed. 8. Issue2It is better to display only the VMs and IPs which are not assigned to LB rule in the list while adding VMs to Lb rule. For example: I have added VM1 primary IP.Now when I click on “add” ,UI should display only VM1 –secondary IP and VM2-primary and secondary IP. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-6506) [UI-Loadbalancing]Improper display of VMs/IPs while adding the VMs to LB rule.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] manasaveloori reassigned CLOUDSTACK-6506: - Assignee: Jessica Wang [UI-Loadbalancing]Improper display of VMs/IPs while adding the VMs to LB rule. -- Key: CLOUDSTACK-6506 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6506 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.4.0 Reporter: manasaveloori Assignee: Jessica Wang Fix For: 4.4.0 1.Deploy 2 VMs VM1 and VM2. 2.Add secondary IPs to both VMs. 3.Create LB rule and add both VMs including primary and secondary IPS. 4.Now click on “add” button beside LB rule .It will display nothing as there are no more VMs/Ips to add. 5.Remove one of the VMs ip from LB rule say primary ip of VM1 is removed. 6.Now when we click on “add” button ,UI should list VM1 with its primary IP in the list. 7.Issue1In step 6 UI is not displaying the VM with ip list if it is already added and removed. 8.Issue2It is better to display only the VMs and IPs which are not assigned to LB rule in the list while adding VMs to Lb rule. For example: I have added VM1 primary IP.Now when I click on “add” ,UI should display only VM1 –secondary IP and VM2-primary and secondary IP. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6507) ensure sequence numbers are honoured while processing OvsVpcPhysicalTopologyConfigCommand and OvsVpcRoutingPolicyConfigCommand
Murali Reddy created CLOUDSTACK-6507: Summary: ensure sequence numbers are honoured while processing OvsVpcPhysicalTopologyConfigCommand and OvsVpcRoutingPolicyConfigCommand Key: CLOUDSTACK-6507 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6507 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Murali Reddy Assignee: Murali Reddy Fix For: 4.4.0 ensure sequence numbers are honoured while processing OvsVpcPhysicalTopologyConfigCommand and OvsVpcRoutingPolicyConfigCommand. On the scripts that process these commands, should check the last sequence number stored in the bridge, only if the update is latest (i.e. sequence number in the command the last sequence number stored in hte bridge config). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6507) ensure sequence numbers are honoured while processing OvsVpcPhysicalTopologyConfigCommand and OvsVpcRoutingPolicyConfigCommand
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980828#comment-13980828 ] ASF subversion and git services commented on CLOUDSTACK-6507: - Commit 380998aa4f1b1b7e778dbf47c12f303bfbf39e3a in cloudstack's branch refs/heads/4.4-forward from [~murali.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=380998a ] CLOUDSTACK-6507: ensure sequence numbers are honoured while processing OvsVpcPhysicalTopologyConfigCommand and OvsVpcRoutingPolicyConfigCommand fix ensures only latest updates are applied (new openflow rules) to the bidge enabled for distributed routing. ensure sequence numbers are honoured while processing OvsVpcPhysicalTopologyConfigCommand and OvsVpcRoutingPolicyConfigCommand --- Key: CLOUDSTACK-6507 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6507 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Murali Reddy Assignee: Murali Reddy Fix For: 4.4.0 ensure sequence numbers are honoured while processing OvsVpcPhysicalTopologyConfigCommand and OvsVpcRoutingPolicyConfigCommand. On the scripts that process these commands, should check the last sequence number stored in the bridge, only if the update is latest (i.e. sequence number in the command the last sequence number stored in hte bridge config). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6505) bridge gets reset for cluster level OVS network.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980827#comment-13980827 ] ASF subversion and git services commented on CLOUDSTACK-6505: - Commit 771d1346d1bd9b64a5eba17bc37134fba5a3112d in cloudstack's branch refs/heads/4.4-forward from [~murali.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=771d134 ] CLOUDSTACK-6505: XenServer bridge for the OVS tunnel network gets reset on the hosts in the xenserver cluster this fix ensures that brige is created only once so that openflow rules configured on the bridge are not lost. bridge gets reset for cluster level OVS network. Key: CLOUDSTACK-6505 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6505 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Murali Reddy Assignee: Murali Reddy Fix For: 4.4.0 This is regression introduced by below commit. commit faf52530cc9ff5827825eefe1c09b2887d0a0883 Author: Murali Reddy muralimmre...@gmail.com Date: Tue Apr 8 19:04:06 2014 +0530 CLOUDSTACK-6356: OVS: tunnel networks does not work across the XenServer clusers To make internal network work across the cluster, above fix introduced logic to plug/un-plug VIF in dom0 connected to OVS internal nework. this logic would ensure there is a bridge created on each host. But this logic should execute only once to created bridge. Currently its executing multiple times resulting in bridge to be recreated and hence loosing all the open flow rules. configured. Fix for this bug should ensure we only create bridge once on each for the OVS tunnel network. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6504) [hyper-v] remove unnecessary warnings while building hyper-v agent code
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980837#comment-13980837 ] ASF subversion and git services commented on CLOUDSTACK-6504: - Commit 6511b96088af75b7e37a5f8b0cce609b006021fb in cloudstack's branch refs/heads/master from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6511b96 ] CLOUDSTACK-6504: removed warnings coming in building hyper-v agent code [hyper-v] remove unnecessary warnings while building hyper-v agent code --- Key: CLOUDSTACK-6504 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6504 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar There are some unnecessary warnings in building hyper-v agent code. Like field is never used etc -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6470) [Hyper-v] while stopping vm hyper-v agent, vm is not gracefully shutdown
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980836#comment-13980836 ] ASF subversion and git services commented on CLOUDSTACK-6470: - Commit 1dc76a2743ae972642498f94d6f6a7ffd8067bf8 in cloudstack's branch refs/heads/master from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1dc76a2 ] CLOUDSTACK-6470: while stopping vm in hyper-v, now we are first trying to shutdown it gracefully before turning it off forcefully [Hyper-v] while stopping vm hyper-v agent, vm is not gracefully shutdown Key: CLOUDSTACK-6470 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6470 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar When we stop VM in case of hyper-v, then it is always force shutdowned i.e. turn off. Even if the integartion services are istalled in hyper-v. Directly turning of VM may result in corruption of disk. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6470) [Hyper-v] while stopping vm hyper-v agent, vm is not gracefully shutdown
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-6470. Resolution: Fixed [Hyper-v] while stopping vm hyper-v agent, vm is not gracefully shutdown Key: CLOUDSTACK-6470 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6470 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar When we stop VM in case of hyper-v, then it is always force shutdowned i.e. turn off. Even if the integartion services are istalled in hyper-v. Directly turning of VM may result in corruption of disk. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6504) [hyper-v] remove unnecessary warnings while building hyper-v agent code
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-6504. Resolution: Fixed [hyper-v] remove unnecessary warnings while building hyper-v agent code --- Key: CLOUDSTACK-6504 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6504 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Anshul Gangwar Assignee: Anshul Gangwar There are some unnecessary warnings in building hyper-v agent code. Like field is never used etc -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6505) bridge gets reset for cluster level OVS network.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980859#comment-13980859 ] ASF subversion and git services commented on CLOUDSTACK-6505: - Commit 8e4391bff310bd3583cf81fe0260e8349d05f82f in cloudstack's branch refs/heads/master from [~murali.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8e4391b ] CLOUDSTACK-6505: XenServer bridge for the OVS tunnel network gets reset on the hosts in the xenserver cluster this fix ensures that brige is created only once so that openflow rules configured on the bridge are not lost. bridge gets reset for cluster level OVS network. Key: CLOUDSTACK-6505 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6505 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Murali Reddy Assignee: Murali Reddy Fix For: 4.4.0 This is regression introduced by below commit. commit faf52530cc9ff5827825eefe1c09b2887d0a0883 Author: Murali Reddy muralimmre...@gmail.com Date: Tue Apr 8 19:04:06 2014 +0530 CLOUDSTACK-6356: OVS: tunnel networks does not work across the XenServer clusers To make internal network work across the cluster, above fix introduced logic to plug/un-plug VIF in dom0 connected to OVS internal nework. this logic would ensure there is a bridge created on each host. But this logic should execute only once to created bridge. Currently its executing multiple times resulting in bridge to be recreated and hence loosing all the open flow rules. configured. Fix for this bug should ensure we only create bridge once on each for the OVS tunnel network. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6507) ensure sequence numbers are honoured while processing OvsVpcPhysicalTopologyConfigCommand and OvsVpcRoutingPolicyConfigCommand
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980860#comment-13980860 ] ASF subversion and git services commented on CLOUDSTACK-6507: - Commit 213a68dc3915ff0c979d71d82dad168be9de9352 in cloudstack's branch refs/heads/master from [~murali.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=213a68d ] CLOUDSTACK-6507: ensure sequence numbers are honoured while processing OvsVpcPhysicalTopologyConfigCommand and OvsVpcRoutingPolicyConfigCommand fix ensures only latest updates are applied (new openflow rules) to the bidge enabled for distributed routing. ensure sequence numbers are honoured while processing OvsVpcPhysicalTopologyConfigCommand and OvsVpcRoutingPolicyConfigCommand --- Key: CLOUDSTACK-6507 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6507 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Murali Reddy Assignee: Murali Reddy Fix For: 4.4.0 ensure sequence numbers are honoured while processing OvsVpcPhysicalTopologyConfigCommand and OvsVpcRoutingPolicyConfigCommand. On the scripts that process these commands, should check the last sequence number stored in the bridge, only if the update is latest (i.e. sequence number in the command the last sequence number stored in hte bridge config). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-6452) Failed to Live Migrate VM across clusters with Xenserver 6.2.5
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi reassigned CLOUDSTACK-6452: --- Assignee: Sanjay Tripathi (was: Devdeep Singh) Failed to Live Migrate VM across clusters with Xenserver 6.2.5 -- Key: CLOUDSTACK-6452 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6452 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller, XenServer Affects Versions: 4.4.0 Reporter: Sailaja Mada Assignee: Sanjay Tripathi Priority: Critical Fix For: 4.4.0 Attachments: migrationlogs.rar Steps: 1. Install and configure Adv zone using Xen 6.2.5 hypervisor with 2 clusters having 1 host in each cluster 2. deploy Windows 2012 instance 3. Live Migrate instance from cluster1 host to cluster2 Observation: Failed to Live Migrate VM across clusters with Xenserver 6.2.5 Job failed due to exception Failed to migrated vm VM[User|i-3-21-VM] along with its volumes. com.cloud.utils.exception.CloudRuntimeException: Error while migrating the vm VM[User|i-3-21-VM] to host Host[-4-Routing]. Exception: com.cloud.utils.exception.CloudRuntimeException Message: Unable to get the updated VDI paths of the migrated vm java.lang.ClassCastException: org.apache.cloudstack.storage.to.TemplateObjectTO cannot be cast to org.apache.cloudstack.storage.to.VolumeObjectTO Stack: com.cloud.utils.exception.CloudRuntimeException: Unable to get the updated VDI paths of the migrated vm java.lang.ClassCastException: org.apache.cloudstack.storage.to.TemplateObjectTO cannot be cast to org.apache.cloudstack.storage.to.VolumeObjectTO at com.cloud.hypervisor.xen.resource.XenServer610Resource.getUpdatedVolumePathsOfMigratedVm(XenServer610Resource.java:123) at com.cloud.hypervisor.xen.resource.XenServer610Resource.execute(XenServer610Resource.java:357) at com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:88) at com.cloud.hypervisor.xen.resource.XenServer620SP1Resource.executeRequest(XenServer620SP1Resource.java:64) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) Caused by: java.lang.ClassCastException: org.apache.cloudstack.storage.to.TemplateObjectTO cannot be cast to org.apache.cloudstack.storage.to.VolumeObjectTO at com.cloud.hypervisor.xen.resource.XenServer610Resource.getUpdatedVolumePathsOfMigratedVm(XenServer610Resource.java:113) ... 16 more -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6452) Failed to Live Migrate VM across clusters with Xenserver 6.2.5
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980885#comment-13980885 ] ASF subversion and git services commented on CLOUDSTACK-6452: - Commit cf4db845ff7b46c7004f22e7d7d7d2f636935428 in cloudstack's branch refs/heads/master from [~sanjay.tripathi] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cf4db84 ] CLOUDSTACK-6452: Failed to Live Migrate VM across clusters with Xenserver 6.2.5. Failed to Live Migrate VM across clusters with Xenserver 6.2.5 -- Key: CLOUDSTACK-6452 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6452 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller, XenServer Affects Versions: 4.4.0 Reporter: Sailaja Mada Assignee: Sanjay Tripathi Priority: Critical Fix For: 4.4.0 Attachments: migrationlogs.rar Steps: 1. Install and configure Adv zone using Xen 6.2.5 hypervisor with 2 clusters having 1 host in each cluster 2. deploy Windows 2012 instance 3. Live Migrate instance from cluster1 host to cluster2 Observation: Failed to Live Migrate VM across clusters with Xenserver 6.2.5 Job failed due to exception Failed to migrated vm VM[User|i-3-21-VM] along with its volumes. com.cloud.utils.exception.CloudRuntimeException: Error while migrating the vm VM[User|i-3-21-VM] to host Host[-4-Routing]. Exception: com.cloud.utils.exception.CloudRuntimeException Message: Unable to get the updated VDI paths of the migrated vm java.lang.ClassCastException: org.apache.cloudstack.storage.to.TemplateObjectTO cannot be cast to org.apache.cloudstack.storage.to.VolumeObjectTO Stack: com.cloud.utils.exception.CloudRuntimeException: Unable to get the updated VDI paths of the migrated vm java.lang.ClassCastException: org.apache.cloudstack.storage.to.TemplateObjectTO cannot be cast to org.apache.cloudstack.storage.to.VolumeObjectTO at com.cloud.hypervisor.xen.resource.XenServer610Resource.getUpdatedVolumePathsOfMigratedVm(XenServer610Resource.java:123) at com.cloud.hypervisor.xen.resource.XenServer610Resource.execute(XenServer610Resource.java:357) at com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:88) at com.cloud.hypervisor.xen.resource.XenServer620SP1Resource.executeRequest(XenServer620SP1Resource.java:64) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) Caused by: java.lang.ClassCastException: org.apache.cloudstack.storage.to.TemplateObjectTO cannot be cast to org.apache.cloudstack.storage.to.VolumeObjectTO at com.cloud.hypervisor.xen.resource.XenServer610Resource.getUpdatedVolumePathsOfMigratedVm(XenServer610Resource.java:113) ... 16 more -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6452) Failed to Live Migrate VM across clusters with Xenserver 6.2.5
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980884#comment-13980884 ] ASF subversion and git services commented on CLOUDSTACK-6452: - Commit 0f755ee4fcb0c2108e87eccea640f50748071050 in cloudstack's branch refs/heads/4.4-forward from [~sanjay.tripathi] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0f755ee ] CLOUDSTACK-6452: Failed to Live Migrate VM across clusters with Xenserver 6.2.5. Failed to Live Migrate VM across clusters with Xenserver 6.2.5 -- Key: CLOUDSTACK-6452 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6452 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller, XenServer Affects Versions: 4.4.0 Reporter: Sailaja Mada Assignee: Sanjay Tripathi Priority: Critical Fix For: 4.4.0 Attachments: migrationlogs.rar Steps: 1. Install and configure Adv zone using Xen 6.2.5 hypervisor with 2 clusters having 1 host in each cluster 2. deploy Windows 2012 instance 3. Live Migrate instance from cluster1 host to cluster2 Observation: Failed to Live Migrate VM across clusters with Xenserver 6.2.5 Job failed due to exception Failed to migrated vm VM[User|i-3-21-VM] along with its volumes. com.cloud.utils.exception.CloudRuntimeException: Error while migrating the vm VM[User|i-3-21-VM] to host Host[-4-Routing]. Exception: com.cloud.utils.exception.CloudRuntimeException Message: Unable to get the updated VDI paths of the migrated vm java.lang.ClassCastException: org.apache.cloudstack.storage.to.TemplateObjectTO cannot be cast to org.apache.cloudstack.storage.to.VolumeObjectTO Stack: com.cloud.utils.exception.CloudRuntimeException: Unable to get the updated VDI paths of the migrated vm java.lang.ClassCastException: org.apache.cloudstack.storage.to.TemplateObjectTO cannot be cast to org.apache.cloudstack.storage.to.VolumeObjectTO at com.cloud.hypervisor.xen.resource.XenServer610Resource.getUpdatedVolumePathsOfMigratedVm(XenServer610Resource.java:123) at com.cloud.hypervisor.xen.resource.XenServer610Resource.execute(XenServer610Resource.java:357) at com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:88) at com.cloud.hypervisor.xen.resource.XenServer620SP1Resource.executeRequest(XenServer620SP1Resource.java:64) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) Caused by: java.lang.ClassCastException: org.apache.cloudstack.storage.to.TemplateObjectTO cannot be cast to org.apache.cloudstack.storage.to.VolumeObjectTO at com.cloud.hypervisor.xen.resource.XenServer610Resource.getUpdatedVolumePathsOfMigratedVm(XenServer610Resource.java:113) ... 16 more -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6498) [Automation] unable to start management server after restart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980890#comment-13980890 ] Harikrishna Patnala commented on CLOUDSTACK-6498: - It seems all the errors are handled gracefully except the encryption error. 2014-04-24 14:49:07,370 DEBUG [utils.crypt.DBEncryptionUtil] (main:null) Error while decrypting: 2jA0WZQvg6SptQ8gRYdqRw 2014-04-24 14:49:07,376 INFO [factory.support.DefaultListableBeanFactory] (main:null) Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@632deed0: defining beans [premiumSecondaryStorageManagerImpl,componentContext,encryptionSecretKeyChecker,userAuthenticatorsRegistry,userPasswordEncodersRegistry,securityCheckersRegistry,resourceDiscoverersRegistry,haInvestigatorsRegistry,haFenceBuildersRegistry,deploymen Recently similar issue is fixed https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=45ab288e;hp=89c6f0087c832a05ed55256a394aee7541ac83d4 on 4.4 (https://issues.apache.org/jira/browse/CLOUDSTACK-6239) but yet to fix on master. [Automation] unable to start management server after restart Key: CLOUDSTACK-6498 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6498 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: advanced zone xenserer 6.2 Reporter: Srikanteswararao Talluri Assignee: Harikrishna Patnala Priority: Blocker Fix For: 4.5.0 Attachments: cloud.sql, log.tar.gz on the daily automation environment, After the zone is deployed , system VMs came up fine. After setting few global settings, I tried to restart management server, it never came up again. I could see some db exceptions related to duplicate keys. I will attach management server logs to this bug for your reference. Caught SQLException when inserting system account com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry '1' for key 'PRIMARY' at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) at com.mysql.jdbc.Util.getInstance(Util.java:386) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1040) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3597) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3529) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1990) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2151) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2625) at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2119) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2415) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2333) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2318) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) 14761,2-9 96% -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6509) Cannot import multiple LDAP/AD users into a cloudstack account
Rajani Karuturi created CLOUDSTACK-6509: --- Summary: Cannot import multiple LDAP/AD users into a cloudstack account Key: CLOUDSTACK-6509 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6509 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Rajani Karuturi Assignee: Rajani Karuturi Priority: Critical Fix For: 4.4.0, 4.3.1 in the ldap add account popup, select multiple users and specify an account name. it fails with errror account with the name already exists. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6509) Cannot import multiple LDAP/AD users into a cloudstack account
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-6509: Status: Reviewable (was: In Progress) Cannot import multiple LDAP/AD users into a cloudstack account -- Key: CLOUDSTACK-6509 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6509 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Rajani Karuturi Assignee: Rajani Karuturi Priority: Critical Labels: ldap Fix For: 4.4.0, 4.3.1 in the ldap add account popup, select multiple users and specify an account name. it fails with errror account with the name already exists. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6509) Cannot import multiple LDAP/AD users into a cloudstack account
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980901#comment-13980901 ] Rajani Karuturi commented on CLOUDSTACK-6509: - patch is on review board https://reviews.apache.org/r/20703/ Cannot import multiple LDAP/AD users into a cloudstack account -- Key: CLOUDSTACK-6509 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6509 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Rajani Karuturi Assignee: Rajani Karuturi Priority: Critical Labels: ldap Fix For: 4.4.0, 4.3.1 in the ldap add account popup, select multiple users and specify an account name. it fails with errror account with the name already exists. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6431) [SDN] migrating vm to a new host added to the cluster does not create gre tunnel port on the new host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980914#comment-13980914 ] ASF subversion and git services commented on CLOUDSTACK-6431: - Commit a176576c349581f56b2d79af88e0c459eb7c3776 in cloudstack's branch refs/heads/4.4-forward from [~murali.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a176576 ] CLOUDSTACK-6431: OVS migrating vm to a new host added to the cluster does not create gre tunnel port on the new host ensure OveElement gets a chance to setup tunnel network on the host before VM is migrated. [SDN] migrating vm to a new host added to the cluster does not create gre tunnel port on the new host - Key: CLOUDSTACK-6431 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6431 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.4.0 Environment: Latest build from 4.4 with commit 80d82106dcc701e9569dde16161b24ff3abfa67f Hypervisor: XenServer6.2 Reporter: Sanjeev N Assignee: Murali Reddy Priority: Critical Fix For: 4.4.0 Attachments: management-server.log.2014-04-15.gz [SDN] migrating vm to a new host added to the cluster does not create gre tunnel port on the new host Steps to Reproduce: = 1.Bring up CS in advanced zone with GRE isolation using two hosts in the xenserver cluster 2.Create an isolated network using stretched-l2 service 3.Deploy few guest vms in the network and make sure that vms are spanned across the two hosts in the cluster 4.Make sure that GRE tunnels are created between these two hosts 5.Add another host to the cluster 6.Migrate one of the vms to the new host added to the cluster Expected Result: = GRE tunnel port should be created on the new host and should have tunnels between this new host and the exiting two hosts. Actual Result: tunnel ports were not created on the new host after vm migration. When we deployed another vm on the new host then only tunnel ports and interfaces with proper gre keys and remote_ips created for mesh topology creation from the new host to the remaining hosts in the cluster. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6431) [SDN] migrating vm to a new host added to the cluster does not create gre tunnel port on the new host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980915#comment-13980915 ] ASF subversion and git services commented on CLOUDSTACK-6431: - Commit bf188fc13b0162a98146f5cc12cc196571b87910 in cloudstack's branch refs/heads/master from [~murali.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bf188fc ] CLOUDSTACK-6431: OVS migrating vm to a new host added to the cluster does not create gre tunnel port on the new host ensure OveElement gets a chance to setup tunnel network on the host before VM is migrated. [SDN] migrating vm to a new host added to the cluster does not create gre tunnel port on the new host - Key: CLOUDSTACK-6431 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6431 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.4.0 Environment: Latest build from 4.4 with commit 80d82106dcc701e9569dde16161b24ff3abfa67f Hypervisor: XenServer6.2 Reporter: Sanjeev N Assignee: Murali Reddy Priority: Critical Fix For: 4.4.0 Attachments: management-server.log.2014-04-15.gz [SDN] migrating vm to a new host added to the cluster does not create gre tunnel port on the new host Steps to Reproduce: = 1.Bring up CS in advanced zone with GRE isolation using two hosts in the xenserver cluster 2.Create an isolated network using stretched-l2 service 3.Deploy few guest vms in the network and make sure that vms are spanned across the two hosts in the cluster 4.Make sure that GRE tunnels are created between these two hosts 5.Add another host to the cluster 6.Migrate one of the vms to the new host added to the cluster Expected Result: = GRE tunnel port should be created on the new host and should have tunnels between this new host and the exiting two hosts. Actual Result: tunnel ports were not created on the new host after vm migration. When we deployed another vm on the new host then only tunnel ports and interfaces with proper gre keys and remote_ips created for mesh topology creation from the new host to the remaining hosts in the cluster. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6446) [Enhancement] Primary and secondary storage counts should be returned in Bytes in listing APIs rather than GBs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi updated CLOUDSTACK-6446: Affects Version/s: (was: 4.3.0) 4.4.0 [Enhancement] Primary and secondary storage counts should be returned in Bytes in listing APIs rather than GBs -- Key: CLOUDSTACK-6446 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6446 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Environment: All hypervisors Reporter: Gaurav Aradhye Assignee: Sanjay Tripathi Labels: automation Fix For: 4.5.0 The APIs listing the primary and secondary storage counts show the count in GB. In case when the resource usage is much smaller, in KBs or MBs, it is being shown as 0 GB. Rather than listing this in GBs, it should be shown in Bytes just like size of any resource is listed in KBs. We can later convert this into any other unit we want, e.g. if UI wants to show that in GB, it can convert it into GB and then display. For test cases purpose, it's very important that exact count is shown in Bytes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6446) [Enhancement] Primary and secondary storage counts should be returned in Bytes in listing APIs rather than GBs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi updated CLOUDSTACK-6446: Fix Version/s: (was: 4.4.0) 4.5.0 [Enhancement] Primary and secondary storage counts should be returned in Bytes in listing APIs rather than GBs -- Key: CLOUDSTACK-6446 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6446 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Environment: All hypervisors Reporter: Gaurav Aradhye Assignee: Sanjay Tripathi Labels: automation Fix For: 4.5.0 The APIs listing the primary and secondary storage counts show the count in GB. In case when the resource usage is much smaller, in KBs or MBs, it is being shown as 0 GB. Rather than listing this in GBs, it should be shown in Bytes just like size of any resource is listed in KBs. We can later convert this into any other unit we want, e.g. if UI wants to show that in GB, it can convert it into GB and then display. For test cases purpose, it's very important that exact count is shown in Bytes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6511) [Automation] Fixes for failures in BVT and component runs
Srikanteswararao Talluri created CLOUDSTACK-6511: Summary: [Automation] Fixes for failures in BVT and component runs Key: CLOUDSTACK-6511 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6511 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: marvin Affects Versions: 4.5.0 Reporter: Srikanteswararao Talluri Assignee: Srikanteswararao Talluri Priority: Blocker Fix For: 4.5.0 Fixes for failures in BVT and component runs -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6511) [Automation] Fixes for failures in BVT and component runs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980955#comment-13980955 ] ASF subversion and git services commented on CLOUDSTACK-6511: - Commit e9fb9065991a5063216f97f37082287b1b97a4e9 in cloudstack's branch refs/heads/master from SrikanteswaraRao Talluri [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e9fb906 ] CLOUDSTACK-6511: fixed for bvt and component test failures [Automation] Fixes for failures in BVT and component runs - Key: CLOUDSTACK-6511 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6511 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: marvin Affects Versions: 4.5.0 Reporter: Srikanteswararao Talluri Assignee: Srikanteswararao Talluri Priority: Blocker Fix For: 4.5.0 Fixes for failures in BVT and component runs -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-6480) Creating Service Offering with Implict Dedication planner fails with message: Please specify the pciDevice and vgpuType correctly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi reassigned CLOUDSTACK-6480: --- Assignee: Sanjay Tripathi Creating Service Offering with Implict Dedication planner fails with message: Please specify the pciDevice and vgpuType correctly Key: CLOUDSTACK-6480 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6480 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Saksham Srivastava Assignee: Sanjay Tripathi While creating SO with Implicit Dedication planner in Strict/Preferred Mode fails with log message Please specify the pciDevice and vgpuType correctly. Ideally SO should be created without specifying pciDevice abd vgpuType. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6480) Creating Service Offering with Implict Dedication planner fails with message: Please specify the pciDevice and vgpuType correctly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Tripathi updated CLOUDSTACK-6480: Fix Version/s: 4.4.0 Creating Service Offering with Implict Dedication planner fails with message: Please specify the pciDevice and vgpuType correctly Key: CLOUDSTACK-6480 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6480 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Saksham Srivastava Assignee: Sanjay Tripathi Fix For: 4.4.0 While creating SO with Implicit Dedication planner in Strict/Preferred Mode fails with log message Please specify the pciDevice and vgpuType correctly. Ideally SO should be created without specifying pciDevice abd vgpuType. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-6511) [Automation] Fixes for failures in BVT and component runs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srikanteswararao Talluri closed CLOUDSTACK-6511. [Automation] Fixes for failures in BVT and component runs - Key: CLOUDSTACK-6511 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6511 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: marvin Affects Versions: 4.5.0 Reporter: Srikanteswararao Talluri Assignee: Srikanteswararao Talluri Priority: Blocker Fix For: 4.5.0 Fixes for failures in BVT and component runs -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6511) [Automation] Fixes for failures in BVT and component runs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srikanteswararao Talluri resolved CLOUDSTACK-6511. -- Resolution: Fixed [Automation] Fixes for failures in BVT and component runs - Key: CLOUDSTACK-6511 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6511 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: marvin Affects Versions: 4.5.0 Reporter: Srikanteswararao Talluri Assignee: Srikanteswararao Talluri Priority: Blocker Fix For: 4.5.0 Fixes for failures in BVT and component runs -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6512) IAM - Not able to list shared networks in the Vm deployment flow.
Sangeetha Hariharan created CLOUDSTACK-6512: --- Summary: IAM - Not able to list shared networks in the Vm deployment flow. Key: CLOUDSTACK-6512 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6512 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Environment: Build from 4.4. Reporter: Sangeetha Hariharan Priority: Critical Fix For: 4.4.0 IAM - Not able to list shared networks in the Vm deployment flow. Steps to reproduce the problem: Create a shared network that is domain specific / account specific. Log in as the account which should have access to this shared network. Using UI , try to deploy a VM using this shared network. shared network is not displayed in the list of networks. This is the call made by UI: http://10.223.49.6:8080/client/api?command=listNetworksresponse=jsonsessionkey=Enn1TgriYaANFQ%2BDKJR7T2Jc9l0%3DzoneId=fdd0ce43-41b8-49ef-9e59-70ead27bda4ccanusefordeploy=truedomainid=a59a0ce2-b5aa-4460-ade8-91d26e048bc4account=testD1_=1398446574911 When Networks are listed using the network tab , then we see the shared network being listed. Following API call without the domainid and account paramater is able to return the shared network. http://10.223.49.6:8080/client/api?command=listNetworksresponse=jsonsessionkey=Enn1TgriYaANFQ%2BDKJR7T2Jc9l0%3DlistAll=truepage=1pagesize=20_=1398446422647 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6513) IAM - Templates - When tenplatefilter=shared
Sangeetha Hariharan created CLOUDSTACK-6513: --- Summary: IAM - Templates - When tenplatefilter=shared Key: CLOUDSTACK-6513 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6513 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Sangeetha Hariharan -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6464) [KVM:basic zone- upgrade to 4.3],after any vm restart,all the nics are plugged to default bridge even though trafiic labels are being used
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13981292#comment-13981292 ] Serg Senko commented on CLOUDSTACK-6464: Hi, This is a very critical bug which does not allow upgrade to 4.3 any KVM ( Traffic labeled ) environment. Someone can assist? [KVM:basic zone- upgrade to 4.3],after any vm restart,all the nics are plugged to default bridge even though trafiic labels are being used -- Key: CLOUDSTACK-6464 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6464 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: sadhu suresh Priority: Critical Fix For: 4.3.1 Steps: 1. create a KVM basic zone with 2 nics on host (pre 4.3 build) 2.use cloudbr0 for management and cloudbr1 for guest by specifying the traffic labels in the physical networks. 3.deploy few vms 4.upgrade to felton GA build as per the Upgrade instructions. actual result: Upgrade successful but all the vnets that were attached to cloudbr1 before upgrade are attached to cloudbr0. Due to this network connectivity is lost. Expected result: Even after upgrade ,all the vnets should be attached to the same bridge as before upgrade. ex: before Upgrade : this vms(i-5-616-VM) nic was attached to cloudbr1 and after upgrade and VM stop/start. the network rules are getting programmed in cloudbr0 .check below output ,984 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-2:null) Executing: /usr/share/cloudstack-common/scripts/vm/network/security_group.py default_network_rules --vmname i-5-616-VM --vmid 616 --vmip 10.x.x245 --vmmac 06:14:48:00:00:7f --vif vnet15 --brname cloudbr0 --nicsecips 0: dumpxml output for i-5-616-VM after upgrade( after VM restart) * virsh # dumpxml 38 domain type='kvm' id='38' namei-5-616-VM/name uuid87557942-1393-49b3-a73e-ae24c40541d1/uuid descriptionOther CentOS (64-bit)/description memory unit='KiB'2097152/memory currentMemory unit='KiB'2097152/currentMemory vcpu placement='static'1/vcpu cputune shares1000/shares /cputune os type arch='x86_64' machine='rhel6.2.0'hvm/type boot dev='cdrom'/ boot dev='hd'/ /os features acpi/ apic/ pae/ /features cpu /cpu clock offset='utc'/ on_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashdestroy/on_crash devices emulator/usr/libexec/qemu-kvm/emulator disk type='file' device='disk' driver name='qemu' type='qcow2' cache='none'/ source file='/mnt/041e5d8e-d9c1-346d-aea9-cd9c7b80a211/75544e9d-a4c9-4a94-943e-b20827676a27'/ target dev='hda' bus='ide'/ alias name='ide0-0-0'/ address type='drive' controller='0' bus='0' target='0' unit='0'/ /disk disk type='file' device='cdrom' driver name='qemu' type='raw' cache='none'/ target dev='hdc' bus='ide'/ readonly/ alias name='ide0-1-0'/ address type='drive' controller='0' bus='1' target='0' unit='0'/ /disk controller type='usb' index='0' alias name='usb0'/ address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/ /controller controller type='ide' index='0' alias name='ide0'/ address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x1'/ /controller interface type='bridge' mac address='06:14:48:00:00:7f'/ source bridge='cloudbr0'/ target dev='vnet15'/ model type='e1000'/ bandwidth inbound average='25600' peak='25600'/ outbound average='25600' peak='25600'/ /bandwidth alias name='net0'/ address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/ /interface serial type='pty' source path='/dev/pts/12'/ target port='0'/ alias name='serial0'/ /serial console type='pty' tty='/dev/pts/12' source path='/dev/pts/12'/ target type='serial' port='0'/ alias name='serial0'/ /console input type='tablet' bus='usb' alias name='input0'/ /input input type='mouse' bus='ps2'/ graphics type='vnc' port='5912' autoport='yes' listen='10.x.x.3' listen type='address' address='10.147.37.3'/ /graphics video model type='cirrus' vram='9216' heads='1'/ alias name='video0'/ address type='pci' domain='0x' bus='0x00' slot='0x02' function='0x0'/ /video memballoon model='virtio' alias name='balloon0'/ address type='pci' domain='0x' bus='0x00' slot='0x04' function='0x0'/ /memballoon /devices seclabel type='none'/ /domain its also applicable to new vm deployments. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6513) IAM - Templates - When templates are listed with templatefilter=shared is used , we see public templates also being included in the list.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeetha Hariharan updated CLOUDSTACK-6513: Component/s: IAM Description: IAM - Templates - When templates are listed with templatefilter=shared is used , we see public templates also being included in the list. Steps to reproduce the problem: As user1 , Create a private template and a public template. Grant access to the private template for user2 using updateTemplatePermissions. As user2 , list templates with templatefilter=shared. This returns both public and the the shared template. GET http://10.223.49.6/client/api?command=listTemplatespagesize=100page=1listAll=truetemplatefilter=sharedapiKey=SrgUY-U-nUl4qsOyn409kCjA2jC7dR5ReIV9SjdnmzLOn3c0Fm-vZbDSpkldUjuqLAXt5ShodtXYOgRB5NCnJQsignature=WBO8ll9nyjiB29aVq%2FpUsEQrthM%3D \n\n ?xml version=1.0 encoding=UTF-8?listtemplatesresponse cloud-stack-version=4.4.0-SNAPSHOTcount6/counttemplateida2065bcc-7139-46b0-ac15-db7d3ff7dd75/idnamePublic_featured_d1a-TP7TPK/namedisplaytextpublic and feature Template/displaytextispublictrue/ispubliccreated2014-04-21T13:50:35-0400/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedtrue/isfeaturedcrossZonesfalse/crossZonesostypeide5ebce64-c019-11e3-907f-4adf980f9414/ostypeidostypenameCentOS 5.3 (64-bit)/ostypenameaccounttesttemplateD1A/accountzoneid75d61334-ff70-49c3-99ed-3af702cd51d7/zoneidzonenameBLR1/zonenamesize5242880/sizetemplatetypeUSER/templatetypehypervisorSimulator/hypervisordomainD1/domaindomainid691ab662-6793-42a0-96e6-3b31a2c4e52d/domainidisextractabletrue/isextractablesshkeyenabledfalse/sshkeyenabledisdynamicallyscalablefalse/isdynamicallyscalable/templatetemplateidce1635dc-1fcb-4f60-8d2f-d1129a3771ce/idnamePublic_not_featured_d2a-NPYFSN/namedisplaytextpublic and not feature Template/displaytextispublictrue/ispubliccreated2014-04-21T13:50:36-0400/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedfalse/isfeaturedcrossZonesfalse/crossZonesostypeide5ebce64-c019-11e3-907f-4adf980f9414/ostypeidostypenameCentOS 5.3 (64-bit)/ostypenameaccounttesttemplateD2/accountzoneid75d61334-ff70-49c3-99ed-3af702cd51d7/zoneidzonenameBLR1/zonenamesize5242880/sizetemplatetypeUSER/templatetypehypervisorSimulator/hypervisordomainD2/domaindomainid18222e53-7221-4d6f-9a76-8f59869f24b2/domainidisextractabletrue/isextractablesshkeyenabledfalse/sshkeyenabledisdynamicallyscalablefalse/isdynamicallyscalable/templatetemplateid223e0c09-e18e-4188-9d8e-7ff2e2305547/idnamePrivate_featured_d1-E9PQHO/namedisplaytextprivate and featured Template/displaytextispublicfalse/ispubliccreated2014-04-21T13:50:36-0400/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedtrue/isfeaturedcrossZonesfalse/crossZonesostypeide5ebce64-c019-11e3-907f-4adf980f9414/ostypeidostypenameCentOS 5.3 (64-bit)/ostypenameaccounttesttemplateD1A/accountzoneid75d61334-ff70-49c3-99ed-3af702cd51d7/zoneidzonenameBLR1/zonenamesize5242880/sizetemplatetypeUSER/templatetypehypervisorSimulator/hypervisordomainD1/domaindomainid691ab662-6793-42a0-96e6-3b31a2c4e52d/domainidisextractabletrue/isextractablesshkeyenabledfalse/sshkeyenabledisdynamicallyscalablefalse/isdynamicallyscalable/templatetemplateida7b69a5e-4cb3-45fa-b3e7-dab3a6b73e45/idnamePublic_not_featured_d1a-XOCR05/namedisplaytextpublic and not feature Template/displaytextispublictrue/ispubliccreated2014-04-21T13:50:35-0400/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedfalse/isfeaturedcrossZonesfalse/crossZonesostypeide5ebce64-c019-11e3-907f-4adf980f9414/ostypeidostypenameCentOS 5.3 (64-bit)/ostypenameaccounttesttemplateD1A/accountzoneid75d61334-ff70-49c3-99ed-3af702cd51d7/zoneidzonenameBLR1/zonenamesize5242880/sizetemplatetypeUSER/templatetypehypervisorSimulator/hypervisordomainD1/domaindomainid691ab662-6793-42a0-96e6-3b31a2c4e52d/domainidisextractabletrue/isextractablesshkeyenabledfalse/sshkeyenabledisdynamicallyscalablefalse/isdynamicallyscalable/templatetemplateide65cdfa0-c019-11e3-907f-4adf980f9414/idnameCentOS 5.3(64-bit) no GUI (Simulator)/namedisplaytextCentOS 5.3(64-bit) no GUI (Simulator)/displaytextispublictrue/ispubliccreated2014-04-09T15:15:54-0400/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedtrue/isfeaturedcrossZonestrue/crossZonesostypeide5eba5c4-c019-11e3-907f-4adf980f9414/ostypeidostypenameCentOS 5.3
[jira] [Updated] (CLOUDSTACK-6512) IAM - Not able to list shared networks in the Vm deployment flow.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeetha Hariharan updated CLOUDSTACK-6512: Component/s: (was: Management Server) IAM IAM - Not able to list shared networks in the Vm deployment flow. - Key: CLOUDSTACK-6512 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6512 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: IAM Affects Versions: 4.4.0 Environment: Build from 4.4. Reporter: Sangeetha Hariharan Priority: Critical Fix For: 4.4.0 IAM - Not able to list shared networks in the Vm deployment flow. Steps to reproduce the problem: Create a shared network that is domain specific / account specific. Log in as the account which should have access to this shared network. Using UI , try to deploy a VM using this shared network. shared network is not displayed in the list of networks. This is the call made by UI: http://10.223.49.6:8080/client/api?command=listNetworksresponse=jsonsessionkey=Enn1TgriYaANFQ%2BDKJR7T2Jc9l0%3DzoneId=fdd0ce43-41b8-49ef-9e59-70ead27bda4ccanusefordeploy=truedomainid=a59a0ce2-b5aa-4460-ade8-91d26e048bc4account=testD1_=1398446574911 When Networks are listed using the network tab , then we see the shared network being listed. Following API call without the domainid and account paramater is able to return the shared network. http://10.223.49.6:8080/client/api?command=listNetworksresponse=jsonsessionkey=Enn1TgriYaANFQ%2BDKJR7T2Jc9l0%3DlistAll=truepage=1pagesize=20_=1398446422647 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6513) IAM - Templates - When templates are listed with templatefilter=shared is used , we see public templates also being included in the list.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeetha Hariharan updated CLOUDSTACK-6513: Priority: Critical (was: Major) IAM - Templates - When templates are listed with templatefilter=shared is used , we see public templates also being included in the list. --- Key: CLOUDSTACK-6513 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6513 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: IAM Affects Versions: 4.4.0 Environment: Build from 4.4 Reporter: Sangeetha Hariharan Priority: Critical Fix For: 4.4.0 IAM - Templates - When templates are listed with templatefilter=shared is used , we see public templates also being included in the list. Steps to reproduce the problem: As user1 , Create a private template and a public template. Grant access to the private template for user2 using updateTemplatePermissions. As user2 , list templates with templatefilter=shared. This returns both public and the the shared template. GET http://10.223.49.6/client/api?command=listTemplatespagesize=100page=1listAll=truetemplatefilter=sharedapiKey=SrgUY-U-nUl4qsOyn409kCjA2jC7dR5ReIV9SjdnmzLOn3c0Fm-vZbDSpkldUjuqLAXt5ShodtXYOgRB5NCnJQsignature=WBO8ll9nyjiB29aVq%2FpUsEQrthM%3D \n\n ?xml version=1.0 encoding=UTF-8?listtemplatesresponse cloud-stack-version=4.4.0-SNAPSHOTcount6/counttemplateida2065bcc-7139-46b0-ac15-db7d3ff7dd75/idnamePublic_featured_d1a-TP7TPK/namedisplaytextpublic and feature Template/displaytextispublictrue/ispubliccreated2014-04-21T13:50:35-0400/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedtrue/isfeaturedcrossZonesfalse/crossZonesostypeide5ebce64-c019-11e3-907f-4adf980f9414/ostypeidostypenameCentOS 5.3 (64-bit)/ostypenameaccounttesttemplateD1A/accountzoneid75d61334-ff70-49c3-99ed-3af702cd51d7/zoneidzonenameBLR1/zonenamesize5242880/sizetemplatetypeUSER/templatetypehypervisorSimulator/hypervisordomainD1/domaindomainid691ab662-6793-42a0-96e6-3b31a2c4e52d/domainidisextractabletrue/isextractablesshkeyenabledfalse/sshkeyenabledisdynamicallyscalablefalse/isdynamicallyscalable/templatetemplateidce1635dc-1fcb-4f60-8d2f-d1129a3771ce/idnamePublic_not_featured_d2a-NPYFSN/namedisplaytextpublic and not feature Template/displaytextispublictrue/ispubliccreated2014-04-21T13:50:36-0400/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedfalse/isfeaturedcrossZonesfalse/crossZonesostypeide5ebce64-c019-11e3-907f-4adf980f9414/ostypeidostypenameCentOS 5.3 (64-bit)/ostypenameaccounttesttemplateD2/accountzoneid75d61334-ff70-49c3-99ed-3af702cd51d7/zoneidzonenameBLR1/zonenamesize5242880/sizetemplatetypeUSER/templatetypehypervisorSimulator/hypervisordomainD2/domaindomainid18222e53-7221-4d6f-9a76-8f59869f24b2/domainidisextractabletrue/isextractablesshkeyenabledfalse/sshkeyenabledisdynamicallyscalablefalse/isdynamicallyscalable/templatetemplateid223e0c09-e18e-4188-9d8e-7ff2e2305547/idnamePrivate_featured_d1-E9PQHO/namedisplaytextprivate and featured Template/displaytextispublicfalse/ispubliccreated2014-04-21T13:50:36-0400/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedtrue/isfeaturedcrossZonesfalse/crossZonesostypeide5ebce64-c019-11e3-907f-4adf980f9414/ostypeidostypenameCentOS 5.3 (64-bit)/ostypenameaccounttesttemplateD1A/accountzoneid75d61334-ff70-49c3-99ed-3af702cd51d7/zoneidzonenameBLR1/zonenamesize5242880/sizetemplatetypeUSER/templatetypehypervisorSimulator/hypervisordomainD1/domaindomainid691ab662-6793-42a0-96e6-3b31a2c4e52d/domainidisextractabletrue/isextractablesshkeyenabledfalse/sshkeyenabledisdynamicallyscalablefalse/isdynamicallyscalable/templatetemplateida7b69a5e-4cb3-45fa-b3e7-dab3a6b73e45/idnamePublic_not_featured_d1a-XOCR05/namedisplaytextpublic and not feature Template/displaytextispublictrue/ispubliccreated2014-04-21T13:50:35-0400/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedfalse/isfeaturedcrossZonesfalse/crossZonesostypeide5ebce64-c019-11e3-907f-4adf980f9414/ostypeidostypenameCentOS 5.3 (64-bit)/ostypenameaccounttesttemplateD1A/accountzoneid75d61334-ff70-49c3-99ed-3af702cd51d7/zoneidzonenameBLR1/zonenamesize5242880/sizetemplatetypeUSER/templatetypehypervisorSimulator/hypervisordomainD1/domaindomainid691ab662-6793-42a0-96e6-3b31a2c4e52d/domainidisextractabletrue/isextractablesshkeyenabledfalse/sshkeyenabledisdynamicallyscalablefalse/isdynamicallyscalable/templatetemplateide65cdfa0-c019-11e3-907f-4adf980f9414/idnameCentOS 5.3(64-bit) no
[jira] [Commented] (CLOUDSTACK-6170) Support managed storage for root disks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13981412#comment-13981412 ] ASF subversion and git services commented on CLOUDSTACK-6170: - Commit 6dfa742eb8d6b775317829636bfa28f0ec297242 in cloudstack's branch refs/heads/4.4-forward from [~mike-tutkowski] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6dfa742 ] CLOUDSTACK-6170 Updated logic to more accurately calculate how much space is currently allocated for a managed storage pool Support managed storage for root disks -- Key: CLOUDSTACK-6170 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6170 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Environment: I expect to support managed storage for root disks on XenServer (ESX and KVM are targeted for 4.5). Reporter: Mike Tutkowski Assignee: Mike Tutkowski Fix For: 4.4.0 Cloud environments have a need for guaranteed storage performance. By this I mean having the ability to specify a minimum and maximum number of IOPS on a volume-by-volume basis. I added support for this for XenServer and ESX in 4.2 for data disks. I added support for this for KVM in 4.3 for data disks. It is my intent to add support for this for XenServer and ESX in 4.4 for root disks (with subsequent support for root disks on KVM expected in 4.5). The main changes are expected to occur in CloudStack logic that controls hypervisors and additions to the way root-volume orchestration happens. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6170) Support managed storage for root disks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13981413#comment-13981413 ] ASF subversion and git services commented on CLOUDSTACK-6170: - Commit 2960ba733afcb6e8d056473475eb3e610d7250dc in cloudstack's branch refs/heads/master from [~mike-tutkowski] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2960ba7 ] CLOUDSTACK-6170 Updated logic to more accurately calculate how much space is currently allocated for a managed storage pool Support managed storage for root disks -- Key: CLOUDSTACK-6170 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6170 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Environment: I expect to support managed storage for root disks on XenServer (ESX and KVM are targeted for 4.5). Reporter: Mike Tutkowski Assignee: Mike Tutkowski Fix For: 4.4.0 Cloud environments have a need for guaranteed storage performance. By this I mean having the ability to specify a minimum and maximum number of IOPS on a volume-by-volume basis. I added support for this for XenServer and ESX in 4.2 for data disks. I added support for this for KVM in 4.3 for data disks. It is my intent to add support for this for XenServer and ESX in 4.4 for root disks (with subsequent support for root disks on KVM expected in 4.5). The main changes are expected to occur in CloudStack logic that controls hypervisors and additions to the way root-volume orchestration happens. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6444) [Automation] test_01_primary_storage_iscsi failed on test_primary_storage.py - Wrong iscsi path format - it should be /targetIQN/LUN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13981424#comment-13981424
]
Min Chen commented on CLOUDSTACK-6444:
--
This seems not IAM related. The error message from IAM is normally permission
denied or some results are not returned in list call. This clearly indicated
that the parameter passed to createStoragePool is not the correct format.
[Automation] test_01_primary_storage_iscsi failed on
test_primary_storage.py - Wrong iscsi path format - it should be
/targetIQN/LUN
Key: CLOUDSTACK-6444
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6444
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation, XenServer
Affects Versions: 4.4.0
Reporter: Chandan Purushothama
Assignee: Min Chen
Priority: Blocker
Fix For: 4.4.0
Attachments: management-server.log.2014-04-16.gz
Error Message:
Execute cmd: createstoragepool failed, due to: errorCode: 530, errorText:None
begin captured logging
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
STARTED : TC: test_01_primary_storage_iscsi :::
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
sending GET request: listZones {}
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
Computed Signature by Marvin: zCinw6XM4JSpQF6uNjzREWyHshQ=
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 10.223.240.161
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listZonessignature=zCinw6XM4JSpQF6uNjzREWyHshQ%3Dresponse=json
HTTP/1.1 200 735
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
Request:
http://10.223.240.161:8080/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listZonessignature=zCinw6XM4JSpQF6uNjzREWyHshQ%3Dresponse=json
Response: { listzonesresponse : { count:2 ,zone : [
{id:4fbc4494-e655-49b6-bda1-7ad8eb641732,name:test0,dns1:10.223.240.232,dns2:10.223.240.234,internaldns1:10.223.240.232,networktype:Basic,securitygroupsenabled:true,allocationstate:Enabled,zonetoken:f0aed2ee-a79d-3608-bae5-09972653a6cf,dhcpprovider:VirtualRouter,localstorageenabled:false,tags:[]},
{id:55fe83ca-4160-40b2-89cb-63cadf8b90f9,name:test1,dns1:10.223.240.234,dns2:10.223.240.232,internaldns1:10.223.240.232,networktype:Basic,securitygroupsenabled:true,allocationstate:Enabled,zonetoken:3973cd3a-d2ed-3242-8431-b40f919051f1,dhcpprovider:VirtualRouter,localstorageenabled:false,tags:[]}
] } }
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
sending GET request: listPods {'zoneid':
u'4fbc4494-e655-49b6-bda1-7ad8eb641732'}
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
Computed Signature by Marvin: Q5eN6r9ACb1qiPi7CI3wiB6wh0k=
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 10.223.240.161
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listPodssignature=Q5eN6r9ACb1qiPi7CI3wiB6wh0k%3Dzoneid=4fbc4494-e655-49b6-bda1-7ad8eb641732response=json
HTTP/1.1 200 314
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
Request:
http://10.223.240.161:8080/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listPodssignature=Q5eN6r9ACb1qiPi7CI3wiB6wh0k%3Dzoneid=4fbc4494-e655-49b6-bda1-7ad8eb641732response=json
Response: { listpodsresponse : { count:1 ,pod : [
{id:d99714b2-7164-4d85-b5a6-c0caf12eb57a,name:test0pod0,zoneid:4fbc4494-e655-49b6-bda1-7ad8eb641732,zonename:test0,gateway:10.223.251.1,netmask:255.255.255.192,startip:10.223.251.4,endip:10.223.251.14,allocationstate:Enabled}
] } }
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
sending GET request: listClusters {'zoneid':
u'4fbc4494-e655-49b6-bda1-7ad8eb641732'}
test_01_primary_storage_iscsi
[jira] [Updated] (CLOUDSTACK-6444) [Automation] test_01_primary_storage_iscsi failed on test_primary_storage.py - Wrong iscsi path format - it should be /targetIQN/LUN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen updated CLOUDSTACK-6444:
-
Assignee: (was: Min Chen)
[Automation] test_01_primary_storage_iscsi failed on
test_primary_storage.py - Wrong iscsi path format - it should be
/targetIQN/LUN
Key: CLOUDSTACK-6444
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6444
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation, XenServer
Affects Versions: 4.4.0
Reporter: Chandan Purushothama
Priority: Blocker
Fix For: 4.4.0
Attachments: management-server.log.2014-04-16.gz
Error Message:
Execute cmd: createstoragepool failed, due to: errorCode: 530, errorText:None
begin captured logging
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
STARTED : TC: test_01_primary_storage_iscsi :::
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
sending GET request: listZones {}
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
Computed Signature by Marvin: zCinw6XM4JSpQF6uNjzREWyHshQ=
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 10.223.240.161
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listZonessignature=zCinw6XM4JSpQF6uNjzREWyHshQ%3Dresponse=json
HTTP/1.1 200 735
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
Request:
http://10.223.240.161:8080/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listZonessignature=zCinw6XM4JSpQF6uNjzREWyHshQ%3Dresponse=json
Response: { listzonesresponse : { count:2 ,zone : [
{id:4fbc4494-e655-49b6-bda1-7ad8eb641732,name:test0,dns1:10.223.240.232,dns2:10.223.240.234,internaldns1:10.223.240.232,networktype:Basic,securitygroupsenabled:true,allocationstate:Enabled,zonetoken:f0aed2ee-a79d-3608-bae5-09972653a6cf,dhcpprovider:VirtualRouter,localstorageenabled:false,tags:[]},
{id:55fe83ca-4160-40b2-89cb-63cadf8b90f9,name:test1,dns1:10.223.240.234,dns2:10.223.240.232,internaldns1:10.223.240.232,networktype:Basic,securitygroupsenabled:true,allocationstate:Enabled,zonetoken:3973cd3a-d2ed-3242-8431-b40f919051f1,dhcpprovider:VirtualRouter,localstorageenabled:false,tags:[]}
] } }
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
sending GET request: listPods {'zoneid':
u'4fbc4494-e655-49b6-bda1-7ad8eb641732'}
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
Computed Signature by Marvin: Q5eN6r9ACb1qiPi7CI3wiB6wh0k=
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 10.223.240.161
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listPodssignature=Q5eN6r9ACb1qiPi7CI3wiB6wh0k%3Dzoneid=4fbc4494-e655-49b6-bda1-7ad8eb641732response=json
HTTP/1.1 200 314
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
Request:
http://10.223.240.161:8080/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listPodssignature=Q5eN6r9ACb1qiPi7CI3wiB6wh0k%3Dzoneid=4fbc4494-e655-49b6-bda1-7ad8eb641732response=json
Response: { listpodsresponse : { count:1 ,pod : [
{id:d99714b2-7164-4d85-b5a6-c0caf12eb57a,name:test0pod0,zoneid:4fbc4494-e655-49b6-bda1-7ad8eb641732,zonename:test0,gateway:10.223.251.1,netmask:255.255.255.192,startip:10.223.251.4,endip:10.223.251.14,allocationstate:Enabled}
] } }
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
sending GET request: listClusters {'zoneid':
u'4fbc4494-e655-49b6-bda1-7ad8eb641732'}
test_01_primary_storage_iscsi
(integration.smoke.test_primary_storage.TestPrimaryStorageServices): DEBUG:
Computed Signature by Marvin: CGgAerZxK5EJBr34YnPiWBJHqWg=
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 10.223.240.161
requests.packages.urllib3.connectionpool: DEBUG: GET
[jira] [Created] (CLOUDSTACK-6514) VMware: Is space allocated for snapshots counted correctly?
Mike Tutkowski created CLOUDSTACK-6514: -- Summary: VMware: Is space allocated for snapshots counted correctly? Key: CLOUDSTACK-6514 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6514 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.4.0 Environment: Ubuntu 12.04 for CloudStack Management Server (just one in this config) Two ESXi 5.1 hosts Reporter: Mike Tutkowski Fix For: 4.4.0 long CapacityManager.getAllocatedPoolCapacity(StoragePoolVO, VMTemplateVO) may not add up allocated space in the passed-in storage pool properly for VMware. The idea is to count the allocated space of all non-destroyed volumes and the corresponding allocated space of their snapshots, if any. In addition, templates on the storage pool should be taken into consideration. I think the number that is in the vm_snapshot_chain_size column of the volumes table is not correctly calculated (and this number is used by the getAllocatedPoolCapacity method when it invokes another method). This is how it currently works when you have a new VM and you take a snapshot of it for the first time (not taking a snapshot of memory): These are the relevant files and their respective sizes: ROOT-21-01-delta.vmdk (16,785,408 bytes) ROOT-21-01.vmdk (316 bytes) ROOT-21-flat.vmdk (2,147,483,648 bytes) ROOT-21.vmdk (515 bytes) i-2-21-VM-Snapshot1.vmsn (28,310 bytes) We include these files for the vm_snapshot_chain_size: ROOT-21-flat.vmdk (2,147,483,648 bytes) ROOT-21.vmdk (515 bytes) i-2-21-VM-Snapshot1.vmsn (28,310 bytes) I think we should be counting these instead: ROOT-21-01-delta.vmdk (16,785,408 bytes) ROOT-21-01.vmdk (316 bytes) i-2-21-VM-Snapshot1.vmsn (28,310 bytes) My thinking is that when we add up the total space that this volume consumes that we've already taking into account 2,147,483,648 bytes because this value is stored in the size column of the volumes table. I would think we'd want to add up the sizes of the VMSN files and the sizes of the -xx files to arrive at vm_snapshot_chain_size? Any thoughts on this? Thanks! -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6437) Ability to differentiate user and system guest OS and mappings
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13981532#comment-13981532 ] ASF subversion and git services commented on CLOUDSTACK-6437: - Commit 78c683f5682560deffa405ac76edf23f8e17565d in cloudstack's branch refs/heads/master from [~amogh.vasekar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=78c683f ] CLOUDSTACK-6437: Add ability to distinguish between user defined and system defined guest OS and mappings Add default mappings for XenServer Local testing with 1. Add new guest OS by API 2. Add new guest OS mapping by API Ability to differentiate user and system guest OS and mappings -- Key: CLOUDSTACK-6437 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6437 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: Amogh Vasekar Assignee: Amogh Vasekar Priority: Critical Fix For: 4.4.0 During upgrades, we need a way to distinguish between user defined and system defined guest OS and mappings. If not, using same names etc might overwrite changes -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6515) VMware: Only updating chain_info in volumes table when VM is started
Mike Tutkowski created CLOUDSTACK-6515: -- Summary: VMware: Only updating chain_info in volumes table when VM is started Key: CLOUDSTACK-6515 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6515 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.4.0 Environment: Ubuntu 12.04 for CloudStack Management Server (only one in this config) Two ESXi 5.1 hosts Reporter: Mike Tutkowski Fix For: 4.4.0 From an e-mail I sent out to the CloudStack distribution list: Is it a problem that we only ever update the chain_info column in the volumes table after a VM has successfully been started? For example, if I take a VM snapshot and then examine this column, it is not up to date. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6516) Default value of secstorage.encrypt.copy overridden
Amogh Vasekar created CLOUDSTACK-6516: - Summary: Default value of secstorage.encrypt.copy overridden Key: CLOUDSTACK-6516 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6516 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Amogh Vasekar Assignee: Amogh Vasekar Fix For: 4.4.0 In 4.3, SSL was turned off by default. However, for SSVM, the value from configuration server overrides the default in Config.java. Work around is to change in global properties. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6505) bridge gets reset for cluster level OVS network.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13981548#comment-13981548 ] ASF subversion and git services commented on CLOUDSTACK-6505: - Commit 61fc57121c0edfd77afc2096eb93b9341634f91b in cloudstack's branch refs/heads/4.4 from [~murali.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=61fc571 ] CLOUDSTACK-6505: XenServer bridge for the OVS tunnel network gets reset on the hosts in the xenserver cluster this fix ensures that brige is created only once so that openflow rules configured on the bridge are not lost. bridge gets reset for cluster level OVS network. Key: CLOUDSTACK-6505 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6505 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Murali Reddy Assignee: Murali Reddy Fix For: 4.4.0 This is regression introduced by below commit. commit faf52530cc9ff5827825eefe1c09b2887d0a0883 Author: Murali Reddy muralimmre...@gmail.com Date: Tue Apr 8 19:04:06 2014 +0530 CLOUDSTACK-6356: OVS: tunnel networks does not work across the XenServer clusers To make internal network work across the cluster, above fix introduced logic to plug/un-plug VIF in dom0 connected to OVS internal nework. this logic would ensure there is a bridge created on each host. But this logic should execute only once to created bridge. Currently its executing multiple times resulting in bridge to be recreated and hence loosing all the open flow rules. configured. Fix for this bug should ensure we only create bridge once on each for the OVS tunnel network. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6170) Support managed storage for root disks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13981550#comment-13981550 ] ASF subversion and git services commented on CLOUDSTACK-6170: - Commit 6b342ffce74dcd5d0d3562b3ee7ccfb7626e3ace in cloudstack's branch refs/heads/4.4 from [~mike-tutkowski] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6b342ff ] CLOUDSTACK-6170 Updated logic to more accurately calculate how much space is currently allocated for a managed storage pool Support managed storage for root disks -- Key: CLOUDSTACK-6170 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6170 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Environment: I expect to support managed storage for root disks on XenServer (ESX and KVM are targeted for 4.5). Reporter: Mike Tutkowski Assignee: Mike Tutkowski Fix For: 4.4.0 Cloud environments have a need for guaranteed storage performance. By this I mean having the ability to specify a minimum and maximum number of IOPS on a volume-by-volume basis. I added support for this for XenServer and ESX in 4.2 for data disks. I added support for this for KVM in 4.3 for data disks. It is my intent to add support for this for XenServer and ESX in 4.4 for root disks (with subsequent support for root disks on KVM expected in 4.5). The main changes are expected to occur in CloudStack logic that controls hypervisors and additions to the way root-volume orchestration happens. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6507) ensure sequence numbers are honoured while processing OvsVpcPhysicalTopologyConfigCommand and OvsVpcRoutingPolicyConfigCommand
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13981547#comment-13981547 ] ASF subversion and git services commented on CLOUDSTACK-6507: - Commit cbe326838d77c0f4d22010ce9419a2854ad07e82 in cloudstack's branch refs/heads/4.4 from [~murali.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cbe3268 ] CLOUDSTACK-6507: ensure sequence numbers are honoured while processing OvsVpcPhysicalTopologyConfigCommand and OvsVpcRoutingPolicyConfigCommand fix ensures only latest updates are applied (new openflow rules) to the bidge enabled for distributed routing. ensure sequence numbers are honoured while processing OvsVpcPhysicalTopologyConfigCommand and OvsVpcRoutingPolicyConfigCommand --- Key: CLOUDSTACK-6507 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6507 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Murali Reddy Assignee: Murali Reddy Fix For: 4.4.0 ensure sequence numbers are honoured while processing OvsVpcPhysicalTopologyConfigCommand and OvsVpcRoutingPolicyConfigCommand. On the scripts that process these commands, should check the last sequence number stored in the bridge, only if the update is latest (i.e. sequence number in the command the last sequence number stored in hte bridge config). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6431) [SDN] migrating vm to a new host added to the cluster does not create gre tunnel port on the new host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13981549#comment-13981549 ] ASF subversion and git services commented on CLOUDSTACK-6431: - Commit 5ba7f6c00628dc971a338e4b5ecab49ef1965b37 in cloudstack's branch refs/heads/4.4 from [~murali.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5ba7f6c ] CLOUDSTACK-6431: OVS migrating vm to a new host added to the cluster does not create gre tunnel port on the new host ensure OveElement gets a chance to setup tunnel network on the host before VM is migrated. [SDN] migrating vm to a new host added to the cluster does not create gre tunnel port on the new host - Key: CLOUDSTACK-6431 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6431 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Network Controller Affects Versions: 4.4.0 Environment: Latest build from 4.4 with commit 80d82106dcc701e9569dde16161b24ff3abfa67f Hypervisor: XenServer6.2 Reporter: Sanjeev N Assignee: Murali Reddy Priority: Critical Fix For: 4.4.0 Attachments: management-server.log.2014-04-15.gz [SDN] migrating vm to a new host added to the cluster does not create gre tunnel port on the new host Steps to Reproduce: = 1.Bring up CS in advanced zone with GRE isolation using two hosts in the xenserver cluster 2.Create an isolated network using stretched-l2 service 3.Deploy few guest vms in the network and make sure that vms are spanned across the two hosts in the cluster 4.Make sure that GRE tunnels are created between these two hosts 5.Add another host to the cluster 6.Migrate one of the vms to the new host added to the cluster Expected Result: = GRE tunnel port should be created on the new host and should have tunnels between this new host and the exiting two hosts. Actual Result: tunnel ports were not created on the new host after vm migration. When we deployed another vm on the new host then only tunnel ports and interfaces with proper gre keys and remote_ips created for mesh topology creation from the new host to the remaining hosts in the cluster. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6499) bug fixes for replacing realhostip with custom domain
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13981545#comment-13981545 ] ASF subversion and git services commented on CLOUDSTACK-6499: - Commit 2f96d430c80121a4e1f5714915c30609f38fb11a in cloudstack's branch refs/heads/4.4 from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2f96d43 ] CLOUDSTACK-6499: Made changes so that uploading custom certificate works for ssvm. 1. Reboot ssvm only when private key is passed meaning the server cert is passed. This is because while uploading the server cert is the last to be uploaded. And we want to propagate the entire chain once uploading is done. 2. Change the SecStorageSetupCommand sent to ssvm so that it also carries the root cert apart from having the chain and the server cert and key. 3. Change ssvm agent code to be able to configure root cert to the java key store. 4. Change ssvm configure ssl script to insert the chain certs correctly. 5. Fix order of chain certificates for apache webserver in SSVM 6. Remove double encoding and decoding for uploadCustomCertificate API from UI and server code respectively, so that API call without UI works fine 7. Java 1.7 - disable using SNI since copyTemplate doesnt work for SSL. bug fixes for replacing realhostip with custom domain - Key: CLOUDSTACK-6499 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6499 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Fix For: 4.4.0 bug fixes for replacing realhostip with custom domain -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-6512) IAM - Not able to list shared networks in the Vm deployment flow.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen reassigned CLOUDSTACK-6512: Assignee: Min Chen IAM - Not able to list shared networks in the Vm deployment flow. - Key: CLOUDSTACK-6512 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6512 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: IAM Affects Versions: 4.4.0 Environment: Build from 4.4. Reporter: Sangeetha Hariharan Assignee: Min Chen Priority: Critical Fix For: 4.4.0 IAM - Not able to list shared networks in the Vm deployment flow. Steps to reproduce the problem: Create a shared network that is domain specific / account specific. Log in as the account which should have access to this shared network. Using UI , try to deploy a VM using this shared network. shared network is not displayed in the list of networks. This is the call made by UI: http://10.223.49.6:8080/client/api?command=listNetworksresponse=jsonsessionkey=Enn1TgriYaANFQ%2BDKJR7T2Jc9l0%3DzoneId=fdd0ce43-41b8-49ef-9e59-70ead27bda4ccanusefordeploy=truedomainid=a59a0ce2-b5aa-4460-ade8-91d26e048bc4account=testD1_=1398446574911 When Networks are listed using the network tab , then we see the shared network being listed. Following API call without the domainid and account paramater is able to return the shared network. http://10.223.49.6:8080/client/api?command=listNetworksresponse=jsonsessionkey=Enn1TgriYaANFQ%2BDKJR7T2Jc9l0%3DlistAll=truepage=1pagesize=20_=1398446422647 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-6513) IAM - Templates - When templates are listed with templatefilter=shared is used , we see public templates also being included in the list.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen reassigned CLOUDSTACK-6513: Assignee: Min Chen IAM - Templates - When templates are listed with templatefilter=shared is used , we see public templates also being included in the list. --- Key: CLOUDSTACK-6513 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6513 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: IAM Affects Versions: 4.4.0 Environment: Build from 4.4 Reporter: Sangeetha Hariharan Assignee: Min Chen Priority: Critical Fix For: 4.4.0 IAM - Templates - When templates are listed with templatefilter=shared is used , we see public templates also being included in the list. Steps to reproduce the problem: As user1 , Create a private template and a public template. Grant access to the private template for user2 using updateTemplatePermissions. As user2 , list templates with templatefilter=shared. This returns both public and the the shared template. GET http://10.223.49.6/client/api?command=listTemplatespagesize=100page=1listAll=truetemplatefilter=sharedapiKey=SrgUY-U-nUl4qsOyn409kCjA2jC7dR5ReIV9SjdnmzLOn3c0Fm-vZbDSpkldUjuqLAXt5ShodtXYOgRB5NCnJQsignature=WBO8ll9nyjiB29aVq%2FpUsEQrthM%3D \n\n ?xml version=1.0 encoding=UTF-8?listtemplatesresponse cloud-stack-version=4.4.0-SNAPSHOTcount6/counttemplateida2065bcc-7139-46b0-ac15-db7d3ff7dd75/idnamePublic_featured_d1a-TP7TPK/namedisplaytextpublic and feature Template/displaytextispublictrue/ispubliccreated2014-04-21T13:50:35-0400/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedtrue/isfeaturedcrossZonesfalse/crossZonesostypeide5ebce64-c019-11e3-907f-4adf980f9414/ostypeidostypenameCentOS 5.3 (64-bit)/ostypenameaccounttesttemplateD1A/accountzoneid75d61334-ff70-49c3-99ed-3af702cd51d7/zoneidzonenameBLR1/zonenamesize5242880/sizetemplatetypeUSER/templatetypehypervisorSimulator/hypervisordomainD1/domaindomainid691ab662-6793-42a0-96e6-3b31a2c4e52d/domainidisextractabletrue/isextractablesshkeyenabledfalse/sshkeyenabledisdynamicallyscalablefalse/isdynamicallyscalable/templatetemplateidce1635dc-1fcb-4f60-8d2f-d1129a3771ce/idnamePublic_not_featured_d2a-NPYFSN/namedisplaytextpublic and not feature Template/displaytextispublictrue/ispubliccreated2014-04-21T13:50:36-0400/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedfalse/isfeaturedcrossZonesfalse/crossZonesostypeide5ebce64-c019-11e3-907f-4adf980f9414/ostypeidostypenameCentOS 5.3 (64-bit)/ostypenameaccounttesttemplateD2/accountzoneid75d61334-ff70-49c3-99ed-3af702cd51d7/zoneidzonenameBLR1/zonenamesize5242880/sizetemplatetypeUSER/templatetypehypervisorSimulator/hypervisordomainD2/domaindomainid18222e53-7221-4d6f-9a76-8f59869f24b2/domainidisextractabletrue/isextractablesshkeyenabledfalse/sshkeyenabledisdynamicallyscalablefalse/isdynamicallyscalable/templatetemplateid223e0c09-e18e-4188-9d8e-7ff2e2305547/idnamePrivate_featured_d1-E9PQHO/namedisplaytextprivate and featured Template/displaytextispublicfalse/ispubliccreated2014-04-21T13:50:36-0400/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedtrue/isfeaturedcrossZonesfalse/crossZonesostypeide5ebce64-c019-11e3-907f-4adf980f9414/ostypeidostypenameCentOS 5.3 (64-bit)/ostypenameaccounttesttemplateD1A/accountzoneid75d61334-ff70-49c3-99ed-3af702cd51d7/zoneidzonenameBLR1/zonenamesize5242880/sizetemplatetypeUSER/templatetypehypervisorSimulator/hypervisordomainD1/domaindomainid691ab662-6793-42a0-96e6-3b31a2c4e52d/domainidisextractabletrue/isextractablesshkeyenabledfalse/sshkeyenabledisdynamicallyscalablefalse/isdynamicallyscalable/templatetemplateida7b69a5e-4cb3-45fa-b3e7-dab3a6b73e45/idnamePublic_not_featured_d1a-XOCR05/namedisplaytextpublic and not feature Template/displaytextispublictrue/ispubliccreated2014-04-21T13:50:35-0400/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedfalse/isfeaturedcrossZonesfalse/crossZonesostypeide5ebce64-c019-11e3-907f-4adf980f9414/ostypeidostypenameCentOS 5.3 (64-bit)/ostypenameaccounttesttemplateD1A/accountzoneid75d61334-ff70-49c3-99ed-3af702cd51d7/zoneidzonenameBLR1/zonenamesize5242880/sizetemplatetypeUSER/templatetypehypervisorSimulator/hypervisordomainD1/domaindomainid691ab662-6793-42a0-96e6-3b31a2c4e52d/domainidisextractabletrue/isextractablesshkeyenabledfalse/sshkeyenabledisdynamicallyscalablefalse/isdynamicallyscalable/templatetemplateide65cdfa0-c019-11e3-907f-4adf980f9414/idnameCentOS 5.3(64-bit) no
[jira] [Commented] (CLOUDSTACK-6512) IAM - Not able to list shared networks in the Vm deployment flow.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13981655#comment-13981655 ] ASF subversion and git services commented on CLOUDSTACK-6512: - Commit 092b4be8d91e2e63aea12e1d40aa264e144e6d84 in cloudstack's branch refs/heads/4.4-forward from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=092b4be ] CLOUDSTACK-6512:IAM - Not able to list shared networks in the Vm deployment flow. This commit is to revert ec5ee761d98c67c7da2ea70b623d4a9f3da966b5 to still use old logic for listNetworks to keep old behavior instead of new IAM model. IAM - Not able to list shared networks in the Vm deployment flow. - Key: CLOUDSTACK-6512 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6512 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: IAM Affects Versions: 4.4.0 Environment: Build from 4.4. Reporter: Sangeetha Hariharan Assignee: Min Chen Priority: Critical Fix For: 4.4.0 IAM - Not able to list shared networks in the Vm deployment flow. Steps to reproduce the problem: Create a shared network that is domain specific / account specific. Log in as the account which should have access to this shared network. Using UI , try to deploy a VM using this shared network. shared network is not displayed in the list of networks. This is the call made by UI: http://10.223.49.6:8080/client/api?command=listNetworksresponse=jsonsessionkey=Enn1TgriYaANFQ%2BDKJR7T2Jc9l0%3DzoneId=fdd0ce43-41b8-49ef-9e59-70ead27bda4ccanusefordeploy=truedomainid=a59a0ce2-b5aa-4460-ade8-91d26e048bc4account=testD1_=1398446574911 When Networks are listed using the network tab , then we see the shared network being listed. Following API call without the domainid and account paramater is able to return the shared network. http://10.223.49.6:8080/client/api?command=listNetworksresponse=jsonsessionkey=Enn1TgriYaANFQ%2BDKJR7T2Jc9l0%3DlistAll=truepage=1pagesize=20_=1398446422647 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6478) Failed to download Template when having 3 SSVM's in one zone on Vmware
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-6478. -- Resolution: Fixed Failed to download Template when having 3 SSVM's in one zone on Vmware -- Key: CLOUDSTACK-6478 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6478 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.4.0 For VMWare, failed to download Template when having 3 SSVM's in one zone When trying to download template, a dialog with download URI like following displayed https://one ssvm ip/userdata/06b2ae45-c681-4952-802b-2f64b5832720.ova When trying to click on the link above, following error message is displayed in the browser. 404 Not Found When replaced IP address of download URL with another ssvm ip, then we could download the template. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6502) IAMGroup.list and IAMPolicy.list in marvin base.py are not working.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-6502. -- Resolution: Fixed IAMGroup.list and IAMPolicy.list in marvin base.py are not working. --- Key: CLOUDSTACK-6502 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6502 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.4.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.4.0 IAMGroup.list and IAMPolicy.list in marvin base.py library have typo bugs, which blocks folks from writing IAM group and policy list related automation test. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-6501) IAM - DomainAdmin - When listVirtualMachines is used with listall=true and account and domainId , Vms owned by the account account is not listed.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen reassigned CLOUDSTACK-6501: Assignee: Min Chen IAM - DomainAdmin - When listVirtualMachines is used with listall=true and account and domainId , Vms owned by the account account is not listed. -- Key: CLOUDSTACK-6501 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6501 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: IAM Affects Versions: 4.4.0 Environment: Build from 4.4 Reporter: Sangeetha Hariharan Assignee: Min Chen Priority: Critical Fix For: 4.4.0 IAM - DomainAdmin - When listVirtualMachines is used with listall=true and account and domainId , Vms owned by the account is not listed. Steps to reproduce the problem: Set up: Pre Reqs: Admin - Creates object Domain Admin for d1 - D1 - Creates object - d1 Domain Admin for d1 - D1/D11 User account for d1 - D1/D111 - Creates object - d111a Domain Admin for d1 - D1/D12 Domain Admin for d2 - D2 - Creates object -d2 User Account in domain D1 - userD1-1 - Creates object -d1a User Account in domain D1 - userD1-2 - Creates object - d1b Domain Account in domain D1/D11 - D11 - Creates object - d11 User Account in domain D1/D11 - userD1-a - Creates object - d11a User Account in domain D1/D11 - userD1-a - Creates object - d11b User Account in domain D1/D12- userD1-b - Creates object - d12a User Account in domain D1/D12 - userD-a - Creates object - d12b As domain admin account D1 , try to list all the Vms for d11 (domain admin user) using account and domainId parameters. Expected Result: Vm owned by the account that is passed in account/domainId parameter. Actual Result: Empty set is returned. GET http://10.223.49.6/client/api?command=listVirtualMachinesdomainId=0e8d9d60-c39a-4304-b048-1e63500d0d30account=testD11listAll=trueisrecursive=trueapiKey=bW1FEJkIERji0cWRNQqvmWOgOINjMeBggyoPsMjN9_Qnvq-QtC6L4ORqmbdfQ-XtUYQdSoJIniZrHK3_oi9pcQsignature=5qLgaWzslWKSz%2FXbVSK0zdj%2B49I%3D \n\n current Time: Thu Apr 24 14:43:18 PDT 2014 ?xml version=1.0 encoding=UTF-8?listvirtualmachinesresponse cloud-stack-version=4.4.0-SNAPSHOT/listvirtualmachinesresponseConnection to 10.223.49.6 8080 port [tcp/webcache] succeeded! Response Time(in secs) : 0 current Time: Thu Apr 24 14:43:18 PDT 2014 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6501) IAM - DomainAdmin - When listVirtualMachines is used with listall=true and account and domainId , Vms owned by the account account is not listed.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-6501. -- Resolution: Fixed IAM - DomainAdmin - When listVirtualMachines is used with listall=true and account and domainId , Vms owned by the account account is not listed. -- Key: CLOUDSTACK-6501 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6501 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: IAM Affects Versions: 4.4.0 Environment: Build from 4.4 Reporter: Sangeetha Hariharan Assignee: Min Chen Priority: Critical Fix For: 4.4.0 IAM - DomainAdmin - When listVirtualMachines is used with listall=true and account and domainId , Vms owned by the account is not listed. Steps to reproduce the problem: Set up: Pre Reqs: Admin - Creates object Domain Admin for d1 - D1 - Creates object - d1 Domain Admin for d1 - D1/D11 User account for d1 - D1/D111 - Creates object - d111a Domain Admin for d1 - D1/D12 Domain Admin for d2 - D2 - Creates object -d2 User Account in domain D1 - userD1-1 - Creates object -d1a User Account in domain D1 - userD1-2 - Creates object - d1b Domain Account in domain D1/D11 - D11 - Creates object - d11 User Account in domain D1/D11 - userD1-a - Creates object - d11a User Account in domain D1/D11 - userD1-a - Creates object - d11b User Account in domain D1/D12- userD1-b - Creates object - d12a User Account in domain D1/D12 - userD-a - Creates object - d12b As domain admin account D1 , try to list all the Vms for d11 (domain admin user) using account and domainId parameters. Expected Result: Vm owned by the account that is passed in account/domainId parameter. Actual Result: Empty set is returned. GET http://10.223.49.6/client/api?command=listVirtualMachinesdomainId=0e8d9d60-c39a-4304-b048-1e63500d0d30account=testD11listAll=trueisrecursive=trueapiKey=bW1FEJkIERji0cWRNQqvmWOgOINjMeBggyoPsMjN9_Qnvq-QtC6L4ORqmbdfQ-XtUYQdSoJIniZrHK3_oi9pcQsignature=5qLgaWzslWKSz%2FXbVSK0zdj%2B49I%3D \n\n current Time: Thu Apr 24 14:43:18 PDT 2014 ?xml version=1.0 encoding=UTF-8?listvirtualmachinesresponse cloud-stack-version=4.4.0-SNAPSHOT/listvirtualmachinesresponseConnection to 10.223.49.6 8080 port [tcp/webcache] succeeded! Response Time(in secs) : 0 current Time: Thu Apr 24 14:43:18 PDT 2014 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6517) IAM - Admin is allowed to create PortFowarding rule for a regular user, when admin does not have UseEntry permission for IpAddress.
Sangeetha Hariharan created CLOUDSTACK-6517: --- Summary: IAM - Admin is allowed to create PortFowarding rule for a regular user, when admin does not have UseEntry permission for IpAddress. Key: CLOUDSTACK-6517 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6517 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: IAM Affects Versions: 4.4.0 Environment: Build from 4.4 Reporter: Sangeetha Hariharan Fix For: 4.4.0 IAM - Admin is allowed to create PortFowarding rule for a regular user, when admin does not have UseEntry permission for IpAddress. Steps to reproduce the problem: As regular user , on a network he owns , acquire an ip address. As admin , try to create a PF rule on this ip address without passing account and domainId. Creating PF rule succeeds. Since Admin has only ListEntry permission for IpAddress owned by other users , we expect this api call to fail. mysql select * from iam_policy_permission where resource_type = 'IpAddress' and policy_id=2; +--+---+---+---+--+-+--++---+-+-+ | id | policy_id | action| resource_type | scope_id | scope | access_type | permission | recursive | removed | created | +--+---+---+---+--+-+--++---+-+-+ | 1840 | 2 | listPublicIpAddresses | IpAddress | -1 | ALL | ListEntry| Allow | 0 | NULL| 2014-04-22 18:31:03 | | 1841 | 2 | listPublicIpAddresses | IpAddress | -1 | ACCOUNT | UseEntry | Allow | 0 | NULL| 2014-04-22 18:31:03 | Admin should be allowed to do this only , when he passes account and domainId of the regular user is passed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6513) IAM - Templates - When templates are listed with templatefilter=shared is used , we see public templates also being included in the list.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13981804#comment-13981804 ] ASF subversion and git services commented on CLOUDSTACK-6513: - Commit a4cb8d11462cb404eba067541639d46e509d717b in cloudstack's branch refs/heads/4.4-forward from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a4cb8d1 ] CLOUDSTACK-6513: IAM - Templates - When templates are listed with templatefilter=shared is used , we see public templates also being included in the list. This commit reverts listTemplates behavior to 4.3 old logic without using consistent interpretation of list parameters adopted in new IAM model. IAM - Templates - When templates are listed with templatefilter=shared is used , we see public templates also being included in the list. --- Key: CLOUDSTACK-6513 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6513 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: IAM Affects Versions: 4.4.0 Environment: Build from 4.4 Reporter: Sangeetha Hariharan Assignee: Min Chen Priority: Critical Fix For: 4.4.0 IAM - Templates - When templates are listed with templatefilter=shared is used , we see public templates also being included in the list. Steps to reproduce the problem: As user1 , Create a private template and a public template. Grant access to the private template for user2 using updateTemplatePermissions. As user2 , list templates with templatefilter=shared. This returns both public and the the shared template. GET http://10.223.49.6/client/api?command=listTemplatespagesize=100page=1listAll=truetemplatefilter=sharedapiKey=SrgUY-U-nUl4qsOyn409kCjA2jC7dR5ReIV9SjdnmzLOn3c0Fm-vZbDSpkldUjuqLAXt5ShodtXYOgRB5NCnJQsignature=WBO8ll9nyjiB29aVq%2FpUsEQrthM%3D \n\n ?xml version=1.0 encoding=UTF-8?listtemplatesresponse cloud-stack-version=4.4.0-SNAPSHOTcount6/counttemplateida2065bcc-7139-46b0-ac15-db7d3ff7dd75/idnamePublic_featured_d1a-TP7TPK/namedisplaytextpublic and feature Template/displaytextispublictrue/ispubliccreated2014-04-21T13:50:35-0400/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedtrue/isfeaturedcrossZonesfalse/crossZonesostypeide5ebce64-c019-11e3-907f-4adf980f9414/ostypeidostypenameCentOS 5.3 (64-bit)/ostypenameaccounttesttemplateD1A/accountzoneid75d61334-ff70-49c3-99ed-3af702cd51d7/zoneidzonenameBLR1/zonenamesize5242880/sizetemplatetypeUSER/templatetypehypervisorSimulator/hypervisordomainD1/domaindomainid691ab662-6793-42a0-96e6-3b31a2c4e52d/domainidisextractabletrue/isextractablesshkeyenabledfalse/sshkeyenabledisdynamicallyscalablefalse/isdynamicallyscalable/templatetemplateidce1635dc-1fcb-4f60-8d2f-d1129a3771ce/idnamePublic_not_featured_d2a-NPYFSN/namedisplaytextpublic and not feature Template/displaytextispublictrue/ispubliccreated2014-04-21T13:50:36-0400/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedfalse/isfeaturedcrossZonesfalse/crossZonesostypeide5ebce64-c019-11e3-907f-4adf980f9414/ostypeidostypenameCentOS 5.3 (64-bit)/ostypenameaccounttesttemplateD2/accountzoneid75d61334-ff70-49c3-99ed-3af702cd51d7/zoneidzonenameBLR1/zonenamesize5242880/sizetemplatetypeUSER/templatetypehypervisorSimulator/hypervisordomainD2/domaindomainid18222e53-7221-4d6f-9a76-8f59869f24b2/domainidisextractabletrue/isextractablesshkeyenabledfalse/sshkeyenabledisdynamicallyscalablefalse/isdynamicallyscalable/templatetemplateid223e0c09-e18e-4188-9d8e-7ff2e2305547/idnamePrivate_featured_d1-E9PQHO/namedisplaytextprivate and featured Template/displaytextispublicfalse/ispubliccreated2014-04-21T13:50:36-0400/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedtrue/isfeaturedcrossZonesfalse/crossZonesostypeide5ebce64-c019-11e3-907f-4adf980f9414/ostypeidostypenameCentOS 5.3 (64-bit)/ostypenameaccounttesttemplateD1A/accountzoneid75d61334-ff70-49c3-99ed-3af702cd51d7/zoneidzonenameBLR1/zonenamesize5242880/sizetemplatetypeUSER/templatetypehypervisorSimulator/hypervisordomainD1/domaindomainid691ab662-6793-42a0-96e6-3b31a2c4e52d/domainidisextractabletrue/isextractablesshkeyenabledfalse/sshkeyenabledisdynamicallyscalablefalse/isdynamicallyscalable/templatetemplateida7b69a5e-4cb3-45fa-b3e7-dab3a6b73e45/idnamePublic_not_featured_d1a-XOCR05/namedisplaytextpublic and not feature
[jira] [Resolved] (CLOUDSTACK-6440) [Automation] test_02_sys_template_ready test case on test_secondary_storage.py failed - listTemplates response is empty
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen resolved CLOUDSTACK-6440.
--
Resolution: Fixed
[Automation] test_02_sys_template_ready test case on
test_secondary_storage.py failed - listTemplates response is empty
-
Key: CLOUDSTACK-6440
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6440
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation, IAM
Affects Versions: 4.4.0
Reporter: Chandan Purushothama
Assignee: Min Chen
Priority: Blocker
Fix For: 4.4.0
System VM Template ID seems to have been made a required parameter while
querying for the System VM Templates inorder to list the Template.
listTemplatesResponse:
'NoneType' object is not iterable
begin captured logging
test_02_sys_template_ready
(integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
STARTED : TC: test_02_sys_template_ready :::
test_02_sys_template_ready
(integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
sending GET request: listZones {'name': u'test0'}
test_02_sys_template_ready
(integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
Computed Signature by Marvin: t23Z4s6lQrS2hRbKTWxJfI+9a5k=
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 10.223.240.161
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qname=test0command=listZonessignature=t23Z4s6lQrS2hRbKTWxJfI%2B9a5k%3Dresponse=json
HTTP/1.1 200 394
test_02_sys_template_ready
(integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
Request:
http://10.223.240.161:8080/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qname=test0command=listZonessignature=t23Z4s6lQrS2hRbKTWxJfI%2B9a5k%3Dresponse=json
Response: { listzonesresponse : { count:1 ,zone : [
{id:4fbc4494-e655-49b6-bda1-7ad8eb641732,name:test0,dns1:10.223.240.232,dns2:10.223.240.234,internaldns1:10.223.240.232,networktype:Basic,securitygroupsenabled:true,allocationstate:Enabled,zonetoken:f0aed2ee-a79d-3608-bae5-09972653a6cf,dhcpprovider:VirtualRouter,localstorageenabled:false,tags:[]}
] } }
test_02_sys_template_ready
(integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
sending GET request: listPods {'zoneid':
u'4fbc4494-e655-49b6-bda1-7ad8eb641732'}
test_02_sys_template_ready
(integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
Computed Signature by Marvin: Q5eN6r9ACb1qiPi7CI3wiB6wh0k=
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 10.223.240.161
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listPodssignature=Q5eN6r9ACb1qiPi7CI3wiB6wh0k%3Dzoneid=4fbc4494-e655-49b6-bda1-7ad8eb641732response=json
HTTP/1.1 200 314
test_02_sys_template_ready
(integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
Request:
http://10.223.240.161:8080/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qcommand=listPodssignature=Q5eN6r9ACb1qiPi7CI3wiB6wh0k%3Dzoneid=4fbc4494-e655-49b6-bda1-7ad8eb641732response=json
Response: { listpodsresponse : { count:1 ,pod : [
{id:d99714b2-7164-4d85-b5a6-c0caf12eb57a,name:test0pod0,zoneid:4fbc4494-e655-49b6-bda1-7ad8eb641732,zonename:test0,gateway:10.223.251.1,netmask:255.255.255.192,startip:10.223.251.4,endip:10.223.251.14,allocationstate:Enabled}
] } }
test_02_sys_template_ready
(integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
sending GET request: listZones {'name': u'test1'}
test_02_sys_template_ready
(integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
Computed Signature by Marvin: Tt/qzyUZeeDi5QbtHNV6Ve7DHao=
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 10.223.240.161
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?apiKey=MNQSBTYnkNvc4PCMgv7itBuPnuHpnUT_TEJRzzCOZXPL5bl9ihaz0P3TpkK3IW36icuUoFQkySLQkvQ9K6Dh0Qname=test1command=listZonessignature=Tt%2FqzyUZeeDi5QbtHNV6Ve7DHao%3Dresponse=json
HTTP/1.1 200 394
test_02_sys_template_ready
(integration.smoke.test_secondary_storage.TestSecStorageServices): DEBUG:
Request:
[jira] [Updated] (CLOUDSTACK-4475) [ZWPS] attaching an uploaded volume to a VM is always going to first primary storage added
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-4475: --- Priority: Major (was: Critical) [ZWPS] attaching an uploaded volume to a VM is always going to first primary storage added -- Key: CLOUDSTACK-4475 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4475 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Doc, Storage Controller Affects Versions: 4.2.1 Environment: vmware esxi 5.1 Reporter: Srikanteswararao Talluri Labels: ReleaseNote Fix For: 4.4.0 Steps to reproduce: == 1. Have an advanced zone deployment with two cluster one host and one cluster scoped primary storage each 2. add two more zone wide primary storages 3. create a deployment on zone scoped primary storage 4. upload a volume. 5. attach uploaded volume to VM created in step 3. Observation: = While attaching volume, volume is always copied to first available primary storage in the storage_pool table and as a result attaching a volume created on cluster scoped primary storage to a VM with its root volume on zone wide primary storage fails. mysql select * from storage_pool; ++--+--+---+--++++---++--+---++-+-+-+-+---+-++-+---+ | id | name | uuid | pool_type | port | data_center_id | pod_id | cluster_id | used_bytes| capacity_bytes | host_address | user_info | path | created | removed | update_time | status | storage_provider_name | scope | hypervisor | managed | capacity_iops | ++--+--+---+--++++---++--+---++-+-+-+-+---+-++-+---+ | 1 | primaryclus1 | 722e6181-8497-3d31-9933-a0a267ae376c | NetworkFilesystem | 2049 | 1 | 1 | 1 | 1678552014848 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/primary | 2013-08-23 12:11:12 | NULL | NULL| Maintenance | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 2 | pimaryclu2 | 9fd9b0fc-c9fd-39b8-8d66-06372c5ff6d2 | NetworkFilesystem | 2049 | 1 | 1 | 2 | 1676566495232 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/clus1primary | 2013-08-23 12:18:14 | NULL | NULL| Up | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 3 | clus1p2 | 22e0c3fe-a390-38fa-8ff7-e1d965a36309 | NetworkFilesystem | 2049 | 1 | 1 | 1 | 1660903886848 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/clus1p2 | 2013-08-23 14:30:32 | NULL | NULL| Up | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 4 | clus1p3 | f2d9fb6b-c433-3c03-acf8-8f73eac48fae | NetworkFilesystem | 2049 | 1 | 1 | 1 | 1660901400576 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/clus1p3 | 2013-08-23 14:31:05 | NULL | NULL| Up | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 5 | clus2p2 | 13bf579c-51f3-317b-893a-98ff6ca8f486 | NetworkFilesystem | 2049 | 1 | 1 | 2 | 1660900147200 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/clus2p2 | 2013-08-23 14:31:38 | NULL | NULL| Up | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 7 | clus2p3 | 294ae9ff-cb02-33a0-8f31-21fdd8ff34db | NetworkFilesystem | 2049 | 1 | 1 | 2 | 1660894195712 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/clus2p3 | 2013-08-23 14:33:03 | NULL | NULL| Up | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 8 | z1 |
[jira] [Updated] (CLOUDSTACK-4475) [ZWPS] attaching an uploaded volume to a VM is always going to first primary storage added
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-4475: --- Priority: Critical (was: Major) [ZWPS] attaching an uploaded volume to a VM is always going to first primary storage added -- Key: CLOUDSTACK-4475 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4475 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Doc, Storage Controller Affects Versions: 4.2.1 Environment: vmware esxi 5.1 Reporter: Srikanteswararao Talluri Priority: Critical Labels: ReleaseNote Fix For: 4.4.0 Steps to reproduce: == 1. Have an advanced zone deployment with two cluster one host and one cluster scoped primary storage each 2. add two more zone wide primary storages 3. create a deployment on zone scoped primary storage 4. upload a volume. 5. attach uploaded volume to VM created in step 3. Observation: = While attaching volume, volume is always copied to first available primary storage in the storage_pool table and as a result attaching a volume created on cluster scoped primary storage to a VM with its root volume on zone wide primary storage fails. mysql select * from storage_pool; ++--+--+---+--++++---++--+---++-+-+-+-+---+-++-+---+ | id | name | uuid | pool_type | port | data_center_id | pod_id | cluster_id | used_bytes| capacity_bytes | host_address | user_info | path | created | removed | update_time | status | storage_provider_name | scope | hypervisor | managed | capacity_iops | ++--+--+---+--++++---++--+---++-+-+-+-+---+-++-+---+ | 1 | primaryclus1 | 722e6181-8497-3d31-9933-a0a267ae376c | NetworkFilesystem | 2049 | 1 | 1 | 1 | 1678552014848 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/primary | 2013-08-23 12:11:12 | NULL | NULL| Maintenance | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 2 | pimaryclu2 | 9fd9b0fc-c9fd-39b8-8d66-06372c5ff6d2 | NetworkFilesystem | 2049 | 1 | 1 | 2 | 1676566495232 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/clus1primary | 2013-08-23 12:18:14 | NULL | NULL| Up | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 3 | clus1p2 | 22e0c3fe-a390-38fa-8ff7-e1d965a36309 | NetworkFilesystem | 2049 | 1 | 1 | 1 | 1660903886848 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/clus1p2 | 2013-08-23 14:30:32 | NULL | NULL| Up | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 4 | clus1p3 | f2d9fb6b-c433-3c03-acf8-8f73eac48fae | NetworkFilesystem | 2049 | 1 | 1 | 1 | 1660901400576 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/clus1p3 | 2013-08-23 14:31:05 | NULL | NULL| Up | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 5 | clus2p2 | 13bf579c-51f3-317b-893a-98ff6ca8f486 | NetworkFilesystem | 2049 | 1 | 1 | 2 | 1660900147200 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/clus2p2 | 2013-08-23 14:31:38 | NULL | NULL| Up | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 7 | clus2p3 | 294ae9ff-cb02-33a0-8f31-21fdd8ff34db | NetworkFilesystem | 2049 | 1 | 1 | 2 | 1660894195712 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/clus2p3 | 2013-08-23 14:33:03 | NULL | NULL| Up | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 8 | z1
[jira] [Updated] (CLOUDSTACK-6518) [Hyper-V] Efficient way of finding the empty nic in VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-6518: --- Priority: Critical (was: Major) [Hyper-V] Efficient way of finding the empty nic in VR --- Key: CLOUDSTACK-6518 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6518 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Priority: Critical Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6518) [Hyper-V] Efficient way of finding the empty nic in VR
Rajesh Battala created CLOUDSTACK-6518: -- Summary: [Hyper-V] Efficient way of finding the empty nic in VR Key: CLOUDSTACK-6518 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6518 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6519) [Hyper-V] while adding VM to Network it should throw error when it is in running state
Rajesh Battala created CLOUDSTACK-6519: -- Summary: [Hyper-V] while adding VM to Network it should throw error when it is in running state Key: CLOUDSTACK-6519 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6519 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Priority: Critical Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
