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
the instance sees the same virtual drive in all cases, the node-level
configuration varies between them.
-There are four disk templates you can choose from:
+There are five disk templates you can choose from:
diskless
The instance has no disks. Only used for special purpose operating
to obtain a highly available instance that can be failed over to a
remote node should the primary one fail.
+rbd
+ The instance will use Volumes inside a RADOS cluster as backend for its
+ disks. It will access them using the RADOS block device (RBD).
+
IAllocator
~~~~~~~~~~
The above command has the minimum required options; other options you
can give include, among others:
-- The memory size (``-B memory``)
+- The maximum/minimum memory size (``-B maxmem``, ``-B minmem``)
+ (``-B memory`` can be used to specify only one size)
- The number of virtual CPUs (``-B vcpus``)
gnt-instance remove INSTANCE_NAME
+.. _instance-startup-label:
+
Startup/shutdown
~~~~~~~~~~~~~~~~
gnt-instance startup INSTANCE_NAME
-While the command to stop one is::
+Ganeti will start an instance with up to its maximum instance memory. If
+not enough memory is available Ganeti will use all the available memory
+down to the instance minumum memory. If not even that amount of memory
+is free Ganeti will refuse to start the instance.
+
+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 --offline 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
status), etc. This is harder to parse and is more expensive than the
list operation, but returns much more detailed information.
+Changing an instance's runtime memory
++++++++++++++++++++++++++++++++++++++
+
+Ganeti will always make sure an instance has a value between its maximum
+and its minimum memory available as runtime memory. As of version 2.6
+Ganeti will only choose a size different than the maximum size when
+starting up, failing over, or migrating an instance on a node with less
+than the maximum memory available. It won't resize other instances in
+order to free up space for an instance.
+
+If you find that you need more memory on a node any instance can be
+manually resized without downtime, with the command::
+
+ gnt-instance modify -m SIZE INSTANCE_NAME
+
+The same command can also be used to increase the memory available on an
+instance, provided that enough free memory is available on its node, and
+the specified size is not larger than the maximum memory size the
+instance had when it was first booted (an instance will be unable to see
+new memory above the maximum that was specified to the hypervisor at its
+boot time, if it needs to grow further a reboot becomes necessary).
Export/Import
+++++++++++++
That's it. After the command completes the secondary node is now the
primary, and vice-versa.
+The instance will be started with an amount of memory between its
+``maxmem`` and its ``minmem`` value, depending on the free memory on its
+target node, or the operation will fail if that's not possible. See
+:ref:`instance-startup-label` for details.
+
+If the instance's disk template is of type rbd, then you can specify
+the target node (which can be any node) explicitly, or specify an
+iallocator plugin. If you omit both, the default iallocator will be
+used to determine the target node::
+
+ gnt-instance failover -n TARGET_NODE INSTANCE_NAME
+
Live migrating an instance
~~~~~~~~~~~~~~~~~~~~~~~~~~
long the migration will take. In any case, for both KVM and Xen
hypervisors, the migration will be transparent to the instance.
+If the destination node has less memory than the instance's current
+runtime memory, but at least the instance's minimum memory available
+Ganeti will automatically reduce the instance runtime memory before
+migrating it, unless the ``--no-runtime-changes`` option is passed, in
+which case the target node should have at least the instance's current
+runtime memory free.
+
+If the instance's disk template is of type rbd, then you can specify
+the target node (which can be any node) explicitly, or specify an
+iallocator plugin. If you omit both, the default iallocator will be
+used to determine the target node::
+
+ gnt-instance migrate -n TARGET_NODE INSTANCE_NAME
+
Moving an instance (offline)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
6. Remove the ganeti state directory (``rm -rf /var/lib/ganeti/*``),
replacing the path with the correct path for your installation.
+7. If using RBD, run ``rbd unmap /dev/rbdN`` to unmap the RBD disks.
+ Then remove the RBD disk images used by Ganeti, identified by their
+ UUIDs (``rbd rm uuid.rbd.diskN``).
+
On the master node, remove the cluster from the master-netdev (usually
``xen-br0`` for bridged mode, otherwise ``eth0`` or similar), by running
``ip a del $clusterip/32 dev xen-br0`` (use the correct cluster ip and
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
--------------------------
projects / ganeti-local / blobdiff