Ask Your Question
2

How to configure the DHCP server so that it can assign IP to VMs?

asked 2013-05-09 00:54:43 -0500

sandeepnimbalkar gravatar image

updated 2013-08-22 19:45:08 -0500

fifieldt gravatar image

We have a Open Stack setup at our local environment. We used this link for the setup

We are able to successfully create the VM's but the VM's are not getting the IP. When I checked the logs, I saw that the VM is trying to contact the DHCP server for the IP but not able to retrieve or even ping the DHCP server.

Do I missed any configuration regarding the DHCP? I found documentation saying which has configuration related to DHCP. Did I miss these steps as github link does have them?

Also, I am not sure while booting, VM is trying to contact 169.254.169.254. What If my networkis not on the internet. Does it cause failure?

Please do suggest me the DHCP configuration as I want my VM to have atleast an IP associated with it. When I try to assign the IP manually, it is not able to ping either my controller nor my network.

Please find below Logs while booting VM.

info: initramfs: up at 0.62
NOCHANGE: partition 1 is size 41913585. it cannot be grown
info: initramfs loading root from /dev/vda1
info: /etc/init.d/rc.sysinit: up at 0.88
[    0.886119] EXT3-fs (vda1): warning: checktime reached, running e2fsck is recommended
Starting logging: OK
Initializing random number generator... done.
Starting network...
udhcpc (v1.18.5) started
Sending discover...
Sending discover...
Sending discover...
No lease, failing
WARN: /etc/rc3.d/S40-network failed
cloud-setup: checking http://169.254.169.254/2009-04-04/meta-data/instance-id
wget: can't connect to remote host (169.254.169.254): Network is unreachable
cloud-setup: failed 1/30: up 10.14. request failed
wget: can't connect to remote host (169.254.169.254): Network is unreachable
cloud-setup: failed 2/30: up 11.15. request failed
wget: can't connect to remote host (169.254.169.254): Network is unreachable
cloud-setup: failed 3/30: up 12.15. request failed
wget: can't connect to remote host (169.254.169.254): Network is unreachable
cloud-setup: failed 4/30: up 13.15. request failed
wget: can't connect to remote host (169.254.169.254): Network is unreachable
cloud-setup: failed 5/30: up 14.16. request failed
wget: can't connect to remote host (169.254.169.254): Network is unreachable
cloud-setup: failed 6/30: up 15.16. request failed
wget: can't connect to remote host (169.254.169.254): Network is unreachable
cloud-setup: failed 7/30: up 16.17. request failed
wget: can't connect to remote host (169.254.169.254): Network is unreachable
cloud-setup: failed 8/30: up 17.17. request failed
wget: can't connect to remote host (169.254.169.254): Network is unreachable
cloud-setup: failed 9/30: up 18.18. request failed
wget: can't connect to remote host (169.254.169.254): Network is unreachable
cloud-setup: failed 10/30: up 19.18. request failed
wget: can't connect to remote host (169.254.169.254): Network is unreachable
cloud-setup: failed ...
(more)
edit retag flag offensive close merge delete

Comments

1

can you post your quantum DHCP logs?

Ashokb gravatar imageAshokb ( 2013-05-10 16:37:12 -0500 )edit

4 answers

Sort by ยป oldest newest most voted
1

answered 2013-05-13 07:41:48 -0500

sandeepnimbalkar gravatar image

updated 2013-05-13 07:42:50 -0500

Hi Robert,

Thanks for the reply.

I checked all the things which you mentioned in your reply.

  1. First thing is to check if traffic is actually possible between the virtual and DHCP server: Add the IP manually to the virtual machine and try to ping the dhcp-agent. Ans : Added the IP to VM manually, but not able to ping the dhcp-agent.

  2. "ovs-vsctl show" and "ovs-ofctl dump-flows <switchname>" should give some useful output

Ans : ovs-vsctl show 67f47c39-65b2-4432-a66d-2dac811d2c1c Bridge "br-eth1" Port "eth1" Interface "eth1" Port "br-eth1" Interface "br-eth1" type: internal Bridge br-ex Port br-ex Interface br-ex type: internal Port "qg-08510cc8-b4" Interface "qg-08510cc8-b4" type: internal Port "eth2" Interface "eth2" Bridge br-int Port "qr-7bc0431e-3c" Interface "qr-7bc0431e-3c" type: internal Port br-int Interface br-int type: internal Port "int-br-eth1" Interface "int-br-eth1" ovs_version: "1.4.3"


