[jira] [Commented] (CLOUDSTACK-9503) The router script times out resulting in failure of deployment

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682834#comment-15682834
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9503:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1745
  
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been 
kicked to run smoke tests


> The router script times out resulting in failure of deployment
> --
>
> Key: CLOUDSTACK-9503
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9503
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.0
> Environment: KVM, Xen
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.1.0
>
>
> When starting the virtual router in a shared network in advance zone the 
> scripts on router time out. This happen as there are several sub-commands 
> that are consolidated in a single command. The default timeout of 2 minutes 
> is short.
> 2016-09-09 00:06:25,016 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) process hasn't exited
> 2016-09-09 00:06:25,016 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) Command: com.cloud.agent.api.Command failed while starting 
> virtual router
> 2016-09-09 00:06:25,016 INFO [c.c.v.VirtualMachineManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) The guru did not like the answers so stopping 
> VM[DomainRouter|r-3445-VM]
> —



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

[jira] [Commented] (CLOUDSTACK-9503) The router script times out resulting in failure of deployment

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682830#comment-15682830
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9503:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1745
  
@blueorangutan test


> The router script times out resulting in failure of deployment
> --
>
> Key: CLOUDSTACK-9503
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9503
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.9.0
> Environment: KVM, Xen
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.9.1.0
>
>
> When starting the virtual router in a shared network in advance zone the 
> scripts on router time out. This happen as there are several sub-commands 
> that are consolidated in a single command. The default timeout of 2 minutes 
> is short.
> 2016-09-09 00:06:25,016 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) process hasn't exited
> 2016-09-09 00:06:25,016 WARN [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) Command: com.cloud.agent.api.Command failed while starting 
> virtual router
> 2016-09-09 00:06:25,016 INFO [c.c.v.VirtualMachineManagerImpl] 
> (Work-Job-Executor-110:ctx-e8089ec7 job-5135/job-5137 ctx-c3a8da18) 
> (logid:8aedea66) The guru did not like the answers so stopping 
> VM[DomainRouter|r-3445-VM]
> —



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

[jira] [Commented] (CLOUDSTACK-9489) When upgrading, Config.java new configuration are not updated.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682831#comment-15682831
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9489:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1684
  
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been 
kicked to run smoke tests


> When upgrading, Config.java new configuration are not updated.
> --
>
> Key: CLOUDSTACK-9489
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9489
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>Priority: Blocker
>
> When Upgrading CloudStack, new configurations (Global Settings) defined in  
> {{server/src/com/cloud/configuration/Config.java}} are not populated.
> This file changed in 4.5 and 4.6 and those configurations are not applied 
> when upgrading to post 4.6.



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

[jira] [Commented] (CLOUDSTACK-9491) Vmware resource: incorrect parsing of device list to find ethener index of plugged nic

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682832#comment-15682832
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9491:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1681
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> Vmware resource: incorrect parsing of device list to find ethener index of 
> plugged nic
> --
>
> Key: CLOUDSTACK-9491
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9491
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Murali Reddy
>Assignee: Murali Reddy
> Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0
>
>
> In VmwareResource.java, there is logic ( in findRouterEthDeviceIndex) to find 
> ethernet interface a mac address is associated with.
> After NIC in plugged in to a Vm through vSphere, it takes some time for the 
> device to show up in the guest VM.
> Logic loops through the device list obtained from /proc/sys/net/ipv4/conf 
> from the VM, and matched againest mac.
> However '/proc/sys/net/ipv4/conf'  is not refreshed, heve logic loops through 
> old device list always.
> In addition there is no exception thrown and error is maked by sending -1. 
> Eventually, VR scripts are getting -1 as device number causing failure in 
> processing the scripts.



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

[jira] [Commented] (CLOUDSTACK-9489) When upgrading, Config.java new configuration are not updated.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682829#comment-15682829
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9489:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1684
  
@blueorangutan test


> When upgrading, Config.java new configuration are not updated.
> --
>
> Key: CLOUDSTACK-9489
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9489
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>Priority: Blocker
>
> When Upgrading CloudStack, new configurations (Global Settings) defined in  
> {{server/src/com/cloud/configuration/Config.java}} are not populated.
> This file changed in 4.5 and 4.6 and those configurations are not applied 
> when upgrading to post 4.6.



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

[jira] [Commented] (CLOUDSTACK-9491) Vmware resource: incorrect parsing of device list to find ethener index of plugged nic

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682825#comment-15682825
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9491:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1681
  
LGTM on tests, the failures wrt VPC are known intermittent issues. I'm not 
sure about the internal lb failures, I'll kick another test round since there 
have been several changes on the base branch. 

@blueorangutan package


> Vmware resource: incorrect parsing of device list to find ethener index of 
> plugged nic
> --
>
> Key: CLOUDSTACK-9491
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9491
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
>Reporter: Murali Reddy
>Assignee: Murali Reddy
> Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0
>
>
> In VmwareResource.java, there is logic ( in findRouterEthDeviceIndex) to find 
> ethernet interface a mac address is associated with.
> After NIC in plugged in to a Vm through vSphere, it takes some time for the 
> device to show up in the guest VM.
> Logic loops through the device list obtained from /proc/sys/net/ipv4/conf 
> from the VM, and matched againest mac.
> However '/proc/sys/net/ipv4/conf'  is not refreshed, heve logic loops through 
> old device list always.
> In addition there is no exception thrown and error is maked by sending -1. 
> Eventually, VR scripts are getting -1 as device number causing failure in 
> processing the scripts.



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

[jira] [Commented] (CLOUDSTACK-9321) Multiple Internal LB rules (more than one Internal LB rule with same source IP address) are not getting resolved in the corresponding InternalLbVm instance's hapro

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682823#comment-15682823
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9321:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1577
  
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been 
kicked to run smoke tests


> Multiple Internal LB rules (more than one Internal LB rule with same source 
> IP address) are not getting resolved in the corresponding InternalLbVm 
> instance's haproxy.cfg file
> --
>
> Key: CLOUDSTACK-9321
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9321
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Network Controller
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
>Priority: Critical
> Fix For: 4.9.1.0
>
>
> Multiple Internal LB rules (more than one Internal LB rule with same source 
> IP address) are not getting resolved in the corresponding InternalLbVm 
> instance's haproxy.cfg file. Moreover, each time a new Internal LB rule is 
> added to the corresponding InternalLbVm instance, it replaces the existing 
> one. Thus, traffic corresponding to these un-resolved (old) Internal LB rules 
> are getting dropped by the InternalLbVm instance.
> PR contents:
> 1) Fix for this bug.
> 2) Marvin test coverage for Internal LB feature on master with native ACS 
> setup (component directory) including validations for this bug fix.
> 3) Enhancements on our exiting Internal LB Marvin test code (nuagevsp plugins 
> directory) to validate this bug fix.
> 4) PEP8 & PyFlakes compliance with the added Marvin test code.
> Added Marvin test code PEP8 & PyFlakes compliance:
> CloudStack$
> CloudStack$ pep8 --max-line-length=150 
> test/integration/component/test_vpc_network_internal_lbrules.py
> CloudStack$
> CloudStack$ pyflakes 
> test/integration/component/test_vpc_network_internal_lbrules.py
> CloudStack$
> CloudStack$ pep8 --max-line-length=150 test/integration/plugins/nuagevsp/.py
> CloudStack$
> CloudStack$ pyflakes test/integration/plugins/nuagevsp/.py
> CloudStack$
> Validations:
> 1) Made sure that we didn't break any Public LB (VpcVirtualRouter) 
> functionality.
> Marvin test run:
> nosetests --with-marvin --marvin-config=nuage.cfg 
> test/integration/component/test_vpc_network_lbrules.py
> Test results:
> Test case no 210 and 227: List Load Balancing Rules belonging to a VPC ... 
> === TestName: test_01_VPC_LBRulesListing | Status : SUCCESS ===
> ok
> Test Create LB rules for 1 network which is part of a two/multiple virtual 
> networks of a ... === TestName: test_02_VPC_CreateLBRuleInMultipleNetworks | 
> Status : SUCCESS ===
> ok
> Test case no 222 : Create LB rules for a two/multiple virtual networks of a 
> ... === TestName: test_03_VPC_CreateLBRuleInMultipleNetworksVRStoppedState | 
> Status : SUCCESS ===
> ok
> Test case no 222 : Create LB rules for a two/multiple virtual networks of a 
> ... === TestName: test_04_VPC_CreateLBRuleInMultipleNetworksVRStoppedState | 
> Status : SUCCESS ===
> ok
> Test case no 214 : Delete few(not all) LB rules for a single virtual network 
> of a ... === TestName: test_05_VPC_CreateAndDeleteLBRule | Status : SUCCESS 
> ===
> ok
> Test Delete few(not all) LB rules for a single virtual network of ... === 
> TestName: test_06_VPC_CreateAndDeleteLBRuleVRStopppedState | Status : SUCCESS 
> ===
> ok
> Test Delete all LB rules for a single virtual network of a ... === TestName: 
> test_07_VPC_CreateAndDeleteAllLBRule | Status : SUCCESS ===
> ok
> Test Delete all LB rules for a single virtual network of a ... === TestName: 
> test_08_VPC_CreateAndDeleteAllLBRuleVRStoppedState | Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule for a VM that belongs to 
> a different VPC. ... === TestName: test_09_VPC_LBRuleCreateFailMultipleVPC | 
> Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule for a VM that does not 
> belong to any VPC. ... === TestName: 
> test_10_VPC_FailedToCreateLBRuleNonVPCNetwork | Status : SUCCESS ===
> ok
> Test case no 217 and 236: User should not be allowed to create a LB rule for 
> a ... === TestName: test_11_VPC_LBRuleCreateNotAllowed | Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule on an Ipaddress that 
> Source Nat enabled. ... === TestName: test_12_VPC_LBRuleCreateFailForRouterIP 
> | Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule on an Ipaddress that 
> 

[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682820#comment-15682820
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8715:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1545
  
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been 
kicked to run smoke tests


> Add support for qemu-guest-agent to libvirt provider
> 
>
> Key: CLOUDSTACK-8715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Reporter: Sten Spans
>Assignee: Wido den Hollander
>  Labels: kvm, libvirt, qemu, systemvm
> Fix For: Future
>
>
> The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite 
> a lot of useful functionality, which can only be provided by having an agent 
> on the VM. This includes things like freezing/thawing filesystems (for 
> backups), reading files on the guest, listing interfaces / ip addresses, etc.
> This feature has been requested by users, but is currently not implemented.
> http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent
> The first change needed is to add the following to the XML generated for KVM 
> virtual machines,:
> 
>   
>   
> 
> This provides the communication channel between libvirt and the agent on the 
> host. All in all a pretty simple change to LibvirtComputingResource.java / 
> LibvirtVMDef.java
> Secondly the qemu-guest-agent package needs to be added to the systemvm 
> template.



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

[jira] [Commented] (CLOUDSTACK-9321) Multiple Internal LB rules (more than one Internal LB rule with same source IP address) are not getting resolved in the corresponding InternalLbVm instance's hapro

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682821#comment-15682821
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9321:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1577
  
@blueorangutan test


> Multiple Internal LB rules (more than one Internal LB rule with same source 
> IP address) are not getting resolved in the corresponding InternalLbVm 
> instance's haproxy.cfg file
> --
>
> Key: CLOUDSTACK-9321
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9321
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Network Controller
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
>Priority: Critical
> Fix For: 4.9.1.0
>
>
> Multiple Internal LB rules (more than one Internal LB rule with same source 
> IP address) are not getting resolved in the corresponding InternalLbVm 
> instance's haproxy.cfg file. Moreover, each time a new Internal LB rule is 
> added to the corresponding InternalLbVm instance, it replaces the existing 
> one. Thus, traffic corresponding to these un-resolved (old) Internal LB rules 
> are getting dropped by the InternalLbVm instance.
> PR contents:
> 1) Fix for this bug.
> 2) Marvin test coverage for Internal LB feature on master with native ACS 
> setup (component directory) including validations for this bug fix.
> 3) Enhancements on our exiting Internal LB Marvin test code (nuagevsp plugins 
> directory) to validate this bug fix.
> 4) PEP8 & PyFlakes compliance with the added Marvin test code.
> Added Marvin test code PEP8 & PyFlakes compliance:
> CloudStack$
> CloudStack$ pep8 --max-line-length=150 
> test/integration/component/test_vpc_network_internal_lbrules.py
> CloudStack$
> CloudStack$ pyflakes 
> test/integration/component/test_vpc_network_internal_lbrules.py
> CloudStack$
> CloudStack$ pep8 --max-line-length=150 test/integration/plugins/nuagevsp/.py
> CloudStack$
> CloudStack$ pyflakes test/integration/plugins/nuagevsp/.py
> CloudStack$
> Validations:
> 1) Made sure that we didn't break any Public LB (VpcVirtualRouter) 
> functionality.
> Marvin test run:
> nosetests --with-marvin --marvin-config=nuage.cfg 
> test/integration/component/test_vpc_network_lbrules.py
> Test results:
> Test case no 210 and 227: List Load Balancing Rules belonging to a VPC ... 
> === TestName: test_01_VPC_LBRulesListing | Status : SUCCESS ===
> ok
> Test Create LB rules for 1 network which is part of a two/multiple virtual 
> networks of a ... === TestName: test_02_VPC_CreateLBRuleInMultipleNetworks | 
> Status : SUCCESS ===
> ok
> Test case no 222 : Create LB rules for a two/multiple virtual networks of a 
> ... === TestName: test_03_VPC_CreateLBRuleInMultipleNetworksVRStoppedState | 
> Status : SUCCESS ===
> ok
> Test case no 222 : Create LB rules for a two/multiple virtual networks of a 
> ... === TestName: test_04_VPC_CreateLBRuleInMultipleNetworksVRStoppedState | 
> Status : SUCCESS ===
> ok
> Test case no 214 : Delete few(not all) LB rules for a single virtual network 
> of a ... === TestName: test_05_VPC_CreateAndDeleteLBRule | Status : SUCCESS 
> ===
> ok
> Test Delete few(not all) LB rules for a single virtual network of ... === 
> TestName: test_06_VPC_CreateAndDeleteLBRuleVRStopppedState | Status : SUCCESS 
> ===
> ok
> Test Delete all LB rules for a single virtual network of a ... === TestName: 
> test_07_VPC_CreateAndDeleteAllLBRule | Status : SUCCESS ===
> ok
> Test Delete all LB rules for a single virtual network of a ... === TestName: 
> test_08_VPC_CreateAndDeleteAllLBRuleVRStoppedState | Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule for a VM that belongs to 
> a different VPC. ... === TestName: test_09_VPC_LBRuleCreateFailMultipleVPC | 
> Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule for a VM that does not 
> belong to any VPC. ... === TestName: 
> test_10_VPC_FailedToCreateLBRuleNonVPCNetwork | Status : SUCCESS ===
> ok
> Test case no 217 and 236: User should not be allowed to create a LB rule for 
> a ... === TestName: test_11_VPC_LBRuleCreateNotAllowed | Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule on an Ipaddress that 
> Source Nat enabled. ... === TestName: test_12_VPC_LBRuleCreateFailForRouterIP 
> | Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule on an Ipaddress that 
> already has a PF rule. ... === TestName: 
> test_13_VPC_LBRuleCreateFailForPFSourceNATIP | 

[jira] [Commented] (CLOUDSTACK-9379) Support nested virtualization at VM level on VMware Hypervisor

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682817#comment-15682817
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9379:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1542
  
Based on test results LGTM. /cc @jburwell 
Can we have one more LGTM on this, @serg38 @jburwell ?


> Support nested virtualization at VM level on VMware Hypervisor
> --
>
> Key: CLOUDSTACK-9379
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9379
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.9.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> h2. Introduction
> It is desired to support nested virtualization at VM level for VMware 
> hypervisor. Current behaviour supports enabling/desabling global nested 
> virtualization by modifying global config {{'vmware.nested.virtualization'}}. 
> It is wished to improve this feature, having control at VM level instead of a 
> global control only.
> h2. Proposal
> A new global configuration is added, to enable/disable VM nested 
> virtualization control: {{'vmware.nested.virtualization.perVM'}}. Default 
> value=false
> h2. Behaviour
> After a vm deployment or start command, vm params include 
> {{nestedVirtualizationFlag}} key and its value is:
> * true -> nested virtualization enabled
> * false -> nested virtualization disabled
> We will determinate nested virtualization enabled/disabled by examining:
> * (1) global configuration {{'vmware.nested.virtualization'}} value
> * (2) global configuration {{'vmware.nested.virtualization.perVM'}} value
> * (3) {{'nestedVirtualizationFlag'}} value in {{user_vm_details}} if present, 
> null if not.
> Using this 3 values, there are different use cases:
> # (1) = TRUE, (2) = TRUE, (3) is null -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = TRUE, (2) = FALSE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) is null -> DISABLED
> # (1) = FALSE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = FALSE, (2) = FALSE -> DISABLED



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

[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682818#comment-15682818
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8715:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1545
  
@blueorangutan test


> Add support for qemu-guest-agent to libvirt provider
> 
>
> Key: CLOUDSTACK-8715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Reporter: Sten Spans
>Assignee: Wido den Hollander
>  Labels: kvm, libvirt, qemu, systemvm
> Fix For: Future
>
>
> The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite 
> a lot of useful functionality, which can only be provided by having an agent 
> on the VM. This includes things like freezing/thawing filesystems (for 
> backups), reading files on the guest, listing interfaces / ip addresses, etc.
> This feature has been requested by users, but is currently not implemented.
> http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent
> The first change needed is to add the following to the XML generated for KVM 
> virtual machines,:
> 
>   
>   
> 
> This provides the communication channel between libvirt and the agent on the 
> host. All in all a pretty simple change to LibvirtComputingResource.java / 
> LibvirtVMDef.java
> Secondly the qemu-guest-agent package needs to be added to the systemvm 
> template.



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

[jira] [Commented] (CLOUDSTACK-9538) Deleting Snapshot From Primary Storage Fails on RBD Storage if you already delete vm's itself

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682804#comment-15682804
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9538:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1710
  
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been 
kicked to run smoke tests


> Deleting Snapshot From Primary Storage Fails on RBD Storage if you already 
> delete vm's itself
> -
>
> Key: CLOUDSTACK-9538
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9538
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Snapshot, Storage Controller
>Affects Versions: 4.9.0
> Environment: Ubuntu 14.04 Management Server +  Ubuntu 14.04 KVM
>Reporter: Özhan Rüzgar Karaman
>
> Hi;
> We plan to store vm snapshots as vm backups on secondary storage while we 
> still destroyed/expunged related vm. The idea is good there was a bug which 
> blocks this idea to work and it was fixed with CLOUDSTACK-9297 bug. 
> Normally with 4.9 release we expected this idea to work on our on our 4.9 ACS 
> environment but we noticed that because we are using rbd as primary storage 
> we need to fix one minor bug for this idea to work.
> The problem occurs because CLOUDSTACK-8302 bug fixed on 4.9 release and it 
> block our idea to work. If you destroy a vm which is on RBD Storage as 
> primary storage it also deletes any related snapshots of that vm on Primary 
> RBD Storage. So after vm destroy no disk file or snapshot file over RBD 
> Storage. This is good for cleanup purposes on primary storage but 
> XenserverSnapshotStrategy.deleteSnapshot class method did not expect this to 
> happen.
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.deleteSnapshot
>  method receives exception. The code tries 10 times on KVM node to remove RBD 
> snapshot but because there is no snapshot on RBD side it get exception after 
> 10 retries, it also spends nearly 5 minutes to delete snapshots and after 
> that it ends with an error like "Failed to delete snapshot" error.
> I think we need to disable snapshot cleanup on primary storage only for RBD 
> type Primary Storage if its related vm was already been destroyed. (Because 
> vm destroy stage removed all snapshots related to vm on primary storage so 
> there is no need to take any action on primary storage.)
> We make some tests below to make this issue clear for bug.
> 1) We create a vm with 3 snapshots on ACS.
> mysql> select * from snapshot_store_ref where snapshot_id in (93,94,95);
> +-+--+-+-+--+++-+---+++---+--+-+-+---+
> | id  | store_id | snapshot_id | created | last_updated | job_id 
> | store_role | size| physical_size | parent_snapshot_id | 
> install_path  
>  | state | update_count | ref_cnt | updated | volume_id |
> +-+--+-+-+--+++-+---+++---+--+-+-+---+
> | 185 |1 |  93 | 2016-10-12 10:13:44 | NULL | NULL   
> | Primary| 28991029248 |   28991029248 |  0 | 
> cst4/bb9ca3c7-96d6-4465-85b5-cd01f4d635f2/54008bf3-43dd-469d-91a7-4acd146d7b84
>  | Ready |2 |   0 | 2016-10-12 10:13:45 |  4774 |
> | 186 |1 |  93 | 2016-10-12 10:13:45 | NULL | NULL   
> | Image  | 28991029248 |   28991029248 |  0 | 
> snapshots/2/4774/54008bf3-43dd-469d-91a7-4acd146d7b84 
>  | Ready |2 |   0 | 2016-10-12 10:15:04 |  4774 |
> | 187 |1 |  94 | 2016-10-12 10:15:38 | NULL | NULL   
> | Primary| 28991029248 |   28991029248 |  0 | 
> cst4/bb9ca3c7-96d6-4465-85b5-cd01f4d635f2/45fc4f44-b377-49c0-9264-5d813fefe93f
>  | Ready |2 |   0 | 2016-10-12 10:15:39 |  4774 |
> | 188 |1 |  94 | 2016-10-12 10:15:39 | NULL | NULL   
> | Image  | 28991029248 |   28991029248 |  0 | 
> snapshots/2/4774/45fc4f44-b377-49c0-9264-5d813fefe93f 
>  | Ready |2 |   0 | 2016-10-12 10:16:52 |  

