[openstack-dev] [quantum] RFC: quantum baremetal config/work to do

Robert Collins robertc at robertcollins.net
Sun Jan 6 19:42:21 UTC 2013

Hey, so I've been poking at quantum with the baremetal hypervisor on
classic l2 switches - no openflow.

Here is what I think needs to be done to make it all work, and what I
think 'it' is :)

So the goal is to have a regular L2 network, with quantum + baremetal
nova managing dhcp on it.

Ignoring quantum for the moment, what needs to happen is that:
 - machines attempt PXE booting using their own MAC address
 - if the machine is not known to nova, something sensible (e.g.
allocate from a pool, or log and ditch, or allocate a number and do
hardware discovery)
 - if the machine is known to nova, boot it providing appropriate
bootfile-name, server-ip-address and tftp-server options.
 - nova's baremetal hypervisor then handles tftp and the rest of the
boot process.

What I have so far is this:
 - quantum with the ovs plugin
 - with a provider network configured (e.g.

and a network and subnet made with that:
$ quantum net-create ctlplane --tenant-id $tenantuuid
--provider:network_type flat --provider:physical_network ctlplane

$ subnet-create --ip-version 4 --allocation-pool
start=,end= --gateway= $netuuid

Will answer DHCP for DHCP requests coming from the physical L2 network
if the MAC has been registered as a port.

My plan for unknown machines for now is to ignore them (can just have
a deliberately slow DHCP server running on the same network, as a
stopgap), but long term would like to teach quantum a fallback
configuration for unknown requests. [which might be to proxy-DHCP the

For machines known to nova, there can be many baremetal hypervisor
machines. One (and only one) will have the right files to PXE boot the
machine that is starting up. [same as for virtualised instances, there
is one owning hypervisor, at least for now]. So we need to set
server-ip-address/tftp-server at least semi-dynamically.  I propose to
handle this by defining a separate pxe boot set of options for each
hypervisor ((in reload_allocations()), and use host set:<tag> rules to
map each baremetal host back to the correct hypervisor.

nova doesn't currently VIF plug correctly - we end up with dynamic MAC
addresses, which messes this up - I'm tackling that now, but wanted a
sanity check on the rest of the stuff.

Comments please!

Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Cloud Services

More information about the OpenStack-dev mailing list