Patent Application
20090077551
This invention pertains to virtualized systems, and more particularly to automated installation of a guest operating system in a fully-virtualized system.
Virtualized systems permit a user to run (potentially) any desired operating system on a computer. If the virtualized system is sufficiently sophisticated, a user can install and run many different operating systems at the same time, and switch between them as desired. The user might even be able to install and run operating systems that normally cannot be installed and run on a single computer at the same time.
There are two basic models for virtualized systems: the fully virtualized system and the para-virtualized system. In the fully virtualized system, the user boots the computer using the host operating system. Once the host operating system is operational, a virtual machine manager (VMM) is activated. The VMM interfaces between the host operating system and the underlying hardware on the one hand, and the guest operating system on the other. Among other functionalities, the VMM emulates the BIOS (Basic Input/Output System) of the computer. The VMM permits the guest operating system to be installed and run as though it were communicating directly with the hardware. In this manner, any desired operating system can be installed as the guest operating system without any special installation requirements. But because the guest operating system thinks it is communicating directly with the hardware, it is not possible to pass parameters to the guest operating system during the boot process. As a consequence, installation of the guest operating system in a fully-virtualized system is a manual process, requiring human involvement.
In contrast, the para-virtualized system permits parameters to be transferred to the guest operating system during the boot process. This capability permits the guest operating system to be installed in a completely automated manner. But this capability comes at a price: the guest operating system must “know” that it is running on a virtualized system. To achieve this capability, the guest operating system needs to be specially designed: an off-the-shelf copy of a standard operating system will not work as a guest operating system in a para-virtualized system.
A need remains for a way to permit installation of a guest operating system on a fully-virtualized system without human involvement that addresses these and other problems associated with the prior art.
In an embodiment of the invention, a fully-virtualized system can request installation of a guest operating system. A customized installation of the guest operating system can be generated on-the-fly by extracting contents from a generic image, modifying those contents, and building the customized image.
The foregoing and other features, objects, and advantages of the invention will become more readily apparent from the following detailed description, which proceeds with reference to the accompanying drawings.
Server 105 includes receiver 110, extractor 115, modifier 120, virtual image builder 125, and data source 130. Receiver 110 is used to receive a request for a customized image to be built on-the-fly. Receiver 110 can receive such a request from a computer system, such as computer system 305 (see
Modifier 120 uses modifications 135, 140, and 145 to modify files 210, 215, and 220 extracted from generic image 205. Modifier 120 might use modifications 135, 140, and 145 to change the contents of files 210, 215, and 220 in some way. For example, modifications 135 might specify some parameters or settings to be used during installation, such as an IP address to be assigned to the computer on which the customized image is installed. Or modifications 135 might specify the particular components to be installed on the computer.
Modifier 120 might also use modifications 135, 140, and 145 to add new files to the contents. For example, modifier 120 might use response file 140 to add a new file (or perhaps more than one) to the contents extracted from generic image 205. This new file can be used during the installation of the customized image to fully automate the installation, without requiring the user's involvement. Examples of some of the issues that can be bypassed with a response file include acceptance of the license agreement, the install language, which components should be installed, and so on.
Modifier 120 might also use modifications 135, 140, and 145 to control specify information about where the customized image is to be installed from. For example, location 145 can specify a particular location from which the customized image is to be installed (that is, the installation medium). This location might be an image on a transportable medium, such as a CD-ROM, or it might be a network-accessible location, such as a folder on a server. By specifying this information in location 145, modifier 120 can modify the files in the customized image so that the specified location can be used during the installation, without the user having to indicate where the customized image file can be found. This, too, can permit installation to be automated, so that the user does not need to interact with the computer during installation of the customized image.
Once modifier 120 has modified the files extracted from generic image 205 as needed, the modified files can be built into a customized image by virtual image builder 125 (see
Modifications 135, 140, and 145 can be managed using policies of the enterprise. By using policies (not shown in
The policies can determine onto which machines particular customized images (that is, specific combinations of modifications to produce a particular guest operating system) can be installed. For example, one policy can define a guest operating system that best supports applications that would be used by a software developer (such as programming languages, lower level operating system access, and test software), whereas another policy can define a guest operating system to support a chief financial officer (who would use a different set of applications running on the guest operating system, and would need access to the company's financial records). The developer can be granted access to the first policy, but not the second; the chief financial officer can be granted access to the second policy, but not the first. For example, based on their role within the company or their login ID. A person skilled in the art will recognize other ways in which users can be granted access to policies, such as based on an association between some identifier of the user and an identifier of the policy.
A person skilled in the art will recognize that specific customized bootable images can be generated in advance: for example, customized images that meet certain policies. In such embodiments, the pre-generated images can be those that are frequently used. Then, when the policy is identified the stored pre-generated image can be loaded. But a person skilled in the art will also recognize how embodiments of the invention can permit generation of the customized image on-the-fly, even when the modifications to be made to the customized images are consistent with policies that are frequently used.
In
At the bottom of the stack of layers in computer system 305 is host operating system 330. Host operating system 330 communicates with the hardware to achieve the desired end result. Because the aim is for computer system 305 to support a virtual machine model, host operating system 330 does not have to include all of the functionalities often provided in end-user operating systems: such functionalities can be provided by the guest operating system. But a person skilled in the art will recognize that host operating system 330 can include these additional functionalities, if desired (potentially at the cost of the running speed of computer system 305).
Sitting above host operating system 330 is virtual machine manager (VMM) 335. VMM 335 is responsible for interfacing with the guest operating system and appearing to the guest operating system to be the hardware layer, so that the guest operating system thinks it is directly installed on computer system 305. VMM 335 informs host operating system 330 of the requests made of the hardware by the guest operating system, so that the appropriate hardware results can be determined.
Guest operating system 340 resides above VMM 335. Guest operating system 340 is the operating system that the user uses. As discussed above, guest operating system 340 thinks that it is installed directly on the hardware of computer system 305, and so is not aware that it is running as a virtual machine. Guest operating system 340 can be installed from customized image 235 by accessing customized image 235 and running the installation program. While
Applications 345 can be run on top of guest operating system 340. Examples of such applications can be word processors, spreadsheets, compilers and programming environments, games, and any other types of applications that are compatible with guest operating system 340.
In
Computer system 305 can access customized image 235 from server 105. Server 105 can include local storage, such as storage 410, on which customized image 235 can be stored. Storage 410 can be either a volatile or non-volatile storage medium. While
Alternatively, customized image 235 and generic image 205 can be stored on some other storage medium 415 separate from both computer system 305 and server 105. For example, customized image 235 and generic image 205 can be stored on a network attached storage (NAS) device. A person skilled in the art will recognize that customized image 235 and generic image 205 do not need to be stored on the same devices, and can be stored separately. For example, generic image 205 might be stored on storage 415 in a non-volatile medium, whereas customized image 235 can be stored on storage 410 in server 105 in a volatile medium.
A person skilled in the art will recognize that
A person skilled in the art will also recognize that there are no timing limitations on the use of embodiments of the invention. For example, in one embodiment a brand new computer system, with no pre-installed host operating system or VMM, can be used. The host operating system, VMM, and guest operating system can all be installed on this new computer system as described above. But in another embodiment an existing computer system already running a host operating system and VMM can be used. A new customized image can be generated so that a new guest operating system can be installed on this existing computer system. In this manner, guest operating systems can be installed as needed by various computer systems on-the-fly.
For example, consider a group of computers, already running host operating systems and VMMs. These computers can be running identical host operating systems and VMMs, or different combinations of host operating systems and VMM, as desired by the administration of the group of computers. Guest operating systems can appear and disappear dynamically on top of these VMMs, as demands and needs change. Some of these guest operating systems might be booted from virtual machine images that already exist. And sometimes it might be desired to install a guest operating system for which a virtual machine image there does not yet exist. In this latter case, a customized image can be generated on-the-fly as described above. Whatever the source for the image of the guest operating system (be it a pre-defined image or a customized image generated on-the-fly), a target computer, with a host operating system and VMM already installed and running can boot this install image, thereby installing the desired guest operating system.
As should be clear from the above description, embodiments of the invention enable the use of a customized image for installation of a guest operating system in a fully-virtualized computer system. The installation can be accomplished without any user involvement depending on the modifications made to the customized image. This avoids the potential delay and complications incurred when the installation of the guest operating system requires the user's involvement, and does not require the guest operating system to be designed with an expectation that the guest operating system knows it is interacting with a virtual machine manager, instead of directly with the hardware.
Embodiments of the invention also avoid difficulties associated with other solutions to the underlying problem. For example, the Preboot Execution Environment (PXE, sometimes termed the Pre-Execution Environment) is a system that permits a computer to boot using a network interface card, independently of any installed storage devices or operating systems. The computer, upon booting, broadcasts a Dynamic Host Control Protocol (DHCP) packet to discover if there is a PXE server. If a PXE server is found, the computer downloads into RAM the operating system to be installed: this download is accomplished using Trivial File Transfer Protocol (TFTP). Then, once downloaded, the computer can install and execute the downloaded operating system.
As can be seen from the above description, to use the PXE protocol requires the PXE infrastructure. The computer must include a network interface card: further, that network interface card must understand the PXE protocol. In addition, there needs to be a PXE server: that is, a server capable of communicating using the PXE protocol. In contrast, embodiments of the invention permit installation of a guest operating system without requiring an understanding of the PXE protocol, or any of the infrastructure. As not all hardware (network interface cards and servers) support the PXE protocol, that embodiments of the invention do not depend on the use of the PXE protocol provides an advantage over the PXE system.
The following discussion is intended to provide a brief, general description of a suitable machine in which certain aspects of the invention may be implemented. Typically, the machine includes a system bus to which is attached processors, memory, e.g., random access memory (RAM), read-only memory (ROM), or other state preserving medium, storage devices, a video interface, and input/output interface ports. The machine may be controlled, at least in part, by input from conventional input devices, such as keyboards, mice, etc., as well as by directives received from another machine, interaction with a virtual reality (VR) environment, biometric feedback, or other input signal. As used herein, the term “machine” is intended to broadly encompass a single machine, or a system of communicatively coupled machines or devices operating together. Exemplary machines include computing devices such as personal computers, workstations, servers, portable computers, handheld devices, telephones, tablets, etc., as well as transportation devices, such as private or public transportation, e.g., automobiles, trains, cabs, etc.
The machine may include embedded controllers, such as programmable or non-programmable logic devices or arrays, Application Specific Integrated Circuits, embedded computers, smart cards, and the like. The machine may utilize one or more connections to one or more remote machines, such as through a network interface, modem, or other communicative coupling. Machines may be interconnected by way of a physical and/or logical network, such as an intranet, the Internet, local area networks, wide area networks, etc. One skilled in the art will appreciate that network communication may utilize various wired and/or wireless short range or long range carriers and protocols, including radio frequency (RF), satellite, microwave, Institute of Electrical and Electronics Engineers (IEEE) 545.11, Bluetooth, optical, infrared, cable, laser, etc.
The invention may be described by reference to or in conjunction with associated data including functions, procedures, data structures, application programs, instructions, etc. which, when accessed by a machine, result in the machine performing tasks or defining abstract data types or low-level hardware contexts. Associated data may be stored in, for example, the volatile and/or non-volatile memory, e.g., RAM, ROM, etc., or in other storage devices and their associated storage media, including hard-drives, floppy-disks, optical storage, tapes, flash memory, memory sticks, digital video disks, biological storage, etc. Associated data may be delivered over transmission environments, including the physical and/or logical network, in the form of packets, serial data, parallel data, propagated signals, etc., and may be used in a compressed or encrypted format. Associated data may be used in a distributed environment, and stored locally and/or remotely for machine access.
Having described and illustrated the principles of the invention with reference to illustrated embodiments, it will be recognized that the illustrated embodiments may be modified in arrangement and detail without departing from such principles, and may be combined in any desired manner. And although the foregoing discussion has focused on particular embodiments, other configurations are contemplated. In particular, even though expressions such as “according to an embodiment of the invention” or the like are used herein, these phrases are meant to generally reference embodiment possibilities, and are not intended to limit the invention to particular embodiment configurations. As used herein, these terms may reference the same or different embodiments that are combinable into other embodiments.
Consequently, in view of the wide variety of permutations to the embodiments described herein, this detailed description and accompanying material is intended to be illustrative only, and should not be taken as limiting the scope of the invention. What is claimed as the invention, therefore, is all such modifications as may come within the scope and spirit of the following claims and equivalents thereto.
