HK1172718B - Converting machines to virtual machines - Google Patents

Description

Converting a machine into a virtual machine

The application is a divisional application with application date of 2008, 11/10, application number of 200780016962.4 (international application number of PCT/US2007/006021) and name of 'convert machine into virtual machine'.

Background

Background and related Art

There are a number of ways of distributing different types of resources (software, hardware, or a combination thereof) in a computerized environment. For example, from a software perspective, an enterprise may install multiple copies of an operating system (or application) on multiple different computers, and thereby distribute one copy among multiple systems. A conventional way of sharing hardware involves setting up a computer system over a network to enable multiple different computer systems to access another computer's drive space for various storage or file sharing needs.

However, recent developments in hardware capabilities (i.e., existing storage, memory, and processing capabilities) mean that merely providing traditional storage and/or network traffic management functions tends to underutilize a given physical machine. Thus, another approach to distributing resources, now from a combined software and hardware perspective, involves installing multiple virtual computer systems on a single physical machine. In general, a virtual machine may be installed with a unique instance of a particular operating system on a designated portion of host storage and with an allocated portion of main memory and processing power.

Because of these and other features, virtual machines can be readily distinguished from other virtual machines, and even from the host servers on which they are installed. To other users on the network, the virtual machine appears only as an independently addressable computer system, such as any other physical computer system on the network. The virtual machine may then be used for various purposes, such as serving as another server on a network (e.g., an email or database server), a host computer system serving as a thin client for software or hardware testing purposes, and so forth.

In addition to this functionality, virtual machines may provide the additional benefit of being able to be installed and set up and removed fairly easily and in some cases fairly quickly. For example, an administrator of a particular host computer system may receive a request for a virtual machine, manually allocate the appropriate resources on the host computer, and then install the requested virtual machine. When the virtual machine is no longer needed, the administrator may manually select one or more commands to shut down or even delete the virtual machine at the host server. Thus, an organization may desire to reduce the number of its physical machines (servers, personal computers, etc.) by having one or a few host servers host roughly hundreds of virtual machines. It will be appreciated that such consolidation may provide a number of advantages, particularly if the organization may reduce various resource consumption and machine management costs, including power savings, temperature/cooling savings, space savings, and other savings that may be achieved due to reduced physical machine usage.

Unfortunately, it is not a simple matter to consolidate physical machines by converting a selected number of existing physical computer systems into virtual machines. In particular, merely copying the contents of a physical drive onto a partition of a host server is often insufficient to create a usable virtual machine. For example, performing a basic copy of a physical machine's driver while the physical machine is running may cause inconsistencies in the state of the file (i.e., the data is not "application consistent"). As such, an application that is accessing data on the physical machine may not be able to use a copy of the data when the data is later moved to the virtual machine. Additionally, merely transferring such a copy to the host server may result in other inconsistencies in the system registry, or inconsistencies with disk and network drivers, operating system binaries, and the like. While there are some mechanisms for circumventing these difficulties, conventional mechanisms for doing so typically involve significant downtime and resource expenditure (from both a human and software standpoint).

For example, one method of converting a physical machine involves creating a virtual machine from scratch at a virtual machine host. Specifically, an administrator may simply install all applications on the physical machine in a new virtual machine, transfer file system and application data to the virtual machine, and then recreate any other workload on the virtual machine from scratch and/or through application restore operations. Of course, this approach is undesirable from various perspectives and can result in a waste of resources for an organization, especially when attempting to convert hundreds of physical machines into virtual machines.

Another approach for converting physical machines involves creating a transferable copy of the physical machine components using fairly complex infrastructure components, such as automated deployment services ("ADS") and/or pre-installed executable environments ("PXE"), and the like. Typically, mechanisms for using this type of infrastructure include shutting down a physical machine and rebooting the physical machine with, for example, PXE. This allows an administrator to boot the physical machine without loading the native operating system and thus prohibit writing files during the replication process.

After copying the physical drive contents, the administrator can then transfer the contents to the virtual machine host. For gigabytes of data, this alone can take one or more hours. After transferring the data, the administrator then needs to perform a number of rather complex changes to the transferred data to make the copied content bootable as a virtual machine. This approach is often used when it is too difficult to simply rebuild the physical machine from scratch into a virtual machine, due at least in part to the downtime associated with taking the physical machine being converted offline and making the data bootable.

Thus, there are numerous problems associated with converting a physical machine to a virtual machine that may be addressed.

