Ask Your Question
0

Quantum with Openvswitch and stack.sh no gateway interface

asked 2012-08-23 13:52:17 -0600

eoghank gravatar image

I am trying to run an all-in-one using stack.sh with the latest (folsom3 and master) branches of Quantum on KVM but the gateway interface does not get created and as a result VM's do not get an IP. I've updated the install to include the steps mentioned here http://wiki.openstack.org/RunningQuantumV2Api (http://wiki.openstack.org/RunningQuan...) and here http://wiki.openstack.org/QuantumDevstack (http://wiki.openstack.org/QuantumDevs...) but never get a gateway interface after creating a network and subnet and spinning up a VM.

This is what ovs-vsctl displays (after creating a network and subnet and spinning up a VM: stack@esg-dell-c4-s11:~/devstack$ sudo ovs-vsctl show 5dab4e1c-89c4-421e-a737-03b338eddc1a Bridge br-int Port patch-tun Interface patch-tun type: patch options: {peer=patch-int} Port "tap73f2ee73-79" tag: 1 Interface "tap73f2ee73-79" type: internal Port "tapd425d955-15" tag: 2 Interface "tapd425d955-15" type: internal Port br-int Interface br-int type: internal Port "tapc46b72b3-b3" tag: 2 Interface "tapc46b72b3-b3" Bridge br-tun Port patch-int Interface patch-int type: patch options: {peer=patch-tun} Port br-tun Interface br-tun type: internal ovs_version: "1.4.0+build0"

Are there any additional steps that need to be run to make this work with the V2 Quantum API?

Eoghan

edit retag flag offensive close merge delete

30 answers

Sort by ยป oldest newest most voted
0

answered 2012-08-30 23:10:24 -0600

Eoghan,

Thanks! I just got a 4 node blade up with quantum V2, crossing two separate VLANs managed by an intervening switch, VMs are getting IP addresses. The above hints for dealing with namespaces were the remaining issue for me. So thanks for posting, it was a big help.

edit flag offensive delete link more
0

answered 2012-08-30 15:03:35 -0600

eoghank gravatar image

Syd:

To your question on namespaces, quantum creates a separate namespace for each subnet created. You can view the namespaces with "ip netns list" and the namespace id's match those of the quantum subnets.

$ quantum subnet-list +--------------------------------------------+-------------+-----------------+-------------+------------+-------------+--------------------------------------+------------+------+--------------------------------------+----------------------------------+ | allocation_pools | cidr | dns_nameservers | enable_dhcp | gateway_ip | host_routes | id | ip_version | name | network_id | tenant_id | +--------------------------------------------+-------------+-----------------+-------------+------------+-------------+--------------------------------------+------------+------+--------------------------------------+----------------------------------+ | {"start": "10.0.0.2", "end": "10.0.0.254"} | 10.0.0.0/24 | [] | True | 10.0.0.1 | [] | 8582c300-c86c-42d8-9fe2-8e6680815486 | 4 | | cb731bd2-ea13-4537-90a7-65efe6312c00 | 65b7bd9ca5ff4a20874d589cbe9c97b0 | +--------------------------------------------+-------------+-----------------+-------------+------------+-------------+--------------------------------------+------------+------+--------------------------------------+----------------------------------+ $ ip netns list cb731bd2-ea13-4537-90a7-65efe6312c00

To change network namespaces and be able to ping the VM's run this and you are placed in the subnet's namespace:

$ ip netns exec cb731bd2-ea13-4537-90a7-65efe6312c00 bash

Eoghan

edit flag offensive delete link more
0

answered 2012-08-30 00:46:06 -0600

See the referenced bug report. ENABLED_SERVICES is one I copied from an earlier post you made on this thread, and from the devstack logs (attached to the bug), it sure looks like it is trying to start it.

  • screen -S stack -p q-agt -X stuff 'sudo python /opt/stack/quantum/quantum/plugins/openvswitch/agent/ovs_quantum_agent.py --config-file /etc/quantum/quantum.conf --config-file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini^M'
  • screen_it q-dhcp 'sudo python /opt/stack/quantum/bin/quantum-dhcp-agent --config-file /etc/quantum/quantum.conf --config-file=/etc/quantum/dhcp_agent.ini' ++ echo -ne '\015'
  • NL=$'\r'
  • is_service_enabled q-dhcp
  • services=q-dhcp
  • for service in '${services}'
  • [[ ,g-api,g-reg,key,n-api,n-cpu,n-sch,n-vnc,mysql,rabbit,openstackx,q-svc,quantum,q-agt,n-cpu,q-dhcp, =~ ,q-dhcp, ]]
  • return 0
  • screen_rc q-dhcp 'sudo python /opt/stack/quantum/bin/quantum-dhcp-agent --config-file /etc/quantum/quantum.conf --config-file=/etc/quantum/dhcp_agent.ini'
  • SCREENRC=/opt/stack/devstack/stack-screenrc
  • [[ ! -e /opt/stack/devstack/stack-screenrc ]]
  • grep q-dhcp /opt/stack/devstack/stack-screenrc
  • screen -S stack -X screen -t q-dhcp
  • sleep 1.5
  • [[ -n '' ]]
  • screen -S stack -p q-dhcp -X stuff 'sudo python /opt/stack/quantum/bin/quantum-dhcp-agent --config-file /etc/quantum/quantum.conf --config-file=/etc/quantum/dhcp_agent.ini^M'
  • NOVA_CONF_DIR=/etc/nova
  • [[ ! -d /etc/nova ]] ++ whoami
edit flag offensive delete link more
0

answered 2012-08-30 00:40:47 -0600

Just to confirm did you have q-dhcp in ENABLED_SERVICES? If so I'm not sure why stack.sh isn't starting it for you. Is there an error?

screen_it q-dhcp "sudo python $AGENT_DHCP_BINARY --config-file $Q_CONF_FILE --config-file=$Q_DHCP_CONF_FILE"

edit flag offensive delete link more
0

answered 2012-08-30 00:29:05 -0600

Well, a clean install of ubuntu 12.04 and still running into the same issue -- O need to launch the quantum-dhcp-agent by hand. Then things work. Boo.

I think I'll file a bug on this, my setup is too generic and my localrc is correct based on our discussions.

edit flag offensive delete link more
0

answered 2012-08-29 22:45:26 -0600

I agree that your issue was because you were using an older version of devstack. That's explains why the dhcp agent was starting with one config file instead of two.

This page seems up to date to me: http://wiki.openstack.org/QuantumDevs... (and shows localrc) . I agree it can definitely be challenging getting everything working together when you are running on master :)

Aaron

edit flag offensive delete link more
0

answered 2012-08-29 22:29:38 -0600

Aaron:

I'm suspecting that I was on the fence between a setup that was old-devstack and new, which is why I am going thru this blade reimaging exercise.

Totally encourage you to post a localrc somewhere prominent. Would buying you a beer at the openstack summit help to encourage you more? :-)

