[jira] [Commented] (CLOUDSTACK-9217) CloudStack should block volume migration to a pool in maintenance mode

2016-03-25 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on CLOUDSTACK-9217:


Github user bvbharatk commented on the pull request:

https://github.com/apache/cloudstack/pull/1322#issuecomment-201706492
  
_Link to logs Folder (search by build_no):_ 
https://www.dropbox.com/sh/yj3wnzbceo9uef2/AAB6u-Iap-xztdm6jHX9SjPja?dl=0

### ACS CI BVT Run
 **Sumarry:**
 Build Number 130
 Hypervisor xenserver
 NetworkType Advanced
 Passed=101
 Failed=4
 Skipped=5


**Failed tests:**
* :setup Failing since 2 runs

 * ContextSuite context=TestResetVmOnReboot>:setup Failing since 2 runs

* integration.smoke.test_volumes.TestCreateVolume

 * test_01_create_volume Failed

 * test_06_download_detached_volume Failing since 2 runs


**Skipped tests:**
test_vm_nic_adapter_vmxnet3
test_deploy_vgpu_enabled_vm
ContextSuite context=TestCreateTemplate>:setup
test_06_copy_template
test_06_copy_iso

**Passed test suits:**
integration.smoke.test_deploy_vm_with_userdata.TestDeployVmWithUserData

integration.smoke.test_affinity_groups_projects.TestDeployVmWithAffinityGroup
integration.smoke.test_portable_publicip.TestPortablePublicIPAcquire
integration.smoke.test_over_provisioning.TestUpdateOverProvision
integration.smoke.test_global_settings.TestUpdateConfigWithScope
integration.smoke.test_guest_vlan_range.TestDedicateGuestVlanRange
integration.smoke.test_scale_vm.TestScaleVm
integration.smoke.test_service_offerings.TestCreateServiceOffering
integration.smoke.test_loadbalance.TestLoadBalance
integration.smoke.test_routers.TestRouterServices
integration.smoke.test_snapshots.TestSnapshotRootDisk

integration.smoke.test_deploy_vms_with_varied_deploymentplanners.TestDeployVmWithVariedPlanners
integration.smoke.test_network.TestDeleteAccount
integration.smoke.test_non_contigiousvlan.TestUpdatePhysicalNetwork
integration.smoke.test_deploy_vm_iso.TestDeployVMFromISO
integration.smoke.test_public_ip_range.TestDedicatePublicIPRange
integration.smoke.test_multipleips_per_nic.TestDeployVM
integration.smoke.test_regions.TestRegions
integration.smoke.test_affinity_groups.TestDeployVmWithAffinityGroup
integration.smoke.test_network_acl.TestNetworkACL
integration.smoke.test_pvlan.TestPVLAN
integration.smoke.test_ssvm.TestSSVMs
integration.smoke.test_nic.TestNic
integration.smoke.test_deploy_vm_root_resize.TestDeployVM
integration.smoke.test_resource_detail.TestResourceDetail
integration.smoke.test_secondary_storage.TestSecStorageServices
integration.smoke.test_vm_life_cycle.TestDeployVM
integration.smoke.test_disk_offerings.TestCreateDiskOffering


> CloudStack should block volume migration to a pool in maintenance mode
> --
>
> Key: CLOUDSTACK-9217
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9217
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller
>Affects Versions: 4.7.0
>Reporter: Pavan Kumar Bandarupally
>Assignee: Pavan Kumar Bandarupally
> Fix For: 4.7.0
>
>
> CloudStack should block migration to a Storage pool which is in maintenance 
> mode.
> I am automating the above functionality.



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

[jira] [Commented] (CLOUDSTACK-9319) Timeout is not passed to virtual router operations consistently

2016-03-25 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on CLOUDSTACK-9319:


Github user insom commented on the pull request:

https://github.com/apache/cloudstack/pull/1451#issuecomment-201620444
  
@alexandrelimassantana Agreed, thanks for the review. I've added a commit 
removing the prototype with the default. That has allowed me to remove that if 
altogether and place it inside the `applyConfigToVR` method.

