[openstack-dev] Quantum (Grizzly) setup on Fedora18 - VM doesnot receive an IP address

Gopi Krishna B gopi97468 at gmail.com
Wed Jul 10 07:21:32 UTC 2013


We are unable to get an IP address when a VM gets launched and the below
DHCP error is observed in the Dashboard logs

The setup in done on Fedora 18 using Openstack Grizzly. Its a 2 node setup,
with Network+ Controller node having 3 NIC's, and Compute node having 2
NIC's. Tried configuring networking in vlan mode.

em1 - mgmt network,
em2 - external/public network (br-ex is created on top of this iface)
eth1 - internal/data network (br-eth1 is created on top of this iface)
****************** *****************************
plugin.ini
-------------
enable_tunneling = False
tenant_network_type = vlan
network_vlan_ranges = eth1:100:1000
integration_bridge = br-int
bridge_mappings = eth1:br-eth1,em2:br-ex
****************** *****************************

The console log from the dashboards is as below.

Initializing random number generator... done.

Starting network...

udhcpc (v1.18.5) started

Sending discover...

Sending select for 192.168.120.2...

Sending select for 192.168.120.2...

Sending select for 192.168.120.2...

No lease, failing

WARN: /etc/rc3.d/S40network failed

cirrosds 'net' up at 182.11

checking http://169.254.169.254/20090404/instanceid

failed 1/20: up 182.13. request failed

failed 2/20: up 184.34. request failed

failed 3/20: up 186.36. request failed


Could anyone help us in resolving this issue, we have tried following
different links and options available on internet, but couldnot resolve
this error. Let us know if further information is required to identify the
root cause.

Some more info, and if someone could possibly identify the root cause then
it would be of great help to me.

from the tcpdump output , I could track the DHCP discover packet at the
tapXXX , qbrXXX , qvbXXX, qvoXX, int-br-eth0, phy-br-eth0 interface, but
not after that

As per my understanding the flow of packets should be from tapXX -> qbrXX
-> qvbXX -> qvoXX --> br-int -> int-br-eth0 -> phy-br-eth0 -> br-eth0 ->
eth0

So in this case is there a missing security group rules, which possibly
drop the packet.
I am not familiar with the iptables rules, so if I need to add any rules
could you please help me in adding the rule.
-- 
Regards
Gopi Krishna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130710/313c59c6/attachment.html>


More information about the OpenStack-dev mailing list