date:20150826


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14715381#comment-14715381
 ] 

Michael Andersen commented on CLOUDSTACK-8759:
--

no network devices in vm confirmed:

root@r-34-VM:~# ip -s link
1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
RX: bytes  packets  errors  dropped overrun mcast
93 10   0   0   0
TX: bytes  packets  errors  dropped carrier collsns
93 10   0   0   0

 Destroying VPC router results in a new unusable VPC router
 --

 Key: CLOUDSTACK-8759
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8759
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.6.0
 Environment: ACS master/4.6 with XenServer and KVM tested
Reporter: Remi Bergsma
Priority: Critical
 Fix For: 4.6.0


 Deploy VPC
 Deploy VM
 This all works fine
 Shutdown, then destroy VPC
 Expected result:
 A new VPC router is deployed that has the same functionality than before, but 
 with a new router instance ID.
 Experienced result:
 VPC router is unaccessible for CloudStack due to missing link-local interface:
 root@r-7-VM:~# ifconfig -a
 loLink encap:Local Loopback  
   inet addr:127.0.0.1  Mask:255.0.0.0
   UP LOOPBACK RUNNING  MTU:16436  Metric:1
   RX packets:1 errors:0 dropped:0 overruns:0 frame:0
   TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:0 
   RX bytes:93 (93.0 B)  TX bytes:93 (93.0 B)
 From a first look, the command line info seems OK.
 root@r-7-VM:/etc/cloudstack# cat cmdline.json 
 {
 config: {
 baremetalnotificationapikey: 
 pPgegDQwez17eCbRj4Wx8IwFs543rcPpF7Gavvtys_D7w1jnAoyJ4A-21H9Bf58s1ZjC4DTVrD0BHxNA3y7agA,
  
 baremetalnotificationsecuritykey: 
 Sxv0QbIgRTH-PkeDWBsY-GYsKz2WIz9JIyWTK16mNnIPPZ-Ozo940_8d8bSEx5pHZ4rEdxG5HQMRRcchANHuHg,
  
 disable_rp_filter: true, 
 dns1: 8.8.8.8, 
 domain: cs2cloud, 
 eth1ip: 169.254.0.249, 
 eth1mask: 255.255.0.0, 
 host: 192.168.22.61, 
 name: r-7-VM, 
 port: 8080, 
 redundant_router: false, 
 template: domP, 
 type: vpcrouter, 
 vpccidr: 10.0.1.0/24
 }, 
 id: cmdline
 [~wilder.rodrigues] Let's have a look when you're back!



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

[jira] [Commented] (CLOUDSTACK-8592) Enhance usage server to provide quota service


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14714401#comment-14714401
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8592:


Github user ke4qqq commented on the pull request:


https://github.com/apache/cloudstack-docs-admin/pull/30#issuecomment-135079970
  
LGTM +1


 Enhance usage server to provide quota service
 -

 Key: CLOUDSTACK-8592
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8592
 Project: CloudStack
  Issue Type: Task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Usage
Affects Versions: 4.6.0
Reporter: Abhinandan Prateek
Assignee: Abhinandan Prateek
Priority: Critical
 Fix For: 4.6.0


 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Quota+Service+-+FS
 Quota service while allowing for scalability will make sure that the cloud is 
 not exploited by attacks, careless use and program errors. To address this 
 problem, we propose to employ a quota-enforcement service that allows 
 resource usage within certain bounds as defined by policies and available 
 quotas for various entities. 
 Quota service extends the functionality of usage server to provide a 
 measurement for the resources used by the accounts and domains using a common 
 unit referred to as cloud currency in this document. It can be configured to 
 ensure that your usage won’t exceed the budget allocated to accounts/domain 
 in cloud currency.
 It will let user know how much of the cloud resources he is using. It will 
 help the cloud admins, if they want, to ensure that a user does not go beyond 
 his allocated quota. Per usage cycle if a account is found to be exceeding 
 its quota then it is locked. Locking an account means that it will not be 
 able to initiat
 e a new resource allocation request, whether it is more storage or an 
 additional ip. Needless to say quota service as well as any action on the 
 account is configurable.



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

[jira] [Commented] (CLOUDSTACK-8759) Destroying VPC router results in a new unusable VPC router


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14715373#comment-14715373
 ] 

Michael Andersen commented on CLOUDSTACK-8759:
--

Was able to reproduce:

- new vpc router is stuck state Starting in cloudstack
- kvm guest is running and accessible via console but has not networking:
[root@kvm1 ~]# virsh console r-34-VM
setlocale: No such file or directory
Connected to domain r-34-VM
Escape character is ^]

Debian GNU/Linux 7 r-34-VM ttyS0

r-34-VM login: root
Password:
Last login: Mon Aug 24 23:25:23 UTC 2015 from 10.0.2.2 on pts/0
Linux r-34-VM 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u3 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@r-34-VM:~# ip route
root@r-34-VM:~# ip addr
1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
root@r-34-VM:~# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 
root=UUID=06c97629-5235-4e64-91dc-5c42cffe429e ro debian-installer=en_US quiet


 Destroying VPC router results in a new unusable VPC router
 --

 Key: CLOUDSTACK-8759
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8759
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.6.0
 Environment: ACS master/4.6 with XenServer and KVM tested
Reporter: Remi Bergsma
Priority: Critical
 Fix For: 4.6.0


 Deploy VPC
 Deploy VM
 This all works fine
 Shutdown, then destroy VPC
 Expected result:
 A new VPC router is deployed that has the same functionality than before, but 
 with a new router instance ID.
 Experienced result:
 VPC router is unaccessible for CloudStack due to missing link-local interface:
 root@r-7-VM:~# ifconfig -a
 loLink encap:Local Loopback  
   inet addr:127.0.0.1  Mask:255.0.0.0
   UP LOOPBACK RUNNING  MTU:16436  Metric:1
   RX packets:1 errors:0 dropped:0 overruns:0 frame:0
   TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:0 
   RX bytes:93 (93.0 B)  TX bytes:93 (93.0 B)
 From a first look, the command line info seems OK.
 root@r-7-VM:/etc/cloudstack# cat cmdline.json 
 {
 config: {
 baremetalnotificationapikey: 
 pPgegDQwez17eCbRj4Wx8IwFs543rcPpF7Gavvtys_D7w1jnAoyJ4A-21H9Bf58s1ZjC4DTVrD0BHxNA3y7agA,
  
 baremetalnotificationsecuritykey: 
 Sxv0QbIgRTH-PkeDWBsY-GYsKz2WIz9JIyWTK16mNnIPPZ-Ozo940_8d8bSEx5pHZ4rEdxG5HQMRRcchANHuHg,
  
 disable_rp_filter: true, 
 dns1: 8.8.8.8, 
 domain: cs2cloud, 
 eth1ip: 169.254.0.249, 
 eth1mask: 255.255.0.0, 
 host: 192.168.22.61, 
 name: r-7-VM, 
 port: 8080, 
 redundant_router: false, 
 template: domP, 
 type: vpcrouter, 
 vpccidr: 10.0.1.0/24
 }, 
 id: cmdline
 [~wilder.rodrigues] Let's have a look when you're back!



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

[jira] [Resolved] (CLOUDSTACK-8761) Management server heartbeat takes too long to finish

2015-08-26 Thread Wei Zhou (JIRA)


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

Wei Zhou resolved CLOUDSTACK-8761.
--
Resolution: Fixed

 Management server heartbeat takes too long to finish
 

 Key: CLOUDSTACK-8761
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8761
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Wei Zhou
Assignee: Wei Zhou

 We got a lot of debug message in management-server.log every 1.5 seconds.
 The cluster.heartbeat.interval is set to 1500 by default. As it was not 
 changed after its first commit, so I think it is 1500 ms.
 However, The durations are less than 10ms actually.
 2015-08-18 00:00:04,526 DEBUG [c.c.c.ClusterManagerImpl] 
 (Cluster-Heartbeat-1:ctx-047bb88f) Management server heartbeat takes too long 
 to finish. profiler: Done. Duration: 4ms, profilerHeartbeatUpdate: Done. 
 Duration: 3ms, profilerPeerScan: Done. Duration: 0ms
 2015-08-18 00:00:06,036 DEBUG [c.c.c.ClusterManagerImpl] 
 (Cluster-Heartbeat-1:ctx-68018e26) Peer scan takes too long to finish. 
 profiler: Done. Duration: 0ms, profilerQueryActiveList: Done. Duration: 0ms, 
 profilerSyncClusterInfo: Done. Duration: 0ms, profilerInvalidatedNodeList: 
 Done. Duration: 0ms, profilerRemovedList: Done. Duration: 0ms



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

[jira] [Commented] (CLOUDSTACK-8766) In zone based template listings, infinite scrolling pagination is broken


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712625#comment-14712625
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8766:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/739#issuecomment-134872958
  
I've add a similar fix for listing iso/zone page and also added code that 
would de-dupe any isos and templates in the main list view.


 In zone based template listings, infinite scrolling pagination is broken
 

 Key: CLOUDSTACK-8766
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8766
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.5.0, 4.5.1, 4.5.2
Reporter: Rohit Yadav
Assignee: Rohit Yadav
Priority: Minor
 Fix For: 4.5.3, 4.6.0


 On the template page, when a template is select, goto Zones tab and scroll to 
 list all the templates. In case the number of zones are more than 20 there is 
 an infinite scrolling/listing issue as it does not paginate the result. The 
 fix would be to use listViewDataProvider to get pagination when requesting 
 the API.



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

[jira] [Commented] (CLOUDSTACK-8761) Management server heartbeat takes too long to finish

2015-08-26 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712626#comment-14712626
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8761:


Github user karuturi commented on the pull request:

https://github.com/apache/cloudstack/pull/730#issuecomment-134872980
  
Hi @ustcweizhou Can you use the merge-pr script next time? 

scripts is at 
https://github.com/apache/cloudstack/blob/master/tools/git/git-pr 
wiki explaining the usage 
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61311655


 Management server heartbeat takes too long to finish
 

 Key: CLOUDSTACK-8761
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8761
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Wei Zhou
Assignee: Wei Zhou

 We got a lot of debug message in management-server.log every 1.5 seconds.
 The cluster.heartbeat.interval is set to 1500 by default. As it was not 
 changed after its first commit, so I think it is 1500 ms.
 However, The durations are less than 10ms actually.
 2015-08-18 00:00:04,526 DEBUG [c.c.c.ClusterManagerImpl] 
 (Cluster-Heartbeat-1:ctx-047bb88f) Management server heartbeat takes too long 
 to finish. profiler: Done. Duration: 4ms, profilerHeartbeatUpdate: Done. 
 Duration: 3ms, profilerPeerScan: Done. Duration: 0ms
 2015-08-18 00:00:06,036 DEBUG [c.c.c.ClusterManagerImpl] 
 (Cluster-Heartbeat-1:ctx-68018e26) Peer scan takes too long to finish. 
 profiler: Done. Duration: 0ms, profilerQueryActiveList: Done. Duration: 0ms, 
 profilerSyncClusterInfo: Done. Duration: 0ms, profilerInvalidatedNodeList: 
 Done. Duration: 0ms, profilerRemovedList: Done. Duration: 0ms



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

[jira] [Commented] (CLOUDSTACK-8766) In zone based template listings, infinite scrolling pagination is broken


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712624#comment-14712624
 ] 

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

Commit 26700fbe766e06c3b953ee9ebae3f51ff1a08968 in cloudstack's branch 
refs/heads/CLOUDSTACK-8766 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=26700fb ]

CLOUDSTACK-8766: Fix infinite scrolling pagination for zonal template listing

Uses listViewDataProvider to implement pagination for listing templates and ISOs
in the zones tab. Dedupes isos and templates in the list views.

This closes #739

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com


 In zone based template listings, infinite scrolling pagination is broken
 

 Key: CLOUDSTACK-8766
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8766
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.5.0, 4.5.1, 4.5.2
Reporter: Rohit Yadav
Assignee: Rohit Yadav
Priority: Minor
 Fix For: 4.5.3, 4.6.0


 On the template page, when a template is select, goto Zones tab and scroll to 
 list all the templates. In case the number of zones are more than 20 there is 
 an infinite scrolling/listing issue as it does not paginate the result. The 
 fix would be to use listViewDataProvider to get pagination when requesting 
 the API.



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

[jira] [Commented] (CLOUDSTACK-8725) RVR functionality is broken in case of isolated networks, conntrackd fails to start.


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712605#comment-14712605
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8725:


Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/692#issuecomment-134863538
  
@remibergsma no, answer is clear and though my question expresses a 
reservation on design level it should not stop this PR; = LGTM


 RVR functionality is broken in case of isolated networks, conntrackd fails to 
 start.
 

 Key: CLOUDSTACK-8725
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8725
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Virtual Router
Affects Versions: 4.6.0
Reporter: Bharat Kumar
Assignee: Bharat Kumar
Priority: Critical
 Fix For: 4.6.0


 I tried setting up a rvr enabled isolated network. In the startup logs of the 
 router i can see that conntrackd is failing to start.  Below are the startup 
 logs
 [info] Setting console screen modes.
 setterm: cannot (un)set powersave mode: Invalid argument
 [info] Skipping font and keymap setup (handled by console-setup).
 [] Loading IPsec SA/SP database: 
 [ ok etc/ipsec-tools.conf.
 INIT: Entering runlevel: 2
 [info] Using makefile-style concurrent boot in runlevel 2.
 [info] ipvsadm is not configured to run. Please edit /etc/default/ipvsadm.
 [ ok ] Loading iptables rules... IPv4... IPv6...done.
 [ ok ] Starting rpcbind daemon...[] Already running..
 sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory
 open-vm-tools: not starting as this is not a VMware VM
 [ ok ] Starting enhanced syslogd: rsyslogd.
 [] Starting ACPI services...RTNETLINK1 answers: No such file or directory
 acpid: error talking to the kernel via netlink
 . ok 
 [] Starting conntrackdERROR: parsing config file in line (102), symbol 
 'Multicast': syntax error
  failed!
 [ ok ] Starting DNS forwarder and DHCP server: dnsmasq.
 [] Starting web server: apache2apache2: Could not reliably determine the 
 server's fully qualified domain name, using 10.1.1.247 for ServerName
 . ok 
 [ ok ] Starting periodic command scheduler: cron.
 [] Starting haproxy: haproxy[WARNING] 223/051439 (3480) : config : 
 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode.
 [WARNING] 223/051439 (3480) : config : 'option forwardfor' ignored for proxy 
 'cloud-default' as it requires HTTP mode.
 [WARNING] 223/051439 (3484) : config : 'stats' statement ignored for proxy 
 'cloud-default' as it requires HTTP mode.
 [WARNING] 223/051439 (3484) : config : 'option forwardfor' ignored for proxy 
 'cloud-default' as it requires HTTP mode.
 . ok 
 [FAIL] Starting keepalived: keepalived failed!
 [ ok ] Starting NTP server: ntpd.
 [ ok ] Starting OpenBSD Secure Shell server: sshd.
 [ ok ] Starting the system activity data collector: sadc.
 Detecting Linux distribution version: OK
 Starting xe daemon:  OK
 [ ok ] Starting OpenBSD Secure Shell server: sshd.
 [] Starting haproxy: haproxy[WARNING] 223/051440 (3709) : config : 
 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode.
 [WARNING] 223/051440 (3709) : config : 'option forwardfor' ignored for proxy 
 'cloud-default' as it requires HTTP mode.
 . ok 
 [] Starting web server: apache2apache2: Could not reliably determine the 
 server's fully qualified domain name, using 10.1.1.247 for ServerName
 httpd (pid 3351) already running
 . ok 
 [FAIL] Starting keepalived: keepalived failed!
 [] Starting conntrackdERROR: parsing config file in line (102), symbol 
 'Multicast': syntax error
  failed!
 sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory
 Failed
 [ ok ] Stopping NFS common utilities: idmapd statd.
 -On router.
 root@r-93-VM:~# service conntrackd restart
 [] Stopping conntrackdERROR: parsing config file in line (102), symbol 
 'Multicast': syntax error
  failed!
 [] Starting conntrackdERROR: parsing config file in line (102), symbol 
 'Multicast': syntax error
  failed!



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

[jira] [Commented] (CLOUDSTACK-8761) Management server heartbeat takes too long to finish

2015-08-26 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712591#comment-14712591
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8761:


Github user asfgit closed the pull request at:

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


 Management server heartbeat takes too long to finish
 

 Key: CLOUDSTACK-8761
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8761
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Wei Zhou
Assignee: Wei Zhou

 We got a lot of debug message in management-server.log every 1.5 seconds.
 The cluster.heartbeat.interval is set to 1500 by default. As it was not 
 changed after its first commit, so I think it is 1500 ms.
 However, The durations are less than 10ms actually.
 2015-08-18 00:00:04,526 DEBUG [c.c.c.ClusterManagerImpl] 
 (Cluster-Heartbeat-1:ctx-047bb88f) Management server heartbeat takes too long 
 to finish. profiler: Done. Duration: 4ms, profilerHeartbeatUpdate: Done. 
 Duration: 3ms, profilerPeerScan: Done. Duration: 0ms
 2015-08-18 00:00:06,036 DEBUG [c.c.c.ClusterManagerImpl] 
 (Cluster-Heartbeat-1:ctx-68018e26) Peer scan takes too long to finish. 
 profiler: Done. Duration: 0ms, profilerQueryActiveList: Done. Duration: 0ms, 
 profilerSyncClusterInfo: Done. Duration: 0ms, profilerInvalidatedNodeList: 
 Done. Duration: 0ms, profilerRemovedList: Done. Duration: 0ms



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

[jira] [Commented] (CLOUDSTACK-8761) Management server heartbeat takes too long to finish


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712590#comment-14712590
 ] 

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

Commit 858b6c02512303c35f59d117bba15c432b1c2109 in cloudstack's branch 
refs/heads/master from Wei Zhou
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=858b6c0 ]