edit flag offensive delete link more
0

answered 2012-08-29 22:22:43 -0600

Hi Syd,

I agree documentation can definitely be improved. I did not need to make any changes in order to get this working. I suspect that your devstack had fallen out of date and some how during your process you updated it (that's why things started working :) )

Those errors you are seeing in the vm is because the vm is configured to run that cloud-setup command. This is exactly what I get to. :)

Things seem to be working from what you posted.

Aaron

edit flag offensive delete link more
0

answered 2012-08-29 22:08:41 -0600

Eoghan:

Glad to hear it. My dnsmasq process is slightly different, it has one additional arg (--dhcp-script)

root 5524 5523 0 14:49 ? 00:00:00 dnsmasq --no-hosts --no-resolv --strict-order --bind-interfaces --interface=tap0af8ef80-41 --except-interface=lo --domain=openstacklocal --pid-file=/opt/stack/data/dhcp/3416e686-fc5e-4efc-b204-9f92f88e9d9c/pid --dhcp-hostsfile=/opt/stack/data/dhcp/3416e686-fc5e-4efc-b204-9f92f88e9d9c/host --dhcp-optsfile=/opt/stack/data/dhcp/3416e686-fc5e-4efc-b204-9f92f88e9d9c/opts --dhcp-script=/opt/stack/quantum/bin/quantum-dhcp-agent-dnsmasq-lease-update --leasefile-ro --dhcp-range=set:tag0,10.4.128.0,static,120s

Can you detail more about what you did with namespaces? Not familiar with that.

Aaron:

I'm going to scp my localrc to a safe place, reimage my blade with a fresh copy of Ubuntu 12.04, and see if I can reproduce this issue with quantum-dhcp-agent not starting. Give me a couple of hours to report back... :-)

I think it would be awesome to the community to publish a wiki page with a mostly copy-pasteable localrc for using devstack with quantum v2 and OVS. If one looks hard enough, it can be pieced together from various posts and such, but that can be error prone and tedious (as you have seen from my recent questions, I have never been sure about keystone, the need to specify v2 flag, what exactly I should use for enabled services...). Let me know if I can help with this if you agree it is worthwhile (and I hope you do :-).

edit flag offensive delete link more
0

answered 2012-08-29 21:55:52 -0600

So, I killed the dhcp agent execution where I specified only the one --config-file arg, tried again with both args. This time, it persisted (didn't exit), and I got a bunch of dnsmasq processes as well.

Created a new net, created a subnet for 10.4.128.0/20, and then spun up a VM. And the console logs reflected that in fact it was due to dhcp agent not running:

Starting network... udhcpc (v1.18.5) started Sending discover... Sending select for 10.4.128.3... Lease of 10.4.128.3 obtained, lease time 120 deleting routers route: SIOCDELRT: No such process adding dns 10.4.128.2 cloud-setup: checking http://169.254.169.254/2009-04-04/meta-data/instance-id (http://169.254.169.254/2009-04-04/met...) wget: can't connect to remote host (169.254.169.254): No route to host cloud-setup: failed 1/30: up 7.50. request failed wget: can't connect to remote host (169.254.169.254): No route to host cloud-setup: failed 2/30: up 11.59. request failed wget: can't connect to remote host (169.254.169.254): No route to host cloud-setup: failed 3/30: up 14.59. request failed wget: can't connect to remote host (169.254.169.254): No route to host cloud-setup: failed 4/30: up 18.65. request failed wget: can't connect to remote host (169.254.169.254): No route to host cloud-setup: failed 5/30: up 22.71. request failed wget: can't connect to remote host (169.254.169.254): No route to host cloud-setup: failed 6/30: up 26.78. request failed

This attempt to hit up a web server at 169.254.169.254 is very weird, something I don't recall seeing previously when working with essex quantum v1/OVS.

Even weirder, now that I rebooted the host and re-ran devstack, quantum-dhcp-agent runs. And my VMs get IP addresses in the specified subnet. WTF? Did running the agent once with only one argument have some kind of side effect?

edit flag offensive delete link more

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: 2012-08-23 13:52:17 -0600

Seen: 13,724 times

Last updated: Aug 30 '12