[jira] [Closed] (CLOUDSTACK-9111) cloudstack-management start failed (CloudStack 4.6.1 + CentOS7)

[satoru nakaya (JIRA)]

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

satoru nakaya closed CLOUDSTACK-9111.
-
Resolution: Not A Problem

In the case of centos7:

cloudstack-setup-management --tomcat7


> cloudstack-management start failed (CloudStack 4.6.1 + CentOS7)
> ---
>
> Key: CLOUDSTACK-9111
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9111
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.1
> Environment: CloudStack 4.6.1 , CentOS7
> http://packages.shapeblue.com/cloudstack/upstream/centos7/4.6/
>Reporter: satoru nakaya
>
> Steps to reproduce:
> 1)clean install CloudStack 4.6.1 on CentOS7
>   use http://packages.shapeblue.com/cloudstack/upstream/centos7/4.6/
> [root@acs ~]# cat /etc/redhat-release
> CentOS Linux release 7.1.1503 (Core)
> [root@acs ~]#
> [root@acs ~]# rpm -qa | grep cloudstack
> cloudstack-management-4.6.1-shapeblue0.el7.centos.x86_64
> cloudstack-common-4.6.1-shapeblue0.el7.centos.x86_64
> [root@acs ~]#
> 2)cloudstack-setup-databases...(snip)
> 3)cloudstack-setup-management　(Failed)
> [root@acs ~]# cloudstack-setup-management
> Starting to configure CloudStack Management Server:
> Configure Firewall ...[OK]
> Configure CloudStack Management Server ...[Failed]
> Cannot find /etc/cloudstack/management/server-nonssl.xml or 
> /etc/cloudstack/management/tomcat6-nonssl.conf, https enable failed
> Try to restore your system:
> Restore Firewall ...  [OK]
> Restore CloudStack Management Server ...[OK]
> [root@acs ~]#
> 4)check log (/var/log/messages)
> Dec  6 10:08:51 acs server: WARNING: Unable to load server configuration from 
> [/usr/share/cloudstack-management/conf/server.xml]
> 5)check service status (failed)
> [root@acs ~]# systemctl status cloudstack-management.service
> cloudstack-management.service - CloudStack Management Server
>Loaded: loaded (/usr/lib/systemd/system/cloudstack-management.service; 
> enabled)
>Active: failed (Result: exit-code) since Sun 2015-12-06 10:08:52 JST; 11s 
> ago
>   Process: 3061 ExecStop=/usr/libexec/tomcat/server stop (code=exited, 
> status=1/FAILURE)
>   Process: 3026 ExecStart=/usr/libexec/tomcat/server start (code=exited, 
> status=0/SUCCESS)
>  Main PID: 3026 (code=exited, status=0/SUCCESS)
> Dec 06 10:08:52 acs.dom.local server[3061]: at 
> java.io.FileInputStream.(FileInputStream.java:146)
> Dec 06 10:08:52 acs.dom.local server[3061]: at 
> org.apache.catalina.startup.Catalina.stopServer(Catalina.java:466)
> Dec 06 10:08:52 acs.dom.local server[3061]: at 
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> Dec 06 10:08:52 acs.dom.local server[3061]: at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> Dec 06 10:08:52 acs.dom.local server[3061]: at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI...va:43)
> Dec 06 10:08:52 acs.dom.local server[3061]: at 
> java.lang.reflect.Method.invoke(Method.java:606)
> Dec 06 10:08:52 acs.dom.local server[3061]: at 
> org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:370)
> Dec 06 10:08:52 acs.dom.local server[3061]: at 
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:457)
> Dec 06 10:08:52 acs.dom.local systemd[1]: cloudstack-management.service: 
> control process exited, code=exited status=1
> Dec 06 10:08:52 acs.dom.local systemd[1]: Unit cloudstack-management.service 
> entered failed state.
> Hint: Some lines were ellipsized, use -l to show in full.
> [root@acs ~]#
> workaround:
> The correct do not know whether or not , but it worked.
> 6)check file
> [root@acs ~]# ls -la /etc/cloudstack/management
> total 132
> drwxr-xr-x. 3 root root   4096 Dec  5 17:59 .
> drwxr-xr-x. 3 root root   4096 Dec  5 17:53 ..
> drwxrwx---. 3 root cloud  4096 Dec  5 17:53 Catalina
> -rw-r--r--. 1 root root   8945 Dec  1 20:22 catalina.policy
> -rw-r--r--. 1 root root   3794 Dec  1 20:22 catalina.properties
> -rw-r--r--. 1 root root   1653 Dec  1 20:22 classpath.conf
> -rw-r--r--. 1 root root   1357 Dec  1 20:22 commons-logging.properties
> -rw-r-. 1 root cloud  3137 Dec  5 17:59 db.properties
> -rw-r--r--. 1 root root979 Dec  1 20:22 environment.properties
> -rw-r--r--. 1 root root927 Dec  1 20:22 java.security.ciphers
> -rw-r--r--. 1 root root  8 Dec  5 17:55 key
> -rw-r--r--. 1 root root   7020 Dec  1 20:22 log4j-cloud.xml
> -rw-r--r--. 1 root root   6722 Dec  1 20:22 server7-nonssl.xml
> -rw-r--r--. 1 root root   7251 Dec  1 20:22 server7-ssl.xml
> -rw-r--r--. 1 root root   1383 Dec  1 20:22 tomcat-users.xml
> -rw-r--r--. 1 root root  50475 Dec  1 20:22 web.xml
> [root@acs ~]
> 7)copy file
> 

[jira] [Commented] (CLOUDSTACK-9111) cloudstack-management start failed (CloudStack 4.6.1 + CentOS7)

[satoru nakaya (JIRA)]

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

satoru nakaya commented on CLOUDSTACK-9111:
---

It worked fine.

[root@acs ~]# cloudstack-setup-management --tomcat7
Starting to configure CloudStack Management Server:
Configure Firewall ...[OK]
Configure CloudStack Management Server ...[OK]
CloudStack Management Server setup is Done!
[root@acs ~]#

[root@acs ~]# ls -la /etc/cloudstack/management
total 136
drwxr-xr-x. 3 root root   4096 Dec  6 16:54 .
drwxr-xr-x. 4 root root   4096 Dec  5 19:36 ..
drwxrwx---. 3 root cloud  4096 Dec  5 18:52 Catalina
-rw-r--r--. 1 root root   8945 Dec  1 20:22 catalina.policy
-rw-r--r--. 1 root root   3794 Dec  1 20:22 catalina.properties
-rw-r--r--. 1 root root   1653 Dec  1 20:22 classpath.conf
-rw-r--r--. 1 root root   2211 Dec  6 10:13 cloudmanagementserver.keystore
-rw-r--r--. 1 root root   1357 Dec  1 20:22 commons-logging.properties
-rw-r-. 1 root cloud  3137 Dec  5 18:56 db.properties
-rw-r--r--. 1 root root979 Dec  1 20:22 environment.properties
-rw-r--r--. 1 root root927 Dec  1 20:22 java.security.ciphers
-rw-r--r--. 1 root root  8 Dec  5 18:54 key
-rw-r--r--. 1 root root   7020 Dec  1 20:22 log4j-cloud.xml
-rw-r--r--. 1 root root   6722 Dec  1 20:22 server7-nonssl.xml
-rw-r--r--. 1 root root   7251 Dec  1 20:22 server7-ssl.xml
lrwxrwxrwx. 1 root root 45 Dec  6 16:54 server.xml -> 
/etc/cloudstack/management/server7-nonssl.xml
-rw-r--r--. 1 root root   1383 Dec  1 20:22 tomcat-users.xml
-rw-r--r--. 1 root root  50475 Dec  1 20:22 web.xml
[root@acs ~]#

[root@acs ~]# systemctl status cloudstack-management.service
cloudstack-management.service - CloudStack Management Server
   Loaded: loaded (/usr/lib/systemd/system/cloudstack-management.service; 
enabled)
   Active: inactive (dead) since Sun 2015-12-06 16:51:51 JST; 3min 6s ago
 Main PID: 3164 (code=exited, status=143)
   CGroup: /system.slice/cloudstack-management.service

Dec 06 16:51:51 acs.dom.local server[3164]: Dec 06, 2015 4:51:51 PM 
org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
Dec 06 16:51:51 acs.dom.local server[3164]: SEVERE: The web application 
[/client] appears to have started a thread named [FileWatchdog] but has 
failed...ory leak.
Dec 06 16:51:51 acs.dom.local server[3164]: Dec 06, 2015 4:51:51 PM 
org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
Dec 06 16:51:51 acs.dom.local server[3164]: SEVERE: The web application 
[/client] appears to have started a thread named [AgentManager-Handler-1] but 
...ory leak.
Dec 06 16:51:51 acs.dom.local systemd[1]: Stopped CloudStack Management Server.
Dec 06 16:53:00 acs.dom.local systemd[1]: Stopped CloudStack Management Server.
Dec 06 16:53:14 acs.dom.local systemd[1]: Stopped CloudStack Management Server.
Dec 06 16:53:36 acs.dom.local systemd[1]: Stopped CloudStack Management Server.
Dec 06 16:54:13 acs.dom.local systemd[1]: Stopped CloudStack Management Server.
Dec 06 16:54:35 acs.dom.local systemd[1]: Stopped CloudStack Management Server.
Hint: Some lines were ellipsized, use -l to show in full.
[root@acs ~]#

[root@acs ~]# systemctl start cloudstack-management.service
[root@acs ~]#

[root@acs ~]# systemctl status cloudstack-management.service
cloudstack-management.service - CloudStack Management Server
   Loaded: loaded (/usr/lib/systemd/system/cloudstack-management.service; 
enabled)
   Active: active (running) since Sun 2015-12-06 16:55:42 JST; 2s ago
 Main PID: 11377 (java)
   CGroup: /system.slice/cloudstack-management.service
   mq11377 java -Djava.awt.headless=true 
-Dcom.sun.management.jmxremote=false -Xmx2g -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/var/log/cloudsta...

Dec 06 16:55:43 acs.dom.local server[11377]: Dec 06, 2015 4:55:43 PM 
org.apache.coyote.AbstractProtocol init
Dec 06 16:55:43 acs.dom.local server[11377]: INFO: Initializing ProtocolHandler 
["ajp-bio-20400"]
Dec 06 16:55:43 acs.dom.local server[11377]: Dec 06, 2015 4:55:43 PM 
org.apache.catalina.startup.Catalina load
Dec 06 16:55:43 acs.dom.local server[11377]: INFO: Initialization processed in 
1092 ms
Dec 06 16:55:43 acs.dom.local server[11377]: Dec 06, 2015 4:55:43 PM 
org.apache.catalina.core.StandardService startInternal
Dec 06 16:55:43 acs.dom.local server[11377]: INFO: Starting service Catalina
Dec 06 16:55:43 acs.dom.local server[11377]: Dec 06, 2015 4:55:43 PM 
org.apache.catalina.core.StandardEngine startInternal
Dec 06 16:55:43 acs.dom.local server[11377]: INFO: Starting Servlet Engine: 
Apache Tomcat/7.0.54
Dec 06 16:55:43 acs.dom.local server[11377]: Dec 06, 2015 4:55:43 PM 
org.apache.catalina.startup.HostConfig deployDirectory
Dec 06 16:55:43 acs.dom.local server[11377]: INFO: Deploying web application 
directory /usr/share/cloudstack-management/webapps/client
[root@acs ~]#


> cloudstack-management start failed (CloudStack 4.6.1 

[jira] [Created] (CLOUDSTACK-9110) Default route is not configured on Redundunt VPC VR (tier 2)

[satoru nakaya (JIRA)]

satoru nakaya created CLOUDSTACK-9110:
-

 Summary: Default route is not configured on Redundunt VPC VR (tier 
2)
 Key: CLOUDSTACK-9110
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9110
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.6.1
 Environment: CloudStack 4.6.1
http://packages.shapeblue.com/cloudstack/upstream/centos7/4.6/

Hypervisor CentOS7/KVM

SystemVM
http://cloudstack.apt-get.eu/systemvm/4.6/systemvm64template-4.6.0-kvm.qcow2.bz2
Reporter: satoru nakaya


Steps to reproduce:


1)Create VPC (Redundant VPC offering)

2)Create tier1 & tier2

3)Create VM Instance on tier1 & tier2

4)Check VPC VR IP Address (no problem)

root@r-9-VM:~# ip a
1: lo:  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
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:00:9a brd ff:ff:ff:ff:ff:ff
inet 169.254.0.154/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:ac:80:00:00:21 brd ff:ff:ff:ff:ff:ff
inet 10.0.1.102/24 brd 10.0.1.255 scope global eth1
inet 10.0.1.103/24 brd 10.0.1.255 scope global secondary eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:7f:b8:00:05 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.67/24 brd 172.16.0.255 scope global eth2
inet 172.16.0.1/24 brd 172.16.0.255 scope global secondary eth2
5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:03:56:00:04 brd ff:ff:ff:ff:ff:ff
inet 172.16.1.25/24 brd 172.16.1.255 scope global eth3
inet 172.16.1.1/24 brd 172.16.1.255 scope global secondary eth3
root@r-9-VM:~#

root@r-10-VM:~# ip a
1: lo:  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
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:00:49 brd ff:ff:ff:ff:ff:ff
inet 169.254.0.73/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 06:ac:80:00:00:21 brd ff:ff:ff:ff:ff:ff
inet 10.0.1.102/24 brd 10.0.1.255 scope global eth1
inet 10.0.1.103/24 brd 10.0.1.255 scope global secondary eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:19:11:00:06 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.233/24 brd 172.16.0.255 scope global eth2
5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:20:19:00:05 brd ff:ff:ff:ff:ff:ff
inet 172.16.1.231/24 brd 172.16.1.255 scope global eth3
root@r-10-VM:~#


5)Reboot VPC VR r-9-VM
6)Check VPC VR IP Address (no problem)

root@r-9-VM:~# ip a
1: lo:  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
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:01:28 brd ff:ff:ff:ff:ff:ff
inet 169.254.1.40/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 06:ac:80:00:00:21 brd ff:ff:ff:ff:ff:ff
inet 10.0.1.103/24 brd 10.0.1.255 scope global eth1
inet 10.0.1.102/24 brd 10.0.1.255 scope global secondary eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:7f:b8:00:05 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.67/24 brd 172.16.0.255 scope global eth2
5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:03:56:00:04 brd ff:ff:ff:ff:ff:ff
inet 172.16.1.25/24 brd 172.16.1.255 scope global eth3
root@r-9-VM:~#

root@r-10-VM:~# ip a
1: lo:  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
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:00:49 brd ff:ff:ff:ff:ff:ff
inet 169.254.0.73/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:ac:80:00:00:21 brd ff:ff:ff:ff:ff:ff
inet 10.0.1.102/24 brd 10.0.1.255 scope global eth1
inet 10.0.1.103/24 brd 10.0.1.255 scope global secondary eth1
4: eth2: 

[jira] [Updated] (CLOUDSTACK-9110) Default route is not configured on Redundant VPC VR (tier 2)

[satoru nakaya (JIRA)]

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

satoru nakaya updated CLOUDSTACK-9110:
--
Summary: Default route is not configured on Redundant VPC VR (tier 2)  
(was: Default route is not configured on Redundunt VPC VR (tier 2))

> Default route is not configured on Redundant VPC VR (tier 2)
> 
>
> Key: CLOUDSTACK-9110
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9110
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.6.1
> Environment: CloudStack 4.6.1
> http://packages.shapeblue.com/cloudstack/upstream/centos7/4.6/
> Hypervisor CentOS7/KVM
> SystemVM
> http://cloudstack.apt-get.eu/systemvm/4.6/systemvm64template-4.6.0-kvm.qcow2.bz2
>Reporter: satoru nakaya
>
> Steps to reproduce:
> 1)Create VPC (Redundant VPC offering)
> 2)Create tier1 & tier2
> 3)Create VM Instance on tier1 & tier2
> 4)Check VPC VR IP Address (no problem)
> root@r-9-VM:~# ip a
> 1: lo:  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
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:00:9a brd ff:ff:ff:ff:ff:ff
> inet 169.254.0.154/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:ac:80:00:00:21 brd ff:ff:ff:ff:ff:ff
> inet 10.0.1.102/24 brd 10.0.1.255 scope global eth1
> inet 10.0.1.103/24 brd 10.0.1.255 scope global secondary eth1
> 4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:7f:b8:00:05 brd ff:ff:ff:ff:ff:ff
> inet 172.16.0.67/24 brd 172.16.0.255 scope global eth2
> inet 172.16.0.1/24 brd 172.16.0.255 scope global secondary eth2
> 5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:03:56:00:04 brd ff:ff:ff:ff:ff:ff
> inet 172.16.1.25/24 brd 172.16.1.255 scope global eth3
> inet 172.16.1.1/24 brd 172.16.1.255 scope global secondary eth3
> root@r-9-VM:~#
> root@r-10-VM:~# ip a
> 1: lo:  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
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:00:49 brd ff:ff:ff:ff:ff:ff
> inet 169.254.0.73/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc noop state DOWN qlen 1000
> link/ether 06:ac:80:00:00:21 brd ff:ff:ff:ff:ff:ff
> inet 10.0.1.102/24 brd 10.0.1.255 scope global eth1
> inet 10.0.1.103/24 brd 10.0.1.255 scope global secondary eth1
> 4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:19:11:00:06 brd ff:ff:ff:ff:ff:ff
> inet 172.16.0.233/24 brd 172.16.0.255 scope global eth2
> 5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:20:19:00:05 brd ff:ff:ff:ff:ff:ff
> inet 172.16.1.231/24 brd 172.16.1.255 scope global eth3
> root@r-10-VM:~#
> 5)Reboot VPC VR r-9-VM
> 6)Check VPC VR IP Address (no problem)
> root@r-9-VM:~# ip a
> 1: lo:  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
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:01:28 brd ff:ff:ff:ff:ff:ff
> inet 169.254.1.40/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc noop state DOWN qlen 1000
> link/ether 06:ac:80:00:00:21 brd ff:ff:ff:ff:ff:ff
> inet 10.0.1.103/24 brd 10.0.1.255 scope global eth1
> inet 10.0.1.102/24 brd 10.0.1.255 scope global secondary eth1
> 4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:7f:b8:00:05 brd ff:ff:ff:ff:ff:ff
> inet 172.16.0.67/24 brd 172.16.0.255 scope global eth2
> 5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:03:56:00:04 brd ff:ff:ff:ff:ff:ff
> inet 172.16.1.25/24 brd 172.16.1.255 scope global eth3
> root@r-9-VM:~#
> root@r-10-VM:~# ip a
> 1: lo:  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
> 2: eth0: 

[jira] [Updated] (CLOUDSTACK-9110) Default route is not configured on Redundant VPC VR (tier 2)

[satoru nakaya (JIRA)]

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

satoru nakaya updated CLOUDSTACK-9110:
--
Description: 
Steps to reproduce:


1)Create VPC (Redundant VPC offering)

2)Create tier1 & tier2

3)Create VM Instance on tier1 & tier2

4)Check VPC VR IP Address (no problem)

root@r-9-VM:~# ip a
1: lo:  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
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:00:9a brd ff:ff:ff:ff:ff:ff
inet 169.254.0.154/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:ac:80:00:00:21 brd ff:ff:ff:ff:ff:ff
inet 10.0.1.102/24 brd 10.0.1.255 scope global eth1
inet 10.0.1.103/24 brd 10.0.1.255 scope global secondary eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:7f:b8:00:05 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.67/24 brd 172.16.0.255 scope global eth2
inet 172.16.0.1/24 brd 172.16.0.255 scope global secondary eth2
5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:03:56:00:04 brd ff:ff:ff:ff:ff:ff
inet 172.16.1.25/24 brd 172.16.1.255 scope global eth3
inet 172.16.1.1/24 brd 172.16.1.255 scope global secondary eth3
root@r-9-VM:~#