Merge pull request #730 from ustcweizhou/profiler-getDurationInMillis

CLOUDSTACK-8761: Replace some profiler.getDuration with 
profiler.getDurationInMillis after commit 5557ad55

This closes #730


 Management server heartbeat takes too long to finish
 

 Key: CLOUDSTACK-8761
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8761
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Wei Zhou
Assignee: Wei Zhou

 We got a lot of debug message in management-server.log every 1.5 seconds.
 The cluster.heartbeat.interval is set to 1500 by default. As it was not 
 changed after its first commit, so I think it is 1500 ms.
 However, The durations are less than 10ms actually.
 2015-08-18 00:00:04,526 DEBUG [c.c.c.ClusterManagerImpl] 
 (Cluster-Heartbeat-1:ctx-047bb88f) Management server heartbeat takes too long 
 to finish. profiler: Done. Duration: 4ms, profilerHeartbeatUpdate: Done. 
 Duration: 3ms, profilerPeerScan: Done. Duration: 0ms
 2015-08-18 00:00:06,036 DEBUG [c.c.c.ClusterManagerImpl] 
 (Cluster-Heartbeat-1:ctx-68018e26) Peer scan takes too long to finish. 
 profiler: Done. Duration: 0ms, profilerQueryActiveList: Done. Duration: 0ms, 
 profilerSyncClusterInfo: Done. Duration: 0ms, profilerInvalidatedNodeList: 
 Done. Duration: 0ms, profilerRemovedList: Done. Duration: 0ms



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

[jira] [Commented] (CLOUDSTACK-8592) Enhance usage server to provide quota service


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14714434#comment-14714434
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8592:


Github user runseb commented on the pull request:


https://github.com/apache/cloudstack-docs-admin/pull/30#issuecomment-135085249
  
LGTM +1


 Enhance usage server to provide quota service
 -

 Key: CLOUDSTACK-8592
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8592
 Project: CloudStack
  Issue Type: Task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Usage
Affects Versions: 4.6.0
Reporter: Abhinandan Prateek
Assignee: Abhinandan Prateek
Priority: Critical
 Fix For: 4.6.0


 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Quota+Service+-+FS
 Quota service while allowing for scalability will make sure that the cloud is 
 not exploited by attacks, careless use and program errors. To address this 
 problem, we propose to employ a quota-enforcement service that allows 
 resource usage within certain bounds as defined by policies and available 
 quotas for various entities. 
 Quota service extends the functionality of usage server to provide a 
 measurement for the resources used by the accounts and domains using a common 
 unit referred to as cloud currency in this document. It can be configured to 
 ensure that your usage won’t exceed the budget allocated to accounts/domain 
 in cloud currency.
 It will let user know how much of the cloud resources he is using. It will 
 help the cloud admins, if they want, to ensure that a user does not go beyond 
 his allocated quota. Per usage cycle if a account is found to be exceeding 
 its quota then it is locked. Locking an account means that it will not be 
 able to initiat
 e a new resource allocation request, whether it is more storage or an 
 additional ip. Needless to say quota service as well as any action on the 
 account is configurable.



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

[jira] [Commented] (CLOUDSTACK-8759) Destroying VPC router results in a new unusable VPC router


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14715497#comment-14715497
 ] 

Michael Andersen commented on CLOUDSTACK-8759:
--

culprit seems to be (from agent log): 

2015-08-26 20:53:59,629{GMT} WARN  [kvm.resource.LibvirtComputingResource] 
(agentRequest-Handler-2:) Timed out: 
/usr/share/cloudstack-common/scripts/vm/hypervisor/kvm/patchviasocket.pl -n 
r-34-VM -p 
%vpccidr=10.2.2.0/24%domain=cs2cloud%dns1=8.8.8.8%template=domP%name=r-34-VM%eth1ip=169.254.3.168%eth1mask=255.255.0.0%type=vpcrouter%disable_rp_filter=true%baremetalnotificationsecuritykey=OUCMhtyF8fM8F_tuVAWGMcPRK9cllK-I1rHXs86sfqmzQAyDOAI8VHe_-1sXAHCkit6FXm3FxyoeDJ5QY5xi_w%baremetalnotificationapikey=Ule7k93ZqrMqawGltaaNul7Nslq20nrPlbd3uhbu9_WJTZpvAzqPB6ysrt_8oLk22U727crw2UB69GmcEJsu1A%host=192.168.22.61%port=8080
 .  Output is:



 Destroying VPC router results in a new unusable VPC router
 --

 Key: CLOUDSTACK-8759
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8759
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.6.0
 Environment: ACS master/4.6 with XenServer and KVM tested
Reporter: Remi Bergsma
Priority: Critical
 Fix For: 4.6.0


 Deploy VPC
 Deploy VM
 This all works fine
 Shutdown, then destroy VPC
 Expected result:
 A new VPC router is deployed that has the same functionality than before, but 
 with a new router instance ID.
 Experienced result:
 VPC router is unaccessible for CloudStack due to missing link-local interface:
 root@r-7-VM:~# ifconfig -a
 loLink encap:Local Loopback  
   inet addr:127.0.0.1  Mask:255.0.0.0
   UP LOOPBACK RUNNING  MTU:16436  Metric:1
   RX packets:1 errors:0 dropped:0 overruns:0 frame:0
   TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:0 
   RX bytes:93 (93.0 B)  TX bytes:93 (93.0 B)
 From a first look, the command line info seems OK.
 root@r-7-VM:/etc/cloudstack# cat cmdline.json 
 {
 config: {
 baremetalnotificationapikey: 
 pPgegDQwez17eCbRj4Wx8IwFs543rcPpF7Gavvtys_D7w1jnAoyJ4A-21H9Bf58s1ZjC4DTVrD0BHxNA3y7agA,
  
 baremetalnotificationsecuritykey: 
 Sxv0QbIgRTH-PkeDWBsY-GYsKz2WIz9JIyWTK16mNnIPPZ-Ozo940_8d8bSEx5pHZ4rEdxG5HQMRRcchANHuHg,
  
 disable_rp_filter: true, 
 dns1: 8.8.8.8, 
 domain: cs2cloud, 
 eth1ip: 169.254.0.249, 
 eth1mask: 255.255.0.0, 
 host: 192.168.22.61, 
 name: r-7-VM, 
 port: 8080, 
 redundant_router: false, 
 template: domP, 
 type: vpcrouter, 
 vpccidr: 10.0.1.0/24
 }, 
 id: cmdline
 [~wilder.rodrigues] Let's have a look when you're back!



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

[jira] [Commented] (CLOUDSTACK-8759) Destroying VPC router results in a new unusable VPC router


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14715501#comment-14715501
 ] 

Michael Andersen commented on CLOUDSTACK-8759:
--

manually running this command confirms the timeout

 Destroying VPC router results in a new unusable VPC router
 --

 Key: CLOUDSTACK-8759
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8759
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.6.0
 Environment: ACS master/4.6 with XenServer and KVM tested
Reporter: Remi Bergsma
Priority: Critical
 Fix For: 4.6.0


 Deploy VPC
 Deploy VM
 This all works fine
 Shutdown, then destroy VPC
 Expected result:
 A new VPC router is deployed that has the same functionality than before, but 
 with a new router instance ID.
 Experienced result:
 VPC router is unaccessible for CloudStack due to missing link-local interface:
 root@r-7-VM:~# ifconfig -a
 loLink encap:Local Loopback  
   inet addr:127.0.0.1  Mask:255.0.0.0
   UP LOOPBACK RUNNING  MTU:16436  Metric:1
   RX packets:1 errors:0 dropped:0 overruns:0 frame:0
   TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:0 
   RX bytes:93 (93.0 B)  TX bytes:93 (93.0 B)
 From a first look, the command line info seems OK.
 root@r-7-VM:/etc/cloudstack# cat cmdline.json 
 {
 config: {
 baremetalnotificationapikey: 
 pPgegDQwez17eCbRj4Wx8IwFs543rcPpF7Gavvtys_D7w1jnAoyJ4A-21H9Bf58s1ZjC4DTVrD0BHxNA3y7agA,
  
 baremetalnotificationsecuritykey: 
 Sxv0QbIgRTH-PkeDWBsY-GYsKz2WIz9JIyWTK16mNnIPPZ-Ozo940_8d8bSEx5pHZ4rEdxG5HQMRRcchANHuHg,
  
 disable_rp_filter: true, 
 dns1: 8.8.8.8, 
 domain: cs2cloud, 
 eth1ip: 169.254.0.249, 
 eth1mask: 255.255.0.0, 
 host: 192.168.22.61, 
 name: r-7-VM, 
 port: 8080, 
 redundant_router: false, 
 template: domP, 
 type: vpcrouter, 
 vpccidr: 10.0.1.0/24
 }, 
 id: cmdline
 [~wilder.rodrigues] Let's have a look when you're back!



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

[jira] [Commented] (CLOUDSTACK-8713) HA is not working on CentOS 7 due to KVM Power state report not properly parsed (Exception)

2015-08-26 Thread Daan Hoogland (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14715530#comment-14715530
 ] 

Daan Hoogland commented on CLOUDSTACK-8713:
---

The problem as described by Remi can not be reproduced. HA has some strange 
qualities, however.
In a setup as described;
- When a VM is stopped on the hypervisor, ha seems to work fine.
- When a kvm host is kick from under us (power off or network unplug) ha seems 
to work fine.
- When shutdown is performed on the host or the agent is stopped with service 
stop, ha doesn't work.

It seems to be a problem with the state machine handling host states. A host in 
Disconnected or Alert state does not recover nor do its VMs.

 HA is not working on CentOS 7 due to KVM Power state report not properly 
 parsed (Exception)
 ---

 Key: CLOUDSTACK-8713
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8713
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.6.0
 Environment: KVM on CentOS 7, management server running latest master 
 aka 4.6.0
Reporter: Remi Bergsma
Priority: Critical

 While testing a PR, I found that HA on KVM does not work properly. 
 Steps to reproduce:
 - Spin up some VMs on KVM using a HA offering
 - go to KVM hypervisor and kill one of them to simulate a crash
 virsh destroy 6 (change number)
 - look how cloudstack handles this missing VM
 Result:
 - VM stays down and is not started
 Expected result:
 - VM should be started somewhere
 Cause:
 It doesn’t parse the power report property it gets from the hypervisor, so it 
 never marks it Stopped. HA will not start, VM will stay down.
 Database reports PowerStateMissing. Starting manually works fine.
 select name,power_state,instance_name,state from vm_instance where 
 name='test003';
 | name| power_state| instance_name | state   |
 | test003 | PowerReportMissing | i-2-6-VM  | Running |
 1 row in set (0.00 sec)
 I also tried to crash a KVM hypervisor and then the same thing happens.
 Haven’t tested it on other hypervisors. Could anyone verify this?
 Logs:
 2015-08-06 15:40:46,809 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
 (AgentManager-Handler-16:null) VM state report is updated. host: 1, vm id: 6, 
 power state: PowerReportMissing 
 2015-08-06 15:40:46,815 INFO  [c.c.v.VirtualMachineManagerImpl] 
 (AgentManager-Handler-16:null) VM i-2-6-VM is at Running and we received a 
 power-off report while there is no pending jobs on it
 2015-08-06 15:40:46,815 INFO  [c.c.v.VirtualMachineManagerImpl] 
 (AgentManager-Handler-16:null) Detected out-of-band stop of a HA enabled VM 
 i-2-6-VM, will schedule restart
 2015-08-06 15:40:46,824 INFO  [c.c.h.HighAvailabilityManagerImpl] 
 (AgentManager-Handler-16:null) Schedule vm for HA:  VM[User|i-2-6-VM]
 2015-08-06 15:40:46,824 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
 (AgentManager-Handler-16:null) Done with process of VM state report. host: 1
 2015-08-06 15:40:46,851 INFO  [c.c.h.HighAvailabilityManagerImpl] 
 (HA-Worker-3:ctx-4e073b92 work-37) Processing 
 HAWork[37-HA-6-Running-Investigating]
 2015-08-06 15:40:46,871 INFO  [c.c.h.HighAvailabilityManagerImpl] 
 (HA-Worker-3:ctx-4e073b92 work-37) HA on VM[User|i-2-6-VM]
 2015-08-06 15:40:46,880 DEBUG [c.c.a.t.Request] (HA-Worker-3:ctx-4e073b92 
 work-37) Seq 1-6463228415230083145: Sending  { Cmd , MgmtId: 3232241215, via: 
 1(kvm2), Ver: v1, Flags: 100011, 
 [{com.cloud.agent.api.CheckVirtualMachineCommand:{vmName:i-2-6-VM,wait:20}}]
  }
 2015-08-06 15:40:46,908 ERROR [c.c.a.t.Request] 
 (AgentManager-Handler-17:null) Unable to convert to json: 
 [{com.cloud.agent.api.CheckVirtualMachineAnswer:{state:Stopped,result:true,contextMap:{},wait:0}}]
 2015-08-06 15:40:46,909 WARN  [c.c.u.n.Task] (AgentManager-Handler-17:null) 
 Caught the following exception but pushing on
 com.google.gson.JsonParseException: The JsonDeserializer EnumTypeAdapter 
 failed to deserialize json object Stopped given the type class 
 com.cloud.vm.VirtualMachine$PowerState
 at 
 com.google.gson.JsonDeserializerExceptionWrapper.deserialize(JsonDeserializerExceptionWrapper.java:64)
 at 
 com.google.gson.JsonDeserializationVisitor.invokeCustomDeserializer(JsonDeserializationVisitor.java:92)
 at 
 com.google.gson.JsonObjectDeserializationVisitor.visitFieldUsingCustomHandler(JsonObjectDeserializationVisitor.java:117)
 at 
 com.google.gson.ReflectingFieldNavigator.visitFieldsReflectively(ReflectingFieldNavigator.java:63)
 at com.google.gson.ObjectNavigator.accept(ObjectNavigator.java:120)
 at

[jira] [Comment Edited] (CLOUDSTACK-8759) Destroying VPC router results in a new unusable VPC router


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14715501#comment-14715501
 ] 

Michael Andersen edited comment on CLOUDSTACK-8759 at 8/26/15 10:09 PM:


manually running this command confirms the timeout

possibly related:
https://issues.apache.org/jira/browse/CLOUDSTACK-2823



was (Author: michaelandersen):
manually running this command confirms the timeout

 Destroying VPC router results in a new unusable VPC router
 --

 Key: CLOUDSTACK-8759
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8759
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.6.0
 Environment: ACS master/4.6 with XenServer and KVM tested
Reporter: Remi Bergsma
Priority: Critical
 Fix For: 4.6.0


 Deploy VPC
 Deploy VM
 This all works fine
 Shutdown, then destroy VPC
 Expected result:
 A new VPC router is deployed that has the same functionality than before, but 
 with a new router instance ID.
 Experienced result:
 VPC router is unaccessible for CloudStack due to missing link-local interface:
 root@r-7-VM:~# ifconfig -a
 loLink encap:Local Loopback  
   inet addr:127.0.0.1  Mask:255.0.0.0
   UP LOOPBACK RUNNING  MTU:16436  Metric:1
   RX packets:1 errors:0 dropped:0 overruns:0 frame:0
   TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:0 
   RX bytes:93 (93.0 B)  TX bytes:93 (93.0 B)
 From a first look, the command line info seems OK.
 root@r-7-VM:/etc/cloudstack# cat cmdline.json 
 {
 config: {
 baremetalnotificationapikey: 
 pPgegDQwez17eCbRj4Wx8IwFs543rcPpF7Gavvtys_D7w1jnAoyJ4A-21H9Bf58s1ZjC4DTVrD0BHxNA3y7agA,
  
 baremetalnotificationsecuritykey: 
 Sxv0QbIgRTH-PkeDWBsY-GYsKz2WIz9JIyWTK16mNnIPPZ-Ozo940_8d8bSEx5pHZ4rEdxG5HQMRRcchANHuHg,
  
 disable_rp_filter: true, 
 dns1: 8.8.8.8, 
 domain: cs2cloud, 
 eth1ip: 169.254.0.249, 
 eth1mask: 255.255.0.0, 
 host: 192.168.22.61, 
 name: r-7-VM, 
 port: 8080, 
 redundant_router: false, 
 template: domP, 
 type: vpcrouter, 
 vpccidr: 10.0.1.0/24
 }, 
 id: cmdline
 [~wilder.rodrigues] Let's have a look when you're back!



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

[jira] [Closed] (CLOUDSTACK-8443) Support CentOS7 as KVM host

2015-08-26 Thread Remi Bergsma (JIRA)


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

Remi Bergsma closed CLOUDSTACK-8443.


 Support CentOS7 as KVM host
 ---

 Key: CLOUDSTACK-8443
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8443
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.5.0, 4.5.1, 4.6.0
Reporter: Rohit Yadav
Assignee: Remi Bergsma
Priority: Critical
 Fix For: 4.6.0


 CentOS7 as KVM host fails with exception:
 2015-05-05 21:39:45,395{GMT} WARN  [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-5:) LibvirtException 
 org.libvirt.LibvirtException: Controller 'cpuacct' is not wanted, but 'cpu' 
 is co-mounted: Invalid argument
   at org.libvirt.ErrorHandler.processError(Unknown Source)
   at org.libvirt.Connect.processError(Unknown Source)
   at org.libvirt.Connect.processError(Unknown Source)
   at org.libvirt.Connect.domainCreateXML(Unknown Source)
   at 
 com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1267)
   at 
 com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3828)
   at 
 com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1361)
 After umounting cpuacct (umount /sys/fs/cgroup/cpuacct), and restarting host, 
 the exception seen is: (also seen after upgrading linux kernel to 4.0.1)
 2015-05-05 21:40:15,875{GMT} WARN  [kvm.resource.LibvirtComputingResource] 
 (agentRequest-Handler-5:) LibvirtException 
 org.libvirt.LibvirtException: unsupported configuration: CPU tuning is not 
 available on this host
   at org.libvirt.ErrorHandler.processError(Unknown Source)
   at org.libvirt.Connect.processError(Unknown Source)
   at org.libvirt.Connect.processError(Unknown Source)
   at org.libvirt.Connect.domainCreateXML(Unknown Source)
   at 
 com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1267)



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

