Patent Application
20110197053
Large organizations are constantly deploying new computer hardware. For example, a corporation may deploy a new desktop computer system each time an employee is hired and on some regular interval (e.g., every five years) during an employee's employment. Deployment is also common in data centers, where administrators deploy new servers for many reasons, such as to add services, to replace aging hardware, and so forth. Application hosting companies may add servers as user demand increases or as a number of applications hosted increases. Because it is not generally feasible to run an operating system (OS) setup program, which can take many minutes to hours, on each new computer system, it is common in physical machine operating system deployment to deploy a physical image of the operating system to the hard disks of new computer systems. The operating system image may be preconfigured to include common software for the organization, as well as configuration settings (e.g., for security) desired by the organization.
Virtualization refers to the execution of a virtual machine by physical hardware and then running operating systems and/or applications virtually on the virtual machine. The virtual machine may represent a least common denominator of hardware functionality or may represent a well-known configuration for which it is easy to prepare an operating system and applications. Many data centers use virtualization to be able to easily move a virtual machine to new physical hardware as resource requirements increase, for maintenance cycles, and to balance physical server loads. Virtualization is useful for many situations, but can also impose limitations that occur due to many virtual machines contending for the same resources (e.g., central processing unit (CPU), memory, and network interface card (NIC)). Running a virtual machine also typically still entails some initial physical deployment to prepare the physical hardware to run virtual machines.
Although newer operating systems, such as MICROSOFT WINDOWS 7, have added support for booting virtual images natively, system administrators routinely still manage many physical deployments. In addition, although virtualization provides many benefits, it has created a new problem in that administrators have doubled their work by the management of two paradigms. Typically, an administrator chooses at the time of deployment to create either a physical deployment image or a virtual deployment image, and is locked into that choice in the future. Thus, the physical and virtual worlds are two separate configuration options. If it later becomes beneficial to make a different choice, such as moving from physical to virtual to allow easier migration as described above, then the administrator has to build a new virtual image and migrate data from the retiring physical deployment to the new virtual machine. This is both time consuming and redundant.
A deployment system is described herein that allows an administrator to convert virtual deployments to physical deployments so that an administrator can easily move between the virtual and physical world. This relieves the administrator from being faced with harsh consequences from choosing the wrong type of deployment at the outset, and allows the administrator instead to routinely opt for a virtual image deployment and convert virtual deployments to physical deployments easily when it is useful. The deployment system allows an administrator to directly deploy an operating system image in the form of a VHD file to the hard disks of a physical machine as a directly bootable and natively installed operating system. Thus, the deployment system relieves administrators from separately managing physical and virtual deployment images. Instead, administrators can manage only virtual deployment images and convert virtual images to physical deployments as needed.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
A deployment system is described herein that allows an administrator to convert virtual deployments to physical deployments so that an administrator can easily move between the virtual and physical world. This relieves the administrator from being faced with harsh consequences from choosing the wrong type of deployment at the outset, and allows the administrator instead to routinely opt for a virtual image deployment and convert virtual deployments to physical deployments easily when it is useful. Virtual machines are typically stored and deployed as Virtual Hard Drive (VHD) files that contain an image of the contents of a virtual machine's stored data. The deployment system allows an administrator to directly deploy an operating system image in the form of a VHD file to the hard disks of a physical machine as a directly bootable and natively installed operating system. The deployment system identifies a target physical machine, receives a VHD file to deploy to the physical machine, extracts the contents of the VHD to a physical storage media of the target physical machine, modifies the extracted contents if needed, and then remaps the extracted contents on the physical hard disk to make the extracted contents bootable as a native operating system. The system is not limited to any one operating system, and administrators can use the system for MICROSOFT WINDOWS, Linux, and other operating system deployments. Thus, the deployment system relieves administrators from separately managing physical and virtual deployment images. Instead, administrators can manage only virtual deployment images and convert virtual images to physical deployments as needed.
VHD is designed to support running virtual machines instead of being used as images for physical machine operating system deployment. However, the deployment system provides a method by which VHD can be used as an operating system image for physical machine operating system deployment. The solution works with multiple operating systems, although the methods used may differ slightly as described further herein. In an operating system deployment scenario the machine on which the operating system is to be deployed is referred to herein as the target machine. Allowing physical deployments from VHDs provides many benefits, including the ability to test an image as a virtual machine before it is deployed physically. Those of ordinary skill in the art will recognize numerous benefits afforded by easy conversion from the virtual domain to the physical domain.
The target identification component 110 identifies a target physical computer system to which to deploy a virtual operating system image. The target identification component may run as part of an operating system preinstallation environment, such as one booted on the target physical machine using a CD-ROM or other media (e.g., a USB drive). For example, MICROSOFT provides the MICROSOFT WINDOWS Preinstallation Environment (WinPE) that can be combined with the deployment system 100 to perform the steps described herein.
The virtual image retrieval component 120 identifies the virtual operating system image to deploy to the target physical computer. The component 120 may access the image over a network or other media accessible from the preinstallation environment. In some embodiments, the virtual image retrieval component 120 displays a user interface to a system administrator through which the system administrator can navigate to a virtual image stored in a data store and select the virtual image for deployment to the target physical computer. An organization may create a variety of virtual operating system images for deployments to a variety of types of physical hardware and store the images in a centrally accessible location for deployment as needed.
The virtual image extraction component 130 identifies the contents of a virtual operating system image and makes the contents accessible for copying to the physical computer. For example, the virtual operating system image may be mountable as a native file system based on the file system within the virtual operating system image and the types of file systems understood by the preinstallation environment. For example, WINDOWS can mount VHD files containing NTFS file system data natively. For mounted file systems, the component 130 can copy the virtual image data as one or more files. Otherwise, the virtual image extraction component 130 can access the image data as a binary file and can copy the image's contents to the physical computer's hard disk or other storage.
The image adaptation component 140 performs machine-specific adjustments to the virtual operating system image copied to the physical computer. The virtual operating system image may contain configuration settings that are not correct for the physical hardware. For example, the virtual machine for which the virtual operating system image was created may include a different video card or network card than the target physical computer. The image adaptation component 140 may also retrieve drivers specific to the hardware to which the virtual operating system image is being deployed.
The target finalization component 150 prepares the target physical computer to boot into the deployed virtual operating system image. The component 150 may modify the master boot record (MBR) of the target computer to mark the partition on which the deployed operating system is stored as active and may modify boot menu settings of a boot loader to indicate that the deployed operating system is the one to boot by default. This allows the deployment system 100 to reboot the target physical computer system at the end of deployment so that the target system boots into the newly deployed image.
The computing device on which the deployment system is implemented may include a central processing unit, memory, input devices (e.g., keyboard and pointing devices), output devices (e.g., display devices), and storage devices (e.g., disk drives or other non-volatile storage media). The memory and storage devices are computer-readable storage media that may be encoded with computer-executable instructions (e.g., software) that implement or enable the system. In addition, the data structures and message structures may be stored or transmitted via a data transmission medium, such as a signal on a communication link. Various communication links may be used, such as the Internet, a local area network, a wide area network, a point-to-point dial-up connection, a cell phone network, and so on.
Embodiments of the system may be implemented in various operating environments that include personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics, digital cameras, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and so on. The computer systems may be cell phones, personal digital assistants, smart phones, personal computers, programmable consumer electronics, digital cameras, and so on.
The system may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, and so on that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments.
Continuing in block 230, the system mounts the virtual image so that the virtual image contents are accessible. The contents of the VHD file are then accessible as a collection of WINDOWS or UNIX file system files. For example, the programs installed by the system may be able to use well-known file system application programming interfaces (APIs) within the preinstallation environment to access the VHD contents (rather than the binary method described with reference to
Continuing in block 250, the system identifies machine-specific data stored in the virtual image. The system identifies Information in the VHD that is machine hardware specific, or operating system instance specific, such as drivers, boot configuration, and so forth. For example, the system may be designed with knowledge about where particular operating systems store configuration data (e.g., the Registry of MICROSOFT WINDOWS, or configuration file of UNIX). Continuing in block 260, the system adjusts the identified machine-specific data based on hardware of the target physical computer. The identified machine hardware and operating system instance specific information is modified to match the new hardware and the operating system instance and re-saved to the appropriate WINDOWS or other operating system file system volumes. This may include updating hardware configuration information, modifying operating system activation product keys, and so forth.
Continuing in block 270, the system finalizes the target computer system for booting into the deployed operating system. For example, the system may modify the boot settings of the target physical computer to indicate that the deployed operating system is the one that boots by default. Continuing in block 280, the system reboots the target physical computer, which will then boot into the deployed operating system. The target machine boots into the new operating system and hence completes the operating system deployment process. After block 280, these steps conclude.
Beginning in block 310, the system boots into a preinstallation environment on a target physical computer. For example, the target physical computer may boot into WinPE from a network or media device attached to the target physical computer. Continuing in block 320, the system retrieves a selected virtual image for deployment to the target physical computer. For example, a VHD that contains the virtual operating system image at this time may be accessible by the target physical computer locally or on the network. In some embodiments, the system deploys a program to the target machine at this point, named vhd2pd.exe that performs the remaining steps on the target system.
Continuing in block 330, the system opens the virtual image as a binary file and block copies the virtual image contents to a data store of the target physical computer. The contents of the VHD, which is the raw image of a storage medium, is deployed directly to the target physical computer (e.g., to a hard disk or flash storage). Note that unlike
Continuing in block 340, the system identifies the master boot record (MBR) of the virtual image and the MBR of the data store of the target physical computer. The MBR defines how partitions of storage media are used during boot and which partition is the active one to boot by default. The MBR may also invoke a boot loader that displays a boot menu or other pre-operating system software. Continuing in block 350, the system copies the identified virtual image MBR to the identified target physical computer MBR. The system may also realign the binary layout of the VHD content and the physical disk if the MBR of the VHD and that of the physical disk are not in the same location relative to the rest of the binary content.
Continuing in block 360, the system finalizes the target computer system for booting into the deployed operating system. For example, the system may modify the boot settings of the target physical computer to indicate that the deployed operating system is the one that boots by default. Continuing in block 370, the system reboots the target physical computer, which will then boot into the deployed operating system. The target machine boots into the new operating system and hence completes the operating system deployment process. After block 370, these steps conclude.
In some embodiments, the deployment system is used in conjunction with tools for converting a physical deployment to a virtual image. Thus, a system administrator can install an operating system on target hardware, configure the operating system, install various application programs, and then create a virtual image of the physical deployment. This allows the system administrator to only manage stored virtual images (rather than also creating physical images using imaging software like Norton Ghost or Acronis Truelmage). This simplifies the administrator's management tasks while providing a full range of flexibility in how images are created (physically or virtually) and deployed (physically and virtually).
As noted herein, the deployment system is not dependent on any particular operating system or file system to work. The methods described herein can be applied to any operating system and any type of file system data with which an operating system can be deployed. If the operating system runs on the target hardware and can be stored in a virtual image, then the deployment system can deploy the virtual image to physical hardware.
Although described herein for single operating system deployments to a particular target computer, the deployment system can be used to deploy more than one operating system to the same target computer. For example, many operating systems support dual or multi-booting, so that a single hard disk (or several hard disks) of a target computer can contain and boot multiple operating systems. Such systems typically provide a boot menu via a boot loader through which a user can select the operating system to use for any particular boot. In such situations, the system may modify the boot menu to include entries for each operating system deployed to the target computer. For example, this can be useful for test hardware where a particular target computer is used to test application behavior in a variety of operating systems (e.g., MICROSOFT WINDOWS XP, MICROSOFT WINDOWS Vista, and MICROSOFT WINDOWS 7).
From the foregoing, it will be appreciated that specific embodiments of the deployment system have been described herein for purposes of illustration, but that various modifications may be made without deviating from the spirit and scope of the invention. For example, although hard drives, storage media, and hard drive images are described herein, the deployment system is not limited to any one type of data storage hardware. The system can also be used with other current technologies, such as solid-state disk drives, as well as future data storage technologies. Accordingly, the invention is not limited except as by the appended claims.
