KR20090025204A - Converting machines to virtual machines - Google Patents

Abstract

Physical (or prior virtual) machine volumes can be converted to virtual machines at a virtual machine host while the physical machines are running. In one implementation, a volume shadow copy service can 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 are running. The snapshot data can then be transferred to a mounted virtual hard disk file (dynamic or fixed) at a virtual machine host. Operational information (e.g., boot record, system registry, drivers, devices, configuration preferences, etc.) associated with the virtual hard disk file and the operating system(s) within the virtual machine can then be modified as appropriate to ensure that the corresponding virtual machine is bootable and functional at the virtual machine host. The virtual hard disk file can then be un-mounted, and used as a new virtual machine.

Description

How to convert a machine into a virtual machine and computer program product {CONVERTING MACHINES TO VIRTUAL MACHINES}

There are many ways to distribute different types of resources (software, hardware, or a combination) in a computerized environment. For example, from a software perspective, an enterprise can install multiple copies of an operating system (or application program) on a plurality of different computers, thereby distributing one copy across multiple systems. Common methods of sharing hardware include setting up a computer system on a network such that a plurality of different computer systems can access the drive space of another computer for various storage or file sharing needs.

However, recent developments in hardware performance (ie, current storage, memory, and processing capacity) suggest that simply providing conventional storage and / or network traffic management functions can maximize the performance of a given physical machine. It means that there is a tendency to be unavailable. In such a case, an additional method of distributing resources in terms of combined software and hardware now includes installing a plurality of virtual computer systems on a single real system. In general, a virtual machine may be installed using a unique instance of a particular operating system on a dedicated portion of the host's storage device and an allocation portion of host memory and processing power.

Because of these and other features, virtual machines can be easily distinguished from other virtual machines, even from host servers on which they are installed. To other users on the network, the virtual machine will simply appear as a separately addressable computer system, such as any other real computer system on the network. The virtual machine is then used as another server on the network (e.g., an email or database server), for software or hardware testing purposes, as a main computer system for thin clients, or the like. It can be used for a wide range of purposes.

In addition to these features, virtual machines can also provide the added benefit of being fairly easy to install and set up in some cases as well as to be removed. For example, an administrator for a particular host computer system can receive a request for a virtual machine and manually allocate the appropriate resources on the host computer to install the requested virtual machine. When a virtual machine is no longer needed, the administrator can manually select one or more commands to shut down the virtual machine or even remove the virtual machine from the host server. Thus, an organization may want to reduce the number of real machines (servers, personal computers, etc.) by having one or several host servers potentially host hundreds of virtual machines. In particular, this consolidation can be achieved if the organization is able to reduce a variety of resource consumption and machine management costs, including power savings, temperature / cooling savings, space savings, and other savings available by reduced real machine usage. It will be appreciated that the present invention may provide a number of advantages.

Unfortunately, integrating real machines by converting multiple existing real computer systems into virtual machines is not a simple matter. In particular, simply copying the contents of the physical drive to a partition on the host server is generally not enough to create a usable virtual machine. For example, performing a basic copy of a drive on a real machine while the real machine is running may create inconsistency in the file state (ie, data is not "application-consistent"). Can be. As such, an application that is accessing data on a real machine is not able to use a copy of the data when it is later moved to the virtual machine. Also, simply transferring these copies to the host server can cause other inconsistencies in the system registry, inconsistencies with multiple disks and network drivers, inconsistencies in the operating system binaries, and so on. . Although some mechanisms exist to overcome these difficulties, conventional mechanisms for doing so typically involve significant downtime and resource wastage (both in human and software).

For example, one method of converting a real machine involves creating a virtual machine from scratch on a virtual machine host. In particular, the administrator simply installs all the applications on the physical machine into the new virtual machine, transfers the file system and application data to the virtual machine, and then uses any other in the virtual machine from nothing and / or through application restore operations. You can rebuild your workload. Of course, this approach is not desirable in many respects, especially if you are trying to convert hundreds of real machines into virtual machines, which can waste your organization's resources.

Another way to convert a physical machine is to use a fairly complex infrastructure such as an Automated Deployment Service (ADS) and / or a Pre-Installation Executable Environment (PXE) to create a transferable copy of the physical machine's content. ) Using the component. In general, mechanisms using this type of infrastructure include shutting down the real machine and rebooting the real machine, for example using PXE. This can prevent administrators from writing to the file during the copying process because it allows administrators to start the real machine without loading their own operating system.

After copying the actual drive content, the administrator can deliver the content to the virtual machine host. This alone can take an hour or more for gigabytes of data. Once the data has been delivered, the administrator needs to make a number of relatively complex changes to the delivered data in order to make the copied content bootable as a virtual machine. This method is typically at least partly due to the downtime associated with taking the physical machine that is being converted offline and making the data bootable. This is done when it is too difficult to simply rebuild the real machine as a virtual machine from nothing.

Thus, there are several issues associated with converting a real machine into an addressable virtual machine.

<Overview of invention>