[jira] [Commented] (CLOUDSTACK-8766) In zone based template listings, infinite scrolling pagination is broken


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712633#comment-14712633
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8766:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/740#issuecomment-134873788
  
I've updated the PR to fix the same issue for listing isos and also 
addition code to de-dupe list iso and template results.


 In zone based template listings, infinite scrolling pagination is broken
 

 Key: CLOUDSTACK-8766
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8766
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.5.0, 4.5.1, 4.5.2
Reporter: Rohit Yadav
Assignee: Rohit Yadav
Priority: Minor
 Fix For: 4.5.3, 4.6.0


 On the template page, when a template is select, goto Zones tab and scroll to 
 list all the templates. In case the number of zones are more than 20 there is 
 an infinite scrolling/listing issue as it does not paginate the result. The 
 fix would be to use listViewDataProvider to get pagination when requesting 
 the API.



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

[jira] [Commented] (CLOUDSTACK-8725) RVR functionality is broken in case of isolated networks, conntrackd fails to start.


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712877#comment-14712877
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8725:


Github user michaelandersen commented on the pull request:

https://github.com/apache/cloudstack/pull/692#issuecomment-134932710
  
verified that conntrackd starts on redundant vpc routers. 
LGTM in that respect.

Design wise i feel we need to refactor this, naming of copy_if_needed is 
ambiguous. 
Also we're running a lot of boilerplate code which can be replaced by more 
widely used and maintained python packages. 
 



 RVR functionality is broken in case of isolated networks, conntrackd fails to 
 start.
 

 Key: CLOUDSTACK-8725
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8725
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Virtual Router
Affects Versions: 4.6.0
Reporter: Bharat Kumar
Assignee: Bharat Kumar
Priority: Critical
 Fix For: 4.6.0


 I tried setting up a rvr enabled isolated network. In the startup logs of the 
 router i can see that conntrackd is failing to start.  Below are the startup 
 logs
 [info] Setting console screen modes.
 setterm: cannot (un)set powersave mode: Invalid argument
 [info] Skipping font and keymap setup (handled by console-setup).
 [] Loading IPsec SA/SP database: 
 [ ok etc/ipsec-tools.conf.
 INIT: Entering runlevel: 2
 [info] Using makefile-style concurrent boot in runlevel 2.
 [info] ipvsadm is not configured to run. Please edit /etc/default/ipvsadm.
 [ ok ] Loading iptables rules... IPv4... IPv6...done.
 [ ok ] Starting rpcbind daemon...[] Already running..
 sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory
 open-vm-tools: not starting as this is not a VMware VM
 [ ok ] Starting enhanced syslogd: rsyslogd.
 [] Starting ACPI services...RTNETLINK1 answers: No such file or directory
 acpid: error talking to the kernel via netlink
 . ok 
 [] Starting conntrackdERROR: parsing config file in line (102), symbol 
 'Multicast': syntax error
  failed!
 [ ok ] Starting DNS forwarder and DHCP server: dnsmasq.
 [] Starting web server: apache2apache2: Could not reliably determine the 
 server's fully qualified domain name, using 10.1.1.247 for ServerName
 . ok 
 [ ok ] Starting periodic command scheduler: cron.
 [] Starting haproxy: haproxy[WARNING] 223/051439 (3480) : config : 
 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode.
 [WARNING] 223/051439 (3480) : config : 'option forwardfor' ignored for proxy 
 'cloud-default' as it requires HTTP mode.
 [WARNING] 223/051439 (3484) : config : 'stats' statement ignored for proxy 
 'cloud-default' as it requires HTTP mode.
 [WARNING] 223/051439 (3484) : config : 'option forwardfor' ignored for proxy 
 'cloud-default' as it requires HTTP mode.
 . ok 
 [FAIL] Starting keepalived: keepalived failed!
 [ ok ] Starting NTP server: ntpd.
 [ ok ] Starting OpenBSD Secure Shell server: sshd.
 [ ok ] Starting the system activity data collector: sadc.
 Detecting Linux distribution version: OK
 Starting xe daemon:  OK
 [ ok ] Starting OpenBSD Secure Shell server: sshd.
 [] Starting haproxy: haproxy[WARNING] 223/051440 (3709) : config : 
 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode.
 [WARNING] 223/051440 (3709) : config : 'option forwardfor' ignored for proxy 
 'cloud-default' as it requires HTTP mode.
 . ok 
 [] Starting web server: apache2apache2: Could not reliably determine the 
 server's fully qualified domain name, using 10.1.1.247 for ServerName
 httpd (pid 3351) already running
 . ok 
 [FAIL] Starting keepalived: keepalived failed!
 [] Starting conntrackdERROR: parsing config file in line (102), symbol 
 'Multicast': syntax error
  failed!
 sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory
 Failed
 [ ok ] Stopping NFS common utilities: idmapd statd.
 -On router.
 root@r-93-VM:~# service conntrackd restart
 [] Stopping conntrackdERROR: parsing config file in line (102), symbol 
 'Multicast': syntax error
  failed!
 [] Starting conntrackdERROR: parsing config file in line (102), symbol 
 'Multicast': syntax error
  failed!



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

[jira] [Updated] (CLOUDSTACK-8602) MigrateVirtualMachineWithVolume leaves old chain data for volume


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

Rajani Karuturi updated CLOUDSTACK-8602:

Assignee: Likitha Shetty  (was: Suresh Kumar Anaparti)

 MigrateVirtualMachineWithVolume leaves old chain data for volume
 

 Key: CLOUDSTACK-8602
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8602
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Likitha Shetty
Assignee: Likitha Shetty
 Fix For: 4.6.0


 CS maintains chain info of every volume in DB, where chain info is the 
 complete volume path. When the volumes associated with a VM are migrated to 
 different storage pool, their chain info changes, but this information is not 
 reflected in the DB.



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

[jira] [Resolved] (CLOUDSTACK-8610) [VMWARE] Unable to attach 7th Disk to a Windows server 2012R2 instance


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

Rajani Karuturi resolved CLOUDSTACK-8610.
-
Resolution: Fixed

 [VMWARE] Unable to attach 7th Disk to a Windows server 2012R2 instance
 --

 Key: CLOUDSTACK-8610
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8610
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Likitha Shetty
Assignee: Likitha Shetty
 Fix For: 4.6.0


 +Steps to reproduce+
 1. Set global config vmware.root.disk.controller to 'osdefault'.
 2. Deploy a VM and attach 6 disks to the VM.
 3. Try to attach a 7th disk to the VM.
 Step 3 will fail with the below error
 {noformat}
 2015-06-22 11:03:22,673 ERROR [c.c.s.r.VmwareStorageProcessor] 
 (DirectAgent-636:ctx-8e72c2d9 s1p-z1-esxic-001.es.local, job-9286/job-9287, 
 cmd: AttachCommand) (logid:6372e940) Failed to attach volume: Failed to add 
 disk scsi0:7. 
 java.lang.RuntimeException: Failed to add disk scsi0:7. 
 at 
 com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:336)
  
 at 
 com.cloud.hypervisor.vmware.mo.VirtualMachineMO.attachDisk(VirtualMachineMO.java:1206)
 {noformat}



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

[jira] [Updated] (CLOUDSTACK-8610) [VMWARE] Unable to attach 7th Disk to a Windows server 2012R2 instance


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

Rajani Karuturi updated CLOUDSTACK-8610:

Assignee: Likitha Shetty  (was: Suresh Kumar Anaparti)

 [VMWARE] Unable to attach 7th Disk to a Windows server 2012R2 instance
 --

 Key: CLOUDSTACK-8610
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8610
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Likitha Shetty
Assignee: Likitha Shetty
 Fix For: 4.6.0


 +Steps to reproduce+
 1. Set global config vmware.root.disk.controller to 'osdefault'.
 2. Deploy a VM and attach 6 disks to the VM.
 3. Try to attach a 7th disk to the VM.
 Step 3 will fail with the below error
 {noformat}
 2015-06-22 11:03:22,673 ERROR [c.c.s.r.VmwareStorageProcessor] 
 (DirectAgent-636:ctx-8e72c2d9 s1p-z1-esxic-001.es.local, job-9286/job-9287, 
 cmd: AttachCommand) (logid:6372e940) Failed to attach volume: Failed to add 
 disk scsi0:7. 
 java.lang.RuntimeException: Failed to add disk scsi0:7. 
 at 
 com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:336)
  
 at 
 com.cloud.hypervisor.vmware.mo.VirtualMachineMO.attachDisk(VirtualMachineMO.java:1206)
 {noformat}



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

[jira] [Commented] (CLOUDSTACK-8721) Setting details of VM through API results in removal of all other details except the one passed in API


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712918#comment-14712918
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8721:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/673#issuecomment-134940325
  
ah, I see merging now :)


 Setting details of VM through API results in removal of all other details 
 except the one passed in API
 --

 Key: CLOUDSTACK-8721
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8721
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Anshul Gangwar
Assignee: Anshul Gangwar

 Setting details of VM through API results in removal of all other details 
 except the one passed in API. We are storing vm details which are not set by 
 user and in this process of setting details all details are getting lost 
 which could lead to other issues.



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

[jira] [Commented] (CLOUDSTACK-8773) NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the same time

2015-08-26 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712701#comment-14712701
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8773:


GitHub user nlivens opened a pull request:

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

CLOUDSTACK-8773 : NPE in CheckRouterTask, when a DomainRouter happens…

… to be expunged at the same time

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nlivens/cloudstack CLOUDSTACK-8773

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/745.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #745


commit f91955d9a914179e9fb35e0994ef2b1afc6a2a28
Author: Nick Livens nick.liv...@nuagenetworks.net
Date:   2015-08-26T07:36:00Z

CLOUDSTACK-8773 : NPE in CheckRouterTask, when a DomainRouter happens to be 
expunged at the same time




 NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the 
 same time
 ---

 Key: CLOUDSTACK-8773
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8773
 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
Reporter: Nick Livens
Priority: Minor

 During restart network of a tier with public LB, following exception occurred:
 {noformat:title=exception in management-server.log}
 2015-07-24 02:09:06,086 DEBUG [c.c.a.t.Request] (Job-Executor-44:ctx-7e4a9dc8 
 ctx-f882738e) Seq 1-59048436: Received:  { Ans: , MgmtId: 275619427002880, 
 via: 1, Ver: v1, Flags: 10, { Answer } }
 2015-07-24 02:09:06,166 INFO  [o.a.c.s.v.VolumeServiceImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Volume 11 is not referred 
 anywhere, remove it from volumes table
 2015-07-24 02:09:06,263 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Expunged 
 VM[VpcInlineLoadBalancerVm|b-8-VM]
 2015-07-24 02:09:06,391 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Found 2 routers to update status.
 2015-07-24 02:09:06,393 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Fail to complete the CheckRouterTask!
 java.lang.NullPointerException
 at 
 com.cloud.network.vpn.Site2SiteVpnManagerImpl.getConnectionsForRouter(Site2SiteVpnManagerImpl.java:732)
 at sun.reflect.GeneratedMethodAccessor268.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 
 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.$Proxy206.getConnectionsForRouter(Unknown 
 Source)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.updateSite2SiteVpnConnectionState(VirtualNetworkApplianceManagerImpl.java:1044)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl$CheckRouterTask.runInContext(VirtualNetworkApplianceManagerImpl.java:1348)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at

[jira] [Commented] (CLOUDSTACK-8749) KVM: link local route cleanup


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712718#comment-14712718
 ] 

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

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

CLOUDSTACK-8749: Add checks to prevent malformed/unexpected input

Based on @jburwell's comment on PR #718

This closes #735

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com


 KVM: link local route cleanup
 -

 Key: CLOUDSTACK-8749
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8749
 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: 4.5.3, 4.6.0


 The KVM agent attempts to delete link local interfaces whenever found, so 
 they don't conflict with the system vm's link local route on cloud0, however 
 it doesn't specify which device to delete the route for.
 The aim is to fix the edge case which (unlikely) can try to delete existing 
 cloud0 routes/interface.



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

[jira] [Commented] (CLOUDSTACK-8749) KVM: link local route cleanup

2015-08-26 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712720#comment-14712720
 ] 

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

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

Merge pull request #735 from shapeblue/kvm-linkbr-checks-master

CLOUDSTACK-8749: Add checks to prevent malformed/unexpected inputBased on 
@jburwell's comment on PR #718

* pr/735:
  CLOUDSTACK-8749: Add checks to prevent malformed/unexpected input

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com


 KVM: link local route cleanup
 -

 Key: CLOUDSTACK-8749
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8749
 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: 4.5.3, 4.6.0


 The KVM agent attempts to delete link local interfaces whenever found, so 
 they don't conflict with the system vm's link local route on cloud0, however 
 it doesn't specify which device to delete the route for.
 The aim is to fix the edge case which (unlikely) can try to delete existing 
 cloud0 routes/interface.



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

[jira] [Commented] (CLOUDSTACK-8749) KVM: link local route cleanup

2015-08-26 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712719#comment-14712719
 ] 

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

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

Merge pull request #735 from shapeblue/kvm-linkbr-checks-master

CLOUDSTACK-8749: Add checks to prevent malformed/unexpected inputBased on 
@jburwell's comment on PR #718

* pr/735:
  CLOUDSTACK-8749: Add checks to prevent malformed/unexpected input

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com


 KVM: link local route cleanup
 -

 Key: CLOUDSTACK-8749
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8749
 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: 4.5.3, 4.6.0


 The KVM agent attempts to delete link local interfaces whenever found, so 
 they don't conflict with the system vm's link local route on cloud0, however 
 it doesn't specify which device to delete the route for.
 The aim is to fix the edge case which (unlikely) can try to delete existing 
 cloud0 routes/interface.



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

[jira] [Commented] (CLOUDSTACK-8749) KVM: link local route cleanup


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712722#comment-14712722
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8749:


Github user asfgit closed the pull request at:

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


 KVM: link local route cleanup
 -

 Key: CLOUDSTACK-8749
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8749
 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: 4.5.3, 4.6.0


 The KVM agent attempts to delete link local interfaces whenever found, so 
 they don't conflict with the system vm's link local route on cloud0, however 
 it doesn't specify which device to delete the route for.
 The aim is to fix the edge case which (unlikely) can try to delete existing 
 cloud0 routes/interface.



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

[jira] [Updated] (CLOUDSTACK-8773) NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the same time


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

Rajani Karuturi updated CLOUDSTACK-8773:

Assignee: Nick Livens

 NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the 
 same time
 ---

 Key: CLOUDSTACK-8773
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8773
 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
Reporter: Nick Livens
Assignee: Nick Livens
Priority: Minor

 During restart network of a tier with public LB, following exception occurred:
 {noformat:title=exception in management-server.log}
 2015-07-24 02:09:06,086 DEBUG [c.c.a.t.Request] (Job-Executor-44:ctx-7e4a9dc8 
 ctx-f882738e) Seq 1-59048436: Received:  { Ans: , MgmtId: 275619427002880, 
 via: 1, Ver: v1, Flags: 10, { Answer } }
 2015-07-24 02:09:06,166 INFO  [o.a.c.s.v.VolumeServiceImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Volume 11 is not referred 
 anywhere, remove it from volumes table
 2015-07-24 02:09:06,263 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Expunged 
 VM[VpcInlineLoadBalancerVm|b-8-VM]
 2015-07-24 02:09:06,391 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Found 2 routers to update status.
 2015-07-24 02:09:06,393 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Fail to complete the CheckRouterTask!
 java.lang.NullPointerException
 at 
 com.cloud.network.vpn.Site2SiteVpnManagerImpl.getConnectionsForRouter(Site2SiteVpnManagerImpl.java:732)
 at sun.reflect.GeneratedMethodAccessor268.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 
 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.$Proxy206.getConnectionsForRouter(Unknown 
 Source)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.updateSite2SiteVpnConnectionState(VirtualNetworkApplianceManagerImpl.java:1044)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl$CheckRouterTask.runInContext(VirtualNetworkApplianceManagerImpl.java:1348)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at 
 java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)
 2015-07-24 02:09:06,580 DEBUG 
 [c.c.n.l.VpcInlineLoadBalancerVMManagerImpl] (Job-Executor-44:ctx-7e4a9dc8 
 ctx-f882738e) Attempting to destroy VpcInline LB vm 8
 2015-07-24 02:09:06,586 DEBUG [o.a.c.e.o.NetworkOrchestrator]

[jira] [Commented] (CLOUDSTACK-8773) NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the same time


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712756#comment-14712756
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8773:


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

https://github.com/apache/cloudstack/pull/745#discussion_r37960337
  
