[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2009154272A1 - 版管理システム、方法、及び、プログラム - Google Patents

版管理システム、方法、及び、プログラム Download PDF

Info

Publication number
WO2009154272A1
WO2009154272A1 PCT/JP2009/061215 JP2009061215W WO2009154272A1 WO 2009154272 A1 WO2009154272 A1 WO 2009154272A1 JP 2009061215 W JP2009061215 W JP 2009061215W WO 2009154272 A1 WO2009154272 A1 WO 2009154272A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
update
image file
version
virtual machine
Prior art date
Application number
PCT/JP2009/061215
Other languages
English (en)
French (fr)
Inventor
川戸 正裕
Original Assignee
日本電気株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電気株式会社 filed Critical 日本電気株式会社
Priority to JP2010517976A priority Critical patent/JPWO2009154272A1/ja
Publication of WO2009154272A1 publication Critical patent/WO2009154272A1/ja

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/18File system types
    • G06F16/1873Versioning file systems, temporal file systems, e.g. file system supporting different historic versions of files

Definitions

  • the present invention relates to a version management system, method, and program, and more specifically, a version management system that manages a version of an image file that includes a storage image that represents at least part of the contents of a file system constructed in a storage apparatus,
  • the present invention relates to a method and a program.
  • Version management system version management system, version control system
  • An example of a version management system is described in Patent Document 1.
  • the version management system of Patent Document 1 includes a file registration server, a file distribution server, and a client. These elements are connected to each other via a network.
  • the file registration server stores a file to be subjected to version management in the file distribution server in response to a request from the client.
  • the file registration server compares the file with a past version and registers the difference.
  • the file distribution server stores the file registered by the file registration server and sends the file to the client in response to a request from the client.
  • the file distribution server stores the version of the file as a difference with respect to the past version
  • the file distribution server transmits the past version and the difference to the client.
  • the client performs processing for restoring the contents of the desired version from the past version and the difference.
  • the image file includes a storage image (disk image) that represents the contents of the storage device (virtual disk) that can be seen from the virtual machine as a file.
  • the first problem is that it is difficult to know what changes have been made between different versions of the same virtual machine. The reason is that when the difference between the image files is taken, information regarding the file system on the virtual disk is lost from the resulting difference file.
  • a method of comparing file systems on virtual disks instead of directly comparing image files is also conceivable.
  • the processing procedure becomes more complicated and processing time is extra.
  • the method of storing the difference file in the repository (corresponding to the file distribution server in Patent Document 1), when comparing with the file system on the virtual disk, it is necessary to compare after restoring the original image file. is there. Accordingly, extra time is required.
  • An object of the present invention is to provide a version management system, method, and program capable of easily referring to a difference between versions in version management for an image file of a virtual machine.
  • the image file registration means for registering an image file including a storage image representing at least part of contents of a management target file system built in the storage device in the storage device, and the storage A file system corresponding to a version of an image file registered in the storage device by registering in the storage device an update file including difference information representing a difference between the image file registered in the device and the image file at the time of version update
  • a version management system comprising update file registration means for recording, in a version management table, change information indicating each change event executed up to the version update time.
  • the present invention provides an image file deployment means for registering an image file including a storage image representing at least part of contents of a management target file system constructed in the storage apparatus in an image file storage area;
  • An update file including difference information representing a difference between the image file registered in the image file storage area and the image file at the time of version update is acquired, and corresponds to the version of the image file registered in the image file storage area
  • a server host comprising update file acquisition means for generating change information indicating each change event executed up to the version update time for the file system.
  • the third aspect of the present invention is the version management method using a computer according to the third aspect, wherein an image file including a storage image representing at least part of contents of a management target file system built in the storage apparatus is stored in the storage apparatus. Registering, an image file registered in the storage device, and an update file including difference information indicating a difference between an image file at the time of version update, and a step of registering in the storage device; Recording a change information indicating each change event executed up to the version update time on a file system corresponding to the version of the image file registered in the storage device in a version management table. I will provide a.
  • a version management method using a computer wherein an image file including a storage image representing a content of at least a part of a management target file system constructed in the storage apparatus is stored in an image file. Registering in the image file storage area, acquiring an update file including difference information indicating a difference between the image file registered in the image file storage area and the image file at the time of version update, and registering in the image file storage area And a step of generating change information indicating each change event executed up to the version update time for a file system corresponding to the version of the image file that has been made.
  • the present invention relates to a process of registering an image file including a storage image representing at least a part of the contents of a managed file system built in a storage device in an image file storage area in a computer, and to the image file storage area.
  • a process for obtaining an update file including difference information indicating a difference between the registered image file and the image file at the time of version update, and a file system corresponding to the version of the image file registered in the image file storage area And a process for generating change information indicating each change event executed up to the version update time.
  • the version management system, method, and program of the present invention can easily refer to differences between versions when used for version management for image files of virtual machines.
  • FIG. 1 is a block diagram showing a version management system according to an embodiment of the present invention.
  • the flowchart which shows the procedure of an update file registration process The flowchart which shows the procedure of an update file acquisition process.
  • FIG. 1 shows a virtual machine version management system according to an embodiment of the present invention.
  • the virtual machine version management system includes a virtual machine management device 100, a repository server 200, a storage device 300, and one or more virtual machine (VM) hosts 400.
  • Each of the virtual machine management apparatus 100, the repository server 200, and the virtual machine host 400 is a computer that operates under program control.
  • the storage device 300 is a storage device that includes a physical storage medium such as a hard disk.
  • the virtual machine version management system performs version management of a virtual machine that combines version management with an image file representing the state of the virtual machine as a management unit and version management with an update file as a management unit.
  • the image file is a file including a storage image representing at least part of the contents of a file system constructed in a storage device (virtual storage) accessed by the virtual machine.
  • the update file is a file including difference information for generating an image file of a newer version than the specific version from the past specific version of the image file. That is, the update file is a file that represents a difference in file system between the version before the change and another version after the change.
  • the update file includes, as difference information, the contents of the file / directory changed on the file system constructed in the virtual storage, or the difference between the contents before and after the change of the file / directory changed on the file system.
  • the image file is not always a single file.
  • the state of the virtual machine is expressed by a plurality of files such as a virtual machine setting file (VMX file), a virtual storage (VMDK file), and a nonvolatile memory (NVRAM file).
  • VMX file virtual machine setting file
  • VMDK file virtual storage
  • NVRAM file nonvolatile memory
  • these files are collectively referred to as an image file.
  • the version management since the setting file can be handled without any problem by the existing version management system, the version management may be performed by the existing version management technique separately from the virtual storage file.
  • the system administrator performs operations such as registration of an image file and deployment of the image file to the virtual machine host 400 through the virtual machine management apparatus 100.
  • the virtual machine management apparatus 100 includes an input device such as a keyboard and a mouse and an output device such as a display. The system administrator uses them to instruct the virtual machine management apparatus 100 for various operations.
  • a terminal having the same input / output device and the virtual machine management apparatus 100 may be connected by a communication means such as a network, and the system administrator may operate the virtual machine management apparatus 100 through the terminal.
  • the repository server 200 is an apparatus for storing / distributing image files and update files of each version used for version management of image files.
  • the virtual machine management apparatus 100 and the repository server 200 are connected by communication means such as a network.
  • the repository server 200 receives an operation request for the image file and the update file of the virtual machine host 400 from the virtual machine management apparatus 100.
  • the repository server 200 operates the data stored in the storage device 300 in response to the received request.
  • the repository server 200 and the storage device 300 are connected using connection means such as a fiber channel.
  • the storage device 300 may be a storage medium built in the repository server 200.
  • the storage device 300 stores a version management table 310, one or more image files 320, and one or more update files 330.
  • Any storage format can be used as the storage format of the image file 320 and the update file 330 in the storage device 300.
  • the storage format of the image file 320 may be an archive in which the contents of the virtual storage (virtual disk) and various setting files are combined into a zip format or the like.
  • the storage format of the update file is an archive in the zip format etc. of the changed contents of files that have changed between versions (for example, /etc/resolv.conf and /etc/nsswitch.conf). Can be used.
  • the storage format of the update file it is also possible to take a difference of contents before and after the change for each changed file and archive the difference.
  • the version management table 310 information for referring to the image file 320 or the update file 330 of the corresponding version for the version of the virtual machine is recorded. Also, the version management table 310 includes change information indicating each change event executed on the virtual disk from the previous version update to the current version update. The change information includes information (file name / directory name) for identifying a file that has been changed on the file system constructed on the virtual disk in the versions before and after the update. This change information is recorded in the version management table 310 in association with the update file 330.
  • FIG. 2 shows a specific example of the version management table 310.
  • the version management table 310 includes information on a virtual machine name, a version number, a type, a file name on the virtual machine, and a file name in the repository.
  • the virtual machine name is a name for the repository server 200 to identify the virtual machine.
  • the version number is a number for identifying the change history of each virtual machine identified by the virtual machine name. For each virtual machine, the first version number is “1”, and thereafter the version numbers increase to “2” and “3”.
  • the type is information indicating whether to indicate an image file or an update file.
  • a file name for identifying the image file or the update file in the storage device 300 is recorded.
  • an update file is stored in the storage device 300 for the combination of the virtual machine identified by the virtual machine “vm01” and the version number “2”. It can be seen that the file name of the update file is “vm01_update_002.zip”.
  • the file name on the virtual machine is information for identifying the change target, that is, information for identifying the name of the file or directory that has been changed on the virtual machine before and after the update.
  • the file name to be updated on the virtual machine is recorded with respect to the update file.
  • the type is an image file
  • the file name on the virtual machine is blank.
  • an update file corresponding to a combination of the virtual machine name “vm01” and the version number “2” is “/ etc / hosts” and “ It can be seen that the difference information for the two files in "/ etc / group” is included.
  • a plurality of file names on the virtual machine may correspond to a single virtual machine name / version number pair.
  • the virtual machine host 400 is a server machine on which the virtual machine operates. On the virtual machine host 400, an arbitrary number of virtual machines can be operated.
  • the repository server 200 and the virtual machine host 400 are connected by a virtual machine network 500.
  • the virtual machine network 500 is a network such as Ethernet (registered trademark).
  • the virtual machine network 500 may be connected to the virtual machine management device 100 and the storage device 300.
  • the repository server 200 includes an image file registration unit 210, an image file distribution unit 220, an update file registration unit 230, an update file distribution unit 240, and a snapshot registration unit 250.
  • the image file registration unit 210 stores an image file to be distributed in the storage device 300.
  • the image file registration unit 210 stores, for example, an image file for a newly created virtual machine in the storage device 300.
  • the image file distribution unit 220 distributes the image file 320 stored in the storage device 300 to the virtual machine host 400.
  • the update file registration unit 230 acquires the update file from the virtual machine host 400 and stores it in the storage device 300.
  • the update file distribution unit 240 distributes the update file 330 stored in the storage device 300 to the virtual machine host 400.
  • the update file distribution unit 240 distributes the update file to the virtual machine host 400 and applies the difference information included in the update file to the file system of the virtual machine.
  • the snapshot registration unit 250 acquires the contents of the image file and the update file at a specific time from the virtual machine host 400 and stores them in the storage device 300.
  • the virtual machine host 400 includes an image file deployment unit 410, an update file acquisition unit 420, an update file application unit 430, a snapshot acquisition unit 440, and an image file storage area 450.
  • An arbitrary number of virtual machines are operating on the virtual machine host 400.
  • Each virtual machine has an update log recording unit 460.
  • Each virtual machine also stores an update log 470 that records changes made to the file system built on the virtual disk as part of the image file.
  • the image file storage area 450 is a storage area for storing an image file of each virtual machine operating on the virtual machine host 400.
  • the virtual machine host 400 stores the image file in a storage device such as a hard disk built in the virtual machine host 400, for example.
  • the virtual machine host 400 may store the image file in a network storage (SAN: “Storage—Area” Network, NAS: Network—Attached—Storage, etc.) shared among a plurality of virtual machine hosts.
  • SAN Storage—Area” Network
  • NAS Network—Attached—Storage, etc.
  • the image file deployment unit 410 receives an image file from the repository server 200, stores the received image file in the image file storage area 450, and deploys the image file to the virtual machine. At that time, the image file deployment unit 410 performs registration processing of an image file for the virtual machine, if necessary. By deploying the image file to the virtual machine, the virtual machine becomes accessible to the image file (virtual disk). When deploying an image file to a virtual machine, the image file deployment unit 410 records the version number of the virtual machine to be deployed as an update record in the update log 470 for the virtual machine.
  • the update log recording unit 460 monitors the access to the virtual disk by the virtual machine during the operation of the virtual machine. Each time the change to the file system on the virtual disk accessed by the virtual machine occurs, the update log recording unit 460 adds an outline of the change to the update log 470 as a change history.
  • the change history includes the name of the file or directory where the change occurred.
  • the update file acquisition unit 420 receives an update file acquisition request from the repository server 200.
  • the update file acquisition unit 420 shifts to a version update process of the virtual machine operating on the virtual machine host 400 and writes an update record to which the new version number is added in the update log 470.
  • the update file acquisition unit 420 reads from the update log 470 the change history made between the previous update record and the latest update record, and identifies the file that has changed in the virtual disk based on the change history Then, an update file and change information are created.
  • the difference information included in the update file may be either the content of the file after the change or the difference between the file contents before and after the change.
  • the update file acquisition unit 420 includes the name of the file or directory in which the change has occurred and the type of operation applied to the file or directory in the change information.
  • the update file acquisition unit 420 returns the created update file and change information to the repository server 200.
  • the update file application unit 430 receives an update file from the repository server 200.
  • the update file application unit 430 applies the difference information included in the update file to the image file of the virtual machine operating on the virtual machine host 400.
  • the difference information is the contents of the file after the change
  • the update file application unit 430 overwrites the contents of the corresponding file in the virtual disk with the difference information included in the update file.
  • the difference information is the difference between the file contents before and after the change
  • the update file application unit 430 applies the difference between the file contents before and after the change to the contents of the corresponding file before the change in the virtual disk, Replace the file with the modified file contents.
  • the image file of the virtual machine stored in the image file storage area 450 is updated to the latest image file.
  • the snapshot acquisition unit 440 receives a snapshot acquisition request from the repository server. Upon receiving a snapshot acquisition request, the snapshot acquisition unit 440 proceeds to version update processing in a virtual machine operating on the virtual machine host 400 and writes an update record with a new version number added to the update log 470. To do.
  • the snapshot acquisition means 440 acquires the image file at that time after the update record is entered.
  • the snapshot acquisition unit 440 creates an update file and change information in the same procedure as the update file acquisition unit 420, and returns the created update file, change information, and image file to the repository server 200.
  • Fig. 3 shows the image file storage procedure.
  • the system administrator operates the virtual machine management apparatus 100 and designates registration of the image file (Management IV 11: M11).
  • the virtual machine management apparatus 100 transmits an image file registration request to the repository server 200 (M12).
  • the image file registration unit 210 of the repository server 200 requests the storage device 300 to deploy the image file and stores the image file 320 (M13).
  • the image file registration unit 210 adds the stored image file information to the version management table 310 (M14).
  • Figure 4 shows the image file distribution / deployment procedure.
  • the system administrator operates the virtual machine management apparatus 100 and designates distribution of the image file 320 to the virtual machine host 400 (M21). At this time, the system administrator can designate distribution of the image file of the first version or an arbitrary version.
  • the virtual machine management apparatus 100 transmits an image file distribution request to the repository server 200 (M22).
  • the image file distribution unit 220 of the repository server 200 searches the requested image file 320 with reference to the version management table 310, and acquires the search result, for example, the file name (M23). .
  • the image file distribution unit 220 acquires the image file 320 corresponding to the search result from the storage device 300 (M24).
  • the image file distribution unit 220 transmits the acquired image file 320 to the virtual machine host 400 together with the image file deployment request (M25).
  • the image file deployment unit 410 of the virtual machine host 400 stores the image file received from the repository server 200 in the image file storage area 450 of the host. Further, the image file deployment unit 410 performs registration of an image file for the virtual machine.
  • Figure 5 shows the update file acquisition / registration procedure.
  • the system administrator operates the virtual machine management apparatus 100 and designates that changes made on the virtual machine host 400 are registered in the repository as an update file (M31).
  • the virtual machine management apparatus 100 transmits an update file registration request to the repository server 200 (M32).
  • the update file registration unit 230 of the repository server 200 transmits an update file acquisition request to the designated virtual machine host 400 (M33).
  • the update file acquisition unit 420 of the virtual machine host 400 creates an update file and change information with reference to the update log 470 and returns the created update file and change information to the repository server 200.
  • the update file registration unit 230 acquires an update file and change information from the virtual machine host 400 as a response to the update file acquisition request transmitted in M33.
  • the update file registration unit 230 stores the acquired update file in the storage device 300 as the update file 330 (M34). Also, the update file registration unit 230 registers the information of the stored update file in the version management table 310 (M35). At that time, the update file registration unit 230 records the change information acquired together with the update file in the version management table 310 in association with the stored update file.
  • FIG. 6 shows the procedure for distributing / applying the update file.
  • the system administrator operates the virtual machine management apparatus 100 and designates that the state of the virtual machine host 400 is updated (M41). Alternatively, the system administrator may specify a specific version.
  • the virtual machine management apparatus 100 transmits an update file distribution request to the repository server 200 (M42).
  • the update file distribution unit 240 of the repository server 200 acquires the current version number of the virtual machine on the virtual machine host from the virtual machine host 400 (M43).
  • the update file distribution unit 240 refers to the version management table 310 of the storage device 300 and searches for an update file name to be applied (M44).
  • the update file distribution unit 240 acquires the contents of the update file 330 corresponding to the search result in M44 from the storage device 300 (M45).
  • the update file distribution unit 240 transmits the acquired update file 330 to the update application target virtual machine host 400 together with the update file application request (M46).
  • the update file application unit 430 on the virtual machine host 400 applies the update file received from the repository server 200 to the image file storage area 450 stored in the host, and updates the image file. .
  • FIG. 7 shows a procedure for acquiring a snapshot.
  • the system administrator operates the virtual machine management apparatus 100 and designates registration of a snapshot from the virtual machine host 400 (M51).
  • the virtual machine management apparatus 100 transmits a snapshot registration request to the repository server 200 (M52).
  • the snapshot registration unit 250 of the repository server 200 transmits a snapshot acquisition request to the virtual machine host 400 (M53).
  • the snapshot acquisition unit 440 of the virtual machine host 400 When receiving the snapshot acquisition request, creates an update file and change information, and transmits a set of the image file, update file, and change information to the snapshot registration unit 250. .
  • the snapshot registration unit 250 stores the acquired image file and the update file in the storage device 300 (M54). Further, the snapshot registration unit 250 adds the stored image file and update file information to the version management table 310. At that time, the snapshot registration unit 250 records the change information acquired together with the update file in the version management table 310 in association with the stored update file.
  • the latest image file can be distributed to the virtual machine host 400 by executing the image file distribution procedure shown in FIG. 4 and the update file application procedure shown in FIG. That is, first, a virtual machine image is distributed to a specific virtual machine host 400 in the image file processing procedure shown in FIG. Thereafter, the update file application process shown in FIG. 5 is performed, so that the image file on the host can be updated.
  • the repository server 200 When the image file registration operation (FIG. 3) is performed on the virtual machine management apparatus 100, the repository server 200 newly stores the image file 320 in the storage device 300. The repository server 200 sets the version number “1” for the image file 320.
  • the system administrator instructs the virtual machine management apparatus 100 to distribute the image file having the specified version number to the specific virtual machine host 400.
  • the version number of the image file specified by the distribution operation is the same as the version number of the image file on the virtual machine host 400 of the distribution destination.
  • the repository server 200 increases the version number of the virtual machine image file in the virtual machine host 400 by one when the system administrator performs an update file registration operation (FIG. 5).
  • the version number of the image file before the version update in the virtual machine matches the latest version number of the image file 320 or the update file 330 stored in the storage device 300. Therefore, the version number in the virtual machine after the version update is a version number obtained by adding 1 to the latest version number in the storage device 300.
  • the version number of the latest image file 320 or update file 330 stored in the storage device 300 is v
  • the version number of the image file in the virtual machine from which the update file is to be acquired is v + 1.
  • the repository server 200 assigns a version number obtained by adding 1 to the latest version number in the storage device 300 to the update file registered in the storage device 300 by the update file registration operation. Specifically, the repository server 200 assigns the version number v + 1 to the update file 330 that is registered in the storage device 300 by the update file registration operation and is necessary for updating the image file from the version number v to v + 1. .
  • the repository server 200 for a specific virtual machine is a version between the version of the image file in the current virtual machine host 400 and the version specified in the update file application operation. Is applied to the virtual machine host 400.
  • the version number of the image file in the virtual machine host 400 is updated to the version number specified by the update file application operation.
  • the version numbers of the image file 320 and the update file 330 managed by the repository server 200 do not change.
  • the repository server 200 sets the version number designated by the update file application operation as vx, the version number of the image file in the application target virtual machine host 400 as vy (vx> vy), the version number vy + 1,
  • the update files of vy + 2,..., vx are sequentially applied to the virtual machine host 400.
  • the image file with the version number and the subsequent update file may be applied.
  • the version number of the image file in the virtual machine host 400 is finally vx.
  • the repository server 200 increases the version number of the virtual machine image file in the virtual machine host 400 by one.
  • the version number of the image file before the version update in the virtual machine matches the latest version number of the image file 320 or the update file 330 stored in the storage device 300. Therefore, the version number in the virtual machine after the version update is a version number obtained by adding 1 to the latest version number in the storage device 300. Specifically, if the version number of the latest image file 320 or update file 330 stored in the storage device 300 is v, the version number of the image file in the snapshot acquisition target virtual machine is v + 1.
  • the repository server 200 assigns a version number obtained by adding 1 to the latest version number in the storage device 300 to the image file and the update file registered in the storage device 300 by the snapshot registration operation. Specifically, the repository server 200 assigns the version number v + 1 to the image file registered in the storage device 300 by snapshot registration. Further, the repository server 200 assigns the version number v + 1 to the update file 330 that is registered in the storage device 300 by the snapshot registration operation and is necessary for updating the image file from the version number v to v + 1.
  • Fig. 8 shows a specific example of version number assignment.
  • an image file registration operation is performed to register an image file for the new virtual machine in the repository server 200 (storage device 300).
  • the repository server 200 records the version number of the first version, that is, the version number “1” in the version management table 310 (FIG. 2) for the image file.
  • an image file distribution operation is performed at time t12, and the image file with the version number “1” is distributed to the specific virtual machine host 400.
  • both the storage device 300 and the virtual machine host 400 store the image file with the version number “1”.
  • an update file registration operation is performed, and the update file is registered in the storage device 300.
  • the repository server 200 records the version number “2” in the version management table 310 for the update file stored in the storage device 300. That is, the repository server 200 assigns the version number “2” to the update file that is acquired from the virtual machine host 400 and is required to increase the version number “1” to the version number “2”.
  • the storage device 300 stores an image file 320 having a version number “1” and an update file 330 having a version number “2”.
  • the virtual machine host 400 stores the image file with the version number “2”.
  • an update file registration operation is performed again to register the virtual machine update file in the storage device 300.
  • the version number of the image file of the virtual machine is increased to “3”.
  • the repository server 200 records the version number “3” in the version management table 310 for the update file acquired from the virtual machine host 400, and assigns the version number “3” to the update file.
  • the storage device 300 stores the image file 320 having the version number “1” and the update file 330 having the version number “2” and the version number “3”.
  • the virtual machine host 400 stores an image file having a version number “3”.
  • a snapshot registration operation is performed, and the virtual machine image file and the update file are registered in the storage device 300.
  • the repository server 200 records the version number “4” in the version management table 310 for each of the image file and the update file acquired from the virtual machine host 400. That is, the repository server 200 assigns the version number “4” to each of the image file and the update file registered by the snapshot registration operation.
  • the storage device 300 stores the image file 320 with the version number “1” and the version number “4”, and the update file 330 with the version numbers “2”, “3”, and “4”.
  • the virtual machine host 400 stores the image file with the version number “4”.
  • FIG. 9 shows a data example of the update log 470.
  • the image file deploying unit 410 deploys the image file to the virtual machine host 400 at time t12 in FIG. 8, the image file deploying unit 410 records an update record indicating that the image file with the version number “1” is deployed in the update log 470.
  • the update log recording unit 460 records changes made to the file system (virtual disk) by the virtual machine in the update log 470 after the image file is deployed.
  • the update log recording unit 460 indicates that “/ etc / hosts” and “/ etc / group” have been updated after the deployment of the image file with the version number “1” along with the update date and time. Are recorded in the update log 470.
  • the update file acquisition unit 420 When an update file registration operation is performed at time t13, the update file acquisition unit 420 records an update record indicating that the version number is updated to “2” in the update log.
  • the update file acquisition unit 420 refers to the update log 470, and after the update record of the version number “1” is recorded until the update record of the version number “2” is recorded, Examine the changes that have been made.
  • the update file acquisition unit 420 sets “/ etc An update file is generated based on the contents of "/ hosts” and "/ etc / group”.
  • the update file acquisition unit 420 transmits the generated update file to the repository server 200.
  • the update log recording unit 460 records changes made to the file system by the virtual machine in the update log 470 after the version number is updated to “2”.
  • the update file acquisition unit 420 records an update record indicating that the version number is updated to “3” in the update log 470. After that, based on the changes made to the file system by the virtual machine between the recording of the update record of the version number “2” and the recording of the update record of the version number “3” in the same operation as above. Generate an update file.
  • the update file acquisition unit 420 transmits the generated update file to the repository server 200.
  • the update log recording unit 460 records changes made to the file system by the virtual machine in the update log 470 after the version number is updated to “3”.
  • the snapshot acquisition unit 440 records an update record indicating that the version number is updated to “4” in the update log 470.
  • the snapshot acquisition means 440 operates in the same manner as described above, and after the update record of the version number “3” is recorded, the virtual machine is stored in the file system between the update record of the version number “4”.
  • An update file is generated based on the changes made.
  • the snapshot acquisition unit 440 transmits the generated update file and the image file at the time t15 to the repository server 200.
  • FIG. 10 shows a specific example of update conflict.
  • an image file for the new virtual machine is registered in the storage device 300.
  • the version number of the image file in the storage device 300 is “1”.
  • the image file 320 of the storage device 300 is distributed to the virtual machine host A.
  • the version numbers of the image file 320 in the storage device 300 and the image file on the virtual machine host A are both “1”.
  • the image file 320 is distributed from the repository server 200 to the virtual machine host B.
  • the version numbers of the image files in the storage device 300 and the image files on the virtual machine hosts A and B are all “1”.
  • an update file is acquired for the virtual machine host A.
  • the storage device 300 stores the image file 320 having the version number “1” and the update file 330 having the version number “2”.
  • the virtual machine host A stores an image file with a version number “2”
  • the virtual machine host B stores an image file with a version number “1”.
  • an attempt is made to acquire an update file for the virtual machine host B.
  • the latest version number in the storage device 300 is “2”, and the version number of the image file of the virtual machine host B is “1”. Therefore, the version numbers do not match.
  • the version number of the image file on the virtual machine host 400 needs to be the same as the version number of the latest image file or update file in the repository server 200. If this condition is not satisfied, it is treated as an update conflict and the update file registration operation fails.
  • the conflict can be resolved by the following procedure.
  • the update is applied to the virtual machine host B.
  • the version number of the image file on the virtual machine host B is “2”.
  • the version number of the image file on the virtual machine host B is “2”, so the update conflict is resolved and the update file is registered. To succeed.
  • the image file on the virtual machine host A and the image file on the virtual machine host B are not necessarily the same content immediately after the execution of the procedure (1). This is because the virtual machine host B may have a change that is not included in the update file with the version number “2”.
  • the update file with the version number “2” includes a change to / etc / hosts, and on the virtual machine host B, there is a possibility that different contents are changed to the same file / etc / hosts.
  • simply applying the update file with the version number “2” on the virtual machine host B causes inconsistency. In order to avoid this inconsistency, it is only necessary to manually synthesize the changed contents in the procedure (1).
  • the update file acquisition unit 420 refers to the change history in order to acquire a change made between a certain version of the virtual machine and the latest virtual machine.
  • the update file acquisition unit 420 refers to the change history, identifies a file name or directory name that has been changed, and generates an update file and change information.
  • An example of means for realizing the update log recording means 460 is means that resides in an operating system (OS) kernel and captures a system call related to file or directory update.
  • OS operating system
  • LuS Linux Auditing System
  • Linux registered trademark
  • the image file to be registered Prior to registration of the image file, the image file to be registered is placed at a position that can be referred to from at least one of the virtual machine management apparatus 100 and the repository server 200.
  • the system administrator operates the virtual machine management apparatus 100 to select image file registration (M11 in FIG. 3).
  • the system administrator inputs the virtual machine name and the image file name to be registered to the virtual machine management apparatus.
  • the system administrator may input additional information such as a natural language description of the virtual machine to be registered.
  • the virtual machine management apparatus 100 sends an image file registration request to the repository server 200 (M12 in FIG. 3).
  • the image file registration request includes information input by the system administrator, that is, a virtual machine name, an image file name, and other additional information.
  • the virtual machine management apparatus 100 when the image file to be registered is placed at a position that can be referred to from the repository server 200, the virtual machine management apparatus 100 includes the address information of the image file acquisition source in the image file name, etc.
  • An image file registration request is sent to the repository server 200.
  • the virtual machine management apparatus 100 sends a URL (Uniform Resource Locator) referring to the image file in the image file registration request. ) In this case, it is not necessary to include the contents of the image file in the image file registration request itself.
  • the virtual machine management apparatus 100 includes the contents of the image file to be registered in the image file registration request. For example, if the image file to be registered is stored in the internal hard disk of the virtual machine management device 100 and the image file is not shared with the repository server 200 via the network, the virtual machine management device 100 The contents of the image file are transmitted to the repository server 200.
  • any file transfer means such as FTP (File Transfer Protocol), HTTP (Hypertext Transfer Protocol), or SSH (Secure Shell) can be used.
  • FIG. 11 shows the procedure of the image file registration process.
  • the image file registration unit 210 determines the file name in the repository for the image file to be registered (step S211).
  • the image file registration unit 210 determines, for example, a virtual machine name, a character string indicating an image file (image), and a character string obtained by concatenating the version number with “_” (underscore) as the file name in the repository. To do. Specifically, the file name of the image file with the virtual machine name “vm01” is determined as “vm01_image_01.zip”.
  • the image file registration unit 210 stores the contents of the image file of the registration file in the storage device 300 (step S212).
  • the image file registration unit 210 acquires the content of the image file from the URL and stores it in the storage device 300.
  • the image file registration request includes the content of the image file
  • the image file registration unit 210 stores the content of the included image file in the storage device 300.
  • This step S212 corresponds to M13 in FIG.
  • the image file registration unit 210 attaches the file name in the repository determined in step S211 to the image file.
  • the image file registration unit 210 After storing the image file, the image file registration unit 210 adds information about the image file to be registered to the version management table 310 (step S213).
  • This step S213 corresponds to M14 in FIG.
  • the image file registration unit 210 records the virtual machine name included in the image file registration request in “virtual machine name” of the version management table 310 (FIG. 2), and records 1 in “version number”. .
  • the image file registration unit 210 records information indicating the image file in “type”, and records the file name determined in step S211 in “file name in repository”.
  • the image file registration unit 210 also registers the additional information in the version management table 310. This additional information can later be used for convenience by the system administrator. Note that either registration of the image file in step S212 and addition of the version management table 310 in step S213 may be performed first.
  • the system administrator operates the virtual machine management apparatus 100 to select image file distribution (M21 in FIG. 4).
  • the system administrator inputs the virtual machine name, the virtual machine version number, and the host name of the virtual machine host 400 of the distribution destination (hereinafter also referred to as the distribution destination host name).
  • the virtual machine management apparatus 100 sends an image file distribution request to the repository server (M22 in FIG. 4).
  • the image file distribution request includes information input to the virtual machine management apparatus 100 by the system administrator, that is, a virtual machine name, a version number, and a distribution destination host name.
  • the repository server 200 Upon receiving an image file distribution request from the virtual machine management apparatus 100, the repository server 200 performs image file distribution processing by the image file distribution unit 220.
  • FIG. 12 shows the procedure of the image file distribution process.
  • the image file distribution unit 220 searches the version management table 310 using the virtual machine name, version number, and type as a key, and acquires the in-repository file name of the image file for the corresponding virtual machine and version number. (Step S221). This step S221 corresponds to M23 in FIG.
  • step S221 the image file distribution unit 220 executes a search using the virtual machine name and version number specified in the image file distribution request received from the virtual machine management apparatus 100 as search keys.
  • the “type” used as the search key in step S221 is an image file.
  • the image file distribution unit 220 returns an error to the virtual machine management apparatus 100 when the file name in the repository cannot be acquired, that is, when an entry satisfying the search condition is not found, and performs processing. finish.
  • the image file distribution unit 220 acquires the image file 320 corresponding to the file name in the repository acquired in step S221 from the storage device 300 (step S222). This step S222 corresponds to M24 in FIG. If the corresponding file does not exist in the storage device 300, the image file distribution unit 220 returns an error to the virtual machine management device 100 and ends the process.
  • the image file distribution unit 220 transmits an image file deployment request to the virtual machine host 400 (step S223).
  • This step S223 corresponds to M25 in FIG.
  • the image file distribution unit 220 transmits an image file deployment request to the virtual machine host 400 corresponding to the distribution destination host name specified in the image file distribution request received from the virtual machine management apparatus 100.
  • the image file distribution request includes the virtual machine name, the version number, and the contents of the image file.
  • the virtual machine name included in this request is the same as the virtual machine name included in the image file distribution request, and the version number is the same as the version number included in the image file distribution request.
  • the content of the image file is the content of the image file acquired in step S222.
  • the image file deployment unit 410 When the virtual machine host 400 receives the image file deployment request from the repository server 200, the image file deployment unit 410 performs the image file deployment process.
  • FIG. 13 shows the procedure of image file deployment processing.
  • the image file deployment unit 410 checks the operating status of the virtual machine specified by the image file deployment request and determines whether the virtual machine is operating (step S411).
  • the virtual machine host 400 holds information indicating the operating status of each virtual machine, and the image file deployment unit 410 can check whether the virtual machine is operating by referring to the information. it can.
  • the image file deployment unit 410 determines that the virtual machine is operating, it stops the virtual machine (step S412).
  • the image file deployment unit 410 issues a shutdown command, for example, and stops the virtual machine.
  • the image file deployment unit 410 stores the image file included in the image file deployment request in the image file storage area 450 (step S413).
  • the image file deployment unit 410 stores the virtual machine name included in the image file deployment request in association with the image file.
  • step S411 When the image file deployment unit 410 determines in step S411 that the virtual machine is not operating, the image file deployment unit 410 proceeds to step S413 and stores the image file in the image file storage area 450. If the designated virtual machine does not exist on the virtual machine host 400, that is, if the image file corresponding to the image file storage area 450 is not stored, the image file deployment unit 410 proceeds to step S413 and proceeds to the image file. Is stored.
  • the image file deployment unit 410 After storing the image file, the image file deployment unit 410 newly creates an update log 470 in the stored image file and records the version number therein (step S414). When the update log 470 already exists, the image file deployment unit 410 deletes it and creates a new update log 470. In step S414, the image file deployment unit 410 records the version number specified in the image file deployment request received from the repository server 200 in the update log 470.
  • the image file deployment unit 410 executes a necessary registration operation in step S413.
  • the system administrator operates the virtual machine management apparatus 100 to select update file registration (M31 in FIG. 5). At that time, the system administrator gives the virtual machine management apparatus 100 the host name (hereinafter referred to as update acquisition source host name), virtual machine name, and update target directory path of the update file acquisition source virtual machine host 400. input.
  • update acquisition source host name hereinafter referred to as update acquisition source host name
  • virtual machine name hereinafter referred to as update acquisition source host name
  • update target directory path of the update file acquisition source virtual machine host 400 input.
  • the update target directory path is specified when it is desired to acquire the update contents under a specific directory, instead of acquiring all the update contents made on the specified virtual machine. For example, if you want to obtain the updated contents of the directory under “/ etc / sysconfig”, specify “/ etc / sysconfig” as the update target directory. When the update target directory is not specified, it is assumed that acquisition of all files / directories on the specified virtual machine is requested. The fact that the update target directory is not specified is equivalent to the case where “/” is specified as the update target directory path in an operating system such as Linux.
  • the virtual machine management apparatus 100 sends an update file registration request to the repository server 200 (M32 in FIG. 5).
  • the update file registration request includes information input by the system administrator, that is, an update acquisition source host name, a virtual machine name, and an update target directory.
  • FIG. 14 shows the procedure of the update file registration process.
  • the update file registration unit 230 searches the version management table 310 using the virtual machine name included in the update file registration request as a key, and acquires the latest image file or the latest update file version number (step S231). ).
  • the update file registration unit 230 transmits an update file acquisition request to the virtual machine host 400 corresponding to the update acquisition source host name (step S232). This step S232 corresponds to M33 in FIG.
  • the update file acquisition request includes the virtual machine name specified in the update file registration request, the directory path name of the update target specified in the update file record request, and the version number searched in step S231.
  • FIG. 15 shows the procedure of the update file acquisition process.
  • the update file acquisition unit 420 acquires the current version number for the virtual machine specified in the update file acquisition request from the image file storage area 450 (step S421), and is included in the acquired version number and the update file acquisition request.
  • the version number is compared (step S422). When the update conflict described above occurs, the version numbers do not match. If the version numbers do not match, the update file acquisition unit 420 returns an error to the repository server 200 as a response to the update file acquisition request, and ends the process (step S428).
  • the update file acquisition unit 420 checks the operating status of the virtual machine designated by the update file acquisition request when the version numbers match (step S423). When the virtual machine is operating, the update file acquisition unit 420 stops the virtual machine (step S424). The reason for stopping the virtual machine is to prevent the virtual machine from changing the virtual disk when the update file is generated. In step S424, it is not necessary to completely stop the virtual machine, and it is sufficient to stop the file access.
  • the update file acquisition unit 420 retrieves the image file corresponding to the virtual machine designated by the update file acquisition request from the image file storage area 450, and updates the update file 470 in the image file at the end.
  • the record is recorded (step S425).
  • the update record to be recorded at this time is a version number obtained by adding 1 to the version number acquired in step S421. If the update file acquisition unit 420 determines in step S423 that the virtual machine is not operating, the update file acquisition unit 420 proceeds to step S425 as it is and records the update record in the update log.
  • the update file acquisition unit 420 stores, from the update log 470, a change history for the virtual machine specified in the update file acquisition request between the previous update record and the update record recorded in step S425. get.
  • the update file acquisition unit 420 identifies a file or directory that has changed on the virtual machine based on the acquired change history, checks what change has occurred since the previous update, and generates change information. Further, the update file acquisition unit 420 acquires the contents of the changed file or directory and generates an update file (step S426).
  • step S426 the update file acquisition unit 420 checks the change history between the update record with the version number “2” and the update record with the version number “3”, and identifies the file or directory that has changed.
  • “/etc/resolv.conf” and “/etc/nsswitch.conf” are updated between the version number “2” and the version number “3”.
  • the update file acquisition unit 420 acquires the contents of “/etc/resolv.conf” and “/etc/nsswitch.conf” on the virtual disk accessed by the virtual machine, and creates an update file.
  • the update file acquisition unit 420 transmits the created update file and change information to the repository server 200 as a response to the update file acquisition request (step S427), and ends the process.
  • the update file acquisition unit 420 transmits, for example, an update file including the contents of “/etc/resolv.conf” and “/etc/nsswitch.conf” after the change as difference information to the repository server 200. Also, change information indicating that “update” has been made to “/etc/resolv.conf” and “/etc/nsswitch.conf” is sent to the repository server 200.
  • the update file registration unit 230 receives a response to the update file acquisition request from the virtual machine host 400 transmitted in step S232.
  • the received response is a success response (step S427 in FIG. 15) or an error response (step S428).
  • the response in addition to the fact that the update file acquisition was successful, the response includes change information including the file name on the virtual machine where the change has occurred, and the update file entity including the difference information indicating the change contents And are included.
  • the update file registration unit 230 determines whether or not the update file has been successfully acquired (step S233). When the update file registration unit 230 receives a response indicating that the update file acquisition has failed from the virtual machine host 400, the update file registration unit 230 notifies the virtual machine management apparatus 100 of the failure (step S237) and ends the process.
  • the update file registration unit 230 determines a file name in the repository corresponding to the update file acquired from the virtual machine host 400 (step S234).
  • the update file registration unit 230 determines, for example, a character string obtained by connecting a virtual machine name, a character string (update) for distinguishing an image file and an update file, and a version number as a file name in the repository. Specifically, the update file registration unit 230 determines the file name in the repository as “vm01_update — 02.zip” for the virtual machine name “vm01” and the version number “2”.
  • the update file registration unit 230 stores the update file acquired from the virtual machine host 400 in the storage device 300 as the update file 330 (step S235).
  • This step S235 corresponds to M34 in FIG.
  • the update file registration unit 230 gives the file name in the repository determined in step S234 to the update file.
  • the update file registration unit 230 records the change information acquired together with the stored update file in the version management table 310 (step S236).
  • This step S236 corresponds to M35 in FIG.
  • the update file registration unit 230 notifies success as a response to the virtual machine management apparatus 100, and ends the process.
  • step S236 the update file registration unit 230 adds a new entry to the version management table 310 and records the following information in each item.
  • the virtual machine name the virtual machine name included in the update file registration request is recorded.
  • version number a version number obtained by adding 1 to the version number acquired in step S231 is recorded.
  • Type the update file is recorded, and in “Repository file name”, the file name determined in step S234 is recorded.
  • file name on virtual machine change information included in the response to the update file acquisition request in step S232, that is, information indicating which file on the virtual machine the update file corresponds to is recorded. .
  • the system administrator operates the virtual machine management apparatus 100 to select update file application (M41 in FIG. 6). At that time, the system administrator sends the virtual machine name to be distributed, the version number of the virtual machine, and the host name of the virtual machine host 400 to which the update file is applied (hereinafter referred to as the update application destination host name) to the virtual machine management apparatus 100. Also called).
  • the version number may be omitted. If the input of the version number is omitted, the virtual machine version stored in the storage device 300 is handled as if the latest version number was specified.
  • the virtual machine management apparatus 100 transmits an update file distribution request to the repository server 200 (M42 in FIG. 6).
  • the update file distribution request includes information input to the virtual machine management apparatus 100, that is, information on the virtual machine name, version number, and update application destination host name.
  • the repository server 200 Upon receiving an update file distribution request from the virtual machine management apparatus 100, the repository server 200 performs update file distribution processing by the update file distribution unit 240.
  • FIG. 16 shows the procedure of the update file distribution process.
  • the update file distribution unit 240 inquires of the virtual machine host 400 about the current version number of the virtual machine on the virtual machine host 400, and acquires the latest version number (step S241). This step S241 corresponds to M43 in FIG.
  • step S241 the update file distribution unit 240 makes an inquiry to the virtual machine host 400 corresponding to the update application destination host name specified in the received update file distribution request.
  • This inquiry includes the virtual machine name included in the update file distribution request.
  • the virtual machine host 400 that has received the inquiry acquires the version number of the image file of the virtual machine to be queried from the image file storage area 450 included in the virtual machine host 400 and returns the version number to the repository server 200.
  • the update file distribution unit 240 fails to inquire about the virtual machine host 400, that is, if the version number of the image file of the virtual machine to be inquired cannot be acquired, the update file distribution unit 240 A failure response is notified and the process ends.
  • a typical case in which acquisition of the version number fails is a case where the virtual machine designated as the query target does not exist on the virtual machine host 400.
  • the update file distribution unit 240 refers to the version management table 310 and acquires the update file name (step S242). This step S242 corresponds to M44 in FIG.
  • the update file distribution unit 240 uses the search key with “virtual machine name” as the virtual machine name included in the update file distribution request and “type” as the update file, and the version management table 310 (FIG. 2). ) To obtain the file name of the corresponding update file. By this search, the update file distribution unit 240 acquires the version numbers of all update files stored in the storage device 300 and the corresponding update file names for the specified virtual machine name. If the corresponding information is not found in step S242, the update file distribution unit 240 notifies the failure as a response to the virtual machine management apparatus 100 and ends the process.
  • the update file distribution unit 240 acquires the contents of the update file 330 to be applied to the virtual machine host 400 from the storage device 300 (step S243).
  • This step S243 corresponds to M45 in FIG.
  • the update file distribution unit 240 determines the contents of the update file that is larger than the version number acquired in step S241 and not more than the version number included in the update file acquisition request from the update files acquired in step S242. get. If the update file distribution request does not include a version number, the update file distribution unit 240 acquires the contents of all update files having version numbers larger than the version number acquired in step S241.
  • Step S243 will be described using a specific example. It is assumed that the update file distribution request includes the virtual machine name “vm01” and the version number “3”. Further, it is assumed that the current version number in the virtual machine is “1” as a result of the inquiry in step S241.
  • the update file distribution unit 240 refers to the version management table 310 shown in FIG. 2 and, among the virtual machine name “vm01” and the type “update file”, the version number is larger than “1” and “3”. Get the file name (file name in the repository) of the following update file.
  • the update file distribution unit 240 acquires the contents of the update file corresponding to the virtual machine name vm01 and the version numbers “2” and “3”. As shown in this example, in step S243, a plurality of update files may be acquired at once.
  • the update file distribution unit 240 in step S243, the image file with the version number “8” and the version numbers “9” and “10”. May be acquired as the contents of the update file to be applied to the virtual machine host 400.
  • the update file distribution unit 240 transmits an update file application request to the virtual machine host 400 (step S244).
  • This step S244 corresponds to M46 in FIG.
  • the transmission destination of the update file application request is the virtual machine host 400 corresponding to the update application destination host name included in the update file distribution request.
  • the update file application request includes the virtual machine name included in the update file distribution request, the version number acquired in step S241, and the contents of the update file acquired in step S243. If the update file distribution unit 240 has acquired update files for a plurality of version numbers in step S243, the update file distribution unit 240 includes the acquired plurality of update files in the update file application request.
  • FIG. 17 shows the procedure of update file application processing.
  • the update file application unit 430 confirms the operation status of the virtual machine specified in the update file application request (step S431).
  • the update file application unit 430 stops the virtual machine (step S432).
  • the update file application unit 430 expands the content of the update file included in the update file application request to the image file specified in the update file application request in the image file storage area 450 after the virtual machine is stopped. (Step S433).
  • step S433 by expanding the contents of the update file in the file system accessed by the virtual machine, the contents of the file name or directory name recorded in the file name on the virtual machine in the version management table 310 are It is updated to the contents of the file or directory in the image file of the desired version.
  • step S433 the update file application unit 430 expands the contents of the update file in order from the update file with the smallest version number when the update file application request includes a plurality of update files. For example, when the update file application request includes an update file with the version number “2” and an update file with the version number “3”, the update file application unit 430 expands the contents of the update file with the version number “2”. Later, the contents of the update file with the version number “3” are expanded. If the update file application unit 430 determines in step S431 that the virtual machine is not in operation, the update file application unit 430 proceeds to step S433 as it is and expands the contents of the update file in the image file storage area 450.
  • the update file application unit 430 writes an update record at the end of the update log 470 (step S434).
  • the update log 470 to be updated is an update log corresponding to the virtual machine that has expanded the update file in step S433.
  • the update file application unit 430 writes the latest version number among the update files expanded in step S433 in the update record. That is, the update file application unit 430 enters the version number of the update file with the largest version number in the update record.
  • the system administrator operates the virtual machine management apparatus 100 to select snapshot registration (M51 in FIG. 7).
  • the system administrator inputs the host name of the virtual machine host 400 of the snapshot acquisition source (hereinafter also referred to as the snapshot acquisition source host name) and the virtual machine name to the virtual machine management apparatus 100.
  • the virtual machine management apparatus 100 sends a snapshot registration request to the repository server 200 (M52 in FIG. 7).
  • the snapshot acquisition request includes information input by the system administrator, that is, a snapshot acquisition destination host name and a virtual machine name.
  • FIG. 18 shows a procedure for snapshot registration processing. Most of the snapshot registration procedures are the same as the update file registration processing procedure (FIG. 14). The main difference between the snapshot registration process and the update file registration process is that an image file is registered in addition to the update file.
  • the snapshot registration unit 250 searches the version management table 310 using the virtual machine name included in the received snapshot registration request as a key, and acquires the latest image file or update file version number (step S251).
  • the snapshot registration unit 250 transmits a snapshot acquisition request to the virtual machine host 400 (step S252). This step S252 corresponds to M53 in FIG.
  • step S252 the snapshot registration unit 250 transmits a snapshot acquisition request to the virtual machine host 400 corresponding to the snapshot acquisition source virtual machine host name specified in the snapshot acquisition request.
  • the snapshot acquisition request includes the virtual machine name included in the snapshot acquisition request and the version number obtained as a search result in step S251.
  • FIG. 19 shows a procedure for snapshot acquisition processing. Most of the procedure of the snapshot acquisition process is the same as the procedure of the update file acquisition process shown in FIG. The main difference between the snapshot acquisition process and the update file acquisition process is that an image file is acquired in addition to the update file.
  • the snapshot acquisition unit 440 acquires the current version number of the virtual machine designated by the snapshot acquisition request from the image file storage area 450 (step S441).
  • the snapshot acquisition unit 440 compares the version number acquired in step S441 with the version number specified in the snapshot acquisition request, and determines whether or not they match (step S442). When the two do not match, the snapshot acquisition unit 440 notifies the repository server 200 of the failure as a response to the snapshot acquisition request (step S448), and ends the process.
  • step S443 the snapshot acquisition unit 440 checks whether the virtual machine specified in the snapshot acquisition request is operating.
  • the snapshot acquisition unit 440 stops the virtual machine (step S444).
  • the snapshot acquisition unit 440 records the update record in the update log 470 on the image file corresponding to the virtual machine specified by the snapshot acquisition request in the image file storage area 450 (step S40).
  • step S445 the snapshot acquisition unit 440 records a version number obtained by adding 1 to the version number acquired in step S441 as an update record.
  • step S443 When the snapshot acquisition unit 440 determines in step S443 that the virtual machine is not operating, the snapshot acquisition unit 440 proceeds to step S445 as it is and records the update record in the update log 470. After recording the update record, the snapshot acquisition unit 440 acquires, from the update log 470, a history of changes made on the virtual machine between the previous update record (version update) and the current update record. .
  • the snapshot acquisition means 440 identifies a file or directory that has changed on the virtual machine based on the acquired change history, checks what change has occurred since the previous update, and generates change information. In addition, the snapshot acquisition unit 440 acquires the contents of the changed file or directory and generates an update file. Furthermore, the snapshot acquisition unit 440 acquires the entire image file for the virtual machine (step S446). The snapshot acquisition unit 440 transmits the created update file and change information and the acquired image file to the repository server 200 as a response to the snapshot acquisition request (step S447), and ends the process.
  • the snapshot registration unit 250 receives a response to the snapshot acquisition request from the virtual machine host 400 transmitted in step S252.
  • the received response is a success response (step S447 in FIG. 19) or an error response (step S448).
  • the response includes the contents of the image file, the update file, and the change information, in addition to the fact that the snapshot has been successfully acquired.
  • the image file and the update file included in the response have a version number corresponding to the latest version on the virtual machine host 400 for the virtual machine specified in the snapshot acquisition request.
  • the snapshot registration unit 250 determines whether the acquisition of the snapshot is successful (step S253).
  • the snapshot registration unit 250 receives a response indicating that the snapshot acquisition has failed from the virtual machine host 400, the snapshot registration unit 250 notifies the virtual machine management apparatus 100 of the failure (step S257) and ends the process.
  • a typical example in which snapshot acquisition fails is when the version number specified in the snapshot acquisition request is different from the version number on the virtual machine host 400 from which the snapshot is acquired, that is, an update conflict has occurred. Is the case.
  • the snapshot registration unit 250 determines a file name in the repository for the acquired image file and update file (step S254).
  • the file name in the repository for the image file is the same as the determination of the file name in the repository by the image file registration unit 210 (step S211 in FIG. 11).
  • the determination of the file name in the repository for the update file is the same as the determination of the file name in the repository by the update file registration unit 230 (step S234 in FIG. 14).
  • the snapshot registration unit 250 stores the image file and the update file acquired from the virtual machine host 400 in the storage device 300 (step S255). This step S255 corresponds to M54 in FIG. In step S255, the snapshot registration unit 250 assigns the file name in the repository determined in step S254 to the image file and the update file, respectively.
  • the snapshot registration unit 250 adds information on the stored image file and update file to the version management table 310 (step S256). This step S256 corresponds to M55 in FIG. After adding information to the version management table 310, the snapshot registration unit 250 notifies success as a response to the virtual machine management apparatus 100, and ends the processing.
  • step S256 the snapshot registration unit 250 adds an entry for recording information in the version management table 310 for the image file, and records the following information in each item.
  • the virtual machine name the virtual machine name included in the received snapshot registration request is recorded.
  • version number a version number obtained by adding 1 to the version number acquired in step S251 is recorded.
  • Type records “image file”, and “repository file name” records the repository file name for the image file determined in step S254.
  • the snapshot registration unit 250 adds an entry for recording information in the version management table 310 for the update file, and records the following information in each item.
  • the virtual machine name the virtual machine name included in the received snapshot registration request is recorded.
  • version number a version number obtained by adding 1 to the version number acquired in step S251 is recorded.
  • the update file is recorded in “Type”, and the file name in the repository for the update file determined in step S254 is recorded in “File name in repository”. Further, in “File name on virtual machine”, the file name included in the change information included in the response to the snapshot acquisition request in step S252 is recorded.
  • the administrator uses the virtual machine management apparatus 100 to specify a virtual machine and check what files have been changed from one version to another at any time.
  • the virtual machine management apparatus 100 refers to the version management table 310 through the repository server 200 and acquires information on “file name on the virtual machine” in the version management table 310.
  • the virtual machine management apparatus 100 outputs the information on the “file name on the virtual machine” to an output device such as a display, so that the administrator can easily know what file has been changed between the versions. be able to.
  • the update file registration unit 230 updates the version of the image file in the virtual machine, and uses the difference information for generating the image file at the current version update time from the image file at the previous version update time.
  • the update file to be included is registered in the storage device 300.
  • the update file registration unit 230 records change information indicating what changes have been made to the virtual disk between the previous version update and the current version update in the version management table 310.
  • change information is recorded in the version management table 310. By referring to the change information, the administrator can know which file / directory has been changed and how the virtual machine is changed between different versions without looking at the contents of the update file.
  • the update file acquisition unit 420 includes the changed file contents or the difference between the file contents before and after the change as difference information in the update file.
  • the image file includes the entire contents of the virtual disk, and therefore it takes a long time to register the image file in the storage device 300.
  • the image file consumes a large storage capacity.
  • the time required for registering the update file can be shorter than when registering the contents (image file) of the entire virtual disk. .
  • the storage capacity required for the storage device 300 required for registering the update file can be reduced.
  • a difference between image files may be considered as difference information.
  • the version of the image file can be updated by applying the difference information to the image file before the version update. Further, compared with the case where the image file itself is registered in the storage device 300, the time required for registration and the storage capacity consumed can be reduced. Even when the update file is a difference between image files, it is possible to know which file / directory has been changed and how between different versions by referring to the change information. . However, since image files are usually large in size, it takes a long time to compare image files before and after version update. Further, when the comparison process is performed, it is necessary to temporarily store both the new and old versions of the image file on the computer, so that an extra storage area of the computer is consumed.
  • the file size changed on the virtual disk is smaller than the image file (entire virtual disk). For this reason, the time required to acquire the contents of a changed file or to generate a difference between file contents before and after the change of the changed file is compared to the time required to generate a difference between image files. short. Therefore, the update file is generated in a short time compared to the case where the difference between the image files is set as the update file by using the changed file contents or the difference between the file contents before and after the change as the update file. Can be done. In addition, the storage capacity required for work can be saved.
  • a file that has been changed in the virtual disk is identified by referring to an update log that records changes made to the virtual disk.
  • the changed file is identified by referring to the update log. Therefore, compared to when the image file is expanded and the file system on the virtual disk is compared to identify the changed file. Thus, it is possible to identify a file that has been changed in a short time.
  • the snapshot registration unit 250 updates the version of the image file in the virtual machine, the image file at the time of version update, and the update file and change information corresponding to the previous version update to the current version update. Are obtained and stored in the storage device 300.
  • a specific version of the image file can be distributed to the virtual machine host. For example, by storing the image file 320 with the version number “4” in the storage device 300 in the snapshot registration operation, the image with the version number “4” is distributed when distributing the image file with the version number “5”. The file and the update file with the version number “5” may be distributed. Therefore, the time required for image file deployment can be shortened as compared with the case where the image file with a specific version number is always distributed using the difference from the image file with the version number “1”.
  • FIG. 20 shows an example of a version management system that performs version management of an image file on a server host.
  • This version management system basically has the same configuration as the version management system of the above embodiment except that the virtual machine host 400 in FIG. 1 is replaced with the server host 400a and the image file storage area 450 is replaced with the storage device 480. It is.
  • the storage device 480 is a storage device to be managed, and is a storage device to which an image file is to be created.
  • the storage device 480 may be a real storage device or a virtual storage device constructed on the real storage device.
  • the image file creation unit may be the entire storage device 480 or an area (partition) provided in the storage device 480.
  • a program for realizing each means in the server host 400a is recorded on a storage device in the server host 400a.
  • the part where these programs are stored and the part where the disk image (image file) is written in the storage device 480 are preferably different disks or different areas.
  • a program for realizing each means in the server host 400a may be recorded as firmware in a read-only memory (ROM) built in the server host 400a.
  • the update log 470 is preferably recorded on a single disk or area on the storage device, a non-volatile memory, or the like.
  • the image file registration unit 210 registers the image file 320 in the storage device 300.
  • the image file 320 includes a disk image of the storage device 480.
  • the image file distribution unit 220 transmits the image file 320 to the server host 400a.
  • the image file deployment unit 410 receives an image file from the repository server 200 and deploys the received image file to the storage device 480. That is, the image file deployment unit 410 expands the contents of the image file on the storage device 480 so that the server host 400a can be accessed.
  • the update file acquisition unit 420 updates the version in the storage device 480 according to an instruction from the update file registration unit 230, generates an update file and change information, and transmits the update file and change information to the update file registration unit 230.
  • the update file includes difference information for generating a disk image at the current version update time from a disk image at the previous version update time. More specifically, the update file indicates the difference between the contents of the file / directory changed on the file system constructed in the storage device 480 or the contents before and after the change of the file / directory changed on the file system. , Included as difference information. Alternatively, the update file 330 may include a difference between disk images between different versions as difference information.
  • the change information is information indicating what changes have been made to the storage apparatus 480 between the previous version update and the current version update.
  • the update log recording unit 460 records changes made to the storage device 480 in the update log 470.
  • the update file acquisition unit 420 refers to the update log 470, identifies a file that has changed in the storage device 480, and includes information for identifying the file that has changed in the file system in the change information. .
  • the update file registration unit 230 acquires an update file and change information from the server host 400a.
  • the update file registration unit 230 registers the acquired update file as the update file 330 in the storage device 300.
  • the update file registration unit 230 records the acquired change information in the version management table 310.
  • the update file distribution unit 240 acquires the update file 330 from the storage device 300, and transmits the difference information included in the acquired update file to the server host 400a.
  • the update file application unit 430 receives the difference information from the update file distribution unit 240 and applies the received difference information to the storage device 480.
  • the update file application unit 430 applies the difference information to the storage apparatus 480, whereby the version of the storage apparatus 480 is updated to the version of the update file.
  • the snapshot acquisition unit 440 updates the version of the storage apparatus 480 according to an instruction from the snapshot registration unit 250, converts the contents of the storage apparatus 480 at the time of version update into an image file, and transmits the image file to the snapshot registration unit 250.
  • the snapshot acquisition unit 440 generates an update file and change information in the same procedure as the update file acquisition unit 420 and transmits the update file and change information to the snapshot registration unit 250.
  • the snapshot registration unit 250 registers the acquired image file and update file in the storage device 300 as an image file 320 and an update file 330, respectively.
  • the snapshot registration unit 250 records the acquired change information in the version management table 310.
  • each virtual machine host 400 or each server host 400a includes each unit such as the image file deployment unit 410 has been described. It is not essential for the host to have each means. For example, if the image file storage area 450 (FIG. 1) or the storage device 480 (FIG. 20) is accessible from a device other than the server host, the device is the image file deployment means 410, the update file acquisition means 420, the update file. You may have the application means 430 and the snapshot acquisition means 440. FIG. In that case, an apparatus having each unit such as the image file deployment unit 410 may perform processing such as image file deployment and update file transmission to a plurality of server hosts.
  • the version management system registers, in its minimum configuration, an image file including a storage image representing at least part of the contents of a managed file system built in the storage device in the storage device.
  • An image file registration means for registering, an update file including difference information representing a difference between an image file registered in the storage device and an image file at the time of version update, registered in the storage device, and registered in the storage device
  • Update file registration means for recording, in a version management table, change information indicating each change event executed up to the version update time for the file system corresponding to the version of the image file.
  • an image file including a storage image representing at least a part of the contents of a management target file system constructed in the storage apparatus is stored in the image file storage area.
  • An image file deployment unit to be registered, an image file registered in the image file storage area, and an update file including difference information representing a difference between the image file at the time of version update are acquired and registered in the image file storage area
  • the version management method is a version management method that uses a computer in its minimum configuration, and is a storage that represents the contents of at least a part of a file system to be managed built in a storage apparatus. Registering an image file including an image in a storage device, and registering an update file including difference information indicating a difference between the image file registered in the storage device and an image file at the time of version update in the storage device And recording, in the version management table, change information indicating each change event executed up to the version update time for the file system corresponding to the version of the image file registered in the storage device.
  • the version management method is a version management method that uses a computer in its minimum configuration, and is a storage that represents at least part of the contents of a managed file system built in a storage apparatus.
  • a step of registering an image file including an image in an image file storage area, and a step of acquiring an update file including difference information indicating a difference between the image file registered in the image file storage area and the image file at the time of version update And generating change information indicating each change event executed up to the version update time for the file system corresponding to the version of the image file registered in the image file storage area.
  • the version management system, method, and program of the present invention are not particularly limited, but when used for version management for image files of virtual machines, differences between versions can be easily referred to. Therefore, an arbitrary version of an image file can be easily constructed, and based on this, the state of the computer at an arbitrary time can be easily reproduced.
  • the present invention can be applied to uses such as version management of a test / evaluation system using a virtual machine in software development.
  • the present invention can also be applied to uses such as version management of a system constructed using a virtual machine in a software actual operation environment.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

 版管理システムは、ストレージ装置内に構築された管理対象のファイルシステムの少なくとも一部の内容を表すストレージイメージを含むイメージファイルを記憶装置に登録するイメージファイル登録手段と、前記記憶装置に登録されたイメージファイルと版更新時点におけるイメージファイルとの差を表す差分情報を含む更新ファイルを前記記憶装置に登録し、前記記憶装置に登録されたイメージファイルの版に対応するファイルシステムに対して前記版更新時点までに実行された各変更イベントを示す変更情報を版管理表に記録する更新ファイル登録手段とを備える。

