JP2008084029A - Virtual machine management system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To easily manage a guest OS and APs driven in the guest OS by unifying image files of the diversified guest OS in a virtual machine management system for managing a plurality of virtual machines and to easily restore an AP environment in updating the guest OS. <P>SOLUTION: Data concerned with a plurality of APs to be driven in the guest OS are separated and stored as one virtual AP image file to unifiedly manage image files of the guest OS. In updating the guest OS, the unified image file of the guest OS is updated only once, and the updated image file is overwritten to the other guest OS image file. Then the virtual AP image file is downloaded to the guest OS whose update is completed and data are read from the AP image file to start the AP. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a technique for managing a plurality of virtual machines and OS image files used on the virtual machines.

  A virtual machine is an environment that emulates specific hardware, or a virtual machine environment that is realized by the environment, and usually executes emulation software on some operating system (hereinafter referred to as OS). Is realized. Further, on the virtual machine, it is possible to operate an OS or a program different from the OS. At this time, an OS used to execute the virtual machine itself is referred to as a “host OS”, and an OS executed on the virtual machine is referred to as a “guest OS”. Since a virtual machine can construct a plurality of machine environments on one physical computer, it is used for server consolidation for the purpose of efficient use of resources. In addition, since the guest OS can be handled as a single image file and multiple machine environments can be constructed by copying only the image file, a test environment can be constructed for large-scale system development. Etc.

