Image Format
Version 7 (Nikos Skalkotos, 11/23/2011 05:00 pm) → Version 8/39 (Constantinos Venetsanopoulos, 11/24/2011 11:34 am)
h1. Image Format
The image format is a required OS Provider parameter and snf-image will complain if not found
Right now we support 3 4 different types of image formats: images:
* @extdump@ extdump
* @ntfsdump@ ntfsdump
* @diskdump@ diskdump
* custom
h2. extdump & ntfsdump
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 partition
* Have the root device in /etc/fstab specified in a persistent way, using UUID or LABEL (for extdump only)
h3. 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.
h2. diskdump
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 that 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
h3. Image Properties
In order for snf-image to be able to properly configure an a diskdump image of @diskdump@ format, it needs to be passed a set aware some of image properties:
* *OSFAMILY={linux,windows}* *OSFAMILY={linux|windows}*
This specifies whether the image is a Linux or a Windows Image
* *ROOT_PARTITION={1,2,3,4}* *ROOT_PARTITION=[1234]*
This specifies the partition number of the root partition. As mentioned earlier, for now we only support primary partitions
* *USERS="username1 username2...."*
This is a list of users, whose password will be reset by snf-image.
All image properties are passed to snf-image through the @img_properties@ OS parameter. The @img_properties@ parameter is *mandatory* when trying to deploy an image of @diskdump@ format. @img_properties@ should be a json file dumped as a string. When trying try to deploy an image of type @{ext,ntfs}dump@ then @img_properties@ are not necessary. reset the password for.
The image format is a required OS Provider parameter and snf-image will complain if not found
Right now we support 3 4 different types of image formats: images:
* @extdump@ extdump
* @ntfsdump@ ntfsdump
* @diskdump@ diskdump
* custom
h2. extdump & ntfsdump
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 partition
* Have the root device in /etc/fstab specified in a persistent way, using UUID or LABEL (for extdump only)
h3. 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.
h2. diskdump
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 that 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
h3. Image Properties
In order for snf-image to be able to properly configure an a diskdump image of @diskdump@ format, it needs to be passed a set aware some of image properties:
* *OSFAMILY={linux,windows}* *OSFAMILY={linux|windows}*
This specifies whether the image is a Linux or a Windows Image
* *ROOT_PARTITION={1,2,3,4}* *ROOT_PARTITION=[1234]*
This specifies the partition number of the root partition. As mentioned earlier, for now we only support primary partitions
* *USERS="username1 username2...."*
This is a list of users, whose password will be reset by snf-image.
All image properties are passed to snf-image through the @img_properties@ OS parameter. The @img_properties@ parameter is *mandatory* when trying to deploy an image of @diskdump@ format. @img_properties@ should be a json file dumped as a string. When trying try to deploy an image of type @{ext,ntfs}dump@ then @img_properties@ are not necessary. reset the password for.