Description

版管理システム、方法、及び、プログラム
 本発明は、版管理システム、方法、及び、プログラムに関し、更に詳しくは、ストレージ装置に構築されたファイルシステムの少なくとも一部の内容を表すストレージイメージを含むイメージファイルの版を管理する版管理システム、方法、及び、プログラムに関する。
 ファイル等のバージョン管理を行う版管理システム(バージョン管理システム、version control system)が知られている。版管理システムの一例が、特許文献1に記載されている。特許文献1の版管理システムは、ファイル登録サーバ、ファイル配付サーバ、及び、クライアントから構成されている。これら要素は、ネットワークを介して相互に接続されている。ファイル登録サーバは、クライアントからの要求に応じて、版管理の対象となるファイルを、ファイル配付サーバに格納する。ファイル登録サーバは、登録済みファイルの更新が要求された場合には、ファイルの過去の版との比較を行い、その差分を登録する。
 ファイル配付サーバは、ファイル登録サーバにより登録されたファイルを格納し、クライアントからの要求に応じて、ファイルをクライアントに送信する。ファイル配付サーバは、ファイルの版が過去の版に対する差分として格納されている場合は、過去の版と差分とをクライアントに送信する。クライアントは、過去の版と差分とから、所望の版の内容を復元する処理を行う。