Brief summary

Implementations of the present invention solve one or more problems in the art with systems, methods, and computer program products configured to efficiently convert a physical machine into a virtual machine. In particular, implementations of the invention allow physical machine volume data to be quickly copied, transferred, and made bootable, such as at a virtual machine host (or other suitable computer system) or the like, without having to take the physical machine offline. In an implementation, for example, one or more application writers may be used to create an application (and/or file system) consistent snapshot of one or more physical machine volumes while the one or more volumes remain online (e.g., via a volume shadow copy service). These snapshots can then be transferred to a virtual hard disk file at the host server using efficient transfer means (e.g., block-level replication). Operational information (e.g., boot data, system registry, and binary code, etc.) associated with the transferred snapshot data can then be modified at the virtual machine host to make the transferred snapshot volume bootable.

For example, one example method of converting a physical machine to a virtual machine from the perspective of the physical machine without incurring significant downtime in accordance with an implementation of the present invention may involve identifying one or more hardware configuration settings for one or more volumes of the physical machine. The method may also involve creating one or more consistent snapshots corresponding to the one or more physical machine volumes. Additionally, the method may involve sending the one or more snapshots to the mounted virtual hard disk file. Further, the method may involve sending a boot record of the one or more consistent snapshots to the mounted virtual hard disk file. In this case, the boot record may form part of the operational information of the one or more consistent snapshots that may be modified (or created from scratch, if desired) at the virtual machine host.

Additionally, another example method from the perspective of a virtual machine of converting a physical machine to a virtual machine in accordance with an implementation of the present invention may involve creating a virtual hard disk file having a file size. The method may also involve mounting the virtual hard disk file at a virtual machine host. In this case, the virtual hard disk file may appear as a physical disk accessible to the operating system. Additionally, the method may involve receiving one or more consistent snapshots corresponding to the one or more physical machine volumes. Further, the method may involve modifying operational information of the one or more consistent snapshots. In this manner, the one or more consistent snapshots can be tailored to the operating system at the virtual machine host, such as through changes to boot records, drivers, operating system binaries, system registry, and/or configuration preferences, among others. Also, the method may involve removing the mount of the virtual hard disk file. The virtual hard disk file is therefore not accessible as a physical disk, but can boot as a virtual machine.

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 as an aid in determining the scope of the claimed subject matter.

Additional features and advantages of exemplary implementations of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of such exemplary implementations. The features and advantages may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features will become more fully apparent from the following description and appended claims, or may be learned by the practice of such exemplary implementations as set forth hereinafter.

Brief Description of Drawings

In order to describe the manner in which the above-recited and other advantages and features of the invention can be obtained, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered to be limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

FIG. 1A illustrates a schematic diagram in which one or more snapshots are taken of one or more physical disk volumes and one or more virtual hard disk files are created at a virtual machine host, according to one implementation of the invention;

FIG. 1B illustrates the schematic diagram of FIG. 1A in which data of one or more snapshots of a physical disk volume is transferred into a created virtual hard disk file using an efficient transfer mechanism;

FIG. 1C illustrates a schematic diagram of FIGS. 1A-1B in which a virtual hard disk file containing transferred snapshot data is modified to create a bootable virtual machine, according to one implementation of the invention; and

fig. 2 illustrates a flow diagram of a method for converting one or more machines into a corresponding one or more virtual machines from the perspective of a physical machine and a virtual machine host.

Detailed Description

The present invention extends to systems, methods, and computer program products configured to efficiently convert a physical machine to a virtual machine. In particular, implementations of the invention allow physical machine volume data to be quickly copied, transferred, and made bootable, such as at a virtual machine host (or other suitable computer system) or the like, without having to take the physical machine offline. In an implementation, for example, one or more application writers may be used to create an application (and/or file system) consistent snapshot of one or more physical machine volumes while the one or more volumes remain online (e.g., via a volume shadow copy service). These snapshots can then be transferred to a virtual hard disk file at the host server using efficient transfer means (e.g., block-level replication). Operational information (e.g., boot data, system registry, and binary code, etc.) associated with the transferred snapshot data can then be modified at the virtual machine host to make the transferred snapshot volume bootable.

