8.18. Disk Image Modes
Bochs can handle independent disk image format for each disk present on the ata interfaces. The disk image type is selected in the configuration file by the "mode" option of the ataX-xxx directives. Example:
ata0-master: type=disk, mode=flat, path=10M.sample, cylinders=306, heads=4, spt=17 |
Note: If unspecified, the default "mode" is flat.
Table 8-3. Supported Disk Modes
| Name | Description | Features |
|---|---|---|
| flat | one file, flat layout | accessible with mtools or winimage-like tools |
| concat | multiple files, concatenated | mappable to contained partitions |
| external | accessed through an external C++ class | developer specific, needs a C++ class at compile time |
| dll | accessed through a DLL | developer specific, windows only |
| sparse | up to 10 layers stackable files | commitable, rollbackable, growing |
| vmware3 | vmware3 disk support | vmware version 3 compatibility |
| vmware4 | vmware4 disk support | vmware version 4 compatibility |
| undoable | flat file with a commitable redolog | commitable, rollbackable |
| growing | one growing file | growing |
| volatile | flat file with a volatile redolog | always rollbacked |
8.18.1. flat
8.18.1.1. description
In flat mode, all sectors of the harddisk are stored in one flat file, in lba order.
8.18.1.2. image creation
Flat disk images can be created with the bximage utility (see Section 8.19 for more information).
8.18.1.3. path
The "path" option of the ataX-xxx directive in the configuration file must point to the flat image file.
8.18.1.4. external tools
Flat images content can be accessed from the host by the following tools :
mtools (see Section 8.2)
mount with a loopback (see Section 8.7)
Winimage / DiskExplorer (see Section 8.4)
Bochs Tools (see Section 8.3)
8.18.1.5. typical use
Flat mode is Bochs default harddisk layout. This is also the layout of disk images provided on Bochs websites.
8.18.1.6. limitations
On some host OSes, Bochs flat disk images are limited to 2GiB.
8.18.2. concat
8.18.2.1. description
In concat mode, all sectors of the harddisk are stored in several flat files, in lba order.
8.18.2.2. image creation
Disk images for the usage in 'concat' mode can be created with the bximage utility (see Section 8.19 for more information).
8.18.2.3. path
The "path" option of the ataX-xxx directive in the configuration file must point to the first file (e.g. win95-1). The lower layer files names are found by adding 1 to the last character (e.g. win95-2, win95-3, etc.).
8.18.2.4. external tools
If every single file contains a complete partition, they can be accessed with same tools as the 'flat' mode images.
8.18.2.5. typical use
If the partition sizes and file sizes are set up correctly, this allows you to store each partition in a separate file, which is very convenient if you want to operate on a single partition (e.g. mount with loopback, create filesystem, fsck, etc.).
8.18.2.6. limitations
On some host OSes, there is a limit of 2GiB per file.
8.18.3. external/dll
8.18.3.1. description
This mode is only useful for developers and needs an additional C++ class compiled in, or an additional DLL linked to Bochs.
8.18.4. sparse
8.18.4.1. description
Sparse disk support has been added by JustinSB. Sparse disk features are:
Large hard drive can be created, and only used space will be stored in the file. In practice, on Unix, this is not a large gain as it is done anyway.
Multiple sparse drive images can be mounted on top of each other. Writes go to the top image. This allows several similar configurations to share a master "base" file, and also allows filesystem rollback or no-write options. Up to 10 disk images can be layered on top of each other.
8.18.4.2. image creation
Sparse disk images must be created with the bximage utility (see Section 8.19 for more information). Be sure to enter "sparse" when selecting the image type.
8.18.4.3. path
The "path" option of the ataX-xxx directive in the configuration file must point to the top layered file. The lower layer files names are found by substracting 1 from the last character (must be a digit)
8.18.4.4. external tools
No external tool support Sparse disk images yet.
8.18.4.5. typical use
8.18.4.5.1. Space Saving
Create a sparse disk image using bximage. Set size to eg 10GB. Only allocated space will be stored, so your drive image should be only about as large as the files stored on it.
8.18.4.5.2. Disk Rollback
Create a sparse disk image called "c.img.0". Point .bochsrc at "c.img.0". In bochs, install your favourite OS. Switch off bochs.
Create a sparse disk image (of the same size) and name it "c.img.1". Point .bochsrc at "c.img.1" "c.img.0" is visible, but all writes go to "c.img.1". After using bochs, you can simply delete "c.img.1" to undo changes and go back to a clean OS install.
8.18.4.5.3. Disk Optional Commit
Create a sparse disk image called "c.img.0". Point .bochsrc at "c.img.0". In bochs, install your favourite OS. Switch off bochs.
Create a sparse disk image (of the same size) and name it "c.img.1". Point .bochsrc at "c.img.1" "c.img.0" is visible, but all writes go to "c.img.1". After using bochs, if you want to keep the changes, use the (currently non-existant) merge utility to make a single unified drive image.
Alternatively simply create a new partition on top called "c.img.2".
8.18.4.5.4. Common Base
Create a sparse disk image called "base.img". Point .bochsrc at "base.img". In bochs, install your favourite OS. Switch off bochs.
Create a sparse disk image (of the same size) and name it "www.img.1". Make "wwww.img.0" a symlink to "base.img". Point .bochsrc at "www.img.1". Using bochs, install a webserver.
Create a symlink to "base.img" called "db.img.0". Create a sparse disk image (of the same size) and name it "db.img.1". Point .bochsrc at "db.img.1". Using bochs, install a database server.
Now both a database server and webserver can be run in separate virtual machines, but they share the common OS image, saving drive space.
8.18.4.6. limitations
There is a need for supporting utilities (yet unwritten) :
to merge two sparse disk images into a single image
to defragment a sparse disk image and remove unused space
8.18.5. vmware3/vmware4
8.18.5.1. description
Sharvil Nanavati has added vmware3/4 disk image support into Bochs for Net Integration Technologies, Inc. You should be able to use disk images created by vmware version 3 and 4.
8.18.5.2. image creation
Create such disk image with vmware version 3 or 4.
8.18.5.3. path
The "path" option of the ataX-xxx directive in the configuration file must point to the vmware3/4 disk image.
8.18.5.4. external tools
give a look at vmware3/4 tools : disk image creation, etc.
8.18.5.5. typical use
If you want to use an existing vmware3/4 disk image.
8.18.5.6. limitations
Only vmware versions 3 and 4 disk image files are supported.
8.18.6. undoable
8.18.6.1. description
Undoable disks are commitable/rollbackable disk images. An undoable disk is based on a read-only flat image (see Section 8.18.1), associated with a growing redolog, that contains all changes (writes) made to the flat image content.
This redolog is dynamically created at runtime, if it does not previously exists.
All writes go to the redolog, reads are done from the redolog if previously written, or from the flat file otherwise.
If unspecified with the "journal" option of the ataX-xxx directive, the redolog file name is created by adding a ".redolog" suffix to the flat image name.
File size of the redolog can grow up to the total disk size plus a small overhead due to internal data managment (about 3% for a 32MiB disk, less than 0.5% for a 2GiB disk).
After a run, the redolog will still be present, so the changes are still visible the next time you run Bochs with this disk image.
After a run, the redolog can be committed (merged) to the flat image with the bxcommit utility.
After a run, the redolog can be rollbacked (discarded) by simply deleting the redolog file.
Note: In this mode, the flat file is always open in read-only mode, so it can safely be stored on a read-only medium (for example on a cdrom).
8.18.6.2. image creation
The flat disk images must be created with the bximage utility (see Section 8.19 for more information). The growing redolog is created automatically if needed.
8.18.6.3. path
The "path" option of the ataX-xxx directive in the configuration file must be the flat image name. The redolog name can be set with the "journal" option of the same directive. If not set, the redolog name is created by adding the ".redolog" suffix to the flat image name.
8.18.6.4. external tools
See Section 8.18.1.4 for tools to access the flat disk image content.
Note: The up-to-date content can only be seen after you commit the redolog to the flat file with the bxcommit utility.
8.18.6.5. typical use
to be completed
8.18.6.5.1. Commit
to be completed
8.18.6.5.2. Rollback
to be completed
8.18.6.5.3. Common Base
to be completed
8.18.6.5.4. Harddisk Image on a Read-Only Medium
to be completed
8.18.6.6. limitations
to be completed
8.18.7. growing
8.18.7.1. description
Growing disk images start as a small files, and grow whenever new data is written to them.
Once a sector is written in the growing file, subsequent writes to the same sector will happen in place.
File size of Growing disk images can go up to the total disk size plus a small overhead due to internal data managment. (about 3% for a 32MiB disk, less than 0.5% for a 2GiB disk).
8.18.7.2. image creation
Growing disk images must be created with the bximage utility (see Section 8.19 for more information). Be sure to enter "growing" when selecting the image type.
8.18.7.3. path
The "path" option of the ataX-xxx directive in the configuration file must be the growing image name.
8.18.7.4. external tools
No external tool support Growing disk images yet.
8.18.7.5. typical use
Growing disk images can be used whenever you want to maximize disk space. However, please note that Bochs will not check if enough disk space is available before writing new data. If no disk space is available, a panic will occur.
8.18.7.6. limitations
to be completed
8.18.8. volatile
8.18.8.1. description
Volatile disks are always-rollbacked disk images. An volatile disk is based on a read-only flat image (see Section 8.18.1), associated with a growing temporary redolog, that contains all changes (writes) made to the flat image content. All data written to the disk image are lost at the end of the Bochs session.
The redolog is dynamically created at runtime, when Bochs starts, and is deleted when Bochs closes (win32) or just after it has been created (Unix).
All writes go to the redolog, reads are done from the redolog if previously written, or from the flat file otherwise.
If unspecified with the "journal" option of the ataX-xxx directive, the redolog file name is created by adding a ".redolog" suffix to the flat image name.
File size of the redolog can grow up to the total disk size plus a small overhead due to internal data managment (about 3% for a 32MiB disk, less than 0.5% for a 2GiB disk).
After a run, the redolog is not any more present, so the changes are discarded.
Note: In this mode, the flat file is always open in read-only mode, so it can safely be stored on a read-only medium (for example on a cdrom).
8.18.8.2. image creation
The flat disk images must be created with the bximage utility (see Section 8.19 for more information). The growing redolog is created automatically.
8.18.8.3. path
The "path" option of the ataX-xxx directive in the configuration file must be the flat image name. The redolog name can be set with the "journal" option of the same directive. If not set, the redolog name is created by adding the ".redolog" suffix to the flat image name. A random suffix is also appended to the redolog name.
8.18.8.4. external tools
See Section 8.18.1.4 for tools to access the flat disk image content.
8.18.8.5. typical use
can be completed
8.18.8.5.1. Repeatable simulations
to be completed
8.18.8.5.2. Multiple Bochs instances
to be completed
8.18.8.5.3. Harddisk Image on a Read-Only Medium
to be completed
8.18.8.6. limitations
to be completed