As a virtual machine construction method, the following Patent Document 1 provides a means for facilitating settings applied to a guest OS, new construction / deletion of a virtual machine, and the like. In addition, a virtual machine management tool for managing a plurality of virtual machines from one management console screen is being prepared. Furthermore, there are means for setting the OS from a computer connected via a network, such as Active Directory (registered trademark) of Windows (registered trademark), and the construction of a virtual machine has become easier.
JP2005-332223

  However, since the virtual machines and guest OSs can be easily duplicated and set up, the virtual machines proliferate, and the settings and application installation statuses in the guest OS become diverse. There is a problem that complicated management must be performed.

  In addition, in the conventional virtual machine management system, when the guest OS is updated, the guest OS image on the virtual machine is rewritten with the updated one, so that the application environment constructed so far cannot be easily restored. There is. In order to restore the application environment, it was necessary to start from the installation of the application again.

  The present invention has been invented in view of such a problem, and an object of the present invention is to unify the image files of the diversified guest OS (hereinafter, the image file of the unified guest OS is the master guest OS). (Referred to as an image), guest OS, and management of applications running on the guest OS. It is another object of the present invention to easily restore the application environment when updating the guest OS.

  In order to achieve the above object, the present invention provides a virtual machine management system for managing a plurality of virtual machines in a virtual machine server on which a plurality of virtual machines operate. Means for creating a virtual AP image file on a virtual hard disk managed by a guest OS that operates on the virtual OS, and an arbitrary module that operates on an arbitrary virtual machine on a virtual hard disk managed by the guest OS that operates on the virtual machine When an arbitrary data write or read process is attempted with respect to an arbitrary area, a predetermined area on the virtual AP image file existing on the virtual hard disk from the area instructed to write or read To write or read And the means for separating the arbitrary data into the virtual AP image file and the virtual AP image file from the virtual hard disk to a physical hard disk managed by the host OS on the virtual machine server. Means for backing up and means for downloading the virtual AP image file on the physical hard disk onto the virtual hard disk, and data relating to a module operating on the arbitrary virtual machine is stored in the image of the guest OS. By separating from the file, the guest OS image file can be handled in a unified manner.

  In other words, in the present invention, the guest OS image file is unified as a master guest OS image. When an arbitrary module operates on the guest OS created by copying the master guest OS image and writes / reads data to / from the virtual HDD, the data is redirected to the virtual AP image file. Thereby, the guest OS image and the virtual AP image can be clearly separated.

  According to the present invention, updating such as updating is easy in the guest OS. For example, if you want to update the guest OS, update the master guest OS image once and overwrite any guest OS image file that runs on the virtual machine server with the updated master guest OS image. This completes the update of the guest OS. At this time, since the execution code and data related to the application are separated as the virtual AP image file, even if the guest OS image file is overwritten with the updated master guest OS image, Data of an arbitrary module such as an operating application is left as a virtual AP image file and does not disappear. Normally, when updating a guest OS with different application installation status, it is necessary to start the guest OS and perform an update operation manually or automatically. In the present invention, however, a master guest OS image is used. It is possible to complete the update of all guest OSs existing on the virtual machine server simply by overwriting. Further, if the system of the present invention is used, it is possible to update a guest OS that has not been started without starting the guest OS.

  According to the present invention, the management of the guest OS and applications running on the guest OS is facilitated by unifying the diversified guest OS image files as the master guest OS image. In addition, when updating the guest OS, there is no need to perform the work from installing the application again, and the application environment can be easily restored.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  FIG. 1 shows a system configuration of a virtual machine management system according to an embodiment of the present invention. Hereinafter, the application is abbreviated as AP.

  1 includes a virtual machine server 100, a host OS 101, a virtual machine management module 102, an update module 103, a virtual machine 104, a guest OS 105, a virtual AP conversion module 106, and a virtual AP backup module 107 (hereinafter referred to as a virtual APBU module). A virtual AP download module 108 (hereinafter referred to as a virtual APDL module), a virtual HDD 109, a virtual AP image 110, a virtual AP 111, a physical HDD 112, a master guest OS image 113, and a guest OS image 114.

  The virtual machine server 100 is a physical computer for operating a plurality of virtual machines. In addition, the virtual machine server 100 includes one physical hard disk (HDD) 112. In this embodiment, in order to distinguish from a virtual HDD on a virtual machine, a physical hard disk managed by the host OS on the virtual machine server is referred to as a physical HDD 112. In FIG. 1, the parts that actually physically exist and operate are the virtual machine server 100, the host OS 101, the virtual machine management module 102, the update module 103, and the physical HDD 112. A portion within the dotted line 120 indicates a virtually realized range. In the present embodiment, a configuration for only one virtual machine server 100 is given, but a configuration in which a plurality of virtual machine servers exist may be used.

  The virtual machine management module 102 is a module (program) for managing the virtual machine 104, and operates on the host OS 101 to add, delete, start, stop, and set a virtual machine (for example, the name of the virtual machine Management functions, etc.). The virtual machine management module 102 also provides a GUI interface function for an administrator to manage a virtual machine, and can exercise the management function at an arbitrary timing.

  The virtual machine 104 can operate a plurality of virtual machines 104 on the virtual machine server 100. In order to construct a new virtual machine environment, it is necessary to create a new guest OS image 114 on the physical HDD 112 and mount it after creating a new virtual machine 104 by the virtual machine management module 102. At this time, one guest OS image 114 is required for one virtual machine 104. In other words, one virtual machine 104 is realized by creating one guest OS image 114 on the physical HDD 112. A method for newly creating the guest OS image 114 can be created by copying a master guest OS image 113 (described later).

  On the guest OS 105, a virtual AP module 106, a virtual APBU module 107, and a virtual APDL module 108 are always operating.

  The virtual AP conversion module 106 monitors file I / O operations such as data read / write operations performed by any module such as the guest OS 105 and application 111 on the virtual HDD 109, and these file I / Os are virtual APs. The function of redirecting to an arbitrary area on the image 110 (described later) and the redirected destination are stored, and an arbitrary module such as the guest OS 105 or the application 111 has previously read / written on the virtual HDD 109. When read / write is performed on the performed data (actually, data stored on the virtual AP image 110 by the virtual AP conversion module 106), the redirect is performed so as to refer to the area on the virtual AP image 110. With the function to do. These functions are related to data related to the application 111 on the guest OS 105 (for example, an executable file, driver, or data installed by an installer on a virtual machine as described in FIG. 3 or virtual data as described in FIG. 4). It is possible to separate stored data stored by the AP 111 as one virtual AP image 110.

  The virtual APBU module 107 is a module having a function of backing up a virtual AP image 110 (described later) stored on the virtual HDD 109 onto the physical HDD 112 managed by the host OS 101. The virtual APBU module 107 always backs up the virtual AP image 110 before the virtual machine 104 stops. Reference numeral 115 denotes a backed up virtual AP image. The virtual APBU module 107 can also be called from the virtual machine management module 102 at an arbitrary timing.

  The virtual APDL module 108 is a module having a function of downloading the virtual AP image 115 backed up on the physical HDD 112 onto the virtual HDD 109. The virtual APDL module 107 always downloads the virtual AP image (download from 115 to 110) immediately after the virtual machine 104 is activated. The virtual APDL module 108 can be called from the virtual machine management module 102 at an arbitrary timing.

  In the virtual AP image 110, the data stored in the virtual HDD 109 in the conventional virtual machine environment among the data related to the modules such as a plurality of applications 111 operating on the virtual machine 104 is redirected by the virtual AP conversion module 106. This is an image file for writing. Since there is no such virtual AP image 110 in the conventional virtual machine, the execution file when the application is installed in the virtual machine and the data saved by the virtual AP are easily incorporated into the guest OS image. The data was inseparable. In the system of the present embodiment, the guest OS image 114 corresponding to the guest OS 105 is not changed, and data related to the application can be separated and handled as the virtual AP image 110. One virtual AP image 110 exists for one guest OS 105. Further, in one virtual AP image 110, data related to a plurality of applications 111 operating on a certain virtual machine 104 is written. Only one virtual AP image 110 is created by the virtual AP conversion module 106 at an arbitrary timing from when the installation of the guest OS 105 is completed until an arbitrary module such as an application is newly installed.

  The virtual AP 111 is an application in which an execution file, a driver, data, and the like are separated on the virtual AP image 110 by the virtual AP conversion module 106 (detailed in FIG. 3). When a new application is installed on the virtual machine 104, data that should be saved in an arbitrary location on the virtual HDD on the conventional virtual machine is saved on the virtual AP image 110 in the system of FIG. Is done. Therefore, all applications that are not installed when the guest OS 105 is installed are virtualized and become virtual APs 111.

  The master guest OS image 113 is an image file of a guest OS that is the basis of all the guest OS images 114. The actual content is an image file of a guest OS in a state where any module other than the virtual AP module 106, the virtual APBU module 107, and the virtual APDL module 108 is not newly installed. It should be noted that updates and settings must be kept up to date or appropriate. The master guest OS image 113 is used when the guest OS 105 mounted on the virtual machine 104 is updated. The update of the master guest OS image 113 is managed by the update module 103. The update will be described in detail in the operation description.

  The update module 103 has a function of updating the master guest OS image 113. The update module 103 updates the master guest OS image 113 once when the guest OS 105 is updated, and overwrites the guest OS image 114 on the physical HDD 112 with the updated master guest OS image 113. Then complete the update. In the conventional virtual machine management system, when the guest OS image file is overwritten with another guest OS image file, data related to an arbitrary module such as an application is erased. However, in the system of FIG. Data related to an arbitrary module such as an application is separated into the virtual AP image 110 by the conversion module 106 and stored on the physical HDD 113, so that the application data is not erased.

  Hereinafter, the flow of processing in the present embodiment will be described in detail with reference to FIGS.

  FIG. 2 is a flow of creating a master guest OS image. In order to create the master guest OS image 113, first, an arbitrary virtual machine is activated (s200). If the virtual machine does not exist, create a new virtual machine and start it. When the virtual machine is activated, an arbitrary OS is installed (s201). When the installation operation is completed, the virtual APBU module 107, the virtual APDL module 108, and the virtual AP module 106 are installed on the guest OS (s202). Next, the update and setting are brought into an optimum state (s203). Finally, the guest OS is shut down and the virtual machine is stopped (s204). When the above operation is performed, a guest OS image is created on the physical HDD, and this is used as the master guest OS image 113.

  FIG. 3 is a diagram showing separation of AP data (AP virtualization) at the time of AP installation. Here, the operation of separating the application data from the guest OS image file when the application is installed will be described.

  First, it is assumed that arbitrary application A and application B are installed, and the installers are referred to as AP installer A300 and AP installer B301. When installation is started from the AP installer A, in a conventional virtual machine environment, as shown by a dotted line, installation data (for example, execution files, drivers, data stored in the registry, etc.) is stored in the virtual HDD 109 managed by the guest OS 105. (For example, the ApplicationA folder under the Program folder of the C drive) (s300). In FIG. 3, the execution file A302, the driver A303, the data A304, and the like are those.

  On the other hand, in the system of the present embodiment, the virtual AP conversion module 106 redirects and saves from a region that should be originally stored to a predetermined region on the virtual AP image 110 (s301). In FIG. 3, an execution file A305, a driver A306, data A307, and the like on the virtual AP image 110 are shown. As described above, data related to the application can be separated on the virtual AP image 110.

  FIG. 4 is a diagram illustrating an operation example of the virtual AP module.

  First, it is assumed that the virtual AP 111 attempts to write the stored data B (s400). The virtual AP 111 attempts to write to the area of the stored data B401 on the virtual HDD 109 (s402). However, in actuality, the virtual AP conversion module 106 redirects and writes to the area of the storage data B404 on the virtual AP image 110 (s403). At this time, the virtual AP conversion module 106 stores the correspondence relationship between the area of the stored data B401 on the virtual HDD where the data is originally stored and the area of the stored data B404 on the redirected virtual AP image 110. Thereafter, when an arbitrary module on the virtual AP 111 or the guest OS 105 performs read / write processing on the storage data B 401 on the virtual HDD 109, the virtual AP module 106 stores the storage data B 404 on the virtual AP image 110. Redirect to this area to read / write. As described above, by backing up the virtual AP image 110 from the virtual HDD 109 to the physical HDD, the application data can be separated from the image file of the guest OS. Therefore, management of the image file of each guest OS used on each virtual machine becomes unnecessary, and management of the OS image becomes easy.

  5 and 6 show a guest OS update and its flow.

  When the guest OS needs to be updated, the virtual machine management module 102 issues a stop command to the virtual machine 104, but before stopping on the virtual machine 104, the virtual APBU module 107 places the virtual AP image 110 on the physical HDD 112. Backup to (s500). Thereafter, the virtual machine 104 is stopped (s501). As a result, all data related to an arbitrary module such as an application running on the virtual machine 104 is copied onto the physical 112.

  Next, the update module 103 performs an update process for the master guest OS image 113 stored on the physical HDD 112 (s502). As a method for updating the master guest OS image 113, there is a method in which the master guest OS image 113 is mounted on an arbitrary virtual machine and updated. When the update of the master guest OS image 113 is completed, the guest OS image 114 is overwritten with the updated master guest OS image 113 (s503). Thereafter, the virtual machine management module 102 mounts and activates the guest OS image 114 on the virtual machine 104 (s504).

  After startup, the virtual APDL module 108 downloads the virtual AP image 115 backed up on the physical HDD 112 onto the virtual HDD 109 and arranges it as the virtual AP image 110 (s505). After downloading the virtual AP image 110, the guest OS 105 places an execution file, driver, data, and the like necessary for starting the virtual application 111 on the memory and starts the application (s506). At this time, the guest OS 105 tries to read the execution file, driver, and data to an arbitrary location on the virtual HDD 109, but is read from the virtual AP image 110 on the virtual HDD 109 by the redirect function of the virtual AP conversion module 106. Arranged on the memory. Thus, the update of the guest OS is completed.

