Haizea

OpenNebula (\url{http://www.opennebula.org/}) is a virtual infrastructure manager that enables the dynamic deployment and re-allocation of virtual machines on a pool of physical resources. Haizea can be used to extend OpenNebula's scheduling capabilities, allowing it to support advance reservation of resources and queueing of best effort requests. OpenNebula and Haizea complement each other, since OpenNebula provides all the enactment muscle (OpenNebula can manage Xen and KVM VMs on a cluster, with VMWare support to follow shortly) and Haizea provides the scheduling brains. Using both of them together is simple, since Haizea acts as a drop-in replacement for OpenNebula's scheduling daemon. 

\begin{warning}

Please remember that, although we have tested Haizea considerably with OpenNebula 1.2, Haizea is still a technology preview and, thus, not a good choice for production environments (yet). There are a couple of known issues and limitations which are listed at the end of this document. If you need to use OpenNebula in a production environment, and don't need any of Haizea's scheduling features (advance reservations, queueing of requests, etc.), you may want to use OpenNebula's default scheduler instead.

\end{warning}

If you have not already done so, you will need to install OpenNebula 1.2 and the latest version of Haizea. Start by installing OpenNebula, and then installing Haizea.

Before proceeding, you may want to follow the OpenNebula quickstart guide (\url{http://www.opennebula.org/doku.php?id=documentation:rel1.2:qg}) to verify that your OpenNebula installation is working fine. The rest of this document assumes that OpenNebula is correctly installed, and that you know what a \emph{virtual machine template} is (``VM templates'' is how VMs are requested to OpenNebula, so we'll be working with them quite a bit). You may also want to follow the Haizea Quickstart Guide (see Chapter~\ref{chap:quickstart}, to verify that Haizea is correctly installed.

Next, you need to tell Haizea where the OpenNebula database and \texttt{onevm} command are located. This is done in the \texttt{opennebula} section:

# The following assumes that \$ONE_LOCATION is /opt/nebula/ONE

# If you used a different \$ONE_LOCATION, modify the paths 

# accordingly

db: /usr/local/one/var/one.db

onevm: /usr/local/one/bin/onevm

There are some additional options described at the end of this chapter, but which you do not need to concern yourself with yet.

[2009-02-15 23:32:08.07] ENACT.ONE.INFO Fetched N nodes from ONE db

[2009-02-15 23:32:08.07] RM      Starting resource manager

[2009-02-15 23:32:08.07] RPCSERVER RPC server started on port 42493

[2009-02-15 23:32:08.07] CLOCK   Starting clock

This means that Haizea has correctly started up, accessed OpenNebula's database and detected that there are N physical nodes (the value of N will depend, of course, on how many nodes you have in your system).

[2008-07-21 11:49:00.63] CLOCK   Waking up to manage resources

[2008-07-21 11:49:00.63] CLOCK   Wake-up time recorded as 2008-07-21 11:49:01.00

[2008-07-21 11:49:00.63] CLOCK   Going back to sleep. 

                                 Waking up at 2008-07-21 11:50:01.00 

  ID     NAME STAT CPU     MEM        HOSTNAME        TIME

----------------------------------------------------------

  42     test pend   0       0                 00 00:00:04

[2009-02-15 23:38:01.99] CLOCK   Waking up to manage resources

[2009-02-15 23:38:01.99] CLOCK   Wake-up time recorded as 2009-02-15 23:38:02.00

[2009-02-15 23:38:02.03] LSCHED  Lease #1 has been requested and is pending.

[2009-02-15 23:38:02.03] LSCHED  Scheduling AR lease #1, 1 nodes 

                                   from 2009-02-15 23:38:32.00 

                                     to 2009-02-15 23:39:32.00.

[2009-02-15 23:38:02.03] LSCHED  AR lease #1 has been accepted.

[2009-02-15 23:38:02.03] CLOCK   Going back to sleep. 

                                 Waking up at 2009-02-15 23:38:32.00 

[2009-02-15 23:38:32.00] CLOCK   Waking up to manage resources

[2009-02-15 23:38:32.00] CLOCK   Wake-up time recorded as 2009-02-15 23:38:32.00

[2009-02-15 23:38:32.21] VMSCHED Started VMs for lease 1 on nodes [1]

[2009-02-15 23:38:32.21] CLOCK   Going back to sleep. 

                                 Waking up at 2009-02-15 23:39:32.00 

  ID     NAME STAT CPU     MEM        HOSTNAME        TIME

----------------------------------------------------------

  42     test runn   2  262144          ursa03 00 00:01:04

[2009-02-15 23:39:32.00] CLOCK   Waking up to manage resources

[2009-02-15 23:39:32.00] CLOCK   Wake-up time recorded as 2009-02-15 23:39:32.00

[2009-02-15 23:39:32.00] VMSCHED Stopped VMs for lease 1 on nodes [1]

[2009-02-15 23:39:32.12] CLOCK   Going back to sleep. 

                                 Waking up at 2009-02-15 23:39:42.00 

\item \texttt{preemptible}: This option can be either yes or no. Haizea currently uses a very simple priority scheme where VMs are either preemptible or non-preemptible (furthermore, a non-preemptible VM can preempt preemptible VMs, while preemptible VMs can't preempt anything). If a VM is preemptible, and a preempting VM needs its resources, then the preemptible VM will be suspended while the preempting VM is running. Future versions of Haizea will include better priority schemes.

When running Haizea with OpenNebula, you must specify at least the \texttt{db} and \texttt{onevm} options in the \texttt{[opennebula]} section of the configuration file. However, there are additional options in other sections that you can tweak:

\item As pointed out in this guide, Haizea has to poll OpenNebula every minute to ask if there are any new requests. Additionally, OpenNebula has no way of notifying Haizea of a change of state in a VM (e.g., a VM that died, a suspend operation that finished before expected, etc.). An upcoming version of OpenNebula will add this feature, and Haizea (in turn) will support receiving events from OpenNebula (this includes being instantly notified of new requests, instead of having to poll OpenNebula periodically).

\item If a command sent to OpenNebula fails, Haizea currently ignores this. Nonetheless, OpenNebula commands run from Haizea shouldn't fail unless you're running incredibly heavy loads, or if you manually shutdown a VM managed by Haizea.

\item Haizea cannot enact cold migrations in OpenNebula (i.e., migrating a suspended VM to a different node if resources become available earlier on a different node than the one where the VM was suspended on). Haizea actually has all the scheduling code for this, and only the enactment "glue" is missing (should be added in TP 1.3 or 1.4)