Thus, implementations of the invention may provide advantages such as relatively fast, "one-stop" physical-to-virtual machine transitions in a manner that may avoid physical machine outages. Furthermore, because the converted machines are consistent at the virtual machine host, implementations of the invention allow for reliable "one-stop" physical to virtual machine conversion. As will be more fully understood from the following description and claims, such conversions may be achieved with any number of suitable components and modules. For example, implementations of the invention may include using components and mechanisms in volume shadow copy service ("VSS") to create application (and/or file system) consistent snapshots. These components may create one or more consistent snapshots (or point-in-time images) of one or more physical machine volumes running during the snapshot process.

Additionally, implementations of the present invention may include the use of a reel service ("VDS") and/or related components. Generally speaking, a VDS (or related components) includes a platform for creating and configuring volumes on physical disks. Further, various implementations of the invention include the use of a "disk image maker (disk image) and, in some cases, an" image loader (image generator) ". In general, a disk image maker includes components and/or modules configured to create a block (or byte block) based copy of a physical disk or volume given a starting location and a number of bytes (or byte blocks) to copy. Instead, the image loader tool includes one or more components and/or modules configured to expose a virtual hard disk file as a physical disk, for example, by taking the file as input and mounting the virtual hard disk file in a file system. The exposed physical disk may be made accessible to the operating system as any other physical disk, including the ability to write data in its volume.

Implementations of the invention also include using virtual hard disk files ("VHD" files) at a virtual machine host, where the VHD files include one physical disk and one or more physical disk volumes managed (and internally accessible) by one or more virtual machines ("VMs"). While the terms "virtual machine," "virtual machine host," and "VHD file" are used in some Microsoft environments, it is understood that references herein to Microsoft components (and/or WINDOWS SERVER components) are merely exemplary. In particular, it will be appreciated upon reading this specification and the claims that the components, modules and/or mechanisms described herein may be found and implemented in a variety of operating environments that implement virtual machines or related such entities.

Referring now to FIG. 1A, there is shown a schematic diagram of an exemplary computerized environment 100 in which a physical machine 105 (e.g., a personal computer, a physical server, etc.) can be converted to a virtual machine hosted at virtual machine host 110. At a basic level, converting a physical machine (e.g., 105) to a virtual machine (e.g., 175, fig. 1C) may involve taking a snapshot of one or more physical machine volumes (e.g., 115), creating a virtual machine hard disk file (e.g., 140) at the virtual machine host, transferring the snapshot to the VHD file, and then making one or more transferred snapshot volumes in the VHD file bootable as a virtual machine (e.g., 175). Thus, it can be appreciated that there are a variety of different preparatory and post-operative procedures that can be implemented to make the conversion efficient.

For example, in at least one implementation, the conversion process may be initiated by using conversion module 130 (i.e., which may include one or more modules at machine 105 and/or host 110) that initiates snapshot operations of one or more volumes (e.g., volume 115) on a physical disk of physical machine 105. In general, translation module 130 may include any suitable writers and requestors configured to create consistent shadow copies of physical disk volumes. For example, as previously described, such writers and requesters may be provided in a volume shadow copy service. Thus, for example, conversion module 130 may begin the conversion process by sending a signal to all application writers in each of one or more volumes of the physical disk (e.g., volume 115) to begin a snapshot operation of its data. For example, as shown, volume 115 includes at least volume data 125, and boot record 120.

Upon receiving this message from the translation module 130, each application writer on the volume 115 may flush its in-memory data to physical disk and/or freeze any file system or volume logs. For applications that do not use an application writer, the translation module 130 may instruct (e.g., by default, or by command of a user or administrator) to close the application and thereby ensure that no writes are made during the snapshot. Thus, FIG. 1A illustrates that the conversion module 130 can then create a single, point-in-time snapshot (i.e., copy) of all the volume data on the volume 115. For example, FIG. 1A shows that the conversion module 130 has created a snapshot 117 (i.e., a "snapshot volume") of the volume 115, where the snapshot 117 in this case includes volume data 127 and boot record 120.

It will be appreciated that various optimizations may be performed in taking snapshots or performing snapshot (and copy) operations to ensure that data is copied and transferred in an efficient manner. For example, the translation module 130 may identify what portions (i.e., including data) of the volume 115 are being used and what portions are free. The snapshot operation may thus be configured to copy only the used portion of the volume or physical disk, rather than the entire volume or entire physical disk. Additionally, the snapshot operations may also be configured to avoid certain files that may be less useful (or not useful at all) in the virtualized environment.