--- Diff: engine/schema/src/com/cloud/vm/dao/DomainRouterDaoImpl.java ---
@@ -251,8 +251,11 @@ public boolean remove(final Long id) {
 sc.setJoinParameters(networkRouter, type, 
Network.GuestType.Isolated);
 final ListDomainRouterVO routerIds = listBy(sc);
 final ListDomainRouterVO routers = new 
ArrayListDomainRouterVO();
-for (final DomainRouterVO router : routerIds) {
-routers.add(findById(router.getId()));
+for (DomainRouterVO router : routerIds) {
+router = findById(router.getId());
--- End diff --

Can you use 
`CollectionUtils.addIgnoreNull(routers,findById(router.getId()))`?


 NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the 
 same time
 ---

 Key: CLOUDSTACK-8773
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8773
 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
Reporter: Nick Livens
Assignee: Nick Livens
Priority: Minor

 During restart network of a tier with public LB, following exception occurred:
 {noformat:title=exception in management-server.log}
 2015-07-24 02:09:06,086 DEBUG [c.c.a.t.Request] (Job-Executor-44:ctx-7e4a9dc8 
 ctx-f882738e) Seq 1-59048436: Received:  { Ans: , MgmtId: 275619427002880, 
 via: 1, Ver: v1, Flags: 10, { Answer } }
 2015-07-24 02:09:06,166 INFO  [o.a.c.s.v.VolumeServiceImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Volume 11 is not referred 
 anywhere, remove it from volumes table
 2015-07-24 02:09:06,263 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Expunged 
 VM[VpcInlineLoadBalancerVm|b-8-VM]
 2015-07-24 02:09:06,391 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Found 2 routers to update status.
 2015-07-24 02:09:06,393 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Fail to complete the CheckRouterTask!
 java.lang.NullPointerException
 at 
 com.cloud.network.vpn.Site2SiteVpnManagerImpl.getConnectionsForRouter(Site2SiteVpnManagerImpl.java:732)
 at sun.reflect.GeneratedMethodAccessor268.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 
 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.$Proxy206.getConnectionsForRouter(Unknown 
 Source)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.updateSite2SiteVpnConnectionState(VirtualNetworkApplianceManagerImpl.java:1044)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl$CheckRouterTask.runInContext(VirtualNetworkApplianceManagerImpl.java:1348)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at

[jira] [Commented] (CLOUDSTACK-8765) vm migration failed due to different dev name on KVM


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712771#comment-14712771
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8765:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/736#issuecomment-134912144
  
@ustcweizhou interesting find and fix, we should also merge this on 4.5; 
LGTM.


 vm migration failed due to different dev name on KVM
 

 Key: CLOUDSTACK-8765
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8765
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Wei Zhou
Assignee: Wei Zhou

 The devname of ethernet nics could be different.
 for example, the first nic name is eth0 in some linux OS, and em1 in other 
 linux OS, and bond0 if we use linux bonding.
 The vm can not be migrated between them due to different dev name.
 http://cloudstack.markmail.org/message/jacsml3wy5tmeerp
 http://cloudstack.markmail.org/message/ovmmt25vfqkowp2z
 the fix is:
 http://cloudstack.markmail.org/message/d4iocagbc6m25zxk



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

[jira] [Commented] (CLOUDSTACK-8773) NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the same time


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712789#comment-14712789
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8773:


Github user nlivens commented on the pull request:

https://github.com/apache/cloudstack/pull/745#issuecomment-134914138
  
@karuturi I've used the method you suggested, this problem occurs in a 
specific scenario which is hard to reproduce in a consistent way. 


 NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the 
 same time
 ---

 Key: CLOUDSTACK-8773
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8773
 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
Reporter: Nick Livens
Assignee: Nick Livens
Priority: Minor

 During restart network of a tier with public LB, following exception occurred:
 {noformat:title=exception in management-server.log}
 2015-07-24 02:09:06,086 DEBUG [c.c.a.t.Request] (Job-Executor-44:ctx-7e4a9dc8 
 ctx-f882738e) Seq 1-59048436: Received:  { Ans: , MgmtId: 275619427002880, 
 via: 1, Ver: v1, Flags: 10, { Answer } }
 2015-07-24 02:09:06,166 INFO  [o.a.c.s.v.VolumeServiceImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Volume 11 is not referred 
 anywhere, remove it from volumes table
 2015-07-24 02:09:06,263 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Expunged 
 VM[VpcInlineLoadBalancerVm|b-8-VM]
 2015-07-24 02:09:06,391 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Found 2 routers to update status.
 2015-07-24 02:09:06,393 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Fail to complete the CheckRouterTask!
 java.lang.NullPointerException
 at 
 com.cloud.network.vpn.Site2SiteVpnManagerImpl.getConnectionsForRouter(Site2SiteVpnManagerImpl.java:732)
 at sun.reflect.GeneratedMethodAccessor268.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 
 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.$Proxy206.getConnectionsForRouter(Unknown 
 Source)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.updateSite2SiteVpnConnectionState(VirtualNetworkApplianceManagerImpl.java:1044)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl$CheckRouterTask.runInContext(VirtualNetworkApplianceManagerImpl.java:1348)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at 
 java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at

[jira] [Commented] (CLOUDSTACK-8761) Management server heartbeat takes too long to finish


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712863#comment-14712863
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8761:


Github user miguelaferreira commented on the pull request:

https://github.com/apache/cloudstack/pull/730#issuecomment-134930757
  
@karuturi Just tried the code you posted, and this was the result:

```zsh
jsonTmp=pr.json
prAuthor=$(cat ${jsonTmp} | python -c 
try:
  import sys, json
  print 
json.load(sys.stdin)['user']['login'].encode('utf-8').decode('ascii','ignore')
except:
  print ''
)
echo $prAuthor 

ustcweizhou
```


 Management server heartbeat takes too long to finish
 

 Key: CLOUDSTACK-8761
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8761
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Wei Zhou
Assignee: Wei Zhou

 We got a lot of debug message in management-server.log every 1.5 seconds.
 The cluster.heartbeat.interval is set to 1500 by default. As it was not 
 changed after its first commit, so I think it is 1500 ms.
 However, The durations are less than 10ms actually.
 2015-08-18 00:00:04,526 DEBUG [c.c.c.ClusterManagerImpl] 
 (Cluster-Heartbeat-1:ctx-047bb88f) Management server heartbeat takes too long 
 to finish. profiler: Done. Duration: 4ms, profilerHeartbeatUpdate: Done. 
 Duration: 3ms, profilerPeerScan: Done. Duration: 0ms
 2015-08-18 00:00:06,036 DEBUG [c.c.c.ClusterManagerImpl] 
 (Cluster-Heartbeat-1:ctx-68018e26) Peer scan takes too long to finish. 
 profiler: Done. Duration: 0ms, profilerQueryActiveList: Done. Duration: 0ms, 
 profilerSyncClusterInfo: Done. Duration: 0ms, profilerInvalidatedNodeList: 
 Done. Duration: 0ms, profilerRemovedList: Done. Duration: 0ms



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

[jira] [Commented] (CLOUDSTACK-8721) Setting details of VM through API results in removal of all other details except the one passed in API

2015-08-26 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712865#comment-14712865
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8721:


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

https://github.com/apache/cloudstack/pull/673#discussion_r37964980
  
--- Diff: server/src/com/cloud/vm/UserVmManagerImpl.java ---
@@ -2188,7 +2188,13 @@ public UserVm updateVirtualMachine(UpdateVMCmd cmd) 
throws ResourceUnavailableEx
 }
 
 if (details != null  !details.isEmpty()) {
-vmInstance.setDetails(details);
+_vmDao.loadDetails(vmInstance);
--- End diff --

When do we need to remove detail? Even if needed then those values can be 
updated to get the desired effect. Many details are for internal purposes only 
and user is not even aware of them.


 Setting details of VM through API results in removal of all other details 
 except the one passed in API
 --

 Key: CLOUDSTACK-8721
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8721
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Anshul Gangwar
Assignee: Anshul Gangwar

 Setting details of VM through API results in removal of all other details 
 except the one passed in API. We are storing vm details which are not set by 
 user and in this process of setting details all details are getting lost 
 which could lead to other issues.



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

[jira] [Commented] (CLOUDSTACK-8773) NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the same time


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712898#comment-14712898
 ] 

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

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

Merge pull request #745 from nlivens/CLOUDSTACK-8773

CLOUDSTACK-8773 : NPE in CheckRouterTask, when a DomainRouter happens to be 
expunged at the same time

* pr/745:
  CLOUDSTACK-8773 : NPE in CheckRouterTask, when a DomainRouter happens to be 
expunged at the same time

Signed-off-by: Rajani Karuturi rajani.karut...@citrix.com


 NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the 
 same time
 ---

 Key: CLOUDSTACK-8773
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8773
 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
Reporter: Nick Livens
Assignee: Nick Livens
Priority: Minor

 During restart network of a tier with public LB, following exception occurred:
 {noformat:title=exception in management-server.log}
 2015-07-24 02:09:06,086 DEBUG [c.c.a.t.Request] (Job-Executor-44:ctx-7e4a9dc8 
 ctx-f882738e) Seq 1-59048436: Received:  { Ans: , MgmtId: 275619427002880, 
 via: 1, Ver: v1, Flags: 10, { Answer } }
 2015-07-24 02:09:06,166 INFO  [o.a.c.s.v.VolumeServiceImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Volume 11 is not referred 
 anywhere, remove it from volumes table
 2015-07-24 02:09:06,263 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Expunged 
 VM[VpcInlineLoadBalancerVm|b-8-VM]
 2015-07-24 02:09:06,391 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Found 2 routers to update status.
 2015-07-24 02:09:06,393 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Fail to complete the CheckRouterTask!
 java.lang.NullPointerException
 at 
 com.cloud.network.vpn.Site2SiteVpnManagerImpl.getConnectionsForRouter(Site2SiteVpnManagerImpl.java:732)
 at sun.reflect.GeneratedMethodAccessor268.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 
 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.$Proxy206.getConnectionsForRouter(Unknown 
 Source)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.updateSite2SiteVpnConnectionState(VirtualNetworkApplianceManagerImpl.java:1044)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl$CheckRouterTask.runInContext(VirtualNetworkApplianceManagerImpl.java:1348)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at 
 java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
 at

[jira] [Commented] (CLOUDSTACK-8773) NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the same time

2015-08-26 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712899#comment-14712899
 ] 

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

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

Merge pull request #745 from nlivens/CLOUDSTACK-8773

CLOUDSTACK-8773 : NPE in CheckRouterTask, when a DomainRouter happens to be 
expunged at the same time

* pr/745:
  CLOUDSTACK-8773 : NPE in CheckRouterTask, when a DomainRouter happens to be 
expunged at the same time

Signed-off-by: Rajani Karuturi rajani.karut...@citrix.com


 NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the 
 same time
 ---

 Key: CLOUDSTACK-8773
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8773
 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
Reporter: Nick Livens
Assignee: Nick Livens
Priority: Minor

 During restart network of a tier with public LB, following exception occurred:
 {noformat:title=exception in management-server.log}
 2015-07-24 02:09:06,086 DEBUG [c.c.a.t.Request] (Job-Executor-44:ctx-7e4a9dc8 
 ctx-f882738e) Seq 1-59048436: Received:  { Ans: , MgmtId: 275619427002880, 
 via: 1, Ver: v1, Flags: 10, { Answer } }
 2015-07-24 02:09:06,166 INFO  [o.a.c.s.v.VolumeServiceImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Volume 11 is not referred 
 anywhere, remove it from volumes table
 2015-07-24 02:09:06,263 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Expunged 
 VM[VpcInlineLoadBalancerVm|b-8-VM]
 2015-07-24 02:09:06,391 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Found 2 routers to update status.
 2015-07-24 02:09:06,393 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Fail to complete the CheckRouterTask!
 java.lang.NullPointerException
 at 
 com.cloud.network.vpn.Site2SiteVpnManagerImpl.getConnectionsForRouter(Site2SiteVpnManagerImpl.java:732)
 at sun.reflect.GeneratedMethodAccessor268.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 
 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.$Proxy206.getConnectionsForRouter(Unknown 
 Source)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.updateSite2SiteVpnConnectionState(VirtualNetworkApplianceManagerImpl.java:1044)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl$CheckRouterTask.runInContext(VirtualNetworkApplianceManagerImpl.java:1348)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at 
 java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
 at

[jira] [Resolved] (CLOUDSTACK-8773) NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the same time


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

Rajani Karuturi resolved CLOUDSTACK-8773.
-
Resolution: Fixed

 NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the 
 same time
 ---

 Key: CLOUDSTACK-8773
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8773
 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
Reporter: Nick Livens
Assignee: Nick Livens
Priority: Minor

 During restart network of a tier with public LB, following exception occurred:
 {noformat:title=exception in management-server.log}
 2015-07-24 02:09:06,086 DEBUG [c.c.a.t.Request] (Job-Executor-44:ctx-7e4a9dc8 
 ctx-f882738e) Seq 1-59048436: Received:  { Ans: , MgmtId: 275619427002880, 
 via: 1, Ver: v1, Flags: 10, { Answer } }
 2015-07-24 02:09:06,166 INFO  [o.a.c.s.v.VolumeServiceImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Volume 11 is not referred 
 anywhere, remove it from volumes table
 2015-07-24 02:09:06,263 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Expunged 
 VM[VpcInlineLoadBalancerVm|b-8-VM]
 2015-07-24 02:09:06,391 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Found 2 routers to update status.
 2015-07-24 02:09:06,393 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Fail to complete the CheckRouterTask!
 java.lang.NullPointerException
 at 
 com.cloud.network.vpn.Site2SiteVpnManagerImpl.getConnectionsForRouter(Site2SiteVpnManagerImpl.java:732)
 at sun.reflect.GeneratedMethodAccessor268.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 
 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.$Proxy206.getConnectionsForRouter(Unknown 
 Source)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.updateSite2SiteVpnConnectionState(VirtualNetworkApplianceManagerImpl.java:1044)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl$CheckRouterTask.runInContext(VirtualNetworkApplianceManagerImpl.java:1348)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at 
 java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)
 2015-07-24 02:09:06,580 DEBUG 
 [c.c.n.l.VpcInlineLoadBalancerVMManagerImpl] (Job-Executor-44:ctx-7e4a9dc8 
 ctx-f882738e) Attempting to destroy VpcInline LB vm 8
 2015-07-24 02:09:06,586 DEBUG [o.a.c.e.o.NetworkOrchestrator]

[jira] [Commented] (CLOUDSTACK-8749) KVM: link local route cleanup


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712651#comment-14712651
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8749:


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

https://github.com/apache/cloudstack/pull/735#discussion_r37953111
  
--- Diff: 
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
 ---
@@ -286,7 +287,11 @@ private void deleteExitingLinkLocalRouteTable(String 
linkLocalBr) {
 String[] lines = parser.getLines().split(\\n);
 for (String line : lines) {
 String[] tokens = line.split( );
-if (!tokens[2].equalsIgnoreCase(linkLocalBr)) {
+if (tokens != null  tokens.length  2) {
+continue;
+}
+final String device = tokens[2];
+if (!Strings.isNullOrEmpty(device)  
!device.equalsIgnoreCase(linkLocalBr)) {
--- End diff --

With respect to this specific code, I would like do this the next time we 
do a round of refactoring, possibly factor such code to a util class that can 
be used as a general purpose line parsing static method and add unit tests. For 
now, at least the code takes care of malformed inputs. 


 KVM: link local route cleanup
 -

 Key: CLOUDSTACK-8749
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8749
 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: 4.5.3, 4.6.0


 The KVM agent attempts to delete link local interfaces whenever found, so 
 they don't conflict with the system vm's link local route on cloud0, however 
 it doesn't specify which device to delete the route for.
 The aim is to fix the edge case which (unlikely) can try to delete existing 
 cloud0 routes/interface.



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

[jira] [Commented] (CLOUDSTACK-8725) RVR functionality is broken in case of isolated networks, conntrackd fails to start.

2015-08-26 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712652#comment-14712652
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8725:


Github user remibergsma commented on the pull request:

https://github.com/apache/cloudstack/pull/692#issuecomment-134876392
  
@DaanHoogland OK, thanks!



 RVR functionality is broken in case of isolated networks, conntrackd fails to 
 start.
 

 Key: CLOUDSTACK-8725
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8725
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Virtual Router
Affects Versions: 4.6.0
Reporter: Bharat Kumar
Assignee: Bharat Kumar
Priority: Critical
 Fix For: 4.6.0


 I tried setting up a rvr enabled isolated network. In the startup logs of the 
 router i can see that conntrackd is failing to start.  Below are the startup 
 logs
 [info] Setting console screen modes.
 setterm: cannot (un)set powersave mode: Invalid argument
 [info] Skipping font and keymap setup (handled by console-setup).
 [] Loading IPsec SA/SP database: 
 [ ok etc/ipsec-tools.conf.
 INIT: Entering runlevel: 2
 [info] Using makefile-style concurrent boot in runlevel 2.
 [info] ipvsadm is not configured to run. Please edit /etc/default/ipvsadm.
 [ ok ] Loading iptables rules... IPv4... IPv6...done.
 [ ok ] Starting rpcbind daemon...[] Already running..
 sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory
 open-vm-tools: not starting as this is not a VMware VM
 [ ok ] Starting enhanced syslogd: rsyslogd.
 [] Starting ACPI services...RTNETLINK1 answers: No such file or directory
 acpid: error talking to the kernel via netlink
 . ok 
 [] Starting conntrackdERROR: parsing config file in line (102), symbol 
 'Multicast': syntax error
  failed!
 [ ok ] Starting DNS forwarder and DHCP server: dnsmasq.
 [] Starting web server: apache2apache2: Could not reliably determine the 
 server's fully qualified domain name, using 10.1.1.247 for ServerName
 . ok 
 [ ok ] Starting periodic command scheduler: cron.
 [] Starting haproxy: haproxy[WARNING] 223/051439 (3480) : config : 
 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode.
 [WARNING] 223/051439 (3480) : config : 'option forwardfor' ignored for proxy 
 'cloud-default' as it requires HTTP mode.
 [WARNING] 223/051439 (3484) : config : 'stats' statement ignored for proxy 
 'cloud-default' as it requires HTTP mode.
 [WARNING] 223/051439 (3484) : config : 'option forwardfor' ignored for proxy 
 'cloud-default' as it requires HTTP mode.
 . ok 
 [FAIL] Starting keepalived: keepalived failed!
 [ ok ] Starting NTP server: ntpd.
 [ ok ] Starting OpenBSD Secure Shell server: sshd.
 [ ok ] Starting the system activity data collector: sadc.
 Detecting Linux distribution version: OK
 Starting xe daemon:  OK
 [ ok ] Starting OpenBSD Secure Shell server: sshd.
 [] Starting haproxy: haproxy[WARNING] 223/051440 (3709) : config : 
 'stats' statement ignored for proxy 'cloud-default' as it requires HTTP mode.
 [WARNING] 223/051440 (3709) : config : 'option forwardfor' ignored for proxy 
 'cloud-default' as it requires HTTP mode.
 . ok 
 [] Starting web server: apache2apache2: Could not reliably determine the 
 server's fully qualified domain name, using 10.1.1.247 for ServerName
 httpd (pid 3351) already running
 . ok 
 [FAIL] Starting keepalived: keepalived failed!
 [] Starting conntrackdERROR: parsing config file in line (102), symbol 
 'Multicast': syntax error
  failed!
 sed: can't read /ramdisk/rrouter/enable_pubip.sh: No such file or directory
 Failed
 [ ok ] Stopping NFS common utilities: idmapd statd.
 -On router.
 root@r-93-VM:~# service conntrackd restart
 [] Stopping conntrackdERROR: parsing config file in line (102), symbol 
 'Multicast': syntax error
  failed!
 [] Starting conntrackdERROR: parsing config file in line (102), symbol 
 'Multicast': syntax error
  failed!



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

[jira] [Updated] (CLOUDSTACK-8775) [HyperV]NPE while attaching Local storage volume to instance whose root volume is on ZWPS.

2015-08-26 Thread Deepthi Machiraju (JIRA)


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

Deepthi Machiraju updated CLOUDSTACK-8775:
--
Attachment: mysqldump.dmp
management-server.rar

 [HyperV]NPE while attaching Local storage volume to instance whose root 
 volume is on ZWPS.
 --

 Key: CLOUDSTACK-8775
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8775
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.6.0
Reporter: Deepthi Machiraju
Priority: Critical
 Fix For: 4.6.0

 Attachments: management-server.rar, mysqldump.dmp


 - Create a custom disk offering which has the tag of Localstorage.
 - Navigate to Storage and Click on Upload and select the above disk offering 
 with the file URL.
 - After the upload is complete , try attaching the to the instance whose root 
 volume resides on zone wide primary storage.
 Expected Result : 
 - Attach should be sucessful
 Observation :
 Attach is failing with NPE and below is the trace.
 Note : When the root volume is on CLuster storage , volume attch of local 
 storage is sucessful.
 
 2015-08-26 08:07:59,045 DEBUG [o.a.c.s.a.ZoneWideStoragePoolAllocator] 
 (Work-Job-Executor-69:ctx-754f463c job-182/job-183 ctx-20cae27f) 
 ZoneWideStoragePoolAllocator to find storage pool
 2015-08-26 08:07:59,045 ERROR [c.c.v.VmWorkJobHandlerProxy] 
 (Work-Job-Executor-69:ctx-754f463c job-182/job-183 ctx-20cae27f) Invocation 
 exception, caused by: java.lang.NullPointerException
 2015-08-26 08:07:59,045 INFO  [c.c.v.VmWorkJobHandlerProxy] 
 (Work-Job-Executor-69:ctx-754f463c job-182/job-183 ctx-20cae27f) Rethrow 
 exception java.lang.NullPointerException
 2015-08-26 08:07:59,045 DEBUG [c.c.v.VmWorkJobDispatcher] 
 (Work-Job-Executor-69:ctx-754f463c job-182/job-183) Done with run of VM work 
 job: com.cloud.vm.VmWorkAttachVolume for VM 3, job origin: 182
 2015-08-26 08:07:59,045 ERROR [c.c.v.VmWorkJobDispatcher] 
 (Work-Job-Executor-69:ctx-754f463c job-182/job-183) Unable to complete 
 AsyncJobVO {id:183, userId: 2, accountId: 2, instanceType: null, instanceId: 
 null, cmd: com.cloud.vm.VmWorkAttachVolume, cmdInfo: 
 rO0ABXNyAB9jb20uY2xvdWQudm0uVm1Xb3JrQXR0YWNoVm9sdW1lB62v-WGH4hwCAAJMAAhkZXZpY2VJZHQAEExqYXZhL2xhbmcvTG9uZztMAAh2b2x1bWVJZHEAfgABeHIAE2NvbS5jbG91ZC52bS5WbVdvcmufmbZW8CVnawIABEoACWFjY291bnRJZEoABnVzZXJJZEoABHZtSWRMAAtoYW5kbGVyTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO3hwAAIAAgADdAAUVm9sdW1lQXBpU2VydmljZUltcGxwc3IADmphdmEubGFuZy5Mb25nO4vkkMyPI98CAAFKAAV2YWx1ZXhyABBqYXZhLmxhbmcuTnVtYmVyhqyVHQuU4IsCAAB4cAAp,
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 227345751881375, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: Wed Aug 26 08:07:57 UTC 2015}, job origin:182
 java.lang.NullPointerException
 at 
 org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.copyVolumeFromSecToPrimary(VolumeOrchestrator.java:463)
 at 
 org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.copyVolume(VolumeOrchestrator.java:776)
 at 
 org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolumeOnPrimaryStorage(VolumeOrchestrator.java:796)
 at 
 com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:1321)
 at 
 com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:2837)
 at sun.reflect.GeneratedMethodAccessor379.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at 
 com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
 at 
 com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2876)
 at sun.reflect.GeneratedMethodAccessor314.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at 
 org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
 at

[jira] [Commented] (CLOUDSTACK-8749) KVM: link local route cleanup


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712726#comment-14712726
 ] 

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

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

Merge pull request #733 from shapeblue/kvm-linkbr-checks

CLOUDSTACK-8749: Add checks to prevent malformed/unexpected inputBased on 
@jburwell's comment on PR #718

* pr/733:
  CLOUDSTACK-8749: Add checks to prevent malformed/unexpected input

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com


 KVM: link local route cleanup
 -

 Key: CLOUDSTACK-8749
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8749
 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: 4.5.3, 4.6.0


 The KVM agent attempts to delete link local interfaces whenever found, so 
 they don't conflict with the system vm's link local route on cloud0, however 
 it doesn't specify which device to delete the route for.
 The aim is to fix the edge case which (unlikely) can try to delete existing 
 cloud0 routes/interface.



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

[jira] [Commented] (CLOUDSTACK-8773) NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the same time


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712750#comment-14712750
 ] 

Rajani Karuturi commented on CLOUDSTACK-8773:
-

assigned to [~nlivens] as I see a PR from him

 NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the 
 same time
 ---

 Key: CLOUDSTACK-8773
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8773
 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
Reporter: Nick Livens
Assignee: Nick Livens
Priority: Minor

 During restart network of a tier with public LB, following exception occurred:
 {noformat:title=exception in management-server.log}
 2015-07-24 02:09:06,086 DEBUG [c.c.a.t.Request] (Job-Executor-44:ctx-7e4a9dc8 
 ctx-f882738e) Seq 1-59048436: Received:  { Ans: , MgmtId: 275619427002880, 
 via: 1, Ver: v1, Flags: 10, { Answer } }
 2015-07-24 02:09:06,166 INFO  [o.a.c.s.v.VolumeServiceImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Volume 11 is not referred 
 anywhere, remove it from volumes table
 2015-07-24 02:09:06,263 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Expunged 
 VM[VpcInlineLoadBalancerVm|b-8-VM]
 2015-07-24 02:09:06,391 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Found 2 routers to update status.
 2015-07-24 02:09:06,393 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Fail to complete the CheckRouterTask!
 java.lang.NullPointerException
 at 
 com.cloud.network.vpn.Site2SiteVpnManagerImpl.getConnectionsForRouter(Site2SiteVpnManagerImpl.java:732)
 at sun.reflect.GeneratedMethodAccessor268.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 
 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.$Proxy206.getConnectionsForRouter(Unknown 
 Source)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.updateSite2SiteVpnConnectionState(VirtualNetworkApplianceManagerImpl.java:1044)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl$CheckRouterTask.runInContext(VirtualNetworkApplianceManagerImpl.java:1348)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at 
 java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)
 2015-07-24 02:09:06,580 DEBUG 
 [c.c.n.l.VpcInlineLoadBalancerVMManagerImpl] (Job-Executor-44:ctx-7e4a9dc8 
 ctx-f882738e) Attempting to destroy VpcInline LB vm 8
 2015-07-24

[jira] [Commented] (CLOUDSTACK-8773) NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the same time


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712766#comment-14712766
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8773:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/745#issuecomment-134910642
  
LGTM, you can also use the method @karuturi has suggested.


 NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the 
 same time
 ---

 Key: CLOUDSTACK-8773
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8773
 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
Reporter: Nick Livens
Assignee: Nick Livens
Priority: Minor

 During restart network of a tier with public LB, following exception occurred:
 {noformat:title=exception in management-server.log}
 2015-07-24 02:09:06,086 DEBUG [c.c.a.t.Request] (Job-Executor-44:ctx-7e4a9dc8 
 ctx-f882738e) Seq 1-59048436: Received:  { Ans: , MgmtId: 275619427002880, 
 via: 1, Ver: v1, Flags: 10, { Answer } }
 2015-07-24 02:09:06,166 INFO  [o.a.c.s.v.VolumeServiceImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Volume 11 is not referred 
 anywhere, remove it from volumes table
 2015-07-24 02:09:06,263 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Expunged 
 VM[VpcInlineLoadBalancerVm|b-8-VM]
 2015-07-24 02:09:06,391 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Found 2 routers to update status.
 2015-07-24 02:09:06,393 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Fail to complete the CheckRouterTask!
 java.lang.NullPointerException
 at 
 com.cloud.network.vpn.Site2SiteVpnManagerImpl.getConnectionsForRouter(Site2SiteVpnManagerImpl.java:732)
 at sun.reflect.GeneratedMethodAccessor268.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 
 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.$Proxy206.getConnectionsForRouter(Unknown 
 Source)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.updateSite2SiteVpnConnectionState(VirtualNetworkApplianceManagerImpl.java:1044)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl$CheckRouterTask.runInContext(VirtualNetworkApplianceManagerImpl.java:1348)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at 
 java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)
 2015-07-24 02:09:06,580 DEBUG

[jira] [Commented] (CLOUDSTACK-8610) [VMWARE] Unable to attach 7th Disk to a Windows server 2012R2 instance


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712845#comment-14712845
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8610:


Github user asfgit closed the pull request at:

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


 [VMWARE] Unable to attach 7th Disk to a Windows server 2012R2 instance
 --

 Key: CLOUDSTACK-8610
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8610
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Likitha Shetty
Assignee: Suresh Kumar Anaparti
 Fix For: 4.6.0


 +Steps to reproduce+
 1. Set global config vmware.root.disk.controller to 'osdefault'.
 2. Deploy a VM and attach 6 disks to the VM.
 3. Try to attach a 7th disk to the VM.
 Step 3 will fail with the below error
 {noformat}
 2015-06-22 11:03:22,673 ERROR [c.c.s.r.VmwareStorageProcessor] 
 (DirectAgent-636:ctx-8e72c2d9 s1p-z1-esxic-001.es.local, job-9286/job-9287, 
 cmd: AttachCommand) (logid:6372e940) Failed to attach volume: Failed to add 
 disk scsi0:7. 
 java.lang.RuntimeException: Failed to add disk scsi0:7. 
 at 
 com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:336)
  
 at 
 com.cloud.hypervisor.vmware.mo.VirtualMachineMO.attachDisk(VirtualMachineMO.java:1206)
 {noformat}



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

[jira] [Commented] (CLOUDSTACK-8610) [VMWARE] Unable to attach 7th Disk to a Windows server 2012R2 instance


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712846#comment-14712846
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8610:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/554#issuecomment-134925991
  
LGTM, merging. Someone needs to add the unit test, later. I'm trying to 
build my skills around vmware related codebase.


 [VMWARE] Unable to attach 7th Disk to a Windows server 2012R2 instance
 --

 Key: CLOUDSTACK-8610
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8610
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Likitha Shetty
Assignee: Suresh Kumar Anaparti
 Fix For: 4.6.0


 +Steps to reproduce+
 1. Set global config vmware.root.disk.controller to 'osdefault'.
 2. Deploy a VM and attach 6 disks to the VM.
 3. Try to attach a 7th disk to the VM.
 Step 3 will fail with the below error
 {noformat}
 2015-06-22 11:03:22,673 ERROR [c.c.s.r.VmwareStorageProcessor] 
 (DirectAgent-636:ctx-8e72c2d9 s1p-z1-esxic-001.es.local, job-9286/job-9287, 
 cmd: AttachCommand) (logid:6372e940) Failed to attach volume: Failed to add 
 disk scsi0:7. 
 java.lang.RuntimeException: Failed to add disk scsi0:7. 
 at 
 com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:336)
  
 at 
 com.cloud.hypervisor.vmware.mo.VirtualMachineMO.attachDisk(VirtualMachineMO.java:1206)
 {noformat}



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

[jira] [Commented] (CLOUDSTACK-8602) MigrateVirtualMachineWithVolume leaves old chain data for volume


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712847#comment-14712847
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8602:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/548#issuecomment-134926126
  
LGTM


 MigrateVirtualMachineWithVolume leaves old chain data for volume
 

 Key: CLOUDSTACK-8602
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8602
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Likitha Shetty
Assignee: Suresh Kumar Anaparti
 Fix For: 4.6.0


 CS maintains chain info of every volume in DB, where chain info is the 
 complete volume path. When the volumes associated with a VM are migrated to 
 different storage pool, their chain info changes, but this information is not 
 reflected in the DB.



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

[jira] [Commented] (CLOUDSTACK-8761) Management server heartbeat takes too long to finish


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712884#comment-14712884
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8761:


Github user ustcweizhou commented on the pull request:

https://github.com/apache/cloudstack/pull/730#issuecomment-134934361
  
@remibergsma @karuturi @miguelaferreira 
The 730.json is empty. I finally find the repoName (folder name) should be 
cloudstack. In my env, it it not. I will change it. Thanks for you help!




 Management server heartbeat takes too long to finish
 

 Key: CLOUDSTACK-8761
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8761
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Wei Zhou
Assignee: Wei Zhou

 We got a lot of debug message in management-server.log every 1.5 seconds.
 The cluster.heartbeat.interval is set to 1500 by default. As it was not 
 changed after its first commit, so I think it is 1500 ms.
 However, The durations are less than 10ms actually.
 2015-08-18 00:00:04,526 DEBUG [c.c.c.ClusterManagerImpl] 
 (Cluster-Heartbeat-1:ctx-047bb88f) Management server heartbeat takes too long 
 to finish. profiler: Done. Duration: 4ms, profilerHeartbeatUpdate: Done. 
 Duration: 3ms, profilerPeerScan: Done. Duration: 0ms
 2015-08-18 00:00:06,036 DEBUG [c.c.c.ClusterManagerImpl] 
 (Cluster-Heartbeat-1:ctx-68018e26) Peer scan takes too long to finish. 
 profiler: Done. Duration: 0ms, profilerQueryActiveList: Done. Duration: 0ms, 
 profilerSyncClusterInfo: Done. Duration: 0ms, profilerInvalidatedNodeList: 
 Done. Duration: 0ms, profilerRemovedList: Done. Duration: 0ms



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

[jira] [Commented] (CLOUDSTACK-8761) Management server heartbeat takes too long to finish

2015-08-26 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712885#comment-14712885
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8761:


Github user miguelaferreira commented on the pull request:

https://github.com/apache/cloudstack/pull/730#issuecomment-134934893
  
@ustcweizhou good catch!

The idea of that script was to be a simple collection of git commands and 
assumed that people already understood git. But then we iterated many times 
over it, adding more and more logic to make it easier to use. The issue you 
just bumped into is the downside: the script became to tied up in small details!

We should fix this structurally in the script.


 Management server heartbeat takes too long to finish
 

 Key: CLOUDSTACK-8761
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8761
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Wei Zhou
Assignee: Wei Zhou

 We got a lot of debug message in management-server.log every 1.5 seconds.
 The cluster.heartbeat.interval is set to 1500 by default. As it was not 
 changed after its first commit, so I think it is 1500 ms.
 However, The durations are less than 10ms actually.
 2015-08-18 00:00:04,526 DEBUG [c.c.c.ClusterManagerImpl] 
 (Cluster-Heartbeat-1:ctx-047bb88f) Management server heartbeat takes too long 
 to finish. profiler: Done. Duration: 4ms, profilerHeartbeatUpdate: Done. 
 Duration: 3ms, profilerPeerScan: Done. Duration: 0ms
 2015-08-18 00:00:06,036 DEBUG [c.c.c.ClusterManagerImpl] 
 (Cluster-Heartbeat-1:ctx-68018e26) Peer scan takes too long to finish. 
 profiler: Done. Duration: 0ms, profilerQueryActiveList: Done. Duration: 0ms, 
 profilerSyncClusterInfo: Done. Duration: 0ms, profilerInvalidatedNodeList: 
 Done. Duration: 0ms, profilerRemovedList: Done. Duration: 0ms



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

[jira] [Commented] (CLOUDSTACK-8773) NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the same time


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712897#comment-14712897
 ] 

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

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

CLOUDSTACK-8773 : NPE in CheckRouterTask, when a DomainRouter happens to be 
expunged at the same time


 NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the 
 same time
 ---

 Key: CLOUDSTACK-8773
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8773
 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
Reporter: Nick Livens
Assignee: Nick Livens
Priority: Minor

 During restart network of a tier with public LB, following exception occurred:
 {noformat:title=exception in management-server.log}
 2015-07-24 02:09:06,086 DEBUG [c.c.a.t.Request] (Job-Executor-44:ctx-7e4a9dc8 
 ctx-f882738e) Seq 1-59048436: Received:  { Ans: , MgmtId: 275619427002880, 
 via: 1, Ver: v1, Flags: 10, { Answer } }
 2015-07-24 02:09:06,166 INFO  [o.a.c.s.v.VolumeServiceImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Volume 11 is not referred 
 anywhere, remove it from volumes table
 2015-07-24 02:09:06,263 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Expunged 
 VM[VpcInlineLoadBalancerVm|b-8-VM]
 2015-07-24 02:09:06,391 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Found 2 routers to update status.
 2015-07-24 02:09:06,393 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Fail to complete the CheckRouterTask!
 java.lang.NullPointerException
 at 
 com.cloud.network.vpn.Site2SiteVpnManagerImpl.getConnectionsForRouter(Site2SiteVpnManagerImpl.java:732)
 at sun.reflect.GeneratedMethodAccessor268.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 
 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.$Proxy206.getConnectionsForRouter(Unknown 
 Source)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.updateSite2SiteVpnConnectionState(VirtualNetworkApplianceManagerImpl.java:1044)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl$CheckRouterTask.runInContext(VirtualNetworkApplianceManagerImpl.java:1348)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at 
 java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at

[jira] [Commented] (CLOUDSTACK-8761) Management server heartbeat takes too long to finish


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712663#comment-14712663
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8761:


Github user ustcweizhou commented on the pull request:

https://github.com/apache/cloudstack/pull/730#issuecomment-134882707
  
@karuturi Sure, I tried before the merge, but got the following message:

[root@git (master)]# git pr 730
/root/git/master/tools/git/730.json
ERROR: We couldn't grab the PR author. Something went wrong querying the 
GitHub API.



 Management server heartbeat takes too long to finish
 

 Key: CLOUDSTACK-8761
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8761
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Wei Zhou
Assignee: Wei Zhou

 We got a lot of debug message in management-server.log every 1.5 seconds.
 The cluster.heartbeat.interval is set to 1500 by default. As it was not 
 changed after its first commit, so I think it is 1500 ms.
 However, The durations are less than 10ms actually.
 2015-08-18 00:00:04,526 DEBUG [c.c.c.ClusterManagerImpl] 
 (Cluster-Heartbeat-1:ctx-047bb88f) Management server heartbeat takes too long 
 to finish. profiler: Done. Duration: 4ms, profilerHeartbeatUpdate: Done. 
 Duration: 3ms, profilerPeerScan: Done. Duration: 0ms
 2015-08-18 00:00:06,036 DEBUG [c.c.c.ClusterManagerImpl] 
 (Cluster-Heartbeat-1:ctx-68018e26) Peer scan takes too long to finish. 
 profiler: Done. Duration: 0ms, profilerQueryActiveList: Done. Duration: 0ms, 
 profilerSyncClusterInfo: Done. Duration: 0ms, profilerInvalidatedNodeList: 
 Done. Duration: 0ms, profilerRemovedList: Done. Duration: 0ms



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

[jira] [Commented] (CLOUDSTACK-8754) VM migration triggered by dynamic scaling is failing

[
https://issues.apache.org/jira/browse/CLOUDSTACK-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712735#comment-14712735
]

ASF GitHub Bot commented on CLOUDSTACK-8754:

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/725#issuecomment-134902453

FWIW, this LGTM; @koushik-das please send a different PR in future if you
decide to add tests and do further enhancements.

Travis is green, merging now.

VM migration triggered by dynamic scaling is failing

Key: CLOUDSTACK-8754
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8754
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.5.0, 4.6.0
Reporter: Koushik Das
Assignee: Koushik Das
Fix For: 4.6.0

Steps to reproduce
1. Create a cluster with two hosts, disable one. Since dynamic scaling is
supported by XS and Vmware use one of them.
2. Create 2 service offerings (say 'small' and 'big')
3. Exhaust CPU capacity of the enabled host by deploying VMs with SO 'small'.
4. Try scaling up one of the VMs to SO 'big', and make sure it is failing
with insufficient capacity.
5. Enable the other host in cluster. Make sure this has enough CPU capacity
to accommodate the VM with SO 'big'.
6. Now repeat step 4.
Expected

Since there is no cpu resource left on host, vm should scale up after live
migration to another host
Actual

VM scale up failed due to Received exception while scaling
com.cloud.utils.exception.CloudRuntimeException: Unable to serialize:
com.cloud.vm.VmWorkMigrateForScale@65700a07

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

[jira] [Commented] (CLOUDSTACK-8754) VM migration triggered by dynamic scaling is failing

2015-08-26 Thread ASF subversion and git services (JIRA)

[
https://issues.apache.org/jira/browse/CLOUDSTACK-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712741#comment-14712741
]

ASF GitHub Bot commented on CLOUDSTACK-8754:

Github user asfgit closed the pull request at:

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

VM migration triggered by dynamic scaling is failing

Since there is no cpu resource left on host, vm should scale up after live
migration to another host
Actual

VM scale up failed due to Received exception while scaling
com.cloud.utils.exception.CloudRuntimeException: Unable to serialize:
com.cloud.vm.VmWorkMigrateForScale@65700a07

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

[jira] [Commented] (CLOUDSTACK-8754) VM migration triggered by dynamic scaling is failing

[
https://issues.apache.org/jira/browse/CLOUDSTACK-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712737#comment-14712737
]

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

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

CLOUDSTACK-8754: VM migration triggered by dynamic scaling is failing
This is caused by serialization failure for VmWorkMigrateForScale object.
Replaced DeployDestination member
present in VmWorkMigrateForScale with serializable types.

VM migration triggered by dynamic scaling is failing

Since there is no cpu resource left on host, vm should scale up after live
migration to another host
Actual

VM scale up failed due to Received exception while scaling
com.cloud.utils.exception.CloudRuntimeException: Unable to serialize:
com.cloud.vm.VmWorkMigrateForScale@65700a07

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

[jira] [Commented] (CLOUDSTACK-8755) xs-tools.iso missing from ISOs GUI


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712781#comment-14712781
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8755:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/727#issuecomment-134913294
  
LGTM


  xs-tools.iso missing from ISOs  GUI
 

 Key: CLOUDSTACK-8755
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8755
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.5.0
Reporter: prashant kumar mishra
Assignee: shweta agarwal
 Fix For: 4.5.1






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

[jira] [Commented] (CLOUDSTACK-8756) Incorrect guest os mapping for CentOS 5.9


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712779#comment-14712779
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8756:


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

https://github.com/apache/cloudstack/pull/728#discussion_r37961562
  
--- Diff: tools/marvin/marvin/config/test_data.py ---
@@ -775,6 +775,15 @@
 ostype: CentOS 5.6 (64-bit)
 
 },
+CentOS6.3template: {
+displaytext: Centos,
+name: Centos,
+passwordenabled: False,
+ostype: CentOS 6.3 (64-bit),
+url: http://10.147.28.7/templates/centos63.ova;,
--- End diff --

Can you share or host this ova publicly? Will this test fail for this 
URL/file not available in one's env.


 Incorrect guest os mapping  for CentOS 5.9
 --

 Key: CLOUDSTACK-8756
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8756
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.5.1
Reporter: prashant kumar mishra
Assignee: shweta agarwal
 Fix For: 4.5.1


 1) Create VM from ISO of CentOS5.9 on VMware
 2) Try to attach VMwaretools from CCP and failed.
 3) Try to attach VMwaretools from ESXi and also failed.
 4) When checked VM EditSettingOptionsGeneralOptions in ESXi, Version is 
 Other (64-bit).
 5) In CCP UI, the version for this VM is CentOS5.9(32bit) which is correct.



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