@DaanHoogland Because the original commit is about the wrong signature for 
the method being used I'm not quite sure how to add tests for it. I hope that 
this second commit will help as it means the compiler can enforce things. 
Thanks for the review!

(Also it's Friday and I don't have a Maven install on this laptop - should 
pass the CI tests, if not, I may need to come back to it on Tuesday).


> Timeout is not passed to virtual router operations consistently
> ---
>
> Key: CLOUDSTACK-9319
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9319
> 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
> Environment: KVM + Ceph cloud, Ubuntu hosts.
>Reporter: Aaron Brady
>Priority: Trivial
>
> The timeout parameter is not passed down to `applyConfigToVR` inside 
> `VirtualRoutingResource` in all cases.
> This timeout is worked out as 3 seconds per command or 120 seconds (whichever 
> is larger), but because it's not passed to the first invocation, the default 
> (120 seconds, DEFAULT_EXECUTEINVR_TIMEOUT) is used.
> In a recent upgrade of our Virtual Routers, the timeout was being hit and 
> increasing `router.aggregation.command.each.timeout` had no effect. I built a 
> custom 4.8 agent with the timeout increased to allow the upgrade to continue.



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

[jira] [Commented] (CLOUDSTACK-9319) Timeout is not passed to virtual router operations consistently

2016-03-25 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on CLOUDSTACK-9319:


Github user alexandrelimassantana commented on the pull request:

https://github.com/apache/cloudstack/pull/1451#issuecomment-201610435
  
@insom with this changes there is still one place where the applyConfigToVR 
is not provided with this timeout parameter (line 183, same class). This 
function is actually called only in those 2 places. If it comes to a state 
where you will always supply the timeout, remove the one which doesn't require 
you to.

Also, if you plan to always supply the timeout, a change into lines 378 and 
379 would provide more coersion:
```Java
if (timeout < 120) {
timeout = 120;
}
```
into:

```Java
if (timeout < VRScripts.DEFAULT_EXECUTEINVR_TIMEOUT) {
timeout = VRScripts.DEFAULT_EXECUTEINVR_TIMEOUT;
}
```


> Timeout is not passed to virtual router operations consistently
> ---
>
> Key: CLOUDSTACK-9319
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9319
> 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
> Environment: KVM + Ceph cloud, Ubuntu hosts.
>Reporter: Aaron Brady
>Priority: Trivial
>
> The timeout parameter is not passed down to `applyConfigToVR` inside 
> `VirtualRoutingResource` in all cases.
> This timeout is worked out as 3 seconds per command or 120 seconds (whichever 
> is larger), but because it's not passed to the first invocation, the default 
> (120 seconds, DEFAULT_EXECUTEINVR_TIMEOUT) is used.
> In a recent upgrade of our Virtual Routers, the timeout was being hit and 
> increasing `router.aggregation.command.each.timeout` had no effect. I built a 
> custom 4.8 agent with the timeout increased to allow the upgrade to continue.



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

[jira] [Commented] (CLOUDSTACK-9218) Test to verify restart network after master VR destroyed

2016-03-25 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on CLOUDSTACK-9218:


Github user bvbharatk commented on the pull request:

https://github.com/apache/cloudstack/pull/1323#issuecomment-201576078
  
_Link to logs Folder (search by build_no):_ 
https://www.dropbox.com/sh/yj3wnzbceo9uef2/AAB6u-Iap-xztdm6jHX9SjPja?dl=0

### ACS CI BVT Run
 **Sumarry:**
 Build Number 129
 Hypervisor xenserver
 NetworkType Advanced
 Passed=104
 Failed=2
 Skipped=4


**Failed tests:**
* integration.smoke.test_guest_vlan_range.TestDedicateGuestVlanRange

 * test_dedicateGuestVlanRange Failing since 4 runs

* integration.smoke.test_volumes.TestCreateVolume

 * test_06_download_detached_volume Failed


**Skipped tests:**
test_vm_nic_adapter_vmxnet3
test_deploy_vgpu_enabled_vm
test_06_copy_template
test_06_copy_iso