System configuration diagram of an embodiment of the present invention Master guest OS image creation flow chart AP data separation (AP virtualization) diagram during AP installation Illustration of usage example of virtual AP module and virtual AP image Update diagram of guest OS in the present invention Guest OS update flowchart in the present invention

Explanation of symbols

  DESCRIPTION OF SYMBOLS 100 ... Virtual machine management server, 101 ... Host OS, 102 ... Virtual machine management module, 103 ... Update module, 104 ... Virtual machine, 105 ... Guest OS, 106 ... Virtual AP conversion module, 107 ... Virtual APBU module, 108 Virtual APDL Module 109 109 virtual HDD 110 virtual AP image 111 virtual AP 112 physical HDD 113 master guest OS image 114 guest OS image

Claims (1)

In a virtual machine server on which a plurality of virtual machines operate, a virtual machine management system that manages the plurality of virtual machines,
Means for creating a virtual AP image file on a virtual hard disk managed by a guest OS operating on the virtual machine for each virtual machine;
When an arbitrary module operating on an arbitrary virtual machine attempts to write or read arbitrary data to an arbitrary area on the virtual hard disk managed by the guest OS operating on the virtual machine , By redirecting from the area where writing or reading is instructed to a predetermined area on the virtual AP image file existing on the virtual hard disk, by changing the writing or reading destination and executing writing or reading, Means for separating the arbitrary data into the virtual AP image file;
Means for backing up the virtual AP image file from the virtual hard disk to a physical hard disk managed by a host OS on the virtual machine server;
Means for downloading the virtual AP image file on the physical hard disk onto the virtual hard disk,
A virtual machine characterized in that the guest OS image file can be handled in a unified manner by separating data related to a module operating on the arbitrary virtual machine from the guest OS image file. Management system.

Images