[openstack-dev] [quantum] RFC: quantum baremetal config/work to do
gkotton at redhat.com
Mon Jan 7 10:01:11 UTC 2013
On 01/06/2013 09:42 PM, Robert Collins wrote:
> 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.
Why have Nova managing the DHCP. Quantum has IPAM and a option of using
a DHCP agent. The advantage of this is that the DHCP agent will only
allocate IP addresses for devices that are registered as Quantum ports.
> 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=192.0.2.34,end=192.0.2.38 --gateway=192.0.2.33 $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
The Quantum DHCP agent will only provide IP's for MAC addresses that are
known to the agent.
> 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.
When you create a Quantum port you are able to specify the MAC address
of the port. This may require a few tweaks to the Nova code when
creating the Quantum port. Today you are able to do a nova boot and pass
the port id a parameter. So if you create the Quantum port outside of
Nova then you can do this with the existing API's.
> Comments please!
More information about the OpenStack-dev