Skip to content
Hardware Isolation Layer, formerly Hardware as a Service
Python Shell Mako
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.
ci Run the networking server Jan 23, 2019
docs Some fixes in the documentation that @RobinKaul found Nov 8, 2018
examples Remove extra args in node_register call in example. Sep 7, 2018
scripts Add the file for tab completion. Mar 29, 2018
specs Add section describing changes to HIL. Jan 22, 2018
tests Add integration test Feb 14, 2019
.gitignore change the testfiles name to avoid import mismatch Feb 21, 2018
.travis.yml Install obmd for all tests. May 31, 2018
AUTHORS Update AUTHORS Feb 6, 2018
COPYING more changes Jan 25, 2018
LICENSE Put Apache-2.0 license at LICENSE Jul 25, 2014 Rename haas to hil. Jun 16, 2017
README.rst Remove coveralls May 14, 2018
setup.cfg Rename haas to hil. Jun 16, 2017 Dont use the latest version of pytest plugins pytest-cov and pytest-x… Jan 17, 2019



HIL is a low-level tool for reserving physical machines and connecting them via isolated networks. It does not prescribe a particular method for imaging/managing said machines, allowing the user to use any solution of their choosing.

We call this paradigm "hardware as a service" (HaaS); HIL is our implementation of this idea.

HIL keeps track of available resources in a database, which a system administrator must populate initially.

This includes information such as:

  • What machines are available
  • What network interfaces they have
  • Where those NICs are connected (what port on what switch)

From there, a regular user may:

  • Reserve physical machines
  • Create isolated logical networks
  • Create "headnodes," which are small virtual machines usable for management/provisioning purposes
  • Connect network interfaces belonging to physical and/or headnodes to logical networks.
  • Reboot their machines, view the serial consoles -- aditionaly such management features may exist in the future.

A typical user workflow might look like:

  1. Reserve some machines.
  2. Create a logical "provisioning" network.
  3. Connect a NIC from each machine to the provisioning network. In particular, one could connect a NIC from which the machine will attempt to boot.
  4. Create a headnode, and attach it to the provisioning network
  5. Log in to the headnode, set up a PXE server, reboot the nodes, and deploy an operating system on them via the network.


Required software/hardware for running a production HIL include:

  • Network switches:
    • At least one switch from the Cisco Nexus 5xxx or Dell PowerConnect 55xx families
    • For environments including more than one switch, all VLANs must be trunked to all managed switches
  • A single node that has the following:
    • A webserver capable of supporting the WSGI standard (Apache/mod_wsgi is the only one tested)
    • python 2.7, with the ability to install packages via pip
    • Access to:
      • The Internet or intranet (a way for users to connect to the HIL service)
      • The administrative telnet IP on the managed switches
    • Currently only CentOS and RHEL 7.x have been tested, though any node that otherwise meets these requirements should function.
  • Database: a Postgres database server. Sqlite works but is not recommended for production.

For IPMI proxy functionality:

  • Network access from the HIL service node to the IPMI interfaces of node under management
  • Nodes that support IPMI v2+
  • A recent version of ipmitool installed on the HIL service node

For headnode functionality:

  • A recent Linux version for the HIL service node that has libvirt with KVM installed
  • Some number of VM templates
  • A trunk port connected between the switch and HIL service node that carries all VLANs accessible from HIL


  • The full documentation is availalbe at ReadTheDocs in a beautiful and easy to navigate web interface.
  • The docs directory contains documentation in .rst and .md format
  • examples contains examples of config files, templates for creating headnode VM images and a script to register nodes with HaaS.

Of particular relevance to developers:

Please note that the documentation is a mix of Markdown and reStructured Text, since the latter is preferred by the python and OpenStack communities and the former was what was originally used.


If you would like to learn more about HIL's design or cite it in a publication, please refer to:

Jason Hennessey, Sahil Tikale, Ata Turk, Emine Ugur Kaynar, Chris Hill, Peter Desnoyers, and Orran Krieger. 2016. HIL: Designing an Exokernel for the Data Center. In Proceedings of the Seventh ACM Symposium on Cloud Computing (SoCC '16). DOI: 10.1145/2987550.2987588


author = {Hennessey, Jason and Tikale, Sahil and Turk, Ata and Kaynar, Emine Ugur and Hill, Chris and Desnoyers, Peter and Krieger, Orran},
title = {HIL: Designing an Exokernel for the Data Center},
booktitle = {Proceedings of the Seventh ACM Symposium on Cloud Computing},
series = {SoCC '16},
year = {2016},
isbn = {978-1-4503-4525-5},
location = {Santa Clara, CA, USA},
pages = {155--168},
numpages = {14},
url = {},
doi = {10.1145/2987550.2987588},
acmid = {2987588},
publisher = {ACM},
address = {New York, NY, USA},
keywords = {IaaS, PaaS, bare metal, cloud computing, datacenter management, exokernel},

An early short paper on HIL (then called "Hardware as a Service/HaaS"):

Jason Hennessey, Chris Hill, Ian Denhardt, Viggnesh Venugopal, George Silvis, Orran Krieger, and Peter Desnoyers, Hardware as a service - enabling dynamic, user-level bare metal provisioning of pools of data center resources. in 2014 IEEE High Performance Extreme Computing Conference, Waltham, MA, USA, 2014.

Other work that has involved HIL can be found on the Mass Open Cloud papers page.

Mass Open Cloud

This project is part of the larger Mass Open Cloud. For a description of the team and other information, see

You can’t perform that action at this time.