[haizea-commit] r571 - trunk/doc/manual

haizea-commit at mailman.cs.uchicago.edu haizea-commit at mailman.cs.uchicago.edu
Sun Feb 15 19:35:11 CST 2009 

Author: borja
Date: 2009-02-15 19:35:06 -0600 (Sun, 15 Feb 2009)
New Revision: 571

Added:
   trunk/doc/manual/hand.png
Modified:
   trunk/doc/manual/analysing.tex
   trunk/doc/manual/gen_html.sh
   trunk/doc/manual/install.tex
   trunk/doc/manual/opennebula.tex
   trunk/doc/manual/quickstart.tex
   trunk/doc/manual/simulation.tex
   trunk/doc/manual/title.tex
   trunk/doc/manual/whatis.tex
Log:
Documentation updates for TP1.3

Modified: trunk/doc/manual/analysing.tex
===================================================================
--- trunk/doc/manual/analysing.tex	2009-02-15 22:31:33 UTC (rev 570)
+++ trunk/doc/manual/analysing.tex	2009-02-16 01:35:06 UTC (rev 571)
@@ -11,8 +11,33 @@
 ...
 \end{wideshellverbatim}
 
-Haizea currently includes no tools to easily convert this datafile into an easily readable format (like a graph) although these will eventually be added to Haizea. For now, if you want to access the data collected by Haizea, you will have to do so programmatically. The data file contains a pickled \texttt{AccountingData} object (see module \texttt{haizea.resourcemanager.accounting}) with all the information collected during a simulation experiment. An example of how this file is unpickled, and some of its information accessed, can be found in function \texttt{haizea\_convert\_data} in module \texttt{haizea.cli.commands}.
+This file is not human-readable, and there are two ways of accessing its contents: using the \texttt{haizea-convert-data} command or programmatically through Python. These are both described next.
 