[jira] [Commented] (CLOUDSTACK-9538) Deleting Snapshot From Primary Storage Fails on RBD Storage if you already delete vm's itself

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682802#comment-15682802
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9538:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1710
  
@blueorangutan test


> Deleting Snapshot From Primary Storage Fails on RBD Storage if you already 
> delete vm's itself
> -
>
> Key: CLOUDSTACK-9538
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9538
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Snapshot, Storage Controller
>Affects Versions: 4.9.0
> Environment: Ubuntu 14.04 Management Server +  Ubuntu 14.04 KVM
>Reporter: Özhan Rüzgar Karaman
>
> Hi;
> We plan to store vm snapshots as vm backups on secondary storage while we 
> still destroyed/expunged related vm. The idea is good there was a bug which 
> blocks this idea to work and it was fixed with CLOUDSTACK-9297 bug. 
> Normally with 4.9 release we expected this idea to work on our on our 4.9 ACS 
> environment but we noticed that because we are using rbd as primary storage 
> we need to fix one minor bug for this idea to work.
> The problem occurs because CLOUDSTACK-8302 bug fixed on 4.9 release and it 
> block our idea to work. If you destroy a vm which is on RBD Storage as 
> primary storage it also deletes any related snapshots of that vm on Primary 
> RBD Storage. So after vm destroy no disk file or snapshot file over RBD 
> Storage. This is good for cleanup purposes on primary storage but 
> XenserverSnapshotStrategy.deleteSnapshot class method did not expect this to 
> happen.
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.deleteSnapshot
>  method receives exception. The code tries 10 times on KVM node to remove RBD 
> snapshot but because there is no snapshot on RBD side it get exception after 
> 10 retries, it also spends nearly 5 minutes to delete snapshots and after 
> that it ends with an error like "Failed to delete snapshot" error.
> I think we need to disable snapshot cleanup on primary storage only for RBD 
> type Primary Storage if its related vm was already been destroyed. (Because 
> vm destroy stage removed all snapshots related to vm on primary storage so 
> there is no need to take any action on primary storage.)
> We make some tests below to make this issue clear for bug.
> 1) We create a vm with 3 snapshots on ACS.
> mysql> select * from snapshot_store_ref where snapshot_id in (93,94,95);
> +-+--+-+-+--+++-+---+++---+--+-+-+---+
> | id  | store_id | snapshot_id | created | last_updated | job_id 
> | store_role | size| physical_size | parent_snapshot_id | 
> install_path  
>  | state | update_count | ref_cnt | updated | volume_id |
> +-+--+-+-+--+++-+---+++---+--+-+-+---+
> | 185 |1 |  93 | 2016-10-12 10:13:44 | NULL | NULL   
> | Primary| 28991029248 |   28991029248 |  0 | 
> cst4/bb9ca3c7-96d6-4465-85b5-cd01f4d635f2/54008bf3-43dd-469d-91a7-4acd146d7b84
>  | Ready |2 |   0 | 2016-10-12 10:13:45 |  4774 |
> | 186 |1 |  93 | 2016-10-12 10:13:45 | NULL | NULL   
> | Image  | 28991029248 |   28991029248 |  0 | 
> snapshots/2/4774/54008bf3-43dd-469d-91a7-4acd146d7b84 
>  | Ready |2 |   0 | 2016-10-12 10:15:04 |  4774 |
> | 187 |1 |  94 | 2016-10-12 10:15:38 | NULL | NULL   
> | Primary| 28991029248 |   28991029248 |  0 | 
> cst4/bb9ca3c7-96d6-4465-85b5-cd01f4d635f2/45fc4f44-b377-49c0-9264-5d813fefe93f
>  | Ready |2 |   0 | 2016-10-12 10:15:39 |  4774 |
> | 188 |1 |  94 | 2016-10-12 10:15:39 | NULL | NULL   
> | Image  | 28991029248 |   28991029248 |  0 | 
> snapshots/2/4774/45fc4f44-b377-49c0-9264-5d813fefe93f 
>  | Ready |2 |   0 | 2016-10-12 10:16:52 |  4774 |
> | 189 |1 |  95 | 2016-10-12 10:17:08 | NULL | NULL   
> | 

[jira] [Commented] (CLOUDSTACK-9410) Data Disk shown as "detached" in XS

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682646#comment-15682646
 ] 

ASF subversion and git services commented on CLOUDSTACK-9410:
-

Commit bdc806e3156d5403a500a2f3baf0cae45ef08250 in cloudstack's branch 
refs/heads/master from [~koushikd]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bdc806e ]

Merge release branch 4.8 to 4.9

* 4.8:
  CLOUDSTACK-9410: Data Disk shown as detached in XS


> Data Disk shown as "detached" in XS
> ---
>
> Key: CLOUDSTACK-9410
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9410
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
>Reporter: subhash yedugundla
>Priority: Minor
>
> ===
> Issue Description
> ===
> 1. Create a data-disk
> 2. Attach data-disk to an instance. Name in XenCenter for the data-disk looks 
> like "i-2-762-VM-DATA"
> 3. Detach data-disk from instance. Name will change to "detached"
> The issue is that the one would like to see the name of the disk once 
> detached, as the same name given to the volume when created and not 
> “detached” and the naming convention for the disk when detached is misleading 
> Even though one should be managing everything through cloudstack, when there 
> are multiple DATA disks that are detached and if all show the same name it 
> will cause confusion.



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

[jira] [Commented] (CLOUDSTACK-9410) Data Disk shown as "detached" in XS

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682645#comment-15682645
 ] 

ASF subversion and git services commented on CLOUDSTACK-9410:
-

Commit 38c56bdf441c0f4cc8af8ed507b4edf29f8f347c in cloudstack's branch 
refs/heads/master from [~yvsubhash]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=38c56bd ]

CLOUDSTACK-9410: Data Disk shown as detached in XS


> Data Disk shown as "detached" in XS
> ---
>
> Key: CLOUDSTACK-9410
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9410
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
>Reporter: subhash yedugundla
>Priority: Minor
>
> ===
> Issue Description
> ===
> 1. Create a data-disk
> 2. Attach data-disk to an instance. Name in XenCenter for the data-disk looks 
> like "i-2-762-VM-DATA"
> 3. Detach data-disk from instance. Name will change to "detached"
> The issue is that the one would like to see the name of the disk once 
> detached, as the same name given to the volume when created and not 
> “detached” and the naming convention for the disk when detached is misleading 
> Even though one should be managing everything through cloudstack, when there 
> are multiple DATA disks that are detached and if all show the same name it 
> will cause confusion.



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

[jira] [Commented] (CLOUDSTACK-9410) Data Disk shown as "detached" in XS

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682647#comment-15682647
 ] 

ASF subversion and git services commented on CLOUDSTACK-9410:
-

Commit 027409d9bcf0b9562a316da5201bb9158724bae2 in cloudstack's branch 
refs/heads/master from [~koushikd]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=027409d ]

Merge release branch 4.9 to master

* 4.9:
  CLOUDSTACK-9410: Data Disk shown as detached in XS


> Data Disk shown as "detached" in XS
> ---
>
> Key: CLOUDSTACK-9410
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9410
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
>Reporter: subhash yedugundla
>Priority: Minor
>
> ===
> Issue Description
> ===
> 1. Create a data-disk
> 2. Attach data-disk to an instance. Name in XenCenter for the data-disk looks 
> like "i-2-762-VM-DATA"
> 3. Detach data-disk from instance. Name will change to "detached"
> The issue is that the one would like to see the name of the disk once 
> detached, as the same name given to the volume when created and not 
> “detached” and the naming convention for the disk when detached is misleading 
> Even though one should be managing everything through cloudstack, when there 
> are multiple DATA disks that are detached and if all show the same name it 
> will cause confusion.



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

[jira] [Commented] (CLOUDSTACK-9410) Data Disk shown as "detached" in XS

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682622#comment-15682622
 ] 

ASF subversion and git services commented on CLOUDSTACK-9410:
-

Commit bdc806e3156d5403a500a2f3baf0cae45ef08250 in cloudstack's branch 
refs/heads/4.9 from [~koushikd]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bdc806e ]

Merge release branch 4.8 to 4.9

* 4.8:
  CLOUDSTACK-9410: Data Disk shown as detached in XS


> Data Disk shown as "detached" in XS
> ---
>
> Key: CLOUDSTACK-9410
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9410
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
>Reporter: subhash yedugundla
>Priority: Minor
>
> ===
> Issue Description
> ===
> 1. Create a data-disk
> 2. Attach data-disk to an instance. Name in XenCenter for the data-disk looks 
> like "i-2-762-VM-DATA"
> 3. Detach data-disk from instance. Name will change to "detached"
> The issue is that the one would like to see the name of the disk once 
> detached, as the same name given to the volume when created and not 
> “detached” and the naming convention for the disk when detached is misleading 
> Even though one should be managing everything through cloudstack, when there 
> are multiple DATA disks that are detached and if all show the same name it 
> will cause confusion.



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

[jira] [Commented] (CLOUDSTACK-9410) Data Disk shown as "detached" in XS

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682621#comment-15682621
 ] 

ASF subversion and git services commented on CLOUDSTACK-9410:
-

Commit 38c56bdf441c0f4cc8af8ed507b4edf29f8f347c in cloudstack's branch 
refs/heads/4.9 from [~yvsubhash]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=38c56bd ]

CLOUDSTACK-9410: Data Disk shown as detached in XS


> Data Disk shown as "detached" in XS
> ---
>
> Key: CLOUDSTACK-9410
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9410
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
>Reporter: subhash yedugundla
>Priority: Minor
>
> ===
> Issue Description
> ===
> 1. Create a data-disk
> 2. Attach data-disk to an instance. Name in XenCenter for the data-disk looks 
> like "i-2-762-VM-DATA"
> 3. Detach data-disk from instance. Name will change to "detached"
> The issue is that the one would like to see the name of the disk once 
> detached, as the same name given to the volume when created and not 
> “detached” and the naming convention for the disk when detached is misleading 
> Even though one should be managing everything through cloudstack, when there 
> are multiple DATA disks that are detached and if all show the same name it 
> will cause confusion.



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

[jira] [Commented] (CLOUDSTACK-9410) Data Disk shown as "detached" in XS

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682597#comment-15682597
 ] 

ASF subversion and git services commented on CLOUDSTACK-9410:
-

Commit 38c56bdf441c0f4cc8af8ed507b4edf29f8f347c in cloudstack's branch 
refs/heads/4.8 from [~yvsubhash]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=38c56bd ]

CLOUDSTACK-9410: Data Disk shown as detached in XS


> Data Disk shown as "detached" in XS
> ---
>
> Key: CLOUDSTACK-9410
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9410
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
>Reporter: subhash yedugundla
>Priority: Minor
>
> ===
> Issue Description
> ===
> 1. Create a data-disk
> 2. Attach data-disk to an instance. Name in XenCenter for the data-disk looks 
> like "i-2-762-VM-DATA"
> 3. Detach data-disk from instance. Name will change to "detached"
> The issue is that the one would like to see the name of the disk once 
> detached, as the same name given to the volume when created and not 
> “detached” and the naming convention for the disk when detached is misleading 
> Even though one should be managing everything through cloudstack, when there 
> are multiple DATA disks that are detached and if all show the same name it 
> will cause confusion.



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

[jira] [Commented] (CLOUDSTACK-9410) Data Disk shown as "detached" in XS

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682599#comment-15682599
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9410:


Github user asfgit closed the pull request at:

https://github.com/apache/cloudstack/pull/1586


> Data Disk shown as "detached" in XS
> ---
>
> Key: CLOUDSTACK-9410
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9410
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
>Reporter: subhash yedugundla
>Priority: Minor
>
> ===
> Issue Description
> ===
> 1. Create a data-disk
> 2. Attach data-disk to an instance. Name in XenCenter for the data-disk looks 
> like "i-2-762-VM-DATA"
> 3. Detach data-disk from instance. Name will change to "detached"
> The issue is that the one would like to see the name of the disk once 
> detached, as the same name given to the volume when created and not 
> “detached” and the naming convention for the disk when detached is misleading 
> Even though one should be managing everything through cloudstack, when there 
> are multiple DATA disks that are detached and if all show the same name it 
> will cause confusion.



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

[jira] [Commented] (CLOUDSTACK-9410) Data Disk shown as "detached" in XS

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682596#comment-15682596
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9410:


Github user koushik-das commented on the issue:

https://github.com/apache/cloudstack/pull/1586
  
Merging as all the required LGTMs are there.


> Data Disk shown as "detached" in XS
> ---
>
> Key: CLOUDSTACK-9410
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9410
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
>Reporter: subhash yedugundla
>Priority: Minor
>
> ===
> Issue Description
> ===
> 1. Create a data-disk
> 2. Attach data-disk to an instance. Name in XenCenter for the data-disk looks 
> like "i-2-762-VM-DATA"
> 3. Detach data-disk from instance. Name will change to "detached"
> The issue is that the one would like to see the name of the disk once 
> detached, as the same name given to the volume when created and not 
> “detached” and the naming convention for the disk when detached is misleading 
> Even though one should be managing everything through cloudstack, when there 
> are multiple DATA disks that are detached and if all show the same name it 
> will cause confusion.



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

[jira] [Resolved] (CLOUDSTACK-9460) Graceful handling of Mysql server connection timeout