root@r-10-VM:~# ip a
1: lo:  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
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:00:49 brd ff:ff:ff:ff:ff:ff
inet 169.254.0.73/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 06:ac:80:00:00:21 brd ff:ff:ff:ff:ff:ff
inet 10.0.1.102/24 brd 10.0.1.255 scope global eth1
inet 10.0.1.103/24 brd 10.0.1.255 scope global secondary eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:19:11:00:06 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.233/24 brd 172.16.0.255 scope global eth2
5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:20:19:00:05 brd ff:ff:ff:ff:ff:ff
inet 172.16.1.231/24 brd 172.16.1.255 scope global eth3
root@r-10-VM:~#


5)Reboot VPC VR r-9-VM
6)Check VPC VR IP Address (no problem)

root@r-9-VM:~# ip a
1: lo:  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
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:01:28 brd ff:ff:ff:ff:ff:ff
inet 169.254.1.40/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 06:ac:80:00:00:21 brd ff:ff:ff:ff:ff:ff
inet 10.0.1.103/24 brd 10.0.1.255 scope global eth1
inet 10.0.1.102/24 brd 10.0.1.255 scope global secondary eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:7f:b8:00:05 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.67/24 brd 172.16.0.255 scope global eth2
5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:03:56:00:04 brd ff:ff:ff:ff:ff:ff
inet 172.16.1.25/24 brd 172.16.1.255 scope global eth3
root@r-9-VM:~#

root@r-10-VM:~# ip a
1: lo:  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
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:00:49 brd ff:ff:ff:ff:ff:ff
inet 169.254.0.73/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:ac:80:00:00:21 brd ff:ff:ff:ff:ff:ff
inet 10.0.1.102/24 brd 10.0.1.255 scope global eth1
inet 10.0.1.103/24 brd 10.0.1.255 scope global secondary eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:19:11:00:06 brd ff:ff:ff:ff:ff:ff
inet 172.16.0.233/24 brd 172.16.0.255 scope global eth2
inet 172.16.0.1/24 brd 172.16.0.255 scope global secondary eth2
5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:20:19:00:05 brd ff:ff:ff:ff:ff:ff
inet 172.16.1.231/24 brd 172.16.1.255 scope global eth3
inet 172.16.1.1/24 brd 172.16.1.255 scope global secondary eth3

[jira] [Created] (CLOUDSTACK-9111) cloudstack-management start failed (CloudStack 4.6.1 + CentOS7)

[satoru nakaya (JIRA)]

satoru nakaya created CLOUDSTACK-9111:
-

 Summary: cloudstack-management start failed (CloudStack 4.6.1 + 
CentOS7)
 Key: CLOUDSTACK-9111
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9111
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.6.1
 Environment: CloudStack 4.6.1 , CentOS7
http://packages.shapeblue.com/cloudstack/upstream/centos7/4.6/
Reporter: satoru nakaya


Steps to reproduce:

1)clean install CloudStack 4.6.1 on CentOS7

  use http://packages.shapeblue.com/cloudstack/upstream/centos7/4.6/

[root@acs ~]# cat /etc/redhat-release
CentOS Linux release 7.1.1503 (Core)
[root@acs ~]#
[root@acs ~]# rpm -qa | grep cloudstack
cloudstack-management-4.6.1-shapeblue0.el7.centos.x86_64
cloudstack-common-4.6.1-shapeblue0.el7.centos.x86_64
[root@acs ~]#

2)cloudstack-setup-databases...(snip)

3)cloudstack-setup-management　(Failed)

[root@acs ~]# cloudstack-setup-management
Starting to configure CloudStack Management Server:
Configure Firewall ...[OK]
Configure CloudStack Management Server ...[Failed]
Cannot find /etc/cloudstack/management/server-nonssl.xml or 
/etc/cloudstack/management/tomcat6-nonssl.conf, https enable failed
Try to restore your system:
Restore Firewall ...  [OK]
Restore CloudStack Management Server ...[OK]
[root@acs ~]#

4)check log (/var/log/messages)

Dec  6 10:08:51 acs server: WARNING: Unable to load server configuration from 
[/usr/share/cloudstack-management/conf/server.xml]

5)check service status (failed)

[root@acs ~]# systemctl status cloudstack-management.service
cloudstack-management.service - CloudStack Management Server
   Loaded: loaded (/usr/lib/systemd/system/cloudstack-management.service; 
enabled)
   Active: failed (Result: exit-code) since Sun 2015-12-06 10:08:52 JST; 11s ago
  Process: 3061 ExecStop=/usr/libexec/tomcat/server stop (code=exited, 
status=1/FAILURE)
  Process: 3026 ExecStart=/usr/libexec/tomcat/server start (code=exited, 
status=0/SUCCESS)
 Main PID: 3026 (code=exited, status=0/SUCCESS)

Dec 06 10:08:52 acs.dom.local server[3061]: at 
java.io.FileInputStream.(FileInputStream.java:146)
Dec 06 10:08:52 acs.dom.local server[3061]: at 
org.apache.catalina.startup.Catalina.stopServer(Catalina.java:466)
Dec 06 10:08:52 acs.dom.local server[3061]: at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Dec 06 10:08:52 acs.dom.local server[3061]: at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
Dec 06 10:08:52 acs.dom.local server[3061]: at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI...va:43)
Dec 06 10:08:52 acs.dom.local server[3061]: at 
java.lang.reflect.Method.invoke(Method.java:606)
Dec 06 10:08:52 acs.dom.local server[3061]: at 
org.apache.catalina.startup.Bootstrap.stopServer(Bootstrap.java:370)
Dec 06 10:08:52 acs.dom.local server[3061]: at 
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:457)
Dec 06 10:08:52 acs.dom.local systemd[1]: cloudstack-management.service: 
control process exited, code=exited status=1
Dec 06 10:08:52 acs.dom.local systemd[1]: Unit cloudstack-management.service 
entered failed state.
Hint: Some lines were ellipsized, use -l to show in full.
[root@acs ~]#


workaround:
The correct do not know whether or not , but it worked.

6)check file

[root@acs ~]# ls -la /etc/cloudstack/management
total 132
drwxr-xr-x. 3 root root   4096 Dec  5 17:59 .
drwxr-xr-x. 3 root root   4096 Dec  5 17:53 ..
drwxrwx---. 3 root cloud  4096 Dec  5 17:53 Catalina
-rw-r--r--. 1 root root   8945 Dec  1 20:22 catalina.policy
-rw-r--r--. 1 root root   3794 Dec  1 20:22 catalina.properties
-rw-r--r--. 1 root root   1653 Dec  1 20:22 classpath.conf
-rw-r--r--. 1 root root   1357 Dec  1 20:22 commons-logging.properties
-rw-r-. 1 root cloud  3137 Dec  5 17:59 db.properties
-rw-r--r--. 1 root root979 Dec  1 20:22 environment.properties
-rw-r--r--. 1 root root927 Dec  1 20:22 java.security.ciphers
-rw-r--r--. 1 root root  8 Dec  5 17:55 key
-rw-r--r--. 1 root root   7020 Dec  1 20:22 log4j-cloud.xml
-rw-r--r--. 1 root root   6722 Dec  1 20:22 server7-nonssl.xml
-rw-r--r--. 1 root root   7251 Dec  1 20:22 server7-ssl.xml
-rw-r--r--. 1 root root   1383 Dec  1 20:22 tomcat-users.xml
-rw-r--r--. 1 root root  50475 Dec  1 20:22 web.xml
[root@acs ~]


7)copy file

[root@acs ~]# cd /etc/cloudstack/management
[root@acs management]# cp -p server7-nonssl.xml server.xml

8)start cloudstack-management service

[root@acs ~]# systemctl start cloudstack-management.service

9)check service status (running)

[root@acs ~]# systemctl status cloudstack-management.service
cloudstack-management.service - CloudStack Management Server
   Loaded: loaded (/usr/lib/systemd/system/cloudstack-management.service; 

[jira] [Commented] (CLOUDSTACK-9015) Redundant VPC Virtual Router's state is BACKUP & BACKUP

[satoru nakaya (JIRA)]

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

satoru nakaya commented on CLOUDSTACK-9015:
---


It recovered in the following.
I think there is a problem in the iptables rules ?

(I do not set the ACL (Default_allow))


15) Flush iptables rule r-40-VM
16) Flush iptables rule r-41-VM
17) Check Redundant state (good)
r-40-VM Redundant state:MASTER
r-41-VM Redundant state:BACKUP

==

root@r-40-VM:~# /etc/init.d/iptables-persistent flush
[ ok ] Flushing rules... IPv4... IPv6...done.
root@r-40-VM:~# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
root@r-40-VM:~#

root@r-41-VM:~# /etc/init.d/iptables-persistent flush
[ ok ] Flushing rules... IPv4... IPv6...done.
root@r-41-VM:~# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
root@r-41-VM:~#

root@r-40-VM:~# tcpdump -i eth2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
04:37:50.599495 IP 172.17.0.111.36574 > 225.0.0.50.3780: UDP, length 16
04:37:50.951447 IP 172.17.0.123 > vrrp.mcast.net: AH(spi=0xac11007b,seq=0x20f): 
VRRPv2, Advertisement, vrid 7, prio 1, authtype ah, intvl 1s, length 20
04:37:51.155104 IP 172.17.0.123.39245 > 225.0.0.50.3780: UDP, length 16
04:37:51.600175 IP 172.17.0.111.36574 > 225.0.0.50.3780: UDP, length 16
04:37:51.952787 IP 172.17.0.123 > vrrp.mcast.net: AH(spi=0xac11007b,seq=0x210): 
VRRPv2, Advertisement, vrid 7, prio 1, authtype ah, intvl 1s, length 20

==


> Redundant VPC Virtual Router's state is BACKUP & BACKUP
> ---
>
> Key: CLOUDSTACK-9015
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9015
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: CloudStack master(2015/10/31) 4.6.0-snapshot
> Hypervisor CentOS6/KVM
> SystemVM
> build #654 (2015/10/22 19:27:55)
> http://jenkins.buildacloud.org/job/build-systemvm64-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvm64template-master-4.6.0-kvm.qcow2.bz2
>Reporter: satoru nakaya
>Assignee: Wilder Rodrigues
>Priority: Critical
>
> Steps of reproduce.
> 1)Create VPC (Redundant VPC offering)
> 2)Create tier
> 3)Create VM Instance on this tier
> 4)Check Redundant state (good)
>r-14-VM Redundant state:MASTER
>r-15-VM Redundant state:BACKUP
> 5) Reboot Router r-14-VM
> 6)Check Redundant state (good)
>r-14-VM Redundant state:BACKUP
>r-15-VM Redundant state:MASTER
> 7) Reboot Router r-15-VM
> 8)Check Redundant state (bad)
>r-14-VM Redundant state:BACKUP
>r-15-VM Redundant state:BACKUP
> 9)Check Log(r-14-VM's /var/log/messages)
> Nov  1 00:46:29 r-14-VM Keepalived_vrrp[3711]: VRRP_Instance(inside_network) 
> sending 0 priority
> Nov  1 00:47:34 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:47:34 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:53 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:53 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:47:54 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:47:54 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
> 10)Check Log(r-15-VM's /var/log/messages)
> Nov  1 00:49:19 r-15-VM Keepalived_vrrp[3682]: VRRP_Instance(inside_network) 
> sending 0 priority
> Nov  1 00:50:25 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:50:25 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
> Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
> function error
> Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error



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

[jira] [Comment Edited] (CLOUDSTACK-9015) Redundant VPC Virtual Router's state is BACKUP & BACKUP

[satoru nakaya (JIRA)]

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

satoru nakaya edited comment on CLOUDSTACK-9015 at 11/3/15 5:33 AM:


It recovered in the following.
I think there is a problem in the iptables rules ?

(I do not set the ACL (Default_allow))


15) Flush iptables rule r-40-VM
16) Flush iptables rule r-41-VM
17) Check Redundant state (good)
r-40-VM Redundant state:MASTER -> MASTER
r-41-VM Redundant state:MASTER -> BACKUP

==

root@r-40-VM:~# /etc/init.d/iptables-persistent flush
[ ok ] Flushing rules... IPv4... IPv6...done.
root@r-40-VM:~# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
root@r-40-VM:~#

root@r-41-VM:~# /etc/init.d/iptables-persistent flush
[ ok ] Flushing rules... IPv4... IPv6...done.
root@r-41-VM:~# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
root@r-41-VM:~#

root@r-40-VM:~# tcpdump -i eth2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
04:37:50.599495 IP 172.17.0.111.36574 > 225.0.0.50.3780: UDP, length 16
04:37:50.951447 IP 172.17.0.123 > vrrp.mcast.net: AH(spi=0xac11007b,seq=0x20f): 
VRRPv2, Advertisement, vrid 7, prio 1, authtype ah, intvl 1s, length 20
04:37:51.155104 IP 172.17.0.123.39245 > 225.0.0.50.3780: UDP, length 16
04:37:51.600175 IP 172.17.0.111.36574 > 225.0.0.50.3780: UDP, length 16
04:37:51.952787 IP 172.17.0.123 > vrrp.mcast.net: AH(spi=0xac11007b,seq=0x210): 
VRRPv2, Advertisement, vrid 7, prio 1, authtype ah, intvl 1s, length 20

==



was (Author: giraffeforestg):

It recovered in the following.
I think there is a problem in the iptables rules ?

(I do not set the ACL (Default_allow))


15) Flush iptables rule r-40-VM
16) Flush iptables rule r-41-VM
17) Check Redundant state (good)
r-40-VM Redundant state:MASTER
r-41-VM Redundant state:BACKUP

==

root@r-40-VM:~# /etc/init.d/iptables-persistent flush
[ ok ] Flushing rules... IPv4... IPv6...done.
root@r-40-VM:~# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
root@r-40-VM:~#

root@r-41-VM:~# /etc/init.d/iptables-persistent flush
[ ok ] Flushing rules... IPv4... IPv6...done.
root@r-41-VM:~# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain FORWARD (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
root@r-41-VM:~#

root@r-40-VM:~# tcpdump -i eth2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
04:37:50.599495 IP 172.17.0.111.36574 > 225.0.0.50.3780: UDP, length 16
04:37:50.951447 IP 172.17.0.123 > vrrp.mcast.net: AH(spi=0xac11007b,seq=0x20f): 
VRRPv2, Advertisement, vrid 7, prio 1, authtype ah, intvl 1s, length 20
04:37:51.155104 IP 172.17.0.123.39245 > 225.0.0.50.3780: UDP, length 16
04:37:51.600175 IP 172.17.0.111.36574 > 225.0.0.50.3780: UDP, length 16
04:37:51.952787 IP 172.17.0.123 > vrrp.mcast.net: AH(spi=0xac11007b,seq=0x210): 
VRRPv2, Advertisement, vrid 7, prio 1, authtype ah, intvl 1s, length 20

==


> Redundant VPC Virtual Router's state is BACKUP & BACKUP
> ---
>
> Key: CLOUDSTACK-9015
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9015
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: CloudStack master(2015/10/31) 4.6.0-snapshot
> Hypervisor CentOS6/KVM
> SystemVM
> build #654 (2015/10/22 19:27:55)
> http://jenkins.buildacloud.org/job/build-systemvm64-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvm64template-master-4.6.0-kvm.qcow2.bz2
>Reporter: satoru nakaya
>Assignee: Wilder Rodrigues
>Priority: Critical
>
> Steps of reproduce.
> 1)Create VPC (Redundant VPC offering)
> 2)Create tier
> 3)Create VM Instance on this tier
> 4)Check Redundant state (good)
>r-14-VM 

[jira] [Commented] (CLOUDSTACK-9015) Redundant VPC Virtual Router's state is BACKUP & BACKUP

[satoru nakaya (JIRA)]

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

satoru nakaya commented on CLOUDSTACK-9015:
---

Dear Wilder Rodrigues,

In my environment , it is different.

1) Create new VPC (Redundant VPC offering)

2) Create new tier

3) Create new VM Instance on this tier

4) Check Redundant state (good)
r-40-VM Redundant state:MASTER
r-41-VM Redundant state:BACKUP



root@r-40-VM:~# cat /var/log/messages | grep Keep
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: Registering Kernel netlink 
reflector
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: Registering Kernel netlink 
command channel
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: Registering gratuitous ARP 
shared channel
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: Opening file 
'/etc/keepalived/keepalived.conf'.
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: Truncating auth_pass to 8 
characters
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: Configuration is using : 64675 
Bytes
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: Using LinkWatch kernel netlink 
reflector...
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: VRRP_Instance(inside_network) 
Entering BACKUP STATE
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: VRRP_Script(heartbeat) succeeded
Nov  3 00:20:51 r-40-VM Keepalived_healthcheckers[3682]: Registering Kernel 
netlink reflector
Nov  3 00:20:51 r-40-VM Keepalived_healthcheckers[3682]: Registering Kernel 
netlink command channel
Nov  3 00:20:51 r-40-VM Keepalived_healthcheckers[3682]: Opening file 
'/etc/keepalived/keepalived.conf'.
Nov  3 00:20:51 r-40-VM Keepalived_healthcheckers[3682]: Configuration is using 
: 6893 Bytes
Nov  3 00:20:51 r-40-VM Keepalived_healthcheckers[3682]: Using LinkWatch kernel 
netlink reflector...
Nov  3 00:20:55 r-40-VM Keepalived_vrrp[3683]: VRRP_Instance(inside_network) 
Transition to MASTER STATE
Nov  3 00:20:56 r-40-VM Keepalived_vrrp[3683]: VRRP_Instance(inside_network) 
Entering MASTER STATE
root@r-40-VM:~#
root@r-40-VM:~# ip a
1: lo:  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
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:00:df brd ff:ff:ff:ff:ff:ff
inet 169.254.0.223/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:31:06:00:00:1a brd ff:ff:ff:ff:ff:ff
inet 10.0.1.105/24 brd 10.0.1.255 scope global eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:0b:9b:00:04 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.123/24 brd 172.17.0.255 scope global eth2
inet 172.17.0.1/24 brd 172.17.0.255 scope global secondary eth2
root@r-40-VM:~#
root@r-40-VM:~# tcpdump -i eth2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
00:24:18.075586 IP 172.17.0.111.52868 > 225.0.0.50.3780: UDP, length 16
00:24:18.188066 IP 172.17.0.123 > vrrp.mcast.net: AH(spi=0xac11007b,seq=0xc9): 
VRRPv2, Advertisement, vrid 7, prio 1, authtype ah, intvl 1s, length 20
00:24:18.234988 IP 172.17.0.123.36868 > 225.0.0.50.3780: UDP, length 16
00:24:19.077054 IP 172.17.0.111.52868 > 225.0.0.50.3780: UDP, length 16
00:24:19.189476 IP 172.17.0.123 > vrrp.mcast.net: AH(spi=0xac11007b,seq=0xca): 
VRRPv2, Advertisement, vrid 7, prio 1, authtype ah, intvl 1s, length 20
00:24:19.235403 IP 172.17.0.123.36868 > 225.0.0.50.3780: UDP, length 16
00:24:20.078192 IP 172.17.0.111.52868 > 225.0.0.50.3780: UDP, length 16
00:24:20.191015 IP 172.17.0.123 > vrrp.mcast.net: AH(spi=0xac11007b,seq=0xcb): 
VRRPv2, Advertisement, vrid 7, prio 1, authtype ah, intvl 1s, length 20
00:24:20.235856 IP 172.17.0.123.36868 > 225.0.0.50.3780: UDP, length 16
00:24:21.079201 IP 172.17.0.111.52868 > 225.0.0.50.3780: UDP, length 16
00:24:21.193830 IP 172.17.0.123 > vrrp.mcast.net: AH(spi=0xac11007b,seq=0xcc): 
VRRPv2, Advertisement, vrid 7, prio 1, authtype ah, intvl 1s, length 20
00:24:21.235997 IP 172.17.0.123.36868 > 225.0.0.50.3780: UDP, length 16
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel
root@r-40-VM:~#



