[jira] [Commented] (CLOUDSTACK-9651) Fix Docker image build of simulator, marvin and management-server.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15734643#comment-15734643 ] ASF subversion and git services commented on CLOUDSTACK-9651: - Commit f2798403b58c26ef26227a26485e9266e7ef84c5 in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f279840 ] Merge pull request #1815 from pdion891/dockerfile4.10.0 Fix docker image build for cloudstack-managementCLOUDSTACK-9651 Fix Docker images build for 4.10.0.0: - simulator - marvin - management_centos6 Squashed version of #1435. * pr/1815: CLOUDSTACK-9651; fix docker image build for cloudstack-management, simulator and marvin for 4.10.0.0 close #1435 Signed-off-by: Rohit Yadav > Fix Docker image build of simulator, marvin and management-server. > -- > > Key: CLOUDSTACK-9651 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9651 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.7.0, 4.8.0, 4.9.0 >Reporter: Pierre-Luc Dion >Assignee: Pierre-Luc Dion > Labels: docker > > Fixe automated build of docker image for cloudstack-simulator, > cloudstack-management and cloudstack-marvin. > Automate release changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9651) Fix Docker image build of simulator, marvin and management-server.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15734644#comment-15734644 ] ASF subversion and git services commented on CLOUDSTACK-9651: - Commit f2798403b58c26ef26227a26485e9266e7ef84c5 in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f279840 ] Merge pull request #1815 from pdion891/dockerfile4.10.0 Fix docker image build for cloudstack-managementCLOUDSTACK-9651 Fix Docker images build for 4.10.0.0: - simulator - marvin - management_centos6 Squashed version of #1435. * pr/1815: CLOUDSTACK-9651; fix docker image build for cloudstack-management, simulator and marvin for 4.10.0.0 close #1435 Signed-off-by: Rohit Yadav > Fix Docker image build of simulator, marvin and management-server. > -- > > Key: CLOUDSTACK-9651 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9651 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.7.0, 4.8.0, 4.9.0 >Reporter: Pierre-Luc Dion >Assignee: Pierre-Luc Dion > Labels: docker > > Fixe automated build of docker image for cloudstack-simulator, > cloudstack-management and cloudstack-marvin. > Automate release changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9651) Fix Docker image build of simulator, marvin and management-server.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15734642#comment-15734642 ] ASF subversion and git services commented on CLOUDSTACK-9651: - Commit f88a1082c256b7fe83d2ec3df070f5dd835b3f86 in cloudstack's branch refs/heads/master from [~pdion] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f88a108 ] CLOUDSTACK-9651; fix docker image build for cloudstack-management, simulator and marvin for 4.10.0.0 close #1435 > Fix Docker image build of simulator, marvin and management-server. > -- > > Key: CLOUDSTACK-9651 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9651 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.7.0, 4.8.0, 4.9.0 >Reporter: Pierre-Luc Dion >Assignee: Pierre-Luc Dion > Labels: docker > > Fixe automated build of docker image for cloudstack-simulator, > cloudstack-management and cloudstack-marvin. > Automate release changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9651) Fix Docker image build of simulator, marvin and management-server.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15734645#comment-15734645 ] ASF GitHub Bot commented on CLOUDSTACK-9651: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1815 > Fix Docker image build of simulator, marvin and management-server. > -- > > Key: CLOUDSTACK-9651 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9651 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.7.0, 4.8.0, 4.9.0 >Reporter: Pierre-Luc Dion >Assignee: Pierre-Luc Dion > Labels: docker > > Fixe automated build of docker image for cloudstack-simulator, > cloudstack-management and cloudstack-marvin. > Automate release changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9611) Dedicating a Guest VLAN range to Project does not work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15734651#comment-15734651 ] ASF GitHub Bot commented on CLOUDSTACK-9611: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1771 @blueorangutan package > Dedicating a Guest VLAN range to Project does not work > -- > > Key: CLOUDSTACK-9611 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9611 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > Trying to dedicate a guest VLAN range to an account fails. If we pass both > account and projectid parameters to the dedicateGuestVlanRange (which are not > mentioned as mutually exclusive in API description) the API layer throws > error saying both are mutually exclusive. > Steps to Reproduce: > > Create an account. Create a project in that account. > Go to admin account and change view to the above project. > Navigate to Infrastructure -> Zone -> Physical Network -> Guest -> Dedicate > Guest VLAN range. > Try to dedicate the guest VLAN range from the project view for the account > associated with the project. > It fails with Error saying accountName and projectId are mutually exclusive. > Expected: > > The VLAN range should get dedicated to the project account. > Notes: > = > If we do the dedication from default view then it works fine as no projectid > is associated over there. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9620) KVM Improvements for Managed Storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15734654#comment-15734654 ] ASF GitHub Bot commented on CLOUDSTACK-9620: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1748 @blueorangutan package > KVM Improvements for Managed Storage > > > Key: CLOUDSTACK-9620 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9620 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Management Server >Affects Versions: Future > Environment: KVM >Reporter: Mike Tutkowski > Fix For: Future > > > Allow zone-wide primary storage based on a custom plug-in to be added via the > GUI in a KVM-only environment. > Support for root disks on managed storage with KVM > Template caching with managed storage and KVM > Support for volume snapshots with managed storage on KVM > Added the ability to revert a volume to a snapshot on KVM > Updated some integration tests > Enforce that a SolidFire volume’s Min IOPS cannot exceed 15,000 and its Max > and Burst IOPS cannot exceed 100,000. > A SolidFire volume must be at least one GB. > The storage driver should not remove the row from the > cloud.template_spool_ref table. > Enable cluster-scoped managed storage > Only volumes from zone-wide managed storage can be storage motioned from a > host in one cluster to a host in another cluster (cannot do so at the time > being with volumes from cluster-scoped managed storage). > Updates for SAN-assisted snapshots -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9611) Dedicating a Guest VLAN range to Project does not work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15734653#comment-15734653 ] ASF GitHub Bot commented on CLOUDSTACK-9611: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1771 @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. > Dedicating a Guest VLAN range to Project does not work > -- > > Key: CLOUDSTACK-9611 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9611 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > Trying to dedicate a guest VLAN range to an account fails. If we pass both > account and projectid parameters to the dedicateGuestVlanRange (which are not > mentioned as mutually exclusive in API description) the API layer throws > error saying both are mutually exclusive. > Steps to Reproduce: > > Create an account. Create a project in that account. > Go to admin account and change view to the above project. > Navigate to Infrastructure -> Zone -> Physical Network -> Guest -> Dedicate > Guest VLAN range. > Try to dedicate the guest VLAN range from the project view for the account > associated with the project. > It fails with Error saying accountName and projectId are mutually exclusive. > Expected: > > The VLAN range should get dedicated to the project account. > Notes: > = > If we do the dedication from default view then it works fine as no projectid > is associated over there. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9620) KVM Improvements for Managed Storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15734658#comment-15734658 ] ASF GitHub Bot commented on CLOUDSTACK-9620: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1748 @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. > KVM Improvements for Managed Storage > > > Key: CLOUDSTACK-9620 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9620 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Management Server >Affects Versions: Future > Environment: KVM >Reporter: Mike Tutkowski > Fix For: Future > > > Allow zone-wide primary storage based on a custom plug-in to be added via the > GUI in a KVM-only environment. > Support for root disks on managed storage with KVM > Template caching with managed storage and KVM > Support for volume snapshots with managed storage on KVM > Added the ability to revert a volume to a snapshot on KVM > Updated some integration tests > Enforce that a SolidFire volume’s Min IOPS cannot exceed 15,000 and its Max > and Burst IOPS cannot exceed 100,000. > A SolidFire volume must be at least one GB. > The storage driver should not remove the row from the > cloud.template_spool_ref table. > Enable cluster-scoped managed storage > Only volumes from zone-wide managed storage can be storage motioned from a > host in one cluster to a host in another cluster (cannot do so at the time > being with volumes from cluster-scoped managed storage). > Updates for SAN-assisted snapshots -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9611) Dedicating a Guest VLAN range to Project does not work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15734734#comment-15734734 ] ASF GitHub Bot commented on CLOUDSTACK-9611: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1771 Packaging result: ✖centos6 ✔centos7 ✔debian. JID-375 > Dedicating a Guest VLAN range to Project does not work > -- > > Key: CLOUDSTACK-9611 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9611 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Kumar Maharana > > Trying to dedicate a guest VLAN range to an account fails. If we pass both > account and projectid parameters to the dedicateGuestVlanRange (which are not > mentioned as mutually exclusive in API description) the API layer throws > error saying both are mutually exclusive. > Steps to Reproduce: > > Create an account. Create a project in that account. > Go to admin account and change view to the above project. > Navigate to Infrastructure -> Zone -> Physical Network -> Guest -> Dedicate > Guest VLAN range. > Try to dedicate the guest VLAN range from the project view for the account > associated with the project. > It fails with Error saying accountName and projectId are mutually exclusive. > Expected: > > The VLAN range should get dedicated to the project account. > Notes: > = > If we do the dedication from default view then it works fine as no projectid > is associated over there. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9359) Return ip6address in Basic Networking
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15734735#comment-15734735 ] ASF GitHub Bot commented on CLOUDSTACK-9359: Github user wido commented on the issue: https://github.com/apache/cloudstack/pull/1700 @rhtyd Understood! I have one more PR pending after this which should make IPv6 usable in Basic Networking. 4.11 would be great to get this in. > Return ip6address in Basic Networking > - > > Key: CLOUDSTACK-9359 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9359 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server > Environment: CloudStack Basic Networking >Reporter: Wido den Hollander >Assignee: Wido den Hollander > Labels: api, basic-networking, ipv6 > Fix For: Future > > > In Basic Networking Instances will obtain their IPv6 address using SLAAC > (Stateless Autoconfiguration) as described in the Wiki: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/IPv6+in+Basic+Networking > When a ip6cidr is configured and is a /64 we can calculate the IPv6 address > an Instance will obtain. > There is no need to store a IPv6 address in the database with the /64 subnet > (ip6cidr) and the MAC address we can calculate the address using EUI-64: > "A 64-bit interface identifier is most commonly derived from its 48-bit MAC > address. A MAC address 00:0C:29:0C:47:D5 is turned into a 64-bit EUI-64 by > inserting FF:FE in the middle: 00:0C:29:FF:FE:0C:47:D5. When this EUI-64 is > used to form an IPv6 address it is modified:[1] the meaning of the > Universal/Local bit (the 7th most significant bit of the EUI-64, starting > from 1) is inverted, so that a 1 now means Universal. To create an IPv6 > address with the network prefix 2001:db8:1:2::/64 it yields the address > 2001:db8:1:2:020c:29ff:fe0c:47d5 (with the underlined U/L (=Universal/Local) > bit inverted to a 1, because the MAC address is universally unique)." > The API should return this address in the ip6address field for a NIC in Basic > Networking. > End-Users can use this, but it can also be used internally by Security > Grouping to program rules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9620) KVM Improvements for Managed Storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15734736#comment-15734736 ] ASF GitHub Bot commented on CLOUDSTACK-9620: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1748 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-376 > KVM Improvements for Managed Storage > > > Key: CLOUDSTACK-9620 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9620 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Management Server >Affects Versions: Future > Environment: KVM >Reporter: Mike Tutkowski > Fix For: Future > > > Allow zone-wide primary storage based on a custom plug-in to be added via the > GUI in a KVM-only environment. > Support for root disks on managed storage with KVM > Template caching with managed storage and KVM > Support for volume snapshots with managed storage on KVM > Added the ability to revert a volume to a snapshot on KVM > Updated some integration tests > Enforce that a SolidFire volume’s Min IOPS cannot exceed 15,000 and its Max > and Burst IOPS cannot exceed 100,000. > A SolidFire volume must be at least one GB. > The storage driver should not remove the row from the > cloud.template_spool_ref table. > Enable cluster-scoped managed storage > Only volumes from zone-wide managed storage can be storage motioned from a > host in one cluster to a host in another cluster (cannot do so at the time > being with volumes from cluster-scoped managed storage). > Updates for SAN-assisted snapshots -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9650) Allow starting VMs regardless of cpu/memory cluster.disablethreshold setting
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15734743#comment-15734743 ] ASF GitHub Bot commented on CLOUDSTACK-9650: Github user wido commented on the issue: https://github.com/apache/cloudstack/pull/1812 So to get this clear, you might OOM hypervisors due to this since you allocate more memory on them? Or is this just the cluster threshold and it still might not find a suitable hypervisor > Allow starting VMs regardless of cpu/memory cluster.disablethreshold setting > > > Key: CLOUDSTACK-9650 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9650 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 >Reporter: Koushik Das >Assignee: Koushik Das > Fix For: 4.10.1.0 > > > VM deployments are not allowed on clusters where resource (cpu/memory) > allocation has exceeded the cluster disabled thresholds. The same policy also > gets applied in case of start VM if last host where the VM was running > doesn't have enough capacity and a new host is picked up. In certain > scenarios this can be restrictive and despite having capacity, the VM cannot > be started. > This improvement is to provide administrator an option to disable/enable > cluster threshold enforcement during start of a stopped VM as long as > sufficient capacity is available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9657) Ipset command fails for VM's with long internal name
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15734763#comment-15734763 ] ASF GitHub Bot commented on CLOUDSTACK-9657: GitHub user jayapalu opened a pull request: https://github.com/apache/cloudstack/pull/1824 CLOUDSTACK-9657: Fixed security group ipset issues with long vm name ipset set name max length allowed is 31 char. If the vm name has longer name then the trimming of set has done in this fix. Also cleanup of rules are taken care. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jayapalu/cloudstack SGipset Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1824.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1824 commit 32357d0b7c62bbef983967e3b7b690f9d3d68426 Author: Jayapalu Date: 2016-12-08T10:35:21Z CLOUDSTACK-9657: Fixed security group ipset issues with long vm name > Ipset command fails for VM's with long internal name > > > Key: CLOUDSTACK-9657 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9657 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Jayapal Reddy >Assignee: Jayapal Reddy > Fix For: 4.9.1.0 > > > ipset rules configuration in security groups is failing for the VM with > longer name > ipset -N 12345677 nethash > ipset v6.11: Syntax error: setname '12345677' is > longer than 31 characters -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8908) After copying the template charging for that template is stopped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15734867#comment-15734867 ] ASF GitHub Bot commented on CLOUDSTACK-8908: Github user yvsubhash commented on the issue: https://github.com/apache/cloudstack/pull/896 @rhtyd Can you plz merge this? > After copying the template charging for that template is stopped > - > > Key: CLOUDSTACK-8908 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8908 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template, Usage >Affects Versions: 4.5.2 >Reporter: subhash yedugundla > > [Repro Steps] > Register a template in Zone 1 . > Copy the template from Zone 1 to Zone 2 . > Once copied, deleted the template from Zone 1. > Check the charging of the template and found that charging of the template > in Zone 2 stopped > Sample data related to the issue > mysql> select id,type,state,description,created from event where description > like "%4186%" and type like "%template%"; > +-+-+---+-+-+ > > | id | type | state | description | created | > +-+-+---+-+-+ > > | 1964466 | TEMPLATE.CREATE | Completed | Successfully completed creating > template. Id: 4186 name: PerfTestVM2 | 2015-06-15 09:48:57 | > | 2411011 | TEMPLATE.COPY | Scheduled | copying template: 4186 from zone: 3 > to zone: 1 | 2015-07-22 03:57:32 | > | 2411012 | TEMPLATE.COPY | Started | copying template. copying template: > 4186 from zone: 3 to zone: 1 | 2015-07-22 03:57:32 | > | 2411458 | TEMPLATE.COPY | Completed | Successfully completed copying > template. copying template: 4186 from zone: 3 to zone: 1 | 2015-07-22 > 04:47:08 | > | 2412521 | TEMPLATE.DELETE | Scheduled | Deleting template 4186 | 2015-07-22 > 06:46:18 | > | 2412522 | TEMPLATE.DELETE | Started | deleting template. Template Id: 4186 > | 2015-07-22 06:46:18 | > | 2412523 | TEMPLATE.DELETE | Completed | Successfully completed deleting > template. Template Id: 4186 | 2015-07-22 06:46:18 | > +-+-+---+-+-+ > > You can see that the template of zone3 is not removed. > mysql> select * from template_zone_ref where template_id=4186;; > +--+-+-+-+-+-+ > > | id | zone_id | template_id | created | last_updated | removed | > +--+-+-+-+-+-+ > > | 3974 | 3 | 4186 | 2015-06-15 09:48:57 | 2015-06-15 09:48:57 | NULL | > <=Not removed > | 4845 | 1 | 4186 | 2015-07-22 04:47:08 | 2015-07-22 04:47:08 | 2015-07-22 > 06:46:18 | > +--+-+-+-+-+-+ > > However, not only Zone1 but also the charging of the template of Zone3 > stopped. > +-+-+-+-+--+---++--+-+ > > | id | start_date | end_date | zone_id | description | usage_display | > raw_usage | usage_id | size | > +-+-+-+-+--+---++--+-+ > > | 5998486 | 2015-06-14 15:00:00 | 2015-06-15 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 4.808055 Hrs | 4.808055400848389 | > 4186 | 14995087360 | > =an abbreviation > 4186 | 14995087360 | > | 7834096 | 2015-07-19 15:00:00 | 2015-07-20 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7889426 | 2015-07-20 15:00:00 | 2015-07-21 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7945799 | 2015-07-21 15:00:00 | 2015-07-22 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 15.771667 Hrs | 15.771666526794434 > | 4186 | 14995087360 | > | 7945801 | 2015-07-21 15:00:00 | 2015-07-22 14:59:59 | 1 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 1.986111 Hrs | 1.9861112833023071 | > 4186 | 14995087360 | > +-+-
[jira] [Commented] (CLOUDSTACK-8856) Primary Storage Used(type tag with value 2) related tag is not showing in listCapacity api response
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15734885#comment-15734885 ] ASF GitHub Bot commented on CLOUDSTACK-8856: Github user bvbharatk commented on the issue: https://github.com/apache/cloudstack/pull/865 Rebased with 4.9 > Primary Storage Used(type tag with value 2) related tag is not showing in > listCapacity api response > --- > > Key: CLOUDSTACK-8856 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8856 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Bharat Kumar >Assignee: Bharat Kumar > > Actual behavior: > Primary Storage Used(type tag with value 2) related tag is showing in > listCapacity api response when 'sortby=Usage' parameter is removed in > listCapacity api. > Expected behavior: > Primary Storage Used(type tag with value 2) related tag should be shown in > listCapacity api response when 'sortby=Usage' parameter is included in > listCapacity api. > Steps to reproduce: > 1.Login cloudstack as admin and launch one vm successfully. > 2.Make sure that firebug tool is enable and navigate to Dashboard. > 3.Right click on 'listCapacity' api and select 'Copy Location'. > 4.Remove 'response=json' parameter from above copied url and paste the > modified url in new tab. > 5.Check for 'type tag with value 2' in 'listCapcity' api xml response. > listCapacity API Command: > http://10.81.29.87/client/api?command=listCapacity&sessionkey=Qp0XOEUVLrZHBZrQp7ame96IzXE%3D&fetchLatest=true&sortBy=usage&_=1417697306264 > Response: > > - > 9 > - > 5 > 25cb4986-c286-4937-a0ec-b290307eaa4f > XenRT-Zone-0 > 3 > 5 > 60 > > - > 4 > 25cb4986-c286-4937-a0ec-b290307eaa4f > XenRT-Zone-0 > 3 > 15 > 20 > > - > 7 > 25cb4986-c286-4937-a0ec-b290307eaa4f > XenRT-Zone-0 > 1 > 5 > 20 > > - > 6 > 25cb4986-c286-4937-a0ec-b290307eaa4f > XenRT-Zone-0 > 227751755776 > 4395909513216 > 5.18 > > - > 0 > 25cb4986-c286-4937-a0ec-b290307eaa4f > XenRT-Zone-0 > 2952790016 > 124470096896 > 2.37 > > - > 1 > 25cb4986-c286-4937-a0ec-b290307eaa4f > XenRT-Zone-0 > 2000 > 100800 > 1.98 > > - > 3 > 25cb4986-c286-4937-a0ec-b290307eaa4f > XenRT-Zone-0 > 29339156480 > 8791819026432 > 0.33 > > - > 9 > 25cb4986-c286-4937-a0ec-b290307eaa4f > XenRT-Zone-0 > 8388608 > 981911732224 > 0 > > - > 19 > 25cb4986-c286-4937-a0ec-b290307eaa4f > XenRT-Zone-0 > 0 > 0 > 0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9660) NPE while destroying volumes during 1000 VMs deploy and destroy tests
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15734919#comment-15734919 ] ASF GitHub Bot commented on CLOUDSTACK-9660: GitHub user koushik-das opened a pull request: https://github.com/apache/cloudstack/pull/1825 CLOUDSTACK-9660: NPE while destroying volumes during 1000 VMs deploy … …and destroy tests NPE is seen as VM destroy and storage cleanup threads try to remove the same root volume. Fix is to handle only non-root volumes in storage cleanup thread, root volumes will be handled as part of VM destroy. You can merge this pull request into a Git repository by running: $ git pull https://github.com/Accelerite/cloudstack CLOUDSTACK-9660 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1825.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1825 commit d6b41d9ac21a9740494bfcfd58ea51d712e52f4e Author: Koushik Das Date: 2016-12-09T10:19:39Z CLOUDSTACK-9660: NPE while destroying volumes during 1000 VMs deploy and destroy tests NPE is seen as VM destroy and storage cleanup threads try to remove the same root volume. Fix is to handle only non-root volumes in storage cleanup thread, root volumes will be handled as part of VM destroy. > NPE while destroying volumes during 1000 VMs deploy and destroy tests > - > > Key: CLOUDSTACK-9660 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9660 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 >Reporter: Koushik Das >Assignee: Koushik Das > Fix For: 4.10.0.0 > > > Steps: > 1. Install and configure a zone (advanced or basic). > 2. Set config storage.cleanup.enabled = true and storage.cleanup.interval = > 10 seconds > 3. Deploy 1000 VMs and then destroy over multiple iterations. > NPE seen in MS logs while deleting volume: > 2015-06-18 16:27:47,797 DEBUG [c.c.v.VirtualMachineManagerImpl] > (UserVm-Scavenger-1:ctx-5ecc886e) (logid:132e3ff8) Cleaning up hypervisor > data structures (ex. SRs in XenServer) for managed storage > 2015-06-18 16:27:47,799 DEBUG [o.a.c.e.o.VolumeOrchestrator] > (UserVm-Scavenger-1:ctx-5ecc886e) (logid:132e3ff8) Cleaning storage for vm: > 2894 > 2015-06-18 16:27:47,823 INFO [o.a.c.s.v.VolumeServiceImpl] > (UserVm-Scavenger-1:ctx-5ecc886e) (logid:132e3ff8) Expunge volume with no > data store specified > 2015-06-18 16:27:47,828 DEBUG [c.c.s.StorageManagerImpl] > (StorageManager-Scavenger-1:ctx-5e7b4eda) (logid:bb642325) Storage pool > garbage collector found 0 templates to clean up in storage pool: > XenRT-Zone-0-Pod-0-Cluster-0-Primary-Store-0 > 2015-06-18 16:27:47,828 INFO [o.a.c.s.v.VolumeServiceImpl] > (UserVm-Scavenger-1:ctx-5ecc886e) (logid:132e3ff8) Volume 2894 is not > referred anywhere, remove it from volumes table > 2015-06-18 16:27:47,829 DEBUG [c.c.s.StorageManagerImpl] > (StorageManager-Scavenger-1:ctx-5e7b4eda) (logid:bb642325) Storage pool > garbage collector found 0 templates to clean up in storage pool: > XenRT-Zone-0-Pod-0-Cluster-1-Primary-Store-0 > 2015-06-18 16:27:47,832 DEBUG [c.c.s.StorageManagerImpl] > (StorageManager-Scavenger-1:ctx-5e7b4eda) (logid:bb642325) Secondary storage > garbage collector found 0 templates to cleanup on template_store_ref for > store: nfs://10.81.56.7/xenrtnfs/1092931-dycPsK > 2015-06-18 16:27:47,833 DEBUG [c.c.s.StorageManagerImpl] > (StorageManager-Scavenger-1:ctx-5e7b4eda) (logid:bb642325) Secondary storage > garbage collector found 0 snapshots to cleanup on snapshot_store_ref for > store: nfs://10.81.56.7/xenrtnfs/1092931-dycPsK > 2015-06-18 16:27:47,834 DEBUG [c.c.s.StorageManagerImpl] > (StorageManager-Scavenger-1:ctx-5e7b4eda) (logid:bb642325) Secondary storage > garbage collector found 0 volumes to cleanup on volume_store_ref for store: > nfs://10.81.56.7/xenrtnfs/1092931-dycPsK > 2015-06-18 16:27:47,842 DEBUG [c.c.v.VirtualMachineManagerImpl] > (UserVm-Scavenger-1:ctx-5ecc886e) (logid:132e3ff8) Expunged > VM[User|i-10-2894-VM] > 2015-06-18 16:27:47,844 WARN [c.c.s.StorageManagerImpl] > (StorageManager-Scavenger-1:ctx-5e7b4eda) (logid:bb642325) Unable to destroy > volume 0b22f54b-3242-49ef-b16d-1c7801d5c2bd > java.lang.NullPointerException > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.expungeVolumeAsync(VolumeServiceImpl.java:276) > at > com.cloud.storage.StorageManagerImpl.cleanupStorage(StorageManagerImpl.java:1121) > at > com.cloud.storage.StorageManagerImp
[jira] [Commented] (CLOUDSTACK-9650) Allow starting VMs regardless of cpu/memory cluster.disablethreshold setting
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15734927#comment-15734927 ] ASF GitHub Bot commented on CLOUDSTACK-9650: Github user koushik-das commented on the issue: https://github.com/apache/cloudstack/pull/1812 OOM on HV won't happen, only cluster threshold check is skipped in case of starting a stopped VM > Allow starting VMs regardless of cpu/memory cluster.disablethreshold setting > > > Key: CLOUDSTACK-9650 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9650 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 >Reporter: Koushik Das >Assignee: Koushik Das > Fix For: 4.10.1.0 > > > VM deployments are not allowed on clusters where resource (cpu/memory) > allocation has exceeded the cluster disabled thresholds. The same policy also > gets applied in case of start VM if last host where the VM was running > doesn't have enough capacity and a new host is picked up. In certain > scenarios this can be restrictive and despite having capacity, the VM cannot > be started. > This improvement is to provide administrator an option to disable/enable > cluster threshold enforcement during start of a stopped VM as long as > sufficient capacity is available. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8908) After copying the template charging for that template is stopped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15735012#comment-15735012 ] ASF GitHub Bot commented on CLOUDSTACK-8908: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/896 @blueorangutan test > After copying the template charging for that template is stopped > - > > Key: CLOUDSTACK-8908 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8908 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template, Usage >Affects Versions: 4.5.2 >Reporter: subhash yedugundla > > [Repro Steps] > Register a template in Zone 1 . > Copy the template from Zone 1 to Zone 2 . > Once copied, deleted the template from Zone 1. > Check the charging of the template and found that charging of the template > in Zone 2 stopped > Sample data related to the issue > mysql> select id,type,state,description,created from event where description > like "%4186%" and type like "%template%"; > +-+-+---+-+-+ > > | id | type | state | description | created | > +-+-+---+-+-+ > > | 1964466 | TEMPLATE.CREATE | Completed | Successfully completed creating > template. Id: 4186 name: PerfTestVM2 | 2015-06-15 09:48:57 | > | 2411011 | TEMPLATE.COPY | Scheduled | copying template: 4186 from zone: 3 > to zone: 1 | 2015-07-22 03:57:32 | > | 2411012 | TEMPLATE.COPY | Started | copying template. copying template: > 4186 from zone: 3 to zone: 1 | 2015-07-22 03:57:32 | > | 2411458 | TEMPLATE.COPY | Completed | Successfully completed copying > template. copying template: 4186 from zone: 3 to zone: 1 | 2015-07-22 > 04:47:08 | > | 2412521 | TEMPLATE.DELETE | Scheduled | Deleting template 4186 | 2015-07-22 > 06:46:18 | > | 2412522 | TEMPLATE.DELETE | Started | deleting template. Template Id: 4186 > | 2015-07-22 06:46:18 | > | 2412523 | TEMPLATE.DELETE | Completed | Successfully completed deleting > template. Template Id: 4186 | 2015-07-22 06:46:18 | > +-+-+---+-+-+ > > You can see that the template of zone3 is not removed. > mysql> select * from template_zone_ref where template_id=4186;; > +--+-+-+-+-+-+ > > | id | zone_id | template_id | created | last_updated | removed | > +--+-+-+-+-+-+ > > | 3974 | 3 | 4186 | 2015-06-15 09:48:57 | 2015-06-15 09:48:57 | NULL | > <=Not removed > | 4845 | 1 | 4186 | 2015-07-22 04:47:08 | 2015-07-22 04:47:08 | 2015-07-22 > 06:46:18 | > +--+-+-+-+-+-+ > > However, not only Zone1 but also the charging of the template of Zone3 > stopped. > +-+-+-+-+--+---++--+-+ > > | id | start_date | end_date | zone_id | description | usage_display | > raw_usage | usage_id | size | > +-+-+-+-+--+---++--+-+ > > | 5998486 | 2015-06-14 15:00:00 | 2015-06-15 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 4.808055 Hrs | 4.808055400848389 | > 4186 | 14995087360 | > =an abbreviation > 4186 | 14995087360 | > | 7834096 | 2015-07-19 15:00:00 | 2015-07-20 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7889426 | 2015-07-20 15:00:00 | 2015-07-21 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7945799 | 2015-07-21 15:00:00 | 2015-07-22 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 15.771667 Hrs | 15.771666526794434 > | 4186 | 14995087360 | > | 7945801 | 2015-07-21 15:00:00 | 2015-07-22 14:59:59 | 1 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 1.986111 Hrs | 1.9861112833023071 | > 4186 | 14995087360 | > +-+
[jira] [Commented] (CLOUDSTACK-8908) After copying the template charging for that template is stopped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15735014#comment-15735014 ] ASF GitHub Bot commented on CLOUDSTACK-8908: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/896 @rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests > After copying the template charging for that template is stopped > - > > Key: CLOUDSTACK-8908 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8908 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template, Usage >Affects Versions: 4.5.2 >Reporter: subhash yedugundla > > [Repro Steps] > Register a template in Zone 1 . > Copy the template from Zone 1 to Zone 2 . > Once copied, deleted the template from Zone 1. > Check the charging of the template and found that charging of the template > in Zone 2 stopped > Sample data related to the issue > mysql> select id,type,state,description,created from event where description > like "%4186%" and type like "%template%"; > +-+-+---+-+-+ > > | id | type | state | description | created | > +-+-+---+-+-+ > > | 1964466 | TEMPLATE.CREATE | Completed | Successfully completed creating > template. Id: 4186 name: PerfTestVM2 | 2015-06-15 09:48:57 | > | 2411011 | TEMPLATE.COPY | Scheduled | copying template: 4186 from zone: 3 > to zone: 1 | 2015-07-22 03:57:32 | > | 2411012 | TEMPLATE.COPY | Started | copying template. copying template: > 4186 from zone: 3 to zone: 1 | 2015-07-22 03:57:32 | > | 2411458 | TEMPLATE.COPY | Completed | Successfully completed copying > template. copying template: 4186 from zone: 3 to zone: 1 | 2015-07-22 > 04:47:08 | > | 2412521 | TEMPLATE.DELETE | Scheduled | Deleting template 4186 | 2015-07-22 > 06:46:18 | > | 2412522 | TEMPLATE.DELETE | Started | deleting template. Template Id: 4186 > | 2015-07-22 06:46:18 | > | 2412523 | TEMPLATE.DELETE | Completed | Successfully completed deleting > template. Template Id: 4186 | 2015-07-22 06:46:18 | > +-+-+---+-+-+ > > You can see that the template of zone3 is not removed. > mysql> select * from template_zone_ref where template_id=4186;; > +--+-+-+-+-+-+ > > | id | zone_id | template_id | created | last_updated | removed | > +--+-+-+-+-+-+ > > | 3974 | 3 | 4186 | 2015-06-15 09:48:57 | 2015-06-15 09:48:57 | NULL | > <=Not removed > | 4845 | 1 | 4186 | 2015-07-22 04:47:08 | 2015-07-22 04:47:08 | 2015-07-22 > 06:46:18 | > +--+-+-+-+-+-+ > > However, not only Zone1 but also the charging of the template of Zone3 > stopped. > +-+-+-+-+--+---++--+-+ > > | id | start_date | end_date | zone_id | description | usage_display | > raw_usage | usage_id | size | > +-+-+-+-+--+---++--+-+ > > | 5998486 | 2015-06-14 15:00:00 | 2015-06-15 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 4.808055 Hrs | 4.808055400848389 | > 4186 | 14995087360 | > =an abbreviation > 4186 | 14995087360 | > | 7834096 | 2015-07-19 15:00:00 | 2015-07-20 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7889426 | 2015-07-20 15:00:00 | 2015-07-21 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7945799 | 2015-07-21 15:00:00 | 2015-07-22 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 15.771667 Hrs | 15.771666526794434 > | 4186 | 14995087360 | > | 7945801 | 2015-07-21 15:00:00 | 2015-07-22 14:59:59 | 1 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 1.9861
[jira] [Commented] (CLOUDSTACK-9630) Cannot use listNics API as advertised
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15735077#comment-15735077 ] ASF GitHub Bot commented on CLOUDSTACK-9630: Github user sudhansu7 commented on the issue: https://github.com/apache/cloudstack/pull/1797 @jburwell I have modified the base branch to 4.9 . Also added a marvin test to check nic details. > Cannot use listNics API as advertised > - > > Key: CLOUDSTACK-9630 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9630 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Sudhansu Sahu > > listNics API for a VM, "type" was not returned within API response. > EXPECTED BEHAVIOR > == > The listNics API response return type of NIC (type), as specified in > https://cloudstack.apache.org/api/apidocs-4.8/user/listNics.html > > ACTUAL BEHAVIOR > == > The listNics API response does not return type of NIC. > (local) 🐵 > list nics virtualmachineid=a69edaf5-8f21-41ff-8c05-263dc4bd5354 > count = 1 > nic: > id = 211e0d46-6b94-4425-99f7-e8e9efea2472 > deviceid = 0 > gateway = 10.1.1.1 > ipaddress = 10.1.1.45 > isdefault = True > macaddress = 02:00:06:f6:00:01 > netmask = 255.255.255.0 > networkid = c08fddf1-fd77-4810-a062-ea9d03c5c7e6 > virtualmachineid = a69edaf5-8f21-41ff-8c05-263dc4bd5354 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9617) Enabling Remote access Vpn Fails when there is a portforwarding rule of the reserved ports ( 1701 , 500 , 4500) under TCP protocol.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15735149#comment-15735149 ] ASF GitHub Bot commented on CLOUDSTACK-9617: Github user jayapalu commented on the issue: https://github.com/apache/cloudstack/pull/1782 @ustcweizhou I am updating code for the LB rules as well > Enabling Remote access Vpn Fails when there is a portforwarding rule of the > reserved ports ( 1701 , 500 , 4500) under TCP protocol. > --- > > Key: CLOUDSTACK-9617 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9617 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Reporter: Jayapal Reddy >Assignee: Jayapal Reddy > Fix For: 4.9.2.0 > > > Navigate to Network -> Configuration -> Portforwarding > Create a new rule 1701 under both private and public ports for TCP Protocol > and assign a VM. > Now Enable Remote access VPN on the Network . > observation : > Enabling VPN acess is failing with the following error "The range > specified, 1701-1701, conflicts with rule 53 which has 1701-1701 " > Expected Result : > Enabling VPN should be sucessful , as the port forwarding rule added is TCP > protocol , and the firewall rules populated when VPN is enabled is UDP > protocol. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9661) Allow Carrier Grade NAT IP ranges (RFC 6598) to be used within a VPC
Simon Weller created CLOUDSTACK-9661: Summary: Allow Carrier Grade NAT IP ranges (RFC 6598) to be used within a VPC Key: CLOUDSTACK-9661 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9661 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.10.0.0 Reporter: Simon Weller Assignee: Simon Weller Priority: Minor Fix For: Future In a carrier environment, IP space is very precious. RFC 6598 specifies a IANA-Reserved IPv4 Prefix for Shared Address Space that is used in carrier networks for handling Carrier Grade NAT (CGN). Since this range is not publicly routable, it can be used within a carriers network in a similar way to RFC 1918 space. This PR adds support for RFC 6598 space. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9661) Allow Carrier Grade NAT IP ranges (RFC 6598) to be used within a VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Weller updated CLOUDSTACK-9661: - Affects Version/s: 4.8.0 4.9.0 Fix Version/s: (was: Future) > Allow Carrier Grade NAT IP ranges (RFC 6598) to be used within a VPC > > > Key: CLOUDSTACK-9661 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9661 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.8.0, 4.9.0, 4.10.0.0 >Reporter: Simon Weller >Assignee: Simon Weller >Priority: Minor > > In a carrier environment, IP space is very precious. RFC 6598 specifies a > IANA-Reserved IPv4 Prefix for Shared Address Space that is used in carrier > networks for handling Carrier Grade NAT (CGN). Since this range is not > publicly routable, it can be used within a carriers network in a similar way > to RFC 1918 space. > This PR adds support for RFC 6598 space. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9661) Allow Carrier Grade NAT IP ranges (RFC 6598) to be used within a VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15735360#comment-15735360 ] ASF GitHub Bot commented on CLOUDSTACK-9661: Github user kiwiflyer commented on the issue: https://github.com/apache/cloudstack/pull/1606 I've added issue Jira CLOUDSTACK-9661 to track this. https://issues.apache.org/jira/browse/CLOUDSTACK-9661 @leprechau @rhtyd > Allow Carrier Grade NAT IP ranges (RFC 6598) to be used within a VPC > > > Key: CLOUDSTACK-9661 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9661 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.8.0, 4.9.0, 4.10.0.0 >Reporter: Simon Weller >Assignee: Simon Weller >Priority: Minor > > In a carrier environment, IP space is very precious. RFC 6598 specifies a > IANA-Reserved IPv4 Prefix for Shared Address Space that is used in carrier > networks for handling Carrier Grade NAT (CGN). Since this range is not > publicly routable, it can be used within a carriers network in a similar way > to RFC 1918 space. > This PR adds support for RFC 6598 space. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9397) Add Watchdog timer to KVM Instances
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15735609#comment-15735609 ] ASF GitHub Bot commented on CLOUDSTACK-9397: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1707 Trillian test result (tid-638) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 27687 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1707-t638-kvm-centos7.zip Test completed. 45 look ok, 4 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | `Failure` | 407.80 | test_vpc_redundant.py test_04_rvpc_privategw_static_routes | `Failure` | 379.10 | test_privategw_acl.py ContextSuite context=TestTemplates>:setup | `Error` | 354.09 | test_templates.py ContextSuite context=TestListIdsParams>:setup | `Error` | 0.00 | test_list_ids_parameter.py test_01_vpc_site2site_vpn | Success | 169.33 | test_vpc_vpn.py test_01_vpc_remote_access_vpn | Success | 70.80 | test_vpc_vpn.py test_01_redundant_vpc_site2site_vpn | Success | 304.86 | test_vpc_vpn.py test_02_VPC_default_routes | Success | 366.80 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 567.31 | test_vpc_router_nics.py test_05_rvpc_multi_tiers | Success | 538.71 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | Success | 1457.23 | test_vpc_redundant.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Success | 607.93 | test_vpc_redundant.py test_02_redundant_VPC_default_routes | Success | 784.38 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 15.79 | test_volumes.py test_08_resize_volume | Success | 15.25 | test_volumes.py test_07_resize_fail | Success | 20.43 | test_volumes.py test_06_download_detached_volume | Success | 15.24 | test_volumes.py test_05_detach_volume | Success | 100.24 | test_volumes.py test_04_delete_attached_volume | Success | 10.15 | test_volumes.py test_03_download_attached_volume | Success | 15.24 | test_volumes.py test_02_attach_volume | Success | 73.68 | test_volumes.py test_01_create_volume | Success | 724.49 | test_volumes.py test_deploy_vm_multiple | Success | 271.94 | test_vm_life_cycle.py test_deploy_vm | Success | 0.02 | test_vm_life_cycle.py test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py test_10_attachAndDetach_iso | Success | 26.55 | test_vm_life_cycle.py test_09_expunge_vm | Success | 125.17 | test_vm_life_cycle.py test_08_migrate_vm | Success | 40.64 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.09 | test_vm_life_cycle.py test_06_destroy_vm | Success | 130.60 | test_vm_life_cycle.py test_03_reboot_vm | Success | 130.67 | test_vm_life_cycle.py test_02_start_vm | Success | 10.12 | test_vm_life_cycle.py test_01_stop_vm | Success | 45.26 | test_vm_life_cycle.py test_CreateTemplateWithDuplicateName | Success | 126.44 | test_templates.py test_01_create_template | Success | 95.59 | test_templates.py test_10_destroy_cpvm | Success | 171.51 | test_ssvm.py test_09_destroy_ssvm | Success | 228.73 | test_ssvm.py test_08_reboot_cpvm | Success | 136.60 | test_ssvm.py test_07_reboot_ssvm | Success | 139.18 | test_ssvm.py test_06_stop_cpvm | Success | 166.72 | test_ssvm.py test_05_stop_ssvm | Success | 140.53 | test_ssvm.py test_04_cpvm_internals | Success | 1.17 | test_ssvm.py test_03_ssvm_internals | Success | 3.81 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.08 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.09 | test_ssvm.py test_01_snapshot_root_disk | Success | 11.01 | test_snapshots.py test_04_change_offering_small | Success | 244.40 | test_service_offerings.py test_03_delete_service_offering | Success | 0.03 | test_service_offerings.py test_02_edit_service_offering | Success | 0.05 | test_service_offerings.py test_01_create_service_offering | Success | 0.07 | test_service_offerings.py test_02_sys_template_ready | Success | 0.08 | test_secondary_storage.py test_01_sys_vm_start | Success | 0.12 | test_secondary_storage.py test_09_reboot_router | Success | 45.31 | test_routers.py test_08_start_router | Success | 30.22 | test_routers.py test_07_stop_router | Success | 15.14 | test_routers.py test_06_router_advanced | Success | 0.04 | test_routers.py test_05_router_basic | Success | 0.03 | test_routers.py test_04_restart_network_wo_cleanup | Success | 5.64 | test_routers.py test_03_restart_network_cleanup | Success | 65.44 | test_routers.py test_02_router_internal_adv | Success | 1.01 | test_routers.py test_01_route
[jira] [Commented] (CLOUDSTACK-9626) Instance fails to start after unsuccesful compute offering upgrade.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15735623#comment-15735623 ] ASF GitHub Bot commented on CLOUDSTACK-9626: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1796 Trillian test result (tid-641) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 27710 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1796-t641-kvm-centos7.zip Test completed. 46 look ok, 2 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_04_rvpc_privategw_static_routes | `Failure` | 391.18 | test_privategw_acl.py ContextSuite context=TestListIdsParams>:setup | `Error` | 0.00 | test_list_ids_parameter.py test_01_vpc_site2site_vpn | Success | 165.03 | test_vpc_vpn.py test_01_vpc_remote_access_vpn | Success | 66.10 | test_vpc_vpn.py test_01_redundant_vpc_site2site_vpn | Success | 235.59 | test_vpc_vpn.py test_02_VPC_default_routes | Success | 287.73 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 630.07 | test_vpc_router_nics.py test_05_rvpc_multi_tiers | Success | 526.95 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | Success | 1461.20 | test_vpc_redundant.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Success | 557.79 | test_vpc_redundant.py test_02_redundant_VPC_default_routes | Success | 745.44 | test_vpc_redundant.py test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1326.60 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 15.44 | test_volumes.py test_08_resize_volume | Success | 15.40 | test_volumes.py test_07_resize_fail | Success | 20.57 | test_volumes.py test_06_download_detached_volume | Success | 15.30 | test_volumes.py test_05_detach_volume | Success | 100.27 | test_volumes.py test_04_delete_attached_volume | Success | 10.20 | test_volumes.py test_03_download_attached_volume | Success | 15.29 | test_volumes.py test_02_attach_volume | Success | 43.77 | test_volumes.py test_01_create_volume | Success | 682.53 | test_volumes.py test_deploy_vm_multiple | Success | 262.99 | test_vm_life_cycle.py test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py test_advZoneVirtualRouter | Success | 0.03 | test_vm_life_cycle.py test_10_attachAndDetach_iso | Success | 26.54 | test_vm_life_cycle.py test_09_expunge_vm | Success | 125.25 | test_vm_life_cycle.py test_08_migrate_vm | Success | 35.90 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.13 | test_vm_life_cycle.py test_06_destroy_vm | Success | 125.83 | test_vm_life_cycle.py test_03_reboot_vm | Success | 125.84 | test_vm_life_cycle.py test_02_start_vm | Success | 5.14 | test_vm_life_cycle.py test_01_stop_vm | Success | 35.30 | test_vm_life_cycle.py test_CreateTemplateWithDuplicateName | Success | 181.31 | test_templates.py test_08_list_system_templates | Success | 0.03 | test_templates.py test_07_list_public_templates | Success | 0.04 | test_templates.py test_05_template_permissions | Success | 0.06 | test_templates.py test_04_extract_template | Success | 5.38 | test_templates.py test_03_delete_template | Success | 5.25 | test_templates.py test_02_edit_template | Success | 90.13 | test_templates.py test_01_create_template | Success | 151.06 | test_templates.py test_10_destroy_cpvm | Success | 161.57 | test_ssvm.py test_09_destroy_ssvm | Success | 164.44 | test_ssvm.py test_08_reboot_cpvm | Success | 132.01 | test_ssvm.py test_07_reboot_ssvm | Success | 133.52 | test_ssvm.py test_06_stop_cpvm | Success | 131.93 | test_ssvm.py test_05_stop_ssvm | Success | 133.84 | test_ssvm.py test_04_cpvm_internals | Success | 1.18 | test_ssvm.py test_03_ssvm_internals | Success | 3.35 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.14 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.13 | test_ssvm.py test_01_snapshot_root_disk | Success | 11.26 | test_snapshots.py test_04_change_offering_small | Success | 242.78 | test_service_offerings.py test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py test_02_edit_service_offering | Success | 0.06 | test_service_offerings.py test_01_create_service_offering | Success | 0.11 | test_service_offerings.py test_02_sys_template_ready | Success | 0.13 | test_secondary_storage.py test_01_sys_vm_start | Success | 0.19 | test_secondary_storage.py test_09_reboot_router | Success | 45.37 | test_routers.py test_08_start_router | Success | 25.27 | test_routers.py test_07_stop_router | Success | 10.19 | test_routers.py test_06_router_advanced | Suc
[jira] [Commented] (CLOUDSTACK-9175) [VMware DRS] Adding new host to DRS cluster does not participate in load balancing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15735835#comment-15735835 ] ASF GitHub Bot commented on CLOUDSTACK-9175: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1257 Trillian test result (tid-637) Environment: vmware-55u3 (x2), Advanced Networking with Mgmt server 7 Total time taken: 35525 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1257-t637-vmware-55u3.zip Test completed. 42 look ok, 6 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_04_rvpc_privategw_static_routes | `Failure` | 186.66 | test_privategw_acl.py test_04_rvpc_internallb_haproxy_stats_on_all_interfaces | `Failure` | 131.04 | test_internal_lb.py test_01_vpc_site2site_vpn | `Error` | 480.96 | test_vpc_vpn.py test_01_redundant_vpc_site2site_vpn | `Error` | 777.23 | test_vpc_vpn.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | `Error` | 236.67 | test_vpc_redundant.py test_reboot_router | `Error` | 573.34 | test_network.py ContextSuite context=TestListIdsParams>:setup | `Error` | 0.00 | test_list_ids_parameter.py test_01_vpc_remote_access_vpn | Success | 156.38 | test_vpc_vpn.py test_02_VPC_default_routes | Success | 380.10 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 719.85 | test_vpc_router_nics.py test_05_rvpc_multi_tiers | Success | 696.58 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | Success | 1613.09 | test_vpc_redundant.py test_02_redundant_VPC_default_routes | Success | 673.94 | test_vpc_redundant.py test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1456.76 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 30.73 | test_volumes.py test_06_download_detached_volume | Success | 60.60 | test_volumes.py test_05_detach_volume | Success | 100.22 | test_volumes.py test_04_delete_attached_volume | Success | 15.16 | test_volumes.py test_03_download_attached_volume | Success | 25.81 | test_volumes.py test_02_attach_volume | Success | 58.74 | test_volumes.py test_01_create_volume | Success | 516.54 | test_volumes.py test_03_delete_vm_snapshots | Success | 280.21 | test_vm_snapshots.py test_02_revert_vm_snapshots | Success | 232.37 | test_vm_snapshots.py test_01_test_vm_volume_snapshot | Success | 271.82 | test_vm_snapshots.py test_01_create_vm_snapshots | Success | 161.64 | test_vm_snapshots.py test_deploy_vm_multiple | Success | 252.05 | test_vm_life_cycle.py test_deploy_vm | Success | 0.02 | test_vm_life_cycle.py test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py test_10_attachAndDetach_iso | Success | 26.66 | test_vm_life_cycle.py test_09_expunge_vm | Success | 125.13 | test_vm_life_cycle.py test_08_migrate_vm | Success | 126.15 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.10 | test_vm_life_cycle.py test_06_destroy_vm | Success | 10.12 | test_vm_life_cycle.py test_03_reboot_vm | Success | 5.10 | test_vm_life_cycle.py test_02_start_vm | Success | 20.18 | test_vm_life_cycle.py test_01_stop_vm | Success | 5.09 | test_vm_life_cycle.py test_CreateTemplateWithDuplicateName | Success | 316.90 | test_templates.py test_08_list_system_templates | Success | 0.04 | test_templates.py test_07_list_public_templates | Success | 0.04 | test_templates.py test_05_template_permissions | Success | 0.06 | test_templates.py test_04_extract_template | Success | 15.23 | test_templates.py test_03_delete_template | Success | 5.25 | test_templates.py test_02_edit_template | Success | 90.14 | test_templates.py test_01_create_template | Success | 176.07 | test_templates.py test_10_destroy_cpvm | Success | 236.56 | test_ssvm.py test_09_destroy_ssvm | Success | 268.45 | test_ssvm.py test_08_reboot_cpvm | Success | 186.36 | test_ssvm.py test_07_reboot_ssvm | Success | 158.86 | test_ssvm.py test_06_stop_cpvm | Success | 176.63 | test_ssvm.py test_05_stop_ssvm | Success | 203.78 | test_ssvm.py test_04_cpvm_internals | Success | 1.05 | test_ssvm.py test_03_ssvm_internals | Success | 3.58 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.09 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.09 | test_ssvm.py test_01_snapshot_root_disk | Success | 81.33 | test_snapshots.py test_04_change_offering_small | Success | 96.93 | test_service_offerings.py test_03_delete_service_offering | Success | 0.03 | test_service_offerings.py test_02_edit_service_offering | Success | 0.06 | test_service_offerings.py test_01_create_service_offering | Success | 0.08 | test_service_offerings.py test_02_sys_templ
[jira] [Commented] (CLOUDSTACK-9500) VR configuration not clean properly after Public IP release
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15735916#comment-15735916
]
ASF GitHub Bot commented on CLOUDSTACK-9500:
Github user swill commented on the issue:
https://github.com/apache/cloudstack/pull/1706
The merge conflict between this PR and #1741 is a bit tricky, so I have
included this fix in #1741. @vilisseranen and I are currently running both PRs
in production so we had to resolve the merge conflict for our deployment.
Since the resolution is not trivial, I thought it made sense to just include
this fix in my PR.
> VR configuration not clean properly after Public IP release
> ---
>
> Key: CLOUDSTACK-9500
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9500
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.7.0, 4.9.0
>Reporter: Pierre-Luc Dion
>
> On a VPC, releasing a public IP that had Port Forwarding does not remove
> configuration of the public IP on the VR configs
> ({{/etc/cloudstack/forwardingrules.json}}, {{/etc/cloudstack/ips.json}})
> So, when this IP is reassign to another VPC, it cause arp table issues on
> switches, because 2 MAC try to own this IP from 2 different VRs. the IP on
> the old VR is not pignable but the switches arp table get updated every time
> the previous VR have configuration changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9647) NIC adapter type becomes e1000 , even after changing the global parameter "vmware.systemvm.nic.device.type" to vmxnet3 for VPC VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15735921#comment-15735921 ] ASF GitHub Bot commented on CLOUDSTACK-9647: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1810 Trillian test result (tid-639) Environment: vmware-55u3 (x2), Advanced Networking with Mgmt server 7 Total time taken: 36341 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1810-t639-vmware-55u3.zip Test completed. 44 look ok, 4 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_04_rvpc_privategw_static_routes | `Failure` | 1025.96 | test_privategw_acl.py test_02_vpc_privategw_static_routes | `Failure` | 156.95 | test_privategw_acl.py test_01_vpc_site2site_vpn | `Error` | 476.67 | test_vpc_vpn.py test_01_redundant_vpc_site2site_vpn | `Error` | 738.35 | test_vpc_vpn.py test_CreateTemplateWithDuplicateName | `Error` | 0.04 | test_templates.py test_01_create_template | `Error` | 0.05 | test_templates.py ContextSuite context=TestTemplates>:setup | `Error` | 349.56 | test_templates.py test_03_vpc_privategw_restart_vpc_cleanup | `Error` | 772.54 | test_privategw_acl.py test_03_vpc_privategw_restart_vpc_cleanup | `Error` | 833.22 | test_privategw_acl.py ContextSuite context=TestListIdsParams>:setup | `Error` | 0.00 | test_list_ids_parameter.py test_01_vpc_remote_access_vpn | Success | 151.77 | test_vpc_vpn.py test_02_VPC_default_routes | Success | 430.36 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 651.33 | test_vpc_router_nics.py test_05_rvpc_multi_tiers | Success | 692.49 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | Success | 1573.69 | test_vpc_redundant.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Success | 658.99 | test_vpc_redundant.py test_02_redundant_VPC_default_routes | Success | 694.15 | test_vpc_redundant.py test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1404.94 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 31.11 | test_volumes.py test_06_download_detached_volume | Success | 70.62 | test_volumes.py test_05_detach_volume | Success | 110.55 | test_volumes.py test_04_delete_attached_volume | Success | 15.24 | test_volumes.py test_03_download_attached_volume | Success | 20.62 | test_volumes.py test_02_attach_volume | Success | 59.40 | test_volumes.py test_01_create_volume | Success | 458.54 | test_volumes.py test_03_delete_vm_snapshots | Success | 280.27 | test_vm_snapshots.py test_02_revert_vm_snapshots | Success | 229.71 | test_vm_snapshots.py test_01_test_vm_volume_snapshot | Success | 372.94 | test_vm_snapshots.py test_01_create_vm_snapshots | Success | 159.05 | test_vm_snapshots.py test_deploy_vm_multiple | Success | 282.83 | test_vm_life_cycle.py test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py test_advZoneVirtualRouter | Success | 0.03 | test_vm_life_cycle.py test_10_attachAndDetach_iso | Success | 248.35 | test_vm_life_cycle.py test_09_expunge_vm | Success | 125.16 | test_vm_life_cycle.py test_08_migrate_vm | Success | 71.07 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.10 | test_vm_life_cycle.py test_06_destroy_vm | Success | 10.14 | test_vm_life_cycle.py test_03_reboot_vm | Success | 5.14 | test_vm_life_cycle.py test_02_start_vm | Success | 20.27 | test_vm_life_cycle.py test_01_stop_vm | Success | 10.16 | test_vm_life_cycle.py test_10_destroy_cpvm | Success | 231.88 | test_ssvm.py test_09_destroy_ssvm | Success | 243.82 | test_ssvm.py test_08_reboot_cpvm | Success | 306.77 | test_ssvm.py test_07_reboot_ssvm | Success | 158.52 | test_ssvm.py test_06_stop_cpvm | Success | 211.86 | test_ssvm.py test_05_stop_ssvm | Success | 210.28 | test_ssvm.py test_04_cpvm_internals | Success | 1.23 | test_ssvm.py test_03_ssvm_internals | Success | 3.87 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.14 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.14 | test_ssvm.py test_01_snapshot_root_disk | Success | 66.46 | test_snapshots.py test_04_change_offering_small | Success | 96.83 | test_service_offerings.py test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py test_02_edit_service_offering | Success | 0.08 | test_service_offerings.py test_01_create_service_offering | Success | 0.12 | test_service_offerings.py test_02_sys_template_ready | Success | 0.14 | test_secondary_storage.py test_01_sys_vm_start | Success | 0.19 | test_secondary_storage.py test_09_reboot_router | Success | 130.85 | test_routers.py test_08_start_router | Success
[jira] [Commented] (CLOUDSTACK-8908) After copying the template charging for that template is stopped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15735941#comment-15735941 ] ASF GitHub Bot commented on CLOUDSTACK-8908: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/896 Trillian test result (tid-644) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 25273 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr896-t644-kvm-centos7.zip Test completed. 42 look ok, 1 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | `Failure` | 394.19 | test_vpc_redundant.py ContextSuite context=TestVPCRedundancy>:teardown | `Error` | 518.05 | test_vpc_redundant.py test_01_vpc_site2site_vpn | Success | 154.68 | test_vpc_vpn.py test_01_vpc_remote_access_vpn | Success | 65.89 | test_vpc_vpn.py test_01_redundant_vpc_site2site_vpn | Success | 260.11 | test_vpc_vpn.py test_02_VPC_default_routes | Success | 270.17 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 568.68 | test_vpc_router_nics.py test_05_rvpc_multi_tiers | Success | 512.90 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | Success | 1433.92 | test_vpc_redundant.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Success | 553.77 | test_vpc_redundant.py test_02_redundant_VPC_default_routes | Success | 761.75 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 15.56 | test_volumes.py test_08_resize_volume | Success | 15.27 | test_volumes.py test_07_resize_fail | Success | 20.41 | test_volumes.py test_06_download_detached_volume | Success | 15.28 | test_volumes.py test_05_detach_volume | Success | 100.34 | test_volumes.py test_04_delete_attached_volume | Success | 10.20 | test_volumes.py test_03_download_attached_volume | Success | 15.21 | test_volumes.py test_02_attach_volume | Success | 45.79 | test_volumes.py test_01_create_volume | Success | 712.90 | test_volumes.py test_deploy_vm_multiple | Success | 303.20 | test_vm_life_cycle.py test_deploy_vm | Success | 0.02 | test_vm_life_cycle.py test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py test_10_attachAndDetach_iso | Success | 21.48 | test_vm_life_cycle.py test_09_expunge_vm | Success | 185.28 | test_vm_life_cycle.py test_08_migrate_vm | Success | 40.80 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.08 | test_vm_life_cycle.py test_06_destroy_vm | Success | 125.72 | test_vm_life_cycle.py test_03_reboot_vm | Success | 125.72 | test_vm_life_cycle.py test_02_start_vm | Success | 10.12 | test_vm_life_cycle.py test_01_stop_vm | Success | 40.28 | test_vm_life_cycle.py test_CreateTemplateWithDuplicateName | Success | 85.69 | test_templates.py test_08_list_system_templates | Success | 0.02 | test_templates.py test_07_list_public_templates | Success | 0.02 | test_templates.py test_05_template_permissions | Success | 0.03 | test_templates.py test_04_extract_template | Success | 5.11 | test_templates.py test_03_delete_template | Success | 5.15 | test_templates.py test_02_edit_template | Success | 90.11 | test_templates.py test_01_create_template | Success | 45.52 | test_templates.py test_10_destroy_cpvm | Success | 161.59 | test_ssvm.py test_09_destroy_ssvm | Success | 163.51 | test_ssvm.py test_08_reboot_cpvm | Success | 101.43 | test_ssvm.py test_07_reboot_ssvm | Success | 133.47 | test_ssvm.py test_06_stop_cpvm | Success | 136.62 | test_ssvm.py test_05_stop_ssvm | Success | 133.59 | test_ssvm.py test_04_cpvm_internals | Success | 1.24 | test_ssvm.py test_03_ssvm_internals | Success | 5.24 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.13 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.14 | test_ssvm.py test_01_snapshot_root_disk | Success | 11.71 | test_snapshots.py test_04_change_offering_small | Success | 246.68 | test_service_offerings.py test_03_delete_service_offering | Success | 0.03 | test_service_offerings.py test_02_edit_service_offering | Success | 0.05 | test_service_offerings.py test_01_create_service_offering | Success | 0.08 | test_service_offerings.py test_02_sys_template_ready | Success | 0.08 | test_secondary_storage.py test_01_sys_vm_start | Success | 0.12 | test_secondary_storage.py test_09_reboot_router | Success | 50.40 | test_routers.py test_08_start_router | Success | 70.53 | test_routers.py test_07_stop_router | Success | 10.13 | test_routers.py test_06_router_advanced | Success | 0.04 | test_routers.py test_05_router_basic | Success | 0.03 | test_routers.py
[jira] [Commented] (CLOUDSTACK-9626) Instance fails to start after unsuccesful compute offering upgrade.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15735944#comment-15735944 ] ASF GitHub Bot commented on CLOUDSTACK-9626: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1796 LGTM, and test LGTM. > Instance fails to start after unsuccesful compute offering upgrade. > --- > > Key: CLOUDSTACK-9626 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9626 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.8.0 >Reporter: Sudhansu Sahu >Assignee: Sudhansu Sahu > > ISSUE > > Instance fails to start after unsuccesful compute offering upgrade. > > TROUBLESHOOTING > == > We observed VM instance get compute values "cpuNumber","cpuSpeed","memory" > removed from table "user_vm_details", which cause instance fail to startup > next time on XenServer > mysql> select * from user_vm_details where vm_id=10; > +-+---++-+-+ > | id | vm_id | name | value >| display | > +-+---++-+-+ > | 218 |10 | platform | > viridian:true;acpi:1;apic:true;pae:true;nx:true | 1 | > | 219 |10 | hypervisortoolsversion | xenserver56 >| 1 | > | 220 |10 | Message.ReservedCapacityFreed.Flag | true >| 1 | > +-+---++-+-+ > 3 rows in set (0.00 sec) > > Unexpected exception while executing > org.apache.cloudstack.api.command.user.vm.ScaleVMCmd > java.lang.NullPointerException > at > com.cloud.vm.UserVmManagerImpl.upgradeStoppedVirtualMachine(UserVmManagerImpl.java:953) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1331) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1271) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at $Proxy169.upgradeVirtualMachine(Unknown Source) > at > org.apache.cloudstack.api.command.user.vm.ScaleVMCmd.execute(ScaleVMCmd.java:127) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:167) > at > com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:97) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:543) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:50) > 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:47) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:500) > at > java.util.concurrent.Ex
[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15735948#comment-15735948 ] ASF GitHub Bot commented on CLOUDSTACK-9619: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1749 Trillian test result (tid-643) Environment: vmware-55u3 (x2), Advanced Networking with Mgmt server 7 Total time taken: 36803 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1749-t643-vmware-55u3.zip Test completed. 40 look ok, 9 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_04_rvpc_privategw_static_routes | `Failure` | 1065.68 | test_privategw_acl.py test_01_vpc_site2site_vpn | `Error` | 482.22 | test_vpc_vpn.py test_01_redundant_vpc_site2site_vpn | `Error` | 778.60 | test_vpc_vpn.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | `Error` | 677.71 | test_vpc_redundant.py test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | `Error` | 116.64 | test_vpc_redundant.py test_CreateTemplateWithDuplicateName | `Error` | 0.04 | test_templates.py test_01_create_template | `Error` | 0.05 | test_templates.py ContextSuite context=TestTemplates>:setup | `Error` | 233.77 | test_templates.py test_07_reboot_ssvm | `Error` | 305.65 | test_ssvm.py ContextSuite context=TestSnapshotRootDisk>:teardown | `Error` | 106.87 | test_snapshots.py test_09_reboot_router | `Error` | 5.12 | test_routers.py test_08_start_router | `Error` | 171.15 | test_routers.py test_03_vpc_privategw_restart_vpc_cleanup | `Error` | 722.54 | test_privategw_acl.py test_03_vpc_privategw_restart_vpc_cleanup | `Error` | 778.19 | test_privategw_acl.py ContextSuite context=TestListIdsParams>:setup | `Error` | 0.00 | test_list_ids_parameter.py test_3d_gpu_support | `Error` | 470.19 | test_deploy_vgpu_enabled_vm.py test_01_vpc_remote_access_vpn | Success | 172.01 | test_vpc_vpn.py test_02_VPC_default_routes | Success | 360.06 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 727.25 | test_vpc_router_nics.py test_05_rvpc_multi_tiers | Success | 679.35 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | Success | 1564.39 | test_vpc_redundant.py test_02_redundant_VPC_default_routes | Success | 665.20 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 25.84 | test_volumes.py test_06_download_detached_volume | Success | 90.75 | test_volumes.py test_05_detach_volume | Success | 100.28 | test_volumes.py test_04_delete_attached_volume | Success | 10.19 | test_volumes.py test_03_download_attached_volume | Success | 25.37 | test_volumes.py test_02_attach_volume | Success | 64.78 | test_volumes.py test_01_create_volume | Success | 519.97 | test_volumes.py test_03_delete_vm_snapshots | Success | 275.24 | test_vm_snapshots.py test_02_revert_vm_snapshots | Success | 199.15 | test_vm_snapshots.py test_01_test_vm_volume_snapshot | Success | 206.59 | test_vm_snapshots.py test_01_create_vm_snapshots | Success | 129.65 | test_vm_snapshots.py test_deploy_vm_multiple | Success | 247.65 | test_vm_life_cycle.py test_deploy_vm | Success | 0.04 | test_vm_life_cycle.py test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py test_10_attachAndDetach_iso | Success | 47.26 | test_vm_life_cycle.py test_09_expunge_vm | Success | 125.21 | test_vm_life_cycle.py test_08_migrate_vm | Success | 91.28 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.10 | test_vm_life_cycle.py test_06_destroy_vm | Success | 10.15 | test_vm_life_cycle.py test_03_reboot_vm | Success | 5.14 | test_vm_life_cycle.py test_02_start_vm | Success | 20.26 | test_vm_life_cycle.py test_01_stop_vm | Success | 10.15 | test_vm_life_cycle.py test_10_destroy_cpvm | Success | 231.95 | test_ssvm.py test_09_destroy_ssvm | Success | 243.87 | test_ssvm.py test_08_reboot_cpvm | Success | 186.61 | test_ssvm.py test_06_stop_cpvm | Success | 176.93 | test_ssvm.py test_05_stop_ssvm | Success | 218.79 | test_ssvm.py test_04_cpvm_internals | Success | 1.42 | test_ssvm.py test_03_ssvm_internals | Success | 6.55 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.12 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.13 | test_ssvm.py test_01_snapshot_root_disk | Success | 61.40 | test_snapshots.py test_04_change_offering_small | Success | 97.36 | test_service_offerings.py test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py test_02_edit_service_offering | Success | 0.08 | test_service_offerings.py test_01_create_service_offering | Success | 0.11 | test_service_offerings.py test_02_sys_template_ready | Suc
[jira] [Commented] (CLOUDSTACK-8908) After copying the template charging for that template is stopped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15735992#comment-15735992 ] ASF GitHub Bot commented on CLOUDSTACK-8908: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/896 LGTM. > After copying the template charging for that template is stopped > - > > Key: CLOUDSTACK-8908 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8908 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template, Usage >Affects Versions: 4.5.2 >Reporter: subhash yedugundla > > [Repro Steps] > Register a template in Zone 1 . > Copy the template from Zone 1 to Zone 2 . > Once copied, deleted the template from Zone 1. > Check the charging of the template and found that charging of the template > in Zone 2 stopped > Sample data related to the issue > mysql> select id,type,state,description,created from event where description > like "%4186%" and type like "%template%"; > +-+-+---+-+-+ > > | id | type | state | description | created | > +-+-+---+-+-+ > > | 1964466 | TEMPLATE.CREATE | Completed | Successfully completed creating > template. Id: 4186 name: PerfTestVM2 | 2015-06-15 09:48:57 | > | 2411011 | TEMPLATE.COPY | Scheduled | copying template: 4186 from zone: 3 > to zone: 1 | 2015-07-22 03:57:32 | > | 2411012 | TEMPLATE.COPY | Started | copying template. copying template: > 4186 from zone: 3 to zone: 1 | 2015-07-22 03:57:32 | > | 2411458 | TEMPLATE.COPY | Completed | Successfully completed copying > template. copying template: 4186 from zone: 3 to zone: 1 | 2015-07-22 > 04:47:08 | > | 2412521 | TEMPLATE.DELETE | Scheduled | Deleting template 4186 | 2015-07-22 > 06:46:18 | > | 2412522 | TEMPLATE.DELETE | Started | deleting template. Template Id: 4186 > | 2015-07-22 06:46:18 | > | 2412523 | TEMPLATE.DELETE | Completed | Successfully completed deleting > template. Template Id: 4186 | 2015-07-22 06:46:18 | > +-+-+---+-+-+ > > You can see that the template of zone3 is not removed. > mysql> select * from template_zone_ref where template_id=4186;; > +--+-+-+-+-+-+ > > | id | zone_id | template_id | created | last_updated | removed | > +--+-+-+-+-+-+ > > | 3974 | 3 | 4186 | 2015-06-15 09:48:57 | 2015-06-15 09:48:57 | NULL | > <=Not removed > | 4845 | 1 | 4186 | 2015-07-22 04:47:08 | 2015-07-22 04:47:08 | 2015-07-22 > 06:46:18 | > +--+-+-+-+-+-+ > > However, not only Zone1 but also the charging of the template of Zone3 > stopped. > +-+-+-+-+--+---++--+-+ > > | id | start_date | end_date | zone_id | description | usage_display | > raw_usage | usage_id | size | > +-+-+-+-+--+---++--+-+ > > | 5998486 | 2015-06-14 15:00:00 | 2015-06-15 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 4.808055 Hrs | 4.808055400848389 | > 4186 | 14995087360 | > =an abbreviation > 4186 | 14995087360 | > | 7834096 | 2015-07-19 15:00:00 | 2015-07-20 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7889426 | 2015-07-20 15:00:00 | 2015-07-21 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7945799 | 2015-07-21 15:00:00 | 2015-07-22 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 15.771667 Hrs | 15.771666526794434 > | 4186 | 14995087360 | > | 7945801 | 2015-07-21 15:00:00 | 2015-07-22 14:59:59 | 1 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 1.986111 Hrs | 1.9861112833023071 | > 4186 | 14995087360 | > +-+-+
[jira] [Commented] (CLOUDSTACK-8908) After copying the template charging for that template is stopped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736190#comment-15736190 ] ASF subversion and git services commented on CLOUDSTACK-8908: - Commit a13ee852af55be346ab836cdf3fc9fb630eb75fc in cloudstack's branch refs/heads/4.9 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a13ee85 ] Merge pull request #896 from yvsubhash/CLOUDSTACK-8908 CLOUDSTACK-8908 After copying the template charging for that template is getting stoppedThis is happening as the zone id is not part of the query. Zone id is added to the query and unit tests are also added * pr/896: CLOUDSTACK-8908 After copying the template charging for that template is stopped Signed-off-by: Rohit Yadav > After copying the template charging for that template is stopped > - > > Key: CLOUDSTACK-8908 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8908 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template, Usage >Affects Versions: 4.5.2 >Reporter: subhash yedugundla > > [Repro Steps] > Register a template in Zone 1 . > Copy the template from Zone 1 to Zone 2 . > Once copied, deleted the template from Zone 1. > Check the charging of the template and found that charging of the template > in Zone 2 stopped > Sample data related to the issue > mysql> select id,type,state,description,created from event where description > like "%4186%" and type like "%template%"; > +-+-+---+-+-+ > > | id | type | state | description | created | > +-+-+---+-+-+ > > | 1964466 | TEMPLATE.CREATE | Completed | Successfully completed creating > template. Id: 4186 name: PerfTestVM2 | 2015-06-15 09:48:57 | > | 2411011 | TEMPLATE.COPY | Scheduled | copying template: 4186 from zone: 3 > to zone: 1 | 2015-07-22 03:57:32 | > | 2411012 | TEMPLATE.COPY | Started | copying template. copying template: > 4186 from zone: 3 to zone: 1 | 2015-07-22 03:57:32 | > | 2411458 | TEMPLATE.COPY | Completed | Successfully completed copying > template. copying template: 4186 from zone: 3 to zone: 1 | 2015-07-22 > 04:47:08 | > | 2412521 | TEMPLATE.DELETE | Scheduled | Deleting template 4186 | 2015-07-22 > 06:46:18 | > | 2412522 | TEMPLATE.DELETE | Started | deleting template. Template Id: 4186 > | 2015-07-22 06:46:18 | > | 2412523 | TEMPLATE.DELETE | Completed | Successfully completed deleting > template. Template Id: 4186 | 2015-07-22 06:46:18 | > +-+-+---+-+-+ > > You can see that the template of zone3 is not removed. > mysql> select * from template_zone_ref where template_id=4186;; > +--+-+-+-+-+-+ > > | id | zone_id | template_id | created | last_updated | removed | > +--+-+-+-+-+-+ > > | 3974 | 3 | 4186 | 2015-06-15 09:48:57 | 2015-06-15 09:48:57 | NULL | > <=Not removed > | 4845 | 1 | 4186 | 2015-07-22 04:47:08 | 2015-07-22 04:47:08 | 2015-07-22 > 06:46:18 | > +--+-+-+-+-+-+ > > However, not only Zone1 but also the charging of the template of Zone3 > stopped. > +-+-+-+-+--+---++--+-+ > > | id | start_date | end_date | zone_id | description | usage_display | > raw_usage | usage_id | size | > +-+-+-+-+--+---++--+-+ > > | 5998486 | 2015-06-14 15:00:00 | 2015-06-15 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 4.808055 Hrs | 4.808055400848389 | > 4186 | 14995087360 | > =an abbreviation > 4186 | 14995087360 | > | 7834096 | 2015-07-19 15:00:00 | 2015-07-20 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7889426 | 2015-07-20 15:00:00 | 2015-07-21 14:59:59 | 3 | Templ
[jira] [Commented] (CLOUDSTACK-9626) Instance fails to start after unsuccesful compute offering upgrade.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736188#comment-15736188 ] ASF subversion and git services commented on CLOUDSTACK-9626: - Commit c89198f4c65e74a27a5586e4e18b0e71b164a904 in cloudstack's branch refs/heads/4.9 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c89198f ] Merge pull request #1796 from sudhansu7/CLOUDSTACK-9626 CLOUDSTACK-9626: Instance fails to start after unsuccesful computeISSUE Instance fails to start after unsuccesful compute offering upgrade. TROUBLESHOOTING == We observed VM instance get compute values "cpuNumber","cpuSpeed","memory" removed from table "user_vm_details", which cause instance fail to startup next time on XenServer `mysql> select * from user_vm_details where vm_id=10; -- id vm_id namevalue display -- 218 10 platformviridian:true;acpi:1;apic:true;pae:true;nx:true 1 219 10 hypervisortoolsversion xenserver56 1 220 10 Message.ReservedCapacityFreed.Flag true1 -- 3 rows in set (0.00 sec)` `2016-11-29 06:49:03,667 ERROR [c.c.a.ApiAsyncJobDispatcher] (API-Job-Executor-12:ctx-49c25b1d job-125) (logid:114a2f1b) Unexpected exception while executing org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin java.lang.NullPointerException at com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1664) at com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1631) at com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1561) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy197.upgradeVirtualMachine(Unknown Source) at org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin.execute(ScaleVMCmdByAdmin.java:48) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150) at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:554) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:502) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worke
[jira] [Commented] (CLOUDSTACK-8908) After copying the template charging for that template is stopped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736181#comment-15736181 ] ASF GitHub Bot commented on CLOUDSTACK-8908: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/896 > After copying the template charging for that template is stopped > - > > Key: CLOUDSTACK-8908 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8908 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template, Usage >Affects Versions: 4.5.2 >Reporter: subhash yedugundla > > [Repro Steps] > Register a template in Zone 1 . > Copy the template from Zone 1 to Zone 2 . > Once copied, deleted the template from Zone 1. > Check the charging of the template and found that charging of the template > in Zone 2 stopped > Sample data related to the issue > mysql> select id,type,state,description,created from event where description > like "%4186%" and type like "%template%"; > +-+-+---+-+-+ > > | id | type | state | description | created | > +-+-+---+-+-+ > > | 1964466 | TEMPLATE.CREATE | Completed | Successfully completed creating > template. Id: 4186 name: PerfTestVM2 | 2015-06-15 09:48:57 | > | 2411011 | TEMPLATE.COPY | Scheduled | copying template: 4186 from zone: 3 > to zone: 1 | 2015-07-22 03:57:32 | > | 2411012 | TEMPLATE.COPY | Started | copying template. copying template: > 4186 from zone: 3 to zone: 1 | 2015-07-22 03:57:32 | > | 2411458 | TEMPLATE.COPY | Completed | Successfully completed copying > template. copying template: 4186 from zone: 3 to zone: 1 | 2015-07-22 > 04:47:08 | > | 2412521 | TEMPLATE.DELETE | Scheduled | Deleting template 4186 | 2015-07-22 > 06:46:18 | > | 2412522 | TEMPLATE.DELETE | Started | deleting template. Template Id: 4186 > | 2015-07-22 06:46:18 | > | 2412523 | TEMPLATE.DELETE | Completed | Successfully completed deleting > template. Template Id: 4186 | 2015-07-22 06:46:18 | > +-+-+---+-+-+ > > You can see that the template of zone3 is not removed. > mysql> select * from template_zone_ref where template_id=4186;; > +--+-+-+-+-+-+ > > | id | zone_id | template_id | created | last_updated | removed | > +--+-+-+-+-+-+ > > | 3974 | 3 | 4186 | 2015-06-15 09:48:57 | 2015-06-15 09:48:57 | NULL | > <=Not removed > | 4845 | 1 | 4186 | 2015-07-22 04:47:08 | 2015-07-22 04:47:08 | 2015-07-22 > 06:46:18 | > +--+-+-+-+-+-+ > > However, not only Zone1 but also the charging of the template of Zone3 > stopped. > +-+-+-+-+--+---++--+-+ > > | id | start_date | end_date | zone_id | description | usage_display | > raw_usage | usage_id | size | > +-+-+-+-+--+---++--+-+ > > | 5998486 | 2015-06-14 15:00:00 | 2015-06-15 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 4.808055 Hrs | 4.808055400848389 | > 4186 | 14995087360 | > =an abbreviation > 4186 | 14995087360 | > | 7834096 | 2015-07-19 15:00:00 | 2015-07-20 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7889426 | 2015-07-20 15:00:00 | 2015-07-21 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7945799 | 2015-07-21 15:00:00 | 2015-07-22 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 15.771667 Hrs | 15.771666526794434 > | 4186 | 14995087360 | > | 7945801 | 2015-07-21 15:00:00 | 2015-07-22 14:59:59 | 1 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 1.986111 Hrs | 1.9861112833023071 | > 4186 | 14995087360 | > +-+-+
[jira] [Commented] (CLOUDSTACK-8908) After copying the template charging for that template is stopped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736191#comment-15736191 ] ASF subversion and git services commented on CLOUDSTACK-8908: - Commit a13ee852af55be346ab836cdf3fc9fb630eb75fc in cloudstack's branch refs/heads/4.9 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a13ee85 ] Merge pull request #896 from yvsubhash/CLOUDSTACK-8908 CLOUDSTACK-8908 After copying the template charging for that template is getting stoppedThis is happening as the zone id is not part of the query. Zone id is added to the query and unit tests are also added * pr/896: CLOUDSTACK-8908 After copying the template charging for that template is stopped Signed-off-by: Rohit Yadav > After copying the template charging for that template is stopped > - > > Key: CLOUDSTACK-8908 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8908 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template, Usage >Affects Versions: 4.5.2 >Reporter: subhash yedugundla > > [Repro Steps] > Register a template in Zone 1 . > Copy the template from Zone 1 to Zone 2 . > Once copied, deleted the template from Zone 1. > Check the charging of the template and found that charging of the template > in Zone 2 stopped > Sample data related to the issue > mysql> select id,type,state,description,created from event where description > like "%4186%" and type like "%template%"; > +-+-+---+-+-+ > > | id | type | state | description | created | > +-+-+---+-+-+ > > | 1964466 | TEMPLATE.CREATE | Completed | Successfully completed creating > template. Id: 4186 name: PerfTestVM2 | 2015-06-15 09:48:57 | > | 2411011 | TEMPLATE.COPY | Scheduled | copying template: 4186 from zone: 3 > to zone: 1 | 2015-07-22 03:57:32 | > | 2411012 | TEMPLATE.COPY | Started | copying template. copying template: > 4186 from zone: 3 to zone: 1 | 2015-07-22 03:57:32 | > | 2411458 | TEMPLATE.COPY | Completed | Successfully completed copying > template. copying template: 4186 from zone: 3 to zone: 1 | 2015-07-22 > 04:47:08 | > | 2412521 | TEMPLATE.DELETE | Scheduled | Deleting template 4186 | 2015-07-22 > 06:46:18 | > | 2412522 | TEMPLATE.DELETE | Started | deleting template. Template Id: 4186 > | 2015-07-22 06:46:18 | > | 2412523 | TEMPLATE.DELETE | Completed | Successfully completed deleting > template. Template Id: 4186 | 2015-07-22 06:46:18 | > +-+-+---+-+-+ > > You can see that the template of zone3 is not removed. > mysql> select * from template_zone_ref where template_id=4186;; > +--+-+-+-+-+-+ > > | id | zone_id | template_id | created | last_updated | removed | > +--+-+-+-+-+-+ > > | 3974 | 3 | 4186 | 2015-06-15 09:48:57 | 2015-06-15 09:48:57 | NULL | > <=Not removed > | 4845 | 1 | 4186 | 2015-07-22 04:47:08 | 2015-07-22 04:47:08 | 2015-07-22 > 06:46:18 | > +--+-+-+-+-+-+ > > However, not only Zone1 but also the charging of the template of Zone3 > stopped. > +-+-+-+-+--+---++--+-+ > > | id | start_date | end_date | zone_id | description | usage_display | > raw_usage | usage_id | size | > +-+-+-+-+--+---++--+-+ > > | 5998486 | 2015-06-14 15:00:00 | 2015-06-15 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 4.808055 Hrs | 4.808055400848389 | > 4186 | 14995087360 | > =an abbreviation > 4186 | 14995087360 | > | 7834096 | 2015-07-19 15:00:00 | 2015-07-20 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7889426 | 2015-07-20 15:00:00 | 2015-07-21 14:59:59 | 3 | Templ
[jira] [Commented] (CLOUDSTACK-8908) After copying the template charging for that template is stopped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736189#comment-15736189 ] ASF subversion and git services commented on CLOUDSTACK-8908: - Commit a13ee852af55be346ab836cdf3fc9fb630eb75fc in cloudstack's branch refs/heads/4.9 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a13ee85 ] Merge pull request #896 from yvsubhash/CLOUDSTACK-8908 CLOUDSTACK-8908 After copying the template charging for that template is getting stoppedThis is happening as the zone id is not part of the query. Zone id is added to the query and unit tests are also added * pr/896: CLOUDSTACK-8908 After copying the template charging for that template is stopped Signed-off-by: Rohit Yadav > After copying the template charging for that template is stopped > - > > Key: CLOUDSTACK-8908 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8908 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template, Usage >Affects Versions: 4.5.2 >Reporter: subhash yedugundla > > [Repro Steps] > Register a template in Zone 1 . > Copy the template from Zone 1 to Zone 2 . > Once copied, deleted the template from Zone 1. > Check the charging of the template and found that charging of the template > in Zone 2 stopped > Sample data related to the issue > mysql> select id,type,state,description,created from event where description > like "%4186%" and type like "%template%"; > +-+-+---+-+-+ > > | id | type | state | description | created | > +-+-+---+-+-+ > > | 1964466 | TEMPLATE.CREATE | Completed | Successfully completed creating > template. Id: 4186 name: PerfTestVM2 | 2015-06-15 09:48:57 | > | 2411011 | TEMPLATE.COPY | Scheduled | copying template: 4186 from zone: 3 > to zone: 1 | 2015-07-22 03:57:32 | > | 2411012 | TEMPLATE.COPY | Started | copying template. copying template: > 4186 from zone: 3 to zone: 1 | 2015-07-22 03:57:32 | > | 2411458 | TEMPLATE.COPY | Completed | Successfully completed copying > template. copying template: 4186 from zone: 3 to zone: 1 | 2015-07-22 > 04:47:08 | > | 2412521 | TEMPLATE.DELETE | Scheduled | Deleting template 4186 | 2015-07-22 > 06:46:18 | > | 2412522 | TEMPLATE.DELETE | Started | deleting template. Template Id: 4186 > | 2015-07-22 06:46:18 | > | 2412523 | TEMPLATE.DELETE | Completed | Successfully completed deleting > template. Template Id: 4186 | 2015-07-22 06:46:18 | > +-+-+---+-+-+ > > You can see that the template of zone3 is not removed. > mysql> select * from template_zone_ref where template_id=4186;; > +--+-+-+-+-+-+ > > | id | zone_id | template_id | created | last_updated | removed | > +--+-+-+-+-+-+ > > | 3974 | 3 | 4186 | 2015-06-15 09:48:57 | 2015-06-15 09:48:57 | NULL | > <=Not removed > | 4845 | 1 | 4186 | 2015-07-22 04:47:08 | 2015-07-22 04:47:08 | 2015-07-22 > 06:46:18 | > +--+-+-+-+-+-+ > > However, not only Zone1 but also the charging of the template of Zone3 > stopped. > +-+-+-+-+--+---++--+-+ > > | id | start_date | end_date | zone_id | description | usage_display | > raw_usage | usage_id | size | > +-+-+-+-+--+---++--+-+ > > | 5998486 | 2015-06-14 15:00:00 | 2015-06-15 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 4.808055 Hrs | 4.808055400848389 | > 4186 | 14995087360 | > =an abbreviation > 4186 | 14995087360 | > | 7834096 | 2015-07-19 15:00:00 | 2015-07-20 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7889426 | 2015-07-20 15:00:00 | 2015-07-21 14:59:59 | 3 | Templ
[jira] [Commented] (CLOUDSTACK-8908) After copying the template charging for that template is stopped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736176#comment-15736176 ] ASF subversion and git services commented on CLOUDSTACK-8908: - Commit 740179c10b6906e6c1e6016c3dd6afce46c8c74b in cloudstack's branch refs/heads/4.8 from [~yvsubhash] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=740179c ] CLOUDSTACK-8908 After copying the template charging for that template is stopped > After copying the template charging for that template is stopped > - > > Key: CLOUDSTACK-8908 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8908 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template, Usage >Affects Versions: 4.5.2 >Reporter: subhash yedugundla > > [Repro Steps] > Register a template in Zone 1 . > Copy the template from Zone 1 to Zone 2 . > Once copied, deleted the template from Zone 1. > Check the charging of the template and found that charging of the template > in Zone 2 stopped > Sample data related to the issue > mysql> select id,type,state,description,created from event where description > like "%4186%" and type like "%template%"; > +-+-+---+-+-+ > > | id | type | state | description | created | > +-+-+---+-+-+ > > | 1964466 | TEMPLATE.CREATE | Completed | Successfully completed creating > template. Id: 4186 name: PerfTestVM2 | 2015-06-15 09:48:57 | > | 2411011 | TEMPLATE.COPY | Scheduled | copying template: 4186 from zone: 3 > to zone: 1 | 2015-07-22 03:57:32 | > | 2411012 | TEMPLATE.COPY | Started | copying template. copying template: > 4186 from zone: 3 to zone: 1 | 2015-07-22 03:57:32 | > | 2411458 | TEMPLATE.COPY | Completed | Successfully completed copying > template. copying template: 4186 from zone: 3 to zone: 1 | 2015-07-22 > 04:47:08 | > | 2412521 | TEMPLATE.DELETE | Scheduled | Deleting template 4186 | 2015-07-22 > 06:46:18 | > | 2412522 | TEMPLATE.DELETE | Started | deleting template. Template Id: 4186 > | 2015-07-22 06:46:18 | > | 2412523 | TEMPLATE.DELETE | Completed | Successfully completed deleting > template. Template Id: 4186 | 2015-07-22 06:46:18 | > +-+-+---+-+-+ > > You can see that the template of zone3 is not removed. > mysql> select * from template_zone_ref where template_id=4186;; > +--+-+-+-+-+-+ > > | id | zone_id | template_id | created | last_updated | removed | > +--+-+-+-+-+-+ > > | 3974 | 3 | 4186 | 2015-06-15 09:48:57 | 2015-06-15 09:48:57 | NULL | > <=Not removed > | 4845 | 1 | 4186 | 2015-07-22 04:47:08 | 2015-07-22 04:47:08 | 2015-07-22 > 06:46:18 | > +--+-+-+-+-+-+ > > However, not only Zone1 but also the charging of the template of Zone3 > stopped. > +-+-+-+-+--+---++--+-+ > > | id | start_date | end_date | zone_id | description | usage_display | > raw_usage | usage_id | size | > +-+-+-+-+--+---++--+-+ > > | 5998486 | 2015-06-14 15:00:00 | 2015-06-15 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 4.808055 Hrs | 4.808055400848389 | > 4186 | 14995087360 | > =an abbreviation > 4186 | 14995087360 | > | 7834096 | 2015-07-19 15:00:00 | 2015-07-20 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7889426 | 2015-07-20 15:00:00 | 2015-07-21 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7945799 | 2015-07-21 15:00:00 | 2015-07-22 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 15.771667 Hrs | 15.771666526794434 > | 4186 | 14995087360 | > | 7945801 | 2015-07-21 15:00:00 | 2015-07-22
[jira] [Commented] (CLOUDSTACK-8908) After copying the template charging for that template is stopped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736180#comment-15736180 ] ASF subversion and git services commented on CLOUDSTACK-8908: - Commit a13ee852af55be346ab836cdf3fc9fb630eb75fc in cloudstack's branch refs/heads/4.8 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a13ee85 ] Merge pull request #896 from yvsubhash/CLOUDSTACK-8908 CLOUDSTACK-8908 After copying the template charging for that template is getting stoppedThis is happening as the zone id is not part of the query. Zone id is added to the query and unit tests are also added * pr/896: CLOUDSTACK-8908 After copying the template charging for that template is stopped Signed-off-by: Rohit Yadav > After copying the template charging for that template is stopped > - > > Key: CLOUDSTACK-8908 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8908 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template, Usage >Affects Versions: 4.5.2 >Reporter: subhash yedugundla > > [Repro Steps] > Register a template in Zone 1 . > Copy the template from Zone 1 to Zone 2 . > Once copied, deleted the template from Zone 1. > Check the charging of the template and found that charging of the template > in Zone 2 stopped > Sample data related to the issue > mysql> select id,type,state,description,created from event where description > like "%4186%" and type like "%template%"; > +-+-+---+-+-+ > > | id | type | state | description | created | > +-+-+---+-+-+ > > | 1964466 | TEMPLATE.CREATE | Completed | Successfully completed creating > template. Id: 4186 name: PerfTestVM2 | 2015-06-15 09:48:57 | > | 2411011 | TEMPLATE.COPY | Scheduled | copying template: 4186 from zone: 3 > to zone: 1 | 2015-07-22 03:57:32 | > | 2411012 | TEMPLATE.COPY | Started | copying template. copying template: > 4186 from zone: 3 to zone: 1 | 2015-07-22 03:57:32 | > | 2411458 | TEMPLATE.COPY | Completed | Successfully completed copying > template. copying template: 4186 from zone: 3 to zone: 1 | 2015-07-22 > 04:47:08 | > | 2412521 | TEMPLATE.DELETE | Scheduled | Deleting template 4186 | 2015-07-22 > 06:46:18 | > | 2412522 | TEMPLATE.DELETE | Started | deleting template. Template Id: 4186 > | 2015-07-22 06:46:18 | > | 2412523 | TEMPLATE.DELETE | Completed | Successfully completed deleting > template. Template Id: 4186 | 2015-07-22 06:46:18 | > +-+-+---+-+-+ > > You can see that the template of zone3 is not removed. > mysql> select * from template_zone_ref where template_id=4186;; > +--+-+-+-+-+-+ > > | id | zone_id | template_id | created | last_updated | removed | > +--+-+-+-+-+-+ > > | 3974 | 3 | 4186 | 2015-06-15 09:48:57 | 2015-06-15 09:48:57 | NULL | > <=Not removed > | 4845 | 1 | 4186 | 2015-07-22 04:47:08 | 2015-07-22 04:47:08 | 2015-07-22 > 06:46:18 | > +--+-+-+-+-+-+ > > However, not only Zone1 but also the charging of the template of Zone3 > stopped. > +-+-+-+-+--+---++--+-+ > > | id | start_date | end_date | zone_id | description | usage_display | > raw_usage | usage_id | size | > +-+-+-+-+--+---++--+-+ > > | 5998486 | 2015-06-14 15:00:00 | 2015-06-15 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 4.808055 Hrs | 4.808055400848389 | > 4186 | 14995087360 | > =an abbreviation > 4186 | 14995087360 | > | 7834096 | 2015-07-19 15:00:00 | 2015-07-20 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7889426 | 2015-07-20 15:00:00 | 2015-07-21 14:59:59 | 3 | Templ
[jira] [Commented] (CLOUDSTACK-9626) Instance fails to start after unsuccesful compute offering upgrade.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736192#comment-15736192 ] ASF GitHub Bot commented on CLOUDSTACK-9626: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/1796 > Instance fails to start after unsuccesful compute offering upgrade. > --- > > Key: CLOUDSTACK-9626 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9626 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.8.0 >Reporter: Sudhansu Sahu >Assignee: Sudhansu Sahu > > ISSUE > > Instance fails to start after unsuccesful compute offering upgrade. > > TROUBLESHOOTING > == > We observed VM instance get compute values "cpuNumber","cpuSpeed","memory" > removed from table "user_vm_details", which cause instance fail to startup > next time on XenServer > mysql> select * from user_vm_details where vm_id=10; > +-+---++-+-+ > | id | vm_id | name | value >| display | > +-+---++-+-+ > | 218 |10 | platform | > viridian:true;acpi:1;apic:true;pae:true;nx:true | 1 | > | 219 |10 | hypervisortoolsversion | xenserver56 >| 1 | > | 220 |10 | Message.ReservedCapacityFreed.Flag | true >| 1 | > +-+---++-+-+ > 3 rows in set (0.00 sec) > > Unexpected exception while executing > org.apache.cloudstack.api.command.user.vm.ScaleVMCmd > java.lang.NullPointerException > at > com.cloud.vm.UserVmManagerImpl.upgradeStoppedVirtualMachine(UserVmManagerImpl.java:953) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1331) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1271) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at $Proxy169.upgradeVirtualMachine(Unknown Source) > at > org.apache.cloudstack.api.command.user.vm.ScaleVMCmd.execute(ScaleVMCmd.java:127) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:167) > at > com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:97) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:543) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:50) > 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:47) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:500) > at > java.util.concurrent.Executors$RunnableAdapter
[jira] [Commented] (CLOUDSTACK-9626) Instance fails to start after unsuccesful compute offering upgrade.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736187#comment-15736187 ] ASF subversion and git services commented on CLOUDSTACK-9626: - Commit c89198f4c65e74a27a5586e4e18b0e71b164a904 in cloudstack's branch refs/heads/4.9 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c89198f ] Merge pull request #1796 from sudhansu7/CLOUDSTACK-9626 CLOUDSTACK-9626: Instance fails to start after unsuccesful computeISSUE Instance fails to start after unsuccesful compute offering upgrade. TROUBLESHOOTING == We observed VM instance get compute values "cpuNumber","cpuSpeed","memory" removed from table "user_vm_details", which cause instance fail to startup next time on XenServer `mysql> select * from user_vm_details where vm_id=10; -- id vm_id namevalue display -- 218 10 platformviridian:true;acpi:1;apic:true;pae:true;nx:true 1 219 10 hypervisortoolsversion xenserver56 1 220 10 Message.ReservedCapacityFreed.Flag true1 -- 3 rows in set (0.00 sec)` `2016-11-29 06:49:03,667 ERROR [c.c.a.ApiAsyncJobDispatcher] (API-Job-Executor-12:ctx-49c25b1d job-125) (logid:114a2f1b) Unexpected exception while executing org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin java.lang.NullPointerException at com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1664) at com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1631) at com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1561) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy197.upgradeVirtualMachine(Unknown Source) at org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin.execute(ScaleVMCmdByAdmin.java:48) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150) at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:554) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:502) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worke
[jira] [Commented] (CLOUDSTACK-8908) After copying the template charging for that template is stopped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736177#comment-15736177 ] ASF subversion and git services commented on CLOUDSTACK-8908: - Commit a13ee852af55be346ab836cdf3fc9fb630eb75fc in cloudstack's branch refs/heads/4.8 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a13ee85 ] Merge pull request #896 from yvsubhash/CLOUDSTACK-8908 CLOUDSTACK-8908 After copying the template charging for that template is getting stoppedThis is happening as the zone id is not part of the query. Zone id is added to the query and unit tests are also added * pr/896: CLOUDSTACK-8908 After copying the template charging for that template is stopped Signed-off-by: Rohit Yadav > After copying the template charging for that template is stopped > - > > Key: CLOUDSTACK-8908 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8908 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template, Usage >Affects Versions: 4.5.2 >Reporter: subhash yedugundla > > [Repro Steps] > Register a template in Zone 1 . > Copy the template from Zone 1 to Zone 2 . > Once copied, deleted the template from Zone 1. > Check the charging of the template and found that charging of the template > in Zone 2 stopped > Sample data related to the issue > mysql> select id,type,state,description,created from event where description > like "%4186%" and type like "%template%"; > +-+-+---+-+-+ > > | id | type | state | description | created | > +-+-+---+-+-+ > > | 1964466 | TEMPLATE.CREATE | Completed | Successfully completed creating > template. Id: 4186 name: PerfTestVM2 | 2015-06-15 09:48:57 | > | 2411011 | TEMPLATE.COPY | Scheduled | copying template: 4186 from zone: 3 > to zone: 1 | 2015-07-22 03:57:32 | > | 2411012 | TEMPLATE.COPY | Started | copying template. copying template: > 4186 from zone: 3 to zone: 1 | 2015-07-22 03:57:32 | > | 2411458 | TEMPLATE.COPY | Completed | Successfully completed copying > template. copying template: 4186 from zone: 3 to zone: 1 | 2015-07-22 > 04:47:08 | > | 2412521 | TEMPLATE.DELETE | Scheduled | Deleting template 4186 | 2015-07-22 > 06:46:18 | > | 2412522 | TEMPLATE.DELETE | Started | deleting template. Template Id: 4186 > | 2015-07-22 06:46:18 | > | 2412523 | TEMPLATE.DELETE | Completed | Successfully completed deleting > template. Template Id: 4186 | 2015-07-22 06:46:18 | > +-+-+---+-+-+ > > You can see that the template of zone3 is not removed. > mysql> select * from template_zone_ref where template_id=4186;; > +--+-+-+-+-+-+ > > | id | zone_id | template_id | created | last_updated | removed | > +--+-+-+-+-+-+ > > | 3974 | 3 | 4186 | 2015-06-15 09:48:57 | 2015-06-15 09:48:57 | NULL | > <=Not removed > | 4845 | 1 | 4186 | 2015-07-22 04:47:08 | 2015-07-22 04:47:08 | 2015-07-22 > 06:46:18 | > +--+-+-+-+-+-+ > > However, not only Zone1 but also the charging of the template of Zone3 > stopped. > +-+-+-+-+--+---++--+-+ > > | id | start_date | end_date | zone_id | description | usage_display | > raw_usage | usage_id | size | > +-+-+-+-+--+---++--+-+ > > | 5998486 | 2015-06-14 15:00:00 | 2015-06-15 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 4.808055 Hrs | 4.808055400848389 | > 4186 | 14995087360 | > =an abbreviation > 4186 | 14995087360 | > | 7834096 | 2015-07-19 15:00:00 | 2015-07-20 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7889426 | 2015-07-20 15:00:00 | 2015-07-21 14:59:59 | 3 | Templ
[jira] [Commented] (CLOUDSTACK-8908) After copying the template charging for that template is stopped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736178#comment-15736178 ] ASF subversion and git services commented on CLOUDSTACK-8908: - Commit a13ee852af55be346ab836cdf3fc9fb630eb75fc in cloudstack's branch refs/heads/4.8 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a13ee85 ] Merge pull request #896 from yvsubhash/CLOUDSTACK-8908 CLOUDSTACK-8908 After copying the template charging for that template is getting stoppedThis is happening as the zone id is not part of the query. Zone id is added to the query and unit tests are also added * pr/896: CLOUDSTACK-8908 After copying the template charging for that template is stopped Signed-off-by: Rohit Yadav > After copying the template charging for that template is stopped > - > > Key: CLOUDSTACK-8908 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8908 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template, Usage >Affects Versions: 4.5.2 >Reporter: subhash yedugundla > > [Repro Steps] > Register a template in Zone 1 . > Copy the template from Zone 1 to Zone 2 . > Once copied, deleted the template from Zone 1. > Check the charging of the template and found that charging of the template > in Zone 2 stopped > Sample data related to the issue > mysql> select id,type,state,description,created from event where description > like "%4186%" and type like "%template%"; > +-+-+---+-+-+ > > | id | type | state | description | created | > +-+-+---+-+-+ > > | 1964466 | TEMPLATE.CREATE | Completed | Successfully completed creating > template. Id: 4186 name: PerfTestVM2 | 2015-06-15 09:48:57 | > | 2411011 | TEMPLATE.COPY | Scheduled | copying template: 4186 from zone: 3 > to zone: 1 | 2015-07-22 03:57:32 | > | 2411012 | TEMPLATE.COPY | Started | copying template. copying template: > 4186 from zone: 3 to zone: 1 | 2015-07-22 03:57:32 | > | 2411458 | TEMPLATE.COPY | Completed | Successfully completed copying > template. copying template: 4186 from zone: 3 to zone: 1 | 2015-07-22 > 04:47:08 | > | 2412521 | TEMPLATE.DELETE | Scheduled | Deleting template 4186 | 2015-07-22 > 06:46:18 | > | 2412522 | TEMPLATE.DELETE | Started | deleting template. Template Id: 4186 > | 2015-07-22 06:46:18 | > | 2412523 | TEMPLATE.DELETE | Completed | Successfully completed deleting > template. Template Id: 4186 | 2015-07-22 06:46:18 | > +-+-+---+-+-+ > > You can see that the template of zone3 is not removed. > mysql> select * from template_zone_ref where template_id=4186;; > +--+-+-+-+-+-+ > > | id | zone_id | template_id | created | last_updated | removed | > +--+-+-+-+-+-+ > > | 3974 | 3 | 4186 | 2015-06-15 09:48:57 | 2015-06-15 09:48:57 | NULL | > <=Not removed > | 4845 | 1 | 4186 | 2015-07-22 04:47:08 | 2015-07-22 04:47:08 | 2015-07-22 > 06:46:18 | > +--+-+-+-+-+-+ > > However, not only Zone1 but also the charging of the template of Zone3 > stopped. > +-+-+-+-+--+---++--+-+ > > | id | start_date | end_date | zone_id | description | usage_display | > raw_usage | usage_id | size | > +-+-+-+-+--+---++--+-+ > > | 5998486 | 2015-06-14 15:00:00 | 2015-06-15 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 4.808055 Hrs | 4.808055400848389 | > 4186 | 14995087360 | > =an abbreviation > 4186 | 14995087360 | > | 7834096 | 2015-07-19 15:00:00 | 2015-07-20 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7889426 | 2015-07-20 15:00:00 | 2015-07-21 14:59:59 | 3 | Templ
[jira] [Commented] (CLOUDSTACK-8908) After copying the template charging for that template is stopped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736183#comment-15736183 ] ASF subversion and git services commented on CLOUDSTACK-8908: - Commit 740179c10b6906e6c1e6016c3dd6afce46c8c74b in cloudstack's branch refs/heads/4.9 from [~yvsubhash] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=740179c ] CLOUDSTACK-8908 After copying the template charging for that template is stopped > After copying the template charging for that template is stopped > - > > Key: CLOUDSTACK-8908 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8908 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template, Usage >Affects Versions: 4.5.2 >Reporter: subhash yedugundla > > [Repro Steps] > Register a template in Zone 1 . > Copy the template from Zone 1 to Zone 2 . > Once copied, deleted the template from Zone 1. > Check the charging of the template and found that charging of the template > in Zone 2 stopped > Sample data related to the issue > mysql> select id,type,state,description,created from event where description > like "%4186%" and type like "%template%"; > +-+-+---+-+-+ > > | id | type | state | description | created | > +-+-+---+-+-+ > > | 1964466 | TEMPLATE.CREATE | Completed | Successfully completed creating > template. Id: 4186 name: PerfTestVM2 | 2015-06-15 09:48:57 | > | 2411011 | TEMPLATE.COPY | Scheduled | copying template: 4186 from zone: 3 > to zone: 1 | 2015-07-22 03:57:32 | > | 2411012 | TEMPLATE.COPY | Started | copying template. copying template: > 4186 from zone: 3 to zone: 1 | 2015-07-22 03:57:32 | > | 2411458 | TEMPLATE.COPY | Completed | Successfully completed copying > template. copying template: 4186 from zone: 3 to zone: 1 | 2015-07-22 > 04:47:08 | > | 2412521 | TEMPLATE.DELETE | Scheduled | Deleting template 4186 | 2015-07-22 > 06:46:18 | > | 2412522 | TEMPLATE.DELETE | Started | deleting template. Template Id: 4186 > | 2015-07-22 06:46:18 | > | 2412523 | TEMPLATE.DELETE | Completed | Successfully completed deleting > template. Template Id: 4186 | 2015-07-22 06:46:18 | > +-+-+---+-+-+ > > You can see that the template of zone3 is not removed. > mysql> select * from template_zone_ref where template_id=4186;; > +--+-+-+-+-+-+ > > | id | zone_id | template_id | created | last_updated | removed | > +--+-+-+-+-+-+ > > | 3974 | 3 | 4186 | 2015-06-15 09:48:57 | 2015-06-15 09:48:57 | NULL | > <=Not removed > | 4845 | 1 | 4186 | 2015-07-22 04:47:08 | 2015-07-22 04:47:08 | 2015-07-22 > 06:46:18 | > +--+-+-+-+-+-+ > > However, not only Zone1 but also the charging of the template of Zone3 > stopped. > +-+-+-+-+--+---++--+-+ > > | id | start_date | end_date | zone_id | description | usage_display | > raw_usage | usage_id | size | > +-+-+-+-+--+---++--+-+ > > | 5998486 | 2015-06-14 15:00:00 | 2015-06-15 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 4.808055 Hrs | 4.808055400848389 | > 4186 | 14995087360 | > =an abbreviation > 4186 | 14995087360 | > | 7834096 | 2015-07-19 15:00:00 | 2015-07-20 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7889426 | 2015-07-20 15:00:00 | 2015-07-21 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7945799 | 2015-07-21 15:00:00 | 2015-07-22 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 15.771667 Hrs | 15.771666526794434 > | 4186 | 14995087360 | > | 7945801 | 2015-07-21 15:00:00 | 2015-07-22
[jira] [Commented] (CLOUDSTACK-9626) Instance fails to start after unsuccesful compute offering upgrade.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736185#comment-15736185 ] ASF subversion and git services commented on CLOUDSTACK-9626: - Commit 542a2112ba0315420486c975a7323c4a0aae1d53 in cloudstack's branch refs/heads/4.9 from [~sudhansu] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=542a211 ] CLOUDSTACK-9626: Instance fails to start after unsuccesful compute offering upgrade. > Instance fails to start after unsuccesful compute offering upgrade. > --- > > Key: CLOUDSTACK-9626 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9626 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.8.0 >Reporter: Sudhansu Sahu >Assignee: Sudhansu Sahu > > ISSUE > > Instance fails to start after unsuccesful compute offering upgrade. > > TROUBLESHOOTING > == > We observed VM instance get compute values "cpuNumber","cpuSpeed","memory" > removed from table "user_vm_details", which cause instance fail to startup > next time on XenServer > mysql> select * from user_vm_details where vm_id=10; > +-+---++-+-+ > | id | vm_id | name | value >| display | > +-+---++-+-+ > | 218 |10 | platform | > viridian:true;acpi:1;apic:true;pae:true;nx:true | 1 | > | 219 |10 | hypervisortoolsversion | xenserver56 >| 1 | > | 220 |10 | Message.ReservedCapacityFreed.Flag | true >| 1 | > +-+---++-+-+ > 3 rows in set (0.00 sec) > > Unexpected exception while executing > org.apache.cloudstack.api.command.user.vm.ScaleVMCmd > java.lang.NullPointerException > at > com.cloud.vm.UserVmManagerImpl.upgradeStoppedVirtualMachine(UserVmManagerImpl.java:953) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1331) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1271) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at $Proxy169.upgradeVirtualMachine(Unknown Source) > at > org.apache.cloudstack.api.command.user.vm.ScaleVMCmd.execute(ScaleVMCmd.java:127) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:167) > at > com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:97) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:543) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:50) > 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(Managed
[jira] [Commented] (CLOUDSTACK-9626) Instance fails to start after unsuccesful compute offering upgrade.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736186#comment-15736186 ] ASF subversion and git services commented on CLOUDSTACK-9626: - Commit c89198f4c65e74a27a5586e4e18b0e71b164a904 in cloudstack's branch refs/heads/4.9 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c89198f ] Merge pull request #1796 from sudhansu7/CLOUDSTACK-9626 CLOUDSTACK-9626: Instance fails to start after unsuccesful computeISSUE Instance fails to start after unsuccesful compute offering upgrade. TROUBLESHOOTING == We observed VM instance get compute values "cpuNumber","cpuSpeed","memory" removed from table "user_vm_details", which cause instance fail to startup next time on XenServer `mysql> select * from user_vm_details where vm_id=10; -- id vm_id namevalue display -- 218 10 platformviridian:true;acpi:1;apic:true;pae:true;nx:true 1 219 10 hypervisortoolsversion xenserver56 1 220 10 Message.ReservedCapacityFreed.Flag true1 -- 3 rows in set (0.00 sec)` `2016-11-29 06:49:03,667 ERROR [c.c.a.ApiAsyncJobDispatcher] (API-Job-Executor-12:ctx-49c25b1d job-125) (logid:114a2f1b) Unexpected exception while executing org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin java.lang.NullPointerException at com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1664) at com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1631) at com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1561) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy197.upgradeVirtualMachine(Unknown Source) at org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin.execute(ScaleVMCmdByAdmin.java:48) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150) at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:554) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:502) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worke
[jira] [Commented] (CLOUDSTACK-9626) Instance fails to start after unsuccesful compute offering upgrade.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736201#comment-15736201 ] ASF subversion and git services commented on CLOUDSTACK-9626: - Commit c89198f4c65e74a27a5586e4e18b0e71b164a904 in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c89198f ] Merge pull request #1796 from sudhansu7/CLOUDSTACK-9626 CLOUDSTACK-9626: Instance fails to start after unsuccesful computeISSUE Instance fails to start after unsuccesful compute offering upgrade. TROUBLESHOOTING == We observed VM instance get compute values "cpuNumber","cpuSpeed","memory" removed from table "user_vm_details", which cause instance fail to startup next time on XenServer `mysql> select * from user_vm_details where vm_id=10; -- id vm_id namevalue display -- 218 10 platformviridian:true;acpi:1;apic:true;pae:true;nx:true 1 219 10 hypervisortoolsversion xenserver56 1 220 10 Message.ReservedCapacityFreed.Flag true1 -- 3 rows in set (0.00 sec)` `2016-11-29 06:49:03,667 ERROR [c.c.a.ApiAsyncJobDispatcher] (API-Job-Executor-12:ctx-49c25b1d job-125) (logid:114a2f1b) Unexpected exception while executing org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin java.lang.NullPointerException at com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1664) at com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1631) at com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1561) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy197.upgradeVirtualMachine(Unknown Source) at org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin.execute(ScaleVMCmdByAdmin.java:48) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150) at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:554) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:502) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Wo
[jira] [Commented] (CLOUDSTACK-8908) After copying the template charging for that template is stopped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736199#comment-15736199 ] ASF subversion and git services commented on CLOUDSTACK-8908: - Commit 740179c10b6906e6c1e6016c3dd6afce46c8c74b in cloudstack's branch refs/heads/master from [~yvsubhash] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=740179c ] CLOUDSTACK-8908 After copying the template charging for that template is stopped > After copying the template charging for that template is stopped > - > > Key: CLOUDSTACK-8908 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8908 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template, Usage >Affects Versions: 4.5.2 >Reporter: subhash yedugundla > > [Repro Steps] > Register a template in Zone 1 . > Copy the template from Zone 1 to Zone 2 . > Once copied, deleted the template from Zone 1. > Check the charging of the template and found that charging of the template > in Zone 2 stopped > Sample data related to the issue > mysql> select id,type,state,description,created from event where description > like "%4186%" and type like "%template%"; > +-+-+---+-+-+ > > | id | type | state | description | created | > +-+-+---+-+-+ > > | 1964466 | TEMPLATE.CREATE | Completed | Successfully completed creating > template. Id: 4186 name: PerfTestVM2 | 2015-06-15 09:48:57 | > | 2411011 | TEMPLATE.COPY | Scheduled | copying template: 4186 from zone: 3 > to zone: 1 | 2015-07-22 03:57:32 | > | 2411012 | TEMPLATE.COPY | Started | copying template. copying template: > 4186 from zone: 3 to zone: 1 | 2015-07-22 03:57:32 | > | 2411458 | TEMPLATE.COPY | Completed | Successfully completed copying > template. copying template: 4186 from zone: 3 to zone: 1 | 2015-07-22 > 04:47:08 | > | 2412521 | TEMPLATE.DELETE | Scheduled | Deleting template 4186 | 2015-07-22 > 06:46:18 | > | 2412522 | TEMPLATE.DELETE | Started | deleting template. Template Id: 4186 > | 2015-07-22 06:46:18 | > | 2412523 | TEMPLATE.DELETE | Completed | Successfully completed deleting > template. Template Id: 4186 | 2015-07-22 06:46:18 | > +-+-+---+-+-+ > > You can see that the template of zone3 is not removed. > mysql> select * from template_zone_ref where template_id=4186;; > +--+-+-+-+-+-+ > > | id | zone_id | template_id | created | last_updated | removed | > +--+-+-+-+-+-+ > > | 3974 | 3 | 4186 | 2015-06-15 09:48:57 | 2015-06-15 09:48:57 | NULL | > <=Not removed > | 4845 | 1 | 4186 | 2015-07-22 04:47:08 | 2015-07-22 04:47:08 | 2015-07-22 > 06:46:18 | > +--+-+-+-+-+-+ > > However, not only Zone1 but also the charging of the template of Zone3 > stopped. > +-+-+-+-+--+---++--+-+ > > | id | start_date | end_date | zone_id | description | usage_display | > raw_usage | usage_id | size | > +-+-+-+-+--+---++--+-+ > > | 5998486 | 2015-06-14 15:00:00 | 2015-06-15 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 4.808055 Hrs | 4.808055400848389 | > 4186 | 14995087360 | > =an abbreviation > 4186 | 14995087360 | > | 7834096 | 2015-07-19 15:00:00 | 2015-07-20 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7889426 | 2015-07-20 15:00:00 | 2015-07-21 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7945799 | 2015-07-21 15:00:00 | 2015-07-22 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 15.771667 Hrs | 15.771666526794434 > | 4186 | 14995087360 | > | 7945801 | 2015-07-21 15:00:00 | 2015-07
[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736202#comment-15736202 ] ASF GitHub Bot commented on CLOUDSTACK-9619: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1749 @blueorangutan package > Fixes for PR 1600 > - > > Key: CLOUDSTACK-9619 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: All >Reporter: Mike Tutkowski > Fix For: 4.10.0.0 > > > In StorageSystemDataMotionStrategy.performCopyOfVdi we call > getSnapshotDetails. In one such scenario, the source snapshot in question is > coming from secondary storage (when we are creating a new volume on managed > storage from a snapshot of ours that’s on secondary storage). > This usually “worked” in the regression tests due to a bit of "luck": We > retrieve the ID of the snapshot (which is on secondary storage) and then try > to pull out its StorageVO object (which is for primary storage). If you > happen to have a primary storage that matches the ID (which is the ID of a > secondary storage), then getSnapshotDetails populates its Map > with inapplicable data (that is later ignored) and you don’t easily see a > problem. However, if you don’t have a primary storage that matches that ID > (which I didn’t today because I had removed that primary storage), then a > NullPointerException is thrown. > I have fixed that issue by skipping getSnapshotDetails if the source is > coming from secondary storage. > While fixing that, I noticed a couple more problems: > We can invoke grantAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > We can invoke revokeAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > I have corrected those issues, as well. > I then came across one more problem: > · When using a SAN snapshot and copying it to secondary storage or creating a > new managed-storage volume from a snapshot of ours on secondary storage, we > attach to the SR in the XenServer code, but detach from it in the > StorageSystemDataMotionStrategy code (by sending a message to the XenServer > code to perform an SR detach). Since we know to detach from the SR after the > copy is done, we should detach from the SR in the XenServer code (without > that code having to be explicitly called from outside of the XenServer logic). > I went ahead and changed that, as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9626) Instance fails to start after unsuccesful compute offering upgrade.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736200#comment-15736200 ] ASF subversion and git services commented on CLOUDSTACK-9626: - Commit 542a2112ba0315420486c975a7323c4a0aae1d53 in cloudstack's branch refs/heads/master from [~sudhansu] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=542a211 ] CLOUDSTACK-9626: Instance fails to start after unsuccesful compute offering upgrade. > Instance fails to start after unsuccesful compute offering upgrade. > --- > > Key: CLOUDSTACK-9626 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9626 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.8.0 >Reporter: Sudhansu Sahu >Assignee: Sudhansu Sahu > > ISSUE > > Instance fails to start after unsuccesful compute offering upgrade. > > TROUBLESHOOTING > == > We observed VM instance get compute values "cpuNumber","cpuSpeed","memory" > removed from table "user_vm_details", which cause instance fail to startup > next time on XenServer > mysql> select * from user_vm_details where vm_id=10; > +-+---++-+-+ > | id | vm_id | name | value >| display | > +-+---++-+-+ > | 218 |10 | platform | > viridian:true;acpi:1;apic:true;pae:true;nx:true | 1 | > | 219 |10 | hypervisortoolsversion | xenserver56 >| 1 | > | 220 |10 | Message.ReservedCapacityFreed.Flag | true >| 1 | > +-+---++-+-+ > 3 rows in set (0.00 sec) > > Unexpected exception while executing > org.apache.cloudstack.api.command.user.vm.ScaleVMCmd > java.lang.NullPointerException > at > com.cloud.vm.UserVmManagerImpl.upgradeStoppedVirtualMachine(UserVmManagerImpl.java:953) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1331) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1271) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at $Proxy169.upgradeVirtualMachine(Unknown Source) > at > org.apache.cloudstack.api.command.user.vm.ScaleVMCmd.execute(ScaleVMCmd.java:127) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:167) > at > com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:97) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:543) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:50) > 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(Mana
[jira] [Commented] (CLOUDSTACK-8908) After copying the template charging for that template is stopped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736208#comment-15736208 ] ASF subversion and git services commented on CLOUDSTACK-8908: - Commit a13ee852af55be346ab836cdf3fc9fb630eb75fc in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a13ee85 ] Merge pull request #896 from yvsubhash/CLOUDSTACK-8908 CLOUDSTACK-8908 After copying the template charging for that template is getting stoppedThis is happening as the zone id is not part of the query. Zone id is added to the query and unit tests are also added * pr/896: CLOUDSTACK-8908 After copying the template charging for that template is stopped Signed-off-by: Rohit Yadav > After copying the template charging for that template is stopped > - > > Key: CLOUDSTACK-8908 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8908 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template, Usage >Affects Versions: 4.5.2 >Reporter: subhash yedugundla > > [Repro Steps] > Register a template in Zone 1 . > Copy the template from Zone 1 to Zone 2 . > Once copied, deleted the template from Zone 1. > Check the charging of the template and found that charging of the template > in Zone 2 stopped > Sample data related to the issue > mysql> select id,type,state,description,created from event where description > like "%4186%" and type like "%template%"; > +-+-+---+-+-+ > > | id | type | state | description | created | > +-+-+---+-+-+ > > | 1964466 | TEMPLATE.CREATE | Completed | Successfully completed creating > template. Id: 4186 name: PerfTestVM2 | 2015-06-15 09:48:57 | > | 2411011 | TEMPLATE.COPY | Scheduled | copying template: 4186 from zone: 3 > to zone: 1 | 2015-07-22 03:57:32 | > | 2411012 | TEMPLATE.COPY | Started | copying template. copying template: > 4186 from zone: 3 to zone: 1 | 2015-07-22 03:57:32 | > | 2411458 | TEMPLATE.COPY | Completed | Successfully completed copying > template. copying template: 4186 from zone: 3 to zone: 1 | 2015-07-22 > 04:47:08 | > | 2412521 | TEMPLATE.DELETE | Scheduled | Deleting template 4186 | 2015-07-22 > 06:46:18 | > | 2412522 | TEMPLATE.DELETE | Started | deleting template. Template Id: 4186 > | 2015-07-22 06:46:18 | > | 2412523 | TEMPLATE.DELETE | Completed | Successfully completed deleting > template. Template Id: 4186 | 2015-07-22 06:46:18 | > +-+-+---+-+-+ > > You can see that the template of zone3 is not removed. > mysql> select * from template_zone_ref where template_id=4186;; > +--+-+-+-+-+-+ > > | id | zone_id | template_id | created | last_updated | removed | > +--+-+-+-+-+-+ > > | 3974 | 3 | 4186 | 2015-06-15 09:48:57 | 2015-06-15 09:48:57 | NULL | > <=Not removed > | 4845 | 1 | 4186 | 2015-07-22 04:47:08 | 2015-07-22 04:47:08 | 2015-07-22 > 06:46:18 | > +--+-+-+-+-+-+ > > However, not only Zone1 but also the charging of the template of Zone3 > stopped. > +-+-+-+-+--+---++--+-+ > > | id | start_date | end_date | zone_id | description | usage_display | > raw_usage | usage_id | size | > +-+-+-+-+--+---++--+-+ > > | 5998486 | 2015-06-14 15:00:00 | 2015-06-15 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 4.808055 Hrs | 4.808055400848389 | > 4186 | 14995087360 | > =an abbreviation > 4186 | 14995087360 | > | 7834096 | 2015-07-19 15:00:00 | 2015-07-20 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7889426 | 2015-07-20 15:00:00 | 2015-07-21 14:59:59 | 3 | Te
[jira] [Commented] (CLOUDSTACK-8908) After copying the template charging for that template is stopped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736206#comment-15736206 ] ASF subversion and git services commented on CLOUDSTACK-8908: - Commit a13ee852af55be346ab836cdf3fc9fb630eb75fc in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a13ee85 ] Merge pull request #896 from yvsubhash/CLOUDSTACK-8908 CLOUDSTACK-8908 After copying the template charging for that template is getting stoppedThis is happening as the zone id is not part of the query. Zone id is added to the query and unit tests are also added * pr/896: CLOUDSTACK-8908 After copying the template charging for that template is stopped Signed-off-by: Rohit Yadav > After copying the template charging for that template is stopped > - > > Key: CLOUDSTACK-8908 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8908 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template, Usage >Affects Versions: 4.5.2 >Reporter: subhash yedugundla > > [Repro Steps] > Register a template in Zone 1 . > Copy the template from Zone 1 to Zone 2 . > Once copied, deleted the template from Zone 1. > Check the charging of the template and found that charging of the template > in Zone 2 stopped > Sample data related to the issue > mysql> select id,type,state,description,created from event where description > like "%4186%" and type like "%template%"; > +-+-+---+-+-+ > > | id | type | state | description | created | > +-+-+---+-+-+ > > | 1964466 | TEMPLATE.CREATE | Completed | Successfully completed creating > template. Id: 4186 name: PerfTestVM2 | 2015-06-15 09:48:57 | > | 2411011 | TEMPLATE.COPY | Scheduled | copying template: 4186 from zone: 3 > to zone: 1 | 2015-07-22 03:57:32 | > | 2411012 | TEMPLATE.COPY | Started | copying template. copying template: > 4186 from zone: 3 to zone: 1 | 2015-07-22 03:57:32 | > | 2411458 | TEMPLATE.COPY | Completed | Successfully completed copying > template. copying template: 4186 from zone: 3 to zone: 1 | 2015-07-22 > 04:47:08 | > | 2412521 | TEMPLATE.DELETE | Scheduled | Deleting template 4186 | 2015-07-22 > 06:46:18 | > | 2412522 | TEMPLATE.DELETE | Started | deleting template. Template Id: 4186 > | 2015-07-22 06:46:18 | > | 2412523 | TEMPLATE.DELETE | Completed | Successfully completed deleting > template. Template Id: 4186 | 2015-07-22 06:46:18 | > +-+-+---+-+-+ > > You can see that the template of zone3 is not removed. > mysql> select * from template_zone_ref where template_id=4186;; > +--+-+-+-+-+-+ > > | id | zone_id | template_id | created | last_updated | removed | > +--+-+-+-+-+-+ > > | 3974 | 3 | 4186 | 2015-06-15 09:48:57 | 2015-06-15 09:48:57 | NULL | > <=Not removed > | 4845 | 1 | 4186 | 2015-07-22 04:47:08 | 2015-07-22 04:47:08 | 2015-07-22 > 06:46:18 | > +--+-+-+-+-+-+ > > However, not only Zone1 but also the charging of the template of Zone3 > stopped. > +-+-+-+-+--+---++--+-+ > > | id | start_date | end_date | zone_id | description | usage_display | > raw_usage | usage_id | size | > +-+-+-+-+--+---++--+-+ > > | 5998486 | 2015-06-14 15:00:00 | 2015-06-15 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 4.808055 Hrs | 4.808055400848389 | > 4186 | 14995087360 | > =an abbreviation > 4186 | 14995087360 | > | 7834096 | 2015-07-19 15:00:00 | 2015-07-20 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7889426 | 2015-07-20 15:00:00 | 2015-07-21 14:59:59 | 3 | Te
[jira] [Commented] (CLOUDSTACK-9626) Instance fails to start after unsuccesful compute offering upgrade.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736204#comment-15736204 ] ASF subversion and git services commented on CLOUDSTACK-9626: - Commit c89198f4c65e74a27a5586e4e18b0e71b164a904 in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c89198f ] Merge pull request #1796 from sudhansu7/CLOUDSTACK-9626 CLOUDSTACK-9626: Instance fails to start after unsuccesful computeISSUE Instance fails to start after unsuccesful compute offering upgrade. TROUBLESHOOTING == We observed VM instance get compute values "cpuNumber","cpuSpeed","memory" removed from table "user_vm_details", which cause instance fail to startup next time on XenServer `mysql> select * from user_vm_details where vm_id=10; -- id vm_id namevalue display -- 218 10 platformviridian:true;acpi:1;apic:true;pae:true;nx:true 1 219 10 hypervisortoolsversion xenserver56 1 220 10 Message.ReservedCapacityFreed.Flag true1 -- 3 rows in set (0.00 sec)` `2016-11-29 06:49:03,667 ERROR [c.c.a.ApiAsyncJobDispatcher] (API-Job-Executor-12:ctx-49c25b1d job-125) (logid:114a2f1b) Unexpected exception while executing org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin java.lang.NullPointerException at com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1664) at com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1631) at com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1561) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy197.upgradeVirtualMachine(Unknown Source) at org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin.execute(ScaleVMCmdByAdmin.java:48) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150) at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:554) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:502) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Wo
[jira] [Commented] (CLOUDSTACK-9626) Instance fails to start after unsuccesful compute offering upgrade.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736203#comment-15736203 ] ASF subversion and git services commented on CLOUDSTACK-9626: - Commit c89198f4c65e74a27a5586e4e18b0e71b164a904 in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c89198f ] Merge pull request #1796 from sudhansu7/CLOUDSTACK-9626 CLOUDSTACK-9626: Instance fails to start after unsuccesful computeISSUE Instance fails to start after unsuccesful compute offering upgrade. TROUBLESHOOTING == We observed VM instance get compute values "cpuNumber","cpuSpeed","memory" removed from table "user_vm_details", which cause instance fail to startup next time on XenServer `mysql> select * from user_vm_details where vm_id=10; -- id vm_id namevalue display -- 218 10 platformviridian:true;acpi:1;apic:true;pae:true;nx:true 1 219 10 hypervisortoolsversion xenserver56 1 220 10 Message.ReservedCapacityFreed.Flag true1 -- 3 rows in set (0.00 sec)` `2016-11-29 06:49:03,667 ERROR [c.c.a.ApiAsyncJobDispatcher] (API-Job-Executor-12:ctx-49c25b1d job-125) (logid:114a2f1b) Unexpected exception while executing org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin java.lang.NullPointerException at com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1664) at com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1631) at com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1561) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy197.upgradeVirtualMachine(Unknown Source) at org.apache.cloudstack.api.command.admin.vm.ScaleVMCmdByAdmin.execute(ScaleVMCmdByAdmin.java:48) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150) at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:554) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:502) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Wo
[jira] [Commented] (CLOUDSTACK-8908) After copying the template charging for that template is stopped
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736205#comment-15736205 ] ASF subversion and git services commented on CLOUDSTACK-8908: - Commit a13ee852af55be346ab836cdf3fc9fb630eb75fc in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a13ee85 ] Merge pull request #896 from yvsubhash/CLOUDSTACK-8908 CLOUDSTACK-8908 After copying the template charging for that template is getting stoppedThis is happening as the zone id is not part of the query. Zone id is added to the query and unit tests are also added * pr/896: CLOUDSTACK-8908 After copying the template charging for that template is stopped Signed-off-by: Rohit Yadav > After copying the template charging for that template is stopped > - > > Key: CLOUDSTACK-8908 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8908 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template, Usage >Affects Versions: 4.5.2 >Reporter: subhash yedugundla > > [Repro Steps] > Register a template in Zone 1 . > Copy the template from Zone 1 to Zone 2 . > Once copied, deleted the template from Zone 1. > Check the charging of the template and found that charging of the template > in Zone 2 stopped > Sample data related to the issue > mysql> select id,type,state,description,created from event where description > like "%4186%" and type like "%template%"; > +-+-+---+-+-+ > > | id | type | state | description | created | > +-+-+---+-+-+ > > | 1964466 | TEMPLATE.CREATE | Completed | Successfully completed creating > template. Id: 4186 name: PerfTestVM2 | 2015-06-15 09:48:57 | > | 2411011 | TEMPLATE.COPY | Scheduled | copying template: 4186 from zone: 3 > to zone: 1 | 2015-07-22 03:57:32 | > | 2411012 | TEMPLATE.COPY | Started | copying template. copying template: > 4186 from zone: 3 to zone: 1 | 2015-07-22 03:57:32 | > | 2411458 | TEMPLATE.COPY | Completed | Successfully completed copying > template. copying template: 4186 from zone: 3 to zone: 1 | 2015-07-22 > 04:47:08 | > | 2412521 | TEMPLATE.DELETE | Scheduled | Deleting template 4186 | 2015-07-22 > 06:46:18 | > | 2412522 | TEMPLATE.DELETE | Started | deleting template. Template Id: 4186 > | 2015-07-22 06:46:18 | > | 2412523 | TEMPLATE.DELETE | Completed | Successfully completed deleting > template. Template Id: 4186 | 2015-07-22 06:46:18 | > +-+-+---+-+-+ > > You can see that the template of zone3 is not removed. > mysql> select * from template_zone_ref where template_id=4186;; > +--+-+-+-+-+-+ > > | id | zone_id | template_id | created | last_updated | removed | > +--+-+-+-+-+-+ > > | 3974 | 3 | 4186 | 2015-06-15 09:48:57 | 2015-06-15 09:48:57 | NULL | > <=Not removed > | 4845 | 1 | 4186 | 2015-07-22 04:47:08 | 2015-07-22 04:47:08 | 2015-07-22 > 06:46:18 | > +--+-+-+-+-+-+ > > However, not only Zone1 but also the charging of the template of Zone3 > stopped. > +-+-+-+-+--+---++--+-+ > > | id | start_date | end_date | zone_id | description | usage_display | > raw_usage | usage_id | size | > +-+-+-+-+--+---++--+-+ > > | 5998486 | 2015-06-14 15:00:00 | 2015-06-15 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 4.808055 Hrs | 4.808055400848389 | > 4186 | 14995087360 | > =an abbreviation > 4186 | 14995087360 | > | 7834096 | 2015-07-19 15:00:00 | 2015-07-20 14:59:59 | 3 | Template Id:4186 > Size:14995087360VirtualSize:16106127360 | 24 Hrs | 24 | 4186 | 14995087360 | > | 7889426 | 2015-07-20 15:00:00 | 2015-07-21 14:59:59 | 3 | Te
[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736207#comment-15736207 ] ASF GitHub Bot commented on CLOUDSTACK-9619: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1749 @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. > Fixes for PR 1600 > - > > Key: CLOUDSTACK-9619 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: All >Reporter: Mike Tutkowski > Fix For: 4.10.0.0 > > > In StorageSystemDataMotionStrategy.performCopyOfVdi we call > getSnapshotDetails. In one such scenario, the source snapshot in question is > coming from secondary storage (when we are creating a new volume on managed > storage from a snapshot of ours that’s on secondary storage). > This usually “worked” in the regression tests due to a bit of "luck": We > retrieve the ID of the snapshot (which is on secondary storage) and then try > to pull out its StorageVO object (which is for primary storage). If you > happen to have a primary storage that matches the ID (which is the ID of a > secondary storage), then getSnapshotDetails populates its Map > with inapplicable data (that is later ignored) and you don’t easily see a > problem. However, if you don’t have a primary storage that matches that ID > (which I didn’t today because I had removed that primary storage), then a > NullPointerException is thrown. > I have fixed that issue by skipping getSnapshotDetails if the source is > coming from secondary storage. > While fixing that, I noticed a couple more problems: > We can invoke grantAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > We can invoke revokeAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > I have corrected those issues, as well. > I then came across one more problem: > · When using a SAN snapshot and copying it to secondary storage or creating a > new managed-storage volume from a snapshot of ours on secondary storage, we > attach to the SR in the XenServer code, but detach from it in the > StorageSystemDataMotionStrategy code (by sending a message to the XenServer > code to perform an SR detach). Since we know to detach from the SR after the > copy is done, we should detach from the SR in the XenServer code (without > that code having to be explicitly called from outside of the XenServer logic). > I went ahead and changed that, as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736220#comment-15736220 ] ASF GitHub Bot commented on CLOUDSTACK-9619: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1749 @blueorangutan test centos7 xenserver-65sp1 > Fixes for PR 1600 > - > > Key: CLOUDSTACK-9619 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: All >Reporter: Mike Tutkowski > Fix For: 4.10.0.0 > > > In StorageSystemDataMotionStrategy.performCopyOfVdi we call > getSnapshotDetails. In one such scenario, the source snapshot in question is > coming from secondary storage (when we are creating a new volume on managed > storage from a snapshot of ours that’s on secondary storage). > This usually “worked” in the regression tests due to a bit of "luck": We > retrieve the ID of the snapshot (which is on secondary storage) and then try > to pull out its StorageVO object (which is for primary storage). If you > happen to have a primary storage that matches the ID (which is the ID of a > secondary storage), then getSnapshotDetails populates its Map > with inapplicable data (that is later ignored) and you don’t easily see a > problem. However, if you don’t have a primary storage that matches that ID > (which I didn’t today because I had removed that primary storage), then a > NullPointerException is thrown. > I have fixed that issue by skipping getSnapshotDetails if the source is > coming from secondary storage. > While fixing that, I noticed a couple more problems: > We can invoke grantAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > We can invoke revokeAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > I have corrected those issues, as well. > I then came across one more problem: > · When using a SAN snapshot and copying it to secondary storage or creating a > new managed-storage volume from a snapshot of ours on secondary storage, we > attach to the SR in the XenServer code, but detach from it in the > StorageSystemDataMotionStrategy code (by sending a message to the XenServer > code to perform an SR detach). Since we know to detach from the SR after the > copy is done, we should detach from the SR in the XenServer code (without > that code having to be explicitly called from outside of the XenServer logic). > I went ahead and changed that, as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736221#comment-15736221 ] ASF GitHub Bot commented on CLOUDSTACK-9619: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1749 @rhtyd a Trillian-Jenkins test job (centos7 mgmt + xenserver-65sp1) has been kicked to run smoke tests > Fixes for PR 1600 > - > > Key: CLOUDSTACK-9619 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: All >Reporter: Mike Tutkowski > Fix For: 4.10.0.0 > > > In StorageSystemDataMotionStrategy.performCopyOfVdi we call > getSnapshotDetails. In one such scenario, the source snapshot in question is > coming from secondary storage (when we are creating a new volume on managed > storage from a snapshot of ours that’s on secondary storage). > This usually “worked” in the regression tests due to a bit of "luck": We > retrieve the ID of the snapshot (which is on secondary storage) and then try > to pull out its StorageVO object (which is for primary storage). If you > happen to have a primary storage that matches the ID (which is the ID of a > secondary storage), then getSnapshotDetails populates its Map > with inapplicable data (that is later ignored) and you don’t easily see a > problem. However, if you don’t have a primary storage that matches that ID > (which I didn’t today because I had removed that primary storage), then a > NullPointerException is thrown. > I have fixed that issue by skipping getSnapshotDetails if the source is > coming from secondary storage. > While fixing that, I noticed a couple more problems: > We can invoke grantAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > We can invoke revokeAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > I have corrected those issues, as well. > I then came across one more problem: > · When using a SAN snapshot and copying it to secondary storage or creating a > new managed-storage volume from a snapshot of ours on secondary storage, we > attach to the SR in the XenServer code, but detach from it in the > StorageSystemDataMotionStrategy code (by sending a message to the XenServer > code to perform an SR detach). Since we know to detach from the SR after the > copy is done, we should detach from the SR in the XenServer code (without > that code having to be explicitly called from outside of the XenServer logic). > I went ahead and changed that, as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9662) Adding XenServer 7 support to Cloudstack
Syed Ahmed created CLOUDSTACK-9662: -- Summary: Adding XenServer 7 support to Cloudstack Key: CLOUDSTACK-9662 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9662 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.9.0.1, Future, 4.10.0.0 Reporter: Syed Ahmed This Bug is to track XenServer 7 support in Cloudstack. The PR can be found at https://github.com/apache/cloudstack/pull/1711 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9628) Fix Template Size in Swift as Secondary Storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736315#comment-15736315 ] ASF GitHub Bot commented on CLOUDSTACK-9628: Github user syed commented on the issue: https://github.com/apache/cloudstack/pull/1770 @jburwell Rebased against 4.9. > Fix Template Size in Swift as Secondary Storage > --- > > Key: CLOUDSTACK-9628 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9628 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.9.0, Future >Reporter: Syed Ahmed > > Cloudstack incorrectly uses the physical size as the size of the > template. Ideally, the size should refelct the virtual size. This > PR fixes that issue. > https://github.com/apache/cloudstack/pull/1770 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736330#comment-15736330 ] ASF GitHub Bot commented on CLOUDSTACK-9619: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1749 Packaging result: ✔centos6 ✔centos7 ✖debian. JID-377 > Fixes for PR 1600 > - > > Key: CLOUDSTACK-9619 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: All >Reporter: Mike Tutkowski > Fix For: 4.10.0.0 > > > In StorageSystemDataMotionStrategy.performCopyOfVdi we call > getSnapshotDetails. In one such scenario, the source snapshot in question is > coming from secondary storage (when we are creating a new volume on managed > storage from a snapshot of ours that’s on secondary storage). > This usually “worked” in the regression tests due to a bit of "luck": We > retrieve the ID of the snapshot (which is on secondary storage) and then try > to pull out its StorageVO object (which is for primary storage). If you > happen to have a primary storage that matches the ID (which is the ID of a > secondary storage), then getSnapshotDetails populates its Map > with inapplicable data (that is later ignored) and you don’t easily see a > problem. However, if you don’t have a primary storage that matches that ID > (which I didn’t today because I had removed that primary storage), then a > NullPointerException is thrown. > I have fixed that issue by skipping getSnapshotDetails if the source is > coming from secondary storage. > While fixing that, I noticed a couple more problems: > We can invoke grantAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > We can invoke revokeAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > I have corrected those issues, as well. > I then came across one more problem: > · When using a SAN snapshot and copying it to secondary storage or creating a > new managed-storage volume from a snapshot of ours on secondary storage, we > attach to the SR in the XenServer code, but detach from it in the > StorageSystemDataMotionStrategy code (by sending a message to the XenServer > code to perform an SR detach). Since we know to detach from the SR after the > copy is done, we should detach from the SR in the XenServer code (without > that code having to be explicitly called from outside of the XenServer logic). > I went ahead and changed that, as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736334#comment-15736334 ] ASF GitHub Bot commented on CLOUDSTACK-9619: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1749 @blueorangutan test > Fixes for PR 1600 > - > > Key: CLOUDSTACK-9619 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: All >Reporter: Mike Tutkowski > Fix For: 4.10.0.0 > > > In StorageSystemDataMotionStrategy.performCopyOfVdi we call > getSnapshotDetails. In one such scenario, the source snapshot in question is > coming from secondary storage (when we are creating a new volume on managed > storage from a snapshot of ours that’s on secondary storage). > This usually “worked” in the regression tests due to a bit of "luck": We > retrieve the ID of the snapshot (which is on secondary storage) and then try > to pull out its StorageVO object (which is for primary storage). If you > happen to have a primary storage that matches the ID (which is the ID of a > secondary storage), then getSnapshotDetails populates its Map > with inapplicable data (that is later ignored) and you don’t easily see a > problem. However, if you don’t have a primary storage that matches that ID > (which I didn’t today because I had removed that primary storage), then a > NullPointerException is thrown. > I have fixed that issue by skipping getSnapshotDetails if the source is > coming from secondary storage. > While fixing that, I noticed a couple more problems: > We can invoke grantAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > We can invoke revokeAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > I have corrected those issues, as well. > I then came across one more problem: > · When using a SAN snapshot and copying it to secondary storage or creating a > new managed-storage volume from a snapshot of ours on secondary storage, we > attach to the SR in the XenServer code, but detach from it in the > StorageSystemDataMotionStrategy code (by sending a message to the XenServer > code to perform an SR detach). Since we know to detach from the SR after the > copy is done, we should detach from the SR in the XenServer code (without > that code having to be explicitly called from outside of the XenServer logic). > I went ahead and changed that, as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9619) Fixes for PR 1600
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15736336#comment-15736336 ] ASF GitHub Bot commented on CLOUDSTACK-9619: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/1749 @rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests > Fixes for PR 1600 > - > > Key: CLOUDSTACK-9619 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9619 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: All >Reporter: Mike Tutkowski > Fix For: 4.10.0.0 > > > In StorageSystemDataMotionStrategy.performCopyOfVdi we call > getSnapshotDetails. In one such scenario, the source snapshot in question is > coming from secondary storage (when we are creating a new volume on managed > storage from a snapshot of ours that’s on secondary storage). > This usually “worked” in the regression tests due to a bit of "luck": We > retrieve the ID of the snapshot (which is on secondary storage) and then try > to pull out its StorageVO object (which is for primary storage). If you > happen to have a primary storage that matches the ID (which is the ID of a > secondary storage), then getSnapshotDetails populates its Map > with inapplicable data (that is later ignored) and you don’t easily see a > problem. However, if you don’t have a primary storage that matches that ID > (which I didn’t today because I had removed that primary storage), then a > NullPointerException is thrown. > I have fixed that issue by skipping getSnapshotDetails if the source is > coming from secondary storage. > While fixing that, I noticed a couple more problems: > We can invoke grantAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > We can invoke revokeAccess on a snapshot that’s actually on secondary > storage (this doesn’t amount to much because the VolumeServiceImpl ignores > the call when it’s not for a primary-storage driver). > I have corrected those issues, as well. > I then came across one more problem: > · When using a SAN snapshot and copying it to secondary storage or creating a > new managed-storage volume from a snapshot of ours on secondary storage, we > attach to the SR in the XenServer code, but detach from it in the > StorageSystemDataMotionStrategy code (by sending a message to the XenServer > code to perform an SR detach). Since we know to detach from the SR after the > copy is done, we should detach from the SR in the XenServer code (without > that code having to be explicitly called from outside of the XenServer logic). > I went ahead and changed that, as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9663) updateRole should return updated role as json
René Moser created CLOUDSTACK-9663: -- Summary: updateRole should return updated role as json Key: CLOUDSTACK-9663 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9663 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.9.0 Reporter: René Moser Priority: Trivial Fix For: Future updateRole does currently only return success but one would expect it returns the updated role as json like other update APIs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9664) updateRole: type can not be changed
René Moser created CLOUDSTACK-9664: -- Summary: updateRole: type can not be changed Key: CLOUDSTACK-9664 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9664 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API, Doc Affects Versions: 4.9.0 Reporter: René Moser Priority: Trivial Fix For: Future Type can not be changed but documentation says so https://cloudstack.apache.org/api/apidocs-4.9/apis/updateRole.html update the docs or allow type to be changed -- This message was sent by Atlassian JIRA (v6.3.4#6332)