[jira] [Commented] (CLOUDSTACK-8723) Verify API call listUsageRecords returns usage of new volume created after restore VM


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712815#comment-14712815
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8723:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/675#issuecomment-134919453
  
LGTM


 Verify API call listUsageRecords returns usage of new volume created after 
 restore VM
 ---

 Key: CLOUDSTACK-8723
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8723
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.2.1
Reporter: Priti Sarap
 Fix For: 4.2.1


 After restoring a running VM current ROOT disk gets destroyed and new ROOT 
 disk gets created.
 This testcase is to check if volume usage of this newly created volume is 
 listed in listUsageRecords API.



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

[jira] [Commented] (CLOUDSTACK-8728) Testcase to Verify if VRs IP changes if it is destroyed and re-created in Basic Zone


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712813#comment-14712813
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8728:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/684#issuecomment-134919215
  
LGTM


 Testcase to Verify if VRs IP changes if it is destroyed and re-created in 
 Basic Zone
 

 Key: CLOUDSTACK-8728
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8728
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.2.1
Reporter: Priti Sarap
 Fix For: 4.2.1






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

[jira] [Commented] (CLOUDSTACK-8727) API call listVirtualMachines returns same keypair


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712811#comment-14712811
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8727:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/685#issuecomment-134919051
  