[John Burwell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Burwell resolved CLOUDSTACK-9460.
--
Resolution: Fixed

Merged to the 4.8, 4.9, and master branches for inclusion in the 4.8.2.0, 
4.9.1.0, and 4.10.0.0 releases.

> Graceful handling of Mysql server connection timeout
> 
>
> Key: CLOUDSTACK-9460
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9460
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0
>
>




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

[jira] [Updated] (CLOUDSTACK-9460) Graceful handling of Mysql server connection timeout

[John Burwell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Burwell updated CLOUDSTACK-9460:
-
Fix Version/s: 4.8.2.0
   4.10.0.0

> Graceful handling of Mysql server connection timeout
> 
>
> Key: CLOUDSTACK-9460
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9460
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
> Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0
>
>




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

[jira] [Commented] (CLOUDSTACK-9379) Support nested virtualization at VM level on VMware Hypervisor

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682237#comment-15682237
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9379:


Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1542
  
@rhytd @jburwell  @karuturi  test_nested_virtualization_vmware  
Success 305.03

The other tests fail due to environmental issues e.g. below. I think it is 
ready for merging now.

2016-11-20 16:32:00,324 - CRITICAL - EXCEPTION: test_3d_gpu_support: 
['Traceback (most recent call last):\n', '  File 
"/usr/lib64/python2.7/unittest/case.py", line 369, in run\ntestMethod()\n', 
'  File "/marvin/tests/smoke/test_deploy_vgpu_enabled_vm.py", line 316, in 
test_3d_gpu_support\nself.virtual_machine.add_nic(self.apiclient, 
self.isolated_network.id)\n', '  File 
"/usr/lib/python2.7/site-packages/marvin/lib/base.py", line 784, in add_nic\n   
 return apiclient.addNicToVirtualMachine(cmd)\n', '  File 
"/usr/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py", 
line 637, in addNicToVirtualMachine\nresponse = 
self.connection.marvinRequest(command, response_type=response, 
method=method)\n', '  File 
"/usr/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line 379, in 
marvinRequest\nraise e\n', "Exception: Job failed: {jobprocstatus : 0, 
created : u'2016-11-20T16:29:43+', cmd : 
u'org.apache.cloudstack.api.command.admin.vm.AddNicToVMCmdByAdmin', userid : 
u'1575bde5-af3a-11e6-b333-06aa7801071a', jobstatus : 2, jobid : 
u'78b21bfa-bc82-4df6-ad54-67ef0899ceeb', jobresultcode : 530, jobresulttype : 
u'object', jobresult : {errorcode : 530, errortext : u'Unable to add NIC to 
VM[User|i-7-9-VM]: com.cloud.exception.AgentUnavailableException: **Resource 
[Host:1] is unreachable:** Host 1: Unable to start instance due to Unable to 
start  VM:a42c5549-c3c4-47b3-8e49-0785d1c2ef44 due to error in finalizeStart, 
not retrying'}, accountid : u'1575a6c7-af3a-11e6-b333-06aa7801071a'}\n"]


> Support nested virtualization at VM level on VMware Hypervisor
> --
>
> Key: CLOUDSTACK-9379
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9379
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.9.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> h2. Introduction
> It is desired to support nested virtualization at VM level for VMware 
> hypervisor. Current behaviour supports enabling/desabling global nested 
> virtualization by modifying global config {{'vmware.nested.virtualization'}}. 
> It is wished to improve this feature, having control at VM level instead of a 
> global control only.
> h2. Proposal
> A new global configuration is added, to enable/disable VM nested 
> virtualization control: {{'vmware.nested.virtualization.perVM'}}. Default 
> value=false
> h2. Behaviour
> After a vm deployment or start command, vm params include 
> {{nestedVirtualizationFlag}} key and its value is:
> * true -> nested virtualization enabled
> * false -> nested virtualization disabled
> We will determinate nested virtualization enabled/disabled by examining:
> * (1) global configuration {{'vmware.nested.virtualization'}} value
> * (2) global configuration {{'vmware.nested.virtualization.perVM'}} value
> * (3) {{'nestedVirtualizationFlag'}} value in {{user_vm_details}} if present, 
> null if not.
> Using this 3 values, there are different use cases:
> # (1) = TRUE, (2) = TRUE, (3) is null -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = TRUE, (2) = FALSE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) is null -> DISABLED
> # (1) = FALSE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = FALSE, (2) = FALSE -> DISABLED



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

[jira] [Commented] (CLOUDSTACK-9379) Support nested virtualization at VM level on VMware Hypervisor

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682129#comment-15682129
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9379:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1542
  
Trillian test result (tid-348)
Environment: vmware-55u3 (x2), Advanced Networking with Mgmt server 7
Total time taken: 32441 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1542-t348-vmware-55u3.zip
Test completed. 43 look ok, 6 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_04_rvpc_privategw_static_routes | `Failure` | 404.56 | 
test_privategw_acl.py
test_04_rvpc_internallb_haproxy_stats_on_all_interfaces | `Failure` | 
232.50 | test_internal_lb.py
test_02_internallb_roundrobin_1RVPC_3VM_HTTP_port80 | `Failure` | 116.96 | 
test_internal_lb.py
test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80 | `Failure` | 506.36 | 
test_internal_lb.py
test_01_vpc_site2site_vpn | `Error` | 471.78 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | `Error` | 719.02 | test_vpc_vpn.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | `Error` | 218.09 | 
test_vpc_redundant.py
test_reboot_router | `Error` | 240.44 | test_network.py
test_3d_gpu_support | `Error` | 386.98 | test_deploy_vgpu_enabled_vm.py
test_01_vpc_remote_access_vpn | Success | 151.89 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 340.42 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 773.29 | test_vpc_router_nics.py
test_05_rvpc_multi_tiers | Success | 660.77 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | Success | 1520.02 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 770.23 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | Success | 654.60 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 25.80 | test_volumes.py
test_06_download_detached_volume | Success | 65.61 | test_volumes.py
test_05_detach_volume | Success | 105.30 | test_volumes.py
test_04_delete_attached_volume | Success | 15.23 | test_volumes.py
test_03_download_attached_volume | Success | 20.35 | test_volumes.py
test_02_attach_volume | Success | 53.79 | test_volumes.py
test_01_create_volume | Success | 447.27 | test_volumes.py
test_03_delete_vm_snapshots | Success | 275.24 | test_vm_snapshots.py
test_02_revert_vm_snapshots | Success | 227.22 | test_vm_snapshots.py
test_01_test_vm_volume_snapshot | Success | 196.69 | test_vm_snapshots.py
test_01_create_vm_snapshots | Success | 161.65 | test_vm_snapshots.py
test_deploy_vm_multiple | Success | 273.76 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 26.92 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.22 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 81.15 | 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.15 | test_vm_life_cycle.py
test_02_start_vm | Success | 20.24 | test_vm_life_cycle.py
test_01_stop_vm | Success | 10.15 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 231.61 | 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 | 15.22 | test_templates.py
test_03_delete_template | Success | 5.11 | test_templates.py
test_02_edit_template | Success | 90.13 | test_templates.py
test_01_create_template | Success | 125.93 | test_templates.py
test_10_destroy_cpvm | Success | 236.93 | test_ssvm.py
test_09_destroy_ssvm | Success | 208.67 | test_ssvm.py
test_08_reboot_cpvm | Success | 156.55 | test_ssvm.py
test_07_reboot_ssvm | Success | 158.49 | test_ssvm.py
test_06_stop_cpvm | Success | 207.13 | test_ssvm.py
test_05_stop_ssvm | Success | 208.82 | test_ssvm.py
test_04_cpvm_internals | Success | 1.21 | test_ssvm.py
test_03_ssvm_internals | Success | 3.41 | 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.52 | test_snapshots.py
test_04_change_offering_small | Success | 91.89 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.05 | test_service_offerings.py

[jira] [Commented] (CLOUDSTACK-9595) Transactions are not getting retried in case of database deadlock errors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681977#comment-15681977
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9595:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1762
  
Trillian test result (tid-347)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 26094 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1762-t347-kvm-centos7.zip
Test completed. 47 look ok, 1 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | `Failure` | 369.46 
| test_vpc_redundant.py
test_01_vpc_site2site_vpn | Success | 154.87 | test_vpc_vpn.py
test_01_vpc_remote_access_vpn | Success | 66.24 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | Success | 255.75 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 273.12 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 534.12 | test_vpc_router_nics.py
test_05_rvpc_multi_tiers | Success | 513.09 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | Success | 1408.56 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 553.46 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | Success | 753.12 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 15.44 | test_volumes.py
test_08_resize_volume | Success | 15.36 | test_volumes.py
test_07_resize_fail | Success | 20.45 | test_volumes.py
test_06_download_detached_volume | Success | 15.29 | test_volumes.py
test_05_detach_volume | Success | 100.25 | test_volumes.py
test_04_delete_attached_volume | Success | 10.18 | test_volumes.py
test_03_download_attached_volume | Success | 15.30 | test_volumes.py
test_02_attach_volume | Success | 73.79 | test_volumes.py
test_01_create_volume | Success | 712.21 | test_volumes.py
test_deploy_vm_multiple | Success | 278.61 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 26.47 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.19 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 35.86 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.10 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 125.83 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 125.82 | test_vm_life_cycle.py
test_02_start_vm | Success | 10.16 | test_vm_life_cycle.py
test_01_stop_vm | Success | 40.30 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 75.58 | 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 | 5.18 | test_templates.py
test_03_delete_template | Success | 5.10 | test_templates.py
test_02_edit_template | Success | 90.17 | test_templates.py
test_01_create_template | Success | 70.57 | test_templates.py
test_10_destroy_cpvm | Success | 131.62 | test_ssvm.py
test_09_destroy_ssvm | Success | 163.18 | test_ssvm.py
test_08_reboot_cpvm | Success | 101.42 | test_ssvm.py
test_07_reboot_ssvm | Success | 133.53 | test_ssvm.py
test_06_stop_cpvm | Success | 166.54 | test_ssvm.py
test_05_stop_ssvm | Success | 133.56 | test_ssvm.py
test_04_cpvm_internals | Success | 0.95 | test_ssvm.py
test_03_ssvm_internals | Success | 3.27 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.11 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.12 | test_ssvm.py
test_01_snapshot_root_disk | Success | 16.20 | test_snapshots.py
test_04_change_offering_small | Success | 209.44 | 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.10 | test_service_offerings.py
test_02_sys_template_ready | Success | 0.12 | test_secondary_storage.py
test_01_sys_vm_start | Success | 0.17 | test_secondary_storage.py
test_09_reboot_router | Success | 30.26 | test_routers.py
test_08_start_router | Success | 25.25 | test_routers.py
test_07_stop_router | Success | 10.15 | test_routers.py
test_06_router_advanced | Success | 0.05 | test_routers.py
test_05_router_basic | Success | 0.04 | test_routers.py
test_04_restart_network_wo_cleanup | Success | 5.59 | test_routers.py
test_03_restart_network_cleanup 

[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681687#comment-15681687
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9539:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1727
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-225


> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681688#comment-15681688
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8908:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/896
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-224


> 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-8715) Add support for qemu-guest-agent to libvirt provider

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681680#comment-15681680
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8715:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1545
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-219


> Add support for qemu-guest-agent to libvirt provider
> 
>
> Key: CLOUDSTACK-8715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Reporter: Sten Spans
>Assignee: Wido den Hollander
>  Labels: kvm, libvirt, qemu, systemvm
> Fix For: Future
>
>
> The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite 
> a lot of useful functionality, which can only be provided by having an agent 
> on the VM. This includes things like freezing/thawing filesystems (for 
> backups), reading files on the guest, listing interfaces / ip addresses, etc.
> This feature has been requested by users, but is currently not implemented.
> http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent
> The first change needed is to add the following to the XML generated for KVM 
> virtual machines,:
> 
>   
>   
> 
> This provides the communication channel between libvirt and the agent on the 
> host. All in all a pretty simple change to LibvirtComputingResource.java / 
> LibvirtVMDef.java
> Secondly the qemu-guest-agent package needs to be added to the systemvm 
> template.



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

[jira] [Commented] (CLOUDSTACK-9402) Nuage VSP Plugin : Support for underlay features (Source & Static NAT to underlay) including Marvin test coverage on master

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681643#comment-15681643
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9402:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1580
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-215


> Nuage VSP Plugin : Support for underlay features (Source & Static NAT to 
> underlay) including Marvin test coverage on master
> ---
>
> Key: CLOUDSTACK-9402
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9402
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Network Controller
>Affects Versions: 4.10.0.0
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
>
> Support for underlay features (Source & Static NAT to underlay) with Nuage 
> VSP SDN Plugin including Marvin test coverage for corresponding Source & 
> Static NAT features on master. Moreover, our Marvin tests are written in such 
> a way that they can validate our supported feature set with both Nuage VSP 
> SDN platform's overlay and underlay infra.
> PR contents:
> 1) Support for Source NAT to underlay feature on master with Nuage VSP SDN 
> Plugin.
> 2) Support for Static NAT to underlay feature on master with Nuage VSP SDN 
> Plugin.
> 3) Marvin test coverage for Source & Static NAT to underlay on master with 
> Nuage VSP SDN Plugin.
> 4) Enhancements on our exiting Marvin test code (nuagevsp plugins directory).
> 5) PEP8 & PyFlakes compliance with our Marvin test code.
> Our Marvin test code PEP8 & PyFlakes compliance:
> CloudStack$
> CloudStack$ pep8 --max-line-length=150 test/integration/plugins/nuagevsp/.py
> CloudStack$
> CloudStack$ pyflakes test/integration/plugins/nuagevsp/.py
> CloudStack$
> Validations:
> 1) Underlay infra (Source & Static NAT to underlay)
> Marvin test run:
> nosetests --with-marvin --marvin-config=nuage.cfg 
> plugins/nuagevsp/test_nuage_source_nat.py
> Test results:
> Test Nuage VSP Isolated networks with different combinations of Source NAT 
> service providers ... === TestName: test_01_nuage_SourceNAT_isolated_networks 
> | Status : SUCCESS ===
> ok
> Test Nuage VSP VPC networks with different combinations of Source NAT service 
> providers ... === TestName: test_02_nuage_SourceNAT_vpc_networks | Status : 
> SUCCESS ===
> ok
> Test Nuage VSP Source NAT functionality for Isolated network by performing 
> (wget) traffic tests to the ... === TestName: 
> test_03_nuage_SourceNAT_isolated_network_traffic | Status : SUCCESS ===
> ok
> Test Nuage VSP Source NAT functionality for VPC network by performing (wget) 
> traffic tests to the Internet ... === TestName: 
> test_04_nuage_SourceNAT_vpc_network_traffic | Status : SUCCESS ===
> ok
> Test Nuage VSP Source NAT functionality with different Egress 
> Firewall/Network ACL rules by performing (wget) ... === TestName: 
> test_05_nuage_SourceNAT_acl_rules_traffic | Status : SUCCESS ===
> ok
> Test Nuage VSP Source NAT functionality with VM NIC operations by performing 
> (wget) traffic tests to the ... === TestName: 
> test_06_nuage_SourceNAT_vm_nic_operations_traffic | Status : SUCCESS ===
> ok
> Test Nuage VSP Source NAT functionality with VM migration by performing 
> (wget) traffic tests to the Internet ... === TestName: 
> test_07_nuage_SourceNAT_vm_migration_traffic | Status : SUCCESS ===
> ok
> Test Nuage VSP Source NAT functionality with network restarts by performing 
> (wget) traffic tests to the ... === TestName: 
> test_08_nuage_SourceNAT_network_restarts_traffic | Status : SUCCESS ===
> ok
> --
> Ran 8 tests in 13360.858s
> OK
> Marvin test run:
> nosetests --with-marvin --marvin-config=nuage.cfg 
> plugins/nuagevsp/test_nuage_static_nat.py
> Test results:
> Test Nuage VSP Public IP Range creation and deletion ... === TestName: 
> test_01_nuage_StaticNAT_public_ip_range | Status : SUCCESS ===
> ok
> Test Nuage VSP Nuage Underlay (underlay networking) enabled Public IP Range 
> creation and deletion ... === TestName: 
> test_02_nuage_StaticNAT_underlay_public_ip_range | Status : SUCCESS ===
> ok
> Test Nuage VSP Isolated networks with different combinations of Static NAT 
> service providers ... === TestName: test_03_nuage_StaticNAT_isolated_networks 
> | Status : SUCCESS ===
> ok
> Test Nuage VSP VPC networks with different combinations of Static NAT service 
> providers ... === TestName: test_04_nuage_StaticNAT_vpc_networks | Status : 
> SUCCESS ===
> ok
> Test Nuage VSP Static NAT functionality for Isolated network by performing 
> (wget) traffic tests 

[jira] [Commented] (CLOUDSTACK-9321) Multiple Internal LB rules (more than one Internal LB rule with same source IP address) are not getting resolved in the corresponding InternalLbVm instance's hapro

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681632#comment-15681632
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9321:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1577
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-216


> Multiple Internal LB rules (more than one Internal LB rule with same source 
> IP address) are not getting resolved in the corresponding InternalLbVm 
> instance's haproxy.cfg file
> --
>
> Key: CLOUDSTACK-9321
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9321
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Network Controller
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
>Priority: Critical
> Fix For: 4.9.1.0
>
>
> Multiple Internal LB rules (more than one Internal LB rule with same source 
> IP address) are not getting resolved in the corresponding InternalLbVm 
> instance's haproxy.cfg file. Moreover, each time a new Internal LB rule is 
> added to the corresponding InternalLbVm instance, it replaces the existing 
> one. Thus, traffic corresponding to these un-resolved (old) Internal LB rules 
> are getting dropped by the InternalLbVm instance.
> PR contents:
> 1) Fix for this bug.
> 2) Marvin test coverage for Internal LB feature on master with native ACS 
> setup (component directory) including validations for this bug fix.
> 3) Enhancements on our exiting Internal LB Marvin test code (nuagevsp plugins 
> directory) to validate this bug fix.
> 4) PEP8 & PyFlakes compliance with the added Marvin test code.
> Added Marvin test code PEP8 & PyFlakes compliance:
> CloudStack$
> CloudStack$ pep8 --max-line-length=150 
> test/integration/component/test_vpc_network_internal_lbrules.py
> CloudStack$
> CloudStack$ pyflakes 
> test/integration/component/test_vpc_network_internal_lbrules.py
> CloudStack$
> CloudStack$ pep8 --max-line-length=150 test/integration/plugins/nuagevsp/.py
> CloudStack$
> CloudStack$ pyflakes test/integration/plugins/nuagevsp/.py
> CloudStack$
> Validations:
> 1) Made sure that we didn't break any Public LB (VpcVirtualRouter) 
> functionality.
> Marvin test run:
> nosetests --with-marvin --marvin-config=nuage.cfg 
> test/integration/component/test_vpc_network_lbrules.py
> Test results:
> Test case no 210 and 227: List Load Balancing Rules belonging to a VPC ... 
> === TestName: test_01_VPC_LBRulesListing | Status : SUCCESS ===
> ok
> Test Create LB rules for 1 network which is part of a two/multiple virtual 
> networks of a ... === TestName: test_02_VPC_CreateLBRuleInMultipleNetworks | 
> Status : SUCCESS ===
> ok
> Test case no 222 : Create LB rules for a two/multiple virtual networks of a 
> ... === TestName: test_03_VPC_CreateLBRuleInMultipleNetworksVRStoppedState | 
> Status : SUCCESS ===
> ok
> Test case no 222 : Create LB rules for a two/multiple virtual networks of a 
> ... === TestName: test_04_VPC_CreateLBRuleInMultipleNetworksVRStoppedState | 
> Status : SUCCESS ===
> ok
> Test case no 214 : Delete few(not all) LB rules for a single virtual network 
> of a ... === TestName: test_05_VPC_CreateAndDeleteLBRule | Status : SUCCESS 
> ===
> ok
> Test Delete few(not all) LB rules for a single virtual network of ... === 
> TestName: test_06_VPC_CreateAndDeleteLBRuleVRStopppedState | Status : SUCCESS 
> ===
> ok
> Test Delete all LB rules for a single virtual network of a ... === TestName: 
> test_07_VPC_CreateAndDeleteAllLBRule | Status : SUCCESS ===
> ok
> Test Delete all LB rules for a single virtual network of a ... === TestName: 
> test_08_VPC_CreateAndDeleteAllLBRuleVRStoppedState | Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule for a VM that belongs to 
> a different VPC. ... === TestName: test_09_VPC_LBRuleCreateFailMultipleVPC | 
> Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule for a VM that does not 
> belong to any VPC. ... === TestName: 
> test_10_VPC_FailedToCreateLBRuleNonVPCNetwork | Status : SUCCESS ===
> ok
> Test case no 217 and 236: User should not be allowed to create a LB rule for 
> a ... === TestName: test_11_VPC_LBRuleCreateNotAllowed | Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule on an Ipaddress that 
> Source Nat enabled. ... === TestName: test_12_VPC_LBRuleCreateFailForRouterIP 
> | Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule on an Ipaddress that 
> already has a PF rule. ... === TestName: 
> 

[jira] [Commented] (CLOUDSTACK-9403) Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin test coverage

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681633#comment-15681633
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9403:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1579
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-214


> Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin 
> test coverage
> 
>
> Key: CLOUDSTACK-9403
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9403
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Network Controller
>Reporter: Rahul Singal
>Assignee: Nick Livens
>
> This is first phase of support of Shared Network in cloudstack through 
> NuageVsp Network Plugin. A shared network is a type of virtual network that 
> is shared between multiple accounts i.e. a shared network can be accessed by 
> virtual machines that belong to many different accounts. This basic 
> functionality will be supported with the below common use case:
> - shared network can be used for monitoring purposes. A shared network can be 
> assigned to a domain and can be used for monitoring VMs  belonging to all 
> accounts in that domain.
> - Public accessible of shared Network.
> With the current implementation with NuageVsp plugin, It support over-lapping 
> of Ip address, Public Access and also adding Ip ranges in shared Network.
> In VSD, it is implemented in below manner:
> - In order to have tenant isolation for shared networks, we will have to 
> create a Shared L3 Subnet for each shared network, and instantiate it across 
> the relevant enterprises. A shared network will only exist under an 
> enterprise when it is needed, so when the first VM is spinned under that ACS 
> domain inside that shared network.
> - For public shared Network it will also create a floating ip subnet pool in 
> VSD along with all the things mentioned in above point.
> PR contents:
> 1) Support for shared networks with tenant isolation on master with Nuage VSP 
> SDN Plugin.
> 2) Support of shared network with publicly accessible ip ranges.  
> 2) Marvin test coverage for shared networks on master with Nuage VSP SDN 
> Plugin.
> 3) Enhancements on our exiting Marvin test code (nuagevsp plugins directory).
> 4) PEP8 & PyFlakes compliance with our Marvin test code.
> Test Results are:-
> Valiate that ROOT admin is NOT able to deploy a VM for a user in ROOT domain 
> in a shared network with ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_ROOTuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for a admin user in a 
> shared network with ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_differentdomain | 
> Status : SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for admin user in the same 
> domain but in a ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_domainadminuser | 
> Status : SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for user in the same 
> domain but in a different ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_domainuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is able to deploy a VM for regular user in a shared 
> network with scope=account ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_user | Status : SUCCESS 
> ===
> ok
> Valiate that ROOT admin is able to deploy a VM for user in ROOT domain in a 
> shared network with scope=all ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_all_ROOTuser | Status : SUCCESS 
> ===
> ok
> Valiate that ROOT admin is able to deploy a VM for a domain admin users in a 
> shared network with scope=all ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_all_domainadminuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is able to deploy a VM for other users in a shared 
> network with scope=all ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_all_domainuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is able to deploy a VM for admin user in a domain in 
> a shared network with scope=all ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_all_subdomainadminuser | Status 
> : SUCCESS ===
> ok
> Valiate that ROOT admin is able to deploy a VM for any user in a subdomain in 
> a shared network with scope=all ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_all_subdomainuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for 

