Boot image
A boot image is a type of disk image that when on a boot device allows the associated computer to boot. A boot image usually includes an operating system, utilities, diagnostics, boot and data recovery information and applications used organization-wide. A specialized image for a particular department or type of user may be called a departmental boot image. Building such an image can take days or weeks, and involve complex decisions about licensing and permissions - including which passwords to store in the boot image and which to require users to type in - and requires experts in software integration to do. However, once built, the boot image can be simply copied onto devices, patched within reasonable limits, and remains disposable in case of any problems (viruses in particular). This is possible because unlike other hard drive images (which may contain any data, et al.), pure boot images contain no mission-critical data. By definition a pure boot image contains no data that cannot be reproduced from configurations or off-the-shelf executables. In particular end-user data is not part of a boot image, although some operating systems require that a copy of user preferences or configuration files be kept within the boot image itself, e.g. Microsoft Windows registry. Utilities like Norton Ghost keep a backup copy of the boot image, for quick re-imaging (often called re-installation) in the event of a problem, thus avoiding the need to diagnose a specific problem with a specific machine.
 | This article needs additional citations for verification. (July 2011) |
A boot image is a type of disk image that when on a boot device allows the associated computer to boot.[1]
A boot image usually includes an operating system, utilities, diagnostics, boot and data recovery information and applications used organization-wide. A specialized image for a particular department or type of user may be called a departmental boot image. Building such an image can take days or weeks, and involve complex decisions about licensing and permissions - including which passwords to store in the boot image and which to require users to type in - and requires experts in software integration to do.
However, once built, the boot image can be simply copied onto devices, patched within reasonable limits, and remains disposable in case of any problems (viruses in particular). This is possible because unlike other hard drive images (which may contain any data, et al.), pure boot images contain no mission-critical data. By definition a pure boot image contains no data that cannot be reproduced from configurations or off-the-shelf executables. In particular end-user data is not part of a boot image, although some operating systems require that a copy of user preferences or configuration files be kept within the boot image itself, e.g. Microsoft Windows registry. Utilities like Norton Ghost keep a backup copy of the boot image, for quick re-imaging (often called re-installation) in the event of a problem, thus avoiding the need to diagnose a specific problem with a specific machine.
As virtual machine
[edit]Some virtual machine infrastructure can directly import and export a boot image for direct installation to "bare metal", i.e. a disk. This is the standard technique for OEMs to install identical copies of an operating system on many identical machines: The boot image is created as a virtual machine and then exported, or created on one disk and then copied via a boot image control infrastructure that also makes virtual machine copies. The VMware vCenter Converter for instance lets users "convert physical machines to virtual machines - for free"[2] as part of that company's suite of products to make images easier to back up and manage. Equivalents exist for Xen and other VM systems.
Goals
[edit]By keeping the boot image entirely separate and disposable, and mandating boot image control, organizations seek to keep their total cost of operations (including its total cost of ownership component) low. Often such organizations look at uptime as a service.
One goal of boot image control is to minimize the number of boot images used by an organization to reduce support costs. It includes at least:
- Specifying the machine hardware to minimize unneeded machine diversity and minimize the resultant number of boot images.
- Upgrading new machine specifications at low additional cost ensures that they will remain useful long past their normal life. Extending the life of desktop machines will reduce the incursion of off-spec machines later in the life-cycle, improving standardization, reducing support costs, minimizing e-waste.
- Organizing the network so that boot images can be efficiently supported, independent of data. Data must not be dependent on boot devices. Use networks to store data on secure servers.
- Hardware acceptance testing on each new machine confirms that it is fit for use in a standardized boot image environment.
- Boot image installation to ensure that only supportable standardized boot images are used.
- Troubleshooting and help desk functions employ standardized tests to identify the source of problems: boot, software, or hardware.
- Desktop system recovery tools and procedures for failed desktop units. These would use backup copies of a boot image created with utilities such as Norton Ghost. In a large organization with many compatible machines, rapid recovery by replacing with a backup boot image may only take a few minutes, with considerable cost savings.
- Data backup and recovery procedures ensure data is stored in the right place so that it can be recovered promptly in crisis situations.
- Installing services for the disabled with a single boot image in a manner that is ubiquitous and cost effective, meeting the needs of all staff regardless of disability, with available technology services.
- Remote work and secure off-site system access procedures.
- Facilitating worker transfer by changing boots or authorizations instead of moving machines.
- Using thin clients for off-spec machines to eliminate the need for special boot images.
Many organizations use thin clients for applications which require high security, involve unreliable users or repurpose older machines for continued use.
A cascading strategy involves re-imaging older, off-spec machines to thin client boot images so that they may continue in use for some less demanding or more access-controlled applications.
References
[edit]- ^ "Bootable CD/ DVD". Isobuster. Retrieved 20 June 2012.
- ^ "VMware vCenter Converter, Convert Physical Machines to Virtual Machines". Vmware.com. Archived from the original on 2012-09-13. Retrieved 2012-08-05.