root@r-41-VM:~# cat /var/log/messages | grep Keep
Nov  3 00:21:41 r-41-VM Keepalived_vrrp[3685]: Registering Kernel netlink 
reflector
Nov  3 00:21:41 r-41-VM Keepalived_vrrp[3685]: Registering Kernel netlink 
command channel
Nov  3 00:21:41 r-41-VM Keepalived_vrrp[3685]: Registering gratuitous ARP 
shared channel
Nov  3 00:21:41 r-41-VM Keepalived_vrrp[3685]: Opening file 
'/etc/keepalived/keepalived.conf'.
Nov  3 00:21:41 r-41-VM Keepalived_vrrp[3685]: Truncating auth_pass to 8 
characters
Nov  3 00:21:41 r-41-VM 

[jira] [Comment Edited] (CLOUDSTACK-9015) Redundant VPC Virtual Router's state is BACKUP & BACKUP

[satoru nakaya (JIRA)]

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

satoru nakaya edited comment on CLOUDSTACK-9015 at 11/3/15 1:08 AM:


Dear Wilder Rodrigues,

In my environment , it is different.

1) Create new VPC (Redundant VPC offering)

2) Create new tier

3) Create new VM Instance on this tier

4) Check Redundant state (good)
r-40-VM Redundant state:MASTER
r-41-VM Redundant state:BACKUP



root@r-40-VM:~# cat /var/log/messages | grep Keep
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: Registering Kernel netlink 
reflector
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: Registering Kernel netlink 
command channel
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: Registering gratuitous ARP 
shared channel
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: Opening file 
'/etc/keepalived/keepalived.conf'.
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: Truncating auth_pass to 8 
characters
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: Configuration is using : 64675 
Bytes
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: Using LinkWatch kernel netlink 
reflector...
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: VRRP_Instance(inside_network) 
Entering BACKUP STATE
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: VRRP_Script(heartbeat) succeeded
Nov  3 00:20:51 r-40-VM Keepalived_healthcheckers[3682]: Registering Kernel 
netlink reflector
Nov  3 00:20:51 r-40-VM Keepalived_healthcheckers[3682]: Registering Kernel 
netlink command channel
Nov  3 00:20:51 r-40-VM Keepalived_healthcheckers[3682]: Opening file 
'/etc/keepalived/keepalived.conf'.
Nov  3 00:20:51 r-40-VM Keepalived_healthcheckers[3682]: Configuration is using 
: 6893 Bytes
Nov  3 00:20:51 r-40-VM Keepalived_healthcheckers[3682]: Using LinkWatch kernel 
netlink reflector...
Nov  3 00:20:55 r-40-VM Keepalived_vrrp[3683]: VRRP_Instance(inside_network) 
Transition to MASTER STATE
Nov  3 00:20:56 r-40-VM Keepalived_vrrp[3683]: VRRP_Instance(inside_network) 
Entering MASTER STATE
root@r-40-VM:~#
root@r-40-VM:~# ip a
1: lo:  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
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:00:df brd ff:ff:ff:ff:ff:ff
inet 169.254.0.223/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:31:06:00:00:1a brd ff:ff:ff:ff:ff:ff
inet 10.0.1.105/24 brd 10.0.1.255 scope global eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:0b:9b:00:04 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.123/24 brd 172.17.0.255 scope global eth2
inet 172.17.0.1/24 brd 172.17.0.255 scope global secondary eth2
root@r-40-VM:~#
root@r-40-VM:~# tcpdump -i eth2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
00:24:18.075586 IP 172.17.0.111.52868 > 225.0.0.50.3780: UDP, length 16
00:24:18.188066 IP 172.17.0.123 > vrrp.mcast.net: AH(spi=0xac11007b,seq=0xc9): 
VRRPv2, Advertisement, vrid 7, prio 1, authtype ah, intvl 1s, length 20
00:24:18.234988 IP 172.17.0.123.36868 > 225.0.0.50.3780: UDP, length 16
00:24:19.077054 IP 172.17.0.111.52868 > 225.0.0.50.3780: UDP, length 16
00:24:19.189476 IP 172.17.0.123 > vrrp.mcast.net: AH(spi=0xac11007b,seq=0xca): 
VRRPv2, Advertisement, vrid 7, prio 1, authtype ah, intvl 1s, length 20
00:24:19.235403 IP 172.17.0.123.36868 > 225.0.0.50.3780: UDP, length 16
00:24:20.078192 IP 172.17.0.111.52868 > 225.0.0.50.3780: UDP, length 16
00:24:20.191015 IP 172.17.0.123 > vrrp.mcast.net: AH(spi=0xac11007b,seq=0xcb): 
VRRPv2, Advertisement, vrid 7, prio 1, authtype ah, intvl 1s, length 20
00:24:20.235856 IP 172.17.0.123.36868 > 225.0.0.50.3780: UDP, length 16
00:24:21.079201 IP 172.17.0.111.52868 > 225.0.0.50.3780: UDP, length 16
00:24:21.193830 IP 172.17.0.123 > vrrp.mcast.net: AH(spi=0xac11007b,seq=0xcc): 
VRRPv2, Advertisement, vrid 7, prio 1, authtype ah, intvl 1s, length 20
00:24:21.235997 IP 172.17.0.123.36868 > 225.0.0.50.3780: UDP, length 16
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel
root@r-40-VM:~#



root@r-41-VM:~# cat /var/log/messages | grep Keep
Nov  3 00:21:41 r-41-VM Keepalived_vrrp[3685]: Registering Kernel netlink 
reflector
Nov  3 00:21:41 r-41-VM Keepalived_vrrp[3685]: Registering Kernel netlink 
command channel
Nov  3 00:21:41 r-41-VM Keepalived_vrrp[3685]: Registering gratuitous ARP 
shared channel
Nov  3 00:21:41 r-41-VM Keepalived_vrrp[3685]: Opening file 
'/etc/keepalived/keepalived.conf'.
Nov  3 00:21:41 r-41-VM Keepalived_vrrp[3685]: Truncating 

[jira] [Comment Edited] (CLOUDSTACK-9015) Redundant VPC Virtual Router's state is BACKUP & BACKUP

[satoru nakaya (JIRA)]

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

satoru nakaya edited comment on CLOUDSTACK-9015 at 11/3/15 2:57 AM:


Dear Wilder Rodrigues,

In my environment , it is different.

1) Create new VPC (Redundant VPC offering)

2) Create new tier

3) Create new VM Instance on this tier

4) Check Redundant state (good)
r-40-VM Redundant state:MASTER
r-41-VM Redundant state:BACKUP



root@r-40-VM:~# cat /var/log/messages | grep Keep
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: Registering Kernel netlink 
reflector
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: Registering Kernel netlink 
command channel
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: Registering gratuitous ARP 
shared channel
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: Opening file 
'/etc/keepalived/keepalived.conf'.
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: Truncating auth_pass to 8 
characters
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: Configuration is using : 64675 
Bytes
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: Using LinkWatch kernel netlink 
reflector...
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: VRRP_Instance(inside_network) 
Entering BACKUP STATE
Nov  3 00:20:51 r-40-VM Keepalived_vrrp[3683]: VRRP_Script(heartbeat) succeeded
Nov  3 00:20:51 r-40-VM Keepalived_healthcheckers[3682]: Registering Kernel 
netlink reflector
Nov  3 00:20:51 r-40-VM Keepalived_healthcheckers[3682]: Registering Kernel 
netlink command channel
Nov  3 00:20:51 r-40-VM Keepalived_healthcheckers[3682]: Opening file 
'/etc/keepalived/keepalived.conf'.
Nov  3 00:20:51 r-40-VM Keepalived_healthcheckers[3682]: Configuration is using 
: 6893 Bytes
Nov  3 00:20:51 r-40-VM Keepalived_healthcheckers[3682]: Using LinkWatch kernel 
netlink reflector...
Nov  3 00:20:55 r-40-VM Keepalived_vrrp[3683]: VRRP_Instance(inside_network) 
Transition to MASTER STATE
Nov  3 00:20:56 r-40-VM Keepalived_vrrp[3683]: VRRP_Instance(inside_network) 
Entering MASTER STATE
root@r-40-VM:~#
root@r-40-VM:~# ip a
1: lo:  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
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 0e:00:a9:fe:00:df brd ff:ff:ff:ff:ff:ff
inet 169.254.0.223/16 brd 169.254.255.255 scope global eth0
3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 06:31:06:00:00:1a brd ff:ff:ff:ff:ff:ff
inet 10.0.1.105/24 brd 10.0.1.255 scope global eth1
4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 02:00:0b:9b:00:04 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.123/24 brd 172.17.0.255 scope global eth2
inet 172.17.0.1/24 brd 172.17.0.255 scope global secondary eth2
root@r-40-VM:~#
root@r-40-VM:~# tcpdump -i eth2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes
00:24:18.075586 IP 172.17.0.111.52868 > 225.0.0.50.3780: UDP, length 16
00:24:18.188066 IP 172.17.0.123 > vrrp.mcast.net: AH(spi=0xac11007b,seq=0xc9): 
VRRPv2, Advertisement, vrid 7, prio 1, authtype ah, intvl 1s, length 20
00:24:18.234988 IP 172.17.0.123.36868 > 225.0.0.50.3780: UDP, length 16
00:24:19.077054 IP 172.17.0.111.52868 > 225.0.0.50.3780: UDP, length 16
00:24:19.189476 IP 172.17.0.123 > vrrp.mcast.net: AH(spi=0xac11007b,seq=0xca): 
VRRPv2, Advertisement, vrid 7, prio 1, authtype ah, intvl 1s, length 20
00:24:19.235403 IP 172.17.0.123.36868 > 225.0.0.50.3780: UDP, length 16
00:24:20.078192 IP 172.17.0.111.52868 > 225.0.0.50.3780: UDP, length 16
00:24:20.191015 IP 172.17.0.123 > vrrp.mcast.net: AH(spi=0xac11007b,seq=0xcb): 
VRRPv2, Advertisement, vrid 7, prio 1, authtype ah, intvl 1s, length 20
00:24:20.235856 IP 172.17.0.123.36868 > 225.0.0.50.3780: UDP, length 16
00:24:21.079201 IP 172.17.0.111.52868 > 225.0.0.50.3780: UDP, length 16
00:24:21.193830 IP 172.17.0.123 > vrrp.mcast.net: AH(spi=0xac11007b,seq=0xcc): 
VRRPv2, Advertisement, vrid 7, prio 1, authtype ah, intvl 1s, length 20
00:24:21.235997 IP 172.17.0.123.36868 > 225.0.0.50.3780: UDP, length 16
^C
12 packets captured
12 packets received by filter
0 packets dropped by kernel
root@r-40-VM:~#



root@r-41-VM:~# cat /var/log/messages | grep Keep
Nov  3 00:21:41 r-41-VM Keepalived_vrrp[3685]: Registering Kernel netlink 
reflector
Nov  3 00:21:41 r-41-VM Keepalived_vrrp[3685]: Registering Kernel netlink 
command channel
Nov  3 00:21:41 r-41-VM Keepalived_vrrp[3685]: Registering gratuitous ARP 
shared channel
Nov  3 00:21:41 r-41-VM Keepalived_vrrp[3685]: Opening file 
'/etc/keepalived/keepalived.conf'.
Nov  3 00:21:41 r-41-VM Keepalived_vrrp[3685]: Truncating 

[jira] [Created] (CLOUDSTACK-9015) Redundant VPC Virtual Router's state is BACKUP & BACKUP

[satoru nakaya (JIRA)]

satoru nakaya created CLOUDSTACK-9015:
-

 Summary: Redundant VPC Virtual Router's state is BACKUP & BACKUP
 Key: CLOUDSTACK-9015
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9015
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.6.0
 Environment: CloudStack master(2015/10/31) 4.6.0-snapshot

Hypervisor CentOS6/KVM

SystemVM
build #654 (2015/10/22 19:27:55)
http://jenkins.buildacloud.org/job/build-systemvm64-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvm64template-master-4.6.0-kvm.qcow2.bz2
Reporter: satoru nakaya


Steps of reproduce.

1)Create VPC (Redundant VPC offering)

2)Create tier

3)Create VM Instance on this tier

4)Check Redundant state
   r-14-VM Redundant state:MASTER
   r-15-VM Redundant state:BACKUP

5) r-14-VM Reboot Router

6)Check Redundant state
   r-14-VM Redundant state:BACKUP
   r-15-VM Redundant state:MASTER

7) r-15-VM Reboot Router

8)Check Redundant state
   r-14-VM Redundant state:BACKUP
   r-15-VM Redundant state:BACKUP

9)Check Log(r-14-VM's /var/log/messages)

Nov  1 00:46:29 r-14-VM Keepalived_vrrp[3711]: VRRP_Instance(inside_network) 
sending 0 priority
Nov  1 00:47:34 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
Nov  1 00:47:34 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
function error
Nov  1 00:47:53 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
function error
Nov  1 00:47:53 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
Nov  1 00:47:54 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
function error
Nov  1 00:47:54 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error

10)Check Log(r-15-VM's /var/log/messages)

Nov  1 00:49:19 r-15-VM Keepalived_vrrp[3682]: VRRP_Instance(inside_network) 
sending 0 priority
Nov  1 00:50:25 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
Nov  1 00:50:25 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
function error
Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
function error
Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
function error
Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error




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

[jira] [Updated] (CLOUDSTACK-9015) Redundant VPC Virtual Router's state is BACKUP & BACKUP

[satoru nakaya (JIRA)]

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

satoru nakaya updated CLOUDSTACK-9015:
--
Description: 
Steps of reproduce.

1)Create VPC (Redundant VPC offering)

2)Create tier

3)Create VM Instance on this tier

4)Check Redundant state (good)
   r-14-VM Redundant state:MASTER
   r-15-VM Redundant state:BACKUP

5) Reboot Router r-14-VM

6)Check Redundant state (good)
   r-14-VM Redundant state:BACKUP
   r-15-VM Redundant state:MASTER

7) Reboot Router r-15-VM

8)Check Redundant state (bad)
   r-14-VM Redundant state:BACKUP
   r-15-VM Redundant state:BACKUP

9)Check Log(r-14-VM's /var/log/messages)

Nov  1 00:46:29 r-14-VM Keepalived_vrrp[3711]: VRRP_Instance(inside_network) 
sending 0 priority
Nov  1 00:47:34 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
Nov  1 00:47:34 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
function error
Nov  1 00:47:53 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
function error
Nov  1 00:47:53 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
Nov  1 00:47:54 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
function error
Nov  1 00:47:54 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error

10)Check Log(r-15-VM's /var/log/messages)

Nov  1 00:49:19 r-15-VM Keepalived_vrrp[3682]: VRRP_Instance(inside_network) 
sending 0 priority
Nov  1 00:50:25 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
Nov  1 00:50:25 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
function error
Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
function error
Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
function error
Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error


  was:
Steps of reproduce.

1)Create VPC (Redundant VPC offering)

2)Create tier

3)Create VM Instance on this tier

4)Check Redundant state
   r-14-VM Redundant state:MASTER
   r-15-VM Redundant state:BACKUP

5) r-14-VM Reboot Router

6)Check Redundant state
   r-14-VM Redundant state:BACKUP
   r-15-VM Redundant state:MASTER

7) r-15-VM Reboot Router

8)Check Redundant state
   r-14-VM Redundant state:BACKUP
   r-15-VM Redundant state:BACKUP