**Passed test suits:**
integration.smoke.test_deploy_vm_with_userdata.TestDeployVmWithUserData

integration.smoke.test_affinity_groups_projects.TestDeployVmWithAffinityGroup
integration.smoke.test_portable_publicip.TestPortablePublicIPAcquire
integration.smoke.test_over_provisioning.TestUpdateOverProvision
integration.smoke.test_global_settings.TestUpdateConfigWithScope
integration.smoke.test_scale_vm.TestScaleVm
integration.smoke.test_service_offerings.TestCreateServiceOffering
integration.smoke.test_loadbalance.TestLoadBalance
integration.smoke.test_routers.TestRouterServices
integration.smoke.test_reset_vm_on_reboot.TestResetVmOnReboot
integration.smoke.test_snapshots.TestSnapshotRootDisk

integration.smoke.test_deploy_vms_with_varied_deploymentplanners.TestDeployVmWithVariedPlanners
integration.smoke.test_network.TestDeleteAccount
integration.smoke.test_non_contigiousvlan.TestUpdatePhysicalNetwork
integration.smoke.test_deploy_vm_iso.TestDeployVMFromISO
integration.smoke.test_public_ip_range.TestDedicatePublicIPRange
integration.smoke.test_multipleips_per_nic.TestDeployVM
integration.smoke.test_regions.TestRegions
integration.smoke.test_affinity_groups.TestDeployVmWithAffinityGroup
integration.smoke.test_network_acl.TestNetworkACL
integration.smoke.test_pvlan.TestPVLAN
integration.smoke.test_ssvm.TestSSVMs
integration.smoke.test_nic.TestNic
integration.smoke.test_deploy_vm_root_resize.TestDeployVM
integration.smoke.test_resource_detail.TestResourceDetail
integration.smoke.test_secondary_storage.TestSecStorageServices
integration.smoke.test_vm_life_cycle.TestDeployVM
integration.smoke.test_disk_offerings.TestCreateDiskOffering


> Test to verify restart network after master VR destroyed
> 
>
> Key: CLOUDSTACK-9218
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9218
> Project: CloudStack
>  Issue Type: Test
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Sanjeev N
>Assignee: Sanjeev N
>
> Adding new marvin test to verify restarting network after destroying master 
> router in RVR
> Steps followed:
> 
> 1.Create network offering with RVR enabled
> 2.Create an isolated network and deploy guest vm in it
> 3.Destory(stop and destroy) master VR
> 4.Verify that backup VR switches to master
> 5.Restart network without cleanup



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

[jira] [Commented] (CLOUDSTACK-9285) Cloudstack 4.8 can't connect to XEN and KVM hosts

2016-03-25 Thread ASF subversion and git services (JIRA) 

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

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

Commit 5251eeddf291a34620f770ea4d1f7b1f8af38293 in cloudstack's branch 
refs/heads/4.9-mvn-upgrade from [~wstevens]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5251eed ]

Merge release branch 4.8 to master

* 4.8:
  Cloudstack 9285 for 4.7.x
  CLOUDSTACK-9285 - Address original on start exception(s) and newline cleanup
  Cloudstack 9285 for 4.7.x