特開2006-260212号公報
 VMware(登録商標)やXen(登録商標)などの仮想マシン(Virtual Machine)技術では、個々の仮想マシンの内部状態は、イメージファイルと呼ばれるファイルによって規定される。イメージファイルは、仮想マシン上から見えるストレージ装置(仮想ディスク)の内容をファイルとして表現したストレージイメージ(ディスクイメージ)を含む。仮想マシン技術を版管理システムに適用し、仮想マシンのイメージファイルを対象として版管理を行うことで、仮想マシンにて、過去のある版の内部状態を再現することが可能となる。
 しかしながら、特許文献1に記載の版管理システムを、仮想マシンのイメージファイルに適用した場合には、以下の問題点が発生する。第1の問題点は、同一の仮想マシンについての異なる版の間で、どのような変更がなされたかを知ることが困難であるということである。その理由は、イメージファイル同士の差分を取った場合、その結果の差分ファイルからは、仮想ディスク上のファイルシステムに関する情報が失われるためである。
 イメージファイル同士を直接比較する代わりに、仮想ディスク上のファイルシステムを比較する手法も考えられる。しかし、その場合は、処理手順はより複雑になり、処理時間も余分にかかる。また、リポジトリ(特許文献1におけるファイル配付サーバに相当)中に差分ファイルを格納する方式では、仮想ディスク上のファイルシステムと比較する際には、元のイメージファイルを復元した上で比較する必要がある。従って、更に余分な時間を要することになる。
 本発明は、仮想マシンについてのイメージファイルを対象とした版管理において、版間の差異を、容易に参照可能な版管理システム、方法、及び、プログラムを提供することを目的とする。
 本発明は、第1の態様において、ストレージ装置内に構築された管理対象のファイルシステムの少なくとも一部の内容を表すストレージイメージを含むイメージファイルを記憶装置に登録するイメージファイル登録手段と、前記記憶装置に登録されたイメージファイルと、版更新時点におけるイメージファイルとの差を表す差分情報を含む更新ファイルを前記記憶装置に登録し、前記記憶装置に登録されたイメージファイルの版に対応するファイルシステムに対して前記版更新時点までに実行された各変更イベントを示す変更情報を版管理表に記録する更新ファイル登録手段と、を備える版管理システムを提供する。
 本発明は、第2の態様において、ストレージ装置内に構築された管理対象のファイルシステムの少なくとも一部の内容を表すストレージイメージを含むイメージファイルをイメージファイル記憶域に登録するイメージファイル配備手段と、前記イメージファイル記憶域に登録されたイメージファイルと、版更新時点におけるイメージファイルとの差を表す差分情報を含む更新ファイルを取得し、前記イメージファイル記憶域に登録されたイメージファイルの版に対応するファイルシステムに対して前記版更新時点までに実行された各変更イベントを示す変更情報を生成する更新ファイル取得手段と、を備えるサーバホストを提供する。
 本発明は、第3の態様において、コンピュータを用いる版管理方法であって、ストレージ装置内に構築された管理対象のファイルシステムの少なくとも一部の内容を表すストレージイメージを含むイメージファイルを記憶装置に登録するステップと、前記記憶装置に登録されたイメージファイルと、版更新時点におけるイメージファイルとの差を表す差分情報を含む更新ファイルを前記記憶装置に登録するステップと、
 前記記憶装置に登録されたイメージファイルの版に対応するファイルシステムに対して前記版更新時点までに実行された各変更イベントを示す変更情報を版管理表に記録するステップと、を有する版管理方法を提供する。
 本発明は、第4の態様において、コンピュータを用いる版管理方法であって、ストレージ装置内に構築された管理対象のファイルシステムの少なくとも一部の内容を表すストレージイメージを含むイメージファイルをイメージファイル記憶域に登録するステップと、前記イメージファイル記憶域に登録されたイメージファイルと、版更新時点におけるイメージファイルとの差を表す差分情報を含む更新ファイルを取得するステップと、前記イメージファイル記憶域に登録されたイメージファイルの版に対応するファイルシステムに対して前記版更新時点までに実行された各変更イベントを示す変更情報を生成するステップと、を有する版管理方法を提供する。
 本発明は、第5の態様において、コンピュータに、ストレージ装置内に構築された管理対象のファイルシステムの少なくとも一部の内容を表すストレージイメージを含むイメージファイルを記憶装置に登録する処理と、前記記憶装置に登録されたイメージファイルと、版更新時点におけるイメージファイルとの差を表す差分情報を含む更新ファイルを前記記憶装置に登録する処理と、前記記憶装置に登録されたイメージファイルの版に対応するファイルシステムに対して前記版更新時点までに実行された各変更イベントを示す変更情報を版管理表に記録する処理と、を実行させるプログラムを提供する。
 本発明は、コンピュータに、ストレージ装置内に構築された管理対象のファイルシステムの少なくとも一部の内容を表すストレージイメージを含むイメージファイルをイメージファイル記憶域に登録する処理と、前記イメージファイル記憶域に登録されたイメージファイルと、版更新時点におけるイメージファイルとの差を表す差分情報を含む更新ファイルを取得する処理と、前記イメージファイル記憶域に登録されたイメージファイルの版に対応するファイルシステムに対して前記版更新時点までに実行された各変更イベントを示す変更情報を生成する処理と、を実行させるプログラムを提供する。
 本発明の版管理システム、方法、及び、プログラムは、仮想マシンについてのイメージファイルを対象とした版管理に用いると、版間の差異を、容易に参照することができる。
 本発明の上記、及び、他の目的、特徴及び利益は、図面を参照する以下の説明により明らかになる。