Implementations of the present invention solve one or more problems in the art using systems, methods, and computer program products that are configured to efficiently convert real machines into virtual machines. In particular, implementations of the present invention may allow real machine volume data to be quickly copied, transferred, and booted to a virtual machine host (or other suitable computer system), and the like, without having to take the physical machine offline. In one implementation, for example, one or more application writers (eg, via a volume shadow copy service) may have one or more physical machine volumes while one or more volumes remain online. Can be used to create an application (and / or file system) -consistent snapshot of a. The snapshot (s) can then be delivered to a virtual hard disk file on the host server using efficient delivery means (eg, block level copy). In addition, operational information (e.g., boot data, system registry and binaries, etc.) associated with the delivered snapshot data may be modified on the virtual machine host, thereby making the delivered snapshot volume bootable. have.

For example, from the perspective of a real machine, one exemplary method in accordance with an implementation of the present invention that converts a real machine into a virtual machine without incurring significant downtime is one for one or more volumes of the real machine. Identifying the above hardware configuration settings may include. The method may also include creating one or more consistent snapshots corresponding to one or more actual machine volumes. The method may also include transferring one or more snapshots to a mounted virtual hard disk file. The method may also include transmitting a boot record for one or more consistent snapshots to the mounted virtual hard disk file. In such a case, the boot record may form part of the operational information for one or more consistent snapshots that may be changed (or, if needed, created from nothing) on the virtual machine host.

In addition, from the point of view of the virtual machine host, another exemplary method according to an implementation of the present invention for converting a real machine into a virtual machine may include creating a virtual hard disk file having a file size. The method may also include mounting the virtual hard disk file on the virtual machine host. In this case, the virtual hard disk file may appear as a physical disk accessible to the operating system. The method may also include receiving one or more consistent snapshots corresponding to one or more actual machine volumes. The method may also include changing operational information for one or more consistent snapshots. As such, one or more consistent snapshots can be made appropriate to the operating system on the virtual machine host, for example, through changes to boot history, drivers, operating system binaries, system registry, and / or configuration preferences. The method may also include removing the mount of the virtual hard disk file. Thus, a virtual hard disk file may not be accessible as a physical disk, but may be bootable as a virtual machine.

An overview of the invention is provided to introduce a selection of concepts in a simplified form that are further described below in the Examples. The Summary of the Invention 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 are set forth in the following examples, and in part will become apparent from the embodiments, or may be learned by practice of such exemplary implementations. The features and advantages of such an implementation can be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features will be more fully apparent from the following examples and the appended claims, or may be learned by practice of example implementations such as those described below.

BRIEF DESCRIPTION OF DRAWINGS To describe the above-described advantages and features of the present invention and the manner in which other advantages and features can be obtained, a more detailed description of the present invention briefly described above is shown with reference to the specific embodiments shown in the accompanying drawings. . It is to be understood that these drawings are only to be considered as limiting the scope thereof since they are merely illustrative of typical embodiments of the invention, and further features and details of the invention will now be described and described through the use of the accompanying drawings. .

1A is an overall schematic diagram in accordance with one implementation of the present invention in which one or more snapshots are taken from one or more physical disk volume (s) and one or more virtual hard disk files are created on a virtual machine host.

1B is an overall schematic diagram of FIG. 1A in which data of one or more snapshots of the physical disk volume (s) is transferred to the created virtual hard disk file using an efficient delivery mechanism.

1C is an overall schematic diagram of FIGS. 1A and 1B in which a virtual hard disk file containing the transferred snapshot data is modified to create a bootable virtual machine in accordance with one implementation of the present invention.

2 is 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 real machine and a virtual machine host.

The present invention extends to systems, methods, and computer program products configured to efficiently convert real machines into virtual machines. In particular, implementations of the present invention may enable the rapid copy, transfer, and booting of real machine volume data, such as on a virtual machine host (or other suitable computer system), without having to take the real machine offline. In one implementation, for example, one or more application writers (eg, through a volume shadow copy service) may have applications (and / or file systems) of one or more physical machine volumes, while one or more volumes remain online. Can be used to create a consistent snapshot. The snapshot (s) can then be delivered to a virtual hard disk file on the host server using efficient delivery means (eg, block level copy). And, operation information (eg, boot data, system registry, binary, etc.) associated with the transferred snapshot data may be changed in the virtual machine host, thereby making the transferred snapshot volume bootable.

Thus, implementations of the present invention may provide advantages such as relatively fast "one-touch" physical-to-virtual machine conversions in a manner that avoids downtime for real machines. have. In addition, implementations of the present invention may allow for a stable “one touch” real to virtual machine conversion, since the converted machine is consistent at the virtual machine host. As will be more fully understood from the following description and claims, this conversion may be performed by any number of suitable components and modules. For example, implementations of the invention may include using components and mechanisms of the Volume Shadow Copy Service (VSS) to create application (and / or file system) -consistent snapshots. Such components can create one or more consistent snapshots (or point-in-time images) of one or more real machine volumes that are running during the snapshot process.

Implementations of the present invention may also include the use of Volume Disk Service (VDS) and / or related components. In general, the VDS (or related component (s)) includes a platform for creating and organizing volumes on a physical disk. Implementations of the present invention also include the use of "disk imagers" and in some cases the use of "image mounters". In general, a disk imager includes components and / or modules configured to create a block (or byte block) based copy of a real disk or volume, given the starting position and number of bytes (or byte blocks) for copying. In contrast, the image mounter tool includes, for example, one or more components and / or modules configured to take a virtual hard disk file as input and mount the virtual hard disk file in a file system to expose the file as a physical disk. . This exposed physical disk can be made accessible as if any other physical disk is accessible to the operating system (which includes the ability to write data to its volume (s)).