> Cloudstack 4.8 can't connect to XEN and KVM hosts
> -
>
> Key: CLOUDSTACK-9285
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9285
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Xen
>Affects Versions: 4.8.0
> Environment: CentOS 7
>Reporter: Jens Fettig
>Priority: Blocker
> Attachments: agentfailure.pcap
>
>
> We used Cloudstack 4.7 in our testing environment. For future uses we updated 
> to Cloudstack 4.8 for some tests. But after the update from 4.7 to 4.8 
> cloudstack has some problems to connect to the hosts again. Here are the 
> error logs.
> {code:title=XEN Server from the managment-server.log:|borderStyle=solid}
> 2016-02-15 11:22:03,476 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) Loading directly 
> connected host 13(xen5)
> 2016-02-15 11:22:06,204 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-1:ctx-aaf933f3) (logid:d157e37d) AutoScaling Monitor is 
> running...
> 2016-02-15 11:22:06,206 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-2:ctx-8e2fc084) (logid:379074cb) VmStatsCollector is 
> running...
> 2016-02-15 11:22:06,217 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-4:ctx-cc1cf960) (logid:b6397e2e) HostStatsCollector is 
> running...
> 2016-02-15 11:22:06,298 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-3:ctx-efda9c07) (logid:5731423e) StorageCollector is 
> running...
> 2016-02-15 11:22:06,302 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-3:ctx-efda9c07) (logid:5731423e) There is no secondary 
> storage VM for secondary storage host cdsdev-secondary
> 2016-02-15 11:22:11,018 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-bc740746) (logid:cc619bad) Begin cleanup expired 
> async-jobs
> 2016-02-15 11:22:11,024 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-bc740746) (logid:cc619bad) End cleanup expired 
> async-jobs
> 2016-02-15 11:22:11,055 DEBUG [c.c.h.x.r.XenServerConnectionPool] 
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) Unable to create 
> master connection to host(192.168.0.97) , due to The credentials given by the 
> user are incorrect, so access has been denied, and you have not been issued a 
> session handle.
> 2016-02-15 11:22:11,055 DEBUG [c.c.h.Status] (ClusteredAgentManager 
> Timer:ctx-43ef0a0a) (logid:82d7b1ec) Transition:[Resource state = Enabled, 
> Agent event = AgentDisconnected, Host id = 13, name = xen5]
> 2016-02-15 11:22:11,101 WARN  [c.c.a.m.ClusteredAgentManagerImpl] 
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec)  can not load 
> directly connected host 13(xen5) due to 
> com.cloud.utils.exception.CloudRuntimeException: Unable to create master 
> connection to host(192.168.0.97) , due to The credentials given by the user 
> are incorrect, so access has been denied, and you have not been issued a 
> session handle.
>   at 
> com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool.getConnect(XenServerConnectionPool.java:163)
>   at 
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.CheckXenHostInfo(CitrixResourceBase.java:523)
>   at 
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.configure(CitrixResourceBase.java:827)
>   at 
> com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:158)
>   at 
> com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:697)
>   at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:217)
>   at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:182)
>   at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:96)
>   at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.runInContext(ClusteredAgentManagerImpl.java:233)
>   at 
> org.apache.cloudstack.managed.context.ManagedContextTimerTask$1.runInContext(ManagedContextTimerTask.java:30)
>   at 
>

[jira] [Commented] (CLOUDSTACK-9285) Cloudstack 4.8 can't connect to XEN and KVM hosts

2016-03-25 Thread ASF subversion and git services (JIRA) 

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

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

Commit 4db1c0125a3b8f5c46a9e3500fe3eec4ca9e95dc in cloudstack's branch 
refs/heads/4.9-mvn-upgrade from [~wstevens]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4db1c01 ]

Merge pull request #1430 from myENA/4.7_cloudstack-9285

CLOUDSTACK-9285 for 4.7.xPer Daan's request, here is a pull request for the 
4.7.x release.

* pr/1430:
  Cloudstack 9285 for 4.7.x
  CLOUDSTACK-9285 - Address original on start exception(s) and newline cleanup
  Cloudstack 9285 for 4.7.x

Signed-off-by: Will Stevens 