本発明の一実施形態の版管理システムを示すブロック図。 版管理表のデータ例を示す図。 イメージファイル登録の手順を示すシーケンス図。 イメージファイル配付の手順を示すシーケンス図。 更新ファイル登録の手順を示すシーケンス図。 更新ファイル適用の手順を示すシーケンス図。 スナップショット登録の手順を示すシーケンス図。 版番号割り当ての具体例を示す図。 更新ログのデータ例を示す図。 更新の競合が発生する例を示す図。 イメージファイル登録処理の手順を示すフローチャート。 イメージファイル配付処理の手順を示すフローチャート。 イメージファイル配備処理の手順を示すフローチャート。 更新ファイル登録処理の手順を示すフローチャート。 更新ファイル取得処理の手順を示すフローチャート。 更新ファイル配付処理の手順を示すフローチャート。 更新ファイル適用処理の手順を示すフローチャート。 スナップショット登録処理の手順を示すフローチャート。 スナップショット取得処理の手順を示すフローチャート。 サーバホストのイメージファイルの版管理を行う版管理システムを示すブロック図。
 以下、図面を参照し、本発明の実施の形態を詳細に説明する。図1は、本発明の一実施形態の仮想マシン版管理システムを示している。仮想マシン版管理システムは、仮想マシン管理装置100と、リポジトリサーバ200と、記憶装置300と、1台以上の仮想マシン(VM:Virtual Machine)ホスト400とを有する。仮想マシン管理装置100、リポジトリサーバ200、及び、仮想マシンホスト400は、それぞれ、プログラム制御により動作するコンピュータである。記憶装置300は、ハードディスクなどの物理的な記憶媒体を備える記憶装置である。
 仮想マシン版管理システムは、仮想マシンの状態を表すイメージファイルを管理単位とする版管理と、更新ファイルを管理単位とする版管理とを組み合わせた仮想マシンの版管理を行う。ここで、イメージファイルは、仮想マシンがアクセスするストレージ装置(仮想ストレージ)に構築されたファイルシステムの少なくとも一部の内容を表すストレージイメージを含むファイルである。また、更新ファイルは、過去の特定の版のイメージファイルからその特定の版よりも新しい版のイメージファイルを生成するための差分情報を含むファイルである。つまり、更新ファイルは、変更前の版と変更後の別の版との間で、ファイルシステムの差異を表現するファイルである。更新ファイルは、仮想ストレージに構築されたファイルシステム上で変更されたファイル/ディレクトリの内容、又は、ファイルシステム上で変更されたファイル/ディレクトリの変更前後での内容の差分を、差分情報として含む。
 なお、実際の仮想マシンソフトウェアでは、イメージファイルは単一のファイルとは限らない。例えば、VMware(登録商標)では、仮想マシンの状態は、仮想マシン設定ファイル(VMXファイル)、仮想ストレージ(VMDKファイル)、不揮発メモリ(NVRAMファイル)等の複数のファイルにより表現される。本明細書では、これらファイルを総称して、イメージファイルと表記する。ただし、設定ファイルについては、既存の版管理システムで問題なく取り扱うことができるため、仮想ストレージのファイルと分けて、既存の版管理の手法で版管理を行ってもよい。
 システム管理者は、仮想マシン管理装置100を通して、イメージファイルの登録、イメージファイルの仮想マシンホスト400への配備などの操作を行う。仮想マシン管理装置100は、キーボードやマウス等の入力装置と、ディスプレイ等の出力装置とを備えている。システム管理者は、それらを用いて、仮想マシン管理装置100に対して、各種操作を指示する。或いは、同様の入出力装置を備える端末と仮想マシン管理装置100との間をネットワーク等の通信手段で接続し、システム管理者が、端末を通して仮想マシン管理装置100を操作する形態でもよい。
 リポジトリサーバ200は、イメージファイルの版管理に用いられる、各版のイメージファイル及び更新ファイルを格納/配付する装置である。仮想マシン管理装置100とリポジトリサーバ200との間は、ネットワーク等の通信手段で接続されている。リポジトリサーバ200は、仮想マシン管理装置100から、仮想マシンホスト400のイメージファイルと更新ファイルとに対する操作の要求を受け取る。リポジトリサーバ200は、受け取った要求に対応して、記憶装置300に格納されたデータを操作する。リポジトリサーバ200と記憶装置300との間は、ファイバチャネル(Fibre Channel)などの接続手段を用いて接続される。または、記憶装置300は、リポジトリサーバ200に内蔵される記憶媒体でも良い。
 記憶装置300は、版管理表310、1以上のイメージファイル320、及び、1以上の更新ファイル330を記憶する。記憶装置300におけるイメージファイル320及び更新ファイル330の格納形式には、任意の格納形式を用いることができる。例えば、イメージファイル320の格納形式には、仮想ストレージ(仮想ディスク)の内容と各種の設定ファイルとをまとめてzip形式などのアーカイブにしたものを用いることができる。また、更新ファイルの格納形式には、版間で変更があったファイル(例えば/etc/resolv.confと/etc/nsswitch.conf)について、その変更後の内容をzip形式などのアーカイブにしたものを用いることができる。更新ファイルの格納形式の別例として、変更があった各ファイルについて変更の前後での内容の差分を取り、その差分をアーカイブしたものも考えられる。
 版管理表310には、仮想マシンの版について、該当する版のイメージファイル320又は更新ファイル330を参照するための情報が記録される。また、版管理表310には、過去の版更新から今回の版更新までの間に仮想ディスクに対して実行された各変更イベントを示す変更情報を含む。変更情報は、更新前後の版において、仮想ディスクに構築されたファイルシステム上で変更があったファイルを識別するための情報(ファイル名/ディレクトリ名)を含む。この変更情報は、更新ファイル330と対応付けて、版管理表310に記録される。
 図2に、版管理表310の具体例を示す。版管理表310は、仮想マシン名、版番号、種別、仮想マシン上のファイル名、及び、リポジトリ内ファイル名の各情報を有する。仮想マシン名は、リポジトリサーバ200が仮想マシンを識別するための名称である。版番号は、仮想マシン名によって識別される各仮想マシンのそれぞれについて、その変更履歴を識別するための番号である。各仮想マシンについて、最初の版番号は「1」であり、以後、「2」、「3」と、版番号が増加していく。
 種別は、イメージファイルと更新ファイルの何れを指すかを示す情報である。リポジトリ内ファイル名は、イメージファイル又は更新ファイルを記憶装置300内で識別するファイル名が記録される。図2に示す版管理表310を参照することで、例えば、仮想マシン「vm01」で識別される仮想マシンと版番号「2」の組み合わせについて、更新ファイルが記憶装置300に格納されており、その更新ファイルのファイル名は「vm01_update_002.zip」であることがわかる。
 仮想マシン上のファイル名は、前記変更対象を識別する情報、すなわち、仮想マシン上で更新前後の版において変更があったファイル又はディレクトリの名前を識別する情報である。仮想マシン上のファイル名には、更新ファイルに対して、仮想マシン上で更新の対象となるファイル名が記録される。種別がイメージファイルの場合は、仮想マシン上のファイル名は空欄となる。図2に示す版管理表310を参照することで、例えば、仮想マシン名「vm01」と版番号「2」との組合せに相当する更新ファイルは、その仮想マシンにおける「/etc/hosts」と「/etc/group」の2つのファイルに対する差分情報を含んでいることがわかる。この例が示すように、単一の仮想マシン名と版番号との組に対して、仮想マシン上のファイル名が複数対応することもあり得る。
 図1に戻り、仮想マシンホスト400は、その上で仮想マシンが動作するサーバ機である。仮想マシンホスト400上では、任意の数の仮想マシンを動作させることができる。リポジトリサーバ200と、仮想マシンホスト400とは、仮想マシンネットワーク500により接続されている。仮想マシンネットワーク500は、イーサネット(Ethernet:登録商標)等のネットワークである。仮想マシンネットワーク500には、仮想マシン管理装置100、及び、記憶装置300が接続されていてもよい。
 リポジトリサーバ200は、イメージファイル登録手段210、イメージファイル配付手段220、更新ファイル登録手段230、更新ファイル配付手段240、及び、スナップショット登録手段250を備える。イメージファイル登録手段210は、配付対象となるイメージファイルを、記憶装置300に格納する。イメージファイル登録手段210は、例えば新規に作成された仮想マシンについてのイメージファイルを、記憶装置300に格納する。イメージファイル配付手段220は、記憶装置300に格納されたイメージファイル320を、仮想マシンホスト400に配付する。
 更新ファイル登録手段230は、仮想マシンホスト400から、更新ファイルを取得し、記憶装置300に格納する。更新ファイル配付手段240は、記憶装置300に格納された更新ファイル330を仮想マシンホスト400に配付する。更新ファイル配付手段240は、更新ファイルを仮想マシンホスト400に配付して、更新ファイルに含まれる差分情報を、仮想マシンのファイルシステムに適用させる。スナップショット登録手段250は、仮想マシンホスト400から、特定の時点でのイメージファイルの内容及び更新ファイルを取得し、それらを記憶装置300に格納する。
 仮想マシンホスト400は、イメージファイル配備手段410、更新ファイル取得手段420、更新ファイル適用手段430、スナップショット取得手段440、及び、イメージファイル記憶域450を有する。仮想マシンホスト400上では、任意の台数の仮想マシンが動作している。各仮想マシンは、更新ログ記録手段460を有する。また、各仮想マシンは、イメージファイルの一部として、仮想ディスクに構築されたファイルシステムに対して行われた変更を記録した更新ログ470を記憶する。
 イメージファイル記憶域450は、仮想マシンホスト400上で動作する各仮想マシンのイメージファイルを記憶する記憶領域である。仮想マシンホスト400は、例えば、仮想マシンホスト400が内蔵するハードディスク等の記憶装置に、イメージファイルを格納する。或いは、仮想マシンホスト400は、複数の仮想マシンホスト間で共有されるネットワークストレージ(SAN: Storage Area Network、NAS:Network Attached Storageなど)に、イメージファイルを格納してもよい。
 イメージファイル配備手段410は、リポジトリサーバ200からイメージファイルを受信し、受信したイメージファイルをイメージファイル記憶域450に格納して、仮想マシンに対してイメージファイルを配備(deploy)する。その際、イメージファイル配備手段410は、必要に応じて、仮想マシンに対するイメージファイルの登録処理などを行う。仮想マシンに対してイメージファイルを配備することで、仮想マシンは、イメージファイル(仮想ディスク)に対してアクセス可能な状態となる。イメージファイル配備手段410は、仮想マシンに対してイメージファイルを配備する際に、その仮想マシンについての更新ログ470に、配備対象の仮想マシンの版番号を、更新記録として記録する。
 更新ログ記録手段460は、仮想マシンの動作中に、仮想マシンによる仮想ディスクへのアクセスを監視する。更新ログ記録手段460は、仮想マシンがアクセスする仮想ディスク上のファイルシステムへの変更が発生するたびに、その変更の概略を変更履歴として更新ログ470に追記する。変更履歴は、変更が発生したファイル又はディレクトリの名前が含まれる。
 更新ファイル取得手段420は、リポジトリサーバ200から更新ファイルの取得要求を受ける。更新ファイル取得手段420は、更新要求を受けると、仮想マシンホスト400上で動作する仮想マシンの版更新処理に移行し、更新ログ470に、新しい版番号が付加された更新記録を記入する。また、更新ファイル取得手段420は、更新ログ470から、前回の更新記録から最新の更新記録までの間になされた変更履歴を読み出し、変更履歴に基づいて仮想ディスクにて変更があったファイルを特定し、更新ファイル及び変更情報を作成する。操作の種類がファイル変更であるとき、更新ファイルに含まれる差分情報は、変更後のファイルの内容と、変更前後でのファイル内容の差分との何れでもよい。更新ファイル取得手段420は、変更情報には、変更が発生したファイル又はディレクトリの名前、及び、そのファイル又はディレクトリに適用した操作の種類を含める。更新ファイル取得手段420は、作成した更新ファイルと変更情報とをリポジトリサーバ200に返却する。
 更新ファイル適用手段430は、リポジトリサーバ200から、更新ファイルを受け取る。更新ファイル適用手段430は、更新ファイルを受け取ると、更新ファイルに含まれる差分情報を、仮想マシンホスト400上で動作する仮想マシンのイメージファイルに適用する。更新ファイル適用手段430は、例えば差分情報が変更後のファイルの内容であるときは、仮想ディスク中の該当ファイルの内容を、更新ファイルに含まれる差分情報で上書きする。また、更新ファイル適用手段430は、差分情報が変更前後でのファイル内容の差分であるときは、仮想ディスクにおける変更前の該当ファイルの内容に対して変更前後でのファイル内容の差分を適用し、該当ファイルを、変更後のファイル内容に置き換える。更新ファイル適用手段430が更新ファイルを適用することで、イメージファイル記憶域450に記憶される仮想マシンのイメージファイルが、最新版のイメージファイルに更新される。
 スナップショット取得手段440は、リポジトリサーバからスナップショットの取得要求を受け取る。スナップショット取得手段440は、スナップショットの取得要求を受けると、仮想マシンホスト400上で動作する仮想マシンにおける版更新処理に移行し、更新ログ470に、新しい版番号が付加された更新記録を記入する。スナップショット取得手段440は、更新記録の記入後、その時点でのイメージファイルを取得する。また、スナップショット取得手段440は、更新ファイル取得手段420と同様な手順で更新ファイル及び変更情報を作成し、作成した更新ファイル及び変更情報とイメージファイルとを、リポジトリサーバ200に返却する。
 図3に、イメージファイル格納の手順を示す。システム管理者は、仮想マシン管理装置100を操作して、イメージファイルの登録を指定する(Management 11:M11)。仮想マシン管理装置100は、リポジトリサーバ200に対して、イメージファイル登録要求を送信する(M12)。リポジトリサーバ200のイメージファイル登録手段210は、イメージファイル登録要求を受けると、記憶装置300に、イメージファイル配備を要求し、イメージファイル320を格納する(M13)。イメージファイル登録手段210は、イメージファイル320の格納後、格納したイメージファイルの情報を、版管理表310に追加する(M14)。
 図4に、イメージファイルの配付/配備の手順を示す。システム管理者は、仮想マシン管理装置100を操作して、イメージファイル320を仮想マシンホスト400に配付することを指定する(M21)。このとき、システム管理者は、初版又は任意の版のイメージファイルの配付を指定できる。仮想マシン管理装置100は、リポジトリサーバ200に対して、イメージファイル配付要求を送信する(M22)。リポジトリサーバ200のイメージファイル配付手段220は、イメージファイル配付要求を受けると、版管理表310を参照して要求されたイメージファイル320を検索し、その検索結果、例えばファイル名を取得する(M23)。
 イメージファイル配付手段220は、記憶装置300から、検索結果に該当するイメージファイル320を取得する(M24)。イメージファイル配付手段220は、取得したイメージファイル320を、イメージファイル配備要求と共に、仮想マシンホスト400に送信する(M25)。仮想マシンホスト400のイメージファイル配備手段410は、イメージファイル配備要求を受けると、リポジトリサーバ200から受信したイメージファイルを、当該ホストのイメージファイル記憶域450に格納する。また、イメージファイル配備手段410は、仮想マシンに対するイメージファイルの登録などを行う。
 図5に、更新ファイルの取得/登録の手順を示す。システム管理者は、仮想マシン管理装置100を操作して、仮想マシンホスト400上になされた変更を、更新ファイルとしてリポジトリに登録することを指定する(M31)。仮想マシン管理装置100は、リポジトリサーバ200に対して、更新ファイル登録要求を送信する(M32)。リポジトリサーバ200の更新ファイル登録手段230は、指定された仮想マシンホスト400に対して更新ファイル取得要求を送信する(M33)。仮想マシンホスト400の更新ファイル取得手段420は、更新ファイル取得要求を受けると、更新ログ470を参照して更新ファイル及び変更情報を作成し、作成した更新ファイル及び変更情報をリポジトリサーバ200に返す。
 更新ファイル登録手段230は、M33で送信した更新ファイル取得要求に対する応答として、仮想マシンホスト400から更新ファイル及び変更情報を取得する。更新ファイル登録手段230は、取得した更新ファイルを、記憶装置300に更新ファイル330として格納する(M34)。また、更新ファイル登録手段230は、格納した更新ファイルの情報を、版管理表310に登録する(M35)。その際、更新ファイル登録手段230は、更新ファイルと共に取得した変更情報を、格納した更新ファイルに対応付けて、版管理表310に記録する。
 図6は、更新ファイルの配付/適用の手順を示している。システム管理者は、仮想マシン管理装置100を操作して、仮想マシンホスト400の状態を最新にすることを指定する(M41)。或いは、システム管理者は、特定の版を指定してもよい。仮想マシン管理装置100は、リポジトリサーバ200に対して、更新ファイル配付要求を送信する(M42)。リポジトリサーバ200の更新ファイル配付手段240は、仮想マシンホスト400から、その仮想マシンホスト上の仮想マシンについての現在の版番号を取得する(M43)。
 更新ファイル配付手段240は、記憶装置300の版管理表310を参照し、適用対象の更新ファイル名を検索する(M44)。更新ファイル配付手段240は、記憶装置300の中から、M44での検索結果に該当する更新ファイル330の内容を取得する(M45)。更新ファイル配付手段240は、取得した更新ファイル330を、更新ファイル適用要求と共に、更新適用対象の仮想マシンホスト400に対して送信する(M46)。仮想マシンホスト400上の更新ファイル適用手段430は、更新ファイル適用要求を受け取ると、リポジトリサーバ200から受信した更新ファイルを、当該ホストが記憶するイメージファイル記憶域450に適用し、イメージファイルを更新する。
 図7は、スナップショットの取得の手順を示している。システム管理者は、仮想マシン管理装置100を操作して、仮想マシンホスト400からスナップショットの登録を指定する(M51)。仮想マシン管理装置100は、リポジトリサーバ200に対して、スナップショット登録要求を送信する(M52)。リポジトリサーバ200のスナップショット登録手段250は、スナップショット登録要求を受けると、仮想マシンホスト400に対して、スナップショット取得要求を送信する(M53)。
 仮想マシンホスト400のスナップショット取得手段440は、スナップショット取得要求を受けると、更新ファイル及び変更情報を作成し、イメージファイルと更新ファイル及び変更情報との組を、スナップショット登録手段250に送信する。スナップショット登録手段250は、イメージファイルと更新ファイルの組を取得すると、取得したイメージファイルと更新ファイルとを、それぞれ記憶装置300に格納する(M54)。また、スナップショット登録手段250は、格納したイメージファイル及び更新ファイルの情報を、版管理表310に追加する。その際、スナップショット登録手段250は、更新ファイルと共に取得した変更情報を、格納した更新ファイルに対応付けて、版管理表310に記録する。
 版管理システムでは、図4に示すイメージファイル配付の手順と、図5に示す更新ファイル適用の手順とを実行することで、仮想マシンホスト400に、最新のイメージファイルを配付することができる。すなわち、まず、図4に示すイメージファイルの処理手順で、仮想マシンイメージを特定の仮想マシンホスト400に配付する。その後、図5に示す更新ファイル適用の処理を行うことで、当該ホスト上のイメージファイルを最新の状態にすることができる。
 続いて、仮想マシン管理装置100に対する各操作と、仮想マシンにおけるイメージファイルの版番号、及び、記憶装置300に格納するイメージファイル320、更新ファイル330の版番号との関係について説明する。リポジトリサーバ200は、仮想マシン管理装置100に対してイメージファイル登録の操作(図3)がなされると、記憶装置300に、新規にイメージファイル320を格納する。リポジトリサーバ200は、このイメージファイル320に対して、版番号「1」を設定する。
 イメージファイル配付操作(図4)では、システム管理者は、仮想マシン管理装置100に対して、指定した版番号のイメージファイルを、特定の仮想マシンホスト400に配付するように指示する。イメージファイル配付操作を実行した直後の時点では、配付操作で指定したイメージファイルの版番号と、配付先の仮想マシンホスト400上のイメージファイルの版番号とは同一である。
 リポジトリサーバ200は、システム管理者が更新ファイル登録の操作(図5)を行うと、仮想マシンホスト400における仮想マシンのイメージファイルの版番号を1つ増加させる。通常は、仮想マシンにおける版更新前のイメージファイルの版番号は、記憶装置300が格納するイメージファイル320又は更新ファイル330の最新の版番号と一致する。このため、版更新後の仮想マシンにおける版番号は、記憶装置300内の最新の版番号に1を加えた版番号となる。具体的には、記憶装置300が格納する最新のイメージファイル320又は更新ファイル330の版番号がvであれば、更新ファイル取得対象の仮想マシンにおけるイメージファイルの版番号はv+1となる。
 リポジトリサーバ200は、更新ファイル登録の操作で記憶装置300に登録する更新ファイルに対して、記憶装置300内の最新の版番号に1を加えた版番号を割り当てる。具体的には、リポジトリサーバ200は、更新ファイル登録の操作で記憶装置300に登録する、イメージファイルを版番号vからv+1に更新するのに必要な更新ファイル330に対して、版番号v+1を割り当てる。
 更新ファイル適用の操作(図6)では、リポジトリサーバ200は、特定の仮想マシンについて、現在の仮想マシンホスト400におけるイメージファイルの版と、更新ファイル適用操作にて指定された版との間の版の更新ファイルを、仮想マシンホスト400に対して適用する。更新ファイルを適用することで、仮想マシンホスト400におけるイメージファイルの版番号は、更新ファイル適用操作にて指定された版番号に更新される。このとき、リポジトリサーバ200が管理するイメージファイル320及び更新ファイル330の版番号は変化しない。
 具体的には、リポジトリサーバ200は、更新ファイル適用操作にて指定された版番号をvx、適用対象の仮想マシンホスト400におけるイメージファイルの版番号をvy(vx>vy)として、版番号vy+1、vy+2、・・・、vxの更新ファイルを、順次に仮想マシンホスト400に対して適用する。ただし、記憶装置300に、版番号vyよりも新しい版番号のイメージファイルが存在する場合には、その版番号のイメージファイルと、以降の更新ファイルとを適用してもよい。更新ファイルを適用することで、最終的に、仮想マシンホスト400におけるイメージファイルの版番号はvxとなる。
 システム管理者が、スナップショット登録の操作(図7)を行うと、リポジトリサーバ200は、仮想マシンホスト400における仮想マシンのイメージファイルの版番号を1つ増加させる。通常は、仮想マシンにおける版更新前のイメージファイルの版番号は、記憶装置300が格納するイメージファイル320又は更新ファイル330の最新の版番号と一致する。このため、版更新後の仮想マシンにおける版番号は、記憶装置300内の最新の版番号に1を加えた版番号となる。具体的には、記憶装置300が格納する最新のイメージファイル320又は更新ファイル330の版番号がvであれば、スナップショット取得対象の仮想マシンにおけるイメージファイルの版番号はv+1となる。
 リポジトリサーバ200は、スナップショット登録の操作で記憶装置300に登録するイメージファイル及び更新ファイルに対して、それぞれ記憶装置300内の最新の版番号に1を加えた版番号を割り当てる。具体的には、リポジトリサーバ200は、スナップショット登録で記憶装置300に登録するイメージファイルに、版番号v+1を割り当てる。また、リポジトリサーバ200は、スナップショット登録の操作で記憶装置300に登録する、イメージファイルを版番号vからv+1に更新するのに必要な更新ファイル330に、版番号v+1を割り当てる。
 図8に、版番号割り当ての具体例を示す。時刻t11で、イメージファイル登録操作を行い、新規の仮想マシンについてのイメージファイルを、リポジトリサーバ200(記憶装置300)に登録する。このとき、リポジトリサーバ200は、当該イメージファイルについて、版管理表310(図2)に、初版の版番号、すなわち、版番号「1」を記録する。その後、時刻t12でイメージファイル配付操作を行い、版番号「1」のイメージファイルを、特定の仮想マシンホスト400に配付する。この操作の直後では、記憶装置300と仮想マシンホスト400とは、共に版番号「1」のイメージファイルを格納する。
 時刻t13で更新ファイル登録操作を行い、更新ファイルを記憶装置300に登録する。更新ファイル登録操作を行うことで、仮想マシンホスト400上の更新ファイル取得対象の仮想マシンのイメージファイルの版番号は、「2」に上がる。リポジトリサーバ200は、記憶装置300に格納する更新ファイルについて、版管理表310に、版番号「2」を記録する。つまり、リポジトリサーバ200は、仮想マシンホスト400から取得した、版番号「1」から版番号「2」に上げるために必要な更新ファイルに対して、版番号「2」を付与する。更新ファイル登録操作の直後では、記憶装置300は、版番号「1」のイメージファイル320と、版番号「2」の更新ファイル330とを格納する。また、仮想マシンホスト400は、版番号「2」のイメージファイルを格納する。
 時刻t14で、再び更新ファイル登録の操作を行い、仮想マシンの更新ファイルを記憶装置300に登録する。更新ファイル登録操作を行うことで、仮想マシンのイメージファイルの版番号は、「3」に上がる。リポジトリサーバ200は、仮想マシンホスト400から取得した更新ファイルについて、版管理表310に版番号「3」を記録し、更新ファイルに、版番号「3」を付与する。この操作の直後では、記憶装置300は、版番号「1」のイメージファイル320と、版番号「2」及び版番号「3」の更新ファイル330とを格納する。また、仮想マシンホスト400は、版番号「3」のイメージファイルを格納する。
 時刻t15で、スナップショット登録の操作を行い、仮想マシンのイメージファイルと更新ファイルとを、記憶装置300に登録する。スナップショット登録操作を行うことで、仮想マシンのイメージファイルの版番号は、「4」に上がる。リポジトリサーバ200は、仮想マシンホスト400から取得したイメージファイル及び更新ファイルのそれぞれについて、版管理表310に、版番号「4」を記録する。つまり、リポジトリサーバ200は、スナップショット登録の操作で登録するイメージファイル及び更新ファイルに、それぞれ版番号「4」を付与する。この操作の直後では、記憶装置300は、版番号「1」及び版番号「4」のイメージファイル320と、版番号「2」、「3」、「4」の更新ファイル330とを格納する。また、仮想マシンホスト400は、版番号「4」のイメージファイルを格納する。
 図9に、更新ログ470のデータ例を示す。イメージファイル配備手段410は、図8の時刻t12で仮想マシンホスト400にイメージファイルを配備する際に、更新ログ470に、版番号「1」のイメージファイルを配備した旨の更新記録を記録する。更新ログ記録手段460は、イメージファイルの配備後、仮想マシンがファイルシステム(仮想ディスク)に対して行った変更を、更新ログ470に記録していく。図9の例では、更新ログ記録手段460は、版番号「1」のイメージファイルの配備後、「/etc/hosts」と「/etc/group」とに更新があった旨を、更新日時と共に、更新ログ470に記録している。
 時刻t13で更新ファイル登録操作が行われると、更新ファイル取得手段420は、更新ログに、版番号を「2」に更新する旨の更新記録を記録する。更新ファイル取得手段420は、更新ログ470を参照して、版番号「1」の更新記録の記録後、版番号「2」の更新記録の記録までの間に、仮想マシンがファイルシステムに対して行った変更を調べる。図9を参照すると、版番号「1」と版番号「2」との間に「/etc/hosts」と「/etc/group」の更新があるので、更新ファイル取得手段420は、「/etc/hosts」と「/etc/group」の内容に基づいて、更新ファイルを生成する。更新ファイル取得手段420は、生成した更新ファイルを、リポジトリサーバ200に送信する。
 更新ログ記録手段460は、版番号が「2」に更新された後、仮想マシンがファイルシステムに対して行った変更を、更新ログ470に記録していく。時刻t14で更新ファイル登録操作が行われると、更新ファイル取得手段420は、更新ログ470に、版番号を「3」に更新する旨の更新記録を記録する。その後、上記と同様な動作で、版番号「2」の更新記録の記録後、版番号「3」の更新記録の記録までの間に、仮想マシンがファイルシステムに対して行った変更に基づいて更新ファイルを生成する。更新ファイル取得手段420は、生成した更新ファイルを、リポジトリサーバ200に送信する。
 更新ログ記録手段460は、版番号が「3」に更新された後、仮想マシンがファイルシステムに対して行った変更を、更新ログ470に記録していく。時刻t15でスナップショット登録操作が行われると、スナップショット取得手段440は、更新ログ470に、版番号を「4」に更新する旨の更新記録を記録する。その後、スナップショット取得手段440は、上記と同様な動作で、版番号「3」の更新記録の記録後、版番号「4」の更新記録の記録までの間に、仮想マシンがファイルシステムに対して行った変更に基づいて更新ファイルを生成する。スナップショット取得手段440は、生成した更新ファイルと、時刻t15の時点でのイメージファイルとを、リポジトリサーバ200に送信する。
 ここで、同一名称の仮想マシンについてのイメージファイルを複数の仮想マシンホストに配付すると、更新の競合が発生する可能性がある。図10に、更新の競合の具体例を示す。時刻t21で、新規の仮想マシンについてのイメージファイルを、記憶装置300に登録する。この操作が完了した時点では、記憶装置300におけるイメージファイルの版番号は「1」である。時刻t22で、記憶装置300のイメージファイル320を、仮想マシンホストAに配付する。この操作が完了した時点では、記憶装置300内のイメージファイル320、及び、仮想マシンホストA上のイメージファイルの版番号は共に「1」である。
 時刻t23で、リポジトリサーバ200からイメージファイル320を仮想マシンホストBに配付する。この操作が完了した時点では、記憶装置300内のイメージファイルと、仮想マシンホストA及びB上のイメージファイルの版番号は全て「1」である。時刻t24で、仮想マシンホストAを対象として、更新ファイルを取得する。この操作が完了した時点では、記憶装置300は、版番号「1」のイメージファイル320と版番号「2」の更新ファイル330とを記憶する。また、仮想マシンホストAは、版番号「2」のイメージファイルを記憶し、仮想マシンホストBは、版番号「1」のイメージファイルを記憶する。
 時刻t25で、仮想マシンホストBを対象として更新ファイルの取得を試みる。時刻t25の直前の時点において、記憶装置300内の最新の版番号は「2」であり、仮想マシンホストBのイメージファイルの版番号は「1」である。従って、版番号は一致しない。更新ファイル登録操作を行う直前において、仮想マシンホスト400上のイメージファイルの版番号は、リポジトリサーバ200中の最新のイメージファイル又は更新ファイルの版番号と同一である必要がある。この条件が満たされない場合は、更新の競合として扱い、更新ファイルの登録操作に失敗する。
 上記更新の競合が発生したときは、以下の手順で競合を解決することができる。
 (1)競合が発生した仮想マシンホストに対して更新を適用する。上記の例では、仮想マシンホストBに対して更新を適用する。その結果、仮想マシンホストB上のイメージファイルの版番号は「2」となる。
 (2)競合が発生した仮想マシンホストBを対象として、更新ファイルの登録を再試行する。上記の例では、仮想マシンホストBに対して更新を適用することで仮想マシンホストB上のイメージファイルの版番号は「2」となっているので、更新の競合は解消され、更新ファイルの登録に成功する。
 上記(1)の手順の実行直後の時点において、仮想マシンホストA上のイメージファイルと、仮想マシンホストB上のイメージファイルとは、必ずしも同じ内容ではない点に注意する必要がある。その理由は、仮想マシンホストBにおいて、版番号「2」の更新ファイルには含まれない変更がなされている可能性があるからである。上記競合解決の手順において、版番号「2」の更新ファイルと仮想マシンホストBとの間で、同一ファイルに対して異なる変更がなされている可能性がある。例えば、版番号「2」の更新ファイルは、/etc/hostsに対する変更を含み、仮想マシンホストB上では、同じファイル/etc/hostsに対して異なる内容の変更がなされている可能性がある。このような場合は、単に、仮想マシンホストB上で版番号「2」の更新ファイルを適用するだけでは不整合が生じる。この不整合を回避するためには、上記(1)の手順で、変更内容を手動で合成しておけばよい。
 更新ログ記録手段460により記録される変更履歴の内容、及び、更新ログ記録手段460の実現手段について説明する。変更履歴として記載する情報の一例は、仮想マシン上のファイル又はディレクトリに対する変更がなされた際に、その対象となったファイル又はディレクトリの名前をフルパスで表記したものである。更新ファイル取得手段420は、ある版の仮想マシンと、最新の仮想マシンとの間になされた変更を取得するために、変更履歴を参照する。更新ファイル取得手段420は、変更履歴を参照し、変更があったファイル名又はディレクトリ名を特定して、更新ファイル及び変更情報を生成する。
 更新ログ記録手段460を実現する手段の一例は、オペレーティングシステム(OS)のカーネルに常駐し、ファイル又はディレクトリ更新に関わるシステムコールを捕捉する手段である。この種のプログラムの一例として、Linux(登録商標)オペレーティングシステムと組み合わせて動作するLinux Auditing System(LauS)が知られている。
 続いて、全体の動作について詳細に説明する。はじめに、イメージファイルの登録の詳細について説明する。イメージファイルの登録に先立ち、登録の対象となるイメージファイルは、仮想マシン管理装置100又はリポジトリサーバ200の少なくとも一方から参照可能な位置に置かれる。システム管理者は、仮想マシン管理装置100を操作して、イメージファイル登録を選択する(図3のM11)。その際、システム管理者は、仮想マシン管理装置に対して、仮想マシン名、及び、登録対象のイメージファイル名を入力する。システム管理者は、この他にも、登録対象の仮想マシンについての自然言語による説明などの付加的な情報を入力してもよい。
 仮想マシン管理装置100は、イメージファイル登録操作がなされると、リポジトリサーバ200に対して、イメージファイル登録要求を送る(図3のM12)。イメージファイル登録要求は、システム管理者により入力された情報、すなわち、仮想マシン名、イメージファイル名、その他の付加的な情報を含む。
 ここで、登録対象のイメージファイルがリポジトリサーバ200から参照可能な位置に置かれている場合は、仮想マシン管理装置100は、イメージファイル名などに、イメージファイル取得元のアドレス情報などを含めて、リポジトリサーバ200にイメージファイル登録要求を送る。例えば、リポジトリサーバ200がインターネットを介してアクセス可能なWebサーバ上にイメージファイルが公開されているときは、仮想マシン管理装置100は、イメージファイル登録要求に、イメージファイルを参照するURL(Uniform Resource Locator)を含める。この場合、イメージファイル登録要求自体に、イメージファイルの内容を含める必要はない。
 一方、登録対象のイメージファイルがリポジトリサーバ200から参照できないときは、仮想マシン管理装置100は、イメージファイル登録要求に、登録対象のイメージファイルの内容を含める。例えば、登録対象のイメージファイルが仮想マシン管理装置100の内蔵ハードディスクに格納されており、かつ、そのイメージファイルがネットワークを介してリポジトリサーバ200と共有されていない場合は、仮想マシン管理装置100から、イメージファイルの内容をリポジトリサーバ200に送信する。このときのイメージファイルの送信手段には、FTP(File Transfer Protocol)、HTTP(Hypertext Transfer Protocol)、SSH(Secure Shell)など、任意のファイル転送手段を用いることができる。
 リポジトリサーバ200は、イメージファイル登録要求を受けると、イメージファイル登録手段210により、イメージファイル登録処理を行う。図11に、イメージファイル登録処理の手順を示す。イメージファイル登録手段210は、登録対象のイメージファイルに対して、リポジトリ内ファイル名を決定する(ステップS211)。イメージファイル登録手段210は、例えば、仮想マシン名、イメージファイルであることを示す文字列(image)、及び、版番号を“_”(アンダースコア)で連結した文字列をリポジトリ内ファイル名として決定する。具体的には、仮想マシン名「vm01」のイメージファイルのファイル名を、「vm01_image_01.zip」と決定する。
 イメージファイル登録手段210は、記憶装置300に、登録ファイルのイメージファイルの内容を格納する(ステップS212)。イメージファイル登録手段210は、イメージファイル登録要求にイメージファイルを参照するURLが含まれるときは、そのURLよりイメージファイルの内容を取得して、記憶装置300に格納する。イメージファイル登録手段210は、イメージファイル登録要求にイメージファイルの内容が含まれるときには、その含まれるイメージファイルの内容を、記憶装置300に格納する。このステップS212は、図3のM13に相当する。イメージファイル登録手段210は、ステップS212でイメージファイルの内容を格納する際に、そのイメージファイルに、ステップS211で決定したリポジトリ内ファイル名を付ける。
 イメージファイル登録手段210は、イメージファイルの格納後、版管理表310に、登録対象のイメージファイルに関する情報を追加する(ステップS213)。このステップS213は、図3のM14に相当する。イメージファイル登録手段210は、ステップS213では、版管理表310(図2)の「仮想マシン名」に、イメージファイル登録要求に含まれる仮想マシン名を記録し、「版番号」に1を記録する。また、イメージファイル登録手段210は、「種別」にイメージファイルを示す情報を記録し、「リポジトリ内ファイル名」に、ステップS211で決定したファイル名を記録する。イメージファイル登録手段210は、イメージファイル登録要求に付加的な情報が含まれる場合には、その付加的な情報も、版管理表310に登録する。この付加的な情報は、後に、システム管理者による便宜のために用いることができる。なお、ステップS212のイメージファイルの登録と、ステップS213の版管理表310の追加は、何れが先でもよい。
 次に、イメージファイルの配付/配備の詳細について説明する。システム管理者は、仮想マシン管理装置100を操作して、イメージファイル配付を選択する(図4のM21)。その際、システム管理者は、仮想マシン名、仮想マシンの版番号、及び、配付先の仮想マシンホスト400のホスト名(以下、配付先ホスト名とも呼ぶ)を入力する。仮想マシン管理装置100は、イメージファイル配付操作がなされると、リポジトリサーバに対して、イメージファイル配付要求を送る(図4のM22)。イメージファイル配付要求は、システム管理者が仮想マシン管理装置100に対して入力した情報、すなわち、仮想マシン名、版番号、及び、配付先ホスト名を含む。
 リポジトリサーバ200は、仮想マシン管理装置100からイメージファイル配付要求を受け取ると、イメージファイル配付手段220により、イメージファイル配付処理を行う。図12に、イメージファイル配付処理の手順を示す。イメージファイル配付手段220は、版管理表310に対して、仮想マシン名、版番号、種別をキーとして検索を実行し、該当する仮想マシン及び版番号についてのイメージファイルのリポジトリ内ファイル名を取得する(ステップS221)。このステップS221は、図4のM23に相当する。
 イメージファイル配付手段220は、ステップS221では、仮想マシン管理装置100から受け取ったイメージファイル配付要求にて指定される仮想マシン名及び版番号を検索キーとして、検索を実行する。ステップS221で検索キーとする「種別」は、イメージファイルである。イメージファイル配付手段220は、ステップS221の検索の結果、リポジトリ内ファイル名を取得できない場合、つまり、検索条件を満たすエントリが見つからない場合は、仮想マシン管理装置100に対してエラーを返し、処理を終了する。
 イメージファイル配付手段220は、記憶装置300から、ステップS221で取得したリポジトリ内ファイル名に相当するイメージファイル320を取得する(ステップS222)。このステップS222は、図4のM24に相当する。イメージファイル配付手段220は、記憶装置300に該当するファイルが存在しないときは、仮想マシン管理装置100に対してエラーを返し、処理を終了する。
 イメージファイル配付手段220は、仮想マシンホスト400に対して、イメージファイル配備要求を送信する(ステップS223)。このステップS223は、図4のM25に相当する。イメージファイル配付手段220は、ステップS223では、仮想マシン管理装置100から受け取ったイメージファイル配付要求にて指定される配付先ホスト名に該当する仮想マシンホスト400に対して、イメージファイル配備要求を送信する。イメージファイル配付要求は、仮想マシン名、版番号、及び、イメージファイルの内容を含む。この要求に含まれる仮想マシン名は、イメージファイル配付要求に含まれる仮想マシン名と同じであり、版番号は、イメージファイル配付要求に含まれる版番号と同じである。イメージファイルの内容は、ステップS222で取得したイメージファイルの内容である。
 仮想マシンホスト400は、リポジトリサーバ200からイメージファイル配備要求を受け取ると、イメージファイル配備手段410により、イメージファイル配備処理を行う。図13に、イメージファイル配備処理の手順を示す。イメージファイル配備手段410は、イメージファイル配備要求で指定される仮想マシンの稼働状況を調べ、仮想マシンが動作中であるか否かを判断する(ステップS411)。仮想マシンホスト400は、各仮想マシンの稼働状況を示す情報を保持しており、イメージファイル配備手段410は、その情報を参照することで、仮想マシンが動作中であるか否かを調べることができる。
 イメージファイル配備手段410は、仮想マシンが動作中であると判断したときは、その仮想マシンを停止する(ステップS412)。イメージファイル配備手段410は、例えばシャットダウンコマンドを発行して、仮想マシンを停止する。その後、イメージファイル配備手段410は、イメージファイル配備要求に含まれるイメージファイルを、イメージファイル記憶域450に格納する(ステップS413)。このときイメージファイル配備手段410は、イメージファイル配備要求に含まれる仮想マシン名を、イメージファイルと関連付ける形で格納する。
 イメージファイル配備手段410は、ステップS411で仮想マシンが動作中でないと判断したときは、そのままステップS413へ進み、イメージファイル記憶域450にイメージファイルを格納する。イメージファイル配備手段410は、指定された仮想マシンが仮想マシンホスト400上に存在しない場合、つまり、イメージファイル記憶域450に対応するイメージファイルが格納されていない場合も、ステップS413へ進んでイメージファイルを格納する。
 イメージファイル配備手段410は、イメージファイルの格納後、格納したイメージファイル内に更新ログ470を新規に作成し、そこに版番号を記録する(ステップS414)。イメージファイル配備手段410は、更新ログ470が既に存在しているときは、それを削除した上で、新規の更新ログ470を作成する。イメージファイル配備手段410は、ステップS414では、更新ログ470に、リポジトリサーバ200から受け取ったイメージファイル配備要求にて指定される版番号を記録する。
 なお、使用する仮想マシン製品によっては、仮想マシンを新規に動作させる際に、単にイメージファイル記憶域450に相当するディレクトリにイメージファイルをおくだけでは不十分で、別途、仮想マシン登録操作の実行が必要なものがある。その場合、イメージファイル配備手段410は、ステップS413で、必要な登録操作を実行する。
 続いて、更新ファイルの取得/登録の詳細について説明する。システム管理者は、仮想マシン管理装置100を操作して、更新ファイル登録を選択する(図5のM31)。その際、システム管理者は、仮想マシン管理装置100に対して、更新ファイル取得元の仮想マシンホスト400のホスト名(以下、更新取得元ホスト名)、仮想マシン名、及び、更新対象ディレクトリパスを入力する。
 更新対象ディレクトリパスは、指定した仮想マシン上に対してなされた全ての更新内容を取得するのに代えて、特定のディレクトリ以下の更新内容を取得したいときに指定する。例えば、「/etc/sysconfig」以下のディレクトリの更新内容を取得したいときは、更新対象ディレクトリに「/etc/sysconfig」を指定する。更新対象ディレクトリの指定がないときは、指定した仮想マシン上の全ファイル/ディレクトリの取得が要求されたものとして扱う。更新対象ディレクトリの指定がないことは、Linx等のオペレーティングシステムにおいて、更新対象のディレクトリパスとして「/」が指定された場合と等価である。
 仮想マシン管理装置100は、更新ファイル登録操作がなされると、リポジトリサーバ200に対して更新ファイル登録要求を送る(図5のM32)。更新ファイル登録要求は、システム管理者によって入力された情報、すなわち、更新取得元ホスト名、仮想マシン名、及び、更新対象ディレクトリを含む。
 リポジトリサーバ200は、仮想マシン管理装置100から更新ファイル登録要求を受け取ると、更新ファイル登録手段230により、更新ファイル登録処理を行う。図14に、更新ファイル登録処理の手順を示す。更新ファイル登録手段230は、版管理表310に対して、更新ファイル登録要求に含まれる仮想マシン名をキーとして検索を行い、最新のイメージファイル又は最新の更新ファイルの版番号を取得する(ステップS231)。更新ファイル登録手段230は、更新取得元ホスト名に該当する仮想マシンホスト400に対して更新ファイル取得要求を送信する(ステップS232)。このステップS232は、図5のM33に相当する。更新ファイル取得要求は、更新ファイル登録要求にて指定された仮想マシン名、更新ファイル要録要求にて指定された更新対象のディレクトリパス名、及び、ステップS231で検索された版番号を含む。
 仮想マシンホスト400は、更新ファイル取得要求を受け取ると、更新ファイル取得手段420により、更新ファイル取得処理を行う。図15に、更新ファイル取得処理の手順を示す。更新ファイル取得手段420は、イメージファイル記憶域450から、更新ファイル取得要求で指定された仮想マシンについての現在の版番号を取得し(ステップS421)、取得した版番号と、更新ファイル取得要求に含まれる版番号とを比較する(ステップS422)。前述した更新の競合が発生しているときは、版番号が一致しない。更新ファイル取得手段420は、版番号が一致しないときは、更新ファイル取得要求への応答として、リポジトリサーバ200に対してエラーを返し、処理を終了する(ステップS428)。
 更新ファイル取得手段420は、版番号が一致するときは、更新ファイル取得要求で指定された仮想マシンの稼働状況を調べる(ステップS423)。更新ファイル取得手段420は、仮想マシンが動作中であるときは、その仮想マシンを停止する(ステップS424)。仮想マシンを停止する理由は、更新ファイル生成時に、仮想マシンが仮想ディスクに対して変更を加えることを避けるためである。ステップS424では、仮想マシンを完全に停止する必要はなく、ファイルアクセスを停止するだけでもよい。
 更新ファイル取得手段420は、仮想マシンの停止後、イメージファイル記憶域450から更新ファイル取得要求で指定された仮想マシンに対応するイメージファイルを取り出し、そのイメージファイル内の更新ログ470の末尾に、更新記録を記録する(ステップS425)。このとき記録する更新記録は、ステップS421で取得した版番号に1を加えた版番号である。更新ファイル取得手段420は、ステップS423で仮想マシンが動作中でないと判断したときは、そのままステップS425に進んで、更新ログに更新記録を記録する。
 更新ファイル取得手段420は、更新記録の記録後、更新ログ470から、前回の更新記録とステップS425で記録した更新記録との間に、更新ファイル取得要求で指定された仮想マシンについての変更履歴を取得する。更新ファイル取得手段420は、取得した変更履歴に基づいて、仮想マシン上で変更があったファイル又はディレクトリを特定し、前回の更新からどのような変更があったかを調べ、変更情報を生成する。また、更新ファイル取得手段420は、変更があったファイル又はディレクトリの内容を取得し、更新ファイルを生成する(ステップS426)。
 例えば、ステップS425で、更新ログ470に、更新記録として版番号を「3」を記録したとする。更新ファイル取得手段420は、ステップS426で、版番号「2」の更新記録から、版番号「3」の更新記録の間にある変更履歴を調べ、変更があったファイル又はディレクトリを特定する。図9の例では、版番号「2」から版番号「3」の間に、「/etc/resolv.conf」と「/etc/nsswitch.conf」とが更新されていることがわかる。更新ファイル取得手段420は、ステップS426で、仮想マシンがアクセスする仮想ディスク上での「/etc/resolv.conf」と「/etc/nsswitch.conf」の内容を取得し、更新ファイルを作成する。
 更新ファイル取得手段420は、作成した更新ファイルと、変更情報とを、更新ファイル取得要求への応答としてリポジトリサーバ200に送信し(ステップS427)、処理を終了する。更新ファイル取得手段420は、例えば、変更後の「/etc/resolv.conf」と「/etc/nsswitch.conf」の内容を差分情報として含む更新ファイルを、リポジトリサーバ200に送信する。また、「/etc/resolv.conf」と「/etc/nsswitch.conf」に対して、「更新」があった旨の変更情報を、リポジトリサーバ200に送信する。
 図14に戻り、更新ファイル登録手段230は、ステップS232で送信した仮想マシンホスト400から更新ファイル取得要求に対する応答を受け取る。受け取る応答は、成功応答(図15のステップS427)又はエラー応答(ステップS428)である。成功応答の場合は、応答には、更新ファイル取得に成功した旨に加えて、変更があった仮想マシン上でのファイル名を含む変更情報と、変更内容を示す差分情報を含む更新ファイルの実体とが含まれる。更新ファイル登録手段230は、更新ファイルの取得に成功したか否かを判断する(ステップS233)。更新ファイル登録手段230は、仮想マシンホスト400から更新ファイル取得に失敗した旨の応答を受け取ったときは、仮想マシン管理装置100に対する応答として失敗を通知し(ステップS237)、処理を終了する。
 更新ファイル登録手段230は、更新ファイル取得に成功した旨の応答を受け取ると、仮想マシンホスト400から取得した更新ファイルに対応するリポジトリ内ファイル名を決定する(ステップS234)。更新ファイル登録手段230は、例えば、仮想マシン名と、イメージファイルと更新ファイルとを区別すための文字列(update)と、版番号とを連結した文字列を、リポジトリ内ファイル名として決定する。具体的には、更新ファイル登録手段230は、仮想マシン名「vm01」、版番号「2」に対して、リポジトリ内ファイル名を「vm01_update_02.zip」と決定する。
 更新ファイル登録手段230は、記憶装置300に、仮想マシンホスト400から取得した更新ファイルを、更新ファイル330として格納する(ステップS235)。このステップS235は、図5のM34に相当する。更新ファイル登録手段230は、更新ファイル格納に際しては、更新ファイルに、ステップS234で決定したリポジトリ内ファイル名を付与する。更新ファイル登録手段230は、更新ファイルの格納後、版管理表310に、格納した更新ファイルと共に取得したに変更情報を記録する(ステップS236)。このステップS236は、図5のM35に相当する。更新ファイル登録手段230は、版管理表310への記録後、仮想マシン管理装置100への応答として成功を通知し、処理を終了する。
 更新ファイル登録手段230は、ステップS236では、版管理表310に、新たなエントリを追加し、各項目に、以下の情報を記録する。「仮想マシン名」には、更新ファイル登録要求に含まれる仮想マシン名を記録する。「版番号」には、ステップS231で取得した版番号に1を加えた版番号を記録する。「種別」には、更新ファイルを記録し、「リポジトリ内ファイル名」には、ステップS234で決定したファイル名を記録する。また、「仮想マシン上のファイル名」には、ステップS232の更新ファイル取得要求に対する応答に含まれる変更情報、つまり、更新ファイルが仮想マシン上でのどのファイルに対応するかを示す情報を記録する。
 引き続き、更新ファイルの配付/適用の詳細について説明する。システム管理者は、仮想マシン管理装置100を操作して、更新ファイル適用を選択する(図6のM41)。その際、システム管理者は、仮想マシン管理装置100に、配付対象の仮想マシン名、仮想マシンの版番号、及び、更新ファイル適用先の仮想マシンホスト400のホスト名(以下、更新適用先ホスト名とも呼ぶ)を入力する。版番号は、入力を省略してもよい。版番号の入力が省略された場合は、記憶装置300に格納されている仮想マシンの版について、最新の版番号が指定されたものとして取り扱う。
 仮想マシン管理装置100は、更新ファイル適用操作がなされると、リポジトリサーバ200に、更新ファイル配付要求を送信する(図6のM42)。更新ファイル配付要求には、仮想マシン管理装置100に対して入力された情報、すなわち、仮想マシン名、版番号、更新適用先ホスト名の情報を含む。
 リポジトリサーバ200は、仮想マシン管理装置100から更新ファイル配付要求を受け取ると、更新ファイル配付手段240により、更新ファイル配付処理を行う。図16に、更新ファイル配付処理の手順を示す。更新ファイル配付手段240は、仮想マシンホスト400に対して、その仮想マシンホスト400上の仮想マシンの現在の版番号を問い合わせ、最新の版番号を取得する(ステップS241)。このステップS241は、図6のM43に相当する。
 更新ファイル配付手段240は、ステップS241では、受け取った更新ファイル配付要求にて指定されている更新適用先ホスト名に該当する仮想マシンホスト400に対して問合せを行う。この問合せには、更新ファイル配付要求に含まれる仮想マシン名が含まれる。問合せを受けた仮想マシンホスト400は、自身が備えるイメージファイル記憶域450から、問合せ対象の仮想マシンのイメージファイルの版番号を取得し、その版番号をリポジトリサーバ200に返す。
 なお、更新ファイル配付手段240は、仮想マシンホスト400に対する問合せに失敗した場合、つまり、問合せ対象の仮想マシンのイメージファイルの版番号が取得できなかったときは、仮想マシン管理装置100に対して、失敗応答を通知し、処理を終了する。版番号の取得に失敗する典型的なケースは、問合せ対象として指定された仮想マシンが、仮想マシンホスト400上に存在しないケースである。
 更新ファイル配付手段240は、版管理表310を参照して、更新ファイル名を取得する(ステップS242)。このステップS242は、図6のM44に相当する。更新ファイル配付手段240は、ステップS242では、「仮想マシン名」を更新ファイル配付要求に含まれる仮想マシン名とし、「種別」を更新ファイルとした検索キーを用いて、版管理表310(図2)を検索し、該当する更新ファイルのファイル名を取得する。更新ファイル配付手段240は、この検索により、指定した仮想マシン名について、記憶装置300に格納されている全ての更新ファイルの版番号と、それに対応する更新ファイル名とを取得する。更新ファイル配付手段240は、ステップS242で該当する情報が見つからない場合は、仮想マシン管理装置100への応答として失敗を通知し、処理を終了する。
 更新ファイル配付手段240は、記憶装置300から、仮想マシンホスト400に対して適用すべき更新ファイル330の内容を取得する(ステップS243)。このステップS243は、図6のM45に相当する。更新ファイル配付手段240は、ステップS243では、ステップS242で取得した更新ファイルのうち、ステップS241で取得した版番号よりも大きく、かつ、更新ファイル取得要求に含まれる版番号以下の更新ファイルの内容を取得する。更新ファイル配付手段240は、更新ファイル配付要求に版番号が含まれない場合は、ステップS241で取得した版番号よりも大きい版番号を持つ全ての更新ファイルの内容を取得する。
 ステップS243について、具体例を用いて説明する。更新ファイル配付要求には、仮想マシン名「vm01」、版番号「3」が含まれているとする。また、ステップS241での問合せの結果、仮想マシンにおける現在の版番号は「1」であったとする。更新ファイル配付手段240は、図2に示す版管理表310を参照して、仮想マシン名「vm01」、種別「更新ファイル」のうち、版番号が「1」よりも大きく、かつ、「3」以下の更新ファイルのファイル名(リポジトリ内ファイル名)を取得する。この場合、更新ファイル配付手段240は、ステップS243では、仮想マシン名vm01、版番号「2」、「3」に対応する更新ファイルの内容を取得する。この例が示すとおり、ステップS243では、複数の更新ファイルを一度に取得することがあり得る。
 なお、例えば、更新ファイル配付要求に含まれる版番号が「10」で、仮想マシンにおける現在の版番号が「1」のとき、記憶装置300に、版番号「2」~「10」の何れかのイメージファイルが存在するときは、それを用いることもできる。例えば、版番号「8」のイメージファイルが記憶装置300に存在するときは、更新ファイル配付手段240は、ステップS243では、版番号「8」のイメージファイルと、版番号「9」、「10」の更新ファイルとを、仮想マシンホスト400に対して適用すべき更新ファイルの内容として取得すればよい。
 更新ファイル配付手段240は、仮想マシンホスト400に対して、更新ファイル適用要求を送信する(ステップS244)。このステップS244は、図6のM46に相当する。更新ファイル適用要求の送信先は、更新ファイル配付要求に含まれる更新適用先ホスト名に該当する仮想マシンホスト400である。更新ファイル適用要求は、更新ファイル配付要求に含まれる仮想マシン名、ステップS241で取得した版番号、及び、ステップS243で取得した更新ファイルの内容を含む。更新ファイル配付手段240は、ステップS243で、複数の版番号についての更新ファイルを取得している場合には、更新ファイル適用要求に、取得した複数の更新ファイルを含める。
 仮想マシンホスト400は、リポジトリサーバ200から更新ファイル適用要求を受け取ると、更新ファイル適用手段430により、更新ファイル適用処理を行う。図17に、更新ファイル適用処理の手順を示す。更新ファイル適用手段430は、更新ファイル適用要求で指定されている仮想マシンの稼働状況を確認する(ステップS431)。更新ファイル適用手段430は、仮想マシンが動作中のときは、その仮想マシンを停止する(ステップS432)。
 更新ファイル適用手段430は、仮想マシンの停止後、イメージファイル記憶域450のうち、更新ファイル適用要求で指定されているイメージファイルに対して、更新ファイル適用要求に含まれる更新ファイルの内容を展開する(ステップS433)。ステップS433にて、仮想マシンがアクセスするファイルシステム中に、更新ファイルの内容を展開することで、版管理表310の仮想マシン上のファイル名に記録されているファイル名又はディレクトリ名の内容が、所望の版のイメージファイルにおけるファイル又はディレクトリの内容に更新される。
 更新ファイル適用手段430は、ステップS433では、更新ファイル適用要求に複数の更新ファイルが含まれる場合は、版番号が小さい更新ファイルから順に、更新ファイルの内容を展開する。例えば、更新ファイル適用要求に版番号「2」の更新ファイルと版番号「3」の更新ファイルが含まれる場合は、更新ファイル適用手段430は、版番号「2」の更新ファイルの内容を展開した後に、版番号「3」の更新ファイルの内容を展開する。更新ファイル適用手段430は、ステップS431で仮想マシンが稼働中でないと判断した場合は、そのままステップS433に進み、イメージファイル記憶域450に、更新ファイルの内容を展開する。
 更新ファイル適用手段430は、更新ログ470の末尾に、更新記録を記入する(ステップS434)。更新対象の更新ログ470は、ステップS433で更新ファイルを展開した仮想マシンに対応する更新ログである。更新ファイル適用手段430は、ステップS434では、ステップS433で展開した更新ファイルのうち、最も新しい版番号を、更新記録に記入する。すなわち、更新ファイル適用手段430は、版番号が最大の更新ファイルの版番号を、更新記録に記入する。
 最後に、スナップショットの取得/登録の詳細について説明する。システム管理者は、仮想マシン管理装置100を操作して、スナップショット登録を選択する(図7のM51)。その際、システム管理者は、仮想マシン管理装置100に、スナップショット取得元の仮想マシンホスト400のホスト名(以下、スナップショット取得元ホスト名とも呼ぶ)と、仮想マシン名とを入力する。
 仮想マシン管理装置100は、スナップショット登録操作が行われると、リポジトリサーバ200に、スナップショット登録要求を送る(図7のM52)。スナップショット取得要求は、システム管理者によって入力された情報、すなわち、スナップショット取得先ホスト名と、仮想マシン名とを含む。
 リポジトリサーバ200は、仮想マシン管理装置100からスナップショット登録要求を受けると、スナップショット登録手段250により、スナップショット登録処理を行う。図18にスナップショット登録処理の手順を示す。スナップショット登録の手順の大部分は、更新ファイル登録処理の手順(図14)と同様である。スナップショット登録処理と更新ファイル登録処理との主な相違点は、更新ファイルに加えて、イメージファイルを登録する点である。
 スナップショット登録手段250は、受信したスナップショット登録要求に含まれる仮想マシン名をキーとして版管理表310を検索し、最新のイメージファイル又は更新ファイルの版番号を取得する(ステップS251)。スナップショット登録手段250は、仮想マシンホスト400に対して、スナップショット取得要求を送信する(ステップS252)。このステップS252は、図7のM53に相当する。
 スナップショット登録手段250は、ステップS252では、スナップショット取得要求にて指定されているスナップショット取得元仮想マシンホスト名に該当する仮想マシンホスト400に、スナップショット取得要求を送信する。スナップショット取得要求は、スナップショット取得要求に含まれる仮想マシン名、ステップS251で検索結果として得られた版番号を含む。
 仮想マシンホスト400は、スナップショット取得要求を受け取ると、スナップショット取得手段440により、スナップショット取得処理を行う。図19に、スナップショット取得処理の手順を示す。スナップショット取得処理の手順の大部分は、図15に示す更新ファイル取得処理の手順と同じである。スナップショット取得処理と更新ファイル取得処理との主な相違点は、更新ファイルに加えて、イメージファイルを取得する点である。
 スナップショット取得手段440は、イメージファイル記憶域450から、スナップショット取得要求で指定された仮想マシンについての現在の版番号を取得する(ステップS441)。スナップショット取得手段440は、ステップS441で取得した版番号と、スナップショット取得要求で指定された版番号とを比較し、両者が一致するか否かを判断する(ステップS442)。スナップショット取得手段440は、両者が一致しないときは、スナップショット取得要求への応答として、リポジトリサーバ200に失敗を通知し(ステップS448)、処理を終了する。
 スナップショット取得手段440は、ステップS442で版番号が一致すると判断したときは、スナップショット取得要求で指定された仮想マシンが動作中であるか否かを調べる(ステップS443)。スナップショット取得手段440は、仮想マシンが動作中のときは、仮想マシンを停止する(ステップS444)。スナップショット取得手段440は、仮想マシンの停止後、イメージファイル記憶域450中の、スナップショット取得要求で指定された仮想マシンに対応するイメージファイル上の更新ログ470に、更新記録を記録する(ステップS445)。スナップショット取得手段440は、ステップS445では、ステップS441で取得した版番号に1を加えた版番号を、更新記録として記録する。
 スナップショット取得手段440は、ステップS443で仮想マシンが動作中でないと判断したときは、そのままステップS445に進み、更新ログ470に、更新記録を記録する。スナップショット取得手段440は、更新記録の記録後、更新ログ470から、前回の更新記録の記録(版更新)と今回の更新記録の記録との間に仮想マシン上でなされた変更履歴を取得する。
 スナップショット取得手段440は、取得した変更履歴に基づいて、仮想マシン上で変更があったファイル又はディレクトリを特定し、前回の更新からどのような変更があったかを調べ、変更情報を生成する。また、スナップショット取得手段440は、変更があったファイル又はディレクトリの内容を取得し、更新ファイルを生成する。更に、スナップショット取得手段440は、同仮想マシンについてのイメージファイル全体を取得する(ステップS446)。スナップショット取得手段440は、作成した更新ファイル及び変更情報と、取得したイメージファイルとを、スナップショット取得要求に対する応答としてリポジトリサーバ200に送信し(ステップS447)、処理を終了する。
 図18に戻り、スナップショット登録手段250は、ステップS252で送信した仮想マシンホスト400からスナップショット取得要求に対する応答を受け取る。受け取る応答は、成功応答(図19のステップS447)又はエラー応答(ステップS448)である。成功応答の場合は、応答には、スナップショット取得に成功した旨に加えて、イメージファイルの内容と、更新ファイル及び変更情報とを含む。応答に含まれるイメージファイル及び更新ファイルは、スナップショット取得要求で指定した仮想マシンについて、仮想マシンホスト400上での最新版に相当する版番号を持つ。
 スナップショット登録手段250は、仮想マシンホスト400からスナップショット取得要求に対応する応答を受け取ると、スナップショットの取得に成功したか否かを判断する(ステップS253)。スナップショット登録手段250は、仮想マシンホスト400からスナップショット取得に失敗した旨の応答を受け取ったときは、仮想マシン管理装置100に対する応答として失敗を通知し(ステップS257)、処理を終了する。スナップショット取得に失敗する典型的な例は、スナップショット取得要求で指定した版番号と、スナップショット取得元の仮想マシンホスト400上での版番号とが異なる場合、すなわち、更新の競合が発生した場合である。
 スナップショット登録手段250は、スナップショット取得要求に成功したと判断すると、取得したイメージファイル及び更新ファイルに対するリポジトリ内ファイル名を決定する(ステップS254)。イメージファイルに対するリポジトリ内ファイル名は、イメージファイル登録手段210によるリポジトリ内ファイル名の決定(図11のステップS211)と同様である。また、更新ファイルに対するリポジトリ内ファイル名の決定では、更新ファイル登録手段230によるリポジトリ内ファイル名の決定(図14のステップS234)と同様である。
 スナップショット登録手段250は、記憶装置300に、仮想マシンホスト400から取得したイメージファイル及び更新ファイルを格納する(ステップS255)。このステップS255は、図7のM54に相当する。スナップショット登録手段250は、ステップS255では、イメージファイル及び更新ファイルに、それぞれステップS254で決定したリポジトリ内ファイル名を付与する。スナップショット登録手段250は、版管理表310に、格納したイメージファイル及び更新ファイルの情報をそれぞれ追加する(ステップS256)。このステップS256は、図7のM55に相当する。スナップショット登録手段250は、版管理表310への情報追加後、仮想マシン管理装置100への応答として成功を通知し、処理を終了する。
 スナップショット登録手段250は、ステップS256では、イメージファイルについて、版管理表310に情報を記録するためのエントリを追加し、各項目に、以下の情報を記録する。「仮想マシン名」には、受信したスナップショット登録要求に含まれる仮想マシン名を記録する。「版番号」には、ステップS251で取得した版番号に1を加えた版番号を記録する。「種別」には「イメージファイル」を記録し、「リポジトリ内ファイル名」には、ステップS254で決定したイメージファイル用のリポジトリ内ファイル名を記録する。
 また、スナップショット登録手段250は、更新ファイルについて、版管理表310に情報を記録するためのエントリを追加し、各項目に、以下の情報を記録する。「仮想マシン名」には、受信したスナップショット登録要求に含まれる仮想マシン名を記録する。「版番号」には、ステップS251で取得した版番号に1を加えた版番号を記録する。「種別」には更新ファイルを記録し、「リポジトリ内ファイル名」には、ステップS254で決定した更新ファイル用のリポジトリ内ファイル名を記録する。また、「仮想マシン上のファイル名」には、ステップS252のスナップショット取得要求に対する応答に含まれる変更情報に含まれるファイル名を記録する。
 管理者は、任意の時点で、仮想マシン管理装置100を用いて、仮想マシンを指定して、ある版から別の版までに、どのようなファイルが変更されたかを調べる。仮想マシン管理装置100は、リポジトリサーバ200を通じて版管理表310を参照し、版管理表310における「仮想マシン上のファイル名」の情報を取得する。仮想マシン管理装置100が、この「仮想マシン上のファイル名」の情報をディスプレイ等の出力装置に出力することで、管理者は、版間でどのようなファイルが変更されたかを、容易に知ることができる。
 本実施形態では、更新ファイル登録手段230は、仮想マシンにおけるイメージファイルの版を更新し、過去の版更新時点でのイメージファイルから今回の版更新時点でのイメージファイルを生成するための差分情報を含む更新ファイルを記憶装置300に登録する。また、更新ファイル登録手段230は、過去の版更新から今回の版更新までの間に仮想ディスクに対してどのような変更がなされたかを示す変更情報を版管理表310に記録する。本実施形態では、版管理表310に変更情報を記録している。管理者は、この変更情報を参照することで、仮想マシンについて異なる版の間で、更新ファイルの中身を見なくても、どのファイル/ディレクトリが、どのように変更されたかを知ることができる。
 本実施形態では、更新ファイル取得手段420は、変更されたファイルの内容、又は、変更前後でのファイル内容の差分を、差分情報として更新ファイルに含める。仮に、各版のイメージファイルを記憶装置300に登録することを考えると、イメージファイルは仮想ディスク全体の内容を含むため、イメージファイルの記憶装置300への登録には長時間を要することになる。また、イメージファイルは、大きなストレージ容量を消費する。本実施形態では、変更があった部分を更新ファイルとして持つ構成であるので、更新ファイルの登録に要する時間は、仮想ディスク全体の内容(イメージファイル)を登録する場合に比して、短くて済む。また、更新ファイルの登録に必要な記憶装置300に必要なストレージ容量も少なくて済む。
 ここで、更新ファイル(差分情報)の別例として、イメージファイル同士の差分を、差分情報とすることも考えられる。この場合でも、差分情報を版更新前のイメージファイルに適用することで、イメージファイルの版更新が可能である。また、イメージファイルそのものを記憶装置300に登録する場合に比して、登録に要する時間及び消費するストレージ容量は少なくて済む。更新ファイルを、イメージファイル同士の差分としたときでも、変更情報を参照することで、異なる版の間で、どのファイル/ディレクトリが、どのように変更されたかを知ることができるという効果は得られる。ただし、イメージファイルは通常サイズが大きいので、版更新前後のイメージファイルの比較には、長時間を要する。また、比較処理を行う際には、コンピュータ上に、イメージファイルの新旧の版の双方を一時的におく必要があるため、そのコンピュータのストレージ領域を余分に消費することになる。
 仮想ディスクにて変更されたファイルのサイズは、イメージファイル(仮想ディスク全体)よりもサイズが小さい。このため、変更されたファイルの内容の取得、又は、変更されたファイルの変更前後でのファイル内容の差分の生成に掛かる時間は、イメージファイル同士の差分を生成するのに要する時間に比して短い。従って、変更されたファイルの内容、又は、変更前後でのファイル内容の差分を更新ファイルとすることで、イメージファイル同士の差分を更新ファイルとする場合に比して、更新ファイルの生成を短時間で行うことができる。また、作業に必要なストレージ容量も節約できる。
 本実施形態では、仮想ディスクに対して行われた変更を記録した更新ログを参照して仮想ディスクにて変更があったファイルを特定する。通常、イメージファイルのサイズは大きく、仮想ディスクには多数のファイルが含まれているため、異なる版間のイメージファイルから変更があったファイルを特定すると、時間が掛かることになる。本実施形態では、更新ログを参照して変更があったファイルを特定しているため、イメージファイルを展開し、仮想ディスク上のファイルシステムを比較して変更があったファイルを特定する場合に比して、短時間で変更があったファイルの特定が可能である。
 本実施形態では、スナップショット登録手段250は、仮想マシンにおけるイメージファイルの版を更新し、版更新時点でのイメージファイルと、前回の版更新から今回の版更新までに対応する更新ファイル及び変更情報とを取得し、記憶装置300に格納する。スナップショット登録手段250を用いた構成では、特定の版のイメージファイルを、仮想マシンホストに対して配付することができる。例えば、スナップショット登録の動作で、版番号「4」のイメージファイル320を記憶装置300に格納しておくことで、版番号「5」のイメージファイルの配付に際しては、版番号「4」のイメージファイルと、版番号「5」の更新ファイルを配付すればよいことになる。従って、常に版番号「1」のイメージファイルからの差分で特定の版番号のイメージファイル配付を行う場合に比して、イメージファイル配備に要する時間を短縮できる。
 なお、上記実施形態では、仮想マシンの状態を表すイメージファイルの版管理を行う例について説明したが、本発明の版管理システムは、この例には限定されず、通常のサーバホストにおけるストレージ装置のイメージを含むイメージファイルの版管理を行ってもよい。図20に、サーバホストのイメージファイルの版管理を行う版管理システムの例を示す。この版管理システムは、図1における仮想マシンホスト400がサーバホスト400aに置き換わり、イメージファイル記憶域450がストレージ装置480に置き換わる点を除き、基本的に、上記実施形態の版管理システムと同様な構成である。
 ストレージ装置480は、管理対象のストレージ装置であり、イメージファイル作成対象のストレージ装置である。ストレージ装置480は、実ストレージ装置でもよく、或いは、実ストレージ装置上に構築された仮想的なストレージ装置でもよい。イメージファイル作成単位は、ストレージ装置480全体でもよく、ストレージ装置480に設けられた領域(パーティション)でもよい。サーバホスト400a内の各手段を実現するためのプログラムは、サーバホスト400a内の記憶装置上に記録されている。これらプログラムが格納される部分と、ストレージ装置480でディスクイメージ(イメージファイル)が書き出される部分とは、異なるディスク又は異なる領域であることが好ましい。また、サーバホスト400a内の各手段を実現するためのプログラムは、サーバホスト400aが内蔵する読み出し専用メモリ(ROM)内にファームウェア(Firmware)として記録されていてもよい。この場合、更新ログ470は、記憶装置上の単独のディスク又は領域、不揮発性メモリなどの上に記録することが好ましい。
 図20に示す版管理システムの全体の動作の概略について説明する。イメージファイル登録手段210は、記憶装置300にイメージファイル320を登録する。イメージファイル320は、ストレージ装置480のディスクイメージを含む。イメージファイル配付手段220は、イメージファイル320を、サーバホスト400aに送信する。イメージファイル配備手段410は、リポジトリサーバ200からイメージファイルを受け取り、受け取ったイメージファイルをストレージ装置480に配備する。すなわち、イメージファイル配備手段410は、サーバホスト400aがアクセス可能な状態となるように、イメージファイルの内容をストレージ装置480上に展開する。
 更新ファイル取得手段420は、更新ファイル登録手段230からの指示でストレージ装置480における版を更新すると共に、更新ファイル及び変更情報を生成し、更新ファイル登録手段230に送信する。更新ファイルは、過去の版更新時点でのディスクイメージから今回の版更新時点でのディスクイメージを生成するための差分情報を含む。より詳細には、更新ファイルは、ストレージ装置480に構築されたファイルシステム上で変更されたファイル/ディレクトリの内容、又は、ファイルシステム上で変更されたファイル/ディレクトリの変更前後での内容の差分を、差分情報として含む。或いは、更新ファイル330は、異なる版間でのディスクイメージ同士の差分を差分情報として含んでいてもよい。変更情報は、過去の版更新から今回の版更新までの間にストレージ装置480に対してどのような変更がなされたかを示す情報である。
 更新ログ記録手段460は、ストレージ装置480に対して行われた変更を、更新ログ470に記録する。更新ファイル取得手段420は、更新ログ470を参照して、ストレージ装置480にて変更があったファイルを特定し、変更情報に、ファイルシステム上で変更があったファイルを識別するための情報を含める。更新ファイル登録手段230は、サーバホスト400aから更新ファイル及び変更情報を取得する。更新ファイル登録手段230は、取得した更新ファイルを、記憶装置300に更新ファイル330として登録する。また、更新ファイル登録手段230は、取得した変更情報を版管理表310に記録する。
 更新ファイル配付手段240は、記憶装置300から更新ファイル330を取得し、取得した更新ファイルに含まれる差分情報を、サーバホスト400aに送信する。更新ファイル適用手段430は、更新ファイル配付手段240から差分情報を受け取り、受け取った差分情報をストレージ装置480に適用する。更新ファイル適用手段430が差分情報をストレージ装置480に適用することで、ストレージ装置480の版が更新ファイルの版に更新される。
 スナップショット取得手段440は、スナップショット登録手段250からの指示でストレージ装置480の版を更新し、版更新時点でのストレージ装置480の内容をイメージファイル化し、スナップショット登録手段250に送信する。また、スナップショット取得手段440は、更新ファイル取得手段420と同様な手順で更新ファイル及び変更情報を生成し、スナップショット登録手段250に送信する。スナップショット登録手段250は、取得したイメージファイル及び更新ファイルを、記憶装置300にそれぞれイメージファイル320及び更新ファイル330として登録する。また、スナップショット登録手段250は、取得した変更情報を版管理表310に記録する。
 ところで、図1及び図20の構成では、各仮想マシンホスト400又は各サーバホスト400a(以下、単にサーバホストとも呼ぶ)がイメージファイル配備手段410などの各手段を有する構成を説明したが、各サーバホストが各手段を持つことは必須ではない。例えば、イメージファイル記憶域450(図1)又はストレージ装置480(図20)がサーバホスト以外の装置からアクセス可能であれば、その装置が、イメージファイル配備手段410、更新ファイル取得手段420、更新ファイル適用手段430、及び、スナップショット取得手段440を有していてもよい。その場合、イメージファイル配備手段410等の各手段を持つ装置が、複数のサーバホストに対して、イメージファイルの配備、更新ファイルの送信などの処理を行ってもよい。
 本発明の第1の態様に係る版管理システムは、その最小構成において、ストレージ装置内に構築された管理対象のファイルシステムの少なくとも一部の内容を表すストレージイメージを含むイメージファイルを記憶装置に登録するイメージファイル登録手段と、前記記憶装置に登録されたイメージファイルと、版更新時点におけるイメージファイルとの差を表す差分情報を含む更新ファイルを前記記憶装置に登録し、前記記憶装置に登録されたイメージファイルの版に対応するファイルシステムに対して前記版更新時点までに実行された各変更イベントを示す変更情報を版管理表に記録する更新ファイル登録手段と、を備える。
 本発明の第2の態様に係るサーバホストは、その最小構成において、ストレージ装置内に構築された管理対象のファイルシステムの少なくとも一部の内容を表すストレージイメージを含むイメージファイルをイメージファイル記憶域に登録するイメージファイル配備手段と、前記イメージファイル記憶域に登録されたイメージファイルと、版更新時点におけるイメージファイルとの差を表す差分情報を含む更新ファイルを取得し、前記イメージファイル記憶域に登録されたイメージファイルの版に対応するファイルシステムに対して前記版更新時点までに実行された各変更イベントを示す変更情報を生成する更新ファイル取得手段と、を備える。
 本発明の第3の態様に係る版管理方法は、その最小構成において、コンピュータを用いる版管理方法であって、ストレージ装置内に構築された管理対象のファイルシステムの少なくとも一部の内容を表すストレージイメージを含むイメージファイルを記憶装置に登録するステップと、前記記憶装置に登録されたイメージファイルと、版更新時点におけるイメージファイルとの差を表す差分情報を含む更新ファイルを前記記憶装置に登録するステップと、前記記憶装置に登録されたイメージファイルの版に対応するファイルシステムに対して前記版更新時点までに実行された各変更イベントを示す変更情報を版管理表に記録するステップと、を有する。
 本発明の第4の態様に係る版管理方法は、その最小構成において、コンピュータを用いる版管理方法であって、ストレージ装置内に構築された管理対象のファイルシステムの少なくとも一部の内容を表すストレージイメージを含むイメージファイルをイメージファイル記憶域に登録するステップと、前記イメージファイル記憶域に登録されたイメージファイルと、版更新時点におけるイメージファイルとの差を表す差分情報を含む更新ファイルを取得するステップと、前記イメージファイル記憶域に登録されたイメージファイルの版に対応するファイルシステムに対して前記版更新時点までに実行された各変更イベントを示す変更情報を生成するステップと、を有する。
 本発明の版管理システム、方法、及び、プログラムは、特に限定はされないが、仮想マシンについてのイメージファイルを対象とした版管理に用いると、版間の差異を、容易に参照することができる。このため、任意の版のイメージファイルが容易に構築でき、それに基づいて任意の時点におけるコンピュータの状態の再現が容易である。
 本発明を特別に示し且つ例示的な実施形態を参照して説明したが、本発明は、その実施形態及びその変形に限定されるものではない。当業者に明らかなように、本発明は、添付の請求の範囲に規定される本発明の精神及び範囲を逸脱することなく、種々の変更が可能である。
 本出願は、2008年6月20日出願に係る日本特許出願2008-162236号を基礎とし且つその優先権を主張するものであり、引用によってその開示の内容の全てを本出願の明細書中に加入する。
 本発明は、ソフトウェア開発において、仮想マシンを用いた試験/評価システムの版管理といった用途に適用できる。また、ソフトウェア実運用環境において、仮想マシンを用いて構築されたシステムの版管理といった用途にも適用できる。
 

