MAAS 1.9 network layouts for the Landscape Autopilot

Andreas Hasenack

Andreas Hasenack

on 10 April 2015

Thanks for your interest in Ubuntu OpenStack. Canonical has sunsetted OpenStack Autopilot and replaced it with conjure-up. We welcome you to visit our OpenStack product page to find an Ubuntu OpenStack solution that meets your needs.


The Ubuntu OpenStack Autopilot deploys an OpenStack cloud using Juju, MAAS and Landscape. It requires an existing MAAS 1.9 server and a certain network layout. This article will show two such network layouts that lead to a successful Autopilot run.

UPDATE: this post was updated on November 1st, 2016, to support MAAS version 1.9. Version 1.8 is no longer supported for the Autopilot.

Internet access

MAAS, its nodes and the Autopilot will need to be able to reach the internet, or at least these sites (http and https):

  • an Ubuntu archive ( or a mirror)

If opening holes in a firewall, be mindful that these addresses may resolve to multiple IPs.

Network layout

There are two basic network layouts that we support. Let’s call them “flat network” and “split network”. In both of these models, at least one node needs to have two network interfaces connected to networks that MAAS knows about. We’ll call them private and public networks.

Keep in mind that OpenStack floating IPs will always come from the public network.

In the following diagrams, the “cloud” that is above the router does not necessarily mean the Internet directly, just that eventually devices on this network can reach the Internet.

Flat network

The flat network model is the most basic one. Here we trick the system and simply say the public and private networks are the same and connect both NICs to it:


OpenStack floating IPs will come from the same network as MAAS node IPs in this scenario.

Split network

In the split network topology, we have two actual distinct networks:


MAAS only manages the private network, for which it will setup DNS and DHCP, but it helps if it knows about the public one. An easy way to handle that automatically is to just hook up a second NIC to the MAAS machine and connect it to the public network as shown. MAAS will then automatically know about it. Otherwise you need to manually register it via the MAAS 1.9 API and this is not covered in this post.

Installing MAAS

This is how the MAAS server should be installed:

  • Install Ubuntu server 14.04 LTS on the machine you want to use for MAAS

sudo apt update
sudo apt install maas

  • If you are setting up the split network topology, make sure the MAAS API endpoint is on the private network IP and not the public network:

sudo dpkg-reconfigure maas-cluster-controller
sudo dpkg-reconfigure maas-region-controller

  • Access the MAAS UI at http://maas.ip/MAAS/ and follow the instructions to create the administrator, then login with those credentials
  • Go to the settings tab and change the image download URL in the Boot Images section to and click save
  • Still in the settings tab, insert an upstream DNS server if needed and then click on the save button for that form
  • Go to the Images tab and import disk images for 14.04 LTS (Trusty) 64 bits and 16.04 LTS (Xenial). This will take a few minutes, depending on your bandwidth. Let’s continue with the configuration while that download happens.
  • Add your SSH key to your user profile by clicking on your login name in the top right corner and selecting “Account”

Configuring the MAAS cluster

  • Click on the “Clusters” tab and then click on your cluster
  • Choose a DNS zone name
  • You should see a list of NICs on the machine. Click the edit symbol for the NIC that’s connected to the private network, that is, the network where all the nodes are and where they will PXE boot from
  • Set this NIC to manage DHCP and DNS.
  • If needed, configure the IP, subnet mask, broadcast IP. Note: nothing in this form will change the actual NIC configuration in Ubuntu!
  • Set the “Router IP” to the default gateway for this private network. This is usually NOT the MAAS server IP.
  • Carve up your network space into ranges like this:
    • for the split network case: dynamic range and static range
    • for the flat network case: dynamic range, static range and floating IP range


  • dynamic range: used by all the NICs in the nodes while they enlist and commission. Also used by LXC containers, when they are deployed to allocated nodes. As a rule of thumb, reserve 60 IPs plus total number of NICs connected to the network in MAAS.
  • static range: used by nodes when they are allocated to a user. As a rule of thumb, reserve 20 IPs plus total number of machines in MAAS.
  • floating IP range: used by OpenStack floating IPs. This is not a MAAS configuration, but you should leave room for them