For example, the snapshot operations may be further configured to identify files such as those included in volume diff areas, page files, bad clusters, hibernation files, and the like, among others. These files can thus be avoided when creating snapshot 117 or performing a byte block transfer, and further reduce the amount of data that needs to be transferred to virtual machine host 110. It is to be appreciated that these types of files and optimizations are susceptible to change in various operating environments for other types of files, used or free space computations, and so forth.

Regardless, and by way of explanation, data 127 in snapshot 117 is generally different from original data 125 on volume 115, primarily due to temporal changes during (and/or after) snapshot operations. For example, volume data 125 may continue to change because physical machine 105 is still running during the snapshot operation, such as if the user continues to write to particular application data. Thus, volume data 127 (i.e., "volume data 127") represents an early consistent point in time for data 125 on volume 115, which is essentially the point in time at which conversion module 130 initiates the snapshot process.

However, FIG. 1A also shows that boot record 120 is the same on snapshot 117 as it is on the running data of volume 115. That is, it can be appreciated that during the snapshot process, the boot record is unlikely to change because the application is typically unable to access the boot record (e.g., 120). In particular, boot records are typically changed by the operating system, and are typically changed on a rare (if not nonexistent) basis. As such, fig. 1A shows that boot record 120 is the same in this case as it was prior to the snapshot operation.

Before, during, or shortly after creating snapshot 117, conversion module 130 can also set up one or more virtual hard disk ("VHD") files 140 at virtual machine host 110 that correspond to physical machine 150 physical disks (not shown). For example, FIG. 1A shows conversion module 130 sending message 150 to create a writable virtual hard disk file 140. In an implementation, this may also include first sending a message to create a VHD file of a particular fixed size (e.g., 140), and then sending a separate message to make the VHD file writable. (conversion module 130 can also send messages to create VHD files of dynamic size (writable or otherwise) that grow in size as data is added.)

In general, each VHD file may be configured to correspond to a single physical disk of the computer system, and each volume in the physical disk may likewise be represented in a newly created VHD file. However, in some cases, the VHD files may represent a single volume, rather than an entire physical disk. Nonetheless, in the physical disk example where the physical disk has multiple volumes (although only a single volume 115 is shown), the new VHD may also contain data corresponding to the multiple volumes. Of course, there is some flexibility in this regard. For example, if a user of physical machine 105 has one volume (and/or mirrored volume, etc.) that spans multiple partitions, the user may decide to dedicate only one partition to snapshot data in the target virtual hard disk file. Similarly, a user may decide to transfer only one volume of a physical disk comprising multiple volumes to a virtual hard disk file.

Thus, the size of the VHD file is typically at least as large as the size of the source (e.g., physical disk, a particular physical disk volume, data in physical disk, etc.) data transferred may require. As such, it can be appreciated that the techniques herein can also be used when replicating existing virtual machines to larger storage spaces. For example, an administrator, upon identifying that the volume storage capacity of the virtual machine is decreasing, may create an additional larger VHD file, snapshot the virtual machine data, and essentially "re-virtualize" the virtual machine by transferring (e.g., copying) its snapshot data to the new VHD file using the same process already described.

Thus, implementations of the invention include not only "physical to virtual" machine translation, but also "virtual to virtual" machine translation. In particular, and in some cases, implementations of the invention may also be more generally referred to as converting a "machine" to a "virtual machine". That is, a "machine" can be understood to include both a "physical" computer system (e.g., a desktop computer with associated hardware and operating system) and a "virtual" computer system (e.g., a computer system installed as the only computer system at a virtual machine host).

In any event, after virtual hard disk file 140 is created, conversion module 130 mounts file 140 as a physical disk so that file 140 can receive the data of snapshot 117 via, for example, network communication. (it will be appreciated that in some implementations described herein, a mount may not even be required.) thus, FIG. 1A also illustrates translation module 130 sending a message 155 to mount virtual hard disk file 140. In additional or alternative implementations, message 155 can include an instruction to mount VHD file 140 on virtual machine host 110, physical machine 105 being converted, or any of the places where there is a network connection between the machine on which VHD file 140 is mounted and the physical machine being converted (i.e., 105 in this case).

Mounting a portion of file 140 may include associating the file with one or more device identifiers, such as a device ID of a physical disk. For example, virtual machine host 110 can be instructed to mount virtual hard disk file 140 so that it can be identified by a drive path such as "\ \ device \ Harddisk145\ device \ hard disk145 \". In particular, FIG. 1B illustrates that VHD140 can be identified as "disk drive 145". Similarly, the translation module 130 may also identify a device identifier (and/or, for example, a mount point) for each snapshot (e.g., 117). Finally, conversion module 130 may transmit snapshot content using the device identifiers of any snapshots identified and any corresponding VHD files.