Implementations of the invention further include the use of a virtual hard disk file (“virtual hard disk” file) on the virtual machine host, where the VHD file is managed by (and is also capable of) one or more virtual machines (VMs). One physical disk and one or more physical disk volumes (accessible internally). Although the terms "virtual machine", "virtual machine host" and "VHD file" are used in some MICROSOFT environments, it will be understood that the references herein to MICROSOFT components (and / or WINDOWS SERVER components) are illustrative only. In particular, after reading this specification and claims, it will be understood that the components, modules, and / or mechanisms described herein may be discovered and practiced in a wide variety of operating environments implementing virtual machines or such related entities.

Referring now to FIG. 1A, the figure illustrates an exemplary computerized environment in which a real machine 105 (eg, a personal computer, a real server, etc.) can be converted to a virtual machine hosted on a virtual machine host 110. An overall schematic diagram of 100 is shown. At one component level, the step of converting a real machine (eg, 105) to a virtual machine (eg, 175 of FIG. 1C) may comprise one or more real machine volume (s) (eg, 115). ), Creating a virtual machine hard disk file (s) (eg, 140) on the virtual machine host, delivering the snapshot (s) as a VHD file, and delivering the VHD file. And making the one or more snapshot volumes of the taken snapshot volume (s) as bootable as a virtual machine (eg, 175). Thus, it will be appreciated that there are a number of different pre- and post-operation processes that can be implemented to make the conversion efficient.

In at least one implementation, for example, the conversion process can be initiated through the use of the conversion module 130 (ie, it can include one or more modules in the machine 105 and / or host 110), This initiates a snapshot operation of one or more volumes (eg, volume 115) on the physical disk (s) of the real machine 105. In general, conversion module 130 may include any suitable writer and requestor configured to generate a consistent shadow copy of the actual disk volume. As mentioned above, for example, such writers and requestors may be provided in a volume shadow copy service. Thus, for example, conversion module 130 may signal all application writers of each of one or more volumes (eg, volume 115) of a physical disk to initiate a snapshot operation of its data. The transfer can begin the conversion process. As shown, for example, volume 115 includes at least volume data 125 as well as boot record 120.

Upon receiving this message from the translation module 130, each application writer on volume 115 flushes its in-memory data to the physical disk and / or any file system or volume log. You can freeze the log. For an application that does not use an application writer, the transformation module 130 instructs the application to shut down (eg, by default, or by command from a user or administrator), thereby allowing any writes to occur during the snapshot. It can be guaranteed that it is not done. Thus, FIG. 1A shows that the conversion module 130 can create a single point-in-time snapshot (ie, a copy) of all volume data on the volume 115. For example, FIG. 1A shows that the conversion module 130 has created a snapshot 117 (i.e., "snapshot volume") of the volume 115, in which case the snapshot 117 is a volume. Data 127 and boot record 120.

It will be appreciated that there are a number of optimizations that can be made when taking a snapshot or performing a snapshot (and copy) operation to ensure that data is copied and transferred in an efficient manner. For example, the transformation module 130 can identify which portion of the volume 115 is in use (ie, contains data) and which portion is free. Thus, the snapshot operation may be configured to copy only the volume (s) or the use portion of the physical disk, rather than the entire volume (s) or the entire physical disk. In addition, the snapshot operation may be further configured to avoid certain files that are less useful (or not at all useful) in the virtualized environment.

In particular, for example, the snapshot operation may be further configured to identify files such as those included in volume diff regions, page files, bad clusters, hibernation files, and the like. Thus, these files can be avoided when creating a snapshot 117 or performing a byte block transfer, further reducing the amount of data that needs to be delivered to the virtual machine host 110. It will be appreciated that these types of files and optimizations can easily be modified for other types of files, busy or empty space calculations, etc. in a wide range of operating environments.

In either case, for example, primarily due to changes over time during (and / or after) a snapshot operation, data 127 of snapshot 117 causes original data 125 on volume 115. In general). For example, since the real machine 105 is still running during the snapshot operation, for example, if the user is continuously creating a write to some application data, the volume data 125 may continue to change. have. Thus, volume data 127 (ie, "volume data 127") represents data 125 on volume 115 at a more consistent point-in-time, which is essentially a conversion. It is the designated time that module 130 started the snapshot process.

However, FIG. 1A also shows that the boot record 120 is the same when it is in the snapshot 117 with the execution data of the volume 115. That is, it will be understood that the boot record (eg, 120) cannot change during the snapshot process because the application typically does not have access to the boot record. In particular, the boot record is generally changed by the operating system, but typically rarely. As such, FIG. 1A shows that the boot record 120 in this case is the same as before the snapshot operation.

Prior to or during snapshot 117 creation, or immediately after snapshot 117 creation, conversion module 130 corresponds to a physical disk (not shown) of real machine 105. The virtual hard disk ("VHD") file 140 may be set up in the virtual machine host 110. For example, FIG. 1A shows that the conversion module 130 sends a message 150 for generating a writable virtual hard disk file 140. In addition, in one implementation, it first sends a message to create a particular fixed size VHD file (s) (eg, 140), and then sends a separate message to make the VHD file writable. It may include. (Also, the conversion module 130 may send a message to generate a dynamically writeable VHD file (which is writeable or otherwise), which grows as the data is added.) You can also send it.)