Can you add some tests, we'll need to test it before merging. @DaanHoogland 
have you looked at it, since you had recently made some related changes or 
might have experience in the codebase around that?

In general, LGTM. We definitely merge after you had added some tests.


 API call listVirtualMachines returns same keypair
 -

 Key: CLOUDSTACK-8727
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8727
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Kshitij Kansal

 If you register 2 SSH keypairs with the same public key then 
 listVirtualMachines API call will only return the first keypair. Although its 
 a very rare case and generally don't make much sense by registering the same 
 key with different name, still it can be fixed. 



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

[jira] [Commented] (CLOUDSTACK-8721) Setting details of VM through API results in removal of all other details except the one passed in API


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712853#comment-14712853
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8721:


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

https://github.com/apache/cloudstack/pull/673#discussion_r37964142
  
--- Diff: 
api/src/org/apache/cloudstack/api/command/user/vm/UpdateVMCmd.java ---
@@ -136,13 +136,13 @@ public String getInstanceName() {
 return instanceName;
 }
 
-public Map getDetails() {
+public MapString, String getDetails() {
--- End diff --

This is to avoid long nested type casting before using details.


 Setting details of VM through API results in removal of all other details 
 except the one passed in API
 --

 Key: CLOUDSTACK-8721
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8721
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Anshul Gangwar
Assignee: Anshul Gangwar

 Setting details of VM through API results in removal of all other details 
 except the one passed in API. We are storing vm details which are not set by 
 user and in this process of setting details all details are getting lost 
 which could lead to other issues.



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

[jira] [Commented] (CLOUDSTACK-8721) Setting details of VM through API results in removal of all other details except the one passed in API


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712855#comment-14712855
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8721:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/673#issuecomment-134929360
  
@anshul1886 can you read and reply to some of the comments?


 Setting details of VM through API results in removal of all other details 
 except the one passed in API
 --

 Key: CLOUDSTACK-8721
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8721
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Anshul Gangwar
Assignee: Anshul Gangwar

 Setting details of VM through API results in removal of all other details 
 except the one passed in API. We are storing vm details which are not set by 
 user and in this process of setting details all details are getting lost 
 which could lead to other issues.



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

[jira] [Commented] (CLOUDSTACK-8721) Setting details of VM through API results in removal of all other details except the one passed in API

2015-08-26 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712872#comment-14712872
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8721:


Github user anshul1886 commented on the pull request:

https://github.com/apache/cloudstack/pull/673#issuecomment-134931329
  
@bhaisaab Lost in discussion and got only end result that all we need is 
here.


 Setting details of VM through API results in removal of all other details 
 except the one passed in API
 --

 Key: CLOUDSTACK-8721
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8721
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Anshul Gangwar
Assignee: Anshul Gangwar

 Setting details of VM through API results in removal of all other details 
 except the one passed in API. We are storing vm details which are not set by 
 user and in this process of setting details all details are getting lost 
 which could lead to other issues.



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

[jira] [Commented] (CLOUDSTACK-8732) Unable to resize RBD volume: Cannot determine resize type from pool type RBD


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712906#comment-14712906
 ] 

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

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

Merge pull request #696 from iwebhosting/rbd-live-resize

Default to notify only script to handle non-CLVM/QCOW cases.This relates to 
[CLOUDSTACK-8732](https://issues.apache.org/jira/browse/CLOUDSTACK-8732)

Before this commit the call to `getResizeScriptType` would throw an exception 
(earlier versions returned `null`, which was fine) - this caused the RBD case 
to fail. By changing the default to notify only we fix the case for any 
non-CLVM and non-QCOW cases, too.

This is RBD for now, but this should extend to new storage types supported by 
Libvirt natively in future.

This is my first attempted contribution: I can see a case for adding RBD logic 
to the actual getResizeScriptType call, too, but I felt that putting it 
`LibvirtResizeVolumeCommandWrapper.java` kept the special-casing of RBD (and 
comments about that) in one place.

### Caveat:

With Libvirt 1.2.2 this actually doesn't do the right thing - but it does do 
what the documentation *says* should be the right thing, so I'm going to test 
if this is a Libvirt bug which is fixed in a later version.

(To make it work I need to execute something like:

virsh blockresize --path vda --size 100G i-7-44-VM

where vda is the path as far as the *guest* is concerned, and not an `rbd/` 
path - which *should* work, but doesn't.)

* pr/696:
  Default to notify only script to handle non-CLVM/QCOW cases.

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com


 Unable to resize RBD volume: Cannot determine resize type from pool type RBD
 --

 Key: CLOUDSTACK-8732
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8732
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.5.1
 Environment: Ubuntu 14.04, libvirt 1.2.2, qemu 2.0.0, ceph 0.94.2, 
 Cloudstack 4.5.1, Kernel 3.16.0, KVM hypervisor
Reporter: Darren Worrall

 First time reporter, so apologies early on if I've gotten anything wrong here.
 While trying to resize a RBD backed volume in our 4.5.1 installation (using 
 the {{resizeVolume}} api call), the job fails with the error above. A [pull 
 request|https://github.com/apache/cloudstack/pull/281] was merged in this 
 space but it seems incomplete - you can see that {{getResizeScriptType}} in 
 the source branch [returns 
 null|https://github.com/remibergsma/cloudstack/blob/a26bbc2ce2f99e706895f9c0bbc6bdb5a522c37f/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java#L1824],
  but currently in master the above exception [is 
 thrown|https://github.com/apache/cloudstack/blob/792c27c9bd97bc703ceb28fa8db24db7d0d46012/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java#L1428]
 You can see a management server log snippet 
 [here|https://gist.githubusercontent.com/DazWorrall/3bfcb153dea8b137f38b/raw/1f41096b247221e26b5407ae777f5fe278614d54/management-server.log],
  compete with traces.
 This was discussed on the [mailing 
 list|http://mail-archives.us.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3ccamvtbpou4tkan2kzknzpl0scu3y032ghu3av2qzgtsfas3t...@mail.gmail.com%3E]
  but I cant see if anything came of it. I can confirm the findings there 
 though - going underneath Cloudstack and dealing with libvirt directly works 
 fine, I can live resize root and data volumes without issue.



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

[jira] [Commented] (CLOUDSTACK-8732) Unable to resize RBD volume: Cannot determine resize type from pool type RBD

2015-08-26 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712905#comment-14712905
 ] 

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

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

Merge pull request #696 from iwebhosting/rbd-live-resize

Default to notify only script to handle non-CLVM/QCOW cases.This relates to 
[CLOUDSTACK-8732](https://issues.apache.org/jira/browse/CLOUDSTACK-8732)

Before this commit the call to `getResizeScriptType` would throw an exception 
(earlier versions returned `null`, which was fine) - this caused the RBD case 
to fail. By changing the default to notify only we fix the case for any 
non-CLVM and non-QCOW cases, too.

This is RBD for now, but this should extend to new storage types supported by 
Libvirt natively in future.

This is my first attempted contribution: I can see a case for adding RBD logic 
to the actual getResizeScriptType call, too, but I felt that putting it 
`LibvirtResizeVolumeCommandWrapper.java` kept the special-casing of RBD (and 
comments about that) in one place.

### Caveat:

With Libvirt 1.2.2 this actually doesn't do the right thing - but it does do 
what the documentation *says* should be the right thing, so I'm going to test 
if this is a Libvirt bug which is fixed in a later version.

(To make it work I need to execute something like:

virsh blockresize --path vda --size 100G i-7-44-VM

where vda is the path as far as the *guest* is concerned, and not an `rbd/` 
path - which *should* work, but doesn't.)

* pr/696:
  Default to notify only script to handle non-CLVM/QCOW cases.

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com


 Unable to resize RBD volume: Cannot determine resize type from pool type RBD
 --

 Key: CLOUDSTACK-8732
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8732
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.5.1
 Environment: Ubuntu 14.04, libvirt 1.2.2, qemu 2.0.0, ceph 0.94.2, 
 Cloudstack 4.5.1, Kernel 3.16.0, KVM hypervisor
Reporter: Darren Worrall

 First time reporter, so apologies early on if I've gotten anything wrong here.
 While trying to resize a RBD backed volume in our 4.5.1 installation (using 
 the {{resizeVolume}} api call), the job fails with the error above. A [pull 
 request|https://github.com/apache/cloudstack/pull/281] was merged in this 
 space but it seems incomplete - you can see that {{getResizeScriptType}} in 
 the source branch [returns 
 null|https://github.com/remibergsma/cloudstack/blob/a26bbc2ce2f99e706895f9c0bbc6bdb5a522c37f/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java#L1824],
  but currently in master the above exception [is 
 thrown|https://github.com/apache/cloudstack/blob/792c27c9bd97bc703ceb28fa8db24db7d0d46012/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java#L1428]
 You can see a management server log snippet 
 [here|https://gist.githubusercontent.com/DazWorrall/3bfcb153dea8b137f38b/raw/1f41096b247221e26b5407ae777f5fe278614d54/management-server.log],
  compete with traces.
 This was discussed on the [mailing 
 list|http://mail-archives.us.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3ccamvtbpou4tkan2kzknzpl0scu3y032ghu3av2qzgtsfas3t...@mail.gmail.com%3E]
  but I cant see if anything came of it. I can confirm the findings there 
 though - going underneath Cloudstack and dealing with libvirt directly works 
 fine, I can live resize root and data volumes without issue.



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

[jira] [Commented] (CLOUDSTACK-8732) Unable to resize RBD volume: Cannot determine resize type from pool type RBD


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712907#comment-14712907
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8732:


Github user asfgit closed the pull request at:

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


 Unable to resize RBD volume: Cannot determine resize type from pool type RBD
 --

 Key: CLOUDSTACK-8732
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8732
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.5.1
 Environment: Ubuntu 14.04, libvirt 1.2.2, qemu 2.0.0, ceph 0.94.2, 
 Cloudstack 4.5.1, Kernel 3.16.0, KVM hypervisor
Reporter: Darren Worrall

 First time reporter, so apologies early on if I've gotten anything wrong here.
 While trying to resize a RBD backed volume in our 4.5.1 installation (using 
 the {{resizeVolume}} api call), the job fails with the error above. A [pull 
 request|https://github.com/apache/cloudstack/pull/281] was merged in this 
 space but it seems incomplete - you can see that {{getResizeScriptType}} in 
 the source branch [returns 
 null|https://github.com/remibergsma/cloudstack/blob/a26bbc2ce2f99e706895f9c0bbc6bdb5a522c37f/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java#L1824],
  but currently in master the above exception [is 
 thrown|https://github.com/apache/cloudstack/blob/792c27c9bd97bc703ceb28fa8db24db7d0d46012/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java#L1428]
 You can see a management server log snippet 
 [here|https://gist.githubusercontent.com/DazWorrall/3bfcb153dea8b137f38b/raw/1f41096b247221e26b5407ae777f5fe278614d54/management-server.log],
  compete with traces.
 This was discussed on the [mailing 
 list|http://mail-archives.us.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3ccamvtbpou4tkan2kzknzpl0scu3y032ghu3av2qzgtsfas3t...@mail.gmail.com%3E]
  but I cant see if anything came of it. I can confirm the findings there 
 though - going underneath Cloudstack and dealing with libvirt directly works 
 fine, I can live resize root and data volumes without issue.



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

[jira] [Commented] (CLOUDSTACK-8749) KVM: link local route cleanup

2015-08-26 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712670#comment-14712670
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8749:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/735#issuecomment-134890826
  
renamed the method, 
s/deleteExitingLinkLocalRouteTable/deleteExistingLinkLocalRouteTable/g


 KVM: link local route cleanup
 -

 Key: CLOUDSTACK-8749
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8749
 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: 4.5.3, 4.6.0


 The KVM agent attempts to delete link local interfaces whenever found, so 
 they don't conflict with the system vm's link local route on cloud0, however 
 it doesn't specify which device to delete the route for.
 The aim is to fix the edge case which (unlikely) can try to delete existing 
 cloud0 routes/interface.



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

[jira] [Created] (CLOUDSTACK-8775) [HyperV]NPE while attaching Local storage volume to instance whose root volume is on ZWPS.

2015-08-26 Thread Deepthi Machiraju (JIRA)

Deepthi Machiraju created CLOUDSTACK-8775:
-

 Summary: [HyperV]NPE while attaching Local storage volume to 
instance whose root volume is on ZWPS.
 Key: CLOUDSTACK-8775
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8775
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.6.0
Reporter: Deepthi Machiraju
Priority: Critical
 Fix For: 4.6.0


- Create a custom disk offering which has the tag of Localstorage.
- Navigate to Storage and Click on Upload and select the above disk offering 
with the file URL.
- After the upload is complete , try attaching the to the instance whose root 
volume resides on zone wide primary storage.

Expected Result : 
- Attach should be sucessful

Observation :
Attach is failing with NPE and below is the trace.
Note : When the root volume is on CLuster storage , volume attch of local 
storage is sucessful.

2015-08-26 08:07:59,045 DEBUG [o.a.c.s.a.ZoneWideStoragePoolAllocator] 
(Work-Job-Executor-69:ctx-754f463c job-182/job-183 ctx-20cae27f) 
ZoneWideStoragePoolAllocator to find storage pool
2015-08-26 08:07:59,045 ERROR [c.c.v.VmWorkJobHandlerProxy] 
(Work-Job-Executor-69:ctx-754f463c job-182/job-183 ctx-20cae27f) Invocation 
exception, caused by: java.lang.NullPointerException
2015-08-26 08:07:59,045 INFO  [c.c.v.VmWorkJobHandlerProxy] 
(Work-Job-Executor-69:ctx-754f463c job-182/job-183 ctx-20cae27f) Rethrow 
exception java.lang.NullPointerException
2015-08-26 08:07:59,045 DEBUG [c.c.v.VmWorkJobDispatcher] 
(Work-Job-Executor-69:ctx-754f463c job-182/job-183) Done with run of VM work 
job: com.cloud.vm.VmWorkAttachVolume for VM 3, job origin: 182
2015-08-26 08:07:59,045 ERROR [c.c.v.VmWorkJobDispatcher] 
(Work-Job-Executor-69:ctx-754f463c job-182/job-183) Unable to complete 
AsyncJobVO {id:183, userId: 2, accountId: 2, instanceType: null, instanceId: 
null, cmd: com.cloud.vm.VmWorkAttachVolume, cmdInfo: 
rO0ABXNyAB9jb20uY2xvdWQudm0uVm1Xb3JrQXR0YWNoVm9sdW1lB62v-WGH4hwCAAJMAAhkZXZpY2VJZHQAEExqYXZhL2xhbmcvTG9uZztMAAh2b2x1bWVJZHEAfgABeHIAE2NvbS5jbG91ZC52bS5WbVdvcmufmbZW8CVnawIABEoACWFjY291bnRJZEoABnVzZXJJZEoABHZtSWRMAAtoYW5kbGVyTmFtZXQAEkxqYXZhL2xhbmcvU3RyaW5nO3hwAAIAAgADdAAUVm9sdW1lQXBpU2VydmljZUltcGxwc3IADmphdmEubGFuZy5Mb25nO4vkkMyPI98CAAFKAAV2YWx1ZXhyABBqYXZhLmxhbmcuTnVtYmVyhqyVHQuU4IsCAAB4cAAp,
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 227345751881375, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: Wed Aug 26 08:07:57 UTC 2015}, job origin:182
java.lang.NullPointerException
at 
org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.copyVolumeFromSecToPrimary(VolumeOrchestrator.java:463)
at 
org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.copyVolume(VolumeOrchestrator.java:776)
at 
org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.createVolumeOnPrimaryStorage(VolumeOrchestrator.java:796)
at 
com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:1321)
at 
com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:2837)
at sun.reflect.GeneratedMethodAccessor379.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at 
com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2876)
at sun.reflect.GeneratedMethodAccessor314.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy195.handleVmWorkJob(Unknown Source)
at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
at

[jira] [Commented] (CLOUDSTACK-8754) VM migration triggered by dynamic scaling is failing

[
https://issues.apache.org/jira/browse/CLOUDSTACK-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712738#comment-14712738
]

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

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

Merge pull request #725 from koushik-das/CLOUDSTACK-8754

CLOUDSTACK-8754: VM migration triggered by dynamic scaling is failingThis is
caused by serialization failure for VmWorkMigrateForScale object. Replaced
DeployDestination member present in VmWorkMigrateForScale with serializable
types.

Haven't added any unit test as couldn't find a clean way to do it. Simply
adding a test to do (de)serialization won't help catch any new member addition
to the type which breaks serializability.

* pr/725:
CLOUDSTACK-8754: VM migration triggered by dynamic scaling is failing This is
caused by serialization failure for VmWorkMigrateForScale object. Replaced
DeployDestination member present in VmWorkMigrateForScale with serializable
types.

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com

VM migration triggered by dynamic scaling is failing

Since there is no cpu resource left on host, vm should scale up after live
migration to another host
Actual

VM scale up failed due to Received exception while scaling
com.cloud.utils.exception.CloudRuntimeException: Unable to serialize:
com.cloud.vm.VmWorkMigrateForScale@65700a07

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

[jira] [Commented] (CLOUDSTACK-8754) VM migration triggered by dynamic scaling is failing

2015-08-26 Thread ASF subversion and git services (JIRA)

[
https://issues.apache.org/jira/browse/CLOUDSTACK-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712739#comment-14712739
]

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

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

Merge pull request #725 from koushik-das/CLOUDSTACK-8754

CLOUDSTACK-8754: VM migration triggered by dynamic scaling is failingThis is
caused by serialization failure for VmWorkMigrateForScale object. Replaced
DeployDestination member present in VmWorkMigrateForScale with serializable
types.

Haven't added any unit test as couldn't find a clean way to do it. Simply
adding a test to do (de)serialization won't help catch any new member addition
to the type which breaks serializability.

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com

VM migration triggered by dynamic scaling is failing

Since there is no cpu resource left on host, vm should scale up after live
migration to another host
Actual

VM scale up failed due to Received exception while scaling
com.cloud.utils.exception.CloudRuntimeException: Unable to serialize:
com.cloud.vm.VmWorkMigrateForScale@65700a07

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

[jira] [Commented] (CLOUDSTACK-8754) VM migration triggered by dynamic scaling is failing

2015-08-26 Thread ASF subversion and git services (JIRA)

[
https://issues.apache.org/jira/browse/CLOUDSTACK-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712740#comment-14712740
]

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

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

Merge pull request #725 from koushik-das/CLOUDSTACK-8754

CLOUDSTACK-8754: VM migration triggered by dynamic scaling is failingThis is
caused by serialization failure for VmWorkMigrateForScale object. Replaced
DeployDestination member present in VmWorkMigrateForScale with serializable
types.

Haven't added any unit test as couldn't find a clean way to do it. Simply
adding a test to do (de)serialization won't help catch any new member addition
to the type which breaks serializability.

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com

VM migration triggered by dynamic scaling is failing

Since there is no cpu resource left on host, vm should scale up after live
migration to another host
Actual

VM scale up failed due to Received exception while scaling
com.cloud.utils.exception.CloudRuntimeException: Unable to serialize:
com.cloud.vm.VmWorkMigrateForScale@65700a07

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

[jira] [Commented] (CLOUDSTACK-8773) NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the same time


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712757#comment-14712757
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8773:


Github user karuturi commented on the pull request:

https://github.com/apache/cloudstack/pull/745#issuecomment-134906322
  
A unittest to verify this case would be nice. 


 NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the 
 same time
 ---

 Key: CLOUDSTACK-8773
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8773
 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
Reporter: Nick Livens
Assignee: Nick Livens
Priority: Minor

 During restart network of a tier with public LB, following exception occurred:
 {noformat:title=exception in management-server.log}
 2015-07-24 02:09:06,086 DEBUG [c.c.a.t.Request] (Job-Executor-44:ctx-7e4a9dc8 
 ctx-f882738e) Seq 1-59048436: Received:  { Ans: , MgmtId: 275619427002880, 
 via: 1, Ver: v1, Flags: 10, { Answer } }
 2015-07-24 02:09:06,166 INFO  [o.a.c.s.v.VolumeServiceImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Volume 11 is not referred 
 anywhere, remove it from volumes table
 2015-07-24 02:09:06,263 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Expunged 
 VM[VpcInlineLoadBalancerVm|b-8-VM]
 2015-07-24 02:09:06,391 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Found 2 routers to update status.
 2015-07-24 02:09:06,393 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Fail to complete the CheckRouterTask!
 java.lang.NullPointerException
 at 
 com.cloud.network.vpn.Site2SiteVpnManagerImpl.getConnectionsForRouter(Site2SiteVpnManagerImpl.java:732)
 at sun.reflect.GeneratedMethodAccessor268.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 
 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.$Proxy206.getConnectionsForRouter(Unknown 
 Source)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.updateSite2SiteVpnConnectionState(VirtualNetworkApplianceManagerImpl.java:1044)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl$CheckRouterTask.runInContext(VirtualNetworkApplianceManagerImpl.java:1348)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at 
 java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)
 2015-07-24 02:09:06,580 DEBUG

[jira] [Commented] (CLOUDSTACK-8757) Test to verify if FTP modules are loaded in VR


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712774#comment-14712774
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8757:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/729#issuecomment-134912770
  
Code LGTM (not tested on a real infra though), merging.


 Test to verify if FTP modules are loaded in VR
 --

 Key: CLOUDSTACK-8757
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8757
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.5.1
Reporter: prashant kumar mishra
Assignee: shweta agarwal
 Fix For: 4.5.3






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

[jira] [Commented] (CLOUDSTACK-8756) Incorrect guest os mapping for CentOS 5.9

2015-08-26 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712808#comment-14712808
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8756:


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

https://github.com/apache/cloudstack/pull/728#discussion_r37962558
  
--- Diff: tools/marvin/marvin/config/test_data.py ---
@@ -775,6 +775,15 @@
 ostype: CentOS 5.6 (64-bit)
 
 },
+CentOS6.3template: {
+displaytext: Centos,
+name: Centos,
+passwordenabled: False,
+ostype: CentOS 6.3 (64-bit),
+url: http://10.147.28.7/templates/centos63.ova;,
--- End diff --

Agree, and this should be parameterised IMHO.


 Incorrect guest os mapping  for CentOS 5.9
 --

 Key: CLOUDSTACK-8756
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8756
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.5.1
Reporter: prashant kumar mishra
Assignee: shweta agarwal
 Fix For: 4.5.1


 1) Create VM from ISO of CentOS5.9 on VMware
 2) Try to attach VMwaretools from CCP and failed.
 3) Try to attach VMwaretools from ESXi and also failed.
 4) When checked VM EditSettingOptionsGeneralOptions in ESXi, Version is 
 Other (64-bit).
 5) In CCP UI, the version for this VM is CentOS5.9(32bit) which is correct.



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

[jira] [Commented] (CLOUDSTACK-8765) vm migration failed due to different dev name on KVM


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712799#comment-14712799
 ] 

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

Commit bb8f7c652e42caacff5adce1ce60342603677605 in cloudstack's branch 
refs/heads/master from Wei Zhou
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bb8f7c6 ]

CLOUDSTACK-8765: fix vm migration failure due to different dev name on KVM


 vm migration failed due to different dev name on KVM
 

 Key: CLOUDSTACK-8765
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8765
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Wei Zhou
Assignee: Wei Zhou

 The devname of ethernet nics could be different.
 for example, the first nic name is eth0 in some linux OS, and em1 in other 
 linux OS, and bond0 if we use linux bonding.
 The vm can not be migrated between them due to different dev name.
 http://cloudstack.markmail.org/message/jacsml3wy5tmeerp
 http://cloudstack.markmail.org/message/ovmmt25vfqkowp2z
 the fix is:
 http://cloudstack.markmail.org/message/d4iocagbc6m25zxk



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

[jira] [Commented] (CLOUDSTACK-8765) vm migration failed due to different dev name on KVM

2015-08-26 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712802#comment-14712802
 ] 

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

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

Merge pull request #736 from ustcweizhou/CLOUDSTACK-8765

CLOUDSTACK-8765: fix vm migration failure due to different dev name on KVM

* pr/736:
  CLOUDSTACK-8765: fix vm migration failure due to different dev name on KVM

Signed-off-by: Remi Bergsma git...@remi.nl


 vm migration failed due to different dev name on KVM
 

 Key: CLOUDSTACK-8765
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8765
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Wei Zhou
Assignee: Wei Zhou

 The devname of ethernet nics could be different.
 for example, the first nic name is eth0 in some linux OS, and em1 in other 
 linux OS, and bond0 if we use linux bonding.
 The vm can not be migrated between them due to different dev name.
 http://cloudstack.markmail.org/message/jacsml3wy5tmeerp
 http://cloudstack.markmail.org/message/ovmmt25vfqkowp2z
 the fix is:
 http://cloudstack.markmail.org/message/d4iocagbc6m25zxk



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

[jira] [Commented] (CLOUDSTACK-8757) Test to verify if FTP modules are loaded in VR


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712803#comment-14712803
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8757:


Github user asfgit closed the pull request at:

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


 Test to verify if FTP modules are loaded in VR
 --

 Key: CLOUDSTACK-8757
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8757
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.5.1
Reporter: prashant kumar mishra
Assignee: shweta agarwal
 Fix For: 4.5.3






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

[jira] [Commented] (CLOUDSTACK-8731) automation:checking usage event generation for delete volume

2015-08-26 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712806#comment-14712806
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8731:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/691#issuecomment-134917634
  
LGTM. @cloudsadhu  are you improving it based on @ksowmya 's comment?


 automation:checking usage event generation for delete volume
 

 Key: CLOUDSTACK-8731
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8731
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: sadhu suresh
Assignee: sadhu suresh

 usage event not generated for delete volume  when VM creation failed . 



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

[jira] [Commented] (CLOUDSTACK-8765) vm migration failed due to different dev name on KVM


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712801#comment-14712801
 ] 

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

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

Merge pull request #736 from ustcweizhou/CLOUDSTACK-8765

CLOUDSTACK-8765: fix vm migration failure due to different dev name on KVM

* pr/736:
  CLOUDSTACK-8765: fix vm migration failure due to different dev name on KVM

Signed-off-by: Remi Bergsma git...@remi.nl


 vm migration failed due to different dev name on KVM
 

 Key: CLOUDSTACK-8765
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8765
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Wei Zhou
Assignee: Wei Zhou

 The devname of ethernet nics could be different.
 for example, the first nic name is eth0 in some linux OS, and em1 in other 
 linux OS, and bond0 if we use linux bonding.
 The vm can not be migrated between them due to different dev name.
 http://cloudstack.markmail.org/message/jacsml3wy5tmeerp
 http://cloudstack.markmail.org/message/ovmmt25vfqkowp2z
 the fix is:
 http://cloudstack.markmail.org/message/d4iocagbc6m25zxk



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

[jira] [Commented] (CLOUDSTACK-8765) vm migration failed due to different dev name on KVM


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712804#comment-14712804
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8765:


Github user asfgit closed the pull request at:

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


 vm migration failed due to different dev name on KVM
 

 Key: CLOUDSTACK-8765
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8765
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Wei Zhou
Assignee: Wei Zhou

 The devname of ethernet nics could be different.
 for example, the first nic name is eth0 in some linux OS, and em1 in other 
 linux OS, and bond0 if we use linux bonding.
 The vm can not be migrated between them due to different dev name.
 http://cloudstack.markmail.org/message/jacsml3wy5tmeerp
 http://cloudstack.markmail.org/message/ovmmt25vfqkowp2z
 the fix is:
 http://cloudstack.markmail.org/message/d4iocagbc6m25zxk



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

[jira] [Commented] (CLOUDSTACK-8605) KVM: Config Drive and getVmIp support


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712824#comment-14712824
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8605:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/577#issuecomment-134923025
  
LGTM.


 KVM: Config Drive and getVmIp support
 -

 Key: CLOUDSTACK-8605
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8605
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.6.0
Reporter: Kishan Kavala
Assignee: Kishan Kavala
 Fix For: 4.6.0


 Add support for 
 - creating config drive
 - Fetch IP from guest Vm which is assigned by external DHCP



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

[jira] [Commented] (CLOUDSTACK-5863) Restore volume snapshot


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712825#comment-14712825
 ] 

ASF GitHub Bot commented on CLOUDSTACK-5863:


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

https://github.com/apache/cloudstack/pull/732#discussion_r37963222
  
--- Diff: 
api/src/org/apache/cloudstack/api/command/user/snapshot/RevertSnapshotCmd.java 
---
@@ -31,25 +31,36 @@
 import org.apache.cloudstack.api.response.SnapshotResponse;
 import org.apache.cloudstack.api.response.SuccessResponse;
 import org.apache.cloudstack.context.CallContext;
+import org.apache.log4j.Logger;
 
 import com.cloud.event.EventTypes;
 import com.cloud.storage.Snapshot;
 import com.cloud.user.Account;
 
-@APICommand(name = revertSnapshot, description = revert a volume 
snapshot., responseObject = SnapshotResponse.class, entityType = 
{Snapshot.class},
+@APICommand(name = revertSnapshot, description = revert a volume 
snapshot., responseObject = SuccessResponse.class, entityType = 
{Snapshot.class},
--- End diff --

I will change it to SnapshotResponse for backward compatibility.


 Restore volume snapshot
 ---

 Key: CLOUDSTACK-5863
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5863
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Snapshot
 Environment: KVM, EL6, QCOW2
Reporter: Nux
Assignee: Wei Zhou
  Labels: backup, kvm, restore, snapshot, volumes
 Fix For: 4.6.0


 Hello,
 Just as users can create backups of volumes, they should be able to restore 
 said volumes from them.



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

[jira] [Commented] (CLOUDSTACK-8677) Call-home functionality for CloudStack


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712822#comment-14712822
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8677:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/625#issuecomment-134922676
  
@wido can you implement this as a plugin instead of core feature? Also do 
we want cloudstack to report statistics on each run; I suggest to have it as a 
plugin with a small db entry (global setting or a separate db) to track the 
last time+version we sent the payload/report and we can report that on each 
upgrade and perform checks every time cloudstack runs. This also needs to have 
a global lock in case of multiple mgmt servers.


 Call-home functionality for CloudStack
 --

 Key: CLOUDSTACK-8677
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8677
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: Future, 4.6.0
Reporter: Wido den Hollander
Assignee: Wido den Hollander
 Fix For: 4.6.0


 A call-home feature for the CloudStack management server would send 
 anonimized reports back to the CloudStack project.
 These statistics will contain numbers and details on how CloudStack will be 
 used. It will NOT contain:
 * Hostnames
 * IP-Addresses
 * Instance names
 It will report back:
 * Hosts (Number, version, type, hypervisor)
 * Clusters (Hypervisor en Management type)
 * Primary storage (Type and provider)
 * Zones (Network type and providers)
 * Instances (Number and types)
 This gives the CloudStack project a better insight on how CloudStack is being 
 used and allows us to develop accordingly.
 It will be OPT-OUT, using the usage.report.interval users can disable usage 
 reporting. By default it will run every 7 days and send a JSON document to 
 https://call-home.cloudstack.org/



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

[jira] [Commented] (CLOUDSTACK-8605) KVM: Config Drive and getVmIp support

2015-08-26 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712826#comment-14712826
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8605:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/577#issuecomment-134923368
  
maybe rebase and fix any issues, to get Travis green before merging this 
once @wido can review this.


 KVM: Config Drive and getVmIp support
 -

 Key: CLOUDSTACK-8605
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8605
 Project: CloudStack
  Issue Type: Sub-task
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.6.0
Reporter: Kishan Kavala
Assignee: Kishan Kavala
 Fix For: 4.6.0


 Add support for 
 - creating config drive
 - Fetch IP from guest Vm which is assigned by external DHCP



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

[jira] [Commented] (CLOUDSTACK-8610) [VMWARE] Unable to attach 7th Disk to a Windows server 2012R2 instance


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712844#comment-14712844
 ] 

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

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

CLOUDSTACK-8610. Unable to attach 7th Disk to Windows Server 2012 R2 instance. 
During disk attach, while trying to obtain the controller key for SCSI 
controller, look for device with the generic SCSI controller type i.e. 
VirtualSCSIController.

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com

This closes #554


 [VMWARE] Unable to attach 7th Disk to a Windows server 2012R2 instance
 --

 Key: CLOUDSTACK-8610
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8610
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Likitha Shetty
Assignee: Suresh Kumar Anaparti
 Fix For: 4.6.0


 +Steps to reproduce+
 1. Set global config vmware.root.disk.controller to 'osdefault'.
 2. Deploy a VM and attach 6 disks to the VM.
 3. Try to attach a 7th disk to the VM.
 Step 3 will fail with the below error
 {noformat}
 2015-06-22 11:03:22,673 ERROR [c.c.s.r.VmwareStorageProcessor] 
 (DirectAgent-636:ctx-8e72c2d9 s1p-z1-esxic-001.es.local, job-9286/job-9287, 
 cmd: AttachCommand) (logid:6372e940) Failed to attach volume: Failed to add 
 disk scsi0:7. 
 java.lang.RuntimeException: Failed to add disk scsi0:7. 
 at 
 com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:336)
  
 at 
 com.cloud.hypervisor.vmware.mo.VirtualMachineMO.attachDisk(VirtualMachineMO.java:1206)
 {noformat}



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

[jira] [Commented] (CLOUDSTACK-8602) MigrateVirtualMachineWithVolume leaves old chain data for volume


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712849#comment-14712849
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8602:


Github user asfgit closed the pull request at:

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


 MigrateVirtualMachineWithVolume leaves old chain data for volume
 

 Key: CLOUDSTACK-8602
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8602
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Likitha Shetty
Assignee: Suresh Kumar Anaparti
 Fix For: 4.6.0


 CS maintains chain info of every volume in DB, where chain info is the 
 complete volume path. When the volumes associated with a VM are migrated to 
 different storage pool, their chain info changes, but this information is not 
 reflected in the DB.



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

[jira] [Commented] (CLOUDSTACK-8773) NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the same time


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712659#comment-14712659
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8773:


GitHub user nlivens opened a pull request:

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

CLOUDSTACK-8773 : NPE in CheckRouterTask, when a DomainRouter happens…

… to be expunged at the same time

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nlivens/cloudstack master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/744.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #744


commit f91955d9a914179e9fb35e0994ef2b1afc6a2a28
Author: Nick Livens nick.liv...@nuagenetworks.net
Date:   2015-08-26T07:36:00Z

CLOUDSTACK-8773 : NPE in CheckRouterTask, when a DomainRouter happens to be 
expunged at the same time




 NPE in CheckRouterTask, when a DomainRouter happens to be expunged at the 
 same time
 ---

 Key: CLOUDSTACK-8773
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8773
 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
Reporter: Nick Livens
Priority: Minor

 During restart network of a tier with public LB, following exception occurred:
 {noformat:title=exception in management-server.log}
 2015-07-24 02:09:06,086 DEBUG [c.c.a.t.Request] (Job-Executor-44:ctx-7e4a9dc8 
 ctx-f882738e) Seq 1-59048436: Received:  { Ans: , MgmtId: 275619427002880, 
 via: 1, Ver: v1, Flags: 10, { Answer } }
 2015-07-24 02:09:06,166 INFO  [o.a.c.s.v.VolumeServiceImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Volume 11 is not referred 
 anywhere, remove it from volumes table
 2015-07-24 02:09:06,263 DEBUG [c.c.v.VirtualMachineManagerImpl] 
 (Job-Executor-44:ctx-7e4a9dc8 ctx-f882738e) Expunged 
 VM[VpcInlineLoadBalancerVm|b-8-VM]
 2015-07-24 02:09:06,391 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Found 2 routers to update status.
 2015-07-24 02:09:06,393 ERROR [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
 (RouterStatusMonitor-1:ctx-f911e31d) Fail to complete the CheckRouterTask!
 java.lang.NullPointerException
 at 
 com.cloud.network.vpn.Site2SiteVpnManagerImpl.getConnectionsForRouter(Site2SiteVpnManagerImpl.java:732)
 at sun.reflect.GeneratedMethodAccessor268.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 
 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.$Proxy206.getConnectionsForRouter(Unknown 
 Source)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl.updateSite2SiteVpnConnectionState(VirtualNetworkApplianceManagerImpl.java:1044)
 at 
 com.cloud.network.router.VirtualNetworkApplianceManagerImpl$CheckRouterTask.runInContext(VirtualNetworkApplianceManagerImpl.java:1348)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at

[jira] [Commented] (CLOUDSTACK-8761) Management server heartbeat takes too long to finish

2015-08-26 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712711#comment-14712711
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8761:


Github user karuturi commented on the pull request:

https://github.com/apache/cloudstack/pull/730#issuecomment-134899773
  
interesting... I do not see any such error while merging this pr
It uses python to get the author info on the contents of the url 
https://api.github.com/repos/apache/cloudstack/pulls/730 
```
curl -s https://api.github.com/repos/apache/cloudstack/pulls/730  
${jsonTmp}
prAuthor=$(cat ${jsonTmp} | python -c 
try:
  import sys, json
  print 
json.load(sys.stdin)['user']['login'].encode('utf-8').decode('ascii','ignore')
except:
  print ''
)
```

Can you check if the above works manually? 
@remibergsma have you seen any such issue with git pr script? 


 Management server heartbeat takes too long to finish
 

 Key: CLOUDSTACK-8761
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8761
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Wei Zhou
Assignee: Wei Zhou

 We got a lot of debug message in management-server.log every 1.5 seconds.
 The cluster.heartbeat.interval is set to 1500 by default. As it was not 
 changed after its first commit, so I think it is 1500 ms.
 However, The durations are less than 10ms actually.
 2015-08-18 00:00:04,526 DEBUG [c.c.c.ClusterManagerImpl] 
 (Cluster-Heartbeat-1:ctx-047bb88f) Management server heartbeat takes too long 
 to finish. profiler: Done. Duration: 4ms, profilerHeartbeatUpdate: Done. 
 Duration: 3ms, profilerPeerScan: Done. Duration: 0ms
 2015-08-18 00:00:06,036 DEBUG [c.c.c.ClusterManagerImpl] 
 (Cluster-Heartbeat-1:ctx-68018e26) Peer scan takes too long to finish. 
 profiler: Done. Duration: 0ms, profilerQueryActiveList: Done. Duration: 0ms, 
 profilerSyncClusterInfo: Done. Duration: 0ms, profilerInvalidatedNodeList: 
 Done. Duration: 0ms, profilerRemovedList: Done. Duration: 0ms



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

[jira] [Commented] (CLOUDSTACK-8749) KVM: link local route cleanup


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712724#comment-14712724
 ] 

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

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

CLOUDSTACK-8749: Add checks to prevent malformed/unexpected input

Based on @jburwell's comment on PR #718

This closes #733

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com


 KVM: link local route cleanup
 -

 Key: CLOUDSTACK-8749
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8749
 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: 4.5.3, 4.6.0


 The KVM agent attempts to delete link local interfaces whenever found, so 
 they don't conflict with the system vm's link local route on cloud0, however 
 it doesn't specify which device to delete the route for.
 The aim is to fix the edge case which (unlikely) can try to delete existing 
 cloud0 routes/interface.



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

[jira] [Commented] (CLOUDSTACK-8749) KVM: link local route cleanup

2015-08-26 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712725#comment-14712725
 ] 

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

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

Merge pull request #733 from shapeblue/kvm-linkbr-checks

CLOUDSTACK-8749: Add checks to prevent malformed/unexpected inputBased on 
@jburwell's comment on PR #718

* pr/733:
  CLOUDSTACK-8749: Add checks to prevent malformed/unexpected input

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com


 KVM: link local route cleanup
 -

 Key: CLOUDSTACK-8749
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8749
 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: 4.5.3, 4.6.0


 The KVM agent attempts to delete link local interfaces whenever found, so 
 they don't conflict with the system vm's link local route on cloud0, however 
 it doesn't specify which device to delete the route for.
 The aim is to fix the edge case which (unlikely) can try to delete existing 
 cloud0 routes/interface.



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

[jira] [Commented] (CLOUDSTACK-8749) KVM: link local route cleanup


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712728#comment-14712728
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8749:


Github user asfgit closed the pull request at:

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


 KVM: link local route cleanup
 -

 Key: CLOUDSTACK-8749
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8749
 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: 4.5.3, 4.6.0


 The KVM agent attempts to delete link local interfaces whenever found, so 
 they don't conflict with the system vm's link local route on cloud0, however 
 it doesn't specify which device to delete the route for.
 The aim is to fix the edge case which (unlikely) can try to delete existing 
 cloud0 routes/interface.



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

[jira] [Commented] (CLOUDSTACK-8721) Setting details of VM through API results in removal of all other details except the one passed in API


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712816#comment-14712816
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8721:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/673#issuecomment-134919656
  
Ping, update on this?


 Setting details of VM through API results in removal of all other details 
 except the one passed in API
 --

 Key: CLOUDSTACK-8721
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8721
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Anshul Gangwar
Assignee: Anshul Gangwar

 Setting details of VM through API results in removal of all other details 
 except the one passed in API. We are storing vm details which are not set by 
 user and in this process of setting details all details are getting lost 
 which could lead to other issues.



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

[jira] [Commented] (CLOUDSTACK-8716) Verify creation of snapshot from volume when the task is performed repeatedly in zone wide primary Storage.


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712818#comment-14712818
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8716:


Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/665#issuecomment-134920085
  
LGTM


 Verify creation of snapshot from volume when the task is performed repeatedly 
 in zone wide primary Storage.
 ---

 Key: CLOUDSTACK-8716
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8716
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.2.1
Reporter: Priti Sarap
 Fix For: 4.2.1


 On VMWare with a Zone wide primary storage and more than two clusters verify 
 successful creation of snapshot multiple times.



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

[jira] [Commented] (CLOUDSTACK-8721) Setting details of VM through API results in removal of all other details except the one passed in API


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712841#comment-14712841
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8721:


Github user anshul1886 commented on the pull request:

https://github.com/apache/cloudstack/pull/673#issuecomment-134925254
  
@bhaisaab What else is needed here? 


 Setting details of VM through API results in removal of all other details 
 except the one passed in API
 --

 Key: CLOUDSTACK-8721
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8721
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Anshul Gangwar
Assignee: Anshul Gangwar

 Setting details of VM through API results in removal of all other details 
 except the one passed in API. We are storing vm details which are not set by 
 user and in this process of setting details all details are getting lost 
 which could lead to other issues.



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

[jira] [Commented] (CLOUDSTACK-8716) Verify creation of snapshot from volume when the task is performed repeatedly in zone wide primary Storage.

2015-08-26 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712839#comment-14712839
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8716:


Github user asfgit closed the pull request at:

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


 Verify creation of snapshot from volume when the task is performed repeatedly 
 in zone wide primary Storage.
 ---

 Key: CLOUDSTACK-8716
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8716
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.2.1
Reporter: Priti Sarap
 Fix For: 4.2.1


 On VMWare with a Zone wide primary storage and more than two clusters verify 
 successful creation of snapshot multiple times.



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

[jira] [Commented] (CLOUDSTACK-8723) Verify API call listUsageRecords returns usage of new volume created after restore VM


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712833#comment-14712833
 ] 

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

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

Merge pull request #675 from 
pritisarap12/CLOUDSTACK-8723-Verify-API-call-listUsageRecords-returns-usage-of-new-volume-created-after-restore-VM

CLOUDSTACK-8723: Verify API call listUsageRecords returns usage of new volume 
created after restore VMAfter restoring a running VM current ROOT disk gets 
destroyed and new ROOT disk gets created.
This testcase is to check if volume usage of this newly created volume is 
listed in listUsageRecords API.

* pr/675:
  CLOUDSTACK-8723: Verify API call listUsageRecords returns usage of new 
volume created after restore VM

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com


 Verify API call listUsageRecords returns usage of new volume created after 
 restore VM
 ---

 Key: CLOUDSTACK-8723
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8723
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.2.1
Reporter: Priti Sarap
 Fix For: 4.2.1


 After restoring a running VM current ROOT disk gets destroyed and new ROOT 
 disk gets created.
 This testcase is to check if volume usage of this newly created volume is 
 listed in listUsageRecords API.



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

[jira] [Commented] (CLOUDSTACK-8716) Verify creation of snapshot from volume when the task is performed repeatedly in zone wide primary Storage.

2015-08-26 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14712832#comment-14712832
 ] 

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

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

CLOUDSTACK-8716: Verify creation of snapshot from volume when the task is 
performed repeatedly in zone wide primary Storage

CLOUDSTACK-8716: Verify creation of snapshot from volume when the task is 
performed repeatedly in zone wide primary Storage
 -Removing redundent code
 -Added validate list function for list snapshot operation

CLOUDSTACK-8716: Verify creation of snapshot from volume when the task is 
performed repeatedly in zone wide primary Storage


 Verify creation of snapshot from volume when the task is performed repeatedly 
 in zone wide primary Storage.
 ---

 Key: CLOUDSTACK-8716
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8716
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.2.1
Reporter: Priti Sarap
 Fix For: 4.2.1


 On VMWare with a Zone wide primary storage and more than two clusters verify 
 successful creation of snapshot multiple times.



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

[jira] [Commented] (CLOUDSTACK-8723) Verify API call listUsageRecords returns usage of new volume created after restore VM