[jira] [Created] (CLOUDSTACK-9058) Password server causes Windows VMs to switch to blank passwords after each reboot
dsclose created CLOUDSTACK-9058: --- Summary: Password server causes Windows VMs to switch to blank passwords after each reboot Key: CLOUDSTACK-9058 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9058 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: ISO, Virtual Router Affects Versions: 4.5.2 Reporter: dsclose Priority: Critical Previous versions of the systemvm.iso used a shell script to serve passwords. In response to a "send_my_password" query, if no password was to be served, the /opt/cloud/bin/serve_password.sh script would issue a response with "saved_password" in the body. The new version of the systemvm.iso supercedes serve_password.sh with a python script at /opt/cloud/bin/passwd_server_ip.py. This script's behaviour is different to the original serve_password.sh. In response to a "send_my_password" query, if no password was to be served, the /opt/cloud/bin/passwd_server_ip.py script issues an empty response. Linux guests handle this appropriately. The cloud-set-guest-password init script uses a case statement to ignore blank responses. I've not been able to examine the code for the equivalent Windows guest service but it responds very differently. If a Windows guest receives a blank response from the password server then it assumes that the password needs to be blank. The log on the windows guest reports the following: [INFO] Need to set new password for this VM. First letter in password : [INFO] New password has been set for this VM The windows guest expects a "saved_password" response if a password isn't being issued. If it receives this response then it logs the following: [INFO] No need to set password, because http://10.1.1.1:8080/ said so with response saved_password Because the password server is queried every time the windows service starts, this will result in the guest adopting a blank password every time it is rebooted or the service is restarted. It's probably unrealistic to consider updating the Windows service in every guest currently running in cloudstack. As such it looks like the password server's behaviour needs to be adjusted to match the behaviour that guests expect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9058) Password server causes Windows VMs to switch to blank passwords after each reboot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15001826#comment-15001826 ] ASF GitHub Bot commented on CLOUDSTACK-9058: GitHub user dsclose opened a pull request: https://github.com/apache/cloudstack/pull/1062 CLOUDSTACK-9058 Respond with "saved_password" if no password is to be issued. You can merge this pull request into a Git repository by running: $ git pull https://github.com/dsclose/cloudstack CLOUDSTACK-9058 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1062.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1062 commit 8a7deefe64cab0b3c49ebc510c6524b1fad1f884 Author: dsclose Date: 2015-11-12T08:05:57Z CLOUDSTACK-9058 Respond with "saved_password" if no password is to be issued. > Password server causes Windows VMs to switch to blank passwords after each > reboot > - > > Key: CLOUDSTACK-9058 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9058 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, Virtual Router >Affects Versions: 4.5.2 >Reporter: dsclose >Priority: Critical > > Previous versions of the systemvm.iso used a shell script to serve passwords. > In response to a "send_my_password" query, if no password was to be served, > the /opt/cloud/bin/serve_password.sh script would issue a response with > "saved_password" in the body. > The new version of the systemvm.iso supercedes serve_password.sh with a > python script at /opt/cloud/bin/passwd_server_ip.py. This script's behaviour > is different to the original serve_password.sh. In response to a > "send_my_password" query, if no password was to be served, the > /opt/cloud/bin/passwd_server_ip.py script issues an empty response. > Linux guests handle this appropriately. The cloud-set-guest-password init > script uses a case statement to ignore blank responses. I've not been able to > examine the code for the equivalent Windows guest service but it responds > very differently. > If a Windows guest receives a blank response from the password server then it > assumes that the password needs to be blank. The log on the windows guest > reports the following: > [INFO] Need to set new password for this VM. First letter in password : > [INFO] New password has been set for this VM > The windows guest expects a "saved_password" response if a password isn't > being issued. If it receives this response then it logs the following: > [INFO] No need to set password, because http://10.1.1.1:8080/ said so with > response saved_password > Because the password server is queried every time the windows service starts, > this will result in the guest adopting a blank password every time it is > rebooted or the service is restarted. It's probably unrealistic to consider > updating the Windows service in every guest currently running in cloudstack. > As such it looks like the password server's behaviour needs to be adjusted to > match the behaviour that guests expect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9058) Password server causes Windows VMs to switch to blank passwords after each reboot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15001827#comment-15001827 ] dsclose commented on CLOUDSTACK-9058: - Solved the issue with a minor change to the /opt/cloud/bin/passwd_server_ip.py Created pull request at https://github.com/apache/cloudstack/pull/1062 > Password server causes Windows VMs to switch to blank passwords after each > reboot > - > > Key: CLOUDSTACK-9058 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9058 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, Virtual Router >Affects Versions: 4.5.2 >Reporter: dsclose >Priority: Critical > > Previous versions of the systemvm.iso used a shell script to serve passwords. > In response to a "send_my_password" query, if no password was to be served, > the /opt/cloud/bin/serve_password.sh script would issue a response with > "saved_password" in the body. > The new version of the systemvm.iso supercedes serve_password.sh with a > python script at /opt/cloud/bin/passwd_server_ip.py. This script's behaviour > is different to the original serve_password.sh. In response to a > "send_my_password" query, if no password was to be served, the > /opt/cloud/bin/passwd_server_ip.py script issues an empty response. > Linux guests handle this appropriately. The cloud-set-guest-password init > script uses a case statement to ignore blank responses. I've not been able to > examine the code for the equivalent Windows guest service but it responds > very differently. > If a Windows guest receives a blank response from the password server then it > assumes that the password needs to be blank. The log on the windows guest > reports the following: > [INFO] Need to set new password for this VM. First letter in password : > [INFO] New password has been set for this VM > The windows guest expects a "saved_password" response if a password isn't > being issued. If it receives this response then it logs the following: > [INFO] No need to set password, because http://10.1.1.1:8080/ said so with > response saved_password > Because the password server is queried every time the windows service starts, > this will result in the guest adopting a blank password every time it is > rebooted or the service is restarted. It's probably unrealistic to consider > updating the Windows service in every guest currently running in cloudstack. > As such it looks like the password server's behaviour needs to be adjusted to > match the behaviour that guests expect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9050) Virtual Router Static-NAT rules bind to wrong public interface
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15001829#comment-15001829 ] ASF GitHub Bot commented on CLOUDSTACK-9050: GitHub user dsclose opened a pull request: https://github.com/apache/cloudstack/pull/1063 CLOUDSTACK-9050 Changed grep to match IP address only. Solves issue where virtual router was NATing IP addresses to the wrong interface if the IP address was a substring of the broadcast address on another interface. You can merge this pull request into a Git repository by running: $ git pull https://github.com/dsclose/cloudstack CLOUDSTACK-9050 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1063.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1063 commit e15195bf889ff372589b5a903d91ec5fd6cecb48 Author: dsclose Date: 2015-11-10T08:50:44Z CLOUDSTACK-9050 - Match IP address only. Virtual router was NATing IP addresses to the wrong interface if the IP address was a substring of the broadcast address on another interface. > Virtual Router Static-NAT rules bind to wrong public interface > -- > > Key: CLOUDSTACK-9050 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9050 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, Virtual Router >Affects Versions: 4.5.2 >Reporter: dsclose > > When a virtual router has multiple public NICs (in a scenario where multiple > guest subnets are available) the router is liable to create static-NAT rules > for certain IP addresses that refer to incorrect interfaces. > Example > -- > A /24 has been divided into a /25 and two /26 ranges. The /25 and one /26 are > used for guest IP addresses. This may lead to the following IP addresses > being assigned to a virtual router: > eth0: 10.1.1.1/24 > eth1: 169.254.3.82/16 > eth2: 123.123.123.130/26 and 123.123.123.150/26 > eth3: 123.123.123.19/25 and 123.123.123.120/25 > Scenario: > The user decides to create two static NATs. One from 123.123.123.120/25, the > other from 123.123.123.19/25, both to hosts on the 10.1.1.0/24 range. > Result: > 123.123.123.120/25 is successfully configured as a static NAT and works > immediately. All NAT rules in the resulting iptables correctly refer to eth3 > as the source or destination interface. Cloudstack reports that > 123.123.123.19/25 is successfully configured but it does not work. All NAT > rules in the resulting iptables INCORRECTLY refer to eth2 as the source or > destination interface. > Cause: > The virtual router greps the output of "ip addr show dev ethN" until it finds > the IP address. However, this command also prints out the broadcast address > for the subnet which may partially include an IP address from a similar > range. In the above example, 123.123.123.19/25 was INCORRECTLY NAT'd to eth2 > because the IP address was matched by the broadcast address of > 123.123.123.191. > This is liable to occur on any router with NICs on two similar subnets. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8818) Python scripts should depend on mysql.connector instead of MySQLdb
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15001948#comment-15001948 ] ASF GitHub Bot commented on CLOUDSTACK-8818: Github user wido commented on the pull request: https://github.com/apache/cloudstack/pull/1054#issuecomment-156067993 @DaanHoogland Thanks! Now, that failure has nothing to do with this Python code :) > Python scripts should depend on mysql.connector instead of MySQLdb > -- > > Key: CLOUDSTACK-8818 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8818 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wido den Hollander > Labels: mysql, python, python3 > > Our current Python scripts depend on MySQLdb for MySQL connections. > The best way to go is the native mysql.connector which implements the MySQL > protocol in native Python instead of depending on external libraries. > It would be best if we drop MySQLdb and use mysql.connector since that also > supports Python 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9058) Password server causes Windows VMs to switch to blank passwords after each reboot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002006#comment-15002006 ] ASF GitHub Bot commented on CLOUDSTACK-9058: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1062#issuecomment-156090369 @dsclose Thanks for the fix. Can you please make the title of the PR a bit more descriptive? > Password server causes Windows VMs to switch to blank passwords after each > reboot > - > > Key: CLOUDSTACK-9058 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9058 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, Virtual Router >Affects Versions: 4.5.2 >Reporter: dsclose >Priority: Critical > > Previous versions of the systemvm.iso used a shell script to serve passwords. > In response to a "send_my_password" query, if no password was to be served, > the /opt/cloud/bin/serve_password.sh script would issue a response with > "saved_password" in the body. > The new version of the systemvm.iso supercedes serve_password.sh with a > python script at /opt/cloud/bin/passwd_server_ip.py. This script's behaviour > is different to the original serve_password.sh. In response to a > "send_my_password" query, if no password was to be served, the > /opt/cloud/bin/passwd_server_ip.py script issues an empty response. > Linux guests handle this appropriately. The cloud-set-guest-password init > script uses a case statement to ignore blank responses. I've not been able to > examine the code for the equivalent Windows guest service but it responds > very differently. > If a Windows guest receives a blank response from the password server then it > assumes that the password needs to be blank. The log on the windows guest > reports the following: > [INFO] Need to set new password for this VM. First letter in password : > [INFO] New password has been set for this VM > The windows guest expects a "saved_password" response if a password isn't > being issued. If it receives this response then it logs the following: > [INFO] No need to set password, because http://10.1.1.1:8080/ said so with > response saved_password > Because the password server is queried every time the windows service starts, > this will result in the guest adopting a blank password every time it is > rebooted or the service is restarted. It's probably unrealistic to consider > updating the Windows service in every guest currently running in cloudstack. > As such it looks like the password server's behaviour needs to be adjusted to > match the behaviour that guests expect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9050) Virtual Router Static-NAT rules bind to wrong public interface
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002007#comment-15002007 ] ASF GitHub Bot commented on CLOUDSTACK-9050: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1063#issuecomment-156090668 @dsclose Thanks for the fix. Can you please make the title of the PR a bit more descriptive? How did you test this? Were any Marvin integration tests run? > Virtual Router Static-NAT rules bind to wrong public interface > -- > > Key: CLOUDSTACK-9050 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9050 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, Virtual Router >Affects Versions: 4.5.2 >Reporter: dsclose > > When a virtual router has multiple public NICs (in a scenario where multiple > guest subnets are available) the router is liable to create static-NAT rules > for certain IP addresses that refer to incorrect interfaces. > Example > -- > A /24 has been divided into a /25 and two /26 ranges. The /25 and one /26 are > used for guest IP addresses. This may lead to the following IP addresses > being assigned to a virtual router: > eth0: 10.1.1.1/24 > eth1: 169.254.3.82/16 > eth2: 123.123.123.130/26 and 123.123.123.150/26 > eth3: 123.123.123.19/25 and 123.123.123.120/25 > Scenario: > The user decides to create two static NATs. One from 123.123.123.120/25, the > other from 123.123.123.19/25, both to hosts on the 10.1.1.0/24 range. > Result: > 123.123.123.120/25 is successfully configured as a static NAT and works > immediately. All NAT rules in the resulting iptables correctly refer to eth3 > as the source or destination interface. Cloudstack reports that > 123.123.123.19/25 is successfully configured but it does not work. All NAT > rules in the resulting iptables INCORRECTLY refer to eth2 as the source or > destination interface. > Cause: > The virtual router greps the output of "ip addr show dev ethN" until it finds > the IP address. However, this command also prints out the broadcast address > for the subnet which may partially include an IP address from a similar > range. In the above example, 123.123.123.19/25 was INCORRECTLY NAT'd to eth2 > because the IP address was matched by the broadcast address of > 123.123.123.191. > This is liable to occur on any router with NICs on two similar subnets. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9058) Password server causes Windows VMs to switch to blank passwords after each reboot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002009#comment-15002009 ] ASF GitHub Bot commented on CLOUDSTACK-9058: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1062#issuecomment-156090995 There is a Marvin test regarding passwords and such. Did you run that to see if it still passes? > Password server causes Windows VMs to switch to blank passwords after each > reboot > - > > Key: CLOUDSTACK-9058 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9058 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, Virtual Router >Affects Versions: 4.5.2 >Reporter: dsclose >Priority: Critical > > Previous versions of the systemvm.iso used a shell script to serve passwords. > In response to a "send_my_password" query, if no password was to be served, > the /opt/cloud/bin/serve_password.sh script would issue a response with > "saved_password" in the body. > The new version of the systemvm.iso supercedes serve_password.sh with a > python script at /opt/cloud/bin/passwd_server_ip.py. This script's behaviour > is different to the original serve_password.sh. In response to a > "send_my_password" query, if no password was to be served, the > /opt/cloud/bin/passwd_server_ip.py script issues an empty response. > Linux guests handle this appropriately. The cloud-set-guest-password init > script uses a case statement to ignore blank responses. I've not been able to > examine the code for the equivalent Windows guest service but it responds > very differently. > If a Windows guest receives a blank response from the password server then it > assumes that the password needs to be blank. The log on the windows guest > reports the following: > [INFO] Need to set new password for this VM. First letter in password : > [INFO] New password has been set for this VM > The windows guest expects a "saved_password" response if a password isn't > being issued. If it receives this response then it logs the following: > [INFO] No need to set password, because http://10.1.1.1:8080/ said so with > response saved_password > Because the password server is queried every time the windows service starts, > this will result in the guest adopting a blank password every time it is > rebooted or the service is restarted. It's probably unrealistic to consider > updating the Windows service in every guest currently running in cloudstack. > As such it looks like the password server's behaviour needs to be adjusted to > match the behaviour that guests expect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9050) Virtual Router Static-NAT rules bind to wrong public interface
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002062#comment-15002062 ] ASF GitHub Bot commented on CLOUDSTACK-9050: Github user dsclose commented on the pull request: https://github.com/apache/cloudstack/pull/1063#issuecomment-156103018 I've only used situational tests for this fix. I'll looking into the docs regarding getting the integration tests up and running and will get back to you in the next few days. > Virtual Router Static-NAT rules bind to wrong public interface > -- > > Key: CLOUDSTACK-9050 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9050 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, Virtual Router >Affects Versions: 4.5.2 >Reporter: dsclose > > When a virtual router has multiple public NICs (in a scenario where multiple > guest subnets are available) the router is liable to create static-NAT rules > for certain IP addresses that refer to incorrect interfaces. > Example > -- > A /24 has been divided into a /25 and two /26 ranges. The /25 and one /26 are > used for guest IP addresses. This may lead to the following IP addresses > being assigned to a virtual router: > eth0: 10.1.1.1/24 > eth1: 169.254.3.82/16 > eth2: 123.123.123.130/26 and 123.123.123.150/26 > eth3: 123.123.123.19/25 and 123.123.123.120/25 > Scenario: > The user decides to create two static NATs. One from 123.123.123.120/25, the > other from 123.123.123.19/25, both to hosts on the 10.1.1.0/24 range. > Result: > 123.123.123.120/25 is successfully configured as a static NAT and works > immediately. All NAT rules in the resulting iptables correctly refer to eth3 > as the source or destination interface. Cloudstack reports that > 123.123.123.19/25 is successfully configured but it does not work. All NAT > rules in the resulting iptables INCORRECTLY refer to eth2 as the source or > destination interface. > Cause: > The virtual router greps the output of "ip addr show dev ethN" until it finds > the IP address. However, this command also prints out the broadcast address > for the subnet which may partially include an IP address from a similar > range. In the above example, 123.123.123.19/25 was INCORRECTLY NAT'd to eth2 > because the IP address was matched by the broadcast address of > 123.123.123.191. > This is liable to occur on any router with NICs on two similar subnets. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9058) Password server causes Windows VMs to switch to blank passwords after each reboot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002065#comment-15002065 ] ASF GitHub Bot commented on CLOUDSTACK-9058: Github user dsclose commented on the pull request: https://github.com/apache/cloudstack/pull/1062#issuecomment-156103338 As with my other pull request, I only used situational tests for this. I'll look into the docs to get the marvin tests up and running and will update this issue in a few days. > Password server causes Windows VMs to switch to blank passwords after each > reboot > - > > Key: CLOUDSTACK-9058 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9058 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, Virtual Router >Affects Versions: 4.5.2 >Reporter: dsclose >Priority: Critical > > Previous versions of the systemvm.iso used a shell script to serve passwords. > In response to a "send_my_password" query, if no password was to be served, > the /opt/cloud/bin/serve_password.sh script would issue a response with > "saved_password" in the body. > The new version of the systemvm.iso supercedes serve_password.sh with a > python script at /opt/cloud/bin/passwd_server_ip.py. This script's behaviour > is different to the original serve_password.sh. In response to a > "send_my_password" query, if no password was to be served, the > /opt/cloud/bin/passwd_server_ip.py script issues an empty response. > Linux guests handle this appropriately. The cloud-set-guest-password init > script uses a case statement to ignore blank responses. I've not been able to > examine the code for the equivalent Windows guest service but it responds > very differently. > If a Windows guest receives a blank response from the password server then it > assumes that the password needs to be blank. The log on the windows guest > reports the following: > [INFO] Need to set new password for this VM. First letter in password : > [INFO] New password has been set for this VM > The windows guest expects a "saved_password" response if a password isn't > being issued. If it receives this response then it logs the following: > [INFO] No need to set password, because http://10.1.1.1:8080/ said so with > response saved_password > Because the password server is queried every time the windows service starts, > this will result in the guest adopting a blank password every time it is > rebooted or the service is restarted. It's probably unrealistic to consider > updating the Windows service in every guest currently running in cloudstack. > As such it looks like the password server's behaviour needs to be adjusted to > match the behaviour that guests expect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9058) Password server causes Windows VMs to switch to blank passwords after each reboot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002156#comment-15002156 ] ASF GitHub Bot commented on CLOUDSTACK-9058: Github user ustcweizhou commented on the pull request: https://github.com/apache/cloudstack/pull/1062#issuecomment-156116335 In old password server (serve_password.sh), it return "saved_password" if the password is empty. now it is set to empty in passwd_server_ip.py. our script for linux (cloud-set-guest-password.in) can deal with them very well. I donot have the source code of the windows application for password. If the issue does exist, we need to apply this PR for backward compatibility. > Password server causes Windows VMs to switch to blank passwords after each > reboot > - > > Key: CLOUDSTACK-9058 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9058 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, Virtual Router >Affects Versions: 4.5.2 >Reporter: dsclose >Priority: Critical > > Previous versions of the systemvm.iso used a shell script to serve passwords. > In response to a "send_my_password" query, if no password was to be served, > the /opt/cloud/bin/serve_password.sh script would issue a response with > "saved_password" in the body. > The new version of the systemvm.iso supercedes serve_password.sh with a > python script at /opt/cloud/bin/passwd_server_ip.py. This script's behaviour > is different to the original serve_password.sh. In response to a > "send_my_password" query, if no password was to be served, the > /opt/cloud/bin/passwd_server_ip.py script issues an empty response. > Linux guests handle this appropriately. The cloud-set-guest-password init > script uses a case statement to ignore blank responses. I've not been able to > examine the code for the equivalent Windows guest service but it responds > very differently. > If a Windows guest receives a blank response from the password server then it > assumes that the password needs to be blank. The log on the windows guest > reports the following: > [INFO] Need to set new password for this VM. First letter in password : > [INFO] New password has been set for this VM > The windows guest expects a "saved_password" response if a password isn't > being issued. If it receives this response then it logs the following: > [INFO] No need to set password, because http://10.1.1.1:8080/ said so with > response saved_password > Because the password server is queried every time the windows service starts, > this will result in the guest adopting a blank password every time it is > rebooted or the service is restarted. It's probably unrealistic to consider > updating the Windows service in every guest currently running in cloudstack. > As such it looks like the password server's behaviour needs to be adjusted to > match the behaviour that guests expect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9050) Virtual Router Static-NAT rules bind to wrong public interface
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002165#comment-15002165 ] ASF GitHub Bot commented on CLOUDSTACK-9050: Github user ustcweizhou commented on the pull request: https://github.com/apache/cloudstack/pull/1063#issuecomment-156118661 LGTM the similar issue happened several times in our scripts. We should use more precise expression when we use sed/grep, etc > Virtual Router Static-NAT rules bind to wrong public interface > -- > > Key: CLOUDSTACK-9050 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9050 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, Virtual Router >Affects Versions: 4.5.2 >Reporter: dsclose > > When a virtual router has multiple public NICs (in a scenario where multiple > guest subnets are available) the router is liable to create static-NAT rules > for certain IP addresses that refer to incorrect interfaces. > Example > -- > A /24 has been divided into a /25 and two /26 ranges. The /25 and one /26 are > used for guest IP addresses. This may lead to the following IP addresses > being assigned to a virtual router: > eth0: 10.1.1.1/24 > eth1: 169.254.3.82/16 > eth2: 123.123.123.130/26 and 123.123.123.150/26 > eth3: 123.123.123.19/25 and 123.123.123.120/25 > Scenario: > The user decides to create two static NATs. One from 123.123.123.120/25, the > other from 123.123.123.19/25, both to hosts on the 10.1.1.0/24 range. > Result: > 123.123.123.120/25 is successfully configured as a static NAT and works > immediately. All NAT rules in the resulting iptables correctly refer to eth3 > as the source or destination interface. Cloudstack reports that > 123.123.123.19/25 is successfully configured but it does not work. All NAT > rules in the resulting iptables INCORRECTLY refer to eth2 as the source or > destination interface. > Cause: > The virtual router greps the output of "ip addr show dev ethN" until it finds > the IP address. However, this command also prints out the broadcast address > for the subnet which may partially include an IP address from a similar > range. In the above example, 123.123.123.19/25 was INCORRECTLY NAT'd to eth2 > because the IP address was matched by the broadcast address of > 123.123.123.191. > This is liable to occur on any router with NICs on two similar subnets. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9050) Virtual Router Static-NAT rules bind to wrong public interface
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002169#comment-15002169 ] ASF GitHub Bot commented on CLOUDSTACK-9050: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1063#issuecomment-156119598 @wilderrodrigues Are these scripts still used in master/4.6? > Virtual Router Static-NAT rules bind to wrong public interface > -- > > Key: CLOUDSTACK-9050 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9050 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, Virtual Router >Affects Versions: 4.5.2 >Reporter: dsclose > > When a virtual router has multiple public NICs (in a scenario where multiple > guest subnets are available) the router is liable to create static-NAT rules > for certain IP addresses that refer to incorrect interfaces. > Example > -- > A /24 has been divided into a /25 and two /26 ranges. The /25 and one /26 are > used for guest IP addresses. This may lead to the following IP addresses > being assigned to a virtual router: > eth0: 10.1.1.1/24 > eth1: 169.254.3.82/16 > eth2: 123.123.123.130/26 and 123.123.123.150/26 > eth3: 123.123.123.19/25 and 123.123.123.120/25 > Scenario: > The user decides to create two static NATs. One from 123.123.123.120/25, the > other from 123.123.123.19/25, both to hosts on the 10.1.1.0/24 range. > Result: > 123.123.123.120/25 is successfully configured as a static NAT and works > immediately. All NAT rules in the resulting iptables correctly refer to eth3 > as the source or destination interface. Cloudstack reports that > 123.123.123.19/25 is successfully configured but it does not work. All NAT > rules in the resulting iptables INCORRECTLY refer to eth2 as the source or > destination interface. > Cause: > The virtual router greps the output of "ip addr show dev ethN" until it finds > the IP address. However, this command also prints out the broadcast address > for the subnet which may partially include an IP address from a similar > range. In the above example, 123.123.123.19/25 was INCORRECTLY NAT'd to eth2 > because the IP address was matched by the broadcast address of > 123.123.123.191. > This is liable to occur on any router with NICs on two similar subnets. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9058) Password server causes Windows VMs to switch to blank passwords after each reboot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002173#comment-15002173 ] ASF GitHub Bot commented on CLOUDSTACK-9058: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1062#issuecomment-156121380 @dsclose Thanks, I will also run some tests on this branch and report back later. > Password server causes Windows VMs to switch to blank passwords after each > reboot > - > > Key: CLOUDSTACK-9058 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9058 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: ISO, Virtual Router >Affects Versions: 4.5.2 >Reporter: dsclose >Priority: Critical > > Previous versions of the systemvm.iso used a shell script to serve passwords. > In response to a "send_my_password" query, if no password was to be served, > the /opt/cloud/bin/serve_password.sh script would issue a response with > "saved_password" in the body. > The new version of the systemvm.iso supercedes serve_password.sh with a > python script at /opt/cloud/bin/passwd_server_ip.py. This script's behaviour > is different to the original serve_password.sh. In response to a > "send_my_password" query, if no password was to be served, the > /opt/cloud/bin/passwd_server_ip.py script issues an empty response. > Linux guests handle this appropriately. The cloud-set-guest-password init > script uses a case statement to ignore blank responses. I've not been able to > examine the code for the equivalent Windows guest service but it responds > very differently. > If a Windows guest receives a blank response from the password server then it > assumes that the password needs to be blank. The log on the windows guest > reports the following: > [INFO] Need to set new password for this VM. First letter in password : > [INFO] New password has been set for this VM > The windows guest expects a "saved_password" response if a password isn't > being issued. If it receives this response then it logs the following: > [INFO] No need to set password, because http://10.1.1.1:8080/ said so with > response saved_password > Because the password server is queried every time the windows service starts, > this will result in the guest adopting a blank password every time it is > rebooted or the service is restarted. It's probably unrealistic to consider > updating the Windows service in every guest currently running in cloudstack. > As such it looks like the password server's behaviour needs to be adjusted to > match the behaviour that guests expect. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9057) upgrade to 4.6 requires 4.5 templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002174#comment-15002174 ] ASF GitHub Bot commented on CLOUDSTACK-9057: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/1061#issuecomment-156122612 Since this code is only needed if you upgrade to `4.5` not when you hit this code if you upgrade from say `4.4` and jump forward to `4.6`. This code is still needed in the `4.5` branch but not here. We should run an upgrade test to verify. > upgrade to 4.6 requires 4.5 templates > - > > Key: CLOUDSTACK-9057 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9057 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.2 >Reporter: Daan Hoogland >Assignee: Daan Hoogland >Priority: Minor > > the upgrade coe requiring 4.5 system templates can be removed. > There is a ticket somewhere to make the upgrade code more generic. for this > the maps in the method(s) have to be moved to a central location. The update > call can be an API using those maps. this for prosperity, now remove! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9059) Snapshot on S3 fails when delta is zero
Remi Bergsma created CLOUDSTACK-9059:
Summary: Snapshot on S3 fails when delta is zero
Key: CLOUDSTACK-9059
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9059
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Snapshot
Affects Versions: 4.6.0
Environment: XenServer and S3
Reporter: Remi Bergsma
Priority: Critical
- Create a vm
- make snapshot
Verify it works and makes it to S3. This should work.
- make another snapshot
It fails: Failed to create snapshot due to an internal error creating snapshot
for volume 220
Logs from management:
2015-11-12 16:26:15,103 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Add job-1669 into job monitoring
2015-11-12 16:26:15,107 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Executing AsyncJobVO {id:1669,
userId: 4, accountId: 2, instanceType: Snapshot, instanceId: 12, cmd: org.apa
che.cloudstack.api.command.user.snapshot.CreateSnapshotCmd, cmdInfo:
{"quiescevm":"false","httpmethod":"GET","ctxAccountId":"2","uuid":"2a2b67ce-e6a5-4dd3-85f5-823f14d9fbbe","cmdEventType":"SNAPSHOT.CREATE","respons
e":"json","ctxUserId":"4","volumeId":"0137c81d-aedb-469a-bcbb-cf7df2985c82","name":"nog
een","ctxStartEventId":"2906","id":"12","ctxDetails":"{\"interface
com.cloud.storage.Snapshot\":\"2a2b67ce-e6a5-4dd3-85f5-823f1
4d9fbbe\",\"interface
com.cloud.storage.Volume\":\"0137c81d-aedb-469a-bcbb-cf7df2985c82\"}","_":"1447341974884"},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 28867301
26, completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2015-11-12 16:26:15,109 DEBUG [c.c.a.ApiServlet]
(http-bio-8080-exec-26:ctx-f0fd7270 ctx-2f203261) ===END=== 10.200.22.3 -- GET
command=createSnapshot&response=json&volumeId=0137c81d-aedb-469a-bcbb-cf7df2985c82&qu
iescevm=false&name=nog+een&_=1447341974884
2015-11-12 16:26:15,181 INFO [o.a.c.a.c.u.s.CreateSnapshotCmd]
(API-Job-Executor-3:ctx-a1e712e2 job-1669 ctx-2f94ce7b) VOLSS:
createSnapshotCmd starts:1447341975181
2015-11-12 16:26:15,231 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-3:ctx-a1e712e2 job-1669 ctx-2f94ce7b) Sync job-1670 execution
on object VmWorkJobQueue.220
2015-11-12 16:26:18,143 DEBUG [c.c.a.ApiServlet]
(http-bio-8080-exec-17:ctx-0304676c) ===START=== 10.200.22.3 -- GET
command=queryAsyncJobResult&jobId=5a6748af-cb5f-41b6-82c6-a17971c63d09&response=json&_=144734197
8124
2015-11-12 16:26:18,178 DEBUG [c.c.a.ApiServlet]
(http-bio-8080-exec-17:ctx-0304676c ctx-321af332) ===END=== 10.200.22.3 -- GET
command=queryAsyncJobResult&jobId=5a6748af-cb5f-41b6-82c6-a17971c63d09&response=json&
_=1447341978124
2015-11-12 16:26:19,497 DEBUG [c.c.s.StatsCollector]
(StatsCollector-4:ctx-4fd0fb68) AutoScaling Monitor is running...
2015-11-12 16:26:21,180 DEBUG [c.c.a.ApiServlet]
(http-bio-8080-exec-14:ctx-7690a426) ===START=== 10.200.22.3 -- GET
command=queryAsyncJobResult&jobId=5a6748af-cb5f-41b6-82c6-a17971c63d09&response=json&_=144734198
1124
2015-11-12 16:26:21,216 DEBUG [c.c.a.ApiServlet]
(http-bio-8080-exec-14:ctx-7690a426 ctx-61c72bab) ===END=== 10.200.22.3 -- GET
command=queryAsyncJobResult&jobId=5a6748af-cb5f-41b6-82c6-a17971c63d09&response=json&
_=1447341981124
2015-11-12 16:26:21,316 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Complete async job-1669, jobStatus:
FAILED, resultCode: 530, result: org.apache.cloudstack.api.response.Exce
ptionResponse/null/{"uuidList":[],"errorcode":530,"errortext":"Failed to create
snapshot due to an internal error creating snapshot for volume 220"}
2015-11-12 16:26:21,318 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Publish async job-1669 complete on
message bus
2015-11-12 16:26:21,318 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Wake up jobs related to job-1669
2015-11-12 16:26:21,318 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Update db status for job-1669
2015-11-12 16:26:21,321 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Wake up jobs joined with job-1669
and disjoin all subjobs created from job- 1669
2015-11-12 16:26:21,326 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Done executing
org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd for job-1669
2015-11-12 16:26:21,326 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Remove job-1669 from job monitoring
2015-11-12 16:26:18,280 ERROR [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-3:ctx-fbda09ad job-1669/job-1670) Unable to complete
AsyncJobVO {id:1
[jira] [Created] (CLOUDSTACK-9060) Create volume / template from S3 snapshot fails
Remi Bergsma created CLOUDSTACK-9060: Summary: Create volume / template from S3 snapshot fails Key: CLOUDSTACK-9060 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9060 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Snapshot Affects Versions: 4.6.0 Environment: KVM / XenServer and S3 compatible sec storage Reporter: Remi Bergsma Priority: Critical Create a vm Create a snapshot This works fine. Now create a template from this snapshot: Error: Failed to create templatejava.lang.NullPointerException java.lang.NullPointerException at org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.createTemplateFromSnapshot(AncientDataMotionStrategy.java:490) at org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:441) at org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:68) at org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:73) at org.apache.cloudstack.storage.image.TemplateServiceImpl.copyAsync(TemplateServiceImpl.java:657) at org.apache.cloudstack.storage.image.TemplateServiceImpl.createTemplateFromSnapshotAsync(TemplateServiceImpl.java:663) at com.cloud.template.TemplateManagerImpl.createPrivateTemplate(TemplateManagerImpl.java:1484) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy187.createPrivateTemplate(Unknown Source) at org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin.execute(CreateTemplateCmdByAdmin.java:43) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150) at com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:537) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:494) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) 2015-11-12 15:16:45,413 DEBUG [c.c.t.TemplateManagerImpl] (API-Job-Executor-2:ctx-e0bc8a04 job-1665 ctx-ce0e40f4) Failed to create templatejava.lang.NullPointerException 2015-11-12 15:16:45,449 ERROR [c.c.a.ApiAsyncJobDispatcher] (API-Job-Executor-2:ctx-e0bc8a04 job-1665) Unexpected exception while executing org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAd
[jira] [Commented] (CLOUDSTACK-9004) Add functionality to LibvirtVMDef.HyperVEnlightenmentFeatureDef
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002280#comment-15002280 ] ASF GitHub Bot commented on CLOUDSTACK-9004: Github user DaanHoogland commented on the pull request: https://github.com/apache/cloudstack/pull/1013#issuecomment-156145580 yes, 4.6 is only for bugfixes, any features go into later versions. > Add functionality to LibvirtVMDef.HyperVEnlightenmentFeatureDef > --- > > Key: CLOUDSTACK-9004 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9004 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.2 >Reporter: Josh Harshman >Assignee: Josh Harshman >Priority: Minor > Labels: easyfix, patch, perfomance, windows > > LibvirtVMDef.HyperVEnlightenmentFeatureDef only supports the setting of the > relaxed mode feature. This change will expand the subclass to be able to set > vapic and spinlock boolean values, as well as spinlock retry value. > These values will then be written out to the XML appropriately. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9060) Create volume / template from S3 snapshot fails
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002279#comment-15002279 ] Remi Bergsma commented on CLOUDSTACK-9060: -- Ping [~pdion] is this the same issue as you reported on Swift? [~borisroman] is currently debugging it. > Create volume / template from S3 snapshot fails > --- > > Key: CLOUDSTACK-9060 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9060 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot >Affects Versions: 4.6.0 > Environment: KVM / XenServer and S3 compatible sec storage >Reporter: Remi Bergsma >Priority: Critical > > Create a vm > Create a snapshot > This works fine. Now create a template from this snapshot: > Error: Failed to create templatejava.lang.NullPointerException > java.lang.NullPointerException > at > org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.createTemplateFromSnapshot(AncientDataMotionStrategy.java:490) > at > org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:441) > at > org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:68) > at > org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:73) > at > org.apache.cloudstack.storage.image.TemplateServiceImpl.copyAsync(TemplateServiceImpl.java:657) > at > org.apache.cloudstack.storage.image.TemplateServiceImpl.createTemplateFromSnapshotAsync(TemplateServiceImpl.java:663) > at > com.cloud.template.TemplateManagerImpl.createPrivateTemplate(TemplateManagerImpl.java:1484) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy187.createPrivateTemplate(Unknown Source) > at > org.apache.cloudstack.api.command.admin.template.CreateTemplateCmdByAdmin.execute(CreateTemplateCmdByAdmin.java:43) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:150) > at > com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:537) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) > at > org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) > at > org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:494) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolEx
[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002387#comment-15002387 ] ASF GitHub Bot commented on CLOUDSTACK-8715: Github user wido commented on the pull request: https://github.com/apache/cloudstack/pull/1027#issuecomment-156161390 @ustcweizhou Could you close this PR? #985 has some new patches which use libvirt. Some of your code also went in there :) > Add support for qemu-guest-agent to libvirt provider > > > Key: CLOUDSTACK-8715 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Sten Spans >Assignee: Wido den Hollander > Labels: kvm, libvirt, qemu, systemvm > Fix For: Future > > > The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite > a lot of useful functionality, which can only be provided by having an agent > on the VM. This includes things like freezing/thawing filesystems (for > backups), reading files on the guest, listing interfaces / ip addresses, etc. > This feature has been requested by users, but is currently not implemented. > http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent > The first change needed is to add the following to the XML generated for KVM > virtual machines,: > > > > > This provides the communication channel between libvirt and the agent on the > host. All in all a pretty simple change to LibvirtComputingResource.java / > LibvirtVMDef.java > Secondly the qemu-guest-agent package needs to be added to the systemvm > template. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9015) Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wilder Rodrigues updated CLOUDSTACK-9015: - Summary: Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER (was: Redundant VPC Virtual Router's state is BACKUP & BACKUP) > Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER > -- > > 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] [Updated] (CLOUDSTACK-9059) Snapshot on S3 fails when delta is zero
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remi Bergsma updated CLOUDSTACK-9059:
-
Description:
- Create a vm
- make snapshot
Verify it works and makes it to S3. This should work.
- make another snapshot
It fails: Failed to create snapshot due to an internal error creating snapshot
for volume 220
Logs from management:
2015-11-12 16:26:15,103 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Add job-1669 into job monitoring
2015-11-12 16:26:15,107 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Executing AsyncJobVO {id:1669,
userId: 4, accountId: 2, instanceType: Snapshot, instanceId: 12, cmd: org.apa
che.cloudstack.api.command.user.snapshot.CreateSnapshotCmd, cmdInfo:
{"quiescevm":"false","httpmethod":"GET","ctxAccountId":"2","uuid":"2a2b67ce-e6a5-4dd3-85f5-823f14d9fbbe","cmdEventType":"SNAPSHOT.CREATE","respons
e":"json","ctxUserId":"4","volumeId":"0137c81d-aedb-469a-bcbb-cf7df2985c82","name":"nog
een","ctxStartEventId":"2906","id":"12","ctxDetails":"{\"interface
com.cloud.storage.Snapshot\":\"2a2b67ce-e6a5-4dd3-85f5-823f1
4d9fbbe\",\"interface
com.cloud.storage.Volume\":\"0137c81d-aedb-469a-bcbb-cf7df2985c82\"}","_":"1447341974884"},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 28867301
26, completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
2015-11-12 16:26:15,109 DEBUG [c.c.a.ApiServlet]
(http-bio-8080-exec-26:ctx-f0fd7270 ctx-2f203261) ===END=== 10.200.22.3 -- GET
command=createSnapshot&response=json&volumeId=0137c81d-aedb-469a-bcbb-cf7df2985c82&qu
iescevm=false&name=nog+een&_=1447341974884
2015-11-12 16:26:15,181 INFO [o.a.c.a.c.u.s.CreateSnapshotCmd]
(API-Job-Executor-3:ctx-a1e712e2 job-1669 ctx-2f94ce7b) VOLSS:
createSnapshotCmd starts:1447341975181
2015-11-12 16:26:15,231 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-3:ctx-a1e712e2 job-1669 ctx-2f94ce7b) Sync job-1670 execution
on object VmWorkJobQueue.220
2015-11-12 16:26:18,143 DEBUG [c.c.a.ApiServlet]
(http-bio-8080-exec-17:ctx-0304676c) ===START=== 10.200.22.3 -- GET
command=queryAsyncJobResult&jobId=5a6748af-cb5f-41b6-82c6-a17971c63d09&response=json&_=144734197
8124
2015-11-12 16:26:18,178 DEBUG [c.c.a.ApiServlet]
(http-bio-8080-exec-17:ctx-0304676c ctx-321af332) ===END=== 10.200.22.3 -- GET
command=queryAsyncJobResult&jobId=5a6748af-cb5f-41b6-82c6-a17971c63d09&response=json&
_=1447341978124
2015-11-12 16:26:19,497 DEBUG [c.c.s.StatsCollector]
(StatsCollector-4:ctx-4fd0fb68) AutoScaling Monitor is running...
2015-11-12 16:26:21,180 DEBUG [c.c.a.ApiServlet]
(http-bio-8080-exec-14:ctx-7690a426) ===START=== 10.200.22.3 -- GET
command=queryAsyncJobResult&jobId=5a6748af-cb5f-41b6-82c6-a17971c63d09&response=json&_=144734198
1124
2015-11-12 16:26:21,216 DEBUG [c.c.a.ApiServlet]
(http-bio-8080-exec-14:ctx-7690a426 ctx-61c72bab) ===END=== 10.200.22.3 -- GET
command=queryAsyncJobResult&jobId=5a6748af-cb5f-41b6-82c6-a17971c63d09&response=json&
_=1447341981124
2015-11-12 16:26:21,316 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Complete async job-1669, jobStatus:
FAILED, resultCode: 530, result: org.apache.cloudstack.api.response.Exce
ptionResponse/null/{"uuidList":[],"errorcode":530,"errortext":"Failed to create
snapshot due to an internal error creating snapshot for volume 220"}
2015-11-12 16:26:21,318 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Publish async job-1669 complete on
message bus
2015-11-12 16:26:21,318 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Wake up jobs related to job-1669
2015-11-12 16:26:21,318 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Update db status for job-1669
2015-11-12 16:26:21,321 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Wake up jobs joined with job-1669
and disjoin all subjobs created from job- 1669
2015-11-12 16:26:21,326 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Done executing
org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd for job-1669
2015-11-12 16:26:21,326 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-3:ctx-a1e712e2 job-1669) Remove job-1669 from job monitoring
2015-11-12 16:26:18,280 ERROR [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-3:ctx-fbda09ad job-1669/job-1670) Unable to complete
AsyncJobVO {id:1670, userId: 4, accountId: 2, instanceType: null, instanceId:
null, c
md: com.cloud.vm.VmWorkTakeVolumeSnapshot, cmdInfo:
rO0ABXNyACVjb20uY2xvdWQudm0uVm1Xb3JrVGFrZVZvbHVtZVNuYXBzaG90BL5gG4Li1c8CAARaAAlxdWllc2NlVm1MAAhwb2xpY3lJZHQAEExqYXZhL2xhbmcvTG9uZztMAApzbmFwc2hvdElkcQB-AAFMAAh2b2x
1bWVJZHEAfgABeHIAE2NvbS5jbG91ZC52bS5WbVdvcmufmb
[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002750#comment-15002750 ] ASF GitHub Bot commented on CLOUDSTACK-8715: Github user ustcweizhou closed the pull request at: https://github.com/apache/cloudstack/pull/1027 > Add support for qemu-guest-agent to libvirt provider > > > Key: CLOUDSTACK-8715 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Sten Spans >Assignee: Wido den Hollander > Labels: kvm, libvirt, qemu, systemvm > Fix For: Future > > > The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite > a lot of useful functionality, which can only be provided by having an agent > on the VM. This includes things like freezing/thawing filesystems (for > backups), reading files on the guest, listing interfaces / ip addresses, etc. > This feature has been requested by users, but is currently not implemented. > http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent > The first change needed is to add the following to the XML generated for KVM > virtual machines,: > > > > > This provides the communication channel between libvirt and the agent on the > host. All in all a pretty simple change to LibvirtComputingResource.java / > LibvirtVMDef.java > Secondly the qemu-guest-agent package needs to be added to the systemvm > template. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002749#comment-15002749 ] ASF GitHub Bot commented on CLOUDSTACK-8715: Github user ustcweizhou commented on the pull request: https://github.com/apache/cloudstack/pull/1027#issuecomment-156212332 @wido sure , closed. > Add support for qemu-guest-agent to libvirt provider > > > Key: CLOUDSTACK-8715 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Sten Spans >Assignee: Wido den Hollander > Labels: kvm, libvirt, qemu, systemvm > Fix For: Future > > > The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite > a lot of useful functionality, which can only be provided by having an agent > on the VM. This includes things like freezing/thawing filesystems (for > backups), reading files on the guest, listing interfaces / ip addresses, etc. > This feature has been requested by users, but is currently not implemented. > http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent > The first change needed is to add the following to the XML generated for KVM > virtual machines,: > > > > > This provides the communication channel between libvirt and the agent on the > host. All in all a pretty simple change to LibvirtComputingResource.java / > LibvirtVMDef.java > Secondly the qemu-guest-agent package needs to be added to the systemvm > template. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8715) Add support for qemu-guest-agent to libvirt provider
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002753#comment-15002753 ] ASF GitHub Bot commented on CLOUDSTACK-8715: Github user ustcweizhou commented on the pull request: https://github.com/apache/cloudstack/pull/985#issuecomment-156212769 @wido nice, I will test it. does this need the change on libvirt-java ? > Add support for qemu-guest-agent to libvirt provider > > > Key: CLOUDSTACK-8715 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8715 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Sten Spans >Assignee: Wido den Hollander > Labels: kvm, libvirt, qemu, systemvm > Fix For: Future > > > The qemu guest agent is a newer part of qemu/kvm/libvirt which exposes quite > a lot of useful functionality, which can only be provided by having an agent > on the VM. This includes things like freezing/thawing filesystems (for > backups), reading files on the guest, listing interfaces / ip addresses, etc. > This feature has been requested by users, but is currently not implemented. > http://users.cloudstack.apache.narkive.com/3TTmy3zj/enabling-qemu-guest-agent > The first change needed is to add the following to the XML generated for KVM > virtual machines,: > > > > > This provides the communication channel between libvirt and the agent on the > host. All in all a pretty simple change to LibvirtComputingResource.java / > LibvirtVMDef.java > Secondly the qemu-guest-agent package needs to be added to the systemvm > template. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9061) cannot deploy Instance when using Swift as Secondary Storage
Pierre-Luc Dion created CLOUDSTACK-9061: --- Summary: cannot deploy Instance when using Swift as Secondary Storage Key: CLOUDSTACK-9061 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9061 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Secondary Storage Affects Versions: 4.5.2, 4.6.0 Reporter: Pierre-Luc Dion When using Swift as Secondary Storage, new Instance cannot be created. Uploading new template work and end up correctly into swift. but creating VM's from this new template fail. Seams that the SSVM fail do create the cache template into the Primary storage. Observer on XenServer 6.2 with CloudStack 4.5.2 and 4.6.0rc1 This feature work well in 4.4.x. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9015) Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002989#comment-15002989 ] ASF GitHub Bot commented on CLOUDSTACK-9015: GitHub user wilderrodrigues opened a pull request: https://github.com/apache/cloudstack/pull/1064 CLOUDSTACK-9015 - Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER This PR fixes the problems we were facing with the Redundant VPC Routers. The following changes have been applied: * Add test to cover the rVPC routers stop/start/reboot scenario - Stop/reboot master router should make the backup router become master - Start the stopped router should make it become the backup router * Make sure the Backup router can talk to the Master router after a stop/start/reboot - Stop KeepaliveD/ConntrackD if the eth2 (guest) interface is not configured and UP - Only setup the redundancy after all the router configuration is done - Open the FW for the VRRP communitation - 224.0.0.18 and 225.0.0.50 - Set keepalived.conf.templ by default to use interface eth2 (guest) - It will be reconfigured anyway, but having eth2 there is more clear You can merge this pull request into a Git repository by running: $ git pull https://github.com/ekholabs/cloudstack fix/rVPC-CLOUDSTACK-9015 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/1064.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1064 commit cd05a252fb6c76ceff88f3dc83d3699be18556a7 Author: Wilder Rodrigues Date: 2015-11-12T17:13:51Z CLOUDSTACK-9015 - Make sure the Backup router can talk to the Master router after a stop/start/reboot - Stop KeepaliveD/ConntrackD if the eth2 (guest) interface is not configured and UP - Only setup the redundancy after all the router configuration is done - Open the FW for the VRRP communitation - 224.0.0.18 and 225.0.0.50 - Set keepalived.conf.templ by default to use interface eth2 (guest) - It will be reconfigured anyway, but having eth2 there is more clear commit 952d9a84d23b3070b1073ed8ea53275de1c556e1 Author: Wilder Rodrigues Date: 2015-11-12T17:32:53Z CLOUDSTACK-9015 - Add test to cover the rVPC routers stop/start/reboot scenario - Stop/reboot master router should make the backup router become master - Start the stopped router should make be the backup router > Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER > -- > > 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[2
[jira] [Commented] (CLOUDSTACK-9015) Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002990#comment-15002990 ] ASF GitHub Bot commented on CLOUDSTACK-9015: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/1064#issuecomment-156245517 Ping @remibergsma @borisroman @karuturi @bhaisaab The tests passed as expected: ``` Create a redundant VPC with two networks with two VMs in each network ... === TestName: test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Status : SUCCESS === ok Create a redundant VPC with two networks with two VMs in each network and check default routes ... === TestName: test_02_redundant_VPC_default_routes | Status : SUCCESS === ok Create a redundant VPC with two networks with two VMs in each network ... === TestName: test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Status : SUCCESS === ok -- Ran 3 tests in 4682.008s OK /tmp//MarvinLogs/test_vpc_redundant_ANVQFE/results.txt (END) ``` I will still execute all the other tests to make sure existing functionalities are working fine, although nothing expect for the rVPC code has changed. Cheers, Wilder > Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER > -- > > 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] [Commented] (CLOUDSTACK-8987) S3 XenServer plugin fails due to plugin not found
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003034#comment-15003034
]
Boris Schrijver commented on CLOUDSTACK-8987:
-
[~remibergsma] Is this fixed? I saw a closed PR
> S3 XenServer plugin fails due to plugin not found
> -
>
> Key: CLOUDSTACK-8987
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8987
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Environment: xenserver
>Reporter: Remi Bergsma
>Assignee: Remi Bergsma
>Priority: Critical
>
> The plugin is called as 's3xenserver' but is named 's3xen' instead.
> Regresion from a8212d9ef458dd7ac64b021e6fa33fcf64b3cce0
> 2015-10-22 21:42:30,372 WARN [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-261:ctx-862ebceb) callHostPlugin failed for cmd: s3 with args
> maxErrorRetry: 10, secretKey: +XGy4yPPbAH9AijYxFTr1yVCCiVQuSfXWWj1Invs,
> connectionTtl: null, iSCSIFlag: false, maxSingleUploadSizeInBytes:
> 5368709120, bucket: mccx-nl2, endPoint: s3.storage.acc.schubergphilis.com,
> filename: /var/run/sr-mount/9414f970-0afd-42db-972f-aa4743293430/2
> cf0c24b-a596-4039-b50a-7ce87da4f273.vhd, accessKey: 16efbc4e870f24338141,
> socketTimeout: null, https: false, connectionTimeout: 30, operation: put,
> key: snapshots/2/10/2cf0c24b-a596-4039-b50a-7ce87da4f273
> .vhd, useTCPKeepAlive: null, due to Task failed! Task record:
> uuid: 4be8a515-1e2a-59de-6301-029fb0326651
>nameLabel: Async.host.call_plugin
> nameDescription:
>allowedOperations: []
>currentOperations: {}
> created: Thu Oct 22 21:42:44 CEST 2015
> finished: Thu Oct 22 21:42:44 CEST 2015
> status: failure
> residentOn: com.xensource.xenapi.Host@9c7aad90
> progress: 1.0
> type:
> result:
>errorInfo: [XENAPI_MISSING_PLUGIN, s3xenserver]
> otherConfig: {}
>subtaskOf: com.xensource.xenapi.Task@aaf13f6f
> subtasks: []
> Task failed! Task record: uuid:
> 4be8a515-1e2a-59de-6301-029fb0326651
>nameLabel: Async.host.call_plugin
> nameDescription:
>allowedOperations: []
>currentOperations: {}
> created: Thu Oct 22 21:42:44 CEST 2015
> finished: Thu Oct 22 21:42:44 CEST 2015
> status: failure
> residentOn: com.xensource.xenapi.Host@9c7aad90
> progress: 1.0
> type:
> result:
>errorInfo: [XENAPI_MISSING_PLUGIN, s3xenserver]
> otherConfig: {}
>subtaskOf: com.xensource.xenapi.Task@aaf13f6f
> subtasks: []
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8819) Virtual Template size is not correct when using S3 as image store.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Schrijver resolved CLOUDSTACK-8819. - Resolution: Fixed Fix Version/s: 4.6.0 > Virtual Template size is not correct when using S3 as image store. > -- > > Key: CLOUDSTACK-8819 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8819 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Secondary Storage >Reporter: Boris Schrijver >Assignee: Boris Schrijver > Fix For: 4.6.0 > > > The virtual size is the same as the physical size of the template. See: > https://github.com/apache/cloudstack/blob/master/services/secondary-storage/server/src/org/apache/cloudstack/storage/template/DownloadManagerImpl.java#L300 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9062) Upgrade AWS SDK to latest version.
Boris Schrijver created CLOUDSTACK-9062: --- Summary: Upgrade AWS SDK to latest version. Key: CLOUDSTACK-9062 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9062 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Secondary Storage Affects Versions: 4.6.0 Reporter: Boris Schrijver Assignee: Boris Schrijver Upgrade AWS SDK to latest version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9062) Upgrade AWS SDK to latest version.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boris Schrijver updated CLOUDSTACK-9062: Issue Type: Improvement (was: Bug) > Upgrade AWS SDK to latest version. > -- > > Key: CLOUDSTACK-9062 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9062 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Secondary Storage >Affects Versions: 4.6.0 >Reporter: Boris Schrijver >Assignee: Boris Schrijver > > Upgrade AWS SDK to latest version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9015) Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003061#comment-15003061 ] ASF GitHub Bot commented on CLOUDSTACK-9015: Github user borisroman commented on the pull request: https://github.com/apache/cloudstack/pull/1064#issuecomment-156253559 @wilderrodrigues Thanks for fixing! Will run tomorrow or this weekend. > Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER > -- > > 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] [Commented] (CLOUDSTACK-9015) Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003605#comment-15003605 ] ASF GitHub Bot commented on CLOUDSTACK-9015: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/1064#issuecomment-156336955 Ping @remibergsma @karuturi @giraffeforestg @borisroman @bhaisaab @miguelaferreira @DaanHoogland More test results: * Management Server + MySQL on CentOS 7.1 * Ona KVm Host on CentOS 7.1 * Agent + Common RPMs built from source * nosetests --with-marvin --marvin-config=/data/shared/marvin/mct-zone1-kvm1-ISOLATED.cfg -s -a tags=advanced,required_hardware=true component/test_routers_iptables_default_policy.py component/test_routers_network_ops.py component/test_vpc_router_nics.py component/test_password_server.py component/test_router_dhcphosts.py smoke/test_loadbalance.py smoke/test_internal_lb.py smoke/test_ssvm.py smoke/test_vpc_vpn.py smoke/test_network.py ``` Test iptables default INPUT/FORWARD policy on RouterVM ... === TestName: test_02_routervm_iptables_policies | Status : SUCCESS === ok Test iptables default INPUT/FORWARD policies on VPC router ... === TestName: test_01_single_VPC_iptables_policies | Status : SUCCESS === ok Test redundant router internals ... === TestName: test_01_isolate_network_FW_PF_default_routes_egress_true | Status : SUCCESS === ok Test redundant router internals ... === TestName: test_02_isolate_network_FW_PF_default_routes_egress_false | Status : SUCCESS === ok Test redundant router internals ... === TestName: test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true | Status : SUCCESS === ok Test redundant router internals ... === TestName: test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false | Status : SUCCESS === ok Create a VPC with two networks with one VM in each network and test nics after destroy ... === TestName: test_01_VPC_nics_after_destroy | Status : SUCCESS === ok Create a VPC with two networks with one VM in each network and test default routes ... === TestName: test_02_VPC_default_routes | Status : SUCCESS === ok Check the password file in the Router VM ... === TestName: test_isolate_network_password_server | Status : SUCCESS === ok Check that the /etc/dhcphosts.txt doesn't contain duplicate IPs ... === TestName: test_router_dhcphosts | Status : SUCCESS === ok Test to create Load balancing rule with source NAT ... === TestName: test_01_create_lb_rule_src_nat | Status : SUCCESS === ok Test to create Load balancing rule with non source NAT ... === TestName: test_02_create_lb_rule_non_nat | Status : SUCCESS === ok Test for assign & removing load balancing rule ... === TestName: test_assign_and_removal_lb | Status : SUCCESS === ok Test to verify access to loadbalancer haproxy admin stats page ... === TestName: test02_internallb_haproxy_stats_on_all_interfaces | Status : SUCCESS === ok Test create, assign, remove of an Internal LB with roundrobin http traffic to 3 vm's ... === TestName: test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80 | Status : SUCCESS === ok Test SSVM Internals ... === TestName: test_03_ssvm_internals | Status : SUCCESS === ok Test CPVM Internals ... === TestName: test_04_cpvm_internals | Status : SUCCESS === ok Test stop SSVM ... === TestName: test_05_stop_ssvm | Status : SUCCESS === ok Test stop CPVM ... === TestName: test_06_stop_cpvm | Status : SUCCESS === ok Test reboot SSVM ... === TestName: test_07_reboot_ssvm | Status : SUCCESS === ok Test reboot CPVM ... === TestName: test_08_reboot_cpvm | Status : SUCCESS === ok Test destroy SSVM ... === TestName: test_09_destroy_ssvm | Status : SUCCESS === ok Test destroy CPVM ... === TestName: test_10_destroy_cpvm | Status : SUCCESS === ok Test Remote Access VPN in VPC ... === TestName: test_vpc_remote_access_vpn | Status : SUCCESS === ok Test VPN in VPC ... === TestName: test_vpc_site2site_vpn | Status : SUCCESS === ok Test for port forwarding on source NAT ... === TestName: test_01_port_fwd_on_src_nat | Status : SUCCESS === ok Test for port forwarding on non source NAT ... === TestName: test_02_port_fwd_on_non_src_nat | Status : SUCCESS === ok Test for reboot router ... === TestName: test_reboot_router | Status : SUCCESS === ok Test for Router rules for network rules on acquired public IP ... === TestName: test_network_rules_acquired_public_ip_1_static_nat_rule | Status : SUCCESS === ok Test for Router rules for network rules on acquired public IP ... === TestName: test_network_rules_acquired_public_ip_2_nat_rule | Status : SUCCESS === ok Test for Router rules for
[jira] [Commented] (CLOUDSTACK-9015) Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003606#comment-15003606 ] ASF GitHub Bot commented on CLOUDSTACK-9015: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/1064#issuecomment-156337467 Jenkins failed due to artifact transfer error: ``` [ERROR] Failed to execute goal org.apache.maven.plugins:maven-remote-resources-plugin:1.3:process (default) on project cloud-client-ui: Error resolving project artifact: Could not transfer artifact net.juniper.contrail:juniper-contrail-api:pom:1.0-SNAPSHOT from/to Nexus (http://repository.apache.org/snapshots): Failed to transfer file: http://repository.apache.org/snapshots/net/juniper/contrail/juniper-contrail-api/1.0-SNAPSHOT/juniper-contrail-api-1.0-SNAPSHOT.pom. Return code is: 503, ReasonPhrase: Service Unavailable. for project net.juniper.contrail:juniper-contrail-api:jar:1.0-SNAPSHOT -> [Help 1] ``` > Redundant VPC Virtual Router's state is BACKUP & BACKUP or MASTER & MASTER > -- > > 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)