9)Check Log(r-14-VM's /var/log/messages)

Nov  1 00:46:29 r-14-VM Keepalived_vrrp[3711]: VRRP_Instance(inside_network) 
sending 0 priority
Nov  1 00:47:34 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
Nov  1 00:47:34 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
function error
Nov  1 00:47:53 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
function error
Nov  1 00:47:53 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error
Nov  1 00:47:54 r-14-VM Keepalived_healthcheckers[2178]: Netlink: filter 
function error
Nov  1 00:47:54 r-14-VM Keepalived_vrrp[2179]: Netlink: filter function error

10)Check Log(r-15-VM's /var/log/messages)

Nov  1 00:49:19 r-15-VM Keepalived_vrrp[3682]: VRRP_Instance(inside_network) 
sending 0 priority
Nov  1 00:50:25 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
Nov  1 00:50:25 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
function error
Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
function error
Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error
Nov  1 00:50:45 r-15-VM Keepalived_healthcheckers[2178]: Netlink: filter 
function error
Nov  1 00:50:45 r-15-VM Keepalived_vrrp[2179]: Netlink: filter function error



> Redundant VPC Virtual Router's state is BACKUP & BACKUP
> ---
>
> Key: CLOUDSTACK-9015
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9015
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.6.0
> Environment: CloudStack master(2015/10/31) 4.6.0-snapshot
> Hypervisor CentOS6/KVM
> SystemVM
> build #654 (2015/10/22 19:27:55)
> http://jenkins.buildacloud.org/job/build-systemvm64-master/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvm64template-master-4.6.0-kvm.qcow2.bz2
>Reporter: satoru nakaya
>
> Steps of reproduce.
> 1)Create VPC (Redundant VPC offering)
> 2)Create tier
> 3)Create VM Instance on this tier
> 4)Check Redundant state (good)
>r-14-VM Redundant state:MASTER
>r-15-VM Redundant state:BACKUP
> 5) Reboot Router r-14-VM
> 6)Check Redundant state (good)
>r-14-VM Redundant state:BACKUP
>r-15-VM Redundant state:MASTER
> 7) Reboot Router r-15-VM
> 8)Check Redundant state (bad)
>r-14-VM Redundant state:BACKUP
>r-15-VM Redundant state:BACKUP
> 9)Check Log(r-14-VM's /var/log/messages)
> Nov  1 00:46:29 

[jira] [Created] (CLOUDSTACK-8838) [KVM] agent setup failed when physical interface name is in ensX format (CentOS7)

[satoru nakaya (JIRA)]

satoru nakaya created CLOUDSTACK-8838:
-

 Summary: [KVM] agent setup failed when physical interface name is 
in ensX format (CentOS7)
 Key: CLOUDSTACK-8838
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8838
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.5.2
 Environment:  CloudStack 4.5.2 
(http://packages.shapeblue.com/cloudstack/upstream/centos7/4.5)
 CentOS 7.1.1503 / KVM
 mariadb-5.5.44-1
Reporter: satoru nakaya


[KVM] agent setup failed when physical interface name is in ensX format 
(CentOS7)

My environment:
 CloudStack 4.5.2 
(http://packages.shapeblue.com/cloudstack/upstream/centos7/4.5)
 CentOS 7.1.1503 / KVM
 mariadb-5.5.44-1

management.log:

2015-09-12 08:19:41,930 WARN  [o.a.c.alerts] 
(AgentConnectTaskPool-2:ctx-4925d5ec)  alertType:: 7 // dataCenterId:: 1 // 
podId:: 1 // clusterId:: null // message:: Incorrect Network setup on agent, 
Reinitialize agent after network names are setup, details : Can not find 
network: cloudbr1

[root@acs ~]# ip a
1: lo:  mtu 65536 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
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: ens32:  mtu 1500 qdisc pfifo_fast master 
cloudbr0 state UP qlen 1000
link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff
inet6 fe80::20c:29ff:fea9:93f/64 scope link
   valid_lft forever preferred_lft forever
3: ens33:  mtu 1500 qdisc pfifo_fast master 
cloudbr1 state UP qlen 1000
link/ether 00:0c:29:a9:09:49 brd ff:ff:ff:ff:ff:ff
inet6 fe80::20c:29ff:fea9:949/64 scope link
   valid_lft forever preferred_lft forever
4: cloudbr0:  mtu 1500 qdisc noqueue state UP
link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff
inet 10.0.0.30/24 brd 10.0.0.255 scope global cloudbr0
   valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fea9:93f/64 scope link
   valid_lft forever preferred_lft forever
5: cloudbr1:  mtu 1500 qdisc noqueue state UP
link/ether 00:0c:29:a9:09:49 brd ff:ff:ff:ff:ff:ff
inet6 fe80::20c:29ff:fea9:949/64 scope link
   valid_lft forever preferred_lft forever
6: virbr0:  mtu 1500 qdisc noqueue state DOWN
link/ether 52:54:00:99:14:38 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
   valid_lft forever preferred_lft forever
7: virbr0-nic:  mtu 1500 qdisc pfifo_fast master virbr0 
state DOWN qlen 500
link/ether 52:54:00:99:14:38 brd ff:ff:ff:ff:ff:ff
8: cloud0:  mtu 1500 qdisc noqueue state 
UNKNOWN
link/ether 72:0f:e1:35:ac:6b brd ff:ff:ff:ff:ff:ff
inet 169.254.0.1/16 scope global cloud0
   valid_lft forever preferred_lft forever
inet6 fe80::700f:e1ff:fe35:ac6b/64 scope link
   valid_lft forever preferred_lft forever
[root@acs ~]#


workaround:

Don't use ensX format.

add net.ifnames=0 biosdevname=0 to GRUB_CMDLINE_LINUX

[root@acs ~]# vi /etc/default/grub
  :
GRUB_CMDLINE_LINUX="vconsole.keymap=jp106 crashkernel=auto 
vconsole.font=latarcyrheb-sun16 rhgb quiet net.ifnames=0 biosdevname=0"
  :
[root@acs ~]# grub2-mkconfig -o /boot/grub2/grub.cfg

And
Edit /etc/sysconfig/network-scripts/ifcfg-ensX

 ensX-> ethX

[root@acs ~]# reboot

   :

[root@acs ~]# ip a
1: lo:  mtu 65536 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
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast master 
cloudbr0 state UP qlen 1000
link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff
inet6 fe80::20c:29ff:fea9:93f/64 scope link
   valid_lft forever preferred_lft forever
3: eth1:  mtu 1500 qdisc pfifo_fast master 
cloudbr1 state UP qlen 1000
link/ether 00:0c:29:a9:09:49 brd ff:ff:ff:ff:ff:ff
inet6 fe80::20c:29ff:fea9:949/64 scope link
   valid_lft forever preferred_lft forever
4: cloudbr0:  mtu 1500 qdisc noqueue state UP
link/ether 00:0c:29:a9:09:3f brd ff:ff:ff:ff:ff:ff
inet 10.0.0.30/24 brd 10.0.0.255 scope global cloudbr0
   valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fea9:93f/64 scope link
   valid_lft forever preferred_lft forever
5: cloudbr1:  mtu 1500 qdisc noqueue state UP

[jira] [Commented] (CLOUDSTACK-8503) Couldn't change the nic driver of router-vm from E1000 to Vmxnet3.

[satoru nakaya (JIRA)]

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

satoru nakaya commented on CLOUDSTACK-8503:
---

Reply to myself.

This approach was successful.

API(addResourceDetail)
http://mail-archives.apache.org/mod_mbox/cloudstack-users/201409.mbox/%3c54213b18.7020...@gmail.com%3E

Perhaps we don't need to set global configuration ?


 Couldn't change the nic driver of router-vm from E1000 to Vmxnet3.
 --

 Key: CLOUDSTACK-8503
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8503
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, SystemVM
Affects Versions: 4.3.2
 Environment: management: Apache CloudStack4.3.2 / CentOS 6.5 64bit
 host: VMware vSphere 5.1 (vNetwork Standard Switch)
Reporter: satoru nakaya

 I want to change the nic driver of router-vm from E1000 to Vmxnet3.
 1.set the global configuration
  vmware.systemvm.nic.device.type : Vmxnet3
 2.management-server restart
 3.router-vm stop - start
   result : nic driver not changed
 4.router-vm delete - create
   result : nic driver not changed



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

[jira] [Created] (CLOUDSTACK-8503) Couldn't change the nic driver of router-vm from E1000 to Vmxnet3.

[satoru nakaya (JIRA)]

satoru nakaya created CLOUDSTACK-8503:
-

 Summary: Couldn't change the nic driver of router-vm from E1000 to 
Vmxnet3.
 Key: CLOUDSTACK-8503
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8503
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: SystemVM
Affects Versions: 4.3.2
 Environment: Apache CloudStack4.3.2
VMware vSphere 5.1
Reporter: satoru nakaya


I want to change the nic driver of router-vm from E1000 to Vmxnet3.

1.set the global configuration

 vmware.systemvm.nic.device.type : Vmxnet3

2.management-server restart

3.router-vm stop - start

  result : nic driver not changed

4.router-vm delete - create

  result : nic driver not changed




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

[jira] [Updated] (CLOUDSTACK-8503) Couldn't change the nic driver of router-vm from E1000 to Vmxnet3.

[satoru nakaya (JIRA)]

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

satoru nakaya updated CLOUDSTACK-8503:
--
Environment: 
Apache CloudStack4.3.2
VMware vSphere 5.1 (vNetwork Standard Switch)

  was:
Apache CloudStack4.3.2
VMware vSphere 5.1


 Couldn't change the nic driver of router-vm from E1000 to Vmxnet3.
 --

 Key: CLOUDSTACK-8503
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8503
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: SystemVM
Affects Versions: 4.3.2
 Environment: Apache CloudStack4.3.2
 VMware vSphere 5.1 (vNetwork Standard Switch)
Reporter: satoru nakaya

 I want to change the nic driver of router-vm from E1000 to Vmxnet3.
 1.set the global configuration
  vmware.systemvm.nic.device.type : Vmxnet3
 2.management-server restart
 3.router-vm stop - start
   result : nic driver not changed
 4.router-vm delete - create
   result : nic driver not changed



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

[jira] [Updated] (CLOUDSTACK-8503) Couldn't change the nic driver of router-vm from E1000 to Vmxnet3.

[satoru nakaya (JIRA)]

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

satoru nakaya updated CLOUDSTACK-8503:
--
Environment: 
management: Apache CloudStack4.3.2 / CentOS 6.5 64bit
host: VMware vSphere 5.1 (vNetwork Standard Switch)

  was:
Apache CloudStack4.3.2
VMware vSphere 5.1 (vNetwork Standard Switch)


 Couldn't change the nic driver of router-vm from E1000 to Vmxnet3.
 --

 Key: CLOUDSTACK-8503
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8503
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: SystemVM
Affects Versions: 4.3.2
 Environment: management: Apache CloudStack4.3.2 / CentOS 6.5 64bit
 host: VMware vSphere 5.1 (vNetwork Standard Switch)
Reporter: satoru nakaya

 I want to change the nic driver of router-vm from E1000 to Vmxnet3.
 1.set the global configuration
  vmware.systemvm.nic.device.type : Vmxnet3
 2.management-server restart
 3.router-vm stop - start
   result : nic driver not changed
 4.router-vm delete - create
   result : nic driver not changed



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

[jira] [Updated] (CLOUDSTACK-8503) Couldn't change the nic driver of router-vm from E1000 to Vmxnet3.

[satoru nakaya (JIRA)]

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

satoru nakaya updated CLOUDSTACK-8503:
--
Component/s: Management Server

 Couldn't change the nic driver of router-vm from E1000 to Vmxnet3.
 --

 Key: CLOUDSTACK-8503
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8503
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server, SystemVM
Affects Versions: 4.3.2
 Environment: management: Apache CloudStack4.3.2 / CentOS 6.5 64bit
 host: VMware vSphere 5.1 (vNetwork Standard Switch)
Reporter: satoru nakaya

 I want to change the nic driver of router-vm from E1000 to Vmxnet3.
 1.set the global configuration
  vmware.systemvm.nic.device.type : Vmxnet3
 2.management-server restart
 3.router-vm stop - start
   result : nic driver not changed
 4.router-vm delete - create
   result : nic driver not changed



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

[jira] [Comment Edited] (CLOUDSTACK-7410) OVS distributed routing + KVM / NameError: name 'configure_ovs_bridge_for_routing_policies' is not defined

[satoru nakaya (JIRA)]

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

satoru nakaya edited comment on CLOUDSTACK-7410 at 5/12/15 4:04 AM:


Hi Mr. Aleksandr

 So on Xen everything is ok but on KVM not ?

yes it is.

but xenserver+ovs have other problem.
https://issues.apache.org/jira/browse/CLOUDSTACK-6779




was (Author: giraffeforestg):
Hi Mr. Aleksandr

 So on Xen everything is ok but on KVM not ?

yes it is.

* but xenserver+ovs have other problem.
  https://issues.apache.org/jira/browse/CLOUDSTACK-6779



 OVS distributed routing + KVM / NameError: name 
 'configure_ovs_bridge_for_routing_policies' is not defined
 --

 Key: CLOUDSTACK-7410
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7410
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.0
 Environment: Environment:
  CloudStack 4.4.0
  KVM(CentOS6.4)
  Open vSwitch 1.11.0
  VPC Offering
:
   Connectivity:Ovs
   DistributedRouter:On
  Network Offering
:
   Virtual Networking:Ovs
Reporter: satoru nakaya
 Attachments: computenode_agent.zip, computenode_messages.zip, 
 management-server.zip


 Error is output following when you deploy VM instances in VPC.
 2014-08-03 14:52:25,608 DEBUG [c.c.a.t.Request] (AgentManager-Handler-5:null) 
 Seq 8-7588002422165864587: Processing: { Ans: , MgmtId: 52236007434, via: 8, 
 Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.Answer:{result:false,details:Traceback (most 
 recent call last): File 
 \/usr/share/cloudstack-common/scripts/vm/network/vnet/ovstunnel.py\, line 
 302, in configure_ovs_bridge_for_routing_policies(bridge, config)NameError: 
 name 'configure_ovs_bridge_for_routing_policies' is not defined,wait:0}}] }
 2014-08-03 14:52:25,608 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Seq 
 8-7588002422165864587: Received: { Ans: , MgmtId: 52236007434, via: 8, Ver: 
 v1, Flags: 10, { Answer } }
 2014-08-03 14:52:25,608 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 update the host 8 with latest routing policies.
 2014-08-03 14:52:25,609 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 send VPC routing policy change update to host : 8. But moving on with sending 
 the updates to the rest of the hosts.
 :
 2014-08-03 14:52:25,622 ERROR [c.c.v.VirtualMachineManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 start instance VM[User|i-2-40-VM]
 com.cloud.utils.exception.CloudRuntimeException: Failed to add VPC router 
 VM[DomainRouter|r-38-VM] to guest network 
 Ntwk[95583273-9dc0-4569-be29-706b28543932|Guest|15]
 at 
 com.cloud.network.element.VpcVirtualRouterElement.implement(VpcVirtualRouterElement.java:188)



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

[jira] [Comment Edited] (CLOUDSTACK-7410) OVS distributed routing + KVM / NameError: name 'configure_ovs_bridge_for_routing_policies' is not defined

[satoru nakaya (JIRA)]

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

satoru nakaya edited comment on CLOUDSTACK-7410 at 5/12/15 4:04 AM:


Hi Mr. Aleksandr

 So on Xen everything is ok but on KVM not ?

yes it is.

* but xenserver+ovs have other problem.
  https://issues.apache.org/jira/browse/CLOUDSTACK-6779




was (Author: giraffeforestg):
Hi Mr. Aleksandr

 So on Xen everything is ok but on KVM not ?

yes it is.

# but xenserver+ovs have other problem.
  https://issues.apache.org/jira/browse/CLOUDSTACK-6779



 OVS distributed routing + KVM / NameError: name 
 'configure_ovs_bridge_for_routing_policies' is not defined
 --

 Key: CLOUDSTACK-7410
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7410
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.0
 Environment: Environment:
  CloudStack 4.4.0
  KVM(CentOS6.4)
  Open vSwitch 1.11.0
  VPC Offering
:
   Connectivity:Ovs
   DistributedRouter:On
  Network Offering
:
   Virtual Networking:Ovs
Reporter: satoru nakaya
 Attachments: computenode_agent.zip, computenode_messages.zip, 
 management-server.zip


 Error is output following when you deploy VM instances in VPC.
 2014-08-03 14:52:25,608 DEBUG [c.c.a.t.Request] (AgentManager-Handler-5:null) 
 Seq 8-7588002422165864587: Processing: { Ans: , MgmtId: 52236007434, via: 8, 
 Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.Answer:{result:false,details:Traceback (most 
 recent call last): File 
 \/usr/share/cloudstack-common/scripts/vm/network/vnet/ovstunnel.py\, line 
 302, in configure_ovs_bridge_for_routing_policies(bridge, config)NameError: 
 name 'configure_ovs_bridge_for_routing_policies' is not defined,wait:0}}] }
 2014-08-03 14:52:25,608 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Seq 
 8-7588002422165864587: Received: { Ans: , MgmtId: 52236007434, via: 8, Ver: 
 v1, Flags: 10, { Answer } }
 2014-08-03 14:52:25,608 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 update the host 8 with latest routing policies.
 2014-08-03 14:52:25,609 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 send VPC routing policy change update to host : 8. But moving on with sending 
 the updates to the rest of the hosts.
 :
 2014-08-03 14:52:25,622 ERROR [c.c.v.VirtualMachineManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 start instance VM[User|i-2-40-VM]
 com.cloud.utils.exception.CloudRuntimeException: Failed to add VPC router 
 VM[DomainRouter|r-38-VM] to guest network 
 Ntwk[95583273-9dc0-4569-be29-706b28543932|Guest|15]
 at 
 com.cloud.network.element.VpcVirtualRouterElement.implement(VpcVirtualRouterElement.java:188)



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

[jira] [Commented] (CLOUDSTACK-7410) OVS distributed routing + KVM / NameError: name 'configure_ovs_bridge_for_routing_policies' is not defined

[satoru nakaya (JIRA)]

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

satoru nakaya commented on CLOUDSTACK-7410:
---

Hi Mr. Aleksandr

 So on Xen everything is ok but on KVM not ?

yes it is.

# but xenserver+ovs have other problem.
  https://issues.apache.org/jira/browse/CLOUDSTACK-6779



 OVS distributed routing + KVM / NameError: name 
 'configure_ovs_bridge_for_routing_policies' is not defined
 --

 Key: CLOUDSTACK-7410
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7410
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.0
 Environment: Environment:
  CloudStack 4.4.0
  KVM(CentOS6.4)
  Open vSwitch 1.11.0
  VPC Offering
:
   Connectivity:Ovs
   DistributedRouter:On
  Network Offering
:
   Virtual Networking:Ovs
Reporter: satoru nakaya
 Attachments: computenode_agent.zip, computenode_messages.zip, 
 management-server.zip


 Error is output following when you deploy VM instances in VPC.
 2014-08-03 14:52:25,608 DEBUG [c.c.a.t.Request] (AgentManager-Handler-5:null) 
 Seq 8-7588002422165864587: Processing: { Ans: , MgmtId: 52236007434, via: 8, 
 Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.Answer:{result:false,details:Traceback (most 
 recent call last): File 
 \/usr/share/cloudstack-common/scripts/vm/network/vnet/ovstunnel.py\, line 
 302, in configure_ovs_bridge_for_routing_policies(bridge, config)NameError: 
 name 'configure_ovs_bridge_for_routing_policies' is not defined,wait:0}}] }
 2014-08-03 14:52:25,608 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Seq 
 8-7588002422165864587: Received: { Ans: , MgmtId: 52236007434, via: 8, Ver: 
 v1, Flags: 10, { Answer } }
 2014-08-03 14:52:25,608 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 update the host 8 with latest routing policies.
 2014-08-03 14:52:25,609 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 send VPC routing policy change update to host : 8. But moving on with sending 
 the updates to the rest of the hosts.
 :
 2014-08-03 14:52:25,622 ERROR [c.c.v.VirtualMachineManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 start instance VM[User|i-2-40-VM]
 com.cloud.utils.exception.CloudRuntimeException: Failed to add VPC router 
 VM[DomainRouter|r-38-VM] to guest network 
 Ntwk[95583273-9dc0-4569-be29-706b28543932|Guest|15]
 at 
 com.cloud.network.element.VpcVirtualRouterElement.implement(VpcVirtualRouterElement.java:188)



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

[jira] [Closed] (CLOUDSTACK-8402) Adding the KVM host to management server is failing (java8)

[satoru nakaya (JIRA)]

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

satoru nakaya closed CLOUDSTACK-8402.
-
   Resolution: Fixed
Fix Version/s: 4.6.0

 Adding the KVM host to management server is failing (java8)
 ---

 Key: CLOUDSTACK-8402
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8402
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.5.0
 Environment: Apache CloudStack 4.5.1
 CentOS 6.6 64bit KVM
Reporter: satoru nakaya
 Fix For: 4.6.0


 [root@acs45-kvm02 ~]# cat cloudstack-agent.err
 :
 25/04/2015 16:24:00 2964 jsvc.exec error: Cannot load daemon
 25/04/2015 16:24:00 2963 jsvc.exec error: Service exit with a return value of 
 3
 Cause of the failure is because java8 is installed.
 cloudstack-agent is in need of java7.
 but, java8 is installed by cloudstack-agent dependency resolution.
 Dependency is broken ?
 [root@acs45-kvm02 ~]# yum install cloudstack-agent --nogpgcheck
 Loaded plugins: fastestmirror, security
 Setting up Install Process
 Determining fastest mirrors
:
 -- Finished Dependency Resolution
 Dependencies Resolved
 
  PackageArch  Version 
   Repository Size
 
 Installing:
  cloudstack-agent   x86_644.5.1-SNAPSHOT.el6  
   cloudstack 48 M
 Installing for dependencies:
  cloudstack-common  x86_644.5.1-SNAPSHOT.el6  
   cloudstack109 M
  ipset  x86_646.11-3.el6  
   base   63 k
  jakarta-commons-daemon x86_641:1.0.1-8.9.el6 
   base   45 k
  jakarta-commons-daemon-jsvcx86_641:1.0.1-8.9.el6 
   base   27 k
  java-1.5.0-gcj x86_641.5.0.0-29.1.el6
   base  139 k
  java-1.8.0-openjdk x86_64
 1:1.8.0.45-28.b13.el6_6   updates   187 k
  java-1.8.0-openjdk-headlessx86_64
 1:1.8.0.45-28.b13.el6_6   updates32 M
  java_cup   x86_641:0.10k-5.el6   
   base  197 k
  libart_lgplx86_642.3.20-5.1.el6  
   base   65 k
  libgcj x86_644.4.7-11.el6
   base   19 M
  libmnl x86_641.0.2-3.el6 
   base   21 k
  libvirt-python x86_640.10.2-46.el6_6.4   
   updates   497 k
  sinjdocx86_640.5-9.1.el6 
   base  705 k
 Transaction Summary
 
 Install  14 Package(s)
 Total download size: 209 M
 Installed size: 333 M
 Is this ok [y/N]: N
 workaround
 [root@acs45-kvm02 ~]# yum install java-1.7.0-openjdk
 [root@acs45-kvm02 ~]# yum install cloudstack-agent
 Loaded plugins: fastestmirror, security
 Setting up Install Process
 Determining fastest mirrors
:
 -- Finished Dependency Resolution
 Dependencies Resolved
 
  Package  ArchVersion 
 Repository   Size
 
 Installing:
  cloudstack-agent x86_64  
 4.5.1-SNAPSHOT.el6  cloudstack   48 M
 Installing for dependencies:
  cloudstack-commonx86_64  
 4.5.1-SNAPSHOT.el6  cloudstack  109 M
  ipsetx86_64  6.11-3.el6  
 base 63 k
  jakarta-commons-daemon   

[jira] [Created] (CLOUDSTACK-8402) Adding the KVM host to management server is failing (java8)

[satoru nakaya (JIRA)]

satoru nakaya created CLOUDSTACK-8402:
-

 Summary: Adding the KVM host to management server is failing 
(java8)
 Key: CLOUDSTACK-8402
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8402
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: KVM
Affects Versions: 4.5.0
 Environment: Apache CloudStack 4.5.1
CentOS 6.6 64bit KVM
Reporter: satoru nakaya


# cat cloudstack-agent.err
:
25/04/2015 16:24:00 2964 jsvc.exec error: Cannot load daemon
25/04/2015 16:24:00 2963 jsvc.exec error: Service exit with a return value of 3


Cause of the failure is because java8 is installed.
cloudstack-agent is in need of java7.

but, java8 is installed by cloudstack-agent dependency resolution.

Dependency is broken ?

[root@acs45-kvm02 ~]# yum install cloudstack-agent --nogpgcheck
Loaded plugins: fastestmirror, security
Setting up Install Process
Determining fastest mirrors
   :

-- Finished Dependency Resolution

Dependencies Resolved


 PackageArch  Version   
Repository Size

Installing:
 cloudstack-agent   x86_644.5.1-SNAPSHOT.el6
cloudstack 48 M
Installing for dependencies:
 cloudstack-common  x86_644.5.1-SNAPSHOT.el6
cloudstack109 M
 ipset  x86_646.11-3.el6
base   63 k
 jakarta-commons-daemon x86_641:1.0.1-8.9.el6   
base   45 k
 jakarta-commons-daemon-jsvcx86_641:1.0.1-8.9.el6   
base   27 k
 java-1.5.0-gcj x86_641.5.0.0-29.1.el6  
base  139 k
 java-1.8.0-openjdk x86_64
1:1.8.0.45-28.b13.el6_6   updates   187 k
 java-1.8.0-openjdk-headlessx86_64
1:1.8.0.45-28.b13.el6_6   updates32 M
 java_cup   x86_641:0.10k-5.el6 
base  197 k
 libart_lgplx86_642.3.20-5.1.el6
base   65 k
 libgcj x86_644.4.7-11.el6  
base   19 M
 libmnl x86_641.0.2-3.el6   
base   21 k
 libvirt-python x86_640.10.2-46.el6_6.4 
updates   497 k
 sinjdocx86_640.5-9.1.el6   
base  705 k

Transaction Summary

Install  14 Package(s)

Total download size: 209 M
Installed size: 333 M
Is this ok [y/N]: N




workaround

[root@acs45-kvm02 ~]# yum install java-1.7.0-openjdk
[root@acs45-kvm02 ~]# yum install cloudstack-agent
Loaded plugins: fastestmirror, security
Setting up Install Process
Determining fastest mirrors
   :

-- Finished Dependency Resolution

Dependencies Resolved


 Package  ArchVersion   
  Repository   Size

Installing:
 cloudstack-agent x86_64  
4.5.1-SNAPSHOT.el6  cloudstack   48 M
Installing for dependencies:
 cloudstack-commonx86_64  
4.5.1-SNAPSHOT.el6  cloudstack  109 M
 ipsetx86_64  6.11-3.el6
  base 63 k
 jakarta-commons-daemon   x86_64  1:1.0.1-8.9.el6   
  base 45 k
 jakarta-commons-daemon-jsvc  x86_64  1:1.0.1-8.9.el6   
  base 27 k
 java-1.5.0-gcj   x86_64  1.5.0.0-29.1.el6  
  base   

[jira] [Updated] (CLOUDSTACK-8402) Adding the KVM host to management server is failing (java8)

[satoru nakaya (JIRA)]

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

satoru nakaya updated CLOUDSTACK-8402:
--
Description: 
cat cloudstack-agent.err
:
25/04/2015 16:24:00 2964 jsvc.exec error: Cannot load daemon
25/04/2015 16:24:00 2963 jsvc.exec error: Service exit with a return value of 3


Cause of the failure is because java8 is installed.
cloudstack-agent is in need of java7.

but, java8 is installed by cloudstack-agent dependency resolution.

Dependency is broken ?

[root@acs45-kvm02 ~]# yum install cloudstack-agent --nogpgcheck
Loaded plugins: fastestmirror, security
Setting up Install Process
Determining fastest mirrors
   :

-- Finished Dependency Resolution

Dependencies Resolved


 PackageArch  Version   
Repository Size

Installing:
 cloudstack-agent   x86_644.5.1-SNAPSHOT.el6
cloudstack 48 M
Installing for dependencies:
 cloudstack-common  x86_644.5.1-SNAPSHOT.el6
cloudstack109 M
 ipset  x86_646.11-3.el6
base   63 k
 jakarta-commons-daemon x86_641:1.0.1-8.9.el6   
base   45 k
 jakarta-commons-daemon-jsvcx86_641:1.0.1-8.9.el6   
base   27 k
 java-1.5.0-gcj x86_641.5.0.0-29.1.el6  
base  139 k
 java-1.8.0-openjdk x86_64
1:1.8.0.45-28.b13.el6_6   updates   187 k
 java-1.8.0-openjdk-headlessx86_64
1:1.8.0.45-28.b13.el6_6   updates32 M
 java_cup   x86_641:0.10k-5.el6 
base  197 k
 libart_lgplx86_642.3.20-5.1.el6
base   65 k
 libgcj x86_644.4.7-11.el6  
base   19 M
 libmnl x86_641.0.2-3.el6   
base   21 k
 libvirt-python x86_640.10.2-46.el6_6.4 
updates   497 k
 sinjdocx86_640.5-9.1.el6   
base  705 k

Transaction Summary

Install  14 Package(s)

Total download size: 209 M
Installed size: 333 M
Is this ok [y/N]: N




workaround

[root@acs45-kvm02 ~]# yum install java-1.7.0-openjdk
[root@acs45-kvm02 ~]# yum install cloudstack-agent
Loaded plugins: fastestmirror, security
Setting up Install Process
Determining fastest mirrors
   :

-- Finished Dependency Resolution

Dependencies Resolved


 Package  ArchVersion   
  Repository   Size

Installing:
 cloudstack-agent x86_64  
4.5.1-SNAPSHOT.el6  cloudstack   48 M
Installing for dependencies:
 cloudstack-commonx86_64  
4.5.1-SNAPSHOT.el6  cloudstack  109 M
 ipsetx86_64  6.11-3.el6
  base 63 k
 jakarta-commons-daemon   x86_64  1:1.0.1-8.9.el6   
  base 45 k
 jakarta-commons-daemon-jsvc  x86_64  1:1.0.1-8.9.el6   
  base 27 k
 java-1.5.0-gcj   x86_64  1.5.0.0-29.1.el6  
  base139 k
 java_cup x86_64  1:0.10k-5.el6 
  base197 k
 libart_lgpl  x86_64  2.3.20-5.1.el6
  base 65 k
 libgcj   x86_64  4.4.7-11.el6  
 

[jira] [Updated] (CLOUDSTACK-8402) Adding the KVM host to management server is failing (java8)

[satoru nakaya (JIRA)]

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

satoru nakaya updated CLOUDSTACK-8402:
--
Description: 
[root@acs45-kvm02 ~]# cat cloudstack-agent.err
:
25/04/2015 16:24:00 2964 jsvc.exec error: Cannot load daemon
25/04/2015 16:24:00 2963 jsvc.exec error: Service exit with a return value of 3


Cause of the failure is because java8 is installed.
cloudstack-agent is in need of java7.

but, java8 is installed by cloudstack-agent dependency resolution.

Dependency is broken ?

[root@acs45-kvm02 ~]# yum install cloudstack-agent --nogpgcheck
Loaded plugins: fastestmirror, security
Setting up Install Process
Determining fastest mirrors
   :

-- Finished Dependency Resolution

Dependencies Resolved


 PackageArch  Version   
Repository Size

Installing:
 cloudstack-agent   x86_644.5.1-SNAPSHOT.el6
cloudstack 48 M
Installing for dependencies:
 cloudstack-common  x86_644.5.1-SNAPSHOT.el6
cloudstack109 M
 ipset  x86_646.11-3.el6
base   63 k
 jakarta-commons-daemon x86_641:1.0.1-8.9.el6   
base   45 k
 jakarta-commons-daemon-jsvcx86_641:1.0.1-8.9.el6   
base   27 k
 java-1.5.0-gcj x86_641.5.0.0-29.1.el6  
base  139 k
 java-1.8.0-openjdk x86_64
1:1.8.0.45-28.b13.el6_6   updates   187 k
 java-1.8.0-openjdk-headlessx86_64
1:1.8.0.45-28.b13.el6_6   updates32 M
 java_cup   x86_641:0.10k-5.el6 
base  197 k
 libart_lgplx86_642.3.20-5.1.el6
base   65 k
 libgcj x86_644.4.7-11.el6  
base   19 M
 libmnl x86_641.0.2-3.el6   
base   21 k
 libvirt-python x86_640.10.2-46.el6_6.4 
updates   497 k
 sinjdocx86_640.5-9.1.el6   
base  705 k

Transaction Summary

Install  14 Package(s)

Total download size: 209 M
Installed size: 333 M
Is this ok [y/N]: N




workaround

[root@acs45-kvm02 ~]# yum install java-1.7.0-openjdk
[root@acs45-kvm02 ~]# yum install cloudstack-agent
Loaded plugins: fastestmirror, security
Setting up Install Process
Determining fastest mirrors
   :

-- Finished Dependency Resolution

Dependencies Resolved


 Package  ArchVersion   
  Repository   Size

Installing:
 cloudstack-agent x86_64  
4.5.1-SNAPSHOT.el6  cloudstack   48 M
Installing for dependencies:
 cloudstack-commonx86_64  
4.5.1-SNAPSHOT.el6  cloudstack  109 M
 ipsetx86_64  6.11-3.el6
  base 63 k
 jakarta-commons-daemon   x86_64  1:1.0.1-8.9.el6   
  base 45 k
 jakarta-commons-daemon-jsvc  x86_64  1:1.0.1-8.9.el6   
  base 27 k
 java-1.5.0-gcj   x86_64  1.5.0.0-29.1.el6  
  base139 k
 java_cup x86_64  1:0.10k-5.el6 
  base197 k
 libart_lgpl  x86_64  2.3.20-5.1.el6
  base 65 k
 libgcj   x86_64  

[jira] [Closed] (CLOUDSTACK-8367) When Apply the hotfix(XS61E040) to host(XenServer 6.1) , Can't use NFS Storage in CloudStack

[satoru nakaya (JIRA)]

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

satoru nakaya closed CLOUDSTACK-8367.
-
Resolution: Done

 When Apply the hotfix(XS61E040) to host(XenServer 6.1) , Can't use NFS 
 Storage in CloudStack
 

 Key: CLOUDSTACK-8367
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8367
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: XenServer
Affects Versions: 4.2.1
 Environment: Apache CloudStack 4.2.1 (perhaps any versions...?)
 XenServer 6.1 + XS61E040
Reporter: satoru nakaya
Priority: Critical
 Attachments: packet capture_nfs_mount_error.png, 
 xencenter_nfs_mount_error.png, xencenter_nfs_remount_error.png


 When Apply the hotfix(XS61E040) to host(XenServer 6.1) , Can't use NFS 
 Storage in CloudStack
 Environment:
 Apache CloudStack 4.2.1 (perhaps any versions...?)
 XenServer 6.1 + XS61E040
 1. Apply the hotfix(XS61E040) to host(XenServer 6.1)
 2. Reboot the host
 3. Can't use NFS Storage(Primary Storage)
 packet capture:
 MOUNT 206 V3 MNT Call (Reply In 295) 
 /export/primary/1e0a51cd-cf99-9b7a-74fd-a739f285842f
 XenServer added sr-uuid to the mount point , it is not possible to mount
 [root@xen61-01 ~]# xe pbd-list
:

 uuid ( RO)  : 2c68e999-8516-05cd-07d4-7d3b4cfe1b0c
  host-uuid ( RO): a030fdfb-6823-462e-835a-2714e299d373
sr-uuid ( RO): 1e0a51cd-cf99-9b7a-74fd-a739f285842f
  device-config (MRO): serverpath: /export/primary; server: 
 192.168.11.10
 currently-attached ( RO): false



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

[jira] [Commented] (CLOUDSTACK-8367) When Apply the hotfix(XS61E040) to host(XenServer 6.1) , Can't use NFS Storage in CloudStack

[satoru nakaya (JIRA)]

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

satoru nakaya commented on CLOUDSTACK-8367:
---

I solved the problem.

http://support.citrix.com/article/CTX138152

CloudStack replace the NFSSR.py of XenServer.

CloudStack ManagementServer:

[root@acs ~]# find / -name NFSSR.py
/usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver/xcpserver/NFSSR.py
/usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver/xcposs/NFSSR.py
/usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py
/usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver/xenserver56fp1/NFSSR.py
/usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver/xenserver56/NFSSR.py
[root@acs ~]#

XenServer:

[root@xen61-01 ~]# find / -name NFSSR.py
/opt/xensource/sm/NFSSR.py
[root@xen61-01 ~]#

Which one for XenServer 6.1.0 is ?
I checked the hash value.

XS61E040 installation before:

[root@xen61-01 ~]# md5sum /opt/xensource/sm/NFSSR.py
af8a6bf6a93317075fbc51dd1b7f913c  /opt/xensource/sm/NFSSR.py
[root@xen61-01 ~]#

This one.

[root@acs ~]# md5sum 
/usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py
af8a6bf6a93317075fbc51dd1b7f913c 
/usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py
[root@acs ~]#

XS61E040 installation after:

[root@xen61-01 ~]# md5sum /opt/xensource/sm/NFSSR.py
ebdba8f6d7e5c3be7009cc7b924cd88d  /opt/xensource/sm/NFSSR.py
[root@xen61-01 ~]#

NFSSR.py had returned to those of the original Xenserver.

I solved the problem below.

Copy this file to the XenServer at the location  xe-toolstack-restart

[root@acs ~]# scp 
/usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py
 root@[xenserver]:/opt/xensource/sm/
[root@acs ~]# ssh root@[xenserver] xe-toolstack-restart

Thanks.


 When Apply the hotfix(XS61E040) to host(XenServer 6.1) , Can't use NFS 
 Storage in CloudStack
 

 Key: CLOUDSTACK-8367
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8367
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: XenServer
Affects Versions: 4.2.1
 Environment: Apache CloudStack 4.2.1 (perhaps any versions...?)
 XenServer 6.1 + XS61E040
Reporter: satoru nakaya
Priority: Critical
 Attachments: packet capture_nfs_mount_error.png, 
 xencenter_nfs_mount_error.png, xencenter_nfs_remount_error.png


 When Apply the hotfix(XS61E040) to host(XenServer 6.1) , Can't use NFS 
 Storage in CloudStack
 Environment:
 Apache CloudStack 4.2.1 (perhaps any versions...?)
 XenServer 6.1 + XS61E040
 1. Apply the hotfix(XS61E040) to host(XenServer 6.1)
 2. Reboot the host
 3. Can't use NFS Storage(Primary Storage)
 packet capture:
 MOUNT 206 V3 MNT Call (Reply In 295) 
 /export/primary/1e0a51cd-cf99-9b7a-74fd-a739f285842f
 XenServer added sr-uuid to the mount point , it is not possible to mount
 [root@xen61-01 ~]# xe pbd-list
:

 uuid ( RO)  : 2c68e999-8516-05cd-07d4-7d3b4cfe1b0c
  host-uuid ( RO): a030fdfb-6823-462e-835a-2714e299d373
sr-uuid ( RO): 1e0a51cd-cf99-9b7a-74fd-a739f285842f
  device-config (MRO): serverpath: /export/primary; server: 
 192.168.11.10
 currently-attached ( RO): false



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

[jira] [Updated] (CLOUDSTACK-8367) When Apply the hotfix(XS61E040) to host(XenServer 6.1) , Can't use NFS Storage in CloudStack

[satoru nakaya (JIRA)]

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

satoru nakaya updated CLOUDSTACK-8367:
--
Environment: 
Apache CloudStack 4.2.1 (perhaps any versions...?)
XenServer 6.1 + XS61E040

  was:
Apache CloudStack 4.2.1 (perhaps any versions...?)
XenServer 6.1 + XS61E040 (I'm tested XS61E043 + XS61E038.zip + XS61E039 + 
XS61E040)


 When Apply the hotfix(XS61E040) to host(XenServer 6.1) , Can't use NFS 
 Storage in CloudStack
 

 Key: CLOUDSTACK-8367
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8367
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: XenServer
Affects Versions: 4.2.1
 Environment: Apache CloudStack 4.2.1 (perhaps any versions...?)
 XenServer 6.1 + XS61E040
Reporter: satoru nakaya
Priority: Critical
 Attachments: packet capture_nfs_mount_error.png, 
 xencenter_nfs_mount_error.png, xencenter_nfs_remount_error.png


 When Apply the hotfix(XS61E040) to host(XenServer 6.1) , Can't use NFS 
 Storage in CloudStack
 Environment:
 Apache CloudStack 4.2.1 (perhaps any versions...?)
 XenServer 6.1 + XS61E040 (I'm tested XS61E043 + XS61E038.zip + XS61E039 + 
 XS61E040)
 1. Apply the hotfix(XS61E040) to host(XenServer 6.1)
 2. Reboot the host
 3. Can't use NFS Storage(Primary Storage)
 packet capture:
 MOUNT 206 V3 MNT Call (Reply In 295) 
 /export/primary/1e0a51cd-cf99-9b7a-74fd-a739f285842f
 XenServer added sr-uuid to the mount point , it is not possible to mount
 [root@xen61-01 ~]# xe pbd-list
:

 uuid ( RO)  : 2c68e999-8516-05cd-07d4-7d3b4cfe1b0c
  host-uuid ( RO): a030fdfb-6823-462e-835a-2714e299d373
sr-uuid ( RO): 1e0a51cd-cf99-9b7a-74fd-a739f285842f
  device-config (MRO): serverpath: /export/primary; server: 
 192.168.11.10
 currently-attached ( RO): false



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

[jira] [Updated] (CLOUDSTACK-8367) When Apply the hotfix(XS61E040) to host(XenServer 6.1) , Can't use NFS Storage in CloudStack

[satoru nakaya (JIRA)]

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

satoru nakaya updated CLOUDSTACK-8367:
--
Description: 
When Apply the hotfix(XS61E040) to host(XenServer 6.1) , Can't use NFS Storage 
in CloudStack

Environment:

Apache CloudStack 4.2.1 (perhaps any versions...?)
XenServer 6.1 + XS61E040


1. Apply the hotfix(XS61E040) to host(XenServer 6.1)
2. Reboot the host
3. Can't use NFS Storage(Primary Storage)


packet capture:
MOUNT 206 V3 MNT Call (Reply In 295) 
/export/primary/1e0a51cd-cf99-9b7a-74fd-a739f285842f

XenServer added sr-uuid to the mount point , it is not possible to mount

[root@xen61-01 ~]# xe pbd-list
   :
   
uuid ( RO)  : 2c68e999-8516-05cd-07d4-7d3b4cfe1b0c
 host-uuid ( RO): a030fdfb-6823-462e-835a-2714e299d373
   sr-uuid ( RO): 1e0a51cd-cf99-9b7a-74fd-a739f285842f
 device-config (MRO): serverpath: /export/primary; server: 192.168.11.10
currently-attached ( RO): false


  was:
When Apply the hotfix(XS61E040) to host(XenServer 6.1) , Can't use NFS Storage 
in CloudStack

Environment:

Apache CloudStack 4.2.1 (perhaps any versions...?)
XenServer 6.1 + XS61E040 (I'm tested XS61E043 + XS61E038.zip + XS61E039 + 
XS61E040)


1. Apply the hotfix(XS61E040) to host(XenServer 6.1)
2. Reboot the host
3. Can't use NFS Storage(Primary Storage)


packet capture:
MOUNT 206 V3 MNT Call (Reply In 295) 
/export/primary/1e0a51cd-cf99-9b7a-74fd-a739f285842f

XenServer added sr-uuid to the mount point , it is not possible to mount

[root@xen61-01 ~]# xe pbd-list
   :
   
uuid ( RO)  : 2c68e999-8516-05cd-07d4-7d3b4cfe1b0c
 host-uuid ( RO): a030fdfb-6823-462e-835a-2714e299d373
   sr-uuid ( RO): 1e0a51cd-cf99-9b7a-74fd-a739f285842f
 device-config (MRO): serverpath: /export/primary; server: 192.168.11.10
currently-attached ( RO): false



 When Apply the hotfix(XS61E040) to host(XenServer 6.1) , Can't use NFS 
 Storage in CloudStack
 

 Key: CLOUDSTACK-8367
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8367
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: XenServer
Affects Versions: 4.2.1
 Environment: Apache CloudStack 4.2.1 (perhaps any versions...?)
 XenServer 6.1 + XS61E040
Reporter: satoru nakaya
Priority: Critical
 Attachments: packet capture_nfs_mount_error.png, 
 xencenter_nfs_mount_error.png, xencenter_nfs_remount_error.png


 When Apply the hotfix(XS61E040) to host(XenServer 6.1) , Can't use NFS 
 Storage in CloudStack
 Environment:
 Apache CloudStack 4.2.1 (perhaps any versions...?)
 XenServer 6.1 + XS61E040
 1. Apply the hotfix(XS61E040) to host(XenServer 6.1)
 2. Reboot the host
 3. Can't use NFS Storage(Primary Storage)
 packet capture:
 MOUNT 206 V3 MNT Call (Reply In 295) 
 /export/primary/1e0a51cd-cf99-9b7a-74fd-a739f285842f
 XenServer added sr-uuid to the mount point , it is not possible to mount
 [root@xen61-01 ~]# xe pbd-list
:

 uuid ( RO)  : 2c68e999-8516-05cd-07d4-7d3b4cfe1b0c
  host-uuid ( RO): a030fdfb-6823-462e-835a-2714e299d373
sr-uuid ( RO): 1e0a51cd-cf99-9b7a-74fd-a739f285842f
  device-config (MRO): serverpath: /export/primary; server: 
 192.168.11.10
 currently-attached ( RO): false



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

[jira] [Created] (CLOUDSTACK-8367) When Apply the hotfix(XS61E040) to host(XenServer 6.1) , Can't use NFS Storage in CloudStack

[satoru nakaya (JIRA)]

satoru nakaya created CLOUDSTACK-8367:
-

 Summary: When Apply the hotfix(XS61E040) to host(XenServer 6.1) , 
Can't use NFS Storage in CloudStack
 Key: CLOUDSTACK-8367
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8367
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: XenServer
Affects Versions: 4.2.1
 Environment: Apache CloudStack 4.2.1 (perhaps any versions...?)
XenServer 6.1 + XS61E040 (I'm tested XS61E043 + XS61E038.zip + XS61E039 + 
XS61E040)
Reporter: satoru nakaya
Priority: Critical


When Apply the hotfix(XS61E040) to host(XenServer 6.1) , Can't use NFS Storage 
in CloudStack

Environment:

Apache CloudStack 4.2.1 (perhaps any versions...?)
XenServer 6.1 + XS61E040 (I'm tested XS61E043 + XS61E038.zip + XS61E039 + 
XS61E040)


1. Apply the hotfix(XS61E040) to host(XenServer 6.1)
2. Reboot the host
3. Can't use NFS Storage(Primary Storage)


packet capture:
MOUNT 206 V3 MNT Call (Reply In 295) 
/export/primary/1e0a51cd-cf99-9b7a-74fd-a739f285842f

XenServer added sr-uuid to the mount point , it is not possible to mount

[root@xen61-01 ~]# xe pbd-list
   :
   
uuid ( RO)  : 2c68e999-8516-05cd-07d4-7d3b4cfe1b0c
 host-uuid ( RO): a030fdfb-6823-462e-835a-2714e299d373
   sr-uuid ( RO): 1e0a51cd-cf99-9b7a-74fd-a739f285842f
 device-config (MRO): serverpath: /export/primary; server: 192.168.11.10
currently-attached ( RO): false




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

[jira] [Updated] (CLOUDSTACK-8367) When Apply the hotfix(XS61E040) to host(XenServer 6.1) , Can't use NFS Storage in CloudStack

[satoru nakaya (JIRA)]

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

satoru nakaya updated CLOUDSTACK-8367:
--
Attachment: packet capture_nfs_mount_error.png
xencenter_nfs_remount_error.png
xencenter_nfs_mount_error.png

 When Apply the hotfix(XS61E040) to host(XenServer 6.1) , Can't use NFS 
 Storage in CloudStack
 

 Key: CLOUDSTACK-8367
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8367
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: XenServer
Affects Versions: 4.2.1
 Environment: Apache CloudStack 4.2.1 (perhaps any versions...?)
 XenServer 6.1 + XS61E040 (I'm tested XS61E043 + XS61E038.zip + XS61E039 + 
 XS61E040)
Reporter: satoru nakaya
Priority: Critical
 Attachments: packet capture_nfs_mount_error.png, 
 xencenter_nfs_mount_error.png, xencenter_nfs_remount_error.png


 When Apply the hotfix(XS61E040) to host(XenServer 6.1) , Can't use NFS 
 Storage in CloudStack
 Environment:
 Apache CloudStack 4.2.1 (perhaps any versions...?)
 XenServer 6.1 + XS61E040 (I'm tested XS61E043 + XS61E038.zip + XS61E039 + 
 XS61E040)
 1. Apply the hotfix(XS61E040) to host(XenServer 6.1)
 2. Reboot the host
 3. Can't use NFS Storage(Primary Storage)
 packet capture:
 MOUNT 206 V3 MNT Call (Reply In 295) 
 /export/primary/1e0a51cd-cf99-9b7a-74fd-a739f285842f
 XenServer added sr-uuid to the mount point , it is not possible to mount
 [root@xen61-01 ~]# xe pbd-list
:

 uuid ( RO)  : 2c68e999-8516-05cd-07d4-7d3b4cfe1b0c
  host-uuid ( RO): a030fdfb-6823-462e-835a-2714e299d373
sr-uuid ( RO): 1e0a51cd-cf99-9b7a-74fd-a739f285842f
  device-config (MRO): serverpath: /export/primary; server: 
 192.168.11.10
 currently-attached ( RO): false



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

[jira] [Updated] (CLOUDSTACK-7410) OVS distributed routing + KVM / NameError: name 'configure_ovs_bridge_for_routing_policies' is not defined

[satoru nakaya (JIRA)]

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

satoru nakaya updated CLOUDSTACK-7410:
--
Attachment: computenode_messages.zip

 OVS distributed routing + KVM / NameError: name 
 'configure_ovs_bridge_for_routing_policies' is not defined
 --

 Key: CLOUDSTACK-7410
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7410
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.0
 Environment: Environment:
  CloudStack 4.4.0
  KVM(CentOS6.4)
  Open vSwitch 1.11.0
  VPC Offering
:
   Connectivity:Ovs
   DistributedRouter:On
  Network Offering
:
   Virtual Networking:Ovs
Reporter: satoru nakaya
 Attachments: computenode_messages.zip, management-server.zip


 Error is output following when you deploy VM instances in VPC.
 2014-08-03 14:52:25,608 DEBUG [c.c.a.t.Request] (AgentManager-Handler-5:null) 
 Seq 8-7588002422165864587: Processing: { Ans: , MgmtId: 52236007434, via: 8, 
 Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.Answer:{result:false,details:Traceback (most 
 recent call last): File 
 \/usr/share/cloudstack-common/scripts/vm/network/vnet/ovstunnel.py\, line 
 302, in configure_ovs_bridge_for_routing_policies(bridge, config)NameError: 
 name 'configure_ovs_bridge_for_routing_policies' is not defined,wait:0}}] }
 2014-08-03 14:52:25,608 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Seq 
 8-7588002422165864587: Received: { Ans: , MgmtId: 52236007434, via: 8, Ver: 
 v1, Flags: 10, { Answer } }
 2014-08-03 14:52:25,608 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 update the host 8 with latest routing policies.
 2014-08-03 14:52:25,609 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 send VPC routing policy change update to host : 8. But moving on with sending 
 the updates to the rest of the hosts.
 :
 2014-08-03 14:52:25,622 ERROR [c.c.v.VirtualMachineManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 start instance VM[User|i-2-40-VM]
 com.cloud.utils.exception.CloudRuntimeException: Failed to add VPC router 
 VM[DomainRouter|r-38-VM] to guest network 
 Ntwk[95583273-9dc0-4569-be29-706b28543932|Guest|15]
 at 
 com.cloud.network.element.VpcVirtualRouterElement.implement(VpcVirtualRouterElement.java:188)



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

[jira] [Comment Edited] (CLOUDSTACK-7410) OVS distributed routing + KVM / NameError: name 'configure_ovs_bridge_for_routing_policies' is not defined

[satoru nakaya (JIRA)]

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

satoru nakaya edited comment on CLOUDSTACK-7410 at 3/14/15 7:46 AM:


Today, I was tested in 4.4.2 .
Same error has occurred .
I was using a distributed virtual router of VPC in KVM environment .
VM did not start .

I 've attached the log file.


was (Author: giraffeforestg):
Today, I was tested in 4.4.2 .
Same error has occurred .
I was using a distributed virtual router of VPC in KVM environment .
VM did not start .

I 've attached the management-server.log .

 OVS distributed routing + KVM / NameError: name 
 'configure_ovs_bridge_for_routing_policies' is not defined
 --

 Key: CLOUDSTACK-7410
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7410
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.0
 Environment: Environment:
  CloudStack 4.4.0
  KVM(CentOS6.4)
  Open vSwitch 1.11.0
  VPC Offering
:
   Connectivity:Ovs
   DistributedRouter:On
  Network Offering
:
   Virtual Networking:Ovs
Reporter: satoru nakaya
 Attachments: computenode_agent.zip, computenode_messages.zip, 
 management-server.zip


 Error is output following when you deploy VM instances in VPC.
 2014-08-03 14:52:25,608 DEBUG [c.c.a.t.Request] (AgentManager-Handler-5:null) 
 Seq 8-7588002422165864587: Processing: { Ans: , MgmtId: 52236007434, via: 8, 
 Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.Answer:{result:false,details:Traceback (most 
 recent call last): File 
 \/usr/share/cloudstack-common/scripts/vm/network/vnet/ovstunnel.py\, line 
 302, in configure_ovs_bridge_for_routing_policies(bridge, config)NameError: 
 name 'configure_ovs_bridge_for_routing_policies' is not defined,wait:0}}] }
 2014-08-03 14:52:25,608 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Seq 
 8-7588002422165864587: Received: { Ans: , MgmtId: 52236007434, via: 8, Ver: 
 v1, Flags: 10, { Answer } }
 2014-08-03 14:52:25,608 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 update the host 8 with latest routing policies.
 2014-08-03 14:52:25,609 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 send VPC routing policy change update to host : 8. But moving on with sending 
 the updates to the rest of the hosts.
 :
 2014-08-03 14:52:25,622 ERROR [c.c.v.VirtualMachineManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 start instance VM[User|i-2-40-VM]
 com.cloud.utils.exception.CloudRuntimeException: Failed to add VPC router 
 VM[DomainRouter|r-38-VM] to guest network 
 Ntwk[95583273-9dc0-4569-be29-706b28543932|Guest|15]
 at 
 com.cloud.network.element.VpcVirtualRouterElement.implement(VpcVirtualRouterElement.java:188)



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

[jira] [Updated] (CLOUDSTACK-7410) OVS distributed routing + KVM / NameError: name 'configure_ovs_bridge_for_routing_policies' is not defined

[satoru nakaya (JIRA)]

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

satoru nakaya updated CLOUDSTACK-7410:
--
Attachment: computenode_agent.zip

 OVS distributed routing + KVM / NameError: name 
 'configure_ovs_bridge_for_routing_policies' is not defined
 --

 Key: CLOUDSTACK-7410
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7410
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.0
 Environment: Environment:
  CloudStack 4.4.0
  KVM(CentOS6.4)
  Open vSwitch 1.11.0
  VPC Offering
:
   Connectivity:Ovs
   DistributedRouter:On
  Network Offering
:
   Virtual Networking:Ovs
Reporter: satoru nakaya
 Attachments: computenode_agent.zip, computenode_messages.zip, 
 management-server.zip


 Error is output following when you deploy VM instances in VPC.
 2014-08-03 14:52:25,608 DEBUG [c.c.a.t.Request] (AgentManager-Handler-5:null) 
 Seq 8-7588002422165864587: Processing: { Ans: , MgmtId: 52236007434, via: 8, 
 Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.Answer:{result:false,details:Traceback (most 
 recent call last): File 
 \/usr/share/cloudstack-common/scripts/vm/network/vnet/ovstunnel.py\, line 
 302, in configure_ovs_bridge_for_routing_policies(bridge, config)NameError: 
 name 'configure_ovs_bridge_for_routing_policies' is not defined,wait:0}}] }
 2014-08-03 14:52:25,608 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Seq 
 8-7588002422165864587: Received: { Ans: , MgmtId: 52236007434, via: 8, Ver: 
 v1, Flags: 10, { Answer } }
 2014-08-03 14:52:25,608 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 update the host 8 with latest routing policies.
 2014-08-03 14:52:25,609 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 send VPC routing policy change update to host : 8. But moving on with sending 
 the updates to the rest of the hosts.
 :
 2014-08-03 14:52:25,622 ERROR [c.c.v.VirtualMachineManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 start instance VM[User|i-2-40-VM]
 com.cloud.utils.exception.CloudRuntimeException: Failed to add VPC router 
 VM[DomainRouter|r-38-VM] to guest network 
 Ntwk[95583273-9dc0-4569-be29-706b28543932|Guest|15]
 at 
 com.cloud.network.element.VpcVirtualRouterElement.implement(VpcVirtualRouterElement.java:188)



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

[jira] [Comment Edited] (CLOUDSTACK-7410) OVS distributed routing + KVM / NameError: name 'configure_ovs_bridge_for_routing_policies' is not defined

[satoru nakaya (JIRA)]

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

satoru nakaya edited comment on CLOUDSTACK-7410 at 3/14/15 5:38 AM:


Today, I was tested in 4.4.2 .
Same error has occurred .
I was using a distributed virtual router of VPC in KVM environment .
VM did not start .

I 've attached the management-server.log .


was (Author: giraffeforestg):
Apache CloudStack 4.4.2 (rpm) + CentOS6.4 KVM

 OVS distributed routing + KVM / NameError: name 
 'configure_ovs_bridge_for_routing_policies' is not defined
 --

 Key: CLOUDSTACK-7410
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7410
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.0
 Environment: Environment:
  CloudStack 4.4.0
  KVM(CentOS6.4)
  Open vSwitch 1.11.0
  VPC Offering
:
   Connectivity:Ovs
   DistributedRouter:On
  Network Offering
:
   Virtual Networking:Ovs
Reporter: satoru nakaya
 Attachments: management-server.zip


 Error is output following when you deploy VM instances in VPC.
 2014-08-03 14:52:25,608 DEBUG [c.c.a.t.Request] (AgentManager-Handler-5:null) 
 Seq 8-7588002422165864587: Processing: { Ans: , MgmtId: 52236007434, via: 8, 
 Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.Answer:{result:false,details:Traceback (most 
 recent call last): File 
 \/usr/share/cloudstack-common/scripts/vm/network/vnet/ovstunnel.py\, line 
 302, in configure_ovs_bridge_for_routing_policies(bridge, config)NameError: 
 name 'configure_ovs_bridge_for_routing_policies' is not defined,wait:0}}] }
 2014-08-03 14:52:25,608 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Seq 
 8-7588002422165864587: Received: { Ans: , MgmtId: 52236007434, via: 8, Ver: 
 v1, Flags: 10, { Answer } }
 2014-08-03 14:52:25,608 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 update the host 8 with latest routing policies.
 2014-08-03 14:52:25,609 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 send VPC routing policy change update to host : 8. But moving on with sending 
 the updates to the rest of the hosts.
 :
 2014-08-03 14:52:25,622 ERROR [c.c.v.VirtualMachineManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 start instance VM[User|i-2-40-VM]
 com.cloud.utils.exception.CloudRuntimeException: Failed to add VPC router 
 VM[DomainRouter|r-38-VM] to guest network 
 Ntwk[95583273-9dc0-4569-be29-706b28543932|Guest|15]
 at 
 com.cloud.network.element.VpcVirtualRouterElement.implement(VpcVirtualRouterElement.java:188)



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

[jira] [Updated] (CLOUDSTACK-7410) OVS distributed routing + KVM / NameError: name 'configure_ovs_bridge_for_routing_policies' is not defined

[satoru nakaya (JIRA)]

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

satoru nakaya updated CLOUDSTACK-7410:
--
Attachment: management-server.zip

Apache CloudStack 4.4.2 (rpm) + CentOS6.4 KVM

 OVS distributed routing + KVM / NameError: name 
 'configure_ovs_bridge_for_routing_policies' is not defined
 --

 Key: CLOUDSTACK-7410
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7410
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.0
 Environment: Environment:
  CloudStack 4.4.0
  KVM(CentOS6.4)
  Open vSwitch 1.11.0
  VPC Offering
:
   Connectivity:Ovs
   DistributedRouter:On
  Network Offering
:
   Virtual Networking:Ovs
Reporter: satoru nakaya
 Attachments: management-server.zip


 Error is output following when you deploy VM instances in VPC.
 2014-08-03 14:52:25,608 DEBUG [c.c.a.t.Request] (AgentManager-Handler-5:null) 
 Seq 8-7588002422165864587: Processing: { Ans: , MgmtId: 52236007434, via: 8, 
 Ver: v1, Flags: 10, 
 [{com.cloud.agent.api.Answer:{result:false,details:Traceback (most 
 recent call last): File 
 \/usr/share/cloudstack-common/scripts/vm/network/vnet/ovstunnel.py\, line 
 302, in configure_ovs_bridge_for_routing_policies(bridge, config)NameError: 
 name 'configure_ovs_bridge_for_routing_policies' is not defined,wait:0}}] }
 2014-08-03 14:52:25,608 DEBUG [c.c.a.t.Request] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Seq 
 8-7588002422165864587: Received: { Ans: , MgmtId: 52236007434, via: 8, Ver: 
 v1, Flags: 10, { Answer } }
 2014-08-03 14:52:25,608 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 update the host 8 with latest routing policies.
 2014-08-03 14:52:25,609 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 send VPC routing policy change update to host : 8. But moving on with sending 
 the updates to the rest of the hosts.
 :
 2014-08-03 14:52:25,622 ERROR [c.c.v.VirtualMachineManagerImpl] 
 (Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
 start instance VM[User|i-2-40-VM]
 com.cloud.utils.exception.CloudRuntimeException: Failed to add VPC router 
 VM[DomainRouter|r-38-VM] to guest network 
 Ntwk[95583273-9dc0-4569-be29-706b28543932|Guest|15]
 at 
 com.cloud.network.element.VpcVirtualRouterElement.implement(VpcVirtualRouterElement.java:188)



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

[jira] [Commented] (CLOUDSTACK-8295) max data volume limits to be updated with new values for all hypervisors

[satoru nakaya (JIRA)]

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

satoru nakaya commented on CLOUDSTACK-8295:
---

Hi

Fixed.

http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/storage.html
Working With Volumes
Note

 max data volume limits to be updated with new values for all hypervisors
 

 Key: CLOUDSTACK-8295
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8295
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.3.0, 4.4.0
Reporter: Harikrishna Patnala
 Fix For: 4.6.0


 There is discrepancy in doc and the values we support in Cloudstack
 http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.4/storage.html
 http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/storage.html
 
 CloudStack supports attaching up to 13 data disks to a VM on XenServer
 hypervisor versions 6.0 and above.
 For the VMs on other hypervisor types, the data disk limit is 6.
 
 The Manual is wrong.
 CloudStack supports attaching up to 
  a) 13 data disks on XenServer hypervisor versions 6.0 and above and all 
 versions of VMware 
 b) 64 data disks on HyperV
 c) 6 data disks on other hypervisor types
 mysql select hypervisor_type,hypervisor_version,max_data_volumes_limit from 
 cloud.hypervisor_capabilities order by hypervisor_type;;
 +-+++
 | hypervisor_type | hypervisor_version | max_data_volumes_limit |
 +-+++
 | Hyperv  | 6.2| 64 |
 | KVM | default|  6 |
 | LXC | default|  6 |
 | Ovm | default|  6 |
 | Ovm | 2.3|  6 |
 | VMware  | default| 13 |
 | VMware  | 4.0| 13 |
 | VMware  | 4.1| 13 |
 | VMware  | 5.5| 13 |
 | VMware  | 5.1| 13 |
 | VMware  | 5.0| 13 |
 | XenServer   | 6.1.0  | 13 |
 | XenServer   | 6.2.0  | 13 |
 | XenServer   | default|  6 |
 | XenServer   | 6.0.2  | 13 |
 | XenServer   | 6.0| 13 |
 | XenServer   | 5.6 SP2|  6 |
 | XenServer   | 5.6 FP1|  6 |
 | XenServer   | 5.6|  6 |
 | XenServer   | XCP 1.0|  6 |
 | XenServer   | 6.5.0  | 13 |
 +-+++



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