In general, each VHD file may be configured to correspond to a single physical disk of a computer system, and each volume within the physical disk may appear in the same way as it appears in the newly created VHD file. In some cases, however, a VHD file may represent a single volume rather than the entire physical disk. However, in an example of a real disk in which a real disk has a plurality of volumes (although only a single volume 115 is shown), the new VHD may also include data corresponding to the plurality of volumes. Of course, there is some flexibility in this as well. For example, if a user of the physical machine 105 has a volume that spans multiple partitions (and / or mirrored volumes, etc.), the user may have a snapshot of the destination virtual hard disk file. You can decide to only dedicate one partition to the data. Similarly, the user may decide to transfer only one volume of the physical disk including the plurality of volumes to the virtual hard disk file.

Thus, the size of the VHD file will generally be at least as large as required for transferred source data (e.g., physical disks, specifically physical disk volumes, data on the physical disks, etc.). As such, it will be appreciated that the techniques described herein can also be used when copying an existing virtual machine to a larger storage space. For example, if the administrator identifies that the volume storage capacity of the virtual machine is decreasing, additionally create a larger VHD file (s), snapshot the virtual machine data, and describe that snapshot data already described. The same process can be used to substantially "re-virtualize" a virtual machine by transferring (eg, copying) to a new VHD file (s).

Thus, implementations of the present invention include "virtual to virtual" machine transformations as well as "real to virtual" machine transformations. In particular, in some circumstances, implementations of the invention may be referred to more generally as converting a "machine" into a "virtual machine." That is, a "machine" is a "real" computer system (eg, a desktop computer with associated hardware and operating system (s)) and a "virtual" computer system (eg, a unique computer system (s). It can be understood that the invention includes all of the computer system installed on the virtual machine host).

In any case, when the virtual hard disk file 140 is created, the conversion module 130 mounts the file 140 as a physical disk, so that the file 140 can store data of the snapshot 117 through, for example, network communication. Can be received. (In some implementations described herein, it will be appreciated that even mounting may not be required.) Accordingly, in FIG. 1A, the translation module 130 also sends a message 155 for mounting the virtual hard disk file 140. Is shown. In further or other implementations, the message 155 may be a virtual machine host 110, a real machine 105 being converted, or a machine on which the VHD file 140 is mounted and a real machine being converted (ie, This case may include instructions for mounting the VHD file 140 anywhere on the network connection between the 105.

"와 같은 드라이브 경로를 통해 식별 가능할 수 있게 가상 하드 디스크 파일(140)을 탑재하도록 명령받을 수 있다. 특히, 도 1B에는 VHD(140)가 "디스크 드라이브(145)"로서 식별 가능한 것이 도시되어 있다. 유사 선상에서, 변환 모듈(130)은 각각의 스냅샷(예를 들면, 117)에 대하여 장치 식별자(및/또는 예를 들면, 탑재점(mount point))를 식별할 수도 있다. 최종 적으로, 변환 모듈(130)은 스냅샷 콘텐츠를 전달하기 위하여 임의의 스냅샷 및 임의의 대응하는 VHD 파일에 대해 그 식별된 장치 식별자를 사용할 수 있다.Part of mounting the file 140 may include associating the file with one or more device identifiers, such as the device ID of the physical disk. For example, virtual machine host 110 may "

May be instructed to mount the virtual hard disk file 140 to be identifiable via a drive path such as ". In particular, FIG. 1B shows that the VHD 140 is identifiable as" disk drive 145 ". On a similar line, transformation module 130 may identify a device identifier (and / or for example, a mount point) for each snapshot (eg, 117). The conversion module 130 can use the identified device identifier for any snapshot and any corresponding VHD file to deliver the snapshot content.

In general, the transformation module 130 may deliver the snapshot 117 content using any number of data delivery mechanisms. For example, in one implementation, the conversion module 130 may deliver the snapshot 117 to the file 140 on a byte-by-byte basis via the disk drive 145. However, in additional or other implementations, the transform module 130 can deliver the snapshot 117 to the file 140 by identifying and conveying " byte blocks. &Quot; In general, a block of bytes includes a fixed sequence (of any arbitrary size) of individual bytes. In at least one implementation, passing byte blocks rather than individual bytes can significantly increase the speed at which snapshot 117 can be delivered over the network.

For example, several gigabytes of data, which may typically take several hours to deliver to the virtual machine host 110 via conventional network delivery protocols, are delivered in just a few minutes in some cases using the byte block delivery mechanism. Can be. In any case, FIG. 1B shows that in this case the conversion module 130 passes bytes (or byte blocks) “160 ₁ ”, “160 ₂ ”, etc., and passes these bytes / byte blocks through the disk drive 145. And direct transfer to the writable virtual hard disk file 140. As shown in FIG. 1B, the virtual hard disk file 140 may include all of the boot data 120 and, once data transfer is complete, other volume data 127 captured in the snapshot 117. Will contain).