[jira] [Commented] (CLOUDSTACK-9410) Data Disk shown as "detached" in XS

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681623#comment-15681623
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9410:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1586
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-213


> Data Disk shown as "detached" in XS
> ---
>
> Key: CLOUDSTACK-9410
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9410
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
>Reporter: subhash yedugundla
>Priority: Minor
>
> ===
> Issue Description
> ===
> 1. Create a data-disk
> 2. Attach data-disk to an instance. Name in XenCenter for the data-disk looks 
> like "i-2-762-VM-DATA"
> 3. Detach data-disk from instance. Name will change to "detached"
> The issue is that the one would like to see the name of the disk once 
> detached, as the same name given to the volume when created and not 
> “detached” and the naming convention for the disk when detached is misleading 
> Even though one should be managing everything through cloudstack, when there 
> are multiple DATA disks that are detached and if all show the same name it 
> will cause confusion.



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

[jira] [Commented] (CLOUDSTACK-9417) Usage module refactoring

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681616#comment-15681616
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9417:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1593
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-211


> Usage module refactoring
> 
>
> Key: CLOUDSTACK-9417
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9417
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.9.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.9.1.0
>
>
> h3. Introduction
> Usage sanity check file was not been updated on sanity check.
> It is proposed:
> * New usage folder {{/var/cache/cloudstack/usage}}, creation on 
> cloudstack-usage package built.
> * New sanity check file location in new folder {{/var/cache/cloudstack/usage}}
> * Timestamp included in {{usage.log}} file
> * Include {{updateMaxId()}} on sanity check as it wasn't being updated



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

[jira] [Commented] (CLOUDSTACK-9416) ACS master GUI: Enabling Static NAT on an associated Public IP to one of the NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP being sel

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681613#comment-15681613
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9416:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1592
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-210


> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI
> ---
>
> Key: CLOUDSTACK-9416
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9416
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
> Attachments: network1.png, network2.png
>
>
> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI:
> {noformat}
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'alertManagerImpl'
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.nat.EnableStaticNatCmd': 
> AutowiredFieldElement for public com.cloud.utils.db.UUIDManager 
> org.apache.cloudstack.api.BaseCmd._uuidMgr
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'uUIDManagerImpl'
> 2016-06-13 04:50:00,472 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'messageBus'
> 2016-06-13 04:50:00,479 INFO  [c.c.a.ApiServer] (catalina-exec-7:ctx-83926837 
> ctx-fc7aa5ed) VM ip 10.10.2.163 address not belongs to the vm
> 2016-06-13 04:50:00,480 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) ===END===  10.31.56.146 -- GET  
> command=enableStaticNat=json=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D=36262bcc-282a-46c2-8a80-472e2a24ab5e=af160cde-6762-4756-b97f-f3829f6d9802=10.10.2.163&_=1465818687943
> 2016-06-13 04:50:02,261 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-9:ctx-6050366f) ===START===  10.31.56.146 -- GET  
> command=queryAsyncJobResult=7850c125-54a2-4e99-ab78-9f0e3578c304=json=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&_=1465818689752
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.configuration.ConfigurationService 
> org.apache.cloudstack.api.BaseCmd._configService
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Returning cached instance of 
> singleton bean 'configurationManagerImpl'
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.user.AccountService 
> org.apache.cloudstack.api.BaseCmd._accountService
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Returning cached instance of 
> singleton bean 'accountManagerImpl'
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.vm.UserVmService 
> org.apache.cloudstack.api.BaseCmd._userVmService
> {noformat}



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

[jira] [Commented] (CLOUDSTACK-9451) stopVirtualMachine ignores forced parameter

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681608#comment-15681608
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9451:


Github user nathanejohnson commented on the issue:

https://github.com/apache/cloudstack/pull/1635
  
@rhtyd @jburwell  I believe the last commit should have addressed his 
concerns.


> stopVirtualMachine ignores forced parameter
> ---
>
> Key: CLOUDSTACK-9451
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9451
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Management Server
>Affects Versions: 4.8.0, 4.9.0
>Reporter: Nathan Johnson
>Priority: Minor
>
> As reported by Jeff Hair from the mailing list:
> Hi,
> I'm looking at the documentation and then the code for stopVirtualMachine.
> The forced parameter is passed down into the VM manager, where it seems to
> be ignored. This means that cleanupEvenIfFailed during VM stop will always
> be false, despite what the API command says. Going back to commit a4f4c986
> in 2013, we can see that the forced parameter was used. During subsequent
> refactoring, this seems to have vanished.



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

[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681583#comment-15681583
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9317:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1623
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-207


> Disabling static NAT on many IPs can leave wrong IPs on the router
> --
>
> Key: CLOUDSTACK-9317
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Virtual Router
>Affects Versions: 4.7.0, 4.7.1, 4.7.2
>Reporter: Jeff Hair
>
> The current behavior of enabling or disabling static NAT will call the apply 
> IP associations method in the management server. The method is not 
> thread-safe. If it's called from multiple threads, each thread will load up 
> the list of public IPs in different states (add or revoke)--correct for the 
> thread, but not correct overall. Depending on execution order on the virtual 
> router, the router can end up with public IPs assigned to it that are not 
> supposed to be on it anymore. When another account acquires the same IP, this 
> of course leads to network problems.
> The problem has been in CS since at least 4.2, and likely affects all 
> recently released versions. Affected version is set to 4.7.x because that's 
> what we verified against.



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

[jira] [Commented] (CLOUDSTACK-9456) Migrate master to use Java8 and Spring4

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681567#comment-15681567
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9456:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1638
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-204


> Migrate master to use Java8 and Spring4
> ---
>
> Key: CLOUDSTACK-9456
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9456
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0
>
>
> We need to move master to use Java8 and Spring4.



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

[jira] [Commented] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681539#comment-15681539
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9339:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1659
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-201


> Virtual Routers don't handle Multiple Public Interfaces
> ---
>
> Key: CLOUDSTACK-9339
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9339
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.8.0
>Reporter: dsclose
>Assignee: Murali Reddy
>  Labels: firewall, nat, router
> Fix For: 4.10.0.0, 4.9.1.0
>
>
> There are a series of issues with the way Virtual Routers manage multiple 
> public interfaces. These are more pronounced on redundant virtual router 
> setups. I have not attempted to examine these issues in a VPC context. 
> Outside of a VPC context, however, the following is expected behaviour:
> * eth0 connects the router to the guest network.
> * In RvR setups, keepalived manages the guests' gateway IP as a virtual IP on 
> eth0.
> * eth1 provides a local link to the hypervisor, allowing Cloudstack to issue 
> commands to the router.
> * eth2 is the routers public interface. By default, a single public IP will 
> be setup on eth2 along with the necessary iptables and ip rules to source-NAT 
> guest traffic to that public IP.
> * When a public IP address is assigned to the router that is on a separate 
> subnet to the source-NAT IP, a new interface is configured, such as eth3, and 
> the IP is assigned to that interface.
> * This can result in eth3, eth4, eth5, etc. being created depending upon how 
> many public subnets the router has to work with.
> The above all works. The following, however, is currently not working:
> * Public interfaces should be set to DOWN on backup redundant routers. The 
> master.py script is responsible for setting public interfaces to UP during a 
> keepalived transition. Currently the check_is_up method of the CsIP class 
> brings all interfaces UP on both RvR. A proposed fix for this has been 
> discussed on the mailing list. That fix will leave public interfaces DOWN on 
> RvR allowing the keepalived transition to control the state of public 
> interfaces. Issue #1413 includes a commit that contradicts the proposed fix 
> so it is unclear what the current state of the code should be.
> * Newly created interfaces should be set to UP on master redundant routers. 
> Assuming public interfaces should be default be DOWN on an RvR we need to 
> accommodate the fact that, as interfaces are created, no keepalived 
> transition occurs. This means that assigning an IP from a new public subnet 
> will have no effect (as the interface will be down) until the network is 
> restarted with a "clean up."
> * Public interfaces other than eth2 do not forward traffic. There are two 
> iptables rules in the FORWARD chain of the filter table created for eth2 that 
> allow forwarding between eth2 and eth0. Equivalent rules are not created for 
> other public interfaces so forwarded traffic is dropped.
> * Outbound traffic from guest VMs does not honour static-NAT rules. Instead, 
> outbound traffic is source-NAT'd to the networks default source-NAT IP. New 
> connections from guests that are destined for public networks are processed 
> like so:
> 1. Traffic is matched against the following rule in the mangle table that 
> marks the connection with a 0x0:
> *mangle
> -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark 
> 0x0/0x
> 2. There are no "ip rule" statements that match a connection marked 0x0, so 
> the kernel routes the connection via the default gateway. That gateway is on 
> source-NAT subnet, so the connection is routed out of eth2.
> 3. The following iptables rules are then matched in the filter table:
> *filter
> -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND
> -A FW_OUTBOUND -j FW_EGRESS_RULES
> -A FW_EGRESS_RULES -j ACCEPT
> 4. Finally, the following rule is matched from the nat table, where the IP 
> address is the source-NAT IP:
> *nat
> -A POSTROUTING -o eth2 -j SNAT --to-source 123.4.5.67
>  



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

[jira] [Commented] (CLOUDSTACK-9451) stopVirtualMachine ignores forced parameter

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681540#comment-15681540
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9451:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1635
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-203


> stopVirtualMachine ignores forced parameter
> ---
>
> Key: CLOUDSTACK-9451
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9451
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Management Server
>Affects Versions: 4.8.0, 4.9.0
>Reporter: Nathan Johnson
>Priority: Minor
>
> As reported by Jeff Hair from the mailing list:
> Hi,
> I'm looking at the documentation and then the code for stopVirtualMachine.
> The forced parameter is passed down into the VM manager, where it seems to
> be ignored. This means that cleanupEvenIfFailed during VM stop will always
> be false, despite what the API command says. Going back to commit a4f4c986
> in 2013, we can see that the forced parameter was used. During subsequent
> refactoring, this seems to have vanished.



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

[jira] [Commented] (CLOUDSTACK-4858) Disable copy snapshot to secondary storage snapshot.backup.rightafter

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681501#comment-15681501
 ] 

ASF GitHub Bot commented on CLOUDSTACK-4858:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1697
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-200


> Disable copy snapshot to secondary storage snapshot.backup.rightafter
> -
>
> Key: CLOUDSTACK-4858
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4858
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.2.0
> Environment: kvm, rbd
>Reporter: Sebastian Igerl
>
> "snapshot.backup.rightafterbackup"  is set to false but still the snapshot is 
> copied to secondary storage.
> Primary storage is Ceph/RDB, Secondary is NFS. I restarted both the 
> management server and the nodes.
> see : 
> http://www.marshut.com/wpviz/disable-copy-snapshot-to-secondary-storage-in-cs-4-2.html



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

[jira] [Commented] (CLOUDSTACK-9507) Make listVM cmd response's guest os type field consistent with listTemplate reponse's

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681481#comment-15681481
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9507:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1686
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-199


> Make listVM cmd response's guest os type field consistent with listTemplate 
> reponse's
> -
>
> Key: CLOUDSTACK-9507
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9507
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: Future, 4.10.0.0, 4.9.2.0, 4.9.1.0
>
>
> list virtualmachines response's ostypeid returned is an integer while, the 
> list templates API returns a uuid in the ostypeid key. The fix would be to 
> make the API consistent for users to only/always return uuids as id/integers 
> may not be consumable.



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

[jira] [Commented] (CLOUDSTACK-9489) When upgrading, Config.java new configuration are not updated.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681475#comment-15681475
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9489:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1684
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-198


> When upgrading, Config.java new configuration are not updated.
> --
>
> Key: CLOUDSTACK-9489
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9489
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>Priority: Blocker
>
> When Upgrading CloudStack, new configurations (Global Settings) defined in  
> {{server/src/com/cloud/configuration/Config.java}} are not populated.
> This file changed in 4.5 and 4.6 and those configurations are not applied 
> when upgrading to post 4.6.



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

[jira] [Commented] (CLOUDSTACK-9563) ExtractTemplate returns malformed URL after migrating NFS to s3

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681443#comment-15681443
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9563:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1733
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-186


> ExtractTemplate returns malformed URL after migrating NFS to s3
> ---
>
> Key: CLOUDSTACK-9563
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9563
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>




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

[jira] [Commented] (CLOUDSTACK-9558) Cleanup the snapshots on the primary storage of Xenserver after VM/Volume is expunged

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681439#comment-15681439
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9558:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1722
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-188


> Cleanup the snapshots on the primary storage of Xenserver after VM/Volume is 
> expunged
> -
>
> Key: CLOUDSTACK-9558
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9558
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
> Environment: Xen Server
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> Steps to reproduce the issue
> ===
> i) Deploy a new VM in CCP on Xenserver
> ii) Create a snapshot for the volume created in step i) from CCP. This step 
> will create a snapshot on the primary storage and keeps it on storage as we 
> use it as reference for the incremental snapshots
> iii) Now destroy and expunge the VM created in step i)
> You will notice that the volume for the VM ( created in step i) is deleted 
> from the primary storage. However the snapshot created on primary ( as part 
> of step ii)) still exists on the primary and this needs to be deleted 
> manually by the admin.
> Snapshot exists on the primary storage even after deleting the Volume.



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

[jira] [Commented] (CLOUDSTACK-9359) Return ip6address in Basic Networking

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681348#comment-15681348
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9359:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1700
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-194


> 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-9538) Deleting Snapshot From Primary Storage Fails on RBD Storage if you already delete vm's itself

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681340#comment-15681340
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9538:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1710
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-191


> Deleting Snapshot From Primary Storage Fails on RBD Storage if you already 
> delete vm's itself
> -
>
> Key: CLOUDSTACK-9538
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9538
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Snapshot, Storage Controller
>Affects Versions: 4.9.0
> Environment: Ubuntu 14.04 Management Server +  Ubuntu 14.04 KVM
>Reporter: Özhan Rüzgar Karaman
>
> Hi;
> We plan to store vm snapshots as vm backups on secondary storage while we 
> still destroyed/expunged related vm. The idea is good there was a bug which 
> blocks this idea to work and it was fixed with CLOUDSTACK-9297 bug. 
> Normally with 4.9 release we expected this idea to work on our on our 4.9 ACS 
> environment but we noticed that because we are using rbd as primary storage 
> we need to fix one minor bug for this idea to work.
> The problem occurs because CLOUDSTACK-8302 bug fixed on 4.9 release and it 
> block our idea to work. If you destroy a vm which is on RBD Storage as 
> primary storage it also deletes any related snapshots of that vm on Primary 
> RBD Storage. So after vm destroy no disk file or snapshot file over RBD 
> Storage. This is good for cleanup purposes on primary storage but 
> XenserverSnapshotStrategy.deleteSnapshot class method did not expect this to 
> happen.
> org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.deleteSnapshot
>  method receives exception. The code tries 10 times on KVM node to remove RBD 
> snapshot but because there is no snapshot on RBD side it get exception after 
> 10 retries, it also spends nearly 5 minutes to delete snapshots and after 
> that it ends with an error like "Failed to delete snapshot" error.
> I think we need to disable snapshot cleanup on primary storage only for RBD 
> type Primary Storage if its related vm was already been destroyed. (Because 
> vm destroy stage removed all snapshots related to vm on primary storage so 
> there is no need to take any action on primary storage.)
> We make some tests below to make this issue clear for bug.
> 1) We create a vm with 3 snapshots on ACS.
> mysql> select * from snapshot_store_ref where snapshot_id in (93,94,95);
> +-+--+-+-+--+++-+---+++---+--+-+-+---+
> | id  | store_id | snapshot_id | created | last_updated | job_id 
> | store_role | size| physical_size | parent_snapshot_id | 
> install_path  
>  | state | update_count | ref_cnt | updated | volume_id |
> +-+--+-+-+--+++-+---+++---+--+-+-+---+
> | 185 |1 |  93 | 2016-10-12 10:13:44 | NULL | NULL   
> | Primary| 28991029248 |   28991029248 |  0 | 
> cst4/bb9ca3c7-96d6-4465-85b5-cd01f4d635f2/54008bf3-43dd-469d-91a7-4acd146d7b84
>  | Ready |2 |   0 | 2016-10-12 10:13:45 |  4774 |
> | 186 |1 |  93 | 2016-10-12 10:13:45 | NULL | NULL   
> | Image  | 28991029248 |   28991029248 |  0 | 
> snapshots/2/4774/54008bf3-43dd-469d-91a7-4acd146d7b84 
>  | Ready |2 |   0 | 2016-10-12 10:15:04 |  4774 |
> | 187 |1 |  94 | 2016-10-12 10:15:38 | NULL | NULL   
> | Primary| 28991029248 |   28991029248 |  0 | 
> cst4/bb9ca3c7-96d6-4465-85b5-cd01f4d635f2/45fc4f44-b377-49c0-9264-5d813fefe93f
>  | Ready |2 |   0 | 2016-10-12 10:15:39 |  4774 |
> | 188 |1 |  94 | 2016-10-12 10:15:39 | NULL | NULL   
> | Image  | 28991029248 |   28991029248 |  0 | 
> snapshots/2/4774/45fc4f44-b377-49c0-9264-5d813fefe93f 
>  | Ready |2 |   0 | 2016-10-12 10:16:52 |  4774 |
> | 189 |1 |  95 | 

[jira] [Commented] (CLOUDSTACK-9498) VR CsFile search utility methods fail when search string has char *, + etc

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681337#comment-15681337
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9498:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1680
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-197


> VR CsFile search utility methods fail when search string has char *, + etc
> --
>
> Key: CLOUDSTACK-9498
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9498
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.2, 4.7.1, 4.8.0, 4.8.1, 4.9.0
>Reporter: Murali Reddy
>Assignee: Murali Reddy
> Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0
>
>
> VR CsFile search utility methods fail when search string has char *, + etc.
> These utility methods in CsFile [1] uses python regular expression module to 
> search a string in a file. However, if caller passes a search string, that 
> has chars *, +, . etc that are also happen to be express wild card / match 
> expression in regular expression results in exceptions from python 're' 
> module.
> For instance searching for VPN user [2] passes "username * password *" as 
> search string, if password has chars the interfer with regular expression 
> metacharecters then search will result in exception.
> 2016-09-12 13:55:48,976 configure.py add_l2tp_ipsec_user:569 Adding vpn user 
> murali * abcd++efgh## *
> 2016-09-12 13:55:48,976 CsFile.py load:39 Reading file /etc/ppp/chap-secrets
> 2016-09-12 13:55:48,976 CsFile.py searchString:140 Searching for murali * 
> abcd++efgh## * string
> 2016-09-12 13:55:48,976 configure.py main:1020 Exception while configuring 
> router
> Traceback (most recent call last):
> File "/opt/cloud/bin/configure.py", line 965, in main
> vpnuser.process()
> File "/opt/cloud/bin/configure.py", line 559, in process
> self.add_l2tp_ipsec_user(user, userconfig)
> File "/opt/cloud/bin/configure.py", line 572, in add_l2tp_ipsec_user
> userfound = file.searchString(userSearchEntry, '#')
> File "/opt/cloud/bin/cs/CsFile.py", line 146, in searchString
> if re.search(search, line):
> File "/usr/lib/python2.7/re.py", line 142, in search
> return _compile(pattern, flags).search(string)
> File "/usr/lib/python2.7/re.py", line 242, in _compile
> raise error, v # invalid expression
> 1 
> https://github.com/apache/cloudstack/blob/master/systemvm/patches/debian/config/opt/cloud/bin/cs/CsFile.py
> 2 
> https://github.com/apache/cloudstack/blob/master/systemvm/patches/debian/config/opt/cloud/bin/configure.py#L572



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

