Synnefo » snf-image

h1. snf-image

snf-image is a Ganeti OS Provider primarly used by Synnefo.

It is written from scratch and allows Ganeti to launch instances from predefined or untrusted custom Images. The whole process of deploying an Image onto the block device, as provided by Ganeti, is done in complete isolation from the physical host, enhancing robustness and security.

There are also additional hooks that can be enabled at image deployment. They allow for:

 * changing the password of root or arbitrary users

 * injecting files at arbitrary locations inside the filesystem, e.g., SSH keys

 * setting a custom hostname

 * re-creating SSH host keys to ensure the image uses unique keys

snf-image has been used successfully to deploy many major Linux distributions (Debian, Ubuntu/Kubuntu, CentOS, Fedora), as well as Windows 2008 R2.  

snf-image requires ganeti-os-interface v20 to operate.

It introduces the following OS parameters:

 * @img_id@ (_required_): the unique id of the image as known by the storage backend

 * @img_format@ (_required_): the image format (extdump and ntfsdump [dd] currently supported)

 * @img_passwd@ (_required_): the passwd to be injected inside the image

 * @img_personality@ (_optional_): files to be injected into the image filesystem. It is a JSON-encoded list of files to be injected: every file is defined by its path and base64-encoded data. This format follows the notation proposed by the "OpenStack Compute API v1.1":http://docs.openstack.org/api/openstack-compute/1.1/content/CreateServers.html. ["more...":http://docs.openstack.org/api/openstack-compute/1.1/content/Server_Personality-d1e2543.html ] for defining server personalities.

The snf-image Ganeti OS Provider is released under a [[Licence|2-clause BSD Licence]].

h2. Architecture

snf-image is split in two components: A part running on the Ganeti host, with full root privilege (@snf-image-host@), and a part running inside an unprivileged, helper VM (@snf-image-helper@).

h3. snf-image-host

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.

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-host@ to automate the creation of a helper VM image based on Debian Stable, using @debootstrap@.

The @snf-image-helper@ component is spawned inside a specific hardware environment:

* 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.

* All kernel/console output is redirected to the first virtual serial console, and eventually finds its way into the OS provider 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.

* 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.

h3. 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 the @snf-image-host@ component.

@snf-image-helper@ uses @runparts@ to run tasks found under @/usr/lib/snf-image-helper/tasks@ by default.

h2. Download

h2. Installation

Before installing snf-image be sure to have a working Ganeti installation in your cluster. The installation process should take place in *all* ganeti nodes. Here we will describe the installation in a single node. The process is identical for all nodes and should be repeated manually or automatically (e.g. with puppet).

# Download the snf-image-host debian package as described in the download section.

# Install the snf-image-host debian package:

<pre>

 # dpkg -i snf-image-host_version.deb

</pre>

# If the dependencies are not met, install all the dependencies using @apt-get install@

# Download the snf-image-helper debian package as described in the download section and store it in a handy location.

# *Do NOT install the snf-image-helper debian package* in the Ganeti node (the package should be present but NOT installed in any node).

# Configure the packages, as described in the next section, before you can start using the new OS Provider.

h2. Configuration

Once you have installed snf-image-host in the Ganeti node and also snf-image-helper is present, proceed with the following configuration:

# Edit /etc/default/snf-image and set the HELPER_DIR variable to a directory in which all snf-helper related stuff are going to be stored (the directory should be able to store at least 700MB of data)

# Move the snf-image-helper debian package inside this directory and edit the HELPER_PKG variable in /etc/default/snf-image accordingly

<pre>

 $ mv /path/to/handy/location/snf-image-helper_version.deb HELPER_DIR/

</pre>

# Update the helper-vm image and related data:

<pre>

 $ /usr/bin/snf-image-update-helper

</pre>

h2. Features / Hooks

h2. Community & Support

* Bug-reports: snf-image-bugs@lists.grnet.gr

* Support: snf-image-support@lists.grnet.gr