Despite the data passing, the virtual hard disk file 140 does not necessarily need to be bootable on the virtual machine host 110 because boot data and drivers may not be useful in the context of the virtual machine host 110. Because there is. One reason for this is that the "virtual hardware" present in the virtual machine environment (and / or within the virtual machine host 110) may not be the same as the hardware for the real machine 105. For example, components such as a kernel on the real machine 105 and a hardware abstraction layer (HAL) may be based on, for example, a dual processor system. In addition, the virtual machine host 110 emulates various network card drivers, processor architectures, physical disks (eg, storage devices attached to the machine), physical disk identifiers, operating system drivers, and disk drivers to their hosted virtual machines. which might not be found at the source machine being converted (e.g., the real machine 105). . This difference may exist when converting a physical disk volume from inside a virtual host to a virtual machine.

As a result, the passed boot data 120 may be based on operating system features in the real machine 105 that need not be applied within the appropriate virtualized environment at the virtual machine host 110. These and other reasons mean that the administrator needs to make a number of different changes depending on the particular operating environment (s). Accordingly, the conversion module 130 may change the virtual hard disk file 140 to be bootable in the virtual machine host 110. In some cases, this may include instructions to update the kernel and HAL-and other drivers and registry settings-for the virtual machine to be created based on the snapshot data.

Thus, for example, FIG. 1C also shows that the transformation module 130 sends a request 165 to the virtual machine host 110 to change the operation information and a corresponding argument. (In some cases, these changes to the operating information of the virtual machine (eg, boot sector and registry information) can be made even on the real machine (before it is passed into the VHD file). In one implementation, this is a conversion The module 130 examines the boot history of the volume snapshot 117 and, based on the new disk and volume configuration of the virtual machine, retrieves the previously passed boot data 120 with new boot information (e.g., changed boot). Information or new boot information from the absence of information). Also, in another step, the conversion module 130 may examine the passed registry information (not shown) of the volume snapshot 117 and based on new hardware and drivers present on the virtual machine host 110. The registry information may be updated in a manner appropriate to the virtual machine 110.

In addition, the updating may include changing system binaries such as kernel and HAL drivers from a multiprocessor to a uniprocessor hardware configuration. In addition, such updating may include adding unique computer and drive identity information to the virtual machine host 110, adding any suitable disk or file driver unique to the virtual machine host 110, as well as the appropriate steps. Changing registry information to accommodate network drivers, storage device drivers, and the like. This updating step includes replacing the driver for the physical device with the driver for the virtual device, disabling the driver for the hardware if there is no corresponding virtual device in the virtual environment, and virtual Disabling services and applications dependent on the device if there is no corresponding virtual device in the environment.

In addition, the transformation module 130 is intended to cause the resulting virtual machine (e.g., 175) to operate with the same preferences (e.g., memory, CPU, etc.) as in the original real machine 105. It may further generate these and / or other suitable configuration values for one virtual machine (eg, 175). Also (or alternatively) on this line, the administrator of the virtual machine host 110 can change these preferences for the resulting virtual machine. In addition, the administrator can even build this behavior information (ie configuration values, preferences, etc.) from nothing. In either case, any number of configuration changes suitable to ensure that multiple entities are bootable and will operate correctly on the virtual machine residence (e.g., virtual machine host 110). Will understand.

After appropriately changing / creating the appropriate boot record (ie, changing / creating from 120 to 123) and also appropriately changing / creating system registry information, driver information, and / or other configuration or preference information, the conversion module 130 ) May unmount (ie, "un-mount") the virtual hard disk file 140 so that it is no longer accessible as a drive. For example, FIG. 1C illustrates sending a message 170 to the virtual machine host 110 instructing the virtual machine host 110 to unmount the virtual hard disk file 140. After removing this mount, the virtual hard disk file (s) 140 can be used as the virtual machine 175, whose data is essentially the same as the data on the volume 115 where the snapshot operation began.

In particular, the data in the volume (s) managed by the new virtual machine 175 is consistent in all appropriate aspects (eg, application-consistent, file system-consistent, and / or crash-consistent). -consistent), etc. As a result, the previous user of the real machine 105 now boots the virtual machine 175 on the virtual machine host 110, and as if the user is using the real machine 105 (or the user is the real machine 105). ), You can use a virtual machine (which includes access to old data). It will also be appreciated that VHD files are generally portable. For example, the end user can deliver at least one virtual machine file (s) (eg, VHD file (s), etc.) associated with the virtual machine 175 to a desired location and update any necessary operational information. In the implementation of the &lt; RTI ID = 0.0 &gt; simple &lt; / RTI &gt;

In another implementation, one or more VHD files (eg, 140) may even be created on the real machine 105 itself and then transferred / delivered to the appropriate virtual machine host (eg, 110). For example, a user of the real machine 105 may create a VHD file (eg, 140) on the real machine and deliver snapshot content to that VHD file for the data of interest on the real machine. This is at least one way in which, if desired, the user can avoid mounting the VHD file (ie, at the virtual machine host 110). In either case, the user can transfer / deliver the VHD file and corresponding snapshot content to an appropriate target (eg, virtual machine host 110) and change the corresponding operational information at that target. Alternatively, the user may even change operational information about the VHD file and snapshot content at the source (eg, the real machine 105) before transferring the VHD file and snapshot content to the new destination.

In some cases, rather than creating a VHD "file" by itself, for example, a module (e.g., conversion module 130) may be responsible for carrying snapshot data and VHD metadata generated on the real machine 105. It can be configured to stream from memory as efficient parts (eg, byte blocks). In addition, the data to be streamed may be formatted in the VHD format according to the appropriate VHD format / content specification. Thus, after being delivered to a target (eg, virtual machine host 110), the stream can be stored as a VHD file because the streamed data was created in the VHD file format. This is another way to avoid loading VHD files.