[jira] [Commented] (CLOUDSTACK-9397) Add Watchdog timer to KVM Instances

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681339#comment-15681339
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9397:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1707
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-196


> Add Watchdog timer to KVM Instances
> ---
>
> Key: CLOUDSTACK-9397
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9397
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: kvm, libvirt, watchdog
>
> A Watchdog timer can be used by the hypervisor to verify if an Instance is 
> still alive. If not, for example due to a kernel panic the HV can reset the 
> Instance so that it boots again.
> Inside the Instance the 'watchdog' daemon has to run to provide this. If the 
> Watchdog is not running the HV can't verify if the Instance has crashed.
> This is supported by Libvirt and Qemu and can be configured in the XML: 
> https://libvirt.org/formatdomain.html#elementsWatchdog



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

[jira] [Commented] (CLOUDSTACK-9555) when a template is deleted and then copied over again , it is still marked as Removed in template_zone_ref table

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681338#comment-15681338
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9555:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1716
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-193


> when a template is deleted and then copied over again , it is still marked as 
> Removed in template_zone_ref table
> 
>
> Key: CLOUDSTACK-9555
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9555
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.9.0
> Environment: All Hypervisors
>Reporter: subhash yedugundla
> Fix For: 4.10.0.0
>
>
> Charging of template stops in the following use case
> Step1:Register a Template(Name:A) to Zone1
> Step2:Copy the template(Name:A) to Zone 2
> Step3:Delete the template(Name:A) of only Zone2
> Step4:Copy the template(Name:A) to Zone 2
> Step5:Check the charging of the template



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

[jira] [Commented] (CLOUDSTACK-9567) Difference in the api call outputs for CAPACITY_TYPE_CPU = 1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681335#comment-15681335
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9567:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1734
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-187


> Difference in the api call outputs for CAPACITY_TYPE_CPU = 1
> 
>
> Key: CLOUDSTACK-9567
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9567
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>
> The total capacity reported is different, ideally they have to be same
> http://10.223.59.69:8096/client/api?command=listPods=78c23ee6-c585-4065-a03c-08c15492c077=48889c46-dd04-4a50-af06-8aad7ea46f61=true
> 
> 1
> 1042980
> 1621776
> 64.31
> 
> http://10.223.59.69:8096/client/api?command=listCapacity=78c23ee6-c585-4065-a03c-08c15492c077=48889c46-dd04-4a50-af06-8aad7ea46f61=1
> 
> 1
> 
> 1
> 48889c46-dd04-4a50-af06-8aad7ea46f61
> jp2-east01
> 78c23ee6-c585-4065-a03c-08c15492c077
> RG1-ck2ejo2-Pod11
> 1042980
> 2453456
> 42.51
> 
> 



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

[jira] [Commented] (CLOUDSTACK-9500) VR configuration not clean properly after Public IP release

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681317#comment-15681317
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9500:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1706
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-195


> 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-9566) instance-id metadata for baremetal VM returns ID

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681280#comment-15681280
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9566:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1738
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-182


> instance-id metadata for baremetal VM returns ID
> 
>
> Key: CLOUDSTACK-9566
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9566
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>
> On Baremetal 
> [root@ip-172-17-0-144 ~]# curl 
> http://8.37.203.221/latest/meta-data/instance-id
> 6021
> on Xen 
> [root@ip-172-17-2-103 ~]# curl 
> http://172.17.0.252/latest/meta-data/instance-id
> cbeb517a-e833-4a0c-b1e8-9ed70200fbbf



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

[jira] [Commented] (CLOUDSTACK-9572) Snapshot on primary storage not cleaned up after Storage migration

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681284#comment-15681284
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9572:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1740
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-183


> Snapshot on primary storage not cleaned up after Storage migration
> --
>
> Key: CLOUDSTACK-9572
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9572
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller
>Affects Versions: 4.8.0
> Environment: Xen Server
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> Issue Description
> ===
> 1. Create an instance on the local storage on any host
> 2. Create a scheduled snapshot of the volume:
> 3. Wait until ACS created the snapshot. ACS is creating a snapshot on local 
> storage and is transferring this snapshot to secondary storage. But the 
> latest snapshot on local storage will stay there. This is as expected.
> 4. Migrate the instance to another XenServer host with ACS UI and Storage 
> Live Migration
> 5. The Snapshot on the old host on local storage will not be cleaned up and 
> is staying on local storage. So local storage will fill up with unneeded 
> snapshots.



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

[jira] [Commented] (CLOUDSTACK-9570) Bug in listSnapshots for snapshots with deleted data stores

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681282#comment-15681282
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9570:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1735
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-184


> Bug in listSnapshots for snapshots with deleted data stores
> ---
>
> Key: CLOUDSTACK-9570
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9570
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> If there is snapshot on a data store that is removed, {{listSnapshots}} still 
> tries to enumerate it and gives error (in this example data store 2 has been 
> removed):
> {code:xml|title=/client/api?command=listSnapshots=true=true|borderStyle=solid}
> 
>530
>4250
>Unable to locate datastore with id 2
> 
> {code}
> h3. Reproduce error
> This steps can be followed to reproduce issue:
> * Take a snapshot of a volume (this creates a references for primary storage 
> and secondary storage in snapshot_store_ref table
> * Simulate retiring primary data storage where snapshot is cached (in this 
> example X is a fake data store and Y is snapshot id):
> {{UPDATE `cloud`.`snapshot_store_ref` SET `store_id`='X', `state`="Destroyed" 
> WHERE `id`='Y';}}
> * List snapshots
> {{/client/api?command=listSnapshots=true=true}}



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

[jira] [Commented] (CLOUDSTACK-9560) Root volume of deleted VM left unremoved

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681283#comment-15681283
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9560:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1726
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-190


> Root volume of deleted VM left unremoved
> 
>
> Key: CLOUDSTACK-9560
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9560
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
> Environment: XenServer
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> In the following scenario root volume gets unremoved
> Steps to reproduce the issue
> 1. Create a VM.
> 2. Stop this VM.
> 3. On the page of the volume of the VM, click 'Download Volume' icon.
> 4. Wait for the popup screen to display and cancel out with/without clicking 
> the download link.
> 5. Destroy the VM
> Even after the corresponding VM is deleted,expunged, the root-volume is left 
> in 'Expunging' state unremoved.



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

[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681220#comment-15681220
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9539:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1727
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



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

[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681218#comment-15681218
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9539:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1727
  
@blueorangutan package


> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



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

[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681217#comment-15681217
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9539:


Github user nvazquez commented on the issue:

https://github.com/apache/cloudstack/pull/1727
  
@rhtyd Sure, rebased


> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



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

[jira] [Commented] (CLOUDSTACK-9416) ACS master GUI: Enabling Static NAT on an associated Public IP to one of the NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP being sel

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681206#comment-15681206
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9416:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1592
  
LGTM on code change. Screenshots look alright as well.


> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI
> ---
>
> Key: CLOUDSTACK-9416
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9416
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
> Attachments: network1.png, network2.png
>
>
> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI:
> {noformat}
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'alertManagerImpl'
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.nat.EnableStaticNatCmd': 
> AutowiredFieldElement for public com.cloud.utils.db.UUIDManager 
> org.apache.cloudstack.api.BaseCmd._uuidMgr
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'uUIDManagerImpl'
> 2016-06-13 04:50:00,472 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'messageBus'
> 2016-06-13 04:50:00,479 INFO  [c.c.a.ApiServer] (catalina-exec-7:ctx-83926837 
> ctx-fc7aa5ed) VM ip 10.10.2.163 address not belongs to the vm
> 2016-06-13 04:50:00,480 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) ===END===  10.31.56.146 -- GET  
> command=enableStaticNat=json=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D=36262bcc-282a-46c2-8a80-472e2a24ab5e=af160cde-6762-4756-b97f-f3829f6d9802=10.10.2.163&_=1465818687943
> 2016-06-13 04:50:02,261 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-9:ctx-6050366f) ===START===  10.31.56.146 -- GET  
> command=queryAsyncJobResult=7850c125-54a2-4e99-ab78-9f0e3578c304=json=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&_=1465818689752
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.configuration.ConfigurationService 
> org.apache.cloudstack.api.BaseCmd._configService
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Returning cached instance of 
> singleton bean 'configurationManagerImpl'
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.user.AccountService 
> org.apache.cloudstack.api.BaseCmd._accountService
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Returning cached instance of 
> singleton bean 'accountManagerImpl'
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.vm.UserVmService 
> org.apache.cloudstack.api.BaseCmd._userVmService
> {noformat}



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

[jira] [Commented] (CLOUDSTACK-8781) Superfluous field during VPC creation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681204#comment-15681204
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8781:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/756
  
I'm not sure about the changes, but if the mentioned field is not consumed 
anywhere, it LGTM. Can we have a manual UI screenshot to confirm changes since 
this is a pure UI change?


> Superfluous field during VPC creation
> -
>
> Key: CLOUDSTACK-8781
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8781
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.6.0
>Reporter: Nick Livens
>Assignee: Nick Livens
>Priority: Trivial
> Fix For: Future
>
> Attachments: addVpc.png
>
>
> When creating a VPC, there is a superfluous field "Public Load Balancer 
> Provider" which is being ignored since the LB Provider is specified in the 
> VPC offering. This might confuse the users whether they can use a different 
> LB provider than the one specified in the VPC offering.



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

[jira] [Commented] (CLOUDSTACK-9561) After domain/account deletion, snapshot taken by the domain/account remains undeleted

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681198#comment-15681198
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9561:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1737
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-181


> After domain/account deletion, snapshot taken by the domain/account remains 
> undeleted
> -
>
> Key: CLOUDSTACK-9561
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9561
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>
> While deleting the UserAccount Cleanup for the removed VMs/volumes are not 
> happening. For the removed VMs, snapshots doesn't get cleaned. Only for 
> volumes in ready state the cleanup happens.



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

[jira] [Commented] (CLOUDSTACK-9574) Redesign storage views

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681171#comment-15681171
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9574:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1747
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-180


> Redesign storage views
> --
>
> Key: CLOUDSTACK-9574
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9574
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, UI
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Attachments: PS-DETAILS.PNG, PS.PNG
>
>
> h2. Part 1: Redesign storage tags
> h3. Actual behavior
> Primary storage tags are being saved as an entry on {{storage_pool_details}} 
> with:
> * name = TAG_NAME
> * value = "true"
> When a boolean property is defined in {{storage_pool_details}} and has value 
> = "true", it is displayed as a tag.
> !https://issues.apache.org/jira/secure/attachment/12836196/PS-DETAILS.PNG!
> !https://issues.apache.org/jira/secure/attachment/12836195/PS.PNG!
> h3. Goal
> Redesign {{Storage Tags}} for Primary Storage view, to list only tags, as it 
> is done in Host Tags (Hosts view).
> h2. Part 2: Remove details from listImageStores API call response and UI
> h3. Description
> In Secondary Storage view we propose removing Details field, as Setting tab 
> list details for a given image store. We also remove details from response on 
> listImageStores API method



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

[jira] [Commented] (CLOUDSTACK-8781) Superfluous field during VPC creation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681154#comment-15681154
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8781:


Github user prashanthvarma commented on the issue:

https://github.com/apache/cloudstack/pull/756
  
@rhtyd, rebased against latest master


> Superfluous field during VPC creation
> -
>
> Key: CLOUDSTACK-8781
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8781
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.6.0
>Reporter: Nick Livens
>Assignee: Nick Livens
>Priority: Trivial
> Fix For: Future
>
> Attachments: addVpc.png
>
>
> When creating a VPC, there is a superfluous field "Public Load Balancer 
> Provider" which is being ignored since the LB Provider is specified in the 
> VPC offering. This might confuse the users whether they can use a different 
> LB provider than the one specified in the VPC offering.



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

[jira] [Commented] (CLOUDSTACK-9416) ACS master GUI: Enabling Static NAT on an associated Public IP to one of the NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP being sel

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681146#comment-15681146
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9416:


Github user prashanthvarma commented on the issue:

https://github.com/apache/cloudstack/pull/1592
  
@rhtyd Rebased this PR with latest master.


> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI
> ---
>
> Key: CLOUDSTACK-9416
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9416
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
> Attachments: network1.png, network2.png
>
>
> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI:
> {noformat}
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'alertManagerImpl'
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.nat.EnableStaticNatCmd': 
> AutowiredFieldElement for public com.cloud.utils.db.UUIDManager 
> org.apache.cloudstack.api.BaseCmd._uuidMgr
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'uUIDManagerImpl'
> 2016-06-13 04:50:00,472 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'messageBus'
> 2016-06-13 04:50:00,479 INFO  [c.c.a.ApiServer] (catalina-exec-7:ctx-83926837 
> ctx-fc7aa5ed) VM ip 10.10.2.163 address not belongs to the vm
> 2016-06-13 04:50:00,480 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) ===END===  10.31.56.146 -- GET  
> command=enableStaticNat=json=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D=36262bcc-282a-46c2-8a80-472e2a24ab5e=af160cde-6762-4756-b97f-f3829f6d9802=10.10.2.163&_=1465818687943
> 2016-06-13 04:50:02,261 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-9:ctx-6050366f) ===START===  10.31.56.146 -- GET  
> command=queryAsyncJobResult=7850c125-54a2-4e99-ab78-9f0e3578c304=json=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&_=1465818689752
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.configuration.ConfigurationService 
> org.apache.cloudstack.api.BaseCmd._configService
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Returning cached instance of 
> singleton bean 'configurationManagerImpl'
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.user.AccountService 
> org.apache.cloudstack.api.BaseCmd._accountService
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Returning cached instance of 
> singleton bean 'accountManagerImpl'
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.vm.UserVmService 
> org.apache.cloudstack.api.BaseCmd._userVmService
> {noformat}



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

[jira] [Commented] (CLOUDSTACK-9588) Add Load Balancer functionality in Network page is redundant.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681125#comment-15681125
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9588:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1758
  
Packaging result: ✖centos6 ✔centos7 ✔debian. JID-173


> Add Load Balancer functionality in Network page is redundant.
> -
>
> Key: CLOUDSTACK-9588
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9588
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Steps to Reproduce:
> Network -> Select any network -> Observer Add Load Balancer tab
> The "Add Load Balancer" functionality is redundant.
> The above is used to create LB rule without any public IP.
> Resolution:
> There exist similar functionality in Network -> Any Network -> Details Tab -> 
> View IP Addresses -> Any public IP -> Configuration Tab -> Observe Load 
> Balancing.
> The above is used to create LB rule with a public IP. This is a more 
> convenient way of creating LB rule as the IP is involved.



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

[jira] [Commented] (CLOUDSTACK-9589) vmName entries from host_details table for the VM's whose state is Expunging should be deleted during upgrade from older versions

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681126#comment-15681126
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9589:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1759
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-174


> vmName entries from host_details table for the VM's whose state is Expunging 
> should be deleted during upgrade from older versions
> -
>
> Key: CLOUDSTACK-9589
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9589
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Baremetal
>Affects Versions: 4.4.4
> Environment: Baremetal zone
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> Having vmName entries for VMs in 'expunging' states would cause with 
> deploying VMs with matching host tags fail. So removing them during upgrade



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

[jira] [Commented] (CLOUDSTACK-9583) VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681114#comment-15681114
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9583:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1757
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-172


> VR: In CsDhcp.py preseed both hostaname and localhost to resolve to 127.0.0.1
> -
>
> Key: CLOUDSTACK-9583
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9583
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Murali Reddy
> Fix For: 4.9.1.0
>
>
> It is observed that  'ip route flush' was timing out after 20 seconds with 
> the error that can't resolve the name of the vrouter. Since this is done for 
> each rule for a router with a lot of rules, adding the entry to hosts file 
> fixes it and the router provisioning is observed faster. 



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

[jira] [Commented] (CLOUDSTACK-9598) wrong defaut gateway in guest VM with nics in isolated and a shared network

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681096#comment-15681096
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9598:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1766
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-171


> wrong defaut gateway in guest VM with nics in isolated and a shared network
> ---
>
> Key: CLOUDSTACK-9598
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9598
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Murali Reddy
> Fix For: 4.8.1, 4.10.0.0, 4.9.1.0
>
>
> When a guest instance is created with nic's in a isolated network and a 
> shared network (with just DHCP and DNS), with isolated network as default 
> network, DHCP lease on shared network from the shared network VR has wrong 
> gateway. gateway is pointed to the virtual router IP. 
> /etc/cloudstack/dhcpentry.json in shared network VR will have default gateway 
> set to 0.0.0.0
> root@r-11-VM:~# cat /etc/cloudstack/dhcpentry.json
> {
> "10.6.9.165": {
> "default_entry": false,
> "default_gateway": "0.0.0.0",
> "dns_adresses": "10.1.1.1",
> "host_name": "VM-fce34d73-dc99-4559-b077-64711509907a",
> "ipv4_adress": "10.6.9.165",
> "ipv6_duid": "00:03:00:01:06:5a:da:00:00:6a",
> "mac_address": "06:5a:da:00:00:6a",
> "type": "dhcpentry"
> },
> "id": "dhcpentry"
> DhcpCommand network element command sent from the management server is like 
> below with "defaultRouter":"0.0.0.0"
> 2016-11-15 19:15:29,319 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-25:ctx-a9aca0bb job-69/job-70 ctx-82c3fd7e) 
> (logid:6ca37cdb) Seq 2-4650811040190170578: Sending  { Cmd , MgmtId: 
> 7150818625286, via: 2(trl-202-k-cs49-mreddy-kvm2), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.routing.DhcpEntryCommand":{"vmMac":"06:5a:da:00:00:6a","vmIpAddress":"10.6.9.165","vmName":"VM-fce34d73-dc99-4559-b077-64711509907a","defaultRouter":"0.0.0.0","defaultDns":"10.1.1.1","duid":"00:03:00:01:06:5a:da:00:00:6a","isDefault":false,"executeInSequence":false,"accessDetails":{"zone.network.type":"Advanced","router.guest.ip":"10.6.9.164","router.ip":"169.254.2.18","router.name":"r-11-VM"},"wait":0}}]
>  }
> NIC details in the DB for the nic in the shared network has correct gateway.
> Gateway is set to 0.0.0.0, for every non-default nic [1]
> In case where shared network is non default network, then guest VM will end 
> up treating VR in the shared network as gateway instead of actual shared 
> network gateway.
> [1] 
> https://github.com/apache/cloudstack/blob/4.9/server/src/com/cloud/network/router/CommandSetupHelper.java#L224



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

[jira] [Commented] (CLOUDSTACK-9597) Incorrect updateResourceCount()

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681046#comment-15681046
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9597:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1764
  
Packaging result: ✔centos6 ✔centos7 ✖debian. JID-169