In general, conversion module 130 may use any number of data transfer mechanisms to transfer snapshot 117 content. For example, in one implementation, conversion module 130 may transfer snapshot 117 to file 140 on a byte-by-byte basis via disk drive 145. However, in additional or alternative implementations, conversion module 130 may transfer snapshot 117 to file 140 by identifying and transferring "byte blocks". In general, a chunk of bytes comprises a fixed sequence (of any arbitrary size) of individual bytes. In at least one implementation, transferring chunks rather than individual bytes may significantly increase the speed at which snapshot 117 may be transferred over a network.

For example, gigabytes of data that might normally take several hours to transfer to virtual machine host 110 over a conventional network transfer protocol may in some cases be transferred in just a few minutes using a byte block transfer mechanism. In any event, FIG. 1B shows that in this case, the translation module 130 transfers bytes (or byte blocks) "1601", "1602", etc. and transfers these bytes/byte blocks directly to the writable virtual hard disk file 140 via the disk drive 145. As shown in FIG. 1B, virtual hard disk file 140 may have all boot data 120 and will include other volume data 127 captured in snapshot 117 when the data transfer is complete.

Despite this data transfer, virtual hard disk file 140 may not necessarily be bootable at virtual machine host 110 because one of the reasons that the boot data and drivers may not be useful in the context of virtual machine host 110 is that the "virtual hardware" present in the virtual machine environment (and/or in virtual machine host 110) may be different from the hardware of physical machine 105. For example, components such as a kernel and hardware abstraction layer ("HAL") on the physical machine 105 may be based on, for example, a dual processor system. In addition, virtual machine host 110 can emulate to the hosted virtual machine a different network card driver, processor architecture, physical disk (e.g., storage attached to the machine), physical disk identifier, operating system driver, and disk driver that might otherwise not be found at the source machine (e.g., physical machine 105) being translated. This difference may also exist when transitioning a physical disk volume from a virtual host to a virtual machine.

As a result, transferred boot data 120 may be based on operating system characteristics at physical machine 105 that are not necessarily applicable to the appropriate virtualization environment at virtual machine host 110. These and other reasons mean that an administrator may need to make a number of different modifications depending on the particular operating environment. Thus, the conversion module 130 can also modify the virtual hard disk file 140 to be bootable at the virtual machine host. In some cases, this may include instructions to update the kernel and HAL and other driver and registry settings of the virtual machine to be created based on the snapshot data.