Thus, FIGS. 1A-1C show a number of overall schematics and components that can be used in accordance with an implementation of the present invention for creating a snapshot of actual machine volume data and creating a new virtual machine from that data. In addition to the foregoing, implementations of the invention may be described in terms of flowcharts of methods that include one or more steps to achieve a particular result. For example, FIG. 2 shows a flowchart of a method for converting a machine, such as a real machine or another virtual machine, into a virtual machine from the perspective of the real machine 105 and the virtual machine host 110. The method of FIG. 2 is described below in connection with the components of the mechanism of FIGS. 1A-1C.

For example, FIG. 2 illustrates a method of converting a virtual machine from a virtual machine host to a virtual machine without incurring significant downtime on one or more real machine volumes, from the perspective of the real machine 105. physical machine to a virtual machine at a virtual machine host) may include a step 200 of identifying a hardware configuration of a physical machine. Step 200 includes identifying one or more hardware configuration settings for one or more volumes of the machine. For example, FIG. 1A illustrates a conversion module 130, which may identify hardware (and / or software) configuration settings for volume 115 prior to beginning the snapshot process. This may include identifying boot records 120 and volume data 125 as they are present on the real machine 105 on the volume 115, whether the data is configured for a multiprocessor environment, operating The method may further include identifying an incompatibility of the system support file, whether there is a storage device and a network driver that need to be considered, and the like.

2 also shows that from the perspective of the real machine 105, the method may include the step 210 of taking a snapshot of one or more volumes. Step 210 includes creating one or more consistent snapshots corresponding to one or more machine volumes. For example, FIG. 1A shows that the conversion module 130 creates a snapshot 117 of the volume 115, which is the volume data 127 as well as the same boot record 120 as before. Also includes. In at least one implementation, transformation module 130 may invoke a writer-involved snapshot process on volume 115 if a writer is available, or if such a writer is not available Simply terminates the application (or other write process). As a result, it can be ensured that the data in snapshot 117 is consistent (eg, application consistent) for a single instance over time after the snapshot process.

2 also shows that from the perspective of the real machine 105, the method may include transferring the snapshot (s) to the mounted virtual disk file (220). Step 220 includes sending one or more consistent snapshots to the mounted virtual hard disk file. For example, the conversion module 130 retrieves the device identifier for each snapshot taken from the real machine 105, and converts any device identifier for each virtual hard disk file mounted on the virtual machine host 110. Retrieve. FIG. 1B shows that when retrieving the appropriate device identifier, the conversion module 130 uses the byte (or byte block) transfer / copy mechanism to retrieve the volume data 127 of the snapshot 117 to the virtual hard disk. It is shown that it can be delivered to file 140.

FIG. 2 also shows that from the perspective of the real machine 105, the method may include transferring 230 the boot record (s) to the mounted virtual disk file. Step 230 includes transferring 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 changed at the virtual machine host. For example, FIG. 1B also illustrates that translation module 130 transmits boot data 120 to virtual hard disk file 140. 1C may also send a message 165 for changing boot record 120 to record 123 such 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 can simply be created from nothing, rather than just transferred and changed.

In addition to the foregoing, FIG. 2, from the perspective of the virtual machine host 110, converts a machine (ie, a real machine or a previous virtual machine) from a virtual machine host to a virtual machine without incurring downtime for one or more machine volumes. The method may include the step 240 of creating a virtual hard disk file. Step 240 includes creating a virtual hard disk file having a file size. For example, in FIG. 1A, the command allows the virtual machine host 110 to write a new virtual hard disk file, as well as a message 150 instructing the virtual machine host 110 to create a writable virtual hard disk file. Receiving is shown. In response, the virtual machine host 110 creates a virtual hard disk file 140 and makes it writable. As mentioned earlier, the virtual hard disk file size can be static or dynamic here. For example, the virtual hard disk file 140 may be set to 100 gigabytes to accommodate 50 gigabytes of volume 115 data. Alternatively, the conversion module 130 sets the virtual hard disk file 140 to dynamically grow as additional data is delivered.

2 also illustrates that from the perspective of the virtual machine host 110, the method may include mounting a virtual hard disk file 250. Step 250 includes mounting the virtual hard disk file on the virtual machine host such that the virtual hard disk file appears as an accessible physical disk. For example, FIG. 1A shows that the virtual machine host 110 receives a request 155 to mount a virtual hard disk file 140. In one implementation, the virtual machine host 110 may be instructed to associate the file 140 with a particular device identifier and then mount that identifier as a real device. The virtual hard disk file 140 can then be seen and accessed as the disk device 145.

Also, in view of the virtual machine host 110, the method may include receiving 260 one or more snapshots. Step 260 includes receiving data of one or more consistent snapshots corresponding to one or more actual machine volumes. For example, as shown in FIG. 1B, the virtual machine host 110 may use the volume data 127 using any suitable delivery mechanism (ie, byte-by-byte or byte-block by any network delivery protocol). ) And boot data 120.