Claims (17)

  1.  ストレージ装置内に構築された管理対象のファイルシステムの少なくとも一部の内容を表すストレージイメージを含むイメージファイルを記憶装置に登録するイメージファイル登録手段と、
     前記記憶装置に登録されたイメージファイルと、版更新時点におけるイメージファイルとの差を表す差分情報を含む更新ファイルを前記記憶装置に登録し、前記記憶装置に登録されたイメージファイルの版に対応するファイルシステムに対して前記版更新時点までに実行された各変更イベントを示す変更情報を版管理表に記録する更新ファイル登録手段とを備える版管理システム。
  2.  前記ストレージ装置が、仮想マシンホスト上で動作する仮想マシンがアクセスする仮想ストレージである、請求項1に記載の版管理システム。
  3.  前記更新ファイル登録手段からの要求に応答し、前記ストレージ装置内の現在のファイルシステムに対応する前記更新ファイル及び前記変更情報を取得し、該取得した更新ファイル及び変更情報を前記更新ファイル登録手段に送信する更新ファイル取得手段を更に備える、請求項1又は2に記載の版管理システム。
  4.  前記更新ファイル取得手段は、前記ファイルシステムに対して行われた変更を記録した更新ログを参照して、前記変更があった変更対象のファイルを特定し、前記送信される変更情報が、前記更新ファイル取得手段によって特定された変更対象のファイルを識別する情報を含む、請求項3に記載の版管理システム。
  5.  前記差分情報が、前記ファイルシステム内で変更されたファイル及び/又はディレクトリの内容、又は、前記ファイル及び/又はディレクトリの変更前後での内容の差分を表す情報を含む、請求項3又は4に記載の版管理システム。
  6.  前記記憶装置から前記更新ファイルを取得し、該取得した更新ファイルに含まれる差分情報を送信する更新ファイル配付手段と、
     前記更新ファイル配付手段から前記差分情報を受け取り、該差分情報を前記ストレージ装置に適用する更新ファイル適用手段とを更に有する、請求項1乃至5の何れか一に記載の版管理システム。
  7.  前記記憶装置から前記イメージファイル及び更新ファイルを読み出し、該読み出したイメージファイル及び更新ファイルから、特定の版のイメージファイルを取得し、該取得したイメージファイルを送信するイメージファイル配付手段と、
     前記イメージファイル配付手段から前記特定の版のイメージファイルを受信し、該受信したイメージファイルを前記ストレージ装置のファイルシステムに配備するイメージファイル配備手段とを更に備える、請求項1乃至6の何れか一に記載の版管理システム。
  8.  前記ストレージ装置における版更新時点でのイメージファイル及び前記更新ファイルを前記記憶装置に登録し、且つ、版更新時点までの変更情報を前記版管理表に記録するスナップショット登録手段を更に備える、請求項1乃至7の何れか一に記載の版管理システム。
  9.  前記スナップショット登録手段からの版更新要求に応答し、現在のファイルシステムの内容に基づいて、前記更新ファイル及び前記変更情報を作成し、版更新時点でのイメージファイルと、前記作成した更新ファイル及び変更情報とを前記スナップショット登録手段に送信するスナップショット取得手段を更に有する、請求項8に記載の版管理システム。
  10.  前記更新ファイル登録手段に版更新処理の指令を与える、システム管理者が操作する管理装置を更に備える、請求項1乃至9の何れか一に記載の版管理システム。
  11.  ストレージ装置内に構築された管理対象のファイルシステムの少なくとも一部の内容を表すストレージイメージを含むイメージファイルをイメージファイル記憶域に登録するイメージファイル配備手段と、
     前記イメージファイル記憶域に登録されたイメージファイルと、版更新時点におけるイメージファイルとの差を表す差分情報を含む更新ファイルを取得し、前記イメージファイル記憶域に登録されたイメージファイルの版に対応するファイルシステムに対して前記版更新時点までに実行された各変更イベントを示す変更情報を生成する更新ファイル取得手段とを備えるサーバホスト。
  12.  更新ファイル取得手段は、前記ファイルシステムに対して行われた変更を記録した更新ログを参照して、前記変更があった変更対象のファイルを特定し、前記送信される変更情報が、前記更新ファイル取得手段によって特定された変更対象のファイルを識別する情報を含む、請求項11に記載のサーバホスト。
  13.  前記更新ファイルが、前記ファイルシステム内で変更されたファイル及び/又はディレクトリの内容、又は、前記ファイル及び/又はディレクトリの変更前後での内容の差分を含む、請求項11又は12に記載のサーバホスト。
  14.  コンピュータを用いる版管理方法であって、
     ストレージ装置内に構築された管理対象のファイルシステムの少なくとも一部の内容を表すストレージイメージを含むイメージファイルを記憶装置に登録するステップと、
     前記記憶装置に登録されたイメージファイルと、版更新時点におけるイメージファイルとの差を表す差分情報を含む更新ファイルを前記記憶装置に登録するステップと、
     前記記憶装置に登録されたイメージファイルの版に対応するファイルシステムに対して前記版更新時点までに実行された各変更イベントを示す変更情報を版管理表に記録するステップと、を有する版管理方法。
  15.  コンピュータを用いる版管理方法であって、
     ストレージ装置内に構築された管理対象のファイルシステムの少なくとも一部の内容を表すストレージイメージを含むイメージファイルをイメージファイル記憶域に登録するステップと、
     前記イメージファイル記憶域に登録されたイメージファイルと、版更新時点におけるイメージファイルとの差を表す差分情報を含む更新ファイルを取得するステップと、
     前記イメージファイル記憶域に登録されたイメージファイルの版に対応するファイルシステムに対して前記版更新時点までに実行された各変更イベントを示す変更情報を生成するステップと、を有する版管理方法。
  16.  コンピュータに、
     ストレージ装置内に構築された管理対象のファイルシステムの少なくとも一部の内容を表すストレージイメージを含むイメージファイルを記憶装置に登録する処理と、
     前記記憶装置に登録されたイメージファイルと、版更新時点におけるイメージファイルとの差を表す差分情報を含む更新ファイルを前記記憶装置に登録する処理と、
     前記記憶装置に登録されたイメージファイルの版に対応するファイルシステムに対して前記版更新時点までに実行された各変更イベントを示す変更情報を版管理表に記録する処理と、を実行させるプログラム。
  17.  コンピュータに、
     ストレージ装置内に構築された管理対象のファイルシステムの少なくとも一部の内容を表すストレージイメージを含むイメージファイルをイメージファイル記憶域に登録する処理と、
     前記イメージファイル記憶域に登録されたイメージファイルと、版更新時点におけるイメージファイルとの差を表す差分情報を含む更新ファイルを取得する処理と、
     前記イメージファイル記憶域に登録されたイメージファイルの版に対応するファイルシステムに対して前記版更新時点までに実行された各変更イベントを示す変更情報を生成する処理と、を実行させるプログラム。
                    
