gnt-instance modify -m|--runtime-memory

[ganeti-local] / doc / admin.rst

diff --git a/doc/admin.rst b/doc/admin.rst
index 665c0e6..429087c 100644 (file)
--- a/doc/admin.rst
+++ b/doc/admin.rst
@@ -72,7 +72,9 @@ Depending on the role, each node will run a set of daemons:
   this node's hardware resources; it runs on all nodes which are in a
   cluster
 - the :command:`ganeti-confd` daemon (Ganeti 2.1+) which runs on all
-  nodes, but is only functional on master candidate nodes
+  nodes, but is only functional on master candidate nodes; this daemon
+  can be disabled at configuration time if you don't need its
+  functionality
 - the :command:`ganeti-rapi` daemon which runs on the master node and
   offers an HTTP-based API for the cluster
 - the :command:`ganeti-masterd` daemon which runs on the master node and
@@ -285,10 +287,22 @@ manually start one which is currently stopped you can run::
 
   gnt-instance startup INSTANCE_NAME
 
-While the command to stop one is::
+Note, that this will not work when an instance is in a permanently
+stopped state ``offline``. In this case, you will first have to
+put it back to online mode by running::
+
+  gnt-instance modify --online INSTANCE_NAME
+
+The command to stop the running instance is::
 
   gnt-instance shutdown INSTANCE_NAME
 
+If you want to shut the instance down more permanently, so that it
+does not require dynamically allocated resources (memory and vcpus),
+after shutting down an instance, execute the following::
+
+  gnt-instance modify --ofline INSTANCE_NAME
+
 .. warning:: Do not use the Xen or KVM commands directly to stop
    instances. If you run for example ``xm shutdown`` or ``xm destroy``
    on an instance Ganeti will automatically restart it (via
@@ -577,7 +591,7 @@ For all three cases, the ``replace-disks`` operation can be used::
 
 Since the process involves copying all data from the working node to the
 target node, it will take a while, depending on the instance's disk
-size, node I/O system and network speed. But it is (baring any network
+size, node I/O system and network speed. But it is (barring any network
 interruption) completely transparent for the instance.
 
 Re-creating disks for non-redundant instances
@@ -1344,16 +1358,14 @@ But not one that has already started execution::
 There are two queues for jobs: the *current* and the *archive*
 queue. Jobs are initially submitted to the current queue, and they stay
 in that queue until they have finished execution (either successfully or
-not). At that point, they can be moved into the archive queue, and the
-ganeti-watcher script will do this automatically after 6 hours. The
-ganeti-cleaner script will remove the jobs from the archive directory
+not). At that point, they can be moved into the archive queue using e.g.
+``gnt-job autoarchive all``. The ``ganeti-watcher`` script will do this
+automatically 6 hours after a job is finished. The ``ganeti-cleaner``
+script will then remove archived the jobs from the archive directory
 after three weeks.
 
-Note that only jobs in the current queue can be viewed via the list and
-info commands; Ganeti itself doesn't examine the archive directory. If
-you need to see an older job, either move the file manually in the
-top-level queue directory, or look at its contents (it's a
-JSON-formatted file).
+Note that ``gnt-job list`` only shows jobs in the current queue.
+Archived jobs can be viewed using ``gnt-job info <id>``.
 
 Special Ganeti deployments
 --------------------------