> Incorrect updateResourceCount()
> ---
>
> Key: CLOUDSTACK-9597
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9597
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Reporter: Marc-Aurèle Brothier
>Assignee: Marc-Aurèle Brothier
>
> h3. Currently
> On management server startup, the {{ConfigurationServerImpl}} does a check on 
> the resource type * resource count versus number of accounts & domains to see 
> if all accounts and domains have a resource count set for each resource type. 
> The list of accounts and domains are fetched excluding the removed ones. But 
> the number of resourceCount by account and domain takes all of them, leading 
> to an incorrect math check.
> The API command {{updateResourceCount}} can crash with an incorrect SQL query.
> I discovered the problem while adding a new {{ResourceType}}.
> h3. Changes
> Fetch the number of resourceCount by domain and account excluding the removed 
> ones.



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

[jira] [Commented] (CLOUDSTACK-9592) Empty responses from site to site connection status are not handled propertly

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15681006#comment-15681006
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9592:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1761
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-167


> Empty responses from site to site connection status are not handled propertly
> -
>
> Key: CLOUDSTACK-9592
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9592
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.8.0
> Environment: Any Hypervisor
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> vpn connection status gives responses like the below sometimes
> Processing: { Ans: , MgmtId: 7203499016310, via: 1(10.147.28.37), Ver: v1, 
> Flags: 110, 
> [{"com.cloud.agent.api.CheckS2SVpnConnectionsAnswer":{"ipToConnected":{},"ipToDetail":{},"details":"","result":true,"wait":0}}]
>  }
> 2016-09-27 08:52:19,211 DEBUG [c.c.a.t.Request] 
> (RouterStatusMonitor-1:ctx-c20f391d) (logid:c217239d) Seq 
> 1-2315413158421863581: Received: { Ans: , MgmtId: 7203499016310, via: 
> 1(10.147.28.37), Ver: v1, Flags: 110,
> { CheckS2SVpnConnectionsAnswer }
> In the above scenario, the bug in the processing of this response assumes the 
> connection is disconnected even though it is not disconnected and there would 
> be two consecutive alerts in logs as well as emails even though there is not 
> actual disconnection and reconnection
> Site-to-site Vpn Connection XYZ-VPN on router r-197-VM(id: 197) just switch 
> from Disconnected to Connected
> Site-to-site Vpn Connection to D1 site to site VPN on router r-372-VM(id: 
> 372) just switch from Connected to Disconnected



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

[jira] [Commented] (CLOUDSTACK-9457) Allow retrieval and modification of VM and template details via API and UI

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680987#comment-15680987
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9457:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1767
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-166


> Allow retrieval and modification of VM and template details via API and UI
> --
>
> Key: CLOUDSTACK-9457
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9457
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.10.0.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>Priority: Minor
>
> h2. Introduction
> As suggested on [9379|https://issues.apache.org/jira/browse/CLOUDSTACK-9379], 
> it would be nice to be able to customize vm details through API



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

[jira] [Commented] (CLOUDSTACK-9379) Support nested virtualization at VM level on VMware Hypervisor

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680828#comment-15680828
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9379:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1542
  
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + vmware-55u3) has been 
kicked to run smoke tests


> Support nested virtualization at VM level on VMware Hypervisor
> --
>
> Key: CLOUDSTACK-9379
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9379
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.9.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> h2. Introduction
> It is desired to support nested virtualization at VM level for VMware 
> hypervisor. Current behaviour supports enabling/desabling global nested 
> virtualization by modifying global config {{'vmware.nested.virtualization'}}. 
> It is wished to improve this feature, having control at VM level instead of a 
> global control only.
> h2. Proposal
> A new global configuration is added, to enable/disable VM nested 
> virtualization control: {{'vmware.nested.virtualization.perVM'}}. Default 
> value=false
> h2. Behaviour
> After a vm deployment or start command, vm params include 
> {{nestedVirtualizationFlag}} key and its value is:
> * true -> nested virtualization enabled
> * false -> nested virtualization disabled
> We will determinate nested virtualization enabled/disabled by examining:
> * (1) global configuration {{'vmware.nested.virtualization'}} value
> * (2) global configuration {{'vmware.nested.virtualization.perVM'}} value
> * (3) {{'nestedVirtualizationFlag'}} value in {{user_vm_details}} if present, 
> null if not.
> Using this 3 values, there are different use cases:
> # (1) = TRUE, (2) = TRUE, (3) is null -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = TRUE, (2) = FALSE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) is null -> DISABLED
> # (1) = FALSE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = FALSE, (2) = FALSE -> DISABLED



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

[jira] [Commented] (CLOUDSTACK-9379) Support nested virtualization at VM level on VMware Hypervisor

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680827#comment-15680827
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9379:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1542
  
@blueorangutan test centos7 vmware-55u3


> Support nested virtualization at VM level on VMware Hypervisor
> --
>
> Key: CLOUDSTACK-9379
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9379
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.9.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> h2. Introduction
> It is desired to support nested virtualization at VM level for VMware 
> hypervisor. Current behaviour supports enabling/desabling global nested 
> virtualization by modifying global config {{'vmware.nested.virtualization'}}. 
> It is wished to improve this feature, having control at VM level instead of a 
> global control only.
> h2. Proposal
> A new global configuration is added, to enable/disable VM nested 
> virtualization control: {{'vmware.nested.virtualization.perVM'}}. Default 
> value=false
> h2. Behaviour
> After a vm deployment or start command, vm params include 
> {{nestedVirtualizationFlag}} key and its value is:
> * true -> nested virtualization enabled
> * false -> nested virtualization disabled
> We will determinate nested virtualization enabled/disabled by examining:
> * (1) global configuration {{'vmware.nested.virtualization'}} value
> * (2) global configuration {{'vmware.nested.virtualization.perVM'}} value
> * (3) {{'nestedVirtualizationFlag'}} value in {{user_vm_details}} if present, 
> null if not.
> Using this 3 values, there are different use cases:
> # (1) = TRUE, (2) = TRUE, (3) is null -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = TRUE, (2) = FALSE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) is null -> DISABLED
> # (1) = FALSE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = FALSE, (2) = FALSE -> DISABLED



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

[jira] [Commented] (CLOUDSTACK-9595) Transactions are not getting retried in case of database deadlock errors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680825#comment-15680825
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9595:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1762
  
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been 
kicked to run smoke tests


> Transactions are not getting retried in case of database deadlock errors
> 
>
> Key: CLOUDSTACK-9595
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9595
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.8.0
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> Customer is seeing occasional error 'Deadlock found when trying to get lock; 
> try restarting transaction' messages in their management server logs.  It 
> happens regularly at least once a day.  The following is the error seen 
> 2015-12-09 19:23:19,450 ERROR [cloud.api.ApiServer] 
> (catalina-exec-3:ctx-f05c58fc ctx-39c17156 ctx-7becdf6e) unhandled exception 
> executing api command: [Ljava.lang.String;@230a6e7f
> com.cloud.utils.exception.CloudRuntimeException: DB Exception on: 
> com.mysql.jdbc.JDBC4PreparedStatement@74f134e3: DELETE FROM 
> instance_group_vm_map WHERE instance_group_vm_map.instance_id = 941374
>   at com.cloud.utils.db.GenericDaoBase.expunge(GenericDaoBase.java:1209)
>   at sun.reflect.GeneratedMethodAccessor360.invoke(Unknown Source)
>   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 
> com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
>   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.$Proxy237.expunge(Unknown Source)
>   at 
> com.cloud.vm.UserVmManagerImpl$2.doInTransactionWithoutResult(UserVmManagerImpl.java:2593)
>   at 
> com.cloud.utils.db.TransactionCallbackNoReturn.doInTransaction(TransactionCallbackNoReturn.java:25)
>   at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:57)
>   at com.cloud.utils.db.Transaction.execute(Transaction.java:45)
>   at com.cloud.utils.db.Transaction.execute(Transaction.java:54)
>   at 
> com.cloud.vm.UserVmManagerImpl.addInstanceToGroup(UserVmManagerImpl.java:2575)
>   at 
> com.cloud.vm.UserVmManagerImpl.updateVirtualMachine(UserVmManagerImpl.java:2332)



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

[jira] [Commented] (CLOUDSTACK-9595) Transactions are not getting retried in case of database deadlock errors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680824#comment-15680824
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9595:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1762
  
@blueorangutan test


> Transactions are not getting retried in case of database deadlock errors
> 
>
> Key: CLOUDSTACK-9595
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9595
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.8.0
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> Customer is seeing occasional error 'Deadlock found when trying to get lock; 
> try restarting transaction' messages in their management server logs.  It 
> happens regularly at least once a day.  The following is the error seen 
> 2015-12-09 19:23:19,450 ERROR [cloud.api.ApiServer] 
> (catalina-exec-3:ctx-f05c58fc ctx-39c17156 ctx-7becdf6e) unhandled exception 
> executing api command: [Ljava.lang.String;@230a6e7f
> com.cloud.utils.exception.CloudRuntimeException: DB Exception on: 
> com.mysql.jdbc.JDBC4PreparedStatement@74f134e3: DELETE FROM 
> instance_group_vm_map WHERE instance_group_vm_map.instance_id = 941374
>   at com.cloud.utils.db.GenericDaoBase.expunge(GenericDaoBase.java:1209)
>   at sun.reflect.GeneratedMethodAccessor360.invoke(Unknown Source)
>   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 
> com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
>   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.$Proxy237.expunge(Unknown Source)
>   at 
> com.cloud.vm.UserVmManagerImpl$2.doInTransactionWithoutResult(UserVmManagerImpl.java:2593)
>   at 
> com.cloud.utils.db.TransactionCallbackNoReturn.doInTransaction(TransactionCallbackNoReturn.java:25)
>   at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:57)
>   at com.cloud.utils.db.Transaction.execute(Transaction.java:45)
>   at com.cloud.utils.db.Transaction.execute(Transaction.java:54)
>   at 
> com.cloud.vm.UserVmManagerImpl.addInstanceToGroup(UserVmManagerImpl.java:2575)
>   at 
> com.cloud.vm.UserVmManagerImpl.updateVirtualMachine(UserVmManagerImpl.java:2332)



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

[jira] [Commented] (CLOUDSTACK-9379) Support nested virtualization at VM level on VMware Hypervisor

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680781#comment-15680781
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9379:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1542
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-165


> Support nested virtualization at VM level on VMware Hypervisor
> --
>
> Key: CLOUDSTACK-9379
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9379
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: VMware
>Affects Versions: 4.9.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.10.0.0
>
>
> h2. Introduction
> It is desired to support nested virtualization at VM level for VMware 
> hypervisor. Current behaviour supports enabling/desabling global nested 
> virtualization by modifying global config {{'vmware.nested.virtualization'}}. 
> It is wished to improve this feature, having control at VM level instead of a 
> global control only.
> h2. Proposal
> A new global configuration is added, to enable/disable VM nested 
> virtualization control: {{'vmware.nested.virtualization.perVM'}}. Default 
> value=false
> h2. Behaviour
> After a vm deployment or start command, vm params include 
> {{nestedVirtualizationFlag}} key and its value is:
> * true -> nested virtualization enabled
> * false -> nested virtualization disabled
> We will determinate nested virtualization enabled/disabled by examining:
> * (1) global configuration {{'vmware.nested.virtualization'}} value
> * (2) global configuration {{'vmware.nested.virtualization.perVM'}} value
> * (3) {{'nestedVirtualizationFlag'}} value in {{user_vm_details}} if present, 
> null if not.
> Using this 3 values, there are different use cases:
> # (1) = TRUE, (2) = TRUE, (3) is null -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = TRUE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = TRUE, (2) = FALSE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) is null -> DISABLED
> # (1) = FALSE, (2) = TRUE, (3) = TRUE -> ENABLED
> # (1) = FALSE, (2) = TRUE, (3) = FALSE -> DISABLED
> # (1) = FALSE, (2) = FALSE -> DISABLED



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

[jira] [Commented] (CLOUDSTACK-9595) Transactions are not getting retried in case of database deadlock errors

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680778#comment-15680778
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9595:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1762
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-164


> Transactions are not getting retried in case of database deadlock errors
> 
>
> Key: CLOUDSTACK-9595
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9595
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.8.0
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> Customer is seeing occasional error 'Deadlock found when trying to get lock; 
> try restarting transaction' messages in their management server logs.  It 
> happens regularly at least once a day.  The following is the error seen 
> 2015-12-09 19:23:19,450 ERROR [cloud.api.ApiServer] 
> (catalina-exec-3:ctx-f05c58fc ctx-39c17156 ctx-7becdf6e) unhandled exception 
> executing api command: [Ljava.lang.String;@230a6e7f
> com.cloud.utils.exception.CloudRuntimeException: DB Exception on: 
> com.mysql.jdbc.JDBC4PreparedStatement@74f134e3: DELETE FROM 
> instance_group_vm_map WHERE instance_group_vm_map.instance_id = 941374
>   at com.cloud.utils.db.GenericDaoBase.expunge(GenericDaoBase.java:1209)
>   at sun.reflect.GeneratedMethodAccessor360.invoke(Unknown Source)
>   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 
> com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
>   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.$Proxy237.expunge(Unknown Source)
>   at 
> com.cloud.vm.UserVmManagerImpl$2.doInTransactionWithoutResult(UserVmManagerImpl.java:2593)
>   at 
> com.cloud.utils.db.TransactionCallbackNoReturn.doInTransaction(TransactionCallbackNoReturn.java:25)
>   at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:57)
>   at com.cloud.utils.db.Transaction.execute(Transaction.java:45)
>   at com.cloud.utils.db.Transaction.execute(Transaction.java:54)
>   at 
> com.cloud.vm.UserVmManagerImpl.addInstanceToGroup(UserVmManagerImpl.java:2575)
>   at 
> com.cloud.vm.UserVmManagerImpl.updateVirtualMachine(UserVmManagerImpl.java:2332)



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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680768#comment-15680768
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8908:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/896
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


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

[jira] [Commented] (CLOUDSTACK-8908) After copying the template charging for that template is stopped

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680767#comment-15680767
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8908:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/896
  
@blueorangutan package


> 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-8715) Add support for qemu-guest-agent to libvirt provider

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680764#comment-15680764
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8715:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1545
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> Add support for qemu-guest-agent to libvirt provider
> 
>
> Key: CLOUDSTACK-8715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Reporter: Sten Spans
>Assignee: Wido den Hollander
>  Labels: kvm, libvirt, qemu, systemvm
> Fix For: Future
>
>
> The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite 
> a lot of useful functionality, which can only be provided by having an agent 
> on the VM. This includes things like freezing/thawing filesystems (for 
> backups), reading files on the guest, listing interfaces / ip addresses, etc.
> This feature has been requested by users, but is currently not implemented.
> http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent
> The first change needed is to add the following to the XML generated for KVM 
> virtual machines,:
> 
>   
>   
> 
> This provides the communication channel between libvirt and the agent on the 
> host. All in all a pretty simple change to LibvirtComputingResource.java / 
> LibvirtVMDef.java
> Secondly the qemu-guest-agent package needs to be added to the systemvm 
> template.



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

[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680763#comment-15680763
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8715:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1545
  
@blueorangutan package


> Add support for qemu-guest-agent to libvirt provider
> 
>
> Key: CLOUDSTACK-8715
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM
>Reporter: Sten Spans
>Assignee: Wido den Hollander
>  Labels: kvm, libvirt, qemu, systemvm
> Fix For: Future
>
>
> The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite 
> a lot of useful functionality, which can only be provided by having an agent 
> on the VM. This includes things like freezing/thawing filesystems (for 
> backups), reading files on the guest, listing interfaces / ip addresses, etc.
> This feature has been requested by users, but is currently not implemented.
> http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent
> The first change needed is to add the following to the XML generated for KVM 
> virtual machines,:
> 
>   
>   
> 
> This provides the communication channel between libvirt and the agent on the 
> host. All in all a pretty simple change to LibvirtComputingResource.java / 
> LibvirtVMDef.java
> Secondly the qemu-guest-agent package needs to be added to the systemvm 
> template.



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

[jira] [Commented] (CLOUDSTACK-9280) System VM volumes cannot be deleted when there are no system VMs

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680761#comment-15680761
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9280:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1559
  
@ProjectMoon can you fix the conflicts, thanks


> System VM volumes cannot be deleted when there are no system VMs
> 
>
> Key: CLOUDSTACK-9280
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9280
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.0, 4.7.0
>Reporter: Jeff Hair
>
> Scenario: When deleting a zone, everything under it must be removed. This 
> results in the system VMs being destroyed as there are no more hosts running.
> The storage cleanup thread properly detects that there are volumes to be 
> deleted, but it cannot delete them because the endpoint selection fails with 
> "No remote endpoint to send DeleteCommand, check if host or ssvm is down?"



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

[jira] [Commented] (CLOUDSTACK-9389) [Automation ]modifying integration/smoke/test_routers_network_ops.py

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680760#comment-15680760
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9389:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1563
  
@nitt10prashant ping


> [Automation ]modifying integration/smoke/test_routers_network_ops.py
> 
>
> Key: CLOUDSTACK-9389
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9389
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Reporter: prashant kumar mishra
>Assignee: prashant kumar mishra
>
> Some test cases were failing due to invalid check_string , proposing 
> following modifications  
> 1-Moving check_string to test_data.py  
> 2-Since ping cmd reply is OS dependent ,for  default templates os type  
> CentOS changing check_string  from "3 packets received" to  "3 received" 
> [root@BPKxDmS ~]# ping -c 3 8.8.8.8
> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
> 64 bytes from 8.8.8.8: icmp_seq=1 ttl=52 time=16.9 ms
> 64 bytes from 8.8.8.8: icmp_seq=2 ttl=52 time=16.7 ms
> 64 bytes from 8.8.8.8: icmp_seq=3 ttl=52 time=17.0 ms
> --- 8.8.8.8 ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2020ms
> rtt min/avg/max/mdev = 16.720/16.896/17.015/0.196 ms



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

[jira] [Commented] (CLOUDSTACK-9321) Multiple Internal LB rules (more than one Internal LB rule with same source IP address) are not getting resolved in the corresponding InternalLbVm instance's hapro

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680758#comment-15680758
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9321:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1577
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> Multiple Internal LB rules (more than one Internal LB rule with same source 
> IP address) are not getting resolved in the corresponding InternalLbVm 
> instance's haproxy.cfg file
> --
>
> Key: CLOUDSTACK-9321
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9321
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Network Controller
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
>Priority: Critical
> Fix For: 4.9.1.0
>
>
> Multiple Internal LB rules (more than one Internal LB rule with same source 
> IP address) are not getting resolved in the corresponding InternalLbVm 
> instance's haproxy.cfg file. Moreover, each time a new Internal LB rule is 
> added to the corresponding InternalLbVm instance, it replaces the existing 
> one. Thus, traffic corresponding to these un-resolved (old) Internal LB rules 
> are getting dropped by the InternalLbVm instance.
> PR contents:
> 1) Fix for this bug.
> 2) Marvin test coverage for Internal LB feature on master with native ACS 
> setup (component directory) including validations for this bug fix.
> 3) Enhancements on our exiting Internal LB Marvin test code (nuagevsp plugins 
> directory) to validate this bug fix.
> 4) PEP8 & PyFlakes compliance with the added Marvin test code.
> Added Marvin test code PEP8 & PyFlakes compliance:
> CloudStack$
> CloudStack$ pep8 --max-line-length=150 
> test/integration/component/test_vpc_network_internal_lbrules.py
> CloudStack$
> CloudStack$ pyflakes 
> test/integration/component/test_vpc_network_internal_lbrules.py
> CloudStack$
> CloudStack$ pep8 --max-line-length=150 test/integration/plugins/nuagevsp/.py
> CloudStack$
> CloudStack$ pyflakes test/integration/plugins/nuagevsp/.py
> CloudStack$
> Validations:
> 1) Made sure that we didn't break any Public LB (VpcVirtualRouter) 
> functionality.
> Marvin test run:
> nosetests --with-marvin --marvin-config=nuage.cfg 
> test/integration/component/test_vpc_network_lbrules.py
> Test results:
> Test case no 210 and 227: List Load Balancing Rules belonging to a VPC ... 
> === TestName: test_01_VPC_LBRulesListing | Status : SUCCESS ===
> ok
> Test Create LB rules for 1 network which is part of a two/multiple virtual 
> networks of a ... === TestName: test_02_VPC_CreateLBRuleInMultipleNetworks | 
> Status : SUCCESS ===
> ok
> Test case no 222 : Create LB rules for a two/multiple virtual networks of a 
> ... === TestName: test_03_VPC_CreateLBRuleInMultipleNetworksVRStoppedState | 
> Status : SUCCESS ===
> ok
> Test case no 222 : Create LB rules for a two/multiple virtual networks of a 
> ... === TestName: test_04_VPC_CreateLBRuleInMultipleNetworksVRStoppedState | 
> Status : SUCCESS ===
> ok
> Test case no 214 : Delete few(not all) LB rules for a single virtual network 
> of a ... === TestName: test_05_VPC_CreateAndDeleteLBRule | Status : SUCCESS 
> ===
> ok
> Test Delete few(not all) LB rules for a single virtual network of ... === 
> TestName: test_06_VPC_CreateAndDeleteLBRuleVRStopppedState | Status : SUCCESS 
> ===
> ok
> Test Delete all LB rules for a single virtual network of a ... === TestName: 
> test_07_VPC_CreateAndDeleteAllLBRule | Status : SUCCESS ===
> ok
> Test Delete all LB rules for a single virtual network of a ... === TestName: 
> test_08_VPC_CreateAndDeleteAllLBRuleVRStoppedState | Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule for a VM that belongs to 
> a different VPC. ... === TestName: test_09_VPC_LBRuleCreateFailMultipleVPC | 
> Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule for a VM that does not 
> belong to any VPC. ... === TestName: 
> test_10_VPC_FailedToCreateLBRuleNonVPCNetwork | Status : SUCCESS ===
> ok
> Test case no 217 and 236: User should not be allowed to create a LB rule for 
> a ... === TestName: test_11_VPC_LBRuleCreateNotAllowed | Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule on an Ipaddress that 
> Source Nat enabled. ... === TestName: test_12_VPC_LBRuleCreateFailForRouterIP 
> | Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule on an Ipaddress that 
> already 

