Re: ACS - Some VMs unable to get DHCP IP from VR
You are welcome! Good to know it. -Wei 2016-11-10 21:01 GMT+01:00 Cloud List: > 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 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 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 : > >> > >> > 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
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 Listwrote: > 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 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 : >> >> > 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
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 ZHOUwrote: > 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 : > > > 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
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: > 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
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 ZHOUwrote: > 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 : > > > 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
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: > 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
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 ZHOUwrote: > 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 : > > > 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 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 : > > > > > > > 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
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: > 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 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 : > > > > > 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
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 ZHOUwrote: > 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 : > > > 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
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: > 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
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: > 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 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 : > > > > > 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
Re: ACS - Some VMs unable to get DHCP IP from VR
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 ZHOUwrote: > 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 : > > > 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 wrote: > > > > > can you paste the result of following command? >
Re: ACS - Some VMs unable to get DHCP IP from VR
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: > 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 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 : > > > > > 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 > 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
Re: ACS - Some VMs unable to get DHCP IP from VR
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 ZHOUwrote: > >> 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 : >> >>> 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 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
Re: ACS - Some VMs unable to get DHCP IP from VR
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: > 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 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 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 < > oruzgarkara...@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 > 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 > >> 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 : > >> > > > > >> > > > > Hi, > >> > > > > > >> > > > > After our upgrade from CloudStack 4.2 to 4.8.1.1, we noted that > >> some > >> > > (but > >> > > > > not all) of our VMs
Re: ACS - Some VMs unable to get DHCP IP from VR
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 Listwrote: > 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 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 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 < > oruzgarkara...@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 > 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 > >> 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 ? > >> >
Re: ACS - Some VMs unable to get DHCP IP from VR
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 Listwrote: > 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 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 > >: >> >> > 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 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 >> 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 : >> > > > >> > > > > 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
Re: ACS - Some VMs unable to get DHCP IP from VR
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 ZHOUwrote: > 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 >: > > > 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 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 > 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 : > > > > > > > > > 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 > > > > >
Re: ACS - Some VMs unable to get DHCP IP from VR
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: > 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 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 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 : > > > > > > > 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
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 Listwrote: > 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 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 : > > > > > 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
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 ZHOUwrote: > 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 : > > > 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
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: > 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. >
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.