> Cloudstack 4.8 can't connect to XEN and KVM hosts
> -
>
> Key: CLOUDSTACK-9285
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9285
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Xen
>Affects Versions: 4.8.0
> Environment: CentOS 7
>Reporter: Jens Fettig
>Priority: Blocker
> Attachments: agentfailure.pcap
>
>
> We used Cloudstack 4.7 in our testing environment. For future uses we updated 
> to Cloudstack 4.8 for some tests. But after the update from 4.7 to 4.8 
> cloudstack has some problems to connect to the hosts again. Here are the 
> error logs.
> {code:title=XEN Server from the managment-server.log:|borderStyle=solid}
> 2016-02-15 11:22:03,476 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) Loading directly 
> connected host 13(xen5)
> 2016-02-15 11:22:06,204 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-1:ctx-aaf933f3) (logid:d157e37d) AutoScaling Monitor is 
> running...
> 2016-02-15 11:22:06,206 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-2:ctx-8e2fc084) (logid:379074cb) VmStatsCollector is 
> running...
> 2016-02-15 11:22:06,217 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-4:ctx-cc1cf960) (logid:b6397e2e) HostStatsCollector is 
> running...
> 2016-02-15 11:22:06,298 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-3:ctx-efda9c07) (logid:5731423e) StorageCollector is 
> running...
> 2016-02-15 11:22:06,302 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-3:ctx-efda9c07) (logid:5731423e) There is no secondary 
> storage VM for secondary storage host cdsdev-secondary
> 2016-02-15 11:22:11,018 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-bc740746) (logid:cc619bad) Begin cleanup expired 
> async-jobs
> 2016-02-15 11:22:11,024 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-bc740746) (logid:cc619bad) End cleanup expired 
> async-jobs
> 2016-02-15 11:22:11,055 DEBUG [c.c.h.x.r.XenServerConnectionPool] 
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) Unable to create 
> master connection to host(192.168.0.97) , due to The credentials given by the 
> user are incorrect, so access has been denied, and you have not been issued a 
> session handle.
> 2016-02-15 11:22:11,055 DEBUG [c.c.h.Status] (ClusteredAgentManager 
> Timer:ctx-43ef0a0a) (logid:82d7b1ec) Transition:[Resource state = Enabled, 
> Agent event = AgentDisconnected, Host id = 13, name = xen5]
> 2016-02-15 11:22:11,101 WARN  [c.c.a.m.ClusteredAgentManagerImpl] 
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec)  can not load 
> directly connected host 13(xen5) due to 
> com.cloud.utils.exception.CloudRuntimeException: Unable to create master 
> connection to host(192.168.0.97) , due to The credentials given by the user 
> are incorrect, so access has been denied, and you have not been issued a 
> session handle.
>   at 
> com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool.getConnect(XenServerConnectionPool.java:163)
>   at 
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.CheckXenHostInfo(CitrixResourceBase.java:523)
>   at 
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.configure(CitrixResourceBase.java:827)
>   at 
> com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:158)
>   at 
> com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:697)
>   at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:217)
>   at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:182)
>   at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:96)
>   at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.runInContext(ClusteredAgentManagerImpl.java:233)

[jira] [Commented] (CLOUDSTACK-9285) Cloudstack 4.8 can't connect to XEN and KVM hosts

2016-03-25 Thread ASF subversion and git services (JIRA) 

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

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

Commit 4db1c0125a3b8f5c46a9e3500fe3eec4ca9e95dc in cloudstack's branch 
refs/heads/4.9-mvn-upgrade from [~wstevens]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4db1c01 ]

Merge pull request #1430 from myENA/4.7_cloudstack-9285

CLOUDSTACK-9285 for 4.7.xPer Daan's request, here is a pull request for the 
4.7.x release.

* pr/1430:
  Cloudstack 9285 for 4.7.x
  CLOUDSTACK-9285 - Address original on start exception(s) and newline cleanup
  Cloudstack 9285 for 4.7.x

Signed-off-by: Will Stevens 


