Answer by slogan-r for 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

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 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?