+
+\section{The \texttt{haizea-convert-data} command}
+
+The \texttt{haizea-convert-data} command will convert some of the data contained in the data file into a CSV file. Currently, this command only prints a very small subset of the data contained in the data file. Future versions of Haizea will include more complete data conversion tools.
+
+To print out the data from one simulation run, simply run the following: 
+
+\begin{shellverbatim}
+haizea-convert-data -t per-lease /var/tmp/haizea.dat
+\end{shellverbatim}
+
+This will print out one line per best-effort lease, showing its lease ID, waiting time, and slowdown. 
+
+When running multiple simulations (as described in \ref{sec:multiplesim}), Haizea will generate one data file for each simulation profile, which are all stored in the same directory. \texttt{haizea-convert-data} can also be used to produce aggregate statistics from all these data files. For example:
+
+\begin{shellverbatim}
+haizea-convert-data -t per-experiment /var/tmp/results/*.dat
+\end{shellverbatim}
+
+This will print out one line \emph{per simulation run} (i.e., one for each combination of a simulation profile, tracefile, and injection file). Currently, only the \emph{all-best-effort} metric is printed out (the time at which the last best-effort lease ended).
+
+\section{Analysing data programmatically} 
+
+The data file generated by Haizea is basically contains a Python-pickled \texttt{AccountingData} object (see module \texttt{haizea.resourcemanager.accounting}) with all the information collected during a simulation experiment. Thus, this data can be accessed programmatically from Python. An example of how this file is unpickled, and some of its information accessed, can be found in function \texttt{haizea\_convert\_data} in module \texttt{haizea.cli.commands}.
+
 The \texttt{StatsData} object contains the following information:
 
 \begin{description}
@@ -26,18 +51,13 @@
  \item \texttt{COUNTER\_BESTEFFORTCOMPLETED}: Number of completed best-effort leases.
  \item \texttt{COUNTER\_QUEUESIZE}: Queue size (best-effort leases)
  \item \texttt{COUNTER\_DISKUSAGE}: Total disk space used by VM images in the node pool.
- \item \texttt{COUNTER\_CPUUTILIZATION}: Percentage of CPUs used in node pool.
 \end{itemize}
       A "counter list" (which should more appropriately be called a "metric log") includes an entry for each time a metric changes. Each entry is a tuple (time, lease\_id, value, average). If the metric is not associated with any particular lease, then the lease ID will be \texttt{None}. The average is a running average which will be \texttt{None} when it does not make sense to keep an average (e.g., the number of accepted AR requests).
 \item[Lease descriptors] The lease descriptors (i.e., \texttt{ARLease}, \texttt{BestEffortLease}, or \texttt{ImmediateLease} objects) of all the leases that have been scheduled are included in the object. The resource reservations are removed, as it would make the datafile too big. However, this still conserves interesting metrics like starting and ending times, waiting times, etc.
 \end{description}
 
-\section{Analysing data from multiple simulations}
-
 When running multiple simulations (as described in \ref{sec:multiplesim}), Haizea will add information on the simulation profile to the \texttt{AccountingData} object. In particular, the profile name can be accessed through the \texttt{attrs} attribute:
 
 \begin{wideshellverbatim}
 profile = accounting_data_obj.attrs["profile"]
 \end{wideshellverbatim}
-
-In the future, it will be possible to automatically add other attributes based on the trace files and injection files used in the simulations, to facilitate analysing the different not just between simulation profiles, but also different workloads.

Modified: trunk/doc/manual/gen_html.sh
===================================================================
--- trunk/doc/manual/gen_html.sh	2009-02-15 22:31:33 UTC (rev 570)
+++ trunk/doc/manual/gen_html.sh	2009-02-16 01:35:06 UTC (rev 571)
@@ -1,10 +1,16 @@
 #!/bin/bash
 
-latex2html -split 4 -dir ../../html/manual/ -show_section_numbers -local_icons -toc_depth 3 -link 2 -top_navigation -bottom_navigation manual.tex
+python gen_cli_doc.py > appendix_cli.tex
+python gen_config_doc.py > appendix_conf.tex
+
+latex2html -split 4 -dir ../../html/manual -show_section_numbers -local_icons -toc_depth 3 -link 2 -top_navigation -bottom_navigation manual.tex
 tar cvzf ../../html/downloads/haizea-manual-multiple.tar.gz ../../html/manual
 
-latex2html -split 0 -no_navigation -dir ../../html/manual_single/ -show_section_numbers -local_icons -toc_depth 3 manual.tex 
+latex2html -split 0 -no_navigation -dir ../../html/manual_single -show_section_numbers -local_icons -toc_depth 3 manual.tex 
 tar cvzf ../../html/downloads/haizea-manual-single.tar.gz ../../html/manual_single
 #tidy --clean y --doctype "transitional" --output-xhtml y --indent "auto" --wrap "90" --char-encoding "utf8" --logical-emphasis y
 
 cp manual.pdf ../../html/haizea_manual.pdf
+
+
+

Added: trunk/doc/manual/hand.png
===================================================================
--- trunk/doc/manual/hand.png	                        (rev 0)
+++ trunk/doc/manual/hand.png	2009-02-16 01:35:06 UTC (rev 571)
@@ -0,0 +1,9 @@
+‰PNG
+
+   
+IHDR   !   !   ؆U8   	pHYs  M  MÒέN   tEXtSoftware GPL Ghostscript 8.61$Yu   õIDATH‰Ý—у …o³½ÿÃô8ìÂVŠL–Wev~bU¥Œ1sö•"Zßê֍DÈÑ¢Š–nÑ"^Ég€ê Éa0sJݐA34”ÅRèâ³Ñ”	€¹vf¶›Bê  Ę½'à¢I<eÊjW„;Aëü Ê”Ñ;Š».«EKcõGŒ’ö£N˜ÂrDþ~¬v†ªŽÑë×óÚ澤­QŸÉ¥ 
+áÂk”14ç©EmaßK3úq#Æt'÷Ÿí}ûãô>ã÷³ ‡q&>ð•AÉvtÜòþÑ[¸°3tcðg´~ˆôaoMA'À阋    IEND®B`‚‰PNG
+
+   
+IHDR   !   !   ؆U8   	pHYs  M  MÒέN   tEXtSoftware GPL Ghostscript 8.61$Yu   )IDATH‰íÍ1   µçùXÁ
+ÐIêÙ|‡Ãáp8‡Ãq7ú?u©9	    IEND®B`‚
\ No newline at end of file

Modified: trunk/doc/manual/install.tex
===================================================================
--- trunk/doc/manual/install.tex	2009-02-15 22:31:33 UTC (rev 570)
+++ trunk/doc/manual/install.tex	2009-02-16 01:35:06 UTC (rev 571)
@@ -75,11 +75,18 @@
 [2006-11-25 13:00:00.00] TFILE   Loaded workload with 0 requests (0 best-effort + 0 AR)
 [2006-11-25 13:00:00.00] RM      Starting resource manager
 [2006-11-25 13:00:00.00] CLOCK   Starting simulated clock
-[2006-11-25 13:00:00.00] CLOCK   Stopping simulated clock
-[2006-11-25 13:00:00.00] RM      Stopping resource manager
-[2006-11-25 13:00:00.00] RM        Completed best-effort leases: 0
-[2006-11-25 13:00:00.00] RM        Accepted AR leases: 0
-[2006-11-25 13:00:00.00] RM        Rejected AR leases: 0
+[2006-11-25 13:00:00.00] CLOCK   Simulated clock has stopped
+[2006-11-25 13:00:00.00] RM      Stopping resource manager gracefully...
+[2006-11-25 13:00:00.00] RM      --- Haizea status summary ---
+[2006-11-25 13:00:00.00] RM      Number of leases (not including completed): 0
+[2006-11-25 13:00:00.00] RM      Completed leases: 0
+[2006-11-25 13:00:00.00] RM      Completed best-effort leases: 0
+[2006-11-25 13:00:00.00] RM      Queue size: 0
+[2006-11-25 13:00:00.00] RM      Accepted AR leases: 0
+[2006-11-25 13:00:00.00] RM      Rejected AR leases: 0
+[2006-11-25 13:00:00.00] RM      Accepted IM leases: 0
+[2006-11-25 13:00:00.00] RM      Rejected IM leases: 0
+[2006-11-25 13:00:00.00] RM      ---- End summary ----
 \end{wideshellverbatim}
 
 Ok, not terribly exciting, but if you see this then the basic machinery is working fine. We will see how to do more elaborate simulations, and how to use Haizea to manage real hardware, in the next chapters.

Modified: trunk/doc/manual/opennebula.tex
===================================================================
--- trunk/doc/manual/opennebula.tex	2009-02-15 22:31:33 UTC (rev 570)
+++ trunk/doc/manual/opennebula.tex	2009-02-16 01:35:06 UTC (rev 571)
@@ -3,14 +3,14 @@
 This chapter explains how to use OpenNebula and Haizea together, and explains how to submit requests to OpenNebula to use Haizea's scheduling capabilities.
 
 \begin{warning}
-Please remember that, although we have tested Haizea considerably with OpenNebula 1.0, 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.
+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}
 
 \section{Installing OpenNebula and Haizea}
 
-If you have not already done so, you will need to install OpenNebula 1.0 and the latest version of Haizea. Start by installing OpenNebula, and then installing Haizea.
+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.0: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.
+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.
 
 \section{Configuring Haizea}
 
@@ -30,8 +30,8 @@
 # The following assumes that \$ONE_LOCATION is /opt/nebula/ONE
 # If you used a different \$ONE_LOCATION, modify the paths 
 # accordingly
-db: /opt/nebula/ONE/var/one.db
-onevm: /opt/nebula/ONE/bin/onevm
+db: /usr/local/one/var/one.db
+onevm: /usr/local/one/bin/onevm
 \end{wideshellverbatim}
 
 There are some additional options described at the end of this chapter, but which you do not need to concern yourself with yet.
@@ -59,9 +59,10 @@
 When Haizea starts up, it will print out something like this:
 
 \begin{wideshellverbatim}
-[2008-07-21 11:49:00.63] ONE     Fetched N nodes from ONE db
-[2008-07-21 11:49:00.63] RM      Starting resource manager
-[2008-07-21 11:49:00.63] CLOCK   Starting clock
+[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
 \end{wideshellverbatim}
 
 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).
@@ -113,14 +114,16 @@
 Next time Haizea wakes up, you should see something like this:
 
 \begin{wideshellverbatim}
-[2008-07-21 11:50:00.99] CLOCK   Waking up to manage resources
-[2008-07-21 11:50:00.99] CLOCK   Wake-up time recorded as 2008-07-21 11:50:01.00
-[2008-07-21 11:50:01.03] SCHED   Received AR lease request #1, 1 nodes 
-                                   from 2008-07-21 11:50:31.00 
-                                     to 2008-07-21 11:51:31.00.
-[2008-07-21 11:50:01.03] SCHED   AR lease request #1 has been accepted.
-[2008-07-21 11:50:01.03] CLOCK   Going back to sleep. 
-                                 Waking up at 2008-07-21 11:50:31.00 
+[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 
                                  to handle slot table event.
 \end{wideshellverbatim}
 
@@ -137,11 +140,11 @@
 When the VM is scheduled to start, you will see the following in the Haizea logs:
 
 \begin{wideshellverbatim}
-[2008-07-21 11:50:30.99] CLOCK   Waking up to manage resources
-[2008-07-21 11:50:30.99] CLOCK   Wake-up time recorded as 2008-07-21 11:50:31.00
-[2008-07-21 11:50:31.32] SCHED   Started VMs for lease 1 on nodes [1]
-[2008-07-21 11:50:31.32] CLOCK   Going back to sleep. 
-                                 Waking up at 2008-07-21 11:51:31.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 
                                  to handle slot table event.
 \end{wideshellverbatim}
 
@@ -156,11 +159,11 @@
 You should be able to access the VM (if you configured it with networking and SSH). However, since we requested the VM to run for just a minute, you will soon see the following in the Haizea logs:
 
 \begin{wideshellverbatim}
-[2008-07-21 11:51:31.00] CLOCK   Waking up to manage resources
-[2008-07-21 11:51:31.00] CLOCK   Wake-up time recorded as 2008-07-21 11:51:31.00
-[2008-07-21 11:51:31.17] SCHED   Stopped VMs for lease 1 on nodes [1]
-[2008-07-21 11:51:31.17] CLOCK   Going back to sleep. 
-                                 Waking up at 2008-07-21 11:52:31.00 
+[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 
                                  to see if something interesting has happened by then.
 \end{wideshellverbatim}
 
@@ -239,14 +242,14 @@
 
 \section{Additional OpenNebula configuration options}
 
-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 you can tweak:
+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:
 
 \subsection{Wakeup interval}
 
 This is the interval, in seconds, at which Haizea will wake up to process pending requests in OpenNebula. The default is 60 seconds.
 
 \begin{wideshellverbatim}
-[opennebula]
+[scheduling]
 ...
 wakeup-interval: 60
 ...
@@ -257,9 +260,10 @@
 This option provides Haizea with an estimate of how long it takes for OpenNebula to suspend or resume a virtual machine. This is estimated in MB per second, and is largely dependent on the disk read/write transfer speeds on your system (so, if a VM has 1024 MB of memory, and the suspend rate is estimated to be 64MB/s, Haizea will estimate that suspension will take 16 seconds). If you do not specify a value, Haizea will conservatively assume a rate of 32MB/s. A good estimate will allow Haizea to more correctly schedule resources, but an incorrect estimate will not result in an error (although a warning will be noted in the logs).
 
 \begin{wideshellverbatim}
-[opennebula]
+[scheduling]
 ...
-suspendresume-rate-estimate: 32
+suspend-rate: 32
+resume-rate: 32
 ...
 \end{wideshellverbatim}
 
@@ -279,7 +283,7 @@
 The minimum amount of time that must pass between when a request is scheduled to when it can actually start (i.e., this makes sure that the scheduling function doesn't make reservations with starting times that will be in the past by the time the scheduling function ends). The default (10 seconds) should be good for most configurations, but may need to be increased if you're dealing with exceptionally high loads.
 
 \begin{wideshellverbatim}
-[opennebula]
+[scheduling]
 ...
 non-schedulable-interval: 10
 ...
@@ -292,6 +296,6 @@
 \begin{itemize}
 \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 currently cannot do any image deployment with OpenNebula, and VM images are assumed to be predeployed on the physical nodes, or available on a shared NFS filesystem. An upcoming version of OpenNebula will allow OpenNebula and Haizea to work with a \emph{transfer manager} to handle various VM deployment scenarios.
+\item Haizea currently cannot do any image deployment with OpenNebula, and VM images are assumed to be predeployed on the physical nodes, or available on a shared NFS filesystem. Although OpenNebula includes support for interfacing with a \emph{transfer manager} to handle various VM deployment scenarios, Haizea currently does not access this functionality.
 \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)
 \end{itemize}
\ No newline at end of file

Modified: trunk/doc/manual/quickstart.tex
===================================================================
--- trunk/doc/manual/quickstart.tex	2009-02-15 22:31:33 UTC (rev 570)
+++ trunk/doc/manual/quickstart.tex	2009-02-16 01:35:06 UTC (rev 571)
@@ -81,10 +81,16 @@
 [2006-11-25 13:00:00.00] RM      Starting resource manager
 [2006-11-25 13:00:00.00] CLOCK   Starting simulated clock
 [2006-11-25 13:00:00.00] CLOCK   Stopping simulated clock
-[2006-11-25 13:00:00.00] RM      Stopping resource manager
-[2006-11-25 13:00:00.00] RM        Completed best-effort leases: 0
-[2006-11-25 13:00:00.00] RM        Accepted AR leases: 0
-[2006-11-25 13:00:00.00] RM        Rejected AR leases: 0
+[2006-11-25 13:00:00.00] RM      --- Haizea status summary ---
+[2006-11-25 13:00:00.00] RM      Number of leases (not including completed): 0
+[2006-11-25 13:00:00.00] RM      Completed leases: 0
+[2006-11-25 13:00:00.00] RM      Completed best-effort leases: 0
+[2006-11-25 13:00:00.00] RM      Queue size: 0
+[2006-11-25 13:00:00.00] RM      Accepted AR leases: 0
+[2006-11-25 13:00:00.00] RM      Rejected AR leases: 0
+[2006-11-25 13:00:00.00] RM      Accepted IM leases: 0
+[2006-11-25 13:00:00.00] RM      Rejected IM leases: 0
+[2006-11-25 13:00:00.00] RM      ---- End summary ----
 \end{wideshellverbatim}
 
 Now that you've seen the tracefile, you can see why the simulator starts up and immediately stops: all the lease requests in the tracefile are commented out, and there's nothing to schedule. Go ahead and uncomment only the first lease request and run Haizea again. You should now see the following:
@@ -94,20 +100,27 @@
 [2006-11-25 13:00:00.00] TFILE   Loaded workload with 1 requests (1 best-effort + 0 AR)
 [2006-11-25 13:00:00.00] RM      Starting resource manager
 [2006-11-25 13:00:00.00] CLOCK   Starting simulated clock
-[2006-11-25 13:00:00.00] SCHED   Received (and queueing) best-effort lease request #1, 
-                                 1 nodes for 01:00:00.00.
-[2006-11-25 13:00:00.00] SCHED   Next request in the queue is lease 1. 
-                                 Attempting to schedule...
-[2006-11-25 13:00:00.00] SCHED   Lease #1 has been scheduled on nodes [1] 
+[2006-11-25 13:00:00.00] LSCHED  Lease #1 has been requested and is pending.
+[2006-11-25 13:00:00.00] LSCHED  Queued best-effort lease request #1, 1 nodes for 01:00:00.00.
+[2006-11-25 13:00:00.00] LSCHED  Next request in the queue is lease 1. Attempting to schedule...
+[2006-11-25 13:00:00.00] VMSCHED Lease #1 has been scheduled on nodes [1] 
                                  from 2006-11-25 13:00:00.00 
                                    to 2006-11-25 14:00:00.00
-[2006-11-25 13:00:00.00] SCHED   Started VMs for lease 1 on nodes [1]
-[2006-11-25 14:00:00.00] SCHED   Stopped VMs for lease 1 on nodes [1]
-[2006-11-25 14:00:00.00] CLOCK   Stopping simulated clock
-[2006-11-25 14:00:00.00] RM      Stopping resource manager
-[2006-11-25 14:00:00.00] RM        Completed best-effort leases: 1
-[2006-11-25 14:00:00.00] RM        Accepted AR leases: 0
-[2006-11-25 14:00:00.00] RM        Rejected AR leases: 0
+[2006-11-25 13:00:00.00] VMSCHED Started VMs for lease 1 on nodes [1]
+[2006-11-25 14:00:00.00] VMSCHED Stopped VMs for lease 1 on nodes [1]
+[2006-11-25 14:00:00.00] VMSCHED Lease 1's VMs have shutdown.
+[2006-11-25 14:00:00.00] CLOCK   Simulated clock has stopped
+[2006-11-25 14:00:00.00] RM      Stopping resource manager gracefully...
+[2006-11-25 14:00:00.00] RM      --- Haizea status summary ---
+[2006-11-25 14:00:00.00] RM      Number of leases (not including completed): 0
+[2006-11-25 14:00:00.00] RM      Completed leases: 1
+[2006-11-25 14:00:00.00] RM      Completed best-effort leases: 1
+[2006-11-25 14:00:00.00] RM      Queue size: 0
+[2006-11-25 14:00:00.00] RM      Accepted AR leases: 0
+[2006-11-25 14:00:00.00] RM      Rejected AR leases: 0
+[2006-11-25 14:00:00.00] RM      Accepted IM leases: 0
+[2006-11-25 14:00:00.00] RM      Rejected IM leases: 0
+[2006-11-25 14:00:00.00] RM      ---- End summary ----
 \end{wideshellverbatim}
 
 The above corresponds to the following schedule:
@@ -127,51 +140,49 @@
 Uncomment the AR lease request, and run Haizea again. You should now see the following:
 
 \begin{wideshellverbatim}
-[2006-11-25 13:00:00.00] TRACE   Loading tracefile /usr/share/haizea/traces/sample.lwf
-[2006-11-25 13:00:00.00] TRACE   Loaded workload with 2 requests (1 best-effort + 1 AR)
+[2006-11-25 13:00:00.00] TFILE   Loading tracefile /home/haizea/sample.lwf
+[2006-11-25 13:00:00.00] TFILE   Loaded workload with 2 requests (1 best-effort + 1 AR)
 [2006-11-25 13:00:00.00] RM      Starting resource manager
 [2006-11-25 13:00:00.00] CLOCK   Starting simulated clock
-[2006-11-25 13:00:00.00] SCHED   Received (and queueing) best-effort lease request #1, 
-                                 1 nodes for 01:00:00.00.
-[2006-11-25 13:00:00.00] SCHED   Next request in the queue is lease 1. 
-                                 Attempting to schedule...
-[2006-11-25 13:00:00.00] SCHED   Lease #1 has been scheduled on nodes [1] 
+[2006-11-25 13:00:00.00] LSCHED  Lease #1 has been requested and is pending.
+[2006-11-25 13:00:00.00] LSCHED  Queued best-effort lease request #1, 1 nodes for 01:00:00.00.
+[2006-11-25 13:00:00.00] LSCHED  Next request in the queue is lease 1. Attempting to schedule...
+[2006-11-25 13:00:00.00] VMSCHED Lease #1 has been scheduled on nodes [1] 
                                  from 2006-11-25 13:00:00.00 
                                    to 2006-11-25 14:00:00.00
-[2006-11-25 13:00:00.00] SCHED   Started VMs for lease 1 on nodes [1]
+[2006-11-25 13:00:00.00] VMSCHED Started VMs for lease 1 on nodes [1]
 
-[2006-11-25 13:15:00.00] SCHED   Received AR lease request #2, 4 nodes 
+[2006-11-25 13:15:00.00] LSCHED  Lease #2 has been requested and is pending.
+[2006-11-25 13:15:00.00] LSCHED  Scheduling AR lease #2, 4 nodes
                                  from 2006-11-25 13:30:00.00 
                                    to 2006-11-25 14:00:00.00.
-[2006-11-25 13:15:00.00] SCHED   Must preempt leases [1] to make room for AR lease #2
-[2006-11-25 13:15:00.00] SCHED   Preempting lease #1...
-[2006-11-25 13:15:00.00] SCHED   ... lease #1 will be suspended 
+[2006-11-25 13:15:00.00] LSCHED  Must preempt leases [1] to make room for lease #2
+[2006-11-25 13:15:00.00] LSCHED  Preempting lease #1...
+[2006-11-25 13:15:00.00] LSCHED  ... lease #1 will be suspended 
                                      at 2006-11-25 13:30:00.00.
-[2006-11-25 13:15:00.00] SCHED   AR lease request #2 has been accepted.
+[2006-11-25 13:15:00.00] LSCHED  AR lease #2 has been accepted.
 
-[2006-11-25 13:29:39.00] SCHED   Stopped VMs for lease 1 on nodes [1]
-[2006-11-25 13:29:39.00] SCHED   Suspending lease 1...
+[2006-11-25 13:29:39.00] VMSCHED Stopped VMs for lease 1 on nodes [1]
+[2006-11-25 13:29:39.00] VMSCHED Suspending lease 1...
 
-[2006-11-25 13:30:00.00] SCHED   Lease 1 suspended.
-[2006-11-25 13:30:00.00] SCHED   Started VMs for lease 2 on nodes [2, 3, 4, 1]
-[2006-11-25 13:30:00.00] SCHED   Next request in the queue is lease 1. 
-                                 Attempting to schedule...
-[2006-11-25 13:30:00.00] SLOT    Lease #1 has been scheduled on nodes [1] 
+[2006-11-25 13:30:00.00] VMSCHED Lease 1 suspended.
+[2006-11-25 13:30:00.00] VMSCHED Started VMs for lease 2 on nodes [2, 3, 4, 1]
+[2006-11-25 13:30:00.00] LSCHED  Next request in the queue is lease 1. Attempting to schedule...
+[2006-11-25 13:30:00.00] VMSCHED Lease #1 has been scheduled on nodes [1]
                                  from 2006-11-25 14:00:21.00 (resuming) 
                                    to 2006-11-25 14:30:42.00
 
-[2006-11-25 14:00:00.00] SCHED   Stopped VMs for lease 2 on nodes [2, 3, 4, 1]
-[2006-11-25 14:00:00.00] SCHED   Resuming lease 1...
+[2006-11-25 14:00:00.00] VMSCHED Stopped VMs for lease 2 on nodes [2, 3, 4, 1]
+[2006-11-25 14:00:00.00] VMSCHED Resuming lease 1...
+[2006-11-25 14:00:00.00] VMSCHED Lease 2's VMs have shutdown.
 
-[2006-11-25 14:00:21.00] SCHED   Resumed lease 1
-[2006-11-25 14:00:21.00] SCHED   Started VMs for lease 1 on nodes [1]
+[2006-11-25 14:00:21.00] VMSCHED Resumed lease 1
+[2006-11-25 14:00:21.00] VMSCHED Started VMs for lease 1 on nodes [1]
 
-[2006-11-25 14:30:42.00] SCHED   Stopped VMs for lease 1 on nodes [1]
-[2006-11-25 14:30:42.00] CLOCK   Stopping simulated clock
-[2006-11-25 14:30:42.00] RM      Stopping resource manager
-[2006-11-25 14:30:42.00] RM        Completed best-effort leases: 1
-[2006-11-25 14:30:42.00] RM        Accepted AR leases: 1
-[2006-11-25 14:30:42.00] RM        Rejected AR leases: 0
+[2006-11-25 14:30:42.00] VMSCHED Stopped VMs for lease 1 on nodes [1]
+[2006-11-25 14:30:42.00] VMSCHED Lease 1's VMs have shutdown.
+[2006-11-25 14:30:42.00] CLOCK   Simulated clock has stopped
+[2006-11-25 14:30:42.00] RM      Stopping resource manager gracefully...
 \end{wideshellverbatim}
 
 Notice how the above corresponds to the previous figure. In particular, notice the following:
@@ -197,14 +208,14 @@
 Rerun Haizea. Now, when the AR lease arrives at 13:15, the scheduler will realise it has to preempt the best-effort lease to make room for the AR lease, but will no longer be able to suspend it. The only option is to cancel the best-effort lease and resubmit it to the queue:
 
 \begin{wideshellverbatim}
-[2006-11-25 13:15:00.00] SCHED   Preempting lease #1...
-[2006-11-25 13:15:00.00] SCHED   ... lease #1 has been cancelled and requeued
+[2006-11-25 13:15:00.00] LSCHED  Preempting lease #1...
+[2006-11-25 13:15:00.00] LSCHED  ... lease #1 has been cancelled and requeued
 \end{wideshellverbatim}
 
 Now, the best-effort lease can only be scheduled after the AR lease, at 14:00:
 
 \begin{wideshellverbatim}
-[2006-11-25 13:15:00.00] SLOT    Lease #1 has been scheduled on nodes [1] 
+[2006-11-25 13:15:00.00] VMSCHED Lease #1 has been scheduled on nodes [1] 
                                  from 2006-11-25 14:00:00.00 
                                    to 2006-11-25 15:00:00.00
 \end{wideshellverbatim}
@@ -231,8 +242,8 @@
 Rerun Haizea again. You should get a schedule similar to the previous one, but with some extra messages indicating that image transfers are taking place:
 
 \begin{wideshellverbatim}
-[2006-11-25 13:00:00.00] SCHED   Starting image transfer for lease 1
-[2006-11-25 13:01:22.00] SCHED   Completed image transfer for lease 1
+[2006-11-25 13:00:00.00] DEPLOY  Starting image transfer for lease 1
+[2006-11-25 13:01:22.00] DEPLOY  Completed image transfer for lease 1
 \end{wideshellverbatim}
 
 As you can see, the best-effort lease can no longer start right at 13:00, since an image transfer has to take place before the starting time. The same is true of the AR lease, but notice how Haizea schedules the image transfer in such a way that the AR lease can still start at 13:30 as planned (instead of delaying the starting time until 13:31:22).
@@ -285,7 +296,7 @@
 So, let's give Haizea something to do. The \texttt{haizea-request-lease} command is used to request leases. For example, the following command is used to request an 1-node AR lease one minute in the future, for ten minutes:
 
 \begin{wideshellverbatim}
-haizea-request-lease -t +00:01:00 -d 00:10:00 -n 1 --non-preemptible \
+haizea-request-lease -t +00:02:00 -d 00:10:00 -n 1 --non-preemptible \
                      -c 1 -m 512 -i foobar.img -z 600 
 \end{wideshellverbatim}
 

Modified: trunk/doc/manual/simulation.tex
===================================================================
--- trunk/doc/manual/simulation.tex	2009-02-15 22:31:33 UTC (rev 570)
+++ trunk/doc/manual/simulation.tex	2009-02-16 01:35:06 UTC (rev 571)
@@ -68,7 +68,7 @@
 \item \texttt{Disk}: Disk space in MB (not counting space for disk image cache).
 \end{itemize}
 
-These five resources must always be specified, since Haizea depends on them for fundamental resource reservations (running VMs, suspension of VMs, etc.) which involve these five types of resources. Additional resource types can be specified, but Haizea's scheduling code would have to be modified for them to be taken into account when scheduling leases. In the future, Haizea it will be possible to specify additional resources in the simulated nodes and in the lease requests with less effort.
+These five resources must always be specified, since Haizea depends on them for fundamental resource reservations (running VMs, suspension of VMs, etc.) which involve these five types of resources. Additional resource types can be specified, but Haizea's scheduling code would have to be modified for them to be taken into account when scheduling leases. In the future, it will be possible to specify additional resources in the simulated nodes and in the lease requests with less effort.
 
 \section{Scheduling options}
 

Modified: trunk/doc/manual/title.tex
===================================================================
--- trunk/doc/manual/title.tex	2009-02-15 22:31:33 UTC (rev 570)
+++ trunk/doc/manual/title.tex	2009-02-16 01:35:06 UTC (rev 571)
@@ -7,7 +7,7 @@
 % Title
 \HRule \\[0.4cm]
 \includegraphics[width=0.6\textwidth]{images/haizea.png}\\[1cm]
-\textsc{ \huge The Haizea Manual}\\{\large Technology Preview 1.2}\\{\large 9/29/08}\\[0.4cm]
+\textsc{ \huge The Haizea Manual}\\{\large Technology Preview 1.3}\\{\large 2/16/09}\\[0.4cm]
  
 \HRule \\[1.5cm]
 \url{http://haizea.cs.uchicago.edu/}

Modified: trunk/doc/manual/whatis.tex
===================================================================
--- trunk/doc/manual/whatis.tex	2009-02-15 22:31:33 UTC (rev 570)
+++ trunk/doc/manual/whatis.tex	2009-02-16 01:35:06 UTC (rev 571)
@@ -21,7 +21,7 @@
 
 Haizea can be used as a drop-in replacement for OpenNebula's scheduling daemon. OpenNebula is a virtual infrastructure manager that enables the dynamic deployment and re-allocation of virtual machines on a pool of physical resources. OpenNebula and Haizea complement each other, since OpenNebula provides all the enactment muscle (OpenNebula can manage Xen and KVM virtual machines on a cluster, with VMWare support to follow shortly) while Haizea provides all the scheduling brains. 
 
-Chapter~\ref{chap:opennebula} describes how to use Haizea an OpenNebula together.
+Chapter~\ref{chap:opennebula} describes how to use Haizea and OpenNebula together.
 
 \subsection{Unattended simulation mode}

More information about the Haizea-commit mailing list