« Previous - Version 29/39 (diff) - Next » - Current version
Nikos Skalkotos, 11/24/2011 10:16 pm

Image Format

The image format (img_format) is a required OS Provider parameter and snf-image will complain if not found
Right now we support 4 different types of image formats:
  • extdump
  • ntfsdump
  • diskdump
  • custom (unstable)

extdump & ntfsdump image formats

Those two formats are raw copies (using dd) of partitions hosting Linux systems on ext{2,3,4} and Windows systems on ntfs filesystems respectively.

Partitions hosting a Windows or Linux system that are suitable for dumping should have the following properties:
  • Be the first partition in the filesystem
  • The OS they host should not depend on any other partitions
  • Start at sector 2048
  • Have a bootloader installed in the boot sector of the partition (not MBR)
  • Have the root device in /etc/fstab specified in a persistent way, using UUID or LABEL (for extdump only)

Known Issues

  • For linux systems, having grub installed in the partition is fragile and things can go wrong when resizing the partitions, especially when shrinking.
  • Swap space is not supported.
  • More complicated partition schemes are not supported.

diskdump image format

Diskdump is a newer format that overcomes most of the aforementioned issues. This format is a raw copy (dd) of a whole disk.

This design decision has the following benefits:
  • Swap partitions are supported
  • The system may use multiple partitions:
    • dedicated partitions for /boot, /home etc in linux
    • system and boot partition in Windows
  • There are no restrictions on starting sectors of partitions
Although diskdump is a lot more flexible than the older formats, there are still some rules to follow:
  • All devices in fstab should be specified by persistent names (UUID or LABEL)
  • LVMs and extended partitions should be avoided.
    • The support for extended partitions is partial. snf-image does not support resizing logical partitions.
    • Logical volumes are not supported at all
  • In Linux disks only ext{2,3,4} filesystems are supported

custom image format

For now, a custom image is a diskdump image whose img_id OS Parameter (see Ganeti OS Interface) is a URL that points to the image file. For now, the use of this format is discouraged because it may change in the near future.

Image Properties

In order for snf-image to be able to properly configure an image, it may make use of a set of image properties. Those image properties are passed to snf-image by Ganeti through the img_poroperties OS parameter (see Ganeti OS Interface). For the diskdump format some properties are mandatory. For {ext,ntfs}dump formats all image properties are optional.

A list of mandatory and optional properties follows:
  • Mandatory properties (diskdump only)
    • OSFAMILY={linux,windows}
      This specifies whether the image is a Linux or a Windows Image. {ext,ntfs}dump formats are self descriptive regarding this property.
    • ROOT_PARTITION={1,2,3,4}
      This specifies the partition number of the root partition. As mentioned earlier, for now, only primary partitions are supported. This property is trivial for {ext,ntfs}dump formats (they only host one partition).
  • Optional properties
    • USERS="username1 username2...."
      This is a space-seperated list of users, whose password will be reset by snf-image. If this is missing then the users are chosen according to a set of rules, but please do not depend on this. Those rules may change or even be dropped in the future. Do directly specify the USERS list, just to be on the safe side.
      The rules we currently use are listed below:
      • For Windows images, the Administrator's password is reset.
      • For Linux images, the root password is reset for all distribution. If snf-image detects the system as a Fedora or an Ubuntu Linux, then it also resets the password of the user with username user.
      If this property is defined with a value other than null, then during the deployment, the image will not be configured at all. This is really handy because it gives the ability to deploy images hosting operating systems whose configuration is not supported by snf-image.
    • EXCLUDE_<name_of_a_task>_TASK
      This family of properties gives the ability to exclude individual configuration tasks from running. Hence, if the property EXCLUDE_DeleteSSHKeys_TASK with a value other than null is passed to snf-image, the aforementioned configuration step will not be executed, and the SSH Keys found in the image will not be removed during the deployment. Task exclusion provides great flexibility, but it needs to be used with great care. Tasks depend on each other and although those dependencies are well documented, automatic task dependency resolution isn't yet supported in snf-image. If you exclude task A but not task B which depends on A, you will probably end up with an unsuccessful deployment because B will fail and exit in an abnormal way. You can read more about configuration tasks here.

OS parameter (img_properties)

Image properties are passed to snf_image through the img_properties OS parameter as a simple json string like the one below:

     "PROPERTY1": "VALUE1",
     "PROPERTY2": "VALUE2",
     "PROPERTY3": "VALUE3",
     "PROPERTYn": "VALUEn",

A real life example for creating a new ganeti instance and passing image properties to snf-image would probably look more like this:

gnt-instance add -O img_properties='{"OSFAMILY":"linux","ROOT_PARTITION":"2","USERS":"root guest"}',img_format=diskdump...