As part of a project that I’m involved in at work, I needed to create a reproducible OpenStack Juno environment that I could beat my head against.

I decided to forgo using the pre-packaged solutions that are readily available because I knew I was going to be knee deep in neutron and I wanted to fully envelope myself in its setup and configuration. The masochist in me would be proud.

I followed the documentation available here which was, to my great surprise, almost entirely accurate. It’s not often that one finds high quality documentation in an open source project.

During my testing and use of the end result though, I kept repeatedly running into a traceback error on the compute node. It looked like this

ERROR nova.compute.manager [...] Instance failed to spawn
TRACE nova.compute.manager [...] Traceback (most recent call last):
TRACE nova.compute.manager [...]   File "/usr/lib/python2.7/dist-packages/nova/compute/", line 2267, in _build_resources
TRACE nova.compute.manager [...]     yield resources
TRACE nova.compute.manager [...]   File "/usr/lib/python2.7/dist-packages/nova/compute/", line 2137, in _build_and_run_instance
TRACE nova.compute.manager [...]     block_device_info=block_device_info)
TRACE nova.compute.manager [...]   File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/", line 2620, in spawn
TRACE nova.compute.manager [...]     write_to_disk=True)
TRACE nova.compute.manager [...]   File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/", line 4159, in _get_guest_xml
TRACE nova.compute.manager [...]     context)
TRACE nova.compute.manager [...]   File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/", line 3937, in _get_guest_config
TRACE nova.compute.manager [...]     flavor, CONF.libvirt.virt_type)
TRACE nova.compute.manager [...]   File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/", line 352, in get_config
TRACE nova.compute.manager [...]     _("Unexpected vif_type=%s") % vif_type)
TRACE nova.compute.manager [...] NovaException: Unexpected vif_type=binding_failed
TRACE nova.compute.manager [...]

It’s not often that I am the first person to encounter an error, so I googled the above error in the hopes that it would enlighten me to the problem. tl;dr, it didn’t.

Based on the problem I was receiving versus the accepted solutions available on the net, it seems that this is a rather general error that can indicate a problem “somewhere” in neutron.

The solution for me was actually a user error. In horizon I was logging in as the admin user and trying to boot an image using the ext-net network. That’s not going to work though because there is no DHCP service running on the external net.

Instead I should have been using the demo-net network. In the horizon UI though this network was not visible to me because it had been created by the demo user for the demo tenant.

The easy solution is to create the demo-net network with the shared bit set.

Unfortunately, for the demo user, this cannot be done because regular users, per neutron default policy, can’t do such a thing.

The work-around, for me, was to create the network as the admin user, make it shared, and by virtue of it being shared, it would be visible by the demo user.

The lesson here is if you find yourself faced with the above error, make sure you’re actually using the software correctly. It wasn’t clear that this was a DHCP related error, but in hindsight, it should have been obvious.