[jira] [Commented] (CLOUDSTACK-8295) max data volume limits to be updated with new values for all hypervisors

[satoru nakaya (JIRA)]

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

satoru nakaya commented on CLOUDSTACK-8295:
---

Hi

I want to do so,
But I do not have the assign permission.

 max data volume limits to be updated with new values for all hypervisors
 

 Key: CLOUDSTACK-8295
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8295
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.3.0, 4.4.0
Reporter: Harikrishna Patnala
 Fix For: 4.6.0


 There is discrepancy in doc and the values we support in Cloudstack
 http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.4/storage.html
 http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/storage.html
 
 CloudStack supports attaching up to 13 data disks to a VM on XenServer
 hypervisor versions 6.0 and above.
 For the VMs on other hypervisor types, the data disk limit is 6.
 
 The Manual is wrong.
 CloudStack supports attaching up to 
  a) 13 data disks on XenServer hypervisor versions 6.0 and above and all 
 versions of VMware 
 b) 64 data disks on HyperV
 c) 6 data disks on other hypervisor types
 mysql select hypervisor_type,hypervisor_version,max_data_volumes_limit from 
 cloud.hypervisor_capabilities order by hypervisor_type;;
 +-+++
 | hypervisor_type | hypervisor_version | max_data_volumes_limit |
 +-+++
 | Hyperv  | 6.2| 64 |
 | KVM | default|  6 |
 | LXC | default|  6 |
 | Ovm | default|  6 |
 | Ovm | 2.3|  6 |
 | VMware  | default| 13 |
 | VMware  | 4.0| 13 |
 | VMware  | 4.1| 13 |
 | VMware  | 5.5| 13 |
 | VMware  | 5.1| 13 |
 | VMware  | 5.0| 13 |
 | XenServer   | 6.1.0  | 13 |
 | XenServer   | 6.2.0  | 13 |
 | XenServer   | default|  6 |
 | XenServer   | 6.0.2  | 13 |
 | XenServer   | 6.0| 13 |
 | XenServer   | 5.6 SP2|  6 |
 | XenServer   | 5.6 FP1|  6 |
 | XenServer   | 5.6|  6 |
 | XenServer   | XCP 1.0|  6 |
 | XenServer   | 6.5.0  | 13 |
 +-+++



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