> Cloudstack 4.8 can't connect to XEN and KVM hosts
> -
>
> Key: CLOUDSTACK-9285
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9285
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Xen
>Affects Versions: 4.8.0
> Environment: CentOS 7
>Reporter: Jens Fettig
>Priority: Blocker
> Attachments: agentfailure.pcap
>
>
> We used Cloudstack 4.7 in our testing environment. For future uses we updated 
> to Cloudstack 4.8 for some tests. But after the update from 4.7 to 4.8 
> cloudstack has some problems to connect to the hosts again. Here are the 
> error logs.
> {code:title=XEN Server from the managment-server.log:|borderStyle=solid}
> 2016-02-15 11:22:03,476 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) Loading directly 
> connected host 13(xen5)
> 2016-02-15 11:22:06,204 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-1:ctx-aaf933f3) (logid:d157e37d) AutoScaling Monitor is 
> running...
> 2016-02-15 11:22:06,206 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-2:ctx-8e2fc084) (logid:379074cb) VmStatsCollector is 
> running...
> 2016-02-15 11:22:06,217 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-4:ctx-cc1cf960) (logid:b6397e2e) HostStatsCollector is 
> running...
> 2016-02-15 11:22:06,298 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-3:ctx-efda9c07) (logid:5731423e) StorageCollector is 
> running...
> 2016-02-15 11:22:06,302 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-3:ctx-efda9c07) (logid:5731423e) There is no secondary 
> storage VM for secondary storage host cdsdev-secondary
> 2016-02-15 11:22:11,018 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-bc740746) (logid:cc619bad) Begin cleanup expired 
> async-jobs
> 2016-02-15 11:22:11,024 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-bc740746) (logid:cc619bad) End cleanup expired 
> async-jobs
> 2016-02-15 11:22:11,055 DEBUG [c.c.h.x.r.XenServerConnectionPool] 
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) Unable to create 
> master connection to host(192.168.0.97) , due to The credentials given by the 
> user are incorrect, so access has been denied, and you have not been issued a 
> session handle.
> 2016-02-15 11:22:11,055 DEBUG [c.c.h.Status] (ClusteredAgentManager 
> Timer:ctx-43ef0a0a) (logid:82d7b1ec) Transition:[Resource state = Enabled, 
> Agent event = AgentDisconnected, Host id = 13, name = xen5]
> 2016-02-15 11:22:11,101 WARN  [c.c.a.m.ClusteredAgentManagerImpl] 
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec)  can not load 
> directly connected host 13(xen5) due to 
> com.cloud.utils.exception.CloudRuntimeException: Unable to create master 
> connection to host(192.168.0.97) , due to The credentials given by the user 
> are incorrect, so access has been denied, and you have not been issued a 
> session handle.
>   at 
> com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool.getConnect(XenServerConnectionPool.java:163)
>   at 
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.CheckXenHostInfo(CitrixResourceBase.java:523)
>   at 
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.configure(CitrixResourceBase.java:827)
>   at 
> com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:158)
>   at 
> com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:697)
>   at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:217)
>   at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:182)
>   at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:96)
>   at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.runInContext(ClusteredAgentManagerImpl.java:233)

[jira] [Commented] (CLOUDSTACK-9285) Cloudstack 4.8 can't connect to XEN and KVM hosts

2016-03-25 Thread ASF subversion and git services (JIRA) 

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

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

Commit 64eef2104fea88c12c944a9207213f4b3294d325 in cloudstack's branch 
refs/heads/4.9-mvn-upgrade from [~wstevens]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=64eef21 ]

Merge release branch 4.7 to 4.8

* 4.7:
  Cloudstack 9285 for 4.7.x
  CLOUDSTACK-9285 - Address original on start exception(s) and newline cleanup
  Cloudstack 9285 for 4.7.x