FIG. 2 also shows that, from the point of view of the virtual machine host 110, the method may include changing the boot record 27. Step 270 includes changing operation information for the one or more consistent snapshots such that the one or more consistent snapshots are appropriate for an operating system on the virtual machine host. As shown in FIG. 1C, for example, the virtual machine host 110 receives a message 165 for changing operational information. For example, the message 165 may include one or more requests to identify the appropriate virtual machine host 110 criteria and to change the boot data 120 into the boot data 123 in an appropriate manner. . In addition, message 165 (or other message—not shown) may include one or more requests to change registry and / or operational preference information.

Such changes in operational attributes include, for example, any number of hardware and operating system configurations (eg, any number of processors, hardware drivers, disk drivers / identifiers and storage drivers / identifiers, network drivers, etc.). can do. This change needs to be considered to ensure that the new operating system of the virtual machine is compatible and properly functions for the virtual environment. Changes in operational attributes may further include various registry manipulations, such as the use of drivers and other hardware, the identity of the driver being replaced and / or registered in binaries, updates to kernel and / or HAL information, and the like. The change in operational attributes may further include various configuration preferences for the virtual machine, such as configuration preferences for memory and / or CPU requirements.

2 also shows that from the perspective of the virtual machine host 110, the method may include a step 280 of removing the virtual hard disk file mount. Step 280 includes removing the mounting of the hard disk file such that the virtual hard disk file is not accessible as a physical disk. For example, the virtual machine host 110 receives a message 170 requesting the virtual machine host 110 to unmount the virtual hard disk file 140. The virtual machine host 110 may then unmount the virtual hard disk file such that the file 140 is no longer accessible locally as a host-level disk drive. As a result, the virtual disk file 140 containing the consistent data for a single instance over time may boot up as the virtual machine 175 and attempt to operate on the virtual machine host 110. In particular, from the end user's point of view, the virtual machine 175-in almost all intents and purposes-is essentially the same form as the real machine 105 before the snapshot operation (ie, the same data or its data subset (s)). )to be.

Accordingly, FIGS. 1A-1C and 2 provide a number of components and mechanisms for efficiently converting a machine (eg, a real machine or a former virtual machine) into a virtual machine. In particular, the figures and corresponding texts describe how implementations of the invention may be performed in at least one aspect, without the need to reboot the machine being converted, and / or without rebooting into the ADS or PXE environment. Explain. As such, the components and mechanisms described above allow a real machine to be created relatively quickly, for example at typical disk and network transfer rates.

As discussed herein above, it will be appreciated that implementations of the invention may be modified and changed over a wide variety of optimizations and a wide variety of hardware and operating system environments. For example, implementations of the present invention can be readily applied to converting any type of machine into a new virtual machine. For example, for the old virtual machine, the user may want to create more storage space for the virtual machine that is maxed out the volume. Thus, a user can create one or more VHD files that are larger than the previous VHD file of the previous virtual machine, snapshot the previous virtual machine data, and pass the virtual machine snapshot data to the larger VHD file. In addition, the conversion process described herein may be further separated into a plurality of independent steps other than those explicitly described. For example, if a user has a way to deliver a volume image to a target machine, the user simply simplifies a fix-up operation to "virtualize" the image so that the image is bootable on the target machine. Can be called.

In addition to the foregoing, it will be readily understood that implementations of the invention may be applied to a wide variety of disk configurations. For example, the physical disk (s) on which the machine volume 115 is installed may be any one or more basic or dynamic disks of the operating system, and may further include various partitions and / or volumes. However, the procedures, components, and mechanisms described herein can be applied to this variation of a virtual machine as if they were on a previous machine (eg, a real machine or a previous virtual machine). In particular, features associated with real dynamic or basic disks are passed to the virtual machine host so that the new virtual machine will behave as it did before using basic or dynamic disk attributes. Thus, the components, modules, and mechanisms described herein may be widely applied to ensure seamless transition from the old machine to the newly virtualized form of the old machine.

Embodiments of the present invention may include a dedicated or general purpose computer including various computer hardware, as further described below. In addition, embodiments within the scope of the present invention include computer readable media for conveying or including stored computer executable instructions or data structures. Such computer-readable media may be any available media that can be accessed by a general purpose or dedicated computer.

For example, such computer readable media may include RAM, ROM, EEPROM, CD-ROM, or other optical disk storage, magnetic disk storage, or other magnetic storage, or any desired program code means for the computer executable instructions or data structures. And any other medium used for delivery or storage in form and accessible by a dedicated or general purpose computer. When information is delivered or provided to a computer via a network or other communication connection (hardwired, wireless, or a combination of hardwired or wireless), the computer views the connection as appropriate computer readable media. Thus, any such connections are properly termed computer readable media. Combinations of the above should also be included within the scope of computer-readable media.

Computer-executable instructions include, for example, instructions and data that cause a general purpose computer, dedicated computer, or dedicated processing device to execute a function or group of functions. While the subject matter of the present invention has been described in language specific to structural features and / or methodological steps, it will be understood that the subject matter defined in the appended claims does not need to be limited to the specific features or steps described above. Rather, the specific features and steps described above are disclosed as example forms of implementing the claims.

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

Claims (20)

