% vmm.tex - A simple "cloud" management system

\documentclass{article}

\usepackage{pifont}
\usepackage{algorithmic}
\usepackage{algorithm}

\begin{document}
\title{A simple vm management system}
\author{Richard Marshall\\
	\texttt{rgm@linux.com}}
\date{\today}
\maketitle

\section{Purpose}
To provide a management platform for virtual machines that is flexible and easy to use. 

\section{Design}

\subsection{Components}

\begin{itemize}
    \setlength{\itemsep}{1pt}
    \setlength{\parskip}{0pt}
    \setlength{\parsep}{0pt}
    \item controller - master of vm control: creation, deletion, power management, etc. Delegates to the hosts.
    \item host - handler of underlying hypervisor interaction receives requests from the controller
\end{itemize}

\subsection{Controller}

\subsection{Host}

\subsection{Controller \ding{214} Host Protocol}
A simple protocol is needed to communicate between the controller and the hosts. All attempts need to be made to design the protocol to allow for a stateless communications model between the two components. If communications between the hosts and the controller becomes disrupted the stateless methodology will help prevent synchronization problems that could arise if communications state was required. 
message types

\begin{itemize}
    \setlength{\itemsep}{1pt}
    \setlength{\parskip}{0pt}
    \setlength{\parsep}{0pt}
    \item state (host \ding{213} controller) - informs controller of changes to vm state
    \item request (controller \ding{213} host) - asks host to perform an action
    \item ack (host \ding{213} controller) - confirmation of request completion
\end{itemize}

\subsubsection{state}
State messages allow the hosts to provide information to the controller about changes to vm states. These changes include vm addition/removal, power changes, system resource changes, etc.
Possible changes to vm state:

\begin{itemize}
    \setlength{\itemsep}{1pt}
    \setlength{\parskip}{0pt}
    \setlength{\parsep}{0pt}
    \item power on
    \item power off
    \item pause
    \item crash
    \item vm added
    \item vm removed
    \item cpu added
    \item cpu removed
    \item memory change
    \item disk change
    \item nic added
    \item nic removed
\end{itemize}

One possible method of providing this data to the controller would be to send individual messages including a specific change. The problem with that model is the previous state is required to be known for a message to result in the correct state to be recorded by the controller. Instead of informing the controller that a change has occurred the host informs the controller what the new state is which does not transform the existing state information but instead overrides any existing state. 

\begin{algorithm}
state protocol data unit fields
\begin{algorithmic}
\STATE $vm \gets vmid$
\STATE $state \gets [on|off|crashed|paused]$
\end{algorithmic}
\end{algorithm}

\subsubsection{Requests}

\begin{itemize}
    \setlength{\itemsep}{1pt}
    \setlength{\parskip}{0pt}
    \setlength{\parsep}{0pt}
    \item add
    \item remove
    \item start
    \item stop
    \item restart
    \item pause
    \item migrate
    \item delete
    \item add nic
    \item remove nic
    \item update memory
    \item add cpu
    \item remove cpu (don't remember if cpus can be hot unplugged in xen)
    \item update disk
    \item snapshot
\end{itemize}

Not all the possible requests need to be implemented for a functioning system. The core requests that will need to be implemented at day one are: add, remove, start, stop, and delete.

\subsubsection{ack's}

\begin{itemize}
    \setlength{\itemsep}{1pt}
    \setlength{\parskip}{0pt}
    \setlength{\parsep}{0pt}
    \item success
    \item failure
    \item unsupported request
    \item unknown request
    \item busy
\end{itemize}

\end{document}