Reformat so columns line up in 'mclu list' output.
[mclu.git] / README
diff --git a/README b/README
index 65aa631..8e958f4 100644 (file)
--- a/README
+++ b/README
@@ -4,21 +4,22 @@ The key features:
 
  - Entirely command line driven.
 
- - No required dependencies except libvirt and ssh.
-
- - Only designed for tiny clusters (up to around 10 hosts).
+ - No required dependencies except ansible (on the client only),
+   libvirt and ssh.
 
  - Nothing to install on the nodes except libvirtd and sshd.
 
- - Single, simple configuration file.
+ - Only designed for small clusters (up to around 10-20 hosts).
+
+ - Simple configuration.
 
 Example commands
 ----------------------------------------------------------------------
 
    mclu status                   Display status of the cluster
    mclu list                     List all virtual machines on the cluster
-   mclu wake ham0                Wake up node 'ham0' in the cluster
-   mclu shutdown ham0            Shut down node 'ham0' in the cluster
+   mclu on ham0                  Switch on (wake-on-LAN) node 'ham0'
+   mclu off ham0                 Power off node 'ham0' in the cluster
    mclu start ham0:vm            Start vm on node 'ham0'
    mclu stop ham0:*              Stop all VMs on node 'ham0'
    mclu migrate *:* ham2:        Live migrate all VMs to 'ham2'
@@ -28,67 +29,16 @@ Example commands
    mclu info                     Print general configuration information
    mclu --help                   Print help on all commands
 
+Since the mclu cluster is based on an ansible "hosts group", you can
+also issue ansible commands, eg:
+
+   ansible cluster -u root -a "yum -y update"   Update all nodes in the cluster
+   ansible cluster -m ping                      Ping all nodes
+
 Configuration notes
 ----------------------------------------------------------------------
 
-mclu is based around the idea that you have a small collection of
-fairly similar "nodes".  Ideally they would be identical nodes, if you
-want live migration to work seamlessly, but they don't have to be.
-
-Here is a picture of the cluster that I run mclu on:
-http://rwmj.wordpress.com/2014/04/28/caseless-virtualization-cluster-part-5/#content
-
-The nodes can be up or down.  mclu deals transparently with nodes
-being switched off.  If you configure wake-on-LAN (usually a BIOS
-setting) then mclu will be able to wake up nodes.
-
-There is also one "control" node, which could be your laptop or could
-be one of the cluster nodes.  This is where you run the 'mclu'
-command, and also where the single configuration file is located
-(mclu.conf, usually located in /etc/mclu).  The guest libvirt XML
-files are also stored on the control node (usually /etc/mclu/xmls).
-
-Each node must be accessible from the control node over ssh.  Each
-node must be running the libvirt daemon (libvirtd).
-
-mclu uses a mix of ssh commands and remote libvirt to manage the
-nodes.  You should configure ssh so it can access the nodes without
-needing passwords (eg. using ssh-agent).  If you use the default
-libvirt URI (see config file) then you also need to set up
-passwordless root ssh access to the nodes; there are other ways to
-configure this, eg. opening the libvirtd port on each node, but they
-are probably not as secure.
-
-Each node, including the control node, must have access to shared
-storage where the guest disk images are stored.  The easiest way to do
-this is to export /var/lib/libvirt/images from one machine and
-NFS-mount it on all the nodes (and also to have a nice fast network).
-Cluster filesystems are another possibility.  mclu does NOT support
-non-shared storage nor storage migration.
-
-Guests run on a single node at a time.  You can list/start/stop/
-migrate them using mclu.  The requirement for a guest to be running on
-a single node may be enforced if you run libvirt sanlock or virtlockd.
-This requires further configuration, see:
-http://libvirt.org/locking.html
-https://rwmj.wordpress.com/2014/05/08/setting-up-virtlockd-on-nfs/#content
-
-If sanlock/virtlockd is not running then mclu will try its best not to
-have the guest running in two places at once (if it happens, this will
-cause permanent disk corruption in the guest).
-
-For guest live migration to work transparently, you will probably want
-to configure libvirt bridged networking and open firewall ports
-49152-49215 on every node.
-
-Bridged networking means that each guest appears as a local machine on
-your network, and if it migrates then network connections will not be
-interrupted.  See:
-http://wiki.libvirt.org/page/Networking#Bridged_networking_.28aka_.22shared_physical_device.22.29
-
-The firewall ports have to be opened because libvirt cannot (yet?)  do
-fully managed migration over two SSH connections (even though the
-documentation says it can).  Hopefully they will fix this soon.
+See `CONFIGURATION'.
 
 Dependencies
 ----------------------------------------------------------------------
@@ -114,6 +64,9 @@ To run without installing:
 
  - Edit the configuration file (mclu.conf).
 
+ - Add the hosts group (usually called '[cluster]') to /etc/ansible/hosts.
+   You can set $ANSIBLE_HOSTS to change the location of this file.
+
  - Run commands such as:
 
    ./run status
@@ -125,6 +78,8 @@ To install:
 
  - Edit the configuration file (/etc/mclu/mclu.conf).
 
+ - Add the hosts group (usually called '[cluster]') to /etc/ansible/hosts.
+
  - Run commands such as:
 
    mclu status