> Cloudstack 4.8 can't connect to XEN and KVM hosts
> -
>
> Key: CLOUDSTACK-9285
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9285
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Xen
>Affects Versions: 4.8.0
> Environment: CentOS 7
>Reporter: Jens Fettig
>Priority: Blocker
> Attachments: agentfailure.pcap
>
>
> We used Cloudstack 4.7 in our testing environment. For future uses we updated 
> to Cloudstack 4.8 for some tests. But after the update from 4.7 to 4.8 
> cloudstack has some problems to connect to the hosts again. Here are the 
> error logs.
> {code:title=XEN Server from the managment-server.log:|borderStyle=solid}
> 2016-02-15 11:22:03,476 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) Loading directly 
> connected host 13(xen5)
> 2016-02-15 11:22:06,204 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-1:ctx-aaf933f3) (logid:d157e37d) AutoScaling Monitor is 
> running...
> 2016-02-15 11:22:06,206 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-2:ctx-8e2fc084) (logid:379074cb) VmStatsCollector is 
> running...
> 2016-02-15 11:22:06,217 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-4:ctx-cc1cf960) (logid:b6397e2e) HostStatsCollector is 
> running...
> 2016-02-15 11:22:06,298 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-3:ctx-efda9c07) (logid:5731423e) StorageCollector is 
> running...
> 2016-02-15 11:22:06,302 DEBUG [c.c.s.StatsCollector] 
> (StatsCollector-3:ctx-efda9c07) (logid:5731423e) There is no secondary 
> storage VM for secondary storage host cdsdev-secondary
> 2016-02-15 11:22:11,018 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-bc740746) (logid:cc619bad) Begin cleanup expired 
> async-jobs
> 2016-02-15 11:22:11,024 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (AsyncJobMgr-Heartbeat-1:ctx-bc740746) (logid:cc619bad) End cleanup expired 
> async-jobs
> 2016-02-15 11:22:11,055 DEBUG [c.c.h.x.r.XenServerConnectionPool] 
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec) Unable to create 
> master connection to host(192.168.0.97) , due to The credentials given by the 
> user are incorrect, so access has been denied, and you have not been issued a 
> session handle.
> 2016-02-15 11:22:11,055 DEBUG [c.c.h.Status] (ClusteredAgentManager 
> Timer:ctx-43ef0a0a) (logid:82d7b1ec) Transition:[Resource state = Enabled, 
> Agent event = AgentDisconnected, Host id = 13, name = xen5]
> 2016-02-15 11:22:11,101 WARN  [c.c.a.m.ClusteredAgentManagerImpl] 
> (ClusteredAgentManager Timer:ctx-43ef0a0a) (logid:82d7b1ec)  can not load 
> directly connected host 13(xen5) due to 
> com.cloud.utils.exception.CloudRuntimeException: Unable to create master 
> connection to host(192.168.0.97) , due to The credentials given by the user 
> are incorrect, so access has been denied, and you have not been issued a 
> session handle.
>   at 
> com.cloud.hypervisor.xenserver.resource.XenServerConnectionPool.getConnect(XenServerConnectionPool.java:163)
>   at 
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.CheckXenHostInfo(CitrixResourceBase.java:523)
>   at 
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.configure(CitrixResourceBase.java:827)
>   at 
> com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:158)
>   at 
> com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:697)
>   at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:217)
>   at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:182)
>   at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:96)
>   at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.runInContext(ClusteredAgentManagerImpl.java:233)
>   at 
> org.apache.cloudstack.managed.context.ManagedContextTimerTask$1.runInContext(ManagedContextTimerTask.java:30)
>   at 
>

[jira] [Created] (CLOUDSTACK-9327) CentOS7 as management server, cloudstack-setup-management needs --tomcat7 option

2016-03-25 Thread Dannie Rothmann (JIRA) 
Dannie Rothmann created CLOUDSTACK-9327:
---

 Summary: CentOS7 as management server, cloudstack-setup-management 
needs --tomcat7 option
 Key: CLOUDSTACK-9327
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9327
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Doc
 Environment: CentOS7 as management server, cloudstack-setup-management 
needs --tomcat7 option
Reporter: Dannie Rothmann
Priority: Minor


When installing Management server on CentOS7, the command for setting up 
management fails.

For CentOS7 the command for running the cloudstack-setup-management fails, 
unless the command line option --tomcat7 is added, then it works fine.



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

[jira] [Created] (CLOUDSTACK-9326) CentOS7 as management server, install instruction needs adjusting regarding iptables

2016-03-25 Thread Dannie Rothmann (JIRA) 
Dannie Rothmann created CLOUDSTACK-9326:
---

 Summary: CentOS7 as management server, install instruction needs 
adjusting regarding iptables
 Key: CLOUDSTACK-9326
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9326
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Doc
 Environment: CentOS7 as management server, install instruction needs 
adjusting regarding iptables
Reporter: Dannie Rothmann
Priority: Minor


On 
http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/4.8/management-server/index.html

The section about iptables either needs another section about CentOS7 and the 
new firewalld that has replaced iptables or a description about how to go back 
to using iptables on CentOS7+ - this is quite simple:

Reverting back to iptables on CentOS7, run the following commands:
# systemctl mask firewalld
# systemctl stop firewalld
# yum -y install iptables-services
# systemctl enable iptables
# systemctl start iptables




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

[jira] [Created] (CLOUDSTACK-9325) Install doc. Management server on CentOS 7, MySQL replaced by MariaDB

2016-03-25 Thread Dannie Rothmann (JIRA) 
Dannie Rothmann created CLOUDSTACK-9325:
---

 Summary: Install doc. Management server on CentOS 7, MySQL 
replaced by MariaDB
 Key: CLOUDSTACK-9325
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9325
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Doc
 Environment: CentOS7 as management server, install instruction needs 
adjusting regarding SQL install
Reporter: Dannie Rothmann
Priority: Minor


On this page 
http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/4.8/management-server/index.html

some things needs to be changed for installations on a CentOS7 to work as 
expected:

- MySQL is no longer in the repo, is has been replaced by MariaDB - but 
everything works the same way - just needs the name changed.




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

[jira] [Created] (CLOUDSTACK-9324) Wrong reference regarding Dom0 memory in XenServer

2016-03-25 Thread Dannie Rothmann (JIRA) 
Dannie Rothmann created CLOUDSTACK-9324:
---

 Summary: Wrong reference regarding Dom0 memory in XenServer
 Key: CLOUDSTACK-9324
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9324
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Doc
 Environment: Installation doc for XenServer references wrong Citrix 
article about adding more RAM to dom0
Reporter: Dannie Rothmann
Priority: Minor


http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/4.8/hypervisor/xenserver.html#

Refers to Citrix article http://support.citrix.com/article/CTX126531 - but this 
has changed for XenServer 6.1 and forward.

Please refer to http://support.citrix.com/article/CTX134951 or just add the 
simple explanation.

To set the memory size for dom0 to 20940MB, run the following command from the 
XenServer console commandline:
/opt/xensource/libexec/xen-cmdline --set-xen dom0_mem=2940M,max:2940M 




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

[jira] [Commented] (CLOUDSTACK-9319) Timeout is not passed to virtual router operations consistently

2016-03-25 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on CLOUDSTACK-9319:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/1451#issuecomment-201246728
  
@insom any chance you can supply some test-mech?


> Timeout is not passed to virtual router operations consistently
> ---
>
> Key: CLOUDSTACK-9319
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9319
> 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
> Environment: KVM + Ceph cloud, Ubuntu hosts.
>Reporter: Aaron Brady
>Priority: Trivial
>
> The timeout parameter is not passed down to `applyConfigToVR` inside 
> `VirtualRoutingResource` in all cases.
> This timeout is worked out as 3 seconds per command or 120 seconds (whichever 
> is larger), but because it's not passed to the first invocation, the default 
> (120 seconds, DEFAULT_EXECUTEINVR_TIMEOUT) is used.
> In a recent upgrade of our Virtual Routers, the timeout was being hit and 
> increasing `router.aggregation.command.each.timeout` had no effect. I built a 
> custom 4.8 agent with the timeout increased to allow the upgrade to continue.



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

2016-03-25 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on CLOUDSTACK-9317:


Github user jayapalu commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1450#discussion_r57422486
  
--- Diff: server/src/com/cloud/network/router/CommandSetupHelper.java ---
@@ -778,10 +778,11 @@ public int compare(final PublicIpAddress o1, final 
PublicIpAddress o2) {
 
 final boolean add = ipAddr.getState() == 
IpAddress.State.Releasing ? false : true;
 boolean sourceNat = ipAddr.isSourceNat();
-/* enable sourceNAT for the first ip of the public 
interface */
-if (firstIP) {
-sourceNat = true;
+/* enable sourceNAT for the first ip of the public 
interface as long as it's source nat. */
+if (firstIP && !sourceNat) {
--- End diff --

For additional public subnet case, sourceNat should be set to 'true' to add 
a source nat rule on VR for the first ip in that subnet. This changes will 
break that.

If there is no source nat rule for the additional public subnet the traffic 
to this subnet from he VMs always go through the default source nat interface.


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