Machines in a computerized environment comprising a virtual machine host configured to host one or more virtual machines, the machines comprising one or more volumes. A method for converting a machine from a virtual machine host to a virtual machine without incurring significant downtime on the one or more machine volumes, wherein: Identifying one or more hardware configuration settings for one or more volumes of the machine; Creating one or more consistent snapshots corresponding to the one or more machine volumes; Transferring the one or more consistent snapshots to a mounted virtual hard disk file; And Transferring a boot record for the one or more consistent snapshots to the mounted virtual hard disk file so that a boot record for the one or more consistent snapshots can be modified on the virtual machine host. The method of claim 1, further comprising converting the machine into a virtual machine. The method of claim 1, At least one of the one or more consistent snapshots is transmitted to the virtual machine by delivering the at least one snapshot as a set of one or more byte blocks. The method of claim 1, The machine is a physical machine, Wherein the real machine and the virtual machine host are the same computer system such that one or more volumes of the real machine are transferred to another disk device of the real machine in the same computer system. The method of claim 1, Wherein the one or more machine volumes comprise a plurality of machine volumes installed on a dynamic physical disk. The method of claim 1, Creating one or more consistent snapshots, Identifying, on the one or more machine volumes, used space and free space; Within the used space, identifying one or more files to be avoided during snapshot or copy operations, wherein the one or more files to be avoided include diff area files, page files, bad clusters, Contains any one or more of a hibernation file; And The copied data, (i) the used space identified above, or (ii) the used space identified above, except for one or more files to be avoided. Copying data from the one or more machine volumes to one or more virtual hard disk files to include only one of the following: The method of claim 1, further comprising converting the machine into a virtual machine. The method of claim 1, Identifying the one or more hardware configuration settings, Identifying one or more applications on the one or more volumes, configured for writer-involved snapshot processes; And Sending a command to each identified application to start the writer associated snapshot processes. The method of claim 1, further comprising converting the machine into a virtual machine. The method of claim 6, Identifying one or more applications not configured for the writer associated snapshot processes; And Shutting down each of the identified one or more applications not configured for the writer associated processes. The method of claim 1, further comprising converting the machine into a virtual machine. The method of claim 1, Sending one or more instructions to the virtual machine host to create a virtual hard disk file; And Sending a command to enable the virtual hard disk file to be written to the virtual machine host. The method of claim 1, further comprising converting the machine into a virtual machine. The method of claim 8, And the generated virtual hard disk file is dynamically sized so that the size of the virtual hard disk file can change over time. The method of claim 8, Transmitting one or more instructions to mount the created virtual hard disk file; And Identifying a device identifier for the mounted virtual hard disk file The method of claim 1, further comprising converting the machine into a virtual machine. The method of claim 10, Identifying one or more device identifiers for the one or more consistent snapshots. The method of claim 1, Identifying one or more system values of the virtual machine host; And Transmitting a command to change operation information for data in the one or more consistent snapshots in accordance with the identified one or more system values. More, The command to change the operation information, (i) the boot record; (ii) system registry information; (iii) one or more drivers; (iv) operating system binaries; (v) kernel binaries; or (vi) one or more configuration preferences of the virtual machine And converting any one or more of the instructions to a virtual machine. The method of claim 12, The command to change the operation information, One or more instructions to replace drivers for one or more real devices with drivers for one or more simulated devices; One or more instructions for disabling device drivers for hardware if there is no corresponding virtual device in the virtual environment; or One or more instructions to disable one or more services dependent on one or more devices that do not exist on the virtual machine host And converting the machine to a virtual machine, the method comprising any one or more instructions. The method of claim 12, Sending one or more instructions to the virtual machine host to remove the mounting of the virtual hard disk file such that the virtual hard disk file is accessible as a virtual machine but not as a physical disk. How to convert to a machine. Virtual machine host in a computerized environment, where the virtual machine host is configured to host one or more virtual machines including one or more volumes, thereby virtualizing the physical machine without causing significant downtime to one or more physical machine volumes. A method of converting from a machine host to a virtual machine, Creating a virtual hard disk file having a file size; Mounting the virtual hard disk file on a virtual machine host such that the virtual hard disk file appears as an accessible physical disk; Receiving one or more consistent snapshots corresponding to one or more actual machine volumes; Modifying operation information for the one or more consistent snapshots such that the one or more consistent snapshots are suitable for an operating system on the virtual machine host; And Removing the mounting of the virtual hard disk file such that the virtual hard disk file is not accessible as a physical disk The method comprising converting a real machine into a virtual machine. The method of claim 15, Storing the one or more consistent snapshots in the virtual hard disk file. The method of claim 15, Receiving data for the one or more consistent snapshots at the byte block level. The method of claim 15, Receiving a command to enable writing of the created virtual hard disk file; And Transmitting a device identifier for the mounted virtual hard disk file to a real computer system The method of claim 1, further comprising converting a real machine into a virtual machine. The method of claim 15, Reporting one or more system values to the real computer system, wherein the one or more system values are used to change operational information for the one or more consistent snapshots. How to convert. A machine in a computerized environment comprising a virtual machine host configured to host one or more virtual machines, the machine comprising one or more volumes, when executed, the one or more processors of the machine, the one or more machine volumes A computer program product having computer executable code stored thereon that executes a method of converting a machine from a virtual machine host to a virtual machine without incurring significant downtime on the computer. The method, Identifying one or more hardware configuration settings for one or more volumes of the machine; Creating one or more consistent snapshots corresponding to the one or more machine volumes; Transferring the one or more consistent snapshots to a mounted virtual hard disk file; And Transferring 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 changed on the virtual machine host. Computer program product comprising a.

Images