to be clear, in my 4.16 testing, 'data-server' and 'data-server.' can be
both resolved as VIP, in VR and centos5 VMs. but "data-server." cannot be
resolved in ubuntu 18 VM.
If 'data-server.' cannot be resolved in your vm (ubuntu or other OS
distributions), it is not an issue with cloudstack or cloud-init. it is
caused by os-level changes (eg systemd-resolved).

-Wei



On Thu, 4 Nov 2021 at 10:28, Wei ZHOU <ustcweiz...@gmail.com> wrote:

> Hi Edward,
>
> Sorry I am a bit confused.
>
> Is cloud-init not working in your vm, because 'data-server.' is not
> resolved ? But why did you check the issue in the VR not the VM ?
> Can 'data-server' (without dot) be resolved in the vm ?
>
> I confirm that the password server listens only on the VIP,  it should not
> be a problem.
> in my testing with 4.16.0.0-rc2, 'data-server' and 'data-server.' can be
> both resolved as VIP.
>
> -Wei
>
> On Thu, 4 Nov 2021 at 09:54, Edward St Pierre <edward.stpie...@gmail.com>
> wrote:
>
>> 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 <ustcweiz...@gmail.com> 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 <
>> edward.stpie...@gmail.com
>> > >
>> > 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 <ustcweiz...@gmail.com> 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 <
>> > edward.stpie...@gmail.com
>> > > >
>> > > > 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
>> > > > >
>> > > >
>> > >
>> >
>>
>

Reply via email to