PCT/JP2009/061215 2008-06-20 2009-06-19 版管理システム、方法、及び、プログラム WO2009154272A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010517976A JPWO2009154272A1 (ja) 2008-06-20 2009-06-19 版管理システム、方法、及び、プログラム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2008-162236 2008-06-20
JP2008162236 2008-06-20

Publications (1)

Publication Number Publication Date
WO2009154272A1 true WO2009154272A1 (ja) 2009-12-23

Family

ID=41434184

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2009/061215 WO2009154272A1 (ja) 2008-06-20 2009-06-19 版管理システム、方法、及び、プログラム

Country Status (2)

Country Link
JP (1) JPWO2009154272A1 (ja)
WO (1) WO2009154272A1 (ja)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011117956A1 (ja) * 2010-03-20 2011-09-29 株式会社Pfu 仮想マシン管理装置、開発システム、仮想マシン管理方法、及びプログラム
WO2011117954A1 (ja) * 2010-03-20 2011-09-29 株式会社Pfu 仮想マシン管理装置、仮想マシン管理方法、及びプログラム
WO2011117955A1 (ja) * 2010-03-20 2011-09-29 株式会社Pfu 仮想マシン管理装置、仮想マシン管理システム、仮想マシン管理方法、及びプログラム
JP2013065259A (ja) * 2011-09-20 2013-04-11 Hitachi Solutions Ltd データ転送システム、転送元システム及び転送先システム並びにプログラム
JP2015225632A (ja) * 2014-05-30 2015-12-14 日本電気株式会社 シンクライアント端末装置、サーバ装置、方法、およびプログラム
US9235349B2 (en) 2012-03-30 2016-01-12 Nec Corporation Data duplication system, data duplication method, and program thereof
JP2019101917A (ja) * 2017-12-06 2019-06-24 クラリオン株式会社 更新装置、更新システム
CN111736875A (zh) * 2020-06-28 2020-10-02 深圳前海微众银行股份有限公司 版本更新监控方法、装置、设备及计算机存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10214214A (ja) * 1997-01-30 1998-08-11 Matsushita Electric Ind Co Ltd データ管理方式
JPH11120057A (ja) * 1997-10-17 1999-04-30 Hitachi Ltd ファイルバックアップ方法
JP2005301497A (ja) * 2004-04-08 2005-10-27 Hitachi Ltd ストレージ管理装置、リストア方法及びそのプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10214214A (ja) * 1997-01-30 1998-08-11 Matsushita Electric Ind Co Ltd データ管理方式
JPH11120057A (ja) * 1997-10-17 1999-04-30 Hitachi Ltd ファイルバックアップ方法
JP2005301497A (ja) * 2004-04-08 2005-10-27 Hitachi Ltd ストレージ管理装置、リストア方法及びそのプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MANARU HATTA: "SD-ryu Kasoka Gijutsu Full Course Koremade no VMware Korekara no VMware", SOFTWAREDESIGN, 18 May 2007 (2007-05-18), pages 41 - 42 *

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2011117956A1 (ja) * 2010-03-20 2011-09-29 株式会社Pfu 仮想マシン管理装置、開発システム、仮想マシン管理方法、及びプログラム
WO2011117954A1 (ja) * 2010-03-20 2011-09-29 株式会社Pfu 仮想マシン管理装置、仮想マシン管理方法、及びプログラム
WO2011117955A1 (ja) * 2010-03-20 2011-09-29 株式会社Pfu 仮想マシン管理装置、仮想マシン管理システム、仮想マシン管理方法、及びプログラム
JPWO2011117956A1 (ja) * 2010-03-20 2013-07-04 株式会社Pfu 仮想マシン管理装置、開発システム、仮想マシン管理方法、及びプログラム
JP5403445B2 (ja) * 2010-03-20 2014-01-29 株式会社Pfu 仮想マシン管理装置、仮想マシン管理方法、及びプログラム
JP5403446B2 (ja) * 2010-03-20 2014-01-29 株式会社Pfu 仮想マシン管理装置、仮想マシン管理システム、仮想マシン管理方法、及びプログラム
JP2013065259A (ja) * 2011-09-20 2013-04-11 Hitachi Solutions Ltd データ転送システム、転送元システム及び転送先システム並びにプログラム
US9235349B2 (en) 2012-03-30 2016-01-12 Nec Corporation Data duplication system, data duplication method, and program thereof
JP2015225632A (ja) * 2014-05-30 2015-12-14 日本電気株式会社 シンクライアント端末装置、サーバ装置、方法、およびプログラム
JP2019101917A (ja) * 2017-12-06 2019-06-24 クラリオン株式会社 更新装置、更新システム
CN111736875A (zh) * 2020-06-28 2020-10-02 深圳前海微众银行股份有限公司 版本更新监控方法、装置、设备及计算机存储介质
CN111736875B (zh) * 2020-06-28 2024-07-02 深圳前海微众银行股份有限公司 版本更新监控方法、装置、设备及计算机存储介质