[jira] [Commented] (CLOUDSTACK-7789) I was updated from version 4.4.0 of Apache CloudStack to 4.4.1. It does not work correctly. (404 error of WebGUI)

[satoru nakaya (JIRA)]

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

satoru nakaya commented on CLOUDSTACK-7789:
---

hi. 

It worked!
in this workarounds.

[root@acs ~]# service cloudstack-management stop
Stopping cloudstack-management:[  OK  ]
[root@acs ~]# mysql -u root -p cloud
Enter password:
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 19
Server version: 5.1.73-log Source distribution

Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql
mysql describe snapshot_policy;
+---+-+--+-+-++
| Field | Type| Null | Key | Default | Extra  |
+---+-+--+-+-++
| id| bigint(20) unsigned | NO   | PRI | NULL| auto_increment |
| uuid  | varchar(40) | YES  | UNI | NULL||
| volume_id | bigint(20) unsigned | NO   | MUL | NULL||
| schedule  | varchar(100)| NO   | | NULL||
| timezone  | varchar(100)| NO   | | NULL||
| interval  | int(4)  | NO   | | 4   ||
| max_snaps | int(8)  | NO   | | 0   ||
| active| tinyint(1) unsigned | NO   | | NULL||
+---+-+--+-+-++
8 rows in set (0.01 sec)

