diff --git a/doc/Clusters_from_Scratch/en-US/Ap-Cman.xml b/doc/Clusters_from_Scratch/en-US/Ap-Cman.xml
index b090337cca..af27515cab 100644
--- a/doc/Clusters_from_Scratch/en-US/Ap-Cman.xml
+++ b/doc/Clusters_from_Scratch/en-US/Ap-Cman.xml
@@ -1,131 +1,125 @@
 <?xml version='1.0' encoding='utf-8' ?>
 <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
 <!ENTITY % BOOK_ENTITIES SYSTEM "Clusters_from_Scratch.ent">
 %BOOK_ENTITIES;
 ]>
 <appendix id="ap-cman">
   <title>Using CMAN for Cluster Membership and Quorum</title>
 	
   <section>
     <title>Background</title>
     <para>
       <ulink url="http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Cluster_Suite_Overview/index.html#s2-clumembership-overview-CSO">CMAN v3</ulink> is a Corsync plugin that monitors the names and number of active cluster nodes in order to deliver membership and quorum information to clients (such as the Pacemaker daemons).
     </para>
     <para>
       In a traditional Corosync-Pacemaker cluster, a Pacemaker plugin is loaded to provide membership and quorum information. 
       The motivation for wanting to use CMAN for this instead, is to ensure all elements of the cluster stack are making decisions based on the same membership and quorum data.
       <footnote>
 	<para>
 	  A failure to do this can lead to what is called <literal>internal split-brain</literal> - a situation where different parts of the stack disagree about whether some nodes are alive or dead - which quickly leads to unnecssary down-time and/or data corruption.
 	</para>
       </footnote>
     </para>
     <para>
       CMAN has been around longer than Pacemaker and is part of the Red Hat cluster stack, so it is available and supported by many distributions and other pieces of software (such as OCFS2 and GFS2).
       For this reason it makes sense to support it.
     </para>
   </section>
   <section>
     <title>Adding CMAN Support</title>
       <warning>
 	<para>
 	  Be sure to disable the Pacemaker plugin before continuing with this section.
 	  In most cases, this can be achieved by removing <filename>/etc/corosync/service.d/pcmk</filename> and stopping Corosync.
 	</para>
       </warning>
     <section>
       <title>Adding CMAN Support - cluster.conf</title>
       <para>
 	The preferred approach for enabling CMAN is to configure <filename>cluster.conf</filename> and use the <filename>/etc/init.d/cman</filename> script to start Corosync.
 	Its far easier to maintain and start automatically starts the necessary pieces for using GFS2.
       </para>
       <para>
 	You can find some documentation on
 	<ulink url="http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Cluster_Administration/s1-creating-cluster-cli-CA.html">Installing CMAN and Creating a Basic Cluster Configuration File</ulink>
 	at the Red Hat website.
 	However please ignore the parts about <literal>Fencing</literal>, <literal>Failover Domains</literal>, or <literal>HA Services</literal> and anything to do with <literal>rgmanager</literal> and <literal>fenced</literal>.
 	All these continue to be handled by Pacemaker in the normal manner.
       </para>
       <example>
 	<title>Sample cluster.conf for a two-node cluster</title>
 	<programlisting>
 	<![CDATA[
 <?xml version="1.0"?>
 <cluster config_version="1" name="beekhof">
-  <fence_daemon clean_start="0" post_fail_delay="0" post_join_delay="3"/>
+  <logging debug="true"/>
   <clusternodes>
-    <clusternode name="pcmk-1" nodeid="1">
-      <fence/>
-    </clusternode>
-    <clusternode name="pcmk-2" nodeid="2">
-      <fence/>
-    </clusternode>
+    <clusternode name="pcmk-1" nodeid="1"/>
+    <clusternode name="pcmk-2" nodeid="2"/>
   </clusternodes>
   <cman two_node="1" expected_votes="1"/>
-  <fencedevices/>
-  <rm/>
 </cluster>
 	]]>
 	</programlisting>
       </example>
     </section>
     <section>
       <title>Adding CMAN Support - corosync.conf</title>
       <para>
 	The alternative is to add the necessary cman configuration elements to <filename>corosync.conf</filename>.
 	We recommend you place these directives in <filename>/etc/corosync/service.d/cman</filename> as they will differ between machines.
       </para>
       <para>
 	If you choose this approach, you would continue to start and stop Corosync with it's init script as previously described in this document.
       </para>
       
       <example>
 	<title>Sample corosync.conf extensions for a two-node cluster</title>
 	<programlisting>
 [root@pcmk-1 ~]# <userinput>cat &lt;&lt;-END &gt;&gt;/etc/corosync/service.d/cman</userinput>
 cluster {
     name: beekhof
 
     clusternodes {
             clusternode {
                     votes: 1
                     nodeid: 1
                     name: pcmk-1
             }
             clusternode {
                     votes: 1
                     nodeid: 2
                     name: pcmk-2
             }
     }
     cman {
             expected_votes: 2
             cluster_id: 123
             nodename: `uname -n`
             two_node: 1
             max_queued: 10
     }
 }
 
 service {
     name: corosync_cman
     ver: 0
 }
 
 quorum {
     provider: quorum_cman
 }
 END
 	</programlisting>
       </example>
 
       <warning>
 	<para>
 	  Verify that <literal>nodename</literal> was set appropriately on each host.
 	</para>
       </warning>
 
     </section>
   </section>
 </appendix>