Hi,
The diagnostics I provided shows that it only appears to be listening on
the VIP and not the guest IP..
The DNS does resolve (DNS resolution provided earlier), however I believe
it should resolve to the VIP address as the password server is only
listening on the VIP.
I am using the template 'systemvm-kvm-4.15.1'
The bug you have highlighted is about ubuntu.
This is the password server command line:
python /opt/cloud/bin/passwd_server_ip.py 10.1.1.1,10.1.1.154
And, you can see it only takes the first IP address to listen on:
if len(sys.argv) > 1:
addresses = sys.argv[1].split(",")
if len(addresses) > 0:
listeningAddress = addresses[0]
allowAddresses.append(addresses[0])
if len(addresses) > 1:
allowAddresses.append(addresses[1])
server_address = (listeningAddress, 8080)
passwordServer = ServerClass(server_address, HandlerClass)
I do not think that listening on the VIP is the problem, I believe
that 'data-server.' should resolve to the VIP address and not the guest IP
address.
Ed
On Wed, 3 Nov 2021 at 22:24, Wei ZHOU <[email protected]> wrote:
> It is not a problem, in my opinion. The password server and userdata server
> listen on both guest ip and vip.
>
> As I commented on the link in previous reply, if cloud-init does not work
> in your vm template, it might be caused by systemd-resolved.
>
> -Wei
>
>
> On Wednesday, 3 November 2021, Edward St Pierre <[email protected]
> >
> wrote:
>
> > Hi,
> >
> > Thanks for your input, it actually looks like a bug with the redundant VR
> > setup.
> >
> > See diagnostics directly on master VR:
> >
> > root@r-418-VM:~# netstat -anpl | grep 8080
> > tcp 0 0 10.1.1.1:8080 0.0.0.0:*
> LISTEN
> > 1610/python
> >
> > root@r-418-VM:~# ip addr show
> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
> > default qlen 1000
> > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> > inet 127.0.0.1/8 scope host lo
> > valid_lft forever preferred_lft forever
> > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state
> > UP group default qlen 1000
> > link/ether 02:00:76:04:00:02 brd ff:ff:ff:ff:ff:ff
> > inet 10.1.1.154/24 brd 10.1.1.255 scope global eth0
> > valid_lft forever preferred_lft forever
> > inet 10.1.1.1/24 brd 10.1.1.255 scope global secondary eth0
> > valid_lft forever preferred_lft forever
> >
> > root@r-418-VM:~# dig data-server. @localhost
> >
> > ; <<>> DiG 9.11.5-P4-5.1+deb10u3-Debian <<>> data-server. @localhost
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32161
> > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ;; QUESTION SECTION:
> > ;data-server. IN A
> >
> > ;; ANSWER SECTION:
> > data-server. 0 IN A 10.1.1.154
> >
> > ;; Query time: 1 msec
> > ;; SERVER: 127.0.0.1#53(127.0.0.1)
> > ;; WHEN: Wed Nov 03 11:58:43 UTC 2021
> > ;; MSG SIZE rcvd: 56
> >
> >
> > Ed
> >
> > On Wed, 3 Nov 2021 at 20:15, Wei ZHOU <[email protected]> wrote:
> >
> > > Hi Edward,
> > >
> > > You may face an issue which has recently been fixed in cloud-init .
> > > Please refer to https://github.com/canonical/cloud-init/pull/1004
> > >
> > > -Wei
> > >
> > > On Wed, 3 Nov 2021 at 12:48, Edward St Pierre <
> [email protected]
> > >
> > > wrote:
> > >
> > > > Hi Guys,
> > > >
> > > > Just a really quick question.
> > > >
> > > > Should 'data-server.' resolve to the virtual router or the guest?
> > > >
> > > > Basically the cloud-init datasource for Cloudstack that comes with
> > CentOS
> > > > Stream seems to use this as the address for the VR.
> > > >
> > > > Just looking to see if this is a VR bug or a bug with this module on
> > > > CentOS.
> > > >
> > > > Regards
> > > >
> > > > Ed
> > > >
> > >
> >
>