mysql
mysql ALTER TABLE snapshot_policy ADD display TINYINT(1) NOT NULL DEFAULT '1';
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0
mysql
mysql describe snapshot_policy;
+---+-+--+-+-++
| Field | Type| Null | Key | Default | Extra  |
+---+-+--+-+-++
| id| bigint(20) unsigned | NO   | PRI | NULL| auto_increment |
| uuid  | varchar(40) | YES  | UNI | NULL||
| volume_id | bigint(20) unsigned | NO   | MUL | NULL||
| schedule  | varchar(100)| NO   | | NULL||
| timezone  | varchar(100)| NO   | | NULL||
| interval  | int(4)  | NO   | | 4   ||
| max_snaps | int(8)  | NO   | | 0   ||
| active| tinyint(1) unsigned | NO   | | NULL||
| display   | tinyint(1)  | NO   | | 1   ||
+---+-+--+-+-++
9 rows in set (0.00 sec)

mysql quit
Bye
[root@acs ~]#
[root@acs ~]# service cloudstack-management start
Starting cloudstack-management:[  OK  ]
[root@acs ~]# 

 I was updated from version 4.4.0 of Apache CloudStack to 4.4.1. It does not 
 work correctly. (404 error of WebGUI)
 -

 Key: CLOUDSTACK-7789
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7789
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.4.1
 Environment: CentOS6.4
Reporter: satoru nakaya

 I was updated from version 4.4.0 of Apache CloudStack to 4.4.1.
 It does not work correctly. (404 error of WebGUI)
 From
 # rpm -qa | grep cloudstack
 cloudstack-awsapi-4.4.0-NONOSS_3.el6.x86_64
 cloudstack-common-4.4.0-NONOSS_3.el6.x86_64
 cloudstack-management-4.4.0-NONOSS_3.el6.x86_64
 #
 To
 # rpm -qa | grep cloudstack
 cloudstack-common-4.4.1-NONOSS_3.el6.x86_64
 cloudstack-awsapi-4.4.1-NONOSS_3.el6.x86_64
 cloudstack-management-4.4.1-NONOSS_3.el6.x86_64
 #
 #  tail -f /var/log/cloudstack/management/management-server.log
   :
 014-10-26 11:40:55,432 INFO  [c.c.u.c.ComponentContext] (main:null) Starting 
 com.cloud.bridge.persist.dao.CloudStackSvcOfferingDaoImpl_EnhancerByCloudStack_8e883789
 2014-10-26 11:40:55,433 INFO  [c.c.u.c.ComponentContext] (main:null) Starting 
 com.cloud.bridge.persist.dao.SHostDaoImpl_EnhancerByCloudStack_3055f1c1
 2014-10-26 11:40:55,433 INFO  [c.c.u.c.ComponentContext] (main:null) Starting 
 

[jira] [Created] (CLOUDSTACK-7789) I was updated from version 4.4.0 of Apache CloudStack to 4.4.1. It does not work correctly. (404 error of WebGUI)

[satoru nakaya (JIRA)]

satoru nakaya created CLOUDSTACK-7789:
-

 Summary: I was updated from version 4.4.0 of Apache CloudStack to 
4.4.1. It does not work correctly. (404 error of WebGUI)
 Key: CLOUDSTACK-7789
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7789
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.4.1
 Environment: CentOS6.4
Reporter: satoru nakaya


I was updated from version 4.4.0 of Apache CloudStack to 4.4.1.
It does not work correctly. (404 error of WebGUI)

From
# rpm -qa | grep cloudstack
cloudstack-awsapi-4.4.0-NONOSS_3.el6.x86_64
cloudstack-common-4.4.0-NONOSS_3.el6.x86_64
cloudstack-management-4.4.0-NONOSS_3.el6.x86_64
#

To
# rpm -qa | grep cloudstack
cloudstack-common-4.4.1-NONOSS_3.el6.x86_64
cloudstack-awsapi-4.4.1-NONOSS_3.el6.x86_64
cloudstack-management-4.4.1-NONOSS_3.el6.x86_64
#


#  tail -f /var/log/cloudstack/management/management-server.log
  :
014-10-26 11:40:55,432 INFO  [c.c.u.c.ComponentContext] (main:null) Starting 
com.cloud.bridge.persist.dao.CloudStackSvcOfferingDaoImpl_EnhancerByCloudStack_8e883789
2014-10-26 11:40:55,433 INFO  [c.c.u.c.ComponentContext] (main:null) Starting 
com.cloud.bridge.persist.dao.SHostDaoImpl_EnhancerByCloudStack_3055f1c1
2014-10-26 11:40:55,433 INFO  [c.c.u.c.ComponentContext] (main:null) Starting 
com.cloud.bridge.persist.dao.SObjectDaoImpl_EnhancerByCloudStack_173061b2
2014-10-26 11:40:55,434 INFO  [c.c.u.c.ComponentContext] (main:null) Starting 
com.cloud.bridge.persist.dao.CloudStackUserDaoImpl_EnhancerByCloudStack_127ee70c
2014-10-26 11:40:55,434 INFO  [c.c.u.c.ComponentContext] (main:null) Starting 
com.cloud.bridge.service.core.ec2.EC2Engine_EnhancerByCloudStack_69bd4662
2014-10-26 11:40:55,434 INFO  [c.c.u.c.ComponentContext] (main:null) Starting 
com.cloud.bridge.service.controller.s3.ServiceProvider_EnhancerByCloudStack_94ede0d7

This subsequent log is not output.



# cat /var/log/cloudstack/management/catalina.out
  :
Exception in thread CapacityChecker java.lang.NullPointerException
at org.slf4j.impl.Log4jLoggerAdapter.info(Log4jLoggerAdapter.java:304)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.getContext(ManagedContextRunnable.java:66)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at 
org.apache.cloudstack.managed.context.ManagedContextTimerTask.run(ManagedContextTimerTask.java:27)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
Exception in thread Timer-1 java.lang.NullPointerException
at org.slf4j.impl.Log4jLoggerAdapter.info(Log4jLoggerAdapter.java:304)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.getContext(ManagedContextRunnable.java:66)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at 
org.apache.cloudstack.managed.context.ManagedContextTimerTask.run(ManagedContextTimerTask.java:27)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
Exception in thread HA-Worker-1 java.lang.NullPointerException
at org.slf4j.impl.Log4jLoggerAdapter.error(Log4jLoggerAdapter.java:538)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:117)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.run(HighAvailabilityManagerImpl.java:857)
Exception in thread HA-Worker-4 java.lang.NullPointerException
at org.slf4j.impl.Log4jLoggerAdapter.error(Log4jLoggerAdapter.java:538)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:117)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.run(HighAvailabilityManagerImpl.java:857)
Exception in thread HA-Worker-3 java.lang.NullPointerException
at org.slf4j.impl.Log4jLoggerAdapter.error(Log4jLoggerAdapter.java:538)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:117)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.run(HighAvailabilityManagerImpl.java:857)
Exception in thread HA-Worker-2 java.lang.NullPointerException
at 

[jira] [Updated] (CLOUDSTACK-7789) I was updated from version 4.4.0 of Apache CloudStack to 4.4.1. It does not work correctly. (404 error of WebGUI)

[satoru nakaya (JIRA)]

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

satoru nakaya updated CLOUDSTACK-7789:
--
Description: 
I was updated from version 4.4.0 of Apache CloudStack to 4.4.1.
It does not work correctly. (404 error of WebGUI)

From
# rpm -qa | grep cloudstack
cloudstack-awsapi-4.4.0-NONOSS_3.el6.x86_64
cloudstack-common-4.4.0-NONOSS_3.el6.x86_64
cloudstack-management-4.4.0-NONOSS_3.el6.x86_64
#

To
# rpm -qa | grep cloudstack
cloudstack-common-4.4.1-NONOSS_3.el6.x86_64
cloudstack-awsapi-4.4.1-NONOSS_3.el6.x86_64
cloudstack-management-4.4.1-NONOSS_3.el6.x86_64
#


#  tail -f /var/log/cloudstack/management/management-server.log
  :
014-10-26 11:40:55,432 INFO  [c.c.u.c.ComponentContext] (main:null) Starting 
com.cloud.bridge.persist.dao.CloudStackSvcOfferingDaoImpl_EnhancerByCloudStack_8e883789
2014-10-26 11:40:55,433 INFO  [c.c.u.c.ComponentContext] (main:null) Starting 
com.cloud.bridge.persist.dao.SHostDaoImpl_EnhancerByCloudStack_3055f1c1
2014-10-26 11:40:55,433 INFO  [c.c.u.c.ComponentContext] (main:null) Starting 
com.cloud.bridge.persist.dao.SObjectDaoImpl_EnhancerByCloudStack_173061b2
2014-10-26 11:40:55,434 INFO  [c.c.u.c.ComponentContext] (main:null) Starting 
com.cloud.bridge.persist.dao.CloudStackUserDaoImpl_EnhancerByCloudStack_127ee70c
2014-10-26 11:40:55,434 INFO  [c.c.u.c.ComponentContext] (main:null) Starting 
com.cloud.bridge.service.core.ec2.EC2Engine_EnhancerByCloudStack_69bd4662
2014-10-26 11:40:55,434 INFO  [c.c.u.c.ComponentContext] (main:null) Starting 
com.cloud.bridge.service.controller.s3.ServiceProvider_EnhancerByCloudStack_94ede0d7

This subsequent log is not output.



# cat /var/log/cloudstack/management/catalina.out
  :
Exception in thread CapacityChecker java.lang.NullPointerException
at org.slf4j.impl.Log4jLoggerAdapter.info(Log4jLoggerAdapter.java:304)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.getContext(ManagedContextRunnable.java:66)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at 
org.apache.cloudstack.managed.context.ManagedContextTimerTask.run(ManagedContextTimerTask.java:27)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
Exception in thread Timer-1 java.lang.NullPointerException
at org.slf4j.impl.Log4jLoggerAdapter.info(Log4jLoggerAdapter.java:304)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.getContext(ManagedContextRunnable.java:66)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at 
org.apache.cloudstack.managed.context.ManagedContextTimerTask.run(ManagedContextTimerTask.java:27)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
Exception in thread HA-Worker-1 java.lang.NullPointerException
at org.slf4j.impl.Log4jLoggerAdapter.error(Log4jLoggerAdapter.java:538)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:117)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.run(HighAvailabilityManagerImpl.java:857)
Exception in thread HA-Worker-4 java.lang.NullPointerException
at org.slf4j.impl.Log4jLoggerAdapter.error(Log4jLoggerAdapter.java:538)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:117)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.run(HighAvailabilityManagerImpl.java:857)
Exception in thread HA-Worker-3 java.lang.NullPointerException
at org.slf4j.impl.Log4jLoggerAdapter.error(Log4jLoggerAdapter.java:538)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:117)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.run(HighAvailabilityManagerImpl.java:857)
Exception in thread HA-Worker-2 java.lang.NullPointerException
at org.slf4j.impl.Log4jLoggerAdapter.error(Log4jLoggerAdapter.java:538)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:117)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
com.cloud.ha.HighAvailabilityManagerImpl$WorkerThread.run(HighAvailabilityManagerImpl.java:857)
Exception in thread 

[jira] [Created] (CLOUDSTACK-7630) CPU utilization display of VM Instances is incorrect. (In the case of VMware vSphere 5)

[satoru nakaya (JIRA)]

satoru nakaya created CLOUDSTACK-7630:
-

 Summary: CPU utilization display of VM Instances is incorrect. (In 
the case of VMware vSphere 5)
 Key: CLOUDSTACK-7630
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7630
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.1.1, 4.3.0
 Environment: CloudStack 4.3.0
VMware vSphere 5.0 update 2
Reporter: satoru nakaya


CPU utilization display of VM Instances is incorrect. 

Environment: 
CloudStack 4.3.0
VMware vSphere 5.0 update 2

CloudStack UI
 Instances-VM-Statistics
  CPU Utilized: 1980%
  ^^^

==
# top

top - 01:05:28 up  1:07,  2 users,  load average: 1.03, 1.07, 1.02
Tasks:  76 total,   2 running,  74 sleeping,   0 stopped,   0 zombie
Cpu(s): 97.9%us,  1.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st




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

[jira] [Updated] (CLOUDSTACK-7630) CPU utilization display of VM Instances is incorrect. (In the case of VMware vSphere 5)

[satoru nakaya (JIRA)]

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

satoru nakaya updated CLOUDSTACK-7630:
--
Description: 
CPU utilization display of VM Instances is incorrect. 

Environment: 
CloudStack 4.3.0
VMware vSphere 5.0 update 2

CloudStack UI
 Instances-VM-Statistics
  CPU Utilized: 1980%
  ^^^

==
'# top

top - 01:05:28 up  1:07,  2 users,  load average: 1.03, 1.07, 1.02
Tasks:  76 total,   2 running,  74 sleeping,   0 stopped,   0 zombie
Cpu(s): 97.9%us,  1.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st


  was:
CPU utilization display of VM Instances is incorrect. 

Environment: 
CloudStack 4.3.0
VMware vSphere 5.0 update 2

CloudStack UI
 Instances-VM-Statistics
  CPU Utilized: 1980%
  ^^^

==
 # top

top - 01:05:28 up  1:07,  2 users,  load average: 1.03, 1.07, 1.02
Tasks:  76 total,   2 running,  74 sleeping,   0 stopped,   0 zombie
Cpu(s): 97.9%us,  1.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st



 CPU utilization display of VM Instances is incorrect. (In the case of VMware 
 vSphere 5)
 ---

 Key: CLOUDSTACK-7630
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7630
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.1.1, 4.3.0
 Environment: CloudStack 4.3.0
 VMware vSphere 5.0 update 2
Reporter: satoru nakaya

 CPU utilization display of VM Instances is incorrect. 
 Environment: 
 CloudStack 4.3.0
 VMware vSphere 5.0 update 2
 CloudStack UI
  Instances-VM-Statistics
   CPU Utilized: 1980%
   ^^^
 ==
 '# top
 top - 01:05:28 up  1:07,  2 users,  load average: 1.03, 1.07, 1.02
 Tasks:  76 total,   2 running,  74 sleeping,   0 stopped,   0 zombie
 Cpu(s): 97.9%us,  1.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st



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

[jira] [Updated] (CLOUDSTACK-7630) CPU utilization display of VM Instances is incorrect. (In the case of VMware vSphere 5)

[satoru nakaya (JIRA)]

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

satoru nakaya updated CLOUDSTACK-7630:
--
Description: 
CPU utilization display of VM Instances is incorrect. 

Environment: 
CloudStack 4.3.0
VMware vSphere 5.0 update 2

CloudStack UI
 Instances-VM-Statistics
  CPU Utilized: 1980%
  ^^^

==
 # top

top - 01:05:28 up  1:07,  2 users,  load average: 1.03, 1.07, 1.02
Tasks:  76 total,   2 running,  74 sleeping,   0 stopped,   0 zombie
Cpu(s): 97.9%us,  1.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st


  was:
CPU utilization display of VM Instances is incorrect. 

Environment: 
CloudStack 4.3.0
VMware vSphere 5.0 update 2

CloudStack UI
 Instances-VM-Statistics
  CPU Utilized: 1980%
  ^^^

==
# top

top - 01:05:28 up  1:07,  2 users,  load average: 1.03, 1.07, 1.02
Tasks:  76 total,   2 running,  74 sleeping,   0 stopped,   0 zombie
Cpu(s): 97.9%us,  1.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st



 CPU utilization display of VM Instances is incorrect. (In the case of VMware 
 vSphere 5)
 ---

 Key: CLOUDSTACK-7630
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7630
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.1.1, 4.3.0
 Environment: CloudStack 4.3.0
 VMware vSphere 5.0 update 2
Reporter: satoru nakaya

 CPU utilization display of VM Instances is incorrect. 
 Environment: 
 CloudStack 4.3.0
 VMware vSphere 5.0 update 2
 CloudStack UI
  Instances-VM-Statistics
   CPU Utilized: 1980%
   ^^^
 ==
  # top
 top - 01:05:28 up  1:07,  2 users,  load average: 1.03, 1.07, 1.02
 Tasks:  76 total,   2 running,  74 sleeping,   0 stopped,   0 zombie
 Cpu(s): 97.9%us,  1.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st



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

[jira] [Created] (CLOUDSTACK-7410) OVS distributed routing + KVM / NameError: name 'configure_ovs_bridge_for_routing_policies' is not defined

[satoru nakaya (JIRA)]

satoru nakaya created CLOUDSTACK-7410:
-

 Summary: OVS distributed routing + KVM / NameError: name 
'configure_ovs_bridge_for_routing_policies' is not defined
 Key: CLOUDSTACK-7410
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7410
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.4.0
 Environment: Environment:
 CloudStack 4.4.0
 KVM(CentOS6.4)
 Open vSwitch 1.11.0

 VPC Offering
   :
  Connectivity:Ovs
  DistributedRouter:On

 Network Offering
   :
  Virtual Networking:Ovs
Reporter: satoru nakaya


Error is output following when you deploy VM instances in VPC.

2014-08-03 14:52:25,608 DEBUG [c.c.a.t.Request] (AgentManager-Handler-5:null) 
Seq 8-7588002422165864587: Processing: { Ans: , MgmtId: 52236007434, via: 8, 
Ver: v1, Flags: 10, 
[{com.cloud.agent.api.Answer:{result:false,details:Traceback (most 
recent call last): File 
\/usr/share/cloudstack-common/scripts/vm/network/vnet/ovstunnel.py\, line 
302, in configure_ovs_bridge_for_routing_policies(bridge, config)NameError: 
name 'configure_ovs_bridge_for_routing_policies' is not defined,wait:0}}] }
2014-08-03 14:52:25,608 DEBUG [c.c.a.t.Request] 
(Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Seq 
8-7588002422165864587: Received: { Ans: , MgmtId: 52236007434, via: 8, Ver: v1, 
Flags: 10, { Answer } }
2014-08-03 14:52:25,608 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
(Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
update the host 8 with latest routing policies.
2014-08-03 14:52:25,609 DEBUG [c.c.n.o.OvsTunnelManagerImpl] 
(Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to send 
VPC routing policy change update to host : 8. But moving on with sending the 
updates to the rest of the hosts.

:

2014-08-03 14:52:25,622 ERROR [c.c.v.VirtualMachineManagerImpl] 
(Work-Job-Executor-57:ctx-f0d66eef job-299/job-300 ctx-3845c1db) Failed to 
start instance VM[User|i-2-40-VM]
com.cloud.utils.exception.CloudRuntimeException: Failed to add VPC router 
VM[DomainRouter|r-38-VM] to guest network 
Ntwk[95583273-9dc0-4569-be29-706b28543932|Guest|15]
at 
com.cloud.network.element.VpcVirtualRouterElement.implement(VpcVirtualRouterElement.java:188)




--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-7411) VM instance does not start when you use at the same time the Region level VPC and OVS distributed routing.

[satoru nakaya (JIRA)]

satoru nakaya created CLOUDSTACK-7411:
-

 Summary: VM instance does not start when you use at the same time 
the Region level VPC and OVS distributed routing.
 Key: CLOUDSTACK-7411
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7411
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.4.0
 Environment: Environment:
 CloudStack 4.4.0
 XenServer 6.2SP1

 VPC Offering
   :
  Connectivity:Ovs
   Region Level VPC:On
   DistributedRouter:On

 Network Offering
   :
  Virtual Networking:Ovs
Reporter: satoru nakaya


VM instance does not start when you use at the same time the Region level VPC 
and OVS distributed routing.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-5811) When to run a few days a virtual router using the system service offerings of 2-core CPU, the virtual router to hang

[satoru nakaya (JIRA)]

satoru nakaya created CLOUDSTACK-5811:
-

 Summary: When to run a few days a virtual router using the system 
service offerings of 2-core CPU, the virtual router to hang
 Key: CLOUDSTACK-5811
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5811
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Virtual Router
Affects Versions: 4.1.1
 Environment: Apache CloudStack 4.1.1
CentOS 6.3 (64 bit) , CentOS 6.4 (64 bit)
Reporter: satoru nakaya


When to run a few days a virtual router using the system service offerings of 
2-core CPU, the virtual router to hang.

Hang up when using KVM.
Not hang up when using XenServer.

virtual router:
 Console screen black out
 Can not SSH connection
 No Ping response

 200% CPU usage of qemu-kvm
 # top

top - 08:54:42 up 39 days, 21:53,  1 user,  load average: 5.33, 5.06, 4.79
Tasks: 158 total,   1 running, 157 sleeping,   0 stopped,   0 zombie
Cpu(s): 75.5%us, 24.4%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:   3916176k total,  1343824k used,  2572352k free,   147740k buffers
Swap: 33409016k total,0k used, 33409016k free,   200324k cached

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
31469 root  20   0 2230m 196m 4548 S 202.5  5.1  35297:02 qemu-kvm
31702 root  20   0 1910m 192m 4548 S 192.2  5.0  35214:30 qemu-kvm
30422 root  20   0 1515m 276m 4568 S  4.0  7.2 487:06.56 qemu-kvm
1 root  20   0 19228 1488 1200 S  0.0  0.0   0:00.62 init
2 root  20   0 000 S  0.0  0.0   0:00.06 kthreadd




--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (CLOUDSTACK-5190) Change of consoleproxy.service.offering will not start the process of CloudStack.

[satoru nakaya (JIRA)]

satoru nakaya created CLOUDSTACK-5190:
-

 Summary: Change of consoleproxy.service.offering will not start 
the process of CloudStack. 
 Key: CLOUDSTACK-5190
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5190
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.1.1
 Environment: RHEL6.4 64bit
Reporter: satoru nakaya


Change of consoleproxy.service.offering will not start the process of 
CloudStack. 

1) Changed global setting for consoleproxy.service.offering to a new service 
offering. 

2) Restarted cloudstack-management service. 

3) It becomes a no response while the process of CloudStack starts. 

---
2013-11-16 21:57:03,272 INFO  [cloud.consoleproxy.ConsoleProxyManagerImpl] 
(Timer-1:null) Start configuring console proxy manager : 
ConsoleProxyManagerImpl_EnhancerByCloudStack_899a0eb8
2013-11-16 21:57:03,272 INFO  [cloud.consoleproxy.ConsoleProxyManagerImpl] 
(Timer-1:null) Console proxy max session soft limit : 50
2013-11-16 21:57:03,272 INFO  [cloud.consoleproxy.ConsoleProxyManagerImpl] 
(Timer-1:null) Console proxy standby capacity : 10
2013-11-16 21:57:03,286 DEBUG [agent.manager.AgentManagerImpl] (Timer-1:null) 
Registering listener ConsoleProxyListener with id 18
---

 No response.


*consoleproxy.service.offering of a database is edited into null. 
 It restores by process reboot. 





--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (CLOUDSTACK-2905) Recurring Snapshots are failing becuase of NullPointerException.

[satoru nakaya (JIRA)]

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

satoru nakaya commented on CLOUDSTACK-2905:
---

Thank you so much. :)

 Recurring Snapshots are failing becuase of NullPointerException.
 

 Key: CLOUDSTACK-2905
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2905
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.1.0, 4.2.0
 Environment: cloudstack-management-4.1.0-0.el6.x86_64
Reporter: satoru nakaya
Assignee: Rajesh Battala
Priority: Blocker
 Fix For: 4.1.1, 4.2.0


 Create an Hourly Recurring snapshot policy on the ROOT disk.
 Snapshot policy gets created successfully.
 But when it is time to create a snapshot, snapshot scheduler thread 
 encounters a NullPointer Exception:
 Management server logs:
 # tail -f management-server.log  | grep SnapshotSchedulerImpl
 2013-06-08 08:06:11,393 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
 (SnapshotPollTask:null) Snapshot scheduler.poll is being called at 2013-06-07 
 23:06:11 GMT
 2013-06-08 08:06:11,395 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
 (SnapshotPollTask:null) Got 0 snapshots to be executed at 2013-06-07 23:06:11 
 GMT
 2013-06-08 08:08:39,459 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
 (catalina-exec-4:null) Current time is 2013-06-07 23:06:11 GMT. 
 NextScheduledTime of policyId 1 is 2013-06-07 23:10:00 GMT
 2013-06-08 08:11:11,393 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
 (SnapshotPollTask:null) Snapshot scheduler.poll is being called at 2013-06-07 
 23:11:11 GMT
 2013-06-08 08:11:11,397 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
 (SnapshotPollTask:null) Got 1 snapshots to be executed at 2013-06-07 23:11:11 
 GMT
 2013-06-08 08:11:11,400 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
 (SnapshotPollTask:null) Scheduling 1 snapshot for volume 3 for schedule id: 1 
 at 2013-06-07 23:10:00 GMT
 2013-06-08 08:11:11,453 WARN  [storage.snapshot.SnapshotSchedulerImpl] 
 (SnapshotPollTask:null) Scheduling snapshot failed due to 
 java.lang.NullPointerException

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (CLOUDSTACK-2905) Recurring Snapshots are failing becuase of NullPointerException.

[satoru nakaya (JIRA)]

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

satoru nakaya closed CLOUDSTACK-2905.
-


 Recurring Snapshots are failing becuase of NullPointerException.
 

 Key: CLOUDSTACK-2905
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2905
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.1.0, 4.2.0
 Environment: cloudstack-management-4.1.0-0.el6.x86_64
Reporter: satoru nakaya
Assignee: Rajesh Battala
Priority: Blocker
 Fix For: 4.1.1, 4.2.0


 Create an Hourly Recurring snapshot policy on the ROOT disk.
 Snapshot policy gets created successfully.
 But when it is time to create a snapshot, snapshot scheduler thread 
 encounters a NullPointer Exception:
 Management server logs:
 # tail -f management-server.log  | grep SnapshotSchedulerImpl
 2013-06-08 08:06:11,393 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
 (SnapshotPollTask:null) Snapshot scheduler.poll is being called at 2013-06-07 
 23:06:11 GMT
 2013-06-08 08:06:11,395 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
 (SnapshotPollTask:null) Got 0 snapshots to be executed at 2013-06-07 23:06:11 
 GMT
 2013-06-08 08:08:39,459 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
 (catalina-exec-4:null) Current time is 2013-06-07 23:06:11 GMT. 
 NextScheduledTime of policyId 1 is 2013-06-07 23:10:00 GMT
 2013-06-08 08:11:11,393 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
 (SnapshotPollTask:null) Snapshot scheduler.poll is being called at 2013-06-07 
 23:11:11 GMT
 2013-06-08 08:11:11,397 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
 (SnapshotPollTask:null) Got 1 snapshots to be executed at 2013-06-07 23:11:11 
 GMT
 2013-06-08 08:11:11,400 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
 (SnapshotPollTask:null) Scheduling 1 snapshot for volume 3 for schedule id: 1 
 at 2013-06-07 23:10:00 GMT
 2013-06-08 08:11:11,453 WARN  [storage.snapshot.SnapshotSchedulerImpl] 
 (SnapshotPollTask:null) Scheduling snapshot failed due to 
 java.lang.NullPointerException

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CLOUDSTACK-3457) Language: Japanese. Nothing is displayed on a screen after login.

[satoru nakaya (JIRA)]

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

satoru nakaya commented on CLOUDSTACK-3457:
---

Hi Milamber.

I retested with latest 4.2 branch.
Works fine in Japanese.
Thank you so much.
:-)


 Language: Japanese. Nothing is displayed on a screen after login. 
 --

 Key: CLOUDSTACK-3457
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3457
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.2.0
 Environment: Management Server : CentOS 6.3
Reporter: satoru nakaya
Assignee: Milamber
Priority: Critical
 Fix For: 4.2.0


 1. Language : Choose Japanese. 
 2. Log in. 
 3. Nothing is displayed on a screen after login.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (CLOUDSTACK-3457) Language: Japanese. Nothing is displayed on a screen after login.

[satoru nakaya (JIRA)]

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

satoru nakaya closed CLOUDSTACK-3457.
-

Resolution: Fixed

 Language: Japanese. Nothing is displayed on a screen after login. 
 --

 Key: CLOUDSTACK-3457
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3457
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.2.0
 Environment: Management Server : CentOS 6.3
Reporter: satoru nakaya
Assignee: Milamber
Priority: Critical
 Fix For: 4.2.0


 1. Language : Choose Japanese. 
 2. Log in. 
 3. Nothing is displayed on a screen after login.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CLOUDSTACK-3457) Language: Japanese. Nothing is displayed on a screen after login.

[satoru nakaya (JIRA)]

satoru nakaya created CLOUDSTACK-3457:
-

 Summary: Language: Japanese. Nothing is displayed on a screen 
after login. 
 Key: CLOUDSTACK-3457
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3457
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.2.0
 Environment: Management Server : CentOS 6.3
Reporter: satoru nakaya


1. Language : Choose Japanese. 
2. Log in. 
3. Nothing is displayed on a screen after login.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CLOUDSTACK-2926) An virtual machine instance cannot be started in a mixed hypervisor environment.

[satoru nakaya (JIRA)]

satoru nakaya created CLOUDSTACK-2926:
-

 Summary: An virtual machine instance cannot be started in a mixed 
hypervisor environment.
 Key: CLOUDSTACK-2926
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2926
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.1.0
 Environment: XenServer 6.0.2
VMware vSphere 5 update 1
Reporter: satoru nakaya


1.Create XenServer cluster and primary storage.
2.Create VMware cluster and primary storage.
3.Create Instance in VMware cluster.

An virtual machine instance cannot be started in VMware cluster.


management-server.log:

   :
2013-06-11 10:57:24,427 WARN  [agent.manager.AgentManagerImpl] 
(Job-Executor-12:job-12) Unsupported Command: Unsupported command 
issued:com.cloud.agent.api.storage.PrimaryStorageDownloadCommand.  Are you sure 
you got the right type of server?
2013-06-11 10:57:24,427 DEBUG [agent.manager.AgentManagerImpl] 
(Job-Executor-12:job-12) Details from executing class 
com.cloud.agent.api.storage.PrimaryStorageDownloadCommand: Unsupported command 
issued:com.cloud.agent.api.storage.PrimaryStorageDownloadCommand.  Are you sure 
you got the right type of server?
2013-06-11 10:57:24,429 ERROR [cloud.vm.VirtualMachineManagerImpl] 
(Job-Executor-12:job-12) Failed to start instance VM[DomainRouter|r-4-VM]
java.lang.ClassCastException: com.cloud.agent.api.UnsupportedAnswer cannot be 
cast to com.cloud.agent.api.storage.PrimaryStorageDownloadAnswer
at 
com.cloud.template.TemplateManagerImpl.prepareTemplateForCreate(TemplateManagerImpl.java:647)
at 
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at 
com.cloud.storage.StorageManagerImpl.createVolume(StorageManagerImpl.java:3587)
at 
com.cloud.storage.StorageManagerImpl.prepare(StorageManagerImpl.java:3478)
at 
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:748)
at 
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:471)
at 
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.start(VirtualNetworkApplianceManagerImpl.java:2615)
at 
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startVirtualRouter(VirtualNetworkApplianceManagerImpl.java:1824)
at 
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.startRouters(VirtualNetworkApplianceManagerImpl.java:1924)
at 
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.deployVirtualRouterInGuestNetwork(VirtualNetworkApplianceManagerImpl.java:1902)
at 
com.cloud.network.element.VirtualRouterElement.prepare(VirtualRouterElement.java:208)
at 
com.cloud.network.NetworkManagerImpl.prepareElement(NetworkManagerImpl.java:1541)
at 
com.cloud.network.NetworkManagerImpl.prepareNic(NetworkManagerImpl.java:1658)
at 
com.cloud.network.NetworkManagerImpl.prepare(NetworkManagerImpl.java:1599)
at 
com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:746)
at 
com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:471)
at 
org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:212)
at 
org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209)
at 
com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3865)
at 
com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3458)
at 
com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3444)
at 
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at 
org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:379)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:162)
at 
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:679)

   :

2013-06-11 10:57:25,025 INFO  [cloud.vm.VirtualMachineManagerImpl] 
(Job-Executor-12:job-12) Unable to contact resource.
com.cloud.exception.AgentUnavailableException: Resource [Host:5] is 

[jira] [Created] (CLOUDSTACK-2907) In the case of a VMware HyperVisor,Sample Template (CentOS 5.3(64-bit) no GUI (vSphere)) download does not start.

[satoru nakaya (JIRA)]

satoru nakaya created CLOUDSTACK-2907:
-

 Summary: In the case of a VMware HyperVisor,Sample Template 
(CentOS 5.3(64-bit) no GUI (vSphere)) download does not start.
 Key: CLOUDSTACK-2907
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2907
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.0.2
 Environment: Apache CloudStack 4.0.2
VMware vSphere 5.0 update 1
Reporter: satoru nakaya


Registration of VMware Cluster is successful.
System VM starting is successful.
But,Sample Template (CentOS 5.3(64-bit) no GUI (vSphere)) download does not 
start.
And It is not displayed on a template list.

#Only VMware HyperVisor is used. 
#Other hypervisors, such as Xen or kvm, do not use it. 

#In addition, It is operating normally in the same environment 4.0.0. 
#Only in the case of 4.0.2, it happens.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CLOUDSTACK-2908) An automatic start setup is not carried out after cloudstack-usage installation.

[satoru nakaya (JIRA)]

satoru nakaya created CLOUDSTACK-2908:
-

 Summary: An automatic start setup is not carried out after 
cloudstack-usage installation. 
 Key: CLOUDSTACK-2908
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2908
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Install and Setup
Affects Versions: 4.1.0
 Environment: cloudstack-usage-4.1.0-0.el6.x86_64
Reporter: satoru nakaya
Priority: Trivial


An automatic start setup is not carried out after cloudstack-usage 
installation. 

# yum install cloudstack-usage -y --nogpgcheck
# chkconfig --list | grep cloud
cloudstack-management   0:off   1:off   2:off   3:on4:on5:on6:off
#

You have to carry out an automatic start setup manually. 
# chkconfig --add cloudstack-usage

In version 4.0.x, it was set up automatically.

# chkconfig --list | grep cloud
cloud-management0:off   1:off   2:on3:on4:on5:on6:off
cloud-usage 0:off   1:off   2:off   3:on4:on5:on6:off
#


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CLOUDSTACK-2905) Recurring Snapshots are failing becuase of NullPointerException.

[satoru nakaya (JIRA)]

satoru nakaya created CLOUDSTACK-2905:
-

 Summary: Recurring Snapshots are failing becuase of 
NullPointerException.
 Key: CLOUDSTACK-2905
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2905
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.1.0
 Environment: cloudstack-management-4.1.0-0.el6.x86_64
Reporter: satoru nakaya


Create an Hourly Recurring snapshot policy on the ROOT disk.
Snapshot policy gets created successfully.
But when it is time to create a snapshot, snapshot scheduler thread encounters 
a NullPointer Exception:
Management server logs:

# tail -f management-server.log  | grep SnapshotSchedulerImpl
2013-06-08 08:06:11,393 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
(SnapshotPollTask:null) Snapshot scheduler.poll is being called at 2013-06-07 
23:06:11 GMT
2013-06-08 08:06:11,395 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
(SnapshotPollTask:null) Got 0 snapshots to be executed at 2013-06-07 23:06:11 
GMT
2013-06-08 08:08:39,459 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
(catalina-exec-4:null) Current time is 2013-06-07 23:06:11 GMT. 
NextScheduledTime of policyId 1 is 2013-06-07 23:10:00 GMT
2013-06-08 08:11:11,393 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
(SnapshotPollTask:null) Snapshot scheduler.poll is being called at 2013-06-07 
23:11:11 GMT
2013-06-08 08:11:11,397 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
(SnapshotPollTask:null) Got 1 snapshots to be executed at 2013-06-07 23:11:11 
GMT
2013-06-08 08:11:11,400 DEBUG [storage.snapshot.SnapshotSchedulerImpl] 
(SnapshotPollTask:null) Scheduling 1 snapshot for volume 3 for schedule id: 1 
at 2013-06-07 23:10:00 GMT
2013-06-08 08:11:11,453 WARN  [storage.snapshot.SnapshotSchedulerImpl] 
(SnapshotPollTask:null) Scheduling snapshot failed due to 
java.lang.NullPointerException

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira