More doc updates

7 files changed, 489 insertions, 368 deletions

diff --git a/everest-docs/everest-docs-1.0.0/en-US/Cookbook.xml b/everest-docs/everest-docs-1.0.0/en-US/Cookbook.xml
index 568c5ac..edc3acb 100644
--- a/everest-docs/everest-docs-1.0.0/en-US/Cookbook.xml
+++ b/everest-docs/everest-docs-1.0.0/en-US/Cookbook.xml
@@ -9,66 +9,6 @@
 		toolset is always preferred this chapter is meant to be the user's reference manual.
 	</para>
 
-	<section id="everest-MakeAHost">
-		<title>Creating your initial host machine</title>
-		<para>
-			These are the steps that you do to create your "first"
-			host machine, that your repo machine will run on. You
-			should only have to do this once per project, not per
-			person. Also, your first host machine should be based
-			off of everest-repo.
-		</para>
-		<itemizedlist>
-			<listitem>
-				<para>
-					<userinput>ssh it@everest-repo.usersys.redhat.com</userinput>
-				</para>
-			</listitem>
-			<listitem><para>
-					Run <userinput>everest-bootstrap
-						--config-only</userinput> and
-					fill it in. for machine name, use the
-					machine name you want for the
-					to-be-created host machine
-			</para></listitem>
-			<listitem>
-				<para>
-					run <userinput>koan -s
-						everest-repo.usersys.redhat.com
-						--list-systems</userinput>, you
-					should see your system in there. Also,
-					you can go to
-					http://everest-repo.usersys.redhat.com:8106/nodes.html
-					and see your machine. Click it and you
-					can view or edit the config. If you
-					really fubar and create a system name
-					that shouldn't even exist (like
-					<emphasis>tj1-host-host</emphasis>),
-					you need to delete
-					<emphasis>/etc/everest/nodes/tj1-host-host.usersys.redhat.com</emphasis>.
-					This requires root on the repo machine
-					you're using to provision the host.
-
-				</para>
-			</listitem>
-			<listitem>
-				<para>
-					Once you're comfortable with the
-					config, run this: <userinput>koan -s
-						everest-repo.usersys.redhat.com
-						--replace-self
-						--system=YOUR_HOSTNAME</userinput>.
-
-				</para>
-			</listitem>
-			<listitem>
-				<para>
-					reboot to apply changes, and wait like 10-15 minutes. you're done!
-				</para>
-			</listitem>
-		</itemizedlist>
-	</section>
-
 	<section id="everest-RepoMachineBootstrapping">
 		<title>Creating your own &PRODUCT; Repo machine</title>
 		<para>
@@ -316,12 +256,16 @@ everest-sync save
 			<filename>/etc/everest/machine_types.rb</filename> on a
 			Repo machine.  The comments are the best documentation
 			for the details.  The trick is that this file is
-			controlled by puppet and it lives in the
-			<filename>everest</filename> puppet module.  You can
-			clone this from any Repo machine.  Editing the correct
-			file and pushing it to a
-			<application>puppetmaster</application> is described in
-			[TODO].
+			typically <link
+				linkend="everest-repo-machine-customization">controlled
+				by puppet</link>.  
+			
+		</para>
+
+		<para>
+			<link linkend="everest-sync">everest-sync</link> is a
+			great way to handle moving custom machine types from
+			one Repo machine to another.
 		</para>
 	</section>
 
@@ -334,7 +278,7 @@ everest-sync save
 		</para>
 
 		<para>
-			To do this simply access the
+			To do this simplify access the
 			<application>everestd</application> running on the
 			&PRODUCT; Repo that your machine is subscribed to and
 			update the yaml file.  Once the yaml has been updated
diff --git a/everest-docs/everest-docs-1.0.0/en-US/GettingStarted.xml b/everest-docs/everest-docs-1.0.0/en-US/GettingStarted.xml
index 4dab0ed..bd02c74 100644
--- a/everest-docs/everest-docs-1.0.0/en-US/GettingStarted.xml
+++ b/everest-docs/everest-docs-1.0.0/en-US/GettingStarted.xml
@@ -6,8 +6,119 @@
 	<title>Getting Started</title>
 	<para>
 		For those who wish to get up and running quickly with &PRODUCT;
-		you can simply use <link linkend="everest-Koan">Koan</link> and
-		<link linkend="everest-EverestBootstrap">everest-bootstrap</link>
+		you can simply use <link linkend="everest-replace-self">everest-replace-self</link> and
+		<link linkend="everest-EverestBootstrap">everest-bootstrap</link> tools.  A typical &PRODUCT; evironment consists of:
+
+		<itemizedlist>
+			<listitem>
+				<para>
+					A least one <link
+						linkend="everest-RepoMachineBootstrapping">Repo</link>
+					machine
+				</para>
+			</listitem>
+			<listitem>
+				<para>
+					An <link
+						linkend="everest-hypervisor-setup">environment</link>
+					to host virtual machines
+				</para>
+			</listitem>
+		</itemizedlist>
+
 	</para>
+
+	<section id="everest-hypervisor-setup">
+		<title>Setting up an environment to host virtual machines</title>
+		<para>
+		     Virtualization is by no means a requirement to make use of
+		     the &PRODUCT; tooling, though it is the more common than
+		     "bare metal" provisioning.
+		</para>
+
+		<para>
+			The machine used to host virtual machines is called the
+			Cloud Appliance.  As the name suggests, these can be
+			consist of one-to-many physical machines.  The first
+			goal of this machine is to provide and environment to
+			host virtual machines and for that reason are
+			<emphasis>always</emphasis> provisioned on "bare
+			metal".  The second is to provide an effective way to
+			manage resources amongst underutilized commodity
+			hardware. 
+		</para>
+		
+		<para>
+			Since virtualization plays such a key role in the
+			&PRODUCT; environment these machines amongst the first
+			that users of the &PRODUCT; tooling desire to get up
+			and running quickly.
+		</para>
+
+		<note>
+			<title>Note</title>
+			<para>
+				One of the main goals of the current
+				Cloud machine tooling is to
+				<emphasis>Do the simplest thing that
+					could possibly work</emphasis>.
+				This functionality, implemented through
+				<ulink
+					url="https://fedorahosted.org/func">Func</ulink>
+				modules, will most likely be entirely
+				replaced with <ulink
+					url="http://ovirt.org/">ovirt</ulink>.
+			</para>
+		</note>
+
+                <section id="cloud-appliance-setup">
+			<title>Setup</title>
+			<para>
+				Cloud Appliances use <link
+					linkend="everest-replace-self">everest-replace-self</link>
+				to get up and running quickly.  The key to
+				using
+				<application>everest-replace-self</application>
+				to provision a Cloud Appliance is to:
+				<itemizedlist>
+					<listitem>
+						<para>
+							Use a <emphasis>Cloud</emphasis> profile.
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							Set the
+							<emphasis>-m</emphasis>
+							(metadata) flag
+							appropriately.
+						</para>
+
+						<para>
+							The value for this flag varies depending it is
+							the <emphasis>certmaster</emphasis> or if it is
+							a <emphasis>minion</emphasis> in
+							<application>func</application> parlance.  
+						</para>
+
+						<para>
+							For the master set <emphasis>-m</emphasis> to
+							<emphasis>certmaster=localhost</emphasis>
+						</para>
+
+						<para>
+							For the minion set
+							<emphasis>-m</emphasis>
+							to
+							<emphasis>certmaster=[Any
+								previously
+								created Cloud
+								master]</emphasis>
+						</para>
+					</listitem>
+				</itemizedlist>
+			</para>
+		</section>
+	</section>
 </chapter>
 
diff --git a/everest-docs/everest-docs-1.0.0/en-US/Koan.xml b/everest-docs/everest-docs-1.0.0/en-US/Koan.xml
index 1e2f5ee..f4908dc 100644
--- a/everest-docs/everest-docs-1.0.0/en-US/Koan.xml
+++ b/everest-docs/everest-docs-1.0.0/en-US/Koan.xml
@@ -48,115 +48,6 @@ koan -s everest-repo.usersys.redhat.com --list-systems
 		</para>
 	</section>
 
-	<section id="everest-hypervisor-setup">
-		<title>Setting up an environment to host virtual machines</title>
-		<para>
-		     Virtualization is by no means a requirement to make use of
-		     the &PRODUCT; tooling, though it is the more common than
-		     "bare metal" provisioning.
-		</para>
-
-		<para>
-			The two main types of machines used to host virtual
-			machines are called the Host and Cloud machine types.
-			These machine types, like Repo machines, are typically
-			amongst the first machines that users of the &PRODUCT;
-			tooling desire to get up and running quickly.  These
-			machines use virtualization to host other machines and
-			for that reason are <emphasis>always</emphasis>
-			provisioned on "bare metal".
-		</para>
-
-		<note>
-			<title>Note</title>
-			<para>
-				The <emphasis>Host</emphasis> machine type,
-				while arguably poorly named, is named so based
-				on historical reasons.  In reality there are
-				very few differences between Host and Cloud
-				machines so eventually they will probably go
-				away.
-			</para>
-		</note>
-
-                <section id="everest-host-machines">
-			<title>Host machines</title>
-
-			<para>
-				The quickest way to get a Host machine up and running
-				is to use the <link
-					linkend="everest-replace-self">everest-replace-self</link> tool
-				with a <emphasis>Host</emphasis> profile.
-			</para>
-
-		</section>
-
-                <section id="everest-cloud-machines">
-			<title>Cloud machines</title>
-			<para>
-			     The &PRODUCT; Cloud machine is an effective way to
-			     manage resources amongst underutilized commodity
-			     hardware. 
-			</para>
-
-			<note>
-				<title>Note</title>
-				<para>
-					One of the main goals of the current
-					Cloud machine tooling is to
-					<emphasis>Do the simplest thing that
-						could possibly work</emphasis>.
-					This functionality, implemented through
-					<ulink
-						url="https://fedorahosted.org/func">Func</ulink>
-					modules, will most likely be entirely
-					replaced with <ulink
-						url="http://ovirt.org/">ovirt</ulink>.
-				</para>
-			</note>
-
-			<para>
-				Like Hosts, Cloud machines use <link
-					linkend="everest-replace-self">everest-replace-self</link>
-				to get up and running quickly.  The main
-				different is that a <emphasis>Cloud</emphasis>
-				profile should be used and the
-				<emphasis>-m</emphasis> (metadata) flag must
-				be set.  The value for this flag varies
-				depending it is the
-				<emphasis>certmaster</emphasis> or if it is a
-				<emphasis>minion</emphasis> in
-				<application>func</application> parlance.  
-			</para>
-
-			<para>
-				For the master set <emphasis>-m</emphasis> to
-				<emphasis>certmaster=localhost</emphasis>
-			</para>
-
-			<para>
-				For the minion set <emphasis>-m</emphasis> to
-				<emphasis>certmaster=[Any previously created Cloud master]</emphasis>
-			</para>
-
-			<note>
-				<title>Important</title>
-				<para>
-					It's typically a good idea to create a
-					standalone Cloud machine instead of a
-					Host machine since there is so little
-					difference between the two.
-				</para>
-			</note>
-		</section>
-	</section>
-
-	<section id="everest-Koan-CloudProvisioning">
-		<title>Cloud Provisioning</title>
-		<para>
-
-		</para>
-	</section>
 
 	<section id="everest-Koan-GuestProvisioning">
 		<title>Guest Provisioning</title>
diff --git a/everest-docs/everest-docs-1.0.0/en-US/MachineTypes.xml b/everest-docs/everest-docs-1.0.0/en-US/MachineTypes.xml
index ba08b1e..a5bf990 100644
--- a/everest-docs/everest-docs-1.0.0/en-US/MachineTypes.xml
+++ b/everest-docs/everest-docs-1.0.0/en-US/MachineTypes.xml
@@ -2,223 +2,235 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
 ]>
 
-<chapter id="everest-MachineTypes">
-	<title>Machine Types</title>
-	<para>
-		Many types of machines can be provisioned in the &PRODUCT;
-		environment.  There are simply too mand of them to be listed
-		here.  The most updated list can be found when using the <link
-			linkend="everest-EverestBootstrap">everest-bootstrap</link>
-		wizard.  In this chapter we'll highlight the most common types
-		of &PRODUCT; machines.
-
-		<important>
-		<title>Important</title>
-			<para>
-				From Puppet's point of view these "types" are
-				not bound to any particular OS version.  You
-				choose the OS when <link
-					linkend="everest-Koan">provisioning
-					with Koan</link>. This allows users to
-				test out different OS and applications versions
-				using the same Puppet code.
-			</para>
-		</important>
-	</para>
-
-	<section id="everest-HostMachineType">
-		<title>Host machine</title>
-		<para>
-			The Host machine type is used to host Xen guests in the &PRODUCT; environment.  It provides the user with a suitable graphical desktop environment.
-		</para>
-		<para>
-			Features:
-			<itemizedlist>
-				<listitem><para>NFS automounted home directories</para></listitem>
-				<listitem><para>Kerberized login</para></listitem>
-				<listitem><para>Xen virtualization</para></listitem>
-				<listitem><para>All &PRODUCT; tools</para></listitem>
-			</itemizedlist>
-		</para>
-	</section>
-
-	<section id="everest-RepoMachineType">
-		<title>Repo machine</title>
-		<para>
-			Repo machines are the center of development in the
-			&PRODUCT; environment.  In a nutshell they are the
-			self-contained provisioning, configuration and artifact
-			store.  For this reason &PRODUCT; machines types are
-			generally not considered volatile. 
-                </para>
+<chapter id="everest-Machines">
+	<title>Everest Machines</title>
 
+	<section id="everest-appliances">
+		<title>Appliances</title>
 		<para>
-			As all other machine types it is designed to work as
-			both a "baremetal" and virtual machine.  The main
-			resource requirement that distinguishes this machine
-			type is disk space, which is a function of the amount of
-			bits imported to <application>cobbler</application>.
-			<note>
-				<title>Note</title>
-				<para>
-					There was a time when Repo machines
-					were able to be created via
-					<application><link linkend="everest-EverestBootstrap">everest-bootstrap</link></application>.
-					This led to several "chicken and the
-					egg" sorts of problems.  For this
-					reason the method for provisioning Repo machines was
-					switched to RPM.
-				</para>
-			</note>
+			Appliances in the &PRODUCT; environment are machines
+			that enable the &PRODUCT; tooling.
 		</para>
 
-		<section>
-			<title>Features</title>
+		<section id="everest-HostMachineType">
+			<title>Cloud</title>
+			<para>
+				The Host machine type is used to host Xen
+				guests in the &PRODUCT; environment.  
+			</para>
 			<para>
+				Features:
 				<itemizedlist>
-					<listitem><para>Cobbler for all RPM/provisioning</para></listitem>
-					<listitem><para>A Puppetmaster for all configuration</para></listitem>
-					<listitem><para>Bare git repos for all content located under /pub/git</para></listitem>
-					<listitem><para>GitWeb running on http://[hostname]/git/gitweb.cgi</para></listitem>
-					<listitem><para>Everestd running http://[hostname]:8106/nodes.html</para></listitem>
+					<listitem><para>Xen virtualization</para></listitem>
+					<listitem><para>&PRODUCT; tooling</para></listitem>
 				</itemizedlist>
 			</para>
 		</section>
 
-		<section>
-			<title>Repo machine cloning</title>
+		<section id="everest-RepoMachineType">
+			<title>Repo</title>
 			<para>
-				The state of a particular Repo machine can be
-				described by the content stored under
-				/var/www/cobbler and /pub/git.  Cloning a
-				particular Repo is really just a matter of
-				getting the correct bit from those locations
-				onto a new Repo machine.  
+				Repo machines are the center of development in the
+				&PRODUCT; environment.  In a nutshell they are the
+				self-contained provisioning, configuration and artifact
+				store.  For this reason &PRODUCT; machines types are
+				generally not considered volatile. 
 			</para>
 
 			<para>
-				Aside from the simple bit replicatation that
-				must be performed there are also a few
-				"one-off" things that need to happen.  This
-				involves:
-				<itemizedlist>
-					<listitem>
-						<para>
-							Getting the
-							puppet modules
-							to the location
-							where the
-							<application>puppetmaster</application>
-							can see them.  
-						</para>
-					</listitem>
-					<listitem>
-						<para>
-							Setting up
-							commit hooks
-							for the puppet
-							module git
-							repositories.
-						</para>
-					</listitem>
-					<listitem>
-						<para>
-							Sets up commit
-							hook for the
-							&PRODUCT;
-							documentation.
-						</para>
-					</listitem>
-				</itemizedlist>
+				As all other machine types it is designed to work as
+				both a "baremetal" and virtual machine.  The main
+				resource requirement that distinguishes this machine
+				type is disk space, which is a function of the amount of
+				bits imported to <application>cobbler</application>.
+				<note>
+					<title>Note</title>
+					<para>
+						There was a time when Repo
+						machines were able to be
+						created via <application><link
+								linkend="everest-EverestBootstrap">everest-bootstrap</link>
+						</application>.  This led to
+						several "chicken and the egg"
+						sorts of problems.  For this
+						reason the method for
+						provisioning Repo machines was
+						switched to RPM.
+					</para>
+				</note>
 			</para>
 
-			<para>
-				See the <link
-					linkend="everest-RepoMachineBootstrapping">cookbook</link>
-				for more information.
-			</para>
-		</section>
+			<section>
+				<title>Features</title>
+				<para>
+					<itemizedlist>
+						<listitem>
+							<para>
+								Cobbler for all RPM/provisioning
+							</para>
+						</listitem>
+						<listitem>
+							<para>
+								A Puppetmaster for all configuration
+							</para>
+						</listitem>
+						<listitem>
+							<para>
+								Bare git repos
+								for all content
+								located under
+								/pub/git
+							</para>
+						</listitem>
+						<listitem>
+							<para>
+								GitWeb running
+								on
+								http://[hostname]/git/gitweb.cgi
+							</para>
+						</listitem>
+						<listitem>
+							<para>
+								Everestd
+								running
+								http://[hostname]:8106/nodes.html
+							</para>
+						</listitem>
+					</itemizedlist>
+				</para>
+			</section>
 
-		<section>
-			<title>Repo machine customization</title>
-			<para>
-				The &REPORPM; is designed to get users up and
-				running with a known working configuration.
-				There are certain custom settings users of
-				&PRODUCT; will need to configure for their
-				environment.  The two most common needs for
-				customization are adding new Everest machine
-				types to <link
-					linkend="everestd-configuration">everestd</link>
-				and any extra
-				<application>cobbler</application>
-				customization.
-			</para>
+			<section>
+				<title>Repo machine cloning</title>
+				<para>
+					The state of a particular Repo machine can be
+					described by the content stored under
+					/var/www/cobbler and /pub/git.  Cloning a
+					particular Repo is really just a matter of
+					getting the correct bit from those locations
+					onto a new Repo machine.  
+				</para>
 
-			<para>
-				How these customizations are managed is at the
-				user's discretion. However, since the Repo
-				machine is already controlled by
-				<application>puppet</application> it makes
-				sense in many cases to simply use it for this
-				as well.  The only thing required to make this
-				happen is to describe the configuration details
-				in a <application>puppet</application> class
-				called <emphasis>everest::repo</emphasis>.  
-			<important>
-				<title>Important</title>
 				<para>
-					<emphasis>everest::repo</emphasis> is
-					implemented in the module that ships
-					with the &REPORPM; and can be extended
-					by this redefinition process.  Just
-					make sure the class is on the module
-					path.
+					Aside from the simple bit replicatation that
+					must be performed there are also a few
+					"one-off" things that need to happen.  This
+					involves:
+					<itemizedlist>
+						<listitem>
+							<para>
+								Getting the
+								puppet modules
+								to the location
+								where the
+								<application>puppetmaster</application>
+								can see them.  
+							</para>
+						</listitem>
+						<listitem>
+							<para>
+								Setting up
+								commit hooks
+								for the puppet
+								module git
+								repositories.
+							</para>
+						</listitem>
+						<listitem>
+							<para>
+								Sets up commit
+								hook for the
+								&PRODUCT;
+								documentation.
+							</para>
+						</listitem>
+					</itemizedlist>
 				</para>
-			</important>
-			</para>
+
+				<para>
+					See the <link
+						linkend="everest-RepoMachineBootstrapping">cookbook</link>
+					for more information.
+				</para>
+			</section>
+
+			<section id="everest-repo-machine-customization">
+				<title>Repo machine customization</title>
+				<para>
+					The &REPORPM; is designed to get users up and
+					running with a known working configuration.
+					There are certain custom settings users of
+					&PRODUCT; will need to configure for their
+					environment.  The two most common needs for
+					customization are adding new Everest machine
+					types to <link
+						linkend="everestd-configuration">everestd</link>
+					and any extra
+					<application>cobbler</application>
+					customization.
+				</para>
+
+				<para>
+					How these customizations are managed is at the
+					user's discretion. However, since the Repo
+					machine is already controlled by
+					<application>puppet</application> it makes
+					sense in many cases to simply use it for this
+					as well.  The only thing required to make this
+					happen is to describe the configuration details
+					in a <application>puppet</application> class
+					called <emphasis>everest::repo</emphasis>.  
+					<important>
+						<title>Important</title>
+						<para>
+							<emphasis>everest::repo</emphasis> is
+							implemented in the module that ships
+							with the &REPORPM; and can be extended
+							by this redefinition process.  Just
+							make sure the class is on the module
+							path.
+						</para>
+					</important>
+				</para>
+			</section>
 		</section>
 	</section>
 
-	<section id="everest-JbossDevMachineType">
-		<title>Jboss Development machine</title>
+	<section id="everest-custom-types">
+		<title>Custom Machine Types</title>
 		<para>
-                     The Jboss Development is a nice example of a how machines in the &PRODUCT; environment can be aggregated.  Standalone machine types are specified in Puppet and they can be woven together to solve a particular problem.  
+			A custom machine type in the &PRODUCT; environment can be
+			roughly described as a collection of known working
+			<application>puppet</application> classes matched with an
+			operating system. The list of machines that can be provisioned
+			from a given Repo machine can be found when using the <link
+				linkend="everest-EverestBootstrap">everest-bootstrap</link>
+			wizard or the <link linkend="everest-Everestd">everestd</link>
+			UI.  
+
 			<important>
 				<title>Important</title>
 				<para>
-					The ability to "weave" machine types
-					together in interesting ways does not
-					happen automatically.  For complex
-					configurations it takes an intentional
-					effort to make this work since there
-					are many competing factors (overlapping
-					configuration files, RPM conflicts,
-					etc).  This "feature" is vital for
-					collaboration with large organizations.
-					Production Operations can deploy
-					scalable standalone machines while
-					Development teams can group several
-					machines together for simplicity.  All
-					this can happen while sharing the logic
-					used to configure complex systems.
+					From Puppet's point of view these "types" are
+					not bound to any particular OS version.  You
+					choose the OS with <link
+						linkend="everest-EverestBootstrap">
+						everest-bootstrap</link> or when <link
+						linkend="everest-Koan">provisioning
+						directly with Koan</link>. This allows
+					users to test out different OS and applications
+					versions using the same Puppet code.
 				</para>
 			</important>
 		</para>
-		<para>
-			Features:
-			<itemizedlist>
-				<listitem><para>Useable as a bare-metal machine or VM</para></listitem>
-				<listitem><para>Nomachine for desktop remoting</para></listitem>
-				<listitem><para>Sun JDK</para></listitem>
-				<listitem><para>Apache proxy using mod_proxy_ajp</para></listitem>
-				<listitem><para>Jboss EAP</para></listitem>
-				<listitem><para>Jboss ESB</para></listitem>
-				<listitem><para>Mysql DB for all Jboss datastores</para></listitem>
-				<listitem><para>Build tooling (Eclipse, Git, Maven)</para></listitem>
-			</itemizedlist>
-		</para>
-	</section>
 
+		<section id="everest-CreatingCustomMachineTypes">
+			<title>Creating custom machine types</title>
+			<para>
+				See the <link
+					linkend="everest-AddMachineType">cookbook</link>
+				for more information.
+			</para>
+		</section>
+	</section>
 </chapter>
-
diff --git a/everest-docs/everest-docs-1.0.0/en-US/Preface.xml b/everest-docs/everest-docs-1.0.0/en-US/Preface.xml
index 7f2b667..b552ea5 100644
--- a/everest-docs/everest-docs-1.0.0/en-US/Preface.xml
+++ b/everest-docs/everest-docs-1.0.0/en-US/Preface.xml
@@ -5,6 +5,21 @@
 <preface id="everest-Preface">
 	<title>Preface</title>
 	<para>
+			The ability to "weave" machine types
+			together in interesting ways does not
+			happen automatically.  For complex
+			configurations it takes an intentional
+			effort to make this work since there
+			are many competing factors (overlapping
+			configuration files, RPM conflicts,
+			etc).  This "feature" is vital for
+			collaboration with large organizations.
+			Production Operations can deploy
+			scalable standalone machines while
+			Development teams can group several
+			machines together for simplicity.  All
+			this can happen while sharing the logic
+			used to configure complex systems.
 	</para>
 	<xi:include href="Common_Content/Conventions.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
 	<xi:include href="Feedback.xml" xmlns:xi="http://www.w3.org/2001/XInclude">
diff --git a/everest-docs/everest-docs-1.0.0/en-US/Technologies.xml b/everest-docs/everest-docs-1.0.0/en-US/Technologies.xml
index 1f635ac..a56c53f 100644
--- a/everest-docs/everest-docs-1.0.0/en-US/Technologies.xml
+++ b/everest-docs/everest-docs-1.0.0/en-US/Technologies.xml
@@ -3,6 +3,155 @@ V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [ ]>
 
 <chapter id="everest-technologies">
 	<title>Open source technologies used with &PRODUCT;</title>
