Add job result descriptions to RAPI documentation

[ganeti-local] / doc / walkthrough.rst

diff --git a/doc/walkthrough.rst b/doc/walkthrough.rst
index a173357..0f26cff 100644 (file)
--- a/doc/walkthrough.rst
+++ b/doc/walkthrough.rst
@@ -104,8 +104,8 @@ And let's check that we have a valid OS::
   debootstrap
   node1#
 
-Running a burnin
-----------------
+Running a burn-in
+-----------------
 
 Now that the cluster is created, it is time to check that the hardware
 works correctly, that the hypervisor can actually create instances,
@@ -263,8 +263,8 @@ guide. Similar output lines are replaced with ``…`` in the below log::
       …
   node1#
 
-You can see in the above what operations the burnin does. Ideally, the
-burnin log would proceed successfully through all the steps and end
+You can see in the above what operations the burn-in does. Ideally, the
+burn-in log would proceed successfully through all the steps and end
 cleanly, without throwing errors.
 
 Instance operations
@@ -478,7 +478,8 @@ redundancy::
       - initrd_path: default ()
     Hardware:
       - VCPUs: 1
-      - memory: 128MiB
+      - maxmem: 256MiB
+      - minmem: 512MiB
       - NICs:
         - nic/0: MAC: aa:00:00:78:da:63, IP: None, mode: bridged, link: xen-br0
     Disks:
@@ -584,7 +585,7 @@ reused. Re-adding it is simple::
   Mon Oct 26 05:27:39 2009  - INFO: Readding a node, the offline/drained flags were reset
   Mon Oct 26 05:27:39 2009  - INFO: Node will be a master candidate
 
-And is now working again::
+And it is now working again::
 
   node1# gnt-node list
   Node  DTotal DFree MTotal MNode MFree Pinst Sinst
@@ -592,7 +593,7 @@ And is now working again::
   node2   1.3T  1.3T  32.0G  1.0G 30.4G     1     3
   node3   1.3T  1.3T  32.0G  1.0G 30.4G     0     0
 
-.. note:: If you have the Ganeti has been built with the htools
+.. note:: If Ganeti has been built with the htools
    component enabled, you can shuffle the instances around to have a
    better use of the nodes.
 
@@ -857,7 +858,8 @@ with 12GB of RAM (numbers chosen so that we run out of memory)::
 
   node1# gnt-instance modify -B memory=4G instance1
   Modified instance instance1
-   - be/memory -> 4096
+   - be/maxmem -> 4096
+   - be/minmem -> 4096
   Please don't forget that these parameters take effect only at the next start of the instance.
   node1# gnt-instance modify …
 
@@ -915,8 +917,15 @@ solve this, you have a number of options:
 
 - try to manually move instances around (but this can become complicated
   for any non-trivial cluster)
-- try to reduce memory of some instances to accommodate the available
-  node memory
+- try to reduce the minimum memory of some instances on the source node
+  of the N+1 failure (in the example above ``node1``): this will allow
+  it to start and be failed over/migrated with less than its maximum
+  memory
+- try to reduce the runtime/maximum memory of some instances on the
+  destination node of the N+1 failure (in the example above ``node2``)
+  to create additional available node memory (check the :doc:`admin`
+  guide for what Ganeti will and won't automatically do in regards to
+  instance runtime memory modification)
 - if Ganeti has been built with the htools package enabled, you can run
   the ``hbal`` tool which will try to compute an automated cluster
   solution that complies with the N+1 rule