Also Published As

Publication number Publication date
JPWO2009154272A1 (ja) 2011-12-01

Similar Documents

Publication Publication Date Title
WO2009154272A1 (ja) 版管理システム、方法、及び、プログラム
US8245217B2 (en) Management of software and operating system updates required for the process of creating a virtual machine facsimile of an existing physical or virtual machine
US8996667B2 (en) Deploying an operating system
USRE46748E1 (en) Converting images in virtual environments
US8417796B2 (en) System and method for transferring a computing environment between computers of dissimilar configurations
KR101376952B1 (ko) 머신을 가상 머신으로 변환하는 방법
US20060089995A1 (en) System for conversion between physical machines, virtual machines and machine images
WO2010035597A1 (ja) ファームウェア更新システム、及び更新イメージ生成・配布サーバ装置
US8327096B2 (en) Method and system for efficient image customization for mass deployment
CN102799464A (zh) 虚拟机创建方法及系统、虚拟机重装方法及系统
JP2008015768A (ja) 記憶システム並びにこれを用いたデータの管理方法
US10331427B2 (en) Capturing and deploying an operation system in a computer environment
JP4759941B2 (ja) 起動イメージ提供システム及び方法、ブートノード装置、ブートサーバ装置並びにプログラム
JP5183448B2 (ja) 情報処理装置及び情報処理方法及びプログラム
JP2008033527A (ja) ストレージ装置、ディスク装置及びデータ復元方法
US20190265964A1 (en) Electronic apparatus, updating method, and recording medium
JP2002222106A (ja) クライアント/サーバシステムにおけるクライアントの環境設定装置、方法、プログラム記録媒体およびプログラム
KR102019799B1 (ko) 읽기 및 쓰기가 가능한 가상 디스크의 병합 마운팅을 통한 가상 클러스터 구축 방법 및 장치
JP6497157B2 (ja) 情報管理装置、情報管理方法、情報管理プログラム、データ構造、及び、ソフトウェア資産管理システム
JP5353891B2 (ja) 分散処理システム、分散処理方法およびプログラム
CN113485790B (zh) 一种虚拟机的重启方法、迁移方法和相关设备
JP5725546B2 (ja) ストレージシステム
US20240193052A1 (en) Commit block structure and device, for multiple file transaction
JP2024090917A (ja) データ処理装置及びそのプログラム
JP5772527B2 (ja) データ管理システム及び情報処理装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09766720

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2010517976

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09766720

Country of ref document: EP

Kind code of ref document: A1