ovs-ofctl dump-flows br-ex NXST_FLOW reply (xid=0x4):

cookie=0x0, duration=8128.959s, table=0, npackets=8681, nbytes=521494, priority=0 actions=NORMAL

  1. tcpdump

Ans : tcpdump -i eth2 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth2, link-type EN10MB (Ethernet), capture size 65535 bytes 08:27:12.286578 ARP, Request who-has 192.168.100.1 tell 192.168.100.60, length 46 08:27:12.311778 ARP, Request who-has 192.168.100.1 tell 192.168.100.51, length 46 08:27:12.479770 ARP, Request who-has 192.168.100.1 tell 192.168.100.52, length 28 08:27:13.348591 STP 802.1w, Rapid STP, Flags [Learn, Forward, Agreement], bridge-id 8000.00:0f:cb:a1:27:4c.8002, length 43 08:27:15.288362 ARP, Request who-has 192.168.100.1 tell 192.168.100.60, length 46 08:27:15.319549 ARP, Request who-has 192.168.100.1 tell 192.168.100.51, length 46 08:27:15.348683 STP 802.1w, Rapid STP, Flags [Learn, Forward, Agreement], bridge-id 8000.00:0f:cb:a1:27:4c.8002, length 43 08:27:15.484937 ARP, Request who-has 192.168.100.1 tell 192.168.100.52, length 28 08:27:16.286606 ARP, Request who-has 192.168.100.1 tell 192.168.100.60, length 46 08:27:16.315762 ARP, Request who-has 192.168.100.1 tell 192.168.100.51, length 46 08:27:16.483772 ARP, Request who-has 192.168.100.1 tell 192.168.100.52, length 28 08:27:17.286618 ARP, Request who-has 192.168.100.1 tell 192.168.100.60, length 46 08:27:17.315761 ARP, Request who-has 192.168.100.1 tell 192.168.100.51, length 46 08:27:17.348669 STP 802.1w, Rapid STP, Flags [Learn, Forward, Agreement], bridge-id 8000.00:0f:cb:a1:27:4c.8002, length 43 08:27:17.483766 ARP, Request who-has 192.168.100.1 tell 192.168.100.52, length 28 08:27:19.348810 STP 802.1w, Rapid STP, Flags [Learn, Forward, Agreement], bridge-id 8000.00:0f:cb:a1:27:4c.8002, length 43 08:27:20.313255 ARP, Request who-has 192.168 ...

(more)
edit flag offensive delete link more
0

answered 2013-05-09 17:54:58 -0500

aso726 gravatar image

the 169.254.169.254 is for the metadata service. that IP is proxy'd to the nova-api service running on port 8775 to grab metadata for cloud-userdata to set up post-install scripts. Don't worry about that yet when setting up dhcp. Are you using quantum or nova-network?

edit flag offensive delete link more
0

answered 2013-05-10 07:46:55 -0500

Robert van Leeuwen gravatar image

First thing is to check if traffic is actually possible between the virtual and DHCP server: Add the IP manually to the virtual machine and try to ping the dhcp-agent.

If this does not work first check if the switch allows vlan tagging. Second you could double-check the openvswitch config:

"ovs-vsctl show" and "ovs-ofctl dump-flows <switchname>" should give some useful output

If traffic is allowed between the virtual and DHCP agent you should probably check the dhcp log and use tcpdump to see if the requests/offers are actually sent.

edit flag offensive delete link more
0

answered 2013-10-15 09:21:10 -0500

I have faced the same question, and I just found that a new inter network will be binded with the host that a VM on it first use that network.

edit flag offensive delete link more

Comments

please can you explain more, I am having the same problem with Neutron on Newton Ubuntu 16.04

lost007 gravatar imagelost007 ( 2017-05-24 02:36:17 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2013-05-09 00:54:43 -0500

Seen: 4,949 times

Last updated: Oct 15 '13