Thus, for example, fig. 1C shows that translation module 130 also sends request 165 and corresponding arguments to virtual machine host 110 to modify the operation information. (in some cases, these modifications to the operating information of the virtual machine (e.g., boot sector and registry information) may even be done at the physical machine (before being transferred into the VHD file.) in one implementation, this may include the translation module 130 examining the boot record of the volume snapshot 117 and replacing the previously transferred boot data 120 with new boot information (e.g., modified boot information, or new boot information from scratch) based on the virtual machine's new disk and volume configuration. In another step, translation module 130 can also check the transferred registry information (not shown) of volume snapshot 117 and update the transferred registry information in a manner appropriate for virtual machine 110 based on the new hardware and drivers present at virtual machine host 110.

Such updating may also include changing system binaries, such as kernels and HAL drivers, from multi-processor to single-processor hardware configurations. Additionally, such updates can include adding computer and drive identity information unique to virtual machine host 110, adding any appropriate disk or file driver unique to virtual machine host 110, and changing registry information to accommodate an appropriate network driver, storage driver, and the like. Such updating may also include replacing a driver of the physical device with a driver of the virtual device, disabling a driver of the hardware if there is no corresponding virtual device in the virtual environment, and disabling device-dependent services and applications if there is no corresponding virtual device in the virtual environment.

Additionally, translation module 130 may also create these and/or other appropriate configuration values for the intended virtual machine (e.g., 175) to cause the resulting virtual machine (e.g., 175) to operate with the same preferences (e.g., memory, CPU, etc.) as at the original physical machine 105. In this regard, the administrator of virtual machine host 110 can also (or alternatively) modify these preferences of the resulting virtual machine. Moreover, the administrator may even build this operational information (i.e., configuration values, preferences, etc.) from scratch. In any case, it is understood that multiple entities may make any number of appropriate configuration changes to ensure that the resulting virtual machine is bootable and operates properly on the virtual machine premises (e.g., virtual machine host 110).

After the appropriate boot record (i.e., from 120 to 123), system registry information, driver information, and/or other configuration or preference information is appropriately modified/created, the translation module may then remove the mount of the virtual hard disk file 140 (i.e., "unmount") so that it can no longer be accessed as a drive. For example, figure 1C shows conversion module 130 sending a message 170 to virtual machine host 110 instructing virtual machine host 110 to remove the mount of virtual hard disk file 140. Upon removal of the mount, virtual hard disk file 140 may be used as virtual machine 175, the data of which is essentially the same as the data of volume 115 at the point where the snapshot operation was initiated.

In particular, the data in the volume managed by new virtual machine 175 is consistent from a variety of appropriate perspectives (e.g., application consistent, file system consistent, and/or crash consistent, etc.). As a result, a previous user of physical machine 105 will now be able to boot virtual machine 175 at virtual machine host 110 and use the virtual machine (including accessing previous data) as (or better than) the user used physical machine 105. In addition, it is understood that VHD files may be portable in general. For example, an end user can, in at least one implementation, transfer virtual machine 175 to any desired location (i.e., another virtual machine host) simply by transferring the virtual machine files (e.g., VHD files, etc.) associated with virtual machine 175 to the desired location and performing any necessary operational information updates.

In another implementation, one or more VHD files (e.g., 140) may even be created at physical machine 105 itself and then sent/transferred to the appropriate virtual machine host (e.g., 110). For example, a user of physical machine 105 may create a VHD file (e.g., 140) at the physical machine and transfer snapshot content about data of interest at the physical machine to the VHD file. This is at least one way that a user can avoid mounting the VHD file (i.e., at virtual machine host 110), if desired. In either case, the user can then send/transfer the VHD file and corresponding snapshot contents to the appropriate destination (e.g., virtual machine host 110) and change the corresponding operational information at the destination. Alternatively, a user may change the operational information and snapshot content of a VHD file at the source (e.g., physical machine 105) even before sending the VHD file and snapshot content to a new destination.

In some cases, rather than creating a VHD "file" as such, a module (e.g., translation module 130) may be configured to stream snapshot data and VHD metadata created at physical machine 105 from storage into portions (e.g., byte blocks) suitable for efficient transport. The data to be streamed may also be formatted in VHD format according to the appropriate VHD format/content specification. Thus, after being transferred to the destination (e.g., virtual machine host 110), the stream is then saved as a VHD file because the streamed data is generated in VHD format. This is another way to avoid mounting VHD files.

1A-1C illustrate a number of schematic diagrams and components that may be used to create a snapshot of physical machine volume data and a new virtual machine from the data in accordance with various implementations of the invention. In addition to the foregoing, implementations of the invention may be described in terms of flowcharts of methods comprising one or more acts for achieving a particular result. For example, fig. 2 shows a flow diagram of a method for converting a machine, such as a physical machine or a virtual machine, to a different virtual machine from the perspective of physical machine 105 and virtual machine host 110. The method of fig. 2 will be described below with reference to components according to the mechanisms in fig. 1A to 1C.

For example, figure 2 shows that a method from the perspective of physical machine 105 of converting a physical machine to a virtual machine at a virtual machine host without incurring significant downtime on one or more physical machine volumes can comprise an act 200 of identifying a hardware configuration of the physical machine. Act 200 includes identifying one or more hardware configuration settings for one or more volumes of a machine. For example, FIG. 1A illustrates a conversion module 130 that may identify hardware (and/or software) configuration settings on volume 115 prior to initiating a snapshot process. This may include identifying boot record 120 and volume data 125 as they exist on volume 115 of physical machine 105, and may also include identifying whether the data is configured for use in a multiprocessor environment, incompatibilities in files supported by the operating system, whether there are storage and network drivers to consider, and so forth.

Additionally, figure 2 shows that the method from the perspective of physical machine 105 can comprise an act 210 of creating a snapshot of one or more volumes. Act 210 includes creating one or more consistent snapshots corresponding to the one or more machine volumes. For example, FIG. 1A shows that the conversion module 130 creates a snapshot 117 of the volume 115 that includes the same boot record 120 and volume data 127 as before. In at least one implementation, translation module 130 may invoke writer-involved snapshot processes available on volume 115 or simply close applications (or other write processes) where these writers are not available. As a result, the data in snapshot 117 can be guaranteed to be consistent (e.g., application consistent) for a single instance of time after the snapshot process.

Figure 2 also shows that the method from the perspective of physical machine 105 can comprise an act 220 of sending the snapshot to the mounted virtual disk file. Act 220 includes sending the one or more consistent snapshots to the mounted virtual hard disk file. For example, translation module 130 retrieves the device identifier of each snapshot taken at physical machine 105 and further retrieves any device identifiers of each virtual hard disk file mounted at virtual machine host 110. Upon retrieving the appropriate device identifier, FIG. 1B shows that conversion module 130 may transfer volume data 127 of snapshot 117 to virtual hard disk file 140, such as using a byte (or byte block) transfer/copy mechanism.

Figure 2 also shows that the method from the perspective of physical machine 105 can comprise an act 230 of sending a boot record to the mounted virtual disk file. Act 230 includes sending the boot record for the one or more consistent snapshots to the mounted virtual hard disk file so that the boot record for the one or more consistent snapshots can be modified at the virtual machine host. For example, FIG. 1B shows that translation module 130 also sends boot data 120 to virtual hard disk file 140. Fig. 1C also shows that conversion module 130 can send message 165 to modify boot record 120 to record 123 so that boot record 123 is consistent with the operating environment of virtual machine host 110. In one implementation, a new boot record for a new virtual machine may simply be created from scratch, rather than just sent and modified.

In addition to the foregoing, figure 2 shows that a method from the perspective of virtual machine host 110 of converting a machine (i.e., a physical machine or a previous virtual machine) to a virtual machine at the virtual machine host without incurring significant downtime on one or more machine volumes can comprise an act 240 of creating a virtual hard disk file. Act 240 includes creating a virtual hard disk file having a file size. For example, fig. 1A shows virtual machine host 110 receiving message 150 instructing virtual machine host 110 to create a writable virtual hard disk file, and an instruction to make the new virtual hard disk file writable. In response, virtual machine host 110 creates and makes writable virtual hard disk file 140. As previously mentioned, the virtual hard disk file size may be static or dynamic. For example, the virtual hard disk file 140 may be set to 100GB to accommodate 50GB of volume 115 data. Alternatively, the translation module 130 sets the virtual hard disk file 140 to grow dynamically with additional data transfers.

Figure 2 also shows that the method from the perspective of virtual machine host 110 can comprise an act 250 of mounting the virtual hard disk file. Act 250 includes mounting the virtual hard disk file at the virtual machine host such that the virtual hard disk file appears as an accessible physical disk. For example, fig. 1A shows virtual machine host 110 receiving a request 155 to mount virtual hard disk file 140. In an implementation, virtual machine host 110 may be instructed to associate file 140 with a particular device identifier and then mount the identifier as a physical device. The virtual hard disk file 140 may then be viewed and accessed as a disk device 145.

Additionally, the method from the perspective of virtual machine host 110 can comprise an act 260 of receiving one or more snapshots. Act 260 includes receiving data corresponding to one or more consistent snapshots of one or more physical machine volumes. For example, as shown in fig. 1B, virtual machine host 110 receives volume data 127 and boot data 120 by using any suitable transport mechanism (i.e., byte-by-byte or byte-by-byte block, etc. over any network transport protocol).

Moreover, figure 2 shows that the method from the perspective of virtual machine host 110 can comprise an act 270 of modifying the boot record. Act 270 includes modifying operational information of the one or more consistent snapshots to adapt the one or more consistent snapshots to an operating system at the virtual machine host. As shown in fig. 1C, for example, virtual machine host 110 receives message 165 to modify the operation information. For example, message 165 may include one or more requests to identify appropriate virtual machine host 110 criteria and to change boot data 120 to boot data 123 in an appropriate manner. Message 165 (or another message-not shown) may also include one or more requests to change the registry and/or operational preference information.

These changes in operating characteristics may include, for example, any number of hardware and operating system configurations (e.g., any number of processors, hardware drivers, disk and storage drivers/identifiers, network drivers, etc.). These changes may need to be accounted for to ensure that the new operating system of the virtual machine is compatible and functioning properly with the virtual environment. Changes to operating characteristics may also include various registry manipulations, such as the use of drivers and other hardware, the identity of replaced and/or registered drivers in binary code, updates to kernel and/or HAL information, and the like. Changes in operating characteristics may also include various configuration preferences for the virtual machine, such as those regarding memory and/or CPU requirements.

Additionally, figure 2 shows that the method from the perspective of virtual machine host 110 can comprise an act 280 of removing the virtual hard disk file mount. Act 280 includes removing the hard disk file mount such that the virtual hard disk file is no longer accessible as a physical disk. For example, virtual machine host 110 receives message 170 requesting virtual machine host 110 to remove the mount of virtual hard disk file 140. Virtual machine host 110 can then unload the virtual hard disk file so that file 140 no longer acts as a host-level disk drive accessible locally or over a network. As a result, virtual disk file 140 can boot as virtual machine 175 containing data that is consistent for a single instance in time and is ready to operate at virtual machine host 110. Specifically, and from the perspective of the end user, virtual machine 175 is essentially the same form (i.e., the same data or a subset of the data thereof) of physical machine 105 prior to the snapshot operation for all virtual intents and purposes.

1A-1C and FIG. 2 thus provide a number of components and mechanisms for converting a machine (e.g., a physical machine or a previous virtual machine) to a virtual machine. In particular, these figures and corresponding text describe how implementations of the present invention can be implemented in at least one aspect without having to reboot the machine being converted and/or without having to reboot into an ADS or PXE environment. As such, the components and mechanisms described above allow for a physical machine to be created fairly quickly, such as at conventional disk and network transport speeds.

As previously mentioned herein, the various implementations of the present invention may be changed or modified for a wide variety of optimizations and a wide variety of hardware and operating system environments. For example, implementations of the present invention may be readily applied to the conversion of any type of machine to a new virtual machine. For example, with respect to a previous virtual machine, a user may desire to create more storage space for the virtual machine whose volumes may have overflowed. Thus, a user can create one or more VHD files that are larger than previous VHD files of previous virtual machines, snapshot the previous virtual machine data, and transfer the virtual machine snapshots to these larger VHD files. Furthermore, the conversion process described herein may be further divided into a number of separate steps, in addition to those explicitly described. For example, if a user has a method to transfer a volume image to a target machine, the user may simply invoke a fix-up operation to "virtualize" the image, or otherwise, to make the image bootable at the target machine.

In addition to the above, it is readily appreciated that implementations of the present invention may also be applied to a variety of disk configurations. For example, the physical disk on which machine volume 115 is mounted may be any one or more basic or dynamic disks in an operating system, and may also have various partitions and/or volumes. Nonetheless, the processes, components, and mechanisms described herein may be applied to these variations in virtual machines as they were on previous machines (e.g., physical machines or previous virtual machines). In particular, features associated with the physical dynamic or underlying disk may be transferred to the virtual machine host to cause the new virtual machine to function with these basic or dynamic disk characteristics as it did previously. Thus, the various components, modules, and mechanisms described herein may be broadly applied to ensure seamless transition from a previous machine to a newly virtualized form of the previous machine.

Embodiments of the present invention may comprise a special purpose or general-purpose computer including various computer hardware, as discussed in further detail below. Embodiments within the scope of the present invention also include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer.

By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a computer-readable medium. Thus, any such connection is properly termed a computer-readable medium. Combinations of the above should also be included within the scope of computer-readable media.

Computer-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims (5)

1. A method of converting a computer to a virtual machine at a virtual machine host, the method comprising:

identifying one or more hardware configuration settings for one or more volumes of a computer;

creating one or more consistent snapshots corresponding to one or more volumes of the computer;

sending the one or more consistent snapshots to the mounted virtual hard disk file; and

sending a boot record of the one or more consistent snapshots to the mounted virtual hard disk file such that the boot record of the one or more consistent snapshots can be modified at the virtual machine host.

2. The method of claim 1, wherein the virtual machine host is configured as a host of one or more virtual machines.

3. The method of claim 1, wherein the snapshot can be modified at the virtual machine host such that the snapshot is appropriate for an operating system at the virtual machine.

4. The method of claim 1, wherein creating one or more consistent snapshots corresponding to one or more volumes of the computer comprises creating one or more consistent snapshots corresponding to one or more volumes of the computer while the one or more volumes of the computer are active.

5. The method of claim 1, wherein the one or more volumes of the computer comprise a plurality of computer volumes mounted on dynamic physical disks.