Save the changes and go back to the Images tab and wait for the image download to be finished. Once that is done, proceed to the next step.

Enlist and commission machines

  • Ensure all other machines are set to PXE boot, if possible disable all other boot options (including local disk) in the BIOS
  • Enlist the machines by powering them on. This can usually be done by some sort of virtual console. Eventually they will all appear in the node list in MAAS and be powered down again.
  • Edit each machine in the nodes list and fill in the Power type and power parameters so that MAAS can turn them on and off as needed
  • Select all of the machines and, using the Bulk action dropdown, Commission them
  • Wait until all machines are in the Ready state

Verify networking

Let’s verify the networking setup in each node. Click on each node from the Nodes listing page and verify:

For the flat network topology:

  • Nodes with two NICs should have both of them connected to the subnet. One of the NICs should have the “IP address” field set to “Auto assign” and the other to “Unconfigured”.
  • Nodes with just one NIC should have that NIC connected to the subnet and the “IP address” field set to “Auto assign”.

For the split network topology, nodes with two NICs will have one connected to the private subnet, but the second NIC will have to be changed.

Click on the “fabric” dropdown menu and select the second fabric:


Click on the “subnet” dropdown and select the public subnet:


Leave the “IP address” unconfigured.

Testing things

To make sure juju can drive MAAS and provision machines, let’s take it for a spin. It’s best to try it out now and fix any issues before more complex services like the Autopilot make use of it.

On the machine being used to drive the installation, run these commands:

  1. sudo apt-get update
  2. sudo apt-get install juju-core juju-deployer
  3. Follow Juju docs for configuring MAAS

The remainder of this document will assume that the MAAS Juju environment you just configured is the default one.

For a simple test, we will deploy Ubuntu to all nodes. On the machine that is driving the installation, run these commands:

  1. juju bootstrap this will use one of the MAAS nodes to bootstrap juju. It will take a few minutes to complete
  2. juju deploy ubuntu -n N deploy ubuntu to all remaining nodes. Replace N with the number of nodes minus one, which was used for the bootstrap above. This command returns after a few seconds, but it just starts the process.
  3. watch the nodes list in the MAAS UI. You should see nodes being allocated and deployed
  4. watch the output of juju status --format=yaml periodically until everything is started
  5. login into a random node via ssh and try to reach the internet from it. For example, try juju ssh ubuntu/0 and wget from there
  6. if everything worked correctly, destroy the environment juju destroy-environment $(juju env)

MAAS is setup and ready to be used by the OpenStack Autopilot.


Ubuntu cloud

Ubuntu offers all the training, software infrastructure, tools, services and support you need for your public and private clouds.

Newsletter signup

Select topics you’re interested in

In submitting this form, I confirm that I have read and agree to Canonical’s Privacy Notice and Privacy Policy.

Related posts

Need to set up servers in remote locations?

Use bare metal provisioning with a top-of-the-rack switch When deploying a small footprint environment such as edge computing sites, 5G low latency services, a site support cabinet or baseband unit, its critical to establish the optimal…

Canonical at Open Infrastructure Summit -Denver

Open Infrastructure Summit is coming to Denver from April 29th to May 1st, 2019. Will you be there? We sure will! Come and visit us in Booth B1! Canonical experts will be at the event ready to answer your questions and walk you through our…

Open infrastructure, developer desktop and IoT are the focus for Ubuntu 19.04

18th April, 2019: Canonical today announced the release of Ubuntu 19.04, focused on open infrastructure deployments, the developer desktop, IoT, and cloud to edge software distribution. “The open-source-first on Ubuntu movement in telco,…