You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Cloud List <cl...@sg.or.id> on 2016/11/07 12:44:51 UTC
ACS - Some VMs unable to get DHCP IP from VR
Hi,
After our upgrade from CloudStack 4.2 to 4.8.1.1, we noted that some (but
not all) of our VMs are not able to get DHCP from the VR. This gives
problem when the VM is restarted and cannot get up and running because
unable to get IP.
I logged in to the VR and found below messages showing that the DHCP server
is ignoring the request from the VM.
Nov 7 12:19:43 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
ignored
Nov 7 12:19:52 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:05:64:01:13:d3
ignored
Nov 7 12:19:53 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
ignored
Nov 7 12:20:04 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
ignored
Nov 7 12:20:11 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:05:64:01:13:d3
ignored
Nov 7 12:20:22 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
ignored
Nov 7 12:20:30 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
ignored
Nov 7 12:20:42 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
ignored
Nov 7 12:21:02 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
ignored
Nov 7 12:21:19 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
ignored
Any reason why the dnsmasq service ignored the request from the VM and how
can we fix that?
At the moment, the only workaround we can do is to configure the IP address
statically to the servelet, which is not practical.
Any advice is greatly appreciated.
Thank you.
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by Chiradeep Vittal <ch...@gmail.com>.
I wonder if there are more VMs than the range allowed in the guest network.
The excess VMs may not be getting IPs.
Check
/etc/dnsmasq.d/multiple_ranges.conf
/etc/dnsmasq.conf
Check this
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2008q3/002301.html
You can also turn on logging on dnsmasq by adding log-dhcp to
/etc/dnsmasq.conf (and restarting dnsmasq)
On Mon, Nov 7, 2016 at 11:27 AM, Cloud List <cl...@sg.or.id> wrote:
> Hi Wei,
>
> In addition,
>
> The VR is serving a shared not isolated network, meaning the IP it serves
> is 'guest' not 'public' IP. Will that make a difference on the iptables
> command we need to execute?
>
> Looking forward to your reply, thank you.
>
> Cheers.
>
>
> On Tue, Nov 8, 2016 at 3:19 AM, Cloud List <cl...@sg.or.id> wrote:
>
> > Hi Wei and Ozhan,
> >
> > Thanks for your reply.
> >
> > The problem doesn't affect only Debian-based guest VMs, but also affected
> > some Windows and Ubuntu-based VMs as well. I have executed the command on
> > the VR and reset the NIC of the guest VM, but unfortunately the issue
> still
> > persists.
> >
> > iptables -t mangle -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM
> > --checksum-fill
> >
> > After issuing the above command on VR and reset the NIC on guest vm
> > (ifdown eth0, ifup eth0):
> >
> > On VR's /var/log/dnsmasq.log:
> >
> > Nov 7 19:09:22 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:b1:22:01:13:17
> > ignored
> > Nov 7 19:09:25 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:b1:22:01:13:17
> > ignored
> > Nov 7 19:09:30 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:b1:22:01:13:17
> > ignored
> > Nov 7 19:09:36 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:b1:22:01:13:17
> > ignored
> >
> > On the guest VM:
> >
> > root@vm:~# ifup eth0
> > Internet Systems Consortium DHCP Client 4.2.2
> > Copyright 2004-2011 Internet Systems Consortium.
> > All rights reserved.
> > For info, please visit https://www.isc.org/software/dhcp
> >
> > Listening on LPF/eth0/06:b1:22:01:13:17
> > Sending on LPF/eth0/06:b1:22:01:13:17
> > Sending on Socket/fallback
> > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
> > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
> > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 64DHCPDISCOVER
> on
> > eth0 to 255.255.255.255 port 67 interval 14
> > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9
> > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
> > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 13
> > No DHCOFFERS received.
> > No working leases in persistent database - sleeping.
> >
> > I also tried to execute similar hotfix as mentioned on the bug report:
> >
> > iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM
> > --checksum-fill
> >
> > The problem still persists. Any further advice on this is highly
> > appreciated.
> >
> > Looking forward to your reply, thank you.
> >
> > Cheers.
> >
> >
> > On Tue, Nov 8, 2016 at 2:41 AM, Wei ZHOU <us...@gmail.com> wrote:
> >
> >> GOOD point.
> >>
> >> @CloudList, can you try again after executing the following command in
> VR
> >> ?
> >>
> >> iptables -t mangle -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM
> >> --checksum-fill
> >>
> >> -Wei
> >>
> >> 2016-11-07 14:46 GMT+01:00 Özhan Rüzgar Karaman <
> oruzgarkaraman@gmail.com
> >> >:
> >>
> >> > Hi;
> >> > Whats your problematic vm's type is it Debian? Maybe you are affected
> >> from
> >> > the bug CLOUDSTACK-8326? I do not know if this bug has effected on ACS
> >> 4.2
> >> > release but i know that it effects release 4.8.x 4.9.x
> >> >
> >> > Thanks
> >> > Özhan
> >> >
> >> > On Mon, Nov 7, 2016 at 4:36 PM, Cloud List <cl...@sg.or.id>
> wrote:
> >> >
> >> > > Hi Wei,
> >> > >
> >> > > Thanks for your reply.
> >> > >
> >> > > I checked and I can confirm that the mac address is listed on
> >> > > /etc/dhcphosts.txt in VR.
> >> > >
> >> > > For example:
> >> > >
> >> > > Nov 7 13:30:19 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> >> 06:31:ac:01:13:YY
> >> > > ignored
> >> > > Nov 7 13:30:24 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> >> 06:31:ac:01:13:YY
> >> > > ignored
> >> > > Nov 7 13:30:33 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> >> 06:31:ac:01:13:YY
> >> > > ignored
> >> > >
> >> > > root@r-4155-VM:/var/log# grep 06:31:ac:01:13:f0 /etc/dhcphosts.txt
> >> > > 06:31:ac:01:13:YY,X.X.X.X,vm-name,infinite
> >> > >
> >> > > YY - last two digits of the mac address
> >> > > X.X.X.X - ip address which is supposed to be allocated to the VM
> >> > >
> >> > > Any advice how can I troubleshoot this further?
> >> > >
> >> > > Looking forward to your reply, thank you.
> >> > >
> >> > > Cheers.
> >> > >
> >> > >
> >> > > On Mon, Nov 7, 2016 at 9:22 PM, Wei ZHOU <us...@gmail.com>
> >> wrote:
> >> > >
> >> > > > If the mac address is not listed in /etc/dhcphosts.txt in VR, the
> >> > request
> >> > > > will be ignored.
> >> > > >
> >> > > > Can you give more details so we can reproduce it and fix it ?
> >> > > >
> >> > > > -Wei
> >> > > >
> >> > > > 2016-11-07 13:44 GMT+01:00 Cloud List <cl...@sg.or.id>:
> >> > > >
> >> > > > > Hi,
> >> > > > >
> >> > > > > After our upgrade from CloudStack 4.2 to 4.8.1.1, we noted that
> >> some
> >> > > (but
> >> > > > > not all) of our VMs are not able to get DHCP from the VR. This
> >> gives
> >> > > > > problem when the VM is restarted and cannot get up and running
> >> > because
> >> > > > > unable to get IP.
> >> > > > >
> >> > > > > I logged in to the VR and found below messages showing that the
> >> DHCP
> >> > > > server
> >> > > > > is ignoring the request from the VM.
> >> > > > >
> >> > > > > Nov 7 12:19:43 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> >> > > 06:44:da:01:13:98
> >> > > > > ignored
> >> > > > > Nov 7 12:19:52 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> >> > > 06:05:64:01:13:d3
> >> > > > > ignored
> >> > > > > Nov 7 12:19:53 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> >> > > 06:44:da:01:13:98
> >> > > > > ignored
> >> > > > > Nov 7 12:20:04 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> >> > > 06:44:da:01:13:98
> >> > > > > ignored
> >> > > > > Nov 7 12:20:11 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> >> > > 06:05:64:01:13:d3
> >> > > > > ignored
> >> > > > > Nov 7 12:20:22 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> >> > > 06:44:da:01:13:98
> >> > > > > ignored
> >> > > > > Nov 7 12:20:30 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> >> > > 06:44:da:01:13:98
> >> > > > > ignored
> >> > > > > Nov 7 12:20:42 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> >> > > 06:44:da:01:13:98
> >> > > > > ignored
> >> > > > > Nov 7 12:21:02 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> >> > > 06:44:da:01:13:98
> >> > > > > ignored
> >> > > > > Nov 7 12:21:19 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> >> > > 06:44:da:01:13:98
> >> > > > > ignored
> >> > > > >
> >> > > > > Any reason why the dnsmasq service ignored the request from the
> VM
> >> > and
> >> > > > how
> >> > > > > can we fix that?
> >> > > > >
> >> > > > > At the moment, the only workaround we can do is to configure the
> >> IP
> >> > > > address
> >> > > > > statically to the servelet, which is not practical.
> >> > > > >
> >> > > > > Any advice is greatly appreciated.
> >> > > > >
> >> > > > > Thank you.
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by Wei ZHOU <us...@gmail.com>.
You are welcome!
Good to know it.
-Wei
2016-11-10 21:01 GMT+01:00 Cloud List <cl...@sg.or.id>:
> Hi Wei,
>
> Just to let you know that the workaround you have suggested fixes the
> problem.
>
> /bin/bash /opt/cloud/bin/passwd_server_ip X.X.203.2 &
>
> Many thanks! Greatly appreciated.
>
> Cheers.
>
>
> On Fri, Nov 11, 2016 at 3:49 AM, Cloud List <cl...@sg.or.id> wrote:
>
> > Hi Wei,
> >
> > Thanks for your reply.
> >
> > I ran the command and it seems to be running very long without any
> > response. Does it take time to execute, or is it supposed to run in
> > background? e.g. shall I run with & option instead?
> >
> > /bin/bash /opt/cloud/bin/passwd_server_ip X.X.203.2 &
> >
> > Here's the result:
> >
> > root@r-4155-VM:/opt/cloud/bin# /bin/bash /opt/cloud/bin/passwd_server_ip
> > X.X.203.2
> > [no response]
> >
> > Because when I grep the process using ps aux, I can see that it seems to
> > be running as daemon for the first subnet:
> >
> > 2199 ? S 0:00 /bin/bash /opt/cloud/bin/passwd_server_ip
> > X.X.202.2 dummy
> > 2202 ? S 0:12 python /opt/cloud/bin/passwd_server_ip.py
> > X.X.202.2
> >
> > Do I also need to add the "dummy" option for the second subnet onwards?
> >
> > Looking forward to your reply, thank you.
> >
> > Cheers.
> >
> > On Thu, Nov 10, 2016 at 9:28 PM, Wei ZHOU <us...@gmail.com> wrote:
> >
> >> Sorry what I said in previous reply is wrong. The 80 port /apache2 are
> >> used
> >> for ssh-key server, not password server.
> >>
> >> For password server, there should be a passwd_server_ip.py running with
> >> corresponding ip.
> >> The password server will listen the 8080 port, and cache the vm password
> >> in
> >> /var/cache/cloud/passwords-X.X.X.X
> >>
> >> In a word, you need to run the following command:
> >> /bin/bash /opt/cloud/bin/passwd_server_ip X.X.203.2 (the vr ip in
> second
> >> ip
> >> subnet)
> >>
> >> -Wei
> >>
> >> 2016-11-10 13:07 GMT+01:00 Cloud List <cl...@sg.or.id>:
> >>
> >> > Hi Wei,
> >> >
> >> > Thanks for your reply.
> >> >
> >> > You are right, when I tried to access the other subnet IP on port 80,
> it
> >> > got connection refused. I have modified the Apache configuration to
> add
> >> the
> >> > port and virtualhost configuration and we are now able to access the
> >> other
> >> > subnet IP on port 80.
> >> >
> >> > root@test-40g-root-disk:~# telnet X.X.203.2 80
> >> > Trying X.X.203.2...
> >> > Connected to X.X.203.2.
> >> > Escape character is '^]'.
> >> > ^]
> >> > telnet> quit
> >> > Connection closed.
> >> >
> >> > However, password reset still doesn't work. Not too sure what's wrong.
> >> >
> >> > I looked at the python script on /opt/cloud/bin/passwd_server_ip.py,
> it
> >> > seems to be looking into just one file called
> >> > /var/cache/cloud/passwords-X.X.202.2 although I see some IPs from
> other
> >> > subnets as well inside the file. Is there something we need to modify
> on
> >> > the area as well?
> >> >
> >> > Any further advice is greatly appreciated.
> >> >
> >> > Thank you.
> >> >
> >> >
> >> >
> >>
> >
> >
>
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by Cloud List <cl...@sg.or.id>.
Hi Wei,
Just to let you know that the workaround you have suggested fixes the
problem.
/bin/bash /opt/cloud/bin/passwd_server_ip X.X.203.2 &
Many thanks! Greatly appreciated.
Cheers.
On Fri, Nov 11, 2016 at 3:49 AM, Cloud List <cl...@sg.or.id> wrote:
> Hi Wei,
>
> Thanks for your reply.
>
> I ran the command and it seems to be running very long without any
> response. Does it take time to execute, or is it supposed to run in
> background? e.g. shall I run with & option instead?
>
> /bin/bash /opt/cloud/bin/passwd_server_ip X.X.203.2 &
>
> Here's the result:
>
> root@r-4155-VM:/opt/cloud/bin# /bin/bash /opt/cloud/bin/passwd_server_ip
> X.X.203.2
> [no response]
>
> Because when I grep the process using ps aux, I can see that it seems to
> be running as daemon for the first subnet:
>
> 2199 ? S 0:00 /bin/bash /opt/cloud/bin/passwd_server_ip
> X.X.202.2 dummy
> 2202 ? S 0:12 python /opt/cloud/bin/passwd_server_ip.py
> X.X.202.2
>
> Do I also need to add the "dummy" option for the second subnet onwards?
>
> Looking forward to your reply, thank you.
>
> Cheers.
>
> On Thu, Nov 10, 2016 at 9:28 PM, Wei ZHOU <us...@gmail.com> wrote:
>
>> Sorry what I said in previous reply is wrong. The 80 port /apache2 are
>> used
>> for ssh-key server, not password server.
>>
>> For password server, there should be a passwd_server_ip.py running with
>> corresponding ip.
>> The password server will listen the 8080 port, and cache the vm password
>> in
>> /var/cache/cloud/passwords-X.X.X.X
>>
>> In a word, you need to run the following command:
>> /bin/bash /opt/cloud/bin/passwd_server_ip X.X.203.2 (the vr ip in second
>> ip
>> subnet)
>>
>> -Wei
>>
>> 2016-11-10 13:07 GMT+01:00 Cloud List <cl...@sg.or.id>:
>>
>> > Hi Wei,
>> >
>> > Thanks for your reply.
>> >
>> > You are right, when I tried to access the other subnet IP on port 80, it
>> > got connection refused. I have modified the Apache configuration to add
>> the
>> > port and virtualhost configuration and we are now able to access the
>> other
>> > subnet IP on port 80.
>> >
>> > root@test-40g-root-disk:~# telnet X.X.203.2 80
>> > Trying X.X.203.2...
>> > Connected to X.X.203.2.
>> > Escape character is '^]'.
>> > ^]
>> > telnet> quit
>> > Connection closed.
>> >
>> > However, password reset still doesn't work. Not too sure what's wrong.
>> >
>> > I looked at the python script on /opt/cloud/bin/passwd_server_ip.py, it
>> > seems to be looking into just one file called
>> > /var/cache/cloud/passwords-X.X.202.2 although I see some IPs from other
>> > subnets as well inside the file. Is there something we need to modify on
>> > the area as well?
>> >
>> > Any further advice is greatly appreciated.
>> >
>> > Thank you.
>> >
>> >
>> >
>>
>
>
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by Cloud List <cl...@sg.or.id>.
Hi Wei,
Thanks for your reply.
I ran the command and it seems to be running very long without any
response. Does it take time to execute, or is it supposed to run in
background? e.g. shall I run with & option instead?
/bin/bash /opt/cloud/bin/passwd_server_ip X.X.203.2 &
Here's the result:
root@r-4155-VM:/opt/cloud/bin# /bin/bash /opt/cloud/bin/passwd_server_ip
X.X.203.2
[no response]
Because when I grep the process using ps aux, I can see that it seems to be
running as daemon for the first subnet:
2199 ? S 0:00 /bin/bash /opt/cloud/bin/passwd_server_ip
X.X.202.2 dummy
2202 ? S 0:12 python /opt/cloud/bin/passwd_server_ip.py
X.X.202.2
Do I also need to add the "dummy" option for the second subnet onwards?
Looking forward to your reply, thank you.
Cheers.
On Thu, Nov 10, 2016 at 9:28 PM, Wei ZHOU <us...@gmail.com> wrote:
> Sorry what I said in previous reply is wrong. The 80 port /apache2 are used
> for ssh-key server, not password server.
>
> For password server, there should be a passwd_server_ip.py running with
> corresponding ip.
> The password server will listen the 8080 port, and cache the vm password in
> /var/cache/cloud/passwords-X.X.X.X
>
> In a word, you need to run the following command:
> /bin/bash /opt/cloud/bin/passwd_server_ip X.X.203.2 (the vr ip in second
> ip
> subnet)
>
> -Wei
>
> 2016-11-10 13:07 GMT+01:00 Cloud List <cl...@sg.or.id>:
>
> > Hi Wei,
> >
> > Thanks for your reply.
> >
> > You are right, when I tried to access the other subnet IP on port 80, it
> > got connection refused. I have modified the Apache configuration to add
> the
> > port and virtualhost configuration and we are now able to access the
> other
> > subnet IP on port 80.
> >
> > root@test-40g-root-disk:~# telnet X.X.203.2 80
> > Trying X.X.203.2...
> > Connected to X.X.203.2.
> > Escape character is '^]'.
> > ^]
> > telnet> quit
> > Connection closed.
> >
> > However, password reset still doesn't work. Not too sure what's wrong.
> >
> > I looked at the python script on /opt/cloud/bin/passwd_server_ip.py, it
> > seems to be looking into just one file called
> > /var/cache/cloud/passwords-X.X.202.2 although I see some IPs from other
> > subnets as well inside the file. Is there something we need to modify on
> > the area as well?
> >
> > Any further advice is greatly appreciated.
> >
> > Thank you.
> >
> >
> >
>
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by Wei ZHOU <us...@gmail.com>.
Sorry what I said in previous reply is wrong. The 80 port /apache2 are used
for ssh-key server, not password server.
For password server, there should be a passwd_server_ip.py running with
corresponding ip.
The password server will listen the 8080 port, and cache the vm password in
/var/cache/cloud/passwords-X.X.X.X
In a word, you need to run the following command:
/bin/bash /opt/cloud/bin/passwd_server_ip X.X.203.2 (the vr ip in second ip
subnet)
-Wei
2016-11-10 13:07 GMT+01:00 Cloud List <cl...@sg.or.id>:
> Hi Wei,
>
> Thanks for your reply.
>
> You are right, when I tried to access the other subnet IP on port 80, it
> got connection refused. I have modified the Apache configuration to add the
> port and virtualhost configuration and we are now able to access the other
> subnet IP on port 80.
>
> root@test-40g-root-disk:~# telnet X.X.203.2 80
> Trying X.X.203.2...
> Connected to X.X.203.2.
> Escape character is '^]'.
> ^]
> telnet> quit
> Connection closed.
>
> However, password reset still doesn't work. Not too sure what's wrong.
>
> I looked at the python script on /opt/cloud/bin/passwd_server_ip.py, it
> seems to be looking into just one file called
> /var/cache/cloud/passwords-X.X.202.2 although I see some IPs from other
> subnets as well inside the file. Is there something we need to modify on
> the area as well?
>
> Any further advice is greatly appreciated.
>
> Thank you.
>
>
>
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by Cloud List <cl...@sg.or.id>.
Hi Wei,
Thanks for your reply.
You are right, when I tried to access the other subnet IP on port 80, it
got connection refused. I have modified the Apache configuration to add the
port and virtualhost configuration and we are now able to access the other
subnet IP on port 80.
root@test-40g-root-disk:~# telnet X.X.203.2 80
Trying X.X.203.2...
Connected to X.X.203.2.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
However, password reset still doesn't work. Not too sure what's wrong.
I looked at the python script on /opt/cloud/bin/passwd_server_ip.py, it
seems to be looking into just one file called
/var/cache/cloud/passwords-X.X.202.2 although I see some IPs from other
subnets as well inside the file. Is there something we need to modify on
the area as well?
Any further advice is greatly appreciated.
Thank you.
On Thu, Nov 10, 2016 at 7:46 PM, Wei ZHOU <us...@gmail.com> wrote:
> The password server in VR is implemented by apache2.
> you can have a look at configuration files in /etc/apache2/ (ports.conf,
> sites-available/default, etc)
>
> you will notice that the server listens at the 80 port of default IP of VR.
> However, the VM in non-default ip subnets cannot reach the default IP.
>
> you need to create another configuration file in /etc/apache2/conf.d/ to
> support password servers on non-default ip subnets.
>
> -Wei
>
> 2016-11-10 12:23 GMT+01:00 Cloud List <cl...@sg.or.id>:
>
> > Hi Wei,
> >
> > In this case, dhcp works, and the server is up and running. But password
> > reset doesn't work. What could be the reason?
> >
> > Thanks.
> >
> >
>
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by Wei ZHOU <us...@gmail.com>.
The password server in VR is implemented by apache2.
you can have a look at configuration files in /etc/apache2/ (ports.conf,
sites-available/default, etc)
you will notice that the server listens at the 80 port of default IP of VR.
However, the VM in non-default ip subnets cannot reach the default IP.
you need to create another configuration file in /etc/apache2/conf.d/ to
support password servers on non-default ip subnets.
-Wei
2016-11-10 12:23 GMT+01:00 Cloud List <cl...@sg.or.id>:
> Hi Wei,
>
> In this case, dhcp works, and the server is up and running. But password
> reset doesn't work. What could be the reason?
>
> Thanks.
>
>
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by Cloud List <cl...@sg.or.id>.
Hi Wei,
In this case, dhcp works, and the server is up and running. But password
reset doesn't work. What could be the reason?
Thanks.
On Thu, Nov 10, 2016 at 7:01 PM, Wei ZHOU <us...@gmail.com> wrote:
> The password server depends on the dhcp services.
> The vm fetch the dhcp ip at first, then get the password from dhcp server
> (=password server).
> If dhcp does not work, then password server will not work as well.
>
> -Wei
>
> 2016-11-10 11:29 GMT+01:00 Cloud List <cl...@sg.or.id>:
>
> > Hi Wei,
> >
> > Thanks for your suggestion, will test.
> >
> > I found another problem -- it seems that password reset function also
> works
> > only for VMs on the first subnet (X.X.202.*) but not on second subnet
> > (X.X.203.*) onwards, any file I can modify to add the additional subnets
> so
> > that password reset can work? Which service is doing the password reset
> on
> > VR and which files it read?
> >
> > Looking forward to your reply, thank you.
> >
> > Cheers.
> >
> >
> > On Wed, Nov 9, 2016 at 5:59 PM, Wei ZHOU <us...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I meant some development in cloudstack to add new nic when add new ip
> > > range. it is not easy.
> > >
> > > You can have multiple shared networks untagged. As far as I see, the
> > shared
> > > networks can also have same vlan but with different subnets. I suggest
> > you
> > > to test this solution.
> > >
> > > -Wei
> > >
> > >
> > > 2016-11-09 4:24 GMT+01:00 Cloud List <cl...@sg.or.id>:
> > >
> > > > Hi Wei,
> > > >
> > > > Any documentation on how to implement your suggestion -- adding a new
> > NIC
> > > > for new IP range, while leaving the shared network untagged? Does
> this
> > > mean
> > > > that the different IP subnets can still share the same VLAN and
> > broadcast
> > > > domain?
> > > >
> > > > Looking forward to your reply, thank you.
> > > >
> > > > Cheers.
> > > >
> > > > -ip-
> > > >
> > > >
> > > >
> > > >
> > >
> >
>
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by Wei ZHOU <us...@gmail.com>.
The password server depends on the dhcp services.
The vm fetch the dhcp ip at first, then get the password from dhcp server
(=password server).
If dhcp does not work, then password server will not work as well.
-Wei
2016-11-10 11:29 GMT+01:00 Cloud List <cl...@sg.or.id>:
> Hi Wei,
>
> Thanks for your suggestion, will test.
>
> I found another problem -- it seems that password reset function also works
> only for VMs on the first subnet (X.X.202.*) but not on second subnet
> (X.X.203.*) onwards, any file I can modify to add the additional subnets so
> that password reset can work? Which service is doing the password reset on
> VR and which files it read?
>
> Looking forward to your reply, thank you.
>
> Cheers.
>
>
> On Wed, Nov 9, 2016 at 5:59 PM, Wei ZHOU <us...@gmail.com> wrote:
>
> > Hi,
> >
> > I meant some development in cloudstack to add new nic when add new ip
> > range. it is not easy.
> >
> > You can have multiple shared networks untagged. As far as I see, the
> shared
> > networks can also have same vlan but with different subnets. I suggest
> you
> > to test this solution.
> >
> > -Wei
> >
> >
> > 2016-11-09 4:24 GMT+01:00 Cloud List <cl...@sg.or.id>:
> >
> > > Hi Wei,
> > >
> > > Any documentation on how to implement your suggestion -- adding a new
> NIC
> > > for new IP range, while leaving the shared network untagged? Does this
> > mean
> > > that the different IP subnets can still share the same VLAN and
> broadcast
> > > domain?
> > >
> > > Looking forward to your reply, thank you.
> > >
> > > Cheers.
> > >
> > > -ip-
> > >
> > >
> > >
> > >
> >
>
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by Cloud List <cl...@sg.or.id>.
Hi Wei,
Thanks for your suggestion, will test.
I found another problem -- it seems that password reset function also works
only for VMs on the first subnet (X.X.202.*) but not on second subnet
(X.X.203.*) onwards, any file I can modify to add the additional subnets so
that password reset can work? Which service is doing the password reset on
VR and which files it read?
Looking forward to your reply, thank you.
Cheers.
On Wed, Nov 9, 2016 at 5:59 PM, Wei ZHOU <us...@gmail.com> wrote:
> Hi,
>
> I meant some development in cloudstack to add new nic when add new ip
> range. it is not easy.
>
> You can have multiple shared networks untagged. As far as I see, the shared
> networks can also have same vlan but with different subnets. I suggest you
> to test this solution.
>
> -Wei
>
>
> 2016-11-09 4:24 GMT+01:00 Cloud List <cl...@sg.or.id>:
>
> > Hi Wei,
> >
> > Any documentation on how to implement your suggestion -- adding a new NIC
> > for new IP range, while leaving the shared network untagged? Does this
> mean
> > that the different IP subnets can still share the same VLAN and broadcast
> > domain?
> >
> > Looking forward to your reply, thank you.
> >
> > Cheers.
> >
> > -ip-
> >
> >
> >
> >
>
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by Wei ZHOU <us...@gmail.com>.
Hi,
I meant some development in cloudstack to add new nic when add new ip
range. it is not easy.
You can have multiple shared networks untagged. As far as I see, the shared
networks can also have same vlan but with different subnets. I suggest you
to test this solution.
-Wei
2016-11-09 4:24 GMT+01:00 Cloud List <cl...@sg.or.id>:
> Hi Wei,
>
> Any documentation on how to implement your suggestion -- adding a new NIC
> for new IP range, while leaving the shared network untagged? Does this mean
> that the different IP subnets can still share the same VLAN and broadcast
> domain?
>
> Looking forward to your reply, thank you.
>
> Cheers.
>
> -ip-
>
>
>
>
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by Cloud List <cl...@sg.or.id>.
Hi Wei,
Any documentation on how to implement your suggestion -- adding a new NIC
for new IP range, while leaving the shared network untagged? Does this mean
that the different IP subnets can still share the same VLAN and broadcast
domain?
Looking forward to your reply, thank you.
Cheers.
-ip-
On Tue, Nov 8, 2016 at 9:52 PM, Wei ZHOU <us...@gmail.com> wrote:
> Hi,
>
> I do not know if it works. however, I would prefer to add a new nic for new
> ip range, like we do in vpc vrs, this need more work.
>
> The shared networks can be untagged.
>
> -Wei
>
> 2016-11-08 9:58 GMT+01:00 Cloud List <cl...@sg.or.id>:
>
> > Hi Wei,
> >
> > Adding new subnet on a a new shared network, meaning a new VLAN? But that
> > means the IPs will not be interchange-able between networks?
> >
> > I have managed to find the workaround to the problem. On the VR, I only
> see
> > the IP address of the first subnet on the eth0 interface. The remaining
> > subnets are not there. This was not the case on ACS 4.2 where each of the
> > subnet's IP has "representation" on the VR's /etc/network/interface as
> > eth0's subinterfaces (eth0:0, eth0:1, etc).
> >
> > This is what I did:
> >
> > - Add the rest of the multiple subnets as eth0 subinterfaces on
> > /etc/network/interfaces:
> >
> > iface eth0:0 inet static
> > address X.X.203.2
> > netmask 255.255.255.0
> >
> > iface eth0:1 inet static
> > address X.X.152.2
> > netmask 255.255.255.0
> >
> > iface eth0:2 inet static
> > address X.X.153.2
> > netmask 255.255.255.0
> >
> > - Bring up the sub-interfaces:
> >
> > ifup eth0:0
> > ifup eth0:1
> > ifup eth0:2
> >
> > - Add below lines on /etc/dnsmasq.conf:
> >
> > dhcp-range=X.X.203.1,static
> > dhcp-range=X.X.152.1,static
> > dhcp-range=X.X.153.1,static
> >
> > - Add below files on /etc/dnsmasq.d folder:
> >
> > cloud203.conf
> >
> > dhcp-range=interface:eth0:0,set:interface-eth0:0,X.X.203.2,static
> > dhcp-option=tag:interface-eth0:0,15,cs1cloud.internal
> > dhcp-option=tag:interface-eth0:0,6,8.8.8.8,8.8.4.4
> > dhcp-option=tag:interface-eth0:0,3,X,X.203.1
> > dhcp-option=tag:interface-eth0:0,1,255.255.255.0
> >
> > cloud152.conf, cloud153.conf etc
> >
> > - Restart dnsmasq:
> >
> > service dnsmasq restart
> >
> > Do you think the above workaround will work and there will not be any
> side
> > effect? We understand that it means we have to re-apply the configuration
> > again in the event the VR needs to be re-created.
> >
> > Looking forward to your reply, thank you.
> >
> > Cheers.
> >
> > -ip-
> >
> >
> >
> > On Tue, Nov 8, 2016 at 4:17 PM, Wei ZHOU <us...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I think it is related to multiple ip ranges in a shared network.
> > > If I change the ip in /etc/dhcphosts.txt to another ip in other range,
> I
> > > got the same error log in dnsmasq.log
> > >
> > > We do not use multiple vlan or ip ranges in a shared network. I believe
> > few
> > > of us have the same use case.
> > > If possible, it would be better to add the new ip range as a new shared
> > > network.
> > >
> > > -Wei
> > >
> > >
> > > 2016-11-07 21:35 GMT+01:00 Cloud List <cl...@sg.or.id>:
> > >
> > > > Hi Chiradeep and Wei, thanks for your reply.
> > > >
> > > > Wei, here's the result you requested:
> > > >
> > > > root@r-4155-VM:/var/log2# cat /etc/dnsmasq.conf |grep -v "^#" |grep
> -v
> > > > "^$"
> > > > domain-needed
> > > > bogus-priv
> > > > resolv-file=/etc/dnsmasq-resolv.conf
> > > > local=/cs1cloud.internal/
> > > > except-interface=eth1
> > > > except-interface=eth2
> > > > except-interface=lo
> > > > no-dhcp-interface=eth1
> > > > no-dhcp-interface=eth2
> > > > expand-hosts
> > > > domain=cs1cloud.internal
> > > > domain=cs1cloud.internal
> > > > domain=cs1cloud.internal
> > > > dhcp-range=X.Y.202.1,static
> > > > dhcp-hostsfile=/etc/dhcphosts.txt
> > > > dhcp-ignore=tag:!known
> > > > dhcp-option=15,"cs1cloud.internal"
> > > > dhcp-option=vendor:MSFT,2,1i
> > > > dhcp-boot=pxelinux.0
> > > > enable-tftp
> > > > tftp-root=/opt/tftpboot
> > > > dhcp-lease-max=2100
> > > > domain=cs1cloud.internal
> > > > log-dhcp
> > > > log-facility=/var/log2/dnsmasq.log
> > > > conf-dir=/etc/dnsmasq.d
> > > > dhcp-optsfile=/etc/dhcpopts.txt
> > > > dhcp-option=option:router,X.Y.202.1
> > > > dhcp-option=6,X.Y.202.2,8.8.8.8,8.8.4.4
> > > > dhcp-client-update
> > > >
> > > > We actually have 3 class-C subnets assigned to the network.
> > > >
> > > > X.Y.202.0/24
> > > > X.Y.203.0/24
> > > > Z.A.107.0/24
> > > >
> > > > After enabling log-dhcp as per Chiradeep Vittal, I can see that the
> > > > available DHCP subnet is only the first subnet.
> > > >
> > > > Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 available DHCP
> subnet:
> > > > X.Y.202.2/255.255.255.0
> > > > Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 available DHCP
> subnet:
> > > > X.Y.202.1/255.255.255.0
> > > > Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 client provides name:
> > > > Debian-81-64b
> > > > Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 DHCPDISCOVER(eth0)
> > > > 06:c5:38:01:13:40 ignored
> > > > Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 available DHCP
> subnet:
> > > > X.Y.202.2/255.255.255.0
> > > > Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 available DHCP
> subnet:
> > > > X.Y.202.1/255.255.255.0
> > > > Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 client provides name:
> > > > WIN-H4INMOBBRJA
> > > > Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 vendor class: MSFT
> 5.0
> > > > Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 DHCPDISCOVER(eth0)
> > > > 06:31:ac:01:13:f0 ignored
> > > >
> > > > Coincidentally, all affected VMs are coming from the second subnet:
> > > > X.Y.203.0/24, while the third subnet is rarely used.
> > > >
> > > > Do we need to specifically include the second and third subnets into
> > the
> > > > dnsmasq.conf file? I tried adding below line:
> > > >
> > > > dhcp-range=X.Y.203.1,static
> > > >
> > > > so it will become:
> > > >
> > > > dhcp-range=X.Y.202.1,static
> > > > dhcp-range=X.Y.203.1,static
> > > >
> > > > but it doesn't seem to work.
> > > >
> > > > Any advice is highly appreciated.
> > > >
> > > > Thank you.
> > > >
> > > > On Tue, Nov 8, 2016 at 4:19 AM, Wei ZHOU <us...@gmail.com>
> > wrote:
> > > >
> > > > > can you paste the result of following command?
> > > > >
> > > > > cat /etc/dnsmasq.conf |grep -v "^#" |grep -v "^$"
> > > > >
> > > > > -Wei
> > > > >
> > > > >
> > > > > 2016-11-07 20:27 GMT+01:00 Cloud List <cl...@sg.or.id>:
> > > > >
> > > > > > Hi Wei,
> > > > > >
> > > > > > In addition,
> > > > > >
> > > > > > The VR is serving a shared not isolated network, meaning the IP
> it
> > > > serves
> > > > > > is 'guest' not 'public' IP. Will that make a difference on the
> > > iptables
> > > > > > command we need to execute?
> > > > > >
> > > > > > Looking forward to your reply, thank you.
> > > > > >
> > > > > > Cheers.
> > > > > >
> > > > > >
> > > > > > On Tue, Nov 8, 2016 at 3:19 AM, Cloud List <cl...@sg.or.id>
> > > > wrote:
> > > > > >
> > > > > > > Hi Wei and Ozhan,
> > > > > > >
> > > > > > > Thanks for your reply.
> > > > > > >
> > > > > > > The problem doesn't affect only Debian-based guest VMs, but
> also
> > > > > affected
> > > > > > > some Windows and Ubuntu-based VMs as well. I have executed the
> > > > command
> > > > > on
> > > > > > > the VR and reset the NIC of the guest VM, but unfortunately the
> > > issue
> > > > > > still
> > > > > > > persists.
> > > > > > >
> > > > > > > iptables -t mangle -A POSTROUTING -p udp -m udp --dport 68 -j
> > > > CHECKSUM
> > > > > > > --checksum-fill
> > > > > > >
> > > > > > > After issuing the above command on VR and reset the NIC on
> guest
> > vm
> > > > > > > (ifdown eth0, ifup eth0):
> > > > > > >
> > > > > > > On VR's /var/log/dnsmasq.log:
> > > > > > >
> > > > > > > Nov 7 19:09:22 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > > > 06:b1:22:01:13:17
> > > > > > > ignored
> > > > > > > Nov 7 19:09:25 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > > > 06:b1:22:01:13:17
> > > > > > > ignored
> > > > > > > Nov 7 19:09:30 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > > > 06:b1:22:01:13:17
> > > > > > > ignored
> > > > > > > Nov 7 19:09:36 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > > > 06:b1:22:01:13:17
> > > > > > > ignored
> > > > > > >
> > > > > > > On the guest VM:
> > > > > > >
> > > > > > > root@vm:~# ifup eth0
> > > > > > > Internet Systems Consortium DHCP Client 4.2.2
> > > > > > > Copyright 2004-2011 Internet Systems Consortium.
> > > > > > > All rights reserved.
> > > > > > > For info, please visit https://www.isc.org/software/dhcp
> > > > > > >
> > > > > > > Listening on LPF/eth0/06:b1:22:01:13:17
> > > > > > > Sending on LPF/eth0/06:b1:22:01:13:17
> > > > > > > Sending on Socket/fallback
> > > > > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
> > > > > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
> > > > > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval
> > > > 64DHCPDISCOVER
> > > > > > on
> > > > > > > eth0 to 255.255.255.255 port 67 interval 14
> > > > > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9
> > > > > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
> > > > > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 13
> > > > > > > No DHCOFFERS received.
> > > > > > > No working leases in persistent database - sleeping.
> > > > > > >
> > > > > > > I also tried to execute similar hotfix as mentioned on the bug
> > > > report:
> > > > > > >
> > > > > > > iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j
> > CHECKSUM
> > > > > > > --checksum-fill
> > > > > > >
> > > > > > > The problem still persists. Any further advice on this is
> highly
> > > > > > > appreciated.
> > > > > > >
> > > > > > > Looking forward to your reply, thank you.
> > > > > > >
> > > > > > > Cheers.
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Nov 8, 2016 at 2:41 AM, Wei ZHOU <
> ustcweizhou@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > >> GOOD point.
> > > > > > >>
> > > > > > >> @CloudList, can you try again after executing the following
> > > command
> > > > in
> > > > > > VR
> > > > > > >> ?
> > > > > > >>
> > > > > > >> iptables -t mangle -A POSTROUTING -p udp -m udp --dport 68 -j
> > > > CHECKSUM
> > > > > > >> --checksum-fill
> > > > > > >>
> > > > > > >> -Wei
> > > > > > >>
> > > > > > >> 2016-11-07 14:46 GMT+01:00 Özhan Rüzgar Karaman <
> > > > > > oruzgarkaraman@gmail.com
> > > > > > >> >:
> > > > > > >>
> > > > > > >> > Hi;
> > > > > > >> > Whats your problematic vm's type is it Debian? Maybe you are
> > > > > affected
> > > > > > >> from
> > > > > > >> > the bug CLOUDSTACK-8326? I do not know if this bug has
> > effected
> > > on
> > > > > ACS
> > > > > > >> 4.2
> > > > > > >> > release but i know that it effects release 4.8.x 4.9.x
> > > > > > >> >
> > > > > > >> > Thanks
> > > > > > >> > Özhan
> > > > > > >> >
> > > > > > >> > On Mon, Nov 7, 2016 at 4:36 PM, Cloud List <
> > cloud-list@sg.or.id
> > > >
> > > > > > wrote:
> > > > > > >> >
> > > > > > >> > > Hi Wei,
> > > > > > >> > >
> > > > > > >> > > Thanks for your reply.
> > > > > > >> > >
> > > > > > >> > > I checked and I can confirm that the mac address is listed
> > on
> > > > > > >> > > /etc/dhcphosts.txt in VR.
> > > > > > >> > >
> > > > > > >> > > For example:
> > > > > > >> > >
> > > > > > >> > > Nov 7 13:30:19 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > > > > >> 06:31:ac:01:13:YY
> > > > > > >> > > ignored
> > > > > > >> > > Nov 7 13:30:24 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > > > > >> 06:31:ac:01:13:YY
> > > > > > >> > > ignored
> > > > > > >> > > Nov 7 13:30:33 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > > > > >> 06:31:ac:01:13:YY
> > > > > > >> > > ignored
> > > > > > >> > >
> > > > > > >> > > root@r-4155-VM:/var/log# grep 06:31:ac:01:13:f0
> > > > > /etc/dhcphosts.txt
> > > > > > >> > > 06:31:ac:01:13:YY,X.X.X.X,vm-name,infinite
> > > > > > >> > >
> > > > > > >> > > YY - last two digits of the mac address
> > > > > > >> > > X.X.X.X - ip address which is supposed to be allocated to
> > the
> > > VM
> > > > > > >> > >
> > > > > > >> > > Any advice how can I troubleshoot this further?
> > > > > > >> > >
> > > > > > >> > > Looking forward to your reply, thank you.
> > > > > > >> > >
> > > > > > >> > > Cheers.
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > On Mon, Nov 7, 2016 at 9:22 PM, Wei ZHOU <
> > > ustcweizhou@gmail.com
> > > > >
> > > > > > >> wrote:
> > > > > > >> > >
> > > > > > >> > > > If the mac address is not listed in /etc/dhcphosts.txt
> in
> > > VR,
> > > > > the
> > > > > > >> > request
> > > > > > >> > > > will be ignored.
> > > > > > >> > > >
> > > > > > >> > > > Can you give more details so we can reproduce it and fix
> > it
> > > ?
> > > > > > >> > > >
> > > > > > >> > > > -Wei
> > > > > > >> > > >
> > > > > > >> > > > 2016-11-07 13:44 GMT+01:00 Cloud List <
> > cloud-list@sg.or.id
> > > >:
> > > > > > >> > > >
> > > > > > >> > > > > Hi,
> > > > > > >> > > > >
> > > > > > >> > > > > After our upgrade from CloudStack 4.2 to 4.8.1.1, we
> > noted
> > > > > that
> > > > > > >> some
> > > > > > >> > > (but
> > > > > > >> > > > > not all) of our VMs are not able to get DHCP from the
> > VR.
> > > > This
> > > > > > >> gives
> > > > > > >> > > > > problem when the VM is restarted and cannot get up and
> > > > running
> > > > > > >> > because
> > > > > > >> > > > > unable to get IP.
> > > > > > >> > > > >
> > > > > > >> > > > > I logged in to the VR and found below messages showing
> > > that
> > > > > the
> > > > > > >> DHCP
> > > > > > >> > > > server
> > > > > > >> > > > > is ignoring the request from the VM.
> > > > > > >> > > > >
> > > > > > >> > > > > Nov 7 12:19:43 dnsmasq-dhcp[29938]:
> DHCPDISCOVER(eth0)
> > > > > > >> > > 06:44:da:01:13:98
> > > > > > >> > > > > ignored
> > > > > > >> > > > > Nov 7 12:19:52 dnsmasq-dhcp[29938]:
> DHCPDISCOVER(eth0)
> > > > > > >> > > 06:05:64:01:13:d3
> > > > > > >> > > > > ignored
> > > > > > >> > > > > Nov 7 12:19:53 dnsmasq-dhcp[29938]:
> DHCPDISCOVER(eth0)
> > > > > > >> > > 06:44:da:01:13:98
> > > > > > >> > > > > ignored
> > > > > > >> > > > > Nov 7 12:20:04 dnsmasq-dhcp[29938]:
> DHCPDISCOVER(eth0)
> > > > > > >> > > 06:44:da:01:13:98
> > > > > > >> > > > > ignored
> > > > > > >> > > > > Nov 7 12:20:11 dnsmasq-dhcp[29938]:
> DHCPDISCOVER(eth0)
> > > > > > >> > > 06:05:64:01:13:d3
> > > > > > >> > > > > ignored
> > > > > > >> > > > > Nov 7 12:20:22 dnsmasq-dhcp[29938]:
> DHCPDISCOVER(eth0)
> > > > > > >> > > 06:44:da:01:13:98
> > > > > > >> > > > > ignored
> > > > > > >> > > > > Nov 7 12:20:30 dnsmasq-dhcp[29938]:
> DHCPDISCOVER(eth0)
> > > > > > >> > > 06:44:da:01:13:98
> > > > > > >> > > > > ignored
> > > > > > >> > > > > Nov 7 12:20:42 dnsmasq-dhcp[29938]:
> DHCPDISCOVER(eth0)
> > > > > > >> > > 06:44:da:01:13:98
> > > > > > >> > > > > ignored
> > > > > > >> > > > > Nov 7 12:21:02 dnsmasq-dhcp[29938]:
> DHCPDISCOVER(eth0)
> > > > > > >> > > 06:44:da:01:13:98
> > > > > > >> > > > > ignored
> > > > > > >> > > > > Nov 7 12:21:19 dnsmasq-dhcp[29938]:
> DHCPDISCOVER(eth0)
> > > > > > >> > > 06:44:da:01:13:98
> > > > > > >> > > > > ignored
> > > > > > >> > > > >
> > > > > > >> > > > > Any reason why the dnsmasq service ignored the request
> > > from
> > > > > the
> > > > > > VM
> > > > > > >> > and
> > > > > > >> > > > how
> > > > > > >> > > > > can we fix that?
> > > > > > >> > > > >
> > > > > > >> > > > > At the moment, the only workaround we can do is to
> > > configure
> > > > > the
> > > > > > >> IP
> > > > > > >> > > > address
> > > > > > >> > > > > statically to the servelet, which is not practical.
> > > > > > >> > > > >
> > > > > > >> > > > > Any advice is greatly appreciated.
> > > > > > >> > > > >
> > > > > > >> > > > > Thank you.
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by Wei ZHOU <us...@gmail.com>.
Hi,
I do not know if it works. however, I would prefer to add a new nic for new
ip range, like we do in vpc vrs, this need more work.
The shared networks can be untagged.
-Wei
2016-11-08 9:58 GMT+01:00 Cloud List <cl...@sg.or.id>:
> Hi Wei,
>
> Adding new subnet on a a new shared network, meaning a new VLAN? But that
> means the IPs will not be interchange-able between networks?
>
> I have managed to find the workaround to the problem. On the VR, I only see
> the IP address of the first subnet on the eth0 interface. The remaining
> subnets are not there. This was not the case on ACS 4.2 where each of the
> subnet's IP has "representation" on the VR's /etc/network/interface as
> eth0's subinterfaces (eth0:0, eth0:1, etc).
>
> This is what I did:
>
> - Add the rest of the multiple subnets as eth0 subinterfaces on
> /etc/network/interfaces:
>
> iface eth0:0 inet static
> address X.X.203.2
> netmask 255.255.255.0
>
> iface eth0:1 inet static
> address X.X.152.2
> netmask 255.255.255.0
>
> iface eth0:2 inet static
> address X.X.153.2
> netmask 255.255.255.0
>
> - Bring up the sub-interfaces:
>
> ifup eth0:0
> ifup eth0:1
> ifup eth0:2
>
> - Add below lines on /etc/dnsmasq.conf:
>
> dhcp-range=X.X.203.1,static
> dhcp-range=X.X.152.1,static
> dhcp-range=X.X.153.1,static
>
> - Add below files on /etc/dnsmasq.d folder:
>
> cloud203.conf
>
> dhcp-range=interface:eth0:0,set:interface-eth0:0,X.X.203.2,static
> dhcp-option=tag:interface-eth0:0,15,cs1cloud.internal
> dhcp-option=tag:interface-eth0:0,6,8.8.8.8,8.8.4.4
> dhcp-option=tag:interface-eth0:0,3,X,X.203.1
> dhcp-option=tag:interface-eth0:0,1,255.255.255.0
>
> cloud152.conf, cloud153.conf etc
>
> - Restart dnsmasq:
>
> service dnsmasq restart
>
> Do you think the above workaround will work and there will not be any side
> effect? We understand that it means we have to re-apply the configuration
> again in the event the VR needs to be re-created.
>
> Looking forward to your reply, thank you.
>
> Cheers.
>
> -ip-
>
>
>
> On Tue, Nov 8, 2016 at 4:17 PM, Wei ZHOU <us...@gmail.com> wrote:
>
> > Hi,
> >
> > I think it is related to multiple ip ranges in a shared network.
> > If I change the ip in /etc/dhcphosts.txt to another ip in other range, I
> > got the same error log in dnsmasq.log
> >
> > We do not use multiple vlan or ip ranges in a shared network. I believe
> few
> > of us have the same use case.
> > If possible, it would be better to add the new ip range as a new shared
> > network.
> >
> > -Wei
> >
> >
> > 2016-11-07 21:35 GMT+01:00 Cloud List <cl...@sg.or.id>:
> >
> > > Hi Chiradeep and Wei, thanks for your reply.
> > >
> > > Wei, here's the result you requested:
> > >
> > > root@r-4155-VM:/var/log2# cat /etc/dnsmasq.conf |grep -v "^#" |grep -v
> > > "^$"
> > > domain-needed
> > > bogus-priv
> > > resolv-file=/etc/dnsmasq-resolv.conf
> > > local=/cs1cloud.internal/
> > > except-interface=eth1
> > > except-interface=eth2
> > > except-interface=lo
> > > no-dhcp-interface=eth1
> > > no-dhcp-interface=eth2
> > > expand-hosts
> > > domain=cs1cloud.internal
> > > domain=cs1cloud.internal
> > > domain=cs1cloud.internal
> > > dhcp-range=X.Y.202.1,static
> > > dhcp-hostsfile=/etc/dhcphosts.txt
> > > dhcp-ignore=tag:!known
> > > dhcp-option=15,"cs1cloud.internal"
> > > dhcp-option=vendor:MSFT,2,1i
> > > dhcp-boot=pxelinux.0
> > > enable-tftp
> > > tftp-root=/opt/tftpboot
> > > dhcp-lease-max=2100
> > > domain=cs1cloud.internal
> > > log-dhcp
> > > log-facility=/var/log2/dnsmasq.log
> > > conf-dir=/etc/dnsmasq.d
> > > dhcp-optsfile=/etc/dhcpopts.txt
> > > dhcp-option=option:router,X.Y.202.1
> > > dhcp-option=6,X.Y.202.2,8.8.8.8,8.8.4.4
> > > dhcp-client-update
> > >
> > > We actually have 3 class-C subnets assigned to the network.
> > >
> > > X.Y.202.0/24
> > > X.Y.203.0/24
> > > Z.A.107.0/24
> > >
> > > After enabling log-dhcp as per Chiradeep Vittal, I can see that the
> > > available DHCP subnet is only the first subnet.
> > >
> > > Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 available DHCP subnet:
> > > X.Y.202.2/255.255.255.0
> > > Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 available DHCP subnet:
> > > X.Y.202.1/255.255.255.0
> > > Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 client provides name:
> > > Debian-81-64b
> > > Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 DHCPDISCOVER(eth0)
> > > 06:c5:38:01:13:40 ignored
> > > Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 available DHCP subnet:
> > > X.Y.202.2/255.255.255.0
> > > Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 available DHCP subnet:
> > > X.Y.202.1/255.255.255.0
> > > Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 client provides name:
> > > WIN-H4INMOBBRJA
> > > Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 vendor class: MSFT 5.0
> > > Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 DHCPDISCOVER(eth0)
> > > 06:31:ac:01:13:f0 ignored
> > >
> > > Coincidentally, all affected VMs are coming from the second subnet:
> > > X.Y.203.0/24, while the third subnet is rarely used.
> > >
> > > Do we need to specifically include the second and third subnets into
> the
> > > dnsmasq.conf file? I tried adding below line:
> > >
> > > dhcp-range=X.Y.203.1,static
> > >
> > > so it will become:
> > >
> > > dhcp-range=X.Y.202.1,static
> > > dhcp-range=X.Y.203.1,static
> > >
> > > but it doesn't seem to work.
> > >
> > > Any advice is highly appreciated.
> > >
> > > Thank you.
> > >
> > > On Tue, Nov 8, 2016 at 4:19 AM, Wei ZHOU <us...@gmail.com>
> wrote:
> > >
> > > > can you paste the result of following command?
> > > >
> > > > cat /etc/dnsmasq.conf |grep -v "^#" |grep -v "^$"
> > > >
> > > > -Wei
> > > >
> > > >
> > > > 2016-11-07 20:27 GMT+01:00 Cloud List <cl...@sg.or.id>:
> > > >
> > > > > Hi Wei,
> > > > >
> > > > > In addition,
> > > > >
> > > > > The VR is serving a shared not isolated network, meaning the IP it
> > > serves
> > > > > is 'guest' not 'public' IP. Will that make a difference on the
> > iptables
> > > > > command we need to execute?
> > > > >
> > > > > Looking forward to your reply, thank you.
> > > > >
> > > > > Cheers.
> > > > >
> > > > >
> > > > > On Tue, Nov 8, 2016 at 3:19 AM, Cloud List <cl...@sg.or.id>
> > > wrote:
> > > > >
> > > > > > Hi Wei and Ozhan,
> > > > > >
> > > > > > Thanks for your reply.
> > > > > >
> > > > > > The problem doesn't affect only Debian-based guest VMs, but also
> > > > affected
> > > > > > some Windows and Ubuntu-based VMs as well. I have executed the
> > > command
> > > > on
> > > > > > the VR and reset the NIC of the guest VM, but unfortunately the
> > issue
> > > > > still
> > > > > > persists.
> > > > > >
> > > > > > iptables -t mangle -A POSTROUTING -p udp -m udp --dport 68 -j
> > > CHECKSUM
> > > > > > --checksum-fill
> > > > > >
> > > > > > After issuing the above command on VR and reset the NIC on guest
> vm
> > > > > > (ifdown eth0, ifup eth0):
> > > > > >
> > > > > > On VR's /var/log/dnsmasq.log:
> > > > > >
> > > > > > Nov 7 19:09:22 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > > 06:b1:22:01:13:17
> > > > > > ignored
> > > > > > Nov 7 19:09:25 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > > 06:b1:22:01:13:17
> > > > > > ignored
> > > > > > Nov 7 19:09:30 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > > 06:b1:22:01:13:17
> > > > > > ignored
> > > > > > Nov 7 19:09:36 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > > 06:b1:22:01:13:17
> > > > > > ignored
> > > > > >
> > > > > > On the guest VM:
> > > > > >
> > > > > > root@vm:~# ifup eth0
> > > > > > Internet Systems Consortium DHCP Client 4.2.2
> > > > > > Copyright 2004-2011 Internet Systems Consortium.
> > > > > > All rights reserved.
> > > > > > For info, please visit https://www.isc.org/software/dhcp
> > > > > >
> > > > > > Listening on LPF/eth0/06:b1:22:01:13:17
> > > > > > Sending on LPF/eth0/06:b1:22:01:13:17
> > > > > > Sending on Socket/fallback
> > > > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
> > > > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
> > > > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval
> > > 64DHCPDISCOVER
> > > > > on
> > > > > > eth0 to 255.255.255.255 port 67 interval 14
> > > > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9
> > > > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
> > > > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 13
> > > > > > No DHCOFFERS received.
> > > > > > No working leases in persistent database - sleeping.
> > > > > >
> > > > > > I also tried to execute similar hotfix as mentioned on the bug
> > > report:
> > > > > >
> > > > > > iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j
> CHECKSUM
> > > > > > --checksum-fill
> > > > > >
> > > > > > The problem still persists. Any further advice on this is highly
> > > > > > appreciated.
> > > > > >
> > > > > > Looking forward to your reply, thank you.
> > > > > >
> > > > > > Cheers.
> > > > > >
> > > > > >
> > > > > > On Tue, Nov 8, 2016 at 2:41 AM, Wei ZHOU <us...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > >> GOOD point.
> > > > > >>
> > > > > >> @CloudList, can you try again after executing the following
> > command
> > > in
> > > > > VR
> > > > > >> ?
> > > > > >>
> > > > > >> iptables -t mangle -A POSTROUTING -p udp -m udp --dport 68 -j
> > > CHECKSUM
> > > > > >> --checksum-fill
> > > > > >>
> > > > > >> -Wei
> > > > > >>
> > > > > >> 2016-11-07 14:46 GMT+01:00 Özhan Rüzgar Karaman <
> > > > > oruzgarkaraman@gmail.com
> > > > > >> >:
> > > > > >>
> > > > > >> > Hi;
> > > > > >> > Whats your problematic vm's type is it Debian? Maybe you are
> > > > affected
> > > > > >> from
> > > > > >> > the bug CLOUDSTACK-8326? I do not know if this bug has
> effected
> > on
> > > > ACS
> > > > > >> 4.2
> > > > > >> > release but i know that it effects release 4.8.x 4.9.x
> > > > > >> >
> > > > > >> > Thanks
> > > > > >> > Özhan
> > > > > >> >
> > > > > >> > On Mon, Nov 7, 2016 at 4:36 PM, Cloud List <
> cloud-list@sg.or.id
> > >
> > > > > wrote:
> > > > > >> >
> > > > > >> > > Hi Wei,
> > > > > >> > >
> > > > > >> > > Thanks for your reply.
> > > > > >> > >
> > > > > >> > > I checked and I can confirm that the mac address is listed
> on
> > > > > >> > > /etc/dhcphosts.txt in VR.
> > > > > >> > >
> > > > > >> > > For example:
> > > > > >> > >
> > > > > >> > > Nov 7 13:30:19 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > > > >> 06:31:ac:01:13:YY
> > > > > >> > > ignored
> > > > > >> > > Nov 7 13:30:24 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > > > >> 06:31:ac:01:13:YY
> > > > > >> > > ignored
> > > > > >> > > Nov 7 13:30:33 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > > > >> 06:31:ac:01:13:YY
> > > > > >> > > ignored
> > > > > >> > >
> > > > > >> > > root@r-4155-VM:/var/log# grep 06:31:ac:01:13:f0
> > > > /etc/dhcphosts.txt
> > > > > >> > > 06:31:ac:01:13:YY,X.X.X.X,vm-name,infinite
> > > > > >> > >
> > > > > >> > > YY - last two digits of the mac address
> > > > > >> > > X.X.X.X - ip address which is supposed to be allocated to
> the
> > VM
> > > > > >> > >
> > > > > >> > > Any advice how can I troubleshoot this further?
> > > > > >> > >
> > > > > >> > > Looking forward to your reply, thank you.
> > > > > >> > >
> > > > > >> > > Cheers.
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > On Mon, Nov 7, 2016 at 9:22 PM, Wei ZHOU <
> > ustcweizhou@gmail.com
> > > >
> > > > > >> wrote:
> > > > > >> > >
> > > > > >> > > > If the mac address is not listed in /etc/dhcphosts.txt in
> > VR,
> > > > the
> > > > > >> > request
> > > > > >> > > > will be ignored.
> > > > > >> > > >
> > > > > >> > > > Can you give more details so we can reproduce it and fix
> it
> > ?
> > > > > >> > > >
> > > > > >> > > > -Wei
> > > > > >> > > >
> > > > > >> > > > 2016-11-07 13:44 GMT+01:00 Cloud List <
> cloud-list@sg.or.id
> > >:
> > > > > >> > > >
> > > > > >> > > > > Hi,
> > > > > >> > > > >
> > > > > >> > > > > After our upgrade from CloudStack 4.2 to 4.8.1.1, we
> noted
> > > > that
> > > > > >> some
> > > > > >> > > (but
> > > > > >> > > > > not all) of our VMs are not able to get DHCP from the
> VR.
> > > This
> > > > > >> gives
> > > > > >> > > > > problem when the VM is restarted and cannot get up and
> > > running
> > > > > >> > because
> > > > > >> > > > > unable to get IP.
> > > > > >> > > > >
> > > > > >> > > > > I logged in to the VR and found below messages showing
> > that
> > > > the
> > > > > >> DHCP
> > > > > >> > > > server
> > > > > >> > > > > is ignoring the request from the VM.
> > > > > >> > > > >
> > > > > >> > > > > Nov 7 12:19:43 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > > > >> > > 06:44:da:01:13:98
> > > > > >> > > > > ignored
> > > > > >> > > > > Nov 7 12:19:52 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > > > >> > > 06:05:64:01:13:d3
> > > > > >> > > > > ignored
> > > > > >> > > > > Nov 7 12:19:53 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > > > >> > > 06:44:da:01:13:98
> > > > > >> > > > > ignored
> > > > > >> > > > > Nov 7 12:20:04 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > > > >> > > 06:44:da:01:13:98
> > > > > >> > > > > ignored
> > > > > >> > > > > Nov 7 12:20:11 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > > > >> > > 06:05:64:01:13:d3
> > > > > >> > > > > ignored
> > > > > >> > > > > Nov 7 12:20:22 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > > > >> > > 06:44:da:01:13:98
> > > > > >> > > > > ignored
> > > > > >> > > > > Nov 7 12:20:30 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > > > >> > > 06:44:da:01:13:98
> > > > > >> > > > > ignored
> > > > > >> > > > > Nov 7 12:20:42 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > > > >> > > 06:44:da:01:13:98
> > > > > >> > > > > ignored
> > > > > >> > > > > Nov 7 12:21:02 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > > > >> > > 06:44:da:01:13:98
> > > > > >> > > > > ignored
> > > > > >> > > > > Nov 7 12:21:19 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > > > >> > > 06:44:da:01:13:98
> > > > > >> > > > > ignored
> > > > > >> > > > >
> > > > > >> > > > > Any reason why the dnsmasq service ignored the request
> > from
> > > > the
> > > > > VM
> > > > > >> > and
> > > > > >> > > > how
> > > > > >> > > > > can we fix that?
> > > > > >> > > > >
> > > > > >> > > > > At the moment, the only workaround we can do is to
> > configure
> > > > the
> > > > > >> IP
> > > > > >> > > > address
> > > > > >> > > > > statically to the servelet, which is not practical.
> > > > > >> > > > >
> > > > > >> > > > > Any advice is greatly appreciated.
> > > > > >> > > > >
> > > > > >> > > > > Thank you.
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by Cloud List <cl...@sg.or.id>.
Hi Wei,
Adding new subnet on a a new shared network, meaning a new VLAN? But that
means the IPs will not be interchange-able between networks?
I have managed to find the workaround to the problem. On the VR, I only see
the IP address of the first subnet on the eth0 interface. The remaining
subnets are not there. This was not the case on ACS 4.2 where each of the
subnet's IP has "representation" on the VR's /etc/network/interface as
eth0's subinterfaces (eth0:0, eth0:1, etc).
This is what I did:
- Add the rest of the multiple subnets as eth0 subinterfaces on
/etc/network/interfaces:
iface eth0:0 inet static
address X.X.203.2
netmask 255.255.255.0
iface eth0:1 inet static
address X.X.152.2
netmask 255.255.255.0
iface eth0:2 inet static
address X.X.153.2
netmask 255.255.255.0
- Bring up the sub-interfaces:
ifup eth0:0
ifup eth0:1
ifup eth0:2
- Add below lines on /etc/dnsmasq.conf:
dhcp-range=X.X.203.1,static
dhcp-range=X.X.152.1,static
dhcp-range=X.X.153.1,static
- Add below files on /etc/dnsmasq.d folder:
cloud203.conf
dhcp-range=interface:eth0:0,set:interface-eth0:0,X.X.203.2,static
dhcp-option=tag:interface-eth0:0,15,cs1cloud.internal
dhcp-option=tag:interface-eth0:0,6,8.8.8.8,8.8.4.4
dhcp-option=tag:interface-eth0:0,3,X,X.203.1
dhcp-option=tag:interface-eth0:0,1,255.255.255.0
cloud152.conf, cloud153.conf etc
- Restart dnsmasq:
service dnsmasq restart
Do you think the above workaround will work and there will not be any side
effect? We understand that it means we have to re-apply the configuration
again in the event the VR needs to be re-created.
Looking forward to your reply, thank you.
Cheers.
-ip-
On Tue, Nov 8, 2016 at 4:17 PM, Wei ZHOU <us...@gmail.com> wrote:
> Hi,
>
> I think it is related to multiple ip ranges in a shared network.
> If I change the ip in /etc/dhcphosts.txt to another ip in other range, I
> got the same error log in dnsmasq.log
>
> We do not use multiple vlan or ip ranges in a shared network. I believe few
> of us have the same use case.
> If possible, it would be better to add the new ip range as a new shared
> network.
>
> -Wei
>
>
> 2016-11-07 21:35 GMT+01:00 Cloud List <cl...@sg.or.id>:
>
> > Hi Chiradeep and Wei, thanks for your reply.
> >
> > Wei, here's the result you requested:
> >
> > root@r-4155-VM:/var/log2# cat /etc/dnsmasq.conf |grep -v "^#" |grep -v
> > "^$"
> > domain-needed
> > bogus-priv
> > resolv-file=/etc/dnsmasq-resolv.conf
> > local=/cs1cloud.internal/
> > except-interface=eth1
> > except-interface=eth2
> > except-interface=lo
> > no-dhcp-interface=eth1
> > no-dhcp-interface=eth2
> > expand-hosts
> > domain=cs1cloud.internal
> > domain=cs1cloud.internal
> > domain=cs1cloud.internal
> > dhcp-range=X.Y.202.1,static
> > dhcp-hostsfile=/etc/dhcphosts.txt
> > dhcp-ignore=tag:!known
> > dhcp-option=15,"cs1cloud.internal"
> > dhcp-option=vendor:MSFT,2,1i
> > dhcp-boot=pxelinux.0
> > enable-tftp
> > tftp-root=/opt/tftpboot
> > dhcp-lease-max=2100
> > domain=cs1cloud.internal
> > log-dhcp
> > log-facility=/var/log2/dnsmasq.log
> > conf-dir=/etc/dnsmasq.d
> > dhcp-optsfile=/etc/dhcpopts.txt
> > dhcp-option=option:router,X.Y.202.1
> > dhcp-option=6,X.Y.202.2,8.8.8.8,8.8.4.4
> > dhcp-client-update
> >
> > We actually have 3 class-C subnets assigned to the network.
> >
> > X.Y.202.0/24
> > X.Y.203.0/24
> > Z.A.107.0/24
> >
> > After enabling log-dhcp as per Chiradeep Vittal, I can see that the
> > available DHCP subnet is only the first subnet.
> >
> > Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 available DHCP subnet:
> > X.Y.202.2/255.255.255.0
> > Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 available DHCP subnet:
> > X.Y.202.1/255.255.255.0
> > Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 client provides name:
> > Debian-81-64b
> > Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 DHCPDISCOVER(eth0)
> > 06:c5:38:01:13:40 ignored
> > Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 available DHCP subnet:
> > X.Y.202.2/255.255.255.0
> > Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 available DHCP subnet:
> > X.Y.202.1/255.255.255.0
> > Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 client provides name:
> > WIN-H4INMOBBRJA
> > Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 vendor class: MSFT 5.0
> > Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 DHCPDISCOVER(eth0)
> > 06:31:ac:01:13:f0 ignored
> >
> > Coincidentally, all affected VMs are coming from the second subnet:
> > X.Y.203.0/24, while the third subnet is rarely used.
> >
> > Do we need to specifically include the second and third subnets into the
> > dnsmasq.conf file? I tried adding below line:
> >
> > dhcp-range=X.Y.203.1,static
> >
> > so it will become:
> >
> > dhcp-range=X.Y.202.1,static
> > dhcp-range=X.Y.203.1,static
> >
> > but it doesn't seem to work.
> >
> > Any advice is highly appreciated.
> >
> > Thank you.
> >
> > On Tue, Nov 8, 2016 at 4:19 AM, Wei ZHOU <us...@gmail.com> wrote:
> >
> > > can you paste the result of following command?
> > >
> > > cat /etc/dnsmasq.conf |grep -v "^#" |grep -v "^$"
> > >
> > > -Wei
> > >
> > >
> > > 2016-11-07 20:27 GMT+01:00 Cloud List <cl...@sg.or.id>:
> > >
> > > > Hi Wei,
> > > >
> > > > In addition,
> > > >
> > > > The VR is serving a shared not isolated network, meaning the IP it
> > serves
> > > > is 'guest' not 'public' IP. Will that make a difference on the
> iptables
> > > > command we need to execute?
> > > >
> > > > Looking forward to your reply, thank you.
> > > >
> > > > Cheers.
> > > >
> > > >
> > > > On Tue, Nov 8, 2016 at 3:19 AM, Cloud List <cl...@sg.or.id>
> > wrote:
> > > >
> > > > > Hi Wei and Ozhan,
> > > > >
> > > > > Thanks for your reply.
> > > > >
> > > > > The problem doesn't affect only Debian-based guest VMs, but also
> > > affected
> > > > > some Windows and Ubuntu-based VMs as well. I have executed the
> > command
> > > on
> > > > > the VR and reset the NIC of the guest VM, but unfortunately the
> issue
> > > > still
> > > > > persists.
> > > > >
> > > > > iptables -t mangle -A POSTROUTING -p udp -m udp --dport 68 -j
> > CHECKSUM
> > > > > --checksum-fill
> > > > >
> > > > > After issuing the above command on VR and reset the NIC on guest vm
> > > > > (ifdown eth0, ifup eth0):
> > > > >
> > > > > On VR's /var/log/dnsmasq.log:
> > > > >
> > > > > Nov 7 19:09:22 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > 06:b1:22:01:13:17
> > > > > ignored
> > > > > Nov 7 19:09:25 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > 06:b1:22:01:13:17
> > > > > ignored
> > > > > Nov 7 19:09:30 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > 06:b1:22:01:13:17
> > > > > ignored
> > > > > Nov 7 19:09:36 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > 06:b1:22:01:13:17
> > > > > ignored
> > > > >
> > > > > On the guest VM:
> > > > >
> > > > > root@vm:~# ifup eth0
> > > > > Internet Systems Consortium DHCP Client 4.2.2
> > > > > Copyright 2004-2011 Internet Systems Consortium.
> > > > > All rights reserved.
> > > > > For info, please visit https://www.isc.org/software/dhcp
> > > > >
> > > > > Listening on LPF/eth0/06:b1:22:01:13:17
> > > > > Sending on LPF/eth0/06:b1:22:01:13:17
> > > > > Sending on Socket/fallback
> > > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
> > > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
> > > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval
> > 64DHCPDISCOVER
> > > > on
> > > > > eth0 to 255.255.255.255 port 67 interval 14
> > > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9
> > > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
> > > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 13
> > > > > No DHCOFFERS received.
> > > > > No working leases in persistent database - sleeping.
> > > > >
> > > > > I also tried to execute similar hotfix as mentioned on the bug
> > report:
> > > > >
> > > > > iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM
> > > > > --checksum-fill
> > > > >
> > > > > The problem still persists. Any further advice on this is highly
> > > > > appreciated.
> > > > >
> > > > > Looking forward to your reply, thank you.
> > > > >
> > > > > Cheers.
> > > > >
> > > > >
> > > > > On Tue, Nov 8, 2016 at 2:41 AM, Wei ZHOU <us...@gmail.com>
> > > wrote:
> > > > >
> > > > >> GOOD point.
> > > > >>
> > > > >> @CloudList, can you try again after executing the following
> command
> > in
> > > > VR
> > > > >> ?
> > > > >>
> > > > >> iptables -t mangle -A POSTROUTING -p udp -m udp --dport 68 -j
> > CHECKSUM
> > > > >> --checksum-fill
> > > > >>
> > > > >> -Wei
> > > > >>
> > > > >> 2016-11-07 14:46 GMT+01:00 Özhan Rüzgar Karaman <
> > > > oruzgarkaraman@gmail.com
> > > > >> >:
> > > > >>
> > > > >> > Hi;
> > > > >> > Whats your problematic vm's type is it Debian? Maybe you are
> > > affected
> > > > >> from
> > > > >> > the bug CLOUDSTACK-8326? I do not know if this bug has effected
> on
> > > ACS
> > > > >> 4.2
> > > > >> > release but i know that it effects release 4.8.x 4.9.x
> > > > >> >
> > > > >> > Thanks
> > > > >> > Özhan
> > > > >> >
> > > > >> > On Mon, Nov 7, 2016 at 4:36 PM, Cloud List <cloud-list@sg.or.id
> >
> > > > wrote:
> > > > >> >
> > > > >> > > Hi Wei,
> > > > >> > >
> > > > >> > > Thanks for your reply.
> > > > >> > >
> > > > >> > > I checked and I can confirm that the mac address is listed on
> > > > >> > > /etc/dhcphosts.txt in VR.
> > > > >> > >
> > > > >> > > For example:
> > > > >> > >
> > > > >> > > Nov 7 13:30:19 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > > >> 06:31:ac:01:13:YY
> > > > >> > > ignored
> > > > >> > > Nov 7 13:30:24 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > > >> 06:31:ac:01:13:YY
> > > > >> > > ignored
> > > > >> > > Nov 7 13:30:33 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > > >> 06:31:ac:01:13:YY
> > > > >> > > ignored
> > > > >> > >
> > > > >> > > root@r-4155-VM:/var/log# grep 06:31:ac:01:13:f0
> > > /etc/dhcphosts.txt
> > > > >> > > 06:31:ac:01:13:YY,X.X.X.X,vm-name,infinite
> > > > >> > >
> > > > >> > > YY - last two digits of the mac address
> > > > >> > > X.X.X.X - ip address which is supposed to be allocated to the
> VM
> > > > >> > >
> > > > >> > > Any advice how can I troubleshoot this further?
> > > > >> > >
> > > > >> > > Looking forward to your reply, thank you.
> > > > >> > >
> > > > >> > > Cheers.
> > > > >> > >
> > > > >> > >
> > > > >> > > On Mon, Nov 7, 2016 at 9:22 PM, Wei ZHOU <
> ustcweizhou@gmail.com
> > >
> > > > >> wrote:
> > > > >> > >
> > > > >> > > > If the mac address is not listed in /etc/dhcphosts.txt in
> VR,
> > > the
> > > > >> > request
> > > > >> > > > will be ignored.
> > > > >> > > >
> > > > >> > > > Can you give more details so we can reproduce it and fix it
> ?
> > > > >> > > >
> > > > >> > > > -Wei
> > > > >> > > >
> > > > >> > > > 2016-11-07 13:44 GMT+01:00 Cloud List <cloud-list@sg.or.id
> >:
> > > > >> > > >
> > > > >> > > > > Hi,
> > > > >> > > > >
> > > > >> > > > > After our upgrade from CloudStack 4.2 to 4.8.1.1, we noted
> > > that
> > > > >> some
> > > > >> > > (but
> > > > >> > > > > not all) of our VMs are not able to get DHCP from the VR.
> > This
> > > > >> gives
> > > > >> > > > > problem when the VM is restarted and cannot get up and
> > running
> > > > >> > because
> > > > >> > > > > unable to get IP.
> > > > >> > > > >
> > > > >> > > > > I logged in to the VR and found below messages showing
> that
> > > the
> > > > >> DHCP
> > > > >> > > > server
> > > > >> > > > > is ignoring the request from the VM.
> > > > >> > > > >
> > > > >> > > > > Nov 7 12:19:43 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > > >> > > 06:44:da:01:13:98
> > > > >> > > > > ignored
> > > > >> > > > > Nov 7 12:19:52 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > > >> > > 06:05:64:01:13:d3
> > > > >> > > > > ignored
> > > > >> > > > > Nov 7 12:19:53 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > > >> > > 06:44:da:01:13:98
> > > > >> > > > > ignored
> > > > >> > > > > Nov 7 12:20:04 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > > >> > > 06:44:da:01:13:98
> > > > >> > > > > ignored
> > > > >> > > > > Nov 7 12:20:11 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > > >> > > 06:05:64:01:13:d3
> > > > >> > > > > ignored
> > > > >> > > > > Nov 7 12:20:22 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > > >> > > 06:44:da:01:13:98
> > > > >> > > > > ignored
> > > > >> > > > > Nov 7 12:20:30 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > > >> > > 06:44:da:01:13:98
> > > > >> > > > > ignored
> > > > >> > > > > Nov 7 12:20:42 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > > >> > > 06:44:da:01:13:98
> > > > >> > > > > ignored
> > > > >> > > > > Nov 7 12:21:02 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > > >> > > 06:44:da:01:13:98
> > > > >> > > > > ignored
> > > > >> > > > > Nov 7 12:21:19 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > > >> > > 06:44:da:01:13:98
> > > > >> > > > > ignored
> > > > >> > > > >
> > > > >> > > > > Any reason why the dnsmasq service ignored the request
> from
> > > the
> > > > VM
> > > > >> > and
> > > > >> > > > how
> > > > >> > > > > can we fix that?
> > > > >> > > > >
> > > > >> > > > > At the moment, the only workaround we can do is to
> configure
> > > the
> > > > >> IP
> > > > >> > > > address
> > > > >> > > > > statically to the servelet, which is not practical.
> > > > >> > > > >
> > > > >> > > > > Any advice is greatly appreciated.
> > > > >> > > > >
> > > > >> > > > > Thank you.
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by Wei ZHOU <us...@gmail.com>.
Hi,
I think it is related to multiple ip ranges in a shared network.
If I change the ip in /etc/dhcphosts.txt to another ip in other range, I
got the same error log in dnsmasq.log
We do not use multiple vlan or ip ranges in a shared network. I believe few
of us have the same use case.
If possible, it would be better to add the new ip range as a new shared
network.
-Wei
2016-11-07 21:35 GMT+01:00 Cloud List <cl...@sg.or.id>:
> Hi Chiradeep and Wei, thanks for your reply.
>
> Wei, here's the result you requested:
>
> root@r-4155-VM:/var/log2# cat /etc/dnsmasq.conf |grep -v "^#" |grep -v
> "^$"
> domain-needed
> bogus-priv
> resolv-file=/etc/dnsmasq-resolv.conf
> local=/cs1cloud.internal/
> except-interface=eth1
> except-interface=eth2
> except-interface=lo
> no-dhcp-interface=eth1
> no-dhcp-interface=eth2
> expand-hosts
> domain=cs1cloud.internal
> domain=cs1cloud.internal
> domain=cs1cloud.internal
> dhcp-range=X.Y.202.1,static
> dhcp-hostsfile=/etc/dhcphosts.txt
> dhcp-ignore=tag:!known
> dhcp-option=15,"cs1cloud.internal"
> dhcp-option=vendor:MSFT,2,1i
> dhcp-boot=pxelinux.0
> enable-tftp
> tftp-root=/opt/tftpboot
> dhcp-lease-max=2100
> domain=cs1cloud.internal
> log-dhcp
> log-facility=/var/log2/dnsmasq.log
> conf-dir=/etc/dnsmasq.d
> dhcp-optsfile=/etc/dhcpopts.txt
> dhcp-option=option:router,X.Y.202.1
> dhcp-option=6,X.Y.202.2,8.8.8.8,8.8.4.4
> dhcp-client-update
>
> We actually have 3 class-C subnets assigned to the network.
>
> X.Y.202.0/24
> X.Y.203.0/24
> Z.A.107.0/24
>
> After enabling log-dhcp as per Chiradeep Vittal, I can see that the
> available DHCP subnet is only the first subnet.
>
> Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 available DHCP subnet:
> X.Y.202.2/255.255.255.0
> Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 available DHCP subnet:
> X.Y.202.1/255.255.255.0
> Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 client provides name:
> Debian-81-64b
> Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 DHCPDISCOVER(eth0)
> 06:c5:38:01:13:40 ignored
> Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 available DHCP subnet:
> X.Y.202.2/255.255.255.0
> Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 available DHCP subnet:
> X.Y.202.1/255.255.255.0
> Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 client provides name:
> WIN-H4INMOBBRJA
> Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 vendor class: MSFT 5.0
> Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 DHCPDISCOVER(eth0)
> 06:31:ac:01:13:f0 ignored
>
> Coincidentally, all affected VMs are coming from the second subnet:
> X.Y.203.0/24, while the third subnet is rarely used.
>
> Do we need to specifically include the second and third subnets into the
> dnsmasq.conf file? I tried adding below line:
>
> dhcp-range=X.Y.203.1,static
>
> so it will become:
>
> dhcp-range=X.Y.202.1,static
> dhcp-range=X.Y.203.1,static
>
> but it doesn't seem to work.
>
> Any advice is highly appreciated.
>
> Thank you.
>
> On Tue, Nov 8, 2016 at 4:19 AM, Wei ZHOU <us...@gmail.com> wrote:
>
> > can you paste the result of following command?
> >
> > cat /etc/dnsmasq.conf |grep -v "^#" |grep -v "^$"
> >
> > -Wei
> >
> >
> > 2016-11-07 20:27 GMT+01:00 Cloud List <cl...@sg.or.id>:
> >
> > > Hi Wei,
> > >
> > > In addition,
> > >
> > > The VR is serving a shared not isolated network, meaning the IP it
> serves
> > > is 'guest' not 'public' IP. Will that make a difference on the iptables
> > > command we need to execute?
> > >
> > > Looking forward to your reply, thank you.
> > >
> > > Cheers.
> > >
> > >
> > > On Tue, Nov 8, 2016 at 3:19 AM, Cloud List <cl...@sg.or.id>
> wrote:
> > >
> > > > Hi Wei and Ozhan,
> > > >
> > > > Thanks for your reply.
> > > >
> > > > The problem doesn't affect only Debian-based guest VMs, but also
> > affected
> > > > some Windows and Ubuntu-based VMs as well. I have executed the
> command
> > on
> > > > the VR and reset the NIC of the guest VM, but unfortunately the issue
> > > still
> > > > persists.
> > > >
> > > > iptables -t mangle -A POSTROUTING -p udp -m udp --dport 68 -j
> CHECKSUM
> > > > --checksum-fill
> > > >
> > > > After issuing the above command on VR and reset the NIC on guest vm
> > > > (ifdown eth0, ifup eth0):
> > > >
> > > > On VR's /var/log/dnsmasq.log:
> > > >
> > > > Nov 7 19:09:22 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > 06:b1:22:01:13:17
> > > > ignored
> > > > Nov 7 19:09:25 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > 06:b1:22:01:13:17
> > > > ignored
> > > > Nov 7 19:09:30 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > 06:b1:22:01:13:17
> > > > ignored
> > > > Nov 7 19:09:36 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > 06:b1:22:01:13:17
> > > > ignored
> > > >
> > > > On the guest VM:
> > > >
> > > > root@vm:~# ifup eth0
> > > > Internet Systems Consortium DHCP Client 4.2.2
> > > > Copyright 2004-2011 Internet Systems Consortium.
> > > > All rights reserved.
> > > > For info, please visit https://www.isc.org/software/dhcp
> > > >
> > > > Listening on LPF/eth0/06:b1:22:01:13:17
> > > > Sending on LPF/eth0/06:b1:22:01:13:17
> > > > Sending on Socket/fallback
> > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
> > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
> > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval
> 64DHCPDISCOVER
> > > on
> > > > eth0 to 255.255.255.255 port 67 interval 14
> > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9
> > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
> > > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 13
> > > > No DHCOFFERS received.
> > > > No working leases in persistent database - sleeping.
> > > >
> > > > I also tried to execute similar hotfix as mentioned on the bug
> report:
> > > >
> > > > iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM
> > > > --checksum-fill
> > > >
> > > > The problem still persists. Any further advice on this is highly
> > > > appreciated.
> > > >
> > > > Looking forward to your reply, thank you.
> > > >
> > > > Cheers.
> > > >
> > > >
> > > > On Tue, Nov 8, 2016 at 2:41 AM, Wei ZHOU <us...@gmail.com>
> > wrote:
> > > >
> > > >> GOOD point.
> > > >>
> > > >> @CloudList, can you try again after executing the following command
> in
> > > VR
> > > >> ?
> > > >>
> > > >> iptables -t mangle -A POSTROUTING -p udp -m udp --dport 68 -j
> CHECKSUM
> > > >> --checksum-fill
> > > >>
> > > >> -Wei
> > > >>
> > > >> 2016-11-07 14:46 GMT+01:00 Özhan Rüzgar Karaman <
> > > oruzgarkaraman@gmail.com
> > > >> >:
> > > >>
> > > >> > Hi;
> > > >> > Whats your problematic vm's type is it Debian? Maybe you are
> > affected
> > > >> from
> > > >> > the bug CLOUDSTACK-8326? I do not know if this bug has effected on
> > ACS
> > > >> 4.2
> > > >> > release but i know that it effects release 4.8.x 4.9.x
> > > >> >
> > > >> > Thanks
> > > >> > Özhan
> > > >> >
> > > >> > On Mon, Nov 7, 2016 at 4:36 PM, Cloud List <cl...@sg.or.id>
> > > wrote:
> > > >> >
> > > >> > > Hi Wei,
> > > >> > >
> > > >> > > Thanks for your reply.
> > > >> > >
> > > >> > > I checked and I can confirm that the mac address is listed on
> > > >> > > /etc/dhcphosts.txt in VR.
> > > >> > >
> > > >> > > For example:
> > > >> > >
> > > >> > > Nov 7 13:30:19 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > >> 06:31:ac:01:13:YY
> > > >> > > ignored
> > > >> > > Nov 7 13:30:24 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > >> 06:31:ac:01:13:YY
> > > >> > > ignored
> > > >> > > Nov 7 13:30:33 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > > >> 06:31:ac:01:13:YY
> > > >> > > ignored
> > > >> > >
> > > >> > > root@r-4155-VM:/var/log# grep 06:31:ac:01:13:f0
> > /etc/dhcphosts.txt
> > > >> > > 06:31:ac:01:13:YY,X.X.X.X,vm-name,infinite
> > > >> > >
> > > >> > > YY - last two digits of the mac address
> > > >> > > X.X.X.X - ip address which is supposed to be allocated to the VM
> > > >> > >
> > > >> > > Any advice how can I troubleshoot this further?
> > > >> > >
> > > >> > > Looking forward to your reply, thank you.
> > > >> > >
> > > >> > > Cheers.
> > > >> > >
> > > >> > >
> > > >> > > On Mon, Nov 7, 2016 at 9:22 PM, Wei ZHOU <ustcweizhou@gmail.com
> >
> > > >> wrote:
> > > >> > >
> > > >> > > > If the mac address is not listed in /etc/dhcphosts.txt in VR,
> > the
> > > >> > request
> > > >> > > > will be ignored.
> > > >> > > >
> > > >> > > > Can you give more details so we can reproduce it and fix it ?
> > > >> > > >
> > > >> > > > -Wei
> > > >> > > >
> > > >> > > > 2016-11-07 13:44 GMT+01:00 Cloud List <cl...@sg.or.id>:
> > > >> > > >
> > > >> > > > > Hi,
> > > >> > > > >
> > > >> > > > > After our upgrade from CloudStack 4.2 to 4.8.1.1, we noted
> > that
> > > >> some
> > > >> > > (but
> > > >> > > > > not all) of our VMs are not able to get DHCP from the VR.
> This
> > > >> gives
> > > >> > > > > problem when the VM is restarted and cannot get up and
> running
> > > >> > because
> > > >> > > > > unable to get IP.
> > > >> > > > >
> > > >> > > > > I logged in to the VR and found below messages showing that
> > the
> > > >> DHCP
> > > >> > > > server
> > > >> > > > > is ignoring the request from the VM.
> > > >> > > > >
> > > >> > > > > Nov 7 12:19:43 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > >> > > 06:44:da:01:13:98
> > > >> > > > > ignored
> > > >> > > > > Nov 7 12:19:52 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > >> > > 06:05:64:01:13:d3
> > > >> > > > > ignored
> > > >> > > > > Nov 7 12:19:53 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > >> > > 06:44:da:01:13:98
> > > >> > > > > ignored
> > > >> > > > > Nov 7 12:20:04 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > >> > > 06:44:da:01:13:98
> > > >> > > > > ignored
> > > >> > > > > Nov 7 12:20:11 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > >> > > 06:05:64:01:13:d3
> > > >> > > > > ignored
> > > >> > > > > Nov 7 12:20:22 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > >> > > 06:44:da:01:13:98
> > > >> > > > > ignored
> > > >> > > > > Nov 7 12:20:30 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > >> > > 06:44:da:01:13:98
> > > >> > > > > ignored
> > > >> > > > > Nov 7 12:20:42 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > >> > > 06:44:da:01:13:98
> > > >> > > > > ignored
> > > >> > > > > Nov 7 12:21:02 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > >> > > 06:44:da:01:13:98
> > > >> > > > > ignored
> > > >> > > > > Nov 7 12:21:19 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > >> > > 06:44:da:01:13:98
> > > >> > > > > ignored
> > > >> > > > >
> > > >> > > > > Any reason why the dnsmasq service ignored the request from
> > the
> > > VM
> > > >> > and
> > > >> > > > how
> > > >> > > > > can we fix that?
> > > >> > > > >
> > > >> > > > > At the moment, the only workaround we can do is to configure
> > the
> > > >> IP
> > > >> > > > address
> > > >> > > > > statically to the servelet, which is not practical.
> > > >> > > > >
> > > >> > > > > Any advice is greatly appreciated.
> > > >> > > > >
> > > >> > > > > Thank you.
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by ilya <il...@gmail.com>.
Can you move the routerVM on the same hypervisor as guest VM (or guest
VM to same hypervisor as routerVM)? If it works, then move the routerVM
out to another hypervisor within the same cluster (but same switch).
Are you running vSphere? I've seen similar problem where ARPs would not
make it thru due to some intricacy with VMware and Cisco (or perhaps
Juniper) switch upstream. Solution was to console in to vRouter and ping
a host 2 hops aways. That would fix ARP issue (albeit temporary).
Let me know if it helps,
Regards
ilya
On 11/7/16 12:35 PM, Cloud List wrote:
> Hi Chiradeep and Wei, thanks for your reply.
>
> Wei, here's the result you requested:
>
> root@r-4155-VM:/var/log2# cat /etc/dnsmasq.conf |grep -v "^#" |grep -v "^$"
> domain-needed
> bogus-priv
> resolv-file=/etc/dnsmasq-resolv.conf
> local=/cs1cloud.internal/
> except-interface=eth1
> except-interface=eth2
> except-interface=lo
> no-dhcp-interface=eth1
> no-dhcp-interface=eth2
> expand-hosts
> domain=cs1cloud.internal
> domain=cs1cloud.internal
> domain=cs1cloud.internal
> dhcp-range=X.Y.202.1,static
> dhcp-hostsfile=/etc/dhcphosts.txt
> dhcp-ignore=tag:!known
> dhcp-option=15,"cs1cloud.internal"
> dhcp-option=vendor:MSFT,2,1i
> dhcp-boot=pxelinux.0
> enable-tftp
> tftp-root=/opt/tftpboot
> dhcp-lease-max=2100
> domain=cs1cloud.internal
> log-dhcp
> log-facility=/var/log2/dnsmasq.log
> conf-dir=/etc/dnsmasq.d
> dhcp-optsfile=/etc/dhcpopts.txt
> dhcp-option=option:router,X.Y.202.1
> dhcp-option=6,X.Y.202.2,8.8.8.8,8.8.4.4
> dhcp-client-update
>
> We actually have 3 class-C subnets assigned to the network.
>
> X.Y.202.0/24
> X.Y.203.0/24
> Z.A.107.0/24
>
> After enabling log-dhcp as per Chiradeep Vittal, I can see that the
> available DHCP subnet is only the first subnet.
>
> Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 available DHCP subnet:
> X.Y.202.2/255.255.255.0
> Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 available DHCP subnet:
> X.Y.202.1/255.255.255.0
> Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 client provides name:
> Debian-81-64b
> Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 DHCPDISCOVER(eth0)
> 06:c5:38:01:13:40 ignored
> Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 available DHCP subnet:
> X.Y.202.2/255.255.255.0
> Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 available DHCP subnet:
> X.Y.202.1/255.255.255.0
> Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 client provides name:
> WIN-H4INMOBBRJA
> Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 vendor class: MSFT 5.0
> Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 DHCPDISCOVER(eth0)
> 06:31:ac:01:13:f0 ignored
>
> Coincidentally, all affected VMs are coming from the second subnet:
> X.Y.203.0/24, while the third subnet is rarely used.
>
> Do we need to specifically include the second and third subnets into the
> dnsmasq.conf file? I tried adding below line:
>
> dhcp-range=X.Y.203.1,static
>
> so it will become:
>
> dhcp-range=X.Y.202.1,static
> dhcp-range=X.Y.203.1,static
>
> but it doesn't seem to work.
>
> Any advice is highly appreciated.
>
> Thank you.
>
> On Tue, Nov 8, 2016 at 4:19 AM, Wei ZHOU <us...@gmail.com> wrote:
>
>> can you paste the result of following command?
>>
>> cat /etc/dnsmasq.conf |grep -v "^#" |grep -v "^$"
>>
>> -Wei
>>
>>
>> 2016-11-07 20:27 GMT+01:00 Cloud List <cl...@sg.or.id>:
>>
>>> Hi Wei,
>>>
>>> In addition,
>>>
>>> The VR is serving a shared not isolated network, meaning the IP it serves
>>> is 'guest' not 'public' IP. Will that make a difference on the iptables
>>> command we need to execute?
>>>
>>> Looking forward to your reply, thank you.
>>>
>>> Cheers.
>>>
>>>
>>> On Tue, Nov 8, 2016 at 3:19 AM, Cloud List <cl...@sg.or.id> wrote:
>>>
>>>> Hi Wei and Ozhan,
>>>>
>>>> Thanks for your reply.
>>>>
>>>> The problem doesn't affect only Debian-based guest VMs, but also
>> affected
>>>> some Windows and Ubuntu-based VMs as well. I have executed the command
>> on
>>>> the VR and reset the NIC of the guest VM, but unfortunately the issue
>>> still
>>>> persists.
>>>>
>>>> iptables -t mangle -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM
>>>> --checksum-fill
>>>>
>>>> After issuing the above command on VR and reset the NIC on guest vm
>>>> (ifdown eth0, ifup eth0):
>>>>
>>>> On VR's /var/log/dnsmasq.log:
>>>>
>>>> Nov 7 19:09:22 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
>> 06:b1:22:01:13:17
>>>> ignored
>>>> Nov 7 19:09:25 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
>> 06:b1:22:01:13:17
>>>> ignored
>>>> Nov 7 19:09:30 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
>> 06:b1:22:01:13:17
>>>> ignored
>>>> Nov 7 19:09:36 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
>> 06:b1:22:01:13:17
>>>> ignored
>>>>
>>>> On the guest VM:
>>>>
>>>> root@vm:~# ifup eth0
>>>> Internet Systems Consortium DHCP Client 4.2.2
>>>> Copyright 2004-2011 Internet Systems Consortium.
>>>> All rights reserved.
>>>> For info, please visit https://www.isc.org/software/dhcp
>>>>
>>>> Listening on LPF/eth0/06:b1:22:01:13:17
>>>> Sending on LPF/eth0/06:b1:22:01:13:17
>>>> Sending on Socket/fallback
>>>> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
>>>> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
>>>> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 64DHCPDISCOVER
>>> on
>>>> eth0 to 255.255.255.255 port 67 interval 14
>>>> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9
>>>> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
>>>> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 13
>>>> No DHCOFFERS received.
>>>> No working leases in persistent database - sleeping.
>>>>
>>>> I also tried to execute similar hotfix as mentioned on the bug report:
>>>>
>>>> iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM
>>>> --checksum-fill
>>>>
>>>> The problem still persists. Any further advice on this is highly
>>>> appreciated.
>>>>
>>>> Looking forward to your reply, thank you.
>>>>
>>>> Cheers.
>>>>
>>>>
>>>> On Tue, Nov 8, 2016 at 2:41 AM, Wei ZHOU <us...@gmail.com>
>> wrote:
>>>>
>>>>> GOOD point.
>>>>>
>>>>> @CloudList, can you try again after executing the following command in
>>> VR
>>>>> ?
>>>>>
>>>>> iptables -t mangle -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM
>>>>> --checksum-fill
>>>>>
>>>>> -Wei
>>>>>
>>>>> 2016-11-07 14:46 GMT+01:00 �zhan R�zgar Karaman <
>>> oruzgarkaraman@gmail.com
>>>>>> :
>>>>>
>>>>>> Hi;
>>>>>> Whats your problematic vm's type is it Debian? Maybe you are
>> affected
>>>>> from
>>>>>> the bug CLOUDSTACK-8326? I do not know if this bug has effected on
>> ACS
>>>>> 4.2
>>>>>> release but i know that it effects release 4.8.x 4.9.x
>>>>>>
>>>>>> Thanks
>>>>>> �zhan
>>>>>>
>>>>>> On Mon, Nov 7, 2016 at 4:36 PM, Cloud List <cl...@sg.or.id>
>>> wrote:
>>>>>>
>>>>>>> Hi Wei,
>>>>>>>
>>>>>>> Thanks for your reply.
>>>>>>>
>>>>>>> I checked and I can confirm that the mac address is listed on
>>>>>>> /etc/dhcphosts.txt in VR.
>>>>>>>
>>>>>>> For example:
>>>>>>>
>>>>>>> Nov 7 13:30:19 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
>>>>> 06:31:ac:01:13:YY
>>>>>>> ignored
>>>>>>> Nov 7 13:30:24 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
>>>>> 06:31:ac:01:13:YY
>>>>>>> ignored
>>>>>>> Nov 7 13:30:33 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
>>>>> 06:31:ac:01:13:YY
>>>>>>> ignored
>>>>>>>
>>>>>>> root@r-4155-VM:/var/log# grep 06:31:ac:01:13:f0
>> /etc/dhcphosts.txt
>>>>>>> 06:31:ac:01:13:YY,X.X.X.X,vm-name,infinite
>>>>>>>
>>>>>>> YY - last two digits of the mac address
>>>>>>> X.X.X.X - ip address which is supposed to be allocated to the VM
>>>>>>>
>>>>>>> Any advice how can I troubleshoot this further?
>>>>>>>
>>>>>>> Looking forward to your reply, thank you.
>>>>>>>
>>>>>>> Cheers.
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 7, 2016 at 9:22 PM, Wei ZHOU <us...@gmail.com>
>>>>> wrote:
>>>>>>>
>>>>>>>> If the mac address is not listed in /etc/dhcphosts.txt in VR,
>> the
>>>>>> request
>>>>>>>> will be ignored.
>>>>>>>>
>>>>>>>> Can you give more details so we can reproduce it and fix it ?
>>>>>>>>
>>>>>>>> -Wei
>>>>>>>>
>>>>>>>> 2016-11-07 13:44 GMT+01:00 Cloud List <cl...@sg.or.id>:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> After our upgrade from CloudStack 4.2 to 4.8.1.1, we noted
>> that
>>>>> some
>>>>>>> (but
>>>>>>>>> not all) of our VMs are not able to get DHCP from the VR. This
>>>>> gives
>>>>>>>>> problem when the VM is restarted and cannot get up and running
>>>>>> because
>>>>>>>>> unable to get IP.
>>>>>>>>>
>>>>>>>>> I logged in to the VR and found below messages showing that
>> the
>>>>> DHCP
>>>>>>>> server
>>>>>>>>> is ignoring the request from the VM.
>>>>>>>>>
>>>>>>>>> Nov 7 12:19:43 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
>>>>>>> 06:44:da:01:13:98
>>>>>>>>> ignored
>>>>>>>>> Nov 7 12:19:52 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
>>>>>>> 06:05:64:01:13:d3
>>>>>>>>> ignored
>>>>>>>>> Nov 7 12:19:53 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
>>>>>>> 06:44:da:01:13:98
>>>>>>>>> ignored
>>>>>>>>> Nov 7 12:20:04 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
>>>>>>> 06:44:da:01:13:98
>>>>>>>>> ignored
>>>>>>>>> Nov 7 12:20:11 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
>>>>>>> 06:05:64:01:13:d3
>>>>>>>>> ignored
>>>>>>>>> Nov 7 12:20:22 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
>>>>>>> 06:44:da:01:13:98
>>>>>>>>> ignored
>>>>>>>>> Nov 7 12:20:30 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
>>>>>>> 06:44:da:01:13:98
>>>>>>>>> ignored
>>>>>>>>> Nov 7 12:20:42 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
>>>>>>> 06:44:da:01:13:98
>>>>>>>>> ignored
>>>>>>>>> Nov 7 12:21:02 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
>>>>>>> 06:44:da:01:13:98
>>>>>>>>> ignored
>>>>>>>>> Nov 7 12:21:19 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
>>>>>>> 06:44:da:01:13:98
>>>>>>>>> ignored
>>>>>>>>>
>>>>>>>>> Any reason why the dnsmasq service ignored the request from
>> the
>>> VM
>>>>>> and
>>>>>>>> how
>>>>>>>>> can we fix that?
>>>>>>>>>
>>>>>>>>> At the moment, the only workaround we can do is to configure
>> the
>>>>> IP
>>>>>>>> address
>>>>>>>>> statically to the servelet, which is not practical.
>>>>>>>>>
>>>>>>>>> Any advice is greatly appreciated.
>>>>>>>>>
>>>>>>>>> Thank you.
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by Cloud List <cl...@sg.or.id>.
Hi Chiradeep and Wei, thanks for your reply.
Wei, here's the result you requested:
root@r-4155-VM:/var/log2# cat /etc/dnsmasq.conf |grep -v "^#" |grep -v "^$"
domain-needed
bogus-priv
resolv-file=/etc/dnsmasq-resolv.conf
local=/cs1cloud.internal/
except-interface=eth1
except-interface=eth2
except-interface=lo
no-dhcp-interface=eth1
no-dhcp-interface=eth2
expand-hosts
domain=cs1cloud.internal
domain=cs1cloud.internal
domain=cs1cloud.internal
dhcp-range=X.Y.202.1,static
dhcp-hostsfile=/etc/dhcphosts.txt
dhcp-ignore=tag:!known
dhcp-option=15,"cs1cloud.internal"
dhcp-option=vendor:MSFT,2,1i
dhcp-boot=pxelinux.0
enable-tftp
tftp-root=/opt/tftpboot
dhcp-lease-max=2100
domain=cs1cloud.internal
log-dhcp
log-facility=/var/log2/dnsmasq.log
conf-dir=/etc/dnsmasq.d
dhcp-optsfile=/etc/dhcpopts.txt
dhcp-option=option:router,X.Y.202.1
dhcp-option=6,X.Y.202.2,8.8.8.8,8.8.4.4
dhcp-client-update
We actually have 3 class-C subnets assigned to the network.
X.Y.202.0/24
X.Y.203.0/24
Z.A.107.0/24
After enabling log-dhcp as per Chiradeep Vittal, I can see that the
available DHCP subnet is only the first subnet.
Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 available DHCP subnet:
X.Y.202.2/255.255.255.0
Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 available DHCP subnet:
X.Y.202.1/255.255.255.0
Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 client provides name:
Debian-81-64b
Nov 7 20:27:49 dnsmasq-dhcp[22462]: 1979424125 DHCPDISCOVER(eth0)
06:c5:38:01:13:40 ignored
Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 available DHCP subnet:
X.Y.202.2/255.255.255.0
Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 available DHCP subnet:
X.Y.202.1/255.255.255.0
Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 client provides name:
WIN-H4INMOBBRJA
Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 vendor class: MSFT 5.0
Nov 7 20:27:51 dnsmasq-dhcp[22462]: 2670909966 DHCPDISCOVER(eth0)
06:31:ac:01:13:f0 ignored
Coincidentally, all affected VMs are coming from the second subnet:
X.Y.203.0/24, while the third subnet is rarely used.
Do we need to specifically include the second and third subnets into the
dnsmasq.conf file? I tried adding below line:
dhcp-range=X.Y.203.1,static
so it will become:
dhcp-range=X.Y.202.1,static
dhcp-range=X.Y.203.1,static
but it doesn't seem to work.
Any advice is highly appreciated.
Thank you.
On Tue, Nov 8, 2016 at 4:19 AM, Wei ZHOU <us...@gmail.com> wrote:
> can you paste the result of following command?
>
> cat /etc/dnsmasq.conf |grep -v "^#" |grep -v "^$"
>
> -Wei
>
>
> 2016-11-07 20:27 GMT+01:00 Cloud List <cl...@sg.or.id>:
>
> > Hi Wei,
> >
> > In addition,
> >
> > The VR is serving a shared not isolated network, meaning the IP it serves
> > is 'guest' not 'public' IP. Will that make a difference on the iptables
> > command we need to execute?
> >
> > Looking forward to your reply, thank you.
> >
> > Cheers.
> >
> >
> > On Tue, Nov 8, 2016 at 3:19 AM, Cloud List <cl...@sg.or.id> wrote:
> >
> > > Hi Wei and Ozhan,
> > >
> > > Thanks for your reply.
> > >
> > > The problem doesn't affect only Debian-based guest VMs, but also
> affected
> > > some Windows and Ubuntu-based VMs as well. I have executed the command
> on
> > > the VR and reset the NIC of the guest VM, but unfortunately the issue
> > still
> > > persists.
> > >
> > > iptables -t mangle -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM
> > > --checksum-fill
> > >
> > > After issuing the above command on VR and reset the NIC on guest vm
> > > (ifdown eth0, ifup eth0):
> > >
> > > On VR's /var/log/dnsmasq.log:
> > >
> > > Nov 7 19:09:22 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> 06:b1:22:01:13:17
> > > ignored
> > > Nov 7 19:09:25 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> 06:b1:22:01:13:17
> > > ignored
> > > Nov 7 19:09:30 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> 06:b1:22:01:13:17
> > > ignored
> > > Nov 7 19:09:36 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> 06:b1:22:01:13:17
> > > ignored
> > >
> > > On the guest VM:
> > >
> > > root@vm:~# ifup eth0
> > > Internet Systems Consortium DHCP Client 4.2.2
> > > Copyright 2004-2011 Internet Systems Consortium.
> > > All rights reserved.
> > > For info, please visit https://www.isc.org/software/dhcp
> > >
> > > Listening on LPF/eth0/06:b1:22:01:13:17
> > > Sending on LPF/eth0/06:b1:22:01:13:17
> > > Sending on Socket/fallback
> > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
> > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
> > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 64DHCPDISCOVER
> > on
> > > eth0 to 255.255.255.255 port 67 interval 14
> > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9
> > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
> > > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 13
> > > No DHCOFFERS received.
> > > No working leases in persistent database - sleeping.
> > >
> > > I also tried to execute similar hotfix as mentioned on the bug report:
> > >
> > > iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM
> > > --checksum-fill
> > >
> > > The problem still persists. Any further advice on this is highly
> > > appreciated.
> > >
> > > Looking forward to your reply, thank you.
> > >
> > > Cheers.
> > >
> > >
> > > On Tue, Nov 8, 2016 at 2:41 AM, Wei ZHOU <us...@gmail.com>
> wrote:
> > >
> > >> GOOD point.
> > >>
> > >> @CloudList, can you try again after executing the following command in
> > VR
> > >> ?
> > >>
> > >> iptables -t mangle -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM
> > >> --checksum-fill
> > >>
> > >> -Wei
> > >>
> > >> 2016-11-07 14:46 GMT+01:00 Özhan Rüzgar Karaman <
> > oruzgarkaraman@gmail.com
> > >> >:
> > >>
> > >> > Hi;
> > >> > Whats your problematic vm's type is it Debian? Maybe you are
> affected
> > >> from
> > >> > the bug CLOUDSTACK-8326? I do not know if this bug has effected on
> ACS
> > >> 4.2
> > >> > release but i know that it effects release 4.8.x 4.9.x
> > >> >
> > >> > Thanks
> > >> > Özhan
> > >> >
> > >> > On Mon, Nov 7, 2016 at 4:36 PM, Cloud List <cl...@sg.or.id>
> > wrote:
> > >> >
> > >> > > Hi Wei,
> > >> > >
> > >> > > Thanks for your reply.
> > >> > >
> > >> > > I checked and I can confirm that the mac address is listed on
> > >> > > /etc/dhcphosts.txt in VR.
> > >> > >
> > >> > > For example:
> > >> > >
> > >> > > Nov 7 13:30:19 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > >> 06:31:ac:01:13:YY
> > >> > > ignored
> > >> > > Nov 7 13:30:24 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > >> 06:31:ac:01:13:YY
> > >> > > ignored
> > >> > > Nov 7 13:30:33 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> > >> 06:31:ac:01:13:YY
> > >> > > ignored
> > >> > >
> > >> > > root@r-4155-VM:/var/log# grep 06:31:ac:01:13:f0
> /etc/dhcphosts.txt
> > >> > > 06:31:ac:01:13:YY,X.X.X.X,vm-name,infinite
> > >> > >
> > >> > > YY - last two digits of the mac address
> > >> > > X.X.X.X - ip address which is supposed to be allocated to the VM
> > >> > >
> > >> > > Any advice how can I troubleshoot this further?
> > >> > >
> > >> > > Looking forward to your reply, thank you.
> > >> > >
> > >> > > Cheers.
> > >> > >
> > >> > >
> > >> > > On Mon, Nov 7, 2016 at 9:22 PM, Wei ZHOU <us...@gmail.com>
> > >> wrote:
> > >> > >
> > >> > > > If the mac address is not listed in /etc/dhcphosts.txt in VR,
> the
> > >> > request
> > >> > > > will be ignored.
> > >> > > >
> > >> > > > Can you give more details so we can reproduce it and fix it ?
> > >> > > >
> > >> > > > -Wei
> > >> > > >
> > >> > > > 2016-11-07 13:44 GMT+01:00 Cloud List <cl...@sg.or.id>:
> > >> > > >
> > >> > > > > Hi,
> > >> > > > >
> > >> > > > > After our upgrade from CloudStack 4.2 to 4.8.1.1, we noted
> that
> > >> some
> > >> > > (but
> > >> > > > > not all) of our VMs are not able to get DHCP from the VR. This
> > >> gives
> > >> > > > > problem when the VM is restarted and cannot get up and running
> > >> > because
> > >> > > > > unable to get IP.
> > >> > > > >
> > >> > > > > I logged in to the VR and found below messages showing that
> the
> > >> DHCP
> > >> > > > server
> > >> > > > > is ignoring the request from the VM.
> > >> > > > >
> > >> > > > > Nov 7 12:19:43 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > >> > > 06:44:da:01:13:98
> > >> > > > > ignored
> > >> > > > > Nov 7 12:19:52 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > >> > > 06:05:64:01:13:d3
> > >> > > > > ignored
> > >> > > > > Nov 7 12:19:53 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > >> > > 06:44:da:01:13:98
> > >> > > > > ignored
> > >> > > > > Nov 7 12:20:04 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > >> > > 06:44:da:01:13:98
> > >> > > > > ignored
> > >> > > > > Nov 7 12:20:11 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > >> > > 06:05:64:01:13:d3
> > >> > > > > ignored
> > >> > > > > Nov 7 12:20:22 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > >> > > 06:44:da:01:13:98
> > >> > > > > ignored
> > >> > > > > Nov 7 12:20:30 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > >> > > 06:44:da:01:13:98
> > >> > > > > ignored
> > >> > > > > Nov 7 12:20:42 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > >> > > 06:44:da:01:13:98
> > >> > > > > ignored
> > >> > > > > Nov 7 12:21:02 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > >> > > 06:44:da:01:13:98
> > >> > > > > ignored
> > >> > > > > Nov 7 12:21:19 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > >> > > 06:44:da:01:13:98
> > >> > > > > ignored
> > >> > > > >
> > >> > > > > Any reason why the dnsmasq service ignored the request from
> the
> > VM
> > >> > and
> > >> > > > how
> > >> > > > > can we fix that?
> > >> > > > >
> > >> > > > > At the moment, the only workaround we can do is to configure
> the
> > >> IP
> > >> > > > address
> > >> > > > > statically to the servelet, which is not practical.
> > >> > > > >
> > >> > > > > Any advice is greatly appreciated.
> > >> > > > >
> > >> > > > > Thank you.
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by Wei ZHOU <us...@gmail.com>.
can you paste the result of following command?
cat /etc/dnsmasq.conf |grep -v "^#" |grep -v "^$"
-Wei
2016-11-07 20:27 GMT+01:00 Cloud List <cl...@sg.or.id>:
> Hi Wei,
>
> In addition,
>
> The VR is serving a shared not isolated network, meaning the IP it serves
> is 'guest' not 'public' IP. Will that make a difference on the iptables
> command we need to execute?
>
> Looking forward to your reply, thank you.
>
> Cheers.
>
>
> On Tue, Nov 8, 2016 at 3:19 AM, Cloud List <cl...@sg.or.id> wrote:
>
> > Hi Wei and Ozhan,
> >
> > Thanks for your reply.
> >
> > The problem doesn't affect only Debian-based guest VMs, but also affected
> > some Windows and Ubuntu-based VMs as well. I have executed the command on
> > the VR and reset the NIC of the guest VM, but unfortunately the issue
> still
> > persists.
> >
> > iptables -t mangle -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM
> > --checksum-fill
> >
> > After issuing the above command on VR and reset the NIC on guest vm
> > (ifdown eth0, ifup eth0):
> >
> > On VR's /var/log/dnsmasq.log:
> >
> > Nov 7 19:09:22 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:b1:22:01:13:17
> > ignored
> > Nov 7 19:09:25 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:b1:22:01:13:17
> > ignored
> > Nov 7 19:09:30 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:b1:22:01:13:17
> > ignored
> > Nov 7 19:09:36 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:b1:22:01:13:17
> > ignored
> >
> > On the guest VM:
> >
> > root@vm:~# ifup eth0
> > Internet Systems Consortium DHCP Client 4.2.2
> > Copyright 2004-2011 Internet Systems Consortium.
> > All rights reserved.
> > For info, please visit https://www.isc.org/software/dhcp
> >
> > Listening on LPF/eth0/06:b1:22:01:13:17
> > Sending on LPF/eth0/06:b1:22:01:13:17
> > Sending on Socket/fallback
> > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
> > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
> > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 64DHCPDISCOVER
> on
> > eth0 to 255.255.255.255 port 67 interval 14
> > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9
> > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
> > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 13
> > No DHCOFFERS received.
> > No working leases in persistent database - sleeping.
> >
> > I also tried to execute similar hotfix as mentioned on the bug report:
> >
> > iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM
> > --checksum-fill
> >
> > The problem still persists. Any further advice on this is highly
> > appreciated.
> >
> > Looking forward to your reply, thank you.
> >
> > Cheers.
> >
> >
> > On Tue, Nov 8, 2016 at 2:41 AM, Wei ZHOU <us...@gmail.com> wrote:
> >
> >> GOOD point.
> >>
> >> @CloudList, can you try again after executing the following command in
> VR
> >> ?
> >>
> >> iptables -t mangle -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM
> >> --checksum-fill
> >>
> >> -Wei
> >>
> >> 2016-11-07 14:46 GMT+01:00 Özhan Rüzgar Karaman <
> oruzgarkaraman@gmail.com
> >> >:
> >>
> >> > Hi;
> >> > Whats your problematic vm's type is it Debian? Maybe you are affected
> >> from
> >> > the bug CLOUDSTACK-8326? I do not know if this bug has effected on ACS
> >> 4.2
> >> > release but i know that it effects release 4.8.x 4.9.x
> >> >
> >> > Thanks
> >> > Özhan
> >> >
> >> > On Mon, Nov 7, 2016 at 4:36 PM, Cloud List <cl...@sg.or.id>
> wrote:
> >> >
> >> > > Hi Wei,
> >> > >
> >> > > Thanks for your reply.
> >> > >
> >> > > I checked and I can confirm that the mac address is listed on
> >> > > /etc/dhcphosts.txt in VR.
> >> > >
> >> > > For example:
> >> > >
> >> > > Nov 7 13:30:19 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> >> 06:31:ac:01:13:YY
> >> > > ignored
> >> > > Nov 7 13:30:24 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> >> 06:31:ac:01:13:YY
> >> > > ignored
> >> > > Nov 7 13:30:33 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> >> 06:31:ac:01:13:YY
> >> > > ignored
> >> > >
> >> > > root@r-4155-VM:/var/log# grep 06:31:ac:01:13:f0 /etc/dhcphosts.txt
> >> > > 06:31:ac:01:13:YY,X.X.X.X,vm-name,infinite
> >> > >
> >> > > YY - last two digits of the mac address
> >> > > X.X.X.X - ip address which is supposed to be allocated to the VM
> >> > >
> >> > > Any advice how can I troubleshoot this further?
> >> > >
> >> > > Looking forward to your reply, thank you.
> >> > >
> >> > > Cheers.
> >> > >
> >> > >
> >> > > On Mon, Nov 7, 2016 at 9:22 PM, Wei ZHOU <us...@gmail.com>
> >> wrote:
> >> > >
> >> > > > If the mac address is not listed in /etc/dhcphosts.txt in VR, the
> >> > request
> >> > > > will be ignored.
> >> > > >
> >> > > > Can you give more details so we can reproduce it and fix it ?
> >> > > >
> >> > > > -Wei
> >> > > >
> >> > > > 2016-11-07 13:44 GMT+01:00 Cloud List <cl...@sg.or.id>:
> >> > > >
> >> > > > > Hi,
> >> > > > >
> >> > > > > After our upgrade from CloudStack 4.2 to 4.8.1.1, we noted that
> >> some
> >> > > (but
> >> > > > > not all) of our VMs are not able to get DHCP from the VR. This
> >> gives
> >> > > > > problem when the VM is restarted and cannot get up and running
> >> > because
> >> > > > > unable to get IP.
> >> > > > >
> >> > > > > I logged in to the VR and found below messages showing that the
> >> DHCP
> >> > > > server
> >> > > > > is ignoring the request from the VM.
> >> > > > >
> >> > > > > Nov 7 12:19:43 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> >> > > 06:44:da:01:13:98
> >> > > > > ignored
> >> > > > > Nov 7 12:19:52 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> >> > > 06:05:64:01:13:d3
> >> > > > > ignored
> >> > > > > Nov 7 12:19:53 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> >> > > 06:44:da:01:13:98
> >> > > > > ignored
> >> > > > > Nov 7 12:20:04 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> >> > > 06:44:da:01:13:98
> >> > > > > ignored
> >> > > > > Nov 7 12:20:11 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> >> > > 06:05:64:01:13:d3
> >> > > > > ignored
> >> > > > > Nov 7 12:20:22 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> >> > > 06:44:da:01:13:98
> >> > > > > ignored
> >> > > > > Nov 7 12:20:30 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> >> > > 06:44:da:01:13:98
> >> > > > > ignored
> >> > > > > Nov 7 12:20:42 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> >> > > 06:44:da:01:13:98
> >> > > > > ignored
> >> > > > > Nov 7 12:21:02 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> >> > > 06:44:da:01:13:98
> >> > > > > ignored
> >> > > > > Nov 7 12:21:19 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> >> > > 06:44:da:01:13:98
> >> > > > > ignored
> >> > > > >
> >> > > > > Any reason why the dnsmasq service ignored the request from the
> VM
> >> > and
> >> > > > how
> >> > > > > can we fix that?
> >> > > > >
> >> > > > > At the moment, the only workaround we can do is to configure the
> >> IP
> >> > > > address
> >> > > > > statically to the servelet, which is not practical.
> >> > > > >
> >> > > > > Any advice is greatly appreciated.
> >> > > > >
> >> > > > > Thank you.
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by Cloud List <cl...@sg.or.id>.
Hi Wei,
In addition,
The VR is serving a shared not isolated network, meaning the IP it serves
is 'guest' not 'public' IP. Will that make a difference on the iptables
command we need to execute?
Looking forward to your reply, thank you.
Cheers.
On Tue, Nov 8, 2016 at 3:19 AM, Cloud List <cl...@sg.or.id> wrote:
> Hi Wei and Ozhan,
>
> Thanks for your reply.
>
> The problem doesn't affect only Debian-based guest VMs, but also affected
> some Windows and Ubuntu-based VMs as well. I have executed the command on
> the VR and reset the NIC of the guest VM, but unfortunately the issue still
> persists.
>
> iptables -t mangle -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM
> --checksum-fill
>
> After issuing the above command on VR and reset the NIC on guest vm
> (ifdown eth0, ifup eth0):
>
> On VR's /var/log/dnsmasq.log:
>
> Nov 7 19:09:22 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:b1:22:01:13:17
> ignored
> Nov 7 19:09:25 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:b1:22:01:13:17
> ignored
> Nov 7 19:09:30 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:b1:22:01:13:17
> ignored
> Nov 7 19:09:36 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:b1:22:01:13:17
> ignored
>
> On the guest VM:
>
> root@vm:~# ifup eth0
> Internet Systems Consortium DHCP Client 4.2.2
> Copyright 2004-2011 Internet Systems Consortium.
> All rights reserved.
> For info, please visit https://www.isc.org/software/dhcp
>
> Listening on LPF/eth0/06:b1:22:01:13:17
> Sending on LPF/eth0/06:b1:22:01:13:17
> Sending on Socket/fallback
> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 64DHCPDISCOVER on
> eth0 to 255.255.255.255 port 67 interval 14
> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9
> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 13
> No DHCOFFERS received.
> No working leases in persistent database - sleeping.
>
> I also tried to execute similar hotfix as mentioned on the bug report:
>
> iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM
> --checksum-fill
>
> The problem still persists. Any further advice on this is highly
> appreciated.
>
> Looking forward to your reply, thank you.
>
> Cheers.
>
>
> On Tue, Nov 8, 2016 at 2:41 AM, Wei ZHOU <us...@gmail.com> wrote:
>
>> GOOD point.
>>
>> @CloudList, can you try again after executing the following command in VR
>> ?
>>
>> iptables -t mangle -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM
>> --checksum-fill
>>
>> -Wei
>>
>> 2016-11-07 14:46 GMT+01:00 Özhan Rüzgar Karaman <oruzgarkaraman@gmail.com
>> >:
>>
>> > Hi;
>> > Whats your problematic vm's type is it Debian? Maybe you are affected
>> from
>> > the bug CLOUDSTACK-8326? I do not know if this bug has effected on ACS
>> 4.2
>> > release but i know that it effects release 4.8.x 4.9.x
>> >
>> > Thanks
>> > Özhan
>> >
>> > On Mon, Nov 7, 2016 at 4:36 PM, Cloud List <cl...@sg.or.id> wrote:
>> >
>> > > Hi Wei,
>> > >
>> > > Thanks for your reply.
>> > >
>> > > I checked and I can confirm that the mac address is listed on
>> > > /etc/dhcphosts.txt in VR.
>> > >
>> > > For example:
>> > >
>> > > Nov 7 13:30:19 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
>> 06:31:ac:01:13:YY
>> > > ignored
>> > > Nov 7 13:30:24 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
>> 06:31:ac:01:13:YY
>> > > ignored
>> > > Nov 7 13:30:33 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
>> 06:31:ac:01:13:YY
>> > > ignored
>> > >
>> > > root@r-4155-VM:/var/log# grep 06:31:ac:01:13:f0 /etc/dhcphosts.txt
>> > > 06:31:ac:01:13:YY,X.X.X.X,vm-name,infinite
>> > >
>> > > YY - last two digits of the mac address
>> > > X.X.X.X - ip address which is supposed to be allocated to the VM
>> > >
>> > > Any advice how can I troubleshoot this further?
>> > >
>> > > Looking forward to your reply, thank you.
>> > >
>> > > Cheers.
>> > >
>> > >
>> > > On Mon, Nov 7, 2016 at 9:22 PM, Wei ZHOU <us...@gmail.com>
>> wrote:
>> > >
>> > > > If the mac address is not listed in /etc/dhcphosts.txt in VR, the
>> > request
>> > > > will be ignored.
>> > > >
>> > > > Can you give more details so we can reproduce it and fix it ?
>> > > >
>> > > > -Wei
>> > > >
>> > > > 2016-11-07 13:44 GMT+01:00 Cloud List <cl...@sg.or.id>:
>> > > >
>> > > > > Hi,
>> > > > >
>> > > > > After our upgrade from CloudStack 4.2 to 4.8.1.1, we noted that
>> some
>> > > (but
>> > > > > not all) of our VMs are not able to get DHCP from the VR. This
>> gives
>> > > > > problem when the VM is restarted and cannot get up and running
>> > because
>> > > > > unable to get IP.
>> > > > >
>> > > > > I logged in to the VR and found below messages showing that the
>> DHCP
>> > > > server
>> > > > > is ignoring the request from the VM.
>> > > > >
>> > > > > Nov 7 12:19:43 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
>> > > 06:44:da:01:13:98
>> > > > > ignored
>> > > > > Nov 7 12:19:52 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
>> > > 06:05:64:01:13:d3
>> > > > > ignored
>> > > > > Nov 7 12:19:53 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
>> > > 06:44:da:01:13:98
>> > > > > ignored
>> > > > > Nov 7 12:20:04 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
>> > > 06:44:da:01:13:98
>> > > > > ignored
>> > > > > Nov 7 12:20:11 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
>> > > 06:05:64:01:13:d3
>> > > > > ignored
>> > > > > Nov 7 12:20:22 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
>> > > 06:44:da:01:13:98
>> > > > > ignored
>> > > > > Nov 7 12:20:30 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
>> > > 06:44:da:01:13:98
>> > > > > ignored
>> > > > > Nov 7 12:20:42 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
>> > > 06:44:da:01:13:98
>> > > > > ignored
>> > > > > Nov 7 12:21:02 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
>> > > 06:44:da:01:13:98
>> > > > > ignored
>> > > > > Nov 7 12:21:19 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
>> > > 06:44:da:01:13:98
>> > > > > ignored
>> > > > >
>> > > > > Any reason why the dnsmasq service ignored the request from the VM
>> > and
>> > > > how
>> > > > > can we fix that?
>> > > > >
>> > > > > At the moment, the only workaround we can do is to configure the
>> IP
>> > > > address
>> > > > > statically to the servelet, which is not practical.
>> > > > >
>> > > > > Any advice is greatly appreciated.
>> > > > >
>> > > > > Thank you.
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by Cloud List <cl...@sg.or.id>.
Hi Wei and Ozhan,
Thanks for your reply.
The problem doesn't affect only Debian-based guest VMs, but also affected
some Windows and Ubuntu-based VMs as well. I have executed the command on
the VR and reset the NIC of the guest VM, but unfortunately the issue still
persists.
iptables -t mangle -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM
--checksum-fill
After issuing the above command on VR and reset the NIC on guest vm (ifdown
eth0, ifup eth0):
On VR's /var/log/dnsmasq.log:
Nov 7 19:09:22 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:b1:22:01:13:17
ignored
Nov 7 19:09:25 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:b1:22:01:13:17
ignored
Nov 7 19:09:30 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:b1:22:01:13:17
ignored
Nov 7 19:09:36 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:b1:22:01:13:17
ignored
On the guest VM:
root@vm:~# ifup eth0
Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp
Listening on LPF/eth0/06:b1:22:01:13:17
Sending on LPF/eth0/06:b1:22:01:13:17
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 64DHCPDISCOVER on
eth0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 13
No DHCOFFERS received.
No working leases in persistent database - sleeping.
I also tried to execute similar hotfix as mentioned on the bug report:
iptables -A POSTROUTING -t mangle -p udp --dport bootpc -j CHECKSUM
--checksum-fill
The problem still persists. Any further advice on this is highly
appreciated.
Looking forward to your reply, thank you.
Cheers.
On Tue, Nov 8, 2016 at 2:41 AM, Wei ZHOU <us...@gmail.com> wrote:
> GOOD point.
>
> @CloudList, can you try again after executing the following command in VR ?
>
> iptables -t mangle -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM
> --checksum-fill
>
> -Wei
>
> 2016-11-07 14:46 GMT+01:00 Özhan Rüzgar Karaman <oruzgarkaraman@gmail.com
> >:
>
> > Hi;
> > Whats your problematic vm's type is it Debian? Maybe you are affected
> from
> > the bug CLOUDSTACK-8326? I do not know if this bug has effected on ACS
> 4.2
> > release but i know that it effects release 4.8.x 4.9.x
> >
> > Thanks
> > Özhan
> >
> > On Mon, Nov 7, 2016 at 4:36 PM, Cloud List <cl...@sg.or.id> wrote:
> >
> > > Hi Wei,
> > >
> > > Thanks for your reply.
> > >
> > > I checked and I can confirm that the mac address is listed on
> > > /etc/dhcphosts.txt in VR.
> > >
> > > For example:
> > >
> > > Nov 7 13:30:19 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> 06:31:ac:01:13:YY
> > > ignored
> > > Nov 7 13:30:24 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> 06:31:ac:01:13:YY
> > > ignored
> > > Nov 7 13:30:33 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0)
> 06:31:ac:01:13:YY
> > > ignored
> > >
> > > root@r-4155-VM:/var/log# grep 06:31:ac:01:13:f0 /etc/dhcphosts.txt
> > > 06:31:ac:01:13:YY,X.X.X.X,vm-name,infinite
> > >
> > > YY - last two digits of the mac address
> > > X.X.X.X - ip address which is supposed to be allocated to the VM
> > >
> > > Any advice how can I troubleshoot this further?
> > >
> > > Looking forward to your reply, thank you.
> > >
> > > Cheers.
> > >
> > >
> > > On Mon, Nov 7, 2016 at 9:22 PM, Wei ZHOU <us...@gmail.com>
> wrote:
> > >
> > > > If the mac address is not listed in /etc/dhcphosts.txt in VR, the
> > request
> > > > will be ignored.
> > > >
> > > > Can you give more details so we can reproduce it and fix it ?
> > > >
> > > > -Wei
> > > >
> > > > 2016-11-07 13:44 GMT+01:00 Cloud List <cl...@sg.or.id>:
> > > >
> > > > > Hi,
> > > > >
> > > > > After our upgrade from CloudStack 4.2 to 4.8.1.1, we noted that
> some
> > > (but
> > > > > not all) of our VMs are not able to get DHCP from the VR. This
> gives
> > > > > problem when the VM is restarted and cannot get up and running
> > because
> > > > > unable to get IP.
> > > > >
> > > > > I logged in to the VR and found below messages showing that the
> DHCP
> > > > server
> > > > > is ignoring the request from the VM.
> > > > >
> > > > > Nov 7 12:19:43 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > 06:44:da:01:13:98
> > > > > ignored
> > > > > Nov 7 12:19:52 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > 06:05:64:01:13:d3
> > > > > ignored
> > > > > Nov 7 12:19:53 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > 06:44:da:01:13:98
> > > > > ignored
> > > > > Nov 7 12:20:04 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > 06:44:da:01:13:98
> > > > > ignored
> > > > > Nov 7 12:20:11 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > 06:05:64:01:13:d3
> > > > > ignored
> > > > > Nov 7 12:20:22 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > 06:44:da:01:13:98
> > > > > ignored
> > > > > Nov 7 12:20:30 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > 06:44:da:01:13:98
> > > > > ignored
> > > > > Nov 7 12:20:42 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > 06:44:da:01:13:98
> > > > > ignored
> > > > > Nov 7 12:21:02 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > 06:44:da:01:13:98
> > > > > ignored
> > > > > Nov 7 12:21:19 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > > 06:44:da:01:13:98
> > > > > ignored
> > > > >
> > > > > Any reason why the dnsmasq service ignored the request from the VM
> > and
> > > > how
> > > > > can we fix that?
> > > > >
> > > > > At the moment, the only workaround we can do is to configure the IP
> > > > address
> > > > > statically to the servelet, which is not practical.
> > > > >
> > > > > Any advice is greatly appreciated.
> > > > >
> > > > > Thank you.
> > > > >
> > > >
> > >
> >
>
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by Wei ZHOU <us...@gmail.com>.
GOOD point.
@CloudList, can you try again after executing the following command in VR ?
iptables -t mangle -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM
--checksum-fill
-Wei
2016-11-07 14:46 GMT+01:00 Özhan Rüzgar Karaman <or...@gmail.com>:
> Hi;
> Whats your problematic vm's type is it Debian? Maybe you are affected from
> the bug CLOUDSTACK-8326? I do not know if this bug has effected on ACS 4.2
> release but i know that it effects release 4.8.x 4.9.x
>
> Thanks
> Özhan
>
> On Mon, Nov 7, 2016 at 4:36 PM, Cloud List <cl...@sg.or.id> wrote:
>
> > Hi Wei,
> >
> > Thanks for your reply.
> >
> > I checked and I can confirm that the mac address is listed on
> > /etc/dhcphosts.txt in VR.
> >
> > For example:
> >
> > Nov 7 13:30:19 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:31:ac:01:13:YY
> > ignored
> > Nov 7 13:30:24 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:31:ac:01:13:YY
> > ignored
> > Nov 7 13:30:33 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:31:ac:01:13:YY
> > ignored
> >
> > root@r-4155-VM:/var/log# grep 06:31:ac:01:13:f0 /etc/dhcphosts.txt
> > 06:31:ac:01:13:YY,X.X.X.X,vm-name,infinite
> >
> > YY - last two digits of the mac address
> > X.X.X.X - ip address which is supposed to be allocated to the VM
> >
> > Any advice how can I troubleshoot this further?
> >
> > Looking forward to your reply, thank you.
> >
> > Cheers.
> >
> >
> > On Mon, Nov 7, 2016 at 9:22 PM, Wei ZHOU <us...@gmail.com> wrote:
> >
> > > If the mac address is not listed in /etc/dhcphosts.txt in VR, the
> request
> > > will be ignored.
> > >
> > > Can you give more details so we can reproduce it and fix it ?
> > >
> > > -Wei
> > >
> > > 2016-11-07 13:44 GMT+01:00 Cloud List <cl...@sg.or.id>:
> > >
> > > > Hi,
> > > >
> > > > After our upgrade from CloudStack 4.2 to 4.8.1.1, we noted that some
> > (but
> > > > not all) of our VMs are not able to get DHCP from the VR. This gives
> > > > problem when the VM is restarted and cannot get up and running
> because
> > > > unable to get IP.
> > > >
> > > > I logged in to the VR and found below messages showing that the DHCP
> > > server
> > > > is ignoring the request from the VM.
> > > >
> > > > Nov 7 12:19:43 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > 06:44:da:01:13:98
> > > > ignored
> > > > Nov 7 12:19:52 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > 06:05:64:01:13:d3
> > > > ignored
> > > > Nov 7 12:19:53 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > 06:44:da:01:13:98
> > > > ignored
> > > > Nov 7 12:20:04 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > 06:44:da:01:13:98
> > > > ignored
> > > > Nov 7 12:20:11 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > 06:05:64:01:13:d3
> > > > ignored
> > > > Nov 7 12:20:22 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > 06:44:da:01:13:98
> > > > ignored
> > > > Nov 7 12:20:30 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > 06:44:da:01:13:98
> > > > ignored
> > > > Nov 7 12:20:42 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > 06:44:da:01:13:98
> > > > ignored
> > > > Nov 7 12:21:02 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > 06:44:da:01:13:98
> > > > ignored
> > > > Nov 7 12:21:19 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> > 06:44:da:01:13:98
> > > > ignored
> > > >
> > > > Any reason why the dnsmasq service ignored the request from the VM
> and
> > > how
> > > > can we fix that?
> > > >
> > > > At the moment, the only workaround we can do is to configure the IP
> > > address
> > > > statically to the servelet, which is not practical.
> > > >
> > > > Any advice is greatly appreciated.
> > > >
> > > > Thank you.
> > > >
> > >
> >
>
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by Özhan Rüzgar Karaman <or...@gmail.com>.
Hi;
Whats your problematic vm's type is it Debian? Maybe you are affected from
the bug CLOUDSTACK-8326? I do not know if this bug has effected on ACS 4.2
release but i know that it effects release 4.8.x 4.9.x
Thanks
Özhan
On Mon, Nov 7, 2016 at 4:36 PM, Cloud List <cl...@sg.or.id> wrote:
> Hi Wei,
>
> Thanks for your reply.
>
> I checked and I can confirm that the mac address is listed on
> /etc/dhcphosts.txt in VR.
>
> For example:
>
> Nov 7 13:30:19 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:31:ac:01:13:YY
> ignored
> Nov 7 13:30:24 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:31:ac:01:13:YY
> ignored
> Nov 7 13:30:33 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:31:ac:01:13:YY
> ignored
>
> root@r-4155-VM:/var/log# grep 06:31:ac:01:13:f0 /etc/dhcphosts.txt
> 06:31:ac:01:13:YY,X.X.X.X,vm-name,infinite
>
> YY - last two digits of the mac address
> X.X.X.X - ip address which is supposed to be allocated to the VM
>
> Any advice how can I troubleshoot this further?
>
> Looking forward to your reply, thank you.
>
> Cheers.
>
>
> On Mon, Nov 7, 2016 at 9:22 PM, Wei ZHOU <us...@gmail.com> wrote:
>
> > If the mac address is not listed in /etc/dhcphosts.txt in VR, the request
> > will be ignored.
> >
> > Can you give more details so we can reproduce it and fix it ?
> >
> > -Wei
> >
> > 2016-11-07 13:44 GMT+01:00 Cloud List <cl...@sg.or.id>:
> >
> > > Hi,
> > >
> > > After our upgrade from CloudStack 4.2 to 4.8.1.1, we noted that some
> (but
> > > not all) of our VMs are not able to get DHCP from the VR. This gives
> > > problem when the VM is restarted and cannot get up and running because
> > > unable to get IP.
> > >
> > > I logged in to the VR and found below messages showing that the DHCP
> > server
> > > is ignoring the request from the VM.
> > >
> > > Nov 7 12:19:43 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> 06:44:da:01:13:98
> > > ignored
> > > Nov 7 12:19:52 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> 06:05:64:01:13:d3
> > > ignored
> > > Nov 7 12:19:53 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> 06:44:da:01:13:98
> > > ignored
> > > Nov 7 12:20:04 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> 06:44:da:01:13:98
> > > ignored
> > > Nov 7 12:20:11 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> 06:05:64:01:13:d3
> > > ignored
> > > Nov 7 12:20:22 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> 06:44:da:01:13:98
> > > ignored
> > > Nov 7 12:20:30 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> 06:44:da:01:13:98
> > > ignored
> > > Nov 7 12:20:42 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> 06:44:da:01:13:98
> > > ignored
> > > Nov 7 12:21:02 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> 06:44:da:01:13:98
> > > ignored
> > > Nov 7 12:21:19 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0)
> 06:44:da:01:13:98
> > > ignored
> > >
> > > Any reason why the dnsmasq service ignored the request from the VM and
> > how
> > > can we fix that?
> > >
> > > At the moment, the only workaround we can do is to configure the IP
> > address
> > > statically to the servelet, which is not practical.
> > >
> > > Any advice is greatly appreciated.
> > >
> > > Thank you.
> > >
> >
>
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by Cloud List <cl...@sg.or.id>.
Hi Wei,
Thanks for your reply.
I checked and I can confirm that the mac address is listed on
/etc/dhcphosts.txt in VR.
For example:
Nov 7 13:30:19 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:31:ac:01:13:YY
ignored
Nov 7 13:30:24 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:31:ac:01:13:YY
ignored
Nov 7 13:30:33 dnsmasq-dhcp[18986]: DHCPDISCOVER(eth0) 06:31:ac:01:13:YY
ignored
root@r-4155-VM:/var/log# grep 06:31:ac:01:13:f0 /etc/dhcphosts.txt
06:31:ac:01:13:YY,X.X.X.X,vm-name,infinite
YY - last two digits of the mac address
X.X.X.X - ip address which is supposed to be allocated to the VM
Any advice how can I troubleshoot this further?
Looking forward to your reply, thank you.
Cheers.
On Mon, Nov 7, 2016 at 9:22 PM, Wei ZHOU <us...@gmail.com> wrote:
> If the mac address is not listed in /etc/dhcphosts.txt in VR, the request
> will be ignored.
>
> Can you give more details so we can reproduce it and fix it ?
>
> -Wei
>
> 2016-11-07 13:44 GMT+01:00 Cloud List <cl...@sg.or.id>:
>
> > Hi,
> >
> > After our upgrade from CloudStack 4.2 to 4.8.1.1, we noted that some (but
> > not all) of our VMs are not able to get DHCP from the VR. This gives
> > problem when the VM is restarted and cannot get up and running because
> > unable to get IP.
> >
> > I logged in to the VR and found below messages showing that the DHCP
> server
> > is ignoring the request from the VM.
> >
> > Nov 7 12:19:43 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
> > ignored
> > Nov 7 12:19:52 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:05:64:01:13:d3
> > ignored
> > Nov 7 12:19:53 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
> > ignored
> > Nov 7 12:20:04 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
> > ignored
> > Nov 7 12:20:11 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:05:64:01:13:d3
> > ignored
> > Nov 7 12:20:22 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
> > ignored
> > Nov 7 12:20:30 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
> > ignored
> > Nov 7 12:20:42 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
> > ignored
> > Nov 7 12:21:02 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
> > ignored
> > Nov 7 12:21:19 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
> > ignored
> >
> > Any reason why the dnsmasq service ignored the request from the VM and
> how
> > can we fix that?
> >
> > At the moment, the only workaround we can do is to configure the IP
> address
> > statically to the servelet, which is not practical.
> >
> > Any advice is greatly appreciated.
> >
> > Thank you.
> >
>
Re: ACS - Some VMs unable to get DHCP IP from VR
Posted by Wei ZHOU <us...@gmail.com>.
If the mac address is not listed in /etc/dhcphosts.txt in VR, the request
will be ignored.
Can you give more details so we can reproduce it and fix it ?
-Wei
2016-11-07 13:44 GMT+01:00 Cloud List <cl...@sg.or.id>:
> Hi,
>
> After our upgrade from CloudStack 4.2 to 4.8.1.1, we noted that some (but
> not all) of our VMs are not able to get DHCP from the VR. This gives
> problem when the VM is restarted and cannot get up and running because
> unable to get IP.
>
> I logged in to the VR and found below messages showing that the DHCP server
> is ignoring the request from the VM.
>
> Nov 7 12:19:43 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
> ignored
> Nov 7 12:19:52 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:05:64:01:13:d3
> ignored
> Nov 7 12:19:53 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
> ignored
> Nov 7 12:20:04 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
> ignored
> Nov 7 12:20:11 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:05:64:01:13:d3
> ignored
> Nov 7 12:20:22 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
> ignored
> Nov 7 12:20:30 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
> ignored
> Nov 7 12:20:42 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
> ignored
> Nov 7 12:21:02 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
> ignored
> Nov 7 12:21:19 dnsmasq-dhcp[29938]: DHCPDISCOVER(eth0) 06:44:da:01:13:98
> ignored
>
> Any reason why the dnsmasq service ignored the request from the VM and how
> can we fix that?
>
> At the moment, the only workaround we can do is to configure the IP address
> statically to the servelet, which is not practical.
>
> Any advice is greatly appreciated.
>
> Thank you.
>