docs: fixes in the architecture sections

docs/architecture.rst

 Architecture
 ============
 
+Overview
+^^^^^^^^
+
+snf-image is a Ganeti OS definition. This means that Ganeti provisions a new
+disk (block device) and passes it to snf-image. Then, snf-image is responsible
+to deploy an Image on that disk. If snf-image returns successfully, Ganeti will
+then spawn a VM with that disk as its primary disk.
+
+Thus, snf-image is responsible for two (2) things, which are executed in two
+separate steps:
+
+| 1. Fill the newly provisioned disk with Image data
+| 2. Customize the Image accordingly
+
+For (1), snf-image can fetch the Image from a number of backends, as we describe
+later. For (2) snf-image spawns a helper VM and runs a number of configuration
+tasks inside the isolated environment. Once the last task returns successfully,
+the helper VM ceases and snf-image returns the newly configured disk to Ganeti.
+
+The whole procedure is configurable via OS interface parameters, that can be
+passed to snf-image from the Ganeti command line or RAPI.
+
 snf-image is split in two components: The main program running on the Ganeti
-host with full root privilege (*snf-image* previously *snf-image-host*) and a
+host with full root privilege (*snf-image*, previously *snf-image-host*) and a
 part running inside an unprivileged helper VM (*snf-image-helper*).
 
+We describe each part in the following sections:
+
 snf-image
 ^^^^^^^^^
 
 This part implements the Ganeti OS interface. It extracts the Image onto the
 Ganeti-provided block device, using streaming block I/O (dd with oflag=direct),
-then passes control to snf-image-helper running inside a helper VM. The helper
-VM is created using KVM, runs as an unprivileged user, nobody by default.
+then spawns a helper VM, and passes control to snf-image-helper running inside
+that helper VM. The helper VM is created using either KVM or XEN depending on
+the supported hypervisor as dictated by Ganeti. It runs as an unprivileged
+user.
 
 There is no restriction on the distribution running inside the helper VM, as
 long as it executes the snf-image-helper component automatically upon bootup.
 The snf-image-update-helper script is provided with snf-image to automate the
 creation of a helper VM image based on Debian Stable, using multistrap.
 
-The snf-image-helper component is spawned inside a specific hardware
-environment:
+The snf-image-helper component runs inside a specific environment, which is
+created and ensured by snf-image:
 
  * The VM features a virtual floppy, containing an ext2 filesystem with all
    parameters needed for image customization.
- * The hard disk of the VM being deployed is accessible as the first virtio
-   hard disk.
+ * The hard disk provided by Ganeti that we want to deploy and customize is
+   accessible as the first virtio hard disk.
  * All kernel/console output is redirected to the first virtual serial console,
    and eventually finds its way into the OS definition log files that Ganeti
    maintains.
  * The helper VM is expected to output "SUCCESS" to its second serial port if
    image customization was successful inside the VM.
- * In any other case, execution of the helper VM or snf-image-helper has
-   failed.
+ * If "SUCCESS" is not returned, snf-image assumes that, execution of the helper
+   VM or snf-image-helper has failed.
  * The helper VM is expected to shutdown automatically once it is done. Its
    execution is time-limited; if it has not terminated after a number of
-   seconds, configurable via /etc/default/snf-image, it is sent a SIGTERM
-   and/or a SIGKILL.
-
-KVM is currently a dependency for snf-image, meaning it is needed to spawn the
-helper VM. There is no restriction on the hypervisor used for the actual Ganeti
-instances. This is not a strict requirement; KVM could be replaced by qemu,
-doing full CPU virtualization without any kernel support for spawning the
-helper VM.
+   seconds, configurable via ``/etc/default/snf-image``, snf-image sends a
+   SIGTERM and/or a SIGKILL to it.
 
 snf-image-helper
 ^^^^^^^^^^^^^^^^
 
-This part runs inside the helper VM and undertakes customization of the VM
-being deployed using a number of hooks, or tasks. The tasks run in an
-environment, specified by rules found in a virtual floppy, placed there by
-*snf-image*. *snf-image-helper* uses runparts to run tasks found under
-*/usr/lib/snf-image-helper/tasks* by default
+This part runs inside the helper VM during bootup and undertakes customization
+of the target disk. It does so, by running a number of :ref:`configuration
+tasks <image-configuration-tasks>`. The exact tasks that should run, are
+specified by rules found in the virtual floppy, placed there by *snf-image*,
+before spawning the helper VM. *snf-image-helper* uses *runparts* to run the
+tasks which are found under ``/usr/lib/snf-image-helper/tasks``.
 
 Graphical Representation
 ^^^^^^^^^^^^^^^^^^^^^^^^