Github user wido commented on the issue:
https://github.com/apache/cloudstack/pull/1547
I spend some more time testing this. After the latest commits from
@The-Loeki it all seems to work:
* Virtual Router listens on all addresses
* Apache is configured properly
* DHCP is answered correctly by the VR
The IPs are configured properly inside the VR:
<pre>
root@r-10-VM:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UP qlen 1000
link/ether 06:ee:34:00:00:85 brd ff:ff:ff:ff:ff:ff
inet 109.XX.YY.248/26 brd 109.XX.YY.255 scope global eth0
inet 109.XX.YY.149/28 brd 109.XX.YY.159 scope global eth0
inet 31.XX.YY.133/26 brd 31.XX.YY.191 scope global eth0
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UP qlen 1000
link/ether 0e:00:a9:fe:00:5f brd ff:ff:ff:ff:ff:ff
inet 169.254.0.95/16 brd 169.254.255.255 scope global eth1
root@r-10-VM:~#
</pre>
Apache is also working properly on both the VR and the SecStore VM:
<pre>root@r-10-VM:~# ls -l /etc/apache2/sites-enabled/
total 30
-rwxr-xr-x 1 root root 10230 Jun 2 13:40 vhost-109.XX.YY.248.conf
-rwxr-xr-x 1 root root 10230 Jun 2 13:40 vhost-109.XX.YY.149.conf
-rwxr-xr-x 1 root root 10230 Jun 2 13:40 vhost-31.XX.YY.133.conf
root@r-10-VM:~# apache2ctl configtest
apache2: apr_sockaddr_info_get() failed for r-10-VM
apache2: Could not reliably determine the server's fully qualified domain
name, using 127.0.0.1 for ServerName
Syntax OK
root@r-10-VM:~# </pre>
<pre>root@s-214-VM:~# ls -l /etc/apache2/sites-enabled/
total 10
lrwxrwxrwx 1 root root 26 Nov 9 2015 000-default ->
../sites-available/default
-rw-r--r-- 1 root root 10206 Jun 2 13:35 vhost-109.XX.YY.206.conf
root@s-214-VM:~# apache2ctl configtest
apache2: Could not reliably determine the server's fully qualified domain
name, using 109.XX.YY.206 for ServerName
Syntax OK
root@s-214-VM:~#</pre>
Instances are also able to gather their metadata with cloud-init:
```
1.2.3.4 - - [02/Jun/2016:13:45:15 +0000] "GET
//latest/meta-data/instance-id HTTP/1.1" 200 240 "-" "Cloud-Init/0.7.5"
1.2.3.4 - - [02/Jun/2016:13:45:15 +0000] "GET /latest/user-data HTTP/1.1"
200 202 "-" "Cloud-Init/0.7.5"
1.2.3.4 - - [02/Jun/2016:13:45:15 +0000] "GET /latest/meta-data/ HTTP/1.1"
200 341 "-" "Cloud-Init/0.7.5"
1.2.3.4 - - [02/Jun/2016:13:45:15 +0000] "GET /latest/meta-data/local-ipv4
HTTP/1.1" 200 216 "-" "Cloud-Init/0.7.5"
1.2.3.4 - - [02/Jun/2016:13:45:15 +0000] "GET
/latest/meta-data/local-hostname HTTP/1.1" 200 221 "-" "Cloud-Init/0.7.5"
1.2.3.4 - - [02/Jun/2016:13:45:15 +0000] "GET
/latest/meta-data/public-hostname HTTP/1.1" 200 221 "-" "Cloud-Init/0.7.5"
1.2.3.4 - - [02/Jun/2016:13:45:15 +0000] "GET /latest/meta-data/public-keys
HTTP/1.1" 200 202 "-" "Cloud-Init/0.7.5"
1.2.3.4 - - [02/Jun/2016:13:45:15 +0000] "GET
/latest/meta-data/cloud-identifier HTTP/1.1" 200 253 "-" "Cloud-Init/0.7.5"
1.2.3.4 - - [02/Jun/2016:13:45:15 +0000] "GET
/latest/meta-data/service-offering HTTP/1.1" 200 225 "-" "Cloud-Init/0.7.5"
1.2.3.4 - - [02/Jun/2016:13:45:15 +0000] "GET /latest/meta-data/public-ipv4
HTTP/1.1" 200 216 "-" "Cloud-Init/0.7.5"
1.2.3.4 - - [02/Jun/2016:13:45:15 +0000] "GET /latest/meta-data/vm-id
HTTP/1.1" 200 240 "-" "Cloud-Init/0.7.5"
1.2.3.4 - - [02/Jun/2016:13:45:15 +0000] "GET
/latest/meta-data/availability-zone HTTP/1.1" 200 215 "-" "Cloud-Init/0.7.5"
1.2.3.4 - - [02/Jun/2016:13:45:15 +0000] "GET /latest/meta-data/instance-id
HTTP/1.1" 200 240 "-" "Cloud-Init/0.7.5"
```
The Instance also reports this:
<pre>Cloud-init v. 0.7.5 finished at Thu, 02 Jun 2016 13:46:08 +0000.
Datasource DataSourceCloudStack. Up 62.06 seconds</pre>
As far as I can test it is all working. The commits in the PR need to be
squashed, but to me it looks good.
I consider this PR a **BLOCKER** for 4.9 though.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