[jira] [Commented] (CLOUDSTACK-9396) [Automation]fixing issue related to script test_dhcphosts

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680757#comment-15680757
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9396:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1573
  
@nitt10prashant can you fix the conflicts, thanks


> [Automation]fixing issue related to script  test_dhcphosts
> --
>
> Key: CLOUDSTACK-9396
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9396
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation
>Reporter: prashant kumar mishra
>Assignee: prashant kumar mishra
>
> fixing following
> 1-issue related to check_String:changed check string to "3 received" and use 
> test_data
> 2-ssh to router based on hypervisor type : check if it is vmware ssh to ms 
> else ssh to host
> 3-rename method : because of test_  methods were getting picked up as a test 
> cases ,renamed them not to get picked up as a test method
> 4- modifying  awk  parameter from $2 to $3



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

[jira] [Commented] (CLOUDSTACK-9321) Multiple Internal LB rules (more than one Internal LB rule with same source IP address) are not getting resolved in the corresponding InternalLbVm instance's hapro

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680756#comment-15680756
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9321:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1577
  
@blueorangutan package


> Multiple Internal LB rules (more than one Internal LB rule with same source 
> IP address) are not getting resolved in the corresponding InternalLbVm 
> instance's haproxy.cfg file
> --
>
> Key: CLOUDSTACK-9321
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9321
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Network Controller
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
>Priority: Critical
> Fix For: 4.9.1.0
>
>
> Multiple Internal LB rules (more than one Internal LB rule with same source 
> IP address) are not getting resolved in the corresponding InternalLbVm 
> instance's haproxy.cfg file. Moreover, each time a new Internal LB rule is 
> added to the corresponding InternalLbVm instance, it replaces the existing 
> one. Thus, traffic corresponding to these un-resolved (old) Internal LB rules 
> are getting dropped by the InternalLbVm instance.
> PR contents:
> 1) Fix for this bug.
> 2) Marvin test coverage for Internal LB feature on master with native ACS 
> setup (component directory) including validations for this bug fix.
> 3) Enhancements on our exiting Internal LB Marvin test code (nuagevsp plugins 
> directory) to validate this bug fix.
> 4) PEP8 & PyFlakes compliance with the added Marvin test code.
> Added Marvin test code PEP8 & PyFlakes compliance:
> CloudStack$
> CloudStack$ pep8 --max-line-length=150 
> test/integration/component/test_vpc_network_internal_lbrules.py
> CloudStack$
> CloudStack$ pyflakes 
> test/integration/component/test_vpc_network_internal_lbrules.py
> CloudStack$
> CloudStack$ pep8 --max-line-length=150 test/integration/plugins/nuagevsp/.py
> CloudStack$
> CloudStack$ pyflakes test/integration/plugins/nuagevsp/.py
> CloudStack$
> Validations:
> 1) Made sure that we didn't break any Public LB (VpcVirtualRouter) 
> functionality.
> Marvin test run:
> nosetests --with-marvin --marvin-config=nuage.cfg 
> test/integration/component/test_vpc_network_lbrules.py
> Test results:
> Test case no 210 and 227: List Load Balancing Rules belonging to a VPC ... 
> === TestName: test_01_VPC_LBRulesListing | Status : SUCCESS ===
> ok
> Test Create LB rules for 1 network which is part of a two/multiple virtual 
> networks of a ... === TestName: test_02_VPC_CreateLBRuleInMultipleNetworks | 
> Status : SUCCESS ===
> ok
> Test case no 222 : Create LB rules for a two/multiple virtual networks of a 
> ... === TestName: test_03_VPC_CreateLBRuleInMultipleNetworksVRStoppedState | 
> Status : SUCCESS ===
> ok
> Test case no 222 : Create LB rules for a two/multiple virtual networks of a 
> ... === TestName: test_04_VPC_CreateLBRuleInMultipleNetworksVRStoppedState | 
> Status : SUCCESS ===
> ok
> Test case no 214 : Delete few(not all) LB rules for a single virtual network 
> of a ... === TestName: test_05_VPC_CreateAndDeleteLBRule | Status : SUCCESS 
> ===
> ok
> Test Delete few(not all) LB rules for a single virtual network of ... === 
> TestName: test_06_VPC_CreateAndDeleteLBRuleVRStopppedState | Status : SUCCESS 
> ===
> ok
> Test Delete all LB rules for a single virtual network of a ... === TestName: 
> test_07_VPC_CreateAndDeleteAllLBRule | Status : SUCCESS ===
> ok
> Test Delete all LB rules for a single virtual network of a ... === TestName: 
> test_08_VPC_CreateAndDeleteAllLBRuleVRStoppedState | Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule for a VM that belongs to 
> a different VPC. ... === TestName: test_09_VPC_LBRuleCreateFailMultipleVPC | 
> Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule for a VM that does not 
> belong to any VPC. ... === TestName: 
> test_10_VPC_FailedToCreateLBRuleNonVPCNetwork | Status : SUCCESS ===
> ok
> Test case no 217 and 236: User should not be allowed to create a LB rule for 
> a ... === TestName: test_11_VPC_LBRuleCreateNotAllowed | Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule on an Ipaddress that 
> Source Nat enabled. ... === TestName: test_12_VPC_LBRuleCreateFailForRouterIP 
> | Status : SUCCESS ===
> ok
> Test User should not be allowed to create a LB rule on an Ipaddress that 
> already has a PF rule. ... === TestName: 
> test_13_VPC_LBRuleCreateFailForPFSourceNATIP | 

[jira] [Commented] (CLOUDSTACK-9403) Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin test coverage

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680750#comment-15680750
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9403:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1579
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin 
> test coverage
> 
>
> Key: CLOUDSTACK-9403
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9403
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Network Controller
>Reporter: Rahul Singal
>Assignee: Nick Livens
>
> This is first phase of support of Shared Network in cloudstack through 
> NuageVsp Network Plugin. A shared network is a type of virtual network that 
> is shared between multiple accounts i.e. a shared network can be accessed by 
> virtual machines that belong to many different accounts. This basic 
> functionality will be supported with the below common use case:
> - shared network can be used for monitoring purposes. A shared network can be 
> assigned to a domain and can be used for monitoring VMs  belonging to all 
> accounts in that domain.
> - Public accessible of shared Network.
> With the current implementation with NuageVsp plugin, It support over-lapping 
> of Ip address, Public Access and also adding Ip ranges in shared Network.
> In VSD, it is implemented in below manner:
> - In order to have tenant isolation for shared networks, we will have to 
> create a Shared L3 Subnet for each shared network, and instantiate it across 
> the relevant enterprises. A shared network will only exist under an 
> enterprise when it is needed, so when the first VM is spinned under that ACS 
> domain inside that shared network.
> - For public shared Network it will also create a floating ip subnet pool in 
> VSD along with all the things mentioned in above point.
> PR contents:
> 1) Support for shared networks with tenant isolation on master with Nuage VSP 
> SDN Plugin.
> 2) Support of shared network with publicly accessible ip ranges.  
> 2) Marvin test coverage for shared networks on master with Nuage VSP SDN 
> Plugin.
> 3) Enhancements on our exiting Marvin test code (nuagevsp plugins directory).
> 4) PEP8 & PyFlakes compliance with our Marvin test code.
> Test Results are:-
> Valiate that ROOT admin is NOT able to deploy a VM for a user in ROOT domain 
> in a shared network with ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_ROOTuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for a admin user in a 
> shared network with ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_differentdomain | 
> Status : SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for admin user in the same 
> domain but in a ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_domainadminuser | 
> Status : SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for user in the same 
> domain but in a different ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_domainuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is able to deploy a VM for regular user in a shared 
> network with scope=account ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_user | Status : SUCCESS 
> ===
> ok
> Valiate that ROOT admin is able to deploy a VM for user in ROOT domain in a 
> shared network with scope=all ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_all_ROOTuser | Status : SUCCESS 
> ===
> ok
> Valiate that ROOT admin is able to deploy a VM for a domain admin users in a 
> shared network with scope=all ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_all_domainadminuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is able to deploy a VM for other users in a shared 
> network with scope=all ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_all_domainuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is able to deploy a VM for admin user in a domain in 
> a shared network with scope=all ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_all_subdomainadminuser | Status 
> : SUCCESS ===
> ok
> Valiate that ROOT admin is able to deploy a VM for any user in a subdomain in 
> a shared network with scope=all ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_all_subdomainuser | Status : 
> SUCCESS ===
> ok
> Valiate that 

[jira] [Commented] (CLOUDSTACK-9402) Nuage VSP Plugin : Support for underlay features (Source & Static NAT to underlay) including Marvin test coverage on master

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680751#comment-15680751
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9402:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1580
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> Nuage VSP Plugin : Support for underlay features (Source & Static NAT to 
> underlay) including Marvin test coverage on master
> ---
>
> Key: CLOUDSTACK-9402
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9402
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Network Controller
>Affects Versions: 4.10.0.0
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
>
> Support for underlay features (Source & Static NAT to underlay) with Nuage 
> VSP SDN Plugin including Marvin test coverage for corresponding Source & 
> Static NAT features on master. Moreover, our Marvin tests are written in such 
> a way that they can validate our supported feature set with both Nuage VSP 
> SDN platform's overlay and underlay infra.
> PR contents:
> 1) Support for Source NAT to underlay feature on master with Nuage VSP SDN 
> Plugin.
> 2) Support for Static NAT to underlay feature on master with Nuage VSP SDN 
> Plugin.
> 3) Marvin test coverage for Source & Static NAT to underlay on master with 
> Nuage VSP SDN Plugin.
> 4) Enhancements on our exiting Marvin test code (nuagevsp plugins directory).
> 5) PEP8 & PyFlakes compliance with our Marvin test code.
> Our Marvin test code PEP8 & PyFlakes compliance:
> CloudStack$
> CloudStack$ pep8 --max-line-length=150 test/integration/plugins/nuagevsp/.py
> CloudStack$
> CloudStack$ pyflakes test/integration/plugins/nuagevsp/.py
> CloudStack$
> Validations:
> 1) Underlay infra (Source & Static NAT to underlay)
> Marvin test run:
> nosetests --with-marvin --marvin-config=nuage.cfg 
> plugins/nuagevsp/test_nuage_source_nat.py
> Test results:
> Test Nuage VSP Isolated networks with different combinations of Source NAT 
> service providers ... === TestName: test_01_nuage_SourceNAT_isolated_networks 
> | Status : SUCCESS ===
> ok
> Test Nuage VSP VPC networks with different combinations of Source NAT service 
> providers ... === TestName: test_02_nuage_SourceNAT_vpc_networks | Status : 
> SUCCESS ===
> ok
> Test Nuage VSP Source NAT functionality for Isolated network by performing 
> (wget) traffic tests to the ... === TestName: 
> test_03_nuage_SourceNAT_isolated_network_traffic | Status : SUCCESS ===
> ok
> Test Nuage VSP Source NAT functionality for VPC network by performing (wget) 
> traffic tests to the Internet ... === TestName: 
> test_04_nuage_SourceNAT_vpc_network_traffic | Status : SUCCESS ===
> ok
> Test Nuage VSP Source NAT functionality with different Egress 
> Firewall/Network ACL rules by performing (wget) ... === TestName: 
> test_05_nuage_SourceNAT_acl_rules_traffic | Status : SUCCESS ===
> ok
> Test Nuage VSP Source NAT functionality with VM NIC operations by performing 
> (wget) traffic tests to the ... === TestName: 
> test_06_nuage_SourceNAT_vm_nic_operations_traffic | Status : SUCCESS ===
> ok
> Test Nuage VSP Source NAT functionality with VM migration by performing 
> (wget) traffic tests to the Internet ... === TestName: 
> test_07_nuage_SourceNAT_vm_migration_traffic | Status : SUCCESS ===
> ok
> Test Nuage VSP Source NAT functionality with network restarts by performing 
> (wget) traffic tests to the ... === TestName: 
> test_08_nuage_SourceNAT_network_restarts_traffic | Status : SUCCESS ===
> ok
> --
> Ran 8 tests in 13360.858s
> OK
> Marvin test run:
> nosetests --with-marvin --marvin-config=nuage.cfg 
> plugins/nuagevsp/test_nuage_static_nat.py
> Test results:
> Test Nuage VSP Public IP Range creation and deletion ... === TestName: 
> test_01_nuage_StaticNAT_public_ip_range | Status : SUCCESS ===
> ok
> Test Nuage VSP Nuage Underlay (underlay networking) enabled Public IP Range 
> creation and deletion ... === TestName: 
> test_02_nuage_StaticNAT_underlay_public_ip_range | Status : SUCCESS ===
> ok
> Test Nuage VSP Isolated networks with different combinations of Static NAT 
> service providers ... === TestName: test_03_nuage_StaticNAT_isolated_networks 
> | Status : SUCCESS ===
> ok
> Test Nuage VSP VPC networks with different combinations of Static NAT service 
> providers ... === TestName: test_04_nuage_StaticNAT_vpc_networks | Status : 
> SUCCESS ===
> ok
> Test Nuage VSP Static NAT functionality for Isolated 

[jira] [Commented] (CLOUDSTACK-9403) Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin test coverage

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680748#comment-15680748
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9403:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1579
  
@blueorangutan package


> Nuage VSP Plugin : Support for SharedNetwork fuctionality including Marvin 
> test coverage
> 
>
> Key: CLOUDSTACK-9403
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9403
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Network Controller
>Reporter: Rahul Singal
>Assignee: Nick Livens
>
> This is first phase of support of Shared Network in cloudstack through 
> NuageVsp Network Plugin. A shared network is a type of virtual network that 
> is shared between multiple accounts i.e. a shared network can be accessed by 
> virtual machines that belong to many different accounts. This basic 
> functionality will be supported with the below common use case:
> - shared network can be used for monitoring purposes. A shared network can be 
> assigned to a domain and can be used for monitoring VMs  belonging to all 
> accounts in that domain.
> - Public accessible of shared Network.
> With the current implementation with NuageVsp plugin, It support over-lapping 
> of Ip address, Public Access and also adding Ip ranges in shared Network.
> In VSD, it is implemented in below manner:
> - In order to have tenant isolation for shared networks, we will have to 
> create a Shared L3 Subnet for each shared network, and instantiate it across 
> the relevant enterprises. A shared network will only exist under an 
> enterprise when it is needed, so when the first VM is spinned under that ACS 
> domain inside that shared network.
> - For public shared Network it will also create a floating ip subnet pool in 
> VSD along with all the things mentioned in above point.
> PR contents:
> 1) Support for shared networks with tenant isolation on master with Nuage VSP 
> SDN Plugin.
> 2) Support of shared network with publicly accessible ip ranges.  
> 2) Marvin test coverage for shared networks on master with Nuage VSP SDN 
> Plugin.
> 3) Enhancements on our exiting Marvin test code (nuagevsp plugins directory).
> 4) PEP8 & PyFlakes compliance with our Marvin test code.
> Test Results are:-
> Valiate that ROOT admin is NOT able to deploy a VM for a user in ROOT domain 
> in a shared network with ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_ROOTuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for a admin user in a 
> shared network with ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_differentdomain | 
> Status : SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for admin user in the same 
> domain but in a ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_domainadminuser | 
> Status : SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for user in the same 
> domain but in a different ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_domainuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is able to deploy a VM for regular user in a shared 
> network with scope=account ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_account_user | Status : SUCCESS 
> ===
> ok
> Valiate that ROOT admin is able to deploy a VM for user in ROOT domain in a 
> shared network with scope=all ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_all_ROOTuser | Status : SUCCESS 
> ===
> ok
> Valiate that ROOT admin is able to deploy a VM for a domain admin users in a 
> shared network with scope=all ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_all_domainadminuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is able to deploy a VM for other users in a shared 
> network with scope=all ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_all_domainuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is able to deploy a VM for admin user in a domain in 
> a shared network with scope=all ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_all_subdomainadminuser | Status 
> : SUCCESS ===
> ok
> Valiate that ROOT admin is able to deploy a VM for any user in a subdomain in 
> a shared network with scope=all ... === TestName: 
> test_deployVM_in_sharedNetwork_as_admin_scope_all_subdomainuser | Status : 
> SUCCESS ===
> ok
> Valiate that ROOT admin is NOT able to deploy a VM for parent domain admin 
> user in a shared 

[jira] [Commented] (CLOUDSTACK-9408) remove runtime references to http://download.cloud.com

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680746#comment-15680746
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9408:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1582
  
Ping, where do we stand on the issue? /cc @abhinandanprateek @jburwell and 
others


> remove runtime references to http://download.cloud.com
> --
>
> Key: CLOUDSTACK-9408
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9408
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.5.2, 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Daan Hoogland
>Assignee: Daan Hoogland
>Priority: Blocker
>
> As cloud.com was bought and sold, We have no assurance and can give none to 
> our users as to wether downloads from that site will remain possible. This is 
> to investigate what occurances of cloud.com can remain and which need to 
> change, and change them.
> [~chiradeep][~widodh] I am assigning this to me but am going to ask for some 
> further assistance.
> [~wstevens]I got no pushback so I am marking this as blocker for now.



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

[jira] [Commented] (CLOUDSTACK-9410) Data Disk shown as "detached" in XS

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680743#comment-15680743
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9410:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1586
  
@blueorangutan package


> Data Disk shown as "detached" in XS
> ---
>
> Key: CLOUDSTACK-9410
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9410
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
>Reporter: subhash yedugundla
>Priority: Minor
>
> ===
> Issue Description
> ===
> 1. Create a data-disk
> 2. Attach data-disk to an instance. Name in XenCenter for the data-disk looks 
> like "i-2-762-VM-DATA"
> 3. Detach data-disk from instance. Name will change to "detached"
> The issue is that the one would like to see the name of the disk once 
> detached, as the same name given to the volume when created and not 
> “detached” and the naming convention for the disk when detached is misleading 
> Even though one should be managing everything through cloudstack, when there 
> are multiple DATA disks that are detached and if all show the same name it 
> will cause confusion.



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

[jira] [Commented] (CLOUDSTACK-9402) Nuage VSP Plugin : Support for underlay features (Source & Static NAT to underlay) including Marvin test coverage on master

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680747#comment-15680747
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9402:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1580
  
@blueorangutan package


> Nuage VSP Plugin : Support for underlay features (Source & Static NAT to 
> underlay) including Marvin test coverage on master
> ---
>
> Key: CLOUDSTACK-9402
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9402
> Project: CloudStack
>  Issue Type: Task
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Automation, Network Controller
>Affects Versions: 4.10.0.0
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
>
> Support for underlay features (Source & Static NAT to underlay) with Nuage 
> VSP SDN Plugin including Marvin test coverage for corresponding Source & 
> Static NAT features on master. Moreover, our Marvin tests are written in such 
> a way that they can validate our supported feature set with both Nuage VSP 
> SDN platform's overlay and underlay infra.
> PR contents:
> 1) Support for Source NAT to underlay feature on master with Nuage VSP SDN 
> Plugin.
> 2) Support for Static NAT to underlay feature on master with Nuage VSP SDN 
> Plugin.
> 3) Marvin test coverage for Source & Static NAT to underlay on master with 
> Nuage VSP SDN Plugin.
> 4) Enhancements on our exiting Marvin test code (nuagevsp plugins directory).
> 5) PEP8 & PyFlakes compliance with our Marvin test code.
> Our Marvin test code PEP8 & PyFlakes compliance:
> CloudStack$
> CloudStack$ pep8 --max-line-length=150 test/integration/plugins/nuagevsp/.py
> CloudStack$
> CloudStack$ pyflakes test/integration/plugins/nuagevsp/.py
> CloudStack$
> Validations:
> 1) Underlay infra (Source & Static NAT to underlay)
> Marvin test run:
> nosetests --with-marvin --marvin-config=nuage.cfg 
> plugins/nuagevsp/test_nuage_source_nat.py
> Test results:
> Test Nuage VSP Isolated networks with different combinations of Source NAT 
> service providers ... === TestName: test_01_nuage_SourceNAT_isolated_networks 
> | Status : SUCCESS ===
> ok
> Test Nuage VSP VPC networks with different combinations of Source NAT service 
> providers ... === TestName: test_02_nuage_SourceNAT_vpc_networks | Status : 
> SUCCESS ===
> ok
> Test Nuage VSP Source NAT functionality for Isolated network by performing 
> (wget) traffic tests to the ... === TestName: 
> test_03_nuage_SourceNAT_isolated_network_traffic | Status : SUCCESS ===
> ok
> Test Nuage VSP Source NAT functionality for VPC network by performing (wget) 
> traffic tests to the Internet ... === TestName: 
> test_04_nuage_SourceNAT_vpc_network_traffic | Status : SUCCESS ===
> ok
> Test Nuage VSP Source NAT functionality with different Egress 
> Firewall/Network ACL rules by performing (wget) ... === TestName: 
> test_05_nuage_SourceNAT_acl_rules_traffic | Status : SUCCESS ===
> ok
> Test Nuage VSP Source NAT functionality with VM NIC operations by performing 
> (wget) traffic tests to the ... === TestName: 
> test_06_nuage_SourceNAT_vm_nic_operations_traffic | Status : SUCCESS ===
> ok
> Test Nuage VSP Source NAT functionality with VM migration by performing 
> (wget) traffic tests to the Internet ... === TestName: 
> test_07_nuage_SourceNAT_vm_migration_traffic | Status : SUCCESS ===
> ok
> Test Nuage VSP Source NAT functionality with network restarts by performing 
> (wget) traffic tests to the ... === TestName: 
> test_08_nuage_SourceNAT_network_restarts_traffic | Status : SUCCESS ===
> ok
> --
> Ran 8 tests in 13360.858s
> OK
> Marvin test run:
> nosetests --with-marvin --marvin-config=nuage.cfg 
> plugins/nuagevsp/test_nuage_static_nat.py
> Test results:
> Test Nuage VSP Public IP Range creation and deletion ... === TestName: 
> test_01_nuage_StaticNAT_public_ip_range | Status : SUCCESS ===
> ok
> Test Nuage VSP Nuage Underlay (underlay networking) enabled Public IP Range 
> creation and deletion ... === TestName: 
> test_02_nuage_StaticNAT_underlay_public_ip_range | Status : SUCCESS ===
> ok
> Test Nuage VSP Isolated networks with different combinations of Static NAT 
> service providers ... === TestName: test_03_nuage_StaticNAT_isolated_networks 
> | Status : SUCCESS ===
> ok
> Test Nuage VSP VPC networks with different combinations of Static NAT service 
> providers ... === TestName: test_04_nuage_StaticNAT_vpc_networks | Status : 
> SUCCESS ===
> ok
> Test Nuage VSP Static NAT functionality for Isolated network by performing 
> (wget) traffic tests to the ... === TestName: 
> 

[jira] [Commented] (CLOUDSTACK-9410) Data Disk shown as "detached" in XS

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680745#comment-15680745
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9410:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1586
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> Data Disk shown as "detached" in XS
> ---
>
> Key: CLOUDSTACK-9410
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9410
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
>Reporter: subhash yedugundla
>Priority: Minor
>
> ===
> Issue Description
> ===
> 1. Create a data-disk
> 2. Attach data-disk to an instance. Name in XenCenter for the data-disk looks 
> like "i-2-762-VM-DATA"
> 3. Detach data-disk from instance. Name will change to "detached"
> The issue is that the one would like to see the name of the disk once 
> detached, as the same name given to the volume when created and not 
> “detached” and the naming convention for the disk when detached is misleading 
> Even though one should be managing everything through cloudstack, when there 
> are multiple DATA disks that are detached and if all show the same name it 
> will cause confusion.



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

[jira] [Commented] (CLOUDSTACK-9468) Alert code documentation out of sync with responses

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680740#comment-15680740
 ] 

ASF subversion and git services commented on CLOUDSTACK-9468:
-

Commit b7e520e36f25e5b2e8dc9f63fa639da7f587817b in cloudstack's branch 
refs/heads/master from [~dcarbone]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b7e520e ]

Updating Alert codes (CLOUDSTACK-9468)

- Updating codes per values present here: 
https://github.com/apache/cloudstack/blob/4.8/api/src/org/apache/cloudstack/alert/AlertService.java#L39


> Alert code documentation out of sync with responses
> ---
>
> Key: CLOUDSTACK-9468
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9468
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.8.0
>Reporter: Daniel Carbone
>Priority: Minor
>  Labels: documentation, easyfix, newbie
> Fix For: 4.8.2.0
>
>
> The current API documentation surrounding Alert Code responses is out of sync 
> with the current implementation.
> Most notably:
> ||Code||Documented As||Implemented As||
> |7|USERVM|HOST|
> |8|DOMAIN_ROUTER|USERVM|
> |9|CONSOLE_PROXY|DOMAIN_ROUTER|
> |10|ROUTING|CONSOLE_PROXY|
> |11|STORAGE_MISC|ROUTING|
> |12|USAGE_SERVER|STORAGE_MISC|
> |13|MANAGEMENT_NODE|USAGE_SERVER|
> |14|DOMAIN_ROUTER_MIGRATE|MANAGEMENT_NODE|
> |15|CONSOLE_PROXY_MIGRATE|DOMAIN_ROUTER_MIGRATE|
> |16|USERVM_MIGRATE|CONSOLE_PROXY_MIGRATE|
> |17|VLAN|USERVM_MIGRATE|
> |18|SSVM|VLAN|
> |19|USAGE_SERVER_FAULT|SSVM|
> |20|-|USAGE_SERVER_FAULT|
> |21|-|STORAGE_DELETE|
> |22|-|UPDATE_RESOURCE_COUNT|
> |23|-|USAGE_SANITY_RESULT|
> |24|-|DIRECT_ATTACHED_PUBLIC_IP|
> |25|-|LOCAL_STORAGE|
> |26|-|RESOURCE_LIMIT_EXCEEDED|
> |27|-|SYNC|
> |28|-|UPLOAD_FAILED|
> |29|-|OOBM_AUTH_ERROR|



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

[jira] [Commented] (CLOUDSTACK-9468) Alert code documentation out of sync with responses

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680741#comment-15680741
 ] 

ASF subversion and git services commented on CLOUDSTACK-9468:
-

Commit 8c62464a310c8ec0a3169cb06451e3ce2654e1b1 in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8c62464 ]

Merge pull request #1591 from myENA/alert-response-doc-update

Updating Alert codesUpdating codes per values present here: 
https://github.com/apache/cloudstack/blob/4.8/api/src/org/apache/cloudstack/alert/AlertService.java#L39

* pr/1591:
  Updating Alert codes (CLOUDSTACK-9468)

Signed-off-by: Rohit Yadav 


> Alert code documentation out of sync with responses
> ---
>
> Key: CLOUDSTACK-9468
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9468
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.8.0
>Reporter: Daniel Carbone
>Priority: Minor
>  Labels: documentation, easyfix, newbie
> Fix For: 4.8.2.0
>
>
> The current API documentation surrounding Alert Code responses is out of sync 
> with the current implementation.
> Most notably:
> ||Code||Documented As||Implemented As||
> |7|USERVM|HOST|
> |8|DOMAIN_ROUTER|USERVM|
> |9|CONSOLE_PROXY|DOMAIN_ROUTER|
> |10|ROUTING|CONSOLE_PROXY|
> |11|STORAGE_MISC|ROUTING|
> |12|USAGE_SERVER|STORAGE_MISC|
> |13|MANAGEMENT_NODE|USAGE_SERVER|
> |14|DOMAIN_ROUTER_MIGRATE|MANAGEMENT_NODE|
> |15|CONSOLE_PROXY_MIGRATE|DOMAIN_ROUTER_MIGRATE|
> |16|USERVM_MIGRATE|CONSOLE_PROXY_MIGRATE|
> |17|VLAN|USERVM_MIGRATE|
> |18|SSVM|VLAN|
> |19|USAGE_SERVER_FAULT|SSVM|
> |20|-|USAGE_SERVER_FAULT|
> |21|-|STORAGE_DELETE|
> |22|-|UPDATE_RESOURCE_COUNT|
> |23|-|USAGE_SANITY_RESULT|
> |24|-|DIRECT_ATTACHED_PUBLIC_IP|
> |25|-|LOCAL_STORAGE|
> |26|-|RESOURCE_LIMIT_EXCEEDED|
> |27|-|SYNC|
> |28|-|UPLOAD_FAILED|
> |29|-|OOBM_AUTH_ERROR|



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

[jira] [Commented] (CLOUDSTACK-9468) Alert code documentation out of sync with responses

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680737#comment-15680737
 ] 

ASF subversion and git services commented on CLOUDSTACK-9468:
-

Commit b7e520e36f25e5b2e8dc9f63fa639da7f587817b in cloudstack's branch 
refs/heads/4.9 from [~dcarbone]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b7e520e ]

Updating Alert codes (CLOUDSTACK-9468)

- Updating codes per values present here: 
https://github.com/apache/cloudstack/blob/4.8/api/src/org/apache/cloudstack/alert/AlertService.java#L39


> Alert code documentation out of sync with responses
> ---
>
> Key: CLOUDSTACK-9468
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9468
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.8.0
>Reporter: Daniel Carbone
>Priority: Minor
>  Labels: documentation, easyfix, newbie
> Fix For: 4.8.2.0
>
>
> The current API documentation surrounding Alert Code responses is out of sync 
> with the current implementation.
> Most notably:
> ||Code||Documented As||Implemented As||
> |7|USERVM|HOST|
> |8|DOMAIN_ROUTER|USERVM|
> |9|CONSOLE_PROXY|DOMAIN_ROUTER|
> |10|ROUTING|CONSOLE_PROXY|
> |11|STORAGE_MISC|ROUTING|
> |12|USAGE_SERVER|STORAGE_MISC|
> |13|MANAGEMENT_NODE|USAGE_SERVER|
> |14|DOMAIN_ROUTER_MIGRATE|MANAGEMENT_NODE|
> |15|CONSOLE_PROXY_MIGRATE|DOMAIN_ROUTER_MIGRATE|
> |16|USERVM_MIGRATE|CONSOLE_PROXY_MIGRATE|
> |17|VLAN|USERVM_MIGRATE|
> |18|SSVM|VLAN|
> |19|USAGE_SERVER_FAULT|SSVM|
> |20|-|USAGE_SERVER_FAULT|
> |21|-|STORAGE_DELETE|
> |22|-|UPDATE_RESOURCE_COUNT|
> |23|-|USAGE_SANITY_RESULT|
> |24|-|DIRECT_ATTACHED_PUBLIC_IP|
> |25|-|LOCAL_STORAGE|
> |26|-|RESOURCE_LIMIT_EXCEEDED|
> |27|-|SYNC|
> |28|-|UPLOAD_FAILED|
> |29|-|OOBM_AUTH_ERROR|



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

[jira] [Commented] (CLOUDSTACK-9468) Alert code documentation out of sync with responses

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680738#comment-15680738
 ] 

ASF subversion and git services commented on CLOUDSTACK-9468:
-

Commit 8c62464a310c8ec0a3169cb06451e3ce2654e1b1 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=8c62464 ]

Merge pull request #1591 from myENA/alert-response-doc-update

Updating Alert codesUpdating codes per values present here: 
https://github.com/apache/cloudstack/blob/4.8/api/src/org/apache/cloudstack/alert/AlertService.java#L39

* pr/1591:
  Updating Alert codes (CLOUDSTACK-9468)

Signed-off-by: Rohit Yadav 


> Alert code documentation out of sync with responses
> ---
>
> Key: CLOUDSTACK-9468
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9468
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.8.0
>Reporter: Daniel Carbone
>Priority: Minor
>  Labels: documentation, easyfix, newbie
> Fix For: 4.8.2.0
>
>
> The current API documentation surrounding Alert Code responses is out of sync 
> with the current implementation.
> Most notably:
> ||Code||Documented As||Implemented As||
> |7|USERVM|HOST|
> |8|DOMAIN_ROUTER|USERVM|
> |9|CONSOLE_PROXY|DOMAIN_ROUTER|
> |10|ROUTING|CONSOLE_PROXY|
> |11|STORAGE_MISC|ROUTING|
> |12|USAGE_SERVER|STORAGE_MISC|
> |13|MANAGEMENT_NODE|USAGE_SERVER|
> |14|DOMAIN_ROUTER_MIGRATE|MANAGEMENT_NODE|
> |15|CONSOLE_PROXY_MIGRATE|DOMAIN_ROUTER_MIGRATE|
> |16|USERVM_MIGRATE|CONSOLE_PROXY_MIGRATE|
> |17|VLAN|USERVM_MIGRATE|
> |18|SSVM|VLAN|
> |19|USAGE_SERVER_FAULT|SSVM|
> |20|-|USAGE_SERVER_FAULT|
> |21|-|STORAGE_DELETE|
> |22|-|UPDATE_RESOURCE_COUNT|
> |23|-|USAGE_SANITY_RESULT|
> |24|-|DIRECT_ATTACHED_PUBLIC_IP|
> |25|-|LOCAL_STORAGE|
> |26|-|RESOURCE_LIMIT_EXCEEDED|
> |27|-|SYNC|
> |28|-|UPLOAD_FAILED|
> |29|-|OOBM_AUTH_ERROR|



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

[jira] [Commented] (CLOUDSTACK-9416) ACS master GUI: Enabling Static NAT on an associated Public IP to one of the NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP being sel

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680733#comment-15680733
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9416:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1592
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI
> ---
>
> Key: CLOUDSTACK-9416
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9416
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Mani Prashanth Varma Manthena
>Assignee: Nick Livens
> Attachments: network1.png, network2.png
>
>
> ACS master GUI: Enabling Static NAT on an associated Public IP to one of the 
> NICs (networks) of a multi-NIC VM fails due to a wrong (default) Guest VM IP 
> being selected in the GUI:
> {noformat}
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'alertManagerImpl'
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.nat.EnableStaticNatCmd': 
> AutowiredFieldElement for public com.cloud.utils.db.UUIDManager 
> org.apache.cloudstack.api.BaseCmd._uuidMgr
> 2016-06-13 04:50:00,456 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'uUIDManagerImpl'
> 2016-06-13 04:50:00,472 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) Returning cached instance of 
> singleton bean 'messageBus'
> 2016-06-13 04:50:00,479 INFO  [c.c.a.ApiServer] (catalina-exec-7:ctx-83926837 
> ctx-fc7aa5ed) VM ip 10.10.2.163 address not belongs to the vm
> 2016-06-13 04:50:00,480 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-7:ctx-83926837 ctx-fc7aa5ed) ===END===  10.31.56.146 -- GET  
> command=enableStaticNat=json=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D=36262bcc-282a-46c2-8a80-472e2a24ab5e=af160cde-6762-4756-b97f-f3829f6d9802=10.10.2.163&_=1465818687943
> 2016-06-13 04:50:02,261 DEBUG [c.c.a.ApiServlet] 
> (catalina-exec-9:ctx-6050366f) ===START===  10.31.56.146 -- GET  
> command=queryAsyncJobResult=7850c125-54a2-4e99-ab78-9f0e3578c304=json=Mfs%2B%2F0LCnpWSNQ1SdTi1Q8MxLBc%3D&_=1465818689752
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.configuration.ConfigurationService 
> org.apache.cloudstack.api.BaseCmd._configService
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Returning cached instance of 
> singleton bean 'configurationManagerImpl'
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.user.AccountService 
> org.apache.cloudstack.api.BaseCmd._accountService
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.s.DefaultListableBeanFactory] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Returning cached instance of 
> singleton bean 'accountManagerImpl'
> 2016-06-13 04:50:02,264 DEBUG [o.s.b.f.a.InjectionMetadata] 
> (catalina-exec-9:ctx-6050366f ctx-00689e3f) Processing injected method of 
> bean 'org.apache.cloudstack.api.command.user.job.QueryAsyncJobResultCmd': 
> AutowiredFieldElement for public com.cloud.vm.UserVmService 
> org.apache.cloudstack.api.BaseCmd._userVmService
> {noformat}



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

[jira] [Commented] (CLOUDSTACK-9417) Usage module refactoring

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15680734#comment-15680734
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9417:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1593
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> Usage module refactoring
> 
>
> Key: CLOUDSTACK-9417
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9417
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Usage
>Affects Versions: 4.9.0
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Fix For: 4.9.1.0
>
>
> h3. Introduction
> Usage sanity check file was not been updated on sanity check.
> It is proposed:
> * New usage folder {{/var/cache/cloudstack/usage}}, creation on 
> cloudstack-usage package built.
> * New sanity check file location in new folder {{/var/cache/cloudstack/usage}}
> * Timestamp included in {{usage.log}} file
> * Include {{updateMaxId()}} on sanity check as it wasn't being updated



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