[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Rdo-list] Fedora 20 / Devstack Networking Issues

Ok, I've been chasing down some networking issues along with some other
folks.  Here's what I'm seeing:

Starting with a vanilla F20 cloud image running on a F20 host, clone
devstack into it and run stack.sh.

First thing is that the RabbitMQ server issue I noted a few weeks ago is
still intermittently there.  So during the step where rabbitmqctl is run
to set the password of the rabbit admin user, it might fail and all
subsequent AMQP communication fails which makes a lot of the nova
commands in devstack also fail.

But... if you get past this error (since it is intermittent), then
devstack seems to complete successfully.  Standard commands like nova
list, keystone user-list, etc all work fine.

I did note though that access to Horizon does not work.  I need to
investigate this further.

But worse than that is when you run nova boot, the host to guest
networking (remember this is devstack running in a VM) immediately gets
disconnected.  This issue is 100% reproducible and multiple users are
reporting it (tsedovic, eharney, bnemec cc'd)

I did some investigation when this happens and here's what I found...

If I do:

$ brctl delif br100 eth0

I was immediately able to ping the guest from the host and vice versa.

If I reattach eth0 back to br100, networking stops again

Another thing... I notice that on the system br100 does not have an ip
address, but eth0 does.  I thought when doing bridged networking like
this, the bridge should have the ip address and the physical iface that
is attached to the bridge does not get an ip addr.

So... I tweaked /etc/sysconfig/network-scripts/ifcfg-eth0 to remove the
dhcp from the bootproto line and I copied ifcfg-eth0 to ifcfg-br100
allowing it to use bootproto dhcp

I brought both ifaces down and then brought them both up.  eth0 first
and br100 second

This time, br100 got the dhcp address from the host and networking
worked fine.

So is this just an issue with how nova is setting up bridges?

Since this network disconnect didn't happen until nova launched a vm, I
imagine this isn't a problem with devstack itself, but is likely an
issue with Nova Networking somehow.

Russell/DanS, is there any chance that all of the refactoring you did in
Nova Networking very recently introduce a regression?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]