+
+	<section id="everest-Koan">
+		<title>Koan</title>
+
+		<section id="everest-Koan-Background">
+			<title>Background</title> 
+			<para> 
+				Koan is a tool coming out of Red Hat Emerging
+				Technologies that is used to provision machines from
+				Cobbler servers. Following the unix philosophy it's
+				very simple to use and the man page will tell you
+				everything you need to know. For more information check
+				out the <ulink
+					url="http://cobbler.et.redhat.com/documentation.php">cobbler
+					documentation</ulink>.  
+			</para>
+
+			<note>
+				<title>Note</title>
+				<para>
+					Most provisioning with the &PRODUCT; tools
+					can be done without having to work with Koan
+					directly.  However, a good understanding of its
+					basic operation is useful for advanced usage of
+					the &PRODUCT; tooling.
+				</para>
+			</note>
+		</section>
+
+		<section id="everest-Koan-Installation">
+			<title>Installation</title> 
+			<para> RPMs exist for both Fedora and RHEL (through <ulink
+					url="http://fedoraproject.org/wiki/EPEL">EPEL</ulink>).
+				If your repositories are configured correctly you should simply
+				be able to <userinput>yum install koan</userinput>. Koan doesn't have many
+				dependencies so if you don't feel like adding the EPEL repo to
+				your RHEL machine you can simply install the RPM.  
+			</para>
+
+			<para> Once installed you should test your installation against a
+				cobbler server.  
+				<screen>
+koan -s everest-repo.usersys.redhat.com --list-profiles
+koan -s everest-repo.usersys.redhat.com --list-systems
+				</screen> 
+			</para>
+		</section>
+
+		<section id="everest-Koan-GuestProvisioning">
+			<title>Guest Provisioning</title>
+			<note>
+				<title>Note</title>
+				<para>
+					<application>everest-bootstrap</application>
+					now wraps <application>Koan</application> for provisioning virtual machines.
+					This is only included for advanced use cases.  
+				</para>
+			</note>
+			<screen> 
+koan -s everest-repo.usersys.redhat.com --virt --virt-type=xenpv --virt-path=HostVolGroup00 --system=[your hostname]
+			</screen>
+
+			<para>
+				Here the most important part is obviously the
+				<emphasis>--virt</emphasis> flag. If you pass in a
+				Volume Group name for <emphasis>--virt-path</emphasis>
+				koan will automatically create (or reuse) a logical
+				volume in the format of
+				<literal>[name]-disk0</literal>. With cobbler much of the
+				configuration lies on the server side (the memory, size
+				of the logical volume, etc). If you have different
+				requirements you can either create a new profile for
+				cobbler or you can use the <link
+					linkend="everest-Tooling">tooling</link> that
+				makes up &PRODUCT; achieve the desired results. 
+			</para>
+
+			<tip>
+				<title>Tip</title>
+				<para>
+					One trick to creating a quest with a larger logical
+					volume that a cobbler profile specifies is to simply
+					create it by hand and specify the size you desire. Koan
+					will simply reuse that logical volume.	
+				</para>
+			</tip>
+		</section>
+
+		<section>
+			<title>Watching the VM</title>
+			<para>
+				During the kickstart provisioning process you can
+				connect to the virtual framebuffer which is accessible
+				through VNC. It's only available locally so don't try
+				and connect from another machine. From the Xen host you
+				should be able to use:
+				<screen> 
+ssh -X root@YourXenHost.usersys.redhat.com
+vncviewer localhost:5900
+				</screen>
+			</para>
+
+			<para>
+				The port may vary according to how many guests you have
+				running. To find out which ports are being used:
+				<screen> 
+# If you are using RHEL5 less than U2
+netstat -nlp | grep vnc
+
+#otherwise
+netstat -nlp | grep qemu-dm
+				</screen>
+			</para>
+		</section>
+
+		<section>
+			<title>Cleaning Up</title>
+			<para>
+				If you would like to remove work performed by koan:
+				<itemizedlist>
+					<listitem>
+						<para>
+							Remove the Xen configuration
+							for the guest under
+							<filename>/etc/xen</filename>
+						</para>
+					</listitem>
+					<listitem>
+						<para>
+							Remove the file or logical
+							volume that backs your guest.
+						</para>
+					</listitem>
+				</itemizedlist>
+			</para>
+		</section>
+
+		<section>
+			<title>Known Issues</title>
+			<para>
+				Provisioning will fail if a config file under
+				<filename>/etc/xen</filename> has the same name as the
+				machine you are trying to create.  The error message is
+				fairly cryptic and says something like "machine already
+				exists".  The fix is to simply remove the config file.
+			</para>
+		</section>
+
+	</section>
 	<section id="everest-Tooling-LVM">
 		<title>LVM</title>
 		<para>
diff --git a/everest-docs/everest-docs-1.0.0/en-US/everest.xml b/everest-docs/everest-docs-1.0.0/en-US/everest.xml
index 5e7ca2b..438a339 100644
--- a/everest-docs/everest-docs-1.0.0/en-US/everest.xml
+++ b/everest-docs/everest-docs-1.0.0/en-US/everest.xml
@@ -5,9 +5,8 @@
 <book>
 	<xi:include href="Book_Info.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
 	<xi:include href="Preface.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
-	<xi:include href="GettingStarted.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
 	<xi:include href="MachineTypes.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
-	<xi:include href="Koan.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+	<xi:include href="GettingStarted.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
 	<xi:include href="Tooling.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
 	<xi:include href="Technologies.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
